[devops] DevOps Engineering

안녕하세요. DevOps Engineering 개념에 대해서 간략히 정리했습니다.

DevOps 모델 정의

• 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화, 철학, 방식, 도구의 조합
• 소프트 개발 사이클의 속도를 높여 제품을 더 빠르게 혁신하고 개선할 수 있으며 조직은 고객을 더 잘 지원하고 시장에서 효과적으로 경쟁할 수 있다.

DevOps Pipeline

DevOps 운영 이슈

• Amazon은 소프트웨어를 소규모 독립 서비스로 리팩토링하고 조직을 소규모 자율팀으로 재구성했다.
• 각 팀은 단일 서비스의 개발 및 운영에 대한 완전한 소유권을 가지고 고객과 직접 협력하여 개선했다.
• 이러한 명확한 초점과 제어로 팀은 새로운 기능을 빠르게 생성할 수 있었지만 배포 프로세스는 곧 병목 현상이 되었다. -> 배포자동화 필요
• [참고- The Story of Apollo — Amazon’s Deployment Engine]

DevOps 고려사항

• 다양한 변경에 대한 컴퓨팅 리소스의 탄력적 운영 -> 코드 기반 인프라 구성 및 형상 관리
• 빈번한 소프트웨어 빌드 및 릴리즈를 효과적으로 운영 -> 지속적 통합, 전달 및 마이크로 서비스
• 인프라 및 어플리케이션의 성능 추적 및 대응 -> 모니터링 및 로깅의 표준화, 고도화
• 중복 업무 발생 제거 및 협력 문화 강화 -> 에자일, 협업 툴을 통한 업무의 협력 강화 및 투명화

DevOps 모델 워크플로우

DevOps 모델 구성 요소(Code, Build)

• 소스코드를 개발하고 컴파일 및 코드를 배포 가능한 파일(artifact) 구성 상태로 만드는 단계
• code 단계: git, bitbucket
• build 단계: ant, gradle, maven

컴파일 및 빌드

• compile: 소스 코드를 분석해 기계어(binary code)로 번역
• build: binary code와 asset 들을 모아 실행가능한 상태로 만드는 것
• artifact: 배포 가능한 형태의 컴파일 또는 빌드된 소스 코드
• repository: 아티팩트(패키지)들을 배포하기 위한 저장소

DevOps 모델 구성 요소(Test)

• unit test : 각 기능별로 동작 유무를 확인할 수 있는 custom script
• integration test : unit 테스트의 묶음 혹은 전체 서비스 동작 유무를 확인할 수 있는 custom script
• load test : 네트워크 레벨의 부하를 일으켜 평균 응답 시간 혹은 TPS(Transaction Per Second) 측정 — loadrunner, jmeter 활용

DevOps 모델 구성 요소(Deploy, Release)

• 배포 가능한 파일(artifact)을 통해서 소스코드를 배포(deploy) 및 인프라 리소스에 대한 형상을 변경(생성, 삭제) 하여 서비스 투입(release)하는 단계
• deploy 단계 : 리소스 생성 및 삭제(cloudformation, terraform), 리소스 설정 관리(ansible, chef, saltstack, puppet)
• release 단계 : artifact 배포(jenkins, bamboo, GoCD)

DevOps 모델 구성 요소(Monitor)

• 인프라, 어플리케이션의 시스템과 서비스 레벨의 지표와 로그를 모니터링하여 개선 사항을 도출하는 단계
• monitoring 단계 : 인프라 모니터링(grafana, influxDB, nagios, zabbix), 어플리케이션모니터링(jennifer, pinpoint, net relic)
• 로깅 단계 : elasticsearch, fluentD, splunk

DevOps 도입 형태

• 지속적 통합
• 지속적 전달
• 코드형 인프라
• 마이크로서비스
• 커뮤니케이션 및 협업

지속적 통합(CI: Continuous Integration)

지속적 전달(CD: Continuous Delivery)

AWS CICD 예시

코드 형태의 인프라 구성 방안 및 도구

• Infrastructure as Code(IaC)는 코드 버전 관리와 같은 소프트웨어 개발 기술을 사용하여 명시적인 코드형태로 인프라를 프로비저닝하고 관리하는 방식
• 인프라가 코드를 통해 정의되므로 인프라와 서버를 표준화된 패턴을 사용하여 다양한 환경에 동일한 인프라 구성 매칭이 가능하다.

IaC Type

• Ad-hoc Script 방식
• Configuration Management 방식
• Server Templating 방식
• Infra Provisioning 방식

Ad-hoc script 방식

• 가장 간단한 형태의 자동화 구현 방식
• 수동으로 작업하는 명령어를 순서대로 나열한 script 형태로 구성
• 작성한 script를 해당 장비로 가서 직접 수행
• ad-hoc 방식은 소규모, 단발성 작업에 적합

Ad-hoc script 방식 한계

• 모든 것을 직접 개발하고 구현해야 함
• 복잡한 형상과 설정이 필요한 경우 구현 난이도가 올라감
• script 작성한 엔지니어 말고는 알아볼 수 없는 상황을 초래할 수 있음
• 코드 유지 보수 문제로 귀결

ad-hoc script example

Configuration Management 방식 소개

• 이미 배포된 인프라 환경에서 application이 동작하기 위해 필요한 서버 설정 자동화 작업에 활용(예: ansible)

configuratoin management example— ansible playbook

Server Templating 방식

• template 방식 배포 구조
• 소프트웨어를 정상 동작 시키기 위해 필요한 설정 + 패키지 + OS 이미지를 파일형태로 저장하여 이미지화
• 기존 환경을 수정하여 구성하는 CM 기반 관리와 다르게 원하는 형태의 이미지를 배포하여 구성하는 방식

server templating example

Server Templating 방식 구조

• 클라우드 컴퓨팅, 컨테이너 환경 등에서는 빠지지 않고 활용

Infrastructure Provisioning 방식

• 인프라 환경 배포 및 설정 전반의 작업들을 code로 구성/관리하는 방식
• 대표적인 도구 : terraform, aws cloudformation 등

 

 

blog migration project

written in 2023.4.20

https://medium.com/techblog-hayleyshim/devops-devops-engineering-8f254152970