[개발 프로세스와 DevOps 업무 개요] 02. 규모에 따른 운영

# 학습 목표

• 규모에 따른 운영
  • 수직 확장과 수평 확장의 차이를 설명할 수 있다.
  • 분산 시스템의 장점과 단점을 설명할 수 있다.
  • 자동화와 모니터링의 필요성을 설명할 수 있다.

 

---

# 학습 내용

1.  한 대의 서버

• 관점에 따른 서비스 접속 방법

사용자 관점	서버 관점
- 브라우저에 URL 입력 - DNS 서버가 URL을 IP로 변경해 해당 서버에 접속	- 사용자가 서버에 접속한 이후 경로 처리(도메인 이후의 문자열) - 라우팅 규칙에 따라 서버 자원을 사용자에게 제공

• 한 대의 서버 운영 시 발생하는 문제 해결 방법
  • 분산된 자원을 수집하여 한 페이지로 보여주어야  경우 -> 목적에 따라 자원을 다중 서버로 분산하여 서버 구성
  • 수천명이 한 대의 서버에 페이지를 요청할 경우 ->  규모 확장
  • 단일 서버가 인프라 문제로 서비스 제공이 불가할 경우 -> 규모 확장
  • 머신 러닝, 빅데이터 처리와 같이 여러 컴퓨팅 자원을 통해 만들어진 결과를 한 페이지로 정리해 보여주어야할 경우 -> 분산 서비스

 

2. 규모 확장 : 수직 확장 vs. 수평 확장

	수직 확장	수평 확장
개념	서버의 성능(자원: CPU, RAM, 스토리지, 네트워크 I/O 등)을 높이는 방법	더 많은 서버를 도입하는 방법
특징	- 트래픽 양이 적을 때 유리 - 장애 대응이 어려움 - 하드웨어 장애 발생시 즉시 서비스 중	- 트래픽 양이 많을 때에 적용 가능

 

3. 분산 시스템

• 정의
  
  • 구성 요소(물리적인 하드웨어 상에서 작동하는 프로그램)가 네트워크로 연결된 서로 다른 컴퓨터에 있는 시스템
  • 메세지를 통해 통신
• 용어
  • 성능: 처리 능력, 응답 시간, 반응 시간, 신뢰도, 가용성 등의 지표로 평가 가능
  • 확장성: 증가하는 작업량을 처리할 수 있는가, 시스템 확장이 가능한가를 평가하는 기준
  • 가용성: 시스템이 정상적으로 사용 가능한 정도 (계산 방법 : 작동중인 시간/ (작동중인 시간+ 작동중이지 않은 시간))
• 장점
  • 비용: 상대적으로 저비용(사양이 낮은 서버 여러대 사용)
  • 성능: 저사양의 서버 여러대를 통해 고사양의 서버 성능 발휘 가능
  • 확장성: 여러 대 컴퓨터에 분할해 저장, 처리 가능
  • 가용성: 한 노드의 장애가 서비스 중단으로 이어지지 않음 (중복 허용, 장단점 존재)

 

4. 자동화

• 수평 확장 이후 고려할 사항
  
  • 변경 사항(업데이트 및 패치, 리소스 제공, 프로비저닝, 설정, 배포) 발생 시 모든 컴퓨터에 설정 적용 필요
  • (ex) 수십대의 서버의 기동 중지, 업데이트 다운로드 후 보안 패치 적용과 새로운 릴리즈 프로그램 설치, 재기동 수행
  • 자동화가 필수

! Check Point !
- IT 인프라의 자동화를 돕는 툴의 종류
>

• 프로비저닝
  • 사용자의 요구에 맞게 시스템 자우너 할당, 배치, 배포해두고 필에 따라 즉시 사용할 수 있는 상태로 준비시켜두는 것

! Check Point !
- 프로비저닝 종류
> 

 

5. 모니터링과 로그

• 개요
  • CI/CD 파이프라인 운영 단계에서 서비스 현황 파악, 문제 점검하는 것
  • 지표 및 메트릭(시간에 따라 측정한 결과 값) 기준 설정 필요
• 목표
  • 시간을 기준으로 측정하는 주요 메트릭을 최소화 하여 고가용성 달성
  • 사용량을 추적해 배포에 앞서 세운 가설을 검증하고 개선
• 주요 메트릭의 측정 방법
  • 1대일 경우: 리눅스와 같은 O/S를 통해 측정 가능
  • 클러스터의 경우: 모니터링 전문 도구를 통해 수집 가능
• 주요 벤더사의 모니터링 목표와 메트릭 목표

구글	마이크로소프트(Azure)
장기적인 트렌드 분석 (Analyzing long-term trends) 데이터베이스가 얼마만큼의 용량을 차지하며, 얼마나 빨리 용량이 증가하는가? DAU(일간 활성 사용자수)는 얼마나 빨리 증가하는가? 시간의 경과 및 실험 그룹 간의 비교 (Comparing over time or experiment groups) 어떤 데이터베이스를 썼을 때 쿼리가 빠른가? 지난 주보다 사이트가 얼마나 느려졌는가? 경고 (Alerting) 인프라의 어떤 부분이 고장났는가? 혹은 고장날 수 있는가?	CPU, Memory 인스턴스의 갯수 연결 유지

 

---

# 발표 주제

- (Dev팀과 Ops팀) 각 팀의 목표는 어떻게 다른가요? 두 팀의 목표에서 상충되는 부분이 존재하나요?

• 개발팀과 운영팀의 목표
  • 개발팀: 신규 기능의 빠른 제공, 버그 수정
  • 운영팀: 서비스 안정성, 빠른 성능
• 개발팀과 운영팀의 목표 중 상충되는 부분
  • 개발팀은 잦은 업데이트를 통해 제품을 변경하는 것이 목표라면 운영팀은 서비스 구성 변경을 최소화해 서비스 안정성을 확보하는 것이 목표
  • 사용자 편의를 위해 신규 기능을 개발할 경우 코드 변경, 서비스 재가동, 업데이트 등 변화에 따른 위험이 수반되지만, 사용자에게 안정적인 서비스를 제공해야하는 운영 목표와 상충할 수 밖에 없음
  • 장애 발생 시 책임 전가 가능. 개발자의 경우 테스트 시 문제 없었는데 운영 상 문제가 생겼다고 주장 가능, 운영자의 경우 코드 변경으로 장애가 생겼다고 주장 가능
  • 다만 두 조직 모두 근본적으로 사용자에게 편리하고 안정적인 서비스를 제공하고자 하는 공동의 목표를 추구함에는 변함이 없음

- DevOps를 실현 가능하게 하기 위해 기술이 필요한 부분과, 기술이 아닌 문화로 풀어야 할 부분은 각각 무엇인가요? CI/CD 파이프라인에 근거해 답해봅시다.

• 실현 방법
  • 기술적 측면 : CI/CD 파이프라인 중 코드, 빌드, 테스트, 패키지, 릴리스, 구성 단계에서 적용
    
    • 지속적 통합(CI)
      • 빌드, 테스트 자동화
      • 중앙 형상관리 저장소에 코드 지속적 통합, 테스트, 배포되도록 준비
      • 제품 : 깃, 데미안 
    • 지속적 전달(CD) 
      • 릴리즈, 배포 자동화
      • 형상관리 서버에 자동화된 트리거 기반 배치 유닛 제공
      • 제품 : 젠킨스 등
    • 프로비저닝
      • 운영팀에서 서버에 빌드된 코드 블록을 자동 설치, 시스템 구성/관리를 위해 사용
      • IT 인프라 자원을 중앙에서 관리
      • 서버 자원, OS, SW, 스토리지, 계정 프로비저닝 등
      • 제품 : 퍼펫  등
  • 문화적 측면 : CI/CD 파이프라인 중 계획, 운영 단계에서 적용
    • 개발문화가 변화를 수용하도록 보상시스템 마련(각 기능별로 성과를 보상하는 것이 아니라 전체 개발 차원에서 성과를 측정하고 보상)
    • 개발에서 운영까지를 하나의 통합된 프로세스로 묶어내고 툴과 시스템을 표준화하고 통합하여 의사소통의 효율성을 확보하고 매뉴얼 작업을 가능한 자동화함으로써 코드 통합, 테스트, 릴리즈 과정이 자동화시키는것이 필요
    • 기능교차적인 팀을 만들기 위한 훈련과 효과적인 협업체계를 마련-> Devops팀은 각 기능에 대하여 기본적인 이해와 기술을 갖춘 전문가들로 구성

출처 :  http://pds26.egloos.com/pds/201310/24/85/Devops1.pdf, Devops의 이해와 구현 Part 2 :
Devops 구현하기(품질, 프로세스, 도구 관점에서) - 정보통신산업진흥원 부설 소프트웨어공학센터 경영지원TF팀 황순삼