해당 게시물은
NAVER D2사이트를 참고 및 인용 하였음을 알려드립니다.
정보 출처: https://d2.naver.com/helloworld/2047663
💬
네이버 검색의 SRE 시스템
네이버 검색은 국내 최대 규모의 트래픽과 데이터를 다루는 대용량 분산 시스템이다. 수만 대의 서버에서 수백 개의 검색 서비스가 운영되고 있으며, 하루에도 몇 번씩 크고 작은 신규 개발과 유지보수 활동이 활발하게 반영되고 있다. 이렇게 거대하고 역동적인 시스템이 안정적으로 운영되려면, 그리고 항상 최고의 성능을 보장하려면 어떤 노력이 필요할까? 단순히 많은 비용을 들여서 서버 장비를 증설하거나 유능한 개발자를 많이 채용하면 될까? 당연하게도, 이 문제를 은탄환 같은 만능 해결책이나 딱 떨어지는 정답이 존재하지는 않다. 하지만 수많은 시행착오를 겪어가면서 노하우를 차곡 차곡 쌓아나가다 보면 어느 정도 쓸 만한 현실적인 해결책은 만들어 낼 수 있을 것이다.
이렇게 스케일이 큰 인터넷 서비스를 개발하고 운영하기 위한 방법론을 모으고 모아서 잘 정리한 것이 바로 Site Reliability Engineering(이하 SRE)이다. 이 글에서는 네이버 검색에서 SRE를 도입한 계기를 소개하고, 실제로 어떻게 활용하고 있는지, 그리고 어떤 성과로 이어지고 있는지 소개해 준다.
💬
SRE 도입 계기
대부분의 인터넷 서비스가 마찬가지이지만, 네이버 검색은 특히 온 국민이 사용하는 공공재나 다름없기 때문에 더욱 장애에 민감한 특성을 가지고 있다. 다르게 말하자면 '신뢰성이 매우 중요한 시스템'인데, 여기서 신뢰성이란 365일, 24시간 언제나 서비스가 정상적으로 무중단 제공되는 특성을 의미한다. 서비스의 규모가 커질수록 아래와 같은 이유로 시스템의 신뢰성을 보장하는 일이 점점 어려워진다.
- 첫 번째, 스케일이 한 단계씩 커질 때마다 새로운 방법론이 필요하다.
처리해야 하는 데이터의 규모는 기하급수적으로 증가하고, 그만큼 필요한 서버 장비의 수나 시스템의 종류도 계속 늘어난다. 하지만 숙련된 엔지니어의 숫자는 서비스의 성장 속도만큼 빠르게 증가하기 어렵다. 심지어 엔지니어의 수가 비슷한 속도로 늘어난다고 해도 문제는 해결되지 않는다. 왜냐하면 조직이든 시스템이든 규모가 커질수록 복잡도가 높아지고 관리가 어려워져 점점 효율이 떨어지기 때문이다.
- 두 번째, 예측이 불가능한 일들이 일어난다.
지진과 같은 재난이나 각종 사회, 경제, 문화적으로 우리나라 사람들의 관심이 집중될 만한 이슈가 발생하면 네이버 검색으로 유입되는 요청량이 순간적으로 몇 배씩 폭증한다. 이런 사건 사고는 대부분 사전에 예측이 불가능하기 때문에 검색 시스템 입장에서는 미리 준비하거나 대응하기가 매우 어렵다.
실제로 지난 2016년 9월 경주에서 전례없는 규모의 대형 지진이 일어났을 때, 네이버 통합검색 전체 시스템에서 약 10분간 검색을 수행할 수 없는 장애가 발생했다. 당시 검색 시스템을 구성하는 수만 대의 서버 중에서 단 8대를 차지하는 작은 서비스에서 가용량 문제가 있었는데, 이 작은 문제가 순식간에 전체 통합검색의 장애로 이어졌다. 아주 작은 문제라고 하더라도 전체 시스템을 순식간에 마비시킬 수 있다는 것을 보여준 사례였다. 이후 증상 완화와 원인 파악, 영향도 분석까지 총 1시간에 가까운 시간이 소요되었고 재발 방지책까지 포함한 사후 분석(postmortem)이 완료되는 데 총 48시간이나 걸렸다.
당시 상황에서는 충분히 빠른 대응이었지만 이대로는 앞으로 더 커질 규모를 감당할 수 없다는 위기의식을 느끼게 되었다. 이 사건을 계기로 네이버 검색에서는 SRE라는 기술의 도입을 적극적으로 검토하기 시작했다.
[그림1] 작은 원인에서 시작된 장애는 순식간에 전체 통합검색 시스템을 마비시켰다.
💬
네이버 검색에 딱 맞는 SRE
SRE를 위한 모니터링 도구, 자동화 도구는 이미 많이 만들어져 있었다. 하지만 대규모로 구축하여 오랜 시간 운영해 온 시스템에 이 모든 도구를 적용하는 것은 쉬운 일이 아니었다. 그래서 네이버 검색에서는 어떤 도구를 사용할지 고민하기보다는, 일단 어떤 문제가 존재하는지를 먼저 파악하고 분석하는 작업에 집중했다. 취약한 부분과 개선이 필요한 부분이 무엇인지 정리한 뒤 하나씩 차근차근 극복해 나가자는 전략이었다.
💬
비상 상황 대응 체계
2016년 경주 지진처럼 갑자기 발생하는 비상 상황에 대한 대응 체계가 없었다. 그래서 먼저 네이버 검색 시스템이 맞이할 수 있는 비상 상황(contingency)을 아래와 같이 크게 두 가지로 정의하고 각 상황에서 어떻게 행동해야 하는지 대응 체계를 만들었다.
- 첫 번째, 자연 재해나 국가적 이슈에 의해 갑자기 트래픽이 폭증하는 상황이다. 이 상황은 지진 등 이슈의 주제가 되는 특정 검색어가 집중적으로 증폭된다는 특징이 있다. 중복된 검색 요청이 많을 경우 캐시 서버를 최대한 활용하는 방법으로 충격을 완화할 수 있다는 점에 착안하여 대응 방안을 정리했다. 그리고 이 원리를 응용하여 특정 조건을 만족하는 경우에는 자동으로 비상 대응 모드로 전환되는 자동화 시스템도 마련했다.
[그림2] 2019년 2월에 발생한 포항 지진 상황에서는 트래픽이 증가하기 전에 비상 모드가 먼저 발동 되었다.
- 두 번째, 경쟁사의 검색 서비스가 동작하지 않아 트래픽이 모두 네이버로 집중되는 상황이다. 이 상황에서는 모든 종류의 검색어가 골고루 증폭되기 때문에 캐시 서버로는 대응이 어렵다. 하지만 검색 시장 점유율 기반으로 총 유입 트래픽의 규모가 어느 정도일지 유추할 수 있기 때문에 사전에 가용량 대비를 해두는 것이 가능하다.
이 내용은 네이버 검색 블로그 - 지진에도 흔들리지 않는 네이버 검색 시스템 1편에서도 소개한 적이 있다.
💬
장애 위험 탐지(detection)
시스템 내부에서 오류가 발생하거나 실제 사용자 장애 상황이 되면 시스템 경보 또는 제보를 통해 담당자가 이를 인지한다. 하지만 이렇게 문제가 발생한 다음에 하는 대응은, 아무리 신속 정확하게 처리된다고 하더라도 이미 복구하기 어려운 손실을 동반하고 있는 경우가 많다. 그래서 문제가 발생하기 전에 미리 '위험을 탐지'하여 예방하는 것이 중요하다.
이렇게 장애 발생 전에 '위험도 판단'을 하려면 특정한 '기준'이 필요할 텐데 이 '기준'은 어떻게 정의해야 할까? 만약 서비스마다 특성이 다르다는 이유로 복잡하고 파편화된 기준을 적용하면 정말 긴급한 상황에서 직관적으로 판단하기 어려울 것이다. 쉽고 간단한, 그러면서도 확장성이 있는 규칙이 필요하다.
그리고 이미 장애가 발생한 상황에서도 이 기준은 여전히 유용하다. 지진으로 통합검색 전체가 동작하지 않았을 때에도 가장 절실하게 필요했던 것은 바로 각 서비스별 위험도 판단 기준이었다. 그 기준이 있어야 어떤 서비스가 병목인지, 어느 서비스가 회복되었고 어느 서비스가 여전히 위험한지를 빠르게 확인하고 대처할 수 있기 때문이다.
고민 끝에 네이버 검색에서는 범용적으로 사용할 수 있는 가용량 지표를 개발했다. 공식이 단순하고 직관적이라 누구나 숫자 하나로 쉽게 시스템의 상태를 인지할 수 있으면서도, 서비스의 규모나 성격과 상관없이 적용해볼 수 있는 방법이었다. 2016년 말, 이 새로운 가용량 지표를 도입했더니 1년도 안 되는 기간 동안 문제 상황이 90% 가까이 해소되었다. 그리고 2020년인 현재까지도 유용하게 잘 활용되고 있다. (본문 작성일: 2020.02.11)
[그림3] 부하증가배수와 최대가용배수를 이용한 임계 상황 판단 방법
자세한 가용량 공식과 적용 방법은 네이버 검색 블로그 - 지진에도 흔들리지 않는 네이버 검색 시스템 2편에서 확인할 수 있다.
💬
사후 분석(postmortem) 문화
사후 분석 문화가 잘 형성되는 것이 중요한 이유는, 시스템에서 발생하는 여러 가지 사건 사고와 여기서 얻는 좋은 교훈이 잘 쌓여서 나중에 복리로 문제 해결 효과를 만들어 내기 때문이다. 네이버 검색에서는 장애 사례에 대한 사후 분석 결과가 잘 누적되지 않고 있었다. 장애가 발생했을 때 복구에 집중하느라 내용 공유가 잘 되지 않거나 장애가 해결된 뒤에도 사후 분석 내용이 잘 전파되지 않는 등 여러 측면에서 개선이 필요한 상황이었다.
SRE 팀에서는 이 문제를 해결하기 위해 약 3개월 이상의 기간 동안 사후 분석 보고서(postmortem report)를 직접 작성하여 예시를 보여주었다. 사후 분석 보고서가 얼마나 유용하고 중요한지를 직접 보여줌으로써 자연스럽게 문화가 형성되도록 한 것이다. 이 방법은 천천히 효과가 발생했고, 약 3년이 흐른 현재 모든 엔지니어가 요청 없이도 자율적으로 사후 분석 보고서를 작성하고 있다. 문화 정착에는 시간이 걸리지만 효과는 강력하다.
몇 가지 재미있는 분석 사례를 2018년 DEVIEW 발표 - Search Reliability Engineering에서 소개했다.
[그림4] 장애가 발생할 때마다 엔지니어가 자율적으로 사후 분석 보고서를 작성하는 문화가 정착되었다
💬
전체 시스템을 한눈에 보기
SRE 도입 전 네이버 검색에서는 문제 해결에 꼭 필요한 주요 정보를 적절한 시점에 바로 획득하기가 어려웠다. 워낙 시스템이 거대하고 수많은 시스템과 조직이 엮여 있었기 때문에 통계 정보를 수작업으로 취합하거나 담당자를 찾아 문의하는 방식으로 문제를 해결하는 경우가 많았다. 이 문제는 상황 판단과 의사 결정을 느리게 하고, 커뮤니케이션 과정에서 잘못된 정보가 전달될 확률을 높여, 원활한 장애 대응에 큰 장애물이 되었다. 그래서 이런 수작업이나 불필요한 커뮤니케이션을 줄이는 작업을 시작했다.
네이버 검색에서는 일단 오래 전부터 사용하던 모니터링 시스템이 존재했고 각종 주요 지표가 잘 쌓이고 있었다. 하지만 모든 지표는 서버 단위로 집계되고 있어, 서비스 단위로는 어떤 일이 발생하고 있는지, 그리고 전체 시스템 관점에서 어떤 문제가 있는지 한눈에 볼 방법이 없었다.
그래서 SRE 팀은 먼저 서비스별 고유 ID를 발급하는 일부터 시작했다. 서버 단위로 잘 수집된 지표가 각각 어떤 서비스의 지표로 이어져야 하는지 '메타 정보'를 하나씩 추가해 나가는 것이었다. 그리고 이렇게 만들어진 서비스 ID와 연계하여 담당자 정보도 직접 관리했다. 장애의 빠른 해결을 위해서는 항상 최신화된 담당자 정보가 필요했기 때문이다. 이렇게 서비스 ID와 담당자 정보 관리 체계를 전체 도입하는 데 거의 2년의 시간이 걸렸다. 그리고 마침내, 이렇게 모인 메타 정보와 지표를 엮어서 네이버 검색 시스템을 한눈에 볼 수 있는 대시보드가 만들어졌다.
[그림5] 대시보드에서는 네이버 검색 시스템의 주요 지표를 한 화면에 요약하여 보여준다.
💬
경보 시스템 고도화
대시보드의 완성으로 중요한 지표를 한눈에 볼 수 있게 되자, 자연스럽게 이 지표에 문제가 생겼을 때 경보를 보내줬으면 좋겠다는 요구사항이 나왔다. 예를 들어, 프로그램 오류가 없더라도 트래픽이 갑자기 폭증하거나 반대로 갑자기 트래픽 유입이 중단되는 경우, 서비스에 중대한 변화가 발생했거나 앞으로 발생할 확률이 높다. 이러한 신호를 놓치지 않고 잘 감시하기 위하여 다양한 지표에 각양각색의 기준으로 경보를 걸기 시작했다.
처음에는 이런 지표 변화를 거의 실시간에 가깝게 파악할 수 있었기 때문에 매우 유용했다. 하지만 시간이 흐를수록 우리가 만든 경보의 규칙에 포함되지 않는 예외 경우가 점점 발견되기 시작했고, 갈수록 경보 발생 수에 비해 유용한 정보의 비율이 낮아졌다. 심지어 하루에 수백 통의 경보 메일을 받는 날도 있었는데, 이런 날은 거의 다른 업무 진행이 되지 않을 정도로 큰 불편함을 겪어야 했다. SRE 업무가 성숙해지려면 경보의 고도화가 꼭 필요했다.
경보는 너무 적게 발생하면 중요한 정보를 놓치기 쉽고, 너무 많이 발생하면 불필요한 스트레스와 피로를 유발하기 때문에 적당한 수준을 잘 유지하는 것이 중요하다. 적당한 빈도로 핵심적인 정보만 정확하게 잘 전달하려면 결국 지표 분석을 일정 부분 자동화해야 한다. SRE가 경보를 받고 나서 판단하는 경험적인 규칙과 원리를 경보 시스템에 직접 구현하여 자동으로 분석하게 만들었다. 분석 결과에 따라 아예 경보 발생 자체를 막는 방법이었다. 몇 가지 지표를 조합하여 확인하여 우리가 미리 알고 있는 패턴을 추출할 수 있었고 이 패턴을 활용해 경보 발생 빈도를 대폭 조절할 수 있었다.
자세한 패턴 분석 방식은 네이버 검색의 스마트한 경보 시스템 포스트에서 소개했다.
이뿐만 아니라, 시스템 개편에 따른 트래픽 전환을 자동으로 탐지하거나, 조건에 걸리더라도 경보를 바로 발송하는 것이 아니라 문제가 확정될 때까지 기다리거나, 공휴일의 트래픽 패턴을 학습하여 경보에 반영하는 등 다양한 기법을 계속해서 연구하고 도입하고 있다. 이렇게 네이버 SRE의 경보 시스템은 지속적인 노력을 통해 점점 더 정교하게 다듬어지는 중이다.
[그림6] 하인리히의 1:29:300 법칙에 따라 중대한 장애가 발생하기 전에 일어나는 경미한 사고를 정확히 탐지하여 알리는 것이 경보의 역할이다.
💬
SRE의 효과
SRE는 서비스를 직접 구현하지도 않고, 장애가 발생한 서버를 직접 재구동하거나 버그 패치를 만들지도 않는다. 하지만 장애가 발생했을 때 모든 문제가 해결될 때까지의 시간을 대폭 단축시키고, 장애 발생 자체를 원천적으로 차단하는 중요한 역할을 한다.
이상 징후가 탐지된 시점부터 모든 문제가 해결되고 재발 방지 대책까지 만들어지기까지 여러 과정을 거치는데, 여기서 SRE는 줄일 수 있는 시간을 가능하면 최대한 압축하여 문제가 빠르게 해결되도록 돕는다. 예를 들면, 이상 징후 탐지를 자동화하고 전체 시스템을 한눈에 볼 수 있도록 대시보드를 만들어 커뮤니케이션 및 의사 결정 시간을 단축시킨다. 또한 장애에 직접 대응해야 하는 서비스 담당자가 복구와 상세 원인 파악에 집중하는 동안, 외부 영향도 파악을 대신 수행하여 시간 낭비를 막아준다.
[그림7] 네이버 검색 SRE는 장애 복구와 상세 원인 분석을 제외한 활동에 필요한 시간을 최소화한다.
네이버 검색에서는 이렇게 SRE가 도입된 최근 3년 동안, 엄청나게 장애 비율이 감소했다. 2017년 1,311건의 업데이트가 진행되는 동안 57건의 크고 작은 장애가 발생하여 4.35%의 장애 비율을 기록했는데, 2018년에는 훨씬 많은 2,110건의 업데이트를 하면서도 2017년보다 더 적은 49건의 장애만 발생했다. 비율은 절반 수준인 2.32%이다. 심지어 2019년에는 여기서 더 발전하여 2,273건의 업데이트를 하는 동안 22건의 장애만 발생, 0.97%의 장애 비율을 기록했다. 이 수치를 통해 SRE 활동이 장애 예방에 얼마나 큰 도움이 되었는지를 유추해볼 수 있다.
[그림8] 최근 네이버 검색에서는 장애 발생 빈도가 매년 절반 수준으로 떨어지고 있다.
💬
마치며
SRE 활동을 하면서 뼈저리게 느끼는 것은 100% 완벽한 시스템이나 방법론은 존재하지 않는다는 것이다. 아무리 지속적으로 안정화 작업을 하더라도 언젠가는 예기치 못했던, 전에는 겪어본 적 없는 사건 사고가 발생한다. 이러한 불확실함 속에서도 지속적인 성과를 내기 위해서는 완벽한 도구나 방법론을 찾기보다는 실질적인 문제의 해결에 집중해야 한다. 너무나 많은 경우의 수, 복잡한 상호작용 속에서 세상에 존재할지 모를 완벽한 해답만 찾아 헤매다 보면 정작 눈앞의 문제조차 해결하지 못하고 수렁에 빠질 수 있기 때문이다.
그리고 포기하지 않고 끊임없이 개선해 나가는 끈기의 중요성도 알게 되었다. 정답이 없고 100%가 없다는 말은 다르게 이야기하면 끝이 없다는 뜻이다. 끝없이 나타나는 새로운 문제를 매일매일 풀어야 하고, 그때마다 수많은 시행착오를 겪을 수 밖에 없다. 하지만 이 과정을 차근차근 잘 극복해 나가다 보면 어느새 시스템이 점점 개선되는 모습을 볼 수 있다.
마지막으로 강조하고 싶은 것은 바로 도메인 지식과 전문가의 필요성이다. 워낙 크고 복잡한 시스템을 다뤄야 하기 때문에 범용적인 접근법만으로는 가시적인 성과를 얻기 힘들 수 있다. 해당 도메인에 정통한 전문가가 구석구석 찾아가서 최적화하지 않으면 생각보다 SRE의 효과를 누리기 어려울 것이다. 네이버 검색 SRE 시스템에서도 검색 시스템의 동작 방식과 지표 특성, 사용자 패턴 등을 모두 동원하여 경보를 튜닝하고 장애 분석 및 예방 활동을 할 때 활용하고 있다.
