累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却とモダン化への道

Transcript

1. 累計ダウンロード数1億8000万を超える アプリケーションプラットフォームの レガシーシステム脱却とモダン化への道 2024/7/16 株式会社ヤプリ 三橋
2. Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い
3. ⾃⼰紹介 3 三橋 奎太 / Keita Mitsuhashi • 株式会社ヤプリ SREチーム所属 • SIer → ヤプリ(2022/4⼊社) • New Relic⼤好き
4. 提供サービス 4 ノーコードモバイル アプリケーション プラットフォーム ノーコード顧客管理 システム 今回の発表はこちらの内容
5. ⽬次 • レガシー脱却 OpsWorksの廃⽌ • モダン化への道 PHPアプリケーションのコンテナ化 5
6. レガシー脱却 OpsWorksの廃⽌ 6
7. ざっくりバックエンド構成 • 旧系統はPHP x EC2(OpsWorks)の構成 • 新系統はGolang x ECS/Fargateの構成 7 プラットフォームという性質上、 すべての機能を新系統に移⾏するには時間がかかる
8. OpsWorks終了のお知らせ 8 この通知は、AWS OpsWorks スタックリソースを 1 つ以上あるお客様に配信 しております。AWS OpsWorks スタックを 2024 年 5 月 26 日に廃止すること をお知らせする連絡を差し上げています。2023 年 5 月 26 日以降、新規のお 客様はこのサービスをご利用いただけなくなります。既存のアカウントは、 2024 年 5 月 26 日まで通常どおりサービスを利用できます。2024 年 5 月 26 日以降、お客様は OpsWorks コンソール、 API、CLI、および CloudFormation リソースを使用できなくなります。
9. OpsWorks廃⽌のハードル • OpsWorksの代替機能の検討 • 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任 分解) • ブラックボックス & 影響範囲⼤ 9
10. OpsWorks廃⽌のハードル • OpsWorksの代替機能の検討 • 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任 分解) • ブラックボックス & 影響範囲⼤ 10
11. OpsWorks利⽤状況 • OpsWorksを利⽤しているサーバー ◦ → 約14種類, 合計で100台程度 • 利⽤している機能 ◦ → OSユーザ管理機能, デプロイ機能, API 11
12. OpsWorks利⽤状況 • OpsWorksを利⽤しているサーバー ◦ → 約14種類, 合計で100台程度 • 利⽤している機能 ◦ → OSユーザ管理機能, デプロイ機能, API 12
13. OSユーザ管理機能の代替 13 管理者 EC2 CSV S3 terraform applyで CSVアップロード SSM Documentによる OSユーザ同期 パターン2. Run Command実⾏ (⼿動) パターン1. インスタンス起 動時のRun Command実⾏ (⾃動)
14. OpsWorks利⽤状況 • OpsWorksを利⽤しているサーバー ◦ → 約14種類, 合計で100台程度 • 利⽤している機能 ◦ → OSユーザ管理機能, デプロイ機能, API 14
15. デプロイ機能の代替 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
16. OpsWorks利⽤状況 • OpsWorksを利⽤しているサーバー ◦ → 約14種類, 合計で100台程度 • 利⽤している機能 ◦ → OSユーザ管理機能, デプロイ機能, API 16
17. 旧系統サーバーアクセス経路 17 CMS コンテンツ配信ス テータス管理DB コンテンツ配信 サーバー コンテンツ管理 サーバー 本番アプリ⽤コンテンツ データ(SQLite) プレビューアプリ⽤コン テンツデータ(SQLite) 本番アプリ プレビュー アプリ プロキシサーバー CMSバックエンド サーバー コンテンツ書き込み コンテンツ読み取り
18. コンテンツ反映時の挙動 18 CMS 本番アプリ プレビュー アプリ CMSバックエンド サーバー 5. redisに書き込まれた 値をデクリメントする 1. コンテンツ配信サーバの台数 (同期対象サーバー数)をredisに書 き込み反映処理をリクエストする 2. プレビュー⽤コンテンツデー タをコピーし本番⽤コンテンツ としてS3にアップロードする copy 3. データ同期命令を出す 本番コンテンツ 格納バケット 4. 本番⽤コンテンツ を上書きする コンテンツ反映中(=redisの値が0 でない)の場合は本番アプリのリ クエストもコンテンツ管理サー バーに向ける
19. OpsWorksのAPI利⽤箇所と課題 19 CMS 本番アプリ プレビュー アプリ CMSバックエンド サーバー 1. コンテンツ配信サーバの台数 (同期対象サーバー数)をredisに書 き込み反映処理をリクエストする 3. データ同期命令を出す OpsWorks APIを利⽤しコン テンツ配信サーバの情報 (サーバー数, プライベート DNS)を取得している コンテンツ配信 サーバー 配信サーバーのメンテナンス(サー バー停⽌)中にコンテンツ反映処理が ⾏われると常にコンテンツ管理サー バを向き続ける(redisの値が0になら ない)
20. 代替ついでに改善 20 CMS 本番アプリ プレビュー アプリ CMSバックエンド サーバー 1. コンテンツ配信サーバの台数 (同期対象サーバー数)をredisに書 き込み反映処理をリクエストする 3. データ同期命令を出す EC2 APIを利⽤するように変 更しつつサーバの起動状態 も考慮するように改善 コンテンツ配信 サーバー OpsWorks APIを利⽤しコン テンツ配信サーバの情報 (サーバー数, プライベート DNS)を取得している 配信サーバーのメンテナンス(サー バー停⽌)中にコンテンツ反映処理が ⾏われると常にコンテンツ管理サー バを向き続ける(redisの値が0になら ない) 解決
21. OpsWorks廃⽌のハードル • OpsWorksの代替機能の検討 • 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任 分解) • ブラックボックス & 影響範囲⼤ 21
22. SPOF & ステートフル 22 CMS コンテンツ配信ス テータス管理DB コンテンツ配信 サーバー コンテンツ管理 サーバー 本番アプリ⽤コンテンツ データ(SQLite) プレビューアプリ⽤コン テンツデータ(SQLite) 本番アプリ プレビュー アプリ プロキシサーバー CMSバックエンド サーバー SPOF & ステートフル ステートフル
23. SPOF & ステートフル 23 CMS コンテンツ配信ス テータス管理DB コンテンツ配信 サーバー コンテンツ管理 サーバー プレビューアプリ⽤コン テンツデータ(SQLite) 本番アプリ プレビュー アプリ プロキシサーバー CMSバックエンド サーバー SPOF & ステートフル ステートフル クライアント企業様に影響 が出るためメンテナンス⽇ 程の調整を早い段階で実施 ⼿順書を参考にデータの復 元⽅法を真似る(意味を理解 しながら)
24. 責任分解が曖昧なサーバ 24 コンテンツ配信 サーバー 顧客システム連携⽤ APIサーバー 顧客システムA 顧客システムZ … 専任チームが主に管理しておりメン テナンスなどもお任せできている ⼀⽅でAWSの専⾨的な知識はSREメ ンバーの⽅が詳しい
25. 責任分解が曖昧なサーバ 25 コンテンツ配信 サーバー 顧客システム連携⽤ APIサーバー 顧客システムA 顧客システムZ … 誰が何をするか早めに合意 を取っておく 専任チームが主に管理しておりメン テナンスなどもお任せできている ⼀⽅でAWSの専⾨的な知識はSREメ ンバーの⽅が詳しい 全⼒で⽀援する(丸投げにし ない)
26. OpsWorks廃⽌のハードル • OpsWorksの代替機能の検討 • 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任 分解) • ブラックボックス & 影響範囲⼤ 26
27. ミュータブルなサーバー 27 Ansible Playbook ⼿順書 OpsWorks インスタンス ALB SRE 作成した⼿順書に基づいてパッチ適 ⽤を⾏ってきた サーバーに変更を加えた場合は Ansibleコードを追いつかせていた Ansibleコードを適⽤した後でALBの ターゲットグループに追加する サーバーに変更を加えた場合はAnsible コードを追いつかせていた サーバー追加時はこのAnsibleコードを 適⽤する 新規構築 パッチ適⽤ 本当に⼤丈夫？？ (特にSPOFサーバのAnsibleコー ドの信頼性が低い)
28. AMIとAnsibleによるサーバー構築 28 OpsWorks インスタンス OpsWorks AMI 新AMI 新インスタンス 作業⽤ インスタンス ALB Ansible Playbook AMI取得 作成 AMI取得 作成 適⽤ OpsWorksリソースの削除を ⾏う AMIにより基本的な作りを担保する (ベストではないがスピード優先での 判断) サーバ固有のパラメータは ansibleで担保する
29. 慎重なデプロイ 29 OpsWorks インスタンス 新インスタンス ALB ⼿順書 ALB 新インスタンス 週次QA/⾃動化テストにより 動作の担保を⾏う ステージング環境 本番環境 ローリングデプロイとSLI/SLOに よるユーザ体験の変化の監視 ローリングデプロイとSLI/SLOに よるユーザ体験の変化の監視する ⼊れ替え後もしばらく残しておく 万が⼀の切り戻し⼿順も 載せておく
30. それでもインシデントは起きた • SPOFサーバーのメンテナンス作業が他プロダクトに影響 しインシデントを引き起こした ◦ 経験に頼った影響範囲の調査を⾏ってしまった ◦ → O11y強化, O11y向上委員会の発⾜ • SPOFサーバーの不具合調査⽤に残したインスタンスでも バッチ処理が⾛り重複処理によるインシデントが発⽣ 30
31. OpsWorks脱却に成功 31
32. モダン化への道 PHPアプリケーションの コンテナ化 32
33. OpsWorks脱却できたとはいえ... • EC2インスタンスは依然として残っている ◦ 運⽤⾯やセキュリティ⾯で⾟い • ステートフルな部分がありSPOFも残っている ◦ 冗⻑化が難しく可⽤性が低い ◦ コスト効率もあまりよくない 33
34. コンテナ化のハードル • PHP x コンテナの実績が社内でまだない • 開発環境の特殊構成を考慮する必要がある • 動作をどのように担保するか検討する必要がある 34
35. コンテナ化のハードル • PHP x コンテナの実績が社内でまだない • 開発環境の特殊構成を考慮する必要がある • 動作をどのように担保するか検討する必要がある 35
36. 細かい粒度で地道に調査 • まずはステートレスなサーバから着⼿し実績を作る • それぞれについてどうすべきか地道に検討&調査し次回に 活かす ◦ ベースイメージ ◦ Dockerfile ◦ システム構成 ◦ パラメータチューニング ◦ CI/CD 36
37. コンテナ化のハードル • PHP x コンテナの実績が社内でまだない • 開発環境の特殊構成を考慮する必要がある • 動作をどのように担保するか検討する必要がある 37
38. 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で各コンポーネントに対 するリクエストをルーティング している
39. dev-N dev-2 別途最適な構成を考える 39 dev-1 Cloud Mapでdev環境ごとの namespaceを切り、名前解決 を⾏う CMSバックエンド Cloud Map 切り出した コンポーネント メインサーバー トラフィック量が少ないため時 間課⾦のあるALBを前段に⼊れ ない
40. コンテナ化のハードル • PHP x コンテナの実績が社内でまだない • 開発環境の特殊構成を考慮する必要がある • 動作をどのように担保するか検討する必要がある 40
41. dev-N dev-2 どの機能で使われているか不明 41 dev-1 CMSバックエンド Cloud Map 切り出した コンポーネント メインサーバー CMSでどのような操作をしたと きに実⾏されるのか、モバイル アプリでどのようなYappliの機 能が起動された時に実⾏される のか不明
42. 地道に洗い出す 42 馴染みのない機能はQAチームに相談 → 実⾏契機や想定動作をユーザー⽬線 で記述していたため円滑なコミュニ ケーションができた 処理の概要, 実⾏契機, 想定動作を羅列
43. 洗い出しには⽂明の利器を借りる 43 1. 分散トレーシングを活⽤し、どのようにしてエン ドポイントが叩かれるのかあたりをつける New Relic Tracing画⾯ 2. コードリーディングには⽣成AIの⼒を借りる
44. ⼀部サーバーの コンテナ化完了の⾒込み 44
45. まとめ • OpsWorks廃⽌からコンテナ化への取り組みを紹介した • 10年も働いてくれたサーバーはブラックボックスな部分 も多いが地道にやっていくしかない • 最近はオブザーバビリティやAIといったテクノロジーの発 達により改善がだいぶ楽になった 45
46. ご清聴いただき ありがとうございました 46