アプリケーション性能を管理するのに必要なこと

ITproActive製品選択支援セミナー
アプリケーション性能を管理するのに必要なこと
株式会社ビッグツリーキャピタル
SI事業部
高安厚思
1Copyright (C) 2015 Atsushi Takayasu All Rights Reserved.

1 2 3 4 5自己紹介
高安厚思
▌ 活動領域・キーワード
▌ ２０年にわたり、ソフトウエアエンジニアリングを適用した
システム開発やコンサルティングに携わる。
▌ 最新技術を適切に利用した、柔軟なシステムの構築、
品質管理を中心として技術マネージメントなどを主要テーマとして活動。
▌ 開発方法論、アーキテクチャ設計コンサルティング、システム全体設計を
得意分野とする。
▌ 東京電機大学非常勤講師、SQuBOK設計開発領域検討委員、
ITSS-DS検討委員
▌関連事例
▌ ソーシャルアプリケーション構築プロジェクト性能分析
▌ B2B ECサイト移行プロジェクト性能分析
▌ 公共機関性能改善プロジェクトアーキテクト
その他多数

1 2 3 4 5対外活動
最近の著書、訳書
▌ 「システム設計の謎を解く（ソフトバンク）」
▌ 「StrutsによるWebアプリケーションスーパーサンプル（ソフトバンク）」
▌ 「Seasar入門[（ソフトバンク）」
▌ 「Javaルールブック（エクスメディア）
▌ 「ITアーキテクトのためのシステム設計実践ガイドアーキテクチャ編（日経
BP）」など。
連載記事執筆
▌ 日経SYSTEMS誌「Webアーキテクチャ再入門」
講演
▌ SODEC ミッションクリティカル開発
▌ 日本テクノセンターセミナー講師
▌ UML Forum講師
▌ 日経BP社 ITアーキテクトのためのシステム設計フォーラム特別講演講師
▌ Developers Summit 2013 Summer
▌ QCon 2014
▌ ITpro Active製品選択支援セミナー

1 2 3 4 5会社案内
▌社名：株式会社ビッグツリーキャピタル（Big Tree Capital.LTD.）
▌Webサイト：http://www.bt-capital.com
▌サービスメニュー：
▌ テクノロジー
▌ システムインテグレーション（基幹系システム、ECサイト構築等）
▌ プラットフォーム（AWS、Solr、Hadoop、仮想化基盤等）
▌ コンサルティング
▌ IT戦略コンサルティング（ビジネスモデリング、TCO削減等）
▌ プロジェクトマネジメント（PMO/PgMO、IT調達支援等）
▌ 技術コンサルティング（アーキテクチャ設計、技術検証等）

1 2 3 4 5アジェンダ
▌1 性能とは
▌2 性能を決定する要素
▌3 性能改善の技術
▌4 ライフサイクルと性能
▌5 結論のようなもの
▌付録ライフサイクルと性能の詳細

1 性能とは
Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 6

1 2 3 4 5性能にまつわるよくある話
▌性能に関するステークホルダは多岐にわたり、性能にかかわる要素も
多いため、以下のような会話がされることがある。
アプリケーションとしては十分に
テストしているので問題ない。
十分なシステムリソースがないのでは？
リソースが空いている状態なので、
アプリケーションの問題では？
インフラ担当社アプリ担当社
責任範囲が不明確なため、お互いに疑心暗鬼になりやすい

1 2 3 4 5性能とは
▌『性能』という言葉の定義を明確にし、ステークホルダー間で同意し
ておくことが重要
性能は非機能要件（上記の定義、ハードウェアコストの制約）によって
あらわすことができる。
オンライン
アプリ
 レスポンスタイム（処理時間、応答時間）
 スループット（同時アクセス数）
バッチ
アプリ
 処理時間
 処理可能データ量
同時アクセス数と処理時間はトレードオフ
オンラインバッチの場合、オンラインの
影響に留意

1 2 3 4 5性能を考える上での原則
▌性能を設計、改善する場合には守るべき原則がある
何事も計測すべし
ボトルネックを改善せよ
仮説検証を繰り返せ
この原則を無視した施策は効果がでにくい

2 性能を決定する要素

1 2 3 4 5性能を決定する要因・要素
▌粒度の異なる複数の要因・要素によって性能が決まる
性能は階層の異なる複数の要因によって決定され、
システムリソースがボトルネックとして表れる
要因
要素
計算量、計算処理量、リソースの利用方法
性能を構成する要素（システムリソース）
影響
観測可能
観測困難
推測

1 2 3 4 5性能を決定する要因
▌性能を決定する要因は、外的要因、内的要因、ミドルウェア特性、
アプリロジックに大別できる
複数の要因によって性能が決定される
外的要因
内的要因
ミドルウェア
特性
アプリ
ロジック
同時アクセス数
データ量
処理内容
システムリソースの利用方法
処理内容
システムリソースの利用方法

1 2 3 4 5性能を決定する要素
▌性能を構成する最終要素
▌CPU等のシステムリソースがボトルネックになって、
性能の上限が決まる
CPU
メモリ
ディスク
N/W
 同時アクセス数の増加
 計算量の増加
 データ量の増加
 メモリ確保の増加
 CPU待ち時間の発生
 スワップの発生
 GCの発生
 メモリ不足による
システムダウン
 アクセス特性
 アクセス待ち時間の
発生
 アクセス待ち時間の
発生
システム
リソース
要因現象

3 性能改善の技術

1 2 3 4 5性能改善の技術
▌ システムリソースのボトルネックを改善するためには以下のような技術が有効
圧縮
キャッシュ
分散
計算量の減少
同じデータや構造の繰り返しを別の構造で
表現することによって、データ量を削減する
繰り返し利用されるデータをアクセス速度の
高いリソースに配置することによって、
アクセス速度を向上させる
ボトルネックになるリソースを複数準備し、
それぞれ並列で処理させることによって、
ボトルネックを解消する
ループの回数やデータ構造を変更することに
よって、計算量を減少させる
これらの技術を直接あるいは間接的に利用し、性能を
維持する。

1 2 3 4 5分散方法
▌システムリソースのボトルネックを解消する手段として、
「分散」が用いられる
ステートレスの場合
ステートフルの場合
 状態に依存せず振り分け先を決定できる。
 処理するノードを増加させ、振り分けを行うことで実現する。
 振り分け装置（HW/SW）の性能に依存するがスケールしやすい。
 例）ロードバランサーによるWebサーバの分散
 状態に依存していて、単純に振り分けができない。
振り分けロジックと振り分けに必要な情報によって振り分けを
行うことで実現する。
 分散先を決定するノードによる処理がボトルネックになり、ス
ケールしにくい。
 例）ユーザIDをキーとするシャーディングによる
DBサーバの分散

4 ライフサイクルと性能

1 2 3 4 5ライフサイクル
▌アプリケーションの性能を管理するには各工程で性能を
意識する必要がある
要件定義
設計
実装
テスト
運用
 性能の定義
 性能を表す非機能要件
 アーキテクチャ設計（性能設計）
 リリース・拡張方式設計
 性能監視設計
 性能・負荷・限界テスト及び改善
 アルゴリズム選択
 単体レベルの性能計測・改善
 性能監視・改善
 拡張計画とリリース
本当の意味で、性能を管理するためには全工程での配慮が必要

5 結論

1 2 3 4 5結論めいたもの
 性能はプロジェクト全体の課題と位置づけ、
アーキテクトを中心にして、
全てのステークホルダで取り組む
 原則をとらえた性能改善に取り組む
 性能を改善するためには全工程で
取り組みが必要

付録ライフサイクルと性能の詳細

1 2 3 4 5要件定義工程
▌業務要求から検証可能な性能要件に変換する
▌性能の定義のあいまいさやコストとのトレードオフとなることから、
組織標準があると良い
業務要求
性能要件
業務側から要求される性能のレベル
他の制約は考慮されない場合が多い
他の制約を含め、調整された性能のレベル
定量的に計測できる場合が多い
拡張性要件拡張の条件やリードタイムの条件
制約ハードウェアコスト・運用コストなどの制約
調整・確定

1 2 3 4 5設計工程
▌アーキテクチャ設計において、性能を考える（パフォーマンスモデル）
▌リリース・拡張方式設計において、各構成要素について拡張を設計する
▌運用設計の中で、性能監視を考える
パフォーマンスモデル
リリース設計
性能を改善してリリースするライフサイクルを意識し、
容易にリリースできるようなインフラ・アプリ構成とする。
詳細は「ソフトウェアシステムアーキテクチャ構築の原理」を参照

1 2 3 4 5開発工程
▌アルゴリズムの選択が重要
▌単体レベルの性能計測・改善を実施
アルゴリズムの選択
性能計測
データ量、ループ回数、性能条件の厳しい処理の回避・軽減
（キャッシュ、分散など）
補足事項
 単一プログラム内での検討
 複数プログラム、ミドルウェアを
利用する場合はアーキテクチャ設計の
守備範囲
ロジック上の性能課題を洗い出すために、
開発中に単体機能（単一プログラム）における性能測定をおこなう
（JUnitで記述することでJUnitPerfも利用できる）

1 2 3 4 5テスト工程
▌性能テスト、負荷テスト、限界テストの目的を理解し、どのように
おこなうかを検討する
性能テスト
負荷テスト
負荷のかからない通常レベルの処理量において、
性能を計測し、性能課題がないかを確認する
ピーク時の負荷を疑似的に発生させ、性能要件を
満たしているかを確認する
限界テスト
性能要件を超えた負荷をかけた場合の動作及び
性能特性（ボトルネック発生個所の特定）を確認する
一般的には、負荷テストのみが計画されるケースが多いが
テスト計画段階で、この組み合わせを考える必要がある

1 2 3 4 5運用フェーズ
▌通常時はシナリオで監視する
▌繁忙期は、監視のトリガーに合わせて自動リリースを組み込むという
対応も検討する
通常監視
Web監視の例
http://www.zabbix.com/jp/web_scenarios.php から引用
 ユーザが利用するサービス単位で
監視を構成する
 監視によって負荷が
増加しないように留意する
繁忙期監視
 サービスが維持できているかを
確認する
 流量制御や自動リリースで
システムをダウンさせないように
する

1 2 3 4 5お問い合わせなど
ご清聴ありがとうございました。
ご質問、ご依頼事項がございましたら
atsushi.takayasu@bt-capital.com
へ、お気軽にご連絡ください。

アプリケーション性能を管理するのに必要なこと

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to アプリケーション性能を管理するのに必要なこと

Similar to アプリケーション性能を管理するのに必要なこと (20)

More from Atsushi Takayasu

More from Atsushi Takayasu (6)

Recently uploaded

Recently uploaded (8)

アプリケーション性能を管理するのに必要なこと

Editor's Notes