【Snowflakeコミュニティリーダー実践知】データ基盤IaC化とCursor活用で脱属人化！

ベンダーロックインをどう突破した？ Icebergで持続可能なコスト構造に

　グループ間でのデータ共有を阻んでいた大きな要因の一つがベンダーロックイン。特定の部署だけでクローズドなプラットフォームを利用していると、他のチームからデータへアクセスすることが難しくなります。

　そこで私たちは、データプラットフォームの中にデータを閉じ込めるのではなく、どのツールからでもアクセス可能なオープンな場所にデータを配置し、相互に活用できるようにする環境づくりを進めてきました。これを実現するために採用したのが、オープンテーブルフォーマットである「Apache Iceberg（以下、Iceberg）」。データを特定ベンダー固有のフォーマットではなく、Icebergの形式で保持することでベンダーロックインを防ぎ、Snowflakeや他のツール／システムからも直接データへアクセスできるよう取り組んでいます。これにより、特定のプラットフォームに縛られることなく、グループ全体のデータを繋ぐオープンな基盤の土台が出来上がります。

　数あるオープンテーブルフォーマットの中で、私たちがIcebergを選んだ理由は大きく2つあります。1つ目は、グループ全体でのコラボレーションのしやすさです。

　前述の通り、当社グループは多様な事業とそれを担う多くのグループ会社で構成されています。各社／各部署がそれぞれ異なるツールやエンジンでデータを扱う中で、特定ベンダー固有のフォーマットにデータを閉じ込めてしまうと、その時点でグループ横断の活用は難しくなります。

　その点、IcebergはSnowflakeはもちろん、他のクエリエンジンやBIツールからも同一のデータへ直接アクセスできる“共通言語”として機能します。データを一度Iceberg形式でオープンな場所に置いておけば、どの会社／どのチームが、どのツールを使っていても同じデータを参照できる。この「多様なエンジンが使える」という特性こそが、グループ会社が多く、横断的なコラボレーションを前提とする当社にとって、Icebergを選ぶ決め手となりました。

　2つ目は、コスト最適化の観点です。データ量が比較的少ない企業にとって、Icebergはあまり関係ないと思われるかもしれませんが、Icebergの価値はデータ量の大小だけで測れるものではありません。

　まず、データの取り込み（Ingestion）の面でコストメリットがあります。従来はデータを使うツールごとにCOPY INTOでロードし直す必要があり、そのたびにSnowflakeのウェアハウス（コンピュートリソース）を動かしていました。Snowflakeのコストは大部分をウェアハウスが占めるため、これは無視できない負担です。データをIceberg形式で1ヵ所に持てば、ツールごとの重複ロードが不要になり、取り込みのためにウェアハウスを動かす回数そのものを減らせます。

　さらに、データマート層をSnowflakeのManaged Icebergとして持つことで、Snowflakeの優れたガバナンスレイヤー（Open Catalog）による一元的な権限・カタログ管理を効かせつつ、BIなどの軽量なクエリはDuckDBのような別のエンジンに流すといった使い分けも可能になります。適材適所でエンジンを選べることが、そのままコスト最適化に直結するのです。

　このように、Apache Icebergは「グループ全体をオープンにつなぐ」という当社の目指す姿と、「持続可能なコスト構造」という現実的な要請の双方に応えられる技術基盤です。だからこそ、私たちはIcebergをオープンなデータ基盤の中核に据えることを選びました。

運用属人化の突破口：GUI運用の脱却とIaC化

　技術アーキテクチャを刷新しても、それを動かす組織の運用体制が属人化していては事業の拡大スピードに対応できません。私がGA technologiesに入社した際、当社のSnowflake基盤は既に何千ものリソースが作成・活用されている大規模なものであった一方で、リソース管理は画面操作（GUI）で行われている状況でした。

　GUIによる運用は一見手軽ですが、事業と組織が拡大するにつれ、以下のような課題を引き起こします。

• 運用管理の属人化：特定の担当者しか知らない設定・手順が存在し、離職や異動によりナレッジが失われてしまう
• 本番環境での障害リスク：ユーザーが利用中の本番環境へ直接変更を加えるため、本番環境で予期せぬ障害が起きる可能性がある
• コードレビューの不在：他メンバーによる相互チェックが行われないため、設定ミスや誤操作に気づけない
• 環境を再現しづらい：同じ構成を正確に再現することが困難で、再現する際は手作業で行う必要があるため、人的コストとミスのリスクが増大する

　このような課題を解決するため、私たちはSnowflakeにTerraformを導入し、IaC（Infrastructure as Code）化することを決断しました。また、データの取り込み（Ingestion）においても、パイプラインをPythonコードとして標準化・管理できる「dlt（data load tool）」を活用することで、難易度の高いデータ連携にもチーム全体で対応できるエンジニアリング環境を整えることにしました。