OpenSearchCon Europe 2025のセッション「Unifying Diverse Logs in Big Data Systems for Seamless Analysis and Action with OpenSearch and LLMs」を日本語でまとめます。 可能な限り正確に内容を拾えるようにリスニングに努めたつもりですが、もし誤りがあればご指摘ください。
OpenSearchCon とは？
イベントページ
各セッションはYouTubeで視聴可能
Managing Over 1,000 OpenSearch Clusters in a Private Cloud
セッションリンクは以下
www.youtube.com
スピーカー
- Sun Ro Lee
- LINE クラウドサービスエンジニア
- OpenSearchサービスの開発・運用を約5年担当
LINEは主にアジア地域、特に日本で広く利用されているメッセージングプラットフォームで、メッセージング以外にも音楽、コミック、ショッピングなど様々なサービスを提供している企業である。
セッションまとめ
プライベートクラウドを選択する理由
LINEでは、プライベートクラウドでOpenSearchを運用している。
LINEがプライベートクラウドを運用する理由は3つある。
第一に、セキュリティとデータ保護である。メッセージングプラットフォームとして様々なユーザーデータを扱うため、より高いレベルのデータセキュリティが必要で、時には独自のデータ保護ツールを開発する必要もある。
第二に、コスト効率性である。大規模サービスをパブリッククラウドで運用すると非常に高コストになるため、プライベートクラウドによってコスト削減を図っている。
第三に、機能の柔軟性である。特定のLINEサービスがクラウド上で特別な機能を必要とする場合、クラウドチームが迅速に対応できる利点がある。
LINEが扱うOpenSearchの規模
LINEのプライベートクラウド環境では、現在1,200以上のOpenSearchクラスターが稼働している。これらのクラスターには6ペタバイト以上のデータが格納されており、日本国内の2つのリージョンで運用されている。用途としては、ログストレージ、データ分析、監視、検索エンジンなど多岐にわたっている。
サービスアーキテクチャの特徴
LINEのOpenSearchサービスアーキテクチャの特徴的な点は、コントローラーやAPIサーバー、監視パイプラインはKubernetes上に構築している一方で、OpenSearchノード自体はKubernetesではなくOpenStackベースの仮想マシンとストレージサービスを使用していることである。
OpenSearchは公式にKubernetesオペレーターをサポートしており、Kubernetesにはサービス運用の利点や便利な機能があることは理解している。しかし、コントロールプレーンの障害がすべてのOpenSearchクラスターに影響を与える潜在的なリスクがある。実際に昨年12月のChatGPTサービス障害では、Kubernetes APIサーバーの過負荷により4時間以上のサービス停止が発生した。LINEでも同様のKubernetesに起因するサービス中断を数回経験したため、コントロールプレーンの問題がOpenSearch機能に影響しないよう、制御部分とOpenSearchノードを分離したアーキテクチャを採用している。
ネットワークストレージの採用背景
多くの人が知っているように、OpenSearchのインストールガイドではパフォーマンス上の理由からネットワークストレージの使用を推奨していない。当初LINEも、このガイドラインに従って大容量SSDを搭載した専用サーバーでOpenSearchを運用していた。
しかし、専用サーバーの運用は非常に煩雑で、大規模クラスター構築時にはノードアフィニティの問題が発生することがあった。また、データティアリングも専用サーバーでは負担となっていた。サービスが成長するにつれて、一部のユーザーは検索エンジンにより高いパフォーマンスを求める一方で、他のユーザーはログ保存のためにより大きなOpenSearchノードを望むようになった。そこで、より柔軟なリソース配分と効率的なストレージ運用のために、ローカルストレージからネットワークストレージへの移行を決定した。
高性能ノードとNVMe over Fabric
高性能ノード向けには、NVMe over Fabricストレージを採用した。NVMe over Fabricは、NVMeディスクをネットワーク経由で接続するプロトコルで、データ保護と信頼性のためにRAID構成でNVMe over Fabricディスクを設定することができる。このタイプのストレージは、NVMeディスクの高速性により高性能を提供するが、OpenSearchの独自データレプリケーションポリシーとRAID構成による冗長なデータレプリケーションが発生するという問題があった。
データを保存する際、OpenSearchはレプリカ設定数に応じて1つ以上にレプリケートし、その後NVMeディスクがRAID構成によって再度コピーを作成するため、冗長性が生じてディスクコストが増大するという欠点があった。
軽量ストレージ「NVMe Light」の導入
この冗長性問題を解決するため、「NVMe Light」と呼ぶ軽量ストレージを導入した。これは、レプリケーション戦略を使用せず、単一のNVMeディスクを使用する構成である。この構造の利点は明確で、ストレージコストとネットワークコストがRAID 1構成の半分に削減される。
欠点として、ディスク障害時にデータが失われる可能性があるが、OpenSearchのマルチゾーンシャードアフィニティとシャードレプリケーション設定によってデータフォルトトレランスを確保している。ネットワークストレージではなくOpenSearchのみに依存することで、検索パフォーマンス向けにより多くのリソースを使用できるようになった。より多くのレプリカを使用し、3つのシャードに対して3つのディスクのみを使用することで、コスト削減と検索パフォーマンス向上を両立している。
大規模移行事例とコスト削減効果
大規模移行の事例として、6.1ペタバイトのデータをOpenSearchサービスに移行したケースがある。ここでは、2.0ペタバイトのデータをホットタイプノード（NVMe接続仮想マシン）に保存した。この軽量ストレージ適用後、この移行ケースの製品コストは22％削減された。契約上の問題で正確な節約額を明示することは困難だが、6ペタバイトのデータを保存するために通常必要なサーバー数を考えると、22％は相当大きな削減効果である。
ケーススタディ1
チェックサム失敗問題
ネットワークストレージを使用することで、コスト効率性とコールドティアノードのデータ安全性が向上したが、いくつかの問題も発生した。主要な問題の一つがチェックサム失敗エラーである。
チェックサム失敗エラーは、保存されたシャードからデータを読み取る際に発生し、突然チェックサム失敗エラーが起こってシャードが未割り当て状態になる。これは、OpenSearchが特定のシャードのチェックサムテストに失敗し、このデータが無効であると判断したことを意味する。
この問題はコールドティアノード（ブロックストレージボリュームを使用）でのみ発生し、前述のNVMeディスクを使用するホットティアノードでは発生しなかった。発生時、OpenSearchはレプリカシャードを使用して自動復旧できるため、当初はこの問題が重要でないように見えた。しかし、調査を進めると2つの深刻な懸念が明らかになった。
第一に、この問題は読み取り操作中に発見され、書き込み時ではないため、問題が始まった時期を特定することが困難である。データ書き込み時にはエラーが発生せず、数日または数ヶ月後にデータを読み取ろうとしたり、OpenSearchがシャードを他のノードに移動しようとした際にエラーが発生する。
第二に、より根本的な問題として、プライマリシャードとレプリカシャードが異なるデータを含んでいることである。シャードペアの一方が破損した場合、OpenSearchは他方のシャードを使用して自動復旧できるが、これはプライマリシャードとレプリカシャードが異なるデータを持ち、長期間にわたって保存されていることを意味する。一方でチェックサムテストに失敗し、他方が合格するということは、非常に深刻な問題として認識した。
原因調査とテスト
原因を特定するため、OpenSearchバージョン、Luceneバージョン、オペレーティングシステム、カーネルバージョン、さらにはメモリオプションまで、考えられるほぼすべての要因について広範囲なテストを実施した。この表のほぼすべての組み合わせをテストしたが、各テスト実行で数百ギガバイトのデータを使用するため、非常に時間がかかった。6ヶ月以上を費やしてすべてのテストを完了したが、NVMeディスクとローカルタイプディスクでは問題が発生せず、ブロックストレージでのみ発生することが確認された。
ファイルシステムキャッシュの問題やブロックストレージの問題、Luceneのバグなどいくつかの要因を疑ったが、正確な根本原因は特定できなかった。
ディスクキャッシュモードの発見
幸い、このテストからしばらく経って、この問題がサービスしている2つのOpenStackリージョンのうち1つでのみ発生していることに気づいた。そこで、ディスクオプションに焦点を当てて2つのリージョンを比較し、最終的に異なるオプションを発見した。それがディスクキャッシュモードである。
このハイパーバイザーレベルのオプションは、OpenStackのNovaモジュール（仮想マシン管理モジュール）によって使用され、問題が発生したリージョンでは「writeback」に設定されており、他のリージョンでは「none」（ディスクキャッシュを使用しない）に設定されていた。writebackオプションはディスクパフォーマンスを向上させるが、データ損失の潜在的リスクがあるとOpenStackドキュメントに記載されている。
グラフに示されているように、リージョンA（writeback設定）では定期的にチェックサム失敗エラーが発生していたが、リージョンB（none設定）では、リージョンAの3倍のデータを持っているにもかかわらず、チェックサムエラーが全く発生していなかった。
問題解決とパフォーマンステスト
リージョンAの一部のOpenSearchノードでキャッシュモードをnoneに変更したところ、チェックサム失敗エラーが消失した。そこで3つのクラスターにこの設定を適用した。OpenStackドキュメントではこのオプションがブロックストレージドライバーでは安全であると記載されているが、OpenSearchでデータ不整合を引き起こす可能性があることがわかった。正確な理由は不明だが、キャッシュが何らかの影響を与えている可能性がある。
writebackはキャッシュを使用してディスクパフォーマンスを向上させるため、ディスクパフォーマンスはOpenSearchにとって非常に重要であることから、これら2つのオプション間のパフォーマンステストも実施した。結果として、writebackモードはシングルスレッド環境では優れたパフォーマンスを示したが、OpenSearchはマルチスレッドで読み書きを行うため、この2つのオプション間にはほぼ差がなかった。そのため、writebackオプションからnoneに移行することを決定した。
この問題は数ヶ月から年単位で悩まされ、このプレゼンテーションが採択されるまで正確な原因を特定できていなかった。幸運にもつい最近この原因を特定し、修正できたため、今日この経験を共有できることを非常に嬉しく思っている。ネットワークストレージをOpenSearchクラスターで使用しようとする場合、キャッシュオプションがこのような問題に影響する可能性があることに注意されたい。
ケーススタディ2
Cephベースブロックストレージの問題
2番目の問題もブロックストレージ、特にCephベースブロックストレージに関連している。今回の問題は単一ノードに限定されず、複数のOpenSearchクラスターが同時にダウンし、ディスクヘルスチェック失敗エラーでノードがクラスターから除外される事象であった。
この問題もCephストレージでのみ発生し、NVMeストレージでは発生しなかった。この問題が重要である理由は、複数のクラスターに同時に影響を与えるためである。単一のOpenSearchクラスターだけの問題ではなく、複数ノード障害により、プライマリシャードとレプリケーションシャードの両方が同時に失われる可能性があり、復旧するまでそのデータを検索できなくなる。また、ノードが除外された結果、OpenSearchがデータ復旧を試みるが、この状況下ではCephストレージに追加の負荷をかけ、問題を悪化させる。
Cephストレージの特性と問題の分析
Cephは、データをブロックとしてCephクラスター全体に分散して配布する。通常の条件下では、すべてのサーバー間で負荷が均等に分散されるため有益である。しかし、OpenSearchのような継続的な読み書き負荷を持つシステムには問題となる。OpenSearchの負荷が増加すると、接続されているCephストレージの負荷も増加し、Cephクラスターの応答時間が遅くなる。ある時点でOpenSearchのノードヘルスチェックが失敗し、ノードが除外される。その後、OpenSearchは失われたシャードの復旧を試み、これが別の負荷と別のシャード移動を意味し、問題を悪化させる。そして、繰り返されるノード障害のサイクルを作り出す。
この問題を修正するため、数百のクラスターのほぼすべてにこれらの設定を手動で適用した。インデックス復旧速度や同時に移動するシャード数など、ノード間のネットワーク負荷を削減する設定である。
OpenSearchのヘルスチェックポリシーの問題
主な原因として、Cephクラスターの負荷が通常より若干高かっただけで、大幅に高くはなかった状況でも、OpenSearchがヘルスチェック失敗と判断していたことがわかった。これは、OpenSearchのセンシティブなディスクヘルスチェックポリシーによるものだった。
OpenSearchでは、ヘルスチェックに5秒以上かかると警告ステータスと判断し、1分以上かかると失敗と判断してノードが除外される。また、3回連続で警告が発生した場合も、OpenSearchはこのディスクのヘルスチェックが失敗したと判断する。
Cephは本質的にデータアクセスの遅延を伴うため、OpenSearchのセンシティブなヘルスチェック設定がCeph環境では過度に反応的だった。この問題は、OpenSearchとCephの相互作用に起因しており、現在多くの検索ノードが同時にダウンする問題の修正を試みているが、まだ完全には解決していない。
しかし、この経験から重要な教訓が得られた。OpenSearchのディスクヘルスチェックポリシーは、ネットワークストレージ環境には適さない可能性がある。これが、OpenSearchインストールガイドでネットワークストレージの使用を推奨していない理由だと思われる。
OpenSearchをネットワークストレージで使用することを計画している場合は、ヘルスチェック閾値の調整を検討するか、安定性のためにパフォーマンスやスペースだけでなく、より多くのCephストレージリソースが必要になる可能性がある。
ネットワークストレージの利点
これら2つの代表的な問題を共有したが、これはネットワークストレージが問題のある選択であることを意味するものではない。実際、ネットワークストレージでの運用中に明確な利点を経験している。
第一に、ディスク障害とサーバー復旧時間の削減である。ネットワークストレージには独自のディスク復旧戦略があるため、単一ディスク障害について心配する必要がなくなった。ネットワークストレージが自己復旧するためである。コンピューティングノード（仮想マシン）が障害を起こした場合も、全データを復旧する代わりに新しい仮想マシンを作成することで迅速に復旧できる。
これは特にコールドティアノードで有用で、単一ノードで最大10テラバイトを保持できる。コールドティアノードをローカルストレージで構成した場合、かなり大量のデータのため復旧に1時間以上かかる可能性がある。
第二に、前述のように、専用OpenSearchサーバーの管理負担が解消された。プライベートクラウドで仮想マシン用に10万以上のハイパーバイザーを持っているため、専用サーバー障害について心配する必要がなくなった。これにより、大規模クラスター構築時にシャードアフィニティが崩れることを心配する必要もなくなるという利点も得られる。
今後の展望
今後も継続的にOpenSearchサービスの拡張を計画している。多くのユーザーが独自のクラスターをOpenSearchサービスに移行したいと考えているため、今年中にサービスが10ペタバイトを超える成長を予想している。そのため、クラスター用の自動化されたノードメンテナンスポリシーと自動化ツールが必要になると考えている。
また、一部のユーザーはペタバイトスケールのデータを単一クラスターに保存したいと考えているため、ペタバイトスケールのOpenSearchに対応する必要がある。大規模クラスターにはパフォーマンスと安定性の問題があることは承知しているが、そうしたユーザーに対応するための準備が必要である。
今日共有したケースが、現在OpenSearchサービスを使用している人や、特にネットワークストレージでOpenSearchサービスの実装を計画している人にとって、有用な洞察やヒントを提供できることを期待している。
QA
Q： writeback cacheの問題について、それを実質的にright through（キャッシュを完全に無効化）に設定したにもかかわらず、パフォーマンスが変わらなかったという点は非常に興味深い。通常、キャッシュはディスクとストレージに大きな違いをもたらすはずなので、ブロックストレージとキャッシュの有用性に関するベンチマークが非常に有用だと思う。また、Cephについては、複数のクラスター間でCephストレージを共有しているようだが、クラスターごとに別々のCeph実装を持つことで、一つのクラスターの問題が他のクラスターに波及しないようにできるのではないか。5秒のヘルスチェックメトリクスは妥当だと思うが、Cephが5秒以内に応答しないのは奇妙に思える。
A： アドバイスをありがとう。我々も根本原因を見つけようと努力しており、ヘルスチェック閾値を増やすことは真の解決策ではないと考えている。何らかの解決策を見つけて、再度発表の機会があればと思っている。
Q： 扱っているスケールが非常に興味深いが、設定の一貫性を保ち、新しいクラスターをセットアップするためにどのような自動化を使用しているか。現在どのレベルの自動化を行っており、将来的にどのような自動化の実装を検討しているか。
A： 前述したKubernetesコントローラーに基づいている。OpenSearchクラスターをデプロイ・管理するために独自のKubernetesオペレーターを作成したが、OpenSearchノードはOpenStack上にデプロイするため、公式のKubernetes OpenSearchオペレーターには依存していない。基本的にそのコントローラー・オペレーターに依存している。自動化機能の大部分はオペレーターパターンで実装されている。設定の更新や同期などの他の自動化機能は、ジョブやバッチジョブなどの他のKubernetesモジュールに依存している。継続的に改善を試みているが、すべてKubernetes上で実行している。
