AWS Summit 2024のまとめ

AWS Summit 2024に参加してきました。以下は印象に残ったセッションのメモとなります。

目次

• AWS Summit とは?
• 個人的キーポイント
• セッションハイライト
  • レジリエントなサービス
  • 非同期システム
  • 超高負荷サービスを提供する工夫 (1 億台同時接続)
• 実践的な知識
  • 監視設計
  • AmazonQ
• 感想

AWSSummit Japan とは?

• AWS を利用する人々が集まる年 1 の イベント
  • ベンチャー/SI/ユーザー企業がそれぞれの目線でシステムについて語る
• 登録者 5 万人/150 以上のセッション/250 以上の展示
  • 10 以上のセッション (40min) が常時開催 6 term 2 day
  • どの会場も一杯で立ち見が発生する/事前予約必須
  • 展示はシステムのアーキテクチャの紹介やログ基盤/開発環境に関するツール企業 (NewRelic CloudFlare, HashiCorp etc.) など
• 早く行けば座布団と弁当がもらえる
• DJ の Live, QuizKnock のイベントもある
• お土産もたくさんもらえる

キーポイント

• 生成 AI
  • AWS は ChatGPT のような frontend アプリや API, 学習/推論の基盤など様々なフェーズをサポートできるように抑えている
• サーバーレス
  • サーバーを常時起動しない/オートスケーリングのサービス
  • 実行時間やリクエスト量に応じて課金
  • サーバーレスを活かしたアーキテクチャ紹介も多い
• レジリエントな (障害に強い) アーキテクチャ
  • AWS のデータセンターのいくつかが止まってもサービスは提供し続けることができるか
  • 突発的な負荷や外部要因による影響を最小限に留めることができるか

ハイライトセッション

レジリエントなサービス

• AWS-14 AWS でレジリエントな分散システムを構築するためのデザインパターン

• AWS-59 アーキテクチャ道場 2024!

• AWS はインフラの障害をサポートしない代わりに、障害につよいシステム構成を取ることを推奨する

• マイクロサービス特有のアーキテクチャーパターンが存在する

  • 例外の回し方
    • サーガパターン
  • 障害の影響を抑えるバルクヘッド
    • サーキットブレーカー

• バグや障害の分類や定義がある

  • ハイゼンバグ/繰り返し発生する
  • ボーアバグ/特定の状態で発生するバグ(本番システムの大部分はこっち, 大変)
    • 一部のサービスが落ちたら?
    • グレー障害/ブラウン障害

• クラウドやマイクロサービスのアーキテクチャのデザインパターンを知ることで、引き出しが増えそう

• 対障害性の高いシステム設計になるような勘所/工夫を知ることの重要性

非同期システム

• AWS-56 同期という思い込み 世界は非同期で構成されている

• 同期 (普通の) API も辛い

  • API の仕様が相互の契約となって頻繁な変更に対応できない　(マイクロサービスでもデリバリー速度は上がらない)
  • 一番遅いシステムの性能に全体の性能が引っ張られる
  • 障害の切り分けが大変

• 非同期 (Event) の良さ

  • producer と consumer が疎結合になる (独立してデプロイ/品質改善できる)
  • サービスが独立しているので障害を分離できる

• 豊富な顧客事例紹介

  • ふわっと Dynamo を置く決済完了通知サービス
  • SQS -> Lambda -> S3 -> SNS -> (SQS) でシステムをつなげる (POS データ処理)
    • Lambda -> S3 でデータを永続化しつつ Publisher (再送可能)
    • SNS が Queue (S3 の書き込みを受け取るため)
    • SQS+Lambda が Subscriber

デプロイの仕組みも自作しないといけない場合もある

• CUS-49 Nintendo Switch 向けプッシュ通知システムのリプレイス事例

• スリープモードでも常時通信する通知サービス

  • アプデ通知やフレンドのログイン情報通知/ゲームの通知など様々な通知が Nintendo Switch に送られている

• 1 億台が同時接続可能な性能要件

  • 1 タスクあたり同時接続が数十万/NLB を超えるとポートアロケーションエラーが起きる
  • NLB の設定 (クライアント IP 保持機能) を活用して制約を回避する

• デプロイにも工夫が必要

  • BlueGreen でデプロイすると 1 億台が同時に再接続しようとして落ちる
  • AZ ごとのタスク(Pod)のリバランスをして ALB の接続振り分けによって接続数の偏りをなくす工夫
  • 一時間かけて随時通信を新しいシステムにつなぎ直すようにクライアントに依頼することで時間をかけてデプロイする

実践的な知識

監視設計

CloudWatch Metrics を利用した監視設計が紹介されていた。

1. ログから監視 ログを filter してメトリクス化する アラーム設定する(具体的な例)

2. 複合メトリクス アーキテクチャー道場の例をもとに説明する

Amazon Q (Business)

• chatGPT Browser の Amazon 版
• 多様なコネクタ
• slack や Teams の会話ログ, Confluence, Box, github などたいていの Connector があり設定をすればローカル LLM が作成できる
• Connector がなくても S3 においておけば OK

総括と展望

• システム開発のモチベーションが上がる
  • レガシーシステムをどう改善していくかの工夫や取り組みを聴ける
  • AWS のサービスを活用した豊富な事例紹介
  • 仕事のシステムのアーキテクチャとの類似性を見つけたときの感動