Graviton2プロセッサの性能特性と適用箇所／Supership株式会社中野豊

2020.10.22
Supership株式会社プロダクト開発本部データソリューションスタジオ
エンジニアリング2G 中野豊

目次 
1. 自己紹介&会社紹介
2. 検証内容
3. 検証結果概要
4. 検証結果詳細
5. Gravtion2プロセッサの使用感
6. まとめ
2

1. 自己紹介&会社紹介　
3

1. 自己紹介&会社紹介 
● 所属
○ Supership株式会社
○ DSS (プロダクト開発本部データソリューションスタジオエンジニアリング2G)
● 名前
○ 中野豊
● 仕事
○ サイト内検索エンジンS4の開発・運用
○ データ集計・分析基盤の開発・運用 (最近は特に地理データ)
● ARM CPUとの関わり
○ 趣味 Raspberry Pi 歴7年
○ PyCon JP 2020にラズパイネタで登壇しました
ラズパイ3BのCPUでリアルタイム物体検出
4

Copyright © Supership Inc. ALL RIGHTS RESERVED.
マーケティングテクノロジー事業/
データテクノロジー事業
TV CMのデジタル
広告配信事業
（テレビ朝日等との
JV）
5
関連会社
「大企業が持つアセット」と「スタートアップのスピード・技術力」を掛け合わせた、
“ハイブリッドスタートアップ”
合計10社のスタートアップの共創体
アドベリフィケー
ション
事業
データ
マーケティング
事業
データ
サイエンティスト/
AI構築事業
スタートアップ5社合併による
中核事業会社
2014年10月1日設立

Copyright © Supership Inc. ALL RIGHTS RESERVED. 6
デジタルトランスフォーメーション事業

2. 検証内容 
背景
安価でCPUコア数の多いGraviton2プロセッサが発表された時、
全てのEC2インスタンスをGraviton2にすれば、
業務で抱えている2つの大きな課題が解決されるのでは? と思った
● 細々と沢山あるサーバをコストダウンしたい
○ 軽量なWebアプリ / 少量データを処理するバッチ
○ 役割分担のためにインスタンス/コンテナを分けている
○ 各インスタンス/コンテナは小さいが、数が多くそこそこのコスト
● 大量データ処理の性能を向上させたい
○ Java系のデータ集計・分析基盤 (Elasticsearch, Spark)
○ Goで実装された並列・並行処理のバッチ
○ CPUを多く割り当てて処理性能を上げたい
8

2. 検証内容 
検証内容: EC2を全部Graviton2に置き換えたほうが良いのか
実業務で使用している様々な処理系(または実業務を想定した試験実装)を、
既存のx64インスタンスとGraviton2プロセッサ採用インスタンスの両方で
構築・動作させて性能を計測し
Graviton2プロセッサを採用したEC2インスタンスを使用することで、
Q1. 多数ある小規模サーバのコストダウンを実現できるか?
Q2. 大量データ処理の性能向上を実現できるか?
Q3. 構築・運用面で困ることがないか?
を確認
9

3. 検証結果概要 
A1. YES
● 軽量Webアプリは性能が上がってコストが下がる
● 直列処理バッチは2割前後性能が下がるが、多くの場合許容範囲
A2. 概ねYES
● 物理CPU Coreの多さを生かし、並行並列処理で高いスループット
● 期待ほど性能が伸びず、既存のx64インスタンスが適する場面もある
○ 直列処理が残ってしまい、ボトルネックになる場合
○ Javaが8以前の場合
○ LSEが有効にならない場合
11

3. 検証結果概要 
A3. 困ることは少ない、がゼロではない
● 多くの処理系は何の苦労もなく構築でき、問題なく動作した
○ CPUのアーキテクチャが違っても、行う操作に違いはない
● (現時点では)機械学習関連の環境構築には苦労する
○ arm64向けビルド済バイナリパッケージがほとんど提供されていない
=> コンパイラや依存関係を整備してビルド => 手間と時間
○ 2020年5月時点と10月時点を比べると、確実に改善されている
=> 待っていればそのうち解消されそう
12

4. 検証結果詳細 / 軽量なWebアプリケーション 
検証方法
● JSONを返却するWebサーバを構築
○ nginxによる静的ファイル配信
○ Pythonの簡単なWebアプリ
● Gatlingで最大RPSを計測
○ higher is better
● m6g, m5, m5aのlarge
インスタンスの性能を比較
検証結果
● m6gが最安・最高性能
○ 物理2Coreの威力
● 全く同じ操作で構築できた
14

4. 検証結果詳細 / 軽量なバッチ処理 
検証方法
● 様々なバッチを実行
○ 実業務で使用するバッチをそのまま実行
○ 実業務で使用するデータを用い、よくある処理を抜粋して実行
(ファイルの圧縮伸長など)
○ 基本的にどの処理もシングルスレッド直列処理
○ 数が多いので、ここでは典型的な結果だけ紹介
● 処理時間を計測
○ lower is better
● m6g, m5, m5aのlargeインスタンスの性能を比較
○ 一部の処理ではc6g, c5, c5aの性能も追加で比較
15

4. 検証結果詳細 / 軽量なバッチ処理 
検証結果
● 1スレッド直列処理速度はIntel CPU、特にc5が優位
● 時間に余裕がある処理ならm6g/c6gも十分適用可能
● c5はm5と比べてCPU性能が高いが、c6gはm6gと性能が同じ
● 全く同じ操作で構築できた
16

4. 検証結果詳細 / 機械学習 
検証方法
● Pythonでよく利用する機械学習ライブラリをインストールし、
適当なデータを与えて処理速度を計測
17

検証結果
● arm64環境での機械学習環境構築は苦労が多い
○ コンパイル済みのwheelファイルがほとんど用意されていない
○ ソースコードからその場でコンパイルすることになる
○ ビルドツールをインストールしておく必要がある
○ pip管理外の依存関係は自分で解決する必要がある
○ コンパイルを長時間待つ
● x64環境での環境構築は簡単
○ コンパイル済wheelファイルが用意されていることが多い
○ 依存関係を気にせず pip install パッケージ名で良い
○ 短時間でインストールが終わる
● 速度的にはIntel/AMDと遜色ない
○ タスクによって勝ったり負けたり
○ CPU自体の性能に加え、ライブラリの最適化度合いに左右される
18

試したパッケージ一覧
下記のパッケージはx64の場合は全てビルド済wheelファイルが提供されている
19
pipでビルド済wheelによるインストールが可能 pillow
numpy
onnxruntime
pip installでソースコードからコンパイル可能 mecab-python3
gensim
scikit-learn
lightgbm
pipではインストール困難 pillow-simd
xgboost
torch
tensorflow

4. 検証結果詳細 / Elasticsearch 
検証方法
● Elasticsearch 7.3.0のindexing速度を計測・比較
● データは文字列主体
● インスタンスサイズを上げると、比例して性能が伸びるかを確認
○ 基本は shard数=vCPU数、data post並列数=vCPU数
○ 8x, 9xlargeは上記設定ではエラーが出るため、
エラーが出ない範囲の最大並列度を狙ってチューニング
○ OpenJDK8 vs OpenJDK11
○ LSE有無
● vCPUあたりの秒間処理件数、コストあたりの処理件数で比較
20

Tips. LSEとは 
LSE: Large System Extensions
● 複数スレッドから同じメモリにアクセスする際、読出 => 計算 => 書込
をCPUに対して1命令で指示できる、ARM v8.1-Aの拡張命令群
● 同じ変数を複数スレッドからインクリメントする処理の例
21
0
読出
読出
0
0 => 1
1
+1
書込
書込
+1
メモリの内容が読出時と異なっていること
を検知し、読出からやり直す
Thread 1 Thread 2
0 => 1
1 => 2
2 => 3
3 => 4
Thread 1 Thread 2
読出, +1, 書込
読出, +1, 書込
読出, +1, 書込
読出, +1, 書込
without LSE with LSE

検証結果 OpenJDK8 vs OpenJDK11 (LSE無)
● m6gが高い性能を発揮するにはOpenJDK11以上が必須
● LSEが有効でないと4xlarge以上では処理効率が悪化
22

検証結果 LSE有無
● Graviton2はLSEを有効にすることで、多Core環境でも高い性能を発揮
● LSE + OpenJDK11なら、どのインスタンスサイズでも最速
23

検証結果コストパフォーマンス
● コストあたりの処理性能で見ると、Graviton2プロセッサの良さが際立つ
24

4. 検証結果詳細 / Goのバッチ(1) 
検証方法
● Go1.14.4で実装されたETLバッチ処理の速度を計測・比較
● 入出力部が直列処理、データ加工部が平行処理となっている
● インスタンスサイズを上げると、比例して性能が伸びるかを確認
● 秒間処理件数、コストあたりの処理件数で比較
25
伸長
加工
圧縮加工
加工

検証結果
● 入出力がボトルネックになり、8物理Coreのインスタンスで性能が頭打ち
● ボトルネック部が速いC5の性能が最も高い
● 絶対性能を重視するなら、c5.4xlarge (HT OFF) が適する
26

検証結果
● コストパフォーマンスの観点では、ボトルネックのある処理で
1インスタンスに大量のCPUを割り当てることは得策ではない
● ボトルネックに引っかからない範囲ではc6gのコストパフォーマンスが最良
27

検証方法
● Go1.14.4で実装されたETLバッチ処理の速度を計測・比較
● 完全並行処理
● インスタンスサイズを12xlarge(48vCPU)で固定し、
実行スレッド数を1~48まで変化させて
スレッド数に比例した処理量を得られるか確認
28
読出 => 伸長 => 加工 => 圧縮 => 出力
読出 => 伸長 => 加工 => 圧縮 => 出力
読出 => 伸長 => 加工 => 圧縮 => 出力

検証結果
● いずれもスレッド数に応じた処理量にならず、c6gの成績は特に悪い
● 要因はメモリアクセスの競合と思われる
○ 飛び飛びのメモリを激しく参照する非効率な実装が含まれていた
○ GoのLSE対応は1.16からの見込み。現時点では未対応
29

検証結果
● 実装を修正しメモリ参照を減らしたところ、性能が劇的に改善
● c6gは特に性能が伸び、最安・最速に
30

5. Graviton2プロセッサの使用感　
31

5. Graviton2プロセッサの使用感 
良かったところ
● CPUアーキテクチャの違いで違和感を感じることはほとんどなかった
○ OSのディストリビューションが同じなら操作方法も同じ
○ 困ったのは機械学習周りだけ
● AWSから充実したサポートを受けられた
○ Getting started with Graviton
Graviton2の性能を引き出すためのAWS公式ノウハウ集
○ CPUのCore数が多い時はLSEが効くと性能が出る
■ Ubuntu20.04だとデフォルトでLSEが有効
■ Amazon Linux 2も8月頃デフォルトでLSEが有効化された
■ CentOS8は8.3からLSE対応予定
○ GoでLSEを有効化するためのパッチが出ており、マージの進捗は...
○ ↑全部AWSから教えていただきました
32

困ったところ
● 手元のPC/Macで構築・操作手順を試せない
○ 元々EC2で作業が閉じている人は全く問題ない
33

どんどん使いやすくなってきている
● 今や意識しなくても最初からLSEが有効になっている
○ リリース当初、AL2ではglibcのコンパイルが必要だった
● arm64向けパッケージが増えてきた
○ Elasitcsearch rpm & Docker Image, numpy, onnxruntime
● ソフトウェアの最適化も進んでいる
34

6. まとめ 
A1. YES
● 軽量Webアプリは性能が上がってコストが下がる
● 直列処理バッチは2割前後性能が下がるが、多くの場合許容範囲
A2. 概ねYES
● 物理CPU Coreの多さを生かし、並行並列処理で高いスループット
● 期待ほど性能が伸びず、既存のx64インスタンスが適する場面もある
○ 直列処理が残ってしまい、ボトルネックになる場合
○ Javaが8以前の場合
○ LSEが有効にならない場合
36

6. まとめ 
A3. 困ることは少ない、がゼロではない
● 多くの処理系は何の苦労もなく構築でき、問題なく動作した
○ CPUのアーキテクチャが違っても、行う操作に違いはない
● (現時点では)機械学習関連の環境構築には苦労する
○ arm64向けビルド済バイナリパッケージがほとんど提供されていない
=> コンパイラや依存関係を整備してビルド => 手間と時間
○ 2020年5月時点と10月時点を比べると、確実に改善されている
=> 待っていればそのうち解消されそう
37

Graviton2プロセッサの性能特性と適用箇所／Supership株式会社中野豊

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Graviton2プロセッサの性能特性と適用箇所／Supership株式会社中野豊

Similar to Graviton2プロセッサの性能特性と適用箇所／Supership株式会社中野豊 (20)