조용한 개발 노트

CAP 이론을 아는 것과, 선택하는 것은 다르다CAP 이론은 분산 시스템을 다루는 사람이라면 누구나 한 번쯤 접한다. Consistency, Availability, Partition tolerance 중 두 가지만 선택할 수 있다는 설명은 잘 알려져 있다.하지만 실제 시스템에서 중요한 질문은 이것이 아니다.지금 이 순간, 이 요청에 대해 무엇을 포기할 것인가이 글에서는 CAP을 이론으로 설명하지 않는다. 실제 시스템이 어떤 상황에서 어떤 선택을 강요받는지를 중심으로 살펴본다.Partition은 선택이 아니라 전제다CAP을 오해하게 만드는 가장 큰 이유는 Partition을 마치 선택지처럼 받아들이기 때문이다.현실의 분산 시스템에서 Partition은 다음과 같은 형태로 항상 발생한다.네트워크 지연패킷 ..

MongoDB를 쓰다 보면 다른 데이터베이스에서는 거의 보지 못한 개념을 마주한다.Read Concern, Write Concern.이 둘은 단순한 옵션이 아니다. MongoDB가 정합성과 내구성의 판단을 시스템이 아닌 애플리케이션과 공유하기로 한 설계 선택을 가장 노골적으로 드러내는 인터페이스다.MongoDB는 “기본값”을 단순 상수로 두지 않는다많은 데이터베이스는 기본 Write Concern을 하나의 고정값으로 둔다.MongoDB는 그렇지 않다.MongoDB는 전역 기본값을 명시하지 않은 경우, Replica Set의 토폴로지를 보고 기본 Write Concern을 계산한다.이를 MongoDB 공식 문서에서는 Implicit Default Write Concern(IDWC)이라고 부른다.암시적 기본..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경10편에서 Pod 재시작은 실패가 아니라 정상적인 복구 메커니즘이라는 관점을 다뤘다.이번 편에서는 그 재시작보다 한 단계 위에서 벌어지는 일, Node 장애와 Pod Eviction을 살펴본다.운영 중에 이런 상황을 본 적이 있을 것이다.특정 Pod들이 한꺼번에 사라진다재시작 이유가 명확하지 않다애플리케이션 로그에는 아무 흔적이 없다이 현상의 배경에는 대부분 Node 단위의 문제가 있다.Kubernetes에서 Node는 “안정적인 전제”가 아니다전통적인 서버 운영에서는 이런 전제가 암묵적으로 깔려 있었다.서버는 웬만하면 살아 있다Kubernetes에서는 이 전제가 성립하지 않는다.Node는 언제든 사라질 수 있는 자원이다.클라우드 인..

Kubernetes 환경에서 Spring Boot 서버의 초기 레이턴시를 줄이기 위해 warm-up이나 readiness 지연 전략을 도입하는 경우가 많습니다.실제로 웜업은,JVM JIT 워밍업Spring Bean / AOP 초기화DB 커넥션 풀 준비와 같은 문제를 완화하는 데 효과적인 수단이기도 합니다.하지만 운영 환경에서는, 이 웜업 전략이 오히려 가용성을 떨어뜨리거나 장애를 키우는 원인이 되는 경우도 적지 않습니다.이 글에서는,웜업이 실제로 문제가 되는 상황왜 그런 문제가 발생하는지실무에서는 어떻게 대응하는 게 안전한지를 운영 관점에서 정리해봅니다.1. 웜업이 문제가 되는 대표적인 상황들① 웜업 자체가 너무 무거운 경우웜업 단계에서 다음과 같은 작업을 수행하는 경우가 있습니다.복잡한 조인 쿼리 실행..