개발자 플랫폼 및 컨테이너화된 애플리케이션을 운영하기 위해서는 여러 관리 태스크를 지속적으로 수행해야 합니다. 예를 들어 이러한 태스크에는 템플릿에서 새 애플리케이션 만들기, 새 개발자 그룹이 개발자 플랫폼을 사용하도록 권한 부여, 용량 요구 계획, 런타임 문제 디버깅 등이 포함됩니다.
이러한 운영 작업은 자동화하거나 수동으로 수행할 수 있습니다.
일반적인 자동화된 운영 작업
청사진은 단순 API 유형의 웹훅 트리거 형태로 가장 일반적인 태스크에 대해 자동화 기능을 제공합니다. 트리거는 소스 제어 저장소 중 하나에서 시작되는 웹훅 이벤트에 자동으로 연결됩니다. 개발자 플랫폼 개발자는 다른 트리거를 연결할 수 있습니다. 일반적으로 개발자 플랫폼 개발자는 양식이 제출될 때 웹훅 트리거를 호출하는 간단한 웹 양식일 수 있는 개발자 포털을 작성합니다.
다음 표에서는 웹훅 트리거를 사용해서 청사진이 자동화하는 일반적인 태스크에 대해 설명합니다. 태스크 빈도는 여러 요인에 따라 달라지기 때문에 설명 목적으로만 제공되었습니다. 태스크가 반드시 정확한 간격으로 반복될 필요는 없습니다.
| 태스크 | 사용자 | 설명 | 태스크 빈도 |
|---|---|---|---|
테넌트를 추가합니다. |
개발자 플랫폼 관리자 |
관리자가 개발자 포털에서 양식을 제출합니다. 새 테넌트 양식 필드에는 테넌트 이름과 팀 멤버가 포함됩니다. 자동화된 트리거가 새 테넌트에 대한 리소스를 만듭니다. |
매년 2~3회 |
기존 애플리케이션 템플릿을 기반으로 애플리케이션을 추가합니다. |
애플리케이션 개발자 |
개발자가 개발자 포털에서 양식을 제출합니다. 새 애플리케이션 양식 필드에는 테넌트 이름, 애플리케이션 이름, 기본 애플리케이션 템플릿이 포함됩니다. 자동화된 트리거가 새 애플리케이션에 대한 리소스를 만듭니다. |
매년 2~3회 |
애플리케이션의 소스 코드 변경사항을 빌드하고 개발 환경에 배포합니다. |
애플리케이션 개발자 |
개발자가 소스 코드를 수정하고, 코드를 로컬로 테스트하고, 코드를 커밋합니다. 청사진은 로컬 개발자 워크플로에 포함되지 않지만 Skaffold 툴에서 로컬 빌드 단계가 지원됩니다. |
애플리케이션별로 매일 2~3회 |
애플리케이션에 대해 YAML 구성 변경사항을 개발 환경에 배포합니다. YAML 구성 변경사항 예시는 배포 리소스의 CPU를 늘리는 것입니다. |
애플리케이션 개발자 |
개발자가 애플리케이션 구성을 수정하고 변경사항을 커밋합니다. |
애플리케이션별로 매주 2~3회 |
애플리케이션 인프라 변경사항을 개발 환경에 배포합니다. 애플리케이션 인프라는 애플리케이션 프로젝트의 클라우드 리소스입니다. 변경사항 예시는 PostgreSQL용 AlloyDB 인스턴스의 CPU 수를 늘리는 것입니다. |
애플리케이션 개발자 |
개발자가 애플리케이션 리소스 Terraform 프로젝트를 수정하고 변경사항을 커밋합니다. 개발자가 개발자 포털에서 양식을 제출합니다. 자동화된 트리거가 계획을 시작하고 파이프라인을 적용합니다. |
매년 여러 번 |
애플리케이션 변경사항을 개발 환경에서 비프로덕션 환경으로(또는 비프로덕션 환경에서 프로덕션 환경으로) 승격합니다. 애플리케이션 변경사항에는 새로운 애플리케이션 이미지 또는 애플리케이션 YAML 구성 변경사항이 포함될 수 있습니다. |
애플리케이션 운영자 |
운영자는 개발 브랜치에서 비프로덕션 브랜치로(또는 비프로덕션 브랜치에서 프로덕션 브랜치로) 변경사항을 병합합니다. 운영자가 출시를 감독합니다. |
애플리케이션별로 매주 수 차례 |
애플리케이션 인프라 변경사항을 개발 환경에서 비프로덕션 환경으로(또는 비프로덕션 환경에서 프로덕션 환경으로) 승격합니다. |
애플리케이션 운영자 |
운영자가 개발 브랜치에서 비프로덕션 브랜치로(또는 비프로덕션 브랜치에서 프로덕션 브랜치로) 변경사항을 선택합니다. 운영자가 출시를 감독합니다. |
애플리케이션별로 매분기 수 차례 |
일반적인 수동 운영 작업
일부 개발자 플랫폼 운영은 본질적으로 구조화 수준이 낮을 수 있으며, 개발자 플랫폼을 통한 자동화 기능이 사용되지 않습니다. 이 청사진을 기반으로 자신만의 플레이북을 개발하고 Google Cloud 콘솔에서 이러한 태스크를 수행할 수 있습니다.
다음 표에서는 이러한 자동화되지 않은 태스크에 대해 설명합니다. 태스크 빈도는 여러 요인에 따라 달라지기 때문에 설명 목적으로만 제공되었습니다. 태스크가 반드시 정확한 간격으로 반복될 필요는 없습니다.
| 태스크 | 사용자 | 설명 | 태스크 빈도 |
|---|---|---|---|
새 애플리케이션 템플릿을 정의합니다. |
개발자 플랫폼 개발자 |
개발자가 청사진 템플릿을 기반으로 애플리케이션 템플릿을 수정하거나 템플릿을 새 언어로 이식합니다. |
매년 2~3회 |
개발 환경에서 서비스 런타임 오류를 조사합니다. |
애플리케이션 개발자 |
개발자가 Google Cloud 콘솔에서 로그 탐색기 및 측정항목 탐색기를 사용하여 테넌트 및 애플리케이션의 오류 로그, 모니터링 측정항목, 시계열 데이터를 검토합니다. |
매월 2~3회 |
프로덕션 및 비프로덕션 환경에서 서비스 런타임 오류를 조사합니다. |
애플리케이션 운영자 |
운영자가 Google Cloud 콘솔에서 로그 탐색기 및 측정항목 탐색기를 사용하여 테넌트 및 애플리케이션의 오류 로그, 모니터링 측정항목, 시계열 데이터를 검토합니다. |
매월 2~3회 |
빌드 오류를 조사합니다. |
애플리케이션 개발자 |
개발자가 Google Cloud 콘솔에서 빌드 상태 및 로그를 포함하여 Cloud Build 기록을 확인합니다. |
매주 2~3회 |
개발 환경에서 배포 오류를 조사합니다. |
애플리케이션 개발자 |
개발자가 Google Cloud 콘솔에서 Cloud Deploy 출시 및 출시 기록을 보고 성공 상태, 배포 시도 로그, 오류를 확인합니다. |
매월 2~3회 |
비프로덕션 및 프로덕션 환경에서 배포 오류를 조사합니다. |
애플리케이션 운영자 |
운영자가 Google Cloud 콘솔에서 Cloud Deploy 출시 및 출시 기록을 보고 성공 상태, 배포 시도 로그, 오류 로그를 확인합니다. |
매월 2~3회 |
GKE 문제 디버깅을 위해 클러스터에 연결합니다. |
개발자 플랫폼 관리자 |
관리자가 Connect 게이트웨이를 사용해서 비공개 클러스터에 연결합니다. 예약되지 않은 포드와 같은 일반적인 문제의 경우 관리자가 Google Cloud 콘솔에서 일반적인 문제(예: 예약되지 않은 포드)에 대한 정보를 검토할 수 있습니다. |
매월 2~3회 |
용량을 계획하고 비용을 최적화합니다. |
개발자 플랫폼 관리자 |
관리자가 Google Cloud 콘솔에서 범위 또는 네임스페이스로 집계된 GKE 리소스 사용률을 검토합니다. |
월별 반복 태스크로 예약됩니다. |
노드 풀 크기 조정, 추가, 삭제를 수행합니다. |
개발자 플랫폼 관리자 |
관리자가 IaC를 적절히 수정하고 애플리케이션을 다시 배포합니다. |
용량 계획에 따라 수행됩니다. |
보안 상황을 확인합니다. |
개발자 플랫폼 관리자 |
관리자가 GKE 보안 상황 대시보드를 사용해서 취약점 및 표준 규정 준수 상태를 확인합니다. |
월별 반복 태스크로 예약됩니다. |
클러스터 시스템 소프트웨어 버전을 업그레이드합니다(예: Kubernetes 버전). |
개발자 플랫폼 관리자 |
관리자가 GKE 유지보수 기간 및 예외를 사용해서 계획된 시간에만 업그레이드를 허용합니다. 관리자가 처음에 개발 환경에서 개방형 업그레이드 창을 사용합니다. 업그레이드 상태를 평가하고 나서 개발자가 비프로덕션 환경을 업그레이드한 후 프로덕션 환경을 업그레이드합니다. |
분기별 반복 태스크로 예약됩니다. |
중요한 클러스터 보안 업데이트를 설치합니다. |
없음 |
GKE에서 자동으로 수행됩니다. |
매년 2~3회 |
리전 장애 조치를 테스트합니다. |
개발자 플랫폼 관리자 및 애플리케이션 관리자 |
관리자가 환경에 대한 리전별 장애 조치를 적절하게 예약하고 수동으로 시작합니다. |
재해 복구 운영 계획에 따라 매년 |
리전을 추가합니다. |
개발자 플랫폼 관리자, 개발자 플랫폼 개발자, 애플리케이션 관리자 |
개발자 플랫폼 관리자가 새 리전에 추가 GKE 클러스터를 배포합니다. 관리자가 애플리케이션 템플릿을 업데이트해서 관련 환경에 대해 새 배포 단계를 추가합니다. 그런 후 애플리케이션 운영자가 변경사항을 통합하여 새 리전을 포함하도록 배포 시퀀스를 추가합니다. |
매우 드물게 수행 |
새 리전으로 이동합니다. |
개발자 플랫폼 관리자, 개발자 플랫폼 개발자, 애플리케이션 관리자 |
사용자가 리전 추가에 설명된 대로 새 리전을 추가합니다. 새 구성을 테스트하고 나서 사용자가 이전 리전을 삭제합니다. |
매우 드물게 수행 |
다음 단계
- 개발자 플랫폼의 비용 및 기여 분석 관리(이 시리즈의 다음 문서) 자세히 알아보기