KPIsとビジネス継続性

移行中は、ビジネス目標と主要業績評価指標 (KPIs) を確立して成功を測定することが重要です。移行プロセスの開始時に目標を決定し、現在のシステムのベースラインを確立して、測定可能な改善点を決定できるようにすることが重要です。カスタマージャーニーの一般的な目標は次のとおりです。

• 運用の俊敏性を向上させます。

  この目標では、次のメトリクスを使用して既存のデプロイを測定および比較できます。

  • クラスターをプロビジョニングする平均時間。

  • 新しい地域にデプロイをロールアウトする時間

  • クラスターセキュリティを設定する平均時間

  • 環境をスケーリングする平均時間 (ノードの追加やストレージの追加など）

  • パフォーマンスの低いクエリを検出する平均時間と、クエリを修復する平均時間

  • ソフトウェアバージョンをアップグレードする平均時間

• 総所有コスト (TCO) を削減します。

  現在の TCO を計算するには、次のメトリクスを使用できます。

  • ソリューションを構築して運用するスタッフ時間 (開発、DevOps、モニタリング、スケーリング、バックアップ、復元）

  • 既存のソフトウェアに関連するライセンスコスト

  • データセンターのコスト (ハードウェアの調達と更新、電力、冷却、スペース、ラック、ネットワーク機器）

  • ソリューションを設定するスタッフ時間 (ソフトウェアのインストール、ネットワーク）

  • コンプライアンス監査のコスト (HIPAA、PCI DSS、SOC、ISO、GDPR、FedRAMP)

  • セキュリティの設定コスト (保管時および転送時の暗号化、認証と認可の設定、きめ細かなアクセスコントロール）

  • 大量のウォームデータとコールドデータを保持するコスト

  • アベイラビリティーゾーン間で高可用性を設定するコスト

  • 頻繁なハードウェア調達やピーク負荷の処理を避けるためのオーバープロビジョニングのコスト

  これはすべてを網羅したリストではありません。

• 稼働時間およびその他のサービスレベルアグリーメント (SLAs。新しい環境に移行することで測定および改善できる SLAs は次のとおりです。

  • 合計稼働時間 (Amazon OpenSearch Service が提供する 99.9% の SLA と比較した既存のデプロイの履歴稼働時間データ）

  • 障害復旧 (目標復旧時点と目標復旧時間）

  • さまざまな関数 (検索やインデックス作成など) に関連する応答時間

  • 同時ユーザー数

  • 異なる地域とクラスター間のレプリケーション時間。

Amazon OpenSearch Service に移行するときは、反復プロセスを使用して、これらの KPIs、および望ましい成果を達成しているかどうかを検証します。

運用パフォーマンス

現在のソリューションで確認すべき重要な領域は、パフォーマンスメトリクスです。ベンチマークを確立し、ターゲット環境内で達成することが期待される改善点を決定します。これには、稼働時間の SLA とレイテンシーの要件が含まれます。これにより、ほとんどの場合、現在のサービスレベルを確立し、改善することができます。通常、お客様は以下のサービスレベルインジケータを確認します。

• 1 秒あたりの読み取りと書き込み

• 読み取りおよび書き込みのレイテンシー

• 稼働時間の割合

独自の SLAs を設計するときは、Amazon OpenSearch Service - サービスレベルアグリーメントを完全に理解することが重要です。

プロセスのパフォーマンス

ビジネス継続性の目標を確立するには、現在のプロセスパフォーマンスを評価することが重要です。現在のプラットフォームの既存のランブックまたは標準運用手順 (SOPs) を特定して確認し、チームがほとんどの時間を費やす領域を決定します。移行は、チームがイノベーション、ビジネス機能の構築、カスタマーエクスペリエンスの向上に集中できるように、これらの領域の改善に取り組む良い機会です。サポートや開発スタッフがこれらの問題を解決するのに費やした時間を判断するために、過去のサポートやトラブルチケットのデータを確認することで、既存の環境の問題点を特定できます。次のメトリクスをキャプチャすると、ターゲット環境によって提供される改善を測定するのに役立ちます。

• 平均失敗時間 (MTTF) (稼働時間）

• 平均障害間隔 (MTBF)

• 障害を検出する平均時間 (MTTD)

• 平均修復 (解決) 時間 (MTTR)

• 受信したサポートチケットの数

新しいサービスへのスムーズな移行

サービスの事業継続性を確保するには、シームレスな移行を慎重に計画することが重要です。移行は、アプリケーションと、検索またはログ分析プラットフォームに関連付けられたサービスをモダナイズする良い機会です。ただし、既存のサービスに影響を与えない慎重なカットオーバー戦略を計画する必要があります。このドキュメントのカットオーバー戦略セクションでは、ターゲット環境へのシームレスなカットオーバーを計画する方法に関する情報を提供します。

財務メトリクス

Amazon OpenSearch Service に移行する理由は多数ありますが、一般的にコストが重要な要素です。マネージドサービスに移行することで得られるコスト削減を測定できるように、既存の環境の総所有コスト (TCO) を理解します。まず、「総所有コストの削減目標」に記載されているメトリクスのリストから始めることができます。AWS は、チームが AWS クラウドに移行するためのビジネスケースを作成するのに役立つクラウドバリューベンチマーク調査を発表しました。この調査は Amazon OpenSearch Service に固有ではありませんが、Amazon OpenSearch Service への移行など、ほとんどのクラウド移行で共通する主要な価値分野を対象としています。

ほとんどの場合、Amazon OpenSearch Service は TCO を削減します。TCO を計算するときは、人員配置コストを組み込むことが重要です。エンジニアが現在の環境を維持するために費やす時間とコストを理解することは、重要な要素です。多くのお客様は、ストレージ、コンピューティング、ネットワークインフラストラクチャのコストとマネージドサービスのコストのみを比較します。ただし、これにより正確な総所有コストが得られない場合があります。Amazon OpenSearch Service は、エンジニアが実行しなければならなかったタスクを管理することで、チームの運用効率を向上させます。これには、次のタスクが含まれます。

• ノードを追加または削除してクラスターをスケーリングする

• パッチ適用

• インプレースのアップグレード

• バックアップの取得

• ログとメトリクスをキャプチャするためのモニタリングツールの設定

これらのアクティビティは サービスによって自動化され、AWS は本番稼働レベルのサポートチームを提供します。つまり、スタッフはビジネスに直接価値をもたらすアクティビティに集中できます。