前回は、クロスメディア・パブリッシング実現に向けての問題点として、「データの一元管理」「コンテンツのマルチユース」「 作業工程・データ受け渡しの効率化」について述べました。
連載の第3回目となる今回は、1つ目の問題点「データの一元管理」を、弊社オラクル製品でどのように解決できるかについて紹介 します。

コンテンツ管理システムの必要性

連載の第2回で、「データの一元管理を行うために、ファイル・サーバを集約して適切な設定／運用管理が必要」と述べてきまし た。では一つの大きなファイル・サーバを用意し、そこにすべてのコンテンツを格納すればよいかというと、必ずしもそうとは言 い切れません。コンテンツの格納先が「ファイル・サーバ」である限り、以下に示すようなさまざまなリスクが浮上してきます。

・アクセス数やディスク容量のオーバー
・添付ファイルによるデータ流出
・障害発生時のデータ喪失

上記に挙げたリスクを回避しつつ、一つのサーバへ集約するには、「コンテンツ管理システム」と呼ばれるファイル・サーバより 高度な機能を提供する基盤ソフトウエアが必要になってきます。

オラクルが提供するコンテンツ管理システム

オラクルでは、コンテンツ管理システムとして「Oracle Content Database（CDB）」を提供しております。CDBは、弊社のデータ ベース製品「Oracle Database 10g」およびアプリケーション・サーバ製品「Oracle Application Server 10g」を基盤としたコン テンツ管理システムです。
コンテンツおよびユーザー情報などの管理データは、すべてデータベースに格納されます。一方ユーザーは、アプリケーション・ サーバ上で稼動しているCDBのメイン・プログラムにWebブラウザ、もしくはネットワーク・ドライブ経由[＊]でアクセスします。 CDBにはWebブラウザでアクセスが可能なので、Windowsはもちろんのこと、MacOSやLinuxなどユーザー側のプラットフォームを問 いません。
では、コンテンツ管理システムであるCDBと、通常のファイル・サーバとは何が違うのでしょうか。以下に、ファイル・サーバと CDBの違いについて、代表的なものを示します。
[＊]Windowsにのみ対応。

ファイル・サーバとCDBの違いその1 −サーバの増強ができて障害にも強し

そもそも、なぜ複数のファイル・サーバを用意する必要があるのでしょうか。
その理由として、「一つのファイル・サーバでは全社を賄いきれない」というケースが非常に多いように見受けられます。ファイ ル・サーバを1台だけで運用していると、一度に多人数がアクセスすることで反応が遅くなったり、すぐにディスク容量不足にな るといった制約があるからです。
CDBであれば、そのような制約を受けずに、乱立するファイル・サーバを一つに集約可能です。CDBでは、クラスタリングと呼ばれ る2台以上のコンピュータを使ってサーバを構成し、利用者からはあたかも一つのサーバであるかのように動作させる技術を利用 できます。
クラスタリングによって、例えば最初は2台のコンピュータでファイル・サーバを構成し、ユーザーのアクセス数が増えてきたら3 台目のコンピュータを追加する、といった拡張性に富んだ運用も可能となります。
また、クラスタを構成するコンピュータの1台に障害が発生したとしても、残りのコンピュータでファイル・サーバを稼働し続け ることができます。つまり、クラスタリングは耐障害性にも優れていると言えます。
ファイル・サーバを一つに集約することで、ユーザーの権限も一元的に管理できます。これによって、故意もしくは過失によるコ ンテンツの不適切なアクセスも、未然に防げるのです。

ファイル・サーバとCDBの違いその2 −メール添付はもう不要

ファイル・サーバ上の機密性の高いコンテンツをメールで添付し、間違ったアドレスへ送信してしまったらどうなるでしょうか。 受け取ったユーザーは容易にそのコンテンツを参照できてしまいます。手軽に行えるからといって、ファイル・サーバ上の重要な コンテンツを安易にメール添付するのは、あまり得策だとは言えません。
CDBの場合、コンテンツをメールで送信する際のよりセキュリティの高い方式として、「コンテンツへのアクセスURL」を提供しま す。
先に紹介したとおり、CDBはWebブラウザですべての操作を行うことができます。従って、CDBに格納された各コンテンツに対して も、個別のURLが割り振られています。ユーザーはそのコンテンツへの適切なアクセス権限があればよいので、コンテンツ自体を 相手に送信する必要はありません。メールの本文中に、CDBで示されたURLをコピー＆ペーストするだけで十分です。
コンテンツ自体の添付からアクセス先URLの記述に変えることで、たとえ間違った相手にメールを送信したとしても、受け取った ユーザーにアクセス権限がなければ、そのコンテンツを見ることはできません。このように、不慮の事故が発生したとしても、被 害を最小限に食い止めることができるのです。

ファイル・サーバとCDBの違いその3 −ディスク障害でもデータは元通り

ファイル・サーバにディスク障害が発生した場合、データはどの時点まで復旧できるでしょうか。
どんなに頻繁にバックアップをしていたとしても、復旧できるのは「最後にバックアップを取得した時点」になってしまいます。 つまり、それ以降の変更に関しては失われてしまいます。
CDBのコンテンツ格納先であるOracle Database 10gは、すべてのデータをディスク障害が発生する直前まで復旧させることができ ます。当然ながらファイル・サーバと同じく、CDBの格納先データベースを構成するファイルの定期的なバックアップは必要です 。Oracle Database 10gではそのほかに、データベースに対するすべての変更処理を記録したファイル（アーカイブ・ファイル） を自動生成する機能があります。
ディスク障害が発生した際には、まず一番最近に取得したバックアップ・ファイルを、該当のディスクにコピーします。そしてそ のファイルに対して、「バックアップ以降に行われた変更情報」をアーカイブ・ファイルから取り出して順次適用していきます。 障害直前までのすべての変更情報が適用されれば、データベースの復旧は完了です。
全社に分散されたコンテンツを1カ所に集約すると、アクセス先の統一や重複コンテンツの排除というメリットがある反面、障害 が発生した際には重要なコンテンツが失われるという危険性も高まります。よって格納されたコンテンツをいかに復旧できるか、 についても考慮しておく必要があるのです。
第4回目では、「コンテンツのマルチユース」にまつわる問題点を、弊社オラクルの製品でどう解決できるのか、について紹介し てまいります。

CDBについてのお問い合わせは、日本オラクルの営業窓口であるOracle Directまで。
TEL 0120-155-096
URL http://www.oracle.co.jp/direct/

『プリンターズサークル』11月号より

2006/11/07 00:00:00