네이버의 SRE(Search Reliability Engineering) 시스템

 

본 게시글은 NAVER Engineering의 [ Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템) ] 을 보고 정리하였습니다.

 

1. 들어가며

 

SRE란?

글로벌 스케일의 서비스를 제공하면서 어떻게 하면 시스템의 신뢰성을 보장할지 고민하는 기술 분야이자 방법론, 문화

보통의 SRE는 Site Reliability Engineering이지만 네이버 내부에서는 Site가 아닌 Search로 바꿔서 부름

네이버 검색시스템의 목표

• 많은 사용자가 동시에 검색어를 입력해도 서비스에 문제가 없어야 한다. - 대용량 처리 (High Throughput)
• 네이버 검색창에 검색어를 입력하면 1초안에는 결과가 나와야 한다. - 짧은 대기시간 (Low Latency)

→ 결국 장애가 일어나지 않는 것이 가장 중요하다

장애가 발생하면 대용량 처리와 짧은 대기시간을 보장할 수 없음

⁜ SRE는 장애를 예방하는 효과적인 활동이기 때문에 도입하게 되었다.

 

장애 분석에 대한 두가지 난제

1. 얼마나 비용 효율적인지 증명할 수 있는가?
   → 정확한 비용 측정 / 예측의 중요성
    에러발생으로 인한 손해보다 예측에 사용되는 비용이 더 효율적인지 증명해야 한다.
2. 에러가 발생하지 않았을 때, 예방 활동 덕분이었다는 것을 어떻게 증명할 수 있는가?
   → 정확하고 구체적인 경보 체계 확립 필요
   → 정확한 사후 분석 (post-mortem) 필요

 

결과적으로 네이버 검색시스템에서 바라보는 SRE의 목표는 다음 3가지이다.

1. 모든 검색 서비스 정상 동작
2. 1년 10분 이하 다운타임
3. 고비용 사후처리보다 저비용 사전예방

 

2. 네이버 검색시스템의 SRE

기존 시스템 운영 지표 관측 : 주요 검색 서비스에서 이상이 없었는지 또는 지금까지 발생하지 않았던 특이 케이스가 없었는지 확인 직접 일일이 확인

-> 직접 눈으로 확인해야 하다 보니 시간이 오래 걸려 비효율적

때문에 효율적인 정보 체계 도입

• 서비스 ID 발급 : 각 검색( Layer / 롤) 별로 ID가 통일이 안되어 있어서 하나의 아이디 체계로 모든 정보를 모으기 시작 (SRE 도입할 수 있었던 계기)
• 구조 가시화 : 검색 트래픽 요청의 흐름과 검색을 위해서 만들어진 데이터 흐름을 한눈에 볼 수 있어서 문제가 생겼을 때 원인 추적을 하고 원인과 결과를 구분하기 좋다.
• 성능 / 비용 측정 : 서비스 ID와 구조 가시화 정보가 모여서 첫 번째 수행한 과제. 결과물로 상위 레이어에서 유입된 트래픽이 하단으로 내려왔을 때 몇 배로 증폭이 되는지,  통합검색의 기여도를 따졌을 때 PC 통합검색과 모바일 통합검색의 기여도가 어떻게 바뀌는지 실시간으로 확인할 수 있게 되었다.

정보가 보이니 다양한 응용 방법 고민 시작
→ 장애 분석 업무에 도입
→ 장애가 발생하는 원인 중 대부분이 서버 다운. 어떤 서비스에서는 서버가 죽었을 때 아무런 일이 일어나지 않지만 어떤 서비스에선 서버 한대가 죽었을 때 Servie Outage가 발생. 이렇게 서비스마다 특성이 다르고 위험도가 다르다
→  네이버 검색시스템만의 가용량 지표 개발

 

일반적인 가용량 지표

Avaliability = MTBF / MTTR + MTBF
MTTR (Mean Time To Repair, 평균 복구 시간)
MTBF (Mean Time Betwwen Failures, 평균 무고장 시간)

일반적인 가용량 지표의 계산식은 위와 같지만 99.998% 보장한다 하더라도 1년에 10분이나 장애가 발생한 것이므로 정확한 지표가 되지 못한다.

대용량 서버 구조에서 노드 하나가 죽었을 때 영향도가 어떻게 되는지 측정
→ 형제 노드 또는 상단 노드로 부하가 전파되며 그것을 수치로 표현

새로운 방식 도입

• 부하 증가 배수 : 노드 하나가 죽었을 때 형제 노드가 가중해서 받는 부하량
• 최대 가용 배수 : 지금의 리소스 사용량을 측정하여 노드가 죽었을 때 감당할 수 있는 부하량을 계산

임계 상황 판단 : 부하 증가 배수 > 최대 가용 배수 인 상황일 때 노드 하나가 죽으면 Service Outage가 발생할 수도 있다고 판단

 

가용량 경보 시스템 운영 효과

부하 증가 배수와 최대 가용 배수를 조합해서 서비스 단위로 가용량 경보를 발생시키는 시스템을 2016년 12월에 구성을 하여 임계 상황 발생 횟수가 최대치 대비 약 90% 감소하는 성과를 이뤄냈다.
(단순히 경보만 하는 것이 아니고 SRE 담당자들이 매우 빠르게 1차 분석을 하여 어떤 원인 때문에 경보가 발생한 것으로 추측하고 어떠한 조치를 하는 것이 좋을 것 같다는 것을 3~5분 사이에 전달)

90% 감소 효과를 얻었으나 더 나은 서비스를 위하여 가용량 경보 시스템뿐만 아니라

• 성능, 비용 정보 Tagging, Mapping
• 서비스 단위 가용량 정보 계층별 취합 등

트래픽에 관련된 모든 정보를 보여주는 검색시스템 통합 대시보드를 개발하였고 오프라인으로 전광판까지 제작
(신호등 형태로 한눈에 네이버 검색시스템의 이상 유무를 확인할 수 있다)

 

SRE 업무 사이클

1. 새로운 지표 개발
2. → 관제 범위 확대
3. → 시스템 개발
4. → 새로운 방법론 개발 : 새로운 방법론으로 잡을 수 없는 장애가 발생
5. → 새로운 지표 개발(처음으로 돌아감)

선순환 사이클이지만 현실을 녹록지 않다.

 

SRE 담당자들이 겪는 어려움

엄청난 양의 경보 폭탄이 발생하여 담당자들에게 날아옴 : 9시간 동안 330건 경보 발생(평균 2분마다 1건 수준)

→ 경보 피로 발생
→ 필요해서 도입한 지표인데, 너무 많은 경보로 담당자의 스트레스가 가중
→ 경보 피로를 줄일 방법 도모

	긴급 대응 필요 사황	대응 불필요 사항
경보 발생	True Positive (실제 장애 상황)	False Positive (색인 업데이트, 캐시 갱신 등 시간이 흐르면 정상화 되는 상황)
경보 미발생	False Negative (장애가 발생했으나 경보가 울리지 않는 경우)	True Negative

거짓 정보

False Negative 사례는 실제로 있으면 안 되는 사례이다.
False Negative 사례를 줄이기 위해서 False Positive 경보를 만들어 내기 때문에 거의 없는 사례이기도 하고 실제로 3년 동안 1건 발생하는 거의 없는 케이스이긴 하지만 있으면 큰 문제가 발생한다.

False Positive는 경보 피로의 주범이므로 False Positive 경보를 줄이는 것이 목적

거짓 경보를 줄이기 위해 사용하는 방법

1. 경험치, 휴리스틱 : 그래프만 보고도 금방 장애 유무를 판단하는 것이 가능하지만. 숙달되지 않는 사람이라면 매우 어려워하여 개인차가 존재. 모든 SRE 담당자가 균일하게 판단하는 것이 불가능하다.
2. 경보 분석 자동화 : 다양한 장애 케이스에 대해서 모든 경우에 대한 대응 자동화는 불가능
   → 대신 빠른 대응을 위해 필요한 데이터들을 미리 모아주고 빠른 의사 결정을 위해 필요한 기본적인 상황 판단 자동화 구현

자동 경보 분석 예제

1. 그래프 모양을 보고 쿼리의 유입이 짧은 시간에 급격하게 증가하였을 때 만약 캐시 서버의 Hit Ratio가 줄어들었으면 캐시가 리스타트되었다고 볼 수 있으므로 이런 경우는 의도된 상황이 때문에 경보를 보지 않아도 된다.

이것을 사람이 보고 판단하는 것이 아닌 자동화를 하기 위하여 기울기의 높낮이에 따라 7단계의 기울기로 변환
(1: 매우 급격한 하강, 2: 급격한 하강, 3: 완만한 하강, 4: 변화 없음, 5: 완만한 상승, 6: 급격한 상승, 7: 매우 급격한 상승)
각 지표 그래프를 부호로 인코딩 후 지정한 패턴에 매칭 되면 무시해도 되는 경보라고 판단하여 넘어가게 된다.

2. 어떠한 이슈로 인해 한대의 서버만 이상이 발생한다면 지표 데이터의 유사도를 보고 판단할 수 있다.
코사인 유사도를 사용하여 판단. 
코사인 유사도 < 0.975 → 가용량 문제 발생 전에 조치 필요 → 자동 경보 분석

 

장애관제 및 예보를 수행하고 경험치를 통해서 경보를 끊임없이 줄이는 것으로 SRE 업무가 가지는 효과성은 입증할 수 있다.

하지만 효율성을 어떻게 입증할 것인지 문제가 있습니다. 그래서 만든 두 가지 철학이 있습니다.

NAVER만의 SRE 핵심 철학 2가지.

1. 거시적 관점의 문제 분석 (Macro Analysis)
2. 장애관제 방식 : Blackbox Monitoring

첫 번째로 거시적 관점의 문제 분석입니다.

거시적, 미시적 분석이라는 용어는 경제학에서 사용하는 단어이지만, 네이버 측에서 차용을 하여서 사용
일반적인 서비스나 시스템 담당자들은 자신의 담당 영역을 분석을 하지만 요즘은 점점 하나의 서비스가 여러 서비스랑 동시에 움직이는 서비스가 많아졌기 때문에 각각의 서비스를 단독으로 분석하는 것이 아닌 거시적 관점에서 한꺼번에 분석합니다.
거시적 관점에서 패턴을 분석하여 각각의 서비스가 문제가 있는지 전체 서비스가 문제가 있는지 알게 되며 또 외부 공격인지 내부 공격인지 알 수 있고 공격인지 아닌지도 알 수 있습니다.

이렇게 거시적 관점에서 분석을 하게 되면 문제 분석하는 시간이 극단적으로 단축됩니다.

두 번째로는 Blackbox Monitoring입니다.

일부 로그나 데이터를 모르거나 감춰져 있어도 볼 수 있는 전체 데이터를 보고 문제를 파악하는 방식.
일반적으로 검색 트래픽이 들어오면 상위 계층부터 순차적으로 트래픽이 내려온다. 이때 갑자기 스파이크가 발생하였을 때 해당 계층의 로그나 데이터가 없어도 분석을 할 줄 알아야 한다.
상단 하단 계층의 데이터를 같이 분석하여 데이터 없이도 분석을 할 수 있는 여러 가지 방법론들을 개발하고 있다.

	SRE 스타일	개발자 스타일
문제 분석 관점	Macro Analysis	Micro Analysis
장애관제 방식	Blackbox Monitoring	Whitebox Monitoring

 

SRE 스타일은 나무보다는 숲을 보는 관점이며 일부 정보가 확보되지 않은 상태에서도 정확한 상환 판단이 가능하다.

이런 방법론을 통해서 시간 효율성과 비용 효율성을 극대화할 수 있고, 장해 관제에 있어서 개발 시스템이나 서비스 담당자들이 있음에도 불구하고 독립된 가치를 확보할 수 있다.

 

3. 실제 사례 소개

실제 장애가 발생했던 사례나 SRE에 대한 문화 사람에 대해서 설명

우리 일상과 밀접한 네이버 검색 시스템

사람들의 생체주기를 따라가는 트래픽 : 주말보다 평일에 트래픽이 많이 들어오고 공휴일에도 평일보다는 주말의 트래픽 그래프를 따라간다.

평일에는 출근 시간인 오전, 오후에 증가하며 점심시간, 퇴근시간에 감소된다.
주말이나 공휴일에는 새벽 말고는 비슷한 트래픽을 유지한다.

네이버 검색 시스템의 트래픽은 요일과 굉장히 밀접한 관련이 있으며 특별한 이슈가 없을 때는 거의 일정한 패턴을 나타내고 있다.

만약에 평소와 다르게 갑자기 트래픽이 상승하거나 하강하는 모양이 나타나면 무언가 이상한 문제(Anomaly)가 발생한 것으로 판단하여 SRE 담당자는 집중적으로 분석을 한다.

 

2017년 11월 15일 포항 지진

규모 5.4 본진 발생 직후 평소 대비 약 3배 트래픽이 유입되었으며 그 이후 여진 발생 및 수능 연기 발표 때 트래픽이 증가하였다.
천재지변이 있을 땐 특징이 있는데 대부분은 특정 중복된 검색어가 많이 들어온다는 특성이 있다.
그래서 이러한 경우엔 내부적으로 검색 결과를 재활용하기 위한 캐시 서버의 효율이 올라가서 증가한 트래픽을 잘 처리할 수 있다.

스포츠 이벤트

스포츠 이벤트에도 트래픽이 민감하게 반응한다.
축구경기의 경우 전반전과 후반전 경기중엔 경기에 집중하기 때문에 검색 유입이 줄어들지만 경기 쉬는 시간이나 경기 후에는 평소보다 증가하는 패턴을 보인다. 골 득실이 있을 경우에도 트래픽이 증가한다.

PC의 경우 축구 경기중에 평소보다 감소된 모습을 보이지만 모바일은 크게 차이가 없으며 골 득실이 발생하거나 하프타임, 경기 후에 트래픽 증가가 더 민감하게 반응한다.

우리나라뿐만 아니라 다른 나라의 경기에 관련해서도 트래픽이 영향이 있는데 그때 상황은 조별예선은 골 득실의 점수가 중요하기 때문에 트래픽이 증가하였다.

연장전도 마찬가지로 트래픽이 감소하였으며 이슈가 큰 경기일수록 트래픽 증가율이 크다.

방송 / 연예인 이슈

방송 중 출연자의 네이버 프로필 사진이 변경되었다는 일이 언급된 직후 트래픽이 순간적으로 급증한 사건이 있었다

캐시 서버의 영향을 많이 받아 큰 사건으로 이어지진 않았다

그 외 흔히 겪는 다양한 이슈들

개편과 버전 변경 : 버전 변경 시 트래픽 양상 변화되어 기존의 통계치가 무효화되어 적절한 경보를 발생시키기 어려우며 조작 실수나 버그 유입 가능성이 있다.

분석용 데이터 수집 / 부하 테스트 : 실제 사용자 트래픽이 아니지만 서비스에 영향을 줄 수 있다.

지표 수집 문제 : 지표 수집에 문제가 생겨서 거짓 경보가 발생하는 경우가 많다. Mapping 정보에 문제가 생기거나 수집 자체가 잘 안 되는 경우 등이 원인

각 Case 별로 상황에 따른 대처를 연구하면서 대처법들을 고도화시키고 있다.

 

4. Search Reliability Engineer

SRE들이 주로 하는 고민은

• 지금까지 겪어본 적 없는 문제들
• 언제 어디서 어떻게 발생할지 보르는 Incident(예기치 않았던 이벤트나 사건)
• 모든 경우의 수를 다 자동화하거나 시스템화하는 것은 불가능

문제는 SRE 업무 담당자의 스트레스가 과중되어 업무에 지장이 생기는 것.
나아가서 안정적인 시스템 운용에 지장이 생기는 것이다.

 

안정적인 사람이 만들고 운영하는 안정적인 시스템

SRE는 시스템이 안정적으로 돌아가게 만들기 위한 '모든' 활동 이므로 개발자 / 엔지니어의 심리적, 정신적 안정감도 시스템의 Reliability에 포함이 되어있다.

새벽, 주말의 장애관제

전체 구성원이 365일 24시간 대응할 수는 없으므로 Incident 발생 시 필요한 두 가지 역할을 정의하였다.

Incident Commander (IC)	Scribe
전체 Incident 통제 역할 상환 판단과 의사 결정 리더 or 외부 조직과 대화	서기, 필경사 역할 판단에 필요한 지표 수집 시간대 별로 상세하게 기록

별도의 구성원으로 개별 Rotation으로 돌아가고 있으며 IC는 리더급, Scribe는 실무자로 구성되어 있다.

경보시스템에서 Incident가 발생하면 각각 IC와 Scribe에게 경보가 전달되며 각각 담당업무를 진행하여 장애가 발생하지 않도록 하고 있다.

보통 이러한 Incident가 발생하는 경우는 자택에 있을 때 발생하므로 원격으로 근무를 하는데, 채팅으로 의사소통이 많은 경우가 있어 쳇봇을 활용하고 있다.

담당자가 연락이 되지 않을 때 다른 담당자에게 연락을 하거나 간단하게 지표를 확인할 때 기능들을 쉽게 구현을 하여 활용하고 있다.

이와 같이 스트레스를 최소화하기 위해서 많은 노력을 하고 있다.

해외에서도 마찬가지로 이러한 문제를 겪고 있다. 의료계, 코미디, 스포츠 등에서 심리적 안전을 어떻게 지키는지 참고를 하여 SRE 담당자도 건강하게 장애관제를 할 수 있도록 고민을 많이 하고 있다.

SRE 문화

비난 없는 사후 분석 (Blameless Postmortem) : 현실에서는 단순히 비난이 없는 것보다 사실에 기반하여 분석하는 것이 더 중요. 비난하지 않는 것에 너무 집중을 하다 보면 실제로 공유되어야 하는 사실들이 숨겨지는 경우가 있기 때문에 팩트 기반으로 사건을 잘 분석할 수 있도록 강조한다.

SRE 홍보 활동 : 블로그, 정기 Report 발행, 교육 등 SRE 문화를 전파한다.

 

네이버 검색시스템의 노력

정책적, 제도적 해결책 고민 : 비상 상황 대응 방법 국체화. 구성원 별 역할 체계화

계속 발전하는 SRE : Anomaly Detection, Simulation 등 다양한 측면에서 발전을 위해 노력 중

기술적인 노력 : 데이터 마이닝 기법을 적용하여 Anomaly Detection을 어떻게 고도화할 것인가. 딥러닝을 활용하여 시스템 내부에서 발생하는 변화들을 정확하게 예측할 수 있을까 하는 시뮬레이션 도구를 개발하고 있다.

 

마치며

Search Reliability Engineering

주변에서 아무도 해보지 않은 분야

참고할 사례가 적다

직접 두들겨 맞으면서 개선점을 찾아가는 방법뿐

 

어렵지만 보람을 많이 느낄 수 있는 업무이다.