기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 운영 우수성 요소
AWS Well-Architected Framework의 [운영 우수](https://docs.aws.amazon.com/wellarchitected/latest/framework/operational-excellence.html)성 원칙은 시스템을 실행 및 모니터링하고 프로세스와 절차를 지속적으로 개선하는 데 중점을 둡니다. 여기에는 효과적인 개발 및 워크로드 실행을 지원하고, 작업에 대한 인사이트를 얻으며, 지원 프로세스 및 절차를 지속적으로 개선하여 비즈니스 가치를 전달할 수 있는 능력이 포함됩니다. 사람의 개입 없이 대부분의 문제를 감지하고 해결하는 자가 복구 워크로드를 통해 운영 복잡성을 줄일 수 있습니다. 이 섹션에 설명된 모범 사례를 따르면 이 목표를 달성할 수 있습니다. Amazon Neptune 지표, API 및 메커니즘을 사용하여 워크로드가 예상 동작과 다를 때 적절하게 대응합니다.
운영 우수성 원칙에 대한 이 논의는 다음 핵심 영역에 중점을 둡니다.
+ 코드형 인프라(IaC)
+ 변경 관리
+ 복원력 전략
+ 인시던트 관리
+ 규정 준수를 위한 감사 보고
+ 로깅 및 모니터링
## IaC 접근 방식을 사용하여 배포 자동화
IaC를 사용하여 Neptune에서 배포를 자동화하는 모범 사례로 다음이 포함됩니다.
+ 가능하면 코드형 인프라(IaC)를 적용하여 Neptune 클러스터를 배포합니다. 일관된 환경 구성을 위해 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 템플릿, [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) 또는 [HashiCorp Terraform](https://aws.amazon.com/blogs/apn/terraform-beyond-the-basics-with-aws/)을 사용하여 클러스터에 필요한 모든 리소스를 생성합니다.
+ 인스턴스 크기 조정, 읽기 복제본 추가 또는 제거, 가능하면 글로벌 테이블에서 수동 장애 조치 수행과 같은 Neptune 운영 절차를 자동화합니다.
+ 연결 문자열을 클라이언트 외부에 저장합니다. 추출, 전환, 적재(ETL) 프로세스를 사용하여 블루/그린 배포 전략, 재해 복구(DR) 및 가동 중지 시간이 거의 없는 새 클러스터로의 마이그레이션을 용이하게 합니다. 연결 문자열은 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) 또는 동적으로 변경할 수 있는 모든 위치에 저장할 수 있습니다.
+ 태그를 사용하여 Neptune 리소스에 메타데이터를 추가하고 태그를 기반으로 사용량을 추적합니다. 자세한 내용은 [Tagging Amazon Neptune Resources](https://docs.aws.amazon.com/neptune/latest/userguide/tagging.html)를 참조하세요.
## 되돌릴 수 있는 소규모 변경 자주 적용
다음 권장 사항은 복잡성을 최소화하고 워크로드 중단 가능성을 줄이기 위해 작고 되돌릴 수 있는 변경 사항에 중점을 둡니다.
+ GitHub 또는 GitLab과 같은 소스 제어 서비스에 IaC 템플릿 및 스크립트를 저장합니다.
**중요**
소스 제어에 AWS 자격 증명을 저장하지 마십시오.
+ IaC 배포에서 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 또는 [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)와 같은 지속적 통합 및 지속적 전송(CI/CD) 서비스를 사용해야 합니다. 이러한 서비스는 [프로덕션 Amazon Neptune 클러스터](https://aws.amazon.com/blogs/database/automated-testing-of-amazon-neptune-data-access-with-apache-tinkerpop-gremlin/)에 영향을 미치기 전에 임시 Neptune 클러스터가 포함된 비프로덕션 환경에서 코드를 컴파일, 테스트 및 배포합니다.
+ 인프라 및 애플리케이션 쿼리를 프로덕션에 배포하기 전에 더 하위 환경에서 테스트합니다. 그러면 중단 가능성을 최소화하고 워크로드 및 규모에 맞게 원활하게 작동할 수 있습니다.
## 실패 예상
자가 복구 인프라는 장애를 예상하고 개입 없이 문제를 해결하려고 시도하며 운영 우수성을 보여줍니다. 다음 권장 사항은 Neptune을 사용하여 이러한 성숙도를 달성하는 데 도움이 됩니다.
+ Amazon CloudWatch 지표를 사용하여 DB 인스턴스의 CPU 및 메모리 사용량을 모니터링하고 사용 패턴을 이해하는 모니터링 계획을 생성합니다. 애플리케이션 로그에 있는 주요 지표 및 Neptune 클라이언트 응답에 대한 CloudWatch 대시보드 및 경보를 생성합니다. CPU 사용률이 높거나 낮은 지표에 대한 자세한 내용은 Neptune 설명서의 [Using CloudWatch to monitor DB instance performance in Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/cloudwatch-monitoring-instances.html)을 참조하세요.
쿼리에 out-of-memory 예외가 자주 발생하는 경우 쿼리가 통과하는 총 노드 수를 줄이거나 RAM-to-CPU 비율이 높은 `X2` 패밀리의 인스턴스를 사용해 보세요.
+ 알림을 설정하여 Neptune 클러스터의 상태를 모니터링합니다. 예를 들어 `BufferCacheHitRatio`는 지속적으로 높아야 하지만(99.9% 초과) `MainRequestQueuePendingRequests`는 지속적으로 낮아야 합니다(이상적으로는 0이지만 요구 사항 및 지연 시간 허용치에 따라 다름).
+ 읽기 복제본을 사용하여 Neptune 내에서 고가용성을 달성하는 것이 좋습니다. 장애 조치 이벤트 중에 항상 읽기 쿼리를 지원할 수 있도록 인스턴스를 상시 가동하려면 라이터 인스턴스와 다른 가용 영역에 읽기 복제본이 두 개 이상 있어야 합니다.
+ 사용률 지표를 기반으로 읽기 복제본의 크기를 자동으로 조정합니다. 자세한 내용은 [Auto-scaling the number of replicas in an Amazon Neptune DB cluster](https://docs.aws.amazon.com/neptune/latest/userguide/manage-console-autoscaling.html)를 참조하세요.
+ DB 인스턴스의 장애 조치를 테스트하여 사용 사례 절차에 소요되는 시간을 파악하십시오.
+ 애플리케이션에 완전한 AWS 리전 중단이 지속되어야 하는 경우 [글로벌 데이터베이스를](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-gdb-disaster-recovery.html) DR 계획의 일부로 사용하는 것이 좋습니다.
## 모든 운영 장애로부터 학습
자가 복구 인프라는 드문 문제가 발생하거나 응답이 원하는 만큼 효과적이지 않을 때 반복으로 발전하는 장기적인 노력을 보여줍니다. 다음 사례를 채택하면 다음과 같은 목표에 집중합니다.
+ 모든 장애로부터 학습하여 개선을 주도합니다.
+ 조직과 여러 팀에서 학습한 내용을 공유합니다. 조직 내 여러 팀이 Neptune을 사용하는 경우 공통 채팅룸 또는 사용자 그룹을 생성하여 학습 내용과 모범 사례를 공유합니다.
## 로깅 기능을 사용하여 무단 또는 비정상적인 활동 모니터링
비정상적인 성능 및 활동 패턴을 관찰하려면 Amazon CloudWatch Logs에 로그를 저장합니다. 다음 모범 사례를 고려하세요.
+ [느린 쿼리 로깅](https://docs.aws.amazon.com/neptune/latest/userguide/slow-query-logs.html)을 비활성화합니다. 로그를 정기적으로 검토하고 특정 쿼리가 느린 이유를 진단합니다. [Gremlin](https://docs.aws.amazon.com/neptune/latest/userguide/gremlin-profile-api.html), [SPARQL](https://docs.aws.amazon.com/neptune/latest/userguide/sparql-explain.html) 또는 [openCypher](https://docs.aws.amazon.com/neptune/latest/userguide/access-graph-opencypher-explain.html)에 대한 Neptune 설명 및 프로파일 엔드포인트를 사용하여 이러한 쿼리가 느린 이유를 파악할 수 있습니다.
+ [Neptune 감사 로그를 활성화](https://docs.aws.amazon.com/neptune/latest/userguide/auditing.html#auditing-enable)하고 로그에 무단 액세스 또는 이상이 있는지 정기적으로 검토합니다.
+ 느린 쿼리 로깅 또는 감사 로깅을 사용하는 경우 CloudWatch Logs에 대한 게시를 활성화합니다. 이렇게 하면 인스턴스의 디스크 공간 부족을 방지할 수 있습니다. Neptune 인스턴스는 로그 스토리지 용량을 제한하며 로그 공간이 초과되면 이전 로그 파일을 덮어씁니다. CloudWatch Logs는 로그의 장기 보존을 지원합니다. CloudWatch Logs의 향상된 모니터링 기능은 로그를 쿼리하고 문제를 진단하는 기능을 개선합니다.
+ 감사 로그에 대한 더 나은 분석 도구를 용이하게 하기 위해 CloudWatch Logs의 로그 그룹에 감사 로그 데이터를 게시하도록 Neptune DB 클러스터를 구성할 수 있습니다. CloudWatch Logs로 로그 데이터에 대한 실시간 분석을 수행하고 CloudWatch를 사용하여 경보를 생성하고 지표를 보고 CloudWatch Logs를 사용하여 로그 레코드를 내구성이 높은 스토리지에 저장할 수 있습니다. 자세한 내용은 [Amazon CloudWatch Logs에 Neptune Logs 게시](https://docs.aws.amazon.com/neptune/latest/userguide/cloudwatch-logs.html)를 참조하세요.
+ Neptune은 AWS CloudTrail을 사용하여 컨트롤 플레인 작업의 로깅을 지원합니다. 자세한 내용은 [를 사용하여 Amazon Neptune API 호출 로깅을 참조하세요 AWS CloudTrail](https://docs.aws.amazon.com/neptune/latest/userguide/cloudtrail.html).