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

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

 

 

<구글의 능력자들이 모여 만든 책>

 

---

 

목차

• [Part I 들어가며]
  • CHAPTER 1 보안과 신뢰성 사이의 교집합
  • CHAPTER 2 적을 알자
• [Part II 시스템 설계]
  • CHAPTER 3 사례 연구: 안전한 프록시
  • CHAPTER 4 설계 절충
  • CHAPTER 5 최소 권한 설계
  • CHAPTER 6 이해 가능성을 위한 설계
  • CHAPTER 7 범위의 변화를 위한 설계
  • CHAPTER 8 회복성을 위한 설계
  • CHAPTER 9 복구를 위한 설계
  • CHAPTER 10 서비스 거부 공격의 완화
• [Part 3 시스템의 구현]
  • CHAPTER 11 사례 연구: 공개적으로 신뢰할 수 있는 CA의 설계와 구현 그리고 유지 보수
  • CHAPTER 12 코드 작성
  • CHAPTER 13 코트 테스트
  • CHAPTER 14 코드 배포
  • CHAPTER 15 시스템 조사
• [Part 4 시스템 유지 보수]
  • CHAPTER 16 재해 계획
  • CHAPTER 17 위기 관리
  • CHAPTER 18 복구와 사후처리
• [Part 5 조직과 문화]
  • CHAPTER 19 사례 연구: 크롬 보안 팀
  • CHAPTER 20 역할과 책임의 이해
  • CHAPTER 21 보안과 신뢰성 문화 구축

 

---

 

  구글은 (모든 IT인들이 그렇겠지만) 특히나 서버개발자에게 가장 선망의 대상이 되는 회사 중 한 곳이다. 구글급 사이즈의 전 세계에서 들어오는 엄청난 트래픽을 문제없이 소화하는 능력은 아무데서나 얻을 수 있는 능력이 아니기 때문이다. 그렇다고 구글의 장애율이 0%는 아니지만 문제에 대한 예방과 복구 프로세스 등이 잘 정립되어 있다. 그런 구글에서 많은 개발자, SRE, 보안전문가 등이 모여서 집필한 이 책은 수십 년간의 구글의 사례와 노하우들이 녹아들어 있다. 제목은 SRE를 위한다고 쓰여있지만 그렇지 않다. SRE 뿐만 아니라 서버개발자, 더 나아가 프론트개발자, 데이터 분석가 등 모든 개발자들에게도 도움이 되는 보편적이고 공통적인 내용들도 많이 있다.

 

  허구한 날 비밀번호가 노출되었다고 연락이 오고 하루에도 몇 번씩 다운되는 서비스를 사용하고 싶은 사용자가 있을까? 사용자 입장에서도 안전하지 않고 신뢰성이 없는 서비스는 쓰고 싶지 않지만, 기업 입장에서도 이는 굉장한 영업 손실로 이어진다. 쉬운 예로 주말 저녁 피크타임에 배달앱이 몇 시간 동안 마비가 된다면 배달앱 업체뿐만 아니라 가게 사장님, 고객 들까지도 모두 손해를 보게 된다. 요새는 IT가 접목되지 않은 서비스가 사실상 없고 상당히 많은 부분들이 앱이나 웹 같은 서비스를 통해 이루어진다. 이런 상황이다 보니 서비스의 보안과 신뢰도는 더 이상 2순위가 아니게 되었다. 기능이 좋아 매우 많은 사용자를 끌어 모았다고 하더라도 보안 사고나 신뢰성 부분에 문제가 생긴다면 외면받는 것은 순간이다. SRE가 따로 없는 회사라 할지라도 SRE에 대한 투자와 강화는 항상 해야 하고 할 수밖에 없다.

 

  서버개발자로 일하면서 무심코 지나갔던 부분들도 깨닫게 되었다. 예를 들어 서비스 다운 같은 것에 대비해 신뢰성을 높이기 위해 이중화라던지 메시지 큐 도입 등을 하면 보안 위험도가 증가하고 (개인정보 저장같은), 그것에 대비해 보안 위험도를 낮추면 또 이번에는 신뢰성이 낮아지게 되는 케이스도 있다고 한다. 변화(보안이든 코드든 모든 것에 대응이 가능해 보인다)에 대한 내용도 나온다. "변화는 증분적이어야 하고, 문서화되어 있어야 하고, 테스트를 거쳐야 하고, 격리되어야 하고, 검증되어야 하고, 단계적이어야 한다" (p.181) 개발로 인한 코드 변화가 해당 원칙들을 지키고 있는지도 다시 한번 돌아보아야겠다.

 

  12장엔 코딩에 관한 보편적인 내용들도 나온다. 다중 중첩 방지, YAGNI 스멜 제거, 기술부채 해소, 리팩토링 등이 있다. 또한 기본적인 보안과 신뢰성을 지키기 위해 메모리 안전한 언어 사용을 권하고, 강력한 타입 및 정적 타입 검사 사용을 권하고 있다.

 

  14장 코드 배포에 대한 내용 중에 다음 내용들이 눈에 들어왔다.

1. 코드 검토를 반드시 실행하자
2. 자동화를 도입하자
3. 사람이 아닌 결과물을 검증하자
4. 설정을 코드처럼 관리하자

  4개 항목 어느 하나 소홀할 것이 없어 보인다. 코드 검토 (흔히들 코드 리뷰라고 부르는)를 코드의 퀄리티와 안정성을 보장해준다. 자동화는 사람의 실수를 방지해 준다. 결과물을 검증해야 배포자의 실수라던지 악의적인 사용자의 행위를 막을 수 있다. 쿠버네티스 같은 컨테이너 환경을 사용하면 설정을 코드로 이미 관리하고 있다고 한다.

 

 

  그리고 아래 그림처럼 각 단계를 우회할 수 없어야 한다고 했는데 우리 시스템이 이런가 반성하게 되는 계기도 되었다.

<정말 우회할 수 없을까?>

 

  15장 시스템 조사에서는 디버깅에 대해 명언을 찾을 수 있었다.

문제를 해결하고 수정하기 위해 마법을 불리 필요는 없다. 단지 느리지만 구조화된 조사 과정을 거치면 된다. (p. 420)

  자칫 지루하고 따분한 일이 될 수 있는 게 디버깅이지만 중요하고 가치 있는 일이다. 디버깅을 잘하는 왕도는 없으며 끈기와 노력이 중요한 것 같다.

 

  17장 사고 대응에 대한 내용에서는 아래의 도표가 눈에 들어왔다. 구글 같은 글로벌 서비스는 세계 각지에 직원들이 있고 사고를 24시간 계속해서 대응할 수 있다는 점이 놀라웠다.

<24시간 사고 대응이 가능한 구글>

 

  책의 내용과 분량이 상당히 방대하고 다양하다. SRE뿐만 아니라 다른 개발자들도 읽어 보면 좋을 것 같다. 구글만큼 큰 서비스를 운영하고 있지 않더라도 분명 도움이 되는 내용이며, SRE가 따로 없는 우리 회사의 경우 내가 언제라도 SRE로서의 역할도 할 수 있게 관련 역량들을 계속 쌓아 나가고자 한다.

 

 

SRE를 위한 시스템 설계와 구축, 헤더 애드킨스  외 5명 (한빛미디어)

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