狠狠撸
Submit Search
笔贬笔,骋辞,贰濒补蝉迟颈肠蝉别补谤肠丑による、蔼肠辞蝉尘别を5倍速くする取り组み
?
0 likes
?
592 views
K
Kenjiro Kubota
Follow
笔贬笔颁辞苍蹿别谤别苍肠别2018スポンサーセッション
Read less
Read more
1 of 38
Download now
Download to read offline
More Related Content
笔贬笔,骋辞,贰濒补蝉迟颈肠蝉别补谤肠丑による、蔼肠辞蝉尘别を5倍速くする取り组み
1.
PHP,Go,Elasticsearchによる、 @cosmeを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. インターネットのコスメ情報ポータルサイト 「@cosme(アットコスメ)」 の開発?運営 コスメだけではなくビューティ全般、日本だけではなく世界で"Beauty"に係る人や 企業、個人事業主が活躍できるプラットフォームを作る。 アイスタイルは、「Beauty×IT」の世界ナンバーワンを目指します。
4.
PR.
5.
@cosmeのスマートフォン版 一部ページの速度改善
6.
弊社が掲げているテーマ「1蝉别肠」
7.
Webページの表示速度を1秒台にする とはいえ明確な基準がない ● First Contentful
Paint? ● First Meaningful Paint? ● Speed Index? また、いざ速度改善することになると以下の制約が発生 ● CSS、JavaScriptはあらゆるページに適応されているので変更してほしくない ● 運用が大変になるので↑の分離もやらないでほしい ? とにかくサーバーからのレスポンスを速くしよう
8.
弊社における课题
9.
> モノリシックなアプリケーション 様々なサービスを一つのアプリケーションで構成しているため、巨大なコードになってい る。 > 10年以上運用されているレガシーな環境 コード量が膨大かつ、運用されている中での実行環境やフレームワークのバージョンアッ プが困難 >
仕様が不透明 コードを読み解かないとわからない仕様が多い。
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.
笔丑补濒肠辞苍と驳辞补
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.
オンプレから础奥厂へ移行
38.
thanks:)
Download