さて、第3回は、「Oracle ライセンス管理のためのベースライン構築 その２」と題して、ベースライン構築に必要なOracleライセンス契約書や購入情報、実際の運用環境の情報などライセンスのコンプライアンスを把握するために必要となる管理情報をタイムリーに収集する仕組みをつくるには、どのような関係者（ステークホルダー）からどのような情報を収集する必要があるのかを解説します。

目次

ステークホルダーの範囲（すべてではありません）

まとめ

まずは、なぜOracleライセンス管理が今日のように複雑になり、監査や補正活動において巨額の請求を受けるようになったかを簡単に説明します。 この15年間を振り返ってみると、そもそもOracle DBなどがデプロイされていたサーバーに対してサーバーのライセンスが購入され、保守契約があれば、サーバーが廃棄されるタイミングで保守契約の終了処理さえしっかりとしておけば、それ以外に大きな問題になることはありませんでした。その場合の唯一の課題は、「保守契約がサーバーに紐づけられて管理され、サーバーの廃棄と同期を取って保守契約を終了することができるか」ということでした。ところが、サーバーが統合され、高密度になり、サーバーラックには多数のブレードサーバーが存在するようになり、ライセンス体系もプロセッサCPUに対する課金となりました。その後、高密度化されたサーバーは仮想化によりライセンス体系もプロセッサコアを対象とするようになり、プロセッサの処理能力とコア数、さらには、インスタンスがデプロイされているサーバーの最大キャパシティに対する最小ライセンス数やエディションによる最大ソケット数の制限など、複数の管理メトリクスが追加されるようになったのです。私が知っている限りでは、過去15年間に10数回のライセンス体系の変更がありましたので、ライセンス契約を数年ごとに自動更新してきたユーザーにとっては、どこかのタイミングで補正のためのメーカー活動が発生すると、「寝耳に水」という状況のユーザーが多く、今日もそれが繰り返されているというのが現状です。

図：ライセンス体系の変化

サーバー環境が統合され、仮想化されることにより、その複雑化する環境に対応する形でライセンス体系も複雑化を極めています。今日のOracleライセンス体系やライセンス契約書は、欧米のユーザーの間でも、「最も複雑で難解」と称されるように、IT資産管理を専門に10年以上の経験を持つ私でも、変更があるたびに条件の内容を読んで理解し、解釈の範囲を把握するためには関係する仮想環境などの調査に時間を要します。特に、VMWare のバージョンの変化による環境の変化は、Oracleが正式に認めてはいない環境だけに、Oracleのライセンスの考え方をVMWareの環境で解釈すること自体が、様々な専門家の解釈を生んでおり、実際には、Oracle監査の結果などを踏まえた上で初めて理解が可能となるという非常に困難な状況を生んでいます。このように難解で、自社をリスクにさらす可能性をコントロールするためには、Oracleと契約交渉し、自社の環境や戦略にとってより良い契約条件を勝ち取って、明文化するほかに手だてがないという現在の状況を生んでいることを理解しなければなりません。 Oracleライセンスのコンプライアンスを維持するために必要となる管理メトリクスは前回も解説しましたが、大きくは以下の3つにまとめられます。

• ① フルキャパシティ
• ② サブキャパシティ
• ③ 指名ユーザー

① フルキャパシティ

フルキャパシティの場合は、Oracle インスタンスが稼働する物理サーバーおよび仮想化によりクラスタ化されインスタンスが稼働可能な範囲のすべてのプロセッサに対してライセンスを割り当てます。この場合、VMWare/vCenter 6.0 以降の複数クラスタを統合して、これらの複数クラスタをまたいで自動的に実行されるライブマイグレーションなどの機能が提供可能な状態であれば、すべてのプロセッサコアにライセンスが要求されます。

物理的なサーバーキャパシティの一部でOracleインスタンスが稼働し、すべてのプロセッサを使用しないので、インスタンスに割り当てたリソースのみを対象に課金するためのライセンスモデルがサブキャパシティライセンスモデルの考え方です。ところが、VMWare などOracleが認めていないソフトパーティショニング技術を採用すると、VMWareで仮想化されインスタンスが稼働可能な範囲すべてをライセンス課金対象にしても良いと解釈できるライセンス契約条件が存在しているので、そこに大きな矛盾が発生しています。 しかも、すべてのライセンス体系において最大サーバーキャパシティによる最小ライセンスの要件があり、これも不必要なライセンス消費を大幅に増加させる要因となっています。

② サブキャパシティ

サブキャパシティライセンスは、Oracleインスタンスに割り当てられたプロセッサコアの処理能力に応じた課金のための仕組みなので、どのプロセッサという具体的なプロセッサ処理能力と、割り当てられたコア数、さらには当該コアが搭載されているサーバーのキャパシティ、およびVMWareなど仮想環境のクラスタ環境の最大キャパシティなどが管理メトリクスとなります。

③ 指名ユーザー

指名ユーザーライセンスは基本的には、小規模のシステムで特定の小規模のユーザーが使用するためのライセンスモデルです。注意するポイントは、ユーザーだけではなく、そのシステムがデプロイされる環境のハードウェアの処理能力で最小ライセンス数の制限があるということです。つまり、25ユーザ―ライセンスとして使用していても、CPUの数が大きなサーバーの仮想環境の一部で使用した場合は、そのサーバーの最大キャパシティにより求められる最小ユーザー数が100ユーザーとなり、実際は25ユーザーしか使用していないとしても差分の75ユーザーライセンスを請求されるということです。さらに、MSNUP(Multi Server Named User Plus) のような複数システムを１コンピュータシステムとみなして全ての１コンピュータにアクセスする総ユーザー数で契約しているような規模の場合は、「外部のユーザーがアクセスするようなシステムはないか」という注意が重要となります。外部に開いてしまった場合、これらの外部からシステムにアクセスするユーザーは全てユーザーライセンスの対象となりますので、何十万ユーザーライセンスが請求される可能性もでてくるのです。

重要なポイントは、「契約条件は解釈により異なるため、解釈の余地がないように理解を合意し、明文化する必要がある」ということです。契約条件をそのままの状態で受け入れることは、メーカーの条件解釈を受け入れることになります。それが受け入れられない場合は、しっかりと自社の戦略や運用環境に沿った条件を交渉して解釈の定義という形で契約書に付加する文書で明示しておくことが重要なのです。

交渉に必要な情報としては、「現時点でのOracle契約および運用環境を可視化した情報」が必須となります。

これらの情報を正確に把握し、コントロールするためには、以下のような情報を収集し、紐づけ、自動化して管理することが求められます。

保守契約―保守契約の購入情報―ライセンス条件が明示されたライセンス契約書

ライセンス契約書については前回、どのような契約書が存在し、契約条件に関係する文書にはどのような文書があるのかを提示しましたので、そちらを参照ください。

これらのことから、まずベースラインを構築する際に必要となる情報は以下の通りです。

• ① ライセンス契約書（ライセンスモデル、運用条件）
• ② 購入情報（正確な製品名、取得ライセンス数）
• ③ 保守契約（保守契約期間および条件）
• ④ 環境情報（デプロイ環境、リソース割り当て情報）
• ⑤ インベントリ情報（ソフトウェアインベントリ、VMWare環境・リソース割り当て情報、Oracle DB TNSファイル）
• ⑥ 指名ユーザーのリストおよび関連システムで外部からのアクセスを許可しているシステムのリスト

今日の環境では、運用チームにこれらの情報が整理されて提供されているという状態ではないので、これらの情報を誰から、どのタイミングで取得し、管理に必要な関係性を管理するシステムにデータとして投入し、全体の可視化を図るか、ということが運用チームに与えられた課題になります。これは、「探偵」のような作業となります。さらには、すでに環境構築が済んでしまってから、必要となる管理メトリクスをこれから明確にして、必要情報を収集しようということになりますので、必要な情報が生成されていない場合も考えられます。つまり、追加的にサーバーエージェントのデプロイが必要であったり、現在デプロイされているサーバーエージェントで取得可能な管理メトリクスの範囲を明確にしたうえで、追加で必要となる情報をどのように収集するのか、方法を検討する必要がでてきます。

これらの情報を持っている可能性のあるステークホルダーに問い合わせし、ステークホルダーとしての認識を共有し、なぜ、何のためにこれらの情報が必要となるのか、どのような方法で取得してもらうのかという計画が必要となります。

ステークホルダーの範囲（すべてではありません）

① ライセンス契約書（ライセンスモデル、運用条件）

• ・VMO（Vendor Management Office）
• ・システムプロジェクトチーム
• ・インフラチームなど
システムおよびサブシステムに割り当てた保守契約情報などが存在している場合は、それらの保守契約がどのライセンス契約から発生しているのかをたどっていきます。それがマスターライセンス契約に紐づくのか、購入毎に発生したトランザクションライセンス契約があるのかなどを調査し、紐づけられる情報として列挙します。

② 購入情報（正確な製品名、取得ライセンス数）

• ・発注情報がVMOや調達にシステムのプロジェクトチームやインフラチームから依頼されているのかといった調達プロセスをたな卸しし、保守契約を発注した発注情報などに記載されているライセンス契約情報などを列挙して関係性を明らかにしていきます。

③ 保守契約（保守契約期間および条件）

• ・保守契約がシステムやサブシステムに割り当てられて運用チームにより管理されている場合は、サブシステム名やVMホスト名などと紐づけた情報を用いて購入情報やライセンス契約情報に紐づけしていきます。運用チームにデータがわたっていない場合は、購入情報と同様の対象ステークホルダーから取得する必要があります。

④ 環境情報（デプロイ環境、リソース割り当て情報）

• ・プロジェクトチームなどが作成した導入計画などから初期の導入環境や、変更管理情報などをもとに、ライセンス割り当ての経緯と現状を調査します。

⑤ インベントリ情報（ソフトウェアインベントリ、VMWare環境・リソース割り当て情報、Oracle DB TNSファイル）

• ・インフラチームやインフラ運用を委託しているサービスプロバイダ/外部委託運用会社により現時点での運用環境に必要なサーバーソフトウェアのインベントリ情報などが存在する場合は、インベントリ情報として必要十分な（アプリケーション名、バージョン、エディション情報など）情報が取得可能かを検証します。
• ・インフラチームやインフラ運用を委託しているサービスプロバイダ/外部委託運用会社によりVMWareなど仮想環境のVMに対するリソース割り当て情報や、VMが稼働する物理サーバーの環境情報などが必要なレベルで適宜取得可能かを検証します。VMWare などの仮想環境においては、1か月に1度の情報提供では情報が不足する可能性があります。1か月に1度しか変更を実施しない運用ポリシーが存在するのであれば、そのような運用ポリシー（変更管理ポリシーなど）と管理システムのインベントリデータを合わせて、契約交渉により必要十分として合意し、契約文書の付加文書に明示しておく必要があります。
• ・Oracle運用担当やインフラチーム、インフラ運用を委託しているサービスプロバイダ、プロジェクトチームなどからOracle DB のインストールの際にインストールされるオプションの実際の運用状態を把握するためには、対象のOracle DBのSQLポートにクエリを投げてTNSファイルなどを取得して実行したオプションを把握する必要があります。オプションはインストールされただけではライセンス課金は発生しませんが、実行された段階で追加のライセンス課金が発生します。

また、サーバー環境の場合、以下の課題が考えられます。

• ① 今のタイミングで既に構築されたサーバー環境に、必要十分な情報を取得するためにサーバーエージェントを追加で導入はできない
• ② VMWareの運用はアウトソースされており、VMWareとSOAP連携して必要な情報を取得するためのSLA（サービスレベル契約）が現時点ではないので、情報取得に必要なシステム連携ができない
• ③ Oracle DB への直接アクセスはシステムにどのような影響があるかわからないので許容できない

これらの課題は段階的に解決する方法を考えましょう。実行可能なタイミングは次期共通基盤設計で、対象となるライセンス体系に基づいた管理レベルの設計になる場合もあるでしょう。

しかし、そもそも、上流工程でOracleライセンス体系などの契約条件を検証し、運用中のコンプライアンス維持なども運用要件として定義し、運用チームをまきこんで契約条件に基づいた運用環境を構築するべきなのですが、上流工程で運用まで考慮していない、あるいは、責任の所在が明確でなく、「インフラを運用管理するアウトソース先が責任を持って管理してくれると思っていた」など責任の所在の曖昧さが、最終的に運用チームの負荷をあげ、複雑な管理環境をつくってきたことを考えると、できるだけ上流でこれらを考慮、検討してもらう意識づけをすることも重要な活動となります。

まとめ

メーカーのライセンス体系の複雑化とその背景にある戦略： IT環境の提供の仕方自体が大きく変化しようとしています。 今までの水平分業モデルから垂直統合サービスモデル、つまりクラウドサービスへの変化です。 多くの大手IT企業が「クラウドファースト」のサービスモデルへの変革を戦略的に推進している今日、ユーザー企業も戦略的なIT資産投資計画やソーシング計画を可能とするIT資産管理戦略が求められています。

さて次回は、これらステークホルダーから収集したデータをどのようにシステムに投入し、紐づけして、自動的に突合・整合化が可能なシステムを構築するのかについて解説します。