AWS セミナー (AWS JumpStart 2022)参加リポート
旅行大好き、ゆこゆこ SRE の @kumagaias です。
この夏に AWS JumpStart という研修プログラムに参加してきました。
気になるけど参加しようか迷っている・・という方向けに、少しでも材料を提供できればと思い書いてみました。
概要
冒頭で謎の CEO からビデオレターが届き、
「チャットサービスを半年後にリリースする必要がありますが、残念ながら既存メンバーは全員退職してしまいました。
時間がないので、皆様には明日までにAWSでのアーキテクチャを考えていただきます！」
という無念極まりないお題が発表され、会場が沸きました。
また、機能要件・非機能要件が書かれたスライドも渡されました。
そちらを元に 2 日間、約 100 名のエンジニアがリモートで参加し、チームに分かれてアーキテクチャ図を作っていきました。
対象者
「AWS初学者のエンジニアの方々を対象」とあります。
業務または個人的に AWS を少しでも触ったことのある方
他のクラウドを触ったことのある方
上記の方ですと、十分に楽しめる内容と感じました。
チームでのアーキテクチャのセッションがメインで、コードは一切書きませんでした。
ですので、AWS は少し触っていて興味あるけどエンジニアではないし・・という方にもオススメですよ。
スケジュール
2 日間、チームでの「アーキテクチャ検討」がメインですが、途中 Fargate のハンズオンもあり、飽きさせない内容でした。
また AWS の SA (Solution Architect) さんによる、各チームへの巡回オフィスアワー (20 分 x 3 セット) もあります。
ここで現役の SA さんにざっくばらんに質問ができることも特徴だと思います。
終わりに成果発表会がありました。
各チーム、工夫した点などを発表し、SA さんや参加者からフィードバックをもらうことができました。
発表会の後は自由参加で懇親会もあり、SA さんと AWS のカルチャーについてざっくばらんに喋れたのも楽しかったです。
費用
無料
きっかけ
日頃お世話になっている AWS の担当者さんに本イベントをご紹介頂きました。
他社の方とアーキテクチャのセッションをする機会は貴重と思い参加させて頂きました。
SRE がまる 2 日間不在になるので大丈夫かな・・？と思ったのですが、上長が「ぜひ行ってきてください！」と背中を押してくれたのも後押しになりました。ありがたや。
参加してみて
チームの雰囲気
私達のチームは 3 名でした。
東京と沖縄からの参加で、リモートならではの交流が面白かったです。
スキル的にはこんな感じだったと思います。
中級者 2 名 (インフラ構築経験あり)
初級者 1 名 (アプリケーションエンジニア)
みんなリモート慣れしているのか、すぐに同僚のような雰囲気で (?) お題に取り組んで行きました。
苦労した点
私も含めメンバー全員「そもそもチャットってどうやって実装すんだ？」からスタートでした。
そのためアーキテクチャが想像もつかず、自己紹介までは順調だったのですが、その後すぐに全員でふ～む (?) な時間が流れました。
そこでオフィスアワー時に SA さんに質問したところ「私達 SA もいきなりアーキテクチャを描くのではなく、その前に実装面の調査をしています。チャットで使う技術を少し調査してみては？」とアドバイス頂きました。
そしてチームで調査をして行く中で WebSocket 等のキーワードがわかり、アーキテクチャに落とし込んでいくことが可能となりました。
個人的に大事にした点
チームワークを大事にしました。
具体的には以下になります。
いきなり本題のアーキテクチャを検討し始めず、自己紹介の時間をたっぷり取る (30 分くらい)
最初に 2 日間のチームのタイムラインを決める (ここまでに○○までやりましょうか、など)
休憩時間を明示してみんなで取る
雑談をちょいちょい挟む
Slack のチームのチャンネルで自分から多めに発言する
個人ワークの時間 (調査等) も取る
オフィスアワーで SA さんに聞くことをみんなで事前に整理する
発言が少なくなってきたメンバーに「○○さん、どう思いますか？不明点はありますか？」などと話をふる
発表会では誰か 1 名が全て喋るのではなく、担当を決めてチーム全員で喋る
そういえばセミナーが始まって私が真っ先にやったことは Slack のカスタム絵文字を追加したことです。
気軽に「ありがとう」や「すごい！」を言い合える関係って働きやすいんですよね。
成果物
私達のチームの成果物を添付させて頂きます。
SA さんも仰っていましたが正解はありません。
特徴
サーバレス
開発速度と開発体験を重視
考察
バックエンド
API Gateway
Web Socket API
Lambda
API Gateway も Lambda もリージョンサービスであり、可用性とスケーラビリティが高いため採用。また、使っている分だけ課金されるのでコスト面でのメリットもあります
求められるリアルタイム性が数秒以内だったのでコールドスタートしても概ね問題ないと判断
同時実行数 1,000 は申請すれば緩和されると踏み、当面は問題ないと判断
DB
用途と特性に合わせて 3 つ考えました。
メッセージ保存
Dynamo DB
性能面で NoSQL の Dynamo DB を採用
会員情報保存
Aurora
整合性が求められるので採用
リージョンサービスなので可用性も高い
メッセージ検索
OpenSearch (ElasticSearch)
ただし、仕組みを整えるためにはそれなりに実装コストと金銭コストがかかるので、最初のうちは実装を見送るよう PdM へ働きかけてもいいのでは？と生々しい話もしました (笑)
フロントエンド
Amplify Hosting
半年後にリリースというお題の前提から、開発スピードと体験を重視
CI / CD を 1 から構築する必要がありません
こちらは私の経験からですが、フロントのホスティングであれば十分 production ready です
PWA もできるようです
認証
API Gateway x Cognito
スコープ外
ネットワーク
最初は public / private を図に書いていましたが、SA さんに伺ったところ成果物の必須要件ではないとのことだったので、今回はより本質に注力したかったため省きました
勉強になったこと
サービスレベル
アーキテクチャを考える上で AWS のサービスレベルを意識することが大事だと改めて勉強になりました。
グローバル
CloudFront, WAF など
リージョン
API Gateway, Lambda, DynamoDB, Aurora など
AZ
EC2, RDS など
可用性を高めるためには Multi AZ にしたりする
上に行くほどマネージドサービスのため可用性が高いです。
例えば Aurora は RDS に比べて料金が高いイメージがありますが、内部で冗長化されているので 10 分未満のダウンタイムが許容できれば Multi-AZ にする必要は無さそうで、実は RDS に比べて料金が安くなりますね〜、などと会話しました。
インフラもユーザーファースト
チャットアプリはどんなサービスか？
ユーザーストーリーを自分たちで設定してから、そこに向かってアーキテクチャ検討していたチームがありました。
また、SA さんの解答例では REST でのエンドポイントを軽く出して、アプリケーションの通信の流れを手書きで図にしてからアーキテクチャ検討していたのも印象的でした。
アプリケーションもインフラも、ユーザーの課題解決のためにあると再認識できました。
終わりに
普段の業務で、アーキテクチャのパターンを複数用意して比較検討する機会はなかなか無いので大変勉強になりました。
成果発表会では「なぜこのアーキテクチャになったのか」を深堀りすることができ、大変楽しかったです。
ここまでお読み頂きありがとうございました！
ゆこゆこでは一緒に働いてくれる仲間を募集中です！
ぜひお気軽にご連絡頂ければ幸いです！
https://www.yukoyuko.co.jp/recruit/employeevoice/