Video: [모니터링] 구글이 알려준 꼭 봐아할 지표 4가지 | 멤버십 영상
Channel: 코딩하는기술사
Duration: 13m 43s
Source: subtitle (auto, ko)
Transcript:
안녕하세요, 멤버 여러분. 어, 오늘은이 모니터링 얘기를 좀 해 볼까 합니다. 서비스를 안정적으로 운영하기 위해서는이 모니터링이 필수죠. 그런데 우리 멤버 여러분들은이 모니터링 할 때 주로 어떤 지표를 가장 중요하게 보고 계신가요? 어, 오늘은 어떤 지표를 어떤 관점으로 봐야 하는지 말씀을 드려 보겠습니다. 어,이 시스템 모니터링 분야에는이 업계에서 널리 참고되는 대표적인 프레임워크 세 가지가 있습니다. 어, 첫 번째는 구글 SRE에서 말하는네 가지 황금 신호라고 해서 골든지 시그널스. 그리고 두 번째는이 성능 분야에서 권의자인 브랜든 그래 유즈 메소드. 그리고 세 번째는 그라파나 랩스 CTO인 톰 윌키의 레드 메서드가 있습니다.이 세 가지는 각각 시스템을 서로 다른 관점에서 바라보는 모니터링 프레워크인데요. 간단히 말해서이 구글의 골든 시그널은 사용자의 경험과 서비스의 품질을 중심으로 하고이 USA는 시스템 리소스 중심 그리고 레드는 요청 기반 서비스 모니터링 중심이라고 할 수 있습니다. 어 그래서이 세 가지 프레임워크는 모니터링을 서로 다른 관점에서 바라보는 상호 보완적인 관계라고 할 수 있는데요.

우리 실무에서는이 세 가지를 적절히 조합해서 사용하면 좋습니다. 예를 들어서네 가지 골든 시그널로 서비스의 이상징 지우를 감지하고 레드로 어떤 API나 서비스에서 문제가 발생했는지를 검증을 하고 그리고 유즈로 CPU 메모리 디스크 아이오 같은 실제 병목 리소스를 분석하는 방식이죠. 어, 이렇게이 세 개의 브레워크를 이해하고 나시면 우리 모니터링 시스템을 만들 때 뭘 봐야 되지를 더 이상 고민하지 않게 되고 명확한 국제적인 기준으로 우리 시스템의 상태를 모니터링할 수 있게 되는 겁니다. 자, 그래서 오늘은 첫 번째 구글 SRE에서 정의한 4 골든 시그널네 가지 핵심 모니터링 지표에 대해서 말씀드려 보겠습니다. 자, 구글 SR 북에는 이런 표현이 나옵니다. 당신이네 가지 매트릭만 볼 수 있다면이네 가지에 집중하라. 자, 그네 가지가 뭔지 출발하시죠. 자, 4 골든 시그널 개요입니다. 지역을 하면네 가지 황금 신호라는 뜻이죠. 앞서 말씀드린 대로 자 구글 SRE 원문에는 이렇게 나와 있습니다. 사용자가 사용하는 시스템에서 딱네 가지네 가지의 지표만 볼 수 있다면이네 가지 매트릭에 집중해라라고 하고 있습니다.

어 모니터링 지표는 상당히 많죠. CPU 메모리 디스크 네트워크 가비 컬렉션 스레드 Q D 커넥션 풀류 타임아웃 응답 시간 스루프 동시 요청수 정말 많죠. 물려고 치면 정말 많은 지표를 볼 수 있겠죠. 이렇게 수많은 지표에서 구글은 제일 먼저이네 가지를 봐야 된다고 하고 있습니다. 그것은 바로 레이턴시 트래픽 에러 세츄레이션입니다. 하나씩 자세히 보겠습니다. 자, 먼저 첫 번째는이 레이턴시입니다. 요청 처리 시간이죠. 사용자가 요청을 보낸 순간부터 응답을 받는 순간까지 걸린 시간 즉 실제 사용자가 체감하는 응답 속도라고 할 수 있습니다. 여기에는 두 가지 중요한 포인트가 있는데요. 첫 번째는 레이턴시에 평균을 사용하면 안 된다는 것입니다. 평균 레이턴시가 100ms라고 해도 1%의 사용자는 5초를 기다리고 있을 수 있습니다. 평균은 이런 일부 사용자의 고통을 완전히 숨겨 버리죠. 그래서 레이턴시를 볼 때는 평균보다는 P95, P99와 같은 테일 레이턴시 즉 꼬리 지연이라고 하는이 테일 레이턴시를 함께 봐야 합니다.

다시 말해서 전체 요청에 95% 또는 99%가 얼마 안에 처리되는지를 봐야 된다는 말씀입니다. 최악 구간에 있는 사용자 경험까지 포함해서 봐야 된다는 것이죠. 자, 그리고 두 번째 포인트는이 성공 응답과 실패 응답의 레이턴시를 반드시 구분해야 한다는 것입니다. 어, 일부 실패 응답은 아주 빠르게 반환될 수 있기 때문에 실제 레이턴시에 함께 포함해 버리면 실패를 오히려이 전체 응답 시간이 좋아 보이는 외국이 발생할 수 있습니다. 그래서 실패 응답은 별도로 성공 응답과 분리해서 레이턴시를 추적해야 하는 것입니다. 자, 오른쪽이 그래프는 전체 응답 시간에 분포를 보여주고 있습니다. 평균은 100ms지만 일부 사용자는 5초라는 고통을 경험하고 있을 수 있습니다. 그래서 많은 서비스들은 평균 응답 시간보다는 P95, P99와 같은 꼬리 지연을 중요한 SLI 즉 서비스 수준 목표로 사용하는 경우가 많습니다. 어, 특히이 대규모 분산 시스템에서는 여러 서비스 호출 중에서 가장 느린 요청 하나가 전체 응답 시간을 결정할 수 있기 때문에 레이턴시 즉 꼬리 지은 문제가 훨씬 더 중요해집니다.

자, 이것은 이전에 더 테일 케일이라는 구글 논문 리뷰 영상에서 다룬 적이 있죠. 우측 상단에 링크를 걸어 놓을테니까 안 보신 분들은 꼭 보시기 바랍니다. 어 참고로 여기서이 구글를 볼지이 9호를 볼지는 우리 시스템의 성격과 도메인 특성에 따라서 달라질 수 있습니다. 우리 멤버십의 도메인 그리고 시스템 특징에 따라서 어떤 걸 볼지 선택하시면 되겠습니다. 자, 두 번째는 트래픽입니다. 지금 시스템에 얼마나 많은 요청이 누르고 있는가에 대한 지표입니다.이 이 트래픽은 서비스의 유형마다 측정 다리가 조금씩 다르죠. 웹 서비스는 초당 HTTP 요청수인 RPS. 그리고 스트리밍 서비스는 동시 세션수나 네트워크 아이오. 그리고 데이터베이스나 캐시는 TPS 즉 초당 트랜잭션 수로 보는데요. 자,이 트래픽 수치는 과부화로 인한 장애, 즉 과부화형 장애에서는이 다른 지표들의 선행 신호가 되는 경우가 많습니다. 그래서 중요한 지표인데요. 다시 말해서이 트래픽이 스파이크 즉 트래픽이지는 걸 먼저 실시간으로 감지를 하면 나머지 세 개의 지표 레이턴시 오류율 세추레이션이 나머지 세 개의 지표가 터지기 전에 먼저 조치를 취할 수 있게 됩니다.

왜냐하면 트래픽은 시스템에 들어오는 우하의 시작점이기 때문에 나머지 지표들에 직접적인 영향을 주기 때문입니다. 그래서네 가지 지표 중에서이 트래픽을 가장 먼저 실시간으로 보는 것이 좋습니다. 자, 그리고 세 번째는 에러율입니다. 전체 요청에서 실패한 요청의 비율이라고 할 수 있는데요. 어, 여기서도 주의할 점은 HTTP 505류만 봐서는 안 된다는 점입니다.이 구글 s리에서는 에러의 종류를 세 가지로 구분하고 있습니다. 첫 번째로 명시적인 실패. HTTP 500처럼이 프토콜 레벨에서 직접적으로 오류가 난 것이죠. 그리고 두 번째는 묵시적 실패입니다. HTTP 응답은 200 성공이지만 내용이 잘못된 경우입니다.이 묵시적인 실패는 단순히 인프한 모니터링으로 발견하기 어렵죠. 그래서 보통 우리이 엔드투 엔드 테스트나 어플리케이션 레벨에 검정이 필요한 겁니다. 참고로이 엔드투 엔드 테스트는 실제 사용자가 서비스를 사용하는 흐름 전체를 검증하는 테스트 방식인데요. 단순히 API가 200을 반환하는지만 보는게 아니라 실제로 주문이 잘 저장되었는지 결제가 잘 완료되었는지 즉 사용자가 원하는 결과가 정상적으로 나왔는지를 직접 확인하는 테스트 방식입니다.

자 그리고 세 번째는 정책적 실패입니다. 응답은 왔는데 우리 목표 즉 SO 우리 서비스 수준 목표를 조과해 버린 경우를 정책적 실패라고 합니다. 예를 들어서 1초 안에 응답하기로 우리 SO를 설정을 했는데 즉 목표를 1초 내로 응답한 것이라고 설정을 했는데 1.5초가 걸렸다면 결과 자체는 성공적이었을지 언정 우리 목표 관점으로 보면 실패를 한 것이죠. 다시 말해서 우리 비즈니스 목표 기준으로 봐야 된다는 것입니다.이 에러와 관련해서는 우리 예전 영상 에러 버짓을 설명드린 적이 있죠.이 이 영상도 한번 보시기 바랍니다. 오른쪽 상단에 링크를 걸어 두겠습니다.네 번째는 세츄레이션 즉 리소스 포화도입니다. 시스템에서 가장이 병목이 되는 리소스가 얼마나 한 개에 가까워지고 있는가를 보는 지표입니다. 여기서 핵심 포인트는 이겁니다. 많은 시스템들이이 리소스 100%가 되기 전에 이미 성능이 저하되기 시작합니다. 왜냐하면 리소스 사용률이 높아질수록 우리 대기열 Q가 급격히 증가하기 때문인데요. 그래서 목표 사용률 즉 유틸라이션 타겟을 미리 정해 두는 것이 중요합니다.

예를 들어서 CPU 80% 이상이면 위험과 같은 기준을 우리 팀에서 설정을 미리 해 두는 거죠. 물론 이런 임계값은 시스템의 특성과이 워크로드에 따라서 달라질 수는 있겠죠. 자, 세츄레이션을 위한 특정 대상은 CPU, 메모리, 쓰레드풀, Q의 길이, 그리고 디스크, 아이오, 네트워크, 대역폭 등이 있습니다. 자, 그리고이 앞서 봤던이 레이턴시 즉 지연 시간의 증가는 지금 보고 있는이 세츄레이션의 중요한 징후 중에 하나입니다. 우리 구글 SR에서도이 레이턴시 증가를 세츄레이션의 중요한 신호 중 하나라고 설명하고 있는데요. 특히이 P95, P99와 같이 즉 우리가 정한이 지연 꼬리가 갑자기 시작하면 어떤 리소스가 보화 상태에 가까워지고 있다는 건 아닌지 먼저 확인을 해 보셔야 한다는 것입니다. 자, 다시 한번 구글 SR에서는 리소스 중에서 가장 제약이 심한 것에 집중하라고 합니다. 병목이 중요하다는 것이죠. 자, 이렇게네 가지 지표를 모두 봤는데요.이네 가지는 서로 독립적이지 않습니다.이네 가지는 인과 사슬 관계에 있습니다.

우리이 과부화형 장애에서 자주 관찰되는 패턴이 있어요. 자, 그게 뭐냐면 트래픽이 급증하면 포화도 즉 리소스 포화도 세츄레이션이 올라가고 세츄레이션이 올라가면 처리가 지연되죠. 그리고 레이튼시가 증가하게 되면 결국 에러가 터지는 이런 인과 사슬 관계가 과부와 영에서는 많이 보이는 패턴이죠. 물론 항상이 순서는 아니겠죠. 예를 들어서 DB의 데드락이나 외부 API 장애처럼 드래픽이 증가하지 않았는데도 오류가 발생하는 경우도 있긴 하죠. 하지만 지금 설명드린 것은 과부화로 인한 장애, 과부화형 장에서는이 패턴이 아주 전형적으로 나타난다는 말씀입니다. 자, 그래서 우리 실무에서 모니터링 대시보드에이네 가지를 트래픽, 세츄레이션, 레이턴시, 에러이네 가지를 순서대로 배치를 해 두면 직관적으로 모니터링을 할 수 있겠죠. 왜냐하면 장애가 났을 때 눈이 자연스럽게 원인의 추적 방향 신호를 따라갈 수 있기 때문입니다. 자, 그래서 우리 멤버십들은 바로 체크해 보시면 좋을 것들을 제가 정리해 드리겠습니다. 자, 첫 번째로 지금 우리 대시보드를 한번 열어 보세요.이네 가지 지표가 잘 보이나요?

없으면 추가를 하고 잘 안 보이면 앞단에 배치하시기 바랍니다. 그리고 레이턴시를 평균이 아닌 P95, P95와 같이 꼬리 지연 즉 고통받는 사용자의 레이튼시를 보고 계신가요? 꼭 보시기 바랍니다. 대시보드에 추가해 주세요. 그리고 세 번째 오류를 분류하고 있나요? 단순히 명시적인 500 말고 우리 비즈니스 기준의 어떤 실패, 묵시적인 정책적인 실패를 같이 보고 계신가요? 아니라면 별도 지표로 추가하시기 바랍니다. 그리고네 번째이 포화도 세츄레이션의 목포 사용률을 미리 정하고 계신가요? 리소스가 포화되면 이미 늦을 수 있습니다. 미리 CPU 80% 이상이면 알림을 받도록 한다. 이렇게 기준을 정해서 바로 인식하고 계신가요? 자, 그리고 다섯 번째이네 가지 포골든 시그널을 한 화면에 배치하고 있나요? 인과 사슬 순서대로 트래픽 세추레이션 레이턴시 에러를 한 눈에 잘 보일 수 있도록 모니터링 테시보드를 구성하시길 바랍니다. 자, 지금 말씀드린이 지표들이 없으면 만드시면 되겠죠? 그리고 이미 있다 그러면 제대로 보고 있는지 점검하시기 바랍니다.

자, 그리고 실무에서 자주 보이는 실수도 말씀드리겠습니다. 혹시 해당되는게 없는지 체크해 보시기 바랍니다. 자, 먼저 CPU 메모리 같은 중요한 리소스만 보고 있다. 즉 세츄레이션 일부만 보고 있는 거죠. 레이튼시나 트래픽 오류율은 안 보고 있으면 안 됩니다. 그렇게 되면 어 CPU 메모리 서버는 멀쩡한데 사용자는 분노하는 상황이 있을 수도 있습니다. 두 번째 평균 응답 시간만 보는 경우입니다. 아까 말씀드렸죠. P99 P95 같은 꼬리 지원도 같이 보셔야 됩니다. 그리고 세 번째 500에만 본다. 요청이 성공적이어도 비즈니스 기준으로 잘못된 경우들이 있을 수 있겠죠. 그런 부분까지 체크를 하셔야 됩니다. 그래서 어플리케이션 레벨에서 검증을 필수적으로 하시는게 좋습니다. 자, 그리고 마지막으로네 개가 아니라 수십개를 보고 있다. 처음에는네 개였는데 모니터링 지표가 계속 추가하다 보니까 결국 장애 상황에서는 너무 많은 지표들 때문에 오히려 혼란스러운 상황이 될 수도 있습니다. 그래서 너무 많은 지표를 애매하게 보는 것보다 오늘 말씀드린이네 가지 황금 신호부터 제대로 보고 나서 추가적인 지표들을 보시기 바랍니다.

자, 마지막으로 정리하겠습니다. 포골든 시그널은 구글의 공식 프레모크에서 제시하는네 가지 모니터링 지표입니다. 그리고이네 가지는 인과 사슬 관계가 있습니다. 특히 과부화형 장애에서는 트래픽이 먼저 급정하면 세출레이션이 상승하고 응답 지연이 발생하면서 오류가 나는 패턴입니다. 그래서 먼저 트래픽이 먼저 튀는 걸 꼭 보시기 바랍니다. 그리고네 가지 중점적으로 보시고 점점 모니터링 수치를 늘려 나가시기 바랍니다. 자, 측정할 수 없으면 관리할 수 없고 관리할 수 없으면 개선할 수 없다는 말이 있죠. 오늘 강의는 이걸로 마치겠습니다. 자, 멤버심 여러분 늘 감사합니다. 여러분의 성장이이 채널에 가장 큰 보람입니다. 저도 더욱 분발해서 좋은 콘텐츠로 계속 찾아뵙겠습니다. 감사합니다.