この記事は、ユーティリティネットワーク展開をサポートする管理者、ITスタッフ、またはその他の技術スタッフが、そのワークフローに特有のログ情報をどのように解釈するかを理解するのに役立ちます。この記事は一部非常に技術的であり、ユーティリティネットワークを説明するために使用される概念や技術について深い理解が必要です。
編集：独自にログ解析と分析を行いたい場合は、この記事で使用されたチャートを生成するためのPythonツールの例をこちらで見つけることができます。
この記事は、ユーティリティネットワーク展開をサポートする管理者、ITスタッフ、またはその他の技術スタッフが、そのワークフローに特有のログ情報をどのように解釈するかを理解するのに役立つよう書かれています。この記事は一部非常に技術的であり、ユーティリティネットワークを説明するために使用される概念や技術について深い理解が必要です。
この記事を理解するには、まず以下の記事を読んで内容に慣れている必要があります：Utility Network Diagnostics 記事。その記事では、さまざまなユーティリティネットワーク操作のログ情報の取得方法について説明しています。この記事はそれらの概念を基にしており、これらのログを解釈するためのヒントや、システムのパフォーマンス評価に使用できるパフォーマンス指標の抽出方法を提供します。これらのログはArcGIS Monitorなどのツールの代わりではありませんが、潜在的なパフォーマンスボトルネックを調査するために詳細に掘り下げることができます。
なぜこれが重要なのか？
パフォーマンスを正確に測定し評価する方法を知ることは重要なスキルです。これにより、データモデリングやアーキテクチャ上の決定が及ぼす影響を定量化できます。この記事の結論部分には、これらの決定が及ぼす影響について議論したリソース集があります。
注意：この記事ではさまざまなチャートやログのスクリーンショットを表示していますが、作業用のサンプルデータは含まれていません。チャートは異なるデータセットとスケールを使用しており、それらから結論を導くべきではありません。この記事で説明されている手法を使って、ご自身のデータでテストを行い結論を導いてください。この記事で示されているログはArcGIS Enterprise 12.1から取得したもので、新旧バージョンでは異なるメッセージが表示される可能性があります。ログファイルの具体的な文言や構造は各リリースごとに変わるため、特定メッセージを暗記するよりもログ解釈方法を理解することが重要です。
この記事から得られるもう一つ重要なポイントは、ログがどのように使われるかについて考えることです。ログは重要なトラブルシューティングツールであるだけでなく、データモデリングの決定や設定、さらにはアーキテクチャがパフォーマンスやエンドユーザー体験に与える影響も示すことができます。
サーバーログは特定操作のパフォーマンス測定に役立つ詳細情報を提供し、多くの場合、その操作によって影響を受けたサブネットワークやフィーチャ数との相関も示せます。この重要性の例として、ユーザーからサブネットワークの更新が遅いという苦情があった場合を考えてみましょう。
通常のパフォーマンス評価では、システム内すべてのサブネットワークに対して単一プロセスで更新サブネットワーク操作を実行し、このサーバーから返された応答時間を示すグラフを作成します。このようなグラフになります：
応答時間分布を見ることは興味深いですが、一部応答が良好な理由やさらなる調査が必要な点について洞察は得られません。この方法では各応答を同等と扱いますが、サブネットワークの場合それは当てはまりません。ログファイルを解析すると、より実用的な洞察を提供するグラフが作成できます。
問題となっているサブネットワークを特定してレビューする簡単な方法として、ログからサブネットワーク名と応答時間を含むグラフを作成することがあります。
これにより調査対象となる特定サブネットワークをデータ内で見つけやすくなるだけでなく、システム全体の挙動も把握できます。これによって最良および最悪パフォーマンスのサブネットワークや外れ値も識別しやすくなります。
さらに少し手間をかければ、ログファイルから各サブネットワーク内フィーチャ数も解析できます。これによってX軸に各サブネットワーク内フィーチャ数を用いたチャート作成が可能になります。
このチャートによってネットワークサイズと応答時間との相関関係が見えやすくなります。ほとんどの場合、更新に時間がかかるサブネットワークほど大きいことがわかります。また予想より時間がかかっている小規模ネットワークも数件あり、それらに注目して調査できます。
さらに進めてログからより詳細な情報も解析し、各サブネットワーク内特定操作ごとのタイミングを見ることも可能です。
このチャートによって最も時間がかかっている操作およびサブネットワークがわかります。この詳細情報によって、それら特定操作のタイミング改善策検討につながります。
この記事では以下ログそれぞれについて時間解釈時に考慮すべき主なポイントをご紹介します：
- Tracing は TraceLog を使用します
- Update Subnetwork は UpdateSubnetworkLog を使用します
- Export Subnetwork は ExportSubnetworkLog を使用します
- Enable Network Topology と Validate Network Topology は BuildLog を使用します
個別ログについて話す前に、これらツールでパフォーマンス問題切り分け・トラブルシューティング支援する重要性について説明します。
パフォーマンス切り分け
ArcGIS Enterprise のパフォーマンス問題トラブルシューティング時、その原因は多岐にわたるアーキテクチャや設定、データ問題など様々です。調査対象問題がバージョニング不要なユーティリティネットワーク単一操作性能ならば、新しいモバイルジオデータベースへユーティリティネットワークコピーし依存関係減らして問題切り分けすると良いでしょう。
ローカルモバイルジオデータベースで作業するとArcGIS Enterprise展開アーキテクチャ関連変数なしでユーティリティネットワーク自体性能へ集中できます。一人ユーザー・非バージョニングワークフローへ焦点化可能です。
ローカル環境でのユーティリティネットワーク性能はエンタープライズ環境とは同等ではありません。しかしこれによって性能問題原因がユーティリティネットワークデータ・設定なのか環境アーキテクチャ・設定なのか判別可能です。
ローカル環境で再現できない場合でもローカルテスト情報活用しエンタープライズ調査支援可能です。ローカルジオデータベースとエンタープライズジオデータベース間で詳細ログ時間・ステップ比較し長時間要しているステップあればDBMS用ツール使った性能プラン評価など掘り下げ調査可能です。
ArcGIS Server ログ報告各操作時間とクライアント報告応答時間比較も可能です。この二者間で大きな差異や不整合応答時間あればクライアント・サーバー間通信問題示唆します。以下図は異なるログで捕捉されるタイミング例です。
クライアント応答時間測定にはアプリケーション層・サーバー層・データ層全体で要求完了まで費やした総時間含みます。この値は根本原因特定にはあまり役立ちませんが問題再現へ必要なコンテキスト・ワークフロー理解には重要です。
ArcGIS Server ログではサーバー層・データ層処理時間へ焦点当てつつ各要求コンテキストと処理時間も提供します。
データベース層性能レビューも特にDB関連問題時有益ですがクライアント・アプリケーション層コンテキスト欠如しています。
ローカルモバイルジオデータベースへデータコピーしArcGIS Pro の Diagnostic Monitor でログ取得すると性能問題切り分け強力になります。それぞれ操作ごとのワークフロー・コンテキスト制御可能になり依存関係最小限で性能測定できるためです。以下図をご覧ください。
性能問題切り分け理由と方法をご理解いただいたので次にユーティリティネットワークログから性能情報分析方法をご紹介します。
Trace Log（トレースログ）
Trace Log には4つの重要セクションがあります：
- 環境情報（Environment）
- トレースパラメーター（Trace Parameters）
- ステップとタイミング（Steps and times）
- ネットワークインデックス統計（Network index statistics）
システム全体性能評価時には通常、それぞれのトレース処理時間と返された要素数との比較を見ることが一般的です。この評価例としてユーティリティネットワーク内全てのサブネットワークごとにサブネットワークトレース実行し、その処理時間と各サブネット内要素数との関係を見るケースがあります。
同じサブネット上でもユーザー設定トレースかエクスポートまたは更新サブネット操作用トレースかによって性能値は異なります。トレース性能測定時には更新サブネット中標準設定によるサブネットトレース性能を見るべきです。またエクスポートサブネット利用予定ならば期待設定によるエクスポート中トレース性能測定計画も必要です。
特定サブネットパフォーマンス低下時には各ステップ処理時間と各サブネット要素数との比較を見ることで詳細分析可能です。
トレース操作に関連するさまざまなステップを見ると、なぜ特定のトレースに時間がかかるのか、そしてトレースの構成が全体のパフォーマンスにどれほど大きな影響を与えるかが理解できるようになります。
例として、関数や特定の結果タイプを追加した後のトレースのパフォーマンスをこのようなチャートで分析すると、それぞれが独自の操作として表示され、その関連コストとともに特定の変更のパフォーマンスコストを測定できます。
環境およびトレースパラメーター
構成セクションはトレースのコンテキストを理解するのに役立ちます。トレースの種類、バージョン、開始点、トレース構成、およびトレースに指定された結果タイプを伝えます。これらすべてのパラメーターがトレースの動作に影響します。いずれかを変更すると異なる結果が生じ、パフォーマンスにも影響を与える可能性があります。
ステップと時間
このログのセクションには、トレース中に実行されたすべての操作とそれぞれにかかった時間の詳細情報が含まれています。一部のステップには、そのトレース段階で関与したフィーチャ数に関する情報も含まれています。
時間を分析するとき、最初に確認したいのはトータルトレース時間であり、その後結果サイズを確認します。通過および返された要素数はステップと時間の最後に次の行で示されています：
トータルトレース時間は理解しやすく、これはトレースを実行するためにかかった合計時間です。発見された要素数はもう少し考慮が必要で、通過した要素数と結果内の要素数が含まれます。
これは重要です。多くのトレースは多くの要素を通過しますが、結果として返されるものはその一部だけです。少数のフィーチャしか返されなくても、多くのフィーチャを分析する必要がある場合があります。例としては上流または下流へのトレース、フィルターバリアが設定されたトレース、複数サブネットワーク内のフィーチャを発見するために更新サブネットワーク中に実行されるトレースなどがあります。このため、通過した要素数は結果サイズよりもパフォーマンス予測に優れていることが多いです。
また、個々のステップとその時間もレビューして、トレース中にどこで時間が使われているかを把握したいでしょう。
ネットワークインデックス統計
ネットワークインデックス統計は解析中にデータベースからどれだけネットワーク情報が読み込まれたかを示します。これらのログは通常、サポートや開発チームが特定問題を診断する際に使用されます。
このセクションには以下の統計が含まれます：
- トポロジーテーブル統計 – ネットワークトポロジーから読み取られた行数の概要。
- アソシエーションテーブル統計 – 読み取られたアソシエーション数の概要。
- ウェイトエンジン統計 – 読み取られたネットワーク属性数の概要。
- メモリマネージャ統計 – 使用されたメモリ量の概要。
このレポート内の統計を詳しく調べると、一部のネットワーク属性がウェイトエンジン統計セクションに報告されていないことに気づくかもしれません。それは network attributes stored in-line がトポロジーテーブル内に格納されており、フィーチャの接続性がデータベースからアクセスされる際に含まれるためです。ネットワークインデックスから読み取られる各アウトオブラインネットワーク属性には小さなコスト（通常、小規模ネットワークでは数ミリ秒程度）が伴います。しかし、多くのアウトオブライン属性が読み取られる場合やネットワークが大きい場合、そのコストは顕著になることがあります。
このため、多くのトレースで必要となるネットワーク属性はインラインで保存することを検討すべきです。特にサブネットワーク定義で参照される属性です。なぜすべてのネットワーク属性がインライン保存されないかというと、インライン属性用ストレージ容量には制限があるため、最も重要な属性を選んでインライン保存する必要があります。また、インライン保存されたネットワーク属性はネットワークインデックス統計には表示されません。
2つのテスト間で結果を比較しようとするときは、キャッシュミスも確認してメモリ内（キャッシュ）にどれだけあったかとデータベースから読み取られた行数を判断できます。
異なるトレースや操作間でパフォーマンス比較を行う際にはキャッシュミス数に注意することが重要です。完全にメモリから実行された（ホットキャッシュ）トレースは、接続情報をデータベースから読み込む必要がある（コールドキャッシュ）同じトレースよりも高速です。
ユーザーワークフローではこれを制御する手段はあまりありませんが、一貫したテスト方法論を設定して異なるテスト結果を正確に比較できるよう考慮することが重要です。一番保守的で一貫性ある測定方法はすべてのテストをコールドキャッシュ状態で実施することです。
更新サブネットワークログ
更新サブネットワークのパフォーマンス評価では、まず更新サブネットワーク操作中に作成された更新サブネットワークログを見ることから始めます。また、多くの場合、それぞれのサブネットワークに関連付けられたTrace Logもレビューします。これはサブネットワーク更新時に費やされる時間のおおよそ大部分を占めることがあります。
注：更新サブネットワーク用Trace Logを見ると、単純なトレース実行時とはステップや時間が異なることがあります。これはネットワーク構成によりますが、多重サブネットワーク内で要素検索により多く時間がかかったり（伝播ありの場合）、サブネットワークリニアジオメトリ取得や集約線用関数計算にも時間がかかったりします。
Trace Log同様、更新サブネットワークログにも3つのセクションがあります。
- 環境
- サブネットワークパラメーター
- ステップと時間
- ネットワークインデックス統計
更新サブネットワーク性能評価では以下情報を考慮します：
- サブネットワーク更新にはどれくらい時間がかかったか？
- 更新対象となったサブネットワークはどれくらい大きかったか？
- 何個のフィーチャが更新されたか？
最初の2つはログから簡単にわかります；最後はログを読んで変更されたフィーチャ数を調べる必要があります。
システム全体性能評価では通常、それぞれのサブネットワーク更新時間とそのサブネット内フィーチャ数との関係を見ることになります。
この分析では3つの場合について考慮できます：
- 最初の更新サブネットワーク操作にはどれくらい時間がかかるか？
- 何も変更されていない場合、サブネットワーク更新にはどれくらい時間がかかるか？
- 適度な数のフィーチャ変更時にはどれくらい時間がかかるか？
通常は適度な編集数でupdate subnetwork を実行した場合にどれくらい時間がかかるかに注目します。それこそユーザーの日常的な作業体験だからです。最初のupdate subnetwork は最も時間消費的なのでシステム導入時には必須です。また変更なしシナリオも性能面ではベストケースなので興味深い比較対象となります。
パフォーマンス低下しているサブネットワークを見つけたら個々ステップごとの時間を見ることで特定ステップで大半時間消費しているかどうか判別できます。
update subnetwork 操作中に実行されるtrace と通常サブネットワークtrace の所要時間比較では前者が長くなる傾向があります。その理由はupdate subnetwork が集約用ジオメトリ読み込みや集約線用関数計算、多重サブネット内要素検索など追加処理を行うためです。
環境およびサブネットワークパラメーター
ログ構成セクションを見る際には以下構成項目に注意してください：
バージョン名と編集モードは重要です。編集モードによってupdate subnetwork の動作や所要時間が異なる場合や、それがデフォルト版なのか名前付きバージョンなのかによって違いがあります。この点について詳しくは Understanding Subnetworks: Edit mode 記事をご覧ください。簡単に言うと、「with events」編集モードでは属性ルールによる追加パフォーマンスコストがあります。「without events」編集モードで名前付きバージョンの場合、一部フィーチャ全て更新されない可能性があります。
またティア名も性能評価時には重要です。このティア構成によってupdate subnetwork の動作（サブネットライン作成・更新やネットワーク図など）が制御されます。
ステップと時間
ステップと時間を見る際には主に以下セクションに注目します：
- Trace
- 各種アップデートステップ（Connectivity, Content など）
- サブネットライン管理
- ネットワーク図管理
- 合計（Total）
Trace ではtrace に要した時間と何よりも発見されたサブネット内フィーチャ数を見ることになります。
次に永続化されたサブネット情報（名前、接続状態など）追跡用DB属性アップデート所要時間を見るでしょう。
サブネットライン管理やネットワーク図管理所要時間は通常かなり短いですが、大幅な場合はそれら設定見直しも検討してください。
合計行（Total）はサブネット更新全体所要時間を示します。
ネットワークインデックス統計
update subnetwork 用network index 統計レビュー時にはTrace Log と同様な考慮事項があります。
エクスポートログ (Export Log)
export subnetwork の性能評価では以下3点について考えます：
- 'What result types, attributes, etc. were exported?' は「どんな結果タイプや属性などがエクスポートされたか？」という意味です（訳文保持）。
- 'How long did it take to get all the information that was requested by the trace to be exported?' は「trace によって要求されたすべて情報取得にはどれくらい時間がかかったか？」という意味です（訳文保持）。
- 'How long did it take to generate the file?' は「ファイル生成にはどれくらい時間がかかったか？」という意味です（訳文保持）。
これらの質問に答えるには、主にExport Logを参照します。エクスポートサブネットワーク操作の一部として実行されるトレースに対してTraceLogが生成され、操作中に費やされた時間の詳細な内訳が必要な場合に役立ちます。
Export Logには5つの異なるセクションがあります：
- 環境
- サブネットワークパラメーター
- エクスポートパラメーター
- ステップとその時間
- ネットワークインデックス統計
エクスポートサブネットワークの全体的なパフォーマンスを評価する際には、エクスポートサブネットワークの実行にかかった時間とエクスポートされるフィーチャ数を比較したいです。ただし、TraceLogやUpdateSubnetworkLogとは異なり、トレースによって返されたフィーチャ数のカウントは含まれていません。
しかし、フィーチャのカウントはTraceLogから抽出できます。
エクスポート操作中にサブネットワークのパフォーマンスが低い場合は、エクスポートログでどこに時間が費やされているかを確認します。ほとんどの時間がトレースに費やされている場合は、トレースログを確認します。この際、エクスポート時のトレースで費やされた時間と通常のサブネットワークトレース（結果タイプや関数を含まない）で費やされた時間を比較することがよく役立ちます。
この方法により、エクスポートサブネットワークのトレース中に各結果タイプ（接続性、フィーチャ要素など）を取得するのにどれだけ時間がかかっているか、およびトレース自体にどれだけ時間がかかったかを特定できます。エクスポート時のトレースは、データベースから追加情報を読み取る必要があるため、通常のトレースよりも常に時間がかかります。エクスポート時のトレースログの詳細を見ることで、各結果タイプの取得にどれだけ時間がかかっているかがわかります。
だからこそ、必要な属性やその他の情報だけをエクスポートすることが重要です。不必要な情報をエクスポートするコストは高くなる可能性があります。
環境とパラメーター
Export subnetworkには多くのオプションがあり、何をエクスポートできるかを制御します。しかし、エクスポートに含める情報が多いほど、その情報を収集するために使用されるトレースは長くなります。含める情報が多いほどファイルサイズは大きくなり、ファイルの生成およびダウンロードにも時間がかかります。
ユーザーがエクスポートに含めるよう指定した情報は、レポートのエクスポートパラメーターセクションで確認できます。これにより、含まれる結果タイプと選択されたネットワーク属性数、結果フィールド（フィーチャ用）、関連レコードフィールド（関連レコード用）がわかります。
フィーチャおよび関連レコードから多くの属性を含めるには、データベースへの追加クエリが必要となり、この情報取得のためにトレース時間が増加します。さらに、多くの属性を選択するとファイルサイズが大幅に増加します。サブネットワークのすべてのネットワーク属性を含めるとファイルサイズとエクスポート時間が倍増します。複数テーブルから属性を含めるとパフォーマンスへの悪影響はさらに大きくなります。
ステップと時間
Export subnetworkログで分析すべきステップは少ないです。ほとんどの場合、トレースがexport subnetwork中で最もコストが高いです。ただし、Process/Write JSONステップで大量の時間が費やされている場合、それはファイルサイズが大きくシリアライズ、ダウンロード、および永続化に長時間かかっていることを示しています。
ネットワークインデックス統計
export subnetwork用ネットワークインデックス統計の検討事項はTrace Logの場合と同じです。
Build Log
ビルドログの形式は他のユーティリティネットワーク診断ログとは異なり、長時間実行される可能性のあるセッション中にインクリメンタルに生成されるログとして設計されています。そのため、ビルドログ内の各行はステップ完了までにかかった時間、その時点までの合計時間、およびその瞬間に使用されたメモリ量を報告します。
同じログファイル形式は以下3つすべてのビルド操作で使用されます：
- Enable Network Topology
- Disable Network Topology
- Validate Network Topology
このため、一部ログではステップ番号が飛んでいるように見えることがあります。これはすべてのステップがすべての操作に適用されるわけではないためです。
ログレビュー時には以下セクションに注目してください
- 環境
ステップとその時間
- ネットワークインデックス統計
パフォーマンス評価ではどんなビルドが行われているか、処理されるネットワーク属性数、利用可能なメモリ/ディスク容量、Validateによって影響を受けたサブネットワーク特定分析（ビルド後処理）が行われたかどうか、および処理されるフィーチャ数を考慮します。この情報は主に環境およびビルドネットワーク設定セクションで確認できます。
Enable Network TopologyおよびDisable Network Topologyではスループット、メモリ使用量、およびディスク使用量が主な関心事です。メモリ依存度が高いほど高速ですが、大規模データセットでは現実的ではありません。その場合ビルドはディスクへの書き込みを開始し、その際には設定されたディスク（理想的にはSSD）が高速で十分な空き容量があることを確認する必要があります。
Validate Network Topologyではユーザーが通常呼び出すためビルド全体所要時間が主な関心事であり、待機時間を最小限に抑えたいです。Post build processingで大量の時間消費を観察した場合は次の記事をご覧ください：Understanding Subnetworks Status article. この動作は各ティアごとのサブネットワーク定義によって制御されており、ユーティリティネットワーク展開後でも変更可能です。サブネットワーク上で状態フィールド維持設定されたユーティリティネットワークはValidate Network Topology中にビルド後処理を実行し、有効化によって影響を受けたサブネットワークを特定して汚染済みとしてマークします。
環境およびビルドネットワーク設定
検証範囲はビルドログ内環境セクションで示されます。この範囲はValidate Network Topology評価時のみ意味があります。Enable Network TopologyおよびDisable Network Topologyは常にネットワーク全範囲で実行されます。
ビルドネットワークステップおよびログファイル名から実施されたビルドタイプがわかります。またプロセス開始時点で利用可能だったネットワーク属性数、メモリ、およびディスク容量も確認できます。ビルド中使用メモリ量が利用可能メモリ量を超えるとプロセスはディスク書き込みを開始し遅くなります。
ステップとその時間
ネットワークビルドプロセスには多くのステップがあります。ここですべて説明しませんがログレビュー時には以下点を念頭に置いてください：
- このステップでどれだけ多くの情報が処理されたか？
- このステップでどれだけ多くの情報が作成されたか？
- このステップでどれだけ多くの時間/メモリが使われたか？
各ステップは通常、そのステップ完了までに要した合計時間を最後のメッセージで報告します。
全操作所要合計時間はログファイル最後行を見ることでわかります。
使用メモリ量特定には、そのステップ最初と最後のログメッセージで報告された合計メモリ量を比較してください。
ネットワークインデックス統計
ネットワークビルドプロセスはネットワークインデックスも構築するため、このセクションではシステムテーブルが処理中に読み取り・書き込み・作成した情報量把握に役立ちます。ただしユーティリティネットワーク展開後はこれら数値への影響力はほぼありません。
プロジェクト初期段階ならば保有しているネットワーク属性数による影響を見ることができ、この機会にモデル内で本当に必要な属性のみ要求しているか確認できます。もしどんなワークフローでも不要ならばモデルから削除検討してください。一度展開すると追加可能ですが削除できません。
関連レコードを関連レコードとしてモデル化し続けるべきか、それとも接続性や包含関係付き非空間オブジェクトとしてモデル化すべきか検討している場合、それら非空間オブジェクト組み込みによるビルド所要時間を見ることもできます。
結論
この記事を読んだことでユーティリティネットワーク主要4操作それぞれについてログ解釈方法になじんだでしょう。性能テスト実施や詳細結果解釈も始められます。またアーキテクチャ設計や重要なデータモデリング決定時には、それら決定による性能影響測定も可能です。
性能数値収集・測定へより体系的アプローチには次ツール利用も検討ください： Extract Log Files. この記事内グラフィックは各ログファイルから正規表現で性能数値抽出し可視化作成した手法によります。
これらログファイルはサーバー特定操作実行時間精密測定手段として重要です。一操作評価には非常に有用ですが全体像提供しません。性能分析はユーティリティネットワーク性能だけでなく全体アーキテクチャ影響や負荷下システム性能も考慮した包括的実施必須です。
より包括的テスト・設計例についてはこちらをご覧ください： ArcGIS Architecture Center.
関連レコードモデル化による性能影響例についてはこちらの記事をご参照ください： Modeling related data in a utility network.
サブネットワークの編集モード設定が更新サブネットワークのパフォーマンスにどのように影響するかの例については、Understanding Subnetwork Edit Modeの記事をお読みください。
サブネットワークのステータス管理設定がネットワークトポロジー検証のパフォーマンスにどのように影響するかの例については、Understanding Subnetwork Statusの記事をお読みください。
