섹션 18: AWS의 컨테이너: ECS, Fargate, ECR 및 EKS

Docker 소개

• 앱 배포를 위한 소프트웨어 개발 플랫폼
• 컨테이너 기술
  • 컨테이너 앱에 패키징이 되어있음
  • 표준화 가능
  • 아무 운영체제 실행 가능
• 사용 사례
  • 마이크로서비스 (MSA) 아키텍쳐
  • 온프레미스에서 클라우드로 앱을 리프트-앤-시프트
• 작동 구조
  • 서버에서 도커 에이전트 실행
  • 도커 컨테이너 실행
• 도커 이미지 저장 위치
  • 도커 리포지토리
    • Docker Hub
    • Amazon ECR (Elastic Container Registry) 비공개 저장소
    • Amazon ECR Public Gallery
• 가상머신 vs 도커
  • 가상머신
    • 인프라
      • 호스트 운영체제
        • 하이퍼 바이저
          • Guest 운영 체제
            • 앱
          • Guest 운영 체제2
            • 앱2
    • 위와 같은 구조로 되어있음
    • 각자 분리되어 있음
    • 리소스 공유하지 않음
  • 도커
    • 인프라
      • 호스트 운영체제
        • 도커 Daemon
          • 컨테이너1
          • 컨테이너2
          • 컨테이너3..
    • 도커 Daemon에서 가볍게 실행되는 컨테이너라
      공존이 가능
    • 네트워크나 데이터 공유 가능
    • 덜 안전하지만 하나의 서버에 많은 컨테이너 실행이 가능

Amazon ECS

• Elastic Container Service
• AWS에서 컨테이너를 실행하면은 ECS 클러스터 이른바 ECS 태스트를 실행하는 것
• EC2 시작 유형
  • 인프라를 직업 프로비저닝하고 유지 해야함
  • Amazon ECS, ECS 클러스터가 여러 EC2 인스턴스로 구성
    • ECS 인스턴스가 ECS 에이전트를 실행해야함
    • 그러면 ECS 에이전트가 각각의 EC2 인스턴스를
      Amazon ECS 서비스와 지정된 ECS 클러스터 등록
    • 이후 ECS 태스크를 수행 시작하면 AWS가 컨테이너를 시작, 중지함
  • 즉 새 도커 컨테이너 생기면 EC2 인스턴스에 지정
  • ECS 태스크를 시작하거나 멈추면 자동으로 위치가 지정됨
• Fargate 시작 유형
  • 인프라를 프로비저닝 하지 않음
  • 관리할 EC2 인스턴스 없음
  • 서버리스
  • ECS 클러스터가 있을 때 ECS 태스크를 정의하는 태스크 정의만 생성하면
    • 필요한 CPU, RAM에 따라 ECS 태스크를 AWS가 자동으로 실행
  • 즉 새 도커 컨테이너 생기면 자동으로 처리
• ECS 태스크의 IAM 역할
  • EC2 인스턴스 프로파일
    • API 호출 예시
      • 인스턴스가 저장된 ECS 서비스가 CloudWatch 로그에 API 호출
      • 컨테이너 로그를 보내고 ECR로부터 도커 이미지를 가져옴
  • 태스크마다 특정 역할을 만들 수 있음
    • 태스크 A는 S3에서 API 호출
    • 태스크 B는 DynamoDB(NoSQL)에서 API 호출
• 로드 밸런서 통합
  • ALB (Application Load Balancer)
    • ECS 태스크들이 실행되며 ECS 클러스 안에 있을경우
    • HTTP, HTTPS 엔드 포인트로 태스크를 활용하기 위해 ALB를 앞에서 실행하면?
    • 모든 사용자가 ALB 및 백엔드의 ECS 태스크에 직접 연결됨
    • Fargate와 사용 가능
  • NLB (Network Load Balancer)
    • 처리량이 매우 많거나 높은 성능이 요구될 때만 권장
    • AWS Private Link와 사용 할때 권장됨
• 데이터 볼륨
  • EFS
    • EC2 태스크에 직접 마운트 할 수 있음
    • 데이터 공유하기 좋음
  • S3
    • ECS 태스크에 파일 시스템이 마운트 될 수 없음

Amazon ECS - 오토 스케일링

• 태스크 수를 자동으로 늘리거나 줄일수 있음
• 세 개의 지표를 확장 가능
  • CPU 사용률
  • RAM 사용률
  • ALB 타겟당 요청 수
• 특정 타겟을 추적하는 대상 추적 스케일링
• 단계 스케일링
• 미리 ECS 서비스 확장하는 예약 스케일링
• EC2 시작 유형이라면?
  • 태스크 레벨에서의 ECS 서비스 확장 != EC2 인스턴스 클러스터의 확장
  • 두개가 다르다.
• 백엔드에 EC2 인스턴스가 없을땐?
  • 무조건 Fargate를 사용
  • 전부 서버리스기에 도움이 됨
• ECS 클러스터 용량 공급자
  • 새 태스크를 실행할 용량이 부족하면 자동으로 ASG 확장
  • RAM, CPU가 모자랄 때 EC2 인스턴스를 추가
  • EC2 시작 유형의 경우 EC2 클러스터 용량 공급자 사용하는게 좋음

Amazon ECS - 솔루션 아키텍트

• 예시1
  • EventBridge에 의해 호출된 ECS 태스크
    • Amazon ECS 클러스터가 있고
    • AWS Fargate가 지원중
    • S3 버킷이 있음
  • 만약 S3 버킷에 사용자들이 객체 업로드를 함
    • EventBridge와 S3가 통합되어 모든 이벤트를 전송 할 수 있음
    • EventBridge는 ECS 태스크를 실행하기 위한 규칙을 생성을 했으면
    • ECS 태스크가 생성이 됨
      • ECS 태스크 역할이 있을텐데
      • 태스트 자체가 직접 객체를 받고 처리 후
      • Amazon DynamoDB로 전송 할 수 있음
• 예시2
  • EventBridge Schedule를 이용한 아키텍처
    • Fargate
    • Amazon EventBridge가 지원하는 Amazon ECS 클러스트가 있음
  • 1시간마다 트리거되는 규칙을 스케줄링
  • 이 규칙은 우리를 대신에 Fargate에서 ECS 태스크를 실행해줌
    • 이 태스크는 어떤 역할이든 가능 함
      • S3에 액세스를 하여 배치 프로세싱을 1시간마다 수행이 가능
• 예시3
  • SQS Queue
    • SQS Queue가 있고
    • 2개의 ECS 태스크가 있을 경우
  • 메시지가 SQS Queue로 전송
  • 서비스 자체가 SQS Queue로 부터 메시지를 가져와서 처리 가능

Amazon ECR

• Elastic Container Registry
• 도커 이미지 저장하고 관리하는데 사용 함
• 원래 Docker Hub 등 온라인 저장소를 활용했는데 AWS에도 저장 하는 것
• 이미지를 비공개, 공개로 저장 할 수 있음
• ECR은 ECS랑 완전히 통합 되어있음
• ECS 클러스트의 EC2 인스턴스에 이미지를 끌어올려면
  • IAM 역할 지정하면 됨
  • IAM 역할이 도커 이미지를 인스턴스에 끌어옴
  • ECR에 대한 모든 접근은 IAM이 보호함
    • 권한 에러가 뜨면 정책을 확인해야함
• EC2 인스턴스에 이미지 끌어왔으면 컨테이너가 시작 됨
• 저장만 하는 저장소가 아님
  • 이미지 취약점
  • 스캐닝
  • 버저닝 태그
  • 수명 주기 확인
  • 위의 4개를 제공을 함
• 도커 이미지 저장 할 땐 ECR

EKS 개요

• AWS 관리형 Kubernetes 클러스터 실행 서비스
• Kubernetes는 오픈 소스 시스템
• Docker로 컨테이너화한 애플리케이션을
  • 자동 배포
  • 확장
  • 관리
  • 위의 3개를 제공
• 컨테이너를 실행하는 목적은 ECS와 비슷하지만?
  • 사용하는 API가 다름
  • ECS가 오픈 소스가 아니고, Kubernetes는 오픈 소스여서
    표준화를 기대 할 수 있음
• EKS 두 가지 실행 모드가 있음
  • EC2 시작모드
    • EC2 인스턴스에서 처럼 작업자 모드를 배포 할 때 사용
  • Fargate 모드
    • EKS 클러스터에 서버리스 컨테이너 배포 시 사용
• 사용사례
  • 온프레미스나 클라우드에서 Kubernetes나 Kubernetes API 사용 시
    관리 할 때 사용을 함
  • 클라우드 또는 컨테이너 간 마이그레이션 실행 할 때 EKS가 간단한 솔루션이 됨
• EKS 작업자 노드를 생성하면 EC2 인스턴스가 구상됨
  • ECS 태스크와 유사함
  • 각 노드는 EKS 포드를 실행함
    • 포드라는 명칭을 쓰면 EKS와 관련된 것
  • EKS 포드가 실행되는 EKS 노드는 ASG로 관리 가능
  • ECS와 유사하게 EKS를 노출 할려면
    • 프라이빗 로드 밸런서
    • 퍼블릭 로드 밸런서
    • 2개중 하나를 설정을 하여 웹에 연결을 한다.
• 관리형 노드 그룹
  • AWS로 노드, 즉 EC2 인스턴스 생성 및 관리
  • 노드는 EKS 서비스로 관리되는 ASG의 일부
  • 온디맨드, 스팟 인스턴스 지원
• 자체 관리형 노드
  • 사용자 지정 사항이 많고 제어 대상이 많을때 직접 노드 생성해서
    EKS 클러스터 등록 후
    ASG의 일부로 관리 해야함
• Fargate
  • 노드를 원치 않을 경우 사용
  • 유지 관리 필요 없음
  • 노드 관리 안해도 됨
  • EKS에서 컨테이너만 실행하면 됨
    • EKS 클러스터에서 데이터 볼륨 연결할려면
    • 스토리지 클래스 매니페스트 지정 필요
      • 컨테이너 스토리지 인터페이스 (CSI) 규격 드라이브 활용
• 데이터 볼륨
  • EBS
  • EFS (Fargate)
  • FSx for Lustre
  • FSx for NetApp ONTAP

AWS App Runner - 개요

• 누구나 AWS에 손쉽게 배포를 할 수 있음
• 인프라, 컨테이너, 소스코드 알 필요 없음
• 소스 코드, Docker 컨테이너 이미지로 원하는 구성 설정
• 기본 설정만 하면 다음 작업은 자동
• 장점
  • 오토 스케일링 가능
  • 가용성 높음
  • 로드 밸런싱
  • 암호화 기능
  • 애플리케이션(컨테이너)가 VPC 액세스하여
    DB와 캐시 메시지 대기열 서비스 연결 가능
• 사용사례
  • 마이크로서비스 (MSA)
  • 신속한 프로덕션 배포