🧭 はじめに
「モノリスをマイクロサービスに分割したい」
──この理想に手が届かずに苦しむチームは、少なくありません。
実際、現場では以下のような現実があります。
- モノリスは技術的負債が多く、全容を把握できる人が減っている
- 全部をリプレイスするには時間も工数も足りない
- ビジネス要求は止まらない中、"移行だけ"に集中できる余裕がない
こうした背景の中で、私たちのチームでは “段階的に・部分的に” モダンな構成へと移行する戦略をとりました。
本記事では、AWSのベストプラクティスを参考にしながら、現場で実践したモノリス脱却の4ステップを紹介します。構成図・考慮点・実際のTipsも交えて詳しく解説します。
🧱 Before構成（旧モノリス）
まずは、出発点である “旧モノリス” 構成の概要です。
- オンプレまたはEC2上に構築された LAMPスタック（Apache + PHP + MySQL）
- バッチ、UI、API、外部連携など全てが1つのプロジェクト内に存在
- デプロイ時は手動でssh接続 → アップロード → サービス再起動
- ログ収集や障害通知は存在せず、基本的に“気づいた人が対応”
いわゆる「密結合・職人頼み・属人化」の三重苦が揃った構成でした。
🔄 AWS公式：モダンアプリの4つの柱（引用）
AWS公式「モダンアプリケーション開発」では、以下の4つの設計指針が示されています：
- マイクロサービスアーキテクチャ：責務を分離し、単一機能単位での独立運用を可能にする
- サーバレスファースト：インフラ管理コストを極小化し、機能開発に集中できるようにする
- マネージドサービス活用：SaaSやPaaSを積極活用し、非競争領域の開発・運用から脱却する
- 自動化されたCI/CD：高速かつ安全なリリースを実現するために、パイプライン化・テスト自動化を重視
この指針を念頭に、私たちはまず「切り出しやすい機能」から分離を開始しました。
✅ 4ステップで進めた「なんちゃってマイクロサービス化」
🚀 Step 1：通知・外部APIを Lambda化して分離
AWSの狙い：副作用処理は責務として明確に分離し、独立したマネージド環境へ隔離する
💡 背景
- 通知処理（Slack通知／メール送信／Webhookなど）が本体コードにベタ書きされており、コードの可読性が低下していた
- 通知先の仕様変更（URL変更やAPIトークン更新）があると、デプロイ全体が必要になっていた
- 処理失敗のログが追えず、"通知されていない"ことに誰も気づかない事態も発生
🔧 実装概要
- AWS Lambdaに Node.js で通知用コードを実装（Slack投稿やSendGrid送信など）
- API Gatewayを用いて、エンドポイント化（パス：
/notify） - モノリス側から
fetch/curl/axiosで呼び出し - 失敗時は CloudWatch Logs + SNS で通知を受け取る構成へ
✅ メリットと所感
- 通知仕様の変更が “本体と独立して” 運用できるようになった
- 障害時のトラブルシュートがしやすくなり、開発者の心理的負担も軽減
- 社内SREチームと役割を分離できたことで、コードの責任範囲が明確に
🛠 Step 2：バッチ処理を Lambda + EventBridge + Step Functions に移行
AWSの狙い：定期処理は冪等・観測可能・再実行可能な構成で
📦 実施内容
-
cronで管理されていた複数の夜間バッチ（データ整形／集計／エクスポート）をLambda化 - AWS EventBridgeで時間指定トリガーを設定（例：毎日2:00実行）
- 複数Lambdaをつなげる場合は Step Functions で制御フロー化
- 処理結果はS3・DynamoDB・CloudWatchに自動出力されるよう変更
🧠 運用Tips
- 失敗時は Step Functions のログから再実行できる
- Lambda関数のステートレス化により、ローカル開発もテストしやすくなった
- バッチ処理に関するドキュメントをNotionで構造化し、誰でもメンテ可能にした
💻 Step 3：SPA部分を AppRunner + API Gateway で分離構築
AWSの狙い：UIは高速更新・高速配信可能なモダンSPAへと進化させるべし
🎯 背景
- フロントエンドは jQueryベースのレガシーなテンプレートエンジン（Blade）
- ページ全体がリロードされるUIで、UXに大きな不満
- CI/CD構築も難しく、UI改善が手作業で遅延していた
🛠 実装構成
- Next.js（App Router）を用いてSPAを構築
- AppRunnerで
build & deployを自動化 - API呼び出しは Lambda + API Gateway 経由
- 認証は Cognito で統一（トークン認証＋ログイン導線）
✅ メリット
- UIチーム単独で改善サイクルを回せるように
- 機能追加の速度が約2倍に向上
- デザイナーとエンジニアの分業がしやすくなった
🔐 Step 4：Cognito認証でSPA／モノリス共通認証を構築
AWSの狙い：Authは“共通の信頼ソース”で設計せよ
実装ステップ
- ユーザー認証を Cognito（User Pool + Hosted UI）で統一
- JWTトークンをAPI Gatewayで検証
- モノリス側でもミドルウェアでJWTをdecodeし、ロール判定
- アクセス制御をグループ単位で一元化
注意点
- トークンのリフレッシュタイミング設計が重要
- SPAとAPIが異なるサブドメインを持つ場合、Cookie設定（SameSite/secure）に注意
- 初回ログイン時のリダイレクトフローをユーザーにわかりやすく設計する工夫も必要
📦 最終構成図（全体構成）
✅ 最後に：完璧じゃなくても“価値ある一歩”になる
大事なのは、全てを一気に変えようとしないことです。
- まずは“切り出しやすい”ものから
- 切り出し→運用→改善の成功体験を積み上げる
- 小さな進化でも、確実にチームの力になる
モノリスは“古いから悪い”のではなく、“変化に弱くなる”ことが問題。
部分的にでも柔軟性を取り戻せれば、モダンな開発は“いまからでも”始められます。