Microsoft Purviewでオンプレミスやプライベートネットワーク内のデータソースをスキャンする場合、まず確認すべきなのはセルフホステッド統合ランタイム（SHIR）の配置、権限、ネットワーク許可、バージョン管理です。今回のポイントは、単なる設定手順ではありません。管理者はファイアウォール、DNS、プロキシ、プライベートエンドポイント、更新タイミングをあわせて確認しないと、スキャン失敗や一時的な停止につながります。
なお、指定されたMicrosoft Learnページでは「Last updated on 2025-09-30」と表示されています。本稿では、2026年6月2日時点でMicrosoft Purview管理者・開発者が確認すべき公式情報として、SHIRの作成・管理・展開上の注意点を整理します。(Microsoft Learn)
Microsoft Purviewのセルフホステッド統合ランタイムとは
セルフホステッド統合ランタイム（Self-hosted Integration Runtime、SHIR）は、Microsoft Purviewがオンプレミス環境や仮想ネットワーク内のデータソースをスキャンするために使う実行基盤です。Microsoft PurviewのIntegration Runtimeは、さまざまなネットワーク環境でデータスキャンを実行するためのコンピューティングインフラであり、SHIRはオンプレミスネットワークまたはプライベートネットワーク内のVMにインストールして利用します。(Microsoft Learn)
つまり、次のような環境ではSHIRの確認が必要です。
| 利用シーン | SHIRが必要になりやすい理由 |
|---|---|
| オンプレミスSQL Server、Oracle、ファイルサーバーなどをスキャンする | Microsoft Purviewから直接アクセスできない社内ネットワーク内にデータソースがあるため |
| Azure仮想ネットワーク内のプライベートなデータソースをスキャンする | パブリックエンドポイントを使わず、VNet内から接続する必要があるため |
| ファイアウォールで接続元IPや通信先を厳格に制限している | SHIRマシンからPurviewサービス、データソース、認証基盤への通信許可が必要になるため |
| プライベートエンドポイント経由でPurviewやデータソースへ接続する | DNS解決やVNet関連付けを正しく構成する必要があるため |
Azure Integration RuntimeやManaged Virtual Network Integration Runtimeはフルマネージドで利用できますが、SHIRは自社管理のマシンにインストールするため、OS、リソース、更新、監視、プロキシ、ファイアウォールを自分たちで管理する必要があります。Microsoft PurviewのIR選定ガイドでも、SHIRはオンプレミスまたは仮想ネットワーク内のデータソースをスキャンする用途と説明されています。(Microsoft Learn)
今回確認すべき変更点と実務上の影響
今回の確認ポイントは、脆弱性修正だけを見るタイプの「セキュリティ更新」ではなく、Microsoft Purviewで安全にスキャンを継続するための運用要件の再確認です。特に影響が大きいのは、閉域網、プロキシ、プライベートエンドポイント、複数ノード構成を使っている環境です。
| 確認項目 | 影響を受ける担当者 | 実務上の影響 |
|---|---|---|
| SHIRをインストールするマシン要件 | インフラ管理者 | OS、.NET Framework、CPU、メモリ、ディスク容量の不足でスキャンが不安定になる |
| ADF/Synapse IRとの共存不可 | Azure管理者、データ基盤担当 | 同じマシンにAzure Data FactoryやAzure Synapse AnalyticsのIRを同居させられない |
| ネットワーク許可リスト | ネットワーク管理者 | Purviewサービス、Azure Relay、Storage、Entra ID、データソースへの送信許可が必要 |
| プロキシ設定 | セキュリティ管理者 | NTLM認証、専用ドメインアカウント、構成ファイル更新漏れが障害原因になる |
| プライベートエンドポイントとDNS | クラウドネットワーク担当 | nslookupでプライベートIPが返らないと、閉域接続のつもりでも失敗する |
| 自動更新と有効期限 | 運用管理者 | 単一ノードでは自動更新時にダウンタイムが発生する可能性がある |
| ソース別の追加要件 | 開発者、データ管理者 | JDK、Visual C++再頒布可能パッケージ、ドライバー不足でスキャンが失敗する |
特に注意したいのは、SHIRが「作成できたら終わり」ではない点です。登録後も、ノード状態、バージョン、サービスアカウント、通信先、スキャン対象ごとの追加コンポーネントを継続的に確認する必要があります。
SHIRを作成する前に確認すべき前提条件
Microsoft PurviewでSHIRを追加・管理するには、Microsoft Purviewのデータソース管理者権限が必要です。また、SHIRのインストールと構成には対象マシンの管理者権限が必要です。(Microsoft Learn)
マシン要件
SHIRマシンの推奨最小構成は、2GHzプロセッサ、8コア、28GB RAM、80GBの空きディスク領域です。ただし、スキャン対象やデータ量によっては、これ以上のスペックが必要になる場合があります。複数のスキャンジョブが同時に動くと、ピーク時のCPU・メモリ使用量が増えるため、本番環境では余裕を持った設計が必要です。(Microsoft Learn)
| 項目 | 確認すべき内容 |
|---|---|
| OS | 64ビットOSであること |
| .NET Framework | 4.7.2以上が必要 |
| CPU | 推奨最小は2GHz、8コア |
| メモリ | 推奨最小は28GB RAM |
| ディスク | 推奨最小は80GBの空き容量 |
| 電源設定 | 休止状態にならない電源プランにする |
| 権限 | インストール時はマシン管理者権限が必要 |
| 長いパス | Windowsの長いパスを有効化しておく |
| FIPSモード | SHIRマシンでは現在サポートされていない |
対応OSにはWindows 8.1、Windows 10、Windows 11、Windows Server 2012、2012 R2、2016、2019、2022が含まれます。一方で、ドメインコントローラーへのSHIRインストールはサポートされていません。(Microsoft Learn)
ADFやSynapseのIRと同じマシンに入れない
Microsoft Purview Integration Runtimeは、Azure Data FactoryまたはAzure Synapse AnalyticsのIntegration Runtimeと同じコンピューター上で共有できません。別のマシンにインストールする必要があります。(Microsoft Learn)
これは移行時に見落とされやすいポイントです。すでにAzure Data Factory用のSHIRが稼働しているサーバーに「Purview用も追加すればよい」と考えると、構成上の制約にぶつかります。Purview用には専用VMまたは専用サーバーを用意してください。
Purviewアカウントが複数ある場合はマシンも分ける
1台のマシンにインストールできるSHIRインスタンスは1つだけです。2つのMicrosoft Purviewアカウントでオンプレミスデータソースをスキャンする必要がある場合は、Purviewアカウントごとに別マシンを用意します。(Microsoft Learn)
実務では、検証環境と本番環境のPurviewアカウントを分けているケースがあります。この場合、検証用SHIRと本番用SHIRを同じサーバーに入れず、環境ごとに分離するとトラブルを避けやすくなります。
Microsoft PurviewでSHIRを作成する手順
SHIRの作成は、Microsoft Purviewガバナンスポータルから行います。公式手順では、従来のMicrosoft PurviewガバナンスポータルでData MapからIntegration runtimesを開き、新しいセルフホステッドIRを作成します。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Purviewガバナンスポータルを開く | 対象Purviewアカウントを間違えない |
| 2 | Data Mapを開く | 左メニューから選択 |
| 3 | Sources and scanning配下のIntegration runtimesを選ぶ | 既存IRがある場合は用途を確認 |
| 4 | 「+ New」を選択 | 新規作成を開始 |
| 5 | Self-Hostedを選択 | Azure IRやManaged VNet IRと混同しない |
| 6 | IR名を入力して作成 | 環境名、用途、リージョンが分かる命名にする |
| 7 | 認証キーをコピー | キーは安全に扱い、不要な共有を避ける |
| 8 | Microsoft Integration Runtimeをダウンロードして対象マシンにインストール | Purview用の専用マシンで実施 |
| 9 | 登録画面で認証キーを貼り付ける | 2つのキーのいずれかを使って登録 |
| 10 | 登録完了後、ノード状態を確認 | Onlineになっているか確認 |
命名は地味ですが重要です。たとえば、shir-prod-east-onprem-sql01のように、用途、本番・検証、接続先の種類が分かる名前にしておくと、複数ノードや複数環境を運用するときに誤操作を減らせます。
管理者が確認すべきネットワーク設定
SHIRのトラブルで最も多いのは、認証キーやPurview側の設定ではなく、ネットワーク経路の不足です。SHIRマシンは、Purviewサービス、スキャン対象のデータソース、スキャン結果の取り込みに使うストレージ、Microsoft Entra IDなどに接続できる必要があります。(Microsoft Learn)
必須通信先と送信ポート
パブリッククラウド環境では、少なくとも次の通信先を確認します。組織の企業ファイアウォールだけでなく、SHIRマシン上のWindowsファイアウォールも対象です。(Microsoft Learn)
| 用途 | 主な通信先 | ポート | 管理上の注意点 |
|---|---|---|---|
| Purviewサービス接続 | *.frontend.clouddatahub.net | 443 | 専用リソースがないためワイルドカードが必要とされる |
| Azure Relay | *.servicebus.windows.net | 443 | テスト接続、フォルダーやテーブル一覧の参照などUI操作に関係 |
| Purview API | <tenantId>-api.purview-service.microsoft.com | 443 | プラットフォームプライベートエンドポイントでカバーされる場合がある |
| Purviewアカウント | <purview_account>.purview.azure.com | 443 | アカウントプライベートエンドポイントでカバーされる場合がある |
| Blob Storage | <managed_storage_account>.blob.core.windows.netまたは<ingestion_storage_account>.*.blob.storage.azure.net | 443 | スキャン結果の取り込みに関係 |
| Queue Storage | <managed_storage_account>.queue.core.windows.netまたは<ingestion_storage_account>.*.queue.storage.azure.net | 443 | スキャン処理の連携に関係 |
| SHIR更新 | download.microsoft.com | 443 | 自動更新を無効化している場合は不要になることがある |
| Microsoft Entra ID | login.windows.net、login.microsoftonline.com | 443 | サインイン・認証に必要 |
2023年12月15日より前に作成されたPurviewアカウントではMicrosoft Purviewによって作成されたマネージドストレージアカウントへの接続が必要です。一方、それ以降に作成されたアカウント、またはAPIバージョン2023-05-01-preview以降でデプロイされたアカウントでは、インジェストストレージアカウントが使われます。(Microsoft Learn)
この違いは、ファイアウォール設定で見落とされやすい部分です。古いPurviewアカウントを運用している場合は、Azure portalのManaged resourcesタブを確認し、対象ストレージ名を許可リストに含めてください。新しい構成では、PropertiesのIngestion storage IDやJSON ViewのprimaryEndpointを確認します。
スキャン対象ごとの通信も別途必要
SHIRがPurviewサービスに接続できても、スキャン対象のデータソースに接続できなければスキャンは成功しません。たとえば、Azure Data Lake Storage Gen2では<your_storage_account>.dfs.core.windows.netの443、Azure Blob Storageでは<your_storage_account>.blob.core.windows.netの443、Azure SQL Databaseでは<your_sql_server>.database.windows.netの1433、Power BIでは*.powerbi.comと*.analysis.windows.netの443が例示されています。(Microsoft Learn)
Azure SQL DatabaseやAzure Storageなどでは、データソース側のファイアウォールにSHIRマシンのIPアドレスを許可する、またはSHIRが存在するネットワーク内にサービスのプライベートエンドポイントを作成する必要がある場合があります。(Microsoft Learn)
プライベートエンドポイント利用時はDNSを必ず確認する
プライベートエンドポイントを使っている場合、設定画面だけ見て「接続できるはず」と判断するのは危険です。SHIRマシンからnslookupを実行し、対象ドメインがプライベートIPに解決されるか確認してください。
Microsoft Learnでは、プライベートエンドポイントを使用している場合、nslookupでパブリックIPではなくプライベートIPが返る必要があると説明されています。IPが返らない、またはプライベートエンドポイント利用時にパブリックIPが返る場合は、DNSとVNetの関連付け、プライベートエンドポイントとVNetピアリングを見直す必要があります。(Microsoft Learn)
確認例は次のとおりです。
nslookup <purview_account>.purview.azure.com
nslookup <tenantId>-api.purview-service.microsoft.com
nslookup <ingestion_storage_account>.blob.storage.azure.net
nslookup <your_sql_server>.database.windows.net見るべきポイントは、名前解決が成功するか、期待するプライベートIPが返るか、意図しないパブリックIPへ解決されていないかです。特にハブスポーク構成や複数VNetピアリングを使っている環境では、Private DNS Zoneのリンク漏れが原因で失敗することがあります。
Azure Relayのワイルドカードを避けたい場合の対応
セキュリティポリシー上、*.servicebus.windows.netのようなワイルドカード許可を避けたい組織もあります。その場合は、Purviewガバナンスポータルで対象SHIRを編集し、Nodesタブから「View Service URLs」を選ぶことで、SHIRに必要なFQDNを確認できます。確認したFQDNをファイアウォール規則に追加すれば、より絞り込んだ許可リストを作れます。(Microsoft Learn)
ただし、FQDNを細かく管理する場合は、ノード追加や再構成時に通信先が変わっていないかを運用手順に入れておきましょう。セキュリティを高めるつもりで許可先を絞りすぎると、接続テストやスキャン設定画面の参照操作だけ失敗することがあります。
プロキシ環境で失敗しやすいポイント
企業ネットワークでプロキシサーバーを使ってインターネットへ接続している場合、SHIRにも適切なプロキシ設定が必要です。プロキシは初回登録時にも、登録後にも設定できます。(Microsoft Learn)
Microsoft Purviewで説明されている選択肢は、プロキシを使わない、システムプロキシを使う、カスタムプロキシを使う、の3パターンです。カスタムプロキシではアドレスとポートが必須で、ユーザー名とパスワードはプロキシ認証方式に応じて任意です。設定はWindows DPAPIで暗号化され、SHIRマシンにローカル保存されます。(Microsoft Learn)
| プロキシ設定 | 向いている環境 | 注意点 |
|---|---|---|
| プロキシを使用しない | SHIRマシンが直接Purviewやデータソースへ接続できる | 企業ネットワークでは利用できないことが多い |
| システムプロキシを使用 | OSまたは構成ファイルで標準化している | 必要な4つの構成ファイルへの反映漏れに注意 |
| カスタムプロキシを使用 | SHIR専用のHTTPプロキシを指定したい | アドレスとポートが必須。認証情報の管理が必要 |
重要なのは、プロキシ経由でデータソースに接続できるコネクタが限られる点です。公式情報では、AzureデータソースとPower BI以外のコネクタでは、プロキシ経由でデータソースに接続することはサポートされていません。(Microsoft Learn)
たとえば、Purviewサービスへの通信はプロキシ経由で通せても、オンプレミスDBへのスキャン経路までプロキシで中継できるとは限りません。SHIRマシンからデータソースへ直接到達できるネットワーク設計にするのが基本です。
システムプロキシ利用時は4つの構成ファイルを更新する
システムプロキシを使う場合、SHIRはC:\Program Files\Microsoft Integration Runtime\5.0\配下の複数ファイルのプロキシ設定を使います。対象は次の4つです。(Microsoft Learn)
.\Shared\diahost.exe.config
.\Shared\diawp.exe.config
.\Gateway\DataScan\Microsoft.DataMap.Agent.exe.config
.\Gateway\DataScan\DataTransfer\Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config実務で多い失敗は、1つか2つのファイルだけ更新して「設定したつもり」になることです。Microsoft Learnでも、上記4ファイルをすべて更新することが重要事項として示されています。(Microsoft Learn)
作業時は、必ず次の順序で進めてください。
| 手順 | 作業 | 失敗防止のポイント |
|---|---|---|
| 1 | 対象ファイルをバックアップ | XMLを壊したときに即時復旧できる |
| 2 | 管理者権限で編集 | 通常権限では保存できない場合がある |
| 3 | 4ファイルすべてを更新 | 一部だけ更新すると操作ごとに挙動が変わる |
| 4 | プライベートエンドポイント宛の通信は必要に応じてバイパス | ローカル・閉域通信をプロキシへ回さない |
| 5 | Integration Runtime Host Serviceを再起動 | 変更を反映する |
| 6 | サービス起動と接続テストを確認 | XML構文ミスがあるとサービスが起動しないことがある |
NTLM認証のプロキシを使う場合、Integration Runtime Host Serviceはドメインアカウントで実行されます。後からそのドメインアカウントのパスワードを変更した場合は、サービス構成を更新してサービスを再起動する必要があります。そのため、頻繁なパスワード変更を避けられる専用ドメインアカウントを使うことが推奨されています。(Microsoft Learn)
高可用性とスケーラビリティの設計
本番環境では、SHIRを単一ノードで構成するか、複数ノードで構成するかが重要です。SHIRは複数のオンプレミスマシンまたはAzure VMに関連付けることができ、最大4ノードまで構成できます。複数ノードにすることで、スキャンの単一障害点を避け、同時スキャン数を増やせます。(Microsoft Learn)
| 構成 | 向いている用途 | 注意点 |
|---|---|---|
| 1ノード | 検証、小規模スキャン、重要度の低い定期スキャン | 自動更新時にダウンタイムが発生する可能性がある |
| 2ノード | 本番の基本構成 | 片方の更新・障害時に継続性を確保しやすい |
| 3〜4ノード | 大量スキャン、複数部門利用、高可用性重視 | ノードごとのリソース、ネットワーク、バージョン状態を監視する必要がある |
複数ノードを追加する場合は、同じ認証キーを使って登録します。ただし、追加前に最初のノードで「Remote access to intranet」オプションが有効になっていることを確認します。(Microsoft Learn)
また、スキャン対象によって複数ノードの効果は異なります。Azure Blob Storage、Azure Data Lake Storage Gen1、Azure Data Lake Storage Gen2、Azure Filesなどでは各スキャン実行が複数ノードを使って性能向上できます。一方、その他のソースでは、いずれか1つのノードでスキャンが実行されます。(Microsoft Learn)
そのため、「ノードを増やせばすべてのスキャンが必ず速くなる」とは考えないでください。複数ノード化は、可用性、同時実行数、対象データソースの種類を踏まえて判断します。
バージョン管理と自動更新の注意点
SHIRはインストール時に自動更新が既定で有効になります。Microsoft Purviewでは通常、毎月2つの新しいSHIRバージョンがリリースされ、機能追加、バグ修正、機能強化が含まれると説明されています。(Microsoft Learn)
ただし、運用上は次の点に注意が必要です。
| 項目 | 内容 |
|---|---|
| 自動更新 | 既定で有効。新しいバージョンへ自動更新される |
| 手動更新 | 最新版が必要な場合はダウンロードセンターから手動更新できる |
| 自動更新版と最新版 | 安定性のため、自動更新で配布される版が実際の最新版より前のバージョンになる場合がある |
| 単一ノード | 自動更新中にダウンタイムが発生する |
| 複数ノード | 自動更新中も他ノードがタスクを処理するためダウンタイムを避けやすい |
| バージョン有効期限 | 各バージョンは1年で期限切れ |
| 期限通知 | 有効期限の90日前からポータルとクライアントに表示される |
単一ノードで本番スキャンを運用している場合は、自動更新のタイミングでスキャンが止まる可能性を考慮してください。重要なスキャンがある時間帯を避ける、複数ノード化する、バージョン状態を定期確認する、といった運用ルールを作るべきです。
バージョン確認は、従来のMicrosoft PurviewガバナンスポータルのData Map、Integration runtimesから確認できます。SHIRクライアントのHelpタブでも確認できます。(Microsoft Learn)
サービスアカウントと権限の確認
SHIRの既定のサインインサービスアカウントはNT SERVICE\DIAHostServiceです。サービスのプロパティから確認できます。このアカウントには「サービスとしてログオン」の権限が必要で、権限がないとSHIRを正常に開始できません。(Microsoft Learn)
確認場所は次のとおりです。
ローカル セキュリティ ポリシー
→ セキュリティの設定
→ ローカル ポリシー
→ ユーザー権利の割り当て
→ サービスとしてログオンドライバーやJDKなどを追加インストールする場合も、このサービスアカウントが必要なファイルにアクセスできるかを確認してください。特にJDBCドライバーを任意フォルダーに置く構成では、フォルダーの読み取り権限不足でスキャン時に失敗することがあります。
ParquetスキャンではJavaランタイムが必要
SHIRを使ってParquetファイルをスキャンする場合は、SHIRマシンに64ビットJRE 8またはOpenJDKをインストールする必要があります。Javaランタイムの検出では、まずレジストリのJRE設定が確認され、見つからない場合はOpenJDK用のJAVA_HOMEシステム変数が確認されます。(Microsoft Learn)
設定例は次のようになります。
JAVA_HOME=C:\Program Files\Java\jdk1.8\jreまた、一部のデータソースではJDK、Visual C++再頒布可能パッケージ、特定ドライバーなどの追加セットアップが必要です。これらはデータソースごとのコネクタ記事の前提条件に記載されるため、スキャン対象を追加するたびに確認してください。(Microsoft Learn)
管理画面で確認できる項目
SHIRは作成後、Microsoft PurviewガバナンスポータルのIntegration runtimesから編集・管理できます。Settingsタブでは説明の更新、キーのコピー、新しいキーの再生成ができ、Nodesタブでは登録済みノード、状態、IPアドレス、ノード削除を確認できます。VersionタブではIRバージョンの状態を確認できます。(Microsoft Learn)
| タブ | 確認できること | 運用で見るべきポイント |
|---|---|---|
| Settings | 説明、キーのコピー、キー再生成 | 認証キーを不要に共有していないか |
| Nodes | ノード一覧、状態、IPアドレス、削除 | Offline、Connecting、IP変更を検知する |
| Version | IRバージョン状態 | 期限切れ、更新待ち、手動更新要否を確認 |
| 通知領域 | SHIRの状態詳細 | クライアント側の異常兆候を確認 |
認証キーはノード登録に使う重要情報です。運用担当者間で平文共有し続けるのではなく、登録後は保管場所とアクセス権を限定してください。退職者や外部委託先にキーを共有していた場合は、キーの再生成も検討します。
移行・展開時に失敗しやすいポイント
既存環境からMicrosoft Purviewのスキャン運用を移行する場合、次の点で失敗しやすくなります。
| 失敗例 | 原因 | 対応 |
|---|---|---|
| ADF用SHIRがあるサーバーにPurview用SHIRを入れようとする | Purview IRはADF/Synapse IRと同一マシンで共有不可 | Purview専用マシンを用意する |
| 登録直後は成功したがスキャンが失敗する | Purviewサービスには接続できるがデータソース側ポートが閉じている | データソースごとのFQDN・ポートを確認する |
| プライベートエンドポイント利用時に接続できない | DNSがパブリックIPへ解決されている | SHIRマシンからnslookupを実行し、Private DNS Zone連携を見直す |
| プロキシ設定後にSHIRサービスが起動しない | XML構文ミス、構成ファイル更新ミス | バックアップから戻し、4ファイルを再確認する |
| 単一ノードでスキャンが止まる | 自動更新やマシン再起動の影響 | 本番は2ノード以上を検討する |
| スキャン対象追加後にエラーが出る | JDK、JRE、ドライバー、Visual C++などの不足 | コネクタごとの前提条件を確認する |
| 長時間スキャン中に応答しなくなる | ホストマシンが休止状態になる | 電源プランで休止状態を無効化する |
| ディスク容量がじわじわ減る | 一時フォルダー内の古い数値フォルダーが残る | 7日より古い一時フォルダーを定期クリーンアップする |
展開前には、単に「SHIRをインストールする」だけでなく、ネットワークチーム、セキュリティチーム、データ基盤チームで責任分界点を決めておくことが重要です。特に、ファイアウォール許可、Private DNS、プロキシ認証、ドライバー配置は担当が分かれやすいため、作業漏れが発生しやすい領域です。
管理者向けチェックリスト
本番環境でSHIRを使う前に、最低限次の項目を確認してください。
| 確認項目 | チェック内容 |
|---|---|
| 権限 | Purviewのデータソース管理者権限がある |
| マシン | 64ビットOS、.NET Framework 4.7.2以上、推奨スペックを満たす |
| 配置 | ADF/Synapse IRと同じマシンに入れていない |
| 電源 | 休止状態にならない |
| ネットワーク | Purview、Azure Relay、Storage、Entra ID、データソースへの送信が許可されている |
| DNS | プライベートエンドポイント利用時にプライベートIPへ解決される |
| プロキシ | 必要な場合は3方式のいずれかで正しく設定している |
| サービスアカウント | NT SERVICE\DIAHostServiceまたは指定アカウントに必要権限がある |
| 追加コンポーネント | JRE、OpenJDK、JDK、Visual C++、ドライバーなどをコネクタごとに確認した |
| 可用性 | 本番では複数ノード化を検討した |
| 更新 | 自動更新、手動更新、バージョン有効期限を確認した |
| 監視 | ノード状態、イベントログ、通知領域、スキャン失敗時ログを確認できる |
開発者・データ担当者が確認すべきポイント
開発者やデータ管理者は、SHIRそのものの構築をインフラ担当に任せがちです。しかし、スキャン対象を追加する側にも確認すべきことがあります。
まず、スキャン対象のデータソースがどのIRタイプに対応しているかを確認します。Microsoft PurviewにはAzure IR、Managed Virtual Network IR、SHIR、Kubernetes対応SHIR、AWS IRなどがあり、データソースやネットワーク制御に応じて選択が変わります。(Microsoft Learn)
次に、コネクタ固有の前提条件を確認します。たとえば、ファイル形式やデータベースによっては、JavaランタイムやJDBCドライバーが必要です。これを後回しにすると、Purview側の接続設定は正しくてもスキャン実行時に失敗します。
最後に、スキャンスケジュールをインフラ負荷と合わせて設計します。SHIRマシンのCPUとメモリ使用量は、設定したスキャン頻度やデータ量、同時実行数によってピークが発生します。夜間バッチ、バックアップ、ETL処理とスキャン時間が重なると、マシン負荷やデータソース負荷が高くなるため注意してください。(Microsoft Learn)
次に取るべき対応
Microsoft PurviewでSHIRを使っている、またはこれから導入する場合は、まず現在の構成を棚卸ししてください。見るべき順序は、マシン要件、ネットワーク、DNS、プロキシ、ノード構成、バージョン、スキャン対象ごとの前提条件です。
特に本番環境では、単一ノード運用のままにせず、可用性と自動更新時の影響を確認しましょう。閉域網やプライベートエンドポイントを使っている環境では、ポータル上の設定だけで判断せず、SHIRマシンからの名前解決と接続確認まで行うことが重要です。
SHIRは、Microsoft Purviewのデータガバナンスをオンプレミスやプライベートネットワークまで広げるための要になるコンポーネントです。安全に運用するには、作成手順だけでなく、通信経路、認証、更新、ノード管理まで含めて標準手順化してください。
コメント