アプリケーションのパフォーマンスというよりはパフォーマンス全般の監視、管理、改善に関する内容が入っていました。
パフォーマンスの難しさは昔から感じていましたが、改めて話を聞くと多くの知識が必要だと感じました。そのためにも関係者で協力して対応しないといけないと感じました。
昔、ある人が『がんばって性能を確保するより、ハードにお金をかければいいんだ』という話を聞きました。
その言葉は正しいですが、それは設計が正しいなどの前提があるのだと感じました。
以下、メモ。
ITpro Active製品選択支援セミナー
アプリケーションパフォーマンス管理~攻めの運用でビジネスに貢献する~
日程:2015年1月30日(金) 13:00~17:20
会場:ソラシティホールEAST](ソラシティカンファレンスセンター)
主催:ITpro Active
A-1 アプリケーションパフォーマンスを最大化するためのインフラ/運用管理とは
・2000年まではシステムをしっかりと作ることが求められ、~2005年に経営戦略との連携が求められるようになった。~2010年はビジネス的効果を求められる。近年は変革が求められる。
・経営者が求めるIT戦略のテーマ
売上増大への直接的な貢献
業務コスト削減
顧客サービスの向上
・IT動向の重要指数はIT基盤の統合・再構築
IT基盤が足を引っ張り、目的が実現できないことが問題になっている企業が多い。
・基盤への投資意欲は、スマートデバイス、ネットワーク(特に無線)、クラウドに集中している。
・基盤関連のコンサルティングを実施するとスマートデバイス、ネットワーク、クラウド、IT基盤が必ずテーマになる。
・今までは情報システム部門の目的を達成するためのIT基盤であったが、近年は業務部門の目的を達成するためのIT基盤になっている。
・UXの向上によってROIの改善効果があることがITRの調査で分かっている。(Webサイトの場合)
社内システムでもUX向上によって生産性が倍以上の効果が出る。
UXの向上でシステム利用率は3倍になる。
・UXは作ってみて使ってみないとわからないため、プロトタイプを作ってPDCAサイクルを回すしかない。
・UX中心設計/開発/運用の方法論、ITインフラ、評価・フィードバックが必要。
A-2 Splunkを示すEnterpise APM ~APM Big Data を提供するdynaTrace~
・近年はWEBサービスが広まり、ユーザーニーズが向上している。
特にレスポンスに対する要求が強い。
・ログの種類が多くなりトラブル時やレスポンス悪化時にどれを見れば良いのかわからなくなっている。
→ログ全体を可視化できるツールが必要。
・dynaTraceは各サーバにエージェントを導入し、該当サーバを利用した際にユニークIDを振ってログを出力し、次のサーバに渡す。
その後、管理サーバに送り、レポート化する。
・dynaTraceであれば、すべてのユーザ、すべてのサーバの情報を取得しているため、一気通貫でログの関連付けができ、どこにボトルネックがあるわかりました。
・dynaTraceは他製品よりもサーバへの負荷が圧倒的に低い。
・dynaTraceの実績はグローバルで1000社程度、国内で40社。
・dynaTraceのライセンス体系はインストールしたエージェント数によって決まる。
・splunkはログの可視化のためのツールだが、実際はログ取得によって不正操作がないかセキュリティのために使うことも多い。
・splunkを利用し、ログデータから現在の発注された商品の現状を見せることができるようになった。
・サポートがよい企業を体験するとロイヤル顧客になる。
・見たいデータを瞬時に探すことができる。
・2月はどこのサイトでも最も売り上げが落ちるためキャンペーンを実施する。
キャンペーンの効果が出ているかリアルタイムで把握し、必要に応じた対応をしたい。
・ログを可視化することでパフォーマンス劣化の予兆を事前に設置して顧客の満足度を向上できるようにしている。
・splunkは世界100か国で利用され、国内で1500社。
・splunkのライセンスはログ容量で決まる。
A-3 のためのアプリケーション可視化・最適化・高速化
~クラウドを含めたアプリケーション・ネットワークのパフォーマンス向上~
・製造業等は海外に拠点を持っていることが多く、WANの高速化の要求がある。
・WAN高速化製品はリバーベッドとCiscoの2強。
・安全性、柔軟性、信頼性、高いパフォーマンスがユーザのネットワークに対する要求。
・SteelHeadはWANの高速化、SteelCentralはネットワークの可視化ができる。
・SteelHeadはバイトキャッシュを採用している。重複排除している。
さらに、拡張TCPを利用して高速化している。
・akamaiとriverbedで連携しインターネットのルートを最適化して、WAN高速化の限界を超えている。
・今後、クラウドの適応範囲を増やし、高速なクラウド利用環境を目指す。
A-4 Mobile App が主役の時代のAPM:CA Mobile App Analytics & CA APM9.7
・モバイルアプリケーションは利用しているアプリケーションが多い割に逆に使わなくなってしまうアプリケーションも多い。
・課題
アプリケーションレビューの評価が低く、SNSなどでネガティブな情報が拡散されてしまう。
アプリケーションの品質を保つことができない。利用環境が多様でありすべてをテストすることができないため、ユーザからの報告ないと気が付かない。
ユーザに十分な体感を与えることができていない。
・CA MAAをアプリに入れてユーザがインストールするとユーザのスマートフォンから利用状況、クラッシュ情報をサーバに送る。
WebはAPMで監視し、ネイティブとハイブリッドはMAAで監視する。
・収集したデータから、インストールの状況、アンインストール状況、利用状況(利用時間、利用回数)、クラッシュ情報のレポートが作成できる。
クラッシュレポートはクラッシュの種類の分析もでき、アプリ開発のインプットとしてテスト改善につなげることができる。
・MAAは昨年にリリースされたばかりの新商品。CAが自社で開発した製品。
A-5 アプリケーション性能を管理するのに必要なこと
・性能という言葉は人によって使い方が違うため、要件を決めるときに言葉の整理が必要。
また、必ず検証できるものだけで整理しないといけない。
・オンラインアプリはレスポンスタイム(処理時間と応答時間)とスループット
・バッチアプリは処理時間と処理可能データ量。
・性能を考えるうえでの原則
ボトルネックを改善せよ
何事も計測すべし
仮説検証を繰り返せ
・性能チェックはどういうライフサイクルで使っていくかが重要。
ツールだけでは要因特定は難しいため、ツールを使って要因を探す。
・性能を決定する要因
外的要因(同時アクセス数)
内的要因(データ量)
ミドルウェア特性(処理内容、システムリソースの利用方法)
アプリロジック(処理内容、システムリソースの利用方法)
ミドルウェア特性とアプリロジックは作るときに考えること。痛い目にあいやすい。
外的要因と内的要因は保守の中で発生する。予兆があるため見逃さないようにする。
・性能改善の技術は以下の4つしかない。
圧縮、キャッシュ、分散、計算量の減少。
・分散はステートレスとステートフルの場合とある。
・システムのライフサイクル(要件定義から廃棄まで)の各工程で性能を意識する必要がある。特に運用設計の性能監視を忘れがち。
・性能は個人やチームの責任ではなく、プロジェクト全体の問題であるため、関係者で協力しあって目標達成に向けて対応することが必要。
0 件のコメント:
コメントを投稿