[서비스메시] Ambient Mesh에 대해서

궁금증

---

서비스 메시를 공부하다가 문득 이런 궁금증이 생겼다.

 

"Kube-proxy도 노드 상에 데몬셋의 형태로 존재하며 파드로 요청을 라우팅하는데, Envoy와 같이 Istio가 사용하는 프록시는 데몬셋의 형태로 관리할 수 없을까?"

 

 

프록시를 노드 별로 데몬셋(혹은 유사한 형태)로 서빙하려면 다음과 조건들이 붙지 않을까 생각했다.

 

1. Istio를 사용하지 않는 네임스페이스의 리소스에 대한 라우팅은 무시할 것
2. 프록시를 통과하는 요청을 네임스페이스 별로 격리할 것
3. 동일 네임스페이스 내 파드 간 요청이 발생해도 노드의 프록시를 경유할 것
4. ...

 

물론 이런 조건들을 생각해보기는 했지만 이게 꼭 지켜져야 하는 필수 조건인가도 고민이 좀 됐다.

그러다 문득 Istio 블로그에서 요런 글을 보게 된다.

 

Introducing Ambient Mesh
A new dataplane mode for Istio without sidecars.

Introducing Ambient Mesh

 

 

사이드카 프록시

---

사이드카를 활용하는 기존의 방식

 

기존의 Istio는 사이드카 프록시를 활용해서 앱 컨테이너의 앞단에서 요청을 먼저 처리하고 포워딩을 결정해준다.

앱 컨테이너는 기존의 로직을 최대한 유지한 채로 프록시로부터 수신한 요청을 처리하고 그대로 반환하면 된다.

 

사이드카는 하나의 애플리케이션이 온전한 wrapper 형태로 존재하게 해주고, 주요 비즈니스 로직 외의 부수적인 로직을 처리할 수 있게 해주었다. (K8S Pods, ECS Tasks, ...)

 

그런데 요런 패턴으로 서비스를 관리하다보면서 느끼는 문제점이 있다. 사이드카 컨테이너의 변경은 곧 해당 서비스 전체를 재배포로 이어진다는 것이다.

 

요런 문제를 위 블로그에서 짚고 있다.

• 사이드카는 애플리케이션에 주입된 형태로 존재해야 한다.
• 애플리케이션의 리소스를 공유한다.
• Istio 정책에 영향을 받는 프록시는 애플리케이션의 의도와 상관없이 특정 파드로의 요청을 부정확하게 처리할 가능성이 있다.

 

이 중에서 1, 2번의 경우가 사이드카의 대표적인 문제점이라고 생각된다.

 

1번은 파드의 로컬 네트워크 내에서 요청을 처리할 수 있는 장점이 있다는 반면에 앞서 말한 주입과 업그레이드에 문제가 있다.

 

2번의 경우는, 한 노드에 불필요하게 여러 리소스를 소비하는 컨테이너가 존재할 수 있다는 것이다.

애플리케이션에서 리소스 제한을 걸어두면 그 안에서 공유하겠지만, 이것 자체가 애플리케이션의 리소스 고갈을 유발할 수 있다.

그렇다고 사이드카를 위해서 리소스 여유분을 더 확보하자니, 노드 자체의 리소스가 더 소모된다.

 

Ambient Mesh

---

아키텍처는 늘 트레이드 오프라고 하듯이, 정말 편리한 형태로 서빙을 도와주는 사이드카 패턴이지만 위와 같은 단점도 존재한다.

 

기존의 Istio 데이터 플레인에 존재하는 문제는 더 있었는데, 추상화된 하나의 레이어가 모든 기능을 담당한다는 것이다.

 

흔히들 보는 mTLS 같은 보안 레이어부터 L7 레이어까지 모든 기능이 하나의 데이터 플레인 레이어에 존재한다.

그러니까 작은 기능이나 정책 하나만 적용하려고 해도 모든 데이터 플레인 레이어가 사용된다.

 

Ambient Mesh는 이런 문제을 해결하기 위해서 Secure Overlay Layer와 L7 Processing Layer를 구분해서 구현하게 했다.

 

요런 레이어링은 Istio로의 전환에도 도움을 준다고 한다. (네임스페이스에 Istio 전체를 일괄 적용하지 않고 부분 적용 할 수 있으니 점진적으로 전환할 수 있다.)

 

기존의 L7 수준에서 이루어지던 HTTP 기반 요청 라우팅, 애플리케이션 레벨의 로드밸런싱 등등의 기능을 L7 Processing Layer에서 처리한다.

그리고, L4 (+L7) 수준에서 이루지던 TCP 기반의 정책과 기능들이나 mTLS와 같은 보안 요소들을 Secure Overlay Layer에서 처리한다.

 

그리고 주요 포인트인 데몬셋 형태의 배포를 통해서 에이전트 형태로 노드마다 동작하는 특징을 가지고 있다.

ztunnel 이라는 것으로 Ambient-Mesh 내 구성요소들을 연결한다고 한다. 요것은 Secure-Overlay를 생성해서 L4 수준의 정책을 적용시켜준다.

 

L7 기능이 필요하다면 Ambient Mesh를 활성화하고 L7 정책을 적용할 네임스페이스를 구성하면 된다.

웨이포인트 프록시가 그 역할을 수행하는데, 이건 별도 Deployment 리소스로 동적으로 배포되게 된다.

이 웨이포인트는 HTTP CONNECT over mTLS 를 통해서 HTTP 연결된 터널 위에 존재한다.

 

그러니까 정리하면, L4 기능은 노드의 공유 에이전트가 ztunnel로써 수행하고, L7 기능은 웨이포인트 프록시를 통해서 수행된다는 것이다.

데몬셋 형태의 배포는 L4 ztunnel에만 해당되는 이야기고 L7은 별도의 파드(웨이포인트)에서 처리된다.

 

이 이유를 말해주고 있는데 Envoy 자체가 멀티 테넌트를 고려해서 만든 것이 아니여서 라고 한다.

L7의 복잡한 정책이 공유 에이전트에서 처리되는 순간 보안 문제가 발생할 수 있으니, ztunnel이 커버하는 영역을 L4 처리로만 한정짓는 것으로 완화한다.

 

그래서 Ambient-Mesh 쓰냐?

---

뭔가 블로그 글을 보다보면 Ambient-Mesh는 최고야! 라고 말하는 것 같지만... 늘 공유 자원을 사용하는 곳에서는 문제가 발생하기 마련이다. 그런 점에서 사이드카를 통해서 단순한 기술적 문제 뿐만 아니라 컴플라이언스 같은 요소들도 같이 고려해볼 수 있다는 것이다.

늘 그렇지만, 대체되는 기술이 아니라 공존하는 기술로써 쓰인다고 말하고 있다.

 

어찌되었건 Ambient Mesh를 이용하면 L4 처리는 노드에서 데몬셋 형태로 처리되는 것이 가능하지만, L7 처리는 별도의 파드에서 수행되니 원래의 궁금증이 완전히 해결되지는 않았다.

 

하지만 이 기술이 L7 처리를 분리한 이유를 기술하고 있으니, 이 문제를 효과적으로 해결할 방법이 고안되지 않는 한 이것이 또 다른 대안이 아니겠나 싶다.