Education*
Devops
Architecture
F/B End
B.Chain
Basic
Others
CLOSE
Search For:
Search
BY TAGS
linux
HTTP
golang
flutter
java
fintech
개발환경
kubernetes
network
Docker
devops
database
tutorial
cli
분산시스템
www
블록체인
AWS
system admin
bigdata
보안
금융
msa
mysql
redis
Linux command
dns
javascript
CICD
VPC
FILESYSTEM
S3
NGINX
TCP/IP
ZOOKEEPER
NOSQL
IAC
CLOUD
TERRAFORM
logging
IT용어
Kafka
docker-compose
Dart
SRE의 개념과 DevOps와의 차이
Recommanded
Free
YOUTUBE Lecture:
<% selectedImage[1] %>
yundream
2023-06-06
2023-06-06
3207
사이트 신뢰성 엔지니어링(SRE)는 2003년 구글에서 시작되었다. 2016년 구글은 1,000 명 이상의 SRE 엔지니어를 고용했다. 오랜 역사를 자랑하고 있지만, 국내의 경우 상당히 늦은 2019년 정도부터 SRE 엔지니어에 대한 채용이 시작됐다. 그러면서 **DevOps** 업무와 어떤 차이가 있는지에 대한 논의가 함께 진행된다. DevOps 활동에 인프라와 서비스에 대한 확장성과 가용성을 확보하는 업무가 포함되어 있는데, **사이트 신뢰성** 과 겹치는 부분이 많기 때문이다. ## DevOps는 접근 방식이다 DevOps는 그 자체로는 툴이나 솔류션이 아니다. 개발과 운영 팀간의 협업과 커뮤니케이션을 강조하는 문화적이고 조직적인 **접근 방식**이다. 목표는 조직간 사일로를 허물고 프로세스를 능률화하여 높은 품질의 소프트웨어를 더 빠르게 제공하는 것을 목표로 한다. DevOps는 이처럼 포괄적인 문화 및 행동양식을 제안하고 있다. 이때 포괄하는 영역은 "개발"과 "운영"인데 한 마디로 제품의 개발과 출시 이후를 모두 포함하기 때문에, SRE 뿐만 아니라 DevSecOps와도 겹쳐 보이게 된다.  DevOps는 제품 디자인에서 개발, 테스트, 전개, 운영, 관리, 모니터링의 과정에서 개발팀과 운영팀의 경계를 허물어서 효과적으로 목표를 달성한다. 여기에서 목표는 "가치의 전달"로 이는, 고객의 가치를 사업 가치로 만들고 이 가치를 코드화해서 고객까지 전달하고 전달된 가치를 보호하는 것이다. 이를 위해서 DevOps에서는 개발팀과 운영팀간에 1. 목표의 공유 2. 기술셋의 공유 3. 일관된 도구의 사용 4. 기본 가치의 공유 를 위한 **방법론**을 찾아서 수행한다. ## What is SRE SRE는 SLO(Service Level Objectives) 및 오류 예산(error budget)를 측정하고 이를 충족하는데 중점을 둔다. * SLO: 허용 가능한 수준의 서비스 안정성을 정의 * 오류 예산: 특정 기간 발생할 수 있는 허용 가능한 중단 시간 또는 오류 수준을 정량화 결국 목표는 시스템 및 서비스의 가용성, 안정성을 보장하는 것이다. * Reliability as a Feature: SRE 이전에 **신뢰성**은 보통 비기능으로 간주했다. SRE에서는 신뢰성을 기능으로 간주한다. 안정성을 제품의 요구사항으로 취급하고 성능, 가동시간, 메트릭에 대한 목표 및 SLO를 설정한다. 측정 가능한 수치로 관리하는 것이다. * Automation: 신뢰성과 안정성을 확보하기 위한 방법으로 자동화를 강조한다. 인적 오류를 줄이고 효율성을 개선하고 더 빠른 사고대응 및 복구를 가능하게 한다. * 모니터링: 측정가능한 수치를 얻기 위해서 강력한 모니터링 시스템을 구현한다. * 사고대응: 사고대응 프로세스를 개발하여 사고를 신속하게 식별, 진단, 해결, 복구하여 사용자에게 미치는 영향을 최소화한다. * 근본원인 분석(Root Cause Analysis): SRE 팀은 사고의 근본원인을 이해하기 위해 철저한 분석을 수행한다. 이러한 분석을 통해서 개선이 필요한 영역을 식별하고 유사한 문제가 발생하지 않도록 예방조치를 취한다. * 용량 계획 및 성능 엔지니어링: 용량이 늘거나 줄어드는 상황에서 시스템 성능이 최적화되도록 계획을 세워서 각 용량 상황에서 최적의 성능 수준을 유지하도록 한다. * 협업과 커뮤니케이션: SRE 팀은 개발 팀, 운영 인력 및 기타 이해 관계자와 긴밀히 협력하여 협업을 촉진한다. 효과적인 커뮤니케이션은 성공적인 SRE 관행에 필수적이다. ## SRE Concept  **SLO**는 프로덕트 오너, CTO 등과 합의한 고객에게 제공할 신뢰도의 목표 또는 범위 수준이다. 신뢰성 0%는 아무것도 작동하지 않는 것을 의미하며, 신뢰성 100%는 아무것도 망가지지 않는다는 것을 의미한다. 당연하지만 신뢰성 100%와 같은 유토피아는 존재하지 않기 때문에 우리는 신뢰성에 대한 허용 가능한 수준을 정의해야 한다. **SRE는 시스템(SYSTEM)의 서비스 수준**을 관리한다. 이 시스템은 유저서비스 시스템, 데이터시스템, 저장소 등 3개의 주요 컴포넌트로 구성되며, 이들 컴포넌트로부터 SLI(서비스 수준 지표)를 측정한다. **SLI**는 서비스의 수준을 정량적으로 평가하기 위해서 측정하는 핵심 요소들이다. 이들은 고객서비스 유형에 따라서 달라진다. 1. 이-커머스에서 상품 검색 서비스는 사용자 요청을 기반으로 검색 결과값을 고객에게 노출한다. 검색 결과의 정확도가 높다고 가정하면, 이 서비스에 대한 신뢰성 지표는 **가용성**, **요청 대기 시간**, **처리량** 이다. 쿠팡과 같은 이-커머스에서 상품 검색 서비스는 사용자가 가장 많이 사용하는 기능이기 때문에, 주어진 시간에 수천명의 사용자로부터 오는 수백만건의 요청을 빠르고(처리량 x 대기시간), 안전하게(가용성) 제공해야 한다. 2. 유튜브와 같은 비디오 업로드(데이터) 서비스는 사용자에게 파이프라인 구성요소를 제공한다. 비디오를 업로드하고 변환하고, 밝기 또는 색 보정을 하고 비디오 설명과 같은 메타데이터를 저장하고 마지막으로 공개 가능한 URL을 리턴한다. 이러한 종류의 서비스의 안정성 지표는 **End-To-End Latency와 대역폭(Throughput)** 이다. 동시에 많은 사용자가 파일을 업로드할 것이기 때문에 모든 사용자가 빠르게 파일을 업로드 할 수 있어야 한다. 3. DropBox와 같은 스토리지 서비스는 스토리지의 구성요소(디렉토리, 파일)을 노출한다. 이러한 종류의 서비스에서 주요 안정성 지표는 **가용성, 대기시간, 내구성**이다. 사용자는 필요할 때 파일에 액세스할 수 있어야하며, 가능한 빠르게 업로드 및 다운로드 할 수 있어야 한다. 또한 파일은 1개월, 1년, 10년이 지나도 손상없이 사용할 수 있어야 한다. **성공률(SUCESS RATIO)** 는 SLI를 추적하기 위한 직관적인 방식이다. 즉 전체 서비스 요청 중 얼마나 성공했는지로 SLI를 평가할 수 있다. 예를 들어 * 요청 기반 서비스에 대해서 99.9%의 SLO를 설정했다고 하면, 가용성 SLI는 1000개의 요청 중 999개를 성공해야 함을 의미한다. SRE 엔지니어는 이를 측정하기 위한 매트릭으로 HTTP Status Code를 수집할 수 있다. 200OK는 성공, 5xx는 실패를 의미할 것이다. * 스토리지 서비스의 경우 내구성은 파일에 대한 해시와 체크섬등으로 파일의 무결성을 확인하여 내구성을 평가할 수 있을 것이다. **오류 예산(ERROR BUDGET)** 은 데이터 기반 의사결정을 위한 핵심 개념이다. 오류 예산이 있기 때문에 "고객으로 부터 서비스가 엉망이라는 메일이 왔으니 수정해", "100% 무결한 서비스를 만들어라" 와 같은 기분에 기반한 의사결정을 막을 수 있다. 기본 공식은 *100 - SLO*로 계산된다. 예를 들어서 가용성이 99.9%라면 오류예산은 0.1%다. 즉 한달에 1,000만건의 요청이 발생했다면 서비스는 최대 10,000 건의 요청이 실패할 수 있다. 이 임계값이 초과했을 때, 장애를 줄이기 위한 정책, 시스템 개선에 대한 활동을 시작한다. "사건과 사고는 구별해야 한다" SLI 지표를 측정하기 위해서는 솔류션을 도입비용이 들어가며 품질을 높이기 위해서는 개발 혹은 인프라 비용이 들어간다. 이러한 모든 활동에는 cost(돈)가 들어간다. 프러덕트 오너는 비용, 시간, 품질 사이에서 절충을 해야 한다. ## DevOps와 SRE 이상에서 DevOps는 조직간 사일로를 제거하여 효과적인 커뮤니케이션을 이루기 위한 관행이며 SRE는 그러한 관행을 달성하기 위한 구체적인 방법론이라고 볼 수 있다. 애자일 관행을 실행하기 위한 방법론으로 스크럼, 칸반, 린 소프트웨어 개발, 익스트림 프로그래밍 등이 있는 것과 유사하다. 2009년 DevOps Day라는 이름의 첫번째 컨퍼런스가 벨기에 겐트에서 열렸으며, 대략 이때를 DevOps의 시작이라고 보고 있다. 아래는 구글 트랜드로 확인해본 DevOps에 대한 관심 변화 그래프다.  아래는 SRE에 대한 관심변화 그래프다.  DevOps, SRE 모두 2017년 정도 부터 제대로 관심을 받고 있다는 것을 알고 있다. 역사가 매우 짧다는 얘기다. 이런 이유로 DevOps와 SRE에 대해서는 사람들 마다 약간식 다르게 해석할 수 있음을 염두에 두고 생각을 해야 한다. "내"가 생각하는 DevOps, SRE의 관계는 아래와 같다. > DevOps는 문화이고 SRE는 DevOps 문화(관행)을 실현하기 위한 구체적인 방법이다. DevOps가 애자일이라면 SRE는 스크럼인 이런 관계로 나는 바라보고 있다. 따라서 나는 SRE는 어떤일을 하고 DevOps는 어떤일을 한다 이런 관점으로 두 개를 비교하지 않는다. 그냥 SRE가 어떤 영역을 구체화하려고 하는가 하는 관점에서 바라본다. ## DevOps와 SRE 조직 구성 나는 DevOps라는 포괄적인 역할 중, 신뢰성 부분을 구체화한게 SRE라고 보는 관점에서 상황에 따른 조직의 구성을 제안한다. **조직 규모와 복잡성:** 조직의 규모와 복잡성에 따라서 DevOps와 SRE를 분리하거나 통합한다. * 워크로드가 단순하고 작은 조직으로 운영될 때는 운영, SRE 업무를 동일한 팀이 수행할 수 있다. * 워크로드가 복잡하고 큰 조직으로 운영되는 환경에서는 DevOps와 SRE를 분리하여 각 팀이 명확한 역할과 책임을 가지게 한다. **업무 툭성**: * DevOps 팀은 개발과 운영 간의 협럭, 지속적인 통합과 배포(CICD), 자동화 등을 담당할 수 있다. * SRE 팀은 사고관리체계, 용량계획, 측정가능한 서비스 신뢰성등에 전문화 될 수 있다. **프로젝트에 따라서**: * 하나의 팀으로 유지를 하다가 필요에 따라서 DevOps와 SRE를 분리하거나 통합할 수 있다. 내 생각에 DevOps 조직으로 시작하고, 팀원이 6명 이상으로 늘어나야 될 정도로 워크로드가 커지고 복잡해지기 시작하면 DevOps와 SRE를 분리를 고민하고 이를 위한 계획을 세워야 한다고 보고 있다. 단일 팀으로 10명이면 이미 한 팀으로 운영하기에는 비효율적이 되므로 그전에 SRE에 대한 업무 역할을 계획하여 채용 혹은 역할 조정을 위한 리서치 및 교육을 진행해야 한다. DevOps와 SRE는 철학을 서로 공유하기 때문에 DevOps가 성숙되면 자연스럽게 SRE 업무를 수행하게 되며 필요에 따라서 자유롭게 통합하거나 분리할 수 있다. ## DevOps와 SRE를 위한 툴 DevOps와 SRE를 위한 툴들이다. 분류를 해놓긴 했으나 앞서 언급했듯이, DevOps와 SRE는 많은 부분을 공유하며 환경에 따라서 세부적인 역할이 달라질 수 있으므로 참고만하자. 예를들어 보안과 관련된 부분들은 **DevSecOps**로 분리할 수도 있다. | 작업 | 툴 | SRE | DevOps | | --------------------------------------------------- | ---------------------------------------- | --- | ------ | | 운영체제 | Linux & 가상화 시스템 | YES | YES | | Cloud | AWS, GCP, Azure | YES | YES | | Containers | Docker | YES | YES | | Planning and Designing | Jira & Confluence ... | YES | YES | | Backend Programming Language | Python/Flask 등 경량 프레임워크 | | YES | | SCV | Git | YES | YES | | Code Analysis & Securing Code | SonarQube,OWASP, AppScan CodeSweep | | YES | | Build Management | Maven, Gradle | | YES | | Package Management | Paker & Artifactory | | YES | | Unit Testing & Acceptance Testing & Coverage | Junit, Selenium, Jacoco | | YES | | Securing App Runtime (DAST) | AppScan, Fortify Webinspect ... | | YES | | Configuration & Deployment Management | Ansible | YES | YES | | Container Orchestration | Kubernetes, Helm, ECS | YES | YES | | Infrastructure Coding | Terraform | YES | YES | | Service mesah Data Planes & Contrl Planes | Envoy & Istio | YES | | | Network configurations and Service Discovery | Consul | YES | | | Continuous Integration | Jenkins, Github Action | YES | YES | | Securing credentials | HashiCorp Vault, KMS, SSL & Certificates | YES | | | Infrastructure Monitoring Tool - 1 | Datadog | YES | | | Infrastructure Monitoring Tool - 2 | Prometheus with Grafana | YES | YES | | Log Monitoring Tool - 1 | Splunk | YES | YES | | Log Monitoring Tool - 2 | ELK | YES | | | Performance & Run Monitoring | NewRelic | YES | YES | | Emergency Response & Alerting & Chat & Notification | SMTP, SES, SNS, Pagerduty, Slack | YES | | | Security Through Logs 1 | Splunk SIEM | | YES | | Cloud Security service & Practices | Cloud Security with Cloud Service | | YES | ## 정리 다음 글에서는 AWS 클라우드를 기반으로 SRE에 대한 모범사례를 분석할 계획입니다. ## 참고 * [Differnece between DevOps, DevSecOps and SRE](https://www.ismiletechnologies.com/devops/difference-between-devops-devsecops-and-sre/) * [DevOps vs DevSecOps Vs SRE?](https://www.devopsschool.com/blog/what-should-i-learn-for-devops-vs-devsecops-vs-sre/) * [SRE Concept map](https://www.linkedin.com/pulse/sre-concept-map-orlando-garcia/)
Recent Posts
Vertex Gemini 기반 AI 에이전트 개발 05. 첫 번째 LLM 애플리케이션 개발
LLama-3.2-Vision 테스트
Vertex Gemini 기반 AI 에이전트 개발 04. 프롬프트 엔지니어링
Vertex Gemini 기반 AI 에이전트 개발 03. Vertex AI Gemini 둘러보기
Vertex Gemini 기반 AI 에이전트 개발 02. 생성 AI에 대해서
Vertex Gemini 기반 AI 에이전트 개발 01. 소개
Vertex Gemini 기반 AI 에이전트 개발-소개
생성 AI 모델 Flux.1 설치 및 사용
GPT를 이용한 Reranker 테스트
5분만에 만들어보는 Streamlit 챗봇
Archive Posts
Tags
cloud
Copyrights © -
Joinc
, All Rights Reserved.
Inherited From -
Yundream
Rebranded By -
Joonphil
Recent Posts
Archive Posts
Tags