アマゾン ウェブ サービス ジャパン合同会社の主催するAWS JumpStart for NewGradsという新卒向け研修の案内をいただき、
id:momochi29と
id:arthur-1の2名が参加しました。本エントリでは、このイベントではてなの新卒エンジニアが何を学んできたのかを紹介します。
AWS JumpStart for NewGradsとはどんな研修か
AWS JumpStart for NewGradsとは、クラウドアーキテクチャの設計が学べる新卒向けの研修です。各社合同で参加しており、参加者総数200名以上という大規模なオンラインイベントでした。
この研修は主に3つの内容で構成されていました。
- スケーラブルWebサイトハンズオン
- サーバーレスハンズオン
- アーキテクチャ検討・発表
メインのアクティビティは、3のアーキテクチャ検討です。3日間という限られた時間で、テーマとなるアプリケーションのインフラ構成についてチームでディスカッションして発表するという、課題解決型学習（PBL）方式のワークでした。
本エントリでは、このアーキテクチャ検討を深掘りして説明しますが、その前にハンズオンの内容についても軽く触れておきます。
- スケーラブルWebサイトハンズオン
- ECS Fargate・ALB・Auroraを用いたWebアプリケーションの構築に取り組みました。ただ作るだけでなく、データベースのフェールオーバーなど、システムに問題が起きたときに、自動で復旧される挙動を観察することができました。
- サーバーレスハンズオン
- API Gateway・Lambda・DynamoDBを用いてREST APIを作りました。この構成、実ははてなの新卒エンジニア研修で扱った構成とほぼ同じものでした。とはいえ、発展課題は難易度が高く、2人でDynamoDBのキー設計などを議論しながら進めました。
アーキテクチャを3日間で検討する
我々のチームは、他の企業のエンジニアも含めて計4人でアーキテクチャ検討を行いました。どのように議論を進めたか、3日間の流れに沿って説明します。
1日目 - 設計の土台となる議論を深めることに集中
まず、与えられた要件を満たすアプリケーションを考え、必要となるデータモデルを洗い出しました。そして、それぞれのモデルに対して読み込み／書き込みの特性を考察しました。これは、アーキテクチャ設計においてどのようなサービスを利用するのが適しているかを判断するためです。
このとき、与えられた要件と、類似するサービスの事例をもとに、どれくらいのトラフィック量やストレージの消費量があるのかを概算しました。定量指標がアーキテクチャ選択の判断材料として役に立つと考えたからです。今回、平均のリクエスト数については与えられていましたが、ピーク時にどれくらいになるのかを自分達で推測することで、サービスのスケールに対する解像度を高めることができました。
その後、Well-Architectedフレームワークを参考に、パフォーマンスや信頼性などの面で実現したい非機能要件を定義し、優先順位をつけました。この作業は、具体的なアーキテクチャ設計に取り組む際に指針となるものです。
他のチームはもうアーキテクチャ図を書き始めている様子でしたが、我々のチームは設計の土台となる議論を深めることに集中し、1日目を終えました。
2日目 - 各自が素案を作成して比較
まずは各自が手を動かしてアーキテクチャ図を書き、お互いの図を見比べて、2つの素案にまとめました。この時点ではどちらかに決めず、SA（ソリューションアーキテクト）のレビューを受けることにしました。
どちらでもテーマを実現できそうだとレビューしてもらいましたが、最終的にはどちらかを自分たちで選ぶ必要があります。そのためには、2案がどのようなトレードオフ関係にあるか（例えば、A案ではインフラ費用を抑えられるが実装コストが高い、など）を正しく理解する必要があると考えました。
両素案の比較にあたって、現時点でのアーキテクチャがラフスケッチレベルで、トレードオフの分析は難しいと判断しました。そこで、ある機能を実現するにはどういったデータの流れ方をするかを考えて、不足していると分かったコンポーネントを追加していきました。
3日目 - 実装コストを重視してアーキテクチャを決定
2日目で出た2案のうち、どちらにするかを決定する必要がありました。
まず、現時点でのアーキテクチャ図に各自が気になっているポイントを付箋で貼って、疑問や問題の解消に取り掛かかりました。実際にアプリケーションを開発することを想像してドキュメントに当たりながら、「これぐらいの開発コストで実現できそうだね」「これなら要件を満たせそうだね」などと会話しました。
その結果、「インフラ費用はかかるが、実装コストを抑えることができる」案の方を採用することに決めました。自分たちの実装力と実装コストを考えたときに、インフラ費用よりも実装コストを重視しようと議論で決定したからです。
残りの時間で、2日目には考えられていなかったデプロイ・監視・監査・セキュリティ周りについて、利用できそうなサービスを探し、図に書き加えていきました。
最終的に完成したアーキテクチャの全体図を以下に示します。
アーキテクチャ設計で工夫したこと
3日間にわたるアーキテクチャ設計では、要件にある「画像をセキュアに配信する」ことと「リアルタイム性」を実現するために工夫した点があります。
画像をセキュアに配信する
画像をセキュアに配信することが要件としてあり、この実現方法として次の2つを考えました。
- CloudFrontで署名付きURLを使用し、閲覧権限を絞る
- Cognitoで認証を行い、DBに問い合わせて認可を行う
A案は、署名付きURLを知っているユーザーだけにアクセスを絞ることができます。また、CloudFrontで署名の検証を行うので、バックエンドに貫通せず負荷を軽減できるというメリットがあります。一方で、署名付きURLが漏れてしまった場合には、本来アクセス権がない人でも閲覧可能になってしまうというデメリットがあります。
B案は、ユーザーがアクセス権を持っているかどうかをバックエンドに問い合わせることで、適切なユーザーのみにアクセスを絞ることができます。しかし、アクセスごとにバックエンドに問い合わせるので、負荷が増大するというデメリットがあります。
A案とB案では、パフォーマンスとセキュリティのトレードオフがあります。今回の要件では画像をセキュアに配信することがより重要であると考えたので、B案を採用しました。このときのアーキテクチャは、次のようになります。
リアルタイム性を実現する
リアルタイム性が要件としてありました。これを実現するためにWebSocketを利用したアプリケーションを作ろうとし、次の3つの実装案を考えました。
- ALBとECS（Fargate）を組み合わせて、各コンテナでWebSocketの通信を行う
- APIGatewayでWebSocketの通信を行う
- AppSyncのPub/Sub APIを使う
議論の結果、C案を採用することにしました。それは、インフラ費用だけでなく運用やアプリケーション開発に必要なコストも考慮したからです。
A案はコンテナ間でデータの同期を考えて実装する必要があったり、接続の管理をする必要があります。B案は言わば全部入りのサービスであるAppSyncを自前で再実装するようなもので実装コストが大きいです。
C案を採用したアーキテクチャは、次のようになりました。
AppSyncはこれまで全く触れたことがなかったので、どれほどスケールするサービスか分からず、この部分がボトルネックになることを懸念していました。しかし、SAの方に「AppSyncは1,000万の接続に耐え得る」ということをレビューで教えてもらい、要件を満たせることを確認しました。
研修の振り返り
他のチームと比較して、実際のアプリケーション開発を意識してアーキテクチャを組むことができていたと思います。どういったコードを書き、どのような設定をすれば実装できるのかを各自がイメージできていました。
逆に、インフラコストの検討は他のチームよりもできていませんでした。マネージドに寄せているので、今の構成ではけっこうお金がかかりそうですが、具体的にどれほどの費用がかかるかを見積もることができていませんでした。
WebSocketを使いたいのは実質的に1つのAPIのみだったので、一部のAPIを別のシステムとして切り出して他のシステムをECSで受けるようにすると、開発の自由度や費用といった面でよかったなという学びが、SAの方の構成からありました。
最後に
今回、新卒エンジニア2人でAWS JumpStart for NewGradsに参加しました。他の企業のエンジニアと一緒にワークに参加することは、企業文化の違いを感じられてとても新鮮でした。また、アーキテクチャ検討のプロセスを一から実践的に学ぶことができました。
3日間ともに議論を交わしたチームメンバーの皆さん、参加を後押ししてくれた上司、そして、このような場を用意していただいたアマゾン ウェブ サービス ジャパン合同会社の皆さま、ありがとうございました。
id:arthur-1
Mackerel 開発チーム アプリケーションエンジニア。顧客要望や dogfooding から特定した MVP を検証可能な形で実装し続けることで仮説検証型開発を支えている。東京工業大学情報工学科卒業後、2022年4月に新卒入社。
blog: Diary of a Perpetual Student
