pile·
아키텍처·뷰노뷰노·

MSA로의 첫걸음

뷰노 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 도입 여부를 어떤 근거로 갈랐는지 구체적으로 볼 수 있다.
뷰노
뷰노 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 아키텍처·aws-architectureAWS Architecture·

    일관성이 새로운 지연이다: 데이터 레이어에서의 AI

    AI 에이전트가 데이터베이스 레이어에서 겪는 데이터 정합성 문제를 다룬다. 비동기 복제 지연(replication lag)으로 stale 데이터를 읽은 에이전트가 잘못된 판단을 내리는 "조용한 독"을 AWS 서비스 기반 세 가지 아키텍처 패턴으로 해결하는 방법을 제시한다. "빠르지만 틀린 답이 약간 느리지만 맞는 답보다 비싸다"는 주장 아래, 데이터베이스 아키텍처를 AI 신뢰성의 기반으로 재정의한다.

    요약 이어보기
    #ai-agent#data-consistency#aurora+2
  2. 아키텍처·flexflex·

    사람도 에이전트도, 덜 읽을수록 더 잘 고칩니다

    flex 팀이 코드베이스의 모듈 경계 설계가 AI 에이전트의 코드 탐색 효율에 미치는 영향을 실측한 글이다. 193개 에이전트 작업 로그를 분석하고, 잘 나뉜 모듈과 뭉친 모듈을 비교한 결과 — 도메인이 물리 모듈로 분리된 저장소에서 에이전트가 불필요한 파일을 덜 읽고 목표 코드에 더 집중했다. 사람도 에이전트도 컨텍스트 한도가 있어, 무관 코드를 덜 읽을수록 수리 성공률이 높다는 것이 핵심 결론이다.

    요약 이어보기
    #llm-agent#context-window#modular-architecture+1
  3. 아키텍처·aws-architectureAWS Architecture·

    데이터 거주 요건을 충족하는 재해 복구 전략

    데이터 거주(data residency) 규정을 지키면서 재해 복구(DR)를 구현해야 하는 조직을 위해 AWS가 세 가지 전략 프레임워크를 제시한다. 금융, 의료, 공공 부문처럼 지리적 데이터 보관 의무가 있는 환경에서도 복구 목표(RTO/RPO)를 달성할 수 있는 아키텍처 선택지를 비교한다.

    요약 이어보기
    #multi-cloud#compliance#disaster-recovery+2