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

2 層メッセージングアーキテクチャーの理解

2 層アーキテクチャーにより、スケーラビリティーと信頼性のために最適化された設計が可能になります。単独のホストでメッセージングシステムのすべてのコンポーネントを実行する代わりに、2 層アーキテクチャーでは、コンポーネントを異なるマシンに分割します。このようなコンポーネントの分割により、特別な専用機能が実行されます。たとえば、追加のメッセージストレージが必要になったり、より多くのアウトバウンドリレーが必要になったりするなど、特定の機能コンポーネントの負荷が増大すると、サーバーを追加して増大する負荷に対応できます。

2 層アーキテクチャーは、「アクセス層」「データ層」で構成されます。アクセス層は、アーキテクチャーの中で、配信、メッセージアクセス、ユーザーログイン、および認証を処理する部分です。データ層は、すべてのデータを維持する部分です。これには、LDAP マスターサーバーと、ユーザーメッセージを格納するよう設定された Messaging Server マシンが含まれます。

図 11–1 は、2 層アーキテクチャーの例を示しています。

図 11–1 2 層 Messaging Server アーキテクチャー

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

次でこれらの機能部分について説明します。

公衆アクセスネットワーク: Messaging Server を内部ユーザーとインターネットに接続するネットワークです。それぞれの配備で独自のネットワーク要件が定義されますが、基本的な Messaging Server の要件は、SMTP、POP、IMAP、および HTTP のような標準のプロトコルを使用したエンドユーザーとインターネットへの接続性です。

私設データネットワーク: このネットワークは、公衆アクセスネットワークと Messaging Server データの間で、セキュリティー保護された接続を提供します。セキュリティー保護されたアクセス層と、サービス全体のディレクトリ、メッセージデータセンター、および個人アドレス帳 (PAB) サーバーが含まれるデータ層で構成されます。

LDAP ディレクトリサーバー: ユーザーベースに関する情報の格納と取得に使用され るディレクトリサーバーです。ユーザーとグループエイリアス、メールホスト情報、配信設定などを格納します。設計の要件次第で、システムの同一ディレクトリを複数格納することも可能です。図 11–1 は、マスターディレクトリと 2 つのレプリカを示します。LDAP ディレクトリサーバーは、Messaging Server 製品の一部として提供されます。必要であれば、既存の Sun Java System Directory Server ディレクトリのデータを使用することも可能です。既存のディレクトリのデータ形式は、Messaging Server スキーマに準拠している必要があります。

メッセージストア: ユーザーメールを保持し、格納します。「バックエンド」と呼ばれることもあります。メッセージストアは、IMAP サーバー、POP サーバー、および Web メール (Messenger Express) サーバーのようなメッセージアクセスコンポーネントを指すこともあります。図 11–1 は、2 つのメッセージストアを持つ配備を示します。必要に応じて、さらにストアを追加することもできます。

個人アドレス帳 (PAB) サーバー: LDAP サーバー内のユーザーのアドレスを保存および取得します。このサーバーは、前述の LDAP サーバーと同一であってもなくてもかまいません。

DNS サーバー: ホスト名を IP アドレスにマップします。DNS サーバーは、メッセージを外部ドメインにルーティングするときに、どのホストに接続するかを判断します。内部的には、DNS は実際のサービスをマシン名にマップします。DNS サーバーは、Messaging Server 製品の一部ではありません。Messaging Server をインストールする前に、稼働状態の DNS サーバーをインストールする必要があります。

ロードバランサ: ネットワーク接続について、均一にバランスを取るか、複数のサーバーにアルゴリズムを適用してバランスを取ります。ロードバランサを使用すると、1 つのネットワークアドレスで多数のサーバーを表すことができるため、トラフィックのボトルネックを解消し、トラフィックフローの管理と高いレベルのサービス保証が可能になります。図 11–1 には、MMP 用、MTA 用、および MEM 用のロードバランサが含まれています。ロードバランサは Java Enterprise System 製品の一部ではありません。ロードバランサをメッセージストアまたはディレクトリマスター上で使用することはできません。ロードバランサは、MMP、MEM、Communications Express、MTA、ディレクトリコンシューマへの接続用として使用したり、Messaging Server の MTA が Brightmail 製品を使用する状況で使用したりします。

MTA インバウンドリレー: 外部 (インターネット) サイトからのメッセージを受信し、それを内部ホストおよびローカルのメッセージストアサーバーにルーティングする専用MTA です。この MTA は外部からの最初のコンタクトポイントとなるため、MTA インバウンドリレーには、権限のないリレーを防ぎ、スパムをフィルタリングし、サービス拒否攻撃に対抗する機能が追加されます。MX レコードを使えば、着信メールトラフィックの負荷を分散できます。詳細については、「MX (メール交換) レコード」を参照してください。

MTA アウトバウンドリレー: 内部または承認されたユーザーからのメールだけを受け取り、それをその他の内部ユーザーまたは外部 (インターネット) ドメインにルーティングする MTA です。単独のマシンをインバウンドリレーとアウトバウンドリレーとして使用できますが、インターネットに接続された大規模な配備では、これらの機能を 2 つの別のマシンに分割します。このようにすると、内部クライアントは、外部サイトからインバウンドするメールと競合することなく、メールを送信できます。

Delegated Administrator サーバー: 管理者に GUI 管理コンソールを提供し、管理者がユーザーの追加や削除など、より高度な管理作業を行えるようにします。

Messaging マルチプレクサ または MMP: ユーザーのメールボックスを含む特定のマシンと、関連付けられた DNS 名との結合を解除して、複数の物理マシンにわたるメッセージストアの拡大縮小を可能にします。クライアントソフトウェアは、メッセージストアのある物理的なマシンを知る必要はありません。このようにすると、ユーザーは、メールボックスが新しいマシンに移動されるたびにホストメッセージストアの名前を変更する必要がなくなります。POP クライアントまたは IMAP クライアントがメールボックスへのアクセスを要求すると、MMP はディレクトリサービスを参照してユーザーのメールボックスがある場所を検索し、そのメールボックスがある Messaging Server システムに要求を転送します。複数の MMP を使用する場合、それらをロードバランサの背後に配置する必要があります。

MEM (Messenger Express マルチプレクサ): Web メール用の HTTP アクセスサービスへの単一の接続ポイントとして機能する特別なサーバーです。すべてのユーザーがこのメッセージングプロキシサーバーに接続し、該当するメールボックスに導かれます。このため、メールユーザーには複数の Messaging Server が単一のホスト名であるかのように表示されます。Messaging Multiplexing Proxy (MMP) は POP および IMAP サーバーに接続しますが、Messenger Express マルチプレクサは HTTP サーバーに接続します。つまり、Messenger Express マルチプレクサと Messenger Express との関係は、MMP と POP や IMAP との関係と同じです。複数の MEM を使用する場合、それらをロードバランサと組み合わせて使用する必要があります。Communications Express 配備の場合、Communications Express ソフトウェアも、MEM を含む同じホストに配備されます。

2 層アーキテクチャー — メッセジングデータフロー

この節では、メッセージングシステム経由のメッセージフローについて説明します。メッセージフローがどのように機能するかは、実際のプロトコルとメッセージパス次第です。

メールの送信: 内部ユーザーから別の内部ユーザーへ

機能説明: 内部ユーザー > ロードバランサ > MTA アウトバウンドリレー 1 または 2 > MTA インバウンドリレー 1 または 2 > メッセージストア 1 または 2


注 –

アウトバウンドリレーからストアにメールを直接配信させるために、LMTP を使用するのが一般的になってきています。2 層配備では、この方法を選択できます。


内部ユーザーから別の内部ユーザー (すなわち同じ電子メールシステムのユーザー) へ宛てられたメッセージは、最初にロードバランサへ送られます。ロードバランサは、電子メールユーザーを基盤となるサイトアーキテクチャーから切り離し、高可用性電子メールサービスを提供します。ロードバランサは、その接続を MTA アウトバウンドリレー 1 または 2 のいずれかに送信します。アウトバウンドリレーはアドレスを読み取り、メッセージが内部ユーザー宛てのものかどうかを判断します。アウトバウンドリレーは、MTA インバウンドリレー 1 または 2 にメッセージを送信するか、設定によっては適切なメッセージストアに直接送信します。MTA インバウンドリレーは、そのメッセージを適切なメッセージストアに配信します。メッセージストアはそのメッセージを受け取り、メールボックスに配信します。

メールの取得: 内部ユーザー

機能説明: 内部ユーザー > ロードバランサ > MMP/MEM/Communications Express Proxy Server 1 または 2 > メッセージストア 1 または 2

メールは POP、HTTP、または IMAP のいずれかを使用して取得されます。ユーザー接続がロードバランサに受信され、MMP サーバー、MEM/Communications Express サーバーのいずれかに転送されます。次にユーザーは、接続したアクセスマシンにログイン要求を送信します。アクセス層のマシンは、ログイン要求とパスワードを検証し、ユーザー接続で指定された同じプロトコルを使用して、適切なメッセージストア (1 または 2) に要求を送信します。そしてアクセス層のマシンは、クライアントとサーバー間の残りの接続を仲介します。

メールの送信: 内部ユーザーから外部 (インターネット) ユーザーへ

機能説明: 内部ユーザー > ロードバランサ > MTA アウトバウンドリレー 1 または 2 > インターネット

内部ユーザーから外部ユーザー (すなわち異なる電子メールシステムのユーザー) へ宛てられたメッセージは、ロードバランサに送られます。ロードバランサは、電子メールユーザーを基盤となるサイトアーキテクチャーから切り離し、高可用性電子メールサービスを提供します。ロードバランサは、そのメッセージを MTA アウトバウンドリレー 1 または 2 のいずれかに送信します。アウトバウンドリレーはアドレスを読み取り、メッセージが外部ユーザー宛てのものかどうかを判断します。アウトバウンドリレーは、インターネット上の MTA にメッセージを送信します。

メールの送信: 外部 (インターネット) ユーザーから内部ユーザーへ

機能説明: 外部ユーザー > MTA インバウンドリレー 1 または 2 > メッセージストア 1 または 2

外部ユーザー (インターネット) から内部ユーザーへ宛てられたメッセージは、MTA インバウンドリレー 1 または 2 へ送られます (ロードバランサは不要)。インバウンドリレーはアドレスを読み取り、メッセージが内部ユーザー宛てのものかどうかを判断します。インバウンドリレーは LDAP 検索を使用して メッセージストア 1 または 2 のいずれに送信するかを判断し、それに従って配信します。メッセージストアはそのメッセージを受け取り、適切なメールボックスに配信します。