AWSソリューションアーキテクト Paul Horvath氏が講演されるということで、JAWSの勉強会に参加してきました。しかし業務の都合で遅れて参加したため、氏の講演の前半は聞き逃してしまいました。とほほ orz
株式会社gumiのCTO 堀内さんによる『AWSによるソーシャルアプリ運用事例』も興味深い内容でした。
AWSによるソーシャルアプリの運用事例
- gumiはすべてのアプリケーションをAWSで運用している。
- 最初の占いはオープンして5分でサーバーダウンした。
- プログラムをチューニング? => 効果はある。が、限界がある。
- サーバーを増設? => 時間がかかる。ラックに空きもない。
- AWSがいいらしい、ということで導入した。
- Auto Scalingで負荷に合わせてサーバーの台数を自動調整できる。
- プログラムは1台のNFSにデプロイして、すべてのインスタンスで共有するようにした。
- Auto Scalingするとき、新しいインスタンスを起動するためのAMIを登録する必要があるが、プログラムを更新するたびにAMIを作り直すのはナンセンスなので、NFSに切り出した。
- RDSで手軽にMySQLを使える。
- 問題点
- プログラムが安定していないと、不安定な挙動による負荷の増大を検出してスケールしてしまう。=> プログラムが安定している必要がある。
- NFSサーバーの負荷問題
- ELBの使用をやめた(後述)ことでAuto Scalingを使いにくくなった。
- Auto Scalingはインスタンスの起動とELBへの登録を行ってくれるが、ELBの使用が前提になる。
- ELB自身のスケールアップ時に通信断が発生するので、ELBの使用をやめた。
- 10分間にレスポンスタイム10秒以上のリクエストが1000件あるとプラットフォームによってJOIN停止になる。
- およそ60万リクエスト/h(?)以上でスケールアップが発生する。
- Apache + mod_proxy_balancerに置き換えた。
- どうやら、あらかじめスケールアップしておくことで回避可能だということを知った。
- RDS
- メンテナンスウィンドウでIO Freezeが発生する。
- メンテナンスウィンドウを小さくするため、ディスク容量を小さくしたら容量が枯渇した! => ディスク容量は余裕を持たせよう。
- Multi-AZにより可用性がアップする。
- Multi-AZにするとメンテナンスウィンドウでIO Freezeが発生しない。
- RDSを前提とした設計が必要になる。
- gumiの現在の構成
- Load Balancer : Apache + mod_proxy : 2台
- Web Application Server : Apache : 2台〜20台(Auto Scalingは使っていない)
- Cache Server : Memcached : 1台
- DB Server : Tokyo Tyrant : 2台
- RDS
- NFS Server : 1台
-
- 全140台
- 最初はUS Eastを使っていたが、US WestやSingaporeに移行中
- US East 100台
- US West 20台
- Singapore 20台
- RDS 12台
