본문 바로가기

Back-End

네이버 검색의 서비스 신뢰도 높이기 - SRE

들어가기 전

나는 B2C 서비스는 조그만 회사에서 밖에 경험해 보지 못했다. 그래서 네이버나 카카오와 같은 대기업이 요구하는 신뢰성에 비하면 항상 후한(?) 신뢰성만을 지켜왔다. 그렇기 때문에, 대규모 서비스에서 신뢰성 보장을 위해서 어떠한 노력을 하는지에 대해서는 전혀 알고 있지 않다.

 

그래서 이번 포스팅을 통해 사이트 신뢰성을 지키기 위해 무엇을 해야하는지 어떠한 점이 어려운지를 정리해 보려한다. ( 네이버 검색 SRE 시스템 블로깅을 참고로.... )

신뢰성이란? 365일, 24시간 언제나 서비스가 정상적으로 무중단 제공되는 특성

네이버 검색 서비스에 SRE 도입한 계기

  1. 예측 할 수 없는 상황 : 지진이 일어나 검색 요청량이 폭증 하는 경우
  2. 스케일이 커질수록 새로운 방법론 필요

16년 9월 경주에서 대형 지진이 일어났을 때, 전체 시스템이 마비되어 증상 완화, 원인파악, 영향도 분석까지 약 1시간이 걸리고 재발 방지책까지 포함한 사후 분석(postmortem)에는 이틀이 걸렸다고 한다.

 

장애 위험 탐지(detection)

  • 위험도 탐지 기준은 어떻게? - 파편화된 기준 적용? 확장성 있는 기준 적용?
    => 범용적 + 직관적 + 쉬운 기준

사후 분석(postmortem) 문화

개발자들이 귀찮아 하는 것 중 하나가 문제가 터지고 난 후에 문서화하는 것이다... ( 나만 그런가...? )

네이버에서는 사건 사고의 문서화 문화를 도입하여 상당히 큰 효과를 거두었다고 한다.

 

  • 서버 단위 집계 X -> 서비스 단위 집계 필요

위 그림은 네이버 지표 대시보드인데, 이렇게 쌓는데도 2년의 시간이 걸렸다고 한다. 이 고도화된 지표를통해 경보 시스템을 만들었는데, 어떤 경보가 좋은 경보일까?

  • 경보가 너무 많이 발생하면? -> 업무 피로도, 문제에 무뎌짐
  • 경보가 너무 조금 발생하면? -> 중요한 정보를 놓침

그렇다면 네이버에서는 어떻게 고도화 하고 있을까?

  • 공휴일의 트래픽 패턴을 학습하여 경보에 반영하기
  • 시스템 개편에 따른 트래픽 전환을 자동으로 탐지하기
  • 조건에 걸리더라도 바로 발송하는 것이 아니라 문제가 확정될 때까지 기다리기

SRE 도입의 효과

정리

SRE와 같은 활동에는 항상 100% 정답은 없는거 같다. 다양한 상황, 시스템이 존재하기 때문이다. 그렇기 때문에 실질적인 문제의 해결에 집중하고, 하나씩 개선해 나가는 것이 답인거 같다.

 

참고

http://www.yes24.com/Product/Goods/23437813?Acode=101

 

Site Reliability Engineering: How Google Runs Production Systems

 

www.yes24.com

https://d2.naver.com/helloworld/2047663