Amazon ElastiCache Well-Architected Lens Operational Excellence 기둥 - Amazon ElastiCache
OE 1: ElastiCache 클러스터에 의해 트리거되는 알림 및 이벤트에 대해 어떻게 이해하고 대응합니까?OE 2: 기존 ElastiCache 클러스터를 언제 어떻게 확장하나요?OE 3: ElastiCache 클러스터 리소스를 관리하고 클러스터를 유지 관리하려면 어떻게 해야 하나요 up-to-date?OE 4: ElastiCache 클러스터에 대한 클라이언트 연결을 어떻게 관리하나요?OE 5: 워크로드의 ElastiCache 구성 요소를 배포하려면 어떻게 해야 하나요?OE 6: 장애를 어떻게 대비하고 완화할 계획인가요?OE 7: Valkey 또는 Redis OSS 엔진 이벤트 문제를 어떻게 해결하나요?

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

Amazon ElastiCache Well-Architected Lens Operational Excellence 기둥

운영 우수성 요소는 비즈니스 가치를 제공하고 프로세스 및 절차를 지속적으로 개선하기 위한 시스템 운영 및 모니터링에 중점을 둡니다. 주요 주제에는 변경 자동화, 이벤트 대응, 일상 운영 관리를 위한 표준 정의 등이 포함됩니다.

OE 1: ElastiCache 클러스터에 의해 트리거되는 알림 및 이벤트에 대해 어떻게 이해하고 대응합니까?

질문 수준 소개: ElastiCache 클러스터를 작동할 때 특정 이벤트가 발생할 때 선택적으로 알림 및 알림을 받을 수 있습니다. ElastiCache기본적으로 는 장애 조치, 노드 교체, 조정 작업, 예약된 유지 관리 등과 같이 리소스와 관련된 이벤트를 기록합니다. 각 이벤트에는 날짜 및 시간, 소스 이름 및 소스 유형, 설명이 포함됩니다.

질문 수준의 이점: 클러스터에서 생성되는 경고를 트리거하는 이벤트의 근본 원인을 이해하고 관리할 수 있다면 더 효과적으로 운영하고 이벤트에 적절하게 대응할 수 있습니다.

  • [필수] ElastiCache 콘솔ElastiCache 에서( 리전 선택 후) 또는 Amazon Command Line Interface(AWS CLI) describe-events 명령 및 를 사용하여 에서 생성된 이벤트를 검토합니다ElastiCache API. Amazon Simple Notification Service(Amazon )를 사용하여 중요한 클러스터 이벤트에 대한 알림을 보내 ElastiCache 도록 를 구성합니다SNS. 클러스터와 SNS 함께 Amazon을 사용하면 ElastiCache 이벤트에 대해 프로그래밍 방식으로 조치를 취할 수 있습니다.

    • 이벤트에는 크게 현재 이벤트와 예정된 이벤트라는 두 가지 범주가 있습니다. 현재 이벤트 목록에는 리소스 생성 및 삭제, 조정 작업, 장애 조치, 노드 재부팅, 생성된 스냅샷, 클러스터의 파라미터 수정, CA 인증서 갱신, 장애 이벤트(클러스터 프로비저닝 실패 - VPC 또는 ENI-, 조정 실패 - 및 ENI스냅샷 실패)가 포함됩니다. 예정된 이벤트 목록에는 유지 관리 기간 동안 교체가 예정된 노드 및 교체 일정이 변경된 노드가 포함됩니다.

    • 이러한 이벤트 중 일부에 즉시 대응할 필요는 없지만 먼저 모든 장애 이벤트를 살펴보는 것이 중요합니다.

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

      • ElastiCache:SnapshotFailed (발키 또는 RedisOSS만 해당)

    • [리소스]:

  • [최고] 이벤트에 대한 응답을 자동화하려면 SNS 및 Lambda Functions와 같은 AWS 제품 및 서비스 기능을 활용합니다. 모범 사례에 따라 작고 빈번하며 되돌릴 수 있는 변경을 코드로 적용하여 시간이 지남에 따라 운영을 발전시킵니다. Amazon CloudWatch 지표를 사용하여 클러스터를 모니터링해야 합니다.

    [리소스]: AWS Lambda 및 를 사용하는 사용 사례에 대해 Lambda, Amazon Route 53 및 Amazon을 사용하여 ElastiCache (Redis OSS)(클러스터 모드 비활성화됨) 읽기 전용 복제본 엔드포인트를 모니터링합니다SNSSNS.

OE 2: 기존 ElastiCache 클러스터를 언제 어떻게 확장하나요?

질문 수준 소개: ElastiCache 클러스터의 크기를 올바르게 조정하는 것은 기본 워크로드 유형이 변경될 때마다 평가해야 하는 밸런싱 작업입니다. 목표는 워크로드에 적합한 규모의 환경에서 운영하는 것입니다.

질문 수준의 이점: 리소스를 과도하게 사용하면 지연 시간이 늘어나고 전반적인 성능이 저하될 수 있습니다. 반면, 활용도가 낮으면 최적화되지 않은 비용으로 리소스를 과도하게 프로비저닝하게 될 수 있습니다. 환경을 적절한 규모로 조정하면 성능 효율성과 비용 최적화 간의 균형을 맞출 수 있습니다. 리소스 사용률 초과 또는 미달을 해결하려면 를 두 가지 차원으로 확장 ElastiCache 할 수 있습니다. 노드 용량을 늘리거나 줄여서 수직으로 규모를 조정할 수 있습니다. 노드를 추가 및 제거하여 수평적으로 규모를 조정할 수도 있습니다.

OE 3: ElastiCache 클러스터 리소스를 관리하고 클러스터를 유지 관리하려면 어떻게 해야 하나요 up-to-date?

질문 수준 소개: 대규모로 운영할 때는 모든 리소스를 정확히 찾아 식별할 수 있어야 합니다 ElastiCache. 새 애플리케이션 기능을 롤아웃할 때는 개발, 테스트, 프로덕션 등 모든 ElastiCache 환경 유형에 클러스터 버전 대칭을 생성해야 합니다. 리소스 속성을 사용하면 새 기능을 배포하거나 새 보안 메커니즘을 활성화하는 등 다양한 운영 목표에 맞게 환경을 분리할 수 있습니다.

질문 수준의 이점: 개발, 테스트 및 프로덕션 환경을 분리하는 것이 운영 모범 사례입니다. 또한 잘 이해되고 문서화된 프로세스를 사용하여 환경 전반의 클러스터와 노드에 최신 소프트웨어 패치를 적용하는 것이 가장 좋습니다. 기본 ElastiCache 기능을 활용하면 엔지니어링 팀이 ElastiCache 유지 관리가 아닌 비즈니스 목표 달성에 집중할 수 있습니다.

  • [최고] 사용 가능한 최신 엔진 버전에서 를 실행하고 셀프 서비스 업데이트가 사용 가능하게 되는 즉시 적용합니다. 클러스터의 지정된 유지 관리 기간 동안 기본 인프라를 ElastiCache 자동으로 업데이트합니다. 하지만 클러스터에서 실행 중인 노드는 셀프 서비스 업데이트를 통해 업데이트됩니다. 이러한 업데이트에는 보안 패치 또는 소프트웨어 소규모 업데이트의 두 가지 유형이 있습니다. 패치 유형과 적용 시기의 차이를 이해해야 합니다.

    [리소스]:

  • [Best] 태그를 사용하여 ElastiCache 리소스를 구성합니다. 개별 노드가 아닌 복제 그룹에 태그를 사용합니다. 리소스를 쿼리할 때 표시되도록 태그를 구성하고 태그를 사용하여 검색을 수행하고 필터를 적용할 수 있습니다. 일반적인 태그 세트를 공유하는 리소스 모음을 쉽게 만들고 유지 관리하려면 리소스 그룹을 만들어야 합니다.

    [리소스]:

OE 4: ElastiCache 클러스터에 대한 클라이언트 연결을 어떻게 관리하나요?

질문 수준 소개: 대규모로 운영할 때는 클라이언트가 ElastiCache 클러스터와 연결되어 애플리케이션 운영 측면(예: 응답 시간)을 관리하는 방법을 이해해야 합니다.

질문 수준의 이점: 가장 적절한 연결 메커니즘을 선택하면 시간 초과와 같은 연결 오류로 인해 애플리케이션 연결이 끊기지 않습니다.

  • [필수] 읽기와 쓰기 작업을 분리하고 복제본 노드에 연결하여 읽기 작업을 실행합니다. 하지만 쓰기와 읽기를 분리하면 Valkey 및 Redis OSS 복제의 비동기적 특성으로 인해 쓰기 직후 키를 읽을 수 없게 됩니다. WAIT 명령을 활용하여 실제 데이터 안전을 개선하고 전체 성능 비용으로 클라이언트에 응답하기 전에 복제본이 쓰기를 승인하도록 할 수 있습니다. 읽기 작업에 복제본 노드를 사용하는 것은 클러스터 모드 비활성화에 대한 ElastiCache 리더 엔드포인트를 사용하여 ElastiCache (Redis OSS) 클라이언트 라이브러리에서 구성할 수 있습니다. 클러스터 모드가 활성화된 경우 ElastiCache (Redis OSS) READONLY 명령을 사용합니다. 많은 ElastiCache (Redis OSS) 클라이언트 라이브러리의 경우 ElastiCache (Redis OSS)READONLY가 기본적으로 또는 구성 설정을 통해 구현됩니다.

    [리소스]:

  • [필수] 연결 풀링을 사용합니다. TCP 연결을 설정하면 클라이언트와 서버 측 모두에서 CPU 시간이 많이 걸리고 풀링을 통해 TCP 연결을 재사용할 수 있습니다.

    연결 오버헤드를 줄이려면 연결 풀링을 사용해야 합니다. 연결 풀을 사용하면 애플리케이션에서 연결 설정 비용 없이 '마음대로' 연결을 재사용하고 연결을 해제할 수 있습니다. 애플리케이션 환경에 사용할 수 있는 프레임워크를 사용하여 ElastiCache (Redis OSS) 클라이언트 라이브러리(지원되는 경우)를 통해 연결 풀링을 구현하거나 처음부터 구축할 수 있습니다.

  • [가장 좋음] 클라이언트의 소켓 제한 시간이 최소 1초로 설정되어 있는지 확인합니다. 몇몇 클라이언트의 일반적인 기본값인 '없음'으로 설정되어 있으면 안 됩니다.

    • 제한 시간 값을 너무 낮게 설정하면 서버 로드가 높을 때 시간 초과가 발생할 수 있습니다. 너무 높게 설정하면 애플리케이션에서 연결 문제를 감지하는 데 시간이 오래 걸릴 수 있습니다.

    • 클라이언트 애플리케이션에서 연결 풀링을 구현하여 새 연결의 볼륨을 제어합니다. 이렇게 하면 연결을 열고 닫는 데 필요한 지연 시간과 CPU 사용률이 줄어들고 가 클러스터에서 활성화된 경우 TLS 핸드셰TLS이크를 수행할 수 있습니다.

    [리소스]: 고가용성을 위한 구성 ElastiCache (RedisOSS)

  • [좋음] (사용 사례에서 가능한 경우) 파이프라이닝을 사용하면 성능이 크게 향상될 수 있습니다.

    • 파이프라이닝을 사용하면 애플리케이션 클라이언트와 클러스터 간의 왕복 시간(RTT)을 줄이고 클라이언트가 이전 응답을 아직 읽지 않은 경우에도 새 요청을 처리할 수 있습니다.

    • 파이프라이닝을 사용하면 응답/확인을 기다리지 않고 서버에 여러 명령을 보낼 수 있습니다. 파이프라이닝의 단점은 결국 모든 응답을 대량으로 가져올 때 끝에 가서야 잡을 수 있는 오류가 있을 수 있다는 점입니다.

    • 잘못된 요청을 생략하는 오류가 반환될 때 요청을 재시도하는 메서드를 구현합니다.

    [리소스]: 파이프라이닝

OE 5: 워크로드의 ElastiCache 구성 요소를 배포하려면 어떻게 해야 하나요?

질문 수준 소개: ElastiCache 환경은 AWS 콘솔을 통해 수동으로 배포하거나 , APIs, CLI툴킷 등을 통해 프로그래밍 방식으로 배포할 수 있습니다. 운영 우수성 모범 사례에서는 가능하면 코드를 통해 배포를 자동화하는 것을 권장합니다. 또한 ElastiCache 클러스터는 워크로드별로 격리하거나 비용 최적화를 위해 결합할 수 있습니다.

질문 수준의 이점: ElastiCache 환경에 가장 적합한 배포 메커니즘을 선택하면 시간이 지남에 따라 운영 우수성을 개선할 수 있습니다. 인적 오류를 최소화하고 반복성, 유연성 및 이벤트에 대한 응답 시간을 향상하기 위해서는 가능하면 코드로 작업을 수행하는 것이 좋습니다.

워크로드 격리 요구 사항을 이해하면 워크로드당 전용 ElastiCache 환경을 보유하거나 여러 워크로드를 단일 클러스터 또는 그 조합으로 결합하도록 선택할 수 있습니다. 장단점을 이해하면 운영 우수성과 비용 최적화 간의 균형을 맞추는 데 도움이 될 수 있습니다.

  • [필수] 에서 사용할 수 있는 배포 옵션을 이해하고 가능하면 이러한 절차를 ElastiCache자동화합니다. 가능한 자동화 방법에는 CloudFormation, AWS CLI/SDK, 및 가 포함됩니다APIs.

    [리소스]:

  • [필수] 모든 워크로드에 대해 필요한 클러스터 격리 수준을 결정합니다.

    • [가장 좋음]: 높은 수준의 격리 - 워크로드와 클러스터를 1:1로 매핑합니다. 워크로드별로 ElastiCache 리소스의 액세스, 크기 조정, 크기 조정 및 관리를 완벽하게 제어할 수 있습니다.

    • [더 좋음]: 중간 수준의 격리 - 목적별로 M:1로 격리하지만 여러 워크로드 간에 공유될 수 있습니다(예: 워크로드 캐싱 전용 클러스터와 메시징 전용 클러스터).

    • [좋음]: 낮은 수준의 격리 - M:1 격리로 다용도로 사용하며 완전히 공유합니다. 공유 액세스가 허용되는 워크로드에 권장됩니다.

OE 6: 장애를 어떻게 대비하고 완화할 계획인가요?

질문 수준 소개: 운영 우수성에는 테스트 목적으로 잠재적 장애 원인을 제거하거나 완화할 수 있도록 정기적인 '사전' 연습을 수행하여 장애를 예측API하는 것이 포함됩니다. 는 시뮬레이션된 노드 장애 이벤트를 허용하는 장애 조치를 ElastiCache 제공합니다.

질문 수준의 이점: 장애 시나리오를 미리 테스트하면 장애 시나리오가 워크로드에 미치는 영향을 파악할 수 있습니다. 이를 통해 대응 절차와 그 효과를 안전하게 테스트할 수 있을 뿐만 아니라 팀이 대응 절차 실행에 익숙해질 수 있습니다.

[필수] 개발/테스트 계정에서 장애 조치 테스트를 정기적으로 수행합니다. TestFailover

OE 7: Valkey 또는 Redis OSS 엔진 이벤트 문제를 어떻게 해결하나요?

질문 수준 소개: Operational Excellence를 사용하려면 서비스 수준 및 엔진 수준 정보를 모두 조사하여 클러스터의 상태와 상태를 분석하는 기능이 필요합니다. ElastiCache 는 Amazon CloudWatch 및 Amazon Kinesis Data Firehose 모두에 Valkey 또는 Redis OSS 엔진 로그를 내보낼 수 있습니다.

질문 수준 이점: ElastiCache 클러스터에서 Valkey 또는 Redis OSS 엔진 로그를 활성화하면 클러스터의 상태와 성능에 영향을 미치는 이벤트에 대한 인사이트를 얻을 수 있습니다. Valkey 또는 Redis OSS 엔진 로그는 ElastiCache 이벤트 메커니즘을 통해 사용할 수 없는 데이터를 엔진에서 직접 제공합니다. ElastiCache 이벤트(이전 OE-1 참조)와 엔진 로그를 모두 주의 깊게 관찰하여 ElastiCache 서비스 관점과 엔진 관점에서 문제를 해결할 때 이벤트 순서를 결정할 수 있습니다.

  • [필수] ElastiCache (Redis OSS) 6.2 이상부터 사용할 수 있는 Redis OSS 엔진 로깅 기능이 활성화되어 있는지 확인합니다. 클러스터 생성 중에 또는 생성 후 클러스터를 수정하여 이 작업을 수행할 수 있습니다.

    • Amazon CloudWatch Logs 또는 Amazon Kinesis Data Firehose가 Redis OSS 엔진 로그의 적절한 대상인지 확인합니다.

    • CloudWatch 또는 Kinesis Data Firehose 내에서 적절한 대상 로그를 선택하여 로그를 유지합니다. 클러스터가 여러 개 있는 경우, 문제 해결 시 데이터를 분리하는 데 도움이 되므로 클러스터마다 다른 대상 로그를 사용하는 것이 좋습니다.

    [리소스]:

  • [최고] Amazon CloudWatch Logs를 사용하는 경우 Amazon CloudWatch Logs Insights를 활용하여 중요한 정보를 위해 Valkey 또는 Redis OSS 엔진 로그를 쿼리하는 것이 좋습니다.

    예를 들어 다음과 같이 가 LogLevel 'WARNING'인 이벤트를 반환하는 Valkey 또는 Redis OSS 엔진 로그가 포함된 CloudWatch 로그 그룹에 대한 쿼리를 생성합니다.

    fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"

    [리소스]: CloudWatch Logs Insights를 사용한 로그 데이터 분석