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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

ITproActive製品選択⽀援セミナー 1 2 3 4 5 ⾃⼰紹介⾼安厚思 ▌ 活動領域・キーワード ▌２０年にわたり、ソフトウエアエンジニアリングを適⽤したシステム開発やコンサルティングに携わる。 ▌最新技術を適切に利⽤した、柔軟なシステムの構築、品質管理を中⼼として技術マネージメントなどを主要テーマとして活動。 ▌開発⽅法論、アーキテクチャ設計コンサルティング、システム全体設計を得意分野とする。 ▌東京電機⼤学⾮常勤講師、SQuBOK設計開発領域検討委員、 ITSS-DS検討委員 ▌関連事例 ▌ソーシャルアプリケーション構築プロジェクト性能分析 ▌B2B ECサイト移⾏プロジェクト性能分析 ▌公共機関性能改善プロジェクトアーキテクトその他多数 2 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved.

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能にまつわるよくある話 ▌性能に関するステークホルダは多岐にわたり、性能にかかわる要素も多いため、以下のような会話がされることがある。 7 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. アプリケーションとしては⼗分にテストしているので問題ない。⼗分なシステムリソースがないのでは︖ リソースが空いている状態なので、アプリケーションの問題では︖ インフラ担当社アプリ担当社責任範囲が不明確なため、お互いに疑⼼暗⻤になりやすい

Slide 8

Slide 8 text

ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能とは ▌『性能』という⾔葉の定義を明確にし、ステークホルダー間で同意しておくことが重要 8 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 性能は⾮機能要件（上記の定義、ハードウェアコストの制約）によってあらわすことができる。オンラインアプリ ü レスポンスタイム（処理時間、応答時間） ü スループット（同時アクセス数）バッチアプリ ü 処理時間 ü 処理可能データ量同時アクセス数と処理時間はトレードオフオンラインバッチの場合、オンラインの影響に留意

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能を決定する要因・要素 ▌粒度の異なる複数の要因・要素によって性能が決まる 11 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 性能は階層の異なる複数の要因によって決定され、システムリソースがボトルネックとして表れる要因要素計算量、計算処理量、リソースの利⽤⽅法性能を構成する要素（システムリソース）影響観測可能観測困難推測

Slide 12

Slide 12 text

ITproActive製品選択⽀援セミナー 1 2 3 4 5 性能を決定する要因 ▌性能を決定する要因は、外的要因、内的要因、ミドルウェア特性、アプリロジックに⼤別できる 12 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 複数の要因によって性能が決定される外的要因内的要因ミドルウェア特性アプリロジック同時アクセス数データ量処理内容システムリソースの利⽤⽅法処理内容システムリソースの利⽤⽅法

Slide 13

Slide 13 text

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 アクセス待ち時間の発⽣システムリソース要因現象

Slide 14

Slide 14 text

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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サーバの分散

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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 拡張計画とリリース本当の意味で、性能を管理するためには全⼯程での配慮が必要

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

ITproActive製品選択⽀援セミナー 1 2 3 4 5 要件定義⼯程 ▌業務要求から検証可能な性能要件に変換する ▌性能の定義のあいまいさやコストとのトレードオフとなることから、組織標準があると良い 22 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 業務要求性能要件業務側から要求される性能のレベル他の制約は考慮されない場合が多い他の制約を含め、調整された性能のレベル定量的に計測できる場合が多い拡張性要件拡張の条件やリードタイムの条件制約ハードウェアコスト・運⽤コストなどの制約調整・確定

Slide 23

Slide 23 text

ITproActive製品選択⽀援セミナー 1 2 3 4 5 設計⼯程 ▌アーキテクチャ設計において、性能を考える（パフォーマンスモデル） ▌リリース・拡張⽅式設計において、各構成要素について拡張を設計する ▌運⽤設計の中で、性能監視を考える 23 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. パフォーマンスモデルリリース設計性能を改善してリリースするライフサイクルを意識し、容易にリリースできるようなインフラ・アプリ構成とする。詳細は「ソフトウェアシステムアーキテクチャ構築の原理」を参照

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

ITproActive製品選択⽀援セミナー 1 2 3 4 5 テスト⼯程 ▌性能テスト、負荷テスト、限界テストの⽬的を理解し、どのようにおこなうかを検討する 25 Copyright (C) 2015 Atsushi Takayasu All Rights Reserved. 性能テスト負荷テスト負荷のかからない通常レベルの処理量において、性能を計測し、性能課題がないかを確認するピーク時の負荷を疑似的に発⽣させ、性能要件を満たしているかを確認する限界テスト性能要件を超えた負荷をかけた場合の動作及び性能特性（ボトルネック発⽣個所の特定）を確認する⼀般的には、負荷テストのみが計画されるケースが多いがテスト計画段階で、この組み合わせを考える必要がある

Slide 26

Slide 26 text

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 流量制御や⾃動リリースでシステムをダウンさせないようにする