ステージ 2 – 概念実証

移行を実行するときは、ターゲット状態ソリューションが必要に応じて機能するかどうかを証明することが重要です。proof-of-concept (PoC) 演習を実行することを強くお勧めします。このセクションでは、PoC の実行時に考慮すべきさまざまな側面に焦点を当てます。

• エントリ条件と終了条件の定義

• 資金の保護

• 自動化

• 徹底的なテスト

• PoC ステージ

• 障害シミュレーション

エントリ条件と終了条件の定義

PoC の演習を成功させるには、明確な開始基準と終了基準を持つことが重要です。エントリ条件を定義するときは、次の点を考慮してください。

• ユースケースの定義

• 環境へのアクセス

• さまざまなサービスに精通していること

• 関連するトレーニング要件

同様に、PoC の結果を評価するために使用できる終了基準を定義します。これには、以下が含まれます。

• 機能

• パフォーマンス要件

• セキュリティ実装 PoC

資金の保護

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

自動化

自動化を実行できる場所を特定し、テストを自動化してタイムボックス化するための専用トラックを計画します。自動デプロイとテストは、人間によるエラーを発生させることなく、迅速なペースでリフォーム、繰り返し、テスト、検証を行うのに役立ちます。

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

徹底的なテスト

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

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

プレゼンテーションレイヤーでは、次のアクティビティを含む PoC 演習を必ず実行してください。

• 認証 — ユーザーを認証するための計画されたメカニズムを検証します。

• 認可 — 従う認可メカニズムを特定し、期待どおりに動作していることを確認します。

• クエリ – 本番環境で発生する最も一般的なユースケースは何ですか？ ビジネスにとって重要なエッジケースシナリオにはどのようなものがありますか？ これらのパターンを特定し、PoC 中に検証します。

• レンダリング — データは、ユースケース全体でさまざまなユーザーに対して正確かつ適切にレンダリングされていますか？ ログ分析のユースケースでは、ターゲットバージョンに応じて OpenSearch Dashboards または Kibana でダッシュボードを構築してテストし、要件を満たしていることを確認することができます。

取り込みレイヤー

取り込みレイヤーでは、収集、バッファリング、集約、ストレージなどのさまざまなコンポーネントを必ず評価してください。

• 収集 – ログ分析のユースケースでは、ログ記録しているすべてのデータが収集されているかどうかを検証します。検索ユースケースでは、データを供給するソースを特定し、データの完全性と正確性を検証して、収集フェーズが正常に実行されたことを確認します。

• バッファ — トラフィックが急増している場合は、取り込まれるデータをバッファリングしていることを確認できます。バッファリング設計を作成するには、さまざまな方法があります。例えば、Amazon Data Firehose でデータを収集したり、Amazon S3 ストレージをバッファとして使用したりできます。

• 集約 — 取り込み中に実行する一括 API の使用などのデータの集約を検証します。

• ストレージ – 実行している取り込みをストレージが最適に処理できるかどうかを検証します。

PoC ステージ

PoC を実装し、結果を検証するには、次のステージを使用することをお勧めします。事前に計画に時間を費やしても、これらの PoC フェーズを繰り返して計画 PoC を調整することをためらわないでください。

• 機能テストと負荷テスト — すべてのレベルが徹底的にテストされていることを確認します。スタックのすべての部分の障害をシミュレートします。例えば、2 つの大きなノードを持つクラスターがあり、そのうちの 1 つがダウンした場合、もう 1 つのノードはクラスター上のすべてのトラフィックを占有する必要があります。このようなシナリオでは、ノードの数が多いほど、ノード障害からの復旧がスムーズになる可能性があります。このようなシナリオでは、ピーク負荷以上のワークロードをテストして、パフォーマンスに影響がないことを確認します。テスト中に問題を早期に提起し、潜在的な問題がさまざまな利害関係者によって適切なタイミングで評価されるようにします。

• KPIs の検証と調整 — PoC 中に、PoC PoC の終了基準で定義した KPIsとビジネス成果を満たしていることを確認します。KPIs を満たすように設定を調整します。

• 自動化とデプロイ — 自動化とモニタリングは、PoC テスト中に重点を置くべきその他の重要な側面です。自動化ステップを絞り込み、詳細なモニタリングとともに検証して、すべての利害関係者に PoC の結果を自信を持って評価するための十分な情報を提供します。すべてのステップを文書化し、本番稼働用移行に再利用できるランブックを作成します。

障害シミュレーション

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