Scalable software architecture as an engineering decision tree

スケーラブルとは何か

2文の定義：スケーラビリティとは、待ち時間、スループット、コストなどの運用制約を満たしながら、リソースの追加または再割り当てによって増加したワークロードを維持するシステムの能力です。エンジニアは、システムがサービス レベル ターゲットとオペレーターのランブックを維持しながら成長または縮小できるように、スケーラビリティを設計します。

測定可能な成果物に関する簡単な注意：パターンを選択する前に、SLA に直接マップするメトリックを選択します。スループット (req/s)、p99 待ち時間、またはトランザクションあたりのコスト (またはテナントあたりのコスト) です。その選択は、水平方向のスケール、垂直方向のスケール、シャーディング、またはゾーン/ドメイン パーティショニングを優先するかどうかを決定します。

スニペット (40〜55 ワード)：「スケーラブルなシステムは、リソースの追加またはパーティショニングによって負荷の増加に伴ってサービス レベル ターゲットを維持します。エンジニアは、待ち時間、分離、コストの目標に応じて、水平方向のスケーリング、シャーディング、またはゾーン/ドメイン アーキテクチャを選択します。正しいメトリック (スループット、p99 待ち時間、テナントあたりのコスト) が決定を駆ります。」

プラットフォームとバックエンド チームのための実用的な枠組み：「スケーラブル」とは、単一のプロパティではなく、エンジニアリングの決定ツリーとして扱います。保護しなければならない SLA メトリックから始めます。バースト時の p99 待ち時間が制約である場合、コロケートされたサービス、バウンドされたファンアウト、高速な水平方向のオートスケーリングを優先します。合計スループットとコストが決定を駆ります。シャーディングまたはパーティショニングされたワークロードを優先します。テナントの分離と爆発半径が主な場合、テナントを別々のコンピューティング、ストレージ、観測可能性ストリームにマップするドメイン/ゾーンの境界を採用します。

設計セッションで使用できる具体的な成果物のマッピング：

- 待ち時間に敏感な API (p99 ターゲット)：クロス AZ/ネットワーク ホップを最小限に抑えます。水平方向のスケールを好み、リソース予約とサーキット ブレーカーを緊密にします。 - 高スループットのインジェスト：キーのパーティショニング (シャーディング) を行います。各シャードはバッチ、圧縮、またはバックプレッシャーを独立して適用できます。 - コスト最適化されたマルチテナント サービス：ソフト マルチテナンシーをテナントごとの調整と請求メトリックと組み合わせます。コスト/待ち時間のニーズが異なる場合、重いテナントを専用ゾーンに移動します。 - 運用の観測可能性と信頼性：各スケーリング パターンがトレーシング、メトリックの基数制限、カオス/スケール テストのテスト ハーネスを維持することを確認します。

この定義とマッピングを使用して、設計レビューのアーキテクチャ トレードオフ テーブルを駆ります。SLA メトリック、優先されるスケーリング パターン、予想される運用タスク (オートスケーリングの調整、シャードの再バランス、テナントの移行)、およびパターンが実行されたときに SLA を保証するランブックのステップをリストします。

スケーラブルは何に使われるか？

スケーラブルなシステムは、負荷、テナント、データボリューム、または機能の複雑さが増加しても、重要な運用結果を維持するように構築されています。実際には、チームはスケーラビリティのパターンを使用して、4つの購入者中心の結果を保護しています。遅延（ユーザーエクスペリエンス）、スループット（容量）、コスト（ユニットエコノミクス）、および分離/コンプライアンス（テナント保証）。以下は、一般的なプロダクションの使用例、保護しなければならない主なメトリックへのマッピング、およびすぐに適用できる戦術的なパターンの1つです。

一般的な使用例と結果

- トラフィックの急増を伴う消費者向けAPI：主なメトリック — 尾部遅延。パターン — 自動スケーリングされたステートレスフロントエンドをリクエストの調整とサーキットブレーカーの後ろに配置します。レート制限付きクライアントSDKとエッジのトークンバケットをペアにします。- 分離と公正な請求が必要なマルチテナントSaaS：主なメトリック — テナントの分離とコストの帰属。パターン — パーティションドテナンシー：密度のために論理テナンシー（スキーマまたは行）を使用します。パフォーマンスSLAまたは規制上の分離が必要な場合は、隔離テナンシー（テナントごとのコンピュートまたはノード）を使用します。テレメトリでは、テナントごとのコストメーターも使用します。- 可変なインジェストを伴う分析パイプライン：主なメトリック — スループットと処理遅延。パターン — 耐久性キュー（例：Kafka、SQS）と遅延に基づいてスケーリングする自動スケーリングされたコンシューマーグループを使用して、インジェストと処理を切り離します。- リアルタイム推論を伴うLLMストリーミング：主なメトリック — 尾部遅延とストリーミングの観測可能性。パターン — バックプレッシャーに応じたパイプライン（非同期ストリーム + コネクションプーリング）を使用し、トークンレベルのトレーシングでインフラのイベントをモデル遅延と関連付けます。

マッピング例 — 実際の選択、即時の結果

- 予測できないトラフィックのパブリックAPI → 自動スケーリングされたステートレスサービス + 調整。結果：尾部遅延を低減しますが、コストの分散を増加させます。コストを上限にし、ダウンストリームシステムを保護するために調整を適用します。- マルチテナント分析 → パーティションドストレージ + テナントごとのリテンション + コストの帰属。結果：テナント間のIO干渉を減らし、テナントごとのコンプライアンスをサポートします。シャード管理作業を増加させます。- LLM応答のストリーミング → バックプレッシャー + リアルタイムの観測可能性。結果：尾部遅延を保護するには、エンドツーエンドのフロー制御とトークンレベルのトレースが必要です。そうでない場合、隠れたキューがSLOを破損しますが、アグリゲートメトリクスは良好です。

チェックリストの結果 — このメトリックを保護し、このパターンを適用します

- 遅延（ユーザー向けAPI）：自動スケーリング + エッジの調整 + サーキットブレーカー。- スループット（インジェスト/分析）：耐久性キューと遅延に基づいてスケーリングするコンシューマーグループ。- コスト（ユニットエコノミクス）：テナントごとのメーターと階層化された分離（共有 → 専用）。- コンプライアンス/データ保管：リテンションポリシーごとにストレージをパーティショニングし、監査ログを使用してリテンションセーフな削除を自動化します。

実行可能な次のステップ：製品の優先度の高い使用例の1つを選択し、上記の単一の主なメトリックを特定し、ステージング環境で合成スパイクテストとSLOドリブンのランブック（しきい値、警告、エスカレーションパス）を使用して、対応するパターンを実装します。

スケーラブルなシステムはどのように動作するのか?

スケーラビリティは、容量を追加する場所、データと作業を分割する方法、そしてどのプラットフォームコンポーネントがその容量を調整するかを変更する一連のエンジニアリングパターンとして実装されます。以下は、各選択肢を具体的な運用結果（コスト、待ち時間、観測性、テストの信頼性、テナントの分離）にマッピングするために必要なメカニズム、トレードオフ、プラットフォームコンポーネントです。

メカニズムとトレードオフ: 水平スケーリング vs 垂直スケーリング

水平スケーリング（インスタンスの追加）は、並行性と障害の分離を向上させます。一方、垂直スケーリング（インスタンスのサイズを大きくする）は、シングルスレッドのボトルネックに対する待ち時間を短縮します。

- プロビジョニング時間: 水平オートスケーリングでは、インスタンスの起動とウォームアップ（イメージやJITによっては数秒から数分）が必要になります。一方、垂直方向の変更では、インスタンスの置き換えまたはスケジュールされたサイズ変更ウィンドウが必要となり、エラスティシティの観点では遅くなります。-障害の影響範囲: 小さなノードを多数配置することで、影響範囲を減らすことができます。一方、大きなノードを少数配置することで、リスクが集中し、ローリングアップグレードが複雑になります。- オートスケーリングの粒度とコスト: 水平スケーリングでは、より細かいステップ（ポッド）でスケーリングでき、スポット容量を利用できます。一方、垂直スケーリングでは、余分なリソースが浪費され、課金ステップが粗くなります。

パーティショニング戦略: シャーディング vs マルチリージョン/ゾーンの分割

パーティショニングにより、負荷と状態が分離されます。関心のある運用結果によって選択します。

- テナント/ユーザー/キーのシャーディング: ノイズの多いテナントを分離し、シャードごとのスキーマ移行を可能にします。トレードオフとして、クロスシャードトランザクションの複雑さや、運用上のシャーディング作業が必要になります。- マルチリージョンまたはゾーンの分割: ユーザーへの待ち時間を短縮し、リージョンごとの障害耐性を提供します。アクティブアクティブレプリケーションによりコストが増加し、コンフリクト解決とリージョンフェイルオーバーのランブックが必要になります。

必要なプラットフォームコンポーネント

- オーケストレーション: 水平方向のエラスティシティのためにKubernetesまたは管理されたオートスケーリンググループを使用します。ノードプールを使用して、混合インスタンスサイズを実現します。ポッドの障害予防予算を設定して、安全なアップグレードを実現します。- サービスディスカバリとレート制限: エンドポイントをルーティング可能にし、バースト期間中にはダウンストリームシステムを保護します。- 分散キャッシュとメッセージキュー: キャッシュを使用してDBの負荷を軽減します。キューを使用してバーストを緩和し、ランブックでリトライ/バックオフロジックを実現します。- 観測性: トレース、p99に焦点を当てたメトリクス、ログ、ストリーミングテレメトリを使用します。トレースにテナントタグをインストルメントして、ランブックでインシデントをテナント分離アクションにマップできるようにします。

作業済みマイクロ計算チェックリスト: p99待ち時間ターゲットのためのノードモデル

- 1) 定常状態のリクエストコストを測定します。p50とp99の下で、代表的な負荷のCPUms、メモリ、I/Oをリクエストごとにキャプチャします。- 2) トラフィックプロファイルを定義します。予想RPS、バーストファクター（例：ピークの2倍）、および許容されるキュー待ち時間。- 3) インスタンスサイズを選択し、システムオーバーヘッド後のノードごとの使用可能なCPUms/秒を推定します。- 4) 必要なノード数を計算します。ceil((RPS * CPUms_per_request * burst_factor) / CPUms_per_node)を使用します。p99 CPUmsを使用して、尾部の作業をキャプチャし、オートスケーラーの遅延とノイズの多い隣接ノードに対する安全マージン（25〜50%）を追加します。- 5) p95/p99に焦点を当てたロードテストで検証します。グレードの段階的な増加、キャッシュミスの演習、およびスケールアップとスケールドアウン時のオートスケーラーの動作を確認します。

各選択肢をランブックアクションにマップします。水平スケールイベント → オートスケーラーが発火したことを確認し、ドレイン/コーデン、ローリング置換の検証を実行します。シャードのリバランシング → チェックポイント、キーの移行、整合性の検証を実行します。リージョンフェイルオーバー → DNS/エッジルーティングのシフト、クォーラムの検証を実行します。これらの結果（コスト、待ち時間、観測性、テストの信頼性、テナントの分離）は、プロダクションシステムのスケーリングパターンの選択時に主な軸となるべきです。

いつ選択するべきか？

生産シグナルとビジネス制約が測定可能な運用結果（コスト、待ち時間、分離、観測可能性、テストの信頼性）にマップされる場合、スケーラブルなアーキテクチャを選択します。如果 "ロードの増加はどのくらい速いか？"、"p99 SLA はどのくらい厳しいか？"、"テナントの分離またはコンプライアンスのニーズは何があるか？" という質問に答えることができる場合、運用上の手間を最小限に抑えるためのパターンを選択します。

決定基準と生産シグナル

- 成長プロファイル：安定した成長は容量計画と垂直方向の右サイズに適している；予測できないスパイクはオートスケーラーと調整を使用した水平方向のスケーリングに適している。 - SLA の厳密さ：厳しい p99 待ち時間はパーティショニング、関連データのコロケーション、事前に温めたインスタンスを推進する；緩い待ち時間はコストを節約するためにバッチング、キューイング、またはイベントの整合性を許可する。 - テナントモデル：シングルテナントシステムは顧客ごとにスタックを最適化できる；マルチテナントプラットフォームはコンプライアンスと爆発半径のニーズによって論理的分離と物理的分離を比較検討する必要がある。 - コストの感度：ユニットコストが重要な場合、予測可能な負荷の場合、効率的なパッキングと垂直方向のスケーリングを優先する；停止コストがインフラコストよりも高い場合、冗長性と水平方向のスケールアウトを優先する。 - トランザクションパターン：ヘビークロスエンティティトランザクションは関連パーティションのコロケーションまたは分散トランザクションを減らすためにワークフローを再作成することを示唆する。

具体的な決定ツリー（実用的結果へのマッピング）

- 厳しい p99 + 予測できないスパイク → 水平方向のスケーリング + オートスケーラー + サーキットブレーカー。結果：待ち時間 SLO を保持するが、オーケストレーションとウォームアップ管理のコストが増加する。 - コンプライアンス/監査のニーズがあるマルチテナント → 論理的または物理的なテナント分離 + テナントごとのリテンションと監査トレイル。結果：監査リスクと爆発半径を減らす；運用コストとライセンスコストが増加する。 - ヘビークロスエンティティトランザクション → パーティションのコロケーションまたはアフィニティによるシャーディング。結果：分散トランザクションの待ち時間と障害モードを減らす；リバランシングを複雑にする。 - 予測可能でゆっくり成長する負荷 + 厳しいコストターゲット → 垂直方向のスケーリングとインスタンスの右サイズ。結果：コストが低いが、単一ノードのリスクが高い；強力な容量テストが必要。

パターンを採用する前の運用準備チェックリスト

- インフラストラクチャとしてのコードとテストされたロールバックを使用した自動 CI/CD。 - カナリアとプログレッシブなデプロイを使用して、生産トラフィックでのスケーリング動作を検証する。 - 定義された SLO/SLA（p50/p95/p99 を含む）とエラーバジェットポリシーをリリースゲートに結び付ける。 - スケーリングインシデントのランブック：容量を追加する方法、負荷を削減する方法、整合性を回復する方法、およびプレイブック所有者。 - 実在的なスパイク形状、テナントの混合、障害モードをシミュレートする容量テスト；観測可能性の KPI（リクエストキューの長さ、GC 一時停止時間、尾部待ち時間）を含める。

意思決定はトレードオフの演習です：各オプションを気にする運用結果にマップし、フルロールアウト前に容量テストとカナリアウィンドウで検証します。

それらは類似の用語とどう違うのか?

スケーラビリティは、しばしばエラスティシティ、可用性、パフォーマンスと混同される。実際の違い:

- スケーラビリティ: システムが時間の経過とともにワークロードの増加をどれだけ耐えられるか（シャーディング、水平方向のスケーリング）を示す。 - エラスティシティ: 容量が短期的な負荷に追随するためにどれだけすばやく変更できるか（オートスケーラー、高速インスタンスの起動）を示す。 - 可用性: サービスが到達可能である確率（冗長性、フェイルオーバー）を示す。 - パフォーマンス: 与えられた負荷での待ち時間またはスループットを示す。

これらを別々のエンジニアリングの懸念事項として扱い、異なるコントロール、ランブックタスク、SLAの結果にマッピングする。

スケーラビリティ vs エラスティシティ

スケーラビリティは、主要な再設計を行わずに容量を追加できるようにする設計上の特性である。エラスティシティは、スケーラブルな設計の上に実装されたランタイムの動作である。システムがスケーラブルだがエラスティックでない場合、長期的な成長に対応できるが、突然のスパイクに苦労する；エラスティックだがアーキテクチャ的にスケーラブルでない場合、オートスケーリングは、状態のある性質や負荷パターンの増加に伴って高価で脆弱になる。

スケーラビリティ vs 可用性

可用性は、冗長性、ヘルスチェック、フェイルオーバーを通じてアップタイムをターゲットにする。スケーラビリティは容量の成長をターゲットにする。高くスケーラブルなシステムでも、冗長性が欠如している場合、または単一の障害点の調整コンポーネントを持っている場合、利用できない。各懸念事項ごとに別々のランブックとテストを行う。

スケーラビリティ vs パフォーマンス

パフォーマンスエンジニアリングは、現在の負荷での待ち時間（プロファイル、キャッシュ、高速I/O）を最適化する。スケーラビリティは、負荷が増加するにつれてこれらの待ち時間がどのように変化するかを測定する。コードとキャッシュを使用してパフォーマンスを改善する；パーティショニング、並列性、解結を使用してスケーラビリティを改善する。

実践的なマッピング: クイックチェックリスト

- スムーズなコストの成長と長期的な容量が必要: スケーラビリティを優先する－水平方向のスケール、シャーディング、ステートレスワーカー。 - 最小限のオペレーションで突然のスパイクを処理する必要がある: エラスティシティを追加する－高速オートスケーラー、短いブート時間、エフェメラルプール。 - アップタイムを優先するSLA: 可用性に投資する－レプリケーション、ヘルスチェック、マルチリージョンのフェイルオーバー、インシデントランブック。 - 待ち時間を優先するSLA: パフォーマンスに焦点を当てる－プロファイリング、キャッシュ、リソースの分離、SLOドリブンテスト。

よくある質問

ステートフルAPIの水平スケーリングと垂直スケーリングのどちらを選択するかを決定する方法は?

単一プロセスのステートフルワークロードにメモリ/CPUが必要で、シンプルな一貫性が必要な場合は、垂直スケーリング（より大きなインスタンス）を選択します。ただし、マージナルコストが高く、影響範囲が広がる可能性があります。状態をパーティション化できる（シャーディングまたはスティッキーセッション）またはステートレスフロントエンドを使用できる場合は、水平スケーリングを選択します。これにより、可用性と障害分離が向上しますが、ルーティング、検出、クロスインスタンスの調整が必要になります。SLAに選択を結び付けることができます。99パーセンタイルの待ち時間がGCポーズによって支配されている場合は、垂直スケーリングが短期的な解決策となります。可用性と運用的回復性のためには、水平スケーリングと明確なパーティション化ルールを優先します。

データをシャーディングすることで、どのような運用結果が変化するか?

シャーディングにより、ノードあたりの負荷が軽減され、待ち時間の尾部が短縮されますが、運用作業が追加されます。シャードのリバランス、ルーティングロジック、クロスシャードトランザクション、大規模なテストマトリックスなどです。スプリット/マージ移行のランブックエントリ、シャードの偏りを監視し、クロスシャードの一貫性を検証するシンセティックテストを期待します。テナントがシャードにマップされる場合、シャーディングによりテナントの分離が向上しますが、オーケストレーションにシャードごとのクォータとサーキットブレーカーを含める必要があります。

ゾーニング（マルチゾーンまたはマルチリージョン）は、観測可能性とコストにどのような影響を与えるか?

ゾーニングにより、障害分離が向上し、ユーザーの待ち時間が短縮されますが、観測可能性の表面が増加します。ゾーンタグ付きの集約トレースとメトリクス、ゾーンごとのシンセティックテスト、自動フェイルオーバープレイブックが必要になります。リージョナルリソースの複製とクロスゾーントラフィックによりコストが増加します。SLAの利点と実行コストおよびデータ居住要件のバランスをとる必要があります。計画的なゾーンフェイルオーバーの際にノイジーアラームを避けるために、ゾーンが認識できるアラートのしきい値を使用します。

サービス境界をスケーラビリティのために再構成する必要があるのはいつか?

サービスがスケーリングプロファイルを同等のサービスと乖離させた場合（たとえば、リードヘビーエンドポイントがコンピューティングを膨らませたり、ノイズの隣人を引き起こしたりする場合）に、境界を再構成します。結合を減らし、独立したデプロイを可能にし、ストレージ/キャッシュをカスタマイズできる場合は、機能を別のサービスに移動します。各再構成には、信頼性を維持するために、更新されたCIテスト、契約/バージョニングポリシー、およびSLO移行計画が必要です。

アーキテクチャが真正にスケーラブルであることを検証するための迅速なチェックは?

4つのチェックを実行します。（1）コードを変更せずに容量を追加できますか？（2）障害モードは小さな影響範囲に分離されていますか？（3）テレメトリとシンセティックテストは、負荷下で線形または部分線形の劣化を示していますか？（4）運用タスク（デプロイ、ロールバック、復旧）は自動化されており、ランブックに文書化されていますか？どれかが「いいえ」である場合、設計は変更が必要です。通常、オーケストレーション、観測可能性、またはサービス境界で変更が必要です。プロダクションスケーラブルと宣言する前に。

参考文献

- Wikipedia: スケーラビリティ - Automotive IQ: ドメインアーキテクチャ vs ゾーンアーキテクチャ (ニュースフィード) - EE Times: チップレットアーキテクチャ (ニュースフィード) - Designboom: オクターブ (ニュースフィード) - HackerNoon: AIとエンジニア (ニュースフィード) - The Desert Sun: JPLoft (ニュースフィード) - TNGlobal: FPTスケーリング (ニュースフィード)