기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# KPI 및 비즈니스 연속성
<a name="kpis-business-continuity"></a>

마이그레이션 중에 비즈니스 목표와 핵심 성과 지표(KPI)를 설정하여 성공을 측정하는 것이 중요합니다. 측정 가능한 개선 사항을 결정할 수 있도록 마이그레이션 프로세스를 시작할 때 목표를 결정하고 현재 시스템의 기준을 설정하는 것이 중요합니다. 고객 여정의 일반적인 목표는 다음과 같습니다.
+ 운영 민첩성을 개선합니다.

  이 목표에 따라 다음 지표를 사용하여 기존 배포를 측정하고 대상 환경과 비교할 수 있습니다.
  + 클러스터를 프로비저닝하는 데 걸리는 평균 시간
  + 배포를 새 리전으로 롤아웃하는 시간
  + 클러스터 보안을 구성하는 데 걸리는 평균 시간
  + 평균 환경 규모 조정 시간(예: 노드 추가 및 스토리지 추가)
  + 성능이 느린 쿼리를 감지하는 평균 시간과 평균 쿼리 복구 시간
  + 소프트웨어 버전을 업그레이드하는 평균 시간
+ 총 소유 비용(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 및 지연 시간 요구 사항이 포함됩니다. 이를 통해 현재 서비스 수준을 설정하고 대부분의 경우 이를 개선할 수 있습니다. 일반적으로 고객은 다음 서비스 수준 지표를 살펴봅니다.
+ 초당 읽기 및 쓰기
+ 읽기 및 쓰기 지연 시간
+ 가동 시간 백분율

자체 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는 프로덕션 수준의 지원 팀을 제공합니다. 즉, 직원은 비즈니스에 직접적인 가치를 더하는 활동에 집중할 수 있습니다.