Icebergを使った マルチテナント型のログ基盤 2025-04-14 Tadahisa Kamijo Data & Analytics 井戸端会議 

自己紹介 上條 忠久 Kamijo Tadahisa ● さくらインターネット株式会社 クラウド事業本部 テクノロジー室 ● ソフトウェアエンジニアとしてサービス開発・運用 ○ Go, TypeScript, Python, Kotlin ○ Linux, Nomad, Ansible, Prometheus, React ● 今日は大阪から参加 

ログ基盤概要 ● 現在社内各チームで監視基盤が個別に構築運用されている ○ Prometheus, Elastic Stack, Loki, etc… ○ 社内向けログ基盤を提供することで、運用レベルの底上げ・運用コスト削減を目的 ○ OSS運用なども行ったが、マルチテナント提供・ライセンス体系の問題 ○ Trino+Icebergの構成で開発を開始 ● 2023年からパブリックサービス化を目指して開発開始 ○ アプリケーション・OS・ミドルウェアから出力される、システムログの保管場所として開発 ○ Trino, Iceberg, 社内のオブジェクトストレージ等を組み合わせてスクラッチ開発 ○ デジタル庁のガバメントクラウドの要件に含まれ、 2025年度末までの完成を目指す 

ログ基盤概要 OTLP/HTTPでのログ書き込みをサポート ● OpenTelemetry Logging Protocol ● HTTPでProtocolBufferバイト列をgzipで圧 縮してPOST ● fluent-bit, OtelCollector等が対応 独自WebUI ● 時間選択 ● 該当件数が表示されるフィルタ機能 

Apache Iceberg overview ● ストレージフォーマット ○ ビッグデータ・データレイク構築 ○ 仕様とデータを読み書きする低レイヤーライブラリ (Java,Python)の提供 ○ クエリエンジンTrino, Presto, Spark, Hive, Flink, Impala, 他から同じデータを参照 ● Netflix→Apache Software Foundation ● 機能 ○ 高い信頼性: Seriallizable isolation, Snapshot, Atomic mutation ○ 費用対効果の高いストレージ : Object Storage, Parquet ○ パフォーマンス最適化 : Partitioning, Clustering, CoW/MoR切り替え ○ スキーマ変更: Schema Evolution, Table, Partitioning 

ログ基盤でのIceberg ● テナント毎にテーブルを分ける ○ データ削除の容易さ ○ 性能分離・メンテナンスの容易さ ○ 暗号化の要求 ● 時間でパーティション・ソート ○ 検索対象のファイルを減らす ○ パーティション毎に課金メトリクスを取りたい CREATE TABLE log_tenant_1234 ( timestamp TIMESTAMP(6), insert_id VARCHAR, labels MAP(VARCHAR, VARCHAR ), level VARCHAR, -- DEBUG, INFO, WARN, ERROR message VARCHAR ) WITH ( partitioning = ARRAY[ 'day(timestamp)' ], sorted_by = ARRAY[ 'timestamp' ] ); (実際は大量のフィールドが定義されています ) 

ログ基盤の構成 (2023年時点 旧構成) Write Client Ingester (Kotlin) Shipper (Kotlin) Object Storage REST Catalog (MySQL) Query Gateway (Go) Maintainer (Go) gRPC Publish Consume Write Iceberg Table Catalog Operations Issue Maintenance Command HTTP API Read Client HTTP API 性能改善を目的にKafka導入 ● Icebergはコミットが衝突すると処理時間が伸びる ● ファイルサイズをある程度制御したい 

運用して分かってきた課題感 ● 並列度を上げるのが難しい ○ Iceberg Commitは数秒かかることも有る・可能な限り競合させたくない (単一Partitionへ) ○ Parquetの書き込みはメモリをテーブルあたり数百 MB使うことも ○ ログによって容量の差が激しい (数KB~数百MB) Upload Commit Upload Commit Upload Commit Upload Commit Upload Commit Upload Commit Upload Commit 時間軸 Upload Commit Upload Commit Upload Commit Upload Commit Upload Commit Upload Commit Upload Commit Upload Commit Upload Commit 

Iceberg TableへのAppend処理を分解する Append処理を2つのプロセスに分割して解決 ● Loader ○ KafkaからConsume ○ オブジェクトストレージに Parquetファイルを作成・書き込み ○ DataFile(パス・統計情報などを含む )をKafkaにPublish ● Committer ○ KafkaからConsume ○ Iceberg TableへData FileをCommit ■ 必要に応じて一定時間待機し、テーブル毎に複数個のファイルを含める Loaderは競合制御無しで並行実行可能 Committerはテーブル毎に競合しないようにコミット 

ログ基盤の構成 (2025年時点) Write Client Ingester (Go) Committer (Kotlin) Object Storage REST Catalog (MySQL) Query Gateway (Go) Maintainer (Go) OTLP/H TTP Publish Consume Write Iceberg Table Catalog Operations Issue Maintenance Command HTTP API Read Client HTTP API Loader (Kotlin) Publish Consume Parquet File Data File log rows 

Append処理の分割 ● メリット ○ スループット・スケーラビリティの向上 ■ 競合ポイントを分離 ○ コミット頻度の調整が容易に ■ 頻度を減らしたい時はコミット時に待ってバッチサイズを大きくすれば良い ● デメリット ○ コードが複雑化 ○ Committerが止まるとデータロストの危険性 ■ 復旧手順も非常に煩雑 

Icebergテーブルのメンテナンス ● Manifestから参照が切れた不要なデータが発生する ○ データが削除された場合 ○ コンパクションで複数ファイルを結合したファイルを作成した場合 ○ 書き込み中にクライアントが異常終了した場合 ● 不要なデータを定期的にremove_orphan_filesコマンドで削除 ○ そこそこ負荷が高いので 1日1回くらいの頻度が多い？ ● remove_orphan_filesは時間指定が可能 ○ 短い時間を指定しすぎると長い Queryが失敗する ○ 長い時間を指定するとストレージコストが増大する 

Committer停止時のデータロスト Loader Committer MQ ObjectStorage Trino Maintainer Catalog ②Parquet配置 ③ファイルパスPublish ④問題が発生して停止 ⑤古いファイルを削除 ⑥Subscribe再開 ⑦削除されたファイルを含む ManifestをCommit ①ログ投入 ⑧クエリ ⑨ファイルが無い 

対策 ● remove_orphan_filesのretention_thresholdを5日に設定 ○ 書き込んで5日以上経ったファイルを削除する設定 ○ 休日含んでも5日あったら復旧できるはず ○ ストレージのコストは増えている ● テーブルを修復するコマンドを開発 ○ 対象のファイルが存在しない Iceberg Tableは読み書きできなくなる ○ Manifestからファイルのエントリを削除する等のオペレーションをコマンド化 ○ PyIcebergライブラリを利用 

まとめ ● マルチテナント環境でのログ基盤の開発を行っている ● テナントごとにテーブル分離する設計 ● 複数テーブルへの性能向上のために、書き込みを分離 ● 問題が発生した場合の対処法を準備している