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
20
バッチシステムのリプレース ~オンプレ/PHP->AWS/TypeScriptで実現する大規模バッチの新規設計、構築~
・大規模なバッチリプレースをAWSで実現する工夫
・新規にバッチシステムを構築するための技術選定のポイント
muratak
November 30, 2024
Tweet
Share
More Decks by muratak
See All by muratak
DDoS対策 ~監視、分析、対策~
tresagua0123
3
84
Why Hono なぜHonoを使うべきなのか
tresagua0123
6
1.4k
大規模な美容メディアのフロントエンドを支えるサーバー技術
tresagua0123
0
26
Next.jsのセキュリティ設計とアーキテクチャ
tresagua0123
4
3.1k
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Practical Orchestrator
shlominoach
190
11k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
332
22k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Documentation Writing (for coders)
carmenintech
73
5k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
It's Worth the Effort
3n
185
28k
Embracing the Ebb and Flow
colly
86
4.8k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Music & Morning Musume
bryan
46
6.7k
The Pragmatic Product Professional
lauravandoore
36
6.8k
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及び一部本番) ・非機能要件 : パフォーマンス、負荷、可用性、保守、ログ、監視 など各種観点 ・セキュリティ :
個人情報が適切に扱われているか?や脆弱性はないかなど ・リリース計画 : リリースの事前周知と有事の際の切り戻し策 こう言った各種観点から、 →リプレースしたシステムが問題なく稼働できるよう万策を事前に練るよ
おしまい