SRE에 자동화된 진화 적용

콘텐츠에는 다음이 포함됩니다.
SRE에 대한 자동화 시스템의 가치
자동화 시스템의 진화
해외 인터넷 기업의 SRE 자동화 적용 사례
국내 운영 및 유지보수 분야의 자동화 실습.

SRE는 Site Reliability Engineering의 약자로 외국 인터넷 기업에서 유래한 단어 또는 새로 정의한 직위입니다. 전통적인 시스템 관리자 모델 시대에는 이 역할을 운영 및 유지 관리라고 불렀고, 해외에서는 운영이라고 불렀습니다.

Google SRE의 VP는 Ben Treynor입니다. 2003년 회사에 입사했을 때 그의 첫 번째 임무는 7명으로 구성된 '생산 운영 및 유지 관리 팀'을 구성하는 것이었습니다. 그러나 그는 곧 Google 시스템의 증가 속도로 인해 기존의 운영 및 유지 관리 모델로는 안정적인 운영 및 유지 관리 요구 사항을 신속하게 충족할 수 없다는 사실을 발견했습니다. 그는 수석 소프트웨어 개발자이기 때문에 R&D 팀처럼 운영 및 유지 관리 팀을 구성했습니다. 우리는 개발 능력과 시스템 관리에 대한 지식을 갖춘 많은 R&D 엔지니어를 채용했습니다. 가장 중요한 것은 그들이 반복적인 작업을 싫어한다는 것입니다. 일부 모범 사례, 방법, 프로세스 및 방법을 코드로 굳히고 이 방법을 사용하여 규모 확장 및 복잡성 증가에 대처합니다.

일반적인 SRE 활동은 소프트웨어 엔지니어링, 시스템 엔지니어링, 퀴즈, 프로세스 부담의 네 부분으로 나뉩니다. 그중에서도 일상적인 운영 및 유지보수 서비스와 직접적으로 관련된 업무 유형이 있음을 알 수 있는데, SRE에서는 이를 비효율적인 업무로 정의하고 있으며, 구글은 여전히 ​​이를 Toil이라는 특별한 단어를 사용하여 기술하고 있다.

Trivia는 운영 및 유지 관리 서비스에서 수동적이고 반복적이며 전술적인 작업입니다. 그 성장은 서비스의 성장과 선형적입니다. 이 작업 부분은 자동화될 수 있습니다. Google은 SRE가 자신의 시간 중 최소 50%를 소프트웨어 엔지니어링 프로젝트에 투자해야 한다고 공개적으로 제안했습니다. 통제하지 않으면 사소한 문제가 점점 더 많아지고 SRE 직원의 시간 대부분을 빠르게 차지하게 되기 때문입니다. 사소한 문제를 줄이고 서비스 규모를 확대하는 작업이 SRE의 E(Engineering)입니다.

이 동영상에서 SRE에 대한 자동화의 가치는 주로 성능과 효율성이라는 두 가지 측면에서 비롯된다는 것을 알 수 있습니다. 자동화하면 많은 사람들이 가장 먼저 생각하는 것이 효율성 향상이다. 실제로 SRE 인력은 단순히 효율성을 높이는 것보다 시스템 성능과 속도, 유연성 사이의 균형을 강조한다. 자동화는 작업의 수동 실행으로 인한 불일치를 제거하고 "명확한 범위와 알려진 단계를 사용하여 일관된 절차 실행"을 보장함으로써 시스템 성능을 보장합니다. 이것이 자동화의 주요 가치입니다.

자동화 시스템은 확장 가능하고 널리 적용 가능한 플랫폼을 제공할 수 있습니다. 플랫폼은 문제를 중앙 집중화하고, 대규모 시스템 오류를 처리하며, 인간이 할 수 있는 것보다 더 지속적이고 더 자주 작업을 실행할 수 있습니다. 그리고 플랫폼 자체의 성과 지표를 노출할 수 있기 때문에 이전 프로세스에서는 쉽게 눈에 띄지 않았던 세부 사항을 발견하는 데에도 도움이 될 수 있습니다. 물론 플랫폼화의 기본은 올바른 설계와 구현에 있습니다. 자동화로 인해 효율성이 향상되는 것을 이해하는 것이 더 쉽습니다. 자동화된 프로그램을 작성하는 데 소요되는 노력과 시간과 수작업을 취소하여 절약되는 부분을 비교 분석하는 경우가 많지만 일단 자동화가 구현되면 특정 작업은 특정 작업자와 분리되므로 진행할 때 측정해보면, 자동화로 절약된 시간과 노력은 모든 사용자에게 돌아가야 합니다.

Google 데이터 센터 클러스터 가동 프로세스를 담당하는 SRE인 Joseph Bironas는 다음과 같이 말한 적이 있습니다. "자동화할 수 없는 프로세스와 솔루션을 계속 생산한다면 시스템 유지 관리를 수행할 사람이 계속 필요할 것입니다. 이 작업은 기계에 인간의 피, 땀, 눈물을 공급하는 것과 같습니다. 특수 효과는 없지만 화난 시스템 관리자로 가득 찬 매트릭스 세계와 같습니다."

Google SRE의 자동화 프로세스는 위의 단계를 거쳤습니다. 첫 번째 단계는 전적으로 수동 작업에 의존한 후 외부에서 유지 관리되는 시스템별 자동화 스크립트를 사용하여 작동하는 비자동화 단계입니다. 특정 시스템 자동화는 점차 일반 시스템 자동화로 발전한 다음 외부에서 유지 관리되는 자동화 시스템을 내부적으로 유지 관리되는 자동화로 대체합니다. 자동화 시스템은 결국 운영 및 유지 관리 플랫폼에 통합되고 수동 트리거가 필요하지 않은 자동화 시스템으로 발전했습니다.

Google의 리소스 관리 시스템 Borg는 Google SRE에서 오랫동안 사용해온 대표적인 자동 애플리케이션 출시 시스템입니다. 자원 관리가 왜 그렇게 중요한가요? 규모가 너무 크기 때문에 운영 비용이 진화의 유일한 장애물이 됩니다. 기술적으로 말하면, 통합 리소스 관리 시스템은 구현하기가 매우 어렵고 인프라의 품질에 따라 이 시스템의 기능이 결정됩니다. 특히 분산 환경에서는 다양한 비즈니스 시나리오의 물리적 서버에 대한 요구 사항이 완전히 동일하지 않습니다. Google의 Borg가 통합 리소스 관리를 달성하기 위한 전제 조건은 GoogleFS, BigTable, Chubby, GSLB 등과 같은 핵심 기술의 지원입니다. SRE는 이 시스템의 사용자이며 시스템 안정성을 위해 지속적으로 피드백을 제공하고 Borg 시스템 사용을 개선합니다. 요구 사항, 지금까지 Borg는 여전히 Google에서 내부적으로 사용하는 애플리케이션 게시 시스템입니다.

우선, Borg 시스템은 완전히 계층화된 시스템 아키텍처입니다. 가장 기본적인 파일 시스템부터 최상위 로드 오프로딩까지, 기술 스택의 각 계층은 Google 내에서 고유합니다. 이것의 장점은 경험을 축적하고 재사용할 수 있다는 것입니다. 국내 기업의 시스템 아키텍처도 개발 과정에서 계층적 조직 구조를 거치게 되며, 인적 요소를 제외하고 여러 시스템을 결합하여 많은 계층이 구축됩니다. 표면적으로는 비용이 절감됐지만 실제로는 인력유지비용이 늘었다. 이 시점에서 외국 시스템의 발전은 잠시 접어두고 기술을 선택할 때 어떻게 해야 할까요? 경험에 비추어 볼 때, 동료들이 공유하는 여러 오픈 소스 시스템으로 구성된 단일 계층 시스템은 단기적인 효과가 분명한 지름길 방법입니다. 기업의 비즈니스가 빠른 속도로 발전하면 모든 리팩토링은 뒤집고 다시 시작하기 위한 파괴적인 도구가 됩니다. 크고 작은 다양한 엔터프라이즈 시스템에서의 경험을 통해 저는 이러한 변화의 역동성을 깊이 이해하고 있습니다. SRE에서 도구 변경의 아이디어는 오래된 오픈 소스 도구를 새로운 오픈 소스 도구로 대체하는 것이 아니라, 우리의 안정성 요구 사항은 도구 선택 수를 단순화하고 이를 기반으로 우리 자신의 요구 사항을 진정으로 고려해야 합니다. 결국 우리는 자체 개발한 자동화 시스템으로 가는 길을 가야 합니다.

둘째, Borg 시스템의 인프라 기술은 충분히 발전했습니다. SRE는 약간 중복되지 않나요? 분명히 기술 발전은 SRE 방법론을 대체할 수 없습니다. 현재 업계에서 가장 널리 사용되는 DevOps 개념에는 비용 및 안정성에 대한 추가 설명이 포함되어 있지 않으며 자동화 및 생산성 향상과 같은 다양한 방식에 중점을 두고 있습니다. 이러한 관행은 비즈니스 신뢰성과 비용 제어 간의 견제와 균형인 비즈니스 시나리오의 지속 가능한 개발의 핵심 문제를 해결할 수 없습니다. SRE 방법은 최저 비용으로 최대의 비즈니스 이점을 얻는 것입니다. 따라서 SRE 포지션은 코드 작성이 가능한 시스템 운영 및 유지보수 엔지니어를 모집합니다. 운영 및 유지보수만 한다면 절대 순수 개발자를 확보할 수 없습니다. 그러므로 우리는 인지적 위도를 높이고 소프트웨어 엔지니어링의 관점에서 기업의 현재 내부 비즈니스 시스템을 해결해야 합니다. 저자의 개인적인 경험을 바탕으로 우리는 테스트 시스템, 프로젝트 관리 시스템, 프로세스 제어 시스템, 릴리스 시스템 등을 포함한 제품을 개발하는 기술 회사입니다. 회사의 규모가 크든 작든 상관없이 필요합니다. SRE 드라이버가 없으면 공백을 메울 도구를 선택하게 됩니다. 그러나 시스템은 서로 관련되어 있지 않으며 내부적으로 누구도 이 문제의 반복을 실제로 추진할 수 없습니다. 마지막으로, 우리는 단순히 운영과 유지보수 또는 개발을 통해 이 문제를 해결하도록 놔두었습니다. 실제 상황은 이 문제를 완전히 해결할 수 없다는 것입니다.

셋째, SRE는 외국 인터넷 기업 어디에서나 볼 수 있지만, 중국에서는 그러한 입장이나 아이디어 확산이 거의 없습니다. 이것은 문화적 차이 때문일까요? 저자는 국내 운영 및 유지관리 시스템이 지속적으로 진화하는 과정에서 현재 외국의 인지 수준에 비해 발전 속도가 확실히 느리다고 본다. 하지만 타오바오의 등장으로 알리바바의 기술지원 부서는 사실상 국내 SRE에 대한 최고의 검증이다. SRE의 이점은 매우 분명하지만 중소기업 사이에서 회사를 홍보하는 것은 매우 어려울 것입니다. 핵심 문제는 외국 기술 서비스 제공업체 시스템이 매우 건전하다는 점입니다. 중소기업이 SRE 전환을 원할 경우 다수의 기술 서비스 제공업체의 솔루션을 얻을 수 있습니다. 그리고 기업들은 그러한 기술의 사전 연구 과정에 비용의 일부를 기꺼이 지출할 의향이 있습니다. 국내 기업들은 성숙한 기술을 구매할 것으로 기대하며 인프라에 에너지를 투자할 의지가 없습니다. 비용 통제 역시 인건비 고려 사항을 기반으로 하기 때문에 기술 제공업체가 운영할 공간을 확보하기가 어렵습니다. 따라서 이러한 곤경에서 클라우드 컴퓨팅 사업의 발전은 윤활유 역할을 할 수 있습니다. 즉, 공유 기술 경제는 SRE가 중국에 진출하는 방법이 될 수 있습니다. 예를 들어 저자가 일하는 Shuren Cloud는 기업과의 협력을 통해 기업이 요구하는 플랫폼 구축을 완성하는 SRE 개념을 구현하는 경량 애플리케이션 관리 플랫폼이다. 이러한 협력 과정에서 진화된 시스템은 부가가치의 역할을 하며 다른 기업의 Shuren Cloud Platform을 통해 윈윈(win-win) 상황을 달성하도록 장려됩니다. 결과에 따르면 기업은 성공적인 SRE 실행 결과를 얻었으며 기술 서비스 제공업체는 SRE를 실행할 기회를 얻었습니다.

넷째, SRE는 도구를 잘 활용합니다. 문제 해결에서 문제에 대한 심층 분석, 문제 해결을 위한 모델과 체크리스트 제공으로 문제 해결 방식의 변화입니다. 예를 들어 Netflix의 SRE는 Linux 시스템 성능을 해결할 때 SRE에 체크리스트를 제공합니다.

국내 운영 및 유지보수 분야의 급속한 발전 반복에 국한하여, 저자는 돌파구로서 가장 고민되는 세 가지 영역에서 자동화 실천 현황을 세분화할 것이다.
1. 모니터링 및 알람

국내 모니터링 및 알람 도구는 종류가 많지만, 구현할 수 있는 대중적인 솔루션은 거의 없습니다. 기존 기업에서 가장 일반적으로 사용하는 것은 Zabbix입니다. 또한 중국 Xiaomi가 개발한 오픈 소스 인터넷 기업 수준 모니터링 도구인 Open-Falcon도 옵션입니다. 그러나 두 시나리오 모두 피할 수 없는 매우 직접적인 질문이 있습니다. 즉, 비즈니스 시나리오에서 문제를 분석하고 실제 문제를 해결하기 위해 최단 경로를 사용하는 방법은 무엇입니까? 모니터링의 관점에서는 시스템 수준, 비즈니스 수준, 서비스 수준 등 다양한 차원이 있습니다. SRE 관점에서 문제를 다룰 때, 선험적인 경험을 바탕으로 다양한 시스템 지연을 기반으로 계획을 세우는 것이 아니라 용량 계획이 첫 번째 단계입니다. 그래서 처음부터 도구가 가장 어려운 문제는 아니었습니다. Zabbix를 예로 들어 모니터링할 수 있는 차원은 시스템 상태, 데이터베이스의 QPS 및 Redis의 메모리입니다. 하지만 웹사이트 속도가 느려지면 모니터링 입장에서 할 수 있는 게 아무것도 없습니다. 문제를 파악하고 해결하려면 풀링크 분석이 필요합니다. DevOps 경험을 바탕으로 이런 질문을 할 가능성은 없지만 문제가 발생했을 때 자동으로 서버를 전환하거나 용량을 자동으로 확장하여 문제를 해결하는 방법에 대해 질문합니다. DevOps 시나리오에서는 비용 제어가 불가능합니다. 관리자는 예산 비용만 강제할 수 있으며 업스트림이나 다운스트림 모두 비즈니스 운영 비용을 완전히 이해할 수 없습니다.
2. 로그 모니터링

국내 로그 모니터링은 ELK(Elasticsearch, Logstash, Kibana) 기술 스택을 광범위하게 사용합니다. 이 기술 스택은 매우 인기가 높으며 기업의 수많은 내부 로그 문제도 해결했습니다. 그러나 실제 시나리오에서 비즈니스 로그 관리는 여전히 매우 고통스럽습니다. 하나는 실시간 로그를 조회하는 것이고, 두 번째는 이력 로그를 집계하는 것이다. 로그 쿼리 사용을 효과적으로 제공하는 방법은 무엇입니까? Qunar 운영 및 유지 관리 팀은 Apache Mesos에서 내부 부서에 주문형 ELK 서비스를 제공함으로써 개발자가 언제든지 자신의 비즈니스 로그를 쿼리하고 분석할 수 있는 방법을 공유했습니다. . 쿼리가 완료되면 ELK 서비스 인스턴스가 자동으로 삭제됩니다. 저자는 이러한 혁신적인 접근 방식이 실제로 SRE 사고의 실천이라고 믿습니다.
3. 지속적인 통합 및 출시 시스템

국내 운영 및 유지 관리에 가장 일반적으로 사용되는 도구는 Jenkins를 사용하여 지속적인 통합 및 릴리스를 완료하는 것입니다. 하지만 우리는 Jenkins를 사용할 수 있는 한 심층적인 연습을 중단하는 경우가 많습니다. SRE 관점에서 먼저 지속적인 통합의 비즈니스 문제점이 무엇인지 분석합니다. 지속적인 통합 과정에서 테스트 시스템이 연결되기 때문입니다. 따라서 저자는 지속적 통합의 목적이 제품 품질을 지속적으로 향상시키는 것이라고 믿습니다. 핵심 목표를 염두에 두고 우리가 제어하는 ​​것은 단순히 Jenkins 작업을 관리하는 방법이 아니라 테스트 효율성을 향상하고 통합 시간을 단축할 수 있는지 여부입니다. 목표 목록을 수립하고 이를 SRE 개선 프로세스에 반영하면 분명 다른 결과가 나올 것입니다. 지속적인 출판은 사실 또 다른 주제입니다. 문제는 사용자가 출판을 완전히 이해하지 못한다는 것입니다. 릴리스에는 그레이스케일 릴리스, 테스트 릴리스, 롤링 릴리스, 롤백 릴리스 및 기타 시나리오가 포함됩니다. 그리고 모든 시나리오는 되돌릴 수 있어야 합니다. 이 문제를 해결하려면 Jenkins만으로는 이 문제를 해결할 수 없습니다. 이를 충족하려면 일련의 경량 애플리케이션 관리 플랫폼 지원과 같은 확장된 도구가 필요합니다.

산업의 발전 역사로 볼 때 기술 표준화는 필연적인 진화 과정이며, 운영 및 유지 관리 자동화는 실제로 표준화의 발현입니다. SRE를 시작하는 첫 단계부터 업무 책임을 정리하고, 정리하고, 해결해야 할 문제는 체크리스트로 문서화해야 한다. 비즈니스의 신속한 구현을 촉진합니다. 다음 단계는 이러한 비즈니스 지표와 시나리오를 시각화하여 회사가 운영 비용을 절감하고 서비스 시스템의 목표를 정량화하는 데 도움을 주는 것입니다. 유능한 기업의 경우 개발 프로세스 중에 다양한 리소스의 인터페이스가 통합됩니다. 이 프로세스는 작성자의 경험에 비추어 볼 때 실제 결과에 따라 작은 단계로 반복되고 신중하게 구현되어야 합니다. 비용을 고려하지 않은 플랫폼화는 영광스러운 정치적 성과일 뿐 비용 문제를 효과적으로 해결하지 못하기 때문입니다. 자동화의 가장 높은 형태는 분명 지능적인 시스템이지만, 저자의 관점에서 볼 때 아마도 모든 사람들이 공상 과학 영화를 너무 많이 봤을 것입니다. 이는 과학적인 방법을 사용하여 소프트웨어의 이점을 극대화하려는 소프트웨어 엔지니어링의 목적을 희석시켰습니다. 하지만 이는 확실히 고도로 지능적인 자가 치유 시스템은 아닙니다. 저자의 견해에 따르면, 이 인공지능 시스템은 노키아 휴대폰과 애플 휴대폰을 비교하는 것처럼 소프트웨어 엔지니어링의 또 다른 차원이다. 인공지능 시스템으로 대체되는 것이 아니라. 아마도 언젠가는 SRE가 직접 은퇴하고 로봇이 전체 운영 및 유지 관리 시스템을 대체하게 되지만, SRE는 결국 기술 역사에 깊은 흔적을 남기게 될 것입니다.

위 내용은 SRE에 자동화된 진화 적용의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!