はじめに

Zabbix Summit 2026 レポートの2日目では、大規模な監視環境を支える技術的な工夫から、収集したデータの活用、ビジネスサービスの信頼性管理まで、幅広いテーマの講演をいくつかピックアップして紹介します。

今回取り上げる講演では、毎秒 100 万件の新規監視値を扱うための性能面の工夫や、日々の運用を効率化する機能、製造現場の業務アプリケーションを支える監視事例が紹介されました。さらに、Zabbix が収集したデータをレポートや AI による異常検知に活用する方法や、サービス全体の状態を可視化して SLA の管理につなげる取り組みも取り上げられました。

これらの講演に共通しているのは、監視データを収集して異常を通知するだけでなく、その情報を運用の改善や業務上の判断に役立てようとしている点です。それぞれの講演から、Zabbix の機能をどのように活用し、監視の効率化やサービスの安定運用につなげているのかを見ていきます。

大規模監視と日々の運用を支える Zabbix の工夫

Aleksandrs Kalimulins 氏の講演「Achieving 1M NVPS and Other Little Things」では、毎秒 100 万件の新規監視値を扱うというテーマとともに、日常の運用に役立つ Zabbix の機能が紹介されました。エージェント設定の簡素化からプロキシの運用、マクロによる通知の改善、ブラウザー監視まで、規模の拡大と使いやすさを両立するための工夫が幅広く取り上げられました。

■ エージェントの設定を整理する

エージェントの設定では、ホスト名の取得方法や、長いアイテムキーとパラメータの扱いが話題になりました。環境ごとに異なる情報をどこで設定するかを整理することで、テンプレートの再利用と保守をしやすくできます。短い別名やユーザーパラメータの活用は、複雑な設定を扱いやすくするための手段として紹介されました。

また、単一のエージェントを複数の論理的なホストとして利用する考え方も示されました。アクティブ監視では複数のホスト名を設定する方法があり、パッシブ監視では複数のホストから同じエージェントの接続先を参照できます。同じマシン上の監視対象を分けて管理したい場合に役立ちます。ただし、監視対象をどう分けるかは、テンプレートやパラメータの管理方針と合わせて考える必要があります。

導入を支援する機能として、ホストウィザードも紹介されました。画面の案内に従って設定を進め、生成されたコマンドを実行することで、エージェントの導入を進められます。設定に不慣れな担当者でも、必要な作業を段階的に確認できることが利点です。

■ 分散監視を支えるプロキシ

プロキシについては、収集データの保存方法として、ディスク、メモリ、ハイブリッドという選択肢が説明されました。メモリを使う方式は、収集データのバッファリングに伴うデータベースへの書き込みを抑えられます。ハイブリッド方式はメモリとデータベースを組み合わせるもので、通信状況やデータ保持の要件に応じた使い分けが重要です。軽量な SQLite は、遠隔拠点での運用やデータベースの再作成の容易さという観点から取り上げられました。設定の同期頻度についても、回線帯域や接続の安定性を考慮して調整できます。必要なタイミングで手動の設定更新を行う方法も紹介され、拠点ごとの事情に合わせた運用が示されました。

さらに、対応する範囲で異なるバージョンのプロキシを利用し、サーバーとプロキシを段階的に更新する考え方が説明されました。大規模環境では、すべての拠点を一斉に更新する負担を減らせます。プロキシ側でシークレットマクロを解決する機能も取り上げられ、拠点や役割に応じた秘密情報の取り扱いが話題になりました。

■ トリガーと通知を理解しやすくする

複雑なトリガー式は、設定を読むだけでは判定の理由を把握しにくい場合があります。講演では、マクロや式の構成要素を実際の値に展開して確認し、条件を読み解くための機能が紹介されました。複数のテンプレートや条件を組み合わせた監視では、こうした確認機能が調査を助けます。

通知の内容を充実させる方法として、値や時刻を示すマクロ、式マクロ、文字列変換などのマクロ関数も説明されました。例えば、ディスク容量の問題を知らせる際、対象のファイルシステムや残り容量をメッセージに含めれば、通知を受けた時点で状況を把握しやすくなります。異常の発生だけでなく、対応に必要な情報まで伝えることがポイントです。

■ ウェブ監視と表示機能の活用

ウェブシナリオでは、応答から JSONPath や XPath で値を抽出し、後続のステップで利用する方法が紹介されました。複数のリクエストをつなぐ REST API のテストなどに活用できます。ブラウザーアイテムについては、ログイン操作だけに用途を限定せず、自動操作の仕組みをさまざまな確認に応用する考え方が示されました。Appium を利用したモバイルアプリケーションのテストや、スクリーンショットの取得も話題になりました。一方、ブラウザーポーラーは同期的に処理するため、各チェックの所要時間、実行数、タイムアウトを考慮する必要があります。操作を自動化するだけでなく、監視を継続できる処理能力を見積もることが大切です。

このほか、ダッシュボードの操作性、アイテム履歴ウィジェット、ホストやテンプレートを探すグローバル検索も紹介されました。HTTP エージェントを使った Prometheus エクスポーターからのデータ取得にも触れられ、既存の監視資産を取り込む方法が示されました。

■ 毎秒 100 万件をテーマとした性能検証

講演の終盤では、ClickHouse と連携した構成での性能検証が紹介されました。履歴同期処理やバッファー、保存先の設定を調整し、書き込み先に過剰な負荷をかけないようにする工夫が説明されました。強調されたのは、瞬間的なピークではなく、単一の Zabbix サーバーノードで継続して処理できる負荷として評価する姿勢です。実測値は安定して 毎秒 100 万件処理を続けられることが説明されました。今回の講演は、大規模な処理性能と、日常の小さな運用改善を結び付ける内容でした。データ収集、保存、通知、画面操作をそれぞれ見直すことで、扱いやすく拡張しやすい監視環境につながると実感しました。

Zabbix の監視データを活用する ― AI による異常検知と高度なレポート機能

Wolfgang Alper 氏の講演「Putting Zabbix Data to Work: AI-Based Anomaly Detection and Advanced Reporting」では、Zabbix が収集している大量の監視データを、単なる監視結果として見るだけでなく、Reporting、外部連携、AI-Based Anomaly Detection に活用する方法が紹介されました。Alper 氏は、Zabbix はデータ収集に非常に強い一方で、収集した情報をそのまま監視画面の中だけで使うのではなく、Business Insight に変換することが重要だと説明しました。

■ レポート作成と外部システム連携によるデータ活用

まず紹介されたのが、Widget ベースの Reporting Engine です。考え方は Zabbix ダッシュボードに近く、レポートを複数の Widget の組み合わせとして構成します。Availability、Problem History、Current Problem、Long Running Problem、Graph、Markdown など、用途ごとに異なる Widget を利用でき、Management 向けレポートに必要な背景説明や補足情報も追加できます。レポートの元データは Zabbix API から取得し、Trend だけでなく Alert、Problem、Audit Log など幅広い情報を利用します。

収集したデータは Render Process を通して、人が読むレポートに変換することも、外部システムが再利用できるデータに変換することもできます。人向けには PDF レポートを生成でき、Header、Logo、Title、Table of Contents、Page Number などを含む形式で出力されます。各 Widget は Card のように レポート内へ配置され、Service Availability、MTTR、Problem State、Host Graph などを視覚的に確認できます。一方、システム連携向けには JSON、XML、CSV 形式でのエクスポートに対応し、BI Tool、Spreadsheet、Database、External Dashboard、Message Bus などにデータを渡せます。

講演では、既存データから新しい KPI を作る例として、Mean Time to Interaction や Mean Time to Recovery が紹介されました。Zabbix Event API に既に存在する情報を使って、Tech Support Team が Incident に対応するまでの平均時間や、Incident が Close されるまでの時間を算出できます。つまり、新しいデータを収集しなくても、既存の監視データから Management に有用な指標を作れるという点が重要です。

また、外部システムごとに必要なデータフォーマットが異なる場合に備えて、Transformation レイヤも用意されています。JavaScript の transform Function を使い、Report Object に対してフィールドの追加、削除、値の変更、新しい KPI の生成、Flatten 処理、Schema の変更などを実行できます。例えば外部システムが Report ID を必要とする場合は新しい フィールドを追加し、SLI と SLA の条件を比較して Boolean 値を生成することもできます。さらに、レポートデータを OpenTelemetry Collector が扱える形式に変換する例も紹介されました。

こうした仕組みにより、Zabbix で収集したデータを他部門や別アプリケーションに連携し、監視システムを企業全体のデータソースとして活用できます。特に大規模組織では、監視データを Kafka などの Message Bus に流し、別 Department や Business Application が Subscriber として利用する構成も考えられます。

■ 外部 AI Model による異常検知

講演後半では AI-Based Anomaly Detection も紹介されました。考え方は、Zabbix から取得した Time Series Data を外部 AI Model に入力し、各 Value が通常の Behavior からどの程度外れているかを Score として返すものです。複数の Model を同時に利用する Ensemble 構成も可能で、例えば 5 個の Model のうち 3 個以上が Anomaly と判断した場合に、最終的に異常として扱うような Majority Vote も設定できます。利用する Model 数を増やせば判定の信頼性を高められますが、その分 AI Server の Resource も必要になります。

AI 側からは Anomaly Score や Segment Score、さらに Trigger 作成の参考になる Threshold などが Zabbix に返されます。これらの値は通常の Zabbix Item と同様に ダッシュボードで確認でき、Trigger Expression に利用できます。つまり、Zabbix 本体の Source Code を変更せず、既存の アイテム、トリガー、ダッシュボードの仕組みを活用しながら、外部 AI Model による Anomaly Detection を組み込める点が特徴です。

■ 収集したデータを新たな価値につなげる

講演の Takeaway として強調されたのは、「もっとデータを集めること」よりも「すでに集めているデータをもっと賢く使うこと」です。監視システムには Infrastructure、Application、Business Activity など大量の情報が蓄積されています。それらは単なる監視用データではなく、企業にとって価値のある Asset です。

Zabbix が収集したデータをレポートに変換し、Management が理解しやすい KPI として提示し、JSON、XML、CSV などで外部システムに渡し、必要に応じて AI Model で Anomaly Detection を行うことで、Monitoring の役割を大きく拡張できます。今回の講演は、Zabbix を「異常を通知する Tool」だけでなく、「企業データを集約し、加工し、外部へ活用するプラットフォーム」として捉える実践的な事例でした。

Zabbix のサービス監視を活用した BSM と SLA 管理

Marek Panečný 氏の講演「Improving Service Reliability With Zabbix SLA Monitoring」では、Zabbix の Service Monitoring 機能を Business Service Monitoring、いわゆる BSM の考え方で活用し、単なる障害監視からサービス全体の信頼性管理へ発展させる方法が紹介されました。Panečný 氏は Asseco CEIT で監視基盤を担当しており、長年さまざまな監視製品を扱ってきた中で、2013 年頃から Zabbix を主要な監視ソリューションとして利用していると説明しました。

■ サービス全体の状態を可視化する BSM と SLA 監視

一般的な IT 環境は、Hardware、Operating System、Network、Database など複数のレイヤで構成されています。従来の監視では、それぞれのレイヤに対して Item や Trigger を大量に設定し、「何も気付かないまま壊れる」ことを避けるようにします。この方法自体は正しいものの、監視対象が増えるほど Problem や Notification も増え、いわゆる Alert Flood が発生しやすくなります。また、個々の Component の状態は分かっても、「その障害が Business Service にどの程度影響しているか」までは分かりにくいという課題があります。

そこで BSM では、通常の監視レイヤの上に Business レイヤを追加します。その中心となるのが Service Tree です。Service Tree は、Service や Service Component を Node として表し、それらの関係性を Tree 構造として定義するものです。各 Node には Severity や Status があり、下位 Node の状態を上位 Node に伝播させることで、サービス全体への影響を可視化できます。また、この Service Tree があることで、SLA Report、Impact Analysis、Root Cause Analysis といった処理の基盤を作ることができます。

Zabbix は標準機能として、Service Tree の構築、Problem と Service Node の関連付け、伝播や相関のルール、さらに各 Service に対する SLA 設定を提供しています。Problem と Service Node の紐付けには Tag を利用できるため、特定の Problem Severity や条件を Service の状態へ反映できます。そのため、Business Service Monitoring の基本機能は標準の Zabbix だけでも構築可能です。

■ 独自の Widget と Module によるサービス監視の強化

一方で、講演では標準機能の弱点も指摘されました。最も大きな課題は Service Tree の表示方法です。Zabbix 標準では Service Tree を本当の Tree 形式ではなく Table 形式で表示するため、構造が複雑になるほど関係性を直感的に把握しづらくなります。また、Service Tree をダッシュボード上に表示する専用 Widget がなく、Service Tree 自体の自動生成機能もありません。そのため、大規模環境では構築や保守を手作業で行う必要があります。

この課題を補うため、Asseco CEIT では 2 つの Widget と 1 つの Module を独自に開発しました。

• Service Tree Widget
  これは Service Tree を実際の Tree 構造としてダッシュボード上に表示します。Node に Mouse Pointer を合わせると詳細情報を表示でき、対象 Service の Status や Severity が時間とともにどのように変化したかも確認できます。
• Service History Report Widget
  これは複数の Service Node の状態変化を時間軸で表示し、Downtime の割合や継続時間、最終状態変更時刻などを確認できます。Service の信頼性を履歴として把握できるため、SLA の評価や障害傾向の確認にも役立ちます。
• Impact Analysis Module
  これは Problem 一覧から特定の Problem を選択した際に、その Problem が Service Tree のどの Node に影響しているかを表示します。Problem から直接 Impact Analysis を開始できるため、単に「障害が発生した」という情報だけでなく、「どの Business Service に、どの範囲で影響しているか」を素早く把握できます。

これらの拡張機能を標準の Zabbix Service Monitoring と組み合わせることで、CIO、Service Owner、Manager など、技術詳細より Business Impact を重視する利用者にも分かりやすい Monitoring が可能になります。Service Tree を視覚的に確認し、Node ごとの履歴や SLA を把握し、Problem から Impact Analysis を行い、さらに Service Node の状態変化を Alert の起点として利用することもできます。

■ SLA 監視をサービスの信頼性向上につなげる

今回の講演のポイントは、Zabbix の Service Monitoring 機能は単なる補助機能ではなく、Business Service Monitoring を実現するための重要な基盤になり得るという点です。一方で、Service Tree の Visualization や自動生成にはまだ改善の余地があり、今後は Automatic Discovery や Service Tree の自動構築機能が加わることで、さらに実用性が高まることが期待されています。

ラリーカー製造を支える Teamcenter 監視―― PLM を止めないための実践

Marko Väätänen 氏の講演「Keeping PLM at Full Throttle: Teamcenter Monitoring in Rally Cars Manufacturing」では、ラリーカー製造で利用する Teamcenter を対象に、Zabbix による監視の実践が紹介されました。中心となるテーマは、サーバーの稼働状況だけでなく、アプリケーションや業務の流れまで把握し、製造を支える PLM（製品ライフサイクル管理）環境の安定運用につなげることです。講演では、本番環境のダッシュボードや通知の例を交えながら、現場で必要とされる監視の考え方が説明されました。

■ 正常な状態を定義し、監視の範囲を広げる

監視を設計する出発点は、何をもって正常と判断するのかを定義することです。Teamcenter が正常に機能しているかを判断するには、その基盤となるサーバーやデータベースに加え、関連するサービスや自動化処理にも目を向ける必要があります。講演では、一般的な基盤監視と Teamcenter 固有の監視項目を組み合わせ、必要な情報を収集する構成が紹介されました。

具体的な対象として挙げられたのは、データベースの状態、アプリケーションのプロセスごとのメモリ消費量、ファイルの欠落、Windows イベントログなどです。メモリリークの検出も監視対象に含まれており、サービスが起動しているかどうかだけでは分からない問題を捉えようとしています。メモリ使用量をグラフで確認することで、ある時点の値だけでなく、時間の経過に伴う変化を追える点も紹介されました。

■ 業務のワークフローに踏み込む

この事例で注目したいのは、Teamcenter 固有のワークフローを監視対象としている点です。基盤側の状態を確認するだけでなく、アプリケーション内部の処理が期待どおりに進んでいるかを追跡する視点が示されました。処理の連鎖の中に問題があっても、監視がなければ担当者が気付けない場合があるという説明は、業務に近い層を可視化する重要性を表しています。

一方で、ワークフローから必要な情報を取り出す作業は、簡単ではないことも語られました。どの情報を取得したいのか、どの条件で結果を抽出するのかを明確にし、Teamcenter のデータベースや処理の構造に合わせて設定する必要があります。
講演では、UserParameter を使った情報取得や、特定のイベントに対応するトリガーの設定にも触れられました。監視項目を増やすだけでなく、業務上の問題を判断できる情報に整えることが、実装上の要点として読み取れます。

■ ダッシュボードで利用状況をまとめて確認する

本番環境の監視画面では、サービスの状態とともに、ユーザー数やログインに関する情報を確認する例が示されました。複数の情報を一つの画面にまとめることで、担当者が環境全体の様子を把握しやすくしています。日常的に確認する情報を集約することは、異常が起きた際に、どこを調べるべきか判断する助けにもなります。

ライセンスも重要な可視化対象です。講演では、利用中のライセンス数や期限に関する情報を扱い、ダッシュボードで確認する仕組みが紹介されました。システムの稼働状況に加えて、利用者が実際にサービスを使うための条件まで把握している点が特徴です。監視対象となるユーザーのリストを更新する運用にも触れられ、収集対象を実態に合わせて維持する必要性がうかがえました。

■ 通知を、確認と対応につなげる

異常を迅速に知るためのアラームは欠かせませんが、通知が多くなると、その内容を確認して対応すること自体が課題になります。講演でも、多数のメール通知を受け取る状況が取り上げられました。情報を集めて通知する仕組みを整えるだけでは、運用上の負担がなくなるわけではありません。

そこで言及されたのが、事前チェックやワークフローの状態確認です。自動化を考える際にも、対象の状態を確かめる仕組みが必要であり、通知から直ちに処理を実行すればよいという単純な話ではありません。また、チームからの連絡や確認を取り入れるフィードバックの流れも紹介されました。監視で得た情報と現場で把握した状況を照らし合わせることが、問題の確認や対応を支えています。

■ 製造を支えるアプリケーション監視の価値

今回の講演が示したのは、監視対象をインフラからアプリケーション、さらに業務の流れへと広げる実践です。データベース、プロセス、ログ、ファイル、ライセンス、ワークフローをそれぞれ確認することで、単一の指標では見えない問題を捉えようとしています。その実現には、Teamcenter の内部構造と運用を理解し、必要な情報を選び取る作業が欠かせません。

ラリーカー製造という現場を支える PLM 環境において、監視は障害を知らせるだけの仕組みではありません。担当者が日々の状態を理解し、見落としやすい問題に気付き、対応へ進むための基盤です。Zabbix の収集・可視化・通知の機能を、対象アプリケーションの特性に合わせて組み合わせることの価値が伝わる事例でした。

おわりに

今回紹介した講演では、大規模なデータ収集を支える性能面の工夫から、日々の運用を効率化する機能、アプリケーションや業務サービスの状態を把握するための監視、さらには AI や外部システムとの連携まで、Zabbix の幅広い活用方法が紹介されました。

毎秒 100 万件の新規監視値を扱うための性能検証では、データの収集や保存の仕組みを適切に調整することの重要性が示されました。また、エージェントやプロキシの設定、通知メッセージの改善といった日々の運用に関わる工夫も取り上げられ、監視環境の規模を拡大することと、扱いやすさを両立するための考え方を知ることができました。

一方、Teamcenter の監視事例や SLA 監視の講演では、インフラの稼働状況だけでなく、アプリケーション内部の処理や業務サービスへの影響まで把握することの重要性が示されました。さらに、収集したデータをレポートや KPI に変換し、外部システムや AI による異常検知に活用する取り組みからは、監視データを運用改善や意思決定に役立てる可能性が見えてきます。

これらの事例から、監視環境を改善するうえでは、単に監視項目を増やしたり、より多くのデータを収集したりするだけでなく、何を把握したいのか、得られた情報を誰がどのように活用するのかを考えることが重要だと感じました。

Zabbix には、データ収集、障害検知、可視化、通知、サービス監視など、さまざまな機能が備わっています。これらを監視対象や運用上の課題に合わせて組み合わせることで、障害の早期発見にとどまらず、日々の運用の効率化やサービスの信頼性向上にもつなげることができます。

Zabbix Summit 2026 で紹介された事例や考え方を参考に、私たちもお客様の環境や課題に応じた監視のあり方を考え、より実用的な監視・運用の実現に取り組んでいきたいと思います。

はじめに

Zabbix Summit は、オープンソースの統合監視ソリューションである Zabbix に関する最新情報や活用事例、技術的な知見が共有されるイベントです。世界各国の Zabbix ユーザーやエンジニア、パートナー企業、開発者などが集まり、Zabbix の最新機能や今後の開発の方向性、実際の運用現場での取り組みについて理解を深める機会となっています。

今回開催された Zabbix Summit 2026 では、Zabbix の最新バージョンに関する情報をはじめ、監視運用の効率化や自動化、生成 AI との連携、オブザーバビリティなど、今後の監視基盤を考えるうえで興味深いテーマが取り上げられました。

本レポートでは、Zabbix Summit 2026 で発表されたセッションの中から、特に注目した内容をピックアップし、技術的なポイントや実際の Zabbix 環境への活用という観点から紹介します。

Zabbix 8.0 が切り拓く Observability の新時代 ― Alexei Vladishev 氏による基調講演

Zabbix Summit 2026 で、Zabbix の創設者である Alexei Vladishev 氏が「Zabbix 8.0: Redefining Observability」と題した講演が行われました。
講演では、Zabbix 8.0 の主要な新機能と性能改善に加え、AI、クラウド、モバイル、Marketplace を含む今後の戦略が紹介されました。
特に印象的だったのは、従来の監視ツールから、システム全体の状況と問題の背景を理解する Observability プラットフォームへ進化させようとする方向性です。

■ オープンソースと統合監視という Zabbix の強み

Alexei 氏は、Zabbix の大きな特徴として、オープンソースであること、さまざまな環境に柔軟に対応できること、監視に必要な機能を統合的に提供することを挙げました。
Zabbix は、OS やネットワーク機器の監視を中心に発展してきましたが、現在ではコンテナ、クラウド、アプリケーション、オンプレミスとクラウドが混在するハイブリッド環境まで対象を広げています。
異なるベンダーの製品を組み合わせて監視基盤を構築する方法もありますが、できるだけ多くの機能を一つの基盤で利用できることは、構成や運用の複雑さを抑えるうえで重要です。
ライセンス料金を課さない方針に加え、公開ドキュメント、公式トレーニング、各種サービスによって利用者を支援する姿勢も強調されました。
セキュリティについては、認証や製品開発・提供プロセスへの対策の組み込みに触れ、機能の豊富さだけでなく信頼性も重視していることが示されました。

■ OpenTelemetry とトレースによる可観測性の拡張

Zabbix 8.0 の重要なテーマの一つが、OpenTelemetry などを通じた新しい種類のデータの取り扱いです。
従来のインフラ監視では、CPU 使用率、メモリ、ディスク、ネットワークの状態といったメトリクスが中心でした。
しかし、複数のサービスが連携するアプリケーションでは、ある処理がどこを通り、どの部分で遅延や障害が発生したかを把握する必要があります。
そこで重要になるのが、リクエストや処理の経路を追跡するトレースデータです。
講演では、こうした情報を Zabbix で収集、保存、可視化する取り組みが説明され、AWS X-Ray にも言及されました。
メトリクス、ログ、トレースを関連付けて扱うことができれば、単に異常を検知するだけでなく、問題がインフラにあるのか、アプリケーションにあるのかを調べる手掛かりが増えます。
Zabbix をインフラ監視だけでなく、アプリケーションの動作を理解するための基盤へ広げる重要な変化と言えます。

■ MCP Server で AI と監視データを接続

もう一つの大きな進化として紹介されたのが、MCP Server への対応です。
MCP Server は Zabbix と AI の間に入る仲介役として機能し、AI から監視情報を参照・活用するための接点になります。
講演では、「今、最も重要な問題は何か」「どのホストに注目すべきか」といった問いを自然言語で投げかける利用方法が例示されました。
これまで監視担当者は、画面を切り替え、条件を指定し、複数の情報を読み解いて状況を把握する必要がありました。
AI との連携が進めば、必要な情報を対話形式で取り出し、調査の出発点を素早く見つけることが期待されます。
Alexei 氏は、特定の AI モデルに固定するのではなく、利用者が適切な AI の仕組みを選べる柔軟性も重視していました。
ただし、AI がすべての判断を自動化するという説明ではなく、監視データをより使いやすくするための新しいインターフェースとして理解することが重要です。

■ 複合イベント処理によってアラートの意味を整理

Complex Event Processing と呼ばれる複合イベント処理も、講演で強調された機能です。
大規模環境では、単一の障害が原因で多数のトリガーや問題イベントが短時間に発生することがあります。
すべてのイベントを個別に確認する運用では、本当に対処すべき問題が大量の通知に埋もれてしまいます。
新しい処理の仕組みでは、イベントの流れやパターンを扱い、関連する事象を整理して重要な情報を浮かび上がらせることを目指しています。
講演では、毎分 100 件を超えるイベントが発生する状況にも触れ、単純なイベント単位のルールを超えた複雑な処理や、プログラムによるパターンマッチングの拡張について説明されました。
監視の価値を、アラートを数多く出すことから、運用担当者が優先順位を判断しやすくすることへ変えていく機能です。

■ 毎秒数百万メトリクスを見据えた性能向上

性能面では、大量の監視データを継続的に処理する環境を想定した改善が紹介されました。
Alexei 氏は、毎秒数百万件規模のメトリクスを扱う事例を挙げ、ボトルネックの解消やストレージ処理の最適化について説明しました。
新しいストレージエンジンへの対応や、高度な圧縮技術によって、データを効率的に保持・処理する方向性が示されています。
CPU やメモリの効率についても改善が語られ、処理によっては大幅な高速化が得られることが強調されました。
ただし、講演中に示された性能値は特定の条件に基づくものと考えられるため、あらゆる環境で同じ改善率が得られると断定することはできません。
大規模な監視基盤ほど、こうした処理効率の向上はインフラコストや拡張性に直結します。

■ 使いやすさを高める UI とビューのカスタマイズ

UI の改善も、日常の運用に直接関わる重要なテーマです。
講演では、画面の一貫性やアクセシビリティの改善に加え、利用者が必要な情報を柔軟に表示するためのカスタマイズ機能が紹介されました。
表示する列の追加や並べ替え、タグやホストのインベントリ情報を利用した列の構成などにより、用途に応じた一覧画面を作成できるようになります。
例えば、データセンター名や機器に関する情報を列として表示すれば、問題の発生場所や対象機器を一覧から把握しやすくなります。
また、データのフィルタ条件と表示方法を保存し、異なる目的に応じて複数のビューを使い分ける考え方も説明されました。
監視データの量が増えるほど、情報の見せ方を利用者自身が調整できることの価値は高まります。

■ Zabbix Cloud と Mobile App による運用の変化

Zabbix Cloud については、監視基盤そのものの保守負担を減らすサービスとして紹介されました。
利用者がセキュリティパッチ、バックアップ、基盤のメンテナンスを細かく管理する必要を減らし、本来の監視業務に集中できることが狙いです。
クラウドから各拠点のインフラを監視する構成や、Zabbix のバージョン対応についても言及がありました。
一方、Mobile App では、重要な問題をプッシュ通知で素早く把握することと、外出先から問題の状態を確認することが主要な利用場面として示されました。
ユーザープロファイルとモバイル端末を関連付ける仕組みにも触れ、日常的な監視業務をデスクトップの外へ広げようとする姿勢がうかがえます。
Cloud と Mobile App は、監視の対象だけでなく、監視サービスの提供方法や利用する場所を変える取り組みです。

■ Marketplace が広げる拡張機能のエコシステム

Marketplace については、Zabbix 向けの追加機能やソリューションを見つけ、共有・入手するための場所として紹介されました。
例えば、新しいレポートや追加モジュールが必要な場合に、コミュニティやベンダーが提供する成果物を利用できるようにする構想です。
無料のものだけでなく、商用の拡張機能も想定されており、開発者が作成した機能を多くの Zabbix ユーザーへ届ける場として期待されています。
個別に作られていた便利な機能が広く流通すれば、利用者は開発の手間を減らせる一方、パートナーや開発者には新たな提供機会が生まれます。
講演では Marketplace に関する別セッションも案内され、利用者からの期待や意見を集めたいという呼びかけがありました。

■ 今後の展望 ― AI を製品と開発プロセスの両方へ

講演の最後には、Zabbix の長期的な方向性として AI のさらなる活用が語られました。
MCP Server による外部 AI との接続に加え、将来的にはテンプレート作成など、Zabbix の機能そのものに AI を組み込む方向性が示されました。
例えば、監視したいデバイスの情報を伝えることで、設定作業を支援するような使い方が考えられます。
また、AI の活用対象は製品機能に限らず、コードの作成やテスト、QA といった開発・品質保証の領域にも広がっています。
これらはすべてが Zabbix 8.0 で完成しているという意味ではなく、今後の開発に向けた戦略的な展望として説明された内容です。

Root Cause Analysis with Complex Event Processing ― CEP による根本原因分析

Kaspars Mednis 氏の講演「Root Cause Analysis with Complex Event Processing」では、Zabbix のイベント相関機能を活用し、大量の障害通知から根本原因を特定するための考え方が紹介されました。
複合イベント処理（ CEP：Complex Event Processing ）を利用した根本原因分析の目的は、単にアラート数を減らすことではなく、原因となる問題と派生的な症状を区別することです。
時間ウィンドウ、キャパシティ、グループ化、相関ルールを適切に設計すれば、複雑な依存関係の保守負担を減らし、障害対応時に注目すべき情報を絞り込めます。
一方で、設定によってイベントの扱いが変わるため、実際の監視環境に合わせて動作を検証することが重要です。

■ 従来のトリガー依存関係の課題

ひとつの障害が複数のサービスに影響すると、根本原因とは別に多数の関連アラートが発生します。

従来はトリガー間の依存関係を定義して対処できましたが、構成が複雑になるほど設定や保守が難しくなります。
講演では、既存の依存関係が機能することを認めながら、イベントの発生状況に応じて柔軟に関連付ける方法が説明されました。

■ 複合イベント処理（ CEP ）によるイベント相関

複合イベント処理（ CEP ）では、まずフィルターで対象イベントを選び、相関ルールを設定します。
ホストグループやタグなどの属性を条件にでき、関連するイベントを同じ処理の対象として扱えます。
相関ルールでは、どのイベントを照合し、一致した場合にどのような操作を行うかを定義します。
この方法により、すべての依存関係を手動で列挙することなく、一定の条件に基づいて問題同士を関連付けられます。

■ 時間ウィンドウとキャパシティ

中心となる概念が、イベントを一定期間保持して照合する時間ウィンドウです。
例えば 10 分間のウィンドウを設定すると、その期間に入ったイベントを条件に従って評価できます。
イベントがいつウィンドウに入り、いつ対象から外れるかによって相関結果が変わるため、継続時間の設定が重要です。
また、ウィンドウに保持するイベント数を制限するキャパシティも設定できます。
講演では、解決済みの問題であってもウィンドウ内に残る間はキャパシティを消費する場合があることが強調されました。
単にアラートが解決したかどうかだけでなく、ウィンドウ内の状態を理解する必要があります。

■ イベントのグループ化

タグなどを利用してイベントをグループ化すると、同じルールを複数の対象に適用しながら、ウィンドウをグループごとに分離できます。
例えばストレージごとにグループを分ければ、異なるストレージの障害を誤って関連付けずに済みます。
複数の一致条件を組み合わせることもでき、イベントの属性や発生順序に応じた処理を構成できます。
なお、相関ルールで処理対象から外すことと、元のアラートそのものを削除することは同じではありません。

■ ポートフラッピングへの適用

具体例として、ネットワークポートがダウンとアップを短時間に繰り返すポートフラッピングが紹介されました。
こうした変化をすべて独立した障害として通知すると、重要な問題が大量のアラートに埋もれてしまいます。
同じポートのイベントを時間ウィンドウで関連付ければ、繰り返し発生する変化をまとめて扱い、不要な通知を抑制できます。

■ 障害の連鎖とログイン失敗

バックアップ失敗など、ひとつの障害が後続の問題を引き起こすケースも取り上げられました。
イベントを関連付け、条件を満たした際に複数の問題をまとめて解決扱いにするなどの処理が考えられます。
また、ログイン失敗が繰り返されるケースでは、ウィンドウ内のイベント数を評価し、代表的なアラートを残して後続通知を抑制する方法が説明されました。

■ 独自ロジックによる拡張

講演では、ウィンドウ内のイベントを数える関数などを使い、条件判定の結果として true または false を返す処理にも言及がありました。
イベントのタグや数値属性を変更したり、複製や破棄などの操作を組み合わせたりすることで、用途に応じた相関ロジックを作成できます。

Zabbix の新たな APM の可能性 ― OpenTelemetry を活用した監視の進化

Zabbix の製品責任者である Martiņš Orinskis 氏は、「Unlocking New APM Power」と題した講演で、OpenTelemetry を活用したアプリケーション監視の新たな可能性を紹介しました。
クラウドネイティブ技術や分散アーキテクチャの普及により、アプリケーションの健全性を把握することは従来以上に難しくなっています。
単純な死活監視や個別の性能指標だけでなく、複数のサービスを横断して状況を理解し、問題の原因を迅速に特定する仕組みが求められています。

■ OpenTelemetry による多様なデータの活用

OpenTelemetry は、メトリクス、ログ、トレースなどのテレメトリデータを共通の仕組みで収集・転送するための技術です。
講演では、OpenTelemetry Protocol を通じて得られるデータには豊富な属性や情報が含まれる一方、そのままでは量が多く、監視に利用しにくい場合があると説明されました。
そこで重要になるのが、データを集約・計算・変換し、運用担当者にとって意味のあるメトリクスに整理することです。
例えば、特定の業務処理に対するリクエスト数や、サービス単位の応答時間などを抽出すれば、アプリケーションの状態を把握しやすくなります。

■ Zabbix Proxy を活用した収集と集約

今回の説明では、Zabbix Proxy を中心に OpenTelemetry のデータを扱う構成が紹介されました。
テレメトリデータを収集する処理と、そこから必要な値を取り出して Zabbix で監視する処理を分けることで、大量の生データをそのまま監視基盤に保存する必要を減らせます。
プロキシ側で集約やクエリを実行し、結果を Zabbix のアイテムとして扱うことで、既存の監視やアラート機能との連携が可能になります。
講演では、テレメトリストレージに対して SQL に似たクエリを実行し、その結果を JSON 形式で受け取り、Zabbix のストレージに保存する流れも説明されました。
これにより、詳細なデータの保管と、日常の監視に必要な指標の管理を役割分担できる構成が示されました。

■ 柔軟な設定と動的な情報の取得

OpenTelemetry を利用するための接続設定については、設定ファイルを使う方法に加え、ユーザーインターフェースから接続を定義する方法も紹介されました。
収集対象やリソース属性、ホストに関連する設定を組み合わせることで、環境に応じた監視を構成できます。
また、データに含まれるサービス名などの属性を利用し、動的に情報を識別することも重要なポイントです。
JSON 形式のデータから必要なフィールドを取り出す機能や、複数の値をまとめて取得する方法についても説明がありました。
こうした仕組みは、サービスや監視対象が頻繁に変化する環境で特に役立つと考えられます。

■ 集約間隔とアラートの設計

講演では、データの集約間隔とアイテムの実行間隔を適切に設定する必要性にも触れられました。
例えば、10 秒ごとにクエリを実行する場合、どの時間範囲のデータを集約するかによって、監視結果に欠落や重複が生じる可能性があります。
短時間のサンプリングで動作を確認しながら、用途に合った集約方法を選ぶことが重要です。
さらに、JSONPath を使ったフィールドの抽出や、取得したデータに基づくトリガーの設定によって、特定の状態を検出してアラートにつなげる考え方が示されました。
一方、JSON データに対する一部の高度な関数や相関処理については、今後の対応が期待される機能として言及されました。

■ APM と従来の監視をつなぐ

今回の講演で印象的だったのは、OpenTelemetry を独立した監視の仕組みとして扱うのではなく、Zabbix が持つ既存の監視機能と組み合わせようとしている点です。
データセンター全体の状態から、個々のサービスや特定のエンドポイントの応答時間まで、対象に応じて監視の粒度を変えることができます。
ログ、トレース、メトリクスを組み合わせて分析することで、単に異常を検知するだけでなく、その背景にある原因を調べるための手掛かりも得られます。
OpenTelemetry から得られる膨大な情報を、実際の運用に役立つ指標へ変換することが、今後の APM における重要なテーマだと感じました。
Zabbix の新しい取り組みは、従来のインフラ監視とアプリケーションの可観測性をつなぎ、より幅広いユースケースへの対応を目指すものといえます。

おわりに

今回の講演からは、Zabbix 8.0 が単なる機能追加版ではなく、監視基盤の役割を広げる重要な節目として位置付けられていることが伝わってきました。
OpenTelemetry やトレースによるデータの拡張、MCP Server を通じた AI 連携、複合イベント処理による情報の整理、大規模環境を支える性能改善は、いずれも現代の複雑なシステム運用に直結するテーマです。
さらに、UI の柔軟性、Cloud、Mobile App、Marketplace の取り組みは、Zabbix を利用する人や提供する企業の裾野を広げるものです。
オープンソースと柔軟性という従来の強みを維持しながら、収集したデータから問題の意味を理解し、迅速な判断につなげる Observability プラットフォームへ進化していくことが、今回の講演の中心的なメッセージだったと感じました。

はじめに

2026年3月、アジア最大級の FOSS カンファレンスである FOSSASIA Summit 2026 が開催され、その併設イベントとして PostgreSQL PGDay が開催されました。
PGDay は PostgreSQL に特化した 1 日カンファレンスで、世界各地から PostgreSQL 開発者・ユーザが集まる技術イベントです。
SRA OSS では昨年も FOSSASIA PGDay に参加しましたが、今年は参加に加え、2名がスピーカーとして登壇しました。本記事では、FOSSASIA および PGDay の概要とともに、SRA OSS からの発表内容を中心にご紹介します。

FOSSASIA Summit および PostgreSQL PGDay について

FOSSASIA Summit は、オープンソースソフトウェアやオープンテクノロジーをテーマとした国際カンファレンスです。
ソフトウェア開発だけでなく、OS、クラウド、データベース、AI、セキュリティなど、幅広い分野のセッションが用意され、アジア圏を中心に世界各国から参加者が集まります。

その中で開催される PostgreSQL PGDay は、PostgreSQL の開発や運用、拡張、エコシステムに焦点を当てたイベントです。PostgreSQL の内部構造、性能チューニング、高可用性、運用、セキュリティなど、実運用に直結するテーマが幅広く扱われました。

SRA OSS からの発表

Pgpool-II による PostgreSQL 高可用性と性能最適化

基盤技術グループのプリンシパルエンジニア でPgpool-II 開発者でもある彭 博（ペン ボ）からは、「Pgpool-II: An Introduction to High-Availability and Performance Optimization for PostgreSQL」と題し、PostgreSQL 高可用性構成における課題と、それを解決する Pgpool-II の役割について紹介しました。

PostgreSQL にはストリーミングレプリケーションなどの仕組みがありますが、自動フェイルオーバー／フェイルバックは標準では提供されておらず、読み書きの振り分けやロードバランシングはアプリケーション側で実装が必要といった課題があります。Pgpool-II はクライアントと PostgreSQL の間に配置されるミドルウェア で、アプリケーションを大きく変更することなく「自動フェイルオーバー」や「クエリのロードバランシング」といった機能を提供することで、これらの課題を解決します。また、「コネクションプーリング」「インメモリクエリキャッシュ」といったパフォーマンス向上機能も提供しています。

さらに、Pgpool-II 自体が単一障害点になることを避けるための「Watchdog 機能」についても解説されました。Watchdog 機能により「複数のPgpool-II ノード間での死活監視」「リーダー選出」「Virtual IP の自動切替」「スプリットブレイン防止」といった仕組みが提供され、Pgpool-II 自体も冗長化可能であることが紹介されました。

pg_ivm: 高速なマテリアライズドビュー更新

技術開発室の主席研究員でPostgreSQLコントリビュータでもある長田悠吾（ながたゆうご）からは、「pg_ivm: Extension for Fast Materialized View Maintenance and Recent Improvements」というタイトルで、自身が開発するPostgreSQL 拡張モジュールである pg_ivm について発表しました。

pg_ivm は増分ビューメンテナンス（Incremental View Maintenance, IVM） という、高速なマテリアライズドビューの更新を実現する機能を提供する拡張です。通常のマテリアライズドビューでは、元テーブルが更新された後には REFRESH MATERIALIZED VIEW によりビュー全体を再計算する必要がありますが、IVM では更新された差分のみを計算してビューに適用することで、更新コストを大きく削減します。

具体的には、この拡張モジュールにより、テーブル更新時に自動かつ高速に更新されるIMMV（Incrementally Maintainable Materialized View）と呼ばれるビューを作成できます。テーブル更新時のオーバーヘッドなどいくつかの考慮点はありますが、これを用いることで、ビューの更新が通常の REFRESH と比べて数百倍高速となるケースも示されました。

また、最近の改善として外部結合ビューへの対応が追加されたほか、将来の機能改善として、（テーブル更新時に自動で行うのではなく）手動によるビューの増分更新や、パーティションテーブル、論理レプリケーションへの対応などが検討されていることも紹介されました。

その他の発表

PGDay では、SRA OSS の発表以外にも、PostgreSQL の現在と将来に関わる多様なセッションが行われました。

基調講演では、PostgreSQL の30年の歴史や、PostgreSQL コミュニティとその貢献方法についての紹介が行われました。PostgreSQL の開発や内部構造に関係する発表としては、PostgreSQL 18 新機能解説や、データベースのメタ情報を格納するシステムカタログを深掘りするセッション、近年のインデックスの改善について解説するセッションがありました。

また、Pgpool-II や pg_ivm 以外にも、クエリ実行を外部の Apache DataFusion クエリエンジンで行える拡張モジュール pg_fusion や、LIKE/ILIKE を用いた文字列のマッチングを高速化するためのインデックス Biscuit といったツールを紹介するセッションもあり、PostgreSQL エコシステムの広がりを感じられるプログラムとなっていました。

おわりに

今年の FOSSASIA PGDay も、PostgreSQL の進化とコミュニティの活発さを改めて実感できるイベントでした。SRA OSS としても、PostgreSQL および Pgpool-II や pg_ivm といったツールの開発と情報発信を通じて、引き続き PostgreSQL コミュニティの発展に貢献していきます。

はじめに

Current はデータストリーミング分野の第一人者が一堂に会するコミュニティイベントです。イベントでは主に Apache Kafka® (以下 Kafka) や Apache Flink® (以下 Flink) などのストリーミング処理ソフトウェアに関する講演が行われ、世界中の人々が集まり交流、学び、そして情報共有する場です。

今年 2025 年は 3 月 19 日にインドのベンガルール、5 月 20 日にイギリスのロンドン、そして 10 月 29 日にアメリカのニューオーリンズで開催されました。今回はその中のニューオーリンズで開催されたイベントに参加してきましたので、私が聴講したセッションを中心にその様子をお伝えしたいと思います。

開催地、ニューオーリンズ

開催地であるニューオーリンズはアメリカのルイジアナ州南部にあるメキシコ湾に面した港湾都市です。ジャズの発祥地として有名で、フレンチクォータと呼ばれる地域ではフランス・スペイン植民地時代の街並みが残り、クレオール、ケイジャン料理などの美食も味わえる全米でも有数の観光都市でもあります。

イベント会場の様子

Current New Orleans 2025 はニューオーリンズの中心部、ミシシッピ川沿岸の Ernest N. Morial Convention Center (アーネスト N. モリアル コンベンションセンター) の一角で開催され、60 以上のセッションに 3,500 人以上が参加する非常に大規模なイベントとなりました。イベントホール内では 50 近いスポンサーブースが立ち並び、各社が提供するデータストリーミングに関する様々なソリューションの紹介や参加者同士の交流の場となっていました。

それ以外にもイベントホール内ではハッカソンが開催されていたり、VR の体験、ストリーミング処理ともかかわりの深い AI に関するアートの展示など、様々なイベントが開催され、大いに盛り上がっていました。

イベントで提供されるセッションは非常に多く複数のセッションが同時に行われていたため、そのすべてをレポートすることはできませんが、その中から私が聴講したものをいくつか紹介したいと思います。

一日目

Keynote (一日目): Building Intelligent Systems on Real-time Data

一日目の Keynoteでは Confluent 社の CEO 兼共同設立者、Jay Kreps 氏がプレゼンターとして壇上に立ちました。Confluent 社はカリフォルニアに本社を置き、Kafka を基盤とした企業向けのリアルタイムデータストリーミングプラットフォームやフルマネージドクラウドサービスを提供する会社で、日本法人として Confluent Japan もあります。また本イベント Current を主催する会社でもあります。

Keynote の主題は昨今の AI の台頭に対して、それを使ったシステムをどう構築し、組織内のソフトウェアそしてリアルタイムのデータとどう結び付けていくかについてです。効果的に AI を活用していくには AI が利用するデータをどのようにアップデートしていくかが重要です。例えばデータの更新をバッチ処理で行うとすればその分最新の状況との差異が生まれます。そこでリアルタイムデータを逐次的に処理できるストリーミングデータパイプラインを構築すれば、常にデータを最新に保ち続けることができます。そのシステムの構築に有効なのが Kafka や Flink といったストリーミング処理のソフトウェアです。企業にとっても日々生まれ続けるデータをリアルタイムに活用するためにはストリーム処理が必要不可欠なのだと感じました。

また Confluent Intelligence と名付けられた新しいサービスもこのセッションの中で発表されました。これはビルトインの機械学習関数、リアルタイムコンテキストエンジン、ストリーミングエージェントの 3 つの製品から構成されるサービスで、AI システムが過去のデータから継続的に学習し、リアルタイムで行動することを可能にするためのものとのことです。AI エージェントや RAG (検索強化生成)、AI 向け機械学習パイプラインの構築、または Kafka および Flink によるコンテキスト提供に活用が期待されるサービスです。

さらには、Confluent Private Cloud の発表も併せて行われました。これは Confluent Platform を基盤としており、自社インフラにクラウドサービスの効率性を備えたプライベートデータストリーミング環境を実現できるサービスとなるようです。

続いて一日目の個別セッションの内容をご紹介します。

Introduction to Apache Flink: Key Concepts and Architecture

ストリーム処理とバッチ処理の両方をサポートする分散処理フレームワークである Flink について解説する、初心者向けのワークショップセッションです。ストリーム処理とバッチ処理の概念や Flink による分散処理のコンセプトとアーキテクチャを基礎から丁寧に解説されており、ストリーム処理を一から学びたいという人にも最適なセッションだと感じました。

A Deep Dive into Kafka Consumer Rebalance Protocols: Mechanisms and Migration Process Insights

Kafka 4.0 で実装された新しい Consumer Rebalance Protocol の詳細について、既存との違いをデモを交えてわかりやすく解説されていました。また、既存のプロトコルからの移行のメカニズムについてもオンラインとオフライン両方に対応した方法を紹介されていました。

Consumer Rebalance Protocol とは、ConsumerGroup 内でどの Partition をどの Consumer に割り当てるかを調整するメカニズムです。従来のプロトコルではグループ内のメンバが変化した際に、リバランスが完了するまで一時的に Consume が停止するという制約がありましたが、新しいプロトコルではそれが軽減・削除されています。また、リバランスによる再割り当てのロジックを Broker 側に移動しており、それによる大幅な高速化や安定性の向上も見込めるという利点もあります。

The Kafka Protocol Deconstructed: A Live-Coded Deep Dive

このセッションでは Kafka が持つ様々な機能を実現する上でどのようなプロトコルを用いているのかを、かなり根本的な部分まで深掘りして解説されていました。例えば、リクエストのヘッダやボディがどういった要素から構成されていて、それぞれの要素にはどういった内容のデータが格納されているかなど、Kafka が実際にやり取りしている通信プロトコルを明らかにし、それを一から再構築するといったところまで実演していました。

プロトコルを深く知ることで Kafka の内部挙動を本質的に理解できると共に、実用上でのチューニングや問題解決にも応用できそうな、私にとっては非常に有用な内容でした。

Current party

一日目の終わりには参加者ならだれでも参加できるパーティが開かれました。時期が近いこともあり、中はハロウィン風の装飾がされていたり、ニューオーリンズらしくライブ演奏やクレオール、ケイジャン料理が味わえたりと様々な趣向が凝らされており、参加者同士の交流を深めるという意味でも非常に有意義なパーティでした。

二日目

Keynote (二日目): Be Ready for What’s Next

二日目の Keynote では Confluent 社のアドボカシーおよびデベロッパーエクスペリエンスエンジニアリング部門責任者の Adi Polak 氏が登場し、リアルタイムシステムの現在までの発展の経緯について語りました。モノリシックなシステムからマイクロサービスへの転換、マイクロサービス同士をつなぐ Kafka の登場、そしてデータレイクとして Apache Hadoop と HDFS から Apache Iceberg、Apache Hudi、Delta Lake といったテーブルフォーマットを導入したことによる信頼性の向上。これらの発展によって今現実に起こっていることをリアルタイムで処理するための準備が整いました。そして現在 AI が登場しました。真に信頼できる AI のためには優れたモデルが必要ですが、それを構築・実用するには信頼できるリアルタイムデータ、ひいてはそれを作り出す信頼できるシステムを準備しておくことが必要であると彼女は述べていました。

このセッションではその他にもテレビ番組のトークショーを模した形式でのデータストリーミング分野の第一人者へのインタビューや、コミュニティやこの分野に貢献した企業への授賞式なども行われました。

続いて二日目の個別セッションの内容をご紹介します。

What Can you do with a (Kafka) Queue?

このセッションでは Kafka をメッセージキューとして利用可能にするための新しい Consumer Group の実装である、Share Group について解説されていました。従来の Consumer Group では Partition 内でのメッセージ順序を維持するために、グループ内で重複して同じ Partition からメッセージを取得することはありませんが、Share Group ではそれを可能にすることでメッセージキューとして Kafka を使うことができるようになります。この機能はまだ完全に実装されてはいませんが、これによって Kafka の用途の可能性が広がる非常に興味深いものだと感じました。

Playing Chess by Scaling Multi-Agent LLM Play with Kafka Queues

これは上記の Kafka のキュー機能を利用して、LLM (大規模言語モデル) にチェスを並列で同時にプレイさせてみたという、中々面白い内容のセッションです。AI と Kafka の新機能を組み合わせることで、アイディアによってはこういう使い方もできるんだという一例だと思います。実際にセッション中にデモを披露していましたが、かなりスムーズに LLM がチェスを複数盤面で同時にプレイする様子も伺えました。

AI 関連のセッション

Keynote で言及もあったように、データストリーミングは AI とも関連の深い分野です。本イベントでも AI に関するセッションは数多くあり、AI Alley Theater という AI セッション専用のブースが設けられるほどでした。

その他のイベントの様子

おわりに

Current はデータストリーミングの現在を肌で感じることのできる唯一のイベントです。私も今回参加したことで、Kafka をはじめとしたストリーミング処理について、最新の動向や深い知見を大いに得ることができ、データストリーミングの分野が今いかにホットであるかということを知ることができました。

セッションの内容も幅広く、初心者向けに Kafka や Flink といったデータストリーミングプラットフォームを構成するソフトウェアの基礎を解説するものや、より深く内部動作を解説するもの、ソリューションや活用例を紹介するものなど、データストリーミングを知りたい様々な層に広く訴求するイベントだと感じました。皆さんもデータストリーミングに興味があれば、是非参加してみることをお勧めします。

また、本イベントのセッションは動画でアーカイブされており、誰でも見ることができます。非常に多くの有用なセッションがありますので、データストリーミングや Kafka、Flink などのソフトウェアについて知りたいという方は、こちらもチェックしてみてください。

はじめに

COSCUPはConference for Open Source Coders, Users, and Promotersの略で、ヨーロッパ最大のオープンソースイベントであるFOSDEMを参考に2006年から開催されている、オープンソースコミュニティが主催するカンファレンスです。

会場となったのは国立台湾科技大学で、常時20以上のトラックが並行して開催される大規模なイベントでした。講演のほかにも、BoF(Birds of a Feather, コミュニティや参加者が主催する非公式のミートアップ)や、Hacking Corner(開発者向けの交流用オープンスペース)、各OSSコミュニティのブースなどが設けられていました。

参加者人数は延べ3000人を超えており、参加していて非常に活気のあるイベントだと感じました。また、日本のOSS関連のイベントと比べると、参加者の年齢が若いと感じます。

本レポートでは、筆者が参加したセッションの中から特に印象に残ったものをいくつか紹介します。

[Prime Session] Programming Language for AI age

Rubyの開発者、まつもとゆきひろ氏による講演です。Ruby固有の話ではなく、生成AIと付き合ってプログラミングすることについて語られました。

AIを使用するのはペアプログラミングするようなもので、人間と違い、気を遣う必要がないのがメリットです。しかし、AIを使用してプログラミングするには不完全な自然言語を使う必要があります。そうすると、逆アルファ症候群(ある技術が登場すると、その技術が登場する前よりも忙しくなるにもかかわらず、それをありがたがって使用してしまう)を引き起こしてしまいます。今のところ、AIエージェントはドキュメントの生成やリファクタリングには優れている一方、大規模なプロダクトベースのプログラミングには向いていません。(使うとしても、例えばメモリ管理の部分などではAIよりもその分野に詳しくないといけないです。)

人間の言語はプログラミングに向いていないので、AIとやり取りする専用の言語が必要です。それは、簡潔で、理解しやすく、堅牢な表現力と拡張可能な語彙を持つような言語です。そして、そのような特徴を持った言語はすでに存在しています。――それはRubyである、と締めくくられました。

2025年現在のAIの能力に対する感想については、筆者が生成AIを使用した感じと似通っていました。一方で、AIとプログラミングする専用の言語が必要、という認識については思い浮かばなかった発想で、感銘を受けました。

From MongoDB to PostgreSQL

この講演では、ドキュメントデータベースのオープンソース標準を策定するプロジェクトおよびMongoDB互換のオープンソースデータベースFerretDBが紹介されました。MongoDBのライセンス変更に伴い、ドキュメントデータベースにもリレーショナルデータベースのような標準を策定必要がある、という問題意識によりプロジェクトが発足しました。

単にJSONを格納できる、という観点ではPostgreSQLも使用できますが、ドキュメントデータベースの世界ではフレームワークや開発者がMongoDBに依存しており、PostgreSQLをそのまま使用することは困難です。FerretDBは、バックエンドでPostgreSQLを動作させつつも、クライアント側ではMQLというMongoDBの問い合わせ言語を受け取ります。MQLとPostgreSQLの仲立ちをするのがFerretDBです。

また、バックエンドで動作させるデータベースはPostgreSQL互換であればよいので、例えばより高い可用性を求めるのであればバックエンドのデータベースとしてYugabyteDBを動作させることもできるようです。

Japanese Food Knowledge Graph for Taiwanese

日本でOSCを開催している、OSPN(Open Source People Network)による講演です。
日本食を例にあげて、ナレッジグラフの紹介がなされました。ナレッジグラフとは、知識を表現するグラフです。各概念を表すノードがあり、それぞれのノードはプロパティを持っています。ノード間の関係性はエッジ(線)によって示されます。例えば、カツカレーは以下のように表現されます。

Curry - CONTAINS -> Onion
Curry - CONTAINS -> Meat
Curry - IS_SERVED_WITH -> Rice
Katsu Curry - IS_COMPOSED_OF -> Curry
Katsu Curry - IS_COMPOSED_OF -> Tonkatsu

このナレッジグラフは、後述するRAG(検索拡張生成)の情報源としても使用することができます。

講演は英語で行われていましたが、日本語のできる台湾の参加者が、他の参加者の質問を日本語に通訳しやり取りするなど、和気あいあいとした雰囲気での交流がされていました。

Hot Topics in Global PGConf

この講演では、世界各地で開催されているPostgreSQLカンファレンス（PGConf）で話題のトピックについて紹介されました。PGConfで近年話題になっているものを紹介することで、最新技術トレンドや地域ごとの特色、あるいは地域に関係なく役立つ知見を共有することを目的とした講演でした。

技術トピックとしては、AI×pgvectorによるベクトル検索、pg_hint_planやVACUUMを中心としたパフォーマンス最適化、論理レプリケーションやActive-Active構成による高可用性、EDB Postgresのセキュリティ強化、RDSやAuroraなどクラウド移行の事例が紹介されました。PostgreSQL 18の新機能にも触れられていました。

台湾のPostgreSQLコミュニティに技術トレンドを紹介する目的の講演でしたが、紹介された技術トピックは日本のPostgreSQL Conferenceでもよく選ばれているトピックであり、親近感を覚えました。

Community-Driven Edge AI or Building Offline AI Agents with Open Models

この講演では、オープンモデルを活用したオフラインAIエージェントについて紹介されていました。従来のAIはネットワーク接続が前提でしたが、モバイル端末上で動作する「AI Driven Device」への進化が進んでおり、オフラインでも動作可能なAIエージェントのニーズが高まっています。

まず、生成AIが備えておくべき機能として、マルチモーダル(複数の種類の情報、例えばテキストデータのほかに画像や音声、動画を入力として受け取れる)、Function Calling(AIが外部の関数やAPIを呼び出す機能、例えばユーザから写真を受け取って位置を推測し、Google Mapを呼び出す)といった概念が紹介されました。

次に、Googleが開発したオープンモデルであるGemma 3、Gemma 3 Nanoについて紹介されました。
どちらのモデルもマルチモーダル、Function Callingといった機能を兼ね備えています。特にGemma 3 Nanoはサイズが小さく、モバイル端末にも組み込み可能なうえ、完全オフラインで動作する点が特徴的です。

生成AI分野が主題の講演も1つは参加してみようと思い聴講した講演でしたが、図や写真が多くスライドに掲載されており、事前知識が薄くともわかりやすい講演でした。

打開 AI 模型的任意門：用 PostgreSQL 撐起AI

こちらの講演では、PostgreSQLを生成AIの長期的な文脈保持に活用するための方法が紹介されました。
生成AIの既存のモデルを使用して独自チャットボットを作成する際、RAGという手法が使われます。これは、生成AIに参考にさせたい情報をあらかじめデータベースに保存しておき、問い合わせが来たら「関連がありそうな」情報をデータベースから探し出してAIに渡すことで、より求めている回答に近づける手法です。

RAGが登場した際はテキストデータを単にベクトル化し、ベクトルデータベースに保存することが考案されていましたが、このベクトルデータベースには欠点があります。それは、「関連がありそうな」情報をベクトル間の距離により算出するため、チャットの参考にさせるには望ましくないテキストが算出されてしまうという問題です。
本講演ではナレッジグラフを作成しておき活用する方法について紹介されました(Graph RAGといいます)。
ナレッジグラフは知識が構造化されていますので、場合によってはベクトルデータベースを使用するよりも望ましいテキストを抽出することができ、生成AIの精度向上に役立ちます。

筆者が参加したPostgreSQL関連の講演では一番参加者が多く、生成AIへの関心の高さが肌で感じられました。

監控與告警設計：打造適合團隊使用的 PostgreSQL 觀測儀表板

この講演では、金融業の大規模なデータベース環境におけるPostgreSQLの監視・可視化の取り組みが紹介されました。クレジットカード業務を例に、822万枚以上の流通カードを扱う高負荷なシステムにおいて、DB管理者がどのようにサービス性能を向上させているかが語られました。

DBAとデータ分析チームの視点の違いを踏まえた監視設計をしていました。DBAはCPU、メモリ、IO、WALサイズなどのリソース管理を重視し、分析チームはクエリの待機状態やブロックされたプロセスなど、ユーザーの行動に着目するためです。講演では、PrometheusとGrafanaを用いて、両者のニーズを満たす観測ダッシュボードを構築する方法が実例とともに紹介されました。

紹介された監視項目はpg_stat_activityやpg_locks、VACUUの進捗状況などで、一般的にPostgreSQLの状態を把握するのにつかわれるビューやテーブルが網羅的に紹介されていました。また、観測ダッシュボードは視覚的にわかりやすくて良いと感じました。

20 週年論壇：總召視角下的開源精神

COSCUP 開催 20周年を記念した対談です。COSCUP 歴代の代表者が参加し、オープンソースの精神についてをメインに対談が行われました。
対談中に、特に印象に残った点をいくつかあげます。

まず、ソフトウェアをオープンソースとすることのメリットは、コミュニティによる議論によってソフトウェアを改善していくことができる点です。多くの人がそのソフトウェアについて議論をすることで、単独で開発していた時には起こらなかった発想が生まれ、より洗練されたものにできます。

次に印象に残ったのは、「オープンソースに貢献することは、コミュニティに善意を共有している」という考え方です。
オープンソースコミュニティにおいては、善意で誰かに助けてもらうことがあります。ソフトウェアのエラーについて質問すると、誰かにこたえてもらった、というようなことです。この助けてくれた人は、何らかの利益を求めて貢献しているのではなく、質問者が今後コミュニティに何らかの貢献をすることを期待しているのです。

そして、オープンソースの精神を維持するには、オープンソースの考え方を発信し続けていく必要がある、という考え方にも感銘を受けました。時代は変化し続けており、オープンソースの精神を脅かすような技術が台頭してきています。例えば、ブロックチェーンはデフォルトでオープンである一方、ブロックチェーンのユーザがオープンソースの考えに関心があるかは微妙です。また、生成AIやクラウドコンピューティングは構成が複雑なため、オープンであることを要求することは難しいです。このような時代の変化の中で、COSCUPを通じてオープンソースの精神を広めていく必要がある、と述べられていました。

筆者は入社して以来PostgreSQLに関連する業務を行ってきましたが、本対談に参加することによりコミュニティへ貢献することの重要性を再認識しました。

終わりに

COSCUP 2025 へ参加し、聴講してきた講演から印象に残ったものを紹介しました。COSCUPにおいても、AIに関する関心は非常に高く感じられました。講演のタイトルにもAIという単語が含まれているものが多く、またAI関連の講演は他のものと比べ参加者が多い傾向にありました。一方で、AIが目まぐるしく進歩し、変化していく時代の中で、オープンソースコミュニティをどのように維持していくか、が重要だと感じました。今後、筆者も業務で主に使用しているPostgreSQLコミュニティについて、何らかの貢献ができればと思います。

はじめに

PGConf.dev の正式名称は PostgreSQL Development Conference で、PostgreSQL のユーザや開発者、コミュニティ関係者が集まる、PostgreSQL の開発とコミュニティの発展に焦点を当てたイベントです。 今回、株式会社SRA OSSはシルバースポンサーとして、このカンファレンスを支援しました。

今回の会場は、モントリオールのダウンタウン中心部に位置するPlaza Centre-Ville。全４日間の日程のうち、初日には 次年度のPostgreSQL 開発の優先度などを対面で議論する Developer Meeting（招待制）や、拡張モジュールについての議論をアンカンファレンス形式で行う Extension Ecosystem Summit、コミッターからパッチについてのアドバイスを受けられるAdvanced Patch Feedback Session（招待制）、コミュニティ運営に関するグループ・ディスカッションを行うPostgres Community Summitなどが行われました。

2日目の朝にはオープニングセッションと基調講演があり、その後２日間にわたり、３トラック並行でさまざまな講演が行われました。最終日はアンカンファレンスが開催され、その後クロージングセッションで締めくくられました。

本レポートでは、本カンファレンスのいくつかの講演をピックアップして紹介します。

基調講演

今回の基調講演はDavid DeWitt 博士による「From RAP to Snowflake – A Look at 50 Years of SQL DB Scalability 」でした。

1980年代中頃から1990年代初頭にかけて、ウィスコンシン大学の教授だった時代に博士が主導した並列データベースプロジェクト「Gamma」は、シェアード・ナッシング・アーキテクチャ（shared nothing architecture：複数の各ノードがCPU・メモリ・ストレージを完全に独立して持ち、互いに共有せずに性能をスケールさせる方式）の概念を初期に実装・検証したものとして、Spark、Snowflake、Redshiftといった今日の大規模分散データベースシステムの基礎となっています。

この講演は博士の50年にわたるキャリアを通して見たデータベースのスケーラビリティの発展の歴史を、RAP（Rotating Associative Processor) という初期のデータベースマシンから、安価なハードウェアの登場による独自データベースのホスティングの普及、そしてクラウドの時代へと続く流れで紹介されました。

その中では、分散データベースにおけるハッシュ結合の重要性や、ストレージとコンピュートを分離する現在主流の構成において、Snowflakeがいかに革新的であったかなどが語られていました。

Learned Index の実装に向けた試み

Gray W Evans氏 (Fujitsu Australia) とNishchay Kothari 氏(Fujitsu Asia Pte Ltd) による講演「Exploring the benefits of learned indexes in PostgreSQL: Theory and Implementation」では、機械学習を活用したインデックスである Learned Index を PostgreSQL に実装に関する試みについて発表が行われました。

Learned Index については以前のイベントレポートでも紹介しましたが、簡単に説明すると、インデックス内部のキー探索に機械学習モデルを用いることで、高速な検索およびインデックスサイズの削減を目指す技術です。

今回の発表では、Learned IndexのPostgreSQLへの実装に向けた具体的な検討結果が紹介されました。Learned Indexの構造にもいくつか種類がありますが、今回の発表では、データ分布の変化に強く更新処理に対応できるALEX (Adaptive Learned Index) という構造を用いることが検討されていました。

しかしながら、インデックス全体をメモリ上に保持することを前提とするALEXと、インデックスページをディスクに永続化するPostgreSQLのアーキテクチャの間には非互換性があり、通常のワークロードにおいてはLearned Indexによる性能改善はあまり期待できないことがわかってきました。

ただし、クエリ実行中の途中経過に対する一時的なインデックスなど、ALEXインデックスが有用となり得るユースケースについての検討も進められているようです。
今後は、今までにわかってきたことを論文にまとめるとともに、ALEXインデックスが有用なケースに向けて拡張モジュールとして開発を進めるほか、静的なデータ分布を得意とする別のLearned Index構造についても、PostgreSQLにおけるユースケースを検討を行っていく予定とのことでした。

トランザクションマネージャを拡張可能に

近年、様々な分散データベースが登場しており、そこに伴い、グローバルトランザクションマネージャ（GTM）やクロックベースのアルゴリズムなど、多様な分散トランザクション手法が利用されています。 Yuya Watari 氏 (NTT) の講演「Revisiting XTM: A Practical Case Study Highlighting Its Needs」では、PostgreSQLにおいてそうした多様なトランザクション処理をサポート可能にする 拡張トランザクションマネージャ（eXtensible Transaction Manager, XTM）の有用性について議論が行われました。

XTMは2015年に開発コミュニティに提案されたアイデアですが、結局PostgreSQLには取り入れられていません。本発表では、外部データラッパ（FDW）とパーティショニングテーブルを組み合わせたシャーディング構成におけるトランザクション処理を例に、XTM の有用性が再評価されました。

postgres_fdw を使うと、別ノードのPostgreSQLのテーブルに格納されているデータを、自分のノードのテーブルのように参照・更新することができます。しかし、PostgreSQL標準のpostgres_fdw では分散トランザクションに対応しておらず、複数の外部サーバが参加する二相コミットを利用することができません。そこで、この発表ではpostgres_fdw を改造した postgres_fdw_plusを使用しています。

二相コミットにはコミットの「準備」と「確定」の2段階の過程があります。通常は、全ての処理が完了してコミットが確定した後に、クライアントへトランザクション完了の応答を返します。しかしこの発表では、性能を改善するために、「全ての外部サーバでコミットの準備ができた」段階でクライアントに応答を返すという最適化を採用しています。

ただし、この最適化はトランザクションの一貫性に影響を与える可能性があります。たとえば、FDW 経由のデータ更新とコミット準備が外部サーバで実行され、クライアントがトランザクション完了の応答を受け取った直後に、別のトランザクションを開始して外部サーバのデータを直接参照した場合、最初のトランザクションがまだ「コミット準備」状態にあるため、更新したはずのデータが見えないという現象が発生します。

このような状況を解決できるのがXTMです。トランザクション開始時の処理をカスタマイズし、「準備状態のコミットが確定するまで」外部サーバでのトランザクションの開始を待機させることで、更新済みのデータを正しく参照できるようになります。

発表では性能評価も行われ、XTM を利用したトランザクション処理をカスタマイズした場合でも、性能への影響はほとんどなかったことが示されました。一方で、トランザクション隔離性に影響があることが言及されており、ユーザがトランザクションマネージャの制限や前提を十分に理解していることの重要さも示唆されました。
最後に、様々な分散データベースが登場している中で、多様なトランザクション要望に対応するためにXTMの重要性は高まりつつありますが、「本当に必要な機能は何か」を知るには、実際に様々なトランザクション手法を実装してみる必要があるだろうという主張で発表は締めくくられました。

VACUUM の最新情報と今後

更新を繰り返されるテーブルから不要なタプルを回収し、古いトランザクションIDを持つタプルに「凍結」処理することでトランザクションIDの周回を防ぐ ― VACUUMは、PostgreSQLの状態を健全に保つために大切な役割を担っています。Masahiko Sawada氏 (AWS) の講演「The Present and Future of VACUUM in PostgreSQL」では、そんなVACUUMの最新の改善と、今後起こりうる改善が紹介されました。

講演の前半では、PostgreSQL 17 で行われたVACUUMのメモリ効率改善など、最近の改善を振り返りつつ、PostgreSQL 18 での新たな改善点として eager scanning が紹介されました。

通常のVACUUMでは、不要領域がないテーブルページについては処理をスキップして、そのため凍結処理も行われません。その結果、凍結が必要なタプルが徐々に蓄積し、最終的にトランザクションIDの周回を回避するため、大量のタプル凍結処理を行うaggressive モードのVACUUMで負荷が高まる可能性があります。

これに対処するための仕組みがeager scanning です。これは通常のVACUUMの最中に、たとえ不要領域が存在しないページでもスキップせずに、凍結処理のためのスキャンを実行するというものです。ただし、凍結できるタプルが少なく、ページ全体の凍結の失敗が一定以上続いた場合には、eager scan は中止されます。この失敗の割合は、新たに導入されたパラメータ vacuum_max_eager_freeze_failure_rate によって調整可能です。

後半には、PostgreSQL 19 以降に登場する可能性のある、現在開発中のVACUUMの改善がいくつか紹介されました。その一つが、Sawada氏が提案しているテーブルデータの並列VACUUMです。現在のVACUUMではインデックスは複数のワーカプロセスで並列処理可能ですが、テーブル本体は並列処理できません。それを改善しようという提案です。

その他にも、テーブルサイズを切り詰めるVACUUM FULL / CLUSTER の後継として、 CONCURRENT オプションをサポートするREPACK コマンドの提案など、今後のVACUUM改善に向けた興味深い取り組みが紹介されていました。

共有バッファサイズの動的変更

PostgreSQLの共有バッファのサイズは shared_buffers パラメータで決定されますが、現在この値を変更するためにはデータベースの再起動が必要です。このため、ワークロードに応じた動的なスケーリングや、メモリの最適利用が難しく、自動チューニングツールの活用も制限が生じるという課題があります。

Ashutosh Bapat 氏 (EnterpriseDB) の講演「Changing shared_buffers on the fly」は、この問題に取り組むもので、PostgreSQLを再起動せずにshared_buffers を動的に変更可能にする提案について議論されました。

共有バッファの管理に複数のメモリ構造が関係していますが、従来はそれらの領域を共有メモリ上に一括して獲得していたため、共有バッファのサイズが変更時に各構造のメモリアドレスが変わってしまうという問題がありました。提案されている方法では、各構造毎に独立した共有メモリセグメントを使用し、さらにメモリアドレス空間を余分に確保しておくことでこの問題を解決しています。

また発表の中ではメモリサイズ削減時の振る舞いや、サイズ変更時のバックエンドプロセスとの同期、サイズ変更の契機となるイベント（設定のリロード時、SQL関数やDDLコマンド）などについても議論されていました。

動的に切り替わる実行計画

Alena Rybakina 氏 (Postgres Professional)による講演「Switching between query plans in real time (Switch Join)」では、クエリ実行中に現在の実行計画が期待通りに動作しない場合に、別の実行計画へ自動で切り替える機能である Switch Join が紹介されました。

具体的には、２つのテーブルを結合するクエリにおいて、当初はネステッドループ結合で処理を行うものの、推定行数の誤差が一定以上大きい場合にハッシュ結合に切り替える、といった機能を提供します。

Switch Join はPostgreSQLの拡張モジュールとして、カスタムスキャンとフックを用いて実装されています。非常に興味深い機能ですが、ベンチマーク結果では、一部クエリでは性能向上が見られる一方で、オーバヘッドにより別のクエリでは性能が低下する場合もあり、使用するには注意が必要そうです。

なお、本機能はオープンソースではなく、 PostgresPro Standard の一部として提供される予定とのことでした。

適応的なVACUUMの制御

Melanie Plageman 氏 (Microsoft) による講演「Fraught Feedback: Trying and Failing to Implement Adaptive Behavior in Postgres」では、VACUUMの振る舞いを適応的に制御するという実験的な試みについて紹介されました。

ひとつの試みは、VACUUMの負荷を調整するパラメータvacuum_cost_delayの値を、タプル回収の進行具合およびデッドタプルの発生速度を考慮して自動調整するというものです。デッドタプルの発生に対して回収が追いつかなくなった場合はこのパラメータ値を小さくしてVACUUM処理の割合を増やし、逆の場合にはパラメータ値を大きくしてVACUUMを小休止の割合を増やし、負荷を減らすというアイデアです。しかし、実際には処理が安定せず、あまり良い結果は得られなかったようです。

もうひとつの試みは、しばらく変更されないであろうテーブルページを統計的に予測し、そういったページを早めに凍結処理するというものです。これにより、小規模なVACUUMが多く発生した一方、全体のVACUUMにかける時間の総量は減少したとのことでした。

アンカンファレンス

最終日に開催されたアンカンファレンスは、講演者や話す内容があらかじめ決まっている通常のセッションと異なり、参加者がその当日にその場で話題を提案し、議論する形式のイベントです。議論したいテーマがある参加者は、大きなポストイットにそのテーマを書き、順番に口頭で簡単に紹介していきます。最終的には、会場の参加者による多数決で12のテーマが選ばれ、3つのトラックに振り分けられ議論されました。

今回は選ばれたテーマには、PostgreSQLの開発をスケールする、自動VACUUMのパラレル化、PostgreSQLのマルチスレッド化、スタンバイのコミット順序とCSNスナップショット、pg_stat_statementの未来、プランナの意思決定を明確にする、などがありました。

「PostgreSQL のマルチスレッド化」は、前回の pgconf.dev 2024 に引き続き注目を集めているトピックです。今回もThomas Munro 氏　(Microsoft) による関連講演「Investigating Multithreaded PostgreSQL」があり、このテーマへの関心の高さがうかがえました。

また、「スタンバイのコミット順序とCSNスナップショット」では、プライマリとスタンバイの間でトランザクションの「可視」タイミングが異なることに起因する一貫性の問題が議論されました。スタンバイにおける可視化のタイミングはWALの書き込み順で決まりますが、それはプライマリにおける可視化タイミングと同じとは限りません。現在 PostgreSQL開発コミュニティに提案されているCSN (Commit Sequence Number) スナップショットは、この問題を解決する方法としても期待されているようです。

さらに「プランナの意思決定を明確にする」では、PostgreSQLが実行計画を作成する過程で、どのようなプラン、スキャン、インデックスが除外されたか、あるいや優先されたかを知るために有用な情報についての議論がなされていました。

ポスターセッション

今回初の試みとして、ポスターセッションが開催されました。イベント開催約１ヶ月前に、自分たちが提案するパッチやプロジェクトを紹介するポスターの作成が呼びかけられました。作成されたポスターはA2サイズで印刷され、会場内の様々な場所の壁に展示されました。

筆者もこの企画に参加し、ポスターを作成し展示させていただきました。

これらのポスターはオンラインでも閲覧可能となっています。

おわりに

今回で２回目の開催となったPGConf.dev 。昨年参加したときも感じたことですが、このカンファレンスは改めて「PostgreSQLの未来を向いているイベント」であるという印象を強く受けました。

開発コミュニティで現在議論されている提案に関する講演はもちろんのこと、実験的な取り組みを共有する発表の数々が刺激的でした。中でも、多様なワークロードや状況変化に対応するための拡張性や適応性を高めるための提案は、私自身の関心とも重なり、特に興味深く感じました。また、コミュニティそのものの改善や進化を目的とする講演もあり、カンファレンス全体を通して、「これからのPostgreSQLを自分たちで作り上げていく」、「その場に参加していく」という、コミュニティの原動力のようなものを感じることができました。

来年の PGConf.dev 2026はカナダのバンクーバでの開催が予定されています。今回得られた知見と刺激を今後のコミュニティへの貢献に活かしながら、来年もまたぜひ参加できればと思います。

はじめに

FOSSASIA は、オープンソース技術の促進と開発を目的としたアジア最大級のコミュニティであり、オープンソースソフトウェア（FOSS: Free and Open Source Software）に加え、ハードウェア、オープンデータ、AI などの分野で活動しています。FOSSASIA Summit は、このコミュニティが毎年開催するアジア最大級のオープンソース技術イベントであり、開発者、イノベーター、企業、教育者が一堂に会し、知識と技術を共有する場となっています。

今回の会場は バンコク市内の The True Digital Park West で、大小さまざまなデジタル企業や団体が入居するオフィススペース、コワーキングスペース、会議室、飲食店、イベントスペースなどを備えた巨大な複合施設です。会期中の3日間にわたり、AI & Data Science、Cloud & DevOps、Database、Hardware & Firmware、Security、Robotics など多岐にわたるテーマの合計170のセッションが、常時3〜4トラック並行して開催されていました。

FOSSASIA PGDay 2025 は PostgreSQL に焦点を当てたイベントで、FOSSASIA Summit 2025 の数あるセッションの１つとして、2日目に開催されました。
本レポートでは、FOSSASIA Summit 2025 の発表の中から、特に PGDay に関連するトピックを中心にいくつか紹介します。

FOSSASIA PGDay 2025

まずは、PGDay で行われた講演について紹介します。

AWS と PostgreSQL コミュニティ

PGDay の最初の講演は、Amazon Web Services (AWS) の Michael Paquier 氏による “AWS and the PostgreSQL community” でした。この講演では、プラチナスポンサーでもある AWS と PostgreSQL コミュニティの関わりが紹介されました。Amazon RDS や Amazon Aurora などのサービスで活用されているように、AWS にとって PostgreSQL は重要な戦略的コンポーネントと位置づけられています。こうしたサービスを顧客中心の方針で展開する中で、AWS は PostgreSQL に対し、ユーザーの課題を解決する機能の提案や実装を行っています。実際、AWS の PostgreSQL コミュニティへの貢献は大きく、コアチームメンバー 1 人、コミッター 7 人が AWS に所属しています。最新リリースである PostgreSQL 17 では、AWS のメンバーによる 162 件のパッチがコミットされており、全体の 10.2% を占めるとのことです。

講演の後半には、顧客の問題を解決するため AWS が関わった PostgreSQL 17 新機能の例が２つ紹介されました。１つは組み込みの照合順序です。照合順序（collation）とはテキストをソートするときに利用される文字の順序を規定するもので、従来は libc、ICU といった外部のライブラリに依存していました。その場合、外部ライブラリがアップグレードされた際に、照合順序の変化によりインデックスの破損などの影響がでる可能性がありました。PostgreSQL 17 では外部ライブラリに依存しない組み込みの照合順序プロバイダを持てるようになっています。また、もう1つの例として論理レプリケーションの pg_upgrade 対応が挙げられていました。

pgroll: スキーマ移行ツール

Fujitsu の Kothari Nishchay 氏による講演 “PostgreSQL pgroll – Zero-Downtime, Reversible Schema Migrations” では、テーブル定義の変更を安全に行うためのオープンソースのコマンドラインツール pgroll が紹介されました。このツールを使うと、アプリケーションの互換性を破るような破壊的変更や、データベースをロックすることなく、スキーマ移行を行うことができます。

スキーマの変更は JSON ファイル形式でコマンドに指定します。複数のスキーマバージョンを同時に保持することができるため、アプリケーションに問題が発生した場合、元のスキーマにロールバックすることも可能です。この複数のスキーマ管理は、実際のテーブルにビューを使用して「仮想的なスキーマ」を作ることで実現されています。例えば、テーブルのカラム定義を変更する場合、実際のテーブルには古い定義のカラムを残し、新しいカラムを追加します。そして、このカラムの参照は新旧それぞれのスキーマに対応したビュー経由で行われ、。新旧カラム間のデータの同期はトリガを用いて行われます。移行が完全に完了すれば、古いバージョンのスキーマは削除可能となり、最終的に実際のテーブル定義が更新されます。

PostgreSQL と Microsoft SQL Server の違い

PostgreSQL は、他の RDBMS からの移行先としても人気が高まっています。AWS の Roneel Kumar 氏と Sameer Kumar 氏による講演 “Overcoming Challenges in SQL Server to PostgreSQL Migrations: Mapping Backups, Collations, and Case Sensitivity” では、Microsoft SQL Server（以下、SQL Server）から PostgreSQL への移行時に知っておくべき両者の違いが、二人の講演者による対話形式で紹介されました。

比較の内容は、データレイアウト、メモリ、トランザクションなどのアーキテクチャから、データ型、大文字小文字の扱いといったアプリケーション開発機能に関わるもの、バックアップやレプリケーションなどの運用面に至るまで、多岐にわたりました

例えば、トランザクションに関しては、PostgreSQL と SQL Server では同時実行制御の方法に大きな違いがあります。具体的な状況として、複数のトランザクションが同時にテーブルの同じ行にアクセスし、片方が行の更新、もう片方が参照を行う場合を考えます。PostgreSQL では基本的に MVCC（MultiVersion Concurrency Control：多版型同時実行制御）を使用しており、更新前の古い行の情報はテーブルの中に残ります。そのため、更新前の行への参照は、行の更新中でもロック待ちが発生しません。一方、SQL Server ではロックを使用しており、更新と参照の間でロック待ちが発生します。SQL Server でも Snapshot Isolation モードでは MVCC を使用しますが、その場合、古い更新前の行の情報は tempdb と呼ばれる別の領域に格納されるという違いがあります。

その他にも、データ型の違いに関して、SQL Server の bit データ型を移行するには PostgreSQL の boolean 型を使用するのが良いという情報や、SQL Server 向けに書かれたアプリケーションを PostgreSQL で動作させるためのツール Babelfish for PostgreSQL の紹介もありました。

PostgreSQL のベクトル検索

Postgres Professional (PostgresPro) の Vladlen Popolitov 氏による講演 “PostgreSQL for AI – Real Vector Search in PostgreSQL –” では、生成AIの普及により注目度が高まっているベクトル検索に関する解説が行われました。

ベクトルは、テキスト、画像、音声などのさまざまなデータを変換して生成することが可能で、これによりベクトル間の距離、つまり類似性に基づいた検索が可能になります。

このような検索機能を PostgreSQL に提供するのが、拡張モジュールの pgvector です。オープンソースであることによるコストの低さに加え、最近のパフォーマンス向上もあり、PostgreSQL + pgvector の組み合わせは、Pinecone など他のベクトル検索専用データベースと並ぶ人気の選択肢となりつつあります。

講演の前半では、pgvector がサポートするベクトルインデックスアルゴリズム HNSW（Hierarchical Navigable Small World） の概要や、パラメータ調整による検索レイテンシ・精度への影響、またベクトルサイズの削減がもたらす効果について説明がありました。

後半では、類似性検索とフィルタリング条件を併用する場合の課題について取り上げられました。たとえば、「あるテキストに似ていて、かつ著者が特定の人物で、言語が日本語であるテキストを10件抽出する」といった検索を行う場合、まずベクトルによる類似検索が行われた後に、追加のフィルタリングが実行されます。このため、初期の類似検索で十分な候補が得られなかった場合、指定件数（10件）に満たない結果しか得られないことがあります。

この課題への対応策としては、検索範囲を広げるようパラメータ設定を調整する方法がありますが、これは検索のレイテンシ（応答時間）の増加というトレードオフを伴います。別の対策として、部分インデックスを利用する方法も紹介されました。

さらに、pgvector v0.8.0 以降では新たに「反復スキャン（iterative scan）」という機能が導入されており、必要な件数が得られるまで自動で類似検索を繰り返すことが可能になっています。

最後に、フィルタリング検索用の他カラムを指定してベクトルインデックスを構築できる、マルチカラムベクトルインデックスについても言及がありました。現時点ではオープンソース実装は存在していませんが、PostgresPro が提供する商用パッケージでは既に対応しているとのことです。

Learned Index

Fujitsu Australia Limited の Gary Evans 氏による講演 “Exploring the benefits of learned indexes in PostgreSQL: Theory and Implementation” では、機械学習を活用したインデックス構造である Learned Index の理論と PostgreSQL への実装に関するアイデアが紹介されました。

インデックスは、データベースの検索性能を向上させるために広く利用されている構造で、抽象的には「キー値から対応するレコード位置を特定するマッピング」を提供するものです。たとえば、代表的なインデックス構造である B-tree は、木構造を使ってキーの探索を行います。

Learned Index は、このキー探索に機械学習モデルを応用する新しいアプローチです。まず、データの分布を学習させたモデルを使って、特定のキーが存在するおおよその位置を予測し、その周辺を効率的に探索することで、従来よりも高速な検索を実現します。また、インデックスのサイズを小さく抑えられるという利点もあります。

講演ではこの概念の解説に続き、2017年から現在に至るまでの Learned Index に関する研究の流れが紹介されました。学術界でも注目を集めるトピックであり、トップレベルのデータベース国際会議「VLDB 2023」で採択された論文のうち、11件が Learned Index に関するものであったことも紹介されました。

PostgreSQL で Learned Index の実装に取り組む理由としては、PostgreSQL の高い拡張性、pgvector などの進化する AI エコシステムの存在、Learned Index と相性の良いとされるパーティショニングや BRIN インデックス のサポート、充実したインデックスフレームワークなどが挙げられていました。また、実装アプローチとして、Learned Index の学習が進むまでは従来のインデックスと併用し、安定して動作するようになった段階で切り替えるとなどのアイデアも紹介されました。

最後に、想定される課題として、プランナによるコスト推定の精度や、複数トランザクションの同時実行時における安全性の確保などが挙げられていました。

アジアの多言語に対応した全文検索

地元タイのソフトウェアエンジニアである Vee Satayamas 氏による講演 “PostgreSQL extension that enables full-text searching on almost every known human language” は、PostgreSQL の全文検索を多言語に対応させる拡張モジュールの開発について紹介されました。

PostgreSQL には組み込みで全文検索機能が備わっていますが、デフォルトではタイ語や日本語など、主にアジアの言語には対応していないという課題が提示されました。これは、アジア開催の FOSSASIA PGDay らしい視点でもあります。

これまでにも、タイ語の全文検索に対応する拡張モジュールとして pg-search-thai が存在していましたが、長らくメンテナンスが行われていませんでした。そこで、Vee 氏はこのモジュールを Rust で再実装し、タイ語だけでなく、日本語、中国語、ミャンマー語などにも対応した chamkho-PG を開発したとのことです。

Injection Points: PostgreSQL の新しいテスト基盤

ASW の Michael Paquier 氏によるもう１つの講演 “Advanced testing with Injection Points” では PostgreSQL 17 で導入された新しいテスト機能について解説が行われました。この機能は、複数のプロセスが相互に関与するような状況のテストを容易にする、主に PostgreSQL の開発者を対象としています。

PostgreSQL コードの中には injection point と呼ばれるコードが数カ所埋め込まれており、テストコードはその箇所で特定のメッセージを出力させたり、プロセスを待機させたり、逆に待機しているプロセスを起こしたりといった様々な動作をさせることが可能となります。実際にこの機能は TAP テスト、Isolation テストと呼ばれる PostgreSQL のテストコードの中で使用されており、PostgreSQL の品質の向上に一役買っています。

実際にこの機能は、PostgreSQL のテストスイートに含まれる TAP テストや Isolation テストといった仕組みの中で活用されており、複雑な並行動作の検証や、エッジケースの再現性の向上に貢献しています。こうした Injection Points の導入により、PostgreSQL の品質はさらに高められています。

その他の発表

FOSSASIA PGDay 2025 ではこの他にも、拡張統計情報を自動生成するツール pg_stat_advisor の紹介、マルチマスタ論理レプリケーションクラスタを構築する pgEdge による DDL レプリケーションの自動化、PostgreSQL を使った メッセージキューの実装に関する議論、さらに Kafka で収集した膨大なログデータを PostgreSQL で効率的に管理するツール Bagger の紹介など、さまざまな興味深い講演が行われました。

FOSSASIA のその他の発表

続いて、FOSSASIA 2025 で行われた PGDay 以外の講演をいくつか紹介します。

ThaiLLM：タイにおけるオープンソースAIの取り組み

ビッグデータ研究所（Big Data Institute, BDI）の Tiranee Achalakul 博士による講演 “Empowering Thailand with Open Source AI: The Vision and Impact of ThaiLLMs” では、BDI の取り組みと、タイ独自の言語モデルである ThaiLLM プロジェクトについて紹介されました。

BDI はタイの公的機関であり、「医療・観光などに関するビッグデータの統合と解析」、「データの提供者と消費者を結びつけるエコシステムの構築」、「マイクロクレデンシャルを活用した人材育成」の3つがミッションとして紹介されました。

ThaiLLM は、2つ目のミッションである「ビッグデータエコシステムの構築」の一環として、国内の複数機関と連携して進められているプロジェクトです。このプロジェクトでは、タイ固有の言語や文化に適した AI モデルの開発を目指しており、生成されたモデルは 一部のデータやツール等も含めてオープンソースとして公開される予定とのことです。

Eval-Driven による生成AI開発

Mercari の Teofilo Narboneta Zosa氏と Jehandad Kamal氏による講演 “LLMOps for Eval-Driven Development at Scale” では、生成AIアプリケーションの開発における「評価」の重要性と、その方法論について解説されました。

冒頭では、生成AIアプリケーションを構成する基本要素として (1) 言語モデルそのもの、(2) 入力となるプロンプト、RAG (Retrieval Augumented Generation) により与えられるコンテキストなどのデータ、(3) モデルが生成する結果の評価の3つが挙げられ、この中でも、とくに 評価（3つ目の要素） を重視する「Eval-Centric」なアプローチが、生成AIアプリケーションの開発・運用において重要であると強調されました。

具体例として紹介されたのが、メルカリが提供する生成AI機能「AI出品サポート」です。これは、フリマに出品する商品の写真とカテゴリを入力するだけで、商品名や説明文を自動生成するというサービスです。

講演ではこのアプリケーションを例に、プロンプトの評価方法についてもいくつかの実践例が紹介されました。たとえば、最初は「タイトルの長さ」や「説明文が日本語で書かれているか」といった単純なヒューリスティック評価からスタートし、人間からその後は生成モデル自身を用いた評価、いわゆる LLM-as-a-Judge の手法を導入。また、トレーディングカードなどのニッチな商品に関しては、生成された説明文の事実性を検証するための工夫も必要であったことが語られました

後半では、評価を素早く反復できるようにするための具体的な実践として、モデルの入力や出力を可視化する可観測性の確保、プロンプトやデータセットのバージョン管理による再現性の確保、そして評価の自動化を支えるツールの導入といった、評価基盤の整備が重要であることが強調されました。

さまざまなデータベース

FOSSASIA Summit 2025 では、PostgreSQL 以外にもさまざまなデータベースに関する講演が行われました。

例えば、YDB の Evgenii Ivanov 氏の講演 “Designing YDB: Constructing a Distributed DBMS for OLTP and OLAP from the Ground Up” では、オープンソースの分散データベース管理システムである YDB が紹介されました。YDB は OLTP と OLAP の両方に対応したリレーショナルデータベースであり、コンピュートとストレージを分離し、数千台のサーバ上で動作可能な分散アーキテクチャを採用しています。また、分散トランザクションによって ACID 特性を満たす強い一貫性を提供するとのことでした。

講演の冒頭では、名前が似ている分散データベース管理システムである「YugabyteDB」とは別物であることが軽く触れられ、その後、主に分散ストレージのアーキテクチャについて詳しく説明されました。

さらに、WebStoating Pte. Ltd. の Ilya Verbitskiy 氏による講演 “Unlocking the Power of Graph Databases with Neo4j” では、グラフデータベース Neo4j の概要と、その問い合わせ言語である Cypher クエリの紹介がありました。また、MySQL の Phasupong 氏による講演 “MySQL Document Store” では、MySQL における JSON 型のサポートとその活用方法について解説が行われました。

特定のデータベースソフトウェアに特化していない講演として、Grab の Chin Hwee Ong 氏による “Your Data is Late Again! Handling Late-Arriving Data in the Modern Data Stack” では、データ処理基盤における遅れて到着するデータへの対応方法について解説されました。

講演の冒頭では、遅れたデータを正しく捉えるために重要な「時間」の概念として、(1) 現実世界でイベントが発生した時刻である Valid Time（有効時間）、(2) システムにデータが記録された時刻である System Time（システム時間）の2つが紹介されました。

その後、遅れて到着するデータが下流システムに与える影響を防ぐための方法として、遅延データの検出やデータ整合性を確認する手法が解説されました。また、遅れて到着したデータを差分的に処理する際の注意点についても触れられました。特に、遅れをどの程度まで遡って処理するかを決めることで、精度とパフォーマンスのトレードオフを調整する方法が紹介されました。

生成AI関連

上で述べたメルカリの講演以外にも、生成AIに関する講演も多数ありました。

例えば、Fleek Network の Mohit Bhat 氏による講演 “All About AI Agents: Building Your Own Open Source AI Agent to Post on Your Behalf” では、AI エージェント作成に必要となる基本概念として、LLM (言語モデル)、Embeddings (埋め込み)、RAG (Retrieval-Augmented Generation) について解説され、さらに ElizaOS などのフレームワークを用いた実践的なアプローチが紹介されました

また、Michael Christen 氏による講演 “The Complete Anatomy of ChatGPT: A Precise Breakdown of LLMs and Transformers” では、生成AIの発展を歴史的に振り返る内容が紹介されました。具体的には、マルコフ連鎖（1906年）から始まり、シャノンの情報理論（1948年）、パーセプトロン（1957年）、中国人の部屋（1980年）といった思考実験、リカレントニューラルネットワーク (RNNs)（1996年）、Convolutional Networks (CNNs)（1998年）、Embeddings（2002年）、アテンションメカニズム（2014年）、GPT-1（2018年）に至るまでの重要な理論や技術をエポックメイキングな論文を引用しながら、2022年に登場した ChatGPT へと至る過程を解説する大変興味深い内容でした。

データベースに関する講演として先に紹介した YDB と、生成AIに関する講演として YDB の Alexander Zevaykin 氏と Elena Kalinina 氏による “YDB: How to implement streaming RAG in a distributed database” では、YDB の非構造データのメッセージング機能「トピック」とベクトル検索機能を用いて、継続的に流入するデータに基づく RAG である「Streaming RAG」を実装する方法が解説されました。

Tor が支える匿名性と自由

セキュリティの分野では、The Tor Project の Roger Dingledine 氏による講演 “Tor: privacy for everyone” では、プライバシー保持のための技術である Tor について、その考え方と仕組みが紹介されました。「匿名性」という概念の捉え方は人によって異なり、例えば市民にとってはプライバシー、ビジネスにとってはセキュリティ、政府にとっては通信解析の障害となり得る一方、人権活動家にとっては情報への到達可能性を意味します。例えば、ある国では、BBC のニュースを政府によって阻止されずに読むために Tor が使用されている例が紹介されました。このように、社会的に弱い立場にいる人々にとってこそ、技術は特に有用であるという主張がなされました。

おわりに

今回の FOSSASIA Summit 2025 に参加して、まず感じたことは、タイおよびアジアにおけるオープンソースコミュニティの活力でした。特にタイ国内では、独自の言語モデル「ThaiLLM」のプロジェクトに代表されるように、オープンソース技術を活用したデジタル経済の普及・発展に力を入れていることが伺えました。

講演内容は、やはり全体的に AI 関連の話題が多く、オープンソースにおいてもこの分野がこれからさらに発展していくであろうことが感じられました。筆者は業務で主に PostgreSQL やデータベースの分野に関わっていますが、AI と関連する領域についての理解を深める必要性を改めて実感しました。

また、FOSSASIA はオープンソース技術全般の普及や発展を目的とする組織であるため、特定のオープンソース製品だけではなく、関連する概念や理論、アイデアについての発表も多かったことが印象的でした。まさに、オープンに知識や技術を共有する場として非常に刺激的なイベントでした。

はじめに

PGconfEU は、PostgreSQL Europe が主催する大規模なカンファレンスで、毎年ヨーロッパの都市で開催されます。このカンファレンスでは、世界中の開発者やユーザーが一堂に会し、PostgreSQL に関する最新の情報や技術を共有する貴重な機会となります。

筆者は今回はレポーターとしてこのイベントに参加しました。普段は PostgreSQL の技術サポートを業務としているので、今回のカンファレンスでは、多くの知識や経験を吸収し、自身のスキルを向上させることも参加目的の１つでした。

会場となった Divani Caravel Hotel は、アテネの中心に位置し、美しい景色を楽しむことができる場所でした。発表セッションが 4 つの部屋で並行して行われ、参加者はそれぞれ興味のあるトピックに応じてセッションを選ぶことができました。

本レポートではいくつかの印象的な発表をピックアップし、その要点や感想を紹介します。

削除されたデータの復元方法

CYBERTEC の Christoph Berg の講演 “UNDELETE data FROM table;” は、削除されたデータをどのようにして「復元」できるかというテーマでした。データを削除した場合、トランザクション内で削除されたデータならばロールバックによって元に戻すことができますし、
ベースバックアップから PITR（Point-In-Time Recovery）を使ってデータを復旧する方法もあります。

今回はその他の手段として、“pg_dirtyread” という拡張機能を使うことで削除された行を読み取る方法が紹介されていました。

pg_dirtyread を使うと、テーブル内の削除された行も SELECT 文を使って表示できるようになります。特に、出力された行の xmax システムカラムを調べることで、それが削除された行であるかをチェックすることができます。（PostgreSQL では xmax というシステムカラムに行を削除したトランザクションの ID が格納されます。）このように、pg_dirtyread を使用することで、失われた行を再びテーブルに挿入することが可能になりますが、削除された行の内容がその後の更新や VACUUM によってページから失われていた場合には復元することができません。

ページから失われたデータを復元するには、PostgreSQL に同梱されているツールである pg_waldump を使うことで削除されたデータがどのように WAL に記録されているかを確認することができます。PostgreSQL では通常 FPW（Full Page Write）が ON となっており、CHECKPOINT 以降の初回のページ変更時にテーブルのページイメージ全体が WAL に出力されています。そのため、行が削除される前のテーブルページの状態を WAL から確認することができます。PostgreSQL 16 以降では pg_waldump に –save-fullpage オプションが追加され、フルページの内容を保存できるようになりました。この方法を使用することで、削除されたデータが含まれているページを特定のディレクトリに抽出し、それを元にデータを復元することができます。

もちろん普段からバックアップを取るのが重要であり、データ復旧には PITR を利用するのが一般的なのですが、以上のように pg_dirtyread と pg_waldump を使って削除されたデータを復元する方法もあることを紹介する発表でした。

PostgreSQLのコネクションプーラーの比較

コネクションプーラーは、PostgreSQL データベースのパフォーマンスを最適化するための重要なミドルウェアであり、特に接続管理において大きな役割を果たします。この機能によって接続数が過剰になる問題が解決され、データベースの負荷が軽減されます。CYBERTEC の Julian Markwort の講演“Comparing Connection Poolers for PostgreSQL” では PostgreSQL におけるコネクションプーラーの役割や利点、課題、および代表的なプーラーの比較について学ぶことができました。SRA OSS が中心となって開発しているクラスタリングツールで、サポート業務で取り扱うことの多い “Pgpool-II” のコネクションプール機能についても紹介されていました。また、“Odyssey” や “pgagroal” 、“PgCat” といった 2019 年以降に登場した比較的新しいプーラーについても、今回初めて知ることができました。

紹介されていたコネクションプーラーには以下のものがありました：

• Pgpool-II: 様々な機能を持つクラスタリングツール。設定がやや複雑。
• PgBouncer: コネクションプールの機能に特化した軽量のプーラー。
• Odyssey: スケーラブルなマルチスレッド設計のプーラー。
• pgagroal: 高性能を目的に新たに設計されたプーラー。
• PgCat: シャーディング、ロードバランシング、フェイルオーバー機能を持つマルチスレッド設計のプーラー。
• Supavisor: クラウドネイティブなコネクションプーラー。

どのプーラーを選ぶべきかについては、発表者の直感に基づいた個人的意見であると断った上で、以下のような特徴をあげていました：

• PgBouncer は広く使われており、学習コストも低いのでおすすめ。
• PgCat も機能の追加も進んでおり最有力な候補。
• pgagroal は性能問題を時期尚早に解決しようとして行き詰まっているように見え、いくつかの機能も欠けている。
• Odyssey は他のプーラーにも影響を与えた新しい試みだったが、メモリリークなどの問題が残っている。

論理レプリケーションのセットアップを高速化する

EDB の Euler Taveira が発表した “Speeding Up Logical Replication Setup” では、
論理レプリケーションのセットアップを迅速化する方法として、PostgreSQL 17 の新機能「pg_createsubscriber」が紹介されました。

論理レプリケーションを構築したときには、最初にレプリケーションするテーブルデータの初期コピーが行われます。各テーブルごとに起動する tablesync ワーカプロセスの中で COPY … TO STDOUT を利用してデータを取得し、データが同期された後に、論理レプリケーションによる変更の適用が開始されます。しかし、この方法では各テーブルが個別に処理されるため、完了までに時間がかかる場合があります。一方で、pg_createsubscriber は物理ストリーミングレプリケーションのスタンバイサーバを元にして、論理レプリケーションのサブスクライバサーバを作るコマンドあり、テーブルの初期コピーを行わず、論理レプリケーションの構築を迅速に行うことが可能です。この講演では、サイズに応じたパフォーマンス改善の例も示され、例えば 20GB のデータで 13 倍の速度向上が見込まれるとされました。また、今後の pg_createsubscriber コマンドの機能改善のアイデアとして、ベースバックアップからのサブスクライバ構築、完了時のサーバー起動、指定されていないデータベースの削除、特定のテーブルの指定、サブスクライバ構築後に物理スタンバイを無効にしない、といったことを可能にするオプションの追加が挙げられていました。

AI と地理情報システム

Redgate Software の Grant Fritchey が発表した“Leveraging AI as a PostgreSQL DBA” の講演では、データベース管理者（DBA）が AI をどのように活用できるか、またその効果的な使用法について詳しく説明されました。現在、人工知能（AI）は非常に注目されているテーマです。AI は単に「新しい技術」として存在するだけでなく、DBA の仕事をより効率的に行うための強力なツールとなり得ます。具体的な実践例として、いくつかのタスクにおける AI の活用方法が示されました。例えば、データベース設計、データ生成、テストスクリプト作成、クエリ最適化、コード評価などが挙げられます。紹介されたツールには、ChatGPT、Microsoft CoPilot、Google Gemini、Perplexity、You.com、Brave.com などが含まれていました。筆者自身も普段、ChatGPT や Microsoft CoPilot を使用しており、その効果を実感しています。また、AI の結果を鵜呑みにせず、「trust, but verify（信頼するが、確認する）」という考え方を持つことが重要ということが主張されていました。

生成 AI を効果的に活用するためには、AI に与える命令や指示を記述した文であるプロンプトの質が非常に重要です。これに関してはは、以下のポイントが強調されていました。

• Clarity, clarity, clarity: 明確さが重要。
• Use appropriate terms: 適切な用語を使用する。
• More detail is better: より詳細な情報が結果を改善する。
• Context matters: 文脈を理解することが必要。
• Stop digging, start over: 回答の方向性がおかしい場合は、無理やり修正しようとしないで最初からやり直す。

MICROSOFT の Varun Dhawan の講演 “Using Postgres to locate the best coffee near you!” では、PostgreSQL と地理情報を扱うための拡張モジュール “PostGIS”、さらにベクトルデータを組み合わせて、自然言語クエリを活用する方法について説明がありました。特に、「最寄りのコーヒーショップはどこですか？」という質問に対して正確な結果を得る手法が紹介され、PostgreSQL の多様な機能を組み合わせることで、シンプルなキーワードマッチングから強力な文脈認識検索ソリューションへの進化が強調されました。さらに、AI を活用した方法として、ベクトル化されたデータセットから関連情報を抽出し、OpenAI の大規模言語モデルに渡すことで、より正確な回答を生成するアプローチも紹介されました。この手法は RAG（Retrieval-Augmented Generation）という技術で、簡単に言うと、ユーザーの質問に対して、データベースから関連する情報を検索し、その情報を文脈として与えることで、生成 AI からより適切な回答を得る方法です。

RAG のプロセスでは、まずユーザーのクエリ（例えばコーヒーショップの検索クエリ）を受け取り、それをベクトル化します。次に、ベクトルデータベース（PostgreSQL）から関連するコンテキスト（例えば、コーヒーショップのレビュー）を検索し、取得したコンテキストを大規模言語モデル（OpenAI）に渡し、言語モデルが応答を生成する流れとなります。この統合により、AI と PostgreSQL を活用した効果的な情報検索が実現可能となります。

Deriv の Jimmy Angelakos が発表した“–Mom, can we have G**gle Maps? –We have G**gle Maps at home” は、PostgreSQL と PostGIS を使って “OpenStreetMap (OSM)” のデータを取り込み、GISの機能を実現する方法に焦点を当てています。この講演は「高価な API が本当に必要か？既存の無料で強力なオープンデータソースである OpenStreetMap と、PostgreSQL + PostGIS の組み合わせで十分では？」という問題提起から始まりました。OpenStreetMap (OSM) は無料で利用できる地理データベースであり、PostgreSQL と組み合わせることで、さまざまな空間データクエリやジオコーディング（情報に対して関連する地理座標を付加すること）を実現できます。OSM データは、PBF や XML 形式のダンプとしてエクスポート可能で、簡単に PostgreSQL に取り込めます。このプレゼンテーションでは、OSM データを PostgreSQL にインポートするツールとして “PgOSM Flex” の使用が紹介されました。

PostgreSQL セキュリティ

CYBERTEC の Taras Kloba の講演 “PostgreSQL Security:Defending Against External Attacks” では、データベースセキュリティの重要性を再認識させられました。特に、過去の PostgreSQL の脆弱性が悪用されることで LinkedIn や OpenTable などで実際に発生した具体的なデータ漏洩事例に基づいて解説されたことで、PostgreSQL の脆弱性がどれほど危険であるかを深く理解することができました。これにより、データベースのセキュリティ対策が単なるオプションではなく、企業や組織の持続可能性にも直結する必須事項であることを強く認識しました。

具体的な対策として、PostgreSQL の最新パッチを適用すること、アクセス制御を強化すること、SSL 接続を強制すること、そしてTDE（透過的データ暗号化）を導入するなどが紹介されており、日々の業務において重要な手段として非常に参考になりました。さらに、権限昇格による脆弱性を回避するため、ユーザ関数定義時の SECURITY DEFINER の使用を制限することや、COPY FROM PROGRAM の実行権限をスーパーユーザのみに付与するといった実務的なアドバイスも示されており、これらは実際のシステム運用において非常に役立つ内容であったと感じます。

ワイヤプロトコル

現在の PostgreSQL で使用している通信プロトコルは、2003 年にバージョン 7.4 で導入され、以来多くの新機能が追加されていますが、プロトコル自体は大きく変更されていません。このプロトコルは、PostgreSQL の効率的な操作を支え、様々なクライアントライブラリやミドルウェア、さらには他のDBMS実装でも広く利用されています。Neon,inc の Heikki Linnakangas の講演 “The Wire Protocol” はこの通信プロトコルを解説するもので、メッセージ構造、認証、クエリの実行やキャンセル、COPY、レプリケーション機能、将来に向けたプロトコルの拡張といったトピックが含まれていました。

筆者はプロトコルについての知識にあまり馴染みがなかったため、PostgreSQL のプロトコルの特に認証やクエリの実行方法、COPY プロトコルの使用など理解するのが難しい部分もありました。しかし、プロトコルを学ぶことで、データベースがどのように動作しているか、また、より効率的にクエリを実行したりエラーハンドリングを行ったりするための手助けになると感じられ、今後、この講演を機に少しずつでもプロトコルに関する知識を深めていきたいと思うようになりました。

マテリアライズドビューの増分更新

弊社の長田の講演 “pg_ivm: Extensions for Rapid Materialized View Update” では、マテリアライズドビューを迅速に更新するための機能を PostgreSQL に提供するの拡張モジュール “pg_ivm” が紹介されました。マテリアライズドビューは、クエリの結果を保存するデータベースオブジェクトであり、クエリ応答を迅速にするために使用されますが、基になるテーブルが変更されると、その状態を最新に保つためにはビューの更新が必要です。pg_ivm は、Incremental View Maintenance（IVM）という手法を使用し、ビューの全ての行を更新するのではなく、「増分」のみを計算して、マテリアライズドビューを迅速に更新できる拡張モジュールです。

この拡張モジュールは、PostgreSQL 13 から 17 のバージョンで使用可能で、通常の REFRESH コマンドで 20 秒かかるビューをわずか 15 ミリ秒で更新できる例が紹介されていました。従来のマテリアライズドビューと比較して、更新が 500 倍以上速くなる場合もあり、大きなパフォーマンス向上が期待できます。また、今後の計画や機能要望として、外部結合や論理レプリケーションのサポートや、GROUPING SET や ROLLUP を含む高度な集計機能の対応があげられていました。

以前、pg_ivm について深く学ぶ機会はありませんでしたが、今回の講演を通じて、学習者としてだけでなく開発者の視点からも、その仕組みなどの難しさを実感することができました。

ライトニングトーク

最後に、最終日に行われたライトニングトークの様子についてご紹介します。

ライトニングトーク（Lighting talks）とは、通常、非常に短いプレゼンテーション形式のことを指します。一般的に、各プレゼンテーションは 5 分から 10 分程度の短時間で行われ、参加者が素早く情報を共有したり、新しいアイデアを紹介したりする場です。

今回のライトニングトークは 13 トピックがあり、その中で私に印象に残ったのは、motherduckdb の Jelte Fennema が発表した “pg_duckdb: Challenges and Benefits of Elephants with Eaks” でした。

“pg_duckdb” は、“DuckDB” を PostgreSQL の内部で利用可能にする拡張モジュールです。DuckDB は「分析用の SQLite」とも呼ばれ、複雑な分析クエリをサポートするインメモリ型の分析データベースです。“SQLite” と同じく組み込み用途のデータベースですが、分析作業に特化しており、非常に効率的に動作します。

pg_duckdb の特徴として、DuckDB の強力な分析エンジンを PostgreSQL に統合することで、ユーザーは従来の SQL エンジンに比べて圧倒的に高速な分析処理を実現できます。この拡張機能は 2024 年 10 月に最初のリリース（v.0.1.0）が公開され、parquet や CSV 形式のデータを BLOB（バイナリデータストレージ）から読み書きする機能を提供します。また、PostgreSQL テーブル上で DuckDB エンジンを使用したり、DuckDB のカラム型フォーマットを利用して一時テーブルを作成したりすることができます。さらに、MotherDuck というサーバーレスのクラウド分析プラットフォームへの分析処理のオフロード機能もあり、より効率的なデータ処理を実現します。この技術は、まるで象がダックに乗っているようなイメージです。象は飛べたり歩けたり泳いだりすることができ、いろんなものを食べて生きていくことができます。同じように、pg_duckdb は環境の変化にも強く、高速な分析を可能にします。

おわりに

PostgreSQL Conference Europe 2024 では、AI や PostgreSQL 17 の新機能、拡張機能に関する多くの講演がありました。普段の業務で知っているトピックもありましたが、知らなかった知識もたくさん得ることができました。特に、AI の活用方法や PostgreSQL 17 の新機能についての発表は、私にとって非常に興味深く、業務に活かせる具体的なナレッジを得ることができました。

また、発表者のトークスタイルやプレゼンテーション技術からも学ぶことが多く、技術的な内容だけでなく、コミュニケーションの大切さも再確認しました。さらに、ドイツや中国からの参加者とも交流し、お互いの仕事内容やカンファレンスの発表内容について話すこともできました。このような楽しい時間を過ごせたことは、私にとって貴重な経験でした。

参加者 781 名という大規模なイベントで、多くの方々と意見を交わし、さまざまな視点を学ぶことができたのは貴重な機会でした。アテネの美しい風景もこのカンファレンスを特別なものにしてくれました。青い空と古代遺跡が調和する光景は、まるで歴史が息づいているかのようで、街を歩くたびにその魅力に引き込まれました。コーヒーとビールもとても美味しかったです！

今回のカンファレンスでは、他国の参加者との出会いを通じて、それぞれの文化や背景を知ることで PostgreSQL に対する理解がさらに深まりました。このカンファレンスで得た知識やつながりを活かし、今後も自分の成長につなげていきたいと思います。

はじめに

PGConf.dev の正式名称は PostgreSQL Development Conference で、PostgreSQL のユーザや開発者、コミュニティ関係者が集まる、PostgreSQL の開発とコミュニティの発展に焦点を当てたイベントです。これまでは、年に一度のカンファレンスとして PGCon が同じくカナダのオタワで開催されていましたが、昨年の PGCon 2023 が最後となり、PGConf.dev はその後継イベントにあたります。つまり、今回は PGConf.dev の記念すべき初めての開催となります。 SRA OSS LLC はブロンズスポンサーとして、このカンファレンスの支援をさせていただきました。

今回の会場となったのは、バンクーバーのランドマークであるハーバーセンターの麓にあるサイモン・フレイザー大学（SFU）のバンクーバー・キャンパスです。全４日間の日程のうち、初日には PostgreSQL コミュニティの運営などが議論される “PostgreSQL Developer & Leadership Meeting”（招待制）や、拡張モジュールについての議論をアンカンファレンス形式で行う Extension Ecosystem Summit などが行われました。カンファレンスが本格的に始まるのは２日目からで、朝のオープニングセッションに続いて、様々な講演発表が２日間に渡って３トラック並行で行われました。最終日にはアンカンファレンスが行われた後に、クロージングとなりました。本レポートでは、これらの発表の中からいくつかピックアップして紹介します。

なお、以降では PostgreSQL 17 の新機能や改善について言及している箇所がありますが、それらは全て執筆時にリリース済の PostgreSQL 17 beta1 を元にしています。PostgreSQL 17 の正式リリースは 2024 年の秋頃を予定しており、それまでに状況が変わっている可能性もあることにご注意ください。

PostgreSQL の I/O 改善

Microsoft の Thomas Munro の講演 “Streaming I/O and vectored I/O” では、PostgreSQL がディスク上のテーブルデータにアクセスする際に、複数のブロックを同時に、さらに最終的には事前にバックグラウンドで読み書きすることを可能にする「ストリーミング I/O」の試みについて解説されました。

従来の PostgreSQL ではテーブルをディスクから読む際に、サイズが 8kB のブロック１つ毎に、 OS に読み込み要求を発行しています。これに対し、vectored I/O（scatter/gather I/O とも呼ばれます）という方法を使うことで、OS に１つの要求を発行するだけで複数ブロックの同時読み込みができるようになります。

この複数ブロックの同時読み込みは PostgreSQL 17 の改善として取り込まれており、後に必要となるブロックの番号をコールバック関数を介して伝えることで、事前に読み込んだブロックを１つずつ返すインタフェース（streaming API）として実装されています。先読みの程度と方法についてはデータのアクセスパターン（シーケンシャルか、ランダムアクセスか）によって適応的に調整されるようになっています。PostgreSQL 17 では実際にこの API を利用してテーブルのシーケンシャルスキャン、 ANALYZE 処理、pg_prewarm が改善されています。一方で、今回実装された streaming API は、将来 PostgreSQL に非同期 I/O（asynchronous I/O）を実装するための布石でもあります。本当の非同期 I/O は PostgreSQL 17 にはまだ実装されませんが、そのための準備は少しずつ進んでいるようです。

PostgreSQL 17 とその後

Fujitsu の Amit Kapila による “PostgreSQL 17 and beyond” は、次期 PostgreSQL の新機能や改善をわかりやすく解説する、もやは定番となったシリーズの講演です。PostgreSQL 17 の特徴を、Storage, Logical Replication, SQL, Security, JSON, Monitoring のセクションに分けて紹介していました。新機能の中でも目立つのは、増分バックアップ（incremental backup）のサポートや、ロジカルレプリケーションのレプリケーションスロットのフェイオーバ機能や pg_upgrade 対応、VACUUM の改善でしょうか。パーティションテーブルでパーティションの SPLIT（分割）と MERGE（併合） が可能になったことや、SQL/JSON 標準である JSON_TABLE のサポートも目新しいかもしれません。

最後に PostgreSQL 18 以降に向けて議論されている機能を紹介するのもいつもの流れです。今回は、透過的カラム暗号化、非同期 I/O に向けた取り組み、統計情報のインポート・エクスポート、ロジカルレプリケーションのDDL やシーケンス対応などが挙げられていました。その中には、弊社顧問の石井が取り組んでいる「行パターン認識（Row Pattern Recognition: RPR）」についても言及がありました。こちらについては、今回の PGConf.dev でも発表がありましたので、後ほどご紹介いたします。

Adaptive Radix Tree による VACUUM の性能改善

AWS の Masahiko Sawada による “PostgreSQL meets ART – Using Adaptive Radix Tree to speed up vacuuming” は、PostgreSQL 17 で改善された VACUUM の性能についての講演です。Adaptive Radix Tree (ART）はその改善のために PostgreSQL に実装された新しいデータ構造です。講演では Adaptive Radix Tree の概要の説明に続いて、それがどのように VACUUM の改善に使われているのか解説されました。

VACUUM はテーブルの中に発生した不要タプル領域を回収して再利用できるようにする処理ですが、その際には、まずテーブルをスキャンして不要タプルのタプルID (TID) をリストアップします。その後に、リストに含まれる TID に対応するインデックスエントリとテーブルタプルの回収が行われます。従来の PostgreSQL では、TID のリストは配列に格納されていました。しかし、この配列を用いた方法には、大きなメモリを事前に確保する必要がある、メモリ使用効率が悪い、使えるメモリ上限に 1GB の制限がある、TIDの検索に時間がかかる、といった問題がありました。そこで、従来の配列に替わる新しいデータ構造を検討した結果、採用されたのが Adaptive Radix Tree です。これにより、大きなメモリの事前確保は不要となり、メモリ使用効率も良くなり、1GBという上限もなくなり、さらに TIDの検索が高速化されました。発表の中の性能評価の結果では、PostgreSQL 16 と 17 で VACUUM 実行結果を比較した結果、実際にメモリ使用量と実行時間が大きく削減できていることが示されました。一方で VACUUM は多くのユーザが必然的に使用する重要な機能のため、beta 版のうちに何か問題がないか是非テストをして欲しい、という聴衆へのメッセージで講演は締めくくられていました。

SLRU キャッシュの改善

EDB の Dilip Kumar による講演 “Problem in PostgreSQL SLRU – And how we are optimizing it” は、PostgreSQL の SLRU と呼ばれるメモリ管理システムの問題点とその改善について解説するものでした。

PostgreSQL はトランザクションに関する様々なデータをディスク上に持っています。代表的なものは WAL ですが、それ以外にもトランザクションのコミット状態（CLOG と呼ばれるもので、pg_xact ディレクトリに格納されている）や、サブトランザクションの状態（pg_subtrans）、共有行ロック取得時に使用されるマルチトランザクション状態（pg_multixact）などがあります。これらの情報は頻繁にアクセスされるため共有メモリ上にキャッシュされているのですが、そのキャッシュを管理しているのが SLRU (Simple Least Recently Used) です。

従来の PostgreSQL では SLRU へのアクセスが集中するような状況で劇的な性能劣化が観測されることがありました。例えば大量のサブトランザクションが発生する場合（多量の SAVEPOINT や PL/pgPSQL の EXCEPTION の使用）や、多量の共有行ロックが発生するような状況です。この発表では、そのような状態を意図的に作り出すことで実際に性能劣化をおこることを紹介していました。問題の原因としては、SLRU キャッシュのサイズが小さく頻繁にバッファ置き換えが発生していること、ロック競合が起きていること、CPU キャッシュミスが頻繁に発生していることの３つが挙げられています。

PostgreSQL 17 では SLRU の改善がいくつか行われています。まず、設定により各 SLRU キャッシュのサイズを変更できるようになったこと。次に SLRU キャッシュの内部を複数の “bank” に分割することで情報検索が早くなったこと、そして、ロックを bank 単位に分割することで競合を減らしたことです。発表によると、これらの改善によって SLRU への負荷が高い状況で２〜３倍の性能向上が見られたとのことでした。

PostgreSQL でデータの「パターン」を検索する

これまでは主に PostgreSQL 17 に入る予定の機能や改善に関する発表を紹介してきました。その以外にも、将来の PostgreSQL に向けた提案に関する発表もいくつかありました。その内の１つが、SRA OSS の顧問である石井達夫（Tatsuo Ishii）による行パターン認識の実装について講演 “Implementing Row Pattern Recognition” です。

「行パターン認識（Row Pattern Recognition: RPR）」とは、SQL 標準（SQL:2016）で定義されている機能の一つで、SELECT 文で時系列データなどの行の並びに関する「パターン」を指定して検索ができるものです。例えば、株価の時系列データの中から「株価が上昇してから下降する」といったパターンが現れる箇所を検索することができます。

SQL 標準には２種類の行パターン認識の文法があります。１つは FROM の後ろに MATCH_RECOGNIZE 句を書いてその中で行パターン認識を定義するもので、もう１つは WINDOW 句の中に行パターン認識の定義を書くものです。今回の提案では実装のしやすさから後者の文法が選ばれました。また、行パターンの指定には正規表現を用いるのですが、現状対応している正規表現も今はシンプルなもののみとなっています。

この機能を実装したパッチは PostgreSQL 18 向けに提案されており、開発コミュニティのメーリングリストで議論が進行中です。今のパッチには新しい機能を加える予定はなく、メモリ消費を抑えるなどの改善に留めておき、それがコミットされた後に機能の追加や対応する正規表現の拡充などを予定している、とのことです。また、聴衆の中にメーリングリストでの行パターン認識の議論に参加していた人がいたらしく、発表終了後に話が盛り上がっている様子でした。

PostgreSQL の拡張性とその課題

PostgreSQL の特徴の１つは拡張性の高さと言われており、PostgreSQL に機能を付与する拡張モジュールが数多く開発されています。今回の PGConf.dev 2024 でも、拡張機能に関する講演や議論が多くありました。初日に行われた Extension Ecosystem Summit や、最終日のアンカンファレンスにおいても、PostgreSQL 本体が提供するインターフェース（ABI/API)、パッケージング、拡張モジュール管理方法、など様々な議論がされていたのに加え、拡張モジュールを取り巻く状況の改善に関する発表が複数ありました。

その１つが、TileDB の Abigale Kim による “Anarchy in the Database: A Survey and Evaluation of Database Management System Extensibility” です。PostgreSQL を含むいくつかの DBMS の拡張機能を調査したというこの講演によると、PostgreSQL は他の DBMS に比べて柔軟性の高い拡張機能を持ち、また実際に拡張モジュールの数も桁違いに多いようです。一方で、複数の拡張モジュールを組み合わせると動かなくなる、といったような現象もよく見られます。講演の中で紹介された例は、分散データベース機能を提供する著名な拡張モジュールである citus と、PostgreSQL に同梱されている auto_explain を同時に使うとエラーが発生する、といったものでした。

調査のため、メジャーな拡張モジュールを 114 個選択し、その組み合わせを試してみたところ、その内 17% の組み合わせで問題が発生したとのことでした。解析の結果、そのような問題の発生と相関が高かった要因としては、「複数のPostgreSQLバージョンに対応するようなロジック」「ユーティリティコマンドに対するフック (ProcessUtility_hook) の使用」などが見つかったそうです。

このような PostgreSQL の柔軟な拡張性と安全性や保守性の懸念の関係を、発表者は「諸刃の剣（a double edged sword）」と表現していました。発表の最後ではこの問題への対処として、拡張モジュール管理の仕組みを作ることや、拡張モジュール間の互換性をチェックするツールを作ることなどが示唆されていました。

pgvector：ベクトルデータベースとしての PostgreSQL

PostgreSQL の拡張モジュールを紹介する発表もいくつかあり、そのうちの１つが AWS の Jonathan Katz による “Vectors: how to better support a nasty data type in PostgreSQL” です。これは、ベクトルデータの類似性検索機能を提供する拡張モジュール pgvector と、その課題についての講演です。生成AIの話題が尽きない昨今、pgvecto は最も人気にある PostgreSQL の拡張モジュールの１つと言えるでしょう。

この発表では導入として、生成AIを用いた Retrieval Augmented Generation (RAG) におけるベクトルデータの果たす役割について解説されました。RAG とは何かをごく簡単に言えば、ユーザからの質問をそのまま生成AIに送るのではなく、ユーザの質問に関連する情報をデータベースから検索し、その情報を「文脈」として与えることで、生成AIからより適切な回答を得ようとする方法のことです。この時「ユーザの質問に関連する情報の検索」のときに行われるのがベクトルデータの類似性検索です。データベース内の情報は予めベクトルデータに変換（embedding) しておきます。ユーザの質問もベクトルデータに変換した上で、その質問と最も「近い」情報を「ベクトルデータの類似性」に基づいて検索するわけです。

発表では pgvector の概要、サポートしているインデックス（IVFFlat, HNSW）、過去一年の pgvector の性能向上についての説明がされた後、最後は pgvector の課題についての話題となりました。そのうちの１つが高次元ベクトルのデータサイズです。たとえば、3072 次元のベクトルの場合、そのサイズは 12kB にもなる（1次元が 4 byte の場合）のですが、このサイズは PostgreSQL の標準のブロックサイズである 8kB を超えています。実際には TOAST という技術により、テーブルにはこのサイズのデータを格納することはできるのですが、インデックスには TOAST が適用されないため、そのような高次元ベクトルではインデックスを生成できません。この問題に対して PostgreSQL 側で可能な対策としては、TOAST をインデックスに適用できるよう改良したり、インデックスのページサイズを 8kB 以上に変更できるようにする、といった案が示唆されていました。その他にも、pgvector でパラレルクエリがサポートされていなかったり、類似性検索実行時には外部サーバでの非同期実行が動作しないなどの課題が挙げられていました。

適応的クエリ最適化

Postgres Professional の Alena Rybakina による講演 “Adaptive query optimization in PostgreSQL” においても興味深い拡張モジュールが紹介されていました。

PostgreSQL はカラム値の分布などの統計情報を元にして適切なクエリ実行計画を選択します。その時に行われるのは、結果行数（cardinality) の推定ですが、クエリが複雑だったり、カラム値の分布に偏りや相関がある場合には正確な推定ができず、あまり適切ではない実行計画が選ばれることがあります。これを是正するため、PostgreSQL には拡張統計情報という機能がありますが、これを適切に設定するのはそう簡単ではありません。

この講演で紹介している Adaptive Query Optimizer（AQO, 適応的クエリ最適化）は、繰り返し実行されるクエリの統計情報を記憶・学習することで適切な実行計画の生成を助ける拡張モジュールです。具体的には k-近傍法を用いて、クエリに含まれる条件の選択率に基づいて、実行結果として出力される行数を推定しているようです。Join Onder Bechmark というベンチマークでテストしたところ、ほとんどのクエリで行数推定の誤りが改善され、実行時間が短縮されていることが示されていました。現状の課題として、一時テーブルを含むクエリやスタンバイサーバでの動作には対応していないらしく、これらは将来の計画として挙げられていました。

より良いコミュニティを目指して

ここまで PostgreSQL の技術的な発表についていくつか紹介してきましたが、今回の PGConf.dev 2024 ではより良いコミュニティのあり方についてのセッションもありました。４人のコミッタ Amit Langote, Masahiko Sawada, Melanie Plageman, Robert Haas による “Making PostgreSQL Hacking More Inclusive” では、PostgreSQL 開発コミュニティをより良くしてくために、様々な背景を持つ発表者の経験や考えを共有するというものでした。発表者の２人が日本からの参加であることもあり、英語話者でない人にとっての議論の難しさなど共感できる内容が多かったです。曖昧な言葉ではなく直接的に伝えるのが重要であるという考えは複数の発表者で共有されているようでした。

アンカンファレンス

最後に、最終日に行われたアンカンファレンスの様子についてご紹介します。

アンカンファレンスとは、講演者や話す内容があらかじめ決まっているのではなく、参加者がその当日にその場で話題を提案して議論する形式のイベントです。議論したいことがある人はその場でテーマを大きなポストイットに書き込み、簡単に口頭で説明します。その後、関連するテーマは統合されたりしながら、最終的に議論されるテーマは会場にいる参加者の多数決により選ばれ、3つのトラックに振り分けられます。今回は PostgreSQL のマルチスレッド化、可観測性、新しいテストの枠組み、コミュニティの参加者を増やすには、通信プロトコルの強化など、全部で12のテーマが選ばれました。

PostgreSQL のマルチスレッド化については、２日目に Neon の Heikki Linnakangas による発表Multi-threaded PostgreSQL?でも提案があったのですが、アンカンファレンスでは、Robert Haas, Heikki Linnakangas, Thomas Munro といった強力な開発者たちが中心となって、グローバル変数、拡張モジュールの扱い、プロセスIDからスレッドIDへの書き換え、シグナルハンドラのリファクタリングといった、より具体的な課題解決について議論されていたようでした。誰がどこを担当するかといった話まで登場し、PostgreSQL のマルチスレッド化の計画が現実味を帯びて進みだしているように感じられました。

他に、可観測性に関するセッションは、自律運転（self-driving）、promethus exporter、VACUUM 統計情報といったテーマが合併されたもので、様々な興味から収集したい情報や、その集約の方法、たとえば拡張モジュールがよいのか本体の機能がよいのか、などについて議論されていたようでした。

また、新しいテストフレームワークを議論するセッションでは、現在の Perl を使ったテスト方法の問題点があげられ、Python の pytest を導入する提案などが議論されていました。

おわりに

今回の PGConf.dev も、興味深い発表を沢山聞くことができ大変刺激的でした。セッションでもホールでも議論が大いに盛り上がっていました。今回行われた全ての議論から、PostgreSQL の本体ははもちろん、拡張モジュールやテスト、コミュニティのあり方まで、PostgreSQL に関わるあらゆることをより良くしていこうという活気と熱意を感じることができました。

来年の PGConf.dev もカナダのどこかの都市、予定ではバンクーバー、トロント、オタワ、モントリオールのどこかで開催される予定だそうです。また是非参加できたらと思います。

はじめに

Zabbix Summit はZabbix LLC が主催する世界最大の Zabbix イベントです。今年 2023年も例年通り Zabbix LLC があるラトビア共和国の首都リガにて10月8日と9日の2日間にかけて開催されました。Zabbix Summit は毎年世界各国から大勢の Zabbix ユーザが集まります。今年も SRA OSS はシルバースポンサとしてイベントを支援させていただいており、2019年以来4年ぶりに現地で参加させていただきました。

リガはバルト三国でも最も大きい都市で、別名「バルト海の真珠」とも呼ばれる非常に美しい港町です。リガの旧市街地はアールヌーボ調の建築物が数多く残されており、世界遺産にも登録されています。Zabbix Summit 2023 はそんなリガの新市街にあるRadisson Blu Hotel Latvija で開催されました。

本記事では Zabbix Summit 2023 での講演からいくつかをピックアップしてレポートいたします。

Zabbix の現状とこれから

イベントは Zabbix LLC の CEO であり設立者でもある Alexei Vladishev 氏による、「Zabbix: current state and future」と題した基調講演で始まりました。講演はタイトル通り、Zabbix の現状とリリースを間近に控えた Zabbix 7.0、そしてその後の 8.0 までの展望を説明する内容でした。

Vladishev 氏曰く、Zabbix の現状として「オープンソースであり続けること」、「持続可能性を考慮した長期的な視野」、「オールインワンの監視プラットフォーム」を戦略の基軸として、いまや世界中に 250 以上のパートナを持てるまでに成長することができたこと。近年ではエンタープライズ向けの監視ソリューションとして、品質とセキュリティを最優先事項として開発を続けてきたことを語りました。

そしてこれからの Zabbix 7.0 以降の発展の方向性として、以下の 4 つのキーワードを展開しました。

• Single pane of glass
• Reducing operating costs
• Complex event processing
• Extremely adoptable

「Single pane of glass」が表すのは監視の統合的な可視性と透明性。これに向けて新しいウィジェットやレポート機能、そしてより複雑なシナリオや複数のステップからなる監視を Zabbix で実行できるような機能の実装を考えていることを話していました。

次の「Reducing operating costs」、これは Zabbix の性能だけでなく、ユーザの運用コストの軽減も見据えた機能です。これは例えばプロセスの非同期およびスレッド化、Web UI の高速化、Zabbix プロキシのインメモリデータベース機能やダウンタイムなしでのアップグレードなどです。

「Complex event processing」はイベント相関関係機能のさらなる発展、具体的にはイベントの自動分類や時間・トポロジを元にした相関エンジンの実装。そして最終的には「Extremely adoptable」、すなわち Zabbix がどのようなユースケースにも対応しうる監視ソリューションになることを目指しているということを熱く語りました。

来る Zabbix 7.0 では待望の Zabbix プロキシの HA 機能の実装、そしてその後も8.0 にかけて OpenTelemetry の監視やアプリケーション・パフォーマンス管理 (APM)、AI や機械学習を利用した監視機能なども実装されるとのことで、今後の Zabbix の発展が楽しみになる非常に興味深い講演でした。

Zabbix 7.0 での新機能

「Internal Changes and Improvements in Zabbix 7.0」では Zabbix のチーフトレーナ、Kaspars Mednis 氏から Zabbix 7.0 で実装される新機能の一部、特に内部的な変更点や改善点についての講演が行われました。

まず説明されたのは、データ収集における性能改善についてです。これはいくつかのプロセスの処理・機能が変更されたことによるものであり、それが保存前処理のスレッド化とデータ収集プロセスの非同期化です。特にデータ収集プロセスについては、Zabbix エージェント監視、SNMP 監視、HTTP エージェント監視を担当するプロセスがそれぞれ分離され、かつ非同期にデータ収集を実施できるようになった結果、大幅に効率的かつ省リソースでの監視を実現できるとのことでした。

またそれ以外にも、Zabbix プロキシのインメモリデータベース機能、アイテムレベルでのタイムアウト設定、ディスカバリの並列実行などの Zabbix 7.0 での改善点の解説がありました。

様々な領域で活用される Zabbix

今回の Zabbix Summit でも様々な国の様々な環境・領域での Zabbix 活用の事例紹介が数多くありました。

例えば「Zabbix Behind the Scenes: How Zabbix simplified digital transformation for Brazil’s largest media group」では、ブラジル最大のメディア企業におけるコンテンツ配信ネットワーク (CDN) や生中継機器の監視におけるユースケース。「Case study – Zabbix in financial institutions」では UAE の金融機関における監視アーキテクチャとカスタム Web モジュールについて。「Monitoring the London Underground」ではイギリスはロンドンの地下鉄におけるネットワーク監視。「Zabbix and HPC」ではイスラエルの研究機関における高性能コンピュータの Zabbix での監視など、世界各国の幅広い領域で Zabbix が利用されていることが感じられました。

その中でも、日本のトヨタ自動車、阿部 博氏による「Monitoring Green Power and Distributed Edge Computing Infrastructure with Zabbix」の講演について、詳しく紹介したいと思います。

この講演では、トヨタ自動車が取り組んでいるグリーンエネルギとエッジ基盤の分散監視に Zabbix をいかに活用しているかを詳細に説明されました。近年、自動車業界でも IoT 化がすすめられ、自動車から得られる様々なデータとその重要性の増加およびその活用の観点から、自社でのデータセンタ投資が積極的に行われています。そして今後益々増えていくデータ量とデジタル需要の半面、企業としてはエネルギ消費の効率化やカーボンニュートラルに向けた、グリーンなデータセンタの構築が急務でもあります。

トヨタ自動車でもグリーンなデータセンタの施策を進めていますが、各地に点在するデータセンタ (エッジ基盤) を制御し、使用エネルギの効率化を図るためには全体を統合して監視していく必要があります。そこで採用されたのが Zabbix による分散監視のシステムです。各地のデータセンタに Zabbix プロキシを配置し、監視全体の負荷分散および遠隔地の集中監視を実現しています。また、Kafkaを用いてデータセンタ間のデータ同期を図る際にも、各地の処理負荷の監視結果に基づいて効率的に Producer と Consumer の数の増減を実施することが可能となったともしています。

最後に今後のさらなるグリーンなデータセンタの実現に向けて、世界規模の分散監視の実現や太陽光発電の発電量監視に基づいた電力需要の決定など、Zabbix を活用したさらなるグリーンエネルギの活用への展望を述べて、講演の締めくくりとしました。

TimescaleDB の性能とダウンタイムなしでの移行方法

講演のレポートの最後として、Kim Anthonisen 氏による TimescaleDB に関する講演「Implementing TimescaleDB on large Zabbix without downtime」について紹介します。

この講演では Zabbix DB を PostgreSQL から TimescaleDB へダウンタイムなしに移行する方法について解説していました。移行方法の概要としては以下のようになります。

1. 新規に TimescaleDB で Zabbix DB を作成する
2. PostgreSQL 側の history テーブルに値が追加されたら同じ値を TimescaleDB 側の history テーブルに追加するトリガーを作成する
3. 既存データを PostgreSQL から TimescaleDB にロードする
4. 全てのデータが TimescaleDB にロード完了次第データベースを切り替える

こうすることによって、ダウンタイムなしでの TimescaleDB への移行を実現するという方法です。

また、この講演では TimescaleDB の性能についても言及がありました。一部のテーブルへの housekeeper 処理の必要がなくなることによる Zabbix および DB への負荷軽減に加えて、TimescaleDB の圧縮機能により DB サイズが約 80% 削減できたこと、さらに I/O が約 1/3 ほどに軽減できたことも報告しています。

TimescaleDB については弊社でもその特徴や性能について調査および発表を行っていますが、Zabbix DB として多くの利点があり、特に大規模環境で利用すると負荷軽減などの点で大きなメリットがあると感じました。

Zabbix 本社訪問

Zabbix Summit 終了後の 10/9 に Zabbix 本社に訪問し、CEO の Alexei Vladishev 氏とのミーティングの機会をいただけました。ミーティングでは今後の Zabbix の方向性や、弊社からの質問、要望など様々な議題についてお話をさせていただき、非常に有益な時間となりました。

おわりに

今回も Zabbix Summit 2023 では Zabbix を愛する多くの方々の講演を聞き、さらに世界各国の Zabbix ユーザの方々と交流を持つことができました。このレポートで紹介しきれなかった講演も多々ありますが、Zabbix 社のサイトで講演資料と講演の動画が公開されていますので、ご興味があればぜひ見ていただきたいと思います。

Zabbix Summit は来年も今年と同じラトビア共和国のリガにて開催される予定です。Zabbix に関する情報収集や交流の非常に有意義な場ですので、もし機会がありましたら参加することをお勧めいたします。