PHPConference2018スポンサーセッション

1. PHP,Go,Elasticsearchによる、
＠ｃｏｓｍｅを5倍速くする取り組み
istyle.inc KenjiroKubota @PHPConference2018

2. Profile.
~ 2015/08 istyle.inc
テクノロジー本部 R&D 部技術開発部 チーフエンジニア
久保田 賢二朗
● PHP(Laravel/Phalcon)
● JavaScript(Vue.js/Svelte)
● Golang
● HHVM/Hack
kenjiro kubota

3. PR.
株式会社アイスタイル
istyle Inc.
インターネットのコスメ情報ポータルサイト
「＠ｃｏｓｍｅ（アットコスメ）」
の開発・運営
コスメだけではなくビューティ全般、日本だけではなく世界で"Beauty"に係る人や
企業、個人事業主が活躍できるプラットフォームを作る。
アイスタイルは、「Beauty×IT」の世界ナンバーワンを目指します。

4. PR.

5. ＠ｃｏｓｍｅのスマートフォン版
一部ページの速度改善

6. 弊社が掲げているテーマ「1sec」

7. Webページの表示速度を1秒台にする
とはいえ明確な基準がない
● First Contentful Paint？
● First Meaningful Paint？
● Speed Index？
また、いざ速度改善することになると以下の制約が発生
● CSS、JavaScriptはあらゆるページに適応されているので変更してほしくない
● 運用が大変になるので↑の分離もやらないでほしい
⇒ とにかくサーバーからのレスポンスを速くしよう

8. 弊社における課題

9. > モノリシックなアプリケーション
様々なサービスを一つのアプリケーションで構成しているため、巨大なコードになってい
る。
> １０年以上運用されているレガシーな環境
コード量が膨大かつ、運用されている中での実行環境やフレームワークのバージョンアッ
プが困難
> 仕様が不透明
コードを読み解かないとわからない仕様が多い。

10. どうやって速度改善するか？

11. 機能を切り出してアプリケーションを分ける
マイクロサービスアーキテクチャをヒントに「商品」という単位でサー
ビスを切り分け
アプリケーションも新たに刷新。まずはモノリシックなアプリケーショ
ンを分離させる。
ランキング・ブランド・サロン・クーポンetc
商品ページ・クチコミ

12. 現行で動いてるシステムの仕様をそのままに
新規アプリケーションでフルスクラッチ
メリット
● 全く別の実行環境を用意できるので一気にバージョンアップが可能
● 技術選定に幅がある
● 負のコード（設計）に触れることがない
デメリット
● 同じ仕様のものを再開発しなければならない（そもそも仕様がわからない）
⇒ SQLやコードを読み解きながらそのページに必要な処理をひたすら追う

13. 特定のパスへのアクセスはサーバーの向き先を変更
/product/prodcut_id/{id}/top

14. アプリケーションの構成
フロント API データ

15. Phalconとは
● PHPフレームワーク
● Zephir/C拡張で記述されていてオーバーヘッドが少ない
● PSR-0/4準拠
● DIコンテナ標準搭載
● PHPフレームワークで実行速度が最速の部類
弊社ではLaravelの事例が多いが、今回は実行速度を優先
それでいてPHPライブラリや知見を生かせるPhalconを採用

16. goaとは
● GolangのREST-API向けフレームワーク
● Design(Req/Resの定義)からSwagger.jsonを生成できる
● Golangの為、実行速度は速い
弊社のGolang採用事例でも過去何回かgoaは導入されている
フロントとAPI間の開発において、SwaggerUIを実装ベースで
更新できるため今回も採用

17. Elasticsearchとは
● Elastic社が開発しているオープンソースの全文検索エンジン
● 同社のKibanaという可視化ツールが利用できる
● 高いスケーラビリティ
● 検索速度や分析柔軟性が高い
こちらも弊社では多く採用しています。
高速な検索、スケーラビリティの高さから採用

18. データの同期

19. 既存のデータベースからのデータ移行

20. メッセージングシステムを利用して更新を検知

21. 定期的に移行バッチも実行してデータを同期
● 全件同期できるほどのデータ量であれば毎日全件更新
● データが多い場合は毎時で直近1-2時間内に作成・更新されたデータを同期

22. データの構造に変更が発生した場合
インデックスA
Alias
インデックスB
Alias

23. Phalconとgoa

24. REST APIへの実行が直列だとレイテンシが無駄

25. GuzzlePromiseで並列実行...
UseCase

26. 事前に並列取得し、
各レスポンスをシングルトンオブジェクトで保持
UseCaseB
UseCaseA
UseCaseC
並列取得 個別取得

27. アノテーションにより事前取得

29. リグレッション テスト

30. もちろん従来のアプリケーションと同じ仕様になっている
ようにしなければならない。
● DOMを抽出し、内容を比較
⇒ h1タグに出力された文字列が一致しているか
⇒ htmlのタグのsrcやhrefなどの値が一致しているか
⇒ listタグのn番目の要素は同一か
⇒ レスポンスのステータスコードの比較
etc...

31. 数万ページに対して実施し、表示される要素に変化がない
ことを確認
● 非同期で生成されるDOMは検知できない
⇒ 現状非同期で処理している箇所が少ないので現在は手動
確認（増えたらbehat等を検討）
● 現在でもアップデートを続けて、設定・定義ファイルを読み
込ませて実行できるためどんなサイトにも利用できる
● 需要があればOSS化したい

32. 改善結果

33. 1.1sec 0.2 sec

34. まとめ

35. ・ロードバランサーを利用して一部ページから切り替え
レガシーなシステムのまま改善するのは大変です。新しい技術の導
入も難しいため、ページ単位でシステムを移行していく。
・画面に必要なデータは高速なデータベースに移す
同じデータベースを使うことも良いかもしれませんが、CQRSの考え
方をヒントにクエリを分離し、ページに読み出すデータは別途速い
データベースに移すことも検討してみてください。
・リグレッションテストは大事
仕様を変更できる場合はよいですが、そのままの仕様で移行すると
なると同一性の担保が大切です。

36. オンプレからAWSへ移行

38. thanks:)