일반적으로 가능한 한 적은 수의 클러스터를 사용하는 것이 권장사항이지만 조직에서 다양한 이유로 기술 및 비즈니스 목표를 달성하기 위해 여러 클러스터를 배포하도록 선택합니다. 최소한 대부분의 조직은 비프로덕션 서비스를 다른 클러스터에 배치해 프로덕션 서비스와 분리합니다. 더 복잡한 시나리오에서는 조직이 여러 클러스터를 선택하여 계층, 언어, 팀, 또는 인프라 제공업체에 걸쳐 서비스를 분리합니다.
여러 클러스터를 채택해야 하는 대부분의 이유는 다음 3가지의 요구사항 카테고리로 분류됩니다.
- 격리: 서비스 제어 영역과 데이터 영역을 구분하여 신뢰성을 개선하거나 보안 요구사항을 해결합니다.
- 위치: 가용성, 지연 시간, 지역적 요구를 해결하기 위해 서비스를 특정 위치에 배치합니다.
- 확장: 특히 Kubernetes 클러스터의 컨텍스트에서 단일 클러스터에 의해 적용되는 실제 한도를 초과하여 서비스를 확장합니다.
자세한 내용은 아래 섹션에서 다루고 있습니다.
많은 경우 조직은 동시에 이러한 요구사항 중 다수의 균형을 맞춰야 합니다. 조직을 고려했을 때 일반적인 추천 사항으로는 클러스터를 가능한 한 적게 사용하는 것이 좋습니다. 어떤 멀티 클러스터 요구 사항이 조직의 가장 높은 우선순위인지 결정하고 타협할 수 없다면 적절한 절충을 수행하여 멀티 클러스터 아키텍처를 만드세요.
조직에서 서비스 모델별 클러스터 또는 클러스터별 팀 모드를 고려하는 경우 이러한 시스템의 운영자에게 주어진 관리 부담을 고려해야 합니다. Fleet 및 이를 지원하는 Google Cloud 구성요소 및 기능은 여러 클러스터를 가능한 한 쉽게 관리할 수 있게 해주지만 클러스터가 늘어남에 따라 항상 관리 복잡성이 추가됩니다.
격리
이 컨텍스트에서 격리는 제어 영역 및/또는 데이터 영역의 분리를 의미합니다. 둘 모두 여러 클러스터를 실행하여 분리할 수 있습니다. 하지만 구현에 따라 이러한 분리는 데이터 영역 격리로도 확장될 확률이 높습니다. 일반적으로 다음을 고려할 때 격리가 발생합니다.
환경
조직이 종종 서로 다른 네트워크와 클라우드 프로젝트에서 실행되는 별도의 클러스터에서 개발, 스테이징/테스트, 프로덕션 서비스를 자주 실행합니다. 이러한 분리는 프로덕션 서비스가 실수로 중단되지 않도록 하고 개발 또는 테스트 중에 민감한 정보에 액세스하지 못하게 합니다.워크로드 계층화
복잡한 애플리케이션이 많은 조직에서는 종종 서비스를 계층화하여 중요도가 낮은 클러스터와는 분리된 클러스터에서 더 중요한 서비스를 실행하는 것을 선택합니다. 이러한 환경에서는 더 중요한 서비스와 해당 클러스터가 액세스, 보안, 업그레이드, 정책 등 특별한 고려사항으로 취급됩니다. 이 계층화의 예시는 스테이트리스(Stateless) 서비스와 스테이트풀(Stateful) 서비스를 별도의 클러스터에 배치하여 분리하는 것입니다.실패로 인한 영향 감소
조직이 작업자의 실수, 클러스터 실패 또는 관련 인프라 실패의 영향을 제한하고자 할 때 서비스를 여러 클러스터로 분할할 수 있습니다.업그레이드
조직이 내부 업그레이드(즉, 자동 실패, 애플리케이션 취약성 또는 롤백 기능 업그레이드)의 잠재적인 문제에 대해 우려하는 경우 새로운 클러스터에 서비스의 복사본을 배포하도록 선택할 수 있습니다. 이러한 방식으로 업그레이드하려면 업그레이드 과정에서 트래픽 관리 및 상태 복제 작업을 처리할 수 있도록 계획 또는 자동화가 필요합니다.보안/규제 분리
조직은 덜 민감한 워크로드와는 별도로 규제 요건에 따라 워크로드를 유지하거나 자사(신뢰할 수 있는) 서비스(클러스터)와는 분리된 인프라에서 타사(신뢰도가 낮은) 서비스를 실행하는 것을 포함하여 다양한 이유로 서비스를 격리하는 것을 선택할 수 있습니다.테넌트 분리
보안 격리, 성능 격리, 비용 계산, 소유권을 포함한 다양한 이유로 테넌트를 여러 클러스터로 분리할 수 있습니다.
위치
지연 시간
특정 서비스의 경우 특정 위치(또는 지리적 위치)에 물리적으로 워크로드를 찾아 충족해야 하는 지연 시간 요구사항이 있습니다. 이는 업스트림 서비스 또는 최종 사용자가 지연 시간에 민감할 때 발생할 수 있지만 워크로드 자체가 다운스트림 서비스 지연 시간에 민감한 경우에도 쉽게 발생할 수도 있습니다.가용성
단일 클라우드 제공업체(또는 여러 제공업체)의 여러 가용성 영역에서 동일한 서비스를 실행하면 전반적인 가용성이 향상됩니다.관할권
데이터 상주 및 기타 관할 처리 요구사항을 적용하기 위해서는 특정 리전 내에서 컴퓨팅 및 스토리지가 필요할 수 있으며, 인프라를 여러 데이터 센터 또는 클라우드 제공업체에 배포해야 합니다.데이터 중력
대규모 데이터 또는 특정 데이터베이스 인스턴스 등은 단일 클라우드 제공업체 또는 리전에 통합하기 어렵거나 불가능하거나 권장되지 않을 수 있습니다. 처리 및 제공 요구사항에 따라 애플리케이션을 해당 데이터와 가깝게 배포해야 할 수 있습니다.기존 인프라/서비스
데이터를 클라우드로 이동하는 것이 어려울 수 있듯이 일부의 기존 인프라를 이동하는 것도 비슷하게 어려울 수 있습니다. 이러한 기존 서비스를 이동할 수 없지만 새 서비스를 개발할 수 있도록 추가 클러스터를 배포하면 조직에서 개발 속도를 향상시킬 수 있습니다.개발자 옵션
조직은 개발자가 사용하는 클라우드 관리형 서비스에서 개발자가 선택할 수 있는 이점을 제공할 수 있는 경우가 많습니다. 일반적으로 도구를 사용하면 각 제공업체에 할당된 추가 리소스를 관리할 필요 없이 필요에 따라 가장 적합한 도구를 사용하여 보다 신속하게 작업할 수 있습니다.로컬/에지 컴퓨팅 요구
마지막으로 조직에서 창고, 공장 바닥, 소매점 등 보다 전통적인 업무 환경에 애플리케이션 현대화 방식을 도입하려고 한다면 훨씬 많은 인프라에서 더 많은 워크로드를 관리해야 합니다.
확장
GKE는 클러스터를 노드 5,000개 이상으로 확장할 수 있으므로 이러한 한도로 인해 여러 클러스터가 작동하는 경우는 거의 없습니다. 클러스터가 확장성 한도에 도달하기 전에 조직에서는 여러 클러스터에 서비스를 배포하는 경우가 많습니다. 확장성 한도에 도달한 클러스터의 경우 여러 클러스터에서 애플리케이션을 실행하면 문제가 해결될 수 있지만 여러 클러스터를 관리해야 하는 복잡성이 추가됩니다.