Amazon EC2 を Arm に切り替えたら幸せなことしかありませんでした

WRITER: Takuya Hasegawa
このエントリーをはてなブックマークに追加

技術本部 サービスリライアビリティグループ（SRG）の長谷川 @rarirureluis です👳
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。

はじめに

Apple M1 で Arm という単語をよく耳にし、そしてその性能に驚いた方も多いと思います。Apple M1 が搭載された Mac のベンチマークはこちら

そして Amazon EC2（以下：EC2）にも Arm が搭載されたインスタンスがあります。
https://aws.amazon.com/jp/ec2/graviton/

今回はとあるサービスの全開発環境の EC2 インスタンスを m5.large から t4g.medium へ移行したら幸せになれたので、この記事を読んで少しでも Arm インスタンスの良さが伝わって頂けたらなと思います。

AWS Graviton は何が嬉しいか

Arm が搭載された EC2 インスタンスは、従来の Intel/AMD が載ったインスタンスよりも安く高性能なため、非常にコスパが良いです。

現在（2020/11/19）は EC2 以外に Amazon RDS、Amazon ElastiCache にも展開されています。
https://aws.amazon.com/jp/about-aws/whats-new/2020/10/achieve-up-to-52-percent-better-price-performance-with-amazon-rds-using-new-graviton2-instances/
https://aws.amazon.com/jp/about-aws/whats-new/2020/10/amazon-elasticache-now-supports-m6g-and-r6g-graviton2-based-instances/

Arm が搭載された m6g.large と従来の m5.large を比較した内容も、半年前に記事にしています。
https://blog.luispc.com/entry/2020/05/18/190613

Arm に対応させることはじめ

今回 Arm に対応したサービスは Ansible と Terraform で管理されているため、先ずは Ansible で Arm に対応させるとこから始めます。

x86_64 から、AArch64 の Ansible へ

まずはミドルウェア等に AArch64 に対応しているかが鍵です。
一部ミドルウェアでは x86_64 と AArch64 でバージョン差異があるので注意してください。

今回使用しているミドルウェアで変更が必要だったのは、下記のミドルウェアでした。

  • Nginx
  • td-agent

今回 Arm 対応したサービスは、Ansible が綺麗に整備されていたので、1営業日もかからずに、Ansible で Arm 対応することができました。前担当者には感謝感激雨あられです。

Nginx

Nginx の公式リポジトリには CentOS 8 から AArch64 向けパッケージが用意されていますが、今回は CentOS 7 のため利用せずに epel のを利用しました。

名前                : nginx
アーキテクチャー    : aarch64
エポック            : 1
バージョン          : 1.12.2
リリース            : 3.el7
リポジトリー        : installed
提供元リポジトリー  : epel

td-agent

td-agent の公式リポジトリには CentOS 7 向けの AArch64 向けパッケージが用意されています（v4.x から）。

ミドルウェアに対するコンフィグの変更等もなく、AArch64 対応することができました。

エントロピーについて

EC2 の Arm では、random デバイスに対するエントロピーがとても少ない場合によってはエラー、もしくは大幅なパフォーマンス低下を引き起こします。

今回は Apache Tomcat(java) を利用して乱数生成する部分のパフォーマンスが、大幅に低下しました。
これは乱数生成で /dev/random を利用するのですが、これに対するリソースが少ないために発生します。

t4g.medium のエントロピーを確認すると

$ cat /proc/sys/kernel/random/entropy_avail
11

たったの 11 しかありませんでした。

haveged

これを解決するのが haveged です。
https://wiki.archlinux.jp/index.php/Haveged

インストールも yum で簡単に、インストール後は systemd で起動します。

有効化後のエントロピー数は 1401 となりました。

Ansible の準備ができたら Arm な EC2 を作成し、Ansible を流して動作確認を行い、ターゲットグループに追加するだけです。問題がなければ x86_64 な EC2 を引き抜けばノーメンテで切り替えられます。

結果

本番環境はこれからですが、開発環境を全て Arm へ切り替えをしました。
今回は m5.large から t4g.medium への切り替えです。

時間単位辺りの料金で言うと

  • m5.large: $0.124/h
  • t4g.medium: $0.0432/h

と価格差は 3倍ぐらいあることに注目してください。

パフォーマンス

赤い縦線が切り替え後です。

ALB レスポンスタイム

グレーの線は m5.large

Load Average

青：1分 / 紫：5分 / 黄：15分

価格差は m5.large が t4g.medium の 3倍にもかかわらず、性能差はないと言っても問題ないかと思います。
開発環境の EC2 は 26台あるので、今回の Arm への切り替えを単純計算すると

0.124 * 720 * 26 = $2321.28/month
0.0432 * 720 * 26 = $808.704/month

となります。

性能劣化なしに開発環境のみの切り替えで 年間 180万円以上の削減ができました。
本番環境では m5.(x)large -> m6g.(x)large への切り替えをするため価格差は小さくなりますが、この記事の通り性能差は更に大きいのでやる価値は十二分にあるかと思います。
https://blog.luispc.com/entry/2020/05/18/190613

インフラ CA Tech JOB 「NVIDIA DGX A100 の機能調査」
次の記事
広告配信プロダクトのDWHにSnowflakeを採用しました
前の記事