ArcGIS Server パフォーマンス戦略

Aaron Lopez

パフォーマンス：課題と戦略

ArcGIS Enterpriseは、サービスやウェブアプリケーションを通じてユーザーにGISリソースを提供するための堅牢でスケーラブルなプラットフォームを提供します。しかしながら、時には公開されたリソースエンドポイントからのパフォーマンスが遅くなることがあります。

 

ArcGISは非常に多用途であるため、これらのリソースを利用可能にする際にはさまざまな方法、構成、およびオプションがあります。

良好なパフォーマンスを得ることは、「fast = true」という設定を切り替えるだけで簡単かつ直接的に達成できるわけではありません。

ある管理者にとって便利な機能が、他の人にとっては役立つ一方でパフォーマンスに干渉する構成である場合もあります。 

 

実際の世界では、パフォーマンスはしばしば複数の項目や構成設定の関数です。最も一般的なものを理解し克服するための戦略を持つことは、展開をより高速なパフォーマンス達成への道に乗せるのに役立ちます。

パフォーマンスとは何か？

パフォーマンスとは、特定の関心機能に対してサーバーまたはサービスがどれだけ速く（または遅く）動作するかの説明です。ArcGIS Server service がクエリ、applyEdit、またはexportなどの操作を完了し、その後要求したclientに応答を返すまでにかかる時間がパフォーマンスの例です。

 

この期間は秒またはミリ秒で測定され、一般的に応答時間と呼ばれます。

「応答時間」と呼ばれていますが、クライアント（ウェブブラウザやArcGIS Proなど）が要求したサーバーリソースを待つ全体時間を構成するいくつかの重要なステップがあります：

1. サーバーのホスト名のDNSルックアップ
2. クライアントとサーバー間のSSLハンドシェイク
3. クライアントとサーバー間のTCP/IP接続
4. サーバーへのリクエスト送信
   1. サーバーによるリクエスト処理
5. サーバーからの応答受信
   1. 大きな応答の場合、Time-to-first-byte（TTFB）を代わりに使用して応答時間を測定できます

通常、大部分の時間は4.1で費やされます。ここがサーバーが応答処理を行っている場所です。

このコミュニティ記事では、この応答時間部分に影響を与える可能性がある領域について探ります。

なぜパフォーマンスが重要なのか？

簡単に言うと：パフォーマンスが速いほど応答時間は短くなります。 

応答時間が短いほど、サーバーは同時により多くのリクエストを処理できます。

この高い同時処理能力はより大きなスケーラビリティにつながり、最終的にはより多くのユーザーへの対応を意味します。

 

パフォーマンスは、一度に単一操作を完了するために必要な時間単位（例：フィーチャークエリ要求を実行するのに0.238秒）として測定されます。 

一方でスケーラビリティは、多くの場合トランザクション数や操作数／時間（例：requests/sec または operations/hour）として測定されます。

 

より良い、高速または「より多く」のパフォーマンスについて話す場合、それは低い応答時間の達成を意味します。一方で、より良いスケーラビリティはより高いスループット率（例：operations/hour の増加）に到達することを意味します。

 

注意：もちろん、より良いパフォーマンスやスループットを得るためには、関心のある操作が適切に実行され、期待されるコンテンツ（例：マップ画像、json または pbf データ）で応答する必要があります。例えばエラーメッセージは高速で単純な応答であり、その配信は高いスループット率に達することがあります。テスターや分析者として、この種のスループットは求めているものではありません...我々が興味があるのは成功したリクエストのスループットです。

許容可能なパフォーマンスとは？

それは状況によります。 

高速（または遅い）パフォーマンスとして分類する基準や要件は組織ごとに大きく異なることがあり、公開されたサービスやユーザーが呼び出す予定の操作によっても異なります。

ArcGIS Server機能やユーザーアプリケーションワークフロー（複数リクエストがグループ化されて一つの操作を表す）のために異なる応答時間目標を持つことも珍しくありません。

任意の秒数でも要件として問題ありませんが、積極的な目標を達成するにはより多くのハードウェアおよびより広範囲なチューニングや戦略（本記事）が必要になることも念頭に置いてください。

パフォーマンスはどのように測定されるか？

応答時間は、パフォーマンスが目標要件内または以下であるかどうか判断するための主要指標です。

一般的な測定戦略には以下があります：

• 単一ユーザーインタラクション
  • ウェブブラウザまたは ArcGIS Pro を通じて
    • これが最も簡単な開始点です
      • まだパフォーマンスについて理解がない場合はここから始めてください
• 大量の応答時間データの統計解析
  • ログ解析ツール、ArcGIS Server Manager 統計ページ、その他観測ユーティリティ経由で
    • これらの方法には展開済み環境でユーザーが既に実行した実際のリクエスト分析という利点があります
  • この記事後半でさらに詳しく説明します
• 負荷テスト
  • パフォーマンスおよびスケーラビリティについて理解できます 
  • セットアップにはより多くの時間がかかります
  • 開始用オンラインリソースがあります
    • Performance Engineering: Load Testing ArcGIS Enterprise 

ログ分析やテスト実行時によく使われる戦略として、大量の応答時間データを分解するために統計情報を活用します。平均値および90th（または95th）パーセンタイル、最小値および最大値によってユーザーが経験した可能性のあるパフォーマンス理解が得られます。

応答時間取得 -- ウェブブラウザ

単一ユーザーインタラクションからどのように応答時間が取得されるかは興味深い話題です。

ウェブアプリケーションからREST要求の応答時間を取得する最も簡単な方法はブラウザの「開発者ツール」機能です。主要ブラウザすべてが送受信される要求・応答・時間を見る機能を提供しています。この期間から要求や操作（複数要求の場合もあり）がどれだけ速く実行されたか把握できます。そしてこれが許容範囲か改善すべきか判断できます。

 

応答時間取得 -- ArcGIS Pro

ArcGIS ProもREST経由でArcGIS Enterpriseと通信しますが、開発者ツール相当機能は内蔵していません。応答時間取得には別途HTTPデバッガーが必要です。多数ありますが人気なのはFiddlerです。

FiddlerをArcGIS Proと同じマシンにインストールするとトラフィック傍受設定可能です。要求パラメータ、応答内容および時間も同様に取得・検査できます。

パフォーマンス向上には目標設定が必要か？

絶対に必要ではありません。GIS管理者は公式なパフォーマンス要件なしでも常にシステム分析・チューニング・ベストプラクティス適用可能です。
しかしながら調整前にシステム初期状態でどんなパフォーマンスを提供しているか理解しておくこと（通常ベースライン応答時間数値と呼ばれる）は強く推奨されます。こうして適用変更効果が正なのか判断できます。

一般的なパフォーマンス課題と潜在的戦略

サービスプールタイプとインスタンス数

ArcGIS管理者が頻繁に直面するパフォーマンス課題領域の一つはdediated(専用)サービス向け適切なインスタンス数設定ですが、その前に異なるタイプについて復習しましょう。 3種類あり、それぞれ長所があります。

</ DIV >< UL >< LI >< STRONG >Dedicated(専用)</ STRONG ></ LI >< LI >< STRONG >Hosted(ホスト)</ STRONG ></ LI >< LI >< STRONG >Shared(共有)</ STRONG ></ LI ></ UL >< DIV >< P >GIS管理者としてインスタンスタイプ識別できることが重要です service.<\/P>これは ArcGIS Server Manager の Manage Services 内で簡単に確認できます:<\/DIV>

 <\/DIV>

<\/span><\/P><\/DIV>適切なタイプの選択<\/SPAN><\/H3>最も高いパフォーマンスとスケーラビリティの制御を達成したい場合は、専用サービスタイプを選択するのが理想的です。<\/U>このタイプでは、管理者は以下を行うことができます:<\/P><\/DIV>利用可能な処理能力を最大限に活用するために、CPUコア数と同じ最大インスタンス数を設定する（最大値を通じて）<\/SPAN><\/LI>アイドル時のメモリ消費を抑える（最小値を通じて）<\/SPAN><\/LI>最小値と最大値を同じに設定して予測可能なパフォーマンスを調整する<\/SPAN><\/LI><\/UL>専用サービスは、要求が多いサービスやパフォーマンスが最重要なサービスに最適です。<\/P>ホストされたサービスは ArcSOC インスタンスを使用せず、必要に応じて自動スケールします。ただし、主にフィーチャークエリで使用されるため、利用可能な ArcGIS 機能は制限されています（Hosted）。<\/P>共有サービスは、要求頻度が低いアイテムへのアクセスに適しています。通常、より多くの ArcGIS 機能が利用可能ですが、すべての ArcGIS 機能（例：ブランチバージョニング）が利用できるわけではありません。共有インスタンスプールは ArcGIS Pro でサービスを公開する際のデフォルトタイプです。<\/U><\/P>注意: 選択したサービスタイプが専用に設定されている場合、(最小および最大) インスタンス数が最適かどうか評価することが重要です。ArcGIS Pro で公開するときのデフォルトは最大2インスタンスのみ使用する設定です。これはパフォーマンスやスケーラビリティが重要なサービスには低すぎて不十分な場合があります。<\/STRONG><\/FONT> <\/SPAN><\/P><\/DIV>マップの焦点合わせ<\/H2>マップの最適化は新しい戦略ではありませんが、展開からより良いパフォーマンスを得るために比較的簡単に実行できる方法です。
マップがその主目的と表示に焦点を当てているとき、システムは不要な作業を行う必要がありません。ウェブはマルチユーザープラットフォームであることを忘れないでください。動的データの表示をできるだけ効率化することが良好なパフォーマンス（およびスケーラビリティ）の鍵です。同時に多くのリクエストが発生する可能性があるため、共有されるコンテンツはできるだけ効率的である必要があります。<\/P><\/span>マップ戦略<\/SPAN><\/H3>最適なデフォルト範囲を選択する<\/SPAN>マップがロサンゼルスのデータを提供している場合、デフォルト範囲はカリフォルニア全体を表示すべきではありません<\/LI>多くの異なるマップスケールが必要な場合は、スケール依存性と一般化を使用して詳細度を必要なとき（例：最大スケール）に制限します<\/LI><\/UL><\/LI>不要なレイヤーを削除するあったら便利なデータレイヤーの削除も検討してください少なくとも選択解除し、ユーザーが有効化するオプトイン方式にしてください<\/LI><\/UL><\/LI><\/UL><\/LI>ユーザーがサービスでできることを意図的に制限する<\/LI>オンザフライ投影変換を避けるデータフレームとデータで同じ座標系を使用する<\/LI><\/UL><\/LI>定義クエリ属性列への比較ロジック適用時にはインデックスがあることを確認してください <\/LI><\/UL><\/LI><\/UL>注意: 「マップの焦点合わせ」はマップ、アプリ、およびサービスに適用されます<\/FONT><\/STRONG><\/DIV>ソフトウェアリリース<\/H2>特定バージョンの ArcGIS Enterprise（および関連ソリューション）は初期ベースリリース後に複数のパッチが存在することがあります。これらのパッチはパフォーマンス向上や機能・セキュリティ修正を提供します。 <\/P>定期的にEsri Patches and Updates<\/A> サイトを確認するか、「Check for ArcGIS Enterprise Updates」ツールを実行し、適切なタイミングで更新プログラムを適用することを強く推奨します。<\/P>

リソース競合と拡張<\/H2>ベストプラクティスやパフォーマンス戦略が適用されていても応答時間短縮やスケーラビリティ向上がまだ必要な場合があります。現在 ArcGIS Server を稼働させているハードウェアの処理能力やメモリがボトルネックとなりユーザー体験改善の妨げになっている可能性があります。<\/P>そのような状況ではハードウェアの拡張やアップグレードを検討する必要があります。<\/DIV>

スケーラビリティ<\/SPAN>

ArcGIS Server と ArcGIS Web Adaptor の展開層については、ハードウェアによる 一般的に 次のオプションがあります:スケーラビリティ 向上のため:<\/> <\/> <\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/>


スケールアップ




既存マシンへのリソース追加（例：追加処理コア）




追加メモリも同時実行 ArcSOC インスタンス数増加によるスケール支援になる

 





クラウド、仮想化、Kubernetes などの展開に理想的






スケールアウト




同等リソース容量のマシン追加




オンプレミス、クラウド、仮想化、Kubernetes などの展開に理想的




id="toc-hId-333806091">Observability

「Quantifying ArcGIS」は素晴らしい戦略であり、個人的なお気に入りです。これは、どのリソースが要求されていたか、そしてこれらの要求に対する応答がどれだけ速かったかを定義します。一般的なシステムパフォーマンスの理解を得るために重要です。システムリソースの利用状況もキャプチャできれば、分析はさらに高度になります。

システムを定期的に調査するための多くのユーティリティがあります。いくつかのツールはアクセスログを読み取り、主にユーザーによる統計的なリクエストパフォーマンスに焦点を当てます。他のツールはServerの統計ページをポーリングし、その期間中のCPU使用率（ArcGIS Serverまたはデータベースの）をキャプチャします。どのアプローチが最適でしょうか？もし現在observabilityが行われていない場合、おそらくどれか一つでも良い追加となるでしょう。これらはすべて、デプロイメントのパフォーマンスと健全性に関する何らかの洞察を提供するのに役立ちます。 

デプロイメントの分析が行われると、通常、次の理由で関心があるかもしれないマップサービスを強調するレポートが生成されます：

• 観測された応答時間が予想より遅い
• リソースへのリクエスト数
• 応答時間とリクエスト数の両方

多くのサービスを持つArcGIS Siteでは、統計的に遅いものや最も多くのリソースを消費しているものを知ることはチューニング作業に集中する助けになります。このようなレポートにより、GIS管理者はデータを価値ある情報に変換し、ユーザー体験向上のための意思決定においてより良い判断ができるようになります。とはいえ、ログや統計の検査は分析全体の一部（重要な部分）に過ぎません。

一般的なObservabilityツールの課題

多くのシステムobservabilityおよび監視ツールは、サービスへのリクエストとレスポンスに分析を集中させています。これは良いアプローチであり、確かに管理者がArcGISを定量化する助けになりますが、制限もあります。その制限は、遅いマップサービスは単純に処理コアを追加することで「修正」できるという仮定から生じることがあります。より多くのコアは状況の一部を改善するかもしれませんが、追加リソースを取得する前にサービスをより深く（再度）検査することが推奨されます。

これは「Focus the Map」セクションに戻ります。例えば：

• サービスのデータがあまりにも小さいスケールで表示されていないことを確認する
• 最適でないクエリを避ける

詳細なクエリ分析は、一般的なサービスレポートでは隠れてしまう可能性があるこれらの挙動の発生を示す助けになります。しかしながら、サービスリクエストパラメータと基礎となるクエリの内訳は分析を改善できますが、それ自体で報告に複雑さ（例：実行時間増加、見るべきビューが増えること、それらビューの理解）が加わります。さらに、すべてのobservabilityツールがこの種の検査を行うわけではありません。

最近注目されている取り組みとして、この問題に取り組もうとしているものがあります。それらは「query datastore」として知られるメカニズムを通じて基礎となるデータベースクエリ自体から始まるボトムアップ分析アプローチに基づいています。query datastore分析は強力であり、trace のようにデータベースパフォーマンスに影響を与えませんが、それにはクエリ自体とその目的についてある程度知識が必要です。将来的には、この種の分析機能によってobservabilityツールから最大限の効果を得られるようになるでしょう。

結論

ArcGIS Enterprise Site のパフォーマンスとスケーラビリティを簡単に向上させる単一項目はありません。しかし、本記事ではそれらを改善するために一緒に適用できる一般的な戦略をいくつか挙げています。また、これらは定期的に見直し対応すべき項目であることも重要です。ユーザー習慣は時間とともに変化し、ウェブアプリケーションやサービスの人気も変わります。特定サービスに割り当てられたリソースは再評価または削減され、新たな注目アイテム用スペースとなることがあります。

ArcGISパフォーマンス分析は楽しいものですが、最高のユーザー体験維持には継続的な努力も必要です。

 

 

帰属

 

Resource: File:Grayson_running_the_4x100.jpg

Description: 英語: 2010年Tigered招待競技会で4x100メートルリレー第1走者として走るGrayson

Author: Graysonbay

Created: 2010年11月29日 02:02

License: このファイルは Creative Commons Attribution 3.0 Unported ライセンスです

 

Resource: File:Kurvimeter_1_fcm.jpg

Author: Frank C. Mfcller, バーデン＝バーデン

License: このファイルは Creative Commons Attribution-Share Alike 4.0 International ライセンスです。

 

Resource: File:My_Opera_Server.jpg

Description: My Home用サーバー

Author: William Viker, william.viker@gmail.com (c) 2006

License: このファイルの著作権者は誰でも 著作権者が適切に帰属されることを条件としてあらゆる目的で使用することを許可しています。 再配布、派生作品、商用利用およびその他すべての使用が許可されています。

 

Resource: File:Samsung-1GB-DDR2-Laptop-RAM.jpg

Description: 2007年製MacBookノートパソコンから取り出されたSamsung製DDR2 667 MHz (PC2-5300) 1ギガバイトRAMスティック。

Author: Evan-Amos

Created: 2018年8月1日

License: Public Domain

AndreaB_

@AaronLopez Wonderful, thank you so much! Exactly the clarification and info that I needed and couldn't find all in one spot, (or anywhere, in some cases)! I'll be thinking about all of this as I try to get the response times lower than 0.5 seconds for these map services.