AWSの次世代プロセッサ Graviton2（Arm64）を LambdaとFargateで使うために 考えるべきこと 1 濱⽥孝治（ハマコー）

スライドは後で入手することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター音が出ないようにご配慮ください

3 自己紹介 濱⽥孝治（ハマコー） • 2017年9⽉⼊社 • CX事業本部 Delivery部 VPoE • 好きな⾔葉「わっしょい」「どすこい」 • @hamako9999 • 実家は住之江区。四つ橋線の北加賀屋駅 • 実家は「寿楽温泉」という名の銭湯

4 最初に皆さんお聞きしたい Graviton聞いたことがあるひと︕

5 最初に皆さんお聞きしたい Graviton触ったことがあるひと︕

6 最初に皆さんお聞きしたい Graviton実際に 本番環境で使っている⼈︕

7 AWSではこのように発表しています Intel ArchitectureのプロセッサからGravitonに乗り換 えることで • 幅広いワークロードで価格帯性能⽐が最⼤40%向 上 • 同等のx86ベースのインスタンスよりも最⼤20% 安価 • 同等のx86ベースのインスタンスと⽐較してエネルギ ー効率が最⼤60%向上

8 こう思いますよね︖ どうせ そんな⼀筋縄ではいかないんでしょ…

9 今日の主旨 馴染みが無いGravitonの 利⽤⽅法を共有することで 皆さんのアプリケーションワークロード改善 のヒントにしてもらいたい

10 喋ること喋らないこと 喋ること • LambdaでGraviton2を活⽤するときの注意点 • FargateでGraviton2を活⽤するときの注意点 喋らないこと • EC2のGraviton2の話 • Lambdaそのものの話 • Fargateそのものの話

11 Agenda • Gravitonプロセッサとはなにか︖ • LambdaにおけるGraviton2導⼊の注意点 • FargateにおけるGraviton2導⼊の注意点 • まとめ

12 Gravitonプロセッサとはなにか︖

13 EC2で利⽤できるプロセッサ 年代 ロゴ プロセッサ名 インスタンスタイプ CPUアーキテクチ ャ 2006- Intel Xeon Scalable processors c6i.xlarge x86アーキテクチャ 2018- AMD EPYC processors c6a.xlarge x86アーキテクチャ 2018- AWS Graviton processors c7g.xlarge Armアーキテクチャ

14 AWS Gravitonの歴史 Graviton⾃体にも歴史がある 引用：AWS Graviton AWS Black Belt Online Seminar

15 AWS Gravitonの歴史 Graviton⾃体にも歴史がある 引用：AWS Graviton AWS Black Belt Online Seminar LambdaとFargateで利⽤するのはコレ

16 CPUアーキテクチャの違いを知りたい 「x86 ARM 違い」 検索、検索〜

17 おそらくこう思うはず 「あ、沼だこれ」

18 x86とArmアーキテクチャの違い 完全に理解しようとすると、時間が無限に溶ける • プロセッサの進化の歴史 • 命令セットアーキテクチャの違い • ビット数の違い • FISCとRISCの違い • システムオンチップ（SoC）とか

19 x86とArmアーキテクチャの違い 完全に理解しようとすると、時間が無限に溶ける • プロセッサの進化の歴史 • 命令セットアーキテクチャの違い • ビット数の違い • FISCとRISCの違い • システムオンチップ（SoC）とか ハードに知⾒がある⼈じゃないと敷居が⾼い ので、AWS Gravitonが従来のチップと何が 違うのかを把握するのが現実的

20 AWS Gravitonプロセッサとは（1/2） • 64ビットArmプロセッサコア搭載カスタムAWSシリコン • クラウドネイティブなワークロードに最適化 • お客様に代わり迅速なイノベーション、ビルド、イテレート を実施

• x86系インスタンス︓2vCPU = 1物理コア • Arm系インスタンス︓1vCPU = 1物理コア 同インスタンスサイズでは、2倍の物理コア利⽤が可能→2倍の物理コアでもコスト は最⼤20%安価 21 AWS Gravitonプロセッサとは（2/2）

22 AWS Gravitonを使うときの公式ドキュメント（1/2） AWS Graviton getting-started • GitHubにホストされている。おそらく これが最新の公式ドキュメント • プログラミング⾔語別考慮事項 • OSサポート情報 • 各種アプリケーションでの推奨バージョ ン • デバッグ・プロファイル https://github.com/aws/aws-graviton-getting-started/

23 AWS Gravitonを使うときの公式ドキュメント（2/2） AWS Graviton2 for independent Software Vendors • AWSのWhitePaperに存在 • Graviton2に依存しているが、そもそものア ーキテクチャから各レイヤーで何を考慮すべ きか、ユースケースの提⽰も含まれている • チュートリアル的な要素は無いが、全体的な アーキテクチャを俯瞰しながら理解するには こちらのほうがオススメ https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/use-case-scenarios.html

24 基本として EC2の場合

25 どれぐらい⼤変か︖ 「プログラミング⾔語環境を含む様々な OSSアプリケーションが対応済み 多くのお客様から想像よりずっと簡単だったとの声」 引用：AWS Graviton AWS Black Belt Online Seminar

26 EC2の場合 Considerations when transitioning workloads to AWS Graviton based Amazon EC2 instances 移⾏のステップが事細かに提⽰されていて、 具体的に⼿元のアプリケーションをどのよう に移⾏するか全てわかる情報 • 移⾏ステップ1. 依存関係の調査 • 移⾏ステップ2. 対応状況・バージョンの確認 • 移⾏ステップ3. テスト • 移⾏ステップ4. 本番環境への投⼊ https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md

27 Lambdaにおける Graviton2導⼊の注意点

28 リリース⽇は2021年10⽉4⽇ https://aws.amazon.com/jp/blogs/news/aws-lambda-functions-powered-by-aws-graviton2-processor-run-your- functions-on-arm-and-get-up-to-34-better-price-performance/

29 実際問題 サーバーレスの代表格Lambdaにおいて プロセッサのアーキテクチャーを 気にする必要あるの︖

30 結論 「あんまり無いよ︕」 Graviton2きたか…!! ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ /

31 x86からArm64へのLambdaの移⾏ アーキテクチャ固有の依存関係やバイナリを持たない場 合、設定変更だけで利⽤可能 • Node.jsやPythonのようなインタプリタ型⾔語、Javaの バイトコードのFunctionなどが該当 • Lambdaがネイティブサポートするほとんどのラ ンタイムでarm64が利⽤可能 • LambdaレイヤーやLambdaエクステンションの中 にArm未対応のバイナリが含まれていないかどう かは確認が必要

32 コンソールだとこれだけ Architecture指定ラジオボタンで 「arm64」を選択

33 対応するランタイムとアーキテクチャ⼀覧 現状arm64アーキテクチ ャに対応していないのは、 Python3.7、Java8、 Amazon Linuxのカスタ ムランタイムぐらい https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

34 コンパイル⾔語での利⽤ RustやGoなどのコンパイル⾔語では、Armをサポート するカスタムランタイム「provided.al2」を利⽤するこ とで、Armアーキテクチャを利⽤可能 ・Goの場合、GOARCHをarm64指定 ・Rustの場合、ターゲットを指定 GOOS=linux GOARCH=arm64 go build cargo build --release -- target-cpu=neoverse-n1

35 Porting Advisor for Graviton（2023年1⽉25⽇） https://aws.amazon.com/jp/about-aws/whats-new/2023/01/porting-advisor-graviton/

36 Porting Advisor for Graviton Gravitonへの移⾏を助けるコマンドラインツール • 静的にソースコードを分析 • ⽋落ライブラリや古いライブラリ、変更が必要なコード 構造を強調表⽰するレポートを作成 • オープンソース • 公式でDockerイメージも提供されているので、dockerが 動いている環境では即座にお試し可能

37 Porting Advisor for Graviton（実⾏サンプル） ./dist/porting-advisor-linux-x86_64 ./sample-projects/ | Elapsed Time: 0:00:03 Porting Advisor for Graviton v1.0.0 Report date: 2023-01-06 23:48:20 13 files scanned. detected java code. we recommend using Corretto. see https://aws.amazon.com/corretto/ for more details ./sample-projects/java-samples/pom.xml: dependency library: leveldbjni-all is not supported on Graviton ./sample-projects/java-samples/pom.xml: using dependency library snappy-java version 1.1.3. upgrade to at least version 1.1.4 ./sample-projects/java-samples/pom.xml: using dependency library zstd-jni version 1.1.0. upgrade to at least version Use --output FILENAME.html to generate an HTML report.

38 いやぁ 案外楽そうでしたね よござんす

39 Fargateにおける Graviton2導⼊の注意点

40 リリース⽇は2021年11⽉25⽇ https://aws.amazon.com/jp/blogs/news/announcing-aws-graviton2-support-for-aws-fargate-get-up-to-40-better- price-performance-for-your-serverless-containers/

41 実際問題 EC2関係無いFargateにおいて プロセッサのアーキテクチャーを 気にする必要あるの︖

42 結論 「めっちゃあります」 Graviton2めんどい…?? ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ /

43 それぞれの形式のアーキテクチャ互換性 ファイル形式 アーキテクチャ互換性 スクリプトファイル 有る 基本気にしなくて良い バイナリファイル 無い アーキテクチャごとのビルドなど考慮 が必要 コンテナイメージ ？？？？？？

44 それぞれの形式のアーキテクチャ互換性 ファイル形式 アーキテクチャ互換性 スクリプトファイル 有る 基本気にしなくて良い バイナリファイル 無い アーキテクチャごとのビルドなど考慮 が必要 コンテナイメージ 無い アーキテクチャごとのイメージビルドが 必要

45 コンテナイメージでCPUアーキテクチャごとにビルドが必要な理由 コンテナイメージには、CPUアーキテクチャの違いに依存するものが多く含まれて いるため • バイナリ • 特定CPUアーキテクチャ向けにコンパイルが必要 • 各種ライブラリ • イメージビルドするさいに取り込まれる共有ライブラリ • glibc、OpenSSL • システムコール • OSカーネルとのインターフェースのシステムコールもアーキ テクチャに依存

46 いろんな疑問が出てくる出てくる 実際にどうやってビルドするの︖ アーキテクチャ毎に別でECR⽤意するの︖ タグを分けたりする︖ 今⽇の晩御飯は︖

47 キーワードはこちら マルチアーキテクチャ コンテナイメージ これが全てを解決しますええかんじやん…!! ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ /

48 コンテナのCPUアーキテクチャ移⾏⼿順 • ⼿順①︓利⽤しているアプリケーションの状況確認 し、適宜アップデート • ⼿順②︓新アーキテクチャ⽤コンテナビルド⼿順の 確⽴ • ⼿順③︓デプロイ

49 参考にするべき公式情報 Container-based workloads on Graviton https://github.com/aws/aws-graviton-getting-started/blob/main/containers.md

50 ⼿順①︓アプリケーションの状況確認 主な確認ポイント • Dockerfile • ベースイメージ︓マルチアーキテクチャで提供されている場合、対応不要 • ビルド時取得しているパッケージのArm対応確認 • パッケージ管理システムで取得しているライブラリのarm対応確認 • サイドカーコンテナ • エージェントコンテナ • （onEC2の場合）ホストコンテナのAMI

51 ⼿順①︓アプリケーションの状況確認 アプリケーション⾯ではLambdaでも紹介した、 Porting Advisor for Gravitonが役にたちます

52 ⼿順②︓新アーキテクチャビルド⼿順の確⽴ 基本︓マルチアーキテクチャイメージとしてビルドし ECRにPushしておけば、ホスト側（Fargateを想定）で、 マニフェストファイルを読み込み、同じCPUアーキテク チャのイメージをPullして実⾏してくれる 1. マルチアーキテクチャイメージでPushしておく 2. ホスト側（Fargate、EC2）でよしなに該当するア ーキテクチャのイメージをPullして実⾏してくれる

同じタグで複数のコンテナイメージをサポート 53 ⼿順②︓新アーキテクチャビルド⼿順の確⽴

54 ⼿順②︓新アーキテクチャビルド⼿順の確⽴ マルチアーキテクチャイメー ジのビルドに⽋かせないツー ルがbuildx • ビルドするユーザー環境に 依存しない複数プラットフ ォーム向けのビルドが可能 • --platformフラグを設定す ることで、x86やArm向けの イメージをビルド https://github.com/docker/buildx#getting-started

55 ⼿順②︓新アーキテクチャビルド⼿順の確⽴ https://github.com/docker/buildx#getting-started $ docker buildx build ¥ --push ¥ --platform linux/arm/v7,linux/arm64/v8,linux/amd64 ¥ --tag your-username/multiarch-example:buildx-latest .

56 ⼿順③︓デプロイ ECSのタスク定義で Architectureに 「Linux/ARM64」を指定 して、サービスからこのタ スク定義を参照してタスク を起動することで、Armア ーキテクチャのコンテナが 起動

57 いやぁ どうですかね︖ みなさん、いけそうですか︖

58 まとめ

59 まとめ • GravitonをAWSで使うといろいろよござんすな点 は多い • Lambdaの場合 • 依存バイナリがなく、カスタムランタイムも利⽤してい なければ、Graviton2への移⾏はハードル低め • Fargateの場合 • コンテナイメージ⾃体に各種バイナリが含まれているの で専⽤ビルドが必須 • マルチアーキテクチャイメージの概念をしることで、今 までのオペレーションを⼤きく変えずに移⾏を検討する

60 皆さんのよりよい Graviton2ライフを 応援しています︕