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

by kmitsuhashi

Slide 1

Slide 1 text

累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却とモダン化への道 2024/7/16 株式会社ヤプリ三橋

Slide 2

Slide 2 text

Xへの投稿の際は、ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い

Slide 3

Slide 3 text

⾃⼰紹介 3 三橋奎太 / Keita Mitsuhashi ● 株式会社ヤプリ SREチーム所属 ● SIer → ヤプリ(2022/4⼊社) ● New Relic⼤好き

Slide 4

Slide 4 text

提供サービス 4 ノーコードモバイルアプリケーションプラットフォームノーコード顧客管理システム今回の発表はこちらの内容

Slide 5

Slide 5 text

⽬次 ● レガシー脱却 OpsWorksの廃⽌ ● モダン化への道 PHPアプリケーションのコンテナ化 5

Slide 6

Slide 6 text

レガシー脱却 OpsWorksの廃⽌ 6

Slide 7

Slide 7 text

ざっくりバックエンド構成 ● 旧系統はPHP x EC2(OpsWorks)の構成 ● 新系統はGolang x ECS/Fargateの構成 7 プラットフォームという性質上、すべての機能を新系統に移⾏するには時間がかかる

Slide 8

Slide 8 text

OpsWorks終了のお知らせ 8 この通知は、AWS OpsWorks スタックリソースを 1 つ以上あるお客様に配信しております。AWS OpsWorks スタックを 2024 年 5 月 26 日に廃止することをお知らせする連絡を差し上げています。2023 年 5 月 26 日以降、新規のお客様はこのサービスをご利用いただけなくなります。既存のアカウントは、 2024 年 5 月 26 日まで通常どおりサービスを利用できます。2024 年 5 月 26 日以降、お客様は OpsWorks コンソール、 API、CLI、および CloudFormation リソースを使用できなくなります。

Slide 9

Slide 9 text

OpsWorks廃⽌のハードル ● OpsWorksの代替機能の検討 ● 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任分解) ● ブラックボックス & 影響範囲⼤ 9

Slide 10

Slide 10 text

OpsWorks廃⽌のハードル ● OpsWorksの代替機能の検討 ● 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任分解) ● ブラックボックス & 影響範囲⼤ 10

Slide 11

Slide 11 text

OpsWorks利⽤状況 ● OpsWorksを利⽤しているサーバー ○ → 約14種類, 合計で100台程度 ● 利⽤している機能 ○ → OSユーザ管理機能, デプロイ機能, API 11

Slide 12

Slide 12 text

OpsWorks利⽤状況 ● OpsWorksを利⽤しているサーバー ○ → 約14種類, 合計で100台程度 ● 利⽤している機能 ○ → OSユーザ管理機能, デプロイ機能, API 12

Slide 13

Slide 13 text

OSユーザ管理機能の代替 13 管理者 EC2 CSV S3 terraform applyで CSVアップロード SSM Documentによる OSユーザ同期パターン2. Run Command実⾏ (⼿動) パターン1. インスタンス起動時のRun Command実⾏ (⾃動)

Slide 14

Slide 14 text

OpsWorks利⽤状況 ● OpsWorksを利⽤しているサーバー ○ → 約14種類, 合計で100台程度 ● 利⽤している機能 ○ → OSユーザ管理機能, デプロイ機能, API 14

Slide 15

Slide 15 text

デプロイ機能の代替 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

Slide 16

Slide 16 text

OpsWorks利⽤状況 ● OpsWorksを利⽤しているサーバー ○ → 約14種類, 合計で100台程度 ● 利⽤している機能 ○ → OSユーザ管理機能, デプロイ機能, API 16

Slide 17

Slide 17 text

旧系統サーバーアクセス経路 17 CMS コンテンツ配信ステータス管理DB コンテンツ配信サーバーコンテンツ管理サーバー本番アプリ⽤コンテンツデータ(SQLite) プレビューアプリ⽤コンテンツデータ(SQLite) 本番アプリプレビューアプリプロキシサーバー CMSバックエンドサーバーコンテンツ書き込みコンテンツ読み取り

Slide 18

Slide 18 text

コンテンツ反映時の挙動 18 CMS 本番アプリプレビューアプリ CMSバックエンドサーバー 5. redisに書き込まれた値をデクリメントする 1. コンテンツ配信サーバの台数 (同期対象サーバー数)をredisに書き込み反映処理をリクエストする 2. プレビュー⽤コンテンツデータをコピーし本番⽤コンテンツとしてS3にアップロードする copy 3. データ同期命令を出す本番コンテンツ格納バケット 4. 本番⽤コンテンツを上書きするコンテンツ反映中(=redisの値が0 でない)の場合は本番アプリのリクエストもコンテンツ管理サーバーに向ける

Slide 19

Slide 19 text

OpsWorksのAPI利⽤箇所と課題 19 CMS 本番アプリプレビューアプリ CMSバックエンドサーバー 1. コンテンツ配信サーバの台数 (同期対象サーバー数)をredisに書き込み反映処理をリクエストする 3. データ同期命令を出す OpsWorks APIを利⽤しコンテンツ配信サーバの情報 (サーバー数, プライベート DNS)を取得しているコンテンツ配信サーバー配信サーバーのメンテナンス(サーバー停⽌)中にコンテンツ反映処理が⾏われると常にコンテンツ管理サーバを向き続ける(redisの値が0にならない)

Slide 20

Slide 20 text

代替ついでに改善 20 CMS 本番アプリプレビューアプリ CMSバックエンドサーバー 1. コンテンツ配信サーバの台数 (同期対象サーバー数)をredisに書き込み反映処理をリクエストする 3. データ同期命令を出す EC2 APIを利⽤するように変更しつつサーバの起動状態も考慮するように改善コンテンツ配信サーバー OpsWorks APIを利⽤しコンテンツ配信サーバの情報 (サーバー数, プライベート DNS)を取得している配信サーバーのメンテナンス(サーバー停⽌)中にコンテンツ反映処理が⾏われると常にコンテンツ管理サーバを向き続ける(redisの値が0にならない) 解決

Slide 21

Slide 21 text

OpsWorks廃⽌のハードル ● OpsWorksの代替機能の検討 ● 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任分解) ● ブラックボックス & 影響範囲⼤ 21

Slide 22

Slide 22 text

SPOF & ステートフル 22 CMS コンテンツ配信ステータス管理DB コンテンツ配信サーバーコンテンツ管理サーバー本番アプリ⽤コンテンツデータ(SQLite) プレビューアプリ⽤コンテンツデータ(SQLite) 本番アプリプレビューアプリプロキシサーバー CMSバックエンドサーバー SPOF & ステートフルステートフル

Slide 23

Slide 23 text

SPOF & ステートフル 23 CMS コンテンツ配信ステータス管理DB コンテンツ配信サーバーコンテンツ管理サーバープレビューアプリ⽤コンテンツデータ(SQLite) 本番アプリプレビューアプリプロキシサーバー CMSバックエンドサーバー SPOF & ステートフルステートフルクライアント企業様に影響が出るためメンテナンス⽇程の調整を早い段階で実施⼿順書を参考にデータの復元⽅法を真似る(意味を理解しながら)

Slide 24

Slide 24 text

責任分解が曖昧なサーバ 24 コンテンツ配信サーバー顧客システム連携⽤ APIサーバー顧客システムA 顧客システムZ … 専任チームが主に管理しておりメンテナンスなどもお任せできている⼀⽅でAWSの専⾨的な知識はSREメンバーの⽅が詳しい

Slide 25

Slide 25 text

責任分解が曖昧なサーバ 25 コンテンツ配信サーバー顧客システム連携⽤ APIサーバー顧客システムA 顧客システムZ … 誰が何をするか早めに合意を取っておく専任チームが主に管理しておりメンテナンスなどもお任せできている⼀⽅でAWSの専⾨的な知識はSREメンバーの⽅が詳しい全⼒で⽀援する(丸投げにしない)

Slide 26

Slide 26 text

OpsWorks廃⽌のハードル ● OpsWorksの代替機能の検討 ● 特性の異なるサーバー (ステートフル, SPOF, 曖昧な責任分解) ● ブラックボックス & 影響範囲⼤ 26

Slide 27

Slide 27 text

ミュータブルなサーバー 27 Ansible Playbook ⼿順書 OpsWorks インスタンス ALB SRE 作成した⼿順書に基づいてパッチ適⽤を⾏ってきたサーバーに変更を加えた場合は Ansibleコードを追いつかせていた Ansibleコードを適⽤した後でALBのターゲットグループに追加するサーバーに変更を加えた場合はAnsible コードを追いつかせていたサーバー追加時はこのAnsibleコードを適⽤する新規構築パッチ適⽤本当に⼤丈夫？？ (特にSPOFサーバのAnsibleコードの信頼性が低い)

Slide 28

Slide 28 text

AMIとAnsibleによるサーバー構築 28 OpsWorks インスタンス OpsWorks AMI 新AMI 新インスタンス作業⽤インスタンス ALB Ansible Playbook AMI取得作成 AMI取得作成適⽤ OpsWorksリソースの削除を⾏う AMIにより基本的な作りを担保する (ベストではないがスピード優先での判断) サーバ固有のパラメータは ansibleで担保する

Slide 29

Slide 29 text

慎重なデプロイ 29 OpsWorks インスタンス新インスタンス ALB ⼿順書 ALB 新インスタンス週次QA/⾃動化テストにより動作の担保を⾏うステージング環境本番環境ローリングデプロイとSLI/SLOによるユーザ体験の変化の監視ローリングデプロイとSLI/SLOによるユーザ体験の変化の監視する⼊れ替え後もしばらく残しておく万が⼀の切り戻し⼿順も載せておく

Slide 30

Slide 30 text

それでもインシデントは起きた ● SPOFサーバーのメンテナンス作業が他プロダクトに影響しインシデントを引き起こした ○ 経験に頼った影響範囲の調査を⾏ってしまった ○ → O11y強化, O11y向上委員会の発⾜ ● SPOFサーバーの不具合調査⽤に残したインスタンスでもバッチ処理が⾛り重複処理によるインシデントが発⽣ 30

Slide 31

Slide 31 text

OpsWorks脱却に成功 31

Slide 32

Slide 32 text

モダン化への道 PHPアプリケーションのコンテナ化 32

Slide 33

Slide 33 text

OpsWorks脱却できたとはいえ... ● EC2インスタンスは依然として残っている ○ 運⽤⾯やセキュリティ⾯で⾟い ● ステートフルな部分がありSPOFも残っている ○ 冗⻑化が難しく可⽤性が低い ○ コスト効率もあまりよくない 33

Slide 34

Slide 34 text

コンテナ化のハードル ● PHP x コンテナの実績が社内でまだない ● 開発環境の特殊構成を考慮する必要がある ● 動作をどのように担保するか検討する必要がある 34

Slide 35

Slide 35 text

コンテナ化のハードル ● PHP x コンテナの実績が社内でまだない ● 開発環境の特殊構成を考慮する必要がある ● 動作をどのように担保するか検討する必要がある 35

Slide 36

Slide 36 text

細かい粒度で地道に調査 ● まずはステートレスなサーバから着⼿し実績を作る ● それぞれについてどうすべきか地道に検討&調査し次回に活かす ○ ベースイメージ ○ Dockerﬁle ○ システム構成 ○ パラメータチューニング ○ CI/CD 36

Slide 37

Slide 37 text

コンテナ化のハードル ● PHP x コンテナの実績が社内でまだない ● 開発環境の特殊構成を考慮する必要がある ● 動作をどのように担保するか検討する必要がある 37

Slide 38

Slide 38 text

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で各コンポーネントに対するリクエストをルーティングしている

Slide 39

Slide 39 text

dev-N dev-2 別途最適な構成を考える 39 dev-1 Cloud Mapでdev環境ごとの namespaceを切り、名前解決を⾏う CMSバックエンド Cloud Map 切り出したコンポーネントメインサーバートラフィック量が少ないため時間課⾦のあるALBを前段に⼊れない

Slide 40

Slide 40 text

コンテナ化のハードル ● PHP x コンテナの実績が社内でまだない ● 開発環境の特殊構成を考慮する必要がある ● 動作をどのように担保するか検討する必要がある 40

Slide 41

Slide 41 text

dev-N dev-2 どの機能で使われているか不明 41 dev-1 CMSバックエンド Cloud Map 切り出したコンポーネントメインサーバー CMSでどのような操作をしたときに実⾏されるのか、モバイルアプリでどのようなYappliの機能が起動された時に実⾏されるのか不明

Slide 42

Slide 42 text

地道に洗い出す 42 馴染みのない機能はQAチームに相談 → 実⾏契機や想定動作をユーザー⽬線で記述していたため円滑なコミュニケーションができた処理の概要, 実⾏契機, 想定動作を羅列

Slide 43

Slide 43 text

洗い出しには⽂明の利器を借りる 43 1. 分散トレーシングを活⽤し、どのようにしてエンドポイントが叩かれるのかあたりをつける New Relic Tracing画⾯ 2. コードリーディングには⽣成AIの⼒を借りる

Slide 44

Slide 44 text

⼀部サーバーのコンテナ化完了の⾒込み 44

Slide 45

Slide 45 text

まとめ ● OpsWorks廃⽌からコンテナ化への取り組みを紹介した ● 10年も働いてくれたサーバーはブラックボックスな部分も多いが地道にやっていくしかない ● 最近はオブザーバビリティやAIといったテクノロジーの発達により改善がだいぶ楽になった 45