이 페이지의 예시에서는 가이드의 개념과 권장사항을 보여주는 Fleet을 사용한 몇 가지 가상 시나리오를 보여줍니다. 이 가이드를 읽기 전에 Fleet 소개 및 Fleet 요구사항 및 권장사항의 개념을 숙지해야 합니다.
예시 1: 프로덕션, 스테이징, 개발 리소스가 있는 Fleet
이 예시에는 네 개의 클러스터가 있습니다. 클러스터 두 개는 프로덕션용(중복화를 위한 두 리전), 다른 하나는 스테이징 및 테스트용, 마지막 하나는 개발용입니다. 모든 클러스터는 플랫폼 팀이 중앙에서 소유하고 관리합니다. 이 간단한 예시에서는 frontend 및 backend의 두 가지 서비스가 있습니다. 그러나 더 복잡한 시나리오에서는 서비스와 클러스터 수가 더 많아질 수 있습니다.
접근 방식 1: 프로덕션, 스테이징, 개발을 위한 별도의 Fleet
Fleet을 활용할 수 있는 방법 중 하나는 프로덕션, 스테이징, 개발 리소스를 위한 별도의 Fleet을 만드는 것입니다.
이렇게 하려면 세 개의 Fleet 호스트 프로젝트를 만들고 이러한 프로젝트에 리소스를 배치하거나 온프레미스 개발 클러스터의 경우 example-dev 프로젝트에 클러스터를 등록합니다. 이 예시의 세부사항으로 인해 네임스페이스 동일성 및 서비스 동일성 문제를 해결할 필요가 없었지만 prod-east 및 prod-west 클러스터의 네임스페이스가 잘 정규화되었는지 확인했습니다.
이 접근 방식을 사용할 때의 장점은 각 Fleet 간에 강력하게 격리된다는 것입니다. 이 접근 방식의 주요 단점으로는 세 가지 서로 다른 Fleet을 관리해야 하므로 프로덕션, 스테이징, 개발 간의 일관성을 확보하기가 어렵습니다. 개발팀의 경우 스테이징된 서비스를 대상으로 개발하기가 더 어렵습니다.
접근 방식 2: 모든 리소스를 위한 단일 Fleet
이 접근 방식에서는 모든 리소스를 위한 단일 Fleet을 만듭니다.
이를 위해서는 example 프로젝트에 리소스를 두고 이 프로젝트에서 Fleet을 만들 수 있습니다. 프로덕션 및 스테이징 리소스를 다른 Fleet 호스트 프로젝트에 배치하고 공유 VPC를 활용하여 분리할 수 있었지만, 이 예시의 단순성을 위해 그렇게 하지 않았습니다.
이 접근 방식을 사용하는 경우 네임스페이스와 서비스가 Fleet 전체에서 정규화되는지 확인해야 합니다. 예를 들어 프로덕션 및 스테이징 클러스터에서 일반 frontend의 이름을 frontend-prod 및 frontend-staging으로 각각 바꿉니다. 마지막으로 개발 네임스페이스의 원래 이름은 유지할 수 있지만 개발 네임스페이스임을 나타내기 위해 명확한 이름(예: frontend-dev-alice)을 제공합니다.
이러한 접근 방식으로 쉬운 관리를 위해 격리를 포기합니다. Google에서는 원치 않는 서비스 간 통신을 방지하기 위해 서비스 메시 승인을 사용하고 있지만 단일 Fleet을 사용하여 전체 시스템을 쉽게 관리할 수 있습니다. 이 배치를 사용하면 모든 리소스에 정책을 적용할 수 있으므로 개발의 디자인과 분위기가 프로덕션과 매우 유사하다는 신뢰를 줍니다.
접근 방식 3: 별도의 프로덕션 및 비프로덕션 Fleet
이 접근 방식에서는 프로덕션을 별도의 Fleet에 배치하는 동시에 스테이징과 개발 리소스를 비프로덕션 Fleet에 결합하는 중간 수준을 취합니다.
이를 위해 프로덕션용 및 비프로덕션용, 총 2개의 Fleet 호스트 프로젝트를 만듭니다. 또한 비프로덕션 Fleet에 등록된 dev 클러스터 온프레미스로 이러한 프로젝트에 리소스를 직접 배치합니다. 명확성을 위해 스테이징과 개발 리소스 간의 네임스페이스와 서비스를 정규화해야 합니다. 예를 들어 스테이징 클러스터에서 frontend 이름을 frontend-staging으로 바꿉니다.
이 접근 방식의 장점은 프로덕션이 비프로덕션과 완전히 격리된다는 것입니다. 예를 들어 개발 서비스가 스테이징 서비스와 통신하도록 사용 설정할 수 있으므로 개발자 Alice가 서비스를 개발하는 동안 frontend가 스테이징된 backend와 통신할 수 있습니다.
요약
예시 1에 설명된 각 접근 방식은 유효합니다. 조직의 선택은 격리와 일관성(및 더 쉬운 관리)의 비교에 따라 다릅니다. 즉, 서로 다른 여러 리소스 종류 간 필요한 격리 수준과 필요한 일관성 수준의 비교로 결정됩니다. Fleet 수가 적은 경우에는 높은 일관성 수준을 달성하는 것이 더 쉽습니다. 세 번째 접근 방식은 개발자가 스테이징된 서비스에 대해 작업할 수 있도록 하는 동시에 프로덕션을 완전히 격리시키는, 가능한 절충안으로 제공됩니다.
예시 2: 서로 다른 리소스 소유자가 있는 Fleet
이 예시에서는 team-a와 team-b라는 두 팀이 있습니다. 이러한 두 팀은 자체 클러스터를 소유하고 관리하며 모두 생성하는 서비스에 네임스페이스 frontend 및 backend를 사용했습니다. 하지만 team-a의 frontend 또는 backend는 모두 실제로 team-b와 다릅니다. 두 팀은 서비스 간에 상호작용할 수 있도록 서비스 메시를 만들려고 합니다.
약간의 개입이 없이 이러한 클러스터를 동일한 메시에 포함할 방법은 없습니다. 클러스터 소유권을 중앙 집중식 플랫폼팀으로 전달하여 두 팀 간의 신뢰 관계를 설정하는 것은 좋은 출발점이 됩니다. 또는 team-a와 team-b 팀 간에 상호 신뢰가 있을 경우 협력하여 이 신뢰를 형성할 수도 있습니다.
다음 단계는 frontend 및 backend가 이러한 두 팀의 클러스터에서 더 이상 과부하되지 않도록 네임스페이스 사용량을 정규화하는 것입니다. 이 작업이 완료되면 모든 리소스에 대해 단일 Fleet을 설정하고 서비스 메시를 만들 수 있습니다.
이러한 수준의 신뢰를 설정할 수 없는 경우 team-a와 team-b는 서로 다른 두 개의 Fleet 호스트 프로젝트를 사용하는 두 개의 개별 Fleet을 만들어야 합니다. 이 접근 방식의 단점은 현재 단일 메시보다 관리하기 어려운 메시 페더레이션을 활용해야 한다는 것입니다. 장점으로는 두 팀이 배포된 네임스페이스 및 서비스를 정규화할 필요가 없고 명시적이고 구체적으로 승인된 통신만 가능하다는 것입니다.
