사이트 신뢰성 엔지니어(SRE, Site Reliability Engineer)가 하는 일, 필요 역량

사이트 신뢰성 엔지니어링(Site Reliability Engineering)이라는 말을 들어본 적이 있으신가요? 최근 개발 직군, 특히 클라우드 관련 채용 동향을 면밀히 파악하신 분들은 한 번쯤 들어본 용어일지도 모르겠습니다.

최근 ChatGPT와 같은 생성형 AI의 발전이 프롬프트 엔지니어링이라는 새로운 직무를 만들어 낸 것처럼, 클라우드 업계 역시 기술 발전에 따라 클라우드 엔지니어, DevOps 엔지니어, 사이트 신뢰성 엔지니어와 같은 직군이 새롭게 등장했습니다. 이 글에서는 사이트 신뢰성 엔지니어링과 이를 수행하는 직군 즉, 사이트 신뢰성 엔지니어(Site Reliability Engineer)에 대해 소개하고자 합니다.

---

사이트 신뢰성 엔지니어란?
: SRE (Site Reliability Engineer)

기술의 발전은 필연적으로 새로운 직무를 만들어 냅니다.

어느 날 갑자기 새로운 직무가 생기는 경우도 있지만, SRE의 근본이 되는 직무는 사실 이전에도 존재했습니다. 바로 시스템 관리자(System Administrator)입니다. 시스템 관리자는 컴퓨터 시스템의 네트워크를 운영하고, 유지 보수하며, 서비스가 잘 제공되도록 관리하는 사람입니다.

간혹 기술의 발전이 과거의 직무를 무의미하게 만드는 경우도 있지만, 이 시스템 관리자라는 직업은 여전히 의미 있는 직업입니다. 다만 그 수요나 비중이 줄어들었을 뿐이죠.

앞서 🔗클라우드 컴퓨팅에 관한 포스팅에서 언급한 것과 같이, 클라우드 컴퓨팅은 인프라를 구축하는 데 필요한 설치 및 유지 보수 등의 작업을 혁신했습니다. 특히 클라우드 서비스 제공자는 물리적 데이터 센터, 물리적 네트워킹, 물리적 서버와 같은 물리적인 요소들을 전부 책임집니다. 또한 해당 자원의 사용 역시 추상화되어서 보다 간편하게 사용할 수 있게 되었습니다.

즉, 온프레미스를 담당하는 시스템 관리자가 아니라면, 실질적으로 서버와 네트워크를 물리적으로 설치할 일이 점차 줄어드는 추세가 되었습니다.

사이트 신뢰성 엔지니어링의 필요성

상대적으로 비중이 줄어드는 일이 있는 반면, 고도화하고 있는 일도 존재합니다. 바로 서비스 운영입니다. 서비스는 이제는 굳이 “웹”이라는 용어를 앞에 붙이지 않아도, 모든 것이 웹에서 서비스되고 있는데요. 즉, 보통은 “사이트”의 형태로 서비스가 제공되고 있습니다.

구글이라는 사이트에 접속해서 무언가를 검색하고 결과를 얻어내기 위해서는, 수많은 종류의 검색 관련 소프트웨어 구성 요소가 뒷단에서 작동되어야 할 것입니다. ChatGPT도 마찬가지죠. 우리가 무언가를 질문하고 AI로부터 답변을 받아내기 위해서는 매우 많은 구성 요소가 작동해야 합니다.

이 모든 소프트웨어 구성요소는 개발이 필요한 무언가이면서 동시에 관리의 대상입니다. 이러한 맥락에서 소프트웨어 개발과 운영의 프로세스를 보다 빠르게 하기 위한 DevOps라는 직군이 생겨났죠. SRE도 마찬가지입니다. 단순히 웹 사이트를 서버에 올려놓고 잘 운영되고 있는지 지켜보기만 해도 되는 시절은 이제 지났습니다.

SRE 용어를 처음 사용한 구글

사이트 신뢰성 엔지니어링이라는 용어는 구글이 가장 먼저 만들었습니다. 구글이 정의하는 사이트 신뢰성 엔지니어링은 간단하게는 “운영팀을 위한 소프트웨어 엔지니어”를 의미합니다. 운영에 왜 개발자가 필요할까요? 이에 대한 구글의 답변은 이러합니다.

끊임없이 엔지니어링을 추구하지 않으면, 업무 부담이 증가하여 그 부담을 나누기 위해 더 많은 인력이 필요하게 되고, 결국에는 서비스의 크기에 따라 전통적인 운영 업무를 담당하는 인력이 기하급수적으로 늘어나게 된다. (중략) …이러한 숙명에서 벗어나려면 서비스를 관리하는 팀은 코드를 작성해야 한다.

_{사이트 신뢰성 엔지니어링 – Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy (2016)}

어떤 방식으로 운영을 하길래 엔지니어링이 필요할 정도일까요? 어느 정도의 규모의 회사에 이러한 일들이 일어날까요? 이에 대해 대답하려면 사이트 신뢰성 엔지니어의 목표와 업무 방식을 이해해야 합니다.

사이트 신뢰성 엔지니어의 목표

사이트 신뢰성 엔지니어의 목표는 다음과 같습니다.

• 서비스의 안정성을 유지하면서 변화를 최대한 수용한다.
• 시스템의 상태와 가용성을 꾸준히 모니터링한다.
• 어떤 기능에 대해 문제가 발생하면 이에 대해 긴급 대응을 한다.
• 시스템의 변화를 추적하고 관리한다.
• 수요를 예측하고, 계획을 세운다.
• 이를 통해 서비스의 수용력을 확보하고, 효율성을 향상한다.

얼핏 보면 굉장히 어렵고 폭넓은 부분을 다루고 있는 것처럼 느낄 수 있습니다. 이에 대한 기초적인 접근은 바로 시스템을 모니터링하는 것입니다. 결국, 긴급 대응이나 수요 예측 등의 출발점이 바로 모니터링이라고 할 수 있습니다.

여러분이 지금 사용하고 있는 PC의 지표를 모니터링하기 위해 어떤 방법을 사용하나요? macOS에서는 활성 상태 보기라는 프로그램을, Windows PC에서는 작업 관리자 라는 프로그램을 사용해 본 경험이 있을 것입니다.

SRE가 살펴보는 것도 이와 별반 다르지 않습니다. 다만, 수십에서 수백 개의 컴퓨터를 대상으로 한다는 점이 다를 뿐이죠. 그렇기 때문에, 이와 관련된 도구나 서비스 운영 방식에 대한 지식이 반드시 필요합니다.

SRE 모니터링 주요 지표는?

그렇다면, SRE가 주로 살펴보는 지표(메트릭)는 과연 무엇일까요? CPU 및 메모리, 사용량 등을 파악하는 것 외에도 네트워크 요청에 따른 응답 상태, 요청의 횟수나 시간 등도 중요한 지표가 될 수 있습니다.

조직마다 각기 상황이 다르고 아키텍처 중 특별한 지표를 사용할 수도 있겠지만, 여기서는 일반적인 주요 측정항목에 대해서 설명합니다. 아래는 구글의 SRE 조직에서 정의한 “네 가지 황금 시그널(The Four Golden Signals)”로 SRE 모니터링의 주요 측정 항목입니다.

구글은 분산 환경에서 한정된 항목만을 측정할 수 있다면, 이 네 가지에 집중할 것을 권장합니다.

1. 대기 시간 (Latency)

대기 시간은 서비스가 요청에 응답하는 데 걸리는 시간을 나타냅니다. 핵심은 지속 시간뿐만 아니라 성공적인 요청의 대기 시간과, 실패한 요청의 대기 시간을 구별하는 데에도 중점을 두어야 합니다.

2. 트래픽 (Traffic)

트래픽은 서비스에 대한 수요 측정입니다. 대표적인 예로는, 초당 HTTP 요청 수가 있습니다.

3. 오류 (Errors)

오류는 실패한 요청/전체 요청 의 비율로 측정됩니다. 대부분의 경우 이러한 실패는 명시적이지만(예: HTTP 500 오류) 암시적일 수도 있습니다(예: “결과 없음”이라는 메시지를 본문으로 전달하는 HTTP 200 응답).

4. 포화 수준 (Saturation)

포화는 서비스 또는 시스템 리소스를 “얼마나 가득 채워서 사용하는가?”로 설명할 수 있습니다. 전형적인 예로는 과도한 CPU 자원 사용이 있습니다. CPU 자원이 부족하면, 스로틀링을 초래하고 결과적으로 응용 프로그램의 성능을 저하시킵니다.

관찰 가능성 (Observability)

최근 DevOps 업계에서는 “관찰 가능성”이라는 용어가 화두입니다. SRE가 하는 일이 어떤 지표에 대한 모니터링이란 것은 알겠는데, 별도로 “관찰 가능성”이라는 용어를 사용하는 이유는 무엇일까요? 모니터링과 관찰 가능성은 어떻게 다른가요?

모니터링이 메트릭을 측정하는 어떤 행위에 대한 용어라면, 관찰 가능성은 보다 더 넓은 의미로 모니터링의 기반을 닦는 작업을 의미합니다. 이는 달리 말하면 모니터링을 위해서라면 관찰 가능한 시스템을 만들어야 한다는 말이기도 합니다. 관찰 가능성이 높은 시스템이 모니터링에 성공할 수 있습니다.

그렇다면, 관찰 가능성이 높은 시스템을 만들기 위해 사이트 신뢰성 엔지니어가 준비해야 할 역량과 기술은 과연 무엇일까요?

사이트 신뢰성 엔지니어의 역량과 기술

앞서 살펴본 바와 같이 성공적인 모니터링, 높은 수준의 관찰 가능성을 달성하려면 어떤 역량이 필요할까요? 역량을 쌓기 전에 먼저 다음에 설명하는 개념이 무엇인지 아는 것으로부터 시작합시다. 낯선 용어에 익숙해질 필요가 있습니다.

로그 수집

로그(Log)는 시스템이나 애플리케이션에서 발생한 이벤트를 텍스트로 저장한 형태입니다. 많은 시스템이 기본적으로 로그를 남기고 있으며, 이를 수집하는 것으로부터 모니터링은 시작합니다.

메트릭 수집

앞서 설명한 바와 같이 CPU 및 메모리, 사용량, 네트워크 요청에 따른 응답 상태, 요청의 횟수 등 수치화된 데이터가 메트릭입니다. 일반적으로 로그에서 추출할 수도 있으며, 이러한 메트릭을 수집하는 것이 모니터링 도구의 기본적인 기능 중 하나입니다.

분산 시스템

현대의 애플리케이션은 한 군데서 모든 로그나 메트릭을 수집하지 않습니다. 다양한 계층, 여러 가지의 구성 요소에 걸쳐 구현된 시스템이 대부분입니다. 따라서 이러한 시스템의 아키텍처를 읽을 줄 알아야 합니다. 다양한 구성 요소로부터 발생하는 로그 및 메트릭을 수집하기 위해 기본적인 분산 시스템의 이해가 필요합니다.

기본적인 용어를 알았다면 이제 어떤 도구, 어떤 기술을 배워야 할까요? 다음과 같은 기술이 SRE에게 공통으로 요구하는 기술입니다.

1) 리눅스

웹 서비스를 운영하는 대부분의 서버는 리눅스 기반에서 작동됩니다. 따라서 리눅스에서 “작업 관리자”를 어떻게 보아야 하는지 알 필요가 있습니다. 당연히 GUI가 아닌 터미널 환경에서 볼 수 있어야 합니다. 또한 리눅스 상에서 작동하는 다양한 애플리케이션의 로그를 쉽게 찾고, 보고, 분석할 수 있어야 합니다.

또한 기본적인 운영체제 작동 원리를 알면 더욱 좋습니다. 프로세스 관리 등이 이에 포함됩니다. 꼭 전공자일 필요는 없습니다.

2) 스크립팅 언어 (프로그래밍 스킬)

Python, Bash 등은 자동화를 위해 흔히 쓰이는 스크립팅 언어입니다. 대부분의 리눅스에서 즉시 사용할 수 있으므로, 많은 이들이 선호합니다. 보통 자동화나 분석에 요긴하게 쓰입니다.

3) 클라우드 서비스

프로덕션(*실제로 서비스되고 있는 환경을 의미)에서 운영되고 있는 서비스는 보통 클라우드 서비스 위에서 작동됩니다. DevOps 과정에서 리눅스와 모던 웹 아키텍처를 배우고 나면 곧바로 배우는 부분이 바로 클라우드 서비스입니다. Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform 등이 대표적인 클라우드 서비스입니다. 앞서 언급한 주요 메트릭은 클라우드 서비스를 통해 쉽게 관찰이 가능합니다.

4) 컨테이너 기술

컨테이너 기술은 개발과 배포의 흐름을 보다 편리하게 만들어 줍니다. 이 Docker, Kubernetes 등으로 대표되는 컨테이너 기술은 분산 시스템을 쉽게 확장 가능한 스케일로 만들어줍니다.

Kubernetes의 경우 여러분이 모니터링해야 하는 대상이 기본적으로 100개, 1000개 이상이 될 수 있습니다. (구글은 억 단위의 모니터링 대상을 Kubernetes로 관리합니다!) 단순히 하나의 대상을 보는 것이 아니라 여러 개의 메트릭을 종합적으로 볼 수 있는 역량이 필요합니다.

5) 로깅/모니터링 도구

시스템에 가장 잘 맞는 로깅 및 모니터링 도구를 선택해야 합니다. 클라우드 서비스에서 제공하는 도구를 사용할 수도 있고, 오픈 소스를 이용할 수도 있습니다. 혼합해서 목적에 맞게 사용하는 것도 가능합니다. 주요 도구들은 다음과 같습니다.

• CloudWatch (AWS 한정)
• Datadog
• Prometheus, Grafana
• ELK Stack

데브옵스 엔지니어와의 차이점

이쯤 되면 데브옵스 엔지니어와 SRE의 책임과 역할이 어떻게 구분되는지 궁금하실 텐데요. 사용하는 도구는 매우 비슷하지만, 포커스가 조금 다릅니다.

데브옵스 엔지니어는 소프트웨어 통합 및 배포에 중점을 맞추는 데 비해, SRE는 이미 작동하고 있는 서비스의 운영과 모니터링, 장애 대응에 초점을 맞춥니다.

SRE는 특히 “무엇이 정상 상태인가”, “어떻게 해야 안정적인 서비스를 제공했다고 할 수 있는가”에 대한 기준과 목표, 규약을 만드는 일을 진행합니다. (이는 각각 SLI, SLO, SLA라고 부릅니다.) 그렇기 때문에 “신뢰성”을 담당하는 엔지니어라고 불리는 것입니다.

Microsoft의 SRE로 근무하고 있는 Shailender Singh의 글 중 이해하기 쉬운 다이어그램이 있어서 첨부합니다.

위 그림에서 협업의 접점을 DevOps가 만들어 내는 것에 주목해 주세요. 위와 같이 DevOps라는 문화 아래 개발자와 운영자, 사이트 신뢰성에 특화된 사이트 신뢰성 엔지니어(SRE)가 다 함께 협업할 때 비로소 안정적인 서비스를 만들어 낼 수 있습니다.

데브옵스 관련 직무를 꿈꾼다면?

지금까지 사이트 신뢰성 엔지니어가 하는 일, 필요 역량과 기술, 그리고 데브옵스 엔지니어와의 차이점에 대해 살펴보았습니다. 바로 앞 문단에서 설명한 것처럼 사이트 신뢰성 엔지니어링 또한 DevOps라는 문화 아래에 있기 때문에 사이트 신뢰성 엔지니어(SRE) 역시 데브옵스의 개념을 먼저 익힐 필요가 있는데요. 관련 직무에 관심이 있다면 높은 수준의 소프트웨어 통합/배포 및 운영의 핵심 개념을 데브옵스 부트캠프를 통해 배워보시길 바랍니다.

_{글 이호용 Educational Software Engineer (DevOps 부트캠프)
편집 조주연 Content Manager}

---