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
Bref でサービスを運用している話
Search
Sugar Sato
March 25, 2026
Technology
230
0
Share
Bref でサービスを運用している話
@Verybest LT Night #1
Sugar Sato
March 25, 2026
More Decks by Sugar Sato
See All by Sugar Sato
AIと共に生きる技術選定 2026
sgash708
0
110
tool ディレクティブを導入してみた感想
sgash708
1
260
DeepWiki で Go をもっと好きになろう
sgash708
0
1k
環境変数ライブラリ選手権
sgash708
0
260
はじめての Go * WASM * OCR
sgash708
1
400
もう僕は OpenAPI を書きたくない
sgash708
6
2.6k
【懺悔】1年目 EM の失敗から学ぼう
sgash708
0
230
testcontainers のススメ
sgash708
1
500
「僕ら」のテストに対する向き合い方
sgash708
5
520
Other Decks in Technology
See All in Technology
Do Ruby::Box dream of Modular Monolith?
joker1007
1
360
AIが書いたコードを信じられない問題 〜レビュー負荷を下げるために変えたこと〜 / The AI Code Trust Gap: Reducing the Review Burden
bitkey
PRO
8
1.4k
基盤を育てる 外部SaaS連携の運用
gamonges_dresscode
1
120
データ定義の混乱と戦う 〜 管理会計と財務会計 〜
wonohe
0
150
CloudTrail を見つめ直してみる
kazzpapa3
1
120
AIコーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術(簡易版)
soysoysoyb
0
170
PyCon JPに学ぶ『決め方の決め方』: TechLead Conference 2026
terapyon
1
190
No Types Needed, Just Callable Method Check
dak2
1
2.2k
Shipping AI Agents — Lessons from Production
vvatanabe
0
290
今年注目する!データ分析プラットフォームでのAIの活用
nayuts
0
170
国内外の生成AIセキュリティの最新動向 & AIガードレール製品「chakoshi」のご紹介 / Latest Trends in Generative AI Security (Domestic & International) & Introduction to AI Guardrail Product "chakoshi"
nttcom
4
1.6k
M5Stack CoreS3とZephyr(RTOS)で Edge AIっぽいことしてみた
iotengineer22
0
380
Featured
See All Featured
Building Adaptive Systems
keathley
44
3k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
160
Automating Front-end Workflow
addyosmani
1370
200k
Chasing Engaging Ingredients in Design
codingconduct
0
180
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
70
39k
Design in an AI World
tapps
1
200
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Code Reviewing Like a Champion
maltzj
528
40k
The Pragmatic Product Professional
lauravandoore
37
7.2k
BBQ
matthewcrist
89
10k
Facilitating Awesome Meetings
lara
57
6.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.1k
Transcript
Date:2026.3.25 Bref でサービス運用している話 @Verybest LT Night #1
自己紹介 菅 直也 (@satoIsSugar) • Serverless • 植物 • アガベ
• ビカクシダ • 猫 • Lambda (♀4歳)
oralis は矯正歯科治療に特化した、クラウド型口腔内写真管理ソフトウェアです。 治療にとって重要な写真を管理するだけではなく、クリニックの経営管理にも役立ち ます。 oralis について 口腔内写真管理 経営管理 口腔内写真を時系列に配列することで、患者様だけではなく、 矯正医にとっても治療経過をわかりやすく管理が可能です。
現在クリニックに何人動的処置の方がいて、何人保定治療の方がいる のか?などクリニックの状態を数値で把握できるようになります
口腔内写真管理 6 患者さんだけではなく、 矯正医にとっても、見やすい設計 時系列に写真を配列することで、患者さんの治療の進 捗をわかりやすく把握・プレゼンできます
経営管理 7 クリニックの 現在状況をレポート 月々の来院数(相談数)動的治療中の人数、保定移行の患 者様の数を調べる事で、クリニックのキャパシティーを把握 できます
矯正治療に特化した仕様 8 症例検索に必要な分類が可能 類似症例や症例検討に役立つ、検索機能を実装 クリニックの資産である口腔内写真の価値を最大化します
資料作成機能 9 組写真の作成、印刷にも対応 過去から現在までの比較写真資料も簡単に作成可能です 5枚法、6枚法、口腔内・顔面写真などの組写真
ところで、この oralis 実はサーバーレスで動いています!
PHP でサーバーレス にチャレンジしたことありますか?
目次 01 Bref とは 02 なぜ Bref を選んだか 03 アーキテクチャ
04 構築と運用 05 コスト 06 メリット・デメリット 07 まとめ
01 Bref とは
• PHP を AWS Lambda で動かすための OSS フレームワーク • Lambda
Layer として PHP ランタイムを提供 • Laravel / Symfony をそのまま動かせる • serverless.yml で構成管理 • GitHub Stars: 4k+ Bref とは
• php-84-fpm ◦ Web API(FPM ベース、HTTP リクエスト処理) • php-84-console ◦
CLI(artisan コマンド実行) • php-84 ◦ Worker(SQS などのイベント処理) • 拡張レイヤーも提供(GD, Imagick 等) • Amazon Linux 2 / ECR イメージ対応 Bref が提供するランタイム
• EC2 / ECS ◦ サーバー管理必要 ◦ 常時課金 ◦ 運用負荷高め
• Bref (Lambda) ◦ サーバー管理不要 ◦ リクエスト単位課金 ◦ 運用負荷低め 従来の PHP ホスティング vs Bref
02 なぜ Bref を選んだか
少人数チームで 本番運用したい!
• チーム ◦ エンジニア少人数 • 既存資産 ◦ PHP (Laravel) のコードベース
• 課題 ◦ インフラ運用に割けるリソースがない • 要件 ◦ コストを抑えつつ本番運用したい 選定時の状況
• インフラの選択肢 ◦ EC2: 運用負荷 高 / コスト 中〜高 /
自由度 高 ◦ ECS Fargate: 運用負荷 中 / コスト 中 / 自由度 高 ◦ Lambda: 運用負荷 低 / コスト 低 / スケーリング自動 ◦ Lambda を選択 • Lambda 上の FW の選択肢 ◦ Laravel Vapor: 運用負荷 低 / 月$399〜 / Laravel公式 ◦ Bref: 運用負荷 低 / 無料(OSS) / 自由度 高 ◦ Bref を選択 選択肢の比較
• OSS で無料 — Vapor は月額 $399〜 • serverless.yml で完結
— インフラ定義がシンプル • Laravel がそのまま動く — コード変更最小限 • PHP ランタイムを選ぶだけ — 学習コスト低い • コミュニティが活発 — ドキュメント充実 Bref に決めた理由
• 基本的にコード変更は最小限で移行できる ◦ Bref Laravel Bridge が自動統合 → サービスプロバイダ追加不要 •
composer require bref/bref bref/laravel-bridge bref/extra-php-extensions • ストレージ ◦ デフォルトを S3 に変更(Lambda は読み取り専用) • キャッシュ・セッション ◦ database に変更(ファイル不可) • キュー ◦ SQS に変更 + Bref\LaravelBridge\Queue\QueueHandler • ログ ◦ stderr に出力(→ CloudWatch Logs) Bref 導入後の Laravel 側の対応
全体構成図
None
03 アーキテクチャ
• Web API ◦ php-84-fpm (ECR) ◦ タイムアウト 28秒 ◦
HTTP リクエスト処理 • Console ◦ php-84-console ◦ タイムアウト 720秒 ◦ artisan コマンド • Queue Worker ◦ php-84 + GD ◦ タイムアウト 300秒 ◦ 画像圧縮・変換 Lambda 関数は 3 種類
• Lambda × RDS の「コネクション爆発」問題 ◦ Lambda はリクエストごとにインスタンスが起動 • 同時接続数が一気に増える
• RDS の max_connections を超えてしまう ◦ RDS Proxy でコネクションをプーリングして回避 なぜ RDS Proxy?
• 2 つの User Pool で運用 ◦ Web User Pool
▪ クリニックユーザー向け(カスタム属性: clinic_id) ◦ Admin User Pool ▪ 管理者向け • Bearer トークンを Laravel ミドルウェアで検証 • clinic_id でデータのテナント分離 認証: AWS Cognito
• ユーザーが写真アップロード → API (Lambda) → S3 に保存 • PhotoCompressionJob
を SQS に投入 • Queue Worker (Lambda + GD) で処理 • 1MB 以上は JPEG 品質 25% に圧縮 • PNG/TIFF → JPEG 変換 • 圧縮済み画像を S3 に再保存 画像処理パイプライン
04 構築と運用
• provider ◦ aws / region: ap-northeast-1 • runtime ◦
provided.al2 (ECR Image) • VPC 内に配置(RDS アクセスのため) • api ◦ ECR イメージ / timeout 28s • console ◦ php-84-console / timeout 720s • jobs ◦ Queue Worker + GD Layer serverless.yml のポイント
None
• FROM bref/php-84-fpm • COPY --from=bref/extra-gd-php-84 /opt /opt • COPY
. /var/task • CMD ["public/index.php"] • たった 4 行で PHP 8.4 + GD の Lambda 環境が完成 Dockerfile
• GitHub push/tag → GitHub Actions • composer install --no-dev
• sls deploy --stage {env} • sls bref:cli --args="migrate --force" • Slack 通知 • staging ◦ ブランチ push で自動デプロイ • production ◦ タグで自動デプロイ デプロイフロー
• dev / stg / prod を 1 つの serverless.yml
で管理 • config.dev.yml ◦ APP_ENV: development • config.stg.yml ◦ APP_ENV: staging • config.prod.yml ◦ APP_ENV: production • 秘密情報: AWS SSM Parameter Store に格納 環境管理
• GD拡張の追加 ◦ brefphp/extra-php-extensions を Layer で追加 • Bref独自のphp.iniが存在 ◦
カスタムphp.iniが上書きされない • 自分のphp.iniを適用するには /opt/bref/etc/php/conf.d/ に配置 • ドキュメントが少なく手探りで解決 つらみ: PHP拡張とphp.ini
• Serverless Framework v4 がリリース(2024/05/22) ◦ CIが翌日から壊れた... ◦ Bref が
sls v4 に未対応だった ▪ v3 にダウングレード • serverless-lift(SQS構築に必要)も v3 依存 ◦ bref も lift も v4 未対応で、バージョン上げられない辛さ • frameworkVersion: '^3.28.1' でピン留めして運用中 つらみ: Serverless Framework v4 問題
• Dockerfile の配置場所 ◦ ./docker/bref/Dockerfile に置くとデプロイは成功するが、 COPYしたリソースにアクセスできない ◦ ルートに配置で解決 •
VPC 内 Lambda = NAT 必須 ◦ NAT Gatewayは高い... ◦ NAT Instance (t2.micro) でコスト削減 • タイムアウト設計 ◦ API Gateway 29秒 > Lambda 28秒にする ◦ 画像処理は Queue Worker に逃がす(最大 300秒) • コールドスタート ◦ ECR イメージは Layer より起動が遅い → 初回アクセスに注意 ハマりポイント
05 コスト
月額 $717(税込)の内訳 サービス 月額 備考 S3 $239.74 写真ストレージ Glue $104.56
写真エクスポート CloudFront $97.47 CDN RDS $97.03 MySQL Multi-AZ Tax $65.19 消費税 VPC $58.13 NAT Instance CloudWatch $28.44 ログ EC2 $21.39 NAT Instance / 踏み台 API Gateway $1.97 HTTP API Lambda $0 計上なし
Lambda のコスト:$0 API Gateway も $1.97 サーバーレスのコンピュート費用はほぼゼロ
サービス特性コスト vs インフラコスト 区分 金額 割合 サービス特性(S3 + Glue) $344
48% Tax $65 9% 純粋なインフラコスト $307 43%
06 メリット・デメリット
• コスト ◦ コンピュート費用がほぼゼロ • スケーリング ◦ トラフィック増減に自動対応 • 運用負荷
◦ サーバー管理不要、パッチ適用不要 • デプロイ ◦ sls deploy で完了、ロールバックも簡単 ▪ 中身は CloudFormation なのでわかりやすい • Laravel がそのまま動く ◦ コード変更最小限で移行可能 メリット
• コールドスタート ◦ 初回リクエストに数秒かかる • タイムアウト制約 ◦ API Gateway 29秒の壁
• VPC 内 Lambda = NAT 必須 ◦ NAT Instance でコスト軽減しているが外部通信には必要 • ローカル再現 ◦ Lambda 環境の完全再現は難しい → Docker Compose で代替 • デバッグ ◦ CloudWatch Logs ベース デメリット
07 まとめ
• PHP でもサーバーレスで本番運用できる(Bref + Laravel) • 少人数チーム*小規模プロダクトこそサーバーレス(インフラ運用を最 小化) • コンピュート費用はほぼ
$0(月 $307 で SaaS 運用) • トレードオフはある(コールドスタート、タイムアウト制約) まとめ
Date:2026.3.25