DEA-1.1データの取り込みを行う。

ヒントボタン

クリックストリームを秒間三万件で絶え間なく取り込み、到着順そのままに二十四時間保持しつつ再処理もしたい場合、Kinesis Data Streams オンデマンドはシャード数を意識せず毎秒最大二百メガバイトへ自動拡張し順序保証も提供します。強化ファンアウト付き Lambda を使えば各コンシューマが二メガバイト毎秒を独立して受け取れるため、ピーク変動にも追従しながらリアルタイム分析や再読取が容易です。
ダッシュボードが単一項目を五十ミリ秒以内で取得する要件には DynamoDB オンデマンドが適しています。広告IDをパーティションキーにして均一分散させれば GetItem は十ミリ秒台で返り、キャパシティはリクエスト駆動で自動拡張します。さらに TTL に二十四時間を設定しておけば古いレコードは自動削除されるため、バケットを跨いで Athena や QuickSight にクエリする場合より低遅延かつ運用負荷とコストを抑えられます。
Kinesis と Lambda で取り込みと処理をサーバレス化し、DynamoDB オンデマンドと TTL によって保存領域を自律運用とする構成は、順序保証、低レイテンシ、高スループットの三要件に加えトラフィック変動への自動スケールと運用コスト最小化を同時にかなえるかという総合的観点で最適解を導く鍵になります。

ヒントボタン

注文データが Amazon Kinesis Data Streams から毎秒5万レコードで流れ込み、到達から60秒以内に Amazon Redshift RA3 へ格納しつつ250同時接続のユーザークエリを2秒以内で返すためには、大量小分け COPY で発生するテーブルロックを避けられる Redshift ストリーミング取り込みと自動 REFRESH マテリアライズドビューを使った数秒レベルの直接ロードが最も要件に沿いやすいです。
Amazon S3 を経由して Redshift COPY を呼び出すパターンは、Kinesis Data Firehose のバッファリングや COPY トランザクションのコミットで遅延が積み重なり、実行中に EXCLUSIVE LOCK がかかるためユーザークエリ SLA が揺らぎやすく、60秒以内の継続ロードが必要なリアルタイム分析ではロックを発生させない Redshift Streaming Ingestion の方が運用負荷と待ち時間を低減できます。
ピーク10万レコード/秒への拡張、ETL サーバー追加禁止、S3 バッチ不可、重複排除、最小遅延、クエリブロック無しという複数制約を俯瞰すると、ノード追加で水平にスループットを伸ばせ、COPY を介さず即時に列指向ストレージへ書き込める Amazon Redshift Streaming Ingestion が全要件をバランス良く満たす選択肢であると整理できます。

ヒントボタン

市場データの配信元が AWS Data Exchange for APIs である以上、まずは InvokeAPI を自動で呼び出す仕組みが必要です。Amazon EventBridge Scheduler は cron の代替として完全マネージドで 1 分単位の間隔を設定でき、IAM ロールだけで動作するため常時稼働の EC2 や AWS Batch を置かずに済みます。30 分おきのジョブを組めば応答取得から後段へシームレスに接続でき、コストと運用の両面で優位になり、認証トークン管理もサービス内部で完結します。

取得したレスポンスをそのまま Amazon S3 に格納すれば高耐久ストレージに最短で届き、バージョニングや S3 Lifecycle も活用できます。AWS Lambda はイベント駆動でミリ秒単位に起動し、InvokeAPI の結果を PUT するだけを実行するため従量課金で済みます。S3 PUT 通知を EventBridge あるいはネイティブイベントで受け取り AWS Glue クローラや Glue ジョブを自動発火させれば、カタログ化と Parquet 変換が即時に行われ、30 分以内という SLA を確実に満たせます。

もし EC2 で curl を定期実行したりファイル配信タイプを手動エクスポートしたり Amazon AppFlow から Kinesis Data Streams へ流す構成を採ると、常時稼働インスタンスの監視やストリーム基盤の保守が増え、nightly rsync や週次バッチでは遅延要件を満たしません。公式コネクタの有無、サーバーレス特性、データ到達タイムラインという複数要件を俯瞰し最小構成で完全自動化できる案を選びましょう。

ヒントボタン

異種データベースで 4TB を夜間に止めずに送るなら、AWS SCT でスキーマを先に変換し、AWS Database Migration Service をフルロードと Change Data Capture の組み合わせで動かすのが基本です。毎時 5GB の変更を 90Mbps の Site-to-Site VPN で継続同期するには m5.4xlarge など高スループットのレプリケーションインスタンスを用い、タスクを並列化しておくと RPO 0 と 15 分以内のダウンタイムが狙えます。

Snowball Edge で物理搬送したり Oracle Data Guard を EC2 上で同期モードにする方法は、一時的な網羅性の高さや既存機能への慣れから魅力的に見えますが、CDC を自動維持できなかったり、VPN の遅延が高く同期が非現実的になったり、さらに AWS Glue や手動スクリプトによる変換・差分吸収が必要となり、医療向けの厳格な RPO 0 と 15 分停止という条件を安定して満たすには運用負荷とコストが膨らみやすい点を踏まえて比較すると良いでしょう。

ネット帯域の制約、ゼロデータ損失、15 分以内のカットオーバー、異種間変換、夜間自動実行という五つの要件を同時に満たせるかを俯瞰すると、マネージドでフルロード後も CDC を止めずに追従しスワップカットオーバーで瞬時に切替えられる AWS DMS が最もシンプルでコスト効率にも優れる選択肢として浮かび上がるはずです。

ヒントボタン

Amazon S3 へ VPC 内からインターネットを一切通さずに通信する方法として思い出したいのが Gateway Endpoint です。類似に NAT Gateway がありますが、こちらは結局 IGW へ 0.0.0.0/0 で抜けるため公開網を経由し、50 並列の AWS Glue ジョブが吐き出す 300 TB 規模の転送では Data Processing 料金も跳ね上がります。オンプレミスと Direct Connect で厳格に閉域を保つ金融機関の設計ではまず Gateway Endpoint を入り口にして検討すると良いです。

Gateway Endpoint を採用する際は、ルートテーブルに個別 CIDR を書く代わりに S3 プレフィックスリストを一行で追加できます。AWS が数百の IP を日々更新しても自動追従するため運用負荷がほぼゼロになり、セキュリティグループやバケットポリシーの aws:SourceVpce 条件で VPC 内からのアクセスだけを許可すれば、インターネット禁止とガバナンスの二つの要件を同時に満たせます。

最少コスト・運用負荷・閉域セキュリティという三つの制約を同時に満たす解法は、VPC のプライベートサブネットに S3 用 Gateway Endpoint へのルートをプレフィックスリストで記載し Glue API 用 Interface Endpoint を補完する構成です。NAT や IGW を排しつつ Direct Connect とは競合しない経路が取れるかを総合的に見比べて判断してください。

ヒントボタン

CloudWatch Logs から別アカウントの Kinesis Data Streams へサブスクリプション転送するとき、ロールを sts:AssumeRole する主体は運用者でも Kinesis でもなく CloudWatch Logs サービス自身です。信頼ポリシーの Principal に logs.amazonaws.com を設定しない限り、CloudWatch Logs は CrossAccountStreamingRole を引き受けられず AccessDeniedException が続きます。まずはこのサービスプリンシパルが正しく置かれているかを丁寧に点検してみてください。

サービスロールの過剰許可を避けるためには IAM の Condition が鍵になります。CloudWatch Logs では aws:SourceArn 条件に /us-east-1/application.log のロググループ ARN を完全一致で入れることで、指定以外のグループやアカウントからの呼び出しを遮断できます。aws:SourceAccount だけでは同一アカウント内の別リソースから AssumeRole できる余地が残るため、最小権限の観点では SourceArn のほうが望ましいというガイドラインを思い出してください。

まとめると、Principal を logs.amazonaws.com とし、Condition で aws:SourceArn に対象ロググループを限定した IAM 信頼ポリシーを CrossAccountStreamingRole に適用し、B アカウント側の Kinesis Data Streams には PutRecord 系権限を保持させる構成が、リアルタイム転送の性能要件とセキュリティ要件の双方を俯瞰して最もバランス良い解決策となります。

ヒントボタン

Salesforce からデータを安全に取り込みつつ運用コードを書かずに済ませたい場合、PrivateLink で VPC エンドポイントを張れる Amazon AppFlow が有力です。GUI で 15 分間隔のスケジュールを設定でき、TLS と SSE-KMS により転送・保存の両方を暗号化可能です。データ量が多くてもマネージドでスケールし、レプリケーションインスタンスや Lambda の保守が不要なため「コードレス」の条件に合致し、他 SaaS 連携の実績も豊富です。

3 年分を保持すると数十億行規模になるため、列指向 Parquet で Amazon S3 に置く方が Redshift 内部ストレージより格段に安価です。Amazon AppFlow は year/month/day 形式のフォルダに自動パーティションを書き分けでき、AWS Glue クローラを回せば Athena や Redshift Spectrum が即座にスキーマを認識します。さらに S3 ライフサイクルで Glacier へ階層移行も容易なので、長期履歴を低コストで維持できます。

dc2.large 4 ノードで同時実行 10 程度の環境では頻繁な COPY や連続 INSERT よりも、Redshift Spectrum で S3 上の Parquet 外部テーブルを参照し、夜間に CTAS で集計テーブルへバルクロードする方が CPU 消費を抑えられます。取得側は AppFlow が 15 分 RPO を確保し、集計側は日次バッチで十分です。プライベート接続・暗号化・ストレージコスト・運用簡素化を俯瞰すると、この流れが全要件を最もバランス良く満たします。

ヒントボタン

オンプレミスNFS共有の毎日3TB増分をメンテナンス時間の4時間で届けるには、10GbpsのAWS Direct Connectを活かしつつTLS1.2以上で暗号化しブロック単位の差分を高並列コピーできるAWS DataSyncをオンプレVMエージェントで使う構成が最適で、ウェブコンソールのスケジューリング機能により00:00〜04:00だけタスクを走らせられるため、導入が簡単かつ運用負荷を抑えながら必要なスループットを確保できます。
DataSyncは転送中にワイヤプロトコルで暗号化するだけでなく転送完了後に自動でチェックサムを再計算しバイト欠損を把握し、その結果をAmazon CloudWatchメトリクスとして公開するため、BytesWrittenとBytesVerifiedの差から0.1％超の閾値にアラームを設定してAmazon SNS通知までをコードなしで実装でき、整合性と監視の両要件をまとめて満たせます。
最終的に90日経過後は高コスト効率が求められるのでAmazon S3 Lifecycleポリシーで対象オブジェクトを自動的にGlacier Deep Archiveへ移行し、転送・暗号化・整合性検証・監視・階層化という複数の要件をフルマネージド機能だけで統合的に実現できる構成を選ぶことが、コスト最適性と運用負荷最小化の双方を俯瞰した総合的な判断となります。

ヒントボタン

Glue ジョブで Oracle JDBC や Amazon MSK に安全かつ継続的に接続するには、Secrets Manager と連携した Glue Connection を用いることで、パスワードや TLS 用 CA 証明書を Connection メタデータに保持し、ジョブ側は名前を指定するだけで済み、コードやジョブ引数に認証情報が残らないうえ、将来的なパスワードローテーションも Secrets Manager 側の更新だけで自動反映されるため監査コストが減ります。
Connection オブジェクトではサブネットとセキュリティグループを紐付けられるので、Glue の ENI がプライベート AZ 内に払い出され、Oracle on-premise と MSK ブローカーへの通信を VPC 内の TLS ポートに限定できます；逆に JDBC URL をスクリプトに直書きすると帯域選定や ACL 調整を毎回手作業で行う必要があり運用を圧迫します。
データ移送を DMS や DataBrew など別サービスに分散させると監視方法が増え保守工数が跳ね上がる一方、Glue Spark ジョブに二種類の Connection を関連付ければ差分 500 万行と 2,000 メッセージ/秒というスループットを単一パイプライン内でさばけるため、セキュリティ・ネットワーク・運用の三要件を総合的に最もシンプルな構成で満たせる点を見極めてください。