Point
1. 約7000人の学生と300人の教職員が利用するメール・システムを再構築
2. ベンダー各社の提案は千差万別。長所短所を徹底比較した
3. 決め手は，無停止移行，障害時の継続運用，アカウント連携のカスタマイズだった
日本大学生産工学部は，在籍する約7000人の学生および教職員300人が利用するメール・システムをリプレースした。同学部のメール・システムは，「学生が就職活動に利用したり，海外の研究者と連絡を取り合ったりするなど日夜を問わずフル稼働している重要なインフラ」（同学部 ITセンター 黒澤達也氏）であるため，これまで以上に冗長性に重きを置いた構成にした。システムのリプレース作業中も，メールの送受信を一切止めずにメール・データを移行する仕組みを用意するなど，工夫を凝らしている。
保守打ち切りで再構築を迫られる
同学部がメール・システムのリプレースに踏み切ったのは，それまで利用していた米Mirapoint製のメール・アプライアンス機「MR200/SP1500」の保守が2004年末に打ち切られることが決まったためである。同システムは2000年に稼働開始してから，それまで大きなシステム障害に見舞われたこともなく，「最低でも5年，できれば6～7年は継続して利用するつもりでいた。保守打ち切りの連絡は寝耳に水だった」（黒澤氏）という。
2004年3月の時点で，どうにか1年先の2005年3月まで保守を継続してもらう約束を取り付けた黒澤氏は，すぐに新メール・システムの計画立案に着手する。手始めに，既存システムの課題を洗い出した。まず浮上したのは，システムの冗長化である（図1右[拡大表示]）。
既存のPOP/SMTPサーバー部分（MR200）は2台構成で運用していた。ただし，それぞれPOPおよびSMTPサーバー用途に分けていたため，障害発生時に処理を自動で引き継ぐ仕組みではなかった。MR200の制御機能およびデータ・ストレージ機能を担う部分（SP1500）についても予算上の都合でコールド・スタンバイ方式になっていた。こちらも切り替え作業に人手を介す必要があったため見直すことにした。
同学部は，米Mirapoint製のアプライアンス機とは別に，蝶理情報システムの「CatchMe@MAIL」をインストールしたWebメール・システムを併用している。そのWebメール・システムも課題を抱えていた。同システムは，2台のサーバーでWebメールのアクセスを負荷分散する構成だったが，保守時などに，片方のサーバーにユーザー・アクセスを集中させる仕組みを備えていなかった。黒澤氏とともにメール・システムの運用を担当する松島正直氏は「せっかく2台構成を敷いているのに，セキュリティ・パッチの適用後にシステムを再起動したくても，ユーザーが全員ログアウトするまで実行できない。アクセスが減る深夜など誰もログオンしていない時間を見計らい，再起動を伴うメンテナンス作業を実施していた」と，振り返る。新システムでは，メンテナンス性の向上も目指すことにした。
メール・データのバックアップ方式も改善の余地があった。データのバックアップには，AIT方式のテープ・ローダーを利用していたが，運用開始から4年以上が経過したことでデータ容量が増大し，夜間に開始するフル・バックアップ作業が翌朝になっても完了しない事態になっていたのだ。
常時稼働する2台のサーバーで冗長化
リプレースを決断してから1年近くも検討を重ね，2005年4月には新メール・システムが稼働した（図2[拡大表示]）。新システムは，先に挙げた課題を解決するため可用性やメンテナンス性を重視した構成になっている。メール・サーバー・ソフトにはディープソフトの「DEEPMail」を採用。同ソフトは，SMTP/POP機能に加え，Webメール機能を兼ね備える。システムの導入はNECが請け負った。
メール・サーバーは，常時2台が稼働して負荷を分散するアクティブ-アクティブ方式のクラスタ構成を敷いた。いずれかのメール・サーバーで障害が発生しても，縮退運転となるが修理対応中も含めサービスを停止しないで済む。アクティブ-アクティブ方式を採用したのは，「ハードの切り替え処理がない分，ホット・スタンバイ方式よりもリスクが少ない」（黒澤氏）と判断したためである。
2台のメール・サーバーに個別のIPアドレスを割り振る構成にしたくなかったことなどから，サーバーへのアクセスはレイヤー4スイッチを経由する仕組みとした。スイッチの制御機能で1台のメール・サーバーに処理を寄せることができるので，日中でもメンテナンスのための計画停止が可能となった。
メール・データのバックアップ方式も刷新した。DEEPMailサーバーの共有ディスクとして利用するNAS（Network Attached Storage）装置内で，ディスクからディスクにバックアップする方式を採用した。この方式だと，フル・バックアップ作業が数十分で完了する。これまでは日次で差分バックアップを実施し，フル・バックアップは週次で実施する運用だったが，システムの見直しを機に毎日フル・バックアップを実施する運用に変更できた。
