[서비스메시] 변수명은 중요하다.

서론

---

서비스 메시를 공부하다가 핸즈온 과정에서 Jaeger를 배포했다.

업무 중에 Jaeger로 추적 스팬들을 뽑아낼 일이 있어서 익숙하다고 생각했는데, 지금 돌이켜보니 신규 구축이라 최신 버전을 끌어다 썼던 것이다.

 

핸즈온 과정에서는 v1.20을 사용하고 있었고, arm 환경에서 테스트하려면 아래 포스팅에서 언급한 바와 같이 v1.24 이상의 버전을 사용해야 했다.

[서비스메시] Istio, Envoy

 

minikube에서 처음 테스트를 한 후, 내 개인 클러스터에서 다시 배포하려는데 아키텍처 문제를 신경 쓰고 싶지 않아서 v1.24를 사용했다.
그런데, Jaeger로 스팬들이 안 모이더라 ㅜㅜ

무슨 문제가 있나 싶어서 v1.20부터 v1.24 간의 패치 노트를 찾아봤다.
그리고 v1.22에서 문제점을 찾아냈다.

Release Release 1.22.0 · jaegertracing/jaeger

 

 

--collector.zipkin.http-port is replaced by --collector.zipkin.host-port

zipkin-collector의 http port를 지칭하던 flag가 collector.zipkin.http-port에서 collector.zipkin.host-port로 변경되었고, 여기에 해당하는 환경변수 역시 COLLECTOR_ZIPKIN_HTTP_PORT 에서 COLLECTOR_ZIPKIN_HOST_PORT로 변경됐다.

 

사실 이건 서비스 메시보다는 분산 추적에 대한 내용이라고 봐야 한다.

그래도 서비스 메시 공부하면서 느낀 거니까 서비스 메시라고 할게요

 

변수명

---

여기서 문득 느낀 점이 하나 있다.

 

envoy 역시 v2 http 필터에서 v3 http 필터로 오면서 host_rewrite를 deprecate 했다.

대신, v3에서는 host_rewrite_literal과 host_rewrite_regex가 추가됐다.

 

literal은 라우팅할 호스트 필드 전체를 입력하는 것이고, regex는 정규표현식을 입력한다.

해당 필드에 들어가는 값의 성격은 다르더라도, 결국 문자열 형태로 입력될 것이다.

이런 부분에서, 값의 성격이 달라지면서 오는 혼동을 줄이고자 명시적으로 필드를 구분한 것이라 생각했다.

 

Zipkin-Collector의 flag과 env 명이 달라진 것도 유사한 이유일 것 같다.

 

Jaeger v1.20과 v1.24 둘 다 Http-Collector로 thrift, proto와 같은 rpc와 http를 지원한다.

14268	HTTP	collector	accept jaeger.thrift directly from clients
14250	HTTP	collector	accept model.proto
9411	HTTP	collector	Zipkin compatible endpoint (optional)

 

하지만, grpc 역시 http/2 위에서 도는 프로토콜임에도 http와 명시적으로 구분하고 있는데 zipkin-collector는 이걸 http로 퉁쳐버린 것이다.

 

구분할 것이라면 확실하게 구분하던지, 아니면 통일하고 호환성을 제공하는지를 결정하려한 것 같다.

그래서 HOST 라는 단어를 사용하지 않았을까?

 

익숙함은 무섭다.

---

나는 당연하게 "http-collector 면 http call만 가능한거 아니야? ㅋㅋ" 라고 생각하고 있었다.

왜냐면 Jaeger는 http와 http 상에서 도는 다른 프로토콜을 구분해 주었으니까.

그러면 우리가 rpc를 사용할 수 있는 환경임에도, http를 유지한다면 자연스럽게 순수 http로만 call하지 않았을까 싶다. 

 

이래서 변수 명이 중요하다.

패치 노트와 공식 문서를 보지 않았다면 몰랐을 테니...