클라우드든 온프레미스든: SRE가 서비스 아래에서 점검하는 것

인프라 공급자는 어떤 서비스에게든 가장 큰 단일 의존성이고, SRE는 그것을 다른 모든 의존성과 똑같이 다룬다. 실제로 무엇을 약속하는지 읽고, 어디가 함께 죽는지 지도를 그리고, 응답하지 않을 때 무슨 일이 일어나는지 확인한다. 공급자가 AWS든 두 층 아래에서 랙을 돌리는 플랫폼 팀이든 마찬가지다. 질문은 양쪽에서 동일하고, 바뀌는 것은 누가 답하느냐다. 클라우드에서는 공급자가 답하고 당신이 검증한다. 온프레미스에서는 당신이 답하고, 당신을 검증해 줄 사람은 없다. 이 글은 여섯 영역의 체크리스트다. 약속, 장애 도메인, 컨트롤 플레인, 한계, 용량, 유지보수.

이 글은 Budget for Failure 시리즈의 4부이자 두 번째 201 수준 부이며, 시리즈의 마지막이다. 1부는 역할을 정의했고, 2부는 거기에 숫자를 줬으며, 3부는 그것을 애플리케이션 코드 안으로 가져갔다. 이 부는 코드 아래로 내려간다.

1. 약속: 의존성이 SLO의 상한을 정한다

2부는 AWS SLA 네 개가 무엇을 약속하는지 나열했다. 이제 대부분의 아키텍처 리뷰가 건너뛰는 산술을 하자. 로드 밸런서, 컴퓨트 계층, 데이터베이스, 객체 스토리지를 반드시 거쳐야 하는 요청은 넷 모두가 성공할 때만 성공한다. 장애들이 독립적이라면 가용성은 곱해진다.

ALB (multi-AZ)      0.9999
EC2 (multi-AZ)      0.9999
RDS (Multi-AZ)      0.9995
S3 Standard         0.9990
------------------------------
product             0.9983   =  99.83%
allowed downtime    about 73 minutes in 30 days

당신의 코드가 예외 하나를 던지기도 전에, 이 스택 아래의 계약상 바닥은 99.83퍼센트다. AWS는 보통 SLA 바닥보다 훨씬 위에서 운영되므로 실질적인 수치는 더 좋지만, 결론은 그대로다. 99.9를 약속하는 하드 의존성 위에 99.99퍼센트를 약속할 수는 없다. 약속을 낮추거나, 3부에서처럼 캐시, 큐, 폴백으로 그 의존성을 소프트하게 만들어야 한다.

온프레미스에는 곱할 SLA 문서가 없으므로, 같은 표를 자신의 이력으로 만든다. 스토리지 어레이, 하이퍼바이저 클러스터, 코어 네트워크, 전원의 측정된 가용성. 아무도 그 숫자를 갖고 있지 않다면, 그것이 리뷰의 첫 번째 발견 사항이다.

2. 장애 도메인: 무엇이 함께 죽는가

곱셈은 독립성을 가정한다. 장애 도메인은 장애 원인을 공유하는 것들의 집합이고, SRE의 일은 그것을 알고 복제본을 도메인에 걸쳐 배치하는 것이다.

수준	클라우드	온프레미스
최소 단위	인스턴스, 기반 호스트	서버, 디스크 셸프
공유 하드웨어	배치 그룹, 랙(기본적으로 보이지 않음)	랙, top-of-rack 스위치, PDU
시설	가용 영역	전원 피드, 냉각 구역, 데이터 홀
사이트	리전	데이터센터, 캠퍼스, 메트로
사이트 위	글로벌 서비스, 계정, 공급자 자체	통신사, DNS 등록기관, ID 공급자

어느 쪽이든 세 가지 점검이 적용된다. 각 상태 저장 시스템의 복제본이 정말 서로 다른 도메인에 있는가, 아니면 쿼럼의 노드 셋이 한 존이나 한 랙에 앉아 있는가? 단일 홈 자원이 다중 홈 자원의 경로에 끼어 있지 않은가, 예를 들어 세 존을 섬기는 NAT 게이트웨이 하나, 또는 같은 전원 피드 위의 "이중화된" 스위치 두 대처럼? 그리고 살아남기로 계획한 가장 큰 도메인이 사라진 뒤, 남은 용량이 전체 부하를 감당하기에 충분한가? 세 존으로 존 하나의 상실을 버틴다는 것은 각 존을 3분의 2 이하로 돌린다는 뜻이다.

Nothing Fails Alone 시리즈는 정확히 이것을 다룬 네 건의 실제 사건이고, AWS 계정에서 단일 존 집중을 찾아내는 read-only 스크립트를 포함한다.

3. 컨트롤 플레인과 데이터 플레인

모든 플랫폼에는 두 반쪽이 있다. 데이터 플레인은 일을 한다. 인스턴스가 돌고, 로드 밸런서가 전달하고, DNS가 응답한다. 컨트롤 플레인은 상태를 바꾼다. 인스턴스를 시작하고, 경로를 수정하고, 그룹을 스케일한다. 컨트롤 플레인은 더 복잡하고 더 자주 실패하며, 큰 사건 중에 실패하는 경향이 있다. 바로 복구 계획이 그것을 쓰고 싶어 하는 순간이다.

그래서 각 복구 절차에 대한 질문은 성공하는 데 컨트롤 플레인 호출이 필요한가이다. 용량이 이미 다른 곳에서 돌고 있어서 존 상실을 버티는 설계는 정적으로 안정적이다. 오토스케일링이 대체 인스턴스를 띄워 줄 것이라서 버티는 설계는 다른 모든 고객이 호출하는 바로 그 순간의 EC2 컨트롤 플레인에 의존한다. Amazon Builders' Library의 정적 안정성 글이 참고 자료다.

온프레미스에도 같은 분리가 다른 이름으로 존재한다. Kubernetes API 서버, vCenter, IPAM과 DNS 자동화, 모든 로그인과 모든 서비스 토큰이 의존하는 ID 공급자. 각각이 다운됐을 때 무엇이 여전히 동작하는지, 그리고 장애를 고치는 데 쓰는 도구(VPN, 배스천, 배포 파이프라인, 채팅 시스템)가 고쳐야 할 바로 그 인프라 위에서 돌고 있지 않은지 물어라.

4. 한계: 쿼터처럼 보이는 장애

1부의 골든 시그널 중 포화에는 호스트 메트릭이 결코 보여주지 않는 공급자 쪽 형태가 있다. AWS에서 포스트모템에 등장하는 한계는 CPU인 경우가 드물다.

서비스 쿼터. 인스턴스 패밀리당 실행 중인 On-Demand vCPU, 계정당 Lambda 동시 실행 수, Elastic IP, 보안 그룹당 규칙 수. 쿼터에 부딪히는 스케일아웃은 최악의 순간에 실패한다.
API 레이트 리밋. 컨트롤 플레인 API는 계정과 리전 단위로 스로틀링한다. 배포 도구, 오토스케일러, 모니터링 에이전트가 모두 Describe*를 호출하면 서로를 스로틀링할 수 있다.
주소 공간. 빈 IP가 바닥난 서브넷은 새 파드, 새 Lambda 네트워크 인터페이스, 새 인스턴스를 멈추는데, 에러 메시지에는 그중 어느 것도 언급되지 않는다.
리소스별 상한. EBS 볼륨의 IOPS와 처리량, RDS 인스턴스 클래스의 연결 수, NAT 게이트웨이의 포트.

각각을 100퍼센트 훨씬 전에 알람이 울리는 포화 SLI로 다뤄라. 많은 쿼터에 대해 CloudWatch는 AWS/Usage 네임스페이스에 사용량을 발행하고, SERVICE_QUOTA() metric math 함수는 현재 한도를 반환하므로, 식 하나로 쿼터 사용률을 얻는다. 나머지는 스케줄에 따라 도는 인벤토리 스크립트면 충분하다.

온프레미스의 한계는 물리적이고 올리기 더 느리다. 랙 유닛, 랙당 전원과 냉각, 스위치 포트, 라이선스된 코어, 스토리지 컨트롤러 처리량, 5년 전에 만든 주소 계획의 크기.

5. 용량: 탄력적이라고 무한은 아니다

클라우드의 약속은 용량이 몇 분 안에 도착한다는 것이다. 보통은 그렇고, SRE는 그렇지 않은 때를 계획한다. 특정 존의 특정 인스턴스 타입은 InsufficientInstanceCapacity를 반환할 수 있는데, 모두가 같은 생존 존으로 페일오버하는 존 이벤트 중에 가장 흔하다. 방어책은 다양성(Auto Scaling 그룹에 여러 인스턴스 타입과 모든 존), 페일오버 상황을 위한 사전 프로비저닝, 그리고 기다릴 수 없는 워크로드를 위한 On-Demand Capacity Reservations다.

온프레미스의 리드 타임은 몇 주에서 몇 달이므로, 용량 계획은 예측의 규율이다. 측정된 성장, 조달 달력, 위의 장애 도메인에 대해 N+1 또는 N+2로 잡은 여유. 신뢰성에 가장 큰 영향을 미치는 결정은 그것을 시험할 사건보다 훨씬 전인 구매 시점에 내려진다.

두 세계 모두에서, 첫 한계를 추정하는 대신 부하 테스트로 찾아라. 중요한 숫자는 2부의 SLI가 저하되기 시작하는 트래픽 수준과, 어떤 리소스가 그것을 일으켰는가이다.

6. 유지보수: 날짜가 박힌 사건들

사건의 상당수는 누군가 미리 일정에 넣어 두고 잊어버린 것이다. 클라우드에서는 인스턴스 퇴역 통지, 데이터베이스 유지보수 창, 표준 지원 종료에 이르는 엔진과 Kubernetes 버전, 인증서 만료, 사용 중단된 런타임. AWS는 이 대부분을 AWS Health를 통해 계정별로 발행하고, 이것은 EventBridge를 거쳐 다른 운영 작업과 같은 큐로 라우팅할 수 있다. 읽지 않으면 예고 없는 재부팅이 된다.

온프레미스에서는 목록이 더 길고 전부 당신 것이다. 펌웨어, 하이퍼바이저와 운영체제 패치, 디스크와 배터리 교체, 하드웨어 교체 주기, 벤더 지원 계약, 현장의 예비 부품. 각각에 소유자와 달력이 필요하다. 메이저 버전 세 개가 뒤처진 플랫폼은 에러 버짓을 미리 쓰고 있는 것이다.

이 영역의 마지막 점검은 공급자가 나쁜 하루를 보내고 있다는 것을 어떻게 알아내느냐다. 상태 페이지는 사건 중에 사람이 쓰며 사건보다 늦다. 공급자를 바깥에서 직접 측정하라. 다른 네트워크에서 실제 사용자 경로를 실행하는 합성 카나리는 대시보드보다 먼저 리전 문제를 알려주고, 실제 트래픽이 당신에게 닿지 못할 때도 SLI의 분모를 살아 있게 한다.

누가 무엇을 소유하는가

관심사	클라우드: SRE의 몫	온프레미스: SRE의 몫
시설, 전원, 냉각	존에 걸쳐 분산; 신뢰하되 검증	피드와 냉각 구역을 알고, 그에 맞춰 랙 배치
하드웨어 장애	인스턴스 상실이 사건이 아니도록 설계	같음, 더하여 예비품, 교체 절차, 벤더 계약
용량	쿼터, 인스턴스 다양성, 예약	예측, 조달 리드 타임, 여유
컨트롤 플레인	복구에 의존하지 않기	직접 운영하고, 이중화하고, 그래도 의존하지 않기
네트워크	존 단위 라우팅, NAT, DNS, 이중화된 전용선	전부: 통신사, BGP, 방화벽, DNS
패치와 수명 주기	공급자 기한 추적; 게스트 OS와 버전은 직접 소유	펌웨어에서 애플리케이션까지 모든 계층
비용	요청당 비용을 숫자로; 유휴 페일오버 용량은 보험	고정 구매 대비 사용률

어느 열도 일이 사라져서 짧은 것이 아니다. 클라우드는 아래쪽 행들을 거의 어떤 단일 회사보다 그 일에 능숙한 공급자에게 옮기고, 그 대가로 당신은 들여다볼 수 없는 의존성을 떠안는다. 그 거래는 대개 옳다. 그래도 거래이고, SRE는 그 양면을 말할 수 있는 사람이다.

실패 모드와 주시할 것

SLA를 예보로 취급하기. 그것은 크레딧이 붙은 가격 조건이다. 페이지 위의 퍼센트가 아니라 측정된 동작과 장애 도메인에 맞춰 설계하라.

다이어그램에서만 멀티 존. 서브넷 목록에는 존 셋, 실행 상태에는 하나, 또는 한 번도 실행해 본 적 없는 페일오버. 에러 버짓 안에서 의도적으로 테스트하라.

망가진 것을 필요로 하는 복구. 첫 단계가 영향받은 리전의 콘솔 로그인이나 파이프라인 실행인 런북.

프로덕션에서 발견한 한계. 4절의 모든 쿼터와 상한은 부하 테스트에서 찾으면 싸고, 출시 중에 찾으면 비싸다.

이제 당신이 선 자리

시리즈의 경로를 한 번에 훑으면 이렇다. 신뢰성을 엔지니어링 문제로 소유하고, 그것을 풀 시간이 생기도록 수작업에 상한을 둔다(1부). 서비스가 얼마나 신뢰할 수 있어야 하는지를 SLO로 말하고, 그 간극을 서명된 정책이 붙은 에러 버짓으로 의도적으로 쓴다(2부). 저장소로 들어가 숫자를 결정하는 타임아웃, 재시도, 롤아웃을 고치고, CPU 대신 번 레이트에 호출한다(3부). 그리고 발밑의 플랫폼이 무엇을 약속하는지, 어디가 함께 죽는지, 그럴 때 무엇을 할지 안다(4부). 네 가지 모두를 위한 도구는 대부분의 엔지니어가 이미 쓰고 있는 것들이다. 이 일을 SRE로 만드는 것은, 그 도구 하나하나가 이제 단 하나의 질문에 답하고 있다는 사실이다. 사용자는 우리가 합의한 신뢰성을 받고 있는가, 그리고 그것을 유지하는 가장 싼 방법은 무엇인가?

다음으로 읽을 글

이 시리즈의 3부: 코드베이스 속의 SRE: 타임아웃, 재시도, 코드로 작성한 알림.
수정은 장애와 운명을 공유한다: 복구 경로가 다운된 컨트롤 플레인에 의존했던 세 건의 사건.
ercan.ai의 Your LLM Bill Is an Observability Problem: 같은 공급자 의존성 사고를 모델 API에 적용한 것. 그곳에서는 쿼터와 비용이 포화 신호다.

AWS, 클라우드 아키텍처, SRE 실무, CI/CD 파이프라인, Linux 등에 대한 컨설팅은 ercanermis.com에서 시작하라.