データフロー - AWS 規範ガイダンス
データ取り込みデータ保持データ移行アプローチ

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

データフロー

データフローの焦点領域には、次の 3 つの領域が含まれます。

  • データ取り込み

  • データ保持

  • データ移行アプローチ

データ取り込み

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

取り込み設計を作成またはモダナイズするには、さまざまな方法があります。セルフマネージド取り込みパイプラインを構築するためのオープンソースツールは多数あります。OpenSearch Service は、Fluentd、Logstash、または OpenSearch Data Prepper との統合をサポートしています。これらのツールは、ほとんどのログ分析ソリューション開発者に人気があります。これらのツールは、Amazon EC2 インスタンス、Amazon Elastic Kubernetes Service (Amazon EKS)、またはオンプレミスにデプロイできます。Logstash と Fluentd はどちらも、出力先として Amazon OpenSearch Service ドメインをサポートしています。ただし、そのためには、Fluentd または Logstash ソフトウェアバージョンを最新の状態に保つ必要があります。

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

もう 1 つのオプションは、サーバーレス取り込みパイプラインの構築に役立つフルマネージドサービスである Amazon Data Firehose です。Firehose は、ストリーミングデータを取り込んで変換し、Amazon OpenSearch Service ドメインに配信する安全な方法を提供します。データのスループットに合わせて自動的にスケーリングでき、継続的な管理は必要ありません。Firehose は AWS Lambda、OpenSearch Service ドメインにロードする前に、データを使用して受信レコードを変換、圧縮、バッチ処理することもできます。

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

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

データ保持

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

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

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

データ移行アプローチ

計画段階では、特定のデータ移行アプローチを決定することが重要です。データ移行アプローチにより、現在のデータストアにあるデータを、ギャップなくターゲットストアに移動する方法が決まります。これらのアプローチの手順の詳細は、アプローチを実装するときのステージ 4 – データ移行セクションで説明されています。

このセクションでは、Elasticsearch または OpenSearch クラスターを Amazon OpenSearch Service に移行するために使用できるさまざまな方法とパターンについて説明します。パターンを選択するときは、次の要素のリストを考慮してください (網羅的ではありません）。

  • 既存のセルフマネージドクラスターからデータをコピーするか、元のデータソース (ログファイル、製品カタログデータベース) から再構築するか

  • ソース Elasticsearch または OpenSearch クラスターとターゲット Amazon OpenSearch Service ドメインのバージョン互換性

  • Elasticsearch または OpenSearch クラスターに依存するアプリケーションとサービス

  • 移行に使用できるウィンドウ

  • 既存の環境内のインデックス付きデータの量

スナップショットからビルドする

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

  • ソースとターゲットには互換性があります。

  • 既存のクラスターには大量のインデックス付きデータが含まれているため、インデックスの再作成に時間がかかる場合があります。

  • ソースデータはインデックスの再作成には使用できません。

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

ソースからビルドする

このアプローチは、現在の Elasticsearch または OpenSearch クラスターからデータを移動しないことを意味します。代わりに、ログまたは製品カタログソースからターゲットの Amazon OpenSearch Service ドメインにデータを直接再ロードします。これは通常、既存のデータインジェストパイプラインに軽微な変更を加えて行われます。ログ分析のユースケースでは、ソースから構築するには、ソースから新しい OpenSearch Service 環境に履歴ログを再ロードする必要もあります。検索のユースケースでは、完全な製品カタログとコンテンツを新しい Amazon OpenSearch Service ドメインに再ロードする必要がある場合があります。このアプローチは、以下のシナリオでうまく機能します。

  • ソース環境バージョンとターゲット環境バージョンは、スナップショットの復元と互換性がありません。

  • 移行の一環として、ターゲット環境でデータモデルを変更する場合。

  • ローリングアップグレードを回避するために Amazon OpenSearch Service の最新バージョンにジャンプし、重大な変更に 1 回で対応したいと考えています。これは、比較的古いバージョンの Elasticsearch (5.x 以前) を自己管理している場合にお勧めします。

  • インデックス作成戦略を変更することもできます。たとえば、毎日ロールオーバーする代わりに、新しい環境で毎月ロールオーバーできます。

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

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

このアプローチでは、Amazon OpenSearch Service のリモート再インデックス API を使用します。リモート再インデックスを使用すると、既存のオンプレミスまたはクラウドベースの Elasticsearch クラスターまたは OpenSearch クラスターから Amazon OpenSearch Service ドメインにデータを直接コピーできます。ターゲット環境にカットオーバーするまで、2 つの環境の場所間でデータを同期できるオートメーションを構築できます。

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

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

すべてのオプションを評価し、最も慣れているオプションを選択することをお勧めします。選択したアプローチがバカにならないようにするには、PoC 段階ですべてのツールとオートメーションをテストします。これらのアプローチを実装する方法の詳細とstep-by-stepガイダンスについては、「ステージ 4 – データ移行」セクションを参照してください。