MSA로의 첫걸음
VUNO Med® 제품은 고객사 내부에 서버와 프로그램을 설치해서 고객사 전용으로 서비스를 사용할 수 있도록 하는 Standalone 방식과 별도의 설치 없이 웹 브라우저에서 로그인 해서 서비스를 사용하는 클라우드 방식 두 가지로 판매를 하고 있습니다. 이 중 클라우드 방식의 경우 기존에는 같은 VPC 내의 서버에서 서비스하는데도 불구하고 각 제품 별로 멤버십과 크레딧 시스템이 다 따로 분리가 되어 있어서 전혀 다른 서비스처럼 동작을 했습니다.
이러한 방식은 한 병원에서 여러 개의 제품을 사용하는 경우, 혹은 중간에 대리점이 있는 경우 각 제품 별로 아이디를 만들고 로그인 해서 관리를 해야 하는 불편함이 있습니다. 또한 중요한 개인 정보가 여기 저기 분산되어 있음으로 인해서 보안 측면에서도 장기적으로 관리가 어렵다고 보았습니다.
이에 이번에 안저(Fundus) 진단 서비스를 클라우드 방식으로 오픈하면서 멤버십과 라이센스/크레딧 관리 시스템을 통합하고 VUNO Med® 각 제품이 마이크로 서비스(Micro Service)로 동작하는 것으로 새롭게 아키텍처를 구축했습니다.
API Gateway 도입
먼저 마이크로 서비스 아키텍처의 꽃! API Gateway를 도입에 관해 이야기 해 보겠습니다. API Gateway란 사용자가 설정한 라우팅 룰에 따라 각 서비스 엔드포인트로 클라이언트를 대리하여 요청하고 응답을 받으면 다시 클라이언트에게 전달하는 프록시(proxy) 역할을 하는 서버입니다. API Gateway를 이용하면 통합적으로 엔드포인트와 REST API를 관리할 수 있고, 모든 클라이언트의 요청은 API Gateway로 전달됩니다.
API Gateway를 사용함으로써 얻을 수 있는 여러 가지 장점이 있지만, 특히 다음과 같은 장점에 주목하여 도입하기로 했습니다.
- 공통의 로직(인증/인가, 로깅 등)을 앞 단에서 처리해 주어서, 각 Micro Service가 동일한 기능을 구현, 관리, 유지보수 하는 번거로움을 줄여 줍니다.
- 내부의 서비스 로직을 감춤으로써 보안을 강화할 수 있습니다.
- 각 Micro Service로 호출되는 API를 통합적으로 관리, 모니터링하기가 용이합니다.
다양한 API Gateway가 있지만 저도 Java 진영의 Zuul, Spring Cloud 등만 접해 본 지라 어떤 것을 도입해야 할 지 고민을 했는데, 팀원들이 모두 익숙한 Nginx 기반이고 대중적으로 많이 사용되며 무료 버전이 있는 등 여러 가지 이유로 Kong으로 결정을 했습니다.
처음에는 Kong에서 기본적으로 제공하는 Plugin으로 다 되는 줄 알고, 설치 후 Konga로 간단히 설정만 하면 될 거라고 생각했으나 이는 오산이었습니다. 저희가 생각한 가장 기본적인 기능인 JWT Authorization 조차도 Enterprise 버전에서만 제공되는 Plugin이었습니다.
(사실 인증 방식으로 JWT를 사용하지 않으면 문제가 없으나, 기존의 서비스들이 모두 JWT를 쓰고 있었기 때문에 통합을 쉽게 하기 위해 JWT에 대한 인증/인가 처리는 반드시 필요했습니다.)
이 때문에 API Gateway는 단순 Routing 기능만 수행하는 것으로 할까도 잠깐 고민했으나 장기적으로는 결국 Plugin을 직접 구현해야 한다고 판단이 되어서 영기샘이 급히 Lua를 공부하여 Plugin을 개발했습니다. 사실 코드는 몇 줄 안되는데 처음 접하는 언어이다 보니 개발 및 테스트 환경을 셋업하는 것이 더 오래 걸렸던 것 같습니다. 이와 관련된 자세한 뒷얘기는 다음에 영기샘이 다른 컨텐츠로 정리해 주시기를 기대해 봅니다.
그래서 결론적으로 현재 VUNO Med® 클라우드 서비스에서 Kong API Gateway는 크게 두 가지 기능을 수행하고 있습니다.
- API 요청 URL에 따라 각 마이크로 서비스로 라우팅
- JWT 토큰 인증/인가
SSO(Single Sign On)
멤버십 통합은 필수적이라고 보았는데, SSO를 할 것인지에 대해서는 팀 내부에서도 논란이 있었습니다. SSO란 여러 서비스 간의 인증을 통합하는 것을 뜻합니다. 구글이나 네이버 같은 일반적인 서비스에서는 공통의 로그인 창이 있고, 여기에서 로그인을 하면 다른 모든 서비스는 별도의 로그인 과정 없이 이용이 가능합니다.
하지만 한 명의 의사 선생님이 여러 종류의 의료 진단 서비스를 동시에 사용할 가능성이 별로 없는 VUNO Med® 서비스에서도 그렇게 해야 하는가에 대한 의문이 있었습니다. 그래도 병원의 관리자 역할을 하는 의사 혹은 간호사 선생님이 진단 결과를 같이 확인하고자 할 때나 리셀러 회사에서 여러 제품을 관리할 때 여러 번 로그인 해야 하는 불편함이 있고, 추후 서비스의 확장성을 위해서도 SSO로 하는 것이 좋겠다고 결론을 내렸습니다. SSO를 구현하는 것이 개별 로그인으로 하는 것보다 더 어려워서 되돌아 가는 것이 쉽다는 것도 의사 결정의 포인트였습니다.
JWT 인증 방식을 사용할 때 SSO를 어떻게 구현할 것인가에 대해서도 여러 가지 방안을 검토했지만 결국 이것도 추후 확장성을 위해 구글느님이 사용하는 iframe을 이용하는 방식으로 구현을 했습니다. 상세한 방법은 아래 stackoverflow 글을 참조하세요.
VUNO Med® MSA v1.0
이렇게 마이크로 서비스 아키텍처가 구축 되었지만 실제로 마이크로 서비스로 통합된 진단 서비스는 아직 안저(Fundus) 밖에 없습니다. 현재 아키텍처는 그림과 같이 로드 밸런서가 제일 앞단에 있고 통합 멤버십 서비스와 안저 서비스 URL로 요청이 오는 경우에만 API Gateway로 라우팅이 되도록 구성되어 있습니다.
조만간 본에이지(BoneAge), 체스트 엑스레이(CXR) 등이 점차 마이크로 서비스로 편입이 될 예정입니다.
다음 걸음은 어디로..
이제 막 MSA로의 첫 걸음을 내디뎠기 때문에 다음 걸음은 어디로 갈 지 아직 방향성을 정하지는 못했으나 몇 가지 후보로 생각하고 있는 것은 있습니다.
우선 첫번째로 API Gateway가 지금은 기본적인 기능만 수행하고 있는데 Response Caching, Rate Limiting 등의 추가 기능을 구현함으로써 서비스의 품질을 높이는 것이 있습니다.
다음으로 Micro Service 간 통신을 현재는 실시간 성의 REST API로만 하고 있는데, 비동기적인 처리나 트랜잭션 처리를 원활하게 하기 위해서는 Message Broker를 도입할 필요가 있겠습니다.
그 외에 실질적인 서비스 운영 대응에 도움을 줄 수 있는 통합 로깅이나 모니터링, 트레이싱 시스템을 구축하는 것도 한 가지 방향입니다.
앞으로 VUNO Med®의 MSA가 어느 길로 갈 지 지켜봐 주세요~
세상은 넓고 할 일은 많은데 일할 사람이 부족하네요…
뷰노 SW 개발팀은 실력 있고 도전을 즐기는 개발자를 항상 채용하고 있습니다. 최고의 동료들과 함께 의료 분야에서 인공지능으로 세상을 바꾸는 역사에 동참하고 싶은 SW 개발자의 지원을 기다립니다.
