はじめに こんにちは。ニフティの山田です。 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

本記事は 2024 年 12 月 3 日 に公開された「 Introducing AWS Glue Data Catalog automation for table statistics collection for improved query performance on Amazon Redshift and Amazon Athena 」を翻訳したものです。 AWS Glue Data Catalog で、新しいテーブルの統計情報を自動的に生成できるようになりました。これらの統計情報は Amazon Redshift Spectrum と Amazon Athena のコストベースオプティマイザー (CBO) と統合され、クエリパフォーマンスの向上とコスト削減につながります。 大規模なデータセットに対するクエリは、大量のデータを読み取り、複数のデータセット間で複雑な結合操作を実行することがよくあります。Redshift Spectrum や Athena などのクエリエンジンがクエリを処理する際、CBO はテーブル統計を使用してクエリを最適化します。例えば、CBO がテーブル列の個別値の数を把握していれば、最適な結合順序と戦略を選択できます。これらの統計情報は事前に収集し、最新のデータ状態を反映するように更新し続ける必要があります。 これまで、Data Catalog は Parquet、ORC、JSON、ION、CSV、XML 形式のテーブルに対して、Redshift Spectrum と Athena の CBO で使用されるテーブル統計の収集をサポートしてきました。この機能とそのパフォーマンス上のメリットについては、 Enhance query performance using AWS Glue Data Catalog column-level statistics で紹介しています。また、Data Catalog は Apache Iceberg テーブルもサポートしています。これについては Accelerate query performance with Apache Iceberg statistics on the AWS Glue Data Catalog で詳しく説明しています。 これまで、Data Catalog で Iceberg テーブルの統計を作成するには、テーブルの設定を継続的に監視および更新する必要がありました。以下のような差別化につながらない重労働が必要でした: 特定のデータテーブル形式 (Parquet、JSON、CSV、XML、ORC、ION など) や Iceberg などのトランザクショナルデータテーブル形式を持つ新しいテーブルと、それぞれのバケットパスを検出する スキャン戦略 (サンプリング率とスケジュール) に基づいてコンピューティングタスクを決定し、セットアップする 特定のタスクに対して AWS Identity and Access Management (IAM) と AWS Lake Formation のロールを設定し、特定の Amazon Simple Storage Service (Amazon S3) アクセス、 Amazon CloudWatch ログ、CloudWatch 暗号化用の AWS Key Management Service (AWS KMS) キー、信頼ポリシーを提供する データレイクの変更を把握するためのイベント通知システムをセットアップする オプティマイザー設定に基づくクエリパフォーマンスとストレージ改善戦略をセットアップする スケジューラーをセットアップするか、セットアップとティアダウンを含む独自のイベントベースのコンピューティングタスクを構築する 今回、Data Catalog では、1 回限りのカタログ設定で、更新および作成されたテーブルの統計を自動的に生成できるようになりました。Lake Formation コンソールでデフォルトカタログを選択し、テーブル最適化設定タブでテーブル統計を有効にすることで開始できます。新しいテーブルが作成されると、Iceberg テーブルでは個別値の数 (NDV) が収集され、Parquet などの他のファイル形式では null の数、最大値、最小値、平均長などの追加統計が収集されます。Redshift Spectrum と Athena は、更新された統計を使用して、最適な結合順序やコストベースの集計プッシュダウンなどの最適化を行い、クエリを最適化できます。AWS Glue コンソールでは、更新された統計と統計生成の実行状況を確認できます。 データレイク管理者は、カタログ内のすべてのデータベースとテーブルに対して週次の統計収集を設定できるようになりました。自動化を有効にすると、Data Catalog はテーブル内のすべての列のカラム統計を週次で生成および更新します。このジョブはテーブル内のレコードの 20% を分析して統計を計算します。これらの統計は、Redshift Spectrum と Athena の CBO がクエリを最適化するために使用できます。 さらに、この新機能では、テーブルレベルで自動化設定とスケジュールされた収集設定を柔軟に構成できます。個々のデータオーナーは、特定の要件に基づいてカタログレベルの自動化設定を上書きできます。データオーナーは、自動化を有効にするかどうか、収集頻度、対象列、サンプリング率など、個々のテーブルの設定をカスタマイズできます。この柔軟性により、管理者はプラットフォーム全体を最適化しながら、データオーナーが個々のテーブルの統計を微調整できます。 この記事では、Data Catalog がテーブル統計収集を自動化する方法と、それを使用してデータプラットフォームの効率を向上させる方法について説明します。 カタログレベルの統計収集を有効にする データレイク管理者は、Lake Formation コンソールでカタログレベルの統計収集を有効にできます。以下の手順を実行します: Lake Formation コンソールで、ナビゲーションペインの Catalogs を選択します。 設定するカタログを選択し、 Actions メニューから Edit を選択します。 Enable automatic statistics generation for the tables of the catalog を選択し、IAM ロールを選択します。必要な権限については、 カラム統計を生成するための前提条件 を参照してください。 Submit を選択します。 AWS Command Line Interface (AWS CLI) を使用してカタログレベルの統計収集を有効にすることもできます: aws glue update-catalog --cli-input-json '{ "name": "123456789012", "catalogInput": { "description": "Updating root catalog with role arn", "catalogProperties": { "customProperties": { "ColumnStatistics.RoleArn": "arn:aws:iam::123456789012:role/service-role/AWSGlueServiceRole", "ColumnStatistics.Enabled": "true" } } } }' このコマンドは AWS Glue の UpdateCatalog API を呼び出し、カタログレベルの統計に対して以下のキーと値のペアを期待する CatalogProperties 構造体を受け取ります: ColumnStatistics.RoleArn – カタログレベルの統計のためにトリガーされるすべてのジョブに使用される IAM ロールの Amazon リソースネーム (ARN) ColumnStatistics.Enabled – カタログレベルの設定が有効か無効かを示すブール値 UpdateCatalog の呼び出し元は、 UpdateCatalog IAM 権限を持ち、Lake Formation 権限を使用している場合はルートカタログに対する ALTER on CATALOG 権限が付与されている必要があります。 GetCatalog API を呼び出して、カタログプロパティに設定されているプロパティを確認できます。渡されるロールに必要な権限については、 カラム統計を生成するための前提条件 を参照してください。 これらの手順に従うことで、カタログレベルの統計収集が有効になります。AWS Glue は、週次で各テーブルのすべての列の統計を自動的に更新し、レコードの 20% をサンプリングします。これにより、データレイク管理者はデータプラットフォームのパフォーマンスとコスト効率を効果的に管理できます。 自動化されたテーブルレベルの設定を確認する カタログレベルの統計収集が有効になっている場合、AWS Glue コンソール、AWS SDK、または AWS Glue クローラーを通じて AWS Glue の CreateTable または UpdateTable API を使用して Apache Hive テーブルまたは Iceberg テーブルが作成または更新されると、そのテーブルに対応するテーブルレベルの設定が作成されます。 自動統計生成が有効なテーブルは、以下のいずれかのプロパティに従う必要があります: Parquet、Avro、ORC、JSON、ION、CSV、XML などの HIVE テーブル形式 Apache Iceberg テーブル形式 テーブルが作成または更新された後、AWS Glue コンソールでテーブルの説明を確認することで、統計収集設定が設定されていることを確認できます。設定には Schedule プロパティが Auto に、 Statistics configuration が Inherited from catalog に設定されているはずです。以下の設定を持つテーブル設定は、AWS Glue によって内部的に自動的にトリガーされます。 以下は、カタログレベルの統計収集が適用され、統計が収集された Hive テーブルの画像です: 以下は、カタログレベルの統計収集が適用され、統計が収集された Iceberg テーブルの画像です: テーブルレベルの統計収集を設定する データオーナーは、特定のニーズに合わせてテーブルレベルで統計収集をカスタマイズできます。頻繁に更新されるテーブルでは、週次よりも頻繁に統計を更新できます。また、最も頻繁にクエリされる列に焦点を当てるために、対象列を指定することもできます。 さらに、統計を計算する際に使用するテーブルレコードの割合を設定できます。そのため、より正確な統計が必要なテーブルではこの割合を増やし、小さなサンプルで十分なテーブルではコストと統計生成パフォーマンスを最適化するために減らすことができます。 これらのテーブルレベルの設定は、前述のカタログレベルの設定を上書きできます。 AWS Glue コンソールでテーブルレベルの統計収集を設定するには、以下の手順を実行します: AWS Glue コンソールで、ナビゲーションペインの Data Catalog の下にある Databases を選択します。 データベースを選択して、利用可能なすべてのテーブルを表示します (例: optimization_test )。 設定するテーブルを選択します (例: catalog_returns )。 Column statistics に移動し、 Generate on schedule を選択します。 Schedule セクションで、 Hourly 、 Daily 、 Weekly 、 Monthly 、 Custom (cron 式) から頻度を選択します。この例では、 Frequency で Daily を選択します。 Start time に、UTC で 06:43 と入力します。 Column options で、 All columns を選択します。 IAM role で、既存のロールを選択するか、新しいロールを作成します。必要な権限については、 カラム統計を生成するための前提条件 を参照してください。 Advanced configuration の下で、 Security configuration で、オプションでセキュリティ設定を選択して、CloudWatch にプッシュされるログの保存時の暗号化を有効にします。 Sample rows に、サンプリングする行の割合として 100 と入力します。 Generate statistics を選択します。 AWS Glue コンソールのテーブルの説明で、指定した日時に統計収集ジョブがスケジュールされていることを確認できます。 これらの手順に従うことで、テーブルレベルの統計収集を設定できました。これにより、データオーナーは特定の要件に基づいてテーブル統計を管理できます。これをデータレイク管理者によるカタログレベルの設定と組み合わせることで、データプラットフォーム全体を最適化するためのベースラインを確保しながら、個々のテーブルの要件に柔軟に対応できます。 AWS CLI を使用してカラム統計生成スケジュールを作成することもできます: aws glue create-column-statistics-task-settings \ --database-name 'database_name' \ --table-name table_name \ --role 'arn:aws:iam::123456789012:role/stats-role' \ --schedule 'cron(8 0-5 14 * * ?)' \ --column-name-list 'col-1' \ --catalog-id '123456789012' \ --sample-size '10.0' \ --security-configuration 'test-security' 必須パラメータは database-name 、 table-name 、 role です。 schedule 、 column-name-list 、 catalog-id 、 sample-size 、 security-configuration などのオプションパラメータも含めることができます。詳細については、 スケジュールに基づくカラム統計の生成 を参照してください。 まとめ この記事では、カタログレベルで自動統計収集を有効にし、テーブルごとに柔軟な制御を可能にする Data Catalog の新機能を紹介しました。組織は、最新のカラムレベルの統計を効果的に管理および維持できます。これらの統計を組み込むことで、Redshift Spectrum と Athena の両方の CBO がクエリ処理とコスト効率を最適化できます。 ぜひこの機能をお試しいただき、コメントでフィードバックをお聞かせください。 著者について Sotaro Hikita は、Analytics Solutions Architect です。幅広い業界のお客様が分析プラットフォームをより効果的に構築・運用できるよう支援しています。特にビッグデータ技術とオープンソースソフトウェアに情熱を持っています。 Noritaka Sekiyama は、AWS Glue チームの Principal Big Data Architect です。東京を拠点に活動しています。お客様を支援するためのソフトウェアアーティファクトの構築を担当しています。余暇にはロードバイクでサイクリングを楽しんでいます。 Kyle Duong は、AWS Glue および AWS Lake Formation チームの Senior Software Development Engineer です。ビッグデータ技術と分散システムの構築に情熱を持っています。 Sandeep Adwankar は、AWS の Senior Product Manager です。カリフォルニア州ベイエリアを拠点に、世界中のお客様と協力して、ビジネスおよび技術要件を、お客様がデータの管理、セキュリティ、アクセス方法を改善できる製品に変換しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。