뷰노 SW개발팀이 의료 진단 서비스를 마이크로 서비스로 전환한 첫 단계를 정리한 글이다. 기존에는 같은 VPC 안에 있으면서도 제품마다 멤버십과 크레딧 시스템이 따로라 전혀 다른 서비스처럼 동작했고, 한 병원에서 여러 제품을 쓰면 제품별로 아이디를 만들어야 했으며 개인정보도 분산돼 있었다. 안저 진단 서비스를 클라우드 방식으로 오픈하면서 멤버십과 라이선스·크레딧 관리를 통합하고 각 제품이 마이크로 서비스로 도는 구조를 새로 세웠다.
핵심 포인트- API Gateway를 앞단에 두어 인증·인가·로깅 같은 공통 로직을 각 서비스가 중복 구현하지 않게 했다
- Kong을 골랐다. 팀원이 모두 익숙한 NGINX 기반이고 대중적으로 많이 쓰이며 무료 버전이 있다는 이유였다
- 기본 제공 플러그인으로 다 될 줄 알았으나 가장 기본인 JWT 인증조차 Enterprise 전용이라 Lua를 익혀 직접 만들었다
- 라우팅만 시키는 선택지도 검토했지만 장기적으로 플러그인 자체 구현이 불가피하다고 판단했다
- SSO는 한 의사가 여러 진단 서비스를 동시에 쓸 일이 드물어 논란이 있었지만 확장성과 되돌리기 난이도를 근거로 채택했다
- 실제로 마이크로 서비스로 통합된 진단 서비스는 아직 안저 하나뿐이다
상세 정리- 판매 형태: 고객사 내부에 서버와 프로그램을 설치하는 standalone 방식과 브라우저 로그인만으로 쓰는 클라우드 방식 두 가지가 있다
- 기존 문제: 제품별 멤버십·크레딧 분리 탓에 대리점이 낀 경우 관리가 번거롭고 개인정보가 흩어져 장기 보안 관리도 어렵다고 봤다
- API Gateway 역할: 설정한 라우팅 룰에 따라 각 서비스 엔드포인트로 대신 요청하고 응답을 클라이언트에 전달하는 프록시다
- 도입 이유 셋: 공통 로직 일원화, 내부 서비스 로직 은닉을 통한 보안 강화, 각 서비스로 가는 API의 통합 관리·모니터링이다
- 검토 대상: Java 진영의 Zuul과 Spring Cloud를 접해봤으나 최종 선택은 Kong이었다
- 플러그인 개발: 코드 자체는 몇 줄이지만 처음 접하는 언어라 개발·테스트 환경 셋업에 시간이 더 걸렸다
- 현재 Kong의 기능: 요청 URL에 따른 마이크로 서비스 라우팅과 JWT 토큰 인증·인가 두 가지다
- SSO 판단 근거: 병원 관리자가 진단 결과를 함께 확인하거나 리셀러가 여러 제품을 관리할 때의 불편, 그리고 개별 로그인으로 되돌리는 편이 더 쉽다는 점이었다
- SSO 구현: JWT 환경에서 여러 방안을 검토한 끝에 확장성을 고려해 iframe을 이용하는 방식으로 만들었다
- 현재 아키텍처: 로드 밸런서가 맨 앞에 있고 통합 멤버십과 안저 서비스 URL로 오는 요청만 API Gateway로 라우팅된다
- 편입 예정: 본에이지와 체스트 엑스레이 등이 차례로 마이크로 서비스로 들어올 예정이다
- 다음 후보 1: API Gateway에 Response Caching과 Rate Limiting 같은 기능을 더해 서비스 품질을 높이는 것이다
- 다음 후보 2: 지금은 서비스 간 통신이 실시간 REST API뿐이라 비동기 처리와 트랜잭션 처리를 위해 Message Broker 도입이 필요하다
- 다음 후보 3: 운영 대응을 돕는 통합 로깅과 모니터링, 트레이싱 시스템 구축도 방향 중 하나다
왜 읽나MSA 첫 단계에서 게이트웨이 선택과 SSO 도입 여부를 어떤 근거로 갈랐는지 구체적으로 볼 수 있다.