こんにちは、Nakaです。
今回は、マスターインポーターのバッチ実行環境の構築について紹介します。
本記事で扱うシステムでは、アプリケーションが参照するマスターデータを管理しています。マスターデータとは、設定値・表示用データ・各種定義情報など、アプリケーションの動作の基準となる基礎データです。
これらのデータはExcel、Google Spreadsheet、CSV などで管理されることが多いです。本システムでは、それらのデータを取り込み、アプリケーションが参照する DB へ反映する処理（マスターインポーター）を提供しています。
マスターデータは件数が多く一括更新が必要になることが多いため、管理画面からの個別登録ではなくインポート方式を採用しています。また、大量データをまとめて処理する性質上、API ではなくバッチとして実行しています。
この仕組みに合わせ、非エンジニアでも安全に実行できることを前提として設計しました。Slack からバッチを実行し、結果を通知し、必要に応じて Amazon ECS を自動更新するフローを構築しています。本記事では、その設計と実装について解説します。
今回の仕組みでは、主に以下の2つの要件を満たす必要がありました。
非エンジニアは基本的に AWS への直接操作権限（IAM）を付与しない運用のため、AWSコンソールを使わずに実行できる必要があります。そのため、
を前提としました。
サーバーは PHP で動作しており、マスターデータのキャッシュは APCu によってサーバーメモリ上に保持されています。
全サーバーに対してキャッシュクリア処理を実装する方法もありますが、実装コストが高く、仕組みも複雑になります。そのため今回は、バッチ実行後にサービスを再デプロイしてキャッシュを更新する方式を採用しました。
この自動化は、AWS Step Functions を中心に構築しています。Slackからワークフローを起動し、バッチ実行・ログ通知・ECS更新までを一連の処理として管理します。Slackへの投稿には2パターンあります。（詳細は後述）
※ ECS 更新は AWS Step Functions内で実行されます