re:Invent 2024: AWSのEC2コスト削減と性能向上の両立戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Win-win: Maximize Amazon EC2 savings while improving performance (CMP214)
この動画では、クラウドでの効率的なコンピューティングリソースの活用方法について、AWSの複数の専門家が解説しています。Elasticityとスケーリングの重要性、800種類以上あるEC2インスタンスタイプの選び方、x86と比べて20%のコスト削減が可能なGravitonプロセッサの特徴、そしてOn-demand、Savings Plans、Spotという3つの主要な購入オプションについて詳しく説明されています。また、1億1000万人以上の顧客を持つデジタルバンクNubankのSenior Director of EngineeringであるCat Swetelが、SpotインスタンスとGravitonを活用して顧客1人あたりの月間サービス提供コストを80セントに抑えた実践例を紹介しています。Black Fridayでの80万ドルのコスト削減など、具体的な成果も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
re:Inventセッション：効率性とパフォーマンスの戦略
みなさん、こんにちは。re:Inventへようこそ。これはパフォーマンスと効率性に関するセッションです。まず自己紹介させていただきます。私の名前はJuanです。サンパウロを拠点としており、Latin AmericaのPrincipal GTM Specialistを務めています。ブラジルのサンパウロを拠点としていますが、実は私はブラジル人ではなくコロンビア出身で、AWSに入社して約6年になります。
本日は素晴らしい同僚お二人をお迎えしています。NubankのSenior Director of EngineeringであるCat Swetelです。彼女はトランザクショナルインフラストラクチャーを担当しており、CI/CDパイプラインから、本番環境でサービスを運用するために必要なすべてのツールまでを管理しています。そしてもうお一人は、EC2 SpotのSenior Product ManagerであるDavid Bermeoです。彼はSpotビジネスを約5年間運営しており、今回が3回目のre:Inventとなります。ただし、ブレイクアウトセッションでの登壇は今回が初めてで、これまではワークショップを担当していました。
それでは、本日のアジェンダに入りましょう。まず、クラウドでより効率的になるための戦略とテクニックについてご説明します。これにはRightsizing、エラスティシティ、スケーリング、そして購入オプションなども含まれます。ここでSpot Instancesについて簡単なアンケートを取らせていただきます。Spot Instancesについて聞いたことがある方は？素晴らしいですね、ほぼ全員ですね。手を挙げた方の中で、すでにSpot Instancesを使用している方は？印象的ですね - 約50%で、これは通常の割合です。これが発表の第一部となります。Davidが購入オプションとSavings Plansについて説明し、最後にCatが効率化への道のりについてお話しします。
クラウドにおける効率化とElastic Compute Cloudの概念
「節約」とは何を意味するのでしょうか？節約には2つの側面があります。1つは、インスタンスごとのコストを最小限に抑えること。もう1つは、それらのリソースを最も効果的な方法で使用していることを確認することです。さらに、カーボンフットプリントという第三の側面もあります。効率化の変更を行い、コストを削減し、適切な購入方法を使用する際に、イノベーションの能力やカスタマーエクスペリエンスを損なわないようにすることが重要です。 この2つのバランスが本当に重要なのです。
そして、エラスティシティ、つまりElastic Compute Cloudの概念が出てきます。 これは、予測される需要が時間とともにどのように推移するかを示す関数です。キャパシティプランニングを行っている方々にはおなじみかもしれません。これは、顧客需要または予測需要の観点から期待されることを表しています。
オンプレミスの世界における過去や現在を見てみると、キャパシティ需要を満たすために必要な投資は階段状の関数のような形になっています。ある程度の期間に必要なキャパシティを想定して投資を行い、要件を満たすようにします。要件や需要が同じレベルに達すると、さらなる投資が必要となり、このような階段状の形になるわけです。しかし、実際の顧客需要は予測した需要の周りを上下する曲線のような形をしています。
使用率が低い場合、必要以上の支出を避けたいと考えるものです。しかし、すでにキャパシティへの投資を行っている場合、機会損失が発生します。つまり、使用していないリソースが存在し、それらのリソースの使用率が低くなってしまうのです。場合によっては、需要が予想以上に急速に増加した場合、その需要を満たすのに十分なリソースがないかもしれません。これも機会損失となります。
ここで、クラウドのElasticという概念が重要になってきます。 顧客の需要に応じてキャパシティやリソースを提供したいわけです。需要が増加したら新しいインスタンスを起動し、需要が減少したらそれらのインスタンスをシャットダウンします。このように需要に追従するのです。これがクラウドの約束する価値ですが、 適切なElasticityとスケーリングのアプローチを使用しない限り、必ずしもこのように機能するわけではありません。インスタンスが少なすぎる場合、コストの観点からは良いかもしれませんが、顧客は低いパフォーマンスを経験することになります。インスタンスが多すぎる場合は、優れたパフォーマンスと顧客体験が得られますが、必要以上の支払いが発生します。常に適切な数のインスタンスを維持する、つまり中間的な状態を目指す必要があり、そのためにはAuto Scalingが必要となります。
Auto Scalingとインスタンスタイプの進化
クラウドの約束は、購入ではなくサービスとして提供されることです。よく電気の例えが使われます。デバイスの電源を入れると消費が発生してコストが生じ、電源を切ると発生しない、というようにです。クラウドもそのように機能するべきですが、そのためには適切なAuto Scalingポリシーが必要です。適切な技術なしでは自動的には実現しません。私たちには複数のAuto Scalingサービスがあります。一方では、実際の需要に基づいてリソースをスケールさせるDynamic Scalingがあります。SimpleスケーリングやStepスケーリングがその例で、CPUの使用率やメモリなどのメトリクスを定義し、CPU使用率が60%などの特定のしきい値に達したときに、そのメトリクスに基づいて新しいインスタンスを起動します。
また、メトリクスに基づいてインスタンスを起動する代わりに、サーモスタットのように常に特定のしきい値を維持しようとするTarget Trackingもあります。例えば、CPU使用率60%を定義すると、そのレベルを維持するために自動的にインスタンスが起動または停止されます。60%を超えると新しいインスタンスが起動され、下回るとインスタンスがシャットダウンされます。Dynamic Scalingは、ワークロードの需要に応じて非常にうまく機能します。一方のアプローチを使用することも、もう一方を使用することもできますが、Black Fridayのようなイベントは予測可能なイベントです。また、スポーツイベントのようなストリーミングの状況では、特別な考慮が必要になる場合もあります。
数ヶ月前に開催された大規模なスポーツイベントは、この良い例でした。権利の制限があるため具体的な名称は控えますが。ストリーミングイベントは事前に計画を立てることができ、需要が実際に発生する前に新しいインスタンスで対応することができます。場合によっては、これが他のスケーリング方法よりも適している可能性があります。なぜなら、これらのイベントは非常に急激に発生するため、自動スケーリングを待っていては遅すぎる可能性があるからです。
このような場合、スケジュールされたスケーリングというオプションがあります。これは、インスタンスをスケールアップしたい日時を定義し、必要なインスタンス数を事前に予測できる方法です。同様に、過去の数週間や数ヶ月の間に見られたワークロードや需要の動向に基づいて、予測的なスケーリングを行うこともできます。これは、機械学習とアルゴリズムを使用してこれらのパターンを自動的に学習し、過去の動向に基づいて予測的にスケーリングする方法です。これら4つのAuto Scalingの方法を組み合わせることで、確実に需要に見合ったリソース量を確保することができます 。
これがエラスティシティであり、Auto Scalingが適切なアプローチとなります。手動でインスタンスをインストールしたり停止したりする必要はありません。ただし、使用するインスタンスの種類やタイプに注意を払う必要があります - ワークロードの要件に正確に合ったインスタンスを使用することが重要です 。各インスタンスで実際に必要以上のパフォーマンスは望ましくありませんし、逆に必要以下であってもいけません。
AWSサービスを10年以上使用している方はどれくらいいらっしゃいますか？15年くらい使用している方は？15-16年前、私たちはEC2をローンチしました。当時はただ1つのインスタンスタイプしかありませんでした - それはx86ベースのM1でした。アプリケーションの要件に関係なく、それを使うしかありませんでした。使うか使わないかの二択でした。しかし、それ以来、サポートするインスタンスの数は指数関数的に増加しています。最も長く使用している方々は、おそらくその数が800以上の異なるインスタンスタイプにまで増加したのを目にしてきたことでしょう 。
General Purposeインスタンス、CPU集約型、メモリ集約型、またはGPUを必要とするものなど、様々なカテゴリーに基づいてインスタンスを選択できます。これらのインスタンスには様々な機能を追加しています 。最小のNanoインスタンスから、インメモリデータベース用の多数のvCPUと大容量メモリを備えた大規模なインスタンスまで。異なるタイプのネットワークアダプターも用意しており、多くのオプションがあります。その目的は 適切な仕事に適切なインスタンスを提供することです。このようなイノベーションを実現できた理由の1つは、シリコンイノベーションです。つまり、私たちは独自のチップ、半導体、シリコンを製造する能力と可能性を持っているということです。インスタンス数を増やすこの能力を可能にしたプロジェクトの1つがNitroプラットフォームです。Nitroは本質的にハイパーバイザーであり、インスタンスを仮想化する方法です。これはハードウェアベースなので、AWSインスタンスを使用して、例えば4つのvCPUと32GBのRAMを取得した場合、仮想化に容量を使用する必要がないため、実際に4つのvCPUと32GBのRAMを取得できます。
Gravitonの特徴と利点
これはハードウェアによって実行されています。この内部で構築した能力から生まれた他のプロジェクトがいくつかあります。その一つがGravitonで、これについては後ほど詳しくお話ししますが、機械学習ワークロード用のInferentialやトレーニングなども含まれています。これらはAWSに特有のものです。その上にOn-Demand InstancesやSavings Plansなどの購入オプションがあります。ただし、特にSpotについての説明は、後ほどDavidに任せたいと思います。
少し話題を変えて、Gravitonについて詳しく見ていきましょう。ここで最後の質問になると思いますが：re:Inventの前にGravitonインスタンスについて聞いたことがある方はどれくらいいらっしゃいますか？ほとんどの方ですが、全員ではないようですね。では、手を挙げた方の中で、すでにGravitonを使用している方は？だいたい同じくらいですね。Gravitonは、Armマイクロアーキテクチャをベースにしたマイクロプロセッサです。ゲーマーの方々はよくご存じだと思います。クラウドには基本的に2つの選択肢があります：IntelかAMDのx86か、Armベースのマイクロプロセッサです。GravitonはArmベースで、Armを中心に設計されていますが、特定のクラウドの要件と仕様を満たすように設計されています。
私たちは、クラウドのワークロードとニーズに合うCPUを作る能力を手に入れました。このマイクロアーキテクチャをクラウドに導入した理由はいくつかありますが、最も重要なのは価格とパフォーマンスの両面です。Armマイクロアーキテクチャは80年代に作られましたが、実際に普及したのは2010年代です。今日のモバイルフォンのほとんどがArmアーキテクチャのマイクロプロセッサを使用しています - あなたのポケットにあるスマートフォンも99.9%の確率でArmマイクロプロセッサで動いています。モバイルデバイスにとって理にかなっているのは、x86と比べてエネルギー消費が非常に低いからです。モバイルの世界では、これはバッテリー寿命が長くなることを意味します。データセンターでは、運用コストが低くなることを意味します。
x86と比べて運用時のエネルギー消費が少ないため、維持・運用のコストが低くなります。まず覚えておいていただきたいのは、Gravitonの価格がx86より低いということです。その理由の一つが、エネルギー効率が良いことです。平均して、GravitonをX86と比較すると、同等のx86インスタンスと比べて価格が20%低くなります。もちろん、アーキテクチャが異なるため、ArmとX86では命令セットが異なります。しかし、だからといって、何十年もかけて構築されてきたArmの大規模なソフトウェアエコシステムが存在しないわけではありません。
ほとんどのLinuxディストリビューションはx86とArm両方で動作するので、Armアーキテクチャへのサポートは充実しています。そして、アプリケーション、オープンソースデータベース、さらには商用ソフトウェアのオプションもすでにArmをサポートしています。つまり、大規模なソフトウェアエコシステムが存在し、エネルギーの観点からも非常に効率的で、同等のx86と比べて30〜60%電力消費が少なくなります。Gravitonはしばらく前から存在しています。手を挙げなかった方々のために言いますと、これは新製品ではありません。すでに第4世代に入っています。2021年に第1世代を発表して以来、Gravitonのパフォーマンスは7倍に向上しています。
これは非常に成熟した製品であり、それは私たちが提供している様々なインスタンスとインスタンスタイプの数に表れています。冒頭でお話ししたように、EC2を最初にローンチした時は、たった1つのインスタンスしかありませんでした。現在では、様々なカテゴリーのインスタンス、異なるタイプ、そして多様なオプションを用意しています。これはx86だけでなくGravitonにも当てはまり、x86で利用可能なオプションのほとんどがGravitonでも利用できます。様々なファミリーオプションがありますが、覚えておくべき重要なポイントは、Gravitonインスタンスには「G」が付いているということです。
20%のコスト削減とGravitonの40%の価格性能比の優位性を活用する最も簡単な方法は、マネージドサービスを通じてです。例えば、LambdaをGraviton上で実行することができます。また、私たちのマネージドデータベースサービスのほとんどがGraviton上で動作しています。RDSでオープンソースデータベースやGravitonがサポートしているものを実行している場合、インスタンスタイプを切り替えるだけで、一晩で平均20%のコスト削減を実現できます。
これは見逃せない機会です。20%という数字は純粋な価格面での比較ですが、パフォーマンスを考慮すると、ほとんどの場合、Gravitonは40%の価格性能比の優位性があります。Gravitonで何が実行できるのでしょうか？基本的に、Linux上で動作するものはすべてGravitonとx86の両方で動作します。オープンソースでLinuxベースであれば、ほぼ間違いなくGravitonで動作します。データベースなどのオープンソースソフトウェアは良い例です。独自のコーディングを行っている場合で、Javaマイクロサービスや、PHPあるいはPythonのような他のインタープリター言語を使用している場合、GravitonとX86の両方用のインタープリターが存在するため、x86で実行中のものを簡単にGravitonに移行できます。ワークロードの観点では、お客様は通常、マイクロサービスやコンテナ、データベース、分析やビッグデータ、そしてWebやゲームサービスでGravitonを使用しています。
EC2の購入オプション：On-demand、Savings Plans、Spot
ここで話題を変えて、Davidにマイクを渡したいと思います。ありがとうございます。ここから聞こえますか？はい、ありがとうJuan。EC2および一般的な他のコンピュートソリューションで利用できる様々な購入オプションについてお話ししたいと思います。主要なコンピュート購入オプションには、On-demand、Savings Plans、Spotの3つがあります。On-demandはクラウドの基本的な構成要素です。On-demandでの節約を最大化するにはどうすればよいでしょうか？Juanが述べたように、使用していない時はオフにすることです。需要に応じてスケールアップし、必要がない時にスケールダウンできれば、それが節約を最大化する方法です。On-demandには契約の縛りがないため、最初に検討すべき購入オプションとなります。
2番目の購入オプションはSavings Plansで、On-demandコストから最大72%の割引が得られます。これは、1年または3年の期間で特定の時間当たりの支出を約束できる、安定した使用状況向けのオプションです。これが節約の仕組みです - 契約という形で妥協する代わりに、特定の割引を受けられます。そして3つ目がSpotで、これは予備容量です。予備容量を最大90%割引で提供していますが、予備であるため、EC2には依然としてそのインスタンスを取り戻す権利があるため、中断可能なワークロードにより適しています。このトークでは、特にSavings PlansとSpotについて詳しく説明していきます。
Savings Plansについてお話ししましょう。EC2 SpotのProduct Managerとして少し恥ずかしいのですが、EC2のコスト削減を最大化する最も簡単な方法は何かと聞かれたら、Savings Plansだと答えます。その理由は、まず節約効果が非常に高く、On-Demandと比べて最大72%の削減が可能だからです。また、ベースラインとなる支出を把握してそれに見合うSavings Plansを購入するだけでよく、EC2が自動的に割引を適用してくれるため、使い方も簡単です。さらに、非常に柔軟性が高いという特徴があります。特定のコンピュートタイプにコミットする必要はなく、支出額にコミットするだけで、Savings Plansのタイプに応じて、リージョン、アカウント、インスタンスタイプを跨いで自動的に適用されます。
Savings Plansには3つのタイプがあり、それぞれ異なる種類のコンピュートに適用されたり、異なる割引率が適用されたりします。最も人気があるのはCompute Savings Planで、最も柔軟性が高いためです。最大66%の割引が適用され、リージョン、ファミリーサイズ、オペレーティングシステム、そして最も重要なコンピュートサービスオプションを跨いで自動的に適用されます。コンピュートサービスオプションとは、Fargate、Lambda、そしてEC2の使用量に適用されるということです。Savings Plansの柔軟性の最も重要な点は、インフラストラクチャやデプロイメント戦略を変更しても、購入した割引が有効に機能し続けることです。
例えば、x86からGravitonに移行することを決めた場合でも、コミットメントは将来のGraviton使用分と以前のx86使用分の両方に適用されます。別のリージョンに拡張する場合でも、Compute Savings Plansは割引を追従させます。さらに、サーバーレスに移行しても、割引は自動的に適用され続けます。
もう1つのバリエーションであるEC2 Instance Savings Plansは、最大72%とより高い割引を提供しますが、特定のリージョンとインスタンスファミリーに限定されます。サイジングの見直しの際に、そのインスタンスファミリー内で大きいサイズや小さいサイズに変更する必要が出てきた場合でも、割引は自動的に適用されます。ただし、Savings Plansを確定する際には、コミットメントを行うことを理解しておくことが重要です。ベースライン支出を分析する際には、これらの割引を受けるために少なくとも1年間はその支出にコミットする必要があることを理解しておく必要があります。
では、Spotについて話しましょう。SpotのProduct Managerとして、EC2の節約を最大化する最良の方法はSpotだと言わなければなりません。最大90%オフで、コミットメントが不要なため、最良の選択肢なのです。まずはSpotに関する誤解を解いていきましょう。Spotは実際には購入オプションの1つです。Spotインスタンスを提供する特別なインフラストラクチャがあるわけではありません。800種類以上のインスタンスと同じインフラストラクチャ、同じハードウェアから提供されています。Spotのための特別なバックヤードがあるわけではないのです。On-Demandと同じパフォーマンスが得られることを確信していただけます。
Nubankの紹介とSpot戦略の実践
ただし、これは実際には余剰キャパシティであることに注意が必要です。 Spotインスタンスは、その特定のインスタンスにOn-demandの使用がない場合にのみ提供されます。2分前の通知でインスタンスが取り上げられるリスクが常に存在します。 中断は必ず発生するため、このSpotインスタンスモデルは、アプリケーションがフォールトトレラント、疎結合、またはステートレスである場合にのみ機能します。そして4つ目の非常に重要な特徴として、柔軟性があります。
柔軟性について詳しく見ていきましょう。 柔軟性には複数の側面があります。時間的な柔軟性やリージョンの柔軟性もありますが、最も重要なのはインスタンスタイプの柔軟性とAvailability Zoneの柔軟性です。例えばC5 16xlargeのような各インスタンスタイプと、us-east-1aのような各Availability Zoneについて、データセンターには一定数のインスタンスが存在します。その一部はOn-demandで使用され、一部はアイドル状態で、一部はSpotで実行されています。
単一のインスタンスタイプと単一のAvailability Zoneに自分を制限するのは得策ではありません。 使用可能なインスタンスタイプを多様化し、柔軟に対応することで、余剰キャパシティを見つける可能性を最大化できます。これはホテルの部屋を予約するのに似ています。フロントに電話して305号室だけを指定して問い合わせるようなことはしないでしょう。305号室が空いていない可能性が高い場合、306号室や405号室が利用可能かもしれないのに、なぜその特定の部屋だけにこだわるのでしょうか？Spotを使用する際に、特定のインスタンスタイプにこだわる具体的な理由はありません。
私たちは、この選択をとても簡単にしました。 800以上のインスタンスタイプがありますが、それらを全て覚えたり、一つずつ選んだりする必要はありません。Attribute-based instance selectionという機能があり、アプリケーションに必要なスペックを指定するだけでOKです。例えば、アプリケーションには44 vCPUのメモリ、最低8 vCPU、8GBのメモリが必要で、まだGravitonへの移行準備ができていないためx86インスタンスが必要、といった具合にパラメータを指定すれば、800以上あるインスタンスの中からユースケースに適合するものを私たちが判断します。
お客様がSpotを活用し始め、柔軟性の重要性を理解すると、 インスタンスタイプが多ければ多いほど良いという考え方を理解されるようになります。
お客様がこの道を進む際に最初に尋ねるのは、サービスを開始する場所を決定するための容量情報についてです。お客様から何度質問を受けても、私たちはデータセンターの容量を明かすことはありません。しかし、この問題に対する解決策はあります。お客様は、コストを最小限に抑えたいのか、中断を最小限に抑えたいのか、あるいはその両方なのか、という希望を私たちに伝えたいと考えています。私たちは、Allocation Strategiesを通じてそのような希望を表現する方法を提供しています。
Spot Instancesについては、お客様が望むことを正確に指定できます。最低価格オプションでは、中断に関係なく、その時点で利用可能な最も安価なインスタンスに配置されます。もう一つのオプションは、中断を最小限に抑えるために最も深いキャパシティプールを見つけ出します。推奨されるアプローチは、コストと中断の両方を同時に考慮し、最適な実行場所に配置することです。On-Demand Instancesについてもallocation strategiesを用意しています。On-Demandで柔軟性があり、使用可能なインスタンスのセットがある場合、最も低価格なものを使用するよう指定するか、最適なオプションの優先順位リストを提供することができます。
購入オプションに関する最後のメッセージは、単一のオプションにこだわる必要はなく、ワークロードに応じて組み合わせることができるということです。1年間24時間365日稼働することが分かっているデータベースの場合、中断されてデータが失われる可能性があるため、Spotには置かないでください。データベースのワークロードについては、適切なサイジングを行い、支出を把握した上で、Savings Planを購入して節約を最大化すべきです。ビデオストリーミングやゲームサービスなど、ユーザーの需要に応じたワークロードの場合、基準となる支出を予測する良い方法がないため、SpotかOn-Demandを使用すべきです。エンドユーザーに中断が発生しないようにしたい場合は、On-Demandを使用してください。
テストや短時間のゲームセッションでは、引き続きSpot Instancesを使用できます。実行時間が短く、ジョブを再試行できる場合や2分間の通知期間内で作業できるジョブベースのワークロードでは、Spotでスケーリングすべきです。これが節約を最大化する最も簡単な方法であり、Amazon EMR、Batch、Amazon EKSなど多くの統合があるため、実装について心配する必要はありません。
NubankにおけるGraviton採用と今後の展望
こんにちは、Catです。まず、今ここにいる多くのNubankの従業員の努力を代表してこの機会をいただけたことに感謝したいと思います。Nubankについて少し説明させていただきます。私たちはデジタルバンクです。つまり、アプリが動いていないとお客様はサービスにアクセスできません - 支店に行くこともできません。なぜなら支店がないからです。この話を通して覚えておいていただきたいのは、効率性を得るために信頼性と安定性を犠牲にしているわけではないということです。 Nubankは1億1000万人以上の顧客を持つラテンアメリカ第4位の金融機関です。ブラジルの成人の約60%がNubankの顧客です。 2013年にブラジルのサンパウロで本社を設立してスタートし、その後メキシコに展開しました。
2020年にはさらにColombiaへと事業を拡大しました。これらの数字は実は少し古いものです。というのも、私たちは先日決算発表を行い、現在では3つの市場で1億1,000万人以上の顧客を抱えていることを正式に発表できるからです。また、私たちのコストパフォーマンスの高さについても強調しておきたいと思います。アクティブな顧客1人あたりの月間サービス提供コストを1ドル以下に抑えてきた実績は、もう何四半期も続いています。スライドでは90セントと表示されていますが、直近の決算発表では、前四半期のコストが1アクティブユーザーあたり80セントだったことを発表しました。このように、効率性は私たちの運営における重要な要素なのです。
この効率化の取り組みの一環として、私たちはDC2からスタートし、その後Kubernetesへと移行しました。2020年には、Spotの実験を開始しました。当時、市場で大きなスケールアップが予想される出来事がいくつか起きていました。例えば、Brazilでは即時決済システムが導入され、私たちの予想通り、大きな成功を収めました。2021年にはIPOを果たしました。これにより、コストと効率性への注目がさらに高まりました。また、Amazon EKSへの移行も行いました。2022年にはGravitonの採用を開始しました。
そして今、2024年を迎え、私たちは50の巨大なクラスターを運用しています。非常に大規模な事業となりました。この過程で、私たちは必要に迫られて、プラットフォームの運用コストを低く抑えながら、非常に高いスケーラビリティを実現してきました。よく聞かれる質問があります。「トランザクション処理のワークロードをSpotで実行するのは、簡単そうに見えますが...」。確かに、私たちのアーキテクチャには、Spotに適した独自の特徴がいくつかあります。まず、Nubankで公式にサポートされているプログラミング言語は、Closure JVMとPythonの2つだけです。非常に均質な環境なのです。
Amazon EKS上で2,000以上のユニークなマイクロサービスが稼働しており、バックエンドサービスの1日あたりのデプロイメント数は約200回にも及びます。デプロイメントは一種の中断を伴うため、私たちのサービスはそれに対して高い耐性を持っています。また、特殊なインスタンスタイプへの依存度も低いです。これまでの講演者の方々も触れていたように、多様化が重要なポイントです。このグラフからわかるように、私たちは多くの異なるインスタンスタイプを活用しています。Nubankには素晴らしいものがあります。それは私たちのエンジニアリング原則で、その1つが「一貫して適用される標準的なアプローチ」です。これにより、プラットフォームの効率性を改善したい場合、すべてのサービスが標準的なアプローチを使用しているため、簡単に展開できます。これによって、実験やプラットフォームの変更の展開が容易になります。これらの要素が組み合わさって、私たちはSpot市場に適した環境を実現しています。
Spotに適している理由をお話ししましたが、次は、私がSpotの旅を始める前に誰かに教えてほしかったことをお話しします。まず知っておくべきなのは、サービスやアプリケーションの起動時間です。単なる起動時間だけでなく、サービスが本格的に稼働し始めるまでの全体的なリードタイムを把握する必要があります。なぜなら、Spot市場では2分前に回収警告が来るからです。起動時間が長すぎると、Spot市場での運用は困難になってしまいます。
2つ目のポイントは、サービスの中断率、つまりインスタンスが回収される頻度を監視することです。このデータを集計する際は十分な注意が必要です。多くのサービス全体での総中断率は非常に低く見えるかもしれませんが、異なる視点で見ると、特定のサービスやフローで中断率が著しく高くなっている可能性があります。そのため、中断率を個別に分析できるようにする必要があります。
総中断率の管理も重要です。私たちの経験では、Spotの回収であれ、統合やBin Packingイベントであれ、サービスの観点からすれば違いはありません - 単に新しい場所に移動する必要があるだけです。そのため、サービスの総中断率に注目してください。また、Spotを使用する際の魅力的な割引率がどの程度なのかを事前に把握しておくことを強くお勧めします。ある程度の不安定性に対するコストを支払うことになるので、その場になって判断するのは避けましょう。
Spot戦略の総保有コストを理解することが大切です。Spotはマーケットでの計算リソース購入時に一定のコストがかかりますが、サービスの起動に必要なリードタイムのコストや、不安定性に伴うコストも考慮に入れる必要があります。最後のポイントは分散化です。前のスライドでも触れましたが、Spotマーケットで許可するインスタンスタイプをどの程度分散させる必要があるのか、約6ヶ月ごとに確認が必要だと感じています。
Nubankのスポット戦略のビジネス成果について、On-Demandの予約を一切行わなかった最初の年である2021年に遡ってお話しします。私たちはリスクを取る決断をし、それは正解でした。Black Fridayの1日で80万ドルの支出を回避でき、キャパシティに関連するインシデントも発生しませんでした。そして、すべてSpotで運用したBlack Friday 2年目について、このチャートをお見せしているのは、Black Fridayを特定するのが難しいほどだからです。1つのバーが他より高くなっていますが、異なる購入方法間のばらつきは、Black Fridayでもそれほど大きくありません。これは成功の証だと考えています。
今年も、ほとんど予約なしで同様の戦略を実行し、すべて順調でした。私は一度もページングを受けることがなく、素晴らしい1日でした。Spotは私たちの購入戦略の一部です。私たちはかなり分散化されています - Spot、Savings Plans、On-Demandなど、様々な方法で購入しています。 これは私たちに素晴らしい結果をもたらしています。SpotとGravitonを採用するにつれて、平均vCPUコストが明確に低下しています。さて、Gravitonの部分について、 HoneycombでのGraviton採用についてLiz Fong-Jonesが書いたブログを読んだ方はいますか？これは素晴らしいブログで、ぜひ読むことをお勧めします。このブログはNubank Engineeringでも大きな話題となりました。そこで、私たちはGravitonについてのバズを耳にし始め
私たちは2021年にそれを実験し始めることを決めました。 そして2022年には、既存のカノニカルなアプローチを適応させ始めました。x86版とGraviton版があり、ベースサービスイメージ、CI/CDパイプライン、そしてそれらすべてにおいて、各サービスオーナーにGravitonを試す機会を提供しました。 2023年には、Gravitonが分析ワークロードに非常に適していることを発見しました。
現在の状況はどうでしょうか？私たちは相当量のGravitonを運用しており、非常に良好なコストパフォーマンスを実現しています。そして、Juanが先ほど述べたように、より効率的なアーキテクチャであるため、カーボンフットプリントを削減できるという付加的なメリットもあります。 もちろん、課題もあります。私たちはSao Paulo AWSリージョンで多くのワークロードを実行しており、世界中の他のリージョンでも様々なワークロードを実行しています。Gravitonは素晴らしいのですが、すべてのリージョンに同時に魔法のように登場するわけではなく、リージョンごとに展開されていくため、それを考慮する必要があります。Nubankでは「radical ownership」という考え方があり、作ったものは自分で運用するという方針です。つまり、プラットフォームを担当する私たちの世界では、Gravitonへの移行を選択するサービスを所有するチームに依存しています。時には少し優しく背中を押すことも必要です。
Gravitonの導入を始める前に誰かに教えてほしかったことは何でしょうか？まず第一に、カノニカルなアプローチがこの移行をずっと容易にするということです。もし多くの個別のサービスチームがベースサービスイメージを適応させ、テストを実施し、展開方法を考え出すことに依存するなら、作業は困難になるかもしれません。私たちの場合、サービスの開発と運用に関するカノニカルなアプローチがあったため、はるかに容易でした。もちろん、テストは必要です。すべてのサービス、すべてのワークロードがGravitonで同じパフォーマンスを発揮するわけではありません。そのため、様々なタイプのワークロードでテストする必要があります。
キャパシティの可用性は非常に重要です。これは、運用しているリージョンで利用可能かということと、Spotインスタンスと組み合わせる場合、そのリージョンに余剰キャパシティがあるかということを意味します。私たちはESGの時代にいて、良き地球市民でありたいと考えています。そのため、Gravitonを検討する際には、「価値があるか？」という問いの中に、より効率的でカーボンフットプリントを削減できるというGravitonのグリーンな利点について考慮する必要があります。事前に、どの程度のパフォーマンスがGravitonへの移行投資を正当化するのかを考えておくことをお勧めします。その数値は組織によって異なるでしょう。
Nubankの次のステップは何でしょうか？来年ここに来たときに何を話すことになるでしょうか？2013年にブラジルで始めた時、私たちは1つの国で1つの製品 - クレジットカードだけでした。現在は3カ国に展開し、銀行口座、貸付、保険など、多くの製品を提供しています。新しい分野に拡大しており、現在では携帯電話サービスも提供しています。私は、さらに多様化を進め、コンピューティングリソースの購入についてより細かな戦略を持つ必要があると考えています。そのため、来年ここに来たときには、私たちが事業を展開している場所や分野の様々な組み合わせに応じて開発された、さらに細かな戦略について話すことになるでしょう。
本日は皆様にご参加いただき、誠にありがとうございます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion