TIL 36 - DevOps / SRE

DevOps란?

애플리케이션 개발의 품질과 속도를 개선하고 신규 또는 수정된 소프트웨어 기능이나 제품의 릴리즈 주기 단축을 장려하는 새로운 철학이자 프레임워크이다.

사례는 애플리케이션 개발팀(Dev)과 해당 IT 운영 팀(Ops)팀 간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성을 장려한다.

'Dev'와 'Ops'간의 이러한 긴밀한 관계는 초기 소프트웨어 계획부터 코딩, 구축, 테스트 및 릴리즈 단계와 구축, 운영 및 지속적인 모니터링에 이르는 DevOps 라이프사이클의 모든 단계에 걸쳐 계속 된다. 이러한 관계는 추가 개선, 개발, 테스트 및 구축에 대한 지속적인 고객 피드백 루프를 추진하는 원동력이 되고 이러한 노력이 제공하는 결과 중 하나는 필요한 기능 변경 또는 추가 기능을 더 빠르고 지속적으로 릴리즈할 수 있다는 것이다.

DevOps 목표를 문화, 자동화, 측정 및 공유(CAMS)의 네가지 범주로 그룹화하는데 DevOps 툴을 사용하여 이 모든 영역을 지원할 수 있습니다. 이러한 툴을 사용하면 개발 및 운영 워크플로우의 효율성 및 협업 기능을 개선하여 통합, 개발, 테스트, 구축 또는 모니터링과 관련된 기존의 시간 소모적인 수동 또는 정적 작업을 자동화 할 수 있다.

또한 기본 인프라는 소프트웨어를 처음 개발 및 테스트하고 운영 환경에 출시 할 때까지 지속적인 성능, 기용성 및 안정성을 바탕으로 DevOps를 지원한다.

DevOps 작동방식

개발팀과 운영팀이 더 이상 '사일로' 묶여 있지 않습니다. 때로는 이 두팀이 단일팀으로 병합되어 엔지니어가 개발에서 테스트, 배포, 운영에 이르기까지 전체 애플리케이션 수명 주기에 걸쳐 작업하고 단일 기능에 한정되지 않은 광범위한 기술을 개발한다.

일부 DevOps 모델에서 품질 보증팀과 보안팀 또한 애플리케이션 수명 주기에 걸쳐 개발 및 운영과 좀 더 긴밀하게 통합하게 된다.

DevOps 방식을 사용하여 속도가 느리고 수동으로 수행되던 프로세스를 자동화한다. 또한, 애플리케이션을 안정적으로 빠르게 운영하고 개선하는데 도움이 되는 기술 스택과 도구를 사용한다. 덕분에 엔지니어는 다른 팀 도움이 필요했을 코드 배포 또는 인프라 프로비저닝과 같이 작업을 독립적으로 수행할 수 있으며, 팀의 작업속도가 더욱 빨라진다.

DevOps 방법

조직에서 개발 및 제품 출시의 속도와 향상을 위해 사용할 수 있는 몇 가지 일반적인 DevOps 방법이 있는데 소프트웨어 개발 방법론 및 모범 사례의 형식을 사용한다. 가장 많이 사용되는 방법은 Scrum, Kanban, Agile이다.

• Scrum : 개발 및 QA프로젝트를 가속하기 위한 팀원의 협력 방법을 정의, 스크럼 사례에는 주요 워크플로 및 특정 용어(Sprint, 시간 상자, 일별 스크럼[회의])와 전담 역할(스크럼 마스터, 제품 소유자)이 포함된다.

• Kanban : 칸반은 진행 중인 소프트웨어 프로젝트 작업 상태(WIP)를 칸반 보드로 추적할 것을 지시합니다.

• Agile : 초기 애자일 소프트웨어 개발 방법이 여전히 DevOps사례 및 툴에 영향을 미치고 있다. 스크럼 및 칸반을 비롯한 많은 DevOps 방법에는 애자일 프로그래밍 요소가 포함되어 있습다. 일부 애자일 사례는 변화하는 요구 및 요구사항에 빠르게 대응하고 요구사항을 사용자 사례로 문서화하며 매일 아침 회의를 수행하고 지속적은 고객 피드백을 포함하는 것과 관련된다. 또한 애자일은 기존의 긴 '폭포수' 개발 방법 대신 짧은 소프트웨어 개발 라이프사이클을 사용할 것을 지시한다.

DevOps의 이점

• 속도
• 신속한 제공
• 안정성
• 확장
• 협업 강화
• 보안

DevOps 툴체인

DevOps '툴체인'의 일부로 DevOps 친화적인 툴을 사용한다. 이러한 툴의 목표는 소프트웨어 전송 워크플로(또는 파이프라인)의 다양한 단게를 추가로 간소화하고, 단축하고, 자동화하는 것이다. 또한 이러한 툴 중 다수는 자동화, 협업 및 개발-운영 팀 간의 통합에 대한 핵심 DevOps 원칙을 손쉽게 준수할 수 있도록 한다.

DevOps 라이프사이클 단계에서 사용되는 툴의 예

• 계획 : 비즈니스 가치 및 요구사항을 정의하는데 도움이 된다. 샘플 툴로는 아렬진 문제를 추적하고 프로젝트 관리를 수행하는데 도움이 되는 Jira, Git이 있다.

• 코딩 : 소프트웨어 설계 및 소프트웨어 코드 생성이 포함된다. 샘플 툴로는 GitHub, GitLab, Bitbucket 또는 Stash가 있다.

• 구축 : 소프트웨어 빌드 및 버전을 관리하고 자동화된 툴을 사용하여 코드를 컴파일하고 패키징하여 향후 제품 릴리즈에 제공한다. 소스 코드 저장소 또는 패키즈 저장소를 사용합니다. 이러한 저장소는 제품 릴리즈에 필요한 '패키지' 인프라 역할도 한다. 샘플 툴로는 Docker, Ansuble, Puppet, Chef, Gradle, Maven 또는 JFrog Artifactory가 있다.

• 테스트 : 최적의 코드 품질을 보장하기 위해 지속적인 테스트(수동 또는 자동)를 수행한다. 샘플 툴로는 JUnit, Codeception, Selenium, Vagrant, TestNG 또는 BlazeMeter가 있다.

• 배포 : 제품 릴리즈를 운영 단계롤 관리, 조정, 예약 및 자동화하는데 도움이 되는 툴이 포함될 수 있다. 샘플 툴로는 Puppet, Chef, Ansible, Jenkins, Kubernetes, OpenShift, OpenStack, Docker 또는 Jira가 있다.

• 운영 : 운영 중인 소프트웨어를 관리한다. 샘플 툴로는 Anabilities, Puppet, PowerShell, Chef, Salt 또는 Otter가 있다.

• 모니터링 : 운영 환경의 특정 소프트웨어 릴리즈에서 발생하는 문제에 대한 정보를 식별하고 수집한다. 샘플 툴로는 New Relic, Datadog, Grafana, Wireshark, Splunk, Nagios 또는 Slack이 있다.

DevOps 사례

• 지속적인 개발 : DevOps 라이프사이클의 계획 및 코딩 단계에 걸쳐 적용

• 지속적인 테스트 : 애플리케이션 코드를 작성하거나 업데이트하는 동안 자동화되고 사전 예갹된 지속적인 코드테스트를 포함. 이러한 테스트를 수행하면 코드를 더 빠르게 운영 환경에 제공할 수 있다.

• 지속적인 통합(CI) : 구성 관리(CM)툴을 다른 테스트 및 개발 툴괗 함께 사용하여 개발 중인 코드의 운영 준비 상태를 추적. 테스트와 개발 간의 신속한 피드백을 통해 코드 문제를 신속하게 파악하고 해결하는 작업이 포함됨.

• 지속적인 제공 : 테스트 후 사전 운영 또는 스테이징 환경으로 코드 변경을 제공하는 작업을 자동화한다. 제공된 후에는 직원이 이러한 코드 변경을 운영 환경으로 승격할 수 있다.

• 지속적인 구축(CD) : 지속적엔 제공과 마찬가지로 이 사레는 신규 또는 변경된 코드를 운영 단계로 자동 릴리즈한다. 지속적인 구축을 수행하는 회사에서 코드 또는 기능 변경을 하루에 여러번 릴리즈 할 수 있다. Docker, Kubernetes 및 기타 컨테이너 기술을 사영하면 서로 다른 구축 플랫폼 및 환경에서 코드의 일관성을 유지하여 지속적인 구축 지원 가능 .

• 지속적인 모니터링 : 작동 중인 코드와 이를 지원하는 기본 인프라에 대한 지속적인 모티너링과 관련됨. 피드백 루프를 통해 버그 또는 문제를 보고한 후 다시 개발 단계로 되돌아간다.

• 코드형 인프라 : 다양한 DevOps 단계에서 소프트웨어 릴리즈에 필요한 인프라 프로비저닝을 자동화하는 데 사용될 수 있습니다. 개발자는 기존 개발 툴 내에서 인프라 "코드"를 추가합니다. 예를 들어 개발자는 Docker, Kubernetes 또는 OpenShift에서 필요에 따라 스토리지 볼륨을 생성할 수 있습니다. 또한 운영 팀은 이 사례를 통해 환경 구성을 모니터링하고, 변경 사항을 추적하며, 구성 롤백을 간소화할 수 있습니다.

---

SRE(사이트 신뢰성 엔지니어링)란?

site Reliability Engineering의 약자로 개발자가 셀프 서비스로 운영을 하려면 그 플랫폼이 자동화 되어 있어야한다. 애플리케이션을 빌드하고 유연하게 배포하고, 이를 모니터링할 수 있는 플랫폼이 필요한데, SRE의 역할은 이러한 플랫폼을 개발하고, 이 플랫폼 위에서 개발자들이 스스로 배포, 운영을 하는 것이 목표이다.

DevOps engineering? / Site Reliability Engineering(SRE)?

DevOps가 개발과 운영의 사일로(분단)현상을 해결하기 위한 방법론이자 하나의 조직문화에 대한 방향성이다. 그렇다면 SRE는 구글이 DevOps에 적용하기 위한 구체적인 실사례와 가이드로 생각하면 된다.
SRE는 크게 3가지 방향으로 개발자들이 속도에 무게를 두고 운영팀이 안정성에 무게를 둬서 발생하는 문제를 풀려고 한다.

• 1. 가용성에 대한 명확한 정의
• 2. 가용성 목표 정의
• 3. 장애 발생에 대한 계획

위 3가지 원칙에 따라서, 가용성을 측정을 위해서 어떤 지표를 사용할지를 명확히 정하고 두번째로는 그 지표에 어느 수준까지 허용을 할 것인지를 정해서 그에 따른 의사결정을 하는 구조이다.

SRE는 문화와 운영 프로세스 팀 구조 등 모든 개념을 포함한 포괄적인 개념이다.

SRE 팀은 기존에 운영 팀이 수동으로 하는 경우가 많았던 태스크를 받아 엔지니어 또는 운영 팀에 넘기고, 엔지니어 또는 운영 팀은 소프트웨어 및 자동화를 사용해 문제를 해결하고 프로덕션 시스템을 관리한다.

SRE는 확장 가능하고 신뢰성이 높은 소프트웨어 시스템을 생성할 때 유용한 방법이다. 코드를 통해 대규모 시스템을 관리할 수 있으므로 수천 대에서 수십만 대에 이르는 머신을 관리하는 시스템 관리자에게 더 큰 확장성과 지속가능성을 제공한다.

SRE를 활용하는 팀은 새 기능을 적시에 출시하고 사용자가 이 기능을 안정적으로 사용하도록 할 수 있다.

표준화 및 자동화는 SRE 모델에서 중요한 2가지 구성 요소입니다. 사이트 신뢰성 엔지니어는 운영 태스크를 개선하고 자동화할 방법을 끊임없이 모색해야 한다.

이를 통해 SRE는 현재 시스템의 신뢰성을 향상하고 그 신뢰성이 갈수록 더 높아지도록 지원한다.

SRE는 전통적인 IT 운영 방식을 클라우드 네이티브 방식으로 전환하는 팀에 유용하다.

DevOps와 SRE 비교

DevOps는 신속한 고품질 서비스 제공을 통해 비즈니스 가치와 대응력을 향상시키기 위한 기업 문화, 자동화, 플랫폼 설계에 대한 접근 방식입니다. SRE는 DevOps의 구현으로 간주될 수 있습니다.

DevOps와 마찬가지로 SRE는 팀 문화 및 관계에 관한 것입니다. SRE와 DevOps 모두 개발 팀과 운영 팀 사이의 간극을 메우고 서비스를 더 빠르게 제공하는 데 도움이 됩니다.

DevOps 및 SRE 모두 더 빠른 애플리케이션 개발 라이프사이클, 서비스 품질 및 신뢰성 개선, 개발되는 애플리케이션당 소요되는 IT 시간 단축 등의 이점을 달성할 수 있습니다.

SRE는 커뮤니케이션 및 워크플로우 문제를 해결할 때 운영 관련 경험이 있는 개발 팀의 사이트 신뢰성 엔지니어에 의존한다는 점이 다릅니다.

사이트 신뢰성 엔지니어 역할 자체에는 서로 중첩되는 책임이 요구되므로 개발 팀과 운영 팀의 기술이 결합됩니다.

DevOps 팀에서 개발자의 운영 태스크가 과도하고 더 전문화된 운영 기술을 보유한 사람이 필요한 경우 SRE가 도움이 될 수 있습니다.

코드 및 새 기능의 측면에서 DevOps는 개발 파이프라인을 효율적으로 거치는 데 중점을 두는 반면, SRE는 사이트 신뢰성과 새로운 기능 개발 간 균형을 맞추는 데 중점을 둡니다.

컨테이너 기술, 쿠버네티스 및 마이크로서비스에 기반을 둔 현대적인 애플리케이션 플랫폼은 DevOps 사례에 매우 중요하며, 안전하고 혁신적인 소프트웨어 서비스를 제공하는 데 도움이 됩니다.