home

Ecs: chapter3

컨테이너를 이용한 AWS 아키텍처

  • AWS well architected
    • 운영 우수성
    • 보안
    • 안정성
    • 성능 효율
    • 비용 최적화
    • 지속 가능성
  • 설계 아키텍처
    • Ingress용 public ALB
    • 애플리케이션용 private subnet
    • Aurora용 private subnet
  • 옵저버빌리티(가관측성): 시스템 전체를 살펴보며 내부 상태까지 깊이 파고들 수 있는 상태
    • 탐지 -> 파악 -> 특정

로깅 설계

  • Cloudwatch logs 구독필터를 사용해서 로그 내에서 특정 문자열이 포함된 경우의 로그만을 추출 가능
    • 이 로그를 lambda -> SNS로 장애 통보 가능
  • Firelens
    • SaaS에도 로그를 전송 가능, firehose로 S3나 Redshift, OpenSearch Service에도 로그 전송 가능
    • 로그 라우팅 담당하는 Fluentd or Fluent Bit 선택 가능
    • Fluent bit는 Fluentd에 비해서 플러그온이 적지만 자원 효율이 좋아서 추천
      • 게다가 Fluent bit는 ECS 태스크 정의에서 AWS의 공식 컨테이너를 사용 가능
      • S3에는 Firehose를 경유하지 않고 직접 S3에 출력 가능하다
      • 심지어 cloudwatch에도 동시에 로그를 전송할 수 있다.
  • 로그 장기 보관을 위해서 애플리케이션 접속 로그는 S3, 에러 로그만 CloudWatch Logs에 전송하려면?
    • Fluent bit를 사용해라.
    • 기본 제공 Fluent bit 컨테이너로는 이것을 하지 못하기 때문에 설정파일을 S3 버킷에 넣어두거나, 직접 이미지를 만들어라

지표 설계

  • 지표는 정기적으로 계측되고 수집되는 시스템 내부의 정량적인 동작 데이터
    • CloudWatch 지표, CloudWatch Container Insights
    • CloudWatch Container Insights를 사용하면 ECS의 테스크 수준의 정보를 파악 가능
    • task수가 많아지면 그만큼 비용이 늘어난다.
    • ECS 클러스터 단위로 명시적인 옵트인이 필요
  • X ray를 사용하면 서비스 맵 대시보드도 제공해서 시스템 전체를 시각적으로 표시
    • 사이드카 형태로 x-ray 배포
    • VPC 밖에 서비스 엔드포인트가 있어서 애플리케이션이 VPC 내부에 있다면 따로 VPC 엔드포인트를 만들어줘야함

CICD

  • ECR 팁
    • 개발서버나 스테이징, 프로덕션 이미지에 태그를 달아서 수명 주기 정책을 유연하게 사용
    • 그리고 이미지 만들 때 운영환경_소스코드저장소 커밋 ID로 만들면 더 좋다

배스천

  • 퍼블릭 서브넷에 EC2를 배포하고, 프라이빗 서버와 연결하기 위한 점프 서버
  • 내부 작업에 대한 작업 기록도 취득 가능
  • 그런데 퍼블릭 서브넷임으로 좀 위험하다
    • 대안으로 배스천서버도 프라이빗으로 넣고, Session manager나 요즘 나온 EC2 Instance connect endpoint 사용

보안 설계

  • AWS의 보안은 공동 책임 모델
  • 이미지에 대한 보안 대책
    • ECR 이미지 스캔
      • 푸시 시 스캔
      • 수동 스캔
    • Trivy를 이용한 취약점 스캔
      • pip, yarn, npm등의 애플리케이션 종속성도 스캔 대상
      • codebuild 워크플로 파일에 기입하는 것으로 쉽게 통합
    • 즉, CICD 때 Trivy를 사용하고, ECR에 푸시 됐을 때 ECR 스캔을 진행한다.
    • 그러나 이미지는 정적이기 때문에 Lambda를 활용해서 주기적으로 스캔을 돌린다.
    • 이미지 설정 문제 대책: Dockle
    • 또한 docker나 AWS에서 공식으로 인증된 신뢰할 수 있는 이미지를 사용
    • Guardduty로 악성코드 탐지
    • 평문 기밀: Secret manager, System Manager Paramater Store 사용
      • secret manager는 각 정보(예 DB_USER: 1234)에 하나의 ARN이 생성되어, 해당 ARN을 ECS 태스크 정의 내에서 지정하면 된다.
      • System Manager Paramater Store는 secure string을 사용해야 암호화가 된다.
    • CICD 때 DCT를 활성화하면 서명된 기본 이미지의 변조 여부를 알 수 있다.
  • 레지스트리에 대한 보안 대책
    • 오래된 이미지는 수명주기 정책을 사용. 이 때 이미지 태그 덮어쓰기 금지하는 설정도 있다.
    • 불충분한 인증, 인가 제한 대첵
      • IAM 사용, 프라이빗 리포지토리 생성
      • 리포지토리 정책에서 push는 CI인 코드빌드, pull은 ecs만 가능하게 바꾸면 수동 푸시를 막을 수 있다.
  • 오케스트레이터에 대한 보안 대책
    • 모든 ECS 태스크는 awsvpc라는 네트워크 모드가 선택
    • 각 태스크에 고유한 ENI가 할당, 그 ENI에 프라이빗 IPv4주소가 할당
    • 퍼블릭 IP주소를 태스크에 할당해 internet gateway로 퍼블릭 네트워크와 통신 가능
    • WAF를 사용하면 되는데 ALB, API Gateway, Cloudfront만 가능
    • 그래서 앞에 퍼블릭 서브넷의 ALB를 두고 WAF를 연결시키고, 보안그룹 설정으로 태스크는 ALB의 inbound만 허용한다.
    • 또한 AWS Shield Standard를 무료로 사용할 수 있다.
    • VPC -> 퍼블릭 네트워크 통신이 필요할 때(리전 서비스 접근한다거나) 그냥 태스크 ENI에 퍼블릭 IP주면 간편하긴 하다.
    • 근데 이는 권장 사항이 아님으로 프라이빗 서브넷에 태스크를 두고 NAT 게이트웨이를 퍼블릭에 배치한다.
      • NAT 게이트웨이도 퍼블릭 네트워크를 경유한다.
      • 이를 원치 않으면 VPC 엔드포인트를 사용한다.
      • 게이트웨이 엔드포인트, 인터페이스 엔드포인트 사용
      • 인터페이스 엔드포인트는 시간 + 데이터 양에 따라 비용이 든다. 거기다가 고가용성 보장하려면 엔드포인트 별로 추가해야함
      • 근데 그냥 NAT 게이트웨이 사용하면 다중 AZ해도 10만원이다. 이게 더 저렴함, 그리고 어차피 인터넷 서비스랑 통신하려면 NAT 게이트웨이를 이용해야 함

안정성 설계

  • 장애, 복구, 가용성, 자동이 키워드
  • 다중 AZ로 ECS 태스크를 배치
  • 이는 ECS 서비스 스케줄러가 알아서 태스크를 AZ에 배치해준다.
  • CloudWatch를 활용한 ECS 태스크 장애 탐지
    • TaskCount: ECS 클러스터에서 실행 중인 태스크 수 (서비스에 속하지 않은 태스크도 포함)
    • RunningTaskCount: ECS 서비스에서 실행 중니 태스크 수
    • ECS 태스크에 장애가 발생했을 때 알람을 보낼 것인지는 비지니스에 강하게 의존
  • ALB와 연계한 ECS 태스크의 제거 및 자동 복구
    • ECS 태스크 장애 발생시 ALB가 자동으로 해당 태스크 제외
  • Fargate 작업 유지 관리로 인한 ECS 태스크 정지
    • 태스크 사용 중단 알림을 보낸다
    • 해당 태스크에 SIGTERM 시그널을 전송
    • 응답하지 않은 경우 SIGKILL을 보내서 강제종료. 그래서 애플리케이션에서 SIGTERM에 대한 핸들링 필요
  • 점검시 서비스 정지
    • ALB 리스너 규칙 정의에서 점검 중 페이지를 설정
    • 503고정 응답하는 Listener Rule에 우선도를 높인다.

성능 설계

  • Auto Scaling 활용
    • 단계 조정 정책
      • 스케일 아웃 및 스케일 인 조건에 단계를 설정해 단계적으로 확장 할 수 있도록 하는 정책
      • 70면 한 개늘리고, 30퍼면 한 개 줄이고..
    • 대상 추적 조정 정책
      • 지정한 지표의 설정 값이 유지되도록 스케일 아웃 또는 스케일 인을 수행하는 정책
      • 스케일 아웃은 고속, 스케일인은 천천히 실행
      • 스케일 아웃은 어느 하나의 지표의 목푯값을 초과하면 하지만, 스케일인은 모든 지표를 만족시켜야 한다.
    • 대상 추적 조정 정책 추천
    • 다양한 실험(locust 활용 등)을 통해서 최적의 비용과 성능을 찾아낸다.
    • 적은 수의 IP주소를 갖는 서브넷을 ECS 서비스에 설정했다면 급격한 스케일아웃으로 인해 IP주소가 부족해 질 수 있다.

비용 최적화 설계

  • 용량 공급자 개요를 활용
    • 온디맨드는 FARGATE, 스팟은 FARGATE_SPOT라는 이름으로 용량 공급자가 미리 정의
    • ECS 서비스에서 기본 값 2, 가중치 4로해서 기본 값은 온디맨드, 가중치는 스팟으로 운영
    • spot은 중단된다. 태스크 종료 2분 전에 종료되는데 이 역시 SIGTERM을 발생시킨다.