Sidecar-Pattern with 여러가지 (1)

이전 프로젝트에서 한가지 의문점이 있었는데, API 통신을 하기 위해서는 무조건 GateWay를 거쳐야 한다는 점이었다.

예를들어 A pod와 B pod가 API를 통해서 데이터를 주고 받으려면 A pod > API GW > B pod 이런식의 플로우를 가지는데,

다이렉트로 pod대 pod통신을 하면 좀 더 효율적이지 않을까 싶은 생각 을 했었다.

관련 내용을 찾아보던중 Sidecar Pattern 이라는 디자인 패턴을 보게 되었는데, 역시 사람들은 이미 몇년전에 해당 패턴을 가지고 테스트를 많이 했더라...

 

암튼, 사이드카 패턴은 우리가 잘알고  있는 isto나 aws사의 app-mesh 같은 서비스가 널리 사용이 되고 있다.

이전 프로젝트도 사이드카로 datadog agent를 올려서 pod에서 발생하는 모든 로그를 수집해 가도록 구현이 되었었다.

 

나는 여기서 localhost에 2개의 스프링 프로젝트를 만들고 1개는 메인 서비스, 또 다른 하나는 사이드카 서비스로 proxy 서비스를 구현해보고자 한다.

 

1. 하려는것은 대략 아래와 같다.

여기서는 간단하게 모든 서비스에서 발생하는 모든 에러는 사이드카 서비스가 받도록 구성하고, 사이드카는 전달된 에러 값을 DB에 기록한다.

그리고 서비스간 통신을 테스트 하기위해서 메인 서비스에서 사이드카에 기록된 로그를 다시 GET 해와서 가공 후 메인 DB에 저장하는 과정을 해보려 한다.

 

여기서는 두가지 항목에 대해서 확인을 할수 있는데.

첫번째는 모든 로그를 사이드카 프로젝트로 보내는게 가능한지, 그리고 만약 사이드카 프로젝트로 모든 로그를 보내서 관리를 하는게 과연 효율적일지?  물론 데이터독 같은경우는 agent가 로그를 수집해서 중앙에서 관리하도록 구현되어 있지만 그건 솔루션 이니까...

 

두번째는 서비스간 다이렉트 통신을 할건데 다이렉트 통신이 정상적으로 잘 되는지 테스트를 해보려 한다.

그리고 다이렉트 통신과 로드밸런서를 쳐서서 통신하는 과정에서 속도도 비교해 보고자 한다.

 

간단한 테스트 이긴한데, 레퍼런스로 가지고 있고, 확장 시켜 나가면 될거같다.

 

2. 그림으로 정리

아래의 그림을 보면 총 2개의 프로젝트가 존재한다. 하나는 실제로 API를 호출하는 프로젝트이고, 나머지 하나는 특수한 목적의 작업만 처리하는 프로젝트이다. 여기서는 모든 프로젝트의 로그를 하나의 프로젝트에서 처리하도록 구성을 했다.

 

추후에는 사이드카와 서킷브레이커를 적용시켜서 테스트를 진행해보자.

- 로그를 중앙에서 관리 하는것의 문제점은 없을까?

- 나중에 EKS로 구현 시 pod로 독립적으로 실행이 될텐데 EKS 내부 안에서의 통신은 내부 통신이니 SSL종료나 기타 인증을 적용시키지 않아도 괜찮을까?

- 서비스가 많아지면 복잡도가 많이 올라가지 않을까?

- 트랜잭션 관리는 어떻게 해야할까? (일단 트랜잭션을 테스트할 간단한 UI를 만들어 놓아야 겠다.)

3. 코드는 아래의 Github 저장소에 업로드 해놓았다.

- SidecarPattern (주 애플리케이션)

https://github.com/Nanninggu/SidecarPattern/tree/master

GitHub - Nanninggu/SidecarPattern: SidecarPattern of Main Application

- SidecarPatternProxy (Sidecar 애플리케이션)

https://github.com/Nanninggu/SidecarPatternProxy

GitHub - Nanninggu/SidecarPatternProxy: SidecarPatternProxy Application

 

다음으로 테스트 할것들 정리

- 만약에 대량의 로그가 발생 했을때 사이드가 프로젝트는 어떻게 대응할까?

- 로그 수집을 이렇게 별도의 프로젝트로 독립적으로 수행하는게 맞는걸까? 단점과 장점은 뭐가 있을까?

- 트랜잭션을 일으키는 UI와 트랜잭션이 발생하는 코드를 만들어보자.

 

- 끝 -