©  2014  Zimbra  JAPAN  LLC.   1   www.zimbra.com/jp  

Zimbra  Collaboration  Server  アーキテクチャ概要  

 

目次  はじめに  ·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙     2  

Zimbra  Collaboration  Server  の設計思想  ·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙     2  

・かしこい検索でメール整理も手間いらず  

・いつものメールに業務ツールを集約して業務効率アップ  

・モバイルファースト  

・ユーザが一番使い安いクライアントからメールボックスにアクセス  

・オールインワンソリューション  

・アーカイブとコンプライアンス対策  

・管理しやすいメールサービスのための機能  

・アーカイブとコンプライアンス対策  

・エコなストレージマネージメント  

・オープンソースのチカラを利用する    

クライアント側アーキテクチャ  ·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙     4  

・Zimbra  Ajax  クライアント  

・Zimbra  Touch  クライアント  

・クライアント/サーバ間通信  

・外部サービスとの連携と   Zimlet  

サーバ側アーキテクチャ  ·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙·∙     6  

・メッセージストア  

・ファイル容量の節約  

・Linux/Unix  ファイルシステムのサポート  

・クラウドストレージのサポート    

・メタデータ   DB  

・Lucene  で作る検索用インデクス  

・添付ファイルの検索のための仕組み  

・アプリケーションジャーナリング   (redo  log)  

・スケーラビリティ  

 

 

 ©  2014  Zimbra  JAPAN  LLC.   2   www.zimbra.com/jp  

はじめに  本誌では、Zimbra  Collaboration  Server  の特徴を取り上げながら、各機能においてどのようなテクノロジーを用いているかを述べます。  

Zimbra  Collaboration  Serverの設計思想     Zimbra  Collaboration  Serverの開発を開始した   2003  年から Zimbra  は以下の点を設計思想として、Web  ベースのメッセージングソリューションを目指しています:  

• 強力な検索ができること  

• 外部サービスと組み合わせやすい構造であること  

• いつでもどこからでもメールボックスにアクセス出来るプラットフォームを提供できること  

• 管理者に優しいシステムであること  

• ディスクなど各種リソースを経済的に利用すること  

• オープンソースの力を利用して、より安全なソフトウエアにすること  

かしこい検索でメール整理も手間いらず   強力な検索エンジンは、メールのような日々溜まっていく大量のデータを管理する方法を再定義します。メッセージ・連絡先・カレンダーの予定・ドキュメントなどすべてのデータをあらかじめ自動的にインデクス化することで、検索結果を高速に得られます。また、検索対象として、文言だけではなく、様々な構造化されたメタデータ   (送信者・アドレスのローカルパートやドメイン・送受信日時等)  を検索出来るようにすることによって、よりピンポイントの検索結果を得られます。そして、それらの検索キーワードそのものを保存しておくことによって、常に最新の検索結果が含まれる   “仮想フォルダ”  を持つことが出来ます。  

いつものメールに業務ツールを集約して業務効率アップ   ビジネスアプリや外部のサービスが   SaaS  ベースで   Web  API  を公開することが一般的になってきた今日、XML,  SOAP,  REST  プロトコルを用いて相互にデータを交換する手段を提供します。それによって、Zimbra  クライアント上にメールの内容と関連する地図や予定を、アプリケーションを切り替えることなく直接表示することが可能です。  

また、コラボレーションを目的としたプロトコルを用いて、リアルタイムで外部のサービスと同期することも出来ます。たとえば   RSS  を購読し、ニュース情報を読んだり検索できますし、CalDav  プロトコルを利用して外部のカレンダーの予定情報を取り込んだり出来ます。また、ユニファイドメッセージング機能を使って、VoIP  情報や、プレゼンス情報を取り込むことも出来ます。  

モバイルファースト   コミュニケーションツールは益々スマートフォンやタブレットなど手元に持ち運べるデバイスにシフトしていきます。Zimbra  Collaboration  Serverのインタフェースもモバイル向けの   UX  を優先して考えて行きます。  

 ©  2014  Zimbra  JAPAN  LLC.   3   www.zimbra.com/jp  

ユーザが一番使い易いクライアントからメールボックスにアクセス     ユーザには、どんなクライアントを使うかを決める権利を持っています。たとえ   Web   メールが「いつでもどこでも安心してアクセス可能」であっても、ひいきのメールクライアントを使い続ける理由は人それぞれあるでしょう。Zimbra  Collaboration  Serverではそのようなユーザのために、POP、IMAP、Outlook、Exchange   ActiveSync  など既存のメールプロトコルでのアクセス手段も提供します。  

管理しやすいメールサービスのための機能   新機能を追加する場合、メンテナンスでシステムを止める場合、あるいは万が一障害が起こった場合でも、エンドユーザへのサービス停止時間を出来る限り減らしつつ、管理者の作業をアプリケーションが自動化して運用を支援します。1。  

エコなストレージマネージメント   メールの性質上、メールの新鮮度と読まれる頻度は反比例します。そこで、高頻度でアクセスされる新しいメールは高速のディスクに、それ以外の古くて読まれる頻度の低いメールは大容量だが低速のディスクに振分けて格納する手段を提供します。どのディスクに入っているかはサーバ側で管理するので、ユーザとしては古いメールへのアクセスが若干遅くなるという事はありますが、それ以外でメールがどこに格納されているかを気にする必要はありません。  

オープンソースのチカラを利用する   Zimbra  のメールサーバは、オープンソースプロジェクトとして、ソースコードを公開しています2。すなわち、Zimbra社の開発者でなくても、メールサーバ内の処理で何を行っているか、Java  のソースコードを読むことで、自分の目で確かめることが出来ます。  

Zimbra  は Linux  (OS)、Jetty  (Web  サーバ/Javaサーブレットコンテナ)、MariaDB  

/MySQL  (メタデータ DB)、Apache  Lucene  (検索インデクシング)、OpenLDAP  (認証ディレクトリ/設定)  等、様々なオープンソースプロダクトを、Zimbra  

Collaboration  Server  のベースあるいはサブコンポーネントとして使用しています。オープンソース技術を使うことによって、より多くの開発者とユーザのちからを借りることができるため、製品の安全性を高め、機能・性能・先進性がさらに良くなっていくと確信しています。  

 

1   Always  On  機能:  バージョン 8.5 から段階的に機能の開発を進めています。  2   Zimbra  Collaboration  Server  はオープンソース版と商用版   (“ネットワークエディション”)  についての違いは  http://www.zimbra.com/products/zimbra-­‐collaboration/compare-­‐products.htmlを参照して下さい。  

 ©  2014  Zimbra  JAPAN  LLC.   4   www.zimbra.com/jp  

クライアント側アーキテクチャ    

図 1  クライアント側アーキテクチャ  

Zimbra  Ajax  クライアント   UX  の基本ポリシーは、 PC  やスマートフォン・タブレットにインストールして使うメールクライアントと遜色ない使い勝手を提供することです。エンドユーザは OutlookやApple  Mail、iOS や Android のメールクライアントと同様の操作感をブラウザ上で体験することができます。 それに加えて、他のサービスの機能やデータを取り込める様な仕組みが用意されています。  

Zimbra  Ajax  クライアントは、JavaScriptで書かれた HTML53  対応の   UX  コードと、CSS  

から成ります。コードはオブジェクト指向プログラミングスタイルで   MVC  モデルにもとづいて設計され、イベントが発生して状態が変わると   UI  の再描画と、サーバとの非同期通信が発生します。Zimbra  Ajax  クライアントで使われるユーザの状態は基本的にはサーバ側で保持されます。  

Zimbraの   UI  を支える JavaScript  コードは   40万行を超しますが、実際にブラウザに読み込まれるときには、圧縮軽量化されてもっと小さくなり、ブラウザ上でキャッシュされます4。  

Zimbra  Touch  クライアント   レスポンシブデザインを採用した   Zimbra  Touchクライアントは、Sencha  

Touch  フレームワークを利用しています。Zimba  Touch  クライアントでは、メール、連絡先、カレンダーの予約の閲覧と新規作成が可能です。  

クライアント/サーバ間通信   クライアントと Zimbra  サーバ間の通信には   XML/SOAP  バインディングを使うことが出来ます。Ajax  クライアント及び   Touch  クライアントは、JavaScript  

で書かれているため、サーバとの通信も   JavaScript  オブジェクトのほうが、パフォーマンスが上がるため、JSON  バインディングを使用しています。    

図 1  に示すように、Webメールクライアントと Zimbra  Collaboration  Server  サーバの通信に使われるプロトコルに加えて、一般的によく使われるメールプロトコル、メッセージオブジェクトなどの同期プロトコルをサポートしています。  

• Outlook  (MAPI)  –サーバ側のプラグインを使うことに依って、Windows  

OS  上で稼働する Outlook  と直接接続させることが出来ます。  

• EWS  (Exchange  Web  Service)  –  Zimbra  Collaboration  Server  8.5  リリース  

3   HTML5の主たる機能   (例えばオフライン機能等)  を活用したクライアントは   8.5  リリース   (2014年末予定)  から対応。  4   2007年までは   Zimbra  Ajax  クライアントのコードの約 1/3  を   Kabuki  Ajax  Toolkit  を使っていましたが、現在サポートされているバージョンは独自   JavaScript  ライブラリを使っています。  

 ©  2014  Zimbra  JAPAN  LLC.   5   www.zimbra.com/jp  

(2014年末予定)  から、ネイティブな   EWS  をサポートします。これによって   Mac  OS  上で稼働する   Outlook  及び   Apple  Mail  と直接接続させる事ができます。プラグインは不要です。  

• EAS  (Exchange  ActiveSync)  –  iOS  や   Android  の   Mail  アプリから、メール・カレンダー・連絡先・タスク   (ToDo  リスト)の同期をとることが出来ます。  

• POP3/IMAP4  –  SSL/TLS  あるいはクリアテキスト通信でのコマンドのやりとりをサポートします。IMAP4  については主たる拡張機能も実装しています。  

• CalDav  –  カレンダー及び   ToDo  リストなどを同期します。  

• RSS,  REST,  SOAP  –  Zimbra  サーバに対して外部サービスからアクセスし、メールボックスを操作する事ができます。  

外部サービスとの連携と   Zimlet   Zimlet  とは、Zimbra  Ajax  クライアント側の   UX  を含む機能と、サーバ側の機能を拡張するためのウィジットアーキテクチャです。Zimlet  アーキテクチャは、インターネット上あるいは企業内の   ITシステムに格納されている様々なデータソースを、あたかも   Zimbra  Collaboration  Server  サーバに格納されているデータであるかのように取り扱える形に変換し、メールや連絡先、カレンダーの予定情報と一緒に   Zimbra  Ajax  クライアント上に表示させる事ができます。  

Zimlet  のアーキテクチャは、クライアント側とサーバ側で使えるフレームワークと、サーバ側のウェブサービス、クライアント側の UXなどに使えるJavaScript  API  から構成されています。1つの Zimlet  パッケージには、Zimlet  の設定   XML、クライアント側に読み込まれる   JavaScript  及び   CSS  やメッセージカタログファイル、サーバ側で実行される   Java  (JPS)  が含まれます。  

サーバ側の仕組みとして、サーバへの   Zimlet  モジュールのインストール、Zimlet  の設定、ユーザ単位あるいは役割   (CoS)  単位での使用許可/不許可、アンインストール  を備えています。クライアント側の   Zimlet  フレームワークは、主にクライアントの   UX  の拡張を行うために便利なコンポーネントをサポートしています。例えばコンテキストメニューや、ダイアログウインドウ、タブといったウィジェットパーツや、ドラッグ＆ドロップといった動きを、デフォルトの UIと同じ見栄えで表示させたり、外部サービスから取得したデータをクライアント上に表示させたりすることが出来ます。  

そもそも   Zimlet  のアーキテクチャの設計思想としては、Zimbra  Ajax  クライアント上で、UX  や機能を拡張したい場合に、あらかじめ用意された JavaScript  

API  を組み合わせるだけで出来ることを目指しています。さらに、クライアント側だけでなく、サーバ側にも拡張が必要な場合であっても、Java  でその機能拡張の部分を書き足すだけで機能が使えるような仕組みを用意しています。拡張部分を Zimbra  本体から疎結合にすることで、バージョンアップ時に   Zimbra  

Ajax  クライアント部分が書き換わっても、基本的には拡張機能部分はそのまま使えます   (スキンのレイアウト等が大幅に変わったりして、元々   Zimlet  が前提にしていたパーツやコンテキストメニューが無くなったり場所が変わった場合には、その限りではありません)。  

 ©  2014  Zimbra  JAPAN  LLC.   6   www.zimbra.com/jp  

サーバ側アーキテクチャ  サーバ側のプログラミング言語として   Java  を採用しています。図 2  の灰色で示された部分が   Zimbra   Collaboration   Server  のアプリケーション及びコンポーネントです。Java  Servlet  コンテナとして   Jetty  を採用しています。図 2  の青色部分は、拡張機能として、デフォルトコンポーネントと差し替えたり、併用して使用することが出来るコンポーネントです。  

図 2   サーバ側アーキテクチャ  

 

メッセージストア  

Zimbra  のメッセージ   (あるいは blob   (ブロブ)  ファイル)は、1 メッセージ毎に 1 ファイルの形式で管理します。書き込み先のファイルシステムは、標準の   Unix/Linux  ファイルシステムの他に、独自のインタフェースを持った外部ファイルサービスも使用可能です。ブロブファイルは添付ファイルを含めて、RFC822  MIME  形式で保存されます。  

• メールメッセージの性質上、受け取ったメールは変更されることが無いため、ブロブファイルも 1回ファイルシステムに書かれたら、上書き変更されることは有りません。  

• メールが消去された場合、ブロブファイルも消されます。ディスクの容量に余裕があるうちは、実際にファイルシステムから消されるタイミングは、メールが消されたタイミングよりずっと後になる可能性があります。  

• Zimbra  はアプリケーションレベルでのブロブファイルの管理   (ブロブの作成・削除)  を行い、それより下のレベルのファイル管理はすべてOS  に任せます。例えば、ファイルのインデクス化、圧縮、暗号化、といった機能や、ディスクの読み書き性能を向上させるキャッシュなどについては   Zimbra  は特に制御しません。  

ファイル容量の節約   複数のユーザに対してメールが配送された場合、それぞれの Zimbra  メールボックスサーバ5毎に、添付ファイルを含むメール全体のブロブファイルをファイルシステムに書き込みます。この時、サーバ側の設定によって、1ブロブファイルを複数のユーザのブロブファイルとして使う事ができます。例えば、或るメールボックスサーバに格納されている全ユーザに同一のメールを送った場合、1ブロブファイルを格納して、それを全ユーザで共有するか、全ユーザ数分のブロブファイルを格納するかを設定で選ぶことが出来ます。ブロブファイルを共有した場合、誰か 1人がメッセージを消しても他のユーザには影響せず、共有している全ユーザがそのメッセージを消去するまで、ブロブファイルは消されません。  

5   2007年までは   Zimbra  Ajax  クライアントのコードの約 1/3  で   Kabuki  Ajax  Toolkit  を使っていましたが、現在サポートされているバージョンは独自   JavaScript  ライブラリを使っています。  

 ©  2014  Zimbra  JAPAN  LLC.   7   www.zimbra.com/jp  

クラウドストレージのサポート   ブロブファイルアクセス部分は Javaクラス6  を拡張することが出来るような仕組みになっており、標準の Linux/Unix ファイルシステムの代わりに、例えば分散ファイルシステムや、外部のストレージサービスにブロブファイルを格納することも可能です。  

メタデータ DB   メールメッセージの内容自体は、サーバ側で一旦受け取ったらそれ以降変更されませんが、メールに関連する属性情報   (メタデータ)  は、メールの状態が変わるたびに変更されます。例えば:  

• 格納されているフォルダ  

• 未読・既読状態  

• タグやフラグの状態  

• どのスレッドに属しているか、などなど  

Zimbra  Collaboration  Server  は、メタデータ操作処理のパフォーマンスやメンテナンスのしやすさを考慮して、リレーショナル DB  の   MySQL  をメタデータ格納先として採用してきました。バージョン   8.5からは、MySQL  で作成した   DB  

ファイルをそのまま変換しなくても使える   MariaDB  に移行します。  

バージョン   8.0  台までの   DB  は、メールサーバ毎作成されるいくつかのテーブルと、ユーザをグループ7に分けてグループごとに作成されるテーブルを持ちます。  

Luceneで作る検索用インデクス     Zimbra  Collaboration  Server  の大きな特徴として、強力な検索機能があります。メール本文や件名に含まれる文字データ、添付ファイルの内容、アドレス、メタデータとして管理されている属性情報   –  例えばフォルダ、既読・未読、タグ、受信日時等   –  などすべてが検索対象として検索出来ます。  

Lucene  は Apacheプロジェクトで開発された全文検索エンジンです。インデクス対象となるドキュメント   –  すなわちメール文言及び添付ファイルの内容8    

–  を bi-­‐gram  で形態素解析を行い   9、分解されたワード/トークンから  

“segment”  と呼ばれる小さなインデクスの塊を生成します。”segment”  は各ユーザ   (メールを受信したユーザ)  のインデクスファイルにマージされて、ユーザごとのインデクスが出来上がります。  

検索時には、そのインデクスファイルの中からキーワードを持つドキュメント   (メール等)  のポインタを取得します。インデクスの作成は、バッチで行われます。バッチが動くタイミングは設定によって変えることが出来ます。  

何らかの理由によって、インデクスの再構成が必要な場合には、外部管理ツールから強制的再構成を行うことが出来ます。  

Zimbra  Collaboration  Server  の検索の実行は、インデクスを使っているため高速に行えますが、インデクスの作成  時間は個々のメールや添付ファイルのサイズに線形に依存します。  

添付ファイルの検索のための仕組み    商用版   (ネットワークエディション)  を使っている環境下で、管理者が管理する

6   com.zimbra.cs.store.StoreManager  を継承したクラスを作成し、ローカルコンフィグ zimbra_class_storeにクラスを指定。  7  グループ数は 100個。  8  添付ファイルの内容をインデクス化する機能は商用版   (ネットワークエディション)  のみサポートされています。  9   StandardAnalyzer  と   CJKAnalyzer  のハイブリット   Analyzer  を実装   (com.zimbra.cs.index.analysis.UniversalAnalyzerを参照のこと)  

 ©  2014  Zimbra  JAPAN  LLC.   8   www.zimbra.com/jp  

ユーザの設定   (Class  Of  Service:  CoS)  によって、使用可能・不可能を制御することが出来ます。添付ファイルの内容までインデクスを張る場合、添付ファイルを内部的に   Lucene  の構文解析器にかけられる形式に変換してからインデクス化を行いますので、サーバ側の負荷が上がります。添付ファイルの形式の変換は、”convertd”  という名前の HTTP  サービスにて、HP  KeyViewを使用して行います。また、convertd  サービスは、Zimbra  Ajax  クライアント側で添付ファイルをブラウザ上でプレビューする際に、HTML  形式に変換する処理も行います。  

アプリケーションジャーナリング   (redo  log)   Zimbra  のジャーナリングは、DB  のトランザクションログの様な役割を持ちサーバがダウンした場合でも、データのロストを防ぎます。ジャーナルファイルは、サーバクラッシュの直近のトランザクションを再現する用途と、リカバリ時にバックアップ時点以降のトランザクションを巻き取る用途に使われます。   ジャーナルデータはメールボックスに対するすべての操作を記録しているフラットファイルです。サイズが一定サイズを超えると、新しいジャーナルファイルが作成され、古いファイルはアーカイブフォルダに格納されます。  

メタデータ DB  のエントリの更新がコミットされた後に、ジャーナルファイルがコミットされます。万一サーバが落ちた場合には、サーバ再起動時に、コミットされていないジャーナルファイルがあるか確認し、未コミットのトランザクションに関しては、ジャーナルファイルを再読み込みします。  

図 3 各ユーザのメールボックスは、特定のメールボックスサーバにて

管理されていて、プロキシ経由で目的のサーバへのルーティングが行

われます

 

スケーラビリティ  

Zimbra   は本質的にステートフルなアーキテクチャです。個々のメールボックスは特定のメールボックスサーバに紐付いています。複数のメールボックスサーバで構成されるシステムでは、担当メールボックスサーバに正しくルーティングさせるために、前段にプロキシを置きます(図 3)。  

ユーザ数の増減があったり、トラフィック量が変化した場合、システム管理者はメールボックスサーバを追加で用意し、ユーザの配分を調整することで、システム全体の負荷をコントロールします。  

バージョン   8.5   以降で順次、Zimbra   をステートレスなアーキテクチャに変える予定です。