이 문서를 통해 프로젝트 관리자 및 기술 리더가 애플리케이션에 대한 사용자 트래픽 급증이 예상되는 기간의 실행 계획을 만드는 데 도움이 됩니다. 예를 들어 미국에서는 11월의 마지막 금요일인 블랙 프라이데이에 1년 중에서 가장 많은 판매가 이루어질 수 있습니다. 다른 여러 국가에도 소매업체에 매우 높은 트래픽이 예상되는 비슷한 기간이 있습니다. 이 문서에서는 블랙 프라이데이 유형의 이벤트에서 조직 준비 상태, 시스템 안정성, Google 고객 참여도를 높일 수 있는 부분을 설명합니다. Show 이 문서에서는 다음과 같은 시스템을 설명합니다.
소개소매 업계의 상거래 시스템은 평균 부하보다 5배 이상 많은 단기간의 피크 요청량을 처리해야 하는 쉽지 않은 기술적 문제에 직면하게 됩니다. 미국에서 이러한 이벤트는 11월 추수감사절 이후 블랙 프라이데이와 사이버 먼데이 기간에 발생합니다. 다른 국가에도 매년 각기 다른 기간에 이와 비슷하게 트래픽이 급증하게 되는 이벤트가 있습니다. 이를 해결하는 방법 중 하나는 클라우드 네이티브 시스템 전략을 채택하는 것입니다. 기존 배포와 비교하여, 이 전략은 피크에 대비한 계획 및 실행을 개선하는 데 도움을 줄 수 있으며 새롭게 고려해 볼 만한 옵션을 제공합니다. 블랙 프라이데이는 미국 내 유통업계의 주요 이벤트로 꼽히긴 하지만 선거일 저녁이나 크리스마스, 12월 31일 등의 휴일과 유사한 특성을 갖고 있습니다. 피크 이벤트는 일반적으로 다음과 같은 특성을 나타냅니다.
거래 쪽으로 트래픽이 쏠리는 상거래 시스템에서는 프런트엔드 증가가 그리 크지 않을 수도 있습니다. 예를 들어 프런트엔드 웹 트래픽은 2~4배 증가하는 반면, 주문/분 단위로 측정되는 백엔드 시스템의 부하는 10배 이상 증가할 수 있습니다. 다음 그림은 일반적인 사용자 트래픽 증가를 보여줍니다. 트래픽의 특징은 최대 트래픽까지 갑자기 증가한 후에 점차 정상으로 돌아간다는 것입니다.  블랙 프라이데이 이벤트를 진행할 때 계획, 준비, 실행 등 세 단계를 따르는 것이 좋습니다. 다음 다이어그램에서 각 단계가 어떻게 각기 다른 역할, 기술, 프로세스를 강조하는지 살펴보세요. 운영 및 관리 직원은 피크 이벤트의 전술적 측면을 활용하여 조직을 이끕니다. 세 가지 단계 및 각 단계의 활동을 검토함으로써 담당 직원은 팀이 피크 이벤트에 더 잘 대응하도록 준비시킬 수 있습니다. 이벤트 중에 예상치 못한 문제가 발생할 경우, 준비가 잘 되어 있으면 문제를 더 빠르고 정확하게 분류하고 해당 문제의 영향을 줄이는 해결 경로를 제공할 수 있습니다. 용어블랙 프라이데이애플리케이션에서 발생하는 모든 유형의 최대 트래픽 이벤트입니다.QPS초당 쿼리 수입니다. 트래픽 양을 나타내는 일반적인 측정항목입니다. QPS는 주문/분과 비교했을 때 일반적으로 기술적인 측면에서 양을 나타내는 용어입니다.주문/분거래 지표입니다. 이 용어는 초당 장바구니 추가 횟수와 같은 다른 지표를 포함합니다. 이 지표는 QPS와 비교했을 때 좀더 비즈니스 관점에서 세부적인 거래량을 나타냅니다.SLI서비스 수준 지표입니다. 서비스가 용인되는 범위 안에 있는지를 나타내는 데 사용되는 측정항목입니다. 예를 들어 페이지 로드 시간의 SLI는 웹페이지와 모든 기본 API 호출을 95번째 백분위수에서 로드하는 것일 수 있습니다.SLO서비스 수준 목표입니다. SLI 및 타겟 목표를 사용하여 정의됩니다. SLO의 예시에는 앞선 SLI 지연 시간이 400ms 아래여야 함 등이 있습니다.SLA서비스수준계약입니다. 고객과 공급업체 사이의 계약에 정의된 서비스에 대한 안정성 목표, 조건 및(종종 재무적인) 결과입니다. SLI 지연 시간이 10분 연속 1초 넘게 유지될 경우 SLA 위반이 발생한 시간 내에서 QPS 100을 초과하는 트래픽의 청구 사용량에 대해 50% 할인 자격이 고객에게 부여되는 경우를 SLA 예시 중 하나로 들 수 있습니다.계획 단계'희망은 전략이 아니다'라는 격언은 철저한 계획과 준비가 필요한 이유를 설명할 때 종종 인용됩니다. 조직 전반에서 그리고 타사 공급업체와 함께 강력한 복합적 계획 및 조율을 실시하면 성공 가능성이 증가합니다. 엔지니어링, 아키텍처, 운영, 비즈니스 관계자들은 무엇을 측정해야 하는지에 동의하고 피크 이벤트가 프로덕션 시스템에 미칠 영향에 대해 알고 있어야 합니다. 계획 및 운영체제 지원에 있어서는 데이터 중심의 의사결정으로 팀 내의 선택과 절충을 결정하게 됩니다. 다음 표에는 계획 단계의 주요 단계가 요약되어 있습니다.
데이터 수집계획 단계에서 처음으로 할 일은 데이터를 수집하는 것입니다. 측정 데이터 이해기존 측정 데이터(요청/초, 주문/분, 초당 장바구니 추가 횟수)로 시작하면 피크 이벤트를 이해하고 계획할 수 있는 토대가 마련됩니다. 다음 질문에 답변하는 것으로 이 프로세스를 시작할 수 있습니다.
목표는 어떤 데이터를 사용할 수 있는지 그리고 해당 데이터가 과거에 어떠한 가치를 제공했는지를 파악하는 것입니다. 수집되고 있지 않은 측정항목이나 SLI가 발견되었다면 준비 단계 중에 시스템을 수정하여 해당 데이터를 수집할 수 있도록 해당 데이터에 우선순위를 두세요. 데이터를 수집하는 것도 중요하지만, 측정항목이 어떤 유용한 정보를 제공하는지를 이해하는 것이 중요합니다. 측정항목이 사용자 만족도 및 비즈니스 성공 지표에 어떻게 관련되는지를 이해하면 시스템 규모가 훨씬 커졌을 때 측정항목을 해석하는 방법을 알 수 있습니다. 이전 피크 이벤트 검토구체적인 프로세스와 무관하게 이전 이벤트로부터 배우는 것이 중요합니다. 특히 부하가 걸렸을 때 시스템에 어떤 제약이 있었는지가 확연히 드러나는 경우는 더욱더 그렇습니다. 기술 분야에서 사후 분석은 데이터를 캡처하고 발생한 이슈를 이해하는 데 유용한 기법입니다. 비즈니스 예측 준비블랙 프라이데이의 영향을 예측함으로써 기업은 상품을 조달하고 판매를 준비하는 방법을 계획할 수 있습니다. 재고 관리, 공급망 관리, 직원 배치 등의 요소에는 정확한 비즈니스 예측이 큰 영향을 미칩니다. 시스템이 트래픽 급증에 대비하는 데에도 이러한 예측이 중요합니다. 이전 예측으로부터 더 많은 정보를 알아낼수록 새로운 비즈니스 판매를 더 정확하게 예측할 수 있습니다. 이와 같은 새로운 예측 정보는 시스템에 예상되는 수요가 어느 정도인지를 판단하는 데에도 중요한 데이터입니다. 다음의 주요 비즈니스 요인 측정항목은 대부분의 전자상거래 사이트에서 흔히 찾아볼 수 있습니다.
이러한 요인을 바탕으로, 측정항목을 시스템이 분석할 수 있는 형태로 변환할 수 있습니다. 그러한 측정항목에는 다음이 포함될 수 있습니다.
그런 다음에 해당 측정항목을 시스템 동작을 측정하고 시스템 상태를 표시하는 SLI 및 SLO로 변환할 수 있습니다. 프로그램 관리 설정조율은 블랙 프라이데이 성공을 위한 핵심입니다. 계획, 준비, 실행 단계를 엔지니어링, 아키텍처, 운영, 리더십 등의 내부 관계자 그리고 타사 공급업체와 맞추고 합의해야 합니다. 공동의 목표를 달성하려면 투명한 커뮤니케이션과 협업이 필요합니다. 먼저 다기능팀을 편성하고, 관계자들을 독려하는 역할을 하는 운영위원회를 구성하는 것이 좋습니다. 프로그램 관리에서 타임라인을 설정할 수 있도록 이러한 팀을 초기에 구성하세요. 프로그램 관리는 추가 인프라, 테스트 지원, 교육을 위한 예산과 리소스도 확보해야 합니다. 커뮤니케이션 채널 설정커뮤니케이션은 피크 이벤트 실행의 모든 단계에서 중요합니다. 계획과 동시에 다음 항목을 만드세요.
공유 상태 검토공유 상태란 여러 팀의 관점을 종합하여 합의에 도달하는 것을 의미합니다. 하나의 관점에 의존하는 대신 합의를 통해 시스템을 더 폭넓게 바라볼 수 있습니다. 공유 상태는 집단의 결정이 개인의 결정 범위를 넘어서 시스템에 어떤 영향을 주는지를 보여줍니다. 예를 들어 기술적 구성의 사소한 변경이 비즈니스 측정항목에 큰 영향을 줄 수도 있습니다. 각각의 공유 상태 검토는 소유 팀과 모든 관련 팀 사이에 이루어집니다. 이러한 검토에서 Google Cloud팀과 소통하면 Google팀이 블랙 프라이데이와 관련된 상황을 파악할 수 있습니다. 그리고 Google팀은 다른 여러 고객과 협력하면서 알게 된 권장사항을 피드백으로 제공할 수 있습니다. 모니터링 및 프로빙 설정모니터링을 통해 시스템의 운영 효율성을 유지하기 위한 정확한 결정을 내릴 수 있습니다. 모니터링은 시스템 상태를 추적하는 데 도움이 되고, 예정된 문제를 미리 알리며, 애플리케이션의 네 가지 주요 신호에 관한 유용한 정보를 제공합니다.
피크 이벤트 문제를 감지하려면 이러한 네 가지 신호의 중요한 가치를 반드시 이해해야 합니다. 구체적이고 실행 가능한 모니터링 단계에는 다음이 포함됩니다.
시스템 모니터링 검토용어 섹션에서 언급한 대로 SLI는 SLO를 측정하는 데 사용됩니다. 모니터링을 사용하여 SLI 및 기타 주요 시스템 값을 모니터링할 수 있습니다. 이 접근 방식을 통해 다음을 파악할 수 있습니다.
모니터링을 통해 성능과 SLO를 검토하는 데 중요한 모든 관련 인프라 및 애플리케이션 측정항목에 대한 정보를 캡처하는 것이 이상적입니다. 여러 영역에서 모니터링을 사용할 수 있습니다.
SLO를 선택한 후에는 단일 핵심 측정항목 집합으로 전반적인 시스템 상태를 표시할 수 있도록 모든 관계자들에게서 폭넓은 합의를 도출해야 합니다. 그런 다음에 시스템 비정상 작동의 알림을 구성하는 데 필요한 데이터를 좁혀나갑니다. 용량 계획 만들기용량 계획은 소매 상거래 시스템에서 중요한 활동입니다. 동적 용량 할당이 가능한 클라우드 네이티브 시스템은 기존 시스템에 비해 아키텍처 및 기술적 측면의 장점을 제공합니다. 수만 개의 코어까지 용량을 확장할 수 있는 클라우드 네이티브 시스템은 보통 수천 개의 컴퓨팅 코어를 사용하므로 평균 부하보다 낮은 경우가 많습니다. 이 경우 클라우드 제공업체와 클라우드 인프라팀은 용량 계획을 공동으로 책임지며, 운영팀은 신뢰 구간이 있는 용량 계획을 만들어야 합니다. 이러한 간격은 추가 VM으로 확장할 수 없게 되는 경우와 같은 예상치 못한 사고를 방지하는 데 도움이 됩니다. 이러한 동적 용량 시스템은 제한적이고 산발적인 용량 급증에 적합합니다. 하지만 자동 확장 및 적시(JIT) 프로비저닝에 의존하는 것보다는 용량 계획을 검토하고 프로비저닝 전 용량을 평가하는 것이 좋습니다. 귀사와 클라우드 제공업체가 사전 확장, 예약 및 기타 기능을 사용하여 시스템 가용성을 높일 수 있다고 생각해보세요. 피크 이벤트 직전에 이 인프라를 프로비저닝할 수 있으며, 불필요한 클라우드 비용을 방지하기 위해 피크 이벤트 후에 곧바로 축소할 수 있습니다. 용량 계획 환경을 개선하기 위해 Google과 고객들은 다음과 같은 권장사항을 개발했습니다.
체크리스트 만들기블랙 프라이데이 같은 이벤트는 주기적으로 발생합니다. 내년에도 블랙 프라이데이는 찾아올 것이고, 또 다른 홍보 캠페인이 진행되거나 대규모 제품 출시가 있을 것입니다. 이벤트마다 정보는 고유하지만 애셋은 재사용하고 확장할 수 있습니다. 매해 이벤트를 통해 체크리스트를 만들고 조정하고 개선하면서 관리의 부담을 줄여 지속적으로 프로세스를 발전시킬 수 있습니다. 체크리스트는 비행기 조종사의 비행 전 점검과 비슷합니다. 오류를 방지하고 일관된 방식으로 실행하는 데 도움이 됩니다. 체크리스트 권장사항은 다음과 같습니다.
위험 분석을 관계자들과 공유하고 우선순위를 알리는 것이 중요합니다. 분석 결과로 어떤 위험이 시스템, 내부 팀, 클라우드 제공업체, 타사 공급업체의 책임하에 있는지를 파악해야 합니다. 클라우드 제공업체 및 공급업체와도 위험을 공유하세요. 일부 위험은 이미 알려져 있고 용인되는 것일 수도 있습니다. 일부는 클라우드 제공업체 또는 공급업체의 도움을 받아 완화 계획을 세워야 합니다. 아키텍처 계획블랙 프라이데이를 위한 아키텍처를 계획하는 것은 고유의 권장사항이 있는 별개의 문제입니다. 피크 시스템 제약조건은 위험 분석에 영향을 미치며 성공적인 최대 부하 테스트에 매우 중요합니다. 설계 아키텍처 검토모든 당사자가 솔루션을 이해하도록 대략적인 설계 아키텍처를 검토하는 것이 좋습니다. 이 검토는 단일 장애 지점(SPOF)이나 Google의 알파 또는 베타 구성요소를 사용하는 것과 같은 안정성 문제를 팀에 알립니다. 모든 문제를 완화할 수는 없지만 문제가 있다는 것을 아는 것만으로도 모든 팀에게 도움이 됩니다. 프로덕션 준비를 위해 시스템을 지원하려면 각각 특정한 대상을 목표로 하는 두 가지 수준의 아키텍처가 필요합니다.
블랙 프라이데이 아키텍처 패턴 검토아키텍처 패턴은 클라우드 기반 시스템을 최적화하고 클라우드 분산 시스템의 몇 가지 난제에 대처하는 데 도움이 됩니다. 다음의 권장사항은 피크 이벤트 중에 클라우드 시스템의 안정성을 높이는 데 도움이 됩니다.
장애 조치 전략 수립제대로 준비되지 않은 팀은 블랙 프라이데이 같은 중요 이벤트 기간에 서비스 중단과 고객 불만이라는 문제를 겪게 됩니다. 장애 조치 전략을 수립하면 팀이 장애의 근본 원인을 조사하는 동안 시스템 업타임을 유지할 수 있습니다. 모든 요소에 장애 가능성이 있기 때문에, 장애와 관련된 위험을 평가하고 시스템의 SLO를 파악하면서 안정성과 비용 사이에서 적절한 균형점을 찾아야 합니다. 클라우드 시스템은 다음과 같은 장애 조치 패턴을 사용합니다.
계획 단계 결과물다음의 계획 단계 결과물은 준비 및 실행 단계 중에 사용됩니다.
준비 단계준비 단계의 목표는 시스템이 최대 사용자 트래픽에 맞춰 확장되고 결과를 문서화할 수 있는지를 테스트하는 것입니다. 준비 단계를 완료하면 최대 트래픽을 더 효율적으로 처리하고 시스템 안정성을 향상시키도록 아키텍처가 개선됩니다. 피크 이벤트와 발생 가능한 문제를 처리하는 프로세스를 간소화하는 데 도움이 되는 운영 및 지원 절차도 이 단계에서 마련됩니다. 시스템 및 운영 관점에서 이 단계는 피크 이벤트에 대한 연습이라고 보면 됩니다. 다음 표에는 계획 단계의 주요 단계가 요약되어 있습니다.
안정성을 보장하도록 지원Google 사이트 안정성 엔지니어(SRE)는 Google 서비스의 안정성과 속도에 초점을 맞춥니다. SRE는 플랫폼 상태를 책임지며 Google 서비스 안정성을 최고 수준으로 유지할 수 있게 도와줍니다. Google SRE팀은 대규모 시스템을 빌드, 출시, 운영하는 방법과 관련하여 많은 권장사항과 경험에 바탕을 둔 조언을 담은 2권의 서적을 출판했습니다. 많은 정보를 활용할 수 있지만, 그 중에서도 특히 부하 테스트와 장애 테스트라는 두 가지가 블랙 프라이데이 이벤트의 성공과 관련이 있습니다. 부하 및 성능 테스트 설정부하 테스트는 테스트 버전의 시스템을 배포하고 요청을 만들어서 높은 시스템 사용률을 시뮬레이션하는 프로세스입니다. 부하 테스트는 일반적으로 절대 최대치 아래의 일부 백분위수에서 지속 가능한 사용자 인지 동작을 테스트하는 데 초점을 맞춥니다. 피크 테스트를 통과하려면 일관된 우수한 성능으로 해당 최상위 백분위수에 도달해야 합니다. 부하 및 성능을 테스트할 때 다음의 권장사항을 따르세요.
시나리오 평가 및 테스트피크 이벤트의 성공 신뢰도를 높이기 위해서는 이벤트 중에 발생할 수 있는 시나리오를 평가하고 테스트하는 것이 중요합니다. 시스템이 재해 상황에 대응할 수 있는지 테스트하기 위해 설계된 프로세스와 도구에는 Google DiRT, Netflix Chaos Monkey 등 여러 가지가 있습니다. 준비 단계 동안에 가장 영향력이 큰 장애 시나리오를 테스트하면 성공 가능성을 높일 수 있습니다. 그러면 피크 상황에서 장애가 발생하더라도 문제를 해결할 수 있는 프로세스나 기술적 솔루션을 찾을 수 있습니다. 다음의 권장사항을 따르세요.
확장 및 안정성을 위해 아키텍처 변경부하 테스트 및 장애 테스트는 아키텍처 검토와 더불어 시스템의 규모와 안정성을 향상시킬 수 있는 제한된 범위의 아키텍처 변경을 장려합니다. 하지만 변경사항이 있으면 위험이 추가되므로 시간 범위를 보수적으로 잡고 변경을 제한하세요. 예를 들어 다음과 같은 변경을 고려할 수 있습니다.
이러한 아키텍처 변경사항 중 다수가 기능 개발 중에 이미 구현되었다면 이상적일 것입니다. 위험 수준이 적절하고 리소스가 풍부한 경우에는 아키텍처 변경이 시스템 가용성을 향상시키는 데 도움이 될 수 있습니다. 모니터링 및 로깅 설정시스템이 어떻게 작동하는지를 확인하려면 모니터링 및 로깅을 주요 점검 도구로 사용하세요. 정보의 세분성과 깊이를 적절히 적용하면 모니터링 및 로깅 성능을 위한 적절한 양의 컴퓨팅과 저장용량이 보장됩니다. 모니터링 구성모니터링을 수행하려면 과거 이벤트로부터 올바른 측정항목을 식별하고, 현재 및 미래의 이벤트에 적합한 측정항목을 검토하고, 측정항목 수집/집계/보고가 가능하도록 시스템을 구현해야 합니다. 모니터링 구성의 일환으로 다음 요소를 고려하세요.
대시보드를 사용하여 모니터링 배포관계자 간의 공유 상태를 유지하기 위한 목적으로, 모니터링 대시보드에서 모든 주체가 좀더 세분화된 측정항목 대신 SLO에 초점을 맞추도록 할 수 있습니다. 대시보드에는 다음과 같은 장점이 있습니다.
피드백을 사용하여 운영 및 지원 개선알려진 문서화 가능한 항목은 계획 단계에서 소개되었습니다. 준비 단계에서는 아키텍처 변경, 부하 테스트, 장애 테스트의 피드백으로 해당 문서를 업데이트해야 합니다. 체크리스트 및 플레이북 작성다음의 권장사항을 따라 중요한 체크리스트를 작성합니다.
알려진 문제와 장애 테스트 중에 발견한 공통적인 문제에 대한 플레이북을 개발합니다. 지원 및 에스컬레이션 절차 교육모든 운영팀 구성원이 자신들의 책임과 다른 팀의 책임을 인지하도록 합니다.
모의 연습을 여러 차례 실행하여 대응 시간을 단축하고 이어지는 시뮬레이션을 통해 조율 상태를 개선합니다. 사후 분석을 통해 각 연습의 결과를 캡처하고 계속해서 다음 연습을 개선합니다. 공급업체 지원 조율다른 팀 구성원이나 공급업체 지원팀에 연락하고 세부정보를 전달하는 방법을 확인합니다. 공급업체는 각기 다른 방법으로 지원 절차를 구현하기 때문에 지원 서비스와 가장 효과적으로 상호작용할 수 있는 방법을 숙지하는 것이 중요합니다. 공급업체 SLA에서 지원 응답과 가용성 및 지연 시간 측정항목에 대해 검토하세요. Google Cloud 지원 문의Google Cloud는 Google Cloud 지원을 통해 참여를 최적화하는 방법에 대한 정보를 제공합니다. 공개된 문서는 모든 고객에게 제공됩니다. Google Cloud 고객 엔지니어링에 직접 문의하거나 플래티넘 지원에 등록한 고객은 Google 담당자와 직접 상담하면서 지원 범위를 검토하고 파악할 수 있습니다. 자세한 내용은 이 문서 후반부에서 설명하는 실행 단계 섹션의 Google Cloud 지원을 참조하세요. 운영팀이 성공을 거둘 수 있도록 준비시키기피크 이벤트를 처리하기 위해서는 많은 스트레스를 받고 감정 노동이 격심할 수밖에 없습니다. 운영팀이 완전히 지치는 것을 방지하기 위해 로테이션 프로세스를 마련하세요. 운영팀에 충분한 휴식을 제공하면 실수가 줄어들고 큰 사고가 발생할 경우 추가적인 예비 지원 인력을 제공할 수 있습니다. 다음 사항이 마련되어 있는지 확인하세요.
대다수 운영팀은 문제를 해결하기 위해 '밤샘 작업'을 해본 경험이 있습니다. 그러한 노력 자체는 칭찬해야 하지만 초인적인 능력을 바라는 것보다는 직원을 적절히 로테이션하는 것이 더 낫습니다. 팀 구성원을 교차 교육하여 여러 명의 전문가를 둠으로써 긴장감과 오류율을 줄일 수 있습니다. 용량 요청 조율계획 단계 중에 용량 계획을 Google Cloud 및 다른 공급업체와 공유하고 조율했습니다. 다음은 고려해야 할 몇 가지 추가적인 용량 계획 전략입니다.
변경 금지 설정블랙 프라이데이는 연중 가장 중요한 비즈니스 이벤트 중 하나입니다. 웹 인프라에 상당한 부담이 가해지지만, 기록적인 비즈니스 수익을 거둘 수 있는 기회가 됩니다. 실패의 가장 큰 원인은 변경(예상된 변경 또는 예상치 못한 변경)입니다. 특히 아키텍처 변경은 인프라의 확장 능력에 영향을 줄 수 있으므로 피크 이벤트가 진행 중이거나 임박한 상황에서는 변경을 금지하는 것이 좋습니다. 변경 금지를 설정할 때 다음의 권장사항을 따르세요.
준비 단계 결과물준비 단계에서는 계획 단계 문서를 수정하고 새로운 항목을 개발합니다. 예를 들면 다음과 같습니다.
실행 단계계획 및 준비 단계를 완료했다면 이제 안심하고 블랙 프라이데이에 임하세요. 모든 것이 계획대로 진행된다면 탁월한 운영 지원에 힘입어 피크 이벤트가 순조롭게 흘러갈 것입니다. 운영팀은 모든 사항을 파악하고 대응할 수 있으므로 예상치 못한 이슈란 없습니다. 이슈가 발생하더라도 금방 파악하여 해결할 수 있습니다. 다음 표에서는 실행 단계의 주요 절차를 요약하여 보여줍니다.
최대 용량까지 수동으로 확장자동 확장 시스템은 예상치 못한 급증에 대응하는 데 효과적이지만, 대부분의 경우 트래픽을 5배에서 10배까지 늘리기 위한 기본 확장 프로세스로는 권장되지 않습니다. 자동 확장 시스템은 일반적으로 작은 단위로만 확장됩니다. 주로 평가 주기별로 추가 용량을 위한 VM을 추가합니다. 시스템이 추가 용량을 위해 수십 또는 수백 개의 VM을 빠르게 확장해야 할 경우에는 적절한 범위로 시스템을 수동 확장하는 것이 더 효율적입니다. 시스템이 준비가 되어 있고, 캐시가 예열될 수 있고, 가상 머신 시작 같은 상대적으로 느린 이벤트가 피크 이벤트 시작 전에 이루어질 수 있도록 수동 확장을 사용하여 시스템 용량을 천천히 늘리세요. 이 프로세스는 시스템에서 해당 용량이 가능한지를 확인하는 안전한 방법이기도 합니다. 최대 트래픽까지 확장하는 것이 기본 목표이지만 블랙 프라이데이 후에 규모를 점차 줄일 수 있는 방법도 계획해야 합니다. 정상 트래픽을 위한 원래의 확장 전략이 있는데 트래픽이 아직 정상으로 돌아오지 않은 경우, 너무 빠르게 축소하면 중단이 발생할 수 있습니다. 빠른 복구에 중점을 둔 실행운영팀의 기본 목표는 시스템을 안정적으로 운영하는 것입니다. 엔지니어는 문제에 대한 데이터를 수집하기 위해 아직 문제가 진행 중일 때 근본 원인을 찾는 경향이 있습니다. 근본 원인 분석도 중요하지만 일단은 복구에 집중해야 합니다. 용량을 추가하거나, 성능이 저하된 구성요소를 삭제하거나, 시스템을 다시 시작하는 등 시스템 복구에 최선을 다하는 와중에 기회가 되면 분석을 위해 데이터를 수집하여 저장하세요. 문제가 '왜' 발생했는지는 이슈를 해결한 후에 언제든지 오프라인에서 분석할 수 있습니다. 가상 상황실 설치실행 단계를 책임지는 것은 운영팀이지만 이외에도 여러 사람이 참여합니다. 운영팀은 팀 간 협업 체계를 활용하여 회사의 다른 부서 및 공급업체에 지원을 요청할 수 있습니다. 가상 상황실은 피크 이벤트 중에 모든 관계자가 팀워크를 발휘할 수 있는 공간입니다. 비동기 채팅 시스템이나 이메일 커뮤니케이션에서 발생하는 지연 없이 아이디어를 빠르게 공유할 수 있습니다. 가상 상황실을 통해 각종 상황에 쉽고 빠르게 대처하고 적극적인 참여를 유도하세요. 피크 이벤트 전용의 하위 팀 공간을 만드는 것도 좋습니다. 이러한 하위 공간이 있으면 이슈가 여러 건 발생할 경우 주 상황실에서는 빠른 진단과 위임에 집중할 수 있습니다. 사고 관리 경험 활용적절한 인원이 이슈에 대응할 수 있도록 사고 관리 프로세스에서 장애 테스트, 모의실험, 테스트 실행을 사용하세요. 운영팀이 사고 관리 프로세스에 익숙해지면 전반적인 대응력과 해결 속도가 향상됩니다. 플레이북 실행이슈가 나타나거나, 시스템 알림이 발생하거나, 문제가 신고될 때 플레이북이 있어야 각 팀에서 상황을 빠르게 진단하고 해결법이 있는지를 판단할 수 있습니다. 예기치 못한 문제라도 플레이북의 데이터는 각 팀이 문제를 빠르게 파악하고 해결하는 데 도움이 됩니다. 하지만 플레이북에 내용을 추가하고 건설적인 의견을 수집하는 것이 최우선 과제는 아닙니다. 대신 정보를 메모해 두고 나중에 사후 분석을 통해 플레이북 실행을 검토하세요. Google Cloud 지원팀과 협력Google Cloud 지원팀에 문의할 때는 최대한 구체적으로 설명하고, 명시적으로 언급되지 않은 정보를 추정하지 마세요. 이 접근 방식으로 지원팀은 고객의 관점에서 문제를 바라보고 좀더 효과적으로 조사 범위를 좁힐 수 있습니다. 다음의 네 가지 주요 세부정보에 집중하세요.
지원 요청을 접수하려면 최대한 많은 데이터를 제공하고 엔지니어의 정보 요청에 응해야 합니다. 해결 속도를 높이려면 스크린샷, tcpdump 출력, 로그 파일 스니펫, 기타 모든 요청된 정보를 제공하세요. Google은 다음과 같은 방식으로 문제를 해결합니다.
이 과정을 함께하고 진행 중인 정보를 공유함으로써 사례 해결 속도를 크게 높일 수 있습니다. 데이터 전송 프로세스 개선새로운 주기에서 처음으로 해야 할 일이 데이터 수집이라면 실행 단계에서 마지막으로 해야 할 일은 데이터 전송입니다. 측정항목 및 로그를 프로세스 중에 생성된 다른 결과물과 함께 보존해야 합니다. 그러면 다음 주기를 시작하고 계획 단계를 처음부터 새로 시작하기 위한 견고한 토대가 마련됩니다. 근본 원인 분석 실시근본 원인 분석(RCA)은 장애를 없애면 시스템이 정상적으로 작동할 수 있도록 시스템에서 가장 세밀한 수준까지 장애를 파악하는 데 집중합니다. 데이터 수집 구성요소를 제외하고는 중단 중에 RCA를 즉시 수행하는 것을 권장하지 않습니다. 시스템을 다시 가동하는 동안 이벤트가 발생한 시점과 그 직후에 생성된 데이터를 수집하고 보존하세요. 시스템 복구가 완료되면 시간에 따른 데이터 저하 또는 노력, 강조사항 손실을 방지하기 위해 잠시 후에 RCA를 수행하세요. RCA는 다음을 수행하는 것을 의미합니다.
사고마다 조사 방법이 달라야 합니다. 사고가 겹치는 경우에는 지원팀과 협력하여 인과관계가 있는지를 파악합니다. 근본 원인이 파악되면 미래의 사고를 방지하는 데 도움이 되도록 실행 가능한 활동 목록을 개발합니다. 사고를 완화하고 다시 발생하지 않도록 하는 데 필요한 리소스, 시간, 비용을 파악합니다. 사고로 인해 시스템이 SLO에서 벗어난 경우, 재발 방지를 적절히 예약합니다. 추정치와 실제값을 비교하여 분석이 주기에서 가장 먼저 할 일 중 하나는 이전 이벤트의 데이터를 수집하여 미래의 요구를 예상하기 위한 기초로 삼는 것입니다. 차이와 원인을 파악함으로써 향후 피크 이벤트 계획자에게 도움을 줄 수 있습니다. 비즈니스 측정항목이 SLO에 어떤 영향을 미치는지를 이해하면 시스템 안정성을 높이는 방법을 파악할 수 있습니다. 용량 계획도 검토합니다. 용량이 예상했던 값보다 낮은 영역 때문에 추가 용량이 필요한 사고가 발생했을 수도 있습니다. 사후 분석 및 고찰 종합사후 분석 및 고찰 프로세스를 수행하는 것이 좋습니다. 이 프로세스에서 모든 팀은 발생한 이벤트의 세부정보와 피크 이벤트 동안 고객과 Google 시스템이 어떻게 행동했는지에 대한 정보를 공유합니다. 모든 팀이 이러한 경험을 검토하고 미래의 계획에 반영합니다. 사후 분석 및 고찰 프로세스 중에 다음 정보를 수집하세요.
공로 인정블랙 프라이데이를 성공적으로 관리하는 데 도움을 준 여러 부서의 팀원들에게 감사의 뜻을 전합니다. 팀 전체와 개인의 성과를 치하하고, 헌신적인 노력을 보인 이들에게는 보상을 제공합니다. 팀은 성공을 회상하고 자축하면서 길고 힘들었던 과정에서 소진한 기력을 회복할 수 있습니다. 업무 만족도는 팀의 장기적인 성공에 핵심적인 요소입니다. 업무는 잠시 제쳐두고 특별한 순간을 만끽하면서 축배를 나누세요. 실행 단계 결과물실행 단계 결과물에는 계획, 준비, 실행 단계의 종료와 더불어 무엇보다도 블랙 프라이데이 이벤트의 성공적인 완료가 포함됩니다. 이 단계의 주요 결과물은 다음을 비롯한 데이터 수집 및 분석입니다.
다음 단계이 정도 분량의 자료로 모든 것을 다 설명할 수는 없습니다. 블랙 프라이데이를 앞두거나 진행하는 동안 불안감을 줄이려면 회사의 각 부서 및 Google Cloud팀과 함께 이 문서에서 다루지 않은 상황을 가정하고 의견을 모아보세요. 다음과 같은 주제를 탐구해 볼 수도 있습니다.
|
구현의 성공 여부를 판단할 수 있는 방법 예상되는 성능을 제시
저작권 © 2024 boxhoidap Inc.
