若手エンジニアがAWS Summit TOKYO 2023に参加してきました! part.4

はじめに

はじめまして。 プラットフォームサービス開発部の宮木です。
弊社AIサービスのインフラ基盤運用を行っています。

AWS Summit Tokyo 2023 関連のこの連載も最後、4本目となります。
私はこの手のイベントには初めて参加しました。Day 2 のみでしたが、クラウド活用に高い関心を持つ方々が一堂に会して示された事例や未来像は興味深く、お祭りのような大規模会場の雰囲気が楽しかったです。

part.3 まではこちら

既にさまざまな方がセッションレポート等を公開されていますが、私も以下のセッションについてお伝えできればと思います。

  • Everything fails, all the time:分散システムにおける耐障害性のある設計について

jpsummit.awsevents.com

分散システムの特徴の一部について理解するのに良い内容でした。 ここでは全体的な流れと詳細は他の記事にお譲りし、私のような初心者向けにいくつかのキーワードを取り上げて記載したいと思います。

  • エクスポテンシャルバックオフ
  • ジッター
  • サーキットブレイカーパターン
  • ポリグロット・パーシステンス
  • Sagaパターン
  • カオスエンジニアリング

分散システムと耐障害性に関するキーワード

分散システムにおける連携には、ネットワークを介したメッセージの要求/応答 が用いられており、システム全体は複雑なものになります。 従って分散システムには多くのネットワーク由来の問題が引き起こされます。
セッションはこれらをいかに防ぎ対処するかというお話でした。 それらに関する基本的な概念やキーワードを簡単に解説します。

エクスポテンシャルバックオフ

ネットワークの通信エラーに対してリクエストを再試行する際に一定の待機時間を設け、それを徐々に長くすることです。 再試行の頻度低下によって通信処理の負荷を軽減できます。

ジッター

ネットワークにおいては主に、レイテンシーの通常の測定値からの揺らぎのことを指します。 ストリーミング等において、ジッターが大きいことでデータが失われたり順序が乱れたりすることで挙動が不安定になるので、好ましく無いものとされています。

セッションにおいては、通信負荷を更に低減する要素として取り上げられていました。 エクスポテンシャルバックオフの待機時間にランダム性を追加し、再試行のタイミングを広く分散させることができます。

サーキットブレイカーパターン

分散システムの設計パターンの一つで、サービスの障害状況に応じて呼び出しを停止するかどうか制御します。 アプリケーションが失敗する可能性のある操作を繰り返し試行するのを防ぎ、障害の伝搬を抑制してサービスの安定性と回復性を向上させます。
アプリケーション側にライブラリを用いたり、サービスメッシュを用いて実装できるようです。

セッションでは、AWS Step Function 等のワークフロー管理ツールを用いる方法が紹介されました。

ポリグロット・パーシステンス

各マイクロサービスに独自のデータストアを持たせて分散化することを指します。 それぞれの特性に応じた最適なデータストアを選択でき、性能改善が期待できます。 一方で課題として、データの一貫性や整合性が保たれるように構造化することが必要です。

セッションでは、後述する Sage パターンを用いてこれを有効化する方法について取り上げられていました。

Sagaパターン

複数のマイクロサービス間のトランザクションを調節して、データの一貫性を管理する方法です。Saga はこのシーケンスのことを指します。
トランザクションの実行がサービス間を連鎖していく中で、いずれかが失敗したりタイムアウトしたりした場合、それ以前のトランザクションによる変更の取り消しを逆順に処理することによってデータの一貫性を保ちます。
留意すべき点としては、デバックが難しく構成要素が増えると複雑さがさらに増すことです。発生する可能性のある一連の障害を処理できるためには、処理の冪等性と可観測性が重要になります。

カオスエンジニアリング

昔 Netflix による取り組みとして有名になったようで、以下のように紹介されています。

カオスエンジニアリングは、システムが本番環境における不安定な状態に耐える能力へ自信を持つためにシステム上で実験を行う訓練方法です。

詳しい話はちょっと自信が無いのですが、簡単に言うと、カオスは比較的簡単な規則に支配された不規則振動のことを指します。
初期条件の微小な違いが長期的に全く異なる振る舞いをもたらすので、システムの変化を予測することは困難になります。(初期値敏感性と予測不可能性) ただ、カオスは決定論的であり、これに当てはまるのであれば挙動の予測は不可能でも法則は明らかにできるかもしれません。
つまり、分散システムはカオス的に振る舞うことがあるため、この条件を経験によって探り、対策しようということです。

感想

難しかったです。 普段の業務でAWSに触れている際にはあまり意識していませんでしたが、サービスの根底にはさまざまな研究があることを感じました。
また、開かれた場でそうした考えに触れるのも有意義な体験だったと思います。皆で知見を持ち寄って追究するというのがとても楽しそうなので、理解を深めて自分も議論に参加できるようになりたいものです。

おわりに

これで AWS Summit Tokyo 2023 関連のこの連載も終了です。ご覧いただきありがとうございました。
マイクロサービスのより良い実践を目指します。

OPTiMではクラウドサービスを活用したインフラ構築・運用に関する活動に興味のある方を募集しています。

www.optim.co.jp