PHPerKaigi 2020 でイベントソーシングについて発表しました
こんにちは、ナカエです。
2020/02/9〜11に行われた PHPerKaigi 2020 に参加してきました。 遅ればせながら参加レポートです。
I will blog → I blogged.
発表資料
「PHPとEventSauceで始めるイベントソーシングアプリケーション」というタイトルで登壇させていただきました。
サンプルコード: n1215/eventsauce-example
発表補足
イベントソーシングに関連する用語や概念の混乱とそれに起因する入門者の心理的ハードルの高さを取り除きたい、というのが今回の１つ目の発表動機です。
イベントソーシングというのは DDD + CQRS + イベントソーシング + α のような複雑な混合物を指すのではなく、もっと身近な、みなさんがすでに取り入れてるかもしれないもっとシンプルな何者かである、という点が伝えられていれば幸いです。
もう一つの発表の動機として、非同期メッセージ駆動なシステム設計の話を最後に付け加えたのですが、駆け足だったので時間が足りませんでした。 イベントソーシングを採用しなくてもメッセージ駆動の設計はできます、というところを強調しそこねた気がしています。
個人的にお話させていただいた方々にはインフラを変化させずに始めやすい、データストアを分けないイベントソーシング+CQRS風の設計をオススメしていました。 全面採用するしないの0/1の二択ではなく、イベントソーシングを活かせる美味しい箇所を一部だけでも見つけたり、段階的な導入方法を探ることで、アプリケーション設計の選択肢が広がればと思います。
トランザクションについて
Q & Aでイベントソーシングとトランザクションは相性が悪いのではという質問をいただきました。
イベントソーシングそのものとトランザクションの相性が悪いのではなく、データストアを分離するレベルのCQRSなど、分散システムとトランザクションの相性が悪いというのが正確なところです。 データ不整合が起こりにくいようにシステム間のトランザクション境界を適切に設計するのが第一ですが、分散システムを考える上では、一時的にデータの一貫性がない状態を許容する結果整合性で妥協することも必要になってきます。
マイクロサービスにおけるデータの整合性担保の困難さや適切な分割の難しさについてはすでに多くが語られているとおりです。そう簡単にできたら誰も苦労していませんね。
リトライ処理と処理の冪等性担保、操作のロールバックのための補償トランザクションなどを考える必要があります。イベントソーシングを採用している場合は、たとえばイベント自体に仮処理と確定の２つを用意するなどの変更が考えられます。いずれにしても、単体のシステムを設計する場合に比べて状態遷移や処理のシーケンスについて厳格に検討することになるでしょう。
RESTとの相性について
イベントソーシング+CQRSとREST APIとの相性が良いのでは？という質問もいただきました。
- CQRSの観点では、処理の冪等性と安全性によりHTTPメソッドを使い分けるRESTとは発想が同じであり親和性が高いと思われる。
- イベントソーシングを採用したとしても、同期的にリソースの状態をレスポンスに含めて返すことはできるが、CQRSの理念には違反している。クライアントがリソースの最新の状態を自ら取得しに行くのでは知識を持たせ過ぎなので、クライアントに非同期的にサーバ側からリソースの状態を通知する仕組みが必要そう。
という浅い回答になってしまい申し訳ないです。
セッション外のAsk the Speakerや立ち話で
- 同期的なレスポンスの処理に慣れた開発者、ユーザをどう非同期なアプリケーションに対応させていくのか、UIから考える必要があるのではないか
- 非同期なアプリケーションの場合はサーバに関する知識を抑えてクライアントで使えるようにするのはRESTで同期的なアプリケーションの場合よりとても難しそう。RESTならクライアント側がほとんど何も知らなくてもハイパーリンクをたどってアプリケーションと対話できる
- クライアントが非同期でリソースの状態を購読する設計にする場合、サーバ側のセッションの寿命が長くなるので考えるべきことが増える
- イベントによる疎結合な設計は全体像の把握が難しい。ビジュアライゼーションなどによりシステム全体の繋がりを開発者が把握できるようにしないとチーム開発は厳しいのでは
などと言ったお話をさせていただき、非常に勉強になりました。
聴講したセッション/LT
- マルチパラダイムモデリング 〜異なるモデリングパラダイムから見るモデリングの勘所〜
- Inside SWOOLE：非同期処理はどのようにして動くのか
- レンサバけもの道
- forteeに脆弱性診断をかけてみた
- AWS Lambda にCustom RuntimeでPHPを導入したシステムに改修を加えてUT導入まで行った話
- Zend VMにおける例外の実装
- もしもPHPソースコードが読めたなら...
- RFCの歩き方
- PHPとRustを組み合わせて音声ファイルをエンコードする話
- 自分の名前を"ちゃんと"入力したい人生だった
いろいろな題材がバランス良く揃っていたと感じます。個人的には、PHPの低レイヤに興味が深まりました。
PHPer茶会、懇親会
1日目、２日目とも終了後の懇親イベントが企画されていました。
1日目はGMOインターネット presentsのPHPer茶会。前年度PHPerチャレンジ優勝者 nrsさん によるPHPerチャレンジ攻略法のセッション、充実のフード、飲み物と余りあるバドワイザー、そして恒例となったボードゲームのテーブル。
ぼくはバドワイザーの消費に協力していたのでお茶は飲んでいません。瓶があるんですねバドワイザーって。バドワイザーを買い過ぎなのでは？
2日目の懇親会は話し込んだりLTを聞いていてあまりフードを食べていないのですが、長谷川スペシャルなハンバーガーとクラフトビールの品揃えが最高でした。NE IPA ねこにひき、覚えたぞ。
その場で懇親会LTのタイムテーブルが書き換えられていたり他薦のLTがねじこまれたりで非常にリアルタイム感がありましたね（オブラートに包んだ表現。
参加者同士の交流促進の仕組み
Tack CのAsk The Speaker、IRT、アンカンファレンスブースなどなど、今年も参加者同士の交流を促進する仕組みが充実していました。
Ask The Speakerで質問に答えたり、逆に@koriymさんに色々教えていただいたのをはじめ、突発的に無限LTが始まっていたアンカンファレンスブースや@ytakeさんのLaravel相談会にお邪魔させてもらいました。Swooleの話も盛り上がっていましたね。Track Cが楽しすぎて聞こうと思っていたセッションをいくつかすっぽかしました。
様々な仕組みの中でも面白い試みとして参加者全員が評価していたであろうのは、参加者のTwitterアイコンを印刷したトレーディングカード。
ゲット pic.twitter.com/SZyFjYWeLZ
— n (@n_1215) February 9, 2020
他の参加者の方と話を始めるきっかけとして絶大な威力を発揮しており、「 カードを交換してもらってもいいですか？」からの交流が各所で見られました。
カードがだいぶ余ったので、今年参加するPHP系のカンファレンスに名刺代わりに持っていこうと思っています。
飲み会など
0日目にはダチョウ肉その他を食べながらオフライン初対面多めの皆様と技術の話をする機会がありました。楽しすぎてかなり長引いてしまい、飲んだ後に翌日発表のスライドを仕上げるのはかなりギリギリでした。
話し込みすぎたので今からスライドを仕上げる展開
— n (@n_1215) February 9, 2020
懇親会後には焼肉界隈の有名な方々と一緒に焼肉を食べる実績を解除しました。 イベント自体も交流要素が盛りだくさんでしたが、公式企画外での交流もいろいろと満喫できました。
まとめ
懇親会LTで制作秘話の紹介のあったPHPerトレーディングカードもタイトなスケジュールで制作されたそうですが、オープニング/クロージングの動画のクオリティ、各種表彰、懇親会のハンバーガーやビールのセレクト、その他ノリで決まった（ように見える）内容が実際に実行されるところがPHPerKaigiの恐ろしいところですね。運営側も全力で考えて全力で楽しんでいるのが伝わってきます。
まさにPHP界隈最強の同窓会イベントという風格ですね。 運営スタッフ・関係者の皆様、最高のイベントをありがとうございました。
来年もぜひお願いします！
