Uber Practice: 대규모 분산 시스템 운영 및 유지 관리 경험

이 기사는 Uber의 엔지니어인 Gergely Orosz가 작성했습니다. 원래 주소는 다음과 같습니다: https://blog.pragmaticengineer.com/operating-a-high-scale-distributed-system/

지난 몇 년 동안. , 저는 대규모 분산 시스템인 Uber의 결제 시스템을 구축하고 운영해 왔습니다. 이 기간 동안 저는 분산 아키텍처 개념에 대해 많은 것을 배웠고 고부하 및 고가용성 시스템을 실행하는 데 따르는 어려움을 직접 목격했습니다. 훨씬 더 크다). 시스템을 구축하는 것 자체는 흥미로운 노력입니다. 시스템이 10배/100배 증가하는 트래픽을 처리하는 방법을 계획하고, 데이터 내구성을 보장하고, 하드웨어 오류를 처리하는 등 모두 지혜가 필요합니다. 그럼에도 불구하고 대규모 분산 시스템을 운영하는 것은 나에게 놀라운 경험이었습니다.

시스템이 커질수록 "잘못될 수 있는 것은 잘못될 것이다"라는 머피의 법칙이 더욱 분명해집니다. 코드를 자주 배포하고 배포하는 개발자가 많고, 여러 데이터 센터가 관련되어 있으며, 전 세계적으로 많은 사용자가 시스템을 사용할수록 이러한 오류가 발생할 가능성이 커집니다. 지난 몇 년 동안 저는 다양한 시스템 오류를 경험했는데 그 중 많은 오류가 저를 놀라게 했습니다. 일부는 하드웨어 오류나 겉보기에 무해해 보이는 버그, 데이터 센터 케이블의 파헤쳐짐, 동시에 발생하는 여러 계단식 오류 등 예측 가능한 것에서 발생합니다. 저는 시스템의 일부가 제대로 작동하지 않아 비즈니스에 막대한 영향을 미치는 수십 번의 비즈니스 중단을 경험했습니다.

이 글은 제가 우버에 근무하면서 대규모 시스템을 효과적으로 운영하고 유지할 수 있는 사례들을 정리한 것입니다. 내 경험은 독특한 것이 아닙니다. 비슷한 규모의 시스템에서 작업하는 사람들은 비슷한 여정을 걸어왔습니다. Google, Facebook, Netflix의 엔지니어들과 이야기를 나누었고 비슷한 경험과 솔루션을 공유했습니다. 여기에 설명된 많은 아이디어와 프로세스는 자체 데이터 센터(대부분의 경우 Uber가 그렇듯이)에서 실행하든 클라우드(Uber는 때때로 서비스의 일부를 클라우드에 탄력적으로 배포함)에서 실행하든 상관없이 유사한 규모의 시스템에 적용되어야 합니다. 그러나 이러한 관행은 더 작거나 덜 중요한 시스템의 경우 너무 가혹할 수 있습니다.

다루어야 할 내용이 많습니다. 다음 주제를 다룰 예정입니다.

• 모니터링
• 근무, 이상 탐지 및 경고
• 결함 및 사고 관리 프로세스
• 사후 분석, 사고 검토 및 지속적인 개선 문화
• 오류 훈련, 용량 계획 및 블랙박스 테스트
• SLO, SLA 및 해당 보고서
• 독립 팀인 SRE
• 지속적인 투자로서의 신뢰성
• 더 많은 추천 자료

모니터링

시스템이 정상인지 확인하려면, "시스템이 제대로 작동하고 있나요?"라고 대답해야 합니다. 이를 위해서는 시스템의 주요 부분에 대한 데이터를 수집하는 것이 중요합니다. 여러 컴퓨터와 데이터 센터에서 여러 서비스가 실행되는 분산 시스템의 경우 모니터링해야 할 핵심 사항이 무엇인지 결정하기 어려울 수 있습니다.

인프라 상태 모니터링 하나 이상의 컴퓨터/가상 머신이 과부하되면 분산 시스템의 일부 부분이 저하될 수 있습니다. 머신의 상태, CPU 사용률, 메모리 사용량은 모니터링할 가치가 있는 기본 내용입니다. 일부 플랫폼에서는 이러한 모니터링 및 자동 크기 조정 인스턴스를 즉시 처리할 수 있습니다. Uber에는 인프라 모니터링과 즉시 알림을 제공하는 탁월한 핵심 인프라 팀이 있습니다. 기술적인 차원에서 어떻게 구현하든, 인스턴스나 인프라에 문제가 있을 경우 모니터링 플랫폼은 필요한 정보를 제공해야 합니다.

서비스 상태 모니터링: 트래픽, 오류, 대기 시간. 우리는 종종 "이 백엔드 서비스가 정상인가요?"라는 질문에 대답해야 합니다. 요청 트래픽, 오류율, 엔드포인트에 액세스하는 엔드포인트 대기 시간 등을 관찰하면 서비스 상태에 대한 귀중한 정보를 얻을 수 있습니다. 나는 이 모든 것이 대시보드에 표시되는 것을 선호합니다. 새로운 서비스를 구축할 때 올바른 HTTP 응답 매핑을 사용하고 관련 코드를 모니터링하면 시스템에 대해 많은 것을 배울 수 있습니다. 따라서 클라이언트 오류 시 4XX가 반환되고 서버 오류 시 5xx가 반환되도록 하는 것은 구축하기 쉽고 해석하기 쉽습니다.

지연 시간 모니터링은 다시 생각해 볼 가치가 있습니다. 프로덕션 서비스의 목표는 대다수의 최종 사용자가 좋은 경험을 하는 것입니다. 평균 대기 시간을 측정하는 것은 매우 좋은 지표가 아닌 것으로 나타났습니다. 왜냐하면 이 평균은 대기 시간이 높은 요청의 작은 비율을 숨길 수 있기 때문입니다. p95, p99 또는 p999(95번째, 99번째 또는 99.9번째 백분위수 요청에서 발생하는 대기 시간)를 측정하는 것이 더 나은 지표입니다. 이 수치는 "사람들의 요청 중 99%가 얼마나 빠른가요?"(p99)와 같은 질문에 답하는 데 도움이 됩니다. 또는 "1,000명 중 1명 이상이 지연을 얼마나 느리게 경험합니까?"(p999). 이 주제에 더 관심이 있는 분들을 위해 이 지연된 입문서 기사에서 추가 자료를 제공합니다.

평균 지연 시간인 p95와 p99의 차이가 상당히 크다는 것을 그림에서 확실히 알 수 있습니다. 따라서 평균 대기 시간은 일부 문제를 가릴 수 있습니다.

모니터링 및 관찰 가능성에 대한 심층적인 콘텐츠가 훨씬 더 많습니다. 읽어볼만한 두 가지 리소스는 Google의 SRE 서적과 분산 시스템 모니터링의 4가지 황금 지표 섹션입니다. 사용자 대면 시스템에 대해 4가지 측정항목만 측정할 수 있는 경우 트래픽, 오류, 대기 시간 및 포화도에 집중할 것을 권장합니다. 더 짧은 자료를 보려면 이벤트 로깅, 메트릭, 추적 모범 사례와 같은 기타 유용한 도구를 다루는 Cindy Sridharan의 Distributed Systems Observability e-Book을 추천합니다.

비즈니스 지표 모니터링. 서비스 모듈을 모니터링하면 서비스 모듈이 어떻게 정상적으로 실행되고 있는지 알 수 있지만 비즈니스가 예상대로 작동하는지, "평소대로 비즈니스"인지는 알 수 없습니다. 결제 시스템에서 중요한 질문은 "사람들이 특정 결제 수단을 사용하여 결제할 수 있는가?"입니다. 비즈니스 이벤트를 식별하고 모니터링하는 것은 가장 중요한 모니터링 단계 중 하나입니다.

다양한 모니터링을 구축했지만 일부 비즈니스 문제를 감지할 수 없어 큰 어려움을 겪었고 마침내 비즈니스 지표에 대한 모니터링을 구축했습니다. 때로는 모든 서비스가 정상적으로 실행되는 것처럼 보이지만 주요 제품 기능을 사용할 수 없는 경우도 있습니다. 이런 종류의 모니터링은 우리 조직과 현장에 매우 유용합니다. 따라서 우리는 Uber의 가시성 기술 스택을 기반으로 이러한 유형의 모니터링을 직접 맞춤화하기 위해 많은 생각과 노력을 기울여야 했습니다.

번역자 주: 비즈니스 지표 모니터링에 대해 우리는 정말로 같은 느낌을 받았습니다. 과거 Didi에서는 모든 서비스가 정상적이지만 비즈니스가 제대로 작동하지 않는 것을 발견했습니다. 현재 우리가 사업을 시작하기 위해 구축하고 있는 Polaris 시스템은 이러한 문제를 해결하기 위해 특별히 설계되었습니다. 관심 있는 친구들은 공식 계정 백그라운드에서 나에게 메시지를 남겨주거나, 내 친구 피코바이트를 추가해 소통하고 사용해 볼 수도 있다.

통화 중, 이상 탐지 및 경고

모니터링은 시스템의 현재 상태에 대한 통찰력을 얻을 수 있는 훌륭한 도구입니다. 그러나 이는 문제를 자동으로 감지하고 사람들이 조치를 취할 수 있도록 경고를 발생시키는 디딤돌일 뿐입니다.

Oncall 자체는 광범위한 주제입니다. Increment Magazine은 "On-Call 이슈"에서 다양한 측면을 다룹니다. 내 강력한 의견은 "당신이 만들면 당신이 그것을 소유한다"는 사고방식을 갖고 있다면 OnCall이 따를 것이라는 것입니다. 서비스를 구축하는 팀은 해당 서비스를 소유하고 서비스 호출을 담당합니다. 우리 팀은 결제 서비스를 담당하고 있습니다. 따라서 알람이 발생할 때마다 담당 엔지니어가 응답하고 세부 사항을 검토합니다. 하지만 모니터링에서 알림으로 어떻게 이동합니까?

감시 데이터에서 이상 징후를 탐지하는 것은 어려운 과제이며 머신러닝이 빛을 발할 수 있는 영역입니다. 이상 탐지를 제공하는 많은 타사 서비스가 있습니다. 다행스럽게도 우리 팀에는 협력할 수 있는 사내 기계 학습 팀이 있었고 그들은 Uber의 사용 방식에 맞게 솔루션을 맞춤화했습니다. 뉴욕에 본사를 둔 Observability 팀은 Uber의 이상 감지 작동 방식을 설명하는 유용한 기사를 작성했습니다. 우리 팀의 관점에서는 모니터링 데이터를 해당 팀의 파이프라인에 푸시하고 각각의 신뢰도 수준에 따라 알림을 받습니다. 그런 다음 엔지니어를 불러야 할지 결정합니다.

언제 알람을 울리는지는 흥미로운 질문입니다. 경고가 너무 적으면 영향을 미치는 중단을 놓칠 수 있습니다. 너무 많으면 잠 못 이루는 밤과 피로로 이어질 수 있습니다. 경보를 추적 및 분류하고 신호 대 잡음비를 측정하는 것은 경보 시스템을 조정하는 데 매우 중요합니다. 경고를 검토하고 실행 가능한 것으로 플래그를 지정한 다음 실행 불가능한 경고를 줄이기 위한 조치를 취하는 것은 지속 가능한 통화 순환을 달성하기 위한 좋은 단계입니다.

빌니우스의 Uber 개발자 경험팀이 구축한 Uber 내부 대기 대시보드의 예입니다.

빌니우스의 Uber 개발 도구 팀은 알림에 주석을 달고 통화 교대를 시각화하는 데 사용하는 깔끔한 통화 도구를 만들었습니다. 우리 팀은 매주 마지막 통화 교대조를 검토하고 문제점을 분석하며 매주 통화 경험을 개선하는 데 시간을 보냅니다.

번역가의 메모: 알람 이벤트 집계, 소음 감소, 예약, 청구, 업그레이드, 협업, 유연한 푸시 전략, 다중 채널 푸시 및 IM 연결은 매우 일반적인 요구 사항입니다. FlashDuty 제품을 참조하여 경험해 보세요. : https://console.flashcat.cloud/

결함 및 사고 관리 프로세스

이것을 상상해 보십시오: 당신은 이번 주 근무 엔지니어입니다. 한밤중에 알람이 당신을 깨워줍니다. 생산 중단이 발생했는지 조사합니다. 이런, 시스템 일부에 문제가 있는 것 같습니다. 우리는 지금 무엇을해야합니까? 모니터링 및 경고가 실제로 발생합니다.

소규모 시스템의 경우 가동 중단은 큰 문제가 아닐 수 있으며 담당 엔지니어는 무슨 일이 일어나고 있고 왜 일어나는지 이해할 수 있습니다. 일반적으로 이해하기 쉽고 완화하기 쉽습니다. 여러 (마이크로) 서비스가 포함된 복잡한 시스템과 많은 엔지니어가 코드를 프로덕션에 적용하는 경우 잠재적인 문제가 발생할 위치를 정확히 찾아내는 것만으로도 충분히 어려울 수 있습니다. 이 문제를 해결하는 데 도움이 되는 몇 가지 표준 프로세스를 갖추면 큰 차이를 만들 수 있습니다.

1차 방어선으로 간단한 완화 단계를 설명하는 경고에 첨부된 실행서입니다. 좋은 런북을 갖춘 팀의 경우 담당 엔지니어가 시스템에 대해 깊이 이해하지 못하더라도 문제가 되는 경우는 거의 없습니다. Runbook은 최신 상태로 유지되고, 업데이트되어야 하며, 오류 발생 시 오류를 처리하기 위해 새로운 완화 방법을 사용해야 합니다.

번역자 참고사항: Nightingale 및 Grafana의 알람 규칙 구성은 사용자 정의 필드를 지원할 수 있지만 RunbookUrl과 같은 일부 추가 필드가 기본적으로 제공됩니다. 핵심은 SOP 매뉴얼의 중요성을 전달하는 것입니다. 또한 안정성 관리 시스템에서는 알람 규칙에 RunbookUrl이 사전 설정되어 있는지 여부가 알람 상태를 나타내는 매우 중요한 지표입니다.

서비스를 배포하는 팀이 여러 개 있으면 조직 전체의 잘못된 의사소통이 중요해집니다. 저는 수천 명의 엔지니어가 자신의 재량에 따라 개발한 서비스를 프로덕션에 배포하는 환경에서 일하고 있습니다. 시간당 수백 건의 배포가 가능할 수도 있습니다. 겉보기에는 관련이 없어 보이는 서비스 배포가 다른 서비스에 영향을 미칠 수 있습니다. 이 경우 표준화된 오류 방송 및 통신 채널이 큰 도움이 될 수 있습니다. 나는 여러 가지 희귀한 경고 메시지를 접했고 다른 팀의 사람들도 비슷한 이상한 현상을 보고 있다는 것을 깨달았습니다. 중단을 처리하기 위해 중앙 집중식 채팅 그룹에 참여함으로써 중단을 일으키는 서비스를 신속하게 식별하고 문제를 해결했습니다. 우리는 한 사람이 할 수 있는 것보다 더 빨리 일을 해냈습니다.

지금은 안심하고 내일 조사해 보세요. 고장이 나는 동안 나는 종종 잘못된 것을 고치고 싶은 "아드레날린이 솟구치는" 느낌을 받습니다. 근본 원인은 잘못된 코드 배포와 코드 변경에 명백한 버그가 있는 경우가 많습니다. 과거에는 코드 변경 사항을 롤백하는 대신 바로 버그를 수정하고 수정 사항을 푸시한 다음 버그를 닫았습니다. 그러나 장애 발생 시 근본 원인을 해결하는 것은 끔찍한 생각입니다. 순방향 복원을 사용하면 이득이 거의 없고 손실이 많습니다. 새로운 수정 사항은 신속하게 수행해야 하므로 프로덕션 환경에서 테스트해야 합니다. 이것이 두 번째 오류(또는 기존 오류에 추가되는 결함)가 발생하는 이유입니다. 나는 이와 같은 결함이 계속해서 악화되는 것을 보았습니다. 먼저 완화에 집중하고 근본 원인을 해결하거나 조사하려는 충동을 억제하십시오. 적절한 조사는 다음 영업일까지 기다릴 수 있습니다.

번역가의 메모: 베테랑 드라이버도 이 점을 깊이 인식해야 합니다. 문제가 발생하면 문제를 해결하기 위해 핫픽스 버전을 출시하려고 시도하는 대신 즉시 롤백하세요.

사후 분석, 사건 검토 및 지속적인 개선 문화

팀이 실패의 여파를 처리하는 방법에 관한 것입니다. 그들은 계속 일할 것인가? 그들은 작은 설문조사를 할 것인가? 시스템 수준의 문제를 해결하기 위해 제품 작업을 중단하면서 앞으로 엄청난 노력을 들일까요?

올바른 사후 분석은 강력한 시스템 구축의 초석입니다. 좋은 사후 조사는 비난이 없고 철저합니다. Uber의 사후 분석 템플릿은 엔지니어링 기술과 함께 지속적으로 발전하고 있으며 사고 개요, 영향 개요, 타임라인, 근본 원인 분석, 학습한 내용, 상세한 후속 체크리스트 등의 섹션을 포함합니다.

이것은 제가 Uber에서 사용하는 것과 유사한 리뷰 템플릿입니다.

훌륭한 사후 분석은 근본 원인을 깊이 파고들어 유사한 모든 오류를 더 빠르게 예방, 감지 또는 완화할 수 있는 개선 사항을 제안합니다. 내가 더 깊이 파고든다는 것은 그들이 잘못된 코드 변경과 코드 검토자가 버그를 잡아내지 못하는 근본 원인에서 멈추지 않는다는 것을 의미합니다.

그들은 '5why' 탐색 방법을 사용하여 더 깊이 파고들어 더 의미 있는 결론에 도달합니다. 예:

• 이 문제는 왜 발생하나요? –> 코드에 버그가 도입되었기 때문입니다.
• 왜 다른 사람은 이 버그를 발견하지 못했나요? –> 코드 검토자가 눈치 채지 못한 코드 변경으로 인해 이러한 문제가 발생할 수 있습니다.
• 이 오류를 파악하기 위해 코드 검토자에게만 의존하는 이유는 무엇입니까? –> 이 사용 사례에 대한 자동화된 테스트가 없기 때문입니다.
• "이 사용 사례에 대해 자동화된 테스트를 수행하는 것은 어떨까요?" –> 테스트 계정 없이는 테스트가 어렵기 때문입니다.
• 테스트 계정이 왜 없나요? –> 시스템에서 아직 지원하지 않기 때문입니다
• 결론: 이 문제는 테스트 계정이 부족한 시스템적인 문제를 나타냅니다. 테스트 계정 지원을 시스템에 추가하는 것이 좋습니다. 다음으로, 향후의 모든 유사한 코드 변경에 대해 자동화된 테스트를 작성합니다.

이벤트 검토는 이벤트 후 분석을 위한 중요한 지원 도구입니다. 많은 팀이 사후 분석을 철저하게 수행하는 반면, 다른 팀은 예방적 개선을 위한 추가 입력 및 과제를 통해 이점을 얻을 수 있습니다. 또한 팀이 제안한 시스템 수준 개선 사항을 구현하기 위해 책임감과 권한을 느끼는 것도 중요합니다.

신뢰성을 중요하게 생각하는 조직의 경우 숙련된 엔지니어가 가장 심각한 실패를 검토하고 문제를 제기합니다. 수리를 완료할 수 있는 권한을 제공하기 위해 조직 수준의 엔지니어링 관리도 있어야 합니다. 특히 이러한 수리가 시간이 많이 걸리고 다른 작업을 방해하는 경우에는 더욱 그렇습니다. 강력한 시스템은 하루아침에 만들어지지 않습니다. 지속적인 반복을 통해 구축됩니다. 어떻게 계속 반복할 수 있나요? 이를 위해서는 조직 차원에서 지속적인 개선과 실패로부터 학습하는 문화가 필요합니다.

실패 훈련, 용량 계획 및 블랙박스 테스트

상당한 투자가 필요하지만 대규모 분산 시스템을 계속 실행하는 데 중요한 몇 가지 일상적인 활동이 있습니다. 이는 제가 Uber에서 처음 접한 개념입니다. 이전 회사에서는 규모와 인프라로 인해 이러한 개념을 사용할 필요가 없었습니다.

데이터 센터 장애 훈련은 몇 가지 실제 사례를 관찰하기 전까지는 지루하다고 생각했습니다. 나의 초기 생각은 강력한 분산 시스템을 설계하는 것이 데이터 센터 붕괴 시 복원력을 유지할 수 있다는 것이었습니다. 이론적으로 잘 작동한다면 왜 그렇게 자주 테스트합니까? 대답은 규모와 서비스가 새로운 데이터 센터의 갑작스러운 트래픽 증가를 효과적으로 처리할 수 있는지 여부를 테스트해야 하는 필요성과 관련이 있습니다.

제가 관찰한 가장 일반적인 실패 시나리오는 장애 조치가 발생하고 새 데이터 센터의 서비스에 글로벌 트래픽을 처리할 리소스가 충분하지 않은 경우입니다. ServiceA와 ServiceB가 각각 두 개의 데이터 센터에서 실행되고 있다고 가정합니다. 각 데이터 센터에서 수십 또는 수백 개의 가상 머신이 실행되고 리소스 활용도가 60%라고 가정하고 70%에서 트리거되도록 경보를 설정합니다. 이제 장애 조치를 수행하고 DataCenterA에서 DataCenterB로 모든 트래픽을 리디렉션해 보겠습니다. 새 시스템을 프로비저닝하지 않으면 DataCenterB가 갑자기 로드를 처리할 수 없게 됩니다. 새 시스템을 프로비저닝하는 데는 요청이 쌓이고 삭제되기 시작할 만큼 오랜 시간이 걸릴 수 있습니다. 이러한 차단은 다른 서비스에 영향을 미치기 시작하여 이 장애 조치의 일부가 아닌 다른 시스템에 연속적인 오류를 일으킬 수 있습니다.

다른 일반적인 실패 시나리오에는 라우팅 수준 문제, 네트워크 용량 문제 또는 역압 문제가 포함됩니다. 데이터 센터 장애 조치는 신뢰할 수 있는 분산 시스템이 사용자에게 영향을 주지 않고 수행할 수 있어야 하는 작업입니다. 저는 "해야 한다"는 점을 강조합니다. 이 연습은 분산 시스템의 안정성을 테스트하는 데 가장 유용한 연습 중 하나입니다.

번역자 주: 교통 차단은 계획의 "3개 축" 중 하나입니다. 문제가 발생했을 때 계획이 실행 가능한지 확인하려면 훈련이 필수입니다. 주의하세요, 여러분.

계획된 서비스 가동 중지 시간 연습은 전체 시스템의 복원력을 테스트하는 훌륭한 방법입니다. 이는 또한 특정 시스템의 숨겨진 종속성이나 부적절하거나 의도하지 않은 사용을 발견할 수 있는 좋은 방법입니다. 이 연습은 의존성이 거의 없는 고객 대면 서비스에서는 비교적 쉽게 수행할 수 있지만, 고가용성이 필요하거나 다른 많은 시스템에서 의존하는 중요한 시스템에서는 쉽지 않습니다. 하지만 어느 날 이 중요한 시스템을 사용할 수 없게 되면 어떻게 될까요? 모든 팀이 예상치 못한 중단을 인지하고 대비하는 통제된 훈련을 통해 답변을 검증하는 것이 가장 좋습니다.

블랙박스 테스트는 최종 사용자가 보는 조건에 최대한 가깝게 시스템의 정확성을 측정하는 방법입니다. 이러한 유형의 테스트는 엔드 투 엔드 테스트와 유사하지만 대부분의 제품에서 적절한 블랙박스 테스트를 위해서는 별도의 투자가 필요합니다. 주요 사용자 프로세스와 가장 일반적인 사용자 대상 테스트 시나리오는 우수한 블랙박스 테스트 가능성의 예입니다. 즉, 시스템이 제대로 작동하는지 확인하기 위해 언제든지 트리거될 수 있는 방식으로 설정됩니다.

Uber를 예로 들면, 당연한 블랙박스 테스트는 승객-운전자 프로세스가 도시 수준에서 제대로 작동하는지 확인하는 것입니다. 즉, 특정 도시 내의 승객이 우버를 요청하고, 운전사와 협력하여 탑승을 완료할 수 있나요? 이 상황이 자동화되면 이 테스트를 주기적으로 실행하여 다양한 도시를 시뮬레이션할 수 있습니다. 강력한 블랙박스 테스트 시스템을 사용하면 시스템이나 시스템의 일부가 올바르게 작동하는지 더 쉽게 확인할 수 있습니다. 장애 조치 훈련에도 매우 유용합니다. 장애 조치 피드백을 얻는 가장 빠른 방법은 블랙박스 테스트를 실행하는 것입니다.

위 그림은 페일오버 드릴이 실패하고 드릴 몇 분 후 수동으로 롤백할 때 블랙박스 테스트를 사용하는 예입니다.

대규모 분산 시스템에서는 용량 계획도 똑같이 중요합니다. 크게 보면 컴퓨팅 및 스토리지 비용이 한 달에 수만 달러 또는 수십만 달러에 이른다. 이 규모에서는 고정된 수의 배포를 사용하는 것이 자동 크기 조정 클라우드 솔루션을 사용하는 것보다 저렴할 수 있습니다. 최소한 고정 배포는 "평상시 업무" 트래픽을 처리하고 최대 부하 중에 자동으로 확장되어야 합니다. 하지만 다음 달, 다음 3개월, 내년에 실행해야 하는 최소 인스턴스 수는 몇 개입니까?

좋은 과거 데이터를 갖춘 성숙한 시스템의 미래 트래픽 패턴을 예측하는 것은 어렵지 않습니다. 이는 예산 책정, 공급업체 선택, 클라우드 제공업체 할인 확보에 중요합니다. 서비스 비용이 비싸고 용량 계획을 고려하지 않는다면 비용을 절감하고 제어할 수 있는 간단한 방법을 놓치게 됩니다.

SLO, SLA 및 관련 보고서

SLO는 서비스 수준 목표(Service Level Objective), 즉 시스템 가용성에 대한 수치 목표를 나타냅니다. 각 개별 서비스에 대해 서비스 수준 SLO(예: 용량, 대기 시간, 정확성, 가용성 목표)를 정의하는 것이 좋습니다. 그런 다음 이러한 SLO는 알림의 트리거 역할을 할 수 있습니다. 서비스 수준 SLO 예는 다음과 같습니다.

SLO Metric	Subcategory	Value for Service
용량	최소 처리량	500 요청/초
	최대 예상 처리량	2,500 요청/초
대기 시간	예상 중간 응답 시간	50-90ms
	예상 p99 응답 시간	500-800ms
정확도	최대 오류율	0.5%
가용성	가동 시간 보장	99.9%

비즈니스 수준 SLO 또는 기능적 SLO는 서비스 위에 있는 추상화입니다. 사용자 또는 비즈니스 중심 측정항목을 다룹니다. 예를 들어 비즈니스 수준 SLO는 다음과 같습니다. 이메일 영수증의 99.99%가 이동 완료 후 1분 이내에 전송될 것으로 예상합니다. 이 SLO는 서비스 수준 SLO(예: 결제 및 이메일 수신 시스템의 지연 시간)에 매핑될 수도 있고 다르게 측정해야 할 수도 있습니다.

SLA(서비스 수준 계약)는 서비스 제공자와 서비스 소비자 간의 광범위한 계약입니다. 일반적으로 여러 SLO가 SLA를 구성합니다. 예를 들어 99.99% 사용 가능한 결제 시스템은 각 지원 시스템에 대한 특정 SLO로 분류된 SLA일 수 있습니다.

SLO를 정의한 후 다음 단계는 이를 측정하고 보고하는 것입니다. SLA 및 SLO에 대한 모니터링 및 보고 자동화는 엔지니어링 팀과 사업부 모두에서 우선순위를 낮추는 경향이 있는 복잡한 프로젝트인 경우가 많습니다. 엔지니어링 팀은 실시간으로 오류를 감지하기 위한 다양한 수준의 모니터링을 이미 갖추고 있으므로 관심이 덜할 수 있습니다. 반면, 사업부는 즉각적인 비즈니스 영향이 없는 복잡한 프로젝트에 투자하기보다는 기능 제공에 집중하는 것을 선호합니다.

다음 주제로 넘어가겠습니다. 조만간 대규모 분산 시스템을 운영하는 조직은 이러한 시스템의 안정성을 전담하는 인력을 투입해야 할 것입니다. 웹사이트 안정성 엔지니어링 팀에 대해 이야기해 보겠습니다.

SRE 독립된 팀

사이트 안정성 엔지니어링(Site Reliability Engineering)은 Google에서 시작되어 2003년경에 시작되어 현재 1,500명 이상의 SRE 엔지니어로 구성된 팀으로 성장했습니다. 생산 환경 운영이 더욱 복잡해지고 더 많은 자동화가 필요해짐에 따라 이 작업은 빠르게 정규직이 될 수 있습니다. 회사가 생산 자동화에 정규직으로 일하는 엔지니어가 있다는 것을 깨닫는 데 걸리는 시간은 다양합니다. 이러한 시스템이 더 중요하고 오류가 발생하기 쉬울수록 이러한 일이 더 일찍 발생합니다.

빠르게 성장하는 기술 회사는 초기에 SRE 팀을 구성하고 자체 로드맵을 개발하도록 하는 경우가 많습니다. Uber에서 SRE 팀은 시간이 지남에 따라 시스템 복잡성을 관리한다는 사명을 가지고 2015년에 설립되었습니다. 다른 회사에서는 전용 인프라 팀을 만들면서 동시에 이러한 팀을 시작할 수도 있습니다. 팀 전체의 안정성 작업이 엔지니어의 시간을 많이 차지할 정도로 회사가 성장하면 이를 위한 전담 팀을 만들어야 할 때입니다.

SRE 팀과 함께 이 팀을 사용하면 모든 엔지니어가 대규모 분산 시스템의 운영 측면을 더 쉽게 유지할 수 있습니다. SRE 팀에는 표준 모니터링 및 경고 도구가 있을 수 있습니다. 그들은 통화 도구를 구매하거나 구축할 수 있으며 통화 모범 사례를 위한 Goto 팀이 될 수 있습니다. 오류 검토를 용이하게 하고 오류를 보다 쉽게 ​​감지, 완화 및 방지할 수 있는 시스템을 구축할 수 있습니다. 장애 조치 훈련에 확실히 도움이 되고, 종종 블랙박스 테스트를 촉진하며, 용량 계획에 참여합니다. SLO를 정의 및 측정하고 이에 대해 보고하기 위한 표준 도구의 선택, 맞춤화 또는 구축을 주도합니다.

회사들이 SRE를 통해 해결하고자 하는 문제점이 서로 다르기 때문에 SRE 조직은 회사마다 다릅니다. 이 팀의 이름도 종종 다양합니다. 운영, 플랫폼 엔지니어링 또는 인프라라고 불릴 수 있습니다. Google은 무료로 제공되며 SRE에 대해 자세히 알아볼 수 있는 좋은 방법인 사이트 안정성에 관해 꼭 읽어야 할 두 권의 책을 출판했습니다.

지속적인 투자로서의 신뢰성

모든 제품을 만들 때 첫 번째 버전을 만드는 것은 시작에 불과합니다. v1 이후에는 향후 반복에 새로운 기능이 추가될 예정입니다. 제품이 성공하고 비즈니스 결과를 제공하면 작업은 계속됩니다.

분산 시스템은 비슷한 수명 주기를 가지고 있습니다. 단지 새로운 기능뿐만 아니라 확장을 따라잡기 위해 더 많은 투자가 필요하다는 점입니다. 시스템이 더 많은 로드를 받고, 더 많은 데이터를 저장하고, 더 많은 엔지니어가 작업하게 되면서 원활하게 실행하려면 지속적인 주의가 필요합니다. 분산 시스템을 처음 구축할 때 많은 사람들은 시스템을 자동차와 같다고 생각합니다. 일단 구축되면 몇 달에 한 번씩 필요한 유지 관리만 하면 됩니다. 그러나 이러한 비교는 현실과 거리가 멀다.

저는 분산 시스템을 운영하는 노력을 병원과 같은 대규모 조직을 운영하는 것에 비유하는 것을 좋아합니다. 병원이 제대로 기능하는지 확인하기 위해서는 지속적인 검증과 점검(모니터링, 경보, 블랙박스 테스트)이 필요합니다. 새로운 직원과 장비는 지속적으로 추가됩니다. 병원의 경우 간호사, 의사 등의 직원과 분산 시스템의 경우 새로운 의료 장비로, 새로운 엔지니어를 모집하고 새로운 서비스를 추가합니다. 사람과 서비스의 수가 늘어남에 따라 예전 방식의 업무 방식은 비효율적이 됩니다. 마치 시골의 작은 진료소가 대도시의 큰 병원과 다른 것처럼 말입니다. 보다 효율적인 방법을 찾는 것이 정규직이 되고 효율성을 측정하고 보고하는 것이 중요해집니다. 대형 병원에 재무, 인사, 보안 등 지원 성격의 사무 직원이 있는 것처럼 대규모 분산 시스템을 운영하는 것도 인프라, SRE 등 지원 팀에 의존합니다.

팀이 안정적인 분산 시스템을 실행하려면 조직은 이러한 시스템과 시스템이 구축된 플랫폼의 운영에 지속적으로 투자해야 합니다.

위 내용은 Uber Practice: 대규모 분산 시스템 운영 및 유지 관리 경험의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!