네이버가 검색 서비스 장애율을 0%대로 낮춘 비결

지난 20여 년간 온 국민의 '검색 욕구'를 채워준 네이버 초록창(통합검색)은 이제 공공재나 다름 없이 느껴진다. 아무리 많은 사람이 연말에 '새해 문자'나 설날에 '차례상 차리는 법' 같은 검색어를 동시에 입력하더라도 서비스가 먹통이 되면 안된다는 게 이용자들의 기대치다.

네이버도 사명감을 가지고 검색 서비스를 운영하고 있다. 최근 몇 년 간 네이버 검색에서 이용자들이 느낄 만한 오류는 한 건도 발생하지 않았다. 아무리 네이버라도 국내 최고 수준의 트래픽이 발생하는 서비스를 장애 없이 운영하는 게 쉽지 않을 텐데 놀라운 일이다.

네이버가 이렇게 안정적으로 검색 서비스를 제공하는 비결은 뭘까. 검색 트래픽 처리 시스템을 잘 설계하고 운영하고 있는 게 첫 번째일 것이다. 하지만 이것만으로는 부족하다. 인터넷 서비스에서 장애가 전혀 발생하지 않는 건 불가능에 가깝기 때문이다. 따라서 그에 못지 않게 중요한 일이 이상 징후 탐지와 장애 예방 활동이다.

이에 네이버는 4년 전부터 검색 서비스에 대해 별도의 '사이트 안정성 엔지니어링(Site Reliability Engineering :SRE)'팀을 운영하고 있다. 검색 SRE팀을 운영하면서 네이버 검색 장애율은 2017년 4.35%에서 현재 0.4%로 드라마틱하게 줄어들었다.

네이버 검색 SRE팀은 이제 보다 효율적인 장애 대응 방법을 찾는 일에 집중하고 있다. 효율적인 SRE 대응이 곧 안정적인 서비스 제공과 직결되기 때문이다. 구글, 마이크로소프트 등 글로벌 주요 IT기업들이 SRE 방법론과 기술을 꾸준히 발전시키고 있는 이유이기도 하다.

최근 네이버 검색 SRE팀 엔지니어들을 화상으로 만나, 네이버가 어떻게 SRE 문화와 기술을 개선시켜 나가고 있는지 들어봤다.

이호석 엔지니어 "개발 리소스 줄여주는 모니터링 시스템으로 '일상 속 SRE' 구현"

Q.SRE 모티터링 시스템을 개선하게 된 배경은?

"기존에는 원천 데이터를 수집하고, 여기에서 장애 관제에 필요한 데이터를 가공해 사용하고 있었다. 우리는 서비스 단위로 관제를 하고있기 때문에 각 시스템이 어떤 서비스에 해당하는지 '서비스유니크아이디(SSUID)'를 붙이고 이를 기준으로 지표를 합산해 관제용 데이터를 만들었다.

이런 방식이 처음에는 잘 작동하였으나, 서비스 환경이 지속적으로 진화하면서 변화에 대응하기 어렵다는 문제가 발생했다. 지표의 합산 결과만 저장하다보니 원천 데이터의 일부는 유실될 수 밖에 없는 구조라, 관제에 필요한 정보가 추가되거나 관제 기준이 바뀔 때마다 지표 수집을 위해 새로운 개발을 해야 했다.

또 구조적 문제로 실시간성이 떨어지는 문제도 개선할 필요가 있었다."

Q.이번에 개선된 방식은 어떻게 다른 것인지?

"데이터를 관제가 가능한 레벨로 추상화하기 전에 각 지표에 관제에 필요한 추가 메타 정보를 담아 저장하고 원하는 대로 불러올 수 있는 방법을 찾기 위해 고민했다.

그결과 시계열 데이터베이스(DB)를 도입하기로 했다. 시계열 DB를 도입하면서 다양한 메타데이터를 원천 데이터에 추가로 태깅해 저장할 수 있게 됐다. 원천 데이터가 가지고 있는 정보가 유실되지 않으면서도 관제에 필요한 부가적인 정보도 저장할 수 있게 된 것이다.

원천 데이터에 관제에 필요한 여러 메타 데이터가 추가된 채로 저장돼 있기 때문에, SSUID 기준으로 합산 데이터를 만들어 낼 수도 있고 IDC별 합산 트래픽도 볼 수도 있게 됐다. 시계열 DB에서 제공하는 함수를 이용해 간단하게 이런 작업이 가능해졌다.

데이터 수집할 때 실시간성이 떨어지는 문제도 해결됐다. 이전에는 스크립에 의존하고 계산 결과만 저장하다보니 모든 서버의 지표가 수집되기까지 대기해야 했다. 이런 이유로 실시간성이 평균 3분정도 떨어졌다.

시계열 DB를 도입하면서 계산 결과만 저장할 필요가 없어지다 보니 지표를 수집해 오는 동시에 관제 데이터가 생성·저장되게 됐고, 거의 실시간에 가깝게 지표를 확인할 수 있게 됐다."

Q.그래서 적용된 시계열DB는 무엇?

"다양한 오픈소스 솔루션이 이런 일들을 하고 있는데, 우리는 그래핀이라는 DB를 최종 선택했다.

데이터가 매 분마다 쌓이고, 검색 시스템도 많다보니 그만한 지표를 저장할 수 있는 스케일을 고려했다. 또 데이터의 정합성이 유지되면서도 속도의 문제가 없는지도 따져봤다.

더불어 오픈소스 모니터링 솔루션 중 하나인 그래파이트(Graphite) 기반이라 오픈소스 도구를 같이 사용하기 좋고, 기본 제공되는 함수에 커스텀 함수를 구현할 수 있다는 점과 실시간으로 수집되는 데이터 이외에 관제에 필요한 데이터를 만들어서 저장하고 활용하기 수월하다는 점도 선택이유다."

Q.모니터링 시스템 개선 후 어떤 효과를 봤나?

"서비스 이름이 변경됐을 때, 별도 커뮤니케이션 없이 서비스 정상 작동 여부를 쉽게 파악할 수 있게 된 것이 대표적인 사례다.

서비스명이 변경되면 이전 서비스 트래픽이 갑자기 감소하는데, 그동안에는 왜 경보가 발생하는지 빠르게 파악하기 어려웠다.

이제 데이터를 여러가지 기준에 따라 확인할 수 있게 되면서 별도의 커뮤니케이션 없이도 서비스명 변경이 이유라는 걸 쉽게 파악할 수 있게 됐다. 또 두 서비스의 합산 트래픽을 볼 수 있어, 트래픽 변동 없이 정상 작동하는지도 확인할 수 있게 됐다.

결론적으로 원천 데이터를 저장하고 다양한 질의가 가능해지면서 상대적으로 개발 리소스가 줄고, 다양한 관점에서 관제가 가능해진 것이다. SRE가 서비스 운영 일상에 녹아들게 됐다."

장규범 엔지니어 "메신저 이용한 긴급 복구시스템으로 '손안에 SRE' 실현"

Q.장애 복구에 메신저를 이용하게 된 배경은?

"검색 시스템이 복잡한 만큼 담당자들은 새벽이나 주말에도 장애로 인해 고통 속에서 살고 있다. 일단 장애가 발생하거나 이상 징후가 탐지되면 담당자에게 경보 메시지 전달된다. 만약 주말에 외부에 나와 있다면 PC를 찾아서 PC방에 가야한다. 거기서 사내 네트워크접속에 접속하기 위해 VPN을 설치하고 복구를 위해 터미널에 접속해 실제 복구작업을 해야 했다.

우리는 이 단계를 확 줄이기 위해 업무용 메신저를 통해 긴급한 장애를 해결하고자 했다. 업무용 메신저에서 버튼을 눌러 바로 명령을 내리면, PC가 없어도 사내 VPN에 접속하지 않아도 바로 장애를 해결할 수 있게 될 것으로 봤다."

Q.장애 복구를 어떻게 메신저 버튼 명령으로 처리했나?

"기존 장애 복구 코드들은 플랫폼에 강하게 커플링돼 있었다. 우리는 플랫폼과 모니터링 시스템을 분리하고 중간에 메신저를 넣어 장애 복구를 처리할 수 있게 했다.

구조는 트리거, AOC(Actionable Outage Control system), 액션으로 이뤄져 있다. 트리거가 모니터링 시스템 이벤트를 발생시키면 AOC가 이를 받아서 메신저를 통해 담당자에게 조치 여부를 묻는 버튼을 전달한다. 예컨대 이상 징후가 있는 서버를 서비스에서 제외할 지를 등을 묻는 버튼이다. 버튼을 누르면 액션 기능이 실제 명령을 실행한다.

트래픽이 갑자기 폭증했을 때 가용성을 확보하기 위해 레플리카를 증설하거나 서비스 업데이트 후 문제가 발생했을 때 특정 버전으로 롤백하는 등의 작업이 AOC로 가능하다."

Q.AOC로 복잡한 장애도 처리 가능한가?

"AOC의 목표는 큰 장애가 발생하기 전에 응급조치를 하고 복구할 수 있는 시간을 버는 데 있다. 실제 복잡한 복구는 나중에 한다는 개념으로 설계를 했다. 작은 장애가 시간이 지나면 심각해 지는 경우가 많기 때문에 응급조치를 빨리 하는 것이 중요하다."

손주식 엔지니어 "SRE 잘 하려면?...기술과 문화 함께 발전시켜야"

Q. 네이버 검색 SRE팀이 하는 업무를 정리해 본다면?

"SRE는 장애 발생 전에 이상 징후를 발견하고 사전에 예방하는 일을 말한다. 장애가 발생하기 전에 전조 증상들이 있다. 경험에 기반해서 이런 지표가 지속되면 장애로 이어질 수 있는 규칙을 만들고, 모니터링을 통해 장애를 사전에 예방하는 일을 한다.

인터넷 서비스에서 장애가 전혀 발생하지 않을 수는 없지만, 이걸 최소화 하는 일이 중요하다. 우리팀은 네이버 검색 서비스만을 대상으로 SRE를 하고 있다."

Q.검색 서비스만 별도의 SRE팀을 운영하는 것인가?

"SRE만 전담하는 팀은 검색SRE뿐이다. 다른 서비스는 서비스 개발자가 SRE 업무를 겸직하고 있다.

2016년 경주 지진 때, 갑가지 검색 트래픽이 폭증해, 장애가 발생하는 일이 있었다. 그때 검색SRE팀이 만들어졌다."

Q.SRE팀 운영 이후 장애는 얼마나 줄었나?

"사용자들이 느낄 만큼 큰 장애는 없었다. 장애 발생 비율이 0.4%까지 줄어 들었기 때문이다. 심각도가 높은 장애는 2019년부터 단 한 건도 발생하지 않고 있다."

Q.국내 IT업체 중에는 네이버가 선도적으로 SRE를 다루고 있는 것 같다.

"우리가 처음 SRE를 시작했을 땐 용어 자체도 잘 알려지지 않았는데, 요즘은 대형 서비스에서 장애가 발생하는 게 워낙 큰 주목을 받다보니까 조금씩 관심을 가지는 기업들이 생기고 있다. 글로벌 IT 기업에서는 이미 SRE가 일반적인 활동이다."

Q.SRE 업무에 필요한 스킬셋은 무엇인가?

"스킬셋보다는 마인드셋이 더 중요하다. 문제를 분석하고 해결하는 것을 좋아하는 사람에게 적합하다.

기술적으로 보면 SRE는 다양한 SW가 접목돼야 꽃을 피울 수 있는 분야다. 그래서 팀에도 다양한 백그라운드를 가진 개발자들이 있다. 크게 데이터 수집 업무, 데이터 정제 업무, AOC 같은 새로운 도구 개발 등의 일을 한다. 업무는 칼로 자르듯 나눠져 있지 않고 서로 도와가면서 하고 있다."

Q.SRE를 잘 하려면 기술적 대응도 중요하지만, 문화적인 변화도 중요해 보인다.