본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 네번째 날입니다.
세번째 날에는 트레이드 오프에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 1.프로젝트 개요와 목표 > 04. 대용량 트래픽 대응에 필요한 선택
입니다.
- 어제는 트레이드 오프가 무엇인가에 대해 배웠었는데, 오늘은 이번 강좌의 핵심(채팅 서비스를 제외한)이라고도 볼 수 있는 대용량 트래픽 대응에 필요한 선택에 대한 지식을 습득할 수 있었던 시간이었던 것 같습니다.
- 모든 서비스마다 운영 기준이 다를 수 있고, 대용량 트래픽에 대한 명확한 정의는 상황에 따라 달라질 것. 다만, 일반적으로 서버 한 대로는 물리적인 한계가 존재하기 때문에 대용량 트래픽 대응은 이 한계를 극복하기 위한 구조를 설계하는데에서 시작하는 것.
- 이전 강의에서 Monolithic 아키텍처에 대한 이야기를 했을 때 언급했듯이, 모든 서비스가 하나의 인스턴스로 실행되고, 보통 하나의 서버가 담당함. 수직 확장이 가능하지만 CPU와 메모리 등 한 대의 하드웨어 성능을 올리는 것은 물리적인 한계가 존재함.
- 이 한계에 도달할 때 즈음 데이터베이스의 억제를 구성하면서 안정성을 확보하고 읽기와 쓰기 트래픽을 분리하면서 내부 인프라에서 성능 개선을 시작함.
- 그리고 데이터베이스의 캐시 레이어를 구성하면서 추가적인 성능 개선을 진행함. 그러다가 Monolithic 구조에서 더 이상 성능을 올리기 어려운 상황에 도달함.
- 이제 몇몇 서비스를 물리적으로 다른 서버가 실행해야 할 필요가 생기면 일부 서비스를 별도의 인스턴스로 분리하고, 여러 서버가 나눠서 담당함. 이렇게 서비스가 돌게 되면 성능과 더불어 안정성도 향상됨. 물론 앞에서 증설했던 내부 인프라도 유지하면서 이전에 확보했던 안정성과 성능을 유지함.
- 하지만 아직 Connection Service 와 Main Business 의 채팅을 분리하지 못한 상태임. 이 상태에서는 한 대의 서버가 받아줄 수 있는 Connection 의 한계를 넘기기 어려움.
- Connection Service 와 Message Service 를 물리적으로 분리해야 개별적으로 스케일 아웃이 가능한 구조가 됨. 이제 모든 서비스는 분리되었음. 또한, 확장된 시스템에 맞추어서 인프라도 같이 확장되면서 단일 장애 지점도 사라지게 됨.
- 이렇게 각 단계마다 한계가 존재하고, 그 한계를 해결하기 위해서 다양한 고민을 하고 적합하다고 생각하는 선택을 하면서 시스템 구조를 확장함.
- 이전에는 프록시도 하나였지만, 2개로 여러 대를 증설할 수 있음. 하지만 클라이언트가 알아야 하는 엔드포인트가 이제 하나가 아니라 여러 개가 되면서 문제가 생김.
- 이를 해결하기 위해서 서비스 디스커버리를 도입했음. 단일 로드에서 장애에 취약하던 캐시는 클러스터링을 했고, 데이터베이스도 샤딩으로 확장했음. 서비스 간의 의존성을 분리하고, 스케일 아웃이 용이하도록 데이터 String 을 위해서 Kafka 를 도입했음.
- 이번 강의는 이렇게 단계 별로 시스템 확장이 왜 필요하고 어떻게 확장할지, 확장하기 위해서 필요한 인프라 기술 스택을 하나씩 더해가면서 점진적으로 기존의 코드가 어떻게 변해가는지, 그리고 하나의 큰 시스템을 구성하는 과정을 공부할 수 있도록 준비할 수 있도록 시야를 넓힐 수 있었던 것 같아서 좋았던 것 같습니다.
