클라우드 워크로드에 대해 안정적인 인프라를 빌드하는 첫 번째 단계는 워크로드의 안정성 요구사항이 무엇인지 파악하는 것입니다. Google Cloud 인프라 안정성 가이드 중 이 문서에서는 Google Cloud에 배포하는 워크로드의 안정성 요구사항을 정의하는 데 도움이 되는 가이드라인을 제공합니다.
워크로드별 요구사항 확인
애플리케이션의 안정성 요구사항은 애플리케이션이 제공하는 서비스의 특성 또는 애플리케이션이 실행하는 프로세스에 따라 다릅니다. 예를 들어 은행에 ATM 서비스를 제공하는 애플리케이션에는 가용성이 99.9999%여야 할 수 있습니다. 온라인 거래 플랫폼을 지원하는 웹사이트는 99.999%의 가용성과 빠른 응답 시간이 필요할 수 있습니다. 매일 종료 시점에 은행 거래를 회계 원장에 쓰는 일괄 프로세스의 데이터 최신성 타겟은 8시간일 수 있습니다.
애플리케이션 내에서 개별 구성요소 또는 작업에는 다양한 안정성 요구사항이 있을 수 있습니다. 예를 들어 주문 처리 애플리케이션은 읽기 요청에 비해 주문 데이터베이스에 데이터를 쓰는 작업에 더 높은 안정성이 필요할 수 있습니다.
워크로드의 안정성 요구사항을 세부적으로 평가하면 비용과 노력을 비즈니스에 중요한 워크로드에 집중할 수 있습니다.
중요한 기간 파악
어떤 애플리케이션이 다른 때보다 비즈니스에서 더 중요한 기간이 있을 수 있습니다. 이 기간은 애플리케이션에 최대 부하가 발생하는 시간인 경우가 많습니다. 이러한 기간을 파악하여 적절한 용량을 계획하고 최대 부하 조건에 대해 애플리케이션을 테스트하세요. 최대 부하 기간 동안 애플리케이션 중단 위험을 방지하기 위해서는 프로덕션 코드 고정과 같은 적절한 운영 방식을 사용할 수 있습니다.
다음은 계절적 부하 급증이 발생하는 애플리케이션의 예입니다.
- 재무 회계 애플리케이션의 인벤토리 모듈은 일반적으로 월별, 분기별 또는 연간 인벤토리 감사가 예약된 날에 더 많이 사용됩니다.
- 전자상거래 웹사이트의 경우 쇼핑 시즌이나 프로모션 이벤트 기간에 로드가 크게 급증합니다.
- 대학의 학생 입학 모듈을 지원하는 데이터베이스는 매년 특정 달에 많은 양의 쓰기 작업이 발생하기도 합니다.
- 온라인 세금 신고 서비스는 세금 신고 시즌에 부하가 높습니다.
- 온라인 거래 플랫폼은 99.999%의 가용성과 빠른 응답 시간을 필요로 할 수 있지만 거래 시간(예: 월~금 오전 8시~오후 5시)에만 필요합니다.
다른 비기능적 요구사항 고려
엔터프라이즈 애플리케이션은 안정성 요구사항 외에도 보안, 성능, 비용, 운영 효율성에 대한 기타 비기능적 요구사항이 있을 수 있습니다. 애플리케이션의 안정성 요구사항을 평가할 때는 이러한 다른 요구사항과의 종속 항목과 절충점을 고려하세요.
다음은 안정성이 아니지만 안정성 요구사항과의 절충이 있을 수 있는 요구사항의 예입니다.
- 비용 최적화: 조직에서 IT 비용을 최적화하기 위해 특정 클라우드 리소스에 할당량을 적용할 수 있습니다. 예를 들어 서드 파티 소프트웨어 라이선스 비용을 줄이기 위해 조직에서 프로비저닝할 수 있는 컴퓨팅 코어 수에 할당량을 설정할 수 있습니다. 저장할 수 있는 데이터 양과 리전 간 네트워크 트래픽 볼륨에도 유사한 할당량이 있을 수 있습니다. 이러한 비용 제약조건이 안정적인 인프라 설계에 사용할 수 있는 옵션에 미치는 영향을 고려하세요.
- 데이터 상주: 비즈니스가 전 세계 사용자에게 서비스를 제공하더라도 규제 요구사항을 충족하기 위해 애플리케이션에서 특정 국가에 데이터를 저장하고 처리해야 할 수 있습니다. 애플리케이션을 배포할 수 있는 리전과 영역을 결정할 때 이러한 데이터 상주 제약조건을 고려하세요.
다른 요구사항을 충족하기 위해 내리는 특정 설계 결정은 애플리케이션의 안정성을 개선하는 데 도움이 될 수 있습니다. 다음은 몇 가지 예시입니다.
- 배포 자동화: 클라우드 배포를 효율적으로 운영하기 위해 코드형 인프라(IaC)를 사용하여 프로비저닝 흐름을 자동화할 수 있습니다. 마찬가지로 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 사용하여 애플리케이션 빌드 및 배포 프로세스를 자동화할 수 있습니다. IaC 및 CI/CD 파이프라인을 사용하면 운영 효율뿐만 아니라 워크로드의 안정성도 개선할 수 있습니다.
- 보안 제어: 사용자가 구현하는 보안 제어도 애플리케이션 가용성 개선에 도움이 될 수 있습니다. 예를 들어 Google Cloud Armor 보안 정책은 서비스 거부(DoS) 공격 중에 애플리케이션을 계속 사용할 수 있도록 도와줍니다.
- 콘텐츠 캐싱: 콘텐츠 제공 애플리케이션의 성능을 개선하려면 부하 분산기 구성의 일부로 캐싱을 사용 설정할 수 있습니다. 이 디자인을 사용하면 사용자가 콘텐츠에 더 빠르게 액세스할 수 있을 뿐만 아니라 가용성도 높아집니다. 원본 서버가 다운되어도 캐시된 콘텐츠에 액세스할 수 있습니다.
주기적으로 요구사항 재평가
비즈니스가 발전하고 성장함에 따라 애플리케이션 요구사항이 달라질 수 있습니다. 안정성 요구사항을 주기적으로 재평가하고 조직의 현재 비즈니스 목표 및 우선순위에 부합하는지 확인합니다.
모든 사용자에게 표준 수준의 가용성을 제공하는 애플리케이션이 있다고 가정해 보겠습니다. 리전 부하 분산기를 프런트엔드로 사용하여 리전 내 두 영역에 애플리케이션을 배포했다고 해봅시다. 조직에서 더 높은 가용성을 제공하는 프리미엄 서비스 옵션을 출시할 계획이라면 해당 애플리케이션의 안정성 요구사항이 달라지게 될 것입니다. 새로운 가용성 요구사항을 충족하려면 애플리케이션을 여러 리전에 배포하고 Cloud CDN이 사용 설정된 전역 부하 분산기를 사용해야 할 수 있습니다.
애플리케이션의 가용성 요구사항을 재평가할 수 있는 또 다른 기회는 서비스 중단이 발생한 후입니다. 서비스 중단으로 인해 비즈니스 내 여러 팀 간에 기대치가 일치하지 않는 문제가 드러날 수 있습니다. 예를 들어 한 팀에서는 1년에 45분의 서비스 중단(즉, 연간 가용성 99.99%)을 허용 가능한 범주로 여길 수 있습니다. 그러나 다른 팀에서는 매월 최대 4.3분의 다운타임(즉, 월간 가용성 99.99%)을 기대할 수도 있습니다. 가용성 요구사항을 수정하거나 명확히 하는 방법에 따라 새로운 요구사항을 충족하도록 아키텍처를 조정해야 합니다.