#2 Devops 개요

Devops의 목적
 : 신속하게 비즈니스 요구에 응하기 위함

개발 부문 + 운용 부문 : 긴밀한 연계
 > 다양한 방법과 문화 도입
 > 상품이나 서비스 개선에 걸리는 시간 단축 
 > 비즈니스 요구에 대응

방법
 : 반복되는 것에 대한 개선 -> 새로운 정책 실시
  > 루틴화, 자동화
 : 잘 안되는 곳 -> 신속하게 변화시킴
 : 신규 서비스의 창출/신규 기능의 추가
 : 기존의 서비스를 신속하게 개선(개발/운용)

시작 방법
 : 개발, 운용의 긴밀한 연계와 협력
 : 상호 간의 관점 -> 서로의 전문성 인정
  > 어떻게 서로 더 이해할 수 있을지 생각하는 것

도구의 도입
 - 추상화 : 모든 리소스(서버, 데이터베이스 등)의 추상화
              : 플랫폼간의 차이 흡수 > 난이도 하향
 - 자동화 : 추상화된 리소스 이용
              : 인적 부담 완화
 - 공통화 : 정보 공유의 가시화, 버젼 관리도구, 의사소통 도구 활용
 - 지속적 통합 : 개발과 운용의 개발/구축 방법 통일
                      : 개선 속도 향상
 - 모니터링 : 리소스 정보를 일원화 및 가시화
                  : 긴밀한 협력관계 구축

문화의 형성
 - 목적 의식
  : 개발/운용이 함께 서비스를 키워서 신속하게 비즈니스 요구에 부응
  : 공통의 목표 > 연계를 쉽게 함
 - 공감대
  : 팀 감정을 줄이고, 관계를 긴밀히 함
 - 자율적 사고
  : 상호간 의뢰를 기다리는 것이 아닌, 자율적으로 공통 목표에 달성에 근접

PDCA Cycle : DevOps는 이 싸이클에 맞추어 진행된다고 생각
 - Plan(계획) > Do(실행) > Check(평가) > Act(개선)
 - DevOps의 도입
  : PDCA로 수행 > 애자일 개발 기법도 사례 중 하나
  : 지속적 통합 등에서도 PDCA 방법 사용
   ~> Build > Test > Feedback

조직과 DevOps
1) 속인성 배제
 > 속인성 작업 : 어떤 특정한 사람에게 크게 의존하는 작업(줄여야 함)
  ~> 그 사람만 아는 것, 그 사람이 없으면 곤란한 것
  ~> 개발과 운용 간의 긴밀한 연계에 저해 요인
 > 운용 관점 : 속인성은 치명적임

2) 지식의 공유
 > 인프라 자원의 설정 순서를 정리한 구축 절차서
  : 모든 정보를 기록
  : IaC로 전환

3) 팀 간의 오버헤드 삭감
 전문적인 팀 > 서버팀, 네트워크 팀, 스토리지 팀.. 등
  : 팀 간의 오버헤드가 큼
   : 상호 간 의사소통 > 문서 교환 + 승인 행위를 거쳐야 함
   : 소요기간 산정 > 버퍼 설정
   >> 일정이 계속 늘어짐
 - 정보 공유 > 크로스 체크 > 전문성(의존) 배제
  : 도구의 활용
   > 버전 관리 도구, 인프라 구성 관리 도구
   > 채팅 도구, 공통의 이슈 트래킹 시스템 도입

품질을 높이기 위한 사례)
부정적 사례)
 - 기획 팀의 지시
 - 개발팀이 인프라 운용팀에 언급하지 않고 어떤 캠페인 기능 포함
 - 서버 자원을 낭비하는 문제 존재
 - 서버 부하 증가 ~> 서비스 중단 상태
 - 운용팀은 수정 사실을 모름 ~> 원인 규명 불가

개발팀과 운용팀이 협력 했다면)
 - Release 시점에 내용을 공유
 - Release로 인하여 발생하는 영향 범위 등 파악
 > 공동으로 모니터링 했다면, 빠른 단계에서 원인 찾아 버그 수정이 가능

콘웨이 법칙
 : 1967년 멜벤 콘웨이
 : 시스템을 설계하는 조직은 그 조직의 의사소통 구조를 그대로 복사한 설계를 하게 된다.
 ex)
 - 처음에 난이도와 시간을 추정한 후, 다섯 명이 코볼 작업에 그리고 세명이 ALGOL 작업에 배정되었다.
   그 결과, 코볼 컴파일러는 5단계, ALGOL 컴파일러는 3단계로 실행되었다.
 : 즉, 의사 소통 비용이 있다
  $f(n) = \frac{n(n-1)}{2}$

 : Eric-Raymond(The Jargon File)
  > If you have four groups working on a compiler, you'll get a 4-pass compiler.
  > 4개의 팀이 조직되면 4단계로 빌드하는 컴파일러가 결과물로 나옴 
  > 특정 조직수에 사람이 너무 많아지면 오히려 비효율적이 될 수 있음
  > 역으로 n개의 결과를 보고싶으면, n개의 팀으로 나누면 됨
 
 : 전문성이 높은 팀은 오버헤드가 증가
  > 해결을 위해서는 조직 설계와 시스템 설계 중 어떤 것이 먼저일까?
  > DevOps의 사고방식 + 뒷받침하는 도구의 도입
   ~> 시스템의 구성과 조직의 위상을 동시에 변화

개인적으로 DevOps를 시작하기
> 기본적인 시스템의 개발과 운용의 흐름
 - 기획/요건 정의
 - 설계/구현
 - 테스트
 - 릴리즈
 - 운용

> Infra 구축 단계
 : VirtualBox를 사용하여 개인 개발 환경 구성
 : IaC 달성(인프라의 코드화) > 개인 개발 환경을 코드화
  > Vagrant 사용 : 가상환경 코드화(인프라 형성) = Bootstraping 단계
  > Ansible 사용 : 구축 및 설정 정보 코드화(배포) = Configuration + Orchestration 단계
  > Serverspec 사용 : 구축 대상의 코드화(테스트)
 : Git 사용 > 코드의 버젼 관리

> 개발환경과 운영환경 나누기
 : 일하는 환경이 다를 뿐 정의된 환경은 동일해야 함(개발 팀 환경 = 운영 팀 환경)
 : 실제 운영 환경과 동일한 개발 환경
  > 실제 운영 환경에 직접 배포, 변경하는 것은 위험 함
  > 팀 개발환경 : 제한적이며, 자유롭게 활용할 수 없을 가능성 존재
  > 개발환경 수의 확대 ~> 개인화

> 팀의 공유 개발 환경이 적합한 경우(아래의 경우에는 개인 개발 환경보다 팀 공유 개발 환경이 더 유리함)
 1) 릴리즈 전 마지막 확인
 2) 성능 시험
 3) 로드 밸런서나 스위치 등 서버에서 완결되지 않는 처리 확인
 4) 시스템 외부와의 인터페이스 확인
 5) 데이터베이스 등 그 환경에서만 존재하는 자원을 이용하는 처리
 
> Local 개발 환경이 적합한 경우
 1) 애플리케이션 개발의 초기 단계, 단위 테스트 수준
 2) 프로토타입 구축
 3) 위험이나 파급되는 영향이 큰 변경의 초기 조사
 4) 환경을 완전히 독점하여 해야하는 작업의 확인

------------------실습 ------------------
Virtual Box 설치 & Hyber-V
Vagrant 설치
 > 가상 머신 만으로 Bootstrapping하기에는 난이도가 높음
  > 환경 구축에 시간과 수고가 많음
  > 환경 공유가 어려움
  > 환경 파악이 어려움
  > 환경의 유지보수가 어려움

Ubuntu 22.04로 진행(CentOS는 지원종료)

가상머신 명령어
vagrant up
vagrant up --provider hyperv

가상머신 접속
vagrant ssh

가상머신 접속 종료
exit(가상머신 접속한 상태)

가상머신 종료(host pc에서 가상머신 종료)
vagrant halt  

가상머신 삭제
vagrant destroy

- Vagrantfile을 통해 프로비져닝 수행 가능 : 미리 설치되어야 하는 정보 작성
- Script 추가 (맨 마지막[end이후]에 따로 추가)
$script = <<-SCRIPT 
 스크립트 내용
SCRIPT

적용 방법
vagrant provision