DevOps Day 2 (3/8) - 개발 프로세스 복습 + 규모에 따른 운영

전통적인 소프트웨어 전당 방식 : 폭포수 (waterfall) 모델
클라우드 서비스의 전달 방식 : 애자일 (Agile) 모델 (saas (Software as a Service) -> 잦은 배포, 낮은 Risk. -> 하루에 여러 번의 릴리즈도 가능하고 Roll Back 기능이 있어 복구가 가능함.

서비스 전달 / 배포 Workflow를 구성할 수 있어야 한다

Ci/CD Pipleline -> 지속적 통합 + 지속적 전달 = 지속적 배포 -> 통합 과정은 코드

CI : 지속적 통합 (Continuous Integration)
Plan
Code : 개발자가 코드를 코드 저장소에 Push 한다
Build : 코드 저장소로부터 코드를 가져와서 유닛 테스트 후 빌드한다
Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인한다.
버그나 문제를 일찍 발견할 수 있고, 테스트가 완료된 코드에 대해 빠른 전달 이 가능, 지속적인 배포가 가능.

CD : 지속적 전달 (Continuous Delivery)
Release : 배포 가능한 소프트웨어 패키지를 작성한다 (배포에 적합한 빌드를 선정한다)
Deploy : 프로비저닝을 진행하고, 서비스를 사용자에게 노출한다
Operate : 서비스에 생길 수 있는 현황을 파악하고 문제를 감지한다

Devops가 기존 서버 관리자와 다른 점

 

DevOps의 이점
속도 : 작업 속도가 빨라지므로 고객을 위해 더 빠르게 혁신하고 시장 변화 에 더 잘 적을함
신속한 제공 : 릴리스의 빈도와 속도를 개선하여 제품을 더 빠르게 혁신하고 가선할 수 있음
안정성 : 애플리케이션 업데이트와 인프라 변경의 품질을 보장합니다
확장 : 규모에 따라 인프라와 개발 프로세스를 운영 및 관리합니다
협업 강화 : 개발자와 운영팀은 긴밀하게 협력하고, 많은 책임을 공유하며, 워크플로를 결합함
보안 : 자동화된 규정 준수 정책, 세분화된 제어 및 구성 관리 기술 사용

Devops 방식
지속적 통합
지속적 전달
마이크로 서비스
코드형 인프라
모니터링 및 로깅
커뮤니케이션 및 협업

 

오후 – 규모에 따른 운영
한 대의 서버 – 다양한 사례 경우에 우리는 어떻게 대처해야 하는가?
1. 자원이 여로 곳에 나뉘어 있어서 한 대가 아닌 여러 대의 컴퓨터로부터 자원을 수집한 후 이를 한 페이지로 정리해서 보여줘야 할 경우 -> 목적에 따라 자원을 분리하면, 단일 서버에서 생기는 복잡한 문제가 보다 단순해집니다.
2. 동시에 수천명이 한 대의 서버에 접속해서 HTML 페이지를 요구할 경우
3. 서비스를 제공하는 단일 서버가 인프라 문제(하드웨어 고장, 네트워크 유실, 천재지변 등)로 갑작스럽게 서비스를 제공할 수 없는 경우 -> 2,3 번의 경우 사용자 규모에 따른 트래픽의 증가에 대한 해결책은 바로 규모 확장입니다.
4. 머신 러닝, 빅 데이터 처리와 같이 여러 대의 컴퓨팅 자원을 이용해 통해 만들어진 결과를 한 페이지로 정리해서 보여줘야 할 경우 -> 이는 서버 확장과 목적의 따른 서버 구성이 함께 도입된 사례 - 즉 일종의 분산 시스템입니다

수직 확장 vs 수평 확장
수직 확장 (vertical Scaling, scale up) : 서버의 성능 (CPU, RAM, 스토리지, 네트워크 I/O)을 높이는 방법
수평 확장 (Horizontal Scaling, Scale Out) : 더 많은 서버를 도입하는 방법
Scale out : Adding more if demand increases
Scale in : Removing if the demand decreases
High Availability : Ability to make your application more available to your customer (High Time : 99.9%) -> Horizontal scaling (More available in multiple AZ’s across your region)

분산 시스템 - Deploy
구성 요소가 네트워크로 연결된 서로 다른 컴퓨터에 있는 시스템으로, 메시지를 서로 전달/통신하고 작업을 조정합니다.
성능 (Performance) : 높은 처리량(throughput) 뿐 아니라 낮은 대기 시간(latency)과 같은 지표 등을 포함하는 개념 (처리량이 뛰어나다)
확장성 (Scalability) : 증가하는 작업량을 처리할 수 있는가, 이로 인한 시스템 확장이 가능한가를 따져보는 기준 (많은 사용자들의 요청에 대응할 수 있다)
가용성 (Availability) : 시스템이 정상적으로 사용 가능한 정도를 의미
Availability = Uptime / (Uptime + Downtime)

분산 시스템의 장점
성능 : 여러 대의 성능의 컴퓨터가, 한 대의 고성능 컴퓨터의 성능을 내는 것이 가능하여 비용적인 측면에도 유리함
확장성 : 한 대의 컴퓨터로 많은 업무에 한계가 있어 여러 대의 컴퓨터에 분할하여 저장 및 업무 처리가 가능함
가용성 : 여러 대의 컴퓨터가 있으면 한 컴퓨터에서 장애가 발생해도 다른 컴퓨터로 전환이 가능

 

자동화 – Operate
수평 확장 통해 여러 대의 동일한 컴퓨터 유지하고 있으며 변경 사항의 종류들이 있음
- 업데이트 및 패치
- 리소스 제공
- 프로비저닝
- 설정
- 배포
What is Provisioning?
Server Provisioning : Setting up a server to be used in a network based on required resources
User Provisioning : Identity management that monitors access rights
Network Provisioning : Setting up a network to be used by users, containers or IOT devices
Service provisioning : Setting up a service and management of the data related to that service

 

모니터링과 로그 – Operate
메트릭이란? : 시간에 따라 측정한 결과값. 보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 함.

모니터링의 목표
1. 시간을 기준으로 측정되는 주요 메트릭을 최소화하여 고가용성을 달성
2. 사용량을 축적하여, 배포에 앞서 세운 가설을 검증하고 개선

Validated Learning : Part of the process by which we learn just how close each iteration is to satisfying the people we’re building it for. Validated learning is quantifiable, based on data such as revenue, user engagement, and feedback.

The four Golden Signals for monitoring :
1. Latency : The time it takes to service a request
2. Traffic : Measure of how much demand is being place on your system, measured in a high level system specific metric
3. Errors : Rate of requests that fail, either explicitly, implicitly or by policy.
4. Saturation : How “full” your service is

 

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

 

Dev팀의 주요 목표는 새로운 소프트웨어 개발 및 잦은 배포와 업데이트를 제공하는 것입니다. Dev팀은 개발한 소프트웨어 테스트 진행하여 버그나 문제가 없는지 신속하게 진행하여 고객이 원하는 요구사항에 맞게 개발합니다.
Ops 팀의 주요 목표는 인프라 관리 및 모니터링 진행하여 안정적인 서비스를 제공하는 것입니다. 서비스 가용성을 높이는 것이 목표입니다.

Dev 팀과 Ops 팀의 목표가 달라 상충되는 부분이 있어 두 팀에서 소통과 이해가 중요합니다.

 

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

 

기술 측면에서는 CI/CD 파이프라인이 중요한 역할을 합니다. 소프트웨어 개발, 테스트, 배포하는 프로세스를 구축하는데 필요한 기술입니다.
CI/CD 파이프라인에서 여러 단계가 아래와 같습니다.
Plan -> Code -> Build -> Test -> Release -> Deploy -> Operate
Plan : 새로운 서비스 / 소프트웨어 개발 기획
Code : 서비스가 작동 할 수 있도록 코드 생성. 자바, 파이썬, 등 다양한 코딩 언어로 코딩 작성
Build : 작성한 코드를 가져와 유닛 테스트 후 빌드 진행. Gitlab 등 도구를 사용하여 빌드 과정을 자동화하는 것입니다.  
Test : 다른 컴포넌트와 잘 통합되는지 확인하고 고객이 요구하는 서비스를 제공하기 위해 지속 업데이트 함. 테스틀 자동화 할 수 있는 도구 사용합니다.
Release : 배포가 가능한 소프트웨어 작성함 
Deploy : 프로비저닝을 진행하고 서비스를 고객에게 노출하는 과정이며 다양한 도구를 사용하여 과정을 자동화 할 수 있습니다.
Operate : 제공된 서비스에 문제가 있는지 감지하고 모니터링 하는 과정이며 Nagios, Grafana등 다양한 도구를 사용 할 수 있습니다.

문화적으로 풀어야 할 부분은 바로 협업 문화입니다. 개발자, 운영자, 테스트자 등 업무가 달라 소통 통해 긴밀하게 협업해야 합니다.
Devops는 지속적인 개선 문화가 핵심 가치 중 하나라고 생각합니다. 새로운 환경 및 요구 사항들을 잘 적응하고 대응 할 수 있어야합니다.