f:id:kouichiro-shibao:20211104175618p:plain

概要

ミラティブではデータ分析用ツールとしてRedashのSaaS(redash.io)を使用している。(Lookerと併用)
2021年11月末で redash.io のサービスが終了する。そのため、自前のGCP環境にRedashを移行した。
Redash謹製の移行ツールが提供されているが、いくつかハマったポイントがあった。
本記事では、GCP環境への移行手順・移行時のハマリポイント・移行後にあると便利なものを紹介する。

はじめに

初めまして、ミラティブでデータ分析基盤を担当している芝尾です。データ分析チームは5名のチームになっており、日々ユーザーの皆様のデータを分析してサービスの向上に努めています。今回はミラティブで使用していたデータ分析可視化ツールの移行を行いましたのでそのやり方を共有します。

背景

Redash hosted サービスが終了します。この記事によると 2021/11/30 で終わってしまうようです。そのため自前で用意したサーバにRedashを移行する必要があります。移行は、1, 自前のRedash サーバを用意し、2, redash.io 側からクエリーやチャート、ダッシュボードをコピーすることで行います。

移行方法

移行方法として、まず、自前でRedash V10を用意します（移行ツールはV10しかサポートしていないようです）。
用意したRedash V10に migration tool を使ってhostedサーバからデータを移行します。
独自ドメインを用意したり、oktaでの認証を有効にする(各社やり方が違うので今回は言及しません)。
移行のための便利ツールを用意する。

自前で、Redash V10を用意

まず、自前でRedash V10サーバを用意します。ミラティブの分析チームでは、 GCPを主に利用しているためそちらのやり方を記述します。

GCPでホストしたサーバへ移行する

最新のV10は公式からCompute Engineの公開イメージが提供されていないためで、redash V8からアップデートして、V10を利用します。

Redash V8の作成

V8はこちらのGCPの項目のやり方を参照しました。

$gcloud compute images create "redash-8-0-0" --source-uri gs://redash-images/redash.8.0.0-b32245-1.tar.gz

Compute Engine のイメージの項目に先程作った、redash-8-0-0 ができるので、右端の操作からインスタンスを作成でインスタンスの作成を行います。

f:id:kouichiro-shibao:20211102195829p:plain — redash-8-0-0

初回起動時は自動で、apt update && apt upgrade が走るので、それが終わるまで待ちます。だいたい30分くらいです。。apt upgrade の進捗は、 /var/log/apt/history.log をtailすればわかります。上記インスタンスを立ち上げると、redash-V8 が自動で立ち上がるのでV10に上げるために、一旦 /opt/redash/ で docker-compose down をして、Redashを停止します。

V10へアップデート

redashのV10へのアップデートはこちらのページを参照.

/opt/redash/docker-compose.yml を次のように書き換えた。

image: redash/redash:8.0 の項目を image: redash/redash:10.0.0.b50363 へと書き換え。services/scheduler/environment で、QUEUES と WORKERS_COUNT を削除。 docker-compose.yml の最下部へ

  worker:
    <<: *redash-service
    command: worker
    environment:
      QUEUES: "periodic emails default"
      WORKERS_COUNT: 1

を追加しました。

docker-comopose.ymlは次のようになりました。

version: "2"
x-redash-service: &redash-service
  image: redash/redash:10.0.0.b50363
  depends_on:
    - postgres
    - redis
  env_file: /opt/redash/env
  restart: always
services:
  server:
    <<: *redash-service
    command: server
    ports:
      - "5000:5000"
    environment:
      REDASH_WEB_WORKERS: 4
  scheduler:
    <<: *redash-service
    command: scheduler
  scheduled_worker:
    <<: *redash-service
    command: worker
    environment:
      QUEUES: "scheduled_queries,schemas"
      WORKERS_COUNT: 1
  adhoc_worker:
    <<: *redash-service
    command: worker
    environment:
      QUEUES: "queries"
      WORKERS_COUNT: 2
  redis:
    image: redis:5.0-alpine
    restart: always
  postgres:
    image: postgres:9.6-alpine
    env_file: /opt/redash/env
    volumes:
      - /opt/redash/postgres-data:/var/lib/postgresql/data
    restart: always
  nginx:
    image: redash/nginx:latest
    ports:
      - "80:80"
    depends_on:
      - server
    links:
      - server:redash
    restart: always
  worker:
    <<: *redash-service
    command: worker
    environment:
      QUEUES: "periodic emails default"
      WORKERS_COUNT: 1

Redash V10へDBのマイグレーションをする。

V10は、V8のスキーマ構造が新しくなるので、V10向けに、スキーマ構造のアップデートを行います。 $sudo docker-compose up --force-recreate --build で起動して、 V10へアップデートし、完了後停止します。 $sudo docker-compose run --rm server manage db upgrade を実行してマイグレーション（スキーマ構造の変更）をします。

下記のような画面が出ればOK。

f:id:kouichiro-shibao:20211102200558p:plain — Redash V10起動画面

注意: sudo docker-compose run --rm server manage db upgradeを一回実行しただけだとうまく動かなかったため、sudo docker-compose run --rm server manage db upgrade を再度実行したらうまく行きました。下記のような画面が出れば、 V10へのアップデートとマイグレーションは完了しています。

f:id:kouichiro-shibao:20211102200854p:plain — redash V10 初期画面

上記で、Redash V10の導入は終了です。これから、 redash.ioからqueryの移行を行っていきます。

redash-migration toolの導入

これから、redash-migration-toolsを使って、redash.ioにあるqueryから先程立てたRedash V10にデータを移行してきます。

migration-toolsの説明はこちらにあります。

redash-toolbeltのインストール

$pip3 install -U redash-toolbelt

でインストールできます。

$redash-migrate --help

でエラーが出なければ正常にインストールされています。

metaファイルの作成

基本的に、こちらのmigration-toolのドキュメントとおりに進めます。

最初に

$redash-migrate init

で初期設定を行います。

redash.io側と先程立てたRedash V10側で profileのstatus欄にあるAPI Keyを取得しておいてください。 user_idも聞かれますが、user_idはuser_nameではなく、自分のページにアクセスした際の user_idになります（最初 nameだと思っていて、はまりました）。

f:id:kouichiro-shibao:20211102201901p:plain — user_id

$redash-migrate init を実行するのログは以下のようになります。

(redash-toolbelt-env) shibacow@mr-redash:~/pkg$ redash-migrate init
（中略)
First, please enter information about connecting to your origin instance:
Please enter the origin URL. Example: https://app.redash.io/acme: https://app.redash.io/<組織ID>
Please enter an admin API key for the origin instance: F6wFexxxxxxxxxxxxxxxxxxxxxxxx
Please enter the user id for this admin on the origin instance: 308875

Next, we'll enter the same information for the new
Please enter the destination URL. Example: http://localhost: http://localhost
Please enter an admin API key for the destination instance: KZqIwAmsxxxxxxxxxxxxxxxxxxxx
Please enter the user id for this admin on the destination instance: 1
Please enter the email address for the destination admin user: xxxxxx@example.com
Ready to proceed.

また meta.json の内容は次のようになります。

{
    "users": {
        "308875": {
            "id": "1",
            "email": "xxxxxx@example.com"
        }
    },
    "queries": {},
    "visualizations": {},
    "dashboards": {},
    "alerts": {},
    "flags": {
        "viz_import_complete": {}
    },
    "data_sources": {},
    "groups": {},
    "destinations": {},
    "settings": {
        "origin_url": "https://app.redash.io/<組織ID>",
        "origin_admin_api_key": "F6wFeaxxxxxxxxxxxxxxxxxxxxx",
        "destination_url": "http://localhost",
        "destination_admin_api_key": "KZqIwxxxxxxxxxxxxxxxxxxxxx",
        "preserve_invite_links": true
    }
}

後は、helpの 順番通り にで実行します。依存関係がありますので注意してください。私は次の順番で実行しました。

data_sources 
check_data_sources
users
groups
queries
visualizations
dashboards
destinations
alerts
favorites
disable_users

disable_usersをすると、その後 migrateに失敗するqueries が出てくる（そのクエリーを作ったユーザーが既に有効でないため)。そのため、 disable_usersは行わないか、安定した後実行しても良いかもしれません。

ハマった点

Redash移行中にハマった点をいくつか共有します。

usersの登録時に、"could not create user: probably this user already exists but is not present in meta.json”とでる。

こちらのissue と同じ状況になりました。

Redashにはリミットコントロールがあり、一日50人までしか登録出来ないようです。user情報はその後queries等に使うため、userが登録できないとそれ以降の処理がうまく行えません。

/opt/redah/env に以下の環境変数を指定すれば、その制限は無効化されるため無制限にuserが入ります。　

REDASH_RATELIMIT_ENABLED=false

無制限に入るため、移行後の実運用では有効化したほうが良さそうです。

disable_usersを先に実行したためqueriesの登録がうまく行かない。

redash-migrate disable_users を先に実行したため、そのuserが存在しないことになり、queriesやvisualizationsがうまく登録できない

disable_usersは最後に実行するかもしくは安定稼働後に実行でも良いかもしれません。

登録日が移行日になる。

redashのqueriresの作成日が、移行した日になります。ミラティブ社では、クエリーの作成日で大体の時期を覚えている人も多かったため、日付を変更しました。redash.io側で、apiを利用して、クエリーの作成日を取得します。meta.json で元クエリーのIDと移行先クエリーのIDがわかるので、その情報を元に作成日をアップデートするSQLを作りました。

queriesの情報は、dbの postgres の queries に入っています。こちらの、 created_at と updated_at をアップデートしました。非公式な方法ですが一応動いています。