AWSのGravitonインスタンスでパフォーマンス分析を探る

Pulisher : Enterprise Managed Service Group イ・ヘイン
Description : x86機器とGraviton(ARM Processor) 搭載機の性能テスト過程を確認し、FlameGraphsを通じて性能差を視覚的に確認する方法について紹介したセッション

はじめに

現在、互換性などの問題でGraviton系列のインスタンスを使用している顧客はそれほど多くないと思います。ただ、AI/ML分野に対する関心が継続的に高まり、推論作業でGraviton系列のインスタンスが効率的な処理ができるため、性能面で有利であり、コストも削減できるため、Gravitonに対する関心も高まっているようです。Graviton系列インスタンスを通じてどのような性能と改善点を取ることができるのか確認したいと思い、セッションを申し込みました。

セッションの概要紹介

開発者が高いレベルで作業する傾向に合わせて、パフォーマンス問題を扱うためにアプリケーションの動作を深く掘り下げてボトルネックを解決する方法について学ぶことができるCode Talk形式のセッションです。 実際にAmazon EC2インスタンスを作成してShellを開いてコマンドを直接実行してみたり、ミニアプリケーションを通じてパフォーマンス動作を研究して改善する方法を学びました。

コードサンプルシナリオで説明することは、合計2つです。

１．USEメソッドによるネットワークのボトルネック現象の識別
２．FlameGraphsを使ったアクティブなベンチマーキング

リソースのボトルネック現象を把握するためのいくつかの項目は以下の通りです。

・Utilization : リソースがbusy状態だった平均時間 – CPU Utilization確認
・Saturation : リソースが処理できない追加作業がある場合 – vCPUスケジューラの待ち時間またはキューの長さを分析します。
・Error : エラーイベント数 – Kernelエラーの確認

次に、安全な活用について見ていきましょう。 分析する方法はFlameGraphを使用することです。FlameGraphは、どの部分で最適化が最も大きな影響を与えるかを確認できるように視覚化する視覚化ツールです。 これは、アクティブなベンチマーキングとも連動しています。

FlameGraphsを使ってGravitonとX86機器間の性能テストを可視化する作業を進めてみました。 下のシェルがx86で上がgravitonです。

実習で使うスクリプトは上のように、for文を使って数字を取ってみる簡単なソースコードです。

done後に出力された所要時間を確認してみると、gravitonが約4秒ほど速いことを確認することができました。

パフォーマンスの違いを引き起こす原因を調べるためGraviton Performance Runbookを使ってみました。

複製を受けると全てのパフォーマンスツールをダウンロードすることになり、すでに存在するツールもありますが、いくつかのパフォーマンステストを簡単に実行できるようにスクリプトを提供しており、テストのためこれをx86サーバーに複製しました。

ここにいくつかの依存関係をインストールしてコードのどの部分でパフォーマンスが低いか確認してみました。

・このセッションで説明された全ての内容を把握できなかった場合は、下記のリンクから確認することができます。

https://github.com/aws/aws-graviton-getting-started/blob/main/perfrunbook/README.md

インストールされたスクリプトを使用してこのアプリケーションで独自に小さなグラフを生成しました。

このグラフでは、どのような作業でどのくらいの時間がかかったかを確認することができます。

セッションを終えて

このセッションを通じて、既存のx86装備とGraviton(ARM Processor)装備間の性能テスト過程を確認し、FlameGraphsを通じて性能差を視覚的に確認できる方法について学びました。性能テスト中の速度面ではGravitonが速かったのですが、CPU使用量はx86と大きな差がなかったのですが、このような部分も互換性の部分と一緒に改善されれば、Graviton導入事例が徐々に増えていくことが期待されます。