인프라 설계 -(3)(우리 지금 만나)

우리가 하고자 하는 프로젝트를 누군가에게 보여주기 위해서는 "배포"라는 것이 필요하였습니다. 그래서 인프라에서 어떤 소스들을 활용할지에 대한 논의가 필요했습니다.

 

CI/CD

일단은 CI/CD를 4개로 추려봤습니다.

Jenkins

특징: 가장 널리 사용되는 오픈소스 CI/CD 도구. 플러그인을 통해 다양한 기능과 서비스와 연동 가능.

장점: 커스터마이징 가능, 대규모 커뮤니티, 다양한 플러그인.

단점: 설정이 복잡할 수 있고, 유지 관리가 필요함.

 

GitLab CI/CD

특징: GitLab 플랫폼에 내장된 CI/CD 도구. Git 리포지토리와 통합되어 있어 사용이 편리함.

장점: Git과 긴밀한 통합, 클라우드 및 자체 호스팅 지원, 깃 기반 워크플로우와 자연스러운 연동.

단점: 특정한 사용자 정의가 복잡할 수 있음.

 

AWS CodePipeline

특징: AWS 서비스와 통합된 CI/CD 서비스로, AWS 리소스를 관리하는 데 최적화됨.

장점: AWS 서비스와의 강력한 통합, 간편한 설정, 자동화된 배포.

단점: AWS 외부 서비스와의 통합은 제한적일 수 있음.

 

GitHub Actions

특징: GitHub에서 제공하는 CI/CD 도구로, 리포지토리와 직접적으로 통합됨.

장점: GitHub 리포지토리와 깊은 통합, 워크플로우 자동화 간편, 다중 플랫폼 지원.

단점: 복잡한 설정 시 한계가 있을 수 있음.

 

팀원분들과 논의에서 4개의 후보군 중에 Jenkins를 사용하기로 결정하였습니다.

 

왜 Jenkins를 선택했나요?(왜 사용했나요?)

일단 오픈소스인 Jenkins는 완전히 무료로 사용이 가능한 오픈소스 CI/CD이기 때문이고. 그리고 확장성이 매우 높기에 수천 개의 플러그인을 통해 다양한 기능 추가가 가능해 맞춤형 워크 플로우 구축이 가능하기 때문입니다.

플러그인 덕분에 Docker, Git, AWS 통합이 가능하다.

Jenkins는 온프레미스에서 호스팅 가능하기에 민감한 정보는 외부 클라우드에 저장되지 않게 가능하다는 보안적 이점이 있습니다.

우리팀은 로컬에서 Jenkins를 다룰예정이라 온프레미스에서 호스팅이 가능해야합니다. 

그 이유는?

• 클라우드 서버 비용 절감
• 네트워크 지연을 최소화

가장 큰 이점은 Jenkins는 수년간 사용되어온 도구이기에 풍부한 자료가 있습니다. 주니어 개발자인 우리들에겐 다양한 사용자들의 경험이 공유되어왔기에 복잡한 상황에서도 문제를 해결이 가능한 리소스를 쉽게 찾는 것이 가능합니다.

 

CLOUD

무슨 클라우드를 사용할까?

Amazon Web Services(AWS)

특징:

매우 확장 가능하고 안정적인 서비스 제공.

수천 가지의 서비스와 기능(컴퓨팅, 스토리지, 데이터베이스, 인공지능, 머신러닝 등).

글로벌 데이터센터 네트워크.

비용 관리 도구와 탄력적 과금 체계.

 

Microsoft Azure

특징:

하이브리드 클라우드 환경에 적합한 서비스 제공.

Azure Active Directory와 같은 강력한 ID 관리 서비스.

개발자 도구와 엔터프라이즈 애플리케이션 지원.

DevOps 및 애플리케이션 개발에 강점.

 

Google Cloud Platform (GCP)

특징

강력한 데이터 분석 및 AI/ML 툴 제공(BigQuery, TensorFlow).

글로벌 네트워크 인프라.

Google 서비스(Gmail, YouTube)와 동일한 인프라에서 구동됨.

서버리스, 컨테이너 기반 개발 환경 지원.

그외에 ibm, oracle, alibaba, digital ocean이 있지만 확장성 부족과 비약한 생태계로 인해 제외함.

 

이렇게 3가지로 추려보았습니다.

그중에서 AWS로 결정!

왜 AWS 사용했나요?

풍부한 리소스와 강력한 커뮤니티 자원이 있어 클라우드 서버를 구축하기 더욱 수월합니다.

free tier

다양한 서비스(s3, ec2, ecs 등)

사실 대규모 프로젝트는 아니라 DigitalOcean로 간단하게 배포가 가능하지만 트러블 슈팅에 관한 정보는 AWS가 많이 때문에 주니어 개발자가 다루다가 문제가 터졌을때는 AWS에 리소스가 많기에 AWS로 확정! 이번 프로젝트는 5주간의 짧은 기간이라 인프라에 많은 시간을 할애하기는 힘들어 자료가 많은 AWS를 적용하였습니다.

 

가상화 플랫폼

어떤 가상화 플랫폼을 사용해야 할까?

일단 AWS ECS와 Jenkins를 함께 사용할 예정이라 컨테이너 기반 CI/CD 파이프라인 구축을 해야한다.

일단 조건에 부합하는 가상화 플랫폼이 있어야 합니다

그게 어떤 조건이냐면....

관리 부담이 적어야 하고, 빠르게 배포 및 테스트가 가능해야 합니다.

많은 학습 자료, 수많은 커뮤니티 환경 → 다양한 이슈가 터질시 쉽게 해결 가능해야하고

jenkins와 연동이 가능해야됩니다.

 

그렇게 하여 해당 조건에 부합하기에 컨테이너 기반 가상화 플렛폼중 Docker 선정되었습니다.

 

레지스트리

Docker Hub vs AWS ECR

 

Docker Hub

 

장점

익숙함: 많은 개발자들이 Docker Hub를 이미 사용하고 있어 초기 설정이 간편합니다.

공개 이미지 활용: 오픈 소스 프로젝트나 공개 이미지의 경우 Docker Hub를 통해 손쉽게 공유 및 활용할 수 있습니다.

무료 사용 가능: 제한된 개인 저장소와 공개 저장소를 무료로 사용할 수 있습니다.

 

단점

네트워크 지연: Docker Hub는 전 세계적으로 사용되지만, AWS와 같은 특정 클라우드 환경에서 이미지를 가져올 때 네트워크 지연이 발생할 수 있습니다.

보안 및 접근 제어: 개인 저장소의 경우 무료 플랜에서는 제한적이며, 접근 권한 관리가 AWS IAM만큼 세밀하지 않을 수 있습니다.

AWS 서비스와의 통합 제한: AWS의 다른 서비스와의 자동화 및 통합 기능이 제한적일 수 있습니다.

 

AWS ECR

 

장점

AWS 서비스와의 원활한 통합: ECS, EKS, CodeBuild 등 AWS의 다양한 서비스와 쉽게 통합되어 CI/CD 파이프라인을 구성하기 편리합니다.

보안 강화: AWS IAM을 통해 세밀한 권한 관리가 가능하며, 이미지에 대한 접근을 철저히 통제할 수 있습니다.

빠른 이미지 다운로드 속도: 동일한 AWS 리전 내에서 이미지를 저장하고 가져오기 때문에 네트워크 지연이 최소화됩니다.

추가 기능 지원: 이미지 취약점 스캔, 암호화, 라이프사이클 정책 등을 지원하여 이미지 관리가 용이합니다.

 

단점

비용 발생: 저장 용량과 데이터 전송에 따라 추가 비용이 발생할 수 있습니다. 그러나 소규모 프로젝트에서는 큰 부담이 아닐 수 있습니다.

AWS 종속성: ECR은 AWS 전용 서비스이므로, 다른 클라우드 플랫폼이나 온프레미스 환경으로 이전할 경우 이미지 마이그레이션 작업이 필요합니다.

 

레지스트리는 둘중 하나로 선택해야 했다.

 

적은 네트워크 지연과 기존 AWS를 쓰기에 높은 연동성 그리고 Jenkins도 호환이 되고 자동으로 보안 취약점을 찾고 라이프 사이클 기능을 동해 자동 비용절감으로 비용 부담도 덜한 ECR로 결정하였다!

 

 

최종적으로 확정된 인프라 설계

 

근데 AWS fargate-ECS와 EC2 에 대해 갈팡질항중이라 EC2로 바뀔 가능성이 있다.