JP2022142986A - 課金プログラム、課金装置、及び課金方法 - Google Patents

Abstract

【課題】コンテナで実行されるアプリケーションプログラムに課金できるようにすること。【解決手段】コンテナに割り当てられたリソース量を示す通知をコンテナから受け付け、課金期間内に通知があった場合に、リソース量に応じた額を、コンテナが実行するアプリケーションプログラムの課金額として算出する処理をコンピュータに実行させるための課金プログラムによる。【選択図】図５

Description

本発明は、課金プログラム、課金装置、及び課金方法に関する。

コンピュータを仮想化する技術としてVM(Virtual Machine)仮想化技術とコンテナ仮想化技術が知られている。このうち、VM仮想化技術は、ホストOS(Operating System)の上でゲストOSを実行することにより仮想化を行う技術であり、ゲストOSを実行するためのオーバヘッドが大きい。

一方、コンテナ仮想化技術は、OSのカーネルの一部を利用して仮想化を行うため、VM仮想化技術と比較して仮想化のオーバヘッドが小さく軽量であるという利点がある。そのコンテナ仮想化技術においては、互いに独立した複数のユーザ空間が生成される。これらのユーザ空間はコンテナと呼ばれ、そのコンテナの各々においてアプリケーションプログラムが実行される。

コンテナを利用したサービスの一つに、コンテナ内で実行するアプリケーションプログラムに課金する課金サービスがある。課金サービスにおいては、アプリケーションプログラムの種類や課金期間の長さに応じた額の利用料金をコンテナの利用者に課金する。

しかしながら、コンテナは、セキュリティのために外部からアクセスするのが難しく、コンテナで実行しているアプリケーションプログラムに適切に課金するのが困難である。

特開２００１－５８７７号公報 特開２０００－１１３０６６号公報

一側面によれば、コンテナで実行されるアプリケーションプログラムに課金できるようにすることを目的とする。

一側面によれば、コンテナに割り当てられたリソース量を示す通知を前記コンテナから受け付け、課金期間内に前記通知があった場合に、前記リソース量に応じた額を、前記コンテナが実行するアプリケーションプログラムの課金額として算出する処理をコンピュータに実行させるための課金プログラムが提供される。

一側面によれば、コンテナで実行されるアプリケーションプログラムに課金できる。

図１は、VM仮想化技術を使用した場合のシステムの構成図である。 図２は、課金装置がアプリの課金額を算出する方法について示す模式図である。 図３は、コンテナ仮想化技術を採用した物理サーバの構成図である。 図４は、問題について示す模式図である。 図５は、本実施形態に係る課金方法の概略を示す模式図である。 図６は、コンテナ稼働情報の模式図である。 図７は、コンテナが課金装置に定期的にコンテナ稼働情報を通知するときの模式図（その１）である。 図８は、コンテナが課金装置に定期的にコンテナ稼働情報を通知するときの模式図（その２）である。 図９は、コンテナが課金装置に定期的にコンテナ稼働情報を通知するときの模式図（その３）である。 図１０は、本実施形態における課金額の算出ロジックを説明するための物理サーバの模式図である。 図１１は、図１０のように各コンテナが起動している場合の各アプリの課金額の算出ロジックを示す模式図である。 図１２は、本実施形態における課金額の算出ロジックの別の例を説明するための物理サーバの模式図である。 図１３は、図１２のように各コンテナが起動している場合の各アプリの課金額の算出ロジックを示す模式図である。 図１４は、コンテナの機能構成図である。 図１５は、課金装置の機能構成図である。 図１６は、コンテナが実行する処理のフローチャートである。 図１７は、課金装置が実行する処理のフローチャートである。 図１８は、課金装置のハードウェア構成図である。 図１９は、物理サーバのハードウェア構成図である。

本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。

前述のように、コンピュータの仮想化技術としてはVM仮想化技術とコンテナ仮想化技術とがある。まず、VM仮想化技術におけるアプリケーションプログラムの課金方法について説明する。

図１は、VM仮想化技術を使用した場合のシステムの構成図である。図１に示すように、システム１は、インターネット等のネットワーク２を介して相互に接続された物理サーバ３と課金装置４とを有する。

このうち、物理サーバ３は、課金対象のアプリケーションプログラムを実行するコンピュータであって、メモリやCPU(Central Processing Unit)等のハードウェアリソース１１を有する。そして、ハードウェアリソース１１に含まれるメモリとCPU(Central Processing Unit)が協働してホストOS１２を実行し、更にホストOS１２の上でハードウェアリソース１１が複数の仮想マシン１３を実行する。

仮想マシン１３は、ハードウェアリソース１１の一部が割り当てられた仮想的なコンピュータであって、ゲストOS１４を実行する。更に、各仮想マシン１３は、ゲストOS１４の上でアプリ１５を実行する。各アプリ１５は、課金対象のアプリケーションプログラムである。

一方、課金装置４は、アプリ１５の課金額を算出するための物理サーバや仮想マシン等のコンピュータである。

図２は、課金装置４がアプリ１５の課金額を算出する方法について示す模式図である。

図２に示すように、課金装置４は、仮想マシン１３が起動しているかどうかを確認する確認通知７を仮想マシン１３に定期的に通知する。課金装置４は、その確認通知７に対する応答８が仮想マシン１３からあった場合には当該仮想マシン１３が起動していると判断し、応答がなかった場合には当該仮想マシン１３は停止していると判断する。

更に、課金装置４は、仮想マシン１３が最初に起動していると判断したときから停止していると判断した期間を仮想マシン１３の稼働期間Tとして特定する。この例では、稼働期間Tにおいてアプリ１５も起動していたものとし、課金装置４は、稼働期間Tの長さに応じたアプリ１５の課金額を算出する。

このように、VM仮想化技術を使用している場合には、課金装置４が仮想マシン１３に対して確認通知７を通知することで稼働期間Tを特定することができ、その稼働期間Tに応じた課金額を算出できる。

しかしながら、この方法をコンテナ仮想化技術に適用すると以下のような問題がある。

図３は、コンテナ仮想化技術を採用した物理サーバ３の構成図である。なお、図３において、図１で説明したのと同じ要素には図１におけるのと同じ符号を付し、以下ではその説明を省略する。

図３に示すように、この例では、仮想マシン１３の各々がゲストOS１４の上でコンテナエンジン１８を実行する。コンテナエンジン１８は、コンテナを生成するためのDOCKER（登録商標）等のプログラムである。

コンテナの個数は特に限定されないが、この例では各仮想マシン１３が全部でm個のコンテナ１９を起動するものとし、各々のコンテナ１９を「#1」、「#2」、…、「#m」等の文字列で識別する。各々のコンテナ１９は、仮想マシン１３のCPU等のリソースが割り当てられた一つのコンピュータである。また、各々のコンテナ１９は課金対象のアプリ１５を実行する。

なお、各々の仮想マシン１３は全体として一つのクラスタコンピュータを実現する。以下では、一つのクラスタコンピュータのことを単にクラスタと呼ぶ。

更に、クラスタに属する複数の仮想マシン１３のうちの一つは、m個のコンテナ１９を管理するためのコンテナ管理プログラム２０を実行する。コンテナ管理プログラム２０は、コンテナオーケストレーションプログラムとも呼ばれ、例えばKubernetes（登録商標）やOpenShift（登録商標）等がその一例である。

このようにコンテナ１９が実行しているアプリ１５の課金額を課金装置４が算出するには、図２の例に倣ってコンテナ１９が起動しているかどうかの確認通知７を課金装置４が各コンテナ１９に通知すればよいと考えられる。

しかし、課金装置４は、コンテナ管理プログラム２０を介さないと各コンテナ１９にアクセスできず、しかもコンテナ１９への不正アクセスを防止するためにコンテナ管理プログラム２０はコンテナ１９のIPアドレスを公開していない。そのため、課金装置４が各コンテナ１９に確認通知７を通知して課金額を算出することはできない。

更に、コンテナ１９が実行するアプリ１５の課金額を算出しようとする場合、以下のような問題も生じる。

図４は、その問題について示す模式図である。図４の例では、アプリ１５を実行している「#1」のコンテナ１９が最初に起動しており、それが何等かの不具合によって停止した場合を想定している。この場合にはコンテナ管理プログラム２０が「#2」のコンテナ１９を起動し、その「#2」のコンテナ１９がアプリ１５を実行する。更に、「#2」のコンテナ１９が何等かの不具合によって停止すると、コンテナ管理プログラム２０が「#3」のコンテナ１９を起動し、その「#3」のコンテナ１９がアプリ１５を実行する。

また、この例では、同時に起動しているコンテナ１９の個数に応じてアプリ１５の課金額を設定するものとする。例えば、同時に起動しているコンテナ１９の個数が２個の場合は、１個のコンテナ１９のみが起動している場合の２倍の課金額とする。

このように課金額を設定する場合、課金装置４は、同時に起動しているコンテナ１９の個数を正確に特定する必要がある。しかしながら、前述のように課金装置４からコンテナ１９に確認通知７を通知することができないため、コンテナ１９は同時に稼働しているコンテナ１９の個数を特定することができない。更に、コンテナ１９は頻繁に起動と停止を繰り返すことがあるので、同時に起動しているコンテナ１９の個数を常に把握し続けるのは難しい。その結果、実際には１個のコンテナ１９しか起動していないにも関わらず、課金装置４が誤って２個のコンテナ１９が起動していると判断してしまい。本来の２倍の課金額を算出するおそれがある。

また、このように同時に起動しているコンテナ１９の個数に応じてアプリ１５の課金額を設定する方法では、コンテナ１９の個数が大量に増大した場合に課金額が急激に増えるため、アプリ１５の利用者が納得するような課金額とならない。以下、本実施形態について説明する。

（本実施形態）
図５は、本実施形態に係る課金方法の概略を示す模式図である。なお、図５において、図１～図４で説明したのと同じ要素にはこれらの図におけるのと同じ符号を付し、以下ではその説明を省略する。

まず、コンテナ１９の利用者によって、課金装置４から仮想マシン１３にモジュールプログラム３２がダウンロードされる（ステップＳ１）。モジュールプログラム３２は、コンテナ１９を起動するためのDockerfile等の定義ファイルを含むプログラムである。

次に、コンテナの利用者によって、モジュールプログラム３２を内包するコンテナ１９のイメージファイル３３が作成される（ステップＳ２）。

次いで、コンテナの利用者によって、イメージファイル３３を利用してコンテナ１９が起動される（ステップＳ３）。前述のモジュールプログラム３２にはアプリ１５とソフト管理デーモン３４とが同梱されているため、コンテナ１９の内部でアプリ１５とソフト管理デーモン３４とを実行することができる。なお、ソフト管理デーモン３４は、課金装置４がアプリ１５の課金額を算出できるようにするための常駐プログラムである。

次に、ソフト管理デーモン３４が、課金装置４に対して定期的にコンテナ稼働情報３５の通知を行う（ステップＳ４）。

図６は、コンテナ稼働情報３５の模式図である。図６に示すように、コンテナ稼働情報３５は、バージョン情報３５ａ、契約情報３５ｂ、管理情報３５ｃ、及びメータリング情報３５ｄを含む。

このうち、バージョン情報３５ａは、モジュールプログラム３２のバージョンを示す情報である。契約情報３５ｂは、契約内容を識別する契約IDである。

また、管理情報３５ｃは、Kubernetes等のコンテナ管理プログラム２０を実行している仮想マシン１３が管理している情報であって、ID、合計vCPU数、合計Node数、及び名前空間を含む。このうち、IDは、コンテナ管理プログラム２０がシステムコンポーネントやアドオンを配備する名前空間を一意に識別する識別子である。合計vCPU数は、同一のクラスタに属する全てのコンテナ１９に割り当てられたCPUの総数である。また、合計Node数は、同一のクラスタに属する仮想マシン１３の総数である。

一方、名前空間は、各コンテナ１９を含むクラスタの空間であって、名前とIDとを有する。このうち、名前はクラスタの名前であり、IDはクラスタを一意に識別する識別子である。

メータリング情報３５ｄは、名前、ID、vCPU数、及びコンテナ情報の各々をPod情報として配列要素に含む情報である。このうち、名前は、コンテナ１９を含むPodの名前であり、IDはPodを一意に識別する識別子である。なお、Podは、コンテナ管理プログラム２０が管理するコンテナ１９の最小単位である。vCPU数は、リソース量の一例であって、Pod内のコンテナ１９に割り当てられたCPUの数である。

一方、コンテナ情報は、ID、稼働情報取得日時、vCPU数上限値、及びソフトウェア情報の各々を含む情報である。このうち、IDはコンテナ１９を一意に識別する識別子である。また、稼働情報取得日時は、コンテナ稼働情報３５を取得した日時である。vCPU数上限値は、一つのコンテナ１９に割り当て可能なvCPU数の上限値である。そして、ソフトウェア情報は、アプリ１５のライセンスコードである。

ソフト管理デーモン３４は、このようにメータリング情報３５ｄにvCPU数を含むコンテナ稼働情報３５を１５分程度の周期で課金装置４に通知する。

再び図５を参照する。その後、課金装置４の制御部３１がコンテナ稼働情報３５に基づいてアプリ１５の課金額を算出し、該課金額を出力する（ステップＳ５）。この例では、制御部３１は、コンテナ稼働情報３５の通知を受け続けている間は、コンテナ１９が起動していると判断する。また、制御部３１は、課金期間内にコンテナ稼働情報３５の通知が一度でもあった場合には、その課金期間の長さに応じた課金額を算出する。

以上により、本実施形態に係る課金方法の基本的な処理を終える。

図７は、ステップＳ４においてコンテナ１９が課金装置４に定期的にコンテナ稼働情報３５を通知するときの模式図（その１）である。この例では、「#1」のコンテナ１９が起動しており、「#2」と「#3」のコンテナ１９は停止している場合を想定している。

この場合は、課金装置４の制御部３１は、「#1」のコンテナ１９から定期的にコンテナ稼働情報３５を受け、これにより「#1」のコンテナ１９が起動していると判断する。なお、図７とこれ以降の図では、「#n」のコンテナ１９が起動していると制御部３１が判断した状況を「生存n」で示す。

また、制御部３１は、「#2」と「#3」のコンテナ１９からコンテナ稼働情報３５を受けていないため、これらのコンテナ１９は停止していると判断する。

図８は、コンテナ１９が課金装置４に定期的にコンテナ稼働情報３５を通知するときの模式図（その２）である。

図８の例では、不具合によって「#1」のコンテナ１９が途中で停止し、これを受けてコンテナ管理プログラム２０が「#2」のコンテナ１９を起動した場合を想定している。なお、図７と以降の図では、ある時刻において同時に起動しているコンテナ１９の個数がn個である状況を「n多重」と呼ぶ。図７では全ての時刻で１多重となっているため、同時に起動しているコンテナ１９の個数は全ての時刻で１個ということになる。

また、この例では、「#1」のコンテナ１９は、自コンテナが停止した後にはコンテナ稼働情報３５を課金装置４に通知しなくなる。課金装置４の制御部３１は、「#1」のコンテナ１９からコンテナ稼働情報３５の通知を最後に受けてから２周期（３０分）が経過してもコンテナ稼働情報３５の通知がない場合、「#1」のコンテナ１９は停止したと判断する。図８とこれ以降の図では、「#n」のコンテナ１９が停止したと制御部３１が判断した状況を「死亡n」で示す。

一方、「#2」のコンテナ１９は、自コンテナが起動してから課金装置４に周期的にコンテナ稼働情報３５を通知する。この通知を受けた課金装置４の制御部３１は、「#2」のコンテナ１９が起動したものと判断する。

更に、本実施形態ではコンテナ１９が自ら課金装置４に対してコンテナ稼働情報３５を通知する。そのため、この例のように「#1」のコンテナ１９が停止した後に「#2」のコンテナ１９が起動した場合、「#1」と「#2」の両方のコンテナ１９が課金装置４に同時にコンテナ稼働情報３５を通知することがない。そのため、課金装置４の制御部３１が、「#1」と「#2」の両方のコンテナ１９が同時に起動していると誤って判断するのを防止でき、「#1」と「#2」の両方のコンテナ１９のアプリ１５に対して二重に課金するのを防止できる。

図９は、コンテナ１９が課金装置４に定期的にコンテナ稼働情報３５を通知するときの模式図（その３）である。

図９の例では、不具合によって「#1」のコンテナ１９が停止する前に、コンテナ１９の利用者によって「#2」のコンテナ１９が起動された場合を例示している。この場合は、「#1」と「#2」のコンテナ１９が同時に起動している２多重の期間が存在することになる。

同様に、「#2」のコンテナ１９が停止する前にコンテナの利用者が「#3」のコンテナ１９を起動したため、「#2」と「#3」のコンテナ１９が同時に起動している２多重の期間も存在する。

図１０は、本実施形態における課金額の算出ロジックを説明するための物理サーバ３の模式図である。

図１０では、ある時刻において「#1」～「#8」のコンテナ１９が起動しているときの物理サーバ３を例示している。また、課金対象のアプリ１５の名前としてA～Cの三つが存在するものとする。

本実施形態では、各コンテナ１９に割り当てられたリソース量を、当該コンテナ１９を実行している仮想マシン１３に割り当てられたリソース量に等しいものとする。また、以下ではリソース量としてCPUの個数を例にして説明する。なお、図６のコンテナ稼働情報３５に示したように、仮想マシン１３に割り当てられたCPUをvCPUと呼び、その個数をvCPU数と呼ぶ。
例えば「#1」のコンテナ１９について考える。「#1」のコンテナ１９を実行している仮想マシン１３のvCPU数は２個である。よって、「#1」のコンテナ１９のvCPU数も２個となる。

また、「#2」と「#3」のコンテナ１９は、vCPU数が４個の仮想マシン１３が実行している。この場合、「#2」と「#3」の各々のコンテナ１９のvCPUの数は４個となる。

本実施形態では、コンテナ１９のvCPU数に応じて、そのコンテナ１９が実行するアプリ１５の課金額を課金装置４が以下の算出ロジックで算出する。

図１１は、図１０のように各コンテナ１９が起動している場合の各アプリ１５の課金額の算出ロジックを示す模式図である。

まず、名前がAのアプリ１５について考える。「単価」は、名前がAのアプリ１５を課金期間内に１つだけ使用する場合の料金である。課金期間は、月額課金の場合は１か月であり、日額課金の場合は１日である。「単価」は、課金期間の長さに応じて予め設定され、課金期間が長くなるほど高くなる。

「vCPU係数」は、名前がAのアプリ１５を実行したときにvCPUに加わる負荷を示す係数であり、その値が大きいほどvCPUの使用量が大きくなる。

「ライセンス数」は、名前がAのアプリ１５を実行するコンテナ１９のvCPU数の総数とvCPU係数との積である。なお、当該積の結果の小数点以下は切り上げるものとする。名前がAのアプリ１５ではvCPU数の総数は「2+(4+4)+2+4+0」であり、vCPU係数は「0.5」であるから、これらの積は「8」となる。

「課金額」は、ライセンス数と単価との積であり、名前がAのアプリ１５については「8,000 [JPY]」となる。

このような課金額の算出方法によれば、一つの仮想マシン１３が複数のコンテナ１９を実行している場合、これらのコンテナ１９のvCPU数が多いほどアプリ１５の課金額が増える。これにより、コンテナ１９の個数が増えて実行中のアプリ１５が増えるほど課金額が増えるため、アプリ１５を提供するサービス提供者にとって納得のいく課金体系を実現できる。

なお、「#1」～「#8」のコンテナ１９は課金装置４に定期的にコンテナ稼働情報３５を通知するが、図６に示したようにコンテナ稼働情報３５にはアプリ１５のライセンスコードやコンテナ１９のvCPU数も含まれている。課金装置４は、課金期間内にいずれかのコンテナ１９からコンテナ稼働情報３５の通知が一度でもあった場合、コンテナ稼働情報３５からアプリ１５の名前やコンテナ１９のvCPU数を特定し、図１０の算出ロジックに従って課金額を算出する。

名前がBとCのアプリ１５についてもこれと同様にして課金装置４が算出する。

なお、課金額の算出方法はこれに限定されず、以下のように課金装置４が課金額を算出してもよい。

図１２は、本実施形態における課金額の算出ロジックの別の例を説明するための物理サーバ３の模式図である。

図１２の例では、コンテナ１９に割り当てられたvCPU数を課金額の算出に使用しないため、各コンテナ１９にvCPU数を明示していない。また、「#1」のコンテナ１９が使用可能なvCPUの数は１個に制限されているとする。

図１３は、図１２のように各コンテナ１９が起動している場合の各アプリ１５の課金額の算出ロジックを示す模式図である。

まず、名前がAのアプリ１５について考える。「単価」と「vCPU係数」は図９におけるのと同じである。

「ライセンス数」は、図９の例とは異なり、物理サーバ３で起動している複数の仮想マシン１３のvCPU数の総数とvCPU係数との積である。この例では、仮想マシン１３のvCPU数の総数は「2+4+2+4+4」である。なお、「#1」のコンテナ１９のvCPU数が１個に制限されているが、vCPU数の総数を求める際にはvCPU数の制限については考慮しない。また、名前がAのアプリ１５のvCPU係数は「0.5」であるから、vCPU数の総数とvCPU係数との積は「8」となる。

「課金額」は、ライセンス数と単価との積であり、名前がAのアプリ１５については「8,000 [JPY]」となる。

このような課金額の算出方法によれば、課金額は複数の仮想マシン１３のvCPU数の総数に応じた額となる。そのため、一つの仮想マシン１３が実行する複数のコンテナ１９の個数によらずに課金額は同じとなる。例えば、ここでは名前がAのアプリ１５の課金額は「8,000 [JPY]」となっているが、「#2」と「#3」のコンテナ１９を実行している仮想マシン１３が新しいコンテナ１９を実行した場合にその課金額がどのようになるかを考える。その新しいコンテナ１９が名前がAのアプリ１５を実行しても、複数の仮想マシン１３のvCPU数の総数は「2+4+2+4+4」で変わらないため、名前がAのアプリ１５の課金額も「8,000 [JPY]」で変わらない。

これにより、コンテナ１９の個数が急激に増えてもアプリ１５の課金額が大きく増えるのを抑制でき、コンテナ１９の利用者にとって納得のいく課金体系を実現できる。

一方、仮想マシン１３の個数が増えれば仮想マシン１３のvCPU数の総数も多くなるためアプリ１５の課金額も増える。よって、仮想マシン１３を提供するサービス提供者にとって納得のいく課金体系を実現できる。

次に、コンテナ１９と課金装置４のそれぞれの機能構成について説明する。

図１４は、コンテナ１９の機能構成図である。図１４に示すように、コンテナ１９は、通信部５１、記憶部５２、及び制御部５３を有する。

このうち、通信部５１は、コンテナ１９をネットワーク２（図１参照）に接続するためのインターフェースである。また、記憶部５２は、前述のコンテナ稼働情報３５を記憶する。

一方、制御部５３は、ソフト管理デーモン３４によって実現される機能であって、起動部５４、取得部５５、及び通知部５６を有する。

このうち、起動部５４は、ソフト管理デーモン３４を定期的に起動する処理部である。また、取得部５５は、コンテナ稼働情報３５に含まれる各情報を取得し、それを記憶部５２にコンテナ稼働情報３５として格納する処理部である。なお、コンテナ稼働情報３５に含まれる各情報のうち、契約情報は課金装置４が自装置の記憶部に記憶している。そのため、取得部５５は、契約情報については課金装置４から取得する。

そして、通知部５６は、コンテナ稼働情報３５を課金装置４に通知する処理部である。

図１５は、課金装置４の機能構成図である。図１５に示すように、課金装置４は、通信部６１、記憶部６２、及び制御部３１を有する。

このうち、通信部６１は、課金装置４をネットワーク２（図１参照）に接続するためのインターフェースである。また、記憶部６２は、各コンテナ１９のイメージファイル３３を作成するためのモジュールプログラム３２と、各コンテナ１９から通知されたコンテナ稼働情報３５とを記憶する。

一方、制御部３１は、課金装置４の各部を制御する処理部であって、提供部６６、受付部６７、算出部６８、及び出力部６９を有する。

このうち、提供部６６は、コンテナ１９の利用者にモジュールプログラム３２を提供する処理部である。受付部６７は、各コンテナ１９からコンテナ稼働情報３５の通知を受け付け、それを記憶部６２に格納する処理部である。

算出部６８は、課金期間内に受付部６７がコンテナ稼働情報３５の通知を受け付けた場合に、コンテナ１９のvCPU数と課金期間の長さに応じた額をアプリ１５の課金額として算出する処理部である。例えば、算出部６８は、図１０や図１２の算出ロジックに基づいて課金額を算出する。

出力部６９は、例えばコンテナ１９の利用者が利用している仮想マシン１３に、算出部６８が算出した課金額を出力する処理部である。課金額の出力先は特に限定されず、例えばネットワーク２に接続されたコンテナ１９の利用者端末に出力部６９が課金額を出力してもよい。

次に、コンテナ１９と課金装置４の各々の処理の流れについて説明する。

図１６は、コンテナ１９が実行する処理のフローチャートである。

まず、取得部５５が、メータリング情報３５ｄ（図６参照）におけるソフトウェア情報を自コンテナから取得する（ステップＳ１１）。

次に、取得部５５が、管理情報３５ｃ（図６参照）における名前空間の名前をコンテナ管理プログラム２０を実行している仮想マシン１３から取得し、かつメータリング情報３５ｄにおけるライセンスコードを自コンテナから取得する（ステップＳ１２）。

次いで、取得部５５が、メータリング情報３５ｄにおけるコンテナ情報のIDを自コンテナから取得し、かつメータリング情報３５ｄにおけるPod情報のIDをコンテナ管理プログラム２０から取得する（ステップＳ１３）。

続いて、取得部５５が、課金装置４から管理情報３５ｃ（図６参照）における契約情報を取得する（ステップＳ１４）。

次に、取得部５５が、コンテナ管理プログラム２０を実行している仮想マシン１３や自コンテナから、ステップＳ１１～Ｓ１３では取得されていないコンテナ稼働情報３５の残りの情報を取得する（ステップＳ１５）。そのような情報としては、コンテナ管理プログラム２０を実行している仮想マシン１３が管理している管理情報３５ｃのID、合計vCPU数、合計Node数、及び名前空間におけるIDがある。また、メータリング情報３５ｄにおけるID、vCPU数、vCPU数上限値、及び稼働情報取得日時も取得部５５が自コンテナから取得する。

次いで、通知部５６が、コンテナ稼働情報３５を課金装置４に通知する（Ｓ１６）。

この後は、ステップＳ１１～Ｓ１６を１５分程度の周期で定期的に繰り返す。

図１７は、課金装置４が実行する処理のフローチャートである。

まず、受付部６７が、各コンテナ１９からコンテナ稼働情報３５の通知を受け付け、コンテナ稼働情報３５を記憶部５２に格納する（ステップＳ２１）。

次に、算出部６８が、記憶部５２からコンテナ稼働情報３５を読み出す（ステップＳ２２）。なお、ステップＳ２１とステップＳ２２は３０分程度の周期で繰り返される。

次いで、算出部６８が、読み出したコンテナ稼働情報３５に基づいてアプリ１５の課金額を算出する（ステップＳ２３）。一例として、算出部６８は、課金期間内に一度でもコンテナ１９からコンテナ稼働情報３５の通知があった場合、そのコンテナ１９のアプリ１５の課金額を算出する。

算出部６８が課金額の算出に使用する算出ロジックとしては、前述の図１１や図１３の算出ロジックがある。例えば、図１１の算出ロジックを採用する場合は、算出部６８は、コンテナ稼働情報３５のメータリング情報３５ｄのソフトウェア情報からアプリ１５のライセンスコードを特定する。更に、算出部６８は、メータリング情報３５ｄのvCPU数をコンテナ１９のvCPU数として特定する。そして、算出部６８は、名前がAのアプリ１５を実行しているコンテナ１９のvCPU数の総和を求め、その総和に予め定めておいたvCPU係数と単価とを乗じることで、名前がAのアプリ１５の課金額を算出する。

また、図１３の算出ロジックを採用する場合は、算出部６８は、コンテナ稼働情報３５のメータリング情報３５ｄのソフトウェア情報からアプリ１５の名前を特定する。更に、算出部６８は、メータリング情報３５ｄのvCPU数をコンテナ１９のvCPU数として特定する。前述のように、そのvCPU数は、当該コンテナ１９を実行している仮想マシン１３のvCPU数に等しい。そこで、算出部６８は、同一の仮想マシン１３で起動している複数のコンテナ１９のうちの一つのvCPU数を、当該仮想マシン１３のvCPU数として特定する。

そして、算出部６８は、名前がAのアプリ１５を実行しているコンテナ１９が起動している仮想マシン１３に割り当てられたvCPU数の総和を求め、その総和にvCPU係数と単価とを乗じることで、名前がAのアプリ１５の課金額を算出する。

次いで、出力部６９が課金額を出力する（ステップＳ２４）。

この後は、ステップＳ２３～Ｓ２４を１日に一回の周期で定期的に繰り返す。

以上説明した本実施形態によれば、図１７に示したように、課金装置４の制御部３１が、課金期間内にコンテナ１９からコンテナ稼働情報３５の通知を受け付けた場合に、課金期間の長さとコンテナ１９のvCPU数に応じた課金額を算出する。これにより、コンテナ１９のIPアドレスが公開されておらず課金装置４がコンテナ１９にアクセスできない場合でも、コンテナ稼働情報３５に含まれるvCPU数に応じた課金額を課金装置４が算出でき、コンテナ１９に対して課金できる。

また、停止中のコンテナ１９はコンテナ稼働情報３５を通知しないため、複数のコンテナ１９の各々が起動と停止を頻繁に繰り返す場合であっても、課金装置４が停止中のコンテナ１９に誤って課金するおそれがない。

更に、図１２～図１３に示したように、コンテナ１９のvCPU数でなく、そのコンテナ１９を実行している仮想マシン１３のvCPU数に基づいて課金額を算出することで、コンテナ１９の急増に伴って課金額が急激に増えるのを防止できる。

（ハードウェア構成）
図１８は、課金装置４のハードウェア構成図である。図１８に示すように、課金装置４は、記憶装置４ａ、メモリ４ｂ、プロセッサ４ｃ、通信インターフェース４ｄ、及び媒体読取装置４ｅを有する。これらの各部は、バス４ｇにより相互に接続される。

このうち、記憶装置４ａは、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性のストレージであって、本実施形態に係る課金プログラム１００を記憶する。

なお、課金プログラム１００をコンピュータが読み取り可能な記録媒体４ｆに記録し、媒体読取装置４ｅを介してプロセッサ４ｃにその課金プログラム１００を読み取らせるようにしてもよい。

そのような記録媒体４ｆとしては、例えばCD-ROM (Compact Disc - Read Only Memory)、DVD (Digital Versatile Disc)、及びUSB (Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体４ｆとして使用してもよい。これらの記録媒体４ｆは、物理的な形態を持たない搬送波のような一時的な媒体ではない。

更に、公衆回線、インターネット、及びLAN等に接続された装置に課金プログラム１００を記憶させてもよい。その場合は、プロセッサ４ｃがその課金プログラム１００を読み出して実行すればよい。

一方、メモリ４ｂは、DRAM(Dynamic Random Access Memory)等のようにデータを一時的に記憶するハードウェアである。

プロセッサ４ｃは、課金装置４の各部を制御するCPUやGPU(Graphical Processing Unit)等のハードウェアである。また、プロセッサ４ｃは、メモリ４ｂと協働して課金プログラム１００を実行する。

このようにメモリ４ｂとプロセッサ４ｃとが協働して課金プログラム１００を実行することにより、課金装置４の制御部３１（図１５参照）が実現される。

また、記憶部６２（図１５参照）は、記憶装置４ａとメモリ４ｂによって実現される。

更に、通信インターフェース４ｄは、課金装置４をネットワーク２（図１参照）に接続するためのNIC(Network Interface Card)等のハードウェアである。その通信インターフェース４ｄにより通信部６１（図１５参照）が実現される。

媒体読取装置４ｅは、記録媒体４ｆを読み取るためのCDドライブ、DVDドライブ、及びUSBインターフェース等のハードウェアである。

図１９は、物理サーバ３のハードウェア構成図である。図１９に示すように、物理サーバ３は、記憶装置３ａ、メモリ３ｂ、プロセッサ３ｃ、通信インターフェース３ｄ、入力装置３ｆ、表示装置３ｇ、及び媒体読取装置３ｈを有する。これらの各部は、バス３ｊにより相互に接続される。

このうち、記憶装置３ａは、HDDやSSD等の不揮発性のストレージであって、ホストOS１２、仮想化プログラム１０１、ゲストOS１４、コンテナエンジン１８、及びソフト管理デーモン３４を記憶する。メモリ３ｂとプロセッサ３ｃが協働して仮想化プログラム１０１を実行することにより各仮想マシン１３（図３参照）を実現することができる。

なお、ソフト管理デーモン３４をコンピュータが読み取り可能な記録媒体３ｉに記録し、媒体読取装置３ｈを介してプロセッサ３ｃにそのソフト管理デーモン３４を読み取らせるようにしてもよい。

そのような記録媒体３ｉとしては、例えばCD-ROM、DVD、及びUSBメモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体３ｉとして使用してもよい。これらの記録媒体３ｉは、物理的な形態を持たない搬送波のような一時的な媒体ではない。

更に、公衆回線、インターネット、及びLAN等に接続された装置にソフト管理デーモン３４を記憶させてもよい。その場合は、プロセッサ３ｃがそのソフト管理デーモン３４を読み出して実行すればよい。

一方、メモリ３ｂは、DRAM等のようにデータを一時的に記憶するハードウェアである。

プロセッサ３ｃは、物理サーバ３の各部を制御するCPUやGPU等のハードウェアである。また、プロセッサ３ｃは、メモリ３ｂと協働してソフト管理デーモン３４を実行する。

このようにメモリ３ｂとプロセッサ３ｃとが協働してソフト管理デーモン３４を実行することにより、コンテナ１９の制御部５３（図１４参照）が実現される。

また、記憶部５２（図１４参照）は、記憶装置３ａとメモリ３ｂによって実現される。

更に、通信インターフェース３ｄは、物理サーバ３をネットワーク２（図１参照）に接続するためのNIC等のハードウェアである。その通信インターフェース３ｄにより通信部５１（図１４参照）が実現される。

また、入力装置３ｆは、コンテナ１９の利用者がモジュールプログラム３２に含まれる定義ファイル等を編集するためのキーボードやマウス等のハードウェアである。

表示装置３ｇは、各種の画面を表示するための液晶ディスプレイ等の表示デバイスである。

媒体読取装置３ｈは、記録媒体３ｉを読み取るためのCDドライブ、DVDドライブ、及びUSBインターフェース等のハードウェアである。

１…システム、２…ネットワーク、３…物理サーバ、４…課金装置、１１…ハードウェアリソース、１３…仮想マシン、１５…アプリ、１８…コンテナエンジン、１９…コンテナ、２０…コンテナ管理プログラム、３１…制御部、３２…モジュールプログラム、３３…イメージファイル、３４…ソフト管理デーモン、３５…コンテナ稼働情報、５１…通信部、５２…記憶部、５３…制御部、５４…起動部、５５…取得部、５６…通知部、６１…通信部、６２…記憶部、６６…提供部、６７…受付部、６８…算出部、６９…出力部、１００…課金プログラム、１０１…仮想化プログラム。

Claims (7)

1. コンテナに割り当てられたリソース量を示す通知を前記コンテナから受け付け、
   課金期間内に前記通知があった場合に、前記リソース量に応じた額を、前記コンテナが実行するアプリケーションプログラムの課金額として算出する、
   処理をコンピュータに実行させるための課金プログラム。
2. 前記コンテナは仮想マシンが実行し、
   前記リソース量は、前記仮想マシンに割り当てられたリソース量に等しいことを特徴とする請求項１に記載の課金プログラム。
3. 前記仮想マシンが前記コンテナを複数実行している場合、各々の前記コンテナに割り当てられた前記リソース量が多いほど前記課金額が増えることを特徴とする請求項２に記載の課金プログラム。
4. 前記仮想マシンが前記コンテナを複数実行している場合、前記課金額は複数の前記コンテナの個数によらずに同じであることを特徴とする請求項２に記載の課金プログラム。
5. 前記仮想マシンが複数起動している場合、前記課金額は、複数の前記仮想マシンの各々に割り当てられた前記リソース量の総数に応じた額であることを特徴とする請求項４に記載の課金プログラム。
6. コンテナに割り当てられたリソース量を示す通知を前記コンテナから受け付ける受付部と
   課金期間内に前記通知があった場合に、前記リソース量に応じた額を、前記コンテナが実行するアプリケーションプログラムの課金額として算出する算出部と、
   を有することを特徴とする課金装置。
7. コンピュータが、
   コンテナに割り当てられたリソース量を示す通知を前記コンテナから受け付け、
   課金期間内に前記通知があった場合に、前記リソース量に応じた額を、前記コンテナが実行するアプリケーションプログラムの課金額として算出する、
   処理を実行することを特徴とする課金方法。
   

Images