Amazon Web Services ブログ

Octus が Amazon OpenSearch Service へのゼロダウンタイム移行でインフラストラクチャコストを 85% 削減した方法

本記事は 2025年11月26日 に公開された「How Octus achieved 85% infrastructure cost reduction with zero downtime migration to Amazon OpenSearch Service | AWS Big Data Blog」を翻訳したものです。

データ量が指数関数的に増加し続ける中、ミッションクリティカルなワークロードが求める高いパフォーマンスと信頼性を維持しながら、検索インフラストラクチャのコストを最適化するプレッシャーが高まっています。多くの企業は、運用オーバーヘッドが大きく、効率的なスケーリングを制限する複雑で高コストな検索システムを管理しています。検索システム間の移行が必要な場合、この課題はさらに深刻になります。従来、移行には大幅なダウンタイム、複雑なデータ同期、ビジネス運用への大きな影響が伴います。エンタープライズアプリケーションは、カスタマーエクスペリエンス、ビジネスインテリジェンス、運用継続性に影響を与えるサービス中断を許容できません。移行戦略は、移行プロセス全体を通じてゼロダウンタイムを維持し、完全なデータ整合性を確保しながら、コスト最適化と運用改善を実現する必要があります。

2013年に設立された Octus（旧 Reorg）は、世界をリードするバイサイド企業、投資銀行、法律事務所、アドバイザリー企業向けの重要なクレジットインテリジェンスおよびデータプロバイダーです。比類のない人間の専門知識を実績のあるテクノロジー、データ、AI ツールで補完することで、Octus は金融業界全体で決定的なアクションを促す強力なインサイトを提供しています。

この記事では、Octus が Elastic Cloud で実行していた Elasticsearch ワークロードを Amazon OpenSearch Service に移行した方法を紹介します。複数のシステムを管理する状態から、OpenSearch Service を活用したコスト効率の高いソリューションへの移行の道のりをたどります。また、移行を成功させたアーキテクチャの選択と実装戦略を共有します。その結果、移行中もサービスの可用性を中断することなく、パフォーマンスの向上とコスト効率の改善を実現しました。

戦略的要件

Amazon OpenSearch Service への移行を選択した理由となるいくつかの要件を特定しました：

  • コスト効率：OpenSearch Service の料金モデルにより、パフォーマンスを損なうことなくクラウド支出を最適化できました。
  • 迅速なサポート：AWS は問題解決を加速し、信頼性を高める、信頼できる高品質なサポートを提供しました。
  • 一貫した信頼性：OpenSearch Service は最大 99.99% の SLA を提供し、Octus のミッションクリティカルなワークロードに必要な信頼性を確保しています。
  • クエリダウンタイムなしのシームレスな移行：Migration Assistant for Amazon OpenSearch Service により、移行中もクエリの可用性を中断することなく移行パスを提供し、ビジネス継続性を確保しました。
  • 運用の簡素化：AWS への統合により、高いセキュリティ基準を維持しながらインフラストラクチャの複雑さを軽減しました。

ソリューション概要

Migration Assistant for Amazon OpenSearch Service は、Elasticsearch から OpenSearch Service への移行を支援するツールスイートを提供します。Octus は移行に以下の機能を使用しました：

  • メタデータ移行：このツールにより、Octus は多様なマッピングと設定を持つ数十のインデックスを移行できました。タイムスタンプメタデータとの後方互換性の問題が特定された際、Migration Assistant ツールに直接統合されたカスタム JavaScript 変換を適用し、インデックス全体のマッピングを自動的に調整して互換性を確保しました。
  • 履歴データ移行：Octus は Reindex-from-Snapshot を使用して、ソースクラスターのポイントインタイムスナップショットから履歴ドキュメントを移行しました。スナップショットは Amazon Simple Storage Service（Amazon S3）に保存されているため、ソースクラスターに影響を与えることなくこのプロセスをスケーリングできました。Reindex-from-Snapshot により、移行中にシャーディングスキームを調整し、ターゲットでのクラスターパフォーマンスを最適化することもできました。
  • ライブトラフィックリプレイ：バックフィルが完了すると、Octus は Migration Assistant の Traffic Replayer を使用して、キャプチャされたライブトラフィック（Traffic Capture Proxy から）を OpenSearch Service 互換性のために必要なリクエスト変換とともにターゲットクラスターに送信しました。その結果、ターゲットクラスターにはソースクラスターのドキュメントが含まれ、更新がリアルタイムで実行されました。

以下の図は、この移行の実装アーキテクチャ図を示しています。


図 1 – 移行ステップを含む Migration Assistant アーキテクチャ

Migration Assistant for Amazon OpenSearch Service の詳細については、AWS ソリューションのホームページをご覧ください。

図の各ノードは、移行プロセスの以下のステップに対応しています：

  1. クライアントトラフィックは既存のクラスターに送信されます。
  2. キャプチャプロキシを備えた Application Load Balancer がトラフィックをソースに中継しながら、データを Amazon Managed Streaming for Apache Kafka（Amazon MSK）にレプリケートします。
  3. 移行コンソールを使用して、ポイントインタイムスナップショットを取得します。スナップショットが完了すると、Metadata Migration Tool を使用してターゲットクラスターにインデックス、テンプレート、コンポーネントテンプレート、エイリアスを確立します。継続的なトラフィックキャプチャが行われている状態で、Reindex-from-Snapshot がソースからデータを移行します。
  4. Reindex-from-Snapshot が完了すると、キャプチャされたトラフィックが Amazon MSK から Traffic Replayer によってターゲットクラスターにリプレイされます。
  5. ソースクラスターとターゲットクラスターに送信されたトラフィックのパフォーマンスと動作を、ログとメトリクスを確認して比較します。
  6. ターゲットクラスターの機能が期待どおりであることを確認した後、クライアントを新しいターゲットにリダイレクトします。

完全な移行と最適化の道のり

Octus の Elastic Cloud から Amazon OpenSearch Service への移行は、コア移行作業とその後の最適化フェーズの両方を包含しています。目標は、検索インフラストラクチャ、アプリケーション、データを Elastic Cloud から新しい OpenSearch Service ドメインに最小限の中断で正常に移行し、実際の使用データに基づいてパフォーマンスとコストを継続的に最適化することでした。

Octus は社内のカスタムインフラストラクチャフレームワーク（インフラストラクチャ自動化のための内部ツール）を使用して、ターゲットの OpenSearch Service 1.3 ドメインを構築、デプロイ、監視し、移行の堅固な基盤を確立しました。このアプローチにより、フルマネージドの AWS サービスに移行しながら、使い慣れた内部プロセスを活用できました。OpenSearch Service を使用する際のセキュリティベストプラクティスの実装については、AWS ドキュメントを参照してください。

移行前の最適化

移行を開始する前に、Octus は移行プロセスを効率化するためにソース Elasticsearch クラスターで最適化作業を実施しました。これには、時間の経過とともに蓄積された未使用のインデックスの削除や、移行期間を不必要に延長しストレージ転送コストを増加させる大きなドキュメントの削除が含まれます。これらの準備ステップにより、移行が必要なデータ量が大幅に削減され、全体的な移行の複雑さが最小化され、Migration Assistant ツールをより効率的に使用できるようになりました。

技術的制約とバージョンの考慮事項

移行には、技術的アプローチに影響を与える特定のバージョン互換性の課題がありました。ソース Elasticsearch クラスターはバージョン 7.17 で実行されており、Python クライアントアプリケーションも Elasticsearch 7.17 互換性に制約されていました。移行をサポートするために、チームは Reindex-from-Snapshot を使用しました。これにより、既存のスナップショットから新しい OpenSearch Service クラスターにデータを再インデックスすることで、クロスシステム移行が可能になります。RFS は古いバージョンの Lucene で作成されたインデックスも書き換えるため、最新バージョンの OpenSearch Service への将来のアップグレードが簡素化されます。OpenSearch 1 または 2 への移行を評価しながら、Octus はクライアント側の変更を最小限に抑え、移行の複雑さを軽減するためにターゲットとして OpenSearch 1.3 を選択し、後でより簡単にアップグレードできるようにしました。

バージョンの選択は特に R アプリケーション環境に影響を与えました。R 言語（統計計算とデータ分析のためのオープンソースプログラミング言語）にはネイティブの OpenSearch 1.3 クライアントサポートがなかったためです。この制約により、Octus は ropensci/elastic ライブラリを使用して新しい OpenSearch Service ドメインと統合するカスタムクライアントソリューションを開発する必要がありました。Python 環境も同様の課題を呈し、Elasticsearch 7.17 クライアントの制約により、移行アプローチを慎重に検討する必要がありました。これらのクライアント互換性の懸念は、従来のスナップショットベースの方法よりも Migration Assistant ツールを選択した要因の 1 つでした。Migration Assistant は、移行中のバージョン固有のクライアントインタラクションの管理をより適切にサポートしていたためです。

今後、Octus はアプリケーションスタックの進化とクライアントライブラリサポートの成熟に伴い、新しい OpenSearch バージョンへのアップグレードを計画しており、この移行で達成した安定性を維持しながら、最新の機能とパフォーマンス改善を活用できるようにします。

複数言語にわたるアプリケーションのモダナイゼーション

アプリケーションの変更は、複数のプログラミング環境にわたる重要な技術的取り組みでした：

  • レガシー PHP システム（5.6 および Laravel 4.2）：Octus は OpenSearch リクエストでのマッピングタイプの非推奨を処理しました。これらのマッピングタイプの指定はサポートされていないためです。elasticsearch コネクタライブラリをユーザー名/パスワード認証で引き続き使用しました。
  • モダン PHP アプリケーション（8.1 および Laravel 9）：これらはより包括的な変更を受け、elasticsearch/elasticsearch ライブラリを opensearch-project/opensearch-php クライアントに置き換え、IAM 認証を活用してクラスターに接続しました。
  • Python 環境：Django フレームワーク 2.1、3.2、5.2 を使用するバージョン 3.8、3.10、3.11、3.13 にまたがるアプリケーションは、elasticsearch ライブラリを opensearch-py に置き換え、IAM 認証に移行する必要がありました。
  • R アプリケーション：R 4.5.1 アプリケーションでは、Octus は互換性を確保するためにカスタムライブラリ ropensci/elastic を利用しました。

トラフィックルーティングと強化されたモニタリング

移行を促進するために、Octus は既存のクライアントをリダイレクトして、Migration Assistant の Traffic Capture Proxy を介してソースクラスターにリクエストをルーティングし、ライブトラフィックからターゲットクラスターにデータを移行しました。

このプロセス中に、モニタリングインフラストラクチャは大幅に強化されました。Octus のオブザーバビリティインフラストラクチャは、クラスターマネージャーとデータノード、ネットワーク、データストレージ、セキュリティと IAM アクセスを含む OpenSearch Service クラスターの全体的な健全性を監視します。また、アプリケーションのインデックス作成と検索パフォーマンスも監視します。これにより、ログとメトリクスが Datadog に直接送信されるため、別個のモニタリングクラスターの必要性がなくなり、オブザーバビリティが大幅に向上しました。Datadog モニターは Infrastructure-as-Code を使用して定義され、インフラストラクチャフレームワークにシームレスに統合されました。

カットオーバーと初期結果

Site Reliability Engineering チームはリリースを綿密に計画し、システムアプリケーションのダウンタイムなし、データ損失ゼロで Elasticsearch から OpenSearch Service への移行と Elasticsearch クライアントから OpenSearch Service クライアントへのカットオーバーを成功させました。初期移行フェーズでは、ゼロダウンタイム、データ損失なし、インフラストラクチャとモニタリングの完全な Infrastructure-as-Code 実装、強化されたオブザーバビリティなどの運用上のメリットを達成しながら、52% のコスト削減を実現しました。

移行後の最適化

移行後、Octus は新しい OpenSearch Service セットアップの本番環境およびその他の環境からの運用データに基づいて包括的な最適化を実施しました。この実際の使用データは、実際のリソース消費に関する貴重なインサイトを提供し、さらなるクラスターのリサイズに関する情報に基づいた意思決定を可能にしました。

使用メトリクスの分析と戦略的なリサイズにより、Octus はクラスターサイズを運用ニーズにより正確に合わせ、支出を最小限に抑えながら継続的なパフォーマンスを促進しました。この最適化フェーズでは、元の Elastic Cloud コストと比較して追加で 33% のコスト削減を達成し、一貫した最適なパフォーマンスを維持しながら、合計削減率を 85% にしました。

運用モニタリング

Octus は Datadog を使用して検索とインデックス作成のレイテンシーの両方を監視し、Amazon OpenSearch Service クラスターのパフォーマンスをリアルタイムで可視化しています。以下のスクリーンショットは、カスタム Datadog ダッシュボードが OpenSearch Service クラスターのライブビューを提供する方法を示しています。この可視化は、取り込みプロセスの概要と詳細なインサイトの両方を提供し、ストレージとドキュメント数を理解するのに役立ちます。ダッシュボードの下半分は、個々のノードの健全性とパフォーマンスメトリクス（読み取りと書き込みのレイテンシー、スループット、IOPS など）の時系列ビューを表示します。


図 2 – Datadog ダッシュボード

移行のオブザーバビリティ

Migration Assistant for Amazon OpenSearch Service は、移行の進捗を観察および検証するためのいくつかのダッシュボードを提供します。これらのオブザーバビリティ機能を使用することで、お客様はバックフィルとライブキャプチャおよびリプレイの進捗の両方を追跡でき、本番ワークロードをターゲットクラスターに切り替える前に信頼性を確保できます。以下のグラフは Octus の移行の例で、約 4TB のデータが約 9 時間（08:00 から 17:00）で移行されました。


図 3 – ディスク使用量によるバックフィル進捗


図 4 – 検索可能なドキュメントによるバックフィル進捗

バックフィルが完了すると、キャプチャされたトラフィックがリプレイされ、ソースクラスターとターゲットクラスター間の継続的なアクティビティが同期されます。

バックフィルが完了した時点（約 17:00）で、ターゲットクラスターはソースより約 467 分遅れていました。リプレイプロセスは、キャプチャされたトラフィックをソースで最初に取り込まれた速度よりも速い速度で処理することで、この遅延を急速に削減しました。


図 5 – バックフィル完了後のリプレイ遅延

遅延時間が 0 に達すると、ターゲットクラスターは完全に同期され、本番トラフィックを安全に再ルーティングできました。Octus は最終的な切り替えを行う前に、数日間ターゲットでリプレイされたトラフィックを観察することを選択しました。

卓越性の達成

Octus の Amazon OpenSearch Service への移行は、顕著な成果をもたらしました：

  • スケーラビリティ – Octus は 3 つの環境で Q&A に利用可能なドキュメント数をほぼ 2 倍に増やし、数週間ではなく数日で実現しました。オートスケーリングルールとコントロールを備えた AWS Fargate を使用した Amazon Elastic Container Service（Amazon ECS）の使用により、ピーク使用時間中のサービスの弾力的なスケーラビリティを実現しています。
  • コスト削減 – Elastic Cloud から OpenSearch Service に移行することで、Octus の月間インフラストラクチャコストは 85% 削減されました。
  • 検索パフォーマンスの向上 – Octus は移行中も一貫したレスポンスタイムを維持し、レイテンシーへの悪影響はなく、クエリスループットと全体的な検索パフォーマンスが 20% 向上しました。
  • ゼロダウンタイム – Octus は移行中のダウンタイムがゼロで、アプリケーション全体で 100% のアップタイムを達成しました。
  • 運用オーバーヘッドの削減 – 移行後、Octus の DevOps および SRE チームはメンテナンス負担とオーバーヘッドが 30% 削減されました。1 つのシステムを使用するようになったため、SOC2 コンプライアンスのサポートも簡単になりました。
  • タイムラインの短縮 – 移行全体が予定より早く完了し、計画から完全な完了まで 1 四半期未満で実現しました。

「Elastic Cloud から Amazon OpenSearch Service への移行は、サードパーティへの依存を最小限に抑え、Octus のシステムインフラストラクチャの信頼性を強化するという、より広範な戦略の重要な要素でした。Migration Assistant for Amazon OpenSearch Service により、データ損失ゼロ、ユーザーへのダウンタイムほぼゼロでシームレスな移行を実行できました。」– Vishal Saxena 氏、CTO、Octus

まとめ

この記事では、Octus が Migration Assistant for OpenSearch Service を使用して Elasticsearch ワークロードを Elastic Cloud から Amazon OpenSearch Service に正常に移行し、ゼロダウンタイムと大幅な運用改善を達成した方法を紹介しました。

Migration Assistant for OpenSearch Service は、包括的なツールスイートを通じてこの複雑な移行をサポートしました。Metadata Migration 機能は、多様なマッピングと設定を持つ数十のインデックスを移行し、カスタム JavaScript 変換で後方互換性の問題を処理しました。Reindex-from-Snapshot は、ソースクラスターに影響を与えることなくポイントインタイムスナップショットから履歴ドキュメントを移行し、パフォーマンス向上のためにシャーディングスキームも最適化しました。Live Traffic Replay により、移行プロセス全体を通じてターゲットクラスターがリアルタイム更新と同期された状態を維持しました。

移行は複数の側面で大きな成果をもたらしました。Octus は月間インフラストラクチャコストを 85% 削減しながら、3 つの環境で検索可能なドキュメント数をほぼ 2 倍に増やしました。検索パフォーマンスはクエリスループットが 20% 向上し、一貫したレスポンスタイムでレイテンシーへの悪影響はありませんでした。移行はアプリケーション全体でゼロダウンタイムと 100% のアップタイムを維持し、DevOps および SRE チームはメンテナンス負担と運用オーバーヘッドが 30% 削減されました。移行全体は 1 四半期未満で予定より早く完了しました。

Migration Assistant for OpenSearch Service の詳細と同様の成果を達成する方法については、AWS ソリューションのホームページをご覧ください。

Octus にアクセスして、厳密に検証されたインテリジェンスを迅速に提供し、クレジットライフサイクル全体の専門家に完全な全体像を提供する方法をご覧ください。LinkedIn と X で Octus をフォローしてください。

著者について

Harmandeep SethiHarmandeep Sethi は Octus の SRE エンジニアリングおよびインフラストラクチャフレームワーク責任者で、大規模システムの実装において高パフォーマンスチームをリードしてきた約 10 年の経験があります。オブザーバビリティ、レジリエンスエンジニアリング、インフラストラクチャフレームワークによる運用プロセスの自動化のベストプラクティスを推進することで、Octus の検索エンジンインフラストラクチャとサービスの変革とモダナイゼーションに重要な役割を果たしてきました。

Serhii ShevchenkoSerhii Shevchenko は Octus の Site Reliability Engineer です。ソフトウェア開発と Site Reliability Engineering で合計 9 年の経験があり、システムの信頼性とパフォーマンスの向上に専門性を持っています。Elasticsearch Cloud から AWS OpenSearch への会社の重要な移行において、アプリケーション側の主要な開発者でした。彼の計画は、クライアント向けダウンタイムゼロで移行を実行する上で重要な役割を果たしました。

Govind BajajGovind Bajaj は Octus の Senior Site Reliability Engineer で、高パフォーマンスのエンジニアリングチームと重要なシステムをサポートするスケーラブルなインフラストラクチャの設計と実装を専門としています。8 年以上の経験を持ち、複雑な問題を分解して実用的で適切に設計されたソリューションに変えることに優れており、安全で観測可能でレジリエントなプラットフォームの構築に強い焦点を当てています。

Virendra ShindeVirendra Shinde は Octus の Platform 責任者で、クラウドインフラストラクチャ、Site Reliability、Octus 製品スイートを支えるコアフレームワークを統括しています。Octus に入社する前は、Grayscale Investments で 2 年間、投資家ポータルとデータ API をゼロから構築しました。それ以前は、Blackstone で 8 年間、複数の開発チームをリードしました。メリーランド大学で情報管理の修士号を取得しています。

Brian PresleyBrian Presley は OpenSearch の Software Development Manager で、OpenSearch Migrations と OpenSearch Serverless の背後にあるチームをリードし、スケーラブルで影響力の高い検索および分析ソリューションを構築しています。

Andre KuraitAndre Kurait は AWS の Software Development Engineer II で、テキサス州オースティンを拠点としています。現在、Migration Assistant for Amazon OpenSearch Service に取り組んでいます。Amazon OpenSearch に参加する前は、Amazon Health Services で働いていました。余暇には、旅行、料理、教会のスポーツリーグでのプレーを楽しんでいます。カンザス大学でコンピューターサイエンスと数学の理学士号を取得しています。

Vaibhav SabharwalVaibhav Sabharwal は AWS の Senior Solutions Architect で、ニューヨークを拠点としています。新しいクラウドテクノロジーの学習と、お客様のクラウド導入戦略の構築、革新的なソリューションの設計、運用の卓越性の推進を支援することに情熱を持っています。AWS の Financial Services および Storage Technical Field Communities のメンバーとして、業界内の協力的な取り組みに積極的に貢献しています。

この記事は Kiro が翻訳を担当し、ソリューションアーキテクト の 榎本 貴之 がレビューしました。