OpenSearchCon North America 2025「キーノート：SAPにおけるOpenSearchによるオブザーバビリティ」 - Hariharan Gandhi, SAP

OpenSearchCon North America 2025のキーノートのうち「SAP & OpenSearch Observability A trustful path to innovation」のパートをまとめます。

youtu.be

スピーカー

• Hariharan Gandhi
  • Tech Lead, SAP Cloud logging Service

SAP Business Technology PlatformとOpenSearch

SAP Business Technology Platform（BTP）は、SAPのPaaSであり、包括的なランタイム、サービス、ツールのセットを提供しています。これは世界中の数千の顧客がインテリジェントなビジネスアプリケーションを構築、拡張、統合するためのSAPのイノベーションプラットフォームです。

BTPの基盤には、Cloud FoundryやKubernetesなど複数のランタイムが提供されています。SAPビジネスサービスチームと顧客の両方が、これらのランタイム上にワークロードを構築しています。SAP BTP内のサービスの規模と多様性を考えると、その上で実行されるワークロードの信頼性とパフォーマンスを確保するために、可観測性が不可欠になります。
SAP BTP可観測性チームは、SAPクラウドロギングをホスト型可観測性サービスとして提供し、BTPプラットフォーム上の可観測性のニーズに応えています。多様で強力なランタイムサービスとツールのスイートを完全に活用するには、単一の標準に適応することが不可欠です。そのため、プラットフォーム内でOpenTelemetryの採用が増加しています。
OpenSearchは、その可観測性機能とOpenTelemetryのサポートにより、SAPクラウドロギングサービスの基盤として完璧に適合しています。SAPクラウドロギングは、OpenSearchをベースにアプリケーションログ、メトリクス、トレースを保存・分析するサービスとして機能しています。

OpenSearchは様々な機能を提供していますが、SAPの主な焦点は可観測性です。OpenSearchはBTPの可観測性を実現する上で中心的な役割を果たしています。
DevOpsチームは開発段階からクラウドロギングサービスを活用しています。4つのゴールデンシグナルでアプリケーションを監視し、パフォーマンス低下の検出やインシデント発生後のトラブルシューティング、根本原因分析を行っています。ログ監視、パフォーマンス監視、サービストポロジーの可視化、アラートなど、OpenSearchの可観測性機能をフル活用しています。
特に重要なのがOpenTelemetryサポートです。これによりデータ収集方法が標準化され、ログ、メトリック、トレースを簡単に相関させることができます。従来の独自プロトコルから段階的に移行し、可観測性データの収集と可視化を統一的な方法で行えるようになりました。SAPはOpenTelemetryを早期から採用しており、データ収集にData Prepperを利用しています。

SAP Cloud Logging Service

OpenSearchを基盤としたSAP Cloud Logging Serviceは、ログ、メトリック、トレースに基づく包括的な可観測性ソリューションを提供しています。2年間の社内テストを経て、2023年12月にサービスを一般公開しました。
このサービスの特徴は、可観測性の専門知識がないユーザーにも対応できることです。BTP上でビジネスアプリケーションを構築する開発者は、可観測性サービスの運用やダッシュボード構築の詳細を意識する必要がありません。BTPランタイム（Cloud FoundryやKyma）でアプリケーションを構築すると、SAPクラウドロギングを簡単にプロビジョニングできます。
サービスは各ランタイムとスムーズに統合され、自動的にデータを取り込みます。4つのゴールデンシグナルやサービス品質ダッシュボードなど、事前構築されたダッシュボードがすぐに利用できるため、開発者は複雑な設定なしに監視を開始できます。一方で、OpenSearchに精通したパワーユーザーは、高度な機能を直接活用してカスタマイズすることも可能です。
主要機能として、SAP BTPランタイムへの専用サポート、OpenTelemetryと他のプロトコルへの対応、アラートと異常検知、データ保持管理、アクセス管理のカスタマイズなどを提供しています。

OpenSearchへの移行を決定した要因

OpenSearchへの移行は一夜にして決まったわけではありません。明確なニーズに基づいた決定でした。
まず、プラットフォーム全体の可観測性を提供するホスト型サービスが必要でした。サービスとアプリケーションの両方のユーザーに洞察を提供できる必要がありました。さらに、簡単に拡張でき、信頼性の高いオープンソースソリューションであることが重要でした。
エンタープライズレベルの品質も欠かせません。様々な環境に対応できる設定の柔軟性、適切な認証と認可の仕組みが必要でした。そして何より重要だったのは、強力で信頼できるコミュニティの存在と、将来のイノベーションに向けた明確なロードマップです。
これらの要件がSAPの意思決定を形作り、OpenSearchへの移行を推進することになりました。

約10年前、SAPはElasticsearchのオープンソース版をBTPロギングサービスのエンジンとして採用しました。当時のユースケースは限定的で、BTPのランタイムの1つに対して読み取り専用のロギングサービスを提供するだけでした。ユーザーは事前に用意された可視化機能しか利用できませんでしたが、当時のニーズには適していました。
しかし、Elasticsearchのオープンソース版には課題がありました。基盤となるLuceneは真のオープンソースでしたが、Elasticsearchそのものは単一ベンダーによって主導されており、コミュニティとの相互作用は限定的でした。SAPにとってはプロジェクトへの関与が制限され、ライセンスリスクも存在していました。
さらに、オープンソース版には認証・認可機能やアラート機能など、基本的な可観測性機能が欠けていました。これらの高度な機能は商用版でのみ提供されており、オープンソース領域でのイノベーションとSAPの完全な参画を妨げる要因となっていました。

OpenSearch 1.xへの移行とコミュニティへの参加

その後の進行は3つのフェーズに分けられます。
第1フェーズでは、Elasticsearchの制限を克服するため、独自のカスタム拡張機能を構築しました。セキュリティモジュールなどを自社開発し、オープンソース化しました。これらはうまく機能しましたが、メンテナンスが大きな課題となりました。バージョンアップのたびに互換性を確保する必要があり、特にセキュリティモジュールはエラーが許されない重要な機能だったため、顧客に提供できる機能が大幅に制限されました。
この頃、可観測性スタック全体の再構築を検討していました。Kubernetesを使用した大規模構築を目指し、BTPのどのランタイムにも依存しない設計を求めていました。そんな中、AWSがOpen Distro for Elasticsearchをオープンソース化しました。SAPはこれを歓迎し、すぐにベータ版での評価を開始しました。
しかし間もなく、Elasticsearchのライセンスが非オープンソースライセンスに変更されるという破壊的な変更が発生しました。多くの企業と同様、SAPにとってもElasticsearchは使用できなくなり、これがSAPにとって大きな転換点となりました。

ライセンス変更の直後、AmazonがElasticsearchをフォークしてOpenSearchプロジェクトを立ち上げました。このプロジェクトはApache 2.0ライセンスの下で、真のオープンソースプロジェクトとして開始されました。SAPはこのイニシアチブと投資を高く評価し、すぐにプロジェクトに惹かれました。
OpenSearchが魅力的だった理由はいくつかあります。最初からコミュニティファーストのプロジェクトとして位置づけられており、SAPは当初から様々なイベントや意思決定プロセスに招待され、参加することができました。Open Distroのフォーラムでロゴデザインのフィードバックを収集していた頃のことを今でも覚えています。このようなオープンな姿勢は、SAPが求めていたものでした。
さらに、プロジェクトは最初から品質に厳格な焦点を当てており、エンタープライズ企業にとって重要な要素でした。時間の経過とともに、OpenSearchは公開ロードマップで印象的なイノベーションの計画を発表し、これらすべてがSAPの期待に応えるものでした。

OpenSearchへの移行評価を開始しました。2つの異なる環境がありました。Elasticsearchオープンソース7.xバージョンを実行しているクラスターと、Open Distro for Elasticsearchを実行しているクラスターです。優れたドキュメントのおかげで、両方ともOpenSearch 1.xへスムーズに移行できました。
初期評価後、SAPクラウドロギングサービスのベータ版で移行プロジェクトを開始しました。当時約10,000のOpenSearchインスタンスを運用していましたが、すぐにメリットが現れ始めました。Open Distro時代に必要だったカスタム実装を排除でき、リスクが大幅に軽減されました。
コミュニティへの関与も徐々に増加しました。Data PrepperのOpenTelemetry対応やイベントへの参加など、積極的に貢献を始めました。SAPだけでなく、ユーザーやステークホルダーにとっても、このオープンソースコミュニティの価値が継続的に高まっていることを実感しました。

OpenSearch 2.xへのアップグレードとKubernetesオペレーターへの投資

現在、Kubernetes上で約11,000のOpenSearchクラスターを稼働させています。これらの管理にはKubernetesオペレーターを使用しています。
大規模なクラスター群をOpenSearch 2.xへアップグレードするには、Kubernetesオペレーターの大幅な改善が必要でした。そこで一旦アップグレードを停止し、オペレーターがゼロダウンタイム（ZDM）でクラスターを更新できるよう、計画的なアップデートを可能にする機能の開発に投資しました。
この投資が実を結び、Kubernetesオペレーターに必要な改善を実装できました。現在、SAPクラウドロギングサービスはOpenSearch 2.xへのアップグレードを完了しており、今後のOpenSearch 3.xへの移行準備も整っています。

OpenSearch FoundationとLinux Foundationへの参加

OpenSearchプロジェクトチームのオープンガバナンスへのコミットメントは、OpenSearch Software FoundationをLinux Foundation傘下に設立することで、次の段階へと進化しました。写真はウィーンで開催されたオープンソースサミットでのGabriela Columbo氏の講演の様子です。
この移行により、2つの重要な側面が実現しました。第一に、SAPのようなすべての参加者にとって公平な競争の場が確立されたこと。第二に、オープンソースが真にオープンであり続けることが保証されたことです。これらの特性により、SAPとコミュニティ全体のOpenSearchプロジェクトへの信頼が大きく増幅されました。
真のオープンソースコミュニティでは、イノベーションを共同で形作り、高い品質を保ちながら推進できます。SAP内部でも、ステークホルダーの間でも、この認識の変化が明確に見られるようになりました。

SAPはOpenSearch Software Foundationのプレミアムメンバーとなり、財団内で積極的な役割を担っています。
Governing Boardには、SAP BTPテクニカルサービス責任者が参加しています。Technical Steering Committeeには、SAPクラウドロギングサービスアーキテクトが参加しています。　
彼らが役割を担ってから1年が経過しましたが、これまでの経験は非常に充実したものでした。委員会には世界中の様々な組織からメンバーが参加していますが、一つの大きなチームとして協力し、建設的に計画を立てています。この関与により、SAPはコミュニティから恩恵を受けると同時に貢献し、プロジェクトの長期的な持続可能性にも責任を持っています。

SAPはプロジェクトに参加するすべての人々と共にイノベーションを推進したいと考えています。世界中の多くの組織がOpenSearchに貢献している中、SAPも積極的に参加しています。
SAPの動機は複数あります。コミュニティへの貢献とプロジェクトの持続可能性の支援は、SAP自身の利益にもつながります。イノベーションの共同推進、他の参加組織とのより深い連携も重要な要素です。
企業としての動機に加えて、個人レベルでの変化も見られます。OpenSearchが財団になったことで、チーム内の開発者たちは権威ある財団の一部であるソフトウェアに貢献することに大きなモチベーションを感じるようになりました。これは個々のコントリビュータにとって明確な変化であり、大きなインスピレーションとなっています。

SAPのコントリビューションと今後の取り組み

SAPは現在、3つの主要な領域でコントリビューションを行っています。　　 エンタープライズ対応として、OpenSearchコアのFIPS準拠をサポートする取り組みを進めています。これにより、厳格な規制環境でもOpenSearchを利用できるようになります。　　 可観測性分野では、Data PrepperでのOpenTelemetryイベントのサポートに注力しています。OpenTelemetryシグナルのインデックスエイリアスロールオーバーやHTTPサポートへのコントリビューションも計画しています。
SAPはKubernetes上で最大規模のOpenSearchデプロイメントの1つを運用しており、その経験から得られたフィードバックやバグ報告を積極的に共有しています。大規模運用から学んだ知見を還元することは、コミュニティ全体にとって価値があると考えています。
さらに、OpenSearchの可観測性に関する技術諮問グループ（TAG）が新たに設立され、SAPのメンバーが参加しています。このTAGは、OpenSearchエコシステム全体の可観測性戦略とガイダンスの提供に焦点を当てています。

BTPのランタイムであるCloud FoundryとKymaは、どちらもオープンソースプロジェクトです。特にKymaはSAPが先駆けて開発したKubernetesベースのランタイムです。GardenerはSAPのオープンソースKubernetes as a Serviceの提供であり、Linux Foundation Europe傘下のプロジェクトとして運営されています。このGardenerによって、SAPクラウドロギングサービスは50以上の異なるKubernetesクラスターに展開されています。
OpenTelemetryはデータの生成と消費方法を標準化し、従来のランタイムの可観測性ニーズと新しいOpenTelemetry標準の両方をサポートします。OpenSearchはこれらすべてのデータを統合する役割を果たしています。
SAPの目標は、単一のオープンソースコミュニティだけでなく、これらすべてのオープンソースコミュニティ全体でイノベーションを起こすことです。複数のOSSイニシアチブを調整することで、価値が何倍にもなり、より大きなインパクトを生み出すことができます。真のオープンソースコミュニティは、高品質なイノベーションを共同で形作ることを可能にします。

まとめ

Elasticsearchのオープンソース版から始まり、現在のOpenSearch 2.xに至るまで、SAPは10年にわたる進化の道のりを歩んできました。
この道のりは、Elasticsearchオープンソース版の採用から始まり、Open Distroへの移行、そしてOpenSearchプロジェクトの誕生とともに新たな段階へと進化しました。 OpenSearchへの移行とコミュニティへの積極的な参加を経て、現在はOpenSearch Foundationのメンバーとして、プロジェクトの発展に深く関わっています。
SAPはこの道のりに貢献したすべてのチーム、そして活気あるコミュニティに深く感謝しています。このコミュニティの積極的なメンバーであることを誇りに思い、今後10年間のイノベーションを楽しみにしています。