梅田昌太さん「PHPerがAWSと出会ってDevOpsを目指した話⁠」⁠

アプリケーションエンジニアである梅田さんが，Rettyのサービス拡大とともに発生した問題とどう向き合ってきたかについて紹介しました。スタートアップで，サービスの機能を追加していくことと，ユーザーが増えて発生する問題の解決を両立させて進めていくために，という話はとても興味深かったです。

まずは，Rettyのサービスについて紹介しました。インフラ構成別で分類すると次のようになっています。

• retty.me レティのサービス
• news.retty.me レティのニュース配信サービス
• owners.retty.me レティの飲食店様向けのサービス

次に，サービスの成長に伴うインフラの構成と，その際に発生した問題を説明しました。

• ～5万ユーザ：VPSで稼働。
• 10万ユーザ～：AWSに移行（EC2のみで稼働⁠）⁠。
• 50万ユーザ～：AWSアーキテクチャを意識し，EC2からサービスを分離。
• 100万ユーザ～：EC2の冗長化をして，スケールアウトし始めた。また，Nagios, Monitによる死活監視を始めた。
• 200万～400万ユーザ：サブドメインをAWS＋VPCに移行。32bit amazon linuxから64bit amazon linuxにし，MySQL・PHPのversionをバージョンアップした。
• ～500万ユーザ：ログをTreasureDataに移行し，CIはCircleCIで回すようにした。

また，Opsを楽にしてくれたサービスたちの個人的ランキングも紹介しました。

• 1. Elastic Beanstak（オートスケールｘ自動デプロイ⁠）⁠
  • Heroku toolみたいなもの。gitのリポジトリをデプロイできる。Environemnetとコミットを指定してデプロイ。
• 2. RDS
  • 高いが，Multi_AZは素晴らしい。メンテフリーで，気軽にスケールアップできる。
• 3. S3
  • EBSで，でかいインスタンスを用意するのはあまり良くない。

最後に，大事だと思うこととして，「⁠自前で解決することもできるが，コストがかかっても，運用コストを下げてアプリケーションの開発に専念すること」「⁠AWSが推奨するアーキテクチャに乗って，インフラはAWSに任せること」を挙げていました。

中野拓さん「PHPにおけるI/O多重化とyield⁠」⁠

中野拓さんは，1つ1つのマイクロサービスを複数のAPIでコンポーネント化して実現する際に，増えるI/OをPHPでどのように多重化するかについて説明しました。

まずは，マイクロサービスはどうしてI/Oが遅くなるかを紹介しました。

マイクロサービスとは，ライブラリではなくweb APIによってアプリケーションをコンポーネント化してつくることを指します。その際，ネットワークI/Oは遅いので多重化します。このI/Oを多重化のためにPHPの非同期APIを使うことになります。

真のI/O多重化としてcurl_multiを取り上げましたが，これを書くのは大変だと紹介し，書きやすく抽象化したいと言います。

例えば，node.jsは1スレッド1プロセスですが，同時に複数のリクエストをさばくことができます。また，あらゆるI/Oが徹底的に非同期・多重化されています。このnode.jsを真似たものにReactPHPというのがあります。ただ，callbackが使いづらく，既存のPHPライブラリが使えません。

そこで，中野さんはyield（ジェネレータ）を薦めました。関数を一時停止・再開できる機能です。これを用いることで，既存のコードにほとんど手をいれずに処理を多重化できることを説明しました。

まとめ

最後に，まとめとして次のことを挙げました。

• I/O多重化してマイクロサービスに備えよう
• PHPにcallbackスタイルはつらい
• curl_multiでI/Oを多重化できるが書くのが大変
• yieldでも多重化を書きやすく抽象化してくれる

祖山寿雄さん「今日から始める PHPエンジニアのためのアクセスログ解析基盤構築入門⁠」⁠

アクセスログはネットワークエンジニアにお任せしない風潮になってきていて最近辛いところです。祖山寿雄さんは，アクセスログ解析基盤構築について発表しました。

PHPとログ

PHPはWebアプリケーションを作るための言語ですが，Webアプリケーションを運用するとログが残ります。ログはどこにあるのかというと，アクセスログなら/var/log/wwwや/app/tmp/logなどにあります。

これら生ログを目視するのは，泣きたくなります。grepすると多少ましになりますが，sed&awkなどの職人芸を必要とする場合が出てこないことを祈るばかりです。さらに，古いログは圧縮されています。これを展開して編集して……ということは，したくないはずです。

簡単にログを調べたい

アクセスログは行動履歴なので，きちんと使うことで，会員登録後にアクティブになったユーザとそうでないユーザの行動にどんな違いがあるか？等の情報も取得できます。

もしもHadoopとかRedshiftとかはよく分からず，分析自体はExcelとかRとかに任せるとして，必要なデータを簡単に分析したい時は次の2つのプロセスを考えるのが良いと言います。

• ログ調査を効率化しよう
• ユーザーの行動解析をしよう

1. ログ調査を効率化しよう

ログ調査を効率化するために，ElasticsearchとKibanaを薦めました。Elasticsearchはオープンソースの検索エンジン。Solrとよく比較されます。Kibanaは表示したり，クエリを作ったりします。検索的にログを調べられて便利です。また，静的ファイルとして存在しているので，軽いのがメリットです。

2. ユーザーの行動解析をしよう

解析にはBigQueryがお薦めだと言います。BigQueryではSQLライクなクエリが書けるのと，とにかく安いのが素晴らしいとのこと（1Tの検索でも5ドル程度⁠）⁠。ただ，スキーマレスではないので，JSONなりCSVなりで入れてやる必要はあります。

Elasticsearchのクエリはネストが続くため，人間の視認性が悪い。なのでそこだけはBigQueryが良いそうです。データを投げるだけでGoogleがやってくれるので便利だと述べていました。BigQueryもKibanaほどではないにしてもダッシュボードを作ることができますが，ガチャガチャと打ち込むとクエリ課金なので注意が必要です。

ログを入れるためのfluentd

BigQueryやElasticsearchにログを入れるには，fluentdを使います。fluentdを使うことで，phpやsyslog，apache，それぞれのミドルウェア毎のログを整形したり，いろいろな形式で取り出すことができます。通常はこのような作業は大変です。しかしfluentdが代わりにやってくれます。設定のテンプレートも公開されています。

また，ログのフィルタリングができるので，必要なログだけBigQueryやElasticsearchに渡すことができたりするとのことです。

フローの制御はタグをつけることで実装します。具体的にはX行目のタグはABCみたいな感じです。

ログを送るデモ

そして，nginxのログをBigQueryとElasticsearchに送るデモを行いました。

注意点として，BigQueryはクエリ課金なので，できるだけ絞ったほうが良いとのこと。例えば，静的ファイルはいらない，などです。

また，fluentdのconfigは65k程度で書けます。項目にタグ付けをして，フィルタするイメージです。タグ付けされた項目に応じて送り込むテーブルを変更したりすることもできることを説明しました。

PHPとはかなりかけ離れていましたが，是非これらを使ってみたいと思ったセッションでした。