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
大規模な美容メディアのフロントエンドを支えるサーバー技術
tresagua0123
0
14
Next.jsのセキュリティ設計とアーキテクチャ
tresagua0123
4
2.8k
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Designing for humans not robots
tammielis
250
25k
How STYLIGHT went responsive
nonsquared
96
5.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
3k
The Power of CSS Pseudo Elements
geoffreycrofte
74
5.4k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
YesSQL, Process and Tooling at Scale
rocio
170
14k
Designing for Performance
lara
604
68k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.2k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
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及び一部本番) ・非機能要件 : パフォーマンス、負荷、可用性、保守、ログ、監視 など各種観点 ・セキュリティ :
個人情報が適切に扱われているか?や脆弱性はないかなど ・リリース計画 : リリースの事前周知と有事の際の切り戻し策 こう言った各種観点から、 →リプレースしたシステムが問題なく稼働できるよう万策を事前に練るよ
おしまい