弊社の社内システムについて

こんにちは、開発本部の大西です。

さすがに、まだ、外部に公開できるAccelPlatformの導入事例がないので、皆さんお困りだと思いますので、参考になるかはわかりませんが、弊社の社内システムで利用している環境についてご紹介させていただきます。

弊社での利用用途は、

iAP環境：

• IMBox
• ContentsSearch（IMBox検索用2013 Springで提供予定）
• FileExchange（2013 Springで提供機能のファイル公開機能）
• Accel Collaborationの各機能
• IM-Workflowでの各種申請
• Formaでの簡易アプリケーション
  • IPアドレス管理やクライアントPCの情報セキュリティチェック報告

iWP v7.2環境：

• 勤怠・旅費申請
• プロジェクト管理
• ドキュメントワークフローでの各種申請

※IT統制等の理由から、2システム併用という形になっています。

というような機能や業務で利用しています。
（※販売管理や営業システムなどはこれとは別で存在しています。） 

サーバはAmazonEC2の東京リージョンのエクストララージで、これまで利用していたiWPv7.2上の社内システムと同居しています。
同時アクセスが100〜150程度ですので、コストと運用面から考えて、現状、IM、DB含め、すべてのソフトが、この1つのサーバで完結しています。

バックエンドな部分から説明すると、データベースも共同で、Oracle11gを利用しています。

実はこれが、問題で、iAPの推奨はDBの文字コードもUTF-8 にすべきなのですが、もともとJA16SJISTITLDEというSJISの文字コードのデータベースをそのまま流用しているので、iAP自体に中国語が入っているんですが、DBの文字コードがSJISなので、文字化けで入ってしまっていてまともに使えない状態です。将来的には、iAPだけ切り出して、別DBにしないとダメだなぁ〜と感じています。

IMBoxに関しては、当然ながら、Cassandra 1.1.4を使っています。

Cassandraは、通常、データをメモリ上に保持していて、自動でDiskに書き込むという動きをしますが、過去、3回ほど、Diskにデータが書きだされてなくて、IMBoxデータがぶっ飛ぶという地獄に叩き落される恐怖体験をしているので、今は、15分毎に強制的にDiskに書き出すflashという処理をcronで動かしています。

iAP自体は、普通にインストールしてるので、あんまり語ることはないですが、Javaのパラメータは、こんな感じです。

-Djava.io.tmpdir=/xxx/resin/tmpは、普通であれば、不要ですが、この環境OS自体のディスクの空き容量がかなり厳しく（使用率90％以上）、また、iAPからファイルアップロードされるとJavaがtemp領域に一時的にファイルを作成しながら処理するようになっています。そのため、数百Mのファイルを何個もあげられるとディスク領域がすぐに無くなってしまうので、このパラメータで、ディスクに多少余裕のあるESB領域の場所にtmp領域を明示的に指定してそこを使うようにしています。

フロント部分のWebサーバ、Apacheの部分に関してですが、普通、Apacheを前に立てた場合、mod_cauchoを使うのが定石ですが、iAPの場合、mod_cauchoを利用するとIMBoxで利用しているCometという通信ができません。そのため、新着メッセージの表示が表示されません。
参考：mod_caucho-モジュールを利用した場合、common_imbox-の新着メッセージの表示が表示されません。

また、この環境は、v7.2も同居している環境で、こちらの方がResin3.1のmod_cauchoを利用しているので、iAP接続には、mod_proxyでのリバースプロキシで、iAPが稼働している、Resinに接続しています。

ただ、これだと、静的コンテンツの取得も全部、Resinに行ってしまって、Apacheの役目は、SSLしかなくなってしまい、Apacheを立てている意味がなくなりますので、IM-Jugglingで静的コンテンツを別に出力して、Apacheのコンテンツ配下に格納し、mod_rewriteで振り分けて、静的コンテンツは、そちらを見に行くようにしています。

設定は、こんな感じです。

あとチューニングとして、ApacheのMPM(Multi Processing Module)を標準のpreforkからworkerに変更しました。
CentOSの場合、変更は非常に簡単で、/etc/sysconfig/httpdで、通常にコメントアウトされている

HTTPD=/usr/sbin/httpd.worker

のコメントを外すだけです。

この環境のようにIM専用だとこれだけでも、若干体感できる程度のそこそこの速度向上がありました。ただし、同じApacheでPHPを使っているような環境ではできないよう模様です。

次にやったのは、一部で流行しているSPDYの導入です。

SPDYは、googleが進めているプロトコルで、現在策定中のHTTP 2.0になるんではないかといわれているものです。サポートしているブラウザが、ChromeとFirefox、Opera程度で、また、実運用で利用されているのは、Googleの各サービスとtwitterとfacebookのごく一部程度です。

Apacheの場合、mod_spdyというものがGoogleから提供されていて、最近のLinuxだと通常はyumコマンド一発で導入できますが、この環境のOSが、CentOS5.4と古いため、CentOS5.4で提供されているApacheやglibc自体が古く入りません。なので、Apacheやglibcをなんとか対応しているものに更新して、インストール時に必要なPythonも2.7にVerUpしてから必要ソースを取得して、コンパイルしました。Try&Errorでやってほぼ半日ほどかかってかなり大変でした。

ChromeでSPDY通信が有効になっているか確認する場合は、「chrome://net-internals/#spdy」にアクセスするか、以下のエクステンションを使うのが楽です。 

Chrome ウェブストア - SPDY indicator
(SPDYの時は、URLのわきに緑色の稲妻のようなマークが出ます。) 

で、効果ですが、
※Chromeで、毎回キャッシュをクリアして、デベロッパーツールのNetworkで表示される数字

★Portal
SPDY あり

69request 0B transferred 2.51s(onload:2.40s DDOMContentLoaded:2.03s)
69request 0B transferred 2.61s(onload:2.56s DDOMContentLoaded:2.09s)
69request 0B transferred 2.59s(onload:2.66s DDOMContentLoaded:2.14s)

SPDY なし

69request 1018.21KB transferred 2.46s(onload:2.56s DDOMContentLoaded:2.02s)
69request 1018.17KB transferred 2.46s(onload:2.54s DDOMContentLoaded:2.07s)
69request 1017.99KB transferred 2.61s(onload:2.70s DDOMContentLoaded:2.13s)

★IMBox/mybox

SPDY あり

74requests 138 transferred 4.09s(onload:2.54s DDOMContentLoaded:2.14s)
74requests 138 transferred 4.37s(onload:2.85s DDOMContentLoaded:2.40s)
72requests 138 transferred 4.35s(onload:2.70s DDOMContentLoaded:2.32s)

SPDYなし

74requests 968.44KB transferred 4.15s(onload:2.44s DDOMContentLoaded:2.15s)
73requests 966.72KB transferred 3.96s(onload:2.44s DDOMContentLoaded:2.11s)
74requests 968.22KB transferred 4.06s(onload:2.50s DDOMContentLoaded:2.22s)

★Workspace一覧

SPDY あり

57requests 0KB transferred 2.04s(onload:1.88s DDOMContentLoaded:1.51s)
57requests 0KB transferred 1.88s(onload:1.76s DDOMContentLoaded:1.39s)
57requests 0KB transferred 1.97s(onload:1.84s DDOMContentLoaded:1.47s)

SPDY なし

57requests 881.88KB transferred 1.74s(onload:1.73s DDOMContentLoaded:1.34s)
57requests 881.87KB transferred 1.75s(onload:1.75s DDOMContentLoaded:1.35s)
57requests 882.02KB transferred 1.68s(onload:1.67s DDOMContentLoaded:1.29s)

★v7.2 portal

SPDY なし

103requests 218.05KB transferred 2.45s(onload:2.34s DDOMContentLoaded:360ms)
102requests 218.47KB transferred 2.65s(onload:2.55s DDOMContentLoaded:371ms)
103requests 218.33KB transferred 2.12s(onload:2.02s DDOMContentLoaded:378ms)

SPDY あり

102requests 6.48KB transferred 2.01s(onload:1.94s DDOMContentLoaded:323ms)
102requests 6.96KB transferred 2.28s(onload:2.28s DDOMContentLoaded:376ms)
102requests 6.96KB transferred 2.12s(onload:2.12s DDOMContentLoaded:429ms)

あれ？そんなに速くない・・・。むしろ遅い時もある・・・。

まあ、Chromeだけだし、IEでの接続は普通にHTTPSになるし、注目のプロトコルだし、SPDY indicatorの拡張入れると緑色に輝くので、そのままにしておこう・・・。

というような内容で動いています。

ちなみに、他の事例の参考になると思うので、数値的なものを書いておくと、同時負荷は、平日午前中は、常に100〜150ユーザが接続しています。

よく聞かれるIMBoxのmessage数は、CQLで調べたら、

cqlsh:inner> select count(*) from MESSAGE LIMIT 100000;

 count
-------
42915

cqlsh:inner> select count(*) from GROUP LIMIT 100000;

 count
-------
  162

cqlsh:inner> select count(*) from USER LIMIT 100000;

 count
-------
  300

つまり、利用開始から5ヶ月ほど、ユーザ数：300人で、グループ数：のべ162個、のべメッセージ数；42915です。

現状Cassandraでのディスクの使用量は、約300Mぐらいです。（※添付ファイルは除く）

とまあ、こんな感じで動いています。