서비스 메시 정보
서비스 메시는 서비스 간 통신을 용이하게 하는 애플리케이션의 인프라 계층입니다. 서비스 메시는 트래픽 관리, 복원력, 정책, 보안, 강력한 ID 및 관찰성과 같은 기능을 워크로드에 제공합니다. 애플리케이션은 이러한 운영 기능에서 분리되는 반면, 서비스 메시는 애플리케이션 계층의 외부로 이동하고 인프라 계층으로 하향합니다.
시나리오
서비스 메시를 사용하는 경우 다음과 같은 시나리오를 사용하도록 설정할 수 있습니다.
클러스터의 모든 트래픽 암호화: 클러스터의 지정된 서비스 간에 상호 TLS를 사용하도록 설정합니다. 이는 네트워크 경계의 수신 및 송신으로 확장할 수 있으며 애플리케이션 코드 및 인프라에 필요한 변경 없이 기본적으로 안전한 옵션을 제공합니다.
카나리아 및 단계적 롤아웃: 클러스터의 새 서비스 집합으로 라우팅될 트래픽 하위 집합에 대한 조건을 지정합니다. 카나리아 릴리스를 성공적으로 테스트하는 경우, 조건부 라우팅 및 단계를 제거하여 새 서비스에 대한 모든 트래픽의 퍼센트(%)를 점차적으로 늘립니다. 결국 모든 트래픽이 새 서비스로 전송됩니다.
트래픽 관리 및 조작: 특정 원본의 서비스 버전으로 모든 트래픽을 제한하는 서비스에 대한 정책 또는 지정된 서비스 간의 오류 클래스에 재시도 전략을 적용하는 정책을 만듭니다. 마이그레이션하는 혹은 문제를 디버그하는 동안 새 버전의 서비스로 라이브 트래픽을 미러링합니다. 테스트 환경의 서비스 사이에 오류를 삽입하여 복원력을 테스트합니다.
가시성: 서비스가 그 사이 흘러가는 트래픽에 서로 연결되는 방법에 대한 인사이트를 얻습니다. 수신/송신을 포함하여 클러스터의 모든 트래픽에 대한 메트릭, 로그, 추적을 수집합니다. 애플리케이션에 분산 추적 기능을 추가합니다.
선택 조건
서비스 메시를 선택하기 전에 요구 사항 및 서비스 메시를 설치하는 이유를 이해해야 합니다. 다음 질문 사항에 대해 답합니다.
수신 컨트롤러는 사용자의 요구에 충분한가요?: 때때로 a/b 테스트 또는 트래픽 분할과 같은 기능이 요구되는 시나리오를 지원하기에 충분한 경우도 있습니다. 무턱대고 사용자 환경에 복잡성을 추가하지 마세요.
워크로드 및 환경에서 추가 오버헤드를 허용할 수 있나요?: 서비스 메시를 지원하는 데 필요한 모든 구성 요소에는 CPU 및 메모리와 같은 리소스가 필요합니다. 모든 프록시 및 그와 관련된 정책 검사는 트래픽에 대기 시간을 추가합니다. 대기 시간에 매우 민감하거나 서비스 메시 구성 요소를 다루는 추가 리소스를 제공할 수 없는 워크로드가 있는 경우 서비스 메시 사용을 다시 고려해야 합니다.
불필요한 복잡성이 추가되고 있나요?: 비즈니스 팀 또는 운영 팀에 중요하지 않은 기능을 사용하기 위해 서비스 메시를 설치하려는 경우 그에 따라 더해지는 설치, 유지 관리 및 구성의 복잡성을 감수할 가치가 있는지 고려합니다.
이는 증분 방식으로 채택될 수 있나요?: 많은 기능을 제공하는 일부 서비스 메시는 더 큰 증분 방식으로 채택될 수 있습니다. 성공 여부를 확인하는 데 필요한 구성 요소만 설치합니다. 나중에 더 많은 기능이 필요하다는 것을 알게 되면 나중에 살펴보세요. 처음부터 모든 항목을 설치하는 것은 시급하지 않습니다.
다음 단계
AKS(Azure Kubernetes Service)는 Istio 및 Open Service Mesh에 대해 공식적으로 지원되는 추가 기능을 제공합니다.
또한 AKS와 함께 일반적으로 사용되는 오픈 소스 프로젝트 및 타사에서 제공하는 서비스 메시가 있습니다. 이러한 서비스 메시에 대해서는 AKS 지원 정책에서 다루지 않습니다.
서비스 메시 가로에 대한 자세한 내용은 레이어 5의 서비스 메시 가로를 참조하세요.
서비스 메시 표준화 작업에 대한 자세한 내용은 다음을 참조하세요.