概要

クラウド環境（Amazon Web Services）を前提としてアプリケーション開発し，それを運用することはごく普通なものになりました。しかし，実際にシステムをサービス開始してみると，想定したパフォーマンスを達成できないことが多々あります。それはシステムにかかる負荷を正しく見積もっていないことに原因があるようです。本書では，クラウド環境での負荷試験のやり方や評価方法を解説します。筆者たちはさまざまなクラウド環境でのアプリケーションの開発と運用で実績を積んできました。その成果を余すことなく1冊にまとめました。

こんな方におすすめ

• AWSやオンプレミス，クラウドハイブリッド環境でシステムのパフォーマンスを測りたい方に。クラウド上のアプリの性能を引き出したい方に

著者から一言

本書執筆のきっかけは，2015年2月にレバレジーズ株式会社様主催の勉強会で，負荷試験に関する単独講演の機会をいただいたことでした。この講演自体，元上司である株式会社スピカの國府田勲氏のお膳立てにより（酒を飲んだときのノリで）実施に至ったものでした。
人前での単独講演は初めてで講演そのものはガチガチでしたが，講演時のスライド資料をSlideShareで公開したところ，日本オラクル株式会社の奥野幹也氏に取り上げていただいたことで数多くのエンジニアの皆様にも好評をいただきました。そのスライドを見た技術評論社の池本公平氏より連絡を受けたのですが，そこでも奥野氏による推薦があったということでした。その後，池本氏から『SoftwareDesign』誌の特集で「負荷試験実践 入門」の記事を連載（全4回）するチャンスをいただいたうえで，さらに今回の書籍執筆のお話をいただくこととなりました。
私自身のエンジニアとしてのスキルは，ほぼ携わってきた業務中心で培われてきたことで偏りが生じているため，執筆にあたっては当時同僚であった森下氏に共著を依頼しました。快く引き受けてもらえたことで，多くの部分が補完され，書籍として完成させることができました。最初の舞台を準備していただいたレバレジーズ株式会社様。すべての局面で常に「やっちゃえよ！」と後押ししていただいた國府田勲氏。ネット上ですぐに埋もれるかと思われたスライドに光を当てて推薦していただいた奥野幹也氏。誌面連載および書籍執筆の機会を与えていただいた池本公平氏。共著の森下氏。書籍執筆活動そのものをエンジニアに有益な業務とみなして全面的に協力してくれた株式会社ゆめみと，全体の査読・校正に多大なるご尽力をいただいたゆめみ関係者の皆様。そして勉強会，インターネット，雑誌，書籍といったすべての場でより良い技術・情報を求めノウハウをシェアするエンジニア文化と，それらに携わるすべての人々に深く感謝します。

サンプル

• サンプルPDFファイル1（737KB）

目次

Chapter1　間違いだらけの負荷試験とWebシステムの失敗事例

1.1 間違いだらけの負荷試験

• 1.1.1 ケーススタディ登場人物と状況
• 1.1.2 間違いだらけの開発スケジュール見積もり
• 1.1.3 間違いだらけの試験前提条件
• 1.1.4 間違いだらけの試験準備
• 1.1.5 間違いだらけの試験実施
• 1.1.6 間違いだらけの試験レポート

1.2 Webシステムの失敗事例

• 1.2.1 キャンペーンシステムの失敗事例
• 1.2.2 ECサイトリプレイスの失敗事例
• 1.2.3 図書館新着書籍検索システムの失敗事例

Chapter2　Webシステムの設計手法

2.1 Webシステムに求められる非機能要件としての可用性

• 2.1.1 可用性とは
• 2.1.2 複数のサブシステムが連結する場合の可用性について

2.2 可用性の高いシステムの設計方法

• 2.2.1 システムの冗長化
• 2.2.2 システムのスケール対応

2.3 Webシステム設計の歴史

• 2.3.1 オンプレミス時代のシステム構築1（低可用性／低スケール性）
• 2.3.2 オンプレミス時代のシステム構築2
• 2.3.3 クラウド時代のシステム構築

2.4 この章のまとめ

Chapter3　負荷試験の基本知識

3.1 負荷試験の目的

• 3.1.1 オンプレミス時代の負荷試験の目的
• 3.1.2 クラウド時代の負荷試験の目的

3.2 負荷試験におけるシステムの性能指標

• 3.2.1 スループット
• 3.2.2 レイテンシ
• 3.2.3 複数のサブシステムにより構成されたケースにおけるスループットとレイテンシ

3.3 システム性能改善の基礎知識

• 3.3.1 スループットの改善
• 3.3.2 レイテンシの改善

3.4 より良い負荷試験が実施されていることを示す指標

• 3.4.1 良い負荷試験であることを示す指標
• 3.4.2 悪い負荷試験の指標

3.5 この章のまとめ

Chapter4　負荷試験のツール

4.1 負荷試験で利用する3つのツール

4.2 攻撃ツールと選択基準

• 4.2.1 攻撃ツールとは
• 4.2.2 攻撃ツールによるリクエスト生成と実際のユーザーアクセスによるリクエストの違い
• 4.2.3 攻撃ツールの選択基準
• 4.2.4 対象のシステムに合った攻撃ツールを利用する

4.3 Apache Benchの使用方法

• 4.3.1 Apache Benchの特徴
• 4.3.2 導入方法
• 4.3.3 主なオプション
• 4.3.4 実行結果サンプル

4.4 Apache JMeterの使用方法

• 4.4.1 特徴
• 4.4.2 JMeterを使った攻撃システムの構成例
• 4.4.3 導入方法
• 4.4.4 JMeter実行結果サンプル

4.5 Locustの使用方法

• 4.5.1 特徴
• 4.5.2 導入方法
• 4.5.3 シナリオを書く
• 4.5.4 Locustの起動
• 4.5.5 実行のサンプル

4.6 Tsungの使用方法

• 4.6.1 特徴
• 4.6.2 導入方法
• 4.6.3 シナリオ記述，試験実施
• 4.6.4 実行結果サンプル

4.7 モニタリングツールとプロファイリングツール

4.8 topコマンドとnetstatコマンド

• 4.8.1 topコマンド
• 4.8.2 netstat コマンド

4.9 CloudWatchの活用

• 4.9.1 CloudWatchのグラフの注意点

4.10 Xhprofの使用方法

• 4.10.1 インストール方法
• 4.10.2 Xhprofを実行したサンプル

4.11 New Relicの導入方法

• 4.11.1 New Relicの導入
• 4.11.2 New Relicの機能紹介

Chapter 5　負荷試験の計画

5.1 負荷試験対象システム

5.2 負荷試験計画の立案

• 5.2.1 スケジュールの決定
• 5.2.2 負荷試験の目的の設定
• 5.2.3 前提条件の整理
• 5.2.4 目標値の決定
• 5.2.5 利用する負荷試験ツールの選定
• 5.2.6 試験実施環境の決定
• 5.2.7 負荷試験シナリオの決定

5.3 この章のまとめ

Chapter6　負荷試験の準備

6.1 負荷試験対象環境構築

• 6.1.1 対象環境のセットアップ
• 6.1.2 負荷試験専用の試験対象エンドポイントの追加

6.2 負荷試験ツールの準備

• 6.2.1 攻撃サーバの構築と攻撃ツールのインストール
• 6.2.2 シナリオの作成
• 6.2.3 シナリオ作成時の注意事項

6.3 関連システムの部門間調整

• 6.3.1 連携先システムの調整

6.4 クラウド事業者の各種制限の緩和申請

6.5 この章のまとめ

Chapter 7 負荷試験の実施1～試験実施とボトルネックの特定

7.1 負荷試験実施のステップとは

• 7.1.1 全体に対して一度に負荷試験を実施した場合
• 7.1.2 段取りに従った負荷試験

7.2 ステップ1：ツールや環境の検証

• 7.2.1 対象のシステム
• 7.2.2 Plan
• 7.2.3 Do
• 7.2.4 Check
• 7.2.5 Action

7.3 ステップ2：Webフレームワークの検証

• 7.3.1 対象のシステム
• 7.3.2 Plan
• 7.3.3 Do
• 7.3.4 Check
• 7.3.5 Action

7.4 ステップ3：参照系の性能の検証

• 7.4.1 対象のシステム
• 7.4.2 Plan
• 7.4.3 Do
• 7.4.4 Check
• 7.4.5 Action

7.5 ステップ4：更新系の性能の検証

• 7.5.1 対象のシステム
• 7.5.2 Plan
• 7.5.3 Do
• 7.5.4 Check
• 7.5.5 Action

7.6 ステップ5：外部サービス連携の性能の検証

• 7.6.1 対象のシステム
• 7.6.2 Plan
• 7.6.3 Do
• 7.6.4 Check
• 7.6.5 Action

7.7 ステップ6：シナリオ試験

• 7.7.1 スループットの評価について
• 7.7.2 対象のシステム
• 7.7.3 Plan
• 7.7.4 Do
• 7.7.5 Check
• 7.7.6 Action

7.8 ステップ7：スケールアウト試験準備

• 7.8.1 対象のシステム
• 7.8.2 Plan
• 7.8.3 Do
• 7.8.4 Check
• 7.8.5 Action

7.9 ステップ8： スケールアップ／アウト試験（ステップ1 ～ステップ6の回帰試験）

• 7.9.1 対象のシステム
• 7.9.2 スケールアップ／スケールアウトの例
• 7.9.3 Plan
• 7.9.4 Do
• 7.9.5 Check
• 7.9.6 Action

7.10 ステップ9： 限界性能試験（ステップ1 ～ステップ6の回帰試験）

• 7.10.1 対象のシステム
• 7.10.2 Plan
• 7.10.3 Do
• 7.10.4 Check
• 7.10.5 Action

Chapter 8 負荷試験の実施2～原因分析とシステムの改善作業

8.1 システムのボトルネックの特定

8.2 攻撃ツールボトルネックの原因と対策

• 8.2.1 サーバや攻撃ツールの設定不備
• 8.2.2 攻撃シナリオ不備
• 8.2.3 攻撃サーバ能力不足
• 8.2.4 攻撃サーバ設置ネットワーク不備
• 8.2.5 早見表

8.3 Webサーバボトルネックの原因と対策

• 8.3.1 OSやミドルウェアの設定不備
• 8.3.2 Webフレームワークの問題
• 8.3.3 アプリケーションの不備
• 8.3.4 サーバリソース能力不足
• 8.3.5 早見表

8.4 キャッシュサーバボトルネックの原因と対策

• 8.4.1 キャッシュ利用方法の不備
• 8.4.2 サーバリソース不足
• 8.4.3 早見表

8.5 DBサーバボトルネックの原因と対策

• 8.5.1 DB設計不備
• 8.5.2 DB利用アプリケーションの不備
• 8.5.3 サーバリソース不足
• 8.5.4 早見表

8.6 外部サービスボトルネックの原因と対策

• 8.6.1 外部システムとの連携方法の不備
• 8.6.2 外部システムの性能不足
• 8.6.3 早見表

Chapter9　負荷試験レポートの作成

9.1 負荷試験結果の最終確認

• 9.2 目標値に対する適正な構成を選定する
• 9.2.1 システムの余裕の取り方について

9.3 負荷試験レポート作成

• 9.3.1 レポートに必要な項目
• 9.3.2 負荷試験レポートにおけるシステム利用状況の添付が招きやすい問題

9.4 この章のまとめ

Chapter10　負荷試験実践のケーススタディ

10.1 この章で試験するシステム

• 10.1.1 アプリケーションの機能要件
• 10.1.2 システムの要件
• 10.1.3 システム設計
• 10.1.4 負荷試験における前提条件

10.2 JMeter＋XhprofによるPHPアプリケーションの負荷試験事例

• 10.2.1 負荷試験計画の立案
• 10.2.2 試験実施1： ツールとWebフレームワークの検証（まずは順調な滑り出し）
• 10.2.3 試験実施2：シナリオ試験まで（順調な試験経過）
• 10.2.4 試験実施3： スケールアップ／アウト試験（スケール性能限界が意外と低いかも?）
• 10.2.5 試験実施4：限界性能試験（限界突破!!）
• 10.2.6 適正な構成の選定と試験レポート

10.3 Locust + New RelicによるNode.jsアプリケーションの負荷試験事例

• 10.3.1 1日目前半：ツールや環境の検証
• 10.3.2 1日目後半：アプリケーションシステム全体の検証
• 10.3.3 2日目前半：続・アプリケーションシステム全体の検証
• 10.3.4 2日目前半：スケーラビリティの検証 ～ 2倍にしてみる
• 10.3.5 2日目後半： スケーラビリティの検証―― Webサーバをスケールさせていくと次にボトルネックになるのはどこか？
• 10.3.6 3日目：さらなる最小構成の検証

Chapter11　巻末資料

11.1 用語説明

• 11.1.1 一般用語
• 11.1.2 AWS用語・アイコンについて

11.2 JMeterシナリオ解説

• 11.2.1 スレッドグループの作成
• 11.2.2 シンプルコントローラによるグループ化
• 11.2.3 Dummy user_idの生成
• 11.2.4 ユーザー定義変数の利用
• 11.2.5 HTTPリクエストの実行
• 11.2.6 HTTPレスポンスからuser_idの取得
• 11.2.7 シナリオの一部を○%の確率で実施
• 11.2.8 シナリオの一部を○回繰り返す
• 11.2.9 統計レポートの表示

11.3 Locustシナリオ解説

• 11.3.1 Locustの基本
• 11.3.2 第10章で用いたシナリオ

11.4 間違いだらけの負荷試験 解説編

サポート

現在サポート情報はありません。