re:Invent 2024: AWSのGravitonチップ進化と性能向上、Robinhoodの活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - AWS Graviton: The best price performance for your AWS workloads (CMP320)
この動画では、AWSのカスタムチップGravitonの進化と価格性能比の優位性について解説しています。2018年の初代から2023年のGraviton4まで、各世代で性能と効率が向上し、現在では95%のトップ100顧客が採用するまでに至っています。Graviton4は前世代比で30%の性能向上、50%増のCPUコア数、2倍のL2キャッシュを実現し、初めてマルチソケットコヒーレンシーをサポートしました。また、RobinhoodのSenior Principal EngineerのSujith Katakamが登壇し、18-20ヶ月で本番環境の90%以上をGravitonに移行した具体的な手法と、Mixed Instance Policyを活用したガードレールの構築方法について詳しく解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Gravitonの概要と本セッションの目的
こんにちは。皆様にお会いできて大変嬉しく思います。これまでのセッションをお楽しみいただけていることを願っています。CMP320へようこそ。このComputeのブレイクアウトセッションでは、AWS Gravitonがどのようにワークロードに対して最高の価格性能比を実現するかについて詳しく学んでいただきます。私はAWSのEC2コアコンピュート製品のProduct Managementを率いるSudhir Ramanです。本日は、AWSのSenior Principal EngineerのAli Saidi、そしてRobinhood MarketsからゲストスピーカーとしてSujith Katakamをお迎えしています。
これからの1時間ほど、Gravitonがどのように最高の価格性能比を実現するのかについて詳しく見ていきます。ワークロードのパフォーマンスについて話し合い、お客様の事例を紹介し、そしてワークロードをGravitonへ移行するためのベストプラクティスについてお話しします。また、SujithからRobinhoodがGravitonを採用した経緯、その全体的な journey、そして採用プロセスから得られた重要な気づきや学びについてお話しいただきます。
AWSのカスタムチップ開発とGravitonの進化
AWSは過去数年にわたってカスタムチップの開発に投資を続けており、これらはデータセンターインフラストラクチャ、コアコンピュート、機械学習など、複数の分野にまたがっています。2017年後半からEC2インスタンスタイプを支えているAWS Nitro Systemは、カスタムNitroカードすなわちカスタムチップで構成されており、ストレージとネットワーキングをメインプロセッサからオフロードし、リソース効率を最大化することを可能にしています。InferentiaとTrainiumでは、機械学習、ディープラーニング、そして生成AIアプリケーションを加速するために設計されたカスタムチップを提供しています。そしてGravitonは、クラウドでほぼすべてのワークロードに対して最高の価格性能比を提供することを目的とした、現代のサーバー向けの汎用チップです。
AWSがカスタムチップ開発の journey を始めた理由について少しお話ししましょう。専門化から始まり、多くの理由があります。これにより、適切な機能セットを導入し、クラウドのユースケースに最適化し、コストと電力効率を最適化することができます。製品の定義からサーバーの構築、データセンターへの導入までのスピードが重要です。ハードウェアとソフトウェアスタックの両方を所有するすべてのチームが同じ屋根の下にいます。イノベーションについては、CPUからサーバー、インフラストラクチャ、仮想化レイヤー、そしてアプリケーションレイヤーまで、スタック全体にわたってイノベーションを起こし、それらをサイロ化せずに全体的に行うことで、お客様に革新的な価値を創造することができます。そして最後にセキュリティですが、Nitroはハードウェアベースのroot of trustメカニズムを通じて、サービスのセキュリティレベルを向上させる方法を提供しています。
私たちのGraviton journeyは、ARMベースのEC2インスタンスでアプリケーションが実行できることを実証した最初のGravitonチップとともに2018年に始まりました。それ以来、各世代でこれらのチップのパフォーマンス、機能、効率性を向上させてきました。現在、私たちは第4世代のGraviton4プロセッサを提供しており、様々なワークロードに対してEC2で最高の価格性能比を実現しています。そして現在、150を超えるGravitonチップ搭載のEC2インスタンスをグローバルで提供しています。
各世代で性能と効率を向上させることで、Gravitonがもたらすパフォーマンスとコスト面でのメリットを活用できるワークロードの範囲も広がってきました。アプリケーションやゲームサーバー、メディアエンコーディング、High Performance Computingから、大規模データベース、分析、CPUベースの機械学習アプリケーションまで、幅広い用途に対応しています。
Gravitonの各世代の特徴とパフォーマンス向上
それでは、各世代の特徴を見ていきましょう。まず、Graviton2は2019年にリリースされ、同等のインスタンスと比較して最大40%優れたコストパフォーマンスを実現しました。現在、Graviton2には13種類のインスタンスタイプがあり、コンピュート最適化、メモリ最適化、汎用、ネットワーク最適化、ストレージ最適化、さらにはGPU接続バージョンまで、幅広いワークロードをカバーしています。
その2年後に登場したGraviton3は、Graviton2と比べてさらに25%高い演算性能を実現し、浮動小数点演算性能は2倍に向上するなど、性能の向上を続けました。また、Graviton3は、AWS のデータセンターにDDR5メモリを初めて導入し、DDR4メモリと比べて最大50%の帯域幅向上を実現しました。
多くのお客様がCPU上でAIやMLのワークロードを実行していることから、Graviton3ではこれらのワークロード向けにアーキテクチャの改良も行いました。これには、bfloat16命令のベクター幅を2倍に拡張したことも含まれます。ARM64エコシステムにおけるMLアプリケーションの改善と組み合わせることで、お客様はGraviton2と比較してGraviton3で最大3倍のAIアプリケーション性能を実現できます。EC2インスタンスタイプのポートフォリオとしては、 現在、コンピュート、汎用、メモリ、ネットワーキングをカバーするGraviton3搭載の8種類のインスタンスタイプを提供しています。また、High Performance Computing向けに、ベクター帯域幅を改善した専用インスタンスも用意しています。
そして、これが最新のGraviton4です。これは私たちが今まで開発した中で最もパワフルで、 最もエネルギー効率の高いチップです。各Graviton4チップは、Graviton3と比較してコア数が50%増加し、L2キャッシュは2倍、帯域幅は75%向上しています。さらに、Graviton4では初めてマルチソケットコヒーレンシーをサポートし、より大規模なスケールアップワークロードに対応できるようになり、最も要求の厳しいデータベースや大規模データ分析にも対応できるようになりました。
Graviton4を搭載したEC2インスタンスについて見ていきましょう。ここ数ヶ月間、私たちはGraviton4チップを搭載した様々なEC2インスタンスの展開を開始してきました。すでに、Graviton4を搭載した最新の第8世代Compute、Memory、General Purposeインスタンスを提供しており、それぞれのインスタンスファミリーで最高の価格性能比を実現しています。Graviton3と比較して最大30%高い計算性能を提供し、CPUとメモリの数を3倍にスケールアップして、最大3テラバイトのDDR5メモリまで対応しています。これらはすべて第5世代Nitroシステム上に構築されており、現在、世界の複数のリージョンで一般提供されています。
Graviton4インスタンスラインナップの最新の追加は、re:Inventの開始時に数日前にローンチしたばかりのI8g Storage最適化インスタンスです。I8gは、トランザクショナルデータベースや分析ワークロードなど、レイテンシーとI/Oに敏感なストレージアプリケーションに最適です。22.5テラバイトのローカルNVMeインスタントストレージを備え、最大65%優れたリアルタイムストレージパフォーマンスを提供します。さらに、昨日は第6世代Nitroシステムをベースとしたネットワーク最適化Graviton4インスタンスも事前発表され、数週間後に利用可能となる予定です。
多くのお客様が様々なユースケースでGraviton4を採用しているのを目にしています。世界最大級のゲームの一つであるFortniteを運営する大手インタラクティブエンターテイメント企業のEpic Gamesは、Graviton4をテストし、これまでテストした中で最速のインスタンスだと評価しています。IBM Observabilityはアプリケーションスタック全体の可視性を提供していますが、すでにGraviton3で実現していた節約に加えて、Graviton4に移行することでCPU使用率がさらに30%改善されました。SAPはSAP HANA CloudがGravitonインスタンスで稼働していることを発表し、Graviton4では、Graviton3と比較してトランザクションワークロードで最大40%の改善が見られています。
RobinhoodによるGraviton採用の journey：戦略と実装
Electronic Design Automation（EDA）は、カスタムチップの設計、テスト、検証、製造に必要な重要なワークロードカテゴリーであり、多くの半導体企業やAWSがこれらのワークロードをクラウドで実行しています。以下は、Graviton4チップ自体の開発をサポートするために使用されたクラスターのスナップショットです。このクラスターはスケールで実行され、高性能コンピューティングを必要とし、通常の使用量の約5倍のピークを持ちます。Graviton4による高速な処理能力を提供することで、多くのチップ企業やAWSがこれらのワークロードをクラウドに移行し、最も効率的な方法で実行し、チップの市場投入までの時間を短縮することを可能にしています。
例えば、Armが新しいGraviton4ベースのX8gインスタンスを形式検証ワークロードに使用した際、前世代のインスタンスと比較して最大50%の改善が見られました。
これは市場投入までの時間を大幅に短縮できるワークロードの1つです。顧客の動向に関して、あらゆるカテゴリー、地域、業種、規模の顧客がAWS Gravitonを大規模に採用しているのが見られます。現在、トップ1002社のお客様の95%がAWS Gravitonを利用しています。過去2年間で、新規に導入されたコンピュート容量の50%以上がAWS Gravitonベースとなっています。
価格性能比のメリットに加えて、今日では多くの組織がサステナビリティと炭素排出量の削減に注力しています。AWS Gravitonは他の同等のプロセッサと比較して、同じワークロードの処理に必要なエネルギーを最大60%削減できるため、多くのお客様がサステナビリティ目標の達成に向けてAWS Gravitonを活用しています。いくつか例を見てみましょう。Pinterestは、APIスタック用に数千のインスタンスを使用しており、これをAWS Gravitonに移行したところ、APIリクエストあたりの炭素排出量が62%削減されました。Zendeskは、コアとなるコンピュートアプリケーションをAWS Gravitonに移行し、パフォーマンスが30%向上したことに加えて、月間の炭素排出量が最大50%削減されました。そして、Aerospikeは、AWS Gravitonプロセッサ向けに最適化され、彼らのレポートによると、炭素排出量が49%削減されたとのことです。
では、AWS Graviton4プロセッサについてより詳しく説明するため、Ali Saidiに交代したいと思います。ありがとうございます。AWS Graviton4の詳細を見ていきましょう。これはGraviton4のCPUダイの写真です。AWS Gravitonは、Graviton2からGraviton3、そして現在のGraviton4まで、一貫したペースで進化を続けています。AWS Graviton4ではソケットあたりのCPUコア数を50%増加させ、64コアから96コアに増やしました。また、Graviton4ではL2キャッシュも大幅に増やしています。その理由は単純で、大規模なワークロードには大量のキャッシュが必要だということが分かっているため、プロセッサの近くにできるだけ多くのキャッシュを配置したいからです。
AWS Graviton3と同様に、7つのチップレット設計を採用しており、1つの中央コンピュートダイ、4つのDDRダイ、2つのPCIeダイで構成されています。DDRダイはDDR5を採用しており、発表時点でAmazon EC2で最速のDDRシステムとなる12チャネルのDDR5-5600と、最大96レーンのPCIeを備えています。実際のチップの詳細を見てみましょう。すべてのコアはメッシュで接続されており、そのメッシュ全体に最終レベルキャッシュの部分が分散配置されています。この12チャネルのDDRは、理論上500ギガバイト/秒以上、実効で500ギガバイト/秒弱の帯域幅を提供します。
AWS Gravitonでは、対応可能なワークロードの範囲を着実に拡大してきました。Graviton1では、ARMプロセッサでもx86と同じような体験ができることを示すことが主な目的でした。異なるAMIの起動、インスタンスの開始と停止、IOデバイスのアタッチとデタッチなどが可能で、一部のお客様はそこで良好なパフォーマンスを示すワークロードを見出しました。Graviton2では、スケールアウトワークロードへの適用が始まりました。お客様はJavaやGo、Rust、キーバリューストア、ロードバランサーなどを実行するようになりました。AWS Graviton3では、SIMDの幅が広がったことで、さらにその範囲が拡大し、HPCや機械学習のワークロードもAWS Gravitonへの移行を開始しました。
AWS Graviton4では、スケールアップワークロードについて説明します。お客様から、小規模なデータベースはすべてAWS Gravitonに移行したものの、大規模なものも移行したいという声がありました。96コアや192コアのデータベースが必要なのです。そこでAWS Graviton4が登場しました。通常のワークロードで30%のパフォーマンス向上を実現するだけでなく、最も要求の厳しいワークロードも実行できるようになりました。
Graviton4は、マルチソケットコヒーレンスをサポートする初めてのプロセッサです。ソケットあたりのコア数が50%増加しただけでなく、2つのソケットを1つのシステムに統合して、最大192コアまたは48 xlargeのVMを提供できます。RAMでは最大3テラバイトのDRAM容量を実現し、最大インスタンスでは192コアを搭載しています。
実際のワークロードのパフォーマンスを最適化することに加えて、 Gravitonではすべての高速インターフェースを暗号化してきました。Graviton2から始まり、DRAMインターフェースを暗号化した最初のチップとなりました。Graviton4では、NitroカードとGravitonチップ間のインターフェース暗号化にまで拡張しています。Gravitonチップ間のチップ間リンクも暗号化されており、Nitroカードのブート検証と同様に、Graviton4はホストブートの各段階を検証、監視、保護することでセキュリティの基準を引き上げています。
Graviton3では、通常の2ソケットではなく3ソケットのサーバーを実現しました。これは、Nitroカードとホストとの緊密な結合があったからこそ可能でした。Graviton4では、この柔軟性をさらに高めています。このデュアルソケットサーバーは、非コヒーレントな2つの仮想インスタンス（または仮想インスタンスのセット）、1つの大規模なコヒーレントインスタンス、2つのメタルインスタンス、あるいは1つの大規模なコヒーレントメタルインスタンスとして構成できます。48 xlargeインスタンスを提供する際、実際にコヒーレンスが必要ない場合はそれをオフにすることで電力を節約できます。
Graviton4の開発にあたっては、 実際のワークロードのパフォーマンスを注意深く観察し、CPUのパフォーマンスについてARMと協力して検討を重ねました。これを視覚化するために、レーダーグラフを使用しています。1つのプロットで、ワークロードの特性を包括的に把握することができます。各軸はチップ設計の異なる特性に対応しており、その値はワークロードがその特性にどの程度敏感であるかを示し、最終的に全体的なパフォーマンスを決定します。
このプロセスは2つの部分に分けて考えることができます。フロントエンドは命令を受け取り、その性能は分岐、分岐ターゲット、処理される命令の数などの要因に影響を受け、最終的にフロントストールを引き起こします。 プロセッサの後半部分ではこれらの命令を実行し、L1、L2、L3キャッシュへのヒット率や命令ウィンドウサイズなどの特性に影響を受け、バックストールが発生します。これらのグラフ上でワークロードをプロットし、左右を見ることで、そのワークロードがフロントエンドとバックエンドのどちらに影響を受けやすいかが一目で分かります。値が大きいほど相対的な影響が大きく、小さい方が望ましいということになります。
まずはベンチマークから見ていきましょう。 この従来型のベンチマークでは、多数のバックストールを伴いL3キャッシュに負荷をかけていることが分かります。これは、パイプラインのバックエンドが一般的に多くの作業を行えなかったか、実行すべき作業を見つけられなかったことを示しています。グラフの右側に感度が表れている一方で、左側にはあまり見られません。よく考えてみると、これは理にかなっています。ほとんどのベンチマークは大きなアプリケーションから抽出された小さなカーネルで、ループ内で同じことを繰り返し実行するためです。プロセッサのフロントエンドにはあまり影響を与えず、バックエンドに大きな負荷をかけます。これらは安定して実行しやすいように設計されているのです。
では、実際のワークロードがどのように見えるか比較してみましょう。 Cassandra、Groovy、NGINXなど、私たちのお客様が実際に実行すると予想されるワークロードです。これらを比較すると、まったく異なる様相を呈していることが分かります。全く異なる要因によってボトルネックが発生しているのです。特に、これらのワークロードはマイクロベンチマークが重視する要素をあまり気にしていませんが、グラフの左側、つまり分岐予測器やTLBミス、プロセッサの命令側に関する部分をより重視しています。これらのベンチマークとは異なり、フロントエンドがストールの原因となっているのです。そのため、私たちは興味深い取り組みを行うことになりました。
これらの発見は、いくつかの改善につながりました。 特に興味深い発見の1つは、ワークロードが命令の面でベンチマークよりもはるかに大きいということです。これが、Graviton4でL2キャッシュサイズを2倍にした理由の1つで、実際のワークロードでより多くの命令に対応できるようになりました。また、特に分岐に関連する部分やブランチプレディクタの拡張など、CPUのフロントエンド部分を強化する特別な改良も行いました。さらに、Graviton4はブランチターゲットの識別やROPの緩和に特化した新しい命令を追加するRV9アーキテクチャをサポートしています。
それでは、Graviton4のパフォーマンスを見ていきましょう。 まずMySQLから始めて、いくつかのワークロードを見ていきます。この比較では、Graviton3ベースのR7gシステムとGraviton4ベースのR8gシステムを比較しています。比較的小規模なVMであるAVCPUV MSを使用しています。テストには、倉庫の在庫管理、注文処理、支払い処理、配送管理、在庫確認をシミュレートするように設計されたオープンソースの負荷生成ツールであるHammerDBを使用しています。パフォーマンスは、データベースで1分間に処理される新規注文の数で測定されます。Graviton3からGraviton4への移行により、わずか1世代のプロセッサで40%という印象的なパフォーマンス向上が達成されています。
これらのパフォーマンス向上はMySQLだけに限りません。ロードバランサーとしても機能する人気のWebサーバーであるNGINXでも、同様の向上が見られます。私たちの構成では、固定のロードジェネレーターとWebサーバー数を使用してロードバランサーとして使用しました。ロードバランサーとしてR7gとR8gを比較したところ、30%のパフォーマンス向上が確認されました。同様に、JVM上で動作するGroovyを使用するオープンソースのJava WebアプリケーションフレームワークであるGrailsについても、お客様が一般的に使用しているJavaワークロードやスタックをより適切に反映していることがわかりました。Graviton3ベースのインスタンスとGraviton4を比較したところ、1秒あたりのリクエスト数が45%増加しました。
Graviton上での機械学習フレームワークについても大きな進展がありました。多くのフレームワークが現在Gravitonでの実行をサポートしており、特にPyTorchのパフォーマンスは顕著な改善を示しています。PyTorch 1.13からPyTorch 2への移行で、torch compileを使用した一部のモデルで3.5倍以上の改善を達成しました。PyTorch 3.21では2倍の改善が見られ、現在取り組んでいるJAXの改善では1.5倍の向上を示しています。他のフレームワークも同様の進展を見せており、Graviton3からGraviton4では通常20〜30%のパフォーマンス向上を実現しています。
2018年のA1インスタンスから、2019年のGraviton2、2021年のGraviton3、そして現在のGraviton4まで、私たちの歩みを振り返ると、ワークロードによって異なりますが、4世代を通じて約4倍のパフォーマンス向上を達成しています。総じて、GravitonはGraviton3と比べて最大30%高いパフォーマンスを実現し、業界をリードするパフォーマンスを提供しています。クラウドで初めてDDR5-5600メモリを搭載したシステムであり、EC2で最高のコストパフォーマンスを提供し、Graviton3の3倍までの大きさのインスタンスを提供します。
Graviton移行のベストプラクティスと今後の展望
ここで、RobinhoodがどのようにGravitonを採用したかについて、Sujithにバトンを渡したいと思います。「皆さん、こんにちは。RobinhoodのSujithです。現在Staff Software Engineerとして働いており、RobinhoodがどのようにGravitonの導入を開始し、なぜGravitonを選択したのかについてご説明させていただきます。Gravitonへの移行を検討されている方々にとって、私たちの移行戦略から何か有益な情報を得ていただけると確信しています。Gravitonやコンピューティング全般について詳しくお話する前に、Robinhoodをご存じない方のために簡単にご紹介させていただきます。Robinhoodのミッションは、すべての人のための金融の民主化です。このミッションの一環として、Robinhoodは株式取引から暗号資産の売買、クレジットカードなど、多岐にわたる製品を提供してきました。何百万ものお客様が日々Robinhoodを利用されており、私たちが日々追求している成長とイノベーションを実現するために、インフラストラクチャーのコスト効率性、高いパフォーマンス、そしてスケーラビリティが非常に重要となっています。
Gravitonを選んだ理由についてお話しする前に、Robinhoodのコンピュートアーキテクチャについてご紹介し、その概要をお伝えしたいと思います。私たちは主にKubernetesを主要なコンピュートプラットフォームとして使用しており、これはAWS EC2インスタンスとサービスによってサポートされています。Robinhoodでは、サービスはユーザーに公開されているエッジ、APIサーバー、プラットフォームサービス、そしてデータストアなどのカテゴリーに分類されます。私たちには、メモリ集約型、CPU集約型、ディスク集約型など、多様なワークロードが存在します。新しく導入するアーキテクチャがこれらすべてのタイプのワークロードと互換性があり、うまく機能することを確認する必要がありました。そのため、適切なアーキテクチャの選択には非常に慎重を期しました。なぜなら、この移行が一部のワークロードだけでなく、すべての種類のワークロードにメリットをもたらすことを確実にしたかったからです。
では、なぜGravitonを選んだのでしょうか？主に4つの理由があります。他の発表者も話していたように、Gravitonはイノベーションの最先端にあり、各世代が前世代から大幅に進化しています。私たちはこの進化の波に乗り、Gravitonが提供するすべてのメリットを享受したいと考えました。2つ目の理由は、CPUコアあたりの価格です。GravitonはIntelファミリーのインスタンスタイプと比較して一般的に安価です。プロダクションクラスターで数千のEC2インスタンスを実行している私たちにとって、価格効率の向上は非常に重要です。3つ目の理由は、サステナビリティ目標に関連します。RobinhoodはESGの数値を公開しており、Gravitonへの移行によってESGの取り組みがさらに加速すると考えています。Aliが説明したように、リソース利用の面で非常に効率的であり、私たちはGravitonをRobinhoodのワークロードに適用した場合の効果を実際に確認し、リソース利用効率の向上が実現できるかを検証したいと考えました。
このプレゼンテーションの核心部分では、私たちがGravitonを採用するまでの道のり、経験した各フェーズ、直面した課題、そしてGravitonを私たちの主要なコンピュートタイプとするために実装した施策についてお話しします。大まかに言えば、私たちのGravitonへの journey は2022年6月に始まりました。これはちょうどGraviton3が注目を集め始めた時期で、私たちはGravitonへの移行がRobinhoodにとって有益かどうかを理解するための簡単なPOCから始めました。その後は振り返ることなく前進し、18〜20ヶ月の期間で本番環境のワークロードの90%以上をGravitonに移行しました。
それでは、各フェーズについて詳しくお話ししましょう。第一フェーズは、実際に検証を行うPOCフェーズでした。POCでは主に3つの点を検証しました：ARM64互換のアーティファクトのビルドとリリースがどのようなものになるかを理解すること、私たちのシステムがそのままARM64をサポートできるのか、それともOSの変更やPythonパッケージやプロセスのアップグレードが必要なのかを理解すること、そして最後に、期待通りのパフォーマンスが得られるか、期待通りに動作するか、求めていたメリットが得られるかを自分たちで検証することでした。そして、次のフェーズに進んでいることからもわかるように、POCは成功したと言えます。
POCが大きな成功を収めたため、私たちはSDLCサイクルにARM64サポートを追加することにしました。ARM64アーキテクチャのサポートを確実にする必要があった主な領域は、ビルド、リリース、デプロイの3つのフェーズでした。
Build フェーズの準備として、Robinhood には多くのコンパイル済みコードがあります。Go を使用していますが、C、C++、Rust などのネイティブ言語を使用する依存関係もあります。また、Python で書かれた多くのサービスもあり、それらもネイティブコードのパッケージを使用しています。そのため、これらすべてが ARM64 アーキテクチャ上でコンパイルされ、実行可能であることを確認する必要がありました。
私たちは Bazel をビルドの主要な手段として使用しています。Go については、デフォルトでクロスコンパイルをサポートしているため、Graviton 上で Go サービスを実行できるようにするための作業はほとんど必要ありませんでした。Python については、パッケージをインストールする必要があるため、プロセス自体が遅くなります。パッケージが事前にインストールされている場合は、Artifactory から取得するだけです。そうでない場合は、C コンパイラを使用してコードをコンパイルし、このアーティファクトをリリースする必要があります。このプロセスは一般的に遅いのですが、AMD インスタンスを使用して ARM64 アーキテクチャ向けにコードをコンパイルする場合、さらに遅くなってしまいます。
この課題を克服するために、いくつかの改善を行いました。主な改善点は、Bazel ワークフローで使用する C ツールチェーンを刷新し、クロスコンパイルを可能にしたことです。これにより、同じツールチェーンを使用して複数のアーキテクチャ向けに同じコードをコンパイルできるようになりました。Python サービスについては、Python ホイールを事前にビルドして Artifactory にアップロードすることで作業を前倒しし、アーティファクトのリリースプロセスを大幅に高速化しました。また、ARM64 ビルドエージェントを使用して ARM64 イメージをビルドすることで、仮想化やエミュレーションを使用する必要がなくなりました。最後に、すべてのアプリケーションに対してマルチアーキテクチャベースのイメージをリリースし、移行プロセス中に AMD64 にロールバックすることを可能にしました。これはより安全なオプションでした。
リリースフェーズでは、前述の通り Bazel を使用しています。 リリースパイプラインでは、両方のアーキテクチャでテストを実行するように調整を行いました。これにより、ロールバックが必要な場合でも、AMD64 上でコードをテストしていないという追加のリスクを負うことなく、プロセスを簡単に進めることができます。コードのテストが完了し、リリース可能と判断されたら、AMD と ARM64 の両方のイメージをリリースし、関連するアーティファクトを Amazon S3 と Amazon ECR にプッシュします。
AMD と ARM64 で2つの異なるアーティファクトをリリースする場合、ワークロードをデプロイする際に EC2 エコシステムが適切なアーティファクトを取得するようにする必要があります。これを簡単にするために、マルチアーキテクチャの Amazon ECR イメージインデックスをリリースしました。 イメージインデックスは、AMD と ARM64 の2つの異なるイメージへのポインタとなっており、Kubernetes ノード上のコンテナランタイムがノードのアーキテクチャを検出し、インデックスから適切なイメージを取得することができます。また、パッケージの使用や事前ビルドパッケージに関する内部の詳細を知る必要なく、移行を容易にし、ユーザーに対して透過的にするための新しいユーザー向け API も公開しました。最後に、Amazon ECR には特定のリポジトリが保持できるイメージ数に関する制限があります。
画像のリリース数が倍増したため、制限に達することがないよう確実な対策を講じる必要がありました。最新かつデプロイ可能なタグが常に利用できるよう、堅牢なECRリポジトリポリシーを追加しました。また、すでにデプロイされているタグと最新の1000個のタグを認識し、それらを保持しながら古いタグを廃止できる社内のクリーナージョブを構築しました。
次にデプロイフェーズについてお話しします。先ほど申し上げたように、私たちはコンピュートプラットフォームとしてKubernetesを使用しており、Kubernetesクラスター管理ツールであるkopsはすでにARM64をサポートしています。コンピュートの観点からはすでに対応済みでしたが、コンテナランタイムがアーキテクチャを認識し、イメージインデックスから適切なイメージをプルできることを確認する必要がありました。テストを実施し、Dockerや他の使用しているコンテナランタイムがこれを実行できることを確認しました。これを検証した後は、コンテナランタイムが提供する既存の機能を活用できたため、私たちの作業は少なくて済みました。
導入フェーズを通じてご覧いただいたように、私たちは強制ではなくオプトイン方式を採用したいと考えました。特定のTaintとTolerationを公開することで、新しいコンピュートレイヤーAPIを作成し、オプトインのためのワークフローを構築しました。KubernetesクラスターはバックグラウンドでAuto Scaling Groupを使用しているため、Graviton専用のASGを作成し、これらの専用ASG上にワークロードをデプロイすることで、プロセスとロールバックがより簡単になりました。
どんなソフトウェアでも問題が発生するリスクは常にあり、実際に問題は発生します。私たちは問題を防ぐための様々なガードレールを積極的に追加したいと考えました。最初に追加したのはアドミッションチェックで、主にGravitonにデプロイされるアーティファクトが確実に互換性があり、イメージインデックスを使用しているかを確認します。これは常にロールバックへのパスを確保したかったためです。また、アプリケーションがすでにアーティファクトをリリースしており、これらのGraviton ASGにデプロイされる資格を得るために適切なアフィニティを使用していることも確認したいと考えました。前提条件のいずれかが失敗した場合、アプリケーションの信頼性とアップタイムに影響が出ないよう、管理上x86に戻すようにしました。
2番目のガードレールとして、AWSのMixed Instance Policyの概念を活用しました。Mixed Instance Policyでは、優先するインスタンスタイプのソート済みランク付きリストを持つことができます。Graviton3は比較的新しいインスタンスタイプだったため、インスタンスのフィルレートに関する懸念が生じないようにしたいと考え、マルチアーキテクチャASGを作成することにしました。このAuto Scaling Groupのフォールバックインスタンスタイプがx86を指すようにすることで、このマルチアーキテクチャの概念を導入しました。AWSがインスタンス起動時にGravitonインスタンスを見つけられない場合、私たちが数年間実行してきたx86を含む、優先度付けされたインスタンスタイプのリストを順に確認していきます。
ここで、AWSに大きな賛辞を送りたいと思います。x86インスタンスが起動された場合を検知するアラートを設定しましたが、過去2年間このアラートが一度も発報されなかったことは素晴らしい成果です。ARM64 のサポートを追加し、多数のAPIを公開したことで、私たちはすべてのワークフローにGravitonを採用するプロセスを進めることができました。 私たちが用いた戦略はシンプルです。まず、自動的に対応可能で特別な作業が不要なGolangを優先的に使用し、その後でPythonのプリビルドされたWheelやパッケージのサポートを構築していきました。戦略の第二の部分は、影響度による優先順位付けです。移行の観点から、複雑なサービスに取り組むことで最大のブロッカーを早期に発見することを重視しました。
このアプローチにより、1つのサービスで問題を解決すれば、多くのワークロードの問題も同時に解決できます。影響度の二つ目の側面は主にフットプリントに関するもので、最大のフットプリントを持つアプリケーションを優先することで、プロセスの早い段階で成果を得ることができます。
移行チェックリストについて、まず アプリケーションワークロードがマルチアーキテクチャのアーティファクトをリリースするためのAPIを使用することを期待します。コミュニティレベルで実施していた受け入れチェックを、アドホックな互換性チェックツールを通じて公開し、同様のチェックを実行してアプリケーションが実際に対応可能であることを事前に保証できるようにしました。これにより、アプリケーションが互換性を持たない場合、移行プロセスのすべてのステップを経る必要なく、早い段階で検出できるため、より迅速な反復が可能になりました。互換性が確認されたら、ユーザーは私たちが公開したCompute APIを使用してマルチアーキテクチャのコンピュートにオプトインするだけです。この設定がマージされた後、最新の設定をデプロイすれば、Graviton上で実行されることになります。
そして最も重要な部分です。Gravitonは非常にコスト効率が高く、リソース使用率が最小限で済むため、すべてのアプリケーションからのリソースリクエストを削減するのに役立ちます。 このワークフローは単純明快です。数日間リソース使用率をモニタリングし、使用量対リクエスト比が快適な範囲に収まるようにリソースリクエストを徐々に減少させていきます。この比率に満足できる水準に達するまで、このプロセスを繰り返します。この方法により、ワークロードが要求するリソースを削減し、Kubernetesノードへの密度の高いパッキングが可能となり、結果としてKubernetesクラスターのキャパシティを縮小することができました。
私たちは成果の実現においてまだ道半ばです。特にGraviton4に関して、さらなる取り組みが必要です。現在、96 CPUコアを持つより大きなインスタンスサイズを活用し、さらなるアンパックを行ってKubernetesクラスターのサイズを縮小できるよう、Graviton4を積極的にフリートに導入しています。これにより、DaemonSetやシステムプロセスが使用するCPUを自動的に節約でき、Graviton4のパフォーマンス向上は更なる恩恵となるでしょう。第二に、成果実現のセクションで見たように、リソースリクエストを段階的に削減する必要がありましたが、YAML設定を変更してデプロイする必要があるため、これは面倒なプロセスでした。このプロセスをよりシームレスにするため、履歴データを通じて管理的にこれらの設定を行う動的リソース割り当ての採用を目指しています。最後に、x86上でも起動時に急激なスパイクが見られる特定のワークロードについて、さらなる効率化の可能性を探るためにプロファイリングを行っています。
Gravitonのソフトウェアエコシステムと移行ガイドライン
このプロジェクトを可能にしてくれたRobinhoodチーム全体に感謝の意を表したいと思います。 Sujitさん、素晴らしい洞察をありがとうございます。Robinhoodが Gravitonで実現できたことを見られて、とても良かったです。本日は、Gravitonへの移行に関して、あと2、3点お話ししたいことがあります。これは、お客様から最もよく寄せられる質問の1つです：ARMのソフトウェアエコシステムはどのような状況で、Gravitonへの移行にあたってのベストプラクティスは何でしょうか？
まず、ソフトウェアについてお話しします。オペレーティングシステムに関しては、LinuxコミュニティでARM64とGravitonに対する幅広いサポートが提供されています。これには、Amazon Linux、Red Hat Enterprise Linux、Ubuntu、SUSE Linux Enterprise Serverなど、人気のある商用Linux製品のほぼすべてが含まれています。また、ARM64上のLinuxに対するコミュニティの幅広いサポートも得られています。
Robinhoodと同様に、多くのお客様がGraviton上でコンテナ化されたワークロードを実行しており、これは非常に人気があります。 コンテナのサポートは、Docker自体や、Amazon ECSやEKSなどのマネージドサービスを含め、Graviton ARM64で特に充実しています。イメージレジストリに関しては、Amazon ECR、Docker Hubなどで、x86とARM64の両方に対するマルチアーキテクチャサポートが提供されており、ホストタイプに基づいて適切なイメージを簡単にデプロイできます。
Graviton Ready Partnersプログラムは過去数年間実施されており、 ソフトウェアプロバイダーがGraviton上でアプリケーションを検証し、簡単に見つけられるようにすることを目的としています。これらのプロバイダーは、ソフトウェアがGraviton上で使用できる状態にあることを確認するための品質保証テストを実施しており、お客様がソリューションをより早く見つけ、価格性能のメリットをより迅速に実現できるようにしています。これには、DevOps、CI/CD、ログ管理、モニタリング、データベースなど、複数のカテゴリーにわたるソフトウェアが含まれています。
Graviton EC2を単独で活用することも可能ですが、私たちは様々なAWSマネージドサービスにもそのメリットを拡張しています。これにより、お客様は大きな労力をかけることなくGravitonに移行してそのメリットを実現できます。通常、インスタンスタイプの簡単な変更だけで済み、アーキテクチャの互換性はマネージドサービスが処理します。今日では、これらのマネージドサービスの多くで、Gravitonがデフォルトオプションとなっています。これには、コンピューティング、データベース、分析、機械学習など、人気のあるAWSサービスが幅広く含まれています。
一般的なガイドラインとして、Gravitonへの移行時には、ソフトウェアスタックはより新しいものほど良いスタート地点となることをお客様にお勧めしています。インタープリター型言語やバイトコードにコンパイルされる言語は、通常そのまま実行できます。コンパイル済みのアプリケーションをお持ちの場合は、ARM64向けに再コンパイルが必要になりますが、現在主流のコンパイラはすべてこれをサポートしています。多くのお客様が、C++やGoなどのコンパイル言語をGraviton上で正常にデプロイされています。
リソースに関して、私が特にお勧めしているのは、GitHubで公開されているGraviton Technical Guideです。これには、プラットフォームのチューニングや様々なアプリケーション向けの特別な設定など、詳細なリソースと使用開始のためのガイドラインが記載されています。Graviton Fast Startプログラムでは、Graviton EC2や管理サービスを使い始める際のステップバイステップのガイダンスを提供しています。GitHub上のPorting Advisorツールは、ソースコードの依存関係をスキャンし、良い出発点となります。また、Aperfというツールもご用意しており、これは複数のパフォーマンス指標を同時に収集し、パフォーマンスのトラブルシューティングを迅速化するのに役立ちます。
セッションのまとめと今後の展望
セッションのまとめとして、Gravitonベースのインスタンスは幅広いワークロードで利用可能で、最高のコストパフォーマンスとエネルギー効率を実現し、GitHubリンクを通じて数多くの技術リソースにアクセスできます。お忙しい中、本セッションにご参加いただき、ありがとうございました。引き続き素晴らしいre:Inventをお楽しみください。可能でしたら、モバイルアプリでアンケートにご回答いただけますと幸いです。皆様のフィードバックを心よりお待ちしております。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion