[데이터 중심 애플리케이션 설계] 01장
[DDIA] 1장. 신뢰성·확장성·유지보수성을 갖춘 데이터 시스템
읽은 책: Designing Data-Intensive Applications (Martin Kleppmann)
목표: “데이터 중심 애플리케이션”을 설계할 때 무엇을 우선순위로 봐야 하는지 큰 그림 잡기
0. 이 장이 던지는 질문
현대 애플리케이션은 단순히 “DB 하나”로 끝나지 않는다.
캐시, 검색 인덱스, 메시지 큐, 스트림/배치 처리 등 여러 컴포넌트가 엮여 데이터 시스템을 이룬다.
이 장의 핵심 질문은 이거다:
- 시스템이 커지고 복잡해져도 얼마나 믿을 수 있는가? (Reliability)
- 트래픽/데이터가 늘어나도 버틸 수 있는가? (Scalability)
- 팀과 코드가 바뀌어도 운영/개선이 가능한가? (Maintainability)
1. 데이터 중심 애플리케이션이란?
일반적인 애플리케이션은 “계산(Compute)”보다 “데이터(Data)”가 중심이 되는 경우가 많다.
그래서 성능/안정성/개발 난이도의 병목이 데이터 계층에서 터지기 쉽다.
대표적인 데이터 시스템 구성요소:
- 데이터베이스 (DB)
- 캐시
- 검색 인덱스
- 스트림 처리/메시지 큐
- 배치 처리 시스템
중요 포인트:
- 각각은 “데이터를 다루는 목적이 다름”
- 한 컴포넌트만 최적화해도 전체가 좋아지지 않음(시스템 관점 필요)
2. 신뢰성(Reliability): “정상적으로 계속 동작하는가?”
2.1 신뢰성의 의미
- 사용자가 기대한 기능을 올바르게 수행
- 장애/실수/예상치 못한 상황에서도 가능한 한 정상 서비스 유지
- 장애가 나더라도 “피해를 제한하고 복구 가능”해야 함
2.2 장애(Fault) vs 고장(Failure)
- Fault: 구성 요소 일부가 잘못되는 상황(디스크 불량, 네트워크 단절, 버그 등)
- Failure: 시스템 전체가 사용자에게 서비스를 못하는 상태
즉, fault는 피할 수 없고, 설계로 failure로 번지지 않게 해야 한다.
2.3 현실에서 흔한 fault 원인
- 하드웨어 문제(디스크, 메모리, 전원, 네트워크)
- 소프트웨어 문제(버그, 메모리 릭, 리소스 고갈, 의존성 장애)
- 사람 문제(잘못된 배포, 설정 실수, 운영 절차 미흡)
2.4 신뢰성을 높이는 전형적인 접근
- 중복(Replication), 페일오버, 롤백
- 격리(격리된 배포/점진적 롤아웃), 제한(레이트 리밋)
- 관측성(로그/메트릭/트레이싱), 장애 대응 프로세스
개인 메모: “장애 0”은 목표가 아니라 환상.
목표는 장애가 나도 서비스가 망가지지 않는 구조와 빨리 복구하는 능력.
3. 확장성(Scalability): “부하가 늘면 어떻게 대응할까?”
확장성은 “현재 빠르다”가 아니라, 부하가 증가할 때 성능을 유지/개선할 수 있는 능력이다.
3.1 먼저 부하(Load)를 정의해야 한다
확장 설계는 감으로 하면 망한다.
다음 같은 부하 파라미터를 수치로 잡는 게 출발점이다.
- 초당 요청 수(QPS)
- 읽기/쓰기 비율
- 활성 사용자 수
- 데이터 크기(총 저장량, 인덱스 크기)
- 이벤트/메시지 처리량(초당 n건)
3.2 성능(Performance) 측정은 평균이 아니라 “꼬리”가 중요
사용자는 “평균”이 아니라 느린 순간을 체감한다.
- 지연시간(latency): 요청 1건이 끝날 때까지 걸리는 시간
- 처리량(throughput): 단위 시간당 처리한 요청 수
지연시간은 보통 퍼센타일(p95, p99)로 본다.
- p95: 95% 요청이 이 시간 이내에 끝남
- p99: 99% 요청이 이 시간 이내에 끝남 (꼬리 지연)
운영 관점에선 p99가 흔히 “사용자 불만”과 직결된다.
3.3 확장 전략: 스케일 업 vs 스케일 아웃
- 스케일 업(수직 확장): 더 좋은 서버로 교체
- 장점: 단순함
- 단점: 한계/비용/단일 장애 지점 위험
- 스케일 아웃(수평 확장): 서버 수를 늘림
- 장점: 더 큰 규모까지 가능
- 단점: 분산 시스템 복잡도(데이터 분할, 일관성, 장애처리)가 급상승
4. 유지보수성(Maintainability): “미래의 내가 고칠 수 있는가?”
이 장에서 유지보수성은 크게 3가지로 쪼갠다.
4.1 운용성(Operability)
- 운영하기 쉬운 시스템인가?
- 모니터링/배포/복구/문서화/자동화가 갖춰져 있는가?
4.2 단순성(Simplicity)
- 복잡도를 줄였는가?
- “우발적 복잡도(불필요한 복잡함)”를 제거했는가?
복잡도가 쌓이면:
- 장애 원인 파악이 느려짐
- 변경 비용이 폭증
- 신규 인원이 온보딩 불가
4.3 발전성(Evolvability)
- 요구사항이 바뀌었을 때 확장/변경 가능한 구조인가?
- 새로운 기능 추가가 “기존을 망가뜨리지” 않는가?
개인 메모: 유지보수성은 성능보다 뒤에 밀리기 쉽지만,
규모가 커질수록 “개발 속도” 자체를 결정한다.
5. 이 장의 결론: 좋은 데이터 시스템의 3요소
정리하면, 데이터 중심 시스템 설계의 핵심은:
- 신뢰성: 부분 장애가 전체 실패가 되지 않게
- 확장성: 부하를 수치로 정의하고, 꼬리 지연을 관리하며
- 유지보수성: 운영·단순성·발전성을 확보하는 것
그리고 중요한 전제:
- 이 세 가지는 항상 트레이드오프가 존재한다.
- 정답은 없고, “현재의 요구사항 + 미래의 변화”를 기준으로 선택해야 한다.
6. 내가 적용해볼 체크리스트
- 우리 서비스의 부하 파라미터(QPS/읽기쓰기 비율/데이터 크기)를 숫자로 말할 수 있나?
- 평균 latency 말고 p95/p99를 보고 있나?
- 장애가 났을 때 “어떻게 탐지하고, 어디서 복구하고, 얼마나 걸리는지”가 정의돼 있나?
- 구성 요소가 늘어나는 만큼 관측성과 운영 자동화가 따라가고 있나?
7. 한 줄 요약(5줄)
- 데이터 중심 앱은 여러 데이터 시스템이 엮인 “시스템”이다.
- 신뢰성은 fault를 전제로 failure를 막는 설계다.
- 확장성은 부하를 정의하고, 퍼센타일 지연을 관리하는 능력이다.
- 유지보수성은 운영성/단순성/발전성으로 설명된다.
- 결국 설계는 트레이드오프 선택이며, 요구사항을 수치화하는 게 시작점이다.
Leave a comment