ある大手グローバル小売企業は、オンプレミスに Teradata データウェアハウス（容量 50TB、テーブル数 3,000 以上）を保有しており、社内 200 名以上のデータアナリストが Tableau および自社開発 BI ツールを通じてレポートを作成しています。50 以上のソースシステム（ERP・POS・EC サイト）から Teradata FastLoad および TPT（Teradata Parallel Transporter）を使用した日次バッチロードと、一部ソースシステムからの CDC（変更データキャプチャ）によるリアルタイムデータ取り込みが行われています。年間ライセンスコストは $12M に達しており、5 年以内のコスト削減が経営目標となっています。 移行にあたっての技術的な要件は以下のとおりです。 ・SQL コードに Teradata 固有の構文（TERA モード、マクロ、派生ピリオドカラム、NORMALIZE 句など）が多数含まれている ・2 年超の履歴データにも月次でアナリストがアクセスする要件がある ・移行期間中もアナリストへの BI アクセスを維持すること（停止は許容されない） ・将来的に機械学習パイプラインとの統合を検討している この移行を最も効果的に進めるためのアーキテクチャはどれですか？
AWS Schema Conversion Tool（SCT）は、Teradata 固有の SQL 構文（TERA モード、マクロ、派生ピリオドカラム、NORMALIZE 句など）を Amazon Redshift 互換の SQL に自動変換する機能を持ち、変換できない箇所はアセスメントレポートとして出力して手動対応範囲を明確化できる。AWS DMS はフルロードと CDC の組み合わせにより、移行期間中も BI アクセスを継続しながらダウンタイムを最小化した移行が可能となる。 Redshift Spectrum を使用することで、コールドデータを安価な Amazon S3 に階層化しつつ Redshift から標準 SQL でシームレスにクエリできるため、2 年超の履歴データへの月次アクセス要件をコスト効率よく満たせる。Redshift ML は Amazon SageMaker AutoPilot と統合されており、SQL から直接機械学習モデルを作成・利用できるため、将来の ML 統合要件にも対応する。SCT の ETL 変換機能は Teradata FastLoad・TPT スクリプトを AWS Glue ETL ジョブへの変換をサポートしており、バッチ ETL の移行も効率化できる。 選択肢BのAmazon Athenaは、アドホッククエリには適しているが、200 名以上が同時アクセスするデータウェアハウスワークロードの性能要件には最適でなく、スキャン量課金モデルで高コストになりやすい。Teradata 固有 SQL は Athena（Presto/Trino ベース）と互換性がないため多数のクエリ書き換えが必要で、BI ツール接続変更による中断リスクもある。 選択肢CのRedshift の自動テーブル最適化（ATO）は、Vacuum・Analyze などのテーブルメンテナンス操作を自動化する機能であり、コールドデータを S3 に自動アーカイブする機能ではない。コールドデータの S3 階層化には Redshift Spectrum を使用する必要があり、ATO ではこの要件を満たせない。また DMS のみでは Teradata 固有 SQL の変換が行えず、SCT なしでは大量のクエリ手動書き換えが必要となる。 選択肢DのAWS DataSyncは、NFS・SMB・S3・EFS などのファイル/オブジェクトストレージ間のデータ転送サービスであり、Teradata のリレーショナルデータベースを直接同期する機能はない。また Redshift Federated クエリはオンプレミスの Teradata への接続をサポートしておらず、対象は Amazon RDS・Aurora・S3 に限定されるため、透過的なアクセス継続は実現できない。