Snowflake Kafkaコネクタバージョン4.0の一般提供を開始：同バージョンがメジャーアップグレードである理由を紹介

Apache Kafka®を大規模に実行する場合、コネクタは本来担うべきではない作業（バッファ管理、スキーマ検証、Java仮想マシン（JVM）のチューニングなど）を行うことになります。この状況を変えるために、Kafkaコネクタバージョン4.0（V4）を構築しました。これは、プラットフォーム内で検証、変換、コミットを処理するサーバー側の取り込みサービスであるSnowpipe Streamingの高性能アーキテクチャに基づいて、Snowflake Kafkaコネクタをゼロから書き直したものです。コネクタの役割は、現在ではシンプルになっています。コネクタは行を配信し、残りはSnowflakeが処理します。

Snowpipe Streamingは、一般提供開始以来、数千に及ぶお客様の環境で本番稼働して展開しており、大規模な環境での実績があります。KafkaコネクタV4はこれを最大限に活用し、取り込みロジックをサーバー側に移行することで、ワーカー側の処理負荷を大幅に削減します。Kafkaコネクタバージョン3.0（V3）は、何年にもわたって本番環境で実証されてきました。KafkaコネクタV4へのアップグレードパスでは、最初からやり直す必要はありません。現在V3を実行している場合、既存のデッドレターキュー（DLQ）とエラー処理パターンは、初日から変更なしで機能します。お客様はご自身のペースで移行できます。

本日一般提供（GA）となったKafkaコネクタV4では、取り込みからクエリ可能になるまで、テーブルあたり最大10 GB/秒のスループットと5秒のエンドツーエンドのレイテンシーが観測されています。支出の予測をはるかに容易にするため、サーバーレスコンピュートとクライアント接続に関連付けられたクレジットベースのモデルに代わり、Snowpipe Streamingのスループットベースのモデルと同じ取り込みの料金体系を採用しています。支払いは1 GBあたり0.0037クレジットで一定です。2025年8月にBusiness CriticalおよびVirtual Private Snowflake（BC/VPS）エディションのお客様にロールアウトした際の社内ベンチマークに基づくと、お客様は新しい料金モデルによってすでに50%以上のコスト削減を実現しています。さらに、これまで以上に使いやすくするために、セットアップからSnowflakeでのストリーミングパイプラインの実行までをサポートするKafkaコネクタV4 Cortex Codeスキルと一連のスキルを構築しました。

アーキテクチャの転換

KafkaコネクタV3では、コネクタはクライアント側の検証、バッファ管理、Snowflake固有のカスタムコンバーター、スキーマ処理など、多くの役割を担っていました。これらはすべてリソースを消費し、クライアント側のインフラストラクチャに潜在的な障害点を作り出していました。

KafkaコネクタV4は、このモデルを覆します。処理はPIPEオブジェクトを通じてサーバー側に移行します。これは、ストリーミングデータがテーブルに格納される前に、どのように検証、変換、コミットされるかを定義するSnowflakeマネージドのオブジェクトです。コネクタの役割はシンプルになります。それは、行を配信することです。Snowflakeが検証、変換、クラスタリング、およびコミットを処理します。最新バージョンに移行またはアップグレードするお客様向けに、KafkaコネクタV4はV3のコア機能に対するオプションのクライアント側互換性を提供しています。つまり、お客様はダウンタイムを心配することなくアップグレードできます。

この移行により、ダウンストリームのすべてが簡素化されます。

• テーブルの自動作成：コネクタがデータからターゲットテーブルを作成します。事前のプロビジョニングは不要です。
• サーバー側のスキーマ進化：データの変更に応じて、Snowflakeが新しい列を追加します。クライアント側のDDLは不要です。

標準のコミュニティコンバーター：KafkaコネクタV4では、Snowflake固有のSnowflakeJsonConverterおよびSnowflakeAvroConverterが廃止されました。すでにご存知の標準的なJsonConverter、AvroConverter、およびProtobufConverterを使用できます。

• 構成の簡素化：バッファ、ストリーミング、最適化に関する多数の設定項目が削除されました。サーバーが管理すべきものはサーバーが管理します。
• 移行の互換性：DLQを使用したクライアント側の検証などの機能に完全に対応しています。コネクタクラスを移行し、エラー処理パターンを維持しながら、ご自身のペースでKafkaコネクタV4の機能を採用できます。

Cortex Codeを使用してハンズオンでお試しください。簡素化されたセットアップを直接体験する場合は、Cortex Codeにssv2 quickstartと入力して開始してください。

パフォーマンス

ストリーミングのパフォーマンスを評価する場合、ネットワークがボトルネックになることはほとんどありません。多くの場合、Kafka Connectワーカーのコンピュートオーバーヘッドが原因です。高負荷のワークロード（4CPU、8 GB RAM、8パーティション、ノードあたり8タスク、メッセージサイズ約10 K、250列）環境で、V3とV4のベンチマークテストを実施しました。このデータから、サーバー側のアーキテクチャへの進化によって、パフォーマンスの限界をかつてないほど押し上げられる理由が明確にわかります。

CPU使用率のチャートは、V4がこのスケールをどのように達成しているかを正確に示しています。パーティションあたり8 MB/秒のしきい値では、V3はデータ変換とシリアル化に追いつくために、利用可能なコンピュートリソースを最大化し、CPU使用率が96%に達します。一方、V4はわずか33%のCPU使用率でこの同じワークロードを処理し、メモリ消費量も大幅に抑えられます。これは、大規模な運用を行う組織にとって、クライアントインフラストラクチャの大幅なコスト削減につながることを示しています。

なぜこれほど大きな違いが生じるのでしょうか。第一に、V4 SDKはこれまでの取り組みを基盤とし、高度に最適化された共有Rustコアを導入しています。V3の純粋なJava実装から移行することで、クライアントのフットプリントが縮小します。これにより、CPU使用率の低下、メモリ要件の軽減、Javaガベージコレクション（GC）の負荷解消が実現します。これは、Kafka Connectワーカーの小型化と、運用するインフラストラクチャの無駄の削減に直結します。

第二に、V4はSnowflake PIPEオブジェクトを活用して、処理をサーバー側へ移行します。クライアント側での変換にワーカーのコンピュートを利用する代わりに、V4は単に行データを配信します。データが到着すると、Snowflakeはインフライトのクラスタリング、列名の変更、型のキャスト、レコードのフィルタリングをネイティブかつ自動的に処理します。クライアント側のオーバーヘッドを一切追加することなく、適切にクラスタリングされた最新のデータに対してクエリをより高速に実行できます。

価格と効率性

KafkaコネクタV4は、Snowpipe Streamingのスループットベースの価格モデルを利用しています。Snowflakeのエディションに応じて、取り込まれた非圧縮データ1 GBあたり0.0037クレジット（約0.01ドル）の料金が発生します。最新の価格については、Snowflakeサービス利用テーブルをご覧ください。これは、サーバーレスコンピュートとクライアント接続に関連付けられていた従来のクレジットベースのモデルに代わるものです。コストの予測がより容易になり、見通しが立てやすくなります。

KafkaコネクタV3から移行すると、価格モデルが変更されます。クライアント側のリソース節約、クラスタリングされたデータでのクエリパフォーマンスの向上、および個別の処理ステップを排除するインフライト変換はすべて、総保有コストの削減に貢献します。

コスト削減が最も具体的に現れるのは、クライアント側です。KafkaコネクタV4のRustコアとサーバー側の処理により、Kafka Connectワーカーに必要なリソースが大幅に削減されます。あるお客様からは、クライアント側のコストが最大30%削減されたと報告されています。インスタンスの小型化、ワーカー数の削減、インフラストラクチャ支出の削減などが要因です。

エラーログによるエラー処理

サーバー側の処理により、失敗したレコードのトラブルシューティング方法が変わります。KafkaコネクタV3では、失敗したレコードのトラブルシューティングを行うには、分散インフラストラクチャ全体でクライアントログとKafka Connectワーカーの出力を検索する必要がありました。KafkaコネクタV4のサーバー側の検証では、失敗したレコードはSnowflake内のSQLでクエリ可能なエラーテーブルに格納されます。エラーメッセージ、オフセット、タイムスタンプ、チャネルコンテキストなど、問題の診断に必要なすべての情報にSELECTクエリでアクセスできます。トラブルシューティングは、分散ログの調査からSQLコンソールでの作業へと移行します。

サーバー側の検証により、型チェックは完全にSnowflake側で処理されます。詳細なエラーコードとリアルタイムのチャネルステータスを取得できます。

Kafkaネイティブのエラールーティングを好むチーム向けに、DLQを使用したクライアント側の検証にも引き続き完全に対応しています。KafkaコネクタV3と同じ構成、同じ動作です。既存のパターンを維持しつつ、準備が整った段階でサーバー側のエラーテーブルを採用できます。パイプラインに合ったものを選択できますが、ほとんどのチームにとってエラーテーブルが今後の標準的なアプローチとなります。

移行：KafkaコネクタV4への3つのステップ

特に数百のトピックにわたって数十のコネクタを実行している場合、移行は重大な決断であることを私たちは理解しています。そのため、移行を中核に据えてKafkaコネクタV4を構築しました。

新しいコネクタのバージョンとクラス（KafkaコネクタV3のSnowflakeSinkConnectorではなくSnowflakeStreamingSinkConnector）に更新することで、アップグレードできます。移行に対応した互換性設定が標準で提供されており、KafkaコネクタV3の動作を再現するため、最小限の変更で実行を開始できます。

KafkaコネクタV4はデフォルトでスキーマ化された取り込みを行い、各JSONキーが独自のテーブル列にマッピングされます。これはよりパフォーマンスが高く、推奨される方法です。KafkaコネクタV3のデフォルトである2列モード（VARIANT型としてのRECORD_CONTENTおよびRECORD_METADATA）を維持する場合は、snowflake.enable.schematization=falseを設定します。

移行プロセスは段階的です。

1. 新しいコネクタクラスを使用してKafkaコネクタV4に更新し、上記の互換性フラグを適用します。
2. 非本番環境で既存のデータを使用してテストします。
3. サーバー側の検証、ネイティブの列の命名など、KafkaコネクタV4のデフォルトを1つずつ採用します。

シームレスに移行できます。KafkaコネクタV4は、選択した構成に基づいてオフセットの回復を処理します。データの整合性と1回限りの提供は、全体を通じて維持されます。既存のテーブルは引き続き機能し、段階的なロールアウト中に異なるトピックでKafkaコネクタV3とKafkaコネクタV4を並行して実行できます。

Cortex Codeを使用して移行を自動化することもできます。Custom Kafka Consumer Cortex Codeスキルを使用すると、セットアップ、実行、デバッグを数分で完了できます。開始するには、Cortex Codeでkafka consumer or kafka to snowflakeと入力します。

使用を開始する

KafkaコネクタV4は本日より一般提供されています。KafkaコネクタV4はMavenで利用可能であり、ConfluentプラットフォームやAmazon Managed Streaming for Apache Kafka（Amazon MSK）を含むApache Kafka 2.xおよび3.xと互換性があります。クライアント側の検証モードによるスキーマレジストリの統合をサポートしており、Java 11以降が必要です。パートナーと協力して、パートナーのマネージドKafka ConnectサービスにKafkaコネクタV4を含めるように取り組んでいます。

Cortex Codeスキルを実際に試す

Cortex Codeには、Snowpipe Streaming専用に構築された3つのスキルが標準で用意されており、セットアップから本番環境のパターンまで数分で完了できます。GitHubですべてのCortex Codeスキルを確認できます。

現在の制限事項の包括的なリストについては、KafkaコネクタV4のドキュメントを参照してください。

• Snowpipe Streamingの高性能アーキテクチャの概要
• KafkaコネクタV4ドキュメント
• 移行ガイド：KafkaコネクタV3からKafkaコネクタV4へ
• 料金の詳細：よりインタラクティブな体験をご希望の場合は、クラウドプロバイダー、コンピュート、ストレージ、AIの使用量を考慮してアカウントの現在のコストを見積もるのに役立つオンラインツール、Snowflake Pricing Calculatorをお試しください。