Data Science Lab

[Prometheus] Prometheus Thanos 아키텍처 살펴보기

l  Prometheous with Thanos

Thanos(타노스)는 CNCF(https://www.cncf.io/)의 인큐베이팅 프로젝트로, 프로메테우스의 확장성과 내구성을 향상시키기 위한 오픈소스 프로젝트이다.

l  Prometheus 확장 및 내구성을 위한 다양한 구성 방법 : https://sqlmvp.tistory.com/1521

Thanos는 Prometheus 2.0 스토리지 형식을 활용하여 빠른 쿼리 대기 시간을 유지하면서 모든 개체 스토리지에 메트릭 데이터를 효율적으로 저장한다. 또한 운영중인 프로메테우스 서버의 데이터를 통합 저장 및 외부 저장소에 데이터를 저장할 수 있기 때문에 보관 기간에 제한이 없고, 단일 쿼리로 전체 프로메테우스 서버의 데이터를 쿼리 할 수 있다. 장점을 크게 정리하면 아래와 같이 정리할 수 있다.

l  Long-term Storage : 원격 스토리지에 데이터를 안정적으로 저장하여 장기적인 데이터 보존을 가능

l  Global Query : 여러 원격 스토리지에서 데이터를 통합하여 조회할 수 있는 Global Query 기능을 제공하여 분산된 데이터에 대해 단일 쿼리를 실행할 수 있어 데이터 분석과 모니터링에 유용

l  HA(고가용성) : 원격 스토리지에 데이터를 복제하여 프로메테우스 서버 중 하나가 장애가 발생하더라도 데이터의 고가용성을 보장

타노스는 Sidecar, Query Gateway, Store Gateway, Compactor, Ruler, Receiver라는 6개의 컴포넌트로 이루어져 있다.  

l   Thanos Sidecar

ü  Prometheus와 함께 하나의 POD로 배포되어 기존 프로메테우스 서버와 통합

ü  Prometheus 데이터를 Object Storage 버킷에 백업하고 다른 Thanos 구성 요소가 gRPC API를 통해 Sidecar가 연결된 Prometheus 인스턴스에 액세스

ü  2시간마다 프로메테우스 메트릭을 객체 스토리지로 보냄

ü  사이드카는 Prometheus 끝점을 사용. --web.enable-lifecycle 플래그로 활성화

l   Thanos Query Gateway

ü  PromQL을 처리하는 부분으로 필요한 Prometheus의 sidecar와 연결

ü  질의를 Store (Store API), Sidecar등으로 전달하고 수집

ü  타노스의 전역 쿼리 계층(Global query layer)을 사용하여 모든 프로메테우스 인스턴스에 대해 PromQL를 사용하여 한번에 조회가능

ü  쿼리 구성 요소는 상태 비저장이며 수평 확장이 가능하며 여러 복제본과 함께 배포 가능

ü  사이드카에 연결되면 주어진 PromQL 쿼리를 위해 어떤 프로메테우스 서버에 접속해야 하는지 자동으로 감지

ü  단일 Thanos 쿼리 엔드 포인트에서 여러 메트릭 백엔드를 집계하고 중복 제거하는 기능을 제공

l   Thanos Store Gateway

ü  Store와 같은 개념이며, API Gateway 역할을 하며 오브젝트 스토리지에 접근하는 모든 작업은 Store API를 사용

ü  Query, Receive, Ruler 등에 존재

ü  사이드카와 동일한 gRPC 데이터 API로 구성되어 있지만 개체 저장소 버킷에서 찾을 수 있는 데이터로 백업

ü  스토어 게이트웨이는 오브젝트 스토리지 데이터에 대한 기본 정보를 캐싱 하기위해 소량의 디스크 공간을 차지 (타노스 쿼리 저장소 역할)

l   Thanos Compactor

ü  오브젝트 스토리지에 저장된 블록 데이터를 압축하여 저장공간 최적화 작업 진행

ü  개체 저장소를 간단히 스캔하고 필요한 경우 압축을 처리

ü  동시에 쿼리 속도를 높이기 위해 다운 샘플링된 데이터 복세본을 만드는 역할 수행

ü  주기적 배치 작업으로 실행하거나 데이터를 빨리 압축하기 위해 상시 실행 상태로 둘 수 있음

ü  데이터 처리를 위해 100GB ~ 300GB의 로컬 디스크 공간을 제공하는 것이 좋음  

ü  동시성이 보장되지 않으므로 전체 클러스터에서 싱글톤 형식으로 배포하고 버킷에서 데이터를 수동으로 수정할 때 실행하면 안됨

l   Thanos Ruler

ü  타노스 사이드카가 적용된 프로메테우스의 보존기간이 충분하지 않거나 전체 보기가 필요한 알림 또는 규칙 구성

ü  Thanos 쿼리 구성 요소에 연결하고 Prometheus Alert 및 Record 규칙을 평가

ü  Prometheus Alert Manager를 사용하여 Alert를 트리거 할 수 있음

l   Thanos Receiver

ü  프로메테우스 서버에서 remote_write를 통해 메트릭 데이터 수신할 때 사용

ü  기본 2시간 단위로 TSDB 블록을 만들어 오브젝트 스토리지에 저장

위 아키텍처를 살펴보고 요악하면 다음과 같은 활용을 구상해 볼 수 있다.

l   다수의 프로메테우스 서버를 Global Query view기능을 통해 하나의 인터페이스로 조회 및 활용

l   Global Query view, 메트릭 duplication 기능으로 프로메테우스 서버가 장애나더라도 서비스 단절이나 데이터 손실 방지

l   외부 저장소를 활용할 수 있으므로 데이터 크기에 따른 스토리지 성능 하락에 대비할 수 있고, 메트릭 데이터를 영구 보관할 수 있으므로 다양하게 활용 가능

[참고자료]

l   Thanos공식 문서 : https://thanos.io/v0.6/thanos/getting-started.md/

l   Multi-Cluster Monitoring with Thanos : https://particule.io/en/blog/thanos-monitoring/

2023-06-29 / Sungwook Kang / https://sungwookkang.com

프로메테우스, Prometheus, 모니터링 시스템, Grafana, 그라파나, DevOps, 데브옵스, Kubernetes, 쿠버네티스, 타노스, Thanos, CNCF

[Prometheus] Prometheus 확장 및 내구성을 위한 다양한 구성 방법들

l  Prometheous with Thanos

Prometheus(프로메테우스) 모니터링 시스템은 오픈 소스 기반의 모니터링 시스템으로 Kubernetes(쿠버네티스) 활성화 함께 많이 사용되고 있다.  프로메테우스는 구조가 간단하며, 운영이 쉽고 강력한 쿼리 기능을 가지고 있다. 간단한 텍스트 형식으로 메트릭 데이터를 쉽게 익스포트 할 수 있으며, key-value 형식의 데이터 모델을 사용한다. 수집된 데이터는 Grafana(그라파나)를 통해 시각화를 제공한다.

l  Prometheus 구조 및 개념 : https://sqlmvp.tistory.com/1520

프로메테우스의 가장 큰 약점은 확장성과 가용성이다. 프로메테우스는 클러스터가 지원되지 않는 독립형 서비스로, 프로메테우스 서버 장애시 메트릭을 수집할 수 없다는 것이다. 프로메테우스 서버의 장애시간 또는 재설정 등으로 서버 또는 서비스가 재시작 될 동안 타켓에 대한 모니터링을 할 수 없다면 이는 서비스를 운영하는데 매우 큰 리스크이다.  이러한 문제를 해결하기 위해 여러가지 프로메테우스 서버 구성에 대한 아키텍처를 생각해 볼 수 있다.

[프로메테우스N 구성으로 타켓 서버 중복 모니터링]

두 대이상의 프로메테우스 서버를 구성하여, 각 프로메테우스 서버에서 타겟 서버를 교차해서 메트릭을 수집하는 방식이다.

이러한 방식으로 구성할 경우 관리 해야하는 프로메테우스 서버도 증가하지만, 모니터링 대상이 되는 타겟 서버 입장에서도 여러 프로메테우스 서버로부터 요청되는 메트릭 데이터를 수집 및 전달하기 위해 오버헤드가 발생한다. 또한 프로메테우스로 수집된 데이터를 분석할 때에도, 특정 시점에 장애가 번갈아 발생시, 데이터가 한쪽에만 있게 되므로 중앙에서 한번에 분석하기 불편한 단점이 있다.

[프로메테우스 Federation 구성]

프로메테우스 서버를 여러 대 구성하고, 프로메테우스 서버가 다른 프로메테우스 서버로 요청하여 데이터를 수집할 수 있다.

l  Hierarchical Federation 구성은 프로메테우스 서버 사이에 계층을 두고 Tree 형태로 Federation을 구성하는 방법이다. 부모 프로메테우스는 자식 프로메테우스들의 통합 메트릭 제공 및 통합 메트릭을 기반으로 알람을 제공하는 용도로 사용할 수 있다.

l  Cross-service Federation 구성은 동일 레벨의 프로메테우스 서버사이를 Federation으로 구성하는 방법이다.

Federation으로 구성할 경우, 각 프로메테우스 서버는 타겟 서버로부터 일정 주기로 데이터를 수집하고 저장하고, 부모(중앙) 프로메테우스 서버는 각 프로메테우스 서버로부터 저장된 데이터를 별도의 주기로 수집할 수 있어, 데이터양이 많을 때, 평균값이나 해상도 등을 조정할 수 있다. 예를들면 각 프로메테우스 서버는 10초 단위로 수집하고, 중앙 프로메테우스는 1 분 단위로 하위 프로메테우스 서버로 요청하여 평균값 등을 이용할 수 있다. 하지만 각 프로메테우스 서버 장애 시 데이터 유실, 데이터 증가로 인한 중앙 프로메테우스 서버의 오버헤드 증가 문제가 있으므로 일정 규모 이상에서는 적용하기 힘든 부분이 있다.

[프로메테우스 Thanos 구성]

Thanos는 프로메테우스의 확장성과 내구성을 향상 시키기 위한 오픈소스 프로젝트로, 프로메테우스의 메트릭 데이터를 분산된 원격 스토리지에 저장하고 조회할 수 있는 기능을 제공한다. 아래 그림에서 서드파티 스토리지로 데이터를 저장하기 위한 Adapter 역할이 Thanos의 기능이다.

l   Thanos를 사용하여 구성 할 경우 아래와 같은 장점이 있다.

l   Long-term Storage: 원격 스토리지에 데이터를 안정적으로 저장하여 장기적인 데이터 보존을 가능

l   Global Query: 여러 원격 스토리지에서 데이터를 통합하여 조회할 수 있는 Global Query 기능을 제공하여 분산된 데이터에 대해 단일 쿼리를 실행할 수 있어 데이터 분석과 모니터링에 유용

l   HA(고가용성): 원격 스토리지에 데이터를 복제하여 프로메테우스 서버 중 하나가 장애가 발생하더라도 데이터의 고가용성을 보장

프로메테우스 Thanos 구성으로 데이터를 수집하여 S3에 저장하는 구성하는 구조를 만든다면 아래와 같은 형식으로 아키텍처를 디자인 할 수 있다.

1.          Prometheus용 Thanos 사이드카를 활성화

2.          Sidecar와 대화할 수 있는 기능이 있는 Thanos Querier를 배포

3.          Thanos Sidecar가 S3 버킷에 Prometheus 메트릭을 업로드할 수 있는지 확인

4.          Thanos Store를 배포하여 장기 스토리지(이 경우 S3 버킷)에 저장된 메트릭 데이터를 검색

5.          데이터 압축 및 다운 샘플링을 위해 Thanos Compactor를 설정

다양한 구성으로 프로메테우스의 단점인 확장 및 내구성을 보완하는 방법에 대해서 살펴보았다. 여러 방식이 있겠지만 현재 대규모 서비스에서는 Thanos 구성이 가장 많이 사용되는 듯 하다. Thanos의 아키텍처 및 자세한 내용은 다른 포스트에서 다뤄볼 예정이다. 모니터링을 구성하는데 있어서 정답은 없다. 항상 우리가 가진 리소스 및 환경에서 가장 최선의 방법을 잘 찾는 것이 중요할 듯 하다.

참고자료 :

l   https://wikitech.wikimedia.org/wiki/File:Prometheus_federation.png

l   https://prometheus.io/docs/prometheus/latest/federation/

l   https://www.robustperception.io/federation-what-is-it-good-for/

l   https://aws.amazon.com/blogs/opensource/improving-ha-and-long-term-storage-for-prometheus-using-thanos-on-eks-with-s3/

l   https://thanos.io/v0.6/thanos/getting-started.md/

l   https://particule.io/en/blog/thanos-monitoring/

2023-06-28 / Sungwook Kang / https://sungwookkang.com

프로메테우스, Prometheus, 모니터링 시스템, Grafana, 그라파나, DevOps, 데브옵스, Kubernetes, 쿠버네티스

[Prometheus] Prometheus 구조 및 개념

l  Prometheous

Prometheus(프로메테우스) 모니터링 시스템은 오픈 소스 기반의 모니터링 시스템으로 Kubernetes(쿠버네티스) 활성화 함께 많이 사용되고 있다. 물론 쿠버네티스 환경 외에도 일반적인 온프레미스 환경에서도 사용이 가능하여 많은 인기를 끌고 있다.  현재 CNCF(Cloud Native Computing Foundation)에 소속되어 있다.

프로메테우스는 구조가 간단하며, 운영이 쉽고 강력한 쿼리 기능을 가지고 있다. 간단한 텍스트 형식으로 메트릭 데이터를 쉽게 익스포트 할 수 있으며, key-value 형식의 데이터 모델을 사용한다. 수집된 데이터는 Grafana(그라파나)를 통해 시각화를 제공한다.

프로메테우스는 순전히 숫자로 된 시계열을 기록하는 데 적합하다. 기계 중심 모니터링과 고도로 동적인 서비스 지향 아키텍처 모니터링 모두에 적합하다. 프로메테우스는 중단 중에 신속하게 문제를 진단할 수 있도록 하는 시스템으로서 안정성을 위해 설계되어있으며, 각 프로메테우스 서버는 독립형으로 동작하며, 네트워크 스토리지 또는 기타 원격 서비스에 의존하지 않는다.

대부분의 모니터링 시스템은 타켓 서버(모니터링 대상 서버)에 에이전트를 설치하여 중앙의 모니터링 수집 서버로 push(푸시) 하는 방식인데, 프로메테우스는 pull(풀) 방식을 사용하여 데이터를 수집한다. 즉 모니터링 대상 서버에 exporter(익스포터)라는 에이전트가 실행되어 있으면, 주기적으로 에이전트에 접속하여 데이터를 가져오는 방식이다.

l  Jobs / Exporter : 프로메테우스가 모니터링 데이터를 가져갈 수 있도록 타겟 서버에 설치되는 에이전트 이다. 서버 상태를 나타내는 Node exporter, DB의 상태를 나타내는 SQL Exporter 등 다양한 커스텀 익스포터들이 개발되어 사용되고 있다. 익스포터 자체는 특별한 기능을 수행하지 않는다. 프로메테우스의 요청이 있을 때 그 시점에 메트릭을 수집하여 http get 방식으로 리턴한다. 히스토리를 저장하지 않기 때문에 시점의 값만 알 수 있다.

l  Pushgateway : Pushgateway는보안상의 이유로 프로메테우스가 직접 익스포터에 연결 할 수 없을 때, Proxy Forwarding을 사용하여 메트릭 데이터를 수집할 수 있도록 해주는 서비스이다. Application 이 pushgateway 에 메트릭 데이터를 푸쉬하면, 프로메테우스 서버가 pushgateway 에 접근해 메트릭 데이터를 풀 하는 방식으로 동작한다.

l  Alertmanager: Alertmanagr는 메트릭에 대한 특정 룰을 설정하고 그 규칙을 위반하는 사항에 대해 알람을 전송하는 역할을 한다. 예를들면 “CPU 사용률이 50% 이상일때 알람을 보낸다.” 라고 룰을 설정하면, 수집된 CPU 메트릭의 값이 50 이상일때 알람을 발송한다.

l  Service discovery : 프로메테우스는 기본적으로 풀 방식을 사용하여 모니터링을 하기 때문에 모니터링 대상 서버의 목록을 유지하고 있어야 한다. 쿠버네티스 환경처럼 오토스케일이 발생할 경우, 타겟 서버의 IP가 가변적이어서 수집할 서버의 목록을 확인할 수 없는 경우가 많다. 이런 경우 모니터링 대상 목록을 관리하기 위해 서비스 디스커버리를 사용하여 유지한다.

l  Retrieval : 익스포터로 부터 주기적으로 메트릭을 수집하는 모듈이며, 서비스 디스커버리 시스템으로 부터 모니터링 대상 목록을 받아오는 역할도 수행하는 컴포넌트이다.

l  HDD/SDD : 수집된 데이터는 프로메테우스 서버의 로컬 메모리와 디스크에 저장된다. 단순하고 사용이 쉬운 방면, 별도의 데이터베이스가 없으므로 확장이 불가능하다.

l  Data visualization : 저장된 메트릭은 PromQL 쿼리 언어를 사용하여 조회가 가능하다. 또한 외부 API나 프로메테우스 웹콘솔을 사용하여 visualization 을 구성할 수 있다.

프로메테우스 서버는 독립적인 구조로 운영되기 때문에, 많은 수의 모니터링 서버에서 대량의 메트릭을 수집할 때 프로메테우스 서버의 시스템 리소스가 부족할 경우 확장이 불가능한 구조로 되어 있다. 또한 프로메테우스 서버가 다운되거나 설정 변경으로 인한 재시작시 메트릭이 저장되지 않고 유실되는 문제가 있다. 이러한 문제를 수정하기 위해 프로메테우스 서버를 다양한 형태로 구성 및 운영하기 위한 노하우가 필요 하다. 이 부분은 다른 포스트에서 다루어 본다.

참고자료 :

https://prometheus.io/docs/introduction/overview/

2023-06-28 / Sungwook Kang / https://sungwookkang.com

프로메테우스, Prometheus, 모니터링 시스템, Grafana, 그라파나, DevOps, 데브옵스, Kubernetes, 쿠버네티스

SRE (Site Reliability Engineering) 역할

SRE(Site Reliability Engineering)은 조직이 해당 시스템, 서비스 및 제품에서 적절한 수준의 안정성을 달성하도록 지원하는 엔지니어링 분야로,  실패 비용을 줄임으로써, 신속하게 올바른 방향으로 이동할 수 있도록 지원한다. 이 과정에서 SRE는 자동화, 수치화, 프로세스화를 진행한다. 특히 SRE 관점은 “근본적인 문제는 소프트웨어의 문제”라고 정의하고 접근한다. SRE가 하는 일은 크게 5가지 정도로 나누어 볼 수 있다.

[Metric & Monitoring]

모니터링 지표를 정의하고, 정의된 지표를 모니터링 시스템으로 구성한다. 인사이트를 통해 시스템이 안정적인 상황과 또는 장애가 나는 지표는 무엇인지, 왜인지? 그리고 이러한 지표를 어떻게 개선할 수 있는지를 고민한다.기본적으로 SRE에서 가장 중요한 부분은 모든것을 데이타화하고, 의사결정을 데이타를 기반으로 한다는 것이다.

[Capacity Planning]

시스템을 운영하는데 필요한 하드웨어 리소스(서버, CPU,메모리,디스크,네트워크 등)을 확보하는 작업을 진행한다. 수집된 데이터를 통해 서비스 안정성에 필요한 하드웨어를 미리 예측하는 것이다. SRE 엔지니어는 자원 활용의 효율성 측면에서 소프트웨어의 성능을 그리고 안정성 측면에서 소프트웨어의 안정성을 함께 볼 수 있어야 한다.

[Change Management]

대부분의 시스템 장애의 원인은 대략 70%가 시스템에 변경을 주는 경우에 발생한다. SRE는 점진적인 배포와 변경을 관리한다.배포 또는 장애시 빠르고 정확하게 해당 문제를 찾아낼 수 있도록 해야하며 마지막으로 문제가 발생하였을때 빠르게 롤백할 수 있도록 해야한다.

[Emergency Response]

일반적으로 장애 복구 단계에서 사람이 직접 매뉴얼로 복구를 하게 되면 장애 복구 시간이 더 많이 소요된다. 사람이 컨트롤을 하되 가급적이면 각 단계는 자동화 되는게 좋으며, 사람이 해야 하는 일은 되도록이면 메뉴얼화 되어 있는 것이 좋다. SRE는 자동화 뿐만아니라 메뉴얼, 프로세스를 함께 제공한다.

[Culture]

운영에 필요한 작업뿐만 아니라 SRE 문화를 전반적으로 만들고 지켜나가는 작업을 진행한다.  데이타에 기반한 합리적인 의사결정과 서로 비난하지 않고 장애 원인을 분석하고 이를 예방하는 포스트모템 문화, 그리고 책임을 나눠가지는 문화를 장려하고 선순환 구조를 만들 수 있도록 해야한다.

[참고자료]

·       IO116-Improving Reliability with Error Budgets, Metrics, and Tracing in Stackdriver : https://drive.google.com/file/d/1iOMaYIwlUBiGoG2mf8MFzl3EHy5xGJpq/view

·       Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템) : https://www.slideshare.net/deview/216sresearchreliabilityengineering

·       네이버 검색의 SRE 시스템 : https://d2.naver.com/helloworld/2047663

·       SRE(사이트 안정성 엔지니어링) 소개 : https://docs.microsoft.com/ko-kr/learn/modules/intro-to-site-reliability-engineering/

2020-05-13 / Sungwook Kang / http://sungwookkang.com

SRE, Site Reliability Engineering, DevOps, 사이트안정성엔지니어링, 사이트신뢰성엔지니어링, 시스템운영, SiteReliability, 서비스운영, 모니터링자동화, 시스템운영자동화

SRE (Site Reliability Engineering)

사이트 안정성 엔지니어링(SRE, site Reliability Engineering)은 조직이 해당 시스템, 서비스 및 제품에서 “적절한” 수준의 안정성을 “지속적”으로 달성하도록 지원하는 엔지니어링 분야이다. 여기서 말하는 “적절한” 수준의 안정성은 무엇일까? IT 시스템이 발달할 수록, 더 나은 안정성을 추구 할수록, 안정성을 높이는 데 필요한 노력과 리소스(및 비용)는 빠른 속도로 증가하고 있다. 이를 다르게 표현한다면, 불필요한 안정성 추구는 시간과 돈의 낭비가 발생한다는 것이다. 결론적으로 안정성 수준은 비즈니스 수요에 적절하고 실용적이어야 하는 수준에서 트레이드오프를 해야한다. 예를 들어, 고객이 100% 안정적이지 않은 네트워크(시간의 90% 가동한다고 가정)를 통해 연결하는 경우 노력과 비용(돈)을 투자하여 서비스가 95% 안정적으로 되도록 하는 것은, 정의상 시간과 돈을 낭비하는것과 같다. “지속적인 달성”은  이러한 모든 상황에서 사용자가 해야 할 역할을 의미한다. SRE는 지속 가능한 운영방식을 만들고, 신뢰할 수 있는 시스템을 만든다. 개발자(시스템 사용자)는 서비스, 제품을 만든다. 시간이 지나도 지속되는 운영방식을 구현하여, 사람들(개발자, 사용자)들이 업무에 최선을 다할수 있도록 환경을 제공하는것이 정말 중요하다.

SRE의 역사는 2013년 Google에서 Benjamin Treynor이 7명의 소프트웨어 엔지니어로 구성된 팀을 이끌면서 프로덕션의 운영환경을 개선하기 위한 프로젝트를 진행하면서 시작되었다. 이 팀의 목표는 변화를 수용하면서, 동시에 우수한 품질을 최종 사용자에게 제공하는것이다. 구글은 현재 약 1500명 이상의 엔지니어들이 SRE 업무를 수행하고 있다. SRE 프로세스는 이제 Microsoft, Apple, Amazon, Facebook, Twitter 같은 대기업에서도 도입하여 사용하고 있다.

SRE 엔지니어는 “운영(OPS)” 관련된 작업을 수행하는데 최대 50%의 시간을 소비한다. SRE가 관리하는 소프트웨어 시스템은 고도로 자동화 되어 있으며, 자가치유 기능을 가지고 있어야 한다. 그래서 일반적으로 시스템의 자동화 작업에 50%의 시간을 소비하며 나머지 50%를 운영에 소비한다. 이상적인 SRE 후보자는 시스템 관려 경험을 가진 소프트웨어 엔지니어 및 코딩 및 자동화에 숙련된 시스템 관리자들이다.

기존의 DevOps와 SRE는 어떻게 다를까? 모니터링을 통한 문제 식별, 자동화라는 목표는 두 조직 모두 동일하지만, DevOps가 개발쪽에 조금 더 편향되어 있다면, SRE는 운영쪽에 조금 더 편향되어 있다.

DevOps는 개발과 운영조직 각각의 사일로 현상을(내부 이익만 추구하는 부서간 이기주의 현상) 해체하기 위한 문화적인 움직임으로, 하나의 문화로 인식된다. 그래서 역할을 정의할때도, “저는 DevOps를 하는 운영자, 또는 개발자 입니다.”라고 표현한다.

SRE는 안정성을 위한 엔지니어링으로 DevOps의 운영적인 부분을 보완한다. 그래서 SRE는 문화라기보다는 하나의 역할이며, 표현할 때에도 “저는 SRE 입니다” 라는 식으로 규범으로 인식한다.

[참고자료]

·       IO116-Improving Reliability with Error Budgets, Metrics, and Tracing in Stackdriver : https://drive.google.com/file/d/1iOMaYIwlUBiGoG2mf8MFzl3EHy5xGJpq/view

·       Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템) : https://www.slideshare.net/deview/216sresearchreliabilityengineering

·       네이버 검색의 SRE 시스템 : https://d2.naver.com/helloworld/2047663

·       SRE(사이트 안정성 엔지니어링) 소개 : https://docs.microsoft.com/ko-kr/learn/modules/intro-to-site-reliability-engineering/

2020-05-10 / Sungwook Kang / http://sungwookkang.com

SRE, Site Reliability Engineering, DevOps, 사이트 안정성 엔지니어링