はじめに
こんにちは。GENIEE SFA/CRM インフラチームリーダーのZOU（シュウ）です。
私は普段、AWSをインフラ基盤とする GENIEE SFA/CRM プロダクトのインフラ系の保守運用、コスト削減、リアーキテクチャーなどを担当しています。
今回は「Everything as Codeの践行」という事例をご紹介します。
Everything as Codeとの出会い
Everything as Codeとの出会いは AWS Summit 2025 の「AI Agent 時代のソフトウェア開発の型 〜 Everything as Code で叡智を伝える〜」というセッション（セッションの録画と資料は以下にリンクを記載します）
このセッションが言いたいことは実はシンプルで、「人間だけが知っていることを減らして、AIが自律的に情報を取得できるように、コードを使ってコンテキストの差を埋める」ということです。つまり、「Everything as Code」を一言で言えば、"Git リポジトリを見ればすべてが分かる"状態にするということです。
セッション録画：AWS Summit 2025 -
AI Agent 時代のソフトウェア開発の型 ～ Everything as Code で叡智を伝える ～
セッション資料：https://pages.awscloud.com/rs/112-TZM-766/images/AWS-57_Development_AWS-Summit-JP-2025.pdf
Everything as Codeの践行
Everything as Codeの理念に従って何かインフラで改善できるところがあるかを考えました。第一歩として、GENIEE SFA/CRM でのJenkinsリアーキテクチャーを着手しました。
背景
GENIEE SFA/CRM のAWS環境には、Jenkinsというサービスが動いてるEC2インスタンスがあります。
Jenkinsでは、バックアップ関連、デプロイ関連、監視関連などのジョブが実行されています。
既存の問題：
- メンテナンスが実施されていない：Jenkins のバージョンは 2019 年 1 月 20 日リリースのもので、既に EOL。多くの脆弱性が存在します。
- ジョブの棚卸しが完了していない：約 130 個のジョブが存在しますが、整理・分類されていません。
- スクリプトがコード管理されていない：ジョブで使用するスクリプトがバージョン管理されていません。
- インスタンスリソースが不足している：スペック不足により、一部のジョブが正常に完了しないことがあります。
- 権限管理が不十分：アクセス制御が適切に実装されていません。
Everything as Codeの践行として、こちらの問題を解決するように試しました。
Jenkins自体をやめることができる
元々は Ansible などで Jenkins 自体をコード化管理することを検討していました。しかし、130個のジョブを役割ごとに分類・分析した結果、Jenkins 自体を廃止できるという結論に至りました。
以下、3種類のジョブの移行方法を紹介します。
ジョブ移行
DB バックアップ系のジョブ
毎日深夜、DB（MySQL、MongoDB）に対して mysqldump、mongodump コマンドを実行し、DBのダンプファイルを取得して S3 に保存するジョブがあります。（コマンド完了までバックアップファイルはインスタンスに一時保存されます）
Before：
- データ量が多く、ジョブの実行に 24 時間以上かかることがありました。このジョブがリソースを過度に消費し、他のジョブに悪影響を与えていました。
- ダンプファイルのサイズが大きいため、Jenkins が動く EC2 インスタンスの EBS ボリュームも大きく（150GB 以上）設定する必要がありました。
これらのジョブはAWS Batchに移行しました。
AWS Batch はバッチ処理を実行するためのマネージドサービスです。AWS Batch 自体はシンプルなサービスですが、今回の移行でピックアップしたいことが一点あります。これは「ニーズに応じて正しいインスタンス」を選択するということです。
今回はAWS Batch のコンピューティング環境を EC2 で構成し、「d」が付いたインスタンスタイプを選択しました。「d」は、インスタンスに NVMe SSD の内蔵ストレージを搭載するオプションです。
例えば、下図に示す c6id.xlarge インスタンスの場合、デフォルトで 237GB のストレージが搭載されています。
「d」が付いたインスタンスを選択した理由は、ダンプファイルを S3 に保存する前にインスタンスに一時保存する必要があり、大容量のストレージが必要だったためです。「d」が付いたインスタンスは、このような一時的で大容量のストレージニーズに最適です。
After：
- バックアップジョブが高速かつ安定して完了するようになりました
- AWS Batch で使用する Dockerfile などをコード管理しました
- 背景、技術選定、作成したリソース一覧などを含むドキュメントをコード管理しました
デプロイ系のジョブ
これらのジョブは SFA の CD パイプラインを担当しています。日常的な運用では大きな問題がありませんでしたが、以下の課題がありました。
Before：
- 開発環境へのデプロイを行うため、全開発者に Jenkins アカウントを作成する必要がありました
- ジョブの権限管理は実装されていませんでした
- ジョブはコード化管理されていませんでした
GENIEE SFA/CRM のデプロイはAWS CodeBuildをメインで使用しているため、Jenkinsのジョブはcodebuild_client.start_buildを叩くだけです。そして GENIEE SFA/CRM は GitHub でソースコードを管理しています。この二つの理由で、これらのジョブをGitHub Actionsに移行しました。
After：
- 開発者は GitHub のみに招待すれば良くなりました
- GitHub を通して権限管理ができるようになりました
- デプロイ用のジョブをコード管理できるようになりました
多くのプロジェクトでは、GitHub の手動実行ワークフローの実行者制限を設けていないと思われます。今回の実装方法を紹介します。
まず GitHub のユーザーを属性に応じて、適切なチームに分類しました。例えば、
- SFA/CRM Dev Staff：GENIEE SFA/CRM開発正社員用のチーム
- SFA/CRM Dev Contractors：GENIEE SFA/CRM開発業務委託と他部門のSFA開発連携者用のチーム
そして基本的に、SFA/CRM Dev Staff チームのみに Maintain 権限を付与しています。ワークフロー内で実行者の権限をチェックし、Maintain 権限以上でない場合は実行を拒否する仕組みにしています。
他の定期実行ジョブ
データ異常があるかどうかのチェック、古いデータの削除、リソース状態監視のため、（DB バックアップ以外）定期的に実行するジョブがあります。Jenkinsをやめる方針なので、こちらのジョブの移行が必要になります。
複数の移行先候補がありましたが、「既存スクリプトの実行場所を変えず、迅速に移行でき、ジョブ定義をコード化できる」という観点から、EventBridge + SSM Run Command に移行しました。
処理フロー：
- スクリプトファイルを GitHub にプッシュします
- GitHub PR がマージされると、ワークフローにより S3 オブジェクトや EventBridge などのリソースが自動作成・更新されます
EventBridge の動作：
EventBridge は SendCommand API 経由で、EC2 インスタンス内で以下のコマンドを実行します。
- S3 からスクリプトファイルをダウンロードします
- 実行権限を付与します
- スクリプトを実行します
- スクリプトを削除します
これにより、これらのジョブをコード化して管理できるようになりました。
まとめ
出典：AWS Summit 2025 - AI Agent 時代のソフトウェア開発の型
〜 Everything as Code で叡智を伝える 〜
Everything as Code は、アプリケーションコードだけでなく、インフラストラクチャ、デプロイメント、監視など、8つの領域に適用できます。これらすべてがコード化されることで、人と AI の協働がより効果的になります。
皆さんも日常業務で Everything as Code を意識し、試行錯誤してみてください。
Discussion