Self Hosted版 Redashの構築

November 30, 2021

　MoTでは、クラウドサービス上にあるマネージドデータベースや、BigQueryに流しているサービスログの参照ツールとして、ダッシュボードツール「Redash」を活用しています。

　以前は、Web版のRedashを利用していましたが、2021年11月末にWeb版のサービス提供が終了することが告知されたため、弊社が管理しているAmazon EKS上インフラ基盤Kenos(ケノス)上に、新たにSelf Hosted版 Redashを構築し運用する事となりました。急遽の対応だったにも関わらず、短期間で準備し検証、構築までできたうえ、現状大きなトラブルなく安定稼働しています。

　この記事では、現在MoTで利用しているSelf Hosted版Redashの構築内容についてご紹介いたします。

はじめに

　SREグループ・ヒロチカです。MoTでは、サービスのクラウドインフラの設計から構築・運用までを担当しています。

　弊社では、Redashの2021年11月末のWeb版サービス終了に伴い、急遽Self Hosted版Redashを構築しリプレイスを行ったのですが、そちらの構築時の内容を中心に、ご紹介できればと思います。

Redash https://redash.io/
インフラ基盤Kenos(ケノス)について https://lab.mo-t.com/blog/andonlabo-7-sre-k8s ※2020/4/1の事業統合後、サービス名がKenosに変わっていますが、設計思想等は記事の通りです。
公式のRedashセットアップ手順 https://redash.io/help/open-source/setup

ローカル環境での起動

　EKS上で起動するために、まずローカルPC上のdockerで起動できることを確認します。

　Redashサービス立ち上げるために必要な、PostgreSQL、Redisは、デフォルトに準じてローカルで起動します。

Redash公式より、git clone

git clone https://github.com/getredash/redash.git

今回は、公式のdocker imageを利用し、docker-composeでの起動を目指すため、対象のyamlファイル群のディレクトリまで移動

cd redash/setup/data

ローカルの環境に合わせて、docker-compose.yaml、環境変数ファイルを修正
docker-compose.yaml

version: "2"
x-redash-service: &redash-service
  image: redash/redash:8.0.0.b32245　　　# 利用する docker image
  depends_on:
    - postgres
    - redis
  env_file: .env   # 環境変数のファイルを指定(場所は任意)
  restart: always
services:
  server:
    <<: *redash-service
    command: server
    ports:
      - "5000:5000"   # ローカル上で起動するためのportも任意
    environment:
      REDASH_WEB_WORKERS: 4
  scheduler:
    <<: *redash-service
    command: scheduler
    environment:
      QUEUES: "celery"
      WORKERS_COUNT: 1
  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: .env   # 任意の環境変数のファイルを指定
    volumes:
      - pg-data:/var/lib/postgresql/data　　# ローカルpostgresのvolumesの場所を指定
    restart: always
  nginx:
    image: redash/nginx:latest
    ports:
      - "80:80"
    depends_on:
      - server
    links:
      - server:redash
    restart: always
volumes:             # ローカルpostgresのvolumesの場所を指定するため追加
  pg-data:           
    external: true

.env

REDASH_HOST=http://localhost
PYTHONUNBUFFERED=0
REDASH_LOG_LEVEL=INFO
REDASH_REDIS_URL=redis://redis:6379/0
REDASH_DATABASE_URL=postgresql://postgres@postgres/postgres
POSTGRES_PASSWORD=
POSTGRES_HOST_AUTH_METHOD=trust
REDASH_COOKIE_SECRET=redash-hands-on
REDASH_SECRET_KEY=redash-hands-on

公式の手順通り、db migration後、docker-compose startで、Redashサービスが立ち上がる

$ pwd
/path/to/redash/setup/data

$ docker-compose run --rm server create_db
Creating data_server_run ... done

$ docker-compose start
Starting redis            ... done
Starting postgres         ... done
Starting adhoc_worker     ... done
Starting scheduled_worker ... done
Starting scheduler        ... done
Starting server           ... done
Starting nginx            ... done

$ netstat -na | grep 5000
tcp46      0      0  *.5000                 *.*                    LISTEN

正しく起動できていればhttp://localhost:5000 で初回のアクセスができるようになります。

EKS環境での起動

　ローカルでの確認内容をもとに、弊社で管理しているAmazon EKS環境に構築していきます。docker imageを利用して起動するため、EKSクラスター上での環境変数の調整のみで対応できます(環境によっては、起動コマンドの修正等も必要)。

　また、ローカルPC上では、DBやRedisもローカルでしたが、実際に運用している環境では、Amazon Aurora PostgreSQLとElasticache for Redisを利用しています(こちらの構築については、一般的な構築と変わらないため、本記事では省略しています)。加えて、Redashからのメール送信については、弊社で利用してるSendGridをAPI経由で利用しています。

構成図

設定内容

環境変数
- 設定できる環境変数の内容は、公式を参照

# サービスアクセス用のドメイン(DNS登録必須)
REDASH_HOST: "https://example.xyz" 
PYTHONUNBUFFERED: "0"
REDASH_LOG_LEVEL: "INFO"
# Redis設定
REDASH_REDIS_URL: "rediss://USER:PASSWORD@master.XXX.xxx.regeon.cache.amazonaws.com:6379/0"　　# secureな通信にするためrediss
# RDS設定
REDASH_DATABASE_URL: "postgresql://USER:PASSWORD@XXX.cluster-xxx.regeon.rds.amazonaws.com/DB_NAME"
POSTGRES_PASSWORD: "PASSWORD"
POSTGRES_HOST_AUTH_METHOD: "trust"
# too many requestへの対応(1分間に1000リクエストまでの制限)
REDASH_THROTTLE_LOGIN_PATTERN: "1000/minute"
# SendGrid設定
REDASH_MAIL_SERVER: "smtp.sendgrid.net"
REDASH_MAIL_PORT: "0000"
REDASH_MAIL_USE_TLS: "true"
REDASH_MAIL_USERNAME: "apikey"
REDASH_MAIL_PASSWORD: "API_KEY"
REDASH_MAIL_DEFAULT_SENDER: "mail@mail.com"　# 任意のメールアドレス

server 起動コマンド設定。worker,scheduler等もdocker-compose.yamlと同様に

〜略〜
containers:
  app:
    image:
      repository: redash/redash
      tag: 8.0.0.b32245
    command: ["/bin/sh", "-c", "/app/bin/docker-entrypoint server"]

Redash用DBのdb migrationは、デプロイ時に毎回migrationのshellを実行するpodを起動
- MoTが管理するインフラ基盤Kenosでは、デプロイ時のmigration実行にHelmフックを利用
- 参考: インフラ基盤Kenos(ケノス)について > Helm

〜略〜
containers:
  app:
    image:
      repository: redash/redash
      tag: 8.0.0.b32245
    command: ["/bin/sh", "-c", "/app/bin/docker-entrypoint create_db"]

Self Hosted版 Redash の運用

Self Hosted版 Redashを運用する際、注意しているポイントなど

Redashのセキュリティリスク対策

　データソースに登録したデータベース等へのアクセスをお手軽にするというRedashの特性上、セキュリティ面MoTではRedash自体へのログイン方法の制限、ログイン後のユーザのデータソース参照可能領域を細かく絞り、セキュリティリスクを低減する対策を行っています。

Redashへのアクセス制限

　Redashへのアクセスを社内VPN・社内IPからのみに絞るため、サーバの前段にあるingressにてIPアクセス制限を行っています。

　また、ログインについては完全SSO化し、SAML認証のみを許可するようにしています。

データソース・ユーザ作成

　弊社では、Redash環境からは参照のみで、データベース更新は行わないルールとしているため、データソースに登録しているデータベース等には、readonly権限のユーザ且つ、クラスタを組んでいる場合には、スタンバイ側に接続するような形で、データソースの登録を行っています。

　また、データソース別にグループを分け、ユーザをグループに所属させることで、各ユーザに対して余剰なアクセス権限を与えずに、権限管理ができるようにしています。

　加えて、データソース・ユーザ権限にセキュリティリスクとなる間違った設定がされていないか、バッチジョブによる定期チェックも行っています(具体的には、ダッシュボードの設定で権限の範囲外を超えたデータの共有がされていないか、データソース作成時に不用意に設定されてしまうデフォルト権限の修正、等)

環境別に構築

　弊社のEKSクラスターは、本番・開発と環境別にそれぞれ分かれているため、Redashも、本番環境・開発環境、それぞれ別々に準備し、利用しています。

おわりに

　MoTで利用している、Self Hosted版 Redash 構築についてご紹介いたしました。

　Redash公式のdocker imageを利用して構築しているため、今後アップデートが必要となった場合でも、比較的簡単に対応できる部分は、運用面でもメリットだと思います。

　また今後、複数環境でRedashを構築し運用している場合のオペミスを防ぐためにも、画面上デザインや色を変える等の変更が手軽にできるようになる、ユーザ招待・作成時にデフォルトでのグループ設定ができるようになる、などのアップデートにも期待しています。

We're Hiring!

📢

Mobility Technologies ではともに働くエンジニアを募集しています。

興味のある方は採用ページも見ていただけると嬉しいです。

Twitter @mot_techtalk のフォローもよろしくお願いします！