まだクラウドコンピューティングの基礎を学んでいる方、おそらく初めての本格的なプロジェクトを立ち上げている方、または従来の IT 運用に深く関わっている方は、きっと次のことを考えたことがあるでしょう。

AWS EC2 などの従来のサービスとしてのインフラストラクチャ (IaaS) オプションと、AWS Fargate などのマネージドハイブリッドオプション、または AWS Lambda などの完全なサーバーレスオプションのうち、より安価なオプションはどれですか?

簡単に言うと、これは複雑です。質問に対する何らかの答えを得るために、その理由をいくつか説明します。

製品、サービス、価格などは AWS に固有のものであることに注意してください。ただし、Azure、Google、その他にも同様の戦略と理由があると推測されます。

Google スプレッドシートを用意しましたので、コピーしてください。記事全体でこれを使用します。自由に独自のコピーを作成してください。必要に応じて、サーバーレスとサーバー以外の比較も可能です。

トレードオフの基本的な要約

コンピューティングオプションが互いにどのように異なるかという基本的な点については、他の人に伝えて、その詳細について説明します。

ただし、重要なトレードオフは次のように考えることができます。

EC2 は、予測可能な価格設定とパフォーマンスを提供します。ベアメタルに近いため、コンピュータに必要なことのほとんどを実行でき、非常に柔軟です。ただし、かなりの量の管理を行う必要があり、オフにするまで (または何か悪いことが起こるまで) 常にオンになっているため、分または時間ごとに料金を支払う必要があります。
Fargate は、手動での「サーバーレス風の」エクスペリエンスを提供し、コンテナーイメージ上で実行されるため、コンテナーイメージに配置できるものはすべて、基本的に Fargate 上で実行できます。全体的にはリクエストごとに料金が発生しますが、Fargate には追加の管理とインフラストラクチャが必要です (他のクラウドの競合オプションには必ずしも当てはまりません)。したがって、Fargate は高い柔軟性 (ただし EC2 よりは若干劣ります) を提供し、全体的なサーバーレスプロファイルを維持します。
Lambda は表向き、柔軟性を AWS がサポートするランタイムに制限しています (ただし、これらはカスタムランタイムとコンテナイメージの両方で拡張できます)。Lambda 関数はポートやその他の機能も使用できないため、それに依存している場合、Lambda は厳しく制限されすぎます。利点は、これらの同じ制約によって (一度調整すれば) 非常に迅速な開発フローが可能になり、真に完全にマネージドされることです。必要に応じて、他のサービスに必要なインフラストラクチャと、それをインターネットに接続するための API ゲートウェイを適用するだけで済みます。関数は、実行時間とその構成に基づいて呼び出しごとにのみコストがかかります。

非常に短い言葉で言うと、以上です。

なぜ複雑なのでしょうか?

複雑になる理由はいくつかあります。思いついたことをいくつかシェアさせていただきます。

最初の理由は、私が最も難しいと思う理由です。

架空のアプリケーションを定量化し、特定のハードウェアや構成に対するその影響、そして最終的には総コストを推測するにはどうすればよいでしょうか?

私たちができる最善のことは、既存のトラフィックパターンを調べ、それらを計算のベースラインデータとして使用することだと私は考えています。「汎用」ワークロードなどというものは存在せず、すべて状況に応じて決まります。

2つ目の理由は、そもそもこれがちょっと「リンゴとオレンジ」風の比較だからです。

たとえば、サーバーレスのコンテキストでは、コストを計算する際の主要なデータポイントの 1 つに、呼び出し回数を知ることが含まれます。サーバーの場合は、使用率(平均、中央値、最大、最小など) とサーバーの数になる場合があります。これらはすべて適切で有効な数値ですが、同じことを測定するわけではありません。

サーバーのコストは、1 か月に 1 つのヒットを処理する場合でも、1,000 万件のヒットを処理する場合でも同じです。Lambda の場合はそうではありません。
逆に、Lambda には実際には使用の概念はなく、使用されていないときはゼロにスケールし、実質的に必要なだけスケールアップします。

したがって、これらのさまざまな措置を同等の方法で満たす必要があります。

また、明らかな理由により、追加のインフラストラクチャと管理時間が必要なサーバーを備えたソリューションを、それらのコストがまったくかからないソリューションと厳密に比較することはできません。そうですね、金額的にはそうですが、セットアップとメンテナンスに費やす時間、ソリューションを実行/保守/開発する能力など、考慮すべき追加の懸念事項が生じます。

つまり、ドル単位の「品目コスト」以外にも目を向ける必要があります。非常にうるさいことを言うと、タイトルからはコストが議論されていることが推測されますが、ご容赦ください。

3 番目の理由については、アーキテクチャ上の品質、または伝統的に呼ばれている「非機能要件」に関係しています。冒頭で述べたように、コンピューティングの種類 (およびサービス!) にはさまざまなトレードオフがあります。たとえば、リソースの厳密に線形的な使用は、非常に変動性の高いトラフィックとは大きく異なり、同時実行性やスケーリングなどの側面に疑問が生じます。

これらの詳細については、次を参照してください。

2022 年に AWS でコンテナをスケーリングする

AWS 上のさまざまなオーケストレーターを使用した 2022 年のコンテナーのスケールアップ速度の比較

www.vladionescu.me

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FKHACnNKTefI%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DKHACnNKTefI&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FKHACnNKTefI%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

次に、関連する点ですが、4 番目の理由は、適合性と適用性のレベルです。簡単に言うと、一部の種類のアプリケーションまたはシステムは、本質的に特定のコンピューティングタイプにより適しています。要件を考慮すると、Lambda (または EC2 など) で特定のワークロードを実行することは文字通り不可能かもしれません。

他機種に向けた計算

これらは、あるコンピューティングモデルから別のコンピューティングモデルに計算する場合に役立つかもしれないいくつかのメモです。

EC2からラムダへ

この計算は、現在の毎月のトラフィック (リクエスト) とその平均応答時間 (レイテンシを含まないコンピューティング時間) を確認すれば、おおよそ可能になります。Lambda が計算時間、リクエスト数、構成に基づいて正確に価格設定されているとすると、すべきこれを十分に適切なサイズに簡単に調整できます。

また、関数のスケーリングがワークロードに対してどのように機能するかにも注目してください。

Lambda 関数のスケーリング

同時実行数は、AWS Lambda 関数が同時に処理する実行中のリクエストの数です。それぞれに…

docs.aws.amazon.com

EC2 システムは通常モノリスであり、複数の「パス」を持つ場合があることに注意してください。Lambda ランドスケープでは、おそらく各「パス」を独自の Lambda 関数にする必要があるでしょう。この場合は、スケーリングなどを考慮してください。

ラムダから EC2 へ

私はそれほど「サーバーフル」な人間ではないので、少なくとも少しは役立つようにここで最善を尽くします。

これに私がアプローチする方法は次のとおりです。

Lambda のトラフィックパターンを確認してください。それらは規則的でしょうか、予測可能なものですか、それとももっと混沌としたものですか? トラフィックが少ないときと多いときの差はどれくらいですか?
コンピューティングの種類とトラフィック量に基づいて、ほぼ適切と思われる開始マシン構成を選択します。
マシンをシステムにセットアップします。
k6などを使用してマシン上で負荷テストを実行し、1 秒間に実行されるリクエストの数を測定します。
Lambda トラフィックパターンに基づいて、標準トラフィックを見つけられるだけでなく、スケーリングのニーズが何であるかを確認できるはずです。

パフォーマンステストの基礎が必要な場合は、以下を参照してください。

GitHub – mikaelvesavuori/aws-performance-testing-starter: これは…の基本的な開始点です。

これは、AWS でパフォーマンステストを実施するための基本的な開始点です。- GitHub …

github.com

適切なサイズのインスタンスを見つけるためのリソースもいくつかあります。

ワークロードに適した EC2 インスタンスタイプを決定する

自分のワークロードに最適な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを判断するには、どのような手順を実行する必要がありますか?

再投稿.aws

5 つのステップで最適な EC2 構成を見つける方法 (実際のパフォーマンステストと結果付き)

アプリケーションにとって最適な EC2 構成は何かと考えたことはありますか? さまざまな方法を試したことがありますか?

www.concurrencylabs.com

比較してみよう！

まず、スプレッドシートのコピーを作成します。数値は 2023 年 11 月 26 日時点のものです (それ以降更新していない場合)。

正確な計算については、AWS 料金計算ツールをご覧ください。

AWS 料金計算ツール

AWS Pricing Calculator を使用すると、AWS のサービスを調査し、AWS でのユースケースのコストの見積もりを作成できます。

電卓.aws

すべてのコストと変数は公式の計算ツールから直接取得され、正確性を保証するために多くの計算が二重チェックされ、それに基づいてテストされています。

始める前の考慮事項

ほとんどの追加コスト (データ転送など) は計算されません。ストックホルム地域が使用されます。AWS と同様に、インスタンスの共有と常時使用、および月に 730 時間を想定しています。
AWS ではワークロードを実行するためのオプションが多すぎて、頭がクラクラしてしまいます。ここで紹介する基本的なものがすべてであるとは思わないでください。特定のワークロードに対しては、費用を大幅に節約できるオプションもあります。たとえば、Step Functions は、使い方に応じて非常に安価 (または非常に高価) になります。また、AppSync を使用すると、GraphQL サーバーを手動で展開する場合に比べてコストを大幅に削減できます。
いくつかの非常に異なるコンピューティングモデルを相互に直接比較することは非常に困難です。
継続的に使用されることはおそらく非常にまれであるため、現実的に常に 100% の使用率を想定しないでください。
非定常的な使用は EC2 コストを増加させます。詳細については、AWS の計算ツールを参照してください。
パフォーマンスはワークロードに依存するため、一般化するのは困難です。
インスタンスは一度に複数のリクエストを処理できる可能性があるため、固定インスタンスでは X リクエストを (線形に) 「時間」に変換することはできません。
「すべての」サービスを単に X 個のインスタンスに収めることはできないと仮定します。代わりに、1 つのサービス = 1 ～ n のインスタンスと仮定します。
ここで計算されたコストに追加されるその他の補助コストもあります。Elastic IP、ロードバランサー (ALB、ELB)、ログなどはすべて、直線的または使用量に応じてコストを増加させます。
ここでは、インスタンスを追加するという基本的なオプションを除いて、スケーリングは実際には考慮されていません。
ここでは復元力も考慮されていません。
API ゲートウェイは、基本的な NAT ゲートウェイでは利用できない機能を追加するため、Lambda セットアップで「さらに多くの」機能が追加されます。
静的 Web ページのような非常に単純なワークロードは実質的にゼロコストで提供できることを忘れないでください。そのユースケースでは Lambda も EC2 も必要ありません。
それが重要な場合は、EC2 の単一インスタンスではゼロダウンタイムのデプロイやロールバックなどが実行されるわけではないことを忘れないでください。
EC2 の場合は、スポットインスタンスや既存のワークロードの Graviton への移行またはアップグレードも検討してください。
AWS コスト最適化ハブを使用します。

スプレッドシートの仕組み

それほど複雑ではありませんが、要点を共有しましょう。

メンテナンスの側面も考慮すると、「時間当たりの人件費」がまさにそれです。「月あたりの低レベル操作 (時間)」で、メンテナンス労働の商をさらに調整できます。一般的に理解できる数字に設定されています。

「公に暴露されていますか？」公開されているシステムでは NAT ゲートウェイなどの追加コストがかかる場合があるため、これは切り替えることができる設定です。

「EKSを使いますか？」Fargate または EC2 セットアップで Kubernetes を実行する場合に使用できるトグルです。

「プロビジョニングされた同時実行性を使用しますか?」は Lambda 固有の設定です。「Provisioned concurrency (full month)」と併用してください。

「インスタンス数」、「スケーリングピーク」、「月あたりのスケーリング時間」、「クラスター数」は EC2 固有のものであり、復元力と高可用性についてある程度の期待を設定したい場合に重要です。

Fargate の場合、「1 日あたり開始されたタスク」、「平均継続時間 (分)」、「vCPU 数」を設定します。

「メモリ (GB)」と「ストレージ (GB)」は、 Lambda と Fargate の重要な設定です。これらはデフォルトで非常に標準的なレベルに設定されています。Lambda の場合、「1 秒あたりのリクエスト数」と「ミリ秒単位のリクエスト期間 (平均)」も設定する必要があります。

計算された行はすべて計算されたものであるため、これらをいじらないでください。

「コスト」セクションに最終的な合計額が表示されます。

最初の部分は、多かれ少なかれ、それぞれの合計と料金をまとめるものです。これは、あなたにとって興味深いかもしれませんし、そうでないかもしれません。
「合計、30 日」と「コンピューティング節約プランの使用 (1 年間のコミットメント)」は、おそらく最も関心のある数字でしょう。
残りの 2 つの濃い青色の HTTP API 行は、HTTP API とのさらなる比較です。
最後に、最後の 8 行には、Lambda (一番左) から他のオプションへの変化の割合が表示されます。

スプレッドシートの使用

これを機能させる魔法はありません。基本的には、AWS の公式料金計算ツールを詳しく説明するだけです。

Lambda 列に数値 (トラフィックなど) を入力し始めると、これらの数値が魔法の正しい EC2 または Fargate に相当するものに置き換えられることはありません。これはまだあなたが物事の側でやらなければならない仕事です。

スプレッドシートのコピーを必要に応じて更新および変更します。たとえば、提供されたマシン仕様を比較したい仕様に置き換えます。値シートを使用して新しいデータを追加したり、既存の値を更新したりできます。繰り返しになりますが、これらはすべて AWS 料金計算ツールから取得できます。

計算例

各コンピューティングタイプが最適な選択であると思われる典型的なケースについて、金銭的な観点から見てみましょう。

Lambda と単一の EC2 マイクロインスタンス: 安定した低トラフィックから中トラフィック

以下の画面は、スプレッドシートのデフォルト設定で表示されるものです。すぐに比較できるものの 1 つは、Lambda (列 B) と単一の EC2 マイクロインスタンス (列 D)です。

低から中程度のワークロードの場合、Lambda は、特に HTTP API を使用すると非常にコスト効率が高くなります。

価格に関しては、月あたり 2 時間の大まかな運用コストを考慮すると、マイクロインスタンスと API Gateway バージョン 1 上の Lambda を比較すると、ほぼ同等になります。オンデマンド HTTP API を使用すると、Lambda ソリューションは最大 38% 安くなります。。

ただし、高可用性など、アーキテクチャの品質に関するすべての意味のある考慮事項を考慮すると、EC2 オプションは直ちに破棄される必要があります。パフォーマンスについてはまだ話し始めていませんが、私自身のテストでは EC2 は確かに若干高速でしたが、より原始的で安全でないソリューションであるという欠点があることは言及しておきます。

これをきっかけとして、特定のしきい値を下回るサービスについて、Lambda と EC2 に関する些細な会話を無視することができます。この場合、1 か月あたり約 2,600 万リクエストです。それは多いですか、それとも少ないですか？それは状況による、とあなたは言います。私が扱うコンテキストでは、これは中間の、一種の媒体です。しかし、必要に応じて、月あたりわずか 75 ドルのコストで、多くの付加機能を備えた 2,600 万件のリクエスト (1 か月を通して 10 RPS) に対応できます。

勝者：ラムダ。

Lambda と Fargate: 長時間実行処理

すぐに (…Fargate?) おそらく Fargate が勝者であることがわかるでしょう。それが得意なはずですよね？私は Lambda よりも Fargate にあまり興味がないので、この例が意味があるかどうか見てみましょう。ともかく…

ここでは、15 分間の処理ワークロードが 1 日あたり 1,000 回実行される例を見ていきます。Lambda の最大継続時間はたまたま 15 分であるため、例としてこれほど「正確な」ワークロードを設定することは、現実というよりは理論にすぎません。私たちは常に壁にぶつかりそうになるため、実際のシナリオでは、他の方法で回避できない限り、この時点で Lambda はすでに支持されなくなっている可能性があります。

とにかく数字を見てみましょう。

Lambda はコンフォートゾーンから外れており、コストは 1500 ドル以上に増加しています。Fargate はコストの点で最大 60% 優れています。

サービスは私たち自身の環境内で行われているため、現在は公開サービスは必要ありません。Fargate が 1000 タスクを開始するように設定されている場合、コストパフォーマンス比は約 60% 向上します。

タスクは関数呼び出しとは多少異なります。したがって、これらのタスクについて、ChatGPT 4 は次のように教えてくれます。

Fargate の「タスク開始」イベントは、コンテナーの特定のインスタンスが実行を開始したことを意味します。これは、スケールアウト (負荷によるタスクの数の増加)、サービスの更新 (古いバージョンのコンテナーを新しいバージョンに置き換える)、または新規のデプロイメントが原因である可能性があります。

Fargate タスクは、通常、Lambda 関数に比べて存続期間が長くなります。これらは、継続的に実行する必要があるワークロードや、完了までに長時間かかる可能性のあるタスクに適しています。

大まかに、そして理論的には、アーキテクチャが並列 (バッチ) 処理を想定している場合、これは効果になります。ソリューションを再設計し、タスクの開始数を減らしてコストを節約できる可能性があるでしょうか? 多分。

余談ですが、EC2 と比較すると、おそらくこのようなものには、安価で高性能なスポットインスタンスが必要になるでしょう。

勝者: Fargate、この特定のシナリオの計算において私の能力の限りを尽くしました。

Lambda と高可用性 EC2: 動的な高スループットのワークロード

残念ながら、スプレッドシートで動的な条件を再現するのは困難ですが、非常に高いスループットの要件があり、大量のリクエストが受信されるというシナリオを想定してみましょう。月を通してスケールアップとスケールダウンを行う必要があります。

以下の計算では、Lambda (列 B) について、25 ユニットでプロビジョニングされた同時実行を有効にし、1.5 GB の RAM に更新しました。平均 100 RPS を取り込んでおり、継続時間はそれぞれ約 300 ミリ秒です。全体として、Lambda が多くの面倒な作業を行ってくれるシナリオですが、呼び出しが少し長かったり、メモリが少し多かったなど、状況は理想的とは言えません。

EC2 は、高スループットのワークロードに対して健全なコスト効率を示しています。

EC2 側 (列 G) では、4 台のマシンからなるクラスターを取得しm7g.xlarge、EKS クラスター内にセットアップしています。この構成を使用しても、かなり高い運用コストを想定しても、このソリューションは、HTTP API とコンピューティング節約プランを活用して、最も厳しいセットアップで実行する Lambda ソリューションよりも最大 43% 安くなります。

残念ながら、これは完全な比較ではありません。Lambda と適切な API ゲートウェイの管理上の利点がまだ欠けているためです。EC2 は NAT ゲートウェイを超えて単独で残されます。とにかく、ここには少しの支出の余地があります。

これは、いくつかのユースケースでは、実際に、回避策を講じることができれば、EC2 がより安価な選択肢になるという良い例として役立ちます。

勝者: EC2。

一般的な要点

Google スプレッドシートを使用すると、どのレベルでさまざまなコンピューティングソリューションを検討する価値があるかを理解するのが簡単になります (または少なくとも簡単になります)。

最後に、いくつかのポイントをお伝えします。

Lambda の場合、Provisioned Concurrency により大幅なコストを節約できますが、それはトラフィック量がかなり多くなった場合に限られます。
インターネットに公開される Lambda 関数の場合、API ゲートウェイのコストは関数自体のコストよりもはるかに大きくなる可能性があります。HTTP API (または「V2 API」) は、そのサブコストのコストを大幅に削減します。
Fargate に関して言えば、実際には 1 日に開始されるタスクの数が重要です。
Fargate は、Lambda と比較すると価格を非常に重視するオプションになる可能性がありますが、(良くも悪くも) より従来型のオプションであり、Lambda よりも追加のインフラストラクチャとメンテナンスが必要になることに注意してください。
EC2 の場合、コンピューティング節約プランを利用すると、1 年以上の契約が得られる代わりに、かなりの金額を節約できます。

巻末注: Polestar における実際のコスト効率の高いサーバーレス

私が 5 年間働いてきた Polestar では、2019 年からサーバーレスファースト戦略を採用してきました。セクシーではない、車以外の成功事例の中でも、これはもっと語る価値があると私が感じているものの 1 つです。Polestar の状況 (2024 年現在) では、カスタムソフトウェアの大部分がサーバーレスコンピューティング、特に AWS Lambda 上で実行されています。

では、どれくらい安くできるのでしょうか？たとえ具体的な数字をあげたかったとしても、それは常に相対的な要因の問題です。例: 1 か月あたり 1 億件のリクエストは多すぎますか? 海の一滴？あなたのランドスケープはサーバーレスで実行できますか? すでに明確な責任に分割されていますか? それとも、「マイクロサービス化」は組織にとって苦痛となるでしょうか? これらすべてが重要です。しかし、付加機能を備えたサービスを実行するのに月額 2 桁以下のサービスが多数ありますが、サーバーレスでなければその何倍もの費用がかかるでしょう。

同社には数百人のソフトウェアエンジニアと、幅広いデジタル製品をサポートする多数のチームがいることを考えると、ポールスターは「広くて浅い」状況と呼ぶことができる状況になりました。つまり、多くのアプリケーションは、ほとんど (または完全に) 互いに独立しています。システムがよりモノリシックであれば、(少なくとも理論的には) トラフィックをより少ないインフラストラクチャリソースに蓄積または集中させて、その「塊」を拡張することができます。しかし、もちろん、それは「大きな泥の塊」に対する非常に奇妙な議論になります。😅

この記事で学んだことから、この種の状況 (頻繁に変更があり、システムがほとんど独立している) では、サーバーレス方式でシステムを実行することで多額のコストを節約できることがわかります。個別に、各システムは (相対的に) 公平に実行されます。含まれるトラフィック量。各システムは独立して拡張でき、通常は単独での運用コストが非常に安くなります。私たちは、典型的な「サーバーレスコスト」 (Lambda、DynamoDB、EventBridge など) が、Polestar の全体的な AWS コストのかなり小さな部分であることを確認してきました。

各サービスと環境の特定の AWS アカウントに至るまで、このように明確かつ詳細に分離することで、チームがサーバーレスインフラストラクチャをどのように処理しているかについての鮮明な洞察を簡単に得ることができます。DynamoDB や Lambda などのサーバーレスコンポーネントは、従来の代替コンポーネントに比べて構成可能性が低い場合がありますが、システム周囲の状況が変化するにつれて、これらのコンポーネントは依然として時々チェックできる (そしてそうすべきである) ことを知っておくことが重要です。次のような非常に簡単な調整を行うことで、ランニングコストが 50% 以上大幅に改善されたことが何度かありました。

ARM アーキテクチャで Lambda を実行し、ランタイムをより新しいバージョンに更新します。
ヒューリスティックまたはデータ駆動型のアプローチ ( AWS Lambda Power Tuningなどのツールを使用) を使用して、Lambda 関数のメモリサイズを削減します。
選択的な DynamoDB プロビジョニングをテーブルに追加します。デフォルトではオンデマンドであり、その移行をサポートする経験的データがある場合はプロビジョニングされたテーブルの使用に「成長」するためです。

全体のコストが無視できる場合、もちろん 50% であっても「実際の」お金にはなりませんが、実際に、私たちが最適化した一部のシステムでは、ほんの少しの努力で月に数千ドルの改善につながりました。

サーバーレスのもう 1 つの大きな改善点は、有効化と開発者の高速化が容易になったことです。チームやエンジニアが AWS を使用できるようにするプラットフォームサービスチームも非常に小規模ですが、効果的です。これは主にサーバーレスファーストであるためです。この種のチームの業界標準は約 19% であると言われています。ポールスターでは、全スタッフの約 0.2 ～ 0.3%、部門レベルでは約 1% を占めています。これはサーバーレスが望ましくないからではなく、サーバーレスが効率と有効化に多大な影響を与えるからです。

まだサーバーレスを使用していない場合は、サーバーレスで何かを設計、構築、実行してみることをお勧めします。最後のひと押しが必要な場合は、喜んでさらに共有させていただきます。

読んでいただきありがとうございます! 何かを学んでいただければ幸いです。もう一度、私のゲストとなって、スプレッドシートを使用して、ケースに最適なコンピューティングインフラストラクチャの選択をご自身に知らせてください。

出典: https://medium.com/itnext/which-is-cheaper-serverless-or-servers-1b18816ce7f6

Please follow and like us: