LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

2021年のSSPL移行、OpenSearchが生まれた経緯

Elasticsearchの移行とは、Apache 2.0ライセンスを維持するOpenSearchなど代替基盤への切り替えを検討し、実行する取り組みを指します。背景にあるのは、Elastic社が2021年に採用したライセンス変更です^*1。切り替えると判断した場合は、互換性検証を経てOpenSearchへの移行作業を進めます。

Elastic社は2021年1月14日、公式ブログでライセンス変更を発表しました^*1。対象はElasticsearchとKibanaのソースコードです。バージョン7.11以降、ライセンスをApache 2.0から「SSPL」と「Elastic License」のデュアル形式へ切り替えるという内容でした^*1。

同社は変更の理由について、「クラウドサービス事業者がオープンソース製品をサービスとして提供しながら、コミュニティに還元していない」ためだと説明しています^*1。

SSPLの仕組みについて、同社は「自由な利用・改変を認める」と説明しています^*1。ただし「製品をサービスとして第三者に提供する場合は、管理レイヤーのソースコードも含めてSSPLのもとで公開する必要がある」とも述べています^*1。

あわせて「コミュニティの大部分は実際には変化を経験しない」とも述べ、既存のElastic Cloud利用者やオンプレミス利用者への影響は限定的だとしています^*1。この変更を受け、AWSは対応方針の検討に入りました。

Apache 2.0のOpenSearch、Linux Foundation傘下への移行

AWSは2021年9月8日、公式ブログでOpenSearchの提供開始を発表しました^*2。発表資料では、OpenSearchを「コミュニティ主導のオープンソースプロジェクト」と位置づけています^*2。

これはApache 2.0がライセンス付与された最終版のElasticsearch・Kibanaからのフォークです^*2。同時にサービス名も「Amazon Elasticsearch Service」から「Amazon OpenSearch Service」へ変更されました^*2。

AWSは同発表で、Elastic LicenseやSSPLについて「オープンソースではなく、利用者に同等の自由を与えるものではない」との見解を示しています^*2。既存のElasticsearchバージョンへのサポートは継続する方針です^*2。

新機能はOpenSearchとOpenSearch Dashboardsを通じて提供するとも説明しています^*2。既存アプリケーションを変更せずに利用できる後方互換性の維持も、この時点で約束されています^*2。

OpenSearch公式サイト（opensearch.org）は、プロジェクトを「コミュニティ主導のオープンソース検索・分析スイート」と説明しています^*5。ライセンスはApache 2.0です^*5。

2024年9月16日には、Linux Foundation傘下の「OpenSearch Software Foundation」が発足しました^*6。AWSは同発表で、特定企業に依存しない中立的な運営体制へ移行したと説明しています^*6。理由として「7億件を超えるダウンロード実績と25組織・200名超のメンテナーの参加」を挙げています^*6。

2024年のAGPL追加、Elasticsearchのオープンソース復帰

Elastic社は2024年8月29日、公式ブログで新たな発表を行いました^*3。既存のElastic License・SSPLに加えて、AGPLv3を選択肢に追加するという内容です^*3。

AGPLv3はOSI（Open Source Initiative。オープンソースの定義を審査・認定する非営利団体）が承認するオープンソースライセンスです。同社創業者は「AGPLv3を追加することで、ElasticsearchとKibanaを再びオープンソースと呼べるようにする」と説明しています^*3。

この変更は既存ライセンスを置き換えるものではありません^*3。Elastic License・SSPL・AGPLv3の3種類から利用者が選べる形へ広がった点がポイントです^*3。

同社は2021年の変更について「AWSなどによる競合サービスとの市場の混乱に対応するためだった」と振り返っています^*3。状況が落ち着いたことが、AGPLv3追加の判断材料になったとも説明しています^*3。

公式FAQによると、SSPLの義務が生じるのは「Elasticsearchを第三者向けのサービスとして提供する場合」に限られます^*4。自社システムの内部で利用したり、自社サービスの基盤として組み込んだりする一般的な利用形態では、SSPLの著作権開示義務は及びません^*4。

この線引きを理解しないまま「ライセンスが変わった＝移行が必須」と判断するのは早計です。まず自社の利用形態がSSPLの対象に該当するかどうかの確認が、検討の出発点になります。

Elasticsearch継続かOpenSearch移行か、判断の4つの視点

ElasticsearchからOpenSearchへ移行するかどうかは、自社のライセンスポリシー・利用形態・API依存度によって判断が分かれます。以下の4つの視点で整理すると、検討の優先順位が見えやすくなります。

ライセンス条件が自社ポリシーに適合するか

OSSポリシー上「OSI承認ライセンスに限定する」という要件を持つ組織にとって、Elastic LicenseとSSPLは選択が難しいライセンスです^*4。AGPLv3のみがOSI承認の対象になります^*3。一方OpenSearchは、当初からApache 2.0ライセンスを維持しているため、ライセンス要件の面では確認事項が少なくなります^*5。

自社の利用形態がSSPLの対象に該当するか

前述の通り、SSPLの義務は「サービスとして第三者に提供する場合」に生じます^*4。自社システムの一部として組み込む利用や、社内向けの検索基盤としての利用であれば、Elasticsearch継続でもライセンス上の制約は限定的です。一方、Elasticsearchをベースにしたマネージドサービスを外部提供する場合は、OpenSearchへの切り替えも検討対象になります。

API・クライアントの互換性をどう見るか

OpenSearchはElasticsearch 7.10.2からのフォークであるため、REST APIやクエリ構文には共通する部分が残っています^*2。ただしAWSは、「OpenSearchとElasticsearchは今後も差異が広がる可能性がある」と説明しています^*7。クライアントとサーバーの組み合わせを混在させると、エラーのリスクが高まるとも述べています^*7。

実際にElastic社は、自社の公式クライアントライブラリに接続制限の仕組みを追加しました^*7。対象はOpenSearchクラスタやオープンソース版Elasticsearch 7への接続です^*7。この経緯を受け、AWSは独自のクライアントライブラリを整備しています^*7。

コミュニティ・ガバナンス体制の継続性をどう見るか

OpenSearchはLinux Foundation傘下の「OpenSearch Software Foundation」が運営する体制です^*6。AWS・SAP・Uberなど複数企業が名を連ねており、特定企業への依存を避けたい場合の判断材料になります^*6。一方Elasticsearchは、Elastic社が主導する開発体制を維持しています^*3。どちらの体制を選ぶかは、自社のベンダーロックイン回避方針と照らし合わせて判断するとよいでしょう。

移行前に確認すべきAPI・クライアントの非互換ポイント

OpenSearchへの移行を計画する際は、ライセンス面の判断だけでなく、技術的な非互換ポイントの洗い出しが欠かせません。確認を怠ると、移行後に接続障害や機能不足といったトラブルにつながる恐れがあります。

クライアントライブラリのバージョン・接続制限を誤ると障害につながる

Elastic社の公式クライアントライブラリは、特定バージョン以降でOpenSearchクラスタへの接続を制限する仕組みを持っています^*7。この制限を把握しないまま既存のクライアントを使い続けると、ライブラリのアップデート時に接続エラーが発生し、検索機能が停止するリスクがあります。移行前には、利用中のクライアントライブラリのバージョンと対応方針の確認が欠かせません。

フォーク後に追加された機能はElasticsearchとOpenSearchで一致しない

OpenSearchはElasticsearch 7.10.2をベースに独自の機能追加を続けています^*2。Elasticsearch側も8.x系で新機能を追加しているため、フォーク以降に追加された機能は両者で一致しません。自社が利用しているクエリDSL（検索条件を表現する記述形式）・集計機能・プラグインがどちらの系統の仕様に依存しているかを、移行前に棚卸しする作業が必要です。

移行体制に必要なスキルと工数

OpenSearch移行を内製で完結させる場合、ライセンス条件の確認・API差分の洗い出し・クライアント互換性検証・負荷試験を担う人員が必要です。特にElasticsearchクラスタの構成が複雑な環境では、インデックス設計やシャーディング（データ分散配置）方式の差分確認にも専門知識が求められます。社内に該当スキルを持つ人材が不在の場合、検証工程だけでも想定より長い期間を要することがあります。

移行外注の選定基準と進め方

Elasticsearch/OpenSearchの移行を外注する場合は、全文検索基盤固有の運用実績を持つパートナーの優先が大切です。

Elasticsearch/OpenSearch双方の実績を持つパートナーを選ぶ

移行の外注先を選ぶ際は、Elasticsearchの運用実績に加えて、OpenSearchへの移行支援実績を持つパートナーを優先します。提案段階で「ライセンス影響の整理」「API・クエリ互換性の診断」「移行後の負荷試験」まで踏み込んで提案してくる会社かどうかを確認するとよいでしょう。

マネージドサービス移行への対応可否

主要クラウドのマネージドサービスへの移行実績があるかどうかも確認ポイントです。具体的な例として、Amazon OpenSearch Serviceが挙げられます^*2。オンプレミス環境からの移行を検討している場合は、移行先の運用形態（自己運用かマネージドサービスか）まで含めた提案力を評価します。

外注プロジェクトの進め方

移行プロジェクトは、一般的に「ライセンス影響確認→互換性検証→移行実施→運用定着」の4フェーズで進みます。ライセンス影響確認では、自社の利用形態がSSPLの対象に該当するかを照合し、移行の要否を判断するという流れです^*4。互換性検証フェーズでは、ステージング環境でクライアントライブラリ・クエリ構文・プラグインの動作を確認します。

移行実施フェーズでは、本番切り替えのタイミングと切り戻し手順をあらかじめ定めておくことが重要です。運用定着フェーズでは移行後の監視体制を整え、OpenSearch側の新しいバージョンリリース情報を継続的に確認する体制を構築します。

まとめ：Elasticsearch/OpenSearch移行検討で押さえる3つの判断軸

本稿では、Elasticsearchのライセンス変更の経緯とOpenSearchの位置づけ、移行判断のポイント、外注先選定の基準を整理しました。要点を3つに集約すると次の通りです。第一に、Elasticsearchは2021年にApache 2.0からElastic License/SSPLへ移行しました^*1。2024年にはAGPLv3を追加する形でライセンス体系を広げています^*3。SSPLの義務は第三者向けサービス提供時に限られるため、自社の利用形態の確認が出発点になります^*4。第二に、OpenSearchはLinux Foundation傘下でApache 2.0ライセンスを維持しています^*6。ただしフォーク後のAPI変更やクライアント接続制限には、個別の確認が必要です^*7。第三に、移行を進める場合はライセンス確認・API互換性検証・マネージドサービス対応まで一貫して支援できる外注先の選定が、移行後の障害リスクを抑える鍵になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Elastic「Doubling Down on Open, Part II」（elastic.co、2021年1月14日公開）
2. *2　出典：AWS「Announcing Amazon OpenSearch Service which Supports OpenSearch 1.0」（AWS Newsブログ、2021年9月8日公開）
3. *3　出典：Elastic「Elasticsearch Is Open Source. Again!」（elastic.co、2024年8月29日公開）
4. *4　出典：Elastic「FAQ on Software Licensing」（elastic.co公式FAQ）
5. *5　出典：OpenSearch公式サイト「opensearch.org」
6. *6　出典：AWS「AWS Welcomes the OpenSearch Software Foundation」（AWS Open Source Blog、2024年9月16日公開）
7. *7　出典：AWS「Keeping clients of OpenSearch and Elasticsearch compatible with open source」（AWS Open Source Blog、2021年8月4日公開）

Tweet