オートノミック・コンピューティングとWSDM（Web Services Distributed Management）

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Thomas Studwell (studwell@us.ibm.com), Senior Technical Staff Member, Autonomic Computing Group, IBM　
Heather Kreger (kreger@us.ibm.com), Lead Architect for Web Services and Management for Standards and Emerging Technologies, IBM　

2005年 6月 04日

OASIS（Organization for the Advancement of Structured Information Standards）は最近、新しい標準、WSDM（Web Services Distributed Management）1.0を承認しました。この記事は、この新しい標準がオートノミック技術にもたらす価値と、両者の関係についてご紹介します。ただし、この記事では、オートノミック・コンピューティングに準拠したインターフェースをWSDMを使って構築するための技術的な詳細については触れません。その詳細については、そうしたインターフェースが開発される際に、他の記事や仕様から紹介されることになるでしょう。

初めに: オートノミック・コンピューティングにとっての大きな一歩

OASISは最近、管理統合問題の解決の第一歩として、WSDM TC（Web Services Distributed Management Technical Committee）から提案された新しい標準を承認しました。OASISは、Web Services Distributed Management : MUWS（Management Using Web Services）とWeb Services Distributed Management : MOWS (Management of Web Services、(参考文献)という、2組の仕様を承認、公開しています。WSDMに関する高位レベルの記事に関しては、developerWorks の記事、「WSDMに関するヒント」を見てください。

WSDM 1.0の標準化は、オートノミック・コンピューティング技術にとって重要な第一歩です。その理由を理解するためには、オートノミック・コンピューティングの目指す基本的なゴールを考える必要があります。IBMでは、オートノミック・コンピューティングに関する活動を始めた最初から、オートノミック・コンピューティングがIBM独自のものに頼ってはならないということを理解していました。オートノミック・コンピューティングの価値が本当に発揮されるのは、オートノミック・マネージャーが、企業のITインフラ上の機器やソフトウェアの大部分に自己管理機能をもたらせるようになった時です。IBMのホワイトペーパー、An Architectural Blueprint for Autonomic Computingによると、「オートノミック・コンピューティング・システムでは、ITインフラにまたがってオートノミック・マネージャーが展開されていること、そして多様なサプライヤーからの様々なリソース（他のオートノミック・マネージャーを含みます）をオートノミック・マネージャーが管理していることが必要です。従って、こうしたシステムは、業界のオープン・スタンダードに基づく必要があります。」とあります。

今日のITリソースの管理機能（manageability capabilities）を扱うオープン・スタンダードは、オートノミック・コンピューティング技術の展開を成功させるために必須のものです。WSDM標準は、以下のように幾つかの面から重要です。

• 第1に、主導的なシステム管理ソフトウェアのサプライヤーのみならず、ミドルウェアやオペレーティング・システム、ハードウェアなどのベンダーの全てがこの委員会に参加しており、広範な業界サポートが確保されています。これは標準が実用的なものとなるために必須の条件です。
• 第2は、この標準が、今日のビジネスにとって必須の技術（Webサービス）に対して、必要な管理インターフェースを提供しているという点です。ビジネス界では、致命的アプリケーションにおけるWebサービスの利点を認識しつつあり、この標準は、こうした致命的アプリケーションにおいてシステム管理ツールを使用するための手段を提供しています。
• 最後に、この標準によって、Webサービスのサービス指向アーキテクチャー（SOA: Service-Oriented Architecture）がもたらす底知れないパワーを、システム管理プラットフォームが利用できるようになります。記事、「Management Using Web Services -- A proposed architecture and roadmap」では、ビジネス・アプリケーションに対してWebサービスが証明したのと同様に、SOA技術によって、管理技術、特に複数サプライヤーからの管理技術の統合が非常に容易になることを説明しています。これはオートノミック・コンピューティング・アーキテクチャーにとって、非常に重要な利点です。ITリソースへの管理インターフェースがWebサービスを通して公開されるようになると、オートノミック・マネージャーは標準化された記述子（descriptor）を使ってリソースの管理機能を理解し、監視し、対話動作できるようになり、特定範囲のリソースを処理するためにオートノミック・マネージャーをカスタム設計する必要がなくなります。

WSDMの価値は、IBMやその他の会社が、オートノミック・コンピューティングの基礎である新技術を提供することによって、さらに高まります。IBMのCommon Base Eventなど鍵となる技術は、WSDMのイベント・フォーマットの基本として使われていますが、複数リソースからのイベントを相関させる機能を改善するものであり、この技術によって、複雑なコンピューティング環境における問題診断の所要時間や正確さが改善されるのです。

初期の基礎としてのWSDM標準は、完全にオートノミックなコンピューティング環境に向かう上で大きな前進ですが、オートノミック環境をサポートする他の仕様も、やがて生まれてくるはずです。オートノミック・コンピューティングのプラットフォームを構築するための基礎はWebサービスだけではありませんが、Webサービスを利用できるという利点によって、オートノミック・コンピューティングの実装や統合が容易になることは確かです。オートノミック・コンピューティングのブループリントでは、以下のように言っています。

このアーキテクチャーは、特定な管理プロトコルや実装技術は規定していません。これは、今日の業界に存在する様々なコンピューティング技術や標準、つまりSNMPやJMX（Java Management Extensions）、DMTF（Distributed Management Task Force, Inc.）、さらには将来の技術などに対応する必要があるためです。

このアーキテクチャーは、IT業界に既に存在する、こうした管理技術の多様さを考慮し、センサーやエフェクターとしてWebサービス技術を推奨しています。Webサービス技術のおかげで、実装者は既存の手法を活用でき、複数のバインディング技術やマーシャリング技術をサポートできるようになるのです。

上に戻る

オートノミック・コンピューティングの実装において、WSDMはどのような位置を占めるのか

オートノミック・コンピューティングのブループリントで記述されているオートノミック・コンピューティングのアーキテクチャーは、コンピューティング・インフラの様々な側面を動的に管理する、1つ以上の制御ループから成っています。このオートノミック制御ループを記述するために、MAPEという言葉が使われることがあります。これは、この制御ループの4つの基本要素、Monitor(監視)、Analyze(分析)、Plan(計画)、そしてExecute(実行)の頭文字を取ったものです。この制御ループに関連する、システムやそのポリシー、リソース管理用の内部アルゴリズムなどに関する知識を持ったオートノミック制御ループは、オートノミック・マネージャーとして定義されます。

オートノミック・マネージャーは、ビジネスによって確立されたビジネス・ゴールに基づいて、一連の自己管理タスクを実行します。こうしたタスクは非常に幅広い管理機能の場合もあれば、非常に狭い管理機能の場合もありますが、どれも、そのオートノミック・マネージャーが管理するリソースの要求に基づくものです。例えば、自己修復機能を実行することに特化したオートノミック・マネージャーがあるかも知れません。こうしたオートノミック・マネージャーは、自分が管理しているリソースの健康状態を監視し、既存の条件を分析し、その条件によって要求される場合には、リソースに対して変更を加える必要があります。

図1は、オートノミック・マネージャーと、リソースに対する管理インターフェース（manageability interface）を理想化した状態を示しています。

オートノミック・マネージャーによって管理されるリソースに対する管理補助インターフェースの実装は、タッチポイント（touchpoint）と呼ばれます。タッチポイントのアーキテクチャーは、オートノミック・コンピューティング・アーキテクチャーのチームによって定義されており、管理対象リソースに適切な形で、様々な方法で実装することができます。

オートノミック・コンピューティングのブループリントでは、タッチポイントを次のように記述しています。

タッチポイントは、オートノミック・コンピューティング・システムの構成ブロックであり、1つまたはそれ以上の管理対象リソースの管理機構に対して、センサーとエフェクターの振る舞いを実装します。タッチポイントはまた、標準的な管理インターフェースも提供します。展開された管理可能リソースは、こうした管理インターフェースを通してアクセスされ、制御されます。管理インターフェースは、ログ・ファイルやイベント、コマンド、API（application programming interface）、コンフィギュレーション・ファイルなどの機構を用意しています。こうした機構によって、管理対象リソースの振る舞いの変化の詳細を、様々な方法によって収集できるのです。このブループリントの意図するところでは、詳細を収集するために使用される機構は管理対象リソースに対するセンサーへと集約され、管理対象リソースの振る舞いを変更するために使用される機構は、リソースに対するエフェクターとして集約されます。

Webサービスのもたらす利点を考えると、タッチポイントの実装として望ましいのは、タッチポイントを、1つまたはそれ以上のWebサービス・インターフェースとして公開エクスポーズすることです。この場合、タッチポイントはWSDMの管理可能リソース（WSDM Manageable Resource）として、WSDM準拠である必要があります。

この先で詳細を説明しますが、WSDMは、オートノミック・コンピューティング・タッチポイントの必須要素である全機能を、必須として定義しているわけではありません。例えばIBMのCommon Base Eventは、WSDMのイベント・フォーマットには対応要素が無いような要素を要求します。幸いWSDMインターフェースは拡張性を持っているため、タッチポイントを実装する人は、こうした機能をWSDM準拠のエクステンションを通して提供できますが、エクステンションの実装が標準化されているわけではありません。エクステンションの使用は必須として定義されていないため、インターオペラビリティーを確保するためには、対象となるリソースとマネージャーの関係における利害関係者の合意が必要になります。IBMは、この重要な標準が私達の顧客にもたらす利益が最大となるように、業界の他のリーダー達と密接に協力しており、こうしたWSDMエクステンションの適切な使い方に関して合意できるよう、またエクステンションの標準化に向けての可能性を探っています。

こうした話題が業界で活発になれば、オートノミック・コンピューティングを実現するようなWSDMインターフェースや管理インターフェースが生まれてくるでしょう。確かにWSDM 1.0は、タッチポイントを実装するために必要なもの全てを定義してはいませんが、オートノミック・コンピューター準拠のタッチポイントを構築するための確実な基礎と、拡張するためのポイントは提供しているのです。この記事の後半は、今日これをどのように行うかについて説明して行きます。

タッチポイントに関して1つ重要な点は、今日の複雑な世界においては、リソースが単純で単機能な実体であることは稀である、という点です。例えばデータベース・サーバーは、複数のデータベースやデータベース・テーブル空間、データベース・テーブルといった複数の関連リソースの集約を表します。そうするとWebアプリケーション・サーバーは、そのサーバーによって管理される幾つかのWebアプリケーションを「ホスト」することになります。この見方は、非常に現実的ではありますが、この記事の範囲を超えています。ここでは分かりやすくするために、単純なケースに焦点を当てることにします。ですから、ここでは議論に取り上げませんが、ホストされたリソースのモデルをサポートするために必須な、管理機能が他にもあることは意識しておいてください。

上に戻る

タッチポイントに関する詳細

センサーとエフェクター

管理インターフェースは、センサーとエフェクターに分けることができます。

センサーは、状態変化が起きた場合に、マネージャーが管理可能リソースの状態にアクセスするための手段を、要求に応じて、あるいは通知によって提供します。センサーの例としては、管理可能リソースの現在の操作状態と、その操作状態の遷移に関する情報を公開する、エンドポイントがあります。

エフェクターは、マネージャーが管理可能リソースの状態や振る舞いに対して影響を与えるための手段を提供します。エフェクターの例としては、管理可能リソースの停止操作を提供する（つまり操作状態を「停止」に変更する）エンドポイントがあります。

センサー・インターフェースとエフェクター・インターフェースは、タッチポイントとオートノミック・マネージャーとの間の対話動作として、4つの固有なスタイルをサポートしています。つまり、リクエスト/レスポンス（Request-response）、送信/通知（Send-notification）、実行/操作（Perform-operation）、請求/レスポンス（Solicit-response）という4つのスタイルです。

『リクエスト/レスポンス』と『請求/レスポンス』の対話動作スタイルは、「リクエスト/レスポンス」というフローであり、データを返します。『送信/通知』と『実行/操作』の対話動作スタイルでは、データの流れは基本的に「一方通行」です。これらのスタイルではデータは何も返しませんが、フローの成功失敗に関する詳細を返します。

WSDMでは現在、『請求/レスポンス』の対話動作スタイルを定義していないため、この対話動作スタイルが必要な場合には、エクステンションとしてサポートするか、あるいはWebサービスにおける、別のサービスに対するリクエスト/レスポンスのフローとして見る必要があります。タッチポイントは、全ての対話動作スタイルをサポートする必要はありませんが、（そのIDが検索できるように）『リクエスト/レスポンス』はサポートする必要があります。

機能管理機能（Manageability capabilities）

オートノミック・コンピューティング・アーキテクチャーでは、タッチポイントがサポートする、管理機能を定義しています。下記は記事、「WSDMに関するヒント」からの引用です。

管理機能（manageability capability）というのは、ある特定な管理タスクをサポートするために組み合わせて構成できる、一連のプロパティーやオペレーション、イベント、メタデータその他の意味体系を言います。これは、大部分のリソース情報モデルで一般的な概念を捉えたものです。管理機能は、管理可能リソースがクライアントに提供できると主張する「約束事」を識別します。管理機能は、Javaなどのプログラミング言語における「マーカー」インターフェースに似た、抽象的なインターフェースと考えることができます。WSDM MUWSは、基本的な管理概念のための、基盤としての管理機能セットを定義しています。新規の、あるいは領域特有の機能は、必要に応じて既存の基盤機能を拡張することができます。

管理機能の一部は必須、一部はオプションであり、そしてタッチポイントは自分のリソースを管理するために必須な、独自の固有機能を定義する場合が多いでしょう。ただしどの場合にも、管理機能はWSDM仕様に準拠した形式で表現する必要があります。

一般的に言って、センサーはWSDMメトリックスやID、リレーションシップなどの機能を持つものとして実現されます。こうした機能によって、WSのリソース・プロパティー・インターフェースを通してアクセス可能なプロパティーと、WSDMのイベント・フォーマット準拠のメッセージを含む通知、という両方が提供されます。エフェクターはWSDMのコンフィギュレーション機能として実現され、こうした機能はWSのリソース・プロパティー・インターフェースを通して設定されるプロパティーや、振る舞いを変化させる他の操作を定義します。

表1は、単純な管理可能リソース（MR: manageable resource）に対するオートノミック・コンピューティング・タッチポイントが実装する、管理機能を示しています。この表には3つの名前空間が使われていることに注意してください。表の中で使われている名前空間の接頭辞は、そのインターフェースに対する仕様のソース（以下）を示しています。

• wsdm: WSDM V1.0標準で定義されています
• wsrp: WSのリソース・プロパティー仕様である、WS-RF（WS-Resource Framework）で定義されています
• actp: オートノミック・コンピューティング・アーキテクチャーの中で、公開された標準への、あるいはドラフト標準へのエクステンションとして定義されています。この記事で示したインターフェースは、正式に公開されるまでには変更される可能性があります。

それぞれの機能は、Required（必須、タッチポイントが実装しなければならない）、Optional（オプション。タッチポイントが実装する場合がある）、Strongly recommended（強く推奨される。タッチポイントが実装すべきである）を付けてリストアップしてあります。『要求レベル』の列は、これらをそれぞれ「R」「O」「S」として表現しています。

actp:ResourceType: ResourceTypeは、管理可能リソースに対して分類の階層構造を提供するために使われます。この、分類の階層構造によって、オートノミック・マネージャーは（どの程度高度なマネージャーか、そしてその知識レベルによって）様々なレベルに特化した管理機能を提供することができます。例えばMicrosoft Windows?オペレーティング・システムでは、「Operating System」、「Windows」、「Win32 Operating System」、「Windows XP Professional」といった分類階層構造を持っているかも知れません。この分類階層構造を利用することによって、「Win32 Operating System」の管理方法しか知らないオートノミック・マネージャーでも、ある程度の管理を行うことができる一方、「Windows XP Professional」オペレーティング・システムに固有な機能を知っているオートノミック・マネージャーは、より高度なレベルの制御を行うことができます。どちらのマネージャーも、ある程度までリソースを管理できるのです。

このインターフェースには、次の2つのプロパティーがあります。

• actp:ResourceTypeは、管理可能リソースのリソース・タイプを識別する一連のURIです。管理可能リソースは、複数のタイプを持つことができます。それぞれのタイプは、リソース・タイプのリーフとしての分類階層構造の中にあるか、あるいは管理可能リソースに関する別の分類構造から成っています。
• actp:Nameは、ローカルで知られているリソース名を示す文字列を含みます。この名前はリソースによって割り当てられ、リソースのインスタンス毎に固有である可能性があります（リソース・モデルが異なると、リソースを固有識別するための識別プロパティーの組み合わせに関して別の規則を使う可能性があります）。例えば、オペレーティング・システム、あるいはアプリケーション・サーバー・リソースのNameは、リソースの製品名（通常はリソースのインスタンス毎に固有であることはありません）ではなく、リソースのホストのホスト名（リソースのインスタンス毎に固有な可能性があります）であるかも知れません。

上に戻る

タッチポイントに関する詳細

オートノミック・マネージャーは、その監視(Monitor)機能を使って、自分が管理するリソースの状態を検知します。この情報は次に、オートノミック・マネージャーのゴール達成に必要な変更が加えられるように、先ほどの制御ループの残り部分（MAPEのうちの、分析、計画、実行という機能を持ちます）に渡されます。リソースの状態を連続的にポーリングする実装も可能ですが、そうした実装は（ポーリングのオーバーヘッドによって）非効率になったり、（ポーリング周期が長く設定されると）応答しなくなったりしがちです。イベント駆動のレスポンスは、これら2つを最も効果的にバランスさせることができ、従って好ましい方法として選択されることが多いと言えます。

ほとんど全ての管理システムでは、効率的な状態監視にイベントを使いますが、オートノミック・コンピューティング・アーキテクチャーでは、広範な種類のITリソースの生成するイベントが、比較的小さなイベント・カテゴリー、つまり状況（situations）に分類できること認識しています。そのため、イベント通知を通して効率的にイベントが収集できるだけではなく、効率的なイベント分析も行うことができ、その結果レスポンス時間が改善され、またオーバーヘッドを処理するためにマネージャーが費やす時間も減少します。さらに、本質的に異なるリソースからレポートされたイベントも単純化できることから、複数リソースからのイベント相関を大幅に改善、自動化できること、そしてその結果、自動分析可能な問題のスコープ・レベルをずっと高度にできることも、オートノミック・コンピューティング・チームでは認識しています。

IBMのオートノミック・コンピューティング・アーキテクチャーではCommon Base Eventを開発し、この成果をWSDM標準に含めるべく、WSDM TCに提出しました。Common Base Eventの全要素がWSDM標準に取り入れられたわけではありませんが、その構造や分類に関する成果は、WSDMのイベント・フォーマットに大きな影響を与えています。

上に戻る

WSDMのイベント・フォーマット

WSDMのイベント・フォーマットは拡張可能なXMLフォーマットとして、基本的な、そして一貫性のある一連のデータ要素を定義したものであり、これによって様々なタイプの管理イベント情報を一貫した方法でレポートできるようになります。WSDMのイベント・フォーマットによって、様々な製品やプラットフォーム、管理技術などからのイベントを、プログラム的に処理、相関、解釈できるようになります。

WSDMのイベント・フォーマットは、管理イベント・データによって、3つのカテゴリーに分けることができます。

• イベント・レポーターのID
• イベント・ソースのID
• 状況データ

各カテゴリーは、幾つかの標準プロパティーを定義しています。これらのプロパティーは、大部分の管理イベントに見られるものであり、またイベントや状況特有のデータを追加するために拡張することができます。状況データに含まれるものとしては、状況時間、状況カテゴリー、状況の重大度、メッセージ、代替メッセージ要素などがあります。WSDMではまた、様々なリソースやリソース実装、管理インフラなどから受信するイベントに対して共通な理解ができるように、優先度や重大度、それにStartSituationやStopSituation、CreateSituationといった状況カテゴリーなどの標準セットも定義しています。こうした標準カテゴリーによって、ずっと確実な問題検知、分析、相関、レスポンスが可能となります。

WSDMでは、WS-Notificationsと、WSDMのイベント・フォーマットでフォーマットされたメッセージを使った通知をサポートしています。WS-Notificationは、Webサービス・アーキテクチャーに対して公開/サブスクライブ・サービスを提供します。例えば、独立なプロパティー変化イベントのそれぞれをサブスクライブするのではなく、全メトリック変化やコンフィギュレーション変化をサブスクライブするなど、リソースに対するイベント・カテゴリーに基づいて管理者がサブスクライブできるように、様々なフィルター方法を使用できるようになっています。

WSDMのイベント・フォーマットは拡張可能であり、Common Base EventからWSDMのイベントに割り当てるために必要なフィールドを、実装者が割り当てられるようになっています。

上に戻る

まとめ

WSDM 1.0標準は、自己管理のオートノミック・コンピューティング・システムを構築するための堅固な基礎となっており、今日のITインフラの管理容易性と堅牢さを改善する上で、大きな前進となっています。

この記事では、WSDMと、その基礎となるWS-ResourceProperties仕様が、オートノミック・コンピューティングに必須な管理インターフェースであるオートノミック・コンピューティング・タッチポイントの定義において、大きな割合を占めることを示しました。WSDMは将来を考慮して開発されており、オートノミック・コンピューティング・プラットフォームが今日からでもこの標準を使えるように、拡張可能になっています。

WSDMによって、今やWebサービスが管理できるようになりました。さらに重要なことは、Webサービス技術の利点を、今日の複雑な異機種混合コンピューティング環境における管理統合問題の解決に応用できることです。しかも、管理インターフェースが一層高度なものに改善されたため、私達の顧客はこの新しい標準を使うことによって、IBMによるオートノミック・コンピューティング活動から生まれた技術など自己管理システムの利点を、大いに活用できるようになったのです。

参考文献

• IBMのホワイトペーパー、「An Architectural Blueprint for Autonomic Computingは、この記事で取り上げた概念の背景を、さらに詳しく説明しています。
  
  
• ホワイトペーパー、「Systems management in a Web services world: Management Using Web Services -- A proposed architecture and roadmap」をダウンロードしてください。このペーパーでは、複数ベンダーによる管理システム・ソリューションを異機種混合のシステムにまたがって結合する上で、そしてその結果としての統合の困難を克服する上で、軸となる標準としてのWebサービスが、いかに鍵であるかを示しています。
  
  
• WSDMのイベント・フォーマットの基礎として、IBMによるCommon Base Eventなど鍵となる技術が使われていますが、こうした技術によって、複数リソースからのイベントを相関させる機能を改善することができます。
  
  
• Web Services Distributed Management: Management using Web Services (MUWS 1.0), Part 1は、有用なOASIS標準です。Part 2 もOASISから入手することができます。
  
  
• HeatherKregerが、WSDMに関して素晴らしい入門記事、「WSDMに関するヒント」（developerWorks, 2005年3月）を書いています。
  
  
• Web Services Resource Properties 1.2 (WS-ResourceProperties)は、OASISのワーキング・ドラフトです。
  
  
• SOAが確実に理解できるdeveloperWorksの記事として、「Service-Oriented Architecture expands the vision of Web services」（developerWorks, 2004年4月）があります。
  
  
• WSRFやWSDM、WSNなどに関するOASISの技術委員会は、Webサービスの開発に関心を持つ開発者にとって良い情報源です。
  
  

著者について

		Thomas StudwellはIBMのオートノミック・コンピューティング・アーキテクチャー組織のSenior Technical Staff Memberとして、IBMのオートノミック・コンピューティング技術をオープンな業界標準として推進する責任者です。OASISのWeb Services Distributed Management Technical Committeeに貢献者として参加しており、WSDM TCにIBMのCommon Base Event仕様を提出する責任者でもありました。IEEEのメンバーでもあり、特許も何件か保持しています。また、コンピューティング技術に関する何冊かの著書もあります。

		Heather Kregerは標準及び新興技術領域におけるWebサービスと管理のLead Architectです。彼女は現在、OASISのWeb Services Distributed Management Technical Committeeの共同議長であり、それに関連した幾つかのDMTFワークグループのメンバーです。また、W3CのWeb Services Architecture Working GroupへのIBM代表、J2EE環境でのWebサービス展開を規定するJSR109の共同主催者、JMX（Java Management Extensions）仕様への貢献者でもありました。IBM Systems JournalやCommunications of ACM、Web Services Journalなどに、Webサービスや管理に関して数多くの記事を執筆しています。その他の公開技術成果としては、「Web Services Conceptual Architecture」や「WS-Manageability」、そして彼女の著書「Java and JMX, Building Manageable Systems」などがあります。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する はてなブックマーク livedoorクリップ del.icio.us Buzzurl（バザール） Choix！ Saafブックマーク FC2ブックマーク MM/memo ニフティクリップ Yahoo!ブックマーク CZブックマーク newsing

上に戻る