Page 13 -

그림 1-2 마이크로서비스 아키텍처의 구성 예시
웹 접속 APP 접속 서드파티
NoSQL
1
서비스
API 게이트웨이
디스커버리

이벤트 뉴스 서비스 카페 서비스 웹툰 서비스 외부 새로운 인프라 환경이 온다
결제 서비스
REST REST REST 금융기관

버스
분석 서비스
뉴스 크롤러 카페 서비스 웹툰 보안
스파크 인증 서비스

NoSQL RDB 스토리지
하둡 RDB

하나의 애플리케이션 안에 포함돼 있던 뉴스, 블로그, 웹툰 서비스가 각 서비스와 관련된 기능
과 데이터베이스를 독립적으로 가지는 구조로 표현됐습니다. 각 서비스는 API 게이트웨이와

REST(REpresentational State Transfer) API를 이용한 통신 방식으로 사용자(외부)의 요청을 전달합
니다. 서비스 개수는 고정된 것이 아니기 때문에 어떤 서비스가 등록돼 있는지 파악하기 위해 서
비스 디스커버리를 사용합니다. 또한 수많은 서비스의 내부 통신을 이벤트로 일원화하고 이를 효
과적으로 관리하기 위해 별도로 이벤트 버스를 서비스로 구성합니다.

이런 구조 덕분에 각 서비스는 필요한 기능이 특화된 데이터베이스를 선택해 개별 서비스에 할당
할 수 있습니다. 고객의 요구 사항에 따라 분석 서비스를 새로 추가해야 할 때도 기존에 있는 이벤

트 버스에 바로 연결하면 되므로 매우 유연하게 대응할 수 있습니다. 각 서비스는 독립적으로 동
작할 수 있는 완결된 구조라서 이미 개발된 기능이 다른 서비스에 필요하다면 바로 재사용할 수
있습니다.

1.1.3 컨테이너 인프라 환경에 적합한 아키텍처

그러면 컨테이너 인프라 환경에서는 어떤 아키텍처를 사용해야 좋을까요? IT 세계에서는 대부분 정

해진 답이 없습니다. 주어진 상황에 적합한 기술이 있을 뿐입니다. 모놀리식 아키텍처로 구현을 시
작했지만, 시스템이 성장하고 기능이 늘어나면 마이크로서비스 아키텍처로 전환할 수도 있습니다.

23

인프라_06.indd 23 2021-05-31 오후 3:46:57