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
ゼロダウンタイムでミドルウェアの バージョンアップを実現した手法と課題
Search
つっつん
November 08, 2025
Programming
0
110
ゼロダウンタイムでミドルウェアの バージョンアップを実現した手法と課題
つっつん
November 08, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
JEP 496 と JEP 497 から学ぶ耐量子計算機暗号入門 / Learning Post-Quantum Crypto Basics from JEP 496 & 497
mackey0225
2
280
Atomics APIを知る / Understanding Atomics API
ssssota
1
150
例外処理を理解して、設計段階からエラーを見つけやすく、起こりにくく #phpconfuk
kajitack
12
5.9k
詳細の決定を遅らせつつ実装を早くする
shimabox
1
1k
開発生産性が組織文化になるまでの軌跡
tonegawa07
0
160
AsyncSequenceとAsyncStreamのプロポーザルを全部読む!!
s_shimotori
1
280
ネストしたdata classの面倒な更新にさようなら!Lensを作って理解するArrowのOpticsの世界
shiita0903
1
400
Rails Girls Sapporo 2ndの裏側―準備の日々から見えた、私が得たもの / SAPPORO ENGINEER BASE #11
lemonade_37
2
150
DartASTとその活用
sotaatos
2
130
自動テストのアーキテクチャとその理由ー大規模ゲーム開発の場合ー
segadevtech
2
1k
Building AI with AI
inesmontani
PRO
0
170
歴史から学ぶ「Why PHP?」 PHPを書く理由を改めて理解する / Learning from History: “Why PHP?” Rediscovering the Reasons for Writing PHP
seike460
PRO
0
160
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Faster Mobile Websites
deanohume
310
31k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
2.9k
Making Projects Easy
brettharned
120
6.5k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Gamification - CAS2011
davidbonilla
81
5.5k
Context Engineering - Making Every Token Count
addyosmani
10
390
The Cult of Friendly URLs
andyhume
79
6.7k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Mobile First: as difficult as doing things right
swwweet
225
10k
How to Think Like a Performance Engineer
csswizardry
28
2.3k
Transcript
2025年11月8日 PHPカンファレンス福岡2025 つっつん (@tsuttsun_wind) ゼロダウンタイムでミドルウェアの バージョンアップを実現した手法と課題
自己紹介 名前 : つっつん (X: @tsuttsun_wind) 所属 : 株式会社PR TIMES
領域 : バックエンド 趣味 : お酒、野球観戦、ダーツ カンファレンス初登壇です 🙇
検索リクエスト 検索結果返却 PR TIMES AWS OpenSearch Service 背景 PR TIMESの検索はOpenSearch上で運用されている
バージョンアップ前まで1.3で運用 1分間に平均約3,000回の検索リクエストが飛んでいる 数百万件のドキュメントを保管している ピーク時は1~3分間に約2500件のドキュメントが追加される
AWSからEOLのアナウンス 運用していたバージョンは対象外だが...? 将来のEOLリスクを見据えて、バージョンアップの実施を決定 3.1がリリースされているが、まずは2.19へ上げる 一気にバージョンを上げると変更が多くなる可能性があるため回避
移行にあたっての要件 本番環境のOpenSearchは停止させることが不可 検索機能や更新バッチなどのコア機能がOpenSearchに依存しているため そのため、ゼロダウンタイムでの移行が必要 また、既存で動いている機能のコード変更は、 インシデント発生時に切り戻しが大変になる 障害発生時には速やかにロールバック可能であることが求められる
:リクエスト : 切り替え 旧クラスター 新クラスター クライアント 方針 新クラスターを別途作成して少しずつ移行を進める 1.新旧クラスターの同時運用をしばらく実施する 2.障害発生時の影響を最小限にするため、範囲を限定した上で少しずつ
新クラスターへ切り替える 3.移行が完全に完了した時点で、旧クラスターを廃止する 追加のリソースが必要なため、余計にお金が掛かることに注意が必要
ユーザーを振り分ける仕組みを導入 ユーザー振り分け機能 特定ユーザーのみに移行先のクラスターを使用した検索を提供する ユーザーの振り分けはCookieで各ユーザーにランダムな数値を割り当て、 重みが下回っていたら新機能を提供 10%、20%...と段階的に解放していく 機能提供可否の確認 振り分け結果を返却 クライアント
ユーザーを振り分ける仕組み 割り当てられた数値と重みを比較した結果を返却する
Feature Flag Feature Flagを設定する Feature Flagでユーザー振り分けのオン・オフを管理、 CookieとIPアドレスを確認した上で機能の切り替えを行なっている 有効の場合、結果に応じて処理を分ける 無効の場合、既存の処理を維持する 問題が発生した場合は無効にすることでロールバックが可能
Flagのオン・オフ設定 Flagの状態で処理を分ける クライアント
Feature Flag
既存設計の問題点 インスタンスを直接生成するコードが数十箇所に存在している状態 何が問題? 宛先URLの引数に定数が直接入れられている 次回以降のバージョンアップでも対象コード全てを置き換える必要がある 参照元が多いため、コンストラクタの変更が困難 原因? 実装を参考にした結果コピペで増殖してしまった可能性が高い
既存設計を改善する Factory-Patternの導入 Clientクラスの呼び出しはFactory内で管理、将来的な変更はFactory内で完結 Cookie管理不可のバッチを除き、Feature Flagで切り替え可能
改善したコード 新たにFactory Classを追加、インスタンスの生成箇所は1箇所にまとめる PHPStanのCustom Rule導入も視野 Feature Flagは将来変更が必要な際に適宜導入する
運用時のパフォーマンス比較 移行元 移行先 ドキュメント登録量は変わらず、検索量は増加 ドキュメント処理速度は少々増加、検索処理速度はほぼ変わらず 左上: ドキュメント登録量 右上: 検索量 左下: ドキュメント処理速度 右下:
検索処理速度
結果 課題を解決しつつゼロダウンタイムでのミドルウェア移行を実現 🙌
まとめ 既存設計の課題を解決しつつ、ゼロダウンタイム移行の実現! 新クラスターを作成して少しずつの移行を実施 Feature Flag+ユーザ振り分けで“止めない・壊さない・すぐ戻せる”を実現 入口を1か所に固定させるFactoryを作成
We’re Hiring! カジュアル面談 開発者ブログ PR TIMESでは現在エンジニアを募集しています!