Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
バッチシステムのリプレース ~オンプレ/PHP->AWS/TypeScriptで実現する大規...
Search
muratak
November 30, 2024
0
18
バッチシステムのリプレース ~オンプレ/PHP->AWS/TypeScriptで実現する大規模バッチの新規設計、構築~
・大規模なバッチリプレースをAWSで実現する工夫
・新規にバッチシステムを構築するための技術選定のポイント
muratak
November 30, 2024
Tweet
Share
More Decks by muratak
See All by muratak
DDoS対策 ~監視、分析、対策~
tresagua0123
2
79
Why Hono なぜHonoを使うべきなのか
tresagua0123
6
1.3k
大規模な美容メディアのフロントエンドを支えるサーバー技術
tresagua0123
0
25
Next.jsのセキュリティ設計とアーキテクチャ
tresagua0123
4
3.1k
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
For a Future-Friendly Web
brad_frost
179
9.8k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Automating Front-end Workflow
addyosmani
1370
200k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
950
A Tale of Four Properties
chriscoyier
160
23k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Building Adaptive Systems
keathley
43
2.7k
Transcript
バッチシステムのリプレース ~オンプレ/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及び一部本番) ・非機能要件 : パフォーマンス、負荷、可用性、保守、ログ、監視 など各種観点 ・セキュリティ :
個人情報が適切に扱われているか?や脆弱性はないかなど ・リリース計画 : リリースの事前周知と有事の際の切り戻し策 こう言った各種観点から、 →リプレースしたシステムが問題なく稼働できるよう万策を事前に練るよ
おしまい