Teradata 移行のセキュリティ、アクセス、操作

  • [アーティクル]

この記事は、Teradata から Azure Synapse Analytics に移行する方法についてガイダンスを提供する 7 つのパートから成るシリーズの第 3 部です。 この記事では、セキュリティ アクセス操作のベスト プラクティスに焦点をあてます。

セキュリティに関する考慮事項

この記事では、既存の Teradata レガシ環境の接続方法について説明し、どのようにすると、それらの接続方法を、リスクとユーザーへの影響を最小限に抑えて Azure Synapse Analytics に移行できるかを説明します。

この記事では、接続とユーザー、ロール、およびアクセス許可の構造については、既存の方法をそのまま移行する必要があると想定しています。 そうでない場合は、Azure portal を使用して、新しいセキュリティ体制を作成し、管理します。

Azure Synapse のセキュリティ オプションの詳細については、セキュリティに関するホワイト ペーパーを参照してください。

接続と認証

Teradata の認可オプション

ヒント

Teradata と Azure Synapse の両方の認証は、"データベース内で"、または外部メソッドを通じて行うことができます。

Teradata では、接続と認可のためのメカニズムがいくつかサポートされています。 有効なメカニズム値は次のとおりです。

  • TD1。認証メカニズムとして Teradata 1 を選択する。 ユーザー名とパスワードが必要です。

  • TD2。認証メカニズムとして Teradata 2 を選択する。 ユーザー名とパスワードが必要です。

  • TDNEGO。ユーザーが関与することなく、ポリシーに基づいて自動的に認証メカニズムの 1 つを選択します。

  • LDAP。これは、認証メカニズムとしてライトウェイト ディレクトリ アクセス プロトコル (LDAP) を選択します。 アプリケーションから、ユーザー名とパスワードが提供されます。

  • KRB5。Windows サーバーと連携する Windows クライアントで Kerberos (KRB5) を選択します。 KRB5 を使ってサインインする場合、ユーザーはドメイン、ユーザー名、およびパスワードを指定する必要があります。 ドメインは、MyUserName@MyDomain にユーザー名を設定して指定します。

  • NTLM。Windows サーバーと連携する Windows クライアントで NTLM を選択します。 アプリケーションから、ユーザー名とパスワードが提供されます。

Kerberos (KRB5)、Kerberos Compatibility (KRB5C)、NT LAN Manager (NTLM)、NT LAN Manager Compatibility (NTLMC) は、Windows 専用です。

Azure Synapse の認可オプション

Azure Synapse では、接続と認可について、2 つの基本的オプションがサポートされています。

  • SQL 認証: SQL 認証は、データベース識別子、ユーザー ID、パスワード、その他の省略可能なが含まれるデータベース接続を介して行われます。 これは、Teradata TD1、TD2、および既定の接続と機能的に同じです。

  • Microsoft Entra 認証: Microsoft Entra 認証を使用すると、データベース ユーザーの ID やその他の Microsoft サービスを一元管理できます。 ID の一元管理では、1 か所で SQL Data Warehouse ユーザーを管理できるようになるため、アクセス許可の管理が容易になります。 Microsoft Entra ID では、LDAP および Kerberos サービスへの接続もサポートできます。たとえば、データベースの移行後も既存の LDAP ディレクトリが存続する場合には、Microsoft Entra 認証を使ってそれに接続できます。

ユーザー、ロール、アクセス許可

概要

ヒント

移行プロジェクトを成功させるには、高レベルの計画が極めて重要です。

Teradata と Azure Synapse のどちらでも、ユーザー、ロール、アクセス許可を組み合わせてデータベースのアクセス制御を実装します。 両方で、標準 SQL の CREATE USER および CREATE ROLE ステートメントを使用してユーザーとロールを定義し、GRANT および REVOKE ステートメントを使用してそれらのユーザーやロールに対するアクセス許可の割り当てまたは削除を行います。

ヒント

所要時間とエラーの範囲を減らすため、移行プロセスを自動化することをお勧めします。

2 つのデータベースは概念的に類似していて、既存のユーザー ID、ロール、アクセス許可の移行をある程度自動化できる可能性があります。 そのようなデータを移行するには、Teradata システム カタログのテーブルから既存のレガシ ユーザーとロールの情報を抽出し、それらに合致する同じユーザー/ロール階層を再作成するために Azure Synapse で実行する、同等の CREATE USER ステートメントと CREATE ROLE ステートメントを生成します。

データの抽出後、Teradata システム カタログのテーブルを使用して同等の GRANT ステートメントを生成し、(同等のアクセス許可が存在する場所に) アクセス許可を割り当てます。 次の図は、既存のメタデータを使用して必要な SQL を生成する方法を示しています。

既存のシステムからの特権の移行を自動化する方法を示す図。

ユーザーと役割

ヒント

データ ウェアハウスを移行するには、テーブル、ビュー、SQL ステートメント以上のものが必要です。

Teradata システムの現在のユーザーとロールに関する情報は、システム カタログ テーブル DBC.USERS (または DBC.DATABASES) および DBC.ROLEMEMBERS にあります。 これらのテーブルのクエリを実行して (ユーザーにそれらのテーブルに対する SELECT アクセス権がある場合)、システム内で定義されているユーザーとロールの現在の一覧を取得します。 個々のユーザーに対してこれを行うクエリの例を以下に示します。

/***SQL to find all users***/
SELECT
DatabaseName AS UserName
FROM DBC.Databases
WHERE dbkind = 'u';

/***SQL to find all roles***/
SELECT A.ROLENAME, A.GRANTEE, A.GRANTOR,
  A.DefaultRole, 
  A.WithAdmin,
  B.DATABASENAME, 
  B.TABLENAME,
  B.COLUMNNAME, 
  B.GRANTORNAME,
  B.AccessRight
FROM DBC.ROLEMEMBERS A 
JOIN DBC.ALLROLERIGHTS B 
ON A.ROLENAME = B.ROLENAME 
GROUP BY 1,2,3,4,5,6,7
ORDER BY 2,1,6;

この例は、SELECT ステートメント内に適切なリテラルとしてテキストを含めることで SELECT ステートメントに変更を加え、一連の CREATE USER および CREATE ROLE ステートメントである結果セットを生成します。

既存のパスワードを取得する方法がないため、Azure Synapse で新しい初期パスワードを割り当てるためのスキームを実装する必要があります。

アクセス許可

ヒント

DML や DDL などの基本的なデータベース操作のためには、同等の Azure Synapse アクセス許可が存在します。

Teradata システムでは、システム・テーブル DBC.ALLRIGHTS と DBC.ALLROLERIGHTS がユーザーとロールのアクセス権を保持しています。 これらのテーブルにクエリを実行して (ユーザーがそれらのテーブルに対する SELECT アクセスを持っている場合)、システム内で定義されているアクセス権の現在の一覧を取得します。 個々のユーザーに対するクエリの例を以下に示します。

/**SQL for AccessRights held by a USER***/
SELECT UserName, DatabaseName,TableName,ColumnName,
CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE 
ALRTS.AccessRight
END AS AccessRight, GrantAuthority, GrantorName, AllnessFlag, CreatorName, CreateTimeStamp
FROM DBC.ALLRIGHTS ALRTS LEFT OUTER JOIN AccessRightsAbbv Abbv
ON ALRTS.AccessRight = Abbv.AccessRight 
WHERE UserName='UserXYZ'
Order By 2,3,4,5;

/**SQL for AccessRights held by a ROLE***/
SELECT RoleName, DatabaseName,TableName,ColumnName,
CASE WHEN Abbv.AccessRight IS NOT NULL THEN Abbv.Description ELSE 
ALRTS.AccessRight
END AS AccessRight, GrantorName, CreateTimeStamp
FROM DBC.ALLROLERIGHTS ALRTS LEFT OUTER JOIN AccessRightsAbbv
Abbv
ON ALRTS.AccessRight = Abbv.AccessRight 
WHERE RoleName='BI_DEVELOPER'
Order By 2,3,4,5;

SELECT ステートメント内に適切なテキストをリテラルとして含めることで SELECT ステートメントの例に変更を加え、一連の GRANT ステートメントである結果セットを生成します。

結合キーは省略形の 'type' フィールドなので、アクセス権のフルテキストを検索するには、テーブル AccessRightsAbbv を使用します。 Teradata でのアクセス権と、Azure Synapse でのそれらと同等のアクセス権の一覧については、次の表を参照してください。

Teradata のアクセス許可名 Teradata データ型 Azure Synapse での同等物
ABORT SESSION AS KILL DATABASE CONNECTION
ALTER EXTERNAL PROCEDURE AE 4
ALTER FUNCTION AF ALTER FUNCTION
ALTER PROCEDURE AP ALTER PROCEDURE
CHECKPOINT CP CHECKPOINT
CREATE AUTHORIZATION CA CREATE LOGIN
CREATE DATABASE CD CREATE DATABASE
CREATE EXTERNALPROCEDURE CE 4
CREATE FUNCTION CF CREATE FUNCTION
CREATE GLOP [GC] 3
CREATE MACRO CM CREATE PROCEDURE 2
CREATE OWNER PROCEDURE OP CREATE PROCEDURE
CREATE PROCEDURE PC CREATE PROCEDURE
CREATE PROFILE CO CREATE LOGIN 1
CREATE ROLE CR CREATE ROLE
DROP DATABASE DD DROP DATABASE
DROP FUNCTION DF DROP FUNCTION
DROP GLOP GD 3
DROP MACRO DM DROP PROCEDURE 2
DROP PROCEDURE PD DELETE PROCEDURE
DROP PROFILE DO DROP LOGIN 1
DROP ROLE DR DELETE ROLE
DROP TABLE DT DROP TABLE
DROP_TRIGGER DG 3
DROP USER DU DROP USER
DROP VIEW DV DROP VIEW
DUMP DP 4
EXECUTE E EXECUTE
EXECUTE FUNCTION EF EXECUTE
EXECUTE PROCEDURE PE EXECUTE
GLOP MEMBER GM 3
INDEX IX CREATE INDEX
INSERT I INSERT
MONRESOURCE MR 5
MONSESSION MS 5
OVERRIDE DUMP CONSTRAINT OA 4
OVERRIDE RESTORE CONSTRAINT OR 4
REFERENCES RF REFERENCES
REPLCONTROL RO 5
RESTORE RS 4
SELECT R SELECT
SETRESRATE SR 5
SETSESSRATE SS 5
SHOW SH 3
UPDATE U UPDATE

AccessRightsAbbv テーブルの注記:

  1. Teradata PROFILE の機能は、Azure Synapse の LOGIN と同じです。

  2. 次の表は、Teradata のマクロとストアド プロシージャの違いをまとめたものです。 Azure Synapse では、表で説明されている機能をプロシージャが提供します。

    マクロ ストアド プロシージャ
    SQL を含む SQL を含む
    BTEQ ドット コマンドを含む場合がある 包括的な SPL を含む
    渡されたパラメーター値を受け取ることがある 渡されたパラメーター値を受け取ることがある
    1 つ以上の行を取得することがある カーソルを使用して複数の行を取得する必要がある
    DBC PERM スペースに格納される DATABASE または USER PERM に格納される
    クライアントに行を返す 1 つ以上の値をパラメーターとしてクライアントに返す場合がある

  3. SHOW、GLOP および TRIGGER には、直接 Azure Synapse で同等のものはありません。

  4. これらの機能は、Azure Synapse のシステムによって自動的に管理されます。 「運用面の考慮事項」を参照してください。

  5. Azure Synapse では、これらの機能はデータベースの外部で処理されます。

Azure Synapse でのアクセス権の詳細については、Azure Synapse Analytics のセキュリティ アクセス許可に関するページを参照してください。

操作上の考慮事項

ヒント

データ ウェアハウスを効率的に運用し続けるには、運用タスクが必要です。

このセクションでは、ユーザーへのリスクと影響を最小限に抑えて、Teradata の一般的な運用タスクを Azure Synapse に実装する方法について説明します。

すべてのデータ ウェアハウス製品と同様に、いったん運用環境に移行すると、システムを効率的に実行し続け、監視と監査に向けてデータを提供するために、継続的な管理タスクが必要となります。 データのバックアップ/復元と同様に、将来の成長のためのリソース使用率と容量計画もこのカテゴリに分類されます。

さまざまなデータ ウェアハウスの管理と運用のタスクは、概念的には類似していますが、個々の実装は異なっている場合があります。 一般に、Azure Synapse などの最新のクラウドベースの製品には (Teradata などの従来のデータ ウェアハウスでの、より "手作業が多い" アプローチとは対照的に)、自動化が進んだ "システムによる管理" のアプローチが組み込まれている傾向があります。

以降のセクションでは、さまざまな運用タスクについて、Teradata と Azure Synapse のオプションを比較します。

ハウスキープ処理タスク

ヒント

ハウスキープ処理タスクでは、運用ウェアハウスが効率的に動作している状態を保ち、ストレージなどのリソースの使用を最適化します。

従来のデータ ウェアハウス環境のほとんどでは、更新または削除された行の古いバージョンを削除することによって解放できるディスク ストレージ領域を再利用したり、効率を高めるためにデータ ログ ファイルやインデックス ブロックを再編成したりするなど、通常の "ハウスキープ処理" タスクを実行する必要があります。 統計の収集も、時間のかかる可能性のあるタスクです。 クエリ実行プランの基本生成に対する最新のデータをクエリ オプティマイザーに提供するには、一括データ取り込みの後に統計を収集する必要があります。

Teradata では、以下のように統計を収集することが推奨されています。

  • データが入っていないテーブルの統計を収集し、内部処理で使用される間隔ヒストグラムを設定します。 この初期収集によって、後続の統計収集がより高速になります。 データが追加された後は必ず統計を再収集してください。

  • 新しく設定されたテーブルのプロトタイプ フェーズ統計を収集します。

  • テーブルまたはパーティションにかなりの割合で変更が加えられた後 (およそ 10% の行)、運用フェーズの統計を収集します。 日付やタイムスタンプなどの一意でない値の量が多い場合は、7% で再収集すると有益である可能性があります。

  • ユーザーを作成し、実際のクエリの読み込みをデータベースに適用した後に、運用フェーズの統計を収集します (最大約 3 か月のクエリの実行)。

  • CPU 使用率が低い期間中のアップグレードまたは移行後、最初の数週間のうちに統計を収集します。

統計収集は、自動統計管理のオープン API を使用して手動で管理することも、Teradata Viewpoint Stats Manager ポートレットを使用して自動的に管理することもできます。

ヒント

Azure でハウスキープ処理タスクを自動化して監視します。

Teradata Database には、データ ディクショナリ内に、自動的に、または特定の機能を有効にした後にデータを蓄積するログ テーブルが多数含まれています。 ログ データは時間の経過とともに増大するため、永続的な領域を使い切らないように古い、情報は消去してください。 これらのログを使用可能に保つメンテナンスを自動化するオプションがあります。 メンテナンスが必要な Teradata ディクショナリ テーブルについて次に説明します。

保持する必要があるディクショナリ テーブル

ソフトウェアに付属している DBC.AMPUsage ビューと ClearPeakDisk マクロを使用してアキュムレータとピーク値をリセットします。

  • DBC.Acctg: アカウント/ユーザー別のリソース使用量

  • DBC.DataBaseSpace: データベースとテーブル領域のアカウンティング

Teradata ではこれらのテーブルが自動的に保持されますが、適切な方法でサイズを小さくできます。

  • DBC.AccessRights: オブジェクトに対するユーザー権利

  • DBC.RoleGrants: オブジェクトに対するロール権利

  • DBC.Roles: 定義されているロール

  • DBC.Accounts: ユーザー別のアカウント コード

これらのログ テーブルをアーカイブし (必要な場合)、60 日から 90 日経過した情報を消去します。 リテンション期間は、お客様の要件によって異なります。

  • DBC.SW_Event_Log: データベース コンソール ログ

  • DBC.ResUsage: リソース監視テーブル

  • DBC.EventLog: セッション ログオン/ログオフの履歴

  • DBC.AccLogTbl: ログに記録されたユーザー/オブジェクト イベント

  • DBC.DBQL tables: ログに記録されたユーザー/SQL アクティビティ

  • .NETSecPolicyLogTbl: 動的セキュリティ ポリシー監査証跡をログに記録する

  • .NETSecPolicyLogRuleTbl: 動的セキュリティ ポリシーをログに記録するタイミングと方法を制御する

関連付けられているリムーバブル メディアの有効期限が切れて上書きされたら、次のテーブルを消去します。

  • DBC.RCEvent: アーカイブ/復旧イベント

  • DBC.RCConfiguration: アーカイブ/復旧の構成

  • DBC.RCMedia: アーカイブ/復旧の用 VolSerial

Azure Synapse には、必要に応じて使用できるように統計を自動的に作成するオプションがあります。 インデックスとデータ ブロックの最適化を、手動で、スケジュールに基づいて、または自動的に実行します。 ネイティブの組み込み Azure 機能を利用すると、移行の業務で必要な労力を削減できます。

監視と監査

ヒント

時間の経過とともに、Teradata システムの監視とログ記録を可能にするために、何種類かのツールが実装されています。

Teradata には、Teradata Viewpoint や Ecosystem Manager など、操作を監視するツールがいくつか用意されています。 クエリ履歴をログに記録するために、データベース クエリ ログ (DBQL) という Teradata Database の機能があり、ユーザー定義ルールに基づいてクエリの履歴レコードとその期間、パフォーマンス、およびターゲット アクティビティを格納できる一連の定義済みテーブルが提供されます。

データベース管理者は Teradata Viewpoint を使用して、システムの状態、傾向、および個々のクエリの状態を判断できます。 システムの使用状況で傾向を観察することで、システム管理者は、プロジェクト実装、バッチ ジョブ、およびメンテナンスをより適切に計画して使用のピーク期間を回避することができます。 ビジネス ユーザーは Teradata Viewpoint を使用して、レポートやクエリの状態にすばやくアクセスし、詳細をドリルダウンできます。

ヒント

Azure portal には、Azure のデータとプロセスすべてについて監視と監査のタスクを管理する GUI が用意されています。

同じように、Azure portal 内にある Azure Synapse のリッチな監視エクスペリエンスでは、データ ウェアハウスのワークロードに関する分析情報が表示されます。 データ ウェアハウスを監視するときの推奨されるツールである Azure portal では、構成可能なリテンション期間、アラート、推奨事項、およびメトリックとログのカスタマイズ可能なグラフとダッシュボードが提供されます。

ポータルでは、Operations Management Suite (OMS) や Azure Monitor (ログ) などの他の Azure 監視サービスと統合して、お使いのデータ ウェアハウスだけでなく、統合された監視エクスペリエンスに対する Azure 分析プラットフォーム全体も含む、総合的な監視エクスペリエンスを提供することもできます。

ヒント

低レベルのシステム全体が対象のメトリックは、Azure Synapse で自動的にログ記録されます。

Azure Synapse 用のリソース使用率の統計は、システム内で自動的にログ記録されます。 各クエリについてのメトリックには、CPU、メモリ、キャッシュ、I/O、一時ワークスペースの使用状況の統計情報のほか、失敗した接続試行数などの接続情報が含まれます。

Azure Synapse には、動的管理ビュー (DMV) のセットが用意されています。 これらのビューは、アクティブのトラブルシューティングを行うときと、ワークロードでパフォーマンスのボトルネックを特定するときに役に立ちます。

詳細については、Azure Synapse の操作と管理のオプションに関するページを参照してください。

高可用性 (HA) とディザスター リカバリー (DR)

Teradata は、FALLBACK、アーカイブ復元コピー (ARC) ユーティリティ、Data Stream Architecture (DSA) などの機能を実装して、データのレプリケーションとアーカイブを介してデータ損失防止と高可用性 (HA) の保護を提供します。 ディザスター リカバリー (DR) オプションには、回復時間の要件に応じて、Dual Active Solution、サービスとしての DR、または交換システムが含まれます。

ヒント

Azure Synapse では、復旧時間が確実に短縮されるように、スナップショットを自動的に作成します。

Azure Synapse では、データベース スナップショットを使用してウェアハウスの高可用性を提供します。 データ ウェアハウス スナップショットでは、データ ウェアハウスの以前の状態を復旧またはコピーするために利用できる復元ポイントが作成されます。 Azure Synapse は分散システムであるため、データ ウェアハウス スナップショットは、Azure Storage 内にある多数のファイルで構成されます。 スナップショットでは、データ ウェアハウスに格納されたデータの増分の変更がキャプチャされます。

Azure Synapse では、スナップショットが終日自動的に取得され、7 日間利用できる復元ポイントが作成されます。 この保持期間は変更できません。 Azure Synapse では、8 時間の回復ポイントの目標 (RPO) がサポートされています。 データ ウェアハウスは、プライマリ リージョンで、過去 7 日間に作成されたいずれかのスナップショットから復元できます。

ヒント

キーの更新前に、ユーザー定義スナップショットを使用して復旧ポイントを定義します。

ユーザー定義の復元ポイントもサポートされており、大規模な変更の前後に、スナップショットを手動でトリガーして、データ ウェアハウスの復元ポイントを作成することができます。 この機能により、復元ポイントの論理的な一貫性が保証されており、ワークロードの中断やユーザー エラーが発生した場合には、必要とされる 8 時間未満での RPO に備えて追加のデータ保護が提供されます。

ヒント

Microsoft Azure では、DR を実現するために、地理的に離れた場所への自動バックアップを提供しています。

Azure Synapse では、前述のスナップショットだけでなく、geo バックアップも実行されます。これは、ペアになっているデータセンターに対して、1 日に 1 回、標準として実行されます。 geo 復元の RPO は 24 時間です。 geo バックアップは、Azure Synapse がサポートされているその他の任意のリージョン内のサーバーに復元することができます。 geo バックアップにより、プライマリ リージョン内の復元ポイントを利用できない場合でもデータ ウェアハウスを確実に復元できます。

ワークロードの管理

ヒント

運用データ ウェアハウスでは、一般に、異なるリソース使用特性を持つ混合ワークロードが同時に実行されています。

ワークロードは、データベースへのアクセスを一連のルールで管理できる共通の特性を持つ種類のデータベース要求です。 ワークロードは次の場合に役立ちます。

  • 要求の種類ごとに異なるアクセス優先順位を設定する。

  • リソースの使用パターンの監視、パフォーマンスチューニング、容量計画。

  • 同時に実行できる要求またはセッションの数を制限する。

Teradata システムの場合、ワークロード管理とは、システムのアクティビティを監視し、事前に定義された制限に達したときに対応することで、ワークロードのパフォーマンスを管理する処理です。 ワークロード管理ではルールが使用され、各ルールは一部のデータベース要求にのみ適用されます。 ただし、すべてのルールのコレクションは、プラットフォーム上のアクティブな作業すべてに適用されます。 Teradata Active System Management (TASM) は、Teradata Database で完全なワークロード管理を実行します。

Azure Synapse で、リソース クラスは、クエリ実行のためにコンピューティング リソースとコンカレンシーを制御する、あらかじめ決定されたリソース制限です。 リソース クラスは、ワークロードを管理するのに役立ちます。クラスに応じて、同時に実行されるクエリの数と、各クエリに割り当てられるコンピューティング リソースに制限を設定します。 メモリとコンカレンシーの間にはトレードオフがあります。

Azure Synapse は、リソース使用率の統計情報を自動的にログに記録します。 メトリックには、各クエリの CPU、メモリ、キャッシュ、I/O、一時ワークスペースの使用状況の統計情報が含まれます。 Azure Synapse は、接続の失敗などの接続情報もログに記録します。

ヒント

詳細レベルとシステム全体のメトリックが、Azure Synapse で自動的にログに記録されます。

Azure Synapse では、次の基本的なワークロード管理の概念がサポートされています。

  • ワークロードの分類: ワークロード グループに要求を割り当てて、重要度レベルを設定できます。

  • ワークロードの重要度: 要求がリソースにアクセスする順序に影響を与えることができます。 既定では、クエリは、リソースが使用可能になると先入れ先出しでキューから解放されます。 ワークロードの重要度を使用すると、キューに関係なく、優先順位の高いクエリがリソースをすぐに受け取るようにできます。

  • ワークロードの分離: ワークロード グループのリソースを予約したり、さまざまなリソースの最大と最小の使用量を割り当てたり、要求のグループが使用できるリソースを制限したり、タイムアウト値を設定してランナウェイ クエリを自動的に強制終了したりできます。

混合ワークロードを実行すると、ビジー状態のシステムでリソースの問題が発生する可能性があります。 正常なワークロード管理スキームでは、リソースが効果的に管理され、リソースが確実に効率よく利用され、投資収益率 (ROI) が最大化されます。 ワークロードの分類、ワークロードの重要度、ワークロードの分離により、ワークロードでのシステム リソースの利用方法をより詳細に制御できます。

ワークロード管理ガイドでは、ワークロードの分析、[ワークロードの重要度の管理と監視](../../sql-data-warehouse/sql-data-warehouse-how-to-manage-and-monitor-workload-importance.md)の手法、リソース クラスのワークロード グループへの変換手順について説明されています。 Azure portal と DMV に対する T-SQL クエリを使用してワークロードを監視し、該当するリソースが効率的に利用されるようにします。 Azure Synapse には、ワークロード管理のすべての側面を監視するための一連の動的管理ビュー (DMV) が用意されています。 これらのビューは、アクティブにトラブルシューティングを行うときと、ワークロードでパフォーマンスのボトルネックを特定するときに役立ちます。

この情報を容量計画のために使用して、追加のユーザーやアプリケーション ワークロードのために必要なリソースを判断することもできます。 これは、"ピーク時" のワークロードをコスト効率よくサポートするため、コンピューティング リソースのスケールアップやスケールダウンを計画する場合にも当てはまります。

Azure Synapse でのワークロード管理の詳細については、「リソース クラスを使用したワークロード管理」を参照してください。

コンピューティング リソースをスケーリングする

ヒント

Azure の主な利点は、コンピューティング リソースをオンデマンドで個別にスケールアップおよびスケールダウンし、ピーク時間のあるワークロードをコスト効率よく処理できることです。

Azure Synapse のアーキテクチャでは、ストレージとコンピューティングが分離されており、それぞれを独立してスケーリングできます。 結果として、データ ストレージから独立して、パフォーマンスの需要を満たすためにコンピューティング リソースをスケーリングできます。 コンピューティング リソースは、一時停止して再開することもできます。 このアーキテクチャには、コンピューティングとストレージに対する課金は独立しているという当然の利点があります。 データ ウェアハウスが使用されていない場合は、コンピューティングを一時停止してコンピューティング コストを節約できます。

コンピューティング リソースは、そのデータ ウェアハウスのデータ ウェアハウス ユニット設定を調整することでスケールアップまたはスケールバックできます。 データ ウェアハウス ユニットを追加するにつれて、読み込みとクエリのパフォーマンスは直線的に増加します。

コンピューティング ノードを追加すると、より多くのコンピューティング能力と、より多くの並列処理を活用する機能が追加されます。 コンピューティング ノードの数が増加するにつれて、コンピューティング ノードあたりのディストリビューション数が減少し、コンピューティング能力と並列処理は、クエリのためにより多く提供されます。 同様に、データ ウェアハウス ユニットを減らすと、コンピューティング ノードの数が減少し、それによってクエリ用のコンピューティング リソースが減少します。

次のステップ

視覚化とレポートの詳細を確認するには、このシリーズの次の記事「Teradata 移行の視覚化とレポート」を参照してください。