클라우드 안정성 사고 처리를 위한 권장사항

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

---

클라우드 중단은 전 세계적인 서비스 중단부터 특정 리전, 영역 또는 프로젝트, 워크로드, 애플리케이션에 국한된 문제까지 다양합니다. Google Cloud Platform 서비스 중단이 서비스에 영향을 미치고 있다고 의심되는 경우 체계적인 '확인→조사→보고→해결→검토' 워크플로를 따라 문제를 해결하는 것이 좋습니다. 또한 서비스 중단이 발생하기 전에 장애를 고려하여 설계하고 서비스 복원에 필요한 단계를 적극적으로 연습하여 향후 발생할 중단에 맞춰 환경을 준비해야 합니다. 

이 블로그에서는 안정성 사고 대응 기능을 설계 및 실행하고 영향을 최소화하는 데 도움이 되는 주요 안정성 사고 처리 권장사항을 간략히 설명합니다. 이는 포괄적인 가이드가 아니라 자문 목적으로 가장 중요한 관행만 다루는 입문서입니다. 보안 사고와 관련된 추가 관행은 여기에서 다루지 않습니다. 

여기에서 다룬 기본 단계 외에도 AI 에이전트와 도구가 사고 처리 방식을 어떻게 혁신하고 있는지 살펴보는 것도 좋습니다. Prodcast의 이번 에피소드에서는 Google 직원들이 사이트 안정성 엔지니어링(SRE)에서 에이전트 AI를 활용하여 문제를 조기에 감지하고 중단을 방지하는 최신 트렌드를 살펴봅니다. Cloud Assist 조사를 사용해 보거나 에이전트 스킬 및 원격 관리 MCP 서버를 탐색하여 문제를 빠르게 파악할 수 있는 또 다른 도구 모음을 확보하세요. 이러한 고급 기법을 살펴보기 전에 먼저 사고를 효과적으로 처리하기 위한 기본적인 단계를 중점적으로 살펴보겠습니다.

1. 준비

문제가 발생하기 훨씬 전에 설계, 데이터, 플레이북, 교육이라는 최소 네 가지 차원에서 서비스 중단에 대비하는 데 상당한 시간을 투자해야 합니다.

• 설계: 느리거나 응답하지 않는 인스턴스에서 트래픽을 전환하는 부하 분산기와 같은 자동화된 대응 조치를 설계하거나 사고 대응 플레이북을 최대한 자동화하여 미래를 대비하고 향후 사고를 완화합니다. 모든 중요 애플리케이션의 설계를 검토하여 가능한 한 많은 작업을 자동화함으로써 대응 및 복구 속도를 높입니다.

• 데이터: 중단이 발생했을 때 의미 있는 데이터를 즉시 사용할 수 있으면 대응 역량이 크게 향상됩니다. Cloud Logging, Cloud Trace, Cloud Monitoring 또는 기타 서드 파티 관측 가능성 도구를 사용하고, 관측 대상 시스템과 별도의 위치에 있는 중복 스택에 해당 데이터를 복제합니다. 사고가 발생하기 전에 관측 가능성 스트림 전반에서 타임스탬프가 동기화되어 쉽게 연관성을 파악할 수 있는지 확인하거나, 시간이 중요한 서비스 중단 시 주문형으로 이를 수행하는 방법을 알아두세요.

• 플레이북: 모든 담당자의 역할과 책임을 명확하게 정의하고 사고 대응 프로세스를 상세히 기록한 잘 짜인 플레이북은 효율적인 사고 대응을 위해 무엇보다 중요합니다. 누가 무엇을 담당하나요? 각 중단 유형에 대해 누구에게 알리거나 누구를 동원해야 하나요? 어떻게 연락할 수 있나요? 어떤 도구와 데이터를 사용할 수 있나요? 결과는 어떻게 전달되나요? 장기화되는 사고가 발생할 경우 팀은 다음 교대 근무자에게 어떻게 업무를 인수인계하나요? 사고 대응 시뮬레이션을 실시하고 모든 단계를 면밀히 검토하여 플레이북에서 보완이 필요한 부분을 파악하세요. 책임이 명확하지 않으면 완화 조치에 더 오랜 시간이 걸릴 수밖에 없습니다.

• 교육: 서비스 중단은 드물게 발생하는 이벤트입니다. 직원들이 대응 방법을 숙지하고 기억하도록 하려면, 팀 간 사고 대응 시뮬레이션 훈련을 매년 여러 차례 실시하여 관련 프로세스를 반복 교육해야 합니다. 시뮬레이션 훈련에 대한 사후 검토를 통해 필요한 개선 사항을 파악할 수 있습니다.

2. 확인

최선을 다해 대비하더라도 서비스 중단은 발생하기 마련입니다. 다음과 같은 여러 경로를 통해 서비스 중단을 감지할 수 있습니다.

• 관측 가능성 도구(Google 도구 또는 서드 파티 도구)

• 예정된 유지보수에 대한 Unified Maintenance 관리 알림

• 알림 정책으로 관리되는 Personalized Service Health 알림

• Google의 선제적인 고객 모니터링

이제 무엇이 손상되었는지, 궁극적으로 누가 문제를 해결해야 하는지 결정해야 합니다.

• Google, 예: 버그, 코드 출시, 하드웨어 장애 등

• 사용자, 예: 구성 변경, 부하 증가, 할당량 상한 등

• 서드 파티, 예: 다른 클라우드 제공업체에서 호스팅하는 디렉터리

Google에서 사고를 선언하고 문제 해결을 시작한 경우, 보조 스택으로 장애 조치하는 식으로 서비스를 빠르게 복구할 수 있는지 추정합니다(아래의 '일반적인 원인' 표 참조). Google에서 사고를 선언하고 수정사항을 제공할지 여부는 다음을 참조하여 확인할 수 있습니다.

• Personalized Service Health: 이것을 먼저 확인하세요. Personalized Service Health는 프로젝트 및 리전과 관련된 사고를 구체적으로 보여주며, 사고 유형을 다음과 같이 구분합니다. 

• 새로운 사고: Google에서 알림을 수신했으며, 담당자가 조사 중이고, 영향은 아직 알려지지 않음

• 확인된 사고: Google에서 조사한 결과 고객이 영향을 받은 것으로 확인됨

Google Cloud 콘솔 내에 있는 Personalized Service Health에는 공개 대시보드에 나타나지 않는 제한된 범위의 사고가 표시되는 경우가 많습니다. Personalized Service Health는 Android 및 iOS 스마트폰용 모바일 클라이언트도 제공합니다. 단, 휴대전화에서 업무용 ID와 사용자 인증 정보를 사용할 수 있어야 합니다.

• Gemini Cloud Assist는 Personalized Service Health와 통합되어 있으므로 자연어로 해당 정보를 쿼리하는 데 사용할 수 있습니다.

• Cloud Service Health 대시보드: 많은 고객에게 영향을 미치는 광범위하고 심각한 사고를 알려 주는 인증되지 않은 공개 웹페이지입니다. 영향 범위가 제한된 중단은 공개적으로 외부화되지 않습니다. 모든 콘텐츠는 Personalized Service Health에서도 사용할 수 있습니다. Personalized Service Health가 중단되는 경우 Cloud Service Health가 별도의 인프라에 구축된 대체 채널 역할을 합니다.

• 알려진 문제: 콘솔에서 지원 > 케이스로 이동하여 케이스를 확인하고 콘솔 툴바의 리소스 선택기를 사용하여 관심 있는 특정 클라우드 리소스를 찾습니다. 그런 다음 알려진 문제를 클릭합니다. 문제가 여기에 나열된 문제와 일치하는 경우 지원 케이스를 연결하면 케이스 기록에서 자동 업데이트를 받을 수 있습니다. 일치하는 항목이 없으면 새 지원 케이스를 엽니다. Google은 사고가 선언되는 즉시 해당 케이스를 관련 사고에 자동으로 연결합니다.

• Google에서 선언한 사고는 새로운 정보가 제공될 때마다 업데이트되므로 정기적으로 다시 확인하거나 Personalized Service Health 알림 정책을 설정하여 새로운 정보가 제공될 때마다 알림을 받으세요.

여러 클라우드에서 리소스를 호스팅하고 있다면, 문제가 여러 클라우드 제공업체에서 공통적으로 발생하는지 초기에 확인해 보는 것이 좋습니다. 그렇다면 사용자 또는 애플리케이션이 상호작용하는 서드 파티 서비스로 인해 문제가 외부에서 발생했을 가능성이 높습니다.

3. 조사

Google에서 선언한 안정성 사고의 클라우드 사용 공간 내 영향 범위를 확인하려면 먼저 Personalized Service Health 업데이트에서 기술적 문제에 대한 설명을 확인하세요. 무엇을 찾아야 하는지 알면 영향 범위를 파악하고 적절한 비상 조치를 더 빠르게 결정할 수 있습니다.

Google에서 사고를 선언하지 않은 경우 다음 사항을 확인하여 환경 내 구성 오류 또는 문제를 배제해 보세요.

• Cloud Monitoring: 대시보드에서 오류율(예: 5xx 오류) 급증, 지연 시간 증가 또는 트래픽 감소를 확인합니다.

• Cloud 로그: 로그 탐색기를 사용하여 DEADLINE_EXCEEDED, SERVICE_UNAVAILABLE과 같은 특정 오류 메시지 또는 API 오류를 찾습니다.

• 할당량: 프로젝트 할당량(예: CPU, API 비율 제한)에 도달하지 않았는지 확인합니다. 할당량에 도달하면 서비스 중단과 유사한 동작이 발생할 수 있습니다.

• 변경 내역: 최근에 적용된 변경사항의 로그를 확인합니다. 모든 문제가 즉시 나타나는 것은 아니지만, 타임라인상 근접성은 확정적 증거가 아닐지라도 인과 관계를 보여 주는 강력한 지표가 될 수 있습니다. 또한 증상이 시작되기 직전에 Google에서 업데이트를 출시했는지 확인합니다. Cloud Hub에서 Unified Maintenance 관리 인터페이스를 확인하세요.

트래픽 급증이나 DDoS 공격과 같은 명확한 원인이 없는데 변경사항을 적용한 직후에 문제가 발생했다면, 해당 변경사항을 취소하고 마지막으로 정상 작동이 확인된 구성으로 되돌리는 것이 좋은 전략입니다. 

4. 보고서

Cloud Service Health 및 Personalized Service Health 대시보드가 녹색이지만 측정항목에 장애가 표시되는 경우 Google에 보고해야 합니다. 

• 우선순위 결정:

• P1(심각): 프로덕션 서비스를 사용할 수 없거나 심각한 영향을 받았으며 해결 방법이 없습니다.

• P2(높음): 심각한 영향 또는 성능 저하가 있지만 해결 방법이 있을 수 있습니다.

• 우선순위 설정에 관한 안내 및 문제 설명에 관한 안내를 참고하세요.

• 케이스 제출: 콘솔에서 지원 > 케이스 > 케이스 만들기로 이동합니다.

• 제출한 우선순위의 근거를 마련하고 Cloud 지원팀에서 케이스의 우선순위를 지정할 때 하향 조정되지 않도록 정량화할 수 있는 비즈니스 영향을 설명하세요. 명확하고 정확한 근거를 제시하면 도움이 됩니다.

• 포함할 필수 정보:

• 프로젝트 ID와 영향을 받는 리전/영역

• 타임스탬프(시작 시간, 진행 여부)와 명확하게 표시된 시간대

• 특정 오류 메시지 또는 로그 스니펫

• 범위: 모든 사용자/시스템에 영향을 미치나요? 특정 하위 집합/위치에만 영향을 미치나요?

프리미엄/고급 지원 에스컬레이션

프리미엄 또는 고급 지원 요금제를 이용 중인데 P1 케이스가 적절한 조치를 받지 못하고 있다면, 콘솔 내 해당 지원 케이스에서 에스컬레이션 버튼을 사용하세요. 그러면 지원 관리자가 상황을 조사하고 시정할 수 있도록 알림이 전송됩니다.

5. 해결

이러한 단계를 수행하고 있다면 서비스 중단을 해결하기 위한 과정을 잘 밟고 있는 것입니다. 그동안 서비스 중단의 영향을 완화하고 영향을 받는 이해관계자와 소통할 수 있는 몇 가지 방법을 소개합니다.

해결을 기다리는 동안 다음 작업을 수행하세요.

• 소통: 이해관계자와 고객에게 알립니다. 투명한 정보 공유는 기대치를 조절하고 불필요한 내부 보고가 중복되는 것을 방지해 줍니다.

• 장애 조치: 멀티 리전 아키텍처를 사용하는 경우 트래픽을 정상 리전으로 전환하는 것을 고려하세요. 먼저 중단이 워크로드 수준이 아닌 인프라 수준에서 발생했는지 확인하는 것이 좋습니다. 

• 해결 방법 확인: Google은 영구적인 해결 방법을 마련하는 동안 Service Health Dashboard 업데이트 또는 Personalized Service Health 업데이트에 임시 해결 방법을 게시하는 경우가 많습니다.

• 규제 보고 요구사항 고려: 조직이 규제 보고 요구사항의 적용을 받는지, 최초 보고와 후속 보고의 기한이 언제인지 파악합니다. Google Cloud는 특정 기준을 충족하는 사고에 대해 사고 보고서를 작성합니다. 보고서를 받는 방법은 여기에서 확인하세요. 프리미엄 지원 고객은 계정의 특정 호스팅 위치, 타임스탬프 등에 맞게 맞춤설정된 사고 보고서인 사고 요약을 요청할 수도 있습니다.

에스컬레이션 해제 및 종료

시스템이 안정화되면 Google은 심각도 수준을 낮추고 대기 중인 에스컬레이션 체인을 해제합니다. Google은 영향을 받은 모든 고객을 대상으로 모든 완화 조치를 취한 경우에만 Personalized Service Health에서 사고를 종료합니다. 다른 고객보다 먼저 복구가 완료되는 경우, 사고 종료 시간 이전이라도 사용자의 특정 서비스가 복원될 수 있습니다. 시스템이 지정된 자동 종료 기간에 안정적으로 실행되면 Google Cloud 상태 대시보드에서 사고가 공식적으로 종료됩니다. 이 시점에서 서비스가 정상적으로 작동하는지 확인합니다. 사고 대응 담당자가 사고 처리에 쏟은 추가 시간에 대해 별도의 보상을 받지 못하는 상황이라면, 어떤 방식으로든 꼭 감사의 마음을 전해 보세요.

6. 검토

문제가 해결되고 운영이 정상적이고 안정적인 상태로 돌아오면 사후 분석을 수행하여 향후 서비스 중단 시 팀이 더 효과적으로 대응할 수 있는 방법을 파악해야 합니다. 사고 대응 프로세스에서 의미 있고 실질적인 개선 사항을 도출하려면 '비난 없는' 접근 방식이 필요합니다. 다음과 같이 질문해 보세요.

• 어떤 점이 만족스러웠나요?

• 어떤 점을 개선해야 한다고 생각하시나요?

• 어떤 부분에서 운이 좋았을까요?

• 어떤 부분에서 운이 나빴을까요?

그런 다음 플레이북, 도구, 교육을 개선하기 위해 어떤 변화를 줄 수 있는지 결정합니다.

Google에서는 주요 서비스 중단에 대해 종종 사후 분석 또는 사고 보고서를 게시하며, 이는 Personalized Service Health를 통해 확인할 수 있습니다. 이를 검토하여 근본 원인을 파악하고 자체 재해 복구 계획을 조정하여 향후 영향을 방지하거나 줄이세요. 프리미엄 지원 요금제를 사용하는 고객은 Google로 인해 발생한 사고에 영향을 받고 P1 케이스를 연 경우 사고 요약을 요청할 수 있습니다. 사고 요약은 고객의 환경(예: 영향의 시작 및 종료 시간)에 맞게 맞춤설정된 사고 보고서입니다.

일반적인 원인, 소통 및 예방 전략

앞으로 준비하고 계획하는 데 도움이 되도록 Cloud Service Health 및 Personalized Service Health에 보고된 증상을 기반으로 몇 가지 일반적인 사고를 개요로 정리했습니다. Google에 기대할 수 있는 소통에 대한 안내와 플레이북에 포함할 수 있는 몇 가지 일반적인 완화 또는 예방 전략도 함께 제공합니다.

 

자세히 알아보기

이 문서는 핵심 사항을 간략하게 요약한 것입니다. Google Cloud와 프리미엄 지원 계약을 체결한 경우 계정팀에 문의하여 대응 계획을 자세히 검토하세요. 안정적인 서비스를 구축하고 사고에 대응하는 방법을 포괄적으로 다룬 논문은 Google의 SRE 도서에서 확인하세요. 무료로 다운로드할 수 있습니다. SRE 도서의 새 버전이 2026년 10월경에 출시될 예정이며 O’Reilly Media에서 구매할 수 있습니다. AI 지원 사고 처리를 심층적으로 살펴보는 입문서도 준비 중이니 기대해 주세요.