PHPカンファレンス2016に参加してきました
本日は、PHPカンファレンス2016に参加してきましたので
そのレポートです。
phpcon.php.gr.jp
参加した講演
私が参加してきたのは、以下の講演です。
10:50 - 11:30
老舗メディアが生き残るために継続的な改善に取り組んでいる話
株式会社VOYAGE GROUP
駒崎 大輔
13:00 - 14:00
Cygamesを支えるPHPと、その高速化の取り組み
株式会社Cygames
小笠原 空宙
14:20 - 14:50
PHPアプリケーションに関する12の事実
株式会社mediba
北田 翼
15:00 - 15:30
未来のWebに欠かせないREST APIを
ApacheSolr + Drupalで実装しよう
株式会社KDDIウェブコミュニケーションズ
阿部正幸
10:50 - 11:30 老舗メディアが生き残るために継続的な改善に取り組んでいる話
SVNからGitに移行してリリース物とコミット物の混乱した問題を改善した
- チームのリポジトリ管理をsvnからGitに移行
- コミットされたものがリリース物ではなく、辛かったがその問題が解決した
- Gitによってレビューが活発になった。
- デザイナーチームのフォローを厚くした結果、デザイナーチームもsvnからGitに移行することができた
- Web制作者のためのGitHubの教科書、という本を使って布教したらしい
phpdotenvによる環境により異なる変数の問題解決
- phpdotenvを使って、環境変数に色々と記載。これを使うまでは、パスワードがハードコードされていた。一番の利用理由は、環境によって異なるものがハードコーディングされていると辛いから
- phpdotenvを使うと、どの環境でも共通の方法で環境変数を参照できるようになる
リリースフローの整備と自動化によるリリース品質とサイクルの改善
- リリースフローは、コマンド実行からJenkinsに移行して、リリースフローの整備と自動化を実現した
- この改善により、リリーススピードのアップと、小さいリリースができるようになった。
機能数とテーブルの削減による品質の改善
- 機能数：1800->1200 , テーブル数：1200->900に削減した。機能数で600、テーブル数で300の削減はかなりの改善！
- 機能数を減らした方法は、機能の棚卸
- （1）機能とテーブルの一覧・・・一つ一つ調査して泥臭く作った。100万行のコードを調査するのが辛かった
- （2）テーブルと機能の関連を調べる・・・接続ライブラリにログを仕込んで調査
- 機能の棚卸でまとめた結果をもとに、使われていない機能とそれに紐づく、テーブル等の削除など泥臭くやることで大幅にと削減された
改善習慣を身につけることが大切。そのためには日常業務に改善の習慣を身につけるプロセスを組み込むことが必要
- メルカリの取り組みを参考にKAIZEN会を開催
- 丸1日、缶詰状態でエンジニアが全員、取り組む
- 題材は、基本的に自由
- お昼もお弁当
- KAIZEN会の頻度は月に1回
- KAIZEN会はエンジニアから好評
- エンジニアとしては、集中して作業できて良い
- 過去に自分が書いたコードをリファクタリングする時間ができた
- 普段、見ないコードを見ることができた
- 特にビジネス側から声を掛けられないので集中できるのは良い
- ロジックの共通化が進んで、6000行のコードが1700行に減った事例もあったとのこと
- KAIZEN会は8ヶ月継続中
読書会もやっている
- 読書会も開いていて、@t_wadaさんが技術講師を務めているらしい！
まとめ
- SVN->Git、Jenkinsによるリリースフローの自動化により、小さく素早いリリースできるようになった
- 機能とテーブルを削減することで、不要なコードを減らして過去負債を減らした
- KAIZEN会実施による改善習慣の定着化
- VOYAGE GROUP様の取り組みで、技術力評価会というものも面白いなーと思いました。KAIZEN会、技術力評価会と良い取り組みが色々とあってすごいです。ぜひ、参考にします。
13:00 - 14:00 Cygamesを支えるPHPと、その高速化の取り組み
プレゼン構成
- 前半は、サーバー構成やら取り組みやら、メンバーのマインドセットなど。後半は、Zephirを利用して試みた高速化について得られた知見についてが中心
秒間5万アクセス、100万クエリを日々処理している
- 1200万人ユーザーが使うグラブルの話し。高速化、負荷分散については、かなりのノウハウがありそう（苦労ともいえる）
- 1日300万人がプレイしているらしい（すげー）。秒間5万アクセス、100万クエリ、1日60GBのログがサーバーにたまる
Cygames Researchを設立
- 2016年4月からCygames Researchを設立。
- CySQLを開発中。ゲームに適したSQLとのこと。MySQLの10倍から20倍も速くなるとか
サーバー構成図
開発環境
- 開発環境としては、VagrantとAnsibleですぐに取りかかれる体制
モニタリングツール
- モニタリングツールは、MuninとMackerelを使っている
ログ系
- ログ系は、NewRelic、Google BigQueryで検索できるようにして、Fluentdでログ収集
スローガンは「面白くなければ意味がない」
- スローガンは「面白くなければ意味がない」
- 何を持って面白いとするのかは、ユーザー次第・・・。なのでゴールは手探り、トライアンドエラーをやりやすい実装や仕組みを整えるように意識している
ユーザーが最終的に面白いを決めるからCS優先の体制
- CS最優先・・・ユーザーが最終的に面白いを決めるから。
- 即顧客対応できるように、ログの収集と分析、可視化ツールを優先。確信を持って顧客に説明できるようにする
当たり前のことを当たり前にやろう
- 当たり前のことを当たり前にやる・・・不要な処理は書かない、などなど。チームとして継続して実施することが重要。例えば、夜中にアラートがあったら、ちょっとしたことで治ってしまったり。基本的なミスをえらせば、そういうことも少なくなる。
- チームレベルのアップがないと、チームの共通認識がなく無駄なコミュニケーションが増えるなど、人は増えたのに開発スピードが上がらないということが起こる。
New relicは最強
- New relicは最強。もう他のサービスには戻れない。重いクエリがすぐにわかるので、毎日、地道に対応
4.5秒以上かかったリクエストは重いリクエストとして対応
- 4.5秒以上かかったリクエストは、重いリクエストと判断
- 日次で開発環境で実行された全クエリを監視している。問題があれば、開発者に通知する仕組み。その問題が無くならないと、デプロイできない仕組みになっている
- 本番環境で実行されたクエリも監視。テスト、開発では問題なかったロジックでも、本番データが入ってくると想定外のことが起こる場合がちょくちょくある
- Twemproxyでキャッシュは分散。導入してから大きな問題は起こっていない
必要なくなったデータは、順次パージする
- 必要なくなったデータは、順次パージする仕組み
- イベントごとにテーブルを作成して、イベントが終われば、それらのテーブルdrop Tableする
リリース前には職種、チーム問わず、レビュー
- リリース前には職種、チーム問わず、レビューする。
- 開発チームが気づかない問題（機能的なメリットが少ないなど）に気づくことができる
今後の新しい取り組み
- ゲーム特有の問題に対応していきたい
- 例えば、処理は成功して、戻り値もいいのに問題がある。キャラからして、セリフがおかしいなどがあるとそれはロジック的には正しくてもゲーム的にはNG
- キャラのセリフを解析しておいて、過去と比較してコメントがおかしければアラートするなどの仕組みがアイディアとして上がっている
前半のまとめ
- 結局のところ、高速化の実現は、日々の分析とそれの改善、対応を地道に繰り返すことで実現している
Zephirが面白い
- Zephirが面白いよ。という話がでてきた。高速フレームワークのPhalconは、Zephirで実装されているので速度という意味で実績がある
- Zephirは、PHP Likeな文法で、コンパイルするとC言語に変換してくれる
- 実行は、C言語として行われるので、実行速度が速くなる。特に配列周りは実行速度が速い。*.soファイルなので、いろいろな言語で利用することもできる。
- 配列が多様されているところも、PHPは配列が遅いので80%程度、速度を改善することができる
Zephir、面白いけど、コンパイル手順が増えるのがディメリット
- Zephir、面白いけど、コンパイル手順が増えるので、新しいコードなどには使わないほうが良さそう。バグが多い、新規のコードになるとコンパイルしてから適用になるのでデプロイまでが大変。
- 共通ロジックで、変更が入らないコードを対象とするのが良い
togetterのまとめ記事
14:20 - 14:50 PHPアプリケーションに関する12の事実
12の事実とはTwelve-Factor Appの12の条文のこと
以下、The Twelve-Factor App の解説 - ワザノバ | wazanovaより引用
I. Codebase — One codebase tracked in revision control, many deploys
コードベースはソース管理システムに置き、多くの環境にデプロイできるようにしておくこと。II. Dependencies — Explicitly declare and isolate dependencies
依存するライブラリは明確に宣言し、コードをデプロイするときは正しいバージョンがダウンロードされ、正しい場所に置かれるように設定しておくこと。III. Config — Store config in the environment
設定条件はソースコードの中で環境別に管理すること。IV. Backing Services — Treat backing services as attached resources
コードは多くのサービス（DB、キャッシュ、メール、キューなど）とやり取りし、そのサービスは様々な環境（同じマシン、別のホスト、別のデータセンター、クラウドなど）で実行されているかもしれないが、コードはその違いを意識せずに各サービスをシンプルなエンドポイント（URL、ときにはID/パスワード）で参照できるようにしておくこと。V. Build, release, run — Strictly separate build and run stages
ビルドする時点では開発者はあらゆる面倒な作業が必要となる。しかしリリース後、本番の実行されるステージでは、とにかくシンプルで安心できる環境を用意すること。例えば、マシンに障害があっても、アプリが自動的に再起動することで、人の手を借りないで済むようにしておくと、開発チームは安心して夜寝られるようになる。VI. Processes — Execute the app as one or more stateless processes
多くのトラフィックをさばき、障害耐性を持たせるために、アプリは複数のサーバで実行されることになるが、各コードを実行するインスタンスはステートレスであるべき。つまり、そのシステムのステートは、各々の実行されているアプリのインスタンスではなく、データベース及び共有されたストレージで定義されるべき。例えば、プロファイルの入力画面が３ページあり、中間のステートが実行中のコードで保持されていると、作業が完了するまで同じユーザには同じサーバがアサインされ続ける。正しいアプローチとしては、中間データがDBもしくはkey/valueストアに保持される仕組みにしておくと、途中でサーバが落ちても、ユーザは別のサーバが難なく対応してくれるようになる。VII. Port binding — Export services via port binding
これは IV. Backing Services の拡張的な話で、アプリは外界に対してもシンプルなURLのインターフェースをもつべきということ。ウェブサーバを使っているとデフォルトでその状態にはなっているが、例えば、社内と社外に対して共通のAPIをアプリが提供していた場合、別々のURLを用意することで、より信頼できる社内アクセスには、セキュリティレベルの違う、早いアクセスを提供できるかもしれない。VIII. Concurrency — Scale out via the process model
コードを実行する際に、個別の細かいニーズに対して多くのプロセスを走らせるとよいというアイデアに行きつくはず。例えば、ウェブリクエストの対応、APIコールの対応、バックグランドで入会のwelcomeメールやtweetの送信など、それらの作業が独立して別々のプロセスで平行して実行できるようになると、アプリはうまくスケールする。IX. Disposability — Maximize robustness with fast startup and graceful shutdown
最近は外部ライブラリへの依存が多くなってきているので、秒速で起動することは難しくはなっているが、コードの読込み以外に、その都度に発生する作業があると、高頻度でのリリースサイクルづくりが難しくなる。本番のトラフィックにすぐに対応できるように事前に準備をしておき、起動プロセスをすっきりさせること。また、クラッシュも避けたいが、クラッシュした場合もすぐに復旧できるようにしておき、都度クリーンアップ作業が発生するような状態は避けたい。X. Dev/prod parity — Keep development, staging, and production as similar as possible
開発/ステージング/本番を極力同じ環境にしておくこと。XI. Logs — Treat logs as event streams
最低限、エラーログはNew RelicやAirBrakeに送ったり、ログをpapertrailやSplunk Stormに送るようにしておくこと。リアルタイムのログデータ収集、長期のアーカイブ、データマイニングをHadoopなどを利用して構築しておくと尚良し。XII. Admin processes — Run admin/management tasks as one-off processes
アプリが本番に提供されると、悪いデータのクリーンアップや、分析データの集計、A/Bテストの実施など、一時的なタスクを開発者が実行しなくてはいけなくなる。ローカルのターミナルウィンドウで実行したり、データベースを直接アップデートはしないこと。本番環境のマシンから実行すること。本番システムへのコンソールアクセスを用意するのは必須。
Twelve-Factor Appを実現
- Twelve-Factor Appを実現したというプレゼン
- Twelve-Factor Appを知っている人は、会場にはほぼ無し
環境変数として外だししてやることが重要
- 環境によって変わるものは、config.phpなどに格納するのではなく、環境変数として外だししてやることが重要。下記、ルールがそれにあたる
- 環境変数の実現は、AWS CloudFormationを使って実現。環境変数は、HOST_NAMEだとか、そういうところ。PHPアプリケーション、Webサーバーのhttped.confの各値とか
Twelve-Factor Appはエンジニアとしては学習コストは大きいが、やる価値はある
- エンジニアとしては学習コストは大きいが、やる価値はあるよ。でも、実運用はこれからだから、実運用も含めた成果がわかるのはこれからということ
togetterのまとめ記事
15:00 - 15:30 未来のWebに欠かせないREST APIをApacheSolr + Drupalで実装しよう
ApacheSolr + Drupalは実績のある実装方法
- ApacheSolr + Drupalという実装は、ANNAI株式会社にて、実績のあるAPI実装方法とのこと
- 最新だとElasticsearch + Drupalという実装らしい
システム構成
REST APIサーバーで一元管理すれば、様々なシステムに対応できる
- 一つのいろいろなコンテンツ、システムがあって、それを管理するのが大変。それを、REST APIサーバーで一元管理して、すべてのサイトに配信したらいいじゃんというのがコアなアイディア
Drupal8の記事
- Drupal8の細かい部分はこちらを読んでも良さげ
FESSという検索エンジンが優れている
- FESSという検索エンジンが優れているとのこと。全文検索にはオススメ。
- FESS詳細については以下記事を参照
