주제

6장 - 사례 연구: 램프 속 우주의 힘을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요.

연관 챕터

18

@caffeine-library/readers-release-everything

웹, 애플리케이션, 데이터베이스 cpu 사용량은 정말 낮아도 너무 낮았다. (p.199) / 요청 처리 스레드는 거의 모두 바빴다. 대부분 3분 이상 요청을 처리하느라 3분 이상 일하고 있었다. (p.199)

스레드 수는 굉장히 높은데 cpu 사용량이 낮은게 너무 신기했습니다.
- Q. 이런 경우, 스레드 컨텍스트 스위칭 비용으로 인해 힙메모리도 높았으려나요? EC2 메모리 성능이 문제네~ 하고 ec2 성능 올리는 잘못된 처치로 이어질 가능성도 존재할 거 같아서요.. 무섭네요. -> 해당 개수만큼의 스레드 컨텍스트 메모리는 잡아먹었겠지만, 스레드 상태가 blocking 상태이고 바쁜 상태는 아니므로 그 외 자바 객체 등 많이 잡아먹진 않아 메모리를 많이 잡진 않았을 것.
cpu 사용량이 낮은데, 스레드 수만 높은 경우여서 스레드 덤프 뜨는 거 외엔 방법이 안떠오르긴 합니다. 500번대 에러 (502이든 504이든)를 내뱉고 스레드가 매우 바쁜데 cpu 사용량은 낮은 경우를 겪은 적이 없었어서 너무 인상깊어서 키워드에 작성했어요.

대부분은 뒷단을 호출하기 위한 연결이 생성되길 기다리고 있었다. 이 스레드들은 모두 자원 풀에서 블록되었고 이 블록에는 시간 제한이 없었다. (p.200)

책에서의 처치 방안은 스크립트로 DRP 내 애플리케이션 stop시키는 것이었지만, 사실상 필요한 포카요케는 timeout 미설정돼있는 값들을 설정하도록 하는게 아닐까 싶기도 합니다.

필자는 만약을 위해 가족들의 짐으로 가득한 자동차에 노트북을 쑤셔 넣었다.(p.195)

저는 놀러갈 때엔 노트북을 안들고가는데,,, 이 문구를 보면서 반성하게 됐습니다. 나중에 주니어에서 벗어나면 그만큼 책임도 많으니 항상 노트북을 준비하고 상시대기하는 일이 많아질거 같긴 하군요.

6.1 첫 번째 크리스마스

온라인 상점 오픈
낙관한 이유
1. 운영용 서버 2배 확장
2. 언제 어디서 어느 수준의 지연이 발생하는지 사전 파악됨
3. 모니터링 및 제어 시스템을 잘 구축해놓아서 문제가 발생해도 잘 처리할 수 있다는 자신감이 있었음

6.2 맥박 확인

운영 환경에서 지연 시간, 미사용 힙 메모리, 활성 요청 처리 스레드, 활성 세션, 주문 수 등 다양한 지표들을 주기적으로 모니터링 진행

6.3 추수감사절

추수감사절 : 11월의 넷째 주 목요일
평소의 수십 배의 트래픽을 잘 감당했음을 세션 수, 주문 수, 페이지 지연 시간 등의 지표를 통해 확인

6.4 블랙 프라이데이

블랙 프라이데이 : 추수감사절 익일
사이트가 멈췄다
재시작을 해도 즉시 실패

6.5 생명 징후

파악한 사실
- 세션 수 많음
- 네트워크 대역폭 사용량이 높지만 한계치는 아님
- 페이지 응답 시간 지연
- 서버 및 DB의 CPU 사용량이 매우 낮음
- 검색 서버는 정상 동작
- 요청 처리 스레드가 매우 바빠서 3분 이상 걸림

6.6 진단 테스트

스레드 덤프 확인 결과
- 온라인 상점 서버
  - 일부의 스레드 : 뒷단 호출 후 블록되었고, 시간 제한이 없음
  - 다른 모든 스레드 : 뒷단 호출을 위한 연결 생성 대기
  - 요청 스레드 3,000개 모두 아무 일도 하지 않고 묶여 있어 CPU 사용량이 매우 낮음
- 주문 관리 서버
  - 일부의 스레드 : 뒷단 호출 후 블록되었고, 시간 제한이 없음
  - 다른 모든 스레드 : 뒷단 호출을 위한 연결 생성 대기

6.7 전문가 호출

일정 관리 서버는 원래 4대로 운영하나 2대는 정비로 중단, 1대는 원인 모를 이유도 미작동 중이어서 1대만 정상 동작 중이었음
주문 관리 서버의 90개 요청이 일정 관리 서버를 호출 중이었을 것으로 추정
일정 관리 서버의 CPU 사용량은 100%
평소에 높은 CPU 사용량에 대한 잦은 false positive 알람 때문에 해당 알람을 무시하는 습관이 있었음

6.8 처치 방안 비교

일정 관리 서버만을 위한 별도 연결 풀 존재 → 연결 풀의 최대값을 0개으로 줄이면 배송 일정 예약 불가 문구가 유저에게 노출되나 전체 시스템은 살릴 수 있는 차선책 가능

6.9 처치 결과

연결 풀의 최대값을 0개로 줄이고 컴포넌트를 재시작하는 스크립트를 실행하니 의도한대로 해결됨
전체 서버가 아닌 컴포넌트를 재시작하는 능력은 복구 지향 컴퓨팅의 핵심 개념임

6.10 휴식 시간

연결 풀의 최대값을 재설정하는 스크립트를 재작성하여 언제든지 편리하게 실행할 수 있게 함
부하가 적을 때는 최대값을 증가 시키고 부하가 클 때는 최대값을 1로 감소 시키면서 운영함

📘 응답 시간은 언제나 후행 지표다. 우리는 종료된 응답의 응답 시간만을 측정할 수 있다. (중략) 완료되지 않은 요청은 절대 평균에 포함되지 않았다. (p.199)

💬 응답 시간 통계의 함정을 짚어주기에 뜻깊었습니다. 응용에 끝나지 않는 요청 뿐이라면 응답 시간은 0초로 기록될 테니까. 여기에 대비하려면 현재 진행중인 요청 수 메트릭도 정의하고 수집해야 할 것 같네요. 관련해서 관측하고 계신가요? (태현 님의 Timeout을 설정해 평균이 그쪽으로 치우치는지 의견 감사합니다)

최근 OTel로 웹 서버를 자동 계측했을 때 http.server.active_requests가 추적되는 점은 확인해 보았습니다 :)

📘 담당 엔지니어는 CPU 사용량이 너무 높다는 알림을 여러 번 받았지만 이전까지 CPU 사용량이 순간적으로 튀었을 뿐 문제가 아닌 것으로 판명된 알람을 정기적으로 받았기 때문에 이번에도 응답하지 않은 것이다. (p.202)

💬 False-Posivite 알림 정말 골치가 아픈 것 같습니다. 뻥 알림에 노출되면 관제 담당자가 태만해지기 마련인데, 그렇다고 알림이 민감하지 않게 역치를 넉넉히 했다가 실제 이슈 상황을 너무 늦게 알아챌 수도 있고... 어렵네요. 태현 님 False-Positive 사례에서도 어떻게 조치가 잘 되었을까요?

경보시 추가로 확인해 볼 메트릭 셋 마련, 더 나아가 그들을 엮어 복합 알람(Composite Alarm) 정의
AI/ML 도움으로 이상 탐지 예측해 보기
에러 로그도 통합 조사> Logs Insights로 메트릭화 또는 GenAI 활용 가능성도

caffeine-library / release-everything

[keyword] 6장 - 사례 연구: 램프 속 우주의 힘 #19

주제