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

ITproActive製品選択支援セミナー

Transcript

1. ITproActive製品選択⽀援セミナー アプリケーション性能を管理するのに必要なこと 株式会社ビッグツリーキャピタル SI事業部 ⾼安 厚思 1 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved.
2. ITproActive製品選択⽀援セミナー 1 2 3 4 5 ⾃⼰紹介 ⾼安 厚思 ▌ 活動領域・キーワード ▌２０年にわたり、ソフトウエアエンジニアリングを適⽤した システム開発やコンサルティングに携わる。 ▌最新技術を適切に利⽤した、柔軟なシステムの構築、 品質管理を中⼼として技術マネージメントなどを主要テーマとして活動。 ▌開発⽅法論、アーキテクチャ設計コンサルティング、システム全体設計を 得意分野とする。 ▌東京電機⼤学⾮常勤講師、SQuBOK設計開発領域 検討委員、 ITSS-DS検討委員 ▌関連事例 ▌ソーシャルアプリケーション構築プロジェクト 性能分析 ▌B2B ECサイト移⾏プロジェクト 性能分析 ▌公共機関 性能改善プロジェクト アーキテクト その他多数 2 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved.
3. ITproActive製品選択⽀援セミナー 1 2 3 4 5 対外活動 n最近の著書、訳書 ▌ 「システム設計の謎を解く（ソフトバンク）」 ▌ 「StrutsによるWebアプリケーション スーパーサンプル（ソフトバンク）」 ▌ 「Seasar⼊⾨[（ソフトバンク）」 ▌ 「Javaルールブック（エクスメディア） ▌ 「ITアーキテクトのためのシステム設計実践ガイド アーキテクチャ編（⽇経 BP）」など。 n連載記事執筆 ▌ ⽇経SYSTEMS誌「Webアーキテクチャ再⼊⾨」 n講演 ▌ SODEC ミッションクリティカル開発 ▌ ⽇本テクノセンター セミナー講師 ▌ UML Forum講師 ▌ ⽇経BP社 ITアーキテクトのためのシステム設計フォーラム 特別講演 講師 ▌ Developers Summit 2013 Summer ▌ QCon 2014 ▌ ITpro Active製品選択⽀援セミナー 3 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved.
4. ITproActive製品選択⽀援セミナー 1 2 3 4 5 会社案内 ▌社名︓株式会社ビッグツリーキャピタル（Big Tree Capital.LTD.） ▌Webサイト︓http://www.bt-capital.com ▌サービスメニュー︓ ▌テクノロジー ▌ システムインテグレーション（基幹系システム、ECサイト構築等） ▌ プラットフォーム（AWS、Solr、Hadoop、仮想化基盤等） ▌コンサルティング ▌ IT戦略コンサルティング（ビジネスモデリング、TCO削減等） ▌ プロジェクトマネジメント（PMO/PgMO、IT調達⽀援等） ▌ 技術コンサルティング（アーキテクチャ設計、技術検証等） 4 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved.
5. ITproActive製品選択⽀援セミナー 1 2 3 4 5 アジェンダ ▌1 性能とは ▌2 性能を決定する要素 ▌3 性能改善の技術 ▌4 ライフサイクルと性能 ▌5 結論のようなもの ▌付録 ライフサイクルと性能の詳細 5 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved.
6. ITproActive製品選択⽀援セミナー 1 性能とは Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 6
7. ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能にまつわるよくある話 ▌性能に関するステークホルダは多岐にわたり、性能にかかわる要素も 多いため、以下のような会話がされることがある。 7 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. アプリケーションとしては⼗分に テストしているので問題ない。 ⼗分なシステムリソースがないのでは︖ リソースが空いている状態なので、 アプリケーションの問題では︖ インフラ担当社 アプリ担当社 責任範囲が不明確なため、お互いに疑⼼暗⻤になりやすい
8. ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能とは ▌『性能』という⾔葉の定義を明確にし、ステークホルダー間で同意し ておくことが重要 8 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 性能は⾮機能要件（上記の定義、ハードウェアコストの制約）によって あらわすことができる。 オンライン アプリ ü レスポンスタイム（処理時間、応答時間） ü スループット（同時アクセス数） バッチ アプリ ü 処理時間 ü 処理可能データ量 同時アクセス数と処理時間はトレードオフ オンラインバッチの場合、オンラインの 影響に留意
9. ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能を考える上での原則 ▌性能を設計、改善する場合には守るべき原則がある 9 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 何事も計測すべし ボトルネックを改善せよ 仮説検証を繰り返せ この原則を無視した施策は効果がでにくい
10. ITproActive製品選択⽀援セミナー 2 性能を決定する要素 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 10
11. ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能を決定する要因・要素 ▌粒度の異なる複数の要因・要素によって性能が決まる 11 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 性能は階層の異なる複数の要因によって決定され、 システムリソースがボトルネックとして表れる 要因 要素 計算量、計算処理量、リソースの利⽤⽅法 性能を構成する要素（システムリソース） 影響 観測可能 観測困難 推測
12. ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能を決定する要因 ▌性能を決定する要因は、外的要因、内的要因、ミドルウェア特性、 アプリロジックに⼤別できる 12 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 複数の要因によって性能が決定される 外的要因 内的要因 ミドルウェア 特性 アプリ ロジック 同時アクセス数 データ量 処理内容 システムリソースの利⽤⽅法 処理内容 システムリソースの利⽤⽅法
13. ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能を決定する要素 ▌性能を構成する最終要素 ▌CPU等のシステムリソースがボトルネックになって、 性能の上限が決まる 13 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. CPU メモリ ディスク N/W p 同時アクセス数の増加 p 計算量の増加 p 同時アクセス数の増加 p データ量の増加 p メモリ確保の増加 p CPU待ち時間の発⽣ p スワップの発⽣ p GCの発⽣ p メモリ不⾜による システムダウン p アクセス特性 p データ量の増加 p アクセス待ち時間の 発⽣ p 同時アクセス数の増加 p データ量の増加 p アクセス待ち時間の 発⽣ システム リソース 要因 現象
14. ITproActive製品選択⽀援セミナー 3 性能改善の技術 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 14
15. ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能改善の技術 ▌ システムリソースのボトルネックを改善するためには以下のような技術が有効 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 15 圧縮 キャッシュ 分散 計算量の減少 同じデータや構造の繰り返しを別の構造で 表現することによって、データ量を削減する 繰り返し利⽤されるデータをアクセス速度の ⾼いリソースに配置することによって、 アクセス速度を向上させる ボトルネックになるリソースを複数準備し、 それぞれ並列で処理させることによって、 ボトルネックを解消する ループの回数やデータ構造を変更することに よって、計算量を減少させる これらの技術を直接あるいは間接的に利⽤し、性能を 維持する。
16. ITproActive製品選択⽀援セミナー 1 2 3 4 5 分散⽅法 ▌システムリソースのボトルネックを解消する⼿段として、 「分散」が⽤いられる 16 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. ステートレスの場合 ステートフルの場合 l 状態に依存せず振り分け先を決定できる。 l 処理するノードを増加させ、振り分けを⾏うことで実現する。 l 振り分け装置（HW/SW）の性能に依存するがスケールしやすい。 l 例）ロードバランサーによるWebサーバの分散 l 状態に依存していて、単純に振り分けができない。 振り分けロジックと振り分けに必要な情報によって振り分けを ⾏うことで実現する。 l 分散先を決定するノードによる処理がボトルネックになり、ス ケールしにくい。 l 例）ユーザIDをキーとするシャーディングによる DBサーバの分散
17. ITproActive製品選択⽀援セミナー 4 ライフサイクルと性能 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 17
18. ITproActive製品選択⽀援セミナー 1 2 3 4 5 ライフサイクル ▌アプリケーションの性能を管理するには各⼯程で性能を 意識する必要がある 18 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 要件定義 設計 実装 テスト 運⽤ p 性能の定義 p 性能を表す⾮機能要件 p アーキテクチャ設計（性能設計） p リリース・拡張⽅式設計 p 性能監視設計 p 性能・負荷・限界テスト及び改善 p アルゴリズム選択 p 単体レベルの性能計測・改善 p 性能監視・改善 p 拡張計画とリリース 本当の意味で、性能を管理するためには全⼯程での配慮が必要
19. ITproActive製品選択⽀援セミナー 5 結論 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 19
20. ITproActive製品選択⽀援セミナー 1 2 3 4 5 結論めいたもの 20 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. ü 性能はプロジェクト全体の課題と位置づけ、 アーキテクトを中⼼にして、 全てのステークホルダで取り組む ü 原則をとらえた性能改善に取り組む ü 性能を改善するためには全⼯程で 取り組みが必要
21. ITproActive製品選択⽀援セミナー 付録 ライフサイクルと性能の詳細 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 21
22. ITproActive製品選択⽀援セミナー 1 2 3 4 5 要件定義⼯程 ▌業務要求から検証可能な性能要件に変換する ▌性能の定義のあいまいさやコストとのトレードオフとなることから、 組織標準があると良い 22 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 業務要求 性能要件 業務側から要求される性能のレベル 他の制約は考慮されない場合が多い 他の制約を含め、調整された性能のレベル 定量的に計測できる場合が多い 拡張性要件 拡張の条件やリードタイムの条件 制約 ハードウェアコスト・運⽤コストなどの制約 調整・確定
23. ITproActive製品選択⽀援セミナー 1 2 3 4 5 設計⼯程 ▌アーキテクチャ設計において、性能を考える（パフォーマンスモデル） ▌リリース・拡張⽅式設計において、各構成要素について拡張を設計する ▌運⽤設計の中で、性能監視を考える 23 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. パフォーマンスモデル リリース設計 性能を改善してリリースするライフサイクルを意識し、 容易にリリースできるようなインフラ・アプリ構成とする。 詳細は「ソフトウェアシステムアーキテクチャ構築の原理」を参照
24. ITproActive製品選択⽀援セミナー 1 2 3 4 5 開発⼯程 ▌アルゴリズムの選択が重要 ▌単体レベルの性能計測・改善を実施 24 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. アルゴリズムの選択 性能計測 データ量、ループ回数、性能条件の厳しい処理の回避・軽減 （キャッシュ、分散など） 補⾜事項 p 単⼀プログラム内での検討 p 複数プログラム、ミドルウェアを 利⽤する場合はアーキテクチャ設計の 守備範囲 ロジック上の性能課題を洗い出すために、 開発中に単体機能（単⼀プログラム）における性能測定をおこなう （JUnitで記述することでJUnitPerfも利⽤できる）
25. ITproActive製品選択⽀援セミナー 1 2 3 4 5 テスト⼯程 ▌性能テスト、負荷テスト、限界テストの⽬的を理解し、どのように おこなうかを検討する 25 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 性能テスト 負荷テスト 負荷のかからない通常レベルの処理量において、 性能を計測し、性能課題がないかを確認する ピーク時の負荷を疑似的に発⽣させ、性能要件を 満たしているかを確認する 限界テスト 性能要件を超えた負荷をかけた場合の動作及び 性能特性（ボトルネック発⽣個所の特定）を確認する ⼀般的には、負荷テストのみが計画されるケースが多いが テスト計画段階で、この組み合わせを考える必要がある
26. ITproActive製品選択⽀援セミナー 1 2 3 4 5 運⽤フェーズ ▌通常時はシナリオで監視する ▌繁忙期は、監視のトリガーに合わせて⾃動リリースを組み込むという 対応も検討する 26 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 通常監視 Web監視の例 http://www.zabbix.com/jp/web_scenarios.php から引⽤ p ユーザが利⽤するサービス単位で 監視を構成する p 監視によって負荷が 増加しないように留意する 繁忙期監視 p サービスが維持できているかを 確認する p 流量制御や⾃動リリースで システムをダウンさせないように する
27. ITproActive製品選択⽀援セミナー 1 2 3 4 5 お問い合わせなど 27 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. ご清聴ありがとうございました。 ご質問、ご依頼事項がございましたら atsushi.takayasu@bt-capital.com へ、お気軽にご連絡ください。