re:Invent 2024: AWSが語る効率的なアーキテクチャ設計とコスト削減戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Think big, build small: When to scale and when to simplify (ARC331)
この動画では、AWSのアーキテクチャ設計における効率化とコスト削減について、実践的な知見が共有されています。パンデミック以降のコスト上昇を背景に、システムの適切な規模と複雑さを実現するための考え方を解説し、RustとGoの選択やMonolithicとMicro-servicesの使い分けなど、具体的な意思決定の例を挙げています。また、High Availabilityパターンでは、5つのAvailability Zoneの活用で25%のオーバーヘッドまで削減できることや、Best Effortパターンでは機械学習トレーニングのような冗長性を抑えたアプローチが有効であることなど、実践的なコスト最適化の手法が紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
アーキテクチャ設計におけるリーダーシップスキルとコスト削減の重要性
おはようございます。アーキテクチャに関するセッションへようこそ。今回のセッションは少し異なるアプローチを取ります。皆さんが利用されているAWSの全サービスを構築する開発チームとの仕事や、クラウド移行やクラウド移行後の再アーキテクチャなど、お客様のアーキテクチャプロジェクトを通じて学んだリーダーシップスキルとメンタルモデルに焦点を当てていきます。システムにおける適切な規模と複雑さのレベルを実現するための考え方について、社内チームやお客様との協業を通じて得た知見をお話しします。
この数年間、AWSの社内でもお客様との間でも、コスト削減とフットプリントの縮小により重点を置くようになってきています。パンデミック以降、エネルギー、土地、給与など、基本的なコストが上昇しています。これらは私たちとお客様にとって主要なコスト要因であり、すでに非常にリーンな運営を行い、大規模な経済効果を実現していた私たちのような企業でさえ、さらなる効率化と小規模化に向けて取り組みを倍増させています。
この効率化への注力は、私個人のプロジェクトにも及んでいます。これは非営利団体と行っている個人的なサイドプロジェクトのAWS Consoleのコストと請求の内訳です。このサイドプロジェクトは専用のAWSアカウントで管理していますが、一般のユーザーと同じように登録しただけです。AWSで16年働いていますが、特別な割引はありません - 非営利団体の一部として、通常通りクレジットカードで支払っています。re:Inventに向けて、発表予定の機能の中にコスト削減に役立つものがあることに気づき、早期アクセスのために製品マネージャーに連絡を取りました。約44週間前にそれらの機能を採用することで、新しいネットワーク機能によってLoad Balancerを削除するなど、コアインフラを置き換え、すぐに節約を実現することができました。
システムの複雑さと効率性：シンプルさを追求するアプローチ
システムを最初に構築する時は、通常とてもシンプルで、よく理解された少数の主要コンポーネントだけで構成され、それらのコンポーネントを構築した人々全員がまだチームに残っています。頭の中で全体を把握でき、新しく加わった人でも1週間程度で onboardingを完了し、システム全体を完全に理解できます。このような段階のシステムは、本質的な複雑さが少ないため、信頼性が高く、セキュリティの確保も比較的容易です。
しかし、システムが時間とともに有機的に進化し、横断的な機能なども追加されていくと、最終的にはスパゲッティのような状態になり、頭の中で把握できなくなってしまいます。そうなると、システムの安全性を確認するためにテストやシミュレーションにより多くの投資が必要になり、コストがかかり、開発速度も遅くなる可能性があります。機能の改善に遅延が生じ始め、他の問題も発生し始めます。これらは私たちが戦わなければならないネガティブな傾向です。
私たちは物事をよりシンプルにし、小規模なシステムを設計したいと考えています。私の考えでは、最適化され、効率的で、可能な限り小規模なシステムを構築するには、2つの相補的なスキルセットが必要です。
これを実現するには、システムの詳細を実際に理解しているSystem DesignerとDeveloperが必要です。これは避けて通れません。スタックを上から下まで見通し、どんな巧妙な手法があるのか、何をすれば高速化や小規模化が可能になるのかを把握できる能力が必要なのです。また、Monolithicなサービスをより多く構築すべきか、それともMicro-servicesをより多く構築すべきかといった、システムレベルの設計に関する問題についても常に検討しており、これについても後ほど触れます。
また、組織としてのアプローチも必要です。私が見てきた成功している顧客やチームは、シンプルさをどのように促進し、評価し、インセンティブを与えるかというレンズを通して、アーキテクチャへのアプローチを常に分析する文化を持っています。それをどのように確実に実現し、成果をどのように測定するかを考えます。System DesignerやArchitectが直感だけでなく、実世界からの実データに基づいて判断できるようにし、 すべてのインセンティブが整合していることを確認します。私たちにはこの両方が必要なのです。これらについて、順を追ってお話ししていきます。
反復的なアーキテクチャ設計プロセスとプロトタイピングの重要性
まず始めに、私がアーキテクチャ全般をどのように考え、システムにどのようにアプローチしているかという全体的なメンタルモデルについてお話ししたいと思います。それは非常にIterativeなアプローチです。 以前は、ArchitectやSystem Designer、あるいはチームとして、最初に設計をしなければならない一時的なプロセスとして考えていました。ホワイトボードでブレインストーミングをしたり、時には個人で検討して過去のパターンを研究したり、カンファレンスに参加してトークを聞いたり、他の人々がどのように実践してきたかを学んだりしました。そうして得た情報をすべて活用して最善の設計を行い、同僚と協力してレビューを行う、それがアーキテクチャであり、その後実装に移るというものでした。
このプロセスは今でも可能ですし、実際に行われています。それはプロセスの一部です。しかし現在の私にとって、より重要なのは、このプロセスの周りに、私たちに反復を強制し、導いてくれる別のレイヤーがあることです。今日のWernerのKeynoteを見た方、あるいは会場にいらっしゃった方は、彼がいくつかのシステム間の本質的なシンプルさと複雑さの違いを強調していたのをご覧になったかもしれません。 彼は私の好きな例の一つである、一輪車、自転車、三輪車のシステムにおける本質的な複雑さの違いを使用しました。
もし一からやり直すとしたら、つまり200年前のベロシペードや最初の自転車が登場する前の時代にタイムスリップして、人力で人々をAからBへ移動させる機械システムを設計・構築する任務を与えられたとしたら、様々なアプローチが考えられます。今でも人々はこういったテクニックを試そうとしています。例えば、システムを実際に作る前に、設計を評価するための形式的なアプローチや分析的な方法はないかと考えます。一般的なアプローチの一つは、動く部品の数を数えることです。その観点から見ると、一輪車が最もシンプルな答えとなります。動く部品が最も少ないからです。しかし、これが正解ではないことは分かっています。一輪車は実用的ではありません。
同様に、本質的に最も安定したシステムはどれかと分析すると、三輪車が最も安定していると素早く結論付けるかもしれません。地面に置いても倒れることはありません。これはこれらの乗り物の中で唯一の特徴です。しかし、三輪車でスピードを出してコーナリングを試みると転倒してしまいます。私の幼い子供が家で小さな三輪車に乗って頻繁に経験していることです。四輪を追加して車のように安定した四輪自転車を作ることもできますが、それではコストと重量がさらに増えてしまい、誰もそうしない理由は多々あります。実際、私は現実世界で四輪自転車を見たことがありません。本当に存在するのかどうかも分かりません。
時間の経過とともに、妥協案として自転車という解決策が生まれました。持ち運びできるほど軽量で、比較的安価で、確かに一輪車より動く部品は多いものの、それだけの価値があります。
自転車の学習曲線は一輪車よりもずっと簡単です。私は一輪車に乗れる自信がありません。私はそれほど器用でバランス感覚もよくないのですが、子供でも自転車に乗るのを覚えるのに1日程度で済みます。これはすごいことですし、AからBへの移動も本当に効率的です。しかし、これらのことを事前に予測することはできなかったでしょう。これらすべては、自転車を作り、人々に与え、使用する様子を観察し、フィードバックを得て、何が機能するかを見て、そしてそれぞれのコンポーネントに同じことを適用するという繰り返しを通じて学んできたことです。最適なブラケットは何か？最適なチェーンは何か？これらすべては繰り返しの結果なのです。
このプロセスから私が得た最大の教訓は、アーキテクチャに関する私たちの最初の推測や考えは、ほぼ間違っている可能性が高いということです。もし本当に経験豊富で、作ろうとしているものと同様のものを1回、2回、あるいはそれ以上構築した経験のあるシステム設計者がいない場合、設計しようとするものは恐らく正しい形ではないでしょう。この謙虚さを念頭に置いて、成功とは何かを前もって設計し、決定することが重要になります。私たちは何をしようとしているのか？この新しいアーキテクチャは何を達成すべきなのか？これらをできる限り数値で示す必要があります。技術システムの場合、多くの場合、1秒あたりのリクエスト数、レイテンシー、データ保存量などを具体的に示すことができます。これらすべてに数値を設定することは、成功の定義を前もって持ち、それを常に測定する上で本当に役立ちます。
私はチームと一緒に仕事をする時、Design Reviewに参加するのが大好きです。時にはお客様と一緒に大規模なセッションを行うこともあり、1日や2日かけてホワイトボードを使いながら、何を作るべきかを考えていきます。これは本当に素晴らしい経験で、私はこのプロセスを心から楽しんでいます。なぜなら、そこでは全員の経験が集結し、最初のアプローチとして最善の方法を見出せる可能性が高まるからです。ただし、もし私がその週に休暇を取っていてミーティングに参加できなくても、あまり心配はしません。チームが完璧な判断を下せなかったかもしれないと感じても、それほど気にしません。
その理由は、できるだけ早い段階で小規模なPrototypeを作ることに合意できるプロセスを確立することの方が、私にとって重要だからです。私の考え方としては、あまり多くの労力を無駄にすることなく破棄できるようなPrototypeを作りたいのです。最初のアーキテクチャを設計する段階で、そのプロセスに関わり、Prototypeをテストしてパフォーマンスデータを収集できるようにしたいと考えています。そのようなプロセスが確立され、チームやお客様がそれを実践していれば、最終的に正しい方向に進めると確信できます。最初の判断が少々ずれていても、あるいは大きくずれていても問題ありません。データが教えてくれますし、最終的には軌道修正して目標に到達できます。これは本当に意味のある安全網だと感じています。
コスト意識とOpen Book Financeの実践：開発者の視点から
このようなプロセスを確立するには確かに努力が必要です。ほとんどの開発チームは自然とこのようなことをしません。多くの人々にとって、これは当たり前のことではありません。大抵の人は最初に思いついたことをそのまま実行するか、事前に設計して最善を期待するだけです。しかし、このようなプロセスを導入すること自体はそれほど困難ではありません。人々はすぐにその価値を理解し、参加することを楽しむようになります。ただし、あまり一般的ではないのが、このモデルにコストを組み込むことです。つまり、誰かが設計や新しいアーキテクチャを作り始める初日から、実際にかかるコストについて考えることを主要な指標の一つとして定義することです。驚くべきことに、多くのチームやお客様が、できるだけ早い段階でこの質問をすることがありません。代わりに、財務チームの誰かがコストを尋ねる非常に遅い段階になって初めて、それが分からないという状況に陥ります。
私たちは、できるだけ早い段階でコストを組み込むことを学びました。実際のところ、私たちの開発者もお客様の開発者も、2つのボックスや2つのシステムを設計する時点で既にお金を使っているのです。それらには支払いが必要で、これは一種の支出です。そのため、チームの少なくとも誰かがこれを意識し、コストを把握していることが重要です。極めて正確な把握である必要はありません。1セントまで正確である必要もありません。
多くの場合、桁のオーダーでの見積もりで十分です。多くの場合、ビジネスを破産させるのか、それとも効率的で利益を生む源となり得るのかを判断できる程度の正確さがあれば十分です。しかし、これをできるだけ早い段階で実施することが本当に役立ちます。
私は Open Book Finance システムと、チームがコストを理解できる方法を強く信じています。しかし、チームに総コストの概要を提示するなど、逆効果になるアプローチを見てきました。予算設定も逆効果になることがあります。チームに対して、来年度はこの予算内に収めることが仕事だと伝えても、そのチームが構築しているものが利益を生み出すものである場合、それは意味をなしません。もし利益を生み出していて、顧客に非常に人気が出て予算の上限に近づいているのであれば、むしろそのプロジェクトの予算は増やすべきでしょう。
利益が出ている限り、予算を設定することは意味がありません。しかし、顧客がそのようなアプローチを取り、予算の上限に近づくとコスト削減モードに入って、チーム全体が気を取られてしまうケースを見てきました。1月に合意した数字だからといって、ビジネスの上位レベルで考えれば、それは非合理的です - そのサービスは利益を生み出し、コストを賄えているのですから。成長モードにある場合は、より多くの成長を目指すべきで、それは機能追加によって実現される可能性があります。そのような視点を持ち、開発者にそのように考えるよう促すことが重要です。
私にとって理想的なのは、チームの開発者が、クラウド側での各顧客リクエストや各ビジネスアクションに対する、システムに起因する概算コストを把握できることです。先ほど見たように、私の単純な例でも、インフラストラクチャのクラウドレベルのコストを把握するのは非常に簡単です。これはコンソールから得られる最も基本的なビューです。Cost Explorerを使用すれば、より詳細なビューを取得し、タグ付けを行い、より細かい視点を得ることができます。コスト管理ツールに関しては、大規模なパートナーネットワークも持っています。しかし私の見解では、顧客はこのアプローチを採用し、システム設計者や実際の開発者にまでフィードバックを返し、この視点を提供することで、より大きな恩恵を得られます。
これは比較的測定が容易なインフラストラクチャコストです。結局のところ、そのインフラストラクチャの請求書を受け取り、それをどのように配分すべきかを考えることになりますが、多くの場合、これが最も重要なコストというわけではありません。むしろ、これが最も重要なコストであることは稀です。通常、ITの取り組みにおいて最も重要なコストは、開発者のコストです。これは部分的には、私たち開発者に支払われる給与や、オフィスビルを維持するためのコスト、従業員に関連する全てのものを含みます。しかし、実際にはそのコストですら最も重要なものではありません - より重要なのは機会費用なのです。
通常、無限の数の開発者を雇用することはできず、組織は採用に慎重にならざるを得ず、文化との適合性を確認する必要があります。また、チームを急速に、あるいは大幅に拡大することもできません。Fred Brooksは有名な言葉を残しています。チームの規模を2倍にすると、しばらくの間は少なくとも生産性が半分になる、なぜなら新しい人々の訓練と習熟に時間がかかるからだと。そのため、多くの場合、本当に制約の大きいコストは開発者が何をしているかということです。なぜなら、彼らがそれをしている間は他のことができないからです。もし他にもっとお金を節約できたり、より多くの利益を生み出せることがあるなら、彼らはそちらに取り組むべきでしょう。
適切なタイミングで適切な作業を行うことを確実にする厳密な優先順位付けのプロセスは、非常に重要です。年次計画のプロセスを行い、サービスのエンジニアリング計画や構築内容を確認する際、私が繰り返し投げかける最も一般的な質問は、「本当に今すぐそれを行う必要があるのか」「それはコスト削減なのか、あるいは一時的に先送りできる最適化なのか」というものです。一時的に効率が少し落ちるかもしれませんが、成長モードにある場合は、特にその判断が価値があるかもしれません。
多くの場合、答えは明確で、このようなコストとベネフィットのトレードオフ分析を、一見関係なさそうな例も含めて、できるだけ多くのアーキテクチャ上の決定に適用しています。
プログラミング言語選択とアーキテクチャパターン：人的要因の重要性
一例として、ほぼすべての開発チームが直面する、プログラミング言語の選択があります。私は7、8年前にAWSでRustプログラミング言語に深く投資する決定に関わる機会がありました。当時、私たちは多くの低レベルおよび高性能システムをCで直接実行していました。Cは性能面では優れていますが、安全性とセキュリティに課題がありました。その補完のために、私たちは相当なツール群を構築し投資してきました。メモリの安全性や並行処理のバグがないことを確認するために、常時フォーマル検証プログラムを実行していました。しかし、それらは高コストで、開発プロセスを遅くし、学習と習熟の曲線も変えてしまいます。エンジニアを新たに迎える際、Cを知っているだけでは不十分で、それらのツールの使い方もすべて学ばなければならず、私たちはそれを改善したいと考えていました。
そこで、より良い低レベルシステム言語がないか探してみました。当時、私たちはRustとGoという2つの主要な候補を評価していました。どちらも素晴らしい言語です。私は両方の言語でコーディングをしており、どちらも大好きです。しかし当時、私たちはどちらのプログラミング言語も大規模には使用していませんでした。システムプログラミング言語を変更するかどうかを決める必要がありました。作業を2つに分散させるよりも1つに集中した方がより良い結果が得られるため、実質的に1つしか選べませんでした。
開発チームとして、通常問うべき質問は次のようなものです：私たちが既に知っていることは何か？新しいチームメンバーが既に知っている言語は何か？採用市場はどうなっているか？これらのプログラミング言語の学習曲線はどうか？そして、私たちの分野にとってそのプログラミング言語はどれだけ適しているか？これらの質問を見ると、そのほとんどが人的要因、つまりシステムの本質的な部分ではなく、人に関することです。
RustとGoには、それぞれ異なる長所と短所があります。Goの方がRustよりも学習曲線が緩やかで、開発者はGoを短期間で習得できます。これは非常に価値のある特徴です。一方、Rustの習得にはより時間がかかります。RustとGoはどちらも、優れたメモリ安全性と並行処理の安全性が組み込まれています。しかし、技術的な観点から見たRustの利点の1つは、低レベルの高性能システムにおいてガベージコレクションが不要な点でした。予期せぬ一時停止を心配する必要がありませんでした。その間にGoも進化し、そのガベージコレクションは素晴らしく、非常に高速で安定していますが、ガベージコレクションのタイミングを予測するのは難しいという特徴があります。
この選択を決定づけたのは、開発者の確保とその機会コスト、そして誰を採用できるかという点でした。当時、Googleをはじめとする複数の大手企業がすでにGoに多大な投資をしていました。私たちは、Goは素晴らしい言語だと考えていましたが、Rustを選択すれば、本物のRustエキスパート、つまり大手企業が初めてRustに投資するという冒険に参加したいと考える人材を引きつけられる可能性が高いと考えました。結局のところ、これは人的要因に大きく影響された決定でした。
もう1つ言及すべき例があります。私が関わっているお客様は、常にこのような決定を行っています。例えば、機械学習やAIの分野では、Pythonがその世界で非常に豊かな言語であるため、Pythonを選択することが非常に一般的です。これには唯一の正解はなく、同じ手法を適用しても同じ結果が得られるとは限りません。組織のコンテキスト全体に大きく依存するのです。
私たちが常に直面するもう1つの問題は、モノリシックサービスを構築すべきか、それともマイクロサービスを構築すべきかという点です。AWSの内部でも、私たちはこの問題に直面しています。マイクロサービスが私たちのデフォルトのアプローチですが、モノリスを構築しなければならない特別なケースかどうかを主に検討しています。それでも、この質問は頻繁に出てきます。
私たちのアプローチは、まずパフォーマンスの要件が非常に厳しく、密結合なコードが必要かどうかを確認することです。例えば、コードがナノ秒単位またはそれ以下で動作する、非常に低レベルのネットワークや暗号化データプレーンなどが該当します。このようなコンテキストではサービス間のマイクロサービス呼び出しは行えないため、問題のパラメータによって選択が強制されます。また、開発者同士がブロックし合うコストはどの程度か、選択したフレームワークでそれを時間とともにどのように測定できるかという点も検討します。質問の大半は実際には人的要因に関するものです。私たちは生産性とその方向性について考えているのです。
私がMicroservicesのパワーについて考える際のメンタルフレームワーク、そして採用を検討しているお客様への説明方法は、空母のシステムに例えています。私は軍隊での経験はありませんが、音楽演奏のゲストとして2隻の空母に乗船したことがあります。空母での作業の専門性と運用規模には非常に感銘を受けました。海上最大規模の軍艦でありながら、最速クラスの船舶でもあるという驚くべき存在です。単なる移動式空港というだけでなく、格納庫を備えた移動式航空機整備施設でもあります。また、数千人が生活する移動都市でもあり、郵便サービスから食事サービスまで、あらゆる機能を備えています。さらには、一般的に非常に複雑なシステムとされる原子力発電所も複数備えた移動式発電所でもあるのです。
これらすべてがうまく機能しているのは、すべてが分割されているからです。原子力発電所のチームは、航空機を整備するチームに影響されたり、過度に気にしたりする必要がありません。それぞれが独立した関心事となり、全員が並行して作業できます。空母の指揮官や上級将校は、ほぼすべてのシステムについてある程度の理解を持っていますが、誰一人としてすべての全体像を把握できる人はいません。すべてのシステムの詳細を完全に理解している人は誰もいないのです。このレベルでスムーズに並行作業を行うことが目標であれば、これが私たちが推奨するアプローチとなります。これもまた、人的要因の観点からのアプローチです。
このような人的要因の重視からお分かりの通り、このアーキテクチャへのアプローチは、実はリーダーシップスキルに関するものなのです。これらのスキルは、現在のシニアリーダーだけでなく、夏季インターンの学生に至るまで、全員に必要なものです。適切な質問をし、人を中心にこれらすべてがどのように組織化されているかを考えることは、想像以上に大きな違いを生み出します。リーダーとして、チームメンバーが特定の選択に向かう原動力は何か、そしてビジネス価値をその中心にどう据えるかを考える必要があります。
ここでの典型的な例は、イノベーションが非常に大きな報酬をもたらす可能性がある場合です。新しいものをゼロから構築すると、素晴らしい気分になりますし、とても印象的で、自然と報酬や昇進、インセンティブにつながりやすいものです。私自身、大規模なシステムを構築し、最終的にそれが機能してお客様に価値を届けることで、何度か昇進を経験してきました。しかし、ほとんどのビジネスや組織が必要としているのはそれではありません。多くの場合、既存システムの改善が必要なのです。そのため、健全な組織では、既存システムの改善も同様に重要であることを強調します。
最も典型的なケースは、チームや個人が「アーキテクチャの再構築が必要だ。その時期が来た。古いアーキテクチャは寿命を迎えつつある。新しいものに移行する必要がある」と言い出す場合です。しかし、私たちAWSではそのようなことはしません。私は現在、AWSで2番目にローンチしたサービスであるAmazon Elastic Load Balancingで働いていますが、コアアーキテクチャのほとんどは当時のままです。サービス開始日に稼働していたコードの多くが今でも使われており、完全な再アーキテクチャの誘惑にはあまり直面しません。
なぜなら私たちは、「なぜアーキテクチャの再設計が必要なのか？」「その理由は何か？」「どのような崖に向かって進んでいるのか？」「その崖までどのくらいの距離があるのか？」といった質問をするからです。できるだけ早くデータでその答えを得たいのです。「現在のシステムはXを超えてスケールしない - 今どこにいるのか？ Xにどれだけ近づいているのか？」。アーキテクチャ上の課題に加えて、運用上の危機に直面している可能性もあります。そういったことを本当に知りたいですし、次に導入するものからどれだけ早く改善を測定できるのかということも知りたいです。どのように測定するのか？その数値はどのようになるのか？スケールやパフォーマンスのスループットのために今すぐ実行すべきことなのかを判断するために、金銭的価値を見積もる方法はないのでしょうか？
これらは比較的簡単に数値化できますが、生産性のような要素は、はるかに難しい場合があります。四半期に1つの機能しかリリースできず、アーキテクチャによってボトルネックが発生している状況に達した時、何年も前に行った選択が問題となっています。しかし、これから構築するものについては、四半期に2つの機能を実装できるようになるなど、具体的な目標を事前に設定し、それを測定する方法を見つけ、できるだけ早い段階でその実現可能性を確認する必要があります。
このようなリーダーシップスキルのアプローチは、顧客とのミーティングで最も頻繁に用いることです。多くの場合、これらの質問について30分程度話し合うだけで、大きな進展が得られます。進むべき方向性について必要な答えの80%程度を得られることが多いのです。しかし、顧客がより多くのワークロードをクラウドに移行するにつれて、顧客が採用する一般的なクラウドパターンや、繰り返し出てくる回答もいくつか見てきました。そういったパターンの多くについては、より迅速なアドバイスができるようになっています。特にワークロードを分類する4つの高レベルなパターンについて説明し、複雑さとコストの削減について顧客がどのように考えるべきかを説明したいと思います。
クラウドワークロードの4つのパターンと効率化戦略
まず、High Availabilityクラウドパターンから始めましょう。これは、顧客のアプリケーションが2つ以上のAvailability Zoneにデプロイされる、クラウド上で最も一般的なワークロードタイプです。回復力と冗長性が組み込まれています。多くのAWSサービスではこれがデフォルトとなっており、比較的簡単に実現できます。これは小売業や他の消費者向けサービス、そして最近では企業のバックオフィスでも非常に一般的です。これらのアーキテクチャは圧倒的に一般的で、顧客がオンプレミスで得ていた従来のコストや性能の数値を上回ることも比較的容易です。移行した顧客が継続して利用していることは、その良い証拠となっています。
しかし、さらに効率化できる一般的なポイントがいくつかあります。最も一般的なのは、特にクラウド以前からあり、オンプレミスのアーキテクチャから移行してきた顧客が、通常2つのAvailability Zoneで構築していることです。これは以前にプライマリとセカンダリのデータセンターを持っていたか、アクティブとバックアップのデータベースを持っていたためかもしれません。クラウドに移行する際に、そのパターンを維持しているのです。このパターンは本質的に冗長性と回復力のために100%のオーバーヘッドを必要とします。基本的にすべてのものの2つのコピーを実行しており、顧客がアーキテクトできる場合、これはかなり高コストとなります。
私たちが主に行っているように、できるだけ多くのAvailability Zoneを活用すると、バッファー要件は大幅に下がります。最大規模のRegionの一部で提供している5つのAvailability Zoneに負荷を分散できる場合、あるAvailability Zoneに問題が発生しても、システム全体で必要なオーバーヘッドはわずか25%です。これは全体のオーバーヘッドの4分の1に過ぎず、アーキテクチャの構成を変えるだけで大幅なコスト削減が実現できます。また、運用上の問題が発生した場合でも、レジリエンスと復旧オペレーションが機能し始めるまでの間に即座に影響を受けるのはアクティブな負荷の5分の1だけなので、影響度もずっと小さくなります。この観点からも優れたアプローチですが、現時点ではそれほど一般的ではありません。この戦略を導入するお客様は増えていますが、さらなる普及を期待しています。
次のワークロードのカテゴリは、少し直感に反するかもしれませんが、「Best Effort」と呼ばれるものです。実際、冗長性やレジリエンスがほとんどないか、比較的少ないワークロードが存在します。これらのシステムは1つのAvailability Zoneで、スタックも1つだけで運用されています。以前は、これはかなり珍しく、通常は請求処理のような、6時間のダウンタイムでも大きな影響がないシステムに限られていました。請求書は月に1回夜間に生成するだけなので、朝に追いつけば問題ないため、2つのコピーを常時稼働させる必要はありません。
機械学習のトレーニングでは、すべてのものを2つ以上同時に実行できるほどスケールできないケースが増えています。その代わり、データセンターの電源やネットワークの問題を未然に防ぐため、基盤となるインフラストラクチャの可用性を極めて高くすることに多大な投資を行っています。大規模なトレーニングプロセスでは、非常にまれなイベントのために複数のコピーを並行して実行するのは、コスト的に現実的ではありません。このようなシステムでは、可能な限り効率的なハードウェアで実行することに重点を置いて、お客様のコストと複雑さを削減しています。この分野のお客様が、Amazon EKS、Amazon SageMaker、AWS Batch、AWS Glueなどのコアサービスのドキュメントを1日か1週間かけて読むだけで、大きな成果を上げているのを見てきました。冒頭の例のように、比較的手間のかからない最適化を見つけ出し、すぐに削減効果を得られることが多いのです。
次のカテゴリは一般的ではありませんが、高度に分離されたシステムを必要とするお客様です。これは通常、政府機関や大規模なお客様で、厳格なコンプライアンスや規制要件があり、AWS Local Zonesのような環境で、その専用ゾーン全体を単独で利用する必要がある場合です。このカテゴリには取引所のようなワークロードが含まれ、これらのお客様に対するソリューションは、適切なサイジング、最適なインスタンスタイプの選択、インフラストラクチャの最適な利用に重点を置いています。
最近、もう1つの大きな利点が一般的になってきています。このような重要度の要件を持つワークロードの多くは、非常に厳格な変更管理を実施することで、5ナイン以上という優れた信頼性を実現しています。これらのお客様は通常、営業時間や取引時間が決まっており、その時間帯は誰も何も触れません。このアプローチにより、予期せぬハードウェア障害や完全に予測不可能なパフォーマンスの問題以外の問題を防ぐことができます。週40時間だけで5ナインを達成することを考えると、計算上は実際には9ツーに相当します - 週全体で見ると25%の可用性にも満たないのです。実際にはそれほど高可用性なシステムではありません。でも、誰も気にしないかもしれません。みんなが同じ40時間を使うことに同意しているので、実際には問題にならないのです。
しかし、業界全体のエコシステムというより大きな視点で考えると、誰もが仕事を40時間の忙しい時間帯に集中させることで、ピーク対平均比が上昇し、サービスの平均コストが増加してしまいます。私たちが提供するCloudのように、一部の業界では40時間モデルから24/7モデルへと移行しています。以前は決まった時間内に実際に足を運ばなければならなかった決済やインターネットバンキングなどのサービスも、今では24時間365日利用可能になり、ピーク対平均比を改善することで、コスト削減を実現できるようになりました。これは人的要因に関する非常に大きな視点です - 業界全体をより効率的に変革する方法についてです。このような取り組みがインセンティブ化され始めているのは、とても素晴らしいことだと思います。
そして最後のセグメントとして、グローバルに分散されたワークロードについて見ていきましょう。これらは複数のRegionやEdgeロケーションで実行されているアプリケーションです。典型的にはメディア、エンターテインメント、ゲーミング分野のものです。エンドユーザーや消費者、市民とリアルタイムでやり取りを行います。複数のRegionを使用する場合、Active-Activeか、フェイルオーバー用として使用することが多く、距離に関する要件なども存在します。ここで単純なアプローチを取ると、インフラのフットプリントが簡単に膨れ上がってしまう可能性があります。あるRegionで2つのAvailability Zoneを使用し、別のRegionでも2つの完全なAvailability Zoneを使用する必要があると言うかもしれません。これが最適な解決策である場合も多いのですが、それでも検討する価値のある問題です。なぜなら、時には別のRegionで2つのAvailability Zoneは必要ないかもしれないからです。
フェイルオーバー用の場合、めったに使用することはありませんし、あるRegionがダウンし、別のRegionのAvailability Zoneもダウンするという二重障害の可能性を考慮すると、大きなコスト削減につながる可能性があります。フェイルオーバーモデルから完全に脱却してActive-Activeに移行できれば、先ほどZoneレベルで説明したのと同じコストメリットを、Regionalレベルでさらに大きなスケールで実現できます。そしてそれはより安価になります。また、これらのモデルにおけるコアコストは強整合性のトランザクション要件に帰着する傾向があるため、その分野に投資し、そのようなパターンを回避する方法を学ぶことで、不釣り合いなほどの節約を実現できることがあります。ただし、今週初めに発表したD SQLは、まさにこのような顧客の負担を軽減することを目指しています。
さて、これらのほとんどは文化的なレベルで起こっています。私が投げかけている質問や行動の多くは、非常に平凡なものです。誰でも尋ねることができる、とてもシンプルな質問であり、尋ねるたびにシンプルに聞こえます。しかし、少なくとも私の経験では、結果を得るためには、それらの質問を毎回投げかけ、常にその答えを探し求める文化を築くことが重要です。そして、先ほど述べたインセンティブを整合させるために質問するだけではありません。成功を祝うことも非常に重要です。AWSの大規模な運用会議では、毎週、運用上の成功事例から始めています。チームは、システムのパフォーマンス向上、運用オーバーヘッドの削減、効率性の向上といった運用効率に関する成功事例を推薦します。
私たちはこれらの成功を祝うことを大切にしており、単に機能をリリースするだけでなく、このような成功を収めたことで昇進した人も見てきました。これは非常に重要なことです。このような反復的で文化的なアプローチにより、私たちは市場のテストに耐え、持続可能なアーキテクチャ、プロダクト、サービス、システムを提供できると考えています。そして、AWSにおける個人的な経験として、顧客が私たちの努力の上に構築していくのを見ることほど嬉しいことはありません。私たちはインフラストラクチャを構築するために多大な努力を重ねていますが、Cloudプロバイダーという性質上、それが一般の人々に直接届くことはありません。それを実現するのは、エンドユーザーに向けてであれ、パブリックセクターのワークロードで市民に向けてであれ、私たちの顧客です。顧客が独自のパターンを適用し、これまで以上に効率的なコスト削減を実現する方法を見るのが本当に楽しみです。以上で私の発表を終わります。ご清聴ありがとうございました。後ほどのReplayでも良い時間をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion