1. RDS！スケールアップ前の
アプリチューニング
（ざっくり版）
2013年8月31日
朝永 将
tomonaga (at) birdsong.jp

2. 自己紹介
• LAMP一筋13年
• 2010年∼ 株式会社NEO COSMIC
- ビジュアルノベルアプリ『牡丹の庭』他、11タイトルの開発
• 2013年∼ フリーランス
- ソーシャルアプリ開発
- 講師・ITアドバイザー
• 小鳥好き
- Facebook: masaru.tomonaga

3. こんな運用してませんか？
★ 「DB重いなぁ。。」
• 「取り急ぎスペックあげておきますか∼」
•
（以降、何度か繰り返し）
★ 「いやー、やっぱDB厳しいなぁ。。」
• 「これ以上スペック上げられません!」
★ 「」

4. ('A`)ｳﾞｧｰ

5. 突然の死！

6. フロント（Webサーバ）は
スケールしやすいが、
DBは・・・！？

7. Webサーバ(EC2 etc...)
• スケールアウト・スケールアップして力
技で捌く

8. DBサーバ(RDS)
• データの整合性を考慮すると、単純にRDSを
追加するだけでは対応できない。
• Webよりスケールアウトの難易度が高
い。
• スケールアップするにも限界がある。
（4xlargeとか）

9. アプリ側を
改修しないと・・・

10. • とりあえず勘で直してみる
• 工数足りません！
• 予算ありません！
• 実装で担当者しか改修できません！
（※担当者逃亡中）

11. だめです！

12. Amazonさんに
問い合わせる

13. AWSではアプリ改修
してくれません！
（ヒントは頂けるかもしれないけど…）

14. ググる。

15. [RDS 重い どうにか]

16. 神頼み！

17. がんばって、どうに
かしてください。
（棒読み）

18. まじめな話
どうすれば良い？

19. 技術的なところ(1)
• slowlogを出さない
• Explainで確認→クエリ最適化
• テーブルパーティショニング
• 1億レコード以上のテーブルを作らない
設計（メンテも手間！）

20. 技術的なところ(2)
• ランニングコストが掛かりますが…
• KVSへ一部移行（ElastiCacheなど）
• リードレプリカの活用
• 水平分割（一定のレンジごとにサーバ
を分ける）

21. マネージメント的なところ(1)
• 対・エンジニア向け
• 少なくともslowlogは出させない！
• とりあえず動けば良い→技術的負債
• 実装担当者のマインドを育成（プロダ
クトに対する責任）

22. マネージメント的なところ(2)
• 対・上長、役員向け
• クラウドだから簡単に拡張できるんでしょ？
• DB高負荷時のリスク説明（図表を書いて！）
• 予算要求は松竹梅方式で
• 定期的に負荷データを収集・共有する

23. 大事な事なので2度言
います

24. slowlogを出さない

25. 出したままスケール
してもメリットを活
かせない

26. 技術的負債

27. 体感的には年利40%

28. 出資法違反ですね！

29. 金利だけ返している
状態になり得る

30. slowlog ダメ、ゼッタイ。

31. 今日はありがとうご
ざいました！