はじめに
こんにちは、ポーラ・オルビスホールディングスでデータエンジニアをしているyu_shinoと申します。
弊社ではETLツールとしてTROCCOを利用しているのですが、これまで本番へのデプロイフローに少しモヤモヤを抱えていました。
そんな中で、TROCCOに新しく追加された環境管理機能を試す機会があったので紹介したいと思います。
「TROCCOの環境管理機能、気になっているけど触れていない」という方の参考になれば幸いです。
弊社でのTROCCO運用
利用状況
弊社では主にTROCCOのデータ転送機能を利用しており、本番用と開発用を合わせて200個以上の転送ジョブが存在します。
このうち、本番環境で常時稼働しているジョブは70個程度あり、ほとんどはInputをRedshift、OutputをS3としたデータ抽出ジョブです。
ジョブ開発フロー
ジョブ開発は、基本的に次のような流れで進めています。
- 開発用ジョブを作成・編集する
- 開発用ジョブで各種テストを行う
- テスト結果を確認し、ジョブのレビューを実施する
- 本番用ジョブを作成・編集し、リリースする
このように、開発用と本番用で別々のジョブを持つ運用 になっています。
リリース運用の課題
弊社におけるTROCCO利用の一番の課題は、本番用ジョブのリリース方法にあります。
前述の通り、開発用ジョブでテストとレビューを行ったあとに、本番用ジョブを作成・編集してリリースしていますが、このリリース作業はすべて手作業です。
具体的には、次のような運用になっています。
-
新規ジョブの場合
- 開発用ジョブを複製する
- S3バケット名など、一部のパラメータを本番用の値に置き換える
-
既存ジョブを変更する場合
- 開発用ジョブで変更内容を反映・テストする
- 変更箇所を開発用ジョブから本番用ジョブへ、一つずつコピペして反映する
最初はこの運用でも問題ありませんでしたが、ジョブ数が増えるにつれて次のような課題が顕著になってきました。
- 開発環境と本番環境の差分が分かりにくく、リリース時のチェックコストが高くなる
- リリース時にパラメータの変え忘れやコピペミスが発生するリスクがある
環境管理機能を使ってみた
そんな中で、TROCCOに 環境管理機能 がリリースされました。
この機能では、TROCCO上の各種リソースを複数の環境ごとに分けて管理でき、環境ごとの差分を意識しながら段階的にリリースしていくことができるようです。
弊社が抱えている課題解決に繋がりそうだと感じ、実際に試してみました。
環境準備
まず、TROCCOの環境グループを作成しました。
作成は環境管理画面から簡単に行えます。
今回利用するのは以下の2環境としました。
- dev
- 開発用の環境
- prd
- 本番用の環境
- devで検証済みのジョブをリリースする想定
dev環境へのジョブ作成
環境の準備ができたので、まずはdev環境用のジョブを作成します。
今回は例としてRedshift to S3のジョブを作成しました。
ジョブ作成時の注意点としては、デプロイする際に環境ごとに変更できる項目が以下の3つに限られているという点です。
- 接続情報
- 文字列型のカスタム変数の固定の文字列
- リソースグループ
そのため、S3のバケット名やRedshiftのデータベース名といった環境ごとに変更したい値をジョブ内にベタ書きしてしまうと、デプロイ後に手動で書き換えることになってしまいます。
そのため、環境ごとに変更したい部分については文字列型のカスタム変数を利用することにしました。
転送元であるRedshiftの設定はデータベースとスキーマ名をカスタム変数化し、クエリ内にも埋め込んでいます。
転送先のS3についてもバケット名とパスプレフィックスをカスタム変数化しました。
完成したジョブを環境に紐づけて準備完了です。
prd環境へのジョブ作成
先ほど作成したdev環境用のジョブをprd環境にデプロイします。
デプロイ時には、以下の項目について環境ごとに上書きすることができます。
- 接続情報
- カスタム変数
- リソースグループ
今回は、S3 のパスプレフィックス を prd 向けの値に変更しました。
元の設定から変更が入った箇所は画面上で「差分あり」と表示されるため、どこを変えたか一目で分かる のが便利です！
prd環境用に接続情報やリソースグループを設定し、ジョブの作成が完了しました。
デプロイ後にprd環境のジョブを確認すると、S3のパスプレフィックスはprd用にきちんと切り替わっていました！
それ以外のSQLや各種パラメータはdev環境からそのまま引き継がれています。
dev環境からprd環境への変更作業
dev環境、prd環境にそれぞれジョブを作成できたので、次は 「dev環境でジョブを変更→prd環境に反映」という、実際の運用に近いフローを試してみます。
まずはdev環境のジョブに対して既存のSQLに簡単な変更を加えました。
変更前
変更後
ジョブを保存し、変更をprd環境に反映します。
新規作成時にprd 環境用のカスタム変数（S3 パスプレフィックスなど）はすでに設定済みのため、今回はSQL の変更だけをデプロイします。
デプロイ後に prd環境のジョブを確認すると、dev 環境で変更した SQL がそのまま反映されていることが確認できました。
これまではdev環境で修正したSQLをコピペで本番ジョブに転記していたので、ワンボタンで反映できるようになったのは大きなメリットだと思いました！
注意点
実際に使ってみて、運用面で注意が必要だと感じた点もあります。
- TROCCO側ではデプロイフローを強制できない
- 環境の序列（例：prd > stg > dev）のような概念を持つことができないため、最初からジョブを prd 環境に紐づけることもできてしまう
そのため、「dev でジョブを作成する」、「環境設定から prd 環境にデプロイする」といった、望ましいデプロイフローをチーム内ルールとして明文化しておく必要があると感じました。
所感
TROCCOの環境管理機能を実際に使ってみて、これまでデプロイ時に感じていた不安をかなり解消できそうだと感じました。
特に良かった点としては以下です。
- デプロイ時に変更点を手動で反映しなくて済む
- 開発用ジョブと本番用ジョブの差分が分かりやすい
一方で、各パラメータをあらかじめ変数化する必要があるため、弊社で利用している既存ジョブをすべて変更するのはある程度の工数がかかりそうだとも感じました。
まずは新規ジョブでの利用などから段階的に取り入れて、ルールの整備もしていきたいと考えています。