G-gen の佐藤です。当記事では、BigQuery から外部ストレージを参照する2つの構成、従来の外部テーブルと BigLake テーブルの違いを検証した結果を紹介します。 はじめに BigLake とは 検証方法 検証環境の構築 Cloud Storage 外部テーブルと BigLake テーブル 検証1. 列レベルのアクセス制御 概要 外部テーブルの場合 BigLake テーブルの場合 検証2. 行レベルのセキュリティ 概要 外部テーブルの場合 BigLake テーブルの場合 検証3. パフォーマンス比較 概要 メタデータキャッシュの更新 クエリの実行 ジョブ詳細の確認 はじめに BigLake とは BigLake とは、Google Cloud が提供する分析用データベース BigQuery で、アクセス権限の委任を使用して、BigQuery 外部のストレージにあるデータをクエリするための仕組みです。BigLake の仕組みで作成されたテーブルは BigLake テーブルと呼ばれ、外部テーブルの発展系とされています。 参考 : BigLake 外部テーブルの概要 BigLake の概要については、以下の記事も参考にしてください。 参考 : BigQueryを徹底解説！(応用編) - G-gen Tech Blog - BigLake 検証方法 BigLake テーブルの中でもメタデータキャッシュの効果が高いとされる Hive パーティショニング 構成を用いて、外部テーブルと BigLake テーブルを1つずつ作成します。 参考 : 外部でパーティションに分割されたデータを使用する それぞれのテーブルが、「セキュリティ（アクセス制御）」と「パフォーマンス（スキャン量）」においてどのような挙動の差を示すかを検証します。具体的には、以下の3点に着目しました。 観点 概要 列レベルのアクセス制御 データカタログのポリシータグを付与し、アクセス制御が可能か 行レベルのセキュリティ CREATE ROW ACCESS POLICY 文によるフィルタリングが適用できるか クエリパフォーマンス メタデータキャッシュによって、スキャン量（処理されたバイト数）がどの程度削減されるか 検証環境の構築 Cloud Storage 検証のため、Cloud Storage バケットを用意します。その中にフォルダ構成を作成して、CSV ファイルを配置します。 当検証では、Hive パーティショニング分割テーブルを作成するために、日付ごとにフォルダを分割しました。各フォルダ内には、1ファイルあたり約70 KB の CSV ファイルを100個、用意しました。 gs://biglake-connect-test/ └ datasets/ └ hive_partitioned/ ├ dt =2026-03-25/ │ ├ sample_data_0.csv │ ├ sample_data_1.csv │ └ ... ├ dt =2026-03-26/ │ ├ sample_data_0.csv │ ├ sample_data_1.csv │ └ ... └ dt =2026-03-27/ ├ sample_data_0.csv ├ sample_data_1.csv └ ... 参考 : 外部でパーティションに分割されたデータを使用する 外部テーブルと BigLake テーブル 外部テーブルと BigLake テーブルを作成します。どちらのテーブルも、同じ Cloud Storage パスを参照しています。DDL は以下のとおりです。 従来の外部テーブル CREATE EXTERNAL TABLE `project_id.dataset_id.external_table` WITH PARTITION COLUMNS ( dt DATE , ) OPTIONS ( hive_partition_uri_prefix = " gs://biglake-connect-test/ " , uris=[ ' gs://biglake-connect-test/* ' ], format = " CSV " ); BigLake テーブル CREATE OR REPLACE EXTERNAL TABLE `project_id.dataset_id.biglake_table` WITH PARTITION COLUMNS ( dt DATE , ) WITH CONNECTION `project_id.asia-northeast1.sample_gcs_connect` OPTIONS ( hive_partition_uri_prefix = " gs://biglake-connect-test/ " , uris=[ ' gs://biglake-connect-test/* ' ], max_staleness = INTERVAL 4 HOUR, metadata_cache_mode = ' MANUAL ' , -- 今回は手動でメタデータを更新する format = " CSV " ); 参考 : パーティション分割テーブルに外部テーブルを作成する 参考 : Cloud Storage 用の BigLake 外部テーブルを作成する 検証1. 列レベルのアクセス制御 概要 BigQuery には特定の列に対してアクセス制限をかける 列レベルのアクセス制御 機能があります。この機能では、ポリシータグと呼ばれるタグを、テーブルの列に適用することでアクセス制御を実現します。 外部テーブルと BigLake テーブルのそれぞれに対して、スキーマ編集画面からポリシータグを適用できるかを確認します。 参考 : 列レベルのアクセス制御の概要 参考 : BigQueryの列レベルのアクセス制御・行レベルのセキュリティを解説 - G-gen Tech Blog 外部テーブルの場合 外部テーブルの場合、Google Cloud コンソール画面の BigQuery テーブルのスキーマ編集画面にポリシータグを追加するボタンが表示されず、ポリシータグを設定できないことがわかります。 外部テーブルのスキーマ編集画面 BigLake テーブルの場合 BigLake テーブルには、同じ画面に Add policy tag ボタンが表示されており、ポリシータグを追加できることがわかります。 BigLake テーブルのスキーマ編集画面 検証2. 行レベルのセキュリティ 概要 行レベルのセキュリティ は、Google アカウントやグループが、特定の値を持った行にだけアクセスできるように制御する機能です。この機能では、アクセスポリシーという設定を、テーブルに適用することで有効化します。 外部テーブルと BigLake テーブルのそれぞれに対して、アクセスポリシーを定義する SQL が実行できるかを検証します。 参考 : BigQuery の行レベルのセキュリティの概要 参考 : BigQueryの列レベルのアクセス制御・行レベルのセキュリティを解説 - G-gen Tech Blog 外部テーブルの場合 外部テーブルに対してアクセスポリシーを作成する SQL を実行しようとすると、サポートされていない旨の警告が表示されます。 外部テーブル BigLake テーブルの場合 BigLake テーブルの場合は、同様の SQL が問題なく実行できます。 BigLake テーブル 検証3. パフォーマンス比較 概要 BigLake テーブルは、メタデータキャッシュを利用して外部ファイルの情報を事前に把握することで、不要なスキャンを最小限に抑えるプルーニングを効率化します。この仕組みによって具体的にどれほどの差が生じるのか、実測データをもとに確認します。 参考 : パフォーマンス向上のためのメタデータ キャッシュ メタデータキャッシュの更新 以下の SQL を実行して、BigLake テーブルのメタデータキャッシュを手動で更新します。 CALL BQ.REFRESH_EXTERNAL_METADATA_CACHE( ' project_id.dataset_id.biglake_table ' ); 参考 : BQ.REFRESH_EXTERNAL_METADATA_CACHE クエリの実行 外部テーブルと BigLake テーブルのそれぞれに対して、日付パーティションを指定してフィルタリングを行う以下のクエリを実行しました。 SELECT COUNT (*) , dt FROM `project_id.dataset_id.table_name` WHERE dt = ' 2026-03-26 ' GROUP BY dt; ジョブ詳細の確認 外部テーブルの場合 外部テーブル BigLake テーブルの場合 BigLake テーブル 従来の外部テーブルに対して、BigLake テーブルでは、スロット時間は 約58分の1 、処理されたバイト数は 約98分の1 まで減少しました。 日付ごとのフォルダの中には約7 MB の CSV が格納されているため、従来の外部テーブルでもパーティショニングが効果を発揮しており、特定のフォルダ内のファイルのみが読み込まれていることがわかります。しかし BigLake テーブルの場合、追加のメタデータキャッシングにより、必要最小限のファイルのみが読み込まれていることがわかります。 佐藤 孝俊 (記事一覧) クラウドソリューション部 2026年3月にG-gen にジョイン。 スノーボードにより鎖骨骨折中。

はじめに こんにちは。ニフティの山田です。 AWSを利用するうえで、S3を使うことは多いと思います。静的ファイル配信のみならず、アプリケーションから参照されることも多いでしょう。このようなアプリケーションの動作確認やテストの上では、ローカル環境で動くS3エミュレータがあると便利です。 しかし、従来有力だった以下の2つはいずれも無償提供が実質終了してしまいました。 MinIO: Web UI機能が削除され、バイナリ提供が終了したため、実質的にOSS版は終了 Web UI機能削除： https://github.com/minio/object-browser/pull/3509 バイナリ提供終了： https://github.com/minio/minio/pull/21625 localstack for AWS: 利用にはlocalstackアカウントの発行と認証が必要となり、CIでの実行には有償契約が必須 告知: https://blog.localstack.cloud/the-road-ahead-for-localstack/ そこで今回はこの代替となるものを探してみました。 移行先 Dockerイメージでサーバを立てることができ、複数コンテナの連携や複雑な初期化が必要ないものを選択します。 S3Mock SeaweedFS RustFS イメージ名 abode/s3mock chrislusf/seaweedfs rustfs/rustfs 言語 Java Go Rust GitHub Stars 1,031 29,900 20,900 Web GUI × ◯ ◯ path-style access ◯ ◯ ◯ virtual-hosted-style access × × × バケット基本操作 ◯ ◯ ◯ オブジェクト基本操作 ◯ ◯ ◯ ListObjectsV2 ◯ ◯ ◯ multipart upload ◯ ◯ ◯ タグ ◯ ◯ ◯ 署名付きURL △(署名を無視) ◯ ◯ sigv4auth × ◯ ◯ バケットポリシー × ◯ ◯ バージョニング ◯ ◯ ◯ ライフサイクルポリシー × △(TTL設定のみ) ? CORS × ◯ ? 表は公式ドキュメントを参照したものであり、すべての機能を検証したわけではない点にご留意ください。 S3Mock 文字通りテストなどで利用するS3のモック用途で作られたものです。Testcontainersでの利用も公式に想定されています。 GitHub でAPIごとのサポート状況がリストアップされている点も親切です。 docker composeでの起動例は以下の通りです。 services: s3mock: image: adobe/s3mock:4.11.0 environment: - COM_ADOBE_TESTING_S3MOCK_STORE_RETAIN_FILES_ON_EXIT=true - COM_ADOBE_TESTING_S3MOCK_STORE_ROOT=data - COM_ADOBE_TESTING_S3MOCK_STORE_INITIAL_BUCKETS=my-bucket ports: - 9090:9090 volumes: - s3mock-data:/data volumes: s3mock-data テスト用だけあってデフォルトだと終了時にデータ消去が走ってしまいますが、環境変数で永続化が可能です。また自動作成するバケット名を環境変数で設定できる点が便利です。 Pros エラーレスポンスなど、S3の挙動再現には最も期待できる Cons 署名など高度機能には対応していない Web GUIはない SeaweedFS 分散ストレージOSSの一つです。FUSE、Hadoopなど多くのプロトコルに対応しており、S3互換APIも備えています。 分散システムだけあってMaster・Volume・Filerなど複数コンポーネントから構成されていますが、S3をシングルノードで起動するだけなら以下でできます。 services: seaweedfs: image: chrislusf/seaweedfs:4.09 ports: - 8333:8333 # S3 API - 8888:8888 # Filer UI - 9333:9333 # Master UI command: ["server", "-s3", "-dir=/data", "-ip=0.0.0.0"] volumes: - seaweedfs-data:/data volumes: seaweedfs-data: 上記設定だと無認証でアクセス可能です。簡易的ですがUI(上記のFiler UI)も備わっています。 Pros S3の高度機能にもある程度対応している Web GUIがあるので確認はしやすい Cons 分散システムであるため、構成要素は多い 不具合があった際のデバッグは難しい あくまでもS3互換であるため、エラーレスポンスなど細かいとことで違いが出る可能性がある RustFS 同じく分散ストレージOSSです。…とはいえまだアルファ版でありシングルノードでしか動作しません。MinIOの代替を目指している模様です。 docker composeでの起動方法は以下の通りです。 services: seaweedfs: image: rustfs:rustfs:1.0.0-alpha.82 environment: - RUSTFS_ACCESS_KEY=rustfsadmin - RUSTFS_SECRET_KEY=rustfsadmin - RUSTFS_CONSOLE_ENABLE=true ports: - 9000:9000 # S3 API - 9001:9001 # Admin UI volumes: - rustfs-data:/data volumes: rustfs-data:   アクセスキー・シークレットが必須となります。(デフォルトはrustfsadmin/rustfsadmin) Web GUIへのアクセスにも必要です。 OpenTelemetryにも対応しているらしく、docker composeの サンプル が用意されています。 Pros Web GUIを持ち、SeaweedFSよりモダンなデザイン Cons まだalpha版 ドキュメントがあまり詳細でない 認証トークンをハードコード して CVSS 9.8 の脆弱性を出したことがある 結論 個人的には テスト(Testcontainer)用 S3Mock docker compose用 GUI不要なら: S3Mock GUI必要なら: SeaweedFS で良いのではないかと思っています。localstackほどの機能網羅性はありませんが、単純なCRUDL用途であれば実用に耐えるでしょう。私の担当プロダクトでは規模の小さいものからS3Mock/SeaweedFSへの置き換えを行っています。 Tips: 初期化方法 ローカル実行時やテスト開始時など、バケット作成・初期データ投入を自動的に行いたいケースがあります。 locakstackでは特定ディレクトリにhookスクリプトを置いておくと自動実行される機能がありましたが、上記のいずれもその機能はありません。(S3Mockのみ、バケット作成は自動実行可能) 初期化したければ、別途初期化用のコンテナを用意することになります。 ex) SeaweedFSに対してバケット作成、初期データ投入 seaweedfs: image: chrislusf/seaweedfs:4.09 ports: - 8333:8333 # S3 API - 8888:8888 # Filer UI - 9333:9333 # Master UI command: ["server", "-s3", "-dir=/data", "-ip=0.0.0.0"] volumes: - seaweedfs-data:/data healthcheck: test: ["CMD", "wget", "-q", "--spider", "http://localhost:8333"] interval: 5s timeout: 5s retries: 10 seaweedfs-init: image: amazon/aws-cli:2.33.15 depends_on: seaweedfs: condition: service_healthy environment: AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_DEFAULT_REGION: ap-northeast-1 volumes: - ./mock-contents/data:/data:ro entrypoint: /bin/sh command: - -c - | aws --endpoint-url http://seaweedfs:8333 s3 mb s3://seaweedfs || true aws --endpoint-url http://seaweedfs:8333 s3 sync /data/ s3://seaweedfs/ echo "Initialization complete" 初期化処理を行うコンテナ(上記のaws-cliコンテナ)を用意し、そこで初期化処理を実行する 上記ではバケット作成とs3 syncで初期化している depends_onで起動順の制御が必要 プロセスの起動完了後に実行される必要があるため、S3コンテナ側にヘルスチェックの設定が必須 その他の選択肢 分散ストレージ Ceph Garage Zenko など、S3互換APIを持つストレージOSSは他にもありますが、分散化を前提としておりセットアップが複雑です。ローカル・テスト用で使うには不向きかもしれません。 プロキシ S3Proxy APIだけを提供し、他のストレージバックエンド(Google Cloud Storageなど)に対するプロキシとして機能するものです。 ファイルシステムバックエンドがあるので単独でも使えそうではありますが未検証です。 AWS SDKモック moto (python) aws-sdk-client-mock (JavaScript) ユニットテスト用途であれば昔ながらの方法に立ち戻り、S3互換サーバを立てるのではなく、AWS SDKをモック化することで対応可能です。SDKレスポンスの再現度という点では最も力が入っています。 ただしテスト時にしか使えないので、ローカルPC上で環境を再現する用途には不向きです。また、複数アプリケーションを起動してのテストにも対応できません。 インメモリモック gofakes3 (Go) インメモリでS3互換サーバを立てるものです。SDKモックとは異なりますが、テスト用途であり、やはり環境再現などには使えません。 おわりに 今回は、ローカルS3エミュレータの代替となるサービスについて解説しました。 参考になれば幸いです。  

2025/10/7～9 に、アメリカのシアトルで開催された Airflow Summit というイベントに参加・登壇してきました。この記事では印象に残ったセッションを中心に、イベントの模様を共有します。 Airflow Summit とは オープンソースのワークフロー管理ソフトウェアとしては、おそらく最大級の知名度と導入実績を持つであろう Apache Airflow に関する、コミュニティ主催の年次イベントです。 2020年から毎年開催されており、前回 (2024年) は3日間で参加者650名、登壇者142名、105セッションという規模で開催されました。 今回は2025/4に、20