# Management UIを使用したData Tank 2.0の管理

Management UIは、Treasure Data Data Tank 2.0の設定、監視、制御を可能にするWebアプリケーションです。Management UIへのアクセスには管理者レベルの権限が必要です。アクセスについては、カスタマーサクセス担当者にお問い合わせください。

[Data Tank 2.0メンテナンスの理解](/ja/products/control-panel/datatank/understanding-data-tank-2-0-maintenance)も参照してください。

## Management UI

Management UIを使用してData Tank 2.0を管理できます。

これらのURLにアクセスする前に、Treasure コンソールにサインインしてください。サインインするユーザーは管理者またはオーナーである必要があります。

| リージョン | URL |
|  --- | --- |
| US | `https://console-aciddb.us01.treasuredata.com/app/acid/db/` |
| Tokyo | `https://console-aciddb.treasuredata.co.jp/app/acid/db/` |
| EU01 | `https://console-aciddb.eu01.treasuredata.com/app/acid/db/` |
| AP02 | `https://console-aciddb.ap02.treasuredata.com/app/acid/db/` |


## データベースの管理

データベースページを使用して、データベース関連の設定を表示および構成します。

Data Tank 2.0データベースページの概要
Data Tank 2.0データベースページの詳細ビュー
| タブ | 説明 |
|  --- | --- |
| **DETAILS** | データベース情報を表示します。Data Tank 2.0の接続設定が表示されます。詳細情報を使用してData Tank 2.0に接続します：Host（ホスト名）、Database（データベース名）、Port（ポート番号）。 |
| **LOGS** | データベースログを表示します。 |
| **MONITORING** | 監視ダッシュボードには、CPU使用率、読み取りおよび書き込み操作、メモリ使用量、ストレージ容量使用量などの使用状況メトリクスを網羅した詳細な統計チャートが表示されます。ストレージ容量の監視は、使用量の予期しない増加を特定し、将来的なアップグレードの必要性を予測するのに役立ちます。 |
| **STATUS** | Data Tank 2.0のデータベースおよびインスタンスパラメータを表示します。例えば、データベースのバージョンを確認するには、**DISPLAY INSTANCE PARAMETERS**を選択します。 |
| **EXTENSIONS** | PostgreSQL拡張モジュールを有効または無効にします。サポートされているモジュールは次のとおりです：`pg_stat_statements`、`hstore`、`intarray`、`pgcrypto`。 |


## スキーマの管理

スキーマページを使用して、スキーマの表示、作成、削除を行います。

Data Tank 2.0スキーマページ
スキーマは、テーブル、ビュー、インデックス、データ型、関数、ストアドプロシージャ、オペレータなどの名前付きデータベースオブジェクトを含む名前空間です。各データベースにはデフォルトとして`public`スキーマが自動的に作成されます。Management UIでは、新しいスキーマの作成と空のスキーマの削除が可能です。スキーマを作成した後、スキーマ名は編集できません。`public`スキーマとその説明は削除できません。

スキーマを使用する場面の例を以下に示します：

- **データベースオブジェクトの整理** -- 例えば、テーブルを論理的なグループに整理して管理しやすくする場合。
- **複数ユーザーの利用** -- 互いに干渉することなく1つのデータベースを使用する場合。


### 新しいスキーマの作成

1. 新しいスキーマを作成するには、**NEW**を選択します。
2. 新しいスキーマを作成します。デフォルトでは、新しいスキーマはDDLステートメントの実行を許可しません。新しいスキーマで特定のユーザーのDDLを有効にするには、**Enable customized DDL**をトグルします。


Data Tank 2.0の新しいスキーマ作成ダイアログ
## アクセスキーの管理

Data Tank 2.0にアクセスするにはアクセスキーが必要です。アクセスキーページでは、Data Tank 2.0へのアクセスに必要なアクセスキーの表示と編集ができます。

Data Tank 2.0アクセスキーページ
新しいアクセスキーを作成すると、Data Tank 2.0にアクセスするためのランダムなユーザー名とパスワードが生成されます。アクセスキーを作成する際は、論理名が一意であり、Data Tank 2.0のユーザー名でないことを確認してください。

このページで生成されたユーザー名とパスワードは、作成時にのみ表示され、その後はアクセスできません。

アクセスキーを無効化することで、Data Tank 2.0への接続権限を取り消すことができます。アクセスキー自体は削除されません。アクセスキーを再度有効化すると、権限が復元されます。

## アクセスポリシーの管理

アクセスポリシーページでは、アクセスキーを使用して特定のスキーマへのアクセス権限を付与できます。

Data Tank 2.0アクセスポリシーページ
新しいアクセスキーが作成された後、デフォルトでユーザーはシステムカタログへのアクセス権限を持ちます。ユーザーごとに以下の種類のアクセスポリシーを設定できます。

| アクセスポリシータイプ | 概要 |
|  --- | --- |
| `READ_ONLY` | スキーマ内のテーブルおよびシーケンスへの読み取り専用アクセスを許可します。スキーマ内の関数の実行を許可します。 |
| `READ_WRITE` | スキーマ内のテーブルおよびシーケンスへの読み取りおよび書き込みアクセスを許可します。スキーマ内の関数の実行を許可します。 |
| `CUSTOMIZABLE_ADMIN` | スキーマ内のテーブルおよびシーケンスへの読み取りおよび書き込みアクセスを許可します。スキーマ内の関数の実行を許可します。DDLステートメントの実行を許可します。 |


`CUSTOMIZABLE_USER`ポリシーがアクセスキーに適用されると、ユーザーはそのアクセスキーに対してテーブルごとにアクセス制御を表示および変更できます。アクセスキーとテーブルを組み合わせて適用できるアクセスタイプは以下のとおりです：

| テーブルアクセス制御タイプ | 概要 |
|  --- | --- |
| `READ_ONLY` | テーブルおよびその配列への読み取り専用アクセスを許可します。 |
| `READ_WRITE` | テーブルおよびその配列への読み取りおよび書き込みアクセスを許可します。 |


### DDLステートメントの実行

このセクションでは、`CREATE`、`ALTER`、`DROP`、`GRANT`、`REVOKE`などのDDLステートメントを実行する手順について説明します。

1. 新しいアクセスキーを作成します。
2. 新しいアクセスキーに対して`CUSTOMIZABLE_ADMIN`タイプのアクセスポリシーを作成します。
3. 新しいアクセスキーを使用してPostgreSQLクライアントでData Tank 2.0に接続します。
4. 以下のステートメントを実行します：

```sql
SET ROLE _owner_<database name>_<schema name>
```
5. 必要なDDLステートメントを実行します。


DDLステートメントは、セッション内で`SET ROLE`が実行された場合にのみ実行できます。

切り替えるロール名`_owner_<database name>_<schema name>`は、データベース名とスキーマ名に基づいて決定されます。例えば、データベース名が`aciddb`でスキーマ名が`public`の場合、オーナーロール名は`_owner_aciddb_public`となります。

`SET ROLE`ステートメントが実行されると、アクセスキーはオーナーユーザーの権限を一時的に継承できます。この継承はセッションが終了するまで続きます。アクセスキーが`SET ROLE`を実行できるのは、`CUSTOMIZABLE_ADMIN`アクセスポリシーが設定されている場合のみです。

## 優先メンテナンスウィンドウの管理

Management UIでメンテナンスウィンドウを設定できます。

Management UIでのメンテナンスウィンドウの設定
Management UIでメンテナンスウィンドウを設定するには、以下のフィールドを使用します：

- **Namespace:** `instance`
- **Key:** `preferredMaintenanceWindow`
- **Value:**
  - フォーマット: `^(Mon|Tue|Wed|Thu|Fri|Sat|Sun):([01][0-9]|2[0-3]):[0-5][0-9]-(Mon|Tue|Wed|Thu|Fri|Sat|Sun):([01][0-9]|2[0-3]):[0-5][0-9]$`
  - 例：
    - `Sun:10:00-Sun:12:00` -- 日曜日の10:00から12:00の間（GMT）
    - `Mon:23:00-Tue:01:00` -- 月曜日の23:00から火曜日の01:00の間（GMT）
- **Secret:** チェックなし


- タイムゾーンは常にGMT+00:00です。
- メンテナンスウィンドウは1時間以上である必要があります。


## 変更の管理

変更ページでは、DBインスタンスとそのパラメータおよびIPホワイトリストを表示および管理できます。

### IPホワイトリストの設定

IPホワイトリスト機能を使用すると、特定のIPアドレスのみにData Tank 2.0へのアクセスを許可できます。

1. 設定ページで**Changes**を選択し、**allowedAddress**キーを選択します。

2. **Value**フィールドにCIDR形式で許可するIPアドレスを入力します。各フィールドの値は以下のとおりです：
  - **Namespace:** `instance`
  - **Key:** `allowedAddress`
  - **Value:**
    - `g:treasuredata-main` -- このエントリには、Management UIおよびPostgreSQLとのIntegrationに使用するTreasure DataサーバーのIPアドレスが含まれています。削除しないよう注意してください。
    - IPアドレス（各IPアドレスを別々の行に入力）
  - **Secret:** オフ

3. **SAVE**を選択します。この時点では設定はまだ適用されていません。
4. **Change to be applied**を確認し、**DEPLOY**を選択します。



変更の適用には、処理ステータスが`APPLYING`から`SUCCESS`に変わるまで通常数分かかります。

## SSLおよびTLS認証局の管理

Data Tank 2.0への接続はSSL/TLSで暗号化されています。Treasure Dataは暗号化に関して4つのオプションをサポートしています。

| 認証局（CA） | 説明 |
|  --- | --- |
| `rds-ca-2019` [非推奨] 2024年8月に有効期限切れ。 | RSA 2048プライベートキーアルゴリズムとSHA256署名アルゴリズムを使用する認証局を使用します。このCAは2024年に有効期限が切れ、サーバー証明書の自動ローテーションをサポートしていません。このCAを使用していて同じ標準を維持したい場合は、`rds-ca-rsa2048-g1` CAに切り替えてください。 |
| `rds-ca-rsa2048-g1` | ほとんどのAWSリージョンでRSA 2048プライベートキーアルゴリズムとSHA256署名アルゴリズムを使用する認証局を使用します。AWS GovCloud（US）リージョンでは、このCAはRSA 2048とSHA384を使用します。このCAは`rds-ca-2019`よりも長期間有効で、サーバー証明書の自動ローテーションをサポートしています。 |
| `rds-ca-rsa4096-g1` | RSA 4096プライベートキーアルゴリズムとSHA384署名アルゴリズムを使用する認証局を使用します。このCAはサーバー証明書の自動ローテーションをサポートしています。 |
| `rds-ca-ecc384-g1` | ECC 384プライベートキーアルゴリズムとSHA384署名アルゴリズムを使用する認証局を使用します。このCAはサーバー証明書の自動ローテーションをサポートしています。 |


### 認証局の更新

AWSクラスターのCAを更新するには、クライアント側で証明書バンドルを設定し、Management UIで認証局を切り替える必要があります。

#### クライアント側での証明書バンドルの設定

1. 以下の表でAWSリージョンを確認します。
| Treasure Dataのリージョン | AWSリージョン |
|  --- | --- |
| US | US East (N. Virginia) |
| Tokyo | Asia Pacific (Tokyo) |
| EU01 | Europe (Frankfurt) |
| AP02 | Asia Pacific (Seoul) |
2. Data Tank 2.0に必要な[AWSリージョン用の証明書バンドル](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL.html#UsingWithRDS.SSL.RegionCertificates)を確認します。Data Tank 2.0はAurora PostgreSQLをベースにしています。
3. 証明書バンドル（PEM）をダウンロードします。


このバンドルには、`rds-ca-2019`、`rds-ca-rsa2048-g1`、`rds-ca-rsa4096-g1`、`rds-ca-ecc384-g1`のすべてのCA証明書が含まれています。このバンドルを使用してクライアント側に設定すると、次回認証局を切り替える際に更新は不要です。

#### 管理UIで認証局を切り替える

認証局の切り替えは、通常クラスターに数分間のダウンタイムを引き起こします。この間、クラスターへの接続が失われます。

1. 以下の画像のように、`certificateAuthority`という名前の変更ドラフトを作成します。
2. そのクラスターでデプロイジョブを実行します。


管理UIで認証局の変更ドラフトを作成する