Amazon Web Services ブログ

Continental Automotive Edge (CAEdge) を用いたソフトウェアディファインドビークルのためのプラットフォーム開発

このブログは、Developing a Platform for Software-defined Vehicles with Continental Automotive Edge (CAEdge) を翻訳したのものです。

この投稿はコンチネンタル・オートモーティブの Principal Expert SW Architecture の Martin Stamm、AWS プロフェッショナルサービスのシニアコンサルタントである Andreas Falkenberg、AWS プロフェッショナルサービスのエンゲージメントマネージャである Daniel Krumpholz、AWS のシニアエンゲージメントマネジャである David Crescence と AWS プロフェッショナルサービスのプリンシパルコンサルタントである Junjie Tang による共著です。

よりアジャイルで効率的かつ革新的になるために、自動車メーカーはデジタルトランスフォーメーションに乗り出しています。このトランスフォーメーションの一部として、コンチネンタル は Continental Automotive Edge (CAEdge) を開発しました。CAEdge は、車両をクラウドに接続する、ハードウェアとソフトウェアによるモジュラー型のマルチテナントフレームワークです。コンチネンタルはこのフレームワークを開発しスケールさせるためにアマゾン ウェブ サービス (AWS) と協業しました。

この AWS re:Invent のセッションでは、CAEdge を使って構築した新しく革新的な自動車のアークテクチャとソフトウェアについて、コンチネンタルと AWS がデモを行いました。これにより、未来の自動車製造業者や OEM (Original equipment manufacturers) とそのパートナーは、ソフトウェア中心の自動車アーキテクチャのためのマルチテナントの開発環境を手にすることができます。そして、ソフトウェアやセンサー、ビッグデータに関わるソリューションを、これまでの数分の一の期間で開発できるようになります。結果として、自動車用のソフトウェア開発やテストはより効率的で安全なものとなり、自動車に直接ロールアウトすることができるようになります。自動車製造業者の一連の開発を通じて、既にこのフレームワークの検証が行われています。

自動車産業における主要な課題についての説明

コンチネンタルと OEM、 そして主要な Tier1 企業は、市場で最前線を走りつつ、キャパシティや拡張性のニーズを把握することなく、新しい技術要件に素早く適応する必要があります。開発者はいくつかの課題に直面していますが、特に重大なのが大量のデータを処理することです。例えば、自動運転 (AV) や先進運転支援システム (ADAS) では、1 台の試験車両から 1 日に 20 – 100 TB のデータが生成されます。このようなデータを取り扱い、分散した拠点で利用可能にするために必要な時間が原因で、開発のサイクルは大きく遅延してしまう可能性があります。シミュレーションや検証のテストケースが大量にあるため、開発者も遅延を経験することになります。オンプレミス環境では、これにより極めて大きな費用が生じ、必要なキャパシティを提供するための拡張性の課題が発生することになります。

ソフトウェア中心の組織になるために必要な変革のペースの速さは、次のような新たな課題と機会を生み出しています。

  • 現在の車両の電子アーキテクチャは、分散型で費用がかかり開発が複雑であるため、保守や拡張が困難です。
  • 自動車とクラウドが融合するには、ソフトウェア (SW) によって定義された新しいアーキテクチャと、統合、運用に関する能力が必要です。
  • デジタルライフサイクル管理により、新たなビジネスモデルや市場投入の戦略、パートナーシップが可能になります。

大量のデータを配布して分散処理を実行できる環境に加えて、最先端のセキュリティ技術が必要です。転送時と保存時のデータの暗号化、データ保存場所に関する法律、開発者による安全なアクセスはセキュリティに関する共通の課題であり、 CAEdge の技術を使うことにより対応することができます。

このブログでは、CAEdge の基礎となる、安全なマルチテナントの AWS 環境を構築する方法を説明します。 高度に自動化されたプロセスを通じて OEM、パートナー、サプライヤーの迅速なオンボーディングを可能にするベースとなるインフラストラクチャをコンチネンタルが構築するために、AWS がどのように役立っているかを説明します。ソフトウェア中心の自動車のアーキテクチャのためのブートストラップ開発環境を使えば、数日数週間ではなく、数時間で開発を始めることができます。

CAEdge フレームワークの概要

以下の図が CAEdge フレームワークの概要です。

図 1 – CAEdge フレームワークのアーキテクチャ図

このフレームワークは以下のモジュール化されたビルディングブロックから構成されています。

  • 拡張性の高いコンピュートプラットフォーム: 高パフォーマンスな自動車用ソフトウェアスタックを備えた組込コンピュータと AWS クラウドへの接続
  • クラウド: 開発者とエンドユーザーのためのクラウドサービス
  • DevOps ワークベンチ: ソフトウェアライフサイクル全体をカバーする、開発とメンテナンスのためのツールチェーン

これらのフレームワークのビルディングブロックはAPIにより明確に定義されており、異なるミドルウェアや CI/CD パイプラインなどの、多様なユースケースと容易に統合することができます。

CAEdge マルチテナントフレームワークの概要

コンチネンタルにおける核となるアーキテクチャと、自動車開発のフレームワークに関する用語の一部を以下に記載します。

  • 隔離された AWS Organization としての CAEdge フレームワーク: コンチネンタルの CAEdge フレームワークは、専用の AWS Organization 内で動作します。この AWS Organization にホストされているのは CAEdge に関連するワークロードのみです。これにより、CAEdge と関係のないワークロードから確実に隔離されます。CAEdge フレームワークでは、中央管理的な複数のセキュリティ、アクセス管理、オーケストレーションに関するサービスをユーザーに提供しています。
  • 隔離されたテナント: このフレームワークはテナントを完全に認識します。テナントは独立したエンティティで、OEM や OEM の部門、パートナー、サプライヤーなどを表します。このシステムの重要な機能は、テナントが完全に分離されることを保証することです。テナントの分離を確実にするため、多層防御のセキュリティアプローチを採用しています。
  • テナントが所有するリソースとサービス: 各テナントは専用のリソースとサービスを保有しており、全てのテナントユーザーとサービスがそれらを消費・利用することが可能です。テナントが所有するリソースやサービスは、これらに限定されるわけではありませんが、次のようなものがあります。
    • 専有されているテナント固有のデータレイク
    • テナント固有のロギング、モニタリング、運用
    • テナント固有の UI
  • プロジェクト: 各テナントは任意の数のプロジェクトをホストすることが可能で、各プロジェクトには 1 から N 名のユーザーをアサインすることができます。プロジェクトは、単一のプロダクトやサービスの開発を目的としたハイレベルの構造で、例えば、新たな「ドアロック」システム用のソフトウェアといったものです。プロジェクトという用語は広いスコープで使用されており、あらゆるものがプロジェクトに分類されることになります。
  • ワークベンチ: プロジェクトは 1 から N 個の明確に定義されたワークベンチから構成されます。ワークベンチは、ある特定の「ワークベンチタイプ」を持った、完全に設定された開発環境を表します。例えば「シミュレーション」というタイプのワークベンチでは、走行データに基づくシミュレーションジョブのための設定とジョブの実行を行うことができます。各ワークベンチは、AWS アカウントセットと呼ばれる明確に定義された数の AWS アカウントを通じて実装されています。
    • AWS アカウントセットには、ツールチェーン用アカウント、開発用アカウント、QA 用アカウントと本番用アカウントが、必ず少なくとも 1 つずつ含まれています。全ての AWS アカウントは IAM リソース、セキュリティサービス、および必要に応じてワークベンチ固有のブループリントを用いてベースライン化されており、エンドユーザーは素早く開発を始めることができます。
次の図はハイレベルのアーキテクチャを表しています。

図 2 – ハイレベルのアーキテクチャ図

CAEdge フレームワークでは、テナントレベルでのデータレイクを作成するために、AWS Lake Formation と Glue を用いたデータメッシュのアーキテクチャを使用しています。シミュレーション用のワークベンチを設計するために、自動運転のためのデータレイクに関するリファレンスアーキテクチャを使用しています。

実装の詳細

核となるアーキテクチャと用語を定義したので、次は前出の図に記載のアーキテクチャの実装の詳細を見ていくことにしましょう。

隔離されたテナント: 高度な分離の実現

マルチテナント環境を実現するうえで、多層化してセキュリティを強化するアプローチに従うことにしました。

  • AWS アカウントレベルでのテナントの分離: AWS アカウントレベルでは、可能な限り個別の AWS アカウントを使用しています。1 つの AWS アカウントを 2 つ以上のテナントに割り当てることはありません。1 つの AWS アカウントの機能的なスコープはできる限り小さく保ちます。これにより AWS アカウントの合計数は増えますが、セキュリティ違反やインシデント発生時の影響範囲を劇的に小さくすることができます。例を挙げると
    • 開発・QA・本番の各段階で、ワークベンチはそれぞれ個別の AWS アカウントです。1 つの AWS アカウントが複数のステージを同時に兼ねることはありません。
    • CAEdge の各テナントが所有するデータレイクは、複数の AWS アカウントから構成されます。データレイクは時間が経つとともにアップデートをする必要があります。副作用を避け、十分にテストした上でデータレイクのインフラをアップデートするために、各テナントは開発用・QA用・本番用のデータレイクを保有しています。
  • 適切に定義された Organization Unit (OU) 構造と Service Control Policies (SCP)を用いたテナントの分離: 各テナントには専用の OU 構造が割り当てられており、その OU は複数のサブ OU から構成されています。これにより、SCP レベルでテナント固有のセキュリティ強化や、専有されたテナントが特定のセキュリティ要件を満たす必要がある場合のカスタムのセキュリティ強化が可能となります。SCP は、個々の AWS アカウントのユーザーに最大限の自由を与えつつ、CAEdge の完全性を保護し、特定の要件に対してコンプライアンスと安全性を満たすよう設計されています。
  • AWS アカウントのメタデータ層と IAM のアサインの自動化を用いたテナントの分離: CAEdge フレームワークでは一元化された Amazon DynamoDB データベースを使用して、AWS アカウントをテナントにマップし、AWS アカウントのコンテクストに関わるその他のメタデータを格納しています。このメタデータには、アカウントオーナー、アカウントタイプ、コスト関連情報が含まれています。このデータベースを使うことで、特定のテナントやプロジェクト、ワークベンチに基づいて AWS アカウントを検索することが可能です。さらに、これは完全に自動化された許可と AWS アカウントのアクセス管理機能の土台を成しており、全てのテナントやプロジェクト、ワークベンチの境界を定義しています。
  • AWS セキュリティサービスを用いた、テナント分離におけるセキュリティコントロール: AWS GuardDuty や AWS Config、AWS Inspector、AWS SecurityHub などの標準的な AWS のセキュリティサービスに加えて、IAM Access Analyzer を DynamoDB で作成したアカウントメタデータストアと組み合わせて使用しています。これを用いることで、AWS Organization 外にまたがる、またはクロステナントを含む可能性のある、クロスアカウントアクセス許可の作成を検出することが可能です。

テナントが所有するリソースとサービス、プロジェクト、ワークベンチの自動生成と管理

CAEdge は「すべてを API として扱うアプローチ (Everything-as-an-API Approach)」に従っており、インターネット上の完全にオープンなプラットフォームとして設計されています。全ての重要な機能は、安全でパブリックな API を通じて公開されます。これには、プロジェクトやワークベンチ、AWS アカウントの作成が含まれます。AWS アカウントには、権限付与されたユーザーによるセルフサービスでのアクセス管理と、その後の長期的な管理に関連する更新が含まれます。これは、非常に高度な自動化によってのみ実現できます。

この高度な自動化を実現するために、以下のサービスを設計します。

  • AWS Control Tower: アカウント作成と OU のアサインのための AWS のマネージドサービスです。
  • AWS Deployment Framework (AWS ADF): 1 つの AWS Organization 内で、複数の AWS アカウントや複数リージョンにまたがるリソースの管理とデプロイを行うための、拡張性と柔軟性の高いフレームワークです。ADF を使うことで、リソースを必要とする全てのアカウントのベースライン化を行うことができます。これには、あらゆるセキュリティサービスやデフォルトの IAM ロール、VPC や DNS といったネットワーク関連のリソース、そして AWS アカウントのタイプに固有のその他リソースが含まれています。
  • AWS Single Sign-On (AWS SSO): AWS アカウントへのアクセスをコントロールするための、一元化された IAM に関するソリューションです。 AWS SSO のアサインは完全に自動化されており、カスタム化された Dispatch アプリケーションと AWS SSO エンタープライズソリューションの拡張版に基づいています。
  • AWS DynamoDB: 完全にマネージドの NoSQL データベースで、テナントやプロジェクト、AWS アカウントに関するデータを格納するために使用します。オーナーシップやコスト管理、アクセス管理に関する情報が含まれます。
  • Dispatch CAEdge Web Application: 完全にサーバレスなウェブアプリケーションで、API コールを用いてエンドユーザーに機能を公開しています。このアプリケーションは認証と承認を扱い、上で述べたサービス全てをオーケストレーションするために、AWS Lambda 関数の形でビジネスロジックを提供しています。

次の図は、プラットフォームレベルでの自動化のメカニズムの、ハイレベルな概要を表しています。

図 3 自動化のメカニズムのハイレベルな概要

このソリューションを導入することで、コンチネンタルでは、OEM やサプライヤー、その他のパートナーが、テナント内に開発者用のワークベンチを数分以内で立ち上げることが可能になりました。これによって、セルフサービスアプローチで、セットアップにかかる時間を数週間から数分に短縮できるようになりました。

まとめ

この投稿では、コンチネンタルがどのようにして安全かつマルチテナントなプラットフォームを構築したかを説明しました。このプラットフォームは、ソフトウェア中心の自動車ワークロードにとって拡張性の高い基盤となります。ソフトウェア中心の組織への変化で課題に直面している他の組織は、このソリューションを用いることでオンボーディングのプロセスを簡素化することができ、開発者は数ヶ月ではなく数時間で開発を始められるようになります。

このブログはソリューションアーキテクトの畔栁竜生、國政丈力、渡邊翼が翻訳を担当しました。