Azure Load Balancer の Well-Architected Framework の観点
負荷分散プロセスは、2 つ以上のバックエンド サーバーのグループにネットワーク トラフィックを分散します。 Azure Load Balancer は、ユーザー データグラム プロトコル (UDP) と伝送制御プロトコル (TCP) のレイヤー 4 負荷分散を行う Azure ネイティブ サービスです。 Load Balancer は、リージョンおよびグローバルデプロイの待機時間が短く、高可用性を提供するのに役立ちます。
この記事では、アーキテクトとして、Azure で 負荷分散オプションを確認し、ワークロードに合わせて Load Balancer を選択していることを前提としています。 この記事のガイダンスでは、Well-Architected Framework の柱の原則に対応付けてアーキテクチャの推奨事項を示します。
重要
このガイドの使用方法
各セクションには、設計チェックリスト があり、テクノロジ スコープにローカライズされた設計戦略と共に、アーキテクチャ上の懸念事項が示されています。
また、これらの戦略の実現に役立つテクノロジ機能に関する推奨事項も含まれています。 推奨事項は、Load Balancer とその依存関係で使用できるすべての構成の完全な一覧を表すわけではありません。 代わりに、設計の観点に対応付けて、主要な推奨事項を示しています。 これらの推奨事項は、概念実証の構築や、既存の環境を最適化する場合に使用できます。
主要な推奨事項を示す基本アーキテクチャ:
Azure Virtual Machines のベースライン アーキテクチャ .
技術的範囲
このレビューでは、次の Azure リソースの相互に関連する決定に焦点を当てます。
- ロードバランサー (負荷分散装置)
このガイダンスでは、Standard Load Balancer SKU に重点を置いています。 Basic Load Balancer とゲートウェイ ロード バランサーの SKU は、この記事の範囲外です。
メモ
HTTP アプリケーションの場合は、Load Balancer ではなく Azure Application Gateway または Azure Front Door を検討してください。 これらの代替手段は、負荷分散を管理し、Web アプリケーション ファイアウォール (WAF) やトランスポート層セキュリティ (TLS) 終了などの機能も提供します。
詳細については次を参照してください:
信頼性
信頼性の柱の目的は、十分な回復性と障害から迅速に復帰するしくみを構築して、継続的な機能を提供することです。
信頼性設計原則は、個々のコンポーネント、システム フロー、およびシステム全体に適用される高レベルの設計戦略を提供します。
設計チェック リスト
信頼性に関する設計レビュー チェックリストに基づいて設計戦略を開始します。 仮想マシン (VM) の階層と機能を念頭に置いて、ビジネス要件との関連性を判断します。 必要に応じ、より多くのアプローチを含めて戦略を拡張します。
Microsoft がサポートする保証の影響を理解します。 アーキテクチャ内の他のコンポーネントに加えて、ワークロードの信頼性ターゲットにサービス レベル アグリーメント (SLA) を考慮します。 以下の重要な点に注意してください。
負荷分散されたエンドポイントが 1 分間、すべての正常なバックエンド サーバーに接続できない場合、その分は使用不可と見なされます。 ただし、同じ時間内に少なくとも 1 つの要求が成功した場合、他の要求が失敗した場合でも、その分はダウンタイムとは見なされません。
ダウンタイムには、ソース ネットワーク アドレス変換 (SNAT) ポートの枯渇によって発生する分は含まれません。 予想される接続数を処理し、それに応じてポートを開くワークロードを構成してください。
ワークロード アーキテクチャでゾーン冗長性をサポートします。 Standard Load Balancer SKU をお勧めします。 可用性ゾーンのサポート、複数のリージョン間のトラフィック分散、バックエンド プール内のより多くのインスタンスを処理する機能などの信頼性機能があります。 これらの機能は、ゾーン、リージョン、および個々の VM インスタンス レベルでの障害に耐えるのに役立ちます。 バックエンド プールの最大サイズなどの制限事項に注意してください。
メモ
Load Balancer では、負荷分散された VM の数は管理しますが、Load Balancer インスタンスの数は管理しません。 Load Balancer インスタンスをゾーン冗長に構成することも、ワークロードが 1 つのゾーンに VM を併置する必要がある場合はゾーンにピン留めすることもできます。 フロントエンド IP アドレスのゾーン構成またはマルチゾーン構成によって、負荷分散の冗長性が決まります。
ワークロード アーキテクチャでリージョン冗長をサポートします。 Load Balancer をグローバル ロード バランサーとして構成できます。 このセットアップでは、Load Balancer には、複数のリージョンにブロードキャストする静的エニーキャスト パブリック IP アドレスがあります。 クライアントがこの IP アドレスを要求すると、その要求は最も近いサーバー インスタンスに送信されます。 Load Balancer は、リージョンのロード バランサーに接続して、トラフィックを効率的に分散します。
信頼性の高いスケーリングをサポートするために、ネットワーク スタックの変更を評価します。 自動スケール ルールを使用してバックエンド プールをスケールアウトすることを検討してください。 送信トラフィックに対する潜在的な SNAT ポート不足に注意してください。 この問題に対処するには、構成を容易にするために Azure NAT ゲートウェイを使用しますが、可用性ゾーンの冗長性がないことを理解してください。 または、ゾーンの冗長性を追加するために Load Balancer を使用します。 詳細については、「送信接続」を参照してください。
潜在的な障害を軽減します。 障害モードの分析を実行し、軽減策を特定します。 次の表に、エラーの種類とその軽減方法を示します。
障害 対応策 トラフィックは異常なアプリケーション インスタンスにルーティングされます。 ワークロード インスタンスの正常性を監視します。 ワークロードの依存関係のチェックを含む HTTP 正常性プローブを実装します。 トラフィックは、停止しているリージョンにルーティングされます。 別のリージョンに追加のインスタンスをデプロイします。 新しいリージョンにトラフィックをリダイレクトするグローバル ロード バランサーを追加します。 ワークロードのユーザー ベースは、新しいリージョンのユーザーをサポートするように拡張され、待機時間が長くなっています。 アプリケーションで多数のタイムアウトとエラーが発生するようになりました。 新しいリージョンに追加のインスタンスをデプロイし、サービス構成に追加します。 グローバル ロード バランサーとして、Azure Load Balancer はトラフィックをユーザーの近くにルーティングします。 トラフィックを正常なインスタンスにルーティングします。 正常性プローブには HTTP または TCP を使用できます。 より豊富な状態応答を提供するには、HTTP 以外のアプリであっても、正常性チェック用の HTTP エンドポイントを作成することを検討してください。 この方法は、依存関係とデータベースを確認する場合に特に役立ちます。 HTTP プローブがない場合、ロード バランサーは TCP 接続に依存します。これは VM の正常性を正確に反映していない可能性があります。
Load Balancer で正常性プローブを構成できます。 詳細については、「正常性プローブに関する設計ガイダンス」を参照してください。
推奨事項
| 推奨事項 | メリット |
|---|---|
| Standard Load Balancer SKU を選択します。 詳細については、SKU の比較 参照してください。 |
この SKU では、可用性ゾーンやマルチリージョン負荷分散などの信頼性機能がサポートされています。 |
| フロントエンド IP アドレスをバックエンド サーバーの IP アドレスにマップして負荷分散を有効にするように、規則 を構成します。 バックエンド アドレス プールには、冗長性のために負荷分散するバックエンド エンドポイントが少なくとも 2 つ必要です。 |
規則は、負荷分散アルゴリズムの中核です。 この構成がない場合、配布モードは無効になります。 |
| のヘルスプローブをに設定します。 - プローブ間隔としきい値を設定します。 障害を検出する速度とエンドポイントへの要求数とのトレードオフを考慮してください。 - すべてのインスタンスの状態が異常な場合に、インスタンスにトラフィックを送信するかどうかを評価します。 この構成を使用して、グレースフルな低下エクスペリエンスを実装できます。 詳細については、「AllProbedUp」を参照してください。 |
正常なバックエンド プール インスタンスのみが新しい接続を受信します。 この構成は、異常なインスタンスからトラフィックをルーティングするため、高可用性と信頼性を維持するのに役立ちます。 |
| プライベート IP アドレスとパブリック IP アドレスをゾーン冗長 構成します。 IP アドレスによって、Load Balancer のゾーン冗長性が決まります。 | ゾーン冗長性は、ワークロードがゾーン障害に耐えるのに役立ちます。 1 つのゾーンに障害が発生した場合、サービスは残りのゾーンの いずれかにフェールオーバーできます。 |
セキュリティ
セキュリティの柱の目的は、ワークロードに対して機密性、整合性、可用性を保証することです。
セキュリティ設計の原則、Load Balancer の技術的な設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
設計チェック リスト
セキュリティに関する設計レビュー チェックリストに基づいて設計戦略を開始し、脆弱性と制御を特定してセキュリティ体制を改善します。 必要に応じ、より多くのアプローチを含めて戦略を拡張します。
セキュリティ ベースラインを確認します。 Azure Load Balancer によって負荷分散されるアプリケーションのセキュリティ体制を強化するには、Load Balancer のセキュリティ ベースラインを確認します。
バックエンド サーバーを保護します。 インターネットに直接公開されていない仮想ネットワークにリソースをデプロイします。 仮想ネットワークの前にロード バランサーを配置します。 理想的には、ロード バランサーにはファイアウォール機能が必要です。 HTTP アプリケーションの場合は、Application Gateway または Azure Front Door を検討してください。 HTTP 以外のアプリケーションの場合は、プライベート IP アドレス (内部ロード バランサー) を持つ Load Balancer を検討し、セキュリティを強化するために Azure Firewall 経由でトラフィックをルーティングすることを検討してください。 詳細については、「内部ロード バランサー」を参照してください。
Load Balancer をリバース プロキシとして使用することもできます。 その場合、ロード バランサーには SNAT を持つパブリック IP アドレスがあり、その IP アドレスをマスクしながらリソースが公開されます。
メモ
バックエンド サーバーへのトラフィックをフィルター処理するには、フロントエンドとバックエンドを含むサブネット上のネットワーク セキュリティ グループ (NSG) を使用します。 NSG を Load Balancer サービスに直接適用しないでください。 NSG は、規則を適用する場合、ロード バランサーではなく、送信元コンピューターと宛先コンピューターの送信元ポート、宛先ポート、アドレス範囲を考慮します。
プライベート接続用の設計。 Load Balancer は Azure Private Link で動作します。 アプリケーション リソースを仮想ネットワークに分散する場合は、異なる仮想ネットワーク内のリソースを接続できます。 仮想ネットワーク ピアリングを使用するか、内部ロード バランサーの前に Private Link を配置します。 Private Link オプションは、パブリック IP アドレスを必要とせずに、より安全なアクセスを提供します。 また、ピアリングされていないネットワークからのアクセスも制限されます。
ロールベースのアクセス制御 を使用してプライベート リンクを承認し、必要な ID のみにアクセスを制限できます。
ネットワーク エッジの脅威からアプリケーションを保護します。 Load Balancer をエントリ ポイントとして使用する設計の場合は、エンドポイント レベルでトラフィック検査を実装します。 この設計には WAF のような組み込みのセキュリティ機能がないため、HTTP アプリケーションをセキュリティで保護するために追加の対策を追加する必要があります。 詳細については、「パブリックロードバランサー」を参照してください。 また、分散サービス拒否 (DDoS) 攻撃からロード バランサー エンドポイントを保護します。
ネットワーク トラフィックを暗号化します。 Load Balancer はレイヤー 4 で動作し、TCP トラフィックと UDP トラフィックの負荷分散を完全にサポートします。 Load Balancer では、Secure Sockets Layer (SSL) と TLS 終端はサポートされていません。 アプリケーション層での HTTPS 負荷分散には、Application Gateway を使用します。
推奨事項
| 推奨事項 | メリット |
|---|---|
| 仮想ネットワーク内のプライベート IP アドレスに フロントエンド IP アドレスを構成します。 | この方法は、フロントエンド IP アドレスと仮想ネットワークがインターネットへの直接の露出から確実に分離されるようにするのに役立ちます。 内部ロード バランサーはインターネットからの着信トラフィックを受け入れることができないため、潜在的な攻撃ベクトルが減少します。 |
| Azure DDoS Protection を使用してパブリック ロード バランサーを保護します。 | DDoS Protection プランでは、エンドポイントで脅威や悪用の兆候を監視する検出機能など、高度な保護が提供されます。 |
コストの最適化
コスト最適化では、ビジネス要件を満たしながら組織の予算を満たすために、支出パターンを検出し、重要な領域への投資を優先し、その他の領域を最適化することに重点を置いています。
コスト最適化の設計原則、Load Balancer とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。
設計チェック リスト
投資のコスト最適化に関する設計レビュー チェックリストに基づいて設計戦略を開始します。 ワークロードに割り当てられた予算に合わせて設計を微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過とともに最適化する機会を見つける必要があります。
負荷分散コストをコスト モデルに組み込みます。 Load Balancer が処理するデータの量や、受信負荷分散規則と送信負荷分散規則の数など、主な要因を考慮してください。 正確なコスト見積もりを行うには、トラフィック ログを使用して、受信トラフィックと送信トラフィックのニーズを測定します。
支出の制御を設定します。 Load Balancer のコストをログに記録して分析します。 コストを効果的に管理するには、Microsoft Cost Management を使用して予算を作成し、アラートを構成します。 コストは、ログに記録されたデータの量とストレージ期間に基づいて蓄積され、帯域幅とストレージの費用に影響を与えます。
未使用のリソースを削除します。 未使用のロード バランサー インスタンスを特定して削除します。 ログを分析して使用状況を評価します。 バックエンド VM に関連付けられていないロード バランサー インスタンスを削除します。 トラフィック ログを調べて、使用されていないリソースを見つけます。
フロー コストを最適化します。 効率的なプロトコルとデータ圧縮を使用して、トラフィック フローの負荷を軽減し、コストを最小限に抑えます。
コストを最適化するために、ルールの数を減らすことができます。 エンドポイントごとに個々の IP アドレスとポートを使用する規則を使用する代わりに、バックエンド プールに接続するフロントエンド内のポートの範囲の規則を定義します。
バックエンド フローで最適化を実装します。 たとえば、ロード バランサーがインターセプトする複数のデータベース クエリでは、クエリあたりのコストが増加する可能性があります。 この追加コストを回避するには、ストアド プロシージャを実装してクエリのシーケンスを統合することを検討してください。
操作のコストを評価します。 メンテナンス、スケーリング、コンプライアンスなどのリソースコストと運用コストを考慮してください。 ロード バランサー規則は、コストに大きな影響を与える可能性があります。 財務コストと管理コストを最適化するためのルールの数を減らします。
推奨事項
| 推奨事項 | メリット |
|---|---|
| コストの見積もりには、Azure 料金計算ツールをご利用ください。 | 予想されるトラフィック使用量をコスト見積もりに変換できるため、計画と予算が簡単になります。 |
| ルールの数を評価し、可能であればそれらを減らします。 個々の IP アドレスに対して複数の規則を定義するのではなく、1 つのルールを使用してポートの範囲を集計できるかどうかを評価します。 たとえば、受信 NAT 規則 を使用して、個々の VM ではなくバックエンド プールに IP アドレスとポートをマップできます。 |
統合ルールはコストを最適化し、運用を簡素化します。 スケールアップまたはスケールダウンすると、ルールを変更することなく、バックエンド プールに IP アドレスを追加または削除できます。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスでは主に、開発プラクティス、監視、リリース管理の手順に重点を置いています。
オペレーショナル エクセレンス設計原則は、ワークロードの運用要件に関する目標を達成するための高度な設計戦略を提供します。
設計チェック リスト
Load Balancer に関連する監視、テスト、デプロイのプロセスを定義するためのオペレーショナル エクセレンス の 設計レビュー チェックリストに基づいて、設計戦略を開始します。
コードとしてインフラストラクチャを使用します。 Load Balancer を、仮想ネットワーク、ネットワーク ピアリング、プライベート エンドポイント、NSG などの他のネットワーク コンポーネントと共にデプロイして構成します。 Microsoft.Network loadBalancers リソースの種類について把握してください。
ハブアンドスポーク アーキテクチャには、階層型デプロイを使用します。 スポーク ネットワークにデプロイされているワークロードよりも変更頻度が低いため、最初にハブをデプロイします。 ワークロードを使用してロード バランサーをデプロイします。 複数のワークロードで 1 つのロード バランサーを再利用する場合は、ハブに配置することを検討してください。
包括的なネットワーク監視システムを実装します。 診断機能を実装し、リアルタイムのインサイトとアラートのために多次元メトリクス、正常性イベントスキーマに基づくリソースログ、そして包括的な負荷分散監視のためのAzure Monitor Insightsダッシュボードを活用します。
推奨事項
| 推奨事項 | メリット |
|---|---|
| 多次元メトリック 使用します。 過剰なアラートを最小限に抑えるには、集計の種類を Averageに設定し、95% のしきい値を持つ 5 分間のデータ ウィンドウを使用します。 詳細については、「多次元メトリックのアラートを構成する」を参照してください。 受信と送信の可用性の例を確認します。 |
包括的なリアルタイムの分析情報とアラート構成により、問題の検出が強化され、迅速な対応が可能になります。 |
| リソース ログをキャプチャします。 Load Balancer のエントリは、の正常性イベントスキーマに依存しています。 | ログには、問題をすばやく特定して解決できるように、イベントの詳細なレコードが用意されています。 |
| Load Balancer には、組み込みのAzure Monitor Insights ダッシュボードを使用します。 | 視覚化により、十分な情報に基づく設計の選択が容易になり、問題をすばやく特定、診断、修正できます。 |
メンテナンス操作中に、管理状態 を Down に設定して、既存の接続を中断せずにバックエンド インスタンスをローテーションから外します。 この構成は、既存の接続が正常に終了している間に、新しい接続がバックエンド インスタンスに転送されないようにするのに役立ちます。 |
この 管理者の状態 構成は、定期的なメンテナンスや修正プログラムの適用のために VM を負荷分散ローテーションから外すときのオーバーヘッドと複雑さを軽減するのに役立ちます。 バックエンド インスタンスをローテーションから外す別のオプションとして、NSG を適用して、Load Balancer 正常性プローブまたはクライアントの IP アドレスとポートからのトラフィックをブロックできます。 このオプションを選択すると、複雑さが増します。 |
パフォーマンス効率
パフォーマンス効率とは、容量の管理により、負荷が増加してもユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計原則は、予想される使用量に対してこれらのキャパシティ目標を達成するための高度の設計戦略を提供します。
設計チェック リスト
Load Balancer の主要業績評価指標に基づいてベースラインを定義するためのパフォーマンス効率 の 設計レビュー チェックリストに基づいて、設計戦略を開始します。
ネットワーク パフォーマンスのターゲットを決定します。 ロード バランサーは、サポートできるトラフィックに制限はありません。 ただし、パフォーマンス目標を定義し、容量を計画するときは、ネットワーク パフォーマンスをテストする必要があります。
ストレス テストを使用して、ワークロードの帯域幅要件を理解します。 これらのテストにロード バランサーを含めます。 複数の VM を持つ 1 つの仮想マシン スケール セットでは不十分な場合は、同じロード バランサーを使用して別のスケール セットを追加できます。 VM が要求を迅速に受信できない場合は、ロード バランサーの追加など、ネットワーク コンポーネントの調整が必要になる場合があります。 ただし、ロード バランサーを変更する代わりに、設計を変更し、負荷をより適切に処理するようにワークロードを最適化することを検討してください。
スケーリング戦略を設計するときの制限について説明します。 パフォーマンス要件を満たし、ワークロードをスケーリングするには、バックエンド プールに VM を追加または削除します。 Standard Load Balancer の 1 つのバックエンド プールで、最大 5,000 個の VM を処理できます。
Load Balancer では、スループットの制限は適用されません。 ただし、VM と仮想ネットワークのスループット制限は引き続き適用されます。 詳細については、VM ネットワーク帯域幅 を参照してください。
要求を迅速に処理します。 Standard Load Balancer には、ユーザーとの地理的近接性に基づいてバックエンド エンドポイントにトラフィックをルーティングする層があります。
Load Balancer では、セッションの永続化に基づく負荷分散もサポートされます。 この機能を有効にすると、同じクライアントからの要求は、以前のセッションを処理したのと同じバックエンド サーバーに一貫して送信されます。
パフォーマンスを分析するためにデータを収集します。 Load Balancer 多次元メトリック サービスのパフォーマンスを分析できます。 パフォーマンスの変更を検出するようにアラートを構成します。 Azure Monitor Insights ダッシュボード などのツールを使用して、Load Balancer の状態を視覚化します。 リソースの健康状態を監視し、パフォーマンス問題や停止に関する情報を常に把握するようにリソース正常性機能を設定してください。
ネットワーク トラフィックを最適化します。 同じデータを別々の手順で複数回処理しないでください。 代わりに、必要なすべての計算をバッチで実行し、データを保持します。 この方法により、待機時間が短縮され、ネットワーク トラフィックが最小限に抑えられます。これにより、全体的なパフォーマンスが向上します。
推奨事項
| 推奨事項 | メリット |
|---|---|
| グローバル ユーザーがいる場合は、Standard Load Balancer で グローバル レベルを選択します。 | このレベルの geo 近接分散モードは、最も近いリージョンのエンドポイントからのユーザー要求を処理し、パフォーマンスを向上させます。 |
| 同じユーザーからの要求を同じバックエンド サーバーに送信する場合は、セッションの永続化を有効にする必要があるかどうかを評価します。 信頼性の観点からは、このアプローチはお勧めしません。 このオプションを使用する場合、アプリケーションはユーザー セッションを中断することなく正常に復旧する必要があります。 負荷分散のトレードオフもあります。複数のバックエンドにトラフィックを均等に分散する柔軟性が制限されるためです。 |
セッションの永続化により、パフォーマンスを最適化し、ユーザー セッションの継続性を維持できます。特に、アプリケーションが状態情報をローカルで維持することに依存している場合です。 しかし、トレードオフがあります。 |
| スケールアウト中に、アプリケーションが完全に初期化され、要求を処理する準備ができるまで、プローブダウンシグナル 送信します。 スケール イン中に、スケール バックされているエンドポイント上の新しい接続に対してプローブダウンシグナルを送信します。 既存の接続に対する保留中の要求は引き続き処理されます。 |
ヘルスプローブは、スケーリング操作を最適化するのに役立ちます。 これにより、スケールアウト中にアプリケーションが受信負荷を処理できるようになります。 スケールイン操作の前に、継続的な操作を中断することなく、インスタンスをスムーズに削減できます。 |
Azure のポリシー
Azure には、Load Balancer とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 上記の推奨事項の一部は、Azure Policy を使用して監査できます。 たとえば、次のことを確認できます。
- Basic SKU ロード バランサーを除くロード バランサーでは、フロントエンドのパブリック IP アドレスに対して回復性機能が有効になっています。
- リソース ログは、リソースで発生したアクティビティとイベントを追跡し、変更の可視性と分析情報を提供するために有効になります。
包括的なガバナンスを実現するために、Load Balancer を対象とする Azure Policy の組み込み定義 と、トラフィック分散のセキュリティに影響を与える可能性のあるその他のポリシーを確認してください。
Azure Advisor の推奨事項
Azure Advisor は、ベスト プラクティスに従って Azure デプロイメントを最適化できるようにする、個人用に設定されたクラウド コンサルタントです。 Advisor の推奨事項は、Well-Architected Framework の柱に沿っています。
詳細については、Azure Advisor の推奨事項参照してください。