1. 대규모 시스템 설계
1.1 동시 접속자와 초당 요청량(TPS)
- 사용자 수 파악: 시스템 설계의 첫 단계는 예상 사용자 수를 파악하는 것입니다. 특히 동시 접속자 수와 특정 시간대에 발생하는 최대 초당 요청량(TPS)을 중점적으로 고려해야 합니다.
- TPS의 중요성: 초당 요청량(TPS)은 시스템이 얼마나 많은 트랜잭션을 동시에 처리할 수 있는지를 나타내는 중요한 지표입니다. 예기치 않은 트래픽 급증을 견딜 수 있도록 TPS 기준을 설정하고, 여유 있게 시스템을 설계해야 합니다.
- 대처 방안: 트래픽 급증 시에는 애플리케이션 수를 늘리거나, 대기열 설정, 자동 스케일링을 통해 부하를 분산시키는 방법을 고려해야 합니다.
1.2 요청 종류에 따른 개발
- 읽기 요청 최적화:
- 캐시 활용: Redis 같은 캐시를 사용해 반복되는 데이터 요청에 대한 응답 속도를 향상시킵니다. 엣지 캐싱은 네트워크 지연을 줄여 사용자 경험을 개선합니다.
- 데이터베이스 최적화: 인덱싱, 샤딩, 읽기 전용 데이터베이스 등을 활용하여 DB 읽기 성능을 최적화합니다.
- 쓰기 요청 최적화:
- 비동기 처리: 큐를 활용해 쓰기 요청을 비동기적으로 처리함으로써 애플리케이션의 응답 속도를 개선합니다.
- 배치 처리: 실시간으로 처리할 필요가 없는 쓰기 요청은 배치 처리로 부하를 줄일 수 있습니다.
- 분산 DB: 데이터를 분산하여 저장하고 처리할 수 있는 분산 DB를 활용해 쓰기 성능을 향상시킵니다.
1.3 데이터 일관성 유지
- 분산 트랜잭션: 여러 시스템에 걸친 트랜잭션의 일관성을 유지하기 위해 2PC, 사가 패턴, 이벤트 소싱 등을 활용합니다. 이를 통해 데이터 일관성을 보장하면서도 시스템의 확장성을 유지할 수 있습니다.
- 이벤트 소싱: 상태 변화를 이벤트로 기록하고, 이를 기반으로 시스템 상태를 복구할 수 있는 방법입니다. 복잡한 비즈니스 로직을 처리하는 시스템에서 유용하지만, 설계 및 구현의 복잡성이 증가할 수 있습니다.
- CQRS: 명령과 조회의 책임을 분리하여 성능을 최적화하고 확장성을 높입니다. 명령 모델과 조회 모델을 분리해 각각의 작업에 최적화된 구조를 사용합니다.
1.4 모니터링과 로깅
-
모니터링:
- 실시간 상태 파악: Prometheus, Grafana 같은 도구를 사용해 TPS, 응답 시간, 에러율 등을 모니터링하고, 이상 징후를 감지하면 알림을 받습니다.
- 병목 지점 파악: 모니터링을 통해 시스템의 병목 지점을 파악하고, 성능을 최적화합니다.
-
로깅:
- 이벤트 추적: ELK 스택을 활용해 주요 이벤트를 로깅하고, 문제 발생 시 원인을 추적합니다.
- 디버깅 및 오류 해결: 로그 분석을 통해 오류의 원인을 파악하고, 시스템의 성능을 지속적으로 개선합니다.
1.5 테스트와 배포
- 테스트:
- 단위 테스트: JUnit, TestNG 등을 사용해 시스템의 개별 구성 요소를 테스트합니다.
- 통합 테스트: Spring Boot와 같은 도구를 사용해 여러 구성 요소 간의 상호작용을 테스트합니다.
- 부하 테스트: JMeter로 다양한 부하 시나리오를 설정해 시스템의 성능 한계를 파악합니다.
- 배포:
- 지속적인 통합(CI): Jenkins, GitLab CI 등을 사용해 코드 변경 시 자동으로 빌드하고 테스트합니다.
- 지속적인 배포(CD): 검증된 코드를 자동으로 프로덕션 환경에 배포하여 신속한 기능 제공이 가능합니다.
- Canary 배포, 블루-그린 배포, 롤링 배포 등 다양한 배포 전략을 사용해 시스템 가동 시간을 유지하면서 안전하게 새로운 버전을 배포합니다.
오늘 학습한 내용을 바탕으로 대규모 시스템 설계의 중요성과 각 요소를 고려하는 방법에 대해 깊이 이해할 수 있었습니다. 특히 트래픽 급증을 대비한 설계, 데이터 일관성 유지, 모니터링과 로깅의 중요성을 다시 한 번 느낄 수 있었습니다. 앞으로 이러한 개념들을 실제 프로젝트에 적용해볼 계획입니다.
