다음 저장소를 만나도,
처음부터 배우지 않습니다.
Redis에서도 Kafka에서도 RDB에서도 따로 겪은 문제였는데, 알고 보면 같은 원리였습니다. 복제 지연, 핫 샤드, 쓰기 스큐, 캐시 정합성. 5주 뒤에는 처음 보는 데이터베이스 문서를 열고도 무엇부터 확인할지 알고, 면접과 설계 회의에서 무엇을 포기하고 무엇을 지킨 선택인지 본인 말로 답합니다.
교재는 『데이터 중심 애플리케이션 설계』입니다. 가장 많이 추천받고, 가장 적게 완독하는 책이에요. 혼자 읽으면 3장에서 덮게 되니 5주 동안 장애 장면에서 시작해 같이 되읽습니다.
- 5주 라이브, 10월 8일(목) 시작
약속, 저장, 분산, 진실, 파생 다섯 테마를 한 주에 하나씩 갑니다. 10월 8일, 15일, 22일, 29일, 11월 5일입니다.
- 목요일 저녁 8시부터 2시간, Zep
타자 치는 시간은 없습니다. 진행자가 도해와 워크스루를 끌고 참가자가 토론과 결정을 주도합니다.
- 읽고 와서 가설을 적고 라이브 뒤에 한 장으로 정리합니다
그 주 범위는 두세 장입니다. 라이브 전에는 결정 지점에 본인 답을 적어 내고 라이브 뒤에는 본인 서비스에 어떻게 적용할지 한 장으로 정리해 냅니다.
DB 한 대로 버티는 서비스에서, “이제 무엇을 어떻게 늘릴까”에 근거를 대는 개발자로 바뀌는 5주.
도구는 몇 년마다 바뀌고,
그 아래 원리는 그대로 남습니다.
장애 대응, 기술 선택 회의, 그리고 시스템 디자인 면접. 갈리는 순간은 늘 "무엇을 포기할지 정하는" 대목입니다. 필요한 판단력은 하나인데, 그게 없으면 매번 같은 데서 막힙니다. 5주 동안 매주 본인 이름으로 결정을 내려 봅니다.
- ✓복제본을 붙이는 순간 생기는 문제를 붙이기 전에 압니다
- ✓샤딩 키를 정하기 전에 어떤 키가 핫스팟을 만드는지 계산합니다
- ✓격리수준을 올려도 막히지 않는 결함이 무엇인지 먼저 확인합니다
- ✓캐시와 DB가 어긋나는 구조적 이유를 알고 이중 쓰기를 줄입니다
- ✓새 데이터베이스 문서를 열었을 때 무엇부터 확인할지 목록이 생깁니다
- ✓"강한 일관성"이라는 홍보 문구에서 실제 보장 범위를 가려냅니다
- ✓기술 선택 회의에서 "무엇을 포기하는 선택인지"를 먼저 말합니다
- ✓Redis · Kafka · RDB에서 따로 겪은 문제들이 같은 원리였다는 것이 보입니다
아는 단어가 늘어나는 게 아니라,
답변의 구조가 바뀝니다.
한 일을 보고하는 답에서, 무엇을 감수하고 무엇을 지켰는지 함께 말하는 답으로 옮겨갑니다.
“읽기를 복제본으로 분산해서 부하를 줄였습니다.”
“복제 지연이 사용자에게 보이기 시작했습니다. 글을 쓴 직후 본인 글이 안 보이는 문제라서, 본인이 쓴 데이터는 리더에서 읽도록 예외를 두고 나머지는 복제본으로 보냈습니다.”
“REPEATABLE READ로 두면 더 안전하니까요.”
“재고 차감에서 두 트랜잭션이 각자 조건을 확인하고 각자 쓰는 패턴이었습니다. 스냅숏 격리로는 이 쓰기 스큐가 막히지 않아서, 격리수준 대신 명시적 잠금으로 그 구간만 직렬화했습니다.”
왜 이 책을 같이 읽나요.
아래 네 질문에 근거를 대고 답할 수 있는지가 이 5주의 입구이자 출구입니다.
이 책은 답이 아니라 트레이드오프를 나열합니다. 결정해 본 적 없는 트레이드오프는 읽어도 남지 않습니다. 그래서 매주 책을 펴기 전에 장애 장면을 먼저 만나고 각자 판단을 적은 다음 책과 대조합니다. 내 판단이 틀렸던 지점이 남는 순서입니다.
서비스가 작을 때는 이 책의 내용이 대부분 과잉입니다. DB 한 대, 캐시 하나, 트랜잭션은 기본값이면 됩니다. 읽어도 지금 내 문제 같지 않습니다. 그게 3장에서 책을 덮는 진짜 이유입니다. 5주 동안은 각자 맡은 서비스의 장면을 계속 끌고 옵니다.
- ✓복제 지연이나 재고 마이너스를 겪어봤지만 왜 그렇게 되는지 설명하기 어려운 분
- ✓한 도구는 깊게 아는데 새 저장소 앞에서는 매번 처음부터 시작하는 기분이 드는 분
- ✓이 책을 혼자 펴봤다가 앞부분에서 덮은 적이 있는 분
책을 대신 요약해 주기를 기대하는 분에게는 맞지 않습니다. 읽고 오는 시간이 매주 필요합니다.
5주 커리큘럼.
테마 하나에 한 주씩 씁니다. 매주 그 주의 장면을 먼저 만난 뒤 각자 판단을 적고 마지막에 책과 대조합니다.
이 시스템은 무엇을 약속하는가
운영 시스템과 분석 시스템 · 클라우드와 자체 운영 · 신뢰성 · 확장성 · 유지보수성 · 부하 매개변수 · 응답 시간 백분위 · 관계형과 문서와 그래프 모델 · 질의 언어
- ·평균 응답이 200밀리초인데 고객이 느리다고 하는 이유를 백분위로 설명합니다
- ·사용자가 열 배가 될 때 무엇이 먼저 무너지는지 부하 매개변수로 지목합니다
- ·지금 쓰는 데이터 모델이 무엇을 얻고 무엇을 내준 선택인지 말로 옮깁니다
- ·2판이 첫 장에서 새로 가른 기록 시스템과 파생 데이터의 경계를 잡습니다
본인 서비스의 부하 매개변수와 응답 목표를 정의하고 지금 데이터 모델의 교환을 설명합니다
디스크 위에서 무슨 일이 일어나는가
로그 구조 저장소 · SSTable · LSM 트리 · B-tree · 쓰기 증폭 · 인덱스 비용 · 열 지향 저장 · 부호화 · 스키마 발전 · 상위 호환과 하위 호환
- ·로그 파일 하나에 덧붙이는 저장소부터 직접 설계해 보고 SSTable과 B-tree까지 갑니다
- ·인덱스를 걸었더니 쓰기가 느려진 이유를 자료구조로 설명합니다
- ·읽기에 유리한 저장소와 쓰기에 유리한 저장소가 어디서 갈리는지 봅니다
- ·필드 하나 추가에 배포 순서가 걸리는 이유를 호환성으로 정리합니다
지금 저장소가 읽기와 쓰기 중 무엇에 유리하게 설계됐는지 근거를 대고 스키마 변경 배포 순서를 정리합니다
데이터가 여러 대에 있을 때 생기는 일
단일 리더와 다중 리더와 리더 없는 복제 · 복제 지연 · 본인 쓰기 읽기 · 단조 읽기 · 인과 순서 · 페일오버 · 스플릿 브레인 · 샤딩 키 · 핫스팟 · 재조정
- ·내가 쓴 글이 새로고침하면 사라지는 장면을 복제 지연으로 설명하고 읽기 정책을 설계합니다
- ·댓글이 원글보다 먼저 보이는 경우와 시간이 거꾸로 가는 경우에 각각 어떤 보장이 필요한지 가릅니다
- ·리더가 죽었을 때 페일오버가 조용히 쓰기를 버리는 순간을 짚습니다
- ·키 범위 샤딩과 키 해시 샤딩의 교환, 그리고 샤드 하나가 계속 뜨거운 이유를 봅니다
복제 지연을 사용자 경험 기준으로 정의하고 어떤 읽기를 리더로 보낼지와 샤딩 키의 근거를 설명합니다
무엇을 사실로 믿을 수 있는가
ACID · 읽기 커밋 · 스냅숏 격리 · 쓰기 스큐 · 직렬성 · 명시적 잠금 · 부분 실패 · 신뢰할 수 없는 시계 · 프로세스 정지 · 펜싱 토큰 · 선형성 · CAP · 합의
- ·재고가 마이너스가 되는 쓰기 스큐가 스냅숏 격리로 막히지 않는 이유를 설명합니다
- ·격리수준을 등급이 아니라 무엇을 여전히 허용하는지 적은 목록으로 읽습니다
- ·서버 시계가 밀렸을 때 타임스탬프 순서와 잠금 만료가 어디서 무너지는지, 펜싱 토큰이 무엇을 대신하는지 봅니다
- ·선형성에 드는 비용과 CAP이 실제로 말한 것을 구분하고 합의가 꼭 필요한 지점을 긋습니다
트랜잭션과 합의가 필요한 구간을 직접 긋고 그 판단을 신뢰성과 확장성과 유지보수성의 교환으로 다시 짚습니다
같은 데이터를 여러 벌로 두는 기술
이중 쓰기 · 캐시 무효화 경합 · 변경 데이터 캡처 · 이벤트 소싱 · 멱등성 · 일괄 처리 · 스트림 처리 · 종단 간 정확성 · 정확히 한 번 · 데이터베이스 언번들링
- ·캐시를 지웠는데 옛 값이 보이는 경합을 이중 쓰기 구조로 설명합니다
- ·DB 변경을 검색 인덱스에 반영하는 경로를 변경 데이터 캡처로 다시 그립니다
- ·일괄 처리가 멱등성으로 무엇을 얻는지 보고 그 대가인 하루 지연을 언제 못 받아들이는지 가릅니다
- ·정확히 한 번이 결국 무엇이었는지 3주와 4주의 판단으로 되읽습니다
지금 서비스의 파생 데이터인 캐시와 인덱스와 집계를 원본에서 흐르는 단방향 경로로 다시 그린 뒤 어긋나는 지점을 지목합니다
장 번호는 원서 2판 기준입니다. 국내에 나온 번역서 『데이터 중심 애플리케이션 설계』(위키북스)는 1판이라 장 구성이 조금 다릅니다. 주차 자료에 1판 대응 장 번호를 같이 적어 드립니다. 번역서로 읽으셔도 같은 진도로 따라오시면 됩니다.
한 주가 이렇게 돕니다.
그 주 범위 두세 장을 읽습니다. 완벽히 이해하고 올 필요는 없습니다. 막힌 지점을 표시해 오는 편이 낫습니다. 그 주 결정 지점에 본인 답을 가설로 적어 라이브 전에 냅니다.
장면을 먼저 만나고 각자의 가설을 비교합니다. 책이 뭐라고 하는지 같이 읽은 뒤 우리 서비스로 돌아옵니다. 막힌 지점을 가져오시면 그 지점을 그날 교재로 씁니다. 진행자가 30퍼센트, 참가자가 70퍼센트를 맡습니다.
그 주에 본 트레이드오프를 본인 서비스 기준으로 어떻게 적용할지 한 장으로 정리해 냅니다. 동료의 정리에 코멘트를 남깁니다.
10월 8일 목요일에 시작합니다.
5주 라이브 참가비입니다. 책은 각자 준비하시면 됩니다. 책값은 참가비에 없습니다.
- ·첫 주 라이브가 시작되기 전이면 전액 돌려드립니다. 10월 8일 목요일 저녁 8시가 기준입니다.
- ·첫 주가 시작된 뒤에는 돌려드리지 않습니다. 다섯 주를 하나로 묶어 진행해서 중간에 끊어 계산하기 어렵습니다.
- ·사람이 모자라거나 저희 쪽 사정으로 기수를 못 열면 전액 돌려드립니다.
결제 옵션 불러오는 중…
- 10월 8일 (목)약속1 ~ 3장
- 10월 15일 (목)저장4 ~ 5장
- 10월 22일 (목)분산6 ~ 7장
- 10월 29일 (목)진실8 ~ 10장
- 11월 5일 (목)파생11 ~ 13장
매주 목요일 저녁 8시부터 10시까지 2시간, 메타버스 공간 Zep에서 모입니다. 정원은 15명입니다.
자주 묻는 질문.
책을 미리 다 읽어야 하나요?+
아닙니다. 매주 그 주 범위만 읽고 오시면 됩니다. 5주에 1장부터 13장까지 나눠 가니 한 주에 두세 장입니다. 완벽히 이해하실 필요도 없습니다. 어디서 막혔는지만 표시해 오십시오.
책은 주시나요?+
이번 권은 시판 도서를 교재로 씁니다. 각자 준비해 주십시오. 국내 번역서는 『데이터 중심 애플리케이션 설계』(마틴 클레프만, 위키북스)입니다. 주차 자료는 원서 2판(Designing Data-Intensive Applications, 2nd Edition, 마틴 클레프만 · 크리스 리코미니) 기준으로 만들고 번역서 1판의 대응 장 번호를 같이 적어 드립니다. 어느 쪽으로 읽으셔도 따라오실 수 있습니다.
혼자 읽는 것과 뭐가 다른가요?+
결정해 본 적 없는 트레이드오프는 읽어도 남지 않습니다. 여기서는 매주 장애 장면부터 만난 뒤 각자 판단을 적고 그 판단을 책과 맞춰 봅니다. 그 순서라야 내가 틀렸던 지점이 남습니다. 혼자서는 이 순서를 만들기 어렵습니다.
앞 기수를 안 들었는데 괜찮나요?+
괜찮습니다. 각 권을 따로 들으셔도 되게 짰습니다. 이번 권은 특정 도구가 아니라 그 아래 공통 원리를 보는 5주라서 시리즈에 처음 합류하셔도 무리가 없습니다.
다섯 번 다 참석하지 못할 것 같습니다.+
다섯 번 중 네 번 이상 나올 수 있을 때 신청해 주십시오. 매주 가설과 정리를 주고받는 구조라 한 주 빠지면 그 주 대조를 통째로 건너뜁니다.
환불이 되나요?+
첫 주 라이브가 시작되기 전이면 전액 돌려드립니다. 10월 8일 목요일 저녁 8시가 기준입니다. 첫 주가 시작된 뒤에는 돌려드리지 않습니다. 다섯 주를 하나로 묶어 진행하기 때문입니다. 사람이 모자라거나 저희 쪽 사정으로 기수를 못 열면 전액 돌려드립니다.
결제하면 어떻게 되나요?+
합류가 확정됩니다. 결제를 확인하는 대로 그릿 딥다이브 3기 오픈카톡방 초대 링크를 결제 완료 화면에서 바로 드립니다. 주차 자료와 Zep 입장 방법은 그 방에서 안내합니다. 정원 15명 선착순입니다.
5주 후 손에 남는 것은 완독 인증이 아니라,
처음 보는 데이터 시스템 앞에서도 질문이 서는 본인입니다.
10월 8일(목) 시작 · 매주 목요일 저녁 8시부터 2시간 · 5주 · 99,000원 · 정원 15명.
3기 합류하기 →