Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2020/10/22に開催されたAWSのイベント Compute x AWS Graviton2 「Armプロセッサによるコスト最適化」~ AWS 3週連続!秋の Compute 祭り 第3回 ~ に登壇した際の資料です。

概要:
Graviton2プロセッサを採用したEC2インスタンスを使用することで、多数ある小規模サーバのコストダウンと大量データ処理の性能向上を実現できるか、また、構築・運用において配慮すべき点などはないかを実際の使用感も交えた検証結果をまとめました。
(Supership株式会社 プロダクト開発本部 データソリューションスタジオ エンジニアリング2G 中野 豊)

  • Be the first to comment

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

  1. 1. 2020.10.22 Supership株式会社 プロダクト開発本部 データソリューションスタジオ エンジニアリング2G 中野 豊
  2. 2. 目次
 1. 自己紹介&会社紹介 2. 検証内容 3. 検証結果概要 4. 検証結果詳細 5. Gravtion2プロセッサの使用感 6. まとめ 2
  3. 3. 1. 自己紹介&会社紹介  3
  4. 4. 1. 自己紹介&会社紹介
 ● 所属 ○ Supership株式会社 ○ DSS (プロダクト開発本部 データソリューションスタジオ エンジニアリング2G) ● 名前 ○ 中野 豊 ● 仕事 ○ サイト内検索エンジンS4の開発・運用 ○ データ集計・分析基盤の開発・運用 (最近は特に地理データ) ● ARM CPUとの関わり ○ 趣味 Raspberry Pi 歴7年 ○ PyCon JP 2020にラズパイネタで登壇しました ラズパイ3BのCPUでリアルタイム物体検出 4
  5. 5. Copyright © Supership Inc. ALL RIGHTS RESERVED. マーケティングテクノロジー事業/ データテクノロジー事業 TV CMのデジタル 広告配信事業 (テレビ朝日等との JV) 5 関連会社 「大企業が持つアセット」と「スタートアップのスピード・技術力」を掛け合わせた、 “ハイブリッドスタートアップ” 合計10社のスタートアップの共創体 アドベリフィケー ション 事業 データ マーケティング 事業 データ サイエンティスト/ AI構築事業 スタートアップ5社合併による 中核事業会社 2014年10月1日設立 1. 自己紹介&会社紹介
  6. 6. Copyright © Supership Inc. ALL RIGHTS RESERVED. 6 デジタルトランスフォーメーション事業 1. 自己紹介&会社紹介
  7. 7. 2. 検証内容 7
  8. 8. 2. 検証内容
 背景 安価でCPUコア数の多いGraviton2プロセッサが発表された時、 全てのEC2インスタンスをGraviton2にすれば、 業務で抱えている2つの大きな課題が解決されるのでは? と思った ● 細々と沢山あるサーバをコストダウンしたい ○ 軽量なWebアプリ / 少量データを処理するバッチ ○ 役割分担のためにインスタンス/コンテナを分けている ○ 各インスタンス/コンテナは小さいが、数が多くそこそこのコスト ● 大量データ処理の性能を向上させたい ○ Java系のデータ集計・分析基盤 (Elasticsearch, Spark) ○ Goで実装された並列・並行処理のバッチ ○ CPUを多く割り当てて処理性能を上げたい 8
  9. 9. 2. 検証内容
 検証内容: EC2を全部Graviton2に置き換えたほうが良いのか 実業務で使用している様々な処理系(または実業務を想定した試験実装)を、 既存のx64インスタンスとGraviton2プロセッサ採用インスタンスの両方で 構築・動作させて性能を計測し Graviton2プロセッサを採用したEC2インスタンスを使用することで、 Q1. 多数ある小規模サーバのコストダウンを実現できるか? Q2. 大量データ処理の性能向上を実現できるか? Q3. 構築・運用面で困ることがないか? を確認 9
  10. 10. 3. 検証結果概要  10
  11. 11. 3. 検証結果概要
 Graviton2プロセッサを採用したEC2インスタンスを使用することで、 Q1. 多数ある小規模サーバのコストダウンを実現できるか? A1. YES ● 軽量Webアプリは性能が上がってコストが下がる ● 直列処理バッチは2割前後性能が下がるが、多くの場合許容範囲 Q2. 大量データ処理の性能向上を実現できるか? A2. 概ねYES ● 物理CPU Coreの多さを生かし、並行並列処理で高いスループット ● 期待ほど性能が伸びず、既存のx64インスタンスが適する場面もある ○ 直列処理が残ってしまい、ボトルネックになる場合 ○ Javaが8以前の場合 ○ LSEが有効にならない場合 11
  12. 12. 3. 検証結果概要
 Q3. 構築・運用面で困ることがないか? A3. 困ることは少ない、がゼロではない ● 多くの処理系は何の苦労もなく構築でき、問題なく動作した ○ CPUのアーキテクチャが違っても、行う操作に違いはない ● (現時点では)機械学習関連の環境構築には苦労する ○ arm64向けビルド済バイナリパッケージがほとんど提供されていない => コンパイラや依存関係を整備してビルド => 手間と時間 ○ 2020年5月時点と10月時点を比べると、確実に改善されている => 待っていればそのうち解消されそう 12
  13. 13. 4. 検証結果詳細  13
  14. 14. 4. 検証結果詳細 / 軽量なWebアプリケーション
 検証方法 ● JSONを返却するWebサーバを構築 ○ nginxによる静的ファイル配信 ○ Pythonの簡単なWebアプリ ● Gatlingで最大RPSを計測 ○ higher is better ● m6g, m5, m5aのlarge インスタンスの性能を比較 検証結果 ● m6gが最安・最高性能 ○ 物理2Coreの威力 ● 全く同じ操作で構築できた 14
  15. 15. 4. 検証結果詳細 / 軽量なバッチ処理
 検証方法 ● 様々なバッチを実行 ○ 実業務で使用するバッチをそのまま実行 ○ 実業務で使用するデータを用い、よくある処理を抜粋して実行 (ファイルの圧縮伸長など) ○ 基本的にどの処理もシングルスレッド直列処理 ○ 数が多いので、ここでは典型的な結果だけ紹介 ● 処理時間を計測 ○ lower is better ● m6g, m5, m5aのlargeインスタンスの性能を比較 ○ 一部の処理ではc6g, c5, c5aの性能も追加で比較 15
  16. 16. 4. 検証結果詳細 / 軽量なバッチ処理
 検証結果 ● 1スレッド直列処理速度はIntel CPU、特にc5が優位 ● 時間に余裕がある処理ならm6g/c6gも十分適用可能 ● c5はm5と比べてCPU性能が高いが、c6gはm6gと性能が同じ ● 全く同じ操作で構築できた 16
  17. 17. 4. 検証結果詳細 / 機械学習
 検証方法 ● Pythonでよく利用する機械学習ライブラリをインストールし、 適当なデータを与えて処理速度を計測 17
  18. 18. 4. 検証結果詳細 / 機械学習
 検証結果 ● arm64環境での機械学習環境構築は苦労が多い ○ コンパイル済みのwheelファイルがほとんど用意されていない ○ ソースコードからその場でコンパイルすることになる ○ ビルドツールをインストールしておく必要がある ○ pip管理外の依存関係は自分で解決する必要がある ○ コンパイルを長時間待つ ● x64環境での環境構築は簡単 ○ コンパイル済wheelファイルが用意されていることが多い ○ 依存関係を気にせず pip install パッケージ名 で良い ○ 短時間でインストールが終わる ● 速度的にはIntel/AMDと遜色ない ○ タスクによって勝ったり負けたり ○ CPU自体の性能に加え、ライブラリの最適化度合いに左右される 18
  19. 19. 4. 検証結果詳細 / 機械学習
 試したパッケージ一覧 下記のパッケージはx64の場合は全てビルド済wheelファイルが提供されている 19 pipでビルド済wheelによるインストールが可能 pillow numpy onnxruntime pip installでソースコードからコンパイル可能 mecab-python3 gensim scikit-learn lightgbm pipではインストール困難 pillow-simd xgboost torch tensorflow
  20. 20. 4. 検証結果詳細 / Elasticsearch
 検証方法 ● Elasticsearch 7.3.0のindexing速度を計測・比較 ● データは文字列主体 ● インスタンスサイズを上げると、比例して性能が伸びるかを確認 ○ 基本は shard数=vCPU数、data post並列数=vCPU数 ○ 8x, 9xlargeは上記設定ではエラーが出るため、 エラーが出ない範囲の最大並列度を狙ってチューニング ○ OpenJDK8 vs OpenJDK11 ○ LSE有無 ● vCPUあたりの秒間処理件数、コストあたりの処理件数で比較 ○ higher is better 20
  21. 21. 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
  22. 22. 4. 検証結果詳細 / Elasticsearch
 検証結果 OpenJDK8 vs OpenJDK11 (LSE無) ● m6gが高い性能を発揮するにはOpenJDK11以上が必須 ● LSEが有効でないと4xlarge以上では処理効率が悪化 22
  23. 23. 4. 検証結果詳細 / Elasticsearch
 検証結果 LSE有無 ● Graviton2はLSEを有効にすることで、多Core環境でも高い性能を発揮 ● LSE + OpenJDK11なら、どのインスタンスサイズでも最速 23
  24. 24. 4. 検証結果詳細 / Elasticsearch
 検証結果 コストパフォーマンス ● コストあたりの処理性能で見ると、Graviton2プロセッサの良さが際立つ 24
  25. 25. 4. 検証結果詳細 / Goのバッチ(1)
 検証方法 ● Go1.14.4で実装されたETLバッチ処理の速度を計測・比較 ● 入出力部が直列処理、データ加工部が平行処理となっている ● インスタンスサイズを上げると、比例して性能が伸びるかを確認 ● 秒間処理件数、コストあたりの処理件数で比較 ○ higher is better 25 伸長 加工 圧縮加工 加工
  26. 26. 4. 検証結果詳細 / Goのバッチ(1)
 検証結果 ● 入出力がボトルネックになり、8物理Coreのインスタンスで性能が頭打ち ● ボトルネック部が速いC5の性能が最も高い ● 絶対性能を重視するなら、c5.4xlarge (HT OFF) が適する 26
  27. 27. 4. 検証結果詳細 / Goのバッチ(1)
 検証結果 ● コストパフォーマンスの観点では、ボトルネックのある処理で 1インスタンスに大量のCPUを割り当てることは得策ではない ● ボトルネックに引っかからない範囲ではc6gのコストパフォーマンスが最良 27
  28. 28. 4. 検証結果詳細 / Goのバッチ(2)
 検証方法 ● Go1.14.4で実装されたETLバッチ処理の速度を計測・比較 ● 完全並行処理 ● インスタンスサイズを12xlarge(48vCPU)で固定し、 実行スレッド数を1~48まで変化させて スレッド数に比例した処理量を得られるか確認 28 読出 => 伸長 => 加工 => 圧縮 => 出力 読出 => 伸長 => 加工 => 圧縮 => 出力 読出 => 伸長 => 加工 => 圧縮 => 出力
  29. 29. 4. 検証結果詳細 / Goのバッチ(2)
 検証結果 ● いずれもスレッド数に応じた処理量にならず、c6gの成績は特に悪い ● 要因はメモリアクセスの競合と思われる ○ 飛び飛びのメモリを激しく参照する非効率な実装が含まれていた ○ GoのLSE対応は1.16からの見込み。現時点では未対応 29
  30. 30. 4. 検証結果詳細 / Goのバッチ(2)
 検証結果 ● 実装を修正しメモリ参照を減らしたところ、性能が劇的に改善 ● c6gは特に性能が伸び、最安・最速に 30
  31. 31. 5. Graviton2プロセッサの使用感  31
  32. 32. 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
  33. 33. 5. Graviton2プロセッサの使用感
 困ったところ ● 手元のPC/Macで構築・操作手順を試せない ○ 元々EC2で作業が閉じている人は全く問題ない 33
  34. 34. 5. Graviton2プロセッサの使用感
 どんどん使いやすくなってきている ● 今や意識しなくても最初からLSEが有効になっている ○ リリース当初、AL2ではglibcのコンパイルが必要だった ● arm64向けパッケージが増えてきた ○ Elasitcsearch rpm & Docker Image, numpy, onnxruntime ● ソフトウェアの最適化も進んでいる 34
  35. 35. 6. まとめ  35
  36. 36. 6. まとめ
 Graviton2プロセッサを採用したEC2インスタンスを使用することで、 Q1. 多数ある小規模サーバのコストダウンを実現できるか? A1. YES ● 軽量Webアプリは性能が上がってコストが下がる ● 直列処理バッチは2割前後性能が下がるが、多くの場合許容範囲 Q2. 大量データ処理の性能向上を実現できるか? A2. 概ねYES ● 物理CPU Coreの多さを生かし、並行並列処理で高いスループット ● 期待ほど性能が伸びず、既存のx64インスタンスが適する場面もある ○ 直列処理が残ってしまい、ボトルネックになる場合 ○ Javaが8以前の場合 ○ LSEが有効にならない場合 36
  37. 37. 6. まとめ
 Q3. 構築・運用面で困ることがないか? A3. 困ることは少ない、がゼロではない ● 多くの処理系は何の苦労もなく構築でき、問題なく動作した ○ CPUのアーキテクチャが違っても、行う操作に違いはない ● (現時点では)機械学習関連の環境構築には苦労する ○ arm64向けビルド済バイナリパッケージがほとんど提供されていない => コンパイラや依存関係を整備してビルド => 手間と時間 ○ 2020年5月時点と10月時点を比べると、確実に改善されている => 待っていればそのうち解消されそう 37

    Be the first to comment

  • DaisukeMiyamoto6

    Nov. 27, 2020

2020/10/22に開催されたAWSのイベント Compute x AWS Graviton2 「Armプロセッサによるコスト最適化」~ AWS 3週連続!秋の Compute 祭り 第3回 ~ に登壇した際の資料です。 概要: Graviton2プロセッサを採用したEC2インスタンスを使用することで、多数ある小規模サーバのコストダウンと大量データ処理の性能向上を実現できるか、また、構築・運用において配慮すべき点などはないかを実際の使用感も交えた検証結果をまとめました。 (Supership株式会社 プロダクト開発本部 データソリューションスタジオ エンジニアリング2G 中野 豊)

Views

Total views

1,183

On Slideshare

0

From embeds

0

Number of embeds

209

Actions

Downloads

1

Shares

0

Comments

0

Likes

1

×