마이크로서비스 아키텍처가 개발자에게 주는 가장 좋은 점 가운데 하나는 배포의 자유로움이다.
일반적으로 마이크로서비스를 지향하는 서비스 시스템은 Monolithic 서비스과 대조적으로 제공하는 기능의 개수가 아주 작다. 따라서 고치는 것이 그만큼 훨씬 더 자유롭다. Jenkins의 Build now 버튼을 누르는데 주저함이 없다고나 할까…
하지만 얼마나 잘게 쪼갤 것인가? 큰 고민거리다. QCon 컨퍼런스에서도 이야기가 있었지만, 최선의 방식은 가능한 작게 쪼개는 것이다. 서비스 시스템이 정의되면 이를 위한 http(s):// 로 시작하는 엔드포인트가 만들어진다. 그리고 다른 서비스 시스템들이 이를 코드(정확하게 이야기하자면 Configuration이겠지만)에 반영해서 사용한다. 이 과정에서 문제가 발생할 가능성이 생긴다.
- 엔드포인트는 고정된 값이다. 보통 엔드포인트를 VIP 혹은 ELB를 가지고 사용하면 변경될 가능성이 적긴하다. 그렇지만 변경되면(!!) 사건이 된다. 변경에 영향을 받는 시스템들을 변경된 값에 맞춰 작업해줘야 한다. 이렇게 보면 이게 Monolithic 시스템과 뭔 차이인지 하는 의구심마저 든다.
- 초보자는 이름을 헤메게 된다. 잘게 쪼개진 그 이름들을 다 알 수 있을까? 이런건 어딘가에 정말 잘 정리되어 있어야 찾을까 말까다. 연동할 시스템을 찾아 삼만리를 하다보면 짜증도 나고, 이게 뭐하는 짓인지 의구심마저 들게 된다. 특히나 좀 후진(개발 혹은 QA) 시스템들은 DNS를 등록해서 사용하지도 않기 때문에 더욱 난맥상을 빠질 수 있다.
이런 고민을 놓과 봤을 때 가장 합리적인 결론은 “정리된 목록“이다. 언제나 승리자는 정리를 잘 하는 사람이다. 하지만 시스템이 사람도 아니고… 목록이 있다고 읽을 수 있는건 아니지 않은가???
읽을 수 있다. 물론 그 목록이 기계가 읽을 수 있는 포맷이라면!!! 읽을 수 있다는 사실은 중요하다. 이제 사람이 알아들을 수 있는 “말”을 가지고 기계(시스템)를 다룰 수 있을 것 같다.
http://pds26.egloos.com/pds/201404/12/99/c0109099_5348f03fbc7cd.jpg
가능할 것 같으니 해봐야지! NamedApiEndpoint라는 Github 프로젝트로 해봤는데, 나름 잘 동작하는 것 같다.
https://github.com/tony-riot/api-discoverous
- 동작하는 건 앞서 이야기한 것처럼 서비스 시스템의 엔드포인트를 이름으로 참조한다.
- 이름 참조를 위해서는 { name, endpoint } 쌍을 보관하는 별도의 Repository가 물론 있어야 한다.
- NamedApiEndpoint에서는 스프링 프레임워크(Spring framework)를 바탕한다.
- 어플리케이션 시작 시점에 이름을 기초로 엔드포인트를 쿼리한다.
- 쿼리된 엔드포인트 정보와 URI 정보를 이용해 Full URL을 구성해서 RestTemplate와 동등한 Operation set을 제공한다.
Repository는 별도 시스템으로 만들수도 있지만, Serverless 환경으로 이를 구성시킬 수도 있다. 내부적으로는 AWS DynamoDB를 API G/W를 연동해서 Repository 서비스로 만들었다. 이 부분에 대한 내용은 다른 포스팅에서 좀 더 다루겠다. 분명한 사실은 재미있다라는 거!
빙빙 돌려 이야기를 했지만 Service discoverous라는 개념이다. 관련해서 정리된 글을 링크해본다. 기본적으로 Discovery와 Registry의 개념을 어떤 방식으로 구현하는지에 따라 달리겠지만 Spring 혹은 Springboot를 주로 많이 사용하는 환경에서 사용하기에 큰 문제는 없는 것 같다. 굳이 Well-known 방식을 선호한다면 링크한 페이지를 잘 체크해보면 되겠다.
– 끝 –