以下で説明するワークロードの例では、Azure DevOps パイプラインを使用して自動的に実行され、シミュレートされた車両機能を評価するシミュレーションの構築について説明します。 このパイプラインは、エンジニアが例の機能のソース コードまたはシミュレーション環境の新しいバージョンを確認するたび実行されます。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ユーザー入力レイヤー
開発者はこのレイヤーとのみやり取りします。 開発者のワークステーション (ここでは Azure VM) と、シミュレーション環境を記述する仕様ファイルが含まれます。
オーケストレーション レイヤー
"オーケストレーション" には広い意味があります。この単語によって示される一部の問題は、簡単に解決されます。その他の問題ははるかに複雑です。 たとえば、コンテナーと VM の作成、監視、破棄に関する "オーケストレーション" の問題は、多くのツールによって解決されます。Azure API 自体は、このための十分な "オーケストレーター" です。
ワークフロー
ただし、"オーケストレーション" のブラック ボックスを小さなコンポーネントに分割することが重要です。
シミュレーション API: この API は仕様ファイルを受け取り、オーケストレーション レイヤーでシミュレーション環境とシミュレーションの実行を制御するためのエントリ ポイントです。
インタープリター: このコンポーネントでは、仕様ファイルをシミュレーション マネージャーの論理構造に解釈します。
シミュレーション マネージャー: これは、論理シミュレーション環境のオブジェクトを、他のコンポーネントで使用される必要な状態とアクションに変換するステート マシンです。 これは、シミュレーションのビルド、実行、破棄をトリガーするコンポーネントです。 また、内部依存関係とエラー モードも管理します。
スケジューラ: このコンポーネントでは、インフラストラクチャ リソースに構成要素を割り当て、そこでそれらを開始します。 ハードウェアとアクセスの要件、使用可能なリソース、リソースの制限が考慮されます。
環境マネージャー: このコンポーネントでは、基になるインフラストラクチャを監視し、コンテナー ホストがダウンした場合などの問題に対応します。
ネットワーク マネージャー: このコンポーネントでは、シミュレーション環境のネットワークとルーティングを管理します。 各環境は、分離されたネットワーク環境に存在し、対話機能のために受信接続を受け取る分離された構成要素がある必要があります。 このコンポーネントは、シミュレーション内の構成要素を解決するためにも使用されます (たとえば、内部 DNS を介して)。
アクセス マネージャー: このコンポーネントは、Microsoft Entra ID からシステムの残りの部分に認可と認証を反映します。
構成マネージャー: このコンポーネントは、インフラストラクチャとシミュレーション環境の状態の永続的なストレージ メカニズムとして機能します。
インフラストラクチャの抽象化: これは、汎用コマンドをコンテナーと VM の特定の Azure API コマンドに変換する抽象化レイヤーです。
ストレージ マネージャー: このコンポーネントでは、シミュレーション環境のストレージ (VM ルート デバイスやコンテナーにアタッチされたボリュームなど) のプロビジョニングとアタッチを管理します。
リソース モニター: このコンポーネントでは、インフラストラクチャ レベルのリソース使用状況を監視して時系列データベースに書き込みます。これは、ADP のコア監視にエクスポートできます。
ログ マネージャー: このコンポーネントでは、ユーザーによる検査のために構成要素からログを集計します。 また、ADP コア ログにログをエクスポートします。
オーケストレーション レイヤーは、このワークロードの例の主な焦点です。
シミュレーション インフラストラクチャ レイヤー
このレイヤーは、実行されているすべてのシミュレーション環境を表します。
シミュレーション環境: 定義ファイルとパラメーターによって定義された構成要素の組み合わせは、他のシミュレーション環境からネットワーク分離されて、ここに作成されます。
構成要素コントラクト: すべての構成要素で出力、エラー、状態をオーケストレーション レイヤーに送信する方法を定義する記述された標準。
構成要素パイプライン: この領域では、構成要素の作成と格納を管理します。
構成要素リポジトリ: これは、コンテナー レジストリや Azure イメージ ギャラリーなどの構成要素のイメージの格納および取得システムです。
構成要素ファクトリ: 継続的インテグレーションと継続的配置 (CI/CD) パイプライン。宣言型の構成言語 (Chef や Ansible など) で不変の検証可能なコンポーネント パッケージ (dpkg や apt など) を使用して、構成要素のイメージを作成します。
ストレージ レイヤー
このレイヤーでは、シミュレーションの結果を利用しやすく永続的に保存します。 これは主にモバイル アプリケーション開発プラットフォーム (MADP) の Data Lake ワークストリームの役割ですが、そのチームが出力を管理できる必要があります。
ストレージ インターフェイス: ユーザーがシミュレーション結果のストレージを操作できるインターフェイス。 これは、上記のストレージ マネージャー オーケストレーション コンポーネントと密接に連係して機能するか、それに取って代わられることがあります。
ストレージ: シミュレーション結果を保存するために使用されるストレージ メカニズム (Azure Blob Storage、Azure Disk Storage リソースなど)。
コンポーネント
Azure Virtual Machines を使用すると、物理的なハードウェアを購入して維持する手間を省き、仮想化がもたらす柔軟性を提供する、オンデマンドのスケーラブルなコンピューティング リソースが提供されます。
Azure Virtual Network は、Azure 内のプライベート ネットワークの基本的な構成要素です。 Azure Virtual Network では、Azure Virtual Machines などのさまざまな種類の Azure リソースが、他の Azure リソース、インターネット、オンプレミスのネットワークと安全に通信することができます。
Azure Container Instances には、VM を管理したり、より高度なサービスを採用したりせずに、Azure で最も高速かつ簡単にコンテナーを実行する方法が用意されています。
Azure Container Registry は、オープンソースの Docker Registry 2.0 が基になっている、マネージド型のプライベート Docker レジストリ サービスです。 既存のコンテナー開発およびデプロイ パイプラインで Azure コンテナー レジストリを使用することや、Azure Container Registry タスクを使用して Azure にコンテナー イメージをビルドすることができます。 必要に応じてビルドすることも､ソース コードのコミットや基本イメージの更新などのトリガーでビルドを完全に自動化することもできます。
Azure Pipelines は Azure DevOps Services の一部であり、自動化されたビルド、テスト、デプロイが実行されます。 Jenkins などのサードパーティ CI/CD ソリューションも使用できます。
Microsoft Entra ID は、ユーザー、サービス、アプリケーションを認証するクラウドベースの ID およびアクセス管理サービスです。
Azure Storage では、耐久性があり、高度にスケーラブルな高可用性クラウド ストレージ ソリューションが提供されます。 これには、オブジェクト、ファイル、ディスク、キュー、テーブルのストレージ機能が含まれます。
Azure Monitor では、さまざまなオンプレミスおよび Azure のソースから監視テレメトリを収集します。 このサービスでは、テレメトリを集計して、コストとパフォーマンスのために最適化されたログ データ ストアに格納します。
代替
このアーキテクチャでは、さまざまなツールとサービスをデプロイするために VM とコンテナーが使用されます。 別の方法として、Azure Kubernetes Service (AKS) を使用することもできます。 AKS では、サーバーレスの Kubernetes、統合された CI/CD エクスペリエンス、エンタープライズ レベルのセキュリティとガバナンスが提供されます。
このアーキテクチャでシミュレーション結果を保存するために使用されるストレージ メカニズムは、Azure Blob Storage または Azure Disk Storage に基づいています。 より大規模なワークロードのための別の方法として、データを格納および分析するための Azure の大規模なデータと分析のソリューションを確認できます。
また、Azure Monitor を使用して、インフラストラクチャのパフォーマンスを分析および最適化し、VM にログインせずにネットワークの問題を監視および診断することを検討してください。
シナリオの詳細
自動運転 (AD) を評価するには、機能のエンジニアは AD 機能を備えた車両の動作をシミュレートする必要があります。 次の運転シナリオの例について考えてみてください。
テスト車両は、3 レーンの高速道路の右側のレーンで時速 80 マイルで自動運転されています。 トラックが 600 フィート前方の同じレーンで同じ方向に時速 55 マイルで走行しています。 中央のレーンには近くに車両はありません。 道路標識を視認でき、太陽は車両の真上にあり、道路は乾いています。
このようなシナリオを使用した車両の動作の有限なシミュレーションは、シミュレーション実行 と呼ばれます。 上記のシナリオでは、シミュレートされた車両の想定される動作は、事故を引き起こしたり、交通規則に違反したりすることなく、トラックを楽に追い越すことです。 AD 機能のエンジニアは、機能の新しいバージョンごとにシミュレーションを実行することで、新しいバージョンで想定される動作が引き続き行われるかどうかをテストします。
シミュレーションを実行するために、AD 機能のエンジニアは通常、一連のソフトウェア アプリケーションを使用します。 これらには、Virtual Test Drive (VTD)、Time Partition Testing (TPT)、Avionics Development System 2G (ADS2)、Automotive Data and Time-Triggered Framework (ADTF) が含まれます。これらはすべて、Highway Pilot などの特定の自動運転機能をテストするための具体的な構成に従って相互に通信します。 オンプレミスやクラウドの物理マシンや仮想マシン (VM) にデプロイされたこの一連のソフトウェア ツールとその構成は、シミュレーション環境 と呼ばれます。
実行する各シミュレーションによって生成されるテスト結果の有効性を保証するには、初期状態に設定された新しいシミュレーション環境でシミュレーションが開始されるようにする必要があります。
すべての自動運転チームで、独自の構成を持つ個別の一連のアプリケーションがシミュレーション環境に必要となります。 多くのチームでは、複数の異なるシミュレーション環境も必要になります。 たとえば、LIDAR センサーを評価するには、非常に高い解像度のオブジェクト シミュレーションが必要となりますが、他のドライバー、道路標識、またはその他の機能は必要ありません。 各環境は固有ですが、使用されるアプリケーションにはかなりの重複があります。 たとえば、多くのチームは複数のシミュレーション環境で VTD を使用します。
再利用可能でカプセル化され、独立して評価されるユニットで構成されるシミュレーション環境でシミュレーションを実行できます。 これらのユニットは、Azure クラウドでのシミュレーション環境の自動作成およびオンデマンド作成に使用する "構成要素" として機能します。 これらのシミュレーション環境は、自動運転プラットフォーム (ADP) とも呼ばれています。
考えられるユース ケース
このソリューションは、自動車および輸送業界に最適です。 このワークロードの一般的な用途は次のとおりです。
運転テストの自動化。
自動車業界における制御システムのプロトタイプ作成、開発、統合、テスト、検証、検査。
視覚化のための車両データの記録。
自動車業界での複雑な運転シナリオのシミュレーション。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
可用性と回復性
計画メンテナンス イベントや計画外の停止からアプリケーションを保護するために役立つ可用性セットまたは可用性ゾーンに VM をデプロイすることを検討してください。
可用性セットは VM の論理グループで、これによって Azure は、冗長性と可用性を提供するためにアプリケーションが構築された方法を理解することができます。
可用性ゾーンは Azure リージョン内の一意の物理的な場所です。この場所の VM、アプリケーション、データは、データセンターで障害が発生しても保護されます。 各ゾーンは、1 つまたは複数のデータセンタで構成されています。 ゾーン内の VM とアプリケーションは、1 つのデータセンターで物理的な障害が発生しても引き続き使用できます。
スケーラビリティ
Azure VM は、手動で、または自動スケール機能を使用してスケーリングできます。
コンテナーのデプロイでは、Azure Container Instances と Azure Kubernetes Service も手動または自動でスケールアップまたはスケールアウトするように設計されています。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
他のアプリケーションの種類と同様に、シミュレーション環境は機密データを処理するように設計できます。 そのため、サインインして使用できるユーザーを制限し、ユーザーの ID またはロールに基づいてアクセスできるデータも制限する必要があります。 ID とアクセス制御には Microsoft Entra ID を使い、キーとシークレットの管理には Azure Key Vault を使います。
セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。
DevOps
新しいシミュレーション環境をデプロイする場合は、Azure DevOps や GitHub Actions などのソリューションを使用して、CI/CD プロセスを使用することをお勧めします。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、 コスト最適化の柱の概要に関する記事をご覧ください。
一般的に、コストを見積もるには、Azure 料金計算ツールを使用します。 また、このプロセスに従うことで、最初から VM の容量を適切に調整し、必要に応じて簡単にサイズ変更することで、コストを最適化することもできます。 その他の考慮事項については、Microsoft Azure Well-Architected Framework のコストに関するセクションに説明されています。
次の手順
製品ドキュメント:
Microsoft ラーニング パス:
関連リソース
Azure アーキテクチャ センターの概要に関する記事:
関連するアーキテクチャ: