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
累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却...
Search
kmitsuhashi
July 17, 2024
Technology
0
190
累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却とモダン化への道
kmitsuhashi
July 17, 2024
Tweet
Share
More Decks by kmitsuhashi
See All by kmitsuhashi
ヤプリにおけるAWSコスト最適化の取り組み
kmitsuhashi
0
470
Other Decks in Technology
See All in Technology
トレタO/X アーキテクチャ移行記 Next.js App Router化への道のり / TORETA TECH UPDATE 1
okunokentaro
2
560
[RSJ24] Task Success Prediction for Open-Vocabulary Manipulation Based on Multi-Level Aligned Representations
keio_smilab
PRO
0
220
Javaにおける関数型プログラミンへの取り組み
skrb
4
110
データウェアハウス製品のSnowflakeでPythonが動くって知ってました?
foursue
1
150
20分で分かるIAM全機能 (拡大版) / 20240903-jawsug-yokohama-iam
opelab
3
120
Evolving DevOps Teams and Flexible Organizational Culture
kakehashi
1
130
Staff Engineer / 20240827 Yuichiro Masui
shift_evolve
0
150
Dojo 20240830 COBOL to Java on Z
ichikawayasuhisa
0
240
音声AIエージェントの世界とRetell AI入門 / Introduction to the World of Voice AI Agents and Retell AI
rkaga
3
460
Envoy External AuthZとgRPC Extensionを利用した「頑張らない」Microservices認証認可基盤
andoshin11
0
140
標準最高!標準はださくないぞ! at fukuoka.ts #1
yoiwamoto
0
150
Azure Cosmos DB での時系列ログの運用と改善
sansantech
PRO
0
190
Featured
See All Featured
Ruby is Unlike a Banana
tanoku
96
10k
The Language of Interfaces
destraynor
153
23k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
22
1.7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
103
47k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
248
20k
Navigating Team Friction
lara
183
13k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
GraphQLとの向き合い方2022年版
quramy
43
13k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
It's Worth the Effort
3n
182
27k
Agile that works and the tools we love
rasmusluckow
327
20k
A better future with KSS
kneath
235
17k
Transcript
累計ダウンロード数1億8000万を超える アプリケーションプラットフォームの レガシーシステム脱却とモダン化への道 2024/7/16 株式会社ヤプリ 三橋
Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い
⾃⼰紹介 3 三橋 奎太 / Keita Mitsuhashi • 株式会社ヤプリ SREチーム所属
• SIer → ヤプリ(2022/4⼊社) • New Relic⼤好き
提供サービス 4 ノーコードモバイル アプリケーション プラットフォーム ノーコード顧客管理 システム 今回の発表はこちらの内容
⽬次 • レガシー脱却 OpsWorksの廃⽌ • モダン化への道 PHPアプリケーションのコンテナ化 5
レガシー脱却 OpsWorksの廃⽌ 6
ざっくりバックエンド構成 • 旧系統はPHP x EC2(OpsWorks)の構成 • 新系統はGolang x ECS/Fargateの構成 7
プラットフォームという性質上、 すべての機能を新系統に移⾏するには時間がかかる
OpsWorks終了のお知らせ 8 この通知は、AWS OpsWorks スタックリソースを 1 つ以上あるお客様に配信 しております。AWS OpsWorks スタックを
2024 年 5 月 26 日に廃止すること をお知らせする連絡を差し上げています。2023 年 5 月 26 日以降、新規のお 客様はこのサービスをご利用いただけなくなります。既存のアカウントは、 2024 年 5 月 26 日まで通常どおりサービスを利用できます。2024 年 5 月 26 日以降、お客様は OpsWorks コンソール、 API、CLI、および CloudFormation リソースを使用できなくなります。
OpsWorks廃⽌のハードル • OpsWorksの代替機能の検討 • 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任 分解) •
ブラックボックス & 影響範囲⼤ 9
OpsWorks廃⽌のハードル • OpsWorksの代替機能の検討 • 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任 分解) •
ブラックボックス & 影響範囲⼤ 10
OpsWorks利⽤状況 • OpsWorksを利⽤しているサーバー ◦ → 約14種類, 合計で100台程度 • 利⽤している機能 ◦
→ OSユーザ管理機能, デプロイ機能, API 11
OpsWorks利⽤状況 • OpsWorksを利⽤しているサーバー ◦ → 約14種類, 合計で100台程度 • 利⽤している機能 ◦
→ OSユーザ管理機能, デプロイ機能, API 12
OSユーザ管理機能の代替 13 管理者 EC2 CSV S3 terraform applyで CSVアップロード SSM
Documentによる OSユーザ同期 パターン2. Run Command実⾏ (⼿動) パターン1. インスタンス起 動時のRun Command実⾏ (⾃動)
OpsWorks利⽤状況 • OpsWorksを利⽤しているサーバー ◦ → 約14種類, 合計で100台程度 • 利⽤している機能 ◦
→ OSユーザ管理機能, デプロイ機能, API 14
デプロイ機能の代替 15 EC2 開発者 Chef Recipe管理 リポジトリ push GitHub ActionsによるChef
Recipeのアップロード S3 Chef Recipe SSM Documentによる Chef Recipeの実⾏ Chef Recipe 実⾏完了の通知 アプリケーション コード管理リポジトリ パターン2. GitHub Actionsに よるRun Command実⾏ パターン1. インスタンス 起動時のRun Command実⾏ push
OpsWorks利⽤状況 • OpsWorksを利⽤しているサーバー ◦ → 約14種類, 合計で100台程度 • 利⽤している機能 ◦
→ OSユーザ管理機能, デプロイ機能, API 16
旧系統サーバーアクセス経路 17 CMS コンテンツ配信ス テータス管理DB コンテンツ配信 サーバー コンテンツ管理 サーバー 本番アプリ⽤コンテンツ
データ(SQLite) プレビューアプリ⽤コン テンツデータ(SQLite) 本番アプリ プレビュー アプリ プロキシサーバー CMSバックエンド サーバー コンテンツ書き込み コンテンツ読み取り
コンテンツ反映時の挙動 18 CMS 本番アプリ プレビュー アプリ CMSバックエンド サーバー 5. redisに書き込まれた
値をデクリメントする 1. コンテンツ配信サーバの台数 (同期対象サーバー数)をredisに書 き込み反映処理をリクエストする 2. プレビュー⽤コンテンツデー タをコピーし本番⽤コンテンツ としてS3にアップロードする copy 3. データ同期命令を出す 本番コンテンツ 格納バケット 4. 本番⽤コンテンツ を上書きする コンテンツ反映中(=redisの値が0 でない)の場合は本番アプリのリ クエストもコンテンツ管理サー バーに向ける
OpsWorksのAPI利⽤箇所と課題 19 CMS 本番アプリ プレビュー アプリ CMSバックエンド サーバー 1. コンテンツ配信サーバの台数
(同期対象サーバー数)をredisに書 き込み反映処理をリクエストする 3. データ同期命令を出す OpsWorks APIを利⽤しコン テンツ配信サーバの情報 (サーバー数, プライベート DNS)を取得している コンテンツ配信 サーバー 配信サーバーのメンテナンス(サー バー停⽌)中にコンテンツ反映処理が ⾏われると常にコンテンツ管理サー バを向き続ける(redisの値が0になら ない)
代替ついでに改善 20 CMS 本番アプリ プレビュー アプリ CMSバックエンド サーバー 1. コンテンツ配信サーバの台数
(同期対象サーバー数)をredisに書 き込み反映処理をリクエストする 3. データ同期命令を出す EC2 APIを利⽤するように変 更しつつサーバの起動状態 も考慮するように改善 コンテンツ配信 サーバー OpsWorks APIを利⽤しコン テンツ配信サーバの情報 (サーバー数, プライベート DNS)を取得している 配信サーバーのメンテナンス(サー バー停⽌)中にコンテンツ反映処理が ⾏われると常にコンテンツ管理サー バを向き続ける(redisの値が0になら ない) 解決
OpsWorks廃⽌のハードル • OpsWorksの代替機能の検討 • 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任 分解) •
ブラックボックス & 影響範囲⼤ 21
SPOF & ステートフル 22 CMS コンテンツ配信ス テータス管理DB コンテンツ配信 サーバー コンテンツ管理
サーバー 本番アプリ⽤コンテンツ データ(SQLite) プレビューアプリ⽤コン テンツデータ(SQLite) 本番アプリ プレビュー アプリ プロキシサーバー CMSバックエンド サーバー SPOF & ステートフル ステートフル
SPOF & ステートフル 23 CMS コンテンツ配信ス テータス管理DB コンテンツ配信 サーバー コンテンツ管理
サーバー プレビューアプリ⽤コン テンツデータ(SQLite) 本番アプリ プレビュー アプリ プロキシサーバー CMSバックエンド サーバー SPOF & ステートフル ステートフル クライアント企業様に影響 が出るためメンテナンス⽇ 程の調整を早い段階で実施 ⼿順書を参考にデータの復 元⽅法を真似る(意味を理解 しながら)
責任分解が曖昧なサーバ 24 コンテンツ配信 サーバー 顧客システム連携⽤ APIサーバー 顧客システムA 顧客システムZ … 専任チームが主に管理しておりメン
テナンスなどもお任せできている ⼀⽅でAWSの専⾨的な知識はSREメ ンバーの⽅が詳しい
責任分解が曖昧なサーバ 25 コンテンツ配信 サーバー 顧客システム連携⽤ APIサーバー 顧客システムA 顧客システムZ … 誰が何をするか早めに合意
を取っておく 専任チームが主に管理しておりメン テナンスなどもお任せできている ⼀⽅でAWSの専⾨的な知識はSREメ ンバーの⽅が詳しい 全⼒で⽀援する(丸投げにし ない)
OpsWorks廃⽌のハードル • OpsWorksの代替機能の検討 • 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任 分解) •
ブラックボックス & 影響範囲⼤ 26
ミュータブルなサーバー 27 Ansible Playbook ⼿順書 OpsWorks インスタンス ALB SRE 作成した⼿順書に基づいてパッチ適
⽤を⾏ってきた サーバーに変更を加えた場合は Ansibleコードを追いつかせていた Ansibleコードを適⽤した後でALBの ターゲットグループに追加する サーバーに変更を加えた場合はAnsible コードを追いつかせていた サーバー追加時はこのAnsibleコードを 適⽤する 新規構築 パッチ適⽤ 本当に⼤丈夫?? (特にSPOFサーバのAnsibleコー ドの信頼性が低い)
AMIとAnsibleによるサーバー構築 28 OpsWorks インスタンス OpsWorks AMI 新AMI 新インスタンス 作業⽤ インスタンス
ALB Ansible Playbook AMI取得 作成 AMI取得 作成 適⽤ OpsWorksリソースの削除を ⾏う AMIにより基本的な作りを担保する (ベストではないがスピード優先での 判断) サーバ固有のパラメータは ansibleで担保する
慎重なデプロイ 29 OpsWorks インスタンス 新インスタンス ALB ⼿順書 ALB 新インスタンス 週次QA/⾃動化テストにより
動作の担保を⾏う ステージング環境 本番環境 ローリングデプロイとSLI/SLOに よるユーザ体験の変化の監視 ローリングデプロイとSLI/SLOに よるユーザ体験の変化の監視する ⼊れ替え後もしばらく残しておく 万が⼀の切り戻し⼿順も 載せておく
それでもインシデントは起きた • SPOFサーバーのメンテナンス作業が他プロダクトに影響 しインシデントを引き起こした ◦ 経験に頼った影響範囲の調査を⾏ってしまった ◦ → O11y強化, O11y向上委員会の発⾜
• SPOFサーバーの不具合調査⽤に残したインスタンスでも バッチ処理が⾛り重複処理によるインシデントが発⽣ 30
OpsWorks脱却に成功 31
モダン化への道 PHPアプリケーションの コンテナ化 32
OpsWorks脱却できたとはいえ... • EC2インスタンスは依然として残っている ◦ 運⽤⾯やセキュリティ⾯で⾟い • ステートフルな部分がありSPOFも残っている ◦ 冗⻑化が難しく可⽤性が低い ◦
コスト効率もあまりよくない 33
コンテナ化のハードル • PHP x コンテナの実績が社内でまだない • 開発環境の特殊構成を考慮する必要がある • 動作をどのように担保するか検討する必要がある 34
コンテナ化のハードル • PHP x コンテナの実績が社内でまだない • 開発環境の特殊構成を考慮する必要がある • 動作をどのように担保するか検討する必要がある 35
細かい粒度で地道に調査 • まずはステートレスなサーバから着⼿し実績を作る • それぞれについてどうすべきか地道に検討&調査し次回に 活かす ◦ ベースイメージ ◦ Dockerfile
◦ システム構成 ◦ パラメータチューニング ◦ CI/CD 36
コンテナ化のハードル • PHP x コンテナの実績が社内でまだない • 開発環境の特殊構成を考慮する必要がある • 動作をどのように担保するか検討する必要がある 37
dev-N dev-2 開発環境は特殊構成 38 モバイル バックエンド dev-1 EC2系のコンポーネントはすべ て同⼀サーバーに載っている hostsファイル
CMSバックエンド dev-2 モバイル バックエンド dev-1 hostsファイル CMSバックエンド dev-2 モバイル バックエンド dev-1 EC2系のコンポーネントはすべ て同⼀サーバーに載っている hostsファイル CMSバックエンド dev-2 メインサーバー dev-1 hostsファイル CMSバックエンド hostsで各コンポーネントに対 するリクエストをルーティング している
dev-N dev-2 別途最適な構成を考える 39 dev-1 Cloud Mapでdev環境ごとの namespaceを切り、名前解決 を⾏う CMSバックエンド
Cloud Map 切り出した コンポーネント メインサーバー トラフィック量が少ないため時 間課⾦のあるALBを前段に⼊れ ない
コンテナ化のハードル • PHP x コンテナの実績が社内でまだない • 開発環境の特殊構成を考慮する必要がある • 動作をどのように担保するか検討する必要がある 40
dev-N dev-2 どの機能で使われているか不明 41 dev-1 CMSバックエンド Cloud Map 切り出した コンポーネント
メインサーバー CMSでどのような操作をしたと きに実⾏されるのか、モバイル アプリでどのようなYappliの機 能が起動された時に実⾏される のか不明
地道に洗い出す 42 馴染みのない機能はQAチームに相談 → 実⾏契機や想定動作をユーザー⽬線 で記述していたため円滑なコミュニ ケーションができた 処理の概要, 実⾏契機, 想定動作を羅列
洗い出しには⽂明の利器を借りる 43 1. 分散トレーシングを活⽤し、どのようにしてエン ドポイントが叩かれるのかあたりをつける New Relic Tracing画⾯ 2. コードリーディングには⽣成AIの⼒を借りる
⼀部サーバーの コンテナ化完了の⾒込み 44
まとめ • OpsWorks廃⽌からコンテナ化への取り組みを紹介した • 10年も働いてくれたサーバーはブラックボックスな部分 も多いが地道にやっていくしかない • 最近はオブザーバビリティやAIといったテクノロジーの発 達により改善がだいぶ楽になった 45
ご清聴いただき ありがとうございました 46
47