AWS Architecture Blog

この3部構成のブログシリーズでは、Eclipse Dataspace Components (EDC) を AWS に実装する方法を、基礎概念から本番環境へのデプロイまでガイドします。第1部では、IDSA 標準、Dataspace Protocol (DSP)、および EDC のコアアーキテクチャを用いて理論的基盤を確立します。第2部では、Amazon Elastic Container Service (Amazon ECS)、Amazon Aurora、Amazon API Gateway などのサービスを使用した本番環境向けの AWS デプロイパターンを提供します。第3部では、コスト最適化戦略と、AWS 上で効率的かつスケーラブルなデータスペースインフラストラクチャを運用するための実践的なガイダンスで締めくくります。

International Data Spaces Association (IDSA) は、データスペース向けの標準を確立・推進することに注力する非営利団体です。データスペースは「異なる事業体間での相互運用可能なデータセット共有を促進する一連の技術サービス」と定義されています。技術的なレベルでは、データスペースには参加者（データコンシューマーとデータプロバイダー）が存在します。中央には Dataspace Governance Authority (DSGA) があります。DSGA はデータスペースを管理し、ルールとポリシーを施行し、参加者にメンバーシップクレデンシャルを発行します。

IDSA のルールと仕様は Dataspace Protocol (DSP) に実装されています。DSP は Eclipse Specification プロジェクトとなり、Dataspace Protocol GitHub リポジトリで確認できます。標準化は開発中であり、現在 ISO/IEC DIS 20151 として承認段階にあります。Eclipse Dataspace Components (EDC) は、IDSA の要件に従ってデータスペースを実装するための技術コンポーネントを提供します。

これらのコンポーネントには、フェデレーテッドカタログ (FC)、コネクタ、およびアイデンティティハブが含まれます。FC には、データスペース内の複数の参加者から収集されたカタログの集約リポジトリが含まれます。これらは、参加者のデータアセットを定期的にクロールしてローカルキャッシュに保存することで、オンデマンドで各参加者に個別にクエリする必要を排除します。コネクタは参加者間でデータを共有できるようにするソフトウェアであり、アイデンティティハブはデータスペース内の参加者のクレデンシャルを管理します。Amazon Web Services (AWS) は、EDC コネクタのようなデータスペースコンポーネントのデプロイと運用をサポートする包括的なクラウドインフラストラクチャを提供します。AWS は、スケーラブルなコンピューティング、ストレージ、ネットワーキングサービスを提供し、IDSA 標準および ISO/IEC DIS 20151 仕様に準拠したセキュアでコンプライアントかつ相互運用可能なデータスペースの構築を支援します。

データスペース内で分散的にアイデンティティを検証するために、Decentralized Claims Protocol (DCP) が使用されます。DCP は、ネットワーク参加者間の信頼を確立するための DSP の上に位置するオーバーレイを表します。発行者が検証者にアイデンティティを証明する必要がある場合、まず Decentralized Identifier (DID) を生成します。これはアイデンティティに関する情報を含みます。発行者は Verifiable Credential (VC) をアイデンティティハブに保存します。Verifiable Credential は証明書に似ています。証明書局が公開鍵を検証するのに対し、クレデンシャル発行者は特定の属性を持つ DID を検証します。検証者は発行者の DID を検索し、DID ドキュメントから得られた情報で VC を検証します。

High-level diagram showing how DCP establishes trust between an issuer and verifier using DIDs and Verifiable Credentials

Figure 1: High-level diagram of the Decentralized Claims Protocol (DCP)

Simplified overview showing how a verifier resolves a DID document to verify credentials

Figure 2: Simplified overview of DID document processing

EDC の最後の要素は、メンバーシップ、アクセス、契約、使用ポリシーを含むさまざまな種類のポリシーです。

The role of the connector

EDC コネクタは、コントロールプレーンとデータプレーンの2つの部分に分かれています。コントロールプレーンは契約交渉を処理し、データ転送を開始するためにデータプレーンにメッセージを送信します。データプレーンは、異なる法的主体間でプロバイダーの EDC コネクタからコンシューマーの EDC コネクタへデータを転送する責任を負います。

Diagram showing the EDC connector architecture with separate control plane and data plane

Figure 3: Overview of the connector control and data plane

Structure of the EDC connector open-source project

EDC プロジェクトの一部である Connector repository は、コネクタのコントロールプレーンとデータプレーンがどのように実装されるかを定義します。リポジトリの構造について概要を説明します：

  • /spi – Service Provider Interface (SPI) は、EDC コネクタ内のモジュールがどのように通信するかを定義するアーキテクチャの基盤です。すべてのコンポーネントが実装しなければならない基本的なインターフェースと契約を含み、標準化された統合パターンを確立します。このレイヤーはまた、開発者がコアとカスタムコンポーネント間の関心の分離を維持しつつ、EDC コネクタの機能を拡張するための設計図としても機能します。
  • /core – Core モジュールは、コア SPI の実装を表します。コネクタの必須操作の実際の動作コードを収容し、主要サービスのデフォルト実装とデータ共有のビジネスロジックを含みます。
  • /extensions – Extensions レイヤーは、AWS などの主要クラウドプロバイダーへの接続を含む実際の統合を通じて、コネクタのモジュラーなプラグインアーキテクチャを示します。これらの拡張機能は、参照実装としても、一般的なエンタープライズ統合シナリオ向けの即戦力コンポーネントとしても機能します。

SPI は契約を定義し、Core は基本を実装し、Extensions は専門的な機能を追加します。これらの3つのレイヤーが連携して、柔軟で拡張可能なデータスペースコネクタシステムを作成します。「vanilla」な Eclipse EDC コネクタには、AWS extensions がデフォルトでバンドルされていません。Amazon S3、AWS Secrets Manager、または Amazon DynamoDB との統合など、AWS サービス固有の機能を追加するには、対応する AWS 拡張機能をカスタムの EDC コントロールプレーンおよびデータプレーンのビルドに含める必要があります。

High-level EDC customization guide

ネイティブな AWS サービス統合のために EDC コネクタをカスタマイズすると、ストレージ、セキュリティ、スケーラビリティに AWS マネージドサービスを利用できる目的に特化したソリューションを作成できます。以下の手順は、コネクタが Amazon S3（Asset Administration Shell "Submodel Server" として使用されるデータストレージなど）や AWS Secrets Manager（クレデンシャル管理用）などのサービスとネイティブに統合し、自己管理コンポーネントの運用に依存しないようにするのに役立ちます。

EDC は Gradle 上に構築されたモジュラーでプラグインベースのアーキテクチャを使用します。Vanilla コネクタにはコア機能のみが同梱されています。特定のクラウドサービスや永続化バックエンドと統合するには、EDC のコアモジュールと必要な拡張機能を組み合わせたカスタムビルドを組み立てます。カスタマイズは、バージョンカタログ、ランチャーモジュール、およびプロジェクト設定ファイルの3つの概念を中心に展開されます。

Step 1: Version catalog

バージョンカタログ（gradle/libs.versions.toml）は、すべての依存関係とそのバージョンの集中レジストリです。ここでは、コネクタが使用する必要がある EDC モジュール、クラウドプロバイダーの拡張機能、サードパーティライブラリを宣言します。EDC は AWS 拡張機能を org.eclipse.edc.aws Maven グループで公開しています。これらを、互換性のあるバージョン番号でコア EDC アーティファクト（org.eclipse.edc）と並べて参照します。この単一のファイルにより、プロジェクト内のすべてのモジュールが一貫した依存関係バージョンを使用することが保証されます。

Step 2: Launcher modules

ランチャーモジュールは、実際にデプロイ可能なユニットです。コントロールプレーン用とデータプレーン用がそれぞれ1つずつあります。各ランチャーは小さな Gradle サブプロジェクトであり、その build.gradle.kts にはランタイムでバンドルする拡張機能がリストされています。典型的なコントロールプレーンのランチャーには、コアコントロールプレーンモジュール、メタデータ永続化拡張機能（PostgreSQL や DynamoDB など）、ボールト拡張機能（HashiCorp Vault や AWS Secrets Manager など）、およびターゲットストレージシステム用のプロビジョニング拡張機能が含まれる場合があります。データプレーンのランチャーも、データプレーン固有のモジュールで同じパターンに従います。どちらのランチャーも通常、Gradle プラグインを使用して単一の実行可能 JAR を生成します。実際に使用するもののみを含めることで、コネクタを軽量に保ち、独自の要件に合わせることができます。

Step 3: Project settings

プロジェクト設定ファイル（settings.gradle.kts）は、すべてのモジュールを Gradle に登録します。ランチャーのサブプロジェクトと、ローカルで開発する可能性のあるカスタム拡張機能です。独自の拡張機能（例: DynamoDB バックエンドのアセットストア）を作成する場合、それを extensions/ ディレクトリに配置し、ここに登録してランチャーがプロジェクト依存関係として参照できるようにします。

結果として得られるプロジェクト構造は、通常次のようになります：

my-connector/
├── control-plane/
│   └── build.gradle.kts       # Control plane launcher
├── data-plane/
│   └── build.gradle.kts       # Data plane launcher
├── extensions/                # Optional: Custom extension code
├── gradle/libs.versions.toml  # All dependency versions
├── build.gradle.kts           # Root build config
└── settings.gradle.kts        # Subproject registrations

AWS 上での EDC カスタマイズのオープンソース参照実装は、Dataspace Connector on AWS プロジェクトの一部として提供されています。この投稿では、最新のデータスペースアーキテクチャを使用したセキュアな組織間データ共有の基礎について学びました。ISO/IEC DIS 20151 データスペース標準化に含まれる2つのプロトコル（DSP と DCP）をカバーし、データスペース参加者に必要な主要ソフトウェアである EDC コネクタと、そのカスタマイズ方法について説明しました。

第2部では、AWS 上での EDC コネクタの本番環境向けデプロイパターンを探求し、データスペースインフラストラクチャのセキュリティ、信頼性、運用効率をサポートするアーキテクチャのベストプラクティスを検証します。開始するには、Dataspace Connector on AWS プロジェクトを探索し、サーバーレスで低コストなメタデータ永続化のために Amazon DynamoDB をサポートする Gradle ビルド設定の構成を確認してください。

References

About the authors