AWS と Azure のプラットフォームの違いについて理解を深めたので、AWS の Web アプリケーション アーキテクチャと、 Azure Kubernetes Service (AKS) との互換性を高めるために必要な変更について調べてみましょう。
Yelb アプリケーション アーキテクチャ
Yelb サンプル Web アプリケーションは、yelb-ui と呼ばれるフロントエンド コンポーネントと、yelb-appserver というアプリケーション コンポーネントで構成されます。
yelb-uiは、JavaScript コードをブラウザーに提供します。 このコードは Angular アプリケーションから コンパイルされます。
yelb-ui コンポーネントには、デプロイ モデルに応じてnginx プロキシが含まれる場合もあります。
yelb-appserverは、キャッシュ サーバー () と Postgres バックエンド データベース (redis-server) と対話する yelb-db アプリケーションです。
Redis Cache にはページ ビューの数が格納されますが、 PostgreSQL では投票が保持されます。 どちらのサービスも、AWS または Azure にデータを格納するためのマネージド サービスを使用せずに Kubernetes にデプロイされます。
元の Yelb アプリケーションは自己完結型であり、外部サービスに依存しないため、コードを変更することなく AWS から Azure に移行できます。 Azure では、AKS にデプロイされた Redis Cache サービスと PostgreSQL サービスの代わりに、Azure Managed Redis と Azure Database for PostgreSQL を使用できます。
サンプル Yelb アプリケーションを使用すると、ユーザーは一連の選択肢 (レストラン) に投票し、受け取った投票数に基づいて円グラフを動的に更新できます。 また、アプリケーションはページ ビューの数を追跡し、投票またはページの更新時に API 要求を処理する yelb-appserver インスタンスのホスト名を表示します。 この機能を使用すると、アプリケーションを個別または共同作業でデモできます。
AWS のアーキテクチャ
一般的な Web の悪用から Web アプリケーションと API を保護するために、AWS は AWS Web Application Firewall (WAF) と AWS Firewall Manager を提供します。
AWS サービスを Azure サービスにマップする
最小限の変更で Azure で AWS ワークロードを再作成するには、AWS サービスごとに同等の Azure を使用します。 次の表に、サービス マッピングの概要を示します。
| サービス マッピング | AWS サービス | Azure サービス |
|---|---|---|
| Web アクセス ファイアウォール | AWS Web Application Firewall (WAF) | Azure Web アプリケーション ファイアウォール (WAF) |
| アプリケーションの負荷分散 | Application Load Balancer (ALB) | Azure Application GatewayApplication Gateway for Containers (AGC) |
| コンテンツ配信ネットワーク | Amazon CloudFront | Azure Front Door (AFD) |
| オーケストレーション | Elastic Kubernetes Service (EKS) | Azure Kubernetes Service (AKS) |
| Secrets ボールト | AWS Key Management Service (KMS) | Azure Key Vault |
| コンテナー レジストリ | Amazon Elastic Container Registry (ECR) | Azure Container Registry (ACR) |
| ドメイン ネーム システム (DNS) | Amazon Route 53 | Azure DNS |
| キャッシュ処理 | Amazon ElastiCache | Azure Managed Redis |
| NoSQL | Amazon DynamoDB | Azure Database for PostgreSQL |
Azure サービスと AWS サービスの包括的な比較については、 AWS と Azure のサービスの比較に関するページを参照してください。
Azure でのアーキテクチャ
このソリューションでは、 Yelb アプリケーションは AKS クラスターにデプロイされ、 NGINX イングレス コントローラーなどのイングレス コントローラーを介して公開されます。 イングレス コントローラー サービスは、 内部 (またはプライベート) ロード バランサーを介して公開されます。 内部ロード バランサーを使用して AKS 内のアプリケーションへのアクセスを制限する方法の詳細については、「 Azure Kubernetes Service (AKS) で内部ロード バランサーを使用する」を参照してください。
このサンプルでは、Helm チャートを使用して、アプリケーション ルーティング アドオンを使用したマネージド NGINX イングレス コントローラーまたはアンマネージド NGINX イングレス コントローラーのインストールをサポートしています。 NGINX イングレス コントローラーを使用したアプリケーション ルーティング アドオンには、次の機能があります。
- Kubernetes NGINX イングレス コントローラーに基づくマネージド NGINX イングレス コントローラーの簡単な構成。
- パブリック ゾーンとプライベート ゾーン管理のための Azure DNS との統合。
- Azure Key Vault に格納されている証明書を使用した SSL 終了。
その他の構成については、次の記事を参照してください。
Yelb アプリケーションは、AKS クラスターと同じ仮想ネットワーク内またはピアリングされた仮想ネットワーク内の専用サブネットにデプロイされた Azure Application Gateway リソースで保護されます。 Azure Web Application Firewall (WAF) を使用して Yelb アプリケーションへのアクセスをセキュリティで保護できます。これは、一般的な悪用や脆弱性から Web アプリケーションを一元的に保護します。
ソリューション アーキテクチャの設計
次の図は、Azure で推奨されるアーキテクチャを示しています。
ソリューション アーキテクチャは、次の要素で構成されます。
- Application Gateway は TLS 終了を処理し、HTTPS 経由でバックエンド アプリケーションと通信します。
- Application Gateway リスナーは、 Azure Key Vault から取得した SSL 証明書を使用します。
- リスナーに関連付けられている Azure WAF ポリシーは、受信要求に対して OWASP ルールとカスタム ルールを実行し、悪意のある攻撃をブロックします。
- Application Gateway バックエンド HTTP 設定は、ポート 443 で HTTPS 経由で Yelb アプリケーションを呼び出します。
- Application Gateway バックエンド プールと正常性プローブは、HTTPS を使用して AKS 内部ロード バランサーを介して NGINX イングレス コントローラーを呼び出します。
- NGINX イングレス コントローラーは、AKS 内部ロード バランサーを使用します。
- AKS クラスターは、CSI ボリュームを介して Azure Key Vault からシークレット、証明書、およびキーを取得するために、シークレット ストア CSI Driver アドオン用の Azure Key Vault プロバイダーで構成されます。
- SecretProviderClass は、Application Gateway で使用されるのと同じ証明書を Azure Key Vault から取得します。
- Kubernetes イングレス オブジェクトは、NGINX イングレス コントローラーを使用して、AKS 内部ロード バランサーを介して HTTPS 経由でアプリケーションを公開します。
- Yelb サービスの種類は
ClusterIPであり、NGINX イングレス コントローラーを介して公開されます。
このアーキテクチャを使用して AKS に Yelb アプリケーション をデプロイする包括的な手順については、 コンパニオン サンプルを参照してください。
代替ソリューション
Azure には、AKS クラスターに Web アプリケーションをデプロイし、Web アプリケーション ファイアウォールを使用してセキュリティで保護するためのオプションがいくつか用意されています。
Application Gateway イングレス コントローラー (AGIC) は Kubernetes アプリケーションであるため、Azure のネイティブ Application Gateway L7 ロード バランサーを利用して、Azure Kubernetes Service (AKS) ワークロード用にクラウド ソフトウェアをインターネットに公開できます。 AGIC は、ホストされている Kubernetes クラスターを監視し、選択したサービスがインターネットに公開されるように Application Gateway を継続的に更新します。
イングレス コントローラーは、AKS クラスター上の独自のポッドで実行されます。 AGIC は、Kubernetes リソースのサブセットの変更を監視し、クラスターの状態を Application Gateway 固有の構成に変換して、 Azure Resource Manager (ARM) に適用します。 詳細については、「 Application Gateway イングレス コントローラーとは」を参照してください。
次の表に、Application Gateway イングレス コントローラー (AGIC) の長所と短所を示します。
| 利点 | 欠点 |
|---|---|
|
*
ネイティブ統合: AGIC は、Azure サービス (特に Azure Application Gateway) とのネイティブ統合を提供します。これにより、AKS で実行されているサービスへのトラフィックをシームレスかつ効率的にルーティングできます。 * デプロイの簡略化: AKS アドオンとしての AGIC のデプロイは、他の方法と比較して簡単で簡単です。 これにより、AGIC が有効になっている Application Gateway と AKS クラスターの迅速かつ簡単なセットアップが可能になります。 * フル マネージド サービス: アドオンとしての AGIC はフル マネージド サービスであり、自動更新や Microsoft からのサポートの強化などの利点を提供します。 これにより、イングレス コントローラーが最新の状態に維持され、追加のサポート層が提供されます。 |
* 単一クラウド アプローチ: AGIC は、主に単一クラウド アプローチを採用する顧客によって採用されます。 異なるクラウド プラットフォーム間でのデプロイが必要なマルチクラウド アーキテクチャが必要な場合は、最適な選択肢ではない可能性があります。 この場合、NGINX、Traefik、HAProxy などのクラウドに依存しないイングレス コントローラーを使用して、vendo-lockin の問題を回避できます。 |
詳細については、次のリソースを参照してください。
