4/27のShinjuku.LTに行ってきました
Shinjuku.LTに行ってきました。
イベント駆動マイクロサービスアーキテクチャ
- 資料は後ほど公開される
- マイクロサービスの定義
- 2つ以上のサービスが連携
- 100 ~ 1000が連携しているのだけが対象じゃない
- かつ今後、サービスが増えていくのを前提にしている
- イベント駆動アーキテクチャで変わること
- 同期的な処理と対比されやすい
- お互いがサービスを知ってないと動けない
- どちらかが止まるとお互いに止まっちゃう
- オーケストレーションによる連携
- イベント駆動の場合
- publisher -> event -> subscriber
- コログラフィー??
- 複雑性は上がるけど、可用性が上がる
- 修正する場合
- サイト側は特になし
- イベントの修正と
- イベントを受け取る側の修正
- 新サイトと作る場合
- サイトの作成
- サービス障害時
- 同期的じゃないので、表側は影響を受けない
- 表側はとりあえずイベントを送るだけ
- イベント受け取るのはkinesisとかsqsとかkafkaを想定
- サービス側の復旧待ち
- readとかはできないかもしれないけどwrite系の処理はキューに入れとくから復旧後に反映することができる的な
- 表側はとりあえずイベントを送るだけ
- 同期的じゃないので、表側は影響を受けない
- イベント設計
- ドメインイベント
- 出来事を表す
した時、の場合- イベントべをベースにしてコードを書くと比較的自然な感じになる
- DDDとかでもよく言われてるらしい
- 慣習的にイベントは過去形にするらしい
- 常駐型 / イベント駆動型
- publisher -> event -> subscriber
- 同期的な処理と対比されやすい
ここまでのまとめ
- 各サービスから発生するイベントを中心に設計できる
- 同期から非同期にすることでシステムの可用性が上がる
- サーバレスにする選択肢も取れるので、コスト削減につながるかも
イベント駆動開発の戦略と戦術について
- DDDが境界づけられたコンテキストの1種がhogehoge ???
- 要件
- 任意の条件でポイントを付与
- 条件は増える
- ポイント利用機能を提供
- 今後方針が変わる可能性もある、という状況
- 任意の条件でポイントを付与
- 拡張性、疎結合、可用性、あたりを考える
- 拡張性、疎結合 : サービス側(表側)はポイント付与の条件を知らない、予め定義したどめいんいべんとをパブリッシュするのを約束
- すでにイベントが提供されている状態であれば、ポイントサービスの拡張するだけで良い
- 可用性
- 復旧したタイミングでイベント西尾読み込みが可能結果整合性、絶対に落ちないシステムじゃなくてもよくなった
- graceful degrationを意識
- 拡張性、疎結合 : サービス側(表側)はポイント付与の条件を知らない、予め定義したどめいんいべんとをパブリッシュするのを約束
- 戦術
- イベント定義とライブラリ
- single source of truth
- protocol buffers
- 1gitリポジトリに全サービスのイベントを定義
- パブリッシャーが配信するイベントを定義している
- 型とか、中身とか
- プッシュをトリガにCI/CDまわして各言語毎のライブラリの更新
- consumer driven contract
- クライアント側がほしいイベントとか処理を指定できるし、それを実装できる
- 今回はprotocol buffersで定義している
- 今回はjsonよりメリット多かった
- パブリッシャーが配信するイベントを定義している
- spring cloud stream
- CQRSとイベントソーシング
- 事業拡大とともにポイント付与ロジックは増えてく
- 読み込みはページ単位で呼び出される
- 書き込みと読み込みを分離させる
- ２，３ねんから辛くなるし5年立つとレガシーになっちゃう
- 式年遷宮前提にして、シンプルで捨てやすい作りを前提にした
- axon, akkaは学習コストが高いので、立ち上げの速度とかでつらそうだったので、最低限の機能だけを自前で実装した
- read, writeの分離
- イベントハンドラのパターンマッチ
- DBもread write分ける、まではしてない
- この先色々変わるのではじめからベストみたいなのキリがない
- この先分けたくなることは考えられるので一応スキーマは分けている
- イベント定義とライブラリ
- 後半のまとめ
「いい設計を考えても運用で苦労する人たちがいっぱいいるような作りにすると意味がないのでそこは忘れずに考えていかないとね」
ケトジェニックダイエットしてみたよ
- 旦那「ケトジェニックしたい」
- 20日間試してみた
- ケトジェニックとは？
- ガチガチの糖質制限
- 炭水化物を取らない
- そのかわりに脂質をたくさん取る
- 食べて良いもの
- 肉類
- 魚
- きのこ
- ブロッコリー、葉物野菜
- オリーブオイル、ココナッツオイル
- ウィスキー、焼酎はセーフ
- 食べちゃ駄目なもの
- 炭水化物
- 根菜
- 注意事項
- 唐揚げとか焼き肉行けるのでは？
- ころもとか、タレが駄目！
- 調味料に含まれる糖質を注意
- 醤油も糖が入ってる
- できれば塩
- シーザードレッシングは意外と糖が少ない
- ルール
- ガチめ
- 飲み会も極力糖質取らない
- ジムで適度な運動
- ガチめ
- 体重、体脂肪
- 減少
- 筋肉量
- 横ばい
- ケトジェニックやめた
- わかりやすく増えた
- やってみて
- 食生活が新鮮で楽しかった
- 食品の成分をみる癖がついた
- 糖をとらないので、食後の眠気がなかった
- 辛かったこと
- 外食できない
- 炭水化物の分を肉で補填するので胃もたれがやばい
- アボカドは飽きる
「ケトジェニック、一度やってみるのはあり」
(続)カンファレンスアプリを改善した
- どこか昔に発表したやつ
- 今後どうなりたいの？って考えた時に見直したら良いこと言ってるな、ってなったので発表
- カンファレンスでいい感じにタイムテーブルを作ってみた
- 同僚に見せてみた
- 刺さらなかった?
- 別の見方ができるタイムテーブルも作ってみた
- 同僚に見せてみた
- 本題
- 趣味のアプリを作る機会ってなかなかない
- どうせだったら新しい事、技術を取り込んでいきたい
- 今回はかなりオーバースペック
- でも、ここでの経験は業務で生かされた
- アプリだけで見ると良い技術選定ではなかったかもしれないけど、いい得るものがある
- 遊びだから好きにできる
「自分がやりたいことをやって作っては消してを繰り返すして新しい価値を生み出すのはモチベーションになる」
chaos engeneeringの現状把握
- カオスエンジニアリングの歴史
- カオスエンジニアリングの原則
- カオスエンジニアリング
- failer injection test
- simir army
- 色々な障害テストができる
- simir army
- カオスモン機器ーoss化
- 予期しない障害の最善の対応策は頻繁に障害を起こすこと
- カオスエンジニア:専門職
- カオスアーキテクチャ
- グレムリン
- failer as a service
- chaos conf
- どういう問題が起きる？
- それに答えることができる
- 想定していることはわかるが、想定していないことはわからない
- anti flagile
- 複雑性に対してどう対処する？
- こうどに複雑になったものは予測できない: カオス理論
- 半脆弱性
- すとれすが加わった時により強くなる
- design for failer
「カオスエンジニアリングは最初から入れてもいいくらいのカジュアルなものになってる」
Road to Amazon Correto
「コードパイプラインのロゴが存在してない」
終わりに
なんかカオスエンジニアリングがすごく楽しそうに見えた。 やっぱまとめるだけだとこなす感強いので話さないと駄目だなー。
