JP2022538897A - コンテナベースのアプリケーション - Google Patents

Abstract

コンテナベースのアプリケーションを調整するための方法、コンピュータ・プログラム製品、およびシステムが提供される。プロセッサが、コンテナベースのアプリケーションで一つ以上の関数呼び出しを受信しうる。プロセッサは、コンテナベースのアプリケーションを使用して一つ以上の関数呼び出しを処理しうる。プロセッサは、一つ以上の関数呼び出しの処理に基づいて、コンテナベースのアプリケーションから性能データを取得しうる。プロセッサは、性能データを性能尺度限界に照らして分析しうる。プロセッサは、性能データの分析に基づいてコンテナベースのアプリケーションの態様を調整しうる。態様は、コンテナベースのアプリケーションのリソースおよび機能を含む群より選択される一つ以上でありうる。

Description

本開示は、コンテナベースのアプリケーションに関し、特にコンテナベースのアプリケーションの調整に関する。

設計上、コンテナベースのアプリケーションなどのクラウド・ネイティブ・アプリケーションは、作業負荷／要求の増加に基づいてシステム・リソースを拡張および消費するように設計される。このスケーラビリティは多くの条件下で望ましいが、システム制約が満たされる結果サービスが利用できなくなることは望ましくない。例えばアプリケーションが、追加のコンピューティング・パワーを追加してもそれ以上アプリケーションが追加で入ってくるリクエストを処理できない（ハードウェア能力に関係する）ハード限界または（アプリケーションのリソース割り当てに関係する）ソフト限界でありうるスケール限界に達しうる。換言すれば、この時点でアプリケーションはそれ以上要求を満たすためにスケール・アップできない。この場合、典型的なアプリケーションは、新たなリクエストを後で処理リソースが利用可能になったときに処理されるようにキューに入れ、それによりシステムのレイテンシが増加する。

本開示の実施形態は、コンテナベースのアプリケーションを調整するための方法、コンピュータ・プログラム製品、およびシステムを提供する。プロセッサが、コンテナベースのアプリケーションで一つ以上の関数呼び出しを受信しうる。プロセッサが、コンテナベースのアプリケーションを使用して一つ以上の関数呼び出しを処理しうる。プロセッサは、一つ以上の関数呼び出しの処理に基づいて、コンテナベースのアプリケーションから性能データを取得しうる。プロセッサは、性能データを性能尺度限界に照らして分析しうる。プロセッサは、性能データの分析に基づいてコンテナベースのアプリケーションの態様を調整しうる。態様は、コンテナベースのアプリケーションのリソースおよび機能を含む群より選択される一つ以上でありうる。

本開示に含まれる図面は、本明細書に組み込まれその一部を形成する。これらの図面は、本開示の実施形態を例示し、記述とともに本開示の原理を説明するのに役立つ。図面は、典型的な実施形態の例示に過ぎず、本開示を限定するものではない。

本開示の一実施形態によるクラウド・コンピューティング環境を示す。 本開示の一実施形態による抽象モデル層を示す。 本開示の実施形態によるコンテナベースのアプリケーションを調整するための例示的なプロセスのフロー図を示す。 本開示の実施形態による曲線の折れ曲がり（ｋｎｅｅ‐ｏｆ‐ｔｈｅ‐ｃｕｒｖｅ）のグラフ表現を示す。 本開示の実施形態による本明細書に記載される方法、ツール、およびモジュールならびに任意の関連する機能の一つ以上を実施する際に使用されうる例示的なコンピュータの高レベル・ブロック図を示す。

本明細書に記載される実施形態は、様々な修正および代替形態の余地があるが、その詳細が図面に例として示されており、詳細に説明される。しかし、記載される特定の実施形態は、限定的な意味に取られてはならないことが理解されねばならない。反対に、本開示の精神および範囲内に入る全ての修正物、等価物、および代替物をカバーすることが意図される。

図は概略的なものにすぎず、縮尺通りに描かれていないことが理解されねばならない。同じまたは類似の部分を示すために、図面全体で同じ参照番号が使用されることも理解されねばならない。

本出願の文脈において、本開示の実施形態が方法を構成する場合、そのような方法はコンピュータによる実行のためのプロセス、すなわちコンピュータにより実施可能な方法であることが理解されねばならない。したがって、方法の様々なステップは、コンピュータ・プログラムの様々な部分、例えば一つ以上のアルゴリズムの様々な部分を反映する。

また、本出願の文脈において、（処理）システムは、本開示の方法の一つ以上の実施形態を実行するように適合された単一のデバイスまたは分散されたデバイスの集合でありうる。例えば、システムはパーソナル・コンピュータ（ＰＣ：ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、サーバ、またはローカル・エリア・ネットワーク、インターネット等のネットワークを介して接続されて本開示の方法の少なくとも一つの実施形態を協調的に実行するＰＣもしくはサーバまたはその両方の集合でありうる。

本開示はクラウド・コンピューティングについての詳細な説明を含むが、本明細書に記載の教示の実施態様は、クラウド・コンピューティング環境に限定されないことが理解されねばならない。むしろ、本開示の実施形態は、現在知られているかまたは後に開発される任意の他のタイプのコンピューティング環境と連動して実施されることができる。

クラウド・コンピューティングは、最小限の管理労力またはサービスのプロバイダとのインタラクションで迅速にプロビジョニングおよびリリースされうる、構成可能なコンピューティング・リソース（例えばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想機械、およびサービス）の共有プールへの簡便なオンデマンド・ネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウドモデルは、少なくとも五つの特徴、少なくとも三つのサービス・モデル、および少なくとも四つの展開モデルを含みうる。

特徴は以下の通りである。
オンデマンド・セルフ・サービス：クラウド・コンシューマは、サービスのプロバイダとの人的やり取りを要せずに必要に応じて自動的にサーバの時間およびネットワーク・ストレージなどのコンピューティング能力を一方的に設定しうる。
幅広いネットワーク・アクセス：能力はネットワーク上で利用可能であり、異種のシンまたはシック・クライアント・プラットフォーム（例えば携帯電話、ラップトップ、およびＰＤＡ）による利用を促進する標準的機構を通じてアクセスされる。
リソースのプール：プロバイダのコンピューティング・リソースは、マルチテナント・モデルを使用して複数のコンシューマに提供されるようにプールされ、様々な物理的リソースおよび仮想リソースが要求に応じて動的に割り当ておよび再割り当てされる。コンシューマは通常、提供されたリソースの正確な場所についての制御力または知識を有しないが、より抽象的なレベル（例えば国、州、またはデータセンタ）で場所を特定しうるという点で、場所にとらわれない感覚が存在する。
スピーディなスケーラビリティ：能力は、スピーディに弾力的に、場合によっては自動的に提供されて即座にスケール・アウトし、スピーディに解放されて即座にスケール・インしうる。コンシューマにとって、提供のために利用可能な能力は多くの場合無限に見え、いつでも任意の量で購入されうる。
測定されるサービス：クラウド・システムは、サービスの種類（例えばストレージ、処理、帯域幅、およびアクティブなユーザ・アカウント）に適した何らかの抽象レベルで計測能力を活用することにより、リソースの利用を自動的に制御および最適化する。リソースの使用状況は、監視、制御、および報告されることができ、利用されるサービスのプロバイダおよびコンシューマの両方に透明性を提供する。

サービス・モデルは以下の通りである。
サービスとしてのソフトウェア（ＳａａＳ：Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、クラウド・インフラストラクチャ上で実行されるプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インタフェース（例えばウェブベースの電子メール）を通じて、様々なクライアント・デバイスからアクセス可能である。コンシューマは、限られたユーザ固有のアプリケーション構成設定を場合によっては除いて、ネットワーク、サーバ、オペレーティング・システム、ストレージまたは個々のアプリケーション能力をも含む基礎的クラウド・インフラストラクチャを管理または制御しない。
サービスとしてのプラットフォーム（ＰａａＳ：Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成されるコンシューマが作成または入手したアプリケーションをクラウド・インフラストラクチャ上に展開することである。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基礎的クラウド・インフラストラクチャを管理または制御しないが、展開されたアプリケーションおよび場合によってはアプリケーション・ホスティング環境構成を制御できる。
サービスとしてのインフラストラクチャ（ＩａａＳ：Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、処理、ストレージ、ネットワーク、および他の基本的なコンピューティング・リソースを提供することであり、コンシューマは、オペレーティング・システムおよびアプリケーションを含みうる任意のソフトウェアを展開して実行させることができる。コンシューマは、基礎的クラウド・インフラストラクチャを管理または制御しないが、オペレーティング・システム、ストレージ、展開されたアプリケーションを制御でき、場合によっては選抜されたネットワーキング・コンポーネント（例えばホスト・ファイアウォール）を限定的に制御できる。

展開モデルは以下の通りである。
プライベート・クラウド：クラウド・インフラストラクチャは、ある組織専用に運用される。クラウド・インフラストラクチャは、その組織または第三者によって管理されることができ、構内または構外に存在することができる。
コミュニティ・クラウド：クラウド・インフラストラクチャは、いくつかの組織によって共有され、共有の懸念事項（例えばミッション、セキュリティ要件、ポリシー、およびコンプライアンスの考慮事項）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、これらの組織または第三者によって管理されることができ、構内または構外に存在することができる。
パブリック・クラウド：クラウド・インフラストラクチャは、一般大衆または大きな業界グループに利用可能にされ、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティであり続けるがデータおよびアプリケーションのポータビリティを可能にする標準化されたまたは専用の技術（例えばクラウド間の負荷平衡のためのクラウド・バースティング）によって一緒に結び付けられた二つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の合成物である。

クラウド・コンピューティング環境はサービス指向であり、状態非依存性、低結合度、モジュール性、およびセマンティックな相互運用性に重点を置く。クラウド・コンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。

例示的な実施形態は、コンテナベースのアプリケーションを調整する、特にコンテナベースのアプリケーションのリソースまたは機能を調整するための構想を提供する。この構想は、コンテナベースのアプリケーションで一つ以上の関数呼び出しを受信するステップと、コンテナベースのアプリケーションを使用して一つ以上の関数呼び出しを処理するステップと、一つ以上の関数呼び出しの処理に基づいてコンテナベースのアプリケーションから性能データを取得するステップと、性能データを性能尺度限界に照らして分析するステップと、性能データの分析に基づいてコンテナベースのアプリケーションのリソースもしくは機能またはその両方を調整するステップとを含みうる。

実施形態は、取得される性能データと予め定義された性能尺度限界との間の比較に応じてコンテナベースのアプリケーションを調整するための構想を含む。性能尺度限界の評定は、関数呼び出しが処理されるときにコンテナベースのアプリケーションから取得される性能データの分析に基づきうる。

実施形態は、コンテナベースのアプリケーションが一つ以上の関数呼び出しを受信することを可能にし、関数呼び出しを処理する際にアプリケーションから取得される性能データのセットを分析することによってアプリケーションの機能またはリソースを調整しうる。機能またはリソースは、性能尺度限界に達したと判断されたとき、または所定の期間内に性能尺度に達すると判断されたときに調整されうる。

このようにして、本開示は、性能データと性能尺度限界との間の比較に応じてコンテナベースのアプリケーションを調整する手段を提供しうる。

例えば、関数呼び出しを処理するのに要する時間が時間制限を超えるなど、アプリケーションの性能の尺度が所与の限界を超えるときに、アプリケーションのリソースまたは機能が調整されうる。同様に、アプリケーションの性能の尺度が、所与の期間内に性能が所与の限界を超えることを示すときに、アプリケーションのリソースまたは機能が調整されうる。通常のコンテナベースのアプリケーションでは、アプリケーション・パラメータの任意の調整は通常、アプリケーションの実行開始前に決定される、すなわち通常のコンテナベースのアプリケーションはその挙動を例えば予想外に重い処理負荷に応じて動的に調整できない。場合によっては、関数呼び出しを処理するためにより多くのコンピューティング・パワーを割り当てるだけでは問題を解決できない。

したがって、アプリケーションの性能を分析することによって、性能尺度を使用してアプリケーションの機能またはリソースを調整し、本来ならキューに入れられてレイテンシを引き起こすであろうさらなる関数呼び出しが処理されることを可能にしうる。

このように、コンテナベースのアプリケーションは、受信される関数呼び出しの処理に関係する性能データを動的に取得および分析し、それに応じてコンテナベースのアプリケーションの機能またはリソースを調整しうる。

実施形態は、コンテナベースのアプリケーションから取得される性能データの分析に基づく、コンテナベースのアプリケーションのリソースまたは機能の調整を提供しうる。

コンテナは、仮想マシンを必要とせずに共有オペレーティング・システム・カーネルにアクセスする、仮想分離に依存してアプリケーションを展開および実行するパッケージである。コンテナベースのアプリケーションは、コンテナを使用するシステム上で実行されうる任意のソフトウェア・アプリケーションを指す。

一実施形態では、性能データを性能尺度限界に照らして分析するステップは、性能尺度限界に達しているか否かを判断するステップ、または、所与の期間内に性能尺度限界に達するか否かを判断するステップを含む。このようにして、コンテナベースのアプリケーションは、現在の要求または予測される要求にしたがって動的に調整されうる。

一実施形態では、性能データを分析するステップは、一つ以上の関数呼び出しを処理するための処理時間を判断するステップと、分析された性能データに基づいて曲線の折れ曲がりを識別するステップであって、曲線の折れ曲がりは、処理時間が所定の閾値を超える場合に識別される、ステップとを含む。曲線の折れ曲がりは、性能尺度の急な増加を識別するために使用されうる。この場合、曲線の折れ曲がりを使用して、関数呼び出しを処理するのに要する時間の急な増加（例えばレイテンシの急な増加）を識別しうる。

曲線の折れ曲がりは、性能データ内、例えば関数呼び出しの数および各関数呼び出しを処理する時間等の二つの変数のグラフとしてプロットされた性能データ内の曲線の折れ曲がり特徴から識別されうる。曲線の折れ曲がり特徴は、所与の変数の増加または減少が生じる点などの任意の変化として識別されうる。

例えば、関数呼び出しを処理するのに要する時間は、所与の数の関数呼び出しが受信されたときに増加しうる。この関係において増加が生じる点は、曲線の折れ曲がり特徴として識別されうる。具体的な例では、増加が生じる点は、増加が指数関数的増加であると判断される場合にのみ曲線の折れ曲がり特徴として識別されうる。性能データの所与の変数の減少についても同じことが当てはまりうる。換言すれば、性能データの変数の変化を示す曲線の折れ曲がり特徴によって曲線の折れ曲がりが識別されうる。このようにして、性能データの変数間の関係の変化に基づいて曲線の折れ曲がりが識別されうる。

一実施形態において、性能尺度限界は、物理リソース限界、仮想リソース限界、コンテナ・リソース限界および予め定義されたスケーリング限界の一つ以上を含むスケーラビリティ限界、コスト限界、応答性限界、実行あたりのＣＰＵ利用、コンテナのＣＰＵ利用、メモリ利用、ネットワーク・スループット、ネットワーク・レイテンシ、ストレージ・スループット、ストレージ・レイテンシ、リクエスト応答時間、一秒（または他の合意された期間）あたりのトランザクションの数、および失敗率の一つ以上を含む。このようにして、コンテナベースのアプリケーションの実施態様に応じて様々な性能尺度限界が用いられうる。

一実施形態では、リソースは、コンピューティング・リソースおよび実行アーキテクチャ・リソースの一つ以上を含む。このようにして、調整されるリソースは所与のシナリオに適切な形をとりうる。

一実施形態では、実行アーキテクチャ・リソースは、Ｓｏｆｔｗａｒｅ ａｓ ａ ＳｅｒｖｉｃｅアーキテクチャおよびＦｕｎｃｔｉｏｎ ａｓ ａ Ｓｅｒｖｉｃｅアーキテクチャの一つ以上を含む。このようにして、アプリケーションは直ちに利用可能な実行アーキテクチャを利用しうる。

一実施形態では、機能はフロントエンド機能を含み、フロントエンド機能は、表示されるデータの量、許容される複雑なトランザクションの数、および利用可能なアプリケーション・オプションの数の一つ以上を含む。このようにして、フロントエンド機能はアプリケーションの実施態様に応じていくつかのやり方で調整されうる。

一実施形態では、機能はバックエンド機能を含み、バックエンド機能は、シンセティック・トランザクションの数、ログの量、同期トランザクションの数、および非同期トランザクションの数の一つ以上を含む。このようにして、バックエンド機能はアプリケーションの実施態様に応じていくつかのやり方で調整されうる。

一実施形態では、コンテナベースのアプリケーションの機能を調整するステップは、フロントエンド機能を使用してバックエンド機能を行うステップを含む。このようにして、バックエンド性能の増加のためにバックエンド機能が保たれうる。

提案された構想の価値および有用性を高めうる、従来のコンテナベースのアプリケーションに対する修正および追加のステップも提案されうる。

例示的な実施形態は、多様なタイプのデータ処理環境において利用されうる。例示的な実施形態の要素および機能の説明のための状況を提供するために、図１および図２が例示的な実施形態の態様が実施されうる環境の例として以下に提供される。図１および図２は例に過ぎず、本開示の態様または実施形態が実施されうる環境に関していかなる限定を主張または示唆する意図もないことが理解されねばならない。本開示の精神および範囲から逸脱することなく、描写された環境に対する多数の修正が行われうる。

ここで図１を参照すると、例示的なクラウド・コンピューティング環境５０が示される。図示のように、クラウド・コンピューティング環境５０は、例えばパーソナル・デジタル・アシスタント（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）もしくは携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、もしくは自動車コンピュータ・システム５４Ｎまたはそれらの組み合わせなどのクラウド・コンシューマにより使用されるローカル・コンピューティング・デバイスが通信しうる一つ以上のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信しうる。これらは、本明細書に上述したプライベート、コミュニティ、パブリックもしくはハイブリッド・クラウドまたはそれらの組み合わせなど、一つ以上のネットワークにおいて物理的または仮想的にグループ化されうる（図示せず）。これにより、クラウド・コンピューティング環境５０は、クラウド・コンシューマがローカル・コンピューティング・デバイス上にリソースを維持する必要がないサービスとしてインフラストラクチャ、プラットフォームもしくはソフトウェアまたはそれらの組み合わせを提供することが可能になる。図１に示されるコンピューティング・デバイスのタイプ５４Ａ～Ｎは、例示を意図したものにすぎず、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、任意のタイプのネットワークもしくはネットワークアドレス可能な接続またはその両方により（例えばウェブ・ブラウザを使用して）任意のタイプのコンピュータ化デバイスと通信しうるものと理解される。

ここで図２を参照すると、クラウド・コンピューティング環境５０（図１）によって提供される機能抽象層のセットが示される。図２に示されるコンポーネント、層、および機能は例示を意図したものにすぎず、本開示の実施形態はそれらに限定されないことが予め理解されねばならない。図示されるように、以下の層および対応する機能が提供される。

ハードウェアおよびソフトウェア層６０は、ハードウェアおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例は、メイン・フレーム６１、ＲＩＳＣ（Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ：縮小命令セット・コンピュータ）アーキテクチャ・ベース・サーバ６２、サーバ６３、ブレード・サーバ６４、記憶デバイス６５、ならびにネットワークおよびネットワーキング・コンポーネント６６を含む。いくつかの実施形態では、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

仮想化層７０は、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５という仮想エンティティの例が提供されうる抽象層を提供する。

一例では、管理層８０は、以下に説明される機能を提供しうる。リソース・プロビジョニング８１は、クラウド・コンピューティング環境内でタスクを行うために利用されるコンピューティング・リソースおよび他のリソースの動的調達を提供する。計測および価格設定８２は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡、およびこれらのリソースの消費についての課金または請求を提供する。一例では、これらのリソースはアプリケーション・ソフトウェア・ライセンスを含みうる。セキュリティは、クラウド・コンシューマおよびタスクの識別検証、ならびにデータおよびその他のリソースの保護を提供する。ユーザ・ポータル８３は、コンシューマおよびシステム管理者にクラウド・コンピューティング環境へのアクセスを提供する。サービス水準管理８４は、必要なサービス水準に達するようにクラウド・コンピューティング・リソースの割り当ておよび管理を提供する。サービス水準合意（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）の計画および履行８５は、ＳＬＡにしたがって将来の必要が見込まれるクラウド・コンピューティング・リソースの事前手配および調達を提供する。

作業負荷層９０は、クラウド・コンピューティング環境が利用されうる機能の例を提供する。この層から提供されうる作業負荷および機能の例は、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想学級教育配信９３、データ分析処理９４、トランザクション処理９５、および任意の他の適切な機能９６を含む。

一実施形態では、コンテナベースのアプリケーションを管理するための方法が、管理層８０において展開されうる。

ここで図３を参照すると、本開示の実施形態によるコンテナベースのアプリケーションを調整するための例示的なプロセス３００のフロー図が示される。プロセス３００はステップ３１０から開始し、コンテナベースのアプリケーションで一つ以上の関数呼び出しが受信される。

ステップ３２０で、受信された一つ以上の関数呼び出しがコンテナベースのアプリケーションによって処理される。コンテナベースのアプリケーションは、例えば図１および図２で詳述されるクラウド・コンピューティング環境５０などのクラウドベースの環境に展開されうる。

通常、コンテナに展開されるアプリケーションは、所与の環境の予め定義されたリソースにスケール・アップ可能であるように設計される。これらのリソースは、物理リソース、仮想リソース、または人工リソースでありうる。これらのリソースが使い果たされると、追加の関数呼び出しは処理されるためにキューに入れられ、これによりアプリケーションのレイテンシが増す。

ステップ３３０で、一つ以上の関数呼び出しの処理に基づいてコンテナベースのアプリケーションから性能データが取得される。

コンテナベースのアプリケーションのコンテナは通常、コンテナをワーカ・ノードに置くことによって管理され、これらの組み合わせをポッドと呼ぶことができ、管理ソフトウェアを用いてこれらのポッドが管理される。通常、管理ソフトウェアは、ポッドに関係するトレース、ログ、またはメトリックを提供しない。しかし、この機能を実際に行う様々なツールがあり、これはしばしばサービス・メッシュと呼ばれ、各ポッド内にサイドカーを展開する。このようなツールを用いて各コンテナから性能データが取得されうる。大部分の機能にとってコンテナに関する限りこれはサーバレス監視であることに留意しなければならない。

例えば、性能データは、コンテナベースのアプリケーションを実行するＬｉｎｕｘ（Ｒ）アドレス空間から取得されうる。Ｌｉｎｕｘは、米国、他国またはその両方におけるＬｉｎｕｓ Ｔｏｒｖａｌｄｓの登録商標である。

ステップ３４０で、性能データが性能尺度限界に照らして分析される。

性能データの分析は、一つ以上の関数呼び出しを処理するための処理時間を判断するステップと、分析された性能データに基づいて曲線の折れ曲がりを識別するステップであって、曲線の折れ曲がりは、処理時間が所定の閾値を超える場合に識別される、ステップとを含みうる。

性能データを分析することによって、コンテナベースのアプリケーションが例えば最大のハードウェアのポテンシャルにスケール・アウトしているときに識別することが可能である。これは例えば、性能データの曲線の折れ曲がりを利用することによって行われうる。この技術は、図４を参照してさらに以下に詳述される。

ハードウェアのポテンシャルを性能尺度限界として使用することに加えて、所与の処理環境でコンテナベースのアプリケーションを実行する財政的コストに関係するコストの最大コスト限界に達しているときに判断することも可能である。この場合、リソースは実行アーキテクチャ・リソースであり得、代替環境を利用するために調整されうる（例えばＳｏｆｔｗａｒｅ Ａｓ Ａ Ｓｅｒｖｉｃｅ（ＳＡＡＳ）アーキテクチャからＦｕｎｃｔｉｏｎ Ａｓ Ａ Ｓｅｒｖｉｃｅ（ＦＡＡＳ）アーキテクチャに調整）。

実施形態において、プロセス３００は、性能データの分析に基づいて性能尺度限界に達しているか否かが判断されるステップ３５０に進みうる。性能尺度限界は、コンテナベースのアプリケーションの性能の変化を示す任意の測定可能な限界でありうる。

例えば、性能尺度限界は、このようなアプリケーションが処理要求の増加を満たすためにスケーリングする従来の能力に関係する性能尺度限界であるスケーラビリティ限界でありうる。このように、スケーラビリティ限界に達したときには、コンテナベースのアプリケーションは、作業負荷要求を満たすためにそれ以上スケーリングできない。

スケーラビリティ限界の例は、物理リソース限界でありうる。物理リソース限界は、コンテナベースのアプリケーションを実行するシステムの基礎的物理インフラストラクチャの物理的限界、例えばクラウド処理環境をホストするサーバの物理的限界に関係しうる。物理的限界は例えば、基礎的アーキテクチャのＣＰＵ、基礎的アーキテクチャのメモリ、基礎的アーキテクチャのディスク、基礎的アーキテクチャのネットワークなどに関係しうる。

スケーラビリティ限界のさらなる例は、仮想リソース限界であり得、仮想リソース限界は、例えば、コンテナベースのアプリケーションまたはコンテナベースのアプリケーションの一部の態様が実行しうる仮想マシン（ＶＭ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）の限界に関係しうる。仮想限界は例えば、ＶＭのＣＰＵ分配、ＶＭの割り当てられたメモリ、ＶＭのディスク割り当て、ＶＭのネットワークなどに関係しうる。

スケーラビリティ限界の別の例は、仮想リソース限界に関して上述した限界に類似しうるコンテナ・リソース限界でありうる。コンテナ・リソース限界は、個々のコンテナの制限に関係し、これは例えばコンテナのＣＰＵ分配、コンテナの割り当てられたメモリ、コンテナのディスク割り当て、コンテナのネットワークなどに関係しうる。

スケーラビリティ限界のさらなる例は、予め定義されたスケーリング限界であり得、予め定義されたスケーリング限界は、最大ハードウェア（仮想またはその他の）能力によって定義される限界ではなく、コンテナベースのアプリケーションによる所望のレベルのリソース消費に関係する制限でありうる。このような予め定義されたスケーリング限界は、例えば予期されないコストを回避するためにアプリケーションが消費しうるリソースの量を制約するように設計されうる。

図４を参照してさらに後に述べるように、スケーラビリティ限界は、コンテナベースのアプリケーションから取得される性能データから曲線の折れ曲がりを識別することによって評定されうる。

性能尺度限界のさらなる例は、上記のようにコスト限界でありうる。例えば、受信される関数呼び出しの処理のために消費される処理システムのリソースの量に関連するコストがありうる。このコストが所与の量を超える場合、アプリケーションを実行するコストを所与の量で維持するためにコンテナベースのアプリケーションの機能またはリソースが調整されうる。

性能尺度限界のさらなる例は、所与の関数呼び出しを処理するために要する時間の量に関係する応答性限界でありうる。例えば、関数呼び出し処理時間が所与の量を超える場合、例えばアプリケーションが新たな関数呼び出しに応答しなくなった場合、コンテナベースのアプリケーションの応答性を改善するためにリソースまたは機能が調整されうる。

応答性限界は、例えばスケーラビリティ限界にも達した結果達しうる。換言すれば、スケーラビリティ限界に達すると、アプリケーションは処理要求を満たすためにスケール・アップできないため、追加の関数呼び出しがキューに入れられ、それによりアプリケーションの応答性が低下しうる。あるいは、作業負荷要求の増加に応答するために追加のコンテナを提供する自動スケーリング／プロビジョニング・プロセスの失敗があり、その結果スケーラビリティ限界の前に応答性限界に達しうる。

性能尺度限界は、コンテナ（単数または複数）自体を実行する基礎的物理コンピューティング・リソースもしくは仮想マシン・リソースまたはその両方（すなわちコンテナに通常公開されないデータ）の全体的利用にも関係しうる。コンテナは、外部リソースまたはリソース利用の具体的詳細を性能データの一部として見ることはできないが、コンテナは、（例えばリソース枯渇または性能尺度限界に達したことにより）入ってくる作業負荷を満たせないことを認識しうる。

以上に記載された各限界およびアプリケーションの性能を監視するのに適した任意の他の限界は、性能データを分析および評価することによって監視されて、可用性および例えば処理キャパシティ、コスト要因、および曲線の折れ曲がりの制限の動的だが制限されたプールの範囲内で処理されうる同時リクエストの数を最大化するようにアプリケーション・サービスによって提供される能力もしくは特徴またはその両方が自動的に調整されうる。

さらに、上述の限界は、コンテナベースのアプリケーションのリソース／機能を調整するために互いに任意の組み合わせで使用されうる。

実施形態において、性能データの分析および評価はコグニティブ・エンジンによって行われうる。コグニティブ・エンジンは、より幅広いコンピューティング・プラットフォームの既知の特性を考慮しうる。そのような詳細はコンテナに通常公開されず、物理ホスト・リソースの使用状況、他のコンテナまたは他の仮想マシンの作業負荷などのリソースを含みうる。

さらに、コグニティブ・エンジンは、コンテナの作業負荷最適化特性を考慮して、過去の作業負荷特性により性能尺度限界に到達しうるか、または到達しているかを予測しうる。例えば、あるアプリケーションは、毎月第二日曜日の午前２時～午前７時の間にリソース要件が倍増することが知られうる。

その後、コグニティブ・エンジンは、問題のコンテナの利用を予想しうる。例えば、クライアントがある月のリソースをＮの量だけ購入しており、全ての特徴を有効にしてアプリケーションを実行するとその月の２３日までしかもたない場合、リソース割り当てが使い果たされたときにサービスが完全に利用できなくなるかわりに、コグニティブ・エンジンはアプリケーションの機能が低減されるとした場合に推定される可用性を調べうる。具体的な例では、コグニティブ・エンジンは、活動残高の表示が自動的にされなくなり、かわりに表示されるためにユーザ入力を要した場合にはバンキング・アプリケーションが月末までもちうる（例えばリソースをもう一週間延長する）か否かを判断しうる。

スケーリングおよび性能など、アプリケーションのリソース／機能の調整の判断のために性能データに様々なルールが適用されうる。判断の結果およびそれらの結果がアプリケーションの可用性および性能に与える影響は、データベースに記憶されうる。

ステップ３５０で性能尺度限界に達していると判断された場合には、プロセス３００はステップ３６０に進む。ステップ３６０で、性能データの分析に基づいてコンテナベースのアプリケーションのリソースまたは機能が調整される。

調整されるリソースは、コンテナベースのアプリケーションによって使用されるコンピューティング・リソースを含みうる。コンピューティング・リソースは、例えばＣＰＵ使用状況、メモリ使用状況、ディスク使用状況、ネットワーク使用状況などを含みうる。

調整されるリソースは実行アーキテクチャ・リソースも含み得、実行アーキテクチャ・リソースはＳｏｆｔｗａｒｅ ａｓ ａ ＳｅｒｖｉｃｅアーキテクチャもしくはＦｕｎｃｔｉｏｎ ａｓ ａ Ｓｅｒｖｉｃｅアーキテクチャまたはその両方を含みうる。

コンテナベースのアプリケーション等のクラウドのために構築されたアプリケーションは、それらの性質上、（他のアプリケーションと同様にハードウェア上で実行するが）基礎的実行アーキテクチャおよびシステム・リソースに対してアグノスティックでありうる。したがって、これらの要因を用いて、コンテナベースのアプリケーションの動的調整およびＳＡＡＳからＦＡＡＳへの移行が行われうる。

調整される機能はフロントエンド機能を含み得、フロントエンド機能は、表示されるデータの量、許容される複雑なトランザクションの数、および利用可能なアプリケーション・オプションの数を含みうる。

換言すれば、性能尺度限界に達しており、サービスを保ち、スループット（受信される関数呼び出しの処理）を最大化するためにコンテナベースのアプリケーションの機能が減少／除去されねばならないとの判断に基づいて、アプリケーション論理内で様々な機能が調整されうる。

例えば予めロードされたデータは、ユーザが必要な場合に明示的にデータをリクエストするオプションに置き換えられ、それによりユーザに示される不必要なデータの量が減少されうる。さらに、ユーザに表示されるデータの総量が、例えば動画などのコンテンツもしくは画質またはその両方を低減することによって、制限（もしくは予めロードまたはその両方）されうる。加えて、アプリケーションによって通常行われる複雑なトランザクションが除去されうる。さらなる例では、ユーザに通常利用可能なメニューからオプション、特に複雑なトランザクションが行われることにつながりうるオプションが除去されうる。

機能はバックエンド機能も含み得、バックエンド機能は、シンセティック・トランザクションの数、ログの量、同期トランザクションの数、および非同期トランザクションの数を含みうる。

このようにして、性能尺度限界に達したという判断の結果として、エンドユーザに直接公開されない特徴を含むバックエンド・サービス機能が調整されうる。例えば、コンテナベースのアプリケーションは、トランザクションを後のバッチ処理のためにキューに入れることによって、同期トランザクションから非同期トランザクションに切り替えうる。

さらに、コンテナベースのアプリケーションの機能を調整するステップは、フロントエンド機能を使用してバックエンド機能を行うステップを含みうる。

例えば、バックエンド・サービスがフロントエンド・サービスに「転送」して機能を自動的に減少させ、その結果バックエンド処理能力を保ちうる。例えば、長時間実行される夜間バッチ処理動作が、ＦＡＡＳを介して見込まれるフロントエンド・サービス機能減少を引き起こして、オンライン（リアルタイム）処理から負荷を減少させうる。

ステップ３６０の後、プロセス３００はステップ３１０に戻り、プロセス３００は上述のように進みうる。ステップ３５０で性能尺度限界に達していないと判断された場合には、プロセス３００はステップ３５５に進み得、性能データの分析に基づいて所与の時間制限内に性能尺度限界に達するか否かが判断される。

換言すれば、性能データの分析は、所与の期間内にアプリケーションが性能尺度限界に達することを示しうる。所定量の時間内に性能尺度限界に達すると判断された場合には、プロセス３００はステップ３６０に進み得、アプリケーションの予測される性能を考慮してリソースもしくは機能またはその両方が調整されうる。上述の性能データを分析する方法および様々な性能尺度限界は、所与の期間内に性能尺度限界に達するか否かの判断に同じように当てはまりうることに留意しなければならない。

ステップ３５５で所与の期間内に性能尺度限界に達しないと判断される場合には、プロセス３００は、ステップ３１０に戻って上述のように進みうる。

まとめると、本開示は、アプリケーションの性能を分析および評価し、可用性および処理されうる同時リクエストの数を最大化するためにリソース／機能の動的調整を提供しうる。別の言い方をすると、本開示は、新たに入ってくる、または将来入ってくるエンドユーザのリクエストを処理するために使用されうる、曲線の折れ曲がりのハードウェア問題を回避するために機能を制限して利用可能なリソースを増やすサービスを提供しうる。

ここで図４を参照すると、本開示の実施形態による曲線の折れ曲がりのグラフ表現４００が示される。グラフ４００は、曲線の折れ曲がりの原理を実証するために関数ｘ－ｙ＝ｓｉｎ（ｘ＋ｙ）、ｘ＞０によって表される曲線４１０を呈するのが示される。

この例では、ｘ軸はコンテナベースのアプリケーションによって受信される関数呼び出しの数を表し得、ｙ軸は関数呼び出しを処理するのに要する時間を表しうる。一般に、ｘ軸はアプリケーションに対する要求を表し得、ｙ軸は性能尺度を表しうる。

曲線の折れ曲がり４２０は、指数関数的変化が存在する曲線のエリアとして定義される。この例では、曲線の折れ曲がりは、関数呼び出しを処理するのに要する時間の指数関数的増加である。一般に、曲線の折れ曲がりは、アプリケーションのスケーラビリティ限界などの性能尺度限界に達する点として理解されうる。

数学的には、曲線の折れ曲がりは、プロット４３０を参照して説明されうる。

曲線上の第一点４４０および曲線上の第二点４５０で直交ベクトルＮおよびＴが示される。第二点４５０のベクトルが移動され、第一点４４０に重ね合わされる（点線で示される）。第一点と第二点との間のベクトルＴの変化δＴが示される。

性能データにおける曲線の折れ曲がり特徴を計算するために、δＴが三つの点の間で比較されて、トランザクション完了の低下またはタイムアウトを通常伴う指数ＣＰＵ時間の開始が識別されうる。この時、例えばコンテナをサービスから取り出すことによってコンテナベースのアプリケーションのリソースまたは機能が調整され、ＦＡＡＳアーキテクチャに移行されうる。逆に、平坦なδＴは、最適（変動する）点が確定され実行されるまでアプリケーションがより多くのコンテナを誘発することを促しうる。

上記の計算では、レガシー・システム全体がシリアル・ボトルネックとして振る舞っているとみなされることに留意しなければならない。δＴがピークにあると判断される点は、通常指数関数的上昇であり、曲線の折れ曲がりに関連する。

取得された性能データに基づいて曲線の折れ曲がりを計算することにより、アプリケーションの将来の性能が判断されることができ、それによって所与の期間内に性能尺度限界に達しうるときに予測する手段が提供される。

ここで図５を参照すると、本開示の実施形態による本明細書に記載される方法、ツールおよびモジュールならびに任意の関連する機能の一つ以上を実施する際に使用されうる例示的なコンピュータ５００の高レベル・ブロック図が示される。上述の様々な動作は、コンピュータ５００の能力を利用しうる。例えば、応答テキストを分析することによってテキスト応答データを生成するためのシステムの一つ以上の部分が、本明細書に記載される任意の要素、モジュール、アプリケーション、もしくはコンポーネントまたはそれらの組み合わせに組み込まれうる。

コンピュータ５００は、ＰＣ、ワークステーション、ラップトップ、ＰＤＡ、パーム・デバイス、サーバ、ストレージなどを含むがこれらに限定されない。一般に、ハードウェア・アーキテクチャに関しては、コンピュータ５００は、ローカル・インタフェース（図示せず）を介して通信可能に連結される一つ以上のプロセッサ５１０、メモリ５２０、および一つ以上のＩ／Ｏデバイス５７０を含みうる。ローカル・インタフェースは、当該分野で知られるように例えば一つ以上のバスまたは他の有線もしくは無線接続でありうるがこれらに限定されない。ローカル・インタフェースは、通信を可能にするためにコントローラ、バッファ（キャッシュ）、ドライバ、リピータ、およびレシーバなどの追加の要素を有しうる。さらに、ローカル・インタフェースは、前述のコンポーネント間の適切な通信を可能にするためにアドレス、制御部、もしくはデータ接続またはそれらの組み合わせを含みうる。

プロセッサ５１０は、メモリ５２０に記憶されうるソフトウェアを実行するためのハードウェア・デバイスである。プロセッサ５１０は、事実上任意のカスタム・メイドまたは市販のプロセッサ、中央処理ユニット（ＣＰＵ：ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、またはコンピュータ５００に関連する複数のプロセッサの中の補助プロセッサであり得、プロセッサ５１０は半導体ベースのマイクロプロセッサ（マイクロチップの形態）またはマイクロプロセッサでありうる。

メモリ５２０は、揮発性メモリ要素（例えばダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ：ｄｙｎａｍｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：ｓｔａｔｉｃ ｒａｎｄｏｍ‐ａｃｃｅｓｓ ｍｅｍｏｒｙ）等のランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ））、および不揮発性メモリ要素（例えばＲＯＭ、消去可能プログラム可能リードオンリ・メモリ（ＥＰＲＯＭ：ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ‐ｏｎｌｙ ｍｅｍｏｒｙ）、電子的消去可能プログラム可能リードオンリ・メモリ（ＥＥＰＲＯＭ：ｅｌｅｃｔｒｏｎｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ‐ｏｎｌｙ ｍｅｍｏｒｙ）、プログラム可能リードオンリ・メモリ（ＰＲＯＭ：ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ‐ｏｎｌｙ ｍｅｍｏｒｙ）、テープ、コンパクト・ディスク・リードオンリ・メモリ（ＣＤ‐ＲＯＭ：ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ‐ｏｎｌｙ ｍｅｍｏｒｙ）、ディスク、ディスケット、カートリッジ、カセットなど等）のいずれか一つまたは組み合わせを含みうる。さらに、メモリ５２０は、電子、磁気、光もしくはその他のまたはそれらの組み合わせのタイプの記憶媒体を組み込みうる。メモリ５２０は、様々なコンポーネントが互いに遠隔にあるがプロセッサ５１０によってアクセスされうる分散アーキテクチャを有しうることに留意されたい。

メモリ５２０内のソフトウェアは、論理機能を実施するための実行可能命令の順序付けされたリストをそれぞれ含む一つ以上の個別のプログラムを含みうる。メモリ５２０内のソフトウェアは、例示的な実施形態によれば適切なオペレーティング・システム（Ｏ／Ｓ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）５５０、コンパイラ５４０、ソース・コード５３０、および一つ以上のアプリケーション５６０を含む。図示のように、アプリケーション５６０は、例示的な実施形態の特徴および動作を実施するための多数の機能コンポーネントを含む。コンピュータ５００のアプリケーション５６０は、例示的な実施形態によれば様々なアプリケーション、演算ユニット、論理、機能ユニット、プロセス、動作、仮想エンティティ、もしくはモジュールまたはそれらの組み合わせを表しうるが、アプリケーション５６０は限定を意図するものではない。

オペレーティング・システム５５０は、他のコンピュータ・プログラムの実行を制御し、スケジューリング、入出力制御、ファイルおよびデータ管理、メモリ管理、ならびに通信制御および関連サービスを提供する。例示的な実施形態を実施するためのアプリケーション５６０は、全ての市販のオペレーティング・システム上で適用可能でありうることが本発明者らにより企図される。

アプリケーション５６０は、ソース・プログラム、実行可能プログラム（オブジェクト・コード）、スクリプト、または遂行される命令のセットを含む任意の他のエンティティでありうる。ソース・プログラムの場合、プログラムは通常、Ｏ／Ｓ５５０に関連して正常に動作するようにメモリ５２０内に含まれることも含まれないこともあるコンパイラ（コンパイラ５４０等）、アセンブラ、インタプリタなどを介して翻訳される。Ｉ／Ｏデバイス５７０は、例えばマウス、キーボード、スキャナ、マイクロフォン、カメラ等であるがこれらに限定されない入力デバイスを含みうる。さらに、Ｉ／Ｏデバイス５７０は、例えばプリンタ、ディスプレイ等であるがこれらに限定されない出力デバイスも含みうる。最後に、Ｉ／Ｏデバイス５７０は、例えばＮＩＣまたは変調器／復調器（遠隔デバイス、他のファイル、デバイス、システム、またはネットワークへのアクセス用）、無線周波数（ＲＦ：ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）または他のトランシーバ、電話インタフェース、ブリッジ、ルータなどであるがこれらに限定されない、入力および出力の両方を通信するデバイスをさらに含みうる。Ｉ／Ｏデバイス５７０は、インターネットまたはイントラネット等の様々なネットワークを介して通信するためのコンポーネントも含む。

コンピュータ５００がＰＣ、ワークステーション、インテリジェント・デバイスなどである場合、メモリ５２０内のソフトウェアは、基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ ｉｎｐｕｔ ｏｕｔｐｕｔ ｓｙｓｔｅｍ）（簡略化のために省略）をさらに含みうる。ＢＩＯＳは、起動時にハードウェアを初期化およびテストし、Ｏ／Ｓ５５０を起動し、ハードウェア・デバイス間のデータ転送をサポートする、重要なソフトウェア・ルーチンのセットである。ＢＩＯＳは、コンピュータ５００が起動されたときにＢＩＯＳが実行されうるように、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの何らかのタイプのリードオンリ・メモリに記憶される。

コンピュータ５００の動作時に、プロセッサ５１０は、メモリ５２０内に記憶されたソフトウェアを実行し、メモリ５２０との間でデータを通信し、ソフトウェアにしたがってコンピュータ５００の動作を一般的に制御するように構成される。アプリケーション５６０およびＯ／Ｓ５５０は、プロセッサ５１０によって全体的または部分的に読み出され、場合によってはプロセッサ５１０内にバッファされ、次いで実行される。

アプリケーション５６０がソフトウェアで実装されるときには、アプリケーション５６０は、任意のコンピュータ関連システムもしくは方法によってまたはそれらに関連して使用するために事実上任意のコンピュータ可読媒体に記憶されうることに留意しなければならない。本文書の文脈では、コンピュータ可読媒体は、コンピュータ関連システムもしくは方法によってまたはそれらに関連して使用するためにコンピュータ・プログラムを含むかまたは記憶しうる電子、磁気、光、または他の物理デバイスもしくは手段でありうる。

アプリケーション５６０は、命令実行システム、装置またはデバイス、例えばコンピュータベースのシステム、プロセッサを含むシステム、または命令実行システム、装置もしくはデバイスから命令を取得してそれらの命令を実行しうる他のシステムによってまたはそれらに関連して使用するために任意のコンピュータ可読媒体において具体化されうる。本文書の文脈において、「コンピュータ可読媒体」は、命令実行システム、装置、またはデバイスによってまたはそれらに関連して使用するためにプログラムを記憶、通信、伝搬、または輸送しうる任意の手段でありうる。コンピュータ可読媒体は、例えば電子、磁気、光、電磁、赤外線、または半導体システム、装置、デバイス、または伝搬媒体でありうるがこれらに限定されない。

本出願の文脈において、本開示の実施形態が方法を構成する場合、そのような方法はコンピュータによる実行のためのプロセス、すなわちコンピュータにより実施可能な方法であることが理解されねばならない。したがって、方法の様々なステップは、コンピュータ・プログラムの様々な部分、例えば一つ以上のアルゴリズムの様々な部分を反映する。

本発明は、任意の可能な技術的詳細レベルの統合におけるシステム、方法、装置、もしくはコンピュータ・プログラム製品またはそれらの組み合わせでありうる。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実施させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体（単数または複数）を含みうる。

コンピュータ可読記憶媒体は、命令実行デバイスにより使用するための命令を保持および記憶しうる有形のデバイスでありうる。コンピュータ可読記憶媒体は、例えば電子記憶デバイス、磁気記憶デバイス、光記憶デバイス、電磁記憶デバイス、半導体記憶デバイス、または以上の任意の適切な組み合わせでありうるがこれらに限定されない。コンピュータ可読記憶媒体のより具体的な例の非網羅的なリストは、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリ・メモリ（ＲＯＭ：ｒｅａｄ‐ｏｎｌｙ ｍｅｍｏｒｙ）、消去可能プログラム可能リードオンリ・メモリ（ＥＰＲＯＭすなわちフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク・リードオンリ・メモリ（ＣＤ‐ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、メモリ・スティック、フレキシブル・ディスク、パンチカードまたは命令が記録された溝内の隆起構造などの機械的にエンコードされたデバイス、および以上の任意の適切な組み合わせを含む。本明細書で使用されるところのコンピュータ可読記憶媒体は、電波もしくは他の自由に伝播する電磁波、導波路もしくは他の伝送媒体を通じて伝播する電磁波（例えば光ファイバ・ケーブルを通過する光パルス）、またはワイヤを通じて伝送される電気信号などの一時的信号そのものと解釈されてはならない。

本明細書に記載されるコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれのコンピューティング／処理デバイスに、または、ネットワーク、例えばインターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワークもしくは無線ネットワークまたはその組み合わせを介して外部コンピュータもしくは外部ストレージ・デバイスにダウンロードされうる。ネットワークは、銅線伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、もしくはエッジ・サーバまたはその組み合わせを含みうる。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インタフェースは、ネットワークからコンピュータ可読プログラム命令を受け取り、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体への記憶のためにコンピュータ可読プログラム命令を転送する。

本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ‐ｓｅｔ‐ａｒｃｈｉｔｅｃｔｕｒｅ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路のための構成データ、または、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは類似のプログラミング言語などの手続き型プログラミング言語を含む一つ以上のプログラミング言語の任意の組み合わせで書かれたソース・コードもしくはオブジェクト・コードでありうる。コンピュータ可読プログラム命令は、全体的にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンド・アロンのソフトウェア・パッケージとして、部分的にユーザのコンピュータ上で、および部分的に遠隔コンピュータ上で、または全体的に遠隔コンピュータもしくはサーバ上で、実行しうる。後者のシナリオにおいて、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）またはワイド・エリア・ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）を含む任意のタイプのネットワークを通じてユーザのコンピュータに接続されることができ、または（例えばインターネット・サービス・プロバイダを使用してインターネットを通じて）外部コンピュータに接続がなされうる。いくつかの実施形態において、例えばプログラム可能論理回路、フィールド・プログラム可能ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ‐ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、またはプログラム可能論理アレイ（ＰＬＡ：ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ａｒｒａｙ）を含む電子回路は、本発明の態様を行うためにコンピュータ可読プログラム命令の状態情報を利用して電子回路をパーソナライズすることによってコンピュータ可読プログラム命令を実行しうる。

本発明の態様は、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して本明細書に説明される。フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方のブロックの組み合わせは、コンピュータ可読プログラム命令によって実装されうることが理解されよう。

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行する命令がフローチャートもしくはブロック図またはその両方の一つまたは複数のブロックに指定された機能／行為を実施するための手段を生み出すように、コンピュータまたは他のプログラム可能データ処理装置のプロセッサに提供されて機械を生成しうる。これらのコンピュータ可読プログラム命令は、命令が記憶されたコンピュータ可読記憶媒体がフローチャートもしくはブロック図またはその両方の一つまたは複数のブロックに指定された機能／行為の態様を実施する命令を含む製造品を含むように、コンピュータ、プログラム可能データ処理装置もしくは他のデバイスまたはそれらの組み合わせに特定の様式で機能するように指示しうるコンピュータ可読記憶媒体に記憶されてもよい。

コンピュータ可読プログラム命令は、コンピュータ、他のプログラム可能装置、または他のデバイス上で実行する命令がフローチャートもしくはブロック図またはその両方の一つまたは複数のブロックに指定された機能／行為を実施するように、コンピュータ実施プロセスを生成するために、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードされてコンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作行為を行わせることもできる。

図面のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実施態様のアーキテクチャ、機能、および動作を示す。この点に関して、フローチャートまたはブロック図の各ブロックは、指定された論理機能（単数または複数）を実施するための一つ以上の実行可能命令を含むモジュール、セグメント、または命令の部分を表しうる。いくつかの代替的実施態様では、ブロックに記された機能は、図面に記された順序とは異なる順序で生じうる。例えば、連続して示される二つのブロックは、実際には、関連する機能に応じて一つのステップとして達成され、部分的または全体的に時間的に重複する様式で同時に、実質的に同時に実行されてもよく、またはブロックは逆の順序で実行されうる場合もある。ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方のブロックの組み合わせは、指定された機能または行為を行うかまたは専用ハードウェアおよびコンピュータ命令の組み合わせを遂行する専用ハードウェアベースのシステムによって実施されうることにも留意されたい。

本開示の様々な実施形態の記載は、例示の目的で提示されているが、網羅的であることまたは開示された実施形態に限定されることを意図するものではない。多数の修正およびバリエーションが、記載された実施形態の範囲および精神から逸脱することなく、通常の技術を有する当業者に明らかになるであろう。本明細書で使用される用語は、実施形態の原理、実際の応用例もしくは市販の技術に対する技術的改良を最もよく説明するため、または通常の技術を有する他の当業者が本明細書に開示された実施形態を理解できるようにするために選択されたものである。

本開示は、コンテナベースのアプリケーションを調整するための方法であって、コンテナベースのアプリケーションは一つ以上の関数呼び出しを処理するように適合される、方法を提供する。このような方法は、コンテナベースのアプリケーションで一つ以上の関数呼び出しを受信するステップと、コンテナベースのアプリケーションを使用して一つ以上の関数呼び出しを処理するステップとを含む。一つ以上の関数呼び出しの処理に基づいてコンテナベースのアプリケーションから性能データが取得され、性能データが性能尺度限界に照らして分析される。性能データの分析に基づいてコンテナベースのアプリケーションのリソースまたは機能が調整される。

本開示は、プロセッサ上で実行されたときに提案された構想を実施するためのコンピュータ・プログラム・コードを含むコンピュータ・プログラム製品をさらに提供しようとする。

本開示は、このコンピュータ・プログラム・コードを実行するように適合されたシステム（処理デバイスもしくはネットワーク・コンポーネントまたはその両方等）をさらに提供しようとする。

本開示のさらなる実施形態によれば、コンテナベースのアプリケーションを調整するためのコンピュータ・プログラム製品であって、コンテナベースのアプリケーションは一つ以上の関数呼び出しを処理するように適合される、コンピュータ・プログラム製品が本明細書に提供され、コンピュータ・プログラム製品は、プログラム命令が具体化されたコンピュータ可読記憶媒体を含み、プログラム命令は、コンテナベースのアプリケーションで一つ以上の関数呼び出しを受信するステップと、コンテナベースのアプリケーションを使用して一つ以上の関数呼び出しを処理するステップと、一つ以上の関数呼び出しの処理に基づいてコンテナベースのアプリケーションから性能データを取得するステップと、性能データを性能尺度限界に照らして分析するステップと、性能データの分析に基づいてコンテナベースのアプリケーションのリソースもしくは機能またはその両方を調整するステップとを含む方法を処理ユニットに行わせるために処理ユニットによって実行可能である。

さらに別の態様によれば、コンテナベースのアプリケーションを調整するためのシステムであって、コンテナベースのアプリケーションは一つ以上の関数呼び出しを処理するように適合される、システムが提供され、システムは、一つ以上の関数呼び出しを受信するように適合された受信ユニットと、コンテナベースのアプリケーションを使用して一つ以上の関数呼び出しを処理し、一つ以上の関数呼び出しの処理に基づいてコンテナベースのアプリケーションから性能データを取得し、性能データを性能尺度限界に照らして分析し、性能データの分析に基づいてコンテナベースのアプリケーションのリソースもしくは機能またはその両方を調整するように適合された処理ユニットとを含む。

Claims (21)

1. コンテナベースのアプリケーションで一つ以上の関数呼び出しを受信するステップと、
   前記コンテナベースのアプリケーションを使用して前記一つ以上の関数呼び出しを処理するステップと、
   前記一つ以上の関数呼び出しの前記処理に基づいて前記コンテナベースのアプリケーションから性能データを取得するステップと、
   前記性能データを性能尺度限界に照らして分析するステップと、
   前記性能データの前記分析に基づいて前記コンテナベースのアプリケーションの態様を調整するステップと
   を含むコンピュータ実施方法であって、
   前記態様は、前記コンテナベースのアプリケーションのリソースおよび機能を含む群より選択される一つ以上である、
   コンピュータ実施方法。
2. 前記性能データを前記性能尺度限界に照らして分析するステップは、前記性能尺度限界に達しているか否かを判断するステップを含む、請求項１に記載のコンピュータ実施方法。
3. 前記性能データを前記性能尺度限界に照らして分析するステップは、所定の期間内に前記性能尺度限界に達するか否かを判断するステップを含む、請求項１に記載のコンピュータ実施方法。
4. 前記性能データを分析するステップは、
   前記一つ以上の関数呼び出しを処理するための処理時間を判断するステップと、
   前記分析された性能データに基づいて曲線の折れ曲がりを識別するステップであって、前記曲線の折れ曲がりは、前記処理時間が所定の閾値を超える場合に識別される、ステップと
   を含む、請求項１に記載のコンピュータ実施方法。
5. 前記性能尺度限界は、
   物理リソース限界、
   仮想リソース限界、
   コンテナ・リソース限界、および
   予め定義されたスケーリング限界
   を含む群より選択されるスケーラビリティ限界と、
   コスト限界と、
   応答性限界と、
   実行あたりのＣＰＵ利用と、
   コンテナのＣＰＵ利用と、
   メモリ利用と、
   ネットワーク・スループットと、
   ネットワーク・レイテンシと、
   ストレージ・スループットと、
   ストレージ・レイテンシと、
   リクエスト応答時間と、
   一秒あたりのトランザクションの数と、
   失敗率と
   を含む群より選択される、請求項１に記載のコンピュータ実施方法。
6. 前記リソースは、
   コンピューティング・リソースと、
   実行アーキテクチャ・リソースと
   を含む群より選択される、請求項１に記載のコンピュータ実施方法。
7. 前記リソースは、
   Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅアーキテクチャと、
   Ｆｕｎｃｔｉｏｎ ａｓ ａ Ｓｅｒｖｉｃｅアーキテクチャと
   を含む群より選択される実行アーキテクチャ・リソースである、請求項１に記載のコンピュータ実施方法。
8. 前記機能はフロントエンド機能を含み、前記フロントエンド機能は、
   表示されるデータの量と、
   許容される複雑なトランザクションの数と、
   利用可能なアプリケーション・オプションの数と
   を含む群より選択される、請求項１に記載のコンピュータ実施方法。
9. 前記機能はバックエンド機能を含み、前記バックエンド機能は、
   シンセティック・トランザクションの数と、
   ログの量と、
   同期トランザクションの数と、
   非同期トランザクションの数と
   を含む群より選択される、請求項１に記載のコンピュータ実施方法。
10. 前記コンテナベースのアプリケーションの前記機能を調整するステップは、フロントエンド機能を使用してバックエンド機能を行うステップを含む、請求項１に記載のコンピュータ実施方法。
11. プログラム命令が具体化されたコンピュータ可読記憶媒体を含むコンピュータ・プログラム製品であって、前記コンピュータ可読記憶媒体は、一時的信号そのものではなく、前記プログラム命令は、
    コンテナベースのアプリケーションで一つ以上の関数呼び出しを受信するステップと、
    前記コンテナベースのアプリケーションを使用して前記一つ以上の関数呼び出しを処理するステップと、
    前記一つ以上の関数呼び出しの前記処理に基づいて前記コンテナベースのアプリケーションから性能データを取得するステップと、
    前記性能データを性能尺度限界に照らして分析するステップと、
    前記性能データの前記分析に基づいて前記コンテナベースのアプリケーションの態様を調整するステップと
    を含む方法をプロセッサに行わせるために前記プロセッサによって実行可能であり、
    前記態様は、前記コンテナベースのアプリケーションのリソースおよび機能を含む群より選択される一つ以上である、
    コンピュータ・プログラム製品。
12. 前記性能データを前記性能尺度限界に照らして分析するステップは、
    所定の期間内に前記性能尺度限界に達するか否かを判断するステップ
    を含む、請求項１１に記載のコンピュータ・プログラム製品。
13. 前記性能データを分析するステップは、
    前記一つ以上の関数呼び出しを処理するための処理時間を判断するステップと、
    前記分析された性能データに基づいて曲線の折れ曲がりを識別するステップであって、前記曲線の折れ曲がりは、前記処理時間が所定の閾値を超える場合に識別される、ステップと
    を含む、請求項１１に記載のコンピュータ・プログラム製品。
14. 前記性能尺度限界は、
    物理リソース限界、
    仮想リソース限界、
    コンテナ・リソース限界、および
    予め定義されたスケーリング限界
    を含む群より選択されるスケーラビリティ限界と、
    コスト限界と、
    応答性限界と、
    実行あたりのＣＰＵ利用と、
    コンテナのＣＰＵ利用と、
    メモリ利用と、
    ネットワーク・スループットと、
    ネットワーク・レイテンシと、
    ストレージ・スループットと、
    ストレージ・レイテンシと、
    リクエスト応答時間と、
    一秒あたりのトランザクションの数と、
    失敗率と
    を含む群より選択される、請求項１１に記載のコンピュータ・プログラム製品。
15. プロセッサと、
    前記プロセッサに通信可能に連結され、前記プロセッサによって実行されたときに、
    コンテナベースのアプリケーションで一つ以上の関数呼び出しを受信するステップと、
    前記コンテナベースのアプリケーションを使用して前記一つ以上の関数呼び出しを処理するステップと、
    前記一つ以上の関数呼び出しの前記処理に基づいて前記コンテナベースのアプリケーションから性能データを取得するステップと、
    前記性能データを性能尺度限界に照らして分析するステップと、
    前記性能データの前記分析に基づく前記コンテナベースのアプリケーションの態様であって、前記コンテナベースのアプリケーションのリソースおよび機能を含む群より選択される一つ以上である、態様と
    を含む方法を前記プロセッサに行わせるプログラム命令を記憶するコンピュータ可読記憶媒体と
    を含むシステム。
16. 前記性能データを前記性能尺度限界に照らして分析するステップは、前記性能尺度限界に達しているか否かを判断するステップを含む、請求項１５に記載のシステム。
17. 前記性能データを前記性能尺度限界に照らして分析するステップは、所与の期間内に前記性能尺度限界に達するか否かを判断するステップを含む、請求項１５に記載のシステム。
18. 前記性能データを前記性能尺度限界に照らして分析するステップは、
    前記一つ以上の関数呼び出しを処理するための処理時間を判断するステップと、
    前記分析された性能データに基づいて曲線の折れ曲がりを識別するステップであって、前記曲線の折れ曲がりは、前記処理時間が所定の閾値を超える場合に識別される、ステップと
    を含む、請求項１５に記載のシステム。
19. 前記機能は、
    表示されるデータの量と、
    許容される複雑なトランザクションの数と、
    利用可能なアプリケーション・オプションの数と
    を含む群より選択されるフロントエンド機能を含む、請求項１５に記載のシステム。
20. 前記機能は、
    シンセティック・トランザクションの数と、
    ログの量と、
    同期トランザクションの数と、
    非同期トランザクションの数と
    を含む群より選択されるバックエンド機能を含む、請求項１５に記載のシステム。
21. プログラムがコンピュータ上で実行されたときに請求項１～１０のいずれか一項に記載の方法を行うように適合されたプログラム・コード手段を含む、コンピュータ・プログラム。

Images