PHPカンファレンス 2017に参加してきた
参加してきました。
その時の雑な自分用メモを公開します。
OPCacheの最適化器の最適化
OPCacheの機能
バイトコードの最適化
Lancersバージョンアップ
お姉さんが動いた!
目をつぶっていたNOTICEエラーを消して行った
別ブランチを作成してバージョンアップを行なって行った
masterブランチの更新も走っていたので差分を取り込むのが大変
オレオレUpgrads Shellを作成
自動で新しいメソッド、関数に変換するシェルを作成した
CakePHP1.3でできることをする
paramをdataにするとか
CircleCIでチェックし変更をする
CakePHP1.3と2.8を同居させることに成功した
Codeceptionで動作を担保する
phpのバージョンアップ -> カナリアテスト
CakePHPのバージョンアップ -> 2バージョンを用意して書き換えて行く、UnitTestも2バージョン用意、Codeceptionがあるから安心
Realtime Database Messaging with Firebase
2ヶ月でのリリース
なるべく作らない方針
microserviceとして切り出さない
クラウドサービスを使い倒す
スコープを削りきる
Firebase
Googleの提供するBaaS モバイルに非常に特化して多機能
Firebase Realtime Database
Firebaseの機能の一つ
{ "messages" : { "1": { "text": "hello, firebase", "user": "sota1235" }, }, }
認証機能を追加したりできる
Rule
ノードに対して数字のみとか書き込み禁止とかできる
rulesには.writeにfalse、その中のroomsには.writeと.readにtrueでroomsだけに制限することができる
Ruleの適用
GUI or REST APIで設定
REST APIがおすすめ
スキーマ設計
Subscribe側を意識する
非正規化した方がいい場面もある
後方互換性を意識
配列がない
addすると自動でキーが振られて配列みたいに作成される
放送後はデータを読み込ませない
特定のライブIDが放送中かどうかのフラグを管理し、読み込みを許可する
root.child('alive_lives').child($live_id).val === trueとすることで他のノードの値を引っこ抜いて書きこみ、読み込みを制御できる
admin権限でルールを無視して放送中フラグを変更する
Write戦略
スマホからFirebaseへの書き込みは行わせない(APIを通す)
攻撃、認可など工数を考えたため
APIからEnqueue Job(Q4M)、Worker Process(PHP)がDequeue Job、Firebaseに投げる
FirebaseをSPOFににしない
野良SDKでkreait/firebase-phpをおすすめ
Read戦略
クライアントは受け取ったデータを表示するだけ(バリデーションはかけない)
スケーリング
Realtime Databaseはスケールアップできない
常用インスタンスと高負荷用インスタンスを分ける
料金は従量課金
何台インスタンスを立てていても通信しなければタダ
Firebase ProjectsとGCP Projectは1対1
Cloud Firestoreで変わった点
自動スケールアウトするようになった
SDKのI/Fがよくなった(Where的なことができるようになった)
RDよりLatencyが伸びる可能性がある
VS
新規プロダクトは基本Cloud Firestoreでよい
ReadWriteオペレーションが大量にハッセうする場合はCloud Firestoreの方がお金がかかる
何がよかったか
ユーザー体験
シンプルなアーキテクチャ
待機開発リリースを実現
運用、追加開発しづらいPHPアプリケーションに未来を与える方法
運用、追加開発しづらいPHPアプリケーションに未来を与える方法 // Speaker Deck
しやすいとは
- テストコードがある
- アプリケーションモニタリングがある
- デプロイが容易(CIサーバー・1コマンド)
モニタリングを追加
New Relic
新規機能
各コントローラー、エンドポイントのレスポンスの記録を確認できる
既存のアプリケーションを触らず、別のアプリケーションを立てて修正して行く
Slim 3.xとALBを使用して追加していく
セッション
session管理はデータベースに書き込むようにした
※この度過去に参加したイベントのメモなどを公開することにしたので、投稿日時をイベント当日に変更してあります。