AWS Dev Day 2023に参加してみた！②
AWS Dev Day 2023の二日目のセッションの内容です。
Amazon CodeCatalyst ワークショップ：最新の DevOps サービスを使った開発を体験してみよう！
最近新しくGAされたCodeCatalystという、開発環境、CI/CDパイプライン、タスク管理、ダッシュボードなどDevOpsを行う上で必要な機能全てを詰め込んだDevOpsプラットフォームを体験するというワークショップです。ワークショップ自体は以下のリンクから体験できます。
Amazon CodeCatalyst Workshop
以下は、ワークショップで実施した内容です。ただ、実際にはトラブルの発生や時間の都合などで、下記の項目の半分程度までを実施しました。
このワークショップでは以下のようなサーバーレスWebアプリを作成します。
CodeCatalystではプロジェクトという単位で、リポジトリやパイプラインなどの開発に必要なリソースを管理します。
プロジェクトを開始する際にはblueprintというものを使うことで、プロジェクト構成、サンプルコード、テスト、CI/CD ワークフロー定義などを自動で作成することができるようです。blueprintは目的に合わせて様々なものがあるようですが、今回のワークショップでは、modern-webappというblueprintを使用します。blueprintは以下のような画面で選びます。
bleuprintからプロジェクトを作成すると、リポジトリやCI/CDパイプラインが作成されます。
CI/CDの部分を開くと、以下のようにパイプラインのフローが表示されます。裏でCDKが動いているのが見て取れます。
デプロイが完了したので、variableに出力されているWebサイトのエンドポイントにアクセスしてみます。
以下のようなサンプルのWebサイトが表示されました。
コードの内容を修正する場合は、Codeタブからクローンするリポジトリやブランチ名などを指定すると、サクッと開発環境を作成することができます。今回はCloud9を選択します。
すると、以下のように対象のリポジトリがクローンされたCloud9の開発環境が用意されます。
この中でソースコードを修正すれば、そのまま対象のリポジトリにcommit&pushできます。
感想
今まではCI/CDの環境なんかを作成する際には自分でCodeシリーズを組み合わせたり、もろもろの設定を行う必要があったのが、このサービスを使うとその煩雑な設定がぐっと簡単になった印象です。Codeシリーズでなくても、GitHubやGitHub Actionsとの連携もできるようなので、既存の資産をそのまま活用できます。AzureでいうAzure DevOpsのようなサービスかと思います。
開発する場合も、Gitの認証情報の設定や、リポジトリのクローン、ブランチの分割などもマネコンでポチポチするだけで終わるので非常に楽です。デプロイ時には裏でCDKやCloudFormationが動いてるらしいのですが、インフラの構成もいじれるのかが個人的には気になったところです。
クイズ形式で挑戦 ! AWS のアーキテクチャ改善を実践してみよう！
サンプルとなるアーキテクチャが用意され、そのアーキテクチャの問題点や、どう改善できるかを周りの人と一緒に考えるというセッションです。
以下は今回対象となるアーキテクチャです。
それでは、一つづつどう改善していくかを見ていきます。一つ目の課題として、現状ではCloudFront経由でALBにアクセスしていますが、ALBのセキュリティグループではソースが0.0.0.0/0からのインバウンドを許可しており、全通し状態になっています。現実世界でこんなガバガバな設定する人本当に存在するんでしょうか？？って突っ込みたくなりました。というのはさておき、全通しではよくないのでCloudFront経由でのみアクセスさせるよう、適切なIPの制限を行いたいと思っています。
この場合、AWSマネージドプレフィックスリストというものをセキュリティグループのインバウンドルールに設定すれば、簡単にIPを制限できるそうです。これを使えば、手動でセキュリティグループのIPアドレス範囲を更新する必要がなくなるようです。
二つ目の課題として、CloudFront経由でのみS3のコンテンツにアクセスさせるためにOAIを設定していますが、OAIではKMSでのS3のサーバーサイド暗号化やS3に対するいくつかのHTTPリクエストが制限されているようです。
この場合、OAIではなくOACを使用すると先述した課題が解決できるそうです。現在ではOAIではなくこのOACを使用するのがベストプラクティスとなっているようです。
三つ目の課題として、CloudFrontで使用されるエッジロケーションが増えるに従ってリージョナルエッジキャッシュも使用されるようになっていますが、その分オリジンへのリクエストも増え、負荷が上がっています。
この場合、Origin Shieldというものを使用することでオリジンとリージョナルエッジキャッシュの間にキャッシュレイヤーが追加され、オリジンへの負荷を下げることが出来るそうです。
リージョナルエッジキャッシュまで意識する必要があるシーンに出くわしたことがないのでこういった課題を考える機会もありませんでしたが、世界レベルでのサービスを構築する機会には役立ちそうですね。Googleレベルのサービスかもしれませんが...笑
四つ目の課題として、ALBを配置するサブネットのCIDRブロックを小さめでとっていますが、ALBの仕様では少なくとも各サブネットごとに8個のIPアドレスが必要なため、IPが枯渇するリスクがあります。
そのため、ALBを配置するサブネットのCIDRブロックはあらかじめ大きめにしておく必要があります。ALBが最低8個のIPアドレスを使用するというのは知りませんでした。サブネットの設計前に頭に入れておかないといけなさそうですね。
五つ目の課題として、ALBのロードバランシングアルゴリズムにラウンドロビン方式を採用していますが、順番に各コンピューティングリソースにリクエストを送るため、特定のリソーのみ負荷の高いリクエストが集中してしまう恐れがあります。
この場合、ラウンドロビン方式ではなく最小未処理リクエストを使用すると、リクエストやターゲットの処理能力を考慮した負荷分散が行えるそうです。確かに、負荷分散と言いつつリクエストの処理負荷などを考慮せずに振り分けるのは割と原始的な分散方法かもしれませんね。
六つ目の課題として、あるVPCから他のVPC内のALBにアクセスするためにVPCピアリングやTransit Gatewayを使用していますが、これではIPアドレスが重複するサブネットには接続できません。ルートテーブルで対象のサブネットを定義しても、AWS内部のルーターが同一VPC内のサブネットだと解釈し、ルーティングが機能しないようです。
この場合、NLBとPrivateLinkを使うことで解決できるそうです。
七つ目の課題として、LambdaとDynamoDBを直接接続していますが、同時実行数が増えまくるとDBへの負荷が高くなったり、最大接続数を超えてしまうおそれがあります。
この場合、RDS Proxyを使用するとDBへのコネクションを一元的に管理することが出来るそうです。Lambda関数が大量にあって同時実行数が多くなりそうな場合はRDS Proxyの導入を考えるとよさそうです。
八つ目の課題として、AWS CLIで使用する認証情報にIAMユーザーで生成したアクセスキーを使用しています。しかし、アクセスキーをそのまま使用する場合定期的にローテーションする必要があったり、アクセスキーの情報が流出してしまうリスクもあります。
この場合、AWS IAM Identity Centerを使用すると、指定したIAMロールから一時的なアクセストークンを受け取ることが出来ます。アクセスキーのようなセキュリティリスクを孕むものは慎重に取り扱う必要があり、管理も面倒くさいので、こちらの方式でアクセスするように心がけたいですね。
感想
ニッチな内容もありましたが、割と実践的で役に立つ内容だったかと思います。こういった細かい部分を知っているかどうかが、障害やトラブルを未然に防ぐことにつながりそうです。
まとめ
二日目はハンズオンやケーススタディのような形式だったので、一日目より実践的な知識が得られたように思います。業務だと自分が関わることのできるシステムやアーキテクチャ構成は限られてくるので、ケーススタディで学習するのは楽しかったです。他にも色々なアーキテクチャに触れて、対応範囲を増やしていきたいです。
Discussion