DNS、命名、URL

ArcGIS Enterprise のデプロイメント、および ArcGIS Online またはその他のアプリケーションにおける ArcGIS Enterprise サービスの使用では、DNS、命名規則、URL の使用が、システム内のアクセシビリティと効率的な通信を支える重要な側面となります。 DNS はすべてのシステム間通信の基盤として機能し、人間が読めるドメイン名を必要な IP アドレスに変換し、ユーザーとアプリケーションがインターネットまたはイントラネット上のリソースを見つけることを可能にします。 DNS に加えて、命名規則は URL やホスト名に基づいてシステムを識別できるようにするのに役立ちます。よく使用されるアプリケーションにわかりやすい URL を使用することは、ユーザーがアプリケーション情報を覚えやすくするだけでなく、組織名やわかりやすい短縮名を含めることで、アプリケーションの外部向け「ブランド」を管理するための一般的なアプローチです。

命名規則

サーバー、環境、ArcGIS デプロイメントが複数あるシステムでは明確な命名規則を定めることが重要となります。 こうした規則には、ArcGIS Server のサイト、サービス、Web マップ、データベース、サーバー マシンなど、さまざまな要素に明確な意図を持って名前を付けることが含まれます。 構造化され、整理された命名アプローチは管理者がリソースを特定するのに役立つだけでなく、ArcGIS Enterprise デプロイメントの体系的な管理にも大きく貢献します。

サービスとデータ レイヤーに明確で標準化された名前を使用すると、ユーザーと開発者はそれらを効率的に見つけて参照できます。 論理的な命名規則の使用には次のようなものがあります。

  • サーバーやサービスの目的を示す文字を使用する (例: データベースは D、アプリケーションは A、Web サーバーは W)。
  • サーバーが参加する環境を区別するための文字を使用する (Development の D、Acceptance の A、Production の P など)。
  • GISSERVER01、GISSERVER02 など、役割が共通するサーバーを区別するための番号を使用する。
  • \\gisshare01 と呼ばれる UNC 共有などの共有のフレンドリー名 (より複雑な名前のサーバー上に存在する可能性がありますが、フレンドリー名を使用するとユーザー側の操作が容易になります)。
  • ArcGIS Enterprise にわかりやすいエイリアスを使用する (https://giswebsrv01.prd.orgname.net/portal の代わりに https://maps.orgname.com/portal を使用するなど)。

こうした例は一貫性のある命名規則を策定するための第一歩にすぎません。一般に、IT 組織で確立しているであろう既存の命名標準に合わせることが推奨されています。ユーザー向けの URL については例外で、短く覚えやすいよう意図的に構造化する必要があります。

重要な URL

URL (Uniform Resource Locator) は、ArcGIS Enterprise エコシステム内のさまざまなコンポーネントやリソースのアドレス指定とアクセスを実現する上で重要な役割を果たします。 重要な URL には、Portal for ArcGIS へのプライマリ エントリ ポイントとして機能するポータル URL や、マップ、フィーチャ、ジオプロセシングの各サービスなどのさまざまなサービスへのアクセスを容易にするさまざまな ArcGIS Server URL が含まれます。 さらに、Web アプリケーションの URL、ArcGIS REST API エンドポイント、ロード バランサーの URL (高可用性シナリオの場合) はすべて、シームレスな通信とアクセシビリティを確保する上で重要な役割を果たします。

ArcGIS Enterprise デプロイメントの重要な URL には、次のものがあります。

  • ポータル URL: Portal for ArcGIS にアクセスするための URL は、ユーザーと管理者のプライマリ エントリ ポイントとして機能します。
  • ArcGIS Server URL: ArcGIS Server サービス (マップ サービス、フィーチャ サービス、ジオプロセシング サービスなど) にアクセスするための URL です。
  • Web アプリ URL: ArcGIS Web AppBuilder やカスタム Web アプリなど、ArcGIS Enterprise 上に構築された Web アプリケーションの URL です。
  • ArcGIS REST API エンドポイント: ArcGIS REST API とやりとりするための URL を使用すると、サービスとデータへのプログラムによるアクセスが可能になります。

ArcGIS Enterprise ドキュメントには ArcGIS URL のコンポーネントという専用ページがあり、追加のコンテキストとガイダンスが記載されています。

URL の耐久性

ArcGIS Enterprise デプロイメント、または ArcGIS Enterprise サービスを統合する ArcGIS Online デプロイメントでは、URL の耐久性が極めて重要です。 つまり、ArcGIS Enterprise デプロイメントまたはコンポーネントの URL をいったん定義したら、システムの残りの有効期間を通じて URL が変更されないのが理想的です。 この推奨の理由は、システムの多くのコンポーネントが自己参照型であるためです。マップ サービスへの参照を含む Web マップに、ジオプロセシング サービスを参照するジオプロセシング ウィジェットを使用して Web アプリでアクセスするケースを想像してみてください。 アプリを機能させるには、これらの各 URL が適切に解決され、適切なサービスに到達する必要があるため、耐久性が高いほど、アプリが適切に機能する可能性が高くなります。

次の推奨事項はベスト プラクティスと見なすことができます。

  • 慎重に計画することなく、ArcGIS Enterprise システムの外部 URL を変更しようとしないでください。
  • ArcGIS Server の URL が変更された場合、またはロード バランサーが導入されて新しい URL が作成された場合は、ArcGIS Enterprise または ArcGIS Online のコンテンツを慎重にチェックして、Web マップ、アプリ、アイテムが新しい URL を反映するように適切に更新されていることを確認してください。
  • URL の耐久性は資産となりえます。わかりやすい URL (または「DNS エイリアス」) が使用されている場合、そのエイリアスが指し示すシステムを置き換えることができるため、ダウンタイムの少ないアップグレードとブルーグリーン デプロイメント スタイルが可能になります。

TLS 証明書と SSL 証明書

最新の ArcGIS デプロイメントは全般的に、TLS/SSL を使用した HTTPS 経由の安全な通信を可能にするために、証明書に依存しています。 適切な TLS/SSL 証明書の構成は、特に機密データを扱う場合に不可欠です。 組織では多くの場合、信頼できる認証局 (CA) から TLS 証明書を取得します。これは、ほとんどのデバイスで信頼されている商用 CA か、「ネットワーク上」のコンピューターとクライアントまたは WAN によってのみ信頼されている組織かプライベート CA のいずれかです。 証明書を作成したら、Apache や IIS などの Web サーバーを使用して構成するか、ArcGIS コンポーネントにインポートして、暗号化されたセキュアな通信を確保します。

  • ArcGIS Enterprise 内の TLS/SSL 構成の特定の要件の詳細については、製品ドキュメントをご参照ください。

DNS、命名規則、URL はすべて、ArcGIS Enterprise デプロイメントを成功させるための重要な要素です。 こうした要素の慎重な構成と管理は、信頼性が高くアクセスしやすい GIS サービスを提供すると同時に、インフラストラクチャー全体にわたるセキュリティと組織構造の維持に寄与します。 明確で一貫性のある命名規則と TLS/SSL 証明書により、デプロイメントの効率、セキュリティ、管理性が向上します。

Top