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

# ステージ 2 – 概念実証
<a name="stage-2-poc"></a>

移行を実行するときは、ターゲット状態のソリューションが要求通りに機能するかどうかを検証することが重要です。概念実証 (PoC) 演習を実行することを強くお勧めします。このセクションでは、PoC の実行時に考慮すべきさまざまな側面に焦点を当てます。
+ 開始条件と終了条件の定義
+ 資金の確保
+ 自動化
+ 入念なテスト
+ PoC ステージ
+ 障害シミュレーション

## 開始条件と終了条件の定義
<a name="entry-exit"></a>

明確な開始条件と終了条件を設定することは、PoC 演習を成功させる上で重要です。開始条件を定義する際は、次の点を考慮してください。
+ ユースケースの定義
+ 環境へのアクセス権
+ さまざまなサービスの知識
+ 関連するトレーニング要件

同様に、PoC の結果を評価するために使用できる終了条件を定義します。これには以下が含まれます。
+ 機能
+ パフォーマンス要件
+ セキュリティ実装 PoC

## 資金の確保
<a name="funding"></a>

PoC 条件の定義に基づいて、PoC の資金を確保します。適切なサイズ設定を実行し、関連するすべてのコストを検討していることを確認します。オンプレミスから AWS に移行する場合は、オンプレミスから AWS クラウドへのフレームワークの移行に関連するコストを含めます。AWS の既存のお客様の場合は、AWS アカウントマネージャーに相談して、Amazon OpenSearch Service への移行に使用できるクレジットの対象かどうかを確認してください。

## 自動化
<a name="automate"></a>

自動化を実行できる場面を特定し、テストを自動化してタイムボックス化するための専用トラックを計画します。デプロイとテストが自動化されると、人為的なエラーなしで繰り返しテスト、検証を迅速に行うことができます。

テストをタイムボックス化することで、時間どおりに実行し、課題が発生した場合は他のアクティビティに切り替えることができます。例えば、パフォーマンステストに想定よりも時間がかかる場合は、そのアクティビティを一時停止できます。その後、開発者が問題を解決している間、他のテストや検証アクティビティを進めることができます。問題が解決したら、パフォーマンステストに戻ることができます。既存のソリューションのパフォーマンスをベンチマークし、PoC 中に設定変更の影響を検証できる自動パフォーマンステストを作成します。

## 入念なテスト
<a name="testing"></a>

Amazon OpenSearch Service ドメインと統合されている取り込みパイプラインやクエリメカニズムなど、さまざまなレイヤーに必要な検証を実行し、スタックのすべての部分をテストします。これにより、エンドツーエンドのソリューション実装を検証できます。

**プレゼンテーションレイヤー**

プレゼンテーションレイヤーでは、次のアクティビティを含む PoC 演習を必ず実行してください。
+ **認証** — ユーザー認証用に計画したメカニズムを検証します。
+ **認可** — 準拠する認可メカニズムを特定し、期待どおりに動作することを確認します。
+ **質問** – 本番環境で発生する最も一般的なユースケースは何ですか? ビジネスにとって重要なエッジケースシナリオにはどのようなものがありますか? これらのパターンを特定し、PoC 中に検証します。
+ **レンダリング** – データは、ユースケース全体でさまざまなユーザーに対して正確かつ適切にレンダリングされていますか? ログ分析のユースケースでは、ターゲットバージョンに応じて OpenSearch Dashboards または Kibana でダッシュボードを構築してテストし、要件を満たしていることを確認できます。

**取り込みレイヤー**

取り込みレイヤーでは、収集、バッファリング、集約、ストレージなどのさまざまなコンポーネントを必ず評価してください。
+ **収集** – ログ分析のユースケースでは、ログに記録しているすべてのデータが収集されているかどうかを検証します。検索ユースケースでは、データを供給するソースを特定し、データの完全性と正確性の検証を実行して、収集フェーズが正常に実行されたことを確認します。
+ **バッファ** — トラフィックの急増が生じる場合は、取り込み対象のデータをバッファリングしていることを確認します。バッファリング設計を作成するには、さまざまな方法があります。例えば、Amazon Data Firehose でデータを収集したり、Amazon S3 ストレージをバッファとして使用したりできます。
+ **集約** – バルク API の使用など、取り込み中に実行するデータの集約を検証します。
+ **ストレージ** – 実行中の取り込みをストレージが最適に処理できるかどうかを検証します。

## PoC ステージ
<a name="poc-stages"></a>

PoC を実装し、結果を検証するには、次のような段階を踏むことをお勧めします。事前計画に時間をかけていたとしても、これらの PoC フェーズを繰り返し、計画した PoC を調整することを躊躇しないでください。
+ **機能テストと負荷テスト** — すべてのレベルについて入念にテストします。スタックのすべての部分で障害をシミュレートします。例えば、2 つの大きなノードを持つクラスターがあり、そのうちの 1 つがダウンした場合、もう 1 つのノードはクラスター上のすべてのトラフィックを占有する必要があります。このようなシナリオでは、小さいノードを多数用意するほど、ノード障害からの復旧がスムーズになる可能性があります。このようなシナリオでは、負荷のピーク時にワークロードをテストして、パフォーマンスに影響がないことを確認します。テスト中に問題を早い段階で提起し、潜在的な問題が適切なタイミングでさまざまな利害関係者によって評価されるようにします。
+ **KPI の検証と調整** – PoC の間に、PoC の終了条件で定義した KPI とビジネス成果を満たしていることを確認します。KPI を満たすように設定を調整します。
+ **自動化とデプロイ** – 自動化とモニタリングは、PoC テスト中に重点を置くべきもう 1 つの重要な側面です。自動化ステップを絞り込み、詳細なモニタリングとともに検証して、すべての利害関係者が PoC の結果を確信をもって評価できるように十分な情報を提供します。すべてのステップを文書化し、本番稼働への移行時に再利用できるランブックを作成します。

## 障害シミュレーション
<a name="failure-simulation"></a>

障害シナリオをシミュレートし、設計がユーザー要件を満たすために必要な回復力や耐障害性を備えているかどうかを検証することを強くお勧めします。データノードの障害をシミュレートして、クラスターにリカバリを適切に処理するのに十分なリソースがあるかどうかを確認できます。ドメインが大量の取り込みを処理しきれなくなる可能性を確認するには、一部のソースからのログの突然のバーストをシミュレートして、バッファリング設定をテストできます。本番稼働のデプロイにスケールするときに、設計がクォータを超えないことを確認します。詳細については、[サービスクォータ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/limits.html)に関する Amazon OpenSearch Service ドキュメントを参照してください。