클라우드 워크로드에 대해 안정적인 인프라를 빌드하는 첫 번째 단계는 워크로드의 안정성 요구사항이 무엇인지 파악하는 것입니다. Google Cloud 인프라 안정성 가이드의 이 부분에서는 Google Cloud에 배포하는 워크로드의 안정성 요구사항을 정의하는 데 도움이 되는 가이드라인을 제공합니다.
워크로드별 요구사항 확인
애플리케이션의 안정성 요구사항은 애플리케이션이 제공하는 서비스의 특성이나 수행 중인 프로세스에 따라 달라집니다. 예를 들어 은행의 ATM 서비스를 제공하는 애플리케이션에는 99.999%의 가용성이 필요할 수 있습니다. 온라인 거래 플랫폼을 지원하는 웹사이트에는 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%)을 기대할 수도 있습니다. 가용성 요구사항을 수정하거나 명확히 하는 방법에 따라 새 요구사항을 충족하도록 아키텍처를 조정해야 합니다.