이 문서에서는 확장 가능하고 복원력이 우수한 앱을 만들기 위한 몇 가지 패턴과 방식을 소개하고, 많은 현대적인 아키텍처 구성의 두 가지 기본 목표를 설명합니다. 잘 설계된 앱은 수요 증감에 따라 크기가 원활하게 조정되며 서비스 중단을 견딜 수 있을 만큼 충분히 복원력이 우수합니다. 이러한 요구사항을 충족하는 앱을 빌드하고 운영하기 위해서는 신중한 계획과 설계가 필요합니다.
확장성: 수요에 따른 용량 조정
확장성은 시스템에서 리소스를 추가하거나 삭제하여 작업량 변화에 대응하는 시스템 능력을 나타내는 척도입니다. 예를 들어 확장성이 높은 웹 앱은 사용자가 한 명이거나 여러 명이어도 올바르게 작동하고, 트래픽 양이 갑자기 증가하거나 감소하더라도 이를 단계적으로 처리할 수 있습니다.
앱에서 소비되는 리소스를 조정할 수 있는 유연성은 클라우드로 이동하기 위한 중요한 비즈니스 요인입니다. 올바르게 설계할 수 있다면, 성능 또는 사용자 환경을 훼손하지 않고도 사용률이 낮은 리소스를 삭제함으로써 비용을 줄일 수 있습니다. 이와 비슷하게, 트래픽 사용량이 많은 기간에는 리소스를 추가하여 사용자 환경을 적정 상태로 유지 관리할 수 있습니다. 이렇게 해서 수요를 충족하는 데 필요한 리소스만 앱에 사용할 수 있습니다.
Google Cloud는 확장성과 효율성이 뛰어난 앱을 빌드하는 데 도움이 되는 제품 및 기능을 제공합니다.
- Compute Engine 가상 머신과 Google Kubernetes Engine(GKE) 클러스터는 자동 확장 처리와 통합되어 개발자가 정의한 측정항목을 기준으로 리소스 소비를 늘리거나 줄일 수 있게 해줍니다.
- Google Cloud의 서버리스 플랫폼은 0부터 높은 요청 볼륨까지 빠르게 확장되는 관리형 컴퓨팅, 데이터베이스, 기타 서비스를 제공하며 개발자는 자신이 사용한 항목에 대해서만 비용을 지불합니다.
- BigQuery, Spanner, Bigtable과 같은 데이터베이스 제품은 대규모 데이터 크기에서 일관적인 성능을 제공할 수 있습니다.
- Cloud Monitoring은 앱과 인프라 간 측정항목을 제공하여 데이터에 기반한 확장 결정을 내리는 데 도움을 줍니다.
복원력: 장애를 견딜 수 있는 설계
복원력이 우수한 앱은 시스템 구성요소에 장애가 발생해도 계속 작동합니다. 복원력을 얻기 위해서는 아키텍처의 모든 수준에서 적절한 계획이 필요합니다. 복원력은 인프라 및 네트워크 구성 방식과 앱 및 데이터 스토리지 설계 방식에 영향을 줍니다. 복원력은 사람과 문화로도 확장됩니다.
복원력이 우수한 앱은 빌드 및 운영이 쉽지 않습니다. 인프라, 네트워크, 서비스가 여러 레이어로 포함될 수 있는 분산형 앱이 특히 더 그렇습니다. 작업자 실수와 시스템 중단이 발생하고 그에 따라 앱의 복원력을 향상시키는 과정이 상시적으로 진행됩니다. 처음부터 앱을 올바르게 계획하면 앱이 장애를 견딜 수 있는 능력을 향상시킬 수 있습니다. 프로세스 및 조직 문화가 올바르면 장애로부터 얻은 교훈으로 앱의 복원력을 더욱 향상시킬 수 있습니다.
Google Cloud는 가용성과 복원력이 우수한 앱을 빌드하는 데 도움이 되는 도구와 서비스를 제공합니다.
- Google Cloud 서비스는 전 세계 리전과 영역에서 제공되며 가용성 목적에 가장 적합하게 앱을 배포할 수 있게 해줍니다.
- Compute Engine 인스턴스 그룹과 GKE 클러스터는 한 리전에서 사용 가능한 영역에서 분산 및 관리될 수 있습니다.
- Compute Engine 리전별 영구 디스크는 리전의 영역 간에 동기적으로 복제됩니다.
- Google Cloud는 트래픽을 사용자에게 가장 가까운 정상 리전으로 보내는 전역 부하 분산을 포함하여 앱 트래픽을 관리할 수 있는 다양한 부하 분산 옵션을 제공합니다.
- Google Cloud의 서버리스 플랫폼에는 기본 제공 중복성과 부하 분산을 제공하는 관리형 컴퓨팅 및 데이터베이스 제품이 포함됩니다.
- Google Cloud는 앱 빌드 및 배포를 자동화할 수 있도록 기본 도구와 인기 있는 오픈소스 기술을 통합하여 CI/CD를 지원합니다.
- Cloud Monitoring은 앱 및 인프라 간의 측정항목을 제공하여, 앱 성능 및 상태에 대한 데이터 기반의 의사결정을 도와줍니다.
요인 및 제약조건
앱은 다양한 필요와 원인에 따라 확장성 및 복원력 향상이 요구됩니다. 그리고 확장성 및 복원력 목표를 달성하지 못하게 방해하는 제약조건도 존재할 수 있습니다. 이러한 요구사항과 제약조건의 상대적 중요성은 앱 유형, 사용자 프로필, 조직 규모 및 성숙도에 따라 달라질 수 있습니다.
요인
각 요구사항의 중요도를 구분하기 위해서는 조직 내 여러 부분의 요인을 고려해야 합니다.
비즈니스 요인
비즈니스 측면의 일반적인 요인은 다음과 같습니다.
- 비용 및 리소스 소비를 최적화합니다.
- 앱 다운타임을 최소화합니다.
- 사용량이 많은 기간에 사용자 수요를 충족시킬 수 있는지 확인합니다.
- 서비스 품질 및 가용성을 향상시킵니다.
- 중단 중에도 사용자 환경과 신뢰 수준이 유지 관리되는지 확인합니다.
- 변화하는 시장 수요에 맞게 유연성과 민첩성을 향상시킵니다.
개발 요인
개발 측면의 일반적인 요인은 다음과 같습니다.
- 장애 조사에 걸리는 시간을 최소화합니다.
- 새 기능 개발에 투자되는 시간을 늘립니다.
- 자동화를 통해 반복적인 작업을 최소화합니다.
- 최신 산업 패턴 및 방식을 사용하여 앱을 빌드합니다.
운영 요인
운영 측면에서 고려해야 할 요구사항은 다음과 같습니다.
- 작업자 개입이 필요한 장애 빈도를 줄입니다.
- 장애 자동 복구 능력을 키웁니다.
- 자동화를 통해 반복적인 작업을 최소화합니다.
- 특정 구성요소의 장애로 인한 영향을 최소화합니다.
제약조건
제약조건은 앱의 확장성 및 복원력을 늘릴 수 있는 능력을 제한할 수 있습니다. 잘못된 설계 결정으로 인해 다음과 같은 제약조건이 발생하거나 커지지 않도록 주의해야 합니다.
- 확장이 까다로운 하드웨어 또는 소프트웨어에 대한 종속 항목
- 고가용성 구성에서 운영이 까다로운 하드웨어 또는 소프트웨어에 대한 종속 항목
- 앱 간 종속 항목
- 라이선스 제한
- 개발 및 운영 팀의 기술 또는 경험 부족
- 조직 내 자동화 저항
패턴 및 방식
이 문서의 나머지 부분에서는 확장성과 복원력이 우수한 앱을 빌드하는 데 도움이 되는 패턴과 방식에 대해 설명합니다. 이러한 패턴은 인프라 설계, 앱 아키텍처, 스토리지 선택, 배포 프로세스, 조직 문화를 포함하여 앱 수명 주기의 모든 부분에 영향을 줍니다.
패턴은 크게 세 가지 범주로 나눌 수 있습니다.
- 자동화. 확장성과 복원력이 우수한 앱을 빌드하기 위해서는 자동화가 필요합니다. 인프라 프로비저닝, 테스트, 앱 배포를 자동화하면 일관성과 속도가 향상되고 작업자 오류가 최소화됩니다.
- 느슨한 결합. 시스템을 느슨하게 결합된 독립적인 구성요소로 취급하면 유연성과 복원력이 향상됩니다. 독립성에는 리소스의 물리적 분산 방식과 앱 및 스토리지 설계 방식이 포함됩니다.
- 데이터 기반 설계. 앱 동작을 이해하기 위해서는 측정항목을 수집하는 것이 매우 중요합니다. 앱을 확장할 시간이나 특정 서비스가 비정상 상태인지 여부에 대한 의사결정은 데이터를 기반으로 해야 합니다. 측정항목과 로그는 핵심 기능이어야 합니다.
인프라 프로비저닝 자동화
환경 내 일관성을 향상시키고 배포 성공률을 높이려면 자동화를 통해 바뀌지 않는 인프라를 만들어야 합니다.
인프라를 코드로 취급
코드형 인프라(IaC)는 인프라 프로비저닝과 구성을 애플리케이션 코드를 처리하는 것과 동일한 방식으로 취급하는 기법입니다. 프로비저닝 및 구성 논리가 소스 컨트롤에 저장되어, 이에 대해 검색, 버전 관리, 감사를 수행할 수 있습니다. 코드 저장소에 있기 때문에 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 활용할 수 있으며, 따라서 구성 변경사항이 있을 때마다 테스트 및 배포가 자동으로 수행됩니다.
IaC는 인프라 프로비저닝에서 수동 단계를 삭제함으로써 작업자 오류를 최소화하고 앱 및 환경의 일관성과 재현 가능성을 향상시켜 줍니다. 이렇게 IaC를 채택하면 앱의 복원력이 향상됩니다.
Cloud Deployment Manager를 사용하면 유연한 템플릿으로 Google Cloud 리소스 만들기와 관리를 자동화할 수 있습니다. 또는 구성 커넥터를 사용하면 Kubernetes 기술과 워크플로를 사용하여 리소스를 관리할 수 있습니다. 또한 Google Cloud에서는 Terraform, Chef, Puppet과 같은 인기 있는 제3자 IaC 도구를 기본 지원합니다
변경 불가능한 인프라 만들기
변경 불가능한 인프라는 코드형 인프라의 이점을 기반으로 하는 개념입니다. 변경 불가능한 인프라에서는 배포 후 리소스가 절대 수정되지 않아야 합니다. 가상 머신, Kubernetes 클러스터, 방화벽 규칙을 업데이트해야 할 경우에는 소스 저장소에 있는 해당 리소스의 구성을 업데이트해야 합니다. 변경사항을 테스트하고 검사한 후에는 새로운 구성을 사용해서 리소스를 완전히 다시 배포합니다. 즉, 리소스를 조정하는 대신 다시 만들어 버립니다.
변경 불가능한 인프라를 만들면 배포 및 롤백의 예측 가능성이 향상됩니다. 또한 구성 드리프트 및 눈송이 서버와 같은 변경 가능한 인프라에서 일반적인 문제도 완화됩니다. 이렇게 변경 불가능한 인프라를 채택하면 환경의 일관성과 신뢰성이 향상됩니다.
고가용성을 위한 설계
가용성은 서비스를 사용할 수 있는 시간 비율을 측정합니다. 가용성은 전체 서비스 상태를 보여주는 지표로 사용되는 경우가 많습니다. 가용성이 높은 아키텍처는 일반적으로 구성요소 중복 배포를 통해 서비스 가용성을 극대화하는 것을 목표로 합니다. 가장 간단한 구성에서 일반적으로 고가용성에는 컴퓨팅 리소스 분산, 부하 분산, 데이터 복제가 포함됩니다.
물리적인 리소스 분산
Google Cloud 서비스는 전 세계 여러 위치에서 제공됩니다. 이러한 위치는 리전과 영역으로 구분됩니다. 이러한 리전과 영역 간에 앱을 배포하는 방식에 따라 앱의 가용성, 지연 시간, 기타 속성에 영향을 줍니다. 자세한 내용은 Compute Engine 리전 선택 권장사항을 참조하세요.
중복성은 시스템의 전반적인 가용성 증가를 위해 시스템 구성요소를 중복해서 구성하는 것입니다. Google Cloud에서 중복성은 일반적으로 앱 또는 서비스를 여러 영역에 또는 심지어 여러 리전에 배포하여 얻습니다. 서비스가 여러 영역 또는 리전에 있으면 특정 영역 또는 리전에서 서비스 중단이 발생하더라도 이를 더 잘 견딜 수 있습니다. 이러한 중단을 방지하기 위해 Google Cloud가 모든 노력을 기울이더라도, 예측할 수 없는 이벤트가 발생할 수 있으므로, 이에 대비하는 것이 가장 좋습니다.
Compute Engine 관리형 인스턴스 그룹을 사용하면 리전 내 여러 영역에 가상 머신 인스턴스를 분산하고 인스턴스를 하나의 논리적 단위로 관리할 수 있습니다. 또한 Google Cloud는 데이터를 자동으로 한 리전의 두 영역에 복제할 수 있도록 리전별 영구 디스크를 제공합니다.
이와 비슷하게 GKE에 배포된 앱도 리전별 클러스터를 만들어서 가용성과 복원력을 향상시킬 수 있습니다. 리전 클러스터는 리전 내 여러 영역에 GKE 제어 영역 구성요소, 노드, 포드를 배포합니다. 제어 영역 구성요소가 배포되므로 전부가 아닌 영역 하나 이상에서 중단이 발생하더라도 클러스터의 제어 영역에 계속 액세스할 수 있습니다.
관리형 서비스 우선 고려
애플리케이션 스택의 모든 부분을 독립적으로 설치, 지원, 운영하는 대신, 관리형 서비스를 사용해서 애플리케이션 스택의 부분을 서비스로 사용할 수 있습니다. 예를 들어 가상 머신(VM)에 MySQL 데이터베이스를 설치하고 관리하는 대신 Cloud SQL에서 제공되는 MySQL 데이터베이스를 사용할 수 있습니다. 그러면 가용성 서비스수준계약(SLA)을 얻고 Google Cloud를 사용하여 데이터 복제, 백업, 기본 인프라를 관리할 수 있습니다. 관리형 서비스를 사용하면 인프라 관리에 드는 시간을 줄이고 앱 신뢰성을 향상시키는 데 더 많은 시간을 할애할 수 있습니다.
Google Cloud의 많은 관리형 컴퓨팅, 데이터베이스, 스토리지 서비스에서 중복성이 기본적으로 제공되므로, 가용성 목표를 달성하는 데 도움을 얻을 수 있습니다. 이러한 많은 서비스에서는 리전별 모델이 제공됩니다. 즉, 앱 실행 인프라가 특정 리전에 위치하며, 해당 리전 내 모든 영역에 중복적으로 제공될 수 있도록 Google에서 관리됩니다. 한 영역이 사용 불가능한 상태가 되면 앱 또는 데이터가 리전 내 다른 영역에서 자동으로 제공됩니다.
특정 데이터베이스 및 스토리지 서비스에서는 또한 멀티 리전별 가용성이 제공됩니다. 즉, 앱 실행 인프라가 여러 리전에 배포되어 있습니다. 멀티 리전별 서비스는 리전 하나가 손실되는 장애도 견딜 수 있지만 일반적으로 지연 시간 비용이 더 높습니다.
각 등급에서의 부하 분산
부하 분산을 사용하면 리소스 그룹 간에 트래픽을 분산할 수 있습니다. 트래픽을 분산하면 일부 리소스만 부하가 높고 다른 리소스는 유휴 상태로 유지되지 않도록 방지하는 데 도움이 됩니다. 또한 대부분의 부하 분산기에서는 트래픽이 비정상 또는 사용 불가능한 리소스로 라우팅되지 않도록 보장하는 상태 확인 기능이 제공됩니다.
Google Cloud에는 몇 가지 부하 분산 옵션이 제공됩니다. 앱이 Compute Engine 또는 GKE에서 실행되는 경우 트래픽의 유형, 소스, 기타 특징에 따라 가장 적합한 유형의 부하 분산기를 선택할 수 있습니다. 자세한 내용은 부하 분산 개요 및 GKE 네트워킹 개요를 참조하세요.
또는 App Engine 및 Cloud Run과 같은 일부 Google Cloud 관리형 서비스도 트래픽을 자동으로 부하 분산합니다.
웹 또는 모바일 클라이언트와 같은 외부 소스로부터 수신되는 요청을 부하 분산하는 것이 일반적입니다. 하지만 앱 내에서 여러 서비스 또는 계층 간 부하 분산기를 사용하여 복원력과 유연성을 높일 수도 있습니다. Google Cloud는 이를 위해 내부 레이어 4 및 레이어 7 부하 분산을 제공합니다.
다음 다이어그램은 두 리전 us-central1 및 asia-east1 사이에 전역 트래픽을 분산하는 외부 부하 분산기를 보여줍니다. 또한 웹 계층에서 각 리전 내의 내부 계층으로 트래픽을 분산하는 내부 부하 분산을 보여줍니다.
인프라 및 앱 모니터링
앱의 복원력과 확장성 향상 방법을 결정하려면 먼저 앱 동작을 이해해야 합니다. 앱 성능 및 상태에 대한 관련 측정항목과 시계열을 모두 확인하면 중단을 일으킬 수 있는 잠재적인 문제를 미리 확인하는 데 도움이 될 수 있습니다. 또한 중단이 발생했을 때 이를 진단하고 해결하는 데에도 도움이 될 수 있습니다. Google SRE 도서의 분산형 시스템 모니터링 장에서는 몇 가지 모니터링 방식에 대한 유용한 개요를 제공합니다.
앱 상태에 대한 유용한 정보를 제공하는 것 외에도 측정항목을 사용해서 서비스의 자동 확장 동작을 제어할 수 있습니다.
Cloud Monitoring은 Google Cloud의 통합 모니터링 도구입니다. Cloud Monitoring은 이벤트, 측정항목, 메타데이터를 수집하고 대시보드 및 알림을 통해 유용한 정보를 제공합니다. 대부분의 Google Cloud 서비스는 측정항목을 자동으로 Cloud Monitoring에 전송하고 Google Cloud도 여러 서드 파티 소스를 지원합니다. 또한 앱 관찰을 위한 '단일 제어창'으로서 Cloud Monitoring을 인기 있는 오픈소스 모니터링 도구의 백엔드로 사용할 수 있습니다.
모든 수준에서 모니터링
아키텍처 내의 여러 수준 또는 계층에서 측정항목을 수집하면 앱 상태 및 동작을 총체적으로 이해할 수 있습니다.
인프라 모니터링
인프라 수준의 모니터링은 앱의 기본 상태 및 성능 정보를 제공합니다. 이러한 모니터링 접근 방식은 CPU 부하, 메모리 사용량, 디스크에 기록된 바이트 수와 같은 정보를 캡처합니다. 이러한 측정항목은 머신이 과부하되었거나 예상대로 작동하지 않음을 나타낼 수 있습니다.
자동으로 수집되는 측정항목 외에도 Cloud Monitoring은 해당 머신에서 실행되는 서드 파티 앱을 포함하여 Compute Engine VM에서 보다 자세한 정보를 수집하기 위해 설치할 수 있는 에이전트를 제공합니다.
앱 모니터링
측정항목은 앱 수준으로 캡처하는 것이 좋습니다. 예를 들어 특정 쿼리를 실행하는 데 걸리는 시간이나 연관된 일련의 서비스 호출을 수행하는 데 걸리는 시간을 측정해야 할 수 있습니다. 이러한 앱 수준 측정항목은 사용자가 직접 정의합니다. 이러한 측정항목은 기본 제공되는 Cloud Monitoring 측정항목으로 캡처할 수 없는 정보를 캡처합니다. 앱 수준 측정항목은 주요 워크플로를 보다 긴밀하게 반영하는 수집된 조건을 캡처할 수 있으며, 하위 수준의 인프라 측정항목으로 확인할 수 없는 문제를 드러낼 수 있습니다.
또한 OpenTelemetry를 사용하여 앱 수준 측정항목을 캡처하는 것이 좋습니다. OpenTelemetry는 원격 분석 데이터를 위한 단일 개방형 표준을 제공합니다. OpenTelemetry를 사용하여 클라우드 중심 애플리케이션과 인프라에서 데이터를 수집하고 내보냅니다. 그런 다음 내보낸 원격 분석 데이터를 모니터링하고 분석할 수 있습니다.
서비스 모니터링
분산형 앱 및 마이크로서비스 기반 앱의 경우, 앱에 있는 서로 다른 서비스 및 구성요소 간의 상호작용을 모니터링하는 것이 중요합니다. 이러한 측정항목은 증가한 오류 수 또는 서비스 간 지연 시간과 같은 문제를 진단하는 데 도움이 될 수 있습니다.
Istio는 유용한 정보와 마이크로서비스 네트워크에 대한 운영적 제어를 제공하는 오픈소스 도구입니다. Istio는 모든 서비스 커뮤니케이션에 대한 세부 원격 분석을 생성하며, 측정항목을 Cloud Monitoring으로 전송하도록 구성될 수 있습니다.
엔드 투 엔드 모니터링
블랙박스 모니터링이라고도 부르는 엔드 투 엔드 모니터링은 사용자에게 표시되는 방식으로 외부적으로 표시되는 동작을 테스트합니다. 이 유형의 모니터링은 정의된 기준 내에서 사용자가 중요한 작업을 완료할 수 있는지 여부를 확인합니다. 이러한 대략적인 모니터링은 세부적인 모니터링으로 확인할 수 없는 오류 또는 지연 시간을 확인할 수 있으며, 사용자에게 인식되는 대로 가용성을 드러냅니다.
앱 상태 노출
가용성이 높은 시스템은 시스템 중 어떤 부분이 정상 상태이고 올바르게 작동 중인지 확인할 수 있는 방법이 있어야 합니다. 특정 리소스가 비정상 상태로 표시되면 시스템이 다른 곳으로 요청을 전송할 수 있습니다. 일반적으로 상태 확인에는 엔드포인트에서 데이터를 가져와서 서비스 상태를 확인하는 과정이 포함됩니다.
상태 확인은 부하 분산기의 중요한 역할입니다. 가상 머신 인스턴스 그룹과 연결된 부하 분산기를 만들 때는 상태 확인도 정의합니다. 상태 확인은 특정 인스턴스가 트래픽을 계속 수신해야 할지 여부를 평가하기 위해 부하 분산기가 가상 머신과 통신하는 방법을 정의합니다. 또한 부하 분산기 상태 점검은 비정상 머신이 다시 생성되도록 인스턴스 그룹을 자동 복구하는 데 사용될 수 있습니다. GKE에서 실행 중이고 인그레스 리소스를 통해 외부 트래픽을 부하 분산하는 경우, GKE가 부하 분산기에 적합한 상태 확인을 자동으로 만듭니다.
Kubernetes에는 활성 여부 및 준비 상태 프로브를 위한 기본 제공 지원이 포함됩니다. 이러한 프로브는 Kubernetes 조정자가 클러스터 내에서 포드 및 요청을 관리하는 방법을 결정하는 데 도움이 됩니다. 앱이 Kubernetes에 배포된 경우 적합한 엔드포인트를 통해 앱 상태를 이러한 프로브에 노출하는 것이 좋습니다.
주요 측정항목 설정
모니터링 및 상태 확인은 앱 동작 및 상태에 대한 측정항목을 제공합니다. 다음 단계에서는 이러한 측정항목을 분석하여 가장 기술적이거나 영향이 큰 항목이 무엇인지 판단합니다. 주요 측정항목은 앱이 배포된 플랫폼 및 앱이 수행하는 작업에 따라 크게 달라집니다.
앱 확장 여부를 나타내거나 특정 서비스가 비정상임을 나타내는 측정항목을 하나만 찾지는 않을 것입니다. 측정항목은 종종 특정 조건 집합을 함께 나타내는 여러 요소들의 조합인 경우가 않습니다. Cloud Monitoring을 사용하면 커스텀 측정항목을 만들어 이러한 조건을 캡처할 수 있습니다. Google SRE 도서는 사용자 대상 시스템을 모니터링할 때 지연 시간, 트래픽, 오류, 포화도라는 4가지 골든 신호를 사용할 것을 주장합니다.
또한 이상치에 대한 허용값을 고려해야 합니다. 상태 또는 성능 측정을 위해서는 평균 또는 중앙 값을 사용하는 것은 불균형 범위 넓을 경우 이를 가릴 수 있기 때문에 최선의 대안이 아닐 수 있습니다. 따라서 측정항목 분산을 고려하는 것이 중요합니다. 99번째 백분위수가 평균보다 유용한 측정 기준일 수 있습니다.
서비스 수준 목표(SLO) 정의
모니터링 시스템에서 수집한 측정항목을 사용하여 서비스 수준 목표(SLO)를 정의할 수 있습니다. SLO는 서비스의 성능 또는 안정성을 위한 목표 수준을 지정합니다. SLO는 SRE 방식의 중요한 역할이며 SRE 도서의 서비스 수준 목표 장과 SRE 통합문서의 SLO 구현 장에 자세히 설명되어 있습니다.
서비스 모니터링을 사용하여 Cloud Monitoring의 측정항목을 기반으로 SLO를 정의할 수 있습니다. SLO에 대한 알림 정책을 만들어 SLO를 위반할 위험이 있는지에 대한 여부를 확인할 수 있습니다.
측정항목 저장
모니터링 시스템에서 가져온 측정항목은 단기적으로 실시간 상태 확인을 수행하거나 최근에 발생한 문제를 조사하는 데 유용합니다. Cloud Monitoring은 이러한 사용 사례에 맞게 몇 주 동안 측정항목을 보관합니다.
하지만 장기 분석을 위해 모니터링 측정항목을 보관하는 것도 가치가 있습니다. 이전 레코드에 액세스할 수 있으면 앱 아키텍처 세분화에 대한 데이터 기반 접근방식을 채택하는 데 도움이 될 수 있습니다. 중단 중에 그리고 중단 이후에 수집된 데이터를 사용하여 앱 내에 있는 병목 현상 및 상호 의존성 문제를 식별할 수 있습니다. 또한 이 데이터를 사용하여 의미 있는 테스트를 만들고 검사할 수 있습니다.
이전 데이터는 중요 기간 중 앱이 비즈니스 목표를 지원하는지 검사하는 데에도 도움이 될 수 있습니다. 예를 들어 이러한 데이터를 통해 지난 몇 분기 또는 몇 년 동안 트래픽이 높았던 프로모션 이벤트 기간 중의 앱 확장 규모를 분석할 수 있습니다.
측정항목을 내보내고 저장하는 방법에 대한 자세한 내용은 Cloud Monitoring 측정항목 내보내기 솔루션을 참조하세요.
확장 프로필 확인
앱이 사용자 환경 및 성능 목표를 달성하는지 확인하면서도 리소스가 과도하게 프로비저닝되는 것은 방지해야 합니다.
다음 다이어그램은 간단하게 표시된 앱의 확장 프로필을 보여줍니다. 앱은 기본 수준의 리소스를 유지 관리하고 자동 확장을 사용해서 수요 변화에 대응합니다.
비용 및 사용자 환경 균형 조정
앱 확장 여부를 결정하는 것은 본질적으로 사용자 환경과 비용의 균형을 맞추는 것입니다. 허용되는 최소 성능 수준을 결정하고 상한선을 설정할 부분도 결정합니다. 이러한 기준은 앱마다 달라지며, 단일 앱 내에서도 각 구성요소 또는 서비스에 따라 달라집니다.
예를 들어 소비자 대상 웹이나 모바일 앱에서는 지연 시간 목표가 엄격할 수 있습니다. 연구 결과에 따르면 짧은 지연만으로도 사용자가 앱을 부정적으로 인식하여 전환율이 낮아지고 등록 수가 줄어들 수 있습니다. 따라서 사용자 요청에 빠르게 대응할 수 있도록 앱의 서비스 제공 성능이 충분한지 확인하는 것이 중요합니다. 이 경우에는 더 많은 웹 서버를 운영할 수 있도록 비용을 늘리는 것이 당연할 수 있습니다.
약간의 지연이 용인될 수 있는 업무에 중요하지 않은 내부 앱의 경우에는 비용과 성능 사이의 비율이 달라질 수 있습니다. 이 경우에는 확장 프로필이 덜 공격적일 수 있습니다. 여기에서는 사용자 환경을 최적화하는 것보다 비용을 낮게 유지하는 것이 더 중요할 수 있습니다.
기준 리소스 설정
확장 프로필의 또 다른 중요 구성요소는 최소 리소스 집합의 적정 수준을 결정하는 것입니다.
Compute Engine 가상 머신 또는 GKE 클러스터는 새 노드를 만들고 초기화해야 하기 때문에 일반적으로 확장하는 데 시간이 걸립니다. 따라서 트래픽이 없더라도 최소 리소스 집합을 유지 관리해야 할 수 있습니다. 다시 말하지만, 기준 리소스 범위는 앱 유형과 트래픽 프로필의 영향을 받습니다.
반면에 App Engine, Cloud Run 함수, Cloud Run과 같은 서버리스 기술은 0으로 확장되고 콜드 스타트의 경우에도 빠르게 시작 및 확장되도록 설계되었습니다. 앱 유형 및 트래픽 프로필에 따라 이러한 기술은 앱 부분에 효율성을 제공할 수 있습니다.
자동 확장 구성
자동 확장은 앱에서 사용하는 컴퓨팅 리소스를 자동으로 확장하는 데 도움을 줍니다. 일반적으로 자동 확장은 특정 측정항목이 초과되거나 조건이 충족되면 수행됩니다. 예를 들어 웹 계층에 대한 요청 지연 시간이 특정 값을 초과하기 시작하면 제공 용량을 늘리기 위해 머신 추가가 자동으로 수행되도록 해야 할 수 있습니다.
자동 확장 기능은 많은 Google Cloud 컴퓨팅 제품에 포함되어 있습니다. Cloud Run, Cloud Run 함수, App Engine과 같은 서버리스 관리형 서비스는 빠르게 확장되도록 설계되었습니다. 이러한 서비스는 일반적으로 자동 확장 동작을 제한하거나 영향을 주는 구성 옵션을 제공하지만, 일반적으로 자동 확장 처리 동작은 대부분 작업자에게 드러나지 않습니다.
Compute Engine 및 GKE는 확장 동작을 제어하기 위한 더 많은 옵션을 제공합니다. Compute Engine에서는 Cloud Monitoring 커스텀 측정항목 및 부하 분산기 제공 용량을 포함하여 여러 입력을 기준으로 확장할 수 있습니다. 확장 동작에 대한 최소 및 최대 한도를 설정하고 다양한 시나리오가 처리되도록 여러 신호가 포함된 자동 확장 정책을 정의할 수 있습니다. GKE에서와 같이 워크로드 또는 포드 측정항목을 기준으로 또는 클러스터 외부의 측정항목을 기준으로 노드를 추가하거나 삭제하도록 클러스터 자동 확장 처리를 구성할 수 있습니다.
중요 앱 측정항목, 비용 프로필, 정의된 최소 필수 리소스 수준을 기준으로 자동 확장 동작을 구성하는 것이 좋습니다.
시작 시간 최소화
확장이 효과가 있으려면 늘어난 부하를 처리하기에 충분히 빠른 시간 내에 수행되어야 합니다. 특히 컴퓨팅 또는 서비스 제공 용량을 추가할 때 더 그렇습니다.
미리 만들어진 이미지 사용
앱이 Compute Engine VM에서 실행되는 경우 소프트웨어를 설치하고 앱을 실행할 인스턴스를 구성해야 할 수도 있습니다. 시작 스크립트를 사용하여 새 인스턴스를 구성할 수 있지만 더 효과적인 방법은 커스텀 이미지를 만드는 것입니다. 커스텀 이미지는 앱 관련 소프트웨어 및 구성을 사용해서 설정하는 부팅 디스크입니다.
이미지 관리 방법에 대한 자세한 내용은 이미지 관리 권장사항 문서를 참조하세요.
이미지를 만들었으면 인스턴스 템플릿을 정의할 수 있습니다. 인스턴스 템플릿은 부팅 디스크 이미지, 머신 유형, 기타 인스턴스 속성을 결합합니다. 그런 후 인스턴스 템플릿을 사용하여 개별 VM 인스턴스 또는 관리형 인스턴스 그룹을 만들 수 있습니다. 인스턴스 템플릿을 사용하면 VM 인스턴스 구성을 쉽게 저장할 수 있으므로, 나중에 이를 사용해서 새 VM 인스턴스를 만들 수 있습니다.
커스텀 이미지와 인스턴스 템플릿을 사용해서 배포 속도를 늘릴 수 있지만, 이미지 업데이트 빈도가 늘어나서 유지보수 비용도 증가할 수 있습니다. 자세한 내용은 이미지 구성과 배포 속도 균형 조정 문서를 참조하세요.
앱 컨테이너화
맞춤설정된 VM 인스턴스 빌드 대안으로 앱을 컨테이너화할 수 있습니다. 컨테이너는 코드, 런타임, 시스템 도구, 시스템 라이브러리, 설정 등 앱 실행에 필요한 모든 것이 포함된 독립적으로 실행 가능한 경량형 소프트웨어 패키지입니다. 이러한 특성 덕분에 컨테이너화된 앱은 포팅과 배포가 쉽고, 대규모 유지 관리도 가상 머신보다 용이합니다. 컨테이너는 또한 일반적으로 빠르게 시작할 수 있기 때문에 확장성 및 복원력이 필요한 앱에 적합합니다.
Google Cloud는 앱 컨테이너 실행을 위해 여러 서비스를 제공합니다. Cloud Run은 스테이트리스(Stateless) 컨테이너를 호스팅할 수 있는 서버리스 관리형 컴퓨팅 플랫폼을 제공합니다. App Engine 가변형 환경은 관리형 Platform as a Service(PaaS)에서 컨테이너를 호스팅합니다. GKE는 컨테이너화된 앱을 호스팅하고 조정할 수 있는 관리형 Kubernetes 환경을 제공합니다. 또한 컨테이너 환경을 완전히 제어해야 하는 경우에는 Compute Engine에서 앱 컨테이너를 실행할 수 있습니다.
빠른 시작을 위한 앱 최적화
인프라 및 앱을 가능한 한 효율적으로 배포하는 것 외에 앱을 신속하게 온라인으로 전환할 수 있는지도 중요합니다.
앱에 적합한 최적화는 앱 특성 및 실행 플랫폼에 따라 달라집니다. 다음을 수행하는 것이 중요합니다.
- 시작 시 호출되는 앱의 중요 섹션을 프로파일링하여 병목 현상을 찾아서 없앱니다.
- 특히 고비용 리소스의 경우 지연 초기화와 같은 기법을 구현하여 초기 시작 시간을 줄입니다.
- 시작 시 로드되어야 하는 앱 종속 항목을 최소화합니다.
모듈식 아키텍처 우선 고려
구성요소를 독립적으로 배포, 관리, 확장할 수 있게 해주는 아키텍처를 선택하여 앱의 유연성을 늘릴 수 있습니다. 이 패턴은 또한 단일 장애점을 없애줌으로써 복원력을 향상시킬 수 있습니다.
앱을 여러 독립 서비스로 분할
앱을 느슨하게 결합된 형태의 독립형 서비스로 설계하면 앱의 유연성을 늘릴 수 있습니다. 느슨하게 결합된 설계를 채택하면 서비스를 독립적으로 출시하고 배포할 수 있습니다. 다른 많은 이점 외에도 이 접근 방식을 따르면 해당 서비스에 여러 기술 스택을 사용하고 여러 팀이 각 서비스를 관리할 수 있는 이점이 있습니다. 이 느슨하게 결합된 접근 방식은 마이크로서비스 및 SOA와 같은 아키텍처 패턴의 주요 테마입니다.
서비스 주위의 경계 구성 방법을 고려할 때 주의해야 할 핵심 대상은 가용성과 확장성 요구사항입니다. 예를 들어 지정된 구성 요소의 가용성 요구사항 또는 확장 프로필이 다른 구성요소와 차이가 있으면 독립형 서비스가 대안이 될 수 있습니다.
스테이트리스(Stateless) 목표
스테이트리스(Stateless) 앱 또는 서비스에는 로컬 영구 데이터 또는 상태가 보관되지 않습니다. 스테이트리스(Stateless) 모델은 이전 요청에 관계없이 서비스에서 각 요청 또는 상호작용을 처리할 수 있게 해줍니다. 이 모델은 진행 중인 프로세스 또는 요청을 처리하기 위해 필요한 데이터가 손실되는 일 없이 서비스를 확장 또는 축소하거나 재시작할 수 있으므로, 확장성과 복구 성능에 도움을 줍니다. 인스턴스, 노드, 서비스를 호스팅하는 포드가 예기치 않게 생성되고 삭제될 수 있기 때문에 스테이트리스(Stateless)는 자동 확장 처리를 사용할 때 특히 중요합니다.
모든 서비스를 스테이트리스(Stateless)로 구성하는 것은 가능하지 않을 수 있습니다. 이 경우에는 스테이트(State)가 필요한 서비스를 명시적으로 구분해야 합니다. 스테이트리스(Stateless) 서비스와 스테이트풀(Stateful) 서비스를 명확하게 구분함으로써 스테이트리스(Stateless) 서비스의 확장성을 간편하게 얻으면서도 스테이트풀(Stateful) 서비스에 대해 보다 효과적인 접근 방식을 채택할 수 있습니다.
서비스 간 통신 관리
분산형 마이크로서비스 아키텍처의 한 가지 도전과제는 서비스 간 통신을 관리하는 것입니다. 서비스 네트워크가 증가하면 서비스 상호 의존성도 증가할 가능성이 있습니다. 한 서비스의 장애가 다른 서비스의 장애로 이어질 수 있는 연쇄적 장애가 발생해서는 안됩니다.
회로 차단기 패턴, 지수 백오프, 단계적 성능 저하와 같은 기법을 채택하여 과부하된 서비스나 장애가 발생한 서비스로의 트래픽을 줄일 수 있습니다. 이러한 패턴은 과부하된 서비스가 복구될 가능성을 제공하거나 오류 상태를 단계적으로 처리함으로써 앱의 복원력을 높여줍니다. 자세한 내용은 Google SRE 도서의 연쇄적 장애 해결 장을 참조하세요.
서비스 메시를 사용하면 분산된 서비스 간의 트래픽을 관리할 수 있습니다. 서비스 메시는 서비스를 서로 연결하고 네트워킹에서 비즈니스 로직을 분리해주는 소프트웨어입니다. 서비스 메시는 일반적으로 요청 재시도, 장애 조치, 회로 차단기와 같은 복원성 기능을 제공합니다.
적절한 데이터베이스 및 스토리지 기술 사용
특정 데이터베이스와 스토리지 유형은 확장성 및 복원력을 갖기 어렵습니다. 선택한 데이터베이스로 인해 앱의 가용성 및 확장성이 제한되지 않는지 확인하세요.
데이터베이스 요구 평가
독립형 서비스 집합으로 앱을 설계하는 패턴은 데이터베이스와 스토리지로도 확장됩니다. 앱의 각 부분에 서로 다른 유형의 스토리지를 선택하여 이기종 스토리지로 구성하는 것이 적합할 수 있습니다.
기존 앱은 관계형 데이터베이스로만 작동하는 경우가 종종 있습니다. 관계형 데이터베이스는 트랜잭션, strong consistency, 참조 무결성, 정교한 테이블 간 쿼리와 같은 유용한 기능을 제공합니다. 이러한 기능 덕분에 많은 일반 앱 기능에는 관계형 데이터베이스를 선택하는 것이 효과적입니다. 하지만 관계형 데이터베이스도 몇 가지 제약조건이 있습니다. 관계형 데이터베이스는 일반적으로 확장이 어렵고, 고가용성 구성에서 관리가 까다롭습니다. 모든 데이터베이스 요구 사항에 대해서는 관계형 데이터베이스가 최선의 옵션이 아닐 수 있습니다.
NoSQL 데이터베이스라고도 부르는 비관계형 데이터베이스에는 다른 접근 방식이 사용됩니다. 제품마다 세부정보는 다를 수 있지만, NoSQL 데이터베이스는 일반적으로 관계형 데이터베이스의 몇 가지 기능을 희생하고 대신 향상된 가용성 및 쉬운 확장성 이점을 챙깁니다. CAP 이론의 측면에서 NoSQL 데이터베이스는 종종 일관성보다는 가용성을 선택합니다.
NoSQL 데이터베이스가 적합한지 여부는 종종 필요한 일관성 수준이 어느 정도인지부터 시작됩니다. 특정 서비스의 데이터 모델에 RDBMS의 모든 기능이 필요하지 않고, eventual consistency를 갖도록 모델을 설계할 수 있다면, NoSQL 데이터베이스를 선택하여 가용성 및 확장성을 늘릴 수 있습니다.
데이터 관리 렐름에서 관계형 및 비관계형 데이터베이스는 경쟁 기술보다는 상호 보완적인 기술로 간주되는 경우가 많습니다. 조직에서 두 가지 유형의 데이터베이스를 전략적으로 사용하면 각각의 강점을 활용하여 데이터 저장, 검색, 분석에서 최적의 결과를 얻을 수 있습니다.
다양한 관계형 및 NoSQL 데이터베이스 외에도, Google Cloud은 strong consistency와 높은 가용성을 가지며 SQL을 지원하는 전역 분산형 데이터베이스인 Spanner를 제공합니다. Google Cloud에서 적합한 데이터베이스를 선택하는 방법에 대한 자세한 내용은 Google Cloud 데이터베이스를 참조하세요.
캐싱 구현
캐시의 기본 목적은 기본적으로 속도가 느린 스토리지 레이어에 액세스할 필요를 줄여서 데이터 검색 성능을 늘리는 것입니다.
캐싱은 디스크 기반 스토리지에 대한 의존성을 줄여서 늘어난 확장성을 지원합니다. 메모리로부터 요청을 처리할 수 있기 때문에 스토리지 레이어에 대한 요청 지연 시간이 줄어들고, 일반적으로 서비스가 더 많은 요청을 처리할 수 있습니다. 또한 캐싱은 앱의 다운스트림인 서비스, 특히 데이터베이스에 대한 부하를 줄여줌으로써, 다운스트림 서비스와 상호작용하는 다른 구성요소도 더 확장할 수 있게 해줍니다.
캐싱은 또한 단계적 성능 저하와 같은 기법을 지원하여 복원력을 향상시킬 수 있습니다. 기본 스토리지 레이어가 과부하되거나 사용할 수 없게 되면 캐시가 요청을 계속 처리할 수 있습니다. 그리고 캐시에서 반환된 데이터가 불완전하거나 최신이 아니어도, 특정 시나리오에서는 이것이 허용될 수 있습니다.
Redis용 Memorystore는 Redis 인메모리 데이터 스토어를 기반으로 하는 완전 관리형 서비스를 제공합니다. Memorystore for Redis는 액세스 빈도가 높은 데이터에 대해 지연 시간이 낮은 액세스 및 높은 처리 능력을 제공합니다. 영역 간 복제 및 자동 장애 조치를 제공하는 고가용성 구성으로 배포할 수 있습니다.
개발 프로세스 및 문화 현대화
DevOps는 개발, 운영, 그 외 관련 팀 간의 사일로를 없앰으로써 앱 및 기능을 위한 민첩성 및 줄어든 TTM(time to market)을 촉진하는 도구와 프로세스, 문화가 포함된 넓은 범위의 집합체로 고려될 수 있습니다. DevOps 기법은 소프트웨어의 품질과 신뢰성을 향상시키는 것을 목표로 합니다.
DevOps에 대한 자세한 설명은 이 문서의 범위를 벗어납니다. 하지만 다음 섹션에서는 앱의 신뢰성과 복원력을 향상시키는 것과 관련된 몇 가지 핵심 사항이 다뤄집니다. 자세한 내용은 Google Cloud DevOps 페이지를 참조하세요.
테스트 가능성을 위한 설계
자동 테스트는 현대식 소프트웨어 제공 방식에서 중요한 구성요소입니다. 포괄적으로 단위, 통합, 시스템 테스트 집합을 실행하는 기능은 앱이 예상한 대로 작동하는지 확인하고 배포 주기의 다음 단계로 진행할 수 있는지 확인하기 위해 필수적인 기능입니다. 테스트 가능성은 앱의 핵심 설계 기준입니다.
빠르게 실행할 수 있고 일반적으로 유지 관리도 간편하기 때문에 대량 테스트를 위해서는 단위 테스트를 사용하는 것이 좋습니다. 또한 상위 수준의 통합 및 시스템 테스트를 자동화하는 것이 좋습니다. 코드형 인프라 기법을 채택하면 필요에 따라 전용 테스트 환경 및 리소스를 만들고 테스트가 완료되면 이를 폐기할 수 있기 때문에 이러한 테스트가 크게 간소화됩니다.
테스트에 포함되는 코드베이스 비율이 증가함에 따라 불확실성이 줄어들고 각 코드 변경에 따른 신뢰성 저하 가능성이 줄어듭니다. 테스트 범위를 적절하게 설정하면 신뢰성이 허용 가능 수준에 들어가기 전에 더 많은 항목을 변경할 수 있습니다.
자동화된 테스트는 지속적인 통합의 핵심 구성요소입니다. 각 코드 커밋에서 자동화된 강력한 테스트 집합을 실행하면 변경사항에 대한 빠른 피드백을 얻고 소프트웨어의 품질 및 신뢰성을 향상시킬 수 있습니다. Cloud Build와 같은 Google Cloud 네이티브 도구와 Jenkins와 같은 서드 파티 도구는 지속적 통합을 구현하는 데 도움이 될 수 있습니다.
배포 자동화
지속적 통합과 포괄적인 테스트 자동화는 소프트웨어 안정성에 대한 확신을 제공합니다. 그리고 이것들이 구현된 다음에는 앱 배포를 자동화해야 합니다. 배포 자동화 수준은 조직의 성숙도에 따라 달라집니다.
새로운 소프트웨어 배포와 관련된 위험을 최소화하기 위해서는 적절한 배포 전략을 선택하는 것이 필수적입니다. 올바른 전략을 선택하면 새 버전의 노출을 더 많은 대상으로 단계적으로 늘리면서 중간에 동작을 확인할 수 있습니다. 또한 문제가 발생한 경우 롤백을 위해 명확한 프로비저닝을 설정할 수 있습니다.
장애 처리를 위한 SRE 방식 채택
대규모로 작동하는 분산형 앱의 경우, 하나 이상의 구성요소에서 발생하는 어느 정도의 장애는 일반적입니다. 이 문서에서 다뤄진 패턴을 채택하면 결함이 있는 소프트웨어 출시 버전, 예상치 못한 가상 머신 종료, 심지어 전체 영역에 영향을 주는 인프라 중단으로 인해 발생하는 중단 문제를 앱이 더 효율적으로 처리할 수 있습니다.
하지만 앱 설계를 아무리 신중하게 해도 작업자 개입이 필요한 예기치 못한 이벤트가 발생할 수 있습니다. 이러한 이벤트를 관리하기 위한 구조화된 프로세스를 준비하면 그로 인한 영향을 크게 줄이고 문제를 보다 빠르게 해결할 수 있습니다. 또한 이벤트에 대한 원인과 대응을 조사하면 이후 비슷한 이벤트가 발생하더라도 앱을 더 효과적으로 보호할 수 있습니다.
이슈를 관리하고 비난 없는 사후 분석을 수행하기 위한 강력한 프로세스가 SRE의 주요 원칙입니다. 조직에서 Google SRE의 모든 방식을 구현하는 것이 가능하지 않을 수 있지만 최소 가이드라인만 채택해도 앱의 복원력을 향상시킬 수 있습니다. SRE 도서의 부록에는 프로세스를 구성하는 데 도움이 되는 템플릿이 포함되어 있습니다.
아키텍처 검사 및 검토
앱이 발전함에 따라 사용자 행동, 트래픽 프로필, 심지어 비즈니스 우선순위도 변경될 수 있습니다. 마찬가지로 앱에 사용되는 다른 서비스 또는 인프라도 발전할 수 있습니다. 따라서 앱의 복원력과 확장성을 주기적으로 테스트하고 검사하는 것이 중요합니다.
복원력 테스트
앱의 장애 대응 방식이 예상한 대로 작동하는지 테스트하는 것이 매우 중요합니다. 무엇보다도 장애를 방지하는 최선의 방법은 장애를 실제로 일으켜보고 그로부터 교훈을 얻는 것입니다.
장애 시뮬레이션 및 유도는 복잡합니다. 앱 또는 서비스의 동작을 확인하는 것 외에도, 알림이 예상한 대로 생성되는지, 적합한 측정항목이 생성되는지 확인해야 합니다. 이를 위해서는 간단한 장애를 유도한 후 이를 처리하는 구조적인 접근 방법을 사용하는 것이 좋습니다.
예를 들어 다음과 같이 각 단계에서 검사, 동작 기술을 진행할 수 있습니다.
- 간헐적인 장애를 유도합니다.
- 서비스 종속 항목에 대한 액세스를 차단합니다.
- 모든 네트워크 통신을 차단합니다.
- 호스트를 종료합니다.
자세한 내용은 Google Cloud Next 2019에서 제공되는 파괴되지 않는 시스템 구축을 위한 시스템 파괴 동영상을 참조하세요.
앱 서비스를 관리하기 위해 Istio와 같은 서비스 메시를 사용하는 경우 포드나 머신을 종료하는 대신 애플리케이션 계층에서 오류를 삽입하거나 TCP 레이어에서 손상 패킷을 삽입할 수 있습니다. 네트워크 지연 시간 또는 과부하된 업스트림 시스템을 시뮬레이션하기 위해서는 지연 시간을 유도할 수 있습니다. 또한 업스트림 시스템의 장애를 모방하기 위해 중단을 유도할 수도 있습니다.
확장 동작 테스트
앱이 예상한 대로 확장되는지 확인하기 위해서는 자동화된 비기능 테스트를 사용하는 것이 좋습니다. 이러한 확인은 성능 또는 부하 테스트와 결합되는 경우가 많습니다. hey와 같은 간단한 도구를 사용하여 웹 앱에 부하를 전송할 수 있습니다. REST 엔드포인트에 대해 부하 테스트를 수행하는 방법을 보여주는 자세한 예시는 Google Kubernetes Engine을 사용한 분산 부하 테스트를 참조하세요.
한 가지 일반적인 접근 방식은 주요 측정항목이 변화하는 부하에 대해 예상된 수준 내에 있는지 확인하는 것입니다. 예를 들어 웹 계층의 확장성을 테스트하는 경우, 사용자 요청의 갑작스러운 증가 볼륨에 대해 평균 요청 지연 시간을 측정할 수 있습니다. 마찬가지로, 백엔드 처리 기능의 경우에는 작업 볼륨이 갑작스럽게 증가할 때의 평균 작업 처리 시간을 측정할 수 있습니다.
또한 테스트 부하를 처리하기 위해 생성된 리소스 수가 예상된 범위 내에 있는지도 테스트해야 합니다. 예를 들어 백엔드 작업을 처리하기 위해 생성된 VM 수가 특정 값을 초과하지 않는지 테스트해야 할 수 있습니다.
특이한 사례를 테스트하는 것도 중요합니다. 최대 확장 한도에 도달하면 앱 또는 서비스가 어떻게 동작할까요? 서비스가 축소되는 동안 부하가 다시 갑자기 증가할 경우에는 어떻게 동작할까요?
지속적인 설계
기술 세계는 빠르게 변화합니다. 클라우드에 있어서는 특히 더 그렇습니다. 새로운 제품과 기능이 자주 출시되고, 새로운 패턴이 나타나고, 사용자 및 내부 이해관계자의 요구도 계속해서 증가합니다.
클라우드 네이티브 아키텍처를 위한 원칙 블로그 게시물에서 정의한 것처럼 앱 아키텍처를 미세 조정하고 단순화하고 향상시킬 수 있는 방법을 항상 찾아보세요. 소프트웨어 시스템은 살아 있는 것처럼 변화하는 우선순위에 따라 함께 변화되어야 합니다.
다음 단계
- 클라우드 네이티브 아키텍처를 위한 원칙 블로그 게시물 읽어보기
- SRE 도서를 읽고 Google 프로덕션 환경 관리 방법 자세히 알아보기
- Google Cloud의 DevOps로 소프트웨어 품질과 신뢰성을 향상시키는 방법 자세히 알아보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터를 살펴보세요.