GitHub Actions Self-Hosted Runnerで実現する、セキュアなDBマイグレーション

参考になった

レビュー投稿日の情報になります

ウェルスナビ株式会社 / ユータ

メンバー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名

最終更新日2025/10/06投稿日2025/10/06

利用プラン	利用機能	ツールの利用規模	ツールの利用開始時期	事業形態
GitHub Enterprise Cloud	GitHub Actions Host Runner	11名〜50名	2024年	B to C

利用プラン	GitHub Enterprise Cloud
利用機能	GitHub Actions Host Runner
ツールの利用規模	11名〜50名
ツールの利用開始時期	2024年
事業形態	B to C

アーキテクチャ

アーキテクチャの意図・工夫

アーキテクチャについて以下セキュリティと利便性のバランスを考慮したCI/CDパイプラインを実装しました。

GitHub Actionsワークフロー内にdry-runジョブを組み込み、スキーマ差分を自動で検出・可視化(安全確認を容易にするため)
本番環境へのmigratonジョブ実行はSREチームによる手動承認を必須化(開発/ステージング環境は自動実行可能)
VPC内に配置されたCodeBuild上でGitHub ActoinsのHosted Runnerを起動するようにし、インターネットへの通信時にNetwork Firewallによるアウトバウンド通信を制御(不審サイトへの接続や機密情報の外部送信を抑止するため)

より詳しい実装の詳細については以下の記事もご覧いただけますと幸いです。
https://zenn.dev/wn_engineering/articles/codebuild-on-gha-with-flyway

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

複数プロダクトを開発するようになると、手動でのDBマイグレーション作業に工数が増大していた
プロダクトごとにマイグレーションの方法が異なり、運用品質にばらつきが出ていた

以下の状態を満たせること

DBマイグレーション作業をCI/CDパイプライン上で実現し、運用を効率化
プロダクト間のDBマイグレーション方法を統一し、安定した運用を実現

比較検討したサービス

CodeBuild
CodePipeline

比較した軸

本番DBへの安全な接続が可能か
運用がしやすいか(GitHub上で実行結果やログを確認できる、学習コストが低いなど)
安全に運用できるか(手動承認の実装が可能かなど)

選定理由

CodeBuild上でGitHub Actionsワークフローを起動することで、本番DBへの安全な接続ができるようになった点
実行結果やログをGitHub上で確認でき、手動承認も組み込めるため、利便性と安全性を両立できる点

導入の成果

課題解決の状況

従来は踏み台サーバーに入り、手動でDBマイグレーションを実施
GitHub Actions上でFlywayを実行し、マイグレーション自動化や手順書作成の効率化が進み、運用負荷が低減

得られた成果

ステージング環境にも同様の仕組みを入れ、開発者だけでマイグレーションの実行を実現
本番前の動作が確認が容易になった
社内勉強会で取り組みを紹介することで他プロダクトへの横展開が進み、新規開発時の標準化が促進された

導入時の苦労・悩み

GitHub Actionsを実施するタイミングについて課題がありました。

当初はCIの段階でDBのReaderエンドポイントに接続し、Flywayのdry-run結果をもとにマージ可否を判断する設計を想定していました。

しかしPR時点で本番DBに接続できる仕組みにすると、誤って本番データを参照してしまうリスクがありました。

これを踏まえ、CI/CDパイプラインの設計を見直す必要がありました。

また、FlywayはOSSであることから、サプライチェーンリスクによって脆弱性が混入し、本番DBのデータが外部に送信されるリスクへの対応も検討する必要がありました。

導入に向けた社内への説明

上長・チームへの説明

SREチームでは新規設計やツール導入を実装する場合、ADR(Architectural Decision Records)を作成しリスクベースで提案するようにしています。

今回の提案ではFlywayをGitHub Actions上で実施するにあたり、既存の運用方法からの変更点や変更によって得られるメリット、逆に変更したことで生じる問題点を洗い出し、メリット・デメリットを整理して導入に向けた説明を行いました。

活用方法

DBスキーマの変更が必要になった場面で、開発者が管理するSQLリポジトリにPRを作成します。

そしてPRがマージされるとGitHub Actionsが起動し、Flywayによるマイグレーションが実行されます。

よく使う機能

GitHub Actions Self-Hosted Runner
- DBへセキュアな接続を実現するためにCodebuild上でGitHub Actionsが起動できるようになる機能には大変お世話になりました。
GitHub Environment
- 特定のEnvironmentに対して手動承認を実装できるため、dry-runジョブとmigrationジョブ間に手動承認フェーズを挟むことで実現したかったセキュアなCI/CDパイプラインを構築できました。

ツールの良い点

GitHub ActionsをCodeBuild上で動かすことでAWSのプライベートサブネットに配置されているDBにも安全に通信できる点が良いと考えています。

ツールの課題点

CodeBuild単体に比べて起動に少し時間がかかるところや、AWSとの連携する方法が複数あり、最初の実装がやや大変な部分が課題と考えています。

今後の展望

リリース作業では現在 SRE の立ち会いが必須ですが、事前承認があれば開発者だけでリリース作業を完結できるようにしたいと考えています。

ウェルスナビ株式会社 / ユータ

メンバー / SRE / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名

新卒でSESの会社で5年ほどNW運用保守業務に従事し、ヘルステック系ベンチャーにSREとして転職。クラウドインフラ構築運用を経験し、Webメディア企業で数十から数百程度のメディアサーバー運用構築を担当するSREに転職。 3年ほど経験し、現職に転職。現在は金融資産運用サービスのインフラ運用や新規プロダクトの環境構築、SRE業務、プラットフォームエンジニアリング業務を担当している。