※この記事は 2025年02月19日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。
Tebiki株式会社でtebiki現場教育サービスのプロダクトエンジニアを担当している清田です。 去年、tebiki現場教育で利用していたバッチ処理基盤を移行しました。 当記事では、その移行の内容を紹介します。
前提
tebiki現場教育サービスでは、主に以下の用途でバッチ処理基盤を利用していました。 ・業務イベントに応じたメール一括送信 ・ユーザ全体へのお知らせ通知 ・ユーザの学習状況の収集
バッチ処理基盤はAWSのElastic Beanstalk上でRuby on Rails製のアプリケーションとして起動しており、wheneverというgemを利用して所定のジョブを定期実行していました。
バッチ処理基盤のアプリケーションは改修頻度が低く、社内でオーナーシップを持ってメンテナンスするメンバーがいない状況でした。
その結果、Elastic Beanstalk上で稼働するgemのバージョンが古いまま放置されたり、利用しているRubyプラットフォームがリタイアしてしまい環境が不安定になるといった課題が生じました。
これらの課題を解決すべく、バッチ処理基盤の移行プロジェクトが開始しました。
対応方針
様々な案が検討されましたが、バッチ処理基盤を新環境に移行するのではなく、ECS上で稼働している既存のWebアプリサーバにバッチ処理基盤を統合するという案に決定しました。
具体的には、以下の内容となります。 ・Webアプリ側のベースに合わせたコード改修 ・Webアプリ側にgitレポジトリを統合することで、Webアプリとバッチ処理基盤でコードを共有する ・Elastic Beanstalkで稼働していたアプリケーションは廃止する ・EventBridge Schedulerから、ECSで稼働しているWebアプリのタスクとしてバッチ処理を起動させる
イメージ図
既存のWebアプリに統合することで見込める利点は以下です。
①バッチ処理基盤で利用されていたgemのバージョンアップがしやすくなる gemのバージョンアップにあたっては、Webアプリとバッチ処理基盤でそれぞれのレポジトリに対する作業が発生して手間がかかっていましたが、Webアプリ向けレポジトリのみになることで、バージョンアップの手間が減ります。 また、Webアプリ向けレポジトリではGithubのDependabotを利用して、gemを週次でバージョンアップすることがエンジニア内で習慣付いています。そのため、これまでのようにgemのバージョンアップが疎かになるような事態は起こりづらくなります。
②エンジニアがバッチ処理を改修するハードルが下がる バッチ処理基盤は改修頻度が少なく、またtebiki現場教育サービス内では独自のインフラ基盤を持っているなど毛色が異なっていたことから、触りにくい雰囲気がありました。 エンジニアが慣れ親しんでいるWebアプリ側のコードに統合されることで、改修のハードルが下がり、リファクタリングも促進されます。
③ドメインロジックを共通化できる これまで、Webアプリとバッチ処理基盤はコードが別々のレポジトリで管理されていたため、ドメインロジックが二重で記載されていました。レポジトリが統合されることでドメインロジックを共通化でき、コードの保守性が高まります。
なお、Webアプリ側にはジョブを定期実行する仕組みが備わっていなかったため、新たに用意する必要がありました。 こちらもいくつかの方法を検討しましたが、ecscheduleを利用して定期実行の仕組みを実現することにしました。 ジョブの実行スケジュールはWebアプリにて管理しているファイルに記述され、アプリをデプロイすると自動的に反映されるようにしました。
イメージ図
移行作業
移行作業は以下の流れで行いました。
①Webアプリ側に定期実行の仕組みを用意する ・ecsschduleで実行スケジュールを登録可能にする ・実行スケジュールに応じて、ECSを起動してジョブ処理を実行可能にする
②バッチ処理基盤のジョブのコードをWebアプリ側に移植する ・Webアプリ側のベースに合わせたコード改修 ・テストコードの実装 ・アラート通知の整備 ・sandbox環境での動作確認
③運用切り替え ・本番環境にて、Webアプリ側のジョブを実行するように切り替え
移行作業にあたって様々な課題に直面しましたが、本記事では運用切り替えの箇所にフォーカスしてご紹介します。
運用切り替え
当初、以下の手順で運用切り替えを実施する予定でした。 ・tebiki現場教育サービスにて、メンテナンスモードにする ・旧バッチ処理基盤にて、ジョブの定期実行を停止する ・Webアプリにて、本番環境向けにジョブの実行スケジュールを登録する ・メンテナンスモードを解除する
しかし、移行作業を進める中で、当初の手順では、 ・ビッグバンリリースになるため、障害が発生した時の切り戻しや原因切り分けに時間がかかる ・メンテナンスモードにすると、ユーザの業務に影響が生じる といった懸念がエンジニア内であがりました。
そこで、フィーチャーフラグ管理機能を活用してこれらの懸念を払拭できるように、運用切り替えの方針を変更しました。
フィーチャーフラグを利用した運用切り替え手順は以下の通りです。 ・フィーチャーフラグ管理画面にて、移行するジョブ単位でフィーチャーフラグを追加 ・旧バッチ処理基盤のジョブ処理にて、フィーチャーフラグがONの場合に処理をskipする分岐を追加 ・Webアプリのジョブ処理にて、フィーチャーフラグがONの場合に処理を実行する分岐を追加 ・移行が完了したジョブごとに本番リリース ・問題発生時には、フィーチャーフラグ管理画面にてフラグを切り替えて切り戻し
イメージ図
これによって、以下の効果が得られました。 ・メンテナンスモードを利用しないため、ユーザの業務に影響がない ・ビッグバンリリースではなく、ジョブ単位で細かくリリースを行える（より安心して迅速にリリースできる） ・何か移行後のジョブで問題が発生した時も、迅速に移行前のジョブに切り戻せる
実際に運用切り替えをしていく中で、本番環境にて一部のジョブで不具合が発覚したこともありましたが、すぐに切り戻して復旧作業を行えたため、ユーザ影響は発生せずに済みました。
まとめ
本記事では、負債となっていたバッチ処理基盤の移行について紹介しました。 今回の移行により、バッチ処理部分の保守性が向上し、追加の機能開発もかなりしやすくなったと感じています。 また、フィーチャーフラグを活用した段階的なリリースにより、安全かつ迅速に移行を行えました。 今回得た知見を活かし、開発生産性を向上しながら、より迅速にユーザに価値を提供できるよう開発を行っていきたいと思います。
私たちは仲間を募集しています！
Tebiki社は、エンジニアを募集しています！ 興味がある方は、ぜひカジュアルにお話ししましょう！
▼採用HP https://tebiki.co.jp/recruit.html ▼募集中のエンジニア求人一覧 https://herp.careers/v1/tebiki/requisition-groups/2514f131-4e3b-4f50-9539-27aa01a6639f
