:::note info 本記事は、Qiita ServiceNow アドベントカレンダーの2日目の記事です。 :::
はじめに
こんにちは、Mio(@mio_yokohama)です。 ご覧いただきありがとうございます。
この記事では、ドメイン分離の基本的な概要に加え、私のこれまでの経験や学びをもとによくある課題やベストプラクティスを「ドメイン分離あるある」としてご紹介します。これからドメイン分離を始めようとされている方や、すでに運用中の方にとって、少しでも参考になる情報をお届けできればと思っています。 この記事が、皆様のドメイン分離の旅を素晴らしいものにする一助となれば幸いです。
それでは、ドメイン分離の仕組みとあるあるについて、一緒に見ていきましょう。
本記事の対象者
- ドメイン分離を利用中の方
- ドメイン分離の利用を検討している方
- ドメイン分離についてざっくり知りたい方
記事の構成
- ドメイン分離の概要
- ドメイン分離あるある（ベストプラクティスと事例）
ドメイン分離の概要
ドメイン分離をご存知でしょうか。
ドメイン分離は単一のServiceNowインスタンス内のデータ、コンフィグレーションおよびプロセスを論理的に分離できるようにする機能です。
ドメイン分離のイメージ（生成AIで作成）
建物に例えると単一ドメインが戸建て住宅であるのに対して、ドメイン分離はマンションに似ています。マンションのフロアを区切ったりフロアや部屋をテナントや居住者に貸し出したりするのと同じように、一つのServiceNow インスタンスの一部をドメインという領域に区切り、組織や部門、ユーザーを配置して利用することができます。
ドメイン分離はこのようなデータ分離を可能にする有償のプラグインです。
ドメイン分離の必要性
なぜドメイン分離が必要なのでしょうか？
例えば、企業では営業部門、開発部門、人事部門など様々な部門が存在し、それぞれが異なる業務プロセスを持つことが一般的です。これらの部門が同じServiceNowインスタンスを利用しながら、ドメイン分離によって各部門のデータとプロセスを分離し、それぞれの業務に最適な環境を提供することができます。世界中に拠点を持つ大企業では現地法人などの会社単位でも同様のことが言えます。
また、サービスプロバイダーが複数の顧客にServiceNowでサービスを提供する場合があります。この場合、ドメイン分離によって単一のインスタンスを使いながら、顧客のデータを分離してセキュリティを確保したり、顧客に合わせたカスタマイズを行うことで顧客満足度を高めることもできます。
インスタンスのデータ分離戦略
ServiceNowではドメイン分離のほかにもデータを分離する方法があります。 データ分離においては、それぞれの方法の特性と要件を踏まえて最適な方法を選択する必要があります。
この図はServiceNowのデータ分離を階層で示した図です。 上にいくほど分離の度合いが高く、下の方ほど分離の度合いが低いです。
ここでは特によく比較される個別インスタンスとドメイン分離を比べます。
| 項目 | 個別インスタンス | ドメイン分離 |
|---|---|---|
| コスト | インスタンスの数分のライセンスコスト インスタンスの数分の管理コスト | 組織や部門をまたがる場合もライセンスは共通 インスタンス1つ分の管理コスト |
| カスタマイズ性 | インスタンスごと自由にカスタマイズ可能 インスタンスの所有者が自分で管理 カスタマイズ影響を完全に分離 変更タイミングもインスタンスごとに自由 | インスタンス管理者がカスタマイズ カスタマイズ影響が全体に及ぶ 変更時は全体の調整が必要 カスタマイズは制限される |
| データ | データが複数インスタンスに分散しているため全体的な分析が難しい | 一つのインスタンスにデータ集約されており、全体を横断した分析ができる |
| 使い勝手 | 複数組織にまたがるユーザーはそれぞれのインスタンスにログインが必要 | 一つのユーザーアカウントでログインして利用できる |
ドメイン分離のメリット/デメリット
ドメイン分離には以下のようなメリットとデメリットがあります。
メリット
- データとプロセスの論理的な分離が可能
- 単一インスタンスで複数組織のデータを管理可能
- 組織ごとに異なる設定やカスタマイズが可能
- インスタンス全体のデータを統合的にレポーティング可能
- インスタンス管理の効率化（単一インスタンスの管理で済む）
- コストを1つのインスタンスに集約できる
デメリット
- 個別インスタンスと比べた場合、分離レベルは低い（同じデータベース上で論理的に分離するため）
- 設定の複雑さが増加
- 一度構成すると元に戻すのが困難
- 全てのアプリケーションがドメイン分離に対応しているわけではない
- ドメイン間の連携設定が複雑になる可能性がある
- 追加のライセンス費用が必要
これらのメリット・デメリットを考慮した上で、組織の要件に合わせて導入を検討する必要があります。
ドメイン分離が有効なケース
ドメイン分離が有効なケースは「異なる組織や顧客が同じインスタンスを使用して共通のビジネスプロセスやデータを共有しながらも、個別のプロセスやデータを分離する必要がある場合」です。具体的には、マルチテナント環境で複数の顧客にサービスを提供するマネージドサービスプロバイダーや、データの機密性が高い部門間で独立した運用を求める企業が該当します。また、法規制やコンプライアンス要件により、データの分離が求められる場合にも適しています。
ドメイン分離の仕組み
ドメイン階層 ServiceNowのドメイン分離では、ドメインの階層構造を用いてデータやプロセスの分離と継承を管理します。ドメイン階層の構成によりドメインの管理が柔軟になり、組織全体のガバナンスを確立する際に役立ちます。この階層構造は、親ドメインが全体のポリシーや設定を管理し、子ドメインが独自の運用や特化した設定を持つといった形で運用されます。これにより、複数の部門や顧客が1つのプラットフォーム上で独立した運用を行いながら、必要に応じて統制を維持することが可能です。
データとプロセスの分離 ドメイン階層ではデータとプロセスの分離の方向に注意が必要です。
データの分離
データの分離では、親ドメインはその配下にある子ドメインのデータを参照できますが、子ドメインは親ドメインのデータを参照できません。また、当然に子ドメイン同士のデータも互いに参照できません。このように、データの流れを上方向に制限することで、組織や顧客ごとのプライバシーやセキュリティが確保されます。
プロセスの分離
一方、プロセスの分離では、親ドメインのプロセスや設定は子ドメインに継承されます。これにより、共通の業務プロセスやポリシーを一貫して適用しながら、子ドメインでの運用を標準化することが可能です。そして、必要に応じて子ドメインで独自のプロセスを設定することもでき、親のルールと個別の要件の両方に対応できる柔軟性が特徴です。
この柔軟性により、組織全体で一貫性を保ちながらも、個別の要件に応じたカスタマイズが可能となります。反面、階層が深くなるほど管理が複雑になるため、設計段階で緻密な計画が求められます。
ドメイン分離まとめ
ドメイン分離がどのような機能で、いつ使うべきかをご紹介しました。 ここまでの内容は全てドキュメントとサポートKB、NowCreateのアセットにあります。 より詳細な内容は参考文献のリンクから1次ソースを確認できます。
ドメイン分離あるある
最後に私のこれまでの経験や学びをもとにした「ドメイン分離あるある」をいくつかご紹介します。
最初のドメイン設計が後の運用に影響を与える
ServiceNowのドメイン分離で重要な要素の一つが、初期のドメイン構造設計です。 私の経験から言えることは、最初に設計したドメイン構造が運用を進める中で問題を引き起こし、その後の運用や拡張に影響を与えることがあるという点です。
具体的には、初期に設計したドメイン構成がインスタンスの運用や活用推進に伴う新たなニーズに対応しづらくなったり、ドメイン構造が複雑化し実装やテストが煩雑化したりすることがありました。
これを避けるための教訓として、ドメイン分離を導入する際は、初期設計段階で組織の長期的な成長や変化を見越した柔軟性を持たせることが大切です。 一度構築し運用を開始したドメイン構成を後から変更することは、コストやリスクを伴います。 最初から現時点の「最適解」を求めるのではなく、初期設計段階で組織の長期的な成長や変化を見越して拡張可能な構造を選択することが、後々のコストやリスクを減らすために重要です。
デフォルトドメインの設定と管理が重要
ドメインにはいくつかの種類があり、デフォルトドメインもそのうちの一つです。
デフォルトドメインは通常、全てのユーザーやデータが特定のドメインに配置されない場合に適用されるデフォルトのコンテキストとして機能します。これにより、新しく作成されたレコードがどのドメインにも紐付けられていない状態でインスタンスに存在しないよう動作します。
デフォルトドメインを設定しない場合、どのドメインにも紐づかないレコードはグローバルドメインに配置されます。グローバルドメインはどのドメインからも参照できるため、意図せずデータが他の部門や顧客に見られる可能性があります。
またデフォルトドメインはOOTBでは管理者のみアクセス可能です。 そのため、デフォルトドメインを設定するだけでなく、デフォルトドメインに作成されてしまったレコードがなぜ適切なドメインに配置されなかったかを検査してドメイン決定ルールを最適化する仕組みも用意する必要があります。
参照できないユーザー基準は評価されない
ユーザー基準はプロセス分離ではなくデータ分離であるため、ユーザーから参照できない（ユーザーよりも上のドメイン）ユーザー基準は評価されません。 これにより意図せず「ユーザー基準がない場合に誰でも参照できる」というOOTBの動作を引き起こす可能性があることに注意が必要です。
ドメイン分離環境でユーザー基準による制御を行う場合は、ユーザー基準の対象ユーザーが適切なドメインに存在してユーザー基準を参照できることを確認するようにします。場合によってはユーザー基準をグローバルドメインに配置することも一つの解決策となります。
ドメイン分離対象外のアプリケーションと機能がある
ServiceNowの多くのアプリケーションはドメイン分離に対応していますが、対応していないアプリケーションもあります。 ドメイン分離を検討する場合には利用する機能や今後拡張した際に利用する可能性の高い機能がドメイン分離に対応しているかを確認しておく必要がります。
個人的な経験ではサポート対象のアプリケーションであっても部分的にドメイン分離が対応しておらずカスタマイズをしないと十分に使用できないケースがあり、実際に機能を検証することで判明するユースケースとのギャップがあると考えています。
アイデアポータル なお、ドメイン分離に関わらずServiceNowの機能不十分や改善について投稿・投票できるアイデアポータルが用意されています。 アイデアポータルに投稿して改善を要望して他の開発者の共感を集めたり、アイデア検索をすることですでに他の開発者が直面している課題を把握することができます。 アイデアポータルでドメイン分離のキーワードで検索をすると、すにで他の開発者がリクエストしているアイデアを見ることができます。（Idea Portal） （アイデアポータルは必ずしも投稿した内容に対してServiceNowによる対応が行われることを約束するものではありません。）
包含ドメインと可視性ドメインは過剰に設定しない
ドメイン分離はデータをドメインごとに分離しアクセスを制限します。 ただし、ドメインを超えたアクセスを可能にする機能があり、それが包含ドメインと可視性ドメインです。
包含ドメイン 包含ドメインはドメインの親子関係に関係なく、あるドメインから任意のドメインのデータへの可視性を付与することができます。
可視性ドメイン 可視性ドメインも同様に任意のドメインへの可視性を付与する機能です。 包含ドメインとの違いは、包含ドメインがドメイン単位で設定するのに対して、可視性ドメインはグループとユーザーに付与する関係性である点です。
包含ドメインと可視性ドメインはドメインを超えたアクセス要件を満たすために便利な機能ですが、過度に設定するとドメインの可視性の追跡性が低下し、管理やテストのオーバーヘッドが増加するだけでなく、意図しないデータアクセスが発生する可能性もあります。 これらの機能の利用は最小限となるようにドメイン設計をするようにします。
ドメイン分離を意識した設計、実装、テストが必要
ドメイン分離が有効のインスタンスではドメイン分離を意識して開発をする必要があります。 ドメインの考慮不足によりデータアクセスやビジネスプロセスの不整合が発生する可能性があります。 問題を防ぐには開発者がドメイン分離をよく理解して設計、実装、テストすることが重要です。
実際によく遭遇した問題の例を紹介します。
-
フォームレイアウトが壊れる あるドメインのフォームレイアウトを変更すると、グローバルドメインのフォームレイアウトが上書きされ、特定のドメインのレコードを特定のドメインのユーザーが開いたときにフォームが崩れます。 フォームヘッダーのUI Actionからフォームレイアウトを変更するときに、開いているレコードのドメインのフォームが更新される仕様により、これが意図せず発生することがあります。 フォームレイアウトを変更する際は変更するレイアウトのドメインが適切か確認する必要があります。
-
期待するビジネスロジックが動かない/意図しないビジネスロジックが動く グローバルドメインや親ドメインに設定されたビジネスルールやスクリプトが、子ドメインでも適用されてしまうことで意図しない動作が発生することがあります。 また、ビジネスルールやフローにドメインを考慮した条件を設定していない場合、全ドメインに影響を及ぼす可能性があります。 これは主に「ドメイン設計の不足」や「ロジック条件の不備」、「ドメイン構成や機能の理解不足」に起因することが多く、ドメイン構成が複雑なインスタンスでより発生しやすくなります。 ドメイン構成を明確にドキュメント化したり、開発者のドメイン理解やレビューなどのガバナンス強化が重要です。 ドメイン分離の理解に役立つService Provider (CIS-SP) 試験で学習するのも効果的です。
トラブルシューティングが複雑になる
ドメイン分離が有効のインスタンスでは可視性やビジネスプロセスの不具合が、ビジネスルールや処理そのものによるものなのか、ドメインによるものなのかを切り分ける必要がある場合があります。 SQLデバッグを使用して実際のクエリを確認できます。
まとめ
ドメイン分離に関する「あるある」は、実際の運用で直面しがちな課題や工夫をまとめたものです。 皆様の環境での課題解決や設計の参考になれば嬉しく思います。
もしこの記事の内容が皆様の日々の業務に少しでも役立ったなら光栄です。 引き続き、ServiceNowの価値を最大限に引き出す導入ができるようドメイン分離の世界の学びを深めていきたいと思います。
参考文献
Domain Separation for Service Providers Workshop（パートナーログインが必要）
How can I enable multitenancy using Domain Separation?（パートナーログインが必要）
KB1112327｜User Criteria not working as designed in Domain Seperated instance
Domain separation recommended practices for service providers
KB0724934｜Configure form layout displays ‘label’ as section name in Domain Separated instances