© Rawpixelimages | Dreamstime.com – Antivirus Themed Concepts And Blue Background Photo
システム開発も終盤にさしかかり本番環境の構成を決めなくてはいけないのですが、これが結構やっかいで、またお金の計算をしなくてはいけません（苦笑）。
本番環境というと回線費等に加えて最初に用意するサーバ等のハードウェアも購入する必要がありますから、計算上は3年で償却することにしました。また、3年間でハードウェアの追加無しで約8,000クライアント（営業計画より）までサポート出来るようにするには、サーバにどの程度の能力が必要か（価格は抑えて）の見当をつけなくてはいけません。
細かく書くと3拠点で8,000クライアントというと、2拠点で8,000という意味になります。
※ そうでないと冗長化した意味がありませんから… 余談ですが、冗長化と負荷分散って混同されることが多いです。『1台で処理が間に合わないので2台にしたらなんとか動いた』というのは負荷分散としてはOKですが、これは冗長化はされていません。もし片方が故障したら即座に過負荷になり残り1台もハングアップしてしまいます。ですからその場合は3台構成にしてくださいといつも言っているのですが、なかなか理解してもらえません。
話を戻して…2拠点で8,000＝1拠点は約4,000という事になります。つまり平常時負荷が1拠点2,666（≒8,000÷3）程度で、もし1拠点死んだときには最大4,000の負荷に耐えられなくてはいけないという意味になります。また、拠点は5台のサーバで構成されますので1台で最大800クライアント （平常時は約500）の接続が可能でなくてはいけません。
以上の前提より、平常時は500クライアント/サーバでスループットは10Mbps以上、1拠点ダウン時には1,000クライアント/サーバでスループットは5Mbps以上という設計基準としました。しかし、この基準を満たすにはどの程度のサーバが必要かという検討は簡単ではなく、結局数十台のＰＣをレンタルし、サーバとクライアントのシミュレーターソフトを走らせ負荷を与え、当たりをつけてみることにしました。
…と、文章で書くとすぐ終わったようですがこれが結構しんどい作業でした。納期がせまっていたので開発系スタッフは目を三角にしてデバッグ中ですから、とてもこんな検証作業につきあわせる訳にはいきません。結局、広い会議室にPCを展開して一人でごそごそデータ取りをしていました。
結果的にはCPUにはPentium4の2.8GHzクラスでメモリーは2G程度でなんとかなりそうという結論で、Super Microのベアボーンを用意することにしました。もっと安いサーバは用意できたのですが、スタート時にはハードウェア保守費用の捻出も難しそうでしたので、なるべく信頼性の高いものを用意することにしました。
※業務用なのでハードウェア保守（出来ればオンサイト）は必須だと思いますが…（苦笑）
さて、ここまで書くと勘の良い方は気がつかれたと思いますが、標準のLinuxカーネルではこのシステムを動かすことが出来ません。SMTPを中継するシステ ムですから１クライアントあたり最低でも２ポートは必要になりますから、平常時の500クライアントですでに1,000ポートが必要です。また、何もしていない時でも数十ポートは開いていますから、1,000＋αのポートをオープンしなくてはなりません。
Linuxでは通信ポートもファイルのオープンと同じで、とにかく外部とデータをやりとりする場合にはファイルディスクリプタ（file descriptor）というリソースを消費します。このファイルディスクリプタは標準では1,024が最大値になっていますので、このままでは足りません。 これはカーネルの起動スクリプト等ではどうしようもなく、カーネルのソースを変更＆コンパイルが必要となります。
※詳しくは『Linux kernel, file descriptor』とかでググってみてください。
※本番用カーネルは4,096でコンパイルしました。
また、通信がメインのサーバですので、TCP/IP周りのチューニングも効果があります。
/etc/sysctl.confに書くのですが、特に受信・送信バッファはそこそこ大きくしておくと良いです。
※これも、『Linux kernel TCP/IP チューニング』等で検索を！
実はこの辺のカーネルチューニングをしていて気がついたのですが、開発中だった中継システムの中核となるプログラムが、シングルプロセスのマルチスレッド処理になっていました。これって、CPUが1個の時には問題にならないのですが、マルチCPUもしくはマルチコアになると問題が出てきます。いくらスレッドを増やしても、親のプロセスが同じだと同じCPU上でしか実行されないので、マルチCPUのメリットがまったく出ません。
※だから、Apache等もマルチプロセス・マルチスレッドだったりします。
※最近はシングルプロセス・マルチスレッドでも大丈夫らしい～!?（謎）
※SMP環境にはirqbalanceを是非！（1CPUでハイパースレッドならいらないけどww）
結局、当時はLinux kernelも2.2系でSMP制御がへたくそだったし、選定したサーバも１CPUタイプだったのと、納期が迫っていた（←これが一番！）ので、マルチプロセスで動作するように手を入れるのはやめにしました。
また、分散動作しているサーバ群を1カ所から監視・制御するコントロールシステムも作りたかったのですが、時間と資金が足りず断念しました。Nagiosを使った死活監視とmrtgによる負荷監視で最低限の管理を行い、後は手動でconfigガリガリで運用を行いました。
βテストも何とかこなし、念願の本番サービスをスタートさせましたが、毎日少しずつクライアントが増えていき、それに伴ってサーバの負荷が上昇していく様子は、今思い出してもドキドキの毎日でした。
クライアント側でウィルスやマルウェアのアウトブレイク（爆発的感染）が発生すると、『ウィルス駆除したよ』メールが大量に発生します。今回採用したゲートウェイ型のサービスではクライアントPC上のウィルスを駆除することは出来ないので（通信で流れているマルウェアは駆除可能）、閾値を超えるような通知メールがウィルス検知ゲートウェイから送信されると、自動的に管理者へ警告メールが配信されるようにして、担当の営業さんに連絡してお客様に対応を促す仕組みとか… なんだかちょこちょこスクリプト作っていたような覚えがあります。
実は、同じルータにhttpのウィルスチェック＆Webコンテンツフィルターとかも実装（基本構想はすでに練っていました）したかったのですが、残念ながらエンハンスする予算が付く前にサービス提供会社がなくなってしまいました。
当時サーバサイドの開発担当だったチームも解散後、メンバーもちりじりになってしまい、今では連絡もつきません。一期一会とはいえ本当に残念です。開発期間が短かったので（実質6ヶ月程度!?）、きつかったのは事実ですが、とても楽しく充実した時間を過ごすことができて、このプロジェクトのPMは楽しかったです。最後になりましたが、開発メンバーや関係した沢山の人々に感謝です（言葉にすると陳腐ですが…）。ありがとうございました。
