매년 수십억 명의 사용자가 Google 제품 및 서비스와 상호작용합니다. Google 검색, Gmail, 지도, YouTube, Chrome, 그리고 이제는 Google Cloud와 같은 주요 제품은 현대 생활에 원활하게 통합되어 21세기 환경을 정의하는 데 도움이 됩니다. Google 제품의 검증된 품질과 Google을 항상 사용할 수 있다는 기대감의 영향이 전 세계에 미치고 있습니다.
Google Cloud는 최고의 사용자 환경을 제공하고 안전성과 신뢰성을 개선하며 규제 및 규정 준수 요구사항을 준수할 수 있도록 제품과 서비스에 코드 변경사항을 지속적으로 도입하고 있습니다. 이러한 변경사항은 크기에 관계없이 문제를 일으키는 경우가 있습니다. 이러한 위험이 해결되도록 Google은 변경사항의 전체 수명 주기에서 변경사항 안전을 우선시합니다.
이 문서에서는 Google Cloud팀에서 Google이 수십 년간 투자한 개발 우수성을 바탕으로 개발 속도와 신뢰성에 대한 Google Cloud 고객 기대치를 충족하는 신뢰성 권장사항과 엔지니어링 표준을 구현하는 방법을 설명합니다.
Google Cloud의 변경사항 수명
Google Cloud 제품팀은 관리 프로세스와 도구 대부분을 Google의 다른 엔지니어링팀과 공유합니다. Google은 지속적 통합(CI) 및 지속적 배포(CD)를 우선 적용하는 변경 관리를 위한 표준 소프트웨어 개발 방법을 구현합니다. CI에는 특정 제품이나 서비스에 대해 하루에 여러 번 변경사항을 제안, 테스트, 제출하는 작업이 포함됩니다. CD는 엔지니어가 코드베이스의 안정적인 최신 스냅샷을 기반으로 출시 후보를 지속적으로 준비하는 CI의 확장입니다.
이 방법은 변경사항을 단계적으로 만들고 Google Cloud 고객에게 최대한 빠르고 안전하게 출시하는 것을 우선시합니다. Google은 코드를 작성하기 전에 변경사항 안전을 고려하며 프로덕션에 변경사항을 출시한 후에도 계속해서 안전에 중점을 둡니다. 변경 관리 모델에는 일반적으로 설계, 개발, 검증, 출시라는 4단계가 있습니다. 다음 다이어그램에는 이러한 4단계가 표시되어 있으며 이 문서 전체에서 이 단계를 자세히 설명합니다.
처음부터 안전하게 설계
Google은 개발 프로세스 초기의 작은 실수가 나중에 큰 문제를 일으켜 고객 경험에 상당한 영향을 줄 수 있음을 잘 알고 있습니다. 따라서 모든 주요 변경사항은 승인된 설계 문서로 시작으로 해야 합니다. 엔지니어링팀에서 주요 변경사항을 제안할 수 있는 일반적인 설계 문서 템플릿이 있습니다. 이 공통 설계 문서는 Google Cloud 제품 전체에서 주요 변경사항을 일관되게 평가하는 데 도움이 됩니다. 다음 다이어그램에서는 주요 변경사항에 대한 표준 설계 프로세스를 보여줍니다.
설계 단계는 소프트웨어 개발자가 비즈니스, 기술, 비용, 유지보수 요구사항을 해결하는 변경사항을 제안하면 시작됩니다. 변경사항을 제출하면 신뢰성 및 보안 전문가, 기술 책임자를 포함한 선임 전문가가 참여하는 포괄적인 검토 및 승인 절차가 시작됩니다. 설계를 제안한 엔지니어가 전문가의 모든 의견을 처리하고 각 전문가가 설계를 승인한 후에만 변경사항 구현 작업이 진행될 수 있습니다. 이러한 설계 및 검토 프로세스를 통해 Google Cloud 제품팀이 프로덕션 환경에서 고객에게 부정적인 영향을 미칠 수 있는 변경사항을 시작할 가능성이 줄어듭니다.
개발된 그대로 안전
Google의 코드 개발 프로세스는 코드의 품질과 신뢰성을 높입니다. 제안된 변경사항이 승인되면 개발 프로세스는 교육, 멘토링, 제안된 코드 변경사항에 대한 자세한 의견을 포함하여 신입 엔지니어를 위한 포괄적인 온보딩으로 시작됩니다. 수동 테스트와 자동 테스트를 포함하는 다층적 개발 및 테스트 방식은 모든 개발단계에서 코드를 지속적으로 검증합니다. 각 코드 변경사항은 Google의 높은 표준을 충족하는지 철저하게 검토됩니다.
다음 다이어그램에서는 Google의 개발 프로세스를 간략하게 보여주는 워크플로를 제공합니다.
개발 단계는 엔지니어가 코드 및 해당 단위 테스트와 통합 테스트를 작성하기 시작하면 시작됩니다. 이 단계에서 엔지니어는 자신이 작성한 테스트와 제출 전 테스트 모음을 실행하여 코드 추가와 변경사항이 유효한지 확인할 수 있습니다. 코드 변경사항을 마무리하고 테스트를 실행한 후 엔지니어는 코드에 익숙한 다른 엔지니어에게 직접 검토해 달라고 요청합니다. 이러한 사람의 검토 프로세스는 종종 반복되며 이 과정에서 코드가 추가적으로 수정될 수 있습니다. 작성자와 검토자가 합의하면 작성자가 코드를 제출합니다.
코딩 표준을 통해 고품질 변경사항 보장
Google의 엔지니어링 문화, 관행, 도구는 코드가 정확하고 명확하고 간결하고 효율적일 수 있도록 설계되었습니다. Google의 코드 개발은 세계 최대 규모의 통합 코드 저장소인 모노레포에서 진행됩니다. 모노레포에는 수백만 개의 소스 파일과 수십억 줄의 코드가 있으며 변경 목록이라는 수억 개의 커밋 기록이 있습니다. 매일 수만 개의 새로운 변경 목록이 추가되면서 계속해서 빠르게 성장하고 있습니다. 모노레포의 주요 이점은 코드 재사용을 용이하게 하고 종속 항목을 더 쉽게 관리하고 제품과 서비스 전반에서 일관된 개발자 워크플로를 적용한다는 점입니다.
재사용된 코드가 프로덕션 환경에서 어떻게 작동하는지 이미 잘 알고 있으므로 코드 재사용이 유용합니다. 이미 존재하는 고품질 코드를 활용하면 변경사항이 본질적으로 더 강력하고 필요한 표준으로 더 쉽게 유지할 수 있습니다. 이 관행은 시간과 노력을 절약할 뿐만 아니라 코드베이스의 전반적인 상태를 양호하게 유지하여 더욱 신뢰할 수 있는 제품을 제공합니다.
고품질 오픈소스 소프트웨어를 기반으로 하는 Google Cloud 서비스는 오픈소스 소프트웨어를 관리하기 위해 모노레포를 다른 저장소(일반적으로 Git)로 보완하여 브랜치를 수행할 수 있습니다.
교육 관련 참고사항
코드 품질에 대한 투자는 엔지니어가 팀에 합류할 때 시작됩니다. 엔지니어가 Google을 처음 접하거나 팀의 인프라와 아키텍처에 익숙하지 않은 경우 광범위한 온보딩을 거칩니다. 온보딩의 일환으로 스타일 가이드, 권장사항, 개발 가이드를 학습하고 직접 실습을 수행합니다. 또한 신입 엔지니어는 개별 변경 목록 제출마다 추가 수준의 승인을 받아야 합니다. 특정 프로그래밍 언어 변경사항에 대한 승인은 전문성을 바탕으로 엄격한 기대치를 통과하고 해당 프로그래밍 언어의 가독성을 갖춘 엔지니어가 부여합니다. 모든 엔지니어가 프로그래밍 언어 가독성을 갖출 수 있습니다. 대부분의 팀에는 코딩하는 프로그래밍 언어에 대한 승인자가 여러 명 있습니다.
속도를 안전하게 개선하는 원점 회귀
원점 회귀는 테스트 및 검증을 개발 프로세스 초기 단계로 이동하는 원칙입니다. 이 원칙은 버그를 발견하고 수정하는 데 드는 비용이 출시 프로세스 후반으로 갈수록 급격히 증가한다는 관찰에 기반합니다. 극단적인 경우 고객이 프로덕션 환경에서 발견한 버그를 고려해 보세요. 이 버그는 고객의 워크로드와 애플리케이션에 부정적인 영향을 미칠 수 있으며, 관련 엔지니어링팀에서 버그를 완화하기 전에 고객이 Cloud Customer Care 프로세스를 거쳐야 할 수도 있습니다. 문제를 해결하도록 할당된 엔지니어가 버그가 포함된 변경사항을 처음 도입한 엔지니어와 다른 경우 새 엔지니어가 코드 변경사항을 숙지해야 하므로 버그를 재현하고 결국 수정하는 데 걸리는 시간이 늘어날 가능성이 높습니다. 이 전체 프로세스를 진행하려면 고객과 Google Cloud 지원팀에서 많은 시간을 투자해야 하며 엔지니어는 문제를 해결하기 위해 진행 중인 작업을 중단해야 합니다.
반대로 엔지니어가 개발 중인 변경사항을 작업하는 동안 자동 테스트 실패에서 포착하는 버그를 고려해 보세요. 엔지니어가 테스트 실패를 확인하면 즉시 문제를 해결할 수 있습니다. Google의 코딩 표준에 따라 엔지니어는 테스트가 실패한 변경사항을 제출할 수도 없습니다. 이렇게 조기에 감지하면 고객이 영향을 받지 않으면서 엔지니어가 버그를 수정할 수 있으며 컨텍스트 전환 오버헤드가 없습니다.
후자의 시나리오는 관련된 모든 사람에게 훨씬 더 바람직합니다. 따라서 Google Cloud는 수년간 이 원점 회귀 원칙에 많은 투자를 하여 기존에 변경사항 검증 및 출시 단계에서 수행되었던 테스트를 개발 루프로 직접 옮겼습니다. 현재 엔지니어가 코드 변경사항을 제안하는 동안 모든 단위 테스트, 가장 큰 통합 테스트를 제외한 모든 테스트, 광범위한 정적 및 동적 분석이 동시에 완료됩니다.
자동 사전 제출 테스트에서 코딩 표준 적용
사전 제출 테스트는 특정 디렉터리에 변경사항이 제출되기 전에 실행되는 검사입니다. 사전 제출 테스트는 변경사항과 관련된 단위 테스트 및 통합 테스트이거나 모든 변경사항에 대해 실행되는 일반 테스트(예: 정적 및 동적 분석)일 수 있습니다. 이전에는 사용자가 코드베이스에 변경사항을 제출하기 전에 맨 마지막 단계로 사전 제출 테스트가 실행되었습니다. 현재는 원점 회귀 원칙과 CI 구현 덕분에 엔지니어가 개발 환경에서 코드를 변경하는 동안과 변경사항을 모노레포에 병합하기 전에 지속적으로 사전 제출 테스트를 실행합니다. 엔지니어는 개발 UI에서 클릭 한 번으로 사전 제출 테스트 모음을 수동으로 실행할 수도 있으며 모든 사전 제출 테스트는 사람이 코드를 검토하기 전에 각 변경 목록에 대해 자동으로 실행됩니다.
사전 제출 테스트 모음은 일반적으로 단위 테스트, 퍼즈 테스트(퍼징), 견고한 통합 테스트, 정적 및 동적 코드 분석을 다룹니다. Google 전체에서 널리 사용되는 핵심 라이브러리 또는 코드에 대한 변경사항의 경우 개발자는 전역 사전 제출을 실행합니다. 전역 사전 제출은 전체 Google 코드베이스를 대상으로 변경사항을 테스트하여 제안된 변경사항이 다른 프로젝트나 시스템에 부정적인 영향을 미칠 위험을 최소화합니다.
단위 및 통합 테스트
철저한 테스트는 코드 개발 프로세스의 핵심입니다. 모든 엔지니어는 코드 변경사항에 대한 단위 테스트를 작성해야 하며 Google은 예상되는 동작을 검증할 수 있도록 프로젝트 수준에서 코드 적용 범위를 지속적으로 추적합니다. 또한 중요한 사용자 여정에는 필요한 모든 구성요소와 종속 항목의 기능을 검증하는 통합 테스트가 있어야 합니다.
단위 테스트와 가장 큰 통합 테스트를 제외한 모든 테스트는 즉시 완료되도록 설계되었으며 분산 환경에서 높은 동시 로드를 통해 점진적으로 실행되므로 빠르고 지속적인 자동 개발 의견을 얻을 수 있습니다.
퍼징
단위 테스트와 통합 테스트는 사전 결정된 입력과 출력으로 예상되는 동작을 검증하는 데 도움이 되는 반면, 퍼징은 보안 취약점이나 비정상 종료로 이어질 수 있는 숨어 있는 결함이나 약점이 노출되도록 애플리케이션에 무작위 입력을 쏟아붓는 기법입니다. 퍼징을 사용하면 소프트웨어의 잠재적 약점을 사전에 식별하고 해결하여 고객이 변경사항과 상호작용하기 전에 제품의 전반적인 보안과 신뢰성을 향상시킬 수 있습니다. 이 테스트의 무작위성은 사용자가 Google이 예상치 못한 흥미로운 방식으로 Google 제품과 상호작용하는 경우가 있고 Google이 퍼징을 통해 직접 고려하지 않은 시나리오를 고려할 수 있으므로 특히 유용합니다.
정적 분석
정적 분석 도구는 Google 개발 워크플로에서 코드 품질을 유지하는 데 중요한 역할을 합니다. 정적 분석은 초기에 정규식으로 린트 작업을 수행하여 문제가 있는 C++ 코드 패턴을 식별하는 것에서 크게 발전했습니다. 현재 정적 분석은 모든 Google Cloud 프로덕션 언어를 다루며 잘못되거나 비효율적이거나 지원 중단된 코드 패턴을 찾습니다.
고급 컴파일러 프런트엔드와 LLM을 사용하면 엔지니어가 코드를 작성하는 동안 개선사항이 자동으로 제안될 수 있습니다. 제안된 각 코드 변경사항은 정적 분석을 통해 검토됩니다. 시간 경과에 따라 새로운 정적 검사가 추가되면 전체 코드베이스가 규정 준수 여부에 대해 지속적으로 스캔되고 수정사항이 자동으로 생성되어 검토를 위해 전송됩니다.
동적 분석
정적 분석은 문제를 야기시킬 수 있는 알려진 코드 패턴을 식별하는 데 중점을 두는 반면, 동적 분석은 다른 방식을 사용합니다. 코드를 컴파일하고 실행하여 메모리 위반 및 경합 상태와 같이 실행 중에만 표시되는 문제를 발견하는 작업이 포함됩니다. Google은 동적 분석 활용에 대한 오랜 노하우를 보유하고 있으며 개발자 커뮤니티와 다음을 포함한 여러 도구를 공유하고 있습니다.
- AddressSanitizer: 버퍼 오버플로 및 use-after-free와 같은 메모리 오류를 감지합니다.
- ThreadSanitizer(C++, Go): 데이터 경합 및 기타 스레딩 버그를 찾습니다.
- MemorySanitizer: 초기화되지 않은 메모리 사용량을 발견합니다.
이러한 도구와 유사한 도구는 정적 분석만으로는 감지할 수 없는 복잡한 버그를 포착하는 데 필수적입니다. Google은 정적 분석과 동적 분석을 모두 사용하여 코드가 잘 구성되고 알려진 문제가 없으며 실제 시나리오에서 예상대로 작동하도록 노력하고 있습니다.
사람이 코드를 검토하여 변경사항과 테스트 결과 검증
엔지니어가 코드에서 중요한 마일스톤에 도달하여 기본 저장소에 통합하려는 경우 변경 목록을 제안하여 코드 검토를 시작합니다. 코드 검토 요청은 다음으로 구성됩니다.
- 변경사항의 목적과 추가 컨텍스트를 캡처하는 내용
- 실제로 수정된 코드
- 수정된 코드의 단위 테스트 및 모든 통합 테스트
- 자동 사전 제출 테스트 결과
개발 프로세스에서 이 단계에 이르면 다른 사람이 개입합니다. 지정된 검토자 한 명 이상이 연결된 테스트와 사전 제출 결과를 가이드로 사용하여 변경 목록의 정확성과 명확성을 주의 깊게 검토합니다. 각 코드 디렉터리에는 코드베이스의 하위 집합 품질 보장을 담당하는 검토자와 해당 디렉터리 내에서 변경사항을 적용하려면 승인이 필요한 검토자가 지정되어 있습니다. 검토자와 엔지니어가 협력하여 제안된 코드 변경사항과 관련하여 발생할 수 있는 문제를 파악하고 해결합니다. 변경 목록이 Google 표준을 충족하면 검토자가 승인('LGTM': '좋아요'의 줄임말)합니다. 그러나 엔지니어가 아직도 사용 중인 프로그래밍 언어에 대한 교육을 받고 있으면 프로그래밍 언어 가독성을 갖춘 전문가가 추가로 승인해야 합니다.
변경 목록이 테스트 및 자동 검사를 통과하고 LGTM을 받은 후에는 변경사항을 제안한 엔지니어는 코드를 최소한으로 변경할 수 있습니다. 상당한 변경사항이 있으면 승인이 무효화되고 한 번 더 검토해야 합니다. 사소한 변경사항이라도 원래 검토자에게 자동으로 신고됩니다. 엔지니어가 최종 코드를 제출하면 변경 목록이 모노레포에 병합되기 전에 또 한 번의 전체 사전 제출 테스트를 거칩니다. 테스트에 실패하면 제출이 거부되고 개발자와 검토자에게 시정 조치를 취한 후에 변경사항을 다시 제출하라는 알림이 전송됩니다.
안전한 출시 검증
사전 제출 테스트는 포괄적이지만 Google의 테스트 프로세스는 여기서 끝나지 않습니다. 팀에는 초기 코드 검토 중에 실행할 수 없는 추가 테스트(예: 대규모 통합 테스트)가 있는 경우가 많습니다(실행하는 데 시간이 더 오래 걸리거나 충실도 높은 테스트 환경이 필요할 수 있음). 또한 팀은 외부 종속 항목의 변경과 같이 관리할 수 없는 요인으로 인한 모든 실패를 인식해야 합니다.
바로 이 점이 Google에서 개발 단계 후에 인증 단계를 요구하는 이유입니다. 이 검증 단계에서는 다음 다이어그램과 같이 연속 빌드 및 테스트 프로세스를 사용합니다.
이 프로세스는 마지막 실행 이후 직접 또는 간접 변경사항의 영향을 받는 모든 코드를 주기적으로 테스트합니다. 모든 실패는 담당 엔지니어링팀으로 자동 에스컬레이션됩니다. 대부분의 경우 시스템은 중단의 원인이 되는 변경 목록을 자동으로 식별하고 롤백할 수 있습니다. 이러한 대규모 통합 테스트는 부분적으로 시뮬레이션된 환경부터 전체 물리적 위치에 이르기까지 다양한 스테이징 환경에서 실행됩니다.
테스트에는 기본 신뢰성과 안전부터 비즈니스 로직에 이르기까지 다양한 검증 목표가 있습니다. 이러한 검증 테스트에는 다음과 같은 코드 테스트가 포함됩니다.
- 필수 기능을 제공하는 기능으로, 대규모 통합 테스트를 통해 테스트됩니다.
- 비즈니스 요구사항을 충족하는 기능으로, 고객 워크로드의 합성 표현으로 테스트됩니다.
- 기본 인프라 오류를 견디는 기능으로, 스택 전체에 오류 삽입을 통해 테스트됩니다.
- 제공 용량을 유지하는 기능으로, 부하 테스트 프레임워크로 테스트됩니다.
- 안전하게 롤백하는 기능
안전한 출시
가장 강력한 개발, 테스트, 인증 프로세스를 사용하더라도 사용자에게 부정적인 영향을 미치는 결함이 프로덕션 환경에 잠입하는 경우가 있습니다. 이 섹션에서는 Google Cloud 출시 프로세스가 결함이 있는 변경사항의 영향을 제한하고 회귀를 빠르게 감지하는 방법을 설명합니다. 이 방식은 바이너리, 구성, 스키마 업데이트, 용량 변경사항, 액세스 제어 목록을 포함하여 프로덕션에 배포된 모든 유형의 변경사항에 적용됩니다.
변경사항 전파 및 감독
Google은 Google Cloud 전체에 변경사항을 배포할 때 일관된 방식을 적용하여 부정적인 고객 영향을 최소화하고 문제를 개별 논리적 및 물리적 장애 도메인으로 격리합니다. 이 프로세스는 수십 년간의 SRE 신뢰성 관행과 전 세계 규모의 모니터링 시스템을 기반으로 하여 잘못된 변경사항을 최대한 빨리 감지하고 완화합니다. 신속한 감지를 통해 고객에게 더 빠르게 알리고 유사한 오류가 다시 발생하지 않도록 체계적으로 수정 조치를 취할 수 있습니다.
대부분의 Google Cloud 제품은 리전 또는 영역별입니다. 즉, 리전 A에서 실행되는 리전 제품은 리전 B에서 실행되는 같은 제품과 관련이 없습니다. 마찬가지로 리전 A 내 영역 C에서 실행되는 영역 제품은 리전 A 내 영역 D에서 실행되는 같은 영역 제품과 관련이 없습니다. 이 아키텍처는 다른 리전이나 단일 리전 내 다른 영역에 영향을 미치는 서비스 중단 위험을 최소화합니다. IAM 또는 Google Cloud 콘솔과 같은 일부 서비스는 모든 리전에 걸쳐 전 세계적으로 일관된 레이어를 제공하므로 이러한 서비스를 전역 서비스라고 합니다. 전역 서비스는 단일 장애점을 방지하고 지연 시간을 최소화하기 위해 여러 리전에 복제됩니다. 공유 Google Cloud 출시 플랫폼은 서비스가 지역별, 리전별 또는 전역인지 인식하고 적절하게 프로덕션 변경사항을 조정합니다.
Google Cloud 출시 프로세스는 여러 대상 위치에 배포된 서비스의 모든 복제본을 웨이브로 분할합니다. 초기 웨이브에는 소수의 복제본이 포함되며 업데이트는 순차적으로 진행됩니다. 초기 웨이브에서는 문제를 최대한 빨리 감지하기 위해 대부분의 고객 워크로드 보호와 워크로드 다양성에 대한 노출 극대화 사이에서 균형을 유지하며 일반적인 고객 워크로드 패턴을 모방한 합성 워크로드를 포함합니다.
서비스 복제본이 대상 위치에서 업데이트되어도 출시가 성공적으로 유지되면 후속 출시 웨이브 크기가 점진적으로 증가하고 더 많은 동시 실행이 도입됩니다. Google Cloud 위치 수를 고려하려면 약간의 동시 로드가 필요하지만 서로 다른 웨이브에 있는 위치를 동시에 업데이트할 수 없습니다. 웨이브가 야간이나 주말로 확장되는 경우 진행 상황을 완료할 수 있지만 출시를 관리하는 팀의 업무 시간이 시작될 때까지는 새 웨이브를 시작할 수 없습니다.
다음 다이어그램은 Google Cloud 전체에서 리전 제품과 서비스에 사용하는 출시 로직을 보여주는 워크플로 예시입니다.
Google Cloud 출시 프로세스는 카나리아 분석 서비스(CAS)를 사용하여 출시 기간 동안 A/B 테스트를 자동화합니다. 일부 복제본은 카나리아(서비스 변경사항의 일부 및 시간 제한된 배포)가 되고 나머지 복제본은 변경사항이 포함되지 않은 통제 그룹을 구성합니다. 출시 프로세스의 각 단계에는 다음 단계로 진행하기 전에 서비스의 모든 기능이 제대로 실행되고 CAS에서 잠재적 이상을 감지할 수 있도록 느리게 발생하는 문제를 포착하는 베이킹 시간이 있습니다. 베이킹 시간은 느리게 발생하는 문제 감지와 개발 속도 간의 균형을 맞추기 위해 신중하게 정의됩니다. Google Cloud 출시는 일반적으로 1주일이 소요됩니다.
다음 다이어그램에서는 CAS 워크플로 모습을 간략하게 보여줍니다.
워크플로는 출시 도구가 카나리아 복제본에 변경사항을 배포하는 것으로 시작됩니다. 그런 다음 출시 도구에서 CAS에 확인 결과를 요청합니다. CAS는 통제 그룹을 기준으로 카나리아 복제본을 평가하고 통과 또는 실패 확인 결과를 반환합니다. 상태 신호가 실패하면 서비스 소유자에게 알림이 생성되고 출시 실행 단계가 일시중지되거나 롤백됩니다. 변경사항으로 인해 외부 고객에게 서비스 중단이 발생하면 외부 이슈가 선언되고 Personalized Service Health 서비스를 통해 영향을 받는 고객에게 이를 알립니다. 또한 이슈는 내부 검토를 트리거합니다. Google의 사후 검토 철학은 유사한 오류가 다시 발생할 가능성을 최소화하기 위해 적절한 시정 조치를 파악하고 적용하는 것을 보장합니다.
신호 모니터링 및 출시 후 안전
소프트웨어 결함이 항상 즉각적으로 나타나지 않으며 일부 결함은 특정 상황이 발생해야 트리거될 수 있습니다. 따라서 Google은 출시가 완료된 후에도 프로덕션 시스템을 계속 모니터링합니다. 수년간 출시 시 문제가 즉시 발생하지 않더라도 잘못된 출시가 프로덕션 사고의 원인일 가능성이 매우 높다는 점을 확인했습니다. 따라서 Google의 프로덕션 플레이북은 이슈 대응 담당자가 최근 출시와 관찰된 문제를 연관시키고 이슈 대응 담당자가 최근 변경사항을 이슈 근본 원인에서 제외시킬 수 없는 경우 기본적으로 최근 출시를 롤백하도록 안내합니다.
출시 후 모니터링은 Google에서 출시 기간 동안 자동 A/B 분석에 사용하는 같은 모니터링 신호 집합을 기반으로 합니다. Google Cloud 모니터링 및 알림 철학은 내성(흰색 상자라고도 함) 및 합성(검은색 상자라고도 함)이라는 두 가지 유형의 모니터링을 결합합니다. 내성 모니터링은 CPU 사용률, 메모리 사용률, 기타 내부 서비스 데이터와 같은 측정항목을 사용합니다. 합성 모니터링은 고객의 관점에서 시스템 동작을 살펴보고 서비스 오류율과 프로버 서비스의 합성 트래픽에 대한 응답을 추적합니다. 합성 모니터링은 증상 중심이며 활성 문제를 식별하는 반면, 내성 모니터링을 사용하면 확인된 문제를 진단하고 경우에 따라 임박한 문제를 식별할 수 있습니다.
일부 고객에게만 영향을 미치는 문제를 감지할 수 있도록 Google에서는 고객 워크로드를 관련 워크로드의 사용자 집단으로 클러스터링합니다. 동질 집단 성능이 표준에서 벗어나면 바로 알림이 트리거됩니다. 이러한 알림을 사용하면 합산된 성능이 정상적으로 보여도 고객별 회귀를 감지할 수 있습니다.
소프트웨어 공급망 보호
Google Cloud팀에서 변경사항을 도입할 때마다 Google은 Borg용 Binary Authorization(BAB)이라는 보안 검사를 사용하여 내부자 위험으로부터 소프트웨어 공급망과 Cloud 고객을 보호합니다. BAB는 코드 검토 단계에서 시작하여 프로덕션에 배포된 코드 및 구성에 대한 감사 추적을 만듭니다. 프로덕션 무결성이 보장되도록 BAB는 다음 기준을 충족하는 변경사항만 허용합니다.
- 조작 방지 및 서명됨
- 식별된 빌드 당사자와 식별된 소스 위치에서 가져옴
- 코드 작성자와 다른 당사자가 검토하고 명시적으로 승인함
자체 소프트웨어 개발 수명 주기에 같은 개념을 적용하는 데 관심이 있는 경우 Google은 소프트웨어 아티팩트에 대한 공급망 등급(SLSA)이라는 개방형 사양에 BAB 주요 개념을 포함합니다. SLSA는 프로덕션 환경에서 코드를 개발하고 실행하기 위한 보안 프레임워크 역할을 합니다.
결론
Google Cloud는 Google이 수십 년간 개발 우수성을 위해 투자한 결과물입니다. 코드 상태와 프로덕션 상태는 Google의 모든 엔지니어링팀에 주입된 문화적 요소입니다. Google의 설계 검토 프로세스를 통해 코드 및 프로덕션 상태에 미치는 영향을 초기에 고려할 수 있습니다. Google의 개발 프로세스는 원점 회귀 원칙과 다양한 테스트를 기반으로 하여 설계 아이디어가 안전하고 올바르게 구현되도록 합니다. Google의 인증 프로세스는 대규모 통합 및 외부 종속 항목을 포함하도록 테스트를 더욱 확장합니다. 마지막으로 출시 플랫폼을 사용하면 특정 변경사항이 실제로 예상대로 작동한다는 확신을 점진적으로 쌓을 수 있습니다. 개념 설계에서 프로덕션에 이르기까지 Google 방식을 통해 개발 속도와 신뢰성에 대한 Google Cloud 고객의 기대치를 충족할 수 있습니다.