こんにちは、SCSK林です！ 様々なデータ活用が推進される中、データの蓄積場所（データレイク）と分析基盤を異なるクラウドで運用するようなケースもあると思います。一度AWS S3に溜まった膨大なデータを動かすことは容易ではありません。一方で、分析層ではGoogle CloudのBigQueryが持つクエリ性能や、マネージドなETLサービスを活用したいというニーズがあります。 私が担当した某プロジェクトでは、この「AWSにデータ、Google Cloudで分析」というハイブリッド構成を、完全閉域網で実現することが求められました。本記事では、100以上のインターフェースを抱える大規模なデータ連携基盤において、AWSのネットワーク機能をいかに駆使して「セキュア・低遅延・低運用コスト」を実現したか、その設計思想を解説します。 アーキテクチャ概要：Amazon S3 × Google Cloud Data Fusion 今回のアーキテクチャの主役は、Amazon S3とGoogle Cloud Data Fusionです。 システム構成の概要 Storage (AWS) : S3。数百万レコードにおよぶ日次の業務データが蓄積されるデータレイク。 ETL (Google Cloud) : Cloud Data Fusion。GUIベースでパイプラインを構築・管理。 Network : AWS Direct Connect ⇔ Partner Interconnect による専用線接続。 Security : インターネットを一切経由しない閉域網構成。 解決すべき技術的課題 接続性の確保 : 専用線経由でGCPからS3へどうやって「プライベートIP」でアクセスするか。 名前解決（DNS） : 異なるクラウド間で、複雑なインフラを立てずにどうやってS3のFQDNを解決するか。 スケーラビリティ : 100を超えるインターフェースのトラフィックをどう効率的に捌くか。 【技術的ポイント①】Gateway型を棄却し、PrivateLinkを選定 AWSでS3へのプライベートアクセスを考える際、まず頭に浮かぶのは「Gateway VPC Endpoint」でしょう。しかし、本プロジェクトでは「Interface VPC Endpoint」を使用しました。 Gateway Endpointの仕様的限界 S3 Gateway Endpointは、VPCのルートテーブルを書き換えることで機能します。しかし、この仕組みは「VPCの外部（Direct ConnectやVPNの向こう側）」からは利用できないという制約があります。Google CLoud側から専用線経由でアクセスしようとしても、Gateway Endpointへルーティングを飛ばすことはできません。 この制約を回避するためには、VPC内にForward Proxy（Squid等を搭載したEC2）を立てる必要がありますが、これは「サーバーレス・マネージド」というプロジェクトの方針に反し、運用コストと単一障害点（SPOF）のリスクを増大させます。 Interface VPC Endpoint (PrivateLink) の採用 今回使用したのが、Interface VPC Endpoint (AWS PrivateLink) です。 PrivateLinkは、VPC内のサブネットにENI（Elastic Network Interface）を払い出し、S3への通信をそのIPアドレス経由で行います。 メリット : 専用線（Direct Connect）越しに、Google CloudからS3のプライベートIPへ直接ルーティングが可能。 運用の排除 : EC2のようなOS管理が不要。AWSが提供するフルマネージドな高可用性をそのまま享受できる。 100以上のIFが集中する基盤において、インフラの保守をAWSにオフロードできるメリットは、処理量に応じた課金を十分に正当化できるものでした。 【技術的ポイント②】シンプルなマルチクラウドDNS設計 PrivateLinkを採用した際、次に問題となるのが「DNSの名前解決」です。Google Cloud上のData Fusionから、AWS S3のエンドポイント名をどう解決するか。 通常、ここでも「Route 53 Resolver Endpointを立てて、GCP Cloud DNSと条件付き転送（Forwarding）を設定する」という構成が検討されます。しかし、今回はシンプルで保守性の高い方式を採用しました。 PrivateLinkのDNS特性の活用 AWS PrivateLinkでS3エンドポイントを作成すると、 vpce-xxxx.s3.region.vpce.amazonaws.com のような専用のFQDNが払い出されます。このFQDNは、パブリックなDNSサーバから名前解決しても、VPC内のプライベートIPアドレスを返却するという特性を持っています。 Google Clooud の Cloud DNSでのCNAME変換 この特性を活かし、Google Cloud側の設定のみで名前解決を完結させました。 具体的には、Cloud DNSにおいて、Data Fusionが参照するS3の接続先ドメイン名を、AWSから払い出されたPrivateLink用のFQDNへCNAMEレコードとして登録したのです。 構成フロー: Data Fusionが s3.ap-northeast-1.amazonaws.com へアクセス。 Cloud DNSがそれを PrivateLinkのFQDN（ vpce-xxxx... ）にCNAME解決。 そのFQDNをパブリックDNS経由で解決すると、AWS VPC内のプライベートIPが返る。 専用線（Direct Connect）経由で、そのプライベートIPへ直接通信。 この設計により、AWS側にResolver Endpointという追加の有償リソースを立てることなく、また複雑なクロスクラウドのDNS転送設定も不要にしました。 まとめ 本プロジェクトを通じて、AWSとGoogle Cloudのいいとこ取りをしたハイブリッドデータ連携基盤が完成しました。 安定性 : 100以上のインターフェース、日次数百万レコードの転送において、専用線とPrivateLinkの組み合わせにより極めて低いエラー率と安定したスループットを維持。 コスト最適化 : 冗長化されたプロキシサーバやDNSフォワーダーの構築・運用工数を削減し、純粋なデータ処理に集中。 拡張性 : 今後インターフェースが増加しても、ネットワーク経路やDNS設定を変更することなく、Data Fusion上のパイプライン追加だけで対応可能な拡張性を確保。 AWSの各サービスは単体でも強力ですが、その特性を深く理解することで他クラウドとの連携において価値を発揮すると感じました。 この記事がどなたかのお役に立つと幸いです。

こんにちは、SCSK林です！ モダンなシステムアーキテクチャにおいて、システム間を「疎結合」に保つことはもはや定番です。AWSにおいてその中心を担うのは、Amazon SQSやAmazon Managed Streaming for Apache Kafka (MSK)といったメッセージングサービス、あるいはAmazon S3を用いたバッファ層などかと思います。 ただ、実際のエンタープライズ領域におけるデータ連携案件、特にマルチクラウド構成やオンプレミスとの閉域網接続が絡むプロジェクトでは、単に「サービスを間に挟む」だけでは解決できない課題が多いと感じています。 「どのタイミングでデータの到達を保証すべきか」 「コストとスループットの妥協点をどこに置くか」 「リトライによって発生するデータの重複をどう制御するか」 本記事では、私が携わった、毛色の異なる2つのデータ連携プロジェクトを例に、アーキテクトが直面する「キューイング・バッファリング設計」のポイントについて解説していきたいと思います。 プロジェクト事例①：異種クラウド間連携における「Pull型」MSK設計 プロジェクトの背景と課題 最初にご紹介するのは、AWS上の基幹システムで発生する変更データを、Google Cloud上のDWH基盤（BigQuery）へリアルタイムに同期する案件です。 AWS側ではデータのハブとしてAmazon MSKを採用していました。当初の検討では、MSK Connectを利用してGoogle Cloud側のエンドポイントへデータをPush送信する構成が有力でした。しかし、精査を進めると以下の3つの大きな課題が浮上しました。 ネットワークの不確実性: AWSからGoogle Cloudへのクロスクラウド通信、かつ専用線経由という環境下で、ネットワーク瞬断時のエラーハンドリングをどこまでインフラ層に任せられるか。 コスト効率の悪化: 同期対象となるインターフェース（Topic）は20個以上存在しました。MSK Connectはコネクタ単位でのMCU（MSK Connect Unit）課金が発生するため、1日の流量が数千件程度の比較的小規模なインターフェース群に対して個別にコネクタを立てると、データ量に対して極めて割高な固定費が発生します。 責任分界点の曖昧さ: 送信側（AWS）が無理に押し込む「Push型」では、受信側（Google Cloud）の負荷状況に合わせた流量制御（バックプレッシャー）が難しく、受信失敗時の再送管理が複雑化します。 独自コンシューマーによる「Pull型」への転換 結果的には、マネージドサービスであるMSK Connectの採用を見送り、Google Cloud側のCloud RunからMSKへ「Pull型」でデータを取得しに行くカスタムコンシューマー構成を提案しました。 この設計は、「責任完了のポイント」をコンシューマー側に移譲したことにあります。 同期的なオフセット管理 : コンシューマーはMSKからメッセージを取得し、Google Cloud側のストレージ（Pub/Sub）への書き込みが完全に完了したことを確認してから、MSKに対して「Offset」をコミットします。これにより、処理の途中でコンシューマーがダウンしても、次回の起動時に未処理のデータから確実に再開できる「At-least-once（少なくとも一回）」を担保しました。 コストの最適化 : 20個以上の多くのインターフェースを単一または少数のCloud Runサービスに集約して処理することで、MSK Connectを利用した場合と比較してインフラコストを大幅に抑制しました。 重複排除の戦略的妥協 : At-least-once構成では、再送時にデータの重複が発生する可能性があります。これをインフラ層の複雑なロジックで排除しようとせず、最終的な格納先であるGoogle Cloud側（BigQuery）で、ユニークキーに基づいた「重複排除処理」を行う方針を策定しました。 技術的な「完璧さ」をインフラだけで追求するのではなく、エンドツーエンドでの整合性とコストのバランスを考慮した構成になっているかなと感じています。 ※詳細はこちらのブログも参照ください。 【AWS - Google Cloud】マルチクラウドでキューイングデータ連携 AWS MSKからGCPへのデータ連携において、MSK Connectの仕様制約に伴うコスト肥大化を回避するため、Cloud RunによるPull型アーキテクチャへと転換した事例を紹介します。コスト最適化と疎結合な設計により、大規模なマルチクラウド環境下で高効率かつ堅牢なデータパイプラインを実現した経緯を詳説します。 blog.usize-tech.com 2026.03.23   プロジェクト事例②：S3を「バッファ」と見立てた高耐久非同期アーキテクチャ プロジェクトの背景と課題 次にご紹介するのは、オンプレミス環境からAWSを経由し、データウェアハウスであるSnowflakeへデータをロードする基盤構築案件です。 この案件では、Direct Connect経由で送られてくるデータをAPI Gateway + Lambdaで受け取る構成をとりましたが、以下の制約が障壁となりました。 Lambdaのペイロード制限 : API GatewayおよびLambdaには数MBから数十MBのペイロード制限があり、将来的なデータ肥大化に対応できない懸念がありました。 Snowflakeへのロード遅延 : Snowflakeへの書き込み処理には、オーバーヘッドを含めて一定の時間が必要です。同期的な処理では、APIのタイムアウトや、オンプレミス側のクライアントを長時間待機させるリスクがありました。 性能要件の遵守 : 「データ発生から3分以内に分析可能にすること」という性能要件に対し、単一のプロセスで全てを完結させるのは可用性の観点から危険だと判断しました。 S3を「高耐久なキュー」として定義 私は、Amazon S3を単なるストレージではなく、「書き込みが極めて高速で、無限のキャパシティを持つキュー（バッファ）」として位置づける非同期アーキテクチャを採用しました。 取り込み層（受領）の軽量化: API Gatewayから起動されるLambdaの役割を「S3へのファイル保存」のみに限定しました。これにより、オンプレミス側に対しては数ミリ秒から数百ミリ秒という極めて短いレスポンスタイムで「受領完了」を返せます。 ロード層（処理）のデカップリング: S3へのファイル作成をトリガー（S3 Event Notifications）として、後続のLambdaがSnowflakeへのロードを実行します。この構成により、Snowflake側で一時的なメンテナンスや障害が発生しても、データはS3に「滞留（キューイング）」されるだけであり、取り込み層を止める必要がなくなります。 枯れた技術による信頼性: Snowflakeへのロードには、あえて最新のSnowpipeではなく「LambdaによるCOPYコマンド実行」を選択しました。これは既存の資産であるシェルスクリプトのロジックを流用しやすくするためであり、またエラー時の再実行制御をより細かくハンドリングできるようにするためでした。 結果としてのパフォーマンス この「S3バッファ」を介した非同期構成により、結果としてデータ発生からSnowflakeへの到達まで、平均して十数秒というパフォーマンスを実現しました。目標としていた「3分以内」という性能要件を大幅に上回る余裕を持った設計となりました。 ※詳細はこちらのブログも参照ください。 Amazon API Gateway + AWS Lambda + Snowflake によるニアリアルタイムデータ連携 オンプレミスからSnowflakeへのデータ連携において、API GatewayとLambdaを用いた非同期処理による、データ基盤構築の事例を解説します。S3を境界に「取り込み」と「ロード処理」を分離することで、閉域網での高いセキュリティと耐障害性を両立させた設計をご紹介します。 blog.usize-tech.com 2026.03.23   まとめ：キューイング設計における3つのポイント これら2つの案件を通じて、痛感した「キューイング設計のポイント」は以下の3点に集約されると感じました。 ① 責任分界点（Commit Point）をどこに置くか 「データを受け取った」とみなすタイミングをどこにするかは、システムの信頼性を左右する最も重要な決断です。事例①では、宛先システムが処理を終えたタイミング。事例②では、AWS側の高耐久ストレージ（S3）に書き込んだタイミング。 これを明確に定義することで、障害発生時に「どこからリトライすべきか」が自ずと決まります。 ② マネージドサービスとカスタム実装の天秤 マネージドサービスの利点は十分に理解していますが、事例①のように「インターフェース数が多いが、個々の流量が少ない」といった特殊な条件下では、マネージドサービスのコスト構造がボトルネックになることがあります。 「何でもマネージド」ではなく、ランニングコストと運用負荷（メンテナンス性）を天秤にかけ、時にはカスタムコンシューマー（手組のプログラム）を選択する勇気も必要です。 ③ 冪等性の確保 キューイングを導入する以上、リトライによる「重複」は避けられません。インフラ側で「Exact-once（正確に一回）」を実現しようとすると、アーキテクチャは極めて複雑になり、パフォーマンスも低下します。 「重複は発生するもの」と割り切り、アプリケーション層やデータベースのレイヤーで重複排除を行う設計にすることで、システム全体の堅牢性とシンプルさを両立させることができます。 おわりに AWSはじめ各クラウドサービスには、データ連携を支える強力なサービス群が揃っています。しかし、それらを組み合わせるだけで優れたシステムが出来上がるわけではないと改めて感じました。 今回の事例では、「あえてマネージドサービスを使わない」「あえて非同期にする」といった、ある種のデザインチョイス（選択と集中）です。ビジネス要件、コスト制約、そしてネットワークの物理的な限界を直視し、どこで妥協し、どこで妥協するか。その判断こそが難しいポイントだなと思いました。 今回の構成、事例がどなたかのお役に立つと幸いです。

こんにちは、SCSK林です！ 昨今のエンタープライズシステムにおいて、単一のクラウドプロバイダーで全てのワークロードが完結するケースはかなり稀だと思います。 とある案件では、「AWS上の業務データを閉域網経由でGoogle Cloudへ転送し、BigQueryで分析する」という要件に加え、オンプレミスの基幹システムとも連携が必要な「3地点接続」のネットワーク構築が必要でした。 本記事では、AWSの実装そのものではなく、全体アーキテクトの視点から、「AWS Direct Connect を他クラウドやオンプレミスと接続する際に、ハマりやすいポイントと設計の勘所」について共有します。 細かい実装の話ではないので、マルチクラウド接続を実際に設計/構築する時にはここら辺考えないといけないよな～的な目線で見ていただけると幸いです。 アーキテクチャ概要：SCNXをハブとしたハブ＆スポーク構成 今回の要件において、最大の課題は「AWS、Google Cloud、オンプレミスの3地点を、いかにシンプルかつセキュアに接続するか」でした。 各拠点をフルメッシュで接続（AWS⇔Google Cloud、AWS⇔On-Prem、Google Cloud⇔On-Prem）すると、管理コストとルーティングの複雑さが指数関数的に増大します。 そこで今回は、SCSKのクラウド接続サービス「SCNX」をハブとして採用し、物理的な複雑さを抽象化しました。 AWS: AWS Direct Connect (DX) GCP: Cloud Interconnect On-Premises: 閉域網接続 Hub: SCNX (Virtual Router) ※SCNXの紹介はコチラ： https://www.scsk.jp/sp/netxdc/lp1/ 設計ポイント BGPルーティング設計 例えばActive/Standby構成を実現するためには、物理的に線を繋ぐだけでなく、BGP（Border Gateway Protocol）を用いて「どちらの道を優先するか」を論理的に制御する必要があります。 AWS Direct Connectにおいて、経路制御を行いActive/Standbyを正しく機能させるには、以下の設計が必要となります。 AWSへの流入制御 Google CloudやオンプレミスからAWSへデータを送る際、AWS側で受け取る経路をPrimaryに固定する必要があります。 ここで重要になるのが AS_PATH Prepend です。AWS側（Direct Connect Gateway）の設定において、Standby回線側のAS Path（自律システム経路）を意図的に長く見せる（Prependする）ことで、対向ルーター（SCNX/Google Cloud）に対して「こちらの道は遠回りだ」と判断させ、自然とPrimary回線が選択されるよう設計しました。 AWSからの流出制御 逆に、AWSからGoogle Cloudへデータを送る際は、AWS側で Local Preference 値を調整し、Primary回線の優先度を高く設定する必要があります。 ※参考URL： https://aws.amazon.com/jp/blogs/news/dx-trafficcontrol-osaka/ 他クラウドと接続する場合、AWSのBGP仕様（Prependの反映挙動など）を理解し、対向システム側とパラメータの整合性を取らなければ、頻繁に経路が切り替わる「フラッピング」の原因となります。 データ転送の最適化：MTUとMSSの調整 複数拠点を接続する際に考慮すべきなのがパケットサイズ（MTU）です。 AWS Direct Connectはジャンボフレーム（MTU 9001）をサポートしていますが、経路上にあるSCNXやGoogle Cloud Interconnect、あるいは途中の仮想アプライアンスでMTUが1500に制限されている場合があります。 この不一致を放置すると、ハンドシェイク（小さなパケット）は成功するのに、いざ大量のデータを転送し始めるとパケットがドロップされるという厄介な現象が発生します。 それの予防策、安全策として、TCP MSS Clamping（最大セグメントサイズの調整）を導入し、経路上の最小MTUに合わせてパケットサイズを最適化することで、安定した通信を確立することができます。 IPアドレス設計：AWS Security Groupはじめファイアウォール設定 構築・テストフェーズでありがちなのが、通信がタイムアウトする系のエラーです。 マルチクラウド環境では、IPアドレス設計が非常に重要です。AWS、Google Cloud、オンプレミスでCIDRが重複しないことはもちろん、「どの範囲のIPが、どのポートで通信してくるか」を厳密に管理し、SGのルールへ反映させるプロセスを徹底する必要があります。 また、アプリの追加要件で当初想定より広いIPレンジが後から必要になることもありがちです。 インフラ担当の皆さんは、特にクラウドサービスだと余裕を持ったIPレンジの確保をしておくことが心の余裕につながります。笑   さいごに 単一のクラウドに閉じていれば難しくないことも他クラウド、他拠点が出てくると技術的難易度が上がってしまいます。 また、往々にして担当者・担当チームがクラウドごとにわかれていて全体設計が蔑ろにされ、問題が後から噴出することもままあると思います。 そのためにも、AWSだけでなく、Google Cloudだけでなく、複数のクラウドに関する知識、知見を持っておくことが重要だと感じました。 この記事がどなたかのお役に立つと幸いです。