앰비언트 멀티클러스터 성능

앰비언트 멀티클러스터 성능 (Ambient Multicluster Performance)

앰비언트 모드의 멀티클러스터 배포를 사용하면 최소한의 오버헤드로 규모에 상관없이 진정한 글로벌 내결함성(resilient) 애플리케이션을 제공할 수 있어요. Istio 컨트롤 플레인은 정상적인 기능 외에도 모든 원격 클러스터에 watch을 만들어 각 클러스터가 제공하는 글로벌 서비스 목록을 최신 상태로 유지해요. Istio 데이터 플레인은 정상적인 트래픽 분산의 일부로, 또는 로컬 서비스를 사용할 수 없을 때 특히 이 원격 글로벌 서비스로 트래픽을 라우팅할 수 있어요.

출처: Istio 문서

본문

컨트롤 플레인 성능 (Control plane performance)

여기에 문서화된 것처럼 Istio 컨트롤 플레인은 일반적으로 배포 변경 × 구성 변경 × 연결된 프록시 수의 곱으로 확장돼요. 앰비언트 멀티클러스터는 컨트롤 플레인 확장성 이야기에 두 가지 새로운 차원, 즉 원격 클러스터 수와 원격 서비스 수를 추가해요. 컨트롤 플레인은 원격 클러스터를 위한 프록시를 프로그래밍하지 않기 때문에(멀티-프라이머리 배포 토폴로지를 가정), 메시에 원격 서비스 10개를 추가하는 것은 로컬 서비스 10개를 추가하는 것보다 컨트롤 플레인 성능에 훨씬 적은 영향을 줘요.

우리의 멀티클러스터 컨트롤 플레인 부하 테스트는 10개 클러스터 각각에 4000개의 엔드포인트를 가진 서비스 300개를 만들고, 이 클러스터들을 한 번에 하나씩 메시에 추가했어요. 이 규모에서 원격 클러스터를 추가했을 때의 대략적인 컨트롤 플레인 영향은 CPU 코어의 1%, 메모리 180MB 였어요. 이 규모에서는 적절히 확장된 컨트롤 플레인으로 메시에 10개 이상의 클러스터를 안전하게 확장할 수 있을 거예요. 주의할 점 하나는, 멀티클러스터 확장성의 경우 컨트롤 플레인을 수평 확장해도 도움이 되지 않는다는 거예요. 각 컨트롤 플레인 인스턴스가 원격 서비스의 완전한 캐시를 유지하기 때문이죠. 대신 멀티클러스터 메시의 요구를 충족하도록 컨트롤 플레인의 리소스 요청과 한도를 수정해 수직 확장하는 것을 권장해요.

데이터 플레인 성능 (Data plane performance)

트래픽이 원격 클러스터로 라우팅될 때, 출발지 데이터 플레인은 목적지 클러스터의 east/west 게이트웨이로 암호화된 터널을 설정해요. 그런 다음 첫 번째 터널 안에 두 번째 암호화 터널을 설정하며, 이 터널은 목적지 데이터 플레인에서 종료돼요. 이렇게 내부·외부 터널을 사용하면 데이터 플레인이 어떤 파드 IP가 어떤 서비스를 나타내는지에 대한 세부 사항을 알지 못해도 원격 클러스터와 안전하게 통신할 수 있어요.

다만 이중 암호화는 어느 정도 오버헤드를 수반해요. 데이터 플레인 부하 테스트는 같은 클러스터 안의 파드 사이 트래픽과 서로 다른 두 클러스터 사이 트래픽의 응답 지연을 측정해서 이중 암호화가 지연에 미치는 영향을 파악해요. 또한 이중 암호화는 이중 핸드셰이크를 요구해서, 원격 클러스터로의 새 연결 지연에 특히 큰 영향을 줘요. 아래에서 볼 수 있듯이, 초기 연결은 평균 2.2밀리초(346%)의 추가 지연을 관찰했고, 기존 연결을 사용하는 요청은 0.13밀리초(72%)의 증가를 보였어요. 이 수치가 크게 보일 수 있지만, 대부분의 멀티클러스터 트래픽은 가용 영역이나 리전을 가로질러 갈 것으로 예상되며, 관찰된 오버헤드 지연 증가는 데이터센터 사이의 전체 전송 지연과 비교하면 미미할 거예요.

앰비언트 멀티클러스터 성능