WiseN

EC2 인스턴스의 타입별 대역폭을 살펴보자

Jul 13,2018   |   AWS

작성자_최준승

페이스북 공유하기 트위터 공유하기
Blog thumbnail

여기서 다루는 내용



· 시작하며
· 테스트 경과
· 테스트 결과 - 일반
· 테스트 결과 - 번외
· 마치며







클라우드 환경에서 제공하는 VM의 네트웍 대역폭 정보?






안녕하십니까, GS네오텍 최준승입니다.

오늘은 다소 전근대적(?)인 정보를 전해드리도록 하겠습니다.
전통적인 관점에서 궁금하지만 누구도 알려주지 않는.. 바로 EC2 Instance의 타입별 대역폭 정보입니다.

물론 EC2는 대개 Dedicated한 환경의 물리 서버가 아니기 때문에.
이 수치는 보증할 수 없고. 따라서 정보라는 측면에서 효용이 떨어질 수도 있습니다.

버뜨 그러나. "물리 환경 vs AWS" 란 관점에서 보면 그럴지 몰라도.
AWS 환경 내에서 "Type.A vs Type.B" 라는 상대적 관점으로 보면 의미가 조금은 있을 수도 있겠죠.
그래서 제가 총대를 매고.. 장장 일주일에 걸친 테스트 결과를 공유해 드리려고 합니다.

AWS Management Console에서 EC2를 생성할때 보면 아래와 같은 필드가 있습니다.


※ 알듯말듯 추상적으로 표현되어 있는 네트웍 성능 수치.. 얼마나 Low.. 얼마나 High.. Up to 10Gbps면.. 풀파워일때만?

그렇다면 EC2 환경에서 제공하는 네트웍 성능의 상한값은 어떻게 될까요?
여기서 Enhanced Networking이라고 하는 약간 지엽적인 개념이 등장하는데. 설명서에 따르면 다음과 같습니다.

  • Intel 82599 Virtual Function (VF) interface: C3, C4, D2, I2, M4 (excluding m4.16xlarge), and R3 - Up to 10Gb

  • Elastic Network Adapter (ENA): C5, C5d, F1, G3, H1, I3, m4.16xlarge, M5, M5d, P2, P3, R4, and X1 - Up to 25Gb



자, 이제 대충 환기가 끝났으니. 테스트 환경을 보시죠. 저는 아래 조건에서 테스트를 했습니다.

  • Region: Seoul Region

  • AMI: Amazon Linux 2018.03 (Default)

  • Tool: iperf v3.0.12

  • Command(server): $ iperf3 -s -p [port number]

  • Command(client): $ iperf3 -c [server's private ip] -i 1 -t 1800 -p [port number]
    ※ 일부 테스트는 -P 옵션으로 multi-connection 환경에서 수행

  • ENA: Enabled

  • Instance Family: T2, M4, M5, C4, C5
  • 기타: 원칙적으로 동일 AZ 내 동일 Instance Type간 측정, Placement Group 미설정



과연 AWS이 생각하는 Low는 얼마나 Low한지.. Moderate는 얼마나 Moderate한지.
측정값은 실제 상한값만큼 나오는지.. 그 값은 균일하게 나오는지 등을 테스트를 통해 순서대로 살펴볼 차례인데요.

앞에서도 말씀드렸지만, 독자분들께서 반드시 주지하셔야 할 점은
1. 테스트값은 측정 환경에 따라(측정 시점을 포함하여) 얼마든지 달라질 수 있으며
2. AWS가 (공유 환경에서) 보증하는 값은 더더욱 아니라는 점


입니다. 임금님귀는 당나귀귀도 아니고. 조심해야 할 것이 너무 많네요. ㅜㅜ





테스트 경과






테스트는 아주 지리한 작업이었습니다.

물론 인프라 구성을 포함한 반복문을 돌리면 되는데. 문제는 반복문을 구현하는 시간이 오래 걸리기 때문에..
절충안으로 원격 실행을 위해 EC2 Run Command를 활용하였습니다. 결과값은 나중에 확인하려고 S3로 떨궜죠. 이런식입니다.


※ 터미널 접속 없이 EC2 Run Command의 활용한 iperf 명령어 실행


※ S3 버킷에 가지런히 모인 측정값 모음


※ 이 파일을 열면 측정값이 짠하고 나옵니다

측정은 보통 30분 단위로 수행하였는데. 일부 Instance Type에서 특정 패턴이 관찰되었습니다.
측정 초기에 최대값이 측정되었다가. 일정 시간이 지난 후(15분 ~ 40분)에 값이 하향 고정되는 패턴입니다.

※ m5.2xlarge의 측정 패턴. 참고로 AWS 문서에 표기된 해당 타입의 성능값은 Up to 10Gb이다

참고로 이런 패턴은 M4/C4 계열에서는 발견되지 않았으며, T2/M5/C5 계열에서 주로 발견되었습니다.
Bursting 개념이 있는건지. 아님 일정 기준 하에 내부적으로 QoS가 걸리는건지 정확한 메커니즘은 저도 잘 모르겠습니다.





테스트 결과 - 일반






힘든척하느라 서두가 길었습니다. 이제 측정 결과를 보시죠.




  • T2 계열은 M계열이나 C계열에 비해 전반적으로 낮은 성능을 보여주었습니다

  • 특히 최소값이 매우 낮게 측정되었으며, 측정값의 변동성도 M계열이나 C계열에 비해 그 범위가 넓었습니다

  • T2 계열 중 가장 큰 사이즈인 t2.2xlarge에서도 최대 1Gbps 정도의 값이 측정되었습니다






  • 이전 세대인 M4 계열은 각 Type 내에서 최소값과 최대값이 비슷하게 측정되었습니다

  • m4.large의 경우 0.5Gbps, m4.4xlarge의 경우 2Gbps 정도의 성능이 측정되었습니다

  • m4.16xlarge는 single-connection 기준 측정값이며, multi-connection 환경에서는 20Gbps 내외의 값이 측정되었습니다 *






  • 범용 계열 최신 인스턴스인 M5 계열은 모든 Type에서 최대 10Gbps 정도의 성능이 측정되었습니다

  • 일정 시간이 지난 후엔 Size에 따라 측정값이 하향되는 패턴을 보여주었습니다

  • m5.24xlarge는 single-connection 기준 측정값이며, multi-connection 환경에서는 20Gbps 내외의 값이 측정되었습니다 *






  • C4 계열은 M4 계열과 마찬가지로 각 Type 내에서 최소값과 최대값이 비슷하게 측정되었습니다.

  • M4 계열의 동일 Size와 비교하면, C4 계열이 비교적 나은 성능값을 보여주었습니다






  • C5 계열은 모든 Type에서 최대 10Gbps 정도의 성능이 측정되었습니다

  • M5 계열과 동일하게 일정 시간이 지난 후엔 Size에 따라 측정값이 하향되는 패턴을 보여주었습니다

  • c5.18xlarge는 single-connection 기준 측정값이며, multi-connection 환경에서는 20Gbps 내외의 값이 측정되었습니다 *



여러분은 아마도 비교 대상에 따라 휠을 위아래로 돌리고 계실듯 한데. 3줄로 요약해 드리면 다음과 같습니다.


  • T2 계열의 네트웍 성능은 다른 계열에 비해 현격히 떨어진다

  • 동일 용도의 계열에서 최신 계열이 구계열보다 네트웍 성능이 낫다. 즉 M5가 M4보다 낫고, C5가 C4보다 낫다

  • C4 계열이 전반적으로 M4 계열보다 성능이 낫고, M5 계열과 C5 계열은 유의한 성능 차이가 발견되지 않았다







테스트 결과 - 번외






마칠 시간인데 썰을 좀 더 풀겠습니다.

오늘 테스트 대상의 Instance Type 중 m4.16xlarge/m5.24xlarge/c5.18xlarge는
스펙상에 ENA 설정이 활성화된 경우 최대 25Gbps의 성능이 나온다고 되어 있습니다.
iperf3의 -P 옵션을 사용하여 동시 5개의 connection을 만들어 테스트를 수행하면 아래 값이 측정됩니다.



이번에는 다른 Instance Type을 매칭시켜 테스트해보도록 하겠습니다.

0.2~0.5Gbps 정도의 성능이 나오는 t2.medium과 2.5~9.6Gbps 정도의 성능이 나오는 m5.2xlarge를 매칭시켜 보았습니다.
상식적으로 보면 빠른맨과 느린맨을 같은 컨베이어 벨트에 올려놓으면 느린맨에게 싱크가 맞을텐데요. 결과는 과연?



아, 그렇군요?





마치며






오늘 포스팅은 참 길었네요.

범람하는 AWS 책중에 제가 제일 좋아하는 책이 Amazon In Action 이라고 있습니다. 최근에 번역본도 나온 모양입니다만.
재래식 공법의 저와 달리. 여기 저자분은 이런 테스트를 완전 자동화해서 하고 계십니다.
확실하진 않지만 Cloudformation도 쓰시고 DynamoDB도 썼던 것 같은데. 박수 짝짝 드리구요.

포스팅같은 컨텐츠를 만드는 이유 중 하나는. 동일한 삽질을 다른 사람이 하지 않도록 하는 데에 있습니다.
물론 AWS는 뭔가 너무 범위가 넓어서. 3개월 전에 했던 것도 까먹기 때문에. 제가 기억하는데에도 목적이 있습니다.

아무쪼록 관련 주제가 궁금해서 찾아 오셨다면. 독자분께 도움이 되셨기를 바랍니다.

마치겠습니다. 끝!