レベル: 初級 David Kaminsky (dlk@us.ibm.com), Software Architect, IBM
2005年 3月 22日 ポリシーは、「アクションの進行途中における決定の指針となる一連の考慮事項」と表現されています。ITの世界では、ITインフラの管理に関連した決定のための指針として、ポリシーが使われています。この記事では、ポリシーに基づく管理の概念を紹介し、鍵となる標準について簡単に解説します。また、ポリシーがどのように構成されているかについても議論します。
はじめに
だいぶ前になりますが、私の妹はコーヒー用のマグカップを持っていて、それには「醜い男と踊るヒマがあるほど人生は長くない（life is too short to dance with ugly guys）」と書いてありました。そのマグカップの言葉は、明らかに彼女の振る舞いに影響したようです。彼女はナイトクラブに行くと、彼女が醜いとみなす男には肘鉄を食わしていたのです。
こういうものもあります。「貸し手にも、借り手にもなるな。金を貸すと、その金だけではなく友も失う。そして借金は節約精神を鈍らせる（Neither a borrower, nor a lender be; for a loan oft loses both itself and friend, and borrowing dulls the edge of husbandry）」シェイクスピアはハムレットの中で、借金についてのポリシーを、このように述べています。
もっと正式な定義という意味では、私はCaloらが主張する定義、つまり「アクションの進行途中における決定の指針となる一連の考慮事項」を大いに支持しています（M. J. MasulloとS. B. Calo共著による、Policy Management: An Architecture and Approach、1993年4月14日から16日にロサンゼルスで開催された国際会議、IEEE First International Workshop on Systems Managementの会報より）。この定義で重要なのは、ポリシーが「決定の指針となる」「考慮事項」であって、絶対的なものではないという点です。
例えばあなたが、借金に関してシェイクスピアと同じようなポリシーを持っているとしましょう。ところがあなたの弟はギャンブルで巨額の借金を抱えてしまい、その借金を返さないと、楽しくない事態が発生する、と考えてみてください。あなたのポリシーによれば、金を貸すことは良くないのですが、弟を破産させるのはもっと悪いという、相反したポリシーもあなたは持っています。そこであなたは、たぶんギャンブルに関する忠告と共に、弟に金を渡すでしょう。優先度に関しては、後で触れることにします。
私の好きなポリシーは、映画スター・ウォーズの中に出てくるものです。C3POはHans Soloから注意を受けるとR2D2に対して「wookieに勝たせろ」と言います。Chewbacca（この場合のwookie）は明らかに、敗れると敵の腕をもぎ取るという癖があるのです。R2D2は、戦う時には勝て、という別の暗黙ポリシーも持っていて、これがSoloの勧める賢明な忠告と直接に競合するのです。最終的に、R2D2はWookieに勝たせ、勝利よりも彼の腕を大事にするのです。
ITでのポリシー
ITシステムを操作するために使われるポリシーも、上にあげたポリシーと大きく異なるわけではありません。オペレーション担当スタッフが、どのように環境を管理するかについて、一連の考慮事項を設計します。つまり、いつどんなことが起こり得るか、誰が何をアクセスするのか、いつ何を達成すべきか、様々なタスクを達成することによる価値などについて設計するのです。こうしたポリシーによって体の一部が失われることはありませんが、顧客の不満にはつながる可能性があります。極端な場合には、ポリシーに違反すると、投獄されることもあり得るのです。
ITポリシーの例としては、下記のようなものが考えられます。
- 「顧客のデータベースは、毎晩午前1時から午前3時の間にバックアップする必要がある」
- 「ゴールドの地位を得た顧客は、全ての購入取引において平均1秒以内の応答が約束される」
- 「マネージメントの人間と人事スタッフのみが個人データにアクセスできる」
- 「Webアプリケーション・サーバーが要求する接続要求は、サーバーに関連付けられたデータベースがサポートする接続の数を超えることはできない」
こうした例から、重要なことが分かります。ポリシーには多くのタイプがある、ということです。最初のポリシーは、オペレーション・スタッフが取るべきアクション、つまりデータベースのバックアップについて定めており、2番目のポリシーは重要な顧客のために維持すべきサービス品質について言っています。3番目はアクセス制御、4番目はコンフィギュレーションに関しての指針です。
分類法には多くの種類がありますが、私は通常、結果がどうなるかに基づいてポリシーを分類しています。
- アクション・ポリシーは実行すべきオペレーションを定義します。
- ゴール・ポリシーは、達成し、維持すべき状態を定義しますが、その実現方法については規定しません。
- 結果ポリシーは、値（1つまたは複数）を定義します。
- コンフィギュレーション・ポリシーは、目的としたコンフィギュレーションを定義します。
上記に対する例を、タイプ分けの順序と同じ順であげると、下記のようになります。
- オペレーションを定義する。具体的にはバックアップを定義する。
- 状態を定義する。対象となる期間中の応答時間は1秒を超えてはならない。
- 真/偽の値を定義する（ユーザーが一連のデータにアクセスできるか否かを、真/偽の値で定義する）。
- データベースやアプリケーション・サーバーのコンフィギュレーションを管理する。
多くのシステムでは、ほとんど複雑さが無いようなシステムであっても、こうしたポリシーは共存するものです。上記4つの例は、単純なオンライン商店の場合でも存在しうる、ごく一例にすぎません。様々なタイプを理解することによって、ポリシーの実行に対して責任を持っているのはオペレーション・スタッフのうち誰なのかが特定できるようになります。（もちろん、小さなビジネスでは、オペレーション・スタッフといっても一人だけかも知れません。）
時によると、ポリシー同士が競合します。先に書いた通り、R2D2は、勝つことと、自分の腕を守ることのどちらかを選ばなくてはなりません。つかの間の勝利よりも自分の腕を大事にしたために、R2D2は負けてしまいます。競合するポリシーの中から選択を迫られるのはR2D2だけではありません。次を考えてみてください。
- サーバーの最終バックアップから24時間以上経っていたら、サーバーをバックアップする。これはアクション・ポリシーです。
- 営業時間中は、バックアップ機能を使用不可にする。これはコンフィギュレーション・ポリシーです。
大部分の場合、システムはバックアップを夜間に実行するため、2つのポリシーが必ずしも競合するわけではありません。ところが、マーフィーの法則が襲ってきます。バックアップ・システムに異常が生じ、夜間に終了することができませんでした。2つのポリシーの一方を有効にすると、もう一方は無視されるのです。
ポリシーの競合を解決するための手法には数多くのものがあります。一般的な手法の一つは、各ポリシーに優先度を割り当て（単純な整数の場合がほとんどです）、最高の優先度を持つポリシーを有効にするというものです。
もっと複雑なシステムでは、優先度は式として表現されます。例えば、ポリシーがいくつものレベルのサービス・アグリーメントから成っており、しかもそのアグリーメントに金銭的な価値が伴っている場合、ポリシー管理システムは総合的な価値を最大化しようとします。
もう一つ、別の手法では、メタ・ポリシーが使われます。先にあげた例の2つを再掲しましょう。
- 「顧客のデータベースは、毎晩午前1時から午前3時の間にバックアップする必要がある」
- 「ゴールドの地位を得た顧客は、全ての購入取引において平均1秒以内の応答が約束される」
このビジネスには、「バックアップ・ポリシーは応答時間に関するポリシーよりも優先する」というメタ・ポリシーがあるかも知れません。何らかの理由からこうしたポリシーが競合した場合、システムはポリシー1をポリシー2よりも優先するでしょう。
標準
上記で説明したポリシー・タイプの多くには、それぞれに対応して標準が存在しています。これから先では、有力な動きがある標準を選んで簡単に説明し、さらに詳細を知るための参照先をあげることにします。このリストは標準化の動きを全て捉えたものではなく、とりあげる標準化に関しても、全ての動きを網羅しているわけではありません。
アクションのポリシーに関する標準として、最も有名なものはDMTF PCIM標準でしょう。この標準の変形がIETFやSNIAで採用されています。この標準の最新版では、PolicyConditionsとPolicyActionsが組み合わさってPolicyRuleになっています。PolicyRoleはポリシーの主題を定義し、ルールの優先度としてPolicyRuleに付加されます。PCIMは、何よりもネットワーク関係のベンダーに広く採用されています。DMTFはポリシーに関するモデル（UMLで表現）を定義していますが、XMLスキーマのような言語は定義していません。詳しくは参考文献を見てください。
OASISのXACML（eXtensible Access Control Markup Language）は、アクセス制御ポリシーを表現するための言語を定義しています。XACMLでは条件と効果（結果）が組み合わさってルールとなり、ルールが組み合わさってポリシーになります。通常の場合では、XACMLポリシーの結果が、ポリシーが規定するリソース（私達の用語ではスコープ）へのアクセスを許可あるいは否定します。XACMLにはまた、ポリシーに関連した要求事項を定義した、義務（obligations）という概念があります。例えば、「経理のメンバーは税金関係の記録にアクセスできるが、そうしたアクセスはすべてログを取る必要がある」というようなものです。ログをとることは、経理のメンバーにアクセスを許可することに伴う義務です。XACMLについて詳しくは、参考文献を見てください。
WS-Agreement（Web Services Agreement Specification）は、アグリーメントに関するフォーマットを定義しています。それぞれのアグリーメントは、アグリーメントに関する条件（アグリーメントに関係するのは誰か、など）と共に、サービス・レベル目標を定義しています。サービス・レベル目標は、到達すべき目標と、目標に到達するために必要な条件を定義します。例えば、金銭的な対価と引き換えに、一方が他方に対して、30日という期間内で平均2秒の応答時間を提供することに合意する、というようなものです。これは、平均2秒の応答時間をゴールとする、ゴール・ポリシーの古典的な例です。WS-Agreementに関して詳しくは、参考文献を見てください。
WS-Policy（Web Services Policy Framework）も、ポリシー関連の標準の一つです。WS-Policyでは上にあげたような手法とは異なり、領域特有のポリシー・アサーション（policy assertions）を保持するために作られた、ラッパーを定義します。ラッパー自体の意味体系は限られており、詳細はアサーションに任されています。例えばWS-SecurityPolicyは、WS-Policyラッパー内に埋め込まれたセキュリティー・ポリシーを定義します。WS-Policyは、ポリシー・タイプではなくラッパーを定義するので、全てのポリシー・タイプに関連します。WS-Policyに関して詳しくは、参考文献を見てください。
ポリシーを解剖する
IBM®は様々なポリシー標準を研究する中で、次の4つの共通要素を特定しました。
- スコープ: ポリシーの主題は、また主題でないものは何か
- 条件: いつポリシーを適用すべきか
- ビジネス価値: ポリシーの相対的優先度を表現し、システムが経済的な取捨選択をできるようにする
- 決定:（ポリシーの）観察可能な振る舞いと、目的とする結果
例えば、顧客の口座規模によって差別化したサービス・レベルを提供しようとする、オンラインの証券会社を考えてみてください。ポリシーは次のようなものになるでしょう。
- スコープ: 株取引アプリケーションでの購入取引
- 条件: 顧客の口座に100万ドル以上の資産があるか
- ビジネス価値: 100
- 決定: 最大応答時間1.5秒を維持する
スコープはポリシーの主題を定義しますが、この場合では購入取引です。条件は顧客を差別化しますが、この場合では、特別な待遇をするために高資産口座を選択します。この場合でのビジネス価値は、単純に整数での優先度です。決定はゴールを定義します。この場合では最大1.5秒の応答時間を維持することです。
今度は、2番目の、関連ポリシーを考えてみましょう。
- スコープ: 株取引アプリケーションでの購入取引
- 条件: 顧客の口座には25万ドル以上100万ドル未満の資産があるか
- ビジネス価値: 90
- 決定: 最大応答時間4秒を維持するe
このポリシーは、同じ状況、同じ購入に適用されますが、対象とする顧客の条件は緩くなっています。つまり、条件が示すように、少し資産レベルが低くなっています。皆さんが想像される通り、こうした顧客は同じレベルのサービスは受けられません。最良の顧客に保証される1.5秒という応答時間ではなく、最大4秒の応答時間しか保証されません。
2番目のポリシーのビジネス価値が最初のポリシーのビジネス価値よりも低い、ということは重要ですので注意してください。これは、ポリシーに競合が起きた場合、つまりシステムが『最良の顧客に対して1.5秒、その次のレベルの顧客に対して4秒の応答時間を提供する』という2つのポリシーのどちらかを選択する必要に迫られた場合には、最良の顧客を第一に満足させるように保証すべきなのです。一般的に言って、これが期待される振る舞いです。
もう少し複雑なビジネス価値を考えてみましょう。
- ポリシー1: 満足された要求毎に「価値単位」30
- ポリシー2: 満足された要求毎に「価値単位」10
先の例のように単純な優先度で決めるのではなく、この場合では、システムは全体としての価値を最大化しようとします。システムが、ポリシー1を1回満足させることと、ポリシー2を1回満足させることのいずれかを選択するという状況では、システムはポリシー1を優先することが期待されます。ところが、ポリシー1を1回満足させることと、ポリシー2を4回満足させることのどちらかをシステムが選択するという状況では、システムはポリシー2を優先されることが期待されます。
こうした状況は、ペナルティーが絡む場合によく発生します。上記のビジネス価値は、次のように書き直すことができます。
- ポリシー1: 1.5秒以上を要する取引には30ドルのペナルティー
- ポリシー2: 1.5秒以上を要する取引には10ドルのペナルティー
この例では、なぜシステムが、ポリシー2に4回違反するよりもポリシー1に1回違反する方が良い、と選択するかが、すぐに分かります。
ポリシーは、4つのカテゴリーのどれにも入らないような情報も含むことができる、ということにも注意してください。例えばポリシーには、名前やテキスト記述、誰がポリシーを書いたのかを示すもの、変更履歴、などを持つ場合があります。これらはポリシーを記述しますが、ポリシーをどう使うかには影響しないので、私は単純に一式まとめて、メタデータとしています（メタ・ポリシーと混同しないでください）。
この記事の最初の方では、例を簡潔にするために条件と決定のみに焦点を当てましたが、多くの場合、4つの要素全てが揃わないとポリシーは完全ではなく、堅牢なポリシー言語は4つの全てをサポートしています。これは重要ですので、よく注意してください。
皆さんは、4つの決定タイプが、上記で特定した4つのポリシー・タイプに対応していることにも気がついたかも知れません。他にも分類方法がありますが、オートノミック・システムを議論する場合には、こうした表現で分類すると非常に便利だと私は思っています。
オートノミック・コンピューティングでのポリシー管理
ここでは詳細を議論しませんが、オートノミック・コンピューティングでのポリシー管理では、ポリシー・タイプのうちの3つ、アクションとコンフィギュレーション・プロファイル、そして 結果をサポートしている、ということを注意しておきましょう。（オートノミック・コンピューティングでのポリシー管理は、今後の記事で詳しく説明される予定です。）オートノミック・コンピューティングでのポリシー管理についての詳細は、参考文献を見てください。
開発者達がこれらのポリシーを選択した理由は、（1）オートノミック・システムにとって、自動的なコンフィギュレーション管理が非常に重要なこと、また、（2）アクション・ポリシーと結果ポリシーはコンフィギュレーション・ポリシーの一面と非常に似ているため、コンフィギュレーション管理が実装されてしまえば、アクションと結果は非常に単純なためです。
開発者達がゴールを選択しなかったのは、ゴールは難しいからです。いや、これは冗談です。アクションとコンフィギュレーションは汎用的にサポートすることができますが、ゴールに関しては、そう行かないのです。
ゴール・ポリシーを考えてみてください
- スコープ: 会社Aのオンライン発注システム
- 条件: 営業時間中
- ビジネス価値: 100
- ゴール決定: 平均2秒の応答時間
汎用のオートノミック・マネージャーを作ってオンライン発注システムを監視し、ゴールが達成されたかどうかを判定するのです。このために必要なのは単純に、オンライン発注システムから来るデータを監視し、平均応答時間と2秒のゴールとを比較することだけです。
ゴールを達成することは、桁違いに複雑です。オートノミック・マネージャーは、ゴールに合致し続けるように維持管理するマネージャーの下で、リソースのコンフィギュレーションを調整する方法を知らなければなりません。これには、ゴールのタイプ（この場合では応答時間）に合わせて微調整された、カスタム・コードが必要です。このコードは多くの場合、管理対象のリソースに対しても微調整されている必要があります。汎用のコードでは、まるで不十分なのです。もちろん、ゴール達成用のオートノミック・マネージャーもあります。IBM Enterprise Workload Managerは、応答時間やその他のゴールを管理し、Tivoli® Intelligent Orchestratorはリソース割り当てのゴールを管理します。私は将来、広範な種類のゴール達成用オートノミック・マネージャーが市場に出てくることを期待しています。
まとめ
ポリシーは、1つの記事で網羅する話題としては大き過ぎます。またポリシーに関しては、数多くの本も書かれています。この記事では、必須項目であるスター・ウォーズとシェイクスピアからの引用と共に、ポリシー・タイプやポリシーの共通要素、競合解決の基本、目立った標準化作業など、基本的な話題を紹介しました。皆さんには、Dakshi AgrawalによるdeveloperWorksのチュートリアル（参考文献を見てください）を読むこと、そしてオートノミック・コンピューティングでのポリシー管理（Policy Management for Autonomic Computing）を試してみることをお勧めしたいと思います。
参考文献
著者について  | 
| | David KaminskyはIBMのオートノミック・コンピューティング・グループに所属するSoftware Architectとして、ポリシーに基づく管理システムに焦点を当てた作業を行っています。オートノミック・コンピューティングに関わる前には、ストレージ・システムやポータル、パーベイシブ・コンピューティング、Java技術などに携わってきました。IBM Master Inventorであり、エール大学で並列コンピューティングや分散コンピューティングを学び、コンピューター・サイエンスで博士号を取得しています。彼の成果による2種類の商用製品は、今でも市販されています。 |
記事の評価
| 
