環境分離

多くの組織は、マルチ環境の手法を使用して IT システムを構築します。これらの環境はそれぞれ開発、ステージング、運用前、QA、受け入れ、運用などの用語で呼ばれ、それぞれ異なる特性を持ち、別の目的に使用されます。これらの環境の使用方法についての標準的な定義はありません。ただ、「下位」の開発環境から、最終的な「運用」環境までの一般的なスペクトルが存在します。いずれの場合も、これらの環境の定義と制約は組織によって完全に定義されるもので、他のビジネスプロセスまたは標準と一致し、組織のビジネス要件をサポートするように定義する必要があります。この領域には唯一のベストプラクティスがあるわけではありませんが (システムごとに要件が異なるため)、次のセクションでは、アーキテクチャーのプロセスで環境分離のトピックに取り組む方法の手引きを紹介します。

ArcGIS システムのユーザーは、作業を行う必要があるとき、システムが利用可能なことを期待しています。ただし、システム構成の大幅な変更は、運用環境とは別の環境で安全に開発およびテストされていなければ、ダウンタイムを引き起こす可能性があります。コンピューティング環境の分離は、運用、テスト、および開発のアクティビティー用にそれぞれ別のシステムを作成することで、システムの信頼性と可用性を維持する手法です。すべての変更 (アプリの構成など) を各環境でテストする必要はありませんが、大きな更新や新機能を実装するときは、このテーマに対して体系的なアプローチを取ることで、大きな利点を得ることができます。

場合によっては、ユーザーの求めるものがサービスレベルアグリーメント (SLA) に文書化されている場合もあれば、システムをいつまでに利用可能にしてほしいかの希望だけの場合もあります。システムの変更を管理するために必要な環境の分離とガバナンスのレベルを決定するときは、ユーザーの期待とビジネスのニーズを考慮します。

推奨

ユーザー向けにシステムの信頼性と可用性を最大限に維持するには、次のベストプラクティスが適用されます。

組織で実現可能な場合は、運用、ステージング、開発環境を分離して実装します。
パッチ、アップグレード、OS 設定の変更など、システムの変更は、ステージング環境でテストしてから、運用環境に変更を加えます。
開発環境を使用して、他の環境のユーザーに影響を与えることなく、新しい機能を開発およびテストします。
環境の間でコンテンツや機能を展開させるときは、標準的なガバナンスプラクティスに従います。
コンテンツの昇格をどのように管理するか、つまり誰がコンテンツをレビューし、誰が承認して、どのように移動するかの計画を作成します。

環境の用途

これらのベストプラクティス推奨事項の目的には、次の 3 つの環境定義が Esri とお客様によって広く使用されています。

運用環境は、エンドユーザーをサポートするライブシステムです。通常は稼働時間の要件が SLA によって定義され、効果的な変更管理とガバナンスによって満たされます。一般に、ソフトウェア、アプリケーション、構成、またはネットワークの変更は、ステージング環境でテストせずに運用システムで行うべきではありません。運用環境に関与するスタッフは、通常はアプリを参照して意思決定を行い、オフィスの内外で情報を収集および編集し、ミッションクリティカルな作業を完了するための調整を行います。この環境では、多くの場合に監視が強化され、良好なパフォーマンスを確保するための専用ハードウェアがあり、IT サポートの労力は保守に最も多く割り振られます。
ステージング環境は、一般に運用環境を代表するミラーとして設計されており、システムの変更を運用環境にデプロイする前に検証できます。「代表」という用語が使われているのは、運用環境とまったく同じ環境を維持するには、リソースや人的コストがかかるためです。通常、ステージング環境は階層、サーバー、コンポーネント、およびロールについて運用環境を反映しますが、個別のサーバーには運用環境と同じ容量が必要な場合と、必要ない場合があるため、スケールダウンされたデプロイメントを検討するとコストを削減できることがあります。ステージング環境でユーザー受け入れテスト、パフォーマンステスト、負荷テスト、およびトレーニングを実行し、運用システムにリスクを与えずに済みます。必要なら、さまざまなテストやトレーニングアクティビティーのために複数のステージング環境を実装することもできます。ステージング環境に参加するスタッフは、負荷テスト、パフォーマンステスト、統合テスト、QA/QC、場合によっては、通常これらの作業を担当しているスタッフです。
開発システムは、開発者やアナリストが、大勢のオーディエンスに影響を与えることなく、コンテンツを作成および管理したり、変更を加えたりできるワークスペースです。この専用の環境は、通常はアプリケーション、サービス、データモデル、ジオプロセシングモデルなどの新機能の作成、単体テスト、およびビジネスワークフローの設計と構築に使用されます。変更によって生じるリスクのレベル、作成者の数、およびシステムの停止とダウンタイムが引き起こす影響の可能性に応じて、環境のサイズと複雑さが決まります。一般に、開発環境でコンテンツを積極的に操作するスタッフのみがこのシステムにアクセスできるか、組織内では一般にアクセスできません。

environment-isolation-1

組織のリスクと IT ポリシーに対する許容度によっては、運用、ステージング、および開発の構造の外部で、特定の種類のアクティビティーをさらに分離することが必要な場合があります。必要なら、次のような各種のテストおよびトレーニングアクティビティー用に、複数の環境を実装できます。

QA/QC
統合テストまたは受け入れテスト
パフォーマンステスト
負荷テスト
トレーニング

環境の分離の利点とコスト

環境を分離することで、アップグレード、新しいソフトウェア、予期しない変更など、ビジネスに悪影響を与える可能性のある既知のリスクや変更から本番環境を隔離し、その機能、安定性、パフォーマンスをより適切に維持できます。意図しないシステム変更があると、運用システムがユーザーの期待する機能とパフォーマンスを提供できなくなる可能性があります。これらの分離されたコンピューティング環境を実装すると、安定性、拡張性、パフォーマンスに優れたシステムを提供できます。

また、環境の分離には、IT リソース (複数のシステムの維持)、ソフトウェアライセンス、人件費など、さまざまなコストがかかります。これは、環境の数が増えると、変更制御とデプロイメントに必要なサポートネットワークが大きくなり、スタッフの数も増えるためです。一般に、大規模でビジネスクリティカルなシステムでは、より複雑な環境の分離の手法がデプロイされますが、小規模な組織でも、この手法のバリエーションをデプロイして変更を分離し、システムを保護することを選択できます。これらの選択肢のコストを調査し、関係者にこれらのコストを周知することで、「これまでもそうしてきた」という理由だけで複数の環境を保有することをデフォルトの選択にするのではなく、情報に基づく意思決定が行われるようにすることが重要です。

環境の分離の実装

環境の分離を正しく実装するために、ガバナンスは重要な役割を果たします。これは、リスクを軽減し、リソースを最適化して、ビジネス上の利益を得るための方法です。ガバナンスでは、チームがこれらの環境を維持し、環境全体にわたる変更を促進するために活用するポリシー、手順、技法を定義する必要があります。

あらゆる環境で活用できる考慮事項や、環境間にわたって広範なソフトウェア、アプリケーション、サービス、およびデータを管理するための標準的な道筋はありません。ただし、Chef Cookbooks、Enterprise Cloud Builder、ArcGIS Enterprise Builder、データベースのレプリケーションツール、アセットパッケージなど、環境を一貫してデプロイするのに役立つリソースはいくつかあります。詳細については、ArcGIS Enterprise のデプロイメントツールをご参照ください。さらに、人為的ミスを防ぐため、手動構成は可能な限り避けましょう。これらのタスクの一部を自動化するには、PowerShell DSC for ArcGIS、ArcGIS REST API、および ArcGIS API for Python の使用を検討します。これらのスクリプトの作成は、開発環境に適したアクティビティーであることに注意してください。

開発で行われたすべての選択は本質的に、ステージングや運用の段階で誰かが知る、またはどのようにして行うかを知る必要があるものにつながります。適切な知識やスキルを運用スタッフに確実に伝達することで、適切なデプロイメントの方式を採用し、スタッフが意図した運用を行えるようになります。

複数の ArcGIS Enterprise デプロイメントの操作

一部の組織では、複数の ArcGIS Enterprise 環境を使用して、これらの各層を分離しています。環境間でコンテンツを一貫して正しく移動および管理することは困難な場合があります。しかし、これらのタスクを自動化するために使用できるツールがあります。たとえば、ArcGIS REST API には、レイヤー、マップ、およびアプリを環境間で簡単に移動できる、グループコンテンツのエクスポートとグループコンテンツのインポートなどの操作が利用できます。

たとえば、開発環境のグループ内の Web マップとフィーチャレイヤーのセットを参照する、カスタマイズされた Experience Builder アプリケーションを開発し、それを構造化されたレビューのためにステージングシステムに移行する準備が整った、というシナリオを考えてみます。これらのグループのエクスポート/インポート移行操作を使用してこの作業を行うには、次の手順を実行します。

開発環境からグループコンテンツをパッケージとしてエクスポートします。
パッケージをアイテムとしてステージング環境に追加します。
パッケージの内容をステージング環境内のグループにインポートします。
カスタムアプリをステージングホスティング環境にデプロイし、ステージング環境の URL を参照するように構成を設定します。

environment-isolation-3

この時点で、パッケージ内のアイテムは、ステージンググループの設定によって決定されるステージング環境で検出、共有、編集、および使用できます。同じワークフローを使用して、準備が整い次第、アイテムを本番環境に移行できます。このワークフローは、ArcGIS API for Python の GroupMigrationManager モジュールを使用してスクリプト化することもできます。

ブルーグリーンデプロイメント

システムのアップグレードや大きな設定変更など、特定の種類の変更をデプロイすると、システムが停止する可能性があります。一部の組織では、ブルーグリーンデプロイメントと呼ばれる戦略を使用して、新しい変更をユーザーに対してシームレスにデプロイします。ブルーグリーンデプロイメントは、機能的に同一の 2 つの環境を個別に用意するデプロイメント戦略です。 1 つの環境 (ブルー) は現在のバージョンのアプリケーションを実行し、もう 1 つの環境 (グリーン) は新しいバージョンのアプリケーション、または構成の組を実行します。トラフィックは、ルーター、ロードバランサー、リバースプロキシー、Web サーバーなどの標準的な機構を使用して、いずれかの環境に転送されます。

ブルーとグリーンは、交代で運用環境の役割を果たします。どの時点でも、片方の環境だけがライブの状態です。たとえば、ArcGIS Enterprise をアップグレードするとき、アップグレードは最初にグリーンシステムで行われます。すべてが完全に機能し、運用環境で使用する準備ができていることをテストチームが確認した後で、プロキシーまたはロードバランサーからのトラフィックフローの方向だけをブルーからグリーンに切り替えます。運用環境のエンドユーザーにとっては、違いがわからないほどシームレスに切り替えが行われます。この時点から、新しいコンテンツと機能はブルーで開発されます。十分なテストが行われて成功してから、再度トラフィックの切り替えが行われます。

2 組の環境を常に稼働させておくのは、多くのコストを要する可能性があります。幸いにも、クラウドを利用すればブルーグリーンデプロイメントの実現が容易になります。すべての大手クラウドプラットフォームプロバイダーには、インフラストラクチャーをオンデマンドで立ち上げたり破棄したりできるツールがあります。たとえば、コードとしてのインフラストラクチャーを使用してサーバーを起動および停止し、システムの稼働時間と構成を特定の詳細まで自動化できます。

最終的な推奨

これらの分離されたコンピューティング環境を実装すると、安定性、拡張性、パフォーマンスに優れたシステムを提供できます。これらの環境を活用して効果的な変更管理をサポートすることで、予期しない障害からシステムを保護し、業務の中断を回避できます。ほとんどの組織では、少なくとも運用とステージングの 2 つのコンピューティング環境が必要です。これは、カスタム開発に関与していないか、ローコードやノーコードアプリケーションを主に使用しているため、開発環境を必要としない場合もあるからです。ただし、組織のリスク選好によっては、さらに多くの環境を使用することがあります。

環境の分離 (および各環境内で分離すべきアクティビティー) をどのように実装および管理するかを、できるだけ早い段階で検討してください。これらの選択について、あらゆる条件に対応できる方法はありませんが、多くのツールが使用でき、また一般的なプラクティスをガイダンスとして参考にできます。

最近公開された追加のリソースでは、環境間でのコンテンツ昇格に関する概念と、それをスクリプトで実装する方法の例が紹介されています: 「Esri Community Post: ArcGIS Enterprise Content Promotion」。