dreamstime_s_44863393
© Rawpixelimages | Dreamstime.com – Antivirus Themed Concepts And Blue Background Photo

3回目は表から見えないインフラ系ともいうべきシステムの制御について書いてみます。

前回エクセルでお金の計算を…と、書きましたがそれは運用費の計算を指します。運用費は直接的なもの（回線費や場所代、ライセンスフィー等）と間接的なもの （機器代や開発費の減価償却等）が含まれます。つまり、どんな素晴らしいシステムでも事業として構造的に赤字であれば、戦略的な価値がない限り持続的な事業継続が出来ません。ですので、事業として成立させるには運用費と初期投資額、そしてインカムからおおよその収益モデルを構築する必要があります。
※つまり、売り上げ予想から何年で累損をクリアして損益分岐を越えるか…等々

いろいろとシミュレートした結果、サーバ群を一般的なデータセンタに設置すると運営費で赤字になってしまいます。これは見積もり段階で予想していました。それではBフレッツ等の低価格の回線を使い、電源・空調等のファシリティーが脆弱な一般の事務所にサーバ群を設置した場合、どのような点に考慮してシステムを構築すべきでしょうか？

これは非常に明快な話で、とにかくこれらサーバ群はいつでも止まってしまう（回線的にもサービス的にも）という前提でシステムを構築しなくてはいけない！…ということになります。

要求仕様というか前提となる条件を下記のようにまとめました。

1．ベストエフォート100Mbpsの回線を使用
2．/29を前提としてグローバルIPを割り当てるサーバは5台
3．ゲートウェイ型アンチウィルスサーバは2台構成（LBを組む）
4．中継サーバは5台（専任は3台）、管理サーバは2台（中継サーバを兼務）
5．一拠点はいつ停止してもシステム全体に影響がでないようにする
img2bb8b3d7bf8471f60a648各サーバの役割は、

manager（管理サーバ） メール本文を中継する前にAVRと通信しどのproxyを使うか決定する
proxy  （中継サーバ） AVRからのメール本文を宛先メールサーバへ中継する
auther （認証サーバ） MACアドレスを使った簡易認証を行う

ここから実装の細かい話に入っていくとそれこそ数ページ必要なので、AVRの動作の概略を書いてみます。これで何となく耐障害性をどのようにあげているか雰囲気が解ると思います。

1．AVRスタート！      manager.sample.comでdnsを引く
                      ラウンドロビンで任意のmanagerが通知される
2．managerと通信      使用するproxyがmanagerから通知される
3．proxyと通信        特注プロトコルで通信後、相手先メールサーバと接続される
                      接続後はクライアントからの通信（smtp,pop3）を流す
4．smtp,pop3通信終了  proxy, managerにbyeを送信

2の通信ではmanagerから返答がない場合は、dnsクエリーの返事にある次のmanagerに接続を試みる（タイムアウトは約5秒と短い）。全てのmanagerにタイムアウトした場合には直接相手先メールサーバへ接続を行います。

また、managerは自分の管理下にあるproxyを監視しており、Load averageが規定値を超えたりtime outした場合には一時的に管理テーブルにマークし、そのproxyは使わないようにします。

管理テーブルの記述を工夫すると負荷バランスを変更することも可能です。
例：サーバ5台のうち2台が管理サーバを兼務している場合、管理テーブルに以下のようにプロキシサーバのアドレスを書く。

proxy_address 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.3, 10.0.0.4, 10.0.0.4, 10.0.0.5, 10.0.0.5

このように書くと、兼務と専任サーバの負荷割合が1:3となります。
※もっとも実際に運用してみたところ、監視情報として上がってくるLoad averageの一番小さい値のproxyを選ぶという単純なロジックでも十分でしたww

dnsラウンドロビンを使った簡易的な負荷分散でも、接続されるAVRが増えてくると、確率的にそこそこ負荷が分散されます。システム立上げ時は3拠点でスタートし ましたが、1拠点を止める場合にmanagerを登録しているdnsのゾーンを書き換えると、TTLを20分程度にしていたので、見ている間にトラフィックが切り替わっていく様子は、凄いというか面白かったです。

駆け足ですがインフラ系の仕組みを簡単に書いてみました。ポイントは全体を統括管理するマスターサーバを持っていないという点です。managerは自分に任されているproxyしか管理をしませんし、そもそも自分以外のmanagerの存在を知りません。また、拠点を増やすときには全く同じ機器構成でFWの設定だけを納入環境に合わせ（ポートフォワーディングしているので各サーバはローカルIP）、後はprimaryのdnsにmanagerのグローバルIPを登録するだけなので、スケールアウトが非常に簡単に行えます。
※自立分散型のシステムは耐障害性が高いです。

次回はもう少し突っ込んだ話（kernelチューンとかsmp対応の話とか…）を書いてみます。

投稿タグ
,