배경HAProxy 뒤에 있는 백엔드 서버는 클라이언트 IP를 직접 볼 수 없습니다. 요청이 HAProxy를 거쳐 오기 때문에 백엔드 입장에서는 출발지 IP가 HAProxy IP로 보입니다.클라이언트 실제 IP를 백엔드에 전달하는 방법은 세 가지입니다.방법특징X-Forwarded-ForHTTP 헤더로 전달. HTTP 전용, 어플리케이션이 헤더를 읽도록 수정 필요Transparent Proxy네트워크 레이어에서 출발지 IP 자체를 클라이언트 IP로 변조. 어플리케이션 수정 불필요, 인프라 변경 필요Proxy ProtocolTCP 연결 시작 시 클라이언트 정보를 헤더로 전달. HTTP/TCP 모두 적용 가능, 백엔드에서 파싱 지원 필요이 글은 X-Forwarded-For로 해결되지 않는 TCP 트래픽 환경을 ..

배경Docker 컨테이너는 어떻게 CPU를 제한하고, 다른 컨테이너의 프로세스를 못 보게 막을까요?VM처럼 별도의 OS를 올리는 것이 아닌데, 컨테이너는 어떻게 서로 격리된 것처럼 동작할 수 있을까요.그 답은 Linux 커널의 두 기능에 있습니다. cgroup은 자원 사용량을 제한하고, namespace는 자원의 가시 범위를 격리합니다. 여기에 Union Mount Filesystem이 이미지 레이어를 효율적으로 관리합니다. 이 세 가지가 컨테이너 기술의 핵심입니다.1. cgroup이란cgroup(Control Group)은 프로세스의 자원 사용량을 제한하는 Linux 커널 기능입니다."how much you can use" — 얼마나 쓸 수 있는지를 제한합니다.제한할 수 있는 자원입니다.자원설명CPU사..

배경Nginx upstream_response_time이 간헐적으로 10초씩 튀는 현상이 발생했습니다.nginx -t도 정상, 어플리케이션 APM 로그도 정상(159ms), 그런데 클라이언트는 timeout. 어디서 10초가 사라지는 건지 로그만 봐서는 알 수 없었습니다.결론부터 말하면 원인은 DNS였습니다 — 정확히는, API 서버가 들어온 요청의 IP로 PTR 레코드 역방향 조회를 시도하고, 외부 DNS 서버가 응답하지 않아 5초씩 타임아웃을 반복한 것이었습니다.이 글은 그 트러블슈팅 과정과, 처음 써본 strace가 어떻게 결정적 단서를 줬는지, 그리고 strace 사용법을 함께 정리한 것입니다.1. 증상 파악Nginx 로그upstream_response_time이 10초 발생하는 것을 확인했습니다..

배경시스템을 운영하다 보면 장애는 예고 없이 발생합니다. 문제가 터진 뒤에야 로그를 뒤지는 것보다, 평소에 어떤 지표를 어떻게 모니터링해야 하는지를 아는 것이 중요합니다.이 글은 인프라 관점에서 모니터링해야 할 대상의 종류와, 시스템 병목 파악 시 어떤 관점으로 접근해야 하는지를 정리한 것입니다.1. 모니터링의 종류인프라 관점에서 모니터링은 크게 다섯 가지로 분류할 수 있습니다.종류설명프로세스 모니터링특정 프로세스가 문제없이 가동 중인지 확인메시지 모니터링OS나 어플리케이션이 출력하는 로그 감시리소스 모니터링CPU, 메모리, 디스크 등 자원 사용 상태 확인하드웨어 모니터링물리 장비(디스크, 팬, 전원 등)의 이상 여부 감지잡 모니터링배치 작업, 크론잡 등의 실행 결과 확인모니터링 결과를 통지할 때는 그 ..

배경시스템이 느려졌을 때 "어디서부터 봐야 하지?"라는 막막함을 느낀 적이 있습니다. CPU가 문제인지, 메모리가 부족한 건지, 디스크 I/O인지, 아니면 네트워크인지 — 방향 없이 뛰어들면 시간만 소비됩니다.이 글은 성능 이슈를 분석하는 방법론과 각 자원(CPU, 메모리, 파일시스템/디스크, 네트워크)의 동작 원리와 주요 분석 도구를 정리한 것입니다1. 성능 이슈 분석 방법론무작정 도구부터 실행하기 전에 어떤 관점으로 접근할지 방법론을 정해두면 빠트리는 지점 없이 체계적으로 분석할 수 있습니다.USE 방법론모든 자원에 대해 사용률(Utilization), 포화도(Saturation), 오류(Errors)를 확인하는 방식입니다. 인프라 레벨의 성능 분석에 적합합니다.지표의미사용률 (Utilization)..

배경서버 인프라를 구성하다 보면 단순히 디스크를 연결하는 것 이상의 결정이 필요해집니다. 어떤 방식으로 스토리지를 연결할지, 장애 시 데이터를 어떻게 보호할지, 용량을 어떻게 효율적으로 쓸지가 모두 설계 단계에서 정해져야 합니다.이 글은 스토리지의 종류(DAS, NAS, SAN)부터 RAID, 스냅샷/백업, 고급 기능(자동 계층화, 씬 프로비저닝, 디둡)까지 인프라 담당자가 알아두면 유용한 내용을 정리한 것입니다.1. 스토리지 종류스토리지는 크게 로컬 스토리지와 외부 스토리지로 나뉩니다.로컬 스토리지 — 서버 내부에 디스크를 설치해서 이용하는 저장 영역입니다. 설정이 단순하고 지연이 적지만 확장에 한계가 있습니다.외부 스토리지 — 서버 외부에 준비한 스토리지 장비 또는 스토리지 영역입니다. 아래와 같은 ..

배경Nginx에 새 conf 파일을 추가하고 nginx -t, nginx -s reload를 했는데 요청이 server_name에 매칭되지 않았습니다.설정 문법에는 문제가 없었고, nginx -t도 통과했습니다. 그런데 막상 요청을 보내면 가상 호스트가 잡히지 않고 default server로 떨어졌습니다.원인 추적 중 /var/log/audit/audit.log에서 SELinux AVC deny를 발견했습니다. 파헤쳐보니 문제는 두 개였습니다.첫 번째는 WAF 에이전트 로그 파일(/usr/local/deepfinder/log/filter.log)의 SELinux 컨텍스트가 잘못되어 있었고, 두 번째는 더 근본적인 원인으로 /etc/nginx/conf.d/ 디렉토리 전체가 user_home_t 컨텍스트를..

OpenVPN Access Server로 Split Tunneling 구현하기배경사내에서 OpenVPN을 운영하던 중 두 가지 문제에 부딪혔습니다.첫 번째는 CDN을 사용하는 SaaS 서비스 접근 문제입니다. SaaS 서비스들은 CloudFront 같은 CDN 뒤에 있어 도메인이 가리키는 실제 IP가 수시로 바뀝니다. iptables에 IP를 고정으로 박아두면 금세 깨집니다.두 번째는 사내 서비스의 IP 변경 문제입니다. 배포 환경에 따라 IP가 바뀔 수 있는데, 매번 VPN 설정을 수동으로 건드리는 건 운영 부담이 큽니다.이 두 문제를 해결하기 위해 dnsmasq + iptables DNAT 조합으로 도메인 기반 Split Tunneling을 구성했습니다. 특정 도메인에 대한 DNS 질의를 가상 IP로..

ECS 권한 제어 — Execution Role, Task Role, Container Instance Role, ECS ExecECS에서 IAM 권한은 목적에 따라 네 가지로 분리됩니다.이미지 pull, 로그 전송, 시크릿 주입 → Task Execution Role (ECS 에이전트 사용)앱 코드에서 S3, SQS, DynamoDB 호출 → Task Role (컨테이너 내 앱 사용)EC2가 클러스터에 등록 / 상태 보고 → Container Instance Role (EC2 기반 ECS 전용)ECS Exec으로 컨테이너 직접 접속 → Task Role에 SSM 권한 추가참고: Amazon ECS IA..

ECS Task 생명주기 — 상태 전이, 교체, Graceful ShutdownECS에서 Task는 단순히 "실행 중 / 중지"가 아닙니다. 상태 전이 흐름을 이해하면 장애 원인 파악과 Graceful Shutdown 설계가 쉬워집니다.Task 상태 전이 흐름PROVISIONING → PENDING → ACTIVATING → RUNNING → DEACTIVATING → STOPPING → STOPPED │ │ │ │ 용량 확보 이미지 Pull 정상 실행 SIGTERM 수신 (Fargate) 네트워크 구성 ..