id:kizashi1122 です。
先日 6/20-21 に幕張で開催された AWS Summit 2024 に参加してきました。 参加は去年に引き続き2回目です。
いやあすごい人ですね。 5万人が参加登録したとか。スポンサーがたくさんいるとは言え、参加費が無料なのもすごいです。
基調講演を含めてセッションやブースの数も多くいろいろ聞きましたが、すべて紹介するわけにはいかないので一つだけ。
AWS でレジリエントな分散システムを構築するためのデザインパターン
AWS 新谷さんのセッションです。
モノリスなアプリケーションには課題があります。
- 一つの機能障害がシステム全体の停止の繋がる可能性がある
- 機能ごとに異なる可用性や弾力性（レジリエンス）への対応が難しい
これらはマイクロサービスに分割することで機能ごとに異なる可用性要件を検討できると続きます。
モノリスを分散化していくことで、複雑性が生まれます。複雑性が増してもシステム全体としての可用性は維持する必要があります。そのための手段としては
- グレイスフルデグラデーション
- リトライとエクスポネンシャルバックオフ
- サーキットブレイカー
グレイスフルデグラデーション
ここでは（ECサイトの）Amazon を例にとって説明していました。
高負荷時は検索体験を下げる（検索結果の表示項目を最低限にする）ことを実現しているそうです。 ここまでコントロールできるのはすごいですね。
エクスポネンシャルバックオフ
これは弊社のサービスでも他サービス連携時に実装しています。 相手のサービスに負荷をかけないようにリトライ間隔を伸ばしていく仕組みですね。ただ30分のあとは60分、その後は120分となっても間延びしてしまうので、ある程度まで回数を重ねたときは同じ間隔にするなどの工夫をしています。
ここではサービス間の通信におけるリトライの話でした。
サーキットブレイカー
サーキットブレイカーはサービスとサービスの間に介在するサービスです。
サービスA -> サーキットブレイカー -> サービスB
という構成の場合、サービスBが落ちていたらサーキットブレイカーが即座にサービスBにエラーを返すような仕組みです。
このあと
このあとは架空のECサービスである「ユニコーンリテール」のECサイトを例に具体的に分散システム化していくという実践的な話につながります。ここではドメイン駆動設計を用いて分散化していきます。Sagaパターンやイベントソーシング、CQRS という設計で進めます。
詳細は省略しますが、最終的にこういう構成となっていました。
さらっとすごい構成がでてきましたが、これを実装・運用するのはなかなか大変そうです。
まとめ
弊社もそろそろこの辺りを考えていかないとなぁと思いながら聞いていました。
このあたりを一緒にやりたい！という人がいたら是非弊社まで！
