クラウドインテグレーション部の今村です。
6月20日、21日に行われたAWS Summit Japan 2024 に参加してきたため、レポート記事を書いていきたいと思います。
AWS Summit Japan 2024の関連記事については別の記事も執筆しているためよろしければご覧ください。
2024 Japan AWS All Certifications Engineersを受賞するまでのきっかけと取り組み
AWS Summitとはホームページにも日本最大の "AWS を学ぶイベント"とある通り、AWSに関連する様々なコンテンツが一カ所に集結したイベントです。
AWS Summit Japan 2024 ホームページ
6月20日、21日の2日間にかけて幕張メッセで行われます。
その間にAWSの導入事例やセッション、AWSパートナー企業によるブースの展示、AWS Villageという展示エリアでの最新のAWSイノベーションの展示、AWS DeepRacerのレース、QuizKnockのメンバーの方々によるAWSで妄想してみたという展示パネルなどなど2日間あっても回りきれないようなボリュームです。
今回私は最終日である6月21日に参加していくつかのセッションやブースの見学をしてきました。
まず、来年以降初参加するかもしれない方への参考に当日の私の動きをスケジュールに起こしてみます。
| 時間 | 内容 |
|---|---|
| 6:00頃 | 出発、移動 |
| 8:00過ぎ | 幕張メッセ到着 |
| 8:20ごろ | 入場受付 |
| 8:30 | 会場に入場 |
| 10:00 | 基調講演開始 |
| 17:00過ぎ | AWS Summit終了～帰宅 |
会場は幕張メッセであり、私の自宅から電車で2時間と少しかかります。
そのため、準備は前日のうちに完了させておきました。
名刺、身分証、大きめのバック、冷感グッズ、塩分チャージ、入館用のQRコードの印刷あたりを持っていきました。
昨年参加したときにも準備物は迷いましたが、6月後半ということで会場は蒸し暑いと思って熱中症対策をしてました。
実際は、会場内の冷房が効いていて過ごしやすかったです。
会場ではノベルティをもらうことが多いので折りたたみのバックを準備しました。
朝一だと先着でお弁当やクッション、ドリンクなどが貰えます。
私はお昼ご飯のことを考えずに済むことや長時間セッションを聞いても疲れにくくなるクッションなどを目当てに朝一で会場に向かいました。
会場も朝一だったのでものすごく広く感じます。
基調講演の座席は入場時にもらえる控えに記載してある指定席制でした。
昨年は先着順だったので1回着席したら動きにくかったですが、今年は指定席だったのでロビーで時間まで待機など自由に動きやすかったのではないかと思います。
A~Eまでのセッション会場の真ん中のC会場でなおかつ前から7列目のほぼ真ん中といい席で基調講演を聞くことができました。
翻訳機能もついているため、英語が苦手な方でも問題なく聞くことができます。
今回セッションは5つ申し込みましたが、全部書いていくと長くなるため、1つに絞ってセッションレポートを書いていきたいと思います。
一番印象に残ったセッションは「アーキテクチャ道場 2024！」でした。
こちらは2日目の最後の時間にA,B会場合同でセッションがあるということで人気であることが予想されたので20分前に会場に向かいましたが既に前の方は埋まっていました。
内海 英一郎 氏
アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 チーフテクノロジスト
馬渕 俊介 氏
アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ技術本部 サービスグループ トラベル・交通・物流ソリューション部 ソリューションアーキテクト
山﨑 翔太 氏
アマゾン ウェブ サービス ジャパン合同会社 ストラテジックインダストリ技術本部 デジタルソリューション部 部長 / シニアソリューションアーキテクト
・挨拶
・お題1
・お題1の解説
・お題2
・お題2の解説
このセッションの面白いところは最初にお題と課題の制約がスライドで表示され、その後解説が行われるという、セッションを聞くだけでなく自分ならどうするか考えながら参加できるところです。
自分の考えと登壇者の考えのプロセスの違いを比較するのも楽しみの一つでした。
お題の1つ目はミッションクリティカルなシステム上ですべてのリソースを複数AZで冗長化しているシステムでの障害発生時の緩和策の検討でした。
想定障害としては、見る人によっては正常だったり異常となるグレー障害や機能を完全に失ってはいないが品質が低下しているブラウンアウトといった障害を想定しています。
また、リージョンを跨いだフェイルオーバーについてはトレードオフが伴うため単一リージョン内での対処を想定します。
構成としてはRoute 53と3AZに跨ったALBで構成されアプリケーションはEKSで稼働しています。
データベースとしてAmazon Aurora(以下Aurora)が使用され、リーダーインスタンスが1台とライターインスタンスが2台あります。 ALB→EKS→Auroraはフルメッシュで構成されています。
また制約事項として既存のサービスは別のサービスに置き換えたりすることはしないという条件があります。
このお題には、障害発生時のAZの独立性を高めるようにアーキテクチャを改善を行うという方針で解説がありました。
フルメッシュで構成されている構成をAZ間の独立性を高めるように改善していました。
ALBであればクロスリージョン負荷分散をオフにする、EKSであればAZ単位でFargate Profileを作成する、Auroraにはエンドポイントを作成するなどの対応があげられました。
また、AZ間の独立性を高めるだけではなく、AZの障害を検知する仕組みについても検討がされていました。
グレー障害やブラウンアウトに対してどのような事象が観測されるかの言語化とその事象をCloudWatchAlarmで設定するにはどのようにするかについて解説がありました。
複合条件での監視設計を筋道立てて解説されていたため、設定の意図が分かりやすく業務にも活用できそうでした。
お題の2つ目はサードパーティー製品の信頼性が低いシステムにおいてのサードパーティー製品とアプリケーションの依存関係の緩和がテーマのお題でした。
サードパーティー製品にリクエストが集中したらエラーレスポンスやパフォーマンスの悪化がある中でサードパーティー製品は使用しつつどのように改善するか問われてます。
構成としてはCloudFrontとS3、ALB、ECSの構成でDBとしてDynamoDBが使用されています。
また制約事項として既存のサービスは別のサービスに置き換えたりすることはしないという条件があります。
このお題には以下のような解説がありました。
アプリケーションとサードパーティー製品の間にプロキシサービスを緩衝機能として導入することが検討されました。
サードパーティー製品の負荷を減らすこととアプリケーションとサードパーティー製品を疎結合にすることが目的です。
緩衝機能も流量制限やサーキットブレーカー、非同期処理などいくつかの方法が考えられます。
どの機能を使うかについてはサードパーティー製品の要件に依存するため、今回はアプリケーションの要件として、書き込みか読み取りか、即応性が必要か不要かの4パターンでの整理が行われました。
その後、想定される障害でパターンごとの対応を検討していました。
以上、AWS Summit 2024のレポート記事でした。
今回は基調講演前までの流れも記載してみました。
今年参加ができず来年こそ参加しようと思っている方にも参考になればと思います。
また、セッションレポートで取り上げたアーキテクチャ道場 2024も自分で考えながら参加ができるセッションで、開始前の早い段階から席が埋まるセッションだったなという印象です。
また機会があれば参加してみたい内容でした。