Meet Magento Japan 2018 講演レポート<後編>

November 14, 2018
=2018年11月14日に都内で開催された「Meet Maganto Japan 2018」。当日行われたコウェル社員による講演の様子を前編・後編に分けてレポートします。=
MeetMagentoJapan2018様子
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Speaker Information>>
林 隆洋(Takahiro Hayashi) Head of Technology Promotion Division, Technical Division  CO-WELL Co., Ltd.
Web制作会社、個人事業主を経て2011年株式会社コウェルに参画。
Web黎明期からPerl CGI~Java~Flash/Flex~PHPなどカバーする開発言語を拡大。
2014年から2017年までベトナムに3年ほど駐在しCTOとして教育カリキュラム構築、大学連携などに従事。
近年はセキュリティ方面に注力。2018年からMagentoの性能向上についてのプロジェクトに参画。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
|講演テーマ|国内大規模事例(2) ~ オフショア開発の現場での性能チューニングと構成管理 ~
1)プロジェクト概要
林magento
林: 今回、私が参画することになったプロジェクトは、店舗数200店舗以上、SKU数千万件の国内大手小売業様のECサイトリニューアルです。Magento2の採用、クラウドはMicrosoft Azureであることは既に決定しており、開発は当社日本法人とベトナム開発センターがメインで担当し、基幹システム連携部分は他社で行う方針の下でのプロジェクトになります。
2)大規模プロジェクトにおける性能チューニング
林: まず、背景と実際にあった例についてお話します。 言うまでも無いことですが、ECサイトにとってパフォーマンスは特に重要な項目です。
Magentoは基本的にDBがEAV(Entity Attribute Value)で作られており、カスタマイズ性が高い反面そのままではパフォーマンスが出にくい部分もあります。 また、今回のお客様のようにデータ構造として、商品は複数の店舗を跨いで使われるため、店舗毎に商品が固有で店舗間で共有しない場合はMagentoのデフォルトの動きが余計である場合が出てきます。
不適切なクラスの利用の例でお伝えすると、DBにアクセスする時に使うクラスとして、FactoryとRepositoryというものがあります。Magentoの公式ドキュメントには、FactoryとRepositryがあり、どちらも同じような事が出来ますが、どちらを使うかによってパフォーマンスが大きく変わってくるので開発時には注意が必要になってきます。
また、複数通貨に対応することによる問題では、1サイトで複数の通貨に対応していることで、商品の価格を表示する場面で必ず通貨の設定による表示価格の書式調整処理が発生します。扱う通貨を管理画面で日本円だけにしてあったとしても、その判定をするためのDBアクセス等が発生することになります。
最適な手法で実装できていなくても、データ量が小さければなかなか表面化しません。要するに開発者が開発環境しか見ていない場合に、気付かないまま先の工程に進んでしまうケースが発生しやすくなります。
問題の早期発見には、本番環境で想定しているデータ量の環境を用意するのことはもちろんですが、自動的に定点観測できるようにしておくと発見が早まります。 実際、当プロジェクトでは、2つの点を実施して対策としていました。
一つ目は、明らかに体感で遅い機能についてBlackfireによる計測と分析を行うこと。二つ目は、改修が行われるたびにシナリオ中で遅くなる箇所が出てないかをJmeterで定期測定することです。

・Blackfireによる機能単位のボトルネック調査
Magento公式サイトでも紹介されていますが、Blackfireは所謂PHPのプロファイラとチャートツールの組合せをSaaS化して手軽に分析できるサービスです。
xdebug + webgrind + xdebugtoolkit + graphvizなどでも似たような事はできますが、Blackfireは無料版でも簡単に分析でき、SQLクエリの抽出があるため、それなりにメリットがあります。 また、有料の「Profiler」以上のプランで使える「Timeline Visualization」が非常に分かりやすいので、ボトルネック解消までの意志決定を素早く行う助けになります。

・Jmeterによるシナリオ全体のボトルネック調査
次に、Jmeterによる定点観測についてです。 特に説明が必要ないほど定番だと思いますが、Magentoサイトでも有効活用できます。
どのようなシナリオで計測するかはサイト次第なので、ここではMagentoサイトでのワンポイントを共有するに留めます。 Jmeterの注意点としては、form_keyとuencです。Magentoでは、サイトにアクセスしてセッションが生成されると、_formKeyという隠しフォーム要素ができます。
Jmeterでシナリオを作る際は、最初のレスポンスで出てくる_formKeyを正規表現で抽出して、後続のリクエストに変数指定する必要があります。 さらにMagentoのデフォルトの動きでは、商品をカートに入れる場合に、URLにuencというパラメータがつきます。 これはリファラーをUrlEncodeしたもので、URLが変わるとこの値も変わってしまいます。これがあることで、ある環境で作ったJmeterシナリオが、別の環境では使えないという事態となりますので注意が必要です。 ※参考:https://maxchadwick.xyz/blog/wtf-is-uenc
3)大規模プロジェクトにおける構成管理
magento林
林:最後に、構成管理というと話題が多岐に渡ると思いますが、ここではごくシンプルにデプロイ周りの事例をご紹介します。
Magento deployなどで検索すると、Capistranoが事例として出てきますが、当プロジェクトではごくシンプルな独自のデプロイスクリプトを作ってデプロイする方式としました。
Magentoは本番運用のためのproductionモードがあり、高速化のために各種ファイルのマージやminifyなどの処理を行った上で実行環境に配置します。 このビルド処理は、規模により異なりますが当プロジェクトでは10分以上はかかっています。
そのため、ちょっとした変更であればファイルを差し替えるだけでは済みません。概ね、次のステップが必要となります。Cron停止/メンテモード変更、コードの更新、DBマイグレーション/ビルド、キャッシュ更新(redis)、ビルドサーバでこれらを済ませた後、各サーバにファイル転送、差し替えとなります。
注意点としては、ファイルキャッシュをNASに置く(Magento社は推奨していませんが)場合、ビルドスクリプトがエラーで止まるので一工夫が必要となります。Githubでも似たissueが登録されていますが、var/cacheを手動で消しておけば良いという結論でしたが、一工夫必要というのは、var/cache自体をマウントポイントにしてしまうと削除できずに泣く、ことになるからです。
キャッシュディレクトリは複数あるので、漏れなく綺麗にして置かないと特定サーバだけ古いというケースが起こり得ますので気をつける必要があります。(var/cacheだけでなくpub/static/_cacheという所もある。)
pagetop