バッチ処理のコンテナ化によって手に入れた業務効率化の実現と属人化の排除。その方法とは ?
永井 勝一郎 氏
コネヒト株式会社 エンジニア グループリーダー
ママ向け Q&A アプリ「ママリ」のインフラエンジニアを務めるコネヒトの永井 勝一郎 氏は、2019 年 10 月に開催された AWS DevDay Tokyo 2019 の Call for Paper (公募) 部門のセッションに登壇。「AWS サービスで実現するバッチ実行環境のコンテナ/ サーバーレス化」というテーマで 2 つの自社事例を紹介してくださいました。今回はそのなかから、Amazon ECS Scheduled Task を活用し、スケジュール系バッチ処理の効率化をどのように実現されたのか振り返っていただきます。
話題のポイント
課題
バッチ処理の新規登録やリリース前のテスト実行を担当するのは一部のサーバーサイドエンジニアのみだったため属人化しやすく、手動を前提としたレガシーな運用が残っていた。またサービスに悪影響が出ないよう、アプリケーションリリース以外は極力変更を加えなたくないという意識が働きがちだった。
解決策
スケジュール系バッチ処理をコンテナ化し Amazon ECS Scheduled task に移行。
成果
専用のバッチサーバーが不要になり、どのバッチをどのホストで動かすかはオーケストレーションツールに任せたため、業務の効率化と属人化の排除を実現。可搬性の高さを生かすことで、プラットフォーム変更の敷居が下げることができた。
レガシーな運用プロセスに起因する「負の連鎖」を断ち切りたかった
「できることなら、サーバーの管理や運用の手間を最小限に抑えてサービス開発に集中したい。そんな思いでバッチ処理のコンテナ化に取り組みました」
ママ向け Q&A アプリ「ママリ」の インフラ担当のグループリーダー、永井 氏は当時の様子をこう振り返ります。
「2017 年 8 月から半年ほどかけて、まずウェブサービスのコンテナ化に取り組み、その後、バッチ処理のコンテナ化に着手しました。サービスの拡大に勢いがつくなか、バッチ処理だけレガシーな運用を残すというのもバランスがよくないと考え、ウェブサービス同様、バッチ処理もコンテナ化し、システムの管理・運用の負荷軽減を図ろうと考えました」
サービスの拡大によって、サーバーの変更権限を持つインフラエンジニアの仕事が増えれば、アプリケーションエンジニアが承認を待つ時間も延びます。もしこうした状況を看過すれば、いずれアプリケーションエンジニア、インフラエンジニアのストレスも増し、開発効率は落ちるのは明らかでした。
「レガシーな運用プロセスに起因する負の連鎖を断ち切りたかったというのが、バッチ処理のコンテナ化を後押しした一番の理由」と、永井 氏は振り返ります。しかし、運用プロセスの改善だけが、移行を志した理由ではありませんでした。
「当時コネヒトには、私を含めて 2名のインフラエンジニアしかおらず、私たち以外にバッチサーバーの構成を詳しく知る人間がいないというのも、長い目で見れば大きな問題だと感じていました。もし、バッチ処理のコンテナ化によってインフラ構成をコード化すれば、効率的な管理・運用体制が築けるだけでなく、サーバー運用の属人化も防げます。多少、移行を実現するために学習コストはかかるにしても、デメリットよりメリットが勝ると判断しました」
他の選択肢ではなく、Amazon ECS ScheduleTask を選んだ理由
バッチ処理をコンテナ化する方法はひとつではありません。実行方式の選定にあたって永井 氏は次の点をとくに重視して方針を定めたと永井 氏はいいます。
「バッチ処理のためだけに新たにインフラ環境を用意するのは、新たな業務が発生するため効率化したいという目的に反します。開発環境は、すでに AWS と Docker で運用していたので、その資産を生かせるようなシンプルなアーキテクチャーが必要でした」
そのため、技術選定の過程では、Amazon EC2 で cron サーバーを動かすことや、AWS Lambda 、 AWS Batch の活用も検討しましたが、運用の手間や技術的な制約などを考えると、必ずしも最適解とはいえなかったと、永井 氏は話します。
「検討した候補のなかで、唯一私たちの希望に叶う方法が、オーケストレーションツールの Terraform と Amazon ECS の ScheduledTask を活用する方法でした。この方法なら、Terraform の定義を見れば、サーバーエンジニアでなくても、どんなバッチがあるのか理解できますし、cron 記法でスケジュールを定義することも可能です」
もうひとつ、移行を後押しした理由がありました。
「 ScheduledTask は、コンテナ起動時に指定した Docker イメージを Pull するアーキテクチャーなので、デプロイ時に実行中のバッチに影響を与えることもありません。毎回インスタンスが変わる AWS Lambdaや AWS Batch より、早い起動が期待できるのも魅力的に思えました」
※技術選定のポイントをまとめた記事（コネヒトエンジニアブログ）
明らかな減点材料もなく利点も明確な選択肢が見つかったものの、当時は導入実績もそれほど多い技術ではありませんでした。本番環境に適応することに不安はなかったのでしょうか。
「当時は先行事例に関する情報があまりなかったので、多少の不安があったのは確かです。ただ、AWS のソリューションアーキテクトにも相談した上での判断でしたし、ウェブサービスのコンテナ化を通じて私たち自身にもある程度 AWS についての知見もついていました。そこで思い切って挑戦することに決めました」
実際に本番環境に適用する前には、リスクヘッジとして 1 カ月ほどステージング環境で Scheduled task を動かしてみて、監視と動作検証を行ったといいます。
「とくに問題がないことを確認できたので本番環境に移行しました。それ以来、大きなトラブルもなく現在に至っています」
AWS Step Functions の活用を視野にインフラ運営の高みを目指す
永井 氏は「機能的や安定性に関しては、十分満足している」と評価します。
「当初の目論見通り、バッチサーバーの管理が不要になりましたし、アプリケーションエンジニア自身が、GitHub での開発フローに乗せて、バッチの登録や変更、削除を Pull Request 形式で行えるようになりました。また、起動タイプとして AWS Fargate を選ぶことができるようになったので、サーバーレスの恩恵も受けられます。運用の選択肢が広がったことも導入してよかった点といえるでしょう」
今後は、AWS Step Functions の活用を視野に入れ、バッチ処理をはじめ、インフラ運営のさらなる高度化を目指したいと永井 氏はいいます。
「たとえば A の処理が終わったら B の処理を動かし、もし A の処理に失敗したら B の処理は動かしてはいけないといった高度な処理を行うには、 ScheduledTask ではなく Step Functions の活用が不可欠です。冒頭にも申し上げた通り、サーバーを管理する手間やコストを最小限に抑えてサービス開発に集中したいので、バッチ処理に関してもできるかぎり高度化して、管理不要な環境を整えていきたいと思っています」
レガシーなインフラ環境によって、知らず知らずのうちに疲弊しているエンジニアは少なくありません。AWS の機能を活用し、開発インフラの見直しを図ったコネヒトでの取り組みは、労働生産性の改善と新たなサービス開発のリソースが生まれることを示した事例といえそうです。
最後に、コネヒトと同じ悩みや展望をお持ちのデベロッパーがバッチ処理のコンテナ化するメリットについて、改めて伺いました。
「とくに開発リソースが限られている小規模なデベロッパーにとって、今回私たちがチャレンジした方法は、安価で簡単にバッチ処理を効率化できるのでお勧めです。とくに AWS は、マネージドサービスが充実していますし、仮に単体ではできないことも、他の AWS の機能や、その他のサービスを組み合わせれば可能になることはたくさんあります。もし有用な情報を目にしたら、すぐに手を動かして試す習慣をつけておくと、その経験がいざというときの武器になるかもしれません。日頃から意識して実践しておくと、技術的な課題にも対処しやすくなるはずです」
自社の事例を機に、AWS でのバッチ処理のパターンに関して何か気づきを感じていただけたらうれしい、と永井 氏はいいます。
「レガシーな手法にとらわれず、新しい技術を組み合わせて工夫すれば、改善できることは少なくありません。私自身も、実際にサービスに組み込む時に、思わぬ点が露わになってあわてることがないよう、手を動かすことを前提に最新情報のキャッチアップを続けていくつもりです」
プロフィール
永井 勝一郎 氏
コネヒト株式会社 エンジニア グループリーダー
2007 年、日本大学法学部を卒業後、ホテル、旅館の予約サービスを手掛ける一休などを経て、2017 年 にコネヒトに入社。現在はインフラエンジニアとして、ママ向け Q&A アプリ「ママリ」の Amazon ECS を用いたコンテナー化や Amazon Aurora へのデータベースの移行など、同社のサービス基盤づくりに携わっている。
AWS を無料でお試しいただけます