目次


Lotus Notes/Domino 7 の会議室予約の設計

Comments

会議室予約機能は、カレンダーとスケジュールとともに Lotus Domino 4.5 で導入されました。会議室予約システムは、会議、イベント、または他のアクティビティ用にユーザーが会議室やリソースを予約するための統合システムです。会議を設定するとき、カレンダーとスケジュールのインターフェースまたは会議室予約データベースから、他のユーザーを招集するのと同様に、目的の会議室やリソースを予約できます。カレンダーとスケジュールがユーザーのメールファイルの一部であるのに対し、会議室予約要求は、会議室やリソースが置かれている共有データベースを使用して処理されていました。

Notes/Domino 7 では、会議室予約システムが大幅に機能強化されています。この記事では、これらの機能強化について解説します。まず、Notes/Domino の会議室予約機能の歴史を簡単に振り返ることから始めます。次に、インターフェースの改善やクラスタ対応設計を含め、Notes/Domino 7 での新しい会議室予約機能の特長について説明します。この記事は、Notes/Domino の基本的な機能に慣れている方を対象に書かれています。

会議室予約機能の簡単な歴史

Notes/Domino 4.x では、会議室予約はいくつかのエージェントを使用し、予約の要求、更新、およびキャンセル (以降、これらをまとめて「予約要求」と表記します) の処理を Agent Manager に依存していました。もちろん、この方法でも会議室予約に必要な機能は提供されていましたが、予約要求の処理が本来的に遅いため、パフォーマンスを改善する余地がありました。

Domino 5.x および 6.x では、予約要求の処理を制御するために、テンプレートスクリプトとバックエンドの処理コードを使用するよう会議室予約システムがアップグレードされました。まだ 1つのエージェントが使用されていましたが、その主な目的は過去のイベントを削除することで、素早い処理はそれほど重要ではありませんでした。アップグレードされたこのシステムは、R4.x の設計と比べ、主に実行速度が速い点で改善されています。また、このシステムは、ユーザー間で送信されるメッセージの自動処理に使用されるカレンダーとスケジュールの自動処理機能を共有しています。コードの再利用によって、ユーザーはより一貫した操作性を得られました。

新しい会議室予約システムは応答が速くなりましたが、まだ部分的に外部依存するところがあり、会議室やリソースの予約が重複する可能性がありました。自動処理はサーバーサイドのコードまたはデータベースで実行されますが、どちらも空き時間データの正確さに依存して動作していました。空き時間情報が Schedule Manager (SchedMgr) によって非同期的な方法で更新されると、カレンダーとスケジュールまたは会議室予約データベースからの予約要求が競合し、重複予約が可能になる時間帯が生じます。この時間帯は非常に短いのですが (せいぜい数秒程度)、この時間内に予約要求が作成または送信されると、1 つの会議室が重複して予約されてしまいます。実際には、多数のユーザーがごく少数の会議室を奪い合うような環境を除き、現実的な頻度でこのようなことが発生する例はほとんどありません。200人ほどのユーザー数であれば、数千人のユーザーに比べ、会議室のスケジュールが重複する可能性はかなり低くなります。

もし、会議室予約データベースのレプリカを複数のサーバーに置くと、二重予約 (またはそれ以上に重複する予約) の可能性は、実際に大幅に高まるでしょう。この理由は、会議室予約データベースで直接作成された予約要求は、空き時間情報システムでこの会議室が「予定あり」と表示されていない限り、自動的に受け入れられるからです。この結果、受け入れられた予約を 2 番目のレプリカに保存してから、これを会議室予約データベースのホームサーバーに複製し直して空き時間情報に反映するまでの遅延時間が生じ、重複予約の可能性が大幅に高まります。このリスクのために、Domino 5.x と 6.x では、会議室予約データベースのレプリカが禁止されています。

図 1 は、Domino 5.x/6.x の会議室予約の設計を示す概念図です。Notes Client とルーターでの要求の処理ロジックが示されています。

図 1. Domino 5.x/6.x の会議室予約システム
Domino 5.x/6.x の会議室予約システム
Domino 5.x/6.x の会議室予約システム

Domino 7: 会議室予約の新規モデル

Domino 7 では、会議室予約システムの使いやすさと信頼性に関するユーザーからの要望に応える努力をしました。このために、重複予約の可能性をなくすことを最終目標として、会議室予約システムを再設計しました。これは第 1 の条件で、これに基づいてすべての設計を評価しました。つまり、提供される機能または機能強化で重複予約の可能性がある場合、このような設計を認めませんでした。2 番目の条件は、会議室予約データベースのレプリカを複数のサーバーに配置できるようシステムを再設計することです。私たちは、この条件をさらに強化し、クラスタフェイルオーバーを予約要求の処理に追加することにより、クラスタ対応を実現しました。

また、どの Notes Client でも使用できる会議室予約関連の新機能も、いくつか追加されています。新しい会議室予約システムの利点を享受するために必要なことは、サーバーと会議室予約システムを Domino 7 にアップグレードすることです。ユーザーは現在のバージョンの Notes Client を使い続けても、新しい設計のすべての利点を活用できます。他のクライアント機能では、Domino Server リリースの 2 つの Notes リリースを使用する方法もありますが、新しい会議室予約システムは Notes Client のバージョンに依存しない設計になっています。

会議室予約の新しい設計では、すべての予約要求の処理と、正常な動作に必要なすべてのものを一元化します。これを達成するために、私たちは Rooms and Resource Manager (RnRMgr) と呼ばれる新しい Domino タスクを作成しました。図 2 は、Domino 7 での会議室予約の設計の概念図です。

図 2. Domino 7 の会議室予約システム
Domino 7 の会議室予約システム
Domino 7 の会議室予約システム

すべての要求処理のロジック/権限を RnRMgr に一元化するとともに、SchedMgr タスクと Router タスクを更新しました。SchedMgr タスクは会議室とリソースの空き時間情報を更新しなくなりました。現在は、ユーザーの空き時間情報のみ更新します。Router タスクに関しては、カレンダーとスケジュールのユーザーへの要求だけはこれまでどおり自動処理しますが、Router タスクが使用する自動処理ルーチンは、会議室予約に関する要求を処理しなくなりました。

RnRMgr タスクの役割は、会議室予約データベース内の予約要求を監視し、受信または作成された順番にこれらを処理することです。この処理の一環として、RnRMgr は空き時間の検索と更新を行い、空き時間を最新の状態に保ちます。このため、競合する要求が連続して届いた場合でも、予約の重複は発生しません。予約要求を承認するか拒否するかの判断は、複数の場所ではなく、単一の場所で行われるため、競合する要求が受け入れられて会議室やリソースの予約が重複する可能性が排除されます。

予約要求のロジックを一元化するために、予約を受け付けるすべてのロジックを会議室予約テンプレートから削除しました。ただし、会議室予約データベースがさまざまなチェック (所有者の制限のチェック、RnRMgr によって拒否された要求の禁止など) を実行できるように、一部のオリジナルロジックは残されています。また、空き時間情報もチェックされるので、ユーザーは、新しい予約を予約済みの日時で保存することはできません (データベースの要求に従って、予約済みの会議室への新規予約を何度も保存することほど面倒なことはありません)。

会議室予約データベースの機能強化

Notes/Domino 7 では、会議室予約データベースの実行内容は前のリリースとほとんど同じですが、小さな変更が加えられています。前のリリースでは、予約要求を保存できた場合は、予約が受け入れられて会議室が利用可能になる、とみなすことができました。現在では、予約要求の最終的な決定は RnRMgr によって行われるため、予約要求を保存できる場合は、予約が受け入れられる可能性が高いことを意味します。しかし、別のユーザーがあなたよりも先に待っていて、予約が受け入れられないこともあります。システムの整合性を確保し、ユーザーの信頼性を高めるために、会議室予約の動作にこの小さな変更が必要でした。

Notes/Domino 7 での会議室予約のインターフェースで最も目立つ変更点は、予約要求の状態を示す新しいアイコンが追加されたことです。これらのアイコンの目的は、予約要求の状態を視覚的に示すことです。新しいアイコンには、次のものがあります。

  • 砂時計: 未処理の予約要求を示します。
  • 緑色のチェックマーク: 承認された予約要求を示します。
  • 赤い×印: 拒否された予約要求を示します。

図 3 からもわかるように、ビューに表示されたどの予約にも、いずれかのアイコンが付けられます。

図 3. 予約状況を示すアイコン
予約状況を示すアイコン
予約状況を示すアイコン

一般的に、RnRMgr が実行されていない場合を除き、砂時計アイコンが表示されることはほとんどありません(表示されたとしても、数秒程度で消えます)。図 3 の [リソース別] ビューには、承認された予約が 2件、(他のユーザーとの競合のために) 拒否された予約が 1件、保留中の予約要求が 1件あります。会議室予約データベースでは、他の予約が既に存在するために拒否されるとみなされる予約要求は作成できません。このため、一度に多くの赤い×アイコンが表示されることはありません。通常、これらのアイコンは表示されませんが、競合する要求が同時に作成または送信された結果として表示されることがあります

この他にも、Notes/Domino 7 の会議室予約テンプレートには、Notes ユーザーの生産性を高め、役に立つ次のような新機能が追加されています。

  • 迅速な予約 (クイック予約)
  • どれぐらい先までの予約を作成できるかを制限する機能
  • 他のユーザーへの予約の転送
  • 予約の所有者への定期的な自動確認の送信

これらの機能、および Notes/Domino 7 会議室予約の他の新機能の詳細については、今後の記事で解説することにします。

クラスタ対応設計

これまで、会議室予約の新しい設計と重複を防止する方法について説明してきました。これは、Notes/Domino 7 での私たちの第 1 の目標です。では、2 番目の目標である、会議室予約の可用性の向上について説明します。Domino Server のアップタイムはたいへん優れていますが、計画的または予期せぬダウンタイムが長引く可能性もあります。これらは、ユーザーの不満と不安につながります。これを解決するために、RnRMgr は Domino クラスタを利用できるように設計されています。このため、会議室予約のレプリカが 1 つに制限されている場合でも、図 4 に示すように、会議室予約データベースの複数のレプリカを配置できます。

図 4. 会議室予約データベースの複数のレプリカ
図 4. 会議室予約データベースの複数のレプリカ
図 4. 会議室予約データベースの複数のレプリカ

会議室予約データベースのレプリカコピーが可能になっただけでなく、RnRMgr は積極的に Domino クラスタを使用して、会議室予約要求処理のアプリケーションフェイルオーバーを実行するよう設計されています。つまり、RnRMgr を実行中の 1つのサーバーが一定の期間利用不可能になったとき、クラスタ内の他のサーバー上の RnRMgr が制御を握り、これらのサーバー間で共有されたすべての会議室予約データベースで保留されている会議室予約要求の処理を試みます。

Notes/Domino 7 では、会議室予約データベースの「1次」サーバーという概念が追加されました。1次サーバーは、要求の処理が通常行われる場所です。これは、Domino ディレクトリの会議室のホームサーバーと同じで、カレンダーとスケジュールの要求が通常ルーティングおよび配信される場所でもあります。レプリカを持つ他のすべてのサーバーは、「2次」サーバーです。2次サーバー上では RnRMgr が実行されていますが、これは会議室予約データベースのどの要求も処理しません。このサーバーは単に 1次サーバーを監視しているだけです。1次サーバーが長時間応答せず、「オフライン」とみなされた場合は、2次サーバーが、1次サーバー上の会議室予約データベースで未処理となっている予約要求の処理を開始します。これは、2次サーバーが「代替 1次」サーバーになったことを意味します。1次サーバーが再起動すると、動作を開始する前に、会議室予約データベースのフェイルオーバーステータスをチェックします。代替 1次サーバーがあるときは、1次サーバーは会議室予約データベースに対して何もしません。このデータベースの代替 1次サーバーがないときは、1次サーバーが通常どおりに予約要求の処理を開始します。

この新しいクラスタ対応設計によって、ユーザーは 2次サーバー上のレプリカで予約要求を作成できます。これは、1次サーバー上またはカレンダーとスケジュール経由で作成された場合と同様の信頼性をもって処理されます。通常、この要求は 1次サーバーへクラスタ複製されて RnRMgr による処理を受けます。そして、クラスタ複製によってその結果が 2次サーバーに戻されます。アプリケーションフェイルオーバーが行われている場合、任意のソースからの未処理の要求は、代替 1次サーバー上で処理されます。このようなケースでは、ユーザーによって作成された要求は単にローカルで処理され、以前よりも結果を少し早く得られます。

代替 1次サーバーがダウンすると、このアプリケーションフェイルオーバーが再び発生します。フェイルオーバーが発生すると、別の 2次サーバーが新たな代替 1次サーバーとして選択され、以前と同様に要求の処理が続行されます。Notes/Domino 7 では、1次サーバーにクラスタ環境での優先度が与えられているために、フェイルオーバーが一度発生した後、1次サーバーが再起動されても、代替 1次サーバー (2次サーバー) が、応答不能になるまで予約要求の処理を続行します。代替 1次サーバーが応答不能になった場合は、他の 2次サーバーではなく、元の 1次サーバーに制御が渡されます。

まとめ

Notes/Domino の会議室予約は、単一レプリカで複数による意志決定を行う設計から、意志決定を一元化し、クラスタフェイルオーバー機能を備えた可用性の高い設計へと進化しました。カレンダーとスケジュールシステムには変更を加えず、ユーザーエクスペリエンスの変更を最小限にとどめながら、会議室予約システムは再設計され、会議室予約に対するユーザーの信頼性を高めるとともに、Domino クラスタ機能を利用するようになりました。再設計だけでなく、会議室予約データベースに追加された新機能も、ユーザーに歓迎されるでしょう。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=337919
ArticleTitle=Lotus Notes/Domino 7 の会議室予約の設計
publish-date=08302005