AWS Graviton은 AWS가 2018년에 출시한 ARM 아키텍처 기반의 서버 프로세서 시리즈입니다.
AWS는 Garaviton을 출시 이후로부터 꾸준히 밀고 있습니다. 홍보하는 문구는 꾸준히 동일합니다.
더 빠르고, 더 성능이 좋고, 더 싸다는 식이죠.
아무리 AWS 라고 해도 그들이 하는 말을 비판적인 자세로 받아들일 필요는 있습니다. 사실 문구만 보면 인텔칩으로 서버 돌리면 바보잖아요? 아무리 arm마이그레이션이 공수가 드는 작업이라도 해도요.
사실 대부분의 개발자는 x86보다 arm이 성능이 좋다고 무의식적으로 다 알고 있습니다. apple의 intel칩-M1칩을 통해서요. 팬이 없으면서도 발열이 적고 배터리가 오래가는 맥북은 arm칩에 대한 의구심을 모두 지워버릴 정도로 훌륭했죠.
하지만 arm칩(ex. AWS Graviton & Apple M1)이 Intel 및 AMD의 x86 칩보다 어떻게 저렴하고 빠를 수 있다는 것일까요? Apple이나 AWS가 해당 기기를 사용하는 방식에 맞게 최적화를 해서 그런 것일까요? 반은 맞지만 반은 틀립니다.
이 이유를 설명하기 위해 두 개발 팀이 존재한다고 가정해보겠습니다.
- Team x86에는 엔지니어 4명과 매니저 6명이 있습니다.
- Team Arm에는 엔지니어 6명과 매니저 2명이 있습니다.
이것이 바로 arm칩이 20% 더 적은 비용으로 50% 더 많은 생산량을 얻을 수 있는 방법입니다.
x86 팀에 왜 그렇게 많은 매니저가 있을까
비유를 계속하자면, 두 팀이 모두 풀 스택 엔지니어링 팀이라고 상상해 보겠습니다.
x86 팀은 대규모 기업들의 외주 서비스를 제공해 드리기 위해 일하는 SI팀입니다.
C/C++의 고성능 백엔드 유지부터 Python의 웹 애플리케이션, Javascript, CSS 및 HTML의 프론트엔드에 이르기까지 모든 종류의 기존 프로젝트를 지원해야 합니다.
C/C++에 능숙한 엔지니어도 있고, 파이썬에 능숙한 엔지니어도 있고, 웹 기술에 능숙한 엔지니어도 있습니다.
예를 들어 C/C++ 담당자는 Cobol도 어느 정도 알고 있는 등 팀원 각자가 몇 가지 언어를 정말 잘 알고 있습니다. 유지보수 작업이 필요한 경우 두 가지를 모두 처리할 수 있는데, 보통은 문제가 없지만 대규모 C/C++ 프로젝트와 회사의 레거시 메인프레임에 대한 Cobol 유지보수 작업을 동시에 수행해야 하는 경우 문제가 될 수 있습니다.
고객은 자신이 원하는 것이 무엇인지 정확히 알지 못하는 경우가 많기 때문에 고객이 무엇을 의미하는지 파악하고, 개발자의 이해를 돕도록 유저 스토리를 만들고, 엔지니어를 최대한 활용하고 모든 것이 고객을 위해 이루어질 수 있도록 하는 매니저 역할의 관리자가 필요합니다.
또한 어떤 이유로든 시간대가 다른 두 그룹으로 나뉘기도 합니다. 같은 국가에서 전적으로 처리할 수 있는 소규모 프로젝트에는 적합하지만, 때때로 함께 작업해야 하는 경우 다른 그룹에 일을 넘겨야 할 때 어려움을 겪을 수 있습니다.
Arm 개발팀
Arm 팀도 풀스택 팀이지만 자바스크립트를 기반으로 표준화했습니다.
누구나 자바스크립트를 알고 있으며 백엔드와 프론트엔드 모두에서 사용할 수 있습니다. 프로젝트는 서로 비교적 유사하며 많은 컴포넌트를 여러 프로젝트에서 재사용할 수 있습니다.
또한 각 엔지니어는 주어진 시간에 하나의 프로젝트에만 전념합니다. 할 일이 많지 않을 때는 엔지니어가 HackerNews를 보면서 시간을 보내거나 커피를 내리는 데 시간을 보내는 등, 인력 낭비로 보일 수 있지만 일이 한 번에 많이 몰릴 경우 각 엔지니어가 하나의 프로젝트에 집중하는 형식이 부하 해결에 많은 도움이 됩니다.
또한 자체 개발팀을 운영하기 때문에 외주형식이 아닌 사내에서 정직원으로 채용하고 있으며, 모두 같은 공간에 앉아 일하고 있습니다.
여전히 일부 매니징 역할의 관리자가 필요하지만 x86 팀처럼 큰 규모가 필요하진 않습니다.
arm, x86 칩도 동일합니다
arm, x86 칩 세계에서도 똑같습니다.
x86은 레거시가 많고 다양한 크기의 명령어가 포함된 복잡한 명령어 세트를 가지고 있으므로 높은 명령어 수준의 병렬성을 달성하기 위해 많은 ‘관리 포인트’가 존재하므로 칩이 복잡하고 전력 소모가 큽니다.
Arm은 고정된 크기의 명령어를 가지고 있어 적은 "관리 포인트"로 더 높은 명령어 수준의 병렬 처리가 가능하므로 더 많은 실행 유닛을 보유할 수 있어 더 적은 전력을 소비하면서도 더 많은 작업을 수행할 수 있습니다.
여기서 헷갈리면 안 되는 건 arm팀과 x86팀은 비유, 예시로 든 것이고 실제로 x86이 C/C++을 더 잘하고 arm이 자바스크립트를 쓴다는 건 아닙니다! x86칩의 명령어 세트 특성이 deep하고 width가 적고 arm칩의 명령어 세트 특성이 두루두루 사용하는 멕가이버 특성이 있다는 의미입니다.
또한 특정 요구 사항에 맞게 자체 제작하는 맞춤형 실리콘으로, 일정변동과 라이센스 등의 추가 비용을 피할 수 있다는 장점도 있죠.
Graviton은 하이퍼스레딩도 없다
AWS Graviton 인스턴스 유형과 다른 인스턴스 유형 간의 주요 차이점 중 하나는 vCPU와 물리적 프로세서 코어 매핑입니다. Graviton 타입의 모든 vCPU는 물리적 코어입니다.
모든 vCPU가 물리적 코어가 아니었어?
x86 기반 인스턴스에서 "vCPU"로 표시되는 것은 실제로 하이퍼스레드입니다. 즉, 애플리케이션 프로세스에 의한 100% 사용률 미만의 각 vCPU는 대략적으로 두 개의 가상 코어로 분할된 물리적 CPU 코어의 절반을 얻습니다.
공식문서에서는 다음과 같이 설명하고 있습니다.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-optimize-cpu.html
Amazon EC2 인스턴스는 멀티스레딩을 지원하므로 단일 CPU 코어에서 여러 스레드가 동시에 실행될 수 있습니다. 각 스레드는 인스턴스에서 가상 CPU(vCPU)로 표시됩니다. 인스턴스에는 인스턴스 유형에 따라 달라지는 기본 CPU 코어 수가 있습니다. 예를 들어 m5.xlarge 인스턴스 유형에는 기본적으로 2개의 CPU 코어와 코어당 2개의 스레드(총 4개의 vCPU)가 있습니다.
따라서 하이퍼스레딩을 특별히 비활성화하지 않는 한, x86의 vCPU는 사용률이 높을 때 실제로는 물리적 CPU 코어의 절반에 불과합니다. 이는 일반적으로 전체 CPU 사용률이 낮고 실행할 작은 프로세스가 많은 시나리오에서는 잘 작동하지만, CPU가 병목 현상이 발생하고 애플리케이션이 CPU의 최대 성능을 요구하면 하이퍼스레딩이 더 나빠집니다.
실제로 2개의 코어로 지원되는 4개의 vCPU로 구성된 서버와 4개의 코어로 지원되는 4개의 vCPU로 구성된 서버의 높은 사용률일 때를 비교하는 벤치마크는 후자의 서버가 더 나은 퍼포먼스를 보인 것으로 나타난다고 합니다.
정리하자면 Graviton에는 하이퍼스레딩이 없습니다. 즉, 모든 vCPU는 물리적 프로세서 코어의 모든 기능을 지원합니다. 따라서 가상 하이퍼스레드 CPU 코어와 물리적 CPU 코어의 근본적인 차이로 인해 Graviton 코어가 성능 측면에서 x86 인스턴스보다 더 괜찮습니다.
GCP랑 Azure는 놀고만 있나?
GCP의 T2A VM은 2022년 7월에 Google 최초의 ARM 기반 가상 머신의 인스턴스를 출시했습니다.
Azure도 2021년 4월 Ampere® Altra® Arm 프로세서를 기반으로 하는 Azure 가상 머신 제품군의 미리 보기를 발표했습니다.
한 벤치마킹 기업에서 각 클라우드 벤더사의 arm인스턴스 QPS(queries per second) 테스트를 한 결과,
성능 테스트 결과와 가격 대비 성능 비율 분석을 통해 AWS Graviton3이 GCP T2A 및 Azure Dpsv5보다 성능이 뛰어나고 비용 효율적이고 합니다. 아무래도 선두주자이니만큼 좋은 결과를 받은 것 같네요.
더불어 최근 클라우드사의 arm칩 경쟁이 흥미롭다는 걸 알 수 있습니다. 좋은 경쟁으로 유의미한 성능의 인스턴스가 더 많이 시장에 나왔으면 좋겠네요.
읽어주셔서 감사합니다.
출처
https://api7.ai/blog/arm-performance-google-aws-azure-with-apisix
https://www.reddit.com/r/aws/comments/17gtcd0/how_can_arm_chips_like_aws_graviton_be_faster_and/
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-optimize-cpu.html
'🏋️♀️ DevOps, SRE' 카테고리의 다른 글
엔보이(envoy) 딥-다이브 (2) : 엔보이 로깅의 2가지 종류 (1) | 2024.02.27 |
---|---|
엔보이(envoy) 딥-다이브 (1) : 엔보이가 패킷을 받아 처리하기 까지 (1) | 2024.02.11 |
Renovate bot을 사용해 argoCD로 배포한 helm 차트 버전을 체계적으로 관리해보자 (1) | 2024.01.09 |
Github Actions Kubernetes에서 self-hosted 설치&운영하기 (0) | 2023.09.05 |
DevOps vs SRE , 차이점과 공통점에 대해 (0) | 2023.08.22 |