さて、第2回は、Oracle ライセンス管理のためのベースライン構築 その１として、ベースライン構築の最初のステップであるライセンス契約書のたな卸しとライセンス契約に関係するCI（構成アイテム）とライセンス割り当ての管理を解説します。

目次

自らのコントロールが必要なレベルの組織の選択肢は？

なぜ、このような契約条件を把握するべきなのか？

まずは、簡単にその背景のお話をしたいと思います。 ひと昔前のOracleライセンスの管理は保守契約をサーバーに紐づけて管理すれば良かったので、人的努力により表計算シートでシステム、サブシステム、サブシステムで稼働中のOracleアプリケーション・ソフトウェアとその保守契約を紐づけて管理すればどうにか対処可能なものでした。 しかし、今日の複雑化したIT環境では、「頑張ればどうにかなる」というものではありません。まずは、根性論で対処を要求してくる上司に対して今日の複雑化したIT環境におけるOracleライセンスの複雑性を理解してもらい、目的、体制、役割と責任などを明確にしたうえで、相応の予算と人員を確保してもらうことが重要です。管理に必要十分なスキルセットやナレッジを持った人材が不足するようであれば、部分的にはアウトソースして必要十分なスキルセットを担保しなければ、抱えた人が苦しむことになります。

重要なポイントは、
Oracleライセンス体系が、統合と仮想化により複雑化するIT環境にともない大きく変化してきたということの社内理解を得ること。 また、ライセンス・タイプが製品分類、事業部門ごとに異なる可能性があり、使用権に関する専門的用語も契約ごとに異なる可能性がある、など複雑化に拍車をかける状況があることを理解してもらいましょう。

特に、仮想環境がVMWare など Oracle が認めていない Software Partitioning 技術を利用している場合は、 「Oracleのプログラム・インスタンスが稼働可能な Processor はすべてライセンスされている必要がある」 というOracle のコア・ライセンス・モデルの解釈への対処が要求されるので十分な注意が求められます。 基本的にOracleは、

• ・Hard Partition しか認めていない
• ・OracleVM しか認めていない

というポイントを理解しておきましょう。

最近の欧米市場でよく聞く話ですが、「車の駐車場を借りようとしたら1台しか止めないのに、160台のスペースどこにでも止めてよいから160台分の月額駐車料金を支払えと請求されるなんてあり得ない！」とOracle社に対しての不満を訴えるユーザーが増えているとか。つまり、コア・ライセンス・モデル（いわゆるサブキャパシティ・ライセンス）では、実際には使用していないプロセッサでもOracle製品が稼働可能な範囲のプロセッサは全てライセンスを購入する必要がある、というライセンス契約の解釈に対して不満を持つユーザーが多くいるということです。VMWare/vCenter 6.0 以降の複数クラスタをまたいで可能となったライブマイグレーション機能などは、つまりは、vCenter で統合されたデータセンターすべてのプロセッサがOracleライセンスを取得する範囲と解釈される可能性があるということなのです。対応策としては、OracleをHard Partitionで作成し閉じ込めてしまう方法がありますが、ダイナミックにリソースを最大活用するための高可用性を獲得した環境で、あえて孤立したシステムをライセンス・コンプライアンスのために作るというのは、今までの統合・仮想化によるリソースの最大活用とHAシステムの進化とは逆行する退化と言えるでしょう。 本来あるべき対策としては、ライセンス契約の条件を交渉し、進化した環境の中でコントロールしライセンス最適化を図る方向を模索するべきと言えます。（例えば、VMWareの環境であればホストアフィニティ・ルールなどで稼働範囲を制限する方法があります。それでもVMware のHA環境の機能の目的は損なわれます。）

そのためには、ライセンス契約交渉が必要となりますが、契約交渉をするためには現在の契約状況を正確に把握し、実際の稼働環境の情報を収集し、突合可能な状態を獲得したうえで、収集したHard Fact（事実）を持って自社にとって有用なライセンス契約条件を勝ち取る必要があるのです。もちろん全てのレベルの組織でそのような大がかりな作業をすべきではありません。その点については、以下の記事を参考にして自分の組織はどのような戦略をとるべきかを検討する必要があるでしょう。

自らのコントロールが必要なレベルの組織の選択肢は？

コントロールが必要なレベルの組織の選択肢は以下の二択しかありません。

• ① Oracle の契約条件の解釈に合意する
• ② Oracle と契約条件の解釈を交渉し合意し明文化する

いずれにせよ、契約条件をしっかりと把握する必要がありますので、ライセンスの運用条件を規定する契約書の類をたな卸しし、製品やエディションの違いによるライセンス・タイプの違いを把握し、ライセンスを適切に割り当てたうえで、現在の運用状態を測定し、運用条件の準じた運用が行われていることを担保する必要があります。それができないでいると オラクル・コンシェルジュ（欧米では Oracle LMS：License Management Service、という監査チーム）にULA（Unlimited License Agreements）の提案をされてしまいます。ライセンス契約に関してベンダーからの提案だけの受け身（リアクティブ）になっていると高額な請求書と、選択肢としての新環境の提案のいずれかを受け入れざるを得ない状況となります。自らのコントロールを得てプロアクティブにライセンスをマネジメントすることで自組織にとってあるべき契約条件を獲得し、ベンダーとのWin-Winの関係を構築することがIT資産管理戦略の一つの目的ですから、戦略的にアプローチしてくるベンダーに対して、ユーザー組織も戦略的に交渉しライセンス契約や運用環境を最適化する取り組みを進めることが重要です。

そうなると具体的なライセンス契約書の体系を理解し、必要な情報を収集したり、必要な関係者（ステークホルダー）の協力を得たりする必要がでてきます。

以下にOracleライセンス契約書の体系を示します。

ライセンス契約
• OLSA（Oracle License and Services Agreement）
• SLSA (Software Licensing and Services Agreement)
• MLA (Master License Agreement)

購入情報
• Ordering Document

購入情報に付随するライセンス条件など
• Attachments/Exhibits

ライセンス契約および購入情報に付随する条件変更など
• Amendments

サポート情報
• Support Agreements

これらをCI（構成アイテム）として関係性を管理し、契約条件を明確にしたライセンス条件と有効ライセンス数を管理したうえで、ライセンスを適切に割り当て、それをコントロールするためのインベントリ情報の収集が必要となります。

ライセンス割当台帳におけるCIの関係性

その他にもオンライン情報（価格表やCore Factor Tableなど）を参照と言及されたりしますが、これらの情報に関しては以下の情報を参考にしてください。

なぜ、このような契約条件を把握するべきなのか？

以下にポイントをあげます。

• ① エディションによりライセンス体系（例：ユーザー、コア、ソケット）が異なる
• ② DBオプションは使用した分だけで良い
• ③ DBオプションはインストール時に不要なものもインストールされる

そうなると前掲の図における“ライセンス”は、ライセンス契約の条件を含むエンティティでなくてはなりません。つまり、同一の製品、ライセンス条件であれば同ライセンスは、できれば一つにまとめてライセンスとしてのエンティティを作成し、ライセンス数は使用権としてライセンスの条件である“ライセンス”に紐づけて割り当てを実現することが求められるのです。この場合のライセンスは、後に割り当て状態を確認するためにインベントリ情報と突合する際の測定ロジックとなります。コア・ファクタ・テーブルなどを参照し、係数を計算してライセンス消費を算定しなければいけないコア・モデルの計算式や諸条件がライブラリ化され当該ライセンスが参照しロジックとして利用できるようなシステムが求められます。 これらの割り当てを検証するためのインベントリ情報として必要となる項目を以下にあげます。

• ① インスタンス（VM）のソフトウェア・インベントリ情報
  ・インベントリ情報からインストールされている製品、エディション、バージョン情報を取得
• ② OracleDBインスタンスから取得するTNSファイル
  ・TNSファイルから実際に使用されているオプションなどを特定
• ③ VMWare など仮想環境で割り当てられるリソースおよびインスタンスが稼働可能な範囲の特定

ここまで読まれた運用管理者の方は、「これは運用チームだけでは無理！」と思われた方も沢山いることでしょう。

その通りです！

まず、なんといっても運用チームにはライセンス契約書が共有されておらず、見たことのない運用者がほとんどです。さらに、ライセンスの割り当ても正確な情報は提供されておらず、インベントリ情報から想定する現状情報に限られていたりします。しかも、インベントリ情報には正確なエディションやバージョン情報がなく、保守契約書から類推して割り当て管理表を作成している運用者もいるでしょう。挙句の果てには、既に実装済みのOracleインスタンスのポートへアクセスしてTNSファイルを取得したり、VMWareへSOAP接続して情報を取得したりしなければならないのであれば、協力してもらわないと成り立たないステークホルダーは多岐にわたります。

さて次回は、ライセンス契約の情報や実装の状態、運用の状態を把握するために必要となる情報ソースであるステークホルダーを識別し、何を期待するべきなのかを解説します。