4
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

ドメイン駆動設計#1Advent Calendar 2019

Day 23

ドメインイベントをsplunk>で可視化する

Last updated at Posted at 2019-12-22

こちらは ドメイン駆動設計#1 Advent Calendar 2019 の23日目の記事です。

こんばんは、現在は業務で splunk> の運用に携わっている crossroad0201 です。
この記事では splunk> を ドメイン駆動設計(以下、DDD) の文脈でなにか活用できないか?と考えていたアイデアをご紹介したいと思います。

アイデアをご紹介、と言ってもまったくもって大した内容ではないのですが...(笑)

splunk> とは

みなさん、 splunk> をご存知でしょうか。

一言で言ってしまうと Elasticsearch のようなものですが、大量のデータを蓄積し、独自のクエリ言語を使ってフィルタや各種集計、グラフ化などのデータ分析ができるプロダクトです。

ピンクがコーポレートカラーらしく、Webサイトや公開されているスライドなど、あっちこっちがピンクです(笑)

スクリーンショット 2019-12-22 22.51.13.png

SPL(Search Processing Language)と呼ばれるクエリ言語が使えたり、さまざまなデータソースからデータを取り込む仕組みを持っていたり、データ構造を自動解析してインデックス化したり、大規模なクラスタを構築・運用する仕組みが用意されていたり...と言った特徴があります。
さまざまなOS、ミドルウェア、アプリケーションのログを一元化して可視化したりするのに使われることが多いようです。

僕自身、業務で扱うまでは実はまったく知らなかったのですが、国内外の大手企業などにも多く導入されており、米国での大規模イベント .conf や、国内の GOJAS(Go Japan Splunk User Group) などのコミュニティ活動も活発なようです。

splunk> がどのようなものかは、 こちらのデモ を見るとイメージできると思います。

DDDで splunk> を

さて、そんな splunk> ですが、DDD Loveな自分としてはなんとかDDDと関連付けて使えないものか...と言うことで、 ドメインイベントを splunk> につっこんで見える化する と面白いのではないか?と思っています。

「できたらえーなー」と思っているだけで実践はしていませんのでそこはご了承を...(笑)

ドメインイベント

「ドメインイベント」 については、 ヴァーノンの 実践ドメイン駆動設計 で解説されているのでご存知の方が多いかと思いますが、ドメイン内で発生する事象をモデル化したものです。

例えば...

  • 新規会員が入会した
  • 注文を受け付けた
  • 商品を出荷した

のような、ドメインの文脈の中で過去形で表現される知識がドメインイベントの候補になります。

マイクロサービスとドメインイベント

マイクロサービスアーキテクチャを採用する場合にも、ドメインイベントは非常に重要になります。

書籍マイクロサービスアーキテクチャ などでも述べられているように、マイクロサービス間の連携には 1.リクエスト-レスポンス型2.イベント型 があり、マイクロサービス間を疎結合にして独立性を高めるには、 2.イベント型 による連携が望ましい選択肢になります。( こちらの記事 もご参考に)

DDDを採用する場合は、マイクロサービス間でやり取りするイベントとして、ドメインイベントが使えます。

ここで悩ましいのは、マイクロサービスをまたいでやり取りされるイベントを一元的に見るのが難しい点です。

ドメインイベントの見える化

ここで splunk> の登場です。(まぁ Elasticsearch でも良いんですが...)

各マイクロサービスから発生するイベントを splunk> に蓄積していけば、クエリ言語SPLを使って 「注文番号XXXXXの注文が、いつ誰によってどのように処理されたのか」 と言ったようなことを簡単に見ることができます。

また、あるイベントの発生する曜日や時間帯を調べることでユーザーの行動傾向を分析したり、先行-後続関係にあるイベント間のタイムラグを見ることで業務のボトルネックを特定することもできるかもしれません。

splunk> のクエリ言語は(もちろん学習は必要ですが)アナリストのようなエンジニアではない人でも扱えるので、ビジネスをカイゼンさせていくためのフィードバックを誰でも得ることができるのではないかと思います。

アーキテクチャ

実現のアーキテクチャですがいたってカンタン(なはず)です。

例えばAWSを利用していて、マイクロサービス間のイベントを送受信するために Kinesis Streams を使っているなら、そのストリームをサブスクライブして splunk> にデータ投入する Lambda Function を作るだけです。
Lambada function から splunk> へのデータ投入には HEC(HTTP Event Collector) と呼ばれるHTTPでデータ投入する仕組みがあるので、これを利用すれば良さそうです。

また、 splunk> には Kafkaからデータを取り込むアドオンがある ので、イベント伝播に Kafka を使っている場合はそれが使えるかもしれません。

おわりに

と言うわけで、かんたんな記事で恐縮ですが、DDD界隈でもこのあたりはあまり話題に上がらないと思うので、何かのヒントになれば幸いです。

4
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?