Java EE勉強会

MakingSenseofStreamProcessing / Conclusion Use Logs to Make Your Infrastructure Solid

Chapter 2 Conclusion: Use Logs to Make Your Infrastructure Solid †

要約 †

Figure 2-32. サービスの扱うデータを変更する唯一の方法がイベントにログを追記することだったらどうなるだろう？

ちょっとした思考実験

x POST x PUT x DELETE
○GET
ログを追記するだけで全部実現できるんじゃないの？
  • 私たちの使っているAPIのほぼ全てに書き込みと読み込みのエンドポイントがある
    • REST API なら
      • GET は読み込み（副作用のない操作）
      • POST/PUT/DELETE は書き込み
  • 書き込みをするシステムが1つだけなら十分
  • 複数あると、、、同時書き込み問題や本章で説明した問題が出てきてどうにもならなくなる
  • ちょっと思考実験
  • 書き込みのためのエンドポイントを無くしてみよう（GETだけ残して、POST/PUT/DELETE を無くしてみよう）
  • 追記だけできるようにして、ログを消費するシステムを追加してみよう
    • ログはシステムの外部に置くようにして、他のコンシューマーもログを消費できるように
  • Elasticsearch の亜種を考えてみる
    • REST API によるドキュメントの書き込みはできない
    • Kafka にドキュメントを追記することはできる
    • Elasticsearch は Kafka コンシューマーを持っている（Kafka から読み込んだドキュメントをインデックスに追加できる）
  • 内部的なあれこれを簡潔にしてくれそう
    • 並行処理の制御
    • レプリケーション
  • 同じログを扱うシステムと共存することができる
  • ログが正当なデータソースへと置き換わる世界観
    • 発生したイベントを全て記録している
    • コンシューマーはいろいろな方法でそれを可視化できる（Figure 2-33）
  • コンピューティングのさまざまなレイヤに同じような仕組みがある
    • データベースストレージエンジンやファイルシステムと SSD の関係
    • この考え方を推し進めたのが Chapter 5

Figure 2-33 ログをあらゆる場所で発生したイベントの集積場所とみなす考え方 Pat Helland(Salesforce.com)がCIDR 2015に投稿したセッションペーパー

ログが正しい
データベースはログのキャッシュとなる
Pat Helland CIDR 2015
  • Chapter 1(MakingSenseofStreamProcessing/Events and Stream Processing) で紹介したイベントソーシングとよく似ている（でもちょっと違う）
  • 本章で紹介した仕組みでイベントソーシングを実現するには、ログに記録されたイベントの並び順を固定すること
    • 並びが変わると結果も変わってしまう
  • 本章で紹介したこと
    • データ連携の問題を解決するにはログを使うとよい
    • さまざまな場所で発生したデータを矛盾なく記録できる
  • 次章で紹介すること
    • データベースシステムをログ中心アーキテクチャに統合するため、Kafka を組み込むときに発生する課題

担当者のつぶやき †

みんなの突っ込み †


Menu