要約: サーバーレス分野での FunctionGraph の FinOps 調査と実践に基づいて、このホワイト ペーパーでは、業界初のサーバーレス機能の総コスト見積もりモデルを提案します。
历川：华为云Serverless研发专家
平山：华为云中间件Serverless负责人
冯嘉：华为云中间件首席专家重要ポイント:
1) サーバーレスの急速な発展は広範かつ詳細な注目を集めていますが、サーバーレス機能の総コストの以前の見積もりには、効果的な理論的ガイダンスがまだありません。サーバーレス分野での FunctionGraph の FinOps 調査と実践に基づいて、このホワイト ペーパーでは、業界初のサーバーレス機能の総コスト見積もりモデルを提案します。
2) コストモデルの主要な要素の分析に基づいて、機能の運用コストの 5 つの最適化方法が提案されます; 同時に、ユーザーがコストを削減し、効率を向上させるのをより適切に支援するために、HUAWEI CLOUD は透過的な、効率的、ワンクリックの「ユーザー機能」を初採用。「コストリサーチセンター」。
問題紹介
サーバーレスのミリ秒単位の正確な従量課金制モデルにより、ユーザーはリソースのアイドル時間に対して支払う必要がなくなります。ただし、特定のアプリケーション機能の場合、課金コストに影響を与える要因は一意ではないため、ユーザーが機能実行期間中の合計課金額を正確に見積もることは困難な作業になります。
従来のクラウド リソースの循環リース モデルを例にとると、サイクル数にサイクル単価を掛けることで、ユーザーはリース期間の総コストを簡単に見積もることができ、クラウド プラットフォームが階層型を採用している場合でも、明確な心理的説明の期待を形成できます。価格設定または価格差別 戦略の場合、リースの総コストを計算することは難しくありません。
ただし、サーバーレスのシナリオでは、関数の総コストを事前に見積もるための効果的な理論的ガイダンスはまだありません。一方では、関数の課金に影響を与える主な要因は、関数メモリの仕様、単一インスタンスの同時実行性、関数の実行時間など、固有のものではありません。「従量課金制」では不確実性が高くなります。
もちろん、機能課金を見つけるための理論的なガイダンスは、主にユーザーが機能の総コストを評価するための効果的な基礎を提供することですが、さらに重要なことは、見積もりモデルをさらに使用して、ユーザーがアプリケーション機能とその構成の選択を最適化するのを支援する方法です。サーバーレス分野の FinOps にとって、コストは喫緊の課題です。
FinOps は、クラウド リソースの管理とコストの最適化に焦点を当てており、テクノロジ、ビジネス、金融の専門家を有機的に結び付けることで、ユーザー、企業、および組織のクラウド リソース コストを最適化し、クラウド ビジネスの入出力比率を向上させます [1]。サーバーレス分野における HUAWEI CLOUD FunctionGraphの FinOps 調査と実践に基づいて、このペーパーでは、サーバーレス シナリオにおける機能課金モデルと主な影響要因を分析し、機能運用中の総課金額を事前に見積もるためのモデル フレームワークを紹介します。このモデルは、ユーザーが機能運用の総コストを最適化し、ユーザー クラウドでのサーバーレス リソース管理のパフォーマンスを向上させ、経済的なサーバーレスを実現するのに役立つ効果的な基盤を提供します。
1. 用語集と背景知識
最初に、表 1 にリストされているいくつかの概念について簡単に説明します。
表 1: サーバーレス関数の一般的な名詞
メモリ仕様 (メモリ) : 関数仕様および関数インスタンス仕様とも呼ばれるメモリ仕様は、関数の単一インスタンスに対してサーバーレス プラットフォームによって割り当てられるリソース サイズを示します。通常、関数が使用できるメモリ サイズとして表されます。ユーザーによって指定され、インスタンスが使用できる CPU シェアはメモリ サイズに比例します。通常、サーバーレス クラウド プラットフォームでは、ユーザーが選択できるさまざまな仕様が用意されていますが、FunctionGraph を例にとると、図 1 に示すように、ユーザーは 15 の機能仕様から選択できます。
図 1: FunctionGraph はさまざまな関数メモリ仕様を提供します
Function Execution Time : これは、呼び出し要求応答を完了するプロセスで関数自体の実行に費やされた時間を指し、主に関数コードのロジックによって決定されます。一般に、CPU を集中的に使用する関数の場合、関数のリソース仕様 (メモリと CPU の共有) を増やすと、関数の実行遅延を大幅に短縮できます。ただし、ほとんどの時間をネットワーク IO やその他の操作に費やす関数の場合、リソース仕様を増やしても、実行レイテンシの改善は非常に限定的です。
インスタンスあたりの最大リクエスト数:関数の1 つのインスタンスが同時に処理できるリクエストの最大数。主に、データベース アクセス操作など、関数の実行中にダウンストリーム サービスの戻りをかなりの時間待機するシナリオに適しています。またはディスク IO など。同じトラフィック負荷の場合、関数の単一インスタンスの同時実行数を増やすと、1 メートルあたりのインスタンス数を減らし、ユーザーの請求を節約し、関数呼び出し要求のコールド スタート率を減らすことができます。
関数あたりの最大インスタンス数: 同時に実行される同じ関数のインスタンス数の上限を指します。ユーザーにとっては、最大インスタンス数により、異常なトラフィック ピーク時や機能障害時にクラウド プラットフォームが過度に拡張されてコストが暴走することを防ぐことができます。クラウド プラットフォームにとっては、最大インスタンス数により、プラットフォーム リソースが部分的に使用されることを防ぐことができます。異常な状況下で使用され、光を消費するため、異なる機能間のパフォーマンス分離が保証されます。
2.機能課金とコストモデル
単一インスタンスの観点からの機能課金見積もりモデルについては、[2] を参照してください。実際の運用環境では、非同期機能に加えて、サーバーレス クラウド プラットフォームは通常、FCFS (先着順) を使用して呼び出し要求に応答します. 関数トラフィックの潮汐変動については、プラットフォームはインスタンスの自動スケーリングを通じて自身を適応させ、同時インスタンス数の時間による変動は、図 2 に示すように、区分定数線形関数によって完全に特徴付けることができます。
図 2: 関数の同時インスタンスの数は、スケーリング プロセスによって変化します
異なるサーバーレス クラウド ベンダー間で課金方法に違いはありますが、関数の課金には通常、次のように、関数によって使用されるリソースに対する課金と、要求数に対する課金の 2 つの部分が含まれます。
後半は、関数呼び出しトラフィックと関数構成に関係なく、クラウド プラットフォームによって提供される無料請求の合計額を表します。
3. コスト最適化手法の検討
機能コストの推定モデルを使用すると、ユーザーのコストに影響を与える主な要因について説明できます。見積もり式 (1) で、クラウド プラットフォームによって提供される合計無料料金を無視すると、機能の月間合計コストの構造は次のようになります。
ポイント1: 関数コードのロジック自体を最適化して、関数の実行遅延を短縮する
関数のトラフィック負荷が同じ場合、実行レイテンシが低いほど、ユーザーの請求コストを節約できます。ユーザーのビジネス ロジックを前提として、関数コードを継続的に最適化し、関数の実行効率を向上させることは、ソフトウェア エンジニアリングの当然の要件ですが、サーバーレスのシナリオでは、これはさらに緊急の課題です。
具体的には、PythonやNodejsなどの軽量プログラミング言語の利用を検討して関数の初期化設定に不要な項目を減らし、データベースなど他のサービスを接続する操作をできるだけ関数実行エントリ前の初期化段階に移して簡素化するコードロジックなど
さらに、関数の実行状況をユーザーが把握できるように、FunctionGraph はアプリケーション関数の詳細な可視化と可観測性を提供し、呼び出し数、エラー数、および実行時間などの豊富な観察インジケーターの構成をサポートします。関数の実行時間は、図 3. モニタリングの例に示されています。
図 3: FunctionGraph 関数のランタイム監視の例
ポイント2：機能コードパッケージ、依存パッケージ、画像サイズの最適化
関数呼び出しがコールド スタートをトリガーすると、請求の観点から、コールド スタートの遅延は実行の遅延に含まれて一緒に請求されますが、コールド スタートの遅延のかなりの部分は、サードパーティのストレージ サービスからクラウド プラットフォームによって消費されます。 (図 4 に示すように、HUAWEI CLOUD オブジェクト ストレージ サービス (OBS) からユーザーのコード パッケージと依存関係パッケージをダウンロードするか、イメージ リポジトリ サービスからユーザーのアプリケーション イメージをプルします。現在、ほとんどのクラウド プラットフォームでは、コールド スタートのパフォーマンスを最適化するために、さまざまなキャッシュ メカニズムを使用してユーザー コードとイメージを事前にキャッシュしていますが、インスタンスの起動時にユーザー コードを読み込む際の遅延は依然として非常に重要です。したがって、機能コード パッケージのサイズは、課金時間を短縮するために、依存するパッケージとイメージの削減を含め、可能な限り最適化する必要があります。
図 4: ホット スタートとコールド スタートでの課金時間と最適化ポイント
ポイント3：関数中心の軽量関数を書く
サーバーレス プログラミング フレームワークでは、関数は可能な限り軽量で関数に焦点を当てたプログラム コードとして作成する必要があります。 a 一方では、単一の関数を持つ関数の実行遅延は、的を絞った方法で最適化する方が簡単ですが、他方では、関数に複数の関数が同時に実装されている場合、すべての関数が実行遅延になる可能性が高くなります。関数のパフォーマンスが同時に低下し、その結果、関数の実行中の合計請求額が増加します。
図 5: HUAWEI CLOUD FunctionGraph 関数フローの例
アプリケーション関数が実際に複数の関数を提供する必要がある場合は、大きな関数を複数の小さな関数に分解することを検討してから、図 5 の FunctionGraph 関数フロー関数に示すように、関数を配置して全体的なロジックを実装することができます。大規模な関数の分解は、ユーザーがサーバーレス コンピューティングでのタイムアウトなどの異常なシナリオを処理するためのベスト プラクティスの 1 つでもあります [4]。
ポイント4：ビジネスモデル対応を前提にシングルインスタンスマルチコンカレンシーを採用
式 (2) の関数のコスト構造から、ユーザーのビジネス モデルの前提の下で、特定の単一インスタンスの同時実行数を構成すると、関数の月間総コストを効果的に削減できることがわかります (ユーザーが構成しない場合)。 、クラウド プラットフォームのデフォルト値は通常 1 です。つまり、1 つのインスタンスは同時に 1 つの要求しか処理できません。したがって、関数が同時に呼び出されると、プラットフォームは応答するために複数のインスタンスを開始します。図 6 に示すように、複数の同時実行性を持つ単一のインスタンスを使用すると、待機状態での呼び出し要求の末尾の遅延を改善することもできます。
図 6: 単一インスタンスの同時実行: 請求時間の観点とインスタンス数の観点
もちろん、1 つのインスタンスの同時実行性は高いほどよいのですが、たとえば、過度に高い同時実行性を設定すると、関数インスタンス内の複数のスレッド間でリソースの競合 (CPU 競合など) が激しくなり、関数の応答性が低下します。ユーザーアプリケーションのパフォーマンスに影響を与える QoS インジケータなど 同時に、この記事の背景知識で述べたように、すべてのアプリケーション関数が単一インスタンスの複数同時実行の設定に適しているわけではありません。単一インスタンスの複数同時実行は、主に、ダウンストリーム サービスの戻りを待っている関数実行のプロセスでかなりの割合の遅延が消費されるシナリオに適しています. このようなシナリオでは、CPU などのインスタンス リソースの大部分がアイドル状態であり、データベースやメッセージ キューへのアクセスなどの待機、およびその他のミドルウェア、またはディスク IO、ネットワーク IO など。単一インスタンスの複数同時実行では、関数コード内のグローバル共有変数のエラー キャプチャ (リクエスト レベルのエラー キャプチャの粒度を考慮するなど) とスレッド セーフ (ロック保護など) を調整する必要があります。
ポイント5：実行遅延への影響を考慮した関数リソース仕様の選択
最後に、関数リソース仕様の選択について説明します。式 (2) から明らかなように、インスタンス メモリの仕様が大きいほど、課金コストが高くなります。ただし、メモリ仕様の選択では、関数の実行遅延への影響を同時に考慮する必要があります。ユーザー関数の観点から見ると、関数の実行遅延は、コード自体のビジネス ロジックによって決まるだけでなく、インスタンスの実行時に使用できるリソースのサイズによっても影響を受けます。インスタンス サイズが大きいほど、使用可能なメモリが大きくなり、CPU シェアが増加するため、メモリの多い関数や CPU を集中的に使用する関数の実行パフォーマンスが大幅に向上し、実行レイテンシが短縮される可能性がありますが、もちろん、この改善には上限があります。リソースの仕様を超えると、図 7 の破線で示されているように、リソースの増加が関数の実行遅延を短縮する効果はほとんど無視できます。上記の事実は、図 7 の実線で示されているように、特定のユーザー機能について、総請求コストを削減するために、可能な限り最小値を達成するように妥当なインスタンス サイズを構成する必要があることを示しています。
図 7: 関数仕様の選択では、コストと実行レイテンシの両方への影響を考慮する必要があります
図 8: 機能課金コストの主な要因の分析
4. サーバーレス機能コスト研究センター
コストを削減し、ユーザーの効率を高めることが、FunctionGraph の中心的なコンセプトです。上記で分析した 5 つの機能コスト最適化手法は、ユーザーの観点から説明されていますが、これらの問題はユーザーが考慮する必要がある範囲からはほど遠いものであると考えています。サーバーレス分野. 最高の FinOps 効果を達成するために, ユーザーは経済的なサーバーレスの利点を真に享受できます. 例えば, インスタンスレベルでの詳細な可視化と可観測性を前提として, ユーザーは機能的な FinOps のプロセス全体を自動化するのに役立ちます. 、透過的で効率的なワンクリック機能のリソース管理とコスト最適化サービスをユーザーに提供します。
図 9. オンライン リソース消費の認識と動的な仕様の推奨
この目的を達成するために、FunctionGraph は内部慣行に基づいて、近い将来に「ユーザー機能コスト研究センター - コスト分析および最適化センター」を立ち上げ、オフラインの電力調整、オンラインのリソース消費の認識と最適化をユーザーに提供します.いくつかの重い機能サービス,オンライン リソース レコメンデーション (図 9 に示すオンライン リソース レコメンデーション)、予測自動スケーリング プレビューなどを含む、ユーザーが FinOps 機能を実装するための技術的なしきい値を最小限に抑えます. ユーザー ビジネス開発、サーバーレス変換などは、非常に便利です.
V. まとめと展望
このホワイト ペーパーでは、主にサーバーレス コンピューティング シナリオにおける FinOps の問題について説明し、業界初のユーザー機能の総コスト見積もりモデルを提供し、このモデルに基づいて、ユーザーがアプリケーション機能を最適化し、サーバーレス リソース管理の効率を向上させ、コストを削減するための理論的なリファレンスと実践を提供します。総費用に応じて。
新興技術分野の台頭に伴い、最初に解決すべき問題は「Why & Value」であり、Huawei Yuanrong がサポートする次世代のサーバーレス機能コンピューティングおよびオーケストレーション サービスとして、FunctionGraph を FinOps およびその他の技術コンセプトと組み合わせて、は引き続き、経済的なサーバーレス サービスをユーザーに提供します。フォローアップでは、汎用のフル シナリオ サーバーレスに関する最先端の理論とケース プラクティスを共有し、マイクロサービス サーバーレスでの FunctionGraph の実際の経験を含め、コミュニティに還元します。
参考文献:
[1] FinOps とは: https://www.finops.org/introduction/what-is-finops/
[2] Lambda 関数をより高速かつ安価に実行する: https://levelup.gitconnected.com/running-lambda-functions-faster-and-cheaper-416260fbc375?gi=4370e4c57684
[3] 有効な AWS Lambda コスト最適化戦略。https://dashbird.io/blog/aws-lambda-cost-optimization-strategies/
[4] タイムアウトのベスト プラクティス。https://lumigo.io/learn/aws-lambda-timeout-best-practices/
フォローをクリックして、HUAWEI CLOUDの新技術について初めて学びましょう〜