3.5 확장성, 성능, 복원력

개요와 동기

확장성, 성능, 복원력은 서로 다른 세 가지 품질이지만 사람들은 흔히 뒤섞습니다. 성능은 시스템이 얼마나 빨리 응답하고 자원 단위당 얼마나 많은 일을 하는가입니다. 확장성은 부하가 늘어도 성능을 얼마나 잘 유지하는가입니다. 복원력은 일이 실패할 때 얼마나 잘 계속 동작하거나 우아하게 성능이 저하되는가입니다. 시스템은 빠르지만 확장되지 않을 수 있고(낮은 부하에서는 훌륭하고 높은 부하에서 무너짐), 확장되지만 취약할 수 있고(양은 처리하지만 구성 요소 하나가 실패하면 쓰러짐), 복원력은 있지만 느릴 수 있습니다. 대규모 조직은 셋 모두를 처음부터 설계에 넣어야 합니다. 출시 후에 어느 하나를 사후 보강하는 것은 비싸고 혼란스럽기 때문입니다.

기업과 정부 시스템에서 이를 잘못했을 때의 결과는 공개적이고 심각합니다. 새 제도의 첫날 무너지는 급여 포털, 마감일에 시간 초과되는 세금 신고 시스템, 쇼핑 피크에 다운되는 결제 플랫폼을 생각해 보십시오. 헤드라인이 되고, 조사를 부르고, 대중의 신뢰를 침식하는 실패입니다. 이런 시스템은 또한 매우 뾰족하고 흔히 법적으로 시한이 정해진 부하(신고 마감일, 등록 기간, 급여일)와 엄격한 가용성 및 복구 의무에 직면합니다. 예측 가능한 급증에는 용량을 계획하고, 예측할 수 없는 급증에는 우아하게 성능을 낮추고, 재해 뒤에는 정의된 시간 및 데이터 손실 한도 안에 복구해야 합니다. 이것은 공적 책임의 차원이 있는 엔지니어링입니다.

이 장은 수평 대 수직 확장, 규모의 조력자로서의 무상태성과 샤딩, 로드 밸런싱, 오토스케일링과 용량 계획, 명시적 예산을 둔 성능 엔지니어링, 복원력 패턴과 카오스 엔지니어링, RTO, RPO, 비즈니스 연속성으로 틀을 잡은 다중 리전 재해 복구를 다룹니다. 통일된 메시지는 이런 품질이 희망이 아니라 의도적 설계와 지속적 테스트의 산물이라는 것입니다.

함께 보기: 3.3장(분산 시스템), 9.1장(사이트 신뢰성 엔지니어링), 9.2장(관측 가능성과 모니터링).

핵심 원칙

스케일 업이 아니라 스케일 아웃으로 설계하십시오. 수직 확장은 천장과 단일 장애점이 있고, 수평 확장은 크고 복원력 있는 규모에 도달하는 방법입니다.
무상태성은 수평 확장의 조력자입니다. 어떤 요청이든 어떤 인스턴스로 갈 수 있다면 용량을 자유롭게 추가하고 제거할 수 있습니다.
측정하지 않는 것은 개선할 수 없습니다. 성능 작업은 추측이 아니라 명시적 예산에 대한 프로파일링과 부하 테스트로 이끕니다.
모든 것은 실패합니다. 그에 맞춰 설계하십시오. 구성 요소가 실패한다고 가정하고 시스템이 그 실패에서 살아남도록 만드십시오.
우아한 성능 저하가 하드 실패보다 낫습니다. 필수가 아닌 기능을 떨어내는 부분 동작 시스템이 전면 장애보다 낫습니다.
용량은 계획하고, 급증은 흡수합니다. 예측 가능한 부하는 예측하고, 나머지는 오토스케일링과 여유로 대응하십시오.
복구 목표는 비즈니스 결정입니다. RTO와 RPO는 비즈니스가 비용에 비추어 선택한 뒤 그에 맞춰 엔지니어링합니다.
복원력을 의도적으로 테스트하십시오. 일부러 실패시켜 보기 전에는 시스템이 복원력 있는지 알 수 없습니다.

권장 사항

수평 확장을 선호하고 무상태 서비스를 설계한다

수직 확장(더 큰 기계)은 단순하고 때로 올바른 첫 단계이지만, 딱딱한 천장에 부딪히고, 상단에서 불균형하게 비싸지며, 단일 장애점을 남깁니다. 수평 확장(로드 밸런서 뒤의 더 많은 기계)은 훨씬 더 멀리 확장하고 인스턴스 하나를 잃어도 버틸 수 있어 가용성을 개선합니다. 전제 조건은 무상태성입니다. 클라이언트 세션이나 요청 상태를 인스턴스에 두지 말고 공유 저장소(데이터베이스, 캐시, 토큰)로 밀어내십시오. 무상태 서비스는 자유롭게 추가, 제거, 교체, 로드 밸런싱할 수 있으며, 이것이 오토스케일링과 롤링 배포를 모두 가능하게 합니다. 상태를 분할해야 하는 곳에서는 부하를 고르게 퍼뜨리고 관련 데이터를 같은 샤드에 두는 키로 샤딩하십시오.

로드 밸런싱, 오토스케일링, 용량 계획을 한다

확장된 모든 계층 앞에 로드 밸런서를 두어 트래픽을 분산하고 헬스 체크로 비정상 인스턴스를 우회하게 하십시오. 선행 지표(CPU, 요청 큐 깊이, 지연)가 임계값을 넘으면 용량을 추가하고 부하가 줄면 제거하도록 오토스케일링을 설정하십시오. 급증에 뒤처지지도 요동치지도 않도록 확장 속도와 쿨다운을 조정하십시오. 오토스케일링은 용량 계획의 대체물이 아닙니다. 예측 가능한 핵심 비즈니스 급증(세금 마감일, 등록 기간, 판매 행사)에는 부하를 예측하고, 용량을 미리 프로비저닝하거나 예열하고, 그 목표에 대해 미리 부하 테스트하십시오. 오토스케일링만으로는 계단식 변화에 즉시 반응할 수 없고, 콜드 스타트는 가장 여유가 없는 바로 그때 지연을 더합니다. 항상 여유를 유지하십시오. 100%로 돌리면 급증이나 실패를 흡수할 여지가 없습니다.

명시적 예산에 맞춰 성능을 엔지니어링한다

성능 예산(p95 API 지연 200ms 이내, 페이지 인터랙티브 2초 이내, 거래당 비용 임계값 이내 같은 구체적 목표)을 정하고 테스트와 모니터링에서 시행하여, 회귀가 사용자에게 닿지 않고 파이프라인을 실패시키게 하십시오. 최적화를 측정으로 이끄십시오. 프로파일링으로 실제 병목(추측하는 곳에 있는 일이 드뭅니다)을 찾고, 부하 테스트로 시스템이 어디서 깨지는지, 그 한계 근처에서 어떻게 동작하는지 찾으십시오. 규모에서는 꼬리 지연이 사용자 경험을 지배하므로 핵심 경로와 꼬리(p95/p99)에 집중하십시오. 가장 큰 병목을 먼저 최적화하고, 다시 측정하고, 예산을 충족하면 멈추십시오. 이미 충분한 코드를 과도하게 최적화하는 것은 노력 낭비입니다.

복원력 패턴을 넣고 카오스 엔지니어링으로 검증한다

분산 시스템의 복원력 패턴을 적용하십시오. 타임아웃, 백오프가 있는 한정된 재시도, 서킷 브레이커(의존성이 비정상일 때 빠르게 실패), 벌크헤드(한 실패가 나머지를 소진하지 못하도록 자원 풀을 격리), 그리고 우아한 성능 저하(압박 아래 필수가 아닌 기능을 떨어내거나 단순화: 추천 비활성화, 캐시된 콘텐츠 제공, 급하지 않은 작업 큐잉)와 부하 차단(완전히 무너지는 대신 핵심을 보호하려고 초과 요청을 거부하거나 조절)입니다. 모든 계층의 중복성으로 단일 장애점을 없애십시오. 그다음 카오스 엔지니어링으로 복원력을 검증하십시오. 통제된 실험에서 의도적으로 실패(인스턴스 종료, 지연 추가, 의존성 단절, 존 실패)를 주입하며, 테스트에서 시작해 프로덕션 게임 데이로 성숙시켜 시스템이 설계대로 동작함을 증명합니다. 한 번도 테스트되지 않은 복원력은 가설일 뿐입니다.

다중 리전, 재해 복구, 비즈니스 연속성을 계획한다

복구 목표를 명시적으로 정하십시오. RTO(복구 시간 목표, 얼마나 오래 다운될 수 있는가)와 RPO(복구 시점 목표, 얼마나 많은 데이터 손실을 감당할 수 있는가)입니다. 이것들은 직접적인 비용 함의를 가진 비즈니스 결정이며 아키텍처를 이끕니다. 선택지는 비용과 속도가 다양합니다. 백업과 복원(가장 싸고 가장 느림), 파일럿 라이트, 웜 스탠바이, 액티브-액티브 다중 리전(가장 비싸고 RTO/RPO가 0에 가까움)입니다. 각 시스템의 핵심성이 정당화하는 계층을 고르십시오. 모든 것이 액티브-액티브일 필요는 없습니다. 선택한 RPO에 맞게 리전 간 데이터를 복제하고, 페일오버를 자동화하고, 무엇보다 페일오버를 정기적으로 테스트하십시오. 테스트되지 않은 재해 복구는 마침내 필요할 때 어김없이 실패합니다. 이 모두를 기술만이 아니라 사람, 커뮤니케이션, 수동 대체를 다루는 비즈니스 연속성 계획으로 감싸십시오.

장단점

선택	장점	단점
수직 확장	단순. 코드 변경 없음. 낮은 초기 노력	딱딱한 천장. 상단에서 비쌈. 단일 장애점
수평 확장	거의 무제한 규모. 가용성 개선	무상태성, 로드 밸런싱, 더 많은 운영 필요
오토스케일링	비용을 수요에 맞춤. 가변 부하 처리	지연을 두고 반응. 콜드 스타트. 잘못 조정하면 요동
액티브-액티브 다중 리전	RTO/RPO가 0에 가까움. 리전 손실에서 생존	최고 비용과 복잡성. 어려운 데이터 일관성
백업과 복원 DR	가장 싸고 단순	긴 RTO. 큰 데이터 손실 구간

핵심 트레이드오프는 비용 대 보증입니다. 확장성 여유, 성능, 복구 능력의 증분마다 돈과 복잡성이 들고 수익은 비선형입니다. 가용성을 99.9%에서 99.99%로, 또는 RTO를 한 시간에서 몇 초로 올리면 비용이 곱절이 될 수 있습니다. 규율은 모든 것을 반사적으로 최고 계층으로 엔지니어링하는 대신, 각 투자를 시스템의 실제 핵심성과 비즈니스의 다운타임 및 데이터 손실 허용도에 맞추는 것입니다. 시민에게 노출되는 결제 시스템은 액티브-액티브 중복성을 얻을 자격이 있고, 내부 보고 도구는 그렇지 않습니다.

팀과 논의할 질문

마지막 심각한 인시던트가 일어났을 때 세 가지(성능, 확장성, 복원력) 중 실제로 무엇이 실패했으며, 맞는 것을 고쳤습니까? 이 장은 의도적으로 이들을 구분합니다. 시스템은 빠르지만 부하 아래서 무너질 수 있고, 확장되지만 구성 요소 하나가 죽으면 쓰러질 수 있고, 실패에서 살아남지만 느릴 수 있습니다. 팀은 흔히 잘못 진단합니다. 복원력 문제에 용량을 더하거나, 급증에 용량이 부족했을 뿐인 시스템을 강화합니다. 마지막 두 심각한 인시던트를 짚어 어떤 품질이 깨졌는지, 대응이 실제로 무엇을 개선했는지 말해 보십시오. 구별은 해법을 바꿉니다. 규모에는 무상태성과 샤딩, 복원력에는 중복성과 서킷 브레이커, 성능에는 프로파일링과 예산입니다. 범주를 맞게 잡는 것이 치료에 쓰느냐 증상에 쓰느냐의 차이입니다.
성능 회귀가 파이프라인을 실패시킵니까, 아니면 아무도 알아채기 전에 사용자에게 닿습니까? 성능 예산(p95 지연, 페이지 인터랙티브 시간, 거래당 비용)은 자동으로 시행될 때만 사용자를 보호하므로, 이를 깨는 변경은 출시되지 않고 빌드를 실패시킵니다. 기여자가 많은 큰 팀에서 지연은 천 개의 작은 커밋을 통해 스며들고, 관문이 없으면 출시가 드러낼 때까지 꼬리가 천천히 썩습니다. 현재 예산을 가져와 CI와 모니터링에 연결되어 있는지, 규모에서 사용자가 느끼는 것이 꼬리이므로 평균이 아니라 p95와 p99를 겨냥하는지 확인하십시오. 예산이 없는 곳에서는 하나를 정하는 것이 첫 수입니다. 시행이 좋은 의도를 팀이 커져도 살아남는 속성으로 바꿉니다.
압박 아래서 무엇이 먼저 떨어지며, 그 순서를 설계했습니까 아니면 장애 중에 발견하게 됩니까? 우아한 성능 저하와 부하 차단은 시스템이 핵심을 보호하려고 필수가 아닌 일을 포기한다는 뜻이지만, 무엇이 필수인지 미리 결정했을 때만 가능합니다. 시민에게 노출되는 서비스에서 그 순위는 흔히 정책 결정입니다. 상태 대시보드와 과거 조회가 꺼져도 세금 신고서 제출은 살아남아야 합니다. 아무도 선택하지 않았다면 시스템은 먼저 실패하는 것을 떨어내는데, 그것이 사용자에게 가장 필요한 바로 그것일 수 있습니다. 기능을 우선순위 순으로 나열하고, 아키텍처가 낮은 우선순위(캐시된 응답, 비활성화된 추천, 큐에 넣은 급하지 않은 작업)를 핵심 경로를 함께 끌어내리지 않고 떨어낼 수 있는지 확인하십시오. 그다음 실제 부하 아래서 테스트하십시오. 테스트되지 않은 성능 저하는 바람일 뿐입니다.
가장 핵심적인 시스템의 RTO와 RPO는 얼마이며, 그 숫자는 실제로 누가 정했고, 마지막으로 충족할 수 있음을 입증한 것은 언제입니까? 복구 시간 목표(얼마나 오래 다운될 수 있는가)와 복구 시점 목표(얼마나 많은 데이터 손실을 감당할 수 있는가)는 직접적인 비용 함의가 있는 비즈니스 결정이지만, 큰 팀에서는 서비스에 책임지는 사람들이 소유하기보다 런북을 쓴 사람이 지어내는 경우가 많습니다. 상충하는 끌림은 비용 대 보증입니다. RTO를 한 시간에서 몇 초로, RPO를 몇 분에서 0으로 줄이면 인프라 청구서가 곱절이 될 수 있으니, 맞는 숫자는 가장 인상적인 것이 아니라 비즈니스가 실제로 지불할 것입니다. 문서화된 목표, 마지막 실제 페일오버 테스트 날짜, 그 테스트가 낸 측정된 시간과 데이터 손실을 가져오십시오. 테스트되지 않은 목표는 소원이기 때문입니다. 기업과 정부 환경에서 이 숫자는 법령, 계약, SLA로 정해질 수 있으니, 누가 승인하는지, 마지막 리허설이 의무를 충족했는지 조용히 놓쳤는지 밝히십시오.
가장 큰 예측 가능한 급증에 오토스케일링이 그 순간 반응하리라 믿습니까, 아니면 부하를 예측하고, 미리 프로비저닝하고, 그 목표에 맞춰 부하 테스트했습니까? 오토스케일링은 지연을 두고 반응하고 콜드 스타트는 가장 여유 없는 바로 그때 지연을 더하므로, 알려진 계단식 변화(신고 마감일, 등록 기간, 판매 행사)는 반응형 확장이 실패하고 의도적 용량 계획이 이기는 바로 그 경우입니다. 긴장은 비용입니다. 피크를 위해 용량을 예열하는 것은 1년 중 대부분 놀고 있는 여유에 돈을 낸다는 뜻이고, 오토스케일링이 공짜로 덮어 주기를 바라고 싶은 유혹이 있습니다. 작년의 피크 수치, 성장을 반영한 올해 예측, 오늘의 평균 트래픽이 아니라 그 예측의 몇 배에 맞춰 실행한 부하 테스트 결과를 가져오십시오. 법적으로 시한이 정해진 급증에 직면한 정부나 기업 서비스에서는 잘못되었을 때의 결과를 더하십시오. 첫날 무너지는 급여 포털이나 세금 시스템은 느린 오후가 아니라 공적 조사가 되기 때문입니다.
프로덕션에서 구성 요소를 의도적으로 실패시켜 본 적이 있으며, 각 시스템의 중복성 계층이 핵심성과 비용에 실제로 맞습니까? 한 번도 테스트되지 않은 복원력은 가설이며, 살 수 있는 계층은 싼 백업과 복원에서 웜 스탠바이, 비싼 액티브-액티브 다중 리전까지 다양하므로, 규율은 모든 것을 도금하거나 아무것도 보호하지 않는 대신 보증이 정당화되는 곳에 쓰는 것입니다. 상충하는 고려는 영향 범위와 예산입니다. 카오스 실험에는 가드레일과 중단 스위치가 있어야 하고, 내부 보고 도구의 액티브-액티브는 낭비인 반면 결제 플랫폼의 백업 전용은 태만입니다. 단일 장애점의 목록, 각 핵심 시스템의 중복성 계층, 마지막 통제된 장애 주입의 증거와 그것이 드러낸 것을 가져오십시오. 기업과 정부 포트폴리오에서는 각 계층을 문서화된 핵심성 등급에 대응시켜, 감사자가 돈이 위험을 따름을 볼 수 있게 하고 장애 중에 처음으로 지출을 변호할 필요가 없게 하십시오.

분야별 관점

스타트업. 출시가 가입 쉰 명을 가져올지 오만 명을 가져올지 예측할 수 없으니, 규모를 만들지 말고 사십시오. 관리형 로드 밸런서 뒤에서 무상태 서비스를 돌리고 플랫폼이 요청률에 따라 오토스케일링하게 하십시오. 소박한 성능 예산 하나를 정하고 관리형 데이터 저장소를 골라 급증이 새벽 2시의 재아키텍처링을 강요하지 않게 하십시오. 지금은 다중 리전 재해 복구와 카오스 프로그램을 건너뛰고, 테스트된 백업을 유지하며, 트래픽이 아직 정당화하지 않는 중복성이 아니라 제품에 희소한 엔지니어링 주의를 쓰십시오.

소기업. 신뢰성 전문가도 빠듯한 예산도 없으니 사느냐 만드느냐는 강하게 사는 쪽으로 기웁니다. 관리형 플랫폼이나 서버리스 스택은 확장과 페일오버를 제공자의 일로 만들고, 잘 운영되는 단일 리전이면 대개 충분합니다. 복원력을 지킬 수 있는 소수의 구체적 약속으로 구성하십시오. 한 번은 실제로 복원해 본 야간 백업, 고객에게 알린 현실적인 복구 구간 같은 것입니다. 트래픽도 인력도 정당화하지 않는 액티브-액티브나 지속적 부하 테스트에 돈을 내지 마십시오.

대기업. 문제는 많은 팀에 걸친 일관성입니다. CI에서 시행되는 성능 예산, 복원력 패턴(타임아웃, 서킷 브레이커, 벌크헤드)의 공유 라이브러리, 핵심성에 묶인 각 시스템의 문서화된 중복성 계층을 표준화하십시오. 액티브-액티브 다중 리전은 1등급 서비스에 남겨 두고, 가드레일과 프로덕션 게임 데이를 갖춘 카오스 엔지니어링 프로그램을 운영하고, 알려진 급증의 용량 계획을 사후 생각이 아니라 일정에 잡힌 규율로 다루십시오. 모든 핵심 시스템에 감사자가 검증할 수 있는 소유되고 테스트된 목표가 있도록 RTO와 RPO를 중앙에서 다스리십시오.

정부. 부하는 흔히 법적으로 시한이 있고 가용성 의무는 법정이므로, 용량 계획은 그 순간 반응하는 오토스케일링에 의존할 수 없습니다. 마감일 급증을 예측하고, 미리 프로비저닝하고, 예측을 훨씬 웃도는 수준으로 부하 테스트하십시오. 조달은 RTO, RPO, 리허설된 페일오버 일정을 벤더의 약속이 아닌 계약상의 요구 사항으로 명시해야 하며, 핵심 서비스의 단일 리전 종속을 피해야 합니다. 어느 경로가 법적으로 필수인지(신고서 제출, 급여 청구) 미리 결정해 성능 저하가 상태 대시보드와 조회를 먼저 떨어내게 하고, 아무도 알아채지 못하기를 바라는 대신 장애와 복구에 대해 대중에게 투명하십시오.

사례

스타트업. Product Hunt에 출시하는 작은 스타트업은 가입이 쉰 명일지 오만 명일지 예측할 수 없으므로, 서비스를 관리형 로드 밸런서 뒤에서 무상태로 유지하고 플랫폼이 요청률에 따라 오토스케일링하게 합니다. 소박한 성능 예산(페이지가 95번째 백분위수에서 300ms 이내 응답) 하나를 정하고 관리형 데이터베이스를 골라 트래픽 급증이 새벽 2시의 재아키텍처링을 강요하지 않게 합니다. 출시일 급증이 실제로 오자 사이트는 쓰러지는 대신 조금 느려지고, 팀은 장애와 싸우는 대신 새 사용자와 대화하며 하루를 보냅니다.

대기업. 한 스트리밍 미디어 회사가 글로벌 로드 밸런싱 뒤의 여러 리전에서 무상태 서비스를 운영하고, 하루의 프라임타임 파도를 따라 요청률로 오토스케일링합니다. 성능 예산이 p99 시작 지연으로 모든 릴리스를 관문 통제합니다. 리전 장애 시 트래픽은 자동으로 정상 리전으로 이동하고, 필수가 아닌 기능(개인화된 아트워크, 추천 새로고침)이 재생을 보호하려고 먼저 성능이 저하됩니다. 회사는 프로덕션에서 지속적으로 카오스 실험을 돌려 인스턴스를 일상적으로 종료하고 지연을 주입하므로, 실제 실패가 훈련과 구별되지 않고 고객에게 보이는 장애를 일으키지 않습니다.

정부. 한 세무 기관은 신고 시스템이 매년 막대하고 법적으로 고정된 마감일 급증에 직면함을 압니다. 그 순간 반응하는 오토스케일링에 의존하는 대신, 지난 몇 해로 피크 부하를 예측하고, 몇 주 전에 용량을 미리 프로비저닝하고, 예측의 150%까지 부하 테스트합니다. 아키텍처는 로드 밸런서 뒤의 무상태이며 웜 스탠바이 두 번째 리전을 갖습니다. RTO와 RPO는 정책으로 정해지고(제출된 신고서에 대해 다운타임 15분 이하, 데이터 손실은 거의 0), 페일오버는 분기마다 리허설됩니다. 극심한 부하에서는 필수가 아닌 기능(상태 대시보드, 과거 조회)이 먼저 떨어져서 법적으로 필수인 경로인 신고서 제출이 계속 가용합니다.

비즈니스 사례: 동기, ROI, TCO

확장성, 성능, 복원력은 실패의 비용이 예방의 비용을 훨씬 넘는 전형적인 사례입니다. 하지만 예방은 예산에 보이고 실패는 잠재적일 뿐이어서, 첫 재앙까지 만성적으로 재원이 부족합니다. 도입 비용은 실재합니다. 중복 인프라, 다중 리전 용량, 부하 테스트와 카오스 도구, 무상태성과 복원력 패턴을 만드는 엔지니어링 시간입니다. 투자하지 않는 비용은 수요 피크 중의 세간의 이목을 끄는 장애입니다. 상거래에서는 분 단위의 매출 손실, 정부에서는 놓친 법정 의무와 공적 조사, 서비스 수준 협약(SLA) 위약금, 지속적인 평판 손상입니다.

리더십에게는 비즈니스가 이미 이해하는 숫자로 논거를 세우십시오. 피크 중 한 시간 다운타임의 비용(잃은 거래, 위약금, 복구, 평판)을 추정한 뒤, 그것을 막는 중복성과 테스트의 연간 비용과 비교하십시오. 핵심 시스템에서 예방은 거의 항상 큰 인시던트 한 번의 일부입니다. RTO와 RPO를 명시적 돈에 연결하십시오. 다운타임 한 시간당 얼마의 매출이나 몇 건의 거래이며, 법적으로 또는 상업적으로 어느 정도의 데이터 손실이 허용되는가. 성능은 매출과 만족의 지렛대로 제시하십시오. 더 빠른 시스템은 더 잘 전환하고 거래당 비용이 낮기 때문입니다. 복원력은 보호 대상 손실에 비해 보험료가 작은 보험으로 제시하십시오. 가장 강한 논거는 이런 품질이 설계에 넣기는 싸고, 문제를 강제하는 장애 뒤에 사후 보강하기는 파멸적이라는 점입니다.

안티패턴과 함정

스티키 세션과 인스턴스 내 상태. 서버에 세션 상태를 저장해 자유로운 수평 확장과 안전한 인스턴스 교체를 막는 것.
용량 계획으로서의 오토스케일링. 반응하기에 너무 느린 알려진 계단식 급증을 오토스케일링이 흡수하리라 가정하는 것.
여유 없이 뜨겁게 운영. 사용률 100%에 가깝게 운영해 급증이나 실패를 흡수할 여지를 남기지 않는 것.
프로파일링 없는 최적화. 실제 병목은 건드리지 않은 채 병목이 아닌 코드를 튜닝하는 것.
꼬리 무시. p99 사용자가 고통받는 동안 평균 지연을 보고하는 것. 평균은 규모에서 고통을 가립니다.
테스트되지 않은 재해 복구. 한 번도 실행되지 않았고 필요할 때 실패할 DR 계획과 백업.
단일 장애점. 로드 밸런서 하나, 데이터베이스 주 노드 하나, 리전 하나. 중복되지 않은 구성 요소가 모든 것을 쓰러뜨립니다.
가드레일 없는 카오스 엔지니어링. 영향 범위 통제나 중단 스위치 없이 실패를 주입해, 막으려던 바로 그 장애를 일으키는 것.

성숙도 모델

1단계: 시작. 즉흥적이고 반응적입니다. 단일 인스턴스이거나 수직 확장되고 서버에 상태가 있습니다. 부하 테스트도, 성능 예산도 없고, 아무도 복원해 본 적 없는 가끔의 백업 외에 재해 복구가 없습니다. 어느 구성 요소의 실패든 전면 장애를 일으키고, 규모 문제는 프로덕션에서 발견됩니다.
2단계: 발전. 기본 실천이 나타나지만 팀마다 다릅니다. 일부 서비스는 로드 밸런서 뒤에서 수평 확장되고 무상태이며, 그중 몇몇에 기본 오토스케일링이 있습니다. 부하 테스트는 큰 출시 전에 하지만 일상적이지 않고, 백업은 있고 재해 복구는 문서화되었으나 거의 실행되지 않습니다. 한 팀이 잘하는 것을 다른 팀은 시작하지 못했습니다.
3단계: 표준화. 실천이 문서화되어 조직 전체에서 시행됩니다. 알려진 급증에 대해 여유를 두고 용량이 계획되고, 성능 예산이 CI에서 시행되어 회귀가 빌드를 실패시키며, 복원력 패턴(타임아웃, 한정된 재시도, 서킷 브레이커, 벌크헤드)과 우아한 성능 저하가 기본입니다. RTO와 RPO가 시스템별로 정의되고, 중복성 계층이 핵심성에 따라 할당되며, 재해 복구 페일오버가 팀 전반에서 정기 일정으로 테스트됩니다.
4단계: 관리. 품질이 기준선에 대해 측정되고 통제됩니다. 팀이 p95와 p99 지연, 오류 예산, 예측에 대한 사용률과 여유를 추적하고, 출시에서 발견하는 대신 위반에 경보를 겁니다. 테스트된 페일오버 시간이 목표 RTO와 RPO와 비교되고, 성능 저하 및 부하 차단 임계값이 지표로 검증되며, 릴리스와 용량에 대한 진행 여부 결정이 데이터로 이끌어집니다. 숫자가 기준선에서 벗어나면 간극은 평균 뒤에 숨지 않고 눈에 보이고 소유됩니다.
5단계: 오케스트레이션. 확장성, 성능, 복원력이 조직 전체에서 지속적으로 개선되고 통합됩니다. 핵심성이 정당화하는 곳마다 액티브-액티브 다중 리전이 쓰이고, 프로덕션 게임 데이를 포함한 카오스 엔지니어링이 지속적으로 돌며, 용량 예측이 계획과 조달에 직접 되먹임됩니다. 복원력이 지속적으로 검증되고, 복구 목표가 일관되게 충족되고 입증되며, 아키텍처는 부하 패턴과 위험 그림이 이동함에 따라 적응하여 비즈니스 연속성과 위험 계획에 묶입니다.

논의를 위한 아이디어

서비스 중 어느 것이 여전히 인스턴스에 상태를 두고 있으며, 무상태로 만드는 데 무엇이 막고 있습니까?
가장 핵심적인 시스템의 RTO와 RPO는 무엇이고, 누가 정했으며, 마지막으로 충족할 수 있음을 입증한 것은 언제입니까?
오토스케일링이 가장 큰 알려진 급증에서 실제로 보호해 줍니까, 아니면 할 수 없는 일을 하기를 기대하고 있습니까?
남아 있는 단일 장애점은 어디이며, 제거할 계획은 무엇입니까?
p99 지연을 측정하고 예산을 잡고 있습니까, 아니면 평균 뒤에 숨고 있습니까?
프로덕션에서 구성 요소를 의도적으로 실패시켜 본 적이 있습니까? 없다면 복원력이 동작함을 어떻게 압니까?

핵심 요점

성능, 확장성, 복원력을 구별하십시오. 대규모 시스템은 셋 모두를 처음부터 설계에 넣어야 합니다.
수평 확장과 무상태 서비스가 규모, 가용성, 안전한 배포의 토대입니다.
예측 가능한 핵심 비즈니스 급증에는 오토스케일링을 실제 용량 계획과 여유와 결합하십시오.
명시적 예산에 대한 프로파일링과 부하 테스트로 성능을 이끌고, 핵심 경로와 꼬리에 집중하십시오.
타임아웃, 서킷 브레이커, 벌크헤드, 우아한 성능 저하, 중복성으로 복원력을 만들고, 카오스 엔지니어링으로 검증하십시오.
RTO와 RPO를 비즈니스 결정으로 정하고, 각 시스템의 핵심성에 맞춰 DR을 엔지니어링하고, 페일오버를 정기적으로 테스트하십시오.

참고 문헌과 더 읽을거리

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering and The Site Reliability Workbook
Casey Rosenthal and Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile