MSA 아키텍쳐를 적용한 Spring Boot 프로젝트를 진행하던 중,
SpringCloud를 활용한 API Gateway를 구현 했는데 이때, 라우팅 할 마이크로 서비스들을 직접 지정했습니다.
많은 수의 마이크로 서비스를 직접 지정하다가 이게 맞나.. 싶어 동적으로 라우팅을 하는 방법을 찾아보았습니다.
그렇게 서비스 디스커버리에 대해 조사하게 되었습니다.
1. 동적 서비스 위치
서비스 인스턴스의 위치가 변경되거나 새 인스턴스가 추가되어도 서비스 디스커버리를 통해 실시간으로 찾을 수 있습니다. 이를 통해 서비스 간의 결합도를 낮추고, 확장성을 높이는데 도움이 됩니다.
2. 로드 밸런싱
서비스 디스커버리를 사용하면, 여러 인스턴스 중에서 하나를 선택하는데 사용할 수 있는 로드 밸런싱 기능을 제공합니다. 이를 통해 트래픽을 여러 서비스 인스턴스에 분산시킬 수 있어 성능과 안정성을 향상시킵니다.
3. 장애 감지 및 복구
서비스 디스커버리는 주기적으로 서비스 인스턴스의 상태를 검사하여 실패한 인스턴스를 감지하고, 정상 작동하는 인스턴스로 요청을 전달합니다. 이를 통해 높은 가용성을 유지할 수 있습니다.
이때 생긴 궁금증은 다음과 같습니다.
서비스 디스커버리를 사용하게 되면, 마이크로서비스 간의 통신 과정에서 API Gateway를 거쳐서 통신하는걸까?
직접 통신하는것보다 비효율적이지는 않을까?
- 서비스 디스커버리를 사용하면, 마이크로서비스 간의 통신이 API 게이트웨이를 거치지 않고 직접 통신할 수 있습니다.
- 서비스 디스커버리는 서비스 인스턴스의 위치를 식별하는 데 사용되는데, 이를 통해 마이크로서비스는 다른 서비스의 현재 위치를 쉽게 찾을 수 있습니다.
- 서비스 디스커버리를 사용하지 않고 API 게이트웨이를 거쳐 통신하는 것이 비효율적일 수 있지만, 다음과 같은 이유로 API 게이트웨이를 사용하는 것이 유용할 수 있습니다.
다음은 API 게이트웨이가 유용할 수 있는 경우입니다.
- API 게이트웨이는 클라이언트와 마이크로서비스 사이에 중앙 집중식 진입점을 제공합니다. 이를 통해 보안, 인증, 인가 등과 같은 공통 기능을 한 곳에서 관리할 수 있습니다.
- API 게이트웨이는 마이크로서비스의 경로나 인터페이스가 변경되더라도 클라이언트에 영향을 주지 않도록 중간에서 요청을 처리하고 라우팅할 수 있습니다.
- API 게이트웨이를 통해 트래픽을 관리하고, 요청의 로드 밸런싱을 수행하며, 서비스 장애 시 대체 서비스로 빠르게 전환할 수 있습니다.
즉, 사용 사례에 따라 직접 통신과 API 게이트웨이를 거치는 통신 간의 효율성이 달라질 수 있습니다.
API 게이트웨이에서 서비스 디스커버리를 사용하는 경우에도, 게이트웨이는 클라이언트와 마이크로서비스 사이의 중앙 집중식 진입점 역할을 합니다. 하지만, 서비스 디스커버리를 사용하면 API 게이트웨이가 동적으로 마이크로서비스의 위치를 파악하여 라우팅을 처리할 수 있습니다.
이를 통해, 마이크로서비스 인스턴스가 추가되거나 삭제될 때, 게이트웨이가 이러한 변화를 자동으로 인식하고 올바른 인스턴스로 요청을 라우팅할 수 있습니다. 따라서 서비스 디스커버리를 사용하면 게이트웨이를 통한 요청 처리와 라우팅이 더 효율적으로 수행됩니다.
서비스 디스커버리를 사용하더라도, API 게이트웨이가 클라이언트 요청을 받아 마이크로서비스로 전달하는 구조는 변하지 않습니다. 서비스 디스커버리의 목적은 게이트웨이가 마이크로서비스의 현재 위치를 쉽게 파악하고 요청을 라우팅하는 데 도움을 주는 것입니다.
예시)
마이크로서비스 A와 B가 있다고 가정하겠습니다.
이 두 서비스는 각각 다양한 기능을 제공하며, 클라이언트 요청을 처리합니다.
서비스 디스커버리를 사용하지 않는 경우
API 게이트웨이는 서비스 A와 B의 정적인 위치 정보(예: IP 주소, 포트 번호)를 미리 알고 있어야 합니다.
이 경우, 서비스 A 또는 B의 인스턴스가 증가하거나 줄어들 때, 또는 위치 정보가 변경되면 수동으로 게이트웨이의 설정을 업데이트해야 합니다. 이 과정은 시간이 오래 걸리고 오류가 발생하기 쉽습니다.
서비스 디스커버리를 사용하는 경우
서비스 A와 B는 서비스 디스커버리 시스템에 자신의 위치 정보를 등록합니다.
API 게이트웨이는 서비스 디스커버리 시스템을 통해 동적으로 이 위치 정보를 얻어 올 수 있습니다. 따라서 서비스 A 또는 B의 인스턴스가 증가하거나 줄어들거나 위치 정보가 변경되어도, 게이트웨이는 이러한 변경 사항을 자동으로 인식하고 라우팅을 적절히 처리할 수 있습니다.
결론
서비스 디스커버리를 사용함으로써 얻는 이점은 다음과 같습니다.
- 마이크로서비스 인스턴스의 추가, 제거, 변경을 쉽게 처리할 수 있습니다.
- 수동으로 설정을 업데이트할 필요가 없어 관리가 간편해집니다.
- 마이크로서비스의 위치 정보가 변경되어도 자동으로 반영되므로 더 나은 장애 조치와 확장성을 제공합니다.
이러한 이유로, 서비스 디스커버리를 사용하는 것이 효율적이며, 마이크로서비스 아키텍처에서 권장되는 방식입니다.
'Infra' 카테고리의 다른 글
[Jenkins] Pipeline Kubernetes "process apparently never started in ..." 오류 해결 방법 (0) | 2023.05.08 |
---|---|
[Ansible] 간단 개념 정리 (0) | 2023.04.25 |
[쿠버네티스] Spring Cloud, Docker, MSA 프로젝트에 쿠버네티스를 어떻게 적용할까? (0) | 2023.03.23 |
[AWS RDS] too many connections 에러 해결 방법 (0) | 2023.02.20 |