オール OSS による通信事業者向 による通信事業者向け 通信事業者向け大規模メールサーバ 大規模メールサーバ構築 メールサーバ構築への 構築へのアプローチ へのアプローチ 稲垣尚史* 川野啓一* 福島愼一* 小杉英司* 松下年伸* 宮井昭男* Email and Messaging Large Service System based on Open Source Software (OSS) for telecommunications Carrier 要 旨 近年のインターネットの普及に伴い，電子メールは人々の 業での採用の動きが増加している。しかし，OSS はインター 必須のコミュニケーションツールとして，情報発信，ビジネ ネット上のコミュニティの活動などにメンテナンスが委ねら ス等に幅広く利用されている。背景として，電子メールが， れ，責任の所在がはっきりしないことなどから，信頼性，安 専用ソフトウェアで相互交換するインターネットメール，携 定性に不安があり，ミッションクリティカルなシステムでは， 帯電話向けショートメッセージサービス，ウェブブラウザの 採用を見送られることも多い。 みで動作する Web メール等と加入者の利便性を向上させる このような背景のなか，三菱電機インフォメーションシス 様々なサービスへ進化していることが一因としてある。通信 テムズ(株)（MDIS）は，OSS だけを組み合わせて，通信事業 事業者各社は，これらの多彩なサービスを実現するために， 者向けメールサービス提供システムの構築に取り組んだ。シ サービス提供のためのサーバシステムを日々整備，拡充して ステム構築にあたり，OSS の選定検証，信頼性確保に向けた いる。サービスの拡充においては，商用パッケージ製品では OSS 内部構造にまで及ぶシステム設計，携帯電話向けメール 事足りず，サービス拡張を柔軟に行いたいという要望がある。 も配慮した OSS 間の整合性確保，性能確保などを行うことで さらに，電子メールは緊急時も含めた連絡手段として定着し， 個々の課題を解決し完成させた。MDIS では，本実績を元に， 社会インフラとしての重要性が高まり，システムに求められ 2012 年 10 月より“OSS による携帯電話メールサーバ構築支援 る信頼性はより一層増している。 サービス”を開始している。 ライセンスフリー等のメリットがあるため，近年，オープ ンソースソフトウェア（Open Source Software ：OSS）の企 W e b メ ール メ ールソ フ ト 他キャ リ ア 他キャ リ ア 通信事業者セン 通信事業者セン タ ー設備 ー 設備 メ ールサーバシ ステ ム M M Sゲート S ゲート ウェ イ 設備 オールO オールO SS 絵文字 SM S 設備 大規模 メ ール ＢＯＸ 大規模 ユーザ 情報 運用・ 運用・ 監視 設備 顧客管理 設備 MMS: Mu ltim ed ia Messa g in g Serv ice SMS: Sh ort Messa g e Service 通信事業者向 通信事業者向け大規模メールサービス 大規模メールサービス提供 メールサービス提供システム 提供システム 大規模加入者を収容する通信事業者向けメールサービス提供設備において，オール OSS での構成に取り組んだ。携帯電話網，他キ ャリア網，インターネット網とのインタフェースを持ち，相互にメールの送受信が可能。 * 三菱電機インフォメーションシステムズ㈱ １．まえがき OSS は機能追加を想定し，プラグイン機能を持つものも多い。こ OSS の組み合わせによる通信事業者向け大規模メールサービ のような対応方法の選択肢がある中で，どのような方針で機能 ス提供システム構築にあたり，採用する OSS の候補選定から OSS 不足を補うことが最も効果的か見極めることも，OSS 採用時の課 選定検証を経て商用利用可能なシステム構成を決定するアプロ 題である。 ーチをとった。本稿では今回の構築に際しての取り組みについ て述べる。 ３．OSS 選定と 選定と課題抽出 ２．OSS 採用の 採用のメリットと メリットと課題 (1) OSS の利用実態調査 によれば，国内ユーザ企業が使用してい システム構築にあたり，まず OSS の候補選定から OSS 選定検 証までを実施した。選定検証では，2.2 に示す機能面，安定稼動 る OSS の種類では”オペレーティングシステム”が 59％で最も 面に対するリスクを見極めるため，フィージビリティスタディ 多く， ”Web サーバ／アプリケーションサーバー” ， ”メール／グ による多角的な試行評価を行った。 ループウェア／コラボレーションツール” ， ”データベース管理 ３．１ OSS 候補の 候補の選定 システム”が 30％以上となっている。特定の分野・業種向けの まず実現すべき機能を分解することで各要素機能を抽出し， OSS も増えており，携帯電話のメールサービスである SMS（Short それぞれの要素機能を持つ OSS を選定して，それらを組み合わ Message Service）や MMS（Multimedia Messaging Service）を せることで，表１の OSS 基本構成を策定した。 実現するためのソフトウェアも存在する。しかしながら，これ 表 1 選定した 選定した OSS ら特定の OSS は，商用稼動の前例が少なく品質面での不安があ り，採用にあたって見極めが課題である。 機能名 OSS 名 選定理由 ス提供コストの低減に貢献する。 ・多数の MTA(Mail Transfer Agent)実 績あり ・大規模設備での利用実績あり メールボッ Dovecot ・多数のIMAP(Internet Message Access クス管理 Protocol)サーバ実績あり ・パフォーマンスが良く，標準規格へ の準拠度が高い ・柔軟な設定が可能 MMS Mbuni MMS ・MMSC(MMS Center)機能を持つ OSS Gateway ・最新の MMS 規約に準拠 （２） ソース公開 ソース公開（ 公開（ホワイトボックス化 ホワイトボックス化）による仕様把握 による仕様把握が 仕様把握が可能 SMS ２．１ OSS 採用の 採用のメリット （１） ライセンス料 ライセンス料が発生しない 発生しない OSS 採用の最大のメリットは，ライセンスフリーという点であ る。多くの加入者向けにサービスを提供するキャリアにとって， 加入者ごとのライセンス料が発生しない OSS の採用は，サービ 商用パッケージ製品では仕様が開発ベンダによりブラックボ ックス化されるため，通信事業者は思うように新サービスを提 供できないという問題があるが，OSS を採用することにより開発 ベンダへの依存性が軽減され，低コストで迅速な新サービス対 応開発が可能となる。 ２．２ OSS 採用に 採用に対する課題 する課題 （１） 信頼性・ 信頼性・安定性の 安定性の見極め 見極め OSS 採用には信頼性，安定性の不安があるため，MDIS では， 事前の選定検証によって，OSS の機能面，安定稼働面の実現性評 価を実施し，見極めを行った。OSS は開発の主体となる組織が存 在せず，責任の所在がはっきりしないインターネット上のコミ ュニティの活動に委ねなければならない場合も多い。MDIS では， OSS に造詣が深いベンダとの協業により，自社開発したアプリケ ーションソフトウェアと同等の主体的な開発と品質管理を実施 している。 （２） 機能不足への 機能不足への対応 への対応 OSS を採用する場合，実現機能に対して機能不足，もしくは機 能の差異が発生する場合がある。OSS への機能追加，機能修正は ソース修正も含めて，以下のような対応方法が考えられる。 ① OSS 自身が持つプラグインを利用した機能追加 ② 対象 OSS と連携する外部プログラムによる機能追加 ③ 対象 OSS のソースコードの修正による機能追加 メールサー Postfix バ Kannel SMS ・SMS 配信機能を持つ OSS Gateway ・多数の SMSC(SMS Center)インタフェ －スを持つ データベー MySQL(注1) ・Postfix や Dovecot のサポートする ス リレーショナルデータベース ・パフォーマンスが良い メールフィ Milter ・メールフィルタのプラグイン適否を ルタ管理 manager 制御可能 Web メール Squirrel ・多くの実績をもつ Mail ・IMAP インタフェースを持つ ・プラグインで機能追加が可能 ３．２ 机上での 机上でのフィット でのフィット＆ フィット＆ギャップ分析 ギャップ分析～ 分析～実機による OSS 選定 検証 策定した OSS 基本構成について，目的とする機能・非機能要 件に対する机上でのフィット＆ギャップ分析を行うことで，適 合性が不透明な要件を課題として抽出した。次ステップとして， フィット＆ギャップ分析結果をインプットとして OSS 選定検証 計画を策定し，実機による OSS 選定検証を進めた。OSS 選定検証 計画では，検証項目，検証方法，スケジュールに加え，評価の 実施方法を定義した。また，OSS 選定検証のまとめでは，問題検 出の報告で終わらせずに，その問題の解決方法と，解決に必要 となるコストの試算も含めることで，商用機開発時に活用でき るものとした。 （注 1）MySQL は，Oracle Corp.の登録商標です。 ３．３ OSS 候補選定時の 候補選定時の確認事項 OSS の選定においては，ソフトウェアの機能面に留まらず，次 の観点で MDIS として取り組みが可能か否かを検討した。 ① ライセンス条件 ライセンス条件の 条件の確認 の Postfix のバージョンアップに追従できるようにした。 ① キャリア毎 キャリア毎の変換ルール 変換ルールへの ルールへの対応 への対応 携帯電話向けのメールサービスでは，キャリア毎に採用して いる文字コード，絵文字コードが異なるため，送付先毎にこれ 選定した OSS のライセンス条件（再配布，ライセンス料，派 らを変換して送信を行う必要がある。また，近年では Gmail(注2) 生ソフトウェア作成等）を調査し，今回構築するメールシステ などの Web メールでも絵文字をサポートしており，これらに向 ムの利用目的において問題がないことを確認した。 けても同様の変換を行う必要がある。 ② コミュニティの コミュニティの活動状況の 活動状況の確認 品質を評価する目的で，選定した OSS のコミュニティにおい て，バージョンアップやバグ修正が活発に行なわれているかを 本システムでは文字コード変換，絵文字コード変換をメール フィルタとして実装した。 ② 拡張性を 拡張性を考慮した 考慮した構成 した構成 キャリア毎に専用 MTA(Mail Transfer Agent)を配置し，それ 確認した。 ぞれの変換ルールを持つメールフィルタを組み込むことで，複 ４． システムへの システムへの適用 への適用 ４．１ アーキテクチャの アーキテクチャの決定 OSS 選定検証の結果判明した課題とその解決策に沿って，シス テムとしてのアーキテクチャの策定を進めた。 ４．１．１ 採用 OSS の問題点と 問題点と対策 数の変換ルールに対応するとともに，変換対応キャリアが増加 した場合も，MTA とメールフィルタの追加により，既存部分に影 響を与えずに対応可能な構成とした。 （３） ユーザ個別 ユーザ個別フィルタ 個別フィルタ機能 フィルタ機能 幅広い年代層が利用する携帯電話のメールサービスでは，ユ OSS 選定検証の結果，いくつかの日本独特の携帯電話サービス ーザ毎に複数のフィルタを組み合わせて，効果的に迷惑メール は，OSS だけでは実現できないことが判明した。主なものを表２ などのフィルタリングを行いたいというニーズがある。ユーザ に示す。 個別フィルタ機能は，多くの加入者を対象として個別にフィル No. 1 2 3 表 2 OSS だけでは実現 だけでは実現できない 実現できない機能 できない機能 項目名 必要機能 MMS 機能 ・インターネットメールとの相互通信 機能 絵文字変換処 ・キャリア間で異なる絵文字を変換す 理 る機能 ・利用者毎に定義できるメールフィル ユーザ個別の タ機能 メールフィル タ処理 タを適用する必要があるため，ユーザ毎の異なる適用条件に柔 軟に対応するとともに，負荷対策を考慮する必要があった。 ① 性能上の 性能上の課題 通常，複数のフィルタ処理をメールフィルタとして MTA に組 み込むが，全てのメールフィルタから応答があるまで処理を待 ち合わせる構造となるため，メールフィルタの処理遅延がボト ルネックとなる懸念があった。また，ユーザ毎の適用可否を判 OSS では実現できない機能に対しては，機能追加を実施した。 定するためには，全てのメールフィルタが個別にデータベース 今回は OSS プロダクトのバージョンアップにできるだけ追従で 上のユーザ情報を参照する必要があり，即時性が求められるた きることを方針として，各追加機能に対して，プラグインでの め，高トランザクションが発生する携帯メールシステムでは， 対応，連携プログラムの追加，ソースコード修正の順に実装方 データベース性能がボトルネックとなる懸念があった。 式を検討した。個々の対応については次節に記載する。 ② 本システムでの システムでの工夫点 での工夫点 ４．１．２ 機能不足部分への 機能不足部分への対応 への対応 （１） インターネットメールとの インターネットメールとの変換 との変換を 変換を強化 MMS 機能では，ローカル配信（携帯メッセージ）は MMS 形式で 本システムで採用した Milter manager は，MTA とメールフィ ルタの間に位置し，データベース上のユーザのフィルタ設定情 報を参照して，必要なメールフィルタのみ動作させる制御を行 送受信を行うが，インターネット（外部メール）との送受信は っている。これにより，データベースの参照とメールフィルタ SMTP（Simple Mail Transfer Protocol）形式に変換している。 処理を最小限に抑えることができ，携帯メールシステムにも耐 そのため，ヘッダ変換，文字コード変換，マルチパート構成変 え得る性能を確保することができた。また，新たなサービス(ウ 換などを行う方式を実装し，相互通信を実現した。また，本機 イルスチェック，スパムチェックなど)に対しても，メールフィ 能のベースとなる OSS には，プラグインインタフェースが無か ルタを追加することで，柔軟に対応できる。 ったことと性能面への影響を考慮し，カスタマイズはソース改 修により実現した。 （２） キャリア毎 キャリア毎の絵文字・ 絵文字・文字コード 文字コード変換 コード変換に 変換に対応 絵文字変換処理およびメール個別のフィルタ処理は，Postfix のメールフィルタ拡張プラグインを使い，実装する方法をとっ た。これにより，Postfix の持つ安定性を損なわず，また，今後 （注 2）Gmail は，Google Inc.の登録商標です。 フ ロント エンド 凡 例 物理構成 機能 W e b メ ール メ ールフ ィ ルタ SM TP （ 仮想メ 仮想メ ールアド レ ス ） M ilte r m a na g er MMS W e b メ ール Sq u ir r e l M a il メ ール処理 ール処理 内部メ 内部メ ールア ド レ ス 変換後の 変換後のメ ール処理 ール処理 メ ールソ フ ト Po s tfix Mbuni SM TP （ 送信／ 送信／転送） 転送） I M A P 変換 I M A P プ ロ キシ 機種依存 変換 D o v e co t M ilte r m a n a g e r Po stfix バッ ク エ ン ド データ ベース I M AP 保存容量制限 SM TP ( メ ールボッ ク ス 配信) 配信) D o v e co t ユーザ情報管理 ユーザ情報管理 Po s tfix ユーザ 情報 SM S 通知 メ ールBO ールBO X M y SQ L Kan n el メ ール設定 ール設定サイ 設定サイ ト から の設定変更 の設定変更 ユーザ登録 ユーザ登録／ 登録／ 削除要求 図１ インフラ構成図 インフラ構成図 ４．１．３ プラットフォーム構成 プラットフォーム構成面 構成面での工夫 での工夫 を行うことで，設計段階で不足する機能や品質の把握を可能 今後のスマートフォンの普及や，通信事業者の提供サービ とし，開発上位フェーズから対策を打てるようにした。また， ス増加による利用者増や利用回数増に備え，性能確保や拡張 検証環境を使っての連続運転試験，過負荷試験，異常試験を 性を検討した。その結果，本システムでは，図１の通り 行うことで信頼性，安定性の確認を行った。 SMTP/IMAP/MMS の各種プロトコル処理やメールフィルタリン ５． むすび グ処理を行うフロントエンド部と，メールボックスの管理（メ ールボックス配信，保存容量制限，SMS 通知）を行うバック MDIS は，これらのプロセスを経て，通信事業者向け大規模 エンド部の 2 階層構成とした。 メールサーバのシステム構築を完了し，本ノウハウを活用し （１） 将来の 将来のトラフィ トラフィック フィック増加 ック増加を 増加を想定した 想定したフロントエンド したフロントエンド部 フロントエンド部 て，2012 年 10 月より，”OSS による携帯電話メールサーバ構 将来のトラフィック増加を想定し，フロントエンド部によ 築支援サービス”を開始している。なお，OSS は導入後にも， るスケールアウト可能な構成を検討した。フロントエンド部 サポートの継続性の課題がある。MDIS は，システムのライフ の機能は，フロントエンド部がメールを受け付けると，メー サイクル全般に渡って，ソースコードレベルでの当事者責任 ルアドレスをシステム内部メールアドレスに変換してバック を全うすべく，OSS コンソーシアム(2)の参加企業とのネットワ エンド部に処理を引き継ぐ方式とし，Postfix，Dovecot の組 ークにより，必要充分な体制・技術を維持する。 み合わせにより実現した。この機能により，フロントエンド 部はトラフィックに応じて単純増設可能となり，性能確保を なお，今後も他の分野への OSS 適用の可能性を探って行く 予定である。 可能とした。 （２） 容量拡張可能な 容量拡張可能なバックエンド部 バックエンド部 バックエンド部は，将来のユーザ数の増加に応じて，メー 参考文献 (1) IDC Japan， ”国内オープンソースソフトウェア利用実態調査結 果を発表” ，2012 年 1 月 11 日 ルボックス格納用ストレージを増設することで，拡張可能な http://www.idcjapan.co.jp/Press/Current/20120111Apr.html 構成を検討した。フロントエンド部からバックエンド部への (2) オープンソース・コンソーシアム 処理引継ぎは，メールボックスの格納領域（バックエンド部） http://osscons.jp/ が複数に分散されても，フロントエンド部には影響が無いよ うに，データベースに格納されたユーザ情報で紐付ける方式 により実現した。この機能により，バックエンド部は利用者 増に伴う増設が可能となった。 ４．２ 信頼性， 信頼性，安定性の 安定性の確保 採用した OSS の中で，携帯電話機への接続を実現する MMS/SMS 部分のソフトウェアについては，商用稼動の前例が なく信頼性や安定性に対して懸念があった。本リスクに対し ては，前述の通り，フィット＆ギャップ分析と OSS 選定検証
© Copyright 2024 Paperzz
