この記事のターゲット
- 個人管理されたアプリケーションを企業管理領域に移行したいPM・エンジニア
- 小規模チームで組織管理できるCI/CD基盤を構築したいエンジニア
はじめに
自社サービスと謳っているウェブアプリケーションが、なぜか個人アカウントのVercel + GitHub運用になっていたため、組織で契約しているAWS基盤へ移行したときの話です。
1. なぜ移行が必要だったか
もともとこのアプリケーションは、クライアントには公開せず、社内メンバーがクライアントへのヒアリングで利用する想定のツールでした。そのため、個人のVercel + GitHub環境で構築・運用されていました。
しかし運用を続ける中で、いくつかの問題が表面化しました。
- 引き継ぎがうまくいかず、本来非公開のはずのアプリケーションURLが客先に伝わってしまっていたこと
- 担当者が変わるたびに新しい個人のVercel環境を用意する必要があり、そのたびにアクセスURLやリポジトリが変わってしまうこと
- そもそも個人環境のため、セキュリティリスクが高い
属人化した運用が、そのままセキュリティリスクや引き継ぎコストに直結していた状態です。
この課題を解消するため、リポジトリを1つに集約し、組織で契約しているBacklogとAWSへ移行することを決めました。
2. 移行前の構成
移行前は、担当者それぞれが個人アカウントでVercelにデプロイし、GitHubリポジトリも個人管理という状態でした。組織としての一元管理はなく、誰がどのリポジトリ・環境を持っているかも把握しづらい構成でした。
3. 移行後の構成
移行後は、Backlog Gitへのpushをトリガーに、AWS上のパイプラインが自動でビルド・デプロイを行う構成にしました。
GitHubが利用できないという制約があったため、Backlog GitのWebhookをそのままCI/CDのトリガーにする必要がありました。Amplifyは直接Backlog Gitと連携できないため、CodeCommitへのミラーリングを挟むことで橋渡しする構成にしています。
4. 各コンポーネントの役割
| コンポーネント | 役割 |
|---|---|
| API Gateway | Backlog Gitからのwebhookを受信する共通エンドポイント |
| Lambda | ビルド起動、Amplifyアプリの自動生成など各種処理のトリガー |
| CodeBuild | ビルド実行(CodeCommitへのミラーリング) |
| CodeCommit | Backlog Gitのミラーリング先。Amplifyと連携するための中継リポジトリ |
| EventBridge | CodeBuildの成功を検知し、後続のAmplifyデプロイ処理を起動 |
| Amplify | アプリケーションの自動ビルド・デプロイ先 |
| WAF | 各アプリケーションへのアクセス制御 |
| IAM | 各サービス間の権限管理 |
5. 工夫した点・詰まった点
移行にあたって、特に判断が難しかったのが以下の2点です。
カスタムドメインの設定
AWS Amplifyでアプリケーションを構築すると、デフォルトではAmplify側が自動生成する文字列URLが割り当てられます。これを企業ドメインに乗せる必要があったため、Amplifyに用意されているカスタムドメインの設定機能を使い、ビルド後に企業ドメインを自動で設定し、企業ドメイン配下でアクセスできるようにしました。
WAF設定の自動化
アプリケーションごとにWAFの設定が必要になる構成だったため、都度手動で設定していると運用の手間が増え、設定漏れのリスクも出てきます。そこで、新しいアプリケーションが追加されるたびにWAFの設定を自動で行う仕組みを組み込みました。
6. 移行してどう変わったか
移行によって、運用面で大きく2つの変化がありました。
1つは、権限管理がシンプルになったことです。個人のGitHubアカウントに依存していた状態から、会社で契約しているBacklogプロジェクトに参加してもらう形に変わったことで、開発メンバーであれば誰でも編集に参加できるようになりました。特定の個人にリポジトリへのアクセス権が紐づくことがなくなり、引き継ぎの負担も大きく下がりました。
もう1つは、URL設計の自由度が上がったことです。企業ドメインのもとでアプリケーションを管理できるようになったことで、クライアントごとにURLを分けて公開することが可能になりました。これにより、クライアント専用のURLを個別に用意できるようになり、以前のような「個人のVercel環境のURLをそのまま客先に伝えてしまう」といったリスクも構造的になくなりました。
おわりに
個人アカウントでの運用は、始めるハードルが低い一方で、属人化やセキュリティ面のリスクを後から抱えることになりがちです。今回のようにBacklog GitとAWSを組み合わせることで、GitHubが使えない制約下でも、組織として管理できるCI/CD基盤を構築できました。同じような制約を抱えている方の参考になれば幸いです。