RDS!スケールアップ前のアプリチューニング(ざっくり版)

3,785 views
3,489 views

Published on

Published in: Technology

RDS!スケールアップ前のアプリチューニング(ざっくり版)

  1. 1. RDS!スケールアップ前の アプリチューニング (ざっくり版) 2013年8月31日 朝永 将 tomonaga (at) birdsong.jp
  2. 2. 自己紹介 • LAMP一筋13年 • 2010年∼ 株式会社NEO COSMIC - ビジュアルノベルアプリ『牡丹の庭』他、11タイトルの開発 • 2013年∼ フリーランス - ソーシャルアプリ開発 - 講師・ITアドバイザー • 小鳥好き - Facebook: masaru.tomonaga
  3. 3. こんな運用してませんか? ★ 「DB重いなぁ。。」 • 「取り急ぎスペックあげておきますか∼」 • (以降、何度か繰り返し) ★ 「いやー、やっぱDB厳しいなぁ。。」 • 「これ以上スペック上げられません!」 ★ 「」
  4. 4. ('A`)ヴァー
  5. 5. 突然の死!
  6. 6. フロント(Webサーバ)は スケールしやすいが、 DBは・・・!?
  7. 7. Webサーバ(EC2 etc...) • スケールアウト・スケールアップして力 技で捌く
  8. 8. DBサーバ(RDS) • データの整合性を考慮すると、単純にRDSを 追加するだけでは対応できない。 • Webよりスケールアウトの難易度が高 い。 • スケールアップするにも限界がある。 (4xlargeとか)
  9. 9. アプリ側を 改修しないと・・・
  10. 10. • とりあえず勘で直してみる • 工数足りません! • 予算ありません! • 実装で担当者しか改修できません! (※担当者逃亡中)
  11. 11. だめです!
  12. 12. Amazonさんに 問い合わせる
  13. 13. AWSではアプリ改修 してくれません! (ヒントは頂けるかもしれないけど…)
  14. 14. ググる。
  15. 15. [RDS 重い どうにか]
  16. 16. 神頼み!
  17. 17. がんばって、どうに かしてください。 (棒読み)
  18. 18. まじめな話 どうすれば良い?
  19. 19. 技術的なところ(1) • slowlogを出さない • Explainで確認→クエリ最適化 • テーブルパーティショニング • 1億レコード以上のテーブルを作らない 設計(メンテも手間!)
  20. 20. 技術的なところ(2) • ランニングコストが掛かりますが… • KVSへ一部移行(ElastiCacheなど) • リードレプリカの活用 • 水平分割(一定のレンジごとにサーバ を分ける)
  21. 21. マネージメント的なところ(1) • 対・エンジニア向け • 少なくともslowlogは出させない! • とりあえず動けば良い→技術的負債 • 実装担当者のマインドを育成(プロダ クトに対する責任)
  22. 22. マネージメント的なところ(2) • 対・上長、役員向け • クラウドだから簡単に拡張できるんでしょ? • DB高負荷時のリスク説明(図表を書いて!) • 予算要求は松竹梅方式で • 定期的に負荷データを収集・共有する
  23. 23. 大事な事なので2度言 います
  24. 24. slowlogを出さない
  25. 25. 出したままスケール してもメリットを活 かせない
  26. 26. 技術的負債
  27. 27. 体感的には年利40%
  28. 28. 出資法違反ですね!
  29. 29. 金利だけ返している 状態になり得る
  30. 30. slowlog ダメ、ゼッタイ。
  31. 31. 今日はありがとうご ざいました!

×