AWS JumpStart for NewGrads 2022 　参加記事 ~最強のアーキテクチャ を考えてみた~

新卒 AWS 研修

皆さん初めまして！22 卒の服部(@ruriro0125)です。 普段はるりとと呼ばれています。 本記事では、 私を含めた 22 卒のエンジニアで参加した

AWS JumpStart for NewGrads 2022

という研修でどのように最強なアーキテクチャ構成を考えていったのか、 という内容を紹介させていただきます。

AWS JumpStart for NewGrads 2022 って何？

新卒 1 年目のエンジニアの方々を対象とした、3 日間の実践的な研修プログラムです。

  • 将来的に AWS 活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムを提供します。
  • 単なる AWS サービスの学習だけでなく、チームに分かれて要件に合った適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容となっています。
  • 講義形式のトレーニングではなく、より実践的な経験を積んでいただきます

(研修内で使用された資料より引用)

といった内容になっています。

要約すると 割と難しいお題に沿ったアーキテクチャ構成をチームで考え発表しようというイメージを持っていただければ幸いです。

研修の内容

本研修では、 大まかに以下の二つの内容に取り組みました。

  • AWS を用いた実践的なハンズオン
    • スケーラブルウェブサイト構築ハンズオン
    • Lambda や DynamoDB を用いたサーバーレスなアプリケーション環境の作成
  • お題に沿ったアーキテクチャ構成の検討
    • 詳細は次の項目で説明します

AWS を用いた実践的なハンズオンについては非常に楽しく有意義な内容でしたが、 本記事では省略させていただきます。

アーキテクチャ構成の研修について

概要としては、3 日間でとあるサービス(お題)に沿った適切なアーキテクチャの構成をチームで考えて発表しよう！ というものでした。
サービスの概要としては大規模なチャットアプリで、 開発期間やコストに制限があったり、 多種多様な要望があったり正直投げ出したくなるかなり考えるべき内容が多いものでした。
また 3 日間の中で AWS の人に 3 回アーキテクチャ構成について質問する機会が設けられており、 いかにその機会を上手く活用するかという部分が肝になっていました。

これからは、 上記のような難しいお題に対して私が所属するチームがどのように立ち向かっていたのか、 という流れや詳細についてお話しさせていただきます。

研修開始直後

研修の概要やお題となるサービスの説明を受けてグループワークが始まりました。
アーキテクチャ構成の考案などしたことがない右も左も分からなく、 何から着手すればいいのかも曖昧な状態でした。

ベースとなるアーキテクチャ構成はチーム全員が何となく把握していました。
また「ロードバランサーは負荷分散出来そう」「チャットアプリなら WebSocket 使うのかな？」みたいなことは考えられましたが、 実際にベースとなるアーキテクチャ構成のどの部分を何に変更・改良すればお題に寄り添えるアーキテクチャになるのか？という部分が難しく身動きが取れない状態でした。

ベースとなるアーキテクチャ構成のサンプル図

画像引用元: AWS ソリューション構成例 - 動的 Web サイト

そういった硬直状態の中で、 「まずは何が不明瞭で疑問に感じているのか」という部分の洗い出しをチームで行うことになりました。

疑問点の洗い出し

洗い出しには、オンラインホワイトボードツールを用いて付箋を張り出していくやり方を採用しました。

洗い出しに用いた付箋のスクショ

付箋は色によって以下のような意味付けを行なっていました。

  • 黄色: 要件・考えるべき内容
  • 白色: 意見など雑多なもの
  • 緑色: 解決案
  • 青色: 参考記事
  • 紫色: 疑問点

当初は付箋の色分けはせずに白色のみで意見のやり取りをしていました。
その中でどの付箋がどの内容についての意見や疑問なのかという部分がわかりにくいと感じたため、 付箋の色分けや機能・要件によるグルーピングなどに取り組みました。
洗い出しを一通り行うとチームの中でも疑問や不安に感じている箇所が割と集中していることに気付き、 上記の箇所の調査や質問タイムにどんな内容を聞くか考えようという方針になりました。

質問と回答

先ほど取り組んでいた疑問点の洗い出しを踏まえて何回か質問をし、 アーキテクチャ構成を改良するという内容に取り組みました。

疑問や不安が集中していた部分としては、今回のサービスに対して最適な DB の取り扱いがわからない、
Web サーバーを動かす際に色々なやり方があって選び方が分からないといった抽象的な内容が多かったです。
また CloudFront を用いた静的コンテンツの配布が一般的にどのように運用されているのかがわからない、 といった実際にどう使われているのかが想定出来ないという意見も出ました。

これを踏まえて 1 回目の質問に臨みました。

実際に回答していただいた内容を編集して文章に起こしているため、 意味のブレなどがあると思います。 ご了承ください。

1 回目の質問と回答

Q.CDN(CloudFront) で画像とか動画を配信する際に、 公開されても大丈夫なやつだけを配信すればいいのかが分からないです

A.基本的には全ての内容を配信しても問題ない。 CDN で配信したいコンテンツの url を作成する際に閲覧権限とかの設定を CDN のエッジ上で出来るとのこと。

Q.インメモリキャッシュと永続 DB (RDS を想定)の違いって何ですか？

A.インメモリキャッシュはチャットやユーザー検索を早くするのに用いる。

Q.高い負荷を掛けてもインメモリキャッシュや RDS は耐えられますか？

A.高い負荷を掛けても、 RDS でも対応出来るが応用的な手法が必要となる。インメモリキャッシュでも対応出来るが RDS と同じく工夫が必要となる。 DynamoDB(NoSQL)なら上二つより簡単に対応出来るのでオススメ。

Q.今回のお題に沿った最適な DB って何ですか

A.目的に応じて DB を使い分けることは可能。 具体的にはチャット系は DynamoDB でユーザー機能などは RDS といった形で併用出来るが応用的な手法。

Q.Web サーバーを動かすにあたって、 どのやり方が最適ですか？(EC2 or Lambda or コンテナを使うサービス)

A.サービスを動かすという点のみで考えれば Lambda が一番コストがかかる。 しかし、 一番コストがかかるのはサービスを動かす際のコストではなく人件費です。 なので Lambda は動かすコストは高くても AWS 側に実装・管理をお願い出来る範囲が広いため人件費抑えられる可能性もある。

といった内容でした。 コストが一番かかるのはサービスを運用するコストではなく人件費である、 という点はサービスを実装する観点に囚われがちだった私には非常に面白い観点でした。

上記以外にも、 モバイル端末の対応方法や双方向通信をどうするのかという疑問点や質問したい内容もありましたが、 各疑問点がどれだけ重要かという優先度付けやチームで解決出来るのかどうかという観点から質問項目から外しました。

質問を踏まえたアーキテクチャの検討

上記の質問を踏まえて、 ベースとなるアーキテクチャ構成のうち以下の箇所を変更しました。

DB 部分: RDS -> DynamoDB + インメモリキャッシュ(詳細未定)

元々 RDS を選択する強い理由がない状態かつ、 質問の回答の中で大規模なトラフィックを捌くという観点からは DynamoDB が最適であるというアドバイスがあり採用しました。 コストの面などは一旦置いておいて実現したいサービスの機能を満たせるかどうかという点に注目して決定しました。 また直近のチャット情報を素早く取り扱うためにインメモリキャッシュの採用も決定しましたが、 具体的なサービスや配置場所は今後調査して決めようという方針でした。

Web サーバー部分: EC2 -> ECS(詳細未定)

今回のチームではコンテナを用いた開発に慣れているメンバーが多く、 開発環境などをコンテナ上で行うメリットを享受出来ると判断したため ECS を採用しました。 具体的にどのような使い方をするのかは今後調査して決めようという方針でした。

またチームで調査していく中で、 「認証・認可部分は マネージドなサービスに依存した方が良い」という話が上がったので、 Cognito を採用することを決定しました。

この検討の中で発生した疑問点のうち、 ECS をどう取り扱うのか(Fargate を使うべきか)・API Gateway を使うべきかという部分が重要だとチームで判断したので、 2 回目の質問では上記 2 つとアーキテクチャ構成図の記法をチェックしてもらおうという判断になりました。

何を質問するのかという判断についてですが、 ECS の取扱いについていくつかの方法は知っていましたが、 メリット・デメリットでの比較が難しく AWS の方に相談するべきだと感じ採用しました。
API Gateway については存在こそ知っていたもののどういったサービスなのか、またどういう目的で採用されているのかという情報を調べきれていなかったので採用しました。

2 回目の質問と回答

Q.API Gateway のメリットって何ですか？

A.URL のパスや HTTP パスのキャッシュや流量制限が可能になる。 Cognito との連携が手厚く、 API Gateway で認証機能の提供が可能。(ロードバランサーでも認証機能は提供出来るが、 JWT を使う場合だと cookie に変換する必要があったりと制限が存在する)

Q.ECS Fargate を使う場合のデメリットって何ですか？

A.内部のインスタンスに ssh 接続が出来ない、 グラフィック処理に向いてない、 ログ管理やサービスがダウンした時の対応が難しい。

他にも作成していたアーキテクチャの構成図に矛盾している点がないかどうかも確認していただきました。
アーキテクチャ構成図は基本的には問題がない状態でしたが、 CloudFront を API Gateway に通して提供することが可能であり、 更なる高速化が見込めるというアドバイスをいただきました。

質問を踏まえたアーキテクチャの検討

上記の質問を踏まえて、 ベースとなるアーキテクチャ構成のうち以下の箇所を変更しました。

Web サーバー部分: ECS (何使うかは未定) -> ECS (with Fargate)

質問の回答にもあった Fargate のデメリットの要素のうち、 直接 ssh 接続出来ない事による障害時の対応の難しさは今回のサービスにも当てはまるので採用するか否かの判断が難しかったです。
最終的には、 Fargate を使うことによってエンジニア側の工数を削減出来るメリットの方が先ほど挙げたデメリットよりも大きく、 なおかつログ管理などは CloudWatch などを採用すればある程度対策出来ると判断したため採用しました。

VPC の部分: API Gateway を設置する

質問の回答で、 API gateway を導入することによってコストこそ嵩むものの、 Cognito との連携が強力な点や WebSocket を用いた双方向通信に対応している点などメリットも多く導入した方が良いと判断しました。

またサービスの要望を達成しようとする中で、以下の 4 つの内容を追加しました。
基本的なアーキテクチャの選定が終わったこともあり、 サービスを動かすために必要というよりかはより良くサービスを展開・運用するためのアーキテクチャ選定がメインになっています。

  • Global Accelerator の採用
    • 今回のお題となるサービスでは日本とアメリカで展開したいという要望があり、 どちらかのリージョンのみに各サービスを設置すると応答速度に影響が出ると考え採用しました。
  • ログ管理部分の追加
  • CI/CD 環境の追加
  • 通知を行う環境の追加

2 回目の質問の後に色々な箇所のアーキテクチャ構成を変更・追加しました。
また発表が近づいてきたこともあり、 3 回目の質問では今の構成についての不安点の解消をしようという方針になりました。
そもそもアーキテクチャ構成図に矛盾点があるのか？であったり、 マルチリージョンで展開する時に DynamoDB が負荷に耐えられるのかといったサービスが動くかどうかという部分の要素が重要だと判断したので、 3 回目の質問内容として採用しました。

3 回目の質問

Q.現状のアーキテクチャ構成図に矛盾などは存在しますか?

A.Global Accelerator と API Gateway は併用出来ない。 Global Accelerator を採用する場合は API Gateway の利用を取りやめる必要がある。 逆の場合だと Route53 などを用いたルーティングによって、 Global Accelerator がなくてもマルチリージョン構成の実現は可能。

Q.DynamoDB の機能の一つであるグローバルデータストアを使ってリージョン間の同期を計画していますが、大量の書き込み速度に対して整合性確保出来ますか？

A.適切なキャパシティユニットを設定すれば問題ないよ。 また余談だけどキャッシュ機能は DynamoDB Accelerator 使うのもありだよ

Q.Amazon SNS は Web に通知出来ますか？

A.Web は無理、 メールなら可能

質問を踏まえたアーキテクチャの検討

上記の質問を踏まえて、 ベースとなるアーキテクチャ構成のうち以下の箇所を変更しました。

Global Accelerator の使用の取り止め

Global Accelerator を採用するか否かは最後まで悩みました。
マルチリージョンで展開しようとした際に、 Global Accelerator を採用するやり方と Route53 の地理的近接性ルーティングを採用するやり方などが考えられていたのですが、 双方メリットやデメリットがあり判断が難しい状態でした。
最終的にはグローバールアクセラレーターを採用すると API Gateway の設置が不可能になり、 Cognito との連携やキャッシュ機能などが難しくなることを踏まえて Route53 の地理的近接性ルーティングを用いたマルチリージョン構成にするという方針になりました。

作成したアーキテクチャ構成

最終的なアーキテクチャ構成は以下のようになりました。

マルチリージョン構成で DB 及び S3 のバケットはリージョン間で同期するようにしています。
また Route53 の地理的近接性ルーティングを用いてユーザーの位置に応じた最適な割り振りを実施しています。
基本的なサービスは Fargate 上で動作しているコンテナで処理を行い、 認証であったり WebSocket を用いた双方向通信などは API Gateway も利用しています。
画像や動画のデータは S3 に、それ以外は DynamoDB に保管するようにしました。
また直近のチャット情報などの大量に読み書きされうるデータについてはインメモリキャッシュに載せることで高速化を図りました。
各コンテナは CloudWatch を用いて監視し、 ログは S3 に溜めるようにしています。
開発者視点では CI/CD 環境を整備していることによって変更したコードを上げることによってテスト・ビルドなどを行い ECR に変更後のコンテナのイメージを上げるところまで自動化出来るようにしました。

3 日間の振り返り

最適なアーキテクチャ構成を考えるのは難しい

今回はベースとなるアーキテクチャを、お題となるサービスの要件に沿うように改良を続けていくというものでした。
その中で改良したい問題に対して複数の解決案が考えられる場面が何回かありました。
チームで複数ある解決案から一番最適な案を考えるときに、 様々な観点からメリット・デメリットを踏まえた検討する難しさに直面しました。
具体的として Web サーバーを挙げると、 コストの面では Lambda は高いけどエンジニアの人件費を考慮すると Lambda が一番安くなる場合もあるという風にコストの面で比較しようとしても複数の観点からメリット・デメリットが考えられる状態でした。
そのような難しい判断を強いられる中でチームとしてどういう理由でどのサービスを利用するのかといった部分を明確に決めることが出来たのは 3 日間の成果だったのではと思っています。

AWS の知見が高まった

アーキテクチャ検討の中で、 各サービスを使う・使わないの判断をする際にはそのサービスについての知識が求められます。
概要としては聞いたことがあっても実際にどうやって使うのか、 またメリット・デメリットはどういうものがあるのかといった内容を知っておく必要があります。
この 3 日間では様々なサービスの概要やメリット・デメリットを知ることができ、AWS の知見が高まりました。

アーキテクチャ構成に正解はない

他のチームの発表を見ているとマイクロサービスアーキテクチャを採用しているチームや、 Lambda を用いたサーバーレス なアーキテクチャを採用しているチームなど一つのお題に対して本当に様々なやり方・アーキテクチャ構成が存在すると実感しました。
本研修に参加する前はアーキテクチャ構成には所謂「銀の弾丸」が存在すると思っていたのですが、 発表を聞いているとどのチームが考えたアーキテクチャ構成でもメリット・デメリットが存在し正解はないんだなと感じました。

最後に

「最強のアーキテクチャを考えてみた」というタイトルでしたが、コスト面などの最適化やサービスとしてあった方がいいが提供出来なかった機能などもあり、最強からは程遠いアーキテクチャ構成ではありました。
しかしながら私含めたチームの最善となるアーキテクチャ構成は考えられたのではないかと思っています。

このような素晴らしい機会を設けてくださった AWS の皆さん、 本当にありがとうございました!!