20210729のAWSに関する記事は18件です。

FGOの欲しい素材からクエスト周回数を求めるサイトを作った

スマートフォン向けRPG「Fate/Grand Order」のユーザーが使える、欲しいアイテムの個数を入力すると最適なクエストの周回数を求めるサイトを作りました。 欲しい素材の数を入力すると、どのフリクエを何周するのが最も効率的か教えてくれるサイトを作りました周回するクエストに迷ったら使ってみてください#FGOhttps://t.co/JXzZ8fmHmX— あんてな (@antenna_games) July 18, 2021 サイト フロントエンド API スクレイピング サービスの内容 入力フォームから最小化する対象、集めたいアイテムの数、対象に含めるクエストを入力します。 送信すると最適なクエストの周回数がわかります。 作った目的 フォロワーさんがこんなサイトが欲しい!とツイートしていたのをきっかけにモデル化・実装してみたら割と簡単にできたので、色んな人が簡単に使えるようにWebサイトとして公開してみようと思いました。 ビジネスロジック クエスト$q$​​​​、アイテム$i$​​​​に対して、ドロップ率を$p_{qi}$​​​​​、欲しいアイテムの個数を$n_i$​​​​とすると、合計が最小となるクエスト周回数$x_q$​​​​​は次の線形計画問題を解くことで求められます。 最小化: \quad\sum_{q}x_q 制約条件: \sum_{q} p_{qi} x_q \ge n_{i} \quad ( \forall i)\\ x_{q} \ge 0 \quad( \forall q) これをPythonの線形計画APIであるPuLPでモデル化します。まず、ドロップ率が次のような表で与えられているとします。 quest_name item_name drop_rate モントゴメリー 証 0.627 モントゴメリー 塵 0.154 シャーロット 証 0.481 シャーロット 塵 0.642 …… …… …… このとき、塵と証を100個ずつ集めるのに最適な周回数を求めるコードは次のようになります。 import csv import pulp import itertools import operator item_counts = {'塵': 100, '証': 100} with open('drop_rates.csv', 'r', newline='', encoding='utf-8') as f: reader = csv.DictReader(f) rows = [row for row in reader if row['item_name'] in item_counts] quests = set(row['quest_name'] for row in rows) ig = operator.itemgetter('item_name') groups = itertools.groupby(sorted(rows, key=ig), key=ig) #問題の作成 problem = pulp.LpProblem(sense=pulp.LpMinimize) #変数の作成 laps = pulp.LpVariable.dicts('lap', quests, lowBound=0) #目的関数の設定 problem += pulp.lpSum(laps.values()) #制約条件の設定 for item, rows in groups: problem += pulp.lpSum(float(row['drop_rate']) * laps[row['quest_name']] for row in rows) >= item_counts[item] #求解 problem.solve() for quest, lap in laps.items(): if pulp.value(lap) > 0: print(quest, round(pulp.value(lap))) これを実行すると次のような結果が得られます。 シャーロット 144 モントゴメリー 49 このように、PuLPでは問題を直感的にモデル化して簡単に解くことができます。 アーキテクチャ スクレイピング クエスト周回数の算出には各クエストのアイテムのドロップ率が必要となります。このデータは自前ではなく、FGOアイテム効率劇場という有志の方による統計データを利用しています。Googleスプレッドシートとして公開されているので、定期的に実行されるLambda関数からGoogle Sheets APIでドロップ率表を取得して、データを整理した後S3に保存しています。 API アイテム数からクエスト周回数を計算するLambda関数です。API Gatawayから呼び出されると、PuLPを使って線形計画問題をモデル化して解きます。 Lambda関数の構築にはAWS SAMを使用しています。YAMLを書くだけでデバッグ・デプロイやポリシー設定をやってくれるので便利です。 フロントエンド Next.js+TypeScriptで構築してVercelでホスティングしています。複雑なデータから静的・動的に生成する必要があり、SSG・SSR・CSRを使い分けられるNext.jsはとても便利でした。 スタイルには手軽に使えるNo-Class CSSフレームワークのMVP.cssとNext.jsに組み込まれているCSS in JSであるstyled-jsxを組み合わせています。 工夫した点 サーバーレス構成 最初はDjangoででも作って、自前の最低スペックのVPSにでも置いておこうかと思ったのですが、友人の助言でLambdaベースとしました。公開したら思ったより伸びて、APIコールが最大500回/時くらいになったのでサーバーレス構成の恩恵を感じました。 メンテナンスフリー クエストやアイテムはストーリーが進むごとに追加されますが、効率劇場からスクレイピングしたデータを元にバックエンド・フロントエンドともに自動的に生成されるので、効率劇場の形式が変わらなければ開発者側で対応することなく新クエストや新アイテムに対応できます。 レスポンシブデザイン スマートフォン向けゲームのユーザー向けということでモバイル端末からのアクセスが多いことが予想されたので、モバイル対応を意識しました。レスポンシブ化自体は簡単にできるのですが、画面に含める情報を必要十分に抑えたり、それぞれのコンポーネントを折りたためるようにしてページ内の移動をしやすくしたり、ラジオボタンやチェックボックスを一回り大きくしてタッチしやすくしたり、といったところに気を付けました。 Twitter共有 FGOはTwitterコミュニティが活発なので、結果をTwitterに共有できるようにTweet Web Intentを付けてみたのですが、ユースケースが可視化されて結構参考になりました。 引っかかった点 フロントエンドとバックエンドのすり合わせ フロントエンドをTypeScript、バックエンドをPythonで作っていますが、データやAPIの設計はきちんとすべきだと感じました。キャメルケースとスネークケースが入り混じったり、Pythonでは多用しがちな動的キーの辞書がTypeScriptだと扱いづらかったり……。 AWSの環境変数がVercelで予約されている フロントエンドのSSGのときにgetStaticPropsでS3バケットからアイテムやクエストのリストを取得しているのですが、AWSのAPIを叩くときには認証情報が必要です。Node.jsでは環境変数を使って認証するのが一番手っ取り早く、Vercelにもセキュアに環境変数を設定する機能があるので安心していたのですが、認証に使うAWS_ACESS_KEY_IDやAWS_SECRET_ACESS_KEYはVercelでは予約済みのため使えませんでした。認証情報をファイルとして置いておく方法もあるのですが、GitHubの公開リポジトリにリンクする形でデプロイしているので、S3の読み取り権限しか付与していないとはいえ認証情報を公開するわけにもいかないのでこの方法も使えませんでした。 最終的に環境変数名を衝突しないように変更して、プログラム側で読み取ってAWS SDKに直接渡すようにしましたが、これがベストプラクティスなのかはよくわかりません。 react-checkbox-treeが再現性なくクラッシュする 周回対象に含めるクエストを選択するためにreact-checkbox-treeを使用していました。 ツリー構造はセクション>エリア>クエストの3層になっています。ここで、S3にあるオブジェクトはクエストごとにセクションとエリアが書かれたフラットな表で、ツリー構造を作るときにセクション名やエリア名をキーにしてグループ化を行っていたのですが、キーとなるセクション名やエリア名に元のオブジェクトにはない文字コードが混入することがありました。こうなると同一のIDの枝が2つ生える事態となり、react-checkbox-treeがクラッシュしてしまいます。それだけならまだましなのですが、React16からコンポーネントがエラーを起こすとツリー全体がアンマウントされる仕様になっていたため、一部のユーザーの画面にはエラーメッセージが表示されるだけという事態になっていました。 一部のコンポーネントのエラーがDOM全体を巻き添えにする仕様についてはerror boundaryを設定して回避します。また、この問題に対する解決策として、グルーピングにセクション名やエリア名の代わりにIDを使用するようにしました。 まとめ FGOの欲しい素材からクエスト周回数を求めるサイトを作りました。AWSもReactも初めて触りましたが、AWS SAMとNext.jsが面倒な設定などはすべてやってくれるので割とすんなり作ることができました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

RDS - 既存のRDSを削除して新たにRDSを作成しWordPress.orgと接続させる

まえがき WordPressを作成した当初、DBインスタンスサイズを無料枠のdb.t2.microではなく db.t3.microを選択してしまい、どんどん課金がされていました(月額890円くらいでした)。 こちらに写真を載せております。 前提にも記述しますが、変更しようにも変更できず、新しく作成し直すか激しく悩み、 夜中の2時に起床して、思い切って決行しなんとか7時半くらいに終わりました。 1ヶ月ほど前ですが、船長さんに認めてもらえると思います。まもなくドーレ港です! 動作環境 ・MacBook Air (Retina, 13-inch, 2020) ・Big Sur11.4 ・ターミナルシェル:zsh ・Google Chrome 前提 ・既存のRDSですでにWordPress.orgをインストール、接続済み ・RDSのDBインスタンスクラスを変更しようとしたら、 申し訳ありません。DB インスタンス ○○○ の変更のリクエストが失敗しました。 と表示された。 ・テンプレートを、開発/テスト -> 無料利用枠に変更したい ・DBインスタンスタイプを、db.t3.micro -> db.t2.micro に変更したい 参考にしたサイト ? RDSを無料枠でマルチAZ化 ※※ インスタンスタイプのみ変更したい場合は、下記のリンクが一番手っ取り早いと思うので、 この作業が何らかのエラーで変更できなかった場合にこれからの順序を行ってください。 ※※ ? AWS EC2のインスタンスタイプ変更手順 1. 既存のRDSを削除、新たにRDSを作成 (1)既存のRDSを削除します ※※ こちらの手順1〜4まで ? RDS インスタンスの削除 ※※ (2)最終スナップショットはもしものために置いておきます ※※ 全て終了後削除 ※※ 削除・作成に時間がかかりそわそわしていたので、ポアロのクリスマスを読んでいました。 (3)新しくRDSを作成します ・変更点: ✔️ 開発/テスト -> 無料利用枠 ✔️ db.t3.micro -> db.t2.micro その他、みなさまの設定で作成してください。 作成中にダッシュボードの上部に詳細表示ボタンが現れるのでクリックし、 設定したマスターユーザー、マスターパスワードを保存しておきましょう。 (4)変更点をしっかり確認しておきます db.t3.micro -> db.t2.microのRDSが作成できましたね。 2. 新しいエンドポイントを設定します (1)RDS新規作成でエンドポイントが変更されたため、新しいエンドポイントを設定します (これまで使用していたエンドポイントはRDSを削除したため使用不可になります) (2)MySQLコマンドでMySQLをインストールします (3)Webサーバーにログインします ssh -i ~/認証キー保存ディレクトリ/認証キーの名前.pem ec2-user@Elastic IPアドレス 例) ssh -i ~/Desktop/ninsyo-key.pem ec2-user@44.44.44.44 (4)MySQLをインストールします [ec2-user@ip-○○○~ ]$ sudo yum install mysql (5)データーベースに接続する際にはデーターベースの接続先情報(エンドポイント)が 必要なのでエンドポイントをコピーしにいきます AWSダッシュボード -> RDS -> 左メニューのデータベース -> 作成したRDSをクリック -> 下タブのエンドポイントをコピー (6)コピーしたエンドポイントをターミナルに入力していきます [ec2-user@ip-○○○~ ]$ mysql -h コピーしたエンドポイント -u root(マスターユーザー名) -p (7)パスワード入力を求められるので、マスターパスワードを入力します(ペースト不可) (8)Welcome to the Maria DB monitor.と表示されれば、 Webサーバーからデータベースサーバーへ接続することができています! もしエラーが出てしまったら、 ①ユーザー名orパスワード入力ミスを疑う ②データーベースが利用可能になっていない(=MySQL未接続、 RDS -> データベースで確認、③セキュリティグループの設定ミス)を 確認してみてください。 ※※(9)Ctrl + cでMySQLログアウト、exitでSSHログアウトしますが、 3.(1)でまたすぐにログインするので省略可、その際は、3.の(2)からスタートです ※※ 3. WordPress用のデーターサーバを作成 ①データベース作成 (1)Webサーバーにsshでログインした上でMySQLコマンドでデータベースに接続します [ec2-user@ip-○○○~ ]$ ssh -i ~/Desktop/ninsyo-key.pem ec2-user@44.44.44.44 (2)MySQLコマンドでデータベースサーバーに接続し、パスワードを入力します [ec2-user@ip-○○○~ ]$ mysql -h コピーしたエンドポイント -u root(マスターユーザー名) -p (3)MySQLの中にデータベースを作成します MySQL [(none)]> CREATE DATABASE 作成したいデーターベース名 DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; Queri OK, 1 row affected, 2warnings (0.06sec) などと表示されたら作成できています。 各コマンドの説明は、こちらが分かりやすかったです。? よく使うMySQLコマンド集 (4)ちゃんと作成できているか確認します 作成したデータベース名が記載されていれば作成されています。 MySQL [(none)]> SHOW DATABASES; ②WordPress用のユーザーを作成します (1)ここでは、wordpress_userというユーザー名で作成していきます MySQL [(none)]> CREATE USER 'wordpress_user(作成したいユーザー名)'@'%' IDENTIFIED BY '接続時のパスワードをここで作成し、入力する'; Queri OK, 0 row affected(0.03sec) などと表示されたら作成できています。 (2)作成したユーザー(wordpress_user)にデータベースを操作できる権限を付与します これを行わないとWordPressユーザーが データーベース内でテーブルを参照したり、作成することが不可になってしまいます。 MySQL [(none)]> GRANT ALL ON wordpress_user.* TO 'wordpress_user'@'%'; (3)権限付与しただけなので、MySQLに設定を反映させます MySQL [(none)]> FLUSH PRIVILEGES; (4)ユーザー(wordpress_user)が作成されたか確認します MySQL [(none)]> SELECT user , host FROM mysql.user; ユーザーの一覧が表示され、作成したユーザー(wordpress_user)が 下記のように表示されていれば、どこからでも接続OKの設定が完了です。 (5)作成したユーザーでMySQLに接続できるか確認します 一旦ログアウトしてから再ログインし、MySQLに接続します MySQL [(none)]> exit Bye [ec2-user@ip-○○○~ ]$ mysql -h エンドポイント -u wordpress_user -p Enter password: Welcome to MariaDB monitor.. 4. WordPressを再インストール (1)Webサーバーにsshログインし、WordPressに必要なライブラリをインストールします [ec2-user@ip-○○○~ ]$ sudo amazon-linux-extras install -y php7.4 yumコマンドではなく、amazon-linux-extrasコマンドを使用します。 EC2のOSはAmazon Linux2ですが、extras libraryというパッケージ群が存在し、 その中にphpの最新版が存在し、使用することができます。 (2)php関連の必要なライブラリをyumからインストールします [ec2-user@ip-○○○~ ]$ sudo yum install -y php php-mbstring 先にphp7.4をインストールしておくと、7.4に対応したphp関連のライブラリを インストールしてくれるのでこの順番で行うようにしましょう。 (3)Webサーバーのホームディレクトリに移動します [ec2-user@ip-○○○~ ]$ cd ~ (4)WordPressの最新版をダウンロードします [ec2-user@ip-○○○~ ]$ wget https://ja.wordpress.org/latest-ja.tar.gz (5)インストールが完了したらファイルを確認します [ec2-user@ip-○○○~ ]$ ls latest-ja.tar.gz (6)解凍します [ec2-user@ip-○○○~ ]$ tar xzvf latest-ja.tar.gz (7)解凍が完了したら、ファイルの中身を確認します 下記のようにwordpressと表示されていれば、ディレクトリが作成されています。 [ec2-user@ip-○○○~ ]$ ls latest-ja.tar.gz wordpress ※※ ソースとディレクトリは不要だぜという方は、以下で削除してください。 ※※ [ec2-user@ip-○○○~ ]$ rm -r latest-ja.tar.gz wordpress (8)WordPressのディレクトリに移動します [ec2-user@ip-○○○~ ]$ cd wordpress/ (9)WordPressのプログラムをApacheから見える場所に移動させます [ec2-user@ip-○○○~ ]$ sudo cp -r * /var/www/html/ (10)コピーが完了したら、WordPressのファイルの所有者(グループ)を変更します [ec2-user@ip-○○○~ ]$ sudo chown apache:apache /var/www/html/ -R これでApacheからWordPressのファイルを参照できるようになりました。 (11)(10)の設定を反映させるためにApacheを再起動します ①Apacheの起動状態を確認します [ec2-user@ip-○○○~ ]$ sudo systemctl status httpd.service Active: active(running) since 土 2021-06-12... 起動していなかったら、 sudo systemctl start httpd.service を実行してください ②Apacheを再起動します [ec2-user@ip-○○○~ ]$ sudo systemctl restart httpd.service (12)起動状態の確認を行うため、①のコマンドを再実行し、①と同じように Active: active(running) since .. と表示されればWordPressの再インストールは完了です。 5. データベースと接続するための設定 (1)WordPressサイトに移動すると、 本来の初期設定画面が表示されずデータベース接続確率エラーが表示されます と表示されるので、 ・データベース名 ・ユーザー名 ・パスワード ・データベースのホスト名(エンドポイント) をwp-config.phpに直接書き込んでいきます。 上記を登録すると、wp-config.phpファイルが/var/www/html/配下に作成されます。 WordPressはそのファイルに記載されている内容を読み込んでデータベースと接続します。 (2)wp-config.phpファイルを編集しにいきます ターミナルにてsshログインし、/var/www/html/に移動、wp-config.phpを開きます [ec2-user@ip-○○○~ ]$ cd /var/www/html/ [ec2-user@ip-○○○~ ]$ nano wp-config.php ※※ 今回はvimではなく、nanoで作業しました。 ※※ (3)以下のdefineにMySQLの設定を書き込みます(移動したてはデフォルトの値です) define( 'DB_USER', 'データベースのユーザーネーム(ここではwordpress_user)'); define( 'DB_PASSWORD', 'データベースのパスワード'); define( 'DB_HOST', 'MySQLのホスト名(エンドポイント)'); define( 'DB_CHARSET', 'utf8mb4'); (4)Ctrl + s、Ctrl+xで保存、終了します (5)一応exitでログアウトします (6)WordPressをリロードすると初期設定画面が表示されるので、 サイト名:前と同じでなくてOK ユーザー名:前と同じ(一応) パスワード:前と同じ(一応) 一応としたのは、Chrome側でパスワードが保存されていたためと、 鬼が出るか蛇が出るか、緊張して前と同じにしたら同じように使えるかもと思ったからです。 (7)接続完了です!!!!ここまでおつかれさまでした!!!! 無事、同じドメイン名のWordPressへアクセスできるようになりました。 手動で取得したスナップショットは必ず削除してくださいね。お金かかっちゃいます。 前回(削除した)のRDSでインストールしたWordPressのテーマやプラグインも残っています。 WP mail SMTPやアンチスパムはもう一度設定し直したり、画像はS3 -> CloudFrontに再設定 したりする必要はありますが、きちんと使えるようになっているはずです。 あとがき かなりの長文になってしまいました。読み辛い点や設定の二度手間もあるかと思います。 失敗したらどうしようかと頭掻き毟るくらい悩んでいたので解決できて本当に安堵しました。 手順はノートに記載していたので、接続情報を変更する際にwp-config.phpファイルを 直接編集することを思い出せました。デジタルもアナログも思い切りも大事ですよね。 ゲームだと「さいしょから」の選択、パソコンだと初期化ができますが、 やはりサーバとなるとそんな簡単にはいきません。白紙にしたいと何度も思いました。 ハードなつづきからをやり終えた気分です(ロックマンエグゼ2でお願いします)。 補足 この記事は2021/06/25時点に実行したものであり、RDSを削除 -> 作成のみだったため、 削除したRDSでインストールしたWordPressのテーマやプラグインも残っておりました。 2021/07/26に、2回目としてCyberDuckでWordPressのディレクトリごと削除したあと、 もう一度この手順を踏んだのですが、インストール済みプラグインとテーマは残っており、 記事のみが初期化、S3 -> Cloud Front、プラグイン有効化の設定を行う状態でした。 2回目の理由はphpMyAdminで躓いてしまったからです。すっきり1からやり直したかったので RDSを削除する際のスナップショットは不要と判断し、作成していません。 1回目より時間はかかりませんでしたが悩んでいた3日間はずっと手汗まみれでした。 勉強を重ね、リベンジしようと思います。 ここまでお読みいただき、ありがとうございました。 ご指摘等ございましたらご教示くださると幸甚です。 参考 ・.htacess設定について ? Amazon Linux 2 で LAMP をインストールして WordPress 環境を構築する。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

オンプレサーバをaws SystemManagerで管理する

オンプレのサーバをCloudWatchでもりもり監視していると台数が増えてきますね? 1000台とかになったときにメトリクスを調整するのに設定変更を1台1台やるのはつらいじゃないすか。 そんなあなたのためにawsのSystemManagerのノード管理→Run Commandっていうので、awsコンソールから一斉にコマンドをなげることができます。 すでにパラメータストアにcloudwatch-agentの設定ファイルを保存してあるのでSSMエージェントをインストールしてSystemManagerのハイブリッドアクティベーションで登録するだけです。 tl;dr オンプレのサーバにSSMマネージャを入れて、ハイブリッドアクティベーションをして、CloudWatchAgentの設定ファイルを更新します。fedora33で試しています。 SSMマネージャインストールと登録 下記のまんまでした。 直接URLからインストールします。 [root@deroris ~]# dnf install https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/linux_amd64/amazon-ssm-agent.rpm 一度止めます。 [root@deroris ~]# systemctl stop amazon-ssm-agent awsコンソールのノード管理→ハイブリッドアクティベーションからアクティベーションを登録します。 何も入れなかった。 作成すると上にActivation CodeとActivation IDが出てくる。 それをサーバで流す。一回やってるのでexistって言われてる。 [root@deroris ~]# amazon-ssm-agent -register -code "Dn1mldF8fahPooTKLd5C" -id "88f4a5bc-a7d2-4e95-9cde-3a692dd3b420" -region "ap-northeast-1" Error occurred fetching the seelog config file path: open /etc/amazon/ssm/seelog.xml: no such file or directory Initializing new seelog logger New Seelog Logger Creation Complete Instance already registered. Would you like to override existing with new registration information? [Yes/No]: Y 2021-07-29 19:02:09 INFO Successfully registered the instance with AWS SSM using Managed instance-id: mi-0d10b19839841c0ab 数秒で登録済みインスタンスが1になる。 サービスを開始してステータスを確認すべし。サービス開始するの忘れるので注意。 [root@deroris ~]# systemctl start amazon-ssm-agent [root@deroris ~]# systemctl status amazon-ssm-agent ● amazon-ssm-agent.service - amazon-ssm-agent Loaded: loaded (/etc/systemd/system/amazon-ssm-agent.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2021-07-29 19:03:51 JST; 2s ago Main PID: 1793358 (amazon-ssm-agen) Tasks: 21 (limit: 19076) Memory: 19.7M CPU: 165ms CGroup: /system.slice/amazon-ssm-agent.service ├─1793358 /usr/bin/amazon-ssm-agent └─1793389 /usr/bin/ssm-agent-worker 7月 29 19:03:52 deroris.local amazon-ssm-agent[1793358]: 2021-07-29 19:03:51 INFO no_proxy: 7月 29 19:03:52 deroris.local amazon-ssm-agent[1793358]: 2021-07-29 19:03:51 INFO Agent will take identity from OnPrem 7月 29 19:03:52 deroris.local amazon-ssm-agent[1793358]: 2021-07-29 19:03:51 INFO [amazon-ssm-agent] using named pipe channel for IPC ちゃんと動いていればフリートマネージャに表示される。 これでawsの配下に。 リモートからコマンドを流す CloudWatchAgentを更新してみます。 パラメータストアのメトリクスを編集します。namespaceにNew2を入れました。(画像はまだNew) ノード管理→Run CommandでAmazonCloudWatch-ManageAgentを選択します。 コマンドパラメータで画像のように入力します。 ModeをonPrem、Optional Configuration Locationにパラメータストアの設定名を入れます。 ターゲットに当該のノードを選択します。(ここに表示されていなければSSMの登録がうまくいってない) コマンド出力をS3に保存したりできる。 んで実行 うまくいってればすぐに成功って表示されてくると思います。 あとは、CloudWatchで更新した項目(Namespace)が反映されているかみてみてください。 まとめ サーバをセットアップするときはSSMエージェントを設定しておけばあとから楽になる。 オンプレやvps等のサーバがいっぱいある人にとっては便利かも。 問題なのは、そこまでAWSにロックインされていいのかってことか。 エージェント系なので、ポートを開けたりする必要はないからそのへんは楽かな。 ※↑で使ったアクティベーションコード等はすでに捨てた。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

TagTamerでタグ管理してみる

はじめに 6/30にawsの新しいソリューションとしてTagTamerが公開されました。 Tag Tamer は、新規および既存の AWS リソースにタグを適用するのに役立ちます。構築済みのウェブユーザーインターフェイスを使用することで一貫したタグ付けの実装を保証し、コスト配分、自動化、アクセスコントロール、編成を改善します。 説明文を読む限り、タグ管理を楽に行えるようになるソリューションのようです。 ちょうどタグ管理に悩んでいたので、実装・検証してみて思い通りの使い方ができるのか試してみます。 機能 上記紹介ページより、以下の機能があるようです。 タグのスペルミスや大文字と小文字の誤りを見つけて修正、防止 タグ付けルールを適用 間違ったタグを見つけて更新 タグなしのリソースを見つける AWS リソースとそれに割り当てられたタグのレポートをエクスポート AWS Service Catalog の TagOptions を管理 構築済みのウェブユーザーインターフェースを起動して、AWS アカウントとサービス全体でタグを管理 既存の AWS リソースタグを調べ、タグを変更し、再利用可能なタグオプションを作成 タグのキーと値のペアを一元化された安全なリポジトリに保存 間違ったタグを見つけて置き換え、タグのないリソースを見つける 新しい AWS リソースにタグを自動的に適用 ワークフローを開始して、組織に必要なタグを適用 AWS Service Catalog から新製品をリリースするときに、承認されたタグを選択して適用 料金概算 こちらにコストの一例が載っています。 Publicだと月約$95するらしいです。タグ管理ツールと考えると少し高いような気もしますね。 実装方法 CloudFormationのテンプレートを突っ込むだけかと思いきや、準備が必要なようです。 非常に分かりやすい記事があったので、本稿では構築方法は省きます。 構築後の画面 Multiリージョン対応 現在のままではus-east-1にあるリソースしか検知できていないので、公式ドキュメントを参考に対応リージョンにap-northeast-1を追加したいと思います。 マネコンのEC2画面から、TagTamerのアプリが動いているインスタンスを選択、「アクション - 接続」を押下します。 「セッションマネージャー」タブに移動し、接続を押下します。 /home/ec2-user/tag-tamer/tag_tamer_parameters.jsonを書き換えます。 > sudo vim /home/ec2-user/tag-tamer/tag_tamer_parameters.json "additional_regions"に"ap-northeast-1"を追加 tag_tamer_parameters.json "additional_regions": ["ap-northeast-1"], restartします。 > sudo systemctl restart tag-tamer TagTamerにアクセスしてみると、東京リージョンが追加されています。 やりたいこと タグが付いていないリソースを一覧表示 「See your existing AWS resources & their tags」を押下します。 リソースタイプを選択後、keyに「 No tags applied 」を選択し、検索すると、タグが全くついていないリソースが表示されます。 ただ、これだと「まったくタグが付いていないリソース」しか取れないようです。「特定のタグが付いていないリソース」を表示したい場合はAWS Configの機能を利用して頑張るしかないのかな?と思います。 リソース作成時に作成者名タグを自動付与 TagTamerではできないようでした。 特定のロールがアタッチされているリソースにタグ付与などはできるようなのですが。 やるとしたらConfigで検知→通知→手動アタッチかLambdaで頑張るかですかね。 Key・Value値のタイポを検知して修正 Key・Value値が間違っていた場合に修正できたらうれしいですが、こちらもTagTamerのみではできなさそうです。 まとめ Tag管理はAWSアカウントを運用する上で頭を悩ませる点の一つだと思うので、こういったTag管理ツールが増えると良いなぁと思います。 TagTamerに関しては、運用料金がTag管理のみにしては高いと感じてしまうのと、少し手が届かない部分があるなという印象でした。 ただ、一度デプロイしてみて現状を把握したい場合には一覧表示できていいかもしれません。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PHP-JWTで発生した Cannot handle token prior to [time stamp] エラーの解決

事象 Laravel + PHP-JWT + CognitoでユーザーをJWT検証で認証するWebアプリにて、 ある日突然ローカルでのみJWT検証でエラーが発生する事象が発生しました。 環境 Laravel 6 + nginx + AWS Cognito Jwt検証用ライブラリ: Firebase/PHP-JWT (https://github.com/firebase/php-jwt) エラー内容 Firebase\JWT\BeforeValidException: Cannot handle token prior to [time stamp] (Google訳: [タイムスタンプ]より前のトークンを処理できません) 原因 JWTを発行するサーバー(Cognito)と検証側サーバー(ローカルサーバ)側で時刻が一致しない場合に起きるようです(下記Github issue参照)。 対処法 $leeway変数を再定義してサーバー時刻ずれを秒単位で許容することで回避できるそうです(defalutは0)。 ドキュメントによると数分以上の設定は非推奨とのことです。公式のサンプルでは1分に設定されていますが、今回は5秒に設定しました。 再発した場合はさらに許容時間を増やそうと思います。 use Firebase\JWT\JWT; class JWTSampleClass { public static $leeway = 5; //5秒の時刻ズレの誤差を許容 // } 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

RDSのスキーマがいじれなくて困った話

AWSでAuroraのデータベースを構築しました。 スキーマの設計をいじろうとコマンドを実行してみる。 (あ、qiita超初心者でしたがコードの挿入ができるようになりました!ヤッター) qiita.rb REVOKE ALL ON schema public FROM public; そして出てくるエラーがこれ。 qiita.rb ERROR: cannot execute REVOKE in a read-only transaction 多分だけど『このトランザクションは読み取り専用だからREVOKEってコマンドは実行できない』 みたいなことを言っている。気がする。 困っていたら同期の子が解決法を教えてくれました! postgresにアクセスするときに使うこのコマンドにトリックがあったらしい。 qiita.rb psql -h <エンドポイント> -U <ユーザー名> -d postgres ここの!<エンドポイント>! AWSでデータベース作成したときにエンドポイントが2つあったんですね。 で、いつもはそれのリーダーインスタンスを使ってたんですね。(写真上。roが付いてる) だけど書き込みがしたいからライターインスタンスを使ってみたらできたっていうもんですから私も試してみました! そしたらなんと書き込みができました! qiita.rb postgres=> REVOKE ALL ON schema public FROM public; REVOKE REVOKE・・・なんか好きな英語になりました
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

SSH設定が原因でFilezillaでSFTP接続ができない。

久々のQiita記事投稿です。 最近AWSの書籍1でネットワークの基礎を勉強しつつAWSのサービスを触っています。 AWS自体というわけではなく、SSH設定周りでつまづきました。 環境 macOS 11.5 FilezillaのSSH設定 サーバー(EC2インスタンス)へSFTPで接続する際のSSHの設定。事前にFilezillaの設定>SFTPで秘密鍵(my-key.pem)を指定しておきます。そしていざ接続を試みますが、エラーがでて接続できない。 エラー: FATAL ERROR: No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic) エラー: サーバーに接続できません 原因 秘密鍵の指定パスに日本語が入っていたため。 後書き Filezillaは仕事でもサーバーのファイル操作関連で使用していましたが、そもそもの基礎部分を知らずにつかっていたなぁと実感しました。 本書1ではそもそものSSHやポート、IPアドレスなどのネットワークの基礎知識が初心者でも理解できるよう丁寧に説明されており、なかなか楽しみながら進められています。 Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂3版 Kindle版 ↩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

未経験エンジニアが2ヶ月でSAAに合格するまで

自己紹介 ・2021年5月からAWSの学習を始めた29歳男 ・現職はITと異業種の一般事務 ・学習開始まではエンジニアとして全くの素人、経験無し ・プログラミングスクールに入り4月から7月まで受講。一月だけRuby/Ruby on Railsを学習。 SAA取得に費やした時間:約90時間 上記の通り全くの未経験。5月の学習開始から2ヶ月かけてSAA(ソリューションアーキテクトアソシエイト)を取得しました。 今回は学習記録の意味も含め、どなたかの参考になればと思い記録に残させていただきます。 ※SAAの試験の詳細、技術内容、試験予約の方法等は当記事では割愛させていただきます。 行った学習方法 ・スクールの課題をこなす ・Cloud Practitionerの取得 ・ハンズオン ・ホワイトペーパーを読む ・ブログ記事を読む ・試験対策書籍を読む ・AWS公式の模擬試験の受験 一つずつ詳しく書いていきます。 スクールの課題をこなす 通っているプログラミングスクールで5月からAWSの学習を開始しました。 取り組んだ課題の中で扱ったAWSのサービスとしては ・VPC ・EC2 ・RDS ・ELB ・S3 ・CloudFormation ・IAM ・CloudWatch です。 4月から一月だけRuby on Railsを学び、簡単なCRUD処理を実装したアプリを上記のサービスを使い AWSへデプロイしていました。 下記のハンズオンの項でもそうですが、実際に手を動かすというのはとても重要です。 Cloud Practitionerの取得 入門用資格であるAWS Cloud Practitionerを取得。 元々はさっさとSAAに挑もうと考えていましたが、思い直すことにしました。 理由は、 ・学習のモチベーションを保つ ・AWSの全体像が分からないと各サービスの深掘りが出来ないと感じた です。 そもそもSAAを受験した理由として、 完全未経験ということもあり、とにかく分かりやすい成果が欲しかったというのが大きいです。 AWSの学習を始めて直ぐの頃、SAAの模擬問題を見たのですが、問題の意味すら全く分からず頭が真っ白に。 合格の見通しが立ちそうに無く、 このままでは試験に対してのモチベーションは長く続かないだろうと考えたのです。 そこでCloudPractitionerの模擬問題を見てみると、 SAAに比べ各サービスの表層を捉えることにフォーカスされており、AWSの全体像を捉えるのに適していると感じました。 学習開始2週間でも理解出来る問題が多かったので、まずはこちらを取得して学習のモチベーションを上げていこうと考えました。 (それに、試験に合格すると次の資格受験費用が半額になったり、各種模擬試験の受験料¥2,000が一回無料だったりしてお得なんです!) スクールの課題をこなしつつ6月初旬に合格。 資格取得を通して、各サービスの名前、役割や、クラウドにおけるベストプラクティス等が何となく理解出来る様になりました。 SAA主体の記事なので学習方法の詳細は割愛しますが、 こちらの公式の学習資料が無料かつとても分かりやすいのでオススメです。 ハンズオン CloudPractitioner合格後、再度SAAの問題に挑戦。 正答率は低いまでも、問題文の意味が何となくわかる様になっていて、成長した実感が湧きました。 ここから少しサービスの深掘りをする為にAWS公式の無料ハンズオンや、Udemyのハンズオンにトライ。 内容はスクール課題のものとそこまで変わりありませんでしたが、ほぼ自力で実装していたので、 解説を聴きながら手を動かすことは復習という意味でとても良かったです。 スクールに通っていない方は、こういったハンズオンを経験するだけでも、書籍のみの学習よりも より知識が身に付くはずです。 (書籍のみで合格は可能だと思いますが、特に私の様な初学者の方はある程度サービスを扱えないと資格の意味が無いと個人的には思います。) ホワイトペーパーを読む ホワイトペーパーとはAWSの公式ドキュメントです。 よくあるFAQや、サービスごとの詳細、具体的な使用例等が記載されています。 大体のページは日本語訳がありますが、ドキュメントによっては正直あまり翻訳精度が良く無いことがあります。 私はPCで学習をしていましたが、DeepLという翻訳サービスを利用し、英文のドキュメントをこの サービスで翻訳し、学習していました。Google TranslateやAWSの翻訳よりも自然な文体で 翻訳してくれるのでお勧めです。 ブログ記事を読む ホワイトペーパーでの学習と同時進行で行ったのがブログ記事の閲覧です。 株式会社クラスメソッドさんや、NTT東日本さんの記事を中心に読みました。 クラスメソッドさんはDeveloppersIOというブログサイトを経営されているのですが、各社員さんが 業務で触れたAWSサービスの事柄を学習のアウトプットという名目で執筆されていて、大量の記事があります。 初学者にとってはハードルの高い記事もありますが、中には初学者にも易しいハンズオンの記事等も ありますので参考になりました。 NTT東日本さんの方はAWSホワイトペーパーの内容を要点を抑え、サービスごとに分かり易く纏めた記事が多い印象でした。 ホワイトペーパーで分かりにくい箇所はこの2社の記事と見比べながら理解を進めるといった感じで利用していました。 試験対策書籍を読む 試験の1ヶ月前に試験対策の書籍を一冊のみ購入しました。 この書籍は一夜漬けとある様に、テストに出やすいサービス、内容等を項目ごとに纏めた内容になっています。 試験対策書籍には珍しく、練習問題よりもサービスの細かな解説に特価した内容でした。 ただ、重要部分のみを抽出して記載しているので、体系的に学ぶという意味ではこの書籍のみでは 不足するかと思います。 もう一つ大きな特徴が、LINEを使った練習問題の配信サービスです。 書籍内のQRコードを読み取り友達登録すると、著者の方が毎朝1問ずつ問題を配信してくれます。 Noteを見ると自分が登録するより前の問題も纏められているので、多くの問題に取り掛かることができます。 問題文もSAA試験の問題形式と同じ様な内容で、かつ解答の解説も記述されており、大変有意義なサービスでした。 AWS公式の模擬試験の受験 本試験の1週間程前にAWS公式の模擬試験を受験しました。 20問30分という形式でしたが、正答率は55%とかなり低い結果になり正直めちゃくちゃ焦りました。 試験までにハンズオンで学ぶ時間があまり取れないということもあり、再度ホワイトペーパー、ブログ記事の読書でサービス内容の復習をしました。 本試験 模擬試験でもそうですが、問題文が長いです。流し読みでは選択肢を絞ることが困難なので 語句の見落としに気を付けながら、じっくり読みましょう。 試験時間は140分。 私は1周するのに60分、見直しに30分使用し、計90分で試験終了しました。 (後々いくつか誤答に気づくことが多いので、見直しめっちゃ大事です。) 模擬試験に比べると解きやすい問題もいくつかある様に思えたので、模擬試験のスコアが悪くても取り敢えず受けてみることをお勧めします。 まとめ SAA取得までの流れとして CloudPractitionerの取得でAWSサービスの全体を捉える ↓ ハンズオン、書籍での学習で各サービスを深掘り ↓ 模擬試験を受ける ↓ 弱点を中心に再度書籍で復習 ↓ 合格 という感じです。 先にCloudPractitionerを取得したのは、個人的に大きかったです。 バラバラだった知識を体系付けることが出来ましたし、 知識の土台が出来たことによりハンズオン、ホワイトペーパーでの学習の効果がより上がった実感がありました。 上でも述べましたが「取り敢えずCloudPractitionerは取れたぞ!」という自信も各学習の継続に大きく貢献したと思います。 今現在はスクールの単元も終え、転職活動を行っていますが、 資格取得に満足することなく、今後は現場に出てSAA取得で得た知識を業務で挑戦し、生かしていきたいです。 qiita初投稿で、お見苦しいところもあるかとは思いますが、本記事がどなたかの参考になればとても嬉しく思います。 最後までお付き合いいただきありがとうございました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon EC2を利用した仮想サーバー構築方法①(インスタンス作成編)

AWS初学者です。 前回は、Amazon VPCを利用して仮想ネットワークを作成しました。 (その記事はこちら) 構築した仮想ネットワークをもとに、今回はAmazon EC2(以下EC2と略称)を利用した仮想サーバーの構築方法をいくつかの記事に分けてまとめたいと思います。 まずはEC2を用いて、インスタンスの作成を行います。 ・インスタンス...Amazon EC2で作成した仮想サーバーのこと。 インスタンスの作成 検索バーから「EC2」と検索して、EC2の画面へ移動します。以下の画像のような画面が表示されます(画面右上のリージョンが「東京」になっているかも確認してください)。 [手順1] インスタンスを起動する際に用いるイメージファイル(Amazon Machine Image、通称AMI)を選択します。 AMI(Amazon Machine Image)とは、インスタンスの起動に必要なOSやボリューム、アプリケーションなどを含むテンプレートです。インスタンスを起動する時AMIを必ず指定する必要があります。 参考記事: 「初心者向け」EC2のインスタンスからAMIを作成し、新しいインスタンスを起動してみましょう 「ボリューム」とは、「コンピューターに接続している外部記憶装置を管理するときの単位」のことだそうです。 例えば、コンピューターにDVDを入れたり、コンピューターにハードディスクを繋いだ場合、その「DVD」や「ハードディスク」といった外部記憶装置一つ一つを「ボリューム」と呼びます。 このAMIを選択するには、左のメニューから「インスタンス」をクリックし、画面右上の「インスタンスを起動」をクリックします。 次に、AMIを選択します。 今回は無料枠対象である「Amazon Linux 2 AMI」の「選択」をクリックします。 [手順2]次に、インスタンスタイプを設定します。インスタンスタイプとは、仮想マシンのスペック(CPU、ストレージ、メモリ、ネットワークキャパシティーなどの組み合わせ)のことです。 今回は無料枠対象の「t2.micro」にチェックを入れ、「次のステップ: インスタンスの詳細の設定」をクリックします。 [手順3] 以下のような、インスタンスの詳細情報の設定を行います。 ・ネットワーク: 前回構築したVPC領域を選択(VPC領域の構築についてはこちらの記事を参考) ・サブネット: 前回作成したサブネットを選択(サブネットについてもこちらの記事を参考) ・自動割り当てパブリック: 「有効」を選択 → インターネットからこのインスタンスにアクセスできるように、パブリックIPアドレスを付与する設定。 ・ネットワークインターフェイス: 「プライマリ IP」の欄に「10.0.1.10」と入力。 → 前回、パブリックサブネットは「10.0.1.0/24」と定義しているので、「10.0.1.0 ~ 10.0.1.255」のいずれかのIPアドレスを設定することができる。 ここまでの設定が終わったら「次のステップ: ストレージの追加」をクリックします。 [手順4] ストレージを設定する インスタンスで利用する仮想ハードディスク(Elastic Block Store、略称EBS)を設定します。 今回はカスタマイズせず、最初からフォームに入っている設定のままで「次のステップ: タグの追加」をクリックします。 (今回の場合、8Gバイトの仮想ハードディスクが作成されます) [手順5] 「別のタグを追加」をクリックし、インスタンスに名前をつけます。 今回は「Name」というキーで「Webサーバー」という名前をつけます。 完了したら、「次のステップ: セキュリティグループの設定」をクリックします。 [手順6] インスタンスに対して「セキュリティグループ」を設定します。 セキュリティグループとは、インスタンスにセキュリティを設定する機能のことです。 今回はセキュリティグループ名を「WEB-SG」と書き換え、その他の設定はそのままで「確認と作成」をクリックします。 [手順7] ここまでの設定内容を確認し、「起動」をクリックします。 [手順8] モーダルが表示されるので、「キーペア」を作成します。 キーペアは、作成したインスタンスにログインするために必要な「鍵」のような役割を果たします。これがないとインスタンスにログインできません。 新しいキーペアを作成するために、一番上のプルダウンから「新しいキーペアの作成」を選択します。 キーペア名の欄には、任意の名前を入力します。 その後、必ず「キーペアのダウンロード」をクリックし、「キーペア名.pem」というファイルをダウンロードします。 このファイルは後でダウンロードすることができず、紛失してしまうとインスタンスにログインできなくなってしまいます。 必ずダウンロードし、大切に保管してください。 キーペアのダウンロードが完了したら、「インスタンスの作成」をクリックします。 すると「インスタンスを作成中」というメッセージが表示されます。画面右下の「インスタンスの表示」をクリックすると、インスタンス一覧画面を表示できます。 以下のようにインスタンスが作成され、「インスタンスの状態」という項目が「実行中」になっていれば成功です。 以上で、インスタンスの作成は完了です。 この後は、「SSH接続」「ファイアウォールによる接続制限」を行っていく予定ですが、長くなりそうなので、 この記事では「EC2を利用したインスタンスの作成」までの内容とします。 ここまで読んでいただきありがとうございました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Level Up Amazon DynamoDB 参加レポート

今回は2021年6月3日にAmazonさん主催で実施された「Level Up Amazon DynamoDB - オンラインで学ぶAmazon DynamoDBのベストプラクティス」の参加レポートを上げようと思います。 資料はおそらく参加された方だけに公開されているものなので、自分が話を聞いていて気になったところのメモ書きになります。 前半パートは主にDynamoDBの歴史や実際の設計部分について、 後半パートはDynamoDBを実運用する上での情報といった感じのパート分けになってました。 前半パート 設計思想 AmazonにおけるYou build it, You run it.(あなたが書いたものはあなたが運用しなさい)の原則 → 運用を限りなく簡単にする セキュリティ (パッチ適用や暗号化 etc) 耐久性 (サーバ・ラックの維持やバックアップ・リストア etc) 可用性 (モニタリングやクロスリージョンレプリケーション etc) 性能 (パフォーマンスチューニング・インデックス etc) 拡張性 (キャパシティプランニング etc) などから解放されることで、より柔軟なシステム設計が可能に。 前者3つのセキュリティ・耐久性・可用性は従来のRDBのマネージドサービスであるRDSでもある程度実現可能でしたが、DynamoDBはそこに加えて後者の横の拡張性がかなり柔軟になっており、拡張しても性能の劣化が起こりにくい構成になっているなと感じました。 歴史 2004/12:Amazon.com の拡大に伴うデータベースの拡張性に関する課題 RDBの限界・・・ データベースを縦ではなく横にスケールしたい クエリの70%は非常に簡単なKey Valueなので別のアーキテクチャを検討→NoSQL 2007/10:Dynamoペーパーの公開 https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf この段階では実装寄りではなく、学術論文に近い段階 2012/01:DynamoDBの一般提供開始 現在:Amazonのほとんどを駆動するTier0サービス DynamoDBがもう9年も前から一般提供されていることに驚きました。 データベースとして運用されるNoSQLとしてはMongoDB等の名前を以前から聞いたことはありましたが、DynamoDBに関してはここ数年、サーバレスとマイクロサービスの文脈で目にする機会が加速度的に増えたように思います。 高いリクエスト量と低いレイテンシー 参考 https://aws.amazon.com/jp/blogs/news/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/ 左図のオレンジ:プロビジョニングされたキャパシティユニット(オートスケーリング) 左図の青:実際のアクセス量の推移 右図の青:同じ時間軸での実際のDBのレイテンシーが何msかの推移 通常のDBであれば負荷がかかるほど遅くなるが、DynamoDBは負荷が高くなるとレイテンシーが減る4ms→2.5msまで減る。 (アクセス数が増えたことで、キャッシュの使用量が上がる or コネクションが維持されやすくオーバーヘッドが減ったなどの理由が考えられるとのこと) DynamoDBは負荷がかかっても、上記のようにレイテンシーがむしろ減るような事例が実際のデータにて確認されており、普段RDBの負荷増大に悩まされている身からしては非常に驚きました。 DynamoDBのTable構造 partition key・sort key・dataに分類される dataはschema lessなので、どんなデータでも持てる グローバルセカンダリインデックス(GSI) 異なるパーティションまたはソートキーを使用できる インデックスはすべてのパーティションキーにまたがる 複合インデックスに複合ソートキーを使用する スキーマ内のデータ型を変えたい場合は以下のようなやり方がある 一気に読み込んで一気に処理する 都度古いアイテムを読み込んだ際に判定して1個ずつ書き換える 完全に別の値として追加する(例:created_at → new_created_at) など 読み取りオペレーション 以下の3種の読み取り方法がある。 GetItem プライマリーのキーで持ってくる 正確に0 or 1個を返す Query パーティションキーの正確な値とソートキー条件を指定 0個以上のコレクションを返す Scan 非キー属性のフィルタ条件 テーブルのすべての項目を読み取る 並列化されてるから時間はそこまでかからないかも知れないが、RCUの消費はかなり気になるところ。 なので、可能な限りフルスキャンを実行しないようにするため、グローバルセカンダリインデックス等を用いて必要なデータのみを持ってこられるようにする必要がある。 自分がDynamoDBについての初学者であまりピンとこなかったので、追加で調べた時のAmazon公式の資料を添付しておきます。 後半パート キャパシティモード 2種類のキャパシティモードを選択可能 Provisioned Capacity 階段状に増減する方式で、予め最大消費量の枠を確保してその範囲でやりくりする スケーリングは随時可能。オートスケーリングも設定可能 オンデマンド 使った分のみ課金されるシステム ただし、一定量を超えた際の費用はお高め 参考 https://dev.classmethod.jp/articles/reinvent2018-compare-dynamodb-on-demand-price-with-provisioned-price/ 社内ツールなど、ほぼアクセスされないようなシステムであればオンデマンド、常に一定程度のキャパシティが使用されるシステムであればProvisionedが良い。 キャパシティユニットを消費しきってしまうとスロットリングが発生してエラーを返してしまうので、オートスケーリングの設定等をしましょう。 キャパシティユニット RCU(リードキャパシティユニット)とWCU(ライトキャパシティユニット)の2種類が存在。 画像データをバイナリ化して保存するなど、巨大なデータを書き込むと1回の読み書きでで複数のキャパシティユニットを消費するので注意しましょう。 レプリケーション 3つのAZに書き込み、3つのAZで実行 レプリケーションしたあとのGetItemの整合性は比較的とれていて、レプリケーション前のものが読み込まれることは少ない グローバルセカンダリインデックスと結果整合性 スループットの管理 書き込みキャパシティーユニット 読み込みキャパシティーユニット 書き込み・読み込みユニットのAutoScalingもある コスト削減 Attribute名は短くした方がいい DynamoDBは各レコードにKeyとValueを持つため Keyの長さのデータ容量も何十万何百万アイテムも同じものを持つなるとコストになる Attribute名を短くすることにより、1レコードあたりのデータ量が1WCU内に収まると、書き込み時にもコスト削減の意味が出てくる 今まで多少冗長でもわかりやすいテーブル・カラム名を名付ける方針で実装してきたので、データ量を抑えるためにAttribute名の長さを削減するという発想はなかったので驚きました。 バックアップ オンデマンドバックアップで継続的バックアップ ポイントタイムリカバリ 競合はLast Write Win(最後の書き込みが有効) セキュリティ IAM・VPCによる制御 KMSによる暗号化 CroudTrail等による証跡の管理 NoSQL Workbench GUIツール データモデルのサンプルも色々(ブックマークサービスや音楽配信サービスなど) 手動操作でインデックスを作ったり、ビジュアライザしたりできる Commit to DynamoDBで実際のDBに書き込むことも可能 実際にデータベースを作ったり、中身を見たりをGUIベースで行えるので、学習の補助として非常によさそう。 また、サンプルのデータモデルが何パターンもあるので、設計の参考にもなりそうです。 まとめ RDBからNoSQLにすることで、かなり設計の方針が変わってくる データの階層化、読み込み方、インデックスの作り方、Attribute名を短くするなど 冪等性、結果整合性には注意 巨大なDynamoDBのマスターDBを持つのか、各マイクロサービスのバックエンドとして細かく分散したテーブルごとのDBを持つのかなど、設計の方針はどちらもメリット・デメリットがありそう 同じDBに全部突っ込んでもデータ型が柔軟なので、インデックスの作り方によってはそれでも機能しそうです 今までは1つのRDSに全てのテーブル構造と関連を持つのが当たり前だったので、そもそもDBを分割するという発想自体ができるようになったのが大きなパラダイムシフトだと思いました DynamoDBへのレコードの追加をトリガーにLambdaを起動するみたいな使い方もあるので、今後は複数DB前提の設計についても調べてみたいです
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

コンテナの中で操作できちゃうECS Execの使い方

はじめに Fargateを使って、コンテナの中から色々操作したい(特に開発環境)時に使えるのがECS Execです。 入れたらめっちゃ便利になったので備忘録的に残しておきます。 結論 これ読んでください。すごくわかりやすく書いてあります。 [アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました ただ、ちょっとだけつまったところをメモしておきます。 AWS CLIを最新バージョンにしておく(ECS Execのコマンドが入ってるバージョンであれば良いです) ECS TaskExecRoleじゃなくてTaskRoleにポリシー付与(なんかごっちゃになったので) aws ecs update-serviceを使うときは、自分のconfigのリージョンが東京の可能性あるので、--region ap-northeast-3っていうオプションつける(これはこれに限った話じゃないですが、デフォルトのコンフィグと違うリージョンで使う場合にはリージョンの指定が必要です) コマンドはbin/shじゃなくてshだけ(これは多分dockerイメージ的にそうしないといけないだけだと思うからイメージによりそう) session-manager-pluginっていうのをローカルにインストール必要 最終的なコマンドは aws ecs execute-command \ --cluster cluster-name \ --task task-name \ --container container-name \ --interactive \ --command "sh" \ --region region-name これでコンテナの中で操作できると思います! まとめ めっちゃ便利
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Perspective を試してみる

作成を試してみる AWS Perspective を始める こちら の公式サイトへ飛んで、「AWSコンソールで起動する」 を行います。 スタックの作成 値は自動で入っています。 スタックの詳細を指定 ここではパラメータなど記載します。 スタックの名前は自動で入っていますが必要ならば記載ください。 パラメーターは今回はメールアドレスだけ記載します。 記載したメールアドレス宛にアクセス情報が送られます。 AdminUserEmailAddress : ログイン情報が送られるメールアドレス AlreadyHaveConfigSetup : AWS Configが有効化済みの場合はyesを選択 CreateElasticsearchServiceRole : ElasticSearchのサービスロールを作成するかどうかで、作成していなければyes CreateNeptuneReplica : Neptuneのリードレプリカを作成するかどうかで、必要なければno NeptuneInstanceClass : Neptuneのインスタンスタイプ OptOutOfSendingAnonymousUsageMetrics : 匿名でメトリクスをAWSに送りたい場合はyes スタックオプションの設定 今回は特に変更せず進みます。 タグなど必要があれば記載ください。 最終確認 パラメータや名前などを最終確認します。 最後に下記のチェックを行い、スタックの作成を行います。 スタックの作成待ち すべてスタックが完了するまでに30分程度必要なので待ちます。 aws-perspective-XXXXX というスタックが CREATE_COMPLETE になれば完了しました。 webのURLを確認 aws-perspective-XXXXX-CloudFrontDistribution-XXXXX のスタックを選択 > 出力に URLの記載があるので、こちらへ進みます。 メールでURLのログインパスワードを確認 スタックを作成する際に記載したメールアドレスに以下のようなメールが来るので確認する webUIのログイン UsernameとPasswordを記載し、サインインを行います。 新しいパスワードの記載を求められるので、記載し進みます。 インポートする環境の確認 ここでは、記載されているアカウント・リージョンのリソースのみ表示で良ければ、importへ進みます。 他のアカウントのリソースも追加したい場合は Import an Account で追加が行なえます。 リソースの読み込み 読み込みが完了するまで以下の画面で待ちます。 表示の確認 なかなか表示されなかったので、リロードしResourcesをクリックし進めたら表示できました。 削除も行う 作成したときと逆で、cloudformationのスタックを削除します。 スタックの削除 「ネストされた」 と記載のない 、 aws-perspective と aws-perspective-XXXXX というスタックを削除します。 削除途中でミスったので、もしかしたら違うかもです。 試して、違うかったらご指摘ください。 参考 [AWS Perspectiveで構成図を作成してみる](https://itport.cloud/?p=15123(%E6%96%B0%E3%81%97%E3%81%84%E3%82%BF%E3%83%96%E3%81%A7%E9%96%8B%E3%81%8F) AWS Perspectiveを構築してみた
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

aws_eip_associationって何だ

これは何ですか aws_eip_associationって何に使うんや、と思ったときに書いたメモです。 EC2のドキュメントを眺めていた時、どういうときに使うのかよくわからん、と思ったので、とりあえず構築して理解することにしました。 つまり 新規構築で、EIPをEC2に割り当てる祭、aws_eipを使うと思います。 ただ、既存のEIPを割り当てたいケースもありますよね、きっと。 そこで、aws_eip_associationを使うことで、解決できます。 やってみた まずはEIPをCLIで払い出します。(一時的に払い出しているだけなので、構成情報は書いても問題ないと思うのですが、念のためぼかしてます。) $ aws ec2 allocate-address { "PublicIp": "Your_EIP", "AllocationId": "eipalloc-○△□", "PublicIpv4Pool": "amazon", "NetworkBorderGroup": "ap-northeast-1", "Domain": "vpc" } aws_eip_associationを定義します。 resource "aws_eip_association" "eip" { instance_id = "${aws_instance.Your_EC2.id}" allocation_id = "eipalloc-○△□" } applyして構築します。 $ terraform apply コンソール上から確認してみます。 おお〜、本当に紐づいてますね。面白い。 何だかぼかしまくってて具体的にイメージできなそうですが… 一応、デプロイできたことを確認できました。 最後に やはり文章、記事かなんかでアウトプットするのが一番身になるなと思いました。終
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

IAMでIPアドレス制限をかける

先輩からある日こんなことを言われました。 『IPアドレス制限(※)というセキュリティ対策があるということを知ったので、MFAではなくIAMにその設定を入れ込んでほしいです。 (※)AWSアカウントにアクセスする際のグローバルIPを制限し、その指定IP以外はアクセス出来なくする手法 調べれば出てくると思いますのでやってみてください。』 先月からAWSをいじり始めたひよっこにはよくわからん話すぎたがとりあえず調べてやってみることに。 いろいろ調べていくうちにやらなきゃいけないことは大体つかめた。 要は、自分のパソコンのIPアドレス以外からのアクセスを拒否するIAMポリシーを作る→ユーザーグループに付与しなきゃいけないんだと思う。多分。 ということで、その方向で調べてみると神みたいな記事を見つけた。もうこの記事書いた人に頭が上がらない。ありがとう その神記事がこちら↓ とりあえず『AllowAssumeRoleWithSourceIPRestriction ポリシーの編集』までやって、そこからはポリシーをユーザーグループに紐付け! IAMのユーザーグループにいって・・・ 紐付けたいユーザーグループを選択 アクセス許可のタブを開いて『ポリシーをアタッチ』 で、さっき作ったポリシーを選択して完了!パチパチ 自分、記事見てやっただけですがとってもお勉強になりました
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【8日目】AWS認定ソリューションアーキテクト合格までの道

ネットワークサービス その他のネットワークサービス Amazon Route 53 DNSを提供するマネージドサービス 外部向けDNS(パブリックホストゾーン) VPC内DNS(プライベートホストゾーン) DNS機能だけではなく、通信を制御できるルーティングポリシーを使用できる →レコード作成時にRoute 53がクエリにどう応答するかの設定をする ALIASレコード Amazon Route 53独自のDNS機能 ELBやCloudFrontのエンドポイントをCNAMEレコードではなく、Aレコードとして指定できる Zone ApexレコードをAレコードとして扱える ・CNAMEレコード ドメイン名に対応する、別のドメイン名(あだ名)が書かれている行 ・Aレコード ドメイン名に対応する、IPアドレス(IPv4形式)が書かれている行 ・Zone Apexレコード サブドメインを含まないドメインが書かれている行 ※通常NSレコードとして利用される ・NSレコード DNSサーバーの名前が書かれている行 Amazon CloudFront エッジロケーションからコンテンツを配信するCDNサービス 物理的に最も近いCloudFrontのキャッシュサーバーからコンテンツを受け取れるため、低レイテンシーなWebサービス オリジンとして、ELB/EC2/S3などのAWSサービスやオンプレミス環境のサーバーも指定できる CDN(Content Delivery Network) 世界中に配置されているCDNネットワークから効率的にコンテンツを配信する仕組み 閲覧者から最も近い拠点から配信する CloudFrontの機能 SSLによる通信の暗号化 ユーザーが用意した独自のSSL証明書を導入できる CloudFrontからバックエンドのAWSサービスまでをSSL暗号化通信にできる 署名付きURL 一定時間だけアクセスを許可するためのURLを発行 限定したユーザーのみに公開できる カスタムエラーページ オリジンからエラーコードが返されたとき、あらかじめ設定したエラーページを表示する 地域限定(地理的ブロッキング) CloudFrontへ接続するユーザーの地域情報に基づいてアクセスを許可/拒否できる ストリーミング配信 Webサービス以外にも映像/音声のストリーミング配信にも対応 ストリーミング コンテンツをダウンロードしながら表示や再生すること AWS Global Accelerator AWSが管理するネットワークを利用して、アプリケーションを高いパフォマンスで提供できるサービス インターネット経由よりも高いパフォーマンスが期待される VPCフローログ VPC内のネットワークインターフェイス(ENI:Elastic Network Interface)で通信するトラフィック情報を取得するサービス Amazon CloudWatch Logsへ転送される ENI(Elastic Network Interface) AWSで利用する仮想ネットワークインターフェイス パブリックIPアドレス/プライベートIPアドレスを設定でき、EC2インスタンスなどに接続して利用する Elastic IP(EIP) 固定のグローバルIPアドレスを提供するサービス インスタンスにアタッチされていない/インスタンスが停止中の場合、時間単位で料金が発生 通常、EC2インスタンスを停止するとIPアドレスは保持できなくなるため、IPアドレスが変わるたびにアプリケーションやDNSの変更は手間がかかる AWS Resource Access Manager(RAM) AWSアカウント/AWS Organizations組織内でサブネットやAWS Transit Gatewayなどのリソースを共有するサービス 全てのアカウントで共通して利用するリソースを集約して運用の負荷やコスト効率を向上できる 通常、複数のアカウントを利用している場合、用途が同じでもそれぞれのアカウントでリソースを作成する必要がある AWS DataSync オンプレミス環境のストレージとAWSのストレージサービス間でデータ転送を高速に行うことができるサービス  AWSへのデータ移行が主な利用用途 専用のエージェントを導入して利用する 転送先のストレージサービスとして、S3/EFS/FSx for Windowsなどがある 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ローカル環境にDynamoDBを構築する(Java上に構築)

概要 表題通り、DynamoDBをローカル開発環境に構築する記事です。 DyanmoDBのインストール方法は下記2つの方法がありますが、今回はJava上に構築します。 1. Java上に構築する方法 2. Docker上に構築する方法 1. Javaのインストール 1-1の状態であれば、Javaのインストールが必要です。installを実施しましょう。 1-2の状態であれば、次のステップに進んでください。 1-1jarのinstall未実施 ~/develop/aws/dynamodb/dynamodb_local_latest $ java --v The operation couldn’t be completed. Unable to locate a Java Runtime. Please visit http://www.java.com for information on installing Java. 1-2jarのinstall済み ~ $ java --version openjdk 11.0.11 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode) Javaのinstall リンクからOpenJDKをinstallします。 1-2jarのinstall確認 ~ $ java --version openjdk 11.0.11 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode) 2. DynamoDBのインストール リンクより、DynamoDBをダウンロードする。 解凍ファイルを任意の場所に配置する。 解凍ファイルを配置 ~/develop/aws/dynamodb $ ls dynamodb_local_latest 実行 ~/develop/aws/dynamodb/dynamodb_local_latest $ java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb Initializing DynamoDB Local with the following configuration: Port: 8000 InMemory: false DbPath: null SharedDb: true shouldDelayTransientStatuses: false CorsParams: * dynamoDBにアクセス ~/develop/aws/dynamodb/dynamodb_local_latest $ aws dynamodb list-tables --endpoint-url http://localhost:8000 { "TableNames": [] } これで、インストール完了です!!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WSLからEC2にSSHしようとして「UNPROTECTED PRIVATE KEY FILE!」と言われた時

はじめに 「WSLはWSL内だけで完結させるといいよ」というのが主旨です。 Vscodeでon the WSLの開発をしていると、警告画面で「プロジェクトディレクトリはWSL内に置いてください!」みたいなことを促されたりします。これはアクセス速度の問題ですが、SSHに関してもアクセス権限の問題で、WSL内で完結するのが良さそうです。 ただし、管理者権限やroot権限が上司にいただけない立場で仕事している場合の話です。 現象 WSL から AWS の EC2 インスタンスへSSH 接続するとき、Permission error になります。 The authenticity of host 'ec2-instance-name.region-name.compute.amazonaws.com (public-ip)' can't be established. ECDSA key fingerprint is SHA256:???????????????????????????. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'ec2-instance-name.region-name.compute.amazonaws.com (public-ip)' (ECDSA) to the list of known hosts. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0555 for '????????.pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "???????.pem": bad permissions ubuntu@ec2-instance-name.region-name.compute.amazonaws.com: Permission denied (publickey). この時、Windows 側の Powershell から同じことをしてみると、 he authenticity of host 'ec2-instance-name.region-name.compute.amazonaws.com (public-ip)' can't be established. ECDSA key fingerprint is SHA256:???????????????????????????. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'ec2-instance-name.region-name.compute.amazonaws.com (public-ip)' (ECDSA) to the list of known hosts. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions for '????????.pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "???????.pem": bad permissions ubuntu@ec2-instance-name.region-name.compute.amazonaws.com: Permission denied (publickey). 8行目が、Powershellだと、Permissions forで WSL だとPermissions 0555 forになっています。 状況 まずは大きく、 WARNING: UNPROTECTED PRIVATE KEY FILE! と記載されていますので、「警告!保護されていない秘密鍵ファイル」というアラートが出ていることは分かります。 Permissions 0555 for '????????.pem' are too open. 次にこの部分ですが、カタカナを使わずに言うと、「許可が0555なのは、開放的すぎる」と言ってます。 何の許可かというと、ファイルパーミッションです。 この、0555という数字はstatコマンドなどで確認できます。 stat ????.pem -c '%a' ここで、AWS のコンソールを確認すると、 chmod 400 ???.pem と書いてあります。 しかし、これを行っても、依然として同じエラーメッセージが出て、SSH接続はできません。 原因追及 なぜなのか確認してみましょう。chmod 400 ???.pemをした直後にstat ???.pem -c '%a'で確認すると、555になっていることが分かります。 恐らく、私と同じ状況にある人は、???.pemファイルの置いてあるディレクトリが、WSLの/mnt/の下位ディレクトリに保管されているのではないでしょうか? どういうことなのでしょう?これは、???.pemファイルの保存ディレクトリがWindowsの管轄領域にあり、アクセス権限はWindowsでコントロールされているので、WSL側で自由に変更できないように制限がかけられているということです。 WSL側でファイルパーミッションを書き換えた後にWindows側が自動修復するのか、そもそも書き換える直前にWindows側でコマンドを変更されるのかは分かりませんが、chmodコマンドをひたすら試しても意味のないことが分かります。 解決方法 解決方法は3つあります。 1つは、WSL側が管理しているディレクトリに???.pemファイルを移動する方法です。 そして、もう1つは、諦めてWindows側でSSH接続する方法です。 最後の方法はroot権限でSSH接続する方法です。 先に伝えておくと、Windows側の方法を試しても、WSL側でSSH接続はできません。 WSL側で完結させる方法 まず、最初の方法は簡単で、単純にcpコマンドで移動させてから、chmodでファイルパーミッションを変更するだけです。 例えば、???.pemファイルが置いてあるディレクトリに移動したとして、 cp ./???.pem ~/???.pem とすると、WSLのホームディレクトリに秘密鍵ファイルがコピーされます。このまま、移動先の秘密鍵のファイルパーミッションを変更します。 chmod 400 ~/???.pem 一応ファイルパーミッションを変更できているのか確認しましょう。 stat ~/???.pem -c `%a` とすると、400と出ました。完璧です。これでSSH接続できますね。 Windows側で解決する方法 Windows側ではGUIでやることもできますが、 Powershellでの方法を紹介します。 簡単に言うと、システム権限をシステムから剝奪します。 Copy-Item './???.pem' Set-Location '~/Desktop' New-Variable -Name Key -Value './???.pem' Icacls $Key /c /t /Inheritance:d Icacls $Key /c /t /Grant $( $env:UserName + ':F' ) Icacls $Key /c /t /Remove Administrator 'Authenticated Users' BUILTIN\Administrators BUILTIN Everyone System Users Icacls $Key Remove-Variable -Name Key 上記のPowershellスクリプトの実行には管理者権限が必要です。 秘密鍵ファイルがUSBメモリや外付けHDDなどのリムーバブルメディアに保管されていると上手くいきません。 この時、Icacls $Keyの部分で、ファイルパーミッションがどう設定されたのか確認できます。 .\???.pem PCNAME\USERNAME:(F) のようになっていれば成功です。 ここで、すぐにWindows側でSSH接続を試すと接続できます。 しかし、このファイルは、WSL側から、stat ./???.pem -c '%a'で確認すると、777となっています。 このことから、Windows側に置いている秘密鍵ファイルを使って、WSL側からSSH接続をすることは非常に難しいと結論づけることが出来ます。 ここで、WSLにて、sudo suをしてから、chmod 400 ./???.pemすると、stat ./???.pem -c '%a'の結果は555になります。 その root 権限のまま SSH接続を試すと、接続することが出来ます。 ここで、「ん?」となるのではないでしょうか?そうです。実はWindows側であれこれする前から555なので、root 権限であれば始めからSSH接続できたのです。 公式の記述 このことは、公式にも書かれてます。 ほかの方法 c ドライブなどのmount方法を変更することで、chmodの効力が変わるようですが、デフォルト設定を変更するのは避けたいところ。 まとめ WSL側の領域に秘密鍵ファイルを保管するのが最も早そうです。 日常生活では、777というゾロ目は少しだけハッピーな気分にさせてくれます。 この状況では777という数字は見たくないですね。 みなさんの手元に400が出ることを願っています!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Fargateにsshできるワンライナー

xargs -a <(aws ecs list-tasks --cluster=[your cluster name] --service-name=[your service name] | jq '.taskArns[0] | split("/")[2]') -I{} aws ecs execute-command --cluster [your cluster name] --task {} --container [your container name] --interactive --command '/bin/sh' list-tasksで取得できる一番古いfargateタスク内の特定のコンテナにsshできます。 最初はlist-tasksの結果をパイプでxargsに渡していましたがこれだと Cannot perform start session: EOF となり失敗するはずです。 参考にした記事: https://stackoverflow.com/questions/30044927/xargs-exec-command-with-prompt
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む