이 글은 기술보다 문화에 초점을 두고 있습니다 🙂
1. 들어가며…
안녕하세요. SmartStudio에서 자그마하게 웹 개발을 하고 있는 최재현입니다.
SRE 활동은 하나의 문화야…
언젠가 이런 이야기를 들은 적이 있습니다. 이전 회사인지, 언제였는지 기억은 안 나지만, 저는 항상 마음에 품고 다니는 말입니다. 그러던 어느 날 저는 외부에 스터디를 갔다가 아래의 이야기를 듣게 됩니다.
아 그게 SRE는 백엔드 개발자의 영역이잖아요?
DevOps나 SRE(Site Reliability Engineering) 가 별도로 존재해서
전문적으로 업무 보는 게 아니에요?
라는 이야기를요.
그렇죠. 맞아요. 그렇게 생각할 수도 있지만, 하나의 문화라고 생각했던 저는 깊은 고민에 빠지고 말았답니다.
개발을 하면서 SRE를 늘 생각하고 움직인다면 더 좋은 품질의 서비스를 만들어 낼 수 있을 텐데…라고 생각했기 때문이에요.
사람들은 개발을 하면서 프론트엔드 영역과 백엔드 영역을 구분해서 나누고 생각하죠.
일반적으로 직군으로 나누어져 있으니까요.
하지만 CS(Computer Science) 지식은 누구나 한 번쯤은 익히고 배우거나, 배우는 것을 권장하고 있어요. SRE 문화를 익히는 것도 하나의 CS 지식을 습득하는 것과 같은 궤라고 생각했었습니다.
SRE를 누군가의 업무(Rule)로 나누는 건 요즘같이 화면에서 버튼 클릭 하나만으로 멋진 배포를 할 수 있는, 클라우드 환경 시대엔 맞지 않는다고 생각했거든요. 심지어 클릭도 없이 git에 머지되는 순간 자동으로 테스트, 통합, 배포가 이루어지죠. 이런 시대에 SRE 적 사고를 함양하고 있으면, 자동 배포를 하는 순간 발생할 일에 대해 세심하게 살필 줄 알게되죠. 미리 설정해둔 배포 방식이 사용자에게 미칠 영향을 따라가고, 완전히 배포된 이후 결과물을 지켜보는 것까지 마음속에 담아야 합니다.
한글로는 ‘사이트 신뢰성 엔지니어링’이라고 부르는 SRE. 이것은 사이트를 만들어 나가고 가꾸어가는 사람 모두가 익히고 언제나 생각해야 하는 부분이라 느꼈습니다. 오늘은 여러분들에게 SmartStudio에서 어떻게 이 문화를 전파할 수 있을지 고민하고, 실천하고, 정착하기 위해 어떤 일을 했는지 소개할까 합니다.
SRE 이야기를 하기 전에 먼저 SmartStudio 이야기를 아주 조금 할까 해요. SmartStudio 구성원 대부분은 프론트 개발자(Web, iOS, Android 포함)가 80%로 높은 비율을 차지하고 있답니다. 어마어마한 프론트엔드 조직인 거죠. 그만큼 프론트엔드의 기술력은 국내에서 손꼽히는 정도라고 볼 수 있어요.
외부 스터디를 다녀온 이후 저는 생각했습니다. 우리 SmartStudio에 SRE 문화를 잘 정착시킨다면? 그래서 부족한 부분을 채우고, 모두가 SRE 기초 지식을 함양할 수 있다면? 우리가 가지고 있는, 그리고 앞으로 개발하는 서비스에 대한 더 나은 사이트 신뢰성을 확보할 수 있겠구나 싶었어요.
2. 스터디 준비의 시작…
그렇게 스터디를 만들기로 결심을 했고, 준비작업을 들어갔어요. 사람을 모집해야 하는데, 모집이 안되면 깔끔하게 포기하려 했습니다! 하지만 총 12명이 참가해 주셨어요.
사내에서 스터디를 만드는 건 완전히 자율이에요. 자유롭게 스터디를 만들 수 있고, 책과 같은 지원도 받을 수 있었지요. 고민을 했습니다. 어떤 책을 구해야 할지. 사내 스터디지만 많이 어려우면 따라잡지 못할 수 있고, 너무 쉬우면 중요한 부분을 놓칠 수 있겠다고 생각했어요. 그리고 나중에 필요하면 다시 볼 수 있는 그런 자료들로 채우고 싶었어요.
먼저 책을 구매하기 위해 도서관에서 관련 책을 빌려봤어요. 제가 먼저 읽어봐야 어떤 식으로 스터디를 할지, 어떤 내용을 알려드릴지 정리할 수 있어서였습니다. 그리하여 교재로 몇 가지 리스트가 나왔습니다.
메인으로는 오래되었지만 기본기가 탄탄한 24시간 365일 서버/인프라를 지탱하는 기술로 결정했습니다. 요즘 나오는 책들보다 네트워크나 인프라 지식에 대한 기본 설명이 나아서 였습니다.
부교재로는 사이트 신뢰성 엔지니어링 (구글이 공개하는 서비스 개발과 운영 노하우)을 선택해 SRE에 대한 내용을 익히기로 했습니다. 올해 초에 책이 몇권 더 나왔지만, 작년 연말에는 이 책 밖에 없었어요. 그리고 대규모 트래픽을 직접 경험 하지는 못하더라도 이해와 학습은 필수라 생각하여 마지막 부교재로 웹 개발자를 위한 대규모 서비스를 지탱하는 기술로 결정했습니다.
그렇게 첫 SRE 기초 교양 스터디가 시작됩니다.
책 기반 학습을 권장했지만, 역시나 책은 책! 모두가 같은 이해도로 읽어올 수는 없었어요. 그래서 책을 기반으로 요약정리를 해서 PPT를 만들어 전날이나 빠른 시일 내에 미리 만들어 공유를 했습니다. 미리 읽어보고 오거나 어려웠던 내용을 파고드는 대신, 다 같은 이해도를 가질 수 있도록 간단하게 소개하는 것이 PPT의 역할이었습니다.
전공자 뿐만 아니라 비전공자, 프론트, 백엔드, 모바일 개발 모두가 섞여있는 스터디라 사실 PPT 제작에 부담이 되기도 했습니다. 틀린 내용이 있으면 어떡하지? 걱정 했지만, 스터디 중간중간에 토론하고 질문도 해주시면서 내용을 고치고 살을 좀 더 붙이며 발전 해 나갔습니다. 졸업한 지 오래되신 분들에게는 다시금 기억을 떠올리게 하는 계기가 되기도 했습니다. 네트워크 전공자도 계시더군요. 🤣
PPT 제작은 정말.. 정말… 힘든 시간이었습니다. 매주 30분 발표를 위해 3시간 정도 자료를 조사하고 정리하는 준비가 필요했어요. 내용을 검증하고, 트렌드에 맞춰 가공하고, 책을 먼저 읽어보고, 시대와 맞지 않는 부분은 스킵해서 읽으시라고 미리 가이드하고, 이전 시간에 나온 의문점이나 질문에 대한 답변도 준비해야 했습니다.
3. 내용과 진행은 어떤 식으로?
이 글에서 모두 소개할 수는 없지만, 주로 이런 내용들을 다루었습니다.
SRE는 왜 하는 것이고 무엇인지 알아가는 시간을 가졌고, 네트워크 기초 이론, 가용성이 왜 중요한지, 다중화를 하려면 어떻게 해야 하는지, 대용량 트래픽 분산은 어디에서 하며, MAS 아키텍처가 만능은 아니라는 허와 실에 대한 이야기, 배포 전/후 상시 모니터링에 대해 왜 생각해야 하는지 등 장표를 한 장씩 만들며 진행했습니다.
모두를 위해 심도가 깊거나 어려운 내용으로 준비하지는 않았습니다. 기초 지식을 함양하고 모두가 토론할 수 있다면 스터디의 목적은 달성되는 것이었으니까요.
진행은 이렇게 하였습니다. 너무 달리면 넘어지기 때문에, 가끔 쉬어가는 주간도 있었습니다. 업무를 하면서 자료를 만들다 보니, 시간이 부족할 때도 있었습니다. 그때는 빠르게 다음 주에 할게요! 하고 공지하곤 했습니다.
그러던 평화로운(?) 어느 날이었습니다. 회고 및 토론 시간에서 이런 이야기가 나왔어요.
실습을 해보고 싶은데요…
이론만 있는 것보다, 직접 해보면 더 와닿을 것 같아요.
4. 그러던 어느 날이었습니다.. 실습을..
실습이요? 실습… 어… 그러니까 실습을… 그렇군요. 실습! .. 좋죠!! 좋은데 ㅠㅠ 실습에 대해 생각을 못 했던 저는 ‘아.. 어떻게 하지ㅠㅠ’ 하는 마음과 ‘한 번 실습을 하더라도 유용한 실습이었으면 좋겠다’ 하는 마음, ‘확실히 실습이 많은 도움이 되겠지’ 하는 마음을 가지고 있었어요.
추가로 ‘실습 환경은 어떻게 구축하지? 장비는? 이 인원 모두가 실습을 위해 VM이나 PM을 발급받을 수 있을까? 일이 바빠 참가하지 못했다면 다음에 문서만 읽어도 따라 할 수 있는 실습이 되어야 할 텐데?’ 하며 고민하는 나날을 보냈습니다.
그러던 중 ‘실습을 하며 가이드를 만들면 누구나 나중에 따라 할 수 있겠지?’라는 생각이 들어 다음과 같이 형식으로 가이드를 제작하게 됩니다.
매주 실습을 하면서 가이드를 하나하나 채워나갔어요.
먼저 처음에 고민했었던 장비 수급의 문제는 사내 쿠버네티스 클러스터를 이용해 해결했습니다. nGrinder라는 툴로 무식하게 트래픽을 넣어 애플리케이션이 들어있는 Pod를 다운시켜 인스턴스를 무력하게 만들기도 하고, 이 상황을 모니터링하는 것도 해보기도 했죠. (locust 라는 툴도 있으니 한번 써보시는것도 좋습니다.)
- 개요를 통해 → 가이드를 만들게 된 이유를 알려드렸습니다.
- 사내 쿠버네티스를 기반으로 실습 환경 만들기를 통해 → 쿠버네티스 기초 이론과 이걸 쓰면 왜 좋은지, 그동안 사용하던 VM과 PM을 벗어날 방법을 알려드렸습니다.
- 파이프라인 만들기를 통해 → 쿠버네티스에서 도커 이미지를 빌드하고 배포하는 과정을 익혔습니다.
- 잘 뜬 서버를 트래픽을 부어 죽여보기를 통해 → 다중화의 필요성, 가용성 확보의 필요성을 익혔습니다.
- HPA(Horizontal Pod Autoscaling) 기능을 사용해 자동 확장하기를 통해 → 트래픽에 따른 Pod 자동 확장을 통해 서비스를 안정적으로 유지하는 방법을 익히고, 이 상황을 모니터링하며 상태를 체크했습니다.
실습 시간은 참 빠르게 지나갔어요. 같은 내용으로 두 번 스터디를 하기도 했고, 테스트할 때는 잘 되었는데 라이브에서는 잘 안되는 문제를 겪기도 했습니다.
그리고 요즘은 트래픽을 마구 부어 넣는다고 순수 Node 애플리케이션 서버도 잘 죽지 않더라고요? Nginx나 로드벨런서를 앞에 붙여두지도 않았는데 말이에요. 이건 또 처음 알게 된 사실이었습니다. 🤣
그렇게 모든 팀원이 다같이 안정성과 다중화의 필요성, 운영 방법 등의 기초를 익혀, 사이트 신뢰성 엔지니어링에 대한 지식을 갖추어 나갔습니다.
여러분들도 한번 관련 책을 읽고, 모든 팀원들과 같이 SRE에 대한 스터디를 준비하는건 어떨까요?
저는 기초 스터디를 만들었지만 실제 백엔드 운영쪽에서는 개발 실 단위로 SLI/SLO, 모니터링, 척도분석, 매월 SRE 활동에 대한 회고를 하고 토론하는 시간도 있습니다. Etech 개발실이 궁금하세요? 이곳에 더 자세한 내용이 준비되어 있답니다!
5. 마치며
SRE 기초 스터디는 이렇게 마무리 했었습니다. 물론 실습가이드는 지금도 추가적으로 살을 붙여나가고 있어요. 문서의 생명은 작성하고 고치지 않는 순간 죽는다고 생각합니다.
여러분들도 한번 만들고 그냥 방치해둔 문서가 없나(?) 지금 한번 둘러보는 계기가 되었으면 좋겠네요.
이 스터디를 진행하면서 제 스스로도 한번 더 SRE의 마음을 다지고, 기초 지식을 전수하며 스스로도 많이 배웠다고 느꼈습니다. 저의 경우에는 쿠버네티스나 도커를 접한 지 1년 정도밖에 되지 않았고, 웹 개발자로써 아직도 많이 부족한 감이 없잖아 있는데요. 이런 가이드를 만들고 이렇게 블로그글을 대외적으로 작성 하면서 더 성장할 수 있는 계기가 되었다고 봐요.
다음에는 좀 더 기술적인 내용을 준비해서 여러분들에게 재잘재잘 이야기를 들려드릴 수 있는 자리로 돌아오겠습니다. 저희 SmartStudio의 문화와 기술들을 사랑해 주시고, 긴 글 읽어주셔서 감사합니다.
좋은 하루 되세요 😀
