전통적 서비스 레지스트리 패턴이란 무엇입니까?

기존 온-프레미스 환경에서 분산 애플리케이션의 자원들은 DNS와 네트워크 로드 밸런서로 관리 되었습니다. 즉, 서버, 네트워크 장비, 데이터베이스 등의 물리적 자원들을 하나의 중앙 집중적인 장소에 등록하여 관리하였고, 이를 통해 서비스를 찾거나 사용할 때 이 중앙 집중적인 장소에서만 찾아보면 되었으므로 분산 자원들을 편리하게 관리할 수 있었습니다.

전통적 서비스 레지스트리 모델의 작동 방식

일반적으로 온-프레미스 환경에서 서비스 레지스트리 모델은 DNS와 네트워크 로드밸런서로 구축되었습니다. 애플리케이션은 일반 DNS와 서비스별 경로를 사용해 서비스를 호출하고 로드 밸런서는 라우팅 테이블을 참고하여 서비스를 호스팅하는 서버의 물리적 위치를 찾고 라우팅해줍니다. 또한 경우에 따라 가용성을 위해 보조 로드 밸런서를 두었으며, 보조 로드 밸런서는 주 로드 밸런서에 핑을 보내며 주 로드 밸런서에 문제가 발생하면 주 로드 밸런서를 보조 로드 밸런서로 교체합니다.

그러나 이러한 모델 유형은 사방이 벽으로 둘러싸은 회사 데이터센터 안에서 실행되는 애플리케이션, 정적 서버 그룹에서 실행되는 소수 서비스 환경에선 잘 동작하였으나 클라우드 기반의 마이크로서비스 애플리케이션에선 아래와 같은 어려움이 있습니다.

클라우드 기반의 분산 모델에서 전통적 서비스 레지스트리 모델의 한계

1. 단일 장애 지점 (Single Point Of Failure)
   서비스 확인 계층의 로드 밸런서는 전체 인프라스트럭처에 대한 단일 장애 지점으로 작용합니다. 로드 밸런서가 다운되면 로드 밸런서에 의존하는 모든 애플리케이션이 다운되며, 로드 밸런서를 고가용하게 구축한 경우에도 애플리케이션 인프라스트럭처 안에서 집중화된 병목 지점이 될 가능성이 높습니다.

2. 수평 확장의 제약성 (limited horizontal scalability)
   기존 온-프레미스 환경의 서비스 레지스트리 모델은 로드 밸런서 클러스터에 서비스를 모아 연결하므로 부하 분산 인프라스트럭처를 여러 서버에 수평적으로 확장할 수 있는 능력이 제한됩니다. 이는 하드웨어 제약을 받는 물리적인 로드 밸런싱의 본질적인 한계로 대부분의 상용 로드 밸런서 모델들이 안고 있는 한계입니다.

3. 정적 관리 (statically managed)
   기존 온-프레미스 환경의 로드 밸런서 대부분은 중앙 집중식 데이터베이스를 사용해 경로 규칙을 저장하고 공급업체의 독점적인 API를 사용해야만 새로운 경로를 저장할 수 있었습니다. 따라서 서비스를 신속하게 등록하고 취소하는데 어려움이 있습니다.

4. 복잡성 (complex)
   기존 온-프레미스 환경에서 로드 밸런서는 서비스에 대한 프록시 역할을 하므로 서비스 소비자에게 요청할 때 물리적 서비스에 매핑된 요청 정보가 있어야 했습니다. 그리고 이 변환 계층은 서비스 매핑 규칙을 수동으로 정의하고 배포해야 하므로 복잡성은 증가하고 민첩한 확장에 어려움이 있습니다.

그러나 전통적 로드 밸런서는 SSL termination을 한 곳에서 처리, 후방의 모든 서버에 대한 인/아웃 바운드 포트 접근 제어, PCI 법규 준수 등의 이유로 중요한 요소 중 하나임을 명심할 필요가 있습니다. 다음 글은 클라우드 환경에서의 분산 서비스를 지원하기 위한 방법에 대한 설명을 이어가도록 하겠습니다.