현재 진행 중인 팀 몬스테라의 프로젝트 CS Broker는 CI/CD를 위하여 Github Actions를 선택하기로 하였습니다.
왜 Github Actions를 선택했고, 어떠한 방식으로 CI/CD를 구성 하였는지 알아보겠습니다.
주의! 현재 이 글에서는 간단한 인프라 구성을 언급하기만 하며 ALB, NLB, VPC와 같은 상세 네트워크 구성등을 설명하고 있지 않습니다. 그러한 내용은 추후 포스팅 예정이니 참고해주세요!
왜 Github Actions 였을까요?
일단 가장 큰 이유는 익숙함과 간편함이였습니다.
-
팀 내에 Github Actions를 비교적 오래 사용해 본 사람이 있었습니다.
- 이미 익숙한 기술이기에 비교적 쉽게 CI/CD를 구축할 수 있을 것이다라는 믿음이 있었습니다.
- 익숙한 기술을 사용해보지 않은 팀원에게 설명하는 것이, 모두 모르는 새로운 기술을 선택하는 것보다 시간적 비용이 적게 들 것이라는 판단을 했습였다.
- 실제로, 간단한 설명을 통해 팀원이 스스로 응용 할 수 있었습니다.
-
marketplace에 미리 정의된 여러 Action을 yml 파일을 통해 간단히 사용할 수 있습니다
- Github Action은 현재 기준으로 14,000 여개의 Action이 marketplace에 등록되어있습니다.
- 이러한 미리 정의된 Action은 우리의 시간적 비용을 줄여주고, 쉽게 도입할 수 있을 것이라는 판단을 할 수 있게 해주었습니다.
CI/CD
여러 사람이 협업하는 과정에서 CI는 필수적인 과정이며, 애자일 프로세스를 도입하여 개발을 진행하는 우리팀은 빠르고 간편한 배포 과정이 필요합니다.
이러한 것을 위해 CI/CD 도입은 필수적이였고, 그에 따라 위에서 언급한 Github Actions를 통해 CI/CD를 구축하게 되었습니다.
먼저, CI/CD란?
CI/CD는 애플리케이션의 배포 및 통합을 자동화하는 방법입니다.
옛날에는, CI/CD라는 개념이 존재하지않았고 그로인해 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제인 Integration Hell이라는 문제가 발생했었습니다.
이것을 해결하기 위해 CI/CD라는 방법이 나왔고, 이것을 하나씩 알아보겠습니다.
CI
CI는 Continuous Integration ( 지속적 통합 )을 뜻합니다.
CI는 말그대로, 코드의 통합을 지속적으로 자동화하여 진행하고 이를 통해 코드가 충돌할 수 있는 문제를 해결해줄 수 있습니다.
CI는 단순히 코드의 변경사항을 통합하는 것만을 의미하지 않습니다.
테스트를 자동화하고, 빌드하며 레포지토리에 통합하는 것까지 의미합니다.
이를 통해 자동으로 코드가 통합되며, 수동으로 통합되는 상황을 제거하여 개발자들이 개발에만 집중할 수 있게 해준다는 장점이 있습니다.
CD
CD는 Continous Deployment ( 지속적 배포 ) 혹은 Continous Delivery ( 지속적 제공 ) 을 의미합니다.
Continous Delivery
Continous Delivery ( 지속적 제공 )은 유효한 코드를 레포지토리에 자동으로 릴리즈하는 과정을 의미합니다.
CI를 통해 통합된 코드를 레포지토리까지 릴리즈하는 과정이라고 생각하면 됩니다.
Continous Deployment
Continous Deployment ( 지속적 배포 )는 유효한 코드를 레포지토레에 자동으로 릴리즈하고, 프로덕션 환경에까지 릴리즈하는 과정을 의미합니다.
즉 Continous Delivery는 레포지토리에 릴리즈하고 수동으로 프로덕션에 배포를 진행하며,
Continous Deployment는 프로덕션에 배포까지 자동화하는 개념이라고 생각하면 됩니다.
프로젝트 인프라
백엔드
AI
일단, 백엔드와 AI서버는 둘 다 하나의 서비스를 구성하여 서버로서의 역할을 하기 때문에 거의 유사하게 가져가도 된다고 생각했기 때문에 위와 같은 유사한 구성을 가져가기로 했습니다.
일단 Github Action을 통해 CI/CD 플로우를 구성한 뒤, AWS 환경에서 EC2와 AutoScaling Group을 통해 배포를 하도록하였고 EC2에 올라갈 컨테이너는 ECR에 이미지를 미리 올려 두어 배포를 진행할 수 있도록 설정하였습니다.
이렇게 배포된 컨테이너들의 로그는 ELK 스택을 통해 로그를 수집할 수 있도록 하였습니다.
( ELK와 EFK를 많이 고민하였는데, 그 고민의 과정은 추후 포스팅으로 풀어보겠습니다. )
추가로 MariaDB와 Elasticache는 HA ( High Availability ) 를 위하여 Multi AZ 혹은 Read Replica를 고려해봤지만, MVP를 만드는 단계에서는 너무 큰 자원소모, 어플리케이션 사이드 설정에서 시간 소모 그리고 트랜잭션 관리에서 어려움을 겪을 수 있다고 판단하여 보류하기로 하였습니다.
프론트엔드
프론트엔드는 S3-CloudFront-Route53을 통하여 배포를 진행하기로 하였습니다.
처음에는 Next.js를 통한 SSR을 구성할 계획도 있어, 이것이 아닌 다른 방법을 찾아봤지만 결국 CSR를 선택했기 때문에 정적 페이지를 호스팅할 수 있는 S3 + CloudFront + Route53 을 선택하게 되었습니다.
프론트엔드도 마찬가지로, 그림을 보면 알겠지만 Github Action을 통해 CI/CD 플로우를 구성하였습니다.
Gitlab 미러링은 뭘까요?
이 프로젝트는 소프트웨어 마에스트로에서 진행하는 프로젝트이므로, 원칙적으로는 Gitlab에서 관리하는 것을 권장합니다.
하지만, Gitlab의 비공개 저장소에서 관리를 하게 되면 우리의 커밋 이력 및 PR등을 공개하지 못한다는 단점이 있었습니다. 또한, 소프트웨어 마에스트로의 Gitlab은 여러 다른 앱과의 통합이 어렵다는 단점이 있어 Gitlab을 주 저장소로 사용하는 것을 포기하였습니다.
그러다 생각한 것이, Github에 올리는 커밋을 자동으로 mirroring 해주는 Github Action을 적용하여 코드를 관리하는 것이였습니다.
이를 통해, 익숙한 Github과 공개 저장소라는 장점을 가져가면서 Gitlab도 함께 사용하는 이점까지 얻을 수 있었습니다.
마치면서
사실 이 글은, CI/CD로 Github Actions를 선택한 이유와 간단한 인프라 구조만 설명하고 있어 자세히 알기는 어렵습니다.
그렇기에 앞으로 차차, VPC 구성부터 각 서비스의 구성을 어떻게 해나가는지 차례로 글을 쓰며 설명해나갈 것이며 이를 통해 우리 서비스의 발전 과정을 설명할 예정입니다.
