Snowpipe / Snowpipe Streaming で継続ロードを実装する

S3にファイルが着地した瞬間、あるいはアプリが行を生成した瞬間に、データをSnowflakeのテーブルへ継続的に流し込む——それを担うのがSnowpipeとSnowpipe Streamingです。本記事では、S3イベント通知とSQSを使うSnowpipe auto-ingestの仕組みから、2025年にGAした高性能アーキテクチャ、そしてレイテンシとコストの特性までを、AWS側の設定と検証で潰した落とし穴を交えて、実装目線で解説します。

01「継続ロード」で何を解きたいのか

データ基盤の取り込みは、大きく「定期バッチでまとめて COPY INTO する」方式と、「データが到着するたびに継続的に取り込む」方式に分かれます。前者は仮想ウェアハウスを起動して COPY を回すため、起動待ちや空回りの時間がコストに乗りやすく、鮮度も投入間隔に縛られます。後者、すなわち継続ロードは、S3にファイルが着地した瞬間、あるいはアプリケーションが行を生成した瞬間にテーブルへ流し込むアプローチで、Snowflakeでは Snowpipe と Snowpipe Streaming が担います。

両者はどちらも「ユーザーが管理する仮想ウェアハウスを使わない」点が共通します。Snowflake側のサーバーレス計算（またはストリーミング取り込み層）が処理を引き受けるため、取り込み専用のウェアハウスを常時起動しておく必要がありません。一方で、レイテンシの粒度と課金の仕組みが大きく異なるため、要件に合わない方式を選ぶと「思ったより遅い」「思ったより高い」という結果になります。本記事ではAWS側の設定まで含めて、その勘所を整理します。

02Snowpipe auto-ingest の仕組み

Snowpipeは、S3などのステージに置かれたファイルを検知して、PIPEオブジェクトに定義した COPY 文でターゲットテーブルへ継続的にロードする仕組みです。ファイルの検知方法には、RESTエンドポイントを呼び出す方式と、S3イベント通知を使う auto-ingest 方式があります。AWS上で運用するなら、後者の auto-ingest が定番です。

流れは「S3にファイルが着地 → S3イベント通知がSQSへ → SnowpipeがSQSを見て COPY」です。ポイントは、このSQSキューをSnowflakeが自動で作成・管理することです。PIPEを AUTO_INGEST = TRUE で作成すると、Snowflakeが専用の通知チャネル（SQSキュー）を割り当て、その ARN が SHOW PIPES の notification_channel 列に表示されます。運用者はこのARNを、S3バケットのイベント通知の宛先として設定するだけで済みます。

03AWS側の設定：S3イベント通知・SQS・IAM

auto-ingestの設定は、Snowflake側とAWS側の両輪です。Snowflake側では、まずS3バケットを読むための STORAGE INTEGRATION を作ります。これはSnowflakeが assume する IAM ロールを紐づけるオブジェクトで、ロールの信頼ポリシーにSnowflake側のIAMユーザーARNと external ID を設定します。アクセスキーを埋め込まずに、ロールの引き受けで最小権限のS3読み取りを与えられるのが利点です。続いて外部ステージとPIPEを作り、SHOW PIPES で notification_channel のSQS ARNを取得します。

AWS側では、対象バケットのイベント通知で「すべてのオブジェクト作成イベント（ObjectCreated）」を選び、宛先にそのSQS ARNを指定します。ここで効いてくる制約が、Snowflakeは1つのS3リージョンにつきSQSキューを1つに集約するという点です。つまり同一アカウント・同一リージョンの複数バケットや複数パイプが、この1つのキューを共有します。バケット側のプレフィックスと、PIPE側のパスやパターンで取り込み対象を正しく絞ることが前提になります。

04Snowpipe Streaming：classic と高性能アーキテクチャ

Snowpipeがあくまで「ファイル」を起点にするのに対し、Snowpipe Streamingは行（ロー）を直接テーブルへ書き込みます。ファイルの生成・着地・検知という段を丸ごと省くため、レイテンシは秒単位まで縮みます。KafkaやAmazon MSKからの取り込みでは、Snowflake Kafkaコネクタが内部でこのStreaming経路を使います。

2025年9月、このStreamingにAWS上で「高性能アーキテクチャ」がGAしました。従来（classic）はSDKクライアントがテーブルへ直接書き込み、検証はクライアント側で行う設計でしたが、高性能アーキテクチャではサーバー側の PIPEオブジェクト が入り口になります。PIPEがサーバー側で軽量な変換やスキーマ検証を担い、チャネルとオフセットトークンで exactly-once を保証します。SDKは共有Rustコア上のJava/Python版が提供され、REST APIも用意されています。公称値では最大10GB/s/テーブル、取り込みからクエリ可能までのレイテンシは通常10秒未満とされています。

05レイテンシとコストの特性を正しく見積もる

まずレイテンシから。Snowpipe（ファイルベース）は「マイクロバッチで数分以内」が目安ですが、Snowflakeの公式ドキュメントも、ファイル形式・サイズ・COPY文の複雑さに左右されるため厳密な保証はしていません。まとまった量の代表的なロードで実測して平均を掴め、というのが公式の案内です。対してSnowpipe Streamingは秒単位。「数分の鮮度で十分か、秒単位が要るのか」が方式選択の一次分岐になります。

コストは方式ごとに毛色が違います。Snowpipe（ファイルベース）は、かつては取り込んだデータ量に応じたサーバーレス計算に加えて、1,000ファイルあたりのオーバーヘッド課金（従来モデルで0.06クレジット/1,000ファイル）という2要素があり、極端に細かいファイルを大量に流すとこのファイル単位オーバーヘッドが効いてくる構成でした。ただし2025年12月に価格モデルが簡素化され、現在のSnowpipeは取り込んだデータ量に対するGB単価（0.0037クレジット/GB）で課金され、ファイル数には依存しません。Snowpipe Streaming classicは、ストリーミングクライアントの稼働に対する時間課金（クライアントあたり0.01クレジット/時）とサーバーレス計算の従量。高性能アーキテクチャは、取り込んだ非圧縮GBに対する従量制へ整理され、ファイル数やクライアント数に依存しない、より見積もりやすいモデルになりました。

06検証段階で先に踏み抜いておく落とし穴

EMWは低コストの小規模導入から最大規模まで、複数業種でSnowflakeの取り込み基盤を設計・運用してきました。継続ロードの事故は、そのほとんどがPoC・検証段階で顕在化させて潰せます。実際に検証環境で先に踏んでおき、本番構成では未然に防いだ代表例を挙げます。

一つ目はファイル粒度の問題です。ある検証で、上流が数KB〜数十KBの細かいファイルを毎秒大量に吐く構成をそのまま流したところ、ロード自体は動くのに、当時のファイル単位オーバーヘッド課金がコストを押し上げると分かりました（前述のとおり、このファイル数依存の課金は2025年12月の価格簡素化で解消されています）。本番ではS3着地の手前でFirehoseやアプリ側のバッファリングでファイルを適切なサイズ（目安として数十MB〜100MB超）へ束ねました。オーバーヘッド課金がなくなった現在の価格でも、まとめて束ねるとCOPY・サーバーレス計算の効率が上がるため、大きめのファイルにまとめる設計自体は依然として有効です。

二つ目はS3イベント通知の競合です。既存のバケットにLambdaトリガーが設定済みで、そこへSnowpipe用のSQS通知を同じプレフィックス・同じイベント種別で足そうとすると、S3は重複する通知設定を許しません。検証でこの制約に当たったため、本番ではSNSトピックを噛ませてファンアウトし、同じObjectCreatedイベントを既存のLambdaとSnowflakeの両方へ配信する構成にしました。

三つ目はStreamingクライアントの放置です。classicの検証で、行がほとんど流れていない時間帯でも、開いたままのストリーミングクライアントに対して時間課金が続くことを確認しました。本番ではチャネルを集約し、不要なクライアントを開きっぱなしにしない運用へ寄せることで、アイドルコストを抑えました。高性能アーキテクチャの従量制であれば、この種の心配は構造的に小さくなります。

07使い分けの指針

整理すると、選択の軸はレイテンシ要件・データの入り方・コストモデルの3つです。上流がすでにS3へファイルを落とす（ETL、Firehose、外部SaaSのエクスポートなど）バッチ寄りの取り込みで、鮮度は数分で許容できるなら Snowpipe auto-ingest が最小構成で堅実です。KafkaやアプリからのイベントをCDCやIoTのように秒単位で載せたいなら Snowpipe Streaming、これから新規に組むなら高性能アーキテクチャが第一候補になります。取り込んだ行は、Dynamic Tablesで下流の集計を宣言的に更新したり、CortexやAmazon Bedrockと組み合わせた分析・生成AIの入力へ繋いだりと、その先の設計にも自然に伸ばせます。

重要なのは、ファイル粒度・通知経路・課金モデルという「効いてくるパラメータ」を、本番に載せる前に検証環境で数字にしておくことです。ここを飛ばすと、動くけれど遅い・高い基盤になりがちです。継続ロードは仕組み自体はシンプルですが、AWS側の設定と課金特性の理解が仕上がりを左右します。