アーキテクチャー設計プロセスの重要なステップの 1 つに、システムの物理設計を策定することが挙げられます。 物理設計とは、一般に、_論理アーキテクチャー設計_に基づいて配置される実際のコンポーネント (設計を実装に移行するために作成する必要がある仮想マシン、ストレージ、データベース、およびネットワーク コンポーネント) のハードウェアと構成の詳細を指します。 また、パフォーマンスやスケーラビリティー、システムのデプロイメントになどの問題に対処します。 物理設計における技術的または容量的側面では、CPU の種類、ハードディスクのサイズと種類、メモリーのタイプと容量、ネットワーク インターフェイスやその帯域などの仕様が定義されます。
長年にわたり、システムの容量を慎重に定義することは非常に重要でした。これは、新規システムの多くでは、新しいサーバーやその他のハードウェアを購入に多額の資本支出が伴っていたためです。 物理コンピューターを購入してデータ センターにデプロイすることは、デプロイメント工程の中でも高コストであり、通常は数年間の運用を前提としていたため、初回で適切なサイズを見極めることがコスト管理上、非常に価値があり重要でした。 制御されたコンピューティング環境では、物理ハードウェアは、デプロイメントに変更またはアップグレードはあまり行われず、サポートと管理の要件が大幅に増えるため、システムに容量を追加するコストは従来、大きな負担となっていました。
今日では、パブリック クラウドとプライベート クラウドのパターン全体で仮想化テクノロジーが広く使用されており、事前の容量計画の重要性が変化しています。つまり、特定の仮想マシンのサイズをその仮想サーバーに割り当てられるコンピューティングとメモリーの観点から変更しやすくなっており、ストレージまたは仮想ネットワーク インターフェイス用のディスク スペースの追加は、ハードウェアの取得ではなくソフトウェアの構成により行われるようになっています。 仮想サーバーが構築される物理ホストとネットワークは、依然として設計における重要な検討事項ですが、仮想化では一般に、最初に特定の仕様のサーバーを構築することに注力されることが減り、開始時のサイズが優先され、将来の見直しでリソースを増減する選択肢が取られるようになっています。 このアプローチの変化は、依然としてこのステップが重要であることを認めつつも、容量計画の進め方にも変化が求められていることを示しています。
ArcGIS のさまざまなシステム パターンと配置パターンの詳細については、システム パターンの構造をご参照ください。
これらの物理設計上の検討事項は、アーキテクチャーや物理リソースが主観的であり、アーキテクチャー工程の一環として設計する必要がある ArcGIS Enterprise ベースのシステムに最も関連します。 一方、物理設計に関する検討事項は、ArcGIS Online (SaaS) や ArcGIS Location Platform (PaaS) のサービスなど、インフラストラクチャーがユーザーに代わって処理されるフル マネージド システムには通常、適用されません。 その他のガイダンスについては、ArcGIS Trust Center の ArcGIS 固有の検討事項とクラウド オプションをご参照ください。
全体的なシステム設計の物理設計段階は、必ず全体的なソリューションが計画され、理解を深めたうえで行う必要があります。 この段階では、システムの設計において下すことが予想される決定として、以下が挙げられます (ただしこれらに限定されません)。
これらの詳細は物理設計の策定の指針となり、これらの領域に関する課題は設計プロセスの一環として解決する必要があります。
最新の ArcGIS Enterprise システムの物理アーキテクチャーを設計するためのベスト プラクティス アプローチは次のとおりです。
_情報に基づいて_ハードウェアを選定するには、明確なテスト手法と、ソフトウェア コンポーネントおよびハードウェア コンポーネントの能動的な監視が必要です。 この手法は、初期コスト (需要の確証が認められる前にシステムに過剰投資しない) と柔軟性の調和を図り、システムの使用の増加と変化がハードウェア リソースに与える影響を考慮することから、ベスト プラクティスとされています。
物理設計の一般的な検討事項として、オペレーティング システムの仮想化、CPU と GPU、ネットワーク設計、およびストレージに関連する検討事項が挙げられます。 これらの検討事項の詳細について説明します。
ArcGIS ソフトウェアを物理ハードウェアのオペレーティング システムに直接インストールすることは可能ですが、最新設計の大部分は、ArcGIS ソフトウェアが仮想マシンにインストールされるオペレーティング システムの仮想化に依存しています。
このアプローチでは、VM スナップショット、ディスク拡張、リソースの再割り当て、ネットワーク仮想化などの主要な機能を使用できるため、ハードウェア リソースをより有効に活用できます。 仮想化ソフトウェアは、一般的に、ユーザーの活動とシステム使用率に基づいてさらに物理設計を調整するのに役立つ優れたハードウェア監視ツールとプロファイリング ツールも備えています。
ArcGIS ソフトウェアは、その特定のコンポーネントとリリースでサポートされているオペレーティング システムを提供している場合に限り、どの仮想化システムでもサポートされます。 そのため、組織が可能な限り既存の仮想化エクスペリエンスとリソースを使用することをおすすめします。
物理ハードウェア上であれ仮想マシン上であれ、どのデプロイメントでも、システムに割り当てられた CPU リソースのタイプと最大容量は、システムのパフォーマンス、スケーラビリティー、および予想されるユーザー負荷の正常な処理に重要な役割を果たします。
CPU リソースは、静的ファイル、REST 要求、または複雑なリソースに関するユーザーのすべての要求および非同期ワークフローを処理するために使用されます。 対照的に、GPU リソースはより専門的であり、ArcGIS Pro ワークロード、ラスター解析サービスなどの機械学習およびディープ ラーニングのワークフロー、ならびに ArcGIS Server サイトに公開するときに GPU リソースを利用するジオプロセシング ツールにより適しています。
GPU は通常、仮想インフラストラクチャー (GPU のソフトウェア エミュレーション) または仮想マシンに接続される仮想マシン専用の物理リソースとして提供されます。 単純なデータ管理やサービスの公開など、一部の基本的なワークフローではエミュレーションで十分な場合がありますが、ArcGIS Pro やディープ ラーニング パッケージを本格的に使用する場合は、ハードウェア GPU リソースが役に立つ場合があります。 ArcGIS Pro の CPU と GPU の検討事項の詳細については、GPU での汎用コンピューティングをご参照ください。
ネットワーク アーキテクチャーは、物理設計工程におけるもう 1 つの重要な検討事項です。 ネットワークの構造、接続性、およびリソースは通常、組織レベルで定義され、ArcGIS などの特定のビジネス システムによって継承されますが、設計工程では、ネットワーク設計に物理設計上の検討事項を追加したり強化することが可能です。 ネットワーク設計のコンテキストでの推奨事項について説明します。
システムとデータの近くにクライアントを配置する – この文脈において、近くとは、クライアントが ArcGIS システム コンポーネントや関連データ ソース、ストレージと迅速に通信できる、同一の低遅延ネットワークまたはサブネットワーク内にあることを指します。 多くの ArcGIS アプリケーションは、ストレージ、データベース、およびその他のコンポーネントに複数のリクエストまたは並列リクエストを送信するため、遅延はシステムのパフォーマンスに大きな影響を与える可能性があります。
ネットワークの境界を維持し、外部からのアクセスを防御する – ネットワークは、セキュリティーの考え方と最小特権アプローチで設計する必要があります。 ArcGIS Enterprise のドキュメントには、正常に機能するために ArcGIS Enterprise コンポーネント間で許可する必要があるポートと通信パターンの包括的なセットとともに、対応する接続要件の図が掲載されています。
WAF、ファイアウォール、およびネットワーク フィルタリングを慎重に使用する – 多くのシステムでは、Web アプリケーション ファイアウォール やその他のネットワーク保護およびフィルタリング ソフトウェアを使用して、悪意のある要求や活動を防止しています。 これらのコンポーネントは優れた機能を提供できますが、保護対策が ArcGIS の機能に悪影響を及ぼさないように、慎重に設計および実装する必要があります。
物理アーキテクチャー設計に関連するストレージには、異なる複数のタイプがあります。 ディスク ストレージとは、一般に、従来の Windows または Linux デプロイメントで仮想コンピューターまたは物理コンピューターの OS に公開されるアタッチされたディスク (仮想または物理) を指します。 これらのディスクには通常、いくつかの異なるタイプがあり、見積もられたデータ ストレージ容量とディスク速度情報が含まれ、ギガバイト毎秒 (ストレージのアクセス速度) や 1 分あたり回転数 (7.2K や 10K などの RPM) といった指標が使用されることもあります。
その他のタイプのストレージには、ネットワーク接続ストレージ、ストレージ エリア ネットワーク (SAN)、さまざまなソフトウェア プロバイダーおよびハードウェア プロバイダーの仮想ファイル システム、耐久性と信頼性確保のためのさまざまな RAID 構成、または AWS FSx や Azure Files などのクラウド ストレージ システムが含まれます。 これらの各システムは、機能、長所、短所が異なるため、物理設計に関する推奨の一部として慎重に審査および検討する必要があります。 NAS ストレージ構成は ArcGIS Server サイトにとって特に重要であり、ソフトウェアのドキュメントには NAS デバイスの選択に関する具体的な手引きが記載されています。
ストレージは、ArcGIS Server 構成ストアやリレーショナル データベースのホストに使用されるディスクなど、多くの読み取りと書き込みの活動が発生するコンポーネントに特に関連します。 このような場合、ストレージの速度とスループットは、システムのパフォーマンスに大きな影響を与える可能性があります。 ストレージの使用率を監視できることを確認し、パフォーマンス検証が行われる場合は、コンピューティング スループットが最大化される前に、ストレージ速度によってボトルネックが発生していないことを確認してください。
上で概説した一般的な設計上の検討事項に加えて、他の ArcGIS または製品固有の検討事項も物理設計に適用されますが、以下にこれらの詳細を示します。
ArcGIS Online を使用している組織では、システム設計の一部として行う能動的物理設計の選択肢が少なく、SaaS システムでは、バックエンドのコンピューティング、ストレージ、またはメモリーの設計が主に Esri によって管理され、組織ごとにカスタマイズすることはできません。
ArcGIS Online には、Standard サイズやさまざまな Premium サイズなど、フィーチャ データ ストレージのためのさまざまなオプションが用意されています。 選択したストレージのタイプは、組織内のホスト フィーチャ サービスのスループットと全体的なパフォーマンスに影響を与える可能性があります。 Premium Feature Data Store は、組織に専用のストレージ容量とコンピューティング容量を提供し、より複雑なワークフローや高スループットの工程を支援します。 詳細については、Premium Feature Data Store のオプションをご参照ください。
クライアント ハードウェア構成が、そのクライアントによる ArcGIS Online の使用に与える影響を検討してください。 たとえば、3D コンテンツと WebGL コンテンツを含む複雑な Web アプリは、ハードウェア仕様がより低いデバイスでは適切に表示されない場合があり、クライアントが ArcGIS Online からデータにアクセスしている間、パフォーマンスの低下の根本的な原因は、ArcGIS Online のホスティングやサービス構成の欠陥ではなく、クライアントのハードウェア構成にあります。
ほとんどの ArcGIS Enterprise アーキテクチャーには、既存のリレーショナル データベース管理システム (RDBMS) の一部として構成される enterprise geodatabase が含まれています。 このデータベース コンポーネント専用の物理リソースは、このコンポーネントのパフォーマンスと使いやすさに大きな影響を与える可能性があるため、設計工程では慎重に検討する必要があります。 ほとんどの RDBMS ソフトウェア パッケージには、成熟したパフォーマンス監視ツールが含まれており、データベース管理の専門家は、これらのリソースの適切なサイジングについても協議できます。
これまで、Esri は、Capacity Planning Toolkit など、物理設計用の一連のツールやリソースを公開し、管理してきました。 これらのリソースは、CPU コアとシステム構成がより固定されている (仮想化されていない) 従来型の物理設計方法に焦点を当てており、ワークフローにはたいてい、データベースと Web サービスに接続するデスクトップ クライアントが含まれていました。 これらのリソースは、新しいプロセッサー仕様によって更新されなくなっており、最新の ArcGIS システムのより一般的な Web ベースのワークフローを正確に反映していません。