ソーシャルアプリ開発の５つの工夫

ソーシャルアプリはサービスイン時に膨大なトラフィックが来るという事は度々伺っており、ホスティング会社によると「イチオシ」欄に載ったアプリが数分で落ちたという事もあったそうです。

なかには100台近いサーバーで運用しているサービスもあるようで、そのコストははかり知れません。
なので今回弊社も負荷対策には慎重になっていて、システム開発にはかなり工夫を行いました。

【１】フレームワークを使わない
弊社では標準でcakePHPを採用しているのですが、やはり負荷に対する懸念が強く、今回は保守性の低下を覚悟で１から自前で構築しました。本当は全部静的に作りたい位の意気込みでしたが、セキュリティの都合上簡単なテンプレートエンジンを作り、必ずOAuthのチェックや、文字コード変換、絵文字変換、メンテナンス時間管理は行うようにしました。

【２】できる限りDBを使わずキャッシュ化
管理画面上はDBで管理し、ユーザー画面ではserializeしたデータを扱う事を徹底しました。
なのでそれをwebサーバー間で容易に同期をとるrsyncするシェルを構築。
さらに今回、初の試みでかなり不安な点が、ログの管理等のほとんどをファイルで管理するようにしました。DBを使うよりはコストが少ないだろうという判断ですが、実際どこで問題が発生するのか、未知数な試みです。この結果についてはリリース後に記述します。

【３】定時メンテナンス
毎日定時にメンテナンス時間を設けて、その時間に一気にバックアップや集計、更新作業を行うようにしました。

【４】コールドスタンバイのサーバを複数台用意
リリース後の急激なトラフィックの増減に対応できるように、コールドスタンバイのサーバを常に待機させるようにしました。

【５】動的フラッシュの生成について
ハコニワやホシツクのように、複雑なswfを生成するというパターンは実際に今回の企画では無く、会話シーンのニックネームの文字列置換を行うというものでした。
これに当たって、当初はswfmillを使った生成しておりましたが、処理コストの問題で不採用。
ユーザ別にSWFを生成するパターンも検討しましたが、全体サイズの肥大化への不安と、更新時のハンドリングの難しさ、保守性の問題から取り入れませんでした。
結論として、swfを直接置換して出力する方法を取り入れましたが、これを実装するに苦労した点として、単純に文字列を置換して出力しただけでは、そのバイト数が異なる場合、SWF内のヘッダ情報があわずエラーになってしまうという事。
本来、再度ヘッダ情報を再構築して出力する必要があるのですが、なかなかこの処理が実装できず、最終的には、置換前の文字列と置換後の文字列のバイト数を無理やりあわせて、swf内で表示上の調整をさせるというトリッキーな方法で克服しました。

その他ロードバランサーを入れたり、eacceleratorを導入したりと、細々と工夫は行っておりますが、経験上DBとのやりとりが一番ボトムネックになりやすい為、その点を重点的に対策を行い、【２】が上手く動作すれば、かなりのコストパフォーマンスを発揮してくれるのではないかと睨んでいます。