[DevOps] CI(지속적인 통합, Continuous Intergration)

1. 지속적인 통합 메커니즘

- CI는 개발자가 체크인하는 경우 다음 방법 중 하나로 검증하는 소프트웨어 엔지니어링 실천방법이다.

 1) Pull Mechanism : 예정된 시간에 자동화된 빌드 작업을 실행한다.

 2) Push Mechanism : 변경 사항이 저장소에 저장되는 경우 자동화된 빌드가 실행된다.

- 이 단계에서는 소스 코드 저장소에서 이용 가능한 최신 변경사항에 대한 단위 테스트의 실행이 뒤따른다.

- 빌드-테스트-통보 : 돌고 도는 파이프라인이 구성된다. 빌드 실행 결과에 기반한 빠른 피드백이 핵심이다.

- CI의 필요성 : 개발의 초기단계에서 보완하고 고칠 수 있는 파이프라인 생성, 같은 이슈가 매우 오랜 기간 후에 발생하고 의존성과 복잡성이 증가했을 때 발생한다면, 고치기 어려워진다.

- Jenkins, GitLabCI 쓰자. 

 

2. 모범사례

- Git, SVN 같은 코드 저장소 유지

- 서드파티, 빌드스크립트, 다른 산출물 등을 코드 저장소에 체크인

- 코드 저장소에서 완전히 빌드를 실행. Clean build를 사용한다.

- Maven, Ant등을 사용해 빌드를 자동화한다. (Java의 경우이고, JS의 경우에는 npm, yarn, webpack, gulp 등이 있다.)

- 빌드 자체적인 테스팅을 한다. 단위테스트를 만든다.

- 기능마다 최소한 하루에 한 번 모든 변경 사항을 커밋한다.

- 모든 커밋은 변경 사항의 무결성을 검증하기 위해 빌드되어야 한다.

- 사용자를 인증하고 액세스 제어를 강제화 한다. (인증 및 권한 부여)

- 빌드 이름에 알파벳 문자를 사용하고 기호문자를 피한다.

- 다양한 빌드작업에 대한 균일성을 유지하고 더 나은 방법으로 작업을 관리한다.

- 문제해결 시 유용한 아카이브된 빌드와 다른 산출물을 포함하고 있는 CI 서버의 home 디렉터리를 정기적으로 백업한다.

- CI 서버에 사용 가능한 디스크 공간이 충분한지 확인한다.

- 여러 작업이 동시에 시작하도록 예약하지 않거나, 특정 작업이 슬레이브 인스턴스에 할당해 여러 빌드 작업이 동시에 실행할 수 있는 마스터-슬레이브 개념을 이용한다,

- 프로젝트나 앱 특정 이해당사자에 대해 이메일, SMS, 트위터 통보 등을 설정한다.

- 커뮤니티 플러그인의 사용이 권장된다.

 

3. 클라우드컴퓨팅

클라우드 컴퓨팅

- 클라우드컴퓨팅 서비스의 주요 모델 (관리와 사용자 책임에 따른 분류)

1. IaaS (Infrastructure as a Service):
IaaS는 가상화된 컴퓨팅 리소스를 제공하는 클라우드 기반 서비스입니다.
사용자는 네트워크, 가상 머신, 스토리지, 로드 밸런서 등의 기본 인프라를 제공받으며, 운영 체제와 애플리케이션 스택에 대한 관리 책임이 사용자에게 있습니다.
예시: Amazon Web Services (AWS) EC2, Google Compute Engine (GCE), Microsoft Azure Virtual Machines
사용자 책임: 운영 체제, 미들웨어, 런타임, 데이터, 애플리케이션
클라우드 제공자 책임: 가상화, 서버, 스토리지, 네트워킹

2. PaaS (Platform as a Service):
PaaS는 IaaS를 기반으로 하며, 개발, 테스트, 배포, 호스팅 및 유지 관리를 위한 플랫폼을 제공합니다.
사용자는 운영 체제, 미들웨어, 런타임 등을 관리할 필요 없이 애플리케이션 개발에만 집중할 수 있습니다.
예시: Heroku, Google App Engine, Microsoft Azure App Service
사용자 책임: 데이터, 애플리케이션
클라우드 제공자 책임: 운영 체제, 미들웨어, 런타임, 가상화, 서버, 스토리지, 네트워킹

3. SaaS (Software as a Service):
SaaS는 클라우드에서 실행되는 완전한 애플리케이션을 제공하는 서비스입니다.
사용자는 애플리케이션을 사용할 수 있는 웹 브라우저만 있으면 됩니다.
SaaS 제공자가 모든 것을 관리하며, 사용자는 소프트웨어를 사용하는 데만 집중할 수 있습니다.
예시: Google Workspace, Salesforce, Microsoft Office 365
사용자 책임: 사용자 데이터의 관리 및 보안
클라우드 제공자 책임: 애플리케이션, 데이터, 런타임, 미들웨어, 운영 체제, 가상화, 서버, 스토리지, 네트워킹

세 가지 서비스 모델의 차이를 요약하면 다음과 같습니다:

IaaS:
가장 낮은 수준의 추상화를 제공합니다.사용자는 가상 머신, 스토리지, 네트워크 등의 인프라를 관리합니다.사용자는 운영 체제, 미들웨어, 런타임 등을 선택하고 설치할 책임이 있습니다.비교적 많은 유연성과 제어를 제공하지만, 관리 부담이 더 큽니다.

PaaS:
중간 수준의 추상화를 제공합니다.사용자는 애플리케이션 개발, 배포, 관리에만 집중할 수 있습니다.클라우드 제공자는 런타임, 미들웨어, 운영 체제 등의 관리를 담당합니다.개발 및 배포의 효율성이 향상되지만, 플랫폼의 제약 사항으로 인해 제어력이 상대적으로 떨어집니다.

SaaS:
가장 높은 수준의 추상화를 제공합니다.사용자는 완전한 소프트웨어 애플리케이션을 사용합니다.클라우드 제공자는 애플리케이션, 인프라, 운영 체제 등의 모든 것을 관리합니다.사용자는 소프트웨어를 사용하는 데만 집중하며, 거의 관리 부담이 없습니다. 하지만, 소프트웨어의 사용 및 구성에 대한 제어력이 제한됩니다.
어떤 서비스 모델을 선택할지는 프로젝트의 요구사항, 팀의 역량 및 선호도, 시간 및 비용 투자 등을 고려하여 결정해야 합니다. 각 모델은 특정 시나리오와 요구사항에 더 적합할 수 있으므로, 사용 사례를 분석하여 가장 적합한 클라우드 서비스 모델을 선택하세요.

- 클라우드 컴퓨팅은 앱의 가용성 측면에서 다양한 기회를 열었다.

- 클라우드 배포 모델의 종류

  1) 공용 클라우드 : 인프라스트럭쳐는 공용으로 이용이 가능

  2) 전용 클라우드 : 인프라스트럭쳐는 단일 조직을 위해 운영됨

  3) 커뮤니티 클라우드 : 인프라스트럭쳐는 공유된 관심사항을 갖는 특정 커뮤니티에 의해 공유된다

  4) 하이브리드 클라우드 : 인프라스트럭쳐는 두 개 이상의 클라우드 모델로 구성된다.

 

4. 구성 관리(Configuration Management, CM)

- 구성관리는 시스템, 더 구체적으로는 서버 런타임 환경에서의 변경사항을 관리한다.

- 구성관리는 특정 노드나 서버 상태와 관련된 세부 정보의 추적, 버전 유지에 관한 내용이다.

- 시장에는 셰프, 퍼펫, 앤서블, 솔트 같이 있기 있는 구성 관리 도구가 많다.

 

5. 지속적인 전달/배포

- 지속적인 전달과 배포에는 상호교환적으로 자주 사용이 된다.

- 전달은 모든 환경에서 자동화된 방식으로 배포하는 프로세스이며, 품질 향상을 위해 지속적인 피드백을 제공한다.

- 배포는 프로덕션 환경으로 최신 변경사항을 갖는 앱의 배포에 관한 것이다.

- 즉, 지속적인배포는 지속적인 전달을 의미하지만, 반대는 아니다. 

- 지속적인 전달은 애자일 기간의 스프린트 이후의 점진적인 출시 때문에 중요하다.

- 개발부터 테스팅까지 기능이 준비된 앱의 배포를 위해 요구사항이나 해석의 변경으로 인해 스프린트에서 여러 번의 반복이 포함될 수 있다.

- 그러므로 자동화가 권장된다.

- 모든 환경에 대해 인프라와 런타임 환경 생성을 위해서는 스크립트가 유용하다.

- 자동화 스크립트는 환경에 기반한 구성 파일을 사용할 수 있으며, 자원을 생성해 애플리케이션으로 배포할 수 있다.

 

6. 지속적인 전달의 모범사례

- 계획 : 대상 환경에 앱을 배포하기 위해 하나의 커밋만 필요한 상황을 고려하라. 컴파일, TDD, 검증, 통보, 인스턴스 프로비저닝, 런타임 환경 설정, 배포가 포함되어야 한다. 자동화를 위해 반복적인, 어려운, 수동작업을 고려해야 한다.

- 유사 프로덕션환경에서 버그 수정을 개발하고 테스트한다. (스테이징 서버와 관련된 사항이다.)

- 개발 환경과 테스트환경으로 자주 배포한다.

 

7. 지속적인 모니터링

- 전체적인 전달 파이프라인의 근간이며, 오픈소스 모니터링 도구는 아이스크림 위의 토핑과 같다.

- 세심하게 구현된 계획이어야 하며, 지속적인 전달/배포를 위한 지속적인 통합에 대한 모니터링 실천 방법을 고려해야 한다.

- CI -> 클라우드 프로비저닝 -> 구성관리 -> CD(Delivery) -> CD(Deploy)

- 다양한 상황에서의 모니터링을 생각할 수 있다.

   1) 앱 모니터링 : 응답시간, 서비스 성능, DB

   2) 플랫폼 모니터링 : NoSQL, 메시징, 메모리 캐싱

   3) 로그 모니터링 : 로그 분석

   4) 인프라스트럭쳐 모니터링 : 서버, 스토리지, 네트워크

- 기획 단계에서의 적절한 모니터링 전략을 갖고 있어야 한다.

 

8. 지속적인 피드백

- DevOps 문화에서 중요한 마지막 구성요소이다.

- 폭포수 모델에서 피드백 주기는 매우 길다.

- 애자일이나 데브옵스 문화에서는 작은 구현 단계의 결과를 확인하므로, 더 짧은 주기의 피드백이 주된 차이점을 만든다.

 

 

 

다음 시간에는 이러한 개념들을 직접 구현할 수 있는 툴들이 어떤 것이 있는지 배워본다.