Search
Duplicate

#2 서비스인프라개발팀 : K8S 인프라 CI/CD

이미지
1.png
기술 Stack
Gitops
Gitlab CI
Kubernetes
Helm
Rancher

K8S 인프라 CI/CD

안녕하세요, 사람인HR Tech Sourcer 이승빈입니다 이번 포스팅에서는 2020년에 도입되어 운영하고 있는 kubernetes 인프라에 애플리케이션을 빌드하고 배포하는 사람인HR의 프로세스 운영 기술을 소개해드리려 합니다.
CI/CD
청소 로봇을 운영하기 위해 팀에서 조를 나누어 분업하고 있다고 가정해봅시다. 각 조는 팔, 다리, 몸통별로 역할을 분담하여 부위별로 개발을 진행합니다. 개발을 진행하면서 로봇이 정상적으로 작동하는지 주기적으로 부품을 조합하고 작동을 시험해야 합니다. 이 과정에서 팀원들은 언제 각 조에서 개발하는 부품들을 합쳐서 작동을 시험해볼지 기간을 조정하여 협업하는 환경을 구축해야 합니다.
예를 들어 각 조별로 담당해야 하는 개발 작업이 총 10단계라고 한다면, 개발의 어느 단계에서 모든 조가 모여 부품들을 조합해 정상적으로 작동이 되는지 확인할지 시기를 정해야 한다는 이야기입니다.
Case 1) 각 조마다 역할이 나뉘어져 있으니 믿고 맡기고 작동하는지는 한번에 확인하는 방식
각 조별로 역할이 나뉘어져 있으니, 개발 단계에서의 업무는 각자 진행 하고, 모든 부품들이 합쳐졌을 때 제대로 로봇이 작동하는지 확인은 마지막에 한번에 확인하는 방법이 있습니다. 매 단계마다 부품을 조합해볼 필요가 없기 때문에 개발 단계에서 집중적으로 빠른 작업이 가능하다는 큰 장점이 있는 방법입니다.
하지만, 부품을 조합했을 때, 로봇이 작동하지 않는다면 어떻게 해야 할까요? 오랜 기간 동안 개발을 진행한 후 조합한 것이므로 추가된 기능들이 많을 것이고 작동하지 않는 이유를 찾아내는 과정 역시 매우 복잡할 것입니다. 어쩌면 개발하는 시간보다 문제점을 찾아내는 시간이 더 오래 걸릴지 모른다는 단점이 있는 방법입니다.
Case 2) 중간 점검은 자주, 짧은 간격으로 확인하는 방식
그렇다면, 중간 점검을 자주 자주 짧은 간격으로 두면 위 문제는 바로 해결된다고 할 수 있습니다. 하지만 반대로 중간 점검 기간의 텀을 짧게 잡으면, 잦은 횟수로 부품을 통합하고 작동을 시험해야 하는 불편함이 생기게 됩니다. 시간의 효율성이 1번의 케이스보다 매우 떨어진다는 새로운 문제에 직면합니다. 이 시간은 중간 점점 기간의 텀을 길게 설정했을 때 문제점을 찾는 시간과 비슷하게 소요되거나 심지어 그 이상이 될 수도 있습니다.
개발 기간을 어떻게 설정하든 문제점이 발생한다는 불편한 상황을 뒤로 하고 새롭게 수정된 부품들이 조합되어 문제 없이 작동한다고 해도 청소 로봇을 정해진 영역으로 다시 투입해야 한다는 개발 이외의 새로운 노동이 추가됩니다. 개발이 이루어질 때마다 작업장에 로봇을 가져와 개발하고 다시 각 영역으로 투입하는 일이란 여간 귀찮은 작업이 아닐 수 없습니다.
개발자가 개발에만 몰두할 방법은 없는 걸까요? 오류를 추적하거나 부품을 조합하고 시험해보는 과정을 개선할 수는 없는 걸까요? 로봇이 알아서 각자의 영역으로 돌아갈 순 없는 걸까요?
이때 등장하는 개념이 바로 Continuous Integration(CI)Continuous Delivery 혹은 Continuous Deployment(CD)입니다.
CI : 지속적 통합이라는 의미로 위 과정에서 개발 기간 동안 기능을 변경하거나 추가했을 때, 부품을 조합하고 시험해보는 과정을 자동화하는 것에 해당합니다. 수정된 부품을 검증하는 시간이 줄어들기 때문에 개발에 편의성을 높여주게 됩니다
CD : 지속적인 제공 혹은 배포라는 의미로 위 과정에서 새롭게 보완된 로봇을 각 영역에 배포하는 과정을 자동화하는 것에 해당합니다. 별도의 수작업 없이 배포를 자동화하여 서비스를 빠르게 개선하고 개발에 더욱 신경 쓸 수 있게 됩니다.
Gitlab CI
사람인HR에서는 CI 툴로 gitlab CI를 사용하고 있습니다. gitlab 프로젝트 저장소에 커밋이나 푸시와 같은 수정 사항이 발생하면 gitlab-ci.yml이란 파일에 작성된 과정대로 CI가 수행됩니다. 사전에 Docker 이미지 빌드 과정을 수행하기 위한 Dockerfile 작성이 이루어져 있어야 합니다. 수정한 소스 코드를 컴파일하고 빌드하면 Docker 이미지를 생성하여 빌드하고 저장소에 푸시한 후 자동으로 업데이트합니다.
Kubernetes
kubernetes란 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화를 도와주는 컨테이너 오케스트레이션 Tool입니다. 과거 물리 서버에서 두 개 이상의 애플리케이션을 실행할 경우 특정 애플리케이션이 자원을 전부 차지하는 등 리소스 할당 이슈가 있었고 여러 물리 서버를 실행하는 경우 자원이 충분히 활용되지 않거나 물리 서버를 유지하는 데 큰 비용이 드는 단점이 있었습니다. 이에 대한 해결책으로 가상머신이 도입되었습니다. 가상머신은 소프트웨어를 사용하여 Host OS에서 작동하는 단일 컴퓨터 하드웨어 요소를 다수의 가상 컴퓨터들로 분할하여 사용하는 방법입니다. 실제 컴퓨터 하드웨어의 일부에서만 실행되면서 자체적으로 Guest OS를 두어 각각 독립적인 컴퓨터로써 작동하여 자원을 효율적으로 사용할 수 있게 되었습니다. 하지만 Guest OS부터 가상장치, Host OS, 물리 장치에 이르는 여러 단계의 파이프라인으로 구성되어 있어 속도가 저하되는 또 다른 이슈가 발생했습니다.
그렇게 해서 등장한 것이 바로 컨테이너입니다. 컨테이너란 가상화와 유사하지만, Guest OS를 두어 독립적인 컴퓨터로써 분리하여 사용할 수 있는 자원을 분할하는 것이 아닌 운영체제를 공유하면서 프로세스 자체에 사용할 수 있는 자원을 분할하여 독립적으로 애플리케이션을 실행할 수 있도록 도와주는 기술입니다. 그렇기 때문에 가상화보다는 가볍다는 장점을 가지게 되었고 속도 저하와 관련된 이슈를 해결할 수 있게 되었습니다. 컨테이너를 다루는 도구 중 가장 유명한 것이 Docker이고 이러한 도구를 통해 컨테이너를 오케스트레이션 하는 것이 바로 kubernetes입니다.
Helm
kubernetes에 동일한 애플리케이션을 여러 번 배포하는 상황은 빈번하게 발생합니다. 애플리케이션을 배포하기 위해서 컨테이너 배포뿐 아니라 다양한 리소스들을 같이 배포해야 하는데 동일한 애플리케이션을 배포할 때마다 리소스들을 다시 작성해 주는 것은 매우 불편한 상황이 아닐 수 없습니다. 게다가 리소스들은 가끔 수정이 필요한 작은 부분을 제외하고는 보통 그 정의가 동일하기 때문에 같은 내용들을 한 번에 한 번만 변경할 수 있도록 도와주면서 필요한 일부 항목은 변경이 가능하도록 해주는 시스템이 요구됩니다.
Helm은 kubernetes용 패키지 매니지먼트 도구로 바로 위와 같은 역할을 가능하게 하는 존재입니다. Helm에서는 기본적으로 리소스들의 yaml 포맷 파일을 관리하는데 이러한 yaml파일들의 집합을 차트라 하고 이 차트를 관리하게 됩니다.
Rancher
Rancher란 kubernetes를 관리하는 Tool입니다. kubernetes의 여러 리소스를 관리하기 위한 집합체인 kubernetes 클러스터를 쉽게 생성하고 관리할 뿐 아니라 운영에 필요한 모니터링, 보안 관련 기능을 Web UI 기반으로 쉽게 설치할 수 있는 관리 플랫폼입니다. 사용자 UI를 통해 Rancher의 기능 중 Helm 기반의 Chart를 검색하고 실행할 수 있는 기능을 이용하여 클릭하는 것만으로 간단하게 애플리케이션을 배포 및 실행할 수 있습니다.
GitOps
gitops란 git을 사용하는 프로젝트에서 DevOps를 구현하는 것을 의미합니다. DevOps에 대한 확장으로 인프라를 코드로 취급하여 애플리케이션과 그 기반 인프라를 관리합니다. git 저장소의 코드와 Production 환경이 일치하도록 자동화된 프로세스를 구축하는데 애플리케이션을 배포하거나 업데이트할 때 코드를 수정하여 자동화 프로세스를 통해 일관된 환경을 유지할 수 있도록 하는 방식입니다. gitops를 통하여 두 개의 git 저장소를 관리하는데 하나는 애플리케이션 자체의 소스 코드를 저장하는 code 저장소와 kubernetes 배포용 매니페스트를 저장하는 config 저장소입니다.
Flow
1.
개발자가 git에 애플리케이션 코드를 푸시
2.
푸시된 소스에 대해 gitLab CI 프로세스가 통합 빌드 진행
3.
결과물로써 컨테이너 이미지 생성되고 사내 Docker 저장소에 이미지 푸시
4.
배포 작업서에 변경 사항 업데이트
5.
배포방식(자동 혹은 수동)에 따라 kubernetes 인프라에 Deploy 및 Upgrade
이번 포스팅에서는 사람인HR의 gitops를 기반으로 gitlab CI를 이용한 CI와 Helm, Rancher를 이용한 kubernetes 인프라 CD 자동화 프로세스 운영 방식을 살펴보았습니다. 쿠버네티스는 계속해서 컨테이너 기반 애플리케이션의 표준 플랫폼으로 자리 잡아가고 있는 만큼 개발자분들의 경우 관련된 기술 스택을 확장하신다면 도움이 되지 않을까 생각합니다.
다음 포스팅에서는 Elastic Stack을 사용한 관제 시스템을 소개해드리겠습니다. 사람인HR의 기술에 대한 궁금증이나 개발 큐레이션에 대한 피드백은 언제든지 환영하고 있습니다. 앞으로도 사람인HR 피플팀의 개발 큐레이션 많은 관심 부탁드립니다.
(사람인HR Tech Sourcer 이승빈 E-mail : lsb5368@saramin.co.kr)

출처 및 참고 사이트