View a markdown version of this page

2단계 - 개념 증명 - AWS 권장 가이드
진입 및 종료 기준 정의자금 확보자동화철저한 테스트PoC 단계장애 시뮬레이션

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

2단계 - 개념 증명

마이그레이션을 수행할 때 대상 상태 솔루션이 필요에 따라 작동하는지 입증하는 것이 중요합니다. 개념 증명(PoC) 연습을 실행하는 것이 좋습니다. 이 섹션에서는 PoC를 실행하는 동안 고려해야 할 다양한 측면에 중점을 둡니다.

  • 진입 및 종료 기준 정의

  • 자금 확보

  • 자동화

  • 철저한 테스트

  • PoC 단계

  • 장애 시뮬레이션

진입 및 종료 기준 정의

명확한 진입 및 종료 기준이 성공적인 PoC 연습의 핵심입니다. 진입 기준을 정의할 때 다음 사항을 고려하세요.

  • 사용 사례 정의

  • 환경에 대한 액세스

  • 다양한 서비스에 대한 숙지

  • 관련 교육 요구 사항

마찬가지로 다음을 포함하여 PoC 결과를 평가하는 데 사용할 수 있는 종료 기준을 정의합니다.

  • 기능

  • 성능 요구 사항

  • 보안 구현 PoC

자금 확보

PoC 기준 정의를 기반으로 PoC에 대한 자금을 확보합니다. 적정 규모 조정을 수행하고 관련된 모든 비용을 고려했는지 확인합니다. 온프레미스에서 AWS로 마이그레이션하는 경우 온프레미스에서 AWS 클라우드로 프레임워크를 마이그레이션하는 것과 관련된 비용을 포함합니다. 기존 AWS 고객인 경우 AWS 계정 관리자와 협력하여 Amazon OpenSearch Service로 마이그레이션하는 데 사용할 수 있는 크레딧을 받을 자격이 있는지 확인합니다.

자동화

자동화를 수행할 수 있는 위치를 식별하고 테스트를 자동화하고 테스트 기한을 설정하기 위해 전용 트랙을 계획합니다. 자동화된 배포 및 테스트를 사용하면 사람으로 인한 오류 없이 빠른 속도로 린스, 반복, 테스트 및 검증할 수 있습니다.

테스트 기한을 설정하면 적시에 제공하고 문제가 발생할 경우 다른 활동으로 전환할 수 있습니다. 예를 들어 성능 테스트가 예상 시간보다 오래 걸리는 경우 해당 활동을 일시 중지할 수 있습니다. 그런 다음 개발자가 문제를 해결하는 동안 다른 테스트 및 검증 활동으로 이동할 수 있습니다. 문제가 해결된 후 성능 테스트로 돌아갈 수 있습니다. 기존 솔루션 성능을 벤치마킹하고 PoC 중에 구성 변경의 영향을 검증할 수 있는 자동화된 성능 테스트를 생성합니다.

철저한 테스트

Amazon OpenSearch Service 도메인과 통합되는 수집 파이프라인 및 쿼리 메커니즘과 같이 여러 계층에 필요한 검증을 수행하는지 확인하여 스택의 모든 부분을 테스트합니다. 이렇게 하면 포괄적인 솔루션 구현을 검증하는 데 도움이 됩니다.

프레젠테이션 계층

프레젠테이션 계층에서 다음 활동이 포함된 PoC 연습을 실행해야 합니다.

  • 인증 - 사용자를 인증하기 위해 계획된 메커니즘을 검증합니다.

  • 권한 부여 - 따르려는 권한 부여 메커니즘을 식별하고 예상대로 작동하는지 확인합니다.

  • 쿼리 - 프로덕션 환경에서 발생할 수 있는 가장 일반적인 사용 사례는 무엇인가요? 비즈니스에 중요한 엣지 케이스 시나리오는 무엇인가요? 이러한 패턴을 식별하고 PoC 중에 검증합니다.

  • 렌더링 - 데이터가 사용 사례 전반에 걸쳐 다양한 사용자에 대해 정확하고 적절하게 렌더링되고 있나요? 로그 분석 사용 사례의 경우 대상 버전에 따라 OpenSearch Dashboards 또는 Kibana에서 대시보드를 빌드하고 테스트하여 요구 사항을 충족하는지 확인할 수 있습니다.

수집 계층

수집 계층에서 수집, 버퍼링, 집계 및 스토리지와 같은 다양한 구성 요소를 평가해야 합니다.

  • 수집 - 로그 분석 사용 사례의 경우 로깅 중인 모든 데이터가 수집되고 있는지 확인합니다. 검색 사용 사례의 경우 데이터를 공급하는 소스를 식별하고 데이터의 완전성 및 정확성에 대한 검증을 수행하여 수집 단계가 성공적으로 실행되었는지 확인합니다.

  • 버퍼 - 트래픽이 급증하는 경우 수집되는 데이터를 버퍼링하고 있는지 확인하길 원할 수 있습니다. 버퍼링 설계를 생성하는 여러 방법이 있습니다. 예를 들어 Amazon Data Firehose에서 데이터를 수집하거나 Amazon S3 스토리지를 버퍼로 사용할 수 있습니다.

  • 집계 - 수집 중에 수행하는 대량 API 사용량과 같은 데이터 집계를 검증합니다.

  • 스토리지 - 스토리지에서 사용자가 수행 중인 수집을 최적으로 처리할 수 있는지 검증합니다.

PoC 단계

다음 단계를 사용하여 PoC를 구현하고 결과를 검증하는 것이 좋습니다. 미리 계획에 시간을 투자했더라도 이러한 PoC 단계를 반복하고 계획 PoC를 조정하는 것을 두려워하지 마세요.

  • 기능 테스트 및 로드 테스트 - 모든 수준을 철저하게 테스트하고 있는지 확인합니다. 스택의 모든 부분에서 실패를 시뮬레이션합니다. 예를 들어 클러스터에 큰 노드가 두 개 있고 그중 하나가 중단되는 경우 다른 노드가 클러스터의 모든 트래픽을 계속 처리해야 합니다. 이러한 시나리오에서는 더 작은 노드 수가 많을수록 노드 장애로부터 더 원활하게 복구될 수 있습니다. 피크 로드가 넘는 수준에서 워크로드를 테스트하여 이러한 시나리오에서 성능이 영향을 받지 않는지 확인합니다. 테스트 중에 다양한 이해관계자가 잠재적 문제를 적시에 평가할 수 있도록 문제를 조기에 제기합니다.

  • KPI 확인 및 조정 - PoC 중에 PoC 종료 기준에서 정의한 KPI 및 비즈니스 성과를 충족하는지 확인합니다. KPI를 충족하도록 구성을 조정합니다.

  • 자동화 및 배포 - 자동화 및 모니터링은 PoC 테스트 중에 중점을 두어야 할 또 다른 주요 측면입니다. 자동화 단계를 세부 조정하고 세부 모니터링과 함께 검증하여 모든 이해관계자에게 PoC의 결과를 자신 있게 평가할 수 있는 충분한 정보를 제공합니다. 모든 단계를 문서화하고 프로덕션 마이그레이션에 재사용할 수 있는 런북을 생성합니다.

장애 시뮬레이션

장애 시나리오를 시뮬레이션하고 설계가 사용자 요구 사항을 충족하는 데 필요한 복원력과 내결함성을 제공하는지 확인하는 것이 좋습니다. 복구를 정상적으로 처리하기에 충분한 리소스가 클러스터에 있는지 확인하기 위해 데이터 노드의 장애를 시뮬레이션하고 싶을 수 있습니다. 도메인이 대량 수집으로 인해 압도될 수 있는지 확인하려면 일부 소스에서 갑작스러운 로그 버스트를 시뮬레이션하여 버퍼링 설정을 테스트할 수 있습니다. 프로덕션 배포로 규모를 조정할 때 설계가 할당량을 초과하지 않는지 확인합니다. 자세한 내용은 Amazon OpenSearch Service 설명서의 service quotas를 참조하세요.