イベント ドリブン ワークフロー (EDW) ワークロードを Azure Kubernetes Service (AKS) 用に再設計する

このワークロードに関連する AWS と Azure の主なプラットフォームの違いを理解したので、ワークフロー アーキテクチャを見てみましょう。これを AKS で動作するように変更できます。

AWS ワークロード アーキテクチャ

AWS ワークロードは、競合コンシューマー設計パターンの基本的な例です。 AWS の実装は、Kubernetes、Kubernetes Event-driven Autoscaling (KEDA) 、および Karpenter を使用して、イベント ドリブン ワークフローのスケールとコストを管理するためのリファレンス アーキテクチャです。

プロデューサー アプリがキューにメッセージを送信して負荷を生成し、Kubernetes ポッドで実行されているコンシューマー アプリがメッセージを処理して結果をデータベースに書き込みます。 KEDA がプロデューサー キューへの宣言型バインドによってポッドの自動スケーリングを管理し、Karpenter がコストを最適化するのに十分なだけのコンピューティングでノードの自動スケーリングを管理します。 キューとデータベースに対する認証は、OAuth ベースのサービス アカウント トークン ボリューム プロジェクションを使用します。

ワークロードは AWS EKS クラスターで構成されていて、Amazon Simple Queue Service (SQS) からメッセージを読み取り、処理されたメッセージを Amazon DynamoDB テーブルに保存するコンシューマーを調整します。 プロデューサー アプリがメッセージを生成し、Amazon SQS キューに登録します。 KEDA と Karpenter が、コンシューマーに使用される EKS ノードとポッドの数を動的にスケーリングします。

次のダイアグラムは、AWS の EDW ワークロードのアーキテクチャを表しています。

AWS サービスから Azure サービスへのマップ

Azure での AWS ワークロードの再作成を最小限の変更で行うには、各 AWS サービスと同等の Azure を使用し、元の方法と類似の認証方法を維持します。 この例では、Azure Service Bus や Azure Event Hubs の高度な機能は必要ありません。 そうせずに、作業を再生待ちに追加するために Azure Queue Storage を、結果を保存するために Azure Table Storage を使用できます。

次の表に、サービス マッピングをまとめています。

サービス マッピング	AWS サービス	Azure サービス
キューイング	Simple Queue Service	Azure Queue Storage
永続化	DynamoDB (NoSQL)	Azure Table Storage
オーケストレーション	Elastic Kubernetes Service (EKS)	Azure Kubernetes Service (AKS)
ID	AWS IAM	Microsoft Entra

Azure ワークロード アーキテクチャ

次のダイアグラムは、AWS から Azure へのサービス マッピングを使用した Azure EDW ワークロードのアーキテクチャを示しています。

コンピューティング オプション

コストに対する考慮と、予期されるノード削除に対する回復性に応じて、さまざまな種類のコンピューティングから選択できます。

AWS では、オンデマンド コンピューティング (より高価だが削除リスクなし) とスポット インスタンス (低コストだが削除リスクあり) のいずれかを選択できます。 AKS では、ワークロードのニーズに応じて、オンデマンド ノード プールまたはスポット ノード プールを選択できます。

次のステップ

アプリケーション コードを AKS 用にリファクタリングする

共同作成者

Microsoft では、この記事を保持しています。 最初の寄稿者は次のとおりです。

• Ken Kilty | プリンシパル TPM
• Russell de Pina | プリンシパル TPM
• Jenny Hayes | シニア コンテンツ開発者
• Carol Smith | シニア コンテンツ開発者
• Erin Schaffer |コンテンツ開発者 2