スケールアウトのための設計
水平方向に拡張できるようにアプリケーションを設計する
クラウドの主な利点は、柔軟なスケーリングです。必要なだけの容量を使用でき、負荷が増加すればスケールアウトし、余分な容量が必要ない場合にはスケールインします。 インスタンスを追加または削除し、需要と供給を一致させて水平方向に拡張できるようにアプリケーションを設計します。
スケーラビリティは、スループットの増加とリソースの増加の比率によって測定されます。 理想を言えば、適切に設計されたシステムでは、両方の数値は比例します。つまり、2 倍のリソースを割り当てると、スループットは 2 倍になります。 スケーラビリティは通常、システム内のボトルネックや同期ポイントの導入によって制限されます。
推奨事項
インスタンスの粘性の阻止。 粘性またはセッション親和性とは、同じクライアントからの要求は常に同じサーバーにルーティングされることを指します。 粘性により、アプリケーションのスケールアウトの機能が制限されます。たとえば、大量のユーザーからのトラフィックがインスタンス間で分散されません。 粘性の原因となるものには、メモリでのセッション状態の保存、および暗号化用のマシン固有のキーの使用などがあります。 あらゆるインスタンスであらゆる要求を処理できることを確認してください。
ボトルネックの特定 スケールアウトは、すべてのパフォーマンスの問題が修正されるマジックではありません。 たとえば、バックエンドのデータベースがボトルネックである場合、Web サーバーを追加しても改善されません。 問題に対してより多くのインスタンスを投入する前に、まずシステムでボトルネックを特定して解決します。 システムのステートフルな部分は、最もボトルネックの原因となりやすいものです。
スケーラビリティの要件によるワークロードの分解。 アプリケーションは多くの場合、異なるスケーリング要件がある、複数のワークロードで構成されます。 たとえば、公開サイトと、それとは別に管理サイトがあるアプリケーションがあります。 公開サイトでは突然のトラフィック増加が発生する可能性がある一方、管理サイトの負荷はより小さな、より予測がしやすいものです。
非同期通信プロトコルを介して通信する、分離された自律コンポーネントの設計。 最も望ましいのは、コンポーネントが独自の独立した状態を持ち、イベントを使用して変更やアクティビティを外部のコンポーネントに伝達できることです。 これにより、オーバーロードされたコンポーネントのみを個別にスケーリングできるようになります。 トラフィックを管理して適切なデグレードを行うためのフロー制御メカニズムの実装。 コンシューマーは、自身の消費率を制御する必要があります。 プロデューサーは、自身の転送速度を制御する必要があります。これには停止も含まれます。 メッセージ キューは、余分なワークロードを吸収し、コンシューマーが都合の良いときに作業を処理できるようにするための優れたオプションです。
不必要な通信、調整、待機の回避。
非同期タスクを自然にオフロード。 電子メールの送信、ユーザーが即時応答を必要としないアクション、他のシステムとの統合などのタスクは、すべて非同期メッセージング パターンを利用するのが適しています。
多くのリソースを消費するタスクのオフロード。 多くの CPU または I/O リソースを必要とするタスクは、可能であればバックグラウンド ジョブに移動して、ユーザーの要求を処理しているフロントエンドの負荷を最小限に抑える必要があります。
ライブ使用状況メトリックに基づくオートスケールと、組み込みのオートスケール機能の使用。 多くの Azure コンピューティング サービスでは、自動スケーリングの組み込みサポートがあります。 アプリケーションに予測可能な通常のワークロードがある場合は、スケジュールに基づいてスケールアウトします。 たとえば、営業時間内にスケールアウトします。 ワークロードが予測可能でない場合は、CPU や要求キューの長さなどのパフォーマンス メトリックを使用して、自動スケーリングをトリガーします。 アプリケーションとその通信を観察してボトルネックを特定し、より正確な意思決定に導きます。 自動スケールのベスト プラクティスについては、「自動スケール」をご覧ください。
クリティカルなワークロードの積極的な自動スケーリングの検討。 クリティカルなワークロードの場合、ニーズには常に事前に対処する必要があります。 負荷の高い場所に新しいインスタンスを追加して過度のトラフィックを処理し、段階的にスケールバックすることをお勧めします。
スケールインの設計。 柔軟なスケールでは、インスタンスが削除されると、アプリケーションにスケールインの期間が生じることに注意してください。 アプリケーションでは、削除中のインスタンスを適切に処理する必要があります。 スケールインを処理する方法はいくつかあります。
- シャットダウン イベント (使用可能な場合) をリッスンし、正常にシャットダウンします。
- サービスのクライアントまたはコンシューマーは一時的な障害の処理に対応し、再試行する必要があります。
- 実行時間の長いタスクの場合、チェックポイントまたはパイプとフィルター パターンを使用して、作業を分割することを検討してください。
- 作業項目をキューに配置して、インスタンスが処理の最中に削除された場合は別のインスタンスが作業を取得できるようにします。
冗長性のためにスケーリングを検討してください。 スケールアウトすると、アプリケーションの信頼性が向上します。 たとえば、ゾーン冗長サービスを使用するなど、複数 の可用性ゾーン 間でスケールアウトすることを検討してください。 この方法では、アプリケーションのスループットを向上させ、1 つのゾーンで障害が発生した場合の回復性を提供できます。
システムのスケーラビリティをモデル化して最適化します。 アムダールの法則などのアプローチを使用して、システムをモデル化できます。 競合やコヒーレンスなどのパラメータに基づいてスケーラビリティを定量化します。 競合とは、共有リソースを待機またはキューに入れることによる遅延を指します。 コヒーレンスとは、データの一貫性を保つ遅延を指します。 たとえば、競合が高い場合は並列化できる順次処理を示し、一方、コヒーレンスが高い場合はプロセス間の依存関係が過剰であることを示唆して、相互作用を最小限に抑えるように促します。 ワークロードの設計時に、システムの最大有効容量を計算することで、無駄の発生につながる需要を上回る供給の提供を回避することができます。