前夜祭に引き続き当日も参加しました。
トークの感想と聞いている最中のメモを残しておきます。
PHPの現場公開録音もありました！！
TODO: 資料とビデオのパスを追加
トーク
今からでも出来る!Wwbサービスモニタリング!! - @soudai1025
RDBで有名な@soudai1025さんのWebサービスについての監視についてのお話。有名でお名前はしってたんですが、初めてトークを聞きました。
僕は普段アプリケーション層の開発をしていて、インフラをされている方ほど、監視は積極的に考えていなかったです。
そんな中で、話を聞いていたんですが、
- 小さく初めてその後踏み込んでいくこと
- 時系列データを取って可視化すること
などを強調して語られており、初心者にもわかりやすいトークでした。
SOLIDの原則って、どんなふうに使うの？ - @hidenorigoto
ベストトーク賞おめでとうございました！！
✨✨✨ベストトーク賞発表🎉「SOLIDの原則って、どんなふうに使うの？」後藤秀宣 ( ゴトウヒデノリ )さん @hidenorigoto でした！！！✨✨✨#phperkaigi
— PHPerKaigi 2018@3/9-10 本編＆懇親会チケット販売中！ (@phperkaigi) 2018年3月10日
[資料公開待ち]
とある新人と先輩のコミカルなやり取りを例にしてオープン・クローズド原則について説明してくださってました。
名前は聞いたことがありましたが、理解はしていなかったので非常にわかりやすく、他のかたもTwitterでおっしゃっていましたが、新人教育みたいな場でやってほしいトークでした。
「バリエーションからソースコードを守る」という表現が非常にキャッチーでわかりやすかったと思いました。
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技 - @yoku0825
www.slideshare.net
PHPなしのMySQLのバックアップのお話。
監視と同様、普段あまり気にしていない分野でしたが、主に
- フルバックアップ
- バイナリーログバックアップ
という2つのバックアップ手法を用いてDBの復元が出来る方法を、注意点とともにまとめてくださっていました。
細やかな情報が書いてあるスライドを爆速で飛ばしていくスタイルで、資料はしっかり読み返さないとなという感じでした。
Hackで作るマイクロフレームワーク - @ytake
事前に資料が公開されるスタイルだったので、読んでから参加しました。
Hackという言語は触ったことがなかったので、その概要と今後の大まかな流れについて知ることができました。
型定義ファイルのhhiファイルの紹介で、TypeScriptやFlowTypeのことを例に出されていて、結局そのへんはコミュニティの尽力なんだなっていう風に思いました。
また、前夜祭でのテスティングフレームワークにもありましたが、言語を勉強するときにフレームワークを作るというのが勉強になる、ということだったので、とりあえず公開されているらしいコードをよんでみるこからはじめてみたいな、と思いました。
PHPStanで始める継続的型検査 - @Hiraku
PHPStanによる静的解析の話。
素のPHPに対してのもの、という点では違いますが、↑のトークも見ようによっては静的型解析の話でした。
7系でプリミティブ型の型注釈が入ったとはいえ、あまり強くない型チェックのPHPと静的な解析は難しく、テストで担保するべき部分があるということをおっしゃっていました。
前前夜祭のLarvel Meetup Tokyo #10、前夜祭とともにテストの話が多かったのも、静的な言語が流行りつつある中で、動的なPHPを好きな人たちが、それでも安心感を持って開発するためには、テストが必須だったということなのかな、と思いました。
まとめ
前夜祭とは違って、PHPを利用してアプリケーション開発をする上での色々な分野の話を1日で聞けたのは非常に楽しかったです。
最近参加した大きなカンファレンスの中でも、どなたの発表もすごく上手だな、とすごくハイレベルに感じたので、発表する手法としても学ぶ分が多かったカンファレンスだったと思いました。*1
僕はしがないラジオというPodcastのパーソナリティをしているんですが、そのリスナーの方が話しかけてくださって、写真を取りました！！ありがとうございました。
こういうのも、カンファレンスのいいところだなと思いました！
ペチパーカイギで
— gremito (@grem_ito) 2018年3月10日
しがないラジオのズッキーさんと記念撮影‼
あざまっす！＞＜#しがないラジオ #phperkaigi pic.twitter.com/IykR6SlU5P
おまけ（以下メモ）
あくまで個人的なメモです。詳細は、公開される資料とビデオを参照ください。
LTもありましたが、ビールが入っていたので省略します笑
今からでも出来る!Wwbサービスモニタリング!! - @soudai1025
PHPerのためのWebサービスモニタリング
モニタリングしてますか？
アプリケーションエンジニアのためのモニタリング
- 障害に気づく
- 障害原因を究明
- 未然に障害を防ぐ
話さないこと
- システムメトリック
- データベースの監視はしない
過去のスライドとかブログを見てほしい
Webサービス + PHP
Webサービスは生き物 = 常に変化
シーズンや時間帯、年によっても変わる
3層の監視
可視化が大事
時系列のデータを取る
課金料や使っているサービスのモニタリングもする
モニタリングの勘所
ちっちゃく始める
- リソースを"正しく"使えているか？
- リソースは過不足なく使えているか？
- 意図しない挙動に気づく
- リリースによる変化の機微に気づく
踏み込んだシステムの可視化
スライドに多くの例示あり
誰も見ないグラフに意味はない => ダッシュボードの棚卸しが必要
PHPのモニタリング
イベントとPHP
参考ブログ: 2015年Webサーバアーキテクチャ序論
PHPとキャッシュ
OPCache => コードキャッシュ
APCu => データキャッシュ
https://github.com/krakjoe/apcu/
https://gist.github.com/ck-on/4959032
Apache Server Status
nginx_status
まとめ
常に見続けられるわけじゃないから、時系列にデータを持つ、そして定期的に変化を確認する
推測 -> 計測 -> 観測
事実をより多く、正しく知ることで、未来を正しく予測できる
- Webサービスを監視するときに僕達が考えたこと
- SRE本
エンジニアには根拠が必要
なんとなくでは仕事はできない
- テストコードはプログラムの品質の可視化
- モニタリングはインフラの品質の可視化
QA
DBの問題は金で殴ると解決する
- CPU
- メモリ
- ファイルI/O
サーバレスのモニタリング
- 正しく処理ができているときにどのくらい時間がかかっているか、その結果、処理の数が増え続けていたら注意
- AIで自動でindexをはるとかいう時代になったときにエンジニアはどう振る舞うのか？が今後の課題
SOLIDの原則って、どんなふうに使うの？ - @hidenorigoto
SOLIDの原則
5つの設計原則の頭文字
- 単一責務
- Open Closed
- リスコフの置換原則
- インターフェース分離の原則
- 依存関係逆転
オープン・クローズドの原則
目標
- 原則の理解する
コマンドラインで使うTODOアプリ - いわゆるMVCフレームワークは使わない - TODOにバリエーションが有る - TODO - GoogleCalendar由来のTODO
常に未知の仕様を検討するわけじゃなく、検討すべき根拠のあるものを検討する
オープン = 機能を拡張できる
クローズド = 修正を行わない
同時に満たす
バリエーションを起因として、モジュールに新たな振る舞いを追加する際に、既存のコードを修正せず、単に新しいコードを
バリエーションからソースコードを守る
バリエーションによって変化する部分は？軸に沿ってまとめる
勝手に調べた資料: 何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
おすすめ書籍: レガシーコード改善ガイド
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技 - @yoku0825
MySQLのバックアップ
リプレイする
最初から全部同じクエリを発行していれば、同じテーブルを再現できる
全て正しく
randomは難しい
リプレイ unsafe = バックアップ unsafe
手法おさらい
定期的なフルバックアップとバイナリーログバックアップをする
※レプリケーションフィルターは使用しない
バイナリーログバックアップ
任意の時間まで戻れる
できるだけ多くのログを他のストレージにうつしておけるかがキモ
GTID
日々のバックアップ
バックアップスクリプトのログを残す
文字コードの設定が変わっている場合の文字化け => configもバックアップしとこう
障害の切り分け
単純なクラッシュ
データの復元
サーバー1台でやる？
結局スレーブ作ったほうが早い。。。
フルバックアップをデイリーで取って90日分のバイナリーバックアップ
binlogのリアルタイム保存の方法
--read-from-remote-saver --stop-never --raw
スレーブだと思って文字コードを整えて、やってくれる
リストアの手順
gtid_mode
まとめ
安全なバックアップライフを
QA
binlogのバックアップの正しさはどう担保する？
- 監視
- 1つ1つのバックアップ量を小さくして取り直しのオーバーヘッドをできるだけ小さく
Hackで作るマイクロフレームワーク - @ytake
なぜGoじゃないの？
=> PHPの開発者が使えるものを増やしかった
開発するための知識
PHPのコードがそのまま実行可能
厳格なType Checker
Async, XHP, Generics, Collections
3.24 LTS
HHVMは、Hackを対象にしていくので、PHPとHackはどんどん別物になっていく
Type Checker
- decl
- parcial
- strict
既存のPHPコードはstrictでは使えない
=> コードレビューをビジネスロジックに
callableに気をつける
hhiファイル
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
- 文化的バックボーン、簡単なものになれているユーザーを取り込むのはきびしい？
- フレームワークはあるの？
- ない、作ろう
PHPStanで始める継続的型検査 - @Hiraku
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方面の充実により漠然とした不安が
- 動的と静的の美味しいところを使う
