[SRE] Ch.01 & Ch.02

SRE 이번 챕터 소개

서론

SRE (사이트 신뢰성 엔지니어링) 이란 책을 읽고, 스터디를 진행했었다. 이후에는 SRE 관련하여 업무도 진행하게 되었다. 이런 경험들을 바탕으로 당시 스터디를 하면서 정리했던 내용과 몇 년이 지난 현재 나의 생각을 섞어서 내용을 작성해보고자 한다.

SRE는 구글에서 무료로 제공하기 때문에 꼭 책을 살 필요는 없다. 관련 링크


소개

시스템 관리자를 활용하는 방법

시스템 관리자를 통해 시스템을 운영하는 방법에는 두 가지 접근 방식이 있습니다. 첫 번째 방법은 전통적인 운영팀을 두는 것이며, 두 번째 방법은 SRE(Site Reliability Engineering)를 도입하는 것입니다.

운영팀을 두었을 때 장단점 (전통적인 방식)

장점:

  • 전문 인력 풀을 구성할 수 있습니다.
  • 다양한 운영에 활용할 수 있는 도구들이 많이 존재합니다.
  • 일반적으로 시스템이 안정적으로 운영될 가능성이 높습니다.

단점:

  • 운영팀의 비용이 발생합니다.
    • 직접 비용: 서비스가 확장됨에 따라 발생하는 운영 비용
    • 간접 비용: 역할을 분리함에 따라 발생하는 비용
      • 배경지식 스킬이 다른 경우
      • 목적 추구하는 바가 다른 경우
  • 두 역할 사이에서 충돌이 발생할 수 있습니다.
    • 개발팀(dev): 서비스 개발, 새로운 기능을 만들고 빠르게 반영하여 사용자에게 제공합니다.
    • 운영팀(ops): 안정적으로 서비스를 운영하며 변화에 보수적으로 접근합니다.

SRE : 서비스 관리에 대한 구글의 해법

SRE은 구글에서 개발한 서비스 관리에 대한 해결책입니다. SRE 엔지니어는 서비스를 운영하고 관리하기 위한 시스템을 개발합니다. 이들은 개발을 위한 50%의 시간을 투자해야 합니다. 이는 직접 코드를 수정하기도 하며 자동화된 시스템을 구축하여 운영을 자동화합니다.

SRE 역할은 다음과 같은 책임을 집니다:

  • 가용성, 응답시간, 성능, 효율성, 변화 관리, 모니터링, 위기 대응, 수용량 계획

DevOps & SRE

DevOps는 개발과 운영 역할 사이의 소통, 협업, 통합 및 자동화를 하기 위한 방법론입니다.
반면에 SRE은 서비스 관리를 위한 구글의 해법으로, 시스템 개발과 운영 업무를 동시에 수행하는 개념입니다.
둘의 개념은 유사하지만 SRE은 운영에 초점을 두고 있습니다.

포스트 모텀(Postmortem)

  • 포스트 모텀(Postmortem)은 장애가 발생한 후 상세한 분석과 개선을 수행하는 과정을 의미합니다. 장애가 발생했을 때 해당 문제를 해결하고 앞으로 동일한 문제를 예방하기 위해 중요한 단계입니다.

에러 예산(Error Budget)

  • 에러 예산(Error Budget)은 서비스의 가용성을 보장하기 위해 수용할 수 있는 오류 발생을 나타냅니다. 이 예산을 기반으로 서비스에 대한 변경을 진행하고, 허용 가능한 오류 한도 내에서 시스템을 운영을 한다.

모니터링

  • 장애에 대한 판단은 시스템이 하며 사람이 대응이 필요한 경우만 알림을 발생 시켜야 함
  • 알림 : 사람이 즉각적으로 대응 해야하는 상황
  • 티켓 : 사람의 대응이 필요하지만 즉각적인 대응이 필요 없는 상황
  • 로깅 : 향후 분석이나 조사를 위해 기록 하는 내용

긴급대응

  • MTTR (Mean time to repair : 평균 복구 시간) 복구할 때까지 소요된 시간이 굉장히 중요함
  • 시스템에 의한 > 행동 지침에 숙련된 엔지니어 > 능력이 뛰어난 엔지니어

변화 관리

70%의 장애는 변경으로 인해 발생한다고 알려져 있습니다. 따라서 변화 관리는 매우 중요합니다. 안정적인 서비스를 위해 변경을 단계적으로 출시하고, 문제가 발생하더라도 빠르고 정확하게 도출하고 안전한 롤백 방안을 마련하는 것이 필요합니다.

수요 예측과 수용 계획

수요 예측은 미래의 사용자 요구를 예상하는 과정으로, 서비스가 처리해야 할 트래픽과 요청량을 파악하는 것입니다. 이를 위해 과거의 사용 패턴과 데이터를 분석하며, 통계적인 방법과 머신 러닝 알고리즘등을 활용합니다.

수용 계획은 예상된 수요에 맞게 필요한 자원을 할당하는 것을 의미합니다. 즉, 서버, 스토리지, 네트워크 등의 자원을 얼마나 할당해야 하는지를 계획하는 단계입니다. 수용 계획은 예상치 이상의 트래픽에 대비하여 여유분의 자원을 확보하는 것이 중요합니다. 이는 서비스의 안정성과 가용성을 보장하는 핵심적인 역할을 수행합니다.

프로비저닝

프로비저닝은 서버 (Server), 네트워크 (Network), 스토리지 (Storage) 등의 자원을 설정하고 구성하는 작업을 의미합니다. 새로운 서비스를 배포하거나 변경을 진행할 때, 필요한 자원을 적절히 프로비저닝하여 효율적인 운영을 지원합니다.


SRE 관점에서 바라본 구글의 프로덕션 환경

구글의 하드웨어 관련 내용은 Borg 라던지, 관련 내용이 책 뒤에도 많이 나오지만, SW 개발자인 나의 시점이나, 현재 IT인프라 수준에서는 이 내용을 다시 정리 할 정도로 중요한 내용이 없는것 같다. 그래서 간략히 정리했다.

  • 구글의 대부분 컴퓨터 자원은 구글이 직접 디자인한 데이터센터에 있습니다.
  • 데이터센터는 전원 공급, 냉각 기능, 네트워크 등 모든 요소가 구글이 직접 설계되었습니다.
  • 구글의 컴퓨터 하드웨어는 모든 데이터센터에 동일하게 적용됩니다.
  • 일부 데이터센터는 다양한 세대의 컴퓨터 하드웨어를 사용하기도 합니다.
  • 데이터센터는 랙으로 구성되며, 랙은 수십대의 머신이 일렬로 배치되어 있습니다.
  • 랙들이 결합하여 클러스터를 형성하고, 클러스터들이 결합하여 데이터센터를 구성합니다.
  • 데이터센터 건물들이 모여 캠퍼스를 이룹니다.

구글은 자체적으로 컴퓨터 하드웨어를 설계하여 데이터센터에 적용하는 접근 방식을 취하고 있으며, 효율적인 데이터센터 구조를 구축하여 안정적이고 빠른 서비스 제공을 위해 노력하고 있다고 한다. 국내 기업들도 현 시점에는 비슷한 구조로 서비스를 하고 있기 때문에 특별할게 없다고 생각이 든다.


다음편