마이크로서비스 아키텍처 내 네트워크 통신을 위한 방법

이번 강의에서는 마이크로서비스 아키텍처에서 서비스 디스커버리(Service Discovery), 서비스 등록(Service Registration), 로드 밸런싱(Load Balancing)이라는 새로운 도전 과제를 소개했습니다. 이 과제들은 마이크로서비스 네트워크 내에서의 동적인 환경을 다루기 위한 핵심적인 개념들입니다. 이제 이러한 개념들과 관련된 질문들을 통해 문제의 본질을 이해하고, 왜 이러한 개념들이 중요한지 자세히 알아보겠습니다.

1. 마이크로서비스 간의 연결 문제

• 문제: 마이크로서비스 네트워크 내에서 한 마이크로서비스가 다른 마이크로서비스를 어떻게 찾아서 연결할 수 있을까?
• 전통적 접근: 각 마이크로서비스는 고유의 엔드포인트와 포트 번호를 가지고 있으며, 이를 통해 서로 연결할 수 있을 것입니다.
• 문제점: 마이크로서비스 환경에서는 컨테이너가 동적으로 생성되고 제거되기 때문에 엔드포인트나 IP 주소가 자주 변경됩니다. 이는 각 마이크로서비스가 다른 마이크로서비스의 위치를 추적하는 것을 어렵게 만듭니다.

2. 새로운 서비스 인스턴스의 등록

• 문제: 새로운 마이크로서비스 인스턴스가 마이크로서비스 네트워크에 진입하려면 어떻게 해야 할까?
• 상황: 예를 들어, 초기에는 각 마이크로서비스가 하나의 인스턴스만 가졌지만, 나중에 트래픽 증가로 인해 인스턴스를 5개로 늘릴 수 있습니다. 이 때, 새로운 인스턴스들은 네트워크에 어떻게 등록되고, 다른 마이크로서비스들은 이 새로운 인스턴스들의 존재를 어떻게 알 수 있을까요?
• 문제점: 만약 새로운 인스턴스가 다른 마이크로서비스들에게 자신의 존재를 알리지 못한다면, 해당 인스턴스는 호출되지 않을 것이고, 스케일링의 효과가 사라집니다.

3. 로드 밸런싱

• 문제: 여러 인스턴스가 동시에 실행되고 있을 때, 트래픽을 어떻게 효율적으로 분배할 것인가?
• 상황: 예를 들어, accounts 마이크로서비스가 loans 마이크로서비스에 요청을 보내야 할 때, loans 마이크로서비스의 여러 인스턴스 중 어느 것을 호출할지 결정해야 합니다.
• 문제점: 모든 요청이 특정 인스턴스에만 집중되어 과부하가 걸리고, 나머지 인스턴스는 유휴 상태가 되는 문제를 방지해야 합니다.

4. 해결책: 서비스 디스커버리, 서비스 등록, 로드 밸런싱

• 서비스 디스커버리: 마이크로서비스가 동적으로 생성된 다른 마이크로서비스를 자동으로 발견하고 연결할 수 있도록 도와주는 메커니즘입니다.
• 서비스 등록: 새로운 마이크로서비스 인스턴스가 네트워크에 진입할 때, 자신을 등록하고 다른 서비스에 알릴 수 있도록 하는 프로세스입니다.
• 로드 밸런싱: 여러 인스턴스 간의 트래픽을 효율적으로 분배하여 특정 인스턴스에 과부하가 걸리는 것을 방지하는 메커니즘입니다.

이로써 우리는 마이크로서비스 네트워크 내에서 발생할 수 있는 복잡한 문제들을 이해하고, 이를 해결하기 위한 중요한 패턴들과 개념들을 다루게 됩니다. 이러한 개념들은 마이크로서비스 아키텍처의 안정성과 확장성을 보장하는 데 필수적입니다.

전통적인 방법을 마이크로서비스 환경에 적용할 때의 문제점

서비스 디스커버리(Service Discovery)와 서비스 등록(Service Registration) 개념이 없는 상태에서 전통적인 접근 방식을 마이크로서비스 환경에 적용할 때 발생할 수 있는 문제점들을 설명하고자 합니다. 이를 통해 왜 이러한 전통적인 접근 방식이 마이크로서비스 아키텍처에서 적합하지 않은지를 이해할 수 있습니다.

1. 마이크로서비스 간의 통신 문제

• 상황: 두 개의 마이크로서비스, 예를 들어 accounts와 loans가 서로 통신해야 하는 상황을 가정합니다.
• 전통적 접근: accounts 서비스가 loans 서비스와 통신하기 위해서는 loans 서비스의 IP 주소나 DNS(Domain Name System) 이름이 필요합니다.
• 문제점: 전통적인 방식에서는 accounts 서비스 코드에 loans 서비스의 IP 주소를 하드코딩하거나 DNS 이름을 직접 명시하는 방식으로 통신이 이루어집니다. 이는 작은 규모의 모놀리식(monolithic) 애플리케이션에서는 문제가 없을 수 있지만, 마이크로서비스 환경에서는 각 서비스의 컨테이너가 동적으로 생성되거나 삭제되므로 IP 주소가 자주 변경됩니다. 이러한 변경을 추적하고 관리하는 것은 매우 어렵습니다.

2. DNS 사용의 한계

• DNS: IP 주소 대신 DNS 이름을 사용하면, IP 주소가 변경되더라도 DNS 이름만으로 서비스 간 통신을 유지할 수 있습니다. 플랫폼 팀이나 운영 팀이 DNS와 IP 주소 간의 매핑을 관리합니다.
• 문제점: 클라우드 환경에서는 서비스 인스턴스가 동적으로 확장되거나 축소되며, 각각의 인스턴스는 고유한 IP 주소를 갖게 됩니다. 이로 인해 DNS 레코드를 최신 상태로 유지하는 것이 매우 어렵습니다. 또한, DNS 레코드가 실시간으로 업데이트되지 않으면 서비스 간 통신에 문제가 발생할 수 있습니다.

3. 로드 밸런싱 문제

• 로드 밸런싱: 여러 서비스 인스턴스 간에 트래픽을 효율적으로 분산해야 하는 상황입니다. 예를 들어, accounts 서비스가 loans 서비스에 요청을 보내야 할 때, loans 서비스의 여러 인스턴스 중 어떤 인스턴스를 호출할지 결정해야 합니다.
• 전통적 로드 밸런서: 전통적인 로드 밸런서는 주로 정적인 IP 주소와 서버 환경을 대상으로 설계되었기 때문에, 클라우드 기반의 동적인 마이크로서비스 환경에서는 적합하지 않습니다. IP 주소가 계속해서 변경되는 마이크로서비스 환경에서는 로드 밸런서의 라우팅 테이블을 유지하는 것이 매우 어렵고 비효율적입니다.

4. 전통적인 로드 밸런서의 단점

• 제한된 수평 확장성 및 라이선스 비용:

  • 전통적인 로드 밸런서는 IP 주소를 사전에 알고 있어야 하며, 라우팅 테이블에 이를 수동으로 설정해야 합니다. 이는 자동 확장(Scale up) 및 축소(Scale down)가 빈번히 일어나는 마이크로서비스 환경에서는 비효율적입니다.
  • 또한, 전통적인 로드 밸런서는 클라우드 제공업체로부터 라이선스 비용을 지불해야 하므로 비용적인 부담도 존재합니다.

• 단일 장애점(Single Point of Failure):

  • 하나의 로드 밸런서가 실패하면 백업 로드 밸런서가 그 역할을 대신할 수 있지만, 두 로드 밸런서 모두 실패하는 경우 전체 시스템이 중단될 위험이 있습니다. 이는 로드 밸런서를 클러스터링하여 확장하기 어렵기 때문에 발생하는 문제입니다.

• 수동 관리의 어려움:

  • 전통적인 로드 밸런서는 IP 주소 구성과 라우팅 테이블을 수동으로 관리해야 하는데, 이는 마이크로서비스 환경에서 실질적으로 불가능합니다. 마이크로서비스는 컨테이너로 구성되며, 이 컨테이너들은 짧은 수명을 가지며 빠르게 생성되고 소멸합니다.

• 컨테이너 친화적이지 않음:

  • 전통적인 로드 밸런서는 컨테이너 기반의 동적인 환경에 적합하지 않습니다. 컨테이너는 언제든지 생성되고 삭제될 수 있기 때문에, 전통적인 로드 밸런서는 이러한 변화에 적응하기 어렵습니다.

요약하자면

• 전통적인 방법의 한계: 전통적인 로드 밸런서는 마이크로서비스의 동적인 특성에 적합하지 않으며, IP 주소를 수동으로 관리해야 하는 어려움이 있습니다. 이러한 방식으로는 마이크로서비스의 빠르고 유연한 확장성을 지원할 수 없습니다.
• 다음 단계: 이러한 문제를 해결하기 위해서는 서비스 디스커버리, 서비스 등록, 그리고 클라우드 네이티브 환경에 적합한 새로운 방식의 로드 밸런싱이 필요합니다. 이제 이러한 문제들을 해결할 수 있는 방법에 대해 자세히 알아볼 것입니다.

우리는 전통적인 접근 방식이 마이크로서비스 환경에서 적합하지 않은 이유를 이해했고, 다음 단계에서는 이러한 문제를 해결할 수 있는 현대적인 방법에 대해 다루게 될 것입니다.