AWS Graviton2 출시 후 바로 도입해본 후기
11편 – 가격 대비 성능 40% 향상..은 못 참지!
티맵 경로탐색 엔진
티맵 경로탐색 엔진은 아래 화면과 같이 출발지로부터 목적지까지 사용자에게 최적의 경로를 안내해주기 위한 엔진입니다. (경로탐색엔진에 대한 상세한 내용은 아래 콘텐츠를 참고해주세요)
신규 경로탐색 엔진은 현재 AWS 환경에서 서비스를 제공하고 있고요. 개발된 지 얼마 되지 않았기 때문에 비교적 최신 개발환경을 유지하고 있습니다.
Language: java 11 (amazon correctto 11)
Framework: spring boot 2.x
Infra: Elastic Beanstalk (PAAS) & EC2
도입 계기
우연한 계기로 Graviton2 CPU(ARM64) 기반의 장비가 출시된 것을 알게 되었습니다(AWS 콘솔에 접근할 때마다 계속 소식이 뜨더라고요).
AWS Console위 화면을 보시면 아시겠지만 기존 x86 장비 대비 40%나 가격 대비 성능이 개선되었다고 합니다. 위 내용이 사실이라면 바꾸지 않을 이유가 없었습니다. 저희 엔진은 JVM위에서 동작하기 때문에 OS의존성이 없기도 하고요. Graviton2 기반 장비에 대한 내용을 조금 더 살펴보면 아래와 같은 글을 찾을 수 있어, 저희는 바로 변경 작업을 진행해보기로 하였습니다.
(참고: https://aws.amazon.com/ko/blogs/korea/aws-graviton2-m6g-c6g-r6g-instances-seoul-region/)
기존 AWS 서비스에서도 Graviton 2 기반 인스턴스를 사용하면 최소한의 노력으로 AWS Graviton2 기반 인스턴스의 상당한 가격 대비 성능 이점을 실현할 수 있습니다. 예를 들어, Amazon ElastiCache는 최대 45 % 더 나은 가격 대비 성능을 제공하고, Amazon RDS(MariaDB, MySQL 및 Postgres)는 최대 52% 더 나은 가격 대비 성능 이점을 제공합니다. Amazon EMR은 Graviton2 기반 인스턴스에서 Spark 워크로드에 대해 최대 30% 낮은 비용과 최대 15% 향상된 성능을 제공합니다. Graviton2 기반 데이터베이스 인스턴스는 Amazon Aurora 미리보기(PostgreSQL 및 MySQL 호환)에서도 제공합니다.
Netflix 성능 및 운영 시스템 부문 이사인 Ed Hunter는 “업계 표준 LMbench와 특정 Java 벤치마크를 사용하여 새로운 M6g 인스턴스를 테스트했는데 M5보다 50% 개선된 성능을 확인했다”라고 밝혔습니다. AWS Graviton2 기반 Amazon EC2 인스턴스의 도입에 대한 기대가 매우 크다”고 전했습니다. Snap의 소프트웨어 엔지니어인 Aaron Sheldon는 “Graviton2 기반 인스턴스를 사용하여 Snapchat 메시징 플릿 크기를 줄이고 C5 인스턴스보다 비용을 크게 줄일 수 있으며, C6g 인스턴스로 옮기면서 Graviton2의 성능이 향상되어 CPU 사용률이 약 10% 감소했다”라고 이야기해 주었습니다. Intuit의 클라우드 엔지니어링 및 운영 담당 이사인 Brendan Byrne는 “Kafka 서비스에 Graviton2 기반 R6g 인스턴스를 사용하여 R5 인스턴스보다 20% 더 낮은 비용으로 유사한 성능”을 보인다고 말했습니다.
출처: https://aws.amazon.com/ko/blogs/korea/aws-graviton2-m6g-c6g-r6g-instances-seoul-region/적용
Thor Engine Architecture티맵의 신규 엔진(Thor) 아키텍처입니다. 크게 3개의 모듈로 구성되어 있고, 각 모듈은 아래와 같은 특성을 가지고 있습니다.
preprocessor (EC2 start/stop): 약 2주에 한 번씩 맵 데이터 변환 및 경로탐색을 위한 데이터 최적화 작업을 수행.
customizer (Elastic Beanstalk): 1분, 5분 단위로 변경된 맵 데이터에 변경분에 대한 최적화 작업을 수행.
route-planning (Elastic Beanstalk): 사용자 요청에 최적경로를 탐색해주는 엔진(WebServer)
각 특성이 다르기 때문에 모듈단위로 테스트를 수행한 후 적용해보기로 결정하였습니다. 저희는 Beanstalk 환경설정 파일을 소스코드로 관리하고 있기 때문에, 아래 화면처럼 InstanceTypes 부분만 수정하면 돼서 빠르게 적용이 가능했습니다.
Elastic Beanstalk Configurationpreprocessor 적용
위에서 언급한 대로 preprocessor 같은 경우는 약 2주에 한 번씩 맵 데이터 변환 및 경로탐색을 위한 데이터 최적화 작업을 수행합니다. 내부적으로 높은 성능을 요구하는 병렬 처리 작업이 있기 때문에 vCPU가 가장 큰 인스턴스를 사용하고 있습니다.
각 항목별 테스트 수행 결과는 아래와 같습니다.
테스트 환경: c5.24xlarge (96vCPU / 4.608 USD) → c6g.16xlarge (64vcpu / 2.464 USD)
(참고로 각 인스턴스 세대에서 최대의 vCPU를 지원하는 장비를 사용하였습니다)
결과
• Data Load (sequential)
• Graph Partitioning (parallel): 약 48분 → 43분
• Various Graph Processing (sequential)
• Various Data Converting (sequential)
• Data compression&export (parallel): 1분 미만
• Total: 71분 → 77분
데이터 변환 특성상 순차적으로 처리해야만 하는 작업이 포함되어 있기 때문에 싱글 스레드에서 처리할 수밖에 없는 작업도 있고, Graph Partitioning처럼 많은 CPU를 사용해야만 하는 작업이 포함되어 있습니다.
결과는 다음과 같이 요약 가능합니다.
CPU를 거의 Full로 사용하는 병렬 처리 작업에서 더 적은 vCPU임에도 불구하고 시간 감소.
순차 작업에서는 시간이 증가
위 결과를 보면 단일 vCPU작업에서는 기존 장비(c5) 성능이 더 좋게 나옵니다. 하지만 병렬 처리 작업에서는 더 적은 vCPU임에도 불구하고, c6g가 더 좋은 결과를 보여줍니다. 그로 인해 전체적인 작업 수행 시간은 길어졌지만, 비용 대비 성능을 보면 약 47% 정도 개선된 것으로 계산됩니다.
하지만 해당 인스턴스는 평소에 EC2 Stopped 상태로 유지하고, 필요한 경우에만 Running 상태로 변경 후 사용하여 비용적인 메리트가 크지 않으므로 저희는 c5.24xlarge 인스턴스를 유지하는 것으로 결정하였습니다.
customizer 적용
customizer의 특성은 1분, 5분에 한 번씩 변경되는 맵 및 교통정보 데이터를 경로탐색을 위한 데이터로 최적화하는 작업을 수행합니다. 순간적으로 높은 성능을 요구하는 병렬 처리 작업과, 많은 메모리가 요구되기 때문에 범용 인스턴스를 사용하고 있습니다.
각 항목별 테스트 수행 결과는 아래와 같습니다.
테스트 환경: m5.4xlarge (16vCPU / 0.944 USD) → m6g.4xlarge (16vcpu / 0.752 USD)
결과
• Data Load (sequential)
• customization (parallel): 7s → 11s
• Data compression&export (parallel): 15s → 11s
• Total: ~30s → ~30s
preprocessor 때와는 다르게 짧은 시간에 처리해야 하는 customization 병렬 처리 작업은 기존 장비보다 성능이 일부 저하되었습니다. 그리고, 데이터 compression&export 에서는 성능이 개선되었습니다. 전체적으로 보면 성능은 거의 유사합니다. 하지만 비용이 저렴해졌기 때문에, 비용 대비 성능은 약 20% 개선된 것으로 계산됩니다.
이에 따라 저희는 customizer는 m6g.4xlarge 인스턴스로 교체하는 것으로 결정하였습니다.
route-planning 적용
사용자의 요청에 직접 응답하는 web-application입니다. 하지만, 일반적인 web-application과는 다르게 IO작업보다 CPU 연산이 많은 web-application입니다. 내부적으로 아래와 같은 로직들이 포함됩니다.
map-matching (spatial index …)
route-planning (graph traversing)
route-guidance
protobuffer
저희는 내부적으로 ngrinder를 이용하여 web-application에 대해 성능 측정을 진행하고 있습니다.
ngrinder를 이용한 성능 측정 결과는 다음과 같습니다.
테스트 환경: m5.2xlarge (8vCPU / 0.472 USD) → m6g.2xlarge (8vcpu / 0.376 USD)
ngrinder 성능 측정 결과 (상단: m5 / 하단: m6g)
ngrinder 성능 측정 결과 요약위 성능 측정 결과를 보면 기존보다 성능이 약 13~16% 정도 개선이 되었고, 비용은 20%가 절감되었습니다. 그로 인해 전체적인 비용 대비 성능은 약 35~40% 정도 개선된 것으로 계산됩니다.
이에 따라 저희는 route-planning은 m6g.2xlarge 인스턴스로 교체하는 것으로 결정하였습니다.
마치며
모듈 특성마다 다르지만 AWS에서 발표한 대로 단순 장비 교체만으로 비용 대비 성능이 약 2~40%가 개선되는 효과가 있었습니다. (어메이징!) (Graviton3도 현재 준비 중이라고 하는데, 기대가 됩니다)
저희는 os에 독립적인 JVM기반의 언어를 사용하기 때문에 간단하게 교체가 가능했었는데요. native 언어를 사용하시는 곳에서는 좀 더 면밀한 테스트를 통해 적용하는 것이 좋을 것 같습니다. AWS를 사용하시는 개발자 분들은 각 모듈 특성에 맞게 ARM64 아키텍처 기반의 Graviton2를 적극 도입하는 것을 추천합니다.
끝으로 이와 같은 여정을 함께 할 개발자 분들을 모십니다. 언제든 지원 부탁드립니다. - 티맵모빌리티 채용
