이전 섹션까지는 마이크로서비스 간 내부 통신에 대한 문제점과 해결 방법에 대해 다루었습니다. 이번 섹션에서는 외부 트래픽이 마이크로서비스로 유입될 때 발생할 수 있는 문제점과 이를 해결하는 방법에 대해 알아보겠습니다.
마이크로서비스 네트워크에서는 외부 클라이언트가 여러 개의 서비스와 직접 통신하는 것을 허용하는 대신, 단일 진입점을 유지하는 것이 중요합니다. 여러 클라이언트가 각 마이크로서비스와 직접 통신하게 되면 다음과 같은 문제가 발생할 수 있습니다:
외부에서 들어오는 트래픽을 처리할 때 로그 기록, 감사, 추적, 보안 등 교차 기능적 문제를 처리해야 합니다. 이를 각 마이크로서비스에 개별적으로 구현하면 다음과 같은 문제가 발생할 수 있습니다:
동적 라우팅은 특정 요청이 들어왔을 때 그 요청을 특정 서비스로 라우팅하는 기능을 의미합니다. 예를 들어:
이와 같은 기능을 지원하지 않는다면, 외부 요청을 적절히 처리하고 분배하는 데 어려움이 있을 수 있습니다.
이러한 문제를 해결하기 위한 방법으로 엣지 서버(Edge Server) 또는 API 게이트웨이(API Gateway)를 사용할 수 있습니다. 엣지 서버는 마이크로서비스 네트워크의 가장자리에 위치하여 다음과 같은 역할을 수행합니다:
엣지 서버는 마이크로서비스 네트워크의 게이트키퍼 역할을 하며, 모든 트래픽을 관리하고 보안을 유지하는 중요한 역할을 합니다.
그렇다면 왜 엣지 서버(API Gateway)를 별도로 유지해야 하는지, 그리고 이를 어떻게 구현할 수 있는지에 대해 더 깊이 다루겠습니다.
먼저, 엣지 서버 없이 마이크로서비스를 운영한다고 가정해 보겠습니다. 아래와 같은 상황에서 발생할 수 있는 문제점을 살펴보겠습니다:
중복된 로직: 보안, 로깅, 감사, 라우팅 등의 교차 기능적 요구 사항을 모든 마이크로서비스에 각각 구현해야 합니다. 이는 코드 중복과 유지보수의 어려움을 초래할 수 있습니다.
일관성 부족: 여러 개발자가 다양한 마이크로서비스에 교차 기능적 로직을 구현하는 경우, 표준을 따르지 않거나 일관성이 없는 구현이 발생할 수 있습니다. 이는 보안 및 로깅 정책 등의 비일관성을 초래할 수 있습니다.
공유 라이브러리의 문제점: 교차 기능적 로직을 공통 라이브러리로 구현하고 이를 모든 마이크로서비스에 의존하게 할 경우, 라이브러리와 서비스 간의 강한 결합이 발생합니다. 이후 보안 또는 로깅과 같은 로직을 변경해야 하는 경우, 모든 마이크로서비스에 대한 회귀 테스트와 영향 분석이 필요합니다. 이는 많은 마이크로서비스를 가진 조직에서는 비효율적일 수 있습니다.
이러한 문제를 해결하기 위해 엣지 서버(API 게이트웨이)를 도입하는 것이 현명한 선택입니다. 엣지 서버는 다음과 같은 이점을 제공합니다:
엣지 서버(API 게이트웨이)는 다음과 같은 추가 기능을 제공합니다:
이 모든 기능을 통해 엣지 서버는 마이크로서비스 네트워크의 게이트키퍼 역할을 하며, 안정성과 보안을 유지합니다.
Eureka 서버는 주로 서비스 디스커버리와 서비스 등록을 위한 역할에 중점을 두고 있으며, API 게이트웨이에서 제공하는 다양한 기능을 수행할 수 없습니다. 따라서, API 게이트웨이와 Eureka 서버를 결합하여 사용하는 것이 더 많은 유연성과 기능을 제공합니다.
API 게이트웨이를 도입하면 마이크로서비스 네트워크의 보안, 관리, 성능 등을 효율적으로 개선할 수 있습니다.