[Infra Ops] 장애/배포/연계/보안 케이스 실전 종합

1. 영향도 파악 (가장 먼저)
   → 전체 서비스인가, 특정 기능인가
   → 실제 사용자 영향 범위 (트래픽 시간대 확인)

2. 관련자 공유 (1~2분 내)
   → 팀장, 당직 개발자에게 영향도 요약 전송
   → "20:17 서비스 전체 다운, 확인 중" (원인 몰라도 먼저 공유)

3. Nginx 로그 확인 (인프라 레이어부터)

4. WAS(Tomcat) 로그 확인

5. DB 연결 확인

6. 원인 특정 및 조치

7. 서비스 복구 확인

8. 보고서 작성 (5W1H)

# 3. Nginx 상태와 최근 에러 로그
sudo systemctl status nginx
sudo tail -100 /var/log/nginx/error.log | grep "$(date +%Y/%m/%d)"

# 액세스 로그에서 최근 상태코드 분포
sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
# 출력 예: 502가 급증했다면 → Nginx는 살아있고 WAS가 다운

# 4. WAS 로그 확인
sudo tail -200 /opt/tomcat/logs/catalina.out | grep -E "ERROR|Exception|OutOfMemory"

# 메모리 상태 확인 (OOM 의심 시)
free -h
dmesg | grep -i "out of memory" | tail -10

# 5. DB 연결 확인 (WAS 로그에 DB 연결 오류 있을 때)
mysql -u app -p -e "SELECT 1;" 2>&1
# ERROR 2003 (HY000): Can't connect → DB 자체 문제
# ERROR 1040 (HY000): Too many connections → 커넥션 소진

# 6-1. Tomcat이 응답 안 하면 재시작
sudo systemctl restart tomcat
sudo tail -f /opt/tomcat/logs/catalina.out  # 기동 로그 확인

# 7. 서비스 복구 확인
curl -o /dev/null -s -w "%{http_code}" http://localhost/health
# 200 이면 복구 완료

언제(When):  2026-05-30 02:17 ~ 02:34 (17분간)
무엇이(What): 전체 서비스 응답 없음 (HTTP 502)
어디서(Where): app-server-01 Tomcat 프로세스
왜(Why):     Tomcat heap 메모리 소진 → OOM Killer에 의해 프로세스 종료
어떻게(How): systemctl restart tomcat으로 즉시 복구
조치(Action): JVM 힙 설정 검토, 메모리 사용량 CloudWatch 알람 추가

# 인증서 만료일 즉시 확인
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates
# notBefore=May 30 00:00:00 2025 GMT
# notAfter=May 30 23:59:59 2026 GMT  ← 오늘 만료!

# 인증서 파일 직접 확인 (서버에서)
sudo openssl x509 -in /etc/nginx/ssl/example.com.crt -noout -dates
sudo openssl x509 -in /etc/nginx/ssl/example.com.crt -noout -subject

# 현재 Nginx에 적용된 인증서 경로 확인
grep -r "ssl_certificate " /etc/nginx/conf.d/

# certbot이 설치된 경우
sudo certbot renew --dry-run   # 먼저 테스트

sudo certbot renew             # 실제 갱신
# 갱신 후 자동으로 Nginx reload 됨 (certbot hook 설정 시)

# 수동으로 reload
sudo nginx -t && sudo systemctl reload nginx

# 갱신 확인
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates
# notAfter가 3개월 후로 바뀌었는지 확인

# 1. CSR 생성 (기존 키 재사용)
openssl req -new \
  -key /etc/nginx/ssl/example.com.key \
  -out /tmp/example.com.csr \
  -subj "/C=KR/ST=Seoul/L=Seoul/O=Company/CN=example.com"

# 2. CSR을 인증기관(CA)에 제출 → 새 인증서 파일(.crt) 수령
# 3. 기존 인증서 파일 교체
sudo cp /etc/nginx/ssl/example.com.crt /etc/nginx/ssl/example.com.crt.bak
sudo cp /tmp/new_example.com.crt /etc/nginx/ssl/example.com.crt

# 4. Nginx 설정 검증 후 reload
sudo nginx -t && sudo systemctl reload nginx

# 5. 브라우저에서 자물쇠 아이콘 확인
# 6. 갱신 스케줄 캘린더에 등록 (만료 30일 전 알람)

# 만료 30일 이내 인증서 경고 스크립트 (crontab 등록)
#!/bin/bash
DOMAIN="example.com"
EXPIRY=$(echo | openssl s_client -connect $DOMAIN:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -lt 30 ]; then
  echo "경고: $DOMAIN 인증서 만료 $DAYS_LEFT 일 남음" | \
    mail -s "SSL 인증서 만료 임박" admin@example.com
fi

# 1. 브라우저 개발자도구 → Network 탭
# → 302 리다이렉트가 반복되는 패턴 확인
# → Set-Cookie 헤더가 있는지 확인

# 2. SP(서비스 제공자) 세션 쿠키 확인
# 크롬 개발자도구 → Application → Cookies
# → 세션 쿠키가 설정됐다가 사라지는 패턴?

# 3. Nginx 로그에서 리다이렉트 루프 확인
sudo grep "302" /var/log/nginx/access.log | tail -20
# 같은 URI로 302가 반복되는지 확인

# 4. SameSite 설정 확인 (가장 흔한 원인)
# SP 애플리케이션 설정에서 쿠키 SameSite 속성 확인
# SameSite=Strict: 다른 도메인에서 전송된 요청에 쿠키 미포함
# → IdP → SP 리다이렉트 시 SameSite=Strict 쿠키가 전달 안 됨

# 5. Nginx SSL terminate 환경에서 X-Forwarded-Proto 누락 확인
grep "X-Forwarded-Proto" /etc/nginx/conf.d/*.conf
# proxy_set_header X-Forwarded-Proto $scheme; 이 없으면
# 앱이 항상 HTTP로 인식 → HTTPS 강제 설정과 충돌 → 루프

# Nginx 설정에 X-Forwarded-Proto 추가
location / {
    proxy_pass http://localhost:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;  # 이 줄 추가
}

# IdP 연동 로그 확인 (SAML/OIDC)
# IdP 로그에서 SP assertion 처리 성공 여부 확인
# 대부분의 IdP는 /var/log/shibboleth/ 또는 별도 관리 콘솔에서 확인

sudo nginx -t && sudo systemctl reload nginx

# 검증 — 브라우저 캐시 삭제 후 재로그인 테스트
# 시크릿 모드에서 테스트 (캐시 영향 배제)

# 1. WAF 로그에서 차단 규칙 확인
# AWS WAF 사용 시 CloudWatch Logs에서 확인
aws logs filter-log-events \
  --log-group-name aws-waf-logs-my-waf \
  --filter-pattern "BLOCK" \
  --start-time $(date -d '1 hour ago' +%s)000 | \
  python3 -c "import sys,json; [print(json.dumps(json.loads(e['message']), indent=2)) for e in json.load(sys.stdin)['events']]"

# 출력에서 확인할 항목:
# terminatingRuleId: 차단한 규칙 ID (예: AWS-AWSManagedRulesCommonRuleSet)
# terminatingMatchDetails: 매칭된 패턴 (어떤 파라미터가 걸렸는지)

# 온프레미스 ModSecurity WAF 로그 확인
sudo tail -100 /var/log/modsec_audit.log | grep "Access denied"
# [file "rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"]
# [id "942100"] [msg "SQL Injection Attack Detected"]

# ModSecurity 예외 처리 (특정 URI + 규칙 ID 예외)
# /etc/nginx/modsecurity/exceptions.conf 에 추가
sudo tee -a /etc/nginx/modsecurity/exceptions.conf << 'RULE'
# /api/v1/register 경로에서 942100 규칙 예외
SecRule REQUEST_URI "@beginsWith /api/v1/register" \
  "id:1001,phase:1,pass,nolog,ctl:ruleRemoveById=942100"
RULE

sudo nginx -t && sudo systemctl reload nginx

오탐 확인 전:
  1. 실제로 정상 요청인가 확인 (개발팀에 페이로드 공유 요청)
  2. 해당 규칙이 왜 걸렸는지 이해 (SQL 인젝션 패턴 vs 실제 데이터)
  3. 특정 URI/파라미터에만 예외 적용 (전체 규칙 비활성화 금지)

예외 처리 후:
  4. 변경 내용 문서화
  5. 보안팀 공유 (WAF 규칙 변경은 보안 이벤트)
  6. 해당 파라미터를 애플리케이션 레벨에서도 검증하도록 개발팀 요청

# 1. HikariCP 로그에서 pool 상태 확인
sudo grep -A 5 "HikariPool" /opt/tomcat/logs/catalina.out | tail -30
# "Total=50, Active=50, Idle=0, Waiting=23" → pool 전부 사용 중

# 2. MySQL SHOW PROCESSLIST — 현재 실행 중인 쿼리 확인
mysql -u root -p -e "SHOW FULL PROCESSLIST;"
# 또는
mysql -u root -p -e "
SELECT id, user, host, db, command, time, state, left(info, 100) as query
FROM information_schema.processlist
WHERE command != 'Sleep'
ORDER BY time DESC;"

# 오래된 연결 (Sleep 포함) 확인
mysql -u root -p -e "
SELECT id, user, host, time, command
FROM information_schema.processlist
WHERE time > 60
ORDER BY time DESC;"

# 3. 느린 쿼리 강제 종료 (ID 확인 후)
mysql -u root -p -e "KILL QUERY 1234;"   # 쿼리만 종료 (연결 유지)
mysql -u root -p -e "KILL 1234;"         # 연결 전체 종료

# 4. 슬로우 쿼리 로그에서 근본 원인 찾기
sudo tail -100 /var/log/mysql/slow.log
# Query_time: 45.123456 → 45초 걸린 쿼리
# Full table scan, filesort → 인덱스 없음

# 5. 임시 Pool 크기 증가 (application.properties 또는 환경변수)
# spring.datasource.hikari.maximum-pool-size=50 → 100으로 변경
# → 재배포 또는 재시작 필요 (임시방편)

-- 슬로우 쿼리를 EXPLAIN으로 분석
EXPLAIN SELECT * FROM orders WHERE customer_email = 'user@example.com';
-- type: ALL → 풀스캔 (인덱스 없음)
-- rows: 1000000 → 100만 행 스캔

-- 인덱스 추가 (온라인 DDL — 서비스 중단 없이)
ALTER TABLE orders ADD INDEX idx_customer_email (customer_email);

-- 인덱스 추가 후 재확인
EXPLAIN SELECT * FROM orders WHERE customer_email = 'user@example.com';
-- type: ref → 인덱스 사용
-- rows: 5 → 5행만 스캔

롤백 결정 기준:
  Go(유지): 에러율 1% 미만, 경미한 UI 버그, 핫픽스 가능
  No-Go(롤백): 에러율 5% 이상, 핵심 기능(결제/인증) 오류, 데이터 손실 위험

결제 오류 → 즉시 No-Go 결정

# 1. 오류 확인 — 실제 영향도
sudo grep "ERROR\|Exception" /opt/tomcat/logs/catalina.out | \
  grep "$(date +%Y-%m-%d)" | wc -l
# 오류 수가 급증했는지 확인

# 에러 패턴 파악
sudo grep "PaymentException\|TransactionException" /opt/tomcat/logs/catalina.out | \
  tail -20

# 2. 롤백 결정 → 이전 버전 WAR 파일로 교체
# 배포 전 백업된 WAR 파일 위치 확인
ls -lt /opt/deploy/backup/
# -rw-r--r-- myapp-v1.2.3.war  ← 이전 버전
# -rw-r--r-- myapp-v1.2.4.war  ← 현재 버전 (문제 있는 버전)

# 3. 서비스 중지 → 파일 교체 → 재시작
sudo systemctl stop tomcat

sudo cp /opt/deploy/backup/myapp-v1.2.3.war /opt/tomcat/webapps/ROOT.war

# 기존 배포 디렉터리 삭제 (재배포를 위해)
sudo rm -rf /opt/tomcat/webapps/ROOT/

sudo systemctl start tomcat
sudo tail -f /opt/tomcat/logs/catalina.out  # 기동 로그

# 4. 기동 확인
curl -o /dev/null -s -w "%{http_code}" http://localhost/health
# 200 확인

# 5. 결제 기능 동작 확인 (스모크 테스트)
curl -X POST http://localhost/api/payment/test \
  -H "Content-Type: application/json" \
  -d '{"amount": 100, "method": "test"}'

# 6. 에러율 정상화 확인
sudo grep "ERROR" /opt/tomcat/logs/catalina.out | \
  grep "$(date +%H:%M)" | wc -l
# 0 또는 정상 수준으로 감소 확인

# v1.2.4에서 DB 마이그레이션이 실행됐는지 확인
mysql -u app -p mydb -e "SELECT * FROM flyway_schema_history ORDER BY installed_rank DESC LIMIT 5;"
# v1.2.4 마이그레이션이 실행됐다면 → v1.2.3 코드와 스키마 불일치 가능

# 마이그레이션 롤백 (down migration) 스크립트가 있는 경우
# → 개발팀과 협의 필수 (데이터 손실 가능성 있음)

# 임시 방법: v1.2.4 코드로 빠르게 핫픽스 적용

# 1. 연계 구조 파악
# 어떤 서버에서 어느 외부 IP:Port로 나가는지 확인
# 개발팀에게 확인: "어떤 URL로 호출하나요?"
# 예: https://api.payment.com (443) 또는 http://api.payment.com (80)

# 2. nc(netcat)로 포트 연결 테스트
nc -zv api.payment.com 443
# Connection to api.payment.com 443 port [tcp/https] succeeded! → 포트 열림
# nc: connect to api.payment.com port 443 (tcp) timed out → 차단됨

# curl로 HTTP 레벨 확인
curl -v --connect-timeout 10 https://api.payment.com/health
# connect: Connection timed out → 방화벽 차단

# 3. 현재 방화벽 규칙 확인 (온프레미스)
sudo iptables -L OUTPUT -n | grep -E "443|payment"
# 또는 보안장비(ASA, FortiGate 등)에 접속해 아웃바운드 규칙 확인

# AWS 환경이면 Security Group outbound 확인
aws ec2 describe-security-groups --group-ids sg-12345678 \
  --query "SecurityGroups[0].IpPermissionsEgress"

방화벽 오픈 신청서

신청 목적: 외부 결제 API 연동
요청자: 인프라팀 홍길동
승인자: 팀장 김철수
변경 유형: Outbound 규칙 추가

Source:
  서버: app-server-01 (10.0.1.100)
  서브넷: 10.0.1.0/24

Destination:
  대상: api.payment.com
  IP: 203.0.113.50 (DNS 확인 후 기재)
  Port: 443 (HTTPS)
  Protocol: TCP

비즈니스 사유: 결제 기능 구현을 위한 외부 PG사 API 연동
보안 검토: HTTPS 암호화 통신, 상용 PG사 (PCI-DSS 인증)

# 방화벽 오픈 완료 후 즉시 검증
nc -zv api.payment.com 443
# Connection to api.payment.com 443 port succeeded!

curl -I --connect-timeout 10 https://api.payment.com/
# HTTP/2 200 → 연결 성공

# 개발팀에 연결 성공 공유 후 앱 레벨 테스트 요청