🎱 챗봇 아키텍처에 대해 알아보자 ~

🖤 Intro

이제 챗봇 개발이 거의 마무리 단계에 접어들었으므로….내가 짠 아키텍처에 대해서 알아보고자 한다. 겸사겸사 로직 이상한 부분 있으면 좀 고치기도 하고,

일단은 부트 서버 백엔드 로직을 살펴보기 전에, 내가 짠 우리팀 서버 아키텍처에 대해 알아보도록 하자!

🩶 Start

서버 아키텍처 소개하기~

이번 프로젝트를 진행하면서 개인적으로 가장 많이 신경썼던 부분이기도 하다.

서버간의 책임 영역을 명확히 하고, 서버를 stateless하게 유지하도록 하기 위해 온갖 노력을 다 들였던것도 결국 클린~한 아키텍처를 유지하도록 하기 위함이 컸다.

우선 현재 우리 프로젝트의 서버 아키텍처를 살펴보자.

이중 내가 맡았던 부분은 Recodash의 [챗봇] 파트이다.

우선 서버가 두 개로 나눠져있기에..어떤 도메인이 어떤 서버 파트에서 무슨 일을 수행하는지를 명확히 해야만 했다. 단순한 기술 나열식 아키텍처는 솔직히 아키텍처적으로 의미가 없다고 생각하기에…

메인 도메인 (우리 팀 단위이기도 하다.)인 Shorts & Recodash (DATA) & Pay로 나눠서 구성하였으며, Data Server의 경우 Recodash 팀만이 사용하기에 다음과 같이 분리해서 구성하였다.

Redis역시, Recodash 팀의 나만 사용하므로 화살표를 명확하게 연결해두었으며, DB와 Server를 명확히 구분해두었다.

또한, EC2가 아닌 강사님 서버에 우리 프로젝트를 띄워야 하기에 Docker로 컨테이너링을 해두었다. (사실 이 부분은 차후 바뀔 수도 있을 것 같다..)

마지막으로 Auth의 경우는 인증 / 인가 섹션을 분리해두었고, Auth의 경우 모든 도메인이 공용으로 사용하는 부분이기에 별도의 도메인으로 분리해두었다.

이를 통해 비즈니스 로직들과 기술 로직을 명확히 분리해두었다.

여기서 더 발전할 수는 없을까?

내가 아쉬움을 느꼈던 부분은 이것이다.

지금 우리 팀의 경우는 로드밸런싱 & CI/CD 자동 배포 등을 하지 않을 계획이라고 해서…이 부분에 대한 파트가 빠져있는게 상당히 큰 아쉬움으로 남았다.

그래서 이 파트들을 추가한 예시 아키텍처로 우리 아키텍처를 한 단계 발전? 시켜보고자 한다.

로드밸런싱이 뭔데?

그전에 추가할 요소들에 대한 간략한 개념을 알아보자.

먼저 로드밸런싱부터…

로드밸런싱이란? 들어오는 네트워크 트래픽을 여러 서버에 분산시켜 단일 서버의 부하를 줄이고, 시스템 전체의 성능과 가용성을 향상시키는 기술을 의미한다.

핵심 목표는 다음과 같다.

1. 부하 분산

• 한 서버에 모든 요청이 몰리는 것을 방지한다.

• 각 서버가 적절한 양의 작업을 처리하도록 분배한다.

2. 고가용성

• 한 서버가 다운 되어도 서비스 중단이 없도록 한다.

• 24/7 서비스 운영이 가능하다. 즉, 연중무휴로 서비스가 중단되지 않는다.

3. 확장성

• 트래픽 증가시 새로운 서버만 추가하면 된다. 로드밸런서가 추가된 서버로 알아서 트래픽 분산을 해주기 때문이다.

• 수평적 확장이 용이하다. 즉, 서버 개수만 추가하면 되는 것이다.

MSA에서의 동작 원리

API Gateway → Load Balancer → Auth Service (3대)
             → Load Balancer → User Service (2대)  
             → Load Balancer → Payment Service (4대)

이런식으로, 각 서비스 마다 독립적인 로드 밸런서 구성으로 서비스 확장이 용이해지고, 장애 격리가 가능해지고, 결과적으로 성능 최적화를 할 수 있는 것이다.

그럼 우리 서비스에서 로드밸런싱을 도입해서 얻는 이점은 뭐지?

1. 동시 사용자 처리 능력이 향상된다.

현재 구조에서는, 사용자 100명이 동시 채팅을 진행할 경우 응답 속도가 저하되지만, 로드밸런싱으로 서버를 분산한다면, 각 서버에 요청이 분산되어 빠른 응답이 가능해진다.

2. LLM API 호출 부하 분산

현재는 FAST API 서버 1대가 모든 LLM 요청을 처리한다. 즉, LLM API 응답 대기 시간동안 다른 사용자가 대기하게 되는데, 이를 여러대로 분산하면 전체적인 챗봇 응답 속도를 개선할 수 있다.

3. Redis 연결 부하 분산

현재는 Spring Boot 서버 1대가 모든 Redis 캐싱을 담당하는 구조인데, 로드밸런싱을 하게 되면 여러대의 서버가 Redis 부하를 분산하기 때문에 챗 플로우 관리가 더 안정적이게 된다.

이 외에도, 특히 금융 서비스의 경우는 장애 격리가 매우 중요한데 로드밸런싱을 이용하면 단일 서버 해킹시에도 다른 서버들이 정상 운영되어 트래픽 분산으로 해킹 공격 완화 효과도 있다고 한다.

그럼 CI/CD 자동 배포는 뭔데?

CI (Continuous Integration) : 지속적 통합

• 개발자들이 작성한 코드를 자동으로 통합하고 테스트하는 과정

CD (Continuous Deployment/Delivery) : 지속적 배포

• 테스트를 통과한 코드를 자동으로 운영 서버에 배포하는 과정

즉, 손으로 직접 배포를 할 필요가 없이, 코드를 작성하고 반영하는 것 만으로 자동으로 서비스 재시작이 되는 것을 의미한다. 즉, 자동 빌드 & 자동 배포를 말한다.

내가 github 블로그에 글을 수정해서 올리면 자동으로 서버에 배포되는 것 역시 github action이 CI/CD를 해주고 있기 때문이다.

아키텍처 리팩터링

말했던 요소를 추가해서 다음과 같이 아키텍처를 리팩터링 하였다! (참고로 내가 개발 맡은건 색칠도 해줌)

CI/CD 같은 경우는 Repo 단위로 연결되기에, 다음과 같이 연결해주었다.

완전히 독립된 도메인으로 구성된 구조가 아니라서 좀 아쉽긴 하다….다음에는 이번 프로젝트에서 배운 지식을 바탕으로 꼭 MSA에 도전해보겠다!!!!!