Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル エンタープライズのためにAWS Lambdaの価格を変更しなければならない理由

エンタープライズのためにAWS Lambdaの価格を変更しなければならない理由

キーポイント

  • AWS Lambda supports 10GB of RAM and Container Images up to 10GB. This makes it comparable to container services like AWS ECS or Fargate.
  • For 2 CPUs and 4GB of RAM, AWS Lambda pricing per hour/unit is approximately 7.5 times greater than AWS Fargate Spot.
  • Enterprise batch processing workloads, such as financial modeling, require the capability to burst into 1000's of containers for daily processing.
  • Lambda can scale to 1500 containers in a second. With AWS Fargate, this can take up to 1 hour.
  • Selecting AWS Lambda for development, test, and production workloads will be challenging for enterprises performing batch processing. A cost comparison will lead customers to choose other services and lose out on Lambda's scalability and integrations.

原文(投稿日:2021/04/08)へのリンク

AWS Lambdaは、一般的に信じられていることに反して、財務モデリング、機械学習やビッグデータ処理などの多くのエンタープライズバッチワークロードに最適です。大規模な場合、インスタンスとコンテナベースのプラットフォームとのコスト比較により、Lambdaの価格設定とバッチ処理が完全には適合していないことを明らかにします。コストがエンタープライズチームにサーバレスの採用を思いとどまらせる場合、敏捷性と生産性を向上させる機会を逃します。この記事では、コスト管理といくつかの厳しい価格設定データについての考えを共有します。

クラウドコストの管理

クラウドコストの管理は、開発者やアーキテクトの注目を集めるトピックになりました。1つの要因は、マネージドクラウドサービスのオンデマンドの従量制課金への切り替えです。革新的な自律型チームのDevOps文化に従って開発とプロダクションクラウド環境の両方でリソースを作成する権限も与えられています。このプラクティスはチームの加速に役立つことが証明されていますが、クラウドの課金ショックのリスクが明らかにあります。これは、優れたコスト監視手法と開発チーム内の適切なレベルのクラウドコスト認識を組み合わせることで相殺できます。

ただし、コスト認識とコストFUD (恐れ、不確実性、不審) には違いがあります。コストFUDは、AWS Lambdaのようなサービスの従量制の価格設定のアイデアが、TCO (総所有コスト) と生産性のメリットがサービスコスト (出典) をはるかに上回る可能性があるにもかかわらず、開発者を遠ざけるときに見られます。ワークロードが予測できない場合は、オンデマンドの価格設定が適しています。使わないものにお金を払う必要はありません。ただし、裏返しがあります。ワークロードが長期間にわたって大規模な同時実行を必要とする場合、コストが眉をひそめ始める可能性があります。AWS Lambdaで実行される可変負荷のクラウドワークフローでは、1時間にわたって実行される数千のAWS Lambdaの呼び出しを簡単に使用できます。これはバッチ処理に限定されません。Webベースのトラフィックの急増は、同様の呼び出しパターンをもたらす可能性があります。

Lambda、FargateとEC2の価格比較

説明のために総ランニングコストを比較する前に、AWS Lambda、Fargate、EC2の価格モデルを比較しましょう。ここでは、us-east-1 (バージニア) リージョンの価格が使用されています。ほとんどの地域の価格は同じですが、一部の地域はより高額になる可能性があるため、想定する前に確認してください。

Lambdaの価格

  • AWS Lambdaを使用すると、サポートされている多くのイベントに応答して関数を実行できます。機能は最大15分間実行され、最大10GBのメモリと512MBの一時ストレージを利用できます。
  • Lambdaの使用量は、100万リクエストごとと時間ごとで請求され、ミリ秒で切り上げられます。請求レートは、各機能に割り当てられたメモリによって異なります。値の範囲は128MBから10GBです。AWS LambdaでのvCPUとネットワーク帯域幅の割り当ては、割り当てられたメモリの量に常に比例し、1つのvCPUは約1765MBに相当します。us-east-1では、現在の呼び出しコストはGB秒ごとに0.0000166667ドル、100万リクエストごとに0.20ドルです。(出典)

Fargateの価格

  • AWS Fargateは、コンテナ (またはコンテナベースのワークロード) を実行するためのマネージド環境であり、基盤となるインスタンスやコンテナオーケストレーションインフラストラクチャを明示または管理しない事実から、AWSによってサーバレスコンピューティングエンジンとして販売されています。代わりに、ユーザは、個々のタスクで構成されるサービスを使用してクラスタを作成して、オンデマンドで個々のタスク(コンテナ)を実行します。
  • Fargateの価格は2面的です。1時間あたりのvCPUと1時間あたりのメモリ (GB) で最も近い秒に切り上げられます。(出典)。CPU割り当ては、vCPU1時間あたり0.04048ドル、メモリは1時間あたり0.004445ドルで課金されます。
  • Fargate Spotは、一部のワークロードが中断される可能性があることを受け入れても構わないと考えている場合、最大70%のコスト削減を提供します。予備のコンピューティング能力を利用します。オンデマンドワークロードでこの能力が必要になると、このコンテナには2分後に終了するというシグナルが発行されます。

EC2の価格

  • EC2は仮想インスタンスを提供し、ユーザが基盤となるコンピューティングインフラストラクチャをより細かく制御できるようにします。これには、共有責任の大部分のトレードオフが伴います。たとえば、EC2を使用するということは、ネットワーク構成、高可用性、I/O構成、およびオペレーティングシステムを作成および維持する責任があることを意味します。EC2の価格設定も大きな幅があります。コンピューティング、メモリ、ネットワーク、およびストレージの要件のバランスを取るために、さまざまな価格設定モデルと豊富なオプションがあります。簡単に比較するために、ここではオンデマンドインスタンスに固執し、汎用インスタンスタイプを使用します。Graviton2ベースのt4gインスタンスを選択して、20%の節約とパフォーマンスの向上を実現したいと思うかもしれませんが、従来の方法を維持し、今のところ、ほとんどのユーザがArmではなくIntelベースのCPUを使用していると想定します。t3.mediumでは、1時間あたり0.0336ドルで4GBのメモリと2つのvCPUを取得します。
  • EC2 Spotは予備の能力を利用するオプションであり、Fargate Spotと同様に、ワークロードが中断可能でなければならないことを意味します。コスト削減は最大90%になります。実際の価格は、任意の時点での需要によって異なります。

これらの価格をある程度比較できるようにするために、2つのvCPUと4GBのメモリを備えた2000の同時コンテナまたはインスタンスを必要とするワークロードがあると仮定します。AWS Lambdaでは、最も近いのは4096MBのメモリ構成で、2.41個のvCPUを提供します。バッチ処理ワークロードのリクエスト数は比較的少なく、コストへの影響が無視できるため、100万リクエストあたりのLambdaの価格は除外します。バッチ処理ワークロードは数時間にわたって多くの処理ジョブを実行すると予想されるため、完全に使用された1時間の処理に基づいて計算します。

 

  AWS Lambda AWS Fargate Amazon EC2 Fargate Spot EC2 Spot
Unit Pricing $0.0000166667 per GB-second

$0.04048 per vCPU-hour +

$0.004445 per GB-hour

$0.0336 per hour (t3. medium) $0.01314179 per vCPU-hour + 0.00144306 per GB-hour $0.01008 per vCPU (based on estimated 70% spot saving)
Calculation

$0.0000166667 x 4 GB x 60 seconds

x 60 minutes x 2000 containers

($0.04048 * 2 vCPUs +

$0.004445 * 4 GB) x 2000 tasks

$0.0336 x 2000 instances ($0.01314179 * 2 vCPUs + $0.004445 * 4 GB) x 2000 tasks $0.01008 x 2000 instances

Price per Hour for 2000 instances

(4GB memory / *2 vCPUs)

$480.00 $197.48 $67.20 $64.11 $20.16

 

Lambdaは、このコンテキストではかなり高額に見え始めています。簡略化した計算では、AWS Lambdaは次のとおりです:

  1. Fargateのコストの 2.4
  2. EC2のコストの 7.1
  3. Fargate Spotのコストの 7.5
  4. EC2 spotのコストの 23.8 倍、ただしEC2 spotは価格変動があり、ワークロードを完了するために時間通りに厳密な保証が必要な場合、スポットインスタンスは適切でない場合があります。

これにより、大規模なLambdaワークロードにまだ慣れていない人々から次の3つのいずれかまたはすべての反応があるかもしれません。

  1. 「うん、Lambdaは高すぎる! 私にはこれは無理だ!」
  2. 「これはフェアな比較ではありません。Lambdaは、バースト性のあるイベント駆動型のワークロードではるかに安価に動作する場所向けに設計されています。」
  3. 「バッチ処理はLambdaには適していません。そのためには、大規模なインスタンスに分散されたHPCクラスタまたはビッグデータ処理フレームワークが必要です。」

価格設定から一歩離れて、これらすべてにもかかわらず、Lambdaがますます多くのバッチ処理を引き継ぐ理由を考えてみましょう。

なぜバッチ処理にLambdaを検討するのでしょうか?

確かに、HadoopsとSparksそして何かがありますが、AWS Lambdaでバッチ処理と計算集約型のデータ処理が実行されているのを見かけます。プラットフォームに依存しないビジネスロジックを作成し、ジョブを小さなステートレスユニットに分割することで、最大限の柔軟性が得られ、あらゆる環境でジョブを実行できます。FargateやEC2と比較すると、Lambdaには多くの利点があります:

  1. 他の環境とは異なり、Lambdaは何千ものコンテナに即時のスケーラビリティーを提供します。比較すると、Fargateで数千のコンテナにスケーリングするには1時間以上かかります (出典)。これを高速にスケーリングできると、より大きくスケーリングできるため、同じコストでワークロードを実行するための総時間が短くなります。
  2. Lambda実行環境は、最小レベルの分離を提供し、各小さなジョブは、最小限の特権でセキュアに短い生存期間の環境で実行されます。これにはセキュリティ上の利点があります。このレベルでのワークロードの分離は、障害の影響範囲 (blast radius) が小さいことも意味します。個々の障害を単一のコンテナ内の単一のイベントに分離できるため、トラブルシューティングがかなり容易になります。
  3. Lambdaとサーバレスの採用により、システムアーキテクチャの他の要素との結合が最小限に抑えられた、より小さな単一目的のコンポーネントが促進されます。これは、SOAとその次のマイクロサービスによってもたらされた分離よりも、さらに一歩進んだものです。この実践により、システムの個々のピースについて推論することが簡単になります。
  4. 10GBのRAMを割り当て、Docker/OCIコンテナイメージを使用したLambda関数のデプロイができるようになりました。これにより、一般的なコンテナベースのランタイム用に構築された既存のワークロードを簡単に実行できます。
  5. Lambdaは、多くのイベントソースおよびサービスと緊密に統合されています。
  6. Lambdaは、インスタンスまたはコンテナのクラスタを作成、管理、維持、および保護するためにチームが負担する、画一的な重荷を取り除くという約束を果たします。この種の負担を軽減することを会社に任せることで、重要なビジネス機能により多くの時間を費やすことができます。

ワークロードがビジネスでお金を稼ぐように設計されていると仮定すると、結果を生み出すまでの時間を減らすことは収益と等しいはずです。さらに、処理時間を短縮することで、毎日のバッチからオンデマンドまたはほぼリアルタイムの計算に移行する可能性が広がり、競争上の優位性と新しい収益源への道が開かれます。多くのワークロードで、特に特定のCPUアーキテクチャやオペレーティングシステムが必要な場合、AWS Lambdaが適切ではないと判断する場合があります。適切なコンピューティングサービスを選択するためのガイドについては、私のこのトピックに関する記事を参照してください。

コンピューティングコストは本当に重要でしょうか?

もちろん、コストは重要ですが、アプリケーションの構築と実行にかかる全体的なコストのどのくらいでしょうか? これは会社と状況によって異なります。多くのエンタープライズでは、人件費がはるかに高くなっています。熟練したチームメンバから時間を奪う選択では機会費用を考慮に入れなければなりません。組織がシステムの実行の維持や問題の消火に多くの時間を費やしている場合、それを定量化しようとしなかったとしても、これには莫大なコストがかかることが本能的にわかります。

その上、大規模で収益性の高いエンタープライズにとって480ドルは何でしょうか? さて、Lambdaでワークロードが成功すると、それを実行するための需要が増加します。これは、ジェボンズのパラドックスが述べている経済学の概念に従います。効率が上がると、需要の増加により、リソース消費量が直感に反して大きくなります。1日あたり480ドルのワークロードが1日4回実行され、さまざまな入力データを持つユーザの数が増えると、コストは突然1日あたり1000ドルになります。テストと開発のワークロードを考慮することを忘れないでください。アクティブに保守されている社内エンタープライズシステムでは、開発環境とテスト環境がプロダクションシステムよりも多くのリソースを消費する可能性があります。1日あたり480ドルの見積もりが、7桁の年間請求書にどのように変わるかがわかります。

確かに、7桁の請求書は、何百万時間もの開発者の時間を解放し、十分な収入を生み出すのであれば、有益かもしれません。残念ながら、それが本質的な問題ではありません。Lambdaのコストは、今でも予測不可能であり、他のオプションよりも大幅に高くなっています。これらのコストは目に見えます。分散バッチ処理フレームワークでクラスタのスケーリングやインスタンスのメンテナンス、または複雑な問題のトラブルシューティングに取り組む人々の時間とコストは、目に見えないほど優れています。メリットに関係なく、生のコストは常に重要なテクノロジーの決定を行う際のスケールをひっくり返します。

AWS Lambdaが真の汎用エンタープライズコンピューティングサービスになるためには、価格設定モデルを適応させる必要があります。これは、持続的なワークロードの完全な値下げまたは一括割引の形をとることができます。現在、FunctionsのAzureの価格設定モデルはAWS Lambdaと大きく異なることはありませんが、これは競合他社が差別化することを期待できる領域です。価格設定を他と比較しやすくするステップにより、AWS Lambda採用の決定でエンタープライズの頭を悩ませなくてよくなります。

リファレンス

  1. Financial Engines Cuts Costs 90% Using AWS Lambda and Serverless Computing
  2. You are thinking about serverless costs all wrong、Yan Cui氏
  3. Amazon EC2 On-Demand Pricing
  4. AWS Fargate Pricing
  5. AWS Lambda Pricing
  6. Amazon EC2 Spot Instances Pricing
  7. Spot Instances Advisor
  8. Fighting COVID with serverless with Denis Bauer
  9. Pricing - Azure Functions
  10. Lambda, EC2 or Fargate? A Simple Approach to Choosing AWS Compute for Enterprise Workloads

著者について

Eoin Shanaghy氏 は、経験豊富なテクノロジーリーダー、アーキテクト、開発者です。ダイナミックなスタートアップや大企業のシステムの構築やスケーリングの経験があり、3Gネットワーク管理システム、エンタープライズJava、リアルタイムトレーディングアプリケーションの設計と構築、デジタルビデオ、eラーニングなどがあります。fourTheoremの共同設立の前には、Shanaghy氏はビデオコンテンツマーケティングのスタートアップのShowpiperを設立しました。彼は書籍 AI as a Service の著者です。

この記事に星をつける

おすすめ度
スタイル

BT