さて、第２回はパブリッククラウドからプライベートクラウドやホステッドプライベートクラウド環境において、調達（VMO）、プロジェクト、Oracle担当やインフラチームチーム、あるいは外部のクラウドサービスベンダーなど関係するすべてのステークホルダーの協力が求められるOracle に代表されるサーバーミドルウェアなどのライセンス管理についてです。様々な環境におけるリスクや責任の分界点がどこにあるのか、そして、IT資産管理者としてどのようにコントロールするべきかを詳しく解説します。

目次

【参考】

環境により異なるリスク

パブリッククラウドの場合

プライベートクラウドとオンプレの場合

まとめ

小規模環境であればユーザーライセンスという選択肢もあります。パブリッククラウド上にデプロイするクラウドライセンスも選択肢となります。しかし、サブキャパシティライセンスモデルで導入するのであれば、サーバーエージェントのデプロイやソフトパーティション（VMWare）などから取得する環境情報など、乗り越えなければならない課題が山盛りです。

最初にひとり情シスさんの環境の場合ですが、できるだけ管理工数を抑えたいので、Oracleライセンスなどミドルウェア系の複雑なライセンスは自社での契約を避けましょう。つまり、外部のパブリッククラウドなどに含んでもらうような仕組みを作ることが一番です。SaaSのようなサービスであればDBやアプリケーションサーバーなども含んだ状態でのサービスを探しましょう。オンプレの場合、「DBはSQLやOracleの選択が可能です」など、一見選択肢が与えられていて良いように思えますが、実際は、これらのライセンス契約のリスクを負うことになるので、できる限りは自社でのライセンス契約は避けるのが賢明です。できる限りはサービスとして利用し、結果を求めるというサービス契約を利用することがリスクや管理工数を抑える上で有効な戦略です。システムとして導入し、ライセンス契約をしてしまうことでシステムを構成するライセンス契約の責任を負うこととなり、リスクも管理責任もぐっと増加します。できる限りの範囲においてライセンスの責任をサービス提供者（サービスプロバイダ）に負わせることが肝心です。

それが不可能な場合は、ユーザーライセンス、フルキャパシティ、サブキャパシティ、パブリッククラウドのライセンスモデルを比較し、自社の規模と管理工数を考慮した上で適切なライセンスを選択しましょう。ユーザー数が少なければユーザーライセンスでユーザーリストさえ作成すれば監査対応は問題ありません。しかし、ここでの注意点として、「最小契約数」がサーバーのキャパシティによって実際のユーザー数を上回る場合があるので、デプロイするサーバーの最大キャパシティが最小契約数を決定する※１ことを忘れないように注意しましょう。ユーザーライセンスのソフトウェアをデプロイする場合はハードパーティションで最大キャパシティをコントロールしましょう。自社のユーザー数におけるユーザーライセンス料金と、実際のシステム設計における必要CPU数でのフルキャパシティ、サブキャパシティモデルのライセンス料金を比較して低い方に近い金額で交渉ができるように準備しましょう。

※１ 最大キャパシティとは、例えばインスタンスに割り当てているCPUコア数が2コアであっても、インスタンスがデプロイされているサーバーのCPUコア数が総合計で32コアあり、VMWareなどの仮想化によりソフトパーティションが実施され、ハードパーティションではない場合は、最大32コアに必要な最小契約数が適用される。

【参考】

• Oracle Named User Plus ライセンスで購入の場合
• Processor定義によるライセンスカウント方法
• Processor（サブキャパシティモデルの場合は Oracle Processor Core Factor Tableを参照）
• クラウド・コンピューティングにおけるOracleソフトウェアのライセンス（Amazon や Asure などOracleが承認したクラウド環境においてのライセンスの計算）

Oracle などはライセンス情報としてこれらの情報を公表していますが、ここでの問題は、「こんな複雑なライセンスを理解しろといわれても忙しくてそんな時間はない！」と誰もが感じる点です。

欧米でも同様に、昨今のIT環境の複雑化に起因するライセンスモデルの複雑化と、これら難解なライセンスモデルをユーザーに押し付けておいて、監査を実施し、監査補正料金を請求するというライセンサーのやり方が問題視されています。しかし、残念ながら現実は監査補正を請求されるケースが多いことから、これらの複雑なライセンスモデルを理解して支援してくれるコンサルティングサービスなどが増加傾向にあり、必要であればコンサルタントのサービスを利用してライセンスのアセスメントをすることをお勧めします。

サービスプロバイダがDBを提供する場合は、キャパシティモデルのライセンス料金を参考にして価格交渉をすることです。ただし、コストの観点からだけではなく、運用リスクも転嫁するので、多少の金額が膨らむことは覚悟してください。

「クラウドを使えば安くなる」は大きな間違いです。 リスクや運用負荷を転嫁するので、それらも含めた価格であると理解してください。同じライセンス料金のコストで管理リスクも負担させようとするとサービスプロバイダの環境で無理が生じ双方にとって不利益となります。

「こんなに複雑で難解なライセンスなら使いたくない！」というユーザーも多く、より分かりやすいライセンスモデルのMS SQL などを選択されるユーザーも増えている傾向にあるようです。一方で、プロセッサのキャパシティによりライセンス数を決定するというライセンスモデルを選択するライセンサーが増えているのも事実ですので、何らかの形でプロセッサのキャパシティを管理するという能力が求められるようになるでしょう。

環境により異なるリスク

次に、様々な環境におけるリスクを基に管理手法を考えてみましょう。
以下の図は、様々なクラウド環境におけるリスクを表しています。

パブリッククラウドの場合

前述のように、まずはSaaSにライセンスが包含され、自社として複雑なライセンスモデルのライセンス契約をしないことが賢明です。PaaS や IaaS の場合は、どこまでのインフラのソフトウェアライセンスをサービスプロバイダが提供し、どこからを自社で契約するのかがサービスプロバイダを選定する基準の一つとなります。ここでも、できる限り自社で直接ライセンサーと契約することを回避しましょう。やむを得ずPaaSやIaaSでプロセッサライセンスを契約する場合は、ここが非常に重要なポイントですが、ライセンサー（例えばOracle）がパブリッククラウドとして認識しており、ライセンスのポイント変換などを定義しているか否かにより、PaaSやIaaS のパブリッククラウド上でVM（インスタンス）に割り当てたCPUおよびCPUコア数の情報が、VMにより消費されるライセンスと紐づけられ、ライセンス消費を管理できるような状態でなければなりません。つまり、パブリッククラウドの提供者からこれら管理メトリックスの情報が随時取得できるようにしなければならないのです。AWSのEC2 やAzureであればこれらのライセンスの変換が定義されていたりしますが、そうでないパブリッククラウドの場合は、後述のホステッドプライベートクラウドと同様の管理が求められますので注意してください。

プライベートクラウドとオンプレの場合

全てのコンポーネントが自社資産で構成されるプライベートクラウドまたはオンプレの場合と、プライベートクラウドをサービスとして提供するベンダーが提供するホステッドプライベートクラウドの場合においての違いを把握しましょう。ここでは、インフラのレイヤーで、誰がどこのレイヤーの責任を負っているのかがポイントとなります。

プライベートクラウドとオンプレの場合は、インフラの全域でユーザー企業が責任を負っているので、すべてのライセンス資産をOS層、仮想化層、ミドルウェア層、アプリケーション層のたな卸しを行い、それぞれのライセンス契約で管理が必要となるメトリックスを定義します。サブキャパシティモデルであれば、管理するCI（構成アイテム）はCPUメーカーやCPUコア、VM などがあげられます。これらの関係性を管理し、ライセンス消費メトリックスにおいてVMに割り当てられたライセンス数と、ライセンス消費を決定するメトリックスで消費を明らかにし、運用環境からVMで使用しているハードウェアリソースの情報を取得し、突合します。

問題は、ホステッドプライベートクラウドの場合ですが、以下のようなポイントを確認し、検討する必要があります。

• ① ホストしているベンダーがどこまでの責任を負っているのか？
• ② インフラ提供しているベンダーから自社が契約するライセンスを管理する上で必要十分な情報が提供されるのか？（VMに割り当てているCPU名、CPUコア数など）
• ③ インフラを管理する上で必要となるマネジメントシステムが導入できるか？（運用サービスの定義にインフラ管理システムとソフトウェアライセンス管理システムの連携を含むことができるか）
• ④ サーバー用のエージェントは今のインフラに導入可能か？（現時点でのサービス定義やコストに含まれていないので定義や再契約が必要）
• ⑤ 次期共通基盤などの改定にエージェントを含まなければエージェント導入はできないのか？
• ⑥ 環境を管理する上で必要なシステム連携が今の環境で可能か？（システム連携するためにインフラにアプリケーションを導入したり、FWを超えたりできるか）

まずはサーバーにエージェントを導入という壁を乗り越えなければなりません。すでに構築済みの環境に、特にサーバー環境に追加のエージェントというのは、インフラチームや運用ベンダーなどに抵抗されおおかた不可能です。となると、次の共通基盤の標準化のタイミングで標準基盤のコンポーネントとして組み込んでもらうしかありません。

またサーバーエージェントに加えて、Oracle DB であれば、DBのポートにアクセスしSQL文を発行して運用状態の情報を取得したり、IBM製品であればILMT（IBM License Metric Tool）と連携して情報を取得したり、SAP であればSolution Manager との連携が必要であったり、VMWare を使用していればvCenter などとの連携により情報取得も必要となったりします。

VMWare などで仮想環境を構築している場合、クラスタリング環境のフルキャパシティあるいは複数クラスタをまたいだ全ての環境（vCenter 6.0 以降の場合）へインスタンスが移行できる場合は、これらのフルキャパシティでライセンスが請求されますので、どのように制御し、サブキャパシティのアドバンテージを利用するのかを契約交渉においてしっかりと合意しておく必要があります。そうでない場合は、監査補正請求においてフルキャパシティで請求される可能性が高くなります。

このような環境を管理するためのプロセスや自動化要件定義については本連載の第4回および第5回で詳しく解説します。

まとめ

最初にするべきことは、自社で契約しているライセンス契約をたな卸しして、契約条件を理解することです。どのような契約条件のライセンスを使用しているのかにより管理の方法が異なります。それが分かれば管理するべき内容や、自動化するべき管理対象項目が見えてきます。これを基に、管理工数を削減するためにどのような契約交渉をすべきか、あるいは、将来はどのようなライセンス契約の製品を選択するべきかが見えてきます。

これは、クラウドサービスの契約と並行して理解が必要です。どのような環境で当該ライセンスを運用するのかも、管理をするうえで、誰から、どのような情報を取得するべきかを決定します。

次回は、
第3回 「ライセンス契約をレビューして諸条件を理解、把握するプロセス」

リスクや管理工数は自社が契約しているライセンス契約の内容によって大きく異なります。現時点でのライセンス契約をたな卸しして、契約内容をレビューすることで管理すべきか否かや、どこまで管理しなければならないのか、契約交渉でどのような条件を獲得するべきか、などが見えてきます。戦略的な契約交渉や管理計画を立てるためには不可欠な作業ですので、どのようなポイントを契約条件のなかから読み解くべきか、などを詳しく解説します。

運用チームには提供されていないライセンス契約の情報が管理にとっては最初の難関です。インフラチームも管理対象には性能情報しか入っていない、開発・プロジェクトチームも最初のライセンス要求しか管理していないなどの組織だとライセンス契約のたな卸しは非常に困難な作業です。VMO（Vendor Management Office）や調達部門との協力によりこれらの困難を乗り越えていく必要があります。