WordCamp Tokyo 2019 2日目 セッションデイに一般参加してきましたので、簡単にレポートをまとめたいと思います。
0. 目次
セッション便利なカスタムフィールドに潜む危険な罠 WorePressを使った新しいプロダクト・サービス開発について考える カスタムフィールド製造業からの脱却 WordPressとSSGが織りなす、WordPressウェブフロントの新世界 セッション外での情報収集 アフターパーティ 備考 写真 1. セッション
登壇者氏名の敬称は略とさせていただきます。ご了承ください。
プロフィール
お名前: 須田 樹穂 所属: 株式会社キュービック 職種: フロントエンドエンジニア セッション内容
概要 : サーバがダウンし、それにどう対処したか。原因と対策を究明する対象サイト : カスタム投稿+カスタムフィールドを使った複合検索システムを導入したメディアサイト詳細 :経緯 : 別部署から「レンタルサーバがダウンした」という知らせを受ける原因 : サーバ負荷が急上昇したことなぜサーバ負荷が急上昇したかWordPressの仕組み上、カスタムフィールドはMySQLのwp_postmetaテーブルにインサートされる1項目につき1レコードを使用する1つの投稿で複数のカスタムフィールドを設定すると、1つの投稿に大量のカスタムフィールドのレコードが紐付けられる カスタムフィールドの複合検索にmeta_queryプロパティを使用meta_queryの挙動として、テーブル結合する というものがあるしたがって、複数のカスタムフィールド検索をmeta_queryで行うと、レコードの列数が爆発的に増加して負荷が高くなる 対策 :自分でSQLを書く カスタムフィールドの内容はメインループで絞り込む(=SQLでとりあえずデータを取り出してから、PHPのプログラム側でフィルタリング) カスタムフィールドの罠とは :表面上は手軽なカスタマイズだが、負荷が高まりやすいデータ構造をしている 厄介なのはmeta_queryのSQL文今後、表示速度がSEOに効いてくるのでその面でも不安 備考 :社内体制について仕様書・マニュアルが存在しない 初期仕様を知っている人間がいない 現場で迷走・魔改造が大量発生 これらの要因により、「誰も正確な姿を知らずに爆弾を抱える」ような状態を引き起こした どうすべきだったのか初期仕様はきちんと把握する チームでコミュニケーションをとる 仕様書・マニュアルは引き継ぐためにもきちんと作る 所感
「現場あるある」の体験談を基にしたセッションでした。
話の内容から、
meta_queryを使うとSQL内では
LEFT JOINしていることが窺えます。言われてみれば「確かにそうですよね」と頷くところですが、WordPressの場合は
WP_Queryオブジェクトで上手くラッピングされているので意識が薄まりがちだと思います。
後のセッションで「
wp_postmetaはインデックスを貼っていない」というお話を聞いたので、インデックスを貼っていないテーブルで、滅多矢鱈に
LEFT JOINしたレコードを抽出しようとしたら……それはメモリ負荷が恐ろしいことになりそうだと思いました。
WordPressが単なるWebサイトのツールではなく 、
RDBS(リレーショナルデータベース)を駆使したシステムである ということを改めて認識しました。
対策として挙げられた
自前SQLでなるべく処理を軽くする 抽出条件をSQLではなくPHP側に分散させることでボトルネックを解消する
というのも、システムプログラマとしてよく経験するであろう内容で、この部分でも
サーバサイドプログラム(PHP)とSQLに精通したバックエンドエンジニアが必要 ということが窺えます。
また、後半の「初期仕様を把握している人間がいない」「コミュニケーション不足」「ドキュメントがない」というのも現場あるあるではあるものの、改めて社内ドキュメントが大切であるかを考えさせられました。
プロフィール
お名前: 岡本 秀高 所属: 株式会社DigitalCube 職種: エンジニア(WordPressホスティングサービス「Shifter」「AMIMOTO」のサービス開発を担当) セッション内容
概要 : WordPressの運用に対するマインドセットやソリューションの提案詳細 :WordPressをWebサイトで使う理由ブログやニュースサイト、ECサイト ホスティング etc. 実務の業務テーマ・プラグインの開発 コアアップデートのテスト、本番反映 プラグイン・テーマのアップデート PHP/MySQLなどのアップデート →運用タスクだらけになる 何が起きているのか？脆弱性やバグのパッチ、誰かが修正している より良いサイトを作る為にアップデートをリリース →運用をきちんと回せば、サイトの裏側はより良くなっていく 運用タスクは必要不可欠 現実の問題 :アップデートは使っている個数に比例する サーバ、ミドルウェア、CMS、プラグイン、テーマ、npm、React.js、etc.、… 使用する技術はどんどん増えている 解決の糸口: WordPressから外部のSaaSを利用する : SaaSで試して反応を見る、という始め方依存しないように組み込めば(タグを埋め込むだけ、など)すぐ辞めることができる 辞めやすい・捨てやすいからこそ素早く柔軟に対応できる WordPressをより便利にするSaaSWPのコード量が増える→メンテナンス範囲が増える SaaSのAPIを使うことでWP内部のコードを減らす APIの仕様が変わらなければ影響は少ない SaasのデメリットSaaSの仕様・利用制限・プラン制限に依存する SaaS側の障害の巻き添えを受ける可能性 SaaSを作る為にWordPressを使う : 先ほどとは逆に、WordPressをSaaSとして利用するWP REST API SPA(Single Page Application)サイトをJavaScriptで作るWPのテーマ・プラグインに依存しない実装が可能になる なぜWPをAPIサーバにするかセキュリティ強化のために非公開領域にサーバを置く PWA/AMP対応 フロントエンドとバックエンドを分けることができる SSG(Static Site Generator)でWordPressを使う事前に静的化→高速化＋負荷軽減 編集画面はWordPressのまま 自前で構築する例: Gatsby(React), Nuxt(Vue) サービス例: Shifterランディグページ、コーポレートサイトなど向け WordPressの管理コストを削減する ただし動的出力には一工夫必要ランキング、検索、関連記事、問い合わせフォームなど まとめ運用はきちんとやる。できないなら課金かデグレーションしよう SaaS/FaaSを使って効率的に機能を追加 WP REST APIを使って、WordPressを使ったサービスを考えよう 所感
WordPressのサーバ構築・運用周りにフォーカスして、「単純にWordPress上でテーマ(デザインテンプレート)を変更してサイトを構築」とは異なった趣のサイト構築・運用の提案を示すセッションでした。
WordPressはシステムだからこそ、OS, ミドルウェア(PHP, MySQLなど)といった下層レイヤーから、WordPress本体、テーマ、プラグインといった中間、そしてJavaScriptやHTML, cssといった上層まで、多様なレイヤーの知識・技術が求められます。
それらの運用の負担を軽くするために、
外部サービス連携することで機能の作り込み(+メンテナンス)の負担を軽くする WordPress自体を1つのサービスと見立ててAPIや管理画面の利用に留め、HTML, css, JavaScriptといったフロントエンドをWordPressと切り離すことで負担を分散させる
といった考え方を使い、そのための具体的な手法を示していました。
やはり保守運用は皆苦労するところなのだとしみじみ感じました。
プロフィール
お名前: しずみ 所属: 株式会社サンナナ(代表取締役) / 株式会社CIEL(代表取締役) セッション内容
概要 : カスタムフィールドを駆使したカスタマイズから、ブロックエディタへの転換を図る詳細 :「カスタムフィールド製造業」とは？ :Gutenbergとブロックエディタの違い :Gutenberg: プロジェクトの名前 ブロックエディタ: エディタの名前2018/12まではブロックエディタのことをutenbergを呼んでいた(4.9.x系のプラグインのとき) Gutenbergプロジェクトはまだ継続している これまで行ってきたカスタマイズ :プラグイン「Advanced Custom Field」を駆使した記事編集画面 Advanced Custom Fieldではいろいろ問題点が……カスタムフィールドに全て登録されるので、通常のWordPressの検索ではヒットしない(デフォルトはタイトルと本文のみ) カスタムフィールドも検索対象になるように自前でカスタマイズすれば良い。が時、間がかかる。サーバへの負荷も心配 別テーマに変更されると何も表示されなくなるthe_postのpost_contentsの中に書きこむ処理を自前で実装という荒業でクリア 昨年、ブロックエディタが登場 作業の考え方について 今まではPHPとHTML+cssだったが、JavaScript(React.js)が必要 になった 自前で実装したブロックとそぐわない出力をしている既存コンテンツには警告が出てくれるので、既存ページも変換が可能詳しくは Block Editor Handbook の Block Filters を参照ただし Block Editor Handbook は英語Google翻訳がほぼ違和感翻訳してくれるので大体大丈夫 作りたいものを精査して整理、しっかり設計することが肝心 所感
去年登場したブロックエディタによって、それまで行っていた業務をより便利にカスタマイズできるようになる方法などの例示。
個人的なカスタムフィールドとブロックエディタの比較として
検索 :カスタムフィールド:WordPressデフォルトの検索にはヒットしない(検索フォームや検索ロジックに自前のカスタマイズが必要) カスタマイズ前提の複合条件検索の内容によってはブロックエディタでは賄えないことがある(数値の大小比較など) ブロックエディタ:WordPressデフォルトの検索でヒットする(本文部分にコンテンツが格納されるので) テキストの検索であれば使えるが、複合条件検索の内容によっては不向きな場合がある 拡張性 カスタムフィールド:同じパーツを繰り返す(例: 画像を任意の枚数を売乳する)のは難しい 縦に分割されたコンテンツの列数を増減させるのは難しい ブロックエディタ:同じパーツを繰り返すことができる デフォルトで用意されているブロックで、縦に分割されたコンテンツの列数を増減させることが可能
といったところが挙げられると思います。
テキストベースのコンテンツのレイアウトや流用性・拡張性ではブロックエディタが有用ですが、カスタムフィールドの全てがブロックエディタで置換できるかというと、カスタムフィールドの方が有利な場面もあり、ケースバイケースで使い分けることができるのがベターだと思います。
また、ブロックエディタをカスタマイズする場合はNode.jsやReact.jsといった最近の高度なJavaScriptを必要とする場合が多いため、技術スキルの専門性が高まるということも留意事項として挙げられます。
こうした点を考慮して、上手く付き合うことができれば良いと思いました。
WordPress と SSG(Static Site Generator) が織りなす、WordPress ウェブフロントの新世界 | Slides | Riotz.works
プロフィール
お名前: 江藤 武司 所属: Riotz Works セッション内容
概要 : WordPressとSSGを組み合わせた新たなWebの開発手法の提案詳細 :WP Webフロント世界このセッションの「Webフロント」＝サイトのデザイン・見た目部分を構築する技術 テーマ HTML, css, JavaScript + PHPの知識・スキルが必要 WebフロントとJAMStack + SSGJAMStack “予めHTML化されたWebサイト”を配信する形式のフロント開発技術 JavaScript, API, Markupの組み合わせ 動的要素はWeb APIを利用 “予めHTML化されたWebサイト”を作るためのツール: SSG SSG(Static Site Generator) 静的サイトの生成: テンプレート等からHTMLなどのページファイルをコマンドやシステム連携で自動的に生成 メリットStaticなのでCDNからの配信が高速 HTML生成処理のオフライン化→セキュリティ的に安全 開発者はデータとデザイン(フロントエンドとバックエンド)を分離できるこの部分に注目すると、WPテーマ開発のPHPやMySQLの部分を分けることができる 代表的なSSGパッケージGatsby (React.js)Gridsome (Vue.js) 開発フレームワーク WordPressとSSGの組み合わせ方WordPressのWP REST APIを使用 Gatsby, GridsomeはWordPress対応プラグインがある Nuxt.jsなどはHTTP Client経由でWPへのアクセス、動的な描画(完全な静的も可能) WordPress + SSGのメリットWordPressのエディタとコンテンツ管理の能力を活かせる Webフロントは静的にできるのでパフォーマンスやスケーラビリティのメリットを享受 開発者の役割を分離できる WordPress + SSGがもたらすもの 再考WordPressの環境構築は必要 技術的にNode.jsが増える 解決策 : WPの実行基盤をServerless, Managed, as a Serviceにしてしまうアップデートやメンテナンスのコストをなくす コンテンツ作成・管理に特化し見た目の部分を使用しないCMSはHeadless CMS となる Shifterを使う メリット :WPの運用コストを抑える 開発をフロントエンドエンジニアで完結させる まとめ :JAMStackのメリットは大きい WPをHeadless CMSとして使い、JAMStackのメリットを享受 HeadlessなWordPress + JAMStack/SSGの市場を創出へ 所感
他の技術と組み合わせることで、WordPressのコンテンツ管理の部分とデザインの部分を切り離し、新たな価値を提案する内容のセッションでした。
先の「WordPress as a Service ? WordPressを使った新しいプロダクト・サービス開発について考える」のセッションとも重複しますが、
アップデートなどの運用部分も管理するサービスの「マネージド(managed)」やクラウドを利用する 開発環境内でコンテンツを取得・含んだ状態で静的サイトとして生成してしまう
ということでセキュリティなどのリスクを下げつつ、表示の高速化などのメリットを受けるという新しい開発・運用のワークフローが提示されました。
毎日のように更新するようなサイトではなく、更新頻度の少ないコーポレートサイトやランディングページのような期間限定ページでは上手く利用できると思うので、自分でも上手いことができないか考えさせられました。
なお、「開発環境内でコンテンツを取得・含んだ状態で静的サイトとして生成」の場合ですが、運営者によるWordPressの更新を開発環境がどのように検知するか、という点(いわゆる「ビルド」「デプロイ」の部分)が個人的に気になったので質問したところ、
自前で環境構築、SSGを利用する場合: CI(継続的インテグレーションのツール)と連携する Next.jsやNuxt.jsを使って自前でプログラムする場合: アクセスの度にWordPressサーバにデータを取得するようにプログラミングする(動的生成。ただしブラウザ上で動くクライアントJavaScriptではなく、Node.jsをインストールしたサーバ環境内で動くサーバサイドJavaScriptとして。その意味ではPHPと立ち位置的には近い) Netlify(Node.jsベースのホスティングサービス)を使う
といった方法が考えられるとのことでした。
したがって、「JavaScriptで完結できる」という意味ではバックエンドとフロントエンドは分離できますが、代わりに(ここ最近の新しい)JavaScriptの高度な知識が必要になると思われます。
また、他の方法としてCIとの連携となるとそうした環境の知識・技術も必要になるため、継続してスキルアップが必要だと感じました。
2. セッション外での情報収集
スポンサーブースでいくつか情報収集もしました。
AMP
特に印象に残ったのは、GoogleのサーバがキャッシュしてくれるAMPですが、暫く見ないうちにカルーセル等のアニメーション的な要素にも対応し、Webコンポーネント化していたことでした。
数年前は静的サイトの高速キャッシュ、というイメージだったのですが……いつの間にこんなに化けていたのか……。
Snow Monkey
ブックの熱量が凄かったです！
……これ本当にノベルティで良いのでしょうか？
3. アフターパーティ
アフターパーティはダンスクラブでした。去年とは違う場所で、音が小さい小ホールも用意されていたので大声でなくても会話ができる、ということで進化していました。ありがたいです。
4. 備考
どのセッションでも、登壇者の発声とほぼ同時に文字起こし、英語翻訳されたものがスクリーンに表示されていました。
これは
UDトーク というアプリを使用していたようです。
凄まじいテクノロジーの進歩を感じました……。
5. 写真
以下写真を。
アフターパーティ会場への移動の途中でスバルビル跡地の「新宿の目」も観てきました。
WordCamp Tokyo 2019 WordCamp Tokyo 2019 スタンプラリー チョコ 新宿の航空障害灯 新宿の航空障害灯 新宿の航空障害灯 スバルビル跡 新宿の目 スバルビル跡 新宿の目 スバルビル跡 新宿の目 WordCamp Tokyo 2019 アフターパーティ会場 WordCamp Tokyo 2019 アフターパーティ会場 WordCamp Tokyo 2019 アフターパーティ会場 WordCamp Tokyo 2019 アフターパーティ会場
アルム＝バンド 
