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
380
累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却とモダン化への道
kmitsuhashi
July 17, 2024
Tweet
Share
More Decks by kmitsuhashi
See All by kmitsuhashi
ヤプリにおけるAWSコスト最適化の取り組み
kmitsuhashi
0
620
Other Decks in Technology
See All in Technology
エンジニアとしてプロダクトマネジメントに向き合った1年半
sansantech
PRO
0
100
生成AIを活用した機能を、顧客に提供するまでに乗り越えた『4つの壁』
toshiblues
1
210
ソフトウェア開発現代史:製造業とソフトウェアは本当に共存できていたのか?品質とスピードを問い直す
takabow
15
5.3k
企業テックブログにおける執筆ネタの考え方・見つけ方・広げ方 / How to Think of, Find, and Expand Writing Topics for Corporate Tech Blogs
honyanya
0
820
第27回クラウド女子会 ~re:Invent 振り返りLT会~ 宣言型ポリシー、使ってみたらこうだった!
itkr2305
0
290
HCP TerraformとAzure:イオンスマートテクノロジーのインフラ革新 / HCP Terraform and Azure AEON Smart Technology's Infrastructure Innovation
aeonpeople
3
990
ChatGPTを使ったブログ執筆と校正の実践テクニック/登壇資料(井田 献一朗)
hacobu
1
160
あなたの興味は信頼性?それとも生産性? SREとしてのキャリアに悩むみなさまに伝えたい選択肢
jacopen
6
3.3k
日本語プログラミングとSpring Bootアプリケーション開発 #kanjava
yusuke
2
340
Redmineの意外と知らない便利機能 (Redmine 6.0対応版)
vividtone
0
190
あなたはJVMの気持ちを理解できるか?
skrb
5
2k
【Λ(らむだ)】アップデート機能振り返りΛ編 / PADjp20250127
lambda
0
120
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
39
1.9k
Faster Mobile Websites
deanohume
305
30k
Scaling GitHub
holman
459
140k
GraphQLとの向き合い方2022年版
quramy
44
13k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
BBQ
matthewcrist
85
9.4k
Agile that works and the tools we love
rasmusluckow
328
21k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
KATA
mclloyd
29
14k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
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