スケールアウトのための設計

  • [アーティクル]

水平方向に拡張できるようにアプリケーションを設計する

クラウドの主な利点は、柔軟なスケーリングです。必要なだけの容量を使用でき、負荷が増加すればスケールアウトし、余分な容量が必要ない場合にはスケールインします。 需要に応じて新規インスタンスを追加または削除し、水平方向に拡張できるようにアプリケーションを設計します。

Recommendations

インスタンスの粘性の阻止。 粘性またはセッション親和性とは、同じクライアントからの要求は常に同じサーバーにルーティングされることを指します。 粘性により、アプリケーションのスケールアウトの機能が制限されます。たとえば、大量のユーザーからのトラフィックがインスタンス間で分散されません。 粘性の原因となるものには、メモリでのセッション状態の保存、および暗号化用のマシン固有のキーの使用などがあります。 あらゆるインスタンスであらゆる要求を処理できることを確認してください。

ボトルネックの特定 スケールアウトは、すべてのパフォーマンスの問題が修正されるマジックではありません。 たとえば、バックエンドのデータベースがボトルネックである場合、Web サーバーを追加しても改善されません。 問題に対してより多くのインスタンスを投入する前に、まずシステムでボトルネックを特定して解決します。 システムのステートフルな部分は、最もボトルネックの原因となりやすいものです。

スケーラビリティの要件によるワークロードの分解。 アプリケーションは多くの場合、異なるスケーリング要件がある、複数のワークロードで構成されます。 たとえば、公開サイトと、それとは別に管理サイトがあるアプリケーションがあります。 公開サイトでは突然のトラフィック増加が発生する可能性がある一方、管理サイトの負荷はより小さな、より予測がしやすいものです。

非同期タスクを自然にオフロード。 電子メールの送信、ユーザーが即時応答を必要としないアクション、他のシステムとの統合などのタスクは、すべて非同期メッセージング パターンを利用するのが適しています。

多くのリソースを消費するタスクのオフロード。 多くの CPU または I/O リソースを必要とするタスクは、可能であればバックグラウンド ジョブに移動して、ユーザーの要求を処理しているフロントエンドの負荷を最小限に抑える必要があります。

組み込みの自動スケール機能の使用。 多くの Azure コンピューティング サービスでは、自動スケーリングの組み込みサポートがあります。 アプリケーションに予測可能な通常のワークロードがある場合は、スケジュールに基づいてスケールアウトします。 たとえば、営業時間内にスケールアウトします。 ワークロードが予測可能でない場合は、CPU や要求キューの長さなどのパフォーマンス メトリックを使用して、自動スケーリングをトリガーします。 自動スケールのベスト プラクティスについては、「自動スケール」をご覧ください。

クリティカルなワークロードの積極的な自動スケーリングの検討。 クリティカルなワークロードの場合、ニーズには常に事前に対処する必要があります。 負荷の高い場所に新しいインスタンスを追加して過度のトラフィックを処理し、段階的にスケールバックすることをお勧めします。

スケールインの設計。 柔軟なスケールでは、インスタンスが削除されると、アプリケーションにスケールインの期間が生じることに注意してください。 アプリケーションでは、削除中のインスタンスを適切に処理する必要があります。 スケールインを処理する方法はいくつかあります。

  • シャットダウン イベント (使用可能な場合) をリッスンし、正常にシャットダウンします。
  • サービスのクライアントまたはコンシューマーは一時的な障害の処理に対応し、再試行する必要があります。
  • 実行時間の長いタスクの場合、チェックポイントまたはパイプとフィルター パターンを使用して、作業を分割することを検討してください。
  • 作業項目をキューに配置して、インスタンスが処理の最中に削除された場合は別のインスタンスが作業を取得できるようにします。

冗長性のためにスケーリングを検討してください。 スケールアウトすると、アプリケーションの信頼性が向上します。 たとえば、ゾーン冗長サービスを使用するなど、複数 の可用性ゾーン 間でスケールアウトすることを検討してください。 この方法では、アプリケーションのスループットを向上させ、1 つのゾーンで障害が発生した場合の回復性を提供できます。