Synapse 実装成功の技法: ワークスペース設計を評価する

注意

この記事は、「設計による Azure Synapse 実装の成功」シリーズの記事の一部です。 このシリーズの概要については、設計による Azure Synapse 実装の成功に関するページを参照してください。

Synapse ワークスペースは、分析エンジンとデータ処理エンジン、データ レイク、データベース、テーブル、データセット、レポート成果物とコードおよびプロセス オーケストレーションを 1 つにまとめた、統合されたグラフィカル ユーザー エクスペリエンスです。 Synapse ワークスペースに統合されているテクノロジとサービスの数を考慮して、主要なコンポーネントが設計に含まれていることを確認します。

Synapse ワークスペース設計のレビュー

ソリューション設計に 1 つの Synapse ワークスペースと複数のワークスペースのどちらが含まれているかを識別します。 この設計のドライバーを判別します。 別の理由も考えられますが、ほとんどの場合、複数のワークスペースを使用する理由は、セキュリティの分離または課金の分離のいずれかです。 ワークスペースおよびデータベースの境界の数を決定する場合、サブスクリプションあたりのワークスペース数に 20 個の制限があることに注意してください。

各ワークスペース内のどの要素またはサービスを共有する必要があり、どのリソースと共有する必要があるかを識別します。 リソースには、データ レイク、統合ランタイム (IR)、メタデータまたは構成、コードを含めることができます。 潜在的な相乗効果の観点から、この特定の設計が選択された理由を特定します。 これらの相乗効果によって、追加のコストと管理オーバーヘッドが正当化されるかどうかを自問してください。

データ レイク設計のレビュー

データ レイク (ソリューションに含まれている場合) を適切に階層化することをお勧めします。 データ レイクは、"ブロンズ"、"シルバー"、"ゴールド" のデータセットに関連する 3 つの主要な領域に分割する必要があります。 ブロンズ (または生レイヤー) は、マスクされていない機密データが格納される可能性があるという理由でアクセス制御がより厳格になるため、専用の個別ストレージ アカウントに存在する可能性があります。

セキュリティ設計のレビュー

ワークスペースのセキュリティ設計を確認し、評価中に収集した情報と比較します。 すべての要件が満たされ、すべての制約が考慮されていることを確認します。 管理を容易にするために、適切なアクセス許可プロファイルを持つグループにユーザーを分類することをお勧めします。ロールと一致するセキュリティ グループを使用すると、アクセス制御を簡略化できます。 こうすることで、ネットワーク管理者は、適切なセキュリティ グループに対してユーザーを追加または削除して、アクセスを管理できます。

サーバーレス SQL プールと Apache Spark テーブルでは、ワークスペースに関連付けられた Azure Data Lake Gen2 (ADLS Gen2) コンテナーにデータが格納されます。 ユーザーがインストールした Apache Spark ライブラリも、この同じストレージ アカウントで管理されます。 これらのユース ケースを実現するには、ユーザーとワークスペース マネージド サービス ID (MSI) の両方を ADLS Gen2 ストレージ コンテナーの ストレージ BLOB データ共同作成者 ロールに追加する必要があります。 この要件をセキュリティ要件に照らして検証します。

専用 SQL プールには、機密データを暗号化およびマスクするための豊富なセキュリティ機能セットが用意されています。 専用 SQL プールとサーバーレス SQL プールはどちらも、組み込みロール、ユーザー定義ロール、SQL 認証、Microsoft Entra 認証など、SQL Server のアクセス許可の完全な領域を有効にします。 ソリューションの専用 SQL プールとサーバーレス SQL プールのアクセスとデータのセキュリティ設計を確認します。

データ レイクのセキュリティ プランと、Azure Synapse Analytics ソリューションの一部となるすべての ADLS Gen2 ストレージ アカウント (およびその他のアカウント) のセキュリティ計画を確認します。 ADLS Gen2 ストレージ自体はコンピューティング エンジンではないため、データ属性を選択的にマスクする組み込み機能を備えていません。 ADLS Gen2 アクセス許可は、ロールベースのアクセス制御 (RBAC) を使用してストレージ アカウントまたはコンテナー レベルで、またはアクセス制御リスト (ACL) を使用してフォルダーまたはファイル レベルで適用できます。 設計を注意深く確認し、不要な複雑さを回避するように努めてください。

セキュリティ設計で考慮すべきいくつかの点を次に示します。

• 設計には必ず Microsoft Entra ID のセットアップ要件を含めます。
• テナント間のシナリオを確認します。 このような問題は、一部のデータが別の Azure テナントにある、別のテナントに移動する必要がある、または別のテナントのユーザーがアクセスする必要があるために発生する可能性があります。 設計では、必ずこれらのシナリオを考慮してください。
• 各ワークスペースのロールは何ですかか? ワークスペースをどのように使用しますか?
• ワークスペース内でセキュリティはどのように設計されていますか?
  • すべてのスクリプト、ノートブック、パイプラインを表示できるのは、どのユーザーですか?
  • スクリプトとパイプラインを実行できるのは、どのユーザーですか?
  • SQL プールと Spark プールを作成、一時停止、再開できるのは、どのユーザーですか?
  • ワークスペースに変更を発行できるのは、どのユーザーですか?
  • ソース管理に変更をコミットできるのは、どのユーザーですか?
• パイプラインでは、格納された資格情報またはワークスペースのマネージド ID を使用してデータにアクセスしますか?
• ユーザーは、Synapse Studio でデータを参照するのに適したデータ レイクへのアクセス権を持っていますか?
• データ レイクは、RBAC と ACL の適切な組み合わせを使用して適切にセキュリティ保護されていますか?
• 各ロール (データ サイエンティスト、開発者、管理者、ビジネス ユーザーなど) に対して SQL プール ユーザーのアクセス許可が正しく設定されていますか?

ネットワーク設計のレビュー

ネットワーク設計で考慮すべきいくつかの点を次に示します。

• すべてのリソース間の接続は設計されていますか?
• 使用するネットワーク メカニズム (Azure ExpressRoute、パブリック インターネット、またはプライベート エンドポイント) は何ですか?
• Synapse Studio に安全に接続できる必要がありますか?
• データ流出は考慮されていますか?
• オンプレミスのデータ ソースに接続する必要がありますか?
• 他のクラウド データ ソースまたはコンピューティング エンジン (Azure Machine Learning など) に接続する必要がありますか?
• ネットワーク セキュリティ グループ (NSG) などの Azure ネットワーク コンポーネントは、適切な接続とデータ移動について確認されていますか?
• プライベート DNS ゾーンとの統合は考慮されていますか?
• Synapse Studio 内からデータ レイクを参照する必要がありますか? それともサーバーレス SQL または PolyBase を使用してデータ レイク内のデータに対してクエリを実行するだけですか?

最後に、すべてのデータ コンシューマーを特定し、その接続が設計で考慮されていることを確認します。 ネットワーク アウトポストおよびセキュリティ アウトポストを使用することにより、サービスで必要なオンプレミスソースにアクセスできるようになること、およびその認証プロトコルとメカニズムがサポートされていることを確認します。 一部のシナリオでは、Microsoft Power BI など、SaaS ソリューション用に複数のセルフホステッド IR またはデータ ゲートウェイが必要になる場合があります。

監視設計のレビュー

Azure Synapse コンポーネントの監視の設計を確認して、評価中に特定された要件と期待が確実に満たされるようにします。 リソースとデータ アクセスの監視が設計されていること、および各監視要件が特定されていることを確認します。 堅牢な監視ソリューションを、運用環境への最初のデプロイの一部として配置する必要があります。 そうすることにより、適切なタイミングで障害を特定し、診断して、対処することができます。 基本インフラストラクチャとパイプライン実行とは別に、データも監視する必要があります。 使用中の Azure Synapse コンポーネントに応じて、各コンポーネントの監視要件を特定します。 たとえば、Spark プールがソリューションの一部となる場合は、形式に誤りがあるレコード ストアを監視します。 

監視設計で考慮すべきいくつかの点を次に示します。

• 各リソースの種類 (パイプライン、プールなど) を監視できるのは、どのユーザーですか?
• データベース アクティビティ ログを保持する必要がある期間はどのくらいですか?
• ワークスペース ログおよびデータベース ログの保持では、Log Analytics または Azure Storage が使用されますか?
• パイプライン エラーが発生した場合、アラートはトリガーされますか? その場合、誰に通知する必要がありますか?
• アラートをトリガーする必要がある SQL プールのしきい値レベルは何ですか? 誰に通知する必要がありますか?

ソース管理設計のレビュー

Synapse ワークスペースでは、既定により、変更は、組み込みの発行機能を使用して Synapse サービスに直接適用されます。 ソース管理の統合を有効にすることができます。これには、多くの利点があります。 このような利点としては、開発、テスト、運用の各環境まで変更を昇格するためのコラボレーション、バージョン管理、承認、リリース パイプラインの改善などがあります。 Azure Synapse では、ワークスペースごとに 1 つのソース管理リポジトリを使用できます。これは、Azure DevOps Git または GitHub のいずれかになります。

ソース管理設計で考慮すべきいくつかの点を次に示します。

• Azure DevOps Git を使用している場合、Synapse ワークスペースとそのリポジトリは同じテナント内にありますか?
• ソース管理にアクセスできるのは、どのユーザーですか?
• ソース管理では、各ユーザーにどのようなアクセス許可が付与されますか?
• 分岐とマージの戦略は策定されていますか?
• さまざまな環境にデプロイするためのリリース パイプラインは開発されますか?
• マージおよびリリース パイプラインに承認プロセスは使用されますか?

注意

開発環境の設計は、プロジェクトの成功にとって非常に重要です。 開発環境が設計されている場合は、この手法の別の段階で評価されます。

次の手順

"設計による Azure Synapse の成功" シリーズの次の記事では、データ統合設計を評価し、それがガイドラインと要件を検証する方法について説明します。