～ ミネルヴァの梟は黄昏とともに飛び始める ～

　最近、弊社の製品もマルチキャスト対応をしました。

　マルチキャストとは、複数個所へのデータ配信量を劇的に削減する技術の事で、例えば「ニューヨークとシリコンバレー」に同じデータを送信したい場合、宛先情報を２つ貼り付けたデータを１つアメリカ方面に投げます。同じ経路で送れる間は、そのまま送信し分岐が必要な場所（おそらく、西海岸付近のルータ）でデータを複製し、一方に「ニューヨークの宛先」もう一方に「シリンコンバレーの宛先」を付け、データを分岐させます。こうする事で、太平洋上を流れるデータ量がほぼ半分になります。

　この技術により、ADSLのような上り（送信）速度の遅い回線でも快適にウェブ会議をする事が可能になりました。

　ところが、中継システムに不具合があるようで、半日も使うとCPUが100%に張り付く症状が発生し、プロファイラにかけてみると一部のスレッドが暴走していることが判明しました。暴走の理由はソケットからのReadが永遠にトライアゲインエラーを吐き続けるというものでした。

　暫定対処はしたので、とりあえず安定して動作しているのですが、根本的な対策をする必要があり、負荷プログラムの作成が急務だったのですが、中継システムは改良に次ぐ改良で、正確なプロトコルドキュメントが存在していません。しかもどのドキュメントも使い物になりません。さすがに、30万行のソースコード（実行ラインで15万行）を読む元気もない訳で。。。

　しかも、エンドツーエンドで暗号化しているので、途中でパケットを拾ってもさっぱり分からないというのは結構困りました。結局、中継サーバからバイナリデータを抜き出し、バイナリエディタと関数電卓とを交互ににらめっこしました。プロトコルを解析しなんとか負荷プログラムを作成できました。準備に３日、解析に１日かかった訳ですが。。。

　みなさんちゃんとドキュメントは書きましょう　orz

　以前から放置していた、社内ブログ（wordpress）のDB（MySQL）を移行したのですがめちゃくちゃハマりました。

　もともとそのサーバには、他にもサービスが同居していた事もあり、MySQLにメモリを多めに割り当てていたのですが、そのサービス達も別のサーバに移行したため、ブログのためだけに大量のメモリを確保するDBが存在する事になってしまいました。

　データセンターに太い回線を引き込んでいる共用のDBサーバがあるので、ブログのDBもそちらに移行する事に決定。

　まぁ、DBの移行だからすぐに終わるだろうと思い、DBのダンプをとり、共用DBにリストア。さらにアクセス用のアカウントを作成。コンソールからネットワークを超えてアクセスしようとすると、反応が返ってこない。 続きを読む »

 今日は朝からオフィスビルの停電がありました。弊社では、運用コストを下げるために自社内で多くのサーバを運用しております。当然、信頼性の求められるサーバーはUPS（無停電装置）に接続したり、東京都内のデータセンターにサーバを置いて、クラスタリングを組んだりしています。（弊社は京都に本社があります）

 今回も大規模な停電でしたが、有償版の高機能Web会議システム　SOBA mierukaは無停止でご利用頂ける状態で運用されておりました。 無償版のWeb会議システム　SOBA CITYについても、10分間停止しただけで復旧いたしました。

 弊社では、『開発系統のサーバ群』と『運用系統のサーバ群』があり、開発系統は開発者が好き勝手にサーバを設置しています。しかも、「ファンがうるさい」とか「熱い」との理由からサーバールームと会議室の一角に開発系統のサーバが積まれています。配線もぐちゃぐちゃですが、移動頻度の高いマシンなので、裏側で配線するよりも効率的なのです！（と言い訳をしておこう）