phperkaigi.jp
前夜祭に引き続き当日も参加しました。
blog.zuckey17.org
トークの感想と聞いている最中のメモを残しておきます。
PHPの現場公開録音もありました!!
togetter.com
TODO: 資料とビデオのパスを追加
speakerdeck.com
soudai.hatenablog.com
RDBで有名な@soudai1025さんのWebサービスについての監視についてのお話。有名でお名前はしってたんですが、初めてトークを聞きました。
僕は普段アプリケーション層の開発をしていて、インフラをされている方ほど、監視は積極的に考えていなかったです。
そんな中で、話を聞いていたんですが、
- 小さく初めてその後踏み込んでいくこと
- 時系列データを取って可視化すること
などを強調して語られており、初心者にもわかりやすいトークでした。
ベストトーク賞おめでとうございました!!
[資料公開待ち]
とある新人と先輩のコミカルなやり取りを例にしてオープン・クローズド原則について説明してくださってました。
名前は聞いたことがありましたが、理解はしていなかったので非常にわかりやすく、他のかたもTwitterでおっしゃっていましたが、新人教育みたいな場でやってほしいトークでした。
「バリエーションからソースコードを守る」という表現が非常にキャッチーでわかりやすかったと思いました。
www.slideshare.net
PHPなしのMySQLのバックアップのお話。
監視と同様、普段あまり気にしていない分野でしたが、主に
という2つのバックアップ手法を用いてDBの復元が出来る方法を、注意点とともにまとめてくださっていました。
細やかな情報が書いてあるスライドを爆速で飛ばしていくスタイルで、資料はしっかり読み返さないとなという感じでした。
speakerdeck.com
事前に資料が公開されるスタイルだったので、読んでから参加しました。
Hackという言語は触ったことがなかったので、その概要と今後の大まかな流れについて知ることができました。
型定義ファイルのhhiファイルの紹介で、TypeScriptやFlowTypeのことを例に出されていて、結局そのへんはコミュニティの尽力なんだなっていう風に思いました。
また、前夜祭でのテスティングフレームワークにもありましたが、言語を勉強するときにフレームワークを作るというのが勉強になる、ということだったので、とりあえず公開されているらしいコードをよんでみるこからはじめてみたいな、と思いました。
speakerdeck.com
PHPStanによる静的解析の話。
素のPHPに対してのもの、という点では違いますが、↑のトークも見ようによっては静的型解析の話でした。
7系でプリミティブ型の型注釈が入ったとはいえ、あまり強くない型チェックのPHPと静的な解析は難しく、テストで担保するべき部分があるということをおっしゃっていました。
前前夜祭のLarvel Meetup Tokyo #10、前夜祭とともにテストの話が多かったのも、静的な言語が流行りつつある中で、動的なPHPを好きな人たちが、それでも安心感を持って開発するためには、テストが必須だったということなのかな、と思いました。
まとめ
前夜祭とは違って、PHPを利用してアプリケーション開発をする上での色々な分野の話を1日で聞けたのは非常に楽しかったです。
最近参加した大きなカンファレンスの中でも、どなたの発表もすごく上手だな、とすごくハイレベルに感じたので、発表する手法としても学ぶ分が多かったカンファレンスだったと思いました。*1
僕はしがないラジオというPodcastのパーソナリティをしているんですが、そのリスナーの方が話しかけてくださって、写真を取りました!!ありがとうございました。
こういうのも、カンファレンスのいいところだなと思いました!
おまけ(以下メモ)
あくまで個人的なメモです。詳細は、公開される資料とビデオを参照ください。
LTもありましたが、ビールが入っていたので省略します笑
PHPerのためのWebサービスモニタリング
モニタリングしてますか?
アプリケーションエンジニアのためのモニタリング
- 障害に気づく
- 障害原因を究明
- 未然に障害を防ぐ
話さないこと
過去のスライドとかブログを見てほしい
そーだいなるらくがき帳
Webサービスは生き物 = 常に変化
シーズンや時間帯、年によっても変わる
3層の監視
- サーバサイド
- インターネット
- クライアント
- コントロール可能だが、ユーザ操作など意図しないことが多い、予期しない不具合
可視化が大事
時系列のデータを取る
課金料や使っているサービスのモニタリングもする
モニタリングの勘所
ちっちゃく始める
- リソースを"正しく"使えているか?
- 意図しない挙動に気づく
踏み込んだシステムの可視化
スライドに多くの例示あり
誰も見ないグラフに意味はない => ダッシュボードの棚卸しが必要
PHPのモニタリング
PHPの仕組み?
プロセスとPHP
参考ブログ: 2015年Webサーバアーキテクチャ序論
OPCache => コードキャッシュ
APCu => データキャッシュ
https://github.com/krakjoe/apcu/
https://gist.github.com/ck-on/4959032
Apache Server Status
nginx_status
まとめ
常に見続けられるわけじゃないから、時系列にデータを持つ、そして定期的に変化を確認する
推測 -> 計測 -> 観測
事実をより多く、正しく知ることで、未来を正しく予測できる
エンジニアには根拠が必要
なんとなくでは仕事はできない
- テストコードはプログラムの品質の可視化
- モニタリングはインフラの品質の可視化
QA
DBの問題は金で殴ると解決する
サーバレスのモニタリング
- 正しく処理ができているときにどのくらい時間がかかっているか、その結果、処理の数が増え続けていたら注意
- AIで自動でindexをはるとかいう時代になったときにエンジニアはどう振る舞うのか?が今後の課題
SOLIDの原則
5つの設計原則の頭文字
- 単一責務
- Open Closed
- リスコフの置換原則
- インターフェース分離の原則
- 依存関係逆転
オープン・クローズドの原則
目標
コマンドラインで使うTODOアプリ
- いわゆるMVCフレームワークは使わない
- TODOにバリエーションが有る
- TODO
- GoogleCalendar由来のTODO
常に未知の仕様を検討するわけじゃなく、検討すべき根拠のあるものを検討する
オープン = 機能を拡張できる
クローズド = 修正を行わない
同時に満たす
バリエーションを起因として、モジュールに新たな振る舞いを追加する際に、既存のコードを修正せず、単に新しいコードを
バリエーションからソースコードを守る
バリエーションによって変化する部分は?軸に沿ってまとめる
勝手に調べた資料: 何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
おすすめ書籍: レガシーコード改善ガイド
MySQLのバックアップ
リプレイする
最初から全部同じクエリを発行していれば、同じテーブルを再現できる
全て正しく
randomは難しい
リプレイ unsafe = バックアップ unsafe
手法おさらい
定期的なフルバックアップとバイナリーログバックアップをする
※レプリケーションフィルターは使用しない
バイナリーログバックアップ
任意の時間まで戻れる
できるだけ多くのログを他のストレージにうつしておけるかがキモ
GTID
日々のバックアップ
バックアップスクリプトのログを残す
文字コードの設定が変わっている場合の文字化け => configもバックアップしとこう
障害の切り分け
単純なクラッシュ
データの復元
サーバー1台でやる?
結局スレーブ作ったほうが早い。。。
フルバックアップをデイリーで取って90日分のバイナリーバックアップ
binlogのリアルタイム保存の方法
--read-from-remote-saver --stop-never --raw
スレーブだと思って文字コードを整えて、やってくれる
リストアの手順
gtid_mode
まとめ
安全なバックアップライフを
QA
binlogのバックアップの正しさはどう担保する?
- 監視
- 1つ1つのバックアップ量を小さくして取り直しのオーバーヘッドをできるだけ小さく
なぜGoじゃないの?
=> PHPの開発者が使えるものを増やしかった
開発するための知識
PHPのコードがそのまま実行可能
厳格なType Checker
Async, XHP, Generics, Collections
3.24 LTS
HHVMは、Hackを対象にしていくので、PHPとHackはどんどん別物になっていく
Type Checker
既存のPHPコードはstrictでは使えない
=> コードレビューをビジネスロジックに
callableに気をつける
TypeScript, Flowと同様の型定義ファイル
単体では実行不可
使いたいPHPのコードも保管したい場合は、作成してpackagistで公開しよう!
PSR For Hack
独自のものを作ろうとしている
PSR-7対応のライブラリから対応してくるもよう
強力なライブラリ
hhvm/hhvm_autoload
Composer Plugin
hhiを探して、IDEの補完が効く
PHP7依存のライブラリは、コマンドでHackで使うことができる
hack-router
ytake/hh-container
コードは資料参照
mixed使うな!
anyと一緒笑
コンパイラのために書く
invariant
hhvm/type-assert
RouterとContainer、簡単なValidationがアレば、最低限の動作が可能に
Request BodyなどのValidationにtype-assett
mixedのケア
まとめ
- Hackだからなにか特別なもの、というのはない
- バグが少なく堅実
- コードレビューの負荷軽減
- 簡単では?
QA
- 文化的バックボーン、簡単なものになれているユーザーを取り込むのはきびしい?
- PHPの悪いところをなくす => C++のながれや、その違いが出てきている
- 別離の方向に進んでいるのは事実
- フレームワークはあるの?
dynamic と static
dynaic = 動かしてみる
- 実行されると困る場合
- 全部テストするのは現実的にムリな場合
static = 動かさずに読む
- 言語によって出来ることが違う
- 理論上、決定できない種類のものもある
工夫が必要
影響範囲が多いと漠然とした不安がある
マニュアルでは莫大な時間が
リリースに勇気が必要
staticをCIに組み込みたい!
PHPStan
phpstan/phpstan
Install
- composer
- phar版
- docker hub
バージョン違いに注意
Run
vender/bin/phpstan
カスタムルールも設定可能
正規表現でエラーメッセージをマッチさせることもできる
CIとの連携
2段階でのチェック
reveiwdogが便利
autoload
PHPStanは一部コードを実行する
autoloadに酔って呼び出されたファイルは実行されてしまう
PHPは静的解析しづらい
コンパイルとランタイムの境界が曖昧
100%静的に頑張るのではなく、動的も混ぜるPHPらしいいい落とし所
PHPStanの基本動作
型注釈が丁寧であればあるほどよい
PHPの型注釈は自由度が低い
なので、PHPDocを混ぜて使う
PHPStanはどちらも解釈してくれる
スカラ型に注意
doubleじゃなくてfloat
integer、booleanはない
PHPDoc
PHP公式の機能ではないが、標準らしきものはある
- スペース区切り
- 型を固定した配列
- union風記法
- true/false
現状できないこと
リスコフの置換原則(LSP)
- 型を派生した時、元の能力が減ったらだめ
クラスで頑張れなくもない
ムリに頑張る必要もない
テストすればいい
不安ならユニットテスト
まとめ
- PHPも静的解析がしやすく
- static方面の充実により漠然とした不安が
- 動的と静的の美味しいところを使う