Redshift Serverlessで「ワークロードの分離」は可能か？

# はじめに

### 目的

Snowflakeで言う「ワークロードごとに仮想ウェアハウスを分離し、リソース競合を防ぎ、コスト管理を分ける」といった使い方がRedshift Serverlessでも可能か確かめる

### 結果

技術的に可能だが、Snowflakeの方が明らか便利っぽい

# 背景

### 気になった点

Redshift Serverlessについて調べていたとき、Snowflakeに馴染みがある僕としては、Redshift Serverlessの[名前空間とワークグループ](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-workgroup-namespace.html)という概念にひっかかりました。

> Each namespace can have only one workgroup associated with it. Conversely, each workgroup can be associated with only one namespace.

→ ぼく「名前空間とワークグループが1:1？？？ ということは、各ユーザは名前空間内のテーブルにしかアクセスできないし、紐づけられたワークグループでしかコンピュートできない、ということ？？？」

もし、「各ユーザは名前空間内のテーブルにしかアクセスできないし、紐づけられたワークグループでしかコンピュートできない」が制約として真に実在する場合、以下の困りごとが発生します。

### 困りごと: ワークロードの分離の実現が難しい

会社共通のDWHなどを想定した際、複数部門, 組織, PJTが同じDWH基盤を利用することが想定されます。このとき、コンピュートリソースを分ける (以後、「ワークロードの分離」と呼びます) ことで、①リソース競合を防ぐ、②業務単位ごとに消費リソースを把握しコスト管理・賦課を行う、ことが一般的です。

Redshift Serverlessをサッと見て気になった点は、「各ユーザは名前空間内のテーブルにしかアクセスできないし、紐づけられたワークグループでしかコンピュートできない」という制約があると、部門やタスクごとのワークロードの分離の実現が難しいのでは、ということです。例えば、以下の設計は名前空間:ワークグループ=1:2となっているため、Redshift Serverlessでは実現不可能です。

Architecture1
![スクリーンショット 2024-03-27 15.41.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/656439/dfa30c88-a7cf-3ab6-d1de-215a21f837b0.png)

ワークグループを複数作成し、ワークグループごとにタグをつけたいのですが、名前空間:ワークグループ=1:1ルールが結構邪魔な気がします。

次の設計は実現可能ですが、UnitAのDBで作ったtableをUnitBが閲覧する、といったデータの連携は面倒そうです。

Architecture2
![スクリーンショット 2024-03-27 16.16.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/656439/0026c69e-5ea8-be17-789d-90b123fded34.png)


<br>


Snowflakeなら、部門やタスクごとに仮想ウェアハウスを割り当てることで、リソースを分割することが可能です。また、独立した仮想ウェアハウスの割当により、コストトラックも容易となります。単純に権限を割り当ててしまえばOKで、設計はこんな感じ。

![スクリーンショット 2024-03-27 15.57.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/656439/ce89991c-2f41-d375-9f35-eee271094cfb.png)


(ワークロードの分離は、Snowflakeを触っているなら必ず登場する話題ですよね)

![スクリーンショット 2024-03-27 15.18.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/656439/d6579903-a438-b7b5-d6cc-6935673408c9.png)

[SNOWFLAKE プラットフォーム](https://www.snowflake.com/ja/data-cloud/platform/?utm_cta=website-homepage-workload-button-explore-platform)


# 検証内容

以上を踏まえ、次の前提・要件がRedshift Serverlessでどう実現できそうかを模索してみます。


### 前提

```
* DataEngineering, UnitA, UnitB と、3つの部門が存在する
* DataEngineeringはデータ整備を担う開発組織とする
* UnitA, UnitBはデータ利用を行う業務組織とする
```

### 要件
必要な機能は以下
```
* 3つの部門でワークロードを分離する
    * 競合を防ぐ
    * コストを賦課する
```

### 想定イメージ

想定する利用形態をSnowflakeで作ったイメージは以下。

![スクリーンショット 2024-03-27 17.54.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/656439/fe233fd3-99be-a853-7e93-1becb6c34776.png)

* `DataEngineering`チームの`user1`は、緑枠を責任範囲とし、以下タスクを行う。
    * `SYS_DATA_DB`内のデータ整備
    * `SYS_DATA_DB`から`BIZ_DATA_DB`内の各業務組織ごとに作成されたスキーマに対するView作成
* `UnitA`, および`UnitB`チームの`user2, 3`は、赤枠を責任範囲とし、以下タスクを行う。
    * 各業務組織ごとに作成されたスキーマ内のTable/Viewの参照

(単なる調べ物なので、機能ロールとかアクセスロールは気にしないってことで。。。)

↑のようなものをRedshift Serverlessで作れるかな？をざっと見ていきます。

# 調査①

先ほど挙げた以下のような設計ができないことを確かめます。

Architecture1
![スクリーンショット 2024-03-27 15.41.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/656439/dfa30c88-a7cf-3ab6-d1de-215a21f837b0.png)


ワークグループの作成画面から、「既存の名前空間に追加」を試みると以下の通りで、名前空間:ワークグループ=1:2はやはり不可能でした。

![スクリーンショット 2024-03-27 17.55.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/656439/74d71352-e7f5-5625-e203-bc6c342eb553.png)


# 調査②

方針: ワークロードごとにワークグループを作成する

結論、この方法なら可能です。ただし、どう見てもめんどくさい。

今回の検証で言う、`DataEngineering`, `UnitA`, `UnitB`ごとにワークグループを作り、対応する名前空間を作れば、技術的には要件を満たせるはずです。また、`DataEngineering`チームによる各業務組織へのView作成は、データ共有を用いれば可能です。

https://dev.classmethod.jp/articles/amazon-redshift-serverless-data-sharing-sample/

実現イメージはこんな感じ。

![スクリーンショット 2024-03-27 18.50.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/656439/1240db7f-a30b-affb-2c41-57331aa56387.png)


### 困りごと

データ共有によって、データを参照可能にするためには、データコンシューマ (今回で言う`UnitA`や`UnitB`の人たち) 側でも設定が必要となります。

業務ユーザに対して「初期設定してくれや」はやはり極力避けるべきなので、ここは痛いポイントかなあと思います。

# まとめ

### 目的

Snowflakeで言う「ワークロードごとに仮想ウェアハウスを分離し、リソース競合を防ぎ、コスト管理を分ける」といった使い方がRedshift Serverlessでも可能か確かめる

### 結果

技術的に可能だが、Snowflakeの方が明らか便利

### 所感

AWSネイティブなRedshiftくん、個人的には推しているので、頑張れ...！

(誤りあればご指摘いただければ幸いです)