(OSC Korea x Solo.io) The Future of Service Mesh

목차

 

개요

한국 오픈소스 인프라 커뮤니티 행사인 ‘OpenInfa & Cloud Native Day Korea 2022’ 리뷰

OSC Korea의 이제응 대표님과 Solo.io 의 Ashish Kumar 공동 발표 진행 세션

 

세션

OSC Korea 소개와 OpenMSA 에서의 Solo.io 소개 가 간락하게 이루어졌다.

실제 기업들이 Service Mesh 도입에 겪는 애로사항

해당 ppt 에서 service mesh 적용이 어려운 점을 설명하고 있다.

추가로 Istio 를 도입한 기업들도 사용 방식에 차이가 있다고 한다. istio 만 사용하여 모든 api 를 관리하거나, istio 를 일부분만 쓰고 앞단에 kong 같은 다른 api 서비스를 사용하는 등 이런 복잡성은 관리에 문제를 일으킨다고 한다.

solo.io 는 istio 기반의 gloo mesh 라는 플랫폼을 가지고 있으며 api gateway, k8s ingress, service mesh 및 networking 기술을 통합한다고 한다.

 

Istio

이후 ashish kumar Director 가 이어서 발표했다.

solo.io 의 APAC 지역 feild engineer 라고 한다.

짧게 istio 의 연혁에 대해 소개하는 챕터를 가졌다.

2017년에 시작되었고 2022년 9월에는 새로운 데이터 플레인 모드인 ambient mesh 를 런칭했다고 한다.

istio 의 service mesh 기능에 대해 소개하는 챕터였다.

앱의 구현에 편리하고, 7계층 기반 보안 기능을 제공한다고 한다. 앱은 또한 서비스 검색, 라우팅, 서비스 격리 기능 구현등을 제공한다고 한다. 이 모든 것들은 사이드카에 의해 제공된다.

 

그런데 이 아키텍처가 가져오는 몇 가지 문제가 있다고 한다.

http 관련 강력한 구현이 없다면 일부 응용프로그램 구동에 문제가 있을 수 있다고 한다.

또, 리소스가 과잉 프로비저닝 되는 문제도 있다고 한다. 일반적으로 프로덕션 환경에서는 그렇지 않지만 클러스터는 항상 초과적 프로비저닝이되고 있고, 워크로드 뿐만 아니라 사이드카에 대한 과잉 프로비저닝도 있다고 한다.

 

eBPF

위 문제를 해결하기 위해 ambient mesh 모듈에서 eBPF 를 사용한다고 한다

사이드카 프록시의 경우 각 애플리케이션 인스턴스와 함게 사이드카 프록시를 배포하게 되고 사이드카에는 워크로드 대신 라우팅하는 데 필요한 모든 구성이 있다고 한다. 많은 워크로드 및 프록시가 있을 경우 최적화되지 않은 리소스 프로비저닝이 발생할 수 있다고 한다. 워크로드별로 업데이트를 수행할 수 있고, 특정 워크로드에만 영향을 미치는 카나리아 배포를 수행할 수도 있지만 여전히 사이드카를 삽입하는 것은 까다롭고 버전간 변경이 있는 경우 앱 인스턴스에 영향을 미칠 수도 있다.

두번째 모델은 노드당 공유 프록시로 트래픽을 라우팅하는데 필요한 라우팅 및 클러스터로 구성된 각 사이드카 프록시 대신 해당 구성이 단일 프록시의 노드에 있는 모든 워크로드에서 공유된다. 결국 하나의 프로세스에서 모든 워크로드 인스턴스의 문제를 다루며 이는 버전충돌, 구성충돌 또는 확장 비호환성과 같은 문제가 발생할 수 있고 이 노드들의 문제는 공유 프록시를 업그레이드 할 때 전체 워크로드에 영향을 미칠 수도 있다고 한다.

세번째 모델은 서비스 계정 기반 공유 프록시 라고 한다. 전체 노드에 단일 공유 프록시를 사용하는 대신 프록시를 노드당 특정 서비스 계정으로 격리 할 수 있다고 한다. 이 모델로 기존 모델들의 사이드카 주입에 있던 복잡성을 해결할 수 있다고 한다. 이 모델은 스스로 리소스를 최적화해줄 수 있다고 한다.

 

ambient mesh

사이드카가 없는 istio 를 위한 새로운 데이터 플레인 모드라고 한다.

위에 설명한 사이드카 모델의 단점을 보완하기 위해 설계되었고 더 광범위한 애플리케이션 호환성과 비용절감한 서비스

ztunnel 을 에이전트로 사용하며 메시 내 요소를 안전하게 연결하고 인증한다고 한다. 노드의 네트워킹 스택은 참여 워크로드의 모든 트래픽을 로컬 ztunnel 에이전트를 통해 리다이렉션한다. ztunnel 은 워크로드 트래픽에 대해 L7 처리를 수행하지 않으므로 사이드카보다 훨씬 간편하다고 한다. 복잡성 및 관련 리소스 비용이 크게 감소하여 공유 인프라로 제공될 수 있다.

사이드카는 서비스를 제공하는 워크로드와 함께 위치하며 결과적으로 하나의 취약성이 다른 애플리케이션을 손상시킬 수 있는데, 엠비언트 메시 모델에서 애플리케이션이 손상되더라도 ztunnel 및 웨이포인트 프록시는 여전히 손상된 애플리케이션의 트래픽에 대해 엄격한 보안 정책을 시행할 수 있다.

 

추가

해당 세션을 본 후 이해가 잘 되지 않는 부분을 찾아보고, 생소한 용어들을 찾아보았다.

• service mesh
  • 기존 microservice architecture 관리의 오버헤드를 낮추기 위해 나온 아키텍처
  • 기존의 서비스 아키텍처에서의 호출이 직접 호출이라면 service mesh 는 프록시(경량화된 L7기반)끼리 이루어진다.
  • data plane
    • 프록시들로 이루어져 트래픽을 설정값에 따라 컨트롤 하는 부분
  • control plane
    • 프록시들에 설정값을 전달하고 관리하는 컨트롤러
• istio
  • data plane 의 메인 프록시, Envoy proxy 를 사용하며 이를 컨트롤 해주는 Control Plane 의 오픈소스 솔루션
  • Envoy Proxy
    • c++ 로 개발된 고성능 프록시 사이드카
  • 기능
    • 쉬운 규칙 구성과 트래픽 라우팅을 통해 서비스간의 트래픽 흐름과 api 호출 제어
    • 기본적으로 envoy 를 통해 통신하는 모든 트래픽을 자동으로 TLS 암호화
    • 서비스간 상호작용에 대해 access, role 등의 정책을 설정해 리소스가 각 서비스에게 공정하게 분배되도록 제어
    • 강력한 모니터링 및 로깅 기능 제공
• eBPF
  • 확장 BPF 라는 뜻, 기존 BPF 를 cBPF 라고 구분함
  • Berkely Packet Filter
    • BPF 는 네트워크 트래픽을 분석해야 하는 프로그램을 위해 특정 OS 에서 사용되는 기술이다.
  • 커널 소스 코드를 바꾸거나 모듈을 추가할 필요 없이 프로그램을 os 커널 공간에서 실행하는 기술
  • k8s 환경 내에 관찰 가능성이 수월해지고 네트워킹 및 보안 부분에도 장점이 생기게 됨
• ztunnel
  • 제로 트러스트 터널
  • 서비스간 연결을 보호하는 기능을 제공하는 보안 오버레이 계층
  • 암호화 기반 ID 및 L4 권한 부여 정책을 사용해 애플리케이션 간 상호 TLS 암호화 통신 지원

 

 

참고

https://istio.io/latest/blog/2022/introducing-ambient-mesh/

Introducing Ambient Mesh

https://www.solo.io/blog/traffic-ambient-mesh-ztunnel-ebpf-waypoint/

Traffic in ambient mesh: Ztunnel, eBPF configuration, and waypoint proxies

https://www.solo.io/products/ambient-mesh/

Ambient Mesh

https://gruuuuu.github.io/cloud/service-mesh-istio/

Service Mesh Architecture & Istio를 알아보자

https://hyeyoo.com/133

[Linux Kernel] BPF/eBPF란 무엇인가