失败事例にみる顿产の负荷试験の重要性
- 2. 自己紹介 大西一嘉 株式会社マーベラス 開発本部開発部 チーフアーキテクト / DBアーキテクト 職業：提督でありエンジニア 趣味：艦娘たちを愛でる 他にもNYの地下にもぐったり、 蠣崎氏で全国統一したり、 全米や全欧で運送業を営んだり、 フォーリナーの撃退をしてます 目標：全艦娘コレクション 目標達成まであと4名
- 4. ゲームタイトルにおける負荷 ユーザビリティに重きを置くゲームタイトルにおいて負荷とは、非常にクリティカ ルな問題となります。負荷によって引き起こされる問題としては??? ? レスポンスの遅延による厳しい苦情 ? 登録?変更の反映不能によるデータ欠損 ? そもそもゲームができない ゲームタイトルは、ユーザにより支えられている側面が他のWEBシステムより 強いため、負荷によるユーザ不利益はそのまま収益につながります。
- 6. 限界や兆候を知ることが重要 漫然と負荷試験を行っても意味がありません。負荷試験で知るべき内容は3つ です。 ? 想定負荷に耐えられる事 ? システムの限界点を知る事 ? システムが限界点を迎える前に出る兆候を知る 事 想定負荷に耐えられる事は当然ですが、システムの限界点を知ることでサー バ増設?減設計画が立てやすくなりますし、急な負荷がかかったとしても、兆候 が出ていなければ対応までの時間が稼げます。 今後の運用に余裕を持つことができるようになります。
- 12. 弊社における失敗事例① SQL－データノード間での転送量がネックになっている以上、原因はSQL周りにある はずです。そのため、一つずつ使用しているSQLを外して、ログインを繰り返し、問題 になっているであろうSQLをあぶり出します。あぶりだした結果、一つのSQLを発見し ました。 原因判明 SELECT * FROM t_community_user AS tcu JOIN t_user AS tu ON tcu.user_id = tu.user_id ※ウロ覚えですが、ログインするたびに全コミュニティに紐づくユーザのログイン状況を取得するというものだったのは覚えてます。 そりゃ転送量喰うよ、全データだもの。 MySQL Clusterで絶対やったらダメなパターン
- 13. 弊社における失敗事例① 反省点 ? 「すでに安定稼働しているよ」という言葉を信じ て、負荷試験を省いてしまった。 ? 負荷試験さえすれば、発見できた問題だった。 ? MySQL Clusterの特性を当時知らなかった。 ? 全てのSQLについて負荷チェック?スロークエリ チェックするべきだった。
- 17. さて現状は分かったので、プロジェクトタイトルの立て直しの方針を決めます。 という制約がほぼトップダウンで決定されているため、選択肢は運用実績が高く且つ 確実に組めて修正が最小限に抑えられるであろうMySQLによるシャーディングに確 定、後は物理性能で抑え込むという方針が確定されました。 弊社における失敗事例② プロジェクトの立て直し ? NoSQLクラスタは悪くないだろうけど、ほぼRDBMS への変更が確定 ? MySQL Clusterは、運用実績とクラスタという名前で NoSQLを連想するのでダメ ? 1か月以内に無事故で再開
- 20. 構成変更とPHPの修正を行い、再度負荷試験を実施します。今回はリリース中のア クセスログを参考にユーザの動きをチュートリアルを含めて再現しました。 弊社における失敗事例② シナリオ負荷試験の実施 ? 新規登録 ? チュートリアル ? その後アクセスログから推定されるユーザの動 きを高速で永久ループ 以上の動きを再現したJ-materシナリオを作成し、負荷サーバを100台ほど並べて負 荷を掛け、落ちた状況を再現します。このシナリオで、登録からヘビーユーザまでの 流れを再現しつつ、現構成で問題ないことを確認していきます。
- 21. 徹底的に無慈悲な負荷をかけることで、今回の障害における問題点が見えてきまし た。 弊社における失敗事例② 負荷試験の結果 ? WEBサーバリミテッドなシステムである ? DBコネクション数が異常に増大する 瞬間的にMAXまで食い尽くす。300でも3000でも30000でも ? 増大したコネクションエラーの発生により、WEB のLAの暴走が始まる ? MySQLサーバの負荷はスカスカ。いくら負荷を かけても快調そのもの
- 23. 弊社における失敗事例② 反省点 ? データ密度?アクセス密度を適切に見積れずに、 最初の負荷試験において平均的に分散させて しまった。 ? 負荷試験におけるユーザ行動シナリオが甘 かった。 ? NoSQLの知見が足りてなかった。 ? DBMSへの接続コーディングにおいて間違った 知識を有していた。