PHPカンファレンス東京2016

PHPの今とこれから2016

  • PHPくん21歳
  • PHPのバージョン
    • PHP 5.3がまだ1/4くらいいる
    • EOLを迎えたPHP5.5以下を使っているのが80%
    • アクティブサポート2年+securityアップデート1年=ライフサイクル3年
  • PHP 7.1
    • 2016/12に7.1が出る？
    • Nullable型
    • mcrypt()廃止
      • m_cryptは7.1でE_DEPRECATED 7.2で消える
  • PHPのパフォーマンス
    • PHP7は5.6より大幅高速化
    • 内部構造の最適化、メモリ削減
    • HHVM速すぎィ
  • PHPのこれから
    • PCO(php cryptography objects)
    • JIT for PHP（PHP8？）

Chefとnginxで作るPHPアプリケーションのReliableBlueGreenDeployment

  • SREとしてデプロイフローの最適化や開発環境の整備
  • デプロイの経緯と環境整備
    • 経緯
      • ELBから複数台のnginx+PHPのサーバにプログラム配置
      • ファイルキャッシュの削除などを同時にリリースする必要がある
      • Gitリポジトリ50個あんねんぞどうすんねん　と壁にぶつかる
      • 1台ずつELBから外してデプロイしてELBに入れ直してた
      • SSHのターミナルを台数分開いて作業
      • ふえぇツラいよぉ
    • 簡単健全なデプロイ
      • 自動・並列・無停止が良い！
      • 候補1：Capistorano (ruby製)
        • root/app/release の下にタイムスタンプのディレクトリを作る
        • root/app/current がシンボリックリンクでタイムスタンプディレクトリをみる
        • root/app/current をドキュメントルートとする
        • 環境設定がめんどい
      • 候補2：Chef
        • 動いているサーバーからrecipe作成
        • やるなら同じ挙動のサーバにちゃんとデプロイしたい
        • BlueGreenDeploymentって？
          • 現行サーバ郡(blue)とデプロイ済みサーバ郡(green)を用意してELBに両方つなぐ
          • 現行サーバ群をELBから外してインスタンス削除
      • PHPの管理を何故Rubyで？
        • Chefと相性がいい
        • PHPシステムと干渉しない
    • nginx
      • ELBはアクセス限界を超えると通信を遮断してからスケールアウト
      • nginxのreloadで振り分ければダウンタイムなし
        • LBの代わりにnginxサーバを複数立ち上げてる
  • デプロイの流れ
    • BlueGreenDeploymentに必要なもの
      • 自動化
      • クラウド運用
      • ログ管理の外部化
    • 流れ
      • 管理サーバがGreenを立ち上げ
      • ELBにGreenを追加
      • BlueをELBから外す
      • ELBのステータスを確認
      • ステータスがOKならインスタンスリストを取得
      • 本番LBのインスタンスを差し替えてnginx reload
      • Blueインスタンス削除
    • 課題
      • ここまでをすべて自動化すべき
      • 対応できる人を増やしたい
      • bot

PHPerだってMicroserviceしたい

  • Microserviceじゃなくてもいいじゃない
  • サーバがHTMLを返す時代は終わった
    • webAPIを叩いてJSでレンダリングする時代
  • devicepack
    • CDNをwebサーバにする vue.js
    • APIサーバがEC2 lumen
    • 認証は認証サーバ
    • ビジネスモデルはビジネスモデル
    • 全てが疎結合
  • Microserviceとは
    • モノリシックではない
    • 責務が単一な小さなサービス構成
    • 単位はドメインでもサービスでもリソースでも良い
  • 実現のためには
    • サービス単位で構成を切る
    • I/Oの規約を決める
    • サービスごとで影響範囲を閉じる
  • 何が嬉しいか
    • サービスごとの部分変更に強い
    • スケーラビリティが高い
  • 何故Lumenなのか
    • micro-framework by Laravel
    • LaravelほどFatなものは不必要だった
      • APIサーバとしてルーティングさえできればなんでも良い場合の選択肢
      • 流行ってる=情報量が多い
    • ARNとRoutingの相性がいい
    • Middlewareで認証の処理
  • 何故vue.jsなのか
    • データバインディングだけ担うフレームワーク
    • AngularはフルスタックなのでFat気味
    • 特に深いことを考えなくても実装できる

PHPで学ぶソケットプログラミング

  • ソケットを使えばHTTPより下のプロトコルを使える
    • reactphp/http nodejsの用に使える
    • 独自のプロトコルで通信ができる
    • 別にPHPじゃなくてもいい
  • ソケットAPIの基本
    • ネットワークソケットとUNIXソケットの2種類がある
    • 主要なOSはネットワークソケットAPIを備えている(WinSockとか)
  • 前提知識
    • IPアドレス
      • IPv4は32bit整数
      • IPv6は128bit整数
    • ポート
      • 0-65535まである
      • 0-1023まではwell-knownポート
      • 49152-65535はephemeralポート
      • 自前のネットワークアプリケーションの待受ポートは1024-49151を使えば良さそう
      • Linuxは32768-61000がephemeralポート
        • 1024-32767ポートを使うのが安全
        • mongoとか主要なシステムと絡まないように注意
    • まとめ
      • IP+portで通信相手を特定
  • PHPにおけるsocket
    • 学習用にはソケット拡張(socket_xxx())
    • ストリームのほうが実装が簡単(stream_XXX())
  • サーバのライフサイクル
    • create,bind,listen,accept,closeの順で実装
    • socket_accept()でクライアントから通信がないと動作が止まる
  • クライアントのライフサイクル
    • create,bind,connect,close
  • データの送受信
    • socket_readで受信、socket_writeで送信
    • read待ち中は処理が止まるのでnon_blocking_modeで動かす
    • while(socket_accept())
  • stream_socket_sesrver()はcreate,bind,listenをしてくれる
  • reactphp/event-loop 非同期I/Oを抽象化してくれる
  • ソケットのような低レイヤーの基礎技術は枯れていて変わらない
    • どんな言語であっても同じ仕組みで作ることになるので覚えておいて損はない

質の高いAPIを作るための7つの習慣

開発前に注意すること

  • 契約の確認
    • 納期は決まっているけど内容が決まってない
    • 再見積もりが計画に入ってない
      • 仕様が変わるのに見積もりが変わらない
    • 契約内容は炎上前の最後の砦
      • マネジメント層はきちんと確認する必要がある
  • 見積もりの確認
    • 数字だけが独り歩き、言ったもの負け
    • 計画が変わっても見積もりが変わらない
    • リリース日だけは不動の在り方
    • チーム内で見積もりの勉強会した方がいい
    • 「見積もりは天気予報」
  • チーム体制の確認
    • プログラマのマルチタスクは近視
    • 1人日/日を基本とする

開発中に注意すること

  • 設計基礎知識を身につける
    • RESTAPIの設計は甘く見られがち
    • 押さえて欲しい設計思想や勘所
      • API利用者に分かりやすいURL設計
      • HTTPの仕組みを上手に利用する
    • Web API the good parts読んどけ
  • データに注目する
    • API設計はまずデータから
      • 詰まるところはSQLがメイン
    • データが単純ならBaaSで開発0のバックエンドでもいい
    • コツコツER図を作る
    • データモデリング能力がAPIの品質に直結
    • データベース実践入門読んどけ
  • 常用の設計ツールを持つ
    • 設計成果物としてER図、API仕様書が必要
    • MySQL Workbench →Macでも動く！
    • API仕様書作成のツール選定
      • 仕様書にブラウザでアクセスできる
      • 仕様書更新をCI経由で行える
      • Swagger-UIは良いぞ
    • 最新の状態をキープしやすいものを選ぶ
  • APP設計思想を心に刻む
    • 可用性の高いアプリケーションの設計思想
    • 20 facter app 読んどけ
  • 適切なWAFを選択する
    • オレオレフレームワークをやめろ
    • 選定ポイント
      • Migration
      • テストツール
      • コマンドライン
      • エラーハンドリング
    • Lumenは良いぞ
    • 必要な機能を持ったWAFを知っておく
  • テストファーストで作る
    • APIはテストしやすい
    • API仕様書でI/Oが決まっている
    • やらない選択肢はない
    • PHPUnit使え
    • 全体としては開発速度が上がる
    • PHPUnit,Behat
    • 正常系だけのテストでもいいが1URLに対して複数書くのが基本
  • CIと自動リリースを行う
    • 無理せず少しずつ豪華にしていく
    • CircleCI,Wercker
    • リリースは機械に任せよう

PHPerのためのVue.js入門とVue.js2.0の未来

  • Laravel5.3から公式フロントエンドライブラリにvue.jsを使っている
  • AngularJSは学習コストが高いがVueは簡単
  • Vueはプログレッシブフレームワーク
    • 段階的、コンポーネントを入れればどんどん便利に
  • 導入　CDNから読み込めばそれだけで動く
  • データバインディング
    • Vueインスタンスを作成
    • 対象エレメントを指定
    • データオブジェクトを設定
    • テキスト展開される
  • 双方向バインディング
    • v-modelディレクティブ
  • リストレンダリング
    • v-forディレクティブ foreachみたいに展開してくれる
  • Vue.jsのディレクティブは全部で12個?
  • v-onディレクティブ
    • vue.method に関数を用意しておいてv-on:click=”method”
  • v-if,v-elseディレクティブ
    • if文が簡単に実装できる
  • vbindディレクティブ
  • コンポーネント
    • 独自タグを作れる　再利用性が高い
    • Vue.component
  • 1系で動くものがnpmで落とした2系で動かない
    • ビルドファイルが2つある
    • スタンドアロン版、ランタイム限定ビルド版の2つに別れた
    • エイリアス設定すればOK
  • Vue.js Meetup,Slackコミュニティなどあるよ
  • Vue.js 2.0
    • サーバーサイドレンダリングに対応
    • 初期ロード時間の高速化とSEO対策
  • サーバーサイドレンダリングのポイント
    • vue-serverをrequire

感想

  • デプロイは完全自動化してなんぼ
  • APIの質を上げるにはまずは契約・見積もりから
  • Vue.jsはPHPerに必要なので覚えよう

現場からは以上！

元記事はこちら

「[雑記] PHPカンファレンス東京2016 #phpcon2016」