[아이티데일리] 아마존웹서비스(AWS)는 그간 인텔(Intel)·AMD가 주도해 온 ‘x86’ 프로세서 생태계에 변화를 주고자, 최근 ARM64 기반의 ‘그래비톤(Graviton)’을 전면에 내세우고 있다. 이 가운데 글로벌 영상 스트리밍 플랫폼 기업 ‘하이퍼커넥트’는 비용효율성을 확보하기 위해 x86에서 그래비톤으로의 마이그레이션을 선제적으로 수행하며 인프라 비용을 크게 절감했다. 현재는 영상 서비스, CI/CD 파이프라인 등 80% 이상의 하이퍼커넥트 인프라가 AWS 그래비톤으로 구동되고 있다. 하이퍼커넥트의 이선엽 데브옵스 엔지니어를 만나 AWS 그래비톤으로의 마이그레이션 여정을 들어봤다.

하이퍼커넥트는 2014년 설립된 글로벌 영상 기술 기업이다. 영상 메신저 ‘아자르(Azar)’와 소셜 라이브 스트리밍 서비스 ‘하쿠나 라이브(Hakuna live)’, 그리고 B2B 엔터프라이즈 사업을 영위하고 있다. 창립 초기부터 AWS 클라우드 서비스를 활용해 왔으며, 현재 전 세계 각지의 10개 이상 리전을 이용할 정도로 글로벌 이용자들이 빠르게 증가하고 있다. 이 같은 서비스·이용자 증가세에 따라, 하이퍼커넥트의 인프라 비용 지불도 점차 늘어났다. 이에 하이퍼커넥트는 비용과 에너지 효율성을 갖춘 AWS 그래비톤 프로세서로의 마이그레이션을 결정했다.

AWS 그래비톤은 아마존 EC2(Amazon EC2)에서 실행되는 ARM64 기반 설계 프로세서 제품군이다. 이전까지 서버용 칩 시장은 인텔과 AMD의 x86 프로세서가 주도해 왔다. 하지만 최근 애플(Apple)과 AWS 등 빅테크 기업들이 ARM 아키텍처를 기반으로 한 프로세서 지속적으로 개발·투자하며 ARM 생태계를 확장해 가고 있다.

하이퍼커넥트는 대표적인 ARM64 기반 프로세서인 AWS 그래비톤을 도입해 기존 사용하던 x86 대비 아마존 EC2 인스턴스 기준 20% 이상 비용을 절감하는 효과를 거뒀다. 이후 대고객 서비스부터 내부 개발 프로세스까지 80%에 달하는 인프라를 AWS 그래비톤으로 전환해 구동하고 있다.

다만 예전보다 ARM 프로세서에 대한 시장 인식이 긍정적으로 변화했다고는 하더라도, 여전히 대다수의 오픈소스, 소프트웨어(SW), 서버는 x86에 대해서만 최적화와 유지 보수가 지원되는 경향이 크다. 이는 AWS 그래비톤과 같은 ARM64 기반 프로세서로 마이그레이션할 때 테스트와 최적화를 더욱 심층적으로 해야 하는 이유이기도 하다.

하이퍼커넥트 이선엽 데브옵스 엔지니어와의 인터뷰를 통해 AWS 그래비톤 마이그레이션 과정과 유의할 점을 알아본다.

AWS 클라우드로 글로벌 영상 서비스 기반 갖춰

Q. 하이퍼커넥트가 활용 중인 AWS 서비스는.
A. 우리는 창립 초기부터 AWS 클라우드 서비스를 도입해 왔다. 글로벌 영상 서비스를 하다보면 전 세계에서 많은 트래픽이 발생하는데, AWS 클라우드는 서버를 유연하게 조절하며 트래픽과 여러 이슈에 대응할 수 있다는 점이 우리에게 주는 가장 큰 가치였다. 현재는 세계 각지의 10개 이상 리전을 사용하고 있다.

구체적으로 관리형 쿠버네티스 서비스인 ‘아마존 EKS(Amazon EKS)’를 40개 이상의 클러스터를 생성해 이용하고 있으며, 외부 트래픽을 서버로 균등하게 나눠주는 ‘엘라스틱 로드 밸런싱(ELB, Elastic Load Balancing)’과 클라우드 스토리지 ‘아마존 S3(Amazon S3)’, ‘아마존 오로라(Amazon Aurora)’ DB, 특히 최근 마이그레이션을 완료한 EC2 기반 ‘AWS 그래비톤(AWS Graviton)’ 프로세서 등 다양한 서비스를 활용 중이다.

우리의 인프라 아키텍처를 소개한다면, 먼저 앱 사용자들의 요청이 클라우드플레어(Cloudflare) 네트워크 서비스를 통해 우리의 AWS 클라우드로 들어온다. 이후 ELB 로드 밸런싱을 거쳐 쿠버네티스 클러스터 내부에 진입하고, 내부에는 서비스 메시(Service Mesh)인 ‘이스티오(Istio)’ 게이트웨이가 각각의 마이크로 서비스에 해당 요청을 전달한다.

Q. CI/CD 파이프라인은 어떻게 구성돼 있는가.
A. 우리 개발자들은 AWS 클라우드 내에서 개발한 내용을 ‘깃허브 엔터프라이즈(GitHub Enterprise)’를 활용해 공유한다. 디벨로퍼 포털(Developer Portal) 기능으로 개발 내용과 마이크로 서비스에 대한 정보를 입력할 수 있고, 이러한 등록을 거친 후 깃허브 엔터프라이즈에서 소스 코드를 함께 공유할 수 있다.

디벨로퍼 포털에서 마이크로 서비스 배포를 요청하면 오픈소스 파이프라인인 ‘스피내커(Spinnaker)’가 자동으로 생성된다. 도커(Docker) 이미지 생성과 쿠버네티스 배포를 위한 파이프라인도 있다. 파이프라인 실행 후에는 젠킨스(Jenkins)에서 도커 이미지를 기획하고, 빌드한 결과물은 하버(Harbor) 이미지 저장소에 올라간다. 다음 파이프라인 단게에서는 하버에 올라간 이미지를 쿠버네티스 배포 방식 데이터를 헬름(Helm)을 통해 구성하고, 이 과정이 실제 쿠버네티스에 적용되면 새로운 버전을 무중단으로 배포하게 되는 CI/CD 구조다.

“인텔 x86보다 20% 이상 저렴”

Q. AWS 그래비톤 프로세서를 이용하고 있는데, 도입 계기와 강점은.
A. 우리가 그래비톤 프로세서를 처음 도입한 시기는 2022년 3월 경이다. 우리가 운영하는 제품과 서비스가 많다 보니 이전까지 인프라 비용을 정말 많이 지불해 왔다. 이에 우리는 인프라와 시스템의 비용 절감 효과를 기대하며, 비용 효율이 강점인 AWS 그래비톤 프로세서 활용을 고려하게 됐다.

당초 계획은 모든 시스템을 그래비톤으로 옮기는 것은 아니었다. 내부에 실험적으로 도입했는데, 비용적인 측면에서 만족도가 높아 지난해 1월부터 본격적으로 완전한 마이그레이션 프로젝트를 진행했다. 이를 통해 현재까지 전체 인프라의 80%를 그래비톤으로 마이그레이션 했다. 실제 EC2 인스턴스 기준 그래비톤이 인텔 x86 프로세서 대비 비용이 20%가량 저렴했다. 산술적으로는 우리 인프라의 80%를 옮겼기에 이전보다 16% 정도의 총비용을 절감하게 된 셈이다.

지금은 우리 앱 사용자들의 영상 서비스를 비롯해 사내 DB, CI/CD 파이프라인 등 내부 시스템까지 가능한 모든 영역에서 그래비톤을 활용하고 있다. 내부 빌드 혹은 개발자들의 주기적인 작업, 자동화 스크립트 등 거의 모든 작업들이 그래비톤 프로세서에서 구동된다.

“ARM64 프로파일링 및 최적화 유념해야”

Q. 그래비톤 마이그레이션 과정을 소개해 달라.
A. 우리는 마이그레이션 과정이 긴 기간이 걸릴 것을 예상해 계획과 전략을 꼼꼼하게 수립했다. 먼저 우리 서비스와 사용 중인 EC2 인스턴스를 리스트업했다. 이후 마이그레이션할 수 있는 안전한 서비스와 그렇지 않은 서비스를 분류해 80% 전환이라는 목표치를 설정했다.

분류한 서비스들 중 리스크가 낮은 내부 서비스부터 마이그레이션을 시작했고, 그래비톤에 대한 숙련도를 끌어올리는 과정을 거쳤다. 그런 다음 GPU 사용률이 높은 머신러닝(ML) 관련 서비스들도 마이그레이션했다. 마지막으로 난이도와 리스크가 높은 서비스도 최대한 그래비톤을 활용하고자 한다.

Q. 마이그레이션 과정에서 어려운 점은 없었는가.
A. 파이썬(Python) 서버를 최적화하는 과정이 쉽지 않았다. 파이썬 이외의 다른 언어로 구성된 서버들은 프로세스 아키텍처와의 연관도가 적어 마이그레이션하기 비교적 수월했다. 하지만 파이썬 같은 경우에는 프로세스 아키텍처에 의존적인 라이브러리들을 많이 사용하고 있어, 그래비톤과 같은 ARM64 아키텍트로 옮기는 게 힘든 일이었다.

일단 파이썬 서버의 의존적인 라이브러리들이 ARM64를 지원해야만 이미지 빌드가 가능하다는 문제가 있다. 만약 라이브러리가 더 이상 유지 보수되지 않는 경우에는 라이브러리의 소스 코드를 바탕으로 빌드를 직접 해야될 수도 있다. 이런 방식으로 빌드를 했다고 가정하면, 또 성능 문제가 생길 수도 있다.

인텔의 점유율이 높다 보니, 보통 업계에서 사용하는 서버와 소프트웨어(SW)는 인텔 x86 프로세서에는 대다수 최적화돼 있다. 반면에 그래비톤과 같은 ARM64 기반 프로세서는 근래 보급이 이뤄지고 있어, 최적화와 성능적인 면을 중점적으로 분석해야 한다. 그래서 우리는 서비스를 그래비톤으로 마이그레이션할 때 CPU 프로파일링을 심층적으로 수행했다.

Q. 프로파일링과 최적화를 좀 더 설명한다면.
A. 프로파일링은 쉽게 말하면, 컴퓨터가 어떠한 기능을 하는 데 시간을 얼마나 썼는지를 파악할 수 있는 기술이다. 가령, x86 프로세서 기반에서는 특정 서비스 기능이 1초가 걸렸는데, ARM64에서는 2초가 걸린다면 성능 개선과 최적화 작업이 필요한 것이다. 최근에는 샘플링 기반의 CPU가 많이 활용되고 있다. 이는 1초에 100번 주기적으로 컴퓨터가 지금 어떤 명령어를 실행하고 있는지 등을 샘플링하는 방식이다. 이후 샘플이 어떤 함수에서 시간을 많이 소모하는지 확인할 수 있다.

예를 들어 메모리 할당 함수, 즉 메모리 할당에 시간을 많이 쓰고 있다면 이 프로파일링 분석 결과를 기반으로 메모리 할당 알고리즘과 같은 필요한 요소들을 도입·테스트하며 개선해 볼 수 있다.

또 유의할 점이 있다면, 프로파일링뿐만 아니라 트래픽 부하를 테스트하는 과정도 수행해야 한다는 점이다. 실험 환경에서 실제 유저들의 트래픽을 받는 서비스가 이 부하를 버틸 수 있는지 여부를 확인하는 테스트다. 우리도 이러한 부하 테스트를 진행했다. 실제 환경에는 영향이 없도록 서비스를 복제하고 트래픽 부하를 보내 성능을 점검했고, 이는 실제 서비스하기에 앞서 중요한 과정이다.

ARM64 기반 생태계 활성화 기대

Q. 그래비톤과 관련해 기대하는 바가 있다면.
A. 우리는 AWS 그래비톤3 버전에 대한 마이그레이션과 최적화를 완료했다. 지난해 ‘AWS 리인벤트 2023(AWS re:Invent 2023)’에서 공개된 그래비톤4가 상용화되면 적극적으로 그래비톤 버전을 업그레이드하고자 한다. 그래비톤의 가장 큰 강점인 비용효율성에 더불어, AWS가 그래비톤에 대해 적극적인 투자와 기술지원을 하면서 프로세서 자체 성능이 발 빠르게 좋아지고 있다.

또 우리가 처음 그래비톤 마이그레이션 프로젝트를 수행하던 2년 전과 달리, 최근에는 ARM64 기반 프로세서가 많이 보급되고 있고 이전보다 유지 보수도 더 원활하게 이뤄질 수 있게 됐다는 점도 긍정적이다.

그래비톤은 성능과 비용 모두 우수한 프로세서라고 생각한다. 하지만 오픈소스 프로젝트와 SW 벤더들의 ARM64 지원이 더 확대돼야 많은 조직이 그래비톤과 ARM64 아키텍처를 활용할 수 있다. ARM64 생태계가 지금보다 더 활성화되기를 기대한다.