Intel 천지였던 PC 분야에 ARM
이 광풍을 불기 시작한지 얼마 되지 않았습니다.
이에 개발자도 변화를 감지 하고 대응하기 위해 알아야 할 것들을 정리 했습니다.
그동안 암묵적으로 대부분의 서버 환경이 Intel 기반 이므로 달리 묻지 않고 사용 했습니다.
하지만, 이제 ARM
서버가 대중화 되고 있으므로 구분해서 사용 할 수 있어야 합니다.
Ghz
(기가헤르츠) 라는 단위를 사용 하며 정확히는 주파수의 진동 횟수 입니다만,
다 빼고, 쉽게 말해 그냥 코드가 실행 되는 속도 이고 이 수치가 높을 수록 빠릅니다.
단일 코어 스피드는 기술 한계로 4Ghz 이상으로 쭉쭉 못가고 있으니까, 병렬로 늘리기 시작했죠.
그래서 언제부턴가 클럭 속도 보다 CPU 갯수로 수요를 커버 하고 있습니다.
다들 아시는 인텔 인사이드 (파란 인간 모델) 회사로, PC용 으로 가장 많이 사용하고 가장 안정적(?) 입니다.
안정적이라는 의미는 Intel 에 맞춰 개발한 소프트웨어가 오래 사용되고 다양한 분야에서 검증되어 안정적이라는 뜻입니다. 하드웨어 자체의 안정성은 어느 제조사나 이제 다 비슷 비슷 하다고 생각 합니다.
Intel은 x86 아키텍처
의 CPU를 만듭니다.
Intel 의 x86
호환 CPU를 만드는 회사
한때 인텔보다 클럭 속도가 더 빠르면서도 더 저렴한 CPU를 내놓았지만
아직도 Intel 을 이기지는 못한 회사 (힘내 암드야 ㅠㅠ ← 이거 어디서 한번씩 보신적 없으신가요?)
위 2개 회사 와는 다르게 ARM
은 x86
과 전혀 다른 아키텍처를 사용합니다.
과거의 ARM
은 단순한 아키텍처와 함께 가격이 저렴하고 저전력을 갖춰 소형기기에 많이 사용 했습니다.
스마트폰 시대에 접어들면서 모바일 용으로 많이 쓰이다 보니 엄청난 발전으로
속도 면에서 이제 PC에 근접한 수준에 이르렀습니다. (엑시노스... 많이 들어봤죠? ← 삼성의 ARM CPU
입니다.)
반면에 저렴한 가격과 저전력은 유지했죠.
이로 인해 PC용 ARM
을 사용하는 시도가 많아졌고
AWS가 자체 개발한 ARM
CPU로 만든 서버인 Graviton
이라는 인스턴스를 내놓으면서 서버 시장에 불을 피우고, Apple이 자체 개발한 M1 CPU
로 맥북을 내놓으며 PC시장에도 불이 붙었습니다.
ARM
이라는 회사가 존재 합니다만, 누구든지 ARM
을 기반으로 커스텀한 칩을 직접 만들어서 팔아도 된다고 알고 있습니다. (할 수 있는 능력이 있다면 말이죠.)
Intel 호환을 만드는 AMD
같은 거죠. 하지만 인텔과 AMD는 상호 라이센스를 체결해서 두개 회사에서만 제조가 가능 합니다.
그러니까 M1 칩은 ARM
이 만들어 준게 아니라, Apple이 만든 ARM 호환 CPU
입니다.
x86
과 amd64(x86_64)
, arm
과 arm64/v8
이런 글자들 어디서 보지 않았나요?
이것들은 CPU 아키텍처의 이름 입니다.
각 소프트웨어는 실행되려면 컴파일 되거나 동작 환경이 갖춰 져야 합니다.
요즘은 밑바닥부터 전부 다 스스로 만들지 않고 온갖 라이브러리를 쓰죠.
그런데, 대부분의 라이브러리는 특정 CPU 아키텍처에 맞게 사전 컴파일 되어 있는 것을 갖다가 씁니다.
Linux
로 치면 *.so
라고 하는 Shared Object
를 쓰고요. 윈도우
라면 *.dll
이죠.
예전에는 서버라고 하면 전부 인텔
이나 AMD
를 쓰고 x86
이나 x86_64
를 사용 하니까
그냥 사전 컴파일 해서 배포해도 별 문제가 안됐는데요.
이제는 다릅니다. ARM 서버가 등장
했기 때문이죠.
모바일 앱은 ARM 아키텍처
로 만들어 집니다.
PC 는 M1 Mac
이 아니면 죄다 x86_64
죠.
그냥 실행이 안됩니다. 가끔 된다고 하는 것들은 전부 에뮬레이터를 쓴 겁니다.
반대로 M1 Mac 이 ARM 이니까... iOS 용 앱이 에뮬레이터 없이 돌아가겠네?
맞습니다. M1 Mac 에서는 iOS 앱
들이 다 구동 됩니다.
(에뮬 없이, 네이티브 성능으로)
프로그램은 결국 컴파일 된 바이너리 입니다. (스크립트 언어는 예외로 하죠)
이때, 이 컴파일을 어떤 CPU로 했는지에 따라 결과물이 정해집니다.
x86 머신
에서 빌드한 라이브러리를 그냥 arm
에 가져오면 실행이 안됩니다.
반대의 경우도 마찬가지 입니다.
하지만 x86
에서 빌드한 라이브러리를 x86_64
에서는 가능 합니다.
x86_64
가 하위 호환을 지원 하기 때문이죠.
이런식 입니다.
따라서 내가 사용하고자 하는 라이브러리가 있다면,
우선 이 라이브러리를 실행할 서버의 아키텍처를 이제는 알아야만 합니다.
그에 맞게 라이브러리를 설치해야 하고요.
라이브러리의 소스코드가 공개되어 있고 직접 컴파일이 가능하다면 본인이 직접 ARM 머신에서 컴파일해서 쓰면 됩니다.
소스코드가 없고, ARM
을 지원하지 않는다면 일단 불가능 합니다.
Apple이 신의 한수를 써놨습니다만, 유저 입장에서는 좋죠.
M1 Mac 에서 Intel... 아 우리는 배웠으니 x86
이나 x86_64
으로 빌드된 프로그램을 실행 할 수 있는 이유는 Rosseta
라는 에뮬레이터가 있기 때문 입니다.
이것은 ARM 머신 내부에 x86 가상환경
을 만들고 그 안에서 실행하는 방식 입니다.
에뮬레이터 라는게 다 그런거죠.
따라서 성능의 저하가 있습니다. (애플은 거의 없다고 하지만, 없을 수가 없죠.)
에뮬레이터는 우리가 말을 할때 번역기를 거치는 것과 같습니다.
아니요. 도커도 이미지를 빌드하는 환경의 영향을 받아 그에 맞는 이미지가 만들어집니다.
다만, 도커 허브의 이미지들은 편의를 위해 다양한 아키텍처별로 같은 이미지 이름으로 업로드 되어있습니다.
mysql 도커 이미지의 예시인데, 이제 그동안은 잘 안보이던 회색 태그가 눈에 들어올 거에요.
Linux
, x86-64
, ARM 64
....
같은 mysql:latest
를 pull 받더라도 내부적으로
그 머신의 CPU에 따라 맞는 아키텍처를 받는 것이 도커의 기본 동작 입니다.
만약, 특정 아키텍처의 이미지를 강제로 받으려면 옵션이 필요 합니다.
docker pull --platform=linux/arm64 mysql:latest
이렇게 말이죠. 자세한 것은 도커 매뉴얼을 참고하세요.
유명한 언어는 대부분 ARM
, Intel
모두 지원 하므로 큰 상관 없습니다.
하지만, php
처럼 Linux 확장 모듈을 불러다 쓰는 기능이 있을 경우 문제가 됩니다.
java
의 경우는 대부분 소스코드 형태의 라이브러리가 많기 때문에 CPU 아키텍처에서 대부분 자유롭다고는 합니다만 요즘은 반드시 100% java로 개발되지 않는 경우도 많아 면밀히 확인 해야 합니다.
node.js
의 경우는 수백만개의 npm 라이브러리 때문에 좀 문제가 됩니다.
라이브러리 중에는 linux 의 시스템 명령을 사용하는 것도 많고 gifsicle, imagemagick 등 이미지 처리를 위한 다른 모듈의 도움을 받는 경우도 많은데, 사전 컴파일 된 모듈이 필요한 경우 문제가 됩니다.
npm
을 가지고 직접 실험을 해보는 수 밖에 없어요.
개발자는 그동안 Intel
아키텍처로 통일된 서버 환경에서 잘 살아왔지만... 이제는 ARM
서버 등장과 함께 CPU 아키텍처
를 명확히 구분할 수 있어야 합니다.
긴 글 읽어주셔서 감사합니다.
2022 매튜(@480)
헷갈렸는데, 재밌게 정리해주셨네요.
감사합니다!