안정성

이 아키텍처 프레임워크 섹션에서는 Google Cloud에서 안정적인 서비스를 설계하고 운영하기 위해 기술 및 절차 요구사항을 적용하는 방법을 설명합니다.

전체 프레임워크는 다음 문서 시리즈로 구성됩니다.

안정성은 모든 애플리케이션에서 가장 중요한 기능입니다. 애플리케이션을 신뢰할 수 없으면 다른 기능에 관계없이 사용자는 결국 애플리케이션을 더 이상 사용하지 않게 되기 때문입니다.

  • 애플리케이션에는 측정 가능한 안정성 목표가 있어야 하고 편차는 즉시 수정되어야 합니다.
  • 애플리케이션의 아키텍처는 확장성, 고가용성, 자동 변경 관리를 고려하여 구성되어야 합니다.
  • 애플리케이션은 가능한 경우 자가 복구되어야 하고 관측 가능성을 계측할 수 있어야 합니다.
  • 애플리케이션을 실행하는 데 사용되는 운영 절차는 최소한의 수작업과 연산자의 인지 부하를 적용하는 동시에 장애의 영향을 신속하게 완화해야 합니다.

전략

다음과 같은 전략을 통해 안정성을 달성하세요.

안정성은 사용자가 정의합니다. 사용자 대상 워크로드의 경우 CPU 사용량과 같은 서버 측정항목이 아닌 쿼리 성공률과 같은 사용자 경험을 측정합니다. 일괄 워크로드 및 스트리밍 워크로드의 경우 디스크 사용량과 같은 서버 측정항목보다는, 분기별 보고서가 제 시간에 완료되는지 확인하기 위해 기간별로 검사되는 행 수와 같은 KPI(핵심성과지표)를 측정해야 할 수 있습니다.

충분한 안정성을 갖춰야 합니다. 시스템의 안정성은 사용자가 만족할 만한 수준이어야 하고 투자가 정당화되지 않을 만큼 과도한 수준은 아니어야 합니다. 안정성 기준을 설정하는 서비스 수준 목표(SLO)를 정의하고 오류 예산을 사용하여 변경 속도를 관리합니다. SLO가 비용의 근거를 제공하는 경우에만 아래에 나와 있는 추가 원칙을 적용합니다.

중복 단계를 만듭니다. 안정성이 높은 시스템에는 단일 장애점이 없어야 하며 리소스는 여러 장애 도메인에 걸쳐 복제되어야 합니다. 장애 도메인은 VM, 영역 또는 리전과 같이 독립적으로 실패할 수 있는 리소스 풀입니다.

수평 확장성을 제공합니다. 리소스를 추가하여 시스템의 모든 구성요소가 트래픽 증가 또는 데이터 성장을 수용할 수 있는지 확인합니다.

과부하 허용 범위를 보장합니다. 부하가 걸렸을 때 성능이 단계적으로 저하되도록 서비스를 설계합니다.

롤백 기능을 제공합니다. 작업자가 서비스를 변경하면 변경사항을 실행취소하는 방법 즉, 변경사항을 롤백하는 방법이 잘 정의되어 있어야 합니다.

트래픽 급증을 방지합니다. 클라이언트 간 요청을 동기화하지 마세요. 동시에 트래픽을 보내는 클라이언트가 너무 많으면 트래픽이 급증하여 최악의 경우 연쇄적 장애가 발생할 수 있습니다.

장애 복구를 테스트합니다. 최근 장애 복구를 위한 운영 절차를 테스트하지 않았다면 필요할 때 절차가 제대로 작동하지 않을 수 있습니다. 주기적으로 테스트할 항목에는 리전별 장애 조치, 출시 롤백, 백업에서 데이터 복구가 포함됩니다.

장애를 감지합니다. 너무 빨리 알림을 보내느라 운영팀을 혹사시키는 것과 너무 늦게 알림을 보내 서비스 중단 기간이 길어지는 것 사이에는 상충 관계가 있습니다. 작업자에게 서비스 중단을 알리기 전의 지연 시간(TTD, 감지 시간이라고도 함)은 이 상충 관계에 맞게 조정되어야 합니다.

단계적으로 변경합니다. 서비스 바이너리 또는 구성을 즉각적이고 전체적으로 변경하는 것은 본질적으로 위험합니다. 따라서 사용자에게 미치는 영향을 최소화할 수 있는 출시 초기 단계에 버그를 감지하는 '카나리아 테스트'를 수행하여 변경사항을 단계적으로 출시하는 것이 좋습니다.

조정된 비상 대응 절차를 갖춰야 합니다. 고객 환경과 운영자의 건강과 행복을 고려하면서 서비스 중단 기간(TTM, 완화 기간이라고도 함)을 최소화하도록 운영 권장사항을 설계합니다. 이 접근법을 사용하려면 잘 정의된 역할과 커뮤니케이션 채널을 통해 사전에 대응 절차를 공식화해야 합니다.

관측용 시스템을 운용합니다. TTM을 최소화하기 위해 문제를 신속하게 분류, 해결, 진단할 수 있도록 시스템을 충분히 잘 운용해야 합니다.

응급상황 대응을 문서화 및 자동화합니다. 응급상황에서 사람들은 해야 할 일을 정의하고 복잡한 작업을 수행하는 데 어려움을 겪습니다. 따라서 응급상황 조치를 미리 계획하여 문서화하고, 이상적으로는 이를 자동화합니다.

용량 관리를 수행합니다. 최대 트래픽 이벤트가 발생하기 전에 트래픽을 예측하고 리소스를 프로비저닝합니다.

수작업을 최소화합니다. 반복적인 수작업은 지속적인 가치가 없지만 서비스가 성장함에 따라 증가합니다. 따라서 이 수작업을 지속적으로 줄이거나 최소화하기 위해 노력해야 합니다. 그렇지 않으면 운영 작업만으로 작업자가 완전히 지치게 되므로 성장에 투자할 시간이 거의 남지 않습니다.

권장사항

다음 권장사항에 따라 안정성을 달성하세요.

  • 서비스 수준 목표(SLO) 및 오류 예산을 사용하여 안정성 목표 정의
  • 인프라 및 애플리케이션에 관측 가능성 빌드
  • 확장성 및 고가용성을 고려한 설계
  • 유연하고 자동화된 배포 기능 빌드
  • 효율적인 알림 빌드
  • 이슈 관리를 위한 공동작업 프로세스 빌드

안정성 목표 정의

기존 고객 경험과 오류 및 실수에 대한 허용 범위를 측정하는 동시에 이러한 이벤트를 기반으로 안정성 목표를 설정하는 것이 좋습니다. 예를 들어 사용자가 기대하는 데이터가 없으면 기간 제한 없이 전체 시스템 업타임 목표 100%를 달성할 수 없으므로 의미가 없습니다.

사용자 환경에 따라 SLO를 설정합니다. 사용자와 최대한 가까운 곳에서 안정성 측정항목을 측정합니다. 가능하다면 모바일 또는 웹 클라이언트를 계측합니다. 그럴 수 없다면 부하 분산기를 계측합니다. 마지막 수단으로 서버의 안정성을 측정합니다. SLO는 사용자가 만족할 만한 수준으로 높게 설정합니다.

네트워크 연결 또는 기타 일시적인 클라이언트 측 문제로 인해 고객은 애플리케이션으로 인해 발생하는 일부 안정성 문제를 짧은 기간 동안 인식하지 못할 수 있습니다.

업타임 및 기타 중요한 측정항목의 경우 목표를 100% 미만이되 100%에 가깝게 설정하는 것이 좋습니다. 이 목표를 사용하면 누구나 고품질의 소프트웨어를 더 빠르게 제공할 수 있습니다. 또한 대부분의 경우 적절하게 설계된 시스템을 사용하면 변경 속도와 변경 볼륨을 줄여 가용성을 높일 수 있습니다.

즉, 고객 경험에 맞게 조정된 달성 가능한 안정성 목표는 고객이 허용할 수 있는 최대 속도 및 변경 범위(즉, 신기능 개발 속도)를 정의하는 데 도움이 됩니다.

기존 고객 경험을 측정하고 측정 결과에 따라 목표를 정의할 수 없는 경우 경쟁력 있는 벤치마크 분석을 수행하는 것이 좋습니다. 비교할 만한 경쟁사가 없는 경우, 시스템 가용성 또는 고객에게 유의미한 트랜잭션 성공률과 같은 목표를 아직 정의할 수 없는 경우에도 고객 환경을 측정합니다. 이러한 고객 환경과 주문량(소매), 고객지원 통화 및 티켓, 심각도 등과 같은 비즈니스 측정항목(또는 KPI)의 상관관계를 파악할 수 있습니다. 정해진 일정 기간 동안 이러한 상관관계 연습을 수행하여 고객 행복의 합리적인 기준 즉, SLO에 도달할 수 있습니다.

SLI, SLO, SLA

서비스 수준 지표(SLI)는 제공되는 서비스 수준의 일부 측면을 계량적으로 측정하는 기준으로, 목표가 아닌 측정항목입니다.

서비스 수준 목표(SLO)는 서비스의 안정성을 위한 목표 수준을 지정합니다. SLO는 안정성에 대한 데이터 기반 결정을 내리는 데 중요한 역할을 하므로 SRE 권장사항의 핵심입니다. SLO는 SLI의 값이며, SLI가 이 값 이상일 경우 '신뢰할 수 있는' 서비스로 간주합니다.

오류 예산은 일정 기간 동안의 (100% – SLO)로 계산되며, 특정 기간 동안 시스템의 안정성이 필요 이상인지 이하인지 여부를 알려줍니다. 일반적으로 30일의 롤링 기간을 사용하는 것이 좋습니다.

서비스수준계약(SLA)은 사용자와의 명시적 또는 암시적 계약으로, 포함된 SLO를 충족하거나 충족하지 못한 결과가 포함됩니다.

외부 SLA보다 엄격한 내부 SLO를 사용하는 것이 좋습니다. 이 접근법의 근거는 SLA 위반 시 재무 크레딧 또는 고객 환불을 요구하는 경우가 많으며, 문제 발생 시 재무에 영향을 미치기 전에 해당 문제를 해결하고자 한다는 데 있습니다. 비난 없이 이슈를 검토하는 사후 분석 프로세스에 보다 엄격한 내부 SLO를 연결하는 것이 좋습니다.

애플리케이션에 여러 독립적인 고객이 사용하는 전형적인 SaaS 애플리케이션인 멀티 테넌트 아키텍처가 있으면 테넌트 수준에서 SLI를 캡처해야 합니다. 전역 규모의 집계 수준에서만 SLI를 측정하면 모니터링 시 개별 고객 또는 소수의 고객에게 영향을 미치는 중요한 문제를 신고할 수 없습니다. 각 사용자 요청에 테넌트 식별자를 포함하도록 애플리케이션을 설계하고 스택의 각 레이어를 통해 해당 식별자를 전파합니다. 이 식별자를 전파하면 모니터링 시스템에서 요청 경로를 따라 모든 레이어 또는 마이크로서비스의 테넌트 수준에서 통계를 집계할 수 있습니다.

오류 예산

오류 예산을 사용하여 개발 속도를 관리할 수 있습니다. 오류 예산이 아직 사용되지 않은 경우 계속해서 신기능 출시 속도를 높일 수 있습니다. 오류 예산이 거의 소진된 경우에는 서비스 변경을 중단하거나 속도를 늦추고 안정성 기능에 엔지니어링 리소스를 투입합니다.

Google Cloud는 서비스 모니터링을 통해 SLO 및 오류 예산을 설정하는 데 필요한 노력을 최소화합니다. 이 제품은 SLO를 수동으로 구성하기 위한 UI, 프로그래매틱 방식으로 SLO를 설정하기 위한 API, 오류 예산의 소진율을 추적하기 위한 내장 대시보드를 제공합니다.

SLI 예시

제공 시스템의 경우 일반적인 SLI는 다음과 같습니다.

  • 가용성은 서비스를 사용할 수 있는 시간의 비율을 나타냅니다. 가용성은 보통 올바르게 구성된 요청 중 성공한 요청의 비율(예: 99%)로 정의됩니다.
  • 지연 시간은 특정 비율의 요청이 처리되는 속도를 나타냅니다. 지연 시간은 보통 50번째 백분위수가 아닌 백분위수로 정의됩니다(예: 300ms에서 99번째 백분위 수).
  • 품질은 특정 응답이 얼마나 양호한지 나타냅니다. 품질은 보통 서비스별로 정의되며, 요청에 대한 응답 콘텐츠와 이상적인 응답 콘텐츠 간의 차이 정도를 나타냅니다. 품질 측정 결과는 양호 또는 불량이거나 0~100% 범위의 비율로 표현할 수 있습니다.

데이터 처리 시스템의 경우 일반적인 SLI는 다음과 같습니다.

  • 노출 범위는 처리된 데이터의 비율을 나타냅니다(예: 99.9%).
  • 정확성은 정답으로 간주되는 응답의 비율을 나타냅니다(예: 99.99%).
  • 최신성은 소스 데이터와 집계된 응답이 얼마나 최신인지 나타내며, 집계하는 빈도가 높을수록 결과 값이 향상됩니다(예: 20분).
  • 처리량은 처리 중인 데이터의 양을 나타냅니다(예: 500MiB/초 또는 1,000RPS).

스토리지 시스템의 경우 일반적인 SLI는 다음과 같습니다.

  • 내구성은 시스템에 기록된 데이터가 나중에 검색되는 가능성을 나타냅니다(예: 99.9999%). 영구적인 데이터 손실 이슈는 내구성 측정항목을 줄입니다.
  • 처리량 및 지연 시간(앞의 설명 참조)

설계 관련 질문

  • 애플리케이션의 안정성에 대한 사용자 경험을 측정하고 있나요?
  • 클라이언트 애플리케이션이 안정성 측정항목을 캡처하고 보고하도록 설계되었나요?
  • 시스템 아키텍처가 구체적인 안정성과 확장성 목표를 염두에 두고 설계되었나요?
  • 멀티 테넌트 시스템의 경우 사용자 요청에 테넌트 식별자가 포함되어 있나요? 또한 이 식별자가 소프트웨어 스택의 각 레이어를 통해 전파되나요?

권장사항

  • 고객 중심의 SLI를 정의하고 측정합니다.
  • 위반 시 결과(예: 프로덕션 중단)를 고려하여 외부 SLA보다 엄격한 고객 중심 오류 예산을 정의합니다.
  • 지연 시간 SLI를 설정하여 가장 느린 응답을 감지하기 위한 이상점 값(즉, 90번째 또는 99번째 백분위수)을 캡처합니다.
  • 1년에 1회 이상 SLO를 검토합니다.

리소스

인프라 및 애플리케이션에 관측 가능성 빌드

관측 가능성에는 모니터링, 로깅, 추적, 프로파일링, 디버깅, 기타 유사한 시스템이 포함됩니다.

코드를 사용하면 관측 가능성을 극대화할 수 있습니다. 로그 항목과 trace 항목을 작성하고, 디버깅 및 문제 해결을 염두에 두고 가능성이 가장 높거나 빈번하게 발생하는 시스템의 장애 모드에 따라 우선순위를 지정하여 모니터링 측정항목을 내보냅니다. 주기적으로 모니터링을 감사하고 프루닝하여 사용되지 않거나 무효한 대시보드, 알림, 추적, 로깅을 삭제하여 깔끔하게 정리합니다.

모니터링은 서비스 안정성 계층 구조의 기저를 이룹니다. 적절한 모니터링 없이는 애플리케이션이 제대로 작동하는지 초기에 알 수 없습니다.

잘 설계된 시스템은 개발 단계에서부터 적절한 수준의 관측 가능성을 제공하는 것을 목표로 합니다. 애플리케이션이 프로덕션 단계에 올 때까지 기다리지 말고 바로 관측을 시작하세요.

Google Cloud의 작업 제품군은 실시간 모니터링, 로깅(Google Cloud 및 AWS), 추적, 프로파일링, 디버깅을 제공합니다. 또한 Istio 및 App Engine 서비스(Cloud Monitoring)를 사용하여 서비스 메시를 모니터링할 수 있습니다.

과도한 엔지니어링 모니터링 및 과다 알림은 일반적으로 피해야 할 패턴입니다. 이러한 안티패턴은 초기의 외부 출시 단계 중 살펴보거나 실행하지 않는 시계열, 대시보드, 알림을 사전에 삭제하여 피해야 합니다. 이는 검사하는 경우가 드문 로그 항목에서도 유효합니다.

BigQuery와 같은 클라우드 데이터 웨어하우스로의 애플리케이션 이벤트 전체 또는 샘플 전송을 평가합니다. 이 방법은 바로 모니터링하도록 설계하는 것보다 저렴한 비용으로 임의 쿼리를 실행할 수 있기 때문에 유용합니다. 또한 모니터링에서 보고를 분리합니다. Google 데이터 스튜디오 또는 Looker를 사용하는 사람이면 누구나 보고를 수행할 수 있습니다.

설계 관련 질문

  • 설계 검토 프로세스에 설계 검토와 코드 검토를 안내하는 관측 가능성 관련 표준이 있나요?
  • 애플리케이션에서 내보낸 측정항목이 서비스 중단 문제를 해결하는 데 적합한가요?
  • 애플리케이션 로그 항목이 디버깅에 유용할 만큼 상세하고 관련성이 있나요?

권장사항

  • 마이그레이션을 시작하기 전에 또는 초기 프로덕션 배포 전 새 애플리케이션을 빌드하는 동안 사전에 모니터링을 구현합니다.
  • 애플리케이션 문제와 기본 클라우드 문제 간을 명확하게 구분합니다(예 : 투명성 SLI 및 Google Cloud 상태 대시보드 사용).
  • 프로파일링 외에도 추적, 프로파일링, 디버깅을 포함한 관측 가능성 전략을 정의합니다.
  • 실행되지 않는 알림을 포함하여 사용되지 않거나 유용하지 않은 관측 가능성 아티팩트를 정기적으로 삭제합니다.
  • BigQuery와 같은 데이터 웨어하우스 시스템에 애플리케이션 이벤트(즉, 카디널리티가 높은 측정항목)를 전송합니다.

확장성 및 고가용성 설계

장애 조치가 포함된 멀티 리전 아키텍처 설계

전체 리전이 작동 중지될 때도 서비스가 가동되어야 하는 경우에는 리전의 작동이 중지될 때 자동 장애 조치를 사용하여 여러 리전에 분산된 컴퓨팅 리소스 풀을 사용하도록 설계합니다. 연결할 수 없을 때 전역 서비스 중단을 초래할 수 있는 단일 리전 마스터 데이터베이스와 같은 단일 장애점을 제거합니다.

확장성 병목 현상 제거

단일 VM 또는 단일 영역의 리소스 한도를 초과해서는 안 되는 시스템 구성요소를 식별합니다. 일부 애플리케이션은 수직 확장에 맞게 설계되어 있으므로, 단일 VM에서 부하 증가를 처리하려면 더 많은 CPU 코어, 메모리 또는 네트워크 대역폭이 필요합니다. 이러한 애플리케이션은 확장성에 엄격한 제한을 적용하며 확장을 처리하기 위해 수동으로 재구성해야 하는 경우가 많습니다. 이러한 구성요소를 샤딩(VM 또는 영역 간에 파티션 나누기)을 사용하여 수평 확장이 가능하도록 재설계합니다. 그러면 샤드를 추가하여 트래픽 또는 사용량 증가를 쉽게 처리할 수 있습니다. 여기서 샤드는 표준 VM 유형을 사용하며 샤드당 부하의 증가를 처리하도록 자동으로 추가될 수 있습니다. 재설계의 대안으로, 이러한 구성요소 대신 사용자 작업 없이 수평으로 확장되도록 설계된 관리형 서비스를 사용해 보세요.

단계적으로 서비스 수준 저하

과부하 감지 시 사용자에게 낮은 품질의 응답을 반환하거나 과부하로 인해 완전히 실패하지 않게 트래픽을 부분적으로 삭제하도록 서비스를 설계합니다. 예를 들어 서비스는 비용이 많이 드는 동적 동작을 일시적으로 사용 중지하는 동시에 정적 웹 페이지를 통해 사용자 요청에 응답하거나, 데이터 업데이트를 일시적으로 사용 중지하고 읽기 전용 작업을 허용할 수 있습니다.

지터로 지수 백오프 구현

모바일 클라이언트가 서비스에서 오류 응답을 받은 경우 임의의 지연 후에 다시 시도해야 합니다. 작업을 재시도할 때마다 임의의 시차(지터)를 추가하는 것 외에, 오류가 반복될 경우 재시도 전에 대기 시간이 기하급수적으로 증가합니다. 이렇게 하면 셀룰러 네트워크 장애 후 대규모 클라이언트 그룹에서 갑작스럽게 트래픽이 급증하는 것을 방지할 수 있습니다. 이러한 급증으로 서버에 장애가 발생할 수 있습니다.

최대 트래픽 이벤트 예측 및 계획

시스템에서 블랙 프라이데이와 같이 소매업체의 최대 트래픽이 발생하는 기간을 경험한 경우 트래픽과 매출의 막대한 손실을 방지하기 위해 이러한 이벤트를 준비하는 데 시간을 투자합니다. 최대 트래픽 규모를 예측하여 버퍼를 추가하고 시스템에 트래픽 급증을 처리할 만큼 충분한 컴퓨팅 용량이 있는지 확인합니다. 예상 부하 처리 용량이 실제 용량과 일치하는지 확인하기 위해 사용자 요청이 혼합되어 있는 시스템에서 부하 테스트를 실시합니다. 운영팀이 서비스 중단 훈련을 시뮬레이션하고, 대응 절차를 반복 연습하며, 아래에 설명된 팀 간 이슈 관리 공동작업 절차를 수행하는 연습을 실행합니다.

재해 복구 테스트 수행

재해가 발생할 때까지 기다리지 말고 재해 복구 절차와 프로세스를 주기적으로 테스트하고 확인하세요. 고가용성(HA)에 대한 아키텍처를 계획하고 있을 수도 있습니다. 재해 복구(DR)와 완전히 겹치는 것을 아니지만 복구 시간 목표(RTO) 및 복구 지점 목표(RPO) 값을 고려할 때 HA를 고려해야 하는 경우가 많습니다. HA는 일반적인 정상 기간보다 더 높은 수준의 운영 성능(대개 업타임)을 보장하도록 지원합니다. Google Cloud에서 프로덕션 워크로드를 실행할 때 전역으로 분산된 시스템을 사용하여 한 리전에서 문제가 발생할 경우, 애플리케이션의 가용성이 저하되더라도 계속 서비스를 제공할 수 있습니다. 기본적으로 이 애플리케이션은 DR 계획을 실행합니다.

설계 관련 질문

  • 아키텍처 변경 없이 VM을 추가하여 애플리케이션을 수직 확장할 수 있나요?
  • 아키텍처의 각 구성요소가 샤딩이나 그 밖의 방법으로 수평 확장이 가능한가요?
  • 클라이언트 애플리케이션이 클라이언트 간 요청을 동기화하지 않도록 설계되었나요?
  • 애플리케이션이 전역 서비스 중단 없이 전체 클라우드 리전의 장애를 처리할 수 있나요?
  • 사용자 요청이 샤드와 리전에 걸쳐 균등하게 분산되어 있나요?
  • 애플리케이션이 과부하 시점을 감지하고 서비스 중단을 방지하기 위해 동작을 변경할 수 있나요?

권장사항

  • 클라이언트 애플리케이션의 오류 재시도 로직에서 무작위 순서 지정으로 지수 백오프를 구현합니다.
  • 높은 가용성을 위해 자동 장애 조치가 포함된 멀티 리전 아키텍처를 구현합니다.
  • 부하 분산을 사용하여 샤드와 리전 전체에 사용자 요청을 분산합니다.
  • 과부하 시 완전히 실패하지 않도록 부분 응답을 제공하거나 제한된 기능을 제공하는 등 성능이 단계적으로 저하되도록 애플리케이션을 설계합니다
  • 리소스 프로비저닝을 유도하기 위해 부하 테스트 및 트래픽 예측을 사용하여 반복적인 데이터 기반 용량 계획 프로세스를 설정합니다.
  • 재해 복구 절차를 수립하고 주기적으로 테스트합니다.

유연하고 자동화된 배포 기능 빌드

모든 변경 사항을 롤백 가능한지 확인

특정 유형의 변경사항을 실행 취소할 수 있는 방법이 제대로 정의되지 않은 경우 롤백을 지원하도록 서비스 설계를 변경하고 주기적으로 롤백 프로세스를 테스트합니다. 이 방법은 모바일 애플리케이션에 구현하는 데 비용이 많이 들 수 있으며, 개발자는 기능을 손쉽게 롤백할 수 있도록 Firebase 원격 구성을 적용하는 것이 좋습니다.

예약 프로모션 및 출시를 위한 트래픽 분산

정해진 시간(예: 자정)에 정확히 판매를 시작하고 다수의 사용자가 동시에 서비스에 연결하도록 유도하는 프로모션 이벤트의 경우 요청을 시작하기 전에 무작위 지연을 추가하여 몇 초 동안 트래픽을 분산시킬 수 있도록 클라이언트 코드를 설계합니다. 이렇게 하면 예약된 시작 시간에 서버의 장애를 초래할 수 있는 갑작스러운 트래픽 급증을 방지할 수 있습니다.

카나리아 테스트로 점진적 출시 구현

영역 내 몇 개의 VM과 같이 작은 범위에서 시작하여 새로운 버전의 실행 파일 및 구성 변경사항을 단계적으로 출시합니다. 변경사항을 전역적으로 출시하기 전 사용자 트래픽의 일부에만 영향을 미칠 때 버그를 포착하는 것을 목표로 합니다. 이러한 변경사항을 인식하고 변경된 서버의 측정항목을 나머지 서버와 A/B 비교하는 '카나리아 테스트' 시스템을 설정하여 비정상적인 동작을 신고합니다. 카나리아 시스템은 작업자에게 문제를 알려야 하며 출시를 자동으로 중단할 수도 있습니다. 변경사항이 카나리아 테스트를 통과하면 해당 변경사항을 더 큰 범위(예: 전체 영역)에 단계적으로 전파한 다음 두 번째 영역으로 전파합니다. 그런 후 변경된 시스템이 더 많은 양의 사용자 트래픽을 단계적으로 처리하여 잠재적인 버그를 노출할 때까지 기다립니다.

빌드, 테스트, 배포 자동화

CI/CD 파이프라인을 기반으로 출시 버전에 자동 테스트를 빌드하여 출시에 따른 수작업을 최소화합니다. 자동화된 통합 테스트 및 배포를 수행합니다.

자동화는 유용하지만 만능 해결책은 아니며, 초기 개발 및 설정 비용 외에도 유지보수 비용과 안정성에 대한 위험 부담이 있습니다.

먼저 시스템을 관리하는 팀의 수작업에 대한 목록을 작성하고 평가하는 것부터 시작하는 것이 좋습니다. 이 과정을 Google Cloud 서비스 및 파트너가 이미 제공한 서비스 범위를 확장하기 위해 맞춤설정된 자동화에 투자하기 전에 시작되는 지속적인 프로세스로 만들어야 합니다. 경우에 따라 Compute Engine의 자동 확장 알고리즘과 같은 Google Cloud의 자체 자동화 기능을 변경할 수 있습니다.

Google은 수작업을 수동적, 반복적, 능동적이며 자동화 가능한 작업으로 정의하며, 이러한 작업은 지속적인 가치가 없고 기반이 되는 인프라만큼 빠르게 성장하는 경향이 있습니다. 자세한 내용은 SRE 워크북 수작업 제거를 참조하세요.

고객 지원을 위해 Google에서 제공하는 구성 가능한 자동화 또는 맞춤설정된 자동화를 통해 수작업을 제거할 수 있는 몇 가지 주요 영역은 다음과 같습니다.

자동화 전에 먼저 제거할 수작업의 우선순위를 지정한 다음 두 번째 단계로 Google에서 제공하는 구성 가능한 자동화를 최대한 활용하여 남은 수작업을 줄이는 것이 좋습니다. 첫 번째 단계 및 두 번째 단계와 동시에 수행할 수 있는 세 번째 단계에서는 수작업 비용이 높게 유지(예: 프로덕션 시스템을 관리하는 모든 팀이 할애하는 시간의 50% 초과)되는 경우에 대비해 다른 솔루션의 빌드나 구매를 평가합니다. 솔루션을 빌드하거나 구매할 때는 통합, 보안, 개인정보 보호, 규정 준수 관리 비용을 고려해 보세요.

수동 워크플로를 자동화하거나 제거하는 경우, 사용자의 기술적 요구사항을 부분적으로만 충족하는 Google Cloud 제품 또는 서비스를 발견하면 Google Cloud 비즈니스 계정 담당자를 통해 기능 요청 제출을 고려해 보세요. 이는 Google 고객 중 다수에게 우선순위가 되거나 이미 로드맵의 일부일 수도 있습니다. 이 경우 기능의 우선순위 및 타임라인을 알고 있으면 자체 솔루션을 빌드하는 것과 Google Cloud 기능으로 사용할 수 있을 때까지 대기하는 것 사이의 상충 관계를 더 잘 평가할 수 있습니다.

설계 관련 질문

  • 실행 파일 및 구성의 변경 프로세스가 자동화되어 있나요?
  • 변경 자동화가 가능한 모든 변경사항에 대해 빠른 롤백을 사용하도록 설계되었나요?
  • 스키마 변경사항과 같이 롤백할 수 없는 변경의 경우 현재 또는 이전 바이너리 버전과 데이터 스키마 간의 상위 및 하위 호환성을 보장하기 위한 설계 검토 프로세스가 있나요?
  • 구성 변경사항을 전역적으로 출시하는 대신 단계적으로 출시하기 위해 시스템 구성 파일을 샤딩할 수 있나요?

권장사항

  • 새 출시 및 구성의 카나리아 테스트를 설정합니다.
  • 각 팀에 해당하는 수작업을 정의하고 관련 비용을 정기적으로 평가합니다.
  • 커스텀 자동화를 개발하기 전에 불필요한 수작업/워크플로를 제거합니다.
  • 기본 구성을 조정하거나 기본 구성이 제공되지 않은 경우 기본 구성을 만들어 Google Cloud 서비스를 통해 이미 제공되는 기존 자동화를 사용합니다.
  • 서비스 안정성 및 보안을 위한 유지보수 비용과 위험에도 불구하고 가치가 있을 경우 커스텀 자동화 빌드(또는 구매)를 평가합니다. 또한 유지보수 상태가 양호한 오픈소스 소프트웨어를 평가하는 것이 좋습니다.

효율적인 알림 빌드

알림 지연 최적화

모니터링 시스템에서 사용자에게 문제를 알리기 전에 구성된 지연 시간을 조정하여 신호 대 잡음 비율을 최대화하는 동시에 TTD를 최소화합니다. 오류 예산 소비율을 기준으로 최적의 알림 구성을 생성합니다.

원인이 아닌 증상 알림

사용자 환경에 미치는 직접적인 영향(예: 전역 또는 고객별 SLO 미준수)을 기준으로 알림을 트리거합니다. 특히 영향이 단일 복제본으로 제한되는 경우 장애의 모든 근본 원인에 대한 알림을 보내지 마세요. 잘 설계된 분산 시스템은 단일 복제본 장애로부터 원활하게 복구됩니다.

이슈 관리를 위한 공동작업 프로세스 빌드

잘 설계된 시스템도 결국에는 SLO를 충족하는 데 실패하게 됩니다. SLO가 없는 경우에도 고객은 SLA의 내용과 관계없이 과거의 경험을 토대로 허용 가능한 서비스 수준을 대략적으로 정의하고 기술 지원 또는 이와 유사한 그룹으로 에스컬레이션합니다.

고객에게 적절한 서비스를 제공하려면 이슈 관리 계획을 수립하고 정기적으로 구현해야 합니다. 계획은 10개 정도의 항목으로 구성된 한 페이지짜리 체크리스트일 수 있으며, 이 프로세스를 통해 팀은 평균 감지 시간(MTTD) 및 평균 완화 시간(MTTM)을 줄일 수 있습니다. MTTR의 경우 의미가 모호하기 때문에 그 대신 MTTM을 사용합니다. 여기서 R은 '완화' 대신 '전체 수정'을 의미하는 '수리' 또는 '복구'로 사용됩니다. MTTM은 전체 수정이 아닌 완화를 명시적으로 의미합니다.

운영 우수성이 검증된 잘 설계된 시스템의 경우 장애 간 평균 시간(MTBF)이 길어집니다. 자세한 내용은 시스템 설계 및 운영 우수성 섹션을 참조하세요.

또한 비난 없는 사후 분석 환경과 이슈 검토 프로세스를 수립해야 합니다. '비난 없는'이란 팀이 비난을 멈추고 객관적인 방식으로 문제를 평가하고 문서화해야 함을 의미합니다. 실수는 비판의 대상이 아닌 학습 기회가 되어야 합니다. 항상 시스템의 복원력을 향상시켜 사람의 실수로부터 신속하게 복구하거나 훨씬 더 효과적으로 사람의 실수를 감지하고 예방하는 것을 목표로 해야 합니다.

MTTD 감소

MTTD를 줄이기 위한 기본 요건은 '관측 가능성' 및 '모니터링 목표 정의' 섹션에 설명된 권장사항(예: 애플리케이션 문제와 기본 클라우드 문제 사이의 차이 구분)을 구현하는 것입니다.

여러 SLI를 적절히 조정하면 과다 알림을 유발하지 않고도 적시에 팀에 알림이 전송됩니다. 자세한 내용은 SLI 측정항목 개선: CRE 주기 강의를 참조하세요.

MTTM 감소

MTTM을 줄이려면 적절히 문서화되고 충분한 연습을 거친 이슈 관리 계획이 있어야 합니다. 또한 변경사항에 대한 데이터의 가용성을 높여야 합니다.

이슈 관리 계획 예시

  • 프로덕션 문제가 감지(알림, 페이지)되었거나 나에게 에스컬레이션되었습니다.
  • 우선 권한을 위임해야 하나요? 예. 본인과 팀이 문제를 해결할 수 없다면 위임해야 합니다.
  • 개인정보 보호 또는 보안 위반인가요? 그렇다면 개인정보 보호/보안 팀에 위임하세요.
  • 응급상황이거나 SLO가 위험한가요? 확실하지 않으면 응급상황으로 처리합니다.
  • 더 많은 사람이 참여해야 하나요? 예. X%를 초과하는 고객에게 영향을 미치거나 해결하는데 Y분 넘게 걸리는 경우 더 많은 사람이 필요합니다. 확실하지 않으면 영업 시간 중에 더 많은 사람을 투입하세요.
    • 기본 커뮤니케이션 채널(예: IRC, 행아웃 채팅, Slack)을 정의합니다.
    • 이전에 정의한 역할을 위임합니다. 예를 들면 다음과 같습니다.
      • 이슈 책임자: 전체 조정을 담당합니다.
      • 커뮤니케이션 책임자: 내부 및 외부 커뮤니케이션 처리를 담당합니다.
      • 운영 책임자: 문제를 완화합니다.
    • 이슈가 종료되는 시점을 정의합니다. 이를 위해서는 지원 담당자의 확인이 필요할 수 있습니다.
  • 사후 조사를 위해 공동작업합니다.
  • 반복되는 사후 조사 이슈 검토 회의에 참여하여 담당자가 수행할 작업에 대해 논의합니다.

그래프

다음은 고려해야 할 그래프의 일부 목록입니다. 이슈 대응 전문가가 단일 뷰에서 한 눈에 빨리 확인할 수 있어야 합니다.

  • 서비스 수준 지표(예: 성공한 요청을 총계로 나눈 값)
  • 구성 또는 바이너리 출시
  • 시스템에 대한 초당 요청 수
  • 시스템에서 반환된 초당 오류 수
  • 시스템에서 종속 항목으로 전송되는 초당 요청 수
  • 시스템에서 종속 항목으로 전송되는 초당 오류 수

또한 일반적으로 요청 및 응답 크기, 쿼리 비용, 스레드 풀(풀 소진으로 인한 회귀를 찾는 경우), JVM 그래프 측정항목(해당하는 경우) 등이 표시됩니다.

이러한 그래프를 배치하는 경우 몇 가지 시나리오를 테스트합니다. 또한 머신러닝을 적용하여 이러한 그래프의 올바른 하위 집합(즉, 이상 감지 기술)을 표시할 수도 있습니다.

마지막으로 앞에서 설명한 대로 빠른 완화를 위한 또 다른 일반적인 접근법은 쉽게 롤백할 수 있는 시스템과 변경사항을 설계하는 것입니다.

권장사항

  • 이슈 관리 계획을 수립하고 팀에 관련 교육을 실시합니다.
  • '관측 가능성' 섹션의 권장사항을 구현하여 MTTD를 줄입니다.
  • 이슈 발생 시 '변경사항'을 한 눈에 확인할 수 있는 대시보드를 빌드합니다.
  • 쿼리 스니펫을 문서화하거나 데이터 스튜디오 대시보드를 빌드합니다.
  • Firebase 원격 구성을 평가하여 모바일 애플리케이션 관련 출시 문제를 완화합니다.
  • '재해 복구' 권장사항을 구현하여 이슈의 하위 집합에 대한 MTTM을 줄입니다.
  • 구성 및 바이너리 롤백을 설계하고 테스트합니다.
  • '시스템 설계' 및 '재해 복구'(테스트) 섹션의 권장사항을 구현하여 MTBF를 높입니다.

리소스