編集

ゲートウェイ オフロード パターン

Azure Application Gateway

共有または専用のサービス機能の負荷をゲートウェイ プロキシにオフロードします。 このパターンは、SSL 証明書の使用などの共有サービス機能を、アプリケーションの他の部分からゲートウェイに移動することで、アプリケーション開発をシンプルにします。

コンテキストと問題

一部の機能は複数のサービスでよく使用されます。こうした機能には、構成、管理、およびメンテナンスが必要です。 すべてのアプリケーションのデプロイで分散される共有または専用のサービスにより、管理オーバーヘッドが増加し、デプロイ エラーの可能性が高くなります。 共有機能に対するすべての更新を、その機能を共有するすべてのサービスにデプロイする必要があります。

セキュリティの問題 (トークンの検証、暗号化、SSL 証明書の管理) とその他の複雑なタスクを適切に処理するには、チーム メンバーに高度な専門スキルが必要です。 たとえば、アプリケーションで必要な証明書は、すべてのアプリケーション インスタンスで構成およびデプロイする必要があります。 新しくデプロイするたびに、証明書の有効期限が切れないように、その証明書を管理する必要があります。 有効期限が切れそうな一般的な証明書は、すべてのアプリケーション デプロイで更新、テスト、および確認する必要があります。

認証、承認、ログ、監視、調整など、他の一般的なサービスについては、デプロイ数が膨大になると、実装および管理するのが困難です。 オーバーヘッドとエラーの可能性を減らすために、この種類の機能は統合する方がよい場合があります。

解決策

一部の機能、特に証明書の管理、認証、SSL 終了、監視、プロトコル変換、調整など、分野横断的な懸念事項を、ゲートウェイにオフロードします。

次の図は、受信 SSL 接続を終了するゲートウェイを示しています。 これは、元の要求元に代わって、ゲートウェイの HTTP サーバー アップ ストリームからデータを要求します。

ゲートウェイ オフロード パターンの図

このパターンには次のような利点があります。

  • Web サーバー証明書、安全な Web サイトの構成など、関連リソースを配布および管理する必要をなくして、サービス開発をシンプルにします。 構成がシンプルになると、管理が容易になり、スケーラビリティが実現し、サービスのアップグレードも簡単になります。

  • 専用チームが、セキュリティなどの専門的知識を必要とする機能を実装できます。 これにより、こうした分野横断的で特殊な懸念事項を、関連するエキスパートに任せることができるため、コア チームはアプリケーション機能に集中できます。

  • 要求と応答のログ記録および監視に対してある程度の一貫性を提供します。 サービスが正しくインストルメント化されていなくても、最小限の監視およびログ記録レベルが確保されるように、ゲートウェイを構成できます。

問題と注意事項

  • ゲートウェイが高可用性を備え、障害に対する回復性があることを確認します。 ゲートウェイの複数のインスタンスを実行し、単一障害点をなくします。
  • アプリケーションおよびエンドポイントの容量とスケーリングの要件に対応できるようにゲートウェイが設計されていることを確認します。 ゲートウェイがアプリケーションのボトルネックになっていないこと、また、十分にスケーラブルであることを確認します。
  • セキュリティ、データ転送など、アプリケーション全体で使用される機能のみをオフロードします。
  • ビジネス ロジックはゲートウェイにオフロードしないでください。
  • トランザクションを追跡する必要がある場合は、ログ記録のために関連付け ID を生成することを検討します。

このパターンを使用する状況

このパターンは次の状況で使用します。

  • アプリケーションのデプロイに、SSL 証明書、暗号化など、共通の懸念事項があるとき。
  • アプリケーション デプロイで共通の機能に、さまざまなリソース要件 (メモリ リソース、ストレージ容量、ネットワーク接続など) があるとき。
  • ネットワーク セキュリティ、調整、他のネットワーク境界の懸念事項にかかわる問題への対応を、専門チームに任せたいとき。

サービス間の結合が導入されている場合、このパターンは適切でない可能性があります。

ワークロード設計

設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、ゲートウェイ オフロードパターンをワークロードの設計でどのように使用できるかを評価する必要があります。 次に例を示します。

重要な要素 このパターンが柱の目標をサポートする方法
信頼性設計の決定により、ワークロードが誤動作に対して復元力を持ち、障害発生後も完全に機能する状態に回復することができます。 この責任をゲートウェイにオフロードすると、バックエンドノード上のアプリケーション コードの複雑さが軽減されます。 場合によっては、オフロードが機能を信頼性の高いプラットフォーム提供機能に完全に置き換えることもあります。

- RE: 01 シンプルさと効率性
セキュリティ設計の決定により、ワークロードのデータとシステムの機密性、整合性、および可用性が確保されます。 要求フローにゲートウェイを追加すると、ウェブアプリケーションファイアウォールやクライアントとの TLS 接続などのセキュリティ機能を一元化できます。 プラットフォームが提供するオフロード機能は、すでにセキュリティを強化しています。

- SE:06 ネットワーク制御
- SE:08 リソースの強化
コスト最適化は、ワークロードの投資収益率の維持と改善に重点を置いています。 このパターンを使用すると、ノードごとに消費されるリソースからゲートウェイ実装にコストをリダイレクトできます。 集中処理モデルのコストは、分散モデルのコストよりも低いことがよくあります。

- CO: 14 統合
オペレーショナルエクセレンス は、標準化されたプロセスとチームの結束によってワークロードの品質を提供します。 このパターンでは、オフロードされた機能の設定と維持は、複数のノードから管理するのではなく、単一ポイントから行われます。

- OE:04 ツールとプロセス
パフォーマンスの効率化は、スケーリング、データ、コードを最適化することによって、ワークロードが効率的にニーズを満たすのに役立ちます。 要求プロセスにオフロードゲートウェイを追加すると、機能がゲートウェイに集中しているため、ノードごとのリソース使用量を減らすことができます。 オフロードされた機能の実装は、アプリケーションコードとは無関係に最適化できます。 オフロードされたプラットフォームで提供される機能は、すでに高いパフォーマンスを発揮している可能性があります。

- PE:03 サービスの選択

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

例

次の構成は、Nginx を SSL オフロード アプライアンスとして使用して、受信 SSL 接続を終了し、接続を 3 台のアップストリーム HTTP サーバーのいずれかに分散します。

upstream iis {
        server  10.3.0.10    max_fails=3    fail_timeout=15s;
        server  10.3.0.20    max_fails=3    fail_timeout=15s;
        server  10.3.0.30    max_fails=3    fail_timeout=15s;
}

server {
        listen 443;
        ssl on;
        ssl_certificate /etc/nginx/ssl/domain.cer;
        ssl_certificate_key /etc/nginx/ssl/domain.key;

        location / {
                set $targ iis;
                proxy_pass http://$targ;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
        }
}

Azure では、Application Gateway で SSL 終了を設定することによってこれを実現できます。