[이스티오] Envoy Proxy와의 Stream이 끊겼을 때 (미완)

로그와 매트릭을 수집하는 Pod에 문제가 발생하여 스트림이 끊긴 이후에

Pod이 회복되면 알아서 스트림을 다시 연결하고 전송하는 것을 본 경험이 있다.

 

내가 경험하기론 재연결 로직을 따로 구현하지 않으면 스트림을 다시 열지 않았기 때문에

Envoy Proxy는 어떻게 구현되어 있을 지 궁금해졌다.

(참고로, Stream의 경우 연결이 끊어진 순간 사라지기 때문에 재사용이 불가능하다고 한다)

 

 

먼저, Envoy Proxy의 AccessLogs 패키지 문서를 봤다.

(https://pkg.go.dev/github.com/envoyproxy/go-control-plane/envoy/service/accesslog/v3)

 

재연결의 경우 클라이언트 측에서 시도할 것이기 때문에 클라이언트 코드를 주로 살펴봤다.

 

Envoy의 gRPC 스트리밍 연결 방식이 주석으로 작성돼 있었다.

정리해보면 다음과 같다.

StreamAccessLogsMessage: Envoy가 로그 서버에 지속적으로 로그 메시지(StreamAccessLogsMessage)를 보낸다.
무응답 방식: 서버로부터 응답을 기대하지 않으며, 로그 전송에 실패하더라도 별도의 조치를 취하지 않는다. 즉, 실패 시에도 로그 재전송을 시도하지 않는 구조이다.
연결 끊기: 만약 서버가 Envoy의 재연결을 유도하려면 서버가 연결을 끊는 방식으로 작동한다.

 

흥미로운 내용들이 있지만 이번 주제와 관련된 내용이 있다.

 

연결 끊기에 대한 내용인데 Envoy의 재연결을 원하면 서버에서 연결을 끊으라는 것이다.

 

이 내용을 통해 짐작 가능한 내용은 "서버에서 연결을 끊으면 Envoy에서 재연결을 시도한다"

즉, "Envoy는 재연결을 지원한다", "모종의 이유로 서버에서 연결을 끊어도 재연결이 가능하다"를 짐작할 수 있었다.

 

재연결 로직이 있다는 실마리를 잡았으니 공식 패키지 문서에 명시된 깃허브 레포지토리에 들어가서 코드를 뒤져봤다.
https://github.com/envoyproxy/go-control-plane?tab=readme-ov-file 

 

모든 코드를 뒤져볼 수는 없는 노릇이기에 이번에도 client 관련 코드를 뒤져봤다.

 

우선 현재 에러가 gRPC 커넥션에 문제로 인해 발생한 것인지 판단하는 메서드를 찾았다.

 

이 메서드를 사용하는 부분을 찾으면 재연결에 대한 구현 내용을 찾을 수 있을 거 같은데 찾을 수가 없었다.

 

 

결론을 내보자면,

1. Envoy Proxy는 AccessLogs gRPC 서버에 대한 재연결 기능을 지원한다.

2. 서버와의 커넥션 문제 여부를 판단하는 메서드는 있지만, 직접적으로 재연결을 하는 메서드를 더 찾아봐야할 것 같다.