[DevOps] 데브옵스 한방 정리

해당 포스팅은 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 강의 내용을 기반으로 작성했습니다.

---

DevOps 전체 구성도

어나더클래스 강의의 DevOps 전체 구성도이다.

강의에서는 Spring boot로 개발한 기본적인 백엔드 App을 사용한다.

이 App에 대한 DevOps 환경은 개발 환경, CI/CD 환경, 인프라 환경으로 나뉘고
최종적으로 쿠버네티스에서 App 실행하기 위해서는 빌드 과정과 배포 과정을 거쳐야 한다.

 

먼저 App 빌드 과정은 다음과 같다.

1. IntelliJ로 개발한 소스코드를 GitHub로 커밋하면서 통합적으로 관리하다가 CI/CD 환경에서 빌드 버튼을 누르면 GitHub에서 최신 소스코드가 다운받아진다.
2. Gradle로 소스 빌드가 실행되는데 이 때 Maven 저장소에서 필요한 라이브러리들을 다운받는다.
3. 최종적으로 Jar 파일이 생성되면서 소스 빌드가 종료된다.
4. 쿠버네티스로 App을 배포하기 위해 컨테이너 빌드를 수행해야 한다. 먼저 Docker로 컨테이너 빌드를 할 때 Docker hub에서 openjdk 베이스 이미지를 다운받는다.
5. 다음으로 받은 이미지에 Jar 파일을 넣어 빌드하면 내 App에 대한 컨테이너 이미지가 생성된다.
6. 빌드한 컨테이너 이미지를 Docker hub에 업로드한다.

빌드가 완료되면 App을 쿠버네티스에 배포하는 과정을 거쳐야 한다.

1. 배포는 kubectl 명령을 날려 쿠버네티스에 파드 생성을 요청한다.
2. 쿠버네티스가 Docker hub에서 이미지를 다운받는다.
3. 다운받은 이미지를 기반으로 컨테이너 런타임(containerd)에 컨테이너 생성을 요청한다.

위 흐름은 DevOps의 기본적이면서도 핵심적이기 때문에 익혀놓는 것이 좋다.

DevOps에서 가장 중요한 것

DevOps의 핵심은 개발을 하고, 개발한 코드를 빌드해서 실행가능한 파일로 만드는 것이다.

 

먼저 일반적인 개발 환경을 상정할 때 윈도우나 맥 os를 사용하는 개인 PC에서 개발 툴인 IntelliJ로 개발을 한다고 해보자.

openjdk를 개발 툴킷으로 지정하고 그 위에서 java와 spring framework를 사용하여 소스 코드를 작성한다.

코드를 실행하기 위해서는 만들기 위해서 openjdk로 컴파일 → gradle 빌드 과정을 거쳐 실행 파일을 만든다.

실행 파일은 openjdk의 JVM 위에서 실행되어 개발자가 App에 접근할 수 있게 된다.

 

이처럼 개발자는 개발 환경에서 코드를 작성하고 실행하여 디버깅하는 과정에서 openjdk, gradle, 실행 파일이 필요하다.

반면 인프라 환경에서는 App만 실행하면 되니까 실행 파일과 JVM을 위한 openjdk만 있으면 된다.

CI/CD 환경에서는 빌드가 목적이기 때문에 openjdk과 gradle이 필요하다. 

또한 인프라 환경으로 실행 파일을 넘겨줘야 하기 때문에 추가적인 배포 과정이 필요하다.

 

인프라 환경은 또 3가지 내부 환경으로 세분화 된다.

• 개발 환경(dev): App이 하나가 아니기 때문에 다른 App과의 문제는 없는지 확인하는 개발자 통합 테스트용
• 검증 환경(qa): 개발자가 아닌 전문 테스트 담당자용. 최대한 운영 환경과 똑같이 구성해야 한다.
• 운영 환경(prod): 이중화 구성 필수. QA 단계에서 테스트가 통과하였다고 하더라도 운영 단계에서 서버 다운같은 치명적인 문제를 대비하기 위해 이중화 구성이 필요하다. 이 때 사용한 오픈 소스가 이중화 구성이 문제없는지 확인해야 한다.

CI/CD 환경이 필요한 이유는 혼자 App을 개발하지 않아서 그렇다.

한 App을 만들 때 여러 개발자들이 코딩하기 때문에 소스 코드 통합 관리를 위해 GitHub를 사용한다.

Jenkins가 Github에서 소스 코드를 받아 빌드하고 배포하는 역할을 하는데, 이런 Jenkins 같은 CI/CD 툴이 설치되어있는 서버가 CI/CD 환경이 된다.

 

먼저 컨테이너 도입 이전의 기존 구성은 다음과 같다.

openjdk과 gradle로 빌드를 위해 구성을 한다. 빌드를 하면 jar파일이 생성된다.

인프라 환경에는 개발 환경과 운영 환경이 따로 존재한다. 예를 들어 redhat 계열의 linux는 라이선스 때문에 두 환경의 운영 체제가 다를 수 있다. 개발 환경은 보통 무료 OS를 사용하기 때문이다. 두 환경에 모두 openjdk 설정을 한다.

CI/CD 서버에서 빌드를 해서 생성된 jar 파일을 인프라 환경으로 복사한다.

 

반면 컨테이너 도입 후 구성은 다음과 같다.

소스 빌드, 컨테이너 빌드를 해서 도커 허브에 이미지를 올린다.

배포를 수행하면 인프라 환경의 쿠버네티스가 이미지를 다운받고 각 환경에서 파드를 실행하게 된다.

각 파드 내에는 기존 구성과 마찬가지로 openjdk와 실행 파일이 존재한다.

결국 중요한 건 개발과 빌드에서 실행 파일을 만드는 과정이 항상 존재한다는 사실이 핵심이다.

 

DevOps를 구성하는 오픈소스들

DevOps는 개발부터 운영까지의 원활한 흐름을 만드는 것이다. 그 과정에서 가장 중요한 것이 CI/CD이다.

CI는 통합된 소스를 빌드, 테스트를 자동화하는 기능을 만드는 것. CD는 배포를 자동화하는 기능을 만드는 것이다.

이 DevOps 과정을 세분화하면 총 8단계로 나눌 수 있다. 마치 네트워크의 OSI 모형같은 느낌이다.

이 8단계를 최대한 실무적으로 설명하는 좋은 방법은 각 단계의 대표적인 오픈소스를 가지고 얘기하는 것이다.

1. 계획: 개발 일정 공유, 이슈 사항 등록, 협업을 위한 커뮤니케이션. DevOps의 각 요소들을 slack 같은 툴에 notify를 등록하면 중요 이슈사항을 알림으로 받아볼 수 있다.
2. 개발: 개발 환경에서 코드 개발 시 로직 테스트, 코드 패턴에 대한 버그 체크, 개발자 간의 코딩 스타일 맞추기.
3. 빌드: 소스 코드 빌드, 컨테이너 빌드. CI/CD 환경에서 빌드를 하는 역할.
4. 테스트: 기능, 성능, 커버리지 테스트가 존재. 빌드 단계에서 자동으로 테스트를 한번 더 실행한다. 이후 커버리지 테스트를 통해 테스트 결과가 App 전체 로직의 커버리지 정도를 알 수 있음.
5. 릴리즈: 배포 가능한 패키지를 만드는 과정. 도커 파일과 쿠버네티스 배포를 위한 yaml 파일들을 작성한다. 해당 파일들도 변경 관리가 되어야 하기 때문에 Git 저장소에 업로드 해야한다.
6. 배포: 패키지를 쿠버네티스에 배포해주는 툴.
7. 운영: 실제 운영환경을 보강하는 요소와 툴. 네트워크 트래픽 관리, 데이터베이스 역할을 하며 인프라 환경에 설치한다.
8. 모니터링: 인프라 환경에서 리소스 사용량, App 로그, 트래픽 흐름을 모니터링한다.

DevOps에 엮인 IT직군들 및 그외 다른 Ops들

DevOps 과정에서 각 IT 직군에 대해 연차별로 갖추면 좋을 능력들.

• 개발자
  • ~2년차: 현재 업무팀에서 사용하는 개발환경 적응. 개발 범위가 주어졌을 때 처리하는 퍼포먼스 늘리기.
  • ~4년차: IntelliJ 설정부터 GitHub까지 장애나 변경점이 생기면 스스로 찾아서 처리할 수 있는 실력 키우기.
  • ~6년차: 개발환경 툴들의 초기 설정을 본인이 설정하고 리드. CI 환경의 테스트 자동화까지.
  • ~8년차: 새로운 트렌트를 리드. 기존 환경을 컨테이너로 바꿀 때 내 App을 컨테이너로 만들어서 운영환경에 배포하는 과정을 자동화하기.
• 데브옵스 엔지니어
  • ~2년차:  현재 팀에 구성된 CI/CD 흐름을 빨리 적응하고 비슷한 구성의 파이프라인을 추가할 경우 스스로 할 수 있는 실력.
  • ~4년차: 운영 환경에 설치되는 툴이나 개발 환경의 GitHub까지 담당.
  • ~6년차: 개발을 고려한 모니터링 시스템 설치까지 및 구성.
• 운영자
  • ~4년차: 현재 만들어져 있는 운영 환경들을 모니터링하면서 구성 익히기.
  • ~6년차: 릴리즈와 배포하는 과정까지 어떻게 구성되는지 알고, 현재 배포 구성이 운영환경에 문제를 일으키지는 않는지 파악할 수 있어야 한다.
  • ~8년차: 파이프라인의 시작인 빌드부터 운영 및 배포까지 주도적으로 구성을 업데이트할 수 있어야 함. 이러한 실력자를 사이트 신뢰성 엔지니어(SRE)라고 한다. CI/CD 까지 관여하는 운영자라고 보면 된다.

• GitOps: DevOps 파이프라인을 Git하나로 통일. 이슈/협업관리, 빌드/테스트/배포까지 모두 제공. Github Actions는 테스트와 빌드까지 가능해 J enkins를 대체할 수 있다.
• DevSecOps: 빠른 배포와 보안을 동시에 잡기. DevOps 덕분에 개발 이후에 배포까지 굉장히 빨라졌는데, 이 과정에서 보안적인 측면에서 결함이 없는지 체크할 수 있다. 소스 코드, 컨테이너 이미지의 , 쿠버네티스 클러스터의 보안 검사를 수행한다.
• MLOps: 이 분야의 핵심은 데이터 분석가. 데이터 분석 부터 AI 모델 서빙까지의 파이프라인을 담당한다.
• LLMOps: ChatGPT와 같은 LLM(Large Language Model) 방대한 규모의 머신러닝에 특화된 파이프라인.
• FinOps: 클라우드 환경 비용 절감에 포커스를 둔 파이프라인을 만드는 것.