본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 서른 네번째 날입니다.
서른 세번째 날에는 양방향 카프카 연동을 위한 구조 설명에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 5. 모놀리틱 서비스 분해 > Ch 3. 책임 분리로 진행하는 모놀리틱 서비스 분해와 양방향 카프카 연동 >
01. 왜 Nginx 다중 인스턴스와 서비스 디스커버리가 필요한가
입니다.
🛡 SPOF 제거: 엔진엑스 다중 인스턴스와 서비스 디스커버리
- 이번 파트5 마지막 챕터에서는 싱글 포인트 오브 페일러(SPOF)를 제거하는 방법을 다룹니다.
특히, 엔진엑스를 다중 인스턴스로 구성하고, 서비스 디스커버리 솔루션인 Consul을 연동해 동적으로 서버를 관리하는 방식을 소개합니다.
🚨 현재 구조의 문제: 클라이언트 재배포
- 현재 채팅 프로젝트의 구조에서 엔진엑스는 리버스 프록시 역할을 하며 서버 뒤쪽의 IP를 감춰줍니다.
하지만 문제는 엔진엑스를 스케일 아웃하면 클라이언트 재배포가 필요하다는 점입니다. - 왜냐하면,
- 클라이언트는 엔진엑스의 IP를 직접 알고 접속
- 엔진엑스 인스턴스가 늘어나면 새로운 IP를 알아야 함
- 앱에는 동적 업데이트 기능이 없으므로 재배포 필수
💡 일반적인 해결책
- 실제 서비스에서는 보통 엔진엑스 앞단에 로드밸런서(LB)를 둡니다.
- LB는 물리 장비일 수도 있고, 클라우드 LB일 수도 있음
- 클라이언트는 LB의 주소만 알고, 뒤쪽 엔진엑스는 자유롭게 증설/축소 가능
- LB 주소는 보통 DNS를 통해 제공되어 IP 변경 시에도 클라이언트 영향 없음
- 추가로 VIP(Virtual IP)를 사용해 마스터 노드 변경 시에도 동일한 IP를 유지하는 네트워크 구성도 있습니다.
🎯 우리의 접근: Consul 기반 서비스 디스커버리
- 이번 프로젝트에서는 추가 LB 구성 없이 서비스 디스커버리를 도입해 문제를 해결합니다.
- Consul을 통해 정상 서비스 중인 엔진엑스 목록을 동적으로 가져오고, 클라이언트가 직접 조회하여 접속 대상을 선택하게 합니다.
- 동작 방식
- Consul 클러스터를 3대로 구성 (확장 가능)
- 클라이언트는 접속 시 먼저 Consul에 엔진엑스 목록 요청
- 응답받은 리스트 중 하나에 접속 시도
- 실패 시 다른 노드로 재시도
- 엔진엑스 인스턴스 증설/축소 시 자동 반영
📈 장점
- 클라이언트 재배포 불필요
엔진엑스 IP 변화에도 클라이언트는 Consul만 참조 - 무중단 확장/축소
엔진엑스 노드 수를 자유롭게 조정 가능 - 구현 복잡도 최소화
DNS, LB, VIP 등 네트워크 레벨 구성 없이 서비스 디스커버리로 해결
⚙️ 구현 계획
- 엔진엑스 2대 구성 후 Consul에 등록
- Consul 조회 API를 통해 클라이언트가 동적 접속
- 예제 프로젝트에 먼저 적용 후 채팅 프로젝트에 확장
📝 추가 활용 가능성
- Consul은 단순 서비스 디스커버리뿐 아니라 Key-Value 저장소 기능도 제공합니다.
- 이를 활용하면 서버 설정(YAML 등)을 중앙 집중화해 동적으로 변경할 수 있습니다.
- 이번 구현에서는 사용하지 않지만, 추후 서비스 확장 시 매우 유용하게 쓸 수 있습니다.
- 이번 구조 설계에서 가장 중요한 포인트는 "의존성 제거" 입니다. 클라이언트가 엔진엑스의 고정 IP에 의존하는 순간, 스케일 아웃은 곧 재배포를 의미하게 됩니다. Consul을 도입함으로써 이 의존성을 끊고, 서비스 운영의 유연성을 크게 높일 수 있습니다.
- 또한, 이 방식은 단순 채팅 서버뿐 아니라 마이크로서비스 아키텍처 전반에 적용 가능합니다. 서버 목록을 중앙에서 관리하고, 서비스 인스턴스를 동적으로 증감시키는 구조는 향후 트래픽 급증이나 장애 대응 속도에 큰 차이를 만듭니다.
