aws_summit_autoscale_game.md

AutoScaling ＆ Game

対象

• 恋愛ソーシャルゲーム
• アバター
• ６プラットフォーム

特徴

• 朝夕多い
• 月一イベント
• アバター合成は高付加
• Webサーバとアバター合成サーバ

苦労

• 手動スケールアウト
• 障害対応
• 追加に時間が掛かる（30分〜２時間）

Autoscaleを利用するために

• サーバ構築自動化
• スケールイン時のデータの保持

AMIでもいけるけど…

• 複数プラットフォーム対応厳しい
• 更新大変
• Chef入れた
• でも、Chef20分かかる…
• 共通部分だけAMI化したことで5分になった

構成

• 各AZに一台はAutoscale対象外

問題

• 価格が高い
• リザーブドインスタンス検討→変化に追従できないかも…、事前に決めてしまうの難しい…
• スポットインスタンス利用

スポットインスタンス

• 価格が高くなって起動しなくなるかも…
• 価格情報の監視
• ZABBIXで価格監視
• アラートで状況把握

Autoscale + Spot

• Configの設定だけで入札額変えられる
• 入札できない場合はLaunchConfigを入れ替えるだけにしている
• Ondemand併用
• Spot55%,Ondemand45%

スポットインスタンスの利用者が増えてきた？

• イベント時に一気に確保すると自分たちで価格上げてる
• LaunchConfig切り替えの自動化
• Zabbix価格の変動を検知して、Jenkinsで変更？

技術面

アバター合成サーバの負荷対策

• イベント時に着替え頻発
• 生成済み画像があればそのままなければImageMagickで生成
• 今までNASマウントで画像共有
• S3をマウントしてみた
  • 書き込み遅い、高負荷時エラー
• ローカルディスクだと生成済み画像の共有できない…
• GlusterFS
  • クラスタ構築
  • 追加するためには既存メンバから追加コマンドを叩く必要がある
  • AWSだとIPが自動で割り振られるためIP指定はできないのでHost名で
  • Autoscaleで使うには
    • 生存ノードの判定
    • 追加削除の自動化
    • Serf使った
    • serf membersで生存ノード取得
    • 新しいノードは定期的に吐出されるS3上のメンバ情報をとってJOINをかける

Glusterのクラスタ管理にSerfはあってるけど、今回のユースケースは微妙っぽい気が…

ログ管理

• Fluentd
• 中継サーバで格納先の集中管理
• タイトル増にはDockerで