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

# KPI とビジネス継続性
<a name="kpis-business-continuity"></a>

移行の間に、成功を測定するためのビジネス目標と主要業績評価指標 (KPIs) を確立することは不可欠です。移行プロセスの開始時に目標を決定し、現在のシステムのベースラインを確立することで、測定可能な改善内容を決定できるようにすることが重要です。カスタマージャーニーの一般的な目標は次のとおりです。
+ 運用の俊敏性を向上させます。

  この目標に基づき、次のメトリクスを使用して既存のデプロイを測定し、ターゲット環境と比較できます。
  + クラスターをプロビジョニングするための平均所要時間
  + 新しい地域にデプロイをロールアウトするための所要時間
  + クラスターセキュリティを設定するための平均所要時間
  + 環境をスケーリングするための平均所要時間 (ノードの追加やストレージの追加など)
  + パフォーマンスの低いクエリを検出するための平均所要時間と、クエリを修復するための平均所要時間
  + ソフトウェアバージョンをアップグレードするための平均所要時間
+ 総保有コスト (TCO) を削減します。

  現在の TCO を計算するには、次のメトリクスを使用できます。
  + ソリューションの構築と運用にかかる工数 (開発、DevOps、モニタリング、スケーリング、バックアップ、復元)
  + 既存のソフトウェアに関連するライセンスコスト
  + データセンターのコスト (ハードウェアの調達と更新、電力、冷却、スペース、ラック、ネットワーク機器)
  + ソリューションの設定にかかる工数 (ソフトウェアのインストール、ネットワーク設定)
  + コンプライアンス監査コスト (HIPAA、PCI DSS、SOC、ISO、GDPR、FedRAMP)
  + セキュリティの設定コスト (保管時および転送時の暗号化、認証と認可の設定、きめ細かなアクセスコントロール)
  + 大量のウォームデータとコールドデータを保持するコスト
  + アベイラビリティーゾーン間で高可用性を設定するコスト
  + 頻繁なハードウェア調達やピーク負荷の処理を避けるためのオーバープロビジョニングのコスト

  これはすべてを網羅したリストではありません。
+ 稼働時間およびその他のサービスレベルアグリーメント (SLA) を監視します。新しい環境に移行することで測定および改善できる SLA は次のとおりです。
  + 合計稼働時間 (Amazon OpenSearch Service が提供する 99.9% の SLA と比較した既存のデプロイの過去の稼働時間データ)
  + 障害復旧 (目標復旧時点と目標復旧時間)
  + さまざまな機能 (検索やインデックス作成など) に関連する応答時間
  + 同時ユーザーの数
  + 異なる地域とクラスター間のレプリケーション時間。

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

## 運用パフォーマンス
<a name="operational-performance"></a>

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

独自の SLA を作成するときは、[Amazon OpenSearch Service - サービスレベルアグリーメント](https://aws.amazon.com/elasticsearch-service/sla/)を完全に理解することが重要です。

## プロセスのパフォーマンス
<a name="process-performance"></a>

ビジネス継続性の目標を確立するには、現在のプロセスパフォーマンスを評価することが重要です。現在のプラットフォームの既存のランブックまたは標準運用手順 (SOP) を確認し、チームが大半の時間を費やしている領域を判断します。移行は、チームがイノベーション、ビジネス機能の構築、カスタマーエクスペリエンスの向上に集中できるように、これらの領域の改善に取り組む良い機会です。サポート履歴やトラブルチケットデータを確認することで、既存の環境の問題点を特定し、サポートや開発スタッフがこれらの問題を解決するのに費やした時間を判断できます。次のメトリクスを把握することは、ターゲット環境によってもたらされる改善を測定するのに役立ちます。
+ 平均故障時間 (MTTF) (稼働時間)
+ 平均故障間隔 (MTBF)
+ 故障の平均検出時間 (MTTD)
+ 平均修復時間 (MTTR)
+ 受信したサポートチケットの数

## 新しいサービスへのスムーズな移行
<a name="transition"></a>

サービスのビジネス継続性を確保するには、シームレスな移行を入念に計画することが重要です。移行は、アプリケーションと、検索またはログ分析プラットフォームに関連付けられたサービスをモダナイズする良い機会です。ただし、既存のサービスに影響を与えないように、カットオーバー戦略を慎重に計画する必要があります。このドキュメントの[カットオーバー戦略](stage-5-cutover.md)セクションでは、ターゲット環境へのシームレスなカットオーバーを計画する方法について説明します。

## 財務メトリクス
<a name="financial-metrics"></a>

Amazon OpenSearch Service に移行する理由は多数ありますが、一般的に重要な要因はコストです。既存の環境の総保有コスト (TCO) を把握して、マネージドサービスへの移行により達成したコスト削減効果を測定できるようにします。*総保有コストの削減*目標に記載されているメトリクスのリストを出発点とすることができます。AWS は、チームが AWS クラウドへの移行のビジネスケースを作成するのに役立つ、[クラウドバリューベンチマーク調査](https://pages.awscloud.com/rs/112-TZM-766/images/cloud-value-benchmarking-study-quantifies-cloud-adoption-benefits.pdf)を発表しました。この調査は Amazon OpenSearch Service に固有のものではありませんが、Amazon OpenSearch Service への移行など、ほとんどのクラウド移行で共通する主要な価値領域を対象としています。

ほとんどのケースで、Amazon OpenSearch Service は TCO を削減します。TCO を計算するときは、人員配置コストを組み込むことが重要です。エンジニアが現在の環境を維持するために費やす時間とコストを理解することは、重要な要素です。多くのお客様は、ストレージ、コンピューティング、ネットワークインフラストラクチャのコストとマネージドサービスのコストのみを比較します。しかしながら、これでは正確な総保有コストが得られません。Amazon OpenSearch Service は、エンジニアが実行するしかなかったタスクを管理することで、チームの運用効率を向上させます。これには以下のタスクが含まれます。
+ ノードを追加または削除してクラスターをスケーリングする
+ パッチ適用
+ インプレースのアップグレード
+ バックアップの取得
+ ログとメトリクスをキャプチャするためのモニタリングツールの設定

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