グローバルな小売企業が、AWS上に新しいエンタープライズ分析基盤を構築しています。同社の事業構造と要件は以下の通りです。 【事業構造】 - 本社分析チーム：us-east-1の専用AWSアカウント（アカウントHQ）で全社データを横断分析 - 北米部門：アカウントNA（us-east-1）、1日3TBのトランザクションデータを生成 - EMEA部門：アカウントEU（eu-west-1）、1日2TBのトランザクションデータを生成 - APAC部門：アカウントAP（ap-northeast-1）、1日2TBのトランザクションデータを生成 【分析要件】 - 本社の中央分析チームは、全3リージョンのデータを単一のSQLクエリでJOINして分析できること（例：全リージョンの売上をリージョン別に集計する複雑なクエリ） - 各部門の分析チームは、自部門のデータのみアクセスできること（他部門の生データへのアクセス不可） - トランザクション発生から1時間以内にデータがクエリ可能な状態になること 【コスト・運用要件】 - ストレージコストの重複を避けること（同一データを複数箇所に物理的に保持しない） - 計算（コンピュート）コストを各チーム（部門別・本社別）のAWSアカウントに帰属できること - 3リージョンが同時稼働するピーク時の分析クエリ負荷に対応できること - ソリューションの運用管理の複雑さを最小化すること 最もこれらの要件を満たすアーキテクチャはどれですか？
RA3ノードとRedshift Data Sharingがすべての要件を同時に満たします。 ①ストレージ重複なし：データはプロデューサーのRA3マネージドストレージ（内部はS3ベース）にのみ物理的に存在し、コンシューマークラスターはデータをコピーせずリモート参照するため重複が発生しません。 ②クロスアカウント・クロスリージョン対応：RA3ノードはアカウントをまたいだリージョン間のデータ共有をネイティブサポートします。 ③コスト帰属：プロデューサーはストレージコスト、コンシューマーは計算コストをそれぞれ独立したAWSアカウントで負担するため、自然な形でコスト帰属が実現します。 ④単一SQL：コンシューマークラスターから複数の共有データベースへのクロスデータベースJOINを1つのSQLで実行可能です。 ⑤アクセス制御：RedshiftネイティブのGRANT/REVOKE権限管理で部門別アクセスを制御でき、Lake Formationなどの追加サービスが不要です。 選択肢Bの全部門のデータをAmazon Kinesis Data Firehose経由でアカウントHQの中央S3バケットに集約し、単一の大型Redshiftクラスターにコピーロードする方法は、データを物理的に複製するため「ストレージ重複なし」要件に違反します。全部門の計算負荷が1つのクラスターに集中するため部門別コスト帰属が困難であり、単一障害点のリスクも生じます。 選択肢Cの各部門のデータをそれぞれのAWSアカウント内のS3バケットに保存し、アカウントHQでAmazon Athenaを使用してクロスアカウントクエリを実行する方法は、大規模な多テーブルJOINや複雑な集計クエリのパフォーマンスが劣る場合があります。 選択肢Dの各部門のAWSアカウントにAmazon Redshift DC2クラスターをデプロイし、AWS Glue ETLジョブで1時間ごとにデータをParquet形式でエクスポートする方法は、DC2ノードはRedshift Data Sharingをサポートしていません。Glue ETLによる定期的なS3エクスポートはデータの物理的な複製であり「ストレージ重複なし」要件に違反します。