서비스 메시
서비스 메시 (Service mesh)
서비스 메시 는 온프레미스 및 클라우드 환경을 포함한 인프라 내부와 그 사이에서 안전한 서비스 간 통신을 제공하는 전용 네트워크 계층이에요. 서비스 메시는 종종 마이크로서비스 아키텍처 패턴과 함께 사용되지만, 복잡한 네트워킹이 관련된 모든 시나리오에서 가치를 제공할 수 있어요.
출처: 문서
본문
서비스 메시 는 온프레미스 및 클라우드 환경을 포함한 인프라 내부와 그 사이에서 안전한 서비스 간 통신을 제공하는 전용 네트워크 계층입니다. 서비스 메시는 종종 마이크로서비스 아키텍처 패턴과 함께 사용되지만, 복잡한 네트워킹이 관련된 모든 시나리오에서 가치를 제공할 수 있습니다.
서비스 메시의 이점 (Benefits of a service mesh)
서비스 메시는 보안에서 애플리케이션 복원력 개선에 이르기까지 모든 조직에 이점을 제공합니다.
HashiCorp 공동 창립자 Armon의 Consul 서비스 메시에 대해 더 알아보려면 아래 비디오를 검토하세요.
서비스 메시의 이점 중 일부:
- 서비스 검색
- 애플리케이션 상태 모니터링
- 로드 밸런싱
- 자동 장애 조치
- 트래픽 관리
- 암호화
- 관측 가능성 및 추적성
- 인증 및 인가
- 네트워크 자동화
서비스 메시를 활용하는 일반적인 사용 사례는 제로 트러스트 보안 모델을 달성하는 것입니다. 제로 트러스트 모델에서 애플리케이션은 서비스 메시 내 모든 통신이 TLS 인증서로 인증되고 전송 중에 암호화되도록 아이덴티티 기반 액세스를 요구합니다.
전통적인 보안 전략에서 보호는 주로 네트워크의 경계에 집중됩니다. 클라우드 환경에서는 네트워크 액세스의 표면 영역이 전통적인 온프레미스 네트워크보다 훨씬 넓습니다. 또한 전통적인 보안 관행은 많은 악의적인 행위자가 네트워크 경계 내부에서 발생할 수 있다는 사실을 간과합니다. 제로 트러스트 모델은 이러한 우려를 해결하면서 조직이 필요에 따라 확장할 수 있게 합니다.
어떻게 작동하나요? (How does it work?)
서비스 메시는 일반적으로 컨트롤 플레인과 데이터 플레인으로 구성됩니다. 컨트롤 플레인은 모든 서비스와 각각의 IP 주소를 추적하는 중앙 레지스트리를 유지합니다. 이 활동을 서비스 검색이라고 합니다. 애플리케이션이 컨트롤 플레인에 등록되어 있는 한, 컨트롤 플레인은 메시의 다른 구성원과 애플리케이션에 통신하는 방법을 공유하고 서로 통신할 수 있는 사람에 대한 규칙을 시행할 수 있습니다.
컨트롤 플레인은 메시 보안, 서비스 검색 촉진, 상태 검사, 정책 시행 및 기타 유사한 운영 문제를 담당합니다.
데이터 플레인은 서비스 간 통신을 처리합니다. 많은 서비스 메시 솔루션은 데이터 플레인 통신을 처리하기 위해 사이드카 프록시를 사용하므로 서비스가 네트워크 환경에 대해 가져야 하는 인식 수준을 제한합니다.
API 게이트웨이 vs. 서비스 메시 (API gateway vs service mesh)
API 게이트웨이는 들어오는 클라이언트 요청을 처리하고 서비스로 전달하는 중앙 집중식 액세스 지점입니다. API 게이트웨이는 운영자와 개발자가 들어오는 클라이언트 요청을 관리하고 요청에 따라 다른 처리 로직을 적용할 수 있게 하는 컨트롤 플레인 역할을 합니다. API 게이트웨이는 들어오는 요청을 각각의 서비스로 라우팅합니다. API 게이트웨이의 주요 기능은 요청을 처리하고 서비스의 응답을 클라이언트로 반환하는 것입니다.
서비스 메시는 서비스의 네트워크 관리와 서비스 간 통신을 전문으로 합니다. 메시는 서비스와 그 상태, IP 주소, 트래픽 라우팅을 추적하고 서비스 간 모든 트래픽이 인증되고 암호화되도록 보장합니다. 일부 API 게이트웨이와 달리 서비스 메시는 모든 등록된 서비스의 수명 주기를 추적하고 요청이 서비스의 정상 인스턴스로 라우팅되도록 보장합니다. API 게이트웨이는 트래픽이 서비스의 정상 및 사용 가능한 인스턴스로 전달되도록 로드 밸런서와 함께 자주 배포됩니다. 메시는 라우팅 책임이 분산된 방식으로 처리되므로 로드 밸런서의 자취(footprint)를 줄입니다.
API 게이트웨이는 외부 네트워크(비메시)를 서비스 메시와 연결하기 위해 서비스 메시와 함께 사용할 수 있습니다.
API 게이트웨이와 트래픽 방향: API 게이트웨이는 종종 north-south 트래픽을 수락하는 데 사용됩니다. North-south 트래픽은 데이터센터나 가상 프라이빗 네트워크(VPC)에 들어오거나 나가는 네트워크 트래픽입니다. API 게이트웨이를 서비스 메시에 연결하고 메시 외부에서 액세스를 제공할 수 있습니다. 서비스 메시는 주로 east-west 트래픽을 처리하는 데 사용됩니다. East-west 트래픽은 전통적으로 데이터센터나 VPC 내부에 유지됩니다. 서비스 메시는 다른 데이터센터나 VPC의 다른 서비스 메시에 연결되어 페더레이션 메시를 형성할 수 있습니다.
어떤 문제를 해결하나요? (What problems does it solve?)
현대 인프라는 주로 정적에서 동적(임시적)으로 전환되고 있습니다. 이 동적 인프라는 수명 주기가 짧아 가상 머신(VM)과 컨테이너가 자주 재활용됩니다. 수명이 짧은 리소스에 존재하는 애플리케이션 서비스를 조직이 관리하고 추적하는 것은 어렵습니다. 서비스 메시는 모든 등록된 서비스의 중앙 레지스트리 역할을 하여 이 문제를 해결합니다. 서비스의 인스턴스(예: VM, 컨테이너, 서버리스 함수)가 올라오고 내려갈 때 메시는 그 상태와 가용성을 알고 있습니다. 서비스 검색 을 수행하는 능력은 서비스 메시가 해결하는 다른 문제들의 기초입니다.
서비스 메시는 서비스와 그 인스턴스의 상태를 알고 있으므로 더 지능적이고 동적인 네트워크 라우팅을 구현할 수 있습니다. 많은 서비스 메시는 L7 트래픽 관리 기능을 제공합니다. 결과적으로 운영자와 개발자는 필요에 따라 네트워크 트래픽을 지시하는 로드 밸런싱, 트래픽 분할, 동적 장애 조치, 사용자 지정 리졸버와 같은 강력한 규칙을 만들 수 있습니다. 서비스 메시의 동적 네트워크 동작을 통해 애플리케이션 소유자는 애플리케이션 변경 없이 애플리케이션 복원력과 가용성을 개선할 수 있습니다.
점점 더 많은 애플리케이션이 다른 클라우드 제공자(멀티 클라우드)와 프라이빗 데이터센터에 배포됨에 따라 동적 네트워크 동작 구현이 중요해지고 있습니다. 조직은 네트워크 트래픽을 다른 인프라 환경으로 라우팅해야 할 수 있습니다. 이 트래픽이 안전한지 확인하는 것은 모든 조직의 주요 관심사입니다. 서비스 메시는 모든 서비스 간에 네트워크 트래픽 암호화(mTLS)와 인증을 시행하는 기능을 제공합니다. 서비스 메시는 각 서비스와 그 인스턴스에 대해 SSL 인증서를 자동으로 생성할 수 있습니다. 인증서는 메시 내부의 다른 서비스와 인증하고 TCP/UDP/gRPC 연결을 SSL로 암호화합니다.
어떤 서비스가 서로 통신할 수 있는지 결정하는 세분화된 정책은 서비스 메시의 또 다른 이점입니다. 전통적으로 서비스는 방화벽 규칙을 통해 다른 서비스와 통신할 수 있습니다. 전통적인 방화벽(IP 기반) 모델은 수명 주기가 짧고 IP 주소가 자주 재활용되는 동적 인프라 리소스에서는 시행하기 어렵습니다. 결과적으로 네트워크 관리자는 네트워크 트래픽을 생성하는 서비스를 구분하지 않고 서비스 간 네트워크 트래픽을 허용하기 위해 네트워크 범위를 열어야 합니다. 그러나 서비스 메시를 사용하면 운영자와 개발자가 IP 기반 모델에서 벗어나 서비스 간 권한에 더 집중할 수 있습니다. 운영자는 서비스 A 만 서비스 B 와 통신할 수 있도록 하는 정책을 정의합니다. 그렇지 않으면 기본 동작은 트래픽을 거부하는 것입니다. IP 주소 기반 보안 모델에서 서비스 중심 모델로의 전환은 네트워크 트래픽 보안의 오버헤드를 줄이고 조직이 복잡성으로 인해 보안을 희생하지 않고 멀티 클라우드 환경을 활용할 수 있게 합니다.
서비스 메시를 어떻게 구현하나요? (How do you implement a service mesh?)
서비스 메시는 일반적으로 Kubernetes 클러스터에 설치됩니다. Kubernetes 기반이 아닌 워크로드를 위한 플랫폼에 구애받지 않는 서비스 메시도 있습니다. Kubernetes의 경우 대부분의 서비스 메시는 운영자가 Helm 차트를 통해 설치할 수 있습니다. 또한 서비스 메시는 서비스 메시의 설치와 유지 관리를 지원하는 CLI 도구를 제공할 수 있습니다. Kubernetes 기반이 아닌 서비스 메시는 Terraform, CloudFormation, ARM Templates, Puppet, Chef 등과 같은 코드형 인프라(IaC) 제품을 통해 설치할 수 있습니다.
멀티 플랫폼 서비스 메시란? (What is a multi platform service mesh?)
멀티 플랫폼 서비스 메시는 다양한 인프라 환경을 지원할 수 있습니다. 이는 서비스 메시가 Kubernetes 및 비-Kubernetes 워크로드를 지원하는 것부터 다양한 클라우드 환경(멀티 클라우드 및 하이브리드 클라우드)에 걸쳐 서비스 메시가 확장되는 것까지 다양할 수 있습니다.
다른 서비스 메시 소프트웨어와 Consul 비교 (Consul compared to other service mesh software)
예제: Istio, Solo Gloo Mesh, Linkerd, Kong/Kuma, AWS App Mesh
Consul은 마이크로서비스와 클라우드 인프라(멀티 클라우드 및 하이브리드 클라우드) 운영의 네트워킹 및 보안 문제를 해결하는 완전한 기능을 갖춘 서비스 메시 솔루션을 제공하는 멀티 네트워킹 도구입니다. Consul은 라우팅 및 분할에 대한 소프트웨어 기반 접근 방식을 제공합니다. 또한 실패 처리, 재시도, 네트워크 관측 가능성과 같은 추가 이점을 제공합니다. 이러한 각 기능은 필요에 따라 개별적으로 사용하거나 함께 사용하여 완전한 서비스 메시를 구축하고 제로 트러스트 보안을 달성할 수 있습니다.
Consul의 서비스 메시를 통해 조직은 여러 다른 환경에서 네트워크 서비스를 안전하게 연결하고 관리할 수 있습니다. Consul은 모든 서비스에 연결된 사이드카 프록시로 Envoy를 사용하여 모든 서비스 간 통신이 인가되고, 인증되고, 암호화되도록 보장합니다. Consul에는 개발자가 카나리아 테스트, A/B 테스트 및 블루/그린 배포를 수행하는 데 도움이 되는 로드 밸런싱 및 트래픽 분할과 같은 트래픽 관리 기능이 포함됩니다. 또한 Consul에는 상태 검사 및 관측 가능성 기능이 포함됩니다.
Consul은 플랫폼에 구애받지 않습니다. 모든 런타임(Kubernetes, EKS, AKS, GKE, VM, ECS, Lambda, Nomad)과 모든 클라우드 제공자(AWS, Microsoft Azure, GCP, 프라이빗 클라우드)를 지원합니다. 이는 Consul을 가장 유연한 서비스 검색 및 서비스 메시 플랫폼 중 하나로 만듭니다. 다른 서비스 메시 소프트웨어는 데이터 플레인에 대해 여러 런타임을 지원하지만 컨트롤 플레인을 Kubernetes에서만 실행해야 합니다. Consul을 사용하면 컨트롤 플레인과 데이터 플레인을 서로 다른 런타임에서 실행할 수 있습니다.
Consul은 또한 시크릿 관리의 업계 표준인 Vault와 몇 가지 고유한 통합이 있습니다. 운영자는 Consul의 기본 제공 인증 기관을 사용하거나 Vault의 PKI 엔진을 활용하여 데이터 플레인과 컨트롤 플레인 모두에 대한 TLS 인증서를 생성하고 저장할 수 있습니다. 또한 Consul은 데이터 플레인과 컨트롤 플레인 모두에서 TLS 인증서를 다시 시작 없이 자동으로 회전할 수 있습니다. 이를 통해 운영자에게 추가 관리 부담을 주지 않고 인증서를 더 자주 회전할 수 있습니다. Kubernetes에 Consul을 배포할 때 라이선스, ACL 토큰, TLS 인증서를 포함한 민감한 데이터를 Kubernetes 시크릿 대신 Vault에 중앙 집중식으로 저장할 수 있습니다. Vault는 모든 데이터를 자동으로 암호화하고, 시크릿에 대한 고급 액세스 제어를 제공하며, 모든 시크릿에 대한 중앙 집중식 거버넌스를 제공하기 때문에 Kubernetes 시크릿보다 훨씬 안전합니다.