이전 프로젝트에서의 인프라 및 CI/CD를 구성할 때 최우선적으로 고려했던 점은 ‘과연 우리 프로젝트에 이 기술이 필요할까?’ 였습니다.
이에 따라 주어진 환경 내에서 최소한의 자원만을 사용하여 인프라 환경을 구축했었습니다.
이번에는 개인 토이 프로젝트를 진행하면서 이전에 사용하지 못했던 기술들을 사용하는 것을 목표로
이전에 사용하지 않았던 Docker, Jenkins, AWS ALB를 사용하며 인프라, CI/CD 환경을 구축해보려고 합니다.
프로젝트의 규모가 작고 거의 처음 경험하는 기술 위주로 설계한
초보 개발자의 개인 토이 프로젝트인 점을 참고해주시면 감사하겠습니다! 😃
(설계는 인프라 구축 단계에서 시행착오를 거치며 꾸준히 변경될 수 있습니다! ㅎ__ㅎ...)
1. INFRA 설계
🚀 완성한 INFRA 초기 설계
완성한 개인 프로젝트의 인프라 환경 설계 그림입니다.
간략하게 부분적으로 왜 이러한 환경을 구성했는지, 이 기술은 왜 사용했는지를 기록해보겠습니다.
1-1. Docker 사용 이유
이번 인프라 환경 설계의 핵심 중 하나인 Docker입니다!
Docker를 사용한 이유를 간략하게 나열하면 다음과 같습니다.
- 사용해보지 않았기 때문에 처음으로 직접 적용해보면서 경험해보기 위함
- Scale-out 시 기존 서버의 환경과 똑같은 새로운 서버 환경을 쉽고 간단하게 구성할 수 있기 때문에
- 하나의 서버 내에서 여러 독립된 환경을 구성할 수 있기 때문에
이렇게 3가지로 정리할 수 있습니다.
사용해보지 않았기 때문에 처음으로 직접 적용해보면서 경험해보기 위함
솔직히 말하면, 위의 첫 번째 이유가 사용한 이유 중에 가장 크고 다른 이유들은 이론적인 부분이 강한 것 같습니다.
애초에 이번 개인 프로젝트의 목표도 '이전에 사용하지 않았던 기술들 사용'이 목표이기 때문입니다,
Scale-out 시 기존 서버의 환경과 똑같은 새로운 서버 환경을 쉽고 간단하게 구성할 수 있기 때문에
글을 작성하는 지금 시점은 거의 그림의 80%를 구축한 시점입니다.
해당 그림대로 도커를 사용해보면서 두 번째 이유를 직접 경험할 수 있었습니다.
그림에서 WAS1 EC2와 WAS2 EC2의 WAS on Docker 환경은 똑같은 것을 알 수 있습니다.
(WAS1 -> WAS2로 Scale-out 상황)
이때, 맨 처음 WAS1의 도커 환경을 구축하는 데는 조금 시간이 걸렸지만,
WAS2의 도커 환경을 구축하는 데는 조금 과장 보태서 10초도 안 걸렸습니다.
EC2에 도커를 설치하기만 하고 그 후에 WAS1에서 구성했던 도커의 이미지를 받아서 컨테이너를 실행하기만 하면 됐기 때문입니다.
이렇게 직접 경험을 하고 나니 왜 실무에서 컨테이너 환경을 중요시하고 도커를 사용하는지 알 수 있었습니다.
하나의 서버 내에서 여러 독립된 환경을 구성할 수 있기 때문에
이 부분은 IFNRA EC2를 보면 알 수 있습니다.
만약 도커 없이 하나의 서버에 Jenkins, MySQL, Redis가 존재한다고 가정해봅시다.
이때, Jenkins에 과도한 트래픽 등 어떤 원인으로 인해 장애가 발생했을 때 Jenkins가 속한 INFRA EC2가 다운될 수 있고
그에 따라 INFRA EC2에 있는 MySQL, Redis에도 장애가 발생할 것입니다.
이러한 문제를 서비스들을 각각 도커 컨테이너 내에서 실행함으로써 서로 독립된 환경을 구축하여 해결할 수 있습니다.
이전 예시처럼 Jenkins에 장애가 발생한다면 Jenkins의 도커 컨테이너는 다운될 수 있지만
Jenkins의 도커 컨테이너가 속한 INFRA EC2의 다른 도커 컨테이너(MySQL, Redis)와는 독립적이기 때문에
MySQL, Redis에는 직접적인 영향을 끼치지 않을 것입니다.
※ INFRA EC2에 프로세스가 여러개 존재하는 이유
위에서 INFRA EC2에 Jenkins, MySQL, Redis가 존재하도록 설계했습니다.
이 부분을 보고 커넥션이 잦은 DB 서버와 CD 툴을 하나의 EC2 서버에 두는 것이 비효율적이라고 생각한 분들이 있을 것 같습니다!
사실 저도 그렇게 생각합니다..😭
이렇게 설계한 이유는 금전적인 이유로 AWS 프리티어를 사용하기 때문입니다.
물론 프리티어에서 한달 기준 무료 EC2는 1개가 최대라서 현재 구조도 과금이 발생합니다.
그래도 EC2 1대로는 도저히 원하는 경험을 할 수 없어서 여러 대를 사용하려고 했을 때,
로드 밸런싱 경험을 하면서 원하는 인프라를 구성할 수 있는 구조가 INFRA EC2에 몰빵하는 구조여서 저렇게 설계하게 되었습니다 😂
++24.01.28 수정
CD 시에 Jenkins에서 빌드까지 수행해서 서버 리소스를 엄청 잡아먹었습니다.
그래서 어쩔 수 없이 젠킨스용 EC2를 추가하게 되었습니다.
1-2. AWS Application Load Balancer 사용 이유
이번 인프라 환경 설계의 핵심 중 하나인 AWS ALB입니다!
마찬가지로 ALB를 사용한 이유를 간략하게 나열하면 다음과 같습니다.
- 사용해보지 않았기 때문에 처음으로 직접 적용해보면서 경험해보기 위함
- AWS 환경의 편한 로드 밸런싱을 위해서
사용해보지 않았기 때문에 처음으로 직접 적용해보면서 경험해보기 위함
도커와 마찬가지로 AWS ALB 역시 이번에 처음 사용하는 기술입니다.
로드 밸런서로 실무에서도 많이 사용하고 있기 때문에, 사용해보고 싶어서 사용하게 되었습니다! 😃
AWS 환경의 편한 로드 밸런싱을 위해서
처음에는 로드 밸런서로 Nginx와 AWS ALB를 고민했었습니다.
Nginx도 로드 밸런싱 기능을 제공하기 때문에 Nginx를 사용해도 괜찮지 않을까? 했지만
로드 밸런싱할 Target이 AWS 환경의 EC2이고 설치 및 관리를 AWS에서 GUI로 편하게 할 수 있기 때문에 ALB를 선택했습니다.
추가적으로 Scale-out되는 서버가 많아지거나, EC2 Auto Scaling 같은 기능을 활용할 때
Nginx 보다는 ALB가 더 적합할 것 같았습니다.
※ AWS ELB 중에서 ALB을 선택한 이유
AWS의 로드 밸런싱 서비스(ELB)는 크게 다음과 같이 나뉩니다.
- ALB (Application Load Balancer)
- NLB (Network Load Balancer)
- GWLB (Gateway Load Balancer)
이 중에서 ALB를 선택한 가장 이유는
일반적인 웹 애플리케이션으로의 접근인 HTTP, HTTPS 포트에서 오는 트래픽을 관리하고 싶었기 때문입니다.
NLB, GWLB는 TCP, UDP 기반의 트래픽을 관리하기 때문에 ALB를 사용하게 되었습니다.
2. CI/CD 설계
🚀 완성한 CI/CD 초기 설계
완성한 개인 프로젝트의 CI/CD 설계 그림입니다.
인프라 환경과 마찬가지로 간략하게 왜 이러한 환경을 구성했는지, 이 기술은 왜 사용했는지, CI/CD Flow를 기록해보겠습니다.
2-1. Jenkins 사용 이유
Jenkins 사용 이유는 간단하게 사용해보고 싶어서입니다.
이전 프로젝트에서는 Github Actions를 사용해서 CI/CD를 모두 구성했었습니다.
일반적으로 CI/CD 툴로 대두되는 것이 Github Actions와 Jenkins이기 때문에 Jenkins를 사용해보고 싶었습니다.
2-2. Docker Hub 사용 이유
Docker Image의 Repository로 Docker Hub를 사용하게 되었습니다.
Docker Hub에 Docker Image를 저장하면 젠킨스의 리소스를 절약할 수 있고,
Scale-out 시 젠킨스 서버보다 Docker Hub에서 Docker Image를 받는 것이 더 적합하다고 생각했습니다.
2-3. CD 시 Jenkins Trigger 방식
보통 Jenkins를 적용한 다른 블로그를 찾아보면 Github의 Webhook을 통해 Jenkins Trigger를 하는 방식이 많았습니다.
저도 처음에는 Github Webhook을 사용하여 Trigger를 진행하려 했으나, PR Merge 이벤트만 따로 존재하지 않아서
사용하지 않게 되었습니다.
일반적으로 Push 이벤트로 Trigger를 하는 경우가 많았는데
저는 브랜치에 바로 push하는 것이 아니라 PR을 먼저 Open하고 코드 리뷰를 거친 후에 Merge를 하는 상황을 생각했습니다.
따라서, Github Webhook 대신 Github Actions의 workflow로 직접 PR Merge 이벤트를 지정하여
Jenkins를 Trigger하게 되었습니다.
2-4. CI/CD Flow
1. CI Flow
- Feature -> Main 브랜치 PR Open
- Github Actions workflow로 빌드 & 테스트
- 빌드 & 테스트 실패 시 실패 리포트 발행
2. CD Flow
- Feature -> Main 브랜치 PR Merge
- PR Merge 이벤트로 INFRA EC2 Jenkins 트리거
- Jenkins Pipeline으로 배포 진행
- Docker Image 생성 후 Docker Hub에 Push
- ssh로 WAS EC2 접속하여 Docker Hub Image로 WAS 실행
이렇게 혼자 인프라, CI/CD 환경 설계를 진행해봤습니다.
여러 측면에서 비효율적인 부분과 잘못된 부분이 있을 수 있지만
시간이 된다면 이후에 경험해나가면서 개선해보도록 하겠습니다! 😃
'Infra' 카테고리의 다른 글
| [INFRA] 개인 프로젝트 INFRA, CI/CD 구축기 - (3) AWS ECS 구성하기 (5) | 2024.01.30 |
|---|---|
| [INFRA] 개인 프로젝트 INFRA, CI/CD 구축기 - (2) 인프라 아키텍쳐 수정 (0) | 2024.01.29 |
