トップへ戻る

アーキテクチャー コンポーネントの選択

ArcGIS システムのアーキテクチャー設計プロセスでは、アプリ、ソフトウェア、サポート インフラストラクチャー、およびシステムのその他のコンポーネントに関連する多くの決定事項があります。 ほとんどの選択は主観的なものであるため、要件、システム入力、アプローチに関する知識を持つ経験豊富な設計者が決定する必要がありますが、より適切な意思決定を行ったり、自信を持って意思決定を下したりするのに役立つ一般的なガイドラインもあります。 このセクションでは、いくつかの主要な選択領域を要約し、組織が健全な基準に基づいてより明確な目的を持って選択できるようにするのに役立つガイダンスを提供します。

ArcGIS Online、ArcGIS Enterprise、PaaS、およびハイブリッド システム

本 Web サイトで紹介する各システム パターンは、ArcGIS Online、ArcGIS Enterprise、ArcGIS Location Platform のコンポーネントに加え、関連するアプリケーションとインターフェイスなど、いくつかの異なるデプロイメント パターンで構築できます。 設計プロセスでは、実装する主要コンポーネントの決定が重要です。 この決定は、設計がこれらのシステム パターンに基づいているか、特定の目的に合ったビジネス システムに基づいているかに関係なく適用されます。

従来、多くの組織では、ユーザー向けのメイン「ポータル」システムとして ArcGIS Online と ArcGIS Enterprise のいずれかを選択し、その 1 つのシステムに力を注いできました。しかし、両システムの長所に焦点を当て、それぞれどのシステムを使用すべきかについて明確なガバナンスをユーザーに提供するために、両方を組み合わせる組織が増えています。

ブログ記事「ArcGIS Online or ArcGIS Enterprise? You don’t have to choose」では、これらのアプローチの違いの概要と役立つガイダンスに加え、ArcGIS Enterprise の詳細なドキュメント ページも紹介しています。

ArcGIS Online と ArcGIS Enterprise に共通する機能は何百もありますが、設計の選択の指針となる重要な違いがいくつかあります。

ArcGIS Online の主な差別化要因:

  • ArcGIS Online は SaaS 製品です。システムのデプロイ、更新、パッチ適用については Esri が責任を持って行い、これらの作業はすべて最小限のユーザー ダウンタイムで完了します。 SaaS システムはカスタム コードやアプリケーションによる拡張性が低く、一般に、すべてのテナントが利用できる、変動の少ない信頼性の高い機能セットが提供されています。
  • Esri では、ArcGIS Online のすべてのユーザーに対して堅牢なサービス レベル アグリーメントを提供しています。 この SLA は ArcGIS Online の特定のコンポーネントの可用性を保証するものであり、障害を追跡するためのステータス ページが用意されています。
  • ArcGIS Online はマルチテナント SaaS です。ユーザーは他の組織のコンテンツを検索してアクセスできるため (組織で許可されている場合)、パートナー コンテンツ プロバイダー向けの ArcGIS Marketplace を含む外部データ ソースへのアクセスの幅を広げることができます。
  • ArcGIS Online は、静的な Web サイト アセット、タイル ベースマップ、ユーザー管理のタイル サービス、ホスト フィーチャ サービスのフィーチャ タイルなど、多くの機能で Content Delivery Network (CDN) アクセラレーションを利用するように設計されています。 これは、CDN のサポートにより、中央のデータ センターから遠く離れたユーザーでも、ネットワーク遅延の影響を最小限に抑えられるという、全世界規模で質の高いサービスを実現することにも貢献しています。
  • ArcGIS Online では、ArcGIS Hub Premium、ArcGIS Data Pipelines、ArcGIS Location Platform および Esri Developer サイトとの統合など、現在 ArcGIS Enterprise では利用できないいくつかの機能にアクセスできます。
  • ArcGIS Online はインターネット向け SaaS システムであり、どのユーザーやモバイル デバイスでもインターネット経由で自動的に利用できます。 パブリック DNS や証明書、セキュリティー脆弱性へのパッチ適用などを組織側で管理する必要はなく、これらはすべて Esri が ArcGIS Online を通じて直接提供します。
  • ArcGIS Online はすでにいくつかのセキュリティー標準の認定を受けており、リリースごとに厳格なセキュリティー テスト、計画、実装が行われています。 SaaS システムで高レベルのインフラストラクチャー セキュリティーを実現することで、独自のシステムを構築するよりもはるかにコスト効率よく高いセキュリティーを実現できます。

ArcGIS Enterprise の主な差別化要因:

  • ArcGIS Enterprise には、ArcGIS Knowledge、GeoEvent Server、Data Interoperability Extension for ArcGIS Enterprise、Production Mapping Server、Maritime Chart Server、その他の機能など、ArcGIS Online では利用できない、または部分的にしか利用できない、すべての機能を備えたサーバー ロールが用意されています。
  • ArcGIS Enterprise は既存のデータ ストレージ システム (データベース、ファイル共有、その他のデータ ソース) に直接接続できます。 これらのソースから公開された Web サービスは、既存の業務システムのデータを動的に表示し、アクセスを提供します。
  • アップグレードがすべてのユーザーに対して同時にデプロイされる SaaS とは異なり、組織でデプロイおよび管理するソフトウェアとして、変更とアップグレードがいつ行われるかを制御できます。 変更をユーザーに通知したり、リリース前にアプリケーションの機能をテストしたりするための変更管理は、ソフトウェアベースのアプローチで利用できます。
  • ArcGIS Enterprise では、Web 層認証、AD または LDAP によるエンタープライズ グループの使用、SSL や TLS プロトコルおよび暗号スイートの厳密な指定など、認証のためのより緊密な IT 統合をサポートしています。
  • ネットワーク内で実行されるソフトウェアとして、必要に応じた直接のリアルタイム接続など、他のエンタープライズ データ システムへの接続が可能です。 SaaS としての ArcGIS Online では、こうしたデータセットにアクセスするためにネットワークに「到達」できません。
  • ネットワーク上で実行される ArcGIS Enterprise では、SaaS ベース システムのように認証を要求することなく、イントラネットにオープン サービスを提供することで、組織内の「すべてのユーザー」とより簡単にコンテンツを共有することもできます。
  • ArcGIS Enterprise は内部向けパターンで使用することも、インターネットに公開してインターネット向けワークフローに使用することもできます。
  • ArcGIS Enterprise は多くのコンポーネントから構築されたソフトウェアであるため、セキュリティー スキャンを複雑にしかねないサードパーティー ソフトウェアに大きく依存しています。
  • ArcGIS Enterprise デプロイメントは、ArcGIS Online 組織を https://<orgname>.maps.arcgis.com としてのみ使用できる組織独自のドメイン名の背後でホストできます。

ArcGIS Location Platform の主な差別化要因

  • ArcGIS Location Platform サービスの使用は、開発者に重点を置いた 1 つの Web サイトを通じて提供され、ユーザーはサービス、請求、およびアクセス制御に 1 か所でアクセスできます。
  • API キーは ArcGIS Location Platform 専用の認証パターンとして利用できるため、有効期間が長いキーを作成できますが、特定のサービスまたは機能を対象とし、許可された参照元のリストを通じて制限されます。
  • ArcGIS Location Platform では使用量が直接コストに反映される従量課金制モデルを使用しているため、アプリケーション作成者は自身のアプリケーションのコスト プロファイルをよりきめ細かく制御できます。
  • ArcGIS Location Platform は、場所サービスや ベースマップ スタイル サービスなど、そのシステムを通じてのみ利用可能な特定のサービスへのアクセスを提供します。

ハイブリッド デプロイメント

ArcGIS Online と ArcGIS Enterprise を「ハイブリッド デプロイメント」で併用するシナリオには、次のような利点もあります。

  • 内部コンテンツと外部コンテンツの分離: 一部の組織では、すべての一般向けコンテンツを ArcGIS Online に公開し、ArcGIS Enterprise は内部用途に限定することで、利用目的を明確に分離し、データの適切な共有を促進しています。 こうした組織では、ArcGIS Online のパフォーマンス機能 (キャッシュ + CDN) を使用して、コストを管理しながら、ユーザーにスケーラビリティーの高いサービスを提供している場合もあります。
  • モバイル ユース ケースのサポート: 一部の組織では、ArcGIS Online を使用して、スタッフや請負業者によるパブリックなインターネットベースのデータ収集を可能にしています (そのため、デバイスを VPN に接続する必要がありません)。

ArcGIS Enterprise のオペレーティング システム

ArcGIS Enterprise はさまざまな Windows オペレーティング システムと Linux ベースのオペレーティング システムでサポートされています (詳細については、ArcGIS Enterprise に関する Windows と Linux のドキュメントをご参照ください)。 ArcGIS Enterprise on Kubernetes は、第 3 のタイプのオペレーティング システムと見なすこともできる Kubernetes クラスター上で実行されます。このクラスターは Linux ベースですが、通常の Linux オペレーティング システムとしてアクセスおよび運用されません。

Windows、Linux、それとも Kubernetes?

Windows および Linux 上の ArcGIS Enterprise は、世界中の何万もの組織で使用されており、個々のソフトウェア コンポーネントが異なるハードウェアまたは仮想化された「サーバー」にデプロイされ、1 つのデプロイメントにまとめられる従来のコンピューター ベースのデプロイメント内で統合されます。 ほとんどの組織には Windows と Linux のワークロードを管理した経験があるため、この安定性と一貫性があり将来にも対応できるデプロイメント パターンに慣れています。

ArcGIS Enterprise on Kubernetes は、Kubernetes に投資してコンテナー化されたアプリケーションをオーケストレーションで管理している組織向けに設計された、ArcGIS Enterprise の新しいデプロイメント パターンです。 Kubernetes 上でのエンタープライズ ソフトウェアのデプロイおよび保守のためのリソースとスタッフを確保している組織では、ArcGIS Enterprise on Kubernetes デプロイメント オプションによって、IT の管理と保守を GIS 管理から分離しながら、さまざまなクラウド ネイティブ機能、スケーラビリティーへの新しいアプローチ、ダウンタイムの短いアップグレードおよびパッチ適用機能を導入できます。 ArcGIS Enterprise on Kubernetes、Microsoft Windows、Linux デプロイメントのどれを使用しても、組織のほとんどのメンバーは違いに気づきません。これは、各デプロイメント オプションで、一元管理される直感的な ArcGIS Enterprise ポータルおよびマップとアプリで活用される GIS サービスが提供されているためです。

考慮すべき推奨事項をいくつか以下にまとめました。

  • ArcGIS Enterprise の Kubernetes デプロイメントは一般に、熟練したスタッフ サポートやデプロイメントに関する組織標準など、Kubernetes に組織的な投資をすでに行っている組織に適しています。
  • Windows と Linux のデプロイメントは、セキュリティー、アップグレード、パッチ適用、またはその他の企業全体の要件に関連する他の組織標準に準拠している場合があります。
  • ほとんどの機能は完全に同等ですが、すべての ArcGIS Enterprise ベースの機能やアプリケーションが Kubernetes 版 ArcGIS Enterprise で使用できるわけではありません。 詳細については、リリースのブログ記事をご参照ください。

Windows か Linux か?

ほとんどの組織では、Windows、Linux、その他のオペレーティング システム、またはデプロイメント パターンでワークロードを組み合わせて実行しています。 Windows と Linux の両方のオペレーティング システム ファミリーが完全にサポートされており、ArcGIS Enterprise を効率的に実行できます。 Esri テクニカル サポート アナリストは両方のオペレーティング システム タイプに精通しており、ほとんどのアプリケーションとユーザー操作は、両方のシステムでサポートされています。 Windows と Linux に固有のオペレーティング システム要件については、ArcGIS Enterprise のドキュメントをご参照ください。

ArcGIS Enterprise の Windows と Linux のデプロイメントの主な違いは次のとおりです。

  • サーバー オブジェクト エクステンション および インターセプター (SOE と SOI) は、.NET 開発パターンまたは Java 開発パターンのいずれかを使用して記述できます。 Java で記述された SOE と SOI は Windows、Linux、または Kubernetes デプロイメントで動作しますが、.NET バージョンの ArcGIS Enterprise SDK で記述されたサーバー オブジェクト エクステンションまたはインターセプターは、Windows ベースの ArcGIS Enterprise デプロイメントの ArcGIS Server にのみデプロイできます。
  • Data Interoperability for Server や Production Mapping for Server など、一部の ArcGIS Server エクステンションは Linux オペレーティング システムでサポートされていません。 GeoEnrichment Server や Maritime Chart Server などの他のエクステンションは最近 Linux サポートがサポートされるようになったため、最新のオペレーティング システムを使用する必要があります。
  • 統合 Windows 認証 (IWA) を使用するシングル サインオン シナリオでは、ArcGIS Enterprise に対応した Windows オペレーティング システムが必要です。
  • 一部の Python ベースのツールでは、Windows 固有または Linux 固有のモジュールまたはライブラリが必要になる場合があり、Microsoft Windows を実行する開発者のシステムで動作する場合がありますが、標準ライブラリーが不足しているため Linux ベースの ArcGIS Enterprise 環境に公開すると失敗します。
  • ファイル共有やデータベースへの接続など、データ ソースの問題をトラブルシューティングする場合、ArcGIS Pro をインストールしてテストできないため、Linux では検証や詳細なトラブルシューティングが一般的に困難です。 OS 固有のツールや Python ライブラリー、arcpy を使用したトラブルシューティングを使用して、接続性を評価できます。

組織でどのオペレーティング システム ファミリーを使用するかを選択するときは、次のベスト プラクティス ガイダンスの一部を考慮してください。

  • 特定のオペレーティング システムに関して組織で持っている経験に基づいて決定を下してください。 たとえば、ほとんどのエンタープライズ アプリケーションが Windows 上で実行されている場合、Linux ベースのシステムを選択すると、システムのメンテナンスを支援可能な IT スタッフが限られるため、運用上の課題が発生する可能性があります。 オペレーティング システムが組織の標準に準拠していない場合、パッチ、重要なメンテナンス、セキュリティー監視が不足する可能性が高くなります。
  • オペレーティング システムの特定のバージョン (または Linux ベースのシステムの一種) を選択する場合は、既存の組織のガイダンスに合わせるようにし、組織のサポートと競合しないように、できるだけ新しいバージョンを選択してください。
  • 世界的に見ると、ArcGIS Enterprise のデプロイメント数は Linux よりも Windows の方がはるかに多くなっていますが、一般的には、大規模でより複雑なシステムが Linux 上で実行されている傾向にあります。 この全体的な格差は、特に現地言語のサポートを受けている世界中のお客様について、経験豊富なスタッフのサポートを受けられるかどうかに影響を与える可能性があります。
  • エンタープライズ ArcGIS システムのトラブルシューティング、パッチ適用、インストール、アップグレードをサポートするシステム エンジニアは選択したオペレーティング システムに精通している必要があります。これらの各ステップ (特にトラブルシューティング) は、そのステップをサポートするスタッフが選択した OS に慣れていれば大幅に迅速になります。

リレーショナル データベース プロバイダー

リレーショナル データベースを使用する ArcGIS Enterprise のほとんどのデプロイメントでは、SQL Server、Oracle、PostgreSQL のいずれかが選択されています (ArcGIS Enterprise ドキュメントには、各タイプに固有のソフトウェア インストール要件が記載されています)。 サポートされているその他のデータベースプロバイダーには、DB2、Dameng、Teradata、SAP HANA があり、これらは通常、そのシステムまたはプロバイダーにこれまで多額の投資を行っている組織で使用されます。 大まかに言うと、ArcGIS は、より優れたプロバイダーや高速なプロバイダーを 1 つ選択するわけではないため、各データベース タイプで同等に機能するように設計されています。 エンタープライズ ジオデータベースは、サポートされているどのシステムでも問題なく作成、使用、最適化できます。

一般に、組織ですでにサポートしているデータベース プロバイダーを使用することをおすすめします。特に、DBA のスキル・を持つスタッフがいる場合はなおさらです。 ArcGIS の多くのデプロイメント、特に大規模なデータ アクセスや編集に重点を置いたデプロイメントでは、チューニング、トラブルシューティング、セキュリティー、ストレージの決定を支援する特定の DBA サポートが必要であるため、サポートの可否に応じて、データベース プロバイダーを選定することが推奨されます。

組織で複数の種類のデータベースをサポートしている場合は、どのシステムに対するチームの経験がより多いか、または、決定に役立つ可能性がある、コストやバージョンの制約が判断材料になるかも検討してください。 クエリー レイヤーを使用して、有用なビジネス データを含む可能性のある他のデータベースに接続することも検討してください。

データ ストレージ戦略

ArcGIS システムはさまざまなタイプのストレージに接続できます (詳細については、ArcGIS の概要のデータセクションをご参照ください)。 多くのシナリオでは、既存のデータベースまたはシステムでデータをホストするか、ArcGIS Data Store などの ArcGIS で管理されるコンポーネントを使用するかを、データの所有者と公開者が決定する必要があります。 これら 2 種類のコンポーネントには共通点も多くありますが、いくつかの顕著な違いがあり、その詳細はテクニカル ペーパー「Data in ArcGIS: User Managed and ArcGIS Managed」で解説されています。

データ ストア タイプの詳細については、ArcGIS Enterprise のドキュメントでもご確認いただけます。

商用クラウド プロバイダー

クラウド サービスおよびプロバイダー セクション でも説明したように、実装場所またはプロバイダーを決定する際には、特定の機能や好みよりも組織的な経験が重要となります。

ArcGIS ソフトウェアをクラウドにデプロイする場合、このシステムが組織にとって初めてのクラウド デプロイメントであろうと 50 回目であろうと、関与するスタッフの経験が成功を大きく左右します。 つまり、エンタープライズ IT 組織にすでに AWS の使用経験が豊富にある場合は、ArcGIS Enterprise デプロイメントを Azure ではなく AWS にデプロイすることを提案する方が妥当と言えます。 Azure DevOps パイプラインを使用してデプロイメントを自動化した経験がチームにある場合は、そのプロセスに沿って進むのが最適であり、その経験とベスト プラクティスを活用できます。

認証方法または認証プロバイダー

上記のトピックと同様に、認証プロバイダーまたは認証テクノロジーの選択は通常、SAML と OpenID Connect のどちらを好むかなどの組織の既存の好みとポリシーに加え、Azure AD、PingFederate、Okta などの優先プロバイダーを指針にして行う必要があります。 その他の推奨事項は次のとおりです。

  • 統合 Windows 認証のような Web 層認証はネットワーク内で適切に機能する可能性がありますが、現在、ほとんどのシステムには外部アクセスや社外デバイスが組み込まれているため、Web 層認証パターンでは対応が難しい場合があります。
  • 必要なときにすべてのユーザーが認証エンドポイントにアクセスできるようにしてください。 たとえば、組織では内部 SAML と外部 SAML の ID プロバイダーの両方を提供できます (ワークフローにモバイル アプリケーションが含まれている場合、デバイスが常に VPN に接続されている場合を除き、外部 IdP の使用が優先されます)。
  • 認証方法や認証プロバイダーの変更は混乱を招く可能性がありますが、SAML を使用する場合 (属性の組み合わせを通じてユーザーの NameID またはユーザー名を定義できる) は、一般的に混乱が少なくなります。
Top