서버 & 인프라
쿠버네티스 HPA/VPA 오토스케일링 실전 튜닝
쿠버네티스에서 오토스케일링은 “켜두면 알아서 잘 되는” 기능이 아닙니다. 기본값으로 HPA를 붙여놓고 트래픽 급증을 맞으면, 파드가 늦게 뜨거나 우르르 떴다가 다시 죽는 플래핑(flapping)을 겪게 됩니다. 반대로 리소스를 넉넉히 잡아두면 노드 비용이 새어나갑니다.…
TLS 인증서 자동화: cert-manager·Let’s Encrypt 운영
TLS 인증서를 수동으로 관리하던 시절의 악몽은 대개 하나로 요약됩니다. “인증서가 만료됐는데 아무도 몰랐다.” 갱신 담당자가 퇴사했거나, 캘린더 알림을 놓쳤거나, 갱신은 했는데 배포를 잊은 채 서비스 전체가 브라우저 경고와 함께 멈춰버리는 상황이죠. 이 위험을 근본적…
PostgreSQL VACUUM·오토배큠 튜닝: 테이블 부풀림과 트랜잭션 ID 소진 막기
디스크 사용량이 이유 없이 계속 늘어난다. 데이터는 몇 달째 비슷한 규모인데 테이블 물리 크기만 부풀어 오르고, 어제까지 멀쩡하던 조회 쿼리가 점점 느려진다. 로그를 뒤져 보면 autovacuum 관련 경고가 쌓여 있고, 심하면 database is not accept…
서비스 메시 도입 판단 기준: Istio·Linkerd
서비스 메시는 마이크로서비스 사이의 통신을 애플리케이션 코드 밖으로 빼내어, 트래픽 관리·보안·관측성을 인프라 계층에서 일관되게 처리하는 기술입니다. mTLS 자동 암호화, 재시도와 서킷 브레이커, 세밀한 트래픽 분할, 서비스 간 통신의 자동 계측 같은 기능을 코드 수…
리눅스 파일 디스크립터·ulimit 튜닝: Too many open files 해결
트래픽이 어느 정도 오르기 시작한 서버라면 누구나 한 번쯤 이 로그를 만납니다. Too many open files . 대개는 새벽에, 부하가 몰릴 때, 예고 없이 터집니다. 원인은 리눅스의 파일 디스크립터(File Descriptor, FD) 한계입니다. 소켓·파일·…
쿠버네티스 파드 스케줄링 제어: node affinity·taint·toleration·topologySpread 실전
클러스터를 운영하다 보면 파드가 엉뚱한 곳에 뜨는 순간이 반드시 온다. GPU 노드에 CPU만 쓰는 배치 파드가 스케줄돼 비싼 자원을 놀리거나, 레플리카 3개가 하필 같은 노드에 몰려 그 노드가 죽는 순간 서비스 전체가 내려가거나, 특정 가용영역(AZ) 하나에 파드가 …
리눅스 서버 부하 진단 3종: CPU·메모리·I/O 병목 찾기
서버가 느려졌다는 알림을 받았을 때, 무작정 재부팅하거나 인스턴스를 키우는 것은 근본 원인을 덮는 임시방편입니다. 리눅스 서버의 부하는 크게 CPU, 메모리, I/O 세 축으로 나뉘며, 각 축마다 확인해야 할 지표와 도구가 다릅니다. 이 글에서는 로드 애버리지를 오해 …
CDN 캐시 전략: TTL·캐시키·퍼지 설계
CDN을 앞단에 붙였는데도 오리진 트래픽이 줄지 않는다면, 십중팔구 캐시 전략이 잘못 설계된 것입니다. CDN은 “일단 앞에 두면 알아서 캐싱해주는 마법”이 아니라, 무엇을 얼마나 오래, 어떤 키로 캐시할지 명시적으로 설계해야 제 성능을 냅니다. 이 글에서는 실무에서 …
HTTP 커넥션·타임아웃·재시도: 장애를 막는 클라이언트 설정
분산 시스템에서 장애는 “서버가 죽었을 때”만 발생하지 않습니다. 오히려 더 흔한 원인은 느린 응답 입니다. 하나의 다운스트림 서비스가 평소보다 몇 초 느려지면, 타임아웃을 걸어두지 않은 클라이언트는 스레드와 커넥션을 붙잡은 채 대기하고, 그 대기가 연쇄적으로 상위 서…
HTTP/3(QUIC) 도입 판단: HTTP/2 대비 무엇이 빨라지고 언제 전환할까
사무실 유선망에서는 멀쩡하던 서비스가 지하철이나 엘리베이터에서 유독 버벅인다. 원인을 파고들면 HTTP/2도 완벽하지 않다는 사실에 부딪힌다. HTTP/2는 하나의 TCP 연결 위에 여러 요청을 다중화(multiplexing)해 HTTP/1.1의 병목을 상당 부분 해소…
Kafka vs RabbitMQ: 언제 무엇을 선택할까
비동기 메시징을 도입할 때 가장 자주 마주치는 갈림길이 Kafka와 RabbitMQ 사이의 선택입니다. 둘 다 “메시지 큐”로 뭉뚱그려 불리지만, 설계 철학과 강점이 근본적으로 다릅니다. 잘못 고르면 운영 내내 결이 맞지 않는 도구와 싸우게 됩니다. 핵심을 먼저 말하면…
프로메테우스 + 그라파나로 모니터링 대시보드 구축하기
서비스가 다운되고 나서야 알아채는 것은 이미 늦은 것이다. 프로덕션 환경에서 모니터링은 선택이 아니라 생존 전략이다. 이 글에서는 오픈소스 모니터링 스택의 사실상 표준인 Prometheus와 Grafana를 조합해 실전 대시보드와 알럿까지 구성하는 방법을 단계별로 다룬…
gRPC vs REST: MSA 통신 성능·설계 비교
마이크로서비스 아키텍처(MSA)를 설계할 때 서비스 간 통신 프로토콜 선택은 전체 시스템 성능과 운영 편의성을 좌우하는 핵심 결정입니다. REST는 수십 년간 표준으로 군림해왔지만, gRPC는 구글이 내부 RPC 프레임워크를 오픈소스화하면서 고성능 서비스 간 통신의 유…
컨테이너 보안 기본기: 이미지 스캔과 최소권한 원칙
컨테이너는 격리되어 있다는 착각이 가장 위험하다. 도커 컨테이너는 호스트 OS 커널을 공유하고, 이미지 안에 취약한 라이브러리가 숨어 있거나 root로 프로세스가 실행된다면 침해 사고가 터졌을 때 피해가 호스트 전체로 퍼질 수 있다. 이 글에서는 컨테이너 보안의 두 축…
로그 수집 파이프라인 비교: ELK vs Loki, 무엇을 쓸까
로그는 시스템의 ‘블랙박스’다. 장애가 터졌을 때 로그 파이프라인이 제대로 갖춰져 있지 않으면, 원인 분석에 몇 시간이 아니라 며칠이 걸리기도 한다. 로그 수집 스택을 선택할 때 가장 많이 맞붙는 조합이 ELK(Elasticsearch + Logstash + Kiban…
Redis 캐싱 전략으로 API 응답속도 10배 개선하기
API 응답속도가 느리다는 민원이 들어오면 가장 먼저 손이 가는 해결책이 Redis 캐시입니다. 잘 적용하면 응답 지연을 100ms에서 5ms 이하로 줄이는 것이 현실적으로 가능하지만, 잘못 설계하면 캐시 스탬피드, 데이터 불일치, 무효화 실패 같은 더 복잡한 문제를 …
데이터베이스 커넥션 풀 최적화: 커넥션 고갈 없이 처리량 높이기
웹 서비스가 트래픽 피크를 맞이하면 가장 먼저 무너지는 곳은 대개 데이터베이스 레이어입니다. “Too many connections” 에러, 쿼리 타임아웃, 결국 서비스 전체 다운 — 이 패턴은 커넥션 풀을 제대로 설계하지 않은 시스템에서 반복적으로 나타납니다. 커넥션…
Nginx 리버스 프록시 성능 튜닝: 동시접속 10배 버티기
트래픽이 갑자기 10배로 폭증하는 상황을 상상해보세요. 평소에는 문제없이 돌아가던 서비스가 순식간에 500 에러와 응답 지연으로 무너집니다. 원인의 상당수는 애플리케이션 코드가 아니라 그 앞에 놓인 Nginx 리버스 프록시의 기본값 설정 에 있습니다. Nginx는 기본…
Terraform으로 인프라를 코드로: IaC 입문과 실전 패턴
수동으로 AWS 콘솔을 클릭해 인프라를 구성하던 시대는 끝났습니다. 클라우드 리소스가 수십, 수백 개로 늘어날수록 클릭 기반 관리의 한계는 명확해집니다. 설정 드리프트, 재현 불가능한 환경, 팀원 간 불일치. 이런 문제를 해결하기 위해 등장한 것이 IaC(Infrast…
관측성(Observability) 3요소: 메트릭·로그·트레이스 제대로 이해하기
시스템이 복잡해질수록 “지금 무슨 일이 벌어지고 있나?”라는 질문에 답하기가 어려워집니다. 단일 프로세스 시절에는 로그 몇 줄로 충분했지만, 마이크로서비스가 수십 개 얽히고 쿠버네티스 위에서 수백 개 Pod가 떠 있다면 이야기가 달라집니다. 관측성(Observabili…
쿠버네티스 리소스 requests/limits 튜닝 실전 가이드
쿠버네티스 클러스터를 운영하다 보면 어느 날 갑자기 파드가 OOMKilled 상태로 재시작되거나, CPU 사용률은 낮은데 응답 지연이 급증하는 현상을 마주하게 됩니다. 대부분의 경우 원인은 resources.requests 와 resources.limits 설정의 부재…
Docker 이미지 경량화: 멀티스테이지 빌드로 용량 80% 줄이기
컨테이너 이미지 용량은 배포 속도, 저장 비용, 공격 표면(attack surface) 세 가지에 직접 영향을 미칩니다. CI/CD 파이프라인에서 이미지를 매번 풀(pull)해야 한다면 500 MB짜리 이미지와 50 MB짜리 이미지의 차이는 누적 시간으로 수십 분에 달…