セキュリティとパフォーマンス

世界最大規模であり、防護に最も力を入れている情報機関がオートノミーの知的財産保護システム（IAS：Intellectual Asset Protection System）を導入し、非常に機密性の高い情報資産を保護しています。オートノミーは、様々なセキュリティ管理機能を提供しています。この中には、フロントエンドのユーザ認証機能、バックエンドの権限確認機能、IDOLサーバとクライアントアプリケーション間のコミュニケーションを128ビットのBlock Tiny Encryption Algorithm（BTEA）で暗号化する機能などがあります。IDOLのマップドセキュリティ・ モデルは、実践の場で証明されており、企業内で拡張可能なインデックスを用いた唯一のセキュリティモデルです。

3種類のセキュリティモデル:

1. アンマップドセキュリティ

アンマップドセキュリティは、ソース リポジトリや検索エンジンが採用している従来式の方法です。特定のクエリに照合する可能性があるドキュメントがあると、既存のリポジトリのAPI（Documentumなど）を経由して要求が出され、その特定のドキュメントにアクセスする権限があるかを確認します。検索システムは何千件ものヒット候補から関連性のある検索結果リストをまとめようとします。そのため、ひとつのクエリが既存のレポジトリに対してドキュメントへのアクセス権限の有無を問合せる多数のリクエストを送信します。この方法 ではパフォーマンスと拡張性の大きな問題を引き起こします。

アンマップドセキュリティ

マップドセキュリティ

オートノミーはマップドセキュリティを推奨する一方で、マップド、アンマップド、または両方を掛け合わせたセキュリティを提供します。さらにオートノミーはプラグインのサンプルコードを提供しているため、お客様、OEM、パートナーはそれぞれ独自の形式のセキュリティ プラグインを開発して導入することができます。

2. キャッシュを用いた方法

キャッシュを用いた方法はレガシーシステム向けの方法です。この方法は、これまで実行されたクエリの結果を格納することで、アンマップドセキュリティに付随する拡張性の問題をごくわずかに緩和します。ユーザが同じクエリを繰り返し実行した場合、一連の結果をキャッシュから取り出します。ネットワークを介してリクエストを送信することはありません。しかしこの方法も、新しいクエリが実行される度にネットワーク全体にわたりレポジトリ対して直接要求する必要があります。さらに、キャッシュされている一連の検索結果は新しい情報を 動的には更新しないため、関連性のある可能性がある情報を見過ごしてしまいます。

3. オートノミー独自のIASマップドセキュリティ

マップドセキュリティを提供するのはオートノミーだけです。マップドセキュリティは、詳細に設定することができ、安全かつ精度が高く、迅速な方法です。マップドセキュリティはサードパーティ製品のセキュリティ権限を変えることなく受け継ぎます。IDOLは、すべての基盤となるレポジトリから基盤となるセキュリティモデルをACL、グループ、ロール、保護情報などの形でIDOLエンジン自体のカーネルに直接マッピングし、情報を暗号化されたフィールドに保存します。このため、IDOLは検索結果リストを作成するためにネットワークを介して データストアに対してリクエストを送信する必要がありません。ユーザが閲覧可能なものはIDOLカーネル内でのみ評価されます。この評価は既存のレポジトリのレスポンスタイムよりも速いスピードで行われます。ほかの手法と異なり、このモデルの場合は基盤となるコンテンツの権限が更新されたり変更されたりすると、コネクタレイヤがその情報をリアルタイムにIDOLに通知するシグナル伝達メカニズムを備えているため、常に更新が行われます。

IDOLのアーキテクチャは本質的にモジュール式の設計になっており、通常はこうした設計では複数のサブシステムが互いに通信し合う必要があります。そして多くの場合、安全でないネットワークを介してやり取りすることになります。しかしIDOLでは、これらのプロセス間の通信を暗号化（SSL）することができるため、ファイヤーウォールを突破してしまうパケットスニファでもIDOLのモジュール間でやり取りされるコンテンツを読むことはできません。システムのモジュールすべてがセキュアな通信モードで動作でき、処理のオーバーヘッドを 最小限に抑えたまま128ビットの暗号化による保護を実現します。さらにIDOLは、コンテンツの収集とクエリ実行にもSSLを有効活用することができます。またSSLで暗号化されたサイトにアクセスする際にもSSLを活用できます。

拡張性とパフォーマンス

T構造化コンテンツと非構造化コンテンツを管理するためには、非常に厳しいパフォーマンス要件に対応し、ビジネスのニーズに合わせて容易に拡張可能なプラットフォームが必要です。IDOLは、ほぼすべての業界で採用されており、世界最大規模の企業全体での導入やポータルでの導入が可能です。IDOLの拡張性は、モジュール式の分散型アーキテクチャを基盤としているため、様々なベンダが提供するデュアルCPUサーバで膨大な量のデータを処理できます。たとえば、ChoicePointの100億件のレコードをサポートするために必要なのは、わずか 数百台の基本的なエンタープライズサーバだけです。

一つのIDOLエンジンができること:

この強化された拡張性により、ハードウェアにかかるコストを削減し、より大量のコンテンツを処理できるようになります。IDOLは、様々なベンダのサーバとの親和性が高く、拡張するだけでなく、アーキテクチャが柔軟です。そのため、超並列、SMPプロセス機能、64ビット環境（Intel Itanium 64ビット アーキテクチャなど）、ソフトウェアプラットフォーム（Solaris10、Linux 64、Win64など）、複数の分散型サーバがある環境、そして一般的な形式のすべての外付けディスクアレイ（NAS、SANなど）をフル活用してパフォーマンスをさらに 高めることができます。また優れた柔軟性により、これらの異なる環境を単独または組み合わせて活用することも可能です。

仕組み

様々なレポジトリのコンテンツはコネクタにより集約された後、IDOLサーバにインデックスされるか、Distributed Index Handler（DIH）により複数のIDOLサーバにわたり分散してインデックスされます。DIHは大量のデータを複数のIDOLサーバのインスタンスに効率的に分割してインデックスします。この際、パフォーマンスを最適化する為に、データのバッチ処理、すべてのインデックスコマンドの複製などを行い、動的に負荷分散を行います。DIHは、日付別にコンテンツを分散するなど、クエリ実行の効率を高めるためにデータに応じてオペ レーションを実行することも可能です。また分散サーバであるDistributed Action Handler（DAH）は、ユーザがクエリ実行などのアクション コマンドをIDOLサーバに分散できるようにしてパフォーマンスを高めます。DAHによりアクションが分散されるIDOLサーバの複製が複数あるため、サーバに障害が発生した場合でも中断することなくサービスを提供できます。また、柔軟性を高めるために、DAHとDIHはいずれもミラーリングモード（IDOLサーバは完全に同じもののコピー）や、非ミラーリングモード（各IDOLサーバは設定が異なり、保有するデータも異な る）で実行するように設定可能です。さらに、Distributed Service Handler（DiSH）のコンポーネントは、そのほかのオートノミーの全コンポーネントを効果的に監査、モニタリング、アラート通知します。

リニアな拡張性

単に既存システムの複製を作成するだけで、パフォーマンスと容量を倍にすることができます。そうすることで、ボトルネックの発生を懸念することなく拡張予測をすることができます。

ロードバランシング

オートノミーは、データを複数のサーバにわたって自動的に複製し、ユーザからのリクエストを負荷分散します。こうしてパフォーマンスを保証し、呼び出し時間を減らし、ユーザエクスペリエンスを向上させます。

ミラーリング／フェイルオーバー

自動生成された複製を活用していくつもの予備サーバを提供します。プライマリリソースは自動的に選択されており、それが障害を起こした場合、システムはセカンダリシステムに切り替わります。そのためサービスは速やかに継続されます。

分散

拠点が分散している組織については、システムが配置可能な場所に自動的に複製を作成し利用可能にします。リモートの複製は、ローカルシステムに障害が発生した場合にしか利用されません。単一のシームレスなサービスにより、耐障害性、ローカルパフォーマンスの利点、リソース費用の削減を実現できるのです。

適応確率論的キャッシング（Adaptive Probabilistic Concept Caching）

使用頻度が高いコンセプトはメモリに保存され、可能な限り迅速かつ効率よくクエリ結果が返されます。

イベント予定

過去のイベント

関連するイベントはありません。 こちら あるいは こちら をご覧ください。

関連する導入事例資料はありません。その他のケーススタディ資料は http://publications.autonomy.com/ をご覧ください。