SRE를 위한 시스템 설계와 구축

이 책의 부제는 "구글이 공개하는 SRE 모범 사례와 설계, 구현, 운영 노하우"

저자분들이 구글에서 현재 근무중이시거나, 이전에 구글에서 근무를 하신 분들로 구성되어 있습니다.

 

요즘 SRE라는 용어가 많이 회자되고 있는것 같습니다.

부서이름도 SRE라는 부서명을 사용하는 곳도 있습니다.

 

■ SRE가 무엇인가요?

Site Reliability Enginee의 줄임말 입니다.

한글로 통용되는 번역어는 "사이트 신뢰성 엔지니어" 라고 해석됩니다.

처음에 이 용어가 잘 와 닿지 않았습니다. 정확히 SRE 업무가 무엇인지 정의내리기 어려웠습니다.

 

사이트 신뢰성 엔지니어링(SRE)은 IT 운영에 대한 소프트웨어 엔지니어링 접근 방식입니다. SRE 팀은 소프트웨어를 툴로 활용하여 시스템을 관리하고, 문제를 해결하고, 운영 태스크를 자동화합니다.
SRE 팀은 기존에 운영 팀이 수동으로 하는 경우가 많았던 태스크를 받아 엔지니어 또는 운영 팀에 넘기고, 엔지니어 또는 운영 팀은 소프트웨어 및 자동화를 사용해 문제를 해결하고 프로덕션 시스템을 관리합니다. 
SRE는 확장 가능하고 신뢰성이 높은 소프트웨어 시스템을 생성할 때 유용한 방법입니다. 코드를 통해 대규모 시스템을 관리할 수 있으므로 수천 대에서 수십만 대에 이르는 머신을 관리하는 시스템 관리자에게 더 큰 확장성과 지속가능성을 제공합니다. 
사이트 신뢰성 엔지니어링은 Google 엔지니어링 팀의 Ben Treynor Sloss가 창안한 개념입니다. 

해당 내용을 읽어보면 DevOps vs SRE와의 차이점이 궁금할것 같습니다.
DevOps와 SRE 비교
DevOps는 신속한 고품질 서비스 제공을 통해 비즈니스 가치와 대응력을 향상시키기 위한 기업 문화, 자동화, 플랫폼 설계에 대한 접근 방식입니다. SRE는 DevOps의 구현으로 간주될 수 있습니다.

코드 및 새 기능의 측면에서 DevOps는 개발 파이프라인을 효율적으로 거치는 데 중점을 두는 반면,
SRE는 사이트 신뢰성과 새로운 기능 개발 간 균형을 맞추는 데 중점을 둡니다. 

참고링크 : https://www.redhat.com/ko/topics/devops/what-is-sre

 

해당 책에서는 머릿말에 아래와 같이 소개합니다.

① 사이트 신뢰성 엔지니어(SRE)와 보안 엔지니어는 빌드는 물론 제품에 의도적으로 문제를 일으키고 이를 수정하기도 한다.

ⓩ 담당직무는 개발뿐 아니라 운영도 포함한다

③ SRE와 보안 엔지니어는 전통적인 소프트웨어 엔지니어보다는 전문가에 가깝다.

④ 팀에 공헌하는 사람이기보다는 방해꾼처럼 보이는 경우가 종종 있다.

⑤ 제품팀에 소속되지 않는 경우가 많다

 

이제 SRE책에서 무엇을 소개하고, 설명하고 구성되어 있을지 살펴보면

개발언어책보다 조금 더 큰 범주를 설명하고 있습니다.

"구글 전체의 시스템을 관리하는 입장에서, 하나의 기능의 테스트 보다 전체의 숲을 보게 될 것이고

  그 숲은 미국만 대상으로 하지 않고 전세계를 대상으로 시스템 디자인  뿐만 아니라 수많은 Case를 고려해야 하고

  안정적으로 서비스를 하기 위해서 보안 및 장애, 자연재해등도 고려해야 할것입니다."

 

책의 목차를 살펴보는 중에 조금 예상과 다르게 눈에 들어온 부분이 있었습니다.

예상했던 내용으로 수긍이 되었던 목자정도로는

① 보안과 신뢰성 (비밀번호 등등, 공격, 해킹 등등)

ⓩ 설계에 대한 부분 (Proxy, API설계, 인증)

③ 코드 작성 관련, 코드 테스트, 코드 배포

④ 재해 계획, 장애, 위기

 

마지막 Chapter "조직과 문화" 에 대한 부분은 조금 신선하게 다가왔습니다.

조직문화를 관리하는 별도의 팀이 있겠지만, 

- 역활과 책임의 이해

- 신뢰성을 확보하기 위한 문화 구축

등에 대한 부분은 SRE역활이 기술적인 부분 보다 더욱 큰 범주를 나타낸다고 생각이 들었습니다.

 

 

■ 내용 살펴보기

책의 내용 구성시 가장 눈에 들어온 사항은 "실제 구글 사례"를 통해서 이야기를 풀어가는 점이 매우 현실감 있게 다가왔습니다.

PART1 : 보안과 신뢰성에 대해서 다룹니다. 

보안이라는 분야가 어떠한 로직을 이렇게 바꾸면 된다라는 하나의 기능적인 개발범위처럼 한정할수 없는 분야입니다.

서비스를 하는 입장에서 보안취약점 점검을 하고, 모니터링도 강화하지만, 우리는 어떻게 보안에 안전한 서비스를 제공할수 있을까요?

CIA3대 조건인 기밀성, 무결성, 가용성 측면에서 이야기를 설명하며, 약간은 이론적이지만 정의가 필요한 사항을 다시 한번 분류합니다.

 

PART2 : 시스템 설계에 대해서 다룹니다.

처음부터 잘 구성된 시스템 설계를 기반으로 서비스를 구성할 수도 있지만, 이것은 현실에서 많이 어렵습니다.

그 이유는 처음 서비스를 시작하면 작은 규모로 시작하게 될것이고, 너무 많은 요소를 구성하다 보면 Over-Spec이 될수도 있고

기존에 있는 서비스 구성에 새로운 서비스가 Add-On되는 구조로 서비스가 구성되는 경우도 많기 때문입니다.

· 설계 절충

· 최소 권한 설계

· 이해 가능성을 위한 설계

· 범위의 변화를 위한 설계

· 회복성을 위한 설계

· 복구를 위한 설계

· 서비스 거부 공격의 완화

시스템에 대한 설계시, 위에 언급한 다양한 측면에 대해서 설명을 하며 구글의 사례도 소개를 합니다.

API인증에 대한 설계, 다양한 인터페이스 중에 어떻게 선택해야하는지, 등등 평소에 들어본 기술적인 요소도 나오지만

전혀 생각하지 못했던 과정에서 이런 고민이 필요하다는 것을 알게 됩니다.

PART3 : 시스템 구현에 대해서 이야기를 합니다.

앞장에 보안, 시스템 설계에 대해서 이야기 하고 자연스럽게 개발자 입장에서 조금더 많이 접하게 되는 구현부분입니다.

책의 구성에서 구글 사례를 언급을 해주는데, "사례연구"라는 별도의 Section으로 공감도를 이끌어 냅니다.

왜 이런 애기를 책을 통해서 설명하는지 조금 더 쉽게 간접체험하는 좋은 내용입니다.

 

코드 작성 / 코드 테스트 / 코드 배포 / 시스템 조사로 구성되어 있습니다.

코드에 대해서는 SQL주입 취약점(TrustedSqlString), XSS방지(SafeHtml)등 보안에 대한 조금더 심도있는 예시 및 

롤아웃전략(기존 코드에 대한 수정작업시) 증분 롤아웃, 레거시 변환 및 간결하게 코드 작성을 하기 위한 원칙 예시

여러 도구 (라이브러리 등)을 선택할때의 우선적으로 고려해야 하는 사항 (메모리 안전성,강력한 타입 체크)등을 여러 언어를 비교하면서

실제 업무에서 사용하게 될 판단기준을 제시합니다.

코드 테스트시, 단위테스트 - 통합테스트 의 개념 및 동적, 정적 프로그램 분석, 단위 테스트 작성시 조금더 효율적으로 구성하기 위한 설명으로 구성되어 있습니다.

코드 배포시에는 빌드 > 테스트 > 배포의 기본적으로 알고 있는 구조에서 세부적으로 단계마다 검증해야 하고, 보완해야 하는 

다양한 케이스가 있는것을 알수 있습니다. 

PART4 : 시스템 유지보수

이제 개발도 완료하여서, 배포를 하였으므로 운영되고 있는 서비스에 대한 유지보수가 필요합니다.

SRE의 역활이 SW의 생명주기를 모두 커버해야 하는 것 같다는 생각이 들었습니다.

재해계획 / 위기 관리 / 복구와 사후 처리에 대해서 설명합니다.

해당 부분은 코드적인 부분은 아니고, 정책적인 부분 / 이런 일이 있을때 어떻게 유관서버와의 업무가 정리되어야 하는지

가이드적인 부분이 많이 있습니다. 

 

PART5 : 조직과 문화

"크롬 보안팀 : 사레연구" 

2006년 윈도우 운영체계를 이한 오픈소스 부라우저를 2년 내에 개발할 목적으로 한팀이 구글에서 생겨났다 

구글의 사례연구로 chap19에 있는 내용입니다.

지금은 많은 사용자들이 메인 브라우저로 크롬을 사용중입니다.

이 팀에서 "크롬 제품은 보안을 제품의 핵심원리로 받아들이고 팀 공통의 책임으로 생각하는 문화를 구축했기 때문이다."

처음 beta버전부터 어떻게 조직에서 한가지 목표를 위해서 잘 협업하는지 사례는 아주 현실감 있게 다가옵니다.

 

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."