OpenSearchCon Japan 2025に参加してきました！

こんにちは！Eight Engineering Unit Platformグループで名刺アプリ「Eight」のSREをしている中鉢です。

2025年12月11日、東京虎ノ門で開催された OpenSearchCon Japan 2025 に参加してきました。OpenSearchConは2022年から世界的に開催されているカンファレンスであり、日本では今回が初開催となります 🎉
今回は参加だけでなく、同じSRE チームの藤原が登壇もしました。

Eightでも、ログ分析基盤の改善に伴いElasticsearchからAmazon OpenSearch Serviceへの移行を進めています。

本記事では、特に印象的だったセッションの内容とそこから得られた学び、そして藤原の登壇内容について共有します。

気になったセッションとEightでの適用可能性

Maximize Resource Efficiency with Separated Index and Search Workloads

opensearchconjapan2025.sched.com

新機能であるReader-Writer Separationを利用したインデクシングと検索の分離によるリソース効率化について解説していただきました。

Segment Replication with Remote Store

従来の OpenSearchでは、インデクシング（書き込み）と検索（読み取り）の両方を同じデータノードが担当していました。これにより、インデクシングの負荷が高まると検索パフォーマンスが劣化するという課題がありました。

この問題を解決するために登場したのが「Segment Replication with Remote Store」です。これは、セグメントをS3などのリモートストアに保存し、レプリカノードがそこから直接読み取る仕組みです。Amazon OpenSearch Serviceでは、OpenSearch最適化インスタンスであるOR系インスタンスとして提供されています。

OpenSearch 3.0の新機能：Reader-Writer Separation

OpenSearch 3.0では、さらに進んだ「Reader-Writer Separation」機能が導入されました。これにより、検索専用の「Search Replica」と、インデクシング専用の「Write Replica」を分離して運用できるようになりました。

これにより次のようなメリットがあります。

柔軟なスケーリング: 検索とインデクシングそれぞれに対して独立してノードを追加・削除できる
コスト最適化: 夜間など検索が発生しない時間帯にSearch Replicaを0にするといった運用が可能
パフォーマンスの安定化: インデクシング起因の障害が検索に影響しない
メモリ削減: 役割を分離することでデータノード側のメモリ要件が下がり、トータルでコスト削減につながる

実際の検証では、全体的な高速化とレイテンシーの安定化が確認されたとのことです。ただし、この機能は現時点でAmazon OpenSearch Serviceでは未サポートとのことなので注意が必要です。

Eightでの適用可能性

Eightのログ分析基盤では、現状書き込みが圧倒的に多いワークロードとなっていますが、検索負荷も高いユースケース、もしくは書き込みの負荷によって検索体験をブロックしたくないようなユースケースにおいては非常に有効だと感じました。

まだAmazon OpenSearch Serviceへの移行後まもない状況ですが、今後の利用拡大を考えるとより的確なパフォーマンスチューニングや柔軟なスケーリングはかなり有用であることが予想され、ぜひ使ってみたい機能の1つです。

現状Amazon OpenSearch Serviceでは未サポートということでEightで利用できるのは先になりそうですが、将来的に利用することを見据え、OR系インスタンスへの移行の足掛かりになりそうです。

ChatOps Using OpenSearch MCP Server

opensearchconjapan2025.sched.com

OpenSearch MCPサーバーによる対話型クラスター管理アプローチが紹介されました。

OpenSearch MCPサーバー

OpenSearch MCP（Model Context Protocol）サーバーは、正確なAPIを知らなくても対話型でクラスター管理ができる仕組みです。自然言語でクエリを投げると、AIがクラスターの推奨事項を提示してくれます。
これにより次のようなメリットがあります。

有事の際などOpenSearchのチューニング経験がないメンバーでも、適切な構成変更を実施できる
読み取り専用ロールを持つユーザーを使うことで、破壊的な変更を防げる
クラスターの健全性チェックやパフォーマンス最適化の提案を自動で受けられる

ただし、セッションの最後には「それでも常にダブルチェックを行うこと。AIを過信しないで」という注意喚起もありました。AIの提案は参考にしつつも、最終的な判断は人間が行うべきという原則は変わらないですね。

Eightでの適用可能性

AIの活用は社内でも急速に進められており、関心の高い内容でした。ChatOps化によりSRE以外のメンバーでもOpenSearchクラスターを管理しやすくなります。

具体的にどこまでの権限を持たせるべきかは要検討ですが、アラート対応や定期的なパフォーマンスチューニングなどのユースケースで利用できそうです。

AWS環境でも利用できそうであれば導入を検討してみようと思います。

Practical Migration From Distributed OpenSearch Environments To Enterprise-wide SIEM Platform

opensearchconjapan2025.sched.com

分散環境から全社的SIEMプラットフォームへ移行した事例紹介です。

250+のAWSアカウント分散管理と課題

弥生株式会社では、チームレベルでAWSアカウントを利用しており、合計250以上のAWSアカウントを運用していました。それぞれのアカウントにOpenSearch環境が分散していたため、全社的なセキュリティ監視やログ分析が困難でした。

OR1インスタンスを活用した統合

この課題に対し、OR1インスタンスを活用してdev環境とprd環境のOpenSearch（SIEM）に統合する戦略を取りました。OR1インスタンスは、レプリカノードを作成しなくてもS3にインデックスを複製できるため、データの冗長性を保ちつつコストを削減できます。

アカウント間のログ送信にはLambdaを使用し、15分間隔で実行する構成としています。

この移行により、全体で25%のコスト削減を達成したそうです。これには、OR1ノードタイプへの変更に加えて、インデックス戦略の最適化なども含まれています。マルチアカウント環境での OpenSearch統合もチャレンジングな取り組みだと思いました。

Eightでの適用可能性

1つめのセッションでも少々触れましたが、 OR系インスタンスはEightでは机上検討のみでとどまっていたので、具体的なコスト削減モデルとして非常に参考になりました。

現状Eightのログ基盤はEightのエンジニアのみが利用しており、かつ別途ログを保管している状況のため、冗長性の面はそこまで重要な要件ではありません。しかしノード構成およびインデクシングやシャードの配置戦略ではコスト面を含めかなり苦い思いをしながらチューニングしていたこともあり、移行のメリットは大きくなりそうです。

苦い思いをしたチューニングについて、詳しくは藤原の登壇資料に記載しているのでぜひご確認ください。

登壇内容と当日の様子

登壇者として参加して

こんにちは。Eight Engineering Unit Platformグループの藤原です。今回のOpenSearchCon Japan 2025では、参加者としてだけでなく、登壇者としての貴重な経験もさせていただきました。ここでは、登壇内容から当日の様子、そして得られた学びについて共有したいと思います。

登壇内容

私は、「Lessons From Migrating To OpenSearch: Shard Design, Log Ingestion, and UI Decisions」というテーマで登壇しました。
opensearchconjapan2025.sched.com

Eightのログ分析基盤をElasticsearch + KibanaからAmazon OpenSearch Service + OpenSearch UIに移行したなかで得られた学びと教訓として、特にインデックス設計とシャード設計、インデクシング負荷を抑えるためのパフォーマンスチューニング、そしてUIの選定背景やメリットデメリットについて触れています。Webにはさまざまなベストプラクティスがあげられていますが、ログ分析ワークロードで体系的にまとまったプラクティスが見つけにくいといったことも事実です。そこで、私たちが直面した課題について、トラブルシューティングをベースとした実話を交えてどのように安定稼働させていったかをご紹介しています。当日はOpenSearchConの参加者とも議論をさせていただいて、誰しもが通る道でもあると改めて感じたので、皆さんもご覧いただき他にもこういった良いアイデアがあるよ、などがあればお話ししましょう！

詳細を知りたい方はSpeaker Deckにも資料を公開しているので、ぜひご覧ください！

speakerdeck.com

当日の様子

当日は会場全体で日本人の方が3~4割程度、海外の方が6~7割程度だったと感じています。私のセッションは日本語だったので9割ほどが日本の方でした。予想以上に多くの方が参加してくださり、正直初歩的な内容も多く恐縮でしたが、こういった実運用を通したプラクティスの適用は生々しくも興味を持っていただける内容なのかなと思いました。セッション後も質疑応答で、導入効果やOpenSearch Serverlessの検討はしたか、Fluentdの運用負荷はどうかなどさまざまな質疑をぶつけていただきました。セッションにご参加いただいた皆さん、ありがとうございました！

また、カンファレンス全体を通じて感じたのはOpenSearchコミュニティの活発さと熱意です。会場の休憩室では、他社のエンジニアとの情報交換も活発に行われており、様々なユースケースや運用ノウハウが共有されていました。私自身も登壇の中で触れていないOpenSearch ServerlessやS3からのデータ復旧、Data Prepperを活用したETL処理など、検討をしてみたいユースケースにも出会えました。加えて、元々興味のあったSegment Replication with Remote Storeについて、実際に導入された企業の方と検索の一貫性の体験にどれくらい影響しているかなど、実体験をもとにしたフィードバックも聞けたことはすごく学びになりました。最後には日本らしいLEGOが当たる抽選会もあり、技術カンファレンスながら和やかな雰囲気で締めくくられました。
後日OpenSearchProjectの公式YouTube OpenSearch - YouTube にも登壇動画が掲載されるようです。

まとめ

OpenSearchCon Japan 2025は、最新の技術動向を学び、コミュニティの熱気を肌で感じられる素晴らしいカンファレンスでした。OpenSearchは急速に進化しており、検索基盤としてだけでなく、ログ分析、セキュリティ監視、AIとの統合など、様々な用途で活用の幅が広がっています。Eightでも、今回得られた知見を生かして、より信頼性の高いログ分析基盤の構築を進めていきます。次回が第1回開催となるOpenSearch Tokyo meetupにも、ぜひ参加したいと思います。

Eightは、今もなお成長フェーズにあるプロダクトです。一緒に挑戦を進めてくれる仲間を募集中です。少しでも興味を持っていただけたら、ぜひカジュアルにお話ししましょう！