Google Cloud 아키텍처 프레임워크의 이 문서에서는 업데이트를 배포하고 프로덕션 환경에서 서비스를 실행하고 오류를 테스트하는 방법 등 서비스를 안정적으로 실행하기 위한 운영 원칙을 제공합니다. 안정성을 고려한 설계에는 소프트웨어 설계뿐만 아니라 서비스의 전체 수명주기가 포함되어야 합니다.
애플리케이션 및 서비스에 대해 적합한 이름 선택
프로덕션 구성 파일에 내부 코드 이름을 사용하지 마세요. 특히 신규 직원의 경우 이름이 혼동될 수 있고, 서비스 중단 시 해결 시간(TTM)이 길어질 수 있습니다. 가능한 경우 언제라도 VM, 클러스터, 데이터베이스 인스턴스 등 모든 애플리케이션, 서비스, 중요 시스템 리소스에 대해 해당 이름 길이 한도에 맞게 적합한 이름을 선택하세요. 좋은 이름은 해당 항목의 목적을 나타내야 하고, 정확하고, 구체적이고, 구분이 가능해야 하며, 누구라도 이해할 수 있는 이름입니다. 좋은 이름은 두문자어, 코드 이름, 축약어, 잠재적으로 불쾌감을 주는 용어 등을 피해야 하며, 외부에 공개되더라도 부정적인 대중 반응을 일으키지 않는 것이어야 합니다.
카나리아 테스트로 점진적 출시 구현
서비스 바이너리 또는 구성을 즉각적이고 전체적으로 변경하는 것은 본질적으로 위험합니다. 새 버전의 실행 파일 및 구성 변경사항을 단계적으로 출시합니다. 영역 하나에서 몇 개의 VM 인스턴스와 같이 작은 범위로 시작한 다음 범위를 점진적으로 확장합니다. 변경사항이 예상한 대로 수행되지 않거나 출시 단계에서 사용자에게 부정적인 영향을 미치는 경우 빠르게 롤백합니다. 목표는 변경사항을 전역적으로 출시하기 전에 소수의 사용자 트래픽에만 영향을 미칠 때 버그를 식별하고 해결하는 것입니다.
서비스 변경사항을 인식하고 변경된 서버의 측정항목과 나머지 서버를 A/B 비교하는 카나리아 테스트 시스템을 설정합니다. 이 시스템은 예기치 않거나 비정상적인 동작을 신고해야 합니다. 변경사항이 예상한 대로 작동하지 않으면 카나리아 테스트 시스템이 출시를 자동으로 중단해야 합니다. 사용자 오류처럼 명확한 문제이거나 CPU 사용량 증가나 메모리 블로트와 같이 미묘한 문제가 발생할 수 있습니다.
문제가 처음 감지되었을 때 중단하고 롤백하면 서비스 중단으로 인한 시간적 압박 없이 문제를 진단할 수 있습니다. 변경사항이 카나리아 테스트를 통과하면 해당 변경사항을 더 큰 범위(예: 전체 영역, 두 번째 영역)에 단계적으로 전파합니다. 변경된 시스템이 더 많은 양의 사용자 트래픽을 단계적으로 처리하여 잠재적인 버그를 노출할 때까지 기다립니다.
자세한 내용은 애플리케이션 배포 및 테스트 전략을 참조하세요.
예약 프로모션 및 출시를 위한 트래픽 분산
정해진 시간에 시작하고 많은 사용자가 동시에 서비스에 연결하도록 유도하는 등의 프로모션 이벤트가 있을 수 있습니다. 그렇다면 몇 초 동안 트래픽을 분산하도록 클라이언트 코드를 설계합니다. 요청을 시작하기 전에 무작위 지연을 사용합니다.
시스템을 예열할 수도 있습니다. 시스템을 예열할 경우 예상하는 사용자 트래픽을 미리 전송하여 예상한 대로 작동하는지 확인할 수 있습니다. 이러한 방법으로 예약된 시작 시간에 서버의 장애를 초래할 수 있는 갑작스러운 트래픽 급증을 방지할 수 있습니다.
빌드, 테스트, 배포 자동화
지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 사용하여 출시 프로세스에서 수동적인 작업을 제거하세요. 자동화된 통합 테스트 및 배포를 수행합니다. 예를 들어 GKE로 현대적인 CI/CD 프로세스를 만듭니다.
자세한 내용은 지속적 통합, 지속적 배포, 테스트 자동화 및 배포 자동화를 참조하세요.
작업자 오류 방지
잘못되었을 수 있는 구성은 거부하도록 운영 도구를 설계합니다. 구성 버전이 비어 있거나 일부만 있거나 잘렸거나 손상되었거나 논리적으로 맞지 않거나 예기치 않았거나 예상된 시간 내에 수신되지 않은 경우 감지하여 알립니다. 도구에서 이전 버전과 크게 다른 구성 버전도 거부해야 합니다.
문제를 일으킬 수 있는, 너무 범위가 포괄적인 변경이나 명령어를 허용하지 마세요. 이러한 광범위한 명령어는 '모든 사용자의 권한 취소', '이 리전의 모든 VM 다시 시작', '이 영역의 모든 디스크 다시 포맷'과 같은 명령어일 수 있습니다. 이러한 변경사항은 운영자가 구성을 배포할 때 긴급 재정의 명령줄 플래그 또는 옵션 설정을 추가하는 경우에만 적용해야 합니다.
도구에서 변경사항의 영향을 받는 VM 수 등 위험한 명령어가 미치는 영향의 범위를 표시하고 도구를 진행하기 전에 명시적인 연산자 확인을 요구합니다. 또한 Cloud Storage 보관 정책 잠금과 같은 기능을 사용해 중요한 리소스를 잠그고 실수로 또는 승인 없이 삭제하지 못하도록 방지할 수 있습니다.
장애 복구 테스트
서비스 장애를 복구하는 운영 절차를 정기적으로 테스트합니다. 테스트를 정기적으로 실시하지 않으면 실제 장애가 발생하여 필요할 때 절차가 작동하지 않을 수 있습니다. 주기적으로 테스트할 항목에는 리전별 장애 조치, 출시 롤백 방법, 백업에서 데이터를 복원하는 방법이 포함됩니다.
재해 복구 테스트 수행
장애 복구 테스트와 마찬가지로 재해가 발생할 때까지 기다리지 말고 재해 복구 절차와 프로세스를 주기적으로 테스트하고 확인하세요.
고가용성(HA)을 제공하는 시스템 아키텍처를 만들 수 있습니다. 이 아키텍처는 재해 복구(DR)와 완전히 겹치지는 않지만 복구 시간 목표(RTO) 및 복구 지점 목표(RPO) 값이 중요하다면 HA를 고려해야 하는 경우가 많습니다.
HA를 사용하면 업타임과 같은 합의된 운영 성능을 충족하거나 초과할 수 있습니다. Google Cloud에서 프로덕션 워크로드를 실행할 때 수동 또는 활성 대기 인스턴스를 두 번째 리전에 배포할 수 있습니다. 이 아키텍처를 사용하면 기본 리전에 재해가 발생해도 애플리케이션은 영향을 받지 않는 리전의 서비스를 계속 제공합니다. 자세한 내용은 클라우드 서비스 중단에 대비한 재해 복구 설계를 참조하세요.
카오스 엔지니어링 연습
테스트 시 카오스 엔지니어링의 사용을 고려해 보세요. 안전한 환경에서 부하가 걸린 프로덕션 시스템의 다양한 구성요소에 실제 장애를 주입할 수 있습니다. 이 접근 방식에서는 서비스가 각 수준에서 올바르게 장애를 처리하므로 시스템이 받는 전반적인 영향을 막는 데 도움이 됩니다.
시스템에 주입하는 실패에는 비정상 종료 태스크, RPC의 오류 및 시간 제한, 리소스 가용성 감소가 포함될 수 있습니다. 임의의 결함 주입을 사용하여 서비스 종속 항목에서 간헐적인 장애를 테스트합니다(중단했다가 재개). 이러한 동작은 프로덕션 환경에서 감지하고 완화하기가 어렵습니다.
카오스 엔지니어링은 이러한 실험의 부정적 결과를 최소화하고 억제합니다. 이 테스트로 실제 서비스 중단을 대비해 연습하고 수집된 모든 정보를 사용하여 서비스 중단 대응을 개선하세요.
다음 단계
- 효율적인 알림 빌드(이 시리즈의 다음 문서)
시스템 설계, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등 아키텍처 프레임워크의 다른 카테고리를 살펴봅니다.