Part 1. 데이터 시스템의 기초
Chapter 01. 신뢰할 수 있고 확장가능하며 유지보수하기 쉬운 애플리케이션
오늘날의 많은 애플리케이션은 데이터 중심적이다 -> 데이터 양, 데이터 복잡도, 데이터의 변화속도 때문
- 필요한 데이터 저장소로는…
- 데이터 베이스 - 애플리케이션에서 데이터 저장 및 검색 용도
- 캐시 - 읽기 속도 향상 목적
- 검색 색인 - 데이터 검색 혹은 필터링에 사용
- 스트림 처리 - 데이터에 대한 비동기 처리
- 배치 처리 - 주기적으로 대량의 데이터 분석 및 처리
애플리케이션마다 요구사항이 달라서, 데이터베이스 시스템마다 다양한 특성을 지닌다.
DB, 큐, 캐시 마다 전부 다른 패턴 및 성능 지니고, 구현 방식 다른데 모두 “데이터 시스템”이라고 부르는 이유?
데이터 저장과 처리를 위한 여러 새로운 도구는 최근에 만들어짐 또한 많은 애플리케이션이 과도하고 광범위한 요구사항 지님 개발자는 애플리케이션 개발자 뿐만 아니라 데이터 시스템 설계자 이기도 함
1. 신뢰성
무언가 잘못 되더라도 지속적으로 올바르게 동작함. (몇개 서버 죽어도 동작) Fault를 예측하고 대처할 수 있는 시스템을 내결함성 / 탄력성(resilient)를 지녔다고 말한다. Failure는 Fault와 다른 말로, 시스템 전체가 멈춘 경우를 의미 이책에서는 신뢰할 수 없는 여러 부품으로 신뢰할 수 있는 시스템을 구축하는 다양한 기법 다룸 넷플릭스는 카오스 몽키 이용하여 고의적으로 결함 유도하고 테스트 함.
하드웨어 결함
하드웨어 구성 요소에 중복을 추가하는 방법 사용. 장애 발생시 매우 빠르게 복원하는 방법으로 대응 소프트웨어 내결함성 기술을 사용하거나, 하드웨어 중복성을 추가해 전체 장비의 손실을 견딜 수 있는 시스템으로 옮겨가는 중
소프트웨어 오류
소프트웨어의 오류 문제는 신속한 해결책은 없고, 테스트 잘짜고, 프로세스 격리하고, 재시작 허용하고, 모니터링 분석 등으로 해결
인적 오류
오류 가능성 최소화 하는 방향으로 설계하거나, 휴먼에러 발생할 수 있는 부분 분리하거나, 테스트 철저히 하거나, 오류 복구 빠르게 되도록 하거나, 모니터링 대첵을 잘 마련하는 등으로 대응
2. 확장성
확장성은 증가한 부하에 대처하는 시스템 능력을 사용하는데 사용 확장성을 논할때는 시스템이 특정 방식으로 커지면 이에 대처하기 위한 선택은 무엇인가? 추가 부하를 다루기 위한 계산 자원은 어떻게 투입할까? 등의 질문 고려하는것
부하 기술하기
load parameter 로 나타낼 수 있다. 예시로 throughput, qps, active user, cache rate 등등 트위터 사례의 겨우 사용자당 팔로워 분포가 팬아웃 부하를 결정하기 때문에 확장성 논의시 핵심 부하 매게변수가 된다 트위터의 경우는 하이브리드 형태로 문제를 해결했다 (팔로우가 매우 많은 유명인사는 팬아웃에서 제외되고, 나머지는 읽는 시점에 사용자 홈 타인라인에 합침)
성능 기술하기
처리량: 초당 처리할 수 있는 레코드 수나 일정 크기의 데이터 집합 응답시간: 클라이언트가 요청 보내고 응답 받는 사이의 시간 (요청 실제 처리 시간 + 네트워크 지연 + 큐지연 모두 포함)
지연시간: 요청이 처리되길 기다리는 시간
응답시간은 단일 숫자가 아니라 측정가능한 값의 분포로 생각해야 한다. -> 그래서 백분위로 표시 p95, p999, p999 꼬리 지연시간: 상위 백분위 응답 시간은 서비스 사용자 경험에 직접 영향을 주기 때문에 중요 (예를들어 많이 구매한 유저라 처리가 오래 걸리는것)
백분위는 SLO와 SLA에 자주 사용하고, 기대 성능과 서비스 가용성을 정의하는 계약서에도 자주 등장 (예시 - p50이 200ms, p99가 1000ms 미만) 선두차단(head of line blocking) - 소수의 느린 요청 처리만으로 후속 요청 처리가 지체됨
부하 대응 접근방식
수직확장, 수평확장 다수의 장비에 부하 분산하는 아키텍처를 shared nothing architecture라 부름 탄력적 시스템은 부하 예측 어렵고 많은 경우 유용하지만, 수동 확장 시스템이 운영이 편리 Stateful 데이터 시스템 분산 처리는 많은 복잡도가 추가적으로 발생한다 특정 애플리케이션에 적합한 확장성을 갖춘 아키텍처는 주요 동작이 무엇이고 잘 하지 않는 동작이 무엇인지에 대한 가정을 바탕으로 구축된다
3. 유지보수성
소프트웨어 비용의 대부분은 초기 개발이 아니라 지속해서 이어지는 유지보수에 들어간다 유지보수 중 고통을 최소화하고 레거시 소프트웨어를 만들지 않게끔 소프트웨어를 설계해야 한다
운용성 - 운용의 편리함
운영중 일부를 자동화 해야 한다 시스템 상태 모니터링, 문제 원인 추적, 플랫폼 최신상태 유지, 시스템간 상관관계 파악, 발생가능한 문제 예측, 배포 설정 관리, 유지보수 테스크 진행 등 좋은 운영성이란 동이라헥 발생되는 태스크를 쉽게 수행하게끔 만드는것 좋은 모니터링, 표준도구 이용, 장비 의존성 회피, 좋은 문서, 기본 셋팅 잘해놓고 커스터마이즈 가능하게 등등
단순성 - 복잡도 관리
복잡도를 제거하기 위한 최고의 도구는 추상화로, 추상화를 잘 하면 많은 세부 구현은 숨길 수 있다
발전성 - 변화를 쉽게 만들기
이 책에서는 다양한 애플리케이션이나 다른 특성을 가진 서비스로 구성된 대규모 데이터 시스템 수준에서 민첩성을 높이는 방법을 찾는다