Google Sheets から Snowflake を参照するアドオンの実行基盤を Snowflake Tasks に移行した

## はじめに こんにちは、LayerX バクラク事業部 BizOps 部データグループの平田 (@TrsNium) です。 以前、[Google Apps Script で Snowflake と Google Sheets を連携するアドオンを開発した話](https://tech.layerx.co.jp/entry/2024/12/19/110340)という記事で、Google Apps Script (GAS) を使って Snowflake と Google Sheets を連携するアドオンを開発した話をしました。このアドオンは、BigQuery の Connected Sheets のような体験を Snowflake でも実現するために作られたもので、UI からのオンデマンド実行やスケジュール実行、パラメータ設定など、データ分析に必要な機能を一通り実装していました。 このアドオンは、ビジネス職のメンバーを中心に社内で幅広く使われています。予実管理や KPI (Key Performance Indicator: 重要業績評価指標) のトラッキングはもちろん、SQL を書けないビジネス職のメンバーも、設定済みのクエリを選ぶだけで最新データを取得できます。手軽で共有しやすく、スケジュール機能で自動更新もできるため、データ分析と業務効率化に役立っていました。 しかし利用が広がるにつれ、GAS のタイムアウトや実行枠の制限が壁になり、ユーザー体験を損なう場面が増えました。そこで、GAS から脱却し Snowflake ネイティブな実行基盤に作り直すことにしました。本記事では、その設計・実装・成果を紹介します。 ## GAS 制限とユーザー体験について ## GAS の制限について GAS には利用形態ごとに異なるタイムアウトと実行枠の制限があります ([Quotas for Google Services](https://developers.google.com/apps-script/guides/services/quotas))。 - UI 実行 (google.script.run を経由): 30 秒でタイムアウト。ユーザーがボタンをクリックして実行するケースがこれに該当し、少しでも重いクエリは完了前に打ち切られる - スケジュール実行 (時間主導型トリガー): 30 分でタイムアウト。重いクエリでも実行できるが、即時性がない - 1 日の総実行時間: ユーザーあたり 6 時間/日（Google Workspace アカウントの場合）。ユーザーあたりのスケジュール数にも上限があり、KPI のトラッキングなどで頻繁に利用するユーザーはすぐに上限に達してしまう。その回避策としてマシンアカウント 1 つにスケジュール実行を集約していたが、今度はそのアカウントの 6 時間枠を全ジョブで共有することになり、重いジョブが枠を消費すると他のスケジュールが実行できなくなる - 同時実行数: スクリプトあたり 30 実行まで。利用者が増えるとピーク時にジョブが詰まる 最大の問題は、UI 実行の 30 秒制限です。ユーザーがクエリ実行ボタンを押すと、裏側では google.script.run を経由で GAS が呼ばれますが、この経路に 30 秒のタイムアウトがあります。少し重いクエリや集計テーブルを使う分析では、Snowflake 側で結果の準備が終わる前に処理が打ち切られ、Google Sheets には何も書き込まれません。利用者から「動かない」「同期できない」という問い合わせが多く寄せられました。 回避策としてスケジュール実行を案内していました。スケジュール経由なら重いクエリも完了しますが、これでは Google Sheets 本来の価値が損なわれます。データを見て疑問を持ち、条件を変えてすぐ再実行する — この高速なフィードバックループこそが、Google Sheets でデータ分析を行う中心的な価値だからです。スケジュール登録して次回実行を待つ運用ではサイクルが遅くなり、「ちょっと見てみよう」の気軽さが失われます。 この問題を解決するために、GAS の制限から脱却した新しい実行基盤の検討を始めました。 ## アーキテクチャ選定の思考プロセス ## Option A: AWS 構成 社内の既存インフラが AWS ベースのため、最初に AWS を使った基盤構築を検討しました。API Gateway、ECS、SQS、Step Functions、DynamoDB など、AWS のマネージドサービスを組み合わせてスケーラブルなジョブ実行基盤を作るというアプローチでした。 外部サービス AWS Backend (8+ サービス) クライアント層 POST /jobs enqueue state RunTask Snowflake Google Sheets API API Gateway ECS: Job API SQS (ジョブキュー) Step Functions ECS Task (Runner + Writer) DynamoDB (状態管理) EventBridge (スケジューラ) Google Sheets Add-on UI Apps Script (Minimal Shim) Step Functions でワークフローを可視化でき、SQS で柔軟なキューイングを実現でき、ECS でスケーラブルな実行環境を構築できます。事業が成長し、コネクタの利用が増えても対応できる基盤です。しかし、実装期間、運用コスト、そしてアーキテクチャ上の課題があります。 まず、ユーザーが日常的に GAS の制限に直面している状況で、基盤構築に時間をかける余裕はありませんでした。AWS 構成ではインフラ構築、認証実装、ジョブ管理システムなど、実装に相応の時間がかかる見込みでした。 ## Option B: Snowflake ネイティブ構成 アーキテクチャの複雑さを減らすため、AWS を使わない構成を検討しました。データはすべて Snowflake 上にあり、処理も同じ基盤で完結できる可能性があります。調査を進めると、Snowflake には Tasks によるジョブ管理、Python Stored Procedure による外部 API 呼び出し、External Access Integration による外部連携といった機能が備わっていることが分かりました。これらを組み合わせれば、AWS を介さず Snowflake 単体で完結する構成を実現できます。 以下の図は、Snowflake ネイティブ構成の全体像を示したものです（実際の Task などの詳細は後述します）。 Snowflake (単一プラットフォーム) 手動実行 参照 ジョブ投入 パラメータ取得 Tasks 層**スケジューリング Catalog 層 メタデータ管理 Orchestration 層 ジョブ制御 Core 層 実行エンジン Google Sheets Google Sheets API Snowflake ネイティブ構成では、AWS 構成で必要だった 8 つ以上のサービスを Snowflake 内部の機能だけで実現します。レイヤー構成の詳細は後述します。 ## 共通の懸念：Google Sheets API Quota どちらの構成を選ぶにしても、Google Sheets API の Quota 制限という問題がありました。 GAS 以外の基盤に移行する場合、Google Sheets API の write requests のデフォルト quota がボトルネックになる可能性があります。AWS 構成でも Snowflake 構成でも同じです。この制限が緩和されなければ、GAS のタイムアウト問題を解決しても、結局別の制約に引っかかってしまいます。 そこで事前に Google Cloud へ Quota 増加リクエストを提出したところ、承認されて Quota 制限が大幅に緩和されました。 ## 意思決定のポイント 最終的に、以下の 2 つの観点で Snowflake 構成を選択しました。 ## 1. 実装速度 Snowflake の組み込み機能で要件 (定期実行・パラメータ設定・オンデマンド実行) を満たせるため、AWS 構成のようにインフラやミドルウェアを個別構築する工数が不要になります。基盤構築に時間をかけず、ユーザー課題に集中できる点が決め手でした。 ## 2. 運用・スキルセットとの相性 データチームのコアスキルセットは SQL、dbt、Snowflake です。SQL と Python で完結する Snowflake 構成なら、新メンバーのキャッチアップも容易です。また、QUERY_HISTORY と TASK_HISTORY でログを一元管理でき、デバッグも単一クエリログで完結します。 ## レイヤー構成 全体は4つのレイヤーで構成されています。 レイヤー 役割 主なコンポーネント Tasks スケジューリング scheduler_tick, ingest_job_requests_task, run_pending_jobs_task, check_failed_schedules_task Catalog メタデータ管理 QUERY_CATALOG, QUERY_SCHEDULES, SPREADSHEET_PARAMETERS Orchestration ジョブ制御 JOB_REQUESTS, JOB_STATE, JOB_REQUESTS_STREAM Core 実行エンジン EXECUTE_JOB, WRITE_QUERY_TO_SHEET Tasks 層**: scheduler_tick が5分間隔でスケジュール対象を取り込み、check_failed_schedules_task が1日1回連続失敗を検知してスケジュールを自動停止します。オンデマンド実行は専用の Task を持たず、UI から JOB_REQUESTS に直接 INSERT します。 **Catalog 層**: QUERY_CATALOG にクエリ定義、QUERY_SCHEDULES にスケジュール設定、SPREADSHEET_PARAMETERS にパラメータ設定を格納します。 **オーケストレーション層**: JOB_REQUESTS にリクエストが投入されると、JOB_REQUESTS_STREAM (CDC) が変更を検知し、ジョブを JOB_STATE へエンキューします。 **コア層**: EXECUTE_JOB がジョブを受け取り、WRITE_QUERY_TO_SHEET (Python Stored Procedure) を介して Snowflake クエリの実行と Google Sheets への書き込みを行います。 ## ジョブ実行フロー 実際のジョブ実行フローは以下の通りです。スケジュール実行とオンデマンド実行のどちらも、同じ仕組みで動作します。 📊 Google Sheets⚙️ Python Stored Procedure📥 Job Queue📚 Catalog⏰ Snowflake Tasks👤 ユーザー📊 Google Sheets⚙️ Python Stored Procedure📥 Job Queue📚 Catalog⏰ Snowflake Tasks👤 ユーザー<circle cx=

Google Sheets から Snowflake を参照するアドオンの実行基盤を Snowflake Tasks に移行した

背景や根拠まで確認しますか？

調べる

選ぶ

サイト