変更要約: AZ-120 第4章を新規作成（ドメイン4前半: パフォーマンス・コスト最適化(Azure Advisor 推奨・VM リサイズ・Reserved Instances vs Savings Plans・ストレージコスト・アーカイブ)、ネットワーク・アプリ/DB 最適化(Azure Network Watcher で遅延/スループット計測・近接配置/Accelerated Networking/VM サイズ・アプリサーバー水平/垂直スケール・DB チューニング・継続改善サイクル)）。
4.2ネットワーク・アプリ/DB の最適化
ネットワークパフォーマンスの分析と最適化、遅延/スループットのボトルネック特定、SAP アプリケーションサーバーとデータベースの継続的なチューニング/スケーリングを理解します。
SAP の性能は アプリ層↔DB 層のネットワーク と各層のリソースに左右されます。継続的に計測し、ボトルネックを特定して最適化します。
4.2.1ネットワークパフォーマンスの最適化
ネットワークは 遅延とスループット を計測し（Azure Network Watcher / Connection Monitor で経路と遅延を可視化）、SAP の要件に対するボトルネックを特定します。改善策は Accelerated Networking の有効化、近接配置グループ でアプリ↔DB を近接させる、適切な VM サイズ（NIC 帯域は VM サイズに依存）への調整、ExpressRoute の帯域見直しなど。「アプリ↔DB の遅延が高い」＝近接配置/Accelerated Networking/VM サイズを見直す、が定石です。
4.2.2アプリサーバーと DB の最適化
SAP の アプリケーションサーバー は負荷に応じて 水平スケール（アプリインスタンス追加）や 垂直スケール（VM リサイズ）でスループットを確保します。データベース（HANA 等） は適切な VM（メモリ/CPU）、ストレージ（IOPS/スループット・Write Accelerator）、インデックス/パーティション設計でチューニングします。継続改善のサイクル（計測→ボトルネック特定→最適化→再計測）を回し、Azure Advisor や Azure Monitor の知見を活かします。
決め手：「ネットワーク経路と遅延を可視化」＝Azure Network Watcher。「アプリ↔DB 遅延を下げる」＝近接配置グループ/Accelerated Networking/VM サイズ。「アプリサーバーのスループット確保」＝水平/垂直スケール。「DB 性能」＝VM・ストレージ(IOPS/Write Accelerator)・設計のチューニング。
混同に注意：
①ネットワーク最適化は計測(Network Watcher)→特定→改善のサイクルで、推測で構成を変えない。
②NIC 帯域は VM サイズに依存＝小さい VM では帯域が頭打ち。
③水平スケール(インスタンス追加)と垂直スケール(リサイズ)を使い分ける。
④DB の最適化はストレージ(IOPS/Write Accelerator)も含む。
4.2.3この節のまとめ
- ネットワークは Network Watcher で遅延/スループットを計測し、近接配置/Accelerated Networking/VM サイズで改善
- アプリサーバーは水平/垂直スケール、DB は VM・ストレージ・設計でチューニング
- 計測→ボトルネック特定→最適化→再計測の継続改善サイクルを回す
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. SAP のアプリ層と DB 層の間のネットワーク経路と遅延を可視化してボトルネックを特定したい。最適なのはどれですか？
Q2. アプリ↔DB の遅延が高い。改善策として最も適切なのはどれですか？
Q3. SAP アプリサーバーのスループットを、インスタンスを追加して確保したい。これは何と呼ばれますか？
Q4. 小さい VM で SAP のネットワークスループットが頭打ちになっている。原因として正しいのはどれですか？
Q5. SAP の継続的なパフォーマンス最適化の進め方として正しいのはどれですか？