この記事では、Azure Batch を使って Azure で金融サービス業界 (FSI) のワークロードを実行するためのベースライン アーキテクチャについて説明します。
Architecture
このアーキテクチャ ダイアグラムを含む Visio ファイルをダウンロードします。
ワークフロー
このシナリオ例では、Azure Batch を使って Azure で FSI のワークロードを実行する方法を示します。 次のような一般的なワークフローに従うことを想定します。
- VPN Gateway を使ってプライベート ネットワークに接続します。 または、Azure Bastion を使ってジャンプボックス VM に RDP または SSH で接続します。 どちらの方法も、プライベート ネットワークへの接続に使用できます。
- Azure CLI、Azure Storage Explorer、または
azcopy
を使って、データセットを処理のためにストレージ アカウントにアップロードします。 - Azure CLI、Batch Explorer、または他のツールを使って、データを処理するためのジョブを Batch サービスに送信します。 このデプロイ例では、ジョブの送信にも使用できるカスタム コマンド ライン ツールを開発しました。
- プールのサイズを変更して、コンピューティング ノードをプールに追加します。 既定では、デプロイによってコンピューティング ノードを含まないプールが作成されます。
- ストレージ アカウントから結果をダウンロードします。 ジョブが完了すると、結果はストレージ アカウントに格納されます。 その後、Azure CLI、Azure Storage Explorer、または
azcopy
を使って、これらの結果をダウンロードできます。
コンポーネント
このアーキテクチャは、複数の Azure サービスで構成され、ハブ リソースとスポーク リソースという 2 つのカテゴリのリソースに分かれています。 ハブ アンド スポーク ネットワーク トポロジの詳細については、この記事で後ほど説明します。 以下のセクションでは、それぞれのサービスとその役割について説明します。
ハブのリソース
まず、ハブ ネットワークにデプロイされるリソースを見てみましょう。 これらの共有リソースにより、スポーク ネットワークと外界の間の通信の有効化、フィルター処理、監視が行われます。
ハブ ネットワークには、次のリソースがデプロイされます。
Azure Firewall は、ネットワークにネットワーク レベルの保護を提供します。 ファイアウォールは、特定のトラフィックのみがネットワークを出入りするのを許可するように構成されます。 この構成は、悪意のある攻撃からネットワークを保護し、ネットワークを出入りするトラフィックを監視するのに役立ちます。 その規則は、ビジネス固有のルールと規制に基づいて更新する必要があります。
Azure VPN Gateway は、パブリック インターネットからハブ ネットワークに接続するための 2 つの方法のうちの 1 つを有効にします。 もう 1 つの方法は、Azure Bastion サービスを使うものです。 VPN クライアントがパブリック インターネットから接続できるように、VPN ゲートウェイにはパブリック IP アドレスが割り当てられます。
Azure Bastion は、パブリック インターネットからジャンプボックスに接続するための 2 つの方法のうちの 1 つを有効にします。 もう 1 つの方法は、VPN Gateway を使うものです。 Azure Bastion はハブ ネットワークにデプロイされ、ユーザーがパブリック インターネットから接続できるように、パブリック IP アドレスが割り当てられます。
Linux ジャンプボックスは、デプロイされたリソースにアクセスし、ジョブを送信し、進行状況を監視するためのツールがプレインストールされた Linux VM です。 ジャンプボックスはハブ ネットワークにデプロイされ、VPN ゲートウェイまたは Azure Bastion を使ってオンプレミス ネットワークからアクセスできます。
Windows ジャンプボックスは、デプロイされたリソースにアクセスし、ジョブを送信し、進行状況を監視するためのツールがプレインストールされた Windows VM です。 ジャンプボックスはハブ ネットワークにデプロイされ、VPN ゲートウェイまたは Azure Bastion を使ってオンプレミス ネットワークからアクセスできます。
Log Analytics ワークスペースを使うと、ログを収集できます。 デプロイされるリソースは、可能な限り、ワークスペースにログを保存するように構成されます。 ログは、リソースの監視と問題のトラブルシューティングに使われます。 Azure Application Insights と組み合わせると、デプロイされたリソースに関するパフォーマンス監視とトラブルシューティングの機能が提供されます。
Azure DNS Private Resolver は、プロビジョニングされた仮想ネットワークの外部 (オンプレミスのリソースなど) からクエリが実行される場合に、プライベート エンドポイントの IP を解決するためのインバウンド エンドポイントを提供します。 DNS Private Resolver は、Azure VPN Gateway がデプロイされるときにデプロイされます。
スポークのリソース
次に、スポーク ネットワークにデプロイされるリソースを見てみましょう。 これらのリソースは、計算ワークロードとすべてのサポート リソースを実行するのに役立ちます。
スポーク ネットワークにデプロイされるリソースは次のとおりです。
Azure Batch は、このアーキテクチャがクラウドネイティブのジョブのスケジュール設定と実行において依存するコア サービスです。 Azure Batch は、必要なコンピューティング リソースを管理し、コンピューティング リソースでのタスクをスケジュールし、タスクの完了を監視します。 Batch サービスは 2 つのプールでデプロイされます。1 つは Linux コンピューティング ノードを含む
linux
という名前のプール、もう 1 つは Windows コンピューティング ノードを含むwindows
という名前のプールです。 プールは、次のように構成されます。- ユーザー サブスクリプションのプール割り当てモードを使います。 Batch サービスによって内部的に使われるすべてのリソースは、Batch アカウントと同じサブスクリプションに割り当てられ、サブスクリプション固有のクォータとポリシーを使います。
- スポーク ネットワーク上の対応するサブネットを使うため、サブネットのアドレス範囲からアドレス空間を割り当てられます。 また、これは、それらのサブネットで設定されているすべてのネットワーク セキュリティ グループ (NSG) 規則とトラフィック転送規則も計算ノードに適用されることも意味します。
- 計算ノードにパブリック インターネットから直接アクセスできないようにするため、パブリック IP アドレスは計算ノードに割り当てられません。
- 初期化の間にサポートされるストレージ リソースを計算ノードにマウントすることで、計算ノートで実行されるワークロードが共有ストレージ リソースに簡単にアクセスできるようにします。
- 計算ノードがバッチ プールに参加するときに、ユーザー割り当てマネージド ID を使って、ストレージ アカウント、Container Registry、その他のリソースでその認証を行います。 そうすることで、計算ノードは、パスワードやキーの代わりに証明書を使って認証されるようになります。
Azure Key Vault は、Batch アカウント証明書などのデプロイのシークレットを格納します。 これらの証明書は、計算ノード リソースがバッチ プールに参加するときの認証のために使われます。 Key Vault はスポーク ネットワークにデプロイされ、Batch サービスからのアクセスのみを許可するように構成されます。 この構成により、パブリック インターネットから証明書にアクセスできなくなります。
Azure Storage は、入力と出力のデータを格納します。 デプロイでは、Blob Storage 用と File Storage 用の 2 つのストレージ アカウントが作成されます。 Blob Storage のアカウントは、NFS を使って Linux プールにマウントされます。 File Storage のアカウントは、SMB を使って Linux と Windows 両方のプールにマウントされます。
Azure Container Registry は、バッチ コンピューティング ノードによって使われるコンテナー イメージを格納します。 コンテナー レジストリのプライベート デプロイを使うと、コンテナー イメージへのアクセスを制御するのに役立ち、コンテナー イメージを格納するいっそう安全な方法も提供されます。 コンテナー レジストリはスポーク ネットワークにデプロイされ、Batch サービスからのアクセスのみを許可するように構成されます。 この構成により、パブリック インターネットからコンテナー レジストリにアクセスできなくなります。
Azure マネージド ID は、プールに追加されたコンピューティング ノードの、Container Registry、ストレージ アカウント、その他のリソースでの認証を自動的に行うために使われます。
代替
Azure Kubernetes Service (AKS) は、コンテナー化されたアプリケーション用の同様の構成で Azure Batch サービスの代わりに使用できます。
Azure CycleCloud は、Azure 上のハイパフォーマンス コンピューティング (HPC) クラスターを管理するために使用できます。 このような HPC クラスターは、この記事で対象としているもののようなワークロードを実行するように設定できます。
シナリオの詳細
FSI の一般的なコンピューティング パターンでは、金融商品または金融商品のポートフォリオを特徴付ける入力データセットに対して、多数のコンピューティング集中型シミュレーションが実行されます。 通常、シミュレーションは並列で実行され、結果が集計されてポートフォリオのリスク プロファイルの概要が生成されます。
このアーキテクチャは特定のワークロードを対象にしたものではなく、Azure Batch を使ってコンピューティング集中型シミュレーションを実行するアプリケーションに焦点が当てられています。 どのような運用デプロイ アーキテクチャも、ワークロードとビジネス環境の特定の要件を満たすようにカスタマイズする必要があります。 このアーキテクチャは、運用前と運用のデプロイのためのこのようなカスタマイズの出発点として使うことが意図されています。
考えられるユース ケース
このアーキテクチャは、さまざまな FSI ワークロードを実行するために使用できます。 次に例をいくつか示します。
- 金融商品のポートフォリオのリスク分析
- 金融商品の価値を見積もるためのモンテカルロ シミュレーション
- トレーディング戦略のバック テスト
- 金融商品のポートフォリオのストレス テスト
ネットワーク トポロジ
このアーキテクチャでは、ハブ アンド スポークのネットワーク トポロジを使います。 ハブとスポークのリソースは個別の仮想ネットワークにデプロイされ、仮想ネットワーク ピアリング経由で接続されます。 ハブ ネットワークには、ファイアウォール、VPN Gateway、ジャンプ ボックスなどの共有リソースが含まれます。 スポーク ネットワークには、Batch サービスと Batch 計算ノードが含まれます。 また、ストレージ アカウントや Container Registry など、ワークロードで必要な他のサービス エンドポイントも含まれます。 スポーク ネットワークはパブリック インターネットから分離されており、ハブ ネットワークからのみアクセスできます。
ネットワーク トポロジの要点を次に示します。
- スポーク上のリソースはパブリック インターネットから分離されており、ハブ ネットワークからのみアクセスできるため、パブリック インターネットへのリソースの直接的な露出が最小限に抑えられます。
- プールの計算ノードからのものを含むすべての送信トラフィックは、ファイアウォール経由でルーティングされるため、すべての送信トラフィックがフィルター処理、ログ、追跡されます。
- ファイアウォールは、許可リストに含まれるトラフィックのみを許可するように構成されているため、許可リストに含まれるトラフィックのみが仮想ネットワークから出て行くことができます。
- スポーク ネットワーク上のリソースへのアクセスは、必要に応じてデプロイされる VPN Gateway または Azure Bastion 経由で行うことがことできます。 どちらも、パブリック インターネットからハブ ネットワークに接続するための安全な方法を提供します。
- Windows と Linux のジャンプボックスには、デプロイされたリソースへのアクセス、ジョブの送信、進行状況の監視を行うためのツールがプレインストールされています。 これらのジャンプボックスはハブ ネットワークにデプロイされ、VPN ゲートウェイまたは Azure Bastion を使ってオンプレミス ネットワークからアクセスできます。
- すべての Azure サービスは、パブリック エンドポイント経由ではなくプライベート ネットワーク経由で確実にアクセスされるように、プライベート エンドポイントを使います。 この構成は、パブリック インターネットからサービスにアクセスできないようにするのにも役立ちます。
- NSG 規則は、必要なトラフィックだけが仮想ネットワークを出入りできるように設定されます。 この構成は、悪意のある攻撃からネットワークを保護し、ネットワークを出入りするトラフィックを監視するのに役立ちます。 これらの規則では、仮想ネットワーク内のリソース間のトラフィックも制限されます。
ハブ仮想ネットワーク
ハブの仮想ネットワークには、スポークのネットワークを出入りするトラフィックを許可または監視するリソースが含まれています。 仮想ネットワークのデプロイ テンプレートでは、次のサブネットが定義されています。
GatewaySubnet
: VPN ゲートウェイのサブネット (デプロイされる場合)AzureBastionSubnet
: Azure Bastion サービスのサブネット (デプロイされる場合)AzureFirewallSubnet
: Azure Firewall サービスのサブネットsn-jumpbox
: ジャンプボックスのサブネットsn-dnspr
: Azure DNS リゾルバーにデリゲートされるサブネット
スポーク仮想ネットワーク
スポークの仮想ネットワークには、Batch サービス、Batch 計算ノード、およびワークロードで必要な他のサービス エンドポイントが含まれます。 仮想ネットワークのデプロイ テンプレートでは、次のサブネットが定義されています。
pool-linux
: Linux プールのサブネットpool-windows
: Windows プールのサブネットprivate-endpoints
: スポークのネットワークにデプロイされている Azure サービスのプライベート エンドポイントに使われるサブネット
スポーク ネットワークはハブ ネットワークとピアリングされるため、スポーク ネットワーク上のリソースはハブ ネットワーク上のリソースにアクセスできます。 ルート テーブルは、スポーク間のトラフィックがファイアウォール経由でルーティングされるように設定されます。
リソースへのアクセス
Batch サービスに計算ジョブを送信するには、Batch サービス エンドポイントに接続してジョブを送信し、その進行状況を監視します。 Batch サービスはプライベート エンドポイントを使うように設定されているため、ネットワーク内からのみアクセスできます。
このアーキテクチャには、Batch サービスにジョブを送信できるように、ネットワークに接続するための 2 つのオプションが用意されています。
VPN Gateway を使います。 VPN Gateway を使ってハブ ネットワークに接続します。 VPN に接続された後は、ローカル コンピューターから Batch サービスにジョブを直接送信できます。これにより、ローカル コンピューターにインストールされている Batch Explorer を使ったジョブの監視もしやすくなります。 この構成では、Azure CLI、Batch Explorer、その他のツールが、ローカル コンピューターにインストールされている必要があります。 または、VPN に接続された後、Linux または Windows のジャンプボックスを使って Batch サービスにジョブを送信することもできます。 そのためには、ローカル コンピューターに SSH クライアントまたは RDP クライアントがインストールされている必要があります。
Azure Bastion を使います。 VPN を使う代わりに、Azure Bastion を使って Linux または Windows のジャンプボックスにサインインできます。 Azure portal にサインインした後、Azure Bastion を使って Web ブラウザーからジャンプボックスの VM に直接サインインします。 ジャンプボックスにサインインした後は、ジャンプボックスにインストールされている Azure CLI、Batch Explorer、その他のツールを使って、Batch サービスにジョブを送信できます。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
このワークフロー例では、自動化の準備がまだできていないワークロードの出発点として、手動でのデータ転送とジョブの送信に依存しています。 一方、運用ワークロードの場合は、データ転送とジョブの送信を自動化することをお勧めします。これは、Azure Data Factory または他のワークフロー オーケストレーション ツールを使って実行できます。
バッチ プールは、プールに送信されるジョブの数に基づいて自動的にスケールアップおよびスケールダウンするように設定できます。 この構成は、実行するジョブがないときにプールの実行コストを減らすのに役立ちます。 詳しくは、Azure Batch プール内の計算ノードの自動スケーリングに関する記事をご覧ください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
パスワードやキーなどのシークレットの共有を最小限に抑えるため、このアーキテクチャでは、計算ノードがバッチ プールに参加するときの、ストレージ アカウント、Container Registry、その他のリソースに対する認証に、マネージド ID を使います。 この認証は、バッチ プールにマネージド ID を割り当ててから、マネージド ID にリソースへのアクセスを許可することで行われます。 ロールベースのアクセス制御を使うことで、リソースへのアクセスに必要な最小限の特権をマネージド ID に付与できます。
また、このアーキテクチャでは、パブリック インターネットからサービスにアクセスできないようにするため、プライベート エンドポイントを使います。 この構成は、攻撃面を最小限に抑えるのに役立ち、サービスがパブリック エンドポイント経由ではなくプライベート ネットワーク経由でクセスされるようにするのにも役立ちます。
また、このアーキテクチャでは、ネットワークを出入りするトラフィックのフィルター処理と監視に、Azure Firewall が使われます。 ファイアウォールは、許可リストに含まれるトラフィックのみを許可するように構成されているため、許可リストに含まれるトラフィックのみが仮想ネットワークから出て行くことができます。 この構成は、悪意のある攻撃からネットワークを保護し、ネットワークを出入りするトラフィックを監視するのに役立ちます。
計算ノードにはパブリック IP アドレスが割り当てられないため、計算ノード自体はパブリック インターネットからアクセスできません。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
Azure Batch 自体は無料のサービスであり、お客様はその基になる仮想マシン、ストレージ、ネットワークのコストに対してのみ料金を支払います。 このワークロードで計算ノードの他にコストが発生するリソースは、ストレージ アカウント、ジャンプボックス、VPN Gateway、Azure Bastion です。 ワークロードはリソースにアクセスするための代替手段をサポートするように設計されているため、それらのパスのいずれかを選ぶことで、実行コストを最適化できます。 たとえば、リソースにアクセスするのに VPN Gateway が望ましい場合は、デプロイ時に Azure Bastion とジャンプボックスの VM を無効にしてコストを削減できます。
コンピューティング リソースに関連するコストを削減するには、コスト効率が高い VM SKU をワークロードに使います。 さらに、スポット インスタンスまたはプールの自動スケーリングを使うと、計算ノード関連のコストを削減できます。
このワークロードの実行コストを確認するには、Azure の料金計算ツールをお使いください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
Batch では、ワークロードに適した VM SKU を使うことで効率的なパフォーマンスを実現できます。 ワークロードに適した VM SKU を選ぶ方法について詳しくは、「Azure コンピューティング ユニット」をご覧ください。 計算ードの VM サイズの選択に関する記事では、デプロイ リージョンに基づく適切な VM SKU の選択についてのさらに詳しいガイダンスが提供されています。
このシナリオのデプロイ
この参照アーキテクチャのコードとしてのインフラストラクチャ (IaC) のソース コードは、Azure Batch アクセラレータ リポジトリで入手できます。 それに含まれるチュートリアルでは、この参照アーキテクチャをデプロイする方法と、それを使って azfinsim
という名前のサンプル FSI ワークロードを実行する方法がわかります。 次のボタンを使うと、Azure portal を使ってご自分のサブスクリプションにリソースをデプロイすることもできます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Utkarsh Ayachit | プリンシパル プログラム マネージャー
- Darko Mocelj | EMEA HPC および AI シニア テクノロジ スペシャリスト
次のステップ
学習モジュール