非エンジニアがクエリを実行するための基盤を移行した話

これは Livesense Advent Calendar 2023 DAY 24 の記事です。

リブセンスインフラエンジニアのsheep_san_whiteです。お酒とロードバイクが大好きなおじさんです。

現在、リブセンスではオンプレミス環境からAWS環境への移行を進めています。移行が必要な対象は沢山ありますが、今回は非エンジニアがクエリを実行する基盤の移行について書きます。

以下のいくつかの理由によって非エンジニアがクエリを実行する基盤が作られました。

毎月、オペレーショナルエクセレンス(OPEX)の方たちが管理画面をポチポチ押して50件ほどのCSVファイルを出力していました。

50件ほどあるCSVファイルの出力条件も細かく変える必要があり、この作業を行うのに毎月4時間ほどかかっていました。

管理画面で出力できないクエリを本番DBで実行する際には以下のフローを行う必要があり、チケットの取り回しや本番DBにログインすることの手間がありました。

定期的に実行するクエリだと、何度も依頼をする必要があります。

個人情報を含むデータを扱うため、広く参照されることにリスクがありました。

一部のメンバーだけがクエリの結果を参照できる状態を維持する必要がありました。

下図の通り、Ansibleとrundeckを組み合わせてジョブを管理し、結果をGoogleドライブにアップロードしていました。

既存の基盤では以下の課題を抱えており、3回壊れた時点で別基盤への移行を決意しました。

また、AWS移行も進めているため、併せてAWSへの移行が必要となりました。

最初の半年は問題なく動いていたものの、ある日突然アクセス不可能・データが破損しアクセスできなくなりました。

ログを漁っても思い当たるログが見つからず、業務を止めないために取り急ぎ再構築を行いました。

rundeckのデフォルトのDBで H2 Database を使っていることも疑われましたが、別基盤では安定稼働しており、原因らしい原因がわからないという状況でした。

以降も半年ごとに何故か壊れてアクセスできなくなるということが発生してその度に再構築が必要となっていました。

Ansibleで管理されているとはいえ、オンプレミス環境のVMの構築からなので復旧に半日掛かっていました。

代替の構成を検討したところGitHub Actionsが検討先となりましたが、クエリの実行時間が30分近くと長いものもあり実行時間でコストが積み上がる懸念がありました。

また、本番DBにアクセスするにはファイアウォールの穴あけが必要となりますが、本番DBに対してCIDRで広く開けるよりは別な手法を取りたい思いがありました。

当時ちょうど社内でGitHub Actions Self-Hosted Runnerの活用事例が増えてきた頃だったので、GitHub Actions Self-Hosted Runnerに移行を決めました。

構成要素としてはAutoScalingでEC2インスタンスを起動し、cloud-initでGitHub Actions Self-Hosted Runnerをインストールするというものです。

ジョブの実行基盤をオンプレミス環境のrundeckからAWS上のGitHub Actions Self-Hosted Runnerへ移行したことで、以下の結果が得られました。

運用負荷を減らしてコスト面も考慮した移行になったと思います。

良かった点
- GitHub Actionsに移行したことによるメリット
  - 設定変更時にAnsibleを適用する必要が無くなった
  - ジョブがコケた際の再実行もGUIからre-runするだけ
- GitHub Actions Self-Hosted Runnerで実行することのメリット
  - 一部のクエリで実行に30分〜1時間近くかかるものがあり、単純にGitHub Actionsを使用するよりは低コストに実行できる
- AWSに移行したことによるメリット
  - GitHub Actions Self-Hosted Runnerのインスタンスが死んでもAutoScalingで自動復旧する
  - AutoScaling+スポットインスタンスの利用によりコスト圧縮が可能となる
悪かった点
- GitHub Actions Self-Hosted Runnerのバージョンアップ時に一部のPATHが変わってしまい死んでしまう
  - これは自動復旧するのでさした問題ではない