안녕하세요. 우아한형제들 시스템신뢰성개발팀 박주희입니다.

사회생활 N년차,
여러 업무를 해봤지만, 개인적으로 가장 힘들다고 생각하는 것은 바로 자기소개입니다.
특히, 최근에 업무를 진행하면서 처음 만나는 분들께 ‘안녕하세요. 우아한형제들 시스템신뢰성개발팀 박주희입니다.’ 라고 인사를 하면, 상대의 얼굴에는 물음표만 가득합니다. 흔하지 않은 팀이름에, 어떤 일을 하고 있는지 짐작조차 못 하는 사람이 대부분입니다. 개발자분들에게는 SRE팀이라고 한 번 더 소개하면 ‘아!’ 하는 반응을 주시지만, 다른 직군에 계신 분들에게는 그저 혼란스러움이 가중될 뿐입니다. 그럴 때마다 횡설수설 여러 설명을 덧붙여보지만, 명쾌한 답을 주기란 쉽지 않습니다.
(아직도 부모님께서는 제가 무슨 일을 하고 있는지 모르고 계십니다 :p)

시스템신뢰성개발팀 채용의 문을 선뜻 두드리지 못하는 게 어쩌면 이것 때문은 아닐까 걱정이 되어, 시스템신뢰성개발팀을 잘 설명할 수 있는 내용을 정리해보기로 했습니다. 우리가 어떤 경험을 하고 있는지, 어떻게 성장하고 있는지, 어떤 것이 더 필요한지를 잘 알려준다면, 같이 일할 동료가 많이 늘어날 수 있을 것 같다는 작은 희망을 품고 이 글을 써 내려 가봅니다. 팀이름, JD에 담아내기 힘들었던 조금은 길고 자세한 이야기가 누군가에게는 새로운 관심이 되고, 누군가에게는 큰 결심이 될 수 있기를 바라봅니다.

첫 번째 질문, 시스템신뢰성개발팀 팀명은 무슨 뜻인가요?

시스템신뢰성개발팀, 뭔가 어렵고 복잡한 이름 같죠?
개발조직 내부에서는 시스템신뢰성개발팀이라는 긴 이름 대신 SRE팀으로 많이 부르고 있습니다.
SRE는 Site Reliability Engineering의 약자로 번역하자면 사이트 신뢰성 공학이며, 시스템, 서비스 및 제품에서 적절한 수준의 안정성을 지속적으로 달성하도록 지원하는 엔지니어링 분야입니다. SRE는 서비스의 인프라와 운영 관점의 문제를 소프트웨어 엔지니어링 기법을 통해 해결하고자 나온 개념으로, SRE의 주요 목표는 확장성과 고가용성을 확보한 소프트웨어를 만드는 것 입니다. 자세한 설명은 Google의 SRE 를 한 번 읽어 보시길 추천합니다.
한 마디로, 서비스를 안정적으로 제공하기 위한 여러 활동을 하는 팀이며, 개발조직 내부에서 대부분 SRE팀이라고 부르고 있기 때문에, 어쩌면 몇몇 개발자분들은 SRE팀의 풀네임이 시스템신뢰성개발팀이라는 걸 모르고 계실지도 모릅니다.
슬랙에서 SRE팀으로 검색해보면 아래와 같은 메시지를 확인할 수 있습니다.

두 번째 질문, 시스템신뢰성개발팀은 어떤 일을 하나요?

서비스를 제공하면서 고객의 신뢰를 잃지 않기 위해 가장 중요한 것은 고객이 원하는 시점에 원하는 서비스를 제공해주는 것입니다.
배달의민족 서비스를 생각해보면, 고객이 배고픈 시간에 주문을 할 수 있는 것을 뜻하죠.

우아한형제들은 ‘좋은 음식을 먹고 싶은 곳에서’ 라는 비전을 가지고 있습니다.
SRE팀은 여기에 한 가지를 덧붙여 사용합니다. ‘좋은 음식을 먹고 싶을 때 먹고 싶은 곳에서’



자, 상상을 한번 해 볼까요?

오늘 하루 정말 눈코 뜰 새 없이 바쁘게 보냈습니다. 점심 먹을 시간도 없었어요.
그래도 오늘 정말 중요한 프로젝트를 잘 끝내서 후련함과 뿌듯함을 가득 안고 퇴근길에 오릅니다.
일할 땐 몰랐는데, 끝나고 나니까 배고픔이 몰려오네요.
스스로 보상을 줘야겠다고 생각합니다.
“오늘 하루 고생했으니 치킨에 맥주를 먹어야지~”
퇴근길에 편의점에 들러서 맥주를 사 와 냉장고에 넣어두고 씻기 전에 치킨을 시키려고 배달의민족 앱을 켰습니다.
어떤 치킨을 먹을지 행복한 고민을 하면서 메뉴를 정하고 주문을 하려고 하는데
…
…
주문을 할 수 없다는 오류가 뜹니다.

이런 상황에서 화가 나지 않을 사람은 과연 몇 명이나 될까요?
요즘 자주 들리는 표현을 빌리자면, 한국인은 언제나 먹는 것에 진심인 만큼 원하는 시간에 먹고 싶은 것을 먹을 수 없을 때 오는 그 허탈함과 분노도 엄청납니다. 우리에게 끼니란 에너지 보충 정도의 의미를 넘어서, 삶에서 매우 크고 중요한 부분이기 때문에 배달의민족 서비스도 그만큼 무거운 책임감을 느끼고 있습니다. 우리 서비스에 대한 신뢰는, 원하는 시간에 먹고 싶은 것을 먹을 수 있다는 믿음을 뜻합니다. SRE팀은 이 신뢰를 지키는데 필요한 모든 활동을 하고 있습니다.

그래서 팀 업무에서 언제나 변함없이 최상위 우선순위를 차지하고 있는 것이 바로 ‘장애’ 입니다.

SRE팀은 장애를 빠르게 탐지하여 장애를 최소화 할 수 있는 수단과 방법을 고민하고,
장애 복구 시간을 단축하기 위해서 가능한 모든 수단을 동원하며,
장애에 영향받는 유관부서 및 고객에게 빠짐없이 빠르게 전파하고,
장애가 종료된 후에 각종 후속 조치 및 장애 리뷰를 하는
이 모든 프로세스를 정의하고, 운영하고, 지원하며, 직접 수행하기도 합니다.

이런 장애 대응 활동은 배달의민족 서비스에 국한되어 있지 않고,
배달의민족, 배민라이더스, B마트, 배민상회, 배민장부, 만화경, 로봇 등 모든 서비스를 아우르고 있습니다.

지금부터 장애 탐지, 장애 복구, 장애 재발 방지, 장애 예방 등, 장애를 대응하기 위해서 SRE팀이 하는 일을 간략하게 살펴보겠습니다.

1. 장애 탐지

장애를 최소화할 수 있는 방법 중 하나는 서비스의 이상 징후를 빠르게 탐지하는 것입니다. 다양한 모니터링 지표를 통해 실시간으로 서비스 이상 징후를 확인하고, 필요에 따라 모니터링 지표나 알람을 세분화/고도화하여 문제가 되는 지점을 정확하게 찾기 위해 많은 노력을 하고 있습니다. 이 과정에서 여러 시스템 지표는 물론이고, 비즈니스 지표까지 함께 장애 탐지에 사용하고 있습니다.
모니터링과 알람을 통한 빠른 장애 탐지가 중요한 이유는, 빠르고 정확한 장애 탐지를 통해서 장애가 확산되는 것을 예방하며, 이를 통해서 사용자의 불편함을 최소화할 수 있기 때문입니다. 또한, 이상 징후가 정확하고 빠르게 탐지되면 이를 활용해서 self healing이 가능하도록 엔지니어링이 가능하기 때문에 탐지에서 그치지 않고 이를 계속해서 고도화하고 있습니다.

2. 장애 복구

장애를 직접 겪어 본 사람은 누구나 한 번쯤 말 그대로 멘탈이 너덜너덜해지는 경험을 하게 됩니다. 장애 복구를 진행하는 동시에 무수하게 쏟아지는 질문에 답도 해야 하는데, 이미 머릿속은 하얗고, 손끝은 떨려오고, 심장이 터질 것 같죠. ㅠㅠ (실제 경험담)
이때, SRE팀은 담당 개발자가 서비스 복구에 집중할 수 있도록 여러 지원 활동을 수행합니다. 각종 지표와 로그를 분석하고, 유사한 상황의 경험을 공유하고, 해결방안을 검색해보기도 하며, 유관부서에서 적절하게 대응할 수 있는 정보를 제공하기 위한 장애 전파도 지원하고 있습니다. 장애 상황에서는 같이 대응해주는 동료의 머리와 눈과 손이 너무나 소중하고 든든하기 때문에 (이 또한 경험담) 직접 대응을 지원하기도 하지만, 직접 대응이 불가능한 부분은 도움이 될 수 있을 것 같은 모든 사람을 소환해서 지원을 요청하기도 합니다.

3. 장애 재발 방지

장애가 해소되었다고, 우리의 일이 끝나는 것은 아닙니다.
화재진압과 동일하게, 일단 불을 껐으면 남아 있는 잔불은 없는지, 발화지점은 어디인지, 비슷한 사고를 예방하려면 어떤 조치가 필요한지를 살펴보게 됩니다. 이러한 모든 과정을 장애 리뷰와 장애 재발 방지 작업이라고 합니다.

우아한형제들 개발조직은 굉장히 활발하게 장애 리뷰를 진행하고 있습니다.
하지만, 장애 리뷰는 좋은 장애 재발 방지 대책을 찾기 위한 수단이기 때문에 리뷰가 리뷰에서만 그치면 의미가 없습니다. (마음만 아플 뿐…) 장애 리뷰가 효과를 발휘하기 위해서는 반드시 유사한 장애가 발생하지 않도록 장애 재발 방지 조치가 완료되어야 합니다. 비록 소 잃고 외양간 고치는 격이라고 하더라도, 우리는 다음 소를 잃지 않기 위해서 오늘도 외양간을 고칩니다.

장애 리뷰를 진행하면서 우리는 가능한 가장 원천적이고 핵심적인 원인을 찾으려고 노력합니다. Root Cause를 찾아서 개선하고, 장애 리뷰 과정에서 도출된 여러 시스템 취약점들을 개선합니다. 대부분 장애는 하나의 절대적이고 단순한 원인이 아니라, 여러 원인과 상황들의 시너지 효과로 인해서 촉발되고 확산되기 때문에 장애를 회고하는 과정을 통해서 여러 개선 포인트를 도출합니다.
때로는 그 과정이 길고, 복잡하고, 고통스러울 때도 있지만, 비슷한 장애를 두 번 이상 겪는 것보다는 훨씬 적은 비용과 노력이 들어갑니다. 예를 들어, SRE 팀에서 장애의 root cause를 찾고 재발 방지하는 방법에 설명된 케이스도 초기에 정확한 원인을 찾지 못해서 굉장히 고통스럽고 힘든 나날을 보냈습니다. 여러 가설을 세우고, 하나씩 장애를 유발하는 요인을 제거해가면서 밤낮없이 원인을 찾아 나갔고, 원인을 찾아내서 재발 방지를 위한 조치까지 마무리한 후에야 비로소 마음을 놓을 수 있었습니다. 원인을 찾아가는 과정은 힘들었지만, 피크시간만 되면 수십 명의 서비스 담당자들이 마음졸이며 지켜보지 않아도 되고, 마음 편히 저녁을 먹고 잠자리에 들 수 있다는 것만으로도 많은 시간, 노력, 비용을 줄인 것이라고 생각합니다.

4. 장애 예방

SRE팀은 장애를 예방할 수 있는 여러 활동도 병행하고 있는데, 주요 활동을 살펴보겠습니다.

모의 장애 훈련
2020년 상반기에 서비스의 확장과 MSA로의 아키텍처 변화를 수용하기 위해서 장애 대응 프로세스를 개편했는데, 이 장애 대응 프로세스를 문서만 보고 100% 이해할 수 있는 사람은 없었습니다. 그래서 우리는 개발환경에서 실제에 가까운 장애를 유발하고, 대응해보는 모의 장애 훈련을 진행하게 되었습니다. 처음에는 장애 대응 프로세스를 전파하기 위한 수단이었지만, 이 모의 장애 훈련을 통해서 우리는 실제로 우리 시스템의 많은 취약점을 찾아내게 되었습니다. 훈련을 계획하고 설계하고 실제로 수행하는 데까지 많은 시간과 노력이 들어가지만, 그런 노력을 들일만 한 충분한 가치가 있는 일이기에, 2021년에도 모의 장애는 계속 진행할 예정입니다. (모의 장애 훈련에 대한 긴긴 이야기는 다음 기회에… )

아키텍처 리뷰
MSA 구조에서는 silo 현상이 종종 발견되는데, 이는 사람이나 조직에 국한된 내용이 아니 아키텍처에서 나타나기도 합니다. 각 서비스에 최적화된 구조로 시스템을 구축하기 때문에 각 시스템의 아키텍처, 스펙, 모니터링, 알람 등이 굉장히 파편화되는 현상이 나타나게 되는 것입니다. 그래서 SRE팀에서는 개별 서비스 개발팀과의 아키텍처 리뷰를 진행하면서 각 시스템의 SPOF를 찾아내고, 장애를 유발할 수 있는 포인트를 사전에 찾아서 개선합니다. 아키텍처 리뷰를 위해서 각 서비스의 아키텍처를 모두 문서화해야 하고, 아키텍처를 설계하면서 반드시 지켜져야 할 핵심 내용을 사전에 정의하는 작업이 필요하므로 이 또한 많은 시간과 노력이 필요합니다. 매일 매일 비즈니스 요구사항에 맞춰 개발해나가기에도 빠듯한 일정이기에, 이미 운영되고 있는 서비스의 아키텍처 리뷰에 시간을 할애한다는 것이 쉬운 일은 아닙니다. 하지만 이 과정을 통해서 장애를 예방할 수 있기 때문에 ‘계획된’ 아키텍처 리뷰가 ‘불시의’ 장애를 예방함으로써, 더 가치 있게 시간을 사용할 수 있습니다.

공지, 문서화, 리마인드, 등등
SRE팀은 앞에서 살펴본 것과 같이 장애 대응, 모의 장애 훈련, 아키텍처 리뷰 등을 통해서 다양한 케이스의 취약점을 접하고 있습니다. 위에서 언급했듯이, 이런 중요한 내용이 특정 팀에 머무르는 경우가 있기도 하고, 이미 알고 있지만 빠르게 개선하지 못하는 경우도 있습니다. 이 현상은 누군가의 잘못이라기보다는 서비스의 성장에 맞춰서 비즈니스 요구사항을 빠르게 반영하다 보니 다른 팀에 알려주기에도 벅차고, 우선순위를 조정하기에도 힘이 들기 때문에 발생하게 됩니다. 그렇기 때문에 다양한 채널로 취합된 이런 취약점이나 개선 포인트를 최대한 넓게 공유하는 역할도 SRE팀에서 하고 있습니다. 이슈가 되는 포인트를 정의하고, 개선 방향을 제시하고, 진행 상황을 체크합니다. 이 과정에서 다양한 문서를 생산해내고 있으며, 동원할 수 있는 모든 커뮤니케이션 수단을 활용해서 최대한 많이 전파하기 위해 노력합니다. SRE팀에서 전달하는 내용은 기본적으로 모든 개발팀을 대상으로 하며, 때로는 비즈니스 조직의 유관부서까지 포함하기 때문에 최대한 자세히 설명하려고 노력합니다.

장애에 대한 인식 개선
장애는 경력이나 직급, 직군과 관계없이 모두에게 힘든 일입니다.
특히 원인을 찾고, 재발 방지 대책을 찾다 보면 내가 왜 그랬을까, 왜 진작 몰랐을까, 왜 빨리 해결하지 못했을까, 왜, 왜, 왜, 왜왜왜왜… 라는 생각을 계속 반복하게 됩니다.

이럴 때마다 SRE팀에서는 몇 가지 패턴의 이야기를 합니다.

사람은 누구나 실수 할 수 있기 때문에
같은 실수를 반복하지 않는 것이 중요하고,
실수를 통해서 배우는 것이 중요하며,
내가 한 실수는 다른 사람도 할 수 있기 때문에 실수를 방지할 수 있도록 시스템이 막아줄 수 있어야 한다.

즉, 장애는 결코 어느 한 사람, 한 조직의 잘못이 아니다.

장애를 겪으면서 누군가를 블레임한다고 해서 그 상황이 절대 나아지지는 않으며 오히려 더 폐쇄적으로 이슈를 감추게 되기 때문에 우리는 장애의 책임을 개인이나 특정 조직에 전가하지 않습니다. 장애는 물론 어렵고 힘든 과정이지만, 이 과정에서 많이 배우고 갈고 닦아서 우리 시스템을 더 견고하게 만드는 것이 중요하다고 생각합니다. SRE팀은 누구나 쉽게 이슈를 오픈하고, 도움을 요청하며, 장애에 대해 자유롭게 이야기할 수 있는 환경을 만들기 위해서 많은 노력을 기울이고 있습니다.

세 번째 질문, 시스템신뢰성개발팀은 무엇을 개발하나요?

계속해서 이야기하고 있듯이, SRE팀의 최상위 우선순위는 항상 ‘장애’ 입니다.
이상징후를 빠르게 확인하고, 리소스를 잘 식별하며, 사전에 우리 시스템의 취약점을 찾아내고, 장애가 발생하더라도 간단한 조치로 빠르게 복구할 수 있는 방법에 대해 끊임없이 고민하고 있기 때문에, SRE팀에서 개발하고 있는 모든 코드는 이러한 관점에서 시작된다고 할 수 있습니다.

한가지 예를 들어보면, 우리는 사내 모든 리소스에서 발생하는 모든 변화를 즉시 감지할 수 있는 툴을 만들었는데, 이는 시스템 이슈나 장애가 발생한 경우에 가장 먼저 의심이 되는 포인트 (즉, 시스템의 어떠한 변화)를 확인하는 수단으로 사용하고 있습니다. 각 도메인 서비스(주문, 가게, 쿠폰, 등)는 MSA 구조 아래서 독립적으로 운영되는 듯 보이지만, 이전보다 훨씬 더 촘촘하고 복잡한 연결망을 가지고 있기 때문에 시스템의 변화를 감지하고 대응하는 것이 매우 중요합니다. 종종 한 도메인의 작은 변화가 나비효과를 일으켜서 완전히 생뚱맞다고 생각되는 지점에서 오류를 발생시키기도 하는데, 이 경우 원인을 찾아가는 과정에서 여러 단계를 거치게 되고, 그에 비례하여 장애 시간도 늘어나기 때문에 장애 시간을 단축하고자 이런 툴을 개발하게 되었습니다.

2021년에도, 지금까지 SRE팀이 겪은 많은 경험을 토대로 더 나은 환경에서 우리 서비스의 안정성을 높일 수 있는 것들을 더 많이 준비하고 있습니다. 이 글을 읽고 조금의 관심이 생겼다면, 혹은 단호한 결심을 했다면 [공통기술부문] SRE 엔지니어(DevOps) 모집을 클릭해주세요.

긴 글 읽어주셔서 감사합니다. 앞으로도 SRE팀은 많은 분들의 즐거운 식사를 위해 노력하겠습니다.