読者です 読者をやめる 読者になる 読者になる

第3回AWS User Group - Japan勉強会

AWSソリューションアーキテクト Paul Horvath氏が講演されるということで、JAWSの勉強会に参加してきました。しかし業務の都合で遅れて参加したため、氏の講演の前半は聞き逃してしまいました。とほほ orz

株式会社gumiのCTO 堀内さんによる『AWSによるソーシャルアプリ運用事例』も興味深い内容でした。

AWSによるソーシャルアプリの運用事例

  • 株式会社gumi CTO 堀内氏
  • Twitter: horiuchi
  • 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台