イベント駆動コンテンツ

Webアプリケーションの効率を再定義するBEAR.Sundayの分散キャッシングフレームワーク

2024/3/9にPHPerKaigi 2024 でイベント駆動コンテンツ（Webアプリケーションの効率を再定義するBEAR.Sundayの分散キャッシングフレームワーク）という40分のトークを行いました。

最初のスライド

first slide

「まず、スライドをご覧ください。雲から楽しそうな物がぶら下がっているのをクマが見ています。これは何の象徴でしょうか。」

トークの冒頭でこのような呼びかけを行いました。

これから話すことは分散キャッシングなので、家の中に出現したクラウドからサービスが提供されているということを表しています。このクマの視線はぶら下がっているサービスではなく、クラウドに向いています。つまり、サービスを生み出す仕組みを注視しているのです。これは、常に問題の本質を見つめるという姿勢の象徴になっています。

名前は世界へのシンボリックリンク

human

「名前は意識の世界から現実世界へのシンボリックリンクであり、同一性確認のためのトークンとしての役割を果たしている」ということを、冒頭の「なぜタイトルを変更してはいけないのか」というアイスブレイクの理由に関連付けつつ、キャッシュの「同一性確認」にも繋げています。

名前には、トークンとしての役割（短く覚えやすいほどいい）と、内容表明としての役割（説明が豊かな方がいい）という矛盾した側面があります。これがコンピュータサイエンスにおける二大難問の一つ「名前付けの困難」の理由になっていることに触れつつ、もう一つの難問である「キャッシュ」というテーマへと話を展開していきます。

このように、各スライドでは話の伏線を張りながら、全体を通して一つの物語を紡ぎ出すように構成しました。

このトークを聞いて「映画のようだった」と評してくれた方がいました。最初は何故そう思ったのだろうと感じましたが、張り巡らした伏線やスライドの背後にあるメッセージと物語性を感じ取ってくれたのだと思います。

誰のために何を作るのか

reuse

このスライドの部分は全体を通しても最も重要なスライドの1つです。キャッシュを”how”ではなく、”what”として捉えることで、本質に迫ります。つまり技術的な詳細に焦点を当てるのではなく、キャッシュが果たす本当の役割に注目しました。

キャッシュ、つまりkey value storeによる保存を関心による保存の最適化である事としたことは、 CQRS(Command Query Responsibility Segregation、コマンドとクエリの責任分割)の考え方そのものです。（実際このパッケージの名前はBEAR.CacheなどではなくBEAR.QueryRepositoryです。）

ユーザーが真に望んでいるものは、「揮発性が高く常時消せるもの」というより、実は「本質的に永続的なもの」のであるという新しい視点を提示し、キャッシュは「なるべくなら使わなくていいもの」という考えから「ここにこそ本質的な価値がある」という真逆の価値観への反転を促します。

ゴールを示しながらアイデアの起点として語りました。

Outlook is gold

問題解決に決定的な影響力を与えるのは、問題の解法ではなく問題の定義や問題の捉え方

かつてAlan Kayはこの事をOutlook is goldとして表しました。私はこの考えに大きな影響を受けていて、BEAR.Sundayの設計哲学の一つでもあります。

キャッシュの問題を捉える視点を変えることで、根源的で決定的な解決ができるのでは無いかと考えました。オリジナルのアイデアはもう10年以上前、BEAR.Sundayの生まれる前からありました。しかしこれをどのように実現したらいいのかなかなか良い案が浮かびませんでした。しかしタグベースでの依存解決やモダンCDNのインスタントパージ、その他のアイデアや技術の進化が重なり、ようやく実現できる時が来たと感じ、実装に着手しました。

このトークの後半で語る不易の積み重ねそのものでした。

PHPNWから10年

first slide

私が初めてカンファレンスで登壇したのは、2013年にイギリスで開催されたPHPNWです。 BEAR.Sundayは無名でトークはその設計哲学についてだったにもかかわらず好評を博しました。大事なのは知名度ではなく、アイデアやインスピレーションを与えられるかどうかだと学びました。

イギリスでの成功を受けて、日本でも同じプレゼンテーションをしたいと思い、全国のPHPカンファレンスに応募しました。しかし、福岡、大阪、東京のPHPカンファレンスで全て落選してしまいます。

それでも2018年にPHPerKaigiで機会を得てトークを行い、今回で再度BEAR.Sunday関連の登壇となりました。採択の可否の理由は応募者には分かりませんが、この10年間、BEAR.Sundayについてカンファレンスでトークができたのは、PHPNW、PHPerKaigi 2018、そして2024の3度だけです。

改めまして、会場に来て聞いてくださった皆さん、オンラインで視聴してくださった皆さん、本当にありがとうございました。また、登壇の機会を与えてくださったPHPerKaigiのキュレーターの皆さんや、当日お世話になったスタッフの皆さんにも感謝します。

Q&A

Q&Aでは3人の方から以下の興味深い質問、感想をいただきました。Q&Aが終わった後に、伝えきれなかったことに思いが及んだので、ここで改めて答えたいと思います。

Q1. DI/AOP/RESTのフレームワークがなければ今回のキャッシングフレームワークに辿り着けなかったと思うのですが、いつこのアイデアを思いついたのですか？

A1. 「イベントドリブンコンテンツ」という言葉は知りませんでしたが、「破壊的変更が行われるまで消去されないリソースキャッシュ」のアイデアはBEAR.Sundayの設計時からありました。しかし当時はどうすれば実現の足掛かりができるのかすら分かりませんでしたし、実現するにしてもサーバーサイドのキャッシュで行うつもりでした。またCQRSの提唱者のGregさんのCQRS meets RESTの考えにも影響を受けていました。

BEAR.Sundayはフレームワークをコンポーネントの集合ではなく、アプリケーションの全体制約として捉えています。キャッシュを単なる呼び出しライブラリではなく、制約と呼べるものとして捉える方針は当初からあり、3つのオブジェクトフレームワークに続く第４のフレームワークとしての位置づけました。

最初はコンテンツの依存解決のためのDSLを作るというアイデアもあり、実際にその設計を部分的に始めました。しかし、すぐにその運用では不安が残ることにも気づきました。「期限のないキャッシュ」を実現するために、キャッシュから可能な限り実装者の責任を取り除く必要がありました。

タグによる依存管理
モダンCDNのインスタントパージ
部分キャッシュ（ドーナッツキャッシュ）
ETagレポジトリの管理

キャッシュをフレームワークとして実装するには上記の4つのキーテクノロジーが必要でした。 CDNでタグ消去ができることは以前から知っていましたが、RedisのエンジンだけでなくSymfony Cache全体でサポートがあり、これをコンテンツ依存解決と組み合わせられること、そしてFastlyのThe Rise of Event-Driven Contentの記事を発見したこと、これらの理解でかねてよりのアイデアであった「破壊的変更が行われるまで消去されないキャッシュ」の実現が可能であると確信しました。

部分キャッシュとASP.NETの記事を発見した時も同じことを考え実装していた人たちがいたということが力になりました。こうやってそれぞれの技術の進歩や、他の人たちも自分と同じようなことを考えていることを知ることで完成への確信が持てるようになっていきました。

Q2. 変わるもの、変わらないもの、見極めをどのようにするか？

A2. 優れた制約は変わらない、まずこの一点が重要です。Webは30年以上の歴史があり、様々な技術が登場しては消えていきましたが、HTML、URI、HTTP、この3つのキーテクノロジーはほとんど変わっていません。問題に対する思考態度は大事です。それが制約として耐えうるものなのか、それとも単に要求や技術の一部なのかを見極めることが肝要だと思います。

AOPのインターフェイスは2004年3月のリリース以来、一度も破壊的変更が行われたことはありません。5・7・5の俳句の形式を確立したのは松尾芭蕉だと言われていますが、これも変わりません。トークでも紹介しましたが、BEAR.Sundayは最初の安定版リリース以来、破壊的変更を行ったことはありません。これはWebアプリケーションの「変わらないRESTの制約」をアプリケーション全体の制約として適用したその設計が成功している証拠であり成果です。

不易なのか流行なのかを見極めるためには、その技術が持つ問題解決の本質を見極めることが大事です。

Q3. オレオレフレームワーク開発者としての勇気をもらった。

A3. ユーザー数が極めて限られているフレームワークを開発し維持し続けることに対して、無駄でナンセンスだと批判したり嘲笑したりする人は少なくありません。

しかし大事なのは、少数でも興味深いクライアントと、興味深いプロダクトに関わり、興味深い技術を維持開発できるかどうかです。興味深い仕事ができるのであれば、ダウンロード数やGitHubスターの数は大事ではありません。時に「Qiitaに載ってない」と文句を言われることがあるかもしれません。しかし、そんな人が大勢ユーザーになってくれても、プロジェクトを前に進める力にはなりません。

技術的な投資はしなくていいし、したくないということが当たり前になり、カンファレンスで「道具の使い方」が多く話されるのに対して、「道具を作る」話やそのアイデアを聞くことが少ないのを残念に思っていました。

私はキャリアの初めに、ごく少数の人たちがイノベーションを起こすのを目にしてきました。そして、それはその後のキャリアに決定的な影響を与えました。数は決定的な要因ではありません。重要なのはアイデアであり、物の見方、思考態度です。それを持っている人たちと一緒に仕事をして、興味深い技術に関われれば、それが最高です。

これは本来大きなテーマで、もっと深く語りたいところですが、また機会があればお話ししたいと思います。質問者の方が「勇気をもらった」と言ってくれたことは、とても嬉しかったです。私にとっても大きな励みになりました。共に頑張りましょう。

スライド

スライドの挿絵にDALL·Eで生成した画像を使いました。AIが抽象的な概念を具体的に表現する能力には驚くばかりです（「再起を表してください」のプロンプトで合わせ鏡の中に立つクマが出てきた時は脱帽しました) また、スライドのデザイン調整には弁護士ドットコムのデザイナーの鈴木さんにご協力いただきました。ありがとうございました。

トーク動画

Keynoteで録画した映像があります。

https://www.youtube.com/embed/GWkoWWXoLko?si=AAnmVNkATJoCr9yP

不易の力

ending

このトークの創作は困難を極めるものだろうという事は最初から予想していました。 10年に渡るアイデアの積み重ねや問題提起を、メタな視点を持ちながら興味深い技術詳細も織り交ぜ、その思考態度や制約を物語性を持って語ることは容易なことではありません。

一つのカンファレンストークとして成り立つほどの深いテーマを扱ったスライドがいくつもありました。扱う技術やトピックは広く深いものでしたが、シンプルなメッセージとして伝えたいと思いました。芭蕉の「不易流行」はその助けになりました。

多くのアイデアや技術を駆使して実現したのは、Webが30年以上前に最初から持っていたRESTのキャッシュ制約です。そこに新しいものは1つもありません。Webが最初から持っていた優れた制約へのリスペクトと、それがいかに私たちが抱える問題を解決するのかを示したかったのです。これこそが不易です。

技術的な解決策ではなく問題の捉え方や定義にこそ決定的な解決力があること、開発者の都合ではなくユーザーの本当の望みに焦点を当てること、不易を重ねることの強さ。それらを伝えたかったのです。

感想

その他に主催者経由で熱のあるフィードバックを多数いただきました。聴く人をドライブしたいという思いが伝わったようで、とても嬉しいです。ありがとうございました。