データの本番運用におけるさまざまなセキュリティおよびガバナンス要件を満たすため、DataWorks では基本モードと標準モードという 2 種類のワークスペースモードを提供しています。本トピックでは、アーキテクチャや開発ワークフローへの影響など、複数の観点からこれら 2 つのモードの違いについて説明します。
背景情報
本トピックでは、ワークスペースモードに関する以下の項目を取り上げます。
|
セクション |
説明 |
|
各ワークスペースモードのアーキテクチャについて説明します。 |
|
|
各モードのアーキテクチャが DataWorks におけるノード開発および運用保守 (O&M) にどのように影響するかを説明します。 |
|
|
各ワークスペースモードのメリットとデメリットを比較します。 |
|
|
標準モードワークスペースにおいて、ワークフローガバナンスを実現するために役割と責任がどのように管理されるかを示します。 |
|
|
基本モードのワークスペースには本番環境のみが存在しますが、標準モードのワークスペースには開発環境と本番環境の両方が存在します。本セクションでは、各モードにおける DataWorks モジュールと対応する環境とのマッピング関係を示します。 |
|
|
基本モードワークスペースを使用しており、開発環境と本番環境を分離したい場合は、本セクションをご参照ください。 |
注意事項
-
ワークスペースモードによって、データソースの作成要件が異なります。標準モードワークスペースでは、環境隔離を実現するために、開発環境と本番環境それぞれに対して物理的に分離されたデータソースを作成する必要があります。ワークスペースのデータソース作成方法の詳細については、「データソースの作成」をご参照ください。
-
プロジェクトまたはデータベースをまたいだリソースへのアクセス可否は、データソースの特性によります。開発環境と本番環境それぞれに異なるデータソースを作成した場合、DataWorks の開発環境から本番環境のテーブル、リソース、関数にアクセスできるかどうかは、データソースの特性に依存します。
-
標準モードワークスペースでは、開発環境のタスクはデフォルトで定期的なスケジュールはされません。タスクを定期的にスケジュールするには、本番環境にデプロイする必要があります。
基本概念
基本モードと標準モードのワークスペースアーキテクチャは、以下の観点から比較できます。
DataWorks を体験する目的であれば、どちらのモードでもワークスペースを作成できます。ただし、実際のデータ開発を行う際には、開発環境と本番環境間のコード隔離、環境間の計算リソース分離、権限隔離、およびタスクデプロイメントワークフローガバナンスを実現するために、標準モードワークスペースの使用を推奨します。
基本モードワークスペースを使用中で既存のコードを保持したい場合は、ワークスペースモードをアップグレードできます。詳細については、「基本モードから標準モードへのワークスペースアップグレード」をご参照ください。
以下の表では、基本モードと標準モードのワークスペースを複数の観点から比較しています。
|
観点 |
基本モード |
標準モード (推奨) |
|
データソースの数 |
DataWorks ワークスペースは 1 つのデータソースに対応します。 |
DataWorks ワークスペースは 2 つのデータソースに対応し、開発環境と本番環境のデータソースを分離できます。 説明 環境隔離を実現するには、開発環境と本番環境それぞれに対して物理的に分離されたデータソースを作成する必要があります。
|
|
対応する DataWorks 環境 |
単一のデータソースが DataWorks の本番環境として機能します。 |
2 つのデータソースのうち、一方が開発環境、もう一方が本番環境として DataWorks に機能します。 説明 開発環境と本番環境それぞれに異なるデータソースを作成できます。例：
|
モードの違いが本番ノードの開発および運用保守に与える影響
|
比較項目 |
基本モード |
標準モード (推奨) |
|
本番タスク開発ワークフローガバナンス |
タスクを送信すると、デプロイを必要とせずにスケジューリングシステムで定期的にスケジュールされ、結果データが生成されます。 (送信 --> 本番)
|
タスクはまず開発環境に送信され、その後本番環境にデプロイされて初めて自動スケジュールされます。 (送信 --> デプロイ --> 本番) 説明 標準モードでは、本番環境のタスクのみが自動スケジュールされます。
|
|
本番タスク運用保守権限ガバナンス |
開発者は本番タスクのコードを直接編集できます。 |
開発者は Data Studio でのみコードの編集および送信が可能であり、本番環境に直接コードをデプロイすることはできません。本番環境へのデプロイには運用保守権限が必要です (プロジェクトオーナー、ワークスペース管理者、オペレーターのロールが該当)。
|
|
本番データアクセスガバナンス |
開発者はテストに本番データを直接使用でき、本番データのセキュリティリスクが生じます。 |
開発者は開発環境でテストデータを使用するか、または開発環境で本番テーブルデータへのアクセス権限を申請して検証できます。 説明
|
|
データアクセス ID |
本番環境で直接操作するための統一 ID が使用されます。 MaxCompute、Hologres、EMR、CDH の場合、アクセス ID には Alibaba Cloud アカウント、RAM ユーザー、RAM ロール (MaxCompute のみ対応)、およびタスクオーナーが含まれます。 説明 AnalyticDB for MySQL や AnalyticDB for PostgreSQL などの他のエンジンの場合、データソース作成時に各環境に関連付けられたアカウントに依存します。権限は、データベース内のアカウントの権限と一致します。 |
説明 MaxCompute、Hologres、EMR、CDH
AnalyticDB for MySQL や AnalyticDB for PostgreSQL などの他のエンジンの場合、データソース作成時に各環境に関連付けられたアカウントに依存します。権限は、データベース内のアカウントの権限と一致します。 |
メリットとデメリットの比較
|
比較項目 |
基本モード |
標準モード |
|
メリット |
シンプルで便利、使いやすいです。 データ開発者に DataWorks 開発者ロールを割り当てるだけで、すべてのデータウェアハウス開発タスクを完了できます。 |
安全かつ標準化されています。
|
|
デメリット |
不安定性および不安全性のリスクがあります。
|
ワークフローが比較的複雑であり、ほとんどのケースで単独ではすべてのデータ開発および本番タスクを完了できません。 |
ユースケース：標準モードがワークフローに与える影響
次の図に示すように、標準モードの開発・本番分離アーキテクチャは、データモデル設計、データ処理ロジック、コードデプロイメントなどのワークフローに影響を及ぼします。
付録：異なるワークスペースモードにおける DataWorks モジュールのデータソースマッピング
に移動して、Data Studio に関連付けられた計算リソースを確認できます。以下の表は、異なるワークスペースモードにおける DataWorks モジュールが操作するデータソースについて説明しています。
|
DataWorks モジュール |
標準モード |
基本モード |
|
Data Studio |
開発環境のデータソース (インスタンス、プロジェクト、またはデータベース) を操作します |
本番環境のデータソース (インスタンス、プロジェクト、またはデータベース) を操作します |
|
オペレーションセンター |
|
付録：基本モードでの開発と本番の分離方法
シナリオ：基本モードワークスペースを使用しており、開発環境と本番環境を分離したい場合。
解決策：基本モードワークスペースを 2 つ用意します。1 つのワークスペースを開発環境として、もう 1 つを本番環境として使用します。その後、ワークスペース間デプロイを使用して、開発ワークスペースから本番ワークスペースにタスクをデプロイすることで、環境隔離を実現します。
欠点：本番環境として機能するワークスペース内のコードは、引き続き Data Studio で直接編集可能であるため、本番環境のコード更新エントリポイントが一意ではなく、開発ワークフローが損なわれる可能性があります。
推奨事項：より適切な開発ワークフローガバナンスを実現するため、基本モードワークスペースを標準モードワークスペースにアップグレードすることを推奨します。詳細については、「基本モードから標準モードへのワークスペースアップグレード」をご参照ください。