CSMSA

MSA이론4. DevOps

DevOps

Using DevOps to Solve your Delivery Challenges

  • 배포는 너무 오래걸린다.
  • 테스트에 대해 혼란스럽다.
  • 특정 개인에 대한 높은 의존성.
  • 데브옵스 모델은 lock을 제거한다.
  • 데브옵스 모델은 프로비저닝한다.

Delivery는 Continuous integration + continuous deployment를 의미한다.

데프옵스의 특징

  • 높은신뢰성, 높은 퍼포먼스
  • 데브옵스는 프로덕트, 툴이아니다. 데브옵스는 문화이다.
  • 고수준의 자동화 프로세스
  • 정기적이고 반복적인 플로우를 따른다. 싸이클은 짧고, 작고 잦은 변경을 선호한다.

DevOps

  • 데브옵스의 철학은 개발과 운영의 통합 문화를 만들고, 협업 변화를 촉진하기 위해 기술의 linked toolchain 을 요구하는 것이다.
    toolchain? : Target 시스템의 Software 개발을 진행하기 위해 필요한 host system의 Cross Compile(교차 컴파일) 환경이다.
  • DevOps의 toolchain은 수십개의 non-collaborative 툴을 포함할 수 있고, 복잡하고 어려운 작업을 자동화를 통해 task로 만들 수 있다.
  • DepOps의 정의에 따르면 one-size-fits-all이 해결책이 아니다.
  • DevOps는 특정 문제 및 과제에 대한 정보를 제공한다.

DevOps를 위한 microservice requirements

  • microservice에 기반한 새로운 어플리케이션을 빌드하라
  • 기존 microservice 어플리케이션을 클라우드로 마이그레이션하라
  • 하이브리드 microservice 어플리케이션을 배포하라
  • 존재하는 어플리케이션들을 microservice architecture로 발전하라.

Microservice 배포를 위해 따라야 할 Roles

  • 개발자는 테스트를 반복하며 각 테스트는 pass해야한다. 또한 계속되는 피드백에 대비하자.
  • 테스터는 자동화 된 파이프라인에 컴포넌트, 통합, 회귀를 포함하고 크로스 플랫폼간 API를 통해 테스트가 가능토록 하자.
  • 성능테스터는 로딩 테스팅을 모니터링하고 blue/green, rolling 배포를 하자.

rolling 배포: 일반적인 배포를 의미하는데, 단순하게 한 대씩 재시작한다. 코드 변경에 따른 side effect가 발생할 수 있다
blue-green 배포: 예전 배포물을 블루(blue), 신규 배포물을 그린(green)이라고 해서 붙여진 이름이다. 새로운 배포물을 배포하고 모든 연결을 새로운 배포물만 보게 하며 코드 변경에 따른 side effect가 없다. (배포시 중단시점이 없음!)

  • Release 하는사람은 성능 측정을 해야한다.
  • 운영자는 가용성을 모니터링하고 blue/green 배포를 해야한다.
  • 엔드유저는 지속적인 피드백을 주고 변경에 대해 대비한다.

DevOps의 평가기준

배포빈도(얼마나 자주 배포하나)

  • 최상: 요구될때마다
  • 보통: 일주일 혹은 한달에 한번
  • 최하: 한달에서 여섯달 사이에 한번

Lead time for changes(ie.코드가 커밋되고 정상적으로 동작하는데 걸리는 시간)

  • 최상: 한시간 이내
  • 보통: 일주일 ~ 한달사이
  • 최하: 한달~여섯달 사이

Mean time to recover(복구하는데 걸리는 시간)

  • 최상: 한시간 이내
  • 보통: 하루 이상
  • 최하: 하루 이상

Change failure rate

  • 최상: 0~15%
  • 보통: 31~45%
  • 최하: 16~30%

Database 관련 생각해봐야 할것들

  • Production data에 대한 보호,보안(바꾸는 것은 리스크가 있다)
  • Test data 필요
  • 환경이 다름
  • 의존성
  • 다수 어플리케이션이 동일 db에 접근한다.
  • 이전버전과 호환성 유지
  • 롤백을 어떻게 할지

DevOps Values

CALMS

  • Culture - 변화를 수용하라
  • Automation - CI/CD
  • Lean - 엔드유저가 생상하는 value에 초점을 맞추고, 배치사이즈를 작게하라
  • Measurement - 모든것을 측정하고 개선된것을 보여줘라
  • Sharing - 정보를 공유하고 협업하라

DevOps Tools

Configuration Automation / Management: Puppet, Ansible, Chef, Salt
Continuous Integration: Jenkins, CruiseControl, Capistrano
Monitoring: Icinga (nagios), Zenoss, Sweet, Graphite
Containerization: Docker, Rocket

DevOps 관련용어

CI/CD

  • Continuous Integration 그리고 Continuous Deployment의 약어

Continuous integration

  • 최신코드에서 변경된것을 사용가능하도록 빌드한다.

Continuous deployment

  • 가능한 빠르게 배포 단계를 거치고 빌드된 해당 패키지가 프로덕션 환경으로 전환되도록 한다.

Continuous delivery

  • Continuous integration + continuous deployment

Delivery pipeline

  • 일련의 자동화 단계로써 CI/CD를 수행한다.

Continuous Integration

아래와 같은 단계를 빈번하게 수행한다.

1. Development

  • 배치 테스를 거친 작은 변화들이 빠르게 구현된다.

2. SCM(Source Code management)

  • 여러 개발자의 변경된것사항을 병합한다.(GitHub, SVN … 활용)

3. Build

  • 배포할것을 만든다.(Jenkins, Gradle, Maven … 활용)

4. Package

  • 런타임때 빌드를 설치한다.
  • 변경할 수 없는 이미지를 런타임때 releasing 한다.
  • 클라우드에 푸쉬하고 컨테이너 이미지 빌드

Continuous integration – package step

package step에선 변경 불가능한 이미지가 만들어진다. 이는 deploying instance를 생성할 때 사용된다. 이미지를 변경하고 싶다면 삭제하고 새로 만들어야 한다.

Continuous Deployment

Production 배포까지의 과정
1. Deploy to Test

  • functional testing 진행, test tool을 활용한 자동화
    2. Deploy to Stage
  • Production 배포 전 리허설
  • 통합 testing 진행
    3. Deploy to Prod
  • 사용자가 사용할 수 있도록 빌드

Continuous Delivery vs continuous Deployment

Zero Downtime Deployment

서비스 중단없이 새로운 버전을 배포하는것을 의미한다. DevOps는 잦은 배포를 하므로 필요하다.

Zero Downtime Deployment 특징

  • 어플리케이션은 항상 사용가능하다.
  • 사용자가 중단(Downtime)없이 사용할 수 있다.
  • 이전버전, 새버전이 동시에 배포됨 - 트래픽이 둘 다로 전달됨.

Implementing Zero Downtime Deployment – Blue Green

Deployment
필요한경우 이전버전으로 신성하게 되돌릴 수 있다.

1.v1(blue)이 배포되어 사용자들이 사용하고 있을 때 v2(green)을 배포한다.
2.자동화된 테스트 도구로 테스트, 검증을 진행하고 사용자를 v1에서 v2환경으로 변환한다.
3.v1(blue)을 삭제한다.

DevOps로의 Transformation

  • Top to Bottom문화를 변화시키는 것이 핵심이다.
  • 교육을 늘리고 커뮤니케이션하고 cross-skilling 하라
  • DevOps가 가능한 새로운 프로세스를 평가하라
  • 스스로 재평가하고 재빌드하라
  • DevOps를 지원하는 새로운 기술 평가
  • 조직을 작게 나눠라

Bottom-Up Implementation

  • 협업을 위한 방법을 찾아라. (사람들을 초기부터 참가시킨다.)
  • 자동화 방법을 찾아라
  • metrics driven이 되어라
  • 새로운것을 배우고 지속적으로 개선해라
  • 작은 batches와 함께 병렬적으로 일해라
  • 리팩토링을 허락해라
  • 경영진에게 비즈니스 가치를 입증해라
  • 비즈니스의 목표, metrics, 우선순위를 이해하라.

Top-Down Implementation

  • 시험 케이스를 파일럿으로 선택하라
  • 우수 사레를 문서화하고 전파하라
  • 팀의 역량을 강화하고 가치를 이끌어내라
  • 측정 가능한 결과를 요구하라
  • 과거의 baseline이 충분치 않을때 변명하지 마라
  • 빠르게 실패하고 지속적으로 향상하라
  • 작은성공을 기반으로 나아가라
  • 비효율적인 경우 그룹간 역할 및 책임을 조율하라.
Share