Eclipse Dataspace Components (EDC) コネクタを AWS にデプロイする際、最初に直面する課題のひとつが、必要なインフラストラクチャのコストを予測・管理することです。明確なベンチマークがないと、ワークロードのサイジングや環境の設定、長期的な投資について十分な判断が難しくなります。

この 3 部構成のブログシリーズの 第 1 部では、データスペースアーキテクチャの基礎と、International Data Space Association（IDSA）の標準に基づく EDC について解説しました。第 2 部では、Amazon Web Services (AWS) 上への EDC コネクタの本番環境向けアーキテクチャパターンを探求し、運用上の優秀性、セキュリティ、信頼性の原則について議論しました。この最終回では、残りの 3 つの AWS Well-Architected Framework の柱である、パフォーマンス効率、コスト最適化、サステナビリティを取り上げます。

この記事では、EDC コネクタのデプロイにおいてどの AWS サービスがコストを左右するのか、ビジネスクリティカルなワークロードと非クリティカルなワークロードの月額コストをどのように見積もるか、そして最大 58% の支出削減につながる最適化戦略の適用方法について学びます。

データスペースデプロイにおけるコストドライバーの理解

データスペースとは、独立した組織間でセキュアかつ主権的なデータ共有を可能にする、セキュアで主権的なデータ環境です。このアーキテクチャでは、外部組織とコラボレーションしながら、データの完全な管理とデータ主権の原則の遵守を維持できます。インフラストラクチャのコストは大きく変動する可能性があります。主な要因は、パフォーマンスおよび信頼性の要件、ネットワークを横断するデータ量とデータ速度です。また、2 種類のインフラストラクチャを区別することも重要です。Dataspace Governance Authority (DSGA) は、管理機能、アイデンティティ機能、検出機能などのコンポーネントを一元的に確立します。参加者は、コネクタを含むその他のコンポーネントを自身でホストします。このブログ記事では、参加者側（データプロバイダー側およびデータコンシューマー側）の EDC コネクタデプロイに関連するコストのみに焦点を当てます。

架空の使用状況の前提条件

数値に入る前に、独自の見積もりのベースラインとして使用できる技術的および運用的前提条件を示します。

技術的前提条件

カテゴリ 前提条件 根拠
データ量 参加者あたり 5 GB 6 か月分の履歴データとバックアップを含む
ネットワークトラフィック 参加者あたり月間 20 GB 参加者間のデータ転送
API 呼び出し 参加者あたり月間 100,000 回 カタログクエリ、契約交渉、データ転送
OAuth トークン要求 参加者あたり月間 1,000 回 データプレーン操作のためのマシン間認証

表 1: EDC コネクタのコスト見積もり用技術的前提条件

運用的前提条件

  • 単一の AWS リージョン: Spain (eu-south-2)
  • 稼働時間: 24 時間365日
  • 成長率: ベースラインの見積もりでは考慮しない
  • ディザスタリカバリ: 自動バックアップのみ（クロスリージョンレプリケーションなし）

デプロイアーキテクチャとシナリオ

図 1 は、このシリーズの第 2 部で詳述した、AWS 上への本番環境向け EDC コネクタのデプロイに関するリファレンスアーキテクチャを示しています。

Amazon ECS、Amazon Aurora、Network Load Balancer およびサポートサービスを含む AWS サービスの本番環境向け EDC コネクタデプロイアーキテクチャ図

図 1: 本番環境向け EDC コネクタのデプロイ

この記事では、ワークロードの重要度に応じて 2 つのコストシナリオを検討します。

  • ビジネスクリティカルなワークロード: 重要なビジネス機能を支えるユースケースの高可用性、パフォーマンス、信頼性のために設計されたもの。
  • 非クリティカルなワークロード: 中断を許容できるユースケース、テスト環境、または短時間の停止が許容される本番ワークロードのために設計されたもの。

どちらのシナリオも、このシリーズの第 2 部で説明したアーキテクチャパターンに従いますが、主な違いはコンピュートおよびデータベースリソースのサイズです。

コスト見積もり: ビジネスクリティカルなワークロード

注: これらの見積もりは上記の前提条件を使用し、各サービスの相対的なコスト寄与率を示しています。実際のコストは、特定の使用パターン、データ量、地域の料金によって異なる場合があります。この記事では、どのコンポーネントが最も高いコストドライバーであり、したがって最適化の可能性が最も高いかを強調します。

AWS サービス 構成 月額コスト (USD)
Amazon Aurora PostgreSQL-Compatible Edition db.r6g.large (2 vCPU, 16 GB)、20 GB ストレージ + 10 GB バックアップ 276.00
Amazon Elastic Container Service (Amazon ECS) with AWS Fargate 2 vCPU、4 GB RAM、常時稼働 83.00
Network Load Balancer 処理データ 20 GB 20.00
AWS Secrets Manager シークレット 10 個 4.00
Amazon Cognito 1K マシン間 (M2M) トークン要求 2.25
Amazon Elastic Container Registry (Amazon ECR) 2 GB ストレージ、10 GB 転送 1.00
Amazon API Gateway 100K REST API 呼び出し 0.40
Amazon Simple Storage Service (Amazon S3) 5 GB スタンダード階層 0.10
合計 387.00

表 2: ビジネスクリティカルな EDC コネクタデプロイの推定月額コスト

これらの見積もりは、予算の使われ方と、最も影響の大きい最適化ポイントの特定に役立ちます。ビジネスクリティカルなシナリオでは、主なコストドライバーは Amazon Aurora PostgreSQL です。db.r6g.large 構成は、高メモリと高パフォーマンスを必要とする、信頼性と速度が求められる定常ワークロード向けに選択されています。Amazon ECS with AWS Fargate は、環境の可用性を維持するためにコンテナを継続的に実行するため、2 番目に大きなコスト寄与要因です。Network Load Balancer が 3 番目に顕著なコストコンポーネントであり、残りのサービスは総コストのごく一部を占めるに過ぎません。

コスト見積もり: 非クリティカルなワークロード

開発、テスト、または実験環境を実行する場合、Amazon EC2 Spot キャパシティの使用とリサイズにより、最大 58% のコスト削減が可能です。

AWS サービス 構成 月額コスト (USD)
Amazon Aurora PostgreSQL-Compatible db.t4g.medium (2 vCPU, 4 GB)、20 GB ストレージ + 10 GB バックアップ 110.00
Amazon ECS with AWS Fargate Spot 2 vCPU、4 GB RAM、常時稼働 26.00
Network Load Balancer 処理データ 20 GB 20.00
AWS Secrets Manager シークレット 10 個 4.00
Amazon Cognito 1K M2M トークン要求 2.25
Amazon ECR 2 GB ストレージ、10 GB 転送 1.00
Amazon API Gateway 100K REST API 呼び出し 0.40
Amazon S3 5 GB スタンダード階層 0.10
合計 164.00

表 3: 非クリティカルな EDC コネクタデプロイの推定月額コスト

これらの数値は、非クリティカルな構成が同じデータスループットと API 容量を維持しながら、コストを大幅に削減できることを示しています。コスト削減は、より小型で柔軟なリソースの使用によって実現されます。Amazon Aurora PostgreSQL は依然として主なコストドライバーですが、小型のインスタンスタイプ (db.t4g.medium) を使用することでコストが大幅に削減されます。コンピュート面では、Amazon ECS with AWS Fargate Spot キャパシティを使用することで、ビジネスクリティカルなセットアップと比較してコストをほぼ 70% 削減できます。全体として、この構成はデータスループット、API 呼び出し、ストレージに関する前提条件を同一に保ちながら、月額コストを約 58% 削減します。

コスト最適化に関する主なポイント

この比較は、どちらのシナリオでも主なコスト寄与要因がデータベース、コンピュート、ロードバランシングリソースであり、これらは使用量ベースの料金ではなく、ベースラインのインフラストラクチャコストであることを示しています。Amazon S3、API Gateway、データ転送料金などのサービスは、これらのボリュームでは全体のコストへの寄与はわずかです。このコスト構造は、アーキテクチャが使用量の増加に効率的にスケールすることを示しています。より多くのユースケースをオンボードし、データ量とデータ速度を増加させると、既存のインフラストラクチャ投資から比例したコスト増加なしにより多くの価値を得られます。

Well-Architected の柱: パフォーマンス効率、コスト最適化、サステナビリティ

このシリーズの第 2 部では、AWS Well-Architected Framework の運用上の優秀性、セキュリティ、信頼性の柱に沿った EDC のベストプラクティスを扱いました。このセクションでは、EDC デプロイに適用される残りの 3 つの柱を扱います。

パフォーマンス効率

コンピュートリソースの適正化: Amazon ECS タスク定義を実際のワークロード要件に合わせます。小さめの構成から始め、最初から過剰プロビジョニングするのではなく、観測されたメトリクスに基づいてスケールアップします。Amazon CloudWatch Container Insights は、適切なサイジング判断に必要な可視性を提供します。

Amazon Aurora の柔軟性の活用: 需要パターンが変動するワークロードの場合、アプリケーションのニーズに基づいてデータベース容量を自動的にスケーリングする Amazon Aurora Serverless v2 を検討してください。これにより、ピーク時の容量をプロビジョニングする必要がなくなり、高需要期のパフォーマンスを維持できます。

データ転送パターンの最適化: データプレーン操作を設計して、不要なデータ移動を最小限に抑えます。地理的に離れた場所への大容量転送には Amazon S3 Transfer Acceleration を使用し、必要に応じてデータ圧縮を検討して、転送時間とコストの両方を削減します。

コスト最適化

耐障害性のあるワークロードのコンピュートコスト削減: AWS Fargate Spot を使用すると、中断を許容できるワークロードで最大 70% の節約が可能です。非クリティカルな環境、バッチ処理、開発ワークロードは理想的な候補です。Spot 中断を効果的に管理するために、グレースフルシャットダウンの処理を実装します。

時間の経過に伴うストレージコストの削減: Amazon S3 Lifecycle ポリシーを設定して、アクセス頻度の低いデータを S3 Intelligent-Tiering や S3 Glacier Instant Retrieval などの低コストのストレージクラスに自動的に移行します。EDC コネクタのデプロイでは、履歴転送ログやアーカイブされたアセットは階層化ストレージの適切な候補です。

予期しないコスト増加の監視: AWS Cost Explorer を使用し、AWS Budgets にアラートを設定して、予期しないコスト増加の検出を支援します。EDC 関連の AWS リソースに一貫してタグを付けることで、コストを正確に配分し、最適化の機会を特定できます。

予測可能なワークロードの低料金の固定: 予測可能で安定した使用パターンのビジネスクリティカルなコネクタの場合、Amazon Aurora および AWS Fargate 向けの Savings Plans は、オンデマンド料金と比較して大幅な割引を提供できます。

サステナビリティ

リソース利用率の最適化: プロビジョニングされたリソースの利用率を高めることは、無駄を減らすことを意味します。自動スケーリングポリシーを使用して容量を需要に合わせ、可能であれば営業時間外に非本番環境をシャットダウンします。

効率的なインスタンスタイプの選択: AWS Graviton ベースのインスタンス（この例で使用されている r6g および t4g ファミリーなど）は、同等の x86 インスタンスと比較して優れた価格性能比とエネルギー効率を提供します。AWS Graviton プロセッサは、エネルギー使用量あたりのパフォーマンスを向上させます。

データ移動の最小化: 各データ転送はエネルギーを消費します。データスペースの統合を設計して、冗長な転送を避け、Federated Catalog を使用してピアのカタログデータをローカルにキャッシュし、可能であれば操作をバッチ処理して、ネットワークラウンドトリップの総数を削減します。

まとめ

AWS インフラストラクチャを実際のコンピュートおよびデータベース容量のニーズに合わせて適正化することで、データスペース参加者は、データスペースを価値あるものにするデータセキュリティと主権の側面を損なうことなく、大幅なコスト削減を実現できます。ビジネスクリティカルなワークロードと非クリティカルなワークロードの構成の比較は、Amazon Aurora、AWS Fargate Spot、Amazon S3 などの AWS サービスを効果的に組み合わせて、データ主権、パフォーマンス、コスト効率のバランスを取る方法を示しています。

データスペースが業界や地域を越えて採用が進むにつれ、ネットワーク参加を計画する際にこれらのコストダイナミクスを理解することがますます重要になります。この記事シリーズのパターンと見積もりは、AWS での組織横断的なデータ戦略とデータスペースの取り組みを計画するための基盤を提供します。

開始するには、ワークロードの重要度を評価して、ビジネスクリティカルな構成と非クリティカルな構成のどちらがニーズに適合するかを判断します。次に、AWS Pricing Calculator を使用して、特定のデータ量、リージョン、使用パターンに対するコストを見積もります。エンドツーエンドのリファレンス実装については、Infrastructure-as-Code とカスタム EDC 拡張機能、AI ツール統合を組み合わせた Dataspace Connector on AWS プロジェクトをご覧ください。

参考資料

著者について