狠狠撸

狠狠撸Share a Scribd company logo
PHP,Go,Elasticsearchによる、
@cosmeを5倍速くする取り組み
istyle.inc KenjiroKubota @PHPConference2018
Profile.
~ 2015/08 istyle.inc
テクノロジー本部 R&D 部技術開発部 チーフエンジニア
久保田 賢二朗
● PHP(Laravel/Phalcon)
● JavaScript(Vue.js/Svelte)
● Golang
● HHVM/Hack
kenjiro kubota
PR.
株式会社アイスタイル
istyle Inc.
インターネットのコスメ情報ポータルサイト
「@cosme(アットコスメ)」
の開発?運営
コスメだけではなくビューティ全般、日本だけではなく世界で"Beauty"に係る人や
企業、個人事業主が活躍できるプラットフォームを作る。
アイスタイルは、「Beauty×IT」の世界ナンバーワンを目指します。
PR.
@cosmeのスマートフォン版
一部ページの速度改善
弊社が掲げているテーマ「1蝉别肠」
Webページの表示速度を1秒台にする
とはいえ明確な基準がない
● First Contentful Paint?
● First Meaningful Paint?
● Speed Index?
また、いざ速度改善することになると以下の制約が発生
● CSS、JavaScriptはあらゆるページに適応されているので変更してほしくない
● 運用が大変になるので↑の分離もやらないでほしい
? とにかくサーバーからのレスポンスを速くしよう
弊社における课题
> モノリシックなアプリケーション
様々なサービスを一つのアプリケーションで構成しているため、巨大なコードになってい
る。
> 10年以上運用されているレガシーな環境
コード量が膨大かつ、運用されている中での実行環境やフレームワークのバージョンアッ
プが困難
> 仕様が不透明
コードを読み解かないとわからない仕様が多い。
どうやって速度改善するか?
機能を切り出してアプリケーションを分ける
マイクロサービスアーキテクチャをヒントに「商品」という単位でサー
ビスを切り分け
アプリケーションも新たに刷新。まずはモノリシックなアプリケーショ
ンを分離させる。
ランキング?ブランド?サロン?クーポンetc
商品ページ?クチコミ
現行で動いてるシステムの仕様をそのままに
新規アプリケーションでフルスクラッチ
メリット
● 全く別の実行環境を用意できるので一気にバージョンアップが可能
● 技術選定に幅がある
● 負のコード(設計)に触れることがない
デメリット
● 同じ仕様のものを再開発しなければならない(そもそも仕様がわからない)
? SQLやコードを読み解きながらそのページに必要な処理をひたすら追う
特定のパスへのアクセスはサーバーの向き先を変更
/product/prodcut_id/{id}/top
アプリケーションの構成
フロント API データ
Phalconとは
● PHPフレームワーク
● Zephir/C拡張で記述されていてオーバーヘッドが少ない
● PSR-0/4準拠
● DIコンテナ標準搭載
● PHPフレームワークで実行速度が最速の部類
弊社ではLaravelの事例が多いが、今回は実行速度を優先
それでいてPHPライブラリや知見を生かせるPhalconを採用
goaとは
● GolangのREST-API向けフレームワーク
● Design(Req/Resの定義)からSwagger.jsonを生成できる
● Golangの為、実行速度は速い
弊社のGolang採用事例でも過去何回かgoaは導入されている
フロントとAPI間の開発において、SwaggerUIを実装ベースで
更新できるため今回も採用
Elasticsearchとは
● Elastic社が開発しているオープンソースの全文検索エンジン
● 同社のKibanaという可視化ツールが利用できる
● 高いスケーラビリティ
● 検索速度や分析柔軟性が高い
こちらも弊社では多く採用しています。
高速な検索、スケーラビリティの高さから採用
データの同期
既存のデータベースからのデータ移行
メッセージングシステムを利用して更新を検知
定期的に移行バッチも実行してデータを同期
● 全件同期できるほどのデータ量であれば毎日全件更新
● データが多い場合は毎時で直近1-2時間内に作成?更新されたデータを同期
データの構造に変更が発生した場合
インデックスA
Alias
インデックスB
Alias
笔丑补濒肠辞苍と驳辞补
REST APIへの実行が直列だとレイテンシが無駄
GuzzlePromiseで並列実行...
UseCase
事前に並列取得し、
各レスポンスをシングルトンオブジェクトで保持
UseCaseB
UseCaseA
UseCaseC
並列取得 個別取得
アノテーションにより事前取得
笔贬笔,骋辞,贰濒补蝉迟颈肠蝉别补谤肠丑による、蔼肠辞蝉尘别を5倍速くする取り组み
リグレッション テスト
もちろん従来のアプリケーションと同じ仕様になっている
ようにしなければならない。
● DOMを抽出し、内容を比較
? h1タグに出力された文字列が一致しているか
? htmlのタグのsrcやhrefなどの値が一致しているか
? listタグのn番目の要素は同一か
? レスポンスのステータスコードの比較
etc...
数万ページに対して実施し、表示される要素に変化がない
ことを確認
● 非同期で生成されるDOMは検知できない
? 現状非同期で処理している箇所が少ないので現在は手動
確認(増えたらbehat等を検討)
● 現在でもアップデートを続けて、設定?定義ファイルを読み
込ませて実行できるためどんなサイトにも利用できる
● 需要があればOSS化したい
改善结果
1.1sec 0.2 sec
まとめ
?ロードバランサーを利用して一部ページから切り替え
レガシーなシステムのまま改善するのは大変です。新しい技術の導
入も難しいため、ページ単位でシステムを移行していく。
?画面に必要なデータは高速なデータベースに移す
同じデータベースを使うことも良いかもしれませんが、CQRSの考え
方をヒントにクエリを分離し、ページに読み出すデータは別途速い
データベースに移すことも検討してみてください。
?リグレッションテストは大事
仕様を変更できる場合はよいですが、そのままの仕様で移行すると
なると同一性の担保が大切です。
オンプレから础奥厂へ移行
笔贬笔,骋辞,贰濒补蝉迟颈肠蝉别补谤肠丑による、蔼肠辞蝉尘别を5倍速くする取り组み
thanks:)

More Related Content

笔贬笔,骋辞,贰濒补蝉迟颈肠蝉别补谤肠丑による、蔼肠辞蝉尘别を5倍速くする取り组み