AWSのシニアプリンシパルソリューションアーキテクトであるMichael Haken氏は、Amazon社の運用・アーキテクチャ戦略を通じたクライアント管理や十分なサービス保護構築方法を、ランチで込み合う時間のレストラン対応になぞらえて説明している。「Resilience lessons from the lunch rush （ランチ対応に学ぶレジリエンス）」では、自動キャパシティ予測や負荷制限の実装といったクラウドプロバイダーによるキューの深さ管理に向けた戦略が共有されている。
同記事では、自動キャパシティ予測やオートスケーリングが需要の大きく先を行くサービス提供にいかに貢献しているか、また同社がキャパシティバッファ提供にオーバープロビジョニングを推奨する理由が記載されている。Haken氏は、レストランでの繁忙時間の注文対応とクラウドレジリエンスシステム構築工程との類似点を、次のように説明している。
レストランでは、顧客需要（負荷）とサービス時間（レイテンシ）を管理し、顧客体験の期待値に応えることが求められます。（中略）弊社では、需要とサービス時間の管理に運用上のアプローチも採用しています。これらの手法は、オーダー負荷や待ち時間が増大し始めた際に、レストラン勤務時に用いていた対応方法です。また、私の勤めていた別のレストランでは、構造的アプローチも取り入れていました。レストランのシステムとワークフローは、過負荷の発生防止に向けたシステム設計やワークフロー設計がなされていたのです。
Haken氏は、極端な過負荷のシナリオはクラウドでは稀なイベントであるとしたうえで、こうした例外的なイベントが発生した場合に備えて、顧客体験に影響が及ばないようにする様々な戦略があると述べている。監視システムが過負荷状況を検知した後で対応する運用戦略もあれば、サービス設計の一部として組み込まれているアーキテクチャ戦略も用意されている。また、クライアントの管理・構築パターンも設けられている。
推奨される運用戦略としては、負荷制限、オートスケーリング、公正性の3つがある。負荷制限では、一時的な負荷の急増時に意図的な作業の取り除きを一時的に実施することで、作業への影響を防ぐ方法である。Haken氏は次のように注意を促している。
負荷制限の効果は顧客にランダムな影響を与えることが多く、負荷管理の手段としては雑多と言えます。負荷制限でサービス回線が拡張し、高いグッドプットが維持されますが、顧客体験にも影響を及ぼします。そのため、こうした状況に備えた唯一のソリューションとしては、好ましいものではないのです。
/filters:no_upscale()/news/2025/03/aws-resilence-best-practices/en/resources/1Resilience%20pic%2013.8de3d13402c1148c5a3fc53c59bc76558b54a113-1740771959553.jpg)
出典:AWSドキュメント
公平性とクォータ管理は、マルチテナント環境での統一されたシングルテナント体験を提供しているほか、レート制限のある顧客がクォータを超過した場合、トークンバケット、リーキーバケット、指数加重移動平均（EWMA）、固定ウィンドウ、スライディングウィンドウといったアルゴリズムを通じてクォータ超過を通知するのに役立っている。上記の代わりに、自動キャパシティ予測が十分なキャパシティ確保に向けた主要戦略であると考えられている。
今回の記事では、過負荷を防ぐために4つのアーキテクチャ戦略が推奨されている。 コールドキャッシュの回避、キューの深さの管理、コンスタントワーク、小規模なサービスの制御（control plane and data planeの利用を推奨）の4点だ。 コンスタントワークでは、負荷やストレスに応じたシステムのスケールアップやスケールダウンを行わない。こうすることで、ほぼすべての条件で処理量が一定化され、負荷の予測が可能になっている。
同社では、ストレス実行中に依存関係への影響が出ないよう、クライアント管理に向けた2つのパターンが提案されている。サーキットブレイカーと再試行である。前者は依存関係の持続的な過負荷を防ぐものである。一方で、後者は、リクエストと再試行の間でジッターを伴うエクスポネンシャルバックオフを追加し、すべてのリクエストの再試行を最大再試行回数値、N回まで可能にしている。 Haken氏は、上記のどのアプローチの実行も慎重に行うよう注意を呼び掛けている。
弊社では、サーキットブレーカーの利用に慎重を期しており、複数の依存関係を一様に扱うことはありません。依存関係は、単一のパーティション、障害分離境界、ホスト、顧客といったさまざまな次元で障害に見舞われることがあります。このため、弊社のサーキットブレーカーは「全体の依存関係」より適用範囲が細分化されており、各依存関係で予測される障害ドメインに合わせた調整がなされています。
/filters:no_upscale()/news/2025/03/aws-resilence-best-practices/en/resources/1resilience_Picture10.cbd4872052b6a9d69f86f8a31c9f6330e7b73017-1740771959553.jpg)
出典:AWSドキュメント
以下は、Amazon社CTOであるWerner Vogels氏の総括である。
負荷管理は私たちの身の回りに溢れており、ランチ対応にあえぐレストランから、何百万ものリクエストのバランスを図るクラウドシステムにまで及びます。Mike Haken氏による『The Amazon Builders' Library』最新記事が、「迅速な検出、早期の対応、円滑な鎮静化」という原則がいかに普遍的であるかを物語っています。
Jitterbit社CTO兼エンジニアリング部門SVPのManoj Chaudhary氏はこう述べている。
素晴らしい記事ですね！重要なのは、問題の早期検出と行動です。 SaaS業界やレストラン業界では、負荷の急増、バグ、または食器を落としてしまうといった予期しないインシデントでサービスに負担がかかることがあります。鍵となるのは、こうした問題の早期検出、対応、十分なキャパシティの確保により、スムーズな顧客体験を提供することです。業界分野に関わらず、従業員間の混乱を防ぐことが求められます。
「Resilience lessons from the lunch rush （ランチ対応に学ぶレジリエンス）」は、現在『The Amazon Builders' Library』に収録されており、他のクライアントサーバーパターンのリソース参照も掲載されている。
作者について
