Code, trends, and lessons learned
서론 이전 글에서 ThreadLocal과 MDC가 어떻게 Tracing Context를 저장하고 전파하는지 살펴봤습니다. 동기 환경에서는 “한 요청 = 한 스레드”라는 단순한 모델 덕분에 ThreadLocal만으로도 충분했습니다. 하지만 Spring WebFlux로 넘어오면 상황이 완전히 달라집니다. WebFlux는 소수의 스레드가 수천 개의 요청을 동시에 처리하는 Event Loop 모델을 사용합니다. 하나의 요청이 처리되는 동안 스레드가 수시로 바뀔 수 있죠. 이 환경에서 ThreadLocal은 더 … 더 읽기
왜 ThreadLocal을 알아야 할까? 1편에서 Distributed Tracing의 핵심이 Trace Context 전파라는 것을 살펴봤습니다. 서비스 간에는 HTTP 헤더(W3C Trace Context, B3)로 전파하면 되지만, 한 가지 의문이 남습니다. “서비스 내부에서는 Trace Context가 어디에 저장되어 있을까?” Spring MVC 애플리케이션에서 요청이 들어오면 Controller → Service → Repository를 거치는 동안 traceId와 spanId는 어딘가에 보관되어야 합니다. 매번 파라미터로 넘기는 건 비현실적이니까요. … 더 읽기
서론 “이 API 왜 이렇게 느려요?” MSA 환경에서 이 질문에 답하려면, 요청이 어떤 서비스를 거쳐 어디서 시간을 소비했는지 추적해야 합니다. 서비스가 3개일 때는 로그를 뒤져가며 찾을 수 있지만, 수십 개의 서비스가 얽혀있다면? Distributed Tracing 없이는 사실상 불가능합니다. 이 글에서는 Distributed Tracing이 왜 필요한지, OpenTelemetry가 어떻게 업계 표준이 되었는지, 그리고 Spring Boot 생태계에서는 어떤 선택지가 있는지 … 더 읽기
들어가며 이전 글에서는 Kubernetes 볼륨의 개념과 PV, PVC, StorageClass, CSI 드라이버의 동작 원리를 살펴봤습니다. 이번 글에서는 실전 활용과 운영에 초점을 맞춥니다: AccessModes: 누가 어떻게 접근할 수 있나? “다른 Pod에서도 이 볼륨을 쓸 수 있나요?”라는 질문의 답은 AccessMode에 달려 있습니다. 세 가지 AccessMode AccessMode 약어 의미 ReadWriteOnce RWO 단일 노드에서 읽기/쓰기 ReadOnlyMany ROX 여러 노드에서 읽기 … 더 읽기
들어가며 이전 글에서는 Kubernetes에서 Pod가 어떻게 생성되고 실행되는지 살펴봤습니다. Scheduler가 노드를 선택하고, kubelet이 컨테이너를 실행하는 과정을 알게 됐죠. 그런데 한 가지 문제가 있습니다. Pod가 죽으면 그 안의 데이터도 함께 사라집니다. 데이터베이스를 Pod로 운영한다고 생각해보세요. Pod가 재시작될 때마다 데이터가 날아간다면 서비스가 될 수 없겠죠. 그래서 Kubernetes는 Pod의 라이프사이클과 독립적인 영구 저장소(Persistent Storage)를 제공합니다. 이 글에서는 다음 … 더 읽기
들어가며 이전 글에서는 Kubernetes 클러스터 내부에서 Pod끼리 어떻게 통신하는지 살펴봤습니다. CNI 플러그인이 네트워크를 구성하고, CoreDNS가 서비스 디스커버리를 담당한다는 것을 알게 됐죠. 그런데 그 Pod는 애초에 어떻게 생성되고 실행되는 걸까요? kubectl apply -f deployment.yaml을 실행하면 마법처럼 Pod가 생성됩니다. 하지만 그 사이에는 여러 구성요소가 협력하는 복잡한 과정이 있습니다. 이 글에서는 다음 질문들에 답합니다: 전체 그림: 컨트롤 플레인과 … 더 읽기
들어가며 이전 글에서는 외부 사용자의 요청이 어떻게 Kubernetes 클러스터 내부의 Pod까지 도달하는지 살펴봤습니다. 외부 LB → NodePort → Ingress Controller → Service → Pod 으로 이어지는 흐름이었죠. 그런데 한 가지 의문이 남습니다. 클러스터 내부에서 Pod끼리는 어떻게 통신할까요? 예를 들어, 주문 서비스 Pod이 사용자 서비스 Pod의 API를 호출할 때 실제로 어떤 일이 벌어질까요? 이 글에서는 다음 … 더 읽기
서론 Kubernetes를 사용하다 보면 “내 요청이 정확히 어떤 경로로 Pod까지 도달하는 걸까?”라는 의문이 생깁니다. kubectl apply로 Ingress와 Service를 배포하면 마법처럼 트래픽이 흘러가지만, 문제가 생겼을 때 어디를 봐야 할지 막막해지는 경험을 해보셨을 겁니다. 이 글에서는 외부 사용자의 HTTP 요청이 Kubernetes 클러스터 내부의 Pod까지 도달하는 전체 과정을 단계별로 분석합니다. 각 구간에서 어떤 컴포넌트가 어떤 역할을 하는지, 그리고 … 더 읽기
흩어진 메트릭을 한 화면에 Part 1에서 기본 모니터링과 CPU 알람을, Part 2에서 CloudWatch Agent로 메모리/디스크 모니터링을 설정했습니다. 이제 CPU, 메모리, 디스크, 네트워크 메트릭을 수집하고 있지만 확인하려면 여기저기 클릭해야 합니다. 이번 글에서는 CloudWatch 대시보드로 모든 메트릭을 한 화면에 정리하고, CloudWatch Logs로 서버 로그까지 수집해서 EC2 모니터링 시스템을 완성합니다. CloudWatch 대시보드 만들기 대시보드는 여러 메트릭을 위젯 형태로 … 더 읽기
메모리 사용률은 어디서 볼 수 있을까? 모니터링 가이드 Part 1에서 EC2 기본 모니터링과 CloudWatch 알람을 설정했습니다. 그런데 막상 서버를 운영하다 보면 가장 궁금한 건 따로 있습니다. “메모리가 얼마나 남았지? 디스크가 꽉 차면 어떡하지?” t3.micro처럼 메모리가 1GB뿐인 인스턴스에서 WordPress와 MySQL을 Docker로 돌리고 있다면, 메모리 부족은 현실적인 걱정입니다. 하지만 EC2 기본 모니터링에서는 메모리 사용률과 디스크 용량을 제공하지 … 더 읽기