상세 내용

1. 개요
   • 도담도담은 500명 이상의 사용자를 보유한 교내 스마트 스쿨 플랫폼입니다. 수기로 일일이 진행하던 작업들(외박 승인, 심야자습 신청, 학사일정 관리 등)을 도담도담으로 해결합니다.
   • 30일간 최대 162.82k 요청, 평균 5.4k 요청/일 규모의 서비스 서버를 개발하고 유지보수하였습니다.
   • 웹 서비스는 교내 학생들만 이용할 수 있습니다.
   
2. 모놀리식 구조의 한계와 MSA 전환
   • 기존 단일 애플리케이션에서 서비스 간 결합과 배포 비효율 문제를 경험하였습니다.
   • 하나의 프로세스에서 모든 도메인이 리소스를 공유하여, 특정 도메인의 장애가 전체에 영향을 주었습니다.
   • 작은 수정에도 전체 빌드·재배포가 필요한 구조적 한계가 있었습니다.
   • 도메인 경계를 기준으로 11개 서비스로 분리하고, Spring Cloud Gateway를 단일 진입점으로 두어 라우팅과 OAuth2 인증을 처리하였습니다.
3. 서비스 분리에 따른 통신 구조 설계
   • 서비스가 분리되면서 기존에 메서드 호출로 처리되던 로직을 네트워크 통신으로 대체해야 했습니다.
   • 즉시 응답이 필요한 인증 흐름에는 gRPC를, 결과를 기다릴 필요가 없는 이벤트(사용자 생성, 알림 발송 등)에는 Kafka를 적용하였습니다.
   • Core 모듈에 이벤트 스키마와 Topic을 공통 정의하여 서비스 간 메시지 계약을 일원화하였습니다.
   • 서비스 별로 다른 언어를 적용 가능한 폴리글랏 구조를 적용할 수 있었습니다.
4. 다수 서비스의 배포·운영 복잡성 해소
   • 서비스가 늘어나면서 전체를 매번 빌드·배포하는 것이 비효율적이었습니다.
   • 변경된 서비스만 감지하여 빌드하는 Delta Build와 서비스별 순차 Rolling Update를 적용하였습니다.
   • K3s 클러스터(Worker Node 2대)를 구성하고, 트래픽이 집중되는 핵심 서비스(Gateway, Auth, User)에만 레플리카를 분산 배치하여 제한된 인프라 내에서 고가용성을 확보하였습니다.
   
5. 백엔드 인프라 구조
   • 주요 기능은 Spring Boot 서버가 담당하고, 트래픽이 높은 API는 Redis를 이용하여 Caching합니다.
   • 도담도담 계정으로 OAuth 기능을 지원하기 위해 Token 서버, OAuth 서버, OpenAPI 서버 등을 서비스합니다.
   
6. CI·CD 구조
   • PR 생성 시 GitHub Actions로 Gradle 빌드 및 테스트를 자동 수행하여 코드 품질을 검증합니다.
   • develop 브랜치 병합 시 Docker 이미지를 빌드하여 개발 서버에 Docker Compose로 배포합니다.
   • main 브랜치 병합 시 Docker 이미지를 빌드하여 kubectl apply로 K3S 클러스터에 프로덕션 배포합니다.
7. 느낀점
   • 전교생이 사용하는 서비스를 직접 운영하며 기능 제안과 장애에 빠르고 정확하게 대응하는 과정에서, 안정적인 서비스의 중요성을 느끼고 코드 품질과 유지보수성을 높이기 위해 노력하였습니다.
   • MSA 전환을 통해 트래픽이 집중되는 서비스만 선택적으로 스케일 아웃할 수 있게 되면서, 서비스 단위의 독립적인 확장이 운영 효율에 큰 차이를 만든다는 것을 깨달았습니다.