

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ステージ 5 – カットオーバー
<a name="stage-5-cutover"></a>

このステージでは、現在の Elasticsearch 環境または OpenSearch 環境からターゲット Amazon OpenSearch Service ドメインにカットオーバーするために採用できるさまざまなアプローチについて説明します。カットオーバーは次の 2 つのステップで実行できます。
+ データ同期メカニズムを確立して、ターゲット環境をソースと同期させます。
+ ダウンタイムの有無にかかわらず、現在の環境からターゲット環境へのスワップを実行します。

## データ同期
<a name="data-sync"></a>

連続データを受信するシステムの場合、データ移行中に新しいデータの受信を停止し、メンテナンスウィンドウで移行を実行する必要がある場合があります (ダウンタイムが発生する可能性あり)。ダウンタイムを許容できない場合は、移行を開始した後に変更をキャプチャできます。ターゲット上で変更を再生して、カットオーバーを実行するまで、ソースと同期された最新の状態を維持します。以下のセクションでは、ソースとターゲットの同期を維持するさまざまな方法について説明します。

**ログ分析ワークロード**

ログ分析ワークロードでは、次の方法で更新と同期を実行できます。
+ 保持期間が終了するまで 2 つの環境を並べて実行し、現在の環境とターゲット環境の両方への取り込みを実行できます。ある時点で、アプリケーションをカットオーバーして新しい環境にポイントすることを決定します。場合によっては、ログまたはドキュメントソースから既存のクラスターとターゲット OpenSearch Service 環境の両方に新しいデータを取り込むことができます。その後、現在の環境からコピーすることで、ターゲット環境で古いデータをバックフィルできます。いずれの場合も、ユーザーに影響を及ぼすようなデータギャップがないことを確認する必要があります。
+ データ移行の前に、既存の環境への取り込みを一時停止できます。ただし、このアプローチは、データ移行が完了するまで、ユーザーが既存の環境から最新のデータまたは変更されたデータを検索できない可能性があることを意味します。データ移行が完了したら、データインジェストをターゲット環境にポイントし、アプリケーションとクライアントをターゲット環境にスイッチオーバーできます。つまり、移行が完了するまで新しいデータは利用できません。ただし、システムは引き続き検索できます。新しい環境が利用可能になるまで、ソースログとデータをソースに保持する手段が必要です。
+ データの最初のパスが移行されるまで、現在のログ分析エンジンを引き続き使用できます。次に、最初のパスが開始された後に生成された残りのデータをバックフィルします。残りのデータが最初のパスよりもはるかに小さいと仮定すると、同期が数分で終わる場合も数時間かかる場合もあるため、残りのデータを同期している間は取り込みを一時停止できます。また、同期ウィンドウが小さくなり、ソースからターゲット環境への取り込みを一時停止し、ユーザーに影響を与えることなくターゲット環境にカットオーバーできるようになるまで、このアプローチを使用してパスを数回実行することもできます。次の図は、増分スナップショットと復元を使用してデータを更新または同期する方法を示しています。

    
![ソースから Elasticsearch へのデータフローを示す 2 段階の移行図 OpenSearch Service。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/opensearch-service-migration/images/OpenSearch_1.png)

  *ステップ 1*

  1. データは、ソースからデータインジェストパイプラインを経由して、現在の Elasticsearch 環境と Amazon OpenSearch Service ドメインへと流れます。

  1. 最初のパスで Elasticsearch から Amazon OpenSearch Service ドメインに移動するまでが最も長くかかります。

  1. 最初の更新または同期パスの所要時間はそれよりも短くなります。

  1. 2 回目の更新または同期パスには、最小限の時間がかかります。

  1. データは Elasticsearch からアプリケーションに引き続き流れます。

  *ステップ 2*

  1. データは、ソースからデータインジェストパイプラインを経由して OpenSearch Service ドメインに流れます。

  1. 現在の Elasticsearch 環境への取り込みが停止します。

  1. 最後の更新または同期パスには、最小限の時間がかかります。

  1. データは OpenSearch Service からアプリケーションに流れます。

**検索ワークロード**

前述の 3 つのアプローチでは、カットオーバーを実行する前に、ターゲット上のすべてのデータが最新であることを確認する必要があります。検索ワークロードでは、更新または同期に関する以下の推奨事項を検討してください。
+ 検索ワークロードの場合、通常、ソースから現在の環境への取り込みを一時停止します。現在の環境からターゲット環境にすべてのデータをコピーし、移行の開始以降に変更されたデータを決定できる変更データキャプチャ (CDC) メカニズムを導入します。次に、変更されたデータを Amazon OpenSearch 環境にコピーします。ほとんどの場合、検索アプリケーションのデータインジェストパイプラインには既に CDC メカニズムが組み込まれているため、通常は、データが現在の環境から移行された後にパイプラインを新しい環境にポイントするだけです。次の図は、検索ユースケースのためにソースからインデックスを完全に構築する方法を示しています。

    
![OpenSearch Service とデータソースに接続する Elasticsearch を示す 2 段階の移行図。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/opensearch-service-migration/images/OpenSearch_2.png)

  *ステップ 1*

  1. 現在の Elasticsearch 環境への取り込みが一時停止されます。

  1. データは ElasticSearch から OpenSearch Service ドメインにコピーされます。

  1. データは ElasticSearch からアプリケーションに引き続き流れます。

  *ステップ 2*

  1. Elasticsearch 環境とデータソースまたはアプリケーションへの接続が失われます。

  1. 変更データキャプチャ (CDC) データはパイプラインに取り込まれ、OpenSearch Service ドメインに流れます。

  1. データは OpenSearch Service ドメインからアプリケーションに流れます。
+ 一部の検索ワークロードでは、ソースデータベースまたはデータソースから新しい OpenSearch Service 環境にフルデータのみをロードする必要があります。ロードが完了すると、クライアントアプリケーションは新しい環境にカットオーバーできます。これは、検索ワークロードの移行を実現する最も簡単な方法です。

## スワップまたはカットオーバー
<a name="swap-cutover"></a>

移行ジャーニーの最後のステップは、新しい環境へのスワップまたはカットオーバーです。これは非常に重要なフェーズの 1 つです。この時点で、本番稼働の準備は整っています。データが同期され、最新の状態になり、モニタリングとアラートが設定され、ランブックが最新の状態になり、新しい環境にカットオーバーする準備が整っています。取り込みが正常に流れていること、および新しい環境のメトリクスが正常であることを確認する必要があります。このステージでは、既存の Elasticsearch クラスターまたは OpenSearch クラスターから新しい Amazon OpenSearch Service ドメインへのクライアント接続のカットオーバーを計画し、実行します。クライアントライブラリの変更が必要になる場合がありますので、注意してください。この時点で、互換性とパフォーマンスを検証するために、Amazon OpenSearch Service のすべてのクライアント機能を下位環境でテストしているはずです。

新しい環境をポイントする必要があるクライアントアプリケーションがある場合は、DNS エントリを古い環境から新しい環境に更新します。次に、アプリケーションの動作を注意深くモニタリングして、ユーザーが適切なエクスペリエンスを得ていることを確認します。

通常、このドキュメントのガイドラインに従った場合は、安全なスイッチオーバーが行われます。ただし、新しい環境で問題が発生した場合に備えて、ソース環境を最新の状態に保つことをお勧めします。古い環境を廃止する前に、スワップ後も数週間、両方の環境を運用し続ける AWS のお客様もいます。ビジネス継続性の要件に合った戦略を選択することをお勧めします。