ECS를 활용한 CI&CD Architecture Diagram

 

• Terraform으로 EcsCluster 배포: 테라폼으로 만들어진 인프라를 통해 백엔드 코드/프론트엔드 코드를 GitHub에 푸시하면 CI/CD가 진행됩니다. 
• [GitHub Actions] name: Deploy to Amazon ECS 
• //github actions을 어떤 푸시가 있을 때, 실행시킬지 
  on: 
    push:
      tags:
        - v*
  
  env:
    AWS_REGION: ap-northeast-2
    ECS_CLUSTER: final-test-ecs-cluster
    ECS_SERVICE: final-ecs-service
    ECS_TASK_DEFINITION: .aws/task-definition.json
    CONTAINER_NAME: final-test-api
  
  permissions:
    contents: read
  
  jobs: //deploy를 진행하겠다 
    deploy:
      name: Deploy
      runs-on: ubuntu-latest
  
      steps: //어떤 단계로 deploy 진행시킬껀지
        - name: Checkout //코드 전부를 ubuntu 서버에 클론하겠다 
          uses: actions/checkout@v3
  
        - name: Configure AWS credentials //aws credential 정보를 가져온다(setting-secrets 미리 정의 완료후)
          uses: aws-actions/configure-aws-credentials@v1
          with:
            aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
            aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
            aws-region: ${{ env.AWS_REGION }}
  
        - name: Login to Amazon ECR
          id: login-ecr
          uses: aws-actions/amazon-ecr-login@v1
  
        - name: Extract tag name 
          id: extract_tag_name
          run: echo "##[set-output name=version;]$(echo '${{ github.ref }}' | sed 's/refs\/tags\///')"
  
        - name: Print Image Tag
          run: echo "${{ steps.extract_tag_name.outputs.version }}"
  
        - name: Build, tag, and push image to Amazon ECR
          id: build-image
          env:
            ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
            ECR_REPOSITORY: terraform-test
            IMAGE_TAG: ${{ steps.extract_tag_name.outputs.version }}
          run: |
            docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG backend/
            docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
            echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT
  
        - name: Fill in the new image ID in the Amazon ECS task definition
          id: task-def
          uses: aws-actions/amazon-ecs-render-task-definition@v1
          with:
            task-definition: ${{ env.ECS_TASK_DEFINITION }}
            container-name: ${{ env.CONTAINER_NAME }}
            image: ${{ steps.build-image.outputs.image }}
  
        - name: Deploy Amazon ECS task definition
          uses: aws-actions/amazon-ecs-deploy-task-definition@v1
          with:
            task-definition: ${{ steps.task-def.outputs.task-definition }}
            service: ${{ env.ECS_SERVICE }}
            cluster: ${{ env.ECS_CLUSTER }}
            wait-for-service-stability: true
• ECS Fargate 서버리스를 이용해 직접 관리할 필요없이 개발에만 집중할 수 있게 하기위해, 그리고 auto-scalling이 될 때 확장성이 더 좋기 때문에 EC2가 아닌 Fargate를 선택하였다. (ECS task를 실행할 수 있는 방법은 2가지 - fargate와 EC2/ EC2일 때 auto-scalling이 EC2와 task 각각 필요하다)
• Secret Manager- Rds Endpoint 데이터 읽을 때 필요하다: db 사용자 패스워드를 secret manager를 통해 암호화된 값을 사용한다 (aurora는 쓰기랑 읽기랑 endpoint가 다르기 때문에 각각 값을 입력한다) 
• Aurora DB: Ecs task auto-scalling그룹으로 확장성을 가져와서 트래픽이 몰렸을 때, 스케일업이 자동으로 된다. 하지만 db에 문제가 생기면 다른 모든 서비스에도 영향을 끼칠 수 있으니, 순간적인 트래픽 증가에 대응하기 위한 auto-scalling policy를 구성한다 (AZ zone을 두개로 분리: 가용성 확보를 위해 multi-AZ 활성화, 즉 한쪽 AZ에 문제가 생길 때 대응할 수 있다)
• Open VPN: 외부 사용자가 RDS사용이 필요할 때, 접근 방법을 부여하기 위한 수단이다. VPN 서버를 접속하면 AWS안으로 접속한것이라 private subnet도 접근이 가능하다 
• Cognito: 백엔드 프론트엔드 협업할 때, 회원기입 로그인 세부로직을 구성해야하지만, cognito를 사용하여 간편화하였다. 사용자 pool 방식을 사용하였다
• Slack: ECS 서비스에서 설정한 임계치 기준 CPU 사용량 알림을 설정하면, 스케일아웃/ 스케일인을 slack을 통해 전달받고 모니터링할 수 있다. 관리자 입장에서 편한 사용법이다. 
• Grafana 시각화: Cloudfront log는 WAF log와 거의 비슷하다. ALB log와 ECS log도 겹치는 부분이 많아 따로 시각화하지 않았다. 
• WAF: 방화벽, 웹 공격을 막아주고 국가별 트래픽/에러율 cloudwatch를 통해 log 확인 및 분석이 가능하다.

 

 

5

 

6

 

4

 

18

 

28

 

7

 

328