どのソフトウェア パッケージやシステムでも、アップグレード、メンテナンス、パッチ適用の計画策定がアーキテクチャー設計プロセスにおいて重要です。 システムの特定のバージョンをデプロイしていても、更新が行われ、セキュリティの問題が発見され、ユーザーがシステムを操作するなかで、必然的にシステムにパッチ、更新プログラム、またはアップグレードを適用する必要が生じます。
ArcGIS Online のようなフル マネージド型の SaaS システムでさえ、パッチ適用やアップグレードを考慮する必要があります。 ArcGIS Online の更新プロセスにはシステムのユーザーによる操作が含まれない場合がありますが、発表された新機能の適切な計画策定、アップグレード後のコンテンツとワークフローの慎重なモニタリング、問題が発生した場合の問題の報告はすべて、アップグレードやパッチ適用を円滑に進めるうえで重要です。
パッチ適用という用語はほぼすべてのソフトウェアに当てはまりますが、ArcGIS では通常、機能のギャップ、特定されたソフトウェアの欠陥または問題に対処するために、ある公式のソフトウェア リリースから次のリリースまでの間に配布される、または以前のリリースで提供される特定のソフトウェア更新プログラムを指します。 通常、パッチは新機能を追加するものではなく、ソフトウェア製品ライフサイクルで指定されているように、ソフトウェアのリリース後の一定期間内に設計、開発、提供されます。 例として、ArcGIS Enterprise のライフ サイクルをご参照ください。
ArcGIS Online、ArcGIS Enterprise、その他のクライアント アプリなど、ArcGIS 製品のカテゴリによってパッチ適用のアプローチは異なります。
ArcGIS Online では、新しいソフトウェア バージョンのリリース日の直後の期間に特定されたすべての問題に対してパッチが適用されます。 この初期期間を過ぎると、ArcGIS Online の次回の通常のリリース予定日までパッチは適用されません。 SaaS 製品という性質上、パッチは直接適用され、ユーザーには見えないため、ユーザーの操作は不要です。ユーザーが一度に使用できる ArcGIS Online のリリースは現在のリリースであるため、古いリリースのパッチ適用は行われません。
ArcGIS Enterprise の場合、パッチは Windows および Linux 用にダウンロードおよびインストール可能なファイルとして提供されます。 Kubernetes では、ソフトウェアから直接適用されます。 パッチは Esri サポート Web サイトから特定、ダウンロード、適用することも、ArcGIS Enterprise に付属している ArcGIS Enterprise の更新の確認ツールを使用してパッチを特定して、システムに直接適用することもできます。 このプロセスの詳細については、ArcGIS Enterprise のドキュメントをご参照ください。
ArcGIS Enterprise コンポーネントへのパッチの適用は、ターゲット システムのダウンタイムを考慮して慎重に計画する必要があります。 ほとんどのパッチではパッチを適用するソフトウェア コンポーネントの再起動が必要になるため、サービスまたはコンポーネントの再起動時に短時間のダウンタイムが発生します。 高可用性システムの場合は、高可用性コンポーネントにパッチと更新プログラムを適用する方法をご参照ください。 パッチはソフトウェアの初期インストール後 (すでにリリースされている場合) にデプロイすることも、Chef や PowerShell DSC などの自動化ツールを使用してデプロイすることもできます。
いずれの場合でも、他のソフトウェア コンポーネントまたはオペレーティング システムの IT パッチ適用手順に従って、意図的かつ具体的にパッチ適用を行う必要があります。 1 つのコンポーネントにパッチを適用すると他のコンポーネントに影響を与えることが多く、一般的には、ユーザーのダウンタイムを減らすために、複数のパッチを 1 つのウィンドウまたは期間にまとめることが推奨されています。 意図的なパッチ適用とは、パッチを適用するコンポーネントの順序を慎重に検討し、パッチ適用メカニズム (自動プロセスまたはスタッフ管理プロセス) がこの設計と計画に従うようにすることを意味します。
通常、パッチは問題が検出された場合にロールバックまたはアンインストールできますが、累積的に適用するよう設計されているため、特定の定義された順序や重要度の定義なしで、リリース時に複数のパッチをシステムに適用できます。 パッチは特定の機能を指す場合もあれば、一般的なセキュリティ更新を提供する場合もあるため、リリースされたすべての ArcGIS Enterprise パッチを適用することをお勧めします。
ArcGIS Pro の更新プログラム (特に、Major.minor.patch のナンバリング アプローチで識別される、すでにインストールされているバージョンへのパッチ) は定期的にリリースされますが、通常はソフトウェアの最新バージョンに対してのみリリースされます。ただし、公益事業業界向けや、セキュリティに関する緊急対応が必要な特別なケースでは、例外的に他のバージョンにも提供されることがあります。 通常、パッチはアプリケーション内で直接適用され、ArcGIS Online アカウントにログインしているユーザーに、更新プログラムが利用可能になったことが通知されます。 通常、ソフトウェアをインストールするには更新プログラムに適切な権限が必要ですが、必要に応じてユーザーが自分の裁量でインストールできます。
ArcGIS Pro のパッチは、Microsoft System Center などのソフトウェア自動化を使用して自動化およびデプロイすることもできます。 大規模な ArcGIS Pro 組織デプロイメントでは、ArcGIS Pro への更新プログラムの適用を慎重に計画する必要があります。慎重に計画することで、ユーザーは組織全体でバージョンの一貫性を維持できるため、互換性の確保やテクニカル サポートの円滑化に役立ちます。
ArcGIS Pro 以外のクライアント アプリケーションの更新プログラムは、アプリケーションごとに異なる方法で処理されます。 たとえば、ArcGIS Experience Builder Developer Edition は、Experience Builder for ArcGIS Online の各リリースの直後にリリースされ、通常はパッチが提供されません。 Field Maps や Survey123 などの ArcGIS モバイル アプリケーションの場合、パッチは関連する App Store に直接デプロイされます。モバイル オペレーティング システムがアプリケーションを自動的かつサイレントに更新する方向に移行すると、通常はユーザーが自動的に更新プログラムを受け取ります。 ArcGIS Enterprise 内で構成されたアプリケーションの場合、ArcGIS Enterprise ソフトウェアのパッチにはこの機能の変更が含まれている場合がありますが、Portal for ArcGIS のパッチ適用プロセスの外部で個別にパッチが適用されるわけではありません。
オペレーティング システム (OS) のパッチ適用は、GIS ソフトウェア チームのコントロールまたは責任の範囲外であるのが一般的ですが、エンタープライズ システムが IT 標準にますます準拠するようになるにつれて、OS パッチ適用の明確な計画が適切に設計された設計されたシステムの要件となっています。 ほとんどのエンタープライズ IT 組織では、すでに標準的なパッチ適用アプローチが採用されているため、最初のステップは、ArcGIS システムに対して考えられる影響と、その影響をどのように軽減できるかを理解することです。
オペレーティング システムのパッチ適用は通常、週に 1 回、月に 1 回、または別の間隔で定期的に行われます。 パッチ適用アプローチには、突然の再起動によってオペレーティング システムの更新を強制する中断を伴うものもあれば、シャットダウンしてから再起動してパッチを適用するようにプログラムやサービスに指示する円滑なものや、システムを再起動せずにパッチを適用するものもあります。 いずれの場合も、更新プログラムを適用する前にシステムを適切にシャットダウンすることをお勧めします。これは、より強制的なアプローチでは、ソフトウェア内のデータ永続性コンポーネントに問題が発生したり、ジオプロセシング タスクなどの進行中のジョブが予期せず停止したりする可能性があるためです。
オペレーティング システムの更新は、システムにデプロイされたソフトウェアで予期しない問題を引き起こす可能性もあるため、問題が検出された場合に更新プログラムをロールバックできるように、慎重に追跡および記録する必要があります。 Esri では、互換性だけでなく、潜在的な競合や問題を理解するためにオペレーティング システムのパッチをレビューおよびデプロイしており、問題のある OS の更新プログラムや構成が特定された場合はアドバイザリー ステートメントを発行します。
アップグレードとは、具体的には既存のリリースにパッチを適用するのではなく、ソフトウェアの新しいメジャー リリースまたはマイナー リリースにアップグレードすることを指します。 アップグレードは、SaaS システムではシームレスに行われることもありますが、オンプレミス ソフトウェアの場合は中断が発生する可能性があるため、通常は慎重に計画、管理、テストされます。 ただし、ユーザーが最新のテクノロジ、機能、サービスにアクセスできるようにするにはアップグレードが不可欠であり、ArcGIS で構築されたほとんどのエンタープライズ システムでは定期的なアップグレードが必要です。
公式ドキュメントで説明されているように、ArcGIS Enterprise のアップグレードは適切に文書化され、慎重にテストされたプロセスです。 考慮事項のトピックではアップグレードに関連する重要な決定事項を取り上げており、アップグレードの計画を開始する際には、この内容を確認しておくことが推奨されます。 組織のアップグレード頻度が低い場合や、1 つのバージョンを長期間使用し続けたい場合は、ArcGIS Enterprise の長期サポート リリースを必ずデプロイしてください。
重大な問題が発見された場合にシステムを復元できるように、ArcGIS Enterprise コンポーネントのアップグレードには、VM スナップショット、webgisdr ツール、または別のメカニズムを使用したシステムのバックアップを必ず含める必要があります。
Experience Builder や Instant Apps など、特定の ArcGIS Web アプリケーションの大半へのアップグレードは、ArcGIS Online や ArcGIS Enterprise システムのアップグレードの一環である (したがって、大規模なアップグレードの一環として自動的に適用される) か、オペレーティング システムによって自動的にアップグレードされる (モバイル アプリケーションの場合) ため、ユーザーが気付くことはほとんどありません。
ArcGIS Pro、エンタープライズ ジオデータベースとして有効化されている空間データベース、ArcGIS Enterprise または ArcGIS Online との関係により、ArcGIS Pro には特に配慮が必要です。 ArcGIS Pro のほとんどのバージョンは ArcGIS Enterprise のほとんどのバージョンに接続でき、古いバージョンの ArcGIS Pro を使用して ArcGIS Online に公開することも可能ですが、次のようないくつかの重要なポイントがあります。
デスクトップおよびエンタープライズ ソフトウェアとともにアップグレードする必要があるもう 1 つのコンポーネントは、エンタープライズ ジオデータベース が作成または有効化されるときにリレーショナル データベースに作成されるジオデータベース システム テーブルです。 ジオデータベースのアップグレードは個々のデータベース プロバイダーごとに文書化されており、ArcGIS Pro から、または Python ツールから実行できます。 通常、アップグレードはすぐに完了しますが、アップグレード中にすべてのユーザー接続とシステム接続をデータベースから切断して、関連するテーブルと関数を変更できるようにする必要があるため、作業に支障をきたす可能性があります。 ジオデータベースをアップグレードする前に、データベース レベルまたはスキーマ レベルでエンタープライズ ジオデータベースをバックアップすることをお勧めします。
古いバージョンがサポートから外れたり、廃止されたりするにつれて、クライアント (ユーザーのラップトップまたはデスクトップ コンピューター) とサーバーの両方を新しいバージョンのオペレーティング システムに移行する IT 部門による要求または実装が増えているため、オペレーティング システムのアップグレードには特に注意が必要です。 アクティブで正常に機能するシステムのオペレーティング システムを更新することは可能であり、成功することもありますが、目的の OS リリース バージョンで新しい VM をデプロイし、そのシステムにデプロイメントを移行するよりもリスクが高いと考えられています。
ユーザーはオペレーティング システムのインプレース アップグレードに成功していますが、発生した問題が特に OS のアップグレードに関連している可能性が高く、単純なデプロイメントでは再現できない可能性があるため、問題が Esri コンポーネントの外部で発生していることから、Esri テクニカル サポートから効果的なサポートを受けることがより困難になる可能性があるということが主な潜在的なリスクとして挙げられます。 IT サポートと緊密に連携して、オペレーティング システムのアップグレードに関連する影響、バックアップ、復元の可能性を理解してください。