1장의 메인 소재
1장에서는 "데이터 시스템"에 대하여 정의를 하고, 좋은 데이터 시스템을 어떻게 설계할 수 있을지에 대해 이야기하고자 합니다. 이때 아키텍처를 설계할 때의 중요한 3개의 관심사 신뢰성, 확장성, 유지보수성에 대해 소개합니다.
데이터 시스템이란
하둡, 스파크와 같은 데이터 분석에 활용되는 시스템을 말하는 것이 아닙니다.
이 책에서는 요새 애플리케이션이 복잡하거나 오래 걸리는 계산 중심이 아닌 데이터를 읽고 저장하는 기능이 핵심인 데이터 중심적이라고 이야기 합니다.
데이터베이스와 메시지 큐는 데이터를 저장한다는 점에서 표면적으로는 비슷하지만, 서로 다른 특성이 있기 때문에 구현 방식이 상당히 다릅니다. 그럼에도 불구하고 이 책에서는 이 모든 것을 데이터 시스템이라는 용어로 묶습니다.
전통적으로는 "데이터베이스"가 모든 데이터의 읽기와 쓰는 것을 담당하는 데이터 시스템이었습니다.
그러나, 캐싱, 스트리밍, 큐 등 다양한 도구들이 최근에 만들어져 각 사용 사례에 최적화되었기 때문에 이제 데이터베이스 뿐 아니라, 데이터베이스 외에도 이 다양한 도구들을 일종의 데이터 시스템으로 봐야한다고 말하고 있습니다.
소프트웨어 시스템의 중요한 관심사 3가지
신뢰성(Reliability)
:어떤 역경이 있어도 사용자의 기대에 맞게 동작해야 한다.
결함(fault)이 있어도 올바른 응답을 해야 합니다. 이 결함을 예측하고 대응을 할 수 있는 것을 내결함성(fault-tolerant)혹은 탄력성(resilient)를 지녔다라고 합니다.
결함은 장애(failure)와 다릅니다. 결함은 사양에서 벗어난 시스템의 한 구성 요소로 정의되지만, 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 것입니다. GPT한테 결함과 장애의 예시를 들어주라고 했더니 아래와 같이 대답해주었습니다.
GPT의 대답: 핵심은 결함(Fault)은 원인이고, 장애(Failure)는 결과라는 것입니다.
예를 들어서 DB 3대를 복제해서 primary-replica 구조를 가지고 있다고 가정해봅시다. 이때 DB 1대가 죽었습니다. 이것은 원인입니다. 이것은 결함입니다. 하지만 나머지 2대가 계속 응답을 하기 때문에 서버는 정상 동작을 합니다. 따라서 이 상황은 장애가 아닙니다.
반대로 DB 1대에서 죽어버린다면 이는 곧 장애가 되는 것이지요.
---
또는 Redis가 죽었습니다. Redis가 죽었을 때 모든 응답이 반환되지 않는다면 이는 장애입니다. 하지만 Redis가 죽었을 때 DB로 직접 조회하도록(Fallback) 설계되어있었다면 정상응답을 합니다. 즉 이는 결함이지 장애는 아닙니다.
즉, 결함은 언제든 발생할 수 있지만, 시스템을 어떻게 설계했느냐에 따라 장애가 될 수도 있고, 되지 않을 수도 있습니다.
확장성 (Scalablility)
:부하가 증가해도 좋은 성능을 유지하기 위한 전략을 의미합니다.
부하에 대해 고민하기 위해서는 이 부하를 수치화 할 수 있는 부하 매개변수가 필수적입니다.
예를 들면 데이터베이스의 읽기 대 쓰기 비율, 대화방의 동시 활성자 사용자 수, 캐시 적중률이 될 수 있습니다. 이때 평균적인 경우가 중요할 수도 있고 소수의 극단적인 경우가 병목 현상의 원인일 수 있습니다. 결국 각 상황에 적절한 지표를 선택할 수 있어야 할 것입니다.
예를 들어 "트위터는 초당 4.6k 쓰기가 발생하고 초당 300k 읽기가 발생한다." 라는 읽기/쓰기 수치 및 비율이 부하 매개변수가 될 수 있습니다. 이런 경우 쓰기가 상대적으로 읽기 작업보다 초당 발생 건수가 적으니까, 둘 중 한 곳에 부하가 추가되어야 한다면 쓰기 작업에 부하를 추가하는게 올바른 선택이 될 것입니다.
키워드로는 다양한게 있습니다:
- 처리량(throughout): 하둡 같은 일괄 처리 시스템에서 사용, 초당 처리 가능 레코드 수
- 응답 시간(response time): 클라이언트가 요청을 보내고 응답을 받는 사이의 시간
- p95, p99 (백분위 95, 99): 백분위(percentile) 기준 95% 지점의 수치. 예를 들어 p95가 1.2초라면 요청의 95%는 1.2초 안에 응답이 왔다. 나머지는 1.2초보다 더 걸렸다.
- 꼬리 지연 시간 (tail latency): 백분위 기준 가장 느린 응답들. 아마존은 99.9분위까지의 시간 요구사항을 작성한다고 한다. (1000개의 요청 중 1개)
유지보수성 (Maintainability)
주의를 기울여야 할 소프트웨어 시스템 설계 방식
1. 운용성(operability): 운용팀이 시스템을 원할하게 운영할 수 있도록 쉽게 만들어라.
2. 단순성(simplicity): 시스템 복잡도를 최대한 제거해 새로운 엔지니어가 쉽게 시스템을 이해할 수 있도록 만들어라.
3. 발전성(evolvability): 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 해라.
마무리
저는 안정적인 시스템을 설계하는데 관심이 많습니다. 그렇기 때문에 개발할 때 항상 고가용성, 확장성 등을 고민하는 했습니다. 근데 항상 설계를 하면서도 이게 맞나? 여기서는 오류가 날 수 있지 않나? 이런 의문이 많이 들었습니다.
이 책에서 제 갈증을 해소할 수 있을 것 같가 기대가 많이 됩니다.
이 책을 읽고나서 신뢰성, 확장성, 유지보수성을 고민할 줄 아는 개발자가 되도록 열심히 공부해야할 것 같습니다 ㅎㅎ