System Design
System Design 은 요구사항을 충족하는 대규모 시스템을 설계하고 구성하는 과정으로, 기능적/비기능적 요구사항을 고려해 컴포넌트 간 관계, 데이터 흐름, 장애 대응, 확장 구조를 정의한다. 이는 클라우드 환경, 분산 시스템, 고가용성 아키텍처 설계 등과 밀접하며, 효율적인 아키텍처 설계를 통해 성능, 확장성, 유지보수성을 극대화하는 것이 목적이다. 실무에서는 설계 원칙과 패턴, 트레이드오프 분석 등이 핵심이다.
등장 배경 및 발전 과정
시스템 디자인은 인터넷과 클라우드 컴퓨팅의 발전과 함께 등장했다.
초기 단일 서버 아키텍처에서 시작하여 웹 2.0 시대의 대용량 트래픽 처리 필요성, 클라우드 컴퓨팅의 보편화, 마이크로서비스 아키텍처의 등장으로 발전해왔다.
1960 년대 -1980 년대: 메인프레임 시대
- 중앙 집중식 컴퓨팅
- 단일 장애점 (Single Point of Failure) 문제
1990 년대 -2000 년대: 클라이언트 - 서버 아키텍처
- 네트워크 컴퓨팅의 확산
- 3 계층 아키텍처의 등장
2000 년대 중반: 웹 2.0 과 대용량 트래픽
- Google, Amazon, Facebook 등의 급성장
- 기존 아키텍처의 한계 노출
2010 년대: 클라우드와 마이크로서비스
- AWS, Azure 등 클라우드 플랫폼 보편화
- Netflix, Uber 등의 마이크로서비스 사례
2020 년대: 클라우드 네이티브와 서버리스
- 컨테이너 기반 배포
- 서버리스 컴퓨팅의 확산
목적 및 필요성
목적
비즈니스 연속성 보장
- 서비스 중단 시간 최소화
- 사용자 경험 일관성 유지
비용 효율성 달성
- 리소스 사용량 최적화
- 운영 비용 절감
확장성 확보
- 사용자 증가에 대한 대응
- 데이터 증가에 대한 처리
필요성
디지털 전환 가속화
- 모든 산업의 디지털화
- 온라인 서비스 의존도 증가
글로벌 서비스 요구
- 24/7 서비스 제공 필요
- 지역별 특성 고려
데이터 폭증 대응
- 빅데이터 처리 요구
- 실시간 분석 필요
핵심 개념
System Design은 요구사항 (기능적/비기능적) 을 충족시키는 시스템을 구성하는 아키텍처적 방법론으로, 복잡한 시스템을 모듈화 (Modularization), 인터페이스 정의, 통신 설계, 데이터 저장소 구조화 등을 통해 안정적이고 확장 가능하게 구축하는 데 중점을 둔다.
기본 개념
확장성 (Scalability)
- 시스템이 증가하는 부하를 처리할 수 있는 능력
- 수직 확장 (Scale Up): 더 강력한 하드웨어 사용
- 수평 확장 (Scale Out): 더 많은 서버 추가
신뢰성 (Reliability)
- 시스템이 예상대로 지속적으로 작동하는 능력
- 장애 허용성 (Fault Tolerance) 포함
- 평균 고장 간격 시간 (MTBF: Mean Time Between Failures)
가용성 (Availability)
- 시스템이 운영 가능한 상태를 유지하는 시간의 비율
- 99.9% (8.76 시간/년), 99.99% (52.56 분/년) 등으로 측정
일관성 (Consistency)
- 모든 노드가 동일한 시점에 동일한 데이터를 보는 것
- 강한 일관성, 약한 일관성, 결과적 일관성으로 분류
분할 허용성 (Partition Tolerance)
- 네트워크 분할이 발생해도 시스템이 계속 동작하는 능력
- CAP 정리의 핵심 요소
심화 개념
로드 밸런싱 (Load Balancing)
- 들어오는 요청을 여러 서버에 분산
- Round Robin, Weighted Round Robin, Least Connections 등
캐싱 (Caching)
- 자주 접근하는 데이터를 빠르게 접근할 수 있는 저장소에 보관
- CPU 캐시, 메모리 캐시, 디스크 캐시, 분산 캐시
데이터베이스 설계
- RDBMS vs NoSQL 선택
- 데이터 모델링, 인덱싱, 쿼리 최적화
마이크로서비스 아키텍처
- 작고 독립적인 서비스들로 애플리케이션을 구성
- 서비스 간 통신, 데이터 일관성, 배포 복잡성 관리
실무 구현과의 연관성
실무 요소 | 관련 핵심 개념 | 설명 |
---|---|---|
트래픽 급증 대응 | 수평 확장성 (Horizontal Scalability) | 다수의 서버 인스턴스를 통한 처리 능력 확장 |
장애 허용 설계 | 장애 분리 (Fault Isolation), 복제 (Replication) | 시스템 구성요소의 독립성과 데이터 중복으로 장애 확산 방지 |
지연 시간 최소화 | 캐싱 (Caching), CDNs | 자주 접근하는 데이터 또는 정적 파일을 메모리 또는 에지 서버에 저장 |
비동기 처리 | 메시지 큐 (Message Queue) | 요청과 처리의 비동기화를 통한 시스템 유연성 확보 |
시스템 유지보수 | 모듈화 (Modularization) | 책임이 명확한 컴포넌트로 분리하여 유지보수 용이 |
주요 기능 및 역할
주요 기능
아키텍처 설계
- 시스템 구조 정의
- 컴포넌트 간 상호작용 설계
성능 최적화
- 응답 시간 개선
- 처리량 (Throughput) 향상
보안 설계
- 인증 및 인가 체계
- 데이터 암호화
모니터링 및 관찰성
- 시스템 상태 추적
- 장애 예측 및 대응
주요 역할
비즈니스 요구사항 기술 구현
- 기능적 요구사항을 기술적으로 해결
- 비기능적 요구사항 (성능, 보안 등) 충족
기술 스택 선택 및 통합
- 적절한 기술 조합 결정
- 기술 간 호환성 보장
위험 관리
- 기술적 위험 식별 및 완화
- 장애 복구 계획 수립
기능과 역할의 관계
시스템 설계의 기능들은 계층적 관계를 형성한다:
- 아키텍처 설계가 기반을 제공
- 성능 최적화가 품질을 보장
- 보안 설계가 신뢰성을 확보
- 모니터링이 지속적 개선을 지원
특징
- 복잡성 관리
- 계층화와 모듈화를 통한 복잡성 분해
- 관심사 분리 (Separation of Concerns) 원칙 적용
- 트레이드오프 인식
- CAP 정리에 따른 선택과 집중
- 성능 vs 비용, 일관성 vs 가용성 등의 균형
- 진화 가능성
- 요구사항 변화에 대한 적응성
- 점진적 개선 (Incremental Improvement) 지원
- 측정 가능성
- 정량적 지표를 통한 성능 평가
- SLA (Service Level Agreement) 기반 운영
모듈화된 아키텍처를 통해 복잡성을 관리하고, 명확한 인터페이스 정의로 컴포넌트 간 결합도를 낮춘다. 설계 패턴 적용으로 일관성을 유지하며, 지속적인 모니터링으로 측정 가능성을 확보한다.
핵심 원칙
시스템 설계는 사용자 요구를 분석하고, 이를 바탕으로 시스템 구조와 구성 요소, 데이터 흐름, 상호작용 등을 설계한다. 설계된 시스템은 확장성, 신뢰성, 성능, 보안 등 품질 속성을 보장하며, 실제 구현, 테스트, 배포를 거쳐 운영된다.
설계 원칙
단일 책임 원칙 (Single Responsibility Principle)
- 각 컴포넌트는 하나의 책임만 가져야 함
- 변경 이유가 하나여야 함
느슨한 결합 (Loose Coupling)
- 컴포넌트 간 의존성 최소화
- 인터페이스를 통한 상호작용
높은 응집성 (High Cohesion)
- 관련된 기능을 하나의 모듈로 그룹화
- 내부 요소들 간 강한 연관성
확장성 우선 설계
- 미래 확장을 고려한 구조
- 수평 확장이 용이한 아키텍처
운영 원칙
장애 격리 (Fault Isolation)
- 하나의 장애가 전체 시스템에 미치는 영향 제한
- 서킷 브레이커 패턴 적용
점진적 배포 (Gradual Deployment)
- 카나리 배포, 블루 - 그린 배포 등
- 위험 최소화
자동화 우선
- 반복적 작업의 자동화
- 인적 오류 감소
실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점
카테고리 | 고려사항 | 주의사항 | 권장사항 |
---|---|---|---|
설계 전략 | 요구사항 정의 및 정제 | 비기능 요구사항 (NFR) 누락 | 성능, 가용성, 확장성, 장애 복구 등을 포함한 NFR 명세 작성 |
도메인 분리 | 과도한 마이크로서비스 분할 | DDD 기반 서비스 책임 경계 정의 | |
시스템 목표 설정 | 모든 요구사항에 동일 우선순위 부여 | 우선순위 기반의 기능/비기능 분류 및 문서화 | |
기술 아키텍처 | 기술 스택 선정 | 최신 기술만 도입하거나, 기술 다양성으로 복잡도 증가 | 조직 역량, 유지보수성, 커뮤니티 성숙도 고려한 선택 |
데이터 일관성 전략 | 분산 트랜잭션 단순화 혹은 과소평가 | Event Sourcing, CQRS, SAGA 등 활용 | |
API 및 인터페이스 설계 | 버전 관리 없이 공용 인터페이스 변경 | 명확한 계약 기반 API 설계, 버전 관리 (V1/V2…) 도입 | |
배포 전략 | 배포 자동화 | 수동 배포로 인한 휴먼 에러 | CI/CD 파이프라인 구축, 자동화 테스트/롤백 적용 |
점진적 배포 | 전체 서비스 동시 배포로 위험 증가 | 카나리 배포, 블루 - 그린, 피쳐 플래그 적용 | |
장애 시나리오 플랜 | 단일 장애 지점 (SPOF) 존재 | 구성요소 이중화, 시뮬레이션 기반 복구 전략 수립 | |
운영/관찰성 | 모니터링 및 관찰성 확보 | 분산 환경에서 로그/추적 누락 | 구조화된 로깅, 메트릭 표준화, OpenTelemetry 기반 분산 추적 |
성능 관리 | 캐시 설계 없이 확장성만 고려 | 다층 캐시 구조, TTL, 캐시 무효화 정책 명확화 | |
장애 대응 및 복원력 | 서킷브레이커/리트라이 정책 미비 | Circuit Breaker, Timeout, 백업 시스템 적용 | |
보안 설계 | 인증 및 인가 체계 | 접근 제어 없이 내부 서비스 노출 | OAuth2, JWT, mTLS, API Gateway 기반 인증/인가 |
네트워크 보안 | 내부 통신 암호화 미적용 | 제로 트러스트 모델, 서비스 간 통신 암호화 적용 | |
문서화 및 리뷰 | 시스템/아키텍처 문서화 | 설계 문서 누락, 트레이드오프 설명 부재 | ADR(Architecture Decision Record), 설계 흐름도, API 명세 작성 및 지속적 유지 |
아키텍처 리뷰와 피드백 | 일부 개발자 중심 의사결정 | Cross-functional Review, Peer Review 포함 |
최적화하기 위한 고려사항 및 주의할 점
카테고리 | 최적화 대상 | 핵심 설명 | 주의할 점 | 권장 사항 및 전략 |
---|---|---|---|---|
1. 성능 최적화 | 응답 시간, 처리량, I/O | SLA 기반 응답 속도, Throughput 확보 | 조기 최적화, 복잡도 증가 | 병목 구간 프로파일링, 80/20 법칙 적용, 인덱싱/배치/비동기 처리 |
캐시 전략 | 읽기 성능 향상 및 부하 분산 | 캐시 일관성, Stale Data | TTL 설정, Write-through/Write-back, LRU/LFU 적용 | |
데이터 접근 최적화 | 필요 시점에 최소한의 데이터 로드 | Lazy Load 시 의도치 않은 지연 | Index, Batching, Lazy Loading, Prefetch 적용 | |
GC 및 메모리 관리 | 응답 지연 방지, GC Pause 최소화 | 힙 사이즈 과소/과대 설정 | GC 튜닝 (G1GC 등), 메모리 프로파일링, 힙 크기 조절 | |
2. 확장성 최적화 | 수평 확장, 분산 처리 | 스케일아웃 전략에 따른 부하 분산 | 상태 관리 복잡성 (세션, 상태 저장소 등) | Stateless 설계, 분산 세션 저장소 (Redis 등), Service Discovery 적용 |
오토스케일링 | 트래픽 증가/감소 대응 | 스케일 인/아웃 지연, 잘못된 임계치 설정 | 예측 기반 스케일링, 최소 예비 인스턴스 확보 | |
데이터 분산 | 데이터 파티셔닝/복제 | 일관성 모델 선택 (CAP) 문제 | Sharding, Consistent Hashing, Read/Write 분리, Eventual Consistency 적용 | |
3. 신뢰성/복원력 | 장애 허용, 복제 전략 | 장애 발생 시 자동 복구 및 서비스 지속 보장 | 복잡도 증가, 동기화 비용 | Health check, Failover 설계, Circuit Breaker, Retry with Jitter |
재시도/타임아웃/백오프 | 네트워크 장애, 일시적 실패 대응 | 무한 루프, 리소스 고갈 | 지수 백오프, Retry 제한, Timeout 설정, Circuit Breaker 패턴 적용 | |
4. 비용 최적화 | 리소스 할당, 스케일 정책 | 성능 유지하면서 비용 효율 확보 | 과도한 절감으로 성능 저하 | 예약 인스턴스/스팟 인스턴스 활용, Auto-scaling + 모니터링 기반 비용 관리 |
저장소 및 아카이빙 | 장기 보관/비정기 조회 데이터 저장 비용 최소화 | 압축률 vs CPU 사용량 Trade-off | Hot-Cold 데이터 분리, Glacier/S3 IA 같은 계층형 스토리지 사용 | |
5. 네트워크 최적화 | CDN, 지연 최소화, 메시지 크기 최적화 | 요청 지연 및 대역폭 사용 최적화 | 캐시 미스, 메시지 직렬화 오버헤드 | CDN 정책 설정, 캐시 히트율 모니터링, 메시지 압축 (Protobuf, Avro), Gzip 전송 적용 |
6. 관측 가능성 (Observability) | 트레이싱, 로깅, 모니터링 | 시스템 상태, 병목, 장애 추적 | 과도한 로깅, 개인정보 유출 가능성 | OpenTelemetry, Prometheus + Grafana, Jaeger/Zipkin 도입 |
7. 데이터베이스 최적화 | 쿼리 성능, 인덱스 관리 | DB 부하 분산 및 빠른 검색 | 과도한 인덱스 → 쓰기 성능 저하 | 쿼리 플랜 분석, 인덱스 리밸런싱, 파티셔닝/Read Replica 활용 |
8. 아키텍처 구조 | 동기/비동기 흐름 설계 | 성능, 복원력, 확장성에 직접적 영향 | 적절하지 않은 모델 선택 시 오히려 병목 발생 | Queue/Event 기반 비동기 처리, Saga/CQRS 등 설계 적용 |
9. 운영/테스트 최적화 | 부하 테스트, 트래픽 예측 | 실제 상황 미반영 가능성 | 테스트 커버리지 부족, 불완전한 모의 데이터 | 부하 시뮬레이션 (Apache JMeter, k6 등), 트래픽 기반 테스트 자동화 |
System Design 실무 설계 예제
실시간 채팅 시스템 설계
요구사항:
- 기능적:
- 사용자 간 1:1 채팅 지원
- 메시지 읽음/안 읽음 표시
- 메시지 저장 및 조회
- 오프라인 메시지 푸시 알림
- 확장 가능한 구조
- 비기능적:
- 수십만 동시 사용자 처리
- 99.99% 가용성
- 메시지 지연 ≤ 200ms
- 저장 데이터의 내구성 확보
1 단계: 핵심 기능 정의
- 실시간 송수신 → WebSocket
- 메시지 중계 및 유실 방지 → 메시지 큐 (Kafka)
- 메시지 영속 저장 → NoSQL (MongoDB) 또는 Cassandra
- 빠른 채팅방 목록 조회 → Redis 캐시
- 푸시 알림 → Firebase 또는 SNS
2 단계: 시스템 아키텍처 구성
graph TD U[User Device] --> WS[WebSocket Gateway] WS --> LB1[Chat Load Balancer] LB1 --> CS[Chat Server] CS --> MQ[Kafka Topic] CS --> C[Redis Cache] MQ --> P[Message Processor] P --> DB["NoSQL DB (Mongo/Cassandra)"] P --> PN[Push Notification Server]
3 단계: 주요 설계 결정
컴포넌트 | 선택 기술 | 설계 이유 |
---|---|---|
WebSocket Gateway | Nginx + WS 통신 | 실시간 양방향 통신 지원 |
메시지 브로커 | Kafka | 메시지 유실 방지, 확장성 |
데이터 저장소 | MongoDB 또는 Cassandra | 빠른 쓰기, 수평 확장 |
캐시 | Redis | 채팅방 리스트/메시지 캐싱 |
알림 시스템 | Firebase / SNS | 모바일 푸시 연동 |
각 구성 요소는 상황에 따라 기술 선택이 달라지며, 단순 비교가 아닌 요구사항 기반의 선택과 트레이드오프 판단이 중요하다.
4 단계: 고려한 트레이드오프
선택 | 트레이드오프 |
---|---|
Kafka 사용 | 고가용성과 메시지 유실 방지 → 시스템 복잡도 증가 |
WebSocket | 실시간성 확보 → 커넥션 유지 비용 증가 |
NoSQL 사용 | 확장성 확보 → 트랜잭션 약화 가능 |
5 단계: 실시간 메시지 흐름 워크플로우
sequenceDiagram participant U as User participant G as WebSocket Gateway participant C as Chat Server participant K as Kafka participant P as Processor participant D as DB U->>G: WebSocket 메시지 전송 G->>C: 메시지 전달 C->>K: Kafka Topic에 메시지 Push K->>P: 메시지 Consume P->>D: DB에 메시지 저장 P->>G: ACK 또는 푸시 알림 전송
6 단계: 최적화 포인트
대상 | 전략 |
---|---|
메시지 큐 처리 | 멀티 Consumer, 파티셔닝 |
메시지 저장 | 비동기 저장, 배치 쓰기 |
채팅방 리스트 | Redis 기반 TTL 캐시 |
장애 대응 | Kafka + Retry, Circuit Breaker |
서버 스케일링 | Horizontal Scaling + AutoScaling Group |
주제와 관련하여 주목할 내용
카테고리 | 주제 | 핵심 항목 | 설명 |
---|---|---|---|
아키텍처 설계 | 계층형 아키텍처 | Presentation, Logic, Data Layer | 명확한 책임 분리로 유지보수 및 확장성 확보 |
마이크로서비스 패턴 | Service Mesh, CQRS, Event Sourcing | 서비스 간 통신 및 상태 변경을 패턴 기반으로 분리/최적화 | |
서버리스 아키텍처 | AWS Lambda, Azure Functions | 이벤트 기반 확장성과 운영 간소화를 제공하는 컴퓨팅 모델 | |
Trade-offs | Latency vs. Throughput, CAP Theorem | 설계 시 성능, 일관성, 확장성 간의 균형을 고려한 의사결정 필수 | |
성능 최적화 | 캐싱 | Redis, Memcached, CDN, 브라우저 캐시 | 응답 속도 향상과 백엔드 부하 감소를 위한 다층 캐시 전략 적용 |
수평 확장 | Auto Scaling Group, Kubernetes HPA | 사용자 증가 및 트래픽 변화에 따른 유연한 확장 구조 설계 | |
샤딩/복제 | DB Sharding, Read Replicas | 대용량 데이터 처리를 위한 수평적 확장 전략 | |
통신 구조 | 클라이언트 - 서버 | HTTP, REST, gRPC 등 | 전통적 1:1 통신 구조 기반, API 중심 구조 구현 |
비동기 메시징 | Kafka, RabbitMQ, 메시지 큐 | 느슨한 결합 및 대규모 이벤트 기반 아키텍처에 적합 | |
API 게이트웨이 | 인증/인가, 로깅, 라우팅 | 통합 진입점에서 다양한 기능을 담당하며 마이크로서비스의 핵심 구성 요소 | |
데이터 동기화 | CDC (Change Data Capture) | 데이터 변경 사항 실시간 반영으로 시스템 간 정합성 유지 | |
보안 설계 | 인증/인가 | OAuth 2.0, JWT, RBAC | 사용자 접근 제어 및 API 보호 표준 |
네트워크 보안 | Zero Trust, mTLS | 서비스 간 보안을 보장하는 네트워크 보안 모델 적용 | |
장애 대응 | 내결함성 및 복구 전략 | Circuit Breaker, Retry, Failover | 장애 격리, 자동 회복, 중단 최소화를 위한 보호 패턴 |
이중화 | Active-Active, Active-Passive 구성 | 단일 장애 지점 (SPOF) 제거를 위한 고가용성 전략 | |
데이터 아키텍처 | 일관성 모델 | Strong, Eventual, Causal Consistency | 요구 사항에 따라 선택적으로 적용되는 일관성 보장 전략 |
데이터 저장 전략 | 데이터 레이크, 데이터 메시, 분산 DB | 대규모·비정형·분산 데이터 처리를 위한 저장소 설계 전략 적용 | |
관찰성과 운영 | 모니터링 | Prometheus, Grafana | 메트릭 기반의 실시간 상태 추적 및 대시보드 제공 |
분산 추적 | OpenTelemetry, Jaeger, Zipkin | 마이크로서비스 간 호출 관계 추적 및 성능 병목 파악 가능 | |
로그 관리 | 중앙 집중형 로깅, 구조화 로그 | 장애 분석 및 실시간 감사를 위한 핵심 요소 | |
배포 전략 | CI/CD 자동화 | GitOps, ArgoCD, Jenkins | 인프라 및 코드의 안정적 릴리즈를 위한 자동화된 파이프라인 |
점진적 배포 | 블루 - 그린, 카나리, 피처 플래그 | 무중단 배포 및 사용자 영향 최소화를 위한 배포 전략 | |
설계 문서화 | 의사결정 기록 | ADR (Architecture Decision Record) | 아키텍처 설계 및 기술 선택의 역사와 근거를 기록하여 지속 가능성 확보 |
시스템 흐름 문서화 | API 스펙, 시퀀스/플로우 다이어그램 | 개발 및 협업 시 시스템 구조 파악과 온보딩에 중요한 문서 |
반드시 학습해야할 내용
카테고리 | 주제 | 핵심 항목 | 설명 및 핵심 개념 |
---|---|---|---|
1. 분산 시스템 이론 | 일관성/가용성 이론 | CAP, BASE, PACELC | 분산 시스템의 근본 제약: 일관성 vs 가용성 vs 파티션 내성, 지연 - 일관성 트레이드오프 분석 |
트랜잭션 처리 | ACID, 격리 수준, 동시성 제어 | 분산 트랜잭션 특성과 DB 일관성 보장 기법 (2PC, SAGA 포함) | |
분산 합의 알고리즘 | Raft, Paxos, PBFT | 분산 시스템에서의 일관된 상태 합의, 리더 선출, 블록체인 등에도 활용 | |
2. 네트워크 및 통신 | 프로토콜 및 통신 구조 | TCP/IP, HTTP/2·3, gRPC, WebSocket | 효율적 데이터 전송을 위한 최신 통신 기술, 실시간 처리 및 바이너리 전송 최적화 |
API 설계 | REST, RESTful, GraphQL, gRPC | API 디자인 원칙 및 내부/외부 API 아키텍처 구분 (페이로드 최적화, 보안 포함) | |
3. 보안 및 인증/인가 | 인증/인가 모델 | OAuth2, JWT, RBAC, ABAC | API 보안 및 마이크로서비스 간 인증 방안 |
암호화/서명/해시 | 대칭/비대칭 암호화, 해시 함수, 디지털 서명 | 데이터 무결성과 기밀성 확보, 인증 및 무결성 검증 기술 적용 | |
4. 설계 원칙/패턴 | 객체지향 및 구조적 설계 원칙 | SOLID, KISS, DRY, YAGNI | 유지보수성과 확장성을 높이는 기본 설계 원칙 |
디자인 패턴 | 싱글톤, 팩토리, 옵저버, 전략, 어댑터 등 | 구조적 설계 재사용을 위한 핵심 패턴들 | |
아키텍처 스타일/패턴 | Layered, Hexagonal, Clean Architecture, MSA | 시스템 구성의 큰 틀, 의존성 관리, 도메인 중심 설계 적용 방식 | |
고급 설계 패턴 | CQRS, Event Sourcing, Saga, Circuit Breaker | 이벤트 기반 구조와 회복탄력성 있는 시스템 설계 | |
5. 데이터 설계 | 데이터 저장소 및 분산 처리 | SQL vs NoSQL, Sharding, Replication, Partitioning | 데이터 특성과 트래픽에 따른 적절한 저장소 선택 및 분산 전략 |
데이터 모델링 | 정규화/반정규화, 인덱싱, 파티셔닝 전략 | 읽기/쓰기 최적화를 위한 DB 구조 설계 전략 | |
6. 성능 최적화 | 캐싱/로딩 전략 | In-memory Cache, Distributed Cache, TTL, LRU | 응답 지연 감소 및 트래픽 감소를 위한 캐시 설계 |
로드 밸런싱 | 라운드 로빈, Least Conn., IP Hash, Sticky Session | 수평 확장을 위한 트래픽 분산 기법 | |
비동기 처리 및 큐잉 | Kafka, RabbitMQ, SQS, Celery, Message Patterns | 병렬 처리, 이벤트 기반 설계의 핵심 컴포넌트 | |
7. 운영 및 인프라 | 컨테이너 및 오케스트레이션 | Docker, Kubernetes | 마이크로서비스 배포 및 확장성을 위한 표준 플랫폼 |
CI/CD | 지속적 통합/배포 파이프라인 구성 | 빠른 롤아웃/롤백을 위한 DevOps 핵심 전략 | |
서비스 메시 및 트래픽 제어 | Istio, Linkerd, Envoy | 마이크로서비스 간 네트워크 제어 및 트래픽 정책 적용 | |
8. 가용성 및 복원력 | 이중화/장애 허용 | Failover, Health Check, Auto-healing | 시스템 장애에 대응할 수 있는 복원력 설계 |
복원력 패턴 | Circuit Breaker, Timeout, Retry, Bulkhead | 장애 격리 및 전파 방지를 위한 핵심 제어 구조 | |
9. 관측 가능성 | 모니터링 및 로깅 | Prometheus, Grafana, ELK, Fluent Bit | 시스템 상태 시각화 및 운영 이슈 사전 대응 |
분산 트레이싱 | OpenTelemetry, Jaeger, Zipkin | 마이크로서비스 트랜잭션 추적 및 병목 탐지 | |
10. 시스템 구조 이해 | 모듈화 | 계층 구조, Bounded Context, 의존성 분리 | 확장 가능한 구조 및 책임 분리를 위한 모듈 설계 |
Client-Server 구조 | Frontend-Backend 분리, API Gateway | 요청 흐름/통신 모델에 대한 이해 (MVC → API Gateway 구조까지) | |
마이크로서비스 아키텍처 | 독립 배포, 각 서비스 간 느슨한 결합 | 대규모 시스템 확장을 위한 핵심 구조 |
용어 정리
카테고리 | 용어 | 설명 | |
---|---|---|---|
아키텍처 스타일 | Monolith (모놀리식) | 모든 기능이 하나의 애플리케이션에 통합된 구조로, 초기 개발은 단순하지만 확장성과 유지보수가 어려움 | |
Microservices (마이크로서비스) | 기능별로 분리된 작은 서비스들로 구성되어 독립 배포와 확장이 용이한 분산 아키텍처 | ||
Client-Server | 클라이언트가 요청을 보내고 서버가 응답을 반환하는 전통적인 구조 | ||
Service Mesh | 마이크로서비스 간 통신을 추상화하고 제어하는 인프라 계층 (ex: Istio) | ||
API Gateway | 클라이언트 요청을 백엔드 서비스로 라우팅하고 인증, 로깅, 제한 등을 처리하는 진입점 | ||
Load Balancer | 클라이언트 요청을 여러 서버에 균등하게 분산시켜 트래픽을 조절하는 장치 | ||
Event Sourcing | 상태 변경을 이벤트로 기록하고, 이 이벤트들을 통해 현재 상태를 재구성하는 패턴 | ||
CQRS | 명령 (Command) 과 조회 (Query) 를 분리하여 성능, 확장성, 보안성을 개선하는 아키텍처 패턴 | ||
Saga Pattern | 분산 시스템에서 트랜잭션을 순차적 보상 작업으로 나누어 처리하는 패턴 | ||
데이터 처리 | Sharding | 데이터를 수평적으로 분할하여 여러 서버에 분산 저장하는 방식 (스케일 아웃) | |
Replication | 데이터 복제를 통해 가용성과 내결함성 (Fault Tolerance) 확보 | ||
ACID | 트랜잭션의 4 가지 속성: 원자성, 일관성, 격리성, 지속성 | ||
BASE | NoSQL 기반 원칙: 기본적 가용성, 소프트 상태, 결과적 일관성 | ||
CQRS | 조회와 명령을 분리하여 확장성과 성능을 높이는 설계 방식 | ||
Consistency | 모든 노드에서 동일한 데이터 상태를 유지하는 성질 | ||
Partition Tolerance | 네트워크 분할 상황에서도 시스템이 계속 동작하는 능력 | ||
확장성/성능 | Horizontal Scaling | 서버의 수를 늘려 트래픽과 데이터를 분산하여 처리 능력을 향상 | |
Vertical Scaling | 서버의 하드웨어 성능 (CPU, RAM 등) 을 높여 처리 능력을 강화 | ||
Caching | 자주 접근하는 데이터를 메모리 등 빠른 저장소에 저장하여 응답 속도 향상 | ||
CDN | 전 세계에 분산된 노드를 통해 콘텐츠를 가까운 위치에서 빠르게 전달 | ||
Load Balancing | 요청을 여러 서버에 분산시켜 병목 현상을 방지하고 안정성을 확보 | ||
Throttling | 클라이언트의 요청 속도를 제한하여 시스템을 보호 | ||
신뢰성/장애 대응 | Circuit Breaker | 외부 서비스 오류가 반복될 경우 빠르게 실패 처리하여 시스템 전체 장애 방지 | |
Failover | 장애 발생 시 자동으로 대기 시스템으로 전환하여 가용성 유지 | ||
Redundancy (이중화) | 장애에 대비하여 동일 기능을 하는 시스템을 중복 구성 | ||
Availability | 시스템이 정상적으로 작동할 수 있는 시간의 비율 (Uptime) | ||
통신/메시징 | REST API | HTTP 기반의 동기 통신 인터페이스 | |
메시지 브로커 | 비동기 메시지 전달을 위한 시스템 (Kafka, RabbitMQ 등) | ||
메시지 큐 (Queue) | 생산자가 보낸 메시지를 소비자가 순차적으로 처리하는 FIFO 구조 | ||
Pub/Sub | 하나의 발행자가 다수의 구독자에게 메시지를 전달하는 방식 | ||
보안 | OAuth 2.0 | 외부 애플리케이션이 제한된 접근 권한을 갖도록 하는 인증 프레임워크 | |
JWT | JSON 기반의 인증 토큰으로, 무상태 (stateless) 인증 방식 | ||
RBAC | 역할 기반 접근 제어 방식으로 권한을 역할 단위로 관리 | ||
mTLS | 클라이언트와 서버가 서로 인증하는 TLS 방식 | ||
운영/배포 | CI/CD | 지속적 통합 (Continuous Integration) 과 지속적 배포 (Continuous Deployment) | |
GitOps | Git 을 단일 진실의 소스로 사용하여 운영을 자동화하는 방식 | ||
Container | 애플리케이션과 그 의존성을 패키징하여 격리된 환경에서 실행 | ||
Orchestration | 여러 컨테이너의 배포, 확장, 관리를 자동화 (ex: Kubernetes) | ||
Immutable Deployment | 서버를 수정하지 않고 새 인스턴스를 통해 배포하는 방식 | ||
Strangler Pattern | 레거시 시스템을 점진적으로 새로운 시스템으로 교체하는 전략 | ||
모니터링/가시성 | APM | 애플리케이션의 성능을 모니터링하고 병목을 진단하는 도구 | |
Distributed Tracing | 여러 마이크로서비스에 걸친 요청 흐름 추적 | ||
SLA/SLO/SLI | 서비스 수준 계약/목표/지표로 서비스 품질을 측정하고 약속하는 기준 |
참고 및 출처
Scalability, Availability, and Reliability
- Scalability, Availability, and Reliability: Core Principles for Building a Robust System
- Designing for scalability: Principles every engineer should know
- Scalable Software System Design: Key Principles, Best Practices
- Grokking Scalability in System Design: How I Learned the Techniques, Principles, and Best Practices
System Design 총론
- What is System Design? A Comprehensive Guide to System Architecture and Design Principles
- System Design Fundamentals – Design Gurus
- System Design Complete Guide – Swimm
- Systems Design – CIO Wiki
- System Architecture – InterviewBit
Design Principles & Patterns
- Design Principles in System Design – GeeksforGeeks
- Design Patterns vs. Principles – Medium
- Software Design Pattern – Wikipedia
- Nonfunctional Requirements – Martin Fowler
Caching & Load Balancing
- Caching – System Design Concept – GeeksforGeeks
- Load Balancer – System Design Interview Question – GeeksforGeeks
Microservices Vs Monolith
실전 아키텍처 자료
- AWS Well‑Architected Framework
- Google Cloud Architecture Center
- Microsoft Azure Architecture Center
- The Twelve‑Factor App
- Netflix Technology Blog
- High Scalability
- Martin Fowler’s Blog
- Kubernetes Documentation
- Cloud Native Computing Foundation (CNCF)
추가 학습 및 참고 리소스
- System Design Cheatsheet – GitHub Gist (vasanthk)
- Top 20 System Design Concepts You Should Know – ByteByteGo
- 15 System Design Core Concepts – Medium / Interviewing.io
- System Design Tutorial – GeeksforGeeks
- A Comprehensive Guide to Fundamental Concepts of System Design – datmt
- Fundamentals of System Design – dev.to