JP2022511177A - ファンクションアズアサービス（ＦａａＳ）システムの強化 - Google Patents

ファンクションアズアサービス（ＦａａＳ）システムの強化 Download PDF

Info

Publication number
JP2022511177A
JP2022511177A JP2020564381A JP2020564381A JP2022511177A JP 2022511177 A JP2022511177 A JP 2022511177A JP 2020564381 A JP2020564381 A JP 2020564381A JP 2020564381 A JP2020564381 A JP 2020564381A JP 2022511177 A JP2022511177 A JP 2022511177A
Authority
JP
Japan
Prior art keywords
function
functions
execution
procedure
faas
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2020564381A
Other languages
English (en)
Other versions
JP7327744B2 (ja
Inventor
アール． ハグハイグハト、モハンマド
ドシ、クシティジ
ジェイ． ハードリッチ、アンドリュー
モハン、アヌプ
アール． アイヤール、ラヴィシャンカー
スン、ミンキュ
ブヤン、クリシュナ
ジュー ゴ、テク
ジェイ． クマー、モハン
プリンク、マイケル
レメイ、マイケル
ペレド、リーオア
ツァイ、ジュニア－シアン
エム． ダラム、デビッド
ディー． シャンバーレイン、ジェフリー
エー． スホムリノフ、ヴァディム
ジェイ． ダーレン、エリック
バグソルキ、サラ
セイン、ハーシャッド
メリク－アダムヤン、アレグ
サヒタ、ラビ
ユリエビッチ バボキン、ドミトリー
エム． シュタイナー、イアン
バッハムツキー、アレクサンダー
ラオ、アニル
ジャン、ミンウェイ
ケイ． ジャイン、ナイルシュ
フィロズシャヒアン、アミン
ブイ． パテル、バイジュ
ホアン、ウェンヨン
ラグラム、イェルリ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of JP2022511177A publication Critical patent/JP2022511177A/ja
Application granted granted Critical
Publication of JP7327744B2 publication Critical patent/JP7327744B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/88—Monitoring involving counting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/502—Proximity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/52—Indexing scheme relating to G06F9/52
    • G06F2209/521—Atomic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2105—Dual mode as a secondary aspect
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning

Abstract

システム、装置および方法の実施形態は、強化されたファンクションアズアサービス（ＦａａＳ）をユーザ、例えばコンピュータ開発者およびクラウドサービスプロバイダ（ＣＳＰ）に提供する。そのような強化ＦａａＳサービスを提供するよう構成されるコンピューティングシステムは、１または複数の制御アーキテクチャサブシステム、ソフトウェアおよびオーケストレーションサブシステム、ネットワークおよびストレージサブシステム、ならびにセキュリティサブシステムを含む。コンピューティングシステムは、実行管理の抽象化を表し、実行の管理の負担からユーザを保護するアーキテクチャサブシステムによって提供される実行環境においてユーザによってトリガされるイベントに応じて関数を実行する。ソフトウェアおよびオーケストレーションサブシステムは、保護された実行を維持しながら、減少したインスタンス化レイテンシ、および、増加した実行のスケーラビリティを用いて、関数コードについてのコンテナをインテリジェントにスピンアップおよびスピンダウンすることにより、関数実行のためのコンピューティングリソースを割り当てる。更に、コンピューティングシステムは、ミリ秒単位のインクリメントまで下げられた粒度課金を用いて、それらのコードが実行されるときだけ顧客が支払うことを可能にする。

Description

実施形態は概して、クラウドコンピューティングに関する。より具体的には、実施形態は、強化されたファンクションアズアサービス（ＦａａＳ）コンピューティングシステムに関する。
ファンクションアズアサービス（ＦａａＳ）は、イベント指向型の拡張性が高いコンピュータコード実行モデルであり、通常、クラウドコンピューティングインフラストラクチャ上で専用アプリケーションプログラミングインタフェース（ＡＰＩ）エンドポイントをプロビジョニングするために短時間実行する。従って、ＦａａＳはクラウドコンピューティングの進化におけるステップとみなされ得る。ＦａａＳは、場合によっては「サーバレスコンピューティング」とも呼ばれ、これによりソフトウェア開発者は、コードの実行に伴うハードウェアまたはアプリケーションソフトウェアリソースをプロビジョニングする、または、そうでなければ事前定義するために必要なコスト、時間、および支出を生じさせることなく、拡張性が高いコードを書くことが可能となり得る。また、ＦａａＳにより、クラウドサービスプロバイダ（ＣＳＰ）は、より良い割り当て（例えば、ビンパッキング）に起因してリソース利用を増加させることが可能となり得る。
ビジネスロジックへの着目が増加し、クラウドスタック実装の懸念や制御が減少することに伴い、スケールのコンピュートユニットは経時的に変更している。ＦａａＳは、共通言語ランタイム（ＣＬＲ）および実行コンテキストライフサイクルなどのランタイム環境を抽象化する。ユーザ、例えば、アプリケーション開発者およびＣＳＰは、ＦａａＳを通じて著しい価値を得ることができる。例えば、開発者は高水準言語を使用して関数コードなどのアプリケーションを構築し、関数コードを実行のためにＦａａＳプラットフォームにアップロードする。開発者は自身でホスティングすることなく単にＦａａＳプラットフォームを使用するだけであり、ＦａａＳプラットフォームのインフラストラクチャはユーザに対して非可視的である。
ＣＳＰの場合、ＣＳＰは主な差別化要因として関数のポートフォリオをサービスとして使用し得るが、改善の余地は大いに残っている。例えば、現時点において、クラウドにおいて書かれデプロイされた関数コードが、ＣＳＰが提供する関数と密接にリンクするようになるにつれて、「プロプライエタリロックイン」に関する懸念が残る。このプロプライエタリロックインとは、アプリケーションが特定のクラウド環境に最適化されるようになることを意味する。従って、ＣＳＰ間で関数を移動すると、アプリケーションの性能および応答性が犠牲になることがあり、加えて、ＣＳＰが提供する関数のいくつかが他のＣＳＰによってサポートされないという状況がもたらされる。
既存のＦａａＳの解決手段には課題がある。例えば、既存のＦａａＳの解決手段は通常、未成熟な開発者ツールのエコシステムを提供し、これにより、コストの大きいコールドスタートが必要となり、高レイテンシが生じる。更に、既存のＦａａＳの解決手段は、現在、コード実行状態の制御が限定されており、管理が難しいという問題がある。加えて、ＦａａＳは、抽象化の追加の層を導入しているので、既存のＦａａＳの解決手段によって、特有の、または、新たなシリコンフィーチャを公開および実践することがより難しくなる。
以下の明細書および添付の特許請求の範囲を読み、以下の添付図面を参照することで、当業者は、実施形態の様々な利点を理解するであろう。
一実施形態による、ＦａａＳコンピューティング環境の例の図示である。
一実施形態による、ＦａａＳシステムコンポーネントのセットの例のブロック図である。
一実施形態による、ＦａａＳサーバ構成の例のブロック図である。
一実施形態による、強化ＦａａＳシステムの例のブロック図である。
一実施形態による、強化ＦａａＳシステムのサブシステムの例のブロック図である。
一実施形態による、リソース割り当ておよび制御のための強化ＦａａＳアーキテクチャの例のブロック図である。
一実施形態による、強化ＦａａＳアーキテクチャを使用するユーザレベル機能の管理のフローチャートである。
一実施形態による、コンテナにおける様々な仮想電力管理ユニット（ｖＰＭＵ）イベントをモニタリングするための例示的なＦａａＳコンピュートノードのブロック図である。
一実施形態による、ｖＰＭＵバッファの例のブロック図である。
一実施形態による、関数の性能をモニタリングするための方法の例のフローチャートである。
一実施形態による、電子処理システムの例のブロック図である。
一実施形態による、半導体パッケージ装置の例のブロック図である。
一実施形態による、複数のＦａａＳ関数にわたるメモリ共有のフローチャートである。
一実施形態による、複数のＦａａＳ関数にわたるメモリ共有を提供するＦａａＳシステムの別の例のブロック図である。
一実施形態による、２つのＦａａＳ関数の間の通信を容易にする関数ルックアサイドバッファの別の例のブロック図である。
一実施形態による、分散ＦａａＳ関数をオーケストレーションするためのＦａａＳシステムの別の例のブロック図である。
一実施形態による、ファンクションアズアサービスのコンテナランアヘッド投機的実行を提供する方法の例のフローチャートである。
一実施形態による、コンテナランアヘッド投機的実行をサポートするＦａａＳシステムの別の例のブロック図である。
一実施形態による、画像回転関数のコンテナランアヘッド投機的実行をサポートするＦａａＳシステムの別の例のブロック図である。
一実施形態による、フィードバックサポートを有するファンクションアズアサービスを提供する方法の別の例のフローチャートである。
一実施形態による、フィードバックサポートを有するＦａａＳシステムの別の例のブロック図である。
一実施形態による、フィードバックサポートを有するＦａａＳシステムの別の例のブロック図である。
一実施形態による、インスタンス化のための複数の選択肢を有する関数の例の例示的な図である。
一実施形態による、インスタンス化のための複数の選択肢を有する関数をサポートするＦａａＳシステムの別の例のブロック図である。
一実施形態による、インスタンス化のための複数の選択肢を有する関数のためのファンクションアズアサービスを提供する方法の別の例のフローチャートである。
一実施形態による、スケジューラを有するＦａａＳシステムの別の例のブロック図である。
一実施形態による、ＦａａＳサーバアーキテクチャの例のブロック図である。
一実施形態による、強化ＦａａＳスケジューリングプロセスの例である。
一実施形態による、関数のフローチャートである。
一実施形態による、強化された関数実行シーケンスの例である。 一実施形態による、強化された関数実行シーケンスの例である。
一実施形態による、複数のオペレーションを有する関数のスケジューリングのフローチャートである。
一実施形態による、ＦａａＳのためのメモリストレージ強化コンピューティングアーキテクチャの例のブロック図である。
一実施形態による、ＦａａＳプラットフォームのコンテナおよび関数のためのメモリ割り当てのフローチャートである。
一実施形態による、関数実行のためのバッチ関数リクエストの例である。
一実施形態による、半導体パッケージ装置の例の図示である。
一実施形態による、関数リクエストのバッチのフローチャートである。
一実施形態による、２以上の関数リクエストのバッチのフローチャートである。
一実施形態による、関数リクエストのスケジューリングのフローチャートである。
一実施形態による、冗長関数実装の例である。
一実施形態による、冗長関数実装のフローチャートである。
一実施形態による、ＦａａＳのスケジューラを表す関数生成グラフを示す。
一実施形態による、スケジューラを有する強化ＦａａＳシステムを示す。
一実施形態による、ＦａａＳ関数実装のフローチャートである。
一実施形態による、共通データストレージを有する強化ＦａａＳアーキテクチャの例である。
一実施形態による、例示的ＦａａＳデータストレージのフローチャートである。
一実施形態による、ＦａａＳセキュリティプロトコルを実装および実施する例示的方法のフローチャートである。
一実施形態による、専用ＦａａＳキャッシュを有する強化ＦａａＳサーバアーキテクチャの例のブロック図である。
一実施形態による、汎用キャッシュを有する強化ＦａａＳサーバアーキテクチャの例のブロック図である。
一実施形態による、データオブジェクトのデータ量を示すグラフの例である。
一実施形態による、例示的な強化された関数リソース管理のフローチャートである。
一実施形態による、ソフトウェアスレッドを優先化する方法の例である。
例示的実施形態による、強化ＦａａＳアーキテクチャにおけるページレベルＱｏＳを提供するためのページテーブルにおけるタスクとサービスのクラス（ＣＬＯＳ）との間のインタラクションを示す。 図２１Ｂと同様である。
例示的実施形態による、ページレベルＱｏＳに関連する別のアーキテクチャを示す。
一実施形態による、ＦａａＳサービスに関する決定性および正確度を提供するためのアーキテクチャの例を示す。
一実施形態による、課金目的でリソース利用を計算する方法の例である。
一実施形態による、分散コンピューティング環境の例のブロック図である。
一実施形態による、ファンクションアズアサービスを提供する別の例のフローチャートである。
一実施形態による、複数の関数にわたってメモリ再使用を可能にするＦａａＳシステムの例のブロック図である。 図２５Ａと同様である。
一実施形態による、ファンクションアズアサービスを提供する方法の別の例のフローチャートである。
一実施形態による、ファンクションアズアサービスを提供する別の例のフローチャートである。
一実施形態による、関数コールグラフの例示的な図である。
一実施形態による、関数の分割の例示的な図である。
一実施形態による、関数コールグラフの別の例示的な図である。
一実施形態による、関数の統合の例示的な図である。
一実施形態による、複数の関数によって共有されるメモリを有する強化ＦａａＳシステムの別の例のブロック図である。
一実施形態による、ファンクションアズアサービスを提供するフローチャートである。
一実施形態による、ＦａａＳシステムの別の例のブロック図である。
一実施形態による、コンテナリバーサル機能をサポートするファンクションアズアサービスを提供するフローチャートである。
一実施形態による、コンテナリバーサル機能をサポートするＦａａＳシステムの例のブロック図である。
一実施形態による、関数実行性能の改善のための連続アプリケーションを有するファンクションアズアサービスの提供のフローチャートである。
一実施形態による、関数実行性能の改善のための連続アプリケーションを有するＦａａＳシステムの例のブロック図である。
一実施形態による、ＦａａＳのための強化コンテナ構築およびキャッシュ管理の例である。 図３１Ａと同様である。
一実施形態による、例示的キャッシュエビクションのフローチャートである。
一実施形態による、別の例示的キャッシュエビクションのフローチャートである。
一実施形態による、キャッシュされたデータオブジェクトの生存時間の決定のフローチャートである。
一実施形態による、強化された関数分散の例である。 図３２Ａと同様である。
一実施形態による、強化された関数分散の例である。 一実施形態による、強化された関数分散の例である。
一実施形態による、関数分散のフローチャートである。
一実施形態による、ＦａａＳの関数の強化された関数コンストラクトの例である。
一実施形態による、強化された関数コンストラクトからのモニカ識別のフローチャートである。
一実施形態による、関数コールの頻度に基づいてコールグラフを使用する関数のプリフェッチの例を図示する。
一実施形態による、ＦａａＳ関数の実行を強化するための方法の例である。
一実施形態による、現在の関数の前の関数を示すブロック図である。
一実施形態による、先行関数に基づいてＦａａＳ関数を実行する方法の例である。
一実施形態による、関数が実行される確率に基づいてコンテナのウォーム状態を維持する例を示す。
一実施形態による、ウォームコンテナからＦａａＳ関数を実行する方法の例である。
一実施形態による、サイズに基づく適応型メモリ階層化を示すブロック図である。
一実施形態による、利用率に基づく適応型メモリ階層化を示すブロック図である。
一実施形態による、関数を適応的にメモリ階層化するための方法の例である。
一実施形態による、ＦａａＳのための高速クラスロードの環境を示す。
一実施形態による、強化ＦａａＳコンピューティング環境において関数を実行する方法の例である。
一実施形態による、時間的スケールおよびクラウドスケール（水平）フィードバック両方の連続アプリケーションを容易にするＦａａＳ環境を示す。
一実施形態による、各関数型の異なるベクトルを示す。
一実施形態による、適切なリソースを予め確保する方法の例である。
一実施形態による、コードの最適化に関連する異なる特性を示す。
一実施形態による、強化ＦａａＳコンピューティングにおいて関数を実行する方法の例である。
一実施形態による、デマンドフィンガープリントと関数実行との間の関係を示すグラフである。
一実施形態による、リソースマネージャのオペレーションを示す。
一実施形態による、デマンドフィンガープリントを使用する効率的なＦａａＳリソース管理の方法の例である。
一実施形態による、デマンドフィンガープリントの例である。
一実施形態による、関数クライアントと関数実行ビークルとの間の通信の例である。
一実施形態による、不透明マーカを使用するＦａａＳ関数の実行の方法の例である。
一実施形態による、関数のコンテキストを一意に識別するトークンに基づくサーバ位置選択の例を図示する。
一実施形態による、関数呼び出しの管理のフローチャートである。
一実施形態による、関数呼び出しの管理の詳細な方法のフローチャートである。
関数呼び出しの位置がリクエスト元に基づいて選択されるＦａａＳシステムの例のブロック図である。
関数呼び出しの位置が関数コールツリーに基づいて選択されるＦａａＳシステムの例のブロック図である。
一実施形態による、ドメイン間制御転送の例のブロック図である。
一実施形態による、リモートプロシージャコール先の動作のフローチャートである。
一実施形態による、リモートプロシージャコール元の動作のフローチャートである。
一実施形態による、アプリケーション層関数がデータプレーン関数と並べられるＦａａＳアーキテクチャの例のブロック図である。
一実施形態による、ランタイムフレームワークの動作のフローチャートである。
一実施形態による、調整されたレスポンスオブジェクトの解決手段の例を図示する。
一実施形態による、呼び出しインスタンスに対するレスポンスオブジェクトの調整のフローチャートである。
一実施形態による、パラメータマーシャリングの解決手段の例を図示する。
一実施形態による、プラットフォームにまたがって関数を等しく呼び出す高レベルアーキテクチャの例の図である。
一実施形態による、関数パラメータのマーシャリングのフローチャートである。
一実施形態による、関数間の機能情報の転送の例のブロック図である。
一実施形態による、符号化インライン機能（ＥＩＣ）情報の例のブロック図である。
一実施形態による、ハードウェアキューマネージャの例のブロック図である。
一実施形態による、ハードウェアキューマネージャの動作のフローチャートである。
一実施形態による、機能のエンキューのフローチャートである。
一実施形態による、機能のデキューのフローチャートである。
一実施形態による、キー識別子とキーとの間のマッピングの例を図示する。
一実施形態による、単一アドレス空間の例のブロック図である。
一実施形態による、コンテキストスイッチの例のブロック図である。
一実施形態による、キー識別子マップ更新の例のブロック図である。
一実施形態による、キー識別子マッピングの更新のフローチャートである。
一実施形態による、保護キー識別子更新命令の例のブロック図である。
一実施形態による、保護キー識別子の更新のフローチャートである。
一実施形態による、サブページパーミッションを修正するように許可された権限の無いコンポーネントの例のブロック図である。
一実施形態による、サブページパーミッションの制御のフローチャートである。
一実施形態による、機能情報の制約を含む非優先化モードパスの例を図示する。
一実施形態による、メモリアクセスの制御のフローチャートである。
図１は一実施形態によるＦａａＳコンピューティング環境を示す。開発者は、１または複数のコンピュータ関数を表す関数コード１００（ここではコンピュータコードとも呼ばれる）を書き、関数コード１００は、例えばＣＳＰデータセンタ１０４におけるＦａａＳプラットフォーム１０２にアップロードされる。例えばユースケースまたはインターネットオブシングス（ＩｏＴ）のイベントなどのトリガ１０６が、ＦａａＳプラットフォーム１０２で関数コード１００の実行を開始する。制御されるＦａａＳプラットフォーム１０２、そのデータセンタ、エッジ環境およびＩｏＴ（モバイルを含む）デバイスを含むＣＳＰデータセンタ１０４内において、インフラストラクチャは「スピンアップ」され（例えば、アクティブ化され、および／または、割り当てられ）、オンデマンドでスケーリングされる。関数コード１００は、ＣＳＰの物理的インフラストラクチャ／エッジ／ＩｏＴデバイスおよび基礎となる仮想化コンテナで実行される。最後に、実行の完了に応じて、インフラストラクチャは「スピンダウン」される（例えば、非アクティブ化および／または割り当て解除される）。
以下でより詳細に説明されるように、本明細書において説明される技術は、イベントに応じてオンデマンドで関数コードを実行する、および、コンピュートスケールのユニットとして対応する関数で関数コードをデプロイするスケールのアトミックユニットに基づいてイベントの数に合わせて自動的にスケーリングするなど、強化ＦａａＳ機能を提供することによって、プロプライエタリロックイン、コストの高いコールドスタート、レイテンシ、および、コード実行状態の管理／制御に関する懸念を回避する。加えて、本明細書において説明される技術は、新たなシリコンフィーチャを公開および実施することを容易にする。本明細書において説明される技術は、開発者がＣＳＰ ＦａａＳプラットフォームによってサポートされるより高水準の言語を使用してアプリケーションを構築することを可能にすることによって、コーディングを更に一般化し、ＣＳＰのＦａａＳプラットフォームによるコンピュートに対する更なる需要を促進し得る。
図２は、本明細書において説明される強化ＦａａＳシステム２０２のコンポーネント２００（２００ａ、２００ｂ）の例を示す。示された例において、イベントオリエンテーションコンポーネント２００ａは、イベントに応じてオンデマンドで関数コードが実行されることを確実にし、最小管理コンポーネント２００ｂは、ＦａａＳサービスプロバイダによって、関数コードを実行するインフラストラクチャ管理をユーザ（例えば、コード開発者）から抽象化し、高スケーラビリティコンポーネント２００ｃは、イベント（例えば、ユーザイベントまたはＩｏＴ関連イベント）の数に合わせて関数コード実行を自動的にスケーリングし、スケールコンポーネント２００ｄのアトミックユニットは、コンピュートスケールのユニットとして対応する関数でコンピュータコードをデプロイし、高粒度課金コンポーネント２００ｅは、顧客（例えばコンピュータコード開発者）が、コードを実行させるときだけ支払うこと、および、顧客が例えば１００ミリ秒単位のインクリメントで課金されることを可能にする。以下でより詳細に説明されるように、強化ＦａａＳシステム２０２はまた、他の有利なコンポーネントを含み得る。
従って、ユーザおよびＣＳＰは、強化ＦａａＳシステム２０２を通じて著しい価値を得ることになる。強化ＦａａＳシステム２０２によってユーザに提供される価値は、例えば、関心のあるオペレーションの開発に対する集中の増加、市場投入までの時間（ＴＴＭ）の低減、インフラストラクチャ管理の低減、総所有コスト（ＴＣＯ）の低減を含む。ＣＳＰの場合、強化ＦａａＳシステム２０２によって提供される価値は、例えば、高マージンサービス採用の促進、コンピュートのユニットあたりの収益の増加、新たなクラウドワークロードが可能となること、コストの償却の改善、コンピューティングリソースのスケジューリングの柔軟性、および、他のＣＳＰと競合する能力の提供を含む。
実施形態において、強化ＦａａＳシステム２０２には５個のコンポーネントがある。第１は、関数を形成して関数のコンピュータコードを実行する関数フォーマットコンポーネントである。第２は、イベントコールを関数にルーティングするためのイベント処理ＡＰＩプロキシコンポーネントである。第３のコンポーネントは、関数コードパッケージを受信し、格納し、保護する関数コードストレージである。第４のコンポーネントは、コンテナにおいて、または、他の隔離実行代替物において、関数コードがダウンロードされてインスタンス化される関数実行環境を提供するＦａａＳコンテナである。実行後、コンテナは、新たな関数のために消去（またはリセット、再初期化など）される。コンテナは多くの場合、セキュリティおよび隔離のために、仮想マシン（ＶＭ）内で実行する。最後のコアコンポーネントは、関数コードのためにコンテナをスピンアップする（例えば「コールドブート」）ことによって、利用可能なコンピューティングリソース内においてコンテナ配置を最適化するための関数／コンテナオーケストレーションコンポーネントである。関数が最近実行した場合、新たな関数が既に「ウォーム」コンテナに配置され、インスタンス化レイテンシを減少させることがあり得る。
図３は、ユーザＣＰＳに強化ＦａａＳ性能を提供するためのＦａａＳサーバ構成３００を示す。示される図において、ＦａａＳサーバ構成３００は、強化ＦａａＳ基板３０６上にＦａａＳ管理ロジック３０４を含むスマートネットワークインタフェースカード（ＮＩＣ）３０２を含む。スマートネットワークインタフェースカード３０２は、ＦａａＳサーバ３００の制御センターとして機能する。ＦａａＳサーバは、オーケストレーション方式で関数の複数セットを実行するよう構成されるユニットを実行する１または複数のコンピュータコードを含む。示された例において、中央演算処理装置（ＣＰＵ）３０８（例えばホストプロセッサ）は、ＦａａＳエグゼキュータ３１０を使用して第１セットの関数３１２を実行し、アクセラレータ３１４（例えば機能固定型ハードウェアロジック）は、第２セットの関数３１６を実行し、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）３１８は第３セットの関数３２０を実行する。従って、示されるＦａａＳサーバ構成３００は、専用アクセラレータおよびＦＰＧＡを含む専用シリコンを装備する。ＦａａＳワークロードは、例えば、ワークロードの粒度の増加という観点において、従来のワークロードとは異なる特性を有する可能性があり、ワークロードの粒度の増加は、アクセラレータ３１４およびＦＰＧＡ３１８などの専用シリコンの活用を容易にし得る。複数のセットの関数を分解することによって、ＦａａＳサーバ構成３００は、ＣＳＰが各ワークロード（例えばトランスコード、推論）を、アクセラレータ３１４、ＦＰＧＡ３１８、ＣＰＵ３０８、グラフィックス処理ユニット（ＧＰＵ）（図示せず）などの最適なシリコンの部分にマッチさせることを可能にする。図３において説明されるＦａａＳサーバなどのＦａａＳ固有ハードウェアは、ＦａａＳ性能の改善、ならびに、より多くのユーザおよびＣＳＰによる採用を可能にする。
ＦａａＳサーバ構成３００に含まれるコンポーネントは、示されるものより多くても少なくてもよい。例えば、一例において、ＦａａＳサーバ構成３００は複数のＣＰＵ３０８を含む。別の例において、ＦａａＳサーバ構成３００は、ＦＰＧＡ３１８を含み、ＣＰＵ３０８を含まない。更に別の例において、ＦａａＳサーバ構成３００はアクセラレータ３１４を含み、ＣＰＵ３０８を含まない。
ここで図４を参照すると、強化ＦａａＳシステム４００の実施形態が示される。示されるシステム４００は、ユーザインターフェースハンドラ４０２、オーケストレータ４０４、ＦａａＳアーキテクチャ４０６、ネットワーキングおよびストレージマネージャ４０８、ならびにセキュリティマネージャ４１０を含む。実施形態において、システム４００は、コンテナ／関数実行環境を提供するＦａａＳアーキテクチャ４０６を使用して実行されるＦａａＳ関数コード４１２を受信する。示されるシステム４００はまた、例えばＦａａＳ関数コード４１２などの自身のコンピュータコードを実行するためのユーザリクエストなど、システム４００によって受信された１または複数のＦａａＳイベント４１４を検出する。ＦａａＳイベントに応じて、対応する関数コード４１２は、コンテナ、または、システム４００の別の隔離実行代替物においてダウンロードされ、インスタンス化される。ユーザインターフェースハンドラ４０２は、イベントコールをコンピュータコード４１２の対応する関数にルーティングするイベント処理ＡＰＩプロキシである。オーケストレータ４０４は、コンテナ、または、関数コード４１２のための他の実行ビークルをスピンアップすることによって、利用可能なコンピューティングリソース内において、関数の実行を（例えば、コンテナ、仮想マシン、プロセスなどのうち、どれによって実行されるかによって）最適化する。関数が最近コンテナにおいて実行された場合、コンテナは「ウォームコンテナ」としてマーキングされる。オーケストレータ４０４は、既に「ウォーム」のコンテナ（より一般には、準備ができた実行ビークル）において新たな関数を配置し、インスタンス化レイテンシを減少させ得る。本明細書において使用される「コンテナ」という用語は、プロセス、プロセスグループ、仮想マシン、プロセスアドレス空間内のサンドボックス環境、仮想マシン内のプロセスなど、様々であり得る関数コード４１２などのコードのための任意の形式の実行ビークルとみなされ得る。ネットワーキングおよびストレージマネージャ４０８は、セキュリティマネージャ４１０によって保護される関数コード４１２を受信および格納し得る。一例において、セキュリティマネージャ４１０は、セキュリティおよび隔離のために、コンテナがＶＭ内で実行することを確実にする。
図５は、サブシステムを含む強化ＦａａＳシステム５００の実施形態を示す。示された例において、ＦａａＳシステム５００は、ユーザエクスペリエンスサブシステム５０２、セキュリティサブシステム５０４、ソフトウェアサブシステム５０６（５０６ａ～５０６ｃ）、およびハードウェアサブシステム５０８（５０８ａ～５０８ｄ）を含む。ソフトウェアサブシステム５０６は、ライブラリ５０６ａ、フレームワーク５０６ｂ、プラットフォーム、およびオーケストレーションモジュール５０６ｃなどを含み得る。加えて、示されるハードウェアサブシステム５０８は、ＣＰＵ５０８ａ、ＧＰＵ５０８ｂ、メモリ、ストレージ５０８ｃ、ネットワーキングコンポーネント５０８ｄ、アクセラレータ５０８ｅ（例えばＦＰＧＡ）などを含む。強化ＦａａＳシステム５００は、実行されるＦａａＳ関数コード５１０を受信し、１または複数の関連するＦａａＳイベント５１２に応じて関数コード５１０を実行する。
従って、強化ＦａａＳシステム５００は、フィーチャ収益化の機会を作ることによって、より多様な市場に適している。通信サービスプロバイダ（ＣｏＳＰ）、および、エッジロケーションを有する地域のＣＳＰのような、より小さいサービスプロバイダに対して、ＦａａＳは、エンドツーエンドアプリケーションおよびサービスの次の波へのより大きい参加の機会を表す。多くの次世代アプリケーションおよびサービスは、アプリケーションまたはサービスの一部が、消費者または企業の近くで実行または提供されることを必要とし得る。これらのエッジサイトにおいて、関数の小さいポートフォリオをホスティングすることは、小さな参加者にとって、Ｈｙｐｅｒｓｃａｌｅ ＣＳＰから利用可能となるものなどの、すべての開発および運用（ＤｅｖＯｐｓ）ツール、ＡＰＩ、およびサービスを有する豊富なプラットフォームアズアサービス（ＰａａＳ）を提供することと比べて、遥かに容易な仕事である。
強化ＦａａＳシステム５００は、コンピューティングリソースのテナンシー、スケールおよび利用率を増加させることによって、既存のＦａａＳアーキテクチャを改善し、ＦａａＳパラメータを広げる。ＦａａＳは、クラウドベース技術の開発のデフォルトモードになり、バックエンドインフラストラクチャの保守から開発者を解放し、少数ではなく多数に対してプログラミングを開放する可能性がある。このように、強化ＦａａＳシステム５００は、開発者にとって役立つ完全に新しい方式を提供する可能性を有する。例えば、示されるシステム５００は、ＦａａＳプロバイダが提供するものを強化および拡張するソフトウェアをサポートする、および／または、直接提供する。ＦａａＳサービスプロバイダは、より良いツールによってＦａａＳ採用の障壁が低くなることから利益を得る。一方、ユーザは、システム５００によって提供される、使用の容易性の増加を経験する。
本明細書において、特定の例は、ＦａａＳ関数に関連して説明されるが、概念は、例えば非ＦａａＳコンテナ、デスクトップアプリケーションなど、他のタイプのソフトウェアコンパートメントにも、より幅広く適用可能である。
強化ＦａａＳアーキテクチャ
強化ＦａａＳシステム（例えば、図４および図５において示されるＦａａＳシステム）はまた、ソフトウェア関数および／または高速化された関数を使用してハードウェアフィーチャを直接制御するためのユーザレベル機能（例えば、ＦＰＧＡまたは他の構成可能ロジック）を提供し得る。そのようなアプローチは、ソリッドステートドライブ（ＳＳＤ）ブロックデバイスをバックアップする権限のある保守関数、アクセラレータのための管理関数などにとって有利であり得る。関数は、生存時間が長くないｒｕｎ－ｔｏ－ｃｏｍｐｌｅｔｉｏｎタスクなので、それらによるハードウェアの使用に対するハードウェアベースの制御は、（例えば、関数がユーザレベルソフトウェアの任意の他の関数から区別されないものに対して）そのようなアクセスを仲介するために他の層のプラットフォームソフトウェアを必要とする場合に比べて、より高い効率性および透明性を提供する。
図６Ａは、リソース割り当ておよび制御のための強化ＦａａＳアーキテクチャ６００を示す。示されるアーキテクチャ６００において、第１関数６０２（Ｆ１）は、ＣＰＵコンテナ６０８内で実行されるコード６０４、および、セキュリティ証明トークン６０６を含む。示される第１関数６０２はまた、ユーザレベル機能のセットを定義するメタデータ６１０と関連付けられる。一例において、ユーザレベル機能は、コンテナ６０８外部の１または複数のフィーチャに対応する。例えば、ＯＳ６１２におけるフィーチャ６１４は、メモリ管理、システムコールなど、または、それらの任意の組み合わせを含み得る。加えて、ＶＭＭ６１６（仮想マシンモニタ、例えばハイパーバイザ）におけるフィーチャ６１８は、メモリ管理、デバイス管理、ネットワーク再構成、ネットワークパスへのアクセス、仮想ソフトウェア再構成など、または、それらの任意の組み合わせを含み得る。実施形態において、ＣＰＵ６２０におけるフィーチャ６２２は、リソースディレクタ技術（ＲＤＴ）モニタリングカウンタ、ＲＤＴキャッシュ、および、メモリ制御、ハードウェア性能モニタリングカウンタ、ＤＲＡＭのより直接的な制御、３Ｄ ＸＰｏｉｎｔ、ストレージデバイスなど、または、それらの任意の組み合わせを含む。更に、アクセラレータ６２４におけるフィーチャ６２６（例えばＦＰＧＡ）は、ハードウェア再構成、デバイスリセットなど、または、それらの任意の組み合わせを含む。
関数６０２に関連付けられるセキュリティ証明トークン６０６は、偽造不可能であり得、第１関数６０２のアクティブ化のいくつかの可算、発見可能、または検証可能の属性に結びついている。従って、ＯＳ６１２における検証モジュール６２８および／またはＶＭＭ６１６における検証モジュール６３０が、セキュリティ証明トークン６０６が有効であると決定した場合、第１関数６０２は、フィーチャ６１４、６１８、６２２および６２６（すなわち、ユーザレベル機能に対応する）を使用することを許可される。示される、第１関数６０２からの曲がった矢印は、コンテナ６０８内、および、コンテナ６０８外において第１関数６０２が行い得る様々なコールを表す。一例において、許可されたフィーチャは、確保可能でない、または、他の形で、ＶＭＭ６１６、ＯＳ６１２、または他のソフトウェア「エグゼクティブ」（例えば、ハイパーバイザホストゲストＯＳ）による第１関数６０２への公開が防止される。実際、強化によって正確性違反（例えば、プロトコルおよび／またはシンタックスエラー）またはセキュリティ違反が生じない限り、アーキテクチャ６００は、ユーザレベル機能のセットを強化／拡張し得る。強化は例えば、ＯＳ／ＶＭＭカウンタのフィルタリングビュー、「アフィニティ化」などＯＳ／ＶＭＭオペレーションに対する制御の調整（例えば、ＶＭとホストとの間の関係を確立するアフィニティ規則の実施）、または、メモリ階層化のためのポリシーヒントなどを含み得る。しかしながら、セキュリティ証明トークン６０６が無効であると決定された場合、アーキテクチャ６００は、ユーザレベル機能の第１関数６０２による使用を防止し、デフォルトのフィーチャで実行を継続する。
図６Ａに示されるアクセラレータ６２４はまた、別個の関数がアクセラレータ６２４を再構成することを可能にする１または複数の仮想インタフェース６３２（６３２ａ～６３２ｃ）を含む。一例において、第１関数６０２は、第１仮想インタフェース６３２ａを介してアクセラレータ６２４を再構成し、第２関数６３４（Ｆ２）は、第２仮想インタフェース６３２ｂを介してアクセラレータ６２４を再構成し、第３関数６３６（Ｆ３）は、第３仮想インタフェース６３２ｃを介してアクセラレータ６２４を再構成する。従って、仮想インタフェース６３２は、図６Ａに示されるアーキテクチャなどのＦａａＳアーキテクチャにおける、単一ルートＩＯ仮想化（ＳＲ－ＩＯＶ）および／またはシリアルラピッドＩＯ（ｓＲＩＯ）の使用を可能にする。
ここで、図６Ｂを参照すると、図６Ｂは、図６Ａに示されるものなどの強化ＦａａＳアーキテクチャを使用してユーザレベル機能を管理する方法６４０を示す。方法６４０は概して、例えば、既に説明されたシステム２０２（図２）、システム３００（図３）、システム４００（図４）および／またはシステム５００（図５）などの強化ＦａａＳシステムにおいて実装され得る。より具体的には、方法６４０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせに格納されるロジック命令セットとして実装され得る。
示される処理ブロック６４２は、コンテナ内で実行される関数に関連付けられるセキュリティ証明トークンの検出を提供する。セキュリティ証明トークンが有効かどうかについての決定がブロック６４４で行われ得る。有効な場合、ブロック６４６は、ユーザレベル機能のセットの関数による使用を許可する。ここで、ユーザレベル機能のセットは、コンテナ外の１または複数のフィーチャに対応する。機能のセットは例えば、自己モニタリング、仮想空間の一部の制御、ページの範囲の読み取り保護の制御、ページの範囲の書き込み保護の制御、永続メモリに格納されたオブジェクトの名前空間の確立、メモリ管理、システムコール管理、デバイス管理、ネットワーク構成、ネットワークパスへのアクセス、仮想ソフトウェア再構成などを含み得る。更に、フィーチャはホストプロセッサ（例えばＣＰＵ）フィーチャ、ＯＳフィーチャ、仮想マシン（例えばＶＭＭ）フィーチャ、アクセラレータフィーチャなどであり得る。
加えて、ユーザレベル機能のセットの強化が正確性違反（例えばプロトコルおよび／またはシンタックスエラー）またはセキュリティ違反を生じさせるかどうかについての決定が、ブロック６４８で行われ得る。生じさせない場合、示されるブロック６５０は、強化が正確性またはセキュリティ違反を生じさせないという決定に応じて強化を行う。ブロック６４８において、強化が正確性またはセキュリティ違反を生じさせると決定された場合、方法６４０が終了する。ブロック６４４において、セキュリティ証明トークンが無効であると決定された場合、ブロック６５２は、ユーザレベル機能のセットの関数による使用を防止する。
追加の留意点および例
例６０１は、コンピュータ実行可能プログラム命令のセットを含む少なくとも１つのコンピュータ可読記憶媒体を含む。このプログラムはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、コンテナ内で実行する関数に関連するセキュリティ証明トークンを検出させ、セキュリティ証明トークンが有効である場合、ユーザレベル機能のセットの関数による使用を許可させ、セキュリティ証明トークンが無効である場合、ユーザレベル機能のセットの関数による使用を防止させる。ここで、ユーザレベル機能のセットは、コンテナ外の１または複数のフィーチャに対応する。
例６０２は、例６０１の少なくとも１つのコンピュータ可読記憶媒体を含み、プログラム命令は、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、セキュリティ証明トークンが有効である場合、ユーザレベル機能のセットの少なくとも１つの強化機能を実行させる。ここで、セキュリティ証明トークンは、正確性違反またはセキュリティ違反を生じさせない場合に有効である。
例６０３は、例６０１の少なくとも１つのコンピュータ可読記憶媒体を含み、ここで、ユーザレベル機能のセットは例えば、自己モニタリング、仮想空間の一部の制御、ページの範囲の読み取り保護の制御、ページの範囲の書き込み保護の制御、永続メモリに格納されたオブジェクトの名前空間の確立、メモリ管理、システムコール管理、デバイス管理、ネットワーク再構成、ネットワークパスへのアクセス、仮想ソフトウェア再構成を含むグループから選択される。
例６０４は、例６０１の少なくとも１つのコンピュータ可読記憶媒体を含み、１または複数のフィーチャは、ホストプロセッサフィーチャ、オペレーティングシステムフィーチャ、仮想マシンフィーチャ、およびアクセラレータフィーチャを含むグループから選択される。
図７Ａは、コンテナ７０２内の関数７１４の実行中に関数またはコンテナレベルで様々な仮想パワーパフォーマンスマネジメントユニット（ｖＰＭＵ）イベント７００がモニタリングされるＦａａＳコンピュートノードを示す。イベント７００は、ネストされたモニタリングを可能にするアーキテクチャインタフェース７０４（例えばハードウェアおよび／またはソフトウェア）を介するモニタリングのために構成され得る。ネストに関して、モニタリングは、仮想マシンゲスト、ベアメタルオペレーティングシステム、またはベアメタルコンテナにおいて行われ得るのと同一の方式で、コンテナ内、または、更には関数内において行われ得る。換言すると、いくつかのアーキテクチャイベント（例えば、実行された命令の数、発生したキャッシュミスの数など）を測定する能力、または、ソフトウェアイベントカウンタ（ページインまたはページアウトされたページの数、受信または送信されたパケットの数など）をサンプリングする能力は、カウンタがどこから読み取られるかに依存しない。更に、測定は、特定のレベル（すなわち、関数、コンテナ、ゲストＯＳ、ホストＯＳなど）の寄与を読み取りに反映させる読み取りを実現するために、各レベルで可能である。
示された例において、イベント７００は、実行回数、サイクルあたりの命令（ＩＰＣ）、メモリ帯域幅、キャッシュ利用率、秒あたりのＩ／Ｏオペレーション（ＩＯＰ）、および、ネットワーク帯域幅を含むが、他のイベントもモニタリング／収集され得る。モニタリングされるイベント７００のプログラミングは、システムソフトウェア機能を通じて統一され得る。一例において、例えばコンテナ７０２および／またはホストマシンによって提供されるｖＰＭＵドライバは、イベント７００の統一を行う。より詳細に説明されるように、イベント７００は、様々な仮想ＰＭＵカウンタ（例えば、他のカウンタをミラーリングする「シャドウ」カウンタ）を通じてトラッキングされ得る。
例えば、時間ｔ０において、コンテナ７０２における関数７１４の実行に関連付けられるカウンタ値の第１スナップショット７０６が生成される。同様に、時間ｔｎにおいて、カウンタ値の第２スナップショット７０８が生成され得、時間ｔｎ＋１において、カウンタ値の第３スナップショット７１０が生成され得、以下同様である。カウンタ値は概して、１または複数のイベント７００を定量化し得、ここで、スナップショット７０６、７０８、７１０は、新しい命令、新しいインタフェースコールなどに応じて生成され得る。ハードウェアにおけるスナップショット７０６、７０８、７１０の実装は、ソフトウェアオーバヘッドを最小化し得る。１または複数のスナップショット７０６、７０８、７１０は、ソフトウェアネストのより深いレベルにおける他の事前に存在するスナップショットの他の部分をミラーリングするシャドウスナップショットであり得る。スナップショット７０６、７０８、７１０および／またはスナップショット７０６、７０８、７１０の間の差異（例えばデルタ）は、関数７１４のスクラッチパッドエリアとして動作し得るｖＰＭＵバッファ７１２に格納される。示された例において、ｖＰＭＵバッファ７１２は、ＡＰＩエンドポイント７２０（例えば、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ／ＨＴＴＰエンドポイント）を介して、関数７１４、オーケストレータ７１６、またはノードマネージャ７１８のうち１または複数に公開される。
従って、示された解決手段は、各関数呼び出しのために限定されたメモリリソースを提供するＦａａＳインフラストラクチャにおける容量または帯域幅に関してスタベーションを防止するために使用され得る。より具体的には、例として、関数７１４の開発者は、スナップショット７０６、７０８、７１０を介して、ＯＳメトリクス、メモリキャッシュおよびメモリアクセス統計値などを取得するようにｖＰＭＵをプログラミングすることによって、関数７１４がメモリページスワップまたはキャッシュスラッシングにどれだけ遭遇したかどうか、または、その程度をモニタリングし得る。加えて、複数のノードレベルｖＰＭＵは、分散ｖＰＭＵに構成され得る。
ここで、図７Ｂを参照すると、関数７２６の実行に関連付けられる第１メトリクスデータ７２４（例えば、テレメトリスナップショットおよび／またはスナップショット間の差異）が関数７２６およびコンテナソフトウェア７２８に提供されるｖＰＭＵバッファ７２２が示される。示された例において、コンテナソフトウェア７２８は、第１メトリクスデータ７２４（例えば、経時的なキャッシュ利用率）のアグリゲーションを実行し、アグリゲーションに基づいて第２メトリクスデータ７３０を生成する。加えて、関数７２６は、第３メトリクスデータ７３２を生成するために第１メトリクスデータ７２４を収集および処理し得る。
ここで、図７Ｃを参照すると、関数の性能をモニタリングする方法７３４が示される。既に説明されたように、方法７３４は概して、例えば、システム２０２（図２）、システム３００（図３）、システム４００（図４）および／またはシステム５００（図５）などの強化ＦａａＳシステムにおいて実装され得る。より具体的には、方法７３４は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせに格納されるロジック命令セットとして実装され得る。
示される処理ブロック７３６は、実行の第１時点において、コンテナにおける関数の実行に関連付けられるカウンタ値の第１スナップショットの生成を提供し、カウンタ値の第２スナップショットは、実行の第２時点においてブロック７３８で生成される。一例において、ブロック７４０は、第１スナップショット、第２スナップショットまたは第１スナップショットと第２スナップショットとの間の差異のうち１または複数をｖＰＭＵバッファに格納する。加えて、ｖＰＭＵバッファは、ブロック７４２においてＡＰＩエンドポイントを介して、関数、オーケストレータまたはノードマネージャのうち１または複数に公開され得る。
従って、本明細書において説明される技術によって、関数開発者は、バックグラウンド性能モニタリングを介して、関数実行中に生じる特定の性能テレメトリを区別するために、コンテナまたは任意の他の実行ビークルと連携して作業することが可能となる。従って、イベントオリエンテーション、最小管理、高いスケーラビリティ、スケールのアトミックユニット、および、粒度の高い課金がすべて実現され得る。
追加の留意点および例
例７０１は、実行可能プログラム命令のセットを含む少なくとも１つのコンピュータ可読記憶媒体を含む。これらのプログラム命令は、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、コンテナにおける関数の実行に関連付けられるカウンタ値の第１スナップショットを生成させ、コンテナにおける関数の実行に関連付けられるカウンタ値の第２スナップショットを生成させ、第１スナップショット、第２スナップショット、または第１スナップショットと第２スナップショットとの間の差異のうち１または複数を仮想電源管理ユニット（ＰＭＵ）バッファに格納させる。
例７０２は、例７０１の少なくとも１つのコンピュータ可読記憶媒体を含み、プログラム命令は、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、アプリケーションプログラムインタフェース（ＡＰＩ）エンドポイントを介して、仮想ＰＭＵバッファを関数、オーケストレータまたはノードマネージャのうち１または複数に公開させる。
共有メモリの例
いくつかの実施形態は、有利なことに、コア内メッセージおよび／または通信のためにバッファ強化を提供し得る。従来のＨＴＴＰを介する関数間通信は、協調する関数が同一のコア上の同一の位置にある場合に必要となるものより多くのオーバヘッドを伴い得る。いくつかの実施形態は、２つの協調する関数が、２つの関数の間で交換されるデータのコンテンツをコピーするためにメモリセグメントを共有することを可能にするために共有メモリを提供し得る。有利なことに、いくつかの実施形態は、ＯＳカーネルおよび他のＨＴＴＰ層をバイパスすることによって、関数間通信オーバヘッドを回避し得る。
ここで、図８Ａを参照すると、電子処理システム８１０の実施形態は、プロセッサ８１１、プロセッサ８１１に通信可能に連結されるメモリ８１２、プロセッサ８１１およびメモリ８１２に通信可能に連結されるロジック８１３を含み得、第１トランジェント関数と、第１トランジェント関数と連携する第２トランジェント関数との間でメモリ８１２のメモリ領域を共有する。いくつかの実施形態において、ロジック８１３は更に、ＦａａＳプラットフォームの協調トランジェント関数の間のコア内メッセージ通信のためにバッファ強化を提供するよう構成され得る。いくつかの実施形態において、ロジック８１３は、共有メモリ領域を用いて、第１トランジェント関数と第２トランジェント関数との間でデータを交換するよう構成され得る。例えば、ロジック８１３は、コール命令および戻り命令のうち少なくとも１つに交換データを同期するよう構成され得る。いくつかの実施形態において、ロジック８１３は、プロセッサ８１１、メモリ８１２などを含む様々なコンポーネントに、または、それらと同一の位置に（例えば同じダイ上に）配置され得る。
上記のプロセッサ８１１、メモリ８１２、ロジック８１３、およびシステム８１０の他のコンポーネントの各々の実施形態は、ハードウェア、ソフトウェア、またはそれらの任意の適切な組み合わせで実装され得る。例えば、ハードウェア実装は、例えば特定用途向け集積回路（ＡＳＩＣ）、相補型金属酸化物半導体（ＣＭＯＳ）などの回路技術もしくはトランジスタ－トランジスタロジック（ＴＴＬ）技術またはそれらの任意の組み合わせを用いた、例えば、プログラマブルロジックアレイ（ＰＬＡ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、複合プログラマブルロジックデバイス（ＣＰＬＤ）、または、回路技術を用いる固定機能ロジックハードウェアなどの構成可能ロジックを含み得る。
代替的にまたは追加的に、これらのコンポーネントの全部または一部は、１または複数のモジュールにおいて、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のオペレーティングシステム（ＯＳ）適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。例えば、メモリ８１２永続記憶媒体、または他のメモリは、命令セットを格納し得、この命令セットは、プロセッサ８１１によって実行されるとき、システム８１０に、システム８１０の１または複数のコンポーネント、フィーチャ、または態様（例えば、ロジック８１３、メモリ領域の共有、バッファ強化の提供、データの交換など）を実装させる。適切なプロセッサの実施形態は、汎用プロセッサ、特定用途向けプロセッサ、ＣＰＵ、ＧＰＵ、コントローラ、マイクロコントローラ、カーネル、実行ユニットなどを含み得る。
ここで、図８Ｂを参照すると、半導体パッケージ装置８２０の実施形態は、１または複数の基板８２１、および、１または複数の基板８２１に連結されるロジック８２２を含み得、ここで、ロジック８２２は少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数において実装される。１または複数の基板８２１に連結されるロジック８２２は、第１トランジェント関数と、第１トランジェント関数と連携する第２トランジェント関数との間でメモリ領域を共有するよう構成され得る。いくつかの実施形態において、ロジック８２２は更に、ＦａａＳプラットフォームの協調トランジェント関数の間のコア内メッセージ通信のためにバッファ強化を提供するよう構成され得る。いくつかの実施形態において、ロジック８２２は、共有メモリ領域を用いて、第１トランジェント関数と第２トランジェント関数との間でデータを交換するよう構成され得る。例えば、ロジック８２２は、コール命令および戻り命令のうち少なくとも１つに交換データを同期するよう構成され得る。いくつかの実施形態において、１または複数の基板８２１に連結されるロジック８２２は、１または複数の基板８２１内に位置するトランジスタチャネル領域を含み得る。
ロジック８２２および装置８２０の他のコンポーネントの実施形態は、ハードウェア、ソフトウェア、またはハードウェアでの少なくとも部分的な実装を含めた、これら任意の組み合わせにおいて実装されてよい。例えば、ハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。追加的に、これらのコンポーネントの一部は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
装置８２０は、方法８３０（図８Ｃ）の１または複数の態様、または、本明細書において説明される実施形態のいずれかを実装し得る。いくつかの実施形態において、示される装置８２０は、１または複数の基板８２１（例えば、シリコン、サファイア、ヒ化ガリウム）、および、基板８２１に連結されるロジック８２２（例えば、トランジスタアレイ、および、他の集積回路／ＩＣコンポーネント）を含み得る。ロジック８２２は、少なくとも部分的に、構成可能ロジックまたは固定された機能のロジックハードウェアで実装され得る。一例において、ロジック８２２は、基板８２１内に位置する（例えば組み込まれる）トランジスタチャネル領域を含み得る。従って、ロジック８２２と基板８２１との間のインタフェースは、階段接合でないことがあり得る。ロジック８２２はさらに、基板８２１の初期ウェハ上に成長するエピタキシャル層を備えるとみなされ得る。
ここで図８Ｃを参照すると、複数のＦａａＳ関数にわたってメモリを共有する方法８３０の実施形態は、ブロック８３１において第１トランジェント関数にメモリ領域を割り当てる段階、および、ブロック８３２において、第１トランジェント関数と、第１トランジェント関数と連携する第２トランジェント関数との間でメモリ領域を共有する段階を含み得る。方法８３０のいくつかの実施形態は更に、ブロック８３３において、ＦａａＳプラットフォームの協調トランジェント関数の間のコア内メッセージ通信のためにバッファ強化を提供する段階を含み得る。方法８３０は、ブロック８３４において、共有メモリ領域を用いて、第１トランジェント関数と第２トランジェント関数との間でデータを交換する段階を含み得る。例えば、方法８３０は、ブロック８３５において、コール命令および戻り命令のうち少なくとも１つに交換データを同期する段階を含み得る。
方法８３０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法８３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法８３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法８３０は、以下の例８１４から８１７に関連し記載されたコンピュータ可読媒体に実装されてよい。方法８３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
ここで図８Ｄを参照すると、強化ＦａａＳシステム８４０の実施形態は、２つの協調するＦａａＳ関数８４１および８４２（例えば関数ＡおよびＢ）、および、２つのＦａａＳ関数８４１と８４２との間の連携を容易にするよう構成され得る共有メモリ８４３を含み得る。いくつかの実施形態は有利なことに、ＦａａＳ関数８４１と８４２との間のコア内メッセージ／ＪＳＯＮ通信のためのバッファ／ＩＳＡ強化機能を提供し得る。いくつかのＦａａＳアーキテクチャは、ＨＴＴＰを介する関数間通信のためのＪＳＯＮなどの標準データ交換フォーマットを使用し得る。協調するＦａａＳ関数が、スケジューラによって、同一のコア上の同一の位置にあるとき、関数間通信は、ＯＳカーネルおよび他のＨＴＴＰ層を通過する必要はない。いくつかの実施形態において、共有メモリ８４３は、２つの関数の間で交換されたデータのコンテンツをコピーするためのメモリセグメントを２つの関数に共有させることによって、通信の方式を提供し得る。コール先関数が呼び出される直前に、例えば、コール元関数によって渡されたパラメータが、コール元から共有メモリへコピーされ得る。コール先に戻された後に、応答／ＪＳＯＮオブジェクトコンテンツが共有メモリからコール元へコピーされ得る。同期は、コールおよび戻り命令を介して自然に生じ得る。
ここで図８Ｅを参照すると、関数ルックアサイドバッファ（ＦＬＢ）８５０の実施形態は、２つの協調するＦａａＳ関数ｆおよびｇのエントリを含み得る。通信が共有メモリ（例えば、または内部バッファ）を介して生じるべきか、または、従来のＨＴＴＰ／カーネルルーティングを通じて生じるべきかは、コール元がローカルである／近いかどうかをチェックすることによって決定され、次に、そのチェックの値に基づいて分岐し、データをパッキング／コピーするために適切なコードを実行し得る。チェックを高速化するために、ＦＬＢ８５０は、共に同一の位置にある関数のプロセス／ラムダＩＤをキャッシュするために使用され得るトランスレーションルックアサイドバッファ（ＴＬＢ）と同様のハードウェア構造を含み得る。局所性情報は、ページテーブルエントリと同様に関数が移動するにつれて更新され得、キャッシュにおける任意のレジデントエントリは、関数がホストから除去されるときに無効化される。
ここで図８Ｆを参照すると、強化ＦａａＳシステム８６０の実施形態は、２以上のサーバ８６３、８６４および８６５と通信するオーケストレータ８６２を含み得る。関数コードＦ１～Ｆ９は、Ｆ１、Ｆ４、Ｆ５、Ｆ６およびＦ８と連携して、サーバ８６３、８６４および８６５の間で分散され得る。Ｆ４、Ｆ５およびＦ６は同一サーバ８６４上の同一の位置にあるので、いくつかの実施形態は有利なことにサーバ８６４上の共有メモリを利用してＦ４、Ｆ５およびＦ６にわたる連携を促進し得る。いくつかの実施形態は、より良いビンパッキングおよび／または局所性の最適化のため、何の関数が何のサーバで実行しているかについてのグラフベースの表現を利用し得る。いくつかの実施形態はまた、関数間通信パターンの表現に基づくグラフを利用し得る。例えば、ノード間のコールチェーンは、グラフベースの表現として共有され得る。
いくつかの実施形態において、ＯＳは関数コールＡＰＩを関数に公開し得る。例えば、ＡＰＩフレームワークは、利用可能な場合、ネットワーク通信の代わりに、関数コールのためのＯＳ ＡＰＩを使用し得る。有利なことに、ＡＰＩフレームワークは、遠隔コールのためのネットワークと比較して、より効率的なトランスポートを提供し得る。いくつかの実施形態は、１２８ビットアドレスを利用して、すべての関数をグローバルに、リモートダイレクトメモリアクセス（ＲＤＭＡ）をアクセス可能にすることにより、ネットワークを回避し得る。
システム８１０（図８Ａ）、装置８２０（図８Ｂ）、方法８３０（図８Ｃ）、ＦａａＳシステム８４０（図８Ｄ）、ＦＬＢ８５０（図８Ｅ）および／またはＦａａＳシステム８６０（図８Ｆ）の実施形態または態様／フィーチャは、ＦａａＳプラットフォーム１０２（図１）、強化ＦａａＳシステム２０２（図２）、ＦａａＳサーバアーキテクチャ３００（図３）、強化ＦａａＳシステム（図４）および／または強化ＦａａＳシステム（図５）のすべてまたは一部を置換し得る、または、それらに組み込まれ得る。例えば、様々な実施形態のソフトウェアコンポーネント（例えば、関数コード、ロジックの態様など）は、ＦａａＳソフトウェアサブシステム５０６（図５）に組み込まれ得、様々な実施形態のハードウェアコンポーネント（例えば、共有メモリ、ＦＬＢ、ロジックの態様など）は、ＦａａＳハードウェアサブシステム５０８（図５）に組み込まれ得る。
追加の留意点および例
例８００は、実行可能プログラム命令のセットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、プログラム命令は、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１トランジェント関数と、第１トランジェント関数と連携する第２トランジェント関数との間でメモリのメモリ領域を共有させ、１２８ビットアドレスを利用させ、第１および第２トランジェント関数に関数コールインタフェースを公開させ、第１および第２トランジェント関数を含むグラフベースの表現を形成させる。
例８０１は、プロセッサ、プロセッサに通信可能に連結されるメモリ、プロセッサおよびメモリに通信可能に連結されるロジックを含む電子処理システムを含み、第１トランジェント関数と、第１トランジェント関数と連携する第２トランジェント関数との間でメモリのメモリ領域を共有する。
例８０２は例８０１のシステムを含み、ロジックは更に、ファンクションアズアサービスのプラットフォームの協調トランジェント関数間のコア内メッセージ通信のためにバッファ強化を提供する。
例８０３は例８０１～８０２のいずれかのシステムを含み、ロジックは更に、共有メモリ領域を用いて、第１トランジェント関数と第２トランジェント関数との間でデータを交換する。
例８０４は例８０３のシステムを含み、ロジックは更に、コール命令および戻り命令のうち少なくとも１つに交換データを同期させる。
例８０５は、１または複数の基板、および、１または複数の基板に連結されるロジックを含む半導体パッケージ装置を含み、ロジックは少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数に実装され、ロジックは１または複数の基板に連結され、第１トランジェント関数と、第１トランジェント関数と連携する第２トランジェント関数との間でメモリのメモリ領域を共有する。
例８０６は例８０５の装置を含み、ロジックは更に、ファンクションアズアサービスのプラットフォームの協調トランジェント関数間のコア内メッセージ通信のためにバッファ強化を提供する。
例８０７は例８０５から８０６のいずれかの装置を含み、ロジックは更に、共有メモリ領域を用いて、第１トランジェント関数と第２トランジェント関数との間でデータを交換する。
例８０８は例８０７の装置を含み、ロジックは更に、コール命令および戻り命令のうち少なくとも１つに交換データを同期させる。
例８０９は例８０５～８０８のいずれかの例の装置を含み、１または複数の基板に連結されたロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例８１０は、メモリを共有する方法を含み、当該方法は、第１トランジェント関数のためにメモリ領域を割り当てる段階と、第１トランジェント関数と、第１トランジェント関数と連携する第２トランジェント関数との間でメモリのメモリ領域を共有する段階とを含む。
例８１１は例８１０の方法を含み、当該方法は更に、ファンクションアズアサービスのプラットフォームの協調トランジェント関数間のコア内メッセージ通信のためにバッファ強化を提供する段階を含む。
例８１２は例８１０から８１１のいずれかの方法を含み、当該方法は更に、共有メモリ領域を用いて、第１トランジェント関数と第２トランジェント関数との間でデータを交換する段階を含む。
例８１３は例８１２の方法を含み、当該方法は更に、コール命令および戻り命令のうち少なくとも１つに交換データを同期させる段階を含む。
コンテナ投機的実行の例
いくつかの実施形態は有利なことに、コンテナランアヘッド投機的実行を提供し得る。いくつかの関数は、実行を遅くし得る長いレイテンシ／始動を伴う。いくつかの実施形態は、プロセッサ／コアレベルでデータ／命令ストリームをフェッチするための、また、リソースを確保する、および／または、再割り当てするためのランアヘッド実行機構を提供し得る。有利なことに、いくつかの実施形態は、ランアヘッド機能の利点を活用できる関数のレイテンシ／始動を低減し得る。
限定ではなく説明として、ランアヘッドとは、プロセッサが、停止する代わりに、キャッシュミスサイクル中に（例えば投機的に）命令の実行を続けることを可能にする技術を指し得る。投機的実行は、そうでなければアイドル実行リソースを使用することによって生じる前に命令／キャッシュミスを検出することにより命令およびデータストリームプリフェッチを生成するために使用され得る。管理可能なコストは、レジスタファイル状態を保存し、投機的格納がメモリを修正することを防止するために、投機的実行のサポートを提供することを含み得る。
いくつかのＦａａＳ関数は、データベースからのクエリ、他のＦａａＳサービスの呼び出しなど、可変長（例えば、いくらかの長さ）レイテンシオペレーションのブロックを実行することから利益を受け得る。いくつかの実施形態は、プロセッサ／コアレベルでデータ／命令ストリームをフェッチするために、また、リソースを確保する／再割り当てするために、ランアヘッド実行技術を提供し得る（例えば、データベースにアクセスするための帯域幅を確保する、呼び出される可能性があるコンテナ／ＦａａＳ関数をウォームアップする、コンテナ／ＦａａＳ関数を現在の関数のすぐ近くに再配置するなど）。
ＦａａＳ環境においてそのような機能を可能にするために、いくつかの実施形態は、プロセッサレベルでの投機的実行をサポートするためのコピーオンライト技術と、また、外部から可視的なオペレーションを、リソースの確保／再割り当てに適切なマッチするオペレーションに置換するためのランタイムルーチン（例えば、外部関数呼び出し、データベース更新など）とを提供し得る。いくつかの実施形態は、マルチキートータルメモリ暗号化（ＭＫＴＭＥ）を利用して関数にキーをタギングし得る。例えば、いくつかの実施形態は、ＭＫＴＭＥを使用して、フリーの投機的サイドチャネルにＲＤＭＡを提供し得る。
一実施形態において、図８Ａに関連して説明されたものなどの電子処理システムは、ＦａａＳ関連情報をフェッチするためにランアヘッドを行い、フェッチされたＦａａＳ関連情報に基づいて、１または複数の可変長レイテンシオペレーションをブロックするよう構成される。いくつかの実施形態において、電子処理システムは更に、フェッチされたＦａａＳ関連情報に基づいて、リソースの確保および／または再割り当てを行うよう構成され得る。追加的に、または代替的に、電子処理システムは更に、１または複数の外部から可視的なオペレーションを、リソースの確保および再割り当てのうち１または複数に対応する適切なオペレーションに置換するよう構成され得る。いくつかの実施形態において、ロジック、プロセッサ、メモリなどの様々なコンポーネントは、互いの中に、または、互いと同一の位置（例えば同じダイ）に配置され得る。
別の実施形態において、図８Ｂに示される半導体パッケージ装置と同一または同様の半導体パッケージ装置は、１または複数の基板、および、１または複数の基板に連結されるロジックを含み得る。ここで、ロジックは少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数に実装される。１または複数の基板に連結されるロジックは、ＦａａＳ関連情報をフェッチするためにランアヘッドを行い、フェッチされたＦａａＳ関連情報に基づいて１または複数の可変長レイテンシオペレーションをブロックするよう構成され得る。いくつかの実施形態において、ロジックは更に、フェッチされたＦａａＳ関連情報に基づいて、リソースの確保および／または再割り当てを行うよう構成され得る。追加的に、または代替的に、ロジックは更に、１または複数の外部から可視的なオペレーションを、リソースの確保および再割り当てのうち１または複数に対応する適切なオペレーションに置換するよう構成され得る。いくつかの実施形態において、１または複数の基板に連結されるロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含み得る。
ここで図９Ａを参照すると、ファンクションアズアサービスを提供する方法９３０の実施形態は、ブロック９３１において、ＦａａＳ関連情報をフェッチするためにランアヘッドを行う段階と、ブロック９３２において、フェッチされたＦａａＳ関連情報に基づいて、１または複数の可変長レイテンシオペレーションをブロックする段階とを含み得る。方法９３０のいくつかの実施形態は更に、ブロック９３３において、フェッチされたＦａａＳ関連情報に基づいてリソースを確保および／または再割り当てする段階を含み得る。追加的に、または代替的に方法９３０はまた、ブロック９３４において、１または複数の外部から可視的なオペレーションを、リソースの確保および再割り当てのうち１または複数に対応する適切なオペレーションに置換する段階を含み得る。
方法９３０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法９３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法９３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法９３０は、以下の例９１１から９１３に関連し記載されたコンピュータ可読媒体に実装されてよい。方法９３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
ここで図９Ｂを参照すると、強化ＦａａＳシステム９４０の実施形態は、リソースマネージャ９４４に通信可能に連結されるストリームフェッチモジュール９４２を含み得る。ストリームフェッチモジュール９４２は、実行される関数のＦａａＳ関連情報をフェッチするためにランアヘッドを行う技術を含み得る。リソースマネージャ９４４は、フェッチされたＦａａＳ関連情報に基づいて１または複数の可変長レイテンシオペレーションをブロックする技術を含み得る。いくつかの実施形態において、リソースマネージャ９４４は更に、フェッチされたＦａａＳ関連情報に基づいて、リソースの確保および／または再割り当てを行うよう構成され得る。追加的に、または代替的に、リソースマネージャ９４４は更に、１または複数の外部から可視的なオペレーションを、リソースの確保および再割り当てのうち１または複数に対応する適切なオペレーションに置換するよう構成され得る。システム９４０のいくつかの実施形態は有利なことに、（例えばＦａａＳ環境において）コンテナランアヘッド投機的実行を提供し得る。
ここで図９Ｃを参照すると、強化ＦａａＳシステム９５０の実施形態は、いくつかのＦａａＳ関数の投機的実行を含み得る。ユーザ９５１はブラウザ９５２を使用して、複数の画像、例えばｉｍｇ１．ｊｐｇ～ｉｍｇＮ．ｊｐｇなどを含むウェブページ９５４を表示し得る。ユーザ９５１は、ＦａａＳシステム９５０を通じて、画像回転関数９５３を介して、ウェブページ９５４の１または複数の画像を回転し得る。ＦａａＳシステム９５０は、１または複数の画像（例えば、ｉｍｇ１．ｊｐｇ～ｉｍｇＮ．ｊｐｇ）を回転させることユーザのあり得る意図を判定し得、画像を１または複数の代替的なオリエンテーションに投機的に回転し得る。例えば、ＦａａＳシステム９５０は、画像オリエンテーションの利用率のパターン／シーケンスを検出し、より良いユーザ体験および／または性能メトリクスのために、事前に様々な回転関数を起動し得る。投機的実行は、ユーザの観点からの画像を回転するレイテンシを大幅に低減し得る。
システム、装置、方法９３０（図９Ａ）、ＦａａＳシステム９４０（図９Ｂ）、および／またはＦａａＳシステム９５０（図９Ｃ）の実施形態または態様／フィーチャは、ＦａａＳプラットフォーム１０２（図１）、強化ＦａａＳシステム２０２（図２）、ＦａａＳサーバアーキテクチャ３００（図３）、強化ＦａａＳシステム（図４）および／または強化ＦａａＳシステム（図５）のうちすべてまたは一部を置換し得る、または、それらに組み込まれ得る。例えば、様々な実施形態のソフトウェアコンポーネント（例えば、ストリームフェッチャ、リソースマネージャ、関数コード、ロジックの態様など）は、ＦａａＳソフトウェアサブシステム５０６（図５）に組み込まれ得、様々な実施形態のハードウェアコンポーネント（例えば、様々なキュー／バッファ、ロジックの態様など）は、ＦａａＳハードウェアサブシステム５０８（図５）に組み込まれ得る。
追加の留意点および例
例９００は、実行可能プログラム命令のセットを含む少なくとも１つのコンピュータ可読記憶媒体を含む。これらのプログラム命令は、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、少なくとも１つの関数のＦａａＳ関連情報をフェッチするためにランアヘッドを行わせ、フェッチされたＦａａＳ関連情報に基づいて１または複数の可変長レイテンシオペレーションをブロックさせ、マルチキートータルメモリ暗号化を用いて関数にキーをタギングさせ、画像関連情報を検出させ、検出された画像関連情報に基づいて事前に画像オペレーションを起動させる。
例９０１は、プロセッサと、プロセッサに通信可能に連結するメモリと、プロセッサおよびメモリに通信可能に連結するロジックとを含む電子処理システムを含み、少なくとも１つの関数のＦａａＳ関連情報をフェッチするためにランアヘッドを行い、フェッチされたＦａａＳ関連情報に基づいて１または複数の可変長レイテンシオペレーションをブロックする。
例９０２は例９０１のシステムを含み、ロジックは更に、フェッチされたＦａａＳ関連情報に基づいて、リソースの確保および再割り当てのうち１または複数を行う。
例９０３は、例９０１から９０２のいずれかのシステムを含み、ロジックは更に、１または複数の外部に可視的なオペレーションを、リソースの確保および再割り当てのうち１または複数の対応する適切なオペレーションに置換する。
例９０４は、１または複数の基板、および、１または複数の基板に連結されるロジックを含む半導体パッケージ装置を含み、ロジックは少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数に実装され、１または複数の基板に連結されるロジックは、少なくとも１つの関数のＦａａＳ関連情報をフェッチするためにランアヘッドを行い、フェッチされたＦａａＳ関連情報に基づいて、１または複数の可変長レイテンシオペレーションをブロックする。
例９０５は例９０４の装置を含み、ロジックは更に、フェッチされたＦａａＳ関連情報に基づいて、リソースの確保および再割り当てのうち１または複数を行う。
例９０６は、例９０４から９０５のいずれかの装置を含み、ロジックは更に、１または複数の外部に可視的なオペレーションを、リソースの確保および再割り当てのうち１または複数に対応する適切なオペレーションに置換する。
例９０７は例９０４から９０６のいずれかの例の装置を含み、１または複数の基板に連結されたロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例９０８は、ファンクションアズアサービスを提供する方法を含み、方法は、少なくとも１つの関数のＦａａＳ関連情報をフェッチするためにランアヘッドを行う段階と、フェッチされたＦａａＳ関連情報に基づいて１または複数の可変長レイテンシオペレーションをブロックする段階とを含む。
例９０９は例９０８の方法を含み、方法は更に、フェッチされたＦａａＳ関連情報に基づいて、リソースの確保および再割り当てのうち１または複数を行う段階を含む。
例９１０は、例９０８から９０９のいずれかの方法を含み、方法は更に、１または複数の外部に可視的なオペレーションを、リソースの確保および再割り当てのうち１または複数に対応する適切なオペレーションに置換する段階を含む。
プラットフォームフィードバック、マルチバージョン関数、および非同期関数の例
従来のＦａａＳ呼び出しは、関数を呼び出すいくつかの最終トリガを含む複数のトリガを伴い得る。関数が呼び出された後、作業は（例えば新たな始動、ウォームアップなどが行われた）いくつかのコンテナを有するプラットフォームにディスパッチされる。しかし、新たな呼び出しをサポートするために使用されるリソースが少なすぎることがあり得る。累積したレイテンシにより、関数の実行が遅延し得る。従来のトリガ機構は、先行するものから関数呼び出しへ一方向に流れるので、ＦａａＳシステム自身の機能と外部リソースとの間で最適化することが難しくなり得る。いくつかのＦａａＳシステムにおいて、高速化された関数の始動時間は、関数を実行するレイテンシを増加させる。別の問題は、ＦａａＳデータ／動作は、分解されたシステムにわたって同期することが難しいことであり得る。完全に同期した動作は、後続の関数をコールする前に、コール関数がタスクの完了まで待機することを必要とする。コール関数のリソースは待機中に占有される。
強化ＦａａＳシステムのいくつかの実施形態は、関数を実行するプラットフォームから、次の関数呼び出しのためにプラットフォームが準備できたことを示すトリガ機構へのフィードバックを提供し得る。いくつか実施形態はまた、必要なリソース／条件の事前通知を提供し得、いくつかの通知は、そのようなリソースが利用可能になったとき、または、利用可能になると予期されるとき、および、そのような条件が満たされたときにプラットフォームから戻される（例えば、プルまたはプッシュ）。いくつか実施形態はまた、高速化された関数が始動している間に使用され得る高速化された関数の代替的形式を提供することによって、高速化された関数の始動時間を隠し得る。いくつかの実施形態において、いくつかの関数は、サービスチェイニングをサポートするために非同期として識別され得る。有利なことに、いくつかの実施形態は、リソーススタベーションを回避し、リソースのより良い利用率を提供し、および／または、関数実行においてより少ないレイテンシ（例えば、または見かけ上のレイテンシ）を経験し得る。例えば、いくつかの実施形態は、チェイニング関数をディスパッチ（例えば、関数のアトミック性およびモジュール性を高める）した後に、コール関数を解放し得る。
一実施形態において、図８Ａに関連して説明されたものと同一または同様の電子処理システムは、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを含み得、後続の関数呼び出しのためにトリガエージェントからリクエストを受信し、後続の関数呼び出しの準備完了を示すためにフィードバックをトリガエージェントに提供する。代替的に、または追加的に、ロジックは、高速化された関数が始動している間に使用され得る高速化された関数の１または複数の代替的な形式を提供するよう構成され得る。代替的に、または追加的に、ロジックは、サービスチェインをサポートするために、１または複数の関数を非同期として識別するよう構成され得る。いくつかの実施形態において、ロジックは、プロセッサ、メモリなどを含む様々なコンポーネントの中に、または、それらと同一の位置に（例えば、同じダイ上に）配置され得る。
別の実施形態において、図８Ｂに関連して説明されるものと同一または同様の半導体パッケージ装置は、１または複数の基板、および、１または複数の基板に連結されるロジックを含み得る。ここで、ロジックは少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数に実装される。１または複数の基板に連結されるロジックは、後続の関数呼び出しのためにトリガエージェントからリクエストを受信し、後続の関数呼び出しのための準備完了を示ためにフィードバックをトリガエージェントへ提供するよう構成され得る。代替的に、または追加的に、ロジックは、高速化された関数が始動している間に使用され得る高速化された関数の１または複数の代替的な形式を提供するよう構成され得る。代替的に、または追加的に、ロジックは、サービスチェインをサポートするために、１または複数の関数を非同期として識別するよう構成され得る。いくつかの実施形態において、１または複数の基板に連結されるロジックは、１または複数の基板１０２１内に位置するトランジスタチャネル領域を含み得る。
ここで図１０Ａを参照すると、ファンクションアズアサービスを提供する方法１０３０の実施形態は、ブロック１０３１において、後続の関数呼び出しのためにトリガエージェントからリクエストを受信する段階と、ブロック１０３２において、後続の関数呼び出しのための準備完了を示すためにフィードバックをトリガエージェントに提供する段階とを含み得る。代替的に、または追加的に、方法１０３０は、ブロック１０３３において、高速化された関数が始動している間に使用され得る高速化された関数の１または複数の代替的な形式を提供する段階を含み得る。代替的に、または追加的に、方法１０３０は、ブロック１０３４において、サービスチェインをサポートするために１または複数の関数を非同期として識別する段階を含み得る。
方法１０３０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法１０３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法１０３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法１０３０は、以下の例１０１１から１０１３に関連し記載されたコンピュータ可読媒体に実装されてよい。方法１０３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
プラットフォームフィードバックの例
ここで図１０Ｂを参照すると、強化ＦａａＳシステム１０４０の実施形態は、クライアント１０４４に（例えば有線または無線で）通信可能に連結されるＦａａＳプラットフォーム１０４２を含み得る。いくつかの実施形態は、有利なことに、プラットフォームイベントおよびコールバックの際のＦａａＳおよび／またはハードウェア高速化ＦａａＳ（ＡＦａａＳ）動作の基礎となるアーキテクチャサポートを提供し得る。ハードウェア高速化ＦａａＳまたはＡＦａａＳ動作は、ＦＰＧＡ３１８、アクセラレータ３１４、ＧＰＵ、ＳｍａｒｔＮＩＣ３０２などで、図３に示されるＦａａＳサーバ３００において実行され得るものである。例えば、ＦａａＳプラットフォーム１０４２は、後続の関数呼び出しのためのクライアント１０４４からのリクエストを受信し、後続の関数呼び出しのための準備完了を示すためにフィードバックをクライアント１０４４に提供する技術を含むプラットフォームマネージャ１０４６を含み得る。関数がトリガされる（例えば呼び出される）とき、デーモンは例えば、ディスパッチの条件が整っていないことにより、遅延を生じさせ得る（例えば、より良い条件、ＱｏＳの考慮などのためにより長く待機する）。また、整っていない条件は、高需要であることがあり得る限られたリソース状況（例えばストレージ、アクセラレータなど）に関連することがあり得るので、リソースにアクセスするためのキューが存在し得る。制約に起因して、関数は決して実行しないことがあり得る。なぜなら、始動するとき、時間が長くかかりすぎることがあり得るからである（例えば、５分後にタイムアウト）。いくつかの実施形態では、（例えば、プラットフォーム呼び出し元によって実行される）プラットフォームモニタリングを提供し得る、および／または、関数をセグメント／断片に分割し得る。プラットフォームマネージャ１０４６は次に、限られたリソースへのアクセスを必要としない関数の断片を実行し、データを事前にキューイングし、リソースをモニタリングするために仮想関数を始動し、準備ができたときに残りの断片を実行し得る。セグメントに分割された関数を用いて、クライアント１０４４（例えば消費者）は、適切な時間にコールバックを実行し、および／または、リソースが利用可能になるまで関数を一時停止し得る。
いくつかの実施形態は、１）プラットフォームおよび機能が強化されたＦａａＳ動作のサブミッションおよび実行と、２）ＦａａＳ動作の条件、またはイベントフィードバックベース、ジャストインタイム実行を含む、２つの潜在的に独立しているが補足的な機能を提供し得る。いくつかの実施形態は、消費者（例えばクライアント１０４４）がプラットフォームプロバイダをガイドするための、および、プラットフォームプロバイダが様々なプラットフォーム、ネットワークおよび電力条件に基づいて、より連携した、かつ、より情報が多い動作の実行を実現するための柔軟性を提供し得る。
ここで図１０Ｃを参照すると、強化ＦａａＳシステム１０５０における実施形態は、関数セグメンタ１０５１、プラットフォームモニタ１０５２、関数コールバックモジュール１０５３、および、関数一時停止モジュール１０５４を含み得る。例えば、様々なプラットフォーム条件は、プラットフォームモニタ１０５２によってモニタリングされ得、動作を実行するためのリソースが利用可能であり、かつ、プラットフォームが次に説明されるような様々な他の微妙な条件を満たす場合、動作の実際のトリガが実行され得る。微妙なプラットフォーム条件の例は、データへの距離である。例えば、関数に必要なデータセットが、遠いストレージにある場合（例えば、膨大な数のディスクまたはネットワークＩＯオペレーションを必要とする）、そのような微妙なプラットフォーム条件は満たされない。メタスケジューラは、そのような「データへの距離」の条件を満たすべく、データ移行ステップを開始し得、十分なデータが移行されると、動作を進行できる。代替的に、データがあるところ（例えば、リモートノード上）に近くなるよう関数がプッシュされる必要がある場合、微妙な条件は、データの近くで「十分な計算リソースを有する」に変化する。微妙な条件の別の例はコストである。例えば、低コストで実行できる場合だけ関数がトリガされる（例えば、トリガのためのすべての他の条件が満たされていると想定する）ことが好ましいことがあり得る。これは例えば、プラットフォームが電力、ＣＰＵサイクル、メモリ帯域幅などにおいて十分な余剰の容量を有し、したがって、関数がベストエフォートの処理を受けることができ、いくらか自由だが制約のあるレイテンシ内に完了することが予期できる場合に当てはまり得る。換言すると、このアプローチは、効果、効率性、更にはセキュリティの様々な直接的および間接的な指標が満たされることを基礎とした、関数のトリガおよび／または実際のディスパッチを想定する（例えば、セキュリティ基準の例は、セキュリティについてグレイリストされた動作を実行することを許可するべく、プラットフォーム上でセンシティブサービスが実行していないことであり得る）。
ＡＦａａＳについては、特に、ＡＦａａＳが人工知能（ＡＩ）モデルの低強度バックグラウンド訓練を行うために使用される場合に、リソース可用性は、同様にそのようなプラットフォーム条件であり得る。そのようにすることによって、特に、関数が実行される条件自体が第２トリガであるとき、目標は、より決定的な関数の実行を実現することであり得る（例えば、第１トリガは単に、「すべてのロジック状態ベース、または、時間トリガプリカーサが満たされた」という旨であり得る）。事実上、この技術は、明示的かつ系統的に、関数の実行を正しいリソースの可用性、および、関数の予測された需要にリンクし得る。
関数コールバックモジュール１０５３は、消費者（例えば、または消費者のプロキシを務めるソフトウェアエージェント）が、プラットフォームインフラストラクチャからのフィードバックを通じてリクエストする情報を受信および処理するときに、ＦａａＳアクティビティの実際のサブミッションを結びつけることを可能にし得る。例えば、コールバックモジュール１０５３は、常に準備完了（例えば「事前トリガ」）として扱われる特定のメタ関数を利用し得、その結果、コールバックは、コントローラまたは呼び出し元において消費者のプロキシを自然にアクティブ化する。このプロキシは、消費者がジャストインタイムで、ちょうど良いプラットフォーム条件でディスパッチすることを意図する関数の必要なトリガを提供する。
有利なことに、ＦａａＳシステムにおけるモニタリングおよび／またはコールバック技術のいくつかの実施形態は、「ｂｒｉｎｇ ｙｏｕｒ ｏｗｎ ｃａｐａｂｉｌｉｔｉｅｓ」（ＢＹＯＣ）アプローチをサポートし得、これにより、より豊富な連携を実現し、消費者は、ＣＳＰにおいてより少ない他のリソースを待機しながら、ＣＳＰの同意により、いくつかのリソースを事前確保し得、高度なディスパッチを実現する。例えば、いくつかのトランスレーションサービスは、トランスレーションを実行するためにＦａａＳを呼び出す前に、自身のリソース上ですべて準備し得る。ディープニューラルネットワーク（ＤＮＮ）はＦａａＳプラットフォームにとって大きすぎることがあり得るので、消費者はＤＮＮ部分をＣＳＰにおける自身のプリペイドリソースで実行し、次に、ＣＳＰのＦａａＳプラットフォームを使用して、意図する関数の残りを実行し得る。
システム、装置、方法１０３０（図１０Ａ）、ＦａａＳシステム１０４０（図１０Ｂ）、および／またはＦａａＳシステム１０５０（図１０Ｃ）の実施形態または態様／フィーチャは、ＦａａＳプラットフォーム１０２（図１）、強化ＦａａＳシステム２０２（図２）、ＦａａＳサーバアーキテクチャ３００（図３）、強化ＦａａＳシステム（図４）および／または強化ＦａａＳシステム（図５）のうちすべてまたは一部を置換し得る、または、それらに組み込まれ得る。例えば、様々な実施形態のソフトウェアコンポーネント（例えば、プラットフォームマネージャ、関数セグメンタ、プラットフォームモニタリング、コールバックフィーチャ、一時停止フィーチャ、関数コード、ロジックの態様など）は、ＦａａＳソフトウェアサブシステム５０６（図５）に組み込まれ得、様々な実施形態のハードウェアコンポーネント（例えば、様々なキュー／バッファ、ロジックの態様など）は、ＦａａＳハードウェアサブシステム５０８（図５）に組み込まれ得る。
マルチバージョン関数の例
ここで図１１Ａを参照すると、関数１１１０の実施形態は、インスタンス化のための複数の選択肢（例えば、選択肢１～Ｎ）を含み得る。いくつかの実施形態は有利なことに、マルチテナント高速化関数の段階的なマルチバージョンの開始を提供し得る。いくつかのコンテナ（例えば、アクセラレータを使用する、または、コアがマシンに応じて変動するコアを利用するコンテナ）は始動に時間がかかり得る。ソフトウェア関数は、低レイテンシの始動を提供し得るが、実行のレイテンシが長い。ハードウェア関数は、長いレイテンシの始動を提供し得るが、実行のレイテンシが短い。いくつかの実施形態において、関数１１１０は、複数の選択肢を含み得、様々な要素（例えば、呼び出し元要件、ＦａａＳプラットフォーム条件など）に応じて、それらの１つが実行のために選択され得る。
ここで図１１Ｂを参照すると、強化ＦａａＳシステム１１２０の実施形態は、関数Ｂの複数バージョンを有するコードブロックＡをサポートし得る。例えば、コードブロックＡの呼び出し元は、ミニマリストアクセラレータバージョンＢｍ、高アクセラレータバージョンＢｈを含み、アクセラレータバージョンＢｓを含まない関数Ｂの異なるバージョンを識別し得る。コンテナがアクセラレータ（例えば、ミニマリストアクセラレータＢｍ）について始動される場合、いくつかの実施形態は、Ｂ関数の各バージョンをコンテナに移動させ得る。いくつかの実施形態は、新たに到着する関数Ｂの数の減少に基づいて、アクセラレーションコンテナをデグレードし得る（例えば、高アクセラレータＢｈを解放し、ミニマリストバージョンＢｍをウォームアップし、または、ソフトウェア／非アクセラレータバージョンＢｓにシフトする）。いくつかの実施形態は、複数の関数バージョンを、関数Ｂの物理的位置に近いデータのプリフェッチと組み合わせ得る。
いくつか実施形態は有利なことに、新たな高速化された関数を起動するポイントで、予期される小さくない始動レイテンシを隠すような方式で、マルチテナントの状況において高速化された関数を実行し得る。汎用ＣＰＵで実行する呼び出し元については、呼び出しのターゲットは、イニシャライザまたはホストＣＰＵベースコードがコードブロックＡである、いくつかの関数に対応し得、高速化された関数は関数Ｂに対応し得る。Ａが制御を受信するポイントにおいて、Ｂはアクセラレータ上で既に初期化されていることがあり得る、または、Ｂはアクセラレータ上にイメージングされる必要があり得る。
概して、Ｂｈの初期化は、数ミリ秒から数十ミリ秒かかり得る。例えば、ＦＰＧＡリソースは、使用中のアクティブ関数、アイドル関数、および、リクエストされた（例えばキューイングされた）関数の数の間で調停され得る。Ｂｈがアクティブでない場合、Ｂｈのリソースを割り当て、近くまたは遠くのメモリからＢｈのビットストリームをフェッチし、次に、ビットストリームをアクティブ化（例えば起動）するのに、いくらか時間がかかり得る。アクティブ化されると、Ｂｈのビットストリームは、いくらかの時間にわたってアクティブであり続け得、それにより、Ｂｈのリソースが低減され、Ｂｈが回収される前にＢｈが維持される多くのデューティサイクルにわたって、Ｂｈを始動するコストを償却する。このレイテンシを隠すために、いくつかの実施形態は、Ｂｈの複数のバージョンをサポートし得る。これは例えば、２つの追加的、代替的な形式のＢｍおよびＢｓを含み、Ｂｍは、（例えば、空間において実行する代わりに時間においてループを実行するので）始動するために非常に少ない時間をかけるが、実行により長い時間をかけ得るＢｈの最小高速化バージョンに対応し得、Ｂｓは、Ｂのソフトウェア（例えばＣＰＵ）バージョン（例えば、Ｂｈより電力および性能の効率が遥かに低いことがあり得るが、Ｂｓがウォームである場合、ほぼ即時に起動するＢの非高速化バージョン）に対応し得る。
ここで図１１Ｃを参照すると、ファンクションアズアサービスを提供する方法１１３０の実施形態は、ブロック１１３１で、関数の完全バージョンがアクティブかどうか判定し、アクティブである場合、ブロック１１３２で完全バージョンを使用する段階を含み得る。そうでない場合、方法１１３０は、ブロック１１３３で関数の部分的高速化バージョンがアクティブかどうか判定し、アクティブである場合、ブロック１１３４で部分的高速化バージョンを使用し得る。そうでない場合、方法１１３０は、ブロック１１３５で関数のソフトウェア／ＣＰＵバージョンを使用し得る。顧客ニーズ／プラットフォーム条件に応じて、方法１１３０は更に、ブロック１１３６で関数の完全バージョンまたは部分的高速化バージョンを起動する（例えば、および、アクティブになったときにそのバージョンに切り替える）段階を含み得る。
換言すると、コードブロックＡはＢｈを使用し得、Ｂｈは既にアクティブであり（例えば、Ｂのもっとも高速でもっとも効率的な実行）、Ｂｈのセットアップ時間はない。そうでない場合、Ｂｍが既にアクティブである場合（例えば、セットアップ時間がないが実行の期間がより長い）、ＡはＢｍを使用し得る。または、ＢｈおよびＢｍのいずれもアクティブでない場合、ＡはＢｓを使用し得、その後、ＡはＢｍを起動し得る、または、Ｂｈを起動し得、次に、所望のレイテンシ性能‐エリア‐電力のトレードオフに従って、起動されたＢｍまたはＢｓを使用し得る。
いくつかの実施形態ではまず、高頻度であると（例えば履歴プロファイリングを通じて）知られている高速化された関数について、Ｂｍバージョンを事前起動し得る。非高頻度の高速化された関数については、いくつかの実施形態は、これらのミニマルバージョンをオンデマンドで起動し得るが、ＢｍまたはＢｓが既に起動されていない場合、ソフトウェアバージョンＢｓを最初に使用し得る。ＢｓまたはＢｍに対する需要が最近の時間ウィンドウにおいて特定の閾値を超える場合、いくつかの実施形態は、高速化された関数Ｂｈを起動し、Ｂｈが完全にアクティブ化されるまで、ＢのリクエストのためにＢｓまたはＢｍの使用を継続し得る。
いくつかの実施形態はまた、起動されたＢの各々について、移動ウィンドウ利用率、および、コストメトリクスを収集し得る。収集された情報が閾値を下回る場合、または、他の関数に対する需要が上がる場合、いくつかの実施形態は、Ｂｈの回収を開始し、Ｂｍが適切である場合、Ｂｈのリソースを回収するが、Ｂを実行するための新しいリクエストに応じて、その場所でＢｍを起動し得る。対照的に、Ｂの需要が下から閾値を超える場合、いくつかの実施形態は、Ｂｈの起動を開始し、Ｂｈがアクティブ化された後にＢｍがアクティブである場合、Ｂｍを回収し得る。
ＢｍまたはＢｈの起動のための閾値の選択において（例えばそれぞれ、ＢｓまたはＢｍの利用率が増加するとき）、および、ＢｈまたはＢｍを回収するための閾値の選択において（例えばそれぞれ、ＢｈおよびＢｍの利用率が減少するとき）、いくつかの実施形態は、ＡＦａａＳ制御サービスによって動的に提供されるサービス水準合意（ＳＬＡ）入力を考慮し得る。ＳＬＡ入力が提供されない場合、これらの閾値は、Ｂのリクエストの到着率（例えば、または、到着率の移動ウィンドウ平均）に基づいて、ヒューリスティックかつ動的にセットされ得る。
いくつかの実施形態は、ハードウェアにおけるＢｈのコストによって正規化されるデューティサイクル（利用率）の連続モニタリングを利用して、２つの目標、すなわち、１）ｈＢをどれだけ長くアクティブに保持するかを決定すること、および、２）履歴情報を累積することを実現し得、その結果、アクティブ利用率の頻度および期間の履歴をガイドとして使用することによって、Ｂｈの将来のアクティブ化が促進され得る。関数のバージョンのＢｓからＢｍ、Ｂｈへの切り替えのための閾値を決定するために、貪欲ビンパッキングヒューリスティックスが利用され得る。これらの統計値は、Ｂｈのエピログを使用することによって更新され得、Ｂｓ，ＢｍおよびＢｈから選択するためにコードブロックＡの将来のアクティブ化が使用するインメモリ統計値を更新するために使用され得る。
関数１１１０（図１１Ａ）、ＦａａＳシステム１１２０（図１１Ｂ）および／または方法１１３０（図１１Ｃ）の実施形態または態様／フィーチャ、ＦａａＳプラットフォーム１０２（図１）は、強化ＦａａＳシステム２０２（図２）、ＦａａＳサーバアーキテクチャ３００（図３）、強化ＦａａＳシステム（図４）および／または強化ＦａａＳシステム（図５）のすべてまたは一部を置換し得る、または、それらに組み込まれ得る。例えば、様々な実施形態のソフトウェアコンポーネント（例えば、マルチバージョン関数コード、ロジックの態様など）は、ＦａａＳソフトウェアサブシステム５０６（図５）に組み込まれ得、様々な実施形態のハードウェアコンポーネント（例えば、モニタリング、ロジックの態様など）は、ＦａａＳハードウェアサブシステム５０８（図５）に組み込まれ得る。
非同期関数の例
ここで図１２を参照すると、強化ＦａａＳシステム１２１０の実施形態は、イベント、動作、トリガなどのキュー１２１４を有するスケジューラ１２１２を含み得る。いくつかの実施形態は有利なことに、分散された動作の間の効率的な同期を提供し得る。中間動作によってリンクされるチェイニング関数（例えば関数Ｘは、関数Ｙによって使用されるデータを格納するための動作をコールする必要がある）は、いくつかのコールを生じさせ得る。自身が完了したとみなすことができる前にネットワークまたはストレージオペレーションＰを実行し、上のオペレーションＰに起因して、通信される、または、ストレージエリアに格納されるデータを処理するための別の動作Ｙをトリガする必要がある動作Ｘを考慮する。従来のＦａａＳシステムにおいて、例えば、Ｘは、Ｐが格納を完了するのを待機してからＹをコールする必要がある。スケジューラ１２１２は、待機時間中にリソースがＸによって使用される状態で待機する必要があり得る。強化ＦａａＳの解決手段のいくつかの実施形態は有利なことに、動作トリガＰを有し得るので、Ｘによって消費されるリソースを解放するために、Ｘは、動作が完了する前に破棄され得る。また、いくつかの実施形態は、より興味深い並列性（例えばモジュール設計）を可能にし得る。なぜなら、ルート（例えば親関数）が待機する必要がなく、そのため、完了によってトリガされる他の関数は実行を開始し得るからである。いくつかの実施形態は、ハードウェアキューマネージャ（ＨＱＭ）によって実装され得る。
多くの分散動作は、堅牢性にコミットした、または可視性のために通信される状態が、シリアル化可能なオペレーションシーケンスによって更新されるという要件を満たす場合のみ、同期される必要がある。従って、時間は、例えば、これらのオペレーションの結果が堅牢な媒体に記録される、または、第３者に観察される方式で、後方に移動したように見えるべきでない。しかしながら、いくつかの場合において、プロセスの分散型システムにおいてとられるアプローチは保守的すぎることがあり得る。例えば、利用されるプロセスが既にデータ並列性である場合でも、２相ロッキングなどにおいて、すべてのエージェントは障壁を超えて進み得る（例えば、それらは、データのばらばらのパーティションを操作する）。協調ノードのセットの間で実行される必要がある低レイテンシＦａａＳ動作については、そのようなオーバヘッドは、非常に高価であり、不必要な遅延をもたらす。
実際の協調のいくつか、または大部分は、永続性または通信についての状態が更新されて発生する必要があり得るので、強化ＦａａＳの解決手段のいくつかの実施形態は、（例えば、ストレージ関数またはネットワーク関数として）通信およびストレージの様々なペイロードの非同期サブミッションをサポートするために、ファブリックおよび／またはストレージインタフェースを拡張し得る。それにより、データの任意の所与の範囲への更新は、グローバルに一致した時間順序で実行される。従って、２つのオペレーションＸおよびＹが依存チェイニングされることにより、Ｘが共有ディスク上でデータのブロックの非同期更新を実行し、Ｘの完了がＹ（例えば、ＹはＸによる更新を消費し得る（リードアフターライト、またはＲＡＷ依存）、またはそれを上書きし得る（ライトアフターライト、またはＷＡＷ依存））をトリガする場合、「ストレージＦａａＳ動作」のチェイニングのいくつかの実施形態は、要求される順序依存の違反を回避し得る。いくつかの実施形態は、ストレージ動作自体をチェイニングＦａａＳ動作として抽象化し得る。
限定ではなく説明として、分散関数は、関数が共有データ上でｃｌｏｓｅ－ｔｏ－ｏｐｅｎまたはａｃｑｕｉｒｅ－ｔｏ－ｒｅｌｅａｓｅコンシステンシモデルに従い得るという点で、分散処理と異なり得る。（例えば、関数は、有限期間またはｒｕｎ－ｔｏ－ｃｏｍｐｌｅｔｉｏｎモデルを超えるセッション状態のいかなる通知も有しないことがあり得るからである）。Ｘは、Ｘの完了をシグナリングし、Ｙをトリガする（例えば、［Ｘ， Ｐ］ ＝＞ Ｙとして表される）前に、Ｘ内においてＰを同期的に実行する必要がある代わりに、いくつかの実施形態において、１つの関数Ｘは完了し、次に、チェイニングされた動作Ｐ（例えばストレージ、ネットワークなど）を実行（例えばトリガ）でき、Ｐがスケジューリングされて実行されるとき、Ｐの完了が関数Ｙをトリガし得る（例えば、Ｘ ＝＞ ［Ｐ ＝＞ Ｙ］として表される）ことを指定し得る。従来のシーケンス［Ｘ， Ｐ］ ＝＞ Ｙでは、リタイア前に関数Ｘが更新動作Ｐを同期的に実行する（例えば、Ｐを待機する）必要があり、これにより、レイテンシが増加し、潜在的にスケーリングのボトルネックを生じさせる（例えば、ＸがＰを実行するために様々なロックおよびリソースについて競合する必要がある場合）。Ｙ自体はＸに関連し得る。例えば、ＹはＸの継続であり得、Ｐの実行の結果として利用可能となるいくつかのクレデンシャルを必要とし得る。一例として、Ｘは、いくつかのカメラフィードを処理する画像処理タスクであり得、Ｐは画像データベースを更新するタスクであり得、Ｙは、特定のターゲットオブジェクトまたはパターンを含むかどうか確認するために最新の更新を処理する必要があるタスクであり得る。いくつかの実施形態において、タスクＰは、Ｘに対するファイア・アンド・フォーゲットのタスクとみなされ得る。それにより、Ｘに割り当てられたリソースは、Ｐが起動した後に解放され得る。
いくつかの実施形態において、分散型システムにおける、ロックの取得および解放、ならびに、そのような同期および協調のための２相トランザクションを実行することは、高性能ファブリックおよびストレージオペレーション（例えばスマートＮＩＣ、スマートディスクなど）のための非同期コマンドキュー技術と置き換えられ得る。これは特に、プールされたストレージおよびプールされたメモリが、共有されたフラットアクセスパラダイムにおける異なる実行ビークルにおいて使用され得る「ラックスケール設計」またはＲＳＤアーキテクチャにおいて有用であり得る。それにより、ハードウェアベースキュー機構は、ロック、条件などの必要性を回避でき、同時に、より高いレベルのソフトウェアプロトコル（例えば、リーダ‐ライタロック管理、デッドロック検出および解消など）の必要性を回避できる。いくつかの実施形態は、ＨＱＭのような技術を利用し得る。例えば、タスクの実行を管理するために、タスクはＨＱＭに委譲され得る。
システム１２１０（図１２）の実施形態または態様／フィーチャは、ＦａａＳプラットフォーム１０２（図１）、強化ＦａａＳシステム２０２（図２）、ＦａａＳサーバアーキテクチャ３００（図３）、強化ＦａａＳシステム（図４）および／または強化ＦａａＳシステム（図５）のすべてまたは一部を置換し得る、または、それらに組み込まれ得る。例えば、様々な実施形態のソフトウェアコンポーネント（例えば、スケジューラ、関数コード、ロジックの態様など）は、ＦａａＳソフトウェアサブシステム５０６（図５）に組み込まれ得、様々な実施形態のハードウェアコンポーネント（例えば、ＨＱＭ、ロジックの態様など）は、ＦａａＳハードウェアサブシステム５０８（図５）に組み込まれ得る。
追加の留意点および例
例１０００は、実行可能プログラム命令のセットを含む少なくとも１つのコンピュータ可読記憶媒体を含む。実行可能プログラム命令は、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、後続の関数呼び出しのためにトリガエージェントからリクエストを受信させ、後続の関数呼び出しの準備完了を示すためにフィードバックをトリガエージェントに提供させ、マルチテナント高速化関数の段階的なマルチバージョンの開始を提供させ、分散動作の間で同期を提供させ、基準が満たされたときに後続の関数呼び出しをトリガさせる。
例１００１は、電子処理システムを含み、電子処理システムは、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを含み、後続の関数呼び出しのためにトリガエージェントからリクエストを受信し、後続の関数呼び出しの準備完了を示すためにフィードバックをトリガエージェントに提供する。
例１００２は例１００１のシステムを含み、ロジックは更に、高速化された関数が始動する間に使用され得る高速化された関数の１または複数の代替的形式を提供する。
例１００３は例１００１から１００２のいずれかのシステムを含み、ロジックは更に、サービスチェインをサポートするために１または複数の関数を非同期として識別する。
例１００４は、１または複数の基板、および、１または複数の基板に連結されるロジックを含む半導体パッケージ装置を含み、ロジックは少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックの１または複数に実装され、１または複数の基板に連結されるロジックは、後続の関数呼び出しのためにトリガエージェントからリクエストを受信し、後続の関数呼び出しの準備完了を示すためにフィードバックをトリガエージェントに提供する。
例１００５は例１００４の装置を含み、ロジックは更に、高速化された関数が始動する間に使用され得る高速化された関数の１または複数の代替的形式を提供する。
例１００６は例１００４から１００５のいずれかの装置を含み、ロジックは更に、サービスチェインをサポートするために、１または複数の関数を非同期として識別する。
例１００７は例１００４から１００６のいずれかの例の装置を含み、１または複数の基板に連結されたロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例１００８は、ファンクションアズアサービスを提供する方法を含み、方法は、後続の関数呼び出しのためにトリガエージェントからリクエストを受信する段階と、後続の関数呼び出しの準備完了を示すためにフィードバックをトリガエージェントに提供する段階とを含む。
例１００９は例１００８の方法を含み、方法は更に、高速化された関数が始動する間に使用され得る高速化された関数の１または複数の代替的な形式を提供する段階を含む。
例１０１０は、例１００８から１００９のいずれかの方法を含み、方法は更に、サービスチェインをサポートするために１または複数の関数を非同期として識別する段階を含む。
ＦａａＳのための性能強化コンピューティングアーキテクチャ
サーバレス計算は、ＦａａＳおよび非ＦａａＳ関数が同一コンピュートノード上で実行することを可能にし得る。例えば、大量の独立のＦａａＳ関数を、ハイパースレッディングと同様の通常のクラウドアプリケーション（例えば、非ＦａａＳ関数）の間のインタースティス（アイドル期間）に統合することが可能であり得る。インタースティスとは、いずれの場合も、通常のクラウドアプリケーションによって満たされないことがあり得る隙間であり得る。ハイパースレッディングは、追加のスレッドを用いて、コアあたり１つだけのスレッドで完全に実施されないアイドルマイクロアーキテクチャリソースを利用し得る。
従って、例えば、同一のコンピュートノード（例えばサーバまたはプロセッサコア）上で同時に動作するために、ＦａａＳおよび非ＦａａＳ関数は、マルチテナンシーに統合され得る。そのようなマルチテナンシーの状況において、他の共同テナントの性能に悪影響を与え得るノイジーネイバー問題、つまり、クラウドサービスプロバイダ（ＣＳＰ）共同テナントがリソース（例えば、帯域幅、ディスクＩ／Ｏ、ＣＰＵ）を独占するという問題が存在し得る。例えば、非ＦａａＳ関数は、ＦａａＳ関数によってすべての時間において完全にはサブスクライブされていないリソース帯域幅を占有し得、逆もあり得る。これにより、共同テナントの間で不公平なクラウドネットワーク性能を生じさせ、ＦａａＳ関数が実行するレイテンシを増加させる、または、非ＦａａＳ共同テナントの性能を低減させる。現在の既存の解決手段における、仮想マシンまたはコンテナレベルで、キャッシュ容量、メモリ帯域幅またはプロセッサスケジューリング優先度などのリソースを割り当てる、または確保する他の設計と異なり、新しいノイジーネイバー問題は、例えばプロセッサコアレベルで、各コンピュートノード内のリソースの効率的、適合的、細粒度、および、公平な共有に関するので、質的に独自であり得る。
下に説明される実施形態は、これらの統合が表す、はるかに高いレベルのマルチテナンシーにおけるノイジーネイバー問題を回避するために、ＦａａＳ関数および非ＦａａＳ関数の各々をスケジューリングし得る。これにより、待機に起因するレイテンシを低減または安定化させ、タイムアウトエラーに起因する関数の不良を低減させ、実行性能における変動を制御し得る。更に、いくつかの実施形態は、リソース分散を強化し得る。例えば、関数は、関数の実行を強化するために専用ハードウェアアクセラレータを有するノードに提供され得る。
いくつかの実施形態は、スケジューリングを優先化することによって、複数のハードウェアスレッドの間のコア実行リソースの範囲指定割り当てを提供し得る。優先化されたスケジューリングは、共有コア上で同時マルチスレッディング（ＳＭＴ）実行（例えば、ＳＭＴ４、ＳＭＴ８など）のための非競合需要プロファイルを用いて関数をスケジューリングし得、その結果、各関数は、少なくとも関数がもっともセンシティブであるリソースの公平な使用を受け得る。それにより、関数間リソース競合またはノイジーネイバー問題が回避され得る。従って、いくつかの実施形態は、ＳＭＴ（例えば、ＳＭＴ２、ＳＭＴ４）中に、コア実行リソースの効率的、アジャイル、短期間、細粒度範囲指定割り当てに必要な方法およびツール、ならびにフィードバック機構を含み得る。
図１３Ａを参照すると、リソース競合を低減するＦａａＳのための性能強化コンピューティングアーキテクチャ１３００が示される。下記のように、第１～第３関数１３１２、１３１４、１３１６が、実行のために十分な第１～第３リソース割り当て１３２６、１３２８、１３３０を有することを可能にするために、サーバ１３０２は、第１～第３関数１３１２、１３１４、１３１６を分散することによって、リソース競合を低減させ得る。更、いくつかの実施形態において、第１～第３コンピュートノード１３０４ａ－１３０４ｃ上で実行する第４～第６関数１３１８、１３２０、１３２２は、第１～第３関数１３１２、１３１４、１３１６による第１～第３リソースへのアクセスを損なわない第１～第３リソースの割り当て量を有し得る。
最初、効率性強化サーバ１３０２は、コンピューティングデバイス１３０６、１３０８、１３１０から第１～第３関数１３１２、１３１４、１３１６（例えばＦａａＳ関数）のためのリクエストを受信し得る。第１～第３関数１３１２、１３１４、１３１６のリクエストは、コンピューティングデバイス１３０６、１３０８、１３１０上で動作するアプリケーションによって呼び出され得る。サーバ１３０２は、第１～第３関数１３１２、１３１４、１３１６のセンシティブリソースを決定し得る。例えば、第１関数１３１２は、実行のために第１リソースへのアクセスを必要とし得、第２関数１３１４は、実行のために第２リソースへのアクセスを必要とし得、第３関数１３１６は、実行のために第３リソースへのアクセスを必要とし得る。第１～第３リソースは、実行中に第１～第３関数１３１２、１３１４、１３１６によって必要とされる任意のタイプのコンピューティングリソース（例えば、ハードウェアアクセラレータ、帯域幅、算術ロジックユニット、電力、周波数など）であり得、互いに異なり得る。
サーバ１３０２は、ハードウェアリソース割り当てを指令し得、その結果、第１～第３関数１３１２、１３１４、１３１６の各々は、実行のために、センシティブである少なくとも第１～第３リソースの公平な使用を受ける。詳細には、サーバ１３０２は、様々なタイミングで様々なコンピュートノード１３０４ａ－１３０４ｃ上で実行するために第１～第３関数１３１２、１３１４、１３１６をスケジューリングし得、その結果、第１～第３関数１３１２、１３１４、１３１６は、リソース競合なしで第１～第３リソースへのアクセスを有する。例えば、リソース競合を回避するために、サーバ１３０２は、第１関数１３１２を第１コンピュートノード１３０４ａに分散し得、その結果、第１関数１３１２は、実行に十分な第１リソース割り当て１３２６を有する。サーバ１３０２は、第２関数１３１４を第３コンピュートノード１３０４ｃに分散し得、その結果、第２関数１３１４は、実行に十分な第２リソース割り当て１３２８を有する。サーバ１３０２は、第３関数１３１６を第２コンピュートノード１３０４ｂに分散し得、その結果、第３関数１３１６は、実行に十分な第３リソース割り当て１３３０を有する。
実行前に、サーバ１３０２は、第１～第３関数１３１２、１３１４、１３１６によって必要とされる第１～第３リソースを投機的に決定し得る。例えば、サーバ１３０２は、関連する実装（例えば、ソースコード、トランスコード、同様または同一の関数による要件履歴など）を解析することによって、第１～第３関数１３１２、１３１４、１３１６のセンシティブリソースを決定し得る。従って、サーバ１３０２は、関数によって必要とされる必要なリソース割り当て、および／または、関数によって必要とされるリソースのタイプを識別し得、そのようなリソースをセンシティブリソースとしてラベリングし得る。リソースは、電力消費、ファームウェア要件、ハードウェア要件（例えば、帯域幅需要、アクセラレータ、ＣＰＵの命令フェッチにおける利用可能なリソースの数または部分、ＴＬＢ、分岐ターゲットバッファ（ＢＴＢ）、リザベーションステーション、算術ロジックユニット（ＡＬＵ）などのオペレーションポートなど）、またはクロック周波数要件のうち１または複数を含み得る。リソースはまた、異なるマルチテナント条件において性能の変動を制御するために、例えば、ＣＰＵコアがターボ実行に入ることを許可しないなど、超過割り当てに備えて確保され得る。
いくつかの実施形態において、サーバ１３０２は、第１～第３関数１３１２、１３１４、１３１６の各々によって必要とされる１または複数のリソース割り当てが閾値より上かどうかを判定し得る。上である場合、サーバ１３０２は、１または複数のリソースをセンシティブリソースとしてラベリングし得る。閾値は、第１～第３コンピュートノード１３０４ａ－１３０４ｃにおける平均的なリソース可用性履歴に対応し得る。閾値はまた、コンピュートノード１３０４ａ－１３０４ｃの１または複数の各々において、現在のリソース可用性に設定され得る。
サーバ１３０２は更に、投機的に決定された第１～第３リソースに基づいて第１～第３関数１３１２、１３１４、１３１６をスケジューリングし得、コンピュートノード１３０４ａ－１３０４ｃのうち異なるもので、および／または、異なるタイミングで実行し、リソース競合を回避する。従って、サーバ１３０２は、レイテンシを低減し、第１～第３関数１３１２、１３１４、１３１６の完了速度を強化し得る。
例えば、第１関数１３１２は、集約メモリ帯域幅関数を実行し得、従って、第１リソース（すなわちセンシティブリソース）は高帯域幅リソースである。第２関数１３１４は、集約ＡＬＵ計算関数を実行し得、従って、第２リソース（すなわちセンシティブリソース）はＡＬＵリソースであり得る。第３関数１３１６は、電力集約オペレーションを含み得、従って、第３リソース（すなわちセンシティブリソース）は高電力であり得る。
上述のように、サーバ１３０２は、コンピューティングデバイス１３０６、１３０８、１３１０から第１～第３関数１３１２、１３１４、１３１６を実行するためのリクエストを受信し、リソース競合を回避するために第１～第３関数１３１２、１３１４、１３１６を様々なコンピュートノード１３０４ａ－１３０４ｃに分散し得る。いくつかの実施形態において、サーバ１３０２は、コンピュートノード１３０４ａ－１３０４ｃにおいて実行中である第４～第６関数１３１８、１３２０、１３２２（例えば非ＦａａＳ関数）を既にスケジューリング済みであり得る。サーバ１３０２は、第４～第６関数１３１８、１３２０、１３２２の第１～第３リソース割り当て１３３２、１３３４、１３３６を参照することによって、様々な第１～第３コンピュートノード１３０４ａ－１３０４ｃで、第４～第６関数１３１８、１３２０、１３２２によって広く利用されている第１～第３リソースを識別し得る。
サーバ１３０２は、リソース競合を回避するために第１関数１３１２を第１コンピュートノード１３０４ａに分散し得る。詳細には、第１関数１３１２によって必要とされる第１リソースは、第６関数１３２２によって必要とされる第３リソースと異なり、従って、第１関数１３１２と第６関数１３２２との間のリソース競合が回避される。対照的に、第１関数１３１２が第３コンピュートノード１３０４ｃに提供された場合、第１関数１３１２および第４関数１３１８の両方がセンシティブリソースとして第１リソースを必要とするので、リソース競合は存在し得る。
上で説明されたように、第１関数１３１２および第４関数１３１８は、第１リソースの高い割り当てを必要とし、高い割り当ては、第３コンピュートノード１３０４ｃ上の第１リソースの可用性を超え得る。例えば、第１関数１３１２は、第３ノード１３０４ｃにおける限定された量の第１リソースにアクセス可能であり得るが、第１関数１３１２は、第１リソースが既に第１リソース割り当て１３３２によって第４関数１３１８に著しく割り当てられているので、実行を完了するために十分な第１リソースへのアクセスを有しないことがあり得る。同様に、第３関数１３１６は第２コンピュートノード１３０４ｂに提供され、第２関数１３１４は第３コンピュートノード１３０４ｃに提供され得る。
いくつかの実施形態において、サーバ１３０２は、第６関数１３２２が第１コンピュートノード１３０４ａにおいて第１リソースを利用していることを判定し得る。そのようなシナリオにおいて、サーバ１３０２は、第１関数１３１２が実行を完了するために十分な第１リソースへのアクセスを有することになるかどうかを判定し得る。例えば、第６関数１３２２が、少量だけ、および／または第１リソースへのアクセスを割り当てられる場合、第１関数１３１２は、実行を促進することになる第１リソースの割り当てをなお受け得る。
従って、サーバ１３０２は、リソースの可用性に基づいて、関数がセンシティブリソースへのアクセスを有し得るかどうかを判定し得る。例えば、サーバ１３０２は、以下の数式１３００に従って、コンピュートノードにおける利用可能な割り当ての合計を判定し得る。
利用可能な割り当ての合計＝潜在的な割り当ての合計－既存の割り当て
数式１３００
上の数式１３００において、潜在的な割り当ての合計は、コンピュートノードにおけるセンシティブリソースの潜在的な割り当ての合計であり、既存の割り当ては、コンピュートノードにおける、例えば他の関数への、センシティブリソースの現在の割り当てである。サーバ１３０２は、下の数式１３０１に従い、センシティブリソースの十分な割り当てが存在するかどうかを判定し得る。
センシティブリソース要件≦利用可能な割り当ての合計
数式１３０１
センシティブリソース要件は、関数のセンシティブリソース要件である。上記が真である場合、十分な割り当てが存在する。すなわち、センシティブリソース要件は、コンピュートノードにおけるセンシティブリソースの利用可能な割り当ての合計以下である場合、コンピュートノードにおいて関数の実行を完了するのに十分な割り当てが存在する。
いくつかの実施形態において、サーバ１３０２は、第４～第６関数１３１８、１３２０、１３２２への第１～第３リソース割り当て１３３２、１３３４、１３３６を低減し、それらの第１～第３リソースを第１～第３関数１３１２、１３１４、１３１６に割り当て得、その結果、センシティブリソースが公平に分散される。例えば、いくつかの実施形態において、サーバ１３０２は、第１関数１３１２を第１コンピュートノード１３０４ａではなく第３コンピュートノード１３０４ｃに分散し得る。第１関数１３１２および第４関数１３１８の両方は、センシティブリソースとして第１リソースを必要とするので、リソース競合があり得る。リソース競合を低減するために、サーバ１３０２は、第４関数１３１８への第１リソース割り当て１３３２を低減し、第１関数１３１２への第１リソース割り当て１３２６を増加させ得る。それにより、第４関数１３１８と第１関数１３１２との間で第１リソースの公平な割り当てを確立し得る。
いくつかの実施形態において、サーバ１３０２は、リソース競合を回避するために、第１～第３関数１３１２、１３１４、１３１６のタイミングをスケジューリングし得る。例えば、いくつかの実施形態において、サーバ１３０２は、第１関数１３１２を第３コンピュートノード１３０４ｃに提供し得る。上記のように、第１関数１３１２および第４関数１３１８の両方は、センシティブリソースとして第１リソースを必要とするので、リソース競合があり得る。リソース競合を回避するべく、サーバ１３０２は、第１関数１３１２をスケジューリングして、第４関数１３１８の実行完了後、第３コンピュートノード１３０４ｃ上で実行し得る。それにより、第１関数１３１２と第４関数１３１８との間で第１リソースのリソース競合を回避し得る。
いくつかの実施形態において、サーバ１３０２は、ハードウェアアクセラレータを決定し得る、および／または、ＦＰＧＡは、関数１３１２、１３１４、１３１６の１つの実行を強化し得る。サーバ１３０２は、ハードウェアアクセラレータへのアクセスを有するように関数１３１２、１３１４、１３１６の１つを適宜スケジューリングし得る。
いくつかの実施形態において、コンピュートノード１３０４ａ－１３０４ｃは、プロセッサコア、コンピューティングデバイスまたはサーバであり得る。いくつかの実施形態において、コンピューティングデバイス１３０６、１３０８、１３１０は、遠隔サーバ（不図示）上で実行するアプリケーションを呼び出し得、当該遠隔サーバは次に、関数１３１２、１３１４、１３１６のリクエストをサーバ１３０２に提供する。いくつかの実施形態において、サーバ１３０２は、関数１３１２、１３１４、１３１６を呼び出し得る。コンピューティングデバイス１３０６、１３０８、１３１０は例えば、ラップトップ、モバイルデバイス、サーバ、デスクトップなどを含み得る。いくつかの実施形態において、サーバ１３０２は、第１～第３コンピュートノード１３０４ａ－１３０４ｃを含み得る。更に、いくつかの実施形態において、サーバ１３０２は、上記の態様を実装する図４の、オーケストレータ４０４などの強化ＦａａＳシステム４００を含み得る。
図１３Ｂは、図１３Ａのサーバ１３０２によって実装され得る、より公平なビンパッキングのための強化スケジューリングプロセス１３３８を示す。例えば、関数０および１が同一コンピュートノードで同時に動作する場合、サーバ１３０２は、関数０および１を投機的に解析し、関数０および１に割り当てられた、予測されるサイクルあたり命令数（ＩＰＣ）リソース１３４０、１３４２を識別し得る。関数１は例えば、非ＦａａＳ関数であり得、関数０はＦａａＳ関数であり得る。上記のように、関数１は、関数０と比較して、不公平に高い量のリソース１３４０、１３４２を割り当てられ得る。例えば、関数１が関数０の前にオペレーションを開始する場合、関数１は不公平なリソース割り当てを有し得る。
従って、矢印１３４４に示されるように、関数０および１のスケジューリングは、より公平なビンパッキングに修正され得、および／または、異なる時間に、または、異なるノードにスケジューリングされ得、および／または、より高いＩＰＣのために必要とされるハードウェアリソースの間で公平性（例えば、等しい量）を確立するために、ハードウェアリソースは再分散され得る。従って、関数０は、関数１に割り当てられるリソース１３４８の量によって実現されるＩＰＣと等しいＩＰＣを実現する量のリソース１３４６を割り当てられ得る。図には示されないが、電力および周波数の割り当ても、修正によって関数０と関数１との間でより公平に割り当てられ得る。
図１３Ｃは、ＣＳＰ環境におけるスケジューリング関数の方法１３５０を示し、図１３Ａのサーバ１３０２、および／または、図４のオーケストレータ４０４などの強化ＦａａＳシステム４００によって実行され得る。方法１３５０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせに格納されるロジック命令セットとして実装され得る。
例えば、方法１３５０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック１３５２は、複数の関数のそれぞれの関数各々について、それぞれの関数を実行するのに必要な１または複数のセンシティブリソースを判定することを含み得る。示される処理ブロック１３５４は、第１関数の１または複数のセンシティブリソースと第２関数の１または複数のセンシティブリソースとの間のリソース競合を判定することを含み得る。示される処理ブロック１３５６は、リソース競合を回避するために、第１または第２関数のうち１または複数をスケジューリングすることを含み得る。例えば、示される処理ブロック１３５６は、公平性を確立してサービス品質を維持するために、第１または第２関数のうち１または複数をスケジューリングして、同一ノード上で完全な非重複時間において実行する、互いに異なるノード上で実行する、および／または、１つの関数から別の関数へリソースの割り当てを再分散することを含み得る。示される処理ブロック１３５８は、センシティブリソースの１または複数を第１および第２関数にスケジューリングし、それぞれ第１および第２関数のために目標の性能量を実現することを含み得る。例えば、示される処理ブロック１３５８はセンシティブリソースを第１および第２関数に割り当てることを含み得る。図には示されないが、方法１３５０は、第１関数の１または複数のセンシティブリソースと、第３関数の１または複数のセンシティブリソースとの間のリソース競合が無いことを判定することを含み得る。方法１３５０は、リソース競合が無いことに基づいて、第１および第３関数をスケジューリングして、重複時間において同一ノードで実行する段階を含み得る。
方法１３５０は、ＣＳＰ環境の効率性およびオペレーションを強化し得る。例えば方法１３５０は、レイテンシを低減し、関数の完了速度を強化し得る。
追加の留意点および例
例１３００は、命令セットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、複数の関数のそれぞれの関数各々について、それぞれの関数を実行するのに必要な１または複数のセンシティブリソースを判定させ、複数の関数における第１関数の１または複数のセンシティブリソースと複数の関数における第２関数の１または複数のセンシティブリソースとの間のリソース競合を判定させ、リソース競合を回避するために第１関数または第２関数のうち１または複数をスケジューリングさせ、異なる時間に実行するために第１および第２関数をスケジューリングさせ、異なるコンピュートノードで実行するために第１および第２関数をスケジューリングさせ、複数の関数における第１関数の１または複数のセンシティブリソースと第３関数の１または複数のセンシティブリソースとの間のリソース競合が無いことを判定させ、重複時間において同一ノード上で実行するために第１および第３関数をスケジューリングさせ、第１および第２関数それぞれについて目標の性能量を実現するためにセンシティブリソースの１または複数を第１および第２関数にスケジューリングさせる。
例１３０１は、命令セットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、複数の関数のそれぞれの関数各々について、それぞれの関数を実行するのに必要な１または複数のセンシティブリソースを判定させ、複数の関数における第１関数の１または複数のセンシティブリソースと、複数の関数における第２関数の１または複数のセンシティブリソースとの間のリソース競合を判定させ、リソース競合を回避するために、第１関数または第２関数のうち１または複数をスケジューリングさせる。
例１３０２は、更なる命令セットを含む例１３０１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、異なる時間に実行するために第１および第２関数をスケジューリングさせる。
例１３０３は、更なる命令セットを含む例１３０１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、異なるコンピュートノード上で実行するために第１および第２関数をスケジューリングさせる。
例１３０４は、更なる命令セットを含む例１３０１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、複数の関数における第１関数の１または複数のセンシティブリソースと、第３関数の１または複数のセンシティブリソースとの間のリソース競合が無いことを判定させ、重複時間に同一ノード上で実行するために第１および第３関数をスケジューリングさせる。
例１３０５は、命令セットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、複数の関数のそれぞれの関数各々について、それぞれの関数を実行するのに必要な１または複数のセンシティブリソースを判定させ、複数の関数における第１関数の１または複数のセンシティブリソースと、複数の関数における第２関数の１または複数のセンシティブリソースとの間のリソース競合を判定させ、第１および第２関数それぞれについて目標性能量を実現するためにセンシティブリソースの１または複数を第１および第２関数にスケジューリングさせる。
ＦａａＳのための強化された関数実行
図１４Ａおよび図１４Ｂは、いくつかの実施形態による強化された関数実行シーケンス１４００を示す。そのような例は、図１３Ａのサーバ１３０２、例えば、第１～第３コンピュートノード１３０４ａ－１３０４ｃのうち１または複数、および／または、図４のオーケストレータ４０４などの強化ＦａａＳシステム４００によって実装され得る。より具体的には、関数コール１４０２は、実行する関数１４０４をリクエストし得る。関数１４０４は、サーバレス関数（例えば、単一ＦａａＳ関数）であり得る。関数１４０４は、何らかの順序で実行可能な内部オペレーションの集合として見られ得る。オペレーションは、全部の関数のうち一部を達成する関数１４０４内におけるモジュールの実行であり得る。例えば、関数１４０４は条件のセットに従ってデータベーステーブルからいくつかの数のタプルを選択し、次に、所望の順序で出力を生成するために結果をソートする、または、ソートされた出力から更にサブセレクトする必要があると想定する。その例において、選択およびソートは、関数１４０４内部の２つのオペレーションである。内部オペレーションは、「ファンクレット（ｆｕｎｃｌｅｔ）」と呼ばれ得る。
分解プロシージャ１４０６は、関数１４０４をアトミックユニットと扱って関数１４０４を提示されたように実行する代わりに、例えばトランスコード、または、モジュールが関数１４０４のコード本体からコールされる静的解析を通じて、関数１４０４を一連のファンクレット１４０８ａ－１４０８ｅに分解し得る。関数と異なり、ファンクレット１４０８ａ－１４０８ｅは、効率的な計算および協調のために、互いの間で変動するレベルの状態を共有し得る。個々のファンクレット１４０８ａ－１４０８ｅは、レイテンシを低減し、より効率的にリソースを管理するために、個々のスケジューリングを経て、プロセス１４１０を実行し得る。詳細には、ファンクレット１４０８ａ－１４０８ｅのいくつかは、レイテンシを低減するために同時に実行し得る。更に、ファンクレット１４０８ａ－１４０８ｅの特定のファンクレットが、実行のために専用ハードウェア（例えばアクセラレータまたはＦＰＧＡ）またはファームウェアなどのリソースを必要とする場合、リソース利用およびスケジューリングを強化するために専用ハードウェアが利用可能になるまで、ファンクレット１４０８ａ－１４０８ｅのうち特定のファンクレット実行が遅延する可能性があり得る。
示されるように、関数１４０４は、ファンクレット１４０８ａ－１４０８ｅから成る依存性グラフ１４１４に分解され得る。ここで、依存性グラフ１４１４は、ファンクレット１４０８ａ－１４０８ｅの実行順序を示す。依存性グラフ１４１４において、ファンクレット１４０８ａは最初に実行し得る。ファンクレット１４０８ｂ、１４０８ｃは、ファンクレット１４０８ａからの情報に基づいて実行し、同時に実行し得る。ファンクレット１４０８ｄは、ファンクレット１４０８ｂ、１４０８ｃの後に、ファンクレット１４０８ｂ、１４０８ｃの両方からの情報に基づいて動作し得る。ファンクレット１４０８ｅは、ファンクレット１４０８ｄの後に、ファンクレット１４０８ｄからの情報に基づいて実行し、関数１４０４の実行を完了し得る。
スケジューリングおよび実行プロシージャ１４１０は、依存性グラフ１４１４に基づいて動作し、ファンクレット１４０８ａ－１４０８ｅの各々を個別にスケジューリングし得る。例えば、依存性グラフ１４１４に基づいて、ファンクレット１４０８ａ－１４０８ｅの間の相互接続はクリアである。従って、スケジューリングおよび実行プロシージャ１４１０は、依存性グラフ１４１４の依存性相互接続に基づいて、ファンクレット１４０８ａ－１４０８ｅを同時に（並列に）スケジューリングするか、または、順に（次々に）スケジューリングするかを判定し得る。
図１４Ｂのスケジュールグラフ１４１６に示されるように、ファンクレット１４０８ａ－１４０８ｅは、タイミングＴ０～Ｔ４の間の様々な時間スロット中に、および、様々なコンピュートノード１４１２ａ－１４１２ｃにおいて動作するように、スケジューリングおよび実行プロシージャ１４１０によってスケジューリングされ得る。ファンクレット１４０８ａは、時間Ｔ０～Ｔ１の間にコンピュートノード１４１２ａ上で実行するようスケジューリングされ得る。他のファンクレット１４０８ｂ－１４０８ｅは、ファンクレット１４０８ａからのデータを必要とし、他のファンクレット１４０８のいずれも、時間Ｔ０～Ｔ１中に実行しないことがあり得る。
ファンクレット１４０８ａが実行を完了した後に、ファンクレット１４０８ｂ、１４０８ｃは、時間Ｔ１～Ｔ２の間にコンピュートノード１４１２ａ、１４１２ｂの両方で実行し得る。依存性グラフ１４１４に示されるように、ファンクレット１４０８ｂ、１４０８ｃは、同時に実行し得る。なぜなら、ファンクレット１４０８ｂ、１４０８ｃの両方は、ファンクレット１４０８ａからの情報のみ必要とし、ファンクレット１４０８ｄ、１４０８ｅからの情報を必要としないからである。従って、スケジュールグラフ１４１６において、ファンクレット１４０８ｂ、１４０８ｃは、異なるコンピュートノード１４１２ａ、１４１２ｂで同時に実行する。いくつかの実施形態において、コンピュートノード１４１２ａ－１４１２ｃの１つが、ファンクレット１４０８ｂ、１４０８ｃの両方をサポートするのに十分なリソースを有する場合、ファンクレット１４０８ｂ、１４０８ｃの両方は、コンピュートノード１４１２ａ－１４１２ｃの１つで実行するようスケジューリングされ得る。
ファンクレット１４０８ｂ、１４０８ｃが実行を完了した後に、ファンクレット１４０８ｄは、時間Ｔ２～Ｔ３中にコンピュートノード１４１２ｃ上で実行し得る。ファンクレット１４０８ｄの実行は、コンピュートノード１４１２ｃ上にあるハードウェアアクセラレータおよび／またはＦＰＧＡを通じて強化され得る。従って、スケジューリングおよび実行プロシージャ１４１０は更に、ハードウェアリソースなどのリソースがファンクレット１４０８ａ－１４０８ｅの１つの実行を強化し得るかどうか考慮し、ファンクレット１４０８ａ－１４０８ｅの１つを適宜スケジューリングし得る。更に、依存性グラフ１４１４に示されるように、ファンクレット１４０８ｄは、実行のために、ファンクレット１４０８ｂ、１４０８ｃからのデータを必要とするが、ファンクレット１４０８ｅからのデータを必要としないことが得、従って、ファンクレット１４０８ｂ、１４０８ｃの実行完了後にスケジューリングされる。
ファンクレット１４０８ｄが実行を完了した後に、ファンクレット１４０８ｅは、時間Ｔ３～Ｔ４中にコンピュートノード１４１２ｃ上で実行し得る。リソースの効率性は、ファンクレット１４０８ｅをコンピュートノード１４１２ｃ上で実行させることによって強化され得る。すなわち、ファンクレット１４０８ｅは、ファンクレット１４０８ｄからのデータを必要とし得るので、ファンクレット１４０８ｅは、コンピュートノード１４１２ａ－１４１２ｃの間のデータ転送を最小化するために、ファンクレット１４０８ｄと同一ノード上で実行するようにスケジューリングされ、メモリおよびキャッシュ利用率を強化し得る。従って、スケジューリングおよび実行プロシージャ１４１０は、ファンクレット１４０８ａ－１４０８ｅの強化されたスケジューリングを通じて、データ転送を最小化し、キャッシュ再使用を強化することによって、リソース利用を更に強化し得る。
いくつかの実施形態において、ファンクレット１４０８ａ－１４０８ｅの１または複数は、ファンクレット１４０８ａ－１４０８ｅに必要なリソースが利用可能になったとき、再生成状態から後の時間に実行され得る。例えば、ファンクレット１４０８ｄが実行のためにハードウェアアクセラレータを必要とすると想定する。ハードウェアアクセラレータが利用可能であると識別されたことに応じて、ファンクレット１４０８ｄは実行するようスケジューリングされ得る。ファンクレット１４０８ｄの実行は、ファンクレット１４０８ｂ、１４０８ｃの実行完了のある期間後に発生し得る。すなわち、ファンクレット１４０８ｄは、ファンクレット１４０８ｂ、１４０８ｃの実行が完了したすぐ後に実行を開始するよう自動的にトリガされないことがあり得る。むしろ、ファンクレット１４０８ｄはファンクレット１４０８ｂ、１４０８ｃの実行が完了したことに加えて、ハードウェアアクセラレータが利用可能になったときに実行するようスケジューリングされ得る。
関数１４０４をファンクレット１４０８ａ－１４０８ｅに分割することにより、関数１４０４の不良の可能性が低減され得る。例えば、いくつかの実施形態において、関数１４０４のオペレーションのいくつかは、上述のファンクレット１４０８ｄなどの特定のハードウェアを必要とし得る。関数１４０４がハードウェアを待機する必要がある場合、タイムアウトエラーが発生し得る。すなわち、関数１４０４は、予め定められた時間制限の前に完了することに失敗し、従って、破棄される。
関数１４０４を一連の個々のファンクレット１４０８ａ－１４０８ｅに分割することにより、そのようなタイムアウトエラーは、より良く回避され得る。なぜなら、ファンクレット１４０８ａ－１４０８ｅは、リソースが利用可能になったときだけ動作するように、個別にスケジューリングされ得るからである。つまり、関数１４０４は、リソースが利用可能になるまで、ファンクレット１４０８ａ－１４０８の開始を待機することによって、ファンクレット１４０８ａ－１４０８ｅの間で「一時停止」され得る。上述のように、ファンクレット１４０８ｄは、実行を開始して、次に、ハードウェアアクセラレータが利用可能になるまで待機するのではなく、ハードウェアアクセラレータが利用可能になったときに実行するようスケジューリングされ得る。
更に、分解プロシージャ１４０６、ならびに、スケジューリングおよび実行プロシージャ１４１０は、関数１４０４より細かい粒度である、ファンクレット１４０８ａ－１４０８ｅレベルの粒度でリソースを取得および解放することによって、実行全体を強化するための機会を提供し得る。更に、特定用途向けハードウェアアクセラレータ上で高速化され得るファンクレット１４０８ｄなどのファンクレットを、従来またはＣＰＵベースのソフトウェア実行により良く適合するもの、例えばファンクレット１４０８ａ－１４０８ｃおよび１４０８ｅと混合することが可能であり得る。
更に、実施形態は、関数１４０４の単純なフロー実行を可能にする。すなわち、依存性グラフ１４１４に示されるように、関数１４０４は、順序に従って、より小さいファンクレット１４０８ａ－１４０８ｅに分解される。スケジューリングおよび実行プロシージャ１４１４に実装されるスケジューリングアルゴリズムは、ファンクレット順序を維持しながら、日和見的スケジューリングのために、利用可能なリソース／実行、または、リソースに対する他の競合するニーズの優先度をモニタリングし得る。更に、開発者は、強化された関数実行シーケンス１４００に気づかないことがあり得る。これにより、開発者のタスクが単純化され得る。なぜなら、プロセスがＣＳＰ側で不透明に実行されるので、開発者は、サブ関数を識別する必要はないからである。
上記のように、ファンクレット１４０８ａ－１４０８ｅは、依存性グラフ１４１４によって説明される順序依存性に従って実行プラットフォームにプロビジョニングされ得る。アーキテクチャサポートは、アドレス空間境界内で、または、それをまたいで同時アクティビティとしてスケジューリングされ得るファンクレット１４０８ａ－１４０８ｅについて、依存性グラフ１４１４における正確な順序依存性を保証するために提供され得、ユーザレベル割込み（ＵＬＩ）、ハードウェアキューマネージャ、リモートアトミクス（ＲＡＯ）などを拡張する技術を使用する、効率的なロジックバリアおよびイベント協調のサポートを含む。ファンクレット１４０８ａ－１４０８ｅはまた、上記と同様に実行される「ミニファンクレット」と呼ばれる、より小さいユニットに分解され得る。
強化された関数実行シーケンス１４００は、１または複数のハードウェアキューマネージャによって協調され得る。複数のハードウェアキューマネージャは、ファンクレット１４０８ａ－１４０８ｅをスケジューリングおよびキューイングし得る。ハードウェアキューマネージャは異なるノード上にあり得るが、依存性グラフ１４１４の実行の順序で、ファンクレット１４０８ａ－１４０８ｅのキューを維持し、適宜スケジューリングし得る。
強化された関数実行シーケンス１４００は更に、上述のように図１３Ａのサーバ１３０２によって実装され得るが、またはサーバ１３０２と連携して、図４のオーケストレータ４０４などの強化ＦａａＳシステム４００および／または１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、強化された関数実行シーケンス１４００に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
例として、関数が短い音声ファイルを解析することを含むと想定する。短い音声ファイルの解析は、音声ファイルをテキストに変換（書き写し）すること、異なる参加者によって話された単語および／または文を認識して分割すること、および、書き写し文の発話者のアイデンティティを特定することを含む複数のファンクレット（すなわち、構成要素となるオペレーション）に分解され得る。強化された関数実行シーケンス１４００に関連して、関数を上記のように分解することによって、関数の部分的な実行が実現されるので、ファンクレットのいくつかは、特定量のリソースを有する利用可能な時間に完了する。従って、関数をファンクレットに分解することにより、実行が強化され、リソース利用が低減し、レイテンシが低減し得る。
図１４Ｃは、ＣＳＰ環境において複数のオペレーションを有する関数をスケジューリングする方法１４５０を示し、図１３Ａのサーバ１３０２によって実行され得るが、または、サーバ１３０２と連携して、図４のオーケストレータ４０４などの強化ＦａａＳシステム４００および／または１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、方法１４５０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック１４５２は、関数のオペレーション（すなわちファンクレット）を決定し得る。示される処理ブロック１４５４は、オペレーションの命令を決定し得る。例えば、上述のように、命令は、オペレーションが同時に、または、順に実行し得るかどうかを決定することを含み得る。示される処理ブロック１４５６は、決定された順序に基づいて、オペレーションを個別にスケジューリングし得る。例えば、第１オペレーションは、他のオペレーションが第１オペレーションからのデータに依存する場合、他のオペレーションの前にスケジューリングされ得る。示される処理ブロック１４５６は更に、第１コンピュートノードで実行するために、第１オペレーションをスケジューリングし、第１コンピュートノードと異なる第２コンピュートノードで実行するために第２オペレーションをスケジューリングし得る。従って、第１および第２関数のレイテンシを低減するために、同時スケジューリング、または、異なるハードウェア（例えば専用および／または非専用）の使用が促進され得る。
示される処理ブロック１４５６はまた、第１の時間に第１オペレーションをスケジューリングし、第１の時間と異なる第２の時間に第２オペレーションをスケジューリングし得る。従って、第１および第２関数のシリアル実行が実装され得る。更に、示される処理ブロック１４５６は、リソース割り当て（例えば専用ハードウェアアクセラレータおよび／またはＦＰＧＡ）が利用可能であるという識別、および、第１オペレーションが完了したという識別の両方に応じて実行を開始するように、第２オペレーションをスケジューリングし得る。そのような実施形態において、方法１４５０は更に、リソース割り当てが利用可能になるまで、第２オペレーションの実行を意図的に遅延させる段階を含み得る。更に、第２オペレーションは、第１オペレーションからの出力を必要とし得る。
方法１４５０は、ＣＳＰ環境の効率性およびオペレーションを強化し得る。例えば、方法１４５０は、レイテンシを低減し、リソース利用を強化し、関数の完了速度を強化し得る。
追加の留意点および例
例１４００は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数のオペレーションを決定させ、オペレーションの順序を決定させ、決定された順序に基づいてオペレーションを個別にスケジューリングさせ、第１コンピュートノードで実行するために第１オペレーションをスケジューリングさせ、第２コンピュートノードで実行するために第２オペレーションをスケジューリングさせ、第１の時間に第１オペレーションをスケジューリングさせ、第１の時間とは異なる第２の時間に第２オペレーションをスケジューリングさせ、リソース割り当てが利用可能であるという識別、および、第１オペレーションが完了したという識別の両方に応じて実行を開始するように第２オペレーションをスケジューリングさせ、リソース割り当てが利用可能になるまで第２オペレーションの実行を遅延させ、ここで、第２オペレーションは、第１オペレーションから出力を受信することである。
例１４０１は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数のオペレーションを決定させ、オペレーションの順序を決定させ、決定された順序に基づいてオペレーションを個別にスケジューリングさせる。
例１４０２は、更なる命令セットを含む、例１４０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１コンピュートノードで実行するよう第１オペレーションをスケジューリングさせ、第２コンピュートノードで実行するよう第２オペレーションをスケジューリングさせる。
例１４０３は、更なる命令セットを含む、例１４０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１の時間にオペレーションのうちの第１オペレーションをスケジューリングさせ、第１の時間とは異なる第２の時間にオペレーションのうちの第２オペレーションをスケジューリングさせる。
例１４０４は、更なる命令セットを含む、例１４０３の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、リソース割り当てが利用可能であるという識別、および、第１オペレーションが完了したという識別の両方に応じて、実行を開始するよう第２オペレーションをスケジューリングさせる。
例１４０５は、更なる命令セットを含む、例１４０４の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、リソース割り当てが利用可能になるまで第２オペレーションの実行を遅延させる。
例１４０６は、例１４０３の少なくとも１つのコンピュータ可読媒体を含み、第２オペレーションは、第１オペレーションから出力を受信する。
ＦａａＳのための強化されたメモリ割り当て
図１５Ａは、いくつかの実施形態による、性能およびメモリストレージが強化されたコンピューティングアーキテクチャ１５００を示す。そのような例は、図１３Ａのサーバ１３０２、例えば、第１～第３コンピュートノード１３０４ａ－１３０４ｃ、および／または、図４のオーケストレータ４０４などの強化ＦａａＳシステム４００のうち１または複数によって実装され得る。
性能およびメモリストレージが強化されたコンピューティングアーキテクチャは、コンテナ１５０２および関数１５０４を含む。関数１５０４は、コンテナ１５０２と連携して動作し得る。例えば、関数１５０４はコンテナ１５０２にロードされ得る。いくつかの実施形態において、関数１５０４はコンテナ１５０４にダウンロードおよびインスタンス化され得る。プラットフォームオペレーティングシステム１５０６は、コンテナ１５０２および関数１５０４をホスティングし、コンテナ１５０２および関数１５０４のデータを格納するためにメモリ１５１０と連携して動作し得る。
示されるようにプラットフォームオペレーティングシステム１５０６は、専用メモリコンテナリスト１５２４および専用関数メモリリスト１５２６を含み得る。専用コンテナメモリリスト１５２４および専用関数メモリリスト１５２６は、関数１５０４および／またはコンテナ１５０２の専用であるメモリ１５１０のアドレス範囲を識別するデータ構造、アレイ、またはルックアップテーブルであり得る。例えば、専用コンテナメモリリスト１５２４はベースコンテナメモリ空間１５２０ａ－１５２０ｃを識別する。専用関数メモリリスト１５２６は関数メモリ空間１５２２ａ、１５２２ｂを識別する。示されるように、メモリ１５１０は、未割り当てメモリ空間１５３０も含み得る。
メモリ割り当てリクエストがプラットフォームオペレーティングシステム１５０６によって受信される場合、プラットフォームオペレーティングシステム１５０６は、関数１５０４またはコンテナ１５０２がメモリ割り当てリクエストの元であるかどうかを判定し得る。コンテナ１５０２がメモリ割り当てリクエストの元である場合、メモリ割り当ては、専用コンテナメモリリスト１５２４に基づいて提供され得る。例えば、メモリ割り当ては、専用コンテナメモリリスト１５２４によって識別されるメモリ範囲の割り当てであり得る。従って、コンテナ１５０２は、プラットフォームオペレーティングシステム１５０６から受信されたメモリ割り当てに基づいて、データをベースコンテナメモリ空間１５２０ａ－１５２０ｃに格納し、書き込み得る。従って、コンテナ１５０２は、ベースコンテナメモリ空間１５２０ａ－１５２０ｃを通じて、標準的な信頼済みメモリ部分を用いてプロビジョニングされ得る。
対照的に、関数１５０４がメモリ割り当てリクエストの元である場合、メモリ割り当ては、専用関数メモリリスト１５２６に基づいて提供され得る。例えば、メモリ割り当ては、専用関数メモリリスト１５２６によって識別されるメモリ範囲の割り当てであり得る。従って、関数１５０４は、関数メモリ空間１５２２ａ、１５２２ｂにデータを格納し、書き込み得る。
したがって、コンテナ１５０２のコンテナ固有データ、および、関数１５０４のみによって使用される関数固有データは、異なるベースコンテナ、および、関数メモリ空間１５２０ａ－１５２０ｃ、１５２２ａ、１５２２ｂに格納され得る。コンテナ固有データは、多くの異なる関数によって再利用可能であり得、関数１５０４の実行中に関数１５０４によって変更されないことがあり得る。
関数１５０４が例えば、実行の完了またはエラーによって終了すると、関数メモリ空間１５２２ａ、１５２２ｂに格納された関数固有データは消去され得る。ベースコンテナメモリ空間１５２０ａ－１５２０ｃに格納されたコンテナ固有データは、関数１５０４が実行を完了したとき消去されないことがあり得る。したがって、関数１５０４が終了し、もはや実行しなくなったときでも、コンテナ１５０２は、実行のために別の関数を受信する半ウォーム状態での準備を維持する。従って、関数１５０４が終了するときに消去されるデータの制限によって、コンテナ１５０２の全体の解体が回避され得る。関数１５０４が関数メモリ空間１５２２ａ、１５２２ｂだけにデータを格納することにより、コンテナ１５０２の状態から関数１５０４によってもたらされる変化のみが除去され得、それにより、コンテナ１５０２は、半ウォーム状態に維持され、信頼済みコードがベースコンテナメモリ空間１５２０ａ－１５２０ｃに格納される。したがって、関数固有データとコンテナ固有データとにデータを分割し、適宜格納することにより、関数１５０４に関連するデータの削除が促進され得、セキュリティを強化し、高レイテンシのコールドコンテナ始動を低減する。
詳細には、様々なコンテナタイプについて、コンテナ１５０２を終了および再始動するためのオーバヘッドは非常に大きく、レイテンシを増加させ得る。例えば、コンテナ１５０２がニューラルネットワーク（例えば畳み込みニューラルネットワークまたはディープニューラルネットワーク）用である場合、コンテナ１５０２を終了してから再びスピンアップすることは高価であり得る。これは、ニューラルネットワークが、動作するために著しい量のデータロード（例えばニューラル加重および／または定数値）を含むからであり得る。そのようなデータロードは、コンテナ１５０２の一部であり得る。なぜなら、データロードは異なる関数によって再使用され得、関数によって変更できないからである。従って、関数１５０４でエラーが生じた場合、コンテナ１５０２は強制的に終了され、再びスピンアップされ得、レイテンシが増加し効率性が低減する。
コンピューティングアーキテクチャ１５００は、関数１５０４の終了プロセスを強化し得る。例えば、関数１５０４でエラーが生じる場合、プラットフォームオペレーティングシステム１５０６は、終了されるデータの範囲を制限し得る。すなわち、関数メモリ空間１５２２ａ、１５２２ｂに格納されるデータだけが消去または割り当て解除され得る。従って、関数１５０４によってもたらされる変化のみが、コンテナ１５０２の状態から除去され、コンテナ１５０２全体の解体が回避される。示されるように、プラットフォームオペレーティングシステム１５０６はコンテナ１５０２に対し、コンテナ１５０２において実行する関数１５０４のために割り当てられ使用される関数メモリ空間１５２２ａ、１５２２ｂと、コンテナ１５０２自体のために割り当てられ使用されるベースコンテナメモリ空間１５２０ａ－１５２０ｃとを含む２つの異なるセットのリソースを維持する能力を提供する。
更に、関数１５０４の終了後、関数１５０４のセンシティブデータが消去されるのでセキュリティが強化される。例えば、関数１５０４に固有のセンシティブデータは、関数メモリ空間１５２２ａ、１５２２ｂから消去され得る。
プラットフォームオペレーティングシステム１５０６は、仮想マシンモニタ（不図示）、および、コンテナ１５０２または関数１５０４のうち１または複数によって使用されるライブラリと連携して動作し得る。プラットフォームオペレーティングシステム１５０６、仮想マシンモニタ、およびライブラリのうち１または複数は、メモリ割り当てコール（例えばｍａｌｌｏｃまたはｃａｌｌｏｃなど）が、コンテナ１５０２の一部としてホワイトリストされるコード範囲、または、コンテナ１５０２を実行する既知の有効な主体に由来するかどうかを判定する機構を実装し得る。メモリ割り当てコールが、ホワイトリストされたコード範囲、または、コンテナ１５０２の既知の有効な主体に由来する場合、メモリ割り当てコールに、ベースコンテナメモリ空間１５２０ａ－１５２０ｃからのメモリ範囲が提供される。そうでない場合、デフォルトで、メモリ割り当てコールは関数１５０４のコードに由来すると想定され、次に、関数メモリ空間１５２２ａ、１５２２ｂからのメモリ範囲を与えられる。専用関数メモリ範囲は「一時的」範囲とみなされ得る。
例えば、セグメンテーション違反の結果、クリーンアップまたは解体ループを実行する必要がある場合、ベースコンテナメモリ空間１５２０ａ－１５２０ｃを解体するのではなく、関数１５０２の関数メモリ空間１５２２ａ、１５２２ｂだけが解体される。例えば、専用コンテナメモリリスト１５２４は、コンテナ１５０２によって利用されるすべての割り当てられたメモリ空間のリストを含み得る。同様に、専用関数メモリリスト１５２６は、関数１５０４によって利用されるすべての割り当てられたメモリ空間のリストを含み得る。クリーンアップ中、関数１５０４に割り当てられたメモリ空間は、解体および消去され得、コンテナ１５０２に割り当てられたメモリ空間は変化しない。
更に、メモリ割り当てコールの任意のタイプ、例えば、Ｐｏｒｔａｂｌｅ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ Ｃｏｍｐｌｉａｎｔ Ｕｎｉｘ（登録商標） （ＰＯＳＩＸ）システムコール（例えば、ｍｍａｐ（）コール）または動的メモリ割り当てコール（例えば、ｍａｌｌｏｃ、ｃａｌｌｏｃなど）は、上記のように識別され、適切に命令され得る。例えば、ｍｍａｐ（）コールが関数１５０４から受信される場合、マッピングのために提供された仮想メモリ範囲は、専用関数メモリリスト１５２６に基づいて提供され得る。従って、専用関数メモリリスト１５２６は、仮想メモリ範囲の識別を含み得る。従って、そのような仮想メモリ範囲、および、任意の関連する物理メモリ範囲のみが回収される必要があり得る。
更に、ファイル記述子も同様に処理され得る。例えば、「ｏｐｅｎ（）」コマンドについては、プラットフォームオペレーティングシステム１５０６は、専用コンテナメモリリスト１５２４および専用関数メモリリスト１５２６における２つの異なるグループのファイル記述子を維持し得る。専用コンテナメモリリスト１５２４および関連するベースコンテナメモリ空間１５２０ａ－１５２０ｃにおけるファイル記述子は、異常条件、または、関数１５０４の終了の際に、終了または閉じられる必要はない（しかし、再開始、再生成または再起動、および再初期化される必要があり得る）。専用関数メモリリスト１５２６におけるファイル記述子、および、関連する関数メモリ空間１５２２ａ、１５２２ｂは、異常な条件、または、関数１５０４の終了の際、常に閉じられ得る。
例えば、不正な命令またはセグメンテーション違反によって生じるトラップに起因して、関数１５０４が終了する場合、コンテナ１５０２自体が強制終了することなく、コンテナ１５０２は、関数１５０４のためにクリーンアップを実行し得る。上述のように、プラットフォームオペレーティングシステム１５０６、ソフトウェアライブラリ、および仮想マシンモニタのうち１または複数は、関数１５０４の解体を促進し得る。
いくつかの実施形態において、プラットフォームオペレーティングシステム１５０６および／またはコンテナ１５０２は、関数１５０４に加えて、コンテナ１５０２を解体し得る。すなわち、コンテナ１５０２がエラーを引き起こしていると識別された場合、ベースコンテナメモリ空間１５２０ａ－１５２０ｃは消去され得る。例えば、コンテナ１５０２のホワイトリストされた主体内からの実行であるコードの結果、終了条件（不正命令エラーなど）が発生した場合、関数１５０４に加えて、プロセスまたはコンテナ１５０２は解体されるべきである。いくつかの実施形態において、予め定められた時間にわたってコンテナ１５０２が関数によって使用されないままである場合、コンテナ１５０２は解体され得る。
いくつかの実施形態において、（例えばエラーによって）完了前に関数１５０４が終了する場合、コンテナ１５０２において特別なエントリポイントが定義され得る。エントリポイントは、関数１５０４が解体され、関数メモリ空間１５２２ａ、１５２２ｂが割り当て解除された後、実行がベクトル化される場所である。再エントリポイントは、コンテナ１５０２が、ウォーム始動中に関数の起動を実行するポイントであり得る。例えば、再エントリポイントは、コンテナ１５０２が完全に初期化され、関数１５０４の処理を開始する準備ができる起動ポイントであり得る。この再エントリポイントへのベクトル化は、その起動ポイントに対する「ｌｏｎｇｊｍｐコール」と同等であり得る。
適切な割り当ておよび割り当て解除を促進するために、様々な調整がコマンドまたはライブラリインタフェースに行われ得る。例えば、「ｂａｃｋｔｒａｃｅ」コマンドは通常、様々な割り当ての由来を判定するのに必要であるが、様々な割り当てのための２つの異なるエントリポイント、および「オープンコール」を有することによって回避され得る。例えば、１つのエントリポイントは、ホワイトリストされたコードのみにリンクされ、他のエントリポイントは、関数１５０４のコードのデフォルトである。「ｍｍａｐ（）（仮想範囲を提供する必要がある）」、「ｏｐｅｎ（）（ファイル記述子、ｓｏｃｋｅｔ（）などを割り当てる）」などの他のタイプのプロビジョニングコールについて、コマンドの同様の分岐が行われ得る。各場合において、ホワイトリストされたコードは、通常の方式で割り当てされるコードにリンクされ、非ホワイトリストコードは、専用関数メモリリスト１５２６を介してリソースを関数メモリ空間１５２２ａ、１５２２ｂに隔離する、または、開かれたファイル記述子、ソケットなどを、エラー時に自動で解放される／自動で閉じられる必要がある関数１５０４に関連付けられるデータとしてトラッキングするパスを通ると想定され得る。
従って、強化コンピューティングアーキテクチャ１５００は、コンテナの解体の制限、および、コールドコンテナの初期化の限定を含む、いくつかの強化を含み得、それにより、コストを低減する。更に、強化コンピューティングアーキテクチャ１５００は、コンテナの解体および再生成に利用される帯域幅および電力が少ないので、リソースの利用率の効率性を強化し得る。更に、強化コンピューティングアーキテクチャ１５００は、半ウォーム状態からのコンテナの始動がより速いこと、および、関数の終了およびエラーのオーバヘッドがより少ないことに起因してレイテンシが少ない。また、関数メモリ空間１５２２ａ、１５２２ｂから関数固有データを除去することによってセキュリティが強化され得る。
図１５Ｂは、関数およびコンテナのためのメモリ割り当ての方法１５５０を示し、図１３Ａのサーバ１３０２によって実行され得るが、または、サーバ１３０２と連携して、図４の強化ＦａａＳシステム４００および／または１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、方法１５５０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック１５５２は１または複数のコンテナメモリ空間をコンテナに割り当て得る。示される処理ブロック１５５４は、１または複数の関数メモリ空間を、コンテナに関連する関数に割り当て得る。示される処理ブロック１５５６はメモリ割り当てリクエストを受信し得る。示される処理ブロック１５５８は、メモリ割り当てリクエストがコンテナに由来するか、または、関数に由来するかを決定し得る。示される処理ブロック１５６０は、メモリ割り当てリクエストがコンテナに由来するか、または関数に由来するかに基づいて、１または複数のコンテナメモリ空間または１または複数の関数メモリ空間からのメモリ割り当てを提供し得る。例えば、メモリ割り当てリクエストがコンテナに由来する場合、メモリ割り当ては１または複数のコンテナメモリ空間からのものであり得る。対照的に、メモリ割り当てリクエストが関数に由来する場合、メモリ割り当ては１または複数の関数メモリ空間から提供され得る。
更に、コンテナが動作するためのデータだけが１または複数のコンテナメモリ空間に格納され得る。更に、関数固有データは１または複数の関数メモリ空間だけに格納される。
示される処理ブロック１５６２は、関数が終了したという識別に応じ、１または複数のコンテナメモリ空間からのメモリを割り当て解除することなく、１または複数の関数メモリ空間からメモリを割り当て解除し得る。図には示されないが、方法は更に、別の関数を実行のためにコンテナにロードする段階を含み得る。従って、方法１５５０は、コンテナの解体の制限、および、コールドコンテナの初期化の限定を含む、いくつかの強化を含み得、それにより、コストを低減する。更に、方法１５５０は、コンテナの解体および再生成に利用される帯域幅および電力が少ないので、リソースの利用率の効率性を強化し得る。更に、方法１５５０は、半ウォーム状態からのコンテナの始動がより速いこと、および、関数の終了およびエラーのオーバヘッドがより少ないことに起因してレイテンシが少ないことがあり得る。
追加の留意点および例
例１５００は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、１または複数のコンテナメモリ空間をコンテナに割り当てさせ、１または複数の関数メモリ空間を、コンテナに関連する関数に割り当てさせ、メモリ割り当てリクエストを受信させ、メモリ割り当てリクエストがコンテナに由来するか、または関数に由来するかを判定させ、メモリ割り当てリクエストがコンテナに由来する場合、１または複数のコンテナメモリ空間からのメモリ割り当てを提供させ、メモリ割り当てリクエストが関数に由来する場合、１または複数の関数メモリ空間からのメモリ割り当てを提供させ、関数が終了したという識別に応じ、１または複数のコンテナメモリ空間からのメモリの割り当て解除を行うことなく、１または複数の関数メモリ空間からメモリを割り当て解除させ、ここで、コンテナが動作するためのデータのみが１または複数のコンテナメモリ空間に格納され、関数固有データは、１または複数の関数メモリ空間のみに格納され、１または複数のコンテナメモリ空間は、ファイル記述子またはソケット記述子のうち１または複数を格納するためのものである。
例１５０１は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに１または複数のコンテナメモリ空間をコンテナに割り当てさせ、１または複数の関数メモリ空間を、コンテナに関連する関数に割り当てさせる。
例１５０２は、更なる命令セットを含む、例１５０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、メモリ割り当てリクエストを受信させ、メモリ割り当てリクエストがコンテナに由来するか、または関数に由来するかを判定させ、メモリ割り当てリクエストがコンテナに由来するか、または関数に由来するかに基づいて、１または複数のコンテナメモリ空間、または、１または複数の関数メモリ空間からのメモリ割り当てを提供させる。
例１５０３は、更なる命令セットを含む、例１５０２の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、メモリ割り当てリクエストがコンテナに由来する場合、１または複数のコンテナメモリ空間からのメモリ割り当てを提供させる。
例１５０４は、更なる命令セットを含む、例１５０２の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、メモリ割り当てリクエストが関数に由来する場合、１または複数の関数メモリ空間からのメモリ割り当てを提供させる。
例１５０５は、例１５０１の少なくとも１つのコンピュータ可読媒体を含み、コンテナが動作するためのデータのみが１または複数のコンテナメモリ空間に格納され、関数固有データは１または複数の関数メモリ空間のみに格納される。
例１５０６は、更なる命令セットを含む、例１５０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数が終了したという識別に応じて、１または複数のコンテナメモリ空間からのメモリの割り当て解除を行うことなく、１または複数の関数メモリ空間からメモリを割り当て解除させる。
例１５０７は、例１５０６の少なくとも１つのコンピュータ可読媒体を含み、１または複数のコンテナメモリ空間は、ファイル記述子またはソケット記述子のうち１または複数を格納するためのものである。
ウォームおよびコールドコンテナの関数の分散
関数は、ウォームコンテナとコールドコンテナとの間のランダムな分散を有し得る。本明細書において既に説明されたように、コールドコンテナを初期化するためのレイテンシ時間は小さくないことがあり得る。したがって、コールドコンテナへの関数の分散は、より高いレイテンシを有し得る。なぜなら、コールドコンテナは、例えばプロビジョニングされることによって初期化される必要があり、次に、関数が実行する必要があるからである。対照的に、ウォームコンテナに分散される関数は、より低いレイテンシを有し得る。なぜなら、コールドコンテナの初期化が回避され得るからである。
従来のスケジューリングは、関数を分散するときのコールドコンテナの初期化のためのレイテンシ時間、または、コールドコンテナの初期化をどのように最小化するかを考慮しないことがあり得る。更に、いくつかのスケジューリングは、ウォームコンテナとコールドコンテナとの間の関数の非効率な分散を有し得、より高いリソース利用、および、より高いレイテンシの実行をもたらす。
ここで図１６Ａを参照すると、関数リクエスト１６０４がＦａａＳシステム、例えば、図４のＦａａＳシステム４００の呼び出し元およびバッチバランサ１６０６によってスケジューリングされる例１６００が示される。呼び出し元およびバッチバランサ１６０６は、レイテンシを低減し、リソース利用を強化するために、バッチ実装を実装し得る。例えば、いくつかの実施形態は、各々がバッチ可能関数の実行をリクエストする第１～第Ｎのバッチ可能関数リクエスト１６０８ａ－１６０８ｎを識別し得る。第１～第Ｎのバッチ可能関数リクエスト１６０８ａ－１６０８ｎは、まとめてバッチされ、予期してスケジューリングされ得、その結果、バッチ可能関数は、異なるコンテナではなく同一のコンテナ１６１４ａにおいて実行する。従って、コールドコンテナの初期化は、レイテンシを低減し少ないコンテナを利用するためにバッチ可能関数のバッチ実行によって低減され得る。
更に、呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４に関連する特定の関数のレイテンシの制約を識別し、レイテンシの制約を満たすために関数リクエスト１６０４を分散し得る。レイテンシの制約は、関数が実行を完了すべき、リクエストされたタイミングに対応し得る。例えば、レイテンシの制約が許可するとき、より短いレイテンシの関数は、まとめてグループ化され得る。また、いくつかの実施形態は、コールドコンテナの初期化がバッチ可能関数を処理するのに必要かどうかを判定し、必要である場合、レイテンシの制約が満たされるかどうかを識別するとき、コールドコンテナの初期化のレイテンシ時間を考慮し得る。
従って、いくつかの実施形態は、リソース利用を低減するために、関数のより有効な分散を有しつつ、コールドコンテナの初期化を制限し得る。例えば、関数を実行するために、複数の新しいコールドコンテナを初期化することに比べて、同一のコンテナ内において複数の関数を実行することは、よりリソース効率が高いことがあり得る。更に、バッチ関数は、コンテナの共有に起因して、レイテンシコストの増加を有するにも関わらず、コールドコンテナの初期化が低減され得るので、バッチ関数の全体的なレイテンシは、実際にはより少ないことがあり得る。従って、いくつかの実施形態は、関数がまとめてバッチされる場合でも、強化されたウォームコンテナ利用率に起因して、より低いレイテンシを有し得る。
更に、上述のように、リソース管理は強化され得る。例えば、ウォームコンテナは、特定の量のアイドル時間の後に解体され得る。アイドル時間は、ウォームコンテナがいかなる関数も処理しない時間であり得る。本明細書において説明されるように、バッチ実装を通じて、ウォームコンテナがより多く利用されるようにすることで、より頻繁にウォームコンテナが使用されるように維持するので、実施形態では、コンテナの構築が少なくなり（すなわち、コールドコンテナの初期化）、ウォームコンテナの解体が少なくなり得る。更に、いくつかの実施形態では、リソースを消費する同一のコンテナのインスタンスが少なくなり得る。例えば、各関数についてコンテナを有するのではなく１つのコンテナが複数の関数にサービスを提供し得る。従って、実施形態は、コストを低減するために、効率性を強化し、より少ないリソースを利用する。従って、第１～第Ｎのバッチ可能関数リクエスト１６０８ａ－１６０８ｎが突然かつ不定期のバーストにおいて発生する場合でも、コールドコンテナのペナルティが回避され、コンテナの構築および解体に対する強化ＦａａＳシステムの制御を増加することを可能にし得る。
更に、ロードバランシングコストが低減され得る。例えば、関数のバッチをまとめてスケジューリングすることとは対照的に、オーケストレータによる各関数の個別スケジューリングは、より大きい計算リソースを必要とし得る。更に、各関数リクエストについて個々のメッセージが送信されるのではなく、第１～第Ｎのバッチ関数リクエスト１６０８ａ－１６０８ｎのすべてを含むバッチ関数リクエストメッセージが送信され得るので、メッセージングオーバヘッドは低減され得る。
例１６００に示されるように、関数リクエスト１６０４は、ＦａａＳシステムの呼び出し元およびバッチバランサ１６０６、例えば図４のＦａａＳシステム４００によってスケジューリングされる。呼び出し元およびバッチバランサ１６０６は、オーケストレータ４０４の一部であり得る、または、オーケストレータ４０４と連携して動作し得る。
図１６Ａに示されるように、ＡＰＩプロキシ１６０２を処理するイベントは、イベントコールを、関数リクエスト１６０４に関連する関数にルーティングし得る。１６００の例において、ＡＰＩプロキシ１６０２は、例えばＡＰＩを介して関数リクエスト１６０４を生成し得る。関数リクエスト１６０４は、呼び出し元およびバッチバランサ１６０６に提供され得る。関数リクエスト１６０６は各々、それぞれの関数を実行するためのリクエストであり得る。
呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４がバッチされ得るかどうかを識別するために関数リクエスト１６０４を解析し得る。詳細には、呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４の関数がコンテナ１６１４ａ－１６１４ｃの同一のコンテナにおいて実行し得るかどうかを決定し得る。コンテナ１６１４ａ－１６１４ｃの同一のコンテナにおいて実行し得る関数はまとめてバッチされ得る。いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は、同一の関数がまとめてバッチ可能であると判定し得る。更に、非同一の関数がコンテナ１６１４ａ－１６１４ｃのうち同一のものにおいて実行し得る場合、呼び出し元およびバッチバランサ１６０６は、非同一の関数がまとめてバッチ可能であると判定し得る。
呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４から非バッチ可能関数リクエスト１６１０、１６１２を識別し得る。非バッチ可能関数リクエスト１６１０、１６１２は、他の関数とグループ化できない非バッチ可能関数をリクエストし得、従って、非バッチ可能とみなされる。非バッチ可能関数リクエスト１６１０、１６１２は、個別にコンテナ１６１４ｂ、１６１４ｃへ送信され得る。すなわち、非バッチ可能関数は、別個のコンテナ１６１４ｂ、１６１４ｃで実行し得る。コンテナ１６１４ｂ、１６１４ｃは、ウォームまたはコールドであり得、優先度は、もっとも強いレイテンシ制約を有する非バッチ可能関数リクエスト１６１４ｂ、１６１４ｃの非バッチ可能関数リクエストに与えられる。
示されるように、呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４から第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎを識別し得る。説明されるように、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎの各々は、同一のコンテナ内において実行するよう構成される関数（バッチ可能関数と呼ばれ得る）を呼び出し得る。従って、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎは、コンテナ１６１４ａへ送信され得る。バッチ可能関数はコンテナ１６１４ａ内で実行し得る。第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎは、１より大きい任意の数の関数リクエストを含み得る。
いくつかの実施形態において、コンテナ１６１４ａが同時実行をサポートするのに十分なリソースを有する場合、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎに関連するバッチ可能関数は、コンテナ１６１４ａにおいて同時に実行し得る。例えば、呼び出し元およびバッチバランサ１６０６は、バッチ可能関数の各々のリソース要件を判定し、コンテナ１６１４ａが、リソース要件のすべてを満たすのに十分なリソースへのアクセスを有するかどうかを判定し得る。有する場合、同時実行がスケジューリングされ得る。有しない場合、同時実行はサポートされないことがあり得、バッチ可能関数は順に（次々に）実行され得る。
いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は、バッチ可能関数のセキュリティプロトコルを決定し得る。図１５Ａ、図１５Ｂ、および、上の関連する説明に関連して説明されたように、特定のバッチ可能関数が特定のセキュリティ要件（例えば高セキュリティ）を有することをセキュリティプロトコルが示す場合、特定のバッチ可能関数は、コンテナ１６１４ａにおいて非同時実行のためにスケジューリングされ、コンテナ１６１４ａのデータが維持されたまま特定のバッチ可能関数のデータだけが除去されるコンテナ１６１４ａの限定された解体を実行し得る。
いくつかの実施形態において、バッチ可能関数のいくつかは、同時に実行され得、他のバッチ可能関数は順に実行され得る。いくつかの実施形態において、コンテナ１６１４ａは、第１グループのバッチ可能関数、例えば、コンテナ１６１４ａのリソースによってサポートされ得る最大数のバッチ可能関数を実行し得る。第１グループの実行完了後、第２グループのバッチ可能関数、例えば、コンテナ１６１４ａのリソースによってサポートされ得る最大数のバッチ可能関数が実行を開始し得る。従って、呼び出し元およびバッチバランサ１６０６は、関数のリソース要件に対する、コンテナ１６１４ａのセキュリティプロトコルおよびリソース可用性に基づいて、コンテナ１６１４ａにおけるバッチ可能関数のハイブリッドの直列および並列実行をスケジューリングし得る。
いくつかの実施形態において、コンテナ１６１４ａは、並列に実行するバッチ可能関数を分離するために、パーティショニングされた作業空間を含み得る。各関数は異なるパーティションにおいて実行し得る。パーティションのすべては、バッチ可能関数のいずれかによって利用され得る共通データへのアクセスを有し得る。パーティションは、関数に固有のデータを保護するために、別個のメモリ空間を有し得る。そのために、各パーティションは、関数によって使用される共通データにアクセスしつつ、別個のメモリ空間において関数によって生成されたデータを保存し得る。関数がパーティションにおいて実行を完了した後に、対応する別個のメモリ空間からのデータは、別のデータストレージに保存され得（必要な場合）、別の関数のためのパーティションを準備するために、別個のメモリ空間は消去される。しかしながら、共通データは、実行中に関数によって変更されないことがあり得、コンテナ１６１４ａにおいて実行する各関数によって再利用可能である
いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は関数リクエスト１６０４を累積し得る。例えば、関数リクエスト１６０４は各々、異なる時間に呼び出し元およびバッチバランサ１６０６へ送信され得る。呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４が一定期間にわたって累積することを可能にし得る。すなわち、呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４が受信されたとき、それらを即座にスケジューリングしないことがあり得る。むしろ、呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４をスケジューリングする前に待機し得る。それにより、呼び出し元およびバッチバランサ１６０６が、複数の潜在的なバッチ可能関数リクエスト１６０４が受信され、次に、関数リクエスト１６０４がまとめてバッチ可能かどうかに基づいてスケジューリングされることを可能にすることと可能にし得る。
いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は、関数リクエスト１６０４の各々のレイテンシの制約を決定し、関連する関数を適宜スケジューリングし得る。例えば、非バッチ可能関数リクエスト１６１０は強いレイテンシの制約を有し得る。すなわち、関連するレイテンシの制約に起因して、非バッチ可能関数リクエスト１６１０は、対応する関数を実行するように即座にスケジューリングされる必要があり得る。レイテンシの制約は、数値および／または絶対時間であり得る。レイテンシの制約は、非バッチ可能関数リクエスト１６１０の関連する関数が、短い時間フレーム内に完了する必要があり得ることを示し得る。従って、非バッチ可能関数リクエスト１６１０は、ウォームコンテナであり得るコンテナ１６１４ｂ内において実行するようにスケジューリングされ得る。
いくつかの実施形態において、関数リクエスト１６０４の関数リクエストのレイテンシの制約が非バッチ可能閾値を満たす場合、適時の実行を確実にするべく、関数リクエストは、非バッチ可能として自動的に分類され得る。例えば、関数が予め定められた時間において完了する必要があることをレイテンシの制約が示す場合、対応する関数リクエストは、対応する関数するリクエストとバッチするために他のバッチ可能関数を識別することなく、即座にスケジューリングされ得る。
いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は更に、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎの各々のレイテンシの制約を判定し得る。呼び出し元およびバッチバランサ１６０６は、これまでに受信された第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎのもっとも強いレイテンシ制約に基づいて、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎをスケジューリングすることを待機し得る。
例えば、呼び出し元およびバッチバランサ１６０６は、レイテンシの制約から、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎのそれぞれの関数各々の、実行を完了するための時間フレームを決定し得る。時間フレームは、それぞれのバッチ可能関数が実行を完了すべき好ましい時間ウィンドウに対応し得る。時間フレームのうちの最短の時間フレームが決定され得る。呼び出し元およびバッチバランサ１６０６は、最短の時間フレームを満たすために、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎをコンテナ１６１４ａへ送信し得る。例えば、呼び出し元およびバッチバランサ１６０６は、最短の時間フレームを有する関数が、最短の時間フレーム内に完了することを確実にするために、第１の時間において第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎをコンテナ１６１４ａへ送信し得る。しかしながら、呼び出し元およびバッチバランサ１６０６は、第１の時間に到達するまで、関数リクエスト１６０４の受信および累積を継続し得る。したがって、呼び出し元およびバッチバランサ１６０６は、レイテンシの制約に適合するために、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎをコンテナ１６１４ａへ送信する前に、ある期間待機し得る。
いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は、レイテンシの制約に適合するために、特定の関数の実行を開始するタイミングを決定し得る。呼び出し元およびバッチバランサ１６０６は、特定の関数の実行を完了するために必要な合計予測レイテンシを決定し得る。合計予測レイテンシは、コールドコンテナを初期化するのに必要な時間、呼び出し元およびバッチバランサ１６０６が関数リクエスト１６０４を累積するのに既に費やした時間、特定の関数の前にコンテナを実行するようスケジューリングされた関数のレイテンシ、通信レイテンシ、および／または、コンテナにおいて特定の関数が実行を完了するレイテンシを含み得る。以下の数式１６００は、合計予測レイテンシと許容可能なレイテンシとの比較に基づいて、特定の関数のレイテンシの制約が満たされるかどうかを判定するために使用され得る。
Ｌｗａｉｔ＋ ＬＣＣＬ ＋ ＬＦ ＋ＬＣ ≦ Ｌａｃｃｅｐｔ
数式１６００
上の数式１６００において、Ｌｗａｉｔは、呼び出し元およびバッチバランサ１６０６が特定の関数の特定の関数リクエストを累積した期間である。例えば、Ｌｗａｉｔは、現在の時間と、特定の関数リクエストが受信された時間との間の差異であり得る。ＬＣＣＬは、コールドコンテナを初期化するのに必要な時間である。ウォームコンテナが使用可能として識別される場合、ＬＣＣＬはゼロに設定され得る。ＬＦは、特定の関数の前に実行することがスケジューリングされた各関数の予測実行レイテンシ、および、特定の関数が実行を完了する予測レイテンシの総和である。従って、ＬＦは、総関数実行レイテンシ推定であり得る。ＬＣは、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎをコンテナ１６１４ａへ送信する通信レイテンシである。Ｌａｃｃｅｐｔは、レイテンシの制約から決定され得、特定の関数の総許容可能レイテンシであり得る。例えば、Ｌａｃｃｅｐｔはサービスプロバイダまたはクライアントによって設定される閾値であり得、関数の実行が完了することが予期される合計時間であり得る。関数が、Ｌａｃｃｅｐｔと等しいかより少ないレイテンシで実行を完了する場合、関数は適時に完了したとみなされ得る。上記が真である場合、または、Ｌａｃｃｅｐｔが、Ｌｗａｉｔ、ＬＣＣＬ、ＬＣおよびＬＦの総和以上である場合、レイテンシの制約が満たされたとみなされ得る。いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は、Ｌａｃｃｅｐｔが、予め定められた量だけ総和より大きい場合のみ、レイテンシの制約が満たされたとみなし得る。
上の数式１６００に基づいて、呼び出し元およびバッチバランサ１６０６は、特定の関数の実行を開始する開始タイミングを決定し得る。呼び出し元およびバッチバランサ１６０６は更に、開始タイミングを満たすように、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎを送信する送信時間を決定し得る。例えば、呼び出し元およびバッチバランサ１６０６は、ＬＣＣＬおよびＬＣなどの静的値を決定し得、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎがコンテナ１６１４ａへ送信されるタイミング（送信時間）、および、コンテナ１６１４ａにおけるバッチ可能関数実行の順序を制御することによって、ＬｗａｉｔおよびＬＦなどの動的レイテンシを調整し得る。
いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は、特定の数の第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎが累積されることに応じて、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎをコンテナ１６１４ａへ送信し得る。例えば、コンテナ１６１４ａは、サポートされる数の関数の同時実行をサポートすることが可能であり得る。したがって、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎの関数の数が、サポートされる数に到達した場合、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎは、実行を開始するためにコンテナ１６１４ａへ送信され得る。いくつかの実施形態において、関数は、コンテナ１６１４ａ内において独立するソフトウェアスレッド上で同時に動作し得る。従って、関数は並列に実行し得る。いくつかの実施形態において、関数は利用可能なスレッド上で時間共有モードにおいて実行し得る。
従って、上の例において、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎは、呼び出し元およびバッチバランサ１６０６によって異なる時間に受信され、累積され得る。呼び出し元およびバッチバランサ１６０６は、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎをバッチとして、ウォームまたはコールドであり得るコンテナ１６１４ａへ送信し得る。呼び出し元およびバッチバランサ１６０６は、関連するレイテンシの制約を満たすために、どれだけの作業がバッチにあり得るかに従って、バッチをスケジューリングし得る。従って、そのようなバッチ方式において、関数がトリガされるとき、関数のロードバランシング、呼び出し、および実行が別々に（２ステージ方式で）実行され得る。
いくつかの実施形態において、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎは、レイテンシの制約に従って、呼び出し元およびバッチバランサ１６０６によって２以上のグループに分割され得る。例えば、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎは分割され得、その結果、第１グループがもっとも強いレイテンシ制約を有し、第２グループが次にもっとも強いレイテンシ制約を有し、以下同様である。
レイテンシを低減するべく、２以上のコンテナを有する２以上のグループの同時実行が発生し得る。いくつかの実施形態において、２以上のグループについて、十分なウォームコンテナが無い場合、ウォームコンテナはレイテンシの制約に従って割り当てられ得る。例えば、もっとも強いレイテンシ制約を有するグループ（実行のための最短時間ウィンドウ）は、ウォームコンテナへ送信され得、より弱いレイテンシの制約（実行のためのより長い時間ウィンドウ）を有するグループはコールドコンテナへ送信され得る。例えば、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎから、レイテンシの制約の識別が行われ得る。第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎは、レイテンシの制約に従ってグループ化され得、その結果、実行完了のための最短の時間ウィンドウを有する関数は、ウォームコンテナにおいて実行される。対照的に、実行完了のためにより長い時間ウィンドウを有する関数は、コールドコンテナにおける実行完了のためにまとめてグループ化され得る。
いくつかの実施形態において、グループは、同一のコンテナ１６１４ａにおいて次々に実行するようにスケジューリングされ得る。もっとも強いレイテンシ制約を有するグループは、より弱いレイテンシの制約を有するグループの前に実行するようスケジューリングされ得る。
更に、いくつかの実施形態において、呼び出し元およびバッチバランサ１６０６は、関数のバッチをスケジューリングするために、ＦａａＳインフラストラクチャのフロントエンドからバックエンドまでの粗い粒度のディスパッチとして動作し得る。例えば、バックエンドにおいて、第１バッチ可能関数リクエスト１６０８ａ～第Ｎバッチ可能関数リクエスト１６０８ｎは、関連する関数が通常の方式で実行するコンテナ１６１４ａに与えられ得る。対照的に、ＦａａＳの商用の大規模使用は、個々の関数リクエストスケジューリング方式に基づいて、ロードバランシング、コンテナ割り当て、およびトランスポートオペレーション（すべて純粋なオーバヘッドであり得る）を実行するために、より多くのリソースを必要とし得る。
更に、本明細書において説明されるバッチスケジューリング方式は、コールドとウォームコンテナとの比率を自動的に低減し得る。詳細には、コールドコンテナは、バッチにおける第１動作（例えば関数）についてのみコールドであり、バッチにおける残りの動作についてはウォームである。更に、関数を収納するための、より少ないコールドコンテナが構築され、コールドコンテナとウォームコンテナとの比率を低減する。上述のように、関数は、レイテンシの制約に基づいて、閾値期間より長く遅延されないことがあり得、そのポイントにおいて、関数は何のバッチ内にあるかに関係なく実行のためにプッシュされる。
ここで図１６Ｂを参照すると、半導体パッケージ装置１６２０の実施形態は、１または複数の基板１６２４、および、１または複数の基板１６２４に連結されるロジック１６２２を含み得、ここで、ロジック１６２２は、少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数に実装される。１または複数の基板１６２４に連結されるロジック１６２２は、複数の関数リクエストを受信するよう構成され得、その各々は、それぞれの関数の実行をリクエストし、複数の関数リクエストからバッチ可能関数リクエストを決定し得る。いくつかの実施形態において、ロジック１６２２は、バッチ可能関数リクエストを同一のコンテナへ送信するよう構成され得る。例えば、ロジック１６２２は、同一のコンテナがウォームであると判定し、コンテナがウォームであるという決定に応じて、バッチ可能関数リクエストが同一のコンテナへ送信されると判定するよう構成され得る。いくつかの実施形態において、１または複数の基板１６２４に連結されるロジック１６２２は、１または複数の基板１６２４内に位置するトランジスタチャネル領域を含み得る。
ロジック１６２２および装置１６２０の他のコンポーネントの実施形態は、ハードウェア、ソフトウェア、またはハードウェアでの少なくとも部分的な実装を含めた、これら任意の組み合わせにおいて実装されてよい。例えば、ハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。追加的に、これらのコンポーネントの一部は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
装置１６２０は、方法１６５０、１６７０および１６９０（図１６Ｃ、図１６Ｄ、および図１６Ｅ）の１または複数の態様、または、本明細書において説明される実施形態のいずれかを実装し得る。いくつかの実施形態において、示される装置１６２０は、１または複数の基板１６２４（例えば、シリコン、サファイア、ヒ化ガリウム）、および、基板１６２４に連結されるロジック１６２２（例えば、トランジスタアレイ、および、他の集積回路／ＩＣコンポーネント）を含み得る。ロジック１６２２は、少なくとも部分的に、構成可能ロジックまたは固定された機能のロジックハードウェアで実装され得る。一例において、ロジック１６２２は、基板１６２４内に位置する（例えば組み込まれる）トランジスタチャネル領域を含み得る。従って、ロジック１６２２と基板１６２４との間のインタフェースは、階段接合でないことがあり得る。ロジック１６２２はさらに、基板１６２４の初期ウェハ上に成長するエピタキシャル層を備えるとみなされ得る。
図１６Ｃは、関数リクエストをバッチする方法１６５０を示し、図１３Ａのサーバ１３０２によって実行され得るが、または、サーバ１３０２と連携して、図４の強化ＦａａＳシステム４００および／または１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、方法１６５０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック１６５２は、それぞれの関数の実行を各々がリクエストする複数の関数リクエストを受信し得る。示される処理ブロック１６５４は、複数の関数リクエストからバッチ可能関数リクエストを判定し得る。示される処理ブロック１６５６は、バッチ可能関数リクエストを同一のコンテナへ送信し得る。示される処理ブロック１６５６は更に、同一のコンテナがウォームであると判定し、同一のコンテナがウォームであることに基づいて、バッチ可能関数リクエストが同一のコンテナへ送信されると判定し得る。
示される処理ブロック１６５８は、非バッチ可能である複数の関数リクエストから１または複数の非バッチ可能関数リクエストを判定し得る。示される処理ブロック１６６０は、１または複数の非バッチ可能関数リクエストの各々を異なるコンテナへ送信し得る。
図１６Ｄは、２以上の関数リクエストをバッチする方法１６７０を示し、図１３Ａのサーバ１３０２によって実行され得るが、または、サーバ１３０２と連携して、図４の強化ＦａａＳシステム４００および／または１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
示される処理ブロック１６７２は第１バッチ可能関数リクエストを受信し得る。示される処理ブロック１６７４は、第１バッチ可能関数リクエストがバッチされると判定し得る。示される処理ブロック１６７６は、第２バッチ可能関数リクエストが受信されるまで待機し得る。すなわち、第１バッチ可能関数リクエストは、実行および／またはスケジューリングのために、即座にコンテナへ送信されないことがあり得る。むしろ、方法１６７０は、スケジューリング前の実行のために、関数リクエストを効果的にまとめてバッチするように、他の関数リクエストが受信されるのを待機し得る。示される処理ブロック１６７８は、第１および第２バッチ可能関数リクエストｆまとめてバッチ可能であると判定し得る。示される処理ブロック１６８０は、第１および第２バッチ可能関数リクエストのうち１または複数のレイテンシの制約を判定し得る。本明細書において既に説明されるように、レイテンシの制約は、第１および第２バッチ可能関数リクエストによって呼び出される関数の実行が完了すべきリクエストされる時間を反映し得る。示される処理ブロック１６８２は、１または複数のレイテンシの制約に基づいて、第１および第２バッチ可能関数リクエストを同一のコンテナへ送信する送信時間を決定し得る。詳細には、送信時間は、第１および第２バッチ可能関数リクエストが１または複数のレイテンシの制約に適合すること、または、リクエストされた時間までに実行を完了することを確実にし得る。示される処理ブロック１６８４は、送信時間に第１および第２バッチ可能関数リクエストを同一のコンテナへ送信し得る。
いくつかの実施形態において、示される処理ブロック１６８０、１６８２は、示される処理ブロック１６７４、１６７６、１６７８のうち１または複数と同時に、または、その前に発生し得る。例えば、第１バッチ可能関数リクエストのレイテンシの制約は、ブロック１６７４と同時に識別され得る。更に、示される処理ブロック１６７４は、第１バッチ可能関数リクエストのレイテンシの制約に基づいて、第１バッチ可能関数リクエストが非緊急であると判定し得、他の関数のリクエストを待機し得る。更に、示される処理ブロック１６７６は、第１バッチ可能関数リクエストのレイテンシの制約に適合する期間にわたって他の関数を待機し得る。
図１６Ｅは、レイテンシの制約に適合するように関数リクエストをスケジューリングする方法１６９０を示し、図１３Ａのサーバ１３０２によって実行され得るが、または、サーバ１３０２と連携して、図４の強化ＦａａＳシステム４００および／または１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
示される処理ブロック１６９２は関数リクエストを受信する。例えば、オーケストレータは、関数リクエストを受信し、関数リクエストをスケジューリングし得る。示される処理ブロック１６９４は、関数リクエストのレイテンシの制約を判定し得る。上記のように、レイテンシの制約は、関数リクエストによって呼び出される関数についての総許容可能レイテンシを反映し得る。レイテンシの制約は、関数の好ましい完了タイミングを反映する数値の指標（例えば５μｓ）および／または絶対時間（例えば２：４８ＥＳＴ）であり得る。いくつかの実施形態において、レイテンシの制約は、別の関数リクエストに依存し得る。例えば、関数は、別の関数からのデータを操作し得る。従って、レイテンシの制約は、関数が他の関数の完了の予め定められた時間内に実行を完了すべきであることを反映し得る。いくつかの実施形態において、レイテンシの制約は、関数リクエストの関数が、バッチ処理を待機することなく、可能な限り早く実行されることを反映し得る。
示される処理ブロック１６９６は、レイテンシの制約に適合するために関数リクエストをコンテナへ送信し得る。関数リクエストは、他の関数リクエストとバッチされ得る。従って、関数リクエストおよび他の関数リクエストは、コンテナへ送信され得る。いくつかの実施形態において、関数リクエストがコンテナを共有できない、または、レイテンシの制約がバッチ処理のための時間を許可しない場合、関数リクエストはバッチされないことがあり得る。
追加の留意点および例
例１６００は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、それぞれの関数の実行を各々がリクエストする複数の関数リクエストを受信させ、複数の関数リクエストから複数のバッチ可能関数リクエストを決定させ、複数のバッチ可能関数リクエストから第１バッチ可能関数リクエストを受信させ、第１バッチ可能関数リクエストがバッチされると判定させ、複数のバッチ可能関数リクエストのうちの第２バッチ可能関数リクエストが受信されるまで待機させ、第１および第２バッチ可能関数リクエストがまとめてバッチ可能であると決定させ、第１および第２バッチ可能関数リクエストの１または複数のレイテンシの制約を判定させ、１または複数のレイテンシの制約に基づいて、第１および第２バッチ可能関数リクエストを同一のコンテナへ送信する時間を決定させ、決定された時間において複数のバッチ可能関数リクエストを同一のコンテナへ送信させ、同一のコンテナがウォームであると決定させ、同一のコンテナがウォームであることに基づいて、複数のバッチ可能関数リクエストが同一のコンテナへ送信されると判定させ、非バッチ可能である複数の関数リクエストコールから１または複数の非バッチ可能関数リクエストを判定させ、１または複数の非バッチ可能関数リクエストの各々を異なるコンテナへ送信させ、バッチ可能関数リクエストの関数は、直列、並列、または、直列および並列のハイブリッド方式で実行される。
例１６０１は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、それぞれの関数の実行を各々がリクエストする複数の関数リクエストを受信させ、複数の関数リクエストのうち複数のバッチ可能関数リクエストを判定させる。
例１６０２は、更なる命令セットを含む、例１６０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、複数のバッチ可能関数リクエストを同一のコンテナへ送信させる。
例１６０３は、更なる命令セットを含む、例１６０２ｎ少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、同一のコンテナがウォームであると判定させ、同一のコンテナがウォームであることに基づいて、複数のバッチ可能関数リクエストが同一のコンテナへ送信されると判定させる。
例１６０４は、更なる命令セットを含む、例１６０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１バッチ可能関数リクエストを複数のバッチ可能関数リクエストから受信させ、第１バッチ可能関数リクエストがバッチされると判定させ、複数のバッチ可能関数リクエストのうち第２バッチ可能関数リクエストが受信されるまで待機させ、第１および第２バッチ可能関数リクエストがまとめてバッチ可能であると判定させる。
例１６０５は、更なる命令セットを含む、例１６０４の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１および第２バッチ可能関数リクエストの１または複数のレイテンシの制約を判定させ、１または複数のレイテンシの制約に基づいて、第１および第２バッチ可能関数リクエストを同一のコンテナへ送信する時間を判定させ、決定された時間に第１および第２バッチ可能関数リクエストを同一のコンテナへ送信させる。
例１６０６は、更なる命令セットを含む、例１６０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、非バッチ可能である複数の関数リクエストコールから１または複数の非バッチ可能関数リクエストを判定させ、１または複数の非バッチ可能関数リクエストの各々を異なるコンテナへ送信させる。
例１６０７は、例１６０１の少なくとも１つのコンピュータ可読媒体を含み、バッチ可能関数リクエストの関数は、直列並列、または直列および並列のハイブリッド方式で実行される。
冗長関数実装
ここで図１７Ａを参照すると、関数リクエスト１７１０がＦａａＳシステム、例えば図４のＦａａＳシステム４００のオーケストレータ１７０４によって処理される冗長関数実装１７００の例が示される。
いくつかの場合において、多くの要因（例えば、コンピューティングノードのクラッシュ）に起因して、関数はタイムアウトし得、決して完了しないことがあり得る。例えば、オリジナル関数１７１２はトリガされると、オーケストレータ１７０４がコンピュートノード１７０６ｃを識別してオリジナル関数１７１２へ割り当て得る一連のステップ（例えば、認証、承認、事前起動リソース可用性など）を通り得る。しかしながら、異なるプラットフォームは、一意の特性（例えば仮想化層など）、および、オリジナル関数１７１２をリクエストしたＦａａＳサービスのクライアントにとって未知で不透明であり得るリソースを有し得る。例えば、オリジナル関数１７１２は、適時の実行を促進するのに十分な、サブスクライブされていないリソースを有するコンピューティングノード１７０６ａのウォームコンテナ上で実行し得る。他の場合、オリジナル関数１７１２は、実行を促進するのに十分なリソースを有しないビジーなプラットフォーム上で実行するコンピュートノード１７０６ａのコールドコンテナ上で実行し得る。更に、オリジナル関数１７１２は更に、性能が可変でもある他のサービスを消費し得る。その結果、オリジナル関数１７１２が実際に実行に進み、実行を完了すること、更にオリジナル関数１７１２が適時に完了することの確実性が限定され得る。
例えば、オリジナル関数１７１２は、オリジナル関数１７１２が利用可能なリソースを超える場合、ディスパッチしないことがあり得る（例えば、メモリ上の動的制限）。更に、オリジナル関数１７１２は、適時にディスパッチしないことがあり得る。または、ディスパッチされると、オリジナル関数１７１２が許可された時間制限内に実行を完了するかどうか不明であり得る。
いくつかの場合において、オリジナル関数１７１２が完了し得るが、複数の連続再試行を必要とする。従って、オリジナル関数１７１２は、オリジナル関数１７１２が最終的に完了するまで、複数回数にわたって次々に再生成され得る。クライアント側でそのような連続再試行を行うことは高価であり、かつ、完了を確実にすることが難しい。なぜなら、クライアントは、成功または失敗をもたらす要因を制御しないことがあり得るからである。成功した結果のテストおよび再試行も、リクエスト側のプログラミングを複雑にする。
いくつかの関数は、成功についての高い要件を有するとみなされ得、従って、非完了または完了遅延のリスクは許容されないことがあり得る。下に説明されるように、オーケストレータ１７０４は、複数のコンピュートノード１７０６ａ－１７０６ｃにわたる冗長関数実行によって非完了または完了遅延の可能性を緩和し得る。例えば、オリジナル関数１７１２の冗長関数１７０８ａ、１７０８ｂは、異なるノード１７０６ａ、１７０６ｂにおいて生成および実行され得る。
図１７Ａに示されるように、イベント処理ＡＰＩプロキシ１７０２は、イベントコールを関数へルーティングし得る。１７００の例において、ＡＰＩプロキシ１７０２は、例えばＡＰＩを介して関数リクエスト１７１０を生成し得る。関数リクエストコール１７１０は、オーケストレータ１７０４に提供され得る。関数リクエスト１７１０は、オリジナル関数１７１２を実行するためにリクエストされ得る。オーケストレータ１７０４は関数リクエスト１７１０を解析し得る。詳細には、オーケストレータ１７０４は、冗長関数実行を提供するかどうかを決定し得る。そのような決定は、オリジナル関数１７１２が品質閾値を満たすかどうかに基づき得る。品質閾値は、ユーザリクエスト（例えばトークン、クラスなど）、サービス品質（ＱｏＳ）メトリクス、またはサービス水準合意に基づき得る。
図１７Ａの例において、オーケストレータ１７０４は、オリジナル関数１７１２が品質閾値を満たすと、ひいては、オリジナル関数１７１２の非完了または非適時完了の可能性が冗長関数実行方式を通じて緩和さされると判定し得る。冗長関数実行方式は、冗長関数１７０８ａ、１７０８ｂの生成を含み得る。一例において、冗長関数１７０８ａ、１７０８ｂの各々は、オリジナル関数１７１２の同一コピーであり得る。しかしながら、オリジナル関数１７１２の実装は、１７０８ａ、１７０８ｂなどにおいて、選択的に、より遅いが保証された実行のために特定され得る。
示されるように、オリジナル関数１７１２および冗長関数１７０８ａ、１７０８ｂは、異なるコンピュートノード１７０６ａ－１７０６ｃに提供され得る。従って、関数タイムアウトまたは非完了の可能性は緩和され得る。したがって、冗長関数１７０８ａ、１７０８ｂおよびオリジナル関数１７１２の１つが予め定められた時間に完了に成功する可能性が増加することにより、信頼性が強化される。
オリジナル関数１７１２および冗長関数１７０８ａ、１７０８ｂの１つの実行が完了すると、オーケストレータ１７０４または別の機構は、オリジナル関数１７１２および冗長関数１７０８ａ－１７０８ｂのうち非完了のものの実行をキャンセルし得る。従って、リソースはキャンセルを通じて効率的に管理され得る。
いくつかの実施形態において、関数リクエスト１７１０は、関数が保証されるべきかどうかを指定するフィールドを含み得る。従って、ＦａａＳアーキテクチャのクライアントなどのユーザは、関数がいつ保証されるべきかを指定可能であり得る。いくつかの実施形態において、オーケストレータ１７０４は、保証される関数のホワイトリストを含み、これら実行中の関数の複数コピーを生成し得る。
いくつかの実施形態において、冗長関数１７０８ａ、１７０８ｂは、オリジナル関数１７１２と非重複の実行を有し得る。例えば、コンピュートノード１７０６ｃは、オリジナル関数１７１２の実行の進行レポートを提供し得る。進行レポートは、完了したオペレーションの数、オリジナル関数１７１２の現在実行されているコードのラインなどを示し得る。オリジナル関数１７１２が遅延される、または、タイムアウトし得ることを進行レポートが示す場合、オーケストレータ１７０４は、オリジナル関数１７１２が実行を開始した後の時点で冗長関数１７０８ａ、１７０８ｂを生成し得る。
いくつかの実施形態において、オーケストレータ１７０４は、オリジナル関数１７１２の実行に必要であり得るリソース要件を決定し得る。オーケストレータ１７０４は、リソースの動的利用率の利用可能な指標に基づいてリソース要件を判定し得る。オーケストレータ１７０４は、リソース要件に基づいて、冗長関数１７０８ａ、１７０８ｂを生成すべきかどうかを判定し得る。例えば、冗長関数１７０８ａ、１７０８ｂは、コンピュートノード１７０６ｃが十分なリソースを欠如し得る、または、オリジナル関数１７１２の実行を完了するリソース要件を満たすことができないという識別に応じて生成され得る。
いくつかの実施形態において、オリジナル関数１７１２および冗長関数１７０８ａ－１７０８ｂの各々は、同時に実行を開始するためにオーケストレータ１７０４によってスケジューリングされ得る。例えば、オリジナル関数１７１２および冗長関数１７０８ａ、１７０８ｂは、オリジナル関数１７１２が品質閾値を満たすという識別に応じて実行するようスケジューリングされ得、それにより、オリジナル関数１７１２および冗長関数１７０８ａ、１７０８ｂの各々について、ほぼ同時に、または、可能な限り早く実行を開始する。冗長関数１７０８ａ－１７０８ｂおよびオリジナル関数１７１２は重複する実行時間を有し得る。
いくつかの実施形態において、冗長関数１７０８ａ、１７０８ｂは、オリジナル関数１７１２が実行完了に失敗した場合だけ実行をスケジューリングされ得る。例えば、オーケストレータ１７０４は、オリジナル関数１７１２が実行の完了に失敗し、品質閾値を満たすと判定し得る。従って、オーケストレータ１７０４は、第２の非完了の発生を緩和するために、オリジナル関数１７１２の複数の冗長コピーが冗長関数１７０８ａ、１７０８ｂとして生成されるべきと判定し得る。
更に、ＡＰＩプロキシ１７０２またはオーケストレータ１７０４は、指定されたパラメータに基づいて、オリジナル関数１７１２の重要を識別し得る。指定されたパラメータは、確実性の度合いを取得するべく、異なる関数について異なるタイプの反復方式を指定する管理者またはクライアントによって設定され得る。上記のように、そのような方式は、オリジナル関数１７１２の実行に必要なリソースの動的利用率の利用可能な指標に基づく、予測的、プロアクティブ、リアクティブな手段を含み得る。オリジナル関数１７１２が実行して完了すると、冗長関数１７０８ａ、１７０８ｂの実行がどのステージにあり得る場合でも、オーケストレータ１７０４は、冗長関数１７０８ａ、１７０８ｂをキャンセル、ドロップする、またはキルし得るので、従って、リソースの不必要な消費を減らす。従って、オーケストレータ１７０４は、関数が失敗する可能性を緩和し、関数が適時に実行することを保証することによって、ＦａａＳ関数実装を強化し得る。
図１７Ｂは、冗長ＦａａＳ関数実装の方法１７５０を示し、図１３Ａのサーバ１３０２によって実行され得るが、または、サーバ１３０２と連携して、図４の強化ＦａａＳシステム４００、および／または図１７Ａのオーケストレータ１７０４、および／または１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
示される処理ブロック１７５２は、オリジナル関数を実行するために関数リクエストコールを受信し得る。関数リクエストコールは、例えばアプリケーションまたはユーザデバイスに由来し得る。示される処理ブロック１７５４は、オリジナル関数が品質閾値を満たすかどうか判定し得る。満たさない場合、オリジナル関数だけが実行され得る。すなわち、冗長関数は生成されないことがあり得る。しかしながら、満たす場合、示される処理ブロック１７５６は、１または複数の冗長関数がオリジナル関数と共に実行されると判定し得る。１または複数の冗長コピーの各々は、オリジナル関数の同一コピーであり得る。示される処理ブロック１７５６は、異なるコンピュートノードで重複時間にオリジナル関数および１または複数の冗長コピーを実行することを含み得る。更に、示される処理ブロック１７５６は、第１の時間にオリジナル関数の実行を開始すること、および、第１の時間の後の第２の時間に１または複数の冗長コピーの実行を開始することを更に含み得る。いくつかの実施形態において、オリジナル関数および１または複数の冗長コピーは、非重複時間に実行され得る。いくつかの実施形態において、１または複数の冗長コピーは、オリジナル関数が進行閾値またはリソース要件のうち１または複数を満たさないという識別に応じて実行を開始し得る。
追加の留意点および例
例１７００は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、オリジナル関数を実行するために関数リクエストコールを受信させ、オリジナル関数が品質閾値を満たすかどうかを判定させ、オリジナル関数が品質閾値を満たすことに応じて、オリジナル関数と共に実行されるオリジナル関数の１または複数の冗長関数を判定させ（ここで、１または複数の冗長関数の各々は、オリジナル関数のコピーである）、重複時間にオリジナル関数および１または複数の冗長関数を実行させ、異なるコンピュートノードでオリジナル関数および１または複数の冗長関数を実行させ、第１の時間にオリジナル関数の実行を開始させ、第１の時間の後の第２の時間に１または複数の冗長関数の実行を開始させ、オリジナル関数が進行閾値またはリソース要件を満たさないという識別に応じて１または複数の冗長関数の実行を開始させる。
例１７０１は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、オリジナル関数を実行するために関数リクエストコールを受信させ、オリジナル関数が品質閾値を満たすかどうかを判定させ、オリジナル関数が品質閾値を満たすことに応じて、１または複数の冗長関数がオリジナル関数と共に実行されると判定させ、ここで、１または複数の冗長関数の各々は、オリジナル関数のコピーである。
例１７０２は、更なる命令セットを含む、例１７０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、重複時間にオリジナル関数および１または複数の冗長関数を実行させる。
例１７０３は、更なる命令セットを含む、例１７０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、異なるコンピュートノードでオリジナル関数および１または複数の冗長関数を実行させる。
例１７０４は、更なる命令セットを含む、例１７０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１の時間にオリジナル関数の実行を開始させ、第１の時間の後の第２の時間に１または複数の冗長関数の実行を開始させる。
例１７０５は、更なる命令セットを含む、例１７０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、オリジナル関数が進行閾値またはリソース要件を満たさないという識別に応じて、１または複数の冗長関数の実行を開始させる。
ＦａａＳおよび／またはＡＦａａＳ関数の反復実行
いくつかのタスクは、ＦａａＳおよび／またはＡＦａａＳ関数の反復実行をトリガし得る。ＦａａＳが以下で参照されるが、ＡＦａａＳ関数も同様に実行され得ることが理解される。
ＦａａＳ関数は、関心のある異なるスペースまたはエリアを調査し得る。例えば、ビッドマッチングタスクは、様々な組み合わせのオファーを探索し得、もっとも好ましい条件を有するものを探す。様々な組み合わせは、反復ＦａａＳ関数を通じて探索され得る。例として、ＦａａＳ関数は、ビッドマッチングプロセスを実行するために繰り返し反復する必要があり得る。例えば、オファーの条件が、ビッドの変更を必要とする項目を含む場合、または、他のオファーをアウトビッドするために、１または複数の関数は反復的に動作する必要があり得る。別の例として、人工知能対応エッジサービスにおいて、推論が、許容可能なリスク基準内に収まる関連する信頼性基準を有するまで、推論は解決手段として識別されないことがあり得る。
いくつかの場合において、反復タスクを完了する条件は動的に指定される可能性があるので、反復実行は、上記の様々な動的条件を考慮するために反復制御を動的にスクリプト可能または可変にすることによってサポートされ得る。従って、特定のコンテキストにおけるＦａａＳ関数は、動的制御で反復的に動作する。しかしながら、反復ＦａａＳ関数は、完了のための動的条件に到達することなく不必要に動作を継続する場合があり得る。例えば、２つの探索空間があり、各々は異なるＦａａＳ関数によって探索されると想定する。いくらかの時間の後、ＦａａＳ関数の１つが、実行可能な解決手段をもたらす可能性が低い探索サブ空間を探索していることが明らかになり得る。そのようなＦａａＳ関数を不必要に動作させることは、実行可能な解決手段をもたらす可能性がより高い他のＦａａＳ関数に割り当てられ得るリソースをＦａａＳ関数が消費するという点で、非効率である。更に、ＦａａＳ関数は、終了条件に到達せず（例えば、実行可能な解決手段）、時間に到達するまで、動作を継続し得る。従って、レイテンシは増加し、リソースは非効率的に割り当てられる。
探索空間は、探索アルゴリズムまたはプロシージャ、探索基準を満たす可能な解または解答を探索し得る、解または解答の実行可能な領域であり得る。例えば、探索空間は、探索が実行可能とみなされ得る、可能性、パラメータ、アルゴリズム、値もしくはアクセス、または時間的制約の全体的な集合を説明するために使用され得る。特定の一例において、チェスをプレイするスーパーコンピュータの場合、探索空間は非常に大きいことがあり得るが、クラウドから切断されたラップトップまたはタブレット上で実行するプログラムの場合、探索空間は、評価の深さ、評価の時間、または、評価するための代替的移動の数などにおいて制約され得る。上では探索空間と称されるが、下では「解空間」と称され得る。探索空間は解空間の例である。解空間は、解が識別される空間であり得る。
図１８Ａおよび図１８Ｂを参照すると、強化されたスケジューラ１８２０は、ＦａａＳサービスのために関数生成グラフ１８００生成するために提供される。強化されたスケジューラ１８２０は、条件が満たされること、例えば、解空間（例えば、特定のセットの探索）が実行可能な解を生成する可能性が低い確率に基づいて、関数生成グラフ１８００の解空間へのリソース割り当てをキャンセルまたは再優先化し得る。それにより、リソース割り当てを強化し、実行可能および最適に近い実行可能な解空間から解を探すタイミングを減少させ得る。
図１８Ａは関数生成グラフ１８００を示す。（図１８Ｂに示されるような）スケジューラ１８２０は、関数グラフ１８００を生成し、十分に価値のある解を見つけることに対する関数グラフ１８００を実行するために、様々なスケジューリング、キャンセル、および再優先化メタタスクを実装する様々なハードウェアまたはソフトウェア実装を含み得る。例えば、スケジューラ１８２０は、スレッド構築ブロックを使用して構築される分岐限定オペレーションであり得る。または、それはＳＱＬクエリオプティマイザなどであり得る。タスク１８１２は、関数Ａ１８０２、関数Ｂ１８０４、関数Ｃ１８０６、関数Ｄ１８０８および関数Ｅ１８１０を生成し得る。以下の説明において、簡潔にするために、関数Ａ１８０２、関数Ｂ１８０４、関数Ｃ１８０６、関数Ｄ１８０８および関数Ｅ１８１０は、「生成された関数」と総称され得る。
関数生成グラフ１８００は、生成された関数が並列または直列に動作するスケジューリングのデータ表現である。生成された関数は、異なるが関連する関数であり得る。関数Ｃ１８０６は、実行のために、関数Ａ１８０２からのデータに依存し得、従って、関数Ａ１８０２に依存する。したがって、関数Ａ１８０２および関数Ｃ１８０６は、関数生成グラフ１８００の第１分岐１８１４とみなされ得る。同様に、関数Ｄ１８０８は、実行のために、関数Ｂ１８０４からのデータに依存し得、従って、関数Ｂに依存する。関数Ｂ１８０４および関数Ｄ１８０８は、関数生成グラフ１８００第３分岐１８１８とみなされ得る。関数Ｅ１８１０は、動作のために別の関数からのデータを必要としないことがあり得る。関数Ｅ１８１０は、関数生成グラフ１８００の第２分岐１８１６とみなされ得る。第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８の各々は、少なくとも１つの反復関数を含み得、別個の解空間および／または潜在的な解または結果のための探索可能性とみなされ得る。完了とみなされるために、タスク１８１２は、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８の１つから、可能性のある最良の解または結果のみを採用し得る。
示されるように、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８は、別個だが互いに関連し得る。すなわち、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８は、反復的探索の異なる探索解空間またはエリアを表し得る。第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８は、例えば、実行するための情報を共有しないことによって、独立に動作し得、従って、別個とみなされ得る。しかしながら、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８は、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８は、の１つが、それ自体、または、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８のうち別のものの非優先化またはキャンセルを引き起こし得るという点で関連し得る。
例えば、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８の１つの分岐がキャンセル条件（非優先化条件とみなされ得る）に到達した場合、スケジューラ１８２０は１つの分岐を終了し得る。別の例において、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８の分岐へのリソース割り当ては、スケジューラ１８２０によって修正され、非優先化条件が達成されることに基づき得る。例えば、スケジューラ１８２０が、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８の１つの分岐が、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８の別の分岐に比べて著しく少ない成功確率を有すると識別した場合、非優先化条件が満たされるとみなされ得る。更に、スケジューラ１８２０は、１つの分岐へのリソース割り当てを低減し、他の分岐へのリソース割り当てを増加させ得る。
例えば、各解空間は、異なる解を表し得る。解空間が探索サイズを狭くする、または低減するにつれて、潜在的な解の数は、それに対応して減少し、計算労力または計算時間の制約された量の中で解が達成され得ることを示す。第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８のうち１つの分岐が、反復によって解空間を低減する（解の可能な選択肢を狭くする）場合、その１つの分岐は、成功の傾向があり得る。対照的に、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８のうち別の分岐が解空間を増加させる（解の可能な選択肢を増加させる）、または、同一の解空間サイズを維持する場合、他の分岐は、失敗の傾向があり得る、および／または、現在の優先化探索が解をもたらす可能性を網羅した後に探索するために、代替的な解をもたらし得る。他の分岐は、従って、失敗の傾向に基づいて非優先化条件に到達し得る。いくつかの実施形態において、解空間サイズの比較（解の選択）により、非優先化条件を達成させ得る。例えば、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８のうち１つの分岐の１つの解空間が、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８のうち別の分岐の別の解空間と比べて、より速い速度の反復で低減した場合、他の分岐は、非優先化条件を満たすとみなされ得る。
特に、生成された関数の１つは、上記のように非優先化条件に到達し得る。非優先化条件は、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８のうち１または複数が非優先化され得ることを示し得る。非優先化は、第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８のうち１または複数が、タスクによって対処される問題への実行可能な解を生成する可能性が低い、または、いくつかの他の生成された関数より多くのリソースまたは時間を必要とする可能性が高いエリアまたは空間を探索しているとみなされることを意味し得る。スケジューラ１８２０が第１分岐１８１４、第２分岐１８１６、および第３分岐１８１８の１つの分岐を非優先化する場合、１つの分岐により少ないリソースが割り当てられ得る、または、１つの分岐は、１つの分岐を含む任意の生成された関数を保留／終了／アンワインドすることによって、保留／終了／アンワインドされ得る。非優先化条件は、生成された関数の１つが終了条件を識別するときであり得、従って、１つの生成された関数、または別の生成された関数の終了をもたらす。従って、効率的なリソース割り当ては、タスクにとって重要性がより低い、または、関係ない関数の実行を回避することによって実現され得る。
例えば、関数Ｄ１８０８が非優先化条件に到達すると想定する。第３分岐１８１８は終了し得る。これは、関数Ｄ１８０８および／または関数Ｂ１８０４の実行の停止を含み得る。いくつかの実施形態において、第３分岐１８１８を終了するのではなく、第３分岐１８１８へのリソース割り当てが低減される。例えば、関数Ｄ１８０８および／または関数Ｂ１８０４へのリソース割り当てが低減され得る。いくつかの実施形態において、非優先化条件は、関数Ｄ１８０８によって生成される値、関数Ｄによって生成される解の信頼区間、関数Ｄによる成功の可能性の指標、関数Ｄが潜在的な解に近いかどうかなどを通じて識別され得る。
図１８Ｂに示されるように、強化ＦａａＳシステム１８３２はスケジューラ１８２０を含み得る。既に説明されたように、スケジューラ１８２０は、図１８Ａの関数生成グラフ１８００を生成し、関数グラフ１８００に従ってスケジューリングし、生成された関数を適宜キャンセルし得る。
詳細には、スケジューラ１８２０は、関数生成グラフ１８００に従って、生成された関数の実行をスケジューリングおよびモニタリングし得る。関数Ａ１８２２の反復実行、関数Ｂ１８２６の反復実行、関数Ｃ１８２４の反復実行、関数Ｄ１８２８の反復実行、および、関数Ｅ１８３０の反復実行はそれぞれ、図１８Ａの関数Ａ１８０２、関数Ｂ１８０４、関数Ｃ１８０６、関数Ｄ１８０８、および関数Ｅ１８１０に対応する。
スケジューラ１８２０は、関数生成グラフ１８００の実行中に非優先化条件（例えば終了条件）を識別し、非優先化条件に基づいて実行を中止または保留し得る。例えば、スケジューラ１８２０は、生成された関数の１または複数を終了または保留し、生成された関数の任意の更なる関数インスタンス化を中止および／または一時停止し得る。スケジューラ１８２０は、ハードウェアキューマネージャおよびマルチキャスティングを利用してそれを行い得る。
詳細には、関数Ａ１８２２の反復実行は、関数Ａ１８０２の反復であるＦＡ１～ＦＡｎを含む。関数Ａ１８２２の反復実行が完了し得、次に、関数Ｃ１８２４の反復実行が開始し得る。同様に、関数Ｂ１８２６の反復実行が完了し得、関数Ｄ１８２８の反復実行が開始し得る。いくつかの実施形態において、同時実行が実行され得る。例えば、関数Ａ１８２２の反復実行は、関数Ｃ１８２４の反復実行と同時に発生し得る。更に、関数Ｂ１８２６の反復実行は、関数Ｄ１８２８の反復実行と同時であり得る。
関数Ｃ１８２４の反復実行中、スケジューラ１８２０は、関数Ｃ１８２４の反復実行を終了する非優先化条件を識別し得る。そのような非優先化条件は、第１分岐１８１４、および特に特定の関数Ｃ１８０６が実行可能な解を生成する可能性が低いという識別を含み得る。従って、関数Ｃ１８２４の反復実行は、１つの反復ＦＣ１についてのみ実行する。関数Ｃ１８２４の反復実行のキャンセルまたは保留後、関数Ｃ１８２４の反復実行に割り当てられたリソースは、他の実行に再割り当てられ得る。例えば、関数Ｅ１８３０の反復実行は、増加したリソース割り当てを有し得る、および／または、関数Ｄ１８２８の反復実行は、増加したリソース割り当てを有し得る。
いくつかの実施形態において、スケジューラ１８２０は、関数Ｃ１８２４の反復実行をキャンセルするのではなく、関数Ｃ１８２４の反復実行のリソース割り当てを低減し得る。いくつかの実施形態において、スケジューラ１８２０は、リソース割り当てを関数Ｃ１８２４の反復実行から関数Ｅ１８３０の反復実行および／または関数Ｄ１８２８の反復実行に再分散し得る。いくつかの実施形態において、リソースは、生成された関数のうち１または複数が、成功のための最大の機会、および／または、実行をまだ継続する生成された関数のうち他のものと比較してより大きい成功の機会を有し得る確率に基づいて、生成された関数のうち１または複数に再割り当てされ得る。それにより、関数Ｅ１８３０の反復実行、および／または、関数Ｄ１８２８の反復実行のレイテンシが減少し得、タスクについての解を識別するレイテンシが更に減少し得る。しかしながら、関数Ｃ１８２４の反復実行のレイテンシは増加し得るが、関数Ｃ１８２４の反復実行によって提示される成功の確率がより低いと仮定すれば、許容可能なトレードオフとみなされ得る。
いくつかの実施形態において、関数Ｃ１８２４の反復実行は再優先化され得る。例えば、再優先化の条件が満たされる場合、関数Ｃ１８２４の反復実行は再優先化され得、その結果、関数Ｃ１８２４の反復実行は再開され、および／または、増加したリソース割り当てを有する。例えば、再優先化条件は、関数Ｃ１８２４の反復実行が、生成された関数の他のものと比較して、実行可能な結果を生成する可能性がより高いと示されることであり得る。いくつかの実施形態において、再優先化条件は、別の生成された関数、例えば、関数Ｄ１８２８の反復実行の成功確率が減少したという識別であり得る。
いくつかの実施形態において、生成された関数の反復実行は、異なるノードおよび／またはコンテナで発生する。例えば、関数Ａ１８２２の反復実行は、異なるノードおよび／または異なるコンテナで発生し得る。ＦＡ１は、第１ノードで第１コンテナにおいて実行し得、ＦＡＮは、第２ノードで第２コンテナにおいて実行し得る。
既に説明されたように、スケジューラ１８２０は、生成された関数を終了し、および／または、より少ない有効解空間へのリソース割り当てを低減することによって、上記のようにレイテンシを低減し、強化されたリソース管理を有し得る。例えば、リソースは、非優先化条件の識別に応じて効率的に割り当て解除される。
反復実行制御は、動的にスクリプト可能または可変であり得る。なぜなら、反復タスクを完了するための条件は、動的に指定される可能性が高いからである。従って、スケジューラ１８２０は、第１分岐１８１４、第２分岐１８１６、第３分岐１８１８、および、特に、第１分岐１８１４、第２分岐１８１６、第３分岐１８１８の生成された関数によって表される異なる方式を探索し得る。第１分岐１８１４、第２分岐１８１６、第３分岐１８１８は、動的ヒント、最近見られたパターンおよびパターンにおけるシフト、制約の変形などに従って決定される異なる探索方式であり得る。
例えば、スケジューラ１８２０は、任意の所与の時間において、有限の時間および電力の範囲で最良の推論を識別し得る。それを行うために、時間ウィンドウが十分に小さい、または、閾値を満たさない場合、および／または、コンピュート予算が十分に小さい、または、閾値を満たさない場合、スケジューラ１８２０は、低精度方式を使用し得る。図１８Ｂに示されるように、第１分岐１８１４、第２分岐１８１６、第３分岐１８１８を探索した後に、スケジューラ１８２０は、上記の第１分岐１８１４などの解空間を除去した後に、後の反復のためにより高い精度を使用し得る。従って、スケジューラ１８２０は、第１分岐１８１４、第２分岐１８１６、第３分岐１８１８を通じて、複数の並列、低コスト探索を開始し、次に、第１分岐１８１４、第２分岐１８１６、第３分岐１８１８のうち他のものがより生産的な結果を生成するという識別に応じて、第１分岐１８１４、第２分岐１８１６、第３分岐１８１８のうちいくつかをキャンセルし得る。既に説明されたように、第１分岐１８１４、第２分岐１８１６、第３分岐１８１８の分岐のキャンセルは、キャンセルされた分岐を含む、生成された関数のキャンセルを意味し得る。
従って、スケジューラ１８２０は、関数Ａ１８２２の反復実行、関数Ｂ１８２６の反復実行、関数Ｃ１８２４の反復実行、関数Ｄ１８２８の反復実行、および関数Ｅ１８３０の反復実行のうち非優先化されたものへのリソース割り当てを効率的にキャンセルまたは低減し得る。非優先化とは、非優先化された反復関数が、タスクによって対処される問題への実行可能な解を生成する可能性が低いエリアまたは空間を探索しているとみなされることを意味し得る。例えば、いくつかの実施形態は、関数Ａ１８２２の反復実行、関数Ｂ１８２６の反復実行、関数Ｃ１８２４の反復実行、関数Ｄ１８２８の反復実行、および関数Ｅ１８３０の反復実行のそのような動的反復起動およびキャンセルについての、様々なメタプログラミングサポートを含み得る。解のサブ空間が一時的に非優先化である場合、探索のために消費される解空間のリソースは、例えば、解のサブ空間が再優先化されるまで、データをキャッシング層から移動させることによって、自動的に割り当て解除され得る。更に、生成された関数のキャンセルは、自動的に生成され得、その結果、リソースは、より重要性が低い関数または作業から迅速に割り当て解除され、他のより高い優先度の作業または生成された関数に割り当てられることができる。
いくつかの例において、フレキシブルマルチキャスティングトポロジーが実装され、生成された関数における１つの反復からのデータ（およびイベント）は、ローカルで発生してもしなくてもよい生成された関数（または別の生成された関数）の別の反復に対して自動的に移動され得る。従って、このトポロジーは、効率的な通信方式が、生成された関数をキャンセルまたは再優先化することを可能にする。
更に、いくつかの実施形態は、ネットワーク関数仮想化性能の要求を満たすために、様々なポイントツーポイント機能を一般化する強化マルチキャスティングトポロジーを有し得る。例えば、いくつかの実施形態は、フレキシブルマルチキャストトポロジーを実装し得、その結果、生成された関数およびタスクは、インフラストラクチャの１つの部分において生成され、インフラストラクチャの別の部分においてキャンセルされ、通信トポロジーは、低い通信オーバヘッドで適合する。例えば、エッジコンピューティングにおいて、モバイルクライアントまたはモバイルターゲット（例えば、基地局または消費者施設の設備）のリクエストは位置を変化させ、いくつかの実施形態は、対応する反復の生成された関数を再分散するために、効率的な方式で、異なるノード、コンテナなどの間のマルチキャスト構成を修正し得る。
例えば、いくつかの実施形態において、スケジューラ１８２０は、モバイルクライアントおよび／またはモバイルターゲットの位置を識別し得る。モバイルクライアントおよび／またはモバイルターゲットが位置をシフトするにつれて、生成された関数の反復実行が、異なるコンテナおよび／またはノードに移動され得、モバイルクライアントおよび／またはターゲットの予め定められた距離が維持される。これにより、通信レイテンシが減少し得、このことは、上記のフレキシブルマルチキャスティングインフラストラクチャを通じて実現され得る。更に、スケジューラ１８２０は、コンテナおよび／またはノードを認識し得、その結果、スケジューラ１８２０は、生成された関数の実行、リソース割り当て、およびキャンセルを制御し得る。更に、メタプログラムを実行する機能は更に、ハードウェアキューマネージャなどのハードウェアへシフトされ、プラットフォームソフトウェアに提供され得、その結果、生成された関数は、必要なとき、より迅速な実行、および効率的なキャンセルを有し得る。
図１８Ｃ]は、ＦａａＳ関数実装の方法１８７０を示し、図１３Ａのサーバ１３０２によって実行され得るが、または、サーバ１３０２と連携して、図４の強化ＦａａＳシステム４００、および／または図１８Ｂのスケジューラ１８２０、および／または１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
示される処理ブロック１８７２は、実行される複数の関数を識別し得る。複数の関数は反復実行し得る。示される処理ブロック１８７４は、非優先化条件が識別されることに応じて、複数の関数のうち１または複数を非優先化し得る。例えば、示される処理ブロック１８７４は、非優先化条件が識別されることに応じて、複数の関数のうち１または複数の実行をキャンセルする。示される処理ブロック１８７４はまた、非優先化条件が識別されることに応じて、複数の関数のうち１または複数のリソース割り当てを低減し得る。示される処理ブロック１８７６は、非優先化条件が識別されることに応じて、非優先化されない複数の関数の１または複数へのリソース割り当てを増加させ得る。
方法１８７０は、より少ない有効解空間、例えば、複数の関数のうち１または複数へのリソース割り当てを終了および／または低減することにより、レイテンシを低減し、上記のように強化されたリソース管理を有し得る。例えば、示される処理ブロック１８７４に関連して説明されるような非優先化条件の識別に応じて、リソースは効率的に割り当て解除される。
追加の留意点および例
例１８００は、命令セットを含む、少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、実行される複数の関数を識別させ、非優先化条件が識別されることに応じて複数の関数のうち１または複数を非優先化させ、非優先化条件が識別されることに応じて、複数の関数の１または複数のリソース割り当てを低減させ、または、複数の関数の１または複数の実行をキャンセルさせ、非優先化されない複数の関数のうち１または複数へのリソース割り当てを増加させ、ここで、複数の関数のうちの関数は反復実行するためのものである。
例１８０１は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、実行される複数の関数を識別させ、非優先化条件が識別されることに応じて、複数の関数の１または複数を非優先化させる。
例１８０２は、更なる命令セットを含む、例１８０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、非優先化条件が識別されることに応じて、複数の関数のうち１または複数の実行をキャンセルさせる。
例１８０３は、更なる命令セットを含む、例１８０２の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、非優先化条件が識別されることに応じて、複数の関数のうち１または複数のリソース割り当てを低減させる。
例１８０４は、例１８０１の少なくとも１つのコンピュータ可読媒体を含み、複数の関数の関数は反復的に実行する。
例１８０５は、更なる命令セットを含む、例１８０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、非優先化されない複数の関数のうち１または複数へのリソース割り当てを増加させる。
共通データストレージを有する強化ＦａａＳアーキテクチャ
ＦａａＳ環境における通信レイテンシは、著しいオーバヘッドをもたらし得る。例えば、いくつかのＦａａＳ環境は、数千の関数を含み得、長期間の記憶および／または実行のために、対応するデータはノード間で渡される。更に関数は、「ステートレス」とみなされ得る。したがって、データを生成する関数の実行後に残ったデータの記憶は、特に課題をもたらし得る。いくつかの実施形態は、将来の再使用のために、そのようなデータのキャッシングを強化する。
例えば、ノードであり得るデータベースサーバを想定する。ノード（データベースサーバ）は、関数を実行する実行ノードに対して遠隔であり得る。データベースサーバは、実行のために関数が利用し得るデータを格納し得る。データベースサーバへのデータアクセスは高価であり得、したがって、データは実行ノードへ、または、実行ノードの近くへ移動され得る。そのようなデータ転送は、特にデータの性質およびサイズに応じて、高レイテンシおよびリソース集約的であり得る。例えば、無駄なあちこちへの入力／出力が発生するだけでなく、データの自然のフォーマットが、休止中符号化フォーマットから使用中符号化フォーマットに、および、その逆に修正され得る。従って、マーシャリングコスト、および、データについて休止中符号化フォーマットと使用中符号化フォーマットとの間の変更のコストが増加する。
ここで図１９Ａを参照すると、共通データストレージ１９００を有する強化ＦａａＳアーキテクチャが示される。例１９００は図４の強化ＦａａＳシステム４００を含み得る。いくつかの実施形態は、１または複数の関数による再使用のためにデータを格納するための、（一時的データストレージであり得る）共通データストレージ１９１０の利用を通じて効率性を強化し得る。例えば、関数Ｆ１は、他の関数によって使用される共通データを生成し得る。共通データは共通データストレージ１９１０に格納され得る。関数Ｆ１が実行を完了した後、共通データは、共通データストレージ１９１０に格納された状態で維持され得る。その後、関数Ｆ２などの他の関数は、実行を開始し、共通データにアクセスし得る。例えば、第１関数Ｆ１が実行を完了した後に関数Ｆ２が実行を開始する場合、関数Ｆ２は、共通データストレージ１９１０に近い、および／または、それを含むノード１９０４を実行するなど、ノードにインスタンス化され得る。
従って、共通データは、エビクションされるのではなく、共通データストレージ１９１０において維持され得る。更に、共通データのフォーマットは、セキュリティの理由で暗号化され得るが、そうでない場合は変更されないことがあり得る。従って、上の実装は、ＩＯ転送およびデータ符号化フォーマットの修正を低減させ得、レイテンシを低減しリソース利用を強化する。
制御ノード１９０２は、プロセス１９１２によって示されるように、時間Ｔ０で関数Ｆ１を呼び出し得る。関数Ｆ１は、ノード１９０４上で実行し得る。ノード１９０４はローカルデータストレージ１９０６と通信し得る。いくつかの実施形態において、ローカルデータストレージ１９０６は、実行ノード１９０４の一部であり得る。示されるように、ローカルデータストレージ１９０６は、共通データストレージ１９１０および特定データストレージ１９２８を含む、少なくとも２つのデータストレージまたはパーティションを含む。
関数Ｆ１が実行ノード１９０４のコンテナにおいて実行するとき、関数Ｆ１はデータを生成し得る。データのうち少なくともいくつかは共通データと呼ばれ得る。共通データは、他の関数によって再使用され得る。例えば、制御ノード１９０２は、図１８Ａの関数生成グラフ１８００などの関数生成グラフを生成し得る。制御ノード１９０２は、例えば、関数が別の関数によって生成されたデータに基づいて動作するかどうかなど、関数の相互依存性を判定するために関数生成グラフを解析し得る。制御ノード１９０２は、データが共通データストレージ１９１０または特定データストレージ１９２８に格納されているかどうかを制御し得る。
いくつかの実施形態において、制御ノード１９０２は、関数Ｆ２がＦ１によって生成されたデータを消費すると判定し得る。従って、制御ノード１９０２は、Ｆ１によって生成されたデータの少なくともいくつかが共通データであるというコマンドまたはメッセージを実行ノード１９０４に渡し得る。例えば、Ｆ１がＴ０で呼び出されるとき、制御ノード１９０２は、実行ノード１９０４に対し、関数Ｆ１によって生成されたデータを共通データとして格納するよう命令させ得る。いくつかの実施形態において、Ｆ１のデータすべてではなく、Ｆ１のデータのサブセット（例えば、最終的な計算または結論データ）だけが共通データとみなされ得る。データのサブセットは、関数Ｆ２によって使用可能であると識別されるデータであり得る。Ｆ２によって使用可能でないと識別される他のデータは破棄され得る。
実行ノード１９０４は関数Ｆ１をインスタンス化し、共通データストレージ１９１０からデータストレージを割り当て得る。従って、関数Ｆ１は、プロセス１９１４に示されるような共通データを共通データストレージ１９１０に格納し得る。Ｆ１が実行を完了した後、共通データを制御ノード１９０２へ送信するのではなく、共通データは共通データストレージ１９１０に維持され得る。例えば、共通データストレージ１９１０から共通データを即座に除去するのではなく、共通データは、共通データストレージ１９１０に格納された状態を維持し得る。
共通データには、共通データのための生存時間を説明する生存時間ポリシーが与えられ得る。生存時間は、共通データにアクセスする他の関数によって強化され得る。新しい関数が共通データにアクセスするたびに、生存時間は、固定量だけ（または、ポリシーもしくは過去の履歴に基づくヒューリスティックから決定される可変量だけ）延長され得る。いくつかの実施形態において、共通データは、最大生存時間の対象となり得、その時間の後、共通データは少なくとも共通データストレージ１９１０から自動的にエビクションされ、更に、ローカルデータストレージ１９０６からエビクションされる。Ｆ１が実行を完了した後に共通データがアクセスされないままである場合、生存時間満了後、生存時間に対する何らかの調整無しで、共通データは制御ノード１９０２へエビクションされ得る。ローカルデータストレージ１９０６および／または実行ノード１９０４は生存時間ポリシーを実施し得る。
いくつかの実施形態において、生存時間ポリシーは、セキュリティ要件とバランスが取られ得る。例えば、ローカルデータストレージ１９０６が、物理的進入を通じて容易に脆弱化され得るエッジデバイスにおいて維持される場合、生存時間は低い値に設定され得る。更に、共通データが高いセキュリティ要件を有する場合、生存時間は低い値に設定され得る。
更に、関数Ｆ１および／またはローカルデータストレージ１９０６は共通データを暗号化し得る。それにより、セキュリティが強化され得、その結果、共通データは承認された関数のみによってアクセスされ得る。
関数Ｆ１、実行ノード１９０４および／またはローカルデータストレージ１９０６は、共通データがどこに格納されるか、および、共通データが暗号化されているかどうかを説明する記述子（一意識別子など）を生成し得る。更に、共通データがセキュリティ目的で暗号化される場合、記述子は、共通データにアクセスするための復号プロトコルを含み得る。例えば、記述子は、共通データを復号するための復号鍵を含み得る。記述子は、記述子を他の関数へ適宜渡し得る制御ノード１９０２に提供され得る。
Ｆ１が実行を完了した後に、制御ノード１９０２は、処理１９２４によって示されるように時間Ｔ２にＦ２を呼び出し得る。実行ノード１９０４は関数Ｆ２を実行し得る。関数Ｆ２は関数Ｆ１の記述子を受信し得る。記述子は、任意の適切な復号プロトコルだけでなく、共通データの位置を正確に説明し得る。関数Ｆ２は、プロセス１９１６によって示されるように、共通データストレージ１９１０に格納される共通データにアクセスして共通データに基づいて実行し得る。従って、共通データの生存時間は増加され得る。アクセスとは、関数Ｆ２が、新しい共通データを読み取り、共通データに追加し、および／または、共通データを上書きし得ることを意味し得る。上記のように、共通データはアクセスされるので、共通データの生存時間は予め定められた値だけ延長される。
関数Ｆ２はまた、Ｆ２だけが使用する特定データを生成し得る。プロセス１９２２によって示されるように、特定データは、特定データストレージ１９２８など、共通データストレージ１９１０とは別個のパーティションに格納され得る。特定データは、プロセス１９３０に示されるように、関数Ｆ２が実行を完了したとき、特定データストレージ１９２８から自動的にエビクションされ得る。
プロセス１９３２に示されるように、関数Ｆ２は、Ｔ１（Ｔ１の呼び出し時間）の後の時点で、Ｔ２において関数Ｆ３が呼び出される前に実行を完了し得る。プロセス１９３０によって示されるように、Ｆ２に割り当てられたリソースが回収されるとき、関数Ｆ２によって生成された特定データは、制御ノード１９０２へ自動的にエビクションされ得る。制御ノード１９０２は、長期ストレージのために特定データを格納することなく特定データを破棄する、または、特定データをデータベースノード１９０８に格納し得る。
したがって、共通データストレージ１９１０は、関数Ｆ１と関数Ｆ２との間でデータを渡すための一時ストレージを提供し得る。それにより、関数Ｆ１により生成されるデータを共通データストレージ１９１０に保存することにより、データベースノード１９０８へのデータベースアクセス（読み取り／書き込み）を制限し得る。更に、ローカルデータストレージ１９０６と制御ノード１９０２との間で渡されるデータが少ないので、図１９Ａに示される強化ＦａａＳアーキテクチャは、強化されたリソース管理プロトコルを有し得、関数Ｆ２のレイテンシを更に低減する。例えば、低減されたデータ移動および入力／出力帯域幅に起因して、関数Ｆ２は、共通データのデータ転送を待機することなく、より少ないオーバヘッドで実行を開始し得る。
共通データストレージ１９１０は、Ｆ２によるアクセスを可能にするために、実行ノード１９０４のローカルページキャッシュであり得る。詳細には、Ｆ２は、実行ノード１９０４上で実行し、従って、好都合な方式で実行ノード１９０４のローカルページキャッシュにアクセスできる。いくつかの実施形態において、データストレージ１９１０は、ストレージ（ファイルまたはブロックキャッシュ）キャッシュ、ページキャッシュおよびブロックキャッシュなどのいくつかの組み合わせを使用する一時的キー値ストア、または、ドキュメントストアであり得る。
制御ノード１９０２は、処理１９３２に示されるように、時間Ｔ２でＦ３を呼び出し得る。Ｆ３は実行ノード１９０４上で実行を開始し、特定データを生成する。特定データは、プロセス１９２６によって特定データストレージ１９２８に格納され得る。関数Ｆ３が実行を完了した後、または、Ｆ３のコンテナが分解または回収されるとき、特定データはプロセス１９３０によってエビクションされ、制御ノード１９０２によって破棄される、または、データベースノード１９０８に格納され得る。
関数Ｆ３は、共通データストレージ１９１０に格納された共通データにアクセスしないことがあり得る。したがって、共通データの生存時間は延長されないことがあり得、満了し得る。従って、共通データは、Ｆ２がプロセス１９１８によって完了された後に、予め決定された時間にエビクションされ得る。詳細には、共通データは、共通データストレージ１９１０からエビクションされ、制御ノード１９０２へ送信され得る。制御ノード１９０２は、使用中符号化フォーマットから休止中符号化フォーマットに共通データを修正し、次に、プロセス１９２０における共通データをデータベースノード１９０８に格納し得る。データベースノード１９０８は、長期ストレージであり得る。共通データはまた、ローカルデータストレージ１９０６によって休止中符号化フォーマットに修正され得る。
いくつかの実施形態において、関数Ｆ１、Ｆ２、Ｆ３によって生成されたデータは、データの潜在的な再使用に関係なく、共通ストレージ１９１０に格納され得る。従って、制御ノード１９０２は、関数Ｆ１、Ｆ２、Ｆ３のどれが、他の関数Ｆ１、Ｆ２、Ｆ３によって使用され得るデータを生成し得るかを決定するために、関数グラフを解析しないことがあり得る。むしろ、各関数Ｆ１、Ｆ２、Ｆ３は、生成データを共通データストレージに格納し得る。データは上記と同様に処理され得、対応する生存時間終了後、暗号化され、共通データストレージ１９１０からエビクションされ得る。
図１９Ｂは、１または複数のＦａａＳ関数によって生成された共通データストレージを使用する方法１９５０を示し、図４の強化ＦａａＳシステム４００、および／または、１または複数のモジュールによって、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
示される処理ブロック１９５２は、第１関数の実行中に、関数に関連する第１データをデータストレージに格納し得、そこでは、第１データが１または複数の他の関数によって使用される。例えば、第１データはデータストレージのキャッシュに格納され得、データストレージは１または複数の他の関数にアクセス可能である。示される処理ブロック１９５４は、第１関数終了後、第１関数の第１データをデータストレージに維持し得る。例えば、第１データは、第１関数が実行を完了したことを識別したことに応じてエビクションされないことがあり得る。示される処理ブロック１９５６は、第２関数の実行中に、第２関数が、データストレージに格納された第１データにアクセスすることを可能にし得る。例えば、第２関数は、第１データの位置を示す記述子、および、第１データにアクセスするのに必要な任意のセキュリティプロトコルを受信し得る。記述子は更に、第１データに関連するメタデータの位置を含む、またはそれを示し得、メタデータは、第１データが暗号化されている場合に、第１データを復号するための適用可能な復号鍵を、第１データがフィンガープリントされている場合に、第１データを検証するための適用可能な検証コードを、第１データが圧縮されている場合に、第１データを伸展するための伸展コードなどを含み得る。従って、第１データはデータストレージに格納され得、第１および第２関数はデータストレージにアクセスする。上記のように、そうすることにより、Ｉ／Ｏオペレーション、データ転送およびデータ修正を低減することによって、レイテンシを低減し、リソース管理を強化し得る。
示される処理ブロック１９５８は、データストレージにおいて第１データがアクセスされない期間を判定し得る。示される処理ブロック１９６０は、期間が第１データの生存時間閾値を満たすかどうかを判定し得る。満たさない場合、示される処理ブロック１９５８は、第１データがアクセスされない期間を判定することを繰り返し得る。生存時間閾値が満たされるとき、示される処理ブロック１９６２は、第１データをデータストレージからエビクションし得る。第１データのエビクションは、第１データが格納されるメモリを割り当て解除すること、および／または、第１データをデータストレージから消去することを含み得る。示される処理ブロック１９６４は、第２データサーバに第１データを格納し得る。第２データサーバは、長期データベースストレージサーバであり得る。
図１９Ｃは、ＦａａＳセキュリティプロトコルを実装および実施する方法１９７０を示し、図４の強化ＦａａＳシステム４００、および／または、１または複数のモジュールによって、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
示される処理ブロック１９７２は、第１関数によって生成されるデータが、他の関数によるアクセスのために共通データストレージに格納されることを決定し得る。示される処理ブロック１９７４は、第１データを暗号化し得、その結果、第１データは、第１関数が実行を完了した後に暗号化される。示される処理ブロック１９７６は、第２関数が第１データにアクセスし得ると決定し得る。例えば、示される処理ブロック１９７６は、第２関数のセキュリティ承認、または、第２関数インスタンス化の由来（例えば、第２関数の実行をリクエストするサーバ、サービスまたはクライアント）、第２関数のマルウェア解析、および／または、第２関数が第１データと適合するかどうかを識別し得る。示される処理ブロック１９７８は、第２関数が第１データにアクセスすることを可能にするために第１データを復号し得る。このようにして、方法１９７０は、マルウェアまたは第３者がデータにアクセスする可能性を低減するためにセキュリティを強化し得る。
追加の留意点および例
例１９００は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１関数の実行中に、第１関数に関連する第１データをデータストレージに格納させ（第１データはデータストレージのキャッシュに格納される）、第１関数終了後、第１関数の第１データをデータストレージに維持させ、第２関数の実行中、第２関数がデータストレージに格納された第１データにアクセスすることを可能にさせ、データストレージにおいて第１データがアクセスされない期間を判定させ、期間が第１データの生存時間閾値を満たすかどうかを判定させ、期間が生存時間閾値を満たすとき、第１データをデータストレージからエビクションさせ、期間が生存時間閾値を満たすことに応じて、第１データを第２データサーバに格納させ、記述子を第２関数に渡させ（記述子は第１データの位置を示し、第１データに関連するメタデータの位置を更に示し、メタデータは、第１データが暗号化されている場合、第１データを復号するための適用可能な復号鍵、第１データがフィンガープリントされている場合、第１データを検証するための適用可能な検証コード、または、第１データが圧縮されている場合、第１データを伸展するための伸展コードのうち１または複数を含む）、第１関数が実行を完了した後に第１データが暗号化されるように第１データを暗号化させ、第２関数が第１データにアクセスすることを可能にするために第１データを復号させる。
例１９０１は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１関数の実行中に、第１関数に関連する第１データをデータストレージに格納させ、第１関数の終了後、第１関数の第１データをデータストレージにおいて維持させ、第２関数の実行中に、第２関数がデータストレージに格納された第１データにアクセスすることを可能にさせる。
例１９０２は、更なる命令セットを含む、例１９０１の少なくとも１つのコンピュータ可読媒体を含み得、更なる命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１データがデータストレージにおいてアクセスされない期間を判定させる。
例１９０３は、更なる命令セットを含む例１９０２の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、期間が第１データの生存時間閾値を満たすかどうか判定させ、期間が生存時間閾値を満たすとき、第１データをデータストレージからエビクションさせる。
例１９０４は、更なる命令セットを含む、例１９０３の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、期間が生存時間閾値を満たすことに応じて、第１データを第２データサーバに格納させる。
例１９０５は、例１９０１の少なくとも１つのコンピュータ可読媒体を含み、第１データはデータストレージのキャッシュに格納される。
例１９０６は、更なる命令セットを含む、例１９０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第２関数の記述子を渡させ、記述子は、第１データの位置を示し、第１データに関連するメタデータの位置を更に示し、メタデータは、第１データが暗号化されている場合、第１データを復号するための適用可能な復号鍵、第１データがフィンガープリントされている場合、第１データを検証するための適用可能な検証コード、または、第１データが圧縮されている場合、第１データを伸展するための伸展コードのうち１または複数を含む。
例１９０７は、更なる命令セットを含む、例１９０１のコンピュータ可読媒体を少なくとも１つ含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１関数の実行完了後に第１データが暗号化されるように第１データを暗号化させ、第２関数が第１データにアクセスすることを可能にするために第１データを復号させる。
ファンクションアズアサービス環境は、レイテンシとリソースオーバヘッドとの間のトレードオフを有し得る。コールドコンテナのプロビジョニングは、大規模な高レイテンシデータ転送、および、データに基づくコンテナの構築を含み得る。従って、コールドコンテナのプロビジョニングは高レイテンシオペレーションであり得る。対照的に、ウォームコンテナの維持は、上記データ転送および構築が回避され得るので、低レイテンシオペレーションであり得る。ウォームコンテナの維持は、延長された期間にわたってアイドル状態を維持する過剰なコンピューティングリソースを消費し、著しいメモリフットプリントを有し得る。例えば、ウォームコンテナは、関数の実行を待機しながら、利用されず、アイドル状態を維持し得る。更に、ウォームコンテナは、到着する関数を実行するための著しいリソース割り当てを有し得、一方で、アイドル状態を維持し、そのような関数を待機する。
異なるモードを有する強化ＦａａＳサーバアーキテクチャ
図２０Ａは、サーバ２００２が、ＦａａＳ管理ロジック２００６ａを含むスマートネットワークインタフェースカード（ＮＩＣ）２００４を含む強化ＦａａＳサーバアーキテクチャ２０００を示す。サーバ２００２は更に、ＦａａＳ管理ロジック２００６ａと連携して動作するＦａａＳ管理ロジック２００６ｂを含み得る。ＦａａＳ管理２００６ｂは、サーバ２００２のＯＳドライバまたはスマートミドルウェアであり得る。ＦａａＳ管理ロジック２００６ａは、スマートＮＩＣ２００４に存在し得る。ＦａａＳ管理ロジック２００６ａ、２００６ｂは、キャッシングポリシーの変化に影響し得、その結果、ＦａａＳサーバアーキテクチャ２００００は、データ／オブジェクトに関連する専用ＦａａＳのためのより多くのメモリリソースを使用することによって、増大するＦａａＳワークロードに適合する。いくつかの実施形態において、サーバ２００２は、ＦａａＳ管理ロジック２００６ａ、２００６ｂの両方ではなく一方だけを含み得る。そのため、例えば、キャッシングポリシーを変更するためのＦａａＳ管理２００６ｂだけが含まれ得る。
ＦａａＳ管理ロジック２００６ａ、２００６ｂは、サーバ２００２が、専用ＦａａＳモード、汎用モード、およびハイライドＦａａＳモードを含む３以上の異なるモードにおいて動作するかどうかを判定し得る。図２０Ａに示される実施形態において、サーバ２００２はハイブリッドＦａａＳモードに存在する。ハイブリッドＦａａＳモードにおいて、キャッシュ２００８、２０１０、２０１２のいくつかだけが専用ＦａａＳモードに置かれ、他は汎用モードに置かれる。専用ＦａａＳモードにおいて、キャッシュ２００８、２０１０、２０１２の各々はＦａａＳモードに割り当てられる。
サーバアーキテクチャ２０００は、プラットフォーム（例えばサーバ）のために、ハイブリッドおよび専用ＦａａＳモードを通じて、レイテンシおよびリソースの考慮のバランスを取り得る。ハイブリッドＦａａＳモードにおいて、専用ＦａａＳキャッシュ２００８、２０１０などの１または複数のキャッシュは、１または複数の関数に関連するデータオブジェクトだけを保存するために使用され得る。例えば、１または複数のキャッシュは、コンテナを構築するために、データの少なくともいくつかを格納し得る。いくつかの実施形態において、コンテナを初期化する必要があるコンテナのデータを格納するために１または複数のキャッシュが割り当てられ得る。
いくつかの実施形態は、異なるノード間のデータ転送が回避され得るので、コールドコンテナの初期化のレイテンシを低減し得、コンテナ構築は、ローカルにキャッシュされたデータに基づいて開始し得る。すなわち、コンテナおよび関数の初期化が高速化され得る。下記のように、関数の初期化は、コンテナの構築、および、コンテナにおける関数の実行の開始を含み得る。初期化および／またはコンテナの構築は、キャッシュ可能であり得る関数データ独立部分の構築、および、キャッシュ可能でないコンテナの追加の関数データ固有部分の構築の両方を含み得る。
いくつかの実施形態は、コンテナへの「ジャストインタイム」アプローチを採用し得る。上記のように、コンテナの始動レイテンシが低減される。必要なとき、関数のレイテンシ要件を満たすために、コンテナは、専用ＦａａＳキャッシュ２００８、２０１０におけるデータから「ジャストインタイム」で迅速に再初期化され得る。従って、コンテナ初期化への」ジャストインタイム￥アプローチが、ウォームコンテナ利用率を低減するために採用され得る。
ウォームコンテナ利用率の低減は、ウォームコンテナリソースフットプリントの低減を通じてリソース割り当てを強化し得る。例えば、より少ない、または小さいウォームコンテナがスタンバイ状態で維持され得るときから、リソースが解放され、関数を実行しているアクティブコンテナ（ホットコンテナと呼ばれ得る）に割り当てられ得る。したがって、より多くの関数が、より少ないリソースでサポートされ、増加したリソース割り当てを通じて、より速く実行を完了し、許容可能なレイテンシ要件を維持し得る。
図２０Ａに示されるように、サーバ２００２は３つのキャッシュ２００８、２０１０、２０１２を含み得る。ハイブリッドＦａａＳモードにおいて、キャッシュ２００８、２０１０の２つは専用ＦａａＳキャッシュとして動作し得る。専用ＦａａＳキャッシュ２００８、２０１０は、１または複数のコンテナを構築するための初期化データを格納し得る。１または複数のコンテナは、サーバ２００２にローカルに構築され得る。従って、コンテナをプロビジョニングするためにリモートノードからデータのすべてを受信するのではなく、サーバ２００２は専用ＦａａＳキャッシュ２００８、２０１０にアクセスし得る。更に、サーバ２００２は、いくつかの関数についてウォームコンテナを維持する必要はないことがあり得、それにより、アクセラレータ、メモリ、ＦＰＧＡ、プロセッサなどのハードウェアコンポーネントのウォームコンテナへのリソース割り当てを低減する。従って、サーバ２００２は、よりアクティブな（ホット）コンテナをサポートし、強化されたリソース割り当ておよび「ジャストインタイム」コンテナ初期化アプローチを通じて関数実行を高速化し得る。
いくつかの実施形態において、専用ＦａａＳキャッシュ２００８、２０１０は、コンテナを開始するために必要な総データセットの一部のみを格納し得る。例えば、サーバ２００２は、コンテナのいくつかの異なるコンポーネントを順次に構築し得る。専用ＦａａＳキャッシュ２００８、２０１０における初期化データは、コンテナの開始コンポーネントを構築するためのデータであり得、データは、リモートノードからサーバ２００２へ送信される他の後のコンポーネントを構築するためのものである。したがって、コンテナは、専用ＦａａＳキャッシュ２００８、２０１０に格納された初期化データに基づいて構築プロセスの開始部分を開始し得る。構築プロセスの開始部分と同時に、サーバ２００２は、リモートノードから、構築プロセスの後の部分のためのデータを受信し、次に、受信データに基づいて構築プロセスを完了し得る。
いくつかの実施形態において、専用ＦａａＳキャッシュ２００８、２０１０は、関数に関連するデータオブジェクトのみを格納し得、それにより、関数初期化を高速化する。例えば、専用ＦａａＳキャッシュ２００８、２０１０は、コンテナのための初期化データだけを格納し得る。汎用キャッシュ２０１２などの他のキャッシュは、関数実行中に関数によって生成されたデータを格納し得る。
ＦａａＳ管理２００６ａ、２００６ｂは、専用ＦａａＳモード、汎用モードまたはハイブリッドＦａａＳモードにおいてサーバ２００２をいつ動作させるかを決定し得る。例えば、ＦａａＳ管理２００６ａ、２００６ｂは、専用ＦａａＳモードまたはハイブリッドＦａａＳモードに切り替えるかどうかを決定するために履歴データを利用し得る。例えば、履歴データは、サーバ２００２が、ある関数型を実行した回数を示し得る。詳細には、ＦａａＳ管理２００６ａ、２００６ｂは、各関数を関数型に分類し得る。複数の関数が同一のコンテナにおいて各々実行可能である場合、それらの関数は同一の関数型とみなされ得る。ＦａａＳ管理２００６ａ、２００６ｂは、回数を予め定められた数と比較し、回数が予め定められた数より大きい場合、専用ＦａａＳモードまたはハイブリッドＦａａＳモードに入るべきであると決定し得る。
いくつかの実施形態において、履歴データは、ある時間ウィンドウ、例えば前の５ミリ秒のうちに呼び出された関数型のみを含み得る。サーバ２００２のモードについての上記の決定を促進する履歴データに加えて、ポリシー、サービス水準合意の考慮、および、オーケストレータからの明示的な命令は、専用ＦａａＳキャッシュのサイズおよび量を増加または低減させるための決定に影響し得る。更に、スマートＮＩＣ２００４は、ピアマシンおよび／またはキャッシュ２００８、２０１０、２０１２から、キャッシュされたＦａａＳデータをフェッチすることについてオンザフライの決定を実行し得る。このようにして、ソフトウェアは、ネットワーク間サーバ２００２のセットの間で、キャッシュ２００８、２０１０、２０１２を含むキャッシュにおいてＦａａＳオブジェクトがどのように分散されているかに依存しないことがあり得る。
上述のように、専用ＦａａＳキャッシュ２００８、２０１０は、ハイブリッドモードにおいて汎用キャッシュ２０１２と共存し得る。したがって、上の例において、キャッシュ２００８、２０１０の２つは、ＦａａＳキャッシュに割り当てられ得、一方でキャッシュ２０１２は汎用キャッシュとして利用される。従って、サーバ２００２上のワークロードのＦａａＳ部分が増加するとき、キャッシュ２００８、２０１０、２０１２のうちの専用ＦａａＳキャッシュの数は、それに対応して増加し得る。後に、ＦａａＳ部分が減少するとき、キャッシュ２００８、２０１０、２０１２のうちの非常に小さい専用ＦａａＳキャッシュが存在し続ける、または、すべてのキャッシュ２００８、２０１０、２０１２すべてが、ＦａａＳおよび非ＦａａＳページ、ファイルなどのキャッシングに区別が無い汎用キャッシュになるかのいずれかである。
いくつかの実施形態において、ＦａａＳ管理２００６ａ、２００６ｂは、専用ＦａａＳモード、汎用モード、またはハイブリッドＦａａＳモードに入るべきかどうかを決定するために、スケジューラ２０１４からメッセージを受信し得る。スケジューラ２０１４は、例えば制御ノードにおけるサーバ２００２に対しリモートであり得る。いくつかの実施形態において、サーバ２００２はスケジューラ２０１４を含み得る。スケジューラ２０１４は、これらの決定、ポリシー、システム水準合意の考慮ならびにオーケストレータからの明示的命令を促進する履歴データに基づいて、ＦａａＳ管理２００６ａ、２００６ｂに、専用ＦａａＳモード、ハイブリッドモードまたは汎用モードに入るよう命令し得る。
いくつかの実施形態において、スケジューラ２０１４は、特定のコンテナデータが専用ＦａａＳキャッシュ２００８、２０１０に格納されるべきであるとＦａａＳ管理２００６ａ、２００６ｂに更に命令し得る。例えば、スケジューラ２０１４は、特定のコンテナが複数の関数によって利用されるべきと決定し得、従って、ＦａａＳ管理２００６ａ、２００６ｂに対して、コンテナのための初期化データが、関数による再使用のために専用ＦａａＳキャッシュ２００８、２０１０に格納されるべきであると命令し得る。
更に、スケジューラ２０１４は、関数の実行の完了に部分的に応じて、ＦａａＳ管理２００６ａ、２００６ｂに対し、ハイブリッドＦａａＳモードを終了し、汎用モードベースに入ることを命令し得る。例えば、スケジューラ２０１４は、関数制御フローグラフから、スケジューラ２０１４に内蔵された、収集された統計値およびワークロード予測規則から、専用ＦａａＳキャッシュ２００８、２０１０における初期化データが、実行を完了した関数によってそれ以上利用されることがないこと、および／または、高需要がある可能性が低い、もしくは可能性が無いことを決定し、従って、ＦａａＳ管理２００６に、専用ＦａａＳモードまたはハイブリッドＦａａＳモードを終了して汎用モードまたはハイブリッドＦａａＳモードに入ることを命令し得る。例えば、過去の履歴に基づいて予測され得る関数制御グラフにおける残りの関数は、性能または効率性への著しいリスクを生じさせることなく、専用ＦａａＳキャッシュ２００８、２０１０に格納される初期化データに関連するコンテナとは異なるコンテナにおける実行のためにディスパッチされ得る。ハイブリッドＦａａＳモードが終了すると、専用ＦａａＳキャッシュ２００８、２０１０は、再割り当てされ、汎用モードにおいて汎用キャッシュとして利用され得る。
いくつかの実施形態において、スケジューラ２０１４および／またはＦａａＳ管理２００６ａ、２００６ｂは、ＦａａＳサーバアーキテクチャ２０００の負荷を識別し得る。負荷が特定の閾値より上である場合、リソースとレイテンシとのバランスを効果的にとるために、専用ＦａａＳモードまたはハイブリッドＦａａＳモードに入り得る。負荷が閾値より下に低下する場合、専用ＦａａＳまたはハイブリッドＦａａＳモードが終了し得、次に、ハイブリッドＦａａＳモードまたは汎用モードに入り得る。例えば、負荷が低下する場合、専用ＦａａＳモードからハイブリッドＦａａＳモードに切り替えられ得、負荷が更に低下する場合、ハイブリッドＦａａＳモードが汎用モードに切り替えられる。負荷は、現在実行している関数の数、データアクセス、通信リクエスト、および／または、他の指標を通じて測定され得る。いくつかの実施形態において、負荷は、制御フローグラフに基づいて、スケジューラ２０１４および／またはＦａａＳ管理２００６ａ、２００６ｂによって予測され得る。例えば、スケジューラ２０１４は、制御フローグラフ、および／または、１つのタイプの関数のアクティブ化が、同一または別のタイプの関数のアクティブ化の先駆けとなる頻度についての統計解析に基づいて、複数の関数が同時に動作するかどうかを予測し得る。
いくつかの実施形態において、サーバ２００２は、サーバ２００２が十分に多い数のＦａａＳアプリケーションのリクエストを処理しないという識別に応じて、ハイブリッドＦａａＳモードを終了し、汎用モードに入り得る。例えば、スケジューラ２０１４は、サーバ２００２がもはや多くの数のＦａａＳアプリケーションリクエストを処理する必要がないと判定した場合、サーバ２００２にハイブリッドＦａａＳモードを終了するよう命令し得る。
いくつかの実施形態において、サーバ２００２は、専用ＦａａＳキャッシュ２００８、２０１０において初期化データの生存時間が満了したという識別に応じて、ハイブリッドＦａａＳモードを終了し、汎用モードに入り得る。例えば、ＦａａＳ管理２００６ａ、２００６ｂは、初期化データが使用されない、および／または、コンテナを構築するために使用されない時間を判定するためにカウンタを維持し得る。ＦａａＳ管理２００６ａ、２００６ｂは、時間が生存時間閾値を超える、および／または、満たすかどうかを判定し得る。時間が閾値を超える、および／または、満たす場合、ＦａａＳ管理２００６ａ、２００６ｂは、ハイブリッドＦａａＳモードを自動的に終了し、汎用モードに入り得る。
上の実施形態のいくつかは、特定の条件（例えば、生存時間が満了するという識別、負荷の低減、過去の制御フローグラフの解析、アクティブ化シーケンスなど）に基づいて、専用ＦａａＳモードおよび／またはハイブリッドＦａａＳモードを終了することを説明する。いくつかの実施形態において、即座にハイブリッドＦａａＳモードを終了するのではなく、専用ＦａａＳキャッシュ２００８、２０１０における初期化データは解放されて、次に、新しい初期化データに置き換えられ得る。例えば、条件の１つが満たされた場合、スケジューラ２０１４および／またはサーバ２００２は、異なる初期化データを専用ＦａａＳキャッシュ２００８、２０１０に格納するかどうかを判定し得る。
例えば、スケジューラ２０１４は、制御フローグラフから、専用ＦａａＳキャッシュ２００８、２０１０に格納された初期化データがもはや関係ないことを判定し得る。すなわち、スケジューラ２０１４は、初期化データから構築される第１コンテナがもはや使用されない、または、頻繁に使用されないと判定し得る。スケジューラ２０１４は、ハイブリッドＦａａＳモードを即座に終了するのではなく、制御フローグラフおよび／または履歴データを参照して、第２コンテナが使用されるかどうか判定し得る。使用される場合、スケジューラ２０１４は、ＦａａＳ管理２００６ａ、２００６ｂに対し、第１コンテナについての初期化データを消去し、第２コンテナについての初期化データを専用ＦａａＳキャッシュ２００８、２０１０に格納するよう命令し得る。しかしながら、スケジューラ２０１４が、専用ＦａａＳキャッシュ２００８、２０１０に格納されるべき他の初期化データが無いと判定した場合、ハイブリッドＦａａＳモードが終了し得る。
いくつかの実施形態において、サーバ２００２および／またはスケジューラ２０１４に関連して上記したように、サーバ２００２のオペレーティングシステムは、専用ＦａａＳモード、ハイブリッドＦａａＳモード、汎用モードにいつ入り、専用ＦａａＳモード、汎用モードをいつ終了するかを判定し得る。いくつかの実施形態において、専用ＦａａＳキャッシュ２００８、２０１０はハードウェアキャッシュであり得る。
サーバ２００２を含む実施形態は、所与の時間フレーム内においてサーバ２００２で実行され得る関数の数を増加させ得る。更に、関数を実行する実行環境をセットアップするレイテンシ（例えば時間）（始動時間）、および、関数が消費するメモリは、サーバ２００２で実行され得る関数の数を決定する要因であり得る。上記のように、メモリにおいて関数実行のためのリソースを準備状態に維持すること（すなわちウォームコンテナ）は、始動時間を低減するために利用され得る。メモリフットプリントの潜在的な増加、および、ウォームコンテナのリソース割り当てに対処するべく、いくつかの実施形態は、関数を始動するためのリソースだけを格納するための専用ＦａａＳキャッシュ２００８、２０１０、および／または、メモリフットプリントおよびメモリ割り当てを低減するための関数についてのコンテナを隔離し得る。従って、リソース競合が低減され、関数の始動時間が高速化される。専用ＦａａＳキャッシュ２００８、２０１０は、ＦａａＳアプリケーションにサービスを提供するためにサーバ２００２が使用されていない、または、著しい負荷が無いときに適応的に解放され得る。
図２０Ａに関連して上記されたように、図２０Ｂは、サーバ２０２２が汎用モードである強化ＦａａＳサーバアーキテクチャ２０２０を示す。示されたように、３つのキャッシュ２０２８、２０３０、２０３２は、汎用モードで動作する。すなわち、汎用キャッシュ２０２８、２０３０、２０３２は、データオブジェクトを格納し得るが、ＦａａＳ関連オブジェクトを格納することに割り当てられないことがあり得る。それでも、汎用キャッシュ２０２８、２０３０、２０３２がＦａａＳ関連オブジェクトを格納し、更に、汎用データオブジェクトを格納することは可能であり得る。
ＦａａＳ管理２０２６ａ、２０２６ｂは、汎用モード、ハイブリッドモード、専用ＦａａＳモードの間でサーバ２０２２を切り替え得る。例えば、ＦａａＳ管理２０２６ａ、２０２６ｂは、汎用モードと専用ＦａａＳモードとの間で切り替えるための命令をスケジューラ２０３４から受信し得る。サーバ２０２２がハイブリッドモードに切り替えられるとき、サーバ２０２２はサーバ２００２に似て、図２０Ａに関連して上記されたことと同様に動作し得る。サーバ２０２２が専用ＦａａＳモードに切り替えられるとき、キャッシュ２０２８、２０３０、２０３２の各々は専用ＦａａＳキャッシュとして動作し得る。
図２０Ｃは、データオブジェクトのデータ量を示すグラフ２０４０を示す。グラフ２０４０は、様々なデータオブジェクト（Ｘ軸）とデータの量（Ｙ軸）との間の関係を示す。ホットコンテナは現在、関数を実行し得る。ホットコンテナデータ量２０４２は最大である。ウォームコンテナはアイドルであり得、現在関数を実行しない。ウォームコンテナデータ量２０４４はホットコンテナデータ量２０４２より少ない。図２０Ａおよび図２０Ｂに関連して上記されたように、初期化データは、コンテナを開始するのに必要なデータであり得る。初期化データ量２０４６は最小であり得る。したがって、ウォームデータコンテナ量２０４４と、初期化データ量２０４６との比較は、メモリフットプリント強化が、ウォームコンテナ２０４４を解体し、初期化データを１または複数の専用キャッシュに格納し、初期化データからコンテナを再初期化することによって実現され得ることを示す。
図２０Ｄは、強化関数リソース管理の方法２０５０を示し、図２０Ａおよび２０Ｂの強化ＦａａＳサーバアーキテクチャ２０００、２０２０、および／または、１または複数のモジュールによって、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
示される処理ブロック２０５２は、サーバが関数モードに入ると判定する。関数モードは、上記のように専用ＦａａＳモードまたはハイブリッドＦａａＳモードであり得る。サーバは複数のキャッシュを含み得る。示される処理ブロック２０５４は、関数モードに入ることに応じて、複数のキャッシュのうち１または複数のキャッシュが、初期化データを格納するための専用ファンクションアズアサービスキャッシュとして利用する。初期化データは、関数の実行を開始するために利用され得る。いくつかの実施形態において、初期化データは、関数を開始するための総データセットの一部だけであり得る。示される処理ブロック２０５６は、１または複数の専用ファンクションアズアサービスキャッシュにおける初期化データキャッシュに基づいて関数を初期化し得る。例えば、初期化データは、関数を実行するためのコンテナを構築するために利用され得る。示される処理ブロック２０５８は、ウォームコンテナの需要の低減、関数アクティブ化の速度の低減、または、予測される関数アクティブ化の低減のうち１または複数の識別に基づいて、関数モードを終了し得る。示される処理ブロック２０５８は、１または複数のキャッシュを、初期化データに割り当てられることから解放し、および／または、汎用モードに入り得る。例えば、１または複数のキャッシュは、ファンクションアズアサービスキャッシュとして利用されるのではなく、汎用キャッシュとして利用され得る。上記のように、方法２０５０は、リソース利用を強化し、関数のレイテンシを減少させ得る。
追加の留意点および例
例２０００は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、コンピューティングデバイスの関数モードに入ることを判定させ（コンピューティングデバイスは複数のキャッシュを含む）、関数モードに入ることに応じて、複数のキャッシュのうち１または複数のキャッシュを、初期化データを格納するための専用ファンクションアズアサービスキャッシュとして利用させ（初期化データは関数の実行を開始するために利用され、初期化データは、関数の実行を開始するための総データセットの一部だけであり、初期化データは、関数を実行するためのコンテナを構築するために利用される）、１または複数の専用ファンクションアズアサービスキャッシュにキャッシュされた初期化データに基づいて関数を初期化させ、ウォームコンテナの需要の低減、関数アクティブ化の速度の低減、または予測される関数アクティブ化の低減のうち１または複数の識別に基づいて関数モードを終了させ、関数モードの終了に応じて、１または複数のキャッシュを、初期化データに割り当てられることから解放させ、関数モードの終了に応じて、１または複数のキャッシュを汎用ハードウェアキャッシュとして利用させる。
例２００１は、命令セットを含む少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、コンピューティングデバイスについての関数モードに入ることを判定させ（コンピューティングデバイスは複数のキャッシュを含む）、関数モードに入ることに応じて、複数のキャッシュのうち１または複数のキャッシュを、初期化データを格納するための専用ファンクションアズアサービスキャッシュとして利用させ（初期化データは、関数の実行を開始するために利用される）、１または複数の専用ファンクションアズアサービスキャッシュにおける初期化データキャッシュに基づいて関数を初期化させる。
例２００２は、例２００１の少なくとも１つのコンピュータ可読媒体を含み、初期化データは関数を開始するための総データセットの一部だけである。
例２００３は、例２００２の少なくとも１つのコンピュータ可読媒体を含み、初期化データは、関数を実行するためのコンテナを構築するために利用される。
例２００４は、更なる命令セットを含む、例２００１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、ウォームコンテナの需要の低減、関数アクティブ化の速度の低減、または、予測される関数アクティブ化の低減の１または複数の識別に基づいて、関数モードを終了させる。
例２００５は、更なる命令セットを含む、例２００４の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数モードが終了されることに応じて、初期化データに割り当てられることから１または複数のキャッシュを解放させる。
例２００６は、更なる命令セットを含む、例２００５の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数モードが終了することに応じて、１または複数のキャッシュを汎用ハードウェアキャッシュとして利用させる。
アドレス空間ベースＱｏＳ
ＦａａＳ環境において、アプリケーション、スレッドまたは仮想マシン（ＶＭ）を優先化することが可能であることは重要である。ソフトウェア（ＯＳ／ＶＭＭ）からハードウェアに、どのアプリケーションまたはＶＭの優先度が高／中／低であるかを指示する既存のアプローチは、不正確であり、リソース集約的である。
アプリケーション、スレッドおよび／またはＶＭを優先化する既存の解決手段の例は、クラスオブサービス（ＣＬＯＳ）スレッドベースのインタフェースである。ＣＬＯＳスレッドベースのインタフェースは便利であり得、現在デプロイされ、広く受け入れら得るが、少なくとも２つの短所がある。すなわち、（１）精度の欠如、つまり、各キャッシュラインがプラットフォームにおいてどのように処理されるべきか指定できないこと、および、（２）各コンテキストスワップにおいてＣＬＯＳをスワップするオーバヘッドがあることである。強化ＦａａＳの解決手段のいくつかの例示的な実施形態は、どのアプリケーションまたはＶＭの優先度が高／中／低であるかを示すのに必要なリソースに関してコストがより少なく、より高精度である技術的解決手段を提供し得る。
強化ＦａａＳの解決手段の例示的な実施形態は、ラストレベルキャッシュ（ＬＬＣ）などの共有リソース、およびメモリ帯域幅が、アプリケーション、ＶＭおよびコンテナ（例えばＲＤＴ）によってどのように使用されるかについて、可視性および制御を提供する。そのような技術への強化は、（１）アドレス空間の特定範囲にクラスオブサービス（ＣＬＯＳ）がタギングされる、または、（２）個々のページが、ページごとの属性を追加することによって管理され得る、アドレスベースのＱｏＳを可能にするために構築され得る。アドレス空間ベースのＱｏＳは、メモリタイプおよび範囲レジスタ（ＭＴＲＲ）のスタイルにおけるアドレス範囲の指定、または、保護キーのようなアプローチを通じて展開され得、範囲がベースおよび制限制御レジスタ（ＣＲ）またはモデル固有レジスタ（ＭＳＲ）を通じて指定される。そのような場合、タギングを可能にするために各範囲レジスタがＣＬＯＳに関連付けられている限り、既存の範囲レジスタが再使用され得る、または、新しいものが導入される。
ＣＬＯＳは、スレッド／アプリケーション／ＶＭ／コンテナがグループ化され得るソフトウェア割り当てタグであり得る。このタグは、ソフトウェアスレッド（例えば、コア上の同時マルチスレッディング（ＳＭＴ）スレッド）またはｖＣＰＵがハードウェア論理スレッド上で実行を開始する任意の時間にＭＳＲにスワップされ得る。ソフトウェアは、０またはより多くのスレッドをＣＬＯＳに柔軟に割り当て得、次に、ＬＬＣまたはメモリ帯域幅におけるキャッシュ容量などのプラットフォームリソースが、（優先化の必要性を満たすために、やはりＯＳ／ＶＭＭによって）各ＣＬＯＳについて設定され得る。そのような割り当ては、図４におけるＦａａＳシステム４００または図５におけるＦａａＳシステム５００のうち、いずれか１つを介して実行され得る。
例示的実装において、各ページテーブルエントリはＣＬＯＳタグによって強化され得る。ＣＰＵがトランスレーションルックアサイドバッファ（ＴＬＢ）ミスの間にページテーブルをトラバースするにつれて、ＣＬＯＳ属性が取得および使用され、ＴＬＢにキャッシュされ得る。このことは、アクセスされる各ページ上の各ラインについて、過去に可能であったものより細かい粒度のＱｏＳタギングを可能にするためにＣＬＯＳが提供され得ることを意味する。
今日、スレッドベースのタギングがデプロイされ得、互いの間でＦａａＳスレッドを優先化することを担い得るが、範囲またはアドレスベースのタギングの概念は、ＦａａＳスレッド内のデータも優先化されることを可能にし、ＦａａＳのより細粒度の性質により良く適合し得る。また、ＩｏＴ、産業用自動化、動き制御、およびリアルタイムコンピューティングなどの他の利用において、主要なメモリ範囲が優先化され、またはキャッシュにおいて「疑似ピニング」され得る、アドレスベースのタギングの技術的な利点もあり得る、それにより、前に利用可能であったものより細かい粒度の制御を可能にする。
展開プロセスの間、上記のアプローチは、ツールチェーンに統合され得、クリティカルデータは、リンカスクリプトの特定の部分においてタギングされ得、アドレス空間ベースのＱｏＳが優先化を確実にすることを可能にする。同様に、既知のストリーミングデータ（キャッシュを汚染し得る）は非優先化され得る。従って、特殊な利用について、アドレス空間ベースのＱｏＳは、既存のスレッドベースのタギング技術に追加の利益を提供し得る。
一実施形態において、図８Ａに関連して説明されたものと同様または同一の電子処理システムは、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを含み得、ソフトウェアまたはソフトウェアスレッドを優先化するためのオペレーションを実行する。いくつかの実施形態において、ロジックは、プロセッサ、メモリなどを含む様々なコンポーネントに、または、それらと同一の位置に（例えば同じダイ上に）配置され得る。
別の実施形態において、図８Ｂに関連して説明されるものと同一または同様の半導体パッケージ装置は、１または複数の基板、および、１または複数の基板に連結されるロジックを含み得る。ここで、ロジックは少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数に実装される。１または複数の基板に連結されたロジックは、ソフトウェアまたはソフトウェアスレッドを優先化するためのオペレーションを実行するよう構成され得る。いくつかの実施形態において、１または複数の基板に連結されるロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含み得る。
ここで図２１Ａを参照すると、この図は、一実施形態によるソフトウェアスレッドを優先化する方法２１５０を示す。ブロック２１５２において、方法２１５０は、ソフトウェアスレッドがハードウェア論理スレッド上で実行しているかどうかを判定するオペレーションを含む。ブロック２１５４において、ソフトウェアスレッドがハードウェア論理スレッド上で実行しているとき、タグがレジスタにスワップされ得る。最後に、ブロック２１５６において、１または複数のキャッシュ容量およびメモリ帯域幅が各タグに設定され得る。例示的実施形態によると、キャッシュ容量またはメモリ帯域幅の１または複数は、オペレーティングシステムおよび／または仮想マシンマネージャ（ＶＭＭ）によって設定され得る。
更に、例示的実施形態によると、データおよびアプリケーションは、ランタイム性能インジケータ、問題のあるメモリ領域またはエリアに基づいて、および／または、アクセスパターンに基づいて、ランタイムに異なる性能クラスに動的に移動され得る。
方法２１５０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法２１５０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法２１５０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法２１５０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
ページレベルＱｏＳ
ＣＰＵの性能は、低レイテンシ、高帯域幅メモリアクセスに大きく依存する。現代のＣＰＵアーキテクチャは、ＤＤＲなどの外部メモリの解決手段のレイテンシおよび帯域幅の制約を低減するために、複数のレベルのキャッシュに依存する。ＣＰＵの全体的な性能を改善するためにキャッシングが使用され得、キャッシュＱｏＳ（キャッシュ割り当て技術、ＣＡＴ）およびメモリ帯域幅割り当て（ＭＢＡ）などの機能（両方とも既存の機能）は、マルチコアプロセッサ内における特定のコアの性能をより大きくすることを確実にするための手段を提供する。ＣＡＴおよびＭＢＡは、多くの環境において利益を提供するが、スレッドレベルタギングに依存する。このことは、タグが適用された後（リソース制御のためのクラスオブサービス、ＣＬＯＳ、または、モニタリングのためのリソースモニタリングＩＤ、ＲＭＩＤ）、スレッドに関連するその後のアクティビティが制御および／またはモニタリングされることを意味する。しかしながら、現在、スレッドによってアクセスされるデータアドレスにセンシティブな方式でスレッドのデータ配置を制御する方法はない。特定のアドレスにもっとも重要なキャッシュミスが性能および実行ジッタに著しい影響を引き起こし得るリアルタイムまたは重要なスレッドにおいて、これは、もっともクリティカルなデータをキャッシュに保持するために調整および最適化することが難しいスレッドをもたらし得る。リアルタイム環境において、これらのキャッシュミスは、最悪実行時間を考えるときに想定され、したがって、決定的なリアルタイムワークロード完了時間を保証するためのプログラマーの能力に著しく影響する。
例えば、第１コア、コアＡが、定期的に１００μｓごとにデータＡ（＜１ＫＢ）を消費するワークロードを有するが、全体的なＬ３キャッシュを消費するストリーム処理オペレーションを実行する場合、データＡは強制的にＬ１、Ｌ２、およびＬ３キャッシュ、ならびに、第２レベルＴＬＢ（ＳＴＬＢ）におけるＴＬエントリからエビクションされ得る。次に１００μｓの定期的な頻度でデータＡに再アクセスするこのパターンを通じて、データＡのための仮想アドレスを変換する必要があるページウォークを含むＤＤＲからメモリをフェッチすることによって、予測不可能な追加のレイテンシがしばしば課され得る（トランスレーションは後にＴＬＢ／ＳＴＬＢ構造に格納されるが、後に、ストリーミングワークロードフェーズの大きいワーキングセットによって強制的に追い出される）。リアルタイム環境において、この追加のレイテンシは、使用可能な実行サイクルを更に低減させ得、総利用可能性能の７０％未満を残す。ワーストケースのキャッシュおよびＴＬＢ挙動を考慮してサイクルバジェットがパディングされる必要があるからである。１０μｓのオーダの頻度である、より厳しい制約を有するいくつかの場合において、実効性能は５０％未満であり得る。別の例として、実行の時間スライシングを通じてコア上のワークロードを混合することはまた、キャッシュおよびＳＴＬＢの負担を導入し得る。
強化ＦａａＳおよびリアルタイムの解決手段の例示的な実施形態は、キャッシュ階層が、不必要なエビクションおよび高価なページテーブルウォークを防止することによって、キャッシュにおけるデータブロックのレシデンシを改善することを可能にし得る。
加えて、例示的実施形態によると、ＣＬＯＳ選択がページ属性に追加され、キャッシュ階層に、クリティカルパス実行のためのキャッシュラインレシデンシを改善するための方法を提供し得る。オペレーティングシステムによってページテーブルに割り当てられる各ページは、ページについての選択されたＣＬＯＳを定義し得る。メモリ負荷／格納が発生し、データをキャッシュに運ぶ必要があるとき、ページ属性は、ＣＬＯＳが使用し得るキャッシュブロックを示し得る。具体的には、その方式により、空間を用意するためにエビクションすることが可能になる。同様に、ＳＴＬＢの場合、ページトランスレーションが読み取られるとき、ページ属性によって定義されるＣＬＯＳのために割り当てられたＳＴＬＢの特定の位置を有し得、従って、ＴＬＢエントリのレシデンシを改善する。換言すると、ＣＬＯＳタグは、重要なデータ（２つ上の段落の例におけるデータＡ）を、Ｌ１／Ｌ２／Ｌ３などのレベルおよび／またはＳＴＬＢにおけるキャッシュの保護パーティションに割り当てるために使用され得る。保護パーティションにおけるこのデータの存在は、それがエビクションされる可能性を除去する。このことは、必要なときデータが存在することを意味し、メモリからこのデータをフェッチする必要性によってもたらされる実行ジッタを低減する。
ページレベルＱｏＳは、データの各ブロックを個別に処理する能力を可能にする（この用語はまた、バイト、キャッシュライン、またはページレベルでの管理を指し得るが、実装の効率性のために、ページレベルが共通のアプローチであり得る）。命令は、特定の属性（ＣＬＯＳタグなど）を有するページにマッピングされ得、クリティカルパス実行の場合において、クリティカルパス命令は、特定のＱｏＳ要件を有する別個のページを有し得る。同様に、データについて、アクセスの頻度がより少ないクリティカルパスアイテムは、メモリアクセスの停止を防止する特定のＱｏＳ要件を有し得る。所望のＱｏＳタグ（例えばＣＬＯＳ）をページ属性に組み込むことにより、様々なキャッシュレベルで、ＣＡＴなどのキャッシュ制御機能、および、ＳＴＬＢパーティショニング機能とのより良い統合を可能にし得、決定的レシデンシ、および、よりシンプルなモデリングにより最悪実行時間を保証することを可能にする。
上記のアプローチは、コアレベルＱｏＳ（従来のＲＤＴ）の関連する解決手段と異なり得、ＣＬＯＳは、コア内に存在するすべての下流の構築を制御するレジスタを通じて定義される。セキュリティリスクに起因して、ＣＬＯＳは通常、ユーザ空間アプリケーションに利用可能でない権限レジスタを通じて制御される。このスレッドタギング実装を通じて、すべてのメモリオペレーションについて、実行中の所与の時間に、１つのＣＬＯＳだけがタスクによって使用され得る。コアレベルＱｏＳは、より問題があり得る。なぜなら、タスク内のすべてのデータが同一に処理されることを想定するからである（そして、コアレベル機能は、ＳＭＴの場合と同様、各コア上で複数のスレッドの存在下で管理するのがより難しい）。従って、利用前にアプリオリでＣＬＯＳが切り替えられデータがキャッシュに「プライム」される「疑似ロッキング」などの複雑な特別の利用フロー無しで、タスクは何のアイテムがＬ２またはＳＴＬＢキャッシュにおける特定のレシデンシ要件を有するかを制御できない。従って、そのような複雑なセットアップのステップ無しで、ストリーム処理オペレーションは、キャッシュにおけるすべてのクリティカルパスアイテムをエビクションし得る。更に、疑似ロッキングの解決手段は、場合によっては有効であるが、予測されないマイクロアーキテクチャの挙動に影響され得、キャッシング挙動に関する保証を構築することが非常に難しくなるという点で「脆弱」であり得る。コアあたり多くの統合されたタスクを有する実行環境も問題をもたらし得る。このシナリオにおいて、性能に影響することなく、タスクあたりのキャッシュの大きい量を取り除く能力は困難であり得る。
ページレベルＱｏＳは、ページレベルにおける一例の実施形態において、ページテーブルにおけるエントリにＣＬＯＳ定義を追加することによって、ランタイムサービス品質を改善するための手段を提供し得る。予期される利用率は、以下のシナリオによって示され得る。例えば、実行のためにアプリケーションが用意されるとき、オペレーティングシステムは、アプリケーションのバイナリセクションすべてをメモリに配置するためにページを割り当て得る。バイナリの各セグメントは、オペレーティングシステムから見られるいくつかの手段によってＣＬＯＳでタギングされ得、決定された、そのＣＬＯＳでタギングされた割り当てページに配置され得る。これにより、アプリケーションの異なるセグメントが、全体のサービス品質を改善するためにより高い、または、より低い優先度を有することを可能にし得るがより重要なこととして、重要なページにおけるクリティカルなデータについては、それらはより高い確率でキャッシュ／ＴＬＢに維持されることができ、よりシンプルなインタフェースが（データのこれらの領域をキャッシュ／ＴＬＢにロードするためのページレベルインタフェースを通じて）提供される。
ページが割り当てられるとき、各ページエントリは、ページが表すメモリについてＣＬＯＳを定義するための追加ビットと共にページテーブルに追加され得る。ランタイムにおいて、ページエントリは、仮想－物理アドレス変換を提供するためにＣＰＵによって取得され得る。このポイントにおいて、ＣＬＯＳは、アクセスするメモリについて識別され得る。ＣＬＯＳは、キャッシュ階層がどのようにパーティショニングされるかを定義し得るので、メモリは、そのＣＬＯＳについてパーティションによって定義される共有リソース（キャッシュレベルのＳＴＬＢなど）の領域にロードされ得る。エビクションの場合、キャッシュの特定のパーティションに対するアクセスを有する新しいメモリリクエストだけが、キャッシュパーティションからアイテムをエビクションし得る。このことは、別個のパーティションにおける重要なデータがエビクションから保護されることができることを意味する。これにより、確保されるパーティションについてキャッシュにおけるアイテムについてレシデンシを劇的に改善し得、従って、別の（おそらくよりロバストな）疑似ロッキングの手段を提供する。ランタイム中のメモリアプリケーションの場合、メモリをヒープに割り当てるためのオペレーティングシステムコールに、作成されるべき新しいページテーブルエントリについて選択されたＣＬＯＳが追加的に提供され得る。
ここで図２１Ｂおよび図２１Ｃを参照すると、これら２つの図は、強化ＦａａＳアーキテクチャにおいてページレベルＱｏＳを提供するために、ページテーブルにおいてタスクとＣＬＯＳとの間のインタラクションを示す。ページレベルＱｏＳは、プログラムのセグメントを別個のＣＬＯＳにパーティショニングすることによって、利益を提供し得、特定のセグメント、または、セグメント内の特定のデータのいずれかが、キャッシュ／ＴＬＢにおいて特別に優先化または保護されることを可能にする。図２１Ｂにおいて、アプリケーション２１６０は、３つの別個のタスクを有し得る（例えば、タスク０、タスク１、タスク２）。各々は、特定のリアルタイム決定的要件を有する。これらのタスクの各々は、コードおよびデータ（．ｂｓｓおよび．ｔｅｘｔ）について自身のセグメントを有し、実行中の特定のキャッシュパーティショニングを可能にし、一方で、グローバルプロセスレベルコンテキストをなお共有する（例えば、マルチスレッドアプリケーションの場合と同様）。データ２１６１およびコード２１６２はタスク０に関連し、データ２１６３およびコード２１６４はタスク１に関連し、データ２１６５およびコード２１６６はタスク２に関連する。各タスクのコードおよびデータは、キャッシュの特定のパーティションに標的化され、実行時間に対しより高い決定性を提供し、より厳密な最悪実行時間計算を可能にする。図２１Ｂの例示的な実施形態によれば、．ｂｓｓおよび．ｔｅｘｔセグメントは、同一のクラスオブサービスを共有し得るが、メモリサイズの制約および必要な決定性の度合いに基づいて更にパーティショニングされ得る。
ここで図２１Ｃを参照すると、ランタイムにおいて、タスク０は、ＣＰＵコア０Ｌ２およびＬ３キャッシュのパーティションとして、メモリアロケータＣＬＯＳ３に、ヒープデータ２１７０をリクエストし得る。タスク１はまた、ＣＰＵコア１ Ｌ２およびＬ３キャッシュのパーティションとして、ＣＬＯＳ４にヒープデータ２１７１をリクエストする。ＣＰＵコア０については、以下のように、および、図２１Ｃに示されるように、例示的なタイトループがセンサデータに対して実行され得る。
（１）センサデータがＰＣＩ－Ｅ ＤＭＡを通じてＬ３／ＬＬＣに配置される。例えば、インテル（登録商標）ＤＤＩＯフィーチャは、メモリに格納されたいくつかのデータを、Ｌ３／ＬＬＣキャッシュの専用エリアにキャッシュする。
（２）タスク０は、入力センサデータを消費し、ＣＬＯＳ３ Ｌ２キャッシュパーティションにストリーミングし、一方、ｂｓｓ＿ｃｌｏｓ＿０ ｄｓにおいてデータを同様に更新する。
（３）タスク０は、ｂｓｓ＿ｃｌｏｓ＿２内のデータを通じてタスク２についての出力を生成し、ステップ１にループバックする。
ＣＰＵコア１について、タスク１は、タスク０またはタスク２のいずれかに対するデータ相関無しで、外部割込みに基づいてタスク０と非同期的に実行し得る。リアルタイム決定性に起因して、タスク１のキャッシュにおけるレシデンシはクリティカルであり得る。
ＣＰＵコア１について、タスク２は、以下のようにｂｓｓ＿ｃｌｏｓ＿２へのタスク０の出力に揃えてアイソクロナスに実行され得る。
１）ｂｓｓ＿ｃｌｏｓ＿２を通じてタスク０から出力を読み取る。
２）ＣＰＵコア１Ｌ２およびＬ３キャッシュにおけるＣＬＯＳ４を用いて出力データ書き込みを生成する。
３）ＰＣＩ－Ｅ上のＮＩＣがＬ３からの出力データを読み取る。
ここで図２１Ｄを参照すると、この図は、スレッドレベルＱｏＳがＣＬＯＳを定義するために使用されることを除き、図２１Ｃにおける同様のシナリオを示す。第１に、ＣＰＵコア０ ２１８０に関して、特別なソフトウェアベースの技術、および、それをサポートするよう特別に調整されたキャッシュ階層無しで、タスク０だけがＣＰＵコア０ ２１８０上で実行しているので、センサデータにおいてストリーミングするときにｔｅｘｔ＿ｃｌｏｓ＿０ ｏｒ ｂｓｓ＿ｃｌｏｓ＿０のレシデンシを増加させるためにキャッシュをパーティショニングするための手段が無いことがあり得る。これにより、キャッシュにおいて不要なエビクションが生じ、追加のキャッシュミスが発生したときに全体的な決定性が低減し得る。次に、ＣＰＵコア１ ２１８１に関して、パーティショニングはなおタスク１とタスク２との間に存在し得るが、ストリーミングされたヒープ出力データへの書き込みはＣＬＯＳ２と組み合わされ得る。これは、ｂｓｓ＿ｃｌｏｓ＿２およびｔｅｘｔ＿ｃｌｏｓ＿２への不要なエビクションを生じさせ得、送信されることが命令されたセンサ（または、この場合パケット）データの間のタイミングと、ＮＩＣが実際に送信されるときとの間の決定性を更に低減する。換言すると、キャッシュの共有に起因して、アプリケーションが送信するためのコマンドを発行する時間と、データが実際に有線で送信されるときとの間に非決定的なレイテンシがある。このレイテンシは、ＰＣＩｅデバイスが、メモリからデータを読み取る必要があるという事実に起因する。それはキャッシュでもよく、または、そうでなくてもよい。最終的に、キャッシングのこの不確実性は、非決定性および実行時間におけるジッタをもたらす。
最大の決定的メモリブロックであるＬ３キャッシュ２１８２に関して、ヒープ入力および出力データがクリティカルなコードおよびデータの更なるエビクションを生じさせ得るように粒度が低減される。Ｌ２エビクションは、不要なレイテンシをＬ３キャッシュ２１８２に追加するが、外部メモリからデータをフェッチする必要があることは、ダイメモリブロックと比べて、著しく大きいレイテンシおよびジッタを追加し得る。
ページレベルＱｏＳを実装することにより、キャッシュにおけるデータ／命令レシデンシに基づいて、より決定的なモデルが展開され得、より厳密なリアルタイム実行の制約およびより高いコア利用率を可能にする。高い重要度の主要なＦａａＳワークロードにとって、これは著しい進歩である。
追加の留意点および例
例２１０１は、ソフトウェアスレッドがハードウェア論理スレッド上で実行しているかどうかを判定する段階と、ソフトウェアスレッドがハードウェア論理スレッド上で実行しているとき、タグをレジスタにスワップする段階と、各タグについてキャッシュ容量およびメモリ帯域幅の少なくとも１つを設定する段階とを含む方法を含む。
例２１０２は、例２１０１の方法を含み、タグはページテーブルからのクラスオブサービス（ＣＬＯＳ）タグである。
例２１０３は、例２１０１の方法を含み、キャッシュ容量およびメモリ帯域幅の少なくとも１つは、オペレーティングシステムおよび仮想マシンマネージャのうちの１つによって設定される。
予測可能なＦａａＳスループットおよび統合された同時スレッドの数に関係のない公平性の保証
例示的実施形態によると、決定性および公平性を保証するハードウェアまたはソフトウェアの解決手段がＦａａＳ環境において提供され得る。それらは、一貫性、正確性、および課金の公平性を確実にするために実装され得る。ＦａａＳリソースの管理およびモニタリングは、リソース利用に対する正確な課金を確実にすることと一致するように設計される。
ＦａａＳリソース利用の評価における公平性は必要である。なぜなら、テナントは、ＦａａＳリソースが使用されるときに支払うので、同一のワークロードが繰り返し呼び出されることを考えると、別のテナントのスレッドのアクティビティによって引き起こされる１つのテナントのスレッドの遅れは、不公平性、または、ランタイムの変動（したがって、課金の変動）を引き起こし得るからである。従って、ＣＰＵスケジューリングの量は、公平性を確実にするように調整され得、課金統計値が、所与のＣＰＵ時間および全体の公平性を測定するために使用され得る。また、アウトオブバンド（ＯＯＢ）テレメトリが、現在実現されている公平性の度合いを理解するために、モニタリング用途において役割を担い得る。しかしながら、下記のように制御は重要である。
例示的実施形態によると、決定性および公平性を保証するための少なくとも２つのアプローチがある。すなわち、（１）関数の各々が共有リソースへの等しいアクセスを有することを確実にするために共有リソースをパーティショニングすること、または、（２）以下のオペレーションを行うハードウェアまたはソフトウェア性能管理コントローラを実装することである。
ａ．モニタリングおよび制御
ｂ．動的関数リソース制御および移行
図２２は、ＦａａＳ環境において決定性および正確性を提供するための例示的アーキテクチャを示す。図２２において、コンピューティングデバイス、例えば性能コントローラ２２１０は、すぐ上の段落におけるａおよびｂのオペレーションを実行し得る。コンピューティングデバイス２２１０はまた、履歴ベースのリソーススケジューリングを提供し、呼び出しのためにデータを適切なコアへリダイレクトし、データ共有を最大化し、データ移動を最小化し、サービス水準合意に従って関数をバンドルし得る。コンピューティングデバイス２２１０の上記オペレーションはまた、ソフトウェアを介して実装され得る。
決定性および公平性を確実にするために、コンピューティングデバイス２２１０またはソフトウェアは、特にＬ２が満たされるときに、異なるコア２２２０、２２３０によって処理されるように、Ｌ２キャッシュを分割し得る。
例示的実施形態によると、コンピューティングデバイス２２１０は、データからコードを分割し得る。加えて、バランスをとることを確実にするために関数は移動され得る。例えば、１つのリソースがバックエンドで重い場合、関数は混合され、スケジューラに基づいて異なるコア上にマッチングされ得る。加えて、コンピューティングデバイス２２１０は、時間リソースを動的に再割り当てし得る。
ランタイム２２４０は、図２２のアーキテクチャで実装されても、されなくてもよい。実装されるとき、オペレーティングシステム固有のコールを回避するために、関数は、インフラストラクチャからサービスおよび命令を取得するようにランタイムをコールし得る。
ＦａａＳの課金の正確度の増加
課金のためのソフトウェアベースの時間サンプリングのアプローチは、スキューおよび高いオーバヘッドという問題があるのでＦａａＳに不適切であり得る。課金がミリ秒に基づく場合、コンピューティングリソース利用がマイクロ秒単位で測定され得るような粒度が必要である。
データセンタにおいてワークロードのタイムスケールが減少するにつれて、細粒度のモニタリングおよび課金がますます重要となる。ＦａａＳは、ミリ秒まで下がった顧客課金を可能にするよう設計され、オペレータは、正確度を確実にするためにマイクロ秒レベルで検証可能な課金精度を維持する必要がある。従って、最小限のオーバヘッドを有する、そのような課金をサポートするハードウェア技術が必要となり、複数の技術は下に説明される。
例示的実施形態によると、低いオーバヘッドを有し、インフラストラクチャによる周期的な課金統計値のオンデマンド取得を可能にする課金管理およびモニタリングへのハードウェアアプローチが提供される。この例示的な実施形態は、ＦａａＳ関数のコンテキストスワップパスから、時間アカウントオーバヘッドを除去し得、オーバヘッドおよびコストを改善する。
ＶＭについての課金を例にとると、従来、ＶＭはウェブベースのコンソールまたはモバイルアプリケーションを通じて管理され得、管理者によってオンデマンドでスピンアップまたはスピンダウンされることができる。しかしながら、通常、課金は分単位を基礎として管理される。この粗い粒度の課金は、インフラストラクチャにおいて低コストであり、顧客による管理および検証が容易である。すなわち、そのようなシステムの要件は低い（すなわち、基本的なトラッキングおよび時間同期インフラストラクチャ、ならびに、ＮＴＰなど既存のプロトコルがこの目的に適切である）。
ＦａａＳに必要な細粒度課金において、ＶＭの場合について上述した粗い粒度の課金など従来の技術は不適切であり得る。ＯＳ時間ＡＰＩのソフトウェアベースの時間サンプリングは、スキューの問題があり、関数呼び出し／終了の高い速度は、時間値を収集し、時間スタンプ間の差異を計算することなどのための高いオーバヘッドをもたらし得る。これは、（１）オペレータコストの増加、および、（２）ランタイムについての顧客プロファイルと、オペレータが報告することとの間のミスマッチの可能性をもたらし得る。累積的な低精度および経時的な不正確性は、これらの問題を更に悪化させる。
ハードウェアアプローチは、ソフトウェアの解決手段と対照的に、非常に低いオーバヘッドを伴い、インフラストラクチャによる周期的な課金統計値のオンデマンド取得を可能にし得る。ハードウェア支援ＦａａＳ課金が、関数または特定のスレッド、および、システムにおけるその対応するアクティビティを一意に識別するための複数のタギング技術または解決手段が可能であり、以下を含むがそれらに限定されない。
１）リソースモニタリングＩＤ（ＲＭＩＤ）技術－ＯＳ／ＶＭＭがＲＭＩＤをスワップするとき、ＦａａＳ関数をトラッキングするために、ＲＭＩＤリソーストラッキングタグが使用され得る。各関数（または各テナント）にはＲＭＩＤが割り当てられ得、新しいＣＰＵハードウェアが構築され得る、または、（細粒度時間ベースまたはＣＰＵ参照クロックサイクルのいずれかで）ＣＰＵ上のＲＭＩＤ時間をトラッキングすることが可能になり得る。次に、ＲＭＩＤおよび時間利用を報告する新しいＭＳＲまたはＭＭＩＯブロックを介して、新しいＲＭＩＤごとのイベントコードが報告され得る、または、リソース利用が報告され得る。
２）プロセスアドレス空間ＩＤ（ＰＡＳＩＤ）技術－例示的実施形態によると、ＰＡＳＩＤは、ＰＣＩｅ ｇｅｎ ３仕様追加の一部として導入される２０ｂのタグである。ＰＡＳＩＤは、各コアに割り当てられ得、スケーラブルＩ／Ｏ仮想化（ＳＩＯＶ）のような他のフィーチャと共に使用され得る。ＰＡＳＩＤごとに使用されるＣＰＵ時間をトラッキングするために、新しいハードウェアが構築され得る、または、有効化され得るので、これは、一意関数コンピュート時間利用をトラッキングするのに非常に効率的な方式であり得る（上記のＭＭＩＯベースまたはＭＳＲベースと同様の実装オプションがこの技術と共に利用可能である）。各ＰＡＳＩＤによって消費されるＣＰＵサイクルをトラッキングするためのカウンタのトラッキングシステムの追加は、このアプローチの実装の重要な一部である。
３）ロジックプロセッサＩＤ（ＬＰＩＤ）技術、またはスレッドごと、もしくは、コアごと－ロジックプロセッサＩＤ，スレッド、またはコアは、ＰＡＳＩＤおよびＲＭＩＤと同様に使用され得、同様に、インスタンスごとのカウンタが、ＣＰＵ利用をトラッキングするために追加され得る。これは、各コンテキストスワップでこれらのカウンタを読み取る可能性のためにＯＳ／ＶＭＭを必要とする。または、ソフトウェアの代わりに、これらの結果を集約するためにハードウェアが必要となる。
４）制御レジスタＣＲ３ベースの技術－ベースページテーブルアドレスがプロセスの基礎を形成する場合、一意制御レジスタＣＲ３ごとにハードウェアカウンタにおけるＣＰＵ時間をトラッキングする。ＣＲ３の一意の値ごとに消費される時間またはサイクルが、ＣＰＵ利用をトラッキングするべくトラッキングされ得る（例えば、もっともアクティブなＣＲ３の場合、コストを低減する）。
５）ＶＭ ｖＣＰＵベースの技術－（ＶＴ－ｘアーキテクチャに関連付けられ得る）ＶＭ仮想ＣＰＵＩＤごとにハードウェアカウンタを割り当てる－そのようなカウンタは、ｖＣＰＵの各々についてＣＰＵ利用をトラッキングし得る（実際には、上記のような他お技術も、非仮想化の場合の利用をトラッキングするべく必要となる）。
６）リモートアトミクス（ＲＡＯ）ベースの技術－ＲＡＯは、ＣＰＵ時間をトラッキングするのに使用され得るアンコアでロジックを構築し得る。例えば、ポスティングされたＲＡＯ命令は、ハードウェアによる（または明示的にソフトウェア）による自動的な各コンテキストスワップにおいて、「Ｘサイクルだけインクリメントする」を所与のプロセスＩＤ／ＰＡＳＩＤ／ＲＭＩＤなどについて、トラッキングハードウェアへ送信するのに使用され得る。これは、サーバハードウェアの将来の世代を用いて始動するソフトウェアにおけるＲＡＯの変形により可能となり得る。高性能を実現するために、アンコアは、コアに無いが、コアに密接に接続され得るマイクロプロセッサの関数を反映し得る。アンコアは、例えば、キャッシング、メモリコントローラアクセス、Ｉ／Ｏデバイスアクセス（例えばＰＣＩｅを介する）などのような機能、および、通常は、すべての関数をつなげるための高性能相互接続を提供し得る。
６）リモートアトミクス（ＲＡＯ）ベースの技術－ＲＡＯは、ＣＰＵ時間をトラッキングするのに使用され得るアンコアでロジックを構築し得る。例えば、ポスティングされたＲＡＯ命令は、ハードウェアによる（または明示的にソフトウェア）による自動的な各コンテキストスワップにおいて、「Ｘサイクルだけインクリメントする」を所与のプロセスＩＤ／ＰＡＳＩＤ／ＲＭＩＤなどについて、トラッキングハードウェアへ送信するのに使用され得る。これは、Ｓａｐｐｈｉｒｅ Ｒａｐｉｄｓ Ｓｅｒｖｅｒで始動するソフトウェアにおけるＲＡＯの変形により可能となり得る。アンコアは、コアに無いが、高性能を実現するためにコアに密接に接続され得るマイクロプロセッサの関数を反映し得る。
上記タギング方式の１または複数において、オンデマンドでカウンタをサンプリングし／読み取り、選択的に、オンデマンドでカウンタを消去する機構も（例えば、新しいテナントのためにＰＡＳＩＤまたはＲＭＩＤを再割り当ておよびリサイクルするために）必要であり得る。例示的実施形態によると、上記タグは、ＯＳまたは他のハードウェアによって割り当てられ得る。
一実施形態において、図８Ａに関連して説明されたものと同様または同一の電子処理システムは、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを含み得、リソース利用を計算するためのオペレーションを実行する。いくつかの実施形態において、ロジックは、プロセッサ、メモリなどを含む様々なコンポーネントに、または、それらと同一の位置に（例えば同じダイ上に）配置され得る。
別の実施形態において、図８Ｂに関連して説明されるものと同一または同様の半導体パッケージ装置は、１または複数の基板、および、１または複数の基板に連結されるロジックを含み得る。ここで、ロジックは少なくとも部分的に、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数に実装される。１または複数の基板に連結されたロジックは、リソース利用を計算するためのオペレーションを実行するよう構成され得る。いくつかの実施形態において、１または複数の基板に連結されるロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含み得る。
ここで図２３を参照すると、この図は、例示的実施形態による、課金の目的でリソース利用を計算するための方法２３００を示す。ブロック２３１０において、方法２３００は、ＣＰＵ上のリソースモニタリング識別子（ＲＭＩＤ）時間をトラッキングするオペレーションを含む。ブロック２３２０において、ＲＭＩＤ時間は報告され得る。ブロック２３３０において、カウンタ消去モジュールは、オンデマンドでカウンタを保存および／または消去し、ＲＭＩＤを再割り当てするよう構成され得る。
追加の留意点および例
例２３０１は、中央演算処理装置と、リソースモニタリング識別子（ＲＭＩＤ）を使用して電源管理ユニットにおいてパーティショニングし、ＣＰＵ上のリソースモニタリング識別子（ＲＭＩＤ）時間をトラッキングするよう構成されるリソースモニタリングハードウェアモジュールと、ＲＭＩＤ時間を報告するよう構成されるコード報告ハードウェアモジュールとを含む装置を含む。
例２３０２は、ハードウェアイベントをカウントするためのハードウェアカウンタがＲＭＩＤごとに割り当てられる、例２３０１の装置を含む。
例２３０３は、カウンタ消去モジュールを更に含む、例２３０１の装置を含み、カウンタ消去モジュールは、オンデマンドでカウンタを消去し、ＲＭＩＤを再割り当てするよう構成される。
インテリジェントテレメトリによってガイドされるスケジューリングの例
従来のスケジューラ／オーケストレータは、関数がどのように挙動したかについてのフィードバック無しで、可用性に基づいて関数を分散する。図５に関連して上述されたものなどの、強化ＦａａＳの解決手段のいくつかの実施形態は、関数が実行されるときの挙動についての情報を収集し（例えば、関数が非常に多くの時間を消費した、非常に多くのキャッシュを使用した、など）、収集された情報に基づいて、より良いスケジューリング／オーケストレーションを決定し得る。例えば、様々なハードウェアアーキテクチャは、関数の挙動に関連する有用な情報を提供し得る多くのカウンタを提供し得る。いくつか実施形態は、（例えば、すべてのデータポイントの代わりに）関数に関連する情報の統計値を収集し得る。例えば、収集された情報のデータベースは、将来のルーティング決定のために、スケジューラ／オーケストレータによって維持および使用され得る。有利なことに、いくつかの実施形態は、より良い分散の決定を行い、より良いリソース利用などを提供し得る。
ここで図２４Ａを参照すると、分散コンピューティング環境２４４０の実施形態は、１または複数の実行環境（例えばプラットフォーム、サーバなど）２４４２に通信可能に連結される強化ＦａａＳシステム２４４１を含み得る。強化ＦａａＳシステム２４４１は、関数をスケジューリングし、実行環境２４４２にルーティングするためのオーケストレータ２４４３を含み得る。実行環境２４４２は、関数の実行に関連する情報を収集するよう構成され得るデータ収集モジュール２４４４に通信可能に連結され得る。データ収集モジュール２４４４は、（例えば、個別に、サマリ形式で、収集された情報に関連する統計値として、いくつかの構造化データベースにおいて、など）収集された情報を格納し得るデータストア２４４５に通信可能に連結され得る。オーケストレータ２４４３は、関数をどのようにスケジューリングおよびルーティングするかについて決定するために格納データを利用するべく、データストア２４４５に通信可能に連結され得る。いくつかの実施形態において、オーケストレーションおよび／またはデータ収集は、特定の利用レベルに到達する関数だけで実装され得る（例えば、インスタンス化が１０００を下回る関数は、収集データに基づいてオーケストレーションされないが、インスタンス化が１０００を超える関数は、収集されたデータを有し、収集データに基づいてオーケストレーションされる）。いくつかの実施形態において、関数がよく知られた後（例えば、予め定められた閾値時間にわたって関数が実行された後）、収集は停止され得る。
詳細には、オーケストレータ２４４３は、関数をルーティングし、それらを実行する強化ＦａａＳシステム２４４１などのシステムにスケジューリングする。オーケストレータ２４４３は、フリーサイクルを有するシステムおよび／またはサブシステムを発見し、関数実行をそれらにルーティングできる。オーケストレータ２４４３のいくつかの実施形態は、より効率的で、より経済的な実行のために、関数の前の実行からのテレメトリ情報を使用するインテリジェントスケジューラを提供し得る。テレメトリ情報は、ホスティングシステム上のイベントのシームレスな統計サンプリング、関数の静的および動的プロファイル情報を収集するためのコードの静的または動的インストルメンテーションを含む様々な方式で収集され得る。収集され得るイベント情報の非限定的な例は、データ／命令キャッシュミス、分岐予測ミス、サーマルカウンタ、ＩＰＴ、ＲＤＴなど（例えば、ＣＳＭＥによる、インバンド（ＣＰＵ上）、または、アウトオブバンド）のマイクロアーキテクチャイベント情報を含む。収集され得る他の情報の非限定的な例は、関数の動的コールグラフ、基本ブロックカウント、ＡＰＩコールなどを含み得る。収集された情報は、関数に対応する静的／動的プロファイル情報として整理され得る。
オーケストレータ２４４３のインテリジェントテレメトリ誘導スケジューラの実施形態は、関数についての収集された情報（例えば、または情報のサマリ）を使用して、関数の実行によく適した、または、もっとも適した（例えば、利用可能なリソース、十分なコンピュート、メモリ、ストレージなど）システムまたはシステム／サブシステムのプールへ関数を動的にルーティングし得る。収集されたテレメトリ、および、関数についてのプロファイル情報の適切な事前処理により、インテリジェントスケジューラは、制御下のシステムのリソースの可用性に迅速にアクセス可能であり得る。例えば、スケジューラは、関数のスケジューリングに必要なキャッシュの量が十分であるシステムまたはシステムのプールを識別し得る。収集された情報の粒度は、実装に応じて変動し得るが、インテリジェントスケジューラの実施形態は、関数が必要とするベクトルを、利用可能なシステムのものにマッチングさせる問題を解決し得る。より多くの関数が実行するほど、予測される挙動についてのより正確な情報をスケジューラが有し得るという点で、スケジューラは、インテリジェントであるとみなされ得る。
テレメトリ誘導スケジューリングの一例において、オーケストレータ２４４３のインテリジェントスケジューラの実施形態は、エラーを予測し、防止し得る。例えば、オーケストレータ２４４３のインテリジェントスケジューラのいくつかの実施形態は、どの関数が実行していたか、リソース利用ベクトル（例えば、電力プロファイルなどを含む）などを含む、クラッシュポイントにおけるシステム２４４１の状態を記録し得る。インテリジェントスケジューラは潜在的に、エラーの多くの場合を参照し、システム状態に迅速にマッチングするために（例えば、潜在的なエラーを予測するために）ディープニューラルネットワークＤＮＮを形成し得る。
いくつかの実施形態において、コンパイラは、コンパイル性能の増加のために、プロファイル誘導最適化（ＰＧＯ）またはフィードバック指向最適化（ＦＤＯ）を使用し得る。イベントがトリガするときに関数を実行するために多くのノードが利用可能であり得る。様々なノードは、異なる長所／機能を有し得、どこで関数が実行されるかについて、大きな、または完全な柔軟性があり得る。オーケストレータ２４４３は関数を受信し、実行のためにそれをどのようにルーティングするかを決定する。いくつかの実施形態において、関数が実行されるとき、オーケストレータ２４４３によって関数の挙動についての情報（例えば、キャッシュミス、実行タイミングなど）が収集され得る。いくつかの実施形態は、多くのカウンタを使用してプログラム情報を収集し得る、および／または、データを収集するために関数が計測され得る（例えば、および／または、情報を収集するためにタイマが使用され得る）。また、インストルメンテーションは、コードを高速化するためのコードの修正をもたらし得る（例えば、行列の積が識別され、次回にコードを計測して特定のサーバ上でハードウェアを利用する）。収集データは、関数をどこで実行するかについてのプロファイル誘導最適化のためにコンパイラが利用し得る関数についてのプロファイルを形成し得る。
オーケストレータ２４４３のいくつかの実施形態はまた、ジャストインタイム（ＪＩＴ）の適合のために、将来に関数（例えば、ＡＳＩＣ、ＧＰＵ、ＦＰＧＡなどのハードウェア実装を含む、高速化された関数）が分散されるときにプルインされるリソースについての決定を変更することを含み得る。収集データは、データベース、または、データストア２４４５などのデータストアに格納され、実行中のエラーを識別するためにサンプリングされ得る。エラーに基づいて、オーケストレータ２４４３のいくつかの実施形態は、理想的なリソース割り当ておよびサーバを識別し得る（例えば、関数が大きいキャッシュを使用することをプロファイルが示す場合、オーケストレータ２４４３は、エラーを回避するために、大きいキャッシュ割り当てを有するサーバへ関数をルーティングし得る）。オーケストレータ２４４３のいくつかの実施形態は、生成されたプロファイルを利用してプロファイル誘導最適化を提供し、リソースの選択を最適化するために可能性のある結果を識別し得る。例えば、オーケストレータ２４３３のいくつかの実施形態は、関数を解析し、キャッシュ使用を最大化し得る（例えば、異なるユーザに動画をストリーミングする２つの関数が同一のサーバにプッシュされ得る）。
ここで図２４Ｂを参照すると、ファンクションアズアサービスを提供する方法２４３０の実施形態は、ブロック２４３１において、実行された関数に関連する挙動関連情報を収集する段階と、ブロック２４３２において、収集された挙動関連情報に基づいて後の関数管理決定を行う段階とを含み得る。方法２４３０のいくつかの実施形態は、ブロック２４３３において、収集された挙動関連情報に関連する統計値を決定する段階と、ブロック２４３４において、決定された統計値に基づいて後の関数管理決定を決定する段階とを更に含み得る。例えば、関数管理決定は、ブロック２４３５において、スケジューリング決定およびオーケストレーション決定のうち１または複数を含み得る。
方法２４３０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法２４３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法２４３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法２４３０は、以下の例２４１１から２４１３に関連し記載されたコンピュータ可読媒体に実装されてよい。方法２４３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、ＦＰＧＡビットストリーム、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例２４００は、命令セットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、実行された関数に関連する挙動関連情報を収集させ（挙動関連情報は、１または複数のインバンド情報およびアウトオブバンド情報を含む）、収集された挙動関連情報に基づいて、後のジャストインタイム関数管理決定を行わせる。
例２４０１は、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを含む電子処理システムを含み、プロセッサによって実行された関数に関連する挙動関連情報を収集し、収集された挙動関連情報に基づいて後の関数管理決定を行う。
例２４０２は、例２４０１のシステムを含み、ロジックは更に、収集された挙動関連情報に関連する統計値を決定し、決定された統計値に基づいて後の関数管理決定を行う。
例２４０３は、例２４０１から２４０２のいずれかのシステムを含み、関数管理決定は、スケジューリング決定およびオーケストレーション決定のうち１または複数を含む。
例２４０４は、１または複数の基板と、１または複数の基板に連結されたロジックとを備える半導体パッケージ装置を含み、ロジックは、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数に少なくとも部分的に実装され、１または複数の基板に連結されるロジックは、実行された関数に関連する挙動関連情報を収集し、収集された挙動関連情報に基づいて後の関数管理決定を行う。
例２４０５は、例２４０４の装置を含み、ロジックは更に、収集された挙動関連情報に関連する統計値を決定し、決定された統計値に基づいて後の関数管理決定を行う。
例２４０６は、例２４０４～２４０５のいずれかの装置を含み、関数管理決定は、スケジューリング決定およびオーケストレーション決定のうち１または複数を含む。
例２４０７は、例２４０４～２４０６のいずれかの例の装置を含み、１または複数の基板に連結されたロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例２４０８は、実行された関数に関連する挙動関連情報を収集すること、および、収集された挙動関連情報に基づいて後の関数管理決定を行うことを含むファンクションアズアサービスを提供する方法を含む。
例２４０９は、収集された挙動関連情報に関連する統計値を決定する段階、および、決定された統計値に基づいて後の関数管理決定を行う段階を更に含む、例２４０８の方法を含む。
例２４１０は、例２４０８から２４０９のいずれかの方法を含み、関数管理決定は、スケジューリング決定およびオーケストレーション決定のうち１または複数を含む。
例２４１１は、命令セットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、実行された関数に関連する挙動関連情報を収集させ、収集された挙動関連情報に基づいて後の関数管理決定を行わせる。
例２４１２は、更なる命令セットを含む、例２４１１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、収集された挙動関連情報に関連する統計値を決定させ、決定された統計値に基づいて、後の関数管理決定を行わせる。
例２４１３は、例２４１１～２４１２のいずれかの少なくとも１つのコンピュータ可読記憶媒体を含み、関数管理決定は、スケジューリング決定およびオーケストレーション決定のうち１または複数を含む。
メモリ再使用を最大化するインテリジェント関数スケジューリングの例
図４の説明に関連して上記されたものなどの強化ＦａａＳシステムのいくつかの実施形態は、有利なことに、メモリ再使用を最大化するためのインテリジェント関数スケジューリングを提供し得る。メモリは限られたリソースであり、関数およびデータはメモリにおける空間を占有する。いくつかの実施形態は、同一の言語スタックの関数のインスタンスを同一の基礎システム／マシン／メモリへルーティングし得る。また、ＪＩＴ作成コードが複製され得、いくつかの実施形態において、複製ＪＩＴコードのインスタンスが同一の基礎システム／マシン／メモリへルーティングされ得る。いくつかの実施形態は、好ましくは、同一の言語（例えば、Ｊａｖａ（登録商標）、Ｐｙｔｈｏｎ（登録商標）など）を利用する関数を同一のマシンへルーティングし得る。追加的に、または代替的に、いくつかの実施形態は、共有データを同一のシステム／マシン／メモリ（例えばマップデータ）へルーティングし得る。
下の図２５Ａおよび図２５ＢにおけるＦａａＳシステム２５４０などの強化ＦａａＳシステムの実行環境は、関数の実行をサポートするために、共通コードライブラリ（例えば、動的リンクライブラリ（ＤＬＬ））および／または共通データ（例えば、データセット、データベース、マップデータなど）をロードし得る。そのような共有のライブラリは高価であり得、および／または、多くのデータを有し得る。強化ＦａａＳシステム２５４０のいくつかの実施形態は、有利なことに、共有ライブラリから利益を得るために、同一の言語の関数を同一のマシンへルーティングし得る。いくつかの実施形態において、共有ライブラリは、共有関数の異なるインスタンスのように処理され得る。いくつかのシステムにおいて、例えば、同一の関数のコンパイルされたコードは同様であり得る。また、強化ＦａａＳシステム２５４０のいくつかの実施形態は、共有データ（例えば、２つの関数は両方とも、同一のマップデータにアクセスし得、いくつかの実施形態は２つの関数を同一のマシンへルーティングし得る）およびリソースを活用し得る。
強化ＦａａＳシステム２５４０のいくつかの実施形態は、厳密に同一のビット列を有するメモリ領域（例えばキャッシュライン）の物理メモリの１コピーだけを使用することによって、より大きいメモリ帯域幅、および、より短いメモリアクセスレイテンシを可能にするメモリ再使用技術を含み得る。例えば、数千の異なるキャッシュラインがすべて、同一の値を有する場合（例えば、すべてのビットが０または１、または、０および１の任意の順列である場合）、物理メモリは、複製された領域の１つのコピーだけを格納する。メモリ再使用技術は、ハッシュと組み合わされた追加の間接参照を利用して、同一のメモリ位置を再使用し得る。しかしながら、領域の１つが変更された場合、新しい値のために新しい領域が作成され得る。順列が既に存在する場合、間接参照機構は、修正された領域をその既存の格納された値にマッピングする。メモリ再使用技術の特長は、データの重複を回避するために、すべてのビットの共通パターンが０または１であることである。強化ＦａａＳシステム２５４０のいくつかの実施形態は、データに加えて、関数コードについてメモリ再使用技術から利益を得る可能性を増加させ得る。
加えて、ＦａａＳプラットフォームにおける関数は多くの場合、マネージドランタイム上にある（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｙｔｈｏｎ（登録商標）、Ｊａｖａ（登録商標）、Ｃ＃など）。これらのプラットフォームの各々は、動的にロードおよびリンクされるＤＬＬなどの複数の共有ライブラリを有する。複数のアプリケーションが同一のＤＬＬを使用する場合、ＯＳは通常、メインメモリにおいて１つのＤＬＬを保持し、それは、そのＤＬＬをロードするすべてのアプリケーションについて共有される。加えて、これらのマネージドランタイムの大部分は、それらの高水準言語についての、動的にコードを生成するＪＩＴコンパイラを有する。強化ＦａａＳシステム２５４０のいくつかの実施形態は有利なことに、例えば、図２４Ｂに示されるオーケストレータ２４４３など、スケジューラ／オーケストレータを提供し得、同一の言語の関数、または、前にルーティングされた関数と同様または同一の更なる関数を同一のシステムまたは同一のシステムのプールにルーティングする。更に、同一のデータを使用する関数（例えば、同一のマッピング、同一の動画をストリームミングするなど）は、同一のシステムまたは同一のシステムのプールへルーティングされ得る。有利なことに、強化ＦａａＳシステム２５４０のいくつかの実施形態は、これらの異なる関数が多くの重複のコード／データ（例えば、静的コード、ＤＬＬ、ＪＩＴ生成コード、ＪＩＴ生成データなどに関して）を有する可能性を増加させ得る。メモリ再使用技術を備えたシステムは更に、いくつかの実施形態の恩恵を受け得る。なぜなら、メモリ再使用技術は実際には、キャッシュレベルを含む非常に細かいレベルで、各重複コードの１つのインスタンスだけを使用し得る。有利なことに、いくつかの実施形態は、帯域幅に関して、メモリへの負担を減少させ得、関数／アプリケーションは、使用するコードのより速いアクセスに加えて、データのためのより多くのメモリを有し得る。
いくつかの実施形態において、強化ＦａａＳシステム２５４０のシステムソフトウェアは、キャッシュライン境界においてメモリ再使用の可能性が高いデータ構造およびコードを揃えるよう構成され得る。加えて、０を用いる、いくつかのデータ構造の末端のパディングは、メモリ再使用技術から恩恵を受ける可能性を更に増加させ得る。また、関数／ワークロードの「書き込みセット」を低減または限定することは、書き込みがメモリ再使用技術のステージングエリア内に収まることを確実にすることに役立つことがあり得、書き込みセットが増加を開始するとき、メモリ重複の回避に関連するオーバヘッドの低減をもたらし得る。
ここで、図２５Ａ～図２５Ｂを参照すると、強化ＦａａＳシステム２５４０は、関数ｆおよび関数ｇを含む１または複数のトランジェント関数、および、関数のための１または複数のターゲットシステム２５５０を含み得る。各関数ｆまたはｇは、異なるデータおよびコードセクションに関連する異なるメモリ領域を有する（図２５Ａにおいて異なる影付きのエリアとして示される）。インテリジェントなオーケストレータ／スケジューラのいくつかの実施形態は、多く使用される重複メモリ領域（データおよびコードの両方）を動的かつシームレスにサンプリングし、それらを、実行している関数に関連付け、将来のスケジューリングシナリオにおいてその結果を使用し得る。例えば、いくつかの実施形態は、関数ｆ、ｇにおける共有情報２５４２を識別し、関数を同一のターゲットシステム２５５０へルーティングし得る（例えば、ターゲットシステム２５５０は既にロードされた共有情報２５４２を有し得るため）。
ここで図２５Ｃを参照すると、ファンクションアズアサービスを提供する方法２５３０の実施形態は、ブロック２５３１において、トランジェント関数に対応する共有情報を識別する段階と、ブロック２５３２において、識別された共有情報に基づいて、トランジェント関数を実行環境へルーティングする段階とを含み得る。方法のいくつかの実施形態２５３０は更に、ブロック２５３３において、前にルーティングされたトランジェント関数の新たなインスタンスを識別する段階と、ブロック２５３４において、新たなインスタンスを、前にルーティングされたトランジェント関数と同一の実行環境へルーティングする段階とを含み得る。例えば、共有情報は、ブロック２５３５において、共有コード、共有言語、および、共有データの１または複数を含み得、１つの関数によって生成され別の関数によって消費される一時的の情報の共有を更に含み得る。
方法の実施形態２５３０は、上の図２５Ａおよび図２５Ｂにおいて説明されたＦａａＳシステム２５４０などのシステム、装置、コンピュータ、デバイスなど、例えば、本明細書において説明されるものなどにおいて実装され得る。より具体的には、方法２５３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法２５３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法２５３０は、以下の例２５１１から２５１３に関連し記載されたコンピュータ可読媒体に実装されてよい。方法２５３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例２５０１は、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを備える電子処理システムを含み、トランジェント関数に対応する共有情報を識別し、識別された共有情報に基づいて、トランジェント関数を実行環境へルーティングし、識別された情報は少なくとも別の関数によって共有される。
例２５０２は、例２５０１のシステムを含み、ロジックは更に、前にルーティングされたトランジェント関数の新たなインスタンスを識別し、前にルーティングされたトランジェント関数と同一の実行環境へ新たなインスタンスをルーティングする。
例２５０３は、例２５０１～２５０２のいずれかのシステムを含み、共有情報は、共有コード、共有言語および共有データのうち１または複数を含む。
例２５０４ｈは、１または複数の基板と、１または複数の基板に連結されたロジックとを備える半導体パッケージ装置を含み、ロジックは、構成可能ロジックおよび機能固定型ハードウェアロジックの１または複数に少なくとも部分的に実装され、１または複数の基板に連結されるロジックは、トランジェント関数に対応する共有情報を識別し、識別された共有情報に基づいてトランジェント関数を実行環境へルーティングし、識別された情報は少なくとも別の関数によって共有される。
例２５０５は、例２５０４の装置を含み、ロジックは更に、前にルーティングされたトランジェント関数の新たなインスタンスを識別し、新たなインスタンスを、前にルーティングされたトランジェント関数と同一の実行環境へルーティングする。
例２５０６は、例２５０４～２５０５のいずれかの装置を含み、共有情報は、共有コード、共有言語および共有データの１または複数を含む。
例２５０７は、例２５０４～２５０６のいずれかの例の装置を含み、１または複数の基板に連結されたロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例２５０８は、ファンクションアズアサービスを提供する方法を含み、方法は、トランジェント関数に対応する共有情報を識別する段階と、識別された共有情報に基づいてトランジェント関数を実行環境へルーティングする段階とを含み、識別された情報は、少なくとも別の関数によって共有される。
例２５０９は、例２５０８の方法を含み、方法は更に、前にルーティングされたトランジェント関数の新たなインスタンスを識別する段階と、新たなインスタンスを、前にルーティングされたトランジェント関数と同一の実行環境へルーティングする段階とを含む。
例２５１０は、例２５０８～２５０９のいずれかの方法を含み、共有情報は、共有コード、共有言語および共有データの１または複数を含む。
例２５１１は、命令セットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、トランジェント関数に対応する共有情報を識別させ、識別された共有情報に基づいて、トランジェント関数を実行環境へルーティングさせ、識別された情報は、少なくとも別の関数によって共有される。
例２５１２は、更なる命令セットを含む、例２５１１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、前にルーティングされたトランジェント関数の新たなインスタンスを識別させ、前にルーティングされたトランジェント関数と同一お実行環境へ新たなインスタンスをルーティングさせる。
例２５１３は、例２５１１～２５１２のいずれかの少なくとも１つのコンピュータ可読記憶媒体を含み、共有情報は、共有コード、共有言語、および共有データのうち１または複数を含む。
コンテナ統合／分解および状態のアグリゲーションおよびディスアグリゲーションの例
図４の説明に関連して上記されたものなどの強化ＦａａＳシステムのいくつかの実施形態は、有利なことに、コンテナの統合および／または分解、および／または、状態のアグリゲーションおよびディスアグリゲーションを提供し得る。従来、関数は、関数間の関係を解析または考慮することなく、実行の独立ユニットとして処理され得る。これにより、場合によっては、リソースの最適化、または、ＩＯオーバヘッドの増加（例えば、ネットワークおよびローカル）が引き起されないことがあり得る。実施形態のいくつかの強化ＦａａＳシステムは、有利なことに、関数間の関係を定義するために関数コールグラフを提供し得る。複数の関数コールを回避するために、いくつかの関連する関数はインライン展開され得る。いくつかの関数は、リソース／帯域幅消費を低減するために分解され得る。いくつかの実施形態において、動的コールグラフは、ランタイム解析に基づいて調整され得る。強化ＦａａＳシステムのいくつかの実施形態は、状態の動的な表現およびナビゲーションのためにデータオントロジーを提供し得る。有利なことに、強化ＦａａＳシステムのいくつかの実施形態は、より良いリソース利用、より低いＩＯオーバヘッド、および／または、帯域幅の増加を提供し得る。いくつかの実施形態は、必要ない場合はオーバヘッドを生成しないことがあり得る。いくつかの実施形態において、開発者は、関数を起動する前に、関数がどれだけ長く実行する必要があるかを識別できる。
ここで図２６Ａを参照すると、ファンクションアズアサービスを提供する方法２６３０の実施形態は、ブロック２６３１において、１または複数のトランジェント関数について、関数間の関係を定義するために関数コールグラフなどの組織関連情報を提供する段階と、ブロック２６３２において、組織関連情報に基づいて１または複数のトランジェント関数の実行を修正する段階とを含み得る。方法のいくつかの実施形態２６３０は更に、ブロック２６３３において、トランジェント関数の１または複数を１または複数のサブ関数に分割する段階を含み得る。方法２６３０はまた、ブロック２６３４において、トランジェント関数およびサブ関数の１または複数を統合する段階を含み得る。例えば、方法２６３０は、ブロック２６３５において、トランジェント関数およびサブ関数の１または複数の実行の間で状態情報を共有する段階を含み得る。
方法２６３０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法２６３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法２６３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法２６３０は、以下の例２６１４から２６１７に関連し記載されたコンピュータ可読媒体に実装されてよい。方法２６３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
効率的な実行のためのコンテナ統合／分解の例
ここで図２６Ｂを参照すると、関数コールグラフ２６４０の実施形態は、トランジェント関数ｆ、ｇおよびｈについての組織関連情報を提供し得る。上述のように、依存的と識別される関数は、関数の間の１または複数の依存性に起因して、オーバヘッドの増加、リソース利用の低下などを引き起こし得る。図２６Ｂに示される例において、関数ｇおよびｈは、関数ｆに依存する。例えば、関数ｇおよびｈは、実行のために、関数ｆによって生成された少なくとも１つの出力を必要とする。いくつかの実施形態は、有利なことに、効率的な関数実行のために、（例えば、１つの関数が別のものをもたらすときを識別するためのインストルメンテーションを通じて）関数コールグラフ２６４０などの組織関連情報を提供し得る。
コールグラフは、関数間のコール関係を表す制御フローグラフに対応し得る。加重付きコールグラフにおいて、各円弧（例えば、コール元関数から始まりコール先関数で終了する）は、そのコール呼び出しの頻度でタギングされ得る。コールグラフは、統計的に形成され得、次に、動的に洗練され得る。呼び出しのオーバヘッドおよびデータ通信を低減するために、コールグラフ内で形成される領域に基づいて、特定のＦａａＳ関数が統合され得る。例えば、いくつかの実施形態は、ＦａａＳ関数内制御フローグラフをコールグラフに組み込み得、特定のＦａａＳ関数は２以上の関数に分割され得る。
ここで図２６Ｃ～図２６Ｅを参照すると、例示的な図は、関数ｆがどのように２つのサブ関数ｆ０およびｆ１に分割され得（図２６Ｃを参照）、その後、関数ｇがどのように２つのサブ関数の間で統合され得るか（図２６Ｄおよび図２６Ｅを参照）を示す。分解および統合プロセスは、オペレーションのコンパクトおよび／または効率的なシーケンスを形成するのに役立ち得る。いくつかの実施形態は、コアのキャッシュ性能に良い影響を有し得、また、同時に複数のＦａａＳ関数をウォーム／ライブに維持するために、ストレージ要件およびオーバヘッドを低減し得る。コールドパスが実行される場合において、適切なコード／コールを適切なＦａａＳ関数に挿入することによって、より少ない頻度の制御フローパスおよびコールパスはなおプロビジョニングされる必要があり得る。
いくつかの実施形態において、コード生成は、コンパイラ技術（例えば、オリジナルのラムダからのコンパイラ／コードジェネレータ）を適用して、命令レベルの並列性（ＩＬＰ）を強化するためにスーパーブロックを形成し得る。スーパーブロックは、サイドエントランスが無いトレースに対応し得る。例えば、制御は、上からのみ入り得るが、１または複数の終了ポイントから終了し得る（例えば、上に単一のエントリがあるが、複数の出口がある）。いくつかの実施形態において、プロファイル情報は、複数の基本ブロックを含む共通パスからスーパーブロックを構築するために使用され得る。
いくつかの実施形態は、インフラストラクチャ（例えば、スケジューリング前）によって実行され得、および／または、スケジューラによってランタイムに実行され得る。いくつかの実施形態はまた、データの共通位置を利用し得る。例えば、いくつかの実施形態は、関数をデータに送ることがあり得るが、その逆はない。なぜなら、データを移動するコストが、関数を移動するコストより大きいからである。いくつかの実施形態は、インライン技術を利用し得る。例えば、識別された関数２が、合理的な確実性で関数１によってコールされるとき、いくつかの実施形態は、別個のコールの代わりに、関数２のコードを関数１にインラインし得る（例えば、図２６Ｅを参照）。インライン後、ＦａａＳシステムは、関数２の実行のために外部に行き、スケジューラを取得または関数をダウンロードする必要はない。したがって、インラインは、効率性を増加させ、および／または、強化ＦａａＳシステムのオーバヘッドを低減し得る。いくつかの実施形態において、スケジューラはインラインオペレーションを実行し得る。
追加的に、または代替的に、強化ＦａａＳシステムのいくつかの実施形態は、アウトライン技術を利用し得る。例えば、いくつかの実施形態は、実行の可能性がより低い同一の関数の一部を除去し得る（例えば、ｉｆ－ｅｌｓｅステートメントからｅｌｓｅステートメントを除去するので、実行することはほぼ無い）。除去された部分は、別個のプログラム／関数として構成され得る。アウトラインは有利なことに、各関数について、より小さいダウンロードを提供し得る。強化ＦａａＳシステムのいくつかの実施形態は、同一データ上で動作する関数を識別し（例えば、そうでない場合は関係ないことがあり得る）、データと同じ位置に関数を置き得る。いくつかの実施形態は、任意の統合／分解を実行するかどうかを識別するためのメトリクス（例えば、すべての関数について、最小５分間の実行時間）を決定し得る。
関数再使用を促進するための状態のアグリゲーションおよびディスアグリゲーションの例
多くのＦａａＳフレームワークは、「純粋」またはステートレスである関数の再使用の概念をサポートし得る。従って、コンテナは、実際的な目的で内部状態が一定であるが、入ってくるパラメータとして新しい入力が提供され得る関数について、メモリレイアウトで初期化され得る。そのステートレス関数は次に、（例えば、やはり関数の状態の一部ではない）出力を生成し得る。このステートレス性は、常に有益であるわけではない。場合によっては、より大きい意図が、（例えば、その意図を、１つの関数から別の関数へデータを明示的に移動させる必要がある別個の関数に常に分解する代わりに）図らずも共通の状態を更新する異なるサブモジュールにマッピングされる単一コンテナによって、もっとも良く満たされ得る。加えて、必要な関数の一体化が単一のコンテナに適合するのに大きすぎる場合、または、コンテナの分解が、モジュール性のために好ましい場合、関数のチェーンにおける１つの関数から別のものへの必要な出力の流れは、多くのデータ移動およびメモリ管理オーバヘッドを追加する。
ここで図２７を参照すると、強化ＦａａＳシステム２７００の実施形態は、記述子２７３０などの組織関連情報の利用を通じて、２以上のサブ関数２７２０（例えば、サブ関数Ａ～Ｎ）によって共有され得るメモリ２７１０を含み得る。強化ＦａａＳシステム２７００のいくつかの実施形態は、有利なことに、コンテナの不必要なフラグメンテーションのオーバヘッドを回避するための技術を提供し得る。例えば、データオントロジーは、状態の動的表現およびナビゲーションを提供し得る。例えば、１つの関数から別の関数へ出力として論理的に転送されるべき状態の総量は、記述子の階層に分割され、オントロジーを使用して記述され得る。記述子の階層は、サブ関数の間で共有されるオントロジーに従って、消費する関数における全部の情報がどのように集約されるかを記述し得る。
結果として、前の関数Ｘから次の関数Ｙへ変化する必要はない状態情報は単に、ＸからＹへ渡される共通記述子の位置に維持され、すべての他の状態情報は、その共通記述子を通じて、オーバーレイ（例えば、置き換えまたは延長）としてＹにおいて処理され得る。このようにして、関数は、アクセッサ技術を用いてアクセスされるデータを操作するように意図的に組織され得、これらのアクセッサ技術は、記述子を使用し、かつ、必要な任意のオーバーレイを実行し得、その結果、サブ関数の各々の本体は、それ自体でステートレスとして維持される。例えば、いくつかの実施形態は、１つのメモリ領域から別のものへデータを移動させることなく、「関数をデータに適用する」という概念に従い得る。代わりに、いくつかの実施形態は、渡された記述子を通じて、配置されているデータを操作し得るが、間接的である。
追加の留意点および例
例２６００は、命令セットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、１または複数のトランジェント関数についての組織関連情報を提供させ、組織関連情報に基づいて１または複数のトランジェント関数の実行を修正させ（修正は、トランジェント関数のうち１または複数を１または複数のサブ関数へ分割および統合することのうち１または複数を含み得る）、トランジェント関数およびサブ関数のうち１または複数の実行の間で状態情報を共有させ、トランジェント関数およびサブ関数のうち１または複数によって利用されるデータと同一の位置になるようにトランジェント関数およびサブ関数のうち１または複数を移動させる。
例２６０１は、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを備える電子処理システムを含み、１または複数のトランジェント関数についての組織関連情報を提供し、組織関連情報に基づいて、１または複数のトランジェント関数の実行を修正する。
例２６０２は、例２６０１のシステムを含み、ロジックは更に、トランジェント関数のうち１または複数を１または複数のサブ関数に分割する。
例２６０３は、例２６０１～２６０２のいずれかのシステムを含み、ロジックは更に、トランジェント関数およびサブ関数のうち１または複数を統合する。
例２６０４は、例２６０１～２６０２のいずれかのシステムを含み、ロジックは更に、トランジェント関数およびサブ関数のうち１または複数の実行の間で状態情報を共有する。
例２６０５は、１または複数の基板と、１または複数の基板に連結されたロジックとを含む半導体パッケージ装置を備え、ロジックは、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数において少なくとも部分的に実装され、１または複数の基板に連結されるロジックは、１または複数のトランジェント関数についての組織関連情報を提供し、組織関連情報に基づいて１または複数のトランジェント関数の実行を修正する。
例２６０６は例２６０５の装置を含み、ロジックは更に、トランジェント関数のうち１または複数を１または複数のサブ関数に分割する。
例２６０７は、例２６０５～２６０６のいずれかの装置を含み、ロジックは更に、トランジェント関数およびサブ関数のうち１または複数を統合する。
例２６０８は、例２６０５～２６０６のいずれかの装置を含み、ロジックは更に、トランジェント関数およびサブ関数のうち１または複数の実行の間で状態情報を共有する。
例２６０９は、例２６０５～２６０８のいずれかの例の装置を含み、１または複数の基板に連結されたロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例２６１０は、ファンクションアズアサービスを提供する方法を含み、方法は、１または複数のトランジェント関数についての組織関連情報を提供する段階と、組織関連情報に基づいて、１または複数のトランジェント関数の実行を修正する段階とを含む。
例２６１１は、例２６１０の方法を含み、方法は更に、トランジェント関数のうち１または複数を１または複数のサブ関数に分割する段階を含む。
例２６１２は、例２６１０～２６１１のいずれかの方法を含み、方法は更に、トランジェント関数およびサブ関数のうち１または複数を統合する段階を含む。
例２６１３は、例２６１０～２６１１のいずれかの方法を含み、方法は更に、トランジェント関数およびサブ関数の１または複数の実行の間で状態情報を共有する段階を含む。
例２６１４は、命令セットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、１または複数のトランジェント関数についての組織関連情報を提供させ、組織関連情報に基づいて１または複数のトランジェント関数の実行を修正させる。
例２６１５は、更なる命令セットを含む、例２６１１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、トランジェント関数のうち１または複数を１または複数のサブ関数へ分割させる。
例２６１６は、更なる命令セットを含む、例２６１４～２６１５のいずれかの少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、トランジェント関数およびサブ関数のうち１または複数を統合させる。
例２６１７は、更なる命令セットを含む、例２６１４～２６１５のいずれかの少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、トランジェント関数およびサブ関数のうち１または複数の実行の間で状態情報を共有させる。
コンテナ値ハッシュキャッシュの例
強化ＦａａＳシステムのいくつかの実施形態は、有利なことに、コンテナ値ハッシュキャッシュを提供し得る。コンテナ値は、コンテナに格納され得る任意のタイプのデータ（例えば、ＫＶ格納、テキスト、コード、圧縮実行可能画像、関数呼び出しにおいて使用されるパラメータ、関数実行の結果など）に対応し得る。メモリは限られたリソースであり、コンテナ値はメモリ空間を占有する。いくつかのコンテナ値は、多くの関数によって使用され得、ＩＯ帯域幅は、そのようなコンテナ値をロード／再ロードするために必要である。いくつかの実施形態は、共有コンテナ値にアクセスするのに必要なメモリの量を低減するためにハッシュインデックスを提供し得る。いくつかの実施形態において、共有コンテナ値は、キャッシュにロードされ得る。いくつかの実施形態は、コンテナ値を再ロードするオーバヘッドを回避するために１または複数のコンテナ値をピニングし得る（例えば、コンテナ値が永続的にキャッシュ／メモリに保持されるようにマーキングする）。
ここで図２８Ａを参照すると、ファンクションアズアサービスを提供する方法２８３０の実施形態は、ブロック２８３１において、２以上のトランジェント関数の間で共有されるハッシュテーブルに、共有コンテナ値を格納する段階と、ブロック２８３２において、ハッシュインデックスと共に、共有ハッシュテーブルに格納された共有コンテナ値にアクセスする段階とを含み得る。方法２８３０のいくつかの実施形態は更に、ブロック２８３３において、共有ハッシュテーブルをキャッシングする段階を含み得る。方法２８３０はまた、ブロック２８３４において、共有コンテナ値を共有ハッシュテーブルにピニングする段階を含み得る。
方法２８３０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法２８３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法２８３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法２８３０は、以下の例２８１１から２８１３に関連し記載されたコンピュータ可読媒体に実装されてよい。方法２８３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
図２８Ｂに関連して下で説明される１つの２８４０などの強化ＦａａＳシステムのいくつかの実施形態は、有利なことに、コンテナ値ハッシュキャッシュを提供し得る。いくつかの他のＦａａＳシステムにおいて、反復定数は関数間で共有されない。関数は、いくつかの他のＦａａＳシステムにおいて、異なるように処理され、関数は値を共有しない。強化ＦａａＳシステム２８４０のいくつかの実施形態は、有利なことに、コンテナによって利用される共有定数を格納するためのハッシュテーブルを提供し得る。関数は有利なことに、ハッシュテーブルを参照し得、それにより、そうでない場合は共有コンテナ値をロードする必要があり得るＩＯ帯域幅、メモリ空間、電力、利用率、コンピューティングリソースなどを節約する。
ここで図２８Ｂを参照すると、強化ＦａａＳシステム２８４０の実施形態は、１または複数のトランジェント関数２８４４によって共有され得るハッシュテーブル２８４２を含み得る。ハッシュテーブル２８４２は、対応する共有コンテナ定数値（例えば、Ｃ１～ＣＮ）を戻すために、ハッシュ値（例えば、Ｈ１～ＨＮ）によってインデックス化され得る。
強化ＦａａＳシステム２８４０のいくつかの実施形態は、プロセス／ラムダ／コンテナが始動するときに格納され得る定数値キャッシュを提供し得、別個のキャッシュに大きい定数値（例えば、高速フーリエ変換（ＦＦＴ）を計算するための回転因子、ニューラルネットワークフィルタ値など）を格納し得る。６４の異なる倍精度浮動小数点定数（例えば、各々６４ビット）については、例えば、いくつかの実施形態は、６ビットのインデックスを使用してアクセスし得る（例えば、６４の異なる定数をインデックス化するための２６のインデックス値）。これらの値は、コンパイル時間またはロード時間（例えば、ニューラルネットコンテナをウォームアップするための推論ラムダを注入するとき）定数であり得る。コンパイル／ＪＩＴ／コードジェネレータは最初に、特別な格納命令を用いるラムダ／コンテナ／初期化の開始において、定数値を定数値キャッシュにロードし得る。その後、定数値に対応する通常のロードが、定数値キャッシュへのインデックスを示す特別なロード命令に置き換えられ得る。強化ＦａａＳシステム２８４０のいくつかの実施形態は、有利なことに、ロードのよりコンパクトな符号化によってキャッシュ性能を改善し得る。また、いくつかの実施形態は、メモリオーダリングバッファ（ＭＯＢ）エントリを解放し、定数値キャッシュから読み込むロード命令について、ストアフォワードなどのチェックの要件を除去し得る。
強化ＦａａＳシステム２８４０のいくつかの実施形態はまた、定数が定数値キャッシュにおいてピニングされ、追い出されることがないことを確実にし得る。例えば、畳み込みニューラルネットワーク（ＣＮＮ）フィルタ値が、推論中に非常に頻繁に使用され得る。フィルタ値は定数であり得るが、多くの入力／出力チャネルは、ＣＮＮのワーキングセットを、キャッシュの容量より遥かに大きくし得る。その結果、フィルタ値は、キャッシュ内に収まることができず、いくつかの他のシステムにおいては、複数の異なる関数コールにおいて毎回メモリから戻され得、これは高価であり性能に影響し得る。強化ＦａａＳシステム２８４０のいくつかの実施形態において、定数値キャッシュは一度ロードされ、複数のラムダ／プロセス（例えば、同一のＣＮＮフィルタ値を使用する複数の推論ラムダを含む）の間で共有され得、これは有利なことに、コンピュート、メモリ、および／またはＩＯリソースを節約し得る。
追加の留意点および例
例２８０１は、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを備える電子処理システムを含み、２以上のトランジェント関数の間で共有されるハッシュテーブルに、共有コンテナ値を格納し、ハッシュインデックスを用いて共有ハッシュテーブルに格納された共有コンテナ値にアクセスする。
例２８０２は、例２８０１のシステムを含み、ロジックは更に、共有ハッシュテーブルをキャッシュする。
例２８０３は、例２８０１～２８０２のいずれかのシステムを含み、ロジックは更に、共有ハッシュテーブルにおいて共有コンテナ値をピニングする。
例２８０４は、１または複数の基板と、１または複数の基板に連結されるロジックとを備える半導体パッケージ装置を含み、ロジックは、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数において少なくとも部分的に実装され、１または複数の基板に連結されるロジックは、２以上のトランジェント関数の間で共有されるハッシュテーブルに、共有コンテナ値を格納し、ハッシュインデックスを用いて共有ハッシュテーブルに格納される共有コンテナ値にアクセスする。
例２８０５は、例２８０４の装置を含み、ロジックは更に、共有ハッシュテーブルをキャッシュする。
例２８０６は、例２８０４～２８０５のいずれかの装置を含み、ロジックは更に、共有ハッシュテーブルにおいて、共有コンテナ値をピニングする。
例２８０７は、例２８０４～２８０６のいずれかの例の装置を含み、１または複数の基板に連結されるロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例２８０８は、ファンクションアズアサービスを提供する方法を含み、方法は、２以上のトランジェント関数の間で共有されるハッシュテーブルにおいて、共有コンテナ値を格納する段階と、ハッシュインデックスを用いて共有ハッシュテーブルに格納される共有コンテナ値にアクセスする段階とを含む。
例２８０９は、例２８０８の方法を含み、方法は更に、共有ハッシュテーブルをキャッシングする段階を含む。
例２８１０は、例２８０８～２８０９のいずれかの方法を含み、方法は更に、共有ハッシュテーブルにおいて、共有コンテナ値をピニングする段階を含む。
例２８１１は、命令セットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、２以上のトランジェント関数の間で共有されるハッシュテーブルに共有コンテナ値を格納させ、ハッシュインデックスを用いて共有ハッシュテーブルに格納される共有コンテナ値にアクセスさせる。
例２８１２は、更なる命令セットを含む、例２８１１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、共有ハッシュテーブルをキャッシングさせる。
例２８１３は、更なる命令セットを含む、例２８１１～２８１２のいずれかの少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、共有ハッシュテーブルにおいて共有コンテナ値をピニングさせる。
インバース／アンドゥコンテナの例
強化ＦａａＳシステムのいくつかの実施形態は、有利なことに、インバース／アンドゥコンテナを提供し得る。ＦａａＳシステムにおいて、キャンセルリクエストまたはクラッシュは、いくつかのリソースを不確定状態に置き得る。いくつかの実施形態において、リバース／アンドゥ関数は、クラッシュ／キャンセルリクエストによって影響されるリソースをクリーンアップするように登録され得る。いくつかの実施形態は、より良いリソース利用および／またはより少ない不確定状態を提供し得る。
ここで図２９Ａを参照すると、ファンクションアズアサービスを提供する方法２９３０の実施形態は、ブロック２９３１において、トランジェント関数が関連するクリーンアップ関数を有するかどうかを決定する段階と、ブロック２９３２において、トランジェント関数が割り込まれる場合に、関連するクリーンアップ関数を実行する段階とを含み得る。方法２９３０のいくつかの実施形態は更に、ブロック２９３３において、クリーンアップ関数を登録する段階を含み得る。方法２９３０はまた、ブロック２９３４において、クリーンアップ関数を自動的に生成する段階を含み得る。
方法２９３０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法２９３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法２９３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法２９３０は、下の例２９１１～２９１３に関連して説明されるコンピュータ可読媒体で実装され得る。方法２９３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
いくつかのＦａａＳシステムはステートレスとみなされ得る。「ステートレス」ＦａａＳシステムの例では、ＦａａＳシステムによって実行されている関数のモニタリングされる状態が無い。システムまたは関数がクラッシュする場合、記録される状態が無いため、問題が生じ得る。例えば、関数がいくつかのデータを修正し、次にクラッシュする場合、システムは、どこからピックアップするか、または、どのように関数の完了まで進み、クリーンアップし、始動するかを決定することが不可能であり得る（例えば、ＦａａＳシステムは何のデータのアンドゥを行うか知らない）。図２９Ｂに示される１つの２９４０などの強化ＦａａＳシステムのいくつかの実施形態は、有利なことに、オリジナル関数のインバースとして、ダメージ（例えば、補足的、または、同一の関数に含まれる）をアンドゥするための専用関数を提供し得る。
ここで図２９Ｂを参照すると、強化ＦａａＳシステム２９４０の実施形態は、完了前に割り込みされ得る関数ｆ（ｘ）を呼び出し得る。例えば、そのような割り込みは、関数のキャンセル、関数ｆ（ｘ）のクラッシュ、ＦａａＳシステム２９４０のクラッシュ、必要なリソースのロスなどに対応し得る。割り込みの後、ＦａａＳシステム２９４０のいくつかの実施形態は、クリーンアップ関数ｆ－１（ｘ）を呼び出し、関数ｆ（ｘ）の割り込みによって生じる１または複数の問題に対処し得る。例えば、関数ｆ－１（ｘ）は、アンドゥ関数、インバース関数、リバース関数などとみなされ得る。
従来のＦａａＳ関数、例えば、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ）ラムダ（登録商標）は、ステートレスとみなされ、いくつかの外部に可視的な副作用を有し得る。例えば、ラムダ関数は、データベースエントリを更新し得る、または、それ自体がいくつかの他の外部から可視的な副作用を有し得る別のラムダ関数を呼び出し得る。例えば、アイテム送信の命令は、一連のＦａａＳ関数／ラムダ関数を呼び出し得る。命令が任意のポイントでキャンセルされた場合、キャンセルリクエストが伝搬される必要があり、特定の更新／動作が取り消される必要があり得る。強化ＦａａＳシステム２９４０のいくつかの実施形態は、ＪＳＯＮオブジェクトなどオリジナルのパラメータを用いて同一のチェーンを呼び出すことによってアンドゥ関数を実行し得るが、副作用などをアンドゥする。
強化ＦａａＳシステム２９４０のいくつかの実施形態は、アプリケーション開発者によって提供され得る、または、コードジェネレータによって自動的に生成され得るアンドゥラムダ関数を含む副作用をクリーンアップのために、実際のラムダの代わりに呼び出されるＦａａＳ関数／ラムダ関数のリバース／アンドゥバージョンを登録し得る。例えば、アンドゥラムダ関数は、アンドゥロギングの組み合わせを含み得、ボトムアップ、モジュール方式で（例えば、メンバオブジェクトを削除するためのＣ＋＋デストラクタコールと同様）、バックワードスライス生成を利用し得る。
追加の留意点および例
例２９０１は、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを備える電子処理システムを含み、トランジェント関数が関連するクリーンアップ関数を有するかどうか判定し、トランジェント関数が割り込みされる場合、関連するクリーンアップ関数を実行する。
例２９０２は、例２９０１のシステムを含み、ロジックは更に、クリーンアップ関数を登録する。
例２９０３は、例２９０１～２９０２のいずれかのシステムを含み、ロジックは更に、クリーンアップ関数を自動的に生成する。
例２９０４
１または複数の基板と、１または複数の基板に連結されたロジックとを備える半導体パッケージ装置であり、ロジックは、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数において少なくとも部分的に実装され、１または複数の基板に連結されるロジックは、トランジェント関数が関連するクリーンアップ関数を有するかどうかを決定し、トランジェント関数が割り込みされた場合、関連するクリーンアップ関数を実行する。
例２９０５は、例２９０４の装置を含み、ロジックは更に、クリーンアップ関数を登録する。
例２９０６は、例２９０４～２９０５のいずれかの装置を含み、ロジックは更に、クリーンアップ関数を自動的に生成する。
例２９０７は、例２９０４～２９０６のいずれかの例の装置を含み、１または複数の基板に連結されるロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例２９０８
ファンクションアズアサービスを提供する方法であり、トランジェント関数が関連するクリーンアップ関数を有するかどうかを判定する段階と、トランジェント関数が割り込みされた場合、関連するクリーンアップ関数を実行する段階とを含む。
例２９０９は、例２９０８の方法を含み、方法は更に、クリーンアップ関数を登録する段階を含む。
例２９１０は、例２９０８～２９０９のいずれかの方法を含み、方法は更に、クリーンアップ関数を自動的に生成する段階を含む。
例２９１１
命令セットを含む少なくとも１つのコンピュータ可読記憶媒体であり、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、トランジェント関数が関連するクリーンアップ関数を有するかどうかを判定させ、トランジェント関数が割り込みされた場合に関連するクリーンアップ関数を実行させる。
例２９１２は、更なる命令セットを含む、例２９１１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されたとき、コンピューティングデバイスに、クリーンアップ関数を登録させる。
例２９１３は、更なる命令セットを含む、例２９１１から２９１２のいずれかの少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、クリーンアップ関数を自動的に生成させる。
コンテナ継続渡しスタイルの例
図４において示されるものなどの強化ＦａａＳシステムのいくつかの実施形態は、有利なことに、コンテナに継続渡しスタイルを提供し得る。ＦａａＳ関数は、独立した実行ユニットであり、異なるＦａａＳ関数がいくつかの関係を有する場合、追加のオーバヘッドが発生し得る（例えば、関数の間でデータを渡す）。強化ＦａａＳシステムのいくつかの実施形態は、関数コールの間で情報を渡すための渡し機能を提供し得る。いくつかの実施形態において、条件付き関数コールは、渡しデータの一部であり得る。有利なことに、いくつかの実施形態は、より良いリソース利用、ＩＯ帯域幅の低減、および／または、より速い実行を提供し得る。
ここで図３０Ａを参照すると、ファンクションアズアサービスを提供する方法３０３０の実施形態は、ブロック３０３１において、トランジェント関数のパラメータとして、継続関数を含むトランジェント関数を実行する段階と、ブロック３０３２において、トランジェント関数から継続関数を実行する段階とを含み得る。方法３０３０のいくつかの実施形態は更に、ブロック３０３３において、継続関数についてのコード、コンテキスト、およびデータのうち１または複数を再帰的に渡すことを含み得る。例えば、方法３０３０は、ブロック３０３４において、継続関数の一部として、リカバリコードを渡す段階を含み得る。
方法３０３０の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法３０３０のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法３０３０は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
例えば、方法３０３０は、下の例３０１１～３０１３に関連して説明されるコンピュータ可読媒体で実装され得る。方法３０３０の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
いくつかのＦａａＳシステムにおいて、関数は、独立の機能ユニットであり、異なる関数の間で委譲問題発生し得る。図３０Ｂに示されるような強化ＦａａＳシステム３０４０のいくつかの実施形態は、有利なことに、ラムダ関数または別の関数などの継続関数を他のコール先関数に渡し、関数実行性能を改善し得る。
ここで図３０Ｂを参照すると、強化ＦａａＳシステム３０４０の実施形態は、関数ｆが関数ｇを呼び出すためにデータおよびコードを渡し得、関数ｇが関数ｈを呼び出すためにデータおよびコードを渡し得るなどの再帰関数コールを含み得る。強化ＦａａＳシステム３０４０のいくつかの実施形態は、コード、データ、コンテキストなどをコール先関数に渡すことを可能にするために技術／機能を関数呼び出しに追加し得る。コール先関数は次に、コード、データ、コンテキストなどを再帰的に渡し得る。例えば、関数ｇは、データを関数ｇに渡す関数ｆのコール先であり、関数ｈは、データを関数ｈに渡す関数ｇのコール先である。強化ＦａａＳシステム３０４０のいくつかの実施形態は有利なことに、特定の要件が満たされるまで、特定の動作（例えば、外部から可視的な副作用を有する動作）の実行を遅延させることが可能であり得る。強化ＦａａＳシステム３０４０のいくつかの実施形態はまた、関数コールチェーン中に特定の例外／条件が発生する場合に実行されるべきリカバリ／ロールバックコードを渡すことを可能にし得る。有利なことに、強化ＦａａＳシステム３０４０のいくつかの実施形態は、レジリエントな解決手段を実装することに役立ち、適切／効率的な例外処理を可能にし得る。
強化ＦａａＳシステム３０４０のいくつかの実施形態は、コンテキストおよびデータ構造がプロトコルバッファなどの標準データ交換フォーマットとして渡され得る。継続渡しスタイルをサポートし得る。実行されるコードは、ラムダ関数においてカプセル化され得、また、ラムダアドレス／ＩＤがコンテキストに従って渡され得る。いくつかの実施形態において、ラムダコードのリカバリ／遅延の副作用は、コンパイラ／コードジェネレータによって、オリジナルのラムダから抽出され得る。
追加の留意点および例
例３００１は、プロセッサと、プロセッサに通信可能に連結されたメモリと、プロセッサおよびメモリに通信可能に連結されたロジックとを備える電子処理システムを含み、トランジェント関数のパラメータとして継続関数を含むトランジェント関数を実行し、トランジェント関数から継続関数を実行する。
例３００２は、例３００１のシステムを含み、ロジックは更に、継続関数についてのコード、コンテキストおよびデータのうち１または複数を再帰的に渡す。
例３００３は、例３００１～３００２のいずれかのシステムを含み、ロジックは更に、継続関数の一部として、リカバリコードを渡す。
例３００４は、１または複数の基板と、１または複数の基板に連結されたロジックとを備える半導体パッケージ装置を含み、ロジックは、構成可能ロジックおよび機能固定型ハードウェアロジックのうち１または複数において少なくとも部分的に実装され、１または複数の基板に連結されるロジックは、トランジェント関数のパラメータとして継続関数を含むトランジェント関数を実行し、トランジェント関数から継続関数を実行する。
例３００５は、例３００４の装置を含み、ロジックは更に、継続関数についてのコード、コンテキスト、およびデータのうち１または複数を再帰的に渡す。
例３００６は、例３００４～３００５のいずれかの装置を含み、ロジックは更に、継続関数の一部としてリカバリコードを渡す。
例３００７は、例３００４～３００６のいずれかの例の装置を含み、１または複数の基板に連結されるロジックは、１または複数の基板内に位置するトランジスタチャネル領域を含む。
例３００８
ファンクションアズアサービスを提供する方法であり、トランジェント関数のパラメータとして継続関数を含むトランジェント関数を実行する段階と、トランジェント関数から継続関数を実行する段階とを含む。
例３００９は、例３００８の方法を含み、方法は更に、継続関数についてのコード、コンテキストおよびデータのうち１または複数を再帰的に渡す段階を含む。
例３０１０は、例３００８～３００９のいずれかの方法を含み、方法は更に、継続関数の一部としてリカバリコードを渡す段階を含む。
例３０１１
命令セットを含む少なくとも１つのコンピュータ可読記憶媒体であり、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、トランジェント関数のパラメータとして継続関数を含むトランジェント関数を実行させ、トランジェント関数から継続関数を実行させる。
例３０１２は、更なる命令セットを含む、例３０１１の少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、継続関数についてのコード、コンテキスト、およびデータのうち１または複数を再帰的に渡させる。
例３０１３は、更なる命令セットを含む、例３０１１～３０１２のいずれかの少なくとも１つのコンピュータ可読記憶媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、継続関数の一部として、リカバリコードを渡させる。
都合の良いコンテナ構築およびキャッシュ管理の例
ＦａａＳシステムは、周期的およびランダムなイベントを有するイベントドリブンモデルであり得る。したがって、同一の関数および／または関数が、実行中に関数が利用することになるデータセット（例えばデータオブジェクト）を含む同一または同様のコンテナを利用するという状況が一般に発生する。関数は短い時間スパンにおいて複数回実行され得る。いくつかのアーキテクチャにおいて、ウォームコンテナアプローチを通じてコンテナが再使用され得るいくつかの場合を除き、新しいコンテナが関数実行ごとに使用され得る。ウォームコンテナの維持はリソースを不必要に消費し得る。例えば、ウォームコンテナは、実行のために関数を待機しつつ、アイドル状態で維持し得る。アイドル時間は非生産的であり得る。更に、コンテナの再使用または共有は、コンテナに固有であり得、すべての状況に適用可能でないことがあり得る。
対照的に、ウォームコンテナは解体され得、コールドコンテナは、関数が呼び出されるときに始動され得る。コンテナの構築、始動、または開始は、名前空間および制御グループの構成、ネットワークのセットアップ、および実行環境のセットアップなど、いくつかのステージを含み得る。実行環境はユーザーデータおよび他の要件を含み得る。いくつかの他の要件は、様々なキー、ＣＰＵ／メモリ／ディスク容量確保または優先度、データベース、データセット、キー値ストア、トランスレーションディクショナリ、リソース利用クレジットなどを含み得る。また、他の要件の更なる例は、一旦開かれて、次に、再使用のためにキャッシュされたニューラルネットワーク、ファイルまたはネットワーク記述子、および／または、実行可能のキャッシュされた解決画像を含み得る。
上記のように、コンテナ始動時間（コールドコンテナ始動）は、小さくないレイテンシを有し、リソースを消費する。コンテナ始動時間は、ＦａａＳ性能に影響し得るので、始動時間の低減が望ましい。
ここで図３１Ａを参照すると、ウォームコンテナを利用すること、および／または、コンテナを構築するのに必要なすべてのデータを格納することさえなく、都合の良い方式でコンテナが再構築され得る、ＦａａＳの例３１００が示される。例３１００の強化ＦａａＳアーキテクチャは、キャッシュ３１０２、キャッシュコントローラ３１０４、保持ポリシーマネージャ３１０６、および始動タイマ３１０８を含み得る。キャッシュ３１０２、キャッシュコントローラ３１０４、保持ポリシーマネージャ３１０６、および始動タイマ３１０８は、同一のコンピュートノード（例えば、コンピューティングデバイス、サーバ、モバイルデバイスなど）の一部であり得る。以下で更に詳細に説明されるように、強化ＦａａＳアーキテクチャは、コンテナのサブセットを識別し、コンテナを全体的に回収または解体するのではなく、サブセットを格納し得る。サブセットはワーキングセットと呼ばれ得る。それにより、リソース消費を低減するためにウォームコンテナは解体され得、レイテンシを減少させる必要があるときコンテナが迅速に再構築され得る。
従って、コンテナのリソースはワーキングセットと呼ばれ得る。従って、「ホット」アクティブワーキングセットはキャッシュ３１０２に既に格納され、一方、コンテナのよりアクティブでない部分が除去されることを可能にする。例えば、共有ワーキングセットは、関数の間で共有されるセットであり得、加重、定数、公式、共通データ（例えば、名称、画像など）のデータベース、ユーザーデータ、様々なキー、ＣＰＵ／メモリ／ディスク容量確保または優先度、データセット、キー値ストア、トランスレーションディクショナリ、リソース利用クレジット、一旦開かれて、次に、再使用のためにキャッシュされたニューラルネットワーク、ファイルまたはネットワーク記述子、および／または、実行可能のキャッシュされた解決画像を含み得る。そのようなワーキングセットは、キャッシュ３１０２に保持され、ワーキングセットへのアクセスを付与するためにＦａａＳアーキテクチャによって管理され得る。各ワーキングセットには、関数がワーキングセットにアクセスするたびに延長される生存時間を割り当てられ得る。ワーキングセットは、データの使用の頻度（下で説明される）、ならびに、ワーキングセットなしでコンテナを開始する始動時間の測定、および、生存時間に基づいてキャッシュ３１０２からエビクションされ得る。例えば、ワーキングセットの使用頻度が大きい場合、セットアップ時間が短い場合でもそのワーキングセットは維持され得る。
示されるように、キャッシュ３１０２は、２つのワーキングセット、すなわち、Ｃ（１）ワーキングセット（データオブジェクトとも呼ばれ得る）およびＣ（２）ワーキングセット（データオブジェクトとも呼ばれ得る）を格納するキャッシュ空間３１１２を含む。Ｃ（１）は第１コンテナの略であり、Ｃ（２）は第２コンテナの略である。第１および第２コンテナは、実行中に関数が利用するデータセットを含み得る。Ｃ（１）ワーキングセットは、第１コンテナのワーキングセットであり、Ｃ（２）は、第２コンテナのワーキングセットである。例において、第１および第２コンテナの両方が解体され、非アクティブである（すなわち構築されていない）。第１および第２コンテナが解体されるとき、呼び出された場合に第１および第２コンテナを迅速に構築するために、Ｃ（１）およびＣ（２）ワーキングセットは、キャッシュ空間３１１２において維持される。すなわち、Ｃ（１）ワーキングセットは、第１コンテナを構築するために使用され得る、Ｃ（２）ワーキングセットは、第２コンテナを構築するために使用され得る。
従って、Ｃ（１）およびＣ（２）ワーキングセットをキャッシュ空間３１１２に維持することにより、第１または第２コンテナにおける関数の後の実行が高速化し得る。すなわち、第１および第２コンテナは、Ｃ（１）およびＣ（２）ワーキングセットに少なくとも部分的に基づいて再構築され得る。いくつかの実施形態において、Ｃ（１）およびＣ（２）ワーキングセットは、それぞれ、第１および第２コンテナを構築するためのデータをすべて含み得る。いくつかの実施形態において、Ｃ（１）およびＣ（２）ワーキングセットは、それぞれ、第１および第２コンテナを構築するためのデータのサブセットだけを含み得る。例えば、いくつかのデータはいくつかの異なるコンテナに共通であり得る。そのようなデータはＣ（１）およびＣ（２）ワーキングセットとして格納され得、したがって、Ｃ（１）およびＣ（２）ワーキングセットは各々、いくつかの異なるコンテナを構築するために使用され得る。いくつかの実施形態において、Ｃ（１）およびＣ（２）ワーキングセットは、それぞれ、第１および第２コンテナの構築を開始するためのデータオブジェクトを含み得、第１および第２コンテナを構築するためのデータオブジェクトの残りは、第１および第２関数が構築されるときに到着する。
いくつかの実施形態において、第１または第２コンテナは、関数の実行をサポートするためのデータを更に必要とし得る。すなわち、完全に構築された第１または第２コンテナは、関数の要件に応じて関数をサポートすることが不可能であり得る。従って、第１または第２コンテナは、更なるデータを含むように、および、修正された第１または第２コンテナが関数をサポートすることが可能にするように構築および修正され得る。更なるデータは、データソース（例えば、別のコンピュートノード、データベースサーバなど）から受信され得る。特に、第１コンテナおよび第２コンテナが、実行を促進するための更なるデータで増大される場合、Ｃ（１）およびＣ（２）ワーキングセットのサイズ、ならびに、第１および第２コンテナの始動時間は、異なる関数では異なる。
いくつかのエビクションポリシーは単に、利用の頻度、および、新しいデータが格納されるかどうかに、ほぼ基づき得る。ＦａａＳ環境において、コンテナ始動時間（関数始動時間と同等であり得る）は、小さくなく、従って、エビクション中に考慮される必要があり得る。従って、３１００の例は、始動時間を考慮し、コンテナ始動を強化するために、Ｃ（１）およびＣ（２）ワーキングセットのための強化エビクションポリシーを有する。
示されるように、始動タイマ３１０８が提供される。始動タイマ３１０８は、第１および第２コンテナの始動時間を測定し、測定された始動時間（すなわち構築時間）を、テーブル３１１４においてＴ（１）およびＴ（２）として格納し得る。例えば、構築時間Ｔ（１）（最初の実行）は、第１コンテナを構築するための時間測定である。第１コンテナが関数の実行を開始できるとき、第１コンテナは完全に構築されたとみなされ得る。同様に、構築時間Ｔ（２）（最初の実行）は、第２コンテナを構築するための時間測定である。第２コンテナが関数の実行を開始できるとき、第２コンテナは完全に構築されたとみなされ得る。テーブル３１１４は、構築されている各コンテナのワーキングセットおよびその構築時間を格納するためのデータ構造であり得る。
強化されたキャッシュコントローラ３１０４は、キャッシュ３１０２からのエビクションを制御し得る。キャッシュコントローラ３１０４は、テーブル３１１４にアクセスする、または、テーブル３１１４に格納された情報を含む始動タイマ３１０８からメッセージを受信し得る。キャッシュコントローラ３１０４は、キャッシュ３１０２からのエビクションを決定するとき、構築時間Ｔ（１）およびＴ（２）を利用し得る。従って、キャッシュコントローラ３１０４は、Ｃ（１）ワーキングセットまたはＣ（２）ワーキングセットをエビクションするかどうかを決定するとき、第１および第２コンテナの構築時間Ｔ（１）およびＴ（２）を利用し得る。
例えば、キャッシュコントローラ３１０４は、エビクションポリシーマネージャ３１１０を含み得る。エビクションポリシーマネージャ３１１０は、構築時間Ｔ（１）およびＴ（２）に基づいて、異なる加重式を生成し、そのような値をテーブル３１１６に格納し得る。例えば、エビクションポリシーマネージャ３１１０は、Ｃ（１）ワーキングセットについて第１の加重式を構築し得る。第１の加重式は、加重関数Ｆ（（Ｔ）（１））を含み得る。Ｆ（（Ｔ１）（１））は、入力として構築時間Ｔ（１）を受け付け、構築時間Ｔ（１）から取得した値を出力する関数であり得る。同様に、第２の加重式は、Ｃ（２）ワーキングセットについて生成される。第２の加重式は、関数Ｆ（（Ｔ）（２））を含み得る。関数Ｆ（（Ｔ）（２））は、入力として構築時間Ｔ（２）を受け付け、構築時間Ｔ（２）から取得した値を出力する関数であり得る。テーブル３１１６は第１および第２加重式を格納する。
第１および第２加重式の両方は、更なる値も含み得る。例えば、第１加重式は、Ｃ（１）ワーキングセットのアクセスの頻度に基づく別の関数であり得る関数Ｋ（１）を含み得る。例えば、関数Ｋ（１）は、出力を生成するために、入力として、Ｃ（１）ワーキングセットの複数のアクセスを受け付け得る。同様に、関数Ｋ（２）は、出力を生成するために、入力として、Ｃ（２）ワーキングセットの複数のアクセスを受け付け得る。第１および第２加重式は他の値も含み得る。第１および第２加重式は、上の関数の総和であり得る。
エビクションポリシーマネージャ３１１０は、第１および第２加重式を参照し、Ｃ（１）ワーキングセットまたはＣ（２）ワーキングセットをキャッシュ３１０２からエビクションするかどうかを決定し得る。例えば、エビクションポリシーマネージャ３１１０は、第１加重式の総和計算である第１最終値、および、第２加重式の総和計算である第２最終値を決定し得る。第１および第２最終値は、エビクションポリシーマネージャ３１１６のテーブル３１１６に格納され得る。エビクションポリシーマネージャ３１１０は、第１および第２最終値を比較して、Ｃ（１）およびＣ（２）ワーキングセットをエビクションするかどうかを決定し得る。従って、エビクションポリシーマネージャ３１１０は、構築時間Ｔ（１）およびＴ（２）を互いに、および／または、Ｃ（１）およびＣ（２）ワーキングセットへのアクセスの数と比較する。
例として、第１および第２最終値は、それぞれ、第１および第２コンテナの始動時間、ならびに、Ｃ（１）およびＣ（２）ワーキングセットへのデータアクセスの数に比例し得る。従って、第１最終値が第２最終値より大きい場合、Ｃ（１）ワーキングセットは、Ｃ（２）ワーキングセットより多くアクセスされ得、および／または、第１コンテナは、第２コンテナと比較して、始動時間がより多いことがあり得る。従って、Ｃ（１）ワーキングセットのエビクションは、Ｃ（２）ワーキングセットのエビクションと比較して、より大きい全体のレイテンシをもたらす。従って、エビクションポリシーマネージャ３１１０は、第１および第２最終値に基づいて、Ｃ（２）ワーキングセットをエビクションし得る。従って、エビクションポリシーマネージャ３１００は、最小の最終値に関連するワーキングセットをエビクションし得る。
また、キャッシュコントローラ３１０４は、保持ポリシーマネージャ３１０６を含み得る。保持ポリシーマネージャ３１０６は、Ｃ（１）およびＣ（２）ワーキングセットについての生存時間を決定するために異なる加重式を生成し得る。生存時間はテーブル３１１８に格納され得る。例えば、保持ポリシーマネージャ３１０６は、第１コンテナについての第３加重式を構築し得る。第３加重式は、関数Ｇ（（Ｔ）（１））、すなわち、構築時間Ｔ（１）から取得された値を出力するために入力として構築時間Ｔ（１）を受け付ける関数を含み得る。同様に、第４加重式が第２コンテナについて生成される。第４加重式は、関数Ｇ（（Ｔ）（２））、すなわち、構築時間Ｔ（２）から取得された値を出力するために入力として構築時間Ｔ（２）を受け付ける関数を含み得る。第３および第４加重式は、定数、および／または、それぞれＣ（１）およびＣ（２）ワーキングセットへのデータアクセスの数など、他の値も含み得る。第３加重式から取得された値は、Ｃ（１）ワーキングセットについての生存時間であり得、第４加重式から取得された値は、Ｃ（２）ワーキングセットについての生存時間であり得る。テーブル３１１８は、第３および第４加重式を示す。
対応する生存時間がタイムアウトしたとき（カウンタによってカウントされる）、Ｃ（１）ワーキングセットまたはＣ（２）ワーキングセットはエビクションされ得る。タイマは、Ｃ（１）またはＣ（２）ワーキングセットがアクセスされるたびにリセットされ得る。タイマはまた、リソースを解放する、または、選択されたカテゴリのリクエストに高優先度を付与する必要性の識別に応じて、自動的に、および／または、管理者によってリセットされ得る。いくつかの実施形態において、生存時間は、リセットされないことがあり得、最大の生存時間を表す。
キャッシュ３１０２は、ハードウェアキャッシュ（例えばＬＬＣ、ＴＬＢ）またはソフトウェアオブジェクトキャッシュ（例えば、Ｊａｖａ（登録商標）永続オブジェクトキャッシュ）であり得る。キャッシュ３１０２は、例えばページキャッシュであり得る。更に、キャッシュコントローラ３１０４は、いくつかのキャッシュ、または、キャッシュのレベルを制御し得る。更に、エビクションイベントは、入ってくるデータのためのストレージ空間が無いことによってトリガされ、キャッシュコントローラ３１０４によってモニタリングされ得る。
例として、第１コンテナは、画像認識のために第１関数を実行し得、第２コンテナは、画像回転のために第２関数を実行し得る。第１関数についての画像認識始動は、第１コンテナのニューラルネットワークの初期化を伴い得る。従って、第１コンテナについての構築時間Ｔ（１）は、第２コンテナについての構築時間Ｔ（２）より著しく大きいことがあり得る。画像認識のメモリフットプリントは、より高いことがあり得、再使用のためにコンテナを生存状態に維持することはコストが大きいことがあり得る。更に、画像認識の実行頻度は、画像回転の関数より低いことがあり得る。それにもかかわらず、性能の観点からは、構築時間Ｔ（１）は構築時間Ｔ（２）より著しく大きいので、エビクションポリシーマネージャ３１１０は、Ｃ（１）ワーキングセット（画像認識コンテナ）をエビクションすること、および、Ｃ（２）ワーキングセット（画像回転コンテナ）をエビクションすることは有益でないと決定し得る。更に、Ｃ（１）ワーキングセットの維持は、第２コンテナの始動を強化し得る。なぜなら、Ｃ（１）ワーキングセットからのデータは、第１および第２コンテナの両方に対して共通であると識別され、第２コンテナの構築中に利用され得るからである。従って、エビクションポリシーマネージャ３１１０は、キャッシュエビクションポリシーにおいて始動時間を考慮し得る。
プロセス３１２０は、入ってくるＣ（３）ワーキングセットを収容するために、Ｃ（２）ワーキングセットをエビクションし得る。Ｃ（３）ワーキングセットは、第３コンテナを構築するためのデータであり、Ｃ（１）およびＣ（２）ワーキングセットに関して上記したものと同様のデータを含み得る。図３１Ｂは、図３１Ａによって示されるシナリオ３１００の継続であり得る。図３１Ｂに示されるように、Ｃ（２）データセットおよび関連するデータは、キャッシュ空間３１１２、テーブル３１１４、テーブル３１１６およびテーブル３１１８から消去される。キャッシュ空間３１１２、テーブル３１１４、テーブル３１１６、およびテーブル３１１８は、上記の対応するデータと同様であり得る、第３コンテナについてのデータ、および、Ｃ（３）ワーキングセットを格納する。
図３１Ｃは、強化キャッシュエビクションの方法３１５０を示し、図３１Ａおよび図３１Ｂの強化ＦａａＳサーバアーキテクチャ、および／または、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、方法３１５０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック３１５２は、関数の最初の実行中に始動時間を測定し得る。最初の実行は、関数を実行するためのコンテナの構築だけを含み得る。例えば、始動時間は、コンテナ構築の開始から、コンテナが構築されて関数を実行する準備ができるまでだけ測定され得る。示される処理ブロック３１５４は、始動時間に基づいて、１または複数の加重を生成し得る。１または複数の加重は、始動時間に比例し得る。示される処理ブロック３１５６は、１または複数の加重を利用してデータをエビクションし得る。例えば、キャッシュにおけるコンテナのワーキングセットのユーティリティを示す最終値を計算し、最終値に基づいてデータをエビクションするために、１または複数の加重が加重アルゴリズムにおいて使用され得る。例えば、最終値が別の最終値より大きい（本明細書において説明されたものと同様に計算される）場合、ワーキングセットは、キャッシュからエビクションされないことがあり得、他の最終値に対応する異なるワーキングセットはエビクションされ得る。従って、方法３１５０はキャッシュエビクションを強化し得る。
図３１Ｄは、強化キャッシュエビクションの方法３１７０を示し、図３１Ａおよび図３１Ｂの強化ＦａａＳサーバアーキテクチャ、および／または、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、方法３１７０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック３１７２は、第１コンテナについての第１セットアップ時間を測定し得る。第１関数は、第１コンテナがセットアップ（すなわち構築）された後に第１コンテナにおいて実行し得る。第１セットアップ時間は、第１コンテナの１または複数の名前空間、および、第１コンテナの１または複数の制御グループを構成する、ならびに、実行環境をセットアップする時間であり得る。示される処理ブロック３１７４は、第２コンテナについての第２セットアップ時間を測定し得る。第２関数は、第２コンテナがセットアップされた（すなわち構築された）後に、第２コンテナにおいて実行し得る。第２セットアップ時間は、第２コンテナの１または複数の名前空間、および、第２コンテナの１または複数の制御グループ、ならびに、実行環境を構成する時間であり得る。第２関数は第１関数と異なり得、第１および第２コンテナは互いに異なり得る。
示される処理ブロック３１７６は、第１データセットの使用（例えばアクセス）の第１頻度を測定し得る。第１データセットは、第１コンテナを構築するためのデータであり得る。示される処理ブロック３１７８は、第２データセットの使用（例えばアクセス）の第２頻度を測定し得る。第２データセットは、第２コンテナを構築するためのデータであり得る。アクセスとは、読み取りおよび／または書き込みを意味し得る。
示される処理ブロック３１８０は、第１セットアップ時間と第２セットアップ時間との比較に基づいて、キャッシュからデータオブジェクトをエビクションし得る。更に、示される処理ブロック３１８０は、使用の第１頻度の測定と使用の第２頻度の測定との比較に基づいて、キャッシュからデータオブジェクトをエビクションし得る。第２セットアップ時間が第１セットアップ時間より大きい場合、データオブジェクトは、第１コンテナに関連し得る。例えば、第１セットアップ時間は、第２セットアップ時間より小さいことがあり得る。使用の第１頻度は、使用の第２頻度より、わずかな量だけ大きいことがあり得る。第１セットアップ時間は第２セットアップ時間より少ないので、使用の第１頻度の方が大きいにも関わらず、第１コンテナのデータオブジェクト（すなわち、第１データセット）はエビクションされ得る。データオブジェクトは、第１コンテナを開始する第１データセットを含んでも含まなくてもよい。
いくつかの実施形態において、使用の第１頻度が使用の第２頻度より十分に大きな量だけ大きい場合、第２セットアップ時間が第１第２セットアップ時間より大きいにも関わらず、第１コンテナのデータオブジェクトではなく、第２コンテナに関連するデータオブジェクト（すなわち第２データセット）がエビクションされ得る。例えば、使用の第１頻度が使用の第２頻度より、予め定められた量だけ大きい、またはある割合より大きい場合、第２コンテナに関連するデータオブジェクトはエビクションされ得る。いくつかの実施形態において、データオブジェクト（すなわちデータセット）の使用の頻度が特定の閾値より低下した場合、データオブジェクトは、始動時間を考慮することなくエビクションされ得る。従って、方法３１７０は、キャッシュエビクションを強化し、関数実行のレイテンシを低減し得る。
図３１Ｅは、強化キャッシュエビクションの方法３１９０を示し、図３１Ａおよび図３１Ｂの強化ＦａａＳサーバアーキテクチャ、および／または、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、方法３１９０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック３１９２は、第１コンテナについての第１セットアップ時間を測定し得る。説明されたように、第１セットアップ時間は、第１コンテナを構築する時間であり得る。示される処理ブロック３１９４は、第２コンテナについての第２セットアップ時間を測定し得る。説明されたように、第２セットアップ時間は、第２コンテナを構築する時間であり得る。示される処理ブロック３１９６は、第１セットアップ時間に基づいて、第１コンテナのデータオブジェクトについての生存時間を決定し得る。データオブジェクトはキャッシュに格納され得る。示される処理ブロック３１９６は、第２セットアップ時間に基づいて、第２コンテナのデータオブジェクトについての生存時間を更に決定し得る。第２コンテナのデータオブジェクトは、キャッシュに格納され得る。図には示されないが、生存時間が終了した場合、第１および第２オブジェクトはエビクションされ得る。
追加の留意点および例
例３１００は、命令セットを含む、少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１コンテナについての第１セットアップ時間を測定させ（第１関数は第１コンテナにおいて実行し、第１セットアップ時間は、第１コンテナの１または複数の名前空間、および、第１コンテナの１または複数の制御グループを構成する時間である）、第２コンテナについての第２セットアップ時間を測定させ（第２関数は、第２コンテナにおいて実行し、第２関数は第１関数と異なり、第２セットアップ時間は、第２コンテナの１または複数の名前空間、および、第２コンテナの１または複数の制御グループを構成する時間である）、第１セットアップ時間と第２セットアップ時間との比較、および、第２データセットの使用頻度と比較した第１データセットの使用頻度に基づいてキャッシュからデータオブジェクトをエビクションさせる（第１データセットは、第１コンテナを構築するために利用され、更に、第２データセットは、第２コンテナを構築するために使用され、更に、データオブジェクトは第１データセットを含む）。
例３１０１は、命令セットを含む、少なくとも１つのコンピュータ可読媒体を含み、命令セットはコンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１コンテナについての第１セットアップ時間を測定させ（第１関数は、第１コンテナにおいて実行する）、第２コンテナについての第２セットアップ時間を測定させ（第２関数は第２コンテナにおいて実行し、第２関数は第１関数と異なる）、第１セットアップ時間と第２セットアップ時間との比較に基づいて、キャッシュからデータオブジェクトをエビクションさせる（データオブジェクトは第１コンテナに関連する）。
例３１０２は、例３１０１の少なくとも１つのコンピュータ可読媒体を含み、第１セットアップ時間は、第２セットアップ時間より大きい。
例３１０３は、例３１０２の少なくとも１つのコンピュータ可読媒体を含み、第１セットアップ時間は、第１コンテナの１または複数の名前空間、および、第１コンテナの１または複数の制御グループを構成する時間であり、第２セットアップ時間は、第２コンテナの１または複数の名前空間、および、第２コンテナの１または複数の制御グループを構成する時間である。
例３１０４は、更なる命令セットを含む、例３１０２の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１コンテナの使用頻度に基づいて、データオブジェクトをキャッシュからエビクションさせる。
例３１０５は、更なる命令セットを含む、例３１０２の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第２データセットの使用頻度と比較した第１データセットの使用頻度に基づいてデータオブジェクトをキャッシュからエビクションさせ、第１データセットは、第１コンテナを構築するために利用され、第２データセットは、第２コンテナを構築するために使用され、データオブジェクトは第１データセットを含む。
例３１０６は、更なる命令セットを含む、例３１０２の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１セットアップ時間に基づいて、第１コンテナのデータオブジェクトについての生存時間を決定させ、第２セットアップ時間に基づいて、第２コンテナのデータオブジェクトについての生存時間を決定させる。
例３１０６は、例３１００の少なくとも１つのコンピュータ可読媒体を含み、データオブジェクトは、第１コンテナを開始するためのデータを含む。
強化ＦａａＳ関数分散の例
本明細書において既に説明されたように、いくつかの関数は、実行中にデータセットに依存し得る。データセットは、コンテナに含まれ得るので、関数は、適切なデータセットにアクセスするために、適切なコンテナに提供され得る。いくつかのデータは大きく、および／または、Ｈａｄｏｏｐ環境などにおいて分散され得る。したがって、データセットを関数へ移動させることは、非効率であり得、および／または、環境の総コスト（ＴＣＥ）を増加させ得る。すなわち、関数が接触、または、修正し得るデータ（すなわち、メモリまたはストレージまたはネットワークフットプリント）は、動作が完了するレイテンシ、および、サービスプロバイダによって提供される計算リソースの効率的使用に著しく関係があり得る。いくつかの関数およびデータセットは、同様に、専用コンピューティング（例えば、ハードウェアアクセラレータ）なしで、増加したＴＣＥを有し得る。
したがって、図３２Ａの３２００の例において、オーケストレータ３２０２は、ＦａａＳインフラストラクチャを解析して、第１ノード３２０８および第２ノード３２１６から、レイテンシが最低である関数Ｆ１のデータセットの転送を有するノードを識別し得る。オーケストレータ３２０２は、データ移動、およびデータ移動コストに基づいて、関数Ｆ１をスケジューリングし得る。例えば、コストアナライザ３２０４は、第１ノード３２０８および第２ノード３２１６の各々において、関数Ｆ１の実行の総コストを決定し得る。総コストは、データの移動のコスト、および、実行のコストの総和であり得る。総コストは更に、レイテンシ測定、実行時間測定、リソース測定、セキュアチャネル確立、暗号化／復号または圧縮／展開レイテンシ測定、ネットワークホップ、帯域幅およびバッファリング推定などを含み得る。例えば、オーケストレータ３２０２は、関数Ｆ１の実行に関連するデータオブジェクト、および、データオブジェクトの局所性を決定し得る。オーケストレータ３２０２は、好ましいリソース利用に基づいて、関数Ｆ１およびデータオブジェクトの分散のオーケストレーションを行い得る。したがって、オーケストレータ３２０２は、リソースを解放し、実行の総コストを低減し、より低いＩＯ帯域幅を有し、より低いレイテンシの関数実行を有し得る。
図３１Ａおよび図３１Ｂの実施形態と同様に、第１ノード３２０８は、データオブジェクトをＣ（１）ワーキングセットに格納するキャッシュ３２１２を含む。簡潔性のために、同様のコンポーネントの同様の説明は省略される。例えば、図３２Ａのキャッシュコントローラ３２１０、キャッシュ３２１２、および始動タイマ３２１４は、図３１Ａのキャッシュコントローラ３１０４、キャッシュ３１０２、および始動タイマ３１０８と同様に動作し得る。同様に、第２ノード３２１６は、図３１Ａ～図３１Ｂの実施形態と同様に動作し得る。
理解されるように、Ｃ（１）は第１コンテナの略である。Ｃ（１）ワーキングセットは、第１コンテナについてのワーキングセットである。例において、第１コンテナは解体され、非アクティブである（構築されない）。第１コンテナが解体される場合、第１コンテナを迅速に構築するために、Ｃ（１）ワーキングセットは、キャッシュ３２１２に維持される。すなわち、Ｃ（１）ワーキングセットは、第１コンテナを構築するために使用され得る。
オーケストレータ３２０２は、関数Ｆ１が特定のコンテナにおいて実行し得るかどうかを決定し得る。例えば、関数アナライザ３２０６は、関数Ｆ１の関数コンストラクトから選択的フィールド（例えばメタデータ）の特性を決定し得る。図３３Ａおよび図３３Ｂ、ならびに、関連する説明は、関数コンストラクトをより詳細に説明する。メタデータは、データモニカとの関数Ｆ１の関連を説明する。データモニカは、データセットコンストラクトのアイデンティティの近似的表現であり得る。モニカは、セット関数（例えば、ブルームフィルタ）および／またはモニカ構築ＡＰＩによって、関数の様々な汎用一意識別子、関数のコール元、関数の特定のパラメータ、関数に関連するファイルシステムパス名、レジリエント分散データセット系列、例えば、Ｓｐａｒｋ、関数によってアクセスされる関係データベースにおけるテーブル空間範囲などを通じて構築され得る。従って、関数アナライザ３２０６は、モニカ構築ＡＰＩをインタラクトして、モニカを取得し、および／または、セット関数を含み得る。いくつかの実施形態において、関数アナライザ３２０６は、モニカ構築ＡＰＩを含み得る。図３３Ａおよび図３３Ｂを参照して、更なる詳細を下で説明する。
モニカは、実行中に関数Ｆ１が必要とし得るリソース（例えば、アクセラレータ、データ、加重式、ハードウェア要件など）の名称のコンパクトな表現または記述であり得る。モニカは、特定のデータセットが、実行中に関数Ｆ１によって利用され得ることを示し得る。そのような特定のデータセットは、Ｆ１データセットと呼ばれ得る。
関数アナライザ３２０６は、メタデータに基づいてモニカを決定し得、関数Ｆ１は、モニカに対するソフトアフィニティを有するコンテナのタイプを決定して、コンテナがＦ１データセットの少なくとも一部、および、実行中に必要とされ得る他のリソースを含み得るかどうかを決定し得る。第１ノード３２０８および第２ノード３２１６は、オーケストレータ３２０２に対し、任意の格納されたワーキングセット（例えばＣ（１）ワーキングセット）を通知し得る。オーケストレータ３２０２は、Ｃ（１）ワーキングセットがモニカに対するソフトアフィニティを有するコンテナを構築し得るかどうかを決定し得る。いくつかの実施形態において、オーケストレータ３２０２は、Ｃ（１）ワーキングセットがＦ１データセットの少なくとも一部を含むかどうかを決定し得る。
従って、オーケストレータ３２０２は、関数Ｆ１とデータセットとの間の関連を定義する。それは、潜伏状態として機能し、実行中に関数Ｆ１が必要とする可能性がもっとも高いデータのローカル、ウォームコピーを処理する可能性がもっとも高いコンテナ（例えば、下で説明される第１コンテナ）へ関数Ｆ１を誘引することによって、ストレージ、キャッシュ、および通信の効率的なスケジューリングをガイドする。更に、上記の強化は、サーバレス抽象化に違反することなく実現され得る。
より詳細には、本例において、関数アナライザ３２０６は、実行中に関数Ｆ１が利用することになるＦ１データセットの少なくとも一部を含む第１コンテナを決定し得る。オーケストレータ３２０２は、第１ノード３２０８が、上記のように第１コンテナを構築するのに使用され得るＣ（１）ワーキングセットを含むと判定し得る。したがって、オーケストレータ３２０２は、第１ノード３２０８が、Ｆ１データセットの少なくとも一部を含み得ると識別し、関数を第１ノード３２０８へ誘導し得る。例えば、構築の前に、オーケストレータ３２０２は、キャッシュ３２１２に格納されるＣ（１）ワーキングセットをＦ１データセットと比較し、格納されたＣ（１）ワーキングセットがＦ１データセットの少なくとも一部を含むと判定し得る。
対照的に、第２ノード３２１６は、任意の関連するデータオブジェクトを含まないことがあり得る。第２ノード３２１６が、いくつかのワーキングセット（不図示）を含み得る一方、それらのワーキングセットは、Ｆ１データセットの実行に関連するデータを含まないので省略される。
コストアナライザ３２０４は、第１ノード３２０８および第２ノード３２１６の総コストを決定して、関数Ｆ１を実行し得る。総コストは、予測されるコスト、予測される推定、基礎となるレイテンシ、および／または、推定されるレイテンシであり得、予測または推定されるコストおよびレイテンシは、第１ノードと第２ノードとの間でデータを運ぶコストおよびレイテンシを含む。合計は更に、レイテンシ測定、実行時間測定、リソース測定、セキュアチャネル確立、暗号化／復号または圧縮／展開レイテンシ測定、ネットワークホップ、帯域幅およびバッファリング推定などを含み得る。第１ノード３２４８の総コストは、第１ノード３２０８においてコンテナ（例えば、第１コンテナ、または追加データを有する第１コンテナの修正バージョン）を構築するコストを表し、第１ノード３２０８において関数Ｆ１を実行し得る。第２ノード３２１６の総コストは、第２ノード３２１６において関数Ｆ１を実行し、第２ノード３２１６において関数Ｆ１を実行するためにコンテナを構築するためのコストを表し得る。総コストは、関数Ｆ１を第１ノード３２０８または第２ノード３２１６へ送信するかどうかを決定するために比較され得る。
より詳細には、コストアナライザ３２０４は、関数Ｆ１を実行するための、第１ノード３２０８および第２ノード３２１６の各々の総コストを決定し得る。総コストは、第１ノード３２０８および第２ノード３２１８の各々について決定され得、通信コスト（例えば、コンテナを構築するために転送される必要があるデータの量、データへの近接度など）、コンテナの構築コスト、実行レイテンシコスト（例えば、アクセラレータが必要かどうか）などに基づき得る。
例えば、第１ノード３２０８および第２ノード３２１６のうちのノードが、関数Ｆ１の実行を促進するためのアクセラレータを含む、および／または、関数Ｆ１をサポートするのに十分なリソースを含む場合、実行レイテンシコストが低減され得る。関数Ｆ１をサポートするリソースが無い場合、または、アクセラレータがノードによってサポートされない場合、実行コストが増加し得る。オーケストレータ３２０２は、総コストの比較に基づいて、第１ノード３２０８および第２ノード３２１６のうちのノードに、または、第１ノード３２０８および第２ノード３２１６のうち最低の総コストを有する一方に関数Ｆ１を割り当て得る。
例えば、第２ノード３２１６は、第１ノード３２０８と比較して、関数Ｆ１を実行するための、より高いレイテンシを（すなわち、より高いレイテンシコスト）もたらし得る。詳細には、第２ノード３２１６は、関数Ｆ１についてのコンテナを構築するためのすべてのデータを受信し、次に、コンテナを構築する必要があり得る。対照的に、第１ノード３２０８は、キャッシュ３２１２にローカルに格納されたＣ（１）ワーキングセットから第１コンテナを迅速に構築し、必要な場合は更なるデータで第１コンテナを修正し得、それにより、第２ノード３２１６によってもたらされる通信レイテンシコストの少なくともいくらかを回避する。従って、Ｆ１データセットとＣ（１）ワーキングセットとの間の重複に起因して、第１ノード３２０８の通信レイテンシは、第２ノード３２１６と比較して低減され得、それにより、第１ノード３２０８の全体のコストが低減する。その結果、第１ノード３２０８で関数Ｆ１を実行する総コストは、第２ノード３２１６で関数Ｆ１を実行する総コストより低いことがあり得る。
いくつかの実施形態において、Ｃ（１）ワーキングセットは、Ｆ１データセットの一部だけを含み得、データの残りは、第１コンテナの構築前に、または、構築中に第１ノード３２０８に到着する。そのような実施形態において、コストアナライザ３２０４は、第１ノード３２０８で関数Ｆ１を実行する総コストの一部として、データの残りを転送するコストを含み得る。第１ノード３２０８がデータの残を受信した後、第１コンテナは、関数Ｆ１を実行するためのデータの残りで増大され得る。
本例において、オーケストレータ３２０２は、第１ノード３２０８で関数Ｆ１を実行するための総コストが、第２ノード３２１６で関数Ｆ１を実行するための総コストより低いと判定し得る。プロセス３２２４は、関数Ｆ１を分散し得る。詳細には、オーケストレータは、関数Ｆ１を第１ノード３２０８に提供し得る。図３２Ｂに示されるように、第１ノード３２０８は、キャッシュ３２１２に格納されたＣ（１）ワーキングセットに基づいて、第１ノード３２０８においてコンテナＣ（１）３２２６（すなわち第１コンテナ）を構築する。
いくつかの実施形態において、コンテナＣ（１）は、関数Ｆ１の実行を促進するために、Ｃ（１）ワーキングセットに含まれない更なるデータで増大され得る。関数Ｆ１は次に、実行を開始し得る。例えば、第１ノード３２０８は、実行中に関数Ｆ１が利用するいくつかのデータを受信し得、コンテナＣ（１）の構築中にそのデータをコンテナＣ（１）に追加し得る。
図３２Ｃを参照すると、例３２４０が示される。簡潔性のために、図３２Ａ、図３２Ｂに示されるものと同様のコンポーネントは、ここで繰り返し説明されない。しかしながら、対応するコンポーネントは、互いに同様に動作し得ることが理解されるであろう。
例３２４０において、関数Ｆ２はオーケストレータ３２４２によって割り当てられる。上の実施形態と同様に、第１ノード３２４８は、関数Ｆ２を実行するための第１コンテナを構築するためのＣ（１）ワーキングセットを含み、一方、第２ノード３２５８は、そのようなワーキングセットを含まない。
関数アナライザ３２４６は、関数Ｆ２を解析して、Ｆ２データセットを決定し得る。オーケストレータ３２４２は、Ｃ（１）ワーキングセットが、Ｆ２データセットの第１部分だけを含むと判定し得る。したがって、第１ノード３２４８で関数Ｆ２を実行するべく、Ｆ２データセットの第２部分は、第１ノード３２４８へ送信される必要がある。第２ノード３２５８は、任意の関連するワーキングセットを含まないことがあり得るので、新しいコンテナは、関数Ｆ２を実行するための第２３２５８で構築される必要がない。
コストアナライザ３２４４は、第１ノード３２４８および第２ノード３２５８の総コストを判定し得る。第１ノード３２４８の総コストは、Ｆ２データセットの第２部分を第１ノード３２４８へ送信するためのコストを含み得る。第１ノード３２４８は、Ｆ２データセットの第２部分を第１ノード３２４８へ送信するためのデータソースから遠いことがあり得る。データソースは別のノードであり得る、Ｆ２データセットの第２部分を有する第１ノード３２４８からもっとも近いノードであり得る。従って、コストアナライザ３２４４は、Ｆ２データセットの第２部分を送信するための通信コストが高く、第１ノード３２４８の総コストがそれに対応して高いと判定し得る。
第２ノード３２５８の総コストは、第１コンテナを構築するためのすべての構築データを受信するコストであり得る。しかしながら、この本例において、第２ノード３２５８は、データソースに近く位置し得る。データソースは、すべての構築データを含み得、構築データを第２ノード３２５８へ送信可能であり得る。したがって、第２ノード３２５８の通信コストは、第１ノード３２４８の通信コストより著しく低いことがあり得る。通信コストの間の著しい差異に起因して、ワーキングセットが存在しなくても、第２ノード３２５８は、より低い全体のコストを有し得る。オーケストレータ３２４２は、第２ノード３２５８がワーキングセットを有しないにも関わらず、第２ノード３２５８のデータ転送コストが低いことに起因して、第２ノード３２５８で関数Ｆ２を実行することがより効率的（レイテンシがより低い）であると判定し得る。従って、オーケストレータ３２４２は、レイテンシコストを低減するために、データソースから遠く離れたノードでコンテナを構築するのではなく（関連するワーキングセットを有する場合でも）、データソースに近いノードでコンテナを構築し得る。
プロセス３２６６において、オーケストレータ３２４２は、関数Ｆ２を分散し得る。図３２Ｃの例３２４０の継続である図３２Ｄに示されるように、関数Ｆ２は第２ノード３２５８に提供される。コンテナ３２６８は、データソースから受信されたデータに基づいて関数Ｆ２で実行するように構築され得る。
従って、図３２Ａ～図３２Ｄの上の実施形態は、強化された方式であるが、計算をデータへプッシュし得、そうでなければそれらが実行されるハードウェアまたは実行中に参照し得るデータの物理的位置に依存しない動作を実行する。実施形態は、関数を実行するレイテンシを低減し、更に、リソース利用を低減し得る。
図３２Ｅは、強化された関数分散の方法３２８０を示し、図３２Ａ～図３２Ｄの強化ＦａａＳサーバアーキテクチャ、および／または、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、方法３２８０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック３２８２は、実行される関数を識別し得る。示される処理ブロック３２８４は、実行中に関数が利用するデータセットを判定し得る。示される処理ブロック３２８６は、第１ワーキングセットがデータセットの少なくとも一部を含むかどうかを判定し得る。第１ワーキングセットは、第１コンテナを始動するためのリソースを含み得る。更に、第１ワーキングセットは、第１ノードに格納され得る。例えば、第１ワーキングセットは、第１ノードのハードウェアおよび／またはソフトウェアキャッシュに格納され得る。
示される処理ブロック３２８８は、第１ノードで第１関数を実行するための第１総コストを計算し得る。第１総コスト計算は、第１ワーキングセットがデータセットの一部を含むかどうかに基づき得る。例として、示される処理ブロック３２８６は、第１ワーキングセットがデータセットの第１部分だけを含むと判定し得る。そのような実施形態において、示される処理ブロック３２８８は、データセットの第２部分を第１ノードへ転送するための転送コスト（第１総転送コストと呼ばれ得る）を判定し、第１総コストに転送コストを含め得る。例えば、示される処理ブロック３２８８は、第１コンテナを構築するためのコスト、および、転送コストを含む第１総コストを判定し得る。
示される処理ブロック３２９０は、第２ノードにおける第２コンテナにおいて第１関数を実行する第２総コストを計算し得る。第２総コストは、第２ノードにおける第２コンテナを構築するためのデータを転送するデータ転送コスト、および、第２コンテナを構築するコストを含み得る。第２コンテナはコールドコンテナであり得る。
示される処理ブロック３２９２は、第１および第２総コストの計算に基づいて、関数を第１ノードで実行するか、または第２ノードで実行するかを決定し得る。例として、示される処理ブロック３２９２は、第１ノードで第１コンテナを始動するかどうかを決定し、第１ワーキングセットがデータセットの少なくとも一部を含むかどうかに基づいて、第１ノードにおける第１コンテナにおいて関数を実行し得る。
示される処理ブロック３２９２は、第１総コストが第２総コストより少ない場合、第１ノードにおける第１コンテナを構築し、第１ノードにおける第１コンテナにおいて関数を実行し得る。対照的に、第２コンテナは、第２ノードにおいて構築され得、第２総コストが第１総コストより少ない場合、関数は、第２ノードにおける第２コンテナにおいて実行し得る。
追加の留意点および例
例３２００は、命令セットを含む、少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、実行されるべき関数を識別させ、実行中に関数が利用するデータセットを決定させ、少なくともデータセットの第１部分だけを含む第１ワーキングセットを決定させ（第１ワーキングセットは、第１コンテナを始動するためのリソースを含み、第１ワーキングセットは第１ノードに格納され、第１ワーキングセットは第１ノードのキャッシュに格納される）、データセットの第２部分を第１ノードへ転送する転送コストを決定させ、第１ノードにおいて関数を実行する第１総コストを決定させ（第１総コストは、第１コンテナを構築するコスト、および転送コストを含む）、第２ノードにおける第２コンテナにおいて関数を実行する第２総コストを決定させ（第２総コストは、第２ノードにおける第２コンテナを構築するためのデータを転送するデータ転送コスト、および、第２コンテナを構築するコストを含む）、第２総コストが第１総コストより少ない場合、第２ノードで第２コンテナを構築させ、第２ノードにおける第２コンテナにおいて関数を実行させ、第１総コストが第２総コストより少ない場合、第１ノードにおける第１コンテナを構築させ、第１ノードにおける第１コンテナにおいて関数を実行させる。
例３２０１は、命令セットを含む、少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、実行されるべき関数を識別させ、実行中に関数が利用するデータセットを決定させ、第１ワーキングセットがデータセットの少なくとも一部を含むかどうかを決定させ（第１ワーキングセットは、第１コンテナを始動するためのリソースを含み、第１ワーキングセットは第１ノードに格納される）、第１ワーキングセットがデータセットの少なくとも一部を含むかどうかに基づいて、第１ノードにおける第１コンテナにおいて関数を実行するために、第１ノードにおける第１コンテナを始動するかどうかを決定させる。
例３２０２は、例３２０１の少なくとも１つのコンピュータ可読媒体を含み、第１ワーキングセットは、第１ノードのキャッシュに格納される。
例３２０３は、更なる命令セットを含む、例３２０１の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１ワーキングセットがデータセットの第１部分だけを含むと判定させ、データセットの第２部分を第１ノードへ転送する転送コストを決定させる。
例３２０４は、更なる命令セットを含む、例３２０３の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第１ノードにおいて関数を実行する第１総コストを判定させ（第１総コストは、第１コンテナを構築するコスト、および、転送コストを含む）、第２ノードにおける第２コンテナにおいて関数を実行する第２総コストを決定させ（第２総コストは、第２ノードにおける第２コンテナを構築するためのデータを転送するデータ転送コスト、および、第２コンテナを構築するコストを含む）。
例３２０５は、例３２０４の少なくとも１つのコンピュータ可読媒体を含み、第２コンテナはコールドコンテナである。
例３２０６は、更なる命令セットを含む、例３２０４の少なくとも１つのコンピュータ可読媒体を含み、更なる命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、第２総コストが第１総コストより少ない場合、第２ノードにおける第２コンテナを構築させ、第２ノードにおける第２コンテナにおいて関数を実行させ、第１総コストが第２総コストより少ない場合、第１ノードにおける第１コンテナを構築させ、第１ノードにおける第１コンテナにおいて関数を実行させる。
強化ＦａａＳ関数コンストラクトの例
図３３Ａは、関数の関数コンストラクト３３００を示す。図３２Ａ～図３２Ｄの実施形態に関連して説明されるように、関数コンストラクト３３００は、関数を実行する最高のノードを判定するために利用され得る。図３３Ａにおいて、関数コンストラクト３３００は、データモニカとの関連を説明する選択的フィールドを含む。関数コンストラクトフィールドは、それに含まれるメタデータを識別し、メタデータに基づいてモニカとの関連付けを行うために読み取られ得る。データモニカは、関数コンストラクト３３００のアイデンティティの近似的表現であり得る。モニカは、セット関数（例えば、ブルームフィルタ）および／またはモニカ構築ＡＰＩによって、関数の様々な汎用一意識別子、関数のコール元、関数の特定のパラメータ、関数に関連するファイルシステムパス名、レジリエント分散データセット系列、例えば、Ｓｐａｒｋ、関数によってアクセスされる関係データベースにおけるテーブル空間範囲などを通じて関数コンストラクト３３３０から構築され得る。関数コンストラクト３３００を通じて属性を付与される関数が、関数コンストラクトから取得されたモニカとソフトアフィニティで関連するコンテナにおける実行のために提供され得る。従って、モニカは、リソースおよびレイテンシを低減するべく関数を効果的に割り当てるために使用され得る。
データセットコンストラクトは、いくつかのフィールドを含む。フィールドの属性は、関数生成時に生成され、関数実行およびキャッシュ／メモリスラッシングのレベルに基づいて動的に更新され得る。関数実行中にタッチされ、関数コンストラクト３３００から収集されたデータに基づいて、関数コンストラクト３３００に関連する関数は、データのウォームコピーを所有する可能性が高いコンテナに割り当てられ得、それにより、データ移動を低減し、スラッシングの可能性を低減する。
コール元フィールド３３０２は、関数呼び出しのソース（例えば、クライアント、コンピューティングデバイス、地理的エリアなど）を識別するために使用され得る。ソースのアイデンティティ、位置、および／またはデバイスを記述するために、コール元フィールド３３０２からコール元モニカが決定され得る。
引数フィールド３３０４は、関数の引数を識別するために使用され得る。引数は、関数のタイプ、基礎的なデータ要求などを決定するために使用され得る。例えば、引数への入力データが識別され得、特定の言語ライブラリへのアクセスおよび／またはデータ要求が識別され得る。更に、引数の特定のタイプは、特定のハードウェア利用を通じて強化され得る。したがって、関数のコンピュータ言語、データ要求、ハードウェア要件（例えば、アクセラレータ、メモリ空間、プロセッサ速度）などを記述するために、タイプモニカが引数フィールド３３０４から決定され得る。
他のフィールド３３０６は、関数の他の属性を識別するために使用され得る。例えば、他のフィールド３３０６は、実行のための地理的位置、クライアントの位置などを識別するために使用され得る。クライアントの地理的位置および位置などを記述するために、別のモニカが他のフィールド３３０６から決定され得る。他のモニカは、クライアントの地理的位置に近い、または、データが最終的に送信されるノードへ関数を誘導するために使用され得る。
ファイルシステムパス３３０８は、関数のパスを判定するために使用され得る。例えば、ファイルシステムパス３３０８は、関数の出力を節約する位置を識別するために使用され得る。出力を節約する位置を記述するために、パスモニカがファイルシステムパス３３０８から決定され得る。パスモニカは、出力を節約する位置に近いノードへ関数を誘導するために使用され得る。
コンパクトな識別、および、関数のデータセットに関連するその後の使用の目的のために、データベーステーブル空間範囲３３１０は、データベースにおける「タプル」のセットのロジックアイデンティティを説明するために使用され得る。様々なフィールドまたは属性における値が範囲最小値および範囲最大値の中に収まるデータのロジックスパンを記述するために、データベーステーブル空間範囲３３１０から範囲モニカが決定され得る。それは、データ内のフィールドによって満たされる様々な制約に基づいて、関数において使用されるデータの範囲をコンパクトに説明するために使用され得る。
図３３Ｂは、図３３Ｂに示されるような強化関数コンストラクトからのモニカ識別の方法３３５０を示し、図３２Ａ～図３２Ｄの強化オーケストレータ３２０２、３２４２、および／または、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、または、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、それらの任意の組み合わせに格納されたロジック命令セットとして実装され得る。
例えば、方法３３５０に示されるオペレーションを実行するためのコンピュータプログラムコードは、レジスタ転送言語（ＲＴＬ）、Ｊａｖａ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋などのオブジェクト指向のプログラミング言語、および、Ｃプログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１または複数のプログラミング言語の任意の組み合わせで書かれ得る。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
示される処理ブロック３３５２は、関数に関連する関数コンストラクトのフィールドを識別し得る。示される処理ブロック３３５４は、フィールドからメタデータを決定し得る。
示される処理ブロック３３５６は、フィールドから１または複数のモニカを決定し得、モニカは、実行中に関数が利用する１または複数のリソースを示す。例えば、１または複数のリソースは、実行中に関数が利用するデータを含み得る。１または複数のリソースは更に、関数のハードウェアリソース要件を含み得る。１または複数のリソースは更に、実行中に関数が利用するハードウェアアクセラレータを含み得る。更に、１または複数モニカは、関数を実行する地理的エリアを示し得る。更に、１または複数のモニカは、関数のタイプ（例えば、画像認識または画像回転）を示し得る。上記のように、１または複数のリソースおよび関数のタイプは、関数を適切なノードに割り当て、効率性を増加させつつレイテンシを低減するために利用され得る。
追加の留意点および例
例３３００は、命令セットを含む、少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数に関連する関数コンストラクトのフィールドを識別させ、フィールドからメタデータを決定させ、メタデータから１または複数のモニカを決定させる（モニカは、実行中に関数が利用する１または複数のリソースを示し、１または複数のリソースは、実行中に関数が利用するデータ、関数のハードウェアリソース要件、実行中に関数が利用するハードウェアアクセラレータを含み、１または複数のモニカは、関数を実行する地理的エリア、および、関数のタイプを示す）。
例３３０１は、命令セットを含む、少なくとも１つのコンピュータ可読媒体を含み、命令セットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数に関連する関数コンストラクトのフィールドを識別させ、フィールドからメタデータを決定させ、メタデータから１または複数のモニカを決定させる（モニカは、実行中に関数が利用する１または複数のリソースを示す）。
例３３０２は、例３３０１の少なくとも１つのコンピュータ可読媒体を含み、１または複数のリソースは、実行中に関数が利用するデータを含む。
例３３０３は、例３３０１の少なくとも１つのコンピュータ可読媒体を含み、１または複数のリソースは、関数のハードウェアリソース要件を含む。
例３３０４は、例３３０１の少なくとも１つのコンピュータ可読媒体を含み、１または複数のリソースは、実行中に関数が利用するハードウェアアクセラレータを含む。
例３３０５は、例３３０１の少なくとも１つのコンピュータ可読媒体を含み、１または複数のモニカは、関数を実行する地理的エリアを示す。
例３３０６は、例３３０１の少なくとも１つのコンピュータ可読媒体を含み、１または複数のモニカは、関数のタイプを示す。
動的な配置およびプリフェッチの例
現在の既存の解決手段の場合、ＦａａＳ関数は、関数実行の各ステージにおいて最適に配置されない。例えば、実行のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）バージョンとソフトウェア（メモリ）バージョンとの間でデータをリフローする高いリソースコストがあり得る。多くの場合、インフラストラクチャは、任意の所与の時間において、所望される数（およびタイプ）の関数コンテナを迅速な再使用のために利用可能な状態で保持するのに十分なメモリを有しないことがあり得る。
ここで図３４Ａを参照すると、例示的実施形態によると、関数コールの頻度に基づいて関数をプリフェッチするためにコールグラフが使用される例が示される。ユーザインターフェースハンドラ３４４０は、ＦａａＳ関数実行を最適化し、次に、コールグラフ３４６０を生成するためのリクエスト３４５０を受信し得る。コールグラフ３４６０は、関数間のコール関係３４６２を表し得る。
示された例において、オーケストレータ３４７０は、コールグラフ３４６０における関数コールの示される頻度に基づいて、次に呼び出される可能性がもっとも高い関数３４８０をプリフェッチし得る。プリフェッチ関数は、一時ストレージにロードされ、初期化され得る。示された例において、プリフェッチ関数は、サーバ３４９０のキャッシュ３４９２に一時的に格納され得る。オーケストレータ３４７０は、呼び出される可能性がもっとも低い関数をサーバ３４９０が解放するためのコマンドを発行し得る。
図３４Ｂは、一実施形態によるＦａａＳ関数の実行を強化するための方法を示す。方法３４００のブロック３４１０において、関数アクティブ化（コール）の頻度を示すコールグラフが生成され得る。コールグラフは、関数間のコール関係を表す制御フローグラフであり得る。加重コールグラフにおいて、各円弧（プリカーサ（先行関数）から始まり、１または複数の後続関数で終了する）は、後続の呼び出しの頻度（例えば、プリカーサが後続関数をもたらす確率）でタギングされ得る。コールグラフは制御フローグラフと同様であり得るが、ただし、制御フローグラフは、プロシージャの間でコール－リターン関係（およびネスト）を有するのに対し、関数のコールグラフは、実行して、他の関数の実行を引き起こす条件を徐々にトリガする様々な関数のグラフィカルな指示であり、通常、後者の関数は、前者のものによって生成されるデータまたは結果を消費またはアクセスする。例示的実施形態によると、現在、関数Ｆが実行していること、および、それが関数Ｇの実行をもたらすという知識は、Ｇが「プリフェッチ」され得る、すなわち、その構築が開始し得、そのデータが配置／マッピングなどされ得ることを意味する。コールグラフの加重は、確率を表し得、ＦがＧの実行を引き起こす可能性を示す。
コールグラフは統計的に形成され得、次に、動的に洗練され得る。ブロック３４２０において、次に呼び出される可能性がもっとも高い関数が、コールグラフにおける関数コールの示される頻度に基づいてプリフェッチされ得る。すなわち、プリフェッチ関数は、一時ストレージにロードされて初期化され得、その結果、先行関数がアクティブ化するときに関数の実行の準備が整う。ブロック３４３０において、コールグラフの各フェーズ／領域で呼び出される可能性がもっとも低いＦａａＳ関数が、リソースを解放するためにアンロードされ得る。
従来のプログラムにおける通常のプロシージャコールシーケンスと同様に、１つの「コール元」関数は選択的に、リモートプロシージャコールを用いて、別の「コール先」関数を直接的にコールし得る（次に、コール先へのリモートプロシージャコールが完了したという指示を受信するまで待機する）。上記の円弧は更に、後続関数の実行に関連するコストによって増大され得る。ＦａａＳの場合、これは、パラメータおよび結果を渡すコストを含み得る。例えば、バイトサイズ、ならびに、コール先およびコール元関数をホスティングする２つのポイントの間の通信帯域幅を考慮して、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔｉｏｎ（ＪＳＯＮ）オブジェクトのオーバヘッドが通信され得る。コールの頻度、各ホストで利用可能なリソース、コールオーバヘッド、提供される価格／優先度層などに基づいて、各ステージにおいてＦａａＳ関数について最適な配置が計算され得る。ステージは動的であり得る。すなわち、いくつかの関数Ｆがアクティブ化されるたびに、関数Ｆのアクティブ化は、いくつかの他の関数Ｇのアクティブ化をもたらし得、一般的に、Ｇは異なるどこかで実行され得る。
方法３４００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法３４００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法３４００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法３４００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例３４０１は、関数の間のコール関係を表すコールグラフを形成する段階（コールグラフは、コールグラフによって示される関数コールの頻度に基づいて、先行関数が後続関数をアクティブ化する頻度または可能性を示す）と、呼び出されるとき、もっとも可能性が高い次の関数が既に実行の準備を整えられているように、もっとも可能性が高い次の関数をプリフェッチする段階と、もっとも可能性が低い次の関数を少なくとも１つアンロードする段階とを含む方法を含む。
例３４０２は、例３４０１の方法を含み、方法は、コール呼び出しの頻度を表す円弧を利用するコールグラフを更に含む。
例３４０３は、関数コールの頻度／確率に基づいて各ホストで利用可能なリソースを計算する段階を更に含む、例３４０２の方法を含む。
例３４０４
関数コールが既存のアプリケーションに後方互換性を有する、例３４０１の方法。
例３４０５
メモリにおけるデータバージョンを識別するためにメモリ整合性プロトコルが使用される、例３４０１の方法。
例３４０６は、関数の間のコール関係を表すコールグラフを形成する段階（コールグラフは、コールグラフによって示される関数コールの頻度に基づいて、関数コールの頻度を示す）と、呼び出されたときに、もっとも可能性が高い次の関数が既に実行の準備が整えられているように、もっとも可能性が高い次の関数をプリフェッチする段階と、少なくとも１つのもっとも可能性が低い次の関数をアンロードする段階と、コールグラフにおいて円弧を利用する段階（円弧は、コール呼び出しの頻度を表す）と、関数コールの頻度に基づいて、各ホストで利用可能なリソースを計算する段階（関数コールは、既存のアプリケーションと後方互換性があり、メモリ整合性プロトコルは、メモリにおけるデータバージョンを識別するために使用される）とを含む方法を含む。
マルチテナント関数の段階的なマルチバージョンの開始の例
すぐ上に説明された例示的な実施形態は、前の履歴に基づいて（すなわち、第２関数自身だけでなく、先行関数チェーンのサブセットにも基づいて）、関数Ｃ｛Ｆ（ｉ）...Ｆ（ｉｉ）...Ｆ（ｉｉｉ）...Ｆ（ｎ）｝のチェーンにおける第２関数「Ｂ」に及び得る。換言すると、関数のソフトウェアベース、最小高速化、または高速化バージョンを起動するかどうかを選択するとき、例示的な実施形態は、関数Ｂの利用の履歴だけなく、Ｂに先行するチェーンにおける先行関数Ｂｐの利用の履歴も考慮し得る。図３５Ａは、関数Ｂ３５６０の先行関数Ｂｐ３５５０を示すブロック図である。ここでは、現在実行されている関数３５６０の先行関数Ｂｐ５５０が、プリフェッチされて呼び出されるべき次の関数を決定するために使用され得る。
実施形態の例示的の利益は、（複数の競合者の間の）限定されたアクセラレーションリソースの使用のバランスとると同時に、実行のハードウェア（例えばＦＰＧＡ）およびソフトウェア（メモリ）バージョンの間でデータをリフローするコストを最小化することを含む。実際には、実施形態は、データのリフローが最小化されるように、完全バージョンをアクティブ化する代わりに、高速化された関数の最小バージョンのチェーンをアクティブ化することを可能にし得る。
例示的実施形態によると、１の深度のチェーン、Ｂｐ→Ｂがあり得る。上で説明したように、Ｂｐは、関数Ｂに先行する関数を表す。
この実施形態によれば、関数Ｂｐは、関数Ｂの直前の先行関数であり、ｘおよびｙはそれぞれ、関数Ｂの完全バージョンについての起動閾値および回収閾値であり得る。同様に、ｕおよびｖはそれぞれ、Ｂｐの完全バージョンについての起動閾値および回収閾値であり得る。関数の生存時間が満了した場合、または、実行し続けるための加重測定などの他の考慮事項がいくつかの閾値を下回った場合、関数のリソースは「回収」される。反対の方向において、起動閾値に関して、通常はキャッシュまたはプリフェッチされない関数が、使用の増加の兆候を示している場合、使用の増加と共に、関数がキャッシュされる、および、場合によってはプリフェッチされるままにすることが魅力的になる。従って、例示的実施形態によると、関数の先行関数が現在実行されていて、頻度が増加している場合、先行関数は、関数Ｂがプリフェッチされる適格性が起動閾値を超えるようにし得る。例示的実施形態によると、それぞれの関数についての回収閾値は、起動閾値より低いことがあり得る。また、所望のハードウェアまたはソフトウェア条件が満たされることを確実にするために、ｕが下がるとき、ｘは小さい量ｚ（結合寄与率）だけ下がり得、ｖが上がるとき、ｙは小さい量ｚだけ上がり得る。そのような修正は、ｘ、ｙ、および｜ｘ－ｙ｜のすべてが、様々な最大／最小規則に違反しない値をとるように制約されるという条件に従う。
別の例示的な実施形態によれば、ｕおよびｖが変更を許可されないが、ｘおよびｙが変化してよい場合、仮想値ｕ'およびｖ'（ｕおよびｖの影の値）が計算され得、次に、計算された値ｕ'およびｖ'に基づいて、結合寄与率ｚがｘおよびｙそれぞれに適用され得る。例示的実施形態によると、Ｂｐのリソース利用を抑制する必要性から、値'ｕ'および'ｖ'は例えば、変動が許可されないことがあり得る。しかしながら、Ｂｐにおける到着率に上昇がある場合、その上昇は、下向きにｘに影響し得（Ｂへの到着率が増加するので）、同様に、ｙは上向きに影響され得る（Ｂの回収レートを低減するため）。
上記の実施形態は、他動的にチェーン深度＞１に一般化するために使用され得る。一般的に、結合寄与率（ｚ）の計算において、１より多くのパラメータがあり得る。例えば、リソース制約環境において、生存時間の増加の可変量は、関数Ｂおよびその先行関数の需要が低下した場合に、（Ｂがより速く回収され得るように）所与の高速化された関数Ｂに適用され得る。同様に、全体の需要が低い場合、または、ＳＬＡ要件が厳しい場合、その先行関数での観察に基づいて、関数Ｂの起動について、より強い正のバイアス、および、回収されたＢに対する、より強い負のバイアスがあり得る。
ここで図３５Ｂを参照すると、例示的実施形態によると、方法３５００のブロック３５１０において、関数Ａが起動され得る。ブロック３５２０において、関数Ａに先行する先行関数Ｂが識別され得る。ブロック３５４０において、先行関数Ｂおよび関数Ａの利用の履歴に基づいて、関数Ａの高速化バージョンを起動するかどうかが決定され得る。
方法３５００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法３５００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法３５００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法３５００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例３５０１は、関数を起動する段階と、関数に先行する先行関数を識別する段階と、関数に先行する先行関数および関数の利用の履歴に基づいて、関数の高速化バージョン起動するかどうかを決定する段階と、関数および先行関数をレポジトリに格納する段階とを含む方法を含む。
例３５０２は、例３５０１の方法を含み、メッセージ認証コード（ＭＡＣ）を使用して、メモリにおける関数バージョンを識別する段階を更に含む。
例３５０３は、例３５０１の方法を含み、コンテナがリモートプロシージャコール（ＲＰＣ）をインターセプトする段階と、ローカルでそれにサービスを提供する段階とを更に含み、関数は透過的であり、既存のアプリケーションに対して後方互換性がある。
例３５０３は、例３５０１の方法を含み、関数に関連するデータをプリフェッチする段階を更に含む。
例３５０４は、関数を起動する段階と、関数に先行する先行関数を識別する段階と、関数に先行する先行関数、および、関数の利用の履歴に基づいて、関数の高速化バージョンを起動するかどうか決定する段階と、メッセージ認証コード（ＭＡＣ）を使用して、メモリにおける関数バージョンを識別する段階と、コンテナを介して、リモートプロシージャコール（ＲＰＣ）をインターセプトする段階と、ローカルでそれにサービスを提供する段階（関数は透過的であり、既存のアプリケーションに対して後方互換性がある）と、関数に関連するデータをプリフェッチする段階と、関数および先行関数をレポジトリに格納する段階とを含む方法を含む。
適合的回収レートの例
ここで、図３６Ａを参照すると、別の例示的な実施形態によれば、図３６Ａは、関数のが実行さる確率に基づいて、コンテナをウォーム状態に維持する例を示す。詳細には、コンテナ３６５０における関数Ｘ３６５５を完了（実行）すると、コンテナ３６７０における別の関数Ｙ３６７５が実行される確率Ｐ３６６０がある。例えば、ビデオ監視用途において、Ｘはメディアトランスコード関数であり得、Ｙは検出および粗粒度マッチ関数（例えば、ビデオストリームが人または人の一部を示すかどうかを判定する関数）であり得る。または、Ｘは粗粒度マッチ関数であり得る一方、Ｙは認識関数（例えば、ビデオにおいて検出された任意の人が、データベースにおいて既知の人、すなわち、友人または家族、他人などでもあるかどうかを判定する関数）であり得る。処理の時間、および、他の時間的または空間的相関要素に基づいて、この確率Ｐ３６６０は定数であり得るが、通常は変数である。
オーケストレータ３６８０の確率エバリュエータ３６８５は、そのような確率Ｐ３６６０の動的評価次第であり得る、関数Ｙについてのコンテナ３６７０をウォーム状態に維持する決定を生成し得る。または、より一般的には、タイプＹの関数についてのコンテナ回収レートは、この確率Ｐ３６６０に従って変動し得る。確率Ｐ３６６０の最近および履歴の評価の両方に基づいて、回収レートおよび決定を適合することによって、長期情報に関して、最近の情報に適合された、また、ロードバランシングされた全体の目標が達成され得る。
すぐ上の例示的な解決手段は、関数呼び出しのグラフ（またはサービスメッシュ）に一般化され得、更に、高速化された関数に一般化され得、その結果、（ｉ）回収の時間が適応的に変動するだけでなく、（ｉｉ）複数のグラフエッジにわたる確率フローの、より長い範囲の評価が、アクティブ化時間（ウォームアップ時間）が小さくない関数の事前アクティブ化に使用され得る。
一実施形態において、１または複数の独立関数の確率フローを分解するための汎用フレームワークとして、確率的グラフモデル（ＰＧＭ）が使用され得る。ＰＧＭ分解技術およびライブラリは、先行関数Ｘに対する依存性に基づく各関数Ｙの動的確率、および、Ｘの先行関数に基づくＸの動的確率を取得するために使用され得る。より単純であるが機能する単純化は、弱い確率フローを除去し（すなわち、弱い相関の関数を相互独立として処理する）、そのようなグラフを疎にし、次に、確率的プログラミング言語（例えば、ＦＩＧＡＲＯ）で書かれたＰＧＭソルバを適用し得る。別の実装では、加重（それ自体、事前に推定され得る、または動的に推論され得る）によって、関数の頻度をプリカーサまたは先行関数の頻度と比較する単純化された形式として、探索エンジンページランクアルゴリズムを使用し、利用可能なデータに基づいて、異なる関数がどれだけ頻繁に実行される可能性があるかを推定するために、反復ページランクの解決手段を使用し得る。
そのようなアプローチは、ウォームコンテナの数、または、生存時間パラメータを制御するためにハードコード定数または単純なヒューリスティックスを使用する代わりに、関数の高速化または従来の（ＣＰＵソフトウェアベースの）実現の両方のために、アジャイルなリソース割り当てを可能にし得る。代替的に、この例示的な実施形態は、他の実現と共に機能し得、上の確率フロー技術を使用して、収集されたテレメトリの周期評価に基づいてそのようなノブを調整するために使用され得る。更に、総最適化問題自体は、リソース要件によって正規化された、より高い確率のアクティブ化のスループットを最大化することによって、リソース制約スループット問題を最大化するように努めるビンパッキング問題を有し得る。
ここで図３６Ｂを参照すると、一実施形態によるウォームコンテナからＦａａＳ関数を実行する方法が示される。方法３６００のブロック３６１０において、関数Ａが起動され得る。ブロック３６３０において、関数Ａの後続の関数を実行するための、コンピューティングコンテナの準備完了（例えばウォーム状態）は、後続の関数が実行される確率の動的評価に基づいて維持される。
方法３６００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法３６００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法３６００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法３６００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例３６０１は、関数を実行する段階と、関数実行後に、後続の関数が実行される確率の動的評価に基づいて後続の関数を実行するためのコンテナを準備完了状態に維持する段階とを含む方法を含む。
例３６０２は、関数を実行する段階と、関数実行後、後続の関数が実行される確率の動的評価に基づいて後続の関数を実行するためのコンテナを準備完了状態に維持する段階と、関数ロジックではなく関数データだけを消去する段階と、別個のキーが別個の関数に割り当てられた場合、マルチキートータルメモリ暗号化（ＭＫＴＭＥ）キーを決定する段階と、マネージドランタイムではなく、ユーザプログラムだけを回収する段階とを含む方法を含む。
適応型メモリ階層化の例
関数の使用が少なくなる場合、それが占有する容量の量が低減され得る。多くの場合、インフラストラクチャは、任意の所与の時間において、迅速な再使用のために利用可能な、望ましい数（およびタイプ）の関数コンテナを保持するための十分なメモリを有しないことがあり得る。
図４に示されるものなどの、強化ＦａａＳシステムの例示的実施形態によると、関数がそのデータまたはコードを高性能メモリ層に有するべきかどうかの決定において、関数のサイズおよび利用頻度の両方が考慮され得る。他の実施形態において、これは、利用率に基づき得る。すなわち、使用が少ない関数を、完全に回収する代わりに、より低い性能の層（３ＤＸＰメモリなど）において生存させたままにし得る。メモリ内の階層化を有する強化ＦａａＳシステムの一実施形態によれば、メモリ内の階層化は、サイズおよび利用の両方に適合され得る。すなわち、サイズが大きい場合、関数が頻繁に使用される場合でも、関数は、３ＤＸＰなどの遠い層に置かれ得る。利用が少ない場合も、関数は遠い層に置かれ得る。更に、より遠い層にある場合、関数は、既に少ないリソースを消費しているので、対応する長い生存時間を提供されるべきである。
他の実施形態において、ＭＣＤＲＡＭ／ＨＢＭまたはＤＤＲ層など、性能クリティカルメモリ容量を超過することなく、全体的により高いウォームコンテナレートを実現するために、メモリの複数、実際、または、仮想化層の使用が説明され得る。図３７Ａに示されるような、現在の例示的な実施形態において、関数内および関数チェーンの両方に同一のアプローチが適用され得る。
１．関数内：まず、多くの場合、多層メモリにおける性能層（例えば、ＭＣＤＲＡＭ／ＨＢＭ、ＤＲＡＭ）において利用可能な容量の量と比較して、関数は大き過ぎ得ることを考慮する。例えば、Ａｍａｚｏｎ Ｌａｍｂｄａは、コンテナあたりの制限が約４００ＭＢである。これは、多くのトポロジーの公共バージョンにとって十分に大きいが、Ｍａｔｈ Ｋｅｒｎｅｌ Ｌｉｂｒａｒｙ ｆｏｒ Ｄｅｅｐ Ｎｅｕｒａｌ Ｌｅａｒｎｉｎｇ Ｎｅｔｗｏｒｋｓ（ＭＫＬ－ＤＮＮ）（登録商標）にとっては小さ過ぎ得る。
態様が図３７Ａおよび図３７Ｂに示される、現在の例示的な実施形態によれば、関数は、サイズおよび利用の両方に従ってセグメント化され得る。
１ａ．ＤＲＡＭの配置に割り当てるには大き過ぎる関数３７１０は、外部メモリ層３７２０（図３７Ａ）に事前に割り当てられ得る。
１ｂ．全体的に高い使用頻度の履歴を有するが、既に現在の一時停止レート閾値を切らした関数は、即座に回収される代わりに、外部メモリ層に保持され得、より長い期間にわたって生存し得る。一時停止レート閾値は、効果的に、もっとも最近の使用の後に、関数のコンテナが生存する時間であり得る。その時間にリクエストが到着しない場合、そのリソース（主にメモリ）が解放されるように、関数は除去され得る。
利用統計値およびメモリページアクセスプロファイリングによれば、関数の動的コードフットプリントがあまりにも大き過ぎて、その一部を性能層に一時的に割り当てることから利益を得られない場合を除き、経時的に、よりホットなページセットがＭＣＤＲＡＭ／ＨＢＭ／ＤＤＲ確保範囲に反映され得る。
２．関数のチェーン間：すぐ上で説明された概念は、従って、関数のチェーンに及び得る。
２ａ．図３７Ｂに示されるように、関数のチェーン（またはウェブ）における関数Ｘ（ｉ）３７４０の先行関数３７３０または依存関数３７５０がアクティブである場合（上層または下層割り当てメモリにおいて）、Ｘ（ｉ）をリサイクルする（すなわち、Ｘ（ｉ）をホスティングするコンテナを解体する）代わりに、Ｘ（ｉ）は、先行および／または依存関数の継続上で基礎となる外部層配置を与えられ得る。
適応型メモリ階層化のこのアプローチが実装され得る。なぜなら、実行のレイテンシが、メモリがメモリの外層にある非コールドコンテナのより遅い性能より、コールド起動に対して遥かにセンシティブであるからである。更に、このアプローチは、近い層に十分なフリー容量がある場合、遠い階層に維持される、そのようなアクティブコンテナの一時的プロモーションを禁止しない。
図３７Ａの発明概念は、関数内の異なるオブジェクトに適用され得る。例示的な実施形態において、ソフトウェアは、関数が、関数のデータのどの部分を近くに維持するか、および、どの部分がそうでないかを知っていることがあり得る。そのため、例えばＪａｖａ（登録商標）ナーサリー（若いオブジェクトエリア）に通常割り当てられ得るオブジェクトについては、オブジェクトがより長い期間使用される可能性が高いことが分かっている場合、オブジェクトは、どこか別のところ（例えば、メモリのより低い性能層）に割り当てられ得る。すなわち、大きい関数の関数本体全体を外層に置く代わりに、大きい関数の非ナーサリー部分は、外層に置かれ得る。なぜなら、ナーサリーメモリは、いずれにしてもすぐに回収され得るからである。
例示的実施形態によると、図３７Ａまたは図３７Ｂに示される外層がプライバシー攻撃から保護されない場合があり得る。なぜなら、例えば、ハードウェアキー機構によって保護されないからである。そのため、その場合、解決手段は、ソフトウェアによって暗号化された外層に関数の本体を保持し、次に、関数がアクティブ化される必要がある場合に復号し、ＨＷ保護によってカバーされるメモリ層に関数本体を配置することであり得る。そのような暗号化－復号の場合、キーは、キーがＨＷ保護メモリ内で保護される関数に関連付けられ得、そのキーは、ソフトウェアベースの暗号化－復号方法において使用され得る。関数の本体および状態の復号は、特に、そのサイズが大きい場合、最初からそれを再構築するようり安価であり得る。
ここで図３７Ｃを参照すると、一実施形態による関数を適応的にメモリ階層化する方法が示される。方法３７００のブロック３７１０において、関数Ａが起動され得る。ブロック３７２０において、関数Ａのサイズおよび利用頻度が判定される。ブロック３７３０において、関数Ａが頻繁に使用されるかどうかが判定される。ブロック３７３０において、関数Ａが頻繁使用されると判定され、ブロック３７４０において、関数Ａのサイズが大きいかどうかが判定される。関数Ａのサイズが大きい場合、ブロック３７５０において、関数Ａはメモリの遠い階層に置かれる。
方法３７００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法３７００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法３７００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法３７００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例３７０１は、関数を実行する段階と、関数のサイズおよび利用頻度を決定する段階と、関数が頻繁に使用され、サイズが大きい場合、関数をメモリの遠い階層に置く段階とを含む方法を含む。
例３７０２は、例３７０１の方法を含み、暗号化を使用して、メモリ階層において関数を移動させる段階を更に含む。
例３７０３は、キャッシュを使用して、関数間で通信する段階を含む、例３７０１の方法を含む。
例３７０４は、関数を実行する段階と、関数のサイズおよび利用頻度を判定する段階と、関数が頻繁に使用され、サイズが大きい場合、メモリの遠い階層に関数を置く段階と、暗号化を使用して、メモリ階層において関数を移動させる段階と、キャッシュを使用して、関数の間で通信する段階とを含む方法を含む。
高速クラスロードの例
ＣＳＰは通常、ＦａａＳのために、柔軟なスケジューリング機構／モジュールを利用し得る。ＦａａＳのためにマネージドランタイムコンテナをロードおよび解体することはコストが高いことがあり得るので、収入を生み出す目的で使用され得る貴重なＣＰＵ時間を消費し得る。Ｊａｖａ（登録商標）などの静的タイプマネージドランタイム言語において、この問題は特に深刻であり得る。なぜなら、例えばＪａｖａ（登録商標）仮想マシン（ＪＶＭ）などのマネージドランタイムシステムは、例えば単純な「Ｈｅｌｌｏ Ｗｏｒｌｄ」プログラムを実行する場合でも、基本クラスライブラリの完了なセットをロードする必要があり得るからである。これは、従来のデータセンター利用では問題でないことがあり得るが、ＦａａＳについては、コストが高い。
長期実行アプリケーションまたは連続マイクロサービスと異なり、ＦａａＳ実行についてのリクエストの、アドホックで、バースト性で、予測不可能な到着率は、ＱｏＳの期待を達成することが難しい。特に、ＱｏＳの期待自体が１つの関数と次の関数との間で変動する場合は難しい。
例示的実施形態によると、図３８Ａのブロック図に示されるように、ワークロードベースのクラスロード最適化モジュールが提供され、ここでは、使用されるクラスだけが、最適化されたクラスローダによってロードされる。このモジュールは、高速なマネージドランタイムのロード時間を可能にする。
図３８Ａにおいて、クラス利用データ３８６０は、カスタムマネージドランタイムシステムクラスローダ３８５０を介して取得され得る。
カスタムマネージドランタイムシステムクラスローダ３８５０のアナライザ３８５４は、ＦａａＳサービスの関数の第１実行中に呼び出され得る。クラス依存性グラフなどの利用データ、クラス、方法および変数初期化、オフセット計算、脱仮想化、ならびに、Ｊａｖａ（登録商標）固有の方法に対するＪＮＩ関数のバインドに関連するデータは、クラウド関数の後の呼び出しのために、メタデータファイルとして保存され得る。
カスタムマネージドランタイムシステムクラスローダ３８５０は、特定のＦａａＳ関数に関連付けられるメタデータファイルローダ３８５６を介して、その関数の後のすべての実行ために、メタデータファイルをロードし得る。
複数のメタデータファイルが、異なる入力に起因して、単一のＦａａＳ関数ために確立され得る。ＦａａＳ機械学習フレームワーク３８７０によって生成された機械学習アルゴリズムは、カスタムマネージドランタイムシステムクラスローダ３８５０の更なる最適化のために使用され得る。
例示的実施形態によると、ＦａａＳ機械学習フレームワーク３８７０は、関数の履歴から展開される時系列フィードバック、および、同時に独立に発生する関数の多くのアクティブ化からまとめられたクラウドスケールフィードバックの両方の連続アプリケーションを促進し得る。このように、それは、クラウド学習と組み合わされた連続学習の形式である。
ここで図３８Ｂを参照すると、例示的実施形態によると、方法３８００のブロック３８１０において、アナライザ関数は、ＦａａＳサービスの関数の最初の実行中に呼び出され得る。ブロック３８２０において、利用データは、関数の後の実行のために、メタデータファイルとして格納され得る。ブロック３８４０において、メタデータファイルは、関数の後続の呼び出しのためにロードされ得る。
方法３８００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法３８００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法３８００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法３８００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例３８０１は、ＦａａＳサービスの関数の最初の実行中にアナライザ関数を呼び出す段階と、関数の後続の呼び出しのためにメタデータファイルとして利用データを格納する段階と、関数の後続の呼び出しのためにメタデータファイルをロードする段階（複数のメタデータファイルは単一の関数に対応する）とを含む方法を含む。
例３８０２
例３８０１による方法は更に、実行環境に基づいて関数を回収する段階を含む。
例３８０３
例３８０２による方法は、実行環境においてセキュリティポリシーを実装する段階を更に含む。
例３８０４
例３８０１による方法では、いくつかの関数セットは、同一のＭＫＴＭＥキーで符号化される。
例３８０５は、ＦａａＳサービスの関数の最初の実行中にアナライザ関数を呼び出す段階と、関数の後続の呼び出しのためにメタデータファイルとして利用データを格納する段階と、関数の後続の呼び出しのためにメタデータファイルをロードする段階と、実行環境に基づいて関数を回収する段階と、実行環境においてセキュリティポリシーを実装する段階とを含む方法を含む（複数のメタデータファイルは、単一の関数に対応し、いくつかの関数セットは、同一のＭＫＴＭＥキーで符号化される）。
関数リソースの例
ＦａａＳアクティブ化の主な課題の１つは、効率性を最大化しつつアジャイルなリソースのバランシングを行うこと、および、広く変動するＱｏＳに準拠した実行である。長期実行アプリケーションまたは連続マイクロサービスと異なり、ＦａａＳ実行についてのリクエストの、アドホックで、バースト性で、予測不可能な到着率は、ＱｏＳの期待を達成することが難しい。特に、ＱｏＳの期待自体が１つの関数と次の関数との間で変動する場合は難しい。
コンテナについて、他の技術（例えば、ＲＤＴ技術）を使用して、必要なリソースを事前確保し、そのコンテナを、必要性が事前に分からないいくつかの関数に割り当てることは困難であり得る。従って、図４に示されるような強化ＦａａＳシステムの実施形態が、関数が割り当てられるコンテナのために事前確保されるべき関数のリソースの必要性（例えば、どれだけのキャッシュ容量、どれだけのメモリＢＷなど）を識別するために提供される。この情報をキャプチャするために、時系列およびクラウドワイド履歴機構の両方が使用される。それにより、以前に実行した関数が何を必要とするか分かる。次にその情報は、強化ＦａａＳシステムによってＲＤＴパラメータを設定するために使用され得る。
例示的実施形態によると、図３９Ａに示されるように、関数３９２０の履歴から展開される時系列フィードバック３９１２、および、同時に独立に発生する関数３９３０の多くのアクティブ化から展開されるクラウドスケール（水平）フィードバック３９１４の両方の連続アプリケーションを促進するＦａａＳフレームワーク３９１０が提供される。このように、それは、関数のランタイムで実装され得るクラウド学習と組み合わされた連続学習の形式である。
ここで図３９Ｂを参照すると、例示的実施形態によると、以下のコンポーネント／態様が、各関数型３９５０のために提供され得る。
１．ＱｏＳマニフェストベクトル３９４０は、各ＱｏＳベクトルが、単位球Ｑの内部の値を取るように、共通参照に正規化された｛レイテンシ、スループット、可変性、利用、コストなど｝の多次元空間におけるベクトルとして所望される特定のＱｏＳミックスを説明する。ここで、データは、データ間の関係が大きさまたはスケール不変であり得るように表される。
２．コスト関数が単位球Ｃの内部の値をとるように、共通（機械中立）参照に同様に正規化される、リソースコスト関数｛ＣＰＵサイクル、ＭＥＭ ＢＷ、ＩＯ ＢＷ、...など｝３９９０の対応するベクトル。
３．ベクトルＱをＣにおけるベクトルのセットにマッピングする多値満足関数ベクトルＧ＝｛ｇ１，ｇ２，...ｇＮ｝３９６０。すなわち、ＱからＣへの複数の異なるベクトルｇ１（Ｑ）、ｇ２（Ｑ）、...ｇＮ（Ｑ）は、所与のベクトルＱを満たす。
４．ＣおよびＱの両方は、基礎の連続ドメインの離散化バージョンであり得る。また、各Ｇは、探索するための、満足するリソース割り当ての変形の数に限定があるように、Ｎにおける上限に限定され得る。
５．リソースの利用可能なサブセット、または、同等に、時間における所与の出来事でＣにおけるベクトルの利用可能なサブセットを記述する可用性ベクトル３９７０。
６．ＱｏＳに関連するセキュリティベクトル３９８０。
満足関数ベクトルＧ３９６０は、所望または指定のＱｏＳが、評価されたリソースの支出によって満たされ得るローカル履歴の適用から、反復的に訓練（または学習）され得る。リソース支出は、所与の関数についての各ホストまたはコンテナ内のランタイムにおけるテレメトリを通じて利用可能であり得る。加えて、それらはまた、クラウドにおける他のホストまたはコンテナから訓練される満足関数において混合することによって、更新され得る。この混合は、ローカル履歴が、他のホストからの時間的入力に比べてより大きい加重が所与されるように、加重を付けられ得るが、これらの加重は、進化的学習を実現するために、意図的に変更され得る。経時的に、この解決手段は、例えば、機械またはソフトウェアの挙動における一時的な異常、および、需要の本質的な変動に起因する、一時的な変動にレジリエントなリソース割り当てにおける連続的進化を可能にし得る。特に、満足関数における混合は、クラウドスケール学習に一般化しつつ、（ベストフィット満足ベクトルを選択するために）ビンパッキングヒューリスティックスの適用をもたらし得る。
なお更に、例示的実施形態によると、特定のワークロードについてホスト関数を評価するべく、上記のベクトルに関連するテレメトリを集約するために、メタ言語アクセラレータが実装され得る。所望のＱｏＳについてのＱｏＳ仕様（すなわちマニフェスト）があり得る。この仕様は、テナントについてのデータを含み得る（例えば、データベースシステム、画像処理サービスなど、関数がサービスを受けるソフトウェア実装）。テナントについてのそのようなデータを累積および処理する自動的方式があり得る。いくつかの場合において、サービス（例えばデータベース）は、例えば、標準的方式で動作しない場合、そのメトリクスが無視されるべきであると示し得る。
例示的実施形態によると、同一の関数リクエストがサービスの複数のフェーズを通過するにつれて、エンドツーエンドのレイテンシは、時間を累積する、いくつかの関数リクエストにわたってトラッキングされ得る。レイテンシＳＬＡがミリ秒（ｍｓ）のレイテンシを必要とする場合、関数はローカルに維持され得る。例示的な実施形態は、いくつかの閾値レイテンシより下に留まることを保証し得、そのような閾値レイテンシを保証できるリンクの構築を提供し得る。
ここで図３９Ｃを参照すると、一実施形態による、適切なリソースを事前確保するための方法が示される。方法３９００のブロック３９１０において、関数のリソースニーズが識別され得る。ブロック３９２０において、関数が割り当てられるコンテナにおけるリソースは、識別されたリソースニーズに基づいて事前確保され得る。ブロック３９３０において、ＲＤＴパラメータは、識別されたリソースニーズに基づいて設定され得る。
方法３９００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法３６００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法３９００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法３９００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例３９０１は、関数のリソースニーズを識別する段階と、識別されたリソースニーズに基づいて、関数が割り当てられるコンテナにおけるリソースを予め確保する段階と、識別されたリソースニーズに基づいてＲＤＴパラメータを設定する段階とを含む方法を含む。
例３９０２は、例３９０１による方法を含み、関数のワークロードについてのコスト関数を評価するためにアクセラレータを呼び出す段階を更に含む。
例３９０３は、例３９０１による方法を含み、更に、最小レイテンシを保証するためにリンクを構築する段階を含む。
例３９０４は、例３９０１による方法を含み、更に、少なくとも１つのベクトルを使用してＱｏＳを保護する段階を含む。
例３９０５は、関数のリソースニーズを識別する段階と、識別されたリソースニーズに基づいて、関数が割り当てられるコンテナにおけるリソースを予め確保する段階と、識別されたリソースニーズに基づいて、ＲＤＴパラメータを設定する段階と、特定のワークロードについて、コスト関数を評価するために、アクセラレータを呼び出す段階と、最小レイテンシを保証するためにリンクを構築する段階と、少なくとも１つのベクトルを使用してＱｏＳを保護する段階とを含む方法を含む。
強化された軽量プロファイルガイド最適化（ＰＧＯ）の例
特に、非最適化コードは、レイテンシおよびフットプリントの増加を引き起こし、それらは、ＦａａＳパラダイムにおけるコストに直接変換されるので、コードの最適化は、サーバレス実行にクリティカルであり得る。サーバレスアーキテクチャにおけるコードの大部分は、ｎｏｄｅ．ｊｓ、Ｐｙｔｈｏｎ（登録商標）などのような動的言語であり得る。ＰＧＯは、より大きいタイプ専用コンパイラ領域を形成するための重要な手がかりを提供し得、したがって、タイプチェック、およびスタックレジスタからメモリへの漏洩値を最小化する一方で、サーバレスコンピューティングにおけるその使用は、収集、解析、および適用のＣＰＵオーバヘッド、ならびに、結果としてのレイテンシタックスによって抑制され得る。
関数を実行するコストは、ミリ秒単位で測定される実行時間、および、使用されるメモリに依存するので、レイテンシおよびコードフットプリントの低減は、ＦａａＳ環境において非常に重要となる。強化ＰＧＯ方法を用いて、関数ソースコードは最初にコンパイルされ得、実行中に、動的プロファイルが作成され得る。プロファイルは、様々な最適化を行い、将来の関数実行のためにコード性能を改善するために使用され得る。プロファイルは、関数の将来の実行に有用であり得る。なぜなら、関数の将来の実行がどれだけよく実行されるか、または、特定の関数の将来の実行が実際に実行されるかどうか分からないからである。このプロセスは、時間を消費し得る。この例示的な実施形態は、ＦａａＳ関数のためにハードウェアアシスタンスを使用して、上記プロファイル生成を高速化し得る。例えば、上記の動的プロファイルを形成するために、最後の分岐記録または他ハードウェアが実装され得る。動的プロファイルの生成はまた、部分的に、ソフトウェアまたはソフトウェア－ハードウェアの組み合わせを使用して作成され得る。
強化ＰＧＯ方法の更に別の実施形態によれば、関数性能をデグレードする低レベル機械関連ボトルネックが識別され得る。ＦａａＳ実行環境において、関数の後の実行は、異なるマシン上であり得、低レベル機械依存性を理解することは、非常に有用であり得る。
最後に、強化ＰＧＯ方法の更に別の例示的な実施形態によれば、アレイオペレーションをベクトル化する（例えば、画像処理関数において）、分岐リステアリングを最小化する、および、より速いキャッシュにフィットするようにコードをコンパクト化するなど、関数レイテンシを低減するために、強化ＰＧＯ方法を使用する新しい最適化が追加され得る。
強化ＰＧＯ方法の様々な実施形態はまた、ＦａａＳランタイムにおける動的プロファイリング機能を使用して、異常の検出を可能にする。概して、異常検出は、異常イベントを識別するプロセスである。ＦａａＳ実行環境のコンテキストにおいて、異常イベントの例は、不正命令エラー、メモリ領域への禁止されたアクセス、早期または予期されない関数終了を含む。異常イベントを検出すると、強化ＰＧＯ方法は、更なる解析のために、強化ＦａａＳシステムの性能解析ツールに検出を報告する。異常イベントは、例えば、関数が特定のファイルが利用可能であることを期待するが、実際はそれらが利用可能でないことであり得る。
ここで図４０Ａを参照すると、例示的実施形態によると、図４に示されるものなど、強化ＦａａＳシステムのいくつかの強化があり得、コードの最適化４０５０に関連する上記課題にアドレスするための３つの広いカテゴリを含む。
１．第１カテゴリは、ハードウェアアシストコード、および、ＪＩＴに自動的に公開されるコードの両方の集合に関する（４０６０）。
２．第２カテゴリは、コード実行に影響する主な問題を識別することを容易にし得る。例えば、機械ごとに変動する機械性能データの間の低レベルの差異を抽象化する（４０７０）。すなわち、いくつかの関数が特定のマシン上で実行し、実行が遅い場合、機械性能データに関連するそのような情報は、その遅さが、機械が好ましい頻度で実行していないことに起因するものであり、最適化される必要がある関数のいくつかの欠点に起因するものではないことを示し得る。
３．第３カテゴリは、既存のＦａａＳの解決手段の複数の最適化または強化から成る。
最小動的キャッシュおよびＴＬＢフットプリントにコードをコンパクト化する（４０８０）
分岐リステアリングを最小化する（４０９０）
アレイオペレーションをベクトル化する（４０９５）
ＴＬＢは、コンピュータシステムのメモリについてのアドレス変換情報をキャッシングするための性能クリティカル構造である。高レートのＴＬＢミスは、システムおよび関数性能にとってコストが高い。強化ＦａａＳシステムの実施形態は、ＴＬＢミスを低減できるか、または、ＴＬＢミスのペナルティを低減できるか、いずれかの方式でコードをコンパイルできる。例えば、ＣＰＵコアの間でストライドアクセスパターンについての情報を通信し、プリフェッチャを使用して将来の参照を予測する（その結果、ＴＬＢミスは、データのプリフェッチを遅くするだけであるが、それは実際の実行の速度に影響しない）。
同様に、強化ＦａａＳシステムの実施形態は、コードコンパイルを最適化する。その結果、コンパイルされたコードをより小さい動的ページフットプリントに収めることができる（従って、プロセッサキャッシュにおいて消費する空間を低減する）。同様に、頻繁にアクセスされる静的データは同一の位置にあるように、コードによってタッチされる任意の静的データもコンパクト化される。例えば、強化ＦａａＳシステムの実施形態は、異なるコンパイラの選択肢、および、収集されたキャッシュ統計値の下で、関数の実行履歴を解析し、低い時間局所性を有するコードのコンパイル部分（すなわち、それらのコードモジュール）を選択し、それらを、コードの残り部分とは異なる関数のアドレス空間の部分に配置し、Ｌ１命令キャッシュヒットを改善し、同様に、より頻繁にアクセスされる、または同時にアクセスされる様々なデータオブジェクトをまとめ、その結果、Ｌ１データキャッシュヒットを改善できる。そのようなコンパクト化はまた、同時にアクセスされる（命令およびデータページについての）仮想アドレスの平均数を低減し、その結果、ＴＬＢヒットレートは強化ＦａａＳシステムにおいて改善される。
分岐リステアリングとは、前に命令フェッチャが誤った分岐デスティネーションへ行った場合に、命令フェッチャを正しいデスティネーションへリダイレクトするプロセスを指す。例えば、分岐先バッファ（ＢＴＢ）は、キャッシュのような構造であり、前に見られた分岐を探すために強化ＦａａＳシステムによって使用されることができる。ＢＴＢによって提供される現在のプログラムカウンタの数個のビットは、潜在的分岐についての情報を含む。潜在的分岐の予測が誤った場合、命令フェッチャは誤った分岐デスティネーションへ行く。そのような誤った分岐デスティネーションが見つかると、命令フェッチャは、正しいデスティネーションへリステアリングする必要がある。強化ＦａａＳシステムを使用することで、そのような分岐リステアリングを最小化できる。コンパイラは、分岐リステアリングを低減するために多くの異なる技術を使用できる。一例において、コンパイラは、頻繁に取られる分岐が取られることをＢＴＢが容易に予測できるように、分岐の方向を変更できる（通常、後方分岐が取られることを予測するのは前方分岐より容易である）。別の例において、コンパイラは、評価されたプロファイル情報に基づいて、予測ヒントを分岐命令におけるプレフィックスとして使用できる。
強化ＦａａＳシステムの実施形態は更に、アレイオペレーションのベクトル化を通じて関数実行を最適化できる。例えば、強化ＦａａＳシステムの実施形態は、ループオペレーションをベクトルオペレーションのシーケンスに変換するために、ベクトル化コンパイラを採用できる。そのようなベクトル化／変換は、関数実行の性能が改善されるように、強化ＦａａＳシステムが直ちに、オペランドの複数のペアで１つのオペレーションを処理することを可能にする。
強化の第１カテゴリによって抽出され、第２カテゴリよって変換される実行特性はまた、直交値をドライブするのに使用され得る。例えば、ＲＤＴ、ＳＧＸ、および３ＤＸＰなどの情報アーキテクチャ（ＩＡ）一意性などを用いて、ジャストインタイムＱｏＳ、セキュリティ、および、堅牢性を可能にする。
ここで図４０Ｂを参照すると、例示的実施形態によると、方法４０００のブロック４０１０において、関数ソースコードがコンパイルされ得る。ブロック４０２０において、コンパイルされたソースコードの実行中、関数に関連する動的プロファイルが作成され得る。ブロック４０４０において、関数レイテンシを低減するために、作成された動的プロファイルに基づく新しい最適化が作成され得る。
方法４０００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法４０００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法４０００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法４０００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例４００１は、関数のソースコードをコンパイルする段階と、コンパイルされたソースコードの実行中に、関数に関連する動的プロファイルを形成する段階と、関数レイテンシを低減するために、作成された動的プロファイルに基づいて、新しい最適化を形成する段階とを含む方法を含む。
例４００２は、例４００１による方法を含み、更に、ＦａａＳランタイムにおいて動的プロファイリング機能を使用して異常を検出する段階を含む。
例４００３は、例４００２による方法を含み、更に、検出の結果を性能解析ツールに報告する段階を含む。
例４００４は、例４００１による方法を含み、更に、オーケストレータを介して、プロファイルマッピングを維持する段階を含む。
例４００５は、関数のリソースニーズを識別する段階と、識別されたリソースニーズに基づいて、関数が割り当てられるコンテナにおけるリソースを予め確保する段階と、識別されたリソースニーズに基づいて、ＲＤＴパラメータを設定する段階と、特定のワークロードについて、コスト関数を評価するためにアクセラレータを呼び出す段階と、最小のレイテンシを確実にするためにリンクを構築する段階と、少なくとも１つのベクトルを使用してＱｏＳを保護する段階と、ＦａａＳランタイムに動的プロファイリング機能を使用して異常を検出する段階と、検出の結果を性能解析ツールにリポストする段階と、オーケストレータを介してプロファイルマッピングを維持する段階とを含む方法を含む。
時系列フィンガープリントの例
関数は、その実行中、異なる特性を示し、異なるレートで、ＣＰＵ、メモリ、ネットワークなどのようなリソースを使用し得る。これらの特性を理解し、それらを関数に（それらのデマンドフィンガープリントとして）関連付けることは、効率的なリソース割り当ておよびスケジューリングに重要である。例示的なデマンドフィンガープリントを図４１Ｄに示す。しかしながら、デマンドフィンガープリントは、著しく前の実験が無ければ、容易に取得されないことがあり得る。多くの関数は、数日、数週間、数か月にわたって複数回実行され得る。
図４に示されるものなど、強化ＦａａＳシステムの例示的実施形態によると、関数実行の様々なステージで、異なるリソースの利用率に関する詳細なレポートを自動的に生成し、複数の実行を基礎としてデマンドフィンガープリントを生成するプロセスが提供される。いくつかのリソース（例えばＣＰＵ）は、関数の開始時に多く使用され得、いくつかの他のリソース（例えばメモリ、キャッシュ）は、後の部分の間に多く使用され得る。１つの関数は、最終的に、他の関数もコールし得る。そのような詳細なレポートは、ＦＵＮＣＴＩＯＮ ＣＨＲＯＮＩＣＬＥと呼ばれ得る。従って、経時的に、図４１Ａに示されるように、関数の各実行ごとに、関数の様々な性能、電力、およびスケーリング特性またはセンシティビティが取得され得、豊富な履歴が蓄積して、成熟したデマンドフィンガープリントになる。図４１Ｂに示されるように、ＣＳＰのオーケストレータまたはサーバにおいて実装され得るリソースマネージャ４１１０を介する効率的なリソース管理のために、デマンドフィンガープリント情報は、関数をスケジューリングし、リソースを関数に割り当てるために使用され得る。デマンドフィンガープリントは、関数コールチェーン、由来となるコール元（特定のクライアント）、および、関数コールの特定のパラメータの値と関連付けられ得る。
例示的実施形態によると、図４１Ｂに示されるように、デマンドフィンガープリントは、関数生成時に作成され得、メモリ要件およびタイムアウトのような関数パラメータに関する詳細だけを含み得る。関数実行中、様々なリソース消費（例えばＣＰＵ、メモリ）が記録され得る。関数実行の最後に、関数がＣＰＵ／メモリ／ネットワーク集約的である、または、関数が実行されるときの特定のステージがＣＰＵ／メモリ集約的であるなど、異なるリソース利用パターンが推論され得る。複数の関数実行により、デマンドフィンガープリントは成長し、関数のリソース利用パターンに関するより多くの（正確な）情報が取得され得る。このデマンドフィンガープリントは、関数の更なる実行のためのリソーススケジューリングに使用され得る。関数チェイニングの場合、リソースマネージャ４１１０は、チェイニング関数のデマンドフィンガープリントに基づいてリソース（ＣＰＵ、メモリ）を割り当てることによって、チェイニング関数を実行するためにリソースを事前に準備し得る。
ここで図４１Ｃを参照すると、例示的実施形態によると、方法４１００のブロック４１２０において、リソース特性は、実行の各ステージにおいて、実行された関数のデマンドフィンガープリントを生成するために実行された関数に関連付けられ得る。ブロック４１３０において、オーケストレータ（図示せず）は、例えば、関数の実行の複数のステージにおいて、異なるリソースの利用に関する詳細なレポートを生成し得る。ブロック４１４０において、関数の実行がスケジューリングされ得、生成されたレポートに基づいて、リソースは関数に割り当てられ得る。
方法４１００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法４１００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法４１００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法４１００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例４１０１は、実行の各ステージで、実行された関数のデマンドフィンガープリントを生成するために、実行された関数にリソース特性を関連付ける段階と、オーケストレータを介して、関数の実行の複数のステージにおいて、異なるリソースの利用に関する詳細なレポートを生成する段階と、関数の実行をスケジューリングする段階と、生成されたレポートに基づいて、リソースを関数に割り当てる段階とを含む方法を含む。
例４１０２
例４１０１による方法であり、関数のパラメータ、および、関数を呼び出すテナントに関連するデマンドフィンガープリントを生成する段階を更に含む。
例４１０３
例４１０１による方法であり、デマンドフィンガープリントを生成するためにシーケンス解析機械学習モデルを実装する段階を更に含む。
例４１０４は、実行の各ステージで、実行された関数のデマンドフィンガープリントを生成するために、実行された関数にリソース特性を関連付ける段階と、関数の実行の複数のステージで、異なるリソースの利用に関する詳細なレポートをオーケストレータを介して生成する段階と、関数の実行をスケジューリングする段階と、生成されたレポートに基づいて、リソースを関数に割り当てる段階と、関数、および、関数を呼び出すテナントのパラメータに関連するデマンドフィンガープリントを生成する段階と、デマンドフィンガープリントを生成するために、シーケンス解析機械学習モデルを実装する段階とを含む方法を含む。
ディーププロファイリングを自動化するためのフレームワーク方法および手段
関数、および、それらが実行される、その関連するビークル（コンテナなど）の相互不透明性は、その実行のプロファイリング、デバッグ、審査および最適化において著しい課題をもたらす。図４に示されるものなどの、強化ＦａａＳシステムの例示的な実施形態は、方法を提供し、そのいくつかは、関数の性能トレーシングを簡略化するために、および、実行ビークルから取得されたものに情報を統合するために、ハードウェアアシスト型であり得る。この統合において、ホスティングビークル／コンテナまたはプラットフォームの詳細は、所望のレベルの実行ビークル透明性を実現するために、公開されることから適切に保護され得る。関数のアーキテクチャ中立な挙動は、デバッグ、調整、および審査の目的で、プロファイリング、トレース、およびタイムライン化され得る。
ここで図４２Ａを参照すると、強化ＦａａＳフレームワークは、仮想プロファイリングＡＰＩ４２５０を含む。それを介して、関数クライアント４２６０は、不透明マーカ４２７０と共に時間またはイベント区切りトレースを取得し得る。時間またはイベント区切りトレースは、トレース集合中に発生したイベント（例えば、割込み、または、他の信号、タイムアウト、ページフォールトなど）でアノテートされ得る。それらが、細粒度時間単位において発生した場合、関数の実行と共に開始する。関数クライアント４２６０と実行サービスプロバイダとの間でネゴシエートされる透明性の度合いに従って、様々な正規化された集約測定値４２９０を実行環境４２８０から取得するために、不透明マーカ４２７０は、実行ビークル４２８０に提示され得る。
不透明マーカ４２７０は、適切な権限のツールが、インフラストラクチャレベルにあり、従って、（より低い権限レベルで実行する）実行関数に利用可能でないことがあり得る様々な統計値を受信するための方式を提供し得る。このように、プラットフォームレベルイベントまたは統計値は、いくつかの参照ユニットに適切にフィルタリングまたはマッピングされ、次に、トレースに混合され得る。例えば、不透明マーカ４２７０は後に、「ＣＰＵが時間０ｘ１２３４５にターボ周波数Ｇに入った」、または、「時間０ｘ５６７８９にサーマルトリップに起因するメモリエラーが検出され、修正された」などに変換され得る。
集約測定値は、システムおよび関数の挙動をまとめて解析し特性評価するために取得され得る。なぜなら、一般的に、システム内のすべてを非常に細かいレベルで詳細に知る必要は無いことがあり得るからである。例えば、ページフォールトが平均頻度Ｘで発生したこと、または、関数が実行されたときの時間スパン中に、システムがサーマルイベントを経験した、または、いずれのサーマルイベントも経験しなかったことを知れば十分であり得る。例示的実施形態によると、完全な測定値の列を取得することが実行され得るが、いくつかの場合において、それは、公開し過ぎであり、かつ、後に格納および解析することは高価過ぎることがあり得る。関数実行ビークル４２８０から取得される集約測定値は更に、集約測定値を取得する解析の性能を改善するために正規化されることができる。正規化された集約測定値４２９０は、スワップ利用などのソフトウェアメトリクス、および、Ｌ１キャッシュミスなどのハードウェアメトリクスを含み得る。
仮想プロファイリングは、ランタイムに発生し得、関数を実行しているコンテナによって実行され得る。生成されたトレースは、関数の実行の過程のハードウェアおよびソフトウェアメトリクスの集合を含み、また、関数実行または関数チェイニング中に発生した異なるイベントに基づいて分類され得る。不透明マーカ４２７０は、コンテナ層、仮想マシン層、またはハードウェア層によって生成され得る。選択的ハードウェア強化は、抽象化されているがアジャイルな、関数内からの自己特性評価のために、仮想電力管理ユニット（ＰＭＵ）機能へのダイレクトアクセスを提供する。
ここで図４２Ｂを参照すると、例示的実施形態によると、方法４２００のブロック４２１０において、関数は、不透明マーカと共に時間またはイベント区切りトレースを取得し得る。ブロック４２２０において、不透明マーカは、実行環境から集約測定値を取得するために、関数を実行するコンテナなど、関数の実行ビークルに提示され得る。ブロック４２４０において、関数は、仮想ＰＭＵへのダイレクトアクセスを提供され得る。
方法４２００の実施形態は、例えば、本明細書に記載されたようなシステム、装置、コンピュータ、デバイス等といったものに実装されてよい。より具体的には、方法４２００のハードウェア実装は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤ等の構成可能ロジック、または、例えば、ＡＳＩＣ、ＣＭＯＳもしくはＴＴＬ技術等の回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせを含んでよい。代替的にまたは追加的に、方法４２００は、１または複数のモジュールにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリ等の機械またはコンピュータ可読記憶媒体に格納された、プロセッサまたはコンピューティングデバイスによって実行されるべきロジック命令セットとして実装されてよい。例えば、コンポーネントのオペレーションを実行するためのコンピュータプログラムコードは、例えばＰＹＴＨＯＮ、ＰＥＲＬ、ＪＡＶＡ（登録商標）、ＳＭＡＬＬＴＡＬＫ（登録商標）、Ｃ＋＋、Ｃ＃等のオブジェクト指向プログラミング言語を含む１または複数のＯＳ適用可能／適合プログラミング言語と、「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語との任意の組み合わせで書き込まれ得る。
方法４２００の実施形態またはその一部は、ファームウェア、アプリケーション（例えば、アプリケーションプログラミングインタフェース（ＡＰＩ）を介して）、またはオペレーティングシステム（ＯＳ）上で実行されるドライバソフトウェアにおいて実装されてよい。さらに、ロジック命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、状態設定データ、集積回路用構成データ、電子回路をパーソナライズする状態情報、および／またはハードウェア固有の他の構造コンポーネント（例えば、ホストプロセッサ、中央演算処理装置（ＣＰＵ）、マイクロコントローラ等）を含み得る。
追加の留意点および例
例４２０１は、関数を介して、関数および不透明マーカの時間またはイベント区切りトレースを取得する段階と、実行ビークルから関数についての情報を取得するために、関数に関連する実行ビークルに不透明マーカを提示する段階と、１または複数のハードウェアコンポーネントへのダイレクトアクセスを関数に提供する段階とを含む方法を含む。
例４２０２は、例４２０１の方法を含み、更に、信頼されるエンティティへ供給されるエンクレーブへ、署名されたデータを格納する段階を含む。
例４２０３は、例４２０１の方法を含み、更に、不透明マーカに関連してキャプチャされたシステムテレメトリを暗号化する段階（暗号化はアプリケーション固有の設定を使用して実行され得る）を含む。
例４２０４は、例４２０１の方法を含み、更に、アプリケーションが、実行環境とは関係なくプロファイリングポイントを決定するためのＡＰＩを生成する段階を含む。
例４２０５は、例４２０１の方法を含み、更に、関数およびプロファイリングデータから権限をデカップリングする段階を含む。
例４２０６は、例４２０１の方法を含み、更に、タブ／トークンを挿入するための安全ポイントを管理する段階を含む。
例４２０７は、関数を介して、時間またはイベント区切りトレースおよび不透明マーカを取得する段階と、実行ビークルから情報を取得するために不透明マーカを実行ビークルに提示する段階と、仮想電力管理ユニットへのダイレクトアクセスを関数に提供する段階と、署名されたデータを、信頼されるエンティティへ供給されるエンクレーブへ格納する段階と、アプリケーション固有の設定を使用して、キャプチャされたページを暗号化する段階と、アプリケーションが実行環境とは関係なくプロファイリングポイントを決定するためのＡＰＩを生成する段階と、関数およびプロファイリングデータから権限をデカップリングする段階と、タブ／トークンを挿入するための安全ポイントを管理する段階とを含む方法を含む。
関数実行のためのサーバ選択
ここで図４３Ａを参照すると、強化ＦａａＳシステムのセッション状態管理がユーザインターフェースハンドラ４３００（例えば、例えばＡＰＩゲートウェイなどの、ＡＰＩプロキシ）によって処理される例が示される。示された例において、ユーザインターフェースハンドラ４３００は、関数コンテキスト識別子（ＩＤ）４３０４を含むトークン４３０２（例えば、データ「モニカ」）を生成する。関数コンテキストＩＤ４３０４は、関数を実行するための入ってくるリクエスト４３０６に関連付けられる関数のコンテキスト４３１６を一意に識別する。より具体的には、関数は、コンテキスト４３１６を、データセットコンストラクトのアイデンティティの近似的表現として記述する選択的フィールドで属性を付与され得る。一例において、トークン４３０２は、例えば、様々な汎用一意ＩＤ（ＵＵＩＤ）にわたって適用されるセット関数（例えば、ブルームフィルタ）、リクエスト４３０６のソース（例えば、アプリケーション定義関数マッピングの解決手段における関数のコール元）、関数の特定のパラメータ、ファイルシステムパス名、レジリエント分散データセット（ＲＤＤ）系列（例えば、ＡＰＡＣＨＥ ＳＰＡＲＫ）、関係データベースにおけるテーブル空間範囲などを使用するユーザインターフェースハンドラ４３００のモニカ構築ＡＰＩによって構築され得る。
示された例において、オーケストレータ４３０８は、トークン４３０２（およびより詳細に説明される潜在的な他の要素）に基づいてサーバ位置を選択し、関数呼び出し４３１０と共にトークン４３０２を選択されたサーバ位置へ転送する。示された例において、関数呼び出し４３１０およびトークン４３０２は、コンテキスト４３１６を含むローカルキャッシュ４３１４を含む第１サーバ４３１２へ転送される。ここで、コンテキスト４３１６は、関数によって状態データ（例えば、パーミッション、認証ステータス、トランザクション関連データなど）の取得を促進する。従って、示された解決手段は、関数実行中に使用されるデータへ計算がプッシュされることを可能にする。これに関して、状態データのより効率的な取得が実現される。なぜなら、コンテキスト４３１６はローカルにキャッシュされるからである（例えば、関数固有アフィニティが強化される場合に、同一の状態を有するリクエストを処理する関数がオンデマンドで作成される）。
サーバ位置は、追加の要素に基づいて選択され得る。例えば、第１サーバ４３１２、第２サーバ４３１８、第３サーバ４３２０などの相対位置コスト（例えば、位置へのデータ転送／帯域幅、位置にデータを格納する、および／または、位置でデータを処理するコスト）は、関数呼び出し４３１０およびトークン４３０２を他のところへ転送することを指示し得る。更に別の例において、オーケストレータ４３０８は、サービス品質（ＱｏＳ）要件（例えば、信頼性、処理速度など）に基づいて、サーバ位置を選択する。そのような場合において、第２サーバ４３１８がＱｏＳ要件を満たすことが可能であり、第１サーバ４３１２がＱｏＳ要件を満たすことが可能でない場合、関数呼び出し４３１０およびトークン４３０２は、第２サーバ４３１８へ転送され得る。
更に別の例において、オーケストレータ４３０８は、関数の前の実行のハッシュ結果に基づいて、サーバ位置を選択する。より具体的には、
ＤａｔａＩＤ２＝ｈａｓｈ（ｆｎ（ＤａｔａＩＤ１）
である場合、
ｆｘ（ＤａｔａＩＤ２）がコールされるとき、オーケストレータ４３０８は、ＤａｔａＩＤ２または関数ｆｘ（）を移動するかどうかを決定し得る。
また、サーバ位置は、データがストリーミングされる（例えば、第２、または第３の順序の処理を介して消費される）ノードであり得る。更なる例において、サーバ位置は、関数にする関連する履歴（例えば、時間／時間的履歴）、リクエスト元、および／または、関数コールツリー（すなわち、スケジューリングされる関数を含む呼び出しのシーケンス）に基づいて選択される。
示された解決手段は、関数呼び出し４３１０がリクエスト４３０６に応じてオンデマンドで生成されるという点で、イベントオリエンテーションでＦａａＳシステムを強化する。加えて、サーバ位置の選択がユーザから抽象化されるので、示された解決手段は、最小管理でＦａａＳシステムを強化する。更に、関数呼び出し４３１０がリクエスト４３０６の数に合わせて自動的にスケーリングするので、ＦａａＳシステムは、高いスケーラビリティで強化される。加えて、示された解決手段は、関数がコンピュートスケールの単位であるという点で、スケールのアトミックユニットで、ＦａａＳシステムを強化する。示された解決手段はまた、関数呼び出し４３１０が実行するときだけ顧客が支払うことを可能にし、従って、粒度の高い課金をＦａａＳシステムに提供する。加えて、示された解決手段は、データベースにおいてコンテキスト４３１６を維持する任意の必要性を除去する。そうでない場合、コンテキスト４３１６の取得の効率性が低くなる。
ここで図４３Ｂを参照すると、関数呼び出しを管理する方法４３２２が示される。方法４３２２は概して、例えば、既に説明されたシステム２０２（図２）、システム３００（図３）、および／または、システム４００（図４）などの強化ＦａａＳシステムで実装され得る。より具体的には、方法４３２２は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体において格納されるロジック命令セットとして１または複数のモジュールにおいて実装され得る。
示される処理ブロック４３２４は、関数を実行するための入ってくるリクエストに関連付けられる関数のコンテキストを一意に識別するトークンを生成することを提供する。入ってくるリクエストは、例えば、ユーザによって展開される関数を実行するためのユーザリクエストなどの、ＩｏＴイベントおよび／またはＦａａＳイベントなどのトリガであり得る。一例において、ブロック４３２４は、例えば、既に説明されたユーザインターフェースハンドラ４３００（図４３Ａ）などのユーザインターフェースハンドラによって実行される。ブロック４３２６において、トークンに基づいてサーバ位置が選択される。示されるブロック４３２８は、選択されたサーバ位置で関数を呼び出す。示された例において、コンテキストは、関数による状態データの取得を促進する（例えば、関数はコンテキストから状態データを取得する）。ブロック４３２６および４３２８は、例えば、既に説明されたオーケストレータ４３０８（図４３Ａ）などのオーケストレータによって実行され得る。従って、示される方法４３２２は、イベントオリエンテーション、最小管理、高いスケーラビリティ、スケールのアトミックユニット、および粒度の高い課金という点でＦａａＳシステムを強化する。加えて、示される方法４３２２は、別個のデータベースにおいてコンテキストを維持し、毎回それにアクセスする任意の必要性（これにより、リモートアクセスの追加のレイテンシに起因して効率が遥かに低くなる）を除去する。
図４３Ｃは、関数呼び出しを管理する方法４３３０の更なる詳細を示す。方法４３３０は概して、例えば、既に説明されたシステム２０２（図２）、システム３００（図３）、および／または、システム４００（図４）などの強化ＦａａＳシステムで実装され得る。より具体的には、方法４３３０は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体において格納されるロジック命令セットとして１または複数のモジュールにおいて実装され得る。
示される処理ブロック４３３２は、関数を実行するための入ってくるリクエストに関連付けられる関数のコンテキストを一意に識別するトークンを生成することを提供する。入ってくるリクエストは、例えば、ＩｏＴイベントおよび／またはＦａａＳイベントなどのトリガであり得る。一例において、ブロック４３３２は、例えば、既に説明されたユーザインターフェースハンドラ４３００（図４３Ａ）などのユーザインターフェースハンドラによって実行される。ブロック４３３４において、トークン、および、関数に関連する時間履歴、リクエスト元、関数コールツリー、位置コスト、ＱｏＳ要件、または、関数の前の実行のハッシュ結果のうち１または複数に基づいて、サーバ位置が選択される。示された例において、サーバ位置は、コンテキストを含むローカルキャッシュ、または関数を実行するための性能、ＱｏＳ要件、またはデータアフィニティを最大化する位置を含むように選択される。また、サーバ位置は、データがストリーミングされる（例えば、第２、または第３の順序の処理を介して消費される）ノードであり得る。
ブロック４３３６は、選択されたサーバ位置で関数を呼び出し、コンテキストは、関数による状態データの取得を促進する。ブロック４３３８において、選択されたサーバ位置は、関数に関連する時間履歴に格納される。従って、時間履歴は、関数について将来のサーバ位置を決定するために使用され得る。一例において、ブロック４３３４、４３３６および４３３８は、例えば、既に説明されたオーケストレータ４３０８（図４３Ａ）などのオーケストレータによって実行される。従って、示される方法４３３０は、イベントオリエンテーション、最小管理、高いスケーラビリティ、スケールのアトミックユニット、および粒度の高い課金という点でＦａａＳシステムを強化する。
図４３Ｄは、関数呼び出しの位置がリクエスト元に基づいて選択されるＦａａＳシステム４３４０を示す。より具体的には、第１クライアント４３４２（クライアント１）は、特定の関数を実行するための第１リクエスト４３４４（リクエストＡ）をＦａａＳシステム４３４０へ発行する。第１クライアント４３４２はまた、同一の関数を実行するための第２リクエスト４３４６（リクエストＢ）をＦａａＳシステム４３４０へ発行し得る。加えて、示された例において、第２クライアント４３４８（クライアント２）は、関数を実行するための第３リクエスト４３５０（リクエストＣ）をＦａａＳシステム４３４０へ発行する。そのような場合において、ＦａａＳシステム４３４０は、コンテキストおよび／または状態データを移動する可能性を低減するために、リクエストＡ呼び出し４３５２およびリクエストＢ呼び出し４３５４を共通のサーバ、例えば第ｉサーバ４３５４（サーバｉ）へ送信し得る。対照的に、第３リクエスト４３５０は第２クライアント４３４８（すなわち、異なるリクエスト元）からのものなので、示されるＦａａＳシステム４３４０は、リクエストＣ呼び出し４３５６を第ｊサーバ４３５８（サーバｊ）へ送信する。
図４３Ｅは、関数呼び出しの位置が関数コールツリーに基づいて選択されるＦａａＳシステム４３６０を示す。より具体的には、第１関数コールツリー４３６２（関数コールツリー１）および第２関数コールツリー４３６４（関数コールツリー２）はＦａａＳシステム４３６０へ発行される。そのような場合において、ＦａａＳシステム４３６０は、第１関数コールツリー４３６２に関連するコンテキストおよび／または状態データを移動させる可能性を低減するために、第１関数コールツリー４３６２に対応する第１セットの呼び出し４３６６を第ｉサーバ４３５４へ送信し得る。同様に、示されるＦａａＳシステム４３６０は、第２関数コールツリー４３６４に関連するコンテキストおよび／または状態データを移動さえる可能性を低減するために、第２セットの呼び出し４３６８を第ｊのサーバ４３５８へ送信する。
追加の留意点および例
例４３０１は、実行可能プログラム命令のセットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数を実行するための入ってくるリクエストに関連する関数のコンテキストを一意に識別するトークンを生成させ、トークン、および、関数に関連する時間履歴、リクエスト元、関数コールツリー、位置コスト、サービス品質（ＱｏＳ）要件、または関数の前の実行のハッシュ結果のうち１または複数に基づいてサーバ位置を選択させ（サーバ位置は、コンテキストを含むローカルキャッシュを含むように選択される）、選択されたサーバ位置で関数を呼び出させ（コンテキストは、関数による状態データの取得を促進する）、選択されたサーバ位置を時間履歴に格納させる。
例４３０２は、例４３０１の少なくとも１つのコンピュータ可読記憶媒体を含み、サーバ位置は、データがストリーミングされるノードとなるように選択される。
ドメイン間呼び出し転送の例
もっとも多くの場合、リモートプロシージャコール（ＲＰＣ）から生じるドメイン間制御転送は、分散されたアプリケーションおよびサービスにおいて頻繁に起こり、その高いコストは、関連するコンテキストスイッチ、スタック間コピー（例えば、スーパバイザ／ハイパーバイザの制御下）、およびセキュア制御転送に起因し得る。ＲＰＣは、クライアント－サーバまたはピアツーピアのインタラクションを構築するための主な機構であった。しかしながら、効率的なＲＰＣ実装は、ＦａａＳ環境において困難であり得る。実際、効率的なドメイン間制御転送の重要性は、他の問題（例えば、より軽い加重の抑制、サービス水準合意／ＳＬＡサポートなどを通じた効率的な隔離）が対処されるにつれて、増大し得る。
ＲＰＣインタラクションの間、コール元は、（ａ）そのユーザ空間からカーネル空間へ移動し得る。そこで、（ｂ）様々な機能の検証後、（ｃ）コールパラメータ／データがマーシャリングされ、（ｄ）適切なトランスポート機構を通じてコール先へメッセージングされる。測定は、サイクルを９０％以上を占める最適化されたｇＲＰＣ（Ｇｏｏｇｌｅ ＲＰＣ）実装における制御プレーンのオーバヘッドを示す。一例において、クラウド固有データプレーン（例えば、ユーザトラフィックを搬送するネットワークの一部）作業、例えば、ＮＦＦ－Ｇｏプロジェクト（例えば、ｇｉｔｈｕｂ．ｃｏｍ／ｉｎｔｅｌ－ｇｏ／ｎｆｆ－ｇｏ）などは、効率的なＲＰＣが、ネットワーク関数仮想化にクリティカルであり得ることを確立した（例えば、数億リクエスト／秒、約１リクエスト／パケットが可能である）。同時に、ＦａａＳパラダイムをデータプレーン処理に適用する試行は、ＯＳ、プラットフォームおよびハードウェアアクセラレーションにアクセスするための統一的機構、ならびに、特定のフレームワークへの依存を回避するための関数－関数チェイニング（例えば、ＡＭＡＺＯＮ ＬＡＭＢＤＡ（登録商標）、ＯＰＥＮＷＨＩＳＫ（登録商標）、ＧＣＰ／ＧＯＯＧＬＥ ＣＬＯＵＤ ＰＬＡＴＦＯＲＭ（登録商標）、ＮＦＦ－Ｇｏ（登録商標）のように、異なるクラウド環境において同一の方式で関数コールを行う）の必要性を明らかにし得る。
上のプロセス（ａ）～（ｄ）に伴うオペレーションは、異なるドメインにわたって実行されるボイラープレートコードシーケンスを含み得、これは、計算を高価にする監視介入を伴う。実際、同様のオーバヘッドがコール先の側および結果のリターンパスに適用する。他のハードウェアフィーチャが、より速くなるにつれて（例えば、連続的なハードウェア技術世代において）、これらのオーバヘッドは、比例して、「パイ」のより大きい部分になる。
近年開発された命令は、上の「マクロ」のハードウェア実装または大量生産型オペレーションを促進し得るが、改善の余地は残る。例えば、制御転送を効率的にすることに着目する基礎的機構が無いことは、より頻繁なコンテキストスイッチ、スタック間コピー、転送セキュリティ、および／または監視介入に関連する、より大きいコストをもたらし得る。以下でより詳細に説明されるように、仮想ハードウェアスレッドおよびユニフォームリソース識別子（ＵＲＩ）コール命令は、ドメイン間制御転送の効率性を増加させるために使用され得る。
ここで図４４Ａを参照すると、第１ドメイン４４０２における呼び出し元４４０４（例えばコール元）が、第２ドメイン４４０６におけるコールを「仮想的に待機する」関数をコールする、ドメイン間環境４４００が示される。一般的に、第２ドメイン４４０６におけるコアは、モニタロジック４４０８（例えば、ロジック命令、構成可能ロジック、機能固定型ハードウェアロジックなど、または、それらの任意の組み合わせ）、および、複数の仮想ハードウェアスレッド（ＶＨＴＲ）、例えば、仮想ハードウェアスレッド４４１０などを含み得る。仮想ハードウェアスレッド４４１０は概して、複数のスレッドの間でコアリソースおよびサイクル、または、仮想ネットワーク関数（ＶＮＦ）を細分化するためにスケジューリングハードウェアによって使用されるスレッドスケジューリング構造であり得る。ソフトウェアおよびオペレーティングシステムの観点から、ＶＨＴＲは通常のＣＰＵコアと同様である。いくつかの実施形態において、ＶＨＴＲは、スレッドにピニングされ、複数の関数に関連付けられ、スケジューリングおよび実行を支援する。いくつかの実施形態において、ハードウェアスケジューラは、ＶＨＴＲ間のＣＰＵスライシングを採用する。例えば、１００以上のＶＨＴＲが、２つの処理コアのＣＰＵサイクルを共有するようにスケジューリングされ得る。従って、十分なストレージがある限り、数千のＶＨＴＲが割り当てられ、スレッドにピニングされ得る。
示された例において、仮想ハードウェアスレッド４４１０は、実行とポーリングが保留される一時停止状態（Ｐ状態）に置かれる。仮想ハードウェアスレッド４４１０がＰ状態で待機している間、プロセッササイクルを受信せず、ポーリングを行わない。呼び出し元４４０４が、モニタリング位置、例えばキュー４４１２、または、コールされる側によってモニタリングされる他の位置などにおいて、コールされた関数の１または複数のコールパラメータを（例えば、ＣＡＬＬＵＲＩ２命令を介して）エンキューするとき、示される呼び出し元４４０４は、（例えば、ＷＡＩＴコマンドを介して）ローカル仮想ハードウェアスレッド４４１８をＰ状態に入れる。加えて、モニタロジック４４０８は、キュー４４１２におけるコールパラメータの存在を検出し得る。キュー４４１２におけるコールパラメータの存在は、予め存在するマイクロアーキテクチャ機能、例えば、ユーザレベル割込み（例えば、ＵＭＯＮＩＴＯＲ／ＵＭＷＡＩＴ）、メモリトリガ（例えば、ＭＯＮＩＴＯＲ／ＭＷＡＩＴ）、マークされたキャッシュラインへのロードまたは格納の、トランザクション同期強化（ＴＳＸ）機構によって生成された指示、停止（ＨＬＴ）命令および軽量割込みサービスルーチン（ＩＳＲ）と組み合わされたプロセッサ間割込み（ＩＰＩ）、後方互換性ポーリングループなど、を通じて検出され得る。
一例において、モニタロジック４４０８は、待機状態にあるコアを選択して、関数のアドレス、コールパラメータへのポインタ、および、結果の将来のリターンに使用され得るリクエストを識別するトークンを渡すことにより選択されたコアの実行をトリガするハードウェアスケジューラの一部である。待機中のコアが存在しない場合、ＨＷスケジューラは、各コア（例えば、ハードウェアキューマネージャ／ＨＱＭ）についてのタスクのキューをサポートする、または、パラメータ転送およびキューをサポートするＵＭＯＮＩＴＯＲ／ＵＭＷＡＩＴの拡張されたセマンティックスを使用し得る（例えば、コアがＰ状態において待機しているかどうかを報告する）。従って、コールパラメータがキュー４４１２にあることに応じて、モニタロジック４４０８は、仮想ハードウェアスレッド４４１０を実行状態（Ｅ状態）に置く。示された例において、仮想ハードウェアスレッド４４１０は、モニタリング位置、例えば、キュー４４１４、または、コールする側によってモニタリングされる他の位置などにおいて、コールされた関数の１または複数の結果をエンキューする。モニタロジック４４１６（例えば、ロジック命令、構成可能ロジック、機能固定型ハードウェアロジックなど、または、それらの任意の組み合わせ）は、キュー４４１４における結果の存在を検出し得る。キュー４４１４における結果の存在は、マイクロアーキテクチャ機能、例えば、ユーザレベル割込み、メモリトリガ、マークされたキャッシュラインへのロードまたは格納の、ＴＳＸ機構によって生成された指示、ＨＬＴ命令および軽量ＩＳＲと組み合わされたＩＰＩ、後方互換性ポーリングループなどを通じて検出され得る。結果がキュー４４１４にあることに応じて、示されるモニタロジック４４１６は、仮想ハードウェアスレッド４４１８を実行状態に置き、その結果、それは、結果を消費し、更なるオペレーションを実行し得る。
ここで図４４Ｂを参照すると、リモートプロシージャコール先を操作する方法４４２０が示される。方法４４２０は概して、例えば、既に説明されたシステム２０２（図２）、システム３００（図３）、および／または、システム４００（図４）などの強化ＦａａＳシステムで実装され得る。実施形態において、方法４４２０は、コールされた側のドメイン、例えば、既に説明された第２ドメイン４４０６（図４４Ａ）などにおいて実装される。より具体的には、方法４４２０は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体において格納されるロジック命令セットとして１または複数のモジュールにおいて実装され得る。
示される処理ブロック４４２２は、実行およびポーリングが保留される一時停止状態に仮想ハードウェアスレッドを置くことを提供する。示された例において、仮想ハードウェアスレッドは、コールされた関数に関連付けられ、コールされた関数はリモートプロシージャである。ブロック４４２４において、コールされた関数の１または複数のコールパラメータがモニタリング位置にあるかどうかの判定が行われ得る。無い場合、示される方法４４２０はブロック４４２４を繰り返す。コールパラメータが検出されたと決定されると、ブロック４４２６は、コールパラメータがモニタリング位置にあることに応じて、仮想ハードウェアスレッドを実行状態に置くことを提供する。
図４４Ｃは、リモートプロシージャコール元を操作する方法４４３０を示す。方法４４３０は概して、例えば、既に説明されたシステム２０２（図２）、システム３００（図３）、および／または、システム４００（図４）などの強化ＦａａＳシステムで実装され得る。実施形態において、方法４４３０は、コールする側のドメイン、例えば、既に説明された第１ドメイン４４０２（図４４Ａ）において実装される。より具体的には、方法４４３０は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体において格納されるロジック命令セットとして１または複数のモジュールにおいて実装され得る。
示される処理ブロック４４３２は、実行およびポーリングが保留される一時停止状態に仮想ハードウェアスレッドを置くことを提供する。示された例において、仮想ハードウェアスレッドは、コールされた関数の呼び出し元に関連付けられ、コールされた関数はリモートプロシージャである。ブロック４４３４において、コールされた関数の１または複数の結果がモニタリング位置にあるかどうかの判定が行われ得る。無い場合、示される方法４４３０はブロック４４３４を繰り返す。結果が検出されたと決定されると、ブロック４４３６は、結果がモニタリング位置にあることに応じて、仮想ハードウェアスレッドを実行状態に置くことを提供する。
追加の留意点および例
例４４０１は、実行可能プログラム命令のセットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、実行およびポーリングが保留される一時停止状態に仮想ハードウェアスレッドを置かせ（仮想ハードウェアスレッドは、コールされた関数に関連付けられ、コールされた関数はリモートプロシージャである）、モニタリング位置において、コールされた関数の１または複数のコールパラメータを検出させ、１または複数のコールパラメータがモニタリング位置にあることに応じて、仮想ハードウェアスレッドを実行状態に置かせる。
例４４０２は、実行可能プログラム命令のセットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、実行およびポーリングが保留される一時停止状態に仮想ハードウェアスレッドを置かせ（仮想ハードウェアスレッドは、コールされた関数の呼び出し元に関連付けられ、コールされた関数はリモートプロシージャである）、モニタリング位置において、コールされた関数の１または複数の結果を検出させ、第２位置にあるという１または複数の結果に応じて、第２仮想ハードウェアスレッドを実行状態に置かせる。
異種データフローの統一の例
図４５Ａは、パケットがネットワーク境界４５０２をトラバースするＦａａＳアーキテクチャ４５００を示し、ネットワークスタックは概して、複数の層（例えば、Ｌ７－アプリケーション層、Ｌ４－トランスポート層、Ｌ３－ネットワーク層、Ｌ２－データリンク層など）を含む。例えば、１または複数のデータリンク（例えば、オープンシステム相互接続／ＯＳＩモデル層Ｌ２）関数４５０８は、ワイドエリアネットワーク（ＷＡＮ）における隣接するネットワークノード間、または、同一ローカルエリアネットワーク（ＬＡＮ）セグメント上のノード間のデータ転送を促進する。加えて、１または複数のネットワーク（例えば、ＯＳＩモデルの層Ｌ３）関数４５１２は、パケット転送を処理し得、１または複数のトランスポート（例えば、ＯＳＩモデルの層Ｌ４）関数４５１４は、ホスト－ホスト通信サービスをアプリケーションに提供する。
一例において、ＡＰＩゲートウェイ４５０６は、様々な関数４５０４（４５０４ａ～４５０４ｄ）、例えば、第１アプリケーション層（例えば、ＯＳＩモデルのＬ７）関数４５０４ａ、第１データプレーン関数４５０４ｂ（例えば、ウェブ関数）、第２データプレーン関数４５０４ｃ（例えば、プロキシ関数）、第２アプリケーション層関数４５０４ｄなどからリモートプロシージャコール（ＲＰＣ）をインターセプトする。ハイパーテキスト転送プロトコル（ＨＴＴＰ）をサポートする示されるＡＰＩゲートウェイ４５０６も、１または複数のインフラストラクチャ関数４５１０からＲＰＣをインターセプトする。高速化ＲＰＣ（Ａ－ＲＰＣ）は呼び出し元４５２０は、インターセプトされたＲＰＣに関連付けられるネットワーク関数のインスタンス化を実行し得る。例えば、ＡＰＩゲートウェイ４５０６は、第１アプリケーション層関数４５０４ａからＲＰＣをインターセプトし得る。インターセプトされたＲＰＣが第２アプリケーション層関数４５０４ｄに関連付けられる場合、呼び出し元は、第２アプリケーション層関数４５０４ｄをインスタンス化する。
特に、ＲＰＣは、ＲＰＣのパケット化の前にインターセプトされ、インスタンス化は、ネットワークスタックのトランスポート層および／またはネットワーク層をバイパスする。従って、示された解決手段は、ネットワークスタック全体を通る必要はない新しいアプリケーションバイナリインタフェース（ＡＢＩ）を提供する。インスタンス化はまた、１または複数の暗号化オペレーション、１または複数の呼び出し元ターゲットハンドシェイクメッセージなどをバイパスし得る。従って、示されるＡＰＩゲートウェイ４５０６、関数４５０４および呼び出し元４５２０は、より効率的なインスタンス化およびルーティングを可能にする、ＦａａＳ関数－関数アクセラレーションロジック４５２２を構成する。
示される関数４５０４および様々なイベントソース４５１６（例えば、状態および構成データベース）は、１または複数の制御プレーン関数４５１８によってサポートされる。加えて、イベントソース４５１６は、コンテキストデータをネットワーク境界４５０２、データリンク関数４５０８、インターネットプロトコル（ＩＰ）ロジック４５２４（例えば、ＩＰｖ４、ＩＰｖ６）、伝送制御プロトコル（ＴＣＰ）ロジック４５２６、ＴＣＰメッセージをＡＰＩゲートウェイ４５０６と交換するセキュアソケット層（ＳＳＬ）ロジック４５２８、ユーザデータグラムプロトコル（ＵＤＰ）ロジック４５３０、および、ドメイン名称サーバ（ＤＮＳ）ロジック４５３２に提供し得る。これらはすべて、示された例において高速化される。示されるアーキテクチャ４５００はまた、アドレス解決プロトコル（ＡＲＰ）ロジック４５３４を含む。一例において、ネットワーク境界４５０２、データリンク関数４５０８、ＩＰロジック４５２４、ＴＣＰロジック４５２６、ＳＳＬロジック４５２８、およびＡＰＩゲートウェイ４５０６は、ＦａａＳ ＡＰＩゲートウェイアクセラレーションロジック４５３６である。
第１アプリケーション層関数４５０４ａおよび第２アプリケーション層関数４５０４ｄは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ （ＲＥＳＴ）、ｇＲＰＣ、Ａ－ＲＰＣなどを介して呼び出し可能である。追加のパス４５３８は、レガシースタイルプロトコル、ＡＰＩゲートウェイ４５０６に到達する前に処理される、例えば、ボーダーゲートウェイプロトコル（ＢＧＰ）などを含むパケットを提供し得る。レガシースタイルプロトコルは、他の関数のいくつかの構成に影響し得る。例えば、いくつかのＩＰ関数によって順番に使用されるルーティングテーブルを更新するためにＢＧＰが使用され得る。従って、示される追加のパス４５３８は、適切である場合、ＡＰＩゲートウェイ４５０６の機能を、わずか数個のプロトコルに限定することを可能にする。実際、追加のパス４５３８は、ＲＥＳＴおよびｇＲＰＣコールを処理し得る。ＡＰＩゲートウェイ４５０６は、Ａ－ＲＰＣコール（低レベルのネットワークスタック無しで、再循環、例えば、Ｆ１→Ｆ２→Ｆ３などを含む）だけを担当する。従って、示されるアーキテクチャ４５００は、完全なＬ２－Ｌ７ネットワークスタックおよびＬ７アプリケーション関数の実装を統合し、ＡＰＩゲートウェイ４５０６をそれ自体でインフラストラクチャ（またはランタイム）関数として公開することにより、様々なショートカットを可能にする。示されるアーキテクチャ４５００はまた、異なる設計のアプリケーションに関連する性能問題（そうでない場合はコールがカーネルネットワークスタックを通過する必要があり得るＮＧＩＮＸなど）を除去する。
図４５Ｂは、ＦａａＳサービスについてのランタイムフレームワークを操作する方法４５４０を示す。方法４５４０は概して、例えば、既に説明されたシステム２０２（図２）、システム３００（図３）、および／または、システム４００（図４）などの強化ＦａａＳシステムで実装され得る。実施形態において、方法４５４０は、例えば、既に説明されたようなＦａａＳアーキテクチャ４５００（図４５Ａ）などのＦａａＳアーキテクチャに実装される。より具体的には、方法４５４０は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体において格納されるロジック命令セットとして１または複数のモジュールにおいて実装され得る。
示される処理ブロック４５４２は、ＲＰＣのパケット化の前に、ネットワークスタックのアプリケーション層で第１ネットワーク関数からＲＰＣをインターセプトすることを提供する。ブロック４５４４では、（例えばアプリケーション層で）ＲＰＣに関連付けられる第２ネットワーク関数のインスタンス化を実行し得る。インスタンス化は、ネットワークスタックのトランスポート層、または、ネットワークスタックのネットワーク層のうち１または複数をバイパスする。一例において、インスタンス化はまた、１または複数の暗号化オペレーションおよび／または１または複数の呼び出し元ターゲットハンドシェイクメッセージをバイパスする。
追加の留意点および例
例４５０１は、実行可能プログラム命令のセットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、リモートプロシージャコールのパケット化の前に、ネットワークスタックのアプリケーション層において、第１ネットワーク関数からリモートプロシージャコールをインターセプトさせ、リモートプロシージャコールに関連付けられる第２ネットワーク関数のインスタンス化を実行させる（インスタンス化は、ネットワークスタックのトランスポート層、または、ネットワークスタックのネットワーク層のうち１または複数をバイパスする）。
例４５０２は、例４５０１のコンピュータ可読記憶媒体を少なくとも１つ含み、インスタンス化は、１または複数の暗号化オペレーション、および、１または複数の呼び出し元ターゲットハンドシェイクメッセージをバイパスする。
レスポンスオブジェクト調整の例
一例において、ＦａａＳアーキテクチャは、標準的データ交換フォーマットを使用して、関数の間でパラメータおよび引数を渡し、そのようなフォーマットにシリアル化される呼び出しリクエスト応答を受信するなどを行う。一般に使用されるフォーマットは、軽量で、読み取りと解析が容易であり得るＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）である。関数の異なる呼び出しインスタンスは、レスポンスオブジェクトの異なるフィールドを使用し得る。ここで、レスポンスオブジェクトは、シリアル化され、ＪＳＯＮオブジェクトの形式で戻され得る。例えば、関数「ｆｕｎｃＧｅｔＩｔｅｍｓ」は、アイテムのリストを戻し得る。その各々は、詳細なフィールドのリストを含む。
ｆｕｎｃＧｅｔＩｔｅｍｓ（）｛
／／例えば、データベースからアイテムを取得する
ｉｔｅｍｓＲｅｔ ＝
ｒｅｔｕｒｎ ｉｔｅｍｓＲｅｔ；
｝
ｆｕｎｃＧｅｔＩｔｅｍｓによって戻されるサンプルＪＳＯＮは応答
｛
"ｉｔｅｍｓ"： ［
｛ "ｉｔｅｍ＿ｉｄ"： "ＣＣＡ"，
"ｅｓｔｉｍａｔｅｄ＿ａｔ"： １４６１６１２０１７，
"ｅｘｐｉｒｅｓ＿ａｔ"： １４６１６１２６１７，
"ｓｔａｒｔ＿ｔｉｍｅ"： １４６１６１８０００，
"ｅｎｄ＿ｔｉｍｅ"： １４６１６２１６００，
"ｆｅｅ"： ４．３４，
"ｃｕｒｒｅｎｃｙ＿ｃｏｄｅ"： "ＵＳＤ"，
"ｒｅａｄｙ＿ｂｙ＿ｔｉｍｅ"： １４６１６１７２６０
｝，
｛ "ｉｔｅｍ＿ｉｄ"： "ＣＶＯＷＦ"，
"ｅｓｔｉｍａｔｅｄ＿ａｔ"： １４６１６１２０１７，
"ｅｘｐｉｒｅｓ＿ａｔ"： １４６１６１２６１７，
"ｓｔａｒｔ＿ｔｉｍｅ"： １４６１６２１６００，
"ｅｎｄ＿ｔｉｍｅ"： １４６１６２５２００，
"ｆｅｅ"： ４．３４，
"ｃｕｒｒｅｎｃｙ＿ｃｏｄｅ"： "ＵＳＤ"，
"ｒｅａｄｙ＿ｂｙ＿ｔｉｍｅ"： １４６１６２０８６０
｝，
｛ "ｉｔｅｍ＿ｉｄ"： "Ｙ２ＵｙＮＤ"，
"ｅｓｔｉｍａｔｅｄ＿ａｔ"： １４６１６１２０１７，
"ｅｘｐｉｒｅｓ＿ａｔ"： １４６１６１２６１７，
"ｓｔａｒｔ＿ｔｉｍｅ"： １４６１６２５２００，
"ｅｎｄ＿ｔｉｍｅ"： １４６１６２８８００，
"ｆｅｅ"： ４．３４，
"ｃｕｒｒｅｎｃｙ＿ｃｏｄｅ"： "ＵＳＤ"，
"ｒｅａｄｙ＿ｂｙ＿ｔｉｍｅ"： １４６１６２４４６０
｝
］
｝
関数「ｆｕｎｃＡ」および「ｆｕｎｃＢ」の各々が「ｆｕｎｃＧｅｔＩｔｅｍ」をコールするが、それらは各々、各アイテムの少しのフィールドだけを使用するシナリオがあり得る。
ｆｕｎｃＡ（） ｛
ｒｅｓｐｏｎｓｅ ＝ ｌａｍｂｄａ．ｉｎｖｏｋｅ（ｆｕｎｃＧｅｔＩｔｅｍｓ）
ａｌｌ ＝ ｒｅｓｐｏｎｓｅ［"ｉｔｅｍｓ"］
ｆｏｒ ｉｔｅｍ ｉｎ ａｌｌ：
ｐｒｏｃｅｓｓ（ｉｔｅｍ［"ｉｔｅｍ＿ｉｄ"］， ｉｔｅｍ［"ｆｅｅ"］）
｝
ｆｕｎｃＢ（） ｛
ｒｅｓｐｏｎｓｅ ＝ ｌａｍｂｄａ．ｉｎｖｏｋｅ（ｆｕｎｃＧｅｔＩｔｅｍｓ）
ａｌｌ ＝ ｒｅｓｐｏｎｓｅ［"ｉｔｅｍｓ"］
ｆｏｒ ｉｔｅｍ ｉｎ ａｌｌ：
ｐｒｏｃｅｓｓ（ｉｔｅｍ［"ｉｔｅｍ＿ｉｄ"］， ｉｔｅｍ［"ｓｔａｒｔ＿ｔｉｍｅ"］）
｝
本明細書において説明される技術は、シリアル化された応答（またはパラメータ）オブジェクトを、各コール元の要件／署名に基づいて調整されるように調整する。例えば、「ｆｕｎｃＢ」に戻される応答は、必要／適切なデータフィールドだけを含む以下のＪＳＯＮオブジェクトに圧縮され得る。
｛
"ｉｔｅｍｓ"： ［
｛ "ｉｔｅｍ＿ｉｄ"： "ＣＣＡ"，
"ｓｔａｒｔ＿ｔｉｍｅ"： １４６１６１８０００，
｝，
｛ "ｉｔｅｍ＿ｉｄ"： "ＣＶＯＷＦ"，
"ｓｔａｒｔ＿ｔｉｍｅ"： １４６１６２１６００，
｝，
｛ "ｉｔｅｍ＿ｉｄ"： "Ｙ２ＵｙＮＤ"，
"ｓｔａｒｔ＿ｔｉｍｅ"： １４６１６２５２００，
｝
］
｝
例えば、図４６Ａは、関数４６００がデータフィールド４６０２のセットを戻し得ることを示す（例えば、「ｉｔｅｍ＿ｉｄ」から「ｒｅａｄｙ＿ｂｙ＿ｔｉｍｅ」）。関数４６００の第１呼び出しインスタンス４６０４による第１コール（例えば、「ｆｕｎｃＡ」のラムダ／アノニマスの呼び出し元）が検出された場合、フィールドのセット４６０２の第１サブセット４６０６（例えば、「ｉｔｅｍ＿ｉｄ」および「ｆｅｅ」だけ）が識別され得、第１サブセット４６０６は第１呼び出しインスタンス４６０４に関連する。更に、第１レスポンスオブジェクト４６１２（例えば、ＪＳＯＮオブジェクト）の第１再レイアウト（例えば、再構成、再整列）は、第１サブセット４６０６に基づいて実行され得る。より詳細に説明されるように、第１再レイアウトは、第１サブセット４６０６だけを含むように第１レスポンスオブジェクト４６１２をフィルタリングし、フィールドのセット４６０２における残りのフィールドの前に第１サブセット４６０６をリストするように第１レスポンスオブジェクト４６１２を再整列するなどのことを行い得る。
同様に、関数４６００の第２呼び出しインスタンス４６０８による第２コール（例えば、「ｆｕｎｃＢ」ラムダ／アノニマスの呼び出し元）が検出された場合、フィールドのセット４６０２の第２サブセット４６１０（例えば、「ｉｔｅｍ＿ｉｄ」および「ｓｔａｒｔ＿ｔｉｍｅ」だけ）が識別され得、第２サブセット４６１０は第２呼び出しインスタンス４６０８に関連する。更に第２レスポンスオブジェクト４６１４（例えばＪＳＯＮオブジェクト）の第２再レイアウトは、第２サブセット４６１０に基づいて実行され得る。再び、第２再レイアウトは、第２サブセット４６１０だけを含めるように第２レスポンスオブジェクト４６１２をフィルタリングし、フィールドのセット４６０２における残りのフィールドの前に第２サブセット４６０６をリストするように第２レスポンスオブジェクト４６１４を再整列するなどのことを行い得る。強化ＦａａＳシステムによって提供される、示された解決手段は、従って、レスポンスオブジェクト４６１２、４６１４を圧縮し、より効率的なネットワーキング／帯域幅利用、より低い処理オーバヘッド、強化された性能、最小化された管理、および、より大きいスケーラビリティを可能にする。
一実施形態において、圧縮機構は、応答が送り返される前に、各コール元アノニマス関数（例えば、関数リテラル、ラムダ抽象化、ラムダ式）についての関連フィールドの集合として実装され得る。一例において、関連データフィールドのラベル／オフセットが各コール元について登録され、コール先ラムダの近くのソフトウェア／ハードウェア構造に更にキャッシュされ得る。例えば、生の結果に適用されるフィルタを取得するために、ルックアップテーブルが、コール元ＩＤ／ＩＰ／アドレスによってインデックス化され得る。フィルタは、上の例と同様の、関心のあるいくつかのフィールドを選択し得る。加えて、フィルタはまた、関心のあるフィールドを最初にリストして／持ってきて、残りのフィールド／データを後に置くように、応答／ＪＳＯＮオブジェクトを再フォーマットできる。説明を促進するために、本明細書においてＪＳＯＮ圧縮が使用されるが、例えばｇＲＰＣバイナリ符号化など、メッセージパラメータの他の符号化も使用され得る。
一例において、フィルタコード（例えば、方法スタブ、ラムダ）は、コール元実装の一部として提供される（例えば、署名、方法スタブ）。フィルタコードはまた、コンパイラ／ランタイムツールによって取得され得る。実施形態において、送り返す前に生の結果をフィルタリングすることは、戻り命令を実行する前に、ジャンプテーブルを介して実装される（例えば、各コール元に調整される圧縮／再レイアウトを実行するコードへの間接ジャンプ）。間接ジャンプのターゲットをキャッシュする（例えば、トランスレーションルックアサイドバッファ／ＴＬＢキャッシュと同様）、または、間接ジャンプのターゲットを予測するために、更なる命令セットアーキテクチャ（ＩＳＡ）およびハードウェアサポート（例えば、分岐ターゲットバッファ／ＢＴＢと同様）が展開され得る。
ここで図４６Ｂを参照すると、呼び出しインスタンスにレスポンスオブジェクトを調整する方法４６２０が示される。方法４６２０は概して、例えば、既に説明されたシステム２０２（図２）、システム３００（図３）、および／または、システム４００（図４）などの強化ＦａａＳシステムで実装され得る。より具体的には、方法４６２０は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体において格納されるロジック命令セットとして１または複数のモジュールにおいて実装され得る。
示される処理ブロック４６２２は、フィールドのセットを戻す関数の第１呼び出しインスタンスによる第１コールを検出する。ブロック４６２４において、フィールドのセットの第１サブセットが識別され得る。第１サブセットは第１呼び出しインスタンスに関連する。加えて、ブロック４６２６は、第１サブセットに基づいて、第１レスポンスオブジェクトの第１再レイアウトを実行する。一例において、ブロック４６２６は、第１サブセットだけを含むように第１レスポンスオブジェクトをフィルタリングすることを含む。ブロック４６２６はまた、フィールドのセットにおける残りのフィールドの前に第１サブセットをリストするように第１レスポンスオブジェクトを再整列することを含み得る。他の再レイアウト技術も使用され得る。
一例において、ブロック４６２８において、関数の第２呼び出しインスタンスによる第２コールが検出される。ブロック４６３０において、データフィールドのセットの第２サブセットが識別され、第２サブセットは第２呼び出しインスタンスに関連する。示されるブロック４６３２は、第２サブセットに基づいて第２レスポンスオブジェクトの第２再レイアウトを実行し、第２再レイアウトは第１再レイアウトと異なる。ブロック４６３２は、第２サブセットだけを含むように第２レスポンスオブジェクトをフィルタリングすること、フィールドのセットにおける残りのフィールドの前に第２サブセットをリストするように第２レスポンスオブジェクトを再整列することなどを含み得る。従って、示される方法４６２０は、レスポンスオブジェクトを圧縮し、より効率的なネットワーキング／帯域幅利用、より少ない処理オーバヘッド、強化された性能、最小化された管理、および、より大きいスケーラビリティを可能にする。
追加の留意点および例
例４６０１は、実行可能プログラム命令のセットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、フィールドのセットを戻す関数の第１呼び出しインスタンスによる第１コールを検出させ、フィールドのセットの第１サブセットを識別させ（第１サブセットは第１呼び出しインスタンスに関連する）、第１サブセットに基づいて第１レスポンスオブジェクトの第１再レイアウトを実行させる。
例４６０２は、例４６０１の少なくとも１つのコンピュータ可読記憶媒体を含み、第１再レイアウトは、第１サブセットだけを含むように第１レスポンスオブジェクトをフィルタする。
例４６０３は、例４６０１の少なくとも１つのコンピュータ可読記憶媒体を含み、第１再レイアウトは、フィールドのセットにおける残りのフィールドの前に第１サブセットをリストするように第１レスポンスオブジェクトを再整列する。
例４６０４は、例４６０１の少なくとも１つのコンピュータ可読記憶媒体を含み、命令は実行されるとき、コンピューティングデバイスに、関数の第２呼び出しインスタンスによる第２コールを検出させ、フィールドのセットの第２サブセットを識別させ（第２サブセットは、第２呼び出しインスタンスに関連する）、第２サブセットに基づいて、第２レスポンスオブジェクトの第２再レイアウトを実行させる（第２再レイアウトは第１再レイアウトと異なる）。
パラメータマーシャリングの例
パラメータマーシャリングは、他のソフトウェアアプリケーションへの格納または送信に適した別のフォーマットへ、オブジェクトのメモリ表現を変換することを伴う。従って、マーシャリングは、オブジェクトをシリアル化形式に変換することによって、リモートオブジェクト間の通信を促進する。ＦａａＳフレームワークにおけるＲＰＣについてのパラメータのマーシャリングは、転送されるデータの大きい量に起因して、ボトルネックの課題に直面し得る。テキスト符号化（例えば、ＪＳＯＮの場合、ＲＥＳＴ）またはバイナリ符号化（例えば、ＧＲＰＳ， ＦＬＡＴＢＵＦＦＥＲＳ， ＡＰＡＣＨＥ ＴＨＲＩＦＴ）は、関数パラメータを渡すために使用され、ボトルネックの課題は続き得る。なぜなら、「ワイヤ」上のデータは、メモリ内のデータと異なり、永久的なシリアル化／脱シリアル化があるからである。
図４７Ａは、コンパイラ４７００が関数についてのペイロード４７０２（例えば、「実行準備」データアレイ）を決定し、コンパイル時に、ペイロード４７０２をコールスタック４７０４上に配置するシナリオを示す。より詳細に説明されるように、関数は、１または複数のローカルインスタンス４７０６（すなわち、ローカルプラットフォーム上で）、または、１または複数のリモートインスタンス４７０８（例えば、リモートプラットフォーム上で）のいずれかとして、ペイロード４７０２を介して等しく呼び出し可能である。関数がリモートプラットフォーム上で呼び出されることがランタイムに決定される場合（例えば、コンパイル時に分かっていない様々な条件に基づいて）、示されるペイロード４７０２は、リモートプラットフォーム上のコールスタック４７１０へトランスポートされ、ここでは、それは、インスタンス４７０８を呼び出すために、汎用ＲＰＣハンドラによって使用される。一例において、ペイロード４７０２は、１または複数のパラメータ値、ペイロード４７０２のサイズ、および、関数の識別子を含む。従って、示された解決手段は、関数パラメータの非効率なマーシャリングに関連するボトルネックを除去する。従って、強化された性能、最小管理、および、より大きいスケーラビリティが実現され得る。
より具体的には、「送信準備」フォーマットは、関数コールについてのＡＢＩ（アプリケーションバイナリインタフェース）の一部として使用され得る。ここでは、コールのスタブ側部分についてのスタック４７０４が、ＲＰＣトランスポート機構を使用して送信するために、または、ハードウェアに渡すために必要な詳細のすべてを含む。従って、スタック４７０４では、実行準備データアレイとしてペイロード４７０２が配置され、ターゲットの呼び出しの準備が整えられる。従って、ターゲットがリモートであり、非共有メモリトランスポート機構を介して呼び出される必要がある場合、ローカルプラットフォームのスタック４７０４上に既に組み立てられたペイロード４７０２と共に直接呼び出される。
リモートプラットフォーム（例えば、受信側／ターゲット側）上で、逆のステップは同様に、呼び出しのためにスタック４７１０をセットアップする（例えば、プロトコル処理を畳む、および、単一オペレーションへデータを解凍する）。従って、ターゲットが、ワイヤによってペイロードをトランスポートすることなく呼び出されることができるリモートプロシージャである場合、スタック４７０４は共有メモリにおいて構築されることができ、ローカル関数コールのマッチングでも、ＲＰＣは、非常に軽量であることができる。すべての引数が、リモートコールをディスパッチするために使用されるスタック４７０４と共に共有メモリ内にある。
この原理は、意図的に単純にした例を用いて下に示される。ここでは、マーシャリングは、パラメータ値（例えば、引数）をスタックフレームに単純にコピーすることを伴う。コアの原理は、より複雑な引数の場合でも、同一のままである。
ランタイムにおいて、構成に応じて、例えば、ｔｅｓｔ（ｉｎｔ ａ， ｓｈｏｒｔ ｂ）などの関数は、ローカルコール、または、リモートネットワークホスト上のリモートコールのいずれかとしてディスパッチされ得る。この決定は、コンパイル時には分かっていない様々な条件を基礎とし得る。そのような場合、従来のランタイムは、以下のように、（２重のフォワードスラッシュ「／／」に続くコードアノテーションを有する）そのようなコールを実行し得る。
ｉｆ （＿＿ｌｏｃａｌ＿ｃａｌｌ＿ｔｏ＿ｔｅｓｔ（）） ｛
ｔｅｓｔ（ａ， ｂ）； コンパイラは以下のようにスタックまたはレジスタにａおよびｂを配置するコードを生成する
／／ ｓｔａｃｋ．ａ＝ａ；
／／ ｓｔａｃｋ．ｂ＝ｂ；
／／ ｃａｌｌ ｔｅｓｔ
｝ ／／通常のＡＢＩを使用し、ａおよびｂは、スタックおよび／またはレジスタ上にある
ｅｌｓｅ ｛ ／／ｔｅｓｔ（ａ， ｂ）についてのクライアント側スタブ
／／送信するためのメッセージの構築
ｓｔｒｕｃｔ ｍ＿ｔｅｓｔ ｍ ＝ ｍａｌｌｏｃ （ｓｉｚｅｏｆ （ｓｔｒｕｃｔ ｍ＿ｔｅｓｔ）） ；
ｍ－＞ａ ＝ ａ；
ｍ－＞ｂ ＝ ｂ；
ｍ－＞ｈｅａｄｅｒ ＝ ... ｘｘｘ ...；
／／トランスポートを介して呼び出しを実行する
＿ＲＰＣ＿ＣＡＬＬ＿（"ｔｅｓｔ"， ｍ）；
／／ターゲットホストは上記のステップを逆転させ、次に、ターゲットにおいてｔｅｓｔ（ａ， ｂ）を呼び出す。
｝
対照的に、本明細書において説明される技術は、コンパイラ４７００を介して以下の統一および単純化を実行する。コンパイラ４７００は、ｔｅｓｔ（ａ， ｂ）へのコールを生成する。
ｓｔａｃｋ．ｈｅａｄｅｒ ＝ ｔｅｓｔ＿ｓｐｅｃｉｆｉｃ＿ｈｅａｄｅｒ；／／「ｔｅｓｔ」関数の識別
／／この関数についてのｖｔａｂｌｅにおけるインデックスであり得る３２または６４ビットＩＤなど
ｓｔａｃｋ．ａ＝ａ；
ｓｔａｃｋ．ｂ＝ｂ；
ｓｔａｃｋ．ｅｐｉｌｏｇｕｅ＝ｔｅｓｔ＿ｓｐｅｃｉｆｉｃ＿ｅｐｉｌｏｇｕｅ； ／／フレームのサイズを含み、加えて別のものであり得る。
／／フレーム／ペイロードのサイズは汎用ＲＰＣ実装を可能にする
ｃａｌｌ ［ｔｅｓｔ］； ／／ｖｔａｂｌｅ（仮想メソッドテーブル）を使用する間接コール
更に、コールがリモートプロセス間通信（ＩＰＣ）コールである場合、汎用ＲＰＣハンドラが以下を実行し得る。
＃ｄｅｆｉｎｅ ＿ＳＥＳ ｓｉｚｅｏｆ （ｓｔａｃｋ．ｅｐｉｌｏｇｕｅ）／／関数へのコールを行う
／／ペイロードとしてスタック内容を使用するヘッダ、およびペイロードのサイズにおいて定義される
ｓｅｎｄ（ｓｔａｃｋ．ｈｅａｄｅｒ．ｉｄ，＆ｓｔａｃｋ－＿ＳＥＳ＿，＿ＳＥＳ＿）；
ＳＥＳはスタックエピローグサイズを参照する（例えば、コードの明確性のために使用されるマクロ置換）。既に説明されたように、ペイロードは、コールされた関数、ペイロードのサイズ、および、パラメータの値の識別を含み得る（例えば、そうでない場合はクロスドメインコールを防止する任意のポインタ／参照を回避する）。
図４７Ｂは、高レベルアーキテクチャ４７１２を示す。ここでは、ローカルコールがローカルシステム上で実行するのと同一の方式でリモートコールがスタック上でディスパッチのために配置される。
ここで図４７Ｃを参照すると、関数パラメータをマーシャリングする方法４７２０が示される。方法４７２０は概して、例えば、既に説明されたシステム２０２（図２）、システム３００（図３）、および／または、システム４００（図４）などの強化ＦａａＳシステムで実装され得る。より具体的には、方法４６２０は、例えば、ＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を用いる固定機能ロジックハードウェア、または、これらの任意の組み合わせにおいて、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの機械またはコンピュータ可読記憶媒体において格納されるロジック命令セットとして１または複数のモジュールにおいて実装され得る。
示される処理ブロック４７２２は、関数についてのペイロードを決定することを提供する。一例において、ペイロードは、１または複数のパラメータ値、ペイロードのサイズ、および、関数の識別子を含む。ブロック４７２４は、コンパイル時に、ペイロードをコールスタックに配置し、ここで、関数は、ローカルインスタンスまたはリモートインスタンスのいずれかとして、ペイロードを介して等しく呼び出し可能である。加えて、ブロック４７２６は、ランタイムにおいて、ローカルインスタンスとして関数を呼び出すか、または、ペイロードをリモートプラットフォームへトランスポートするかを決定し得る。従って、示される方法４７２０は、関数パラメータの非効率なマーシャリングに関連するボトルネックを除去する。従って、強化された性能、最小管理、および、より大きいスケーラビリティが実現され得る。
従って、より効率的なデータマーシャリングは、選択的ビット順序（ＭＳＢ／ＬＳＢ）およびタイプのトランスコードを用いるデータ構造の分散／収集を伴い得る。特に選択的ビット順序に関して、いくつかの実装において（例えば、異種アーキテクチャ間、すなわち、ＩＮＴＥＬ＜――＞ＭＩＰＳまたはＡＲＭでコールが実行されるとき、マルチバイトタイプ（例えば、３２ビット整数または浮動小数点）でバイトの順序を指定することが重要であり得る。例えば、３２ビット整数０ｘ１２３４５６７８は、ＬＳＢ（最下位バイト／ビットが最初）の場合、０ｘ７８、０ｘ５６、０ｘ３４、０ｘ１２、または、ＭＳＢ（最上位バイト／ビットが最初）の場合、０ｘ１２、０ｘ３４、０ｘ５６、０ｘ７８のバイトのシーケンスとして符号化されることができる。従って、受信側は、ロードの順序を反転させる必要があり得る。これは、多くのアーキテクチャ上で特別な命令を用いて実行される。この技術はまた、ＣＰＵベースパラメータ渡しと、リモート呼び出し、または、アクセラレータオフロードによって処理される呼び出しのいずれかとの間で変換するために、関数ハブを使用し得る。従って、作業が発生するターゲットは、コール元からは、厳密にプロセスローカルコールのように見える。
追加の留意点および例
例４７０１は、実行可能プログラム命令のセットを含む少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングデバイスによって実行されるとき、コンピューティングデバイスに、関数についてのペイロードを決定させ、コンパイル時に、コールするのに十分な情報を含むフォーマットのコールスタック上にペイロードを構築するコードを配置させる（ここで、関数は、ペイロードを介して、ローカルインスタンス、リモートインスタンスまたはハードウェアとして等しく呼び出し可能である）。
例４７０２は、例４７０１の少なくとも１つのコンピュータ可読記憶媒体を含み、ペイロードは、１または複数のパラメータ値、ペイロードのサイズ、および、関数の識別子を含む。
例４７０３は、例４７０１の少なくとも１つのコンピュータ可読記憶媒体を含み、命令は実行されるとき、コンピューティングデバイスに、ランタイムに、ローカルインスタンスとして関数を呼び出すか、または、ペイロードをリモートプラットフォームへトランスポートするかを決定させる。
機能転送の例
ＦａａＳシステムのオペレーション中、関数（例えばソース関数）の機能は多くの場合、別の関数（例えば、デスティネーション関数）に渡される。これは、ローカル（例えば、ソース関数とメモリ領域を共有する）でも、または、リモート（例えば、デスティネーション関数とメモリ領域を共有しない）でもよい。関数の権限が比較的低い（例えば、権限Ｒｉｎｇ３）場合、関数の間で渡されている機能が正式であることを保証するためのセキュリティ手段が適切である。より詳細に説明されるように、図４に示されるものなど、強化ＦａａＳシステムによって採用される強化技術は、複雑なソフトウェアアーキテクチャにおいて関数機能を生成するための、信頼されるソフトウェアランタイムの展開、または挿入の任意の必要性を除去するために使用される。更に、この技術は、ＨＴＴＰメッセージの転送、および、共有メモリ設定へのデータのコピーに関連するオーバヘッドを除去する。
図４８Ａは、第１関数４８００（ソース関数「ｆ３」）が、第２関数４８０６（デスティネーション関数「ｆ４」）のコール／呼び出しと連携して、機能情報４８０２を信頼済みキューマネージャ４８０４へ送信するシナリオを示す。示された例において、信頼済みキューマネージャ４８０４は、第１認証フォーマット４８０８に関連して、機能情報４８０２が有効である（例えば信頼できる）かどうかを判定する。ここで、機能情報４８０２および第１認証フォーマット４８０８は、第１関数４８００に対応する。実施形態において、第１認証フォーマット４８０８は、第１関数４８００によって認識され、機能情報４８０２が有効かどうかを判定するために第１関数４８０２に割り当てられた第１キー（図示せず）を使用する信頼済みキューマネージャ４８０４を伴う。より具体的には、信頼済みキューマネージャ４８０４は、第１キーを、機能情報４８０２に組み込まれたメッセージ認証コード（ＭＡＣ）と比較し得る。代替的に、機能情報４８０２は、機能情報４８０２の破損が、予測可能で使用可能な機能を敵対者に提供しないような方式で暗号化され得る。
信頼済みキューマネージャ４８０４が、第１認証フォーマット４８０８に関連して、機能情報４８０２は有効であると判定する場合、信頼済みキューマネージャ４８０４は、機能情報を信頼済みキュー（図示せず）に格納する（例えばエンキューする）。また、示される信頼済みキューマネージャ４８０４は、第２関数４８０６に対応する第２認証フォーマット４８１０に従って、機能情報４８０３を生成し、第２関数４８０６へ送信する。実施形態において、第２認証フォーマット４８１０は第２関数４８０６によって認識され、第２関数４８０６に割り当てられた第２キー（図示せず）を用いて機能情報４８０３を認証することを伴う。実施形態において、認証は、第２キーを使用してＭＡＣを再計算すること、および、機能情報４８０３に組み込まれたＭＡＣと結果を比較することを含む。従って、第１認証フォーマット４８０８は通常、第２認証フォーマット４８１０と異なる。
信頼済みキューマネージャ４８０４をハードウェアキューマネージャ（ＨＱＭ）として実装することは、信頼済みソフトウェアランタイムが、複雑なソフトウェアアーキテクチャにおいて機能情報４８０２、４８０３を生成する任意の必要性を除去する。更に、信頼済みキューマネージャ４８０４は、メッセージの転送（例えば、ＨＴＴＰフォーマット、または、ｆ３からｆ４へ転送され得る任意の他のフォーマット）、および、共有メモリ設定へのデータのコピーに関連するオーバヘッドを除去する。関数４８００、４８０６は、ロードバランサが関数４８００、４８０６をＦａａＳシステム中で動的に移動させるという点で、（例えばポータブルアイデンティティを有する）ポータブル関数であり得る。
図４８Ｂは、既に説明されたように、機能情報４８０２、４８０３（図４８Ａ）を容易に置換し得る符号化インライン機能（ＥＩＣ）情報４８１２（４８１２ａ－４８１２ｃ）を示す。示された例において、ＥＩＣ情報４８１２は、ＭＡＣ４８１２ａ、境界情報４８１２ｂおよびポインタ４８１２ｃを含む。一例において、ＭＡＣ４８１２ａは、境界情報４８１２ｂに基づいて有鍵一方向ハッシュ関数によって作成されるタグである。ここで、ＭＡＣ４８１２ａを形成するために使用される秘密鍵は、保護領域（例えば、ホストプロセッサ上）に配置される。従って、ＭＡＣ４８１２ａは、ＥＩＣ情報４８１２が、上記送信側から来て、変更されていないことを確認するために使用される。従って、示されるＭＡＣ４８１２ａは、同じく秘密鍵を保持する検証側が、ＥＩＣ情報４８１２の任意の変化を検出することを可能にすることによって、ＥＩＣ情報４８１２の完全性および信頼性の両方を保護する。一例において、ポインタ４８１２ｃは、境界情報４８１２ｂによって定義されるメモリ領域を参照する。従って、メモリアクセスが関数によって試みられる場合、アクセスにおいて使用されるポインタが正当であり、境界情報４８１２ｂによって定義されるメモリ領域内にあることを確実にするために、ＭＡＣ４８１２ａがチェックされる。
実施形態において、ＥＩＣ情報４８１２は、階層符号化インライン機能を含む。例えば、複合ＥＩＣは、マルチレベル階層における仮想（例えばマルチキャスト）チャネルに対応するＥＩＣのサブグループを含み得る。加えて、ＥＩＣ情報４８１２は、機能としてユーザレベル割込み（ＵＬＩ）を含み得る。プロセスアドレス空間識別子（ＰＡＳＩＤ）は、ＥＩＣ情報４８１２と共にエンキューされ得る。
図４８Ｃは、既に説明されたように、信頼済みキューマネージャ４８０４（図４８Ａ）を容易に置換し得るハードウェアキューマネージャ４８１４を示す。示された例において、ハードウェアキューマネージャ４８１４は、キュー４８１６のセットを維持する。ここで、各キュー４８１６は、特定の関数または関数のセットについての機能情報を保持する。従って、示された解決手段は、エンキューされた機能のハードウェア管理を使用して仮想チャネルを実施する。システムレベル権限を有する（例えば、Ｒｉｎｇ３より権限が高い）ハードウェアキューマネージャ４８１４はまた、（例えば、別のプラットフォーム／機械におけるエッジ間で）キー情報４８１８をリモートハードウェアキューマネージャ４８２０と交換し得る。実施形態において、ハードウェアキューマネージャ４８１４はまた、例えば、機能を認証するために使用されるキー、各関数についてプライベートデータ領域の境界を示す範囲レジスタなど、他のコンテキスト情報を更新する責任を担う。従って、ハードウェアキューマネージャ４８１４は、Ｒｉｎｇ３にあり、信頼済みソフトウェアランタイムとして機能して関数機能を生成する従来のルート保護ドメイン（ＰＤ）４８１５の効率性な改善を表す。一例において、ハードウェアキューマネージャ４８１４は、異なる関数の呼び出しに起因してコンテキストスイッチが発生しそうなときを検出するホストプロセッサ（例えばＣＰＵ）に配置される。
図４８Ｄは、ハードウェアキューマネージャを操作する方法４８２２を示す。方法４８２２は概して、例えば、既に説明された信頼済みキューマネージャ４８０４（図４８Ａ）および／またはハードウェアキューマネージャ４８１４（図４８Ｃ）などのキューマネージャによって実装され得る。より具体的には、方法４８２２はＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの非一時的機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を使用する機能固定型ハードウェアロジック、または、それらの任意の組み合わせに格納されるロジック命令セットにおいて１または複数のモジュールとして実装され得る。
示される処理ブロック４８２４は、第１認証フォーマットに関して、機能情報が有効／信頼できるかどうかを判定する。ここで、機能情報および第１認証フォーマットは第１関数に対応する。一例において、ブロック４８２４は、第１関数に関連する第１キーを使用して、機能情報が有効かどうかを判定する。有効である場合、ブロック４８２６は、機能情報を信頼済みキューに格納（例えばエンキュー）する。一例において、機能情報は、階層符号化インライン機能を含む。
ブロック４８２８において、機能情報は、第２関数に対応する第２認証フォーマットに従って、第２関数へ転送される。実施形態において、第２認証フォーマットは、第２関数への送信中に機能情報を保護および認証するために第２関数に関連する第２キーの使用を指定する。例において、第１関数および第２関数はポータブル関数である。従って、示される方法４８２２は、信頼済みソフトウェアランタイムが、複雑なソフトウェアアーキテクチャにおいて関数機能を生成する任意の必要性を除去する。更に、この技術は、メッセージの転送、および、共有メモリ設定へのデータのコピーに関連するオーバヘッドを除去する。
図４８Ｅは、一実施形態による機能をエンキューする方法４８３０を示す。方法４８３０は概して、例えば、既に説明された信頼済みキューマネージャ４８０４（図４８Ａ）および／またはハードウェアキューマネージャ４８１４（図４８Ｃ）などのキューマネージャによって実装され得る。より具体的には、方法４８３０は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの非一時的機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を使用する機能固定型ハードウェアロジック、または、それらの任意の組み合わせに格納されるロジック命令セットにおいて１または複数のモジュールとして実装され得る。
示される処理ブロック４８３２は、送信される機能、および、意図されるデスティネーションを指定する新しい命令（例えばＥＮＱＣＡＰ）を使用して、機能をエンキューする１または複数のサービスリクエストを検出する。例えば、デスティネーションは、グローバルまたはローカル一意サービスＩＤとして指定されることができる。示されるブロック４８３４において、ＥＮＱＣＡＰは、現在の機能認証キーを使用して、提供される機能を認証する。認証に成功した場合、ＥＮＱＣＡＰブロック４８３６は、機能から境界およびポインタ情報を抽出する。ＥＮＱＣＡＰブロック４８３８は次に、抽出された情報についての適切なデスティネーションキューを識別する。例えば、このプロシージャは、サービスをホスティングするために割り当てられたプロセッサのＩＤへサービスＩＤを変換することを伴い得る。各サービスは、１または複数プロセッサにロックされ得る、または、システム中の任意のプロセッサ上でサービスを呼び出すことが可能になり得る。異なるシステム中のプロセッサ上で自動的にサービスを呼び出すことも可能であり得る。そのような呼び出しは、機能によって参照されるデータをデスティネーションシステムへコピーすることを必要とする。また、サービスについてのコードをデスティネーションシステムへコピーすることが必要であり得る。
デスティネーションシステムと通信するためのネットワークプロトコルが必要であり得る。例えば、オペレーティングシステムは、異なるシステム上のハードウェアキューマネージャインスタンス間で接続を確立することを担い得る。ハードウェアキューマネージャは次に、互いに通信し得る。示されるブロック４８４０は、デスティネーションサービスＩＤと共に、ポインタおよび境界情報をデスティネーションキューにエンキューする。サービス実行は次に、ブロック４８４２に継続し得る。ブロック４８３４において、提供される機能が信頼できないと判定された場合、示されるブロック４８４４において例外が生成される。
図４８Ｆは、一実施形態による、機能をデキューする方法４８３１を示す。方法４８３１は概して、例えば、既に説明された信頼済みキューマネージャ４８０４（図４８Ａ）および／またはハードウェアキューマネージャ４８１４（図４８Ｃ）などのキューマネージャによって実装され得る。より具体的には、方法４８３１は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの非一時的機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を使用する機能固定型ハードウェアロジック、または、それらの任意の組み合わせに格納されるロジック命令セットにおいて１または複数のモジュールとして実装され得る。
示される処理ブロック４８３３は、ポインタおよび境界情報、ならびに、デスティネーションサービスＩＤをデキューするリクエストを検出する。ブロック４８３５において、デスティネーションサービスが現在ロードされているかどうかが判定され得る。ロードされていない場合、ブロック４８３７で、デスティネーションサービスについてのコードおよびデータをロードし、プライベートデータ領域を割り当てる。加えて、ブロック４８３９において、プライベートデータ領域境界レジスタは、初期化され、デスティネーションサービスについてのプライベートデータ領域をカバーする。実施形態において、ブロック４８４１では、ランダム生成データを用いて、機能認証キーレジスタを初期化する。示されるブロック４８４３は、デキューされたポインタおよび境界情報を表す符号化インライン機能を生成し、生成されたＥＩＣをレジスタに格納する。その結果、デスティネーションサービスはそれにアクセスできる。ブロック４８４５では、制御をデスティネーションサービスへ転送する。ブロック４８３５において、デスティネーションサービスが現在ロードされていると判定された場合、方法４８３１はブロック４８３７をバイパスし得る。
追加の留意点および例
例４８０１は、１または複数の基板と、１または複数の基板に連結されたロジックとを備える半導体装置を含み、ロジックは、構成可能ロジックまたは機能固定型ハードウェアロジックに少なくとも部分的に実装され、１または複数の基板に連結されるロジックは、第１認証フォーマットに関して、機能情報が有効かどうかを判定し、機能情報および第１認証フォーマットは、第１関数に対応し、第１認証フォーマットに関して機能情報が有効である場合、機能情報をキューに格納し、第２関数に対応する第２認証フォーマットに従って、機能情報を第２関数へ転送し、ここで、第１関数および第２関数はポータブル関数であり、機能情報は、階層符号化インライン機能およびユーザレベル割込みを含む。
例４８０２は、１または複数の基板と、１または複数の基板に連結されるロジックとを備える半導体装置を含み、ロジックは、構成可能ロジックまたは機能固定型ハードウェアロジックにおいて少なくとも部分的に実装され、１または複数の基板に連結されるロジックは、実行される関数に関連する、デキューアポインタおよび境界情報、ならびに、デスティネーションサービスＩＤを決定し、現在ロードされていないデスティネーションサービスに応じて、識別されたデスティネーションサービスについての関数に関連するコードおよびデータをロードし、関数を実行するためのプライベートデータ領域を割り当て、識別されたデスティネーションサービスへ制御を転送し、ここで、関数を実行するためのプライベートデータ領域を割り当てることは、デスティネーションサービスについてのプライベートデータ領域をカバーするために１または複数のプライベートデータ領域境界レジスタを初期化すること、ランダムに生成されたデータで機能認証キーレジスタを初期化すること、デキューされたポインタおよび境界情報を表す符号化インライン機能を生成すること、および、符号化インライン機能を、デスティネーションサービスによってアクセス可能なレジスタに格納することを含む。
アドレス空間内コンパートメント化の例
マルチキートータルメモリ暗号化（ＭＫ－ＴＭＥ）は、異なる暗号鍵を用いて各関数に割り当てられたメモリ領域を暗号化することによって互いから関数を隔離／コンパートメント化するために使用することができる。そのようなアプローチは、別個のページテーブルを有する線形アドレス空間を分離するために関数を割り当てる任意の必要性を除去する。そうでない場合、ＯＳカーネルを呼び出し、ページテーブルを切り替え、トランスレーションルックアサイドバッファ（仮想メモリから物理メモリへの最近のトランスレーションを格納するＴＬＢ）を再充填するオーバヘッドを負うことになる。
図４９Ａは、共有線形アドレス範囲におけるメモリ領域を暗号化するために使用される、キー識別子（ＩＤ）４９００のセット（４９００ａ～４９００ｄ）、および、暗号鍵４９０２のセット（４９０２ａ～４９０２ｆ）の間のマッピングを示す。示された例において、第１キーＩＤ４９００ａは第１キー４９０２ａおよび第２キー４９０２ｂに割り当てられ、第２キーＩＤ４９００ｂは、第３キー４９０２ｃにマッピングし、第３キーＩＤ４９００ｃは、第４キー４９０２ｄおよび第５キー４９０２ｅにマッピングし、第４キーＩＤ４９００ｄは第６キー４９０２ｆにマッピングする。従って、示されるマッピングは、キーＩＤ４９００が、キー４９０２間で再使用されることを可能にする。例えば、第１キー４９０２ａに対応する関数が終了する、または、そうでない場合、第１キー４９０２ａを用いて暗号化されたメモリ領域が解放される場合、第１キーＩＤ４９００ａは、ページテーブルを切り替えることなく、第２キー４９０２ｂに自動的に再割り当てされ得る。
図４９Ｂは、キーＩＤの多重化がプライベート領域についてのキーおよびキーＩＤに限定されない単一のアドレス空間４９０１の例を示す。示された例において、ｋＩＤ１は、ｆ１およびｆ３両方の関数においてｋ７にマッピングし、ｋＩＤ２は、関数ｆ２においてｋ９にマッピングし、ｋＩＤ３は、関数ｆ４においてｋ９にマッピングする。これらの後者２つのマッピングは、単一の基礎となるキーが、図４９Ａにおいては必ずしも明らかでない複数のキーＩＤからマッピングされることができることを示す。
図４９Ｃは、第１関数４９０４が、第４キー４９０２ｄで暗号化される第１メモリ領域４９０６を使用する（例えば、読み取る、および／または、書き込む）例を示す。示された例において、第３キーＩＤ４９００ｃは、最初に第４キー４９０２ｄに割り当てられる。第１関数４９０４から第２関数４９０８へのコンテキストスイッチが発生するとき、第３キーＩＤ４９００ｃは、第２関数４９０８に関連する第２メモリ領域４９１０を暗号化するために使用される第５キー４９０２ｅに自動的に再割り当てされる。第１メモリ領域４９０６および第２メモリ領域４９１０は、共有された線形アドレス範囲４９１２に配置されることに特に留意すべきである。従って、示された解決手段は、ＯＳカーネルを呼び出し、ページテーブルを切り替え、仮想メモリから物理メモリへのトランスレーションでＴＬＢを再充填するオーバヘッドを除去する。示されるメモリ領域４９０６、４９１０はまた、共有メモリ領域を暗号化するのに使用されるキー（それぞれ、「ｋ９」および「ｋ７」）を含む。
より具体的には、共有メモリを介して通信する必要がある関数は、共有メモリの対応する領域を暗号化するために使用されるキーへのアクセスを共有すべきである。例えば、関数ｆ１およびｆ３が共有メモリ領域４９１０を通じて通信する必要がある場合、その領域は、ｋ７を使用して暗号化することができ、各関数におけるいくつかのキーＩＤはｋ７にマッピングされることができる。キーＩＤは、両方の関数において同一でよく、または、異なってもよい。両方の関数がｋ７を使用可能であることが重要である。しかしながら、両方の関数が同一のキーＩＤを使用することには、いくつかの利点があり得る。なぜなら、キーＩＤが物理アドレスビットを介して運ばれ得るからである。キーＩＤを共有することにより、ｆ１およびｆ２の間で共有されるメモリ領域をカバーする単一の線形－物理アドレスマッピングだけを有することが単純になる。そのようなアプローチは、異なるキーＩＤをサポートする領域をカバーする複数の線形－物理アドレスマッピングを有することと比較して、ＴＬＢオーバヘッドを低減する。
例えば、異なるキーにマッピングするためにキーＩＤを切り替えるための新しいタイプの命令が定義され得る。その命令タイプは、特定のコード範囲内だけで使用可能であるように制限され得る（例えば、範囲レジスタを使用して定義される）。その範囲は、ルートＰＤコードに対応するよう構成され得る。その命令は、権限のあるソフトウェア（例えばＯＳまたはＶＭＭ）によって構成されるキーのレポジトリからキーを選択することを許可し得る。代替的に、命令は、権限のあるソフトウェアに既知であり、かつ、権限の無いソフトウェアからアクセス不可能である位置における構造に、ソフトウェアによって提供されるキーを記録し得る。プロセッサは、その構造から各関数についての現在のキーＩＤ－キーマッピングを取得するよう構成され得る。例えば、これは、新しい関数が呼び出されるたびに発生し得る。または、ルートＰＤは、プロセッサに、インメモリ構造のコンテンツに基づいて内部状態を更新させる命令を呼び出し得る。
代替的に、単一の仮想アドレスまたは仮想アドレスの範囲のマッピングを担うリーフページテーブルエントリまたは複数のエントリにおけるタグ値を変更するための命令が定義され得る。このタグ値は、別の機構によってキーＩＤにマッピングされ得る。その場合、タグ値を効果的に変更することによって、そのメモリ領域に使用されるキーＩＤを変更する。
各関数が、複数のキーＩＤを使用してメモリにアクセスし得ることは明らかである。各メモリアクセスのために適切なキーＩＤを選択するために、関数は、各仮想メモリアドレスにおけるタグ値を指定し得、そのタグ値は、物理メモリアドレスにおける対応するキーＩＤにマッピングされ得る。例えば、プロセッサは、タグを指定する仮想アドレスビットのスライスを抽出して、キーＩＤを指定する物理アドレスのスライスに挿入し得る。
ルートＰＤについてのプライベートデータ領域は、敵対的関数がそのプレーンテキストコンテンツにアクセスすることを防止するために別個のキーを使用して暗号化され得る。そのキーにマッピングされる、関数内から使用可能なキーＩＤは無い。
各関数のコードおよびルートＰＤは、別個のキーを使用して暗号化され得、キーＩＤ－キーマッピングは、それ自体のプライベートコード領域に使用されるキーへのアクセスだけを各関数に付与することにより、不正な制御フロー転送（例えば、関数間で直接、または、関数からルートＰＤにおける不正なエントリポイント）を防止するのを助けるよう構成され得る。ルートＰＤと関数との間で制御を転送するときキーＩＤ－キーマッピングを更新するコードのトランポリン部分は、すべての関数およびルートＰＤからアクセス可能なキーＩＤからマッピングされるキーを使用して暗号化され得る。代替的に、コードのこのトランポリン部分は、各関数について複製され得る。その結果、各関数は、トランポリンコードを含む関数のコンテキストにおいて実行されるコードのすべてを暗号化するために、単一のキーを使用するだけでよい。
代替的に、すべての関数のコードおよびルートＰＤは、単一の共有キーを使用して暗号化され得、様々な制御フロー完全性実施機構が、不正の制御フロー転送を防止するために適用され得る。例えば、１６／０２４，５４７は、いくつかの可能な機構を説明する。
図４９Ｄは、ルート保護ドメイン４９１４（ＰＤ、例えば、ホストプロセッサ／ＣＰＵに配置されるユーザ空間信頼済みモニタリング）を含む単一アドレス空間４９１５、複数のサービスごとのプライベートデータ領域４９１７、および、複数の通信バッファを有する共有データ領域４９１６を示す。示された例において、各サービスごとのプライベートデータ領域が異なるキー（例えばｋ＊）を使用して暗号化される。実施形態において、カーネルを呼び出すオーバヘッドを回避するために、ルートＰＤ４９１４は、関数間で切り替るとき、マッピング更新を実行する。従って、示されるルートＰＤ４９１４は、キーＩＤの再割り当ての頻度を最小化するために、異なるキーＩＤを異なるキーに割り当てる。より具体的には、デスティネーションキーＩＤが既にデスティネーション関数のキーにマッピングされている場合、ルートＰＤ４９１４は、現在の関数とは異なるキーＩＤを有する関数に切り替えることができる。共有メモリ通信を実装するために、いくつかのキーＩＤは、複数の関数からアクセス可能であり得る。
図４９Ｅは、キーＩＤマッピングを更新する方法４９１８を示す。方法４９１８は概して、例えば既に説明されたルートＰＤ４９１４（図４９Ｄ）などのルートＰＤによって実装され得る。より具体的には、方法４９１８は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの非一時的機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を使用する機能固定型ハードウェアロジック、または、それらの任意の組み合わせに格納されるロジック命令セットにおいて１または複数のモジュールとして実装され得る。
示される処理ブロック４９２０は、キー識別子を第１キーにマッピングすることを提供し、ここで、第１キーは、第１関数、および、第１キーで暗号化される第１メモリ領域に関連付けられる。第１関数から第２関数へのコンテキストスイッチがブロック４９２２で検出される。加えて、示されるブロック４９２４は、コンテキストスイッチに応じてキー識別子を第２キーへマッピングし、ここで、第２キーは、第２関数、および、第２キーで暗号化される第２メモリ領域に関連付けられる。実施形態において、第１メモリ領域および第２メモリ領域は、線形アドレス範囲を共有する。従って、示される方法４９１８は、ＯＳカーネルを呼び出し、ページテーブルを切り替え、仮想メモリから物理メモリへのトランスレーションでＴＬＢを再充填するオーバヘッドを除去する。
加えて、第１キーは、第１ターゲットドメインについての対称キーであり得、第２キーは、第２ターゲットドメインについての対称キーであり得る。一例において、第１ターゲットドメインおよび／または第２ターゲットドメインは、信頼ドメインのサブドメインである。そのような場合において、暗号鍵は、（例えば、通常のプレーンテキストまたは暗号テキスト入力に加えて）異なる暗号入力が各サブドメインについて指定されることを可能にする「ｔｗｅａｋ」キーであり得る。ｔｗｅａｋキーの使用は多くの場合、各サブドメインについて完全に異なるキーを指定することより効率的である。
関数は、使用を承認されないキーにアクセスすることを防止され得る。そのためにルートＰＤは、関数を呼び出す前に、関数からアクセス可能であり得る任意のキーＩＤからそれらのキーを１つ１つマッピング解除する。しかしながら、それは、不必要な性能オーバヘッドを導入し得る。より効率的な代替的手段は、アドレスタグをキーＩＤにマッピングするテーブルをサポートすること、および、そのようなテーブル間の切り替えのための効率的オペレーションをサポートすることであり得る。これは、仮想メモリアドレスを物理メモリアドレスにマッピングするページテーブルと同様である。多くの数の関数をサポートするのに有益であるように、キーマッピングテーブルがメモリに格納される場合、タグからキーＩＤへのマッピングをタグ－キーＩＤルックアサイドバッファ（ＴＫＬＢ）にキャッシュすることも有益であり得る。これは、仮想－物理アドレスマッピングをキャッシュするのに使用されるトランスレーションルックアサイドバッファ（ＴＬＢ）と同様である。異なるアドレス空間の間で切り替えるときに、フラッシュする必要性を最小化するために、ＴＬＢエントリがアドレス空間識別子（ＡＳＩＤ）でタギングできる方式と同様に、ＴＫＬＢエントリもコンパートメントＩＤでタギングされ得る。例えば、コンパートメントＩＤは、ルートＰＤだけからアクセス可能であるレジスタに格納され得る。
タグ－キーＩＤマッピングテーブルに代替的に、または追加的に、特定のタグ値またはキーＩＤへの関数によるアクセスをブロックするための機構／プロシージャが定義され得る。例えば、ビットマスクがレジスタ、または、ルートＰＤだけからアクセス可能なインメモリビットマップに格納され得る。ルートＰＤは、関数が使用を承認されたタグまたはキーＩＤを示すために、各関数を呼び出す前に、そのタグマスク構造を更新し得る。例えば、タグマスク構造におけるセットビットは、そのビット位置に対応する特定のタグまたはキーＩＤが、関数による使用を承認されていることを示し得る。コードフェッチおよびデータアクセスを制御する（例えば、実行だけのメモリパーミッションを実施する）ための、別個のタグマスク構造が定義され得る。データアクセスは更に、読み取り、書き込みなどに細分化され得る。別個のタグマスク構造が各タイプのアクセスについて定義される。
また、新しい関数がオリジナルおよび新しいタグ値の両方を使用することを承認されていることを確実にするために、ページテーブルエントリにおけるタグ値を変更する命令の呼び出しは、タグマスク構造に対してチェックされ得る。命令は、タグマスク構造がチェックされるべき指定子を受け付得る、または、それらはすべて並列にチェックされ得る。
性能オーバヘッドを更に低減するために、関数が指定されたタグへのアクセスをドロップすることを可能にすることは有益であり得る。例えば、タグマスク構造におけるビットの消去だけをサポートする命令が定義され得る。このアプローチは、ドロップされたタグに関連付けられるメモリ領域にアクセスすることを防止することによって、サブコンパートメントを効果的にサンドボックスするためにそのサブコンパートメントを呼び出す前に、特定のタグへのアクセスを関数がドロップすることを可能にし得る。サブコンパートメントは、そのタグ自体へのアクセスを再有効化することを防止される。
タグマスク構造によって現在ブロックされているタグ値へのアクセスを再追加するためにルートＰＤが呼び出され得る。代替的に、コールゲートは、各ゲートを通過するときに適用されるタグマスク構造値で延長され得る。
タグ値へのアクセスをドロップする機能は、ジャストインタイム（ＪＩＴ）コンパイラにおいて実行のみのメモリパーミッションを実施するのに有用であり得る。なぜなら、ＪＩＴは、コードをメモリに書き込み、次に、対応するタグを、コードタグマスク構造において有効化しながら、データタグマスク構造からドロップし得るからである。
更に、ハードウェアは、非ルート保護ドメイン内の実行可能メモリへの書き込みを防止するポリシーを選択的に実施し得る。すべてのタグ値、または、特定のタグ値のいずれかについて有効化されている場合、このポリシーが有効化されているタグ値の１つを有する命令をフェッチするとき、データ書き込み、および、コードフェッチタグマスク構造の両方をチェックし得る。いずれかのフェッチタグマスク構造が、対応するタグへのアクセスをブロックする場合、または、データ書き込みタグマスク構造が、対応するタグへのアクセスを可能にする場合、それは、フェッチをブロックし得る。
いくつかのアプリケーションにおいて、タグを指定するために仮想アドレスビットを放棄するのは望ましくないことがあり得る。代替的に、各メモリアクセスの有効セグメントは、タグまたはキーＩＤを選択するために使用され得る。例えば、コードフェッチは、コードセグメント（ＣＳ）に関連するタグを使用し得、通常のデータアクセスは、データセグメント（ＤＳ）に関連するタグを使用し得、スタックアクセスは、スタックセグメントに関連するタグを使用する。タグの関連付けは、単に有効セグメント（例えば、ＣＳとＤＳ）、関連セグメントセレクタ値、または、セグメントレジスタに含まれる（例えば、セグメント記述子テーブルエントリからロードされる）他の情報に基づき得る。セグメントとタグの関連付けは、レジスタまたはインメモリテーブルに格納され得る。関連データは、権限のあるソフトウェアだけから、または、承認された権限の無いソフトウェアから更新可能であり得る。例えば、これらの関連を更新する命令が定義され得、その使用は、ルートＰＤのコード範囲に制限され得る。
追加の留意点および例
例４９０１は、実行可能プログラム命令のセットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングシステムによって実行されるとき、コンピューティングシステムに、キー識別子を第１キーにマッピングさせ（第１キーは、第１関数、および、第１キーで暗号化される第１メモリ領域に関連付けられる）、第１関数から第２関数へのコンテキストスイッチを検出させ、コンテキストスイッチに応じてキー識別子から第２キーにマッピングさせる（第２キーは、第２関数、および、第２キーで暗号化される第２メモリ領域に関連付けられ、第１メモリ領域および第２メモリ領域は、線形アドレス範囲を共有し、第１キーは第１ターゲットドメインの公開鍵であり、第２キーは第２ターゲットドメインの公開鍵であり、第１ターゲットドメインまたは第２ターゲットドメインの１または複数は、信頼ドメインのサブドメインである）。
権限の無い保護キーの更新の例
図５０Ａは、アクセスパーミッションが複数の関数について指定されることを可能にする複数のサービス保護ドメイン５０００（５０００ａ～５０００ｎ）を示す。より具体的には、示されるドメイン５０００は、保護キーレジスタ（ＰＫＲ、図示せず）における複数の「スライス」に対応する。各スライスは、ページへのすべてのアクセスを無効にするビット（例えば、メモリ領域）、および、ページへの書き込みを無効にするビットを含む。ルート保護ドメイン（ＰＤ）５００２（例えば、信頼済みユーザ空間モニタリング）は概して、実行について関数をスケジューリングし、各スケジューリングされた関数をドメイン５０００の１つ（例えば、保護キーレジスタにおけるスライスの１つ）に割り当てる。従って、ルートＰＤ５００２は、第１関数を第１ドメイン５０００ａ（および、例えばＰＫＲにおける第１スライス）に、第２関数を第２ドメイン５０００ｂ（および、例えば、ＰＫＲにおける第２スライス）に割り当てるなどのことを行い得る。いくつかの関数は、複数のスライスへのアクセスを割り当てられ得る（例えば、スライスの１つが、複数の関数間で共有されるメモリの領域へのアクセスを制御する場合）。
示されるルートＰＤ５００２はまた、保護キーＩＤを、スケジューリングされた関数に割り当てる。ここで、各保護キーＩＤは、関数がアクセスするページを暗号化するために使用される暗号鍵にマッピングする。ルートＰＤ５００２が、実行について関数をスケジューリングするとき、ルートＰＤ５００２は、関数への割り当てに保護キーＩＤが利用可能かどうかを判定する。これに関して、関数の数は保護キーＩＤの数より大きいことがあり得る（例えば、示された例において「ｎ」）。関数への割り当てに利用可能な保護キーが無い場合、保護キーＩＤの数は、すべての関数のセットに関して不十分である。そのような場合、示されるルートＰＤ５００２は、更新命令５００４をホストプロセッサ（例えば、図には示されないＣＰＵ）を発行する。更新命令５００４は、階層ページテーブル５００８におけるエントリ５００６を新しい保護キーＩＤ（ＰＫＩＤｎｅｗ）で更新するようホストプロセッサに命令する。これに関して、更新命令５００４は、新しい保護キーＩＤについて何の値を使用するか、および、ページの線形アドレスを示し得る。従って、ホストプロセッサは、階層ページテーブル５００８におけるエントリ５００６を発見する（例えば、ページウォークを介して）ために線形アドレスを使用し得る。ページテーブル５００８におけるエントリは、権限の無いコンポーネントによる直接的修正から保護される、権限のあるデータ構造である。従って、示されるアプローチは、保護キーＩＤ情報だけが修正されることを許可する。
実施形態において、更新命令５００４はまた、ページング構造キャッシュを消去するようにホストプロセッサに命令する。そのようなアプローチは、古い保護キーＩＤ値がページング構造キャッシュから除去されることを保証する。加えて、更新命令５００４は、既に説明した、仮想メモリアドレスから物理メモリアドレスへの最近のトランスレーションを格納するＴＬＢ（図示せず）を消去するようホストプロセッサに命令し得る。従って、示された解決手段は、新しい保護キーＩＤでページテーブル５００８を更新するとき、ＯＳカーネルを呼び出す任意の必要性を除去する。
他のセキュリティの懸念は、更新命令５００４へのアクセスを制限することによって対処され得る。一例において、関数は、マネージドランタイム関数に限定される。一般的に、マネージドランタイム環境は、高水準の解決手段、例えば、ＨＴＭＬ５（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ ５、例えば、ＨＴＭＬ５ Ｅｄｉｔｏｒ'ｓ Ｄｒａｆｔ ８ Ｍａｙ ２０１２， Ｗ３Ｃ）Ｄａｌｖｉｋ （ＡＮＤＲＯＩＤ（登録商標） Ｏｐｅｎ Ｈａｎｄｓｅｔ Ａｌｌｉａｎｃｅ／ＯＨＡ）、ＡＲＴ （ＡＮＤＲＯＩＤ（登録商標） Ｒｕｎｔｉｍｅ， ＯＨＡ）、Ｃ＃ （例えば、Ｃ＃ ５．０， ＭＩＣＲＯＳＯＦＴ Ｃｏｒｐ．， Ａｕｇｕｓｔ １５， ２０１２）、．ＮＥＴ （例えば、．ＮＥＴ Ｆｒａｍｅｗｏｒｋ ４．５， ＭＩＣＲＯＳＯＦＴ Ｃｏｒｐ．， Ｏｃｔｏｂｅｒ １７， ２０１３）、Ｒｕｂｙ （例えば、Ｒｕｂｙ ２．１．０， Ｙ． Ｍａｔｓｕｍｏｔｏ， Ｄｅｃｅｍｂｅｒ ２５， ２０１３）、Ｐｅｒｌ （例えば、Ｐｅｒｌ ５．１８．２， Ｐｅｒｌ．ｏｒｇ， Ｊａｎｕａｒｙ ７， ２０１４）、Ｐｙｔｈｏｎ （例えば、Ｐｙｔｈｏｎ ３．３．３， Ｐｙｔｈｏｎ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎ， Ｎｏｖｅｍｂｅｒ １９， ２０１３）、ＪＡＶＡ （例えば、， ＪＡＶＡ Ｓｔａｎｄａｒｄ Ｅｄｉｔｉｏｎ ７ Ｕｐｄａｔｅ ５１， ＯＲＡＣＬＥ Ｃｏｒｐ．， Ｊａｎｕａｒｙ １４， ２０１４）などであり得る。従って、関数はマネージドランタイム環境によって、ジャストインタイム（ＪＩＴ）でインターセプトまたは呼び出されるので、セキュリティが強化される。
加えて、関数のアトミック実行が強化され得る。従って、そのようなアプローチは、自身のスレッドを操作するアプリケーションにおいて発生し得るオペレーション中のスレッド（例えば、データベース、Ｊａｖａ（登録商標）、および／または、ガベージコレクションアプリケーション）の停止から保護する。
更新命令５００４へのアクセスを制限する他のアプローチは、信頼されないコードをスキャンして、更新命令５００４を含まないことを検証すること、および、ルートＰＤ５００２を含む指定された領域の外で更新命令５００４を実行する任意の試行をブロックすることなどを含む。
図５０Ｂは、保護キーＩＤを更新する方法５０１０を示す。方法法５０１０は概して、例えば既に説明されたルートＰＤ５００２（図５０Ａ）などのルートＰＤによって実装され得る。より具体的には、方法５０１０は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの非一時的機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を使用する機能固定型ハードウェアロジック、または、それらの任意の組み合わせに格納されるロジック命令セットにおいて１または複数のモジュールとして実装され得る。
示される処理ブロック５０１２は、関数のセットに関して、不十分な数の保護キーＩＤを検出することを提供する。ブロック５０１４は、不十分な数の保護キーＩＤに応じて、例えばホストプロセッサなどのプロセッサに、新しい保護キーＩＤでページテーブルエントリを更新するよう命令する。ブロック５０１４は、従って、新しい保護キーＩＤおよび線形アドレスを示す更新命令を発行することを含み得、プロセッサは、線形アドレスに基づいて階層ページテーブルのページウォークを実行する。また、示されるブロック５０１４は、プロセッサに、ページング構造キャッシュおよびＴＬＢを消去するよう（例えば更新命令を介して）命令する。一例において、更新命令への不正アクセスを制限するために、関数のセットは、マネージドランタイム関数に制限される。実施形態において、ブロック５０１４はまた、特定のサービスへのすべてのページ割り当てについて、ページテーブルエントリ（ＰＴＥ）を更新する。なぜなら、各サービスは、１つより多くのページを有する可能性が高いからである。ブロック５０１４はまた、関数のアトミック実行を実施すること、信頼されないコードをスキャンして、更新命令を含まないことを検証すること、ルートＰＤを含む指定領域の外で更新命令を実行する任意の試行をブロックすることなどを含み得る。従って、示される方法５０１０は、ページテーブルエントリを更新するとき、ＯＳカーネルを呼び出す任意の必要性を除去する。
追加の留意点および例
例５００１は、実行可能プログラム命令のセットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングシステムによって実行されるとき、コンピューティングシステムに、関数のセットに関連して不十分な数の保護キー識別子を検出させ、不十分な数の保護キー識別子に応じて、ホストプロセッサにページテーブルエントリを更新するよう命令させ（関数のセットは、マネージドランタイム関数に限定される）、関数のセットのアトミック実行を実施させる。
例５００２は、例５００１の少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令は、実行されるとき、更にコンピューティングシステムに、ページング構造キャッシュを消去するようホストプロセッサに命令させる。
例５００３は、例５００１の少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令は実行されるとき、コンピューティングシステムに、トランスレーションルックアサイドバッファを消去するようホストプロセッサに命令させる。
権限の無いページテーブルパーミッション更新の例
図５１Ａは、サンドボックス５１０２（例えば、コード隔離ツールとして動作する規則のセット）を含む処理５１００を示す。ここで、サンドボックス５１０２は、例えばユーザモードブローカ５１０４（例えば、ユーザ空間コンパートメントマネージャ）などの権限の無いコンポーネントが、例えば、論理アドレス空間５１０６における論理ブロックアドレス５１１２、および、物理アドレス空間５１１０における物理ページ５１１４などの「サンドボックス」リソースにアクセスすることを制限する。ユーザモードのサンドボックスは従来、ソフトウェア指向アクセス制御を介して強化され得る。示された例において、命令セットアーキテクチャページテーブル（ＩＳＡ－ＰＴ）５１０８は、論理アドレス空間５１０６を物理アドレス空間５１１０にマッピングし、ページアドレス変換がＴＬＢ（図示せず）をミスするとき、ＣＰＵ５１１８のページミスハンドラ（ＰＭＨ）５１１６は、アドレス変換を実行する。ハードウェアでソフトウェアベースのアクセス制御を強化することは、マルチテナントワークロードが論理アドレス空間５１０６を共有し、かつ、ＣＰＵ５１１８が、投機的実行を使用するアウトオブオーダ（ＯＯＯ）プロセッサである場合に発生し得る「サイドチャネル攻撃」に関して特に有利であり得る。
特にアウトオブオーダ処理に関して、ＣＰＵは特定の命令を完了し、他の命令の実行を開始する。それらが後に許可されていないことが分かり、従って、これらの命令のいずれも、実際のリタイアメントに適切でない場合も同様である。従って、許可されない命令の結果はいずれも実際には任意の変数を修正しない。サイドチャネル攻撃のリスクは、禁止されていることを攻撃者が知っている、そのような慎重に構築されたオペレーションの結果である性能の影響を観察するという形式で生じ得る。従って、攻撃者が位置Ｘにアクセスできないが、位置Ｘにおけるいくつかのビットから値Ｖを構築するために（例えば、＊Ｘ＆０ｘ０Ｆを用いて）、ＯＯＯに起因して、一時的に十分進展することができる場合でも、攻撃者は、例えばＲ［Ｖ］など、いくつかの他の許可可能範囲にアクセスできる。攻撃者がレイテンシをチェックすることによってＶの異なる可能な値でのＲ［...］へのアクセスがキャッシュヒットまたはミスを生じさせるかどうかをチェックできるとき、Ｒ［Ｖ］へのアクセスは、後に性能の差異を生じさせる。このように、攻撃者は、位置Ｘのコンテンツを直接に参照することを実際に許可されることなく、一度に数ビット、それらのコンテンツについて知る。
ＦａａＳワークロードは、ハードウェアを介して実施される、より細かい粒度のアクセス制御からも利益を得ることができるマルチテナントワークロードのサーバ形態であり得る。より具体的には、ＦａａＳは、４０９６バイト（４ＫＢ）レベル（例えばページレベル）で、従来のハードウェアがメモリパーミッションを制限し得るより細かい粒度のメモリオブジェクトレベルでアクセス制御を提供するハードウェアから利益を得ることができる。
示された解決手段は、ハードウェアによって実施されるサブページパーミッションモデルを提供し、ＯＳ５１２０がパーミッション管理を委譲すること、および、細かい粒度でユーザモードブローカ５１０４に更新することを可能にする。従って、マルチテナントワークロードは、コンパートメントパーミッションを管理するユーザモードブローカ５１０４を用いて、同一の論理アドレス空間５１０６内で実行し得る。しかしながら、ＯＳ５１２０は、線形アドレス空間５１０６の物理アドレス空間５１１０へのマッピングの制御を継続することに特に留意すべきである。
一般的に、保護キーは、プロセス５１００において、論理アドレス空間５１０６が、複数のサブドメイン（例えば、１６のサブドメイン）間で疎な方式でパーティショニングされることを可能にする。従来の保護キーは、読み取り／書き込み（ＲＷ）パーミッションが、ドメインごとにページについて表現されること、および、システムコール無しのドメイン間の高速切り替えを可能にし得る。
示された例において、サブページパーミッションテーブル（ＳＰＰＴ）５１２２は、サブページ５１２５のレベル（例えば、４ＫＢページの場合、１２８バイト粒度）でパーミッションを指定し、ユーザモードブローカ５１０４に公開される。示されるユーザモードブローカ５１０４は、ＳＰＰＴ５１２２に関して、読み取り／書き込み／実行（ＲＷＸ）権限を有する。一例において、ユーザモードブローカ５１０４は、物理アドレス空間５１１０におけるサブページに関してサブページパーミッションを低減する（例えば、ＲＷアクセスをリードオンリーアクセスにダウングレードする）ことが可能であるが、サブページパーミッションを増加させる（例えば、リードオンリーアクセスをリード／ライトアクセスにアップグレードする）能力を有しない。
従って、サブページパーミッションは、ＳＰＰＴ５１２２を介して物理アドレス空間５１１０において各物理ページ５１２４（または、仮想化環境におけるゲスト物理アドレス／ＧＰＡ）について実施される。実施形態において、ＳＰＰＴ５１２２は、物理ページ５１２４を、パーミッションのビットベクトルにマッピングし、各ビットは、サブページ領域について書き込みパーミッションに対応する。サブページパーミッションを指定する拡張ページテーブル（ＥＰＴ）ページエントリが特定４ＫＢマッピングについて有効であるときだけＣＰＵ５１１８によってＳＰＰＴ５１２２をウォークするのではなく、示された解決手段はページウォークを変更し、１）ＩＳＡ－ＰＴ５１０８ページウォークを完了し、論理ブロックアドレス５１２６を物理ページ５１２４のアドレスに変換し、次に、物理ページ５１２４のアドレスを使用してＳＰＰＴ５１２２をウォークする。従って、サブページパーミッションは、ＩＳＡ－ＰＴ５１０８によって有効化／トリガされるが、ＥＰＴを有効化するために仮想マシンモニタ（ＶＭＭ）を必要としない。
加えて、ＳＰＰＴ５１２２は、ユーザモードブローカ５１０４についてＯＳ５１２０によって作成されるＩＳＡ－ＰＴ５１０８における適切なマッピングによってユーザモードブローカ５１０４に公開される。これらのマッピングは、ユーザモードブローカ５１０４が自由にパーミッションを修正することを許可するが、ページについての論理ブロックアドレス－物理アドレスマッピングは許可しない。これは依然としてＯＳ５１２０によって制御される。
更に、新しい命令は、ＳＰＰＴ５１２２を無効化するために、ユーザモードブローカ５１０４によって使用され得る。ここで、新しい命令は、キャッシュされたパーミッションをフラッシュする。そのようなアプローチは、パーミッションが低減されるときに特に有用である。任意のキャッシュパーミッションはまた、ユーザモードブローカ５１０４が、プロセスコンテキストスイッチ上のＣＰＵ間で移動する場合／ときにフラッシュされ得る。一例において、サブページパーミッションは、セキュリティドメインごとに、高水準プログラム言語に公開される。加えて、コールスタック領域は、コールされた関数をコール元関数から隔離するために（例えば、比較的低い権限を有するコールされた関数からのリバーススタック攻撃を防止するために）使用され得る。
図５１Ｂは、サブページパーミッションを制御する方法５１２８を示す。方法５１２８は概して、例えば、既に説明されたＯＳ５１２０（図５１Ａ）などのＯＳによって実装され得る。実施形態において、方法５１２８は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの非一時的機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を使用する機能固定型ハードウェアロジック、または、それらの任意の組み合わせに格納されるロジック命令セットにおいて１または複数のモジュールとして実装され得る。
示される処理ブロック５１３０は、権限の無いコンポーネント（例えばユーザモードブローカ）が、論理アドレス空間と、複数の関数によって共有される物理アドレス空間との間のマッピングを修正することを防止することを提供する。ブロック５１３２において、権限の無いコンポーネントは、物理アドレス空間に関してサブページパーミッションを低減することを許可される。
一例において、ブロック５１３４は、セキュリティドメインごとにサブページパーミッションを高水準プログラム言語に公開する。これに関して、サブページパーミッションは、タグまたはアノテーションとして特定のセキュリティドメインに公開され得る。
実施形態において、ブロック５１３６は、コールスタック領域を介して、複数の関数におけるコール元関数から、複数の関数におけるコールされた関数を隔離うする。従って、ブロック５１３６は、コールされた関数がコール元関数より権限が低いリバーススタック攻撃から保護する。ブロック５１３０、５１３２、５１３４、５１３６は、非連続的に、および／または、任意の適切な順序で実行され得る独立したオペレーションである。
追加の留意点および例
例５１０１は、実行可能プログラム命令のセットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングシステムによって実行されるとき、コンピューティングシステムに、権限の無いコンポーネントが、論理アドレス空間と、複数の関数によって共有される物理アドレス空間との間のマッピングを修正することを防止させ、物理アドレス空間に関して、権限の無いコンポーネントがサブページパーミッションを低減することを許可させ、セキュリティドメインごとにサブページパーミッションを高水準プログラム言語に公開させ、コールスタック領域を介して、複数の関数におけるコールされた関数を、複数の関数におけるコール元関数から隔離させる。
非優先化モードの例
ハードウェア利用率および全体的な業務の効率性の改善は一般に、テナント間でハードウェアコンピューティングリソースを共有することによって実現される。その例は、クラウドコンピューティング、ＦａａＳなどである。この共有は、プロセスが動作の範囲を定めること、ならびに、セキュリティおよびプライバシーを保護するためにテナント間のワークロードインタラクションを防止することを必要とし得る。従って、範囲が定められた動作は、事前に限定される（例えば封じ込められる）必要がある任意のものを参照する。通常、この封じ込めは、例えば、サンドボックスおよび仮想マシン（ＶＭ）など、何らかの種類の隔離を通じて囲まれるコードに適用される。
ＶＭ、プロセス、名前空間（例えば、「コンテナ」の場合）、および、マネージドランタイムは、封じ込めの課題に対処し得るが、始動時間、呼び出し性能、および／または、メモリオーバヘッドに関して、改善の余地が大いに残っており、デプロイメントの適用性および密度を制限する。
ネットワーク関数仮想化（ＮＦＶ）などのいくつかのアプリケーションは、ナノ秒からマイクロ秒の範囲のレイテンシを必要とし得るが、従来のＦａａＳ実装は、コールドスタートコンテナを呼び出すとき、数十ミリ秒のオーダーのレイテンシを生じさせ得る。そのようなアプリケーションにおいて通常使用されるポールモードは、別の問題のセットを有する。すなわち、隔離に関連する密度およびメモリオーバヘッドである。実際に、ＶＭおよびコンテナはなお、数ＭＢ～ＧＢの比較的大きい量のメモリを使用し得る。従って、サーバ上のインスタンスの量は通常限定される。更に、ポールモード実行は、オーバーサブスクリプションと適合しないことがあり得る。対照的に、実行完了アプローチは通常、単一アプリケーション内だけで（例えば、関数コール間の共有メモリ空間に起因して）適用可能である。または、良好な隔離でＦａａＳモデルにマッピングされる場合、高レイテンシを有する。
極端な場合、すべてのアプリケーションが、ローカルおよびリモート両方で実行する関数（例えば、ＯＳ、プラットフォームおよびインフラストラクチャサービスを含む）に分解される場合、性能の需要は、サーバあたり秒あたり数億コールに到達し得る。これは従来、ネイティブコードおよびＣＡＬＬ命令を介してのみ達成可能である。
非優先化モードと呼ばれる近年開発された技術は、複数のメモリ「セグメント」で構成されるアドレス空間を共有しながら、サンドボックス環境において関数を実行するフレームワークを提供する。サンドボックスは、関数がセグメントを変更することを防止し、コードセグメントによって定義されるサンドボックス内に封じ込められるように制御転送を制限する。ローカル記述子テーブル（ＬＤＴ）は、メモリセグメント記述子を含むメモリテーブルである。各セグメント記述子は、セレクタ（例えば、インデックス）、および、例えば、ベースアドレス、サイズ、アクセス権限など、様々な特性を含む。メモリセグメントを参照するべく、関数は、記述子特性をＬＤＴからホストプロセッサ内に転送させるセグメントレジスタにセレクタをロードする。ＬＤＴへの後の修正は概して、セグメントレジスタが再ロードされない限り有効でない。非優先化モードアプローチは、修正されたセグメント記述子の使用に依存する。ここで、ベースアドレスは、範囲の低い制約として処理される。しかしながら、利用可能なセグメント記述子の数が限定されるので、ＬＤＴへの動的更新が必要であり得る。加えて、少ない数のセグメントレジスタは、限定された数のメモリ範囲だけが使用されることを可能にし、すべてのパラメータおよび結果を連続メモリエリアに配置するためにコール元に負担をかける。
本明細書において説明される技術は、非優先化モードを、例えば、符号化インライン機能（ＥＩＣ）情報などの機能情報に拡張し、アドレス空間を共有しながら複数のメモリ領域を使用することを可能にする。より具体的には、非優先化モードの構成は、メモリアクセスのＥＩＣセマンティックスを実施し、スタックアクセスをカバーするＥＩＣについてアプリケーションバイナリインタフェース（ＡＢＩ）を定義し、非権限コードからのシステム／外部コールの処理を定義するために実装される。
図５２Ａは、共有メモリ（例えばメモリセグメント）へのアクセスを試行する関数のための非優先化モードパス５２００を示す。示された例において、ＥＩＣ情報５２０２（５２０２ａ～５２０２ｃ）の１または複数の機能制約（例えばセマンティックス）が、試行されたメモリアクセスに対して実施される。ＥＩＣ情報５２０２は、ＭＡＣ５２０２ａ、境界情報５２０２ｂおよびポインタ５２０２ｃを含む。一例において、ＭＡＣ５２０２ａは、境界情報５２０２ｂに基づいて有鍵一方向ハッシュ関数によって作成されるタグである。ここで、ＭＡＣ５２０２ａを形成するために使用される秘密鍵は、保護領域（例えば、ホストプロセッサ上）に配置される。従って、ＭＡＣ５２０２ａは、ＥＩＣ情報５２０２が、上記送信側から来て、変更されていないことを確認するために使用される。従って、示されるＭＡＣ５２０２ａは、同じく秘密鍵を保持する検証側が、ＥＩＣ情報５２０２の任意の変化を検出することを可能にすることによって、ＥＩＣ情報５２０２の完全性および信頼性の両方を保護する。一例において、ポインタ５２０２ｃは、境界情報５２０２ｂによって定義されるメモリ領域を参照する。従って、メモリアクセスが権限の無い関数によって試みられる場合、アクセスにおいて使用されるポインタが正当であり、境界情報５２０２ｂによって定義されるメモリ領域内にあることを確実にするために、ＭＡＣ５２０２ａがチェックされる。
一例において、セグメント記述子はまた、スタックアクセスをカバーするＥＩＣのためにＡＢＩを定義し、権限の無いコードからシステム／外部コールの処理を定義するように修正される。ＡＢＩは、コール元およびコール先が特定の挙動責務に従うコール変換である。本明細書において使用される場合、ＡＢＩは、コールにおいて、コール先のセグメントレジスタまたは機能がどのようにロードされるか、ならびに、コール元のセグメントレジスタもしくは機能がどのようにアンロードされるかを指定する。同様に、コール先が完了し、コール元が、コール先が完了したポイントから再開する必要がある場合、ＡＢＩは、それぞれのロード／アンロードが逆にどのように実行されるかを指定する。実施形態において、ＡＢＩは、メモリへのすべての参照がＥＩＣとして渡され、特定のバイナリフォーマット（例えば、ビットフィールド－ＭＡＣ／制約／ポインタから成る）でコール先のスタックに置かれることを指定し、ポインタについての単一ビットフィールドを含む通常ポインタから区別する。示された例において、権限モードパス５２０４は、ＥＩＣ情報５２０２の機能制約をバイパスする。
図５２Ｂは、サブページパーミッションを制御する方法５２０６を示す。実施形態において、方法５２０６は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ファームウェア、フラッシュメモリなどの非一時的機械またはコンピュータ可読記憶媒体、例えばＰＬＡ、ＦＰＧＡ、ＣＰＬＤなどの構成可能ロジック、例えばＡＳＩＣ、ＣＭＯＳまたはＴＴＬ技術などの回路技術を使用する機能固定型ハードウェアロジック、または、それらの任意の組み合わせに格納されるロジック命令セットにおいて１または複数のモジュールとして実装され得る。
示される処理ブロック５２０８は関数の呼び出しを検出し、ブロック５２１０において、関数が非優先化モードで呼び出されるかどうかが決定される。既に説明したように、非優先化モードは、複数のメモリセグメントから構成されるアドレス空間を共有しながら、サンドボックス環境において関数を実行するためのフレームワークを提供し得る。非優先化モードで呼び出される関数に応じて、示されるブロック５２１２は、関数による共有メモリ空間へのアクセスの試行に対する１または複数の機能制約を実施する。一例において、ブロック５２１２は、メモリアクセスについてのＥＩＣセマンティックスを実施することに加えて、スタックアクセスをカバーするＥＩＣについてのＡＢＩを定義すること、および、権限の無いコードからのシステム／外部コールの処理を定義することを含む。従って、示される方法は、限定された数の利用可能まセグメント記述子、および、サーバあたり秒あたり非常に多くの数のコールを含むＦａａＳシステムにおける少ない数のセグメントレジスタについての懸念に対処する。
コードセグメント記述子およびコードセグメントレジスタは、各記述子をロードするときにＥＩＣ認証キーレジスタに自動的にロードされる機能認証キーを格納するよう拡張され得る。代替的に、コードセグメントセレクタは、（例えば、ＭＡＣ生成プロシージャへの他の入力と連結される、または、暗号ｔｗｅａｋとして）ＥＩＣ認証アルゴリズムについての入力として使用され得る。
代替的に、ＥＩＣ認証アルゴリズムについての機能認証キー、または、他の入力は、他のセグメントレジスタ（例えば、データセグメント／ＤＳ、追加のセグメント／ＥＳ、汎用セグメント（ＦＳ、ＧＳ）、またはスタックセグメント／ＳＳ）から引き出され得る。
追加の留意点および例
例５２０１は、実行可能プログラム命令のセットを含む、少なくとも１つのコンピュータ可読記憶媒体を含み、実行可能プログラム命令のセットは、コンピューティングシステムによって実行されるとき、コンピューティングシステムに、関数の呼び出しを検出させ、関数が非優先化モードで呼び出されたと判定させ、関数が非優先化モードで呼び出されることに応じて、関数による共有メモリ空間へのアクセスの試行に対する１または複数の機能制約を実施させる。
「連結」という用語は、対象のコンポーネント間の任意のタイプの直接的または間接的関係、を指すために本明細書において使用されてよく、電気的、機械的、流体的、光学的、電磁的、電子機械的、または他の接続に適用されてよい。加えて、「第１」、「第２」等の用語は、説明を容易にするためだけに本明細書において使用されてよく、反対の記載がない限り、何ら特定の時間的または時系列的な意味を含まない。
本願および特許請求の範囲において用いられる「のうちの１または複数」という用語によって結合される項目の列挙は、列挙された用語の任意の組み合わせを意味してよい。例えば、「Ａ、Ｂ、またはＣのうちの１または複数」という文言は、Ａ；Ｂ；Ｃ；ＡおよびＢ；ＡおよびＣ；ＢおよびＣ；またはＡ、Ｂ、およびＣを意味してよい。
当業者ならば、前述の説明から、実施形態の幅広い技術が様々な形態で実装され得ることを理解するであろう。従って、実施形態はこれらの特定の例に関し説明されてきたが、実施形態の真の範囲は、このように限定されるべきではない。なぜなら、図面、明細書、および以下の特許請求の範囲を精査すれば、当業者には他の修正形態が自明であるからである。
他の可能な請求項
（項目１） 強化されたファンクションアズアサービス（ＦａａＳ）を複数のユーザに提供するための実行可能コンピュータプログラミング命令のセットを含む少なくとも１つの非一時的コンピュータ可読記憶媒体であって、上記実行可能コンピュータプログラミング命令は、コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
１または複数のイベントが上記複数のユーザから受信されたことに応じて、上記コンピューティングシステムにおける１または複数のアーキテクチャサブシステム上で複数の関数を実行することであって、上記１または複数アーキテクチャサブシステムは、上記複数の関数、および、上記複数の関数に関連付けられる複数のコンテナについての実行環境の抽象化を表す、実行すること、
上記コンピューティングシステムにおける１または複数のソフトウェアおよびオーケストレーションサブシステムによる複数の関数の実行を促進するために、上記コンピューティングシステムの複数のコンピューティングリソースを割り当て、前記複数のコンピューティングリソースを割り当て、上記複数の関数に関連付けられる複数のパラメータ、および、上記複数のコンピューティングリソースに関連付けられる複数のパラメータを解析すること、
上記複数の関数と、上記複数の関数および上記コンピューティングリソースに関連付けられる上記複数のパラメータの解析とを、上記コンピューティングシステムにおける１または複数のネットワーキングおよびストレージサブシステムに格納することであって、上記複数の関数、および、上記複数のパラメータの上記解析を格納するための位置が、上記複数の関数と、対応する上記複数のコンピューティングリソースとの間の局所性を強化し、関数実行レイテンシを低減するために選択される、格納すること、ならびに、
上記コンピューティングシステムにおける１または複数のセキュリティサブシステムによって、上記複数の関数の上記実行を保護すること
を行わせる、少なくとも１つの非一時的コンピュータ可読記憶媒体。
（項目２） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
上記複数の関数のうち１または複数の関数の上記実行をモニタリングすること、
上記コンピューティングシステムの１または複数のコンピューティングリソースを１または複数の共有リソースにパーティショニングすることであって、上記複数の関数の各関数は、上記１または複数の共有リソースへのアクセスを有する、パーティショニングすること、
上記複数の関数を実行するために１または複数のコンピューティングリソースを割り当てるスケジューリングを提供することであって、上記スケジューリングは、少なくとも、上記コンピューティングシステムによって実行される関数の履歴ベースのリソーススケジューリングに基づいて生成される、提供すること、
上記１または複数の関数のデータを、選択されたコンピューティングデバイスへ実行のためにリダイレクトすること、
上記１または複数の関数に関連するサービスレベルパラメータに従って上記複数の関数のうち１または複数の関数を選択すること、
選択された上記１または複数の関数を、実行のために、組み合わされた関数に組み合わせること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目３） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
上記複数の関数のうち第２関数を呼び出すためのトリガエージェントを受信することであって、上記第２関数は、上記複数の関数のうちの現在実行されている関数の後に実行される、受信すること、
上記第２関数の呼び出しについての準備完了を示すために、フィードバックを上記トリガエージェントに提供すること、
上記複数の関数のうちの関数がマルチテナント高速化関数であることに応じて、上記関数の１または複数のバージョンを開始すること、
上記複数の関数の上記実行に関連付けられる実行動作の間の同期を提供することであって、上記実行動作は、上記複数の関数に関連付けられる複数のコンピューティングデバイスおよび／またはコンテナの間で分散される、提供すること、ならびに、
基準が満たされることに応じて、上記第２関数の呼び出しをトリガすること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目４） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
上記複数の関数のうち２以上の関数の間の共有情報を識別すること、
実行のためにコールされる関数が、実行のために上記共有情報を必要とするかどうかを解析すること、および、
上記解析に基づいて、上記関数を実行環境にルーティングすること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目５） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
関数の最初の実行中に上記関数を解析すること、
上記関数の上記解析から生成された利用データを、上記関数の後続の呼び出しのためにメタデータファイルとして格納することであって、上記関数の各呼び出しは、上記関数の少なくとも１つのメタデータファイルを生成する、格納すること、
１または複数の要素に基づいて上記関数を回収することであって、上記１または複数の要素の各々は、上記関数の実行ステータスを示し、上記実行ステータスは、上記関数を回収するかどうかを示す、回収すること、および、
セキュリティポリシーを上記関数に適用することであって、上記セキュリティポリシーは、上記関数の上記実行環境に関連付けられ、上記関数の１または複数の関数のセットは、同一のセキュリティキーで符号化される、適用すること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目６） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
上記複数の関数のうちの関数の、１または複数のコンピューティングリソースのニーズを識別すること、
上記関数が割り当てられたコンテナにおいて、１または複数の識別されたコンピューティングリソースを事前確保することであって、識別されたコンピューティングリソースの各々は、リソースディレクトリ識別を有する、事前確保すること、
上記関数の特定のワークロードについてコスト関数を評価するためにアクセラレータを適用すること、
データ転送または通信レイテンシを低減するために、上記事前確保されたコンピューティングリソースの間のデータ転送および通信リンクと、上記関数の呼び出しとを構築すること、および、
上記関数の上記実行に関連付けられた１または複数のサービス品質（ＱｏＳ）測定をモニタリングすることであって、少なくとも１つのＱｏＳ測定がベクトルによって定義される、モニタリングすること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目７） 上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
上記関数の実行のランタイムにおいて、１または複数の異常を検出することであって、上記１または複数の異常は、上記関数の実行の上記ランタイムにおいて、動的プロファイリング機能を使用して検出される、検出すること、
上記１または複数の異常の上記検出の結果を少なくとも１つの性能解析ツールに報告すること、および、
上記関数の上記動的プロファイリング機能に基づいて、関数のプロファイルマッピングを維持すること
を行わせる実行可能コンピュータプログラミング命令を更に含む、項目６に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目８） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
リソース特性を、実行された関数に関連付けることであって、上記関数の実行の各ステージにおいて、実行された上記関数のデマンドフィンガープリントを生成し、上記デマンドフィンガープリントは、上記関数のパラメータ、および、上記関数を呼び出す少なくとも１つのテナントに関連付けられ、上記デマンドフィンガープリントは、訓練されたシーケンス解析機械学習モデルのアプリケーションに基づいて生成される、関連付けること、
上記関数の実行の複数のステージにおける異なるリソースの利用についてのレポートを生成すること、ならびに、
生成された上記レポートに基づいて、上記関数を実行するために、上記関数にリソースを割り当てること
を行わせる実行可能コンピュータプログラミング命令を更に含む、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目９） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
フィールドのセットを戻す関数の第１呼び出しインスタンスによる第１コールを検出すること、
上記フィールドのセットの第１サブセットを識別することであって、上記第１サブセットは上記第１呼び出しインスタンスに関連付けられる、識別すること、
上記第１サブセットに基づいて、第１レスポンスオブジェクトの第１再レイアウトを実行することであって、上記第１レスポンスオブジェクトの上記第１再レイアウトは、上記第１レスポンスオブジェクトを再整列または再構成する、実行すること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目１０） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
上記複数の関数のうちの関数についてのペイロードを判定すること、および、
コンパイル時に、上記ペイロードを構築するコードを、コールするのに十分な情報を含むフォーマットでコールスタックに配置することであって、上記関数は、ローカルインスタンス、リモートインスタンス、またはハードウェアとして、上記ペイロードを介して等しく呼び出し可能である、配置すること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目１１） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
第１認証フォーマットに関して、上記複数の関数の第１関数に関連付けられる機能情報が有効であるかどうかを判定することであって、上記機能情報および上記第１認証フォーマットは上記第１関数に対応する、判定すること、
上記第１認証フォーマットに関して、上記機能情報が有効である場合、上記機能情報をキューに格納すること、および、
第２関数に対応する第２認証フォーマットに従って、上記複数の関数のうちの上記第２関数に上記機能情報を転送することであって、上記第１関数および上記第２関数はポータブル関数であり、ポータブル関数は、ポータブルアイデンティティを有し、ロードバランサによって上記コンピューティングシステムの全体にわたって動的に移動可能であり、上記機能情報は、階層符号化インライン機能およびユーザレベル割込みを含む、転送すること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目１２） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
キー識別子を第１キーにマッピングすることであって、上記第１キーは、第１関数、および、上記第１キーで暗号化される第１メモリ領域に関連付けられる、マッピングすること、
上記第１関数から、第２関数ヘのコンテキストスイッチを検出すること、ならびに、
上記コンテキストスイッチに応じて、上記キー識別子を第２キーにマッピングすること
を行わせ、
上記第２キーは、上記第２関数、および、上記第２キーで暗号化される第２メモリ領域に関連付けられ、
上記第１メモリ領域および上記第２メモリ領域は線形アドレス範囲を共有し、
上記第１キーは、第１ターゲットドメインの公開鍵であり、上記第２キーは、第２ターゲットドメインの公開鍵であり、上記第１ターゲットドメインまたは上記第２ターゲットドメインの１または複数は、信頼ドメインのサブドメインである、
項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目１３） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
上記複数の関数のうちの関数のセットに関して、不十分な数の保護キー識別子を検出すること、
上記不十分な数の保護キー識別子に応じて、ページテーブルエントリを更新するようにホストコンピューティングデバイスに命令することであって、上記関数のセットは、マネージドランタイム関数に限定される、命令すること、および、
上記関数のセットのアトミック実行を実施すること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目１４） 上記実行可能コンピュータプログラミング命令は、上記コンピューティングシステムによって実行されるとき、上記コンピューティングシステムに、
ソフトウェアスレッドがハードウェア論理スレッドで実行しているかどうかを判定すること、
上記ソフトウェアスレッドが上記ハードウェア論理スレッドで実行している場合、タグをレジスタにスワップすること、ならびに、
上記タグについて、キャッシュ容量およびメモリ帯域幅の少なくとも１つを設定すること
を行わせる、項目１に記載の少なくとも１つのコンピュータ可読記憶媒体。
（項目１５） 半導体装置であって、
１または複数の基板と、
上記１または複数の基板に連結されたロジックと
を備え、上記ロジックは、構成可能ロジックまたは機能固定型ハードウェアロジックのうち１または複数に少なくとも部分的に実装され、上記１または複数の基板に連結された上記ロジックは、
１または複数のイベントが複数のユーザから受信されたことに応じて、前記コンピューティングシステムにおける１または複数のアーキテクチャサブシステム上で複数の関数を実行することであって、上記１または複数アーキテクチャサブシステムは、上記複数の関数、および、上記複数の関数に関連付けられる複数のコンテナについての実行環境の抽象化を表す、実行すること、
上記コンピューティングシステムにおける１または複数のソフトウェアおよびオーケストレーションサブシステムによる上記複数の関数の実行を促進するために、上記コンピューティングシステムの複数のコンピューティングリソースを割り当て、前記複数のコンピューティングリソースを割り当て、上記複数の関数に関連付けられる複数のパラメータ、および、上記複数のコンピューティングリソースに関連付けられる複数のパラメータを解析すること、
上記複数の関数と、上記複数の関数およびコンピューティングリソースに関連付けられる上記複数のパラメータの解析とを、上記コンピューティングシステムにおける１または複数のネットワーキングおよびストレージサブシステムに格納することであって、上記複数の関数、および、上記複数のパラメータの上記解析を格納するための位置が、上記複数の関数と、対応する上記複数のコンピューティングリソースとの間の局所性を強化し、関数実行レイテンシを低減するために選択される、格納すること、ならびに、
上記コンピューティングシステムにおける１または複数のセキュリティサブシステムによって、上記複数の関数の上記実行を保護すること
を行う、半導体装置。
（項目１６） 上記１または複数の基板に連結される上記ロジックは、
上記複数の関数のうち１または複数の関数の上記実行をモニタリングすること、
上記コンピューティングシステムの１または複数のコンピューティングリソースを１または複数の共有リソースにパーティショニングすることであって、上記複数の関数の各関数は、上記１または複数の共有リソースへのアクセスを有する、パーティショニングすること、
上記複数の関数を実行するために１または複数のコンピューティングリソースを割り当てるスケジューリングを提供することであって、上記スケジューリングは、少なくとも、上記コンピューティングシステムによって実行される関数の履歴ベースのリソーススケジューリングに基づいて生成される、提供すること、
上記１または複数の関数のデータを、選択されたコンピューティングデバイスへ実行のためにリダイレクトすること、
上記１または複数の関数に関連付けられるサービスレベルパラメータに従って、上記複数の関数のうち１または複数の関数を選択すること、
選択された上記１または複数の関数を、実行のために、組み合わされた関数に組み合わせること
を行う、項目１５に記載の半導体装置。
（項目１７） 上記１または複数の基板に連結される上記ロジックは、
上記複数の関数のうち第２関数を呼び出すためのトリガエージェントを受信することであって、上記第２関数は、上記複数の関数のうちの現在実行されている関数の後に実行される、受信すること、
上記第２関数の呼び出しについての準備完了を示すために、フィードバックを上記トリガエージェントに提供すること、
上記複数の関数のうちの関数がマルチテナント高速化関数であることに応じて、上記関数の１または複数のバージョンを開始すること、
上記複数の関数の上記実行に関連付けられる実行動作の間の同期を提供することであって、上記実行動作は、上記複数の関数に関連付けられる複数のコンピューティングデバイスおよび／またはコンテナの間で分散される、提供すること、ならびに、
基準が満たされることに応じて、上記第２関数の呼び出しをトリガすること
を行う、項目１５に記載の半導体装置。
（項目１８） 上記１または複数の基板に連結された上記ロジックは、
上記複数の関数のうち２以上の関数の間の共有情報を識別すること、
実行のためにコールされる関数が、実行のために上記共有情報を必要とするかどうかを解析すること、および、
上記解析に基づいて、上記関数を実行環境にルーティングすること
を行う、項目１５に記載の半導体装置。
（項目１９） 上記１または複数の基板に連結された上記ロジックは、
関数の最初の実行中に上記関数を解析すること、
上記関数の上記解析から生成された利用データを、上記関数の後続の呼び出しのためにメタデータファイルとして格納することであって、上記関数の各呼び出しは、上記関数の少なくとも１つのメタデータファイルを生成する、格納すること
１または複数の要素に基づいて上記関数を回収することであって、上記１または複数の要素の各々は、上記関数の実行ステータスを示し、上記実行ステータスは、上記関数を回収するかどうかを示す、回収すること、および、
セキュリティポリシーを上記関数に適用することであって、上記セキュリティポリシーは、上記関数の上記実行環境に関連付けられ、上記関数の１または複数の関数のセットは、同一のセキュリティキーで符号化される、適用すること
を行う、項目１５に記載の半導体装置。
（項目２０） 上記１または複数の基板に連結される上記ロジックは、
上記複数の関数のうちの関数の、１または複数のコンピューティングリソースニーズを識別すること、
上記関数が割り当てられたコンテナにおいて、１または複数の識別されたコンピューティングリソースを事前確保することであって、識別されたコンピューティングリソースの各々は、リソースディレクトリ識別を有する、事前確保すること、
上記関数の特定のワークロードについてコスト関数を評価するためにアクセラレータを適用すること、
データ転送または通信レイテンシを低減するために、前記事前確保されたコンピューティングリソースの間のデータ転送および通信リンクと、前記関数の呼び出しとを構築すること、および、
上記関数の上記実行に関連付けられた１または複数のサービス品質（ＱｏＳ）測定をモニタリングすることであって、少なくとも１つのＱｏＳ測定がベクトルによって定義される、モニタリングすること
を行わせる、項目１５に記載の半導体装置。
（項目２１） 上記１または複数の基板に連結された上記ロジックは、
上記関数の実行のランタイムにおいて、１または複数の異常を検出することであって、上記１または複数の異常は、上記関数の実行の上記ランタイムにおいて、動的プロファイリング機能を使用して検出される、検出すること、
上記１または複数の異常の上記検出の結果を少なくとも１つの性能解析ツールに報告すること、および、
上記関数の上記動的プロファイリング機能に基づいて、関数のプロファイルマッピングを維持すること
を行う、項目２０に記載の半導体装置。
（項目２２） 上記１または複数の基板に連結される上記ロジックは、
リソース特性を、実行された関数に関連付け、上記関数の実行の各ステージにおいて、実行された上記関数のデマンドフィンガープリントを生成することであって、上記デマンドフィンガープリントは、上記関数のパラメータ、および、上記関数を呼び出す少なくとも１つのテナントに関連付けられ、上記デマンドフィンガープリントは、訓練されたシーケンス解析機械学習モデルのアプリケーションに基づいて生成される、生成すること、
上記関数の実行の複数のステージにおける異なるリソースの利用についてのレポートを生成すること、ならびに、
生成された上記レポートに基づいて、上記関数を実行するために、上記関数にリソースを割り当てること
を行う、項目１５に記載の半導体装置。
（項目２３） 上記１または複数の基板に連結された上記ロジックは、
フィールドのセットを戻す関数の第１呼び出しインスタンスによる第１コールを検出すること、
上記フィールドのセットの第１サブセットを識別することであって、上記第１サブセットは上記第１呼び出しインスタンスに関連付けられる、識別すること、および、
上記第１サブセットに基づいて、第１レスポンスオブジェクトの第１再レイアウトを実行することであって、上記第１レスポンスオブジェクトの上記再レイアウトは、上記第１レスポンスオブジェクトを再整列または再構成する、実行すること
を行う、項目１５に記載の半導体装置。
（項目２４） 上記１または複数の基板に連結される上記ロジックは、
上記複数の関数のうちの関数についてのペイロードを判定すること、および、
コンパイル時に、上記ペイロードを構築するコードを、コールするのに十分な情報を含むフォーマットでコールスタックに配置することであって、上記関数は、ローカルインスタンス、リモートインスタンス、またはハードウェアとして、上記ペイロードを介して等しく呼び出し可能である、配置すること
を行う、項目１５に記載の半導体装置。
（項目２５） 上記１または複数の基板に連結された上記ロジックは、
第１認証フォーマットに関して、上記複数の関数の第１関数に関連付けられる機能情報が有効かどうかを判定し、上記機能情報および上記第１認証フォーマットは、上記第１関数に対応する、判定すること、
上記第１認証フォーマットに関して、上記機能情報が有効である場合、上記機能情報をキューに格納すること、ならびに、
第２関数に対応する第２認証フォーマットに従って、上記複数の関数の上記第２関数へ上記機能情報を転送することであって、上記第１関数および上記第２関数はポータブル関数であり、ポータブル関数は、ポータブルアイデンティティを有し、かつ、ロードバランサによって、上記コンピューティングシステムの全体にわたって動的に移動可能であり、上記機能情報は、階層符号化インライン機能およびユーザレベル割込みを含む、転送すること
を行う、項目１５に記載の半導体装置。
（項目２６） 上記１または複数の基板に連結される上記ロジックは、
キー識別子を第１キーにマッピングすることであって、上記第１キーは、第１関数、および、上記第１キーで暗号化される第１メモリ領域に関連付けられる、マッピングすること、
上記第１関数から、第２関数ヘのコンテキストスイッチを検出すること、ならびに、
上記コンテキストスイッチに応じて、上記キー識別子を第２キーにマッピングすること
を行い、
上記第２キーは、上記第２関数、および、上記第２キーで暗号化される第２メモリ領域に関連付けられ、
上記第１メモリ領域および上記第２メモリ領域は線形アドレス範囲を共有し、
上記第１キーは、第１ターゲットドメインの公開鍵であり、上記第２キーは、第２ターゲットドメインの公開鍵であり、上記第１ターゲットドメインまたは上記第２ターゲットドメインの１または複数は、信頼ドメインのサブドメインである、
項目１５に記載の半導体装置。
（項目２７） 上記１または複数の基板に連結された上記ロジックは、
上記複数の関数のうちの関数のセットに関して、不十分な数の保護キー識別子を検出すること、
上記不十分な数の保護キー識別子に応じて、ページテーブルエントリを更新するようにホストコンピューティングデバイスに命令することであって、上記関数のセットは、マネージドランタイム関数に限定される、命令すること、および、
上記関数のセットのアトミック実行を実施すること
を行う、項目１５に記載の半導体装置。
（項目２８） 上記１または複数の基板に連結された上記ロジックは、
ソフトウェアスレッドがハードウェア論理スレッドで実行しているかどうかを判定すること、
上記ソフトウェアスレッドが上記ハードウェア論理スレッドで実行している場合、タグをレジスタにスワップすること、ならびに、
上記タグについて、キャッシュ容量およびメモリ帯域幅の少なくとも１つを設定すること
を行う、項目１５に記載の半導体装置。
（項目２９） システムであって、
メモリと、上記メモリに連結されたプロセッサとを備え、上記プロセッサは、
１または複数のイベントが上記複数のユーザから受信されたことに応じて、コンピューティングシステムにおける１または複数のアーキテクチャサブシステム上で複数の関数を実行することであって、上記１または複数アーキテクチャサブシステムは、上記複数の関数、および、上記複数の関数に関連付けられる複数のコンテナについての実行環境の抽象化を表す、実行すること、
上記コンピューティングシステムにおける１または複数のソフトウェアおよびオーケストレーションサブシステムによる複数の関数の実行を促進するために、上記コンピューティングシステムの複数のコンピューティングリソースを割り当て、複数のコンピューティングリソースを割り当て、上記複数の関数に関連付けられる複数のパラメータ、および、上記複数のコンピューティングリソースに関連付けられる複数のパラメータを解析すること、
上記複数の関数と、上記複数の関数および上記コンピューティングリソースに関連付けられる上記複数のパラメータの解析とを、上記コンピューティングシステムにおける１または複数のネットワーキングおよびストレージサブシステムに格納することであって、上記複数の関数、および、上記複数のパラメータの上記解析を格納するための位置が、上記複数の関数と、対応する上記複数のコンピューティングリソースとの間の局所性を強化し、関数実行レイテンシを低減するために選択される、格納すること、ならびに、
上記コンピューティングシステムにおける１または複数のセキュリティサブシステムによって、上記複数の関数の上記実行を保護すること
を行うロジックを含む、システム。
（項目３０） 方法であって、
１または複数のイベントが上記複数のユーザから受信されたことに応じて、コンピューティングシステムにおける１または複数のアーキテクチャサブシステム上で複数の関数を実行する段階であって、上記１または複数アーキテクチャサブシステムは、上記複数の関数、および、上記複数の関数に関連付けられる複数のコンテナについての実行環境の抽象化を表す、実行する段階と、
上記コンピューティングシステムにおける１または複数のソフトウェアおよびオーケストレーションサブシステムによる複数の関数の実行を促進するために、上記コンピューティングシステムの複数のコンピューティングリソースを割り当て、複数のコンピューティングリソースを割り当て、上記複数の関数に関連付けられる複数のパラメータ、および、上記複数のコンピューティングリソースに関連付けられる複数のパラメータを解析する段階と、
上記複数の関数と、上記複数の関数およびコンピューティングリソースに関連付けられる上記複数のパラメータの解析とを、上記コンピューティングシステムにおける１または複数のネットワーキングおよびストレージサブシステムに格納する段階であって、上記複数の関数、および、上記複数のパラメータの上記解析を格納するための位置が、上記複数の関数と、対応する上記複数のコンピューティングリソースとの間の局所性を強化し、関数実行レイテンシを低減するために選択される、格納する段階と、
上記コンピューティングシステムにおける１または複数のセキュリティサブシステムによって、上記複数の関数の上記実行を保護する段階と
を含む方法。

Claims (31)

  1. 複数のユーザに強化ファンクションアズアサービス（ＦａａＳ）を提供するためのプログラムであって、コンピュータに以下の手順、すなわち、
    １または複数のイベントが前記複数のユーザから受信されたことに応じて、前記コンピュータにおける１または複数のアーキテクチャサブシステム上で複数の関数を実行する手順であって、前記１または複数アーキテクチャサブシステムは、前記複数の関数、および、前記複数の関数に関連付けられる複数のコンテナについての実行環境の抽象化を表す、手順と、
    前記コンピュータにおける１または複数のソフトウェアおよびオーケストレーションサブシステムによる前記複数の関数の実行を促進するために、前記コンピュータの複数のコンピューティングリソースを割り当てる手順と、
    前記複数の関数に関連付けられる複数のパラメータ、および、前記複数のコンピューティングリソースに関連付けられる複数のパラメータを解析する手順と、
    前記複数の関数と、前記複数の関数および前記複数のコンピューティングリソースに関連付けられる前記複数のパラメータの解析とを、前記コンピュータにおける１または複数のネットワーキングおよびストレージサブシステムに格納する手順であって、前記複数の関数、および、前記複数のパラメータの前記解析を格納するための位置が、前記複数の関数と、対応する前記複数のコンピューティングリソースとの間の局所性を強化し、関数実行レイテンシを低減するために選択される、手順と、
    前記コンピュータにおける１または複数のセキュリティサブシステムによって、前記複数の関数の前記実行を保護する手順と
    を実行させるプログラム。
  2. 前記複数の関数のうち１または複数の関数の前記実行をモニタリングする手順と、
    前記コンピュータの１または複数のコンピューティングリソースを１または複数の共有リソースにパーティショニングする手順であって、前記複数の関数の各関数は、前記１または複数の共有リソースへのアクセスを有する、手順と、
    前記複数の関数を実行するために１または複数のコンピューティングリソースを割り当てるスケジューリングを提供する手順であって、前記スケジューリングは、少なくとも、前記コンピュータによって実行される関数の履歴ベースのリソーススケジューリングに基づいて生成される、手順と、
    前記１または複数の関数のデータを、選択されたコンピューティングデバイスへ実行のためにリダイレクトする手順と、
    前記１または複数の関数に関連するサービスレベルパラメータに従って前記複数の関数のうち１または複数の関数を選択する手順と、
    選択された前記１または複数の関数を、実行のために、組み合わされた関数に組み合わせる手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  3. 前記複数の関数のうち第２関数を呼び出すためのトリガエージェントを受信する手順であって、前記第２関数は、前記複数の関数のうちの現在実行されている関数の後に実行される、手順と、
    前記第２関数の呼び出しについての準備完了を示すために、フィードバックを前記トリガエージェントに提供する手順と、
    前記複数の関数のうちの関数がマルチテナント高速化関数であることに応じて、前記関数の１または複数のバージョンを開始する手順と、
    前記複数の関数の前記実行に関連付けられる実行動作の間の同期を提供する手順であって、前記実行動作は、前記複数の関数に関連付けられる複数のコンピューティングデバイスおよび／またはコンテナの間で分散される、手順と、
    基準が満たされることに応じて、前記第２関数の呼び出しをトリガする手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  4. 前記複数の関数のうち２以上の関数の間の共有情報を識別する手順と、
    実行のためにコールされる関数が、実行のために前記共有情報を必要とするかどうかを解析する手順と、
    前記解析に基づいて、前記関数を実行環境にルーティングする手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  5. 関数の最初の実行中に前記関数を解析する手順と、
    前記関数の前記解析から生成された利用データを、前記関数の後続の呼び出しのためにメタデータファイルとして格納する手順であって、前記関数の各呼び出しは、前記関数の少なくとも１つのメタデータファイルを生成する、手順と、
    １または複数の要素に基づいて前記関数を回収する手順であって、前記１または複数の要素の各々は、前記関数の実行ステータスを示し、前記実行ステータスは、前記関数を回収するかどうかを示す、手順と
    セキュリティポリシーを前記関数に適用する手順であって、前記セキュリティポリシーは、前記関数の前記実行環境に関連付けられ、前記関数の１または複数の関数のセットは、同一のセキュリティキーで符号化される、手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  6. 前記複数の関数のうちの関数の、１または複数のコンピューティングリソースのニーズを識別する手順と、
    前記関数が割り当てられたコンテナにおいて、１または複数の識別されたコンピューティングリソースを事前確保する手順であって、識別されたコンピューティングリソースの各々は、リソースディレクトリ識別を有する、手順と、
    前記関数の特定のワークロードについてコスト関数を評価するためにアクセラレータを適用する手順と、
    データ転送または通信レイテンシを低減するために、前記事前確保されたコンピューティングリソースの間のデータ転送および通信リンクと、前記関数の呼び出しとを構築する手順と、
    前記関数の前記実行に関連付けられた１または複数のサービス品質（ＱｏＳ）測定をモニタリングする手順であって、少なくとも１つのＱｏＳ測定がベクトルによって定義される、手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  7. 前記関数の実行のランタイムにおいて、１または複数の異常を検出する手順であって、前記１または複数の異常は、前記関数の実行の前記ランタイムにおいて、動的プロファイリング機能を使用して検出される、手順と、
    前記１または複数の異常の前記検出の結果を少なくとも１つの性能解析ツールに報告する手順と、
    前記関数の前記動的プロファイリング機能に基づいて、関数のプロファイルマッピングを維持する手順と
    を前記コンピュータに更に実行させる、請求項６に記載のプログラム。
  8. リソース特性を、実行された関数に関連付ける手順であって、前記関数の実行の各ステージにおいて、実行された前記関数のデマンドフィンガープリントを生成し、前記デマンドフィンガープリントは、前記関数のパラメータ、および、前記関数を呼び出す少なくとも１つのテナントに関連付けられ、前記デマンドフィンガープリントは、訓練されたシーケンス解析機械学習モデルのアプリケーションに基づいて生成される、手順と、
    前記関数の実行の複数のステージにおける異なるリソースの利用についてのレポートを生成する手順と、
    生成された前記レポートに基づいて、前記関数を実行するために、前記関数にリソースを割り当てる手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  9. フィールドのセットを戻す関数の第１呼び出しインスタンスによる第１コールを検出すること、
    前記フィールドのセットの第１サブセットを識別する手順であって、前記第１サブセットは前記第１呼び出しインスタンスに関連付けられる、手順と、
    前記第１サブセットに基づいて、第１レスポンスオブジェクトの第１再レイアウトを実行する手順であって、前記第１レスポンスオブジェクトの前記第１再レイアウトは、前記第１レスポンスオブジェクトを再整列または再構成する、手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  10. 前記複数の関数のうちの関数についてのペイロードを判定する手順と、
    コンパイル時に、前記ペイロードを構築するコードを、コールするのに十分な情報を含むフォーマットでコールスタックに配置する手順であって、前記関数は、ローカルインスタンス、リモートインスタンス、またはハードウェアとして、前記ペイロードを介して等しく呼び出し可能である、手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  11. 第１認証フォーマットに関して、前記複数の関数の第１関数に関連付けられる機能情報が有効であるかどうかを判定する手順であって、前記機能情報および前記第１認証フォーマットは前記第１関数に対応する、手順と、
    前記第１認証フォーマットに関して、前記機能情報が有効である場合、前記機能情報をキューに格納する手順と、
    第２関数に対応する第２認証フォーマットに従って、前記複数の関数のうちの前記第２関数に前記機能情報を転送する手順であって、前記第１関数および前記第２関数はポータブル関数であり、ポータブル関数は、ポータブルアイデンティティを有し、ロードバランサによって前記コンピュータの全体にわたって動的に移動可能であり、前記機能情報は、階層符号化インライン機能およびユーザレベル割込みを含む、手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  12. キー識別子を第１キーにマッピングする手順であって、前記第１キーは、第１関数、および、前記第１キーで暗号化される第１メモリ領域に関連付けられる、手順と、
    前記第１関数から、第２関数ヘのコンテキストスイッチを検出する手順と、
    前記コンテキストスイッチに応じて、前記キー識別子を第２キーにマッピングする手順と
    を前記コンピュータに実行させ、
    前記第２キーは、前記第２関数、および、前記第２キーで暗号化される第２メモリ領域に関連付けられ、
    前記第１メモリ領域および前記第２メモリ領域は線形アドレス範囲を共有し、
    前記第１キーは、第１ターゲットドメインの鍵であり、前記第２キーは、第２ターゲットドメインの鍵であり、前記第１ターゲットドメインまたは前記第２ターゲットドメインの１または複数は、信頼ドメインのサブドメインである、
    請求項１に記載のプログラム。
  13. 前記複数の関数のうちの関数のセットに関して、不十分な数の保護キー識別子を検出する手順と、
    前記不十分な数の保護キー識別子に応じて、ページテーブルエントリを更新するようにホストコンピューティングデバイスに命令する手順であって、前記関数のセットは、マネージドランタイム関数に限定される、手順と、
    前記関数のセットのアトミック実行を実施する手順と
    を前記コンピュータに実行させる、請求項１に記載のプログラム。
  14. ソフトウェアスレッドがハードウェア論理スレッドで実行しているかどうかを判定する手順と、
    前記ソフトウェアスレッドが前記ハードウェア論理スレッドで実行している場合、タグをレジスタにスワップする手順と、
    前記タグについて、キャッシュ容量およびメモリ帯域幅の少なくとも１つを設定する手順と
    を前記コンピュータに実行させる、請求項１から１３のいずれか一項に記載のプログラム。
  15. 請求項１から１４のいずれか一項に記載のプログラムを含むコンピュータ可読記憶媒体。
  16. 半導体装置であって、
    １または複数の基板と、
    前記１または複数の基板に連結されたロジックと
    を備え、前記ロジックは、構成可能ロジックまたは機能固定型ハードウェアロジックのうち１または複数に少なくとも部分的に実装され、前記１または複数の基板に連結された前記ロジックは、
    １または複数のイベントが複数のユーザから受信されたことに応じて、コンピューティングシステムにおける１または複数のアーキテクチャサブシステム上で複数の関数を実行することであって、前記１または複数アーキテクチャサブシステムは、前記複数の関数、および、前記複数の関数に関連付けられる複数のコンテナについての実行環境の抽象化を表す、実行すること、
    前記コンピューティングシステムにおける１または複数のソフトウェアおよびオーケストレーションサブシステムによる前記複数の関数の実行を促進するために、前記コンピューティングシステムの複数のコンピューティングリソースを割り当てること、
    前記複数の関数に関連付けられる複数のパラメータ、および、前記複数のコンピューティングリソースに関連付けられる複数のパラメータを解析すること、
    前記複数の関数と、前記複数の関数およびコンピューティングリソースに関連付けられる前記複数のパラメータの解析とを、前記コンピューティングシステムにおける１または複数のネットワーキングおよびストレージサブシステムに格納することであって、前記複数の関数、および、前記複数のパラメータの前記解析を格納するための位置が、前記複数の関数と、対応する前記複数のコンピューティングリソースとの間の局所性を強化し、関数実行レイテンシを低減するために選択される、格納すること、ならびに、
    前記コンピューティングシステムにおける１または複数のセキュリティサブシステムによって、前記複数の関数の前記実行を保護すること
    を行う、半導体装置。
  17. 前記１または複数の基板に連結される前記ロジックは、
    前記複数の関数のうち１または複数の関数の前記実行をモニタリングすること、
    前記コンピューティングシステムの１または複数のコンピューティングリソースを１または複数の共有リソースにパーティショニングすることであって、前記複数の関数の各関数は、前記１または複数の共有リソースへのアクセスを有する、パーティショニングすること、
    前記複数の関数を実行するために１または複数のコンピューティングリソースを割り当てるスケジューリングを提供することであって、前記スケジューリングは、少なくとも、前記コンピューティングシステムによって実行される関数の履歴ベースのリソーススケジューリングに基づいて生成される、提供すること、
    前記１または複数の関数のデータを、選択されたコンピューティングデバイスへ実行のためにリダイレクトすること、
    前記１または複数の関数に関連付けられるサービスレベルパラメータに従って、前記複数の関数のうち１または複数の関数を選択すること、
    選択された前記１または複数の関数を、実行のために、組み合わされた関数に組み合わせること
    を行う、請求項１６に記載の半導体装置。
  18. 前記１または複数の基板に連結される前記ロジックは、
    前記複数の関数のうち第２関数を呼び出すためのトリガエージェントを受信することであって、前記第２関数は、前記複数の関数のうちの現在実行されている関数の後に実行される、受信すること、
    前記第２関数の呼び出しについての準備完了を示すために、フィードバックを前記トリガエージェントに提供すること、
    前記複数の関数のうちの関数がマルチテナント高速化関数であることに応じて、前記関数の１または複数のバージョンを開始すること、
    前記複数の関数の前記実行に関連付けられる実行動作の間の同期を提供することであって、前記実行動作は、前記複数の関数に関連付けられる複数のコンピューティングデバイスおよび／またはコンテナの間で分散される、提供すること、ならびに、
    基準が満たされることに応じて、前記第２関数の呼び出しをトリガすること
    を行う、請求項１６に記載の半導体装置。
  19. 前記１または複数の基板に連結された前記ロジックは、
    前記複数の関数のうち２以上の関数の間の共有情報を識別すること、
    実行のためにコールされる関数が、実行のために前記共有情報を必要とするかどうかを解析すること、および、
    前記解析に基づいて、前記関数を実行環境にルーティングすること
    を行う、請求項１６に記載の半導体装置。
  20. 前記１または複数の基板に連結された前記ロジックは、
    関数の最初の実行中に前記関数を解析すること、
    前記関数の前記解析から生成された利用データを、前記関数の後続の呼び出しのためにメタデータファイルとして格納することであって、前記関数の各呼び出しは、前記関数の少なくとも１つのメタデータファイルを生成する、格納すること
    １または複数の要素に基づいて前記関数を回収することであって、前記１または複数の要素の各々は、前記関数の実行ステータスを示し、前記実行ステータスは、前記関数を回収するかどうかを示す、回収すること、および、
    セキュリティポリシーを前記関数に適用することであって、前記セキュリティポリシーは、前記関数の前記実行環境に関連付けられ、前記関数の１または複数の関数のセットは、同一のセキュリティキーで符号化される、適用すること
    を行う、請求項１６に記載の半導体装置。
  21. 前記１または複数の基板に連結される前記ロジックは、
    前記複数の関数のうちの関数の、１または複数のコンピューティングリソースニーズを識別すること、
    前記関数が割り当てられたコンテナにおいて、１または複数の識別されたコンピューティングリソースを事前確保することであって、識別されたコンピューティングリソースの各々は、リソースディレクトリ識別を有する、事前確保すること、
    前記関数の特定のワークロードについてコスト関数を評価するためにアクセラレータを適用すること、
    データ転送または通信レイテンシを低減するために、前記事前確保されたコンピューティングリソースの間のデータ転送および通信リンクと、前記関数の呼び出しとを構築すること、および、
    前記関数の前記実行に関連付けられた１または複数のサービス品質（ＱｏＳ）測定をモニタリングすることであって、少なくとも１つのＱｏＳ測定がベクトルによって定義される、モニタリングすること
    を行わせる、請求項１６に記載の半導体装置。
  22. 前記１または複数の基板に連結された前記ロジックは、
    前記関数の実行のランタイムにおいて、１または複数の異常を検出することであって、前記１または複数の異常は、前記関数の実行の前記ランタイムにおいて、動的プロファイリング機能を使用して検出される、検出すること、
    前記１または複数の異常の前記検出の結果を少なくとも１つの性能解析ツールに報告すること、および、
    前記関数の前記動的プロファイリング機能に基づいて、関数のプロファイルマッピングを維持すること
    を行う、請求項２１に記載の半導体装置。
  23. 前記１または複数の基板に連結される前記ロジックは、
    リソース特性を、実行された関数に関連付け、前記関数の実行の各ステージにおいて、実行された前記関数のデマンドフィンガープリントを生成することであって、前記デマンドフィンガープリントは、前記関数のパラメータ、および、前記関数を呼び出す少なくとも１つのテナントに関連付けられ、前記デマンドフィンガープリントは、訓練されたシーケンス解析機械学習モデルのアプリケーションに基づいて生成される、生成すること、
    前記関数の実行の複数のステージにおける異なるリソースの利用についてのレポートを生成すること、ならびに、
    生成された前記レポートに基づいて、前記関数を実行するために、前記関数にリソースを割り当てること
    を行う、請求項１６に記載の半導体装置。
  24. 前記１または複数の基板に連結された前記ロジックは、
    フィールドのセットを戻す関数の第１呼び出しインスタンスによる第１コールを検出すること、
    前記フィールドのセットの第１サブセットを識別することであって、前記第１サブセットは前記第１呼び出しインスタンスに関連付けられる、識別すること、および、
    前記第１サブセットに基づいて、第１レスポンスオブジェクトの第１再レイアウトを実行することであって、前記第１レスポンスオブジェクトの前記第１再レイアウトは、前記第１レスポンスオブジェクトを再整列または再構成する、実行すること
    を行う、請求項１６に記載の半導体装置。
  25. 前記１または複数の基板に連結される前記ロジックは、
    前記複数の関数のうちの関数についてのペイロードを判定すること、および、
    コンパイル時に、前記ペイロードを構築するコードを、コールするのに十分な情報を含むフォーマットでコールスタックに配置することであって、前記関数は、ローカルインスタンス、リモートインスタンス、またはハードウェアとして、前記ペイロードを介して等しく呼び出し可能である、配置すること
    を行う、請求項１６に記載の半導体装置。
  26. 前記１または複数の基板に連結された前記ロジックは、
    第１認証フォーマットに関して、前記複数の関数の第１関数に関連付けられる機能情報が有効かどうかを判定し、前記機能情報および前記第１認証フォーマットは、前記第１関数に対応する、判定すること、
    前記第１認証フォーマットに関して、前記機能情報が有効である場合、前記機能情報をキューに格納すること、ならびに、
    第２関数に対応する第２認証フォーマットに従って、前記複数の関数の前記第２関数へ前記機能情報を転送することであって、前記第１関数および前記第２関数はポータブル関数であり、ポータブル関数は、ポータブルアイデンティティを有し、かつ、ロードバランサによって、前記コンピューティングシステムの全体にわたって動的に移動可能であり、前記機能情報は、階層符号化インライン機能およびユーザレベル割込みを含む、転送すること
    を行う、請求項１６に記載の半導体装置。
  27. 前記１または複数の基板に連結される前記ロジックは、
    キー識別子を第１キーにマッピングすることであって、前記第１キーは、第１関数、および、前記第１キーで暗号化される第１メモリ領域に関連付けられる、マッピングすること、
    前記第１関数から、第２関数ヘのコンテキストスイッチを検出すること、ならびに、
    前記コンテキストスイッチに応じて、前記キー識別子を第２キーにマッピングすること
    を行い、
    前記第２キーは、前記第２関数、および、前記第２キーで暗号化される第２メモリ領域に関連付けられ、
    前記第１メモリ領域および前記第２メモリ領域は線形アドレス範囲を共有し、
    前記第１キーは、第１ターゲットドメインの鍵であり、前記第２キーは、第２ターゲットドメインの鍵であり、前記第１ターゲットドメインまたは前記第２ターゲットドメインの１または複数は、信頼ドメインのサブドメインである、
    請求項１６に記載の半導体装置。
  28. 前記１または複数の基板に連結された前記ロジックは、
    前記複数の関数のうちの関数のセットに関して、不十分な数の保護キー識別子を検出すること、
    前記不十分な数の保護キー識別子に応じて、ページテーブルエントリを更新するようにホストコンピューティングデバイスに命令することであって、前記関数のセットは、マネージドランタイム関数に限定される、命令すること、および、
    前記関数のセットのアトミック実行を実施すること
    を行う、請求項１６に記載の半導体装置。
  29. 前記１または複数の基板に連結された前記ロジックは、
    ソフトウェアスレッドがハードウェア論理スレッドで実行しているかどうかを判定すること、
    前記ソフトウェアスレッドが前記ハードウェア論理スレッドで実行している場合、タグをレジスタにスワップすること、ならびに、
    前記タグについて、キャッシュ容量およびメモリ帯域幅の少なくとも１つを設定すること
    を行う、請求項１６から２８のいずれか一項に記載の半導体装置。
  30. 強化ファンクションアズアサービス（ＦａａＳ）を複数のユーザに提供するためのシステムであって、
    メモリと、前記メモリに連結されたプロセッサとを備え、前記プロセッサは、
    １または複数のイベントが前記複数のユーザから受信されたことに応じて、コンピューティングシステムにおける１または複数のアーキテクチャサブシステム上で複数の関数を実行することであって、前記１または複数アーキテクチャサブシステムは、前記複数の関数、および、前記複数の関数に関連付けられる複数のコンテナについての実行環境の抽象化を表す、実行すること、
    前記コンピューティングシステムにおける１または複数のソフトウェアおよびオーケストレーションサブシステムによる前記複数の関数の実行を促進するために、前記コンピューティングシステムの複数のコンピューティングリソースを割り当てること、
    前記複数の関数に関連付けられる複数のパラメータ、および、前記複数のコンピューティングリソースに関連付けられる複数のパラメータを解析すること、
    前記複数の関数と、前記複数の関数および前記複数のコンピューティングリソースに関連付けられる前記複数のパラメータの解析とを、前記コンピューティングシステムにおける１または複数のネットワーキングおよびストレージサブシステムに格納することであって、前記複数の関数、および、前記複数のパラメータの前記解析を格納するための位置が、前記複数の関数と、対応する前記複数のコンピューティングリソースとの間の局所性を強化し、関数実行レイテンシを低減するために選択される、格納すること、ならびに、
    前記コンピューティングシステムにおける１または複数のセキュリティサブシステムによって、前記複数の関数の前記実行を保護すること
    を行うロジックを含む、システム。
  31. 複数のユーザに強化ファンクションアズアサービス（ＦａａＳ）を提供するための方法であって、
    １または複数のイベントが前記複数のユーザから受信されたことに応じて、コンピューティングシステムにおける１または複数のアーキテクチャサブシステム上で複数の関数を実行する段階であって、前記１または複数アーキテクチャサブシステムは、前記複数の関数、および、前記複数の関数に関連付けられる複数のコンテナについての実行環境の抽象化を表す、実行する段階と、
    前記コンピューティングシステムにおける１または複数のソフトウェアおよびオーケストレーションサブシステムによる前記複数の関数の実行を促進するために、前記コンピューティングシステムの複数のコンピューティングリソースを割り当てる段階と、
    前記複数の関数に関連付けられる複数のパラメータ、および、前記複数のコンピューティングリソースに関連付けられる複数のパラメータを解析する段階と、
    前記複数の関数と、前記複数の関数およびコンピューティングリソースに関連付けられる前記複数のパラメータの解析とを、前記コンピューティングシステムにおける１または複数のネットワーキングおよびストレージサブシステムに格納する段階であって、前記複数の関数、および、前記複数のパラメータの前記解析を格納するための位置が、前記複数の関数と、対応する前記複数のコンピューティングリソースとの間の局所性を強化し、関数実行レイテンシを低減するために選択される、格納する段階と、
    前記コンピューティングシステムにおける１または複数のセキュリティサブシステムによって、前記複数の関数の前記実行を保護する段階と
    を含む方法。
JP2020564381A 2018-11-08 2019-04-16 ファンクションアズアサービス（ＦａａＳ）システムの強化 Active JP7327744B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CNPCT/CN2018/114602 2018-11-08
CNPCT/CN2018/114602 2018-11-08
PCT/US2019/027659 WO2020096639A1 (en) 2018-11-08 2019-04-16 Function as a service (faas) system enhancements

Publications (2)

Publication Number Publication Date
JP2022511177A true JP2022511177A (ja) 2022-01-31
JP7327744B2 JP7327744B2 (ja) 2023-08-16

Family

ID=70612331

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020564381A Active JP7327744B2 (ja) 2018-11-08 2019-04-16 ファンクションアズアサービス（ＦａａＳ）システムの強化

Country Status (7)

Country Link
US (1) US11922220B2 (ja)
EP (1) EP3877854A4 (ja)
JP (1) JP7327744B2 (ja)
KR (1) KR20210076882A (ja)
CN (1) CN112955869A (ja)
DE (1) DE112019005604T5 (ja)
WO (1) WO2020096639A1 (ja)

Families Citing this family (121)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7734284B2 (en) 2004-04-30 2010-06-08 Research In Motion Limited System and method for handling data transfers
US10965775B2 (en) * 2012-11-20 2021-03-30 Airbnb, Inc. Discovering signature of electronic social networks
US10331479B2 (en) * 2017-01-13 2019-06-25 Microsoft Technology Licensing, Llc Computing on transient resources
US11669426B2 (en) * 2017-06-30 2023-06-06 International Business Machines Corporation Kernel-based power consumption and isolation and defense against emerging power attacks
WO2019015778A1 (en) * 2017-07-21 2019-01-24 Telefonaktiebolaget Lm Ericsson (Publ) NON-STRUCTURED DATA STORAGE FUNCTION SERVICES (UDSF)
US11947489B2 (en) 2017-09-05 2024-04-02 Robin Systems, Inc. Creating snapshots of a storage volume in a distributed storage system
US11748203B2 (en) 2018-01-11 2023-09-05 Robin Systems, Inc. Multi-role application orchestration in a distributed storage system
GB2573119A (en) * 2018-04-24 2019-10-30 Advanced Risc Mach Ltd Maintaining state of speculation
US11385940B2 (en) 2018-10-26 2022-07-12 EMC IP Holding Company LLC Multi-cloud framework for microservice-based applications
US20220004422A1 (en) * 2018-12-05 2022-01-06 Telefonaktiebolaget Lm Ericsson (Publ) Method and Apparatus of Providing a Function as a Service (FAAS) Deployment of an Application
US11182206B2 (en) * 2019-01-10 2021-11-23 Vmware, Inc. Event proxies for functions-as-a-service (FAAS) infrastructures
US11640361B2 (en) 2019-03-08 2023-05-02 International Business Machines Corporation Sharing secure memory across multiple security domains
US11531627B2 (en) * 2019-03-08 2022-12-20 International Business Machines Corporation Secure storage isolation
US11487906B2 (en) 2019-03-08 2022-11-01 International Business Machines Corporation Storage sharing between a secure domain and a non-secure entity
CN113661480A (zh) * 2019-04-12 2021-11-16 瑞典爱立信有限公司 用于确定无服务器应用的云计算部署修改的技术
US10552121B1 (en) * 2019-05-07 2020-02-04 Capital One Services, Llc System and method for dynamic process flow control based on real-time events
WO2020236261A1 (en) 2019-05-23 2020-11-26 Cray Inc. Dragonfly routing with incomplete group connectivity
US11526434B1 (en) * 2019-06-25 2022-12-13 Amazon Technologies, Inc. Network-level garbage collection in an on-demand code execution system
KR20210012123A (ko) * 2019-07-24 2021-02-03 에스케이하이닉스 주식회사 메모리 시스템, 메모리 컨트롤러 및 동작 방법
US11275635B2 (en) * 2019-09-10 2022-03-15 Digitalocean Llc Method and system for managing and executing serverless functions in a messaging service
US20220277006A1 (en) * 2019-09-10 2022-09-01 Wind Jammer Technologies, LLC Disaggregated Query Processing Utilizing Precise, Parallel, Asynchronous Shared Storage Repository Access
US11507442B2 (en) * 2019-09-17 2022-11-22 Servicenow, Inc. Method and system for determining maturity level of a cloud computing service
US11669368B2 (en) * 2019-09-28 2023-06-06 Intel Corporation Multi-tenant data protection in edge computing environments
US11533317B2 (en) * 2019-09-30 2022-12-20 EMC IP Holding Company LLC Serverless application center for multi-cloud deployment of serverless applications
US11301562B2 (en) * 2019-10-23 2022-04-12 Sap Se Function execution based on data locality and securing integration flows
EP4055778B1 (en) * 2019-11-08 2023-07-12 Telefonaktiebolaget Lm Ericsson (Publ) Code activation management method for network slicing solutions, and corresponding entity, server and computer program
US11539786B2 (en) * 2019-11-19 2022-12-27 Jeff Wang Method and system for heterogeneous blockchain service management
US11593136B2 (en) * 2019-11-21 2023-02-28 Pensando Systems, Inc. Resource fairness enforcement in shared IO interfaces
JP7333748B2 (ja) * 2019-12-13 2023-08-25 株式会社日立製作所 電子機器および電子機器の攻撃検知方法
US11556820B2 (en) 2020-01-03 2023-01-17 Blackberry Limited Method and system for a dynamic data collection and context-driven actions
US11556633B2 (en) * 2020-01-03 2023-01-17 Blackberry Limited Security threat detection in hosted guest operating systems
US11748162B2 (en) * 2020-01-06 2023-09-05 EMC IP Holding Company LLC Function execution environment selection for decomposed application
CN111209084B (zh) * 2020-01-12 2022-11-15 苏州浪潮智能科技有限公司 一种faas分布式计算方法和装置
US11550513B2 (en) * 2020-01-24 2023-01-10 Vmware, Inc. Global cache for container images in a clustered container host system
US11374819B2 (en) 2020-01-31 2022-06-28 Wyze Labs, Inc. Systems and methods for creating virtual devices
US11403131B2 (en) * 2020-02-05 2022-08-02 International Business Machines Corporation Data analysis for predictive scaling of container(s) based on prior user transaction(s)
JP7324165B2 (ja) * 2020-03-18 2023-08-09 株式会社日立製作所 アプリケーション開発支援システム及びアプリケーション開発支援方法
US11875168B2 (en) * 2020-03-19 2024-01-16 Oracle International Corporation Optimizing execution of foreign method handles on a virtual machine
JP2021157339A (ja) * 2020-03-25 2021-10-07 富士通株式会社 情報処理方法、及び情報処理プログラム
US11609932B2 (en) * 2020-03-27 2023-03-21 Adp, Inc. Web services having live data updates
WO2021207269A1 (en) * 2020-04-07 2021-10-14 Assia Spe, Llc Systems and methods for remote collaboration
US11595192B2 (en) * 2020-04-24 2023-02-28 Dell Products L.P. System and method of migrating one or more storage class memories from a first information handling system to a second information handling system
US11366648B2 (en) * 2020-05-28 2022-06-21 Red Hat, Inc. Compiling monoglot function compositions into a single entity
US11921683B2 (en) * 2020-06-08 2024-03-05 Paypal, Inc. Use of time to live value during database compaction
US11316757B1 (en) * 2020-06-23 2022-04-26 Amdocs Development Limited System, method, and computer program for consumer requirement based management for physical edge deployment of an application
US20210406079A1 (en) * 2020-06-29 2021-12-30 Robin Systems, Inc. Persistent Non-Homogeneous Worker Pools
US11375042B2 (en) * 2020-07-10 2022-06-28 Kyndryl, Inc. Symphonizing serverless functions of hybrid services
US11057491B1 (en) 2020-07-17 2021-07-06 Snowflake Inc. Remote execution using a global identity
US11533217B2 (en) * 2020-07-31 2022-12-20 Hewlett Packard Enterprise Development Lp Systems and methods for predictive assurance
CN112085491B (zh) * 2020-08-31 2023-08-04 北京百度网讯科技有限公司 计费系统接入方法及云平台、电子设备、计算机可读介质
US11966765B2 (en) * 2020-09-09 2024-04-23 Nvidia Corporation Memory bandwidth throttling for virtual machines
US11740980B2 (en) 2020-09-22 2023-08-29 Robin Systems, Inc. Managing snapshot metadata following backup
US11442703B2 (en) 2020-09-22 2022-09-13 Cisco Technology, Inc. Domain-specific language for serverless network functions
US11126415B1 (en) 2020-09-22 2021-09-21 Cisco Technology, Inc. Combining domain-specific language with general-purpose language for serverless network functions
US11625230B2 (en) 2020-09-22 2023-04-11 Cisco Technology, Inc. Identifying execution environments for deploying network functions
US20220092480A1 (en) * 2020-09-24 2022-03-24 Adobe Inc. Dynamically adjusting a serverless execution container pool for training and utilizing online machine-learning models
US20210081271A1 (en) * 2020-09-25 2021-03-18 Intel Corporation Dynamic tracing control
US11743188B2 (en) 2020-10-01 2023-08-29 Robin Systems, Inc. Check-in monitoring for workflows
US20210021485A1 (en) * 2020-10-06 2021-01-21 Francesc Guim Bernat Jitter-less distributed function-as-a-service using flavor clustering
US20220114265A1 (en) * 2020-10-08 2022-04-14 Google Llc Unified viewing of roles and permissions in a computer data processing system
US11948010B2 (en) * 2020-10-12 2024-04-02 International Business Machines Corporation Tag-driven scheduling of computing resources for function execution
US11809548B2 (en) * 2020-10-22 2023-11-07 Cisco Technology, Inc. Runtime security analytics for serverless workloads
US11816484B2 (en) 2020-10-30 2023-11-14 Apple Inc. Hardware verification of dynamically generated code
US11750451B2 (en) 2020-11-04 2023-09-05 Robin Systems, Inc. Batch manager for complex workflows
US20210064531A1 (en) * 2020-11-09 2021-03-04 Francesc Guim Bernat Software-defined coherent caching of pooled memory
US11726764B2 (en) 2020-11-11 2023-08-15 Nutanix, Inc. Upgrade systems for service domains
US11665221B2 (en) 2020-11-13 2023-05-30 Nutanix, Inc. Common services model for multi-cloud platform
US11645098B2 (en) * 2020-11-17 2023-05-09 Sap Se Systems and methods to pre-provision sockets for serverless functions
CN112543116A (zh) * 2020-11-24 2021-03-23 哈尔滨工业大学 一种基于精确QoS的快速服务匹配方法
US11573818B2 (en) * 2020-11-24 2023-02-07 International Business Machines Corporation Containerized computing environments
CN112492580B (zh) * 2020-11-25 2023-08-18 北京小米移动软件有限公司 信息处理方法及装置、通信设备及存储介质
US11652688B2 (en) * 2020-11-25 2023-05-16 International Business Machines Corporation Predicting usage pattern of serverless environment via machine learning
EP4016343A1 (en) * 2020-12-17 2022-06-22 Accemic Technologies GmbH Processor arrangement for monitoring control-flow integrity
CN112596720A (zh) * 2020-12-25 2021-04-02 第四范式（北京）技术有限公司 业务运行方法、装置、电子设备和计算机存储介质
US11934854B2 (en) * 2020-12-29 2024-03-19 VMware LLC Placing virtual graphics processing unit (GPU)-configured virtual machines on physical GPUs supporting multiple virtual GPU profiles
US11604682B2 (en) * 2020-12-31 2023-03-14 EMC IP Holding Company LLC Pre-emptive container load-balancing, auto-scaling and placement
US11734277B2 (en) * 2021-02-05 2023-08-22 International Business Machines Corporation Database buffer pool optimization
US11861397B2 (en) * 2021-02-15 2024-01-02 Kyndryl, Inc. Container scheduler with multiple queues for special workloads
US11736585B2 (en) 2021-02-26 2023-08-22 Nutanix, Inc. Generic proxy endpoints using protocol tunnels including life cycle management and examples for distributed cloud native services and applications
US11615181B2 (en) 2021-03-30 2023-03-28 Netapp, Inc. Methods for managing verification and validation of third-party code and devices thereof
US11586725B2 (en) 2021-03-30 2023-02-21 Netapp, Inc. Methods for managing verification and validation of third-party code and devices thereof
US11436054B1 (en) * 2021-04-05 2022-09-06 Hewlett Packard Enterprise Development Lp Directing queries to nodes of a cluster of a container orchestration platform distributed across a host system and a hardware accelerator of the host system
US20220327246A1 (en) * 2021-04-13 2022-10-13 EMC IP Holding Company LLC Storage array data decryption
US11652652B2 (en) 2021-06-24 2023-05-16 APPDIRECT, Inc. Function as a service console for an online application exchange platform
US11444790B1 (en) * 2021-07-09 2022-09-13 International Business Machines Corporation Dynamic exclusion of RDMA-based shared memory communication based on performance-related data
US20230025994A1 (en) * 2021-07-15 2023-01-26 EMC IP Holding Company LLC Multiple virtual namespaces on a single physical namespace to avoid file system restarts and improve availability
US20230036476A1 (en) * 2021-07-28 2023-02-02 International Business Machines Corporation System and apparatus for faas business goals optimization
CN113792192B (zh) * 2021-08-09 2022-12-30 万翼科技有限公司 开源业务函数支撑系统及业务函数的控制方法
CN113656144B (zh) * 2021-08-17 2023-08-11 百度在线网络技术（北京）有限公司 一种数据发布系统、方法、装置、电子设备及存储介质
EP4353004A1 (en) * 2021-09-03 2024-04-17 NEC Laboratories Europe GmbH Ai-driven intelligent radio controller
CN113704007B (zh) * 2021-09-14 2023-11-07 上海交通大学 利用硬件特性的无服务器计算平台加速系统
CN114048405B (zh) * 2021-10-26 2024-04-09 盐城天眼察微科技有限公司 入口模板文件生成方法、装置、设备及存储介质
KR102482115B1 (ko) * 2021-11-12 2022-12-29 삼성전자주식회사 멀티-레벨 어드레스 변환을 이용한 스토리지 장치의 구동 방법 및 이를 수행하는 스토리지 장치
CN113791796B (zh) * 2021-11-15 2022-03-04 北京金山云网络技术有限公司 跨域的镜像生成方法、镜像安装方法、装置及电子设备
CN114071485B (zh) * 2021-11-15 2024-02-02 湖南亿盛通信息科技有限公司 基于不完美信道的智能反射面安全通信能效优化方法
EP4180958A1 (en) * 2021-11-16 2023-05-17 Intel Corporation Computational storage in a function-as-a-service architecture
US11442775B1 (en) * 2021-12-03 2022-09-13 FriendliAI Inc. Dynamic batching for inference system for transformer-based generation tasks
US11514370B1 (en) 2021-12-03 2022-11-29 FriendliAI Inc. Selective batching for inference system for transformer-based generation tasks
CN114390110B (zh) * 2021-12-31 2023-08-22 华南理工大学 一种带约束的可扩展资源供给的多租户系统、方法和设备
US11816341B2 (en) * 2022-01-18 2023-11-14 Dell Products, L.P. Orchestrating distribution of function as a service (FaaS) workloads to autonomous storage systems
US11729081B2 (en) * 2022-01-20 2023-08-15 International Business Machines Corporation Enhancing software application hosting in a cloud environment
US20230300086A1 (en) * 2022-01-28 2023-09-21 Vmware, Inc. On-demand resource capacity in a serverless function-as-a-service infrastructure
CN114629858A (zh) * 2022-01-30 2022-06-14 南京理工大学 Kubernetes中基于自适应处理率的网状微服务资源控制方法
CN114546563B (zh) * 2022-02-23 2023-04-28 北京京航计算通讯研究所 一种多租户页面访问控制方法和系统
US11966726B2 (en) 2022-02-25 2024-04-23 International Business Machines Corporation Operating system (OS) scheduler and compiler for code generation optimization in a (simultaneous multi-threading) SMT enabled CPU
CN114666250A (zh) * 2022-03-01 2022-06-24 中国电子科技集团公司第五十二研究所 一种保持安防软件系统中数据和状态一致性的方法
US20230283516A1 (en) * 2022-03-03 2023-09-07 National Instruments Corporation System and method for efficient data movement in an orchestrated distributed measurement application
CN115086189B (zh) * 2022-05-20 2023-11-07 中国科学院软件研究所 一种面向无服务器计算的服务资源弹性伸缩方法和系统
KR102480300B1 (ko) * 2022-05-25 2022-12-23 리벨리온 주식회사 뉴럴 프로세싱 장치 및 그의 잡 스케쥴링 방법
KR20230164549A (ko) 2022-05-25 2023-12-04 리벨리온 주식회사 뉴럴 프로세싱 장치 및 그의 잡 스케쥴링 방법
US11811681B1 (en) 2022-07-12 2023-11-07 T-Mobile Usa, Inc. Generating and deploying software architectures using telecommunication resources
US11843682B1 (en) * 2022-08-31 2023-12-12 Adobe Inc. Prepopulating an edge server cache
US11966725B2 (en) * 2022-09-14 2024-04-23 Microsoft Technology Licensing, Llc Microservice termination while maintaining high availability
KR102535011B1 (ko) * 2022-10-14 2023-05-26 주식회사 플랜티넷 마이크로서비스 기반 네트워크 디바이스 설정 적용 방법
CN115794418B (zh) * 2023-02-03 2023-04-28 蒲惠智造科技股份有限公司 一种计算资源的分配方法
CN116069414B (zh) * 2023-03-06 2023-06-09 湖北工业大学 一种电力物联网计算任务卸载激励优化方法和存储介质
CN117130771A (zh) * 2023-03-30 2023-11-28 荣耀终端有限公司 一种资源调度方法、电子设备及存储介质
CN116185668B (zh) * 2023-04-26 2023-06-30 上海帆声图像科技有限公司 一种基于grpc的高效多模型选配部署方法
CN117111904A (zh) * 2023-04-26 2023-11-24 领悦数字信息技术有限公司 用于将Web应用自动转换成无服务器函数的方法和系统
CN117097684B (zh) * 2023-10-17 2024-02-27 苏州元脑智能科技有限公司 数据传输方法及装置、存储介质、电子设备
CN117555696B (zh) * 2024-01-11 2024-03-15 西北工业大学 一种多模型并发执行的数据交互方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180034924A1 (en) * 2016-07-28 2018-02-01 Polybit Inc. System and method for a unified interface to networked webservices
US20180115551A1 (en) * 2016-10-20 2018-04-26 Brian Cole Proxy system for securely provisioning computing resources in cloud computing environment
US20180113793A1 (en) * 2016-10-25 2018-04-26 International Business Machines Corporation Facilitating debugging serverless applications via graph rewriting
US20180254998A1 (en) * 2017-03-02 2018-09-06 Alcatel Lucent Resource allocation in a cloud environment
US10121021B1 (en) * 2018-04-11 2018-11-06 Capital One Services, Llc System and method for automatically securing sensitive data in public cloud using a serverless architecture

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430570B1 (en) * 1999-03-01 2002-08-06 Hewlett-Packard Company Java application manager for embedded device
US7779127B2 (en) * 2007-03-09 2010-08-17 Hewlett-Packard Development Company, L.P. System and method for determining a subset of transactions of a computing system for use in determing resource costs
US8510759B1 (en) 2012-06-29 2013-08-13 Intel Corporation Scatter gather emulation
US9880947B2 (en) 2015-03-24 2018-01-30 Intel Corporation Return oriented programming stack pivoting protection
US10331485B2 (en) * 2016-11-18 2019-06-25 Huawei Technologies Co., Ltd. Method and system for meeting multiple SLAS with partial QoS control
DE112017006994T5 (de) 2017-02-05 2019-10-17 Intel Corporation Bereitstellung und verwaltung von microservices
US20190080090A1 (en) * 2017-09-11 2019-03-14 Qualcomm Incorporated Method and apparatus for detecting dynamically-loaded malware with run time predictive analysis
US10771554B2 (en) 2017-09-30 2020-09-08 Intel Corporation Cloud scaling with non-blocking non-spinning cross-domain event synchronization and data communication
US11388272B2 (en) 2018-03-30 2022-07-12 Intel Corporation Technologies for network packet processing between cloud and telecommunications networks
US11960940B2 (en) * 2018-05-29 2024-04-16 Telefonaktiebolaget Lm Ericsson (Publ) Performance of function as a service
US11372689B1 (en) * 2018-05-31 2022-06-28 NODUS Software Solutions LLC Cloud bursting technologies
US20190042339A1 (en) 2018-06-29 2019-02-07 Intel Corporation Techniques for invocation of a function or a service
US11171983B2 (en) 2018-06-29 2021-11-09 Intel Corporation Techniques to provide function-level isolation with capability-based security
US10915366B2 (en) * 2018-09-28 2021-02-09 Intel Corporation Secure edge-cloud function as a service

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180034924A1 (en) * 2016-07-28 2018-02-01 Polybit Inc. System and method for a unified interface to networked webservices
US20180115551A1 (en) * 2016-10-20 2018-04-26 Brian Cole Proxy system for securely provisioning computing resources in cloud computing environment
US20180113793A1 (en) * 2016-10-25 2018-04-26 International Business Machines Corporation Facilitating debugging serverless applications via graph rewriting
US20180254998A1 (en) * 2017-03-02 2018-09-06 Alcatel Lucent Resource allocation in a cloud environment
US10121021B1 (en) * 2018-04-11 2018-11-06 Capital One Services, Llc System and method for automatically securing sensitive data in public cloud using a serverless architecture

Also Published As

Publication number Publication date
WO2020096639A1 (en) 2020-05-14
CN112955869A (zh) 2021-06-11
EP3877854A4 (en) 2022-08-10
US11922220B2 (en) 2024-03-05
DE112019005604T5 (de) 2021-09-09
KR20210076882A (ko) 2021-06-24
JP7327744B2 (ja) 2023-08-16
EP3877854A1 (en) 2021-09-15
US20210263779A1 (en) 2021-08-26

Similar Documents

Publication Publication Date Title
JP7327744B2 (ja) ファンクションアズアサービス（ＦａａＳ）システムの強化
US10606750B1 (en) Computing in parallel processing environments
Zhang et al. Narrowing the gap between serverless and its state with storage functions
ES2933675T3 (es) Sistemas, métodos y aparatos para informática heterogénea
Von Behren et al. Capriccio: Scalable threads for internet services
Nightingale et al. Helios: heterogeneous multiprocessing with satellite kernels
US20170353534A1 (en) Virtual performance monitoring decoupled from hardware performance-monitoring units
US10768982B2 (en) Engine for reactive execution of massively concurrent heterogeneous accelerated scripted streaming analyses
US9098608B2 (en) Processor configured to allocate resources using an entitlement vector
US9460290B2 (en) Conditional security response using taint vector monitoring
US9465657B2 (en) Entitlement vector for library usage in managing resource allocation and scheduling based on usage and priority
US9471373B2 (en) Entitlement vector for library usage in managing resource allocation and scheduling based on usage and priority
US10277477B2 (en) Load response performance counters
Chapman et al. vNUMA: A Virtual Shared-Memory Multiprocessor.
Labrecque et al. The case for hardware transactional memory in software packet processing
Marufuzzaman et al. A review on reliability, security and memory management of numerous operating systems
Fingler et al. Towards a machine learning-assisted kernel with lake
Perarnau et al. Argo
Muyan‐Özçelik et al. Methods for multitasking among real‐time embedded compute tasks running on the GPU
Schatzberg Customization and reuse in datacenter operating systems
Chapman vNUMA: Virtual shared-memory multiprocessors
Bhatia Optimistic compiler optimizations for network systems
Hetherington Software-hardware co-design for energy efficient datacenter computing
Nguyen An Efficient Execution Model for Reactive Stream Programs
Lumetta Design and evaluation of multiprotocol communication on a cluster of SMP's

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220328

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230314

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230426

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230704

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230721

R150 Certificate of patent or registration of utility model

Ref document number: 7327744

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150