自社サービス
自社開発のSaaS
画面 jQueryBootstrap → Vue 3InertiaTailwind CSS
- どんなシステム
- 外部の10サービスとつながり、毎晩自動で動く業務の仕組み（画面約75）
- 難しかった点
- 10の外部サービスとの連携を、すべて動く状態のまま移した
- 引き継いだもの
- 利用者に配布済みのURLを、切らずに移した
- いま
- Laravel・PHP 8.4で稼働している
EC2で動くシステムを、Terraformで管理するECS Fargateへ
状況を相談する（無料・オンライン）古い構成のサポート状況（2026年11月時点）
-
PHP 7系の最後の版（7.4）のサポートが終わりました。出典：php.net
-
Amazon Linux 2 のサポートが終わりました。標準のセキュリティ更新は出ていません。出典：aws.amazon.com
移行で置き換えるもの
| EC2に直接入れた構成 | Terraformで管理するAWS |
|---|---|
| EC2 に Apache と PHP を入れて動かす | ECS Fargate のコンテナ（ARM64）。OS の更新作業がなくなります |
| 画面から手で作った構成。記録は手順メモ | Terraform（OpenTofu）のコード。変更の履歴が Git に残ります |
scp で1ファイルずつ配布 | CodePipeline。main への反映で、テスト・ビルド・入れ替えまで進みます |
| 設定ファイルに書いた接続情報・APIキー | Secrets Manager。タスク定義の secrets からキー単位で渡します |
サーバーの cron | schedule:work と queue:work を、専用のコンテナで動かします |
| EC2 のディスクに置いたアップロードファイル | EFS。AWS Backup で毎日取り、35日残します |
| RDS / Aurora（インスタンスの大きさを固定） | Aurora Serverless v2 を2台。1台は、障害のときに切り替わる先です |
移行の進め方
- 今の環境を調べて、一覧にする
EC2・ロードバランサー・データベース・DNS・証明書・セキュリティグループを AWS から読み出して一覧にします。手で作られた環境は、ここで初めて全体が見えます。
- 今の環境には触れず、新しい環境を横に作る
VPC・サブネット・証明書・ホストゾーンは今あるものを Terraform から参照し、作り直しません。今の環境のリソースは Terraform の管理に入れず、
planの結果が0 to change, 0 to destroyであることを毎回確かめます。 - 別のホスト名で先に公開して、確かめる
新しい環境を検証用のホスト名で公開し、本番のデータを移して動きを確かめます。確かめ終えたら、検証用のホスト名は本番のホスト名へ転送します。
- DNSで切り替える
切り替えは Terraform の変数で行います。配布済みのURLが載っているホスト名のように影響の大きいものは、専用の変数に分けて当日まで
falseのままにし、ほかの変更のapplyで先に切り替わらないようにします。 - 安定を確かめてから、今の環境を撤去する
切り替えのあと、旧環境はしばらく残します。データの移行と動きの確認が終わってから、EC2・旧ロードバランサー・旧データベースを消します。
組むときに決めていること
- stateの置き場所
S3 の
backendに置き、暗号化とuse_lockfileを有効にします。DynamoDB のロック用テーブルは作りません。state 用のバケットは、最初に1回だけ別の Terraform で作ります。 - 秘密情報の値をコードに書かない
データベースの接続情報や外部サービスの API キーは、Terraform では Secrets Manager の入れ物だけを作り、値はコンソールか CLI から入れます（
ignore_changes）。state には秘密情報が含まれることがあるので、state のバケットは暗号化し、公開をすべて止めます。 - データベースのパスワードのローテーション
Aurora のマスターパスワードは AWS に管理させます。ECS は
secretsをタスクの起動時に一度しか読まないため、自動で変わるパスワードをアプリに渡すと、稼働中のタスクが古い値のまま接続できなくなります。そのためアプリには、マスターユーザーとは別に、自動では変わらない専用のユーザーを作ります。 - デプロイで戻せるようにしておく
イメージのタグはコミットの SHA にし、ECR は
IMMUTABLEにして上書きさせません。ECS のサービスにはdeployment_circuit_breakerを入れ、入れ替えに失敗したら前の版へ自動で戻します。データベースの移行はmigrate --isolatedで、新旧のタスクが並んでも二重に走りません。 - Terraformとデプロイの持ち場を分ける
タスク定義の中身は CodePipeline が更新します。Terraform 側は
ignore_changesにして、次のapplyで巻き戻さないようにします。 - 通信を絞る
セキュリティグループは、相手のセキュリティグループを指定して開けます。データベースと EFS は、アプリのタスクからの通信だけを通します。
- WAFを入れるときは、数えるだけの設定から始める
外部に公開する会員向けのシステムでは、AWS のマネージドルール（
CommonRuleSet・SQLiRuleSet・PHPRuleSetなど）とレート制限を入れます。最初は全ルールを「数えるだけ」にしてログを見て、誤検知がないことを確かめてから止める設定に変えます。ファイルのアップロードのように正しい操作を止めてしまうルールは、数えるだけのまま残します。 - 監視
CloudWatch のアラームを SNS からメールで通知します。5xx の増加、正常なタスクが0、メモリ、Aurora の負荷、メールのバウンス率を基本にして、ほかはシステムごとに決めます。
今の構成の確かめ方
- OSの版
- サーバーで
cat /etc/os-release - PHPの版
- サーバーで
php -v - 構成がコードで残っているか
- CloudFormation のスタックと、リポジトリの
*.tfの有無
移行の事例（2件とも、PHPの移行と一緒にAWSを組み直しました）
看護教育・新規事業
会員制プラットフォーム
画面 jQueryBootstrap → Vue 3InertiaTailwind CSS
- どんなシステム
- 会員がログインして使う、学習と求人のサイト
- 難しかった点
- 移行と同時に、49画面をデザインから刷新した
- 引き継いだもの
- 会員のパスワードはそのままに、日中に切り替えた
- いま
- 開発約8週間で切り替えた
よくある質問
構築のあとの監視や障害対応もお願いできますか？
24時間の監視と障害の一次対応はお受けしていません。必要な場合は、運用を専門にしている会社をご紹介します。アラームの設定と、デプロイ・ロールバックの手順書まではお渡しします。
今の環境を止めずに移せますか？
新しい環境を横に作って DNS で切り替えるので、止めるのは切り替えのときだけです。止める時間は、本番のデータで切り替えのリハーサルをして事前に決めます。
今の環境を、そのまま Terraform の管理に入れられますか？
import で取り込むこともできます。ただ、EC2 に直接入れた構成はコードにしても同じものを作り直せないので、当社では新しい環境を横に作って切り替える進め方をとっています。
PHPの移行と一緒でなくても頼めますか？
お受けできます。ただし、サポートが終わった PHP のままコンテナに載せ替えるだけの作業は、お受けしていません。
AWSのアカウントは、どちらの名義で作りますか？
お客様の名義のアカウントに作ります。今お使いのアカウントがあれば、その中に作ります。
検証用の環境も作れますか？
作れます。同じ Terraform のコードから作るので、本番と同じ構成になります。費用は環境の数だけかかるので、要るかどうかは最初に決めます。
費用と期間はどのくらいかかりますか？
今の構成を確認したうえでお伝えします。AWS の利用料は、構成を決めた時点で月額の見込みをお出しします。
