第6回：組織や環境により異なるライセンス管理の自動化アプローチ（前編）

さて、第6回は、「組織や環境により異なるライセンス管理の自動化アプローチ（前編）」と題して、環境により異なる、求められる管理のレベルにあった自動化へのアプローチの方法を解説します。

多くの組織は構成管理を目的としたインベントリ収集を何らかの形で実施しているでしょう。しかし、インベントリ収集で分かることは限られています。10月4日開催した IAITAM ACE Japan 2017 において発表された調査会社（テクノ・システム・リサーチ社）の報告によるとPCクライアントの情報収集を実施している組織が88％、ソフトウェアの情報収集を実施している組織が70％、サーバーの情報収集を実施している組織は57％でしたが、クライアントやサーバーに関係する契約の管理を実施している組織は35％にとどまっています。さらに、資産管理と構成変更管理のひもづけを実施している組織は12％と少なく、コスト配布や課金に必要な財務・会計情報とのひもづけに至っては３％、そして、リクエスト管理を自動化するためのカタログ化は1％と未着手の組織がほとんどであるという状態が明らかになりました。

これらの結果から現状をまとめると以下の4つのポイントとなります。

• ●インベントリ収集は実施している
• ●契約、購入情報、現物資産のひもづけができていない
• ●構成管理と資産管理の連携・統合ができていない
• ●資産情報がコスト配布（チャージバック）、投資計画に利用されていない

ソフトウェアベンダーによる監査や補正/提案サービスを受けたことがあると回答した組織は56％に上り、規模の大きな組織を中心に監査活動の対象となっていることがわかります。 また、監査（補正/提案サービス）後に追加料金を支払ったユーザーは38％ に上っており、ベンダーにとっては非常に効率的な営業活動であることがうかがえます。 また、ライセンス料の超過利用分の取り立て強化に不安を感じていると回答した組織は41％で、うち「ライセンス管理は行っているが、不安を感じている」という組織が85％を占めています。

なぜ、管理していても不安を感じているのか？

それには明白な理由があります。 「ライセンス管理は金太郎飴にならない」からなのです。 IT運用ではよく「金太郎飴」という表現がされますが、どの組織が取り組もうとネットワーク管理は同じである、というような意味合いで使われる言葉です。ところが、ライセンス管理は「金太郎飴」にならないところがライセンス管理を実施していても不安を感じさせる大きな原因の一つとなっているのです。 つまり、IT環境とライセンス契約が異なる組織はライセンス管理をどのように実施し、自動化するべきかも異なるということなのです。

もう少し具体的にIT環境とライセンス契約が異なる状態をパターン化して、それぞれのパターンになにをどこまで管理し自動化するのが良いのかを考えてみましょう。 以下のように大きく3つのパターンに分類してみます。

①仮想化されていない物理サーバーでIBM、Oracle などのキャパシティモデルのミドルウェア製品をスタンダード版で使用している。

②パブリッククラウドでIBM、Oracle などのサブキャパシティモデルのミドルウェア製品を使用している。

③仮想化されていない物理サーバーとVMWareで仮想化された仮想サーバーが存在する混在環境（仮想サーバーは、プライベートクラウド、専用クラウドサービスやパブリッククラウドを含む）で IBM、Oracle などのスタンダード版やエンタープライズ版のサブキャパシティやユーザーモデルのミドルウェア製品を使用している。

①の場合は、仮想化されていない物理サーバーでのライセンスの運用となり、スタンダード版などの条件によくあるCPU（またはソケット）の上限をコントロールし、サーバーとライセンス契約および保守契約がひもづけられた状態がエクセルなどで管理されていれば十分と言えます。CPU（またはソケット）の上限はハードパーティションなどでコントロールが可能です。

②の場合は、各ベンダーが認定しているパブリッククラウドのサービスであれば、当該のクラウドライセンスを契約することで対応が可能でしょう。注意するポイントとしては、① の環境から ② へ移行する際に、スタンダード版をそのまま流用するとライセンス違反となる可能性が大ですので、クラウドサービスに特化したポイント換算などを実施してライセンス契約を組み替える必要があります。この場合でも、管理はシンプル化することが可能ですので、エクセルなどで割り当てたライセンス契約と保守契約をひもづけて管理することで十分でしょう。ただし、ベンダーが認定していないパブリッククラウドの場合は③ と同様の管理が必要となりますので注意が必要です。

問題は③のような混在環境をどのように管理するべきかです。

以下に大きな3つのポイントをまとめます。

1）ライセンス契約のエディションを管理する

多くの組織が小規模システムではスタンダード版を物理サーバー上で運用しています。しかし、サーバーの仮想環境が進む中、仮想サーバーにそのまま移行されるケースもでてきています。基本的に多くのスタンダード版が物理サーバーの最大CPU数（またはソケット数）という制限を条件としており、仮想環境で使用するとライセンス違反となりますので十分な注意が必要です。

2）VMWare の環境での契約条件の交渉と合意条件の管理

VMWare 6.0 から複数のクラスタをまたいでリソースの消費が少ない環境を有効に活用する高可用性システムの構築が可能となりました。しかし、Oracleなどは、VMWare をソフトパーティション技術として正式に認めていないことから契約の条件を理解するためには、その条件の解釈を理解する必要があり、VMWareの環境でOracleライセンスを運用するためには契約交渉が必須となります。一般的な解釈では「Oracleインスタンスが稼働できるCPUはすべてライセンスしてください」という条件から、VMWare 6.0 が使用可能な契約をしている組織において VMWare 環境で（それが5.0であったとしても）Oracle ライセンスは全てフルキャパシティで課金されると考えるべきです。

3）PVU（プロセッサバリューユニット：IBMサブキャパシティモデル）の消費ピークを管理し平準化したピークで交渉し合意条件を管理する

IBMサブキャパシティモデルのライセンスの場合はIBM パスポートアドバンテージなどでILMT（IBM License Metric Tool）やBigFix などの使用が条件として定められています。しかも、インベントリの収集は30分ごとであったり、毎月のピークを記録し、3カ月に１回は要求に応じて報告書を提供し、過去２年分の記録を保存したりしておかなければなりません。 さらに年間を通じたピークが最大値として課金対象になりますので、毎月のライセンス消費のピーク情報を記録し、自らが１２カ月を通して平準化した情報などを用いて交渉しない限りは最大値で課金されるという契約になっています。

前述のように同じソフトウェアであってもエディションが異なるとライセンス契約の運用条件が大きく異なります。多くのスタンダード版はVMWare などの仮想環境においてはライセンス違反となり得るため、物理サーバーをハードパーティションでセグメントを切って運用する必要がでてきます。エンタープライズ版であったとしても VMWare 環境では、まず交渉しておかないとフルキャパシティでVMWare でクラスタ化された全てのCPU にライセンスが課金されますので契約交渉が必須となります。 IBM PVUライセンスによるサブキャパシティライセンスの場合も、IBM製品が稼働可能な範囲はすべて管理対象となりますので、IBM製品がインストールされているVM のみを管理対象とすると、後にインベントリ収集の取り直しとなる可能性が大です。 いずれにせよ、ライセンスエディションや物理システム、仮想環境やクラウドサービスの混在環境の場合は、ライセンス契約やエディション、ライセンスを割り当てたVM と、当該VMに割り当たっているハードウェアリソースとしてのCPUキャパシティ（処理能力）や当該CPUコア数などを管理対象としてひもづけ、リソースの割り当てやサーバーの移行など変更管理を実施する必要があるのです。

前編は、ライセンス管理の実態と、管理ポイントとなるライセンス契約の理解までを解説しました。 次回は管理手法として、取り組みを支援する「ソフトウェアライセンス最適化ツール」の例や特徴、使用方法を解説します。