WordCamp Tokyo 2019 参加レポート

WordCamp Tokyo 2019 2日目 セッションデイに一般参加してきましたので、簡単にレポートをまとめたいと思います。

0. 目次

1. セッション
   1. 便利なカスタムフィールドに潜む危険な罠
   2. WorePressを使った新しいプロダクト・サービス開発について考える
   3. カスタムフィールド製造業からの脱却
   4. WordPressとSSGが織りなす、WordPressウェブフロントの新世界
2. セッション外での情報収集
3. アフターパーティ
4. 備考
5. 写真

1. セッション

登壇者氏名の敬称は略とさせていただきます。ご了承ください。

1.1. 便利なカスタムフィールドに潜む危険な罠

WordCamp Tokyo2019 「便利なカスタムフィールドに潜む危険な罠」 from mikihosuda

プロフィール

• お名前: 須田 樹穂
• 所属: 株式会社キュービック
• 職種: フロントエンドエンジニア

セッション内容

• 概要: サーバがダウンし、それにどう対処したか。原因と対策を究明する
• 対象サイト: カスタム投稿+カスタムフィールドを使った複合検索システムを導入したメディアサイト
• 詳細:
  • 経緯: 別部署から「レンタルサーバがダウンした」という知らせを受ける
  • 原因: サーバ負荷が急上昇したこと
  • なぜサーバ負荷が急上昇したか
    1. WordPressの仕組み上、カスタムフィールドはMySQLのwp_postmetaテーブルにインサートされる
       • 1項目につき1レコードを使用する
         • 1つの投稿で複数のカスタムフィールドを設定すると、1つの投稿に大量のカスタムフィールドのレコードが紐付けられる
    2. カスタムフィールドの複合検索に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に精通したバックエンドエンジニアが必要ということが窺えます。

また、後半の「初期仕様を把握している人間がいない」「コミュニケーション不足」「ドキュメントがない」というのも現場あるあるではあるものの、改めて社内ドキュメントが大切であるかを考えさせられました。

1.2. WordPress as a Service – WordPressを使った新しいプロダクト・サービス開発について考える

プロフィール

• お名前: 岡本 秀高
• 所属: 株式会社DigitalCube
• 職種: エンジニア(WordPressホスティングサービス「Shifter」「AMIMOTO」のサービス開発を担当)

セッション内容

• 概要: WordPressの運用に対するマインドセットやソリューションの提案
• 詳細:
  • WordPressをWebサイトで使う理由
    • ブログやニュースサイト、ECサイト
    • ホスティング
    • etc.
  • 実務の業務
    • テーマ・プラグインの開発
    • コアアップデートのテスト、本番反映
    • プラグイン・テーマのアップデート
    • PHP/MySQLなどのアップデート
  • →運用タスクだらけになる
  • 何が起きているのか？
    • 脆弱性やバグのパッチ、誰かが修正している
    • より良いサイトを作る為にアップデートをリリース
    • →運用をきちんと回せば、サイトの裏側はより良くなっていく
    • 運用タスクは必要不可欠
      • スパムばら撒き、改ざんなどのリスク
  • 現実の問題:
    • アップデートは使っている個数に比例する
    • サーバ、ミドルウェア、CMS、プラグイン、テーマ、npm、React.js、etc.、…
    • 使用する技術はどんどん増えている
  • 解決の糸口:
    • 「やらない」ではなく「自分でやらずに済ませる」
      • アップデート対象を減らせばタスクは減る
  • WordPressから外部のSaaSを利用する: SaaSで試して反応を見る、という始め方
    • 依存しないように組み込めば(タグを埋め込むだけ、など)すぐ辞めることができる
    • 辞めやすい・捨てやすいからこそ素早く柔軟に対応できる
  • WordPressをより便利にするSaaS
    • WPのコード量が増える→メンテナンス範囲が増える
    • 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と切り離すことで負担を分散させる

といった考え方を使い、そのための具体的な手法を示していました。

やはり保守運用は皆苦労するところなのだとしみじみ感じました。

1.3. カスタムフィールド製造業からの脱却 ～ブロックエディター（Gutenberg）をカスタムする方法～

プロフィール

• お名前: しずみ
• 所属: 株式会社サンナナ(代表取締役) / 株式会社CIEL(代表取締役)

セッション内容

• 概要: カスタムフィールドを駆使したカスタマイズから、ブロックエディタへの転換を図る
• 詳細:
  • 「カスタムフィールド製造業」とは？:
    • カスタムフィールドを駆使してWPサイトを作る仕事
      • Capital P(国内有数のWordPress情報サイト)より引用
  • 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を必要とする場合が多いため、技術スキルの専門性が高まるということも留意事項として挙げられます。

こうした点を考慮して、上手く付き合うことができれば良いと思いました。

1.4. WordPress と SSG(Static Site Generator) が織りなす、WordPress ウェブフロントの新世界

WordPress と SSG(Static Site Generator) が織りなす、WordPress ウェブフロントの新世界 | Slides | Riotz.works

プロフィール

• お名前: 江藤 武司
• 所属: Riotz Works

セッション内容

• 概要: WordPressとSSGを組み合わせた新たなWebの開発手法の提案
• 詳細:
  • WP Webフロント世界
    • このセッションの「Webフロント」＝サイトのデザイン・見た目部分を構築する技術
    • テーマ
    • HTML, css, JavaScript + PHPの知識・スキルが必要
      • データベースも操作するのであればSQLも
  • WebフロントとJAMStack + SSG
    • JAMStack
      • “予めHTML化されたWebサイト”を配信する形式のフロント開発技術
      • JavaScript, API, Markupの組み合わせ
        • 構築済みのマークアップの部分を「SSG」で行う
  • 動的要素はWeb APIを利用
  • “予めHTML化されたWebサイト”を作るためのツール: SSG
  • SSG(Static Site Generator)
    • 静的サイトの生成: テンプレート等からHTMLなどのページファイルをコマンドやシステム連携で自動的に生成
  • メリット
    • StaticなのでCDNからの配信が高速
    • HTML生成処理のオフライン化→セキュリティ的に安全
    • 開発者はデータとデザイン(フロントエンドとバックエンド)を分離できる
      • この部分に注目すると、WPテーマ開発のPHPやMySQLの部分を分けることができる
  • 代表的なSSG
    • パッケージ
      • Gatsby (React.js)
      • Gridsome (Vue.js)
    • 開発フレームワーク
      • Next.js
      • Nuxt.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ベースのホスティングサービス)を使う
  • Shifterもnetlifyへ投げる機能あり

といった方法が考えられるとのことでした。

したがって、「JavaScriptで完結できる」という意味ではバックエンドとフロントエンドは分離できますが、代わりに(ここ最近の新しい)JavaScriptの高度な知識が必要になると思われます。

また、他の方法としてCIとの連携となるとそうした環境の知識・技術も必要になるため、継続してスキルアップが必要だと感じました。

2. セッション外での情報収集

スポンサーブースでいくつか情報収集もしました。

AMP

特に印象に残ったのは、GoogleのサーバがキャッシュしてくれるAMPですが、暫く見ないうちにカルーセル等のアニメーション的な要素にも対応し、Webコンポーネント化していたことでした。

数年前は静的サイトの高速キャッシュ、というイメージだったのですが……いつの間にこんなに化けていたのか……。

Snow Monkey

ブックの熱量が凄かったです！

……これ本当にノベルティで良いのでしょうか？

3. アフターパーティ

アフターパーティはダンスクラブでした。去年とは違う場所で、音が小さい小ホールも用意されていたので大声でなくても会話ができる、ということで進化していました。ありがたいです。

4. 備考

どのセッションでも、登壇者の発声とほぼ同時に文字起こし、英語翻訳されたものがスクリーンに表示されていました。

これはUDトークというアプリを使用していたようです。

凄まじいテクノロジーの進歩を感じました……。

5. 写真

以下写真を。

アフターパーティ会場への移動の途中でスバルビル跡地の「新宿の目」も観てきました。

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

•