コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『CQRS+ESカンファレンス』に行ってきたよメモ

行ってきたメモ

『CQRS+ESカンファレンス - connpass』に参加してきたのでそのメモです、

各発表の感想

※資料スライドは見つけたら貼ります。

ドメインイベントで描く未来: CQRS/ESが変えるシステムとDXの可能性

スライドは公開予定ではないということなのでブログを…

CQRS+ESカンファレンス(2024)を開催しました - ytake blog](https://blog.ytake.jp.net/entry/2024/12/24/090000)

感想

  • CQRS/ESをなぜ採用すべきか、というところと基本的な考え方を駆け抜けてサマリで説明
  • イベントを記録すれば後に違う角度で見たくなったときにも見えるという話や、機能的結合や時間的結合の話など改めて重要フレーズピックアップしたいような話でした。
  • 「データはイベントの蓄積である」という考え方をどれだけ持てるかが重要という話は頭に入れながら色々作るときに考えるとよいのかなと思いました。

関連リンク

2年間の実運用を経て振り返るイベントソーシングの実際

感想

  • 中小規模システムのためのCQRS+ESのフレームワークであるSekibanの紹介
  • 大きなものでないと恩恵を受けられないのではないか？というところへの1つの解になりそうな話でした。
  • 作ってみると遭遇しそうな疑問に関してのQ&Aはかなり後続で続く人たちのためにもなる情報に思えました。

関連リンク

いろんな機能をCQRS+ESで作ってみたので皆で所感を見てみよう

感想

  • AxonIQを使ったEventSourcingを用いた実システム作り方
  • 題材としてはAPIサーバを取り扱い、イベントがどのように保存しされ、Queryに使われるテーブルはどのような形になるのかという話をコードを追いながら解説されていました。
  • AxonIQがカバーしている部分もあるので、細かいところが気になったが全体感の理解としては進んだ
  • 最後に紹介のあったイベントストーミングをした図からChatGPTでAxonIQのコードがある程度起こせるデモがあり、雛形作成でここまでいけるのかーという驚きがあった。

関連リンク

イベントの使い方を一度身につけてしまったら、もうそれなしでは生きられなくなるだろう

スライドリンクは公開されたら貼ります

感想

  • 既存システムでのつらみ経験から導入していく家庭のお話
  • 「イベントがほしい」というところからCQRSへだんだん行く過程のお話だったので途中で時間切れになってしまい残念
  • イベントが始点で話をすると結果としてCQRS側へ帰結するんだろうなぁと思いました。

関連リンク

アクターシステムに頼らずEvent Sourcingする方法について

感想

  • ESはアクターモデルがないとできないのではないか？というところに対してのアプローチの話
  • AWSが提唱しているモデルのよくないところを交えつつ、実績のあるKJ法（KatoJun）も紹介されていて、実装したいときの参考になりそうな内容だった
  • 練度が低くてまだうわべだけしか見えていない感じがしたので、もう少し実践的な知識をえたら見直したい

関連リンク

パネルディスカッション

ディスカッション内容

Q. 外部インターフェイスとしては何を採用しているか（REST、gRPC、など）

tomohisaさんはsekibanを使っているためRESTスタイル、鈴木さんはgRPCを利用しているという話をされていた。かとじゅんさんはCommand側はRPCスタイル、ReadモデルはRESTスタイルと使い分けの話をされており、RESTはCommandとの相性問題があるのでその形式が多いと話されていました。成瀬さんはAxonを利用しているためそのあたりはフレームワークが勝手にやってくれているので意識していない旨のお話をされていました。

Q. Protocol Buffersのプロトコルはどうやって共有しているか

かとじゅんさんは他のシステムと連携するかどうかの観点で話をされており、クライアントとサーバーどっちで主管をするか決めて、運用する旨の話をしていました。鈴木さんは単一のアプリケーションに閉じているので、専用のディレクトリを用意して運用している旨の話をされていました。

Q.複雑なシステムじゃなければCQRS+ESは不要かと思うんですが、いるいらないの基準があるか

この話においては、パネルディスカッションのメンバー全員がCQRS+ESの実践者なのでどの方も大小かかわらず使いたいという意見でした。その中で出た意見で印象的だったのが以下の話です。

  • 採用しないとCRUDな作りになるので、データベースの考慮を入れると純粋なドメインモデルとのひずみが出る。そのときに手をいれる必要があるので、それであれば最初からやっておいたほうがよい。
  • そうではないものから書き換えてみたが、書く事自体が大変ではなく、新しい概念や知識を取り込むコストが高い。
  • EUのDDD関連のカンファレンスではCQRS+ESの話が多くなるので今後はメインストリームになるのではないかと考えている。

Q. CDC(Change Data Capture)対応のデータベースじゃないと実践できないですか？

イベントの取り扱いに関して言及があり、イベントをRDBに格納すること自体は問題ないがそのイベントをどうやって取り出すかが問題になる。その際にCDCが存在しないものを使うとポーリングするなどデータベースの負荷がかかるやり方になってしまうのでそのあたりが難しい、とのことでした。また、普通のRDBにしてしまうとスケールアウトの難しさが出るなどの問題があるので、ドキュメント指向のものを使うと良いという話もありました。

感想

  • いろいろな角度でなるほどなぁと思わされれる話が多かった。
  • RESTとイベント記録に関しては確かに噛み合わせが悪い、というよりかはCreate専門になってしまうよなという気持ちに
  • ドキュメント指向のデータベースを使う利点に関してもいままであまりユースケースがわかってなかったのですがこの話を聞いて合点が行きました。

関連リンク

CQRS+ES の力を使って効果を感じる

感想

  • AWSでCQRS+ESにチャレンジしてみる話
  • 前段でかとじゅんさんが指摘していたAWSの例を使っていた話だったので見直しの話が入ったのがタイムリーな感じでした

関連リンク

イベントソーシングとドメインモデリング

感想

  • イベントを中心としたモデリングに関してのLT
  • イベントソーシングはやらずとも、イベントを記録することは念頭に置いて実装することをするのがよいんだろうな、という学びになりました。

関連リンク

使いたいから使うんじゃなく「必然として」使うCQRS+ES

感想

  • 古くからあるシステムにCQRS+ESをあてていく話。
  • 個人的にはCQRS+ESの話というよりも、組織を上げてモダナイズすることの難しさを感じた話
    • マイクロサービス化がモダナイズ化です！という話にしないと前進しなかったんだろうな…という苦労がにじみ出ていた

関連リンク

ドメインイベント増えすぎ問題

感想

  • イベントの種類がたくさん増えてしまって困った話
  • すごく実践に即した話という感じがしており、これからやる人向けへの転ばぬ先の杖的なLTでした。
  • 実際問題このあたりは勘所がないと変な方向にやりそうだな…という感じも強く受けました。

関連リンク

Debeziumを活用したRDBMSイベントソーシングの仕組み

感想

  • Debeziumを利用したCQRSパターンの作成の話。
  • 先ほどのパネルディスカッションにあったCDCがないDBへのアプローチの一例として良さそうでした。
  • ただKafkaも必要になるので考えることは増えそう…

関連リンク

全体を通しての感想

  • まったく普段遣いしない知識の話が満載でしたが、なんとなくの理解でもついていけるように配慮されていてよかったです。
    • ただもう少しアクターモデルやベースの理解があったほうが楽しめた感は否めなかったです。
  • 自分自身がRailsメインが続いていたのでCQRS+ESの考え方自体はぼんやり理解しているレベルでしたが、この機会にもうちょっと足を突っ込むといいのかなと思っています。
  • 普段の実装でもイベントを意識する事自体はマイナスに働くことがないので活かしていきたいと思います。

関連リンク

集合知と合議に関して考えるときに見返したいスライド『合議で決めたいわけではないけれど、 集合知で助けてほしい。』

スライド・記事回顧録

資料スライド

みどころ

人に意見を求めると、どうしても合議のようになってしまいがちな議論に関してを集合知で助けてほしいときにはどういうことを気をつけるべきか、どのようなことを考えるべきかということのヒントがあるスライド。関連リンクの内容含めて動かし方の参考になる部分が多い。

関連リンク

2024年時点のGoogleドキュメントはMarkdown記法での入力ができる。

Tips

小ネタ

設定の仕方

メニューの「設定」を開くとチェックボックスがある。

設定内容

これをオンにすると以下のようにmarkdownで入力するとそれに相当するものに変換してくれる。

勝手に置き換わってくれる

参考リンク

Google ドキュメント、スライド、図形描画でマークダウンを使用する - Google ドキュメント エディタ ヘルプ

ロールベースアクセスコントロールに関してざっくりまとめる

ざっくりまとめ

ぼんやりとした理解なので整理がてらまとめる

ロールベースアクセスコントロール(Role-based access control)とは

各ユーザに1つ以上のロールを割当て、そのロールに準じてアクセスできる権限を設定する考え方。

登場の背景

NISTによって1992年に提唱されてから広まっていった概念。当時ユーザひとりひとりに権限を設定するやり方に対しセキュリティ上の懸念が増えていたところへ、ユーザではなくロールに権限を与えることでシンプルにするようにした考え方。

当時の資料を見ると、管理者が直接ユーザに権利を割り当てたり、ファイルの所有者が権限の設定を行ったりしていたのが主流だったため、切り口が違う概念となっている。

類似の概念としての属性ベースアクセスコントロール(Attribute-based access control)

類似の概念として属性ベースアクセスコントロールがある、こちらはユーザの属性によって権限を確定させてしまう考え方。ロールに似た考え方ではあるが、権限のためのロールではなく違う意図で振られている属性（たとえば役職）などを使うのが違いとなっている。

参考リンク

コロケーションという言葉の意味に関してざっくりまとめる

ざっくりまとめ

いくつか意味があるので、整理する。

本来の意味

英単語の「Collocation」は配置のやり方などを表す言葉。場所の配置などで使われる。

ITインフラにおけるコロケーション

ITインフラにおいては、データセンターの同じ場所にに複数企業のサーバーやネットワーク機器を設置することをいい、そのような場所やサービス自体をコロケーションと呼ぶこともあります。

Webフロントエンド開発のおけるコロケーション

Webフロントエンドにおいては「関連するリソースを近くに置く」という意図で使われる言葉で、自由度の高いディレクトリ配置に対してどのように置くべきか迷った際に、関連するものを近くに置くべきという話で利用される言葉。

英単語の組み合わせ

英文法の文脈でも使われ、その場合は「よく使われる言葉の組み合わせ」を表すもので、強い雨のことを「heavy rain」などと表現するようなよく使われる単語セットのことを表現した言葉。

参考リンク

パスワードの定期的な変更がなぜ無意味かを整理する

ざっくりまとめ

パスワードの定期的変更に意味が無い話はよく見かけるが、背景は把握できていないので整理する。

定期的な変更はそもそもなぜ推奨されていたのか

もともと定期的な変更というところは、定期的に変わることによりリスクを軽減されるのではないというところからの着想ではあった様子。

ただ"様子"と書いたのは、この点においては裏付けとなる資料は（少なからず私は）見つけられなかったので、明確に何か根拠となる情報はなさそう

パスワードの定期変更に関する現状について

2017年に米国国立標準技術研究所(NIST)が警告

NISTが2017年に出した電子認証に関するガイドラインには以下のような文がある。

Verifierは，記憶シークレットを任意で(例えば，定期的に)変更するよう要求すべきではない(SHOULD NOT)．しかしながらAuthenticatorが危殆化した証拠がある場合は，変更を強制するものとする(SHALL)． - NIST Special Publication 800-63B

この文章での「記憶シークレット」がいわゆるパスワードにあたり、定期的な変更を推奨しない一文が盛り込まれている。

国民のためのサイバーセキュリティサイトで名言されている

総務省のサイバーセキュリティのためのサイトで以下のような記述がある。

なお、利用するサービスによっては、パスワードを定期的に変更することを求められることもありますが、実際にパスワードを破られアカウントが乗っ取られる等のサービス側から流出した事実がない場合は、パスワードを変更する必要はありません。むしろ定期的な変更をすることで、パスワードの作り方がパターン化し簡単なものになることや、使い回しをするようになることの方が問題となります。定期的に変更するよりも、機器やサービスの間で使い回しのない、固有のパスワードを設定することが求められます。 - 安全なパスワードの設定・管理 | 国民のためのサイバーセキュリティサイト

これらを整理するとなぜ使いまわしてはならないのか

総務省のサイトの記述が全てではあるが以下のようなことが定期変更を推奨しない背景かと考えられる。

  • パスワードの定期的変更は流出時の対策としては意義があるが、パスワードを推測しにくくするかどうかには関連のある話ではない
  • 加えて、定期的な変更を行うことで、パスワードの作り方がパターン化し簡単なものになることや、使い回しをよりしやすい状況を作りやすくなる

参考リンク

ピクルスの瓶理論とは何かをざっくりまとめる

ざっくりまとめ

ピクルスのツボ理論ともいわれる、メモがてら

原文

Time Management: The Pickle Jar Theory

この話から発展して語られる内容

タスクを以下のように例える。

  • 岩
    • すぐに取り掛かる必要がある重要度も緊急度も高いタスク
  • 普通の石
    • 重要度は高いが緊急度が高くはないタスク
  • 砂
    • すごく簡単な些細なタスク

タスクをそれぞれ石に例えられたら、1日こなしていったタスクを実際に瓶に詰めてみる。そしてその状況をみて一日の使い方がどうだったかを可視化してみる。

このやり方でもし、砂の割合が多ければ、重要である岩をいれることができたのではないかということを振り返ることができる。

また、振り返りとして使うだけではなく、未来の予定の配分としても使える。その日行うべきタスクを実際に入れてみて、溢れないか、あるいは砂の量が多くて大事な石や岩のタスクを入れられない状況になってないか、などを確認することができる。

参考リンク