3일에 걸쳐 위와 같은 CI/CD 프로세스 구조를 개발했다. 회사에 취업하면 이미 설정되어 있거나 관련해서 작업한다고 해도 중간 결과물에 대한 작업이기 때문에 아예 밑바닥 부터 처음 만들어 보았다.
처음 하다보니 어떤 CI/CD 툴을 사용해야 할지, 사용은 어떻게 해야하고 또 방법은 몇개가 있는지 고려해야 할 점은 뭔지 전부 분석하는게 매우 어려웠다.
나는 결국 가장 시장 점유율이 높은 AWS 클라우드 컴퓨팅 서비스와 젠킨스를 사용하게 되었다.
제일 어려웠던 점은 AWS의 경우, EC2에 웹 애플리케이션을 올린다고 해도 패킷통과를 위한 AWS 네트워킹에 대한 이해가 필요하고 또 설정 방법을 알아야만 했다.
어떻게든 패킷통과까지 원활하게 되었으나 가용 영역, 리전, VPC, 서브넷,ENI, 보안그룹, 라우팅 테이블, ACL 등의 네트워크 원리 및 보안 요소에 대해서 포트를 단지 열어줬을 뿐.. 그것이 완벽하게 보안을 갖추었는지 파악하기에는 나의 네트워크 실력이 너무나 부족하다는 것을 알았다. (책 3권으로는 어림도 없었다.. 경험이 중요한 것 같다.)
또한 대용량 트래픽에 대비한 스케일 아웃(AWS 오토 스케일링), 스케일 아웃을 위한 로드 밸런싱, 로드 밸런싱으로 인한 세션 불일치 문제 (스티키 세션 혹은 세션 클러스터링으로 해결), 서비스 배포 시 서비스 불가 방지를 위한 무중단 배포 개념에 대한 이해 및 사용을 위해 AWS Elastic Beanstalk 라는 리소스를 사용하게 되었는데
이 리소스를 이해하는데도 꽤 시간이 걸리며 망할놈의 AWS 문서를 읽어봐도 이해하기가 쉽지가 않았다.
딱 4년차 개발자가 된 시점이었고 회사에서 서비스를 혼자 맡아 본 경험이 있어, 이게 이렇게 돌지 하고 알아서 가능했지(완벽하게 아는것은 아닌....) 경험이 없는 상태에서 처음부터 구조를 잡아야 한다면 정말로 힘들 것 같다. 괜히 DevOps/SRE라는 직업이 있는 것이 아니다.
백엔드 개발자라고 하여, 애플리케이션의 비지니스 로직과 언어 및 WAS, 관련 프레임워크, 데이터베이스 등에 대해 이해하려만 노력했는데 연차가 쌓일 수록 인프라 및 네트워크에 대해 이해가 없으면 결국 도태될 것이라고 생각이 되었다.
나는 사이드 프로젝트를 국비 학원 졸업 후, 단 한번도 만들어 본적이 없었는데 이번 경험을 통해 그래도 어느 정도는(0.01%?) 성장 할 수 있는 계기가 되었다.
위의 영상이 가장 개념을 잘 설명하고 있다.
CI/CD 란? 애플리케이션 개발 단계 부터 배포 떄 까지 자동화를 통해서 사용자에게 빈번히 배포를 할 수 있게 만드는 것
CI (Continuous Integration, 지속적인 통합)
버그 수정이나 개발 기능들이 메인 리포지터리에 테스트 되고 빌드되서 머지되는 것을 말한다.
다음과 같은 점이 고려되어야 한다.
개발 생산성 향상 및 문제점이 빠르게 발견 되고 수정 가능하다. (작은 단위의 문제점 확인 가능)
CD (Continuous Delivery or Continuous Deployment, 지속적인 제공, 배포)
즉 위의 다이어그램 이미지를 보았을 때는
Continuous Integration 은 1번 ~ 3번
Continuous Delivery 는 4번 ~ 5번
Continuous Deployment 는 6번 ~ 7번이라고 생각을 하면 이해가 쉬울 수 있겠다.