アーキテクチャと設計のガイドライン

.NET アプリケーションのパフォー
マンスとスケーラビリティの向上
Part1
マイクロソフト株式会社
エンタープライズ・プラットフォーム本部
エバンジェリスト
関田文雄
何が原因なのか？
テスト
チューニング要素
アーキテクト
設計
見積もり
パフォーマンス
コーディング
プロマネ
要件定義
コミュニケーション
開発者
ユーザー
スケーラビリティ
調達管理
テスター
Agenda
パフォーマンス考慮のアプローチ
パフォーマンス目標
アーキテクチャと設計のガイドライン
実装手法の適用
パフォーマンス考慮のアプローチ
「非常にラッキーなら、パフォーマンス上の問題は発生後で
も解決できます。しかし、許容できるパフォーマンスを得られ
るよう、後からコードの配置替えを行なうと、莫大な作業が必
要となる場合もあります。この落とし穴にはまると、本当に大
変です。最悪の場合、記憶に残る、そして職場を去るきっか
けともなりかねない、きついコメントを受けることになるでしょ
う。『もうどうにもならない。一からやり直しだ』」
— Rico Mariani (アーキテクト), Microsoft
何が起こっているか？
要件の分析
設計
開発
テスト
展開
現場での格闘
ボトルネックの洗い出し
チューニング
その場限りの対応
それでも顧客の要件が
満たせなければ
ハードウェアの変更
やり直し
要件の調整
パフォーマンス考慮の構成要素
要件の分析
パフォーマンス目標（応答時間、スループット…）
設計
アーキテクチャと設計のレビュー（原則、プラクティス…）
開発
コードレビュー
計測
応答時間,スループット…
テスト
テスト
負荷テスト,ストレステス
ト…
チューニング
展開
ネットワーク,アプリケー
ション…
開発プロセスの中にパフォーマンス最適化の
プロセスをどのように組み込むことができる
かが鍵
ライフサイクルの各段階における
パフォーマンス
要件の収集
パフォーマンス
モデリング
プロトタイプ
アーキテクチャと
設計のレビュー
コードレビュー
計測
負荷テスト
ストレステスト
キャパシティ
テスト
チューニング
設計
開発
テスト
展開
保守
RACI チャート
タスク
アーキテクト
管理者
開発者
テスター
パフォーマンス目標
A
R
C
I
パフォーマンスモデリング
A
I
I
I
パフォーマンス設計原則
A
I
I
パフォーマンスアーキテクチャ
A
C
I
アーキテクチャレビューと
設計レビュー
R
I
I
コード開発
A
テクノロジに特有な
パフォーマンス関連問題
A
コードレビュー
R
I
I
A
パフォーマンステスト
C
C
チューニング
C
R
トラブルシューティング
C
A
I
展開レビュー
C
R
I
R： Responsible （実行責任）
A： Accountable（責任）
I
C: Consulted （アドバイス）
I： Keep Informed （情報所有）
Microsoft Patterns & Practices
開発プロジェクトのためのベストプラクティス
「.NET アプリケーションのパフォーマンスと
スケーラビリティの向上」
原題：「Improving .NET Application Performance and Scalability」
原文： 1150 ページ
パート I 「パフォーマンスを考慮したエンジニアリング入門」
パート II 「パフォーマンスを考慮した設計」
パート III 「アプリケーションのパフォーマンスとスケーラビリティ」
パート IV 「データベースサーバーのパフォーマンスとスケーラビリティ」
パート V 「計測、テスト、チューニング」
MSDN サイトで公開中
http://www.microsoft.com/japan/msdn/
パフォーマンス目標
パフォーマンスモデリング
ステップ
1 主要シナリオの特定
作業内容
クリティカルシナリオ、重要シナリオの特定
総ユーザー数、同時アクティブユーザ数、データ
2 ワークロードの特定
量、トランザクション量の特定
応答時間（例：製品カタログは3秒以内に表示）
3 パフォーマンス目標値スループット（例：毎秒 100 トランザクション）
の特定
リソース利用（例：CPU、メモリ、I/O）
4 バジェットの特定
実行時間、利用するリソースの特定
5 処理ステップの特定
特定したシナリオを処理ステップに分割
6 バジェットの割り当て処理ステップに実行時間、リソースを割り当てる
7 評価
机上での妥当性評価
8 検証
各工程で適切な計測を行う
アーキテクチャと設計のガイドライン
アーキテクチャと設計の概要
原則
原則、ガイドライン、プラク
ティスに沿って設計されて
いるかをレビュー
機能・非機能要件
アーキテクチャ
パフォーマンス
目標値
設計
ガイドライン
ベストプラクティス
パターン
パフォーマンス目標を達成
したアーキテクチャ、設計
をプラクティスとして登録
原則
設計プロセス原則
客観的な目標を設定する
アーキテクチャと設計を早期段階で検証する
余剰を取り除く
トータルパフォーマンスをチューニングする
ライフサイクルを通して計測を行う
設計原則
租粒度サービスを設計する
バッチ化作業でラウンドトリップ数を最小化する
遅く確保して早く手放す
処理リソースとのアフィニティを評価する
処理を必要なリソースへ近づける
共有リソースをプールする
不必要な作業を避ける
競合を減らす
一歩進んだ処理を行う
独立したタスクを同時に処理する
ガイドライン
ADO.NET
デスクトップ
アプリケーション
ブラウザ
クライアント
ASP.NET
ビジネス層
ビジネスロジック
プレゼンテーション
Web 層
データ
アクセス
データアクセス層
アプリケーション
クライアント
リモート処理
Web サービスWeb サーバー
サーバー
Enterprise
Services
マネージコード / 相互運用 / XML
データベース
サーバー
ガイドライン（展開）
展開アーキテクチャを検討する
制約と仮定を早い段階で特定する
サーバーアフィニティを評価する
レイヤ型設計を利用する
同じプロセスにとどまる
不可避な場合を除き、アプリケーションロジックをリ
モート化しない
プレゼンテーション
プレゼンテーション
ビジネスロジック
ビジネスロジック
データアクセス
データアクセス
Web/アプリケーション
サーバー
データベース
サーバー
非分散型アーキテクチャ
Web サーバー
アプリケーション
サーバー
データベース
サーバー
分散型アーキテクチャ
ガイドライン（スケーリング）
スケールアップ
既存の構造に与える影響が少
ない（まず最初に検討）
ハードウェアの限界がある
コストは高い
プロセス依存リソースの考慮
状態ストアの考慮
8-32 Way SMP
64GB メモリ
4-8 Way SMP
32GB メモリ
1-4 Way SMP
4GB メモリ
スケールアウト
処理能力が比較的、リニアに
アップ
処理能力と共に耐障害性も
アップ
サーバーが増えるため、運用
コストもリニアにアップ
アプリケーションがスケール
アウトに対応する必要がある
システムの成長予測に見合っ
たスケーリングプランを作る
ステートレス設計
+
+
+…
分散型アーキテクチャで予想される問題
状態アフィニティ
の利用
オペレーションの
ブロック
誤った
データ型
バッチ処理せず
細切れの処理
ビジネスロジック
プレゼンテーション
データアクセス
クライアント
大きな View
State
Web サーバー
キャッシュせずにリク
エスト毎の呼び出し
不十分な
リソース管理
アプリケーション
サーバー
データベース
サーバー
プールなしで
接続
データ構造とアルゴ
リズムの選択ミス
競合、分離レ
ベル、ロック
パフォーマンス / スケーラビリティフレーム
カテゴリ
結合度と凝集度
主な考慮事項
疎結合と高凝集
転送メカニズム、リモートインタ
通信
フェース設計、シリアル化、帯域
トランザクション、ロック、スレッド化、
平行処理
キューイング
割り当て、作成/破棄、プーリング
リソース管理
ユーザー単位、アプリケーション全
キャッシング
体、データの揮発性
ユーザー単位、アプリケーション全
状態管理
体、永続性
アルゴリズムの選択
データ構造 / アルゴリズム
配列 vs. コレクション
設計ガイドライン
カテゴリ
結合度と凝集度
通信
平行処理
リソース管理
ガイドライン
疎結合設計を行う
高凝集設計を行う
アプリケーション機能を論理レイヤへ分割する
Web サービス、リモーティング、Enterprise
Services を適切に選択する
DataSet、型付き DataSet、コレクション、XML、
独自オブジェクト等を適切に選択する
ロック時間を最小化して競合を軽減する
適切な分離レベルを選択する
共有リソースや希少リソースをプールする
遅く確保して早く手放す
効率的なオブジェクトの作成と破棄を検討する
設計ガイドライン
カテゴリ
キャッシング
状態管理
データ構造 / ア
ルゴリズム
ガイドライン
データのキャッシュ先を決める
キャッシュすべきデータを決める
期限切れポリシーと破棄メカニズムを決める
選択可能な状態情報の格納方法を考慮する
セッションリソースを速やかに開放する
ビジネスロジックからセッション変数の使用を避
ける
適切なデータ構造を選択する
値型と参照型を適切に使用する
実装手法の適用
実装手法の概要
ASP.NET
Enterprise Services
ビジネスロジック
Web サービスプレゼンテーション
リモート処理
データアクセス
クライアント
Web サーバー
ADO.NET
アプリケーション
サーバー
マネージコード / 相互運用 / XML
データベース
サーバー
Web サービスのパフォーマンス考慮
接続
maxconnection 属性を設定する
スレッド処理
スレッドプールの設定
アタッチメント
適切な手法を選択する
シリアライズ
シリアル化アセンブリの自動生成（.NET Framework
2.0 から）
Web サービスのパフォーマンス考慮
接続
maxconnection 属性を設定する
デフォルトは接続数=2
Web サービス
Wait!
クライアント
Web サーバー
Wait!
Web サービス
<connectionManagement>
<add address="*" maxconnection="12"/>
</connectionManagement>
Web サービスのパフォーマンス考慮
スレッド処理
キューで待機中の要求が想定以上の場合にチューニング
ASP.NET Applications/Requests in Application Queue パ
フォーマンスカウンタ
項目
maxconnection
maxIoThreads
maxWorkerThreads
minFreeThreads
minLocalRequestFree
Threads
デフォルト
2
20
20
8
4
推奨値
12 * #CPUs
100
100
88 * #CPUs
76 * #CPUs
※ 推奨値は絶対的な数値ではないため、適切なテストを実施し
た上で、環境にあった最適設定を行って下さい
Web サービスのパフォーマンス考慮
アタッチメント
WS-Attachment
アタッチメントは SOAP エンベロープ外
WSE 1.0 / 2.0 でサポート
Base 64 エンコーディング
大量なデータには不向き
相互接続性は高い
MTOM（SOAP Message Transmission
Optimization Mechanism）
W3C で勧告として公開（2005/1/26）
WSE 3.0 でサポート
Web サービスのパフォーマンス考慮
シリアライズ
シリアル化アセンブリの自動生成（.NET
Framework 2.0 から）
デフォルトでは、プロキシが最初にインスタンス化された
時に、XmlSerializer が動的にシリアル化コードを生成し、
csc.exe でコンパイル
C:\>sgen.exe MyProject.dll
生成された MyProject.XmlSerializers.dll を
MyProject.dll と同じフォルダに配置
リモート処理のパフォーマンス考慮
アクティベーション、チャネルの選択
SAO（シングルコール） + HTTP チャネル + IIS を利用
する
ローカルマシン内通信には、IpcChannel を利用する
（.NET Framework 2.0 から）
シリアライズ
DataSet のバイナリ転送では RemotingFormat を設定
する（.NET Framework 2.0 から）
リモート処理のパフォーマンス考慮
アクティベーション、チャネルの選択
SAO（シングルコール） + HTTP チャネル + IIS を
利用する
パフォーマンス
HTTP チャネル＜ TCP チャネル
スケーラビリティ
TCP チャネル＜ HTTP チャネル
CAO ＜ SAO（シングルトン）＜ SAO（シングルコール）
セキュリティ
Windows サービス、カスタムアプリケーション＜ IIS ホスト
※.NET Framework 2.0 から TCP チャネルでも負荷分散自体は可能
<channel ref="tcp" socketCachePolicy="AbsoluteTimeout"
socketCacheTimeout="0" />
リモート処理のパフォーマンス考慮
チャネルの選択
ローカルマシン内通信には、IpcChannel を利用する
（.NET Framework 2.0 から）
ローカルマシン内のプロセス間（AppDomain 間）通信に利用
IpcChannel を使うことにより名前付きパイプにより通信が行われ
る
ipc://myPortName/myObject.rem
アクセス制御に名前付きパイプの ACL が利用可能
<channel ref=“ipc” portName=“testPipe”
authorizedGroup=“Administrators” />
リモート処理のパフォーマンス考慮
シリアライズ
DataSet のバイナリ転送では RemotingFormat
を設定する（.NET Framework 2.0 から）
デフォルトではバイナリ転送でもネットワークを流れる
データは XML
ds.RemotingFormat = SerializationFormat.Binary
その他のパフォーマンス考慮
相互運用
できる限り Blittable 型を使用する
できる限り Unicode から ANSI への変換を避ける
…
マネージコード
Filanalize と Dispose の考慮
頻繁なボックス化/ボックス化解除を避ける
…
ADO.NET
…
ASP.NET
…
Enterprise Services
…
XML
…
チェックリスト（Web サービス）
設計上の考慮事項
非同期呼び出し
チャンキーなインターフェイスを設計してラウンドトリップを減らす
追加的な並行作業があれば Web サービスの非同期呼び出しを検討する
RPC スタイルよりもメッセージベースのプログラミングを採用する
関連のない複数の Web サービスに対しては非同期呼び出しを使う
引数のフォーマットにはリテラルメッセージエンコーディングを使う
UI 応答性が重要なら Web サービスを非同期で呼び出す
Web サービス引数にはプリミティブ型を使うようにする
サーバー状態情報を呼び出し間で保持しない
タイムアウト
コストの大きい Web メソッドについて入力検証を検討する
プロキシタイムアウトを適切に設定する
キャッシュアプローチを考慮する
ASP.NET タイムアウトを Web サービスタイムアウトよりも長くセットする
バルクデータ転送 / アタッチメントアプローチを考慮する
ASP.NET ページへの接続を Web サービス呼び出し完了前にタイムアウトさ
せる
responseDeadlockInterval 属性を考慮する
接続
maxconnection 属性を設定する
WebMethods
異なる Web サービスをまたいで接続に優先順位を付けて割り当てる
できる限りプリミティブ型引数を使う
外部への呼び出しには単一の ID を使う
バッファを考慮する
統合 Windows 認証で UnsafeAuthenticatedConnectionSharing の設定
を考慮する
Basic 認証では PreAuthenticate を使う
スレッド
応答のキャッシュを検討する
セッション状態は、必要とする Web メソッドについてのみ有効にする
シリアライズ
XmlIgnore でシリアル化を減らす
競合低減の公式を使ってスレッドプールをチューニングする
ラウンドトリップを減らす
断続的に発生するバースト負荷に対して minIoThreads と
minWorkerThreads の使用を検討する
XML 圧縮を検討する
一方向通信
応答が必要でないなら、OneWay 属性の使用を検討してください
非同期 Web メソッド
I/O オペレーションに非同期 Web メソッドを使う
ワーカースレッドに依存している場合は非同期 Web メソッドを使わない
キャッシュ
揮発性の低いデータの出力キャッシュを検討する
キャッシュ関連情報のクライアントへの提供を検討する
周辺キャッシュを検討する
状態管理
セッション状態は必要な場合にのみ使う
サーバーアフィニティを避ける
まとめ
パフォーマンスを考慮した設計
パフォーマンス目標
(応答時間、スループット、リソース利用度、ワークロード)
パフォーマンス / スケーラビリティフレーム
結合度と凝集度
通信
並行処理
リソース管理
キャッシング、状態管理
データ構造 / アルゴリズム
計測、テスト、チューニング
計測
応答時間
スループット
リソース利用度
ワークロード
テスト
負荷テスト
ストレステスト
キャパシティテスト
チューニング
ネットワーク
システム
プラットフォーム
アプリケーション
ロール
(原則、プラクティス、パターン)
ライフサイクル
アーキテクチャと設計のガイドライン
(要件、設計、開発、テスト、展開、保守)
(シナリオ、目標値、ワークロード、要件、バジェット、メトリクス)
(アーキテクト、開発者、テスター、管理者)
パフォーマンスモデリング
技術情報リソース
MSDN ホームページ:
http://www.microsoft.com/japan/msdn/
.NET アーキテクチャセンター:
http://www.microsoft.com/japan/msdn/architecture/
Patterns & Plactices:
http://www.microsoft.com/japan/resources/practices/
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Download Report