kth990303
commented
9 months ago 전체 애플리케이션에 대한 99.999% 신뢰성은 이제 충분하지 않다. 이 수준의 신뢰성이라면 매일 수천 명의 사용자가 실망하게 될 것이다. (p.70)
99.999% 라는 비율은 되게 높아보이는데, 절대적인 양으로 따지면 생각보다 수가 많다는 생각이 들어 경각심이 들더라고요. '새벽 시간대에 잠깐 API 레이턴시가 튀는 정도는 괜찮겠지?', '가끔 커넥션타임아웃 뜨는데 괜찮겠지? 백로그로 넘겨도 되겠지?' 와 같은 안일함은, 규모가 커질수록 일일이 챙기기 힘든데, 아이러니하게도 규모가 커질수록 위험할 수 있어서 정말 어려운 것 같습니다. (채용공고 우대사항에 괜히 대용량 트래픽 유경험자 라고 적혀있는게 아니구나 싶기도 하고요? ㅠㅠ)
~ 방화벽의 데이터베이스 쪽 트래픽이 전혀 없다는 것은 매우 중요한 단서였다.(p.80)
하지만 방화벽은 'ICMP 목적지 도달 불가'라는 메시지도 없이 이 패킷들을 계속 버리기만 했다.(p.82)
오라클에는 종료된 연결을 찾아내는 DCD(dead connection detection)란 기능이 있어서 클라이언트가 급작스럽게 작동이 중지되었는지 찾아낼 수 있다.(p.83)
DB 에 트래픽이 없는 건에 대해, DB 인스턴스가 죽은 것도 아니고 애플리케이션도 잘 돌아가고, 애플리케이션 재시작하면 다시 잘 살아나고... 엄청 멘탈 나갔을 듯한데, 트래픽이 없는 것을 보고 진입점포인트 (방화벽) 이슈를 예리하게 캐치해내고, 해결책 또한 방화벽 재설정 같은게 아닌 DCD 설정으로 처리한 게 인상깊었습니다.
약간 유사한 사례라 생각되는 포스팅: https://pat98.tistory.com/788
확실히 아는게 많을수록 시선도 넓어지고 처리 능력도 좋아지는 것 같다는 생각이 들음과 동시에, 악의적인 의도를 고려하여 ICMP reset 을 전송하지 않은 근거있는 행동이 오히려 이러한 결과를 초래했다는 것이 한편으론 무섭네요.
문제를 이해하려면 해당 문제가 드러난 추상화 수준에서 한두 단계를 파고 들어가 실체를 밝혀내는 방법을 알아야 한다.(p.84) 처럼, 한두 단계를 파고 들어가지 않으면 멘탈나가고 발만 동동 굴렀을 것 같습니다.
서버 하나가 작동을 멈추면 [그림 4-9]와 같이 분산된다. 남은 7개의 서버는 각각 총 부하의 14.3% 정도를 처리해야 한다. 각 서버는 전체 부하의 1.8% 정도만 추가로 처리하면 되지만 기존보다 부하가 15% 가량 증가하는 꼴이다. (p.89)
CPU Utilization 이 한 서버당 90% 이상일 때 경고를 띄우는게 아닌, 훨씬 낮은 수치에서 경고를 띄우고 알람을 보내는 이유라고 생각이 드네요. 사내에서 CPU Utilization이라든지, 메모리가 몇 % 쯤일 때 알람을 보내주는지 얘기 나눠봐도 좋을 거 같아 적어봤습니다!
JasonYoo1995
binchoo
주제
4장 - 안정성 안티 패턴'을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요
연관 챕터
7
@caffeine-library/readers-release-everything