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
8
バッチシステムのリプレース ~オンプレ/PHP->AWS/TypeScriptで実現する大規模バッチの新規設計、構築~
・大規模なバッチリプレースをAWSで実現する工夫
・新規にバッチシステムを構築するための技術選定のポイント
muratak
November 30, 2024
Tweet
Share
More Decks by muratak
See All by muratak
Why Hono なぜHonoを使うべきなのか
tresagua0123
6
900
大規模な美容メディアのフロントエンドを支えるサーバー技術
tresagua0123
0
17
Next.jsのセキュリティ設計とアーキテクチャ
tresagua0123
4
2.8k
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Automating Front-end Workflow
addyosmani
1368
200k
The Invisible Side of Design
smashingmag
299
50k
Unsuck your backbone
ammeep
669
57k
Facilitating Awesome Meetings
lara
52
6.2k
Being A Developer After 40
akosma
89
590k
Adopting Sorbet at Scale
ufuk
74
9.2k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Scaling GitHub
holman
459
140k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
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及び一部本番) ・非機能要件 : パフォーマンス、負荷、可用性、保守、ログ、監視 など各種観点 ・セキュリティ :
個人情報が適切に扱われているか?や脆弱性はないかなど ・リリース計画 : リリースの事前周知と有事の際の切り戻し策 こう言った各種観点から、 →リプレースしたシステムが問題なく稼働できるよう万策を事前に練るよ
おしまい