3.5 スケーラビリティ、パフォーマンス、レジリエンス

概要と動機

スケーラビリティ、パフォーマンス、レジリエンスは三つの別個の品質ですが、人々はしばしばそれらをぼかして一つにします。パフォーマンスは、システムがどれだけ速く応答し、資源の単位あたりにどれだけの仕事をするかです。スケーラビリティは、負荷が増えるにつれて、性能をどれだけ維持できるかです。レジリエンスは、物事が失敗したときに、どれだけうまく動き続けるか、あるいは穏やかに縮退するかです。システムは、速いがスケールしない(低負荷では優れるが、高負荷で崩壊する)こと、スケールするが脆い(量は扱えるが、一つのコンポーネントが失敗すると倒れる)こと、あるいは信頼できるが遅いことがありえます。大きな組織は三つすべてを、最初から設計に組み込んで必要とします。ローンチ後にそのどれかを後付けするのは、高価で混乱を招くからです。

企業や政府のシステムにとって、これらを誤った結果は公的で深刻です。新しい制度の初日に崩れる給付のポータル、期限にタイムアウトする申告システム、買い物のピーク時にダウンする決済プラットフォームを考えてください。これらは、見出しになり、調査を引き起こし、公的な信頼を損なう失敗です。これらのシステムはまた、非常にピークの立った、しばしば法的にタイミングが決まった負荷(申告の期限、登録の期間、給料日)と、厳格な可用性と復旧の義務に直面します。予測可能な急増に備えてキャパシティを計画し、予測できないものには穏やかに縮退し、災害の後は定義された時間とデータ損失の限度内に復旧しなければなりません。これは、公的な説明責任の次元を持つエンジニアリングです。

本章は、水平対垂直のスケーリング、スケールを可能にするものとしてのステートレス性とシャーディング、負荷分散、オートスケーリングとキャパシティプランニング、明示的な予算を伴うパフォーマンスエンジニアリング、レジリエンスのパターンとカオスエンジニアリング、そしてRTO、RPO、事業継続で枠づけられるマルチリージョンの災害復旧を扱います。統一するメッセージは、これらの品質は、希望ではなく、意図した設計と継続的なテストの産物だということです。

関連項目: 3.3章(分散システム)、9.1章(サイト信頼性エンジニアリング)、9.2章(オブザーバビリティと監視)。

主要原則

スケールアップではなく、スケールアウトのために設計する。 垂直スケーリングには天井と単一障害点があります。水平スケーリングが、大きく信頼できる規模に達する方法です。
ステートレス性が水平スケールを可能にする。 どのリクエストもどのインスタンスにも行けるなら、自由にキャパシティを追加したり取り除いたりできます。
測定しないものは改善できない。 性能の仕事は、当て推量ではなく、明示的な予算に対するプロファイリングと負荷テストによって駆動されます。
すべては失敗する。そのために設計する。 コンポーネントが失敗すると想定し、その失敗をシステムが生き延びるように築きます。
穏やかな縮退は、ハードな失敗に勝る。 必須でない機能を切り捨てる部分的に動くシステムは、全面的な障害よりましです。
キャパシティは計画され、急増は吸収される。 予測可能な負荷を予測し、残りにはオートスケーリングと余裕を使います。
復旧目標はビジネスの決定である。 RTOとRPOはコストに対してビジネスによって選ばれ、それからそれに向けてエンジニアリングされます。
レジリエンスを意図してテストする。 システムを意図して失敗させるまで、それがレジリエントかどうかはわかりません。

推奨事項

水平スケーリングを好み、ステートレスなサービスを設計する

垂直スケーリング(より大きなマシン)は単純で、ときに正しい最初の一歩ですが、硬い天井に当たり、上位で不釣り合いに高価になり、単一障害点を残します。水平スケーリング(負荷分散装置の背後のより多くのマシン)ははるかに遠くまでスケールし、一つのインスタンスの喪失が生き延びられるので、可用性を改善します。前提条件はステートレス性です。クライアントのセッションやリクエストの状態をインスタンスに持たせず、共有のストア(データベース、キャッシュ、トークン)に押しやります。ステートレスなサービスは、自由に追加、削除、置き換え、負荷分散でき、それがオートスケーリングとローリングデプロイの両方を可能にするものです。状態を分割しなければならない所では、負荷を均等に分散し、関連するデータを同じシャードに保つキーでシャードします。

負荷分散し、オートスケールし、キャパシティを計画する

スケールされたすべての層の前に負荷分散装置を置き、トラフィックを分散し、ヘルスチェックを通じて不健全なインスタンスを迂回してルーティングします。先行指標(CPU、リクエストキューの深さ、レイテンシ)が閾値を超えたらキャパシティを追加し、負荷が下がったら取り除くようオートスケーリングを設定します。急増に遅れることも、振動することもないよう、スケーリングの速度とクールダウンを調整します。オートスケーリングはキャパシティプランニングの代わりにはなりません。予測可能でビジネスに重要な急増(税の期限、登録期間、販売イベント)については、負荷を予測し、キャパシティを事前にプロビジョニングまたはウォームアップし、その目標に向けて事前に負荷テストします。オートスケーリングだけでは、段階的な変化に即座には反応できず、コールドスタートは、最も余裕のないまさにそのときにレイテンシを加えます。常に余裕を保ってください。100%で動かすことは、急増や失敗を吸収する余地を残しません。

明示的な予算に対してパフォーマンスをエンジニアリングする

性能予算(p95のAPIレイテンシが200ミリ秒未満、ページが2秒未満で対話可能、トランザクションあたりのコストが閾値未満といった具体的な目標)を設定し、テストと監視で徹底して、回帰がユーザーに届かずにパイプラインを失敗させるようにします。最適化を測定で駆動します。実際のボトルネックを見つけるためにプロファイルします。それは推測した所にまずなく、システムがどこで壊れ、その限界の近くでどう振る舞うかを見つけるために負荷テストします。クリティカルパスと裾(p95/p99)に集中します。規模では、裾のレイテンシがユーザー体験を支配するからです。最大のボトルネックを最初に最適化し、再測定し、予算を満たしたら止めます。すでに十分なコードの過剰な最適化は、無駄な労力です。

レジリエンスのパターンを組み込み、カオスエンジニアリングで検証する

分散システムのレジリエンスのパターンを適用します。タイムアウト、バックオフ付きの上限付きリトライ、サーキットブレーカー(依存先が不健全なときに速く失敗する)、バルクヘッド(一つの失敗が残りを使い果たせないよう、リソースプールを隔離する)、そして穏やかな縮退(ストレス下で必須でない機能を切り捨てるか単純化する。推薦を無効にする、キャッシュされたコンテンツを提供する、緊急でない仕事をキューに入れる)と負荷の切り捨て(完全に崩壊するのではなく、中核を守るために過剰なリクエストを拒否または絞る)。あらゆる層の冗長性で、単一障害点を排除します。それから、カオスエンジニアリングでレジリエンスを検証します。制御された実験で意図して失敗を注入し(インスタンスを殺す、レイテンシを加える、依存先を切断する、ゾーンを失敗させる)、テストから始めて本番のゲームデーへと成熟させ、システムが設計どおりに振る舞うことを証明します。テストされたことのないレジリエンスは、仮説にすぎません。

マルチリージョン、災害復旧、事業継続を計画する

復旧目標を明示的に決めます。RTO(目標復旧時間、どれだけ停止できるか)とRPO(目標復旧時点、どれだけのデータ損失を許容できるか)。これらは、コストへの直接の影響を伴うビジネスの決定であり、アーキテクチャを駆動します。選択肢は、コストと速度で幅があります。バックアップと復元(最も安く、最も遅い)、パイロットライト、ウォームスタンバイ、アクティブ・アクティブのマルチリージョン(最も高価で、ほぼゼロのRTO/RPO)。各システムの重要度が正当化する階層を選びます。すべてがアクティブ・アクティブを必要とするわけではありません。選んだRPOに合わせてリージョン間でデータをレプリケートし、フェイルオーバーを自動化し、何よりも、フェイルオーバーを定期的にテストします。テストされていない災害復旧は、ようやく必要になったとき、確実に失敗します。これらすべてを、技術だけでなく、人、コミュニケーション、手作業のフォールバックを網羅する事業継続計画で包みます。

トレードオフ: 長所と短所

選択	長所	短所
垂直スケーリング	単純。コードの変更なし。初期の労力が少ない	硬い天井。上位で高価。単一障害点
水平スケーリング	ほぼ無制限のスケール。可用性を改善する	ステートレス性、負荷分散、より多くの運用が必要
オートスケーリング	コストを需要に合わせる。変動する負荷を扱う	遅れて反応する。コールドスタート。誤調整すると振動する
アクティブ・アクティブのマルチリージョン	ほぼゼロのRTO/RPO。リージョンの喪失を生き延びる	最高のコストと複雑さ。データの一貫性が難しい
バックアップと復元のDR	最も安く、最も単純	長いRTO。大きなデータ損失の窓

中心的なトレードオフは、コストと保証です。スケーラビリティの余裕、性能、復旧能力の一段ごとにお金と複雑さがかかり、見返りは非線形です。99.9%から99.99%の可用性へ、あるいは1時間のRTOから数秒へ上げることは、コストを何倍にもしえます。規律は、すべてを反射的に最高の階層にエンジニアリングするのではなく、システムの実際の重要度と、ビジネスのダウンタイムとデータ損失への許容度に、各投資の大きさを合わせることです。市民向けの決済システムはアクティブ・アクティブの冗長性に値し、社内のレポートツールは値しません。

チームで議論すべき問い

直近の深刻なインシデントが起きたとき、三つ(性能、スケーラビリティ、レジリエンス)のどれが実際に失敗し、正しいものを直しましたか。 本章は意図してそれらを分けています。システムは、速くても負荷のもとで崩壊し、スケールしても一つのコンポーネントが死ぬと倒れ、失敗を生き延びても遅いことがありえます。チームはしばしば誤診します。レジリエンスの問題にキャパシティを加えたり、単に急増に対してプロビジョニングが不足していたシステムを堅牢化したり。直近の二つの深刻なインシデントをたどり、どの品質が壊れたか、対応が実際に何を改善したかを名指ししてください。その区別が修正を変えます。スケールにはステートレス性とシャーディング、レジリエンスには冗長性とサーキットブレーカー、性能にはプロファイリングと予算。カテゴリを正しくすることが、治療に支出するか、症状に支出するかの違いです。
性能の回帰はパイプラインを失敗させますか。それとも、誰かが気づく前にユーザーに届いていますか。 性能予算(p95のレイテンシ、ページが対話可能になるまでの時間、トランザクションあたりのコスト)は、自動的に徹底されるときにだけユーザーを守ります。それを吹き飛ばす変更が、出荷されずにビルドを失敗させるように。多くの貢献者を持つ大きなチームでは、レイテンシは千の小さなコミットを通じて忍び込み、ゲートがなければ、ローンチがそれを露わにするまで裾はゆっくり腐ります。現在の予算を持ち込み、それがCIと監視に組み込まれているか、平均ではなくp95とp99を対象にしているかを確認してください。規模では、ユーザーが感じるのは裾だからです。予算がない所では、設定することが最初の一手です。徹底が、良い意図を、チームの成長を生き延びる性質に変えます。
ストレスのもとで、何が最初に切り捨てられ、その順序を設計しましたか。それとも障害の中で発見しますか。 穏やかな縮退と負荷の切り捨ては、システムが中核を守るために必須でない仕事を手放すことを意味しますが、それは何が必須かを前もって決めている場合にだけです。市民向けのサービスでは、その順位付けはしばしば方針の決定です。状況ダッシュボードや過去の検索が暗転しても、税の申告の提出は生き延びなければなりません。誰も選んでいなければ、システムは最初に失敗するものを切り捨て、それはユーザーが最も必要とするまさにそのものかもしれません。機能を優先順位順に一覧にし、アーキテクチャが、優先度の低いもの(キャッシュされた応答、無効化された推薦、キューに入れられた緊急でない仕事)を、クリティカルパスを巻き込まずに落とせることを確認してください。それから本物の負荷のもとでテストします。テストされていない縮退は、希望にすぎないからです。
最も重要なシステムのRTOとRPOは何で、その数字を実際に選んだのは誰で、それを満たせると最後に証明したのはいつですか。 目標復旧時間(どれだけ停止できるか)と目標復旧時点(どれだけのデータ損失を許容できるか)は、コストへの直接の影響を伴うビジネスの決定ですが、大きなチームでは、サービスに責任を負う人々が所有するのではなく、ランブックを書いた人によって考案されることがよくあります。相反する引力はコストと保証です。RTOを1時間から数秒に、RPOを数分からゼロに縮めることはインフラの請求を何倍にもしえるので、正しい数字は最も印象的なものではなく、ビジネスが実際に払うものです。文書化された目標、最後の本物のフェイルオーバーのテストの日付、そのテストが生んだ測定された時間とデータ損失を持ち込んでください。テストされていない目標は願いだからです。企業や政府の設定では、これらの数字は法律、契約、SLAによって定められることがあるので、誰が承認し、最後のリハーサルが義務を満たしたのか、静かに外したのかを名指ししてください。
最大の予測可能な急増に対して、オートスケーリングがその場で反応することを信頼していますか。それとも、負荷を予測し、事前にプロビジョニングし、その目標に向けて負荷テストしましたか。オートスケーリングは遅れて反応し、コールドスタートは最も余裕のないまさにそのときにレイテンシを加えるので、既知の段階的な変化(申告の期限、登録期間、販売イベント)は、まさに反応的なスケーリングが失敗し、意図したキャパシティプランニングが勝つケースです。緊張はコストです。ピークのためにキャパシティをウォームアップすることは、一年のほとんどを遊ぶ余裕に払うことを意味し、オートスケーリングがそれをただでカバーしてくれることを願いたくなります。昨年のピークの数字、成長を伴う今年の予測、今日の平均トラフィックではなくその予測の倍数に向けて実行された負荷テストの結果を持ち込んでください。法的にタイミングが決まった急増に直面する政府や企業のサービスでは、間違えた結果を加えてください。初日に崩れる給付のポータルや税のシステムは、遅い午後ではなく、公的な調査になるからです。
本番でコンポーネントを意図して失敗させたことはありますか。そして各システムの冗長性の階層は、その重要度とコストに実際に合っていますか。テストされたことのないレジリエンスは仮説であり、買える階層は、安いバックアップと復元から、ウォームスタンバイ、高価なアクティブ・アクティブのマルチリージョンまで幅があるので、規律は、すべてを金メッキするのでも、何も守らないのでもなく、保証を正当化される所に費やすことです。相反する考慮は、影響範囲と予算です。カオス実験にはガードレールと中止のスイッチが必要で、社内のレポートツールのアクティブ・アクティブは無駄ですが、決済プラットフォームのバックアップのみは怠慢です。単一障害点の一覧、各重要なシステムの冗長性の階層、最後の制御された障害注入とそれが明らかにしたことの証拠を持ち込んでください。企業や政府のポートフォリオでは、各階層を文書化された重要度の格付けに対応づけ、監査人がお金がリスクに従っていることを見られるようにして、障害の最中に初めて誰かが支出を弁護しなくて済むようにします。

セクター別の視点

スタートアップ。 ローンチが50人のサインアップをもたらすか5万人をもたらすかは予測できないので、スケールを作るのではなく買ってください。マネージドな負荷分散装置の背後でステートレスなサービスを動かし、プラットフォームにリクエスト率でオートスケールさせます。控えめな性能予算を一つ設定し、スパイクが午前2時の再アーキテクチャを強いないようにマネージドなデータストアを選びます。マルチリージョンの災害復旧とカオスのプログラムは今は省き、テストされたバックアップを保ち、乏しいエンジニアリングの注意を、トラフィックがまだ正当化しない冗長性ではなく、製品に使います。

小規模事業者。 レジリエンスの専門家はおらず予算も厳しいので、作るか買うかの選択は強く買うへ傾きます。マネージドなプラットフォームやサーバーレスのスタックは、スケーリングとフェイルオーバーをプロバイダーの仕事にし、通常はよく運用された単一のリージョンで十分です。レジリエンスを、守れる少数の具体的な約束として枠づけます。実際に一度復元したことのある夜間バックアップや、顧客に伝えた現実的な復旧の窓。トラフィックもスタッフも正当化しないアクティブ・アクティブや継続的な負荷テストにお金を払うのは避けてください。

大企業。 問題は多数のチームにわたる一貫性です。CIで徹底される性能予算、レジリエンスのパターン(タイムアウト、サーキットブレーカー、バルクヘッド)の共有ライブラリ、そして各システムの重要度に結びついた冗長性の階層の文書化を標準化します。アクティブ・アクティブのマルチリージョンは第一階層のサービスのために取っておき、ガードレールを伴うカオスエンジニアリングのプログラムと本番のゲームデーを実施し、既知の急増のキャパシティプランニングを後付けではなく、スケジュールされた規律として扱います。RTOとRPOを中央で統治し、すべての重要なシステムに、監査人が検証できる、所有されテストされた目標を持たせます。

政府。 負荷はしばしば法的にタイミングが決まり、可用性の義務は法定なので、キャパシティプランニングは、オートスケーリングがその場で反応することに頼れません。期限の急増を予測し、事前にプロビジョニングし、予測をはるかに上回って負荷テストします。調達では、RTO、RPO、リハーサルされたフェイルオーバーのスケジュールを、ベンダーの約束ではなく契約上の要件として指定し、重要なサービスの単一リージョンへのロックインを避けるべきです。どの経路が法的に不可欠か(申告の提出、給付の申請)を前もって決め、縮退が状況ダッシュボードと検索を最初に切り捨てるようにし、誰も気づかないことを願うのではなく、障害と復旧について公衆に透明であってください。

事例

スタートアップ。 Product Huntでローンチする小さなスタートアップは、50人のサインアップか5万人かを予測できないので、サービスをステートレスなままマネージドな負荷分散装置の背後に置き、プラットフォームにリクエスト率でオートスケールさせます。控えめな性能予算(ページが95パーセンタイルで300ミリ秒未満で応答する)を一つ設定し、スパイクが午前2時の再アーキテクチャを強いないようにマネージドなデータベースを選びます。ローンチ日の急増が実際に来たとき、サイトは倒れるのではなく少し遅くなり、チームは障害と戦う代わりに、新しいユーザーと話してその日を過ごします。

大企業。 ストリーミングメディアの会社が、グローバルな負荷分散の背後で、複数のリージョンにわたってステートレスなサービスを運用し、毎日のゴールデンタイムの波を追ってリクエスト率でオートスケールします。性能予算は、p99の再生開始レイテンシで、すべてのリリースをゲートします。リージョンの障害のもとでは、トラフィックが健全なリージョンに自動的に移り、必須でない機能(パーソナライズされたアートワーク、推薦の更新)が、再生を守るために最初に縮退します。会社は本番で継続的なカオス実験を実施し、日常的にインスタンスを終了させレイテンシを注入するので、本物の失敗が訓練と区別できず、顧客に見える障害を起こしません。

政府。 税務当局は、申告システムが毎年、法的に固定された期限の巨大な急増に直面することを知っています。オートスケーリングがその場で反応することに頼るのではなく、過去の年からピークの負荷を予測し、数週間前にキャパシティを事前にプロビジョニングし、予測の150%まで負荷テストします。アーキテクチャは、ウォームスタンバイの第二リージョンを伴う、負荷分散装置の背後のステートレスなものです。RTOとRPOは方針で定められ(提出された申告について、ダウンタイムは15分以内、データ損失はほぼゼロ)、フェイルオーバーは四半期ごとにリハーサルされます。極端な負荷のもとでは、必須でない機能(状況ダッシュボード、過去の検索)が最初に切り捨てられ、法的に不可欠な経路である申告の提出が利用可能なままになります。

ビジネスケース: 動機、ROI、TCO

スケーラビリティ、パフォーマンス、レジリエンスは、失敗のコストが予防のコストをはるかに上回る典型的なケースです。しかし予防は予算に見え、失敗は潜在的なものにすぎないので、最初の災害まで慢性的に資金不足です。採用のコストは本物です。冗長なインフラ、マルチリージョンのキャパシティ、負荷テストとカオスのツール、ステートレス性とレジリエンスのパターンを築くエンジニアリングの時間。投資しないコストは、需要のピーク時の目立つ障害です。商取引では分単位の収益の損失、政府では逃された法定の義務と公的な調査、サービスレベル合意(SLA)のペナルティ、そして持続的な評判の傷。

ビジネスがすでに理解している数字でリーダーシップに論拠を示してください。ピーク時の1時間のダウンタイムのコスト(失われたトランザクション、ペナルティ、是正、評判)を見積もり、それを防ぐ冗長性とテストの年間コストと比べます。重要なシステムでは、予防はほぼ常に、一回の大きなインシデントの何分の一かです。RTOとRPOを明示的なお金に結びつけます。ダウンタイムの1時間あたりの収益やトランザクション数、法的または商業的にどれだけのデータ損失が許容できるか。性能を、収益と満足のてことして示してください。速いシステムはコンバージョンが良く、トランザクションあたりのコストが低いからです。そしてレジリエンスを、保険料がカバーされる損失に対して小さな保険として示します。最も強い論拠は、これらの品質は設計に組み込むのが安く、問題を強いる障害の後に後付けするのは破滅的に高いということです。

アンチパターンと落とし穴

スティッキーセッションとインスタンス内の状態。 サーバーにセッション状態を保存し、自由な水平スケーリングと安全なインスタンスの置き換えを妨げること。
キャパシティプランニングとしてのオートスケーリング。 反応するには遅すぎる、既知の段階的な急増を、オートスケーリングが吸収すると想定すること。
余裕なしの高負荷運用。 ほぼ100%の使用率で運用し、急増や失敗を吸収する余地を何も残さないこと。
プロファイリングなしの最適化。 本物のボトルネックが手つかずのまま、ボトルネックでないコードを調整すること。
裾の無視。 p99のユーザーが苦しむ間に平均のレイテンシを報告すること。平均は規模での痛みを隠します。
テストされていない災害復旧。 一度も実行されず、必要なときに失敗するDR計画とバックアップ。
単一障害点。 一つの負荷分散装置、一つのデータベースのプライマリ、一つのリージョン。すべてを落とす冗長性のないコンポーネント。
ガードレールのないカオスエンジニアリング。 影響範囲の管理も中止のスイッチもなく失敗を注入し、防ぐつもりだったまさにその障害を引き起こすこと。

成熟度モデル

レベル1: 開始。 場当たり的で反応的です。単一のインスタンスか垂直にスケールされ、状態がサーバーに保持されています。負荷テストも性能予算もなく、誰も復元したことのないときどきのバックアップを超える災害復旧もありません。どのコンポーネントの失敗も全面的な障害を引き起こし、スケールの問題は本番で発見されます。
レベル2: 発展。 基本的な実践が現れますが、チームごとに異なります。一部のサービスは、負荷分散装置の背後で水平にスケールされステートレスで、いくつかに基本的なオートスケーリングがあります。負荷テストは大きなローンチの前には行われますが、日常的ではなく、バックアップは存在し、災害復旧は文書化されているがめったに実行されません。あるチームがうまくやることを、別のチームはまだ始めていません。
レベル3: 標準化。 実践は文書化され、組織全体で徹底されています。キャパシティは余裕を伴って既知の急増のために計画され、性能予算はCIで徹底されて回帰はビルドを失敗させ、レジリエンスのパターン(タイムアウト、上限付きリトライ、サーキットブレーカー、バルクヘッド)と穏やかな縮退が既定です。RTOとRPOはシステムごとに定義され、冗長性の階層は重要度によって割り当てられ、災害復旧のフェイルオーバーは、チームにわたって定期的なスケジュールでテストされます。
レベル4: 管理。 品質は、ベースラインに対して測定され、制御されます。チームはp95とp99のレイテンシ、エラーバジェット、予測に対する使用率と余裕を追跡し、ローンチ時に発見するのではなく、違反にアラートを出します。テストされたフェイルオーバー時間は目標のRTOとRPOと比較され、縮退と負荷の切り捨ての閾値は指標で検証され、リリースとキャパシティの継続・中止の判断はデータで駆動されます。数字がベースラインからずれたとき、そのギャップは平均の陰に隠されず、見えて所有されます。
レベル5: オーケストレーション。 スケーラビリティ、パフォーマンス、レジリエンスは、組織全体で継続的に改善され、統合されます。アクティブ・アクティブのマルチリージョンは重要度が正当化する所で使われ、カオスエンジニアリングは本番のゲームデーを含めて継続的に実行され、キャパシティの予測は計画と調達に直接反映されます。レジリエンスは継続的に検証され、復旧目標は一貫して満たされ証明され、アーキテクチャは負荷パターンとリスクの状況の変化に応じて適応し、事業継続とリスクの計画に結びつけられます。

議論のためのアイデア

サービスのうち、どれがまだインスタンスに状態を保持していて、ステートレスにするのを何が妨げていますか。
最も重要なシステムのRTOとRPOは何で、誰が設定し、それを満たせると最後に証明したのはいつですか。
オートスケーリングは、最大の既知の急増に対してあなたを実際に守りますか。それとも、できないことをするよう頼っていますか。
残っている単一障害点はどこで、それを取り除く計画は何ですか。
p99のレイテンシを測定して予算化していますか。それとも平均の陰に隠れていますか。
本番でコンポーネントを意図して失敗させたことはありますか。ないなら、レジリエンスが機能することをどうやって知りますか。

要点

パフォーマンス、スケーラビリティ、レジリエンスを区別します。大きなシステムは、最初から設計に組み込まれた三つすべてを必要とします。
水平スケーリングとステートレスなサービスは、スケール、可用性、安全なデプロイの基礎です。
オートスケーリングを、予測可能でビジネスに重要な急増のための、本物のキャパシティプランニングと余裕と組み合わせます。
クリティカルパスと裾に焦点を当てて、明示的な予算に対するプロファイリングと負荷テストで性能を駆動します。
タイムアウト、サーキットブレーカー、バルクヘッド、穏やかな縮退、冗長性でレジリエンスを築き、それからカオスエンジニアリングで検証します。
RTOとRPOをビジネスの決定として設定し、各システムの重要度に合わせてDRをエンジニアリングし、フェイルオーバーを定期的にテストします。

参考文献とさらなる読み物

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering and The Site Reliability Workbook
Casey Rosenthal and Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile