1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

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

Last updated at Posted at 2024-03-27

はじめに

目的

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

結果

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

背景

気になった点

Redshift Serverlessについて調べていたとき、Snowflakeに馴染みがある僕としては、Redshift Serverlessの名前空間とワークグループという概念にひっかかりました。

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

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

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

Architecture2
スクリーンショット 2024-03-27 16.16.42.png


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

スクリーンショット 2024-03-27 15.57.12.png

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

スクリーンショット 2024-03-27 15.18.06.png

SNOWFLAKE プラットフォーム

検証内容

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

前提

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

要件

必要な機能は以下

* 3つの部門でワークロードを分離する
    * 競合を防ぐ
    * コストを賦課する

想定イメージ

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

スクリーンショット 2024-03-27 17.54.44.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

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

スクリーンショット 2024-03-27 17.55.55.png

調査②

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

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

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

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

スクリーンショット 2024-03-27 18.50.00.png

困りごと

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

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

まとめ

目的

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

結果

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

所感

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

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

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?