Quiz: Logs and Failure Diagnosis

SSO 로 로그인한 일부 사용자만 502 를 받고, 업스트림 헬스체크는 계속 정상입니다. 가장 유력한 원인은?

• 쿠키가 커서 응답 헤더가 프록시 버퍼를 초과해 nginx 가 파싱에 실패한다
• 백엔드 프로세스가 간헐적으로 죽는다
• proxy_read_timeout 이 짧다
• DNS 캐시가 오래되었다

502 가 발생하는 상황에서 proxy_read_timeout 을 늘리는 조치의 효과는?

• 대부분 해결된다
• 502 가 503 으로 바뀐다
• 효과가 없다 - 타임아웃은 504 와 관련된 설정이다
• 업스트림 부하가 줄어든다

프록시를 건너뛰고 업스트림에 직접 요청할 때 -H 'Host: api.example.com' 을 반드시 붙여야 하는 이유는?

• 가상 호스트 라우팅이 걸려 있으면 Host 가 다를 때 다른 앱으로 가 비교가 무의미해져서
• 인증 토큰이 Host 헤더를 기준으로 서명돼 있어 값이 다르면 거부되기 때문에
• HTTP/1.1 요청은 Host 헤더가 없으면 클라이언트가 만들지 못하기 때문에
• TLS 협상 때 SNI 값을 Host 헤더에서 가져다 쓰기 때문에

java.lang.OutOfMemoryError: unable to create native thread 에 대한 올바른 대응은?

• 힙이 모자라 스레드 스택을 못 잡은 것이므로 -Xmx 를 늘린다
• 정지 시간이 길어 스레드 생성이 밀린 것이므로 GC 알고리즘을 바꾼다
• 클래스 메타데이터 공간이 찬 것이므로 Metaspace 를 늘린다
• 힙이 아니라 스레드 생성 한계 문제이므로 덤프로 누수와 OS 한계를 확인한다

GC 로그에서 Pause Full ... 486M->402M(512M) 이 반복될 때 읽어야 할 신호는?

• Full GC 뒤에도 사용량이 힙 전체에 근접해 실제 부족이나 누수가 의심된다
• Full GC 때마다 80MB 가 회수되고 있으므로 정상 범위의 동작이다
• Young 영역이 작아 조기 승격이 일어난 것이므로 신세대를 키우면 된다
• 이 로그 형태는 알고리즘 선택이 잘못됐을 때만 나오므로 수집기를 바꾼다

장애 발생 시 재기동 직전에 스레드 덤프와 로그를 확보해야 하는 이유는?

• 재기동하면 메모리·스레드 상태가 사라져 원인 분석이 불가능해지기 때문
• 덤프를 미리 떠 두면 기동 시간이 짧아져 복구가 빨라지기 때문
• 장애 시 증적 확보가 정보보호 규정의 필수 절차이기 때문
• 고객 보고서에 첨부할 자료가 필요해 나중에 요구받기 때문

장애 시각 전후로 분당 요청 수가 급증한 것을 발견했습니다. 해석 시 주의할 점은?

• 요청이 몰린 시각과 장애 시각이 겹치므로 트래픽 급증이 원인이라고 볼 수 있다
• 실패한 요청을 사용자가 새로고침한 결과일 수 있어 급증과 오류의 선후를 봐야 한다
• 요청 수는 서버 용량과 무관한 지표라 장애 분석에서 제외하는 것이 맞다
• 짧은 구간의 급증은 로그 집계 주기가 겹쳐 생기는 착시일 가능성이 높다