$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ゼロダウンタイムでミドルウェアの バージョンアップを実現した手法と課題
Search
つっつん
November 08, 2025
Programming
0
250
ゼロダウンタイムでミドルウェアの バージョンアップを実現した手法と課題
つっつん
November 08, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
tparseでgo testの出力を見やすくする
utgwkk
1
130
AIエージェントを活かすPM術 AI駆動開発の現場から
gyuta
0
230
Level up your Gemini CLI - D&D Style!
palladius
1
170
無秩序からの脱却 / Emergence from chaos
nrslib
2
12k
非同期処理の迷宮を抜ける: 初学者がつまづく構造的な原因
pd1xx
1
570
なあ兄弟、 余白の意味を考えてから UI実装してくれ!
ktcryomm
10
11k
新卒エンジニアのプルリクエスト with AI駆動
fukunaga2025
0
140
認証・認可の基本を学ぼう前編
kouyuume
0
150
【Streamlit x Snowflake】データ基盤からアプリ開発・AI活用まで、すべてをSnowflake内で実現
ayumu_yamaguchi
1
110
Reactive Thinking with Signals and the new Resource API
manfredsteyer
PRO
0
160
全員アーキテクトで挑む、 巨大で高密度なドメインの紐解き方
agatan
8
18k
Herb to ReActionView: A New Foundation for the View Layer @ San Francisco Ruby Conference 2025
marcoroth
0
240
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1371
200k
Site-Speed That Sticks
csswizardry
13
990
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Build The Right Thing And Hit Your Dates
maggiecrowley
38
3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Unsuck your backbone
ammeep
671
58k
Leading Effective Engineering Teams in the AI Era
addyosmani
8
1.2k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
120
20k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
31
2.7k
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では現在エンジニアを募集しています!