“트래픽이 10배 늘면요?”
5주 뒤, 이 질문에 답합니다.
대용량 경험 없는 주니어 백엔드를 위한 5주. 더 이상 이 질문에서 털리지 맙시다.
대용량 트래픽을 매일 운영하는 현직자가,
5주 동안 옆에서 같이 겪습니다.
- ✓현직 IT 대기업 백엔드 개발자. 대용량 트래픽 코어 시스템을 담당하고 운영합니다
- ✓서류에서 300번 넘게 떨어진 뒤, 1년 만에 작은 회사에서 IT 대기업으로 옮겼습니다
- ✓200명 넘게 멘토링했고, 인프런 평점 5.0을 지키고 있습니다
작은 회사에서 대용량을 다루는 회사로 가는 문턱을, 직접 넘어 본 사람이 진행합니다.
이직을 준비하다 한 번쯤,
여기서 멈췄을 겁니다.
자격 요건 "대용량 트래픽 처리 경험". 여기서 스크롤이 멈춥니다.
"Redis 캐시 적용." 왜 했는지 물으면 할 말이 없어서, 한 줄로 끝냈습니다.
"복제본에서 옛날 값이 보이면요?" 거기서부터 기억이 없습니다.
필독서라길래 『데이터 중심 애플리케이션 설계』를 샀습니다. 3장에서 덮었습니다.
큰 회사 개발자가 이 질문에 답하는 이유는 하나입니다.
장애를 먼저 겪어 봤습니다.
그 장애를 5주 동안 먼저 겪게 해 드립니다. 트래픽 큰 회사의 면접을, 겪어 본 사람처럼 치르게 됩니다.
대용량 질문은
면접에서 배점이 큰 문항입니다.
준비하고 들어가면 그날 최고점이 되고, 준비 없이 들어가면 그날 최대 감점이 됩니다.
아래 두 장면, 바로 답할 수 있나요?
“글을 올렸는데, 새로고침하니 제 글이 없어요.”
DB도 에러 로그도 멀쩡합니다. 지난주에 읽기 복제본을 붙였습니다. 몇 초 뒤에 다시 열어 보니 글이 있습니다.
새로고침했을 때 글은 왜 안 보였나요? 다시 안 생기게 하려면 무엇을 바꾸시겠나요?
“재고가 1개였는데 주문이 2건 들어갔어요.”
MySQL이고 트랜잭션도 걸었습니다. 격리 수준은 REPEATABLE READ입니다. 그런데 두 주문이 같은 순간에 재고 1을 읽었고, 둘 다 차감에 성공했습니다.
트랜잭션을 걸었는데 왜 뚫렸나요? 격리 수준을 올리는 것 말고 무엇을 하시겠나요?
여기서 말문이 막혔다면, 면접에서도 똑같이 막힙니다.
“회사 트래픽이 작아서”라는 말, 이 5주로 끝냅니다.
같은 질문,
5주 뒤에는 이렇게 답합니다.
같은 질문에 지금 흔히 하는 답과 5주 뒤에 하는 답을 나란히 놓았습니다.
“캐시를 붙이고 읽기 복제본을 늘리겠습니다.”
“먼저 읽기와 쓰기 중 어디가 막히는지 가르겠습니다. 읽기라면 복제본을 늘립니다. 그러면 방금 쓴 글이 안 보이는 복제 지연이 생기니, 방금 쓴 사용자만 잠깐 리더에서 읽게 하겠습니다.”
“트랜잭션을 걸고 격리 수준을 REPEATABLE READ로 두었습니다.”
“MySQL의 REPEATABLE READ에서 일반 SELECT는 잠금 없이 읽어서, 두 주문이 같은 재고 1을 보고 둘 다 차감합니다. 그래서 확인과 차감을 조건부 UPDATE 한 문장으로 합치고, 바뀐 행이 없으면 주문을 실패로 돌렸습니다.”
혼자 읽으면 아는 게 늘고,
같이 읽으면 할 말이 생깁니다.
책은 누구나 삽니다. 면접에서 차이는 그걸 내 말로 꺼낼 수 있느냐에서 납니다.
매주 내 판단을 말로 꺼내고 동료의 반박을 받습니다. 면접 전에 다섯 번 연습하는 셈입니다.
각자 회사와 프로젝트에서 겪은 장면을 가져와 같이 풉니다. 혼자서는 못 겪을 장애입니다.
한 주에 두세 장씩, 만날 사람이 있으니 5주 뒤 마지막 장까지 갑니다.
매주 내 서비스나 포트폴리오에 대입해 한 장으로 남깁니다. 이력서에 그대로 씁니다.
이런 분께 맞습니다.
- ✓이직을 준비하는데, 회사 트래픽이 작아 대용량 질문에 할 말이 없는 주니어 백엔드
- ✓캐시, 복제본, 트랜잭션을 써 봤지만 "왜요?"에서 막히는 분
- ✓이 책을 사 두고 앞부분에서 덮은 분
- ✗대규모 분산 시스템을 이미 운영하면서 이 책을 두 번 넘게 읽은 분. 5주가 얕게 느껴질 겁니다
- ✗책을 대신 요약해 주는 강의를 기대하는 분. 매주 읽고 와서 본인 답을 적어야 합니다
5주 동안,
면접 단골 질문 다섯 개를 끝냅니다.
주차마다 현업 장면 하나로 시작해, 그 질문에 답할 수 있게 만듭니다.
사용자가 10배로 늘면, 무엇이 먼저 무너지나
→ "10배 늘면 어디부터 무너지나요?"에 순서를 대고 답합니다
이번 주 자세히 보기 +
- ·평균 응답이 200밀리초인데 고객이 느리다고 하는 이유를 백분위로 설명합니다
- ·사용자가 10배가 될 때 무엇이 먼저 무너지는지 부하 기준으로 지목합니다
- ·지금 쓰는 데이터 모델이 무엇을 얻고 무엇을 내준 선택인지 말로 옮깁니다
본인 서비스가 10배가 되면 먼저 무너질 곳과 그 근거를 한 장에 적습니다
신뢰성 · 하드웨어 결함과 소프트웨어 오류와 인적 오류 · 확장성 · 부하 기술하기 · 응답 시간 백분위 · 유지보수성 · 관계형 모델과 문서 모델 · 다대일과 다대다 관계 · 그래프형 데이터 모델 · 질의 언어
인덱스를 걸었더니, 왜 쓰기가 느려졌나
→ "인덱스를 더 걸면 되지 않나요?"에 쓰기 비용으로 답합니다
이번 주 자세히 보기 +
- ·로그 파일 하나에 덧붙이는 저장소부터 직접 설계해 보고 B 트리까지 갑니다
- ·인덱스를 걸면 쓰기가 느려지는 이유를 자료구조로 설명합니다
- ·필드 하나 추가에 배포 순서가 걸리는 이유를 호환성으로 정리합니다
지금 저장소가 읽기와 쓰기 중 무엇에 유리한지 근거를 대고 스키마 변경 배포 순서를 정리합니다
해시 색인 · SS테이블과 LSM 트리 · B 트리 · 쓰기 증폭 · 보조 색인 · 트랜잭션 처리와 분석 · 칼럼 지향 저장소 · 부호화 · 스키마 발전 · 상위 호환과 하위 호환 · 데이터플로 모드
방금 쓴 글이, 왜 새로고침하면 사라지나
→ "읽기 복제본 붙이면 끝인가요?"에 복제 지연까지 답합니다
이번 주 자세히 보기 +
- ·내 글이 새로고침하면 사라지는 장면을 복제 지연으로 설명하고 읽기 정책을 설계합니다
- ·리더가 죽었을 때 페일오버가 조용히 쓰기를 버리는 순간을 짚습니다
- ·데이터를 나눠 담았는데 한 서버만 계속 뜨거운 이유와 나누는 기준을 정합니다
어떤 읽기를 리더로 보낼지와 데이터를 나누는 기준을 사용자 경험 기준으로 설명합니다
리더와 팔로워 · 다중 리더 복제 · 리더 없는 복제 · 복제 지연 · 자신이 쓴 내용 읽기 · 단조 읽기 · 일관된 순서로 읽기 · 노드 중단 처리 · 스플릿 브레인 · 파티셔닝 · 핫스팟 · 재균형화
트랜잭션을 걸었는데, 왜 재고가 마이너스인가
→ "동시성은 어떻게 막았나요?"에 격리 수준이 못 막는 곳까지 답합니다
이번 주 자세히 보기 +
- ·재고가 마이너스가 되는 동시 쓰기를 REPEATABLE READ가 왜 못 막는지, 어느 격리 수준부터 막히는지 설명합니다
- ·격리 수준마다 무엇을 여전히 허용하는지 목록으로 정리합니다
- ·서버 시계가 밀렸을 때 분산 락이 어디서 무너지는지 봅니다
트랜잭션과 락이 꼭 필요한 구간을 직접 긋고 그 이유를 적습니다
ACID · 커밋 후 읽기 · 스냅숏 격리 · 갱신 손실 · 쓰기 스큐와 팬텀 · 직렬성 · 부분 장애 · 신뢰성 없는 시계 · 프로세스 중단 · 펜싱 토큰 · 선형성 · CAP · 합의
캐시를 지웠는데, 왜 옛날 값이 보이나
→ "캐시 정합성은요?"에 DB와 캐시가 어긋나는 구조로 답합니다
이번 주 자세히 보기 +
- ·캐시를 지웠는데 옛 값이 보이는 경합을 DB와 캐시에 따로 쓰는 구조로 설명합니다
- ·DB 변경을 검색 인덱스와 캐시에 반영하는 길을 한 방향으로 다시 그립니다
- ·"정확히 한 번"이 결국 무엇이었는지 3주와 4주의 판단으로 되읽습니다
캐시와 인덱스와 집계가 원본에서 어떻게 흘러야 어긋나지 않는지 본인 서비스로 다시 그립니다
일괄 처리 워크플로의 출력 · 스트림 처리 · 시스템 동기화와 이중 쓰기 · 변경 데이터 캡처 · 이벤트 소싱 · 멱등성 · 정확히 한 번 · 데이터베이스 언번들링 · 종단 간 논증
퇴근 후 목요일 저녁,
한 주가 이렇게 돕니다.
두세 장 읽고, 막힌 곳과 내 판단 한 줄을 적어 옵니다.
Zep에서 소그룹으로 판단을 비교하고 책과 맞춰 봅니다. 말하는 시간의 70퍼센트가 참가자 몫입니다.
내 서비스에 어떻게 쓸지 한 장으로 정리합니다. 5주면 다섯 장이 남습니다.
최소 6명이 모이면 오픈 카톡방에서 알리고, 그 다음 주 목요일부터 5주 진행합니다. 매주 목요일 저녁 8시부터 10시까지입니다.
먼저 해 본 1기가
주차마다 남긴 말입니다.
그릿 딥다이브 1기(Redis) 주간 피드백 중 공개에 동의한 답변입니다. 이름은 뺐습니다.
“궁금한 것만 결과에서 원인을 거슬러 찾았는데, 원인에서 결과로 내려오는 것도 재밌습니다.”
검색으로 답부터 찾던 순서가 뒤집힙니다.
“Redis는 싱글 스레드이면서 멀티 스레드입니다.”
외워 둔 한 줄이 어디까지 맞는지 따지기 시작합니다.
큰 회사 개발자도 들어가서 대용량을 처음 겪었습니다.
먼저 공부한 사람이 먼저 뽑혔을 뿐입니다.
최소 6명이 모이면 시작합니다.
정원은 15명입니다.
결제하시면 3기 오픈 카톡방에 모입니다. 6명이 되면 그 방에서 알려 드리고, 그 다음 주 목요일 저녁 8시에 1주차를 엽니다.
한 번에 2만 원이 안 됩니다. 책은 각자 준비하시고, 책값은 참가비에 없습니다.
- ·첫 라이브가 시작되기 전이면 6명이 모이기 전이든 뒤든 언제든 전액 돌려드립니다.
- ·첫 라이브가 시작된 뒤에는 돌려드리지 않습니다.
- ·저희 사정으로 기수를 못 열면 전액 돌려드립니다.
결제 옵션 불러오는 중…
자주 묻는 질문.
무료 DDIA 스터디와 뭐가 다른가요?+
진행자가 대용량 트래픽 코어 시스템을 운영하는 현직자입니다. 돌아가며 책을 발표하는 대신, 진행자가 고른 현업 장애 장면부터 풀고 책과 맞춰 봅니다. 매주 내 판단을 말하고 현직자의 질문을 받습니다.
대용량 트래픽을 겪어 본 적이 전혀 없는데 따라갈 수 있나요?+
그런 분을 위해 짰습니다. 매주 장면은 트래픽이 커지면 어느 서비스에서나 생기는 일이고, 필요한 것은 지금 맡고 있는 서비스 하나뿐입니다. 그 서비스를 기준으로 매주 판단을 적습니다.
운영하는 서비스가 없는 신입이나 SI 개발자도 괜찮나요?+
괜찮습니다. 운영 서비스가 없으면 포트폴리오 프로젝트를 기준으로 판단을 적으시면 됩니다. 재고 차감이나 게시판 같은 흔한 프로젝트가 오히려 매주 장면과 가장 잘 맞습니다.
면접 준비에 도움이 되나요?+
시스템 디자인 면접과 꼬리질문이 묻는 것이 결국 이 책의 주제입니다. 모범 답안을 외우는 대신 본인 서비스 기준으로 근거를 만들고, 그 근거가 그대로 면접 답이 됩니다.
책을 미리 다 읽어야 하나요?+
아닙니다. 매주 그 주 범위만 읽고 오시면 됩니다. 5주에 1장부터 12장까지 나눠 가니 한 주에 두세 장입니다. 다 이해하실 필요도 없습니다. 어디서 막혔는지만 표시해 오십시오.
책은 주시나요?+
이번 권은 시판 도서를 교재로 씁니다. 각자 준비해 주십시오. 교재는 번역서 『데이터 중심 애플리케이션 설계』(마틴 클레프만, 위키북스)이고 장 번호도 이 책 기준입니다. 원서 2판으로 읽으셔도 따라오실 수 있게 2판 장 번호를 같이 적어 드립니다.
혼자 읽는 것과 뭐가 다른가요?+
혼자 읽으면 아는 것이 늘어납니다. 여기서는 매주 내 판단을 말로 꺼내고, 동료의 반박을 받고, 책과 맞춰 봅니다. 면접에서 쓰는 것은 그렇게 한 번 말해 본 판단입니다.
다섯 번 다 참석하지 못할 것 같습니다.+
다섯 번 중 네 번 이상 나올 수 있을 때 신청해 주십시오. 매주 판단과 정리를 주고받는 구조라 한 주 빠지면 그 주 대조를 통째로 건너뜁니다.
언제 시작하나요?+
최소 6명이 모이면 시작합니다. 결제하신 분들은 3기 오픈카톡방에 모이고, 6명이 되면 그 방에서 알려 드립니다. 알린 다음 주 목요일 저녁 8시에 1주차를 열어 5주 진행합니다. 첫 라이브가 시작되기 전이면 6명이 모이기 전이든 뒤든 언제든 전액 환불됩니다.
결제하면 어떻게 되나요?+
합류가 확정됩니다. 결제 완료 화면에서 그릿 딥다이브 3기 오픈카톡방 초대 링크를 바로 드립니다. 시작 안내와 주차 자료, Zep 입장 방법은 그 방에서 드립니다. 정원은 15명입니다.
“트래픽이 10배 늘면요?”
다음 면접에서는 답하고 나옵니다.
최소 6명 모이면 시작 · 매주 목요일 저녁 8시 · 5주 · 99,000원 · 정원 15명
3기 합류하기 →