SRE 7장 - 구글의 발전된 자동화

SRE에게 자동화는 만병통치약이 아니라 주어진 방향으로 힘을 더하는 것과 같다. 목표는 결국 고수준의 시스템, 즉 자율 시스템을 디자인하는 것이다. 

 

자동화의 가치

자동화의 진정한 가치는 무엇일까?

일관성

  시스템이 스케일(scale) 조정은 자동화를 채택하는 주된 이유이기는 하지만, 그 외에도 많은 이유들이 존재한다. 

기본적으로 한 사람 또는 수백 명의 사람이 수행하는 모든 작업들은 매번 같은 방식으로 수행되는 것들이 아니다.

아무리 노력하더라도 사람이 기계처럼 일관성을 가지기란 불가능에 가깝다. 

  이처럼 예상치 못한 일정하지 못한 방식은 실수와 간과로 인해 데이터 품질의 문제를 유발하며, 결국 신뢰성의 문제로 발전하게 된다. 정확하게 정의된 업무 범위와 정해진 절차를 수행하는 데 있어 일관성의 가치는 다양한 측면에서 자동화가 최우선적으로 추구하는 가치다. 

 

플랫폼

  자동화는 오로지 일관성을 제공하기 위한 방법이 아니다. 올바르게 디자인해서 구현된 자동 시스템은 확장이 가능하고 다른 시스템에도 적용이 가능하거나 심지어 이윤을 창출할 수 있는 플랫폼을 제공한다. ( 반면 자동화 없이는 비용 효율성은 물론 확장성도 확보할 수 없다. 즉, 시스템 운영에 대한 세금을 납부하는 것이나 마찬가지다. )

 

이렇게 구축된 플랫폼은 실수를 중앙집중화하는 데도 도움이 된다. 다시 말하면, 앞서 설명한 것처럼 엄청난 인력이 수동으로 동일한 절차를 수행하면 반복적으로 실수가 발생할 수 있는 것에 비해, 자동화된 코드 상에서 수정된 버그는 한 번 수정되면 다시는 발생하지 않는다. 

 

자동화 시스템은 사람보다 더욱 지속적이고 더 빈번하게 동일한 작업을 수행하거나 혹은 사람이 수행하기에는 다소 불편한 작업들을 수행할 수 있다. 게다가 플랫폼은 스스로의 성능을 지표 형태로 제공하거나 혹은 현재 수행 중인 절차에 대해 이전에는 미처 알지 못했던 내용을 발견할 수 있는 기회를 제공하기도 한다. 이런 상세 내용들을 플랫폼을 통해 더 손쉽게 측정할 수 있기 때문이다.

 

더 신속한 수리

자동화된 시스템의 또 다른 이점은 시스템의 일반적인 장애를 해결하는 데 사용할 수 있다는 점이다. 자동화 시스템이 충분히 정기적으로, 그리고 성공적으로 실행된다면, 통상적인 장애에 있어 평균 고장 후 수리 시간(Mean Time To Repair, MTTR)의 절감을 가져올 수 있다. 따라서 문제의 재발을 방지하거나 수리 후 정리 절차를 수행하는 등 남는 시간을 다른 곳에 활용할 수 있어 결과적으로 개발자의 업무 수행 속도 향상을 가져올 수 있다.

 

제품의 생명주기에서 문제가 발견되는 시기가 늦어지면 늦어질수록 수리에는 더 많은 비용이 소모된다. 즉, 문제가 발생하자마자 이를 알아내는 자동화된 시스템을 도입하면 시스템의 전체 비용을 절감할 수 있는 좋은 기회를 얻을 수 있다.

 

더 신속한 조치

SRE의 자동화 시스템이 주로 배포되는 인프라스트럭처 환경에서는 사람이 기계만큼 빠르게 대응하는 것이 대체로 불가능하다.  구글은 엄청난 규모의 자동화 시스템을 구축하고 있다. 구글이 제공하는 많은 서비스들은 이런 자동화 시스템 없이는 오래 살아남기가 힘든데, 그 이유는 이 시스템들이 오래 전부터 수동으로 진행되는 운영 업무의 한계를 알고 있기 때문이다. 

 

시간 절감 ( 가장 중요한 부분이라고 생각 ! )

  시간의 절감은 자동화의 필요성에 대한 근거로 가장 자주 인용되는 부분이다. 자동화에 대한 당위성에 대해, 그 무엇보다 사람이 가장 많이 언급되기는 하지만, 사실 대부분의 경우 그 이점을 바로바로 계산하기에는 어려움이 많다.

 

  엔지니어들은 특정한 자동화 시스템이나 코드를 작성하는 것이 필요한 것인지를 판단할 때 어려움을 겪는 경우가 종종 있다.

 

특히 수동으로 실행되어야 할 작업이 필요하지 않도록 하기 위한 노력 대비 자동화 코드를 작성하는 데 드는 노력을 비교할 때 더욱 그런 어려움을 느낀다. 
그러나 일단 어떤 작업을 자동화 하면 누구라도 그 작업을 수행할 수 있다는 장점은 무시하기 힘들다. 그래서 누구든 적절하게 자동화를 활용할 수 있다면 시간의 절감 효과를 누릴 수 있다.

작업을 수행하는 사람과 실질적인 작업을 분리하는 것은 매우 강력한 효과를 발휘한다.

 

"만일 엔지니어링 절차 및 솔루션을 자동화하지 않는다면 사람이 계속해서 시스템을 유지 보수해야 할 것이다. 사람이 계속해서 이런 작업을 해야 한다면 우리는 인류의 피와 땀 그리고 눈물을 양분으로 삼는 기계일 뿐이다."

 

---

구글 SRE의 가치

  구글의 자동화에 대한 선호는 사실 특정한 비즈니스적 도전에 기인한 것이다. 관리하는 제품과 서비스들은 전 세계를 대상으로 스케일링이 가능해야 하므로 다른 조직에서 일반적으로 보유하고 있는 것과 같은 머신이나 서비스를 다루지 않는다. 진정한 대규모 서비스의 경우에는 자동화 수행에 대한 절충안에 대해 논의할 때 일관성, 신속성, 그리고 신뢰성에 대한 요소들이 주요 논쟁거리가 된다. 

 

다른 조직들은 매우 중요한 장비임에도 불구하고 손쉽게 사용할 수 있는 API가 없다거나, 소스 코드가 없는 소프트웨어 혹은 프로덕션 환경을 완전하게 제어할 수 없는 다른 어떤 장애물이 존재할 수 있다. 구글은 일반적으로 이런 시나리오를 피하기 위해 노력한다. 

구글은 벤더로부터 사용 가능한 API가 제공되지 않으면 이를 직접 개발한다. 심지어 단기적으로 특정 작업을 위해 소프트웨어를 구매하는 것이 더 저렴하다 하더라도, 직접 솔루션을 작성한다. 그렇게 함으로써 API를 생산할 수 있고, 이는 좀 더 큰 장기적인 이점을 가져오기 때문이다. 

결국 시스템 관리의 자동화를 위한 장애물을 극복하기 위해 많은 시간을 투자하며, 그 자동화 시스템을 적극적으로 개발한다. 

 

이론적으로 구글은 가능한 경우에 한 해, 자동화된 머신을 이용해 서비스 머신들을 관리하고 있기는 하지만, 접근법에 대한 약간의 수정이 필요하다. 모든 시스템의 모든 컴포넌트를 자동화하는 것은 적절하지 않으며, 모두가 특정 시점에 자동화를 구현할 능력이나 의지가 있는 것은 아니다. 하지만 보통 구글은 가능하다면 직접 플랫폼을 만들거나 또는 스스로가 시간을 두고 플랫폼을 개발할 수 있는 위치가 될 수 있는 방향으로 선택한다. 

구글은 이런 플랫폼 기반의 접근법을 관리 용이성(manageability)과 확장성(scalability) 측면에서 반드시 필요한 것으로 보고 있다.

---

자동화의 사례

보통 업계에서는 다양한 범주의 문제를 해결하기 위해 코드를 작성하는 것을 자동화라고 표현한다. 

 

자동화의 사례는 그 수를 헤아릴 수 없을 정도지만 몇 가지 예를 들어보자.

• 사용자 계정 생성
• 서비스를 위한 클러스터 턴업이나 턴다운
• 소프트웨어 혹은 하드웨어 설치 준비 및 해제
• 새로운 버전의 소프트웨어 출시
• 런타임 설정 변경
• 특별한 경우의 런타임 설정 변경: 예를 들면 의존성 개체 변경 등

 

구글 SRE의 자동화 사례

  구글 SRE 조직의 가장 큰 공통점은 인프라스트럭처로 전달되는 데이터의 품질을 관리하는 것이 아니라 인프라스트럭처를 운영하는 것이었다. 이런 방향성은 완전히 명확하다고는 할 수 없다. 

  예를 들어, 배포 이후 데이터셋의 절반 가량이 사라져서 이에 대한 알림이 쏟아지는 상황에 대해서는 민감하게 대처하지만, 임의의 계정들을 선별해서 그 속성을 변경하는 등의 코드를 작성하는 경우는 드물다. 그래서 우리에게 있어 자동화란 시스템의 데이터가 아니라, 서비스를 새로운 클러스터에 배포하는 것처럼 시스템의 생명주기를 관리하는 것에 초점이 맞춰져 있다.

 

  구글에서 사용하는 자동화 도구인 퍼펫, 셰프, cfengine, 심지어 펄(perl)과 같은 도구들은 자동화를 위한 컴포넌트의 추상화 수준이 서로 다르다. 펄과 같은 범용 언어들은 이론적으로는 시스템이 접근할 수 있는 API들을 통해 거의 제약 없는 자동화가 가능한 반면, 셰프나 퍼펫은 서비스나 좀 더 높은 수준의 엔티티들에 대한 조작을 통해 한 단계 높은 추상화를 제공한다.

  고수준의 추상화는 관리하고 추론하기가 더 쉽지만, 한편으로는 시스템적으로, 반복적으로, 그리고 잠재적 불일치로 인한 실패가 발생할 수 있는 '추상화의 누수'를 경험할 수도 있다. 

 

  SRE는 자동화를 위한 다양한 철학과 제품을 가지고 있다. 그중 일부는 고수준 엔티티들을 상세히 모델링하지 않고 단순히 바이너리를 배포하기 위한 도구처럼 보이기도 하고, 어떤 것들은 매우 높은 추상화 수준에서 서비스 배포 과정을 기술하기 위한 언어처럼 보이는 것들도 있다. 

후자의 도구들이 재사용성이 높아 공통 플랫폼처럼 사용할 수 있지만, 구글 프로덕션 환경의 높은 복잡도로 인해 경우에 따라서는 전자의 방식이 사태를 즉시 추적해서 파악하기에 더 적합한 경우도 있다.

결국 추상화 수준에 맞게 적절하게 사용할 필요가 있다. 무조건 높은 추상화 수준이 좋은 것은 아니라는 뜻으로 보인다.

 

자동화 클래스의 계층 구조

  그 의도가 무엇이든 간에, 두 시스템(시동 자동화 시스템과 핵심 시스템)의 결합도가 강할수록 우선순위가 애매해지고 그에 따라 제품 개발자가 모든 그에 따라 제품 개발자가 모든 변경 사항에 대해 필요한 배포 요구사항을 테스트하는데 거부감을 갖게 되어 결국 더 빈번한 실패를 경험하게 된다. 게다가 자동화는 그 중요성에 비해 어쩌다가 한 번 실행되므로 테스트가 어렵다. 클러스터 장애 대응은 오랫동안 회자되는 어쩌다가 한 번 실행되는 자동화의 예다. 장애 대응은 몇 달에 한번 정도 실행되거나 혹은 인스턴스 간의 불일치가 발생하기에는 충분할 정도로 드물게 실행된다. 

  그래서 자동화의 혁신은 다음과 같은 단계를 밟는다.

1. 자동화를 하지 않는 단계
   
   • 마스터 데이터베이스에 대한 장애 대응을 각 지역별로 수동으로 진행한다.
2. 별도로 관리되며 시스템에 특화된 자동화를 수행하는 단계
   • SRE가 홈 디렉터리에서 장애 대응 스크립트를 실행한다.
3. 별도로 관리되는 범용 자동화를 수행하는 단계
   • SRE가 데이터베이스 장애 대응을 모두가 사용하는 '범용 장애 대응' 스크립트에 추가해서 실행한다.
4. 내재화되었지만 시스템에 특화된 자동화를 수행하는 단계
   • 데이터베이스에 자체적으로 내장된 장애 대응 스크립트를 실행한다.
5. 자동화가 불필요한 시스템을 도입하는 단계
   • 데이터베이스가 문제를 보고하고 사람의 개입 없이 자동으로 장애 대응을 수행한다.

SRE가 수동 작업을 싫어한다는 점을 잘 알고 있으므로 당연히 그런 작업이 필요하지 않은 시스템을 구축하려고 애쓴다. 하지만 수동 작업을 피할 수 없는 경우도 분명히 존재한다. 

 

예를 들면 특정 시스템과 관련된 설정이 아니라 전체 프로덕션 도메인의 설정 변경을 적용하기 위한 자동화를 생각해보자. 구글처럼 프로덕션 환경이 고도로 집중화된 경우에는 특정 시스템에만 종속되지 않는 변경의 수가 엄청나다. - 이 챕터는 이상하다.

 

---

스스로를 이롭게 하라 : 몽땅 자동화하자!

 당장 수동으로 처리되는 절차를 자동화하는 데 그치지 않고 그보다 더 많은 것을 자동화하려는 노력을 하자.