2017/12/9に実施したGGLTにて発表した資料になります。 内容はミドルウェアの性能試験や障害試験の概要や考え方についてまとめております。 LT用に作ってますので詳細(手順等)は割愛しております。

1. 我流ミドルウェア性能・障害試験の心得
@GGLT vol.4 2017/12/9
株式会社Aiming Osakaスタジオ インフラチーム 菅野 明洋

2. 自己紹介
• 名前
• 菅野明洋(すげの あきひろ)
• 所属
• 株式会社Aiming
インフラチーム

3. 免責事項
• 本発表における見解は、
私自身の見解で行っております。
• 所属する会社、団体の見解を反映したものでは
ありませんので、ご了承ください。
内容の半分くらいは趣味です

4. 第1章 はじめに

5. 皆さん、ミドルウェア選定時に

6. どのように選んでますか？

7. ざっくりまとめてみた
• 欲しい機能がある
• 性能が高い
• 障害に強い
• 新しい(流行)
今回の対象

8. 個人的には新しいとか今話題とか

9. 勢いで導入するのも好きだけど

10. 大型案件とかでは、
そのような博打はうてませんよね

11. 途中で要件満たせずに
開発手戻りしたくない

12. コアな部分がダメだったら
ほとんど0から作り直し

13. リリース後に
ダメって気がついたら悲惨

14. サービスリリース後も
安心して寝たい

15. ということで

16. 開発前にすることをまとめました

17. 第2章 チェック項目

18. 機能確認
• 開発予定のシステムに必要な機能があるか
• ミドルウェアを用いて工数が削減できるか
• etc(アプリケーションの要件次第)

19. 性能要求1
• 負荷試験
• スループット
• どの程度捌けるか
• レイテンシ
• どの程度早く応答できるか
• ユーザビリティ
• 高負荷時のエンドユーザへの影響

20. 性能要求2
• 信頼性
• 定められた仕事を果すこと
• 可用性
• 継続稼働出来ること
• 保守性
• 資源(ソフト・ハード両方)の保守が行われた際に機能を保持できること
• 保全性、整合性、統合性、一貫性
• システムやデータが無矛盾であること
• 機密性
• 不正アクセスがされにくいこと

21. 運用要求
• バックアップ・リストア
• サーバの増減設
• 無停止で行けるかどうか
• 監視方法
• リソース・死活監視が可能かどうか
• 監視に必要な機能がない場合は自前で実装

22. つまり

23. 速い
頑丈
便利
かどうか調べる

24. 第3章 試験項目例

25. 試験一覧
• 性能試験
• 限界性能試験
• 拡張限界性能試験
• シナリオ試験
• 障害性能試験
• サーバダウン試験
• フェイルオーバー試験
• 復旧試験

26. 最小限界性能試験
• 最小構成での性能値
• スループットなどの性能の確認
• リソース監視も導入しハードウェアの負荷も計測
• 他の性能試験での基準値
• 例
• ゲームサーバの負荷試験をした際にも
ボトルネック調査の参考に出来る

27. 拡張限界性能試験
• 台数に比例して性能向上するか？
• 台数に比例しない場合はボトルネックを確認
• 仕様上台数が増えても性能が向上しない実装もある
どのように実装すれば、効果的なのか性能特性も把握

28. シナリオ試験
• 良くあるゲームシステムに模した試験
• 様々な負荷のかけ方を織り交ぜる
• 得意なことと苦手なこととを把握
• 最適化方法の模索
ミドルウェア毎に得意なことは違うので性質を把握する

29. サーバダウン試験
• 意図的にサーバやミドルウェアを落とす
• 落ちた後にどのように破損するか確認
• 実際の物理障害などで起きる事柄を確認する
つまり、ノウハウの蓄積

30. フェイルオーバー試験
• 障害を発生させ切り替わるか確認
• 切り替わりまでの時間の確認
• データ破損の有無の確認

31. 復旧試験
• 意図的にシステムを破損し復旧させる
• 障害の予行演習
• 事前にどこまで復旧できるか確認

32. 障害試験おまけ
• 負荷試験ソフトウェアの処理ログから、
ミドルウェアのあるべき状態との差を確認
• 自作のツールで整合性をチェック
• どこまで正しく処理されたのか？
• データ巻き戻りが無いか？
• etc

33. 第4章 おやくそく

34. おやくそく
• 基本的にデータを取る時は複数回取ること
• データのブレや偶然もあるため各項目10回以上
• 比較対象は基本的に条件を変えないこと
• 条件や構成が変わるとデータの意味が変わる
• システムは相乗りさせない
• 何が悪いのか判別しにくいため

35. 第5章 試験中に見ること

36. 全ての事象に理由を発見する

37. 性能値の頭打ち
• 性能値の頭打ちはなぜ置きたのか？
• サーバの性能が足りない？
• CPU
• Memory
• Disk IO
• Network
台数を増やしても
線形に上昇しない

38. 負荷試験クライアントの性能が
足りていないこともあるので注意

39. 大体はリソース監視の
グラフを見ればわかる

40. 例：とあるクラスタシステム
一台だけ通信量が倍

41. この試験では
1台のサーバに処理が集中して
台数に応じた性能が出なかった

42. 何が言いたいかと言うと

43. 意味も分からず
データだけ取っても意味が無い

44. 個人的には出てきたデータに
考察と根拠を加えることが重要

45. また、一人で行うと思考が偏るため
客観視する人も居たほうが良い

46. これは全ての試験でも
言えると思います

47. ご静聴ありがとうございました