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
夏休みの(最後の)宿題 for JuliaTokyo #12
antimon2
0
130
エンジニア採用ノウハウ0から継続的な採用に至るまで / Try recruiting engineers
ohageeq
0
130
Envoy External AuthZとgRPC Extensionを利用した「頑張らない」Microservices認証認可基盤
andoshin11
0
140
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
160
New Relicで実践する外形監視
aeonpeople
1
120
標準最高!標準はださくないぞ! at fukuoka.ts #1
yoiwamoto
0
150
ログラスが面白いと思う理由をマネージャーがエモく語ってみる / 20240829 vs LT
yoshikiiida
1
520
[RSJ24] Object Segmentation from Open-Vocabulary Manipulation Instructions Based on Optimal Transport Polygon Matching with Foundation Models
keio_smilab
PRO
0
120
Dify - LINE Bot連携 考え方と実用テクニック
uezo
5
1.1k
AWS版GitHub?Amazon CodeCatalystの全体像をまとめてみた
oshanqq
1
3.2k
Azure SQL Database Hyperscale HA レプリカの監視
sansantech
PRO
0
190
Estrategias de escalabilidade para projetos web
jessilyneh
1
150
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
294
20k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
Writing Fast Ruby
sferik
623
60k
A Modern Web Designer's Workflow
chriscoyier
690
190k
The Pragmatic Product Professional
lauravandoore
30
6.2k
Atom: Resistance is Futile
akmur
261
25k
Scaling GitHub
holman
458
140k
Git: the NoSQL Database
bkeepers
PRO
425
64k
GitHub's CSS Performance
jonrohan
1029
450k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
354
29k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
278
13k
BBQ
matthewcrist
83
9.1k
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