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

# データフロー
<a name="data-flow"></a>

データフローの重点領域には、次の 3 つの領域が含まれます。
+ データインジェスト
+ データ保持
+ データ移行アプローチ

## データインジェスト
<a name="data-ingestion"></a>

データインジェストは、Amazon OpenSearch Service ドメインにデータを取り込む方法に焦点を当てています。OpenSearch に適した取り込みフレームワークを選択するときは、データソースと形式を完全に理解することが最も重要です。

取り込み設計を作成またはモダナイズするには、さまざまな方法があります。セルフマネージド型の取り込みパイプラインを構築するための多数のオープンソースツールがあります。OpenSearch Service は、[Fluentd](https://www.fluentd.org/)、[Logstash](https://github.com/opensearch-project/logstash-output-opensearch)、[OpenSearch Data Prepper](https://docs.opensearch.org/latest/data-prepper/) との統合をサポートしています。これらのツールは、大半のログ分析ソリューション開発者に好まれています。これらのツールは、Amazon EC2 インスタンス、Amazon Elastic Kubernetes Service (Amazon EKS)、またはオンプレミスにデプロイできます。Logstash と Fluentd はどちらも、出力先として Amazon OpenSearch Service ドメインをサポートしています。ただし、そのためには、Fluentd または Logstash の維持管理、パッチ適用、テストを行い、ソフトウェアバージョンを最新の状態に保つ必要があります。

運用オーバーヘッドを減らすには、Amazon OpenSearch Service との統合をサポートする AWS マネージドサービスのいずれかを使用できます。例えば、[Amazon OpenSearch Ingestion](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ingestion.html) は、フルマネージド型のサーバーレスデータコレクターであり、Amazon OpenSearch Service ドメインにリアルタイムログ、メトリクス、トレースデータを配信します。OpenSearch Ingestion を使用すると、OpenSearch Service ドメインにデータを取り込むときに、Logstash や [Jaeger](https://www.jaegertracing.io/) などのサードパーティーのソリューションを使用する必要がなくなります。OpenSearch Ingestion にデータを送信するようにデータプロデューサーを設定します。その後、指定したドメインまたはコレクションにデータが自動的に配信されます。また、OpenSearch Ingestion で、送信前にデータを変換するように設定することもできます。

もう 1 つのオプションは、サーバーレス取り込みパイプラインの構築に役立つフルマネージドサービスである [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) です。Firehose は、[ストリーミングデータを取り込んで変換し、Amazon OpenSearch Service ドメインに配信](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html)する安全な方法を提供します。データのスループットに合わせて自動的にスケーリングし、継続的な管理は不要です。Firehose は AWS Lambda、OpenSearch Service ドメインにロードする前に、データを使用して受信レコードを変換、圧縮、バッチ処理することもできます。

マネージドサービスを使用すると、既存のデータインジェストパイプラインを廃止したり、現在のセットアップを拡張して運用上のオーバーヘッドを削減したりできます。

移行計画の立案は、現在の取り込みパイプラインが現在および将来のユースケースのニーズを満たすかどうかを評価するための良い機会となります。セルフマネージド型の Elasticsearch または OpenSearch クラスターから移行する場合、取り込みパイプラインは、クライアントライブラリの更新を最小限に抑えながら、現在のクラスターから Amazon OpenSearch Service ドメインへのエンドポイントのスワッピングをサポートする必要があります。

## データ保持
<a name="data-retention"></a>

データインジェストとストレージを計画するときは、必ずデータ保持の計画を立て、合意を得てください。ログ分析のユースケースでは、履歴データを廃止するための適切なポリシーをドメイン内に作成することが重要です。既存のオンプレミスおよびクラウド VM ベースのアーキテクチャから移行する場合、すべてのデータノードに特定のタイプのインスタンスを使用している可能性があります。データノードに同じ CPU、メモリ、ストレージプロファイルを設定しています。ほとんどのお客様は、高速インデックス作成要件を満たすように高スループットストレージを設定します。この単一のストレージプロファイルのアーキテクチャは、*ホットノードのみ*のアーキテクチャ、または「ホットオンリー」と呼ばれます。ホットオンリーアーキテクチャは、ストレージとコンピューティングを結合します。これは、ストレージ要件が増大した場合にコンピューティングノードを追加する必要があることを意味します。

ストレージをコンピューティングから切り離すために、Amazon OpenSearch Service は UltraWarm ストレージ階層を提供します。UltraWarm は、従来のデータノードよりも大量のデータに対応できるノードを提供することで、Amazon OpenSearch Service に読み取り専用データをコスト効率の高い方法で保存することができます。

計画立案の間に、データ保持と処理の要件を決定します。既存のソリューションのコストを削減するには、UltraWarm 階層を活用します。データ保持要件を特定します。次に、データをホットからウォームに移動するか、不要になったデータをドメインから自動的に削除する*インデックス状態管理ポリシー*を作成します。これにより、ドメインのストレージ不足を避けることもできます。

## データ移行アプローチ
<a name="data-migration-approaches"></a>

計画段階では、特定のデータ移行アプローチを決定することが重要です。データ移行アプローチは、現在のデータストアにあるデータを、ギャップなくターゲットストアに移動する方法を定めます。これらのアプローチの手順の詳細については、[ステージ 4 – データ移行](stage-4-data-migration.md)セクションで説明します。アプローチの実装はこのステージで行います。

このセクションでは、Elasticsearch または OpenSearch クラスターを Amazon OpenSearch Service に移行するために使用できるさまざまな方法とパターンについて説明します。パターンを選択するときは、次の要素のリストを考慮してください (すべて網羅しているわけではありません)。
+ 既存のセルフマネージ型のドクラスターからデータをコピーするか、元のデータソース (ログファイル、製品カタログデータベース) から再構築するか
+ ソース Elasticsearch または OpenSearch クラスターとターゲット Amazon OpenSearch Service ドメインのバージョン互換性
+ Elasticsearch または OpenSearch クラスターに依存するアプリケーションとサービス
+ 移行のために用意できる時間枠
+ 既存の環境内のインデックス付きデータの量

**スナップショットから構築する**

スナップショットは、セルフマネージド型 Elasticsearch クラスターから Amazon OpenSearch Service に移行する最も一般的な方法です。スナップショットは、Amazon S3 などの耐久性の高いストレージサービスを使用して、OpenSearch または Elasticsearch データをバックアップする方法を提供します。このアプローチでは、現在の Elasticsearch または OpenSearch 環境のスナップショットを作成し、ターゲットの Amazon OpenSearch Service 環境で復元します。スナップショットを復元した後、アプリケーションを新しい環境にポイントすることができます。これは以下の状況においてより迅速なソリューションとなります。
+ ソースとターゲットに互換性がある。
+ 既存のクラスターに大量のインデックス付きデータが含まれているため、インデックスの再作成に時間がかかる。
+ ソースデータがインデックスの再作成に対応していない。

その他の考慮事項については、「[ステージ 4 – データ移行](stage-4-data-migration.md)」セクションの「*スナップショットに関する考慮事項*」を参照してください。

**ソースから構築する**

このアプローチは、現在の Elasticsearch または OpenSearch クラスターからデータを移動しないことを意味します。代わりに、ログまたは製品カタログソースからターゲットの Amazon OpenSearch Service ドメインにデータを直接再ロードします。これは通常、既存のデータインジェストパイプラインに軽微な変更を加えて行われます。ログ分析のユースケースでは、ソースからの構築時に、ソースから新しい OpenSearch Service 環境に履歴ログを再ロードする必要がある場合もあります。検索のユースケースでは、完全な製品カタログとコンテンツを新しい Amazon OpenSearch Service ドメインに再ロードする必要がある場合があります。このアプローチは、以下のシナリオに適しています。
+ ソース環境とターゲット環境のバージョンが、スナップショットの復元と互換性がない場合。
+ 移行の一環として、ターゲット環境でデータモデルを変更する場合。
+ ローリングアップグレードを回避するために Amazon OpenSearch Service の最新バージョンにジャンプし、重大な変更に 1 回で対応したいと考えている場合。これは、比較的古いバージョンの Elasticsearch (5.x 以前) を自己管理している場合にお勧めします。
+ インデックス作成戦略を変更することもできます。例えば、毎日ロールオーバーする代わりに、新しい環境で毎月ロールオーバーできます。

ソースから構築するためのオプションについては、「*2. ソースから構築する*」(「[ステージ 4 – データ移行](stage-4-data-migration.md)」セクション) を参照してください。

**既存の Elasticsearch または OpenSearch 環境からリモートでインデックスを再作成する**

このアプローチでは、Amazon OpenSearch Service の[リモート再インデックス API](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/remote-reindex.html) を使用します。リモート再インデックスを使用すると、既存のオンプレミスまたはクラウドベースの Elasticsearch クラスターまたは OpenSearch クラスターから Amazon OpenSearch Service ドメインにデータを直接コピーできます。ターゲット環境にカットオーバーするまで、2 つの環境のロケーション間でデータを同期できるオートメーションを構築できます。

**オープンソースのデータ移行ツールを使用する**

既存の Elasticsearch 環境からターゲット Amazon OpenSearch 環境にデータを移行するには、複数のオープンソースツールを使用できます。その一例が Logstash ユーティリティです。Logstash ユーティリティを使用して、Elasticsearch または OpenSearch クラスターからデータを抽出し、Amazon OpenSearch Service ドメインにコピーできます。

すべてのオプションを評価し、最も使いやすいオプションを選択することをお勧めします。選択したアプローチをフールプルーフとするため、PoC ステージですべてのツールとオートメーションをテストします。これらのアプローチを実装する方法の詳細と、詳しいガイダンスについては、「[ステージ 4 – データ移行](stage-4-data-migration.md)」セクションを参照してください。