오늘은 CI/CD에 대해서 알아보기
배포를 해야하는 이유?
배포는 개발한 애플리케이션을 사용자에게 제공하기 위해 필수적인 과정이다. 애플리케이션의 배포를 통해 사용자들은 개발자가 만든 기능을 실제로 사용할 수 있게 되며, 배포는 애플리케이션의 운영 및 유지 보수에도 중요한 역할을 한다
1. 외부 접근성 확보
- 사설 IP 문제: 한국의 네트워크 환경에서 대부분의 개인 컴퓨터는 사설 IP를 사용한다. 이는 로컬 네트워크 내에서는 문제 없이 접속이 가능하지만, 외부에서 접근하기 어렵다. 예를 들어, 개발자가 로컬 환경에서 API를 구현했다고 해도 외부 사용자는 이 API에 접근할 수 없다.
- 포트 포워딩의 한계: 포트 포워딩을 통해 외부 접근성을 확보할 수 있지만, 이는 다음과 같은 문제를 동반한다.
- PC 종료 시 문제: 개발자의 PC가 꺼지면 외부 접근이 불가능하다.
- 네트워크 변경 문제: 개발자의 PC가 다른 네트워크에 연결되면 설정을 다시 해야 한다.
- 관리의 복잡성: 지속적인 네트워크 환경 변화와 설정 관리는 번거롭다.
2. 트래픽 처리와 성능 관리
- 예측 불가능한 트래픽: 애플리케이션이 사용자에게 공개되면, 예상치 못한 트래픽이 발생할 수 있다. 트래픽이 많아질수록 서버의 CPU, RAM 등의 하드웨어 성능이 중요해진다.
- 과부하 방지: 한 대의 서버에서 모든 요청을 처리하는 것은 비효율적이며, 성능 저하를 초래할 수 있다.
- 확장성: 클라우드 서비스를 이용한 배포를 통해 수평 확장이 가능하다. 트래픽이 증가하면 추가 서버를 쉽게 배치할 수 있다.
3. 데이터베이스 관리
- 데이터베이스 서버 분리: 데이터베이스를 별도의 서버로 분리하면, 애플리케이션 서버와 독립적으로 데이터베이스를 관리할 수 있다.
- 성능 향상: 데이터베이스와 애플리케이션 서버가 분리되면 각 서버의 성능을 최적화할 수 있다.
- 안정성: 하나의 서버가 문제가 생겨도 다른 서버에 영향을 미치지 않는다.
배포해보기
배포 자동화 필요성
WAS를 직접 배포하면 서버에 수정이 생길 때마다 직접 다시 배포해야 하므로 불편하다. 따라서 자동적인 배포 파이프라인을 구축하는 것이 좋다. CI/CD(지속적 통합 및 지속적 배포) 파이프라인을 통해 자동으로 배포를 진행하면 개발 효율성을 크게 향상시킬 수 있다.
수동 배포의 한계
수동 배포는 서버가 하나일 때는 큰 문제가 없을 수 있지만, 서버가 여러 대로 늘어나면 관리가 매우 어려워진다. 특히, 하나의 앱에서 여러 API를 제공하고, 이를 여러 WAS에 분산하여 운영하는 경우 수동 배포는 더 큰 어려움을 초래한다.
♾️ CI/CD
CI/CD는 Continuous Integration (지속적 통합)과 Continuous Deployment/Delivery (지속적 배포/전달)의 약어로, 소프트웨어 개발과 배포 과정에서 자동화를 통해 효율성과 안정성을 높이는 방법론이다. CI/CD 파이프라인을 통해 코드 변경 사항을 자동으로 빌드, 테스트, 배포함으로써 개발 속도를 높이고, 배포 오류를 줄일 수 있다.
CI (Continuous Integration): 지속적 통합
지속적 통합은 개발자가 코드 변경을 지속적으로 통합하여 빌드하고 테스트하는 과정을 자동화하는 것이다. 이는 코드 변경 사항이 통합될 때마다 자동으로 빌드와 테스트를 실행하여 통합 문제를 빠르게 발견하고 해결하는 데 도움을 준다.
- 주요 특징:
- 코드가 수정될 때마다 자동으로 빌드와 테스트가 실행된다.
- 통합 문제를 빠르게 발견하고 해결할 수 있다.
- 코드 품질을 높이고, 배포 주기를 단축할 수 있다.
- CI 도구:
- GitHub Actions: GitHub에서 제공하는 CI/CD 도구로, GitHub 리포지토리와 통합하여 코드 변경 사항을 자동으로 빌드하고 테스트할 수 있다.
- AWS CodePipeline: AWS에서 제공하는 CI/CD 도구로, AWS 인프라와 통합하여 빌드, 테스트, 배포를 자동화할 수 있다.
CD (Continuous Deployment/Delivery): 지속적 배포/전달
지속적 배포는 코드가 빌드되고 테스트를 통과하면 자동으로 프로덕션 환경에 배포되는 과정을 의미한다. 지속적 전달은 빌드와 테스트를 거친 코드를 프로덕션 환경에 배포할 준비가 된 상태로 유지하는 것을 의미한다.
- 주요 특징:
- 코드가 프로덕션 환경에 자동으로 배포된다.
- 배포 오류를 줄이고, 배포 주기를 단축할 수 있다.
- 인프라 관리를 자동화하여 운영 효율성을 높일 수 있다.
- CD 도구:
- AWS Elastic Beanstalk (EB): AWS에서 제공하는 PaaS(Platform as a Service)로, 애플리케이션 배포와 관리를 자동화할 수 있다.
- AWS Elastic Container Service (ECS): AWS에서 제공하는 컨테이너 관리 서비스로, Docker 컨테이너를 실행하고 관리할 수 있다.
CI/CD 파이프라인 구축하기
CI/CD 파이프라인 구축을 위해 GitHub Actions와 AWS Elastic Beanstalk을 사용한 예제를 설명한다.
1. 브랜치 전략 설정
CI/CD 파이프라인을 설정하기 전에 브랜치 전략을 정의해야 한다. 일반적으로 사용하는 깃 플로우(Git Flow) 전략은 다음과 같다
- feature 브랜치: 새로운 기능을 개발하는 브랜치이다.
- hotfix 브랜치: 긴급하게 버그를 수정하는 브랜치이다.
- develop 브랜치: 개발된 기능이 모이는 브랜치로, 통합 테스트를 수행한다.
- release 브랜치: 프로덕션 배포를 준비하는 브랜치이다.
- main 브랜치: 실제로 배포되는 프로덕션 코드가 모이는 브랜치이다.
2. GitHub Actions 스크립트 작성
GitHub Actions는 GitHub 저장소에서 CI/CD 파이프라인을 구현하는 도구다.
3. .ebextensions 설정
Elastic Beanstalk 환경 설정 파일은 .ebextensions 디렉토리에 위치한다. 예를 들어, 00-makeFiles.config 파일을 작성하여 배포 시 EC2 인스턴스에 필요한 스크립트를 포함시킨다.
4. NGINX 설정
NGINX를 리버스 프록시로 설정하려면 .platform/nginx/conf.d 디렉토리에 설정 파일을 작성한다.
5. Procfile 작성
Elastic Beanstalk에서 애플리케이션을 시작하는 명령을 정의하는 Procfile을 작성한다. 프로젝트 루트에 Procfile 파일을 생성한다.
6. 빌드 설정 추가
build.gradle 파일에 빌드 설정을 추가하여 필요한 종속성을 설정한다.
7. AWS Elastic Beanstalk 설정
8. Health Check API 구현
9. GitHub Secrets 설정
'IT 동아리 > UMC' 카테고리의 다른 글
[Chapter 7] JPA를 통한 엔티티 설계, 매핑 & 프로젝트 파일 구조 이해 (0) | 2024.05.24 |
---|---|
[Chapter 6] API URL의 설계, REST API, 프로젝트 세팅 (0) | 2024.05.17 |
[Chapter 5] 실전 SQL - Query를 작성하는 방법 (1) | 2024.05.10 |
[Chapter 3] Web Server & Web Application Server(WAS), Reverse Proxy (1) | 2024.05.02 |
[Chapter 2] AWS (VPC & Internet & Gateway & EC2) (2) | 2024.04.10 |