NGINX Conf 2019에서 LinkedIn, Dell, Gremlin과 함께한 사이트 안정성 엔지니어링 패널에서 얻은 3가지 주요 내용

NGINX Conf 2019에서 저희는 다양한 주제를 다루는 50개 이상의 녹화된 세션을 진행했지만, 이 블로그에서는 업계에서 가장 화제가 되는 주제 중 하나에 대한 요점을 공유하겠습니다. 사이트 신뢰성 엔지니어링(그리고 관련 주제인 카오스 엔지니어링). 저는 세 가지 핵심 요점에만 집중하겠지만, 여기에서 전체 세션을 시청하시기를 권장합니다.

1.    SRE 정의

토론은 패널리스트들이 사이트 안정성 엔지니어링이라는 용어를 어떻게 정의했는지에 대한 것으로 시작되었으며, 일관된 의견은 그것이 본질적으로 다음과 같다는 것이었습니다. "사이트가 제대로 작동하도록 하는 모든 것." 하지만 그 이상으로 그들은 또한 "문제가 발생할 때 매우 깊이 파고들어 가능한 한 빨리 문제를 해결하는 것"과 "개발팀에 고객 중심적 사고방식을 부여하는 것"을 강조했습니다. 그리고, 설명에서 기존 네트워킹 운영팀과 비슷한 점을 발견하셨나요? 네, 저도 그렇지만, 한 패널리스트가 "일부 조직은 네트워크 운영팀의 이름을 바꾸는 것만으로 SRE팀을 구성하지만, 그게 최선의 방법은 아니다"라고 강조하면서 제 생각을 정말 잘 읽었습니다. 이에 대한 논의가 있었지만, 제가 여기서 얻은 결론은 SRE와 NetOps의 가장 큰 차이점은 SRE 인력이 "개발팀이나 고객 대면팀에 앉아 비즈니스 목표에 진정으로 집중한다"는 것입니다.

2.    카오스 엔지니어링 및 실패 주입

SRE 기능의 핵심 주제 중 하나는 카오스 엔지니어링의 개념입니다. 카오스 엔지니어링에 대한 자세한 설명은 이 기사 에서 다루겠지만, 이 세션에서는 "중요한 오류를 식별하고 신속히 해결하는 방법"에 대해 다루겠습니다. 화재 훈련과 비슷한 내용입니다. 화재 훈련과 유사하기는 하지만 카오스 엔지니어링의 목표는 더 광범위합니다. 즉, 복구, 내구성 및 가용성 측정 항목을 정량적으로 분석하는 데 중점을 둡니다.

실패 주입(Failure Injection)은 넷플릭스가 2014년에 도입한 꽤 일반적인 방법입니다. 테스트 목적으로 실패 시뮬레이션 메타데이터를 프로덕션 환경에 푸시하는 테스트 접근 방식이지만, 제어도 가능합니다. 이러한 노력은 일반적으로 SRE 팀이 주도하여 서비스(또는 사이트)의 가용성과 안정성을 높이기 위해 이루어집니다.

3.    SRE의 KPI 및 기술 세트

SRE를 어떻게 측정해야 하는지에 대한 흥미로운 토론이 있었습니다. MTTD(평균 탐지 시간)와 MTTR(평균 대응 시간)이 중요한 지표라는 의견이 여러 개 있었지만, 모든 패널리스트는 지표는 업계와 운영하는 시스템이나 사이트에 따라 다르다는 데 동의했습니다. 토론에서 얻은 좋은 제안은 "다음 질문으로 시작할 수 있습니다. '가장 중요한 상위 5개 시스템은 무엇입니까?' 그러면 우선순위를 정하는 데 도움이 될 것입니다."

SRE 직책에 선호되는 기술 세트에 관한 내용도 다루어졌습니다. 패널리스트들에 따르면, 이는 또한 어떤 시스템을 운영하는지에 따라 달라진다고 합니다. (예를 들어, NGINX를 운영하고 있다면 SRE 채용을 위해서는 NGINX 경험이 매우 중요합니다.) 그룹의 훌륭한 제안은 SRE 인력을 회사의 여러 부서와 시스템에 순환 배치하여 SRE 리소스를 확장하고 더 잘 갖추는 방법을 모색하는 것이었습니다. 또한 SRE 팀이 교육, 사외 활동, 전담 Slack 채널, '게임 데이'와 같은 SRE 커뮤니티 이벤트 및 활동에 참여하도록 하는 것도 도움이 됩니다.

결론 – 2020년이 귀사의 SRE 전략을 정의할 시점일까요?

간단히 말해, 토론에서는 많은 조직이 여전히 SRE의 개념과 역할을 정의하고 활용하는 방법을 배우고 있다는 사실이 드러났습니다. 그리고 패널리스트들이 반복했듯이 이는 종종 산업과 시스템(그리고 개별 회사)에 따라 달라질 것입니다. 전반적으로, Chaos Engineering은 내년에도 계속 다루어질 것입니다. 이것이 여러분과 여러분의 조직에 어떤 의미가 있는지 생각해보기 시작하기에 완벽한 시점일지도 모릅니다.