1. 目的 AWSのデータベース関連サービスの復習をしている。AWS Database Migration Service (DMS)を使ってDBを移行するプロセスを理解する。 2. やったこと EC2インスタンスにWordPressを構築する。WordPressが使用するDBとして、EC2インスタンス内にMariaDBをインストールする。 EC2インスタンスにインストールしたMariaDBのデータを、RDS(MariaDB)にDMSを用いて移行する。 WordPressのDB参照先設定をRDS(MariaDB)に切り替えて、問題なく動作することを確認する。 3. AWS Database Migration Service とは(自分の理解) オンプレミスや他社クラウドで稼働するDBをAWSへ簡単に移行させることができるツール。 4. 構成図 5. 実機確認手順 5.1 全体の流れ EC2インスタンスにWordPressをインストール(移行元となるMariaDB 5.5をEC2インスタンス内にインストール) 移行先のRDS(MariaDB 10.4)を作成 DMSのレプリケーションインスタンス(データ移行を行うインスタンス)を作成 DMSのソースエンドポイント(移行元への接続情報)、ターゲットエンドポイント(移行先への接続情報)を作成 データベース移行タスクを作成し、データ移行を開始 データ移行完了後、WordPressのDB接続設定を、EC2インスタンス内のMariaDBからRDS(MariaDB)へ変更 5.2 EC2インスタンスの作成とWordPress/MariaDBのインストール 事前にVPC及びサブネット(構成図の通り)を用意しておく。 EC2にWordPressをインストールする手順の記事「【超初心者向け】WordPressをAmazon EC2インスタンスにインストールする」を完全にそのまま実施する。(丁寧な解説のある素晴らしい記事) WordPressのインストールが完了し、記事が投稿できることを確認する。 この手順によってインストールされるMariaDBのバージョンは5.5.68となる。 [ec2-user@ip-10-0-1-76 ~]$ rpm -qa | grep -i mariadb mariadb-libs-5.5.68-1.amzn2.x86_64 mariadb-server-5.5.68-1.amzn2.x86_64 mariadb-5.5.68-1.amzn2.x86_64 5.3 移行先のRDS(MariaDB 10.4)の作成 移行先となるRDS(MariaDB)DBインスタンスを作成する。 RDSのMariaDBは5.x系は既に利用不可のため、デフォルトのバージョン(10.4.13)を選択する。 移行元EC2インスタンスと同じVPCに起動し、同一VPCからの接続は許可するようセキュリティグループを設定する。 5.4 DMSのレプリケーションインスタンスの作成 DMSでデータ移行を行うためのレプリケーションインスタンスを作成する。レプリケーションインスタンスが移行元DB、移行先DBの両方と接続して、移行元からデータを抜き出し移行先へ書き込む役割を担う。 マネージメントコンソールにて、「DMS > レプリケーションインスタンス > レプリケーションインスタンスの作成」の画面を開き、移行元EC2インスタンス及びRDS DBインスタンスと同じVPCを選択してレプリケーションインスタンスを作成する。 5.5 DMSのソースエンドポイント、ターゲットエンドポイントの作成 ソースエンドポイント(移行元DBへの接続情報)、ターゲットエンドポイント(移行先DBへの接続情報)を作成する。 5.5.1 ソースエンドポイントの作成 まずソースエンドポイントを作成する。「DMS -> エンドポイント -> エンドポイントの作成」から設定を行う。 「サーバー名」にはEC2インスタンスのプライベートIPを入力する。 「エンジン」として「MariaDB」を選択すると、MariaDBの場合に必要な入力欄が表示される(ログインID/パスワード、port番号など) 作成したソースエンドポイントを選択し、「接続 > 接続テスト」を実行すると、「Failed」になってしまった。 MariaDBが外部からのroot接続を拒否する設定になっていたため、以下の設定変更を行った。 設定方法は「外部のホストから接続できるようにする方法」を参考にさせて頂いた。 MariaDB [(none)]> select user, host from mysql.user; +----------------+-----------+ | user | host | +----------------+-----------+ | root | 127.0.0.1 | | root | ::1 | | root | localhost | | wordpress-user | localhost | +----------------+-----------+ 4 rows in set (0.00 sec) MariaDB [(none)]> grant all privileges on *.* to root@"%" identified by '[PASSWORD]' with grant option; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> select user, host from mysql.user; +----------------+-----------+ | user | host | +----------------+-----------+ | root | % | | root | 127.0.0.1 | | root | ::1 | | root | localhost | | wordpress-user | localhost | +----------------+-----------+ 5 rows in set (0.00 sec) 再度接続テストを行い、成功することを確認した。 5.5.2 ターゲットエンドポイントの作成 次にターゲットエンドポイントを作成する。「DMS -> エンドポイント -> エンドポイントの作成」から設定を行う。 「RDS DBインスタンスの選択」にチェックを入れることにより、既存のRDS DBインスタンスの中から、ターゲットにするDBインスタンスを選択することができ、それに伴いARNなどの情報も自動入力される。 ソースエンドポイント同様、「接続 > 接続テスト」を実行し、接続が成功することを確認する。 5.6 データベース移行タスクの作成 データベース移行タスクを作成する。タスクの概念としては、レプリケーションインスタンスとソース/ターゲットインスタンスを紐づけて、レプリケーションインスタンスにソースからデータを取得させ、ターゲットにデータを書き込む作業をやらせるイメージ。 「DMS -> データベース移行タスク -> タスクの作成」から、タスクの作成を行う。 移行タイプとして、「既存のデータを移行する」「既存のデータを移行して、継続的な変更をレプリケートする」「データ変更のみをレプリケートする」の選択肢がある。データ移行中のソースDBの更新にも対応したいと思い、今回は「既存のデータを移行して、継続的な変更をレプリケートする」を選択する。 エラー時の調査ができるように、CloudWatch ログを有効化した。また、CloudWatchログを使用するにあたり、別途専用のIAM Roleを作成する必要があり、「AWS DMS タスクの CloudWatch Logs が表示されないのはなぜですか? 」を参照して対応した。 テーブルマッピングの設定を入れないとタスクが作成できないため、スキーマ、テーブルの全てをコピーするようなルールを設定した。 タスクを開始したところ、以下のエラーとなった。 「Binary Logging must be enabled」となっているため、「MySQLのバイナリログを活用しリストア＆リカバリで障害時でもDB完全復旧可能な体制を整える。」を参照し、EC2インスタンス内のMariaDBの設定変更を行い、バイナリログを有効化した。 /etc/my.cnf [mysqld] # 以下のBinary log 記載を追記 # Binary log server-id=1 log-bin=/var/log/mysql/bin_log/mysql-bin-log log_bin_index=/var/log/mysql/bin_log/bin.list max_binlog_size=256M expire_logs_days=2 [ec2-user@ip-10-0-1-76 ~]$ mkdir -p /var/log/mysql/bin_log [ec2-user@ip-10-0-1-76 ~]$ sudo chown -R mysql:mysql /var/log/mysql/bin_log [ec2-user@ip-10-0-1-76 ~]$ systemctl restart mariadb タスクを再実行したところ、また別のエラーで止まってしまった。 「Binary Logging must use ROW Format」ということで、DMSのドキュメント「Using a MySQL-compatible database as a source for AWS DMS 」に従い、さらに設定を2行追加した。 /etc/my.cnf # Binary log server-id=1 log-bin=/var/log/mysql/bin_log/mysql-bin-log log_bin_index=/var/log/mysql/bin_log/bin.list max_binlog_size=256M expire_logs_days=2 binlog_format=ROW binlog_checksum=NONE 「エラーを伴って実行中」という微妙な状態だが、タスクは実行されるようになった。 この状態であれば、レプリケーションが実行されており、移行元のMariaDBへの変更が移行先にも自動反映されるはずのため、移行元の記事にコメントを追加した。 5.7 WordPressのデータベース設定の切替 EC2インスタンスのWordPressのDBの参照先設定を、インスタンス内のMariaDBから、RDS(MariaDB)のDBインスタンスに変更する。 実行中のタスクの進行状況が100%であることを確認し、タスクを停止する。 WordPressの設定を変更する。ホスト名はRDSのエンドポイントとし、接続ユーザもいったんRDSのadminとした。 /var/www/html/blog/wp-config.php /** MySQL database username */ define( 'DB_USER', 'admin' ); /** MySQL database password */ define( 'DB_PASSWORD', '[password]' ); /** MySQL hostname */ define( 'DB_HOST', 'mksamba-mariadb.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com' ); [ec2-user@ip-10-0-1-76 blog]$ sudo systemctl restart httpd [ec2-user@ip-10-0-1-76 blog]$ sudo systemctl stop mariadb DBの接続先が変更されても、同じコンテンツが表示可能であることを確認した。 6. 所感 一応流れは理解することができた。本当に本番で使う時はエラーの原因調査などきちんと深堀したい。

前提条件 mavenでspringアプリをjarファイル化していること AWS無料アカウント 概要 大まかに5つの手順を行います。 EC2インスタンス生成＋EC2に接続するために必要な秘密鍵取得 EC2にSSH接続 EC2にjarファイルをsftp送信する EC2上にjavaインストール jar実行 それでは順に説明いたします。 ①EC2インスタンス生成＋EC2に接続するために必要な秘密鍵取得 インスタンスを起動します。 OSテンプレートを指定します。今回はAmazon Linux 2で行います。 セキュリティグループの設定でルールの追加ボタン押下でカスタムTCPを以下の設定で追加します。80はhttp、443はhttpsからのリクエストに対応するためのものです。 ＊追記：HTTPリクエストを受け取る場合8080もポート範囲に指定します。失礼しました。 確認画面で起動を押すと鍵について問われるので、まずは新しいキーペアを作成を選び任意の値を入力しキーペアのダウンロードを押します。 プルダウンを既存のキーペアの選択に変え、作成したばかりのキーペアを選択しチェックを入れた状態でインスタンスの作成を押下します。 ②EC2にSSH接続 今回はteratermを使って接続します。teratermを起動後の最初の画面では作成したEC2インスタンスのパブリック IPv4 アドレスをホストに入力します。 セキュリティの警告が出ますがそのまま進みます。 ユーザー名はec2-user、秘密鍵は先ほど作成したキーペアのパスを参照します。 接続しました。 ③EC2にjarファイルをsftp送信する 今回はWinSCPを使い送信します。まずは設定を押下します。 左のメニューのSSH認証を選択し、秘密鍵は先ほどのキーペアのパスを参照します。 Putty形式に変換はOKで保存します。 戻ってきた最初の画面でホスト名を入力します。EC2インスタンスのパブリック IPv4 アドレスです。 警告が出ますが進みます。不明なサーバーと書いてますがEC2です。 ユーザー名にec2-userを入力します。 jarファイルを左から右にドラッグドロップします。 ④EC2上にjavaインストール EC2でコマンドを実行します。 sudo yum install java-11-amazon-corretto-headless ⑤jar実行 EC2でコマンドを実行します。 java -jar ｛実行したいjarファイル名｝.jar お疲れ様でした。

5G MEC 往復遅延の分布をもう少し さて、先行記事（計測編） では KDDI 5G MEC （その実体は AWS Wavelength インスタンス）相手に ping 往復遅延の Best case を示しました。 今回は計測したデータ全体の分布を見て、距離による影響や KDDI 閉域網とInternet 越しアクセスの差などを見たいと思います。 使用した計測データ 計測機器・計測環境などについては先行記事をご覧下さい。先行記事に示した環境のうち、今回は成績が良かった Smartphone を用いた ping RTT (Rount Trip Time) のデータを使います。 先行記事で示した結果は、大阪にある MEC つまり Wavelength インスタンスとの通信に関するものだけでした。Best case を示すことが目的だったので当然そうなります。しかし実際の計測は以下の四つのインスタンスを対象に行っていました。 Wavelength instance （大阪） Wavelength instance （東京） （通常の）EC2 instance （大阪） （通常の）EC2 instance （東京） 以後、それぞれ WL-Osaka, WL-Tokyo, EC2-Osaka, EC2-Tokyo と略記します。 対象による差異 全体の傾向 まずは上記四つの対象ノードによる計測値の分布を見ます。 計測はある地点で ping を上記四つの対象に向けて 10 回飛ばして記録し、少し移動してまた10回飛ばして記録する、といった方法で行っています。ただし最初の一回目のレスポンスタイムはどうも不安定なようなので、今回のデータからは外しています。 グラフはこの「ある地点でのある対象から得た 9 つのレスポンスタイム」を、縦に並べて打点したものです。色は対象ノード、縦軸はレスポンスタイム、横軸ラベルは計測地点を示します。 見ての通り、教科書的というか Wavelength の方がより早くで、東京より大阪の方がより早くレスポンスが届いています。そしてこれは今回の偶発でしょうか、東京の EC2 インスタンス向けの通信がえらく遅滞していたようです。 詳細比較 細かく比較するために、グラフの下部を拡大します。 距離による遅延の違いや、閉域網であることの優位性が可視化されています。 大阪・東京で 10ms 程度の遅延差が RTT で生じる（端末は京都） 閉域網内か Internet 経由かでは、RTT 最良値では差が出ないが、最悪値では差が出る（閉域網内アクセスの方が安定度が高い） WL-Osaka (大阪のMEC) に対する実験全体でのばらつき やはり値が安定して良かった WL-Osaka つまり大阪の Wavelength インスタンスについては、計 9 箇所で 13 回の計測を行っています。それらをざっと並べてみます。横軸のラベルに意味はありません（計測位置を示していません）。 見ての通り、かなり安定しています。ただ、東京の EC2 インスタンス向けの時にあった「ときどきひどく遅くなる」現象が見られます。（今回の実験では 9 x 13 計測のうち 2 回） 先と同様に拡大します。遅延の大きな 2 データはグラフの上に消えて、見えていません。 平均や偏差といった数値に丸めてしまうと見えてこないミクロな傾向を感じて貰えればと思います。（大したデータ数ではありませんが、元データに興味のある方はリクエスト下さい。お渡しします。） おわりに これがとりあえず計測時点の、京都四条烏丸界隈での KDDI 5G MEC のレスポンスと、その安定度ということでしょうか。つまり条件を揃えれば、まあまあ20-30ms くらいが期待できそうです。私が ONS/ONES などでずっと聞いていた 5ms で返ってくる、といった「究極的なゴール」にはまだ距離感がありますが、まあ、そうなるんだなという実感を得るには充分な数字と思います。 例えば現時点の KDDI 5G は NSA つまり 4G/LTE 網の上に乗っています。これが SA になり、スライシングを含めた 5G らしい構造で伝送されれば、遅延・ばらつきともにかなり改善されるはずです。そして今回の結果は京都から大阪まで（四条烏丸から堂島？）の 50-60Km 程度、11 ホップを超えた数字です。これが例えば四条烏丸交差点に MEC が来たら、距離遅延はほぼゼロに、ホップ数もかなり減って、さて何ミリ秒短かくなるでしょう。そのようにして徐々にこの「究極的」な数字に近づくのだろうなと思えます。 まあ、そういう妄想はひとまずおいて 私が今回の実験で得たかったのは、まさに今回示したグラフでした。私は何にせよ、こういう具体的なデータと体感がないと、そこから先の考え事が出来ないのです。例えば今回のグラフを見ると、この 5G mobile の性質からは（この不安定さが完全に消せるとは思えないので）、最悪ケースを見て「これしか出来ない」と考えるのではなく、最良ケースに何かしら良いことがある応用を考えたくなります。 そう言えば先日ゲーム屋さんから「ロスト（や遅延）があれば過去データから線形補間して対応する。それでだいたい問題無い」と聞いて「ああなるほど！」と思ったものです。データが無い時はそれなりに。早くデータが届いたらよりリアルになる。良いじゃないですか。 （もちろん最悪値に合わせて設計しなければならないアプリケーションの方が多いのでしょうけど、まあそっちには今は興味が湧きません。） 今後の計画 今回は遅延、それも RTT だけを調べましたが、次はある程度まとまったデータを転送した場合の傾向を調べようと思います。それから、四条烏丸交差点近辺に機材を設置して長期計測をしたいと考えています。 片手間なのでなかなか進まないのですが。ボチボチと。皆さんも（KDDI に限らず）MEC について何か分かったらぜひ共有しましょう。情報発信お待ちしています。

CloudWatch メトリクスストリームにより、Datadog で素早くメトリクスを取得できるようになりました。 従来、Datadog から API 経由でポーリングしていましたが、AWS からストリーミングできるようになります。 画像出典： [速報] CloudWatchの監視メトリクスをKinesis経由でストリーム送信可能な新機能「CloudWatch Metric Streams」が登場しました！ 今回は Datadog 提供の CFn テンプレートを利用してメトリクスストリームを設定してみました。 エントリがあまり出ていなかったので、同じ方法を検討している方の参考になればと思います。 効果 先に導入効果をお伝えします。 評価項目 設定前 (GetMetricData API) 設定後 (CloudWatch Metric Streams) 遅延時間 最大12分 3分 (稀に4分) コスト 1,000メトリクスごとに 0.01 USD 1,000メトリクスごとに 0.003 USD + Data Firehose 設定前は最大12分程度あった遅延が、3分に短縮されました。 (目視なのでざっくりですが) 遅延と呼んでいるのは、リアルタイム時刻からメトリクスが表示されるまでの時間です。 コストの最新情報は、AWS公式サイト よりご確認を。 設定方法 設定方法はとても簡単です。 Datadog公式サイト よりご確認ください。 CFnテンプレートを微修正 ※ こちらは任意です。テンプレートを一つにまとめたい、自身で管理したいという方はご参照ください。 手順中で Automatically Using CloudFormationを押下すると AWS の CFn スタック作成画面に飛びます。このテンプレートはDatadog管理のテンプレートであり、かつ、ネストになっているため、状態をコードで追うのがやや面倒です。 私の場合、メトリクスを取得したいリージョンが東京のみで、テンプレートを一つにまとめたかったので下記のように修正しました。逆に複数のリージョンから取得したい人はそのまま利用するのがよいと思います。 テンプレートは長いので 一番下 に貼り付けます。 設定確認 CFnスタックを作成して数分後にこのような画面になっていれば正常に設定されています。 ＜設定前＞ 10分くらい遅延してメトリクスが取得されています。（見に行くタイミングによる） ＜設定後＞ コンスタントに3分遅延でメトリクスが取得されるようになりました！ 注意事項 設定直後グラフが変な感じになる 設定後のスクショを見てもらうと 10:20 で値が上昇していますが、Cloudwatch 側ではこの変化は見られませんでした。おそらくAPIとストリームの重複取得が生じているのだと思いますが、十数分待つと正常値に戻りました。 Datadogページ内には次のように記載されています。 Metric collection via API is automatically disabled for any namespace sending metrics via streaming. Delay evaluation を調整 Monitor でアラームを仕掛けている場合は、Delay evaluation の調整が必要です。この値は、モニターの評価を何秒遅らせるかを指定するものです。メトリクスを素早く取得できても、Delay evaluation を変更しなければアラーム発報までの時間を短縮できないのでご注意ください。 Datadogページ内には次のように記載されていますが、これはAPI経由でメトリクスを取得することを前提としていると思われます。 We highly recommend a delay of at least 900s for AWS metrics. まとめ CloudWatch メトリクスストリームを用いた Datadog メトリクス取得事例をご紹介しました。 アラーム発報までの時間が短縮されることで異常に素早く対応できるのでよかったです！！ CFnテンプレート datadog-metric-streams.yml AWSTemplateFormatVersion: "2010-09-09" Parameters: GlobalPrefix: Type: 'String' Default: 'datadog-metric-streams' GlobalEnvironment: Type: 'String' Default: 'stg' ApiKey: Description: >- Your Datadog API Key Type: String AllowedPattern: .+ ConstraintDescription: ApiKey is required NoEcho: true # [NOTE] # ストリームするメトリクスをフィルタしたい場合 -> Include/Exclude を指定の上、Namespaceに必要/不要な名前空間を入力 # 全メトリクスを取得したい場合 -> Default:Includeのまま、FirstNamespace以降の入力は不要 FilterMethod: Description: >- "Include" for an inclusion filter or "Exclude" for an exclusion filter for the following namespaces. Type: String Default: 'Include' # [NOTE] # Namespaceパラメータ不足の際には適宜追加すること # その際、ConditionsとResourcesの該当箇所への追記も忘れずに FirstNamespace: Description: >- A namespace to use for filtering. Leave blank if you do not need to filter by namespace. Type: String Default: '' SecondNamespace: Description: >- A namespace to use for filtering. Leave blank if you do not need to filter by namespace. Type: String Default: '' ThirdNamespace: Description: >- A namespace to use for filtering. Leave blank if you do not need to filter by namespace. If you need additional namespaces follow this link for additional templates. Type: String Default: '' DdSite: Type: String Default: datadoghq.com Description: Define your Datadog Site to send data to. For the Datadog EU site, set to datadoghq.eu AllowedPattern: .+ ConstraintDescription: DdSite is required Conditions: HasIncludeNamespace1: !And [ !Not [ !Equals [ !Ref FirstNamespace, '' ] ], !Equals [ !Ref FilterMethod, 'Include' ]] HasIncludeNamespace2: !And [ !Not [ !Equals [ !Ref SecondNamespace, '' ] ], !Equals [ !Ref FilterMethod, 'Include' ]] HasIncludeNamespace3: !And [ !Not [ !Equals [ !Ref ThirdNamespace, '' ] ], !Equals [ !Ref FilterMethod, 'Include' ]] HasExcludeNamespace1: !And [ !Not [ !Equals [ !Ref FirstNamespace, '' ] ], !Not [ !Equals [ !Ref FilterMethod, 'Include' ]]] HasExcludeNamespace2: !And [ !Not [ !Equals [ !Ref SecondNamespace, '' ] ], !Not [ !Equals [ !Ref FilterMethod, 'Include' ]]] HasExcludeNamespace3: !And [ !Not [ !Equals [ !Ref ThirdNamespace, '' ] ], !Not [ !Equals [ !Ref FilterMethod, 'Include' ]]] USDatacenter: !Equals [ !Ref DdSite, 'datadoghq.com' ] EUDatacenter: !Equals [ !Ref DdSite, 'datadoghq.eu' ] Staging: !Equals [ !Ref DdSite, 'datad0g.com' ] Resources: # For Firehose ServiceRole: Type: "AWS::IAM::Role" Properties: RoleName: !Sub "${GlobalPrefix}-${GlobalEnvironment}-datadog-service-role" AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: "Allow" Principal: Service: - "firehose.amazonaws.com" Action: - 'sts:AssumeRole' Path: / Policies: - PolicyName: "datadog_stream_s3_policy" PolicyDocument: Version: 2012-10-17 Statement: - Effect: "Allow" Action: - "s3:AbortMultipartUpload" - "s3:GetBucketLocation" - "s3:GetObject" - "s3:ListBucket" - "s3:ListBucketMultipartUploads" - "s3:PutObject" Resource: - !Sub "arn:aws:s3:::${GlobalPrefix}-${GlobalEnvironment}-backup" - !Sub "arn:aws:s3:::${GlobalPrefix}-${GlobalEnvironment}-backup/*" # For CloudWatch Metric Streams DatadogMetricStreamRole: Type: AWS::IAM::Role Properties: RoleName: !Sub "${GlobalPrefix}-${GlobalEnvironment}-datadog-streams-role" AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - streams.metrics.cloudwatch.amazonaws.com Action: - "sts:AssumeRole" Path: / Policies: - PolicyName: "datadog_stream_firehose_policy" PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - "firehose:PutRecord" - "firehose:PutRecordBatch" Resource: - !Sub "arn:aws:firehose:*:${AWS::AccountId}:deliverystream/${GlobalPrefix}-${GlobalEnvironment}" Description: A metric stream role DatadogStreamLogs: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "${GlobalPrefix}-${GlobalEnvironment}" RetentionInDays: 14 HTTPLogStream: Type: AWS::Logs::LogStream Properties: LogGroupName: !Ref DatadogStreamLogs LogStreamName: "http_endpoint_delivery" S3Backup: Type: AWS::Logs::LogStream Properties: LogGroupName: !Ref DatadogStreamLogs LogStreamName: "s3_backup" # 配信エラー時のバックアップ用 DatadogStreamBackupBucket: Type: AWS::S3::Bucket Properties: BucketName: !Sub "${GlobalPrefix}-${GlobalEnvironment}-backup" AccessControl: 'Private' BucketEncryption: ServerSideEncryptionConfiguration: - ServerSideEncryptionByDefault: SSEAlgorithm: 'AES256' PublicAccessBlockConfiguration: BlockPublicAcls: True BlockPublicPolicy: True IgnorePublicAcls: True RestrictPublicBuckets: True DatadogMetricKinesisFirehose: Type: AWS::KinesisFirehose::DeliveryStream Properties: DeliveryStreamName: !Sub "${GlobalPrefix}-${GlobalEnvironment}" DeliveryStreamType: "DirectPut" HttpEndpointDestinationConfiguration: BufferingHints: # [NOTE] # Datadog推奨値に設定 # ref) https://www.datadoghq.com/ja/blog/amazon-cloudwatch-metric-streams-datadog/ SizeInMBs: 4 IntervalInSeconds: 60 EndpointConfiguration: Url: !If - Staging - "https://awsmetrics-http-intake.datad0g.com/v1/input" - !If - EUDatacenter - "https://awsmetrics-intake.datadoghq.eu/v1/input" - "https://awsmetrics-intake.datadoghq.com/v1/input" Name: "Event intake" AccessKey: !Ref ApiKey CloudWatchLoggingOptions: Enabled: True LogGroupName: !Ref DatadogStreamLogs LogStreamName: "http_endpoint_delivery" RoleARN: !GetAtt ServiceRole.Arn RetryOptions: DurationInSeconds: 60 S3BackupMode: "FailedDataOnly" S3Configuration: RoleARN: !GetAtt ServiceRole.Arn BucketARN: !GetAtt DatadogStreamBackupBucket.Arn ErrorOutputPrefix: "datadog_stream" BufferingHints: SizeInMBs: 4 IntervalInSeconds: 60 CompressionFormat: "GZIP" CloudWatchLoggingOptions: Enabled: True LogGroupName: !Ref DatadogStreamLogs LogStreamName: "s3_backup" Tags: - Key: "Team" Value: "aws-integration" - Key: "StreamAccountID" Value: !Ref "AWS::AccountId" DatadogMetricStreamAllNamespaces: Type: AWS::CloudWatch::MetricStream Properties: Name: !Sub "${GlobalPrefix}-${GlobalEnvironment}" FirehoseArn: !GetAtt DatadogMetricKinesisFirehose.Arn RoleArn: !GetAtt DatadogMetricStreamRole.Arn OutputFormat: "opentelemetry0.7" # IncludeFilters と ExcludeFilters は一方のみ指定（両方は不可） # Include も Exclude も指定しない場合は全てのメトリクスがストリームされる IncludeFilters: - !If - HasIncludeNamespace1 - Namespace: !Ref FirstNamespace - !Ref 'AWS::NoValue' - !If - HasIncludeNamespace2 - Namespace: !Ref SecondNamespace - !Ref 'AWS::NoValue' - !If - HasIncludeNamespace3 - Namespace: !Ref ThirdNamespace - !Ref 'AWS::NoValue' ExcludeFilters: - !If - HasExcludeNamespace1 - Namespace: !Ref FirstNamespace - !Ref 'AWS::NoValue' - !If - HasExcludeNamespace2 - Namespace: !Ref SecondNamespace - !Ref 'AWS::NoValue' - !If - HasExcludeNamespace3 - Namespace: !Ref ThirdNamespace - Ref: 'AWS::NoValue' Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: Required Parameters: - GlobalPrefix - GlobalEnvironment - ApiKey - DdSite - Label: default: Optional Parameters: - FilterMethod - FirstNamespace - SecondNamespace - ThirdNamespace

1. CodeCommit AWS環境でGitリポジトリを利用できるサービス。GitHubみたいなもの。 実体としてはバージョニングされたS3でcodepipeline-ap-northeast-1-000011112222のようなバケットが作成されている。 1-1. CodeCommitでコード管理 前提 Admin権限のIAMユーザを作成している。(adminである必要はないがとりあえず面倒なので) コンソールに上記ユーザでサインインしている。 gitインストール済。 ■ 秘密鍵と公開鍵の作成 $ ssh-keygen -t rsa -C "hogehoge@gmail.com" Generating public/private rsa key pair. Enter file in which to save the key (/Users/hoge/.ssh/id_rsa): ./codecommit_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in codecommit_rsa. Your public key has been saved in codecommit_rsa.pub. The key fingerprint is: SHA256:SG3cs50mRNPFKE0AMJP0s0rij9QUnh3fQRhaPENVSsY hogehoge@gmail.com The key's randomart image is: +---[RSA 2048]----+ | .* + .B#| | = *.%. o.oB| ■ IAMユーザと紐付け IAM > ユーザ > 自分のユーザ名 > 認証情報(タブ) > AWS CodeCommitのSSHキー に公開鍵をUploadする。以下で中身をまるっとコピペする。 $ cat ~/.ssh/codecommit_rsa.pub アップロードするとSSHキーIDが発行される。 ■ configファイルの設定 必須ではないと思うが設定しておくと便利。 UserはIAMにキーをUploadしたときに発行されるSSHキーID。 .ssh/cinfig Host git-codecommit.*.amazonaws.com User APKA**************** IdentityFile ~/.ssh/codecommit_rsa configファイルを作成した場合はアクセス権限を666にする。 ■ リポジトリ作成 CodeCommitコンソールからリポジトリを作成をクリックし、リポジトリ名を入力。 ローカルにクローンしたいので、接続した後クローン。 今回はSSH接続する。(CodeCommitコンソールから丸ごとコピペでok) $ ssh git-codecommit.リージョン名.amazonaws.com Warning: Permanently added the RSA host key for IP address '**.***.***.**' to the list of known hosts. Enter passphrase for key '/Users/hogehoge/.ssh/codecommit_rsa': You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit. Interactive shells are not supported.Connection to git-codecommit.ap-northeast-1.amazonaws.com closed by remote host. Connection to git-codecommit.ap-northeast-1.amazonaws.com closed. $ git clone ssh://git-codecommit.リージョン名.amazonaws.com/v1/repos/リポジトリ名 Cloning into 'リポジトリ名'... Enter passphrase for key '/Users/hogehoge/.ssh/codecommit_rsa': warning: You appear to have cloned an empty repository. # Reactアプリを作成 $ npx create-react-app testapp $ tree -L 1 . ├── README.md ├── node_modules ├── package-lock.json ├── package.json ├── public └── src $ git add . $ git commit -m "first commit" $ git push 2. CodeBuild ビルド環境。 指定の場所からビルド対象のファイルを取得し、コンテナを立てて指定されたコマンドを順次実行する。 ここで指定するコマンド等はbuildspec.ymlで定義し、ビルド対象のファイルと同じ場所に置いておく。 ビルド結果などの成果物(アーティファクト)を指定のS3に送る。 2-1. CodeCommitのコードをビルドする。 ■ buildspec.yml作成 ビルドの設定を書くファイル。 設定できることは、基本以下3つ。 パラメータや環境変数の設定 インストール時、ビルド前、ビルド時、ビルド後の各フェーズでの設定/実行したいコマンド。 出力の設定。ビルドした成果物(アーティファクト)の何をどこに送るのか。 今回は以下のように指定。使用するランタイムを指定し、npmの準備。build階層以下のディレクトリだけを全て送る。 buildspec.yml version: 0.2 phases: install: runtime-versions: nodejs: 10 pre_build: commands: - npm update -g npm - npm install build: commands: - npm run build artifacts: files: - 'build/**/*' (なお、拡張子がyamlだと認識されなかったみたいな話を聞いたことがある。試してはいない。) 上記の設定ファイルを最上位の階層に配置してCodeCommitに追加する。 $ tree -L 1 . ├── README.md ├── buildspec.yml # <- New! ├── node_modules ├── package-lock.json ├── package.json ├── public └── src $ git add . $ git commit -m "add buildspec" $ git push ■ ビルドプロジェクトの作成 「ソース」ではCodeCommitの自身のリポジトリを選択する。なお、ここでビルド対象をどれにするかを設定できる。今回はmasterブランチを対象として追いかけてもらう。 「環境」はDockerコンテナのスペックなどを指定する。特になんでもいい。 osはUbuntu、イメージはStandardで最新のversionを選択。 「Buildspec」では先ほど作成したファイルがどこにあるかを指定する。(デフォルトはルートから探してくれる。) 「アーティファクト」では出力先を指定。S3。バケットはあらかじめ作っておいてそれを指定する。 「アーティファクトのパッケージ化」はzipを指定。この先使うCodeDeployはzipしてないと受け付けてくれないので。 ■ ビルドを手動実行 コンソールからビルド実行。 正常に終了するとS3の出力先バケットにzipが作成されている。試しにダウンロードして中を見てみると正しくビルドできているかを確認できる。 3. CodeDeploy デプロイ処理の実行。 指定の場所からファイルを取得し、EC2やオンプレサーバにデプロイする。AutoScalingしている場合はELBなど関連のリソースもいい感じに調整できる。 デプロイ先のEC2にAgentを仕込んおくことが前提であり、デプロイの実行をメインで行うのはこのAgent自身なので、ここでの設定はどこにArtifactがあるか位しか設定しない。 取得したArtifactの中の何をどのパスにデプロイするかなどはappspec.ymlで定義される。 つまり、EC2には事前にAgentを入れ、S3にアクセスするロールが当たっていないとデプロイに失敗する。 用語整理 デプロイメント(デプロイ) : 1回1回のデプロイ自体を指す。それぞれのデプロイにはランダムな英数字のIDが振られ、各デプロイを区別できるようになっている。CodeDeployのデプロイメントからこれらのステータス(成功/失敗)や内容を閲覧することができる。 デプロイグループ : デプロイする先(タグで指定)や、デプロイ方法(Blue&Greenなど)を指定したもの。 リビジョン : デプロイに必要なデータ類をパッケージにした一まとまりのもの。CodeDeployではデプロイの仕方やファイル類を一つにまとめたリビジョンという形でデプロイ対象のEC2に配布し、中のAgentがデプロイを行う。 アプリケーション : デプロイグループとリビジョンを束ねたもの。 3-1. ビルドしたファイルをEC2にデプロイする。 ■ デプロイ先のEC2の用意 Amazon Linux 2 AMI (HVM), SSD Volume Type インスタンスサイズは何でもいい。t2.microで実施。 IAMロールはS3FullAccessとCodeDeployFullAccessを当てたロールを当てる。(本来はAmazonEC2RoleforAWSCodeDeployポリシーをアタッチしたロールを当てるので十分らしい。) ポート80は開けておく。デプロイの確認としてブラウザからアクセスするため。 CodeDeployからデプロイするためにエージェントを入れる必要があるためSSHで入り設定。ついてにWebサーバも用意。 sshでEC2に入りセットアップ $ ssh -i Download/xxx.pem ec2-user@xx.xxx.xxx.xxx $ sudo yum update -y $ sudo yum install httpd -y $ sudo service httpd start Starting httpd: [ OK ] $ sudo yum install ruby $ sudo yum install wget $ cd /home/ec2-user $ wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/install $ chmod +x ./install $ sudo ./install auto $ sudo service codedeploy-agent status The AWS CodeDeploy agent is running as PID 14515 $ sudo chkconfig httpd on SSHするのが面倒であれば高度な詳細で初回起動時に実行するコマンドを列挙してもOK #!/bin/sh sudo yum update -y sudo yum install ruby -y sudo yum install wget -y cd /home/ec2-user wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/install chmod +x ./install sudo ./install auto sudo yum install httpd -y sudo service httpd start sudo chkconfig httpd on なお、AmazonLinux2ではデフォルトでSSMagentが含まれているので、EC2のロールにAmazonEC2RoleforSSMをアタッチした状態で起動するとSSMのセッションマネージャからアクセス可能になる。(=22番ポートを開けなくてもssm-userとしてコンソールからインスタンスにアクセスできるようになる。) ■ appspec.yml作成 Artifactの中身のbuild以下を丸ごと/var/www/html配下に置く。 appspec.yml version: 0.0 os: linux files: - source: /build/ destination: /var/www/html $ tree -L 1 . ├── README.md ├── appspec.yml # <- New! ├── build ├── buildspec.yml ├── node_modules ├── package-lock.json ├── package.json ├── public └── src ■ buildspec.yml編集 EC2ではappspec.ymlに従ってデプロイ処理を行うので、CodeDeployに指定したS3バケットにはappspec.ymlが含まれていないといけない。 ビルド時の出力にappspec.ymlを含めるように追記する。 build.yml version: 0.2 phases: install: runtime-versions: nodejs: 10 pre_build: commands: - npm update -g npm - npm install build: commands: - npm run build artifacts: files: - 'build/**/*' - 'appspec.yml' # <- New! ■ アプリケーション(CodeDeploy)の作成 コンソール上でアプリケーション名を決めて作成。 設定項目 設定内容/値 アプリケーション名 ApplicationName コンピューティングプラットフォーム EC2/オンプレミス ■ デプロイグループ(CodeDeploy)の作成 上記で作成したアプリケーションを選択し、同じくコンソールからデプロイグループの作成を選択。 AWSCodeDeployRoleポリシーをアタッチしたIAMロールを作成する。 デプロイグループを作成する。 設定項目 設定内容/値 デプロイグループ名 DeployGroupName サービスロール 上記作成したIAMロールを指定 環境設定 EC2/オンプレミス キー Name 値 デプロイ対象のインスタンス名 デプロイ設定 CodeDeployDefault.OnceAtTime Load balancer ロードバランシングを無効にする ■ ビルド手動実行&デプロイ手動実行 $ git add . $ git commit -m "add appspec" $ git push コンソールよりビルドを実行(先ほどと同じ手順)。S3のzipファイルが上書きされ更新される。 続いて、CodeDeployのデプロイメントグループからデプロイを作成。ここではArtifactの場所(S3のバケット名とzip名)のみ指定して作成(=デプロイ実行) 成功し、EC2の80番ポートにアクセスしてReactのサンプルアプリが見れたら確認OK 4. CodePipeline コードのソースへのアクションをトリガに種々の処理を走らせる。 CodeCommitへのPushをトリガとしてEC2へのデプロイを自動化する。 4-1. CodePipelineの作成 (&実行) CodePipelineを作成する。 パイプライン名を入力し、サービスロールはここで作成する。 ソースやビルド環境、デプロイ先はこれまでに作成したものを指定する。 作成完了するとデプロイされる。また、これ以降はgit pushによってもCodeCommitのmasterブランチを更新することでもデプロイが走る。コンソールから成功したことを確認したらブラウザからEC2にアクセスしてみる。 4-2. 承認プロセスの追加 好き勝手デプロイされると困るのでビルド後にデプロイするまでに承認を追加する。 作成したパイプラインの編集からステージを追加。→アクショングループの追加を選択し、アクションプロバイダから手動承認を選択。 なお、SNSを利用してE-mailなどで承認リクエストを送る場合は予めSNSトピックとサブスクリプションの設定を行っておくこと。 他は必要項目を適当に埋めて保存するだけ。 試しに背景を変えてpushし、承認メールが来るかを確認。 $ git add . $ git commit -m "change background-color" $ git push ここでのメッセージはCodePipelineの履歴から見れる。 なお、誰が承認したのかのユーザ名などはここには出ないのでCloudTrailのイベント履歴からPutApprovalResultイベントの実行ユーザを確認すると見れる。 また、承認ステージで却下を選択されるとパイプラインは承認ステージで失敗したとなる。 4-3. 再デプロイ(ロールバック) 一度デプロイしたパッケージに不具合が見つかり以前のversionにロールバックする必要があるような場合に実施する。 CodePipelineは一連の実行を管理するので、部分的に実行したりはできないため、CodeDeployから過去のデプロイを直接実行(=デプロイのみ実行)する。 CodeDeployで過去にデプロイしたリビジョンはzipでS3に保存されている(デプロイ履歴の一覧から閲覧できる)。 これを再利用して新たにデプロイし直すことで実質過去のversionにロールバックする。 デプロイ履歴からロールバック対象を選択しコードのデプロイを実行。 4-4. AutoScalingGroup&EC2のデプロイ(ELBなしver) AutoScalingGroup(ASG)に属するEC2にデプロイする場合。 ■ ASGの起動テンプレート作成 大事なのは高度な設定において毎回起動時にwebサーバを起動できるようにすることと、agentを入れておくこと。それ以外はなんでも。 設定項目 設定内容/値 起動テンプレート名 任意の名前 AutoScaling のガイダンス ☑︎ AMI 任意(ここではAmazonLinux2) インスタンスタイプ 任意(ここではt2.micro) キーペア(ログイン) 任意 ネットワーク設定-VPC デフォルト ネットワーク設定-SG 任意 高度な詳細-IAMインスタンスプロフィール S3へのアクセス権を持つIAM ユーザーデータ 以下 #!/bin/sh sudo yum update -y sudo yum install ruby -y sudo yum install wget -y cd /home/ec2-user wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/install chmod +x ./install sudo ./install auto sudo yum install httpd -y sudo service httpd start sudo chkconfig httpd on ■ ASG作成 特にCICDに特化した設定はなし。 設定項目 設定内容/値 ASG名 任意 起動テンプレート 上記で作成したもの インスタンスの購入オプション 起動テンプレートに準拠する(デフォルト) ネットワーク設定-VPC デフォルト ネットワーク設定-サブネット 全て選択 ロードバランシング なし(デフォルト) グループサイズ 希望1 (最小0〜最大2) スケーリングポリシー なし ■ アプリケーション(CodeDeploy)の作成 →前と同じ ■ デプロイメントグループ作成(変更点のみ) EC2へのデプロイと大差ない。デプロイ対象をASGにするだけ。 設定項目 設定内容/値 デプロイタイプ インプレース(Blue/Greenを選ぶとELB必須となってしまう) 環境設定 Amazon EC2 Auto Scaling グループ (上で作成したASGを選択) Load balancer 無効 ■ デプロイ作成 →前と同じ デプロイ後にASGのインスタンス数を増やすと、ちゃんとデプロイ後の設定でデプロイされていることが確認できる。 なお、ASGのコンソールを見ると、以下のようなイベントが紐づけられているのが確認できる。 CodeDeployのターゲットとしてASGを指定するとスケールアウトの際に新規インスタンスにLifeCycleHook(CodeDeploy-managed-automatic-launch-deployment-hook)を自動的に登録してくれるため、ASGのインスタンスにcodedeploy-agentを起動する設定のみしておけば良い。 ■ CodePipelineの設定。 4-3と同じように設定する。CodeCoomitとCodeBuildはそのまま、上で作成したCodeDeployを指定する。 4-5. AutoScalingGroup&EC2のデプロイ(ELBありver) ■ IAMへのASGアクセス権限追加 CodeDeployにアタッチするロールには以下のポリシーが必要。(今回はEC2FullAccess、IAMFullAccessを与えて実行した。) AWSCodeDeployRole ec2:RunInstances ec2:CreateTags iam:PassRole ■ ターゲットグループの作成 設定項目 設定内容/値 プロトコル HTTP ポート 80 ■ ALBの作成 設定項目 設定内容/値 スキーム インターネット向け リスナー HTTP 80 AZ 全て選択 セキュリティグループ(SG) 任意のSGを設定。 ターゲットグループ 上記で作成したもの ■ ASGの作成(ELBに紐づける) ロードバランサの選択のところで既存のロードバランサーにアタッチを選択する。 ASGのSGには上で設定したALBのSGからのport80番へのアクセスを許可しておく。 ■ アプリケーション(CodeDeploy)の作成 →前と同じ ■ デプロイメントグループ作成(変更点のみ) 設定項目 設定内容/値 デプロイタイプ Blue/Green 環境設定 Amazon EC2 Auto Scaling グループの自動コピー (上で作成したASGを選択) デプロイ設定 すぐにトラフィックを再ルーティングデプロイグループの置き換え元インスタンスを終了(時間指定) デプロイ設定 CodeDeployDefault.AllAtOnce Load balancer Application Load Balancer またはNetwork Load Balancer ■ デプロイ作成 →前と同じ デプロイ完了後、ALBに対してブラウザからアクセスするとデプロイ後のReactの画面が待ち受けていることがわかる。 ■ CodePipelineの作成 4-3/4-4と同じように設定する。CodeCoomitとCodeBuildはそのまま、上で作成したCodeDeployを指定する。 なお、これまでに設定したパイプラインも動いてしまうのでそれを止めておくには移行を無効にするを押すとpendingにできる。 pendingにしたデプロイがあるとパイプラインとしては進行中のステータスとなるので、このデプロイを破棄したい場合はインバウンド実行の詳細から停止して中止を選択する。パイプラインの表示上はこの実行が残るが、ステータスは停止となっており、次にパイプラインを走らせると中止した実行は表示されなくなる。 4-6. EC2/ELB/ASG構成で再デプロイする。 EC2インスタンスに直でデプロイする時と同じように旧リビジョンに再デプロイしてみる。 同じように履歴から戻したいリビジョンを選らび再度デプロイすることで実行可能。

はじめに 作成したアプリをAWSにデプロイしようと作業しており、「$ bundle exec rake db:migrate RAILS_ENV=productionコマンドを入力した際に発生したエラーを解決するまでの道のりです。 同じエラー内容が出ている方の一助になれれば幸いです。 エラー解決に向けて unicornをインストールして、「$ bundle exec rake db:migrate RAILS_ENV=production」コマンドを入力すると、 ec2-user@ip-10-0-0-42 アプリ名]$ bundle exec rake db:migrate RAILS_ENV=production rake aborted! ActiveRecord::AdapterNotSpecified: 'production' database is not configured. Available: ["default", "development", "test"] とエラー表示がされました。 どうも'production' databaseに問題がありそうです。そこでdatabase.ymlを確認してみます。 config/database.yml 〜省略〜 production: <<: *default database: <%= Rails.application.credentials.db[:database] %> username: <%= Rails.application.credentials.db[:username] %> password: <%= Rails.application.credentials.db[:password] %> socket: <%= Rails.application.credentials.db[:socket] %> production databaseあるじゃん！と思い、別の要因を探っていました。 しかし原因はymlファイルのインデントの付け方にありました。 正しくは以下のようになります。 config/database.yml 〜省略〜 production: <<: *default database: <%= Rails.application.credentials.db[:database] %> username: <%= Rails.application.credentials.db[:username] %> password: <%= Rails.application.credentials.db[:password] %> socket: <%= Rails.application.credentials.db[:socket] %> ここでの注意点は、インデントはタブではなく、半角スペースを指定してあげてください。 もしここが上手くいっていないと、「Please note that YAML must be consistently indented using spaces. Tabs are not allowed. 」とエラーになってしまいます。 これで再度「bundle exec rake db:load_config RAILS_ENV=production」コマンドを入力したところ、またエラー表示が…。 == 20210320002528 CreateItems: migrating ====================================== -- create_table(:items) rake aborted! StandardError: An error has occurred, all later migrations canceled: Mysql2::Error: Failed to open the referenced table 'categories': CREATE TABLE `items` (`id` bigint NOT NULL AUTO_INCREMENT PRIMARY KEY, `name` varchar(255), `image` varchar(255), `category_id` bigint, `created_at` datetime NOT NULL, `updated_at` datetime NOT NULL, INDEX `index_items_on_category_id` (`category_id`), CONSTRAINT `fk_rails_89fb86dc8b` FOREIGN KEY (`category_id`) REFERENCES `categories` (`id`) ) /var/www/rails/men-skincare/db/migrate/20210320002528_create_items.rb:3:in `change' /home/ec2-user/.rbenv/versions/2.5.3/bin/bundle:23:in `load' /home/ec2-user/.rbenv/versions/2.5.3/bin/bundle:23:in `<main>' Caused by: ActiveRecord::StatementInvalid: Mysql2::Error: Failed to open the referenced table 'categories': CREATE TABLE `items` (`id` bigint NOT NULL AUTO_INCREMENT PRIMARY KEY, `name` varchar(255), `image` varchar(255), `category_id` bigint, `created_at` datetime NOT NULL, `updated_at` datetime NOT NULL, INDEX `index_items_on_category_id` (`category_id`), CONSTRAINT `fk_rails_89fb86dc8b` FOREIGN KEY (`category_id`) REFERENCES `categories` (`id`) ) /var/www/rails/men-skincare/db/migrate/20210320002528_create_items.rb:3:in `change' /home/ec2-user/.rbenv/versions/2.5.3/bin/bundle:23:in `load' /home/ec2-user/.rbenv/versions/2.5.3/bin/bundle:23:in `<main>' Caused by: Mysql2::Error: Failed to open the referenced table 'categories' /var/www/rails/men-skincare/db/migrate/20210320002528_create_items.rb:3:in `change' /home/ec2-user/.rbenv/versions/2.5.3/bin/bundle:23:in `load' /home/ec2-user/.rbenv/versions/2.5.3/bin/bundle:23:in `<main>' Tasks: TOP => db:migrate (See full trace by running task with --trace) うーん、itemsテーブルの作成時にエラーが発生しているようです。 もっと詳しくエラー内容を確認してみると、itemsテーブルを作ろうとしている時に、categoriesテーブルの参照がないよと言われています。 itemsテーブルとcategoriesテーブルの作成順番がうまくいっていないようなので、一度categoryモデルごと削除、再度マイグレーションして、無事エラー解消することができました。 終わりに ymlファイルのインデント規約に関しては知らなかったので良い勉強となりました。 もっとLinuxの知識をつける必要があると感じました。

前提 ・AWS ソリューションアーキテクトアソシエイト試験の過去問で間違えた or 自信がなかった質問を元に、確認した内容を記録していきます。 ・過去問の内容をこのページに掲載するのは安全側に倒して載せません。(copyright 的に) ・最終的にはざっくりとサービスや分野毎にまとめられたらいいかなと思っています。（適宜更新予定） そもそも AWS ソリューションアーキテクトアソシエイト試験ってなあに？ 公式サイトをご参照。 試験時間 130 分、65 問のアソシエイト認定レベルの試験。一問あたり 2 分で解かないといけないんですね。あまりゆっくりとは考えている時間はなさそうです。 1000 点満点中 720 点が合格ライン。分割で勉強するときも解いた問題のうち 8 割正解していることを目標にすれば良さそうですね。 S3 / Glacier Glacier ・Glacier ストレージクラスに格納したオブジェクトの復元は 3 つのオプションから選択することができ、最も早く取り出せる高速取得を使用すると 1 - 5 分で復元できる。（意外と早い！） ・ちなみに通常の復元だと 3 - 5 時間程とのこと。 Glacier Deep Archive ・Glaceir Deep Archive ストレージクラスに格納したオブジェクトの復元は 12 時間以内に可能。（思ったより短かった) ・スタンダードクラスの S3 をバイパスする必要はなく、PUT 時に直接 Glaceir Deep Archive ストレージクラスに格納することが可能。 $ aws s3api put-object --bucket <バケット名> --key <キー名> --storage-class DEEP_ARCHIVE ・復元の仕方は restore-object コマンドを使用。指定した期間のみコピーができる。 $ aws s3api restore-object --bucket <バケット名> --key <キー名> --restore-request '{"Days":<日数>,"GlacierJobParameters":{"Tier":"Standard"}}' ネットワーク セカンダリ ENI を使用するユースケース 2 本足の意義は？と思っていたが、公式ドキュメントにも記載があった。低予算で可用性の高いソリューションを作成するのに使用できるとのこと。 低予算で可用性の高いソリューションを構築する 特定の機能にサービスを提供しているインスタンスのいずれかが機能しなくなった場合は、そのネットワークインターフェイスを同じ役割で構成された交換用またはホットスタンバイ用のインスタンスにアタッチすることで、サービスを迅速に回復できます。たとえば、データベースインスタンスや NAT インスタンスなどの重要なサービスに対するプライマリまたはセカンダリのネットワークインターフェイスとしてネットワークインターフェイスを使用することができます。そのインスタンスが機能しなくなった場合、お客様 (通常はお客様に代わって実行されるコード) がネットワークインターフェイスをホットスタンバイ用のインスタンスにアタッチすることができます。インターフェイスでは、プライベート IP アドレス、Elastic IP アドレス、および MAC アドレスがそのまま維持されるため、交換用のインスタンスにネットワークインターフェイスを接続するとすぐに、ネットワークトラフィックはスタンバイ用のインスタンスに流れ始めます。インスタンスに障害が発生してから、ネットワークインターフェイスがスタンバイ用のインスタンスにアタッチされるまで、一時的な接続断が発生しますが、VPC ルートテーブルや DNS サーバーに変更を加える必要はありません。 SQS 一度ちゃんと勉強しないとダメそうですね。

cdkを使ってリソース定義しようとしたらメソッドにtagsが用意されてない！でもCloudformationでは対応してるよ〜っていうときにタグを入れる方法 リソース名が気に入らないときの上書きにも使える ①Aspects.ofを使う ネットワークACLにNameタグをつける例 stack.py # vpcの定義は省略 nacl = ec2.NetworkAcl(self, 'id', vpc=vpc, subnet_selection=ec2.SubnetSelection( subnet_type=ec2.SubnetType.PUBLIC ), network_acl_name='nacl' ) core.Aspects.of(nacl).add(core.Tag("Name", 'your-public-nacl')) サブネットにまとめてNameタグをつける例 stack.py vpc = ec2.Vpc(self, 'vpc', max_azs=2, cidr='10.0.0.0/24', subnet_configuration=[ec2.SubnetConfiguration( subnet_type=ec2.SubnetType.PRIVATE, name="Private", cidr_mask=27 ), ec2.SubnetConfiguration( subnet_type=ec2.SubnetType.ISOLATED, name="Isolated", cidr_mask=27 ), ec2.SubnetConfiguration( subnet_type=ec2.SubnetType.PUBLIC, name='Public', cidr_mask=27, ) ], ) subnets_list = [vpc.public_subnets, vpc.private_subnets, vpc.isolated_subnets] for subnets in subnets_list: for isubnet in subnets: core.Aspects.of(isubnet).add(core.Tag("Name", 'your-subnet-name')) ②apply_aspectを使う (古いversionの人向け) ネットワークACLにNameタグをつける例 stack.py # vpcの定義は省略 nacl = ec2.NetworkAcl(self, 'id', vpc=vpc, subnet_selection=ec2.SubnetSelection( subnet_type=ec2.SubnetType.PUBLIC ), network_acl_name='nacl' ) nacl.node.apply_aspect(core.Tag("Name", 'your-public-nacl')) サブネットにまとめてNameタグをつける例 stack.py vpc = ec2.Vpc(self, 'vpc', max_azs=2, cidr='10.0.0.0/24', subnet_configuration=[ec2.SubnetConfiguration( subnet_type=ec2.SubnetType.PRIVATE, name="Private", cidr_mask=27 ), ec2.SubnetConfiguration( subnet_type=ec2.SubnetType.ISOLATED, name="Isolated", cidr_mask=27 ), ec2.SubnetConfiguration( subnet_type=ec2.SubnetType.PUBLIC, name='Public', cidr_mask=27, ) ], ) subnets_list = [vpc.public_subnets, vpc.private_subnets, vpc.isolated_subnets] for subnets in subnets_list: for isubnet in subnets: isubnet.node.apply_aspect(core.Tag("Name", "your-subnet-name"))

結論 awsのconfigファイルに削除したプロファイルを再記述し、既存のロールなどと紐づける。 やらかした＼(^o^)／ｵﾜﾀ Amplify CLIにて、amplify initを行った際に設定したaws configファイルのプロファイルを書き換えてしまい、既存の環境にアクセスできなくなりました。 具体的に もともと以下のプロファイルが記載されていました。 [profile amplify_cli] role_arn = arn:aws:iam::012345678910:role/role_amplify_cli source_profile = default region = ap-northeast-1 上記をリネームとリソース整理のために変更しました。 [profile Amp_CLI] role_arn = arn:aws:iam::012345678910:role/role_Amp_CLI source_profile = default region = ap-northeast-1 Access Deniedが発生 Amplifyプロジェクトに変更を加えていざamplify pushしたら、 An error occurred during the push operation: Access Denied と言われてしまい、変更をプッシュできなくなってしまいました。 --profile <新しいプロファイル>を試す --profileオプションつければ行けるかと思いました。 amplify push --profile Amp_CLI 結果、 An error occurred during the push operation: Access Denied ダメでした。 amplify initしてみる じゃあinitからやり直せるかと思い、 amplify init を実行しました。 Could not initialize 'dev': Access Denied ダメでした。 amplify init --profile Amp_CLI でも結果は変わりませんでした。 amplify configureしてみる amplify configureでユーザーリセットを試すも、 Specify the username of the new IAM user: で新しいユーザーを作る設定しかなく、断念しました。 configファイルに手動で復元してみる そんなことで復元できないと思いつつ、削除したプロファイル名を再記述し、既存のロールと紐づけてみました。 [profile amplify_cli] role_arn = arn:aws:iam::012345678910:role/role_Amp_CLI source_profile = default region = ap-northeast-1 これで amplify push --profile role_amplify_cli を実行したところ、何とプッシュが成功しました！ Amplify CLIに紐づいているのはプロファイル名だけだったようで、名前を復元して適切なアクセス権限を持つロールを紐づければ既存環境にアクセスできました。 余談 実はinitがうまくいかなかった時点でサポートとチャットでやり取りしていたのですが、チャットしながらconfigをいじっていたら復元できてしまいましたw それでも、「Amplify CLIでユーザープロファイルを変更したい」という質問に、サポートの方からは「設定したプロファイルを変更可能かを調査してみます」とのご返答を頂き、さすがAWSサポートだと思いました！ 本当に課題解決型のアプローチは心強いですし、毎回勉強になります。 まとめ Amplify CLIで設定したプロファイルをリネームのために削除してしまうというやらかしでした。簡単に復元できたのでよかったですが、安易に削除する前に影響範囲の考慮が必要だと実感しました。 このやらかしがどなたかの参考になれば幸いです。 追記 サポートから設定済みプロファイルの変更方法も教えていただきました。 amplify configure project を実行することで可能でした。 改めてサポートに感謝します！

AWS超個人的メモ Amazon Cloud Watch 　監視メトリクス ### APIGatewayメトリクス 4XXError：指定された期間に取得されたクライアント側エラーの数。 5XXError：指定された期間に取得されたサーバー側エラーの数。 CacheHitCount：指定された期間内に API キャッシュから配信されたリクエストの数。 CacheMissCoun：API キャッシュが有効になっている特定の期間における、バックエンドから提供されたリクエストの数。 Count：指定された期間内の API リクエストの合計数。 IntegrationLatency：API Gateway がバックエンドにリクエストを中継してから、レスポンスを受け取るまでの時間。 Latency：API Gateway がクライアントからリクエストを受け取ってから、クライアントにレスポンスを返すまでの時間。 Amazon DynamoDB 属性サブネットの取得 アトミックカウンター DynamoDBではUpdateItem用のアトミックカウンターの実装が可能 他のDBサービスではアトミックカウンターの実装は出来ないので注意 CLIオプション --projection-expression データの有効期限 TTL（有効期限）を設定することでDynamoDBのテーブルデータを自動的に失効させて、保存されたデータを自動的に削除させることができる。 プライマリキーの最大設定数 DynamoDBのテーブルデータに設定できるプライマリキーは最大で2つ。 API BatchGetItem API BatchWriteItem API 読み込みキャパシティーユニット（RCU）の計算方法 1 つの読み込みキャパシティーユニット（RCU）は、最大サイズ 4 KB の項目に対して、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果整合性のある読み込みを実施できます。 例えば、10 ユニットのプロビジョニングされた読み取りキャパシティーでテーブルを作成したとします。これにより、最大 4 KB の項目に対して、1 秒あたり 10 回の強い整合性のある読み込み、または 20 回の結果的に整合性のある読み込みを行えます。 4 KB を超える項目に対しては、より多くのRCUを消費します。たとえば、8 KB (4 KB × 2) の項目の強い整合性のある読み込みを実施する場合は、2 ユニットのRCUを消費します。同じ項目の結果的に整合性のある読み込みは、RCUを 1 ユニットしか消費しません。 したがって、10 ユニットのプロビジョニングされたRCUによって 20 回の結果整合性のある読み込み処理を行えるため、10RCUが正しい設定となります。 書き込みキャパシティーユニット（WCU）の計算方法 1 つの書き込みキャパシティーユニット（WCU）は、最大サイズが 1 KB の項目に対して、1 秒あたり 1 回の書き込みを表します。 例えば、10 ユニットのプロビジョニングされたWCUでテーブルを作成します。これにより、1 秒あたり最大でサイズが 1 KB の項目に対して、1 秒あたり 10 回の書き込みが実施できます。 書き込みの項目サイズは、次の 1 KB の倍数に切り上げられます。たとえば、500 バイトの項目の書き込みは、1 KB の項目の書き込みと同じスループットを消費します。 したがって、30 ユニットのプロビジョニングされたWCUのテーブルに対して、 1 秒あたり最大でサイズ1 KB の項目対して、1 秒あたり 30 回の書き込みを行えます。 セカンダリインデックス ローカルセカンダリインデックス - グローバルセカンダリインデックス Amazon ECS タスク配置戦略 Binpack CPU またはメモリの最小利用可能量に基づいてタスクを配置します。これにより、使用するインスタンス数を最小限に抑えます Random タスクをランダムに配置します。 Spread 指定された値に基づいてタスクを均等に配置します。有効な値は instanceId (または同じ効果を持つ host)、または attribute:ecs.availability-zone などのコンテナインスタンスに適用される任意のプラットフォームまたはカスタム属性です。サービスタスクはそのサービスからのタスクに基づいて分散されます。スタンドアロンタスクは、同じタスクグループからのタスクに基づいて分散されます。 --- ## Amazon ElastiCache ElastiCache Memcached ElastiCache Redis アプローチ 遅延読み込み戦略 必要なときにのみキャッシュにデータを読み込むキャッシュ戦略です。 書き込みスルー戦略 データがデータベースに書き込まれると常にデータを追加するか、キャッシュのデータを更新します。 TTL の追加 有効期限 (TTL) 値を設定することで一定期間でデータ項目を失効させることができます。遅延読み取りはデータが古くなる可能性がありますが、空ノードによる障害は発生しません。書き込みスルーでは常に新しいデータとなりますが、空ノードの障害が発生して、過剰なデータがキャッシュに入力されることがあります。各書き込みに有効期限 (TTL) 値を追加することで、各戦略の利点を得ることができます。同時に、余分なデータでキャッシュが乱雑になることを回避できます。 したがって、書き込みスルー戦略では、データがデータベースに書き込まれると常にデータを追加するか、キャッシュのデータを更新することで、古いキャッシュを利用しないように実装ができます。また、各書き込みに有効期限 (TTL) 値を設定することで、古いキャッシュを利用しないようにできます。 Amazon Kinesis Data Stream デフォルトのデータ保持期間 Kinesisデータストリームのデフォルトのデータ保持期間は24hで設定されている。 保持期間の最大値は168時間まで設定可能 シャード Amazon RDS MYSQLのモニタリングログ 一般ログ： mysqld の実行内容の一般的な記録です。サーバーは、クライアントが接続または接続解除したときに情報をこのログに書き込み、クライアントから受け取った各 SQL ステートメントをログに記録します。一般クエリーログは、クライアント側でエラーが疑われるとき、クライアントが mysqld に送信した内容を正確に知りたい場合に役立ちます。 エラーログ エラーログには mysqld が開始および停止された時期を示す情報と、サーバーが実行中に発生したあらゆるクリティカルエラーが格納されます。自動的にチェックまたは修復することが必要なテーブルが mysqld で検出された場合、エラーログに警告メッセージが書き込まれます。 スロークエリログ スロークエリーログは、実行に要した時間が long_query_time 秒を超え、少なくとも min_examined_row_limit 行を検査する必要があった SQL ステートメントで構成されます。long_query_time の最小値およびデフォルト値は、それぞれ 0 および 10 です。値はマイクロ秒の精度まで指定できます。ファイルへのロギングの場合、時間はマイクロ秒の部分も含めて書き込まれます。テーブルへのロギングの場合、時間の整数部のみ書き込まれ、マイクロ秒の部分は無視されます。 --- ## AWS API Gateway API Gateway統合タイプ AWS AWS統合は、API は AWS のサービスアクションを公開します。AWS 統合では、統合リクエストと統合レスポンスの両方を設定し、メソッドリクエストから統合リクエストへの、また統合レスポンスからメソッドレスポンスへの、データマッピングを設定する必要があります。 AWS_PROXY AWS_PROXY統合には様々な用途に柔軟に利用できる合理化された統合設定があり、API メソッドを Lambda 関数呼び出しアクションと統合できます。この統合は、統合Lambda 関数との間の直接的なやり取りに依存します。Lambda プロキシ統合とも呼ばれ、ユーザーが統合リクエストまたは統合レスポンスを設定することはありません。API Gateway は、クライアントから受け取ったリクエストをバックエンドの Lambda 関数への入力として渡します。統合 Lambda 関数は、この形式の入力を受け取り、使用可能なすべてのソースからの入力 (リクエストヘッダー、URL パス変数、クエリ文字列パラメータ、該当する本文など) を解析します。その後、こちらの出力形式に従って結果を返します。 HTTP HTTP統合は、API がバックエンドの HTTP エンドポイントを公開することを可能にします。HTTP 統合 (HTTP カスタム統合とも呼ばれます) では、統合リクエストと統合レスポンスの両方を設定する必要があります。メソッドリクエストから統合リクエストへの、また統合レスポンスからメソッドレスポンスへの、データマッピングを設定する必要があります。 HTTP_PROXY HTTP_PROXY統合では、クライアントは 1 つの API メソッドで合理化された統合設定を使用して、バックエンドの HTTP エンドポイントにアクセスできます。ユーザーが統合リクエストまたは統合レスポンスを設定することはありません。API Gateway は、クライアントから受け取ったリクエストを HTTP エンドポイントに渡し、HTTP エンドポイントから送り出されたレスポンスをクライアントに渡します。このようにHTTPエンドポイントを介して対話が行われるため、クライアントとバックエンドがAPI Gatewayの介入なしで直接対話することができます。 MOCK MOCK統合では、API Gateway はリクエストをさらにバックエンドに送信することなく、レスポンスを返します。このタイプの統合は、バックエンドの使用料金が発生することなく、統合設定のテストに使用したり、API の共同開発に使用したりできるためAPI のテストに活用できます。共同開発では、チームは MOCK 統合を使用して、他のチームが所有する API コンポーネントのシミュレーションを設定することで、自分たちの開発成果を区分することもできます。また、CORS 関連のヘッダーを返して、API メソッドが CORS へのアクセスを許可するようにもできます。 AWS CloudFormation ### SAMの利用 CloudFormationテンプレートを利用してLambda関数を利用したサーバーレスアプリケーションのインフラを構成するためには、CloudFormationテンプレートのAWS::Serverless Transformセクションにおいて、AWS SAMのバージョンを指定することが必要です。 --- ## AWS CloudTrail AWS Code Commit AWS Code Deploy CodeDeploy は、Amazon EC2 インスタンスやオンプレミスインスタンス、サーバーレス Lambda 関数、または Amazon ECS サービスに対するアプリケーションのデプロイを自動化するデプロイメントサービスです。 CodeDeploy はサーバーで実行され、Amazon S3 バケット、GitHub リポジトリ、または Bitbucket リポジトリに保存されているアプリケーションをデプロイできます。 AWS Elastic Beanstalk エンドポイントの公開 Elastic Beanstalk環境でHTTPSプロトコルエンドポイントを公開するには ebextensionファイルを作成してロードバランサーを実行することが求められる。 バージョン更新の自動化？ All at once 新しいバージョンをすべてのインスタンスに同時に展開します。 環境内のすべてのインスタンスは、展開が行われている間、短時間サービスが停止します。 これは、展開に必要な合計時間を最短にする方法です。したがって、オプション３が正解となります。 Rolling(ローリング) これにより、Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイします。これにより、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になります。つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在します。 Rolling with additional batch 新しいバージョンをバッチで展開しますが、最初にインスタンスの新しいバッチを起動して、展開プロセス中に完全な容量を確保します。 Immutable 変更不可能な更新を実行して、古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動します。[Immutable] デプロイは、部分的に完了したローリングデプロイにより発生する問題を防止できます。新しいインスタンスがヘルスチェックをパスしなかった場合、Elastic Beanstalkはそれを終了し、元のインスタンスをそのまま残します。 --- ## AWS KMS - ### KMS APIコール AWS SAM AWS Secrets Manager ELBとALBとCLBとNLB ELB(Elastic LoadBalancer) ALB(Application LoadBalancer) ELB(Elastic LoadBalancer) CLB(Classic LoadBalancer) NLB(Network LoadBalancer) ELBとは複数サーバでの冗長化構成を構築し、それらに対して負荷分散を行うマネージドサービス CodePipeline Fargate Root53 NLB IAM 認証バージョン クロスアカウントアクセス IAM ユーザーには、AWSアカウント内のロール、または所有する他の AWS アカウントで定義されたロールに切り替えるアクセス許可を付与することができます。このようなアクセス許可をクロスアカウントアクセスと呼びます。 S3 サーバーアクセスログ KCL(Kinesi Client LIbrary) AWS Lambda 環境変数のセキュリティ確保 AWS KMSを使って伝送中の暗号化のためのヘルパーを有効にする事が可能。 ファイルの一次保存 Lambda関数を使用する場合で一時ファイルを保存する際には　　 ロー化rディレクトリ/tmpを利用する。Lambda上では最大512mbまでデータの一時保存が可能。 制限 AWS Lamdaはデフォルトでコンピューティングやストレージ量が制限されていて、 同時実行数に関しては1000までに制限されている。(すべてのLambda関数で共通) 同時実行数のカウント方法としては(1秒あたりのコール数*平均実行時間) デフォルトの制限を超える場合はAWSへの上限緩和申請が必要となる。 X-Ray SDK 本番環境や分散アプリケーションを分析・デバッグできるサービス。 アプリケーションやサービスの実行状況を監視してパフォーマンス問題やエラーの根本原因を特定してトラブルシューティングを行うことができる。 - ### AWS X-Ray の環境変数 デーモンがECSを検出するようにするにはAWS_XRAY_DAEMON_ADDRESS環境変数 を設定する事が必要。 ### サンプリング要求値の計算方法 ＜1秒あたりのサンプリングされた要求の合計を計算するには、次の式を使用できます。＞ サンプリングリクエスト数　＝　リザーバーサイズ＋（（1秒あたりの着信リクエスト-リザーバーサイズ）*固定レート） 300の着信リクエストから毎秒合計260のリクエストをサンプリングする場合、リザーバサイズを250に、固定レートを20％に設定してから、上記の式を使用して計算します。 = 250 +（（300-250）* 20％） = 260リクエスト したがって、上記式に合致するのはオプション４となります。 AWS X-Ray SDKでは、X-Ray API を使用してサンプリングルールの取得、サンプリング結果の報告、およびクォータ取得を行います。サンプリングルールにおけるリザーバサイズは、固定レートを適用する前に記録する 1 秒あたりのトレースの目標数となります。リザーバはすべてのサービスに累積的に適用されるため、直接使用することはできません。ただし、0 以外の場合は、X-Ray がクォータを割り当てるまでリザーバから 1 秒に 1 個トレースを借りることが可能です。クォータを受信する前に、1 秒ごとに最初のリクエストを記録し、追加のリクエストに固定レートを適用します。固定レートは、0～1.00 (100%) の 10 進数です。 一般的なITの範囲 ### CIDRブロック(サイダーブロック) クラスレスなIPアドレス空間のアドレス割り当ての仕組み。 詳細はここ https://www.nic.ad.jp/ja/basics/terms/cidr.html

この記事は、関口 厚がポートフォリオ用に開発したWEBアプリの紹介記事です。 アプリの概要 アプリ名：ひとこと日記ver2 日々の記録をテキスト形式で保存する、シンプルな日記アプリです。 コードはGithubにてご覧いただけます。(フロントエンドのコード・バックエンドのコード) 作成環境 ・インフラ：AWS ・バックエンド：node.js ＋ Express ・フロントエンド：Vue.js ・データベース：MySQL ●各バージョン node.js v12.18.2, Express 4.17.1, Vue.js 2.6.12, Veu-CLI 4.4.6, MySQL 8.0 アプリで行う主な処理 ユーザー登録・認証処理 日記のCRUD処理 アプリの構成 ・インフラは、AWSのEC2上にExpressサーバーを立て、RDS上にMySQLデータベースを立てています。 ・フロントエンドは、Veu-CLIを使って構築し、SPAにしています。（Nuxt.jsは使っていません） ・Expressサーバーにて、SPAのホスティングと、データベース処理用のエンドポイントの提供を行っています。 ・Vue.js-Express間の通信は、axiosでデータをやり取りしています。 サーバーとクライアントの構成図 ユーザー登録・認証機能の動作 ・UIからユーザー登録、ログインを行います。 ・Vue.jsからaxiosで通信し、Expressサーバーのエンドポイントへアクセスすることで、ユーザー登録、ログインの処理を実現します。 ・ログインするとトークンが発行され、以降の処理はトークンによってユーザーを一意に特定します。 日記機能の動作 ・UIから日記の表示・作成・更新・削除を行います。 ・Vue.jsからaxiosで通信し、Expressサーバーのエンドポイントへアクセスすることで、日記のCRUD処理を実現します。 ・axios通信時にサーバーにトークンを送信することで、ユーザーを一意に特定して、日記データを処理します。 フォルダツリー ●vuecli-appのフォルダ構成（フロントエンド） [ルート] └ [public]フォルダ └ [images]フォルダ 　└ 各種imageは全てここに格納 └ index.html └ favicon-diary.ico └ [src]フォルダ └ [asset]フォルダ └ [components]フォルダ 　└ [diary]フォルダ　日記関係のVueコンポーネントを格納するフォルダ └ Index.vue　トップページ（アプリの紹介ページ） └ Mypage.vue　日記の一覧表示ページ └ Edit_Create.vue　日記作成ページ └ Edit_Update.vue　日記更新・削除ページ └ Header.vue　ログイン時のヘッダーコンポーネント └ Help.vue　機能紹介ページ 　└ [login]フォルダ　ユーザー認証関係のVueコンポーネントを格納するフォルダ └ Regist.vue　ユーザー登録ページ └ Login.vue　ログインページ └ Trial.vue　お試しユーザーログインページ └ App.vue └ main.js └ router.js　Vue.jsのルーティングを記述したJS └ store.js　Vuexの設定を記述したJS ●express-appのフォルダ構成（バックエンド） [ルート] └ [public]フォルダ　ビルドしたVue.jsのファイルをここに格納している。 └ 各種ファイル。Vue-CLIでビルドしたdistフォルダ内のファイルをそのままコピーしたもの。 └ [routes]フォルダ　axiosリクエストのエンドポイントを提供するためのルーターモジュールを格納したフォルダ └ get_diaries.js　一ヶ月分の日記を取得する処理のモジュール └ get_one_diary.js　一日分の日記を取得する処理のモジュール └ edit_create.js　日記を作成する処理のモジュール └ edit_update.js　日記を更新する処理のモジュール └ edit_delete.js　日記を削除する処理のモジュール └ user_regist.js　ユーザー登録する処理のモジュール └ user_login.js　ログインする処理のモジュール └ user_delete.js　ユーザーを削除する処理のモジュール └ user_auth.js　認証トークンを延長する処理のモジュール └ [function]フォルダ　サーバーに機能を与えるモジュールを格納したフォルダ └ db_connect.js　データベース接続設定モジュール └ token.js　認証トークン発行モジュール └ clear_auth.js　有効期限切れのトークン情報を削除するモジュール └ app.js

この記事は、関口 厚がポートフォリオ用に開発したWEBアプリの紹介記事です。 アプリの概要 アプリ名：ひとこと日記ver2 日々の記録をテキスト形式で保存する、シンプルな日記アプリです。 コードはGithubにてご覧いただけます。(フロントエンドのコード・バックエンドのコード) 作成環境 ・インフラ：AWS ・バックエンド：node.js ＋ Express ・フロントエンド：Vue.js ・データベース：MySQL ●各バージョン node.js v12.18.2, Express 4.17.1, Vue.js 2.6.12, Veu-CLI 4.4.6, MySQL 8.0 アプリで行う主な処理 ユーザー登録・認証処理 日記のCRUD処理 アプリの構成 ・インフラは、AWSのEC2上にExpressサーバーを立て、RDS上にMySQLデータベースを立てています。 ・フロントエンドは、Veu-CLIを使って構築し、SPAにしています。（Nuxt.jsは使っていません） ・Expressサーバーにて、SPAのホスティングと、データベース処理用のエンドポイントの提供を行っています。 ・Vue.js-Express間の通信は、axiosでデータをやり取りしています。 サーバーとクライアントの構成図 ユーザー登録・認証機能の動作 ・UIからユーザー登録、ログインを行います。 ・Vue.jsからaxiosで通信し、Expressサーバーのエンドポイントへアクセスすることで、ユーザー登録、ログインの処理を実現します。 ・ログインするとトークンが発行され、以降の処理はトークンによってユーザーを一意に特定します。 日記機能の動作 ・UIから日記の表示・作成・更新・削除を行います。 ・Vue.jsからaxiosで通信し、Expressサーバーのエンドポイントへアクセスすることで、日記のCRUD処理を実現します。 ・axios通信時にサーバーにトークンを送信することで、ユーザーを一意に特定して、日記データを処理します。 フォルダツリー ●vuecli-appのフォルダ構成（フロントエンド） [ルート] └ [public]フォルダ └ [images]フォルダ 　└ 各種imageは全てここに格納 └ index.html └ favicon-diary.ico └ [src]フォルダ └ [asset]フォルダ └ [components]フォルダ 　└ [diary]フォルダ　日記関係のVueコンポーネントを格納するフォルダ └ Index.vue　トップページ（アプリの紹介ページ） └ Mypage.vue　日記の一覧表示ページ └ Edit_Create.vue　日記作成ページ └ Edit_Update.vue　日記更新・削除ページ └ Header.vue　ログイン時のヘッダーコンポーネント └ Help.vue　機能紹介ページ 　└ [login]フォルダ　ユーザー認証関係のVueコンポーネントを格納するフォルダ └ Regist.vue　ユーザー登録ページ └ Login.vue　ログインページ └ Trial.vue　お試しユーザーログインページ └ App.vue └ main.js └ router.js　Vue.jsのルーティングを記述したJS └ store.js　Vuexの設定を記述したJS ●express-appのフォルダ構成（バックエンド） [ルート] └ [public]フォルダ　ビルドしたVue.jsのファイルをここに格納している。 └ 各種ファイル。Vue-CLIでビルドしたdistフォルダ内のファイルをそのままコピーしたもの。 └ [routes]フォルダ　axiosリクエストのエンドポイントを提供するためのルーターモジュールを格納したフォルダ └ get_diaries.js　一ヶ月分の日記を取得する処理のモジュール └ get_one_diary.js　一日分の日記を取得する処理のモジュール └ edit_create.js　日記を作成する処理のモジュール └ edit_update.js　日記を更新する処理のモジュール └ edit_delete.js　日記を削除する処理のモジュール └ user_regist.js　ユーザー登録する処理のモジュール └ user_login.js　ログインする処理のモジュール └ user_delete.js　ユーザーを削除する処理のモジュール └ user_auth.js　認証トークンを延長する処理のモジュール └ [function]フォルダ　サーバーに機能を与えるモジュールを格納したフォルダ └ db_connect.js　データベース接続設定モジュール └ token.js　認証トークン発行モジュール └ clear_auth.js　有効期限切れのトークン情報を削除するモジュール └ app.js

プログラミング勉強日記 2021年5月14日 EC2とは 　EC2はAmazon Elastic Compute Cloudの略で、AWSで利用できるシステムの1つ。AWS上に仮想サーバーを構築して自由に利用できる。クラウド環境において様々な役割を担っている。 EC2の特徴 数分で利用可能な従量課金(時間~秒単位) 起動・ノードの追加・削除・マシンのスペック変更が数分で可能 アンマネーシド型(物理的なインフラ管理はAWS側、立ち上がったサーバーの管理や設定はユーザ側) 物理的なインフラは汎用的なIntelアーキテクチャを使っている WindowsやLinuxなどほとんどのOSをサポート 独自のAmazon Machine Image(AMI)にOSを設定して保存してバックアップのように使える。 　EC2では仮想サーバーのことをインスタンスという単位で扱い、任意のAZにインスタンスを立ち上げてサーバーとして利用する。(インスタンスは1つのAZに設置し、リージョンに直接設置することない)インスタンスには様々な種類や性能のものがある。 EC2の起動方法 　EC2の起動方法は以下の手順になる。 AMI(OSのセッティング)を選択する インスタンスタイプを選択する インスタンスタイプの詳細の設定をする ストレージを選択する タグを追加する セキュリティグループを選択する キーペアを設定する (詳細な説明があるところは下記で詳しく説明する) 1. AMI(OSのセッティング)を選択する 　AMIはOSのセッティングのこと。WindowsやLinuxなどの様々なOSがすでに設定されている状態でAMIとして提供されている。主に、AWS側で用意されたAMI、3rd partyが売っているAMI、自作できるカスタムIAMの3種類ある。カスタムAMIはバックアップのように再利用することができる。 　まずは、EC2インスタンスのOSを設定してそのOSでEC2インスタンスを作る。 2. インスタンスタイプを選択する 　インスタンスタイプの呼び方は、t2.nanoのようになっている。最初に出てくるアルファベット(t)はインスタンスのファミリー。tは汎用インスタンスのtシリーズと呼ばれるファミリー。2は世代。nanoはインスタンスの容量を決定する。 3. インスタンスタイプの詳細の設定をする 　インスタンスの購入方式に応じて割引価格が提供されるので、用途に応じて割引価格を利用する。 　物理対応可能なインスタンスもあり、これは物理サーバーにインスタンスを起動して制御可能。 4. ストレージを選択する 　EC2で直接利用できるストレージは、インスタンスストアとElastic Block Store(EBS)の2つ。 　インスタンスストアは、物理的にEC2インスタンスが起動しているサーバーにアタッチされているハードディスク。EC2の値段に含まれているので無料で使用することができる。内蔵ディスクはPCに入っている内蔵のハードディスクと同じようなもので、EC2の一時的なデータが保持されてEC2の停止・終了とともにクリアされる。 　Elastic Block Store(EBS)は、ネットワーク経由でEC2に接続して使うストレージ。基本的にはEC2と一緒に使う。デフォルトではEC2を削除するとEBSも同時に削除されるようになっている。(設定を変更すればEBSだけ保存することもできる)　EBSは別途料金が発生する。

概要 日時 2021年05月11日, 12日 場所 online 主催者 Amazon Web Services, Inc 参加方法 こちらに登録してオンデマンド配信できる メディアコンテンツの収益化と分析を⾃動化・改善するために AIを活⽤する メディアにおけるAI推進要因 コスト CS改善 強化するAIサービス Amazon Rekognition イメージとビデオ 人検知、テキストの検出、顔検出と分析、動線検出 Transcribe speech2text ライブストリーミングに低遅延、フルマネージド、スケーラブル Translate 機器翻訳 Comprehend 自然言語処理 Personalize 個人に最適化されたメディアコンテンツのレコメンド NASCARにおける課題と解決方法 課題 毎月数百本の短編動画コンテンツをパブリッシュ 全てのコンテンツに字幕が必要で、容易に早く字幕を入れる方法が必要 マルチサイト多言語字幕に対応できる仕組みが必要 解決方法 Amazon Transcribeを利用したコンテンツマネジメントシステムを開発 ワークフロー ビデオをS3にアップロード Lambdaイベントトリガー 音声ファイル抽出とTranscribeジョブを起動 TranscribeジョブがJSONファイルをS3に出力 Lambdaイベントトリガー JSONをVTT形式に変換しS3にアップロード VTTファイルを含んだビデオのURLに更新 音声ファイルとJSONファイルをS3から削除 アーキテクチャ ビデオ、音声 -> S3 -> AWS Lambda -> AWS step Functions -> (Amazon Rekognition, Amazon Transcribe, Amazon Translate, Amazon Comprehend) - Amazon Elasticsearch Service 機械学習モデルの開発、学習、デプロイ ワークフロー 開発 データ収集、統合、アノテーション、分析、可視化、特徴量エンジニアリング、アルゴリズムの選定 学習 モデルの学習、評価 デプロイ管理 デプロイ、スケーリング、再学習、モデルの監視、テスト 課題 開発 時間とリソースがかかる ツールが一般的にDevOpsフレンドリーではない 学習 大量の試行錯誤を効率化する必要 デプロイ 複数チームメンバーと連携 ワークフロー自動化 継続的にモデルを監視する必要 SageMaker studio 機械学習のための統合開発環境、SageMakerの各機能をひとつ所から呼び出して利用できるウェブベースの統合開発環境 https://aws.amazon.com/jp/sagemaker/studio SageMaker Notebooks Notebook instantceが利用できて、これとの大きな違いは以下のように AWS SSOによる認証 早い起動とインスタンスタイプ変更 １クリックでノートブックを共有 SageMaker Ground Truth 機械学習用の大規模な学習データに簡単にラベル付ける メリット 画像、動画、テキスト、3D Point Cloudなどのユースケースのための組み込みのラベリングツール ワーカーの選択肢が多い ワーカへのタスクの振り分け、集計などを自動化 アノテーションのワークフロー アノテーション対象のデータをアップロード ワーカーを指定 ラベリングジョブの作成 タスクはワーカーに自動で割り振られる ラベリングツールでワーカーがアノテーションを行う アノテーション結果がAmazon S3に集計される SageMaker Data Wrangler 機械学習のためのデータを簡単に迅速に準備する メリット データを洗濯してクエリを実行 組み込みのデータ変換機能でデータを簡単に変換 データ変換をカスタマイズ MLモデルの精度を早く推定 SageMaker JupStart 機械学習を簡単かつ迅速に始める メリット １５以上の一般的なMLユースケースの構築済みソリューション １５０を超えるオープンソースモデルのデプロイ時間を短縮 数クリックで始める SageMaker Autopilot SageMaker上でAutoML を簡単に実行 GUIでの利用が可能 データクリーニングと前処理の自動化 多いアルゴリズムを選択 ハイパーパラメータチューニングの自動化 インスタンス、クラスタサイズの自動選択 SageMaker Pipelines MLのCI/CDを実現 データ処理や学習、モデルの最適化などの一連のステップを任意タイミングで実行可能 本番環境にデプロイするのに最適なモデルを選択可能 SageMaker Model Registry SageMkaer Studioでモデルのバージョンを選択し詳細を確認できる SageMaker Model Monitor モデルの品質を維持できる 監視対象： データの品質 モデルの性能 モデルのバイアスドリフト Amazon CodeGuru〜機械学習で実現するコードレビュー⾃動化とアプリケーションパフォーマンス最適化 Amazon CodeGuru利用の全体象 Amazon CodeGuru Reviewer ソースコードのクリティカルな問題や発見 改善方法、ドキュメントを合わせる Java、Pythonに対応 Amazon CodeGuru Profiler アプリケーションのパフォーマンス状況を可視化 改善方法、ドキュメントを合わせる Java/JVMベースの言語、Pythonに対応 CodeGuru Reviewerの動作イメージ 管理者はAmazon CodeGuruとリポジトリと関連を付ける AWS CodeCommitを利用すると便利 変更点をCommitしPull Requestを作成 Pull Requestに対し推奨事項をコメント 推奨事項 AWSベストプラクティス 並列処理 セキュリティ リソースリーク防止 機密データ コーディングベストプラクティス リファクタリング インプットバリデーション コードクオリティ