DevOps 와 CI/CD

DevOps

과거에는 새로운 서비스 출시를 위해 많은 시간 소요( 코드 개발, 테스트 등 )되었다.

 

현재는 서비스 출시의 속도가 빠르고 업데이트 주기도 빈번해졌기 때문에 사용자에게 안정성과 신속성을 제공하기 위해서는 개발, 테스트, 배포, 운영의 업무사이클을 자동화된 하나의 프로세스로 통합할 필요가 있다.

 

지속적인 혁신과 새로운 기술을 통해 빠르게 개선하고 가치있는 고객 경험을 전달하여 기업가치를 빠르고 개선된 형태로 전달하는 것은 기업의 생존문제이다.

 

Devops란 단절된 개발과 운영간 프로세스를 유연( seamless )하게 연결하고 자동화방법을 통해 효율성을 극대화하는 방법이다.

 

 

1. Devops 의 핵심 요소 CAMS

1-1. Culture | 문화

팀의경계를 완화하고 협업 수준을 향상

• 조직의 '사일로'화를 경계해야한다.

 

사일로 조직의 문제점

• 부서별 데이터가 통합되지 않아서 회사 전체 데이터를 통합해 인사이트를 얻기 곤란하다.

 

개선방안

• 비즈니스 목표에 맞춘 원활한 커뮤니케이션과 협업 문화가 중요하다.

 

1-2. Automation | 자동화

개발자가 소스코드를 작성하는 과정에서 부터 실제 서비스에 적용되기 까지의 전체의 과정을 수작업이 아닌 자동화된 프로세스로 관리

서비스에 대한 품질 검사 및 모니터링도 자동화

장점

• 시간을 절약할 수 있다.
• 작업자의 실수를 예방할 수 있다.
• 서비스의 일관성도 유지할 수 있다.

 

자동화의 완성 젠킨스( Jenkins )

Java Runtime 위에서 동작하는 자동화 서버이다.
빌드, 테스트, 배포 등 모든 것을 자동화 해주는 자동화 서버
일련의 자동화 작업의 순서들의 집합인 pipeline 을 통해 CI/CD 를 구축한다.

 

 

1-3. Measure | 측정

Devops 전반에 대한 측정 능력 및 방안 필요하며 측정된 데이터는 투명하고 접근( access ) 가능해야하며

시각화를 통해 가시성이 있어야 한다.

 

측정할 수 없으면 관리할 수 없고, 관리할 수 없으면 개선할 수 없다

• 지속적인 서비스 개선을 위해 중요

 

1-4. Share | 공유

Devops 의 성공을 위해서는 조직 전반의 요구사항을 도출하고 협업 툴을 활용하여 중복 작업 제거 및 참여 의식 고취

 

소통이 없을 시 문제점

• 서비스 구조가 복잡하여 작업 공유가 안되면 작업내용 및 변경사항 파악불가
• 장애가 발생하여도 원인분석에 많은 시간 소요

 

가지고 있어야할 역량 : 개발/운영 노하우를 공유하여 장애 예방 및 조직 전체의 기술 역량 고취 ( slack 을 사용하는 이유가 됨 )

• 다양한 툴 사용해보기
• 원활한 소통을 위한 커뮤니케이션 능력

 

대시보드

Devops 를 통한 조직의 사일로화를 없애고 협업 문화 형성을 위해서는 팀과 원활히 소통할 수 있는

협업툴과 프로젝트 관리를 위해 대시보드의 도입이 필요하다.

 

대시보드 사용의 장점

1. 전체 개발 단계 설정
2. 개발관련핵심 정보 업데이트 ( 마감날짜, 문제점, 주요업데이트, 담당자 )
3. 회의를 통해 정보 분석 및 소통 ( 매일 정해진 시간에 대시보드를 보면서 회의) 을 하여 개발이 지체되는 원인에 대한 분석과 필요한 리소스들은 없는지 소통

이를 통해 팀간의 원활한 커뮤니케이션 가능 목표 달성 및 프로젝트 수행 능력 향상

 

 

2. CI/CD 란 ?

CI/CD

 

지속적인 통합과 배포를 통해 애플리케이션 개발 단계를 자동화하여 고객에게 보다 짧은 주기로 서비스를 제공하고 개선하는 방법

 

3가지 단계

Continuous Integration : 코드를 빌드하고 테스트하고 합친다

• build
• test
• merge

Comtinuous Delivery : 해당 리포지토리에 release 합니다

• automatically release to repository

continuous deployment : 이를 프로덕션, 즉 실제 서비스에 배포합니다

• automatically deploy to production

 

목표

지속적 통합의 핵심 목표는 버그를 신속하게 해결함에 있다.
소프트웨어 품질을 높일 수 있다.
새로운 소프트웨어 업데이트를 검증 및 릴리즈 (release) 하는데 시간을 단축할 수 있다.

 

 

2-1. CI ( continuous intergration )은 무엇인가 ?

개발 -> 통합 -> 저장 -> 빌드 -> 테스트

 

지속적 통합을 의미한다.

 

여러명의 개발자가 각각 맡은 기능을 개발을 하게 되는데 개발된 소스코드들을 하나로 통합하게 되고 단순히 코드를 합치는 것이 아닌 해당 기능이 꼭 필요한가 ?중복된 부분이 없는가 ? 를 확인후 통합 큰 프로젝트나 오픈소스 커뮤니티의 경우에는 관리자( committer )가 확인을 하고 합쳐지게 된다.

 

이 과정에서 개발자 간, 개발자와 커미터 사이에서 빈번한 커뮤니케이션이 발생 합쳐진 코드는 저장소인 소스 저장소(github, gitlab, bitbucket 등 )에 저장된다.  이후 빌드과정을 통해 실행가능한 패키지 형태 ( 실행파일 artifact ) 생성하고 실행파일의 동작 여부 점검

2-2. CD ( continuous Deployment )은 무엇인가 ?

테스트 -> 배포 -> 운영 -> 모니터링

 

지속적 배포를 의미한다.

 

지속적 배포는 실행파일들을 실제 개발 환경에서 테스트 한뒤 문제가 없으면 상용서비스에 적용하고 운영 및 모니터링하는 과정 전체를 말한다.

이 과정이 하나의 프로세스로 구현되면 개발자는 언제나 즉시 배포할 수 있다.

 

파이프 라인

 

파이프 라인이란 CI/CD 파이프 라인을 젠킨스에 젠킨스에 구현하기 위한 일련의 플러그인들의 집합이자 구성.
여러 플러그인들이 이 파이프 라인에서 용도에 맞게 사용하고 정의함으로써 파이프 라인을 통해 서비스가 배포된다.

 

파이프라인이 주는 장점
코드배포까지 좀 더 체계적으로 만드는 점과 조건을 줘서 테스트가 강제된다는 점이다
파이프라인 자체내에 테스트가 있기 때문에 테스트가 없으면 병합( merge )되지 않게 구성할 수 있다

 

 

3. DevOps 용어정리

Plan

• VoC 기반 요구관리 연계

Code

• 개발자들이 웹/로컬 IDE로 협업하여 코딩하고 - 코드리뷰를 실시

Build

• 통합 빌드를 수행하면서 코드 품질과 보안성을 점검하고 (컨테이너 기반 빌드 자동화 컨테이너 관리 )

Test

• 자동화 테스트

Release

• 릴리즈 워크 플로우에 의해 (릴리즈 관리)

Deploy

• 컨테이너 기반 배포 자동화

Operater

• 표준 운영 체제

Monitor

• 가용성 / 인시던트 관리
• SLI/SLO 관리 (sli : service level indicator (서비스 수준 척도), slo : service level objectives ( 서비스 수준 목표 )

 

4. 유연하게 인프라를 확장 축소 하는방법

클라우드 서비스에서는 자원 사용량을 모니터링하여 자동으로 서버를 증설(Scale Out)하는 Auto Scaling 기능도 있다.

 

 

5. 공부를 하여 생각해본 auto scaing 과 ArrayList 의 공통점

자바의 ArrayList:

자동 확장: ArrayList는 내부적으로 배열을 사용하여 데이터를 저장합니다. 초기 배열 크기가 부족해지면, 자동으로 더 큰 배열을 생성하고 기존 데이터를 새로운 배열로 복사합니다. 이 과정은 개발자가 명시적으로 처리할 필요 없이 자동으로 이루어집니다.
유연성: 개발자는 데이터를 추가하거나 제거하는 데 집중할 수 있으며, 배열 크기에 대해 신경 쓸 필요가 없습니다.

 

클라우드의 Auto Scaling:

자동 확장(Scale Out): 서버 자원이 부족해지면 자동으로 더 많은 인스턴스를 추가하여 애플리케이션의 성능을 유지합니다.
자동 축소(Scale In): 자원이 필요 없을 때 자동으로 인스턴스를 줄여 비용을 절감합니다.
유연성: 개발자나 운영자는 트래픽 변화에 맞춰 서버 인프라를 관리할 필요 없이, Auto Scaling 설정만으로 효율적인 자원 관리를 할 수 있습니다.

 

 

6. scale out 이란 ?

서버의 스펙을 상승으로는 한계가 있어 효율이 떨어지는 시점이 있다.
기존의 서버와 같은 사양의 서버 대수를 증가시키는 방법으로 처리 능력을 향상시키는 것을 말한다.
이 방식을 Horizontal scaling이라고도 하며 확장이 Scale Up보다 다소 유연하다.
1의 처리 능력을 가진 서버에 동일한 서버 4대를 추가하여 총 5의 처리 능력을 만드는 것이다.
서버가 여러대가 되므로 각 서버에 걸리는 부하를 균등하게 해주는 로드밸런싱이 필수적으로 동반되어야 한다.

 

 

7. TEST code 의 중요성

테스트를 하지 않고 개발을 진행한다면 개발속도도 느려질 뿐더러 검증받지 못한 코드들이 쌓일 것이다.
테스트 라 함은 어플리케이션에 배포하기 전 단계에서 코드에 대한 검증을 받고 배포하여야한다.
테스트 는 함수등 작은 단위를 테스팅하는 단위테스트, 모듈을 통합 할 때 테스트하는 통합테스트, 사용자가 서비스를 사용하는 상황을 가정해서 테스트하는 엔드 투 엔드 테스트가 대표적이다.

 

 

8. 병합 (merge)

코드간의 공집합에서 충돌이 일어난다
충돌은 대부분 일어나기에 조금 더 작은 단위로 충돌이 일어나게 하는 것이 중요하다
그렇다고 해서 너무 아토믹하게 작은 단위로 하지 않고 작은 issue 단위를 기반으로 merge를 하게 된다
issue 단위로 pr 를 보내고 해결함
코드간의 충돌을 최소화 = 잦은 최적화

 

 

9. 배포

배포는 사용자를 위한 서비스를 위한 배포뿐만 아닌 내부적으로 QA 엔지니어나, 관리자를 위한 배포, 데이터 가공을 통해서 backend 개발자들을 위한 배포들도 포함된다