#1 Devops 개요

Dev(Develop) : 개발
Ops(Operations) : 운용
 ~> 개발과 운용이 긴밀히 협조/연계
 ~> 비즈니스 측면의 가치를 높이는 근무 방식과 변화

일하는 방법을 포함
 : 팀 빌딩
 : 개발 프로세스 설계
 : 문화의 형성

시작 배경
 : 애자일 개발에 의한 계속적인 개발(Continuous Development)로의 변화
 : 계속적인 개발로 인해 나타나는 운용 과제
 > 전통적 개발
  : 개발 ---(인도)---> 운용
 > 애자일 개발
  : 개발 ---(인도)--->운용
  : 추가적인 개발 ---(인도)---> 운용 (업데이트)
  : 추가적인 개발 ---(인도)---> 운용 (업데이트) 
 ~> 운용하는 동안 추가 개발이 진행
 ~> 이를 업데이트 했을 때, 기존 잘 되던 서비스가 동작하지 않는 문제 해결에 대한
      운영팀 입장의 고민이 발생

애자일 개발 -> 계속적 개발로의 변화
 1) 워터폴(Water fall / 폭포수 모델) - 1980~
   계획 > 요건 정의 > 설계 > 개발 > 테스트 > 릴리즈
   : 보통 6개월 ~ 1년의 사이클을 가짐
   : 개발 도중 (혹은 테스트 단계)에서 시장의 변화로 요건이 바뀌는 경우가 생김
   : 릴리즈를 한 시점에서 시장에서 봤을 때 Outdated 제품이 되버릴 리스크가 많아짐
    ~> 이를 해결하고자 시장을 빠르게 반영하기 위한 개발이 애자일 방식
 2) 애자일
   계획 > 설계 > 개발 > 테스트 > 릴리즈 ---(피드백)---> 계획 > 설계 > 개발 > 테스트 > 릴리즈
   : 한 번에 전부 개발하는 것이 아니라 빠르게 적용해 나가면서 개발
   : 워터폴을 줄여 짧게 수행하며 여러 번 반복
   : 급한 문제를 해결해나가는 과정
   : 4 ~ 8주 / 길면 12주(3개월)을 기준으로 사이클을 가짐

애자일 개발의 특징
 : 기능의 추가 혹은 개선이 빈번
  > 업데이트 횟수(높음) : 대응을 위한 개발방법론 도구들이 개발 됨
  > 지속적 통합(Continuous Integration)개념 도입
   : 개발에서 테스트 과정이 극단적으로 빨라야 하는 문제 발생
   : 이를 해결하기 위한 개념이 지속적 통합
   : 개발자가 커밋(commit)을 하면 테스트가 자동으로 진행되고 최종적으로는 릴리즈까지 진행 됨

애자일 개발의 개발과 운영
 개발자 입장 >
  : 개발 범위의 효율화 및 자동화 ~> 지속적 통합으로 달성
 운용 입장>
  : 개발자가 대응할 수 없는 문제가 존재
   > 인프라 관련 설정/구축
   > 개발자 측에서는 50~100명으로 테스트
      실제 운용에서 1000명 이상으로 실행되니 동작안하는 문제 발생
      이 처럼 운영에서만 발생하는 특수한 문제들이 존재함

개발 조직의 형태 

개발 조직 형태

엔지니어링 : 개발, 구축 테스트
 > 플랫폼 인프라 또는 비즈니스 애플리케이션을 정의하고 검증하는데 필요한 모든 활동

운영 : 배포, 운영, 관리
 > 생산 현장에서 플랫폼, 인프라 및 애플리케이션을 배포하고 지원하는데 필요한 모든 활동

애플리케이션 : 비즈니스 소프트웨어
 > 맞춤형 개발 또는 상용 기성품

플랫폼 : 인프라
 > 컴퓨팅, 네트워크, 스토리지 미들웨어, 런타임, 데이터 운영, 보안 등

문제점
 1) 인프라팀
  : 애플리케이션을 신경 쓰지 않음
  : 어떻게 동작하는지 관심이 없고 환경은 구축했으니 무조건 애플리케이션이 동작해야한다는 입장
 2) 운영팀 -> 기술적 부담(technical  debt)
  : application code나 infra source code를 수정하였을 때,
    해당 수정이 미치는 영향도(impact)를 몰라서 업데이트용 패치를 적용하지 않음
  : 하드웨어 기술 지원기간이 지남
  : 신속한 보안을 위해 스크립트를 재시작함
  : 마이그레이션(migration)이 불완전하게 끝남
 3) 개발팀 
  : 스페셜리스트(specialist)들만 존재 (전문가)
  : 누구도 다른 일을 하지 않음
  : 추가 기능 및 개선 사항을 관리하는 리스트에는 To do 만 존재
   -> 요구사항이 추가될 경우 앞으로 해야할 개선사항에만 존재(당장 개발 목록에 추가 되지 않음)
  : (팀이 분화될 수록 심해지는 현상) 전체 애플리케이션 내부에 대한 지식이 없음
  : Product Manager나 Operation Manager등 팀마다 매니저가 존재
   -> Product 책임자가 다수 존재 -> 통합된 환경에 대해서 정말 중요한 요건이 보이지 않음
 4) 개발자 시점
  : 기능 요건은 잘 수행 됨
  : 비기능 요건을 소홀히 취급 > 모니터링, 이중화, 백업, 운영체제 등
    ~> 대부분 운영조직에서 요구하는 요건들
    ~> ex) 어떤 함수가 실행될 때 몇 초 걸리는지 개발자는 관심 없음 / 운영(테스트)에서 필요함

해결 방안 
 > 운용 문제
  : 데일리 스크럼(일일 회의 : 오전에 간단히만 진행)
   - 진행 방향에 대한 해결책 도출
   - 우선 순위 설정
   - Task에 페어(Pair) 대응
   - "정보 공유"가 자연스럽게 전해지는 상태 형성

 > 개발 문제
  : 인프라팀을 포함(Infrastructure as Code | IaC)
    - 인프라 요건을 기존보다 더욱 이른 단계에서 가시화
    - 운영팀이 가지고 있는 인프라를 개발팀이 가질 수 있다면 쉽게 해결 가능
     : 인프라의 요건을 개발자가 개발환경으로 통제
     : Infrastructure를 지식의 유무 관계 없이 코드로 구현
  : 과제(Task)
    - 과제의 담당자를 명확히 함

Devops <- 애자일에서 해결하고자 했던 방향이 담겨 있음
 : 모든 버젼을 관리
  - Software + Configuration : Infra 관리
   > Infra의 지속적 통합(Continuous Integration)
   > 원스톱(One-Stop) 배포(Deployment) : 배포 자동화
     : 릴리즈 시 인도 과정이 필요한데, 이 인도 과정을 자동화 함
 : 모니터링 역시 자동으로 진행
 : 정보 공유
  - 개발과 운용은 "같은 장소"(= 같은 Infra Structure)에서 동일한 것(=같은 문제)을 본다.
    > Dev and Ops see the same thing, in the same place.
    > 운영팀에서 문제가 발생할 경우 개발팀에서도 같은 문제를 재현 가능해야 함
  - 코드화 된 구성 (Iac) 정보 > 버젼 관리
 : 사고 방식의 변화
  - 문화, 조직 운영 방식의 변화 등 포함

IaC > Infra의 관리가 필요
Infra의 구성 관리 도구
 - Provisioning(프로비져닝) : 어떤 일을 하기 위해 준비 되어야 하는 상태
  > 오케스트레이션(Orchestration) 수준 (Capistrano, ... 등)
   : 배포나 노드간 연계 등 복수 서버에 대한 설정이나 관리 담당
  > 컨피규레이션(Configuration) 수준
   : 운영체제, 미들웨어의 설정 담당 (SmartFrog, ... 등)
  > 부트스트래핑(Bootstraping) 수준(가장 Low Level)
   : 가상 서버 생성이나 운영체제 설치 담당 (Kickstart, ... 등)
  ~> Hardware에서 Software를 사용할 수 있는 수준으로 만드는 것이 Bootstraping
  ~> Software를 쓸 수 있는 수준(Bootstraping)에서 원하는 형태의 동작, 튜닝이 되도록 하는 것이 Configuration
  ~> 위의 튜닝이 여러 대의 머신에 걸쳐 일어나는 것이 Orchestration

Provisioning 영역

관련 도구
 - Puppet, Chef, Ansible 등
  ~> Configuration과 Orchestration의 경계선이 사라짐
 - Chef의 경우 상용화가 되어 AWS에 서비스 형태로 들어가져 있음

Provisioning 영역에 구성관리 도구를 적용했을 때

 - Software적으로 (코드로) 정의내림 > 누가 해도 모두 동일한 결과를 기대함

Infrastructure as Code(IaC) : DevOps에 IaC가 꼭 포함된다고 생각
 - Infra의 코드화 : 인프라 구성 관리 도구에 의한 설정의 코드화/구성 정보화 전체를 지칭
 - 모든 인프라는 코드에 의해서만 구축되고 설정이 변경되어야 함
 - 대체로 고도의 프로그래밍 능력을 요구하지 않음
  : 애플리케이션 개발자가 인프라 운용에 관여할 수 있게 됨
  : 인프라 엔지니어도 IaC에 접근할 수 있음

DevOps의 시작
 - 2009년, Flickr(당시: 루디코프, 현: 미국 Yahoo!) 엔지니어 2명
  : 10+ Deploys per Day : Dev and Ops Cooperation at Flickr 발표
  > 하루에 10번 배포가 가능하게 했다
  : 발표 내용
  > 개발 부문과 운용 부문의 대립 관계 설명
   > 개발 부문 : 서비스에 변화를 주고자 함
   > 운용 부문 : 안정적 가동이 목표, 변화를 싫어 함

 - 개발 부문과 운용 부문의 대립

대립 과정

 - 개발 부문과 운용 부문의 목표
  개발 부문 : 세상(시장)의 변화에 대해 대응 -> 비즈니스에 변화를 주고자 함
  운용 부문 : 안정을 위해 사업으로 인한 변화를 가하고 싶지 않음
  두 부문의 공통 목표 : 비즈니스를 유효하게 하는 것
  >> 변화의 위험을 도구와 문화(내용을 공유)로 낮춘다.
 
 - 변화에 대응하기 위한 도구
 1) 인프라 자동화(Automation) > IaC와 같은 Provisioning tool
 2) 버젼 관리 공유 > 이전 상태로 되돌릴 수 있어야 함
 3) 원 스텝 빌드와 배포 > 자동화
 4) 애플리케이션 기능의 유효/무효를 설정 파일로 관리 > 문제가 발생시 해당 기능만 종료해서 서비스 운영
 5) 메트릭(Metric)을 공유 > 기능의 상태(정상작동/비정상/폭주 등)(메트릭)에 대한 정보를 개발팀과 공유
 6) 인스턴트(instant) 메신저 봇 > 슬랙 등

 - 변화에 대응하기 위한 문화
  1) 존중
  2) 신뢰
  3) 실패에 대한 긍정적인 자세
  4) 비난을 하지 않는 것
 
 DevOps의 탄생
 - 2009년 10월 30일
  : DevOpsDays Ghent 2009
  : 패트릭 드부와(Patrick Debois)가 처음으로 DevOps라는 말을 언급
 - 반응
  : 기존의 개발 문화가 있는 한 불가능하지 않는가?
  : 그렇게 배포하는 것이 의미가 있나?
  : 개발과 운영이 협력한다니 어처구니가 없다.