팀 프로젝트 Day3

아키텍쳐 설계

Day2에서 작성한 아키텍쳐 설계를 이어서 진행 하였다.

여러가지를 찾아본 결과 다음과 같은 부분들이 수정이 필요해 보였다.

팀원들과 상의를 한후 아키텍쳐를 완성을 하였다.

변경사항

• VPC Endpoint 추가
• Lambda VPC 종속성 제거
• 모니터링 시스템을 AWS Grafana 에서 오픈소스 EC2 Grafana 로 변경
• 테라폼 제거 (당장 필수인 부분 부터 구현해보고 후에 남는시간에 사용)

요금 계산

위의 아키텍쳐를 한달간 매일 8시간씩 사용한다는 기준으로 비용을 계산하였다.

실제로는 로컬에서 테스트를 거치고 한달이 아닌 2주정도 돌아갈 예정이기에 계산서에 있는 월별 비용의 1/2 이 사용될 금액이다.

예상비용 pdf

해당 아키텍쳐들을 사용하는 이유

ECS 사용이유

확장성 및 유연성:

• ECS의 CPU 사용률에 따라 EC2 인스턴스를 생성 및 삭제하므로 확장성과 유연성의 장점을 가짐

컨테이너 오케스트레이션:

• 내장된 컨테이너 오케스트레이션 기능을 제공하여 애플리케이션을 구성하는 여러 컨테이너를 관리하고 조정
• 컨테이너 이미지, 리소스 요구 사항, 네트워킹 및 기타 구성 옵션을 지정하여 ECS에서 작업 정의 및 서비스를 정의할 수 있음
• 컨테이너의 스케줄링, 배포 및 모니터링을 처리하여 애플리케이션 관리를 단순화

고가용성 및 내결함성:

• ECS 서비스를 통해 애플리케이션에 대한 고가용성과 내결함성 가능
• 서로 다른 EC2 인스턴스 또는 가용 영역에서 서비스의 여러 인스턴스를 실행함으로써 ECS는 로드 밸런싱 및 장애 조치를 자동으로 처리하여 오류가 발생하더라도 애플리케이션에 계속 액세스가능

서비스 검색 및 로드 밸런싱:

• ECS 서비스는 서비스 검색 및 로드 밸런싱을 위해 Elastic Load Balancing(ELB) 및 Amazon Route 53과 같은 다른 AWS 서비스와 통합 가능
• ELB 뒤에 ECS 서비스를 쉽게 노출하거나 Route 53 DNS 기반 서비스 검색을 사용하여 컨테이너 전체에 트래픽을 분산하여 성능과 가용성을 향상

AWS 서비스들과의 통합:

• ECS를 AWS Identity and Access Management(IAM), AWS CloudFormation, AWS CodePipeline 및 기타 서비스와 쉽게 통합하여 애플리케이션의 보안, 자동화 및 배포 기능을 향상

비용 최적화:

• ECS는 리소스 할당 및 자동 확장 정책에 대한 세밀한 제어를 제공하므로 리소스 사용을 최적화하고 비용을 최적화 가능

모니터링 및 로깅:

• ECS 서비스는 강력한 모니터링 및 로깅 기능을 제공
• ECS를 Amazon CloudWatch 및 AWS X-Ray와 같은 서비스와 통합하여 애플리케이션의 성능, 리소스 활용 및 요청 추적 가능

Lambda 사용이유

특정 이벤트 또는 요청에 의해 트리거 되는 아키텍처에 적합

• 점수 추가 및 조회 작업이 매시간 필요하지 않다고 판단하여 서버리스 모델을 사용해 필요할 때만 함수를 호출해 기능을 실행하여 리소스와 비용을 절약
• 또한 람다가 서비스 조정 및 리소스 할당을 자동으로 처리 하므로 컴퓨팅 리소스를 프로비저닝 하고 관리할 필요가 없음

확장성 및 오토스케일링

• 람다는 오토스케일링을 기본적으로 제공하기 때문에 함수가 많은 수의 요청 또는 이벤트를 처리 할 수 있음
• 급증하는 트래픽을 자동적으로 처리해줌으로 안정적이고 빠른 시스템을 제공할 수 있음

ECR 사용이유

1. AWS 서비스와의 통합:
   • ECR은 Amazon Elastic Container Service(ECS) 및 AWS Fargate와 원활하게 통합되어 AWS에서 컨테이너화된 애플리케이션의 배포 및 관리를 간소화합니다.
2. 네트워크 성능:
   • ECR은 AWS 지역에서 실행되는 애플리케이션에 대해 Docker Hub에 비해 더 나은 네트워크 성능을 제공합니다. ECR은 AWS 글로벌 네트워크 인프라를 활용하므로 이미지 가져오기 및 푸시 시간이 빨라집니다.
3. 보안 및 규정 준수:
   • ECR은 AWS 보안 모범 사례에 부합하는 내장 보안 기능을 제공합니다. 세분화된 액세스 제어를 위해 AWS Identity and Access Management(IAM)와 통합되어 세분화된 수준에서 사용자 권한을 관리할 수 있습니다.
4. 고가용성 및 내구성:
   • ECR은 컨테이너 이미지에 대한 고가용성 및 내구성을 제공합니다. ECR에 푸시된 이미지는 지역 내의 여러 가용 영역에 자동으로 복제되어 데이터 내구성과 가용성을 보장합니다.

Cloud Watch와 Grafana 사용이유

Cloud Watch:

• 지표 모니터링: RDS 데이터베이스, Lambda 함수 등의 리소스 사용률, 성능 및 상태를 모니터링하기 위해 사용 합니다.

Grafana:

• 데이터 시각화: Grafana를 사용하면 CloudWatch를 데이터 소스에 연결하여 동적 대시보드를 구축하고, 그래프, 차트, 표, 지도 등 다양한 시각화 옵션을 제공하기 위해 사용합니다.

RDS DB 를 두가지로 분류한 이유

• 사용자 관련 DB 와 그 외 DB 로 나누었습니다. 유저 데이터의 경우 중요한 정보이기에 유저 DB 장애 발생을 최소화하기 위해 분리하였습니다.

Git Actions 사용 이유

1. GitHub와 긴밀한 통합:
   • Git Actions는 GitHub 플랫폼과 긴밀하게 통합되어 GitHub 환경 내에서 원활한 자동화 및 워크플로우를 제공합니다.
   • CodePipeline 및 Jenkins는 GitHub와 통합할 수 있지만 동일한 수준의 통합을 설정하려면 추가 구성 및 설정이 필요합니다.
2. 기본 지원 및 단순성:
   • Git Actions는 GitHub 자체에서 제공하는 기본 CI/CD 도구로, 개발자에게 능률적이고 간소화된 환경을 제공합니다.
   • CI/CD 워크플로는 리포지토리 자체 내에서 YAML 파일을 사용하여 정의되므로 파이프라인을 쉽게 설정하고 관리할 수 있습니다. 반대로 CodePipeline과 Jenkins는 모두 추가 설치 및 설정이 필요하므로 더 복잡하고 시간이 많이 소요될 수 있습니다.
3. 풍부한 작업 생태계:
   • Git Actions는 GitHub Marketplace에서 사용할 수 있는 사전 구축된 작업의 방대한 생태계를 활용합니다. 이러한 작업에는 다양한 도구 및 서비스와의 구축, 테스트, 배포 및 통합과 같은 광범위한 작업이 포함됩니다. 이러한 사전 구축된 작업을 사용할 수 있으므로 엔지니어는 시간과 노력을 절약할 수 있으므로 CI/CD 파이프라인을 사용자 지정하고 확장하는 데 집중할 수 있습니다.
   • CodePipeline과 Jenkins도 플러그인과 확장 기능을 제공하지만 Git Actions 에코시스템에서 사용할 수 있는 작업이 더 많습니다.
4. 가시성 및 협업:
   • Git Actions는 GitHub 리포지토리 내에서 직접 CI/CD 파이프라인 상태를 명확하게 보여줍니다. 엔지니어는 빌드 및 테스트 결과를 쉽게 모니터링하고, 진행 상황을 추적하고, 끌어오기 요청, 문제 및 댓글과 같은 GitHub의 기본 제공 협업 기능을 사용하여 팀원과 협업할 수 있습니다.
   • CodePipeline은 파이프라인 상태를 시각적으로 표시하지만 더 자세한 정보를 보려면 AWS Management Console로 이동해야 할 수 있습니다.
   • Jenkins는 파이프라인 모니터링 및 관리를 위한 웹 기반 인터페이스를 제공하지만 협업 환경은 GitHub와 긴밀하게 통합되지 않을 수 있습니다.
5. 비용 효율성:
   • Git Actions은 넉넉한 프리 티어 사용량을 제공합니다. 그에 비해 CodePipeline의 가격은 활성 파이프라인의 수와 사용된 관련 리소스를 기반으로 하므로 대규모 프로젝트의 경우 더 높은 비용이 발생할 수 있습니다.
   • Jenkins는 무료이지만 서버 유지 관리 및 인프라 설정을 위해 추가 리소스와 노력이 필요합니다.