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
280
累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却とモダン化への道
kmitsuhashi
July 17, 2024
Tweet
Share
More Decks by kmitsuhashi
See All by kmitsuhashi
ヤプリにおけるAWSコスト最適化の取り組み
kmitsuhashi
0
510
Other Decks in Technology
See All in Technology
現実のRuby/Railsアップグレード
takeyuweb
3
2.8k
Aurora_BlueGreenDeploymentsやってみた
tsukasa_ishimaru
1
110
クラシルの現在とこれから
am1157154
1
320
DevOpsに関連するツールとその概要を淡々と読み上げる会
devops_vtj
1
140
ZOZOのデータマネジメントの取り組み:これまでとこれから / ZOZO's Data Management Initiatives
takagiyudai
0
540
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
snoozer05
PRO
2
2.9k
サーバーサイドのデータプレーンプログラミング 〜 NVIDIA Blue Field / DOCA 〜
ebiken
PRO
1
220
AWS Step Functionsのタスク入出力に秩序を与えよう
y_kotani
0
180
いまからでも遅くない!コンテナでWebアプリを動かしてみよう入門(2-2)WebAPIハンズオン
nomu
0
150
What's in a Postgres major release? An analysis of contributions in the v17 timeframe | Claire Giordano | PGConf EU 2024
clairegiordano
1
660
JPOUG_10_20241018_OracleDB_AWS_v1.3.pdf
asahihidehiko
1
240
日経ビジュアルデータにおける スクロールテリングと地図/nikkei-tech-talk-26
nikkei_engineer_recruiting
0
150
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
32
2.9k
Music & Morning Musume
bryan
46
6.1k
Automating Front-end Workflow
addyosmani
1365
200k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
How GitHub (no longer) Works
holman
311
140k
Testing 201, or: Great Expectations
jmmastey
38
7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Writing Fast Ruby
sferik
626
60k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Designing on Purpose - Digital PM Summit 2013
jponch
114
6.9k
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