0Tweetまつけんです。今回は、とれたまのコーナーで有名なテレビ東京さんの番組「ワールドビジネスサテライト」(以下、WBS)で紹介されるにあたって、どういう負荷対策をしたのかを紹介します。WBSに紹介されて直後にサーバーアクセス殺到して落ちました、というような話は結構聞いていたので、機会損失という意味でも落ちるのはなんとか避けたいね、ということで対策をしましょうという話になりました。今回の負荷対策の前提となる条件を挙げます。ありがたいことにCerevoは最近、WBSに2度紹介されています。DASHの紹介(映像はこちら)の2回です。DASHでは現在、iConvexというiPhoneアプリと連動する電子巻き尺ガジェットの支援を募集しています。いうことで、それぞれでの紹介内容にあわせて、別のサイト+コーポレートサイトがあるので、アクセスが増える可能性があるサイトは計3つあります。http://www.cerevo.comになります。弊社は基本的に現時点では、ほぼすべてのサイトをAWS上で運営しているので、インスタンスの追加や変更は比較的に容易に行うことができます。最後に、WBSに限らずなのですが、取材がくるよと決まってから実際に放映されるまでは大抵の場合、あまり時間がないです。今回の場合も、1週間もないくらいの期間でできる対策をしないといけないという縛りもありました。Dashとコーポレートサイトです。websiteをつかって、静的なファイルしか置いてません。そのため、S3が勝手に頑張ってくれるので、少々アクセスが増えたところで、なんなく乗り切ってくれました。ログを見る限り、ピークでは500req/sくらいのアクセスがあったようですが、なんの問題もありませんでした。TokyoにBucketがあって、テレビ番組の負荷であれば、アクセスの大半が国内からであることもわかっている場合、S3に置いておくだけで、充分っぽいねということが分かりました。LiveShellサイトそして、本題のLiveShell向けのサイトです。こちらは、R53,ELB,EC2,RDSを使った、割とスタンダードな構成(だと思っています)のサイトです。負荷対策をどこにどういう風に施していくかという部分です。LiveShell向けサイトはその機能を考えると、大きくわけて2つの種別のページに分けることができます。1つ目は、上記のLiveShellを操作するためのDashboardに関連する、ログイン後に操作されるLiveShell関係のページ。スペック、マニュアル、FAQなどのLiveShellの購入前に主に閲覧されるページ。テレビで紹介された場合に、アクセスが増えると予想されるのは、2つめの購入前に閲覧されるページです。逆に、1つ目のページのアクセスが増える(LiveShellの配信が一時的に急増する)上がるという場合は、正直、スケールアップぐらいしか短期間ではできそうにありません。ここの負荷があがった場合はどこまででもスケールアップで後追いで対応しようということで、c1.mediumまでスケールアップしておき、当日は張り付いてモニタリングだけすることにしました。#基本的に、メモリは常に余っている状態で、CPU負荷の方が高いため、HighCPUなインスタンスを選択しています。2つ目のページ群の負荷対策をどうするかということになります。LiveShell向けのページは全般的にすべて多言語対応されており、日本語、英語の両方の表示に対応しています。その言語切替などのためもあり、製品紹介などのページなども、他のページと同様に、基本的にテンプレートを読み込んで動的に毎回生成している状況でした。スペックといったページに集中した場合、そこがボトルネックになる可能性が高いのは明らかです。そのため、memcachedでキャッシュするとか、いくつか案を考えましたが、そもそもキャッシュをしたところで、動的なコンテンツになっている時点で、様々な箇所に負荷がかかる可能性があり、チューニングをするにしても慎重に行う必要がありそうで、間に合う気がしませんでした。いうわけで、もうすこしシンプルな手として、そういったページは、開発時は動的に生成、実際に本番環境に適用されるタイミングで、静的ページに書き出してデプロイという風に運用することに変更しました。この対策をすると、アクセスが急増したときに、nginxがどれくらいの負荷を捌けるかという問題のみに集中することができます。いうわけで、次はnginxからの静的ページ配信性能をどうするかを考えます。静的なファイルとはいえ、アクセス時にディスクから読み込まれるような事態になれば明らかに間に合いません。すると、メモリに乗っかっていることが前提になるので、メモリの使用状況を考えます。このインスタンスでは、動的部分を担当するアプリも動いているので、そちらが使っているメモリを差し引きます。これは動作実績を見ると、多いときでも600MB程度です。m1.smallでも1.7GBはメモリがあり、その他のプロセスやカーネルの利用量を見ても、1GB程度のメモリは常に空いている状態です。上記で生成された静的コンテンツを集計しても、100MBにも届きません。基本的にはnginxがディスクから配信する際はOS側のページキャッシュに任せるだけで、メモリに載った状態でディスクアクセスなしにファイルを配信してくれるはずです。ここまで検討したら、あとはnginxで配信できる性能をどこまで高めるかという問題です。m1.smallは1ECUということで、ここでも言及されているとおり、CPUを常につかえるわけではないインスタンスです。負荷がかかるときに、このインスタンスを増やしていくというのはナンセンスなので、メモリも足りていることをかんがえると、HighCPUなインスタンスを複数台用意して配信するのがいいだろうということになりました。いうわけで、abなどをつかって配信性能を測定して、最低でも2000req/sくらいのアクセスは耐えられるようにということで見積をして、c1.medium2台で充分だなとおもった後に、心の平穏のために盛って、c1.mediumを4台用意しました。実際の負荷WBSで紹介された場合、そのアクセスの増加ペースは想像以上に瞬間的です。大体紹介がはじまって、1-2分の間に、いつもは20req/sくらいのアクセスが、800req/sくらいにぐぐっと伸びました。その後、コーナー終盤までくると、1000req/sくらいまでピークのアクセスがきます。その後は、スーッとアクセスは減っていき、それでも2時間くらいは300req/sくらいのアクセスが観測されます。その後は順調にアクセスは減り、朝3-4時には50req/sくらいまで落ちました。その後は1日くらいかけて緩やかにアクセスは減っていき、4日目くらいには平常な状態に戻りました。WBSのおもしろいところは、放送翌日の8-10時です、あきらかにアクセスがまた増えます。一瞬ですが、300req/sくらいまで上がりました。これはおそらく、自宅でWBSを見て、出勤後にチェックという人がかなりいるからなのだろうな、と。50req/sそれ以降は平常に戻るという感じの流れでした。負荷としては、大体、CPU負荷で40-50%くらいがピーク時に出ただけで、応答速度も遅いときも600msくらいで、平均は200-300msくらいに落ち着いていました。4台用意しておけば、このくらいのアクセスであれば、まったく問題なくむしろオーバースペックだった感が漂いましたが、まあ落ちてうわーっとなるよりは全然良いし、数日、c1.mediumを立ち上げておいてもそれほど大きなコストではないのでよしとしました。まとめというわけで、負荷対策として、以下を行いました。・アクセスが増えると考えられるページに関しては、デプロイ時に静的なコンテンツを生成して、配信をnginxに任せる・nginxがページキャッシュを利用して、ディスクI/Oを発生させずに配信できるようにメモリ消費を調整する、もしくは、メモリが充分に確保できるインスタンスを使う・nginxの配信性能をベンチマークして予測されるアクセスに耐えられる程度にインスタンスを増やすという形で充分乗り切れました。動的な部分に関しても、ログイン画面や新規登録画面へのアクセスは若干増えましたが、基本的には予想通り、アクセスが大幅に増えることもなく、c1.mediumで充分に乗り越えることができました。おまけLiveShellサイトの構成のご紹介。スタンダードなAWSを使った構成(だと思っています)をしています。ELB—EC2(nginx+gunicorn)—RDS(MySQL)+EC2+EBS(KyotoTycoon)アプリは、基本的にPythonで書かれており、WEBフレームワークはWerkzeugというか、Flaskをベースとしたmyojinという独自フレームワークをつかっています。(これは実はBitBucketで公開しています。ドキュメントもなにもないですが。11.10が動作しており、そこにnginxをリバースプロキシとしておいて、同一インスタンス上でgunicorn経由でmyojinが起動されています。そのアプリが動いているEC2のインスタンスは、m1.smallが2台。KyotoTycoonは、LiveShellの状態など一時保存のためのKVSとしてm1.small上で動作しています。RDSもMySQLでMultiAZは有効になっているけれど、m1.smallインスタンスで動かしていて、特にリードレプリカなども用意していません。(そもそも、一般的なサイトにくらべて、LiveShellを操作するという機能は情報を永続化する必要がないので、SQLを発行する回数はかなり少ないという側面がありますが。)というくらいの上記の通りで、規模としては大変小さいというか、コストはあまりかけずに運営しています。これ以外に、LiveShellをリモートで配信状況をモニタしたり、逆に音量、画質など様々な設定をリアルタイムに操作する機能があり、そのサーバー側の機能を総称してDashboardと呼んでいます。こちらのツール的な部分の機能は、websocket(というか、Socket.IO)をつかってページを開いている間はTCPが常時接続されていたり、LiveShellとはUDPでやりとりをしてNAT越えを実現していたりという感じで、そのために、node.jsやPythonでかかれたデーモンが動いています。こちらも平常時は、m1.smallで動いており、わりと低い負荷で収まっています。MODEでコンパイルされ、1つのファイルにまとまっています。CSSに関しても、基本的に1つのファイルにまとめるようになっています。そのうえで、そういったファイルは、リビジョン番号ごとにディレクトリを変化させ、一度読み込むとキャッシュさせるために、長大(1年)なExpiresを設定しています。事前に静的ファイルはgzipに圧縮されており、nginxのgzip_staticによって配信されるようになっています。画像ファイルに関しては、おなじようなことができていないですが、こちらも続いてやりたいなぁとおもっています。このあたりによって、上のリクエスト数の数字は他のサイトに比べると、閲覧数の割に少なくなっている傾向にある可能性はあります。いう意味でも、この手の施策は、アクセス数の削減につながるので、負荷対策としてもそれなりの効果があるのではないかと思っています。採用情報Cerevoではエンジニアや広報など、様々な職種の採用活動を行なっています。IoTプロダクト開発やスタートアップ支援、企画、営業に関心が高い方からのご応募をお待ちしております。