test

Sun Java System Communications Services 6 2005Q4 配備計画ガイド

第 5 章 Communications Services 論理アーキテクチャーの開発

この章では、Communications Services 論理アーキテクチャーを開発する方法について説明します。論理アーキテクチャーとは、Communications Services コンポーネントとそれらをサポートするために必要なインフラストラクチャーサービスの論理構築ブロックを記述した設計のことです。

この章には、次の節があります。

Communications Services 配備の論理アーキテクチャーの概要

Communications Services を単一層または 2 層論理アーキテクチャーのいずれかに配備することができます。論理アーキテクチャーの特定は、必要なマシンのタイプと台数を左右するため、非常に重要です。

通常、一般企業への配備では単一層アーキテクチャーが使用され、インターネットサービスプロバイダ (ISP) や電気通信会社への配備では 2 層アーキテクチャーが使用されます。ただし、一般的な場合と同じように例外が存在します。小規模な ISP が単一のマシンに配備することがあり、大規模な中央集中型の企業が、多くの場合 ISP が配備するのと同じ理由で 2 層アーキテクチャーに配備することもあります。遠隔地で働く社員のアクセスを容易にする企業が増えるほど、企業の配備も ISP と同様のものになっていきます。

この節では、次の Communications Services 論理アーキテクチャーについて説明します。

Communications Services を単一層アーキテクチャーと複数層アーキテクチャーのどちらで配備するかにかかわらず、両方のモデルの長所と短所を理解する必要があります。

単一ホスト用の単一層論理アーキテクチャー

その名前が示すように、単一ホスト用の単一層論理アーキテクチャーは、すべてのサービスを単一のマシンに配置します。通常、このアーキテクチャーは次のような企業に最適です。

次の図は、単一ホスト用の単一層論理アーキテクチャーを示します。

図 5–1 単一ホスト用の単一層アーキテクチャー

この図は、単一ホスト用の単一層論理アーキテクチャーを示します。

Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 1 は、メッセージング、カレンダ、インスタントメッセージング、ディレクトリなどすべてのサービスを実行する単一のマシンです。Communications Express を配備する場合、Web サーバー (またはアプリケーションサーバー) も、この単一マシン上で実行されます。単一層配備の特徴は、エンドユーザーがプロキシやほかのエージェントを介さずに直接ストアと通信することです。

単一ホスト用の単一層論理アーキテクチャーでは、十分な CPU、メモリー、およびストレージを備えるマシンが必要になります。このタイプの配備に対する組織のニーズに最も適合したマシンを決定するには、Sun の販売代理店と共同で作業を行う必要があります。

単一ホスト用の単一層論理アーキテクチャーを実装する場合、サービスに論理名を割り当てることによって複数層アーキテクチャーに拡張できるように配備を構成することができます。この構成は、DNS マッピングを利用して、ユーザーが同一のフロントエンドプロセス (マシン) を使用するように指示します。将来、サービスを Tier (層) 方式に分割するなど、拡大に対応するための変更が必要になった場合、ユーザーはクライアントアプリケーションを再設定する必要がありません。詳細については、「論理サービス名の使用」を参照してください。

複数ホスト用の単一層論理アーキテクチャー

複数ホスト用の単一層論理アーキテクチャーは複数のサーバーから構成され、各サーバーがコンポーネント製品に特定のサービスを実行します。たとえば、Messaging Server ホストはすべての Messaging Server サービスを実行するようにインストールおよび設定され、Calendar Server ホストはすべての Calendar Server サービスを実行するようにインストールおよび設定されます。ほかのホストも同様になります。このアーキテクチャーは高可用性を確保するために設定される場合もあります。

単一層論理アーキテクチャーの特徴は、エンドユーザーがプロキシやほかのエージェントを介さずに直接データストアと通信することです。たとえば、Messaging Server では、ユーザーは MMP または MTA を経由せずにルーティングされます。単一層論理アーキテクチャーは、サーバー間のメールのルーティングまたは企業ネットワークへの出入りにスタンドアロン MTA ルーターを使用する場合がありますが、エンドユーザーはユーザーのメッセージストアの MTA にメールを送信します。MMP はメッセージストアへのイントラネット接続には関与しません。

同じ考え方が Calendar Server と Instant Messaging の両方に当てはまります。単一層論理アーキテクチャーでは、フロントエンドプロセスは別個のマシンには配置されません。

図 5–2 は、複数ホスト用の単一層論理アーキテクチャーを表しています。

図 5–2 複数ホスト用の単一層アーキテクチャー

この図は、複数ホスト用の単一層アーキテクチャーを示します。

この図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 1 は 4 種類のサーバーのセットです。1 番目のサーバーは Calendar Server プロセスを実行し、2 番目は Messaging Server プロセスを実行し、3 番目は Instant Messaging プロセスを実行し、4 番目は Directory Server プロセスを実行します。Communications Express を配備する場合は、Messaging Server のホストに Web メール用の Web サーバー (Web Server または Application Server) も含まれます。

単一層分散論理アーキテクチャー

単一層分散論理アーキテクチャーは、単一層アーキテクチャーの変形で、2 つの層に Directory Server が配備されています。この形式の配備は、地理的に分散した小規模な部門または組織を持つ企業に適しています。各部門またはオフイスは、独自のサービス (メール、カレンダ、インスタントメッセージング) とローカルディレクトリインスタンス (コンシューマ) を持ちます。すべてのローカルディレクトリインスタンスがキャッシュされますが、集中化された企業マスターリポジトリとは同期します。この配備は、低帯域幅の接続を使用するオフイスでは一般的なシナリオです。ディレクトリは 2 層形式で設計され、データをローカルに保持するために低帯域幅を経由して複製されます。

図 5–3 は、単一層分散論理アーキテクチャーを表しています。

図 5–3 単一層分散アーキテクチャー

この図は、単一層分散論理アーキテクチャーを示します。

この図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。層 0 は、層 1 を通じて負荷を分散するロードバランサを構成します。層 1 は、Communications Services プロセスの複数サーバーのセットです。複数のサーバーが Calendar Server サービスを実行し、複数のサーバーが Messaging Server サービスを実行し、複数のサーバーが Instant Messaging サービスを実行します。Directory Server は、ローカルの複製されたディレクトリのコピーを実行する層 1 のコンシューマサーバーとディレクトリのマスターコピーを持つ層 2 のもう 1 つのサーバーに分割されます。この配備形式では、クライアントの照会はマスターコピーではなく、ローカルのディレクトリコピーに送信されることに注意してください。ローカル Directory Server だけが、マスター Directory Server と通信します。

注 –

インターネット接続を使用する単一層アーキテクチャーを配備する場合は、別のアクセス層を使用します。たとえば、SSL を使用せずにイントラネット内部からデータストアにアクセスするように指示します。ただし、インターネットからデータストアにアクセスする場合は、SSL を介するアクセス層を経由するように指示します。これにより、インターネットから分離されたアクセス層に、データストアの SSL 負荷の大部分がオフロードされます。

この形式の配備の欠点は、企業のイントラネット上のサーバーを利用したり、インターネットからサーバーにアクセスしたりするユーザーが常時 SSL を使用するようにクライアントアプリケーションを設定する必要があることです。これは、SSL の有効、無効を切り替える手間が非常にかかるためです。このため、かなりの割合の SSL トラフィックがストアに直接接続されることになります。イントラネット内部のアクセス層を利用することによって、この問題を解消し、接続の方向を制限することによって、不正なアクセスからイントラネットを保護することができます。

2 層論理アーキテクチャー

2 層論理アーキテクチャーでは、データストアはフロントエンドプロセスを経由して通信します。つまり、Messaging Server の場合、MMP、MEM、および MTA がデータストアプロセスとは別のマシンに配置されることを意味します。2 層アーキテクチャーを使えば、メールストアは重要な共通タスクの負荷が軽減され、メールの受信と配信に集中することができます。Calendar Server の場合、HTTP サービスと管理サービスがストアプロセスと別のマシンに配置されることを意味します。Instant Messaging の場合、プロキシサービスがバックエンドプロセスと別のマシンに配置されることを意味します。

いくつかのレベルで、ほかのサーバーとの共存が可能です。たとえば、同一のマシンにカレンダストアとメッセージストアを配置することができます。同様に、MMP マシンにカレンダのフロントエンドを配置することができます。

2 層論理アーキテクチャーでは、Directory Server は通常、負荷分散された一連のコンシューマディレクトリに対するマルチマスターとレプリケーションを持つため、それ自体が複雑な配備となります。

図 5–4 は、2 層論理アーキテクチャーを表しています。

図 5–4 2 層アーキテクチャー

この図は、2 層論理アーキテクチャーを示します。

上図では、Outlook、Messenger Express などのエンドユーザークライアントプログラムがユーザー層を形成します。ロードバランサが層 0 を形成します。Calendar Server、Messaging Server、Instant Messaging、Web プロキシ/MEM のフロントエンドが層 1 を形成します。最後に、Directory Server、Calendar Server、Messaging Server、Instant Messaging のバックエンドが層 2 を形成します。Communications Express を配備する場合は、Web サーバーも層 2 に配置できます。

2 層アーキテクチャーでは、層 1 と層 2 の要素を独立したインスタンスとして配備できるため、設計全体の柔軟性が高まります。さらに、個々のインスタンスに別々の機能を割り当てることにより、システムのセキュリティーを強化することができます。

通常の配備では、メッセージングとカレンダフロントエンドをネットワークの非武装地帯 (DMZ) に配置し、ファイアウォールを経由してメインのメッセージングとカレンダサービスに接続します。この構成により、層 1 の要素を個々にスケーリングすることができるため、システムの水平方向のスケーリングが可能になります。これらの要素に、バックエンドサーバーの容量を超えるようなスケーリングはしないでください。

フロントエンドの要素がバックエンドサーバーの容量に到達した場合、バックエンドの層 2 の要素を拡大して、より多くのユーザーをサポートすることができます。通常、フロントエンドはトラフィックの関数としてスケーリングします。バックエンドはユーザー数の関数としてスケーリングされます。

注 –

単一層アーキテクチャーおよび 2 層アーキテクチャーにおけるコンポーネントのサイズ決定に関する特別な手順については、クライアントサービス担当者に連絡してください。

エッジ論理アーキテクチャー

エッジ論理アーキテクチャーは 2 層論理アーキテクチャーへのリモートアクセスに対するセキュリティーを向上させます。エッジ配備は、名前およびパスワード認証 (SMTPAuth ) のみを使用することにより、遠隔地のモバイル通信を利用する社員に公衆インターネットを経由するアクセスを許可します。メッセージは、公衆インターネットを介して企業ネットワークと通信されるので、SSL を使用して暗号化されます。仮想私設ネットワークは一切関与しません。通信の内部転送は、最大のパフォーマンスを発揮するために「平文」で行われます。アクセスは、配備の「エッジ」に含まれ、データストアを無許可の侵入から保護します。

エッジを配備するビジネス上の理由は次のとおりです。

図 5–5 は、エッジ論理アーキテクチャーを表しています。

図 5–5 エッジアーキテクチャー

この図は、エッジ論理アーキテクチャーを示します。

この図では、データストアは「エッジ」および「内部」フロントエンドサーバーにのみ接続されるセキュリティー保護された私設ネットワークの層 2 に配置されています。リモートクライアントは SSL を使用してフロントエンドサーバーに接続します。内部アクセスは本質的に安全であるとみなされるので、内部クライアントは SSL を使用して接続する必要はありません。

エッジアーキテクチャー設計の推奨事項

単一層アーキテクチャーの利点

単一層アーキテクチャーを使用する利点は、追加ハードウェアの購入と維持が不要になることによるコストの低減です。

単一層アーキテクチャーがその企業に最適かどうかを決定するには、次の質問に対する回答が役立ちます。

これらの質問に対する回答が「はい」である場合、その企業は単一層アーキテクチャーを使用することを示しています。

2 層アーキテクチャーの利点

Communications Services 製品内のすべてのサービスはネットワーク機能に依存します。2 層アーキテクチャーは、公衆 (ユーザー側) ネットワークと私設 (データセンター側) ネットワークの 2 つの独立したネットワークを持つネットワーク設計を提供します。

ネットワークを 2 層に分離することにより、次の利点が提供されます。

水平方向のスケーラビリティー戦略

スケーラビリティーは、コンピュータ資源を最高の費用効率で利用し、ピーク時の作業負荷を処理し、ビジネスの拡大に対応してすばやくインフラストラクチャーを拡張する必要がある組織に不可欠です。次の点に注意してください。

2 層アーキテクチャーに配備する場合、Communications Services 製品は水平方向に非常に効果的なスケーリングが可能です。各機能要素は、特定の層に増設マシンを追加することにより、増大する負荷をサポートすることができます。

フロントエンドサービスとバックエンドサービスのスケーリング

実際には、フロントエンドサービスとバックエンドサービスのスケーリングは若干異なります。

層 1 の要素の場合、フロントエンドへのトラフィックが現在の容量を超えて増加したときにスケーリングプロセスを開始します。比較的低コストのマシンを追加し、これらのマシン全体の負荷分散を追加します。この結果、ロードバランサにシステムの全体負荷、サービスの分散、およびスケーラビリティー要求の指示をすることにより、層 1 の各サービス機能に優先付けをすることができます。

層 2 の要素の場合、バックエンドサービスがユーザー容量またはデータ容量を超過したときにスケーリングプロセスを開始します。一般的な基準としては、層 1 のサービスの負荷容量のちょうど 2 倍以下に対応できるように層 2 のサービスを設計します。

たとえば、5,000 ユーザー用に設計したアーキテクチャーの場合、層 1 のフロントエンドサービスは 5,000 ユーザーをサポートするように設計されています。バックエンドサービスは、この 2 倍の 10,000 ユーザーに対応できるように設計します。システム容量が 5,000 ユーザーを超えている場合は、フロントエンドサービスを水平方向に拡大することができます。全体容量が 5,000 ユーザーに到達している場合は、バックエンドサービスを対応できるように拡大することができます。このような設計により、ユーザーに関してでも、スループットに関してでも、柔軟に拡大できるようになります。

その他の配備の課題

この節では、いくつかの共通の Communications Services 配備の最良の方法とその他の配備に関する考慮事項について説明します。

Messaging Server に対する LMTP (Local Message Transfer Protocol) の実装

最良の方法は、メッセージ配信のために SMTP の代わりに LMTP を実装することです。LMTP アーキテクチャーがバックエンドメッセージストアへの配信に関して効率性が高い理由は次のとおりです。

LMTP を実装するには 2 層アーキテクチャーが必要です。LMTP の設定手順については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の「LMTP 配信の設定」を参照してください。

Realtime Blackhole List (RBL) の実装

Mail Abuse Protection System の Realtime Blackhole List (MAPS RBL) は、送信元の IP アドレスで識別される、一方的に送られてくる大量電子メール (UBE: Unsolicited bulk email) の既知の送信元の動的な更新リストです。Messaging Server SMTP サーバーは RBL の使用をサポートし、UBE またはスパムとして RBL が識別する送信元からの受信メールを拒否することができます。

すべての配備において RBL の実装を考慮する必要があります。通常、MTA の前に配備された高品質の RBL は、最低でも 10%、場合によってはそれ以上 MTA に対するトラフィックを軽減します。

RBL と BrightMail などのアンチスパムまたはアンチウィルスサーバーは連携して動作することができます。たとえば、アンチスパムサーバーが特定の IP アドレスからの 100 通の電子メールから 95〜99 通のメールを排除した場合、その IP アドレスを RBL に追加することができます。また、BrightMail 分析の実行時に、BrightMail の誤検知によって RBL を調整することができます。この結果、UBE の特定の変動を処理する上で、RBL を一層有効に活用できるようになります。

MTA ディスパッチャーの ENABLE_RBL オプションの設定に関する詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

論理サービス名の使用

Communications Services サーバーの論理名を使用する配備を設計します。将来の拡張や拡大を容易にするために、単一システムの配備においても論理名を使用する必要があります。論理名の使用は、DNS の格納以外に追加の配備設定費用は不要です。

これらの論理名を次の 2 つのカテゴリに分けて考えることができます。1 つは電子メールクライアントプログラムの設定などエンドユーザーに影響を与え、もう 1 つはインバウンド SMTP サーバーなどバックエンドの管理に影響を与えるものです。

次表でこれらの論理名について説明します。

表 5–1 ユーザー側の論理名

例 

説明 

mail.siroe.com

エンドユーザーが電子メールを収集するサーバーの名前 

imap.siroe.com

エンドユーザーが電子メールを収集する IMAP サーバーの名前

pop.siroe.com

エンドユーザーが電子メールを収集する POP サーバーの名前

smtp.siroe.com

送信メールサーバーとしてユーザーが指定する SMTP サーバーの名前 

webcal.siroe.com または ce.siroe.com

Communications Express (以前の Calendar Express) サーバーの名前 

表 5–2 保守レベルの論理名

例 

説明 

relay-in.siroe.com

インバウンド SMTP サーバーのバンクに相当します。 

relay-out.siroe.com

アウトバウンド SMTP サーバーのバンクに相当します。 

mmp.siroe.com

MMP サーバーのバンクに相当します。 

mem.siroe.com

MEM サーバーのバンクに相当します。 

storeAA.siroe.com

バックエンドメッセージストア。たとえば、storeAA.siroe.com〜storeZZ.siroe.com のように、使用するトポロジで動作するネーミング方式を選択します。

calstoreAA.siroe.com

バックエンドカレンダストア。たとえば、calstoreAA.siroe.com〜calstoreZZ.siroe.com のように、使用するトポロジで動作するネーミング方式を選択します。

表 5–3 ユーザーレベルの保守レベル論理名へのマッピング

保守レベル 

ユーザーレベル 

relay-in.siroe.com

なし 

relay-out.siroe.com

smtp.siroe.com

mmp.siroe.com

mmp.siroe.com、pop.siroe.com、imap.siroe.com のうちの 1 つまたは複数の名前

mem.siroe.com

webmail.siroe.com

storeAA.siroe.com〜storeZZ.siroe.com

なし。エンドユーザーには隠されている 

calstore_aa.siroe.com〜calstore_az.siroe.com

なし。エンドユーザーには隠されている