Embed Size (px)
Citation preview
1
卓越したテクノロジー、あくなき追求
J2EE開発プロジェクトにおける諸問題とその対策
J2EE開発プロジェクトにおける諸問題とその対策
ボーランド株式会社
マーケティング部 部長 藤井等
2
Agenda
• 基本的な考え方• 各フェーズで検証すべき問題• 開発の側面から見たパフォーマンス問題• 反復的開発を行うための環境• デモンストレーション
2
卓越したテクノロジー、あくなき追求
基本的な考え方基本的な考え方
4
Tool
J2EEとアプリケーション
J2SE
J2EE Server・Web Server
・Application Server
・Messaging Server …
Connector
J2EE Application
WebComponent
EJBComponent
DatabaseServer
or
EIS
・Security
・Transaction
・Object Lifecycle…
3
5
J2EEプロジェクト開始前の不安
Tool
J2SE
J2EE Server・Web Server
・Application Server
・Messaging Server …
Connector
J2EE Application
WebComponent
EJBComponent
DatabaseServer
or
EIS
・Security
・Transaction
・Object Lifecycle…
Tool
J2SE
J2EE Server・Web Server
・Application Server
・Messaging Server …
Connector
J2EE Application
WebComponent
EJBComponent
DatabaseServer
or
EIS
・Security
・Transaction
・Object Lifecycle…
EJBを使用する必要があるのか?
既存システムとの統合方法はこれでいいのか?
データベースは十分なパフォーマンスを発揮するか?
トランザクション管理は万全か?
Javaのパフォーマンスに問題はないか?
快適な操作性を備えたUIを開発できるか?
サーバーの許容量はどのくらいか?
開発生産性を高めることはできるか?
納期を守ることができるか?
6
不安を解消するための唯一の解決策
技術的な不安は適切なタイミングでひとつひと
つ取り除いていくしかありません。それには、
段階的なリスク回避の手法を採用します。
4
7
従来型の開発プロセスではなぜだめか?
時間
リスク
• 基本設計は適切か？• 各機能は適切に実装されているか？
• 統合段階での品質問題はクリアされているか？
• アーキテクチャの選定は適切か？
これらの懸念点の検証はすべて先送りになっている
要件定義
設計
開発テスト
運用
8
設計
分析
実装
評価
• なぜ反復的な開発が必要か？– 段階的なリリースで、顧客に確認してもらいながら開発を進められる
– リスクの高い部分を先に開発できる– 状況の変化に機敏に対応することができる
反復的な開発プロセス
フェーズ1 フェーズ2 フェーズ3 フェーズ4Unified Profess（UP）
設計
分析
実装
評価
設計
分析
実装
評価
設計
分析
実装
評価
5
9
計画フェーズ 実装フェーズ
反復的な開発によるリスク回避
フェーズ1 フェーズ2 フェーズ3 フェーズ4
• 基本的なアーキテクチャレベルでの検証
• 個々の機能実装における検証• 統合段階での検証
検証内容
影
響
• アーキテクチャの選定• 基本設計にかかわる構成の変更 • 単体レベルでの品質問題
• 統合段階での品質問題
例 • システム統合の方式 • データアクセス性能 • 負荷テスト時の挙動
プロセス2 プロセス3 プロセス4 プロセス5プロセス1
開発のフェーズ
UP
FDD
卓越したテクノロジー、あくなき追求
各フェーズで検証すべき問題各フェーズで検証すべき問題
6
11
計画、設計段階での検証
• アーキテクチャ、技術の適用方法の検証– 有効な方法を採用せずに実装を開始すると、膨大な後戻りが発生する可能性がある
– 検証方法• プロトタイプにより選択した技術の有効性を検証• 基本的な性能特性を理解
• 設計方法の適切性– 実際にはこれを事前検証することは極めて困難
• 将来の再利用性を考慮することは初期段階では無理– 対処方法
• ベストプラクティスの採用（過去の成功例にならう）• 設計変更（リファクタリング）が可能な開発環境の導入
12
実装段階での検証
• 各機能（コンポーネント）レベルでのパフォーマンス問題の解決
– 統合後に問題が発覚しても、その原因を突き止めることは困難
– 検証方法• プロファイラによってパフォーマンス問題が存在するかを確認
• 問題箇所を特定しコードを修正
7
13
統合段階での検証
• アプリケーション統合後のパフォーマンス問題の解決– J2EEはいくつものサービスによって成り立つ集合体– どの箇所がボトルネックになっているかを特定することで全体の性能改善を実現できる
– 検証方法• アプリケーションサーバーをトレースしボトルネックを特定
• 問題の原因（コード？データベースアクセス？ JNDI？…）を特定し修正
卓越したテクノロジー、あくなき追求
開発の側面から見たパフォーマンス問題開発の側面から見たパフォーマンス問題
8
15
パフォーマンス劣化は、複合的な問題に起因
• さまざまな原因によりパフォーマンス劣化が発生‐ アプリケーションパフォーマンスが予想どおり出ない
‐ 連続稼動でパフォーマンス低下が発生する
パフォーマンス問題が発生する理由：
メモリーリーク
テンポラリーオブジェクトの使いすぎ
StringBufferを使用しない文字列結合RPCを考慮しないオブジェクトの配置不必要なデータ転送
：
16
Javaのパフォーマンス問題解決は困難
• Javaは抽象度の高い言語– 下位システムレイヤの隠蔽
• Javaのコードは最適化する必要がないのか？– 一時オブジェクトの使い過ぎ
• 頻繁なガベージコレクションが発生– メモリーリーク
• メモリーリークによるシステムダウン– CPUの不適切な利用
• 応答時間の遅延
9
17
Javaのパフォーマンス問題の所在
• では、これらの問題はJavaプラットフォームそのものの問題か、それとも…– JVMの特性、性能限界か?– アプリケーションサーバーベンダーの問題か?– QA担当者が注意すべき問題か? ：
18
テスト：大規模システム展開
運用・サービスレベル
レスポンス時間解析ツール
デバッグ・テスト
-分析・解析
開発
ライフサイクル
中期
早期
後期
問題管理プロセス
問題点の明確化・修復
許容プラニングプロセス追加リソースを供給しての
分析・モデリング
性能管理プロセス
性能評価
オペレーション
開発フェーズ
ツール及びプロセスの関係図
10
19
パフォーマンス問題解決ツールによる支援
• 開発フェーズからパフォーマンス問題の芽を摘む– 問題が顕在化してからでは、問題の原因を特定することが困難な場合が多い
– ツールを使用することで、問題の発見にかける労力を大幅に削減可能
– 開発プロセスに組み込むことで、プロジェクトチーム全体の品質向上に寄与
– パフォーマンス問題への対処は「開発者の作法」とするべき
20
Optimizeit Suiteを使ったJavaパフォーマンス問題の解決
• ヒープビュー– クラス毎に現在のインスタンス数、サイズを表示– GCの対象とならなかったクラスを探す
• 手順1) Optimizeit Profilerを使用してアプリケーションを実行2) GCの無効化3) GCの実行4) この時点のインスタンス数をマーク (a)
5) アドレス帳サンプルの実行6) GCの実行 (b)
(b)の時点のインスタンス数と(a)の差分を見る※メモリーリークの原因となるオブジェクトを見付ける
11
21
J2EEパフォーマンス問題のもうひとつの側面
Browser
Mobile
Application
クライアント層
HTTP
SOAPRMI/IIOP
伝統的なパフォーマンスツールによるQA
Webフロントエンドのスループットだけを計測していたのでは、問題があることは分かっても、J2EEの各コンポーネントのどこに問題があるのかは分かりません。
22
Optimizeit ServerTraceによる解決
Browser
Mobile
Application
クライアント層
J2EE Platform
Web Server EJB Container
Web層 EJB層 EIS層
Web Container
EJBComponent
EJBComponent
Servlet
JSP
JDBC
JDBC
RMI/IIOP
HTTP
SOAPRMI/IIOP
Optimizeit ServerTrace
Optimizeit ServerTraceは、J2EEの各コンポーネント、レイヤー間の通信をモニターできるので、J2EEアプリケーションのどこにパフォーマンス上の問題があるのかすばやく特定できます。
12
卓越したテクノロジー、あくなき追求
反復的開発を行うための環境反復的開発を行うための環境
24
Application Lifecycle Management
要件定義
設計 開発
テスト
運用
変更管理
効果的な開発プロセス- UP, FDD, XP…- 既存の開発プロセス
13
25
ボーランドのJ2EEソリューション
要件定義
設計 開発
テスト
運用
変更管理
Together JBuilder
Borland Enterprise ServerInterBaseJDataStore
Optimizeit SuiteOptimizeit ServerTrace
CaliberRM
StarTeam
26
統合によってもたらされる価値
開発
設計
プログラマー
デザイナー
LiveSource
14
卓越したテクノロジー、あくなき追求
デモンストレーションデモンストレーション
28
シナリオ
• サーバーサイドアプリケーション– Accountユーザーアカウントクラス。Observableを実装
• setName()、setEmail()でnotifyObservers()を呼び出し、登録されたすべてのObserverクラスに変更を通知
– AccountManagerAccountのプロパティ変更通知を処理するObserverクラス
• update() メソッドで変更通知を受ける
– TestAppアプリケーションの挙動を調べるためのテストアプリケーション
• doTest()メソッドで挙動をテスト
15
29
問題 1
• 問題点 –文字列処理– Stringクラスの乱用によるテンポラリーオブジェクトの使いすぎではないか?
• 検証方法 – Optimizeit– 修正前と修正後のスナップショットを比較– オブジェクト生成の状態を確認
30
問題 ２
• 問題点 – メモリリーク– 連続稼動することでパフォーマンスが落ちる– どこかで使わなくなったオブジェクトを参照しっぱなしになっているようだ…
• 検証方法 – Optimizeit – ガベージコレクションの実行を制御– 2つのガベージコレクション間で開放されないオブジェクトを確認
– メモリリークしているオブジェクトとそのコードを確認
16
31
テンポラリーオブジェクトの使
いすぎにより、頻繁なガベージ
コレクションが発生している。
オブジェクトの使用方法を効率
化する修正をコードに施したと
ころ、ヒープの使用状況が劇
的に改善された。
デモンストレーションからのスナップショット
卓越したテクノロジー、あくなき追求
問い合わせ先： ボーランド株式会社 営業本部 TEL 03-5350-9358
mail [email protected]
