自前でRedashを構築してSaaSからデータ移行をする

こんにちは、ばんがです。
Redash SaaSのサービス終了に伴って、業務でRedashの自前での構築・SaaSからのデータ移行を実施したのでざっくりまとめようと思います。

Hosted Redashの終了について。
https://redash.io/help/faq/eol

Self-Hosted Redashの構築

RedashはOSSでコードが公開されているので自前で構築することができます。
公式から全部入りのAMIが提供されていますので今回はこちらを利用。
Redash自体はもちろん、DB(postgresql, redis)、nginxなどが入っておりこのAMIを使ってEC2を立ち上げればRedash環境が出来上がります。
https://redash.io/help/open-source/setup

とはいえVPCなどネットワーク周りやSSL化するためにロードバランサーなどを作る必要があるので、Terraformを使って必要なリソースを構築しました。

まずは、公式が提供するAMI(ap-northeast-1)を使ってEC2インスタンスを定義。
インスタンスタイプは、最低限smallが必要らしいのでt3.smallにしました。

resource "aws_instance" "redash" {
	  ami           = "ami-060741a96307668be"
	  instance_type = "t3.small"
	  subnet_id     = aws_subnet.redash_public_a.id
	  ebs_optimized = true
	  vpc_security_group_ids = [
	    aws_security_group.redash.id
	  ]
	  monitoring = false
	  key_name   = "redash"
	

	  root_block_device {
	    delete_on_termination = false
	    volume_size           = 8
	  }
	

	  tags = {
	    Name = "redash"
	  }
	

	  depends_on = [
	    aws_subnet.redash_public_a,
	    aws_security_group.redash
	  ]
	}

割愛しますが、VPCやサブネット、ロードバランサーなども定義しておきます。

IP制限をかけたいので、セキュリティグループも定義しましょう。
EC2用とロードバランサー用それぞれを定義します。

Redashで連携した外部データソースと通信するので、EC2用にもアウトバウンド(egress)許可を入れておく必要がありました。

# EC2用
resource "aws_security_group" "redash" {
  name        = "redash"
  description = "For Redash"
  vpc_id      = aws_vpc.redash.id

  ingress {
    from_port                = 80
    to_port                  = 80
    protocol                 = "tcp"
    security_groups = [aws_security_group.redash-lb.id]
  }

  lifecycle {
    ignore_changes = [ingress, egress]
  }
}

# ロードバランサー用
resource "aws_security_group" "redash-lb" {
  name        = "redash-load-balancer"
  description = "sg for redash application load balancer"
  vpc_id      = aws_vpc.redash.id

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Redash関連の全リソースの定義はこちらにあります。参考まで。
https://github.com/bangarrr/terraform-test/tree/master/redash

SaaSからデータを移行する

さて、自前でRedashが構築できたので、SaaS版のRedashからデータを移行します。
公式が提供しているデータ移行ツール(redash-toolbelt)があるのでこちらを利用します。
https://github.com/getredash/redash-toolbelt/tree/master/redash_toolbelt/docs/redash-migrate

まずはインストールします。
当時の最新版(v0.1.8)ではダッシュボードなど複数のデータの移行でエラーが発生したため、v0.1.6を利用しました。

pip install redash-toolbelt==0.1.6

移行作業は、移行元Redashと移行先Redashにアクセスできる環境であればローカル環境で実施できます。

まずは適当な作業ディレクトリで移行設定の初期化をしましょう。

@some workdir
redash-migrate init

コマンドを実行すると、移行元・移行先Redash双方のURLやadminユーザーのアクセスキー、ユーザーIDなどが聞かれるので入力します。(先ほど作成した移行先のRedashで、あらかじめ初期ユーザーを作っておく必要があります)

コマンドが完了するとmeta.jsonファイルが作成されます。
ここに先程の設定が記載されており、またこれから行う移行コマンドを実行していくと、移行したクエリやデータソースなどの情報が追記されていきます。

移行コマンドを実行していく

redash-toolbeltではデータを一括移行できるわけではなく、データソース、クエリ、ダッシュボード...など、それぞれを順番に移行してやる必要があります。
公式にも記載がありますが、redash-migrate --helpコマンドで移行コマンド一覧が表示されます。基本的に上から順番に実行していけばOKです。(逆に変な順番でやるとうまくいかないです)

移行後の作業

残念ながら上記移行コマンドだけでは完全に移行はできないので、移行先のRedashで追加で作業する必要があります。

データソースの認証情報の設定

データソースと連携するためのパスワード/シークレットキーなどの認証情報は移行されないので、新Redashで再度設定する必要があります。

既存ユーザーのパスワード

同じく、既存ユーザーのパスワードも移行されません。最初に作成したAdminユーザー以外の既存ユーザーは招待中の状態になるので、各自でパスワード再設定をしてからログインしてもらうことになります。

グループが重複する

v0.1.6では、デフォルトのユーザーグループ(defaultとadmin)が新旧の分で重複します。
新Redashの方にデフォルトでdefault、adminのグループが存在するのに、グループの移行コマンドによって旧Redashのdefaultとadminが移行されてくるので重複してしまいます。

片方は不要なので、旧のdefault、adminを消しましょう。
ただし、旧グループに入っていたユーザーは新グループの方に追加してください。

クエリのIDがリセットされる

これもv0.1.6の問題かもしれませんが、旧RedashでのクエリのID(DB上のIDだと思われます)は移行されず、新Redashでは新しく1から付与されます。
クエリ中に他クエリのIDを直書きしている場合などはクエリが動かなくなるので、新しいクエリIDで置き換える必要があります。

まとめ

追加の作業を行ってやっとデータ移行が完了しました。
細かいところで色々不具合はありますが、公式の移行ツールが提供されているのはありがたかったです。
現在はv0.1.9も出ているようなので、上記のような細かい問題も改善されているかもしれません。

それではまた。