하루키의 법칙을 이행하는 개발자

이 글은 Kubernetes in Action 4장을 학습하면서 직접 실습한 내용을 정리한 시리즈의 1편입니다. 책으로만 읽으면 그냥 지나칠 만한 부분에서 일부러 막혀보고, 그 막힘을 통해 컨트롤러의 본질을 이해해가는 과정을 기록했습니다.들어가며쿠버네티스를 처음 공부할 때 RC(ReplicationController), RS(ReplicaSet), Deployment, DaemonSet 같은 컨트롤러들의 차이가 헷갈렸습니다. 책을 읽을 때는 "아 그렇구나" 싶지만, 실제로 운영하다 보면 "왜 이렇게 설계했지?"가 막히는 순간이 옵니다.이번 학습에서 제가 잡고 싶었던 건 컨트롤러 패턴의 본질이었습니다. 그래서 일부러 RC/RS의 한계까지 부딪혀보면서, 왜 셀렉터 기반 설계인지, 왜 Deployment가 R..

[DDIA 12장] 데이터 시스템의 미래 — 올바른 시스템을 만든다는 것Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다. 1장 | 2장 | 3장 | 4장 | 5장 | 6장 | 7장 | 8장 | 9장 | 10장 | 11장들어가며DDIA의 마지막 장이다.1장에서 신뢰성, 확장성, 유지보수성으로 시작한 여정이 여기까지 왔다. 스토리지 엔진, 분산 복제, 트랜잭션, 합의 알고리즘, 배치와 스트림 처리까지.12장은 기술적인 심화가 아니다. 지금까지 배운 모든 것을 올려놓고 더 높은 질문을 던진다."기술적으로 가능한 것"과 "올바른 것" 사이의 간격. 데이터 시스템이 현실 세계에 미치는 영향. 그리고 우리가 만드는 시스템이 어떤 세..

[DDIA 11장] 스트림 처리 — 이벤트가 발생하는 즉시 처리하기Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다. 1장 | 2장 | 3장 | 4장 | 5장 | 6장 | 7장 | 8장 | 9장 | 10장들어가며10장에서 배치 처리를 다뤘다. 데이터를 쌓아두고 한꺼번에 처리하는 방식. 강력하지만 본질적으로 "늦다". 어젯밤 로그를 오늘 아침에 집계하고, 오늘 구매 데이터를 내일 추천에 반영한다.그런데 세상은 점점 더 빠른 응답을 원한다. 결제가 완료되는 순간 이상 거래를 탐지하고 싶다. 사용자가 클릭하는 즉시 추천이 바뀌길 원한다. 서버 에러가 발생하는 그 순간 알람을 받고 싶다.배치로는 이게 안 된다. 스트림 처리(Str..

[DDIA 10장] 배치 처리 — MapReduce와 그 너머Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다. 1장 | 2장 | 3장 | 4장 | 5장 | 6장 | 7장 | 8장 | 9장들어가며1부와 2부는 주로 실시간 읽기/쓰기를 처리하는 시스템 — OLTP, 복제, 파티셔닝, 트랜잭션 — 을 다뤘다.3부는 다른 종류의 문제를 다룬다. 데이터를 실시간으로 처리하는 게 아니라 쌓아두고 한꺼번에 처리하는 방식이다.10장은 배치 처리(Batch Processing)다. 수억 건의 로그를 분석하거나, 전체 사용자 데이터를 가공해서 추천 모델을 만들거나, 일별 매출을 집계하는 작업들. 실시간이 아니어도 되지만 규모가 방대한 작업..

[DDIA 9장] 일관성과 합의 — 불확실한 분산 환경에서 정확성 보장하기Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다.1장 | 2장 | 3장 | 4장 | 5장 | 6장 | 7장 | 8장들어가며8장에서 분산 시스템의 불확실성을 배웠다. 네트워크는 패킷을 유실시키고, 클럭은 제멋대로 흐르고, 프로세스는 예고 없이 멈춘다. 이 모든 게 당연하다는 전제를 깔았다.그렇다면 이 혼돈 속에서 어떻게 올바른 시스템을 만들 수 있는가?9장은 그 답을 다룬다. 일관성 보장(Consistency Guarantees) 과 합의 알고리즘(Consensus Algorithms). 불확실성을 전제하면서도 시스템이 "올바르게 동작한다"는 것을 보..

[DDIA 8장] 분산 시스템의 골칫거리 — 네트워크, 클럭, 그리고 불확실성Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다.1장 | 2장 | 3장 | 4장 | 5장 | 6장 | 7장들어가며단일 서버에서 개발할 때는 당연하게 여겼던 것들이 있다.함수를 호출하면 결과가 온다. 시간은 단조롭게 흐른다. 메모리에 쓴 값은 바로 읽힌다. 실패하면 예외가 터진다.분산 시스템에서는 이 중 어느 것도 당연하지 않다.8장은 분산 시스템이 본질적으로 왜 어려운지를 다룬다. 특별히 나쁘게 설계해서가 아니라, 분산이라는 특성 자체가 단일 시스템에 없던 문제들을 만들어낸다. 이 장을 읽고 나면 분산 시스템을 설계할 때 왜 그렇게 조심해야 하는..

[DDIA 7장] 트랜잭션 — ACID는 실제로 무엇을 보장하는가Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다.1장 | 2장 | 3장 | 4장 | 5장 | 6장들어가며"트랜잭션 쓰면 ACID 보장됩니다."면접에서도, 실무에서도 자주 듣는 말이다. 그런데 ACID가 구체적으로 무엇을 보장하는지, 격리 수준이 왜 여러 단계로 나뉘는지, @Transactional 하나 붙인다고 모든 동시성 문제가 해결되는지 물어보면 대답이 흐릿해진다.7장은 트랜잭션의 가장 깊은 곳을 다룬다. ACID의 각 글자가 실제로 무엇을 의미하는지, 트랜잭션 없이 어떤 문제가 생기는지, 격리 수준마다 어떤 이상 현상을 허용하고 막는지를 낱낱이 설명한다..

[DDIA 6장] 파티셔닝 — 데이터를 여러 노드에 쪼개는 법Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다.1장 | 2장 | 3장 | 4장 | 5장들어가며5장에서 복제(Replication)를 다뤘다. 같은 데이터를 여러 노드에 복사해서 가용성과 읽기 성능을 높이는 방법이었다.그런데 데이터 자체가 너무 많으면 어떻게 될까? 수십억 건의 레코드, 수백 TB의 데이터를 한 노드에 담는 건 불가능하다. 쿼리 하나가 전체를 스캔해야 한다면 아무리 좋은 하드웨어도 한계가 있다.이때 필요한 게 파티셔닝(Partitioning) 이다. 데이터를 여러 조각으로 나눠 각각 다른 노드에 저장한다. 흔히 샤딩(Sharding) 이라고도 불..

[DDIA 5장] 복제 — 같은 데이터를 여러 노드에 유지하는 법Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다.1장 | 2장 | 3장 | 4장들어가며서비스가 커지면 DB를 한 대만 운영하기 어려워진다. 장애가 나면 서비스 전체가 멈추고, 트래픽이 몰리면 한 대로는 감당이 안 된다.자연스럽게 DB를 여러 대로 늘리는 생각을 하게 된다. 그런데 여러 대에 같은 데이터를 유지하는 건 생각보다 훨씬 어렵다. 쓰기가 발생했을 때 모든 노드에 동시에 반영하려면 어떻게 해야 하는가? 노드 하나가 죽으면 어떻게 되는가? 네트워크가 끊겼다가 다시 연결되면 데이터는 어떻게 맞추는가?5장은 이 문제를 다룬다. 복제(Replication) ..

[DDIA 4장] 인코딩과 발전 — 스키마가 바뀌어도 시스템은 살아있어야 한다Designing Data-Intensive Applications (Martin Kleppmann) 를 읽으며 정리한 시리즈입니다. 1장 보러가기 | 2장 보러가기 | 3장 보러가기들어가며배포할 때마다 드는 긴장감이 있다.DB 스키마를 바꿨거나, API 응답 필드를 추가했거나, 이벤트 메시지 포맷을 변경했을 때. 새 코드와 구 코드가 동시에 살아있는 그 짧은 순간 — 롤링 배포 중이거나, 아직 클라이언트가 업데이트되지 않은 상태 — 에 문제가 생기진 않을까 하는 불안.4장은 그 불안의 근원을 다룬다. 데이터가 어떻게 직렬화되는지, 스키마가 바뀌었을 때 하위 호환성을 어떻게 유지하는지, 그리고 여러 직렬화 포맷들이 이 문제를 어..