AWS]ECS Fargate X86에서 ARM으로

320x100

300x250

회사에서 EC2보다는 ECS를 더 사용하기로 했기 때문에
RI 준비를 하면서 기존에 EC2를 ECS로 전환하는 작업을 진행했다.

 

그중에서도 X86 아키텍처와 ARM 아키텍처 중, 선택지가 있었는데
아무래도 비용이나 성능면에서나 더 좋은 ARM 아키텍처 기반의 환경을 선택하기로 했다.

 

Savings Plan을 적용했을 때의 요금표는 다음과 같다.

* 기준 : 서울리전/리눅스/선결제 없음 

X86 ECS Fargate 요금표

 

ARM ECS Fargate 요금표

두 요금 표는 소숫점으로 봐서 별 차이가 안 날 수 있지만
Fargate를 사용하는 vCPU와 RAM의 합산 요금을 기준으로 계산되기 때문에 실질적으로 큰 차이가 난다.

 

ARM이 X86대비 시간당 RAM(GB)은 약 20%, CPU는 19.7%

둘 다 대략 약 20%가 저렴하다.

 

그렇다면 왜 더 싼걸까?

 

일단 몇 가지 이유가 있다.

 

애플에서도 맥북을 출시할 때 언급했던 것처럼 기존 X86기반의 인텔 CPU에 비해
ARM기반의 Apple Silicon은 더 적은 전력 소모로 더 큰 효율을 낼 수 있다.

 

ARM 아키텍처 기반이 원래 모바일 및 IoT용이었어서, 더 적은 전력을 사용하도록 설계되었지만

하드웨어의 엄청난 발전속도가 이를 가능하게 만들었다.

그 덕분에 AWS에서도 같은 시간대비 더 저렴한 전력으로 더 많은 효율을 내는

ARM 기반의 인스턴스를 X86보다 더 많이 사용할 수 있다.

 

물론 아직 X86의 점유율이 더 높아 이 점유율을 더 확보하려는 차원도 있을 것이다.

 

 

 

 

 

---

단점

내가 지금 업무 및 개인용으로 사용하는 M1 Pro 모델도 ARM 기반의 노트북인데,

아무래도 출시 초반에는 Docker 및 Java , Third Party Library 등 호환성 문제가 있어 로제타로 실행된다거나

애플에서 언급했던 것처럼 눈부신 성능 차이를 경험하기 힘들었다.

 

그러나 몇 달 지나지 않아서 Docker에서는 ARM기반 아키텍처도 지원하도록 업데이트했고

개발용 소프트웨어뿐 아니라 로제타로 구동되던 다양한 앱들도 ARM을 지원하기 시작했다.

 

출시 초기에는 이는 분명한 단점이었고, 아직까지도 미호환 혹은 로제타로 구동되는 앱들이 많이 있다.

그러나 ARM으로 넘어가는 속도는 굉장히 빠르다.

 

또 하나의 단점은 앞서 언급했던 것처럼, 아직까지도 X86의 점유율이 압도적이기에

개발을 하는 나의 입장에선 ARM에서 일어날 수 있는 트러블 슈팅에 대한 레퍼런스가 매우 적었다.

 

이는 개인 개발환경뿐 아니라 AWS에서도 많이 찾아볼 수 있다.

EC2, Lambda, ECS 등 다양한 서비스들이 ARM을 지원하는 초기에는 호환성 문제가 굉장히 많았다.

 

ECS로 전환하기 위해 작성했던 Dockerfile 조차도 ARM을 지원하는 이미지를 찾아다니는 수고스러움도 더해졌다.

뿐만 아니라 애플리케이션에서 사용하던 라이브러리들도 오류가 나는 경우가 굉장히 빈번했다.

 

 

 

 

---

ARM으로 전환하면서 맞이했던 몇 가지 지금 생각나는 문제들을 적어보면

 

1.Dockerfile에 JDK를 베이스 이미지로 지정했는데 ECS에서 Task에 헬스체크가 실패하여 장애가 나는 문제.

이 문제는 별생각 없이 JDK alphine 이미지니까 당연히 되겠지 했는데, 

내가 선택했던 이미지에는 cURL이 없었던 문제였다.

ECS 컨테이너 헬스체크 명령어를 

CMD-SHELL, curl -f http://localhost:8080 || exit 1으로 지정했는데,

cURL이 없으니 지속적으로 헬스체크 실패 -> ECS에서 비정상적인 서비스라고 판단 -> 중지 -> 재배포의 과정이 무한히 일어났다.

이 과정이 무한히 일어나면서 특정 횟수 이후에는 ECS의 서비스가 삭제되는 일도 생겼다.

(이 서비스가 자동으로 삭제되면 같은 이름으로 서비스를 만들 수 없는 버그가 있다... ㅂㄷㅂㄷ;;  이거 때문에 CodeBuild 설정도 수십 번 바꿨다.)

 

결국엔 OpenJDK에서 DockerHub에서 공식 제공하는

arm64v8/openjdk:11.0.11-9-jdk-oraclelinux7

이미지를 사용하여 해결하였다.

 

 

 

 

 

2.AWS CodeBuild 빌드 실패

처음엔 위 이미지와 같이 CodeBuild 환경에서 사용자 지정 이미지 -> ARM으로 선택해야지 했는데,

위와 같은 환경으로 빌드를 하게 되면 빌드 로그가 나오지 않아 디버깅을 할 수 없는 문제가 있다.

 

서비스 실행역할에 대한 권한문제인가?라는 의문이 들어서 CloudWatch FullAccess도 줬는데 나오지 않았다.

위 이미지 대로 사용하자.

이 환경을 사용하고 서비스 실행 역할에 적절한 CloudWatch 권한만 있으면 빌드 로그가 잘 출력된다.

 

그리고 이미지 하단에 

도커 이미지를 빌드하거나 빌드의 권한을 승격하려면 이 플래그를 활성화합니다.

라는 체크박스를 꼭 체크해 주자.

 

기본이 체크가 안되어있는데, 저 체크박스 옵션이 없으면 런타임에 docker가 설치가 되어있지 않거나 권한 에러가 발생한다.

 

 

 

 

 

3.Java Mail 라이브러리 문제

회사에 오래된 프로젝트에서 Spring-boot-starter-mail이 아닌 오래된 javax.mail 1.4를 쓰고 있었는데,

이 부분에서 지속적인 에러가 발생하여 서비스가 다운되는 일까지 생겼다.

 

이 문제는 버전 업데이트를 하면서 해결.

 

앞으로도 다르 서비스들도 ARM으로 전환 예정인데, 트러블 슈팅 때마다 기록 및 타인에게 레퍼런스용으로 남겨둬야겠다.