퀴즈: 로그와 장애 진단

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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