Google Cloud 아키텍처 프레임워크의 이 카테고리에서는 대략적인 클라우드 플랫폼에서 안정적인 서비스를 설계하고 운영하는 데 필요한 설계 원칙을 다룹니다.
아키텍처 프레임워크는 권장사항을 설명하고 구현 권장사항을 제공하며 사용 가능한 여러 제품 및 서비스를 설명합니다. 이 프레임워크의 목표는 비즈니스 요구사항에 가장 잘 맞는 Google Cloud 배포를 설계하도록 지원하는 것입니다.
안정적인 서비스를 실행하려면 아키텍처에 다음이 포함되어야 합니다.
- 편차가 발생할 때마다 즉시 수정하는 측정 가능한 안정성 목표
- 다음을 위한 설계 패턴:
- 확장성
- 고가용성
- 재해 복구
- 자동 변경 관리
- 자가 복구되는 구성요소(수동 개입 없이 문제를 해결할 수 있음)
- 관측 가능성을 위한 계측을 포함하는 코드
- 최소한의 수작업, 인지 작업자 부하, 신속한 장애 감지 및 완화를 통한 서비스 실행과 같은 핸즈프리 작업
개발, 제품 관리, 운영, 사이트 안정성 엔지니어링 (SRE)팀을 포함한 전체 엔지니어링 조직이 서비스 안정성을 책임집니다. 팀은 애플리케이션의 안정성 목표, 위험, 오류 예산을 이해하고 이러한 요구사항에 대한 책임을 져야 합니다. 안정성과 제품 기능 개발 간의 충돌은 우선순위를 두고 그에 따라 에스컬레이션해야 합니다.
안정성의 핵심 원칙
이 섹션에서는 안정적인 서비스의 핵심 원칙을 살펴보고 이어지는 자세한 문서의 기초를 설정합니다. 이 주제에 대해 더 자세히 읽으면 Google의 안정성 접근 방법이 다음과 같은 안정성 원칙을 기반으로 함을 알 수 있을 것입니다.
안정성이 최우선 과제
엔지니어링팀에서 신제품 개발에 우선순위를 두는 경우가 있습니다. 사용자는 좋아하는 애플리케이션에 대해 새롭고 흥미로운 업데이트를 기대하지만 제품 업데이트는 사용자를 위한 단기적인 목표입니다. 고객은 서비스 안정성에 대해 알지 못하더라도 항상 서비스 안정성을 기대합니다. 사용자가 서비스에 액세스할 수 없거나 서비스 성능이 저하되면 애플리케이션에 다양한 도구 세트가 확장되었거나 플래시 그래픽이 있는 것은 중요하지 않습니다. 애플리케이션 성능이 저하되면 이러한 확장된 기능의 의미는 빠르게 반감됩니다.
안정성은 사용자가 정의
간단히 말해, 고객이 만족할 때 서비스가 안정적이라고 할 수 있습니다. 사용자를 항상 예측할 수 있는 것은 아니며, 사용자를 만족시키기 위해 필요한 것이 무엇인지 과대평가할 수 있습니다.
오늘날 기준으로 웹 페이지는 대략 2초 안에 로드되어야 합니다. 로드 시간이 1초 지연되면 페이지 이탈률은 약 53%이며, 로드 시간이 3초 지연되면 페이지 이탈률은 87%로 크게 증가합니다. 그러나 1초 만에 페이지를 제공하는 사이트를 추구하는 것은 최선의 투자가 아닐 수 있습니다. 고객에게 적합한 서비스 안정성 수준을 결정하려면 다음을 측정해야 합니다.
- 사용자 대상 워크로드: 사용자 환경을 측정합니다. 예를 들어 CPU 사용량 같은 서버 측정항목뿐만 아니라 사용자 요청의 성공률을 측정합니다.
- 일괄 및 스트리밍 워크로드: 기간별로 스캔된 행과 같은 데이터 처리량의 핵심성과지표(KPI)를 측정합니다. 이 방식은 디스크 사용량과 같은 서버 측정항목보다 유용합니다. 처리량 KPI를 사용하면 사용자가 요청한 처리가 제시간에 완료되도록 보장할 수 있습니다.
100% 안정성은 잘못된 목표임
이 원칙은 이전 원칙의 확장입니다. 사용자가 만족할 때 시스템의 안정성이 충분히 확보됩니다. 일반적으로 사용자가 만족하기 위해 100% 안정성이 필요하지는 않습니다. 따라서 사용자를 만족시키는 데 필요한 비율로 안정성 기준을 설정하는 서비스 수준 목표(SLO)를 정의한 다음 오류 예산을 사용하여 적절한 변경 속도를 관리하세요.
해당 제품 또는 애플리케이션의 SLO가 비용의 근거를 제공하는 경우에만 이 프레임워크의 설계 및 운영 원칙을 제품에 적용합니다.
안정성과 빠른 혁신은 상호 보완 관계
오류 예산을 사용하여 시스템 안정성과 개발자 민첩성 사이의 균형을 유지하세요. 다음 지침은 안정성 또는 개발에 더 집중할 수 있는 시기를 결정하는 데 도움이 됩니다.
- 오류 예산이 줄어들면 속도를 늦추고 안정성 기능에 집중하세요.
- 적절한 오류 예산을 사용할 수 있으면 신속하게 혁신하고 제품을 개선하거나 제품 기능을 추가할 수 있습니다.
설계 및 운영 원칙
아키텍처 프레임워크의 안정성 카테고리에 있는 나머지 문서에서는 시스템 안정성을 극대화하는 데 도움이 되는 설계 및 운영 원칙을 제공합니다. 다음 섹션에서는 이 시리즈의 각 문서에서 찾을 수 있는 설계 및 운영 원칙을 요약해서 보여줍니다.
안정성 목표 설정
사용자 만족도는 안정성을 정의하며 안정성 목표는 설정한 SLO로 표현됩니다. SLO를 설정할 때 다음 사항을 고려하세요.
- 적절한 서비스 수준 지표(SLI)를 선택합니다.
- 사용자 경험에 따라 SLO를 설정
- SLO를 반복적으로 개선
- 엄격한 내부 SLO 사용
- 오류 예산을 사용하여 개발 속도 관리
자세한 내용은 서비스 수준 목표의 구성요소를 참조하세요.
인프라 및 애플리케이션에 관측 가능성을 빌드합니다.
코드를 사용하면 관측 가능성을 극대화할 수 있습니다. 자세한 내용은 인프라 및 애플리케이션에 관측 가능성 빌드를 참조하세요.
확장성 및 고가용성 설계
확장성 및 고가용성(HA)과 관련하여 다음 원칙을 고려하세요.
- HA를 위한 중복성 만들기
- 재해 복구(DR)를 위해 리전 간 데이터 복제
- 리전 서비스 중단에 대한 복원력이 우수한 멀티 리전 아키텍처 설계
- 과부하 발생 시 단계적으로 서비스 수준 저하
- 시스템 작동이 지속되는 장애 안전 모드
- 재시도할 수 있도록 API 호출 및 작업 명령어 설계
- 종속 항목을 고려하세요.
- 시스템 종속 항목 식별 및 관리
- 중요한 종속 항목 최소화
- 모든 변경 사항이 롤백 가능한지 확인
또한 다음 활동은 서비스의 안정성에 도움이 됩니다.
- 확장성 병목 현상 제거
- 트래픽 급증을 방지하고 완화하기
- 입력 내용 삭제 및 유효성 검사
자세한 내용은 확장 및 고가용성 설계를 참조하세요.
안정적인 도구 및 운영 프로세스 만들기
다음을 수행하여 도구 및 운영 프로세스에 안정성을 높입니다.
- 애플리케이션 및 서비스에 논리적이고 자체를 정의하는 이름 선택
- 카나리아 테스트를 사용하여 점진적 출시 절차 구현
- 트래픽을 분산시키고 시스템 과부하를 줄일 수 있도록 프로모션 및 출시 시기 조절
- 프로그래매틱 방식의 빌드, 테스트, 배포 프로세스 개발
- 의도와 관계없이 사람이 일으킨 이슈로부터 방어
- 실패 대응 활동 개발, 테스트, 문서화
- 정기적으로 재해 복구 단계 개발 및 테스트
- 카오스 엔지니어링: 서비스의 내결함성과 복원력을 확인하기 위해 시스템에 장애를 발생시키는 방법
자세한 내용은 안정적인 운영 프로세스 및 도구 만들기를 참조하세요.
효율적인 알림 빌드
알림을 만들 때 다음을 수행하는 것이 좋습니다.
- 적절한 지연을 위한 알림 최적화
- 원인이 아닌 증상에 대한 알림
- 평균이 아닌 이상점에 대한 알림
자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 효율적인 알림 빌드를 참조하세요.
이슈 관리를 위한 공동작업 프로세스 빌드
이슈 대응 및 관리(IRM)는 서비스 복구 및 손상 최소화에 필수적입니다. 유효 IRM에는 다음이 포함됩니다.
- 소유권: 명확한 서비스 소유자를 할당합니다.
- 조정된 알림: 신중하게 설계된 알림으로 이슈 대응(IR)을 개선하고 감지 시간(TTD)을 단축합니다.
- IRM 계획 및 학습: 포괄적인 계획, 문서, 학습을 통해 완화 시간(TTM)을 단축합니다.
- 대시보드: 문제가 발생할 때 TTM을 최소화하기 위해 효율적으로 알리도록 대시보드 레이아웃과 콘텐츠를 설계합니다.
- 문서: 진단 절차 및 서비스 중단 시나리오 완화를 포함하여 서비스 지원의 모든 측면에 대한 명확하고 간결한 콘텐츠를 작성하고 유지합니다.
- 비난 없는 문화:
- 조직에서 비난 없는 환경을 조성합니다.
- 누가 아니라 무엇에 초점을 두는 사후 분석 프로세스를 설정합니다.
- 제대로 조사하고 개선할 부분을 파악하여 서비스 중단을 통해 배우고 재발을 방지합니다.
자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 공동작업 이슈 관리 프로세스 빌드를 참조하세요.
다음 단계
- SLO 구성요소
- 아키텍처 프레임워크의 기타 카테고리 살펴보기
- 클라우드 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기