バッチシステムのリプレース ~オンプレ/PHP->AWS/TypeScriptで実 現する大規模バッチの新規設計、構築 ~ 2024/ 4/18 アーリーとレイターのIT企業が語る「システムリプレイス」事例LT & 交流会

istyle/@cosmeについて ・今年で創設25周年 国内外で総合美容サービスを展開

自己紹介 by muratak ・@cosmeを運営するistyle社で働くSWE/ DevRel 現在はRebornというシステム刷新のプロジェクトに複数関わる DevRelとしては本日のイベントの運営を担当 ・技術領域としてはTypeScriptと Go, AWSあたり

自己紹介 ・発信好き転じてSWE/DevRelへ

今日の主題 ・大規模なバッチリプレースを AWSで実現する工夫 ・新規にバッチシステムを構築するための技術選定のポイント

リプレース対象となったシステムの紹介 ・@cosmeの裏側で動くバッチシステム (PHP/オンプレミス) ・全部で40種類くらい の定常実行されているバッチがあるよ (商品の人気ランキング集計だったり、用途はさまざま) ・オンプレでの保守の難しさ、コードが古くなるなどの課題があった →これらのバッチを現状の仕様を損なわずAWS/TypeScriptに移植するよ

AWSでバッチを実現するための技術選定 ・@cosmeバッチでは ECS + Step Functions + Event Bridge ・Event Bridge Schedulerで定期実行 ・Step Functionsでre-runできるように ・CloudWatchにログを送るよ ・NewRelicでスローログなどを見るよ

AWSでバッチを実現する技術選定・比較 ・Lambda → 15分以上の実行ができない(2024.4.18現状) 大量のバッチを一括管理したいニーズには不向きだという判断 ・Batch →キューが溜まってからバッチ処理を行うので時間通りの定常実行には不向き →こういった理由でECSをバッチ処理に使うことが決まった

リプレース実務 : インフラ面 ・オンプレミスでのインフラリソース (CPUやメモリなど )の確認 →AWSになったときにインフラ性能が十分で、コスト面での高騰などないか？ ・ログをどうするか？問題 →必要な情報を漏れなく出し、可読性が高いログを出す cosmeバッチではCloudWatchとNewRelicにより機能からパフォーマンスまで確認 ※Slackでは専用のチャンネルで日々ジョブの成功・失敗具合が自動で報告されるよ

リプレース実務 : アプリ面 ・古PHPコードの解読と言語化 (古文) →古いコードを読み解いて新規にコード化、ドキュメント化 ・TypeScriptによる新規実装 →cosmeバッチでは oclifというフレームワークを用いてバッチ処理を実装 レポジトリー肥大に耐えれるようにレポジトリーパターン で関心分離 速度が少しでも速くなるように、可能な範囲並列処理などテクニックを行って高速化

リプレース実務 : フロント面 ・データベースの確認 新旧バッチそれぞれを実行して、データベースの結果が等しくなるか？ ・フロントエンド (画面の確認 ) 新旧バッチそれぞれを実行して、画面に出るデータの結果が等しくなるか？

リプレースにおいて確認すべき事項 ・機能要件 : 機能が問題なく動くかの事前テスト(stg及び一部本番) ・非機能要件 : パフォーマンス、負荷、可用性、保守、ログ、監視 など各種観点 ・セキュリティ : 個人情報が適切に扱われているか？や脆弱性はないかなど ・リリース計画 : リリースの事前周知と有事の際の切り戻し策 こう言った各種観点から、 →リプレースしたシステムが問題なく稼働できるよう万策を事前に練るよ

おしまい