👍 이 글은 AWS 솔루션즈 아키텍트 김지민님의 강연 AWS에서 컨테이너를 운영한다면 꼭 봐야 하는 모범 사례 를 보고 정리한 내용입니다.
좋은 강연해주신 연사분께 감사드립니다. AWS 입사하면 커피 사겠습니다.

📣 소제목을 누르면 해당 발표 시간의 영상으로 이동합니다. 내용을 보다가 이해가지 않는 부분이 있다면 편하게 찾아보세요.

AWS Well Architected 원칙

• 운영 우수성: 모니터링, 자동화, 이벤트 응답, 표준화 등 프로세스 개선

• 보안: 데이터의 기밀성 및 무결성, 권한 제어 등

• 안정성: 서비스 가용성을 위한 분산 시스템 설계, 장애 회복력 등

• 성능 효율성: 리소스를 효율적으로 사용

• 비용 최적화: 불필요한 지출 제거

• 잘 설계된 워크로드란 위 다섯개를 준수해야함.

참고 : https://aws.amazon.com/ko/architecture/well-architected/

빌드

컨테이너 이미지 모범 사례

첫번째 모범사례: 신뢰할 수 있는 이미지 저장소를 이용하라

• 우리가 컨테이너 이미지를 빌드하는 과정을 보면, 도커 파일이라는 일종의 명세서를 코드 형태로 작성함.
• 악의적인 사용자가 코드나 바이너리를 삽입해서 애플리케이션에 악영향을 줄 수 있는 공급망 공격의 위험이 있음
  • 잘 알려져 있고 믿을 수 있는 이미지 공급자를 통해 이미지를 구축해야함.

두번째 모범 사례: 이미지 빌드에 필요하지 않은 파일은 배제

• 빌드 컨텍스트와 이미지 크기를 줄이면, 이미지를 빌드하는 시간, 이미지를 가져오고 푸시하는 시간을 절약할 수 있어 전반적인 배포 프로세스가 빨라짐
  • 컨테이너 런타임 크기를 최적화해서 불필요한 리소스 소모를 줄일 수 있음
• 멀티 스테이지 도커 빌드를 사용하면 애플리케이션 실행에 불필요한 패키지도 제거할 수 있음
  • 예를 들어, Go 언어로 작성된 프로그램을 실행 파일로 만들기 위해서는 Go 컴파일러가 필요.
    • 하지만 그 프로그램을 실행하는 컨테이너에서는 최종 실행 파일만 있으면 되고, Go 컴파일러는 더이상 필요하지 않음
  • 멀티 스테이지 빌드를 통해 앞 단계에서 컴파일을 완료하면, 실행 파일만 남길 수 있다.
  • 이미지를 가져오는 시간을 줄일 수 있을 뿐만 아니라, 이런 식으로 만든 이미지는 공격 표면이 훨씬 작기 때문에 보안 측면의 이점도 있음.
• 도커 이미지는 각각의 레이어로 구성되어 있고, 각 레이어는 이전 레이어를 참조해서 생성 됌.

✏️ 공격 표면
해커가 네트워크나 민감한 데이터에 무단으로 액세스하거나 사이버 공격을 수행하는 데 사용할 수 있는 취약성, 경로 또는 방법의 합을 말하며, 공격 벡터라고도 함
https://www.ibm.com/kr-ko/topics/attack-surface

• docker run 명령어를 실행하면, 맨 위 레이어에 쓰기 가능한 컨테이너 레이어가 추가되면서 해당 이미지를 기반으로 한 컨테이너를 실행함.
• 만약 여러 컨테이너가 공통된 설정을 상당 부분 공유하고 있다면, 템플릿처럼 쓸 수 있도록 공통된 필요한 설정이나 패키지들을 담아서 만든 베이스 이미지를 활용하는 것도 좋음.
  • 베이스 이미지를 기반으로 앱 서버를 실행하고, 공통 설정에 변경이 필요하다면 새 버전의 베이스 이미지를 배포하는 방식으로 거버넌스를 유지하는 것도 도움이 됌.
• 이 외에도 컨테이너 실행과 관련해서는 도커에서 가이드하는 도커 파일 모범 사례를 참고하는 것도 좋음 (https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)

컨테이너 레지스트리 모범 사례: Amazon ECR

프라이빗 레파지토리

• 위에서 만든 컨테이너 이미지를 이미지 저장소(ECR, 완전관리형 컨테이너 레지스트리)에 저장함.
  • 여기서는 ECR을 기준으로 말하지만, 다른 컨테이너 레지스트리에도 참고할 수 있는 내용임.
  • 아마존 ECR은 퍼블릭 레파지토리도 지원하지만, 기본적으로는 프라이빗 레파지토리.
    • 퍼블릭으로 공개해야 하는 경우가 아니라면, 프라이빗으로 구성해서 내부 사용자만 접근 할 수 있게 하는 것이 안전.

암호화 및 엑세스 제어

• 컨테이너 이미지 또한 데이터 보호 관점에서 암호화와 액세스 제어를 고려할 필요가 있음.
  • ECR에 저장되는 컨테이너 이미지는 자동으로 암호화되서 안전하게 저장
  • KMS(Key Management Service)를 통해 고객 고유의 키를 이용한 암호화도 지원
• ECR은 IAM과 연동해서 컨테이너 이미지로의 접근을 간편하게 제어할 수 있게 해줌
  • 예를 들어 개발자에겐 개발 레포지토리에만 읽기와 쓰기 권한을 주고, 운영 레파지토리에는 권한을 제한하는 등 꼭 필요한 사람에게 필요한만큼만 권한을 부여하는 최소 권한 원칙에 따라 설계해야 함.

태그 명명 규칙을 정하고 불변 태그 기능 활성화

• 태그 네이밍에 대한 일반적인 모범 사례는 latest 태그를 사용하지 말라는 것.
  • 이미지 버전 태그를 명시하지 않으면 latest를 기본으로 사용하게 되는데, latest 이미지 자체가 변경될 수 있기 때문에 변경 불가능한 태그를 이용하는 것이 바람직
    • 빌드 Id나 git hash를 사용 할 수 있음
    • 버전을 병기해서 네이밍 하는 것은 버전의 의미를 파악하면서 유니크한 태그를 만들 수 있다는 점에서 좋은 프랙티스
• 어느 쪽이든 태그 명령 규칙이 정해지면 그에 따라 태깅을 하고, 동시에 불변 태그 기능을 활성화 해서 태그를 덮어씌우지 못하게 설정하는 것이 좋음.
  • 실제 의도했던 것과 다른 버전 이미지가 배포되는 것을 예방할 수 있음

이미지 라이프사이클 정책 관리

• 이미지 태그는 이미지의 라이프 사이클 정책을 관리하는 데도 유용
  • 지정한 기간이 지나면 불필요한 이미지를 자동으로 삭제할 수 있는데, 태그에 따라 만료 기간을 다르게 지정하는 등의 정책을 통해서 불필요한 이미지를 최소화 할 수 있음

취약성 스캐닝: 기본 / 강화된 스캐닝

• AWS ECR은 컨테이너 이미지가 보안 취약점이 없는지 스캐닝 할 수 있는 기능을 제공
  • 기본 스캐닝은 무료이며, ECR에 이미지가 푸쉬되는 시점에 os에 대한 CVE 취약점 검사를 진행
  • 신규 기능으로 AWS 인스팩터(Amazon Inspector)를 이용한 강화된 스캐닝은 os 뿐만 아니라 프로그래밍 언어 패키지에 대한 취약점도 함께 스캐닝할 수 있고, 푸쉬 시점에만 하는 것이 아니라 지속적인 스캐닝.
• 컨테이너 이미지 보안을 위해서 무료로 제공되는 기본 스캐닝이라도 꼭 활용할 것을 권장

배포

운영 우수성: 컨테이너 배포 자동화

• 컨테이너 애플리케이션을 빠르게 배포하고 개발자의 생산성을 높이기위해 CI/CD 파이프라인을 이용함.
  • 이는 운영 우수성 원칙중에 반복되는 작업을 자동화해서 효율성을 높이고 휴먼 에러를 예방해야한다는 내용과 일치
• 일반적으로 소프트웨어 배포과정은 소스 -> 빌드 -> 테스트 -> 프로덕션 4단계.
  • 앞의 두 개를 자동화하는 것을 CI(지속적 통합)라고 하며, 변경분 취합을 자동화해서 빠르게 빌드함.
    • 만약 변경된 코드가 빌드에 실패한다면 빠른 피드백을 줘서 워크플로우를 개선할 수 있음
  • CD(지속적 전달/지속적 배포)와 CI는 엄밀히 말하면 다르지만, 파이프라인에서 안정적으로 테스트하고 운영 환경에 성공적으로 배포하는 것을 목적으로 한다는 점은 공통적.

운영 우수성: 컨테이너 배포 자동화 및 관리형 서비스 활용

• 코드 파이프라인(AWS CodePipeline)은 소프트웨어 릴리즈 단계를 시각화하고 자동화하도록 도와줌.
  • 매월 하나씩은 무료 프리티어 파이프라인 제공
• 코드 빌드(AWS CodeBuild)는 빌드 서버를 관리할 필요 없이, 빌드에 필요한 컴퓨팅 용량만큼 컨테이너를 띄워서 빌드를 수행하고 빌드 잡이 끝나면 내려감
  • 사용한 컴퓨팅 리소스만큼만 분당 비용 지불하기때문에 효율적이고, AWS가 확장성이나 고가용성을 관리해줌.
  • 빌드 출력으로 도커 이미지를 생산할 수 있고, 이 이미지를 ECR과 도커허브 등 컨테이너 이미지 저장소에 푸쉬할 수 있음
    • 위에서 말한 ECR의 스캐닝 기능이 활성화 되어있다면, 자연스럽게 애플리케이션 배포 과정에서 취약점 검사 단계를 파이프라인 안에 녹여내게 됌.
• 위 이미지는 배포 타겟으로 aws Fargate 기반으로 컨테이너를 실행하는 예시.
  • Fargate는 EC2 인스턴스를 관리할 필요없이, ECS의 task나 EKS의 pod를 용량에 맞추어 실행할 수 있게 해주는 관리형 컴퓨팅 서비스
    • EC2를 관리할 필요가 없고, 어떤 타입의 EC2를 써야할 지 고민할 필요없이 필요한 용량을 할당받아 사용할 수 있으므로 관리 부담이 줄어듬
    • fargate는 특권모드가 불가능하고 pod간 커널,cpu,메모리,네트워크 인터페이스등의 자원을 공유하지 않도록 설계되어있어 보안 관점에서도 안전
  • gpu를 써야하거나 os 커널 설정이 반드시 필요한게 아니라면 fargate를 우선적으로 고려할 것을 권장
• CD로 배포하는 것이 익숙치 않다면 롤링 업데이트부터 시작하는 것이 좋음.
  • ECS와 EKS에 모두 적용되는 안내고, 익숙해지면 블루그린 배포나 카나리 배포등의 배포 전략에 대해서도 고려하는 것이 좋음.
  • ECS는 자체적으로 롤링 배포 방식을 지원하며, 블루그린이나 카나리 배포를 사용하려면 aws 코드 디플로이와 함께 사용하면 됌

보안

샘플 컨테이너 애플리케이션으로 보는 보안 원칙

• 예시는 ECS 기반의 3티어 샘플 애플리케이션
  • ALB를 통해 외부로부터 접근
  • ECS에서 웹앱을 구동
  • DB는 Aurora MySql
  • S3는 이미지나 로그 저장 등

보안 그룹을 이용한 네트워크 통신 제어

• 보안 위협을 줄이는 가장 첫 단계는 외부로 노출된 표면적을 줄이는 것부터 시작
  • ALB가 퍼블릭 서브넷에 있고, 외보 인터넷으로부터 80(http), 443(https)요청을 받는다면 ecs 클러스터를 퍼블릭으로 노출시킬 필요가 없음
  • ALB도 꼭 필요한 http, https 포트만 열고, ecs Aurora에도 각각 보안 그룹을 설정해서 ecs는 사용하는 포트만 열고 Aurora도 ecs에서만 접근할 수 있도록 보안 그룹을 설정하는 것이 좋음
  • ECS는 서비스 레벨에서, EKS는 pod 레벨에서 보안 그룹을 적용할 수 있으므로 익숙한 방식으로 보안 그룹을 활용하는 것도 가능

IAM 역할로 접근 제어 및 권한 관리

• 애플리케이션에 권한을 부여하기위해 IAM 유저의 액세스 키와 시크릿 키를 코드에 심어서 사용하는 경우가 있음
  • 대표적인 보안 안티패턴 중 하나
  • 크리덴셜 정보가 누출될 위험이 있고, 보안 사고가 발생했을 때 정확한 원인을 파악하기 어려움
• IAM 유저 대신 IAM 역할로 EC2나 람다, ECS등 AWS 리소스들의 권한을 제어하는 것이 안전
  • IAM 역할은 API 호출이 있을 때마다 단기 크리덴셜을 받아와 인증을 처리하고, IAM 역할이 가진 정책에 따라서 해당 요청이 허용될 지 거부될지를 결정
  • 사진 속 IAM 역할은 S3의 읽고 쓰고 리스트 하는 등 모든 작업을 허용하는 Full Access정책
• 기본적으로 ECS 태스크들은 EC2 노드가 가지고 있는 IAM 역할을 사용할 수 있음
  • ECS는 개별 태스크 레벨에서도 IAM 역할을 연결할 수 있고, EKS도 서비스 어카운트 기준으로 IAM 역할을 부여할 수 있음
  • 노드의 IAM 역할을 공통으로 쓰는 것이 아니라 task나 pod 레벨에서 필요에 따라 세세하게 권한 컨트롤을 구현할 수 있음
• IAM은 AWS 컨테이너 서비스에서 AWS 리소스에 대한 접근 제어를 간편하게 해주는 유용한 도구이며 최소 권한의 원칙을 구현하는 면에서 꼭 사용하길 권장

보안 원칙: 시크릿 관리

• ECS 서비스가 db로 접근할 때 사용하는 db password를 포함해서 외부에 노출시키면 안되는 기밀 정보들이 있음
  • ECS task definition(테스크 정의)에 플레인 텍스트로 db user와 db password를 환경 변수로 전달하는 것은 안티패턴
    • task 정의 템플릿은 암호화 되는 정보가 아니기때문에 describe task 같은 api를 수행했을 때 db password가 노출될 수 있음
    • 노출되지 않는다 하더라도 db password를 정기적으로 변경할 때, 그때마다 환경변수에서 수정하고 다시 배포해야되는 번거로움이 있음
    • 잘못하면 패스워드 오류로 인해 서비스 가용성에도 영향을 줄 수 있음

시크릿 관리: AWS Secrets Manager

• 모범 사례로 aws secret을 사용하는 것을 권장
  • secrets manager는 용도 자체가 db 접속정보를 포함해서 온프레미스나 타사 자격증명을 저장하는데도 활용할 수 있는 관리형 키밸류 스토어
  • 저장되는 정보들은 aes256 암호화로 안전하게 저장, IAM을 이용해 이 시크릿을 누가 어떤 요청을 할 수 있는 지 제한할 수 있음
  • RDS나 document DB, redshift등 AWS 데이터베이스 서비스들은 DB 크리덴셜을 자동으로 로테이션 하는 기능까지 제공
• 시크릿 매니저를 이용한 task definition을 보면(사진), 시크릿의 db user와 password를 시크릿 매니저의 my-db-secret을 이용해 api 호출 방식으로 민감한 데이터를 안전하게 받아올 수 있음

시크릿 관리: AWS Systems Manager

• 시스템 매니저의 파라미터 스토어도 유사한 기능
  • 시크릿 매니저보다는 조금 더 범용적
  • 특정 스트링을 받아올 수 있기 때문에 AMI(Amazon Machine Image) id나 라이센스 등을 받아오거나 환경 변수를 저장하는 데도 사용할 수 있음
  • 하지만 시크릿 매니저처럼 db 패스워드를 동적으로 로테이션 하는 기능은 없으므로, 자격 증명같은 데이터는 파라미터 스토어보다는 시크릿 매니저를 쓰는 걸 권장

모니터링과 로깅

애플리케이션 가시성을 확보하기 위한 설계

• Well-Architected의 모든 원칙들과도 연관있는 중요한 토픽
  • 보안 관점에서는 추정 목적으로 환경에 대한 작업이나 변경 사항을 모니터링하고 검사할 필요가 있음
  • 성능 측면에서는 애플리케이션의 성능을 저하시키는 병목이 어딘지, 원인은 무엇인지 파악하기 위해 필수적
  • 비용 최적화 면에서도 리소스가 필요 이상으로 할당되서 초과 지출하고 있는것은 아닌지 등을 판단하는 데에도 중요한 근거를 제공
• 애플리케이션 가시성을 확보하기 위한 접근 각도로는 메트릭, 로그, 트레이스를 생각할 수 있음
  • 메트릭은 특정 기간동안 일정한 시간 간격에 따라 측정된 데이터
    • cpu, 메모리, 네트워크 트래픽 양 등 숫자로 표현되고 트렌드를 파악하기에 유용
  • 로그는 특정 시점에 발생한 개별 이벤트에 대한 변경 불가능한 타임스탬프 기록
    • 애플리케이션의 오류를 조사하거나 전반적인 분석에도 활용
  • 트레이싱은 하나의 트랜잭션이 통과하는 end to end 경로와 요청 구조에 대한 가시성을 제공. 특히 마이크로 서비스에서 유용

컨테이너 메트릭: Amazon CloudWatch Container Insights

• 컨테이너 메트릭을 볼 수 있는 모니터링 도구는 다양. 여기서는 CloudWatch Container Insights를 소개
  • 컨테이너 환경의 모니터링을 위한 관리형 대시보드로, 컨테이너 인사이트는 컨테이너 레벨의 메트릭과 로그를 모니터링 할 수 있음
• 사진은 컨테이너 인사이트에서 ecs task 레벨의 모니터링을 보여줌
  • 컨테이너 데모라는 하나의 task 안에는 cloud cmd와 ecs 워크샵 크리스탈과 프론트엔드라는 세 개의 컨테이너가 포함되어있음
  • cpu 사용량을 보면 프론트앤드는 cpu가 피크 시점에 54%까지도 오르는 반면에 나머지는 두 컨테이너는 지속적으로 낮은 사용량을 보임
    • 비용 측면에서 낮은 사용량의 컨테이너 사이즈를 줄이는 등의 방안을 생각해볼 수 있음
• task 뿐 아니라 서비스 레벨에서도 모니터링을 해야 특정 서비스 안에 task가 몇개가 정상적으로 구동중인지, 설정해놓은 서비스 오토 스케일링 정책이 유효한 지 등을 검증할 수 있음
• 마찬가지로 클러스터 레벨에서도 클러스터 사이즈에 비해 너무 유휴 리소스가 많다면, 더 적은 노드 개수나 사이즈가 작은 인스턴스 타입으로 노드를 교체함으로써 비용을 최적화 할 수 있음

AWS FireLens 를 이용한 컨테이너 로그 수집 및 분석

• 사진에서는 하나의 task 안에 서비스 컨테이너와 FireLens컨테이너가 사이드카 형태로 함께 배포되어있음
• FireLens 컨테이너는 서비스 컨테이너의 로그를 수집해서 타겟으로 송출해줌
  • FireLens는 fluentbit,fluentd를 AWS 컨테이너에 최적화해서 ECR을 통해 관리형으로 제공해 주는 이미지이고 무료.
  • ECS나 EKS에서 사용 가능하고, task 레벨에서 로그를 수집할 타겟을 CloudWatch(클라우드 워치)를 포함해서 다른 저장소로도 지정할 수 있음
• 클라우드 워치는 통합 모니터링 관점에서 로그를 중앙에서 한 번에 볼 수 있고, 로그 인사이트 기능을 이용해서 간단한 쿼리 기능을 사용할 수 있다는 장점이 있음
  • 클라우드 워치 로그는 로그를 장기간 보관하는 용도의 서비스는 아님
  • 클라우드 워치 로그에서 만료기간을 지정할 수 있으니, 불필요한 로그는 자동 삭제되도록 설정
  • 로그 유형별로 차이는 있겠지만 대부분의 경우 30~40일 정도면 충분
  • 만약 그 이상의 로그가 필요하다면 장기간 저비용으로 저장할 수 있는 S3를 고려.
• S3는 저렴할 뿐 아니라 모인 데이터를 일별 주별 이런 식으로 배치성으로 아테나(Athena)를 이용해 분석할 수 있음
  • 아테나는 서버리스 쿼리 엔진으로 분석 플랫폼을 관리할 필요가 없을 뿐만 아니라 사용한 만큼만 과금하기 때문에 상대적으로 비용 효율적
• 로그를 실시간으로 모니터링하고 보다 심도있는 분석이 필요하다면, 오픈 서치(Amazon OpenSearch Service)와 키바나(Kibana)를 이용할 수 있도록 로그 송출 타겟을 오픈 서치로 지정

AWS X-Ray를 이용한 마이크로서비스 트레이싱

• 수십 개 이상의 마이크로 서비스로 구성되어 있고, ECS 뿐만 아니라 EKS, Lambda, EC2 기반의 서비스도 있으며 이들이 서로 호출하는 방식으로 되어있다면 병목 지점이나 에러 지점을 찾기 어려울 수 있음
• AWS 엑스레이는 트레이싱을 통해서 각 트랜잭션의 엔드 투 엔드 과정을 시각화하여 보여줌.
  • http 응답이 200이 아니라 300이나 400 에러코드가 났다면, 그 비중은 얼마인지, 각각의 마이크로 서비스를 호출하기까지 응답 시간은 얼마가 소요됐는 지, 시간대별로 패턴은 어땠는 지 등을 한눈에 보여줌
• 마이크로 서비스 환경에서 애플리케이션 관점에서의 모니터링이 필요하다면 엑스레이를 활용해서 성능과 안정성을 챙기는 것을 권장

비용

Auto Scaling: 안정성 및 비용 최적화

• CPU 등 클라우드 워치의 메트릭을 기준으로 필요한 컴퓨팅 용량을 조정하는 기능
• 컨테이너에서는 EC2 오토 스케일링과는 달리 노드 스케일링과 task 스케일링을 모두 고려해야 한다는 차이가 있음
• 예를 들어 ECS 클러스터 안에 두 개의 EC2 노드가 있고, 그 안에 task가 수행되고 있는 경우 (사진)
  • ECS 서비스는 태스크 수를 조정하고 Fail난 테스크를 교체하는 역할을 하는데, 이때 늘어나는 트래픽에 맞춰서 서비스 내의 테스크 수를 조정하는 것을 서비스 오토 스케일링이라고 함
  • 각각의 EC2는 리소스의 리밋이 있고, 그 임계치를 넘어설 때에는 클러스터 수준에서 EC2 노드의 수를 늘리는 방식으로 확장해야 함.
  • 클러스터 레벨의 용량을 조정하는 것을 클러스터 오토 스케일링이라고 함.
  • 클러스터 용량까지 너무 복잡하게 생각하고 싶지 않고 심플하게 구성하고 싶다면, Fargate 기반으로 구성하는 것도 좋은 방법

컨테이너 비용 최적화: 오토스케일링

• 오토 스케일링을 잘 활용하기 위해서는 어떤 메트릭을 사용할지부터 잘 선정해야함.
  • 결론은 정직하게도 실제 수요에 맞추어야 한다는 것
  • 부하 테스트를 통해서 실제로 애플리케이션이 CPU나 ALB 요청 수, 네트워크 IO 등 어떤 메트릭이 가장 긴밀하게 연관되어 있는 지, 임계치를 몇으로 설정을 할 지 결정하기 위해서는 모니터링을 통해서 그 패턴을 관찰해야 함
  • 테스트를 통해서 적절한 헬스체크 주기를 조정하고, 콜드 스타트를 고려해서 설정하는 것이 좋음
  • 실제 서비스에서는 간헐적으로 스파이크가 튈 때가 있는데, 그 때마다 컴퓨팅을 늘리는 것은 비용 효율적이지도 효과적이지도 않기 때문에, 오토 스케일리은 일정한 기간동안 높은 사용량을 지속적으로 보여야 발동 됌.
  • 만약 원하는 수준보다 너무 반응이 느리다면 클라우드 워치의 모니터링 주기를 짧게 조정하거나, 임계치를 낮게 설정하는 식으로 조정하는 것이 좋음
• 오토 스케일링은 실제 수요에 따라 컴퓨팅을 공급해서 서비스의 안정성을 높이고 비용을 최적화 할 수 있는 유용한 도구
  • 하지만 평소에 짧은 피크들이 너무 자주 치고 서비스에 영향도 미치는 수준이라면, 오토 스케일링 보다는 애초에 더 큰 사이즈의 EC2와 더 빠른 성능을 가진 EBS 볼륨을 쓰는 것이 더 적절한 선택일 수 있음
• 인프라의 메트릭만 고려할 것이 아니라 오토 스케일링이 실제로 어플리케이션의 응답시간을 줄여지는 지, 애플리케이션 관점에서 접근해야 함.
  • 만약 CPU와 메모리가 충분한데도 응답 속도가 느리다면, 코드 단의 문제일 수도 있고, DB 부하가 높아서 일수도 있으니 시야를 넓혀서 원인을 파악해야 함.

컨테이너 비용 최적화

• 컨테이너 비용을 최적화 수 있는 다른 방법에는 컴퓨팅의 타입과 사이즈를 최적화하고 요금제를 적절히 사용하는 것이 있음
• 어떤 패밀리에 어떤 사이즈 인스턴스를 노드로 사용하느냐는 비용 외에 성능에도 영향을 미치는 요소.
  • 가장 먼저 시작할수 있는 것은 최신 세대 인스턴스로 마이그레이션 해서 가격대비 더 높은 성능을 제공받는 것
  • AWS가 제공하는 코스트 익스플로러(AWS Cost Explorer)나 트러스트 어드바이저(AWS Trusted Advisor), 컴퓨터 옵티마이저(AWS Compute Optimizer)와 같은 도구들을 이용해서 어느 타입의 인스턴스를 어떤 요금제로 사용하는 것이 좋을 지 추천받는게 좋음
    • 예를 들어 지금 사용하고 있는 인스턴스는 너무 사이즈가 크고 리소스 활용이 떨어지니, 작은 타입으로 바꾸라거나 CPU 사용량이 특히 많다면 CPU에 특화된 c타입 인스턴스를 추천하는 등의 기능을 제공
  • ECS task와 EC2 리소스에 태그를 할당해서 컨테이너 별로 정확히 그룹화해서 분석하기 위해서는 ECS task에 tag를 할당하는 것이 이상적
  • AWS Fargate는 컨테이너를 실행하는데 필요한 리소스에 대해서만 비용을 지불한다는 이점과 함께 요금제 유형에 따라 가격을 절감할 수 있음
    • 장기적으로 예상되는 사용량은 세이빙스 플랜으로 약정할인을 받는 것이 비용을 크게 절감할 수 있는 방법
    • 스팟 인스턴스는 유휴 자원을 최대 90퍼센트까지 할인된 가격으로 이용할 수 있어, 중단 가능성이 있지만 비용이 아주 저렴해야만 유의미한 워크로드라면 이를 활용하는 것도 좋음

Summary

ECS Cats and Dogs 워크샵

• ECS나 컨테이너에 아직 익숙하지 않거나 여기서 소개한 내용을 실습으로 해보고 싶다면, ECS Cats and Dog 워크샵을 해보는 것을 추천
  • ECS 기반으로 마이크로 서비스를 배포하고, 컨테이너 인사이트와 파이어 렌즈를 이용해 모니터링을 하며, AWS 코드 시리즈를 이용해 CI/CD 파이프라인을 구축.
  • 서비스와 클러스터 오토 스케일링을 실습할 수 있음

🔗ECS 워크샵 링크
https://catalog.us-east-1.prod.workshops.aws/workshops/8c9036a7-7564-434c-b558-3588754e21f5/ko-KR