내가 올리고 싶은대로 올리는 개발 블로그

장애가 발생했을 때 무엇을 먼저 봐야 할까서버가 느려졌다는 연락을 받으면 많은 사람이 먼저 CPU 사용률, 메모리 사용량, 디스크 사용량 같은 인프라 지표를 확인한다. 물론 틀린 접근은 아니다. 하지만 현대 시스템에서는 인프라가 정상이라도 서비스가 느릴 수 있고, 반대로 인프라 지표는 나쁘지만 사용자는 전혀 문제를 느끼지 못할 수도 있다.이런 환경에서 필요한 것이 관측 가능성이다. 단순히 모니터링 도구를 여러 개 설치하는 것이 아니라, 시스템의 내부 상태를 외부에서 추론할 수 있는 신호를 체계적으로 설계하는 것이다.대표적인 신호는 세 가지다.로그메트릭트레이스이 세 가지를 어떻게 조합하고, 어떤 질문을 위해 어떤 신호를 먼저 볼지 설계하지 않으면 관측 파이프라인은 금방 비용 폭탄과 노이즈의 집합소가 된다...

우리가 보통 GitOps를 접하면 다음과 같이 처음엔 이해한다.Kubernetes YAML 파일을 Git에 저장하고 Argo CD나 Flux로 배포하는 방식완전히 틀린 설명은 아니다.하지만 이 정도로 이해하면 실제 환경에서 곧바로 문제가 생긴다. 애플리케이션 소스 코드는 어디에 저장할 것인가?Docker 이미지가 빌드된 뒤 Git에는 무엇을 변경할 것인가?개발·스테이징·운영 환경은 어떻게 분리할 것인가?운영 환경 배포는 자동으로 할 것인가?Secret은 어느 저장소에 둘 것인가?긴급 변경은 어떻게 처리할 것인가?여러 클러스터를 하나의 구조로 관리할 것인가즉, GitOps의 핵심은 YAML 파일을 Git에 넣는 것 자체가 아니고 운영 환경의 원하는 상태를 어떤 저장소 구조와 변경 절차로 관리할 것인지 설계..

연결을 보는 로드밸런서와 요청을 이해하는 로드밸런서로드밸런서는 여러 서버에 들어오는 트래픽을 분산해 특정 서버에 부하가 몰리지 않도록 하는 장치다.하지만 모든 로드밸런서가 같은 방식으로 동작하는 것은 아니다.대표적으로 L4 로드밸런서와 L7 로드밸런서가 있다.둘 다 트래픽을 여러 서버로 나눈다는 목적은 같지만, 어디까지 트래픽을 이해하고 판단하는가에서 차이가 난다.간단히 말하면 다음과 같다.L4 로드밸런서는 IP와 포트, TCP·UDP 연결 정보를 보고 트래픽을 전달한다.L7 로드밸런서는 HTTP 요청의 URL, Host, Header, Cookie 같은 애플리케이션 내용을 보고 트래픽을 전달한다.L4는 단순하고 범용적인 연결 처리에 적합하고, L7은 웹 요청을 세밀하게 분기하거나 TLS 종료, 보안 정..

CPU, 메모리, 디스크, 네트워크로 원인 좁히기“서버가 느려졌습니다.”인프라 엔지니어라면 한 번쯤 반드시 듣게 되는 말이다. 문제는 이 한마디만으로는 아무것도 알 수 없다는 점이다. SSH 접속이 느린 것인지, 특정 API만 느린 것인지, 서버에서 실행하는 명령어 자체가 느린 것인지에 따라 확인해야 할 지점이 완전히 달라진다.많은 사람이 서버가 느리다는 말을 들으면 바로 top부터 실행하고 CPU 사용률을 확인한다. CPU가 높으면 CPU 문제, 메모리가 높으면 메모리 문제라고 판단하는 식이다. 하지만 실제 장애는 그렇게 단순하지 않다. CPU 사용률은 낮은데 디스크 I/O를 기다리느라 서버가 느릴 수 있고, 메모리가 충분해 보여도 애플리케이션이 파일 디스크립터나 네트워크 연결을 기다리고 있을 수 있다..

리눅스 부팅 과정과 systemd 쉽게 이해하기전원 버튼을 누른 뒤 로그인 화면이 뜰 때까지 무슨 일이 일어날까리눅스를 처음 접하면 서버가 켜지는 장면이 너무 당연하게 느껴진다. 전원을 넣으면 몇 초 뒤 로그인 프롬프트가 뜨고, 서비스를 실행하면 되고, 문제가 생기면 재부팅하면 된다고 생각하기 쉽다. 하지만 운영 관점에서는 이 “몇 초” 동안 무슨 일이 벌어지는지를 모르면 장애 원인을 좁히기가 어렵다. 서버가 아예 안 올라오는 문제, 커널은 떴는데 서비스가 안 뜨는 문제, 특정 장치가 인식되지 않는 문제는 모두 부팅 과정의 서로 다른 단계에서 발생한다.쉽게 말해 리눅스 부팅은 공장 라인이 돌아가는 과정과 비슷하다. 공장을 열기 전에 건물 전기를 켜고, 출입문을 열고, 기계를 점검하고, 작업자를 배치하고,..

쿠버네티스 네트워킹 정리: Service부터 Gateway API까지쿠버네티스 네트워킹은 쿠버네티스를 공부할 때 가장 헷갈리기 쉬운 영역 중 하나입니다. Pod, Service, Ingress, NetworkPolicy, CoreDNS, Gateway API까지 등장하는 개념이 많다 보니, 각각을 따로 외우면 금방 흐름을 놓치게 됩니다. 이 주제는 개별 리소스의 문법이 아니라, 누가 어떤 문제를 해결하기 위해 존재하는가를 축으로 이해해야 합니다. Pod 간 통신, 클러스터 내부 노출, 클러스터 외부 노출, 트래픽 제어, 이름 해석이라는 다섯 가지 문제를 각 기능이 어떻게 나눠서 해결하는지 보면 훨씬 명확해집니다.이 글에서는 Pod 네트워킹의 기본 원리부터 시작해서 Service, Ingress, Netw..

Spring Boot를 쓰다가 FastAPI를 처음 보면 이런 의문이 든다.“@Service도 없고 @Autowired도 없는데, 의존성 주입은 어디서 일어나는 거지?” FastAPI에도 의존성 주입(Dependency Injection, DI)이 있다. 다만 Spring처럼 애플리케이션 전체의 Bean을 관리하는 컨테이너를 중심에 두기보다는, 각 API 요청을 처리하는 과정에서 필요한 값과 공통 로직을 해결하는 구조에 가깝다.FastAPI에서는 Depends()가 이 역할의 출발점이다.이 글에서는 Spring의 DI 흐름을 기준점으로 삼아 FastAPI의 Depends()가 언제 실행되고, 어떤 순서로 의존성을 해결하며, 실무에서는 어디까지 사용하면 좋은지 살펴본다.먼저, Spring의 DISpring..

쿠버네티스 스케줄링 원리에 대해 공부한 내용을 정리했습니다. 들어가며쿠버네티스를 공부할 때 많은 사람이 스케줄링을 단순히 “Pod를 어느 노드에 올릴지 정하는 기능” 정도로 이해합니다. 물론 틀린 말은 아닙니다. 하지만 실무에서는 그 정도 이해로는 금방 한계가 옵니다. 왜 어떤 Pod는 특정 노드에 올라가지 못하는지, 왜 우선순위가 높은 Pod가 먼저 살아남는지, 왜 어떤 요청은 스케줄러까지 가지도 못하고 중간에서 거절되는지 설명할 수 있어야 비로소 운영 관점의 이해라고 할 수 있습니다.냉정하게 말하면, scheduler, taint/toleration, node affinity, PriorityClass, pod admission은 따로 외워서는 안 됩니다. 이 다섯 개는 모두 “Pod가 생성 요청을 ..

로드밸런서에 대한 개념과 구현을 어떻게 하는지 학습한 내용을 정리했습니다.로드밸런서(Load Balancer)?로드밸런서(Load Balancer)는 클라이언트로부터 들어오는 네트워크 트래픽을 여러 백엔드 서버로 분산시키는 장치 또는 소프트웨어다. 교통경찰처럼 수많은 요청(차량)을 각 서버(도로)로 적절히 흘려보내, 특정 서버에 트래픽이 몰려 죽는 일을 방지한다. 현대 서비스에서 고가용성(HA), 수평 확장(Scale-out), 무중단 배포는 로드밸런서 없이는 불가능하다. 핵심 이점은 다음과 같다: 가용성(Availability): 특정 서버 장애 시 나머지 서버로 즉시 트래픽 전환확장성(Scalability): 서버를 추가하는 것만으로 처리 용량 증가보안(Security): DDoS 방어, SSL 터미..

쿠버네티스 백엔드 구조와 설계에 대한 공부 내용을 정리했습니다.컨트롤 플레인과 워커 노드쿠버네티스 클러스터는 컨트롤 플레인과 워커 노드로 구성되어 있다.워커 노드들은 우리가 원하는 애플리케이션의 이미지 기반의 컨테이너화된 애플리케이션을 실행한다.모든 클러스터는 파드를 실행하기 위해 최소한 하나의 워커 노드가 필요하다.워커 노드는 애플리케이션 워크로드의 구성 요소인 파드를 호스팅한다.컨트롤 플레인은 클러스터 내의 워커 노드와 파드를 관리한다. 프로덕션 환경에서, 컨트롤 플레인은 보통 여러 대의 컴퓨터에서 실행되며, 클러스터는 일반적으로 여러 개의 노드를 실행하며 장애를 컨트롤하고 고가용성을 제공한다. 노드와 파드노드는 서버(컴퓨터), 파드는 그 위에서 돌아가는 앱 실행 단위다.보통 노드는 마스터 노드(컨트..