안녕하세요. 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