マイクロサービスと Red Hat Integration

Ver1.0
マイクロサービスと
Red Hat Integration
Red Hat Japan
Application Services
Kenta Kosugi 10th Nov 2021

Ver1.0
本を扱う EC サイト

Ver1.0
これまでの開発方法

Ver1.0
データモデル
基本機能
商品モデル
<< Entity >>
- ISBN
- 発売日
- ページ
- 言語
- 寸法
- 出版社
- 著者
- 価格
- 在庫数
在庫管理機能追加！

Ver1.0
データモデル
基本機能
商品モデル
<< Entity >>
- ISBN
- 発売日
- ページ
- 言語
- 寸法
- 出版社
- 著者
- 価格
- 在庫数
- 在庫位置
在庫管理機能
新しい属性が追加される
キャンペーン機能追加
コードの改修が必要に
▸ 在庫管理機能が ”商品モデル ”に対して
意図していない値 (null や空白、意味のな
い値)を設定することに対する防御
▸ 興味のないプロパティ (在庫位置)に
対するフィルター

Ver1.0
データモデル
基本機能
在庫管理機能
キャンペーン機能
商品モデル
<< Entity >>
- ISBN
- 発売日
- ページ
- 言語
- 寸法
- 出版社
- 著者
- 価格
- 在庫数
- 在庫位置
- 割引率
- 割引開始日時
- 割引終了日時
クチコミ機能追加
▸ キャンペーン機能が ”商品モデル ”に
対して意図していない値 (null や空白、意
味のない値 )を設定することに
対する防御
▸ 興味のないプロパティ (割引情報)に

Ver1.0
データモデル
基本機能
在庫管理機能
商品モデル
<< Entity >>
- ISBN
- 発売日
- ページ
- 言語
- 寸法
- 出版社
- 著者
- 価格
- 在庫数
- 在庫位置
- 割引率
- クチコミ
クチコミ機能
▸ クチコミ機能が ”商品モデル ”に対して
意図していない値 (null や空白、意味のな
い値)を設定することに対する防御
▸ 興味のないプロパティ (クチコミ)に
ポイント機能追加

Ver1.0
データモデル
基本機能
在庫管理機能
クチコミ機能
商品モデル
<< Entity >>
- ISBN
- 発売日
- ページ
- 言語
- 寸法
- 出版社
- 著者
- 価格
- 在庫数
- 在庫位置
- 割引率
- クチコミ
えっ!? また?
えっ!? また?
えっ!? また?

Ver1.0
【参考】3層アーキテクチャの場合
war
war
war
AP サーバー
RDBMS 等
Web ブラウザ
プレゼンテーション層
ビジネスロジック層
データアクセス層
依存関係
①ここに手が入ります
③ & ④ ここにも手が入ります
(依存しているため)
②ここに手が入ります

Ver1.0
【参考】V字モデル
要求分析
要件定義
基本設計
詳細設計
コーディングコードレビュー
単体テスト
結合テスト
システムテスト
受入テスト
Prime
2次請け
EU
Pri
me
3次請
工程のやり直しが必要
モデルの改修は保守時においては
ドキュメントの改修が必要

Ver1.0
【参考】クソコード動画 User クラス
モデルの混在
[1] : クソコード動画「Userクラス」
[2] : クソコード動画「User クラス」で考える技術的負債解消の観点

Ver1.0
データモデル
モデルの混在
基本機能
在庫管理機能
クチコミ機能
商品モデル
<< Entity >>
- ISBN
- 発売日
- ページ
- 言語
- 寸法
- 出版社
- 著者
- 価格
- 在庫数
- 在庫位置
- 割引率
- クチコミ
さまざまな状況に必要なデー
タが商品モデルとして混在し
てしまっている

Ver1.0
モデルの混在
[1] : DRY 原則 : 達人プログラマーシステム開発の職人から名匠への道より抜粋
DRY 原則[1] - Don’t Repeat Yourself -
モデルが重複して使われていることも DRY に反する
信頼性の高いソフトウェアを開発して、開発そのものを簡単に理解したりメンテナンスできるようにする唯一の方法は、
DRY 原則に従うことです。
すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。
何故これがDRY原則なのでしょうか？
DRY 原則を破るということは、同じ知識を２箇所以上に記述することです。この場合、片方を変更するのであれば、もう
片方も変更しなければならないのです。さもなければ異星人のコンピュータのようにプログラムは矛盾につまづくことに
なるのです。これはあなたが覚えていられるかどうかという問題なのではありません。これはあなたが忘れてしまった
時の問題なのです。
この DRY 原則は本書中のコーディングに関係のない部分でも何度も登場します。我々はこれが達人プログラマーの
道具箱の中にある道具のうちで最も重要なものの一つであると考えています。

Ver1.0
モデルの混在を防ぐ
-技術的負債を減らし、
アジリティをあげる-

Ver1.0
▸ 人気本の品揃え
▸ 在庫回転率 %UP
▸ 効率的な在庫配置
▸ 作業ミス軽減による
コスト減
事業戦略とモデル
事業戦略

Ver1.0
コスト減
事業戦略
ビジネスの
エキスパート
バイヤー
マーケ
在庫

Ver1.0
コスト減
事業戦略
ビジネスの
エキスパート
バイヤー
マーケ
在庫
事業を達成できる
ような関心事項
▸ この本は売れるのか？
▸ 流行りの本？
▸ 人気の作者？
▸ この時期にこれくらい割り
引いてこのくらい売り上げ
たい
▸ この本在庫積んでずっと
売れてないから
割引適用したい
▸ この本の在庫はどこにあ
る？
▸ 在庫の引っ越しにも柔軟
に対応したい

Ver1.0
コスト減
事業戦略
ビジネスの
エキスパート
バイヤー
マーケ
在庫
たい
る？
に対応したい
”商品”に対する
イメージ(モデル)
Book
- ISBN
- タイトル
- 著者
- 出版社
Coupon
- ISBN
- 割引率
- 割引期間
Inventory
- ISBN
- 在庫数
- 在庫位置
▸ バイヤーがイメージするモデルは本
▸ マーケがイメージするモデルはクーポン
▸ 在庫がイメージするモデルは段ボール

Ver1.0
コスト減
事業戦略
ビジネスの
エキスパート
バイヤー
マーケ
在庫
たい
る？
に対応したい
Book
- ISBN
- タイトル
- 著者
- 出版社
Coupon
- ISBN
- 割引率
- 割引期間
Inventory
- ISBN
- 在庫数
- 在庫位置
モデルに関する
振る舞い
- 取り扱い商品を
検索
追加
- 割引率を設定
- 割引期間を設定
- 在庫数の検索
- 在庫を増やす
- 在庫を減らす
- 在庫を引っ越す

Ver1.0
コスト減
事業戦略
ビジネスの
エキスパート
バイヤー
マーケ
在庫
たい
る？
に対応したい
Book
- ISBN
- タイトル
- 著者
- 出版社
Coupon
- ISBN
- 割引率
- 割引期間
Inventory
- ISBN
- 在庫数
- 在庫位置
振る舞い
検索
追加
▸ ビジネスには境界がある
▸ モデルに関する振る舞いは境界外
から利用可能に

Ver1.0
ドメイン駆動設計
Domain Driven Design
- DDD -

Ver1.0
Domain Driven Design -DDD-
コスト減
事業戦略
ビジネスの
エキスパート
バイヤー
マーケ
在庫
たい
る？
に対応したい
Book
- ISBN
- タイトル
- 著者
- 出版社
Coupon
- ISBN
- 割引率
- 割引期間
Inventory
- ISBN
- 在庫数
- 在庫位置
振る舞い
検索
追加
▸ 同じ”商品”でも意味の変わる境界を
境界
づけられたコンテキスト
と呼ぶ
▸ Bounded Context
▸ マイクロサービスの候補
▸ どの境界がどのデータに対して責務を持つのかが明らかに
▸ 境界を跨いで同一データを持つことはない
▸ 異なる境界で同一データを持つということはうまく境界を分割でき
ていない可能性がある

Ver1.0
Domain Driven Design -DDD-
コスト減
事業戦略
ビジネスの
エキスパート
バイヤー
マーケ
在庫
たい
る？
に対応したい
Book
- ISBN
- タイトル
- 著者
- 出版社
Coupon
- ISBN
- 割引率
- 割引期間
Inventory
- ISBN
- 在庫数
- 在庫位置
振る舞い
検索
追加
ツール&
データソース
▸ エンジニアの興味のある領域
▸ ワークロードに応じたデータソースを選択
▸ 複数のデータソースへ接続する必要がある
場合はRed Hat Fuse を検討(後述)

Ver1.0
[1] ドメイン駆動設計とは何なのか? : https://codezine.jp/article/detail/11968
ドメイン駆動設計とは何なのか [1]
ソフトウェアの利用者を取り巻く世界について知る必要があります。
ソフトウェアの利用者にとって重要な知識が何である
のかは、その世界の有り様に左右される
のです。価値あるソフトウェアを構築するためには利用者の問題を見極め、解決
するための最善手を常に考えていく必要があります
。ドメイン駆動設計はそういった洞察を繰り返しながら設計を行い、ソ
フトウェアの利用者を取り巻く世界と実装を結びつけることを目的としています。
　あなたが学んだ知識はそれが何であろうと、貴重なあなたの人生の時間をいくばくか費やした、とても大切なものです。
知識がコードに埋め込まれ、ソフトウェアとなって直接的に誰かを支援する。そこに喜びを覚えない開発者はいないでしょ
う。ドメイン駆動設計はまさに
知識をコードへ埋め込むことを実現する
のです（図1.1）
〜略〜
　モデルとは現実の事象あるいは概念を抽象化した概念です。抽象は抽出して象るという言葉のとおり、
現実をすべて忠
実に再現しません。必要に応じて取捨選択を行います。何を取捨選択するかはドメインによります。
　たとえばペンはどのような性質を抽出すべきでしょうか。
小説家にとってペンは道具で、文字が書けることこそが大事な
性質です。一方、文房具店にとってペンは商品です。文字が書けることよりも、その値段などが重要視
されます。このこと
が指し示すのは、対象が同じものであっても何に重きを置くかは異なるということです（図
1.3）。
図 1.1 知識をコードへ
図 1.3 道具としてのペンと商品としてのペン

Ver1.0
某メーカーでデータの正規化の話とか、コンサルでやったりしてました。
そりゃ、すっきりはするかもしれませんが、この会社に来て、
DDD の話を聞いて
以来、標準の形成と定期的なメンテナンスは必要、は同意できるけど、正規化で、
部分的な標準をやっても、それは根本解決にならない。
DDD はデータの正規化とか、そういうレベルじゃない。
【参考】Red Hat で DDD を知った人の話

Ver1.0
UI
ドメイン
モデル
DB アダプタ
REST API
[1] : CodeZin 実践DDD本第4章「アーキテクチャ」～レイヤからヘキサゴナルへ～
DDD - ヘキサゴナルアーキテクチャ -
サービスは REST API だけではなく様々な Adapter を持つ必要がある
アダプター
(外部からデータが入ってくる REST API の口や、データ
ベースへ書き込む RDBMS へ接続するアダプター )
アプリケーションサービス
(ドメインモデルを活用してビジネスのユースケースを記述 )
ドメインモデル
(ビジネスロジックを閉じ込める )
依存関係
RDBMS 等
FatJar / AP サーバー
REST Client
Event Publisher

Ver1.0
REST API
DB Adapter
Inventory サービス
DDD でサービス分割
REST API
Catalog サービス
DB Adapter
バイヤー
EC サイト
UI サービス
バイヤー用UI
REST API
DB Adapter
Marketing サービス
ユーザー
Inventory
- ISBN
- 在庫数
- 在庫位置
Coupon
- ISBN
- 割引率
- 割引期間
Book
- ISBN
- タイトル
- 著者
- 出版社
検索
追加
- 割引情報を検索
- 割引情報を設定
▸ ユースケースはインターフェースの候補に ▸ データは境界で責務ごとに分割

Ver1.0
REST API
DB Adapter
新規機能追加時
REST API
DB Adapter
バイヤー
EC サイト
UI サービス
バイヤー用UI
REST API
DB Adapter
ユーザー
Inventory
- ISBN
- 在庫数
- 在庫位置
Coupon
- ISBN
- 割引率
- 割引期間
Book
- ISBN
- タイトル
- 著者
- 出版社
検索
追加
ポイント機能追加

Ver1.0
REST API
DB Adapter
新規機能追加時
REST API
DB Adapter
バイヤー
EC サイト
UI サービス
バイヤー用UI
REST API
DB Adapter
ユーザー
Inventory
- ISBN
- 在庫数
- 在庫位置
Coupon
- ISBN
- 割引率
- 割引期間
- ポイント
Book
- ISBN
- タイトル
- 著者
- 出版社
検索
追加
▸ 「ポイント」に責務を持つMarketing のみにデータ追加
▸ UI サービスを除き、他のサービスには何ら影響はない

Ver1.0
サービス同士の
Integration

Ver1.0
リクエスト&
レスポンス型
(ステートのやりとり)

Ver1.0
リクエスト・レスポンス型
API
Client
リクエストとレスポンスがセットで
返却されるものはほとんどの場
合ステート
① リクエストを送る
② レスポンスを待つ
たいていの場合レスポンスを受け取るまでブロックされる

Ver1.0
REST API
DB Adapter
リクエスト & レスポンス型
リクエスト & レスポンス型が向いているケース
REST API
DB Adapter
EC サイト
UI サービス
REST API
DB Adapter
ユーザー
Inventory
- ISBN
- 在庫数
- 在庫位置
Coupon
- ISBN
- 割引率
- 割引期間
- ポイント
Book
- ISBN
- タイトル
- 著者
- 出版社
検索
追加
▸ ECサイトのUI サービスのようにCatalog / Inventory / Marketing に
完全に依存するケース
▸ 逆をいうとEC サイトのUI サービスはこれら
3つのサービスが立ち上
がっていないと機能しない
▸ 運命を共にするケースはリクエスト
& レスポンス型を使用

Ver1.0
リクエスト&レスポンス型が向いていないケース
REST API
DB Adapter
REST API
REST Client
DB Adapter
REST API
DB Adapter
バイヤーバイヤー用UI
①取り扱い商品の追加
②取り扱い商品の追加
③取り扱い商品の追加
取り扱い商品の追加

Ver1.0
REST API
DB Adapter
REST API
REST Client
DB Adapter
REST API
DB Adapter
▸ Inventory サービスへの書き込みで失敗すると・・・
▸ Catalog サービスに反映されたデータは？
▸ Marketing サービスに反映されたデータは？

Ver1.0
REST API
DB Adapter
REST API
REST Client
DB Adapter
バイヤー
REST API
DB Adapter
REST API
Notification サービス
Mail Adapter
マーケティング
在庫
Mail Server
▸ Notification サービスを追加
▸ 新商品が追加されたことを
マーケや在庫にメール通知
バイヤー用UI
④取り扱い商品の追加
▸ Catalog サービスの改修が必要
▸ 複雑度が増加
▸ 複数のリソースを一度にUPDATE

Ver1.0
リクエスト&レスポンス型
Camel Saga Pattern : https://www.nicolaferraro.me/2018/04/25/saga-pattern-in-apache-camel/
サーガ・オーケストレーションパターン
補償トランザクションを流して取り消し
API
Flight
Servcie
Payment
Servcie
Train
Servcie
① フライトの予約/ 購入
② フライトの支払い
③ 列車チケットの購入
④ 列車チケットの支払いが失敗
→ フライトの支払いは補償トランザクションを発行して
取り消す必要がある
⑤ 購入の取り消し
⑥ 購入の取り消し

Ver1.0
非同期型＋イベント
[1] Red Hat Data Grid :https://www.redhat.com/ja/technologies/jboss-middleware/data-grid
【参考】セッション状態のデータ格納
セッション情報はデータグリッド [1]に冗長化して格納
カートサービス Red Hat Data Grid
▸ サービス
- 　ステートフルからステートレスになるため
サービス側のスケールが容易
- 　サービスが停止しても、セッション情報を維
持
▸ データグリッド
- 　分散アーキテクチャであるため、スケールが
容易
- 　メモリ上にデータを格納するため、高速の読
み書きが可能
- 　ノード間で複製を持つことで耐障害性を確保
セッション
情報
セッション
情報
セッション
情報

Ver1.0
非同期型
(イベントのやりとり)

Ver1.0
-その前に - イベントとは何か

Ver1.0
カートを考えます(最近の私の話)
モニター買おう。お、検索で一番最初に出てきたこれいいじゃん。
商品A をカートに入れた！
あ、そういえば資料作成しなくちゃ
(購入に至らず・・・
)
VESA でひっかけてっと・・・
商品B をカートに入れた！
そういえば、モニター買うんだった。
あれ・・・商品A よく見たらVESA 規格対応してないやん。
VESA 対応してるやつにしよう。
デザイン的には商品A だけど、VESA ついてないから削除
商品A をカートから削除した！
時系列
2021/06/29

Ver1.0
カートで顧客体験の向上(AI/ML)を実現できるか？
顧客体験を向上させるには・・・？
DB ？
AP Server のセッション？
ETL ？

Ver1.0
https://12factor.net/ja/processes
DB + ETL で考えた場合
ステート中心の考え方
DB ETL DWH

Ver1.0
https://12factor.net/ja/processes
どうなるか
色々な事実がどこかに行ってしまった
DB ETL DWH
DB では参照時点の状態しか
確認することはできない
DB の状態をコピーすると当たり前だがそ
の状態のコピーしかされない
僕が VESA を重要視している事実や、VESA 企画に対応してい
ないモニターが検索結果の先頭に出ていた事実はどこかにいっ
たまま AI/ML の機械学習にかけられる

Ver1.0
赤文字のところ UX 向上において重要
モニター買おう。お、
検索で一番最初に出てきた
これいいじゃん。
商品A をカートに入れた！
あ、そういえば資料作成しなくちゃ
(購入に至らず・・・
)
VESA でひっかけてっと
・・・
商品B をカートに入れた！
そういえば、モニター買うんだった。
あれ・・・商品A よく見たらVESA 規格対応してない
やん。
VESA 対応してるやつにしよう。
デザイン的には商品A だけど、VESA ついてないから削除
商品A をカートから削除した！
時系列
2021/06/29

Ver1.0
”ステート”から”イベント”への発想の転換
発想を転換
LoB IT 部門
認識齟齬は発生しにくい
▸ イベントは非エンジニアでも理解しやすい
▹ ビジネスのエキスパート (エンドユーザー)にも理解可能であるため、
意識を合わせた会話が可能
▸ イベントは不変の事実である (イミュータブル)
▹ 複数スレッドで扱っても問題なし
▹ 対して”状態(ステート)”はロックが必要
▹ 同じ理由で分散環境で扱いやすい
▸ 監査にそのまま使用可能
▹ イベントを変更することは過去の事実の改ざんにあたる
▸ イベントはイベントストアの特性上複数のサービスに伝播できる
▹ データパイプラインを構築可能 (LinkedIn が Kafka を開発した理由
そのもの)
2021:6/30:PM 13:00
「モニター」で
検索した
TYPE : Search

Ver1.0
LinkedIn と Netflix の「アクティビティデータ」
ユーザーの操作に着目したドメインイベント
Activity data is one of the newer ingredients in internet systems.
アクティビティデータは、インターネットシステムの新しい要素の
一つです。
具体的には、どのコンテンツを見たのか、あるいは見なかったのか、どのくらい
の速度で見たのか、どのデバイスで見たのか、1日のいつ見たのかといったこと
です。夜見たいものと昼に見たいものでも変わってきますから。

Ver1.0
【参考】API の種類
リクエスト & レスポンス型非同期型
ステート
イベント
Command &
Reply
Command Topic
Reply Topic
API
Client
Client
API
Client
イベントの受け手
ステートの受け手
Event
Consumer
Event Topic
Client
ステートの受け手
イベントの受け手
メッセージングミドルウェア
メッセージングミドルウェア

Ver1.0
Red Hat AMQ Streams
ストリーミング・プラットフォーム
Apache Kafka - LinkedIn が課題解決のために開発 -
▸ 2010にLinkedInで開発され、2011年にオープンソース化された
▹ ストリーミングデータのための分散システム
▸ 非常に高いスループットと低レイテンシーで大量データを処理
▸ 容易に水平スケール
▸ コミットログとしてメッセージを保持
▸ データパーティショニング (シャーディング)
▸ クラスタリングにより高い耐障害性
▸ 大量のコンシューマも処理可能
● LinkedInの開発者がApache Kafka を新たに作ったわけ
○ リアルタイムログのような高いボリュームのイベントストリームをサポートするためのハイスループットを実現したい
○ オフラインシステムからの定期的なデータロードを可能とする大容量バックログを取り扱いたい
○ 伝統的なメッセージングのユースケースを取り扱うために低遅延である必要がある

Ver1.0
Red Hat AMQ Streams
ストリーミング・プラットフォームの特徴
従来のメッセージング・プラットフォームとの違い
▸ 「テープレコーダー」のようなもの
▸ コンシューマがメッセージを取得しても、ブローカーにメッセージ
が残る(一定期間で削除)
▸ コンシューマ側で読み出し位置を管理
▸ 分散トランザクションに対応しない
▸ 代表的な製品: Kafka, Kinesis, Pulsar, etc.
▸ 「メールボックス」のようなもの
▸ コンシューマがメッセージを取得したら、
ブローカーからメッセージが削除される
▸ 分散トランザクションに対応
▸ 代表的な製品: IBM MQ, Tibco RV, ActiveMQ, etc.
伝統的なメッセージブローカーストリーミング・プラットフォーム

Ver1.0
プロデューサー
AMQ Streams 詳細全体象
Red Hat AMQ Streams
トピック1
トピック2
コンシューマー
グループ1
パーティション 1
トピック2
グループ2
グループ2’
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
レプリカ
プロデューサー
Kafka Connect
(Source & Sink)
Mirror Maker
(他のデータセンターへ)
Kafka Bridge
(プロデューサー & コンシューマー)
Kafka クラスター& Zookeeper クラスター

Ver1.0
イベントの考え方

Ver1.0
全ての事実を保存可能
LinkedIn でサービスが Kafka に直接繋がっている理由
2021:6/30:PM 13:00
検索した
TYPE : Search
時系列
1
Online Data Center (Public Cloud でも可)
Cart サービス
①は不要
cart : {
lines: [
]
}
1

Ver1.0
2021:6/30:PM 13:00
検索した
TYPE : Search
2021:6/30:PM 13:01
「商品A」を
カートに入れた
TYPE : Cart
時系列
2 1
Cart サービス
②は必要
cart : {
lines: [
{ name: “商品 A”, price: 32,000, ・・・}
]
}
2

Ver1.0
2021:6/30:PM 13:00
検索した
TYPE : Search
2021:6/30:PM 13:01
「商品A」を
TYPE : Cart
2021:6/30:PM 16:00
「モニター VESA」で検
索した
TYPE : Search
時系列
2 1
3
Cart サービス
③は不要
cart : {
lines: [
{ name: “商品 A”, price: 32,000, ・・・}
]
}
3

Ver1.0
2021:6/30:PM 13:00
検索した
TYPE : Search
2021:6/30:PM 13:01
「商品A」を
TYPE : Cart
2021:6/30:PM 16:00
索した
TYPE : Search
2021:6/30:PM 16:01
「商品 B」を
TYPE : Cart
時系列
2 1
3
4
Cart サービス
④は必要
cart : {
lines: [
{ name: “商品 A”, price: 32,000, ・・・},
{ name: “商品 B”, price: 30,000, ・・・}
]
}
4

Ver1.0
2021:6/30:PM 13:00
検索した
TYPE : Search
2021:6/30:PM 13:01
「商品A」を
TYPE : Cart
2021:6/30:PM 16:00
索した
TYPE : Search
2021:6/30:PM 16:01
「商品 B」を
TYPE : Cart
2021:6/30:PM 16:02:
「商品 A」を
カートから
削除した
TYPE : Cart
時系列
2 1
3
4
5
cart : {
lines: [
{ name: “商品 B”, price: 30,000, ・・・}
]
}
5
Cart サービス
⑤は必要

Ver1.0
2021:6/30:PM 13:00
検索した
TYPE : Search
2021:6/30:PM 13:01
「商品A」を
TYPE : Cart
2021:6/30:PM 16:00
索した
TYPE : Search
2021:6/30:PM 16:01
「商品 B」を
TYPE : Cart
2021:6/30:PM 16:02:
「商品 A」を
カートから
削除した
TYPE : Cart
時系列
2 1
3
4
5
cart : {
lines: [
{ name: “商品 B”, price: 30,000, ・・・}
]
}
5
Offline Data Center
1
2
3
4
5
Object Storage
Mirror
Maker
TYPE: Cart だけを
フィルタ
Cart サービス
Cart サービス
AI / ML
⑤は必要

Ver1.0
2021:6/30:PM 13:00
検索した
TYPE : Search
2021:6/30:PM 13:01
「商品A」を
TYPE : Cart
2021:6/30:PM 16:00
索した
TYPE : Search
2021:6/30:PM 16:01
「商品 B」を
TYPE : Cart
2021:6/30:PM 16:02:
「商品 A」を
カートから
削除した
TYPE : Cart
時系列
2 1
3
4
5
cart : {
lines: [
{ name: “商品 B”, price: 30,000, ・・・}
]
}
5
Offline Data Center
1
2
3
4
5
Object Storage
フィルタ
▸ 状態をミラーリングするのではなく、イベントをミラー
リング(状態のミラーリングではDB の静止点が必
要)
▸ 状態を再構築するためタイムラグはあるものの全く
同じ状態を持ったアプリを再現
DB 使ってない！！
Mirror
Maker
フィルタ
Cart サービス
Cart サービス
AI / ML

Ver1.0
[1] イベントソーシングパターン : https://docs.microsoft.com/ja-jp/azure/architecture/patterns/event-sourcing
[2] マイクロサービスとメッセージングのなぜ : https://rheb.hatenablog.com/entry/microservices_messaging
DDD Pattern -イベント・ソーシング - [1]
ドメインイベントをすべて収集する
▸ イベントはイベントストアに書き込む
▹ RDBMS のように UPDATE ではなく追記
▸ 記録されたイベントから「ステート」を復元[2]
▸ イベント数は大量になる傾向

Ver1.0
REST API
DB Adapter
Event
Consumer
ドメインイベント
REST API
DB Adapter
Event
Publisher
Event
Consumer
バイヤー
REST API
DB Adapter
Event
Consumer
イベントストア
バイヤー用UI
②取り扱い商品が追加され
たというイベント
③取り扱い商品が追加され
▸ Catalog サービスのローカルトランザクション
(リソース更新)はイベ
ントストアに対する書き込みで閉じる
▸ イベントを取得してデータソースを更新するのは別の
ローカルトランザクション
▸ Catalog サービスはMarketing / Inventory サービスが生きてよ
うが死んでようが関係ない
(依存しない)
▸ イベントを複数のサービスに伝播し、複数のデータソースを個々のサービスが更新
▸ 興味のあるサービスがイベントを取得して自身のデータソースを反映させる

Ver1.0
Mail Adapter
ドメインイベント
REST API
DB Adapter
Event
Consumer
REST API
DB Adapter
REST API
DB Adapter
バイヤー
バイヤー用UI
Event
Publisher
Event
Consumer
Event
Consumer
②取り扱い商品が追加され
③取り扱い商品が
追加されたと
いうイベント
在庫
▸ 新しいサービスが追加
Event
Consumer
Mail Server
▸ Catalog サービスを改修する必要なし
▸ 新たに追加されたサービスがイベントストアから
自分に興味のあるイベントを拾ってくる

Ver1.0
チェンジイベント

Ver1.0
マイクロサービスのための分散データ〜イベントソーシング vs チェンジデータキャプチャ〜
ドメインイベント :
アプリケーションによって生成される、ビジネスドメインの一部である明示的
なイベント。これらのイベントは通常、 OrderPlaced や ItemShipped など、
過去形で表される。ドメインイベントはイベントソーシングの主要な関心事。
チェンジイベント :
データベーストランザクションログから生成されるイベント。発生した状態遷
移を示す。チェンジイベントはチェンジデータキャプチャにとっての関心事。
{
"before"
: {
"id": 1004,
"last_name"
: "Kretchmar"
,
"email": "annek@example.com"
},
"after": {
"id": 1004,
"last_name"
: "Kretchmar"
,
"email": "annek@noanswer.org"
},
"source"
: {
"name": "dbserver1"
,
"table": "customer"
,
"txId": "tx-3"
},
"op": "u",
"ts_ms": 1486500577691
}
2021:6/30:PM 16:02:
「商品 A」を
カートから
削除した
TYPE : Cart

Ver1.0
REST API
DB Adapter
REST API
REST API
DB Adapter
バイヤー
バイヤー用UI
DB Adapter
REST API
Mail Adapter
在庫
Event
Consumer
Mail Server
Log Miner
{
"before": {
"id": 1004,
"last_name": "Kretchmar",
"email": "annek@example.com"
},
"after": {
"id": 1004,
"last_name": "Kretchmar",
"email": "annek@noanswer.org"
},
"source": {
"name": "dbserver1",
"table": "customer",
"txId": "tx-3"
},
"op": "u",
"ts_ms": 1486500577691
}

Ver1.0
Red Hat
Change Data Capture
with Debezium

Ver1.0
Red Hat Change Data Capture with Debezium
Debezium
72
チェンジデータキャプチャプラットフォーム
▸ 複数のデータベース向けのチェンジデータキャプチャ
▹ トランザクションログベース
▹ スナップショット, フィルタリング etc.
▸ オープンソース, 非常に活発なコミュニティ
▸ Latest version: 1.6
▸ 複数の企業で本番環境にデプロイ済み
(例. WePay, JW Player, Convoy, Trivago, OYO, BlaBlaCar
etc.)
▸ Apache Kafka の Kafka Connect(Source) を利用

Ver1.0
Debezium の特徴
▸ すべての変更がキャプチャされる
▸ ポーリングの遅延・オーバーヘッドがない
▸ アプリケーション・モデルの記述がシンプルに
▸ DELETE もキャプチャ
▸ 古いレコードの状態を含むメタデータをキャプチャ

Ver1.0
REST API
DB Adapter
REST API
REST API
DB Adapter
バイヤー
バイヤー用UI
DB Adapter
Mail Adapter
在庫
Event
Consumer
Mail Server
Log Miner

Ver1.0
REST API
DB Adapter
Event
Consumer
これまで登場したサービスの全体像
EC サイトを構成する一部のサービスのみ (支払いや配送などが不足 )
REST API
DB Adapter
Event
Publisher
Event
Consumer
バイヤー
EC サイト
UI サービス
バイヤー用UI
API Gateway
Mobile
REST API
DB Adapter
Event
Consumer
Event
Consumer
Mail Adapter
ユーザー
Mail Server
マーケティングマーケ用UI
在庫在庫用UI
▸ API を外部公開して収益化したい
▸ API ごとに認証・認可をかけたい
▸ API を顧客や利用ユーザーごとに流量制御したい

Ver1.0
Red Hat 3scale API
Management

Ver1.0
3scale API Management
3scale API Management
管理者ポータル
▸ ダッシュボード
▸ デベロッパー/アプリケー
ション/キーの管理
▸ CMS
▸ 分析機能
▸ 課金
API利用者
(アプリケーション開発者
)
認証 &
トラフィック情報
アプリケーション
デベロッパーポータル
▸ 提供者によるカスタマイズ
▸ APIに関する情報
▸ API利用ワークフロー
▸ OpenAPI Spec (Swagger)
APIバックエンド
API Gateway
API Manager
API提供者
(事業部/プロダクトマネー
ジャ/開発者/Ops担当者)
APIリクエスト認証済 API リクエスト

Ver1.0
Red Hat 3scale API Management
3scale API Management 主な機能
▸ セキュリティ
▸ キー管理
▸ 流量制御
▸ ポリシー管理
▸ Appとユーザ管理
▸ プロビジョニング
▸ 分散アーキテクチャ
▸ 複数組織での利用
▸ 様々な環境に対応
▸ 高いスケーラビリティ
▸ 高機能な管理用API
▸ Webhooksによる自動化
▸ 分析機能
▸ Appのトラッキング
▸ API利用者のトラッキン
グ
▸ アラート
▸ デベロッパー支援機能
▸ OpenAPI (Swagger)
コントロール可視化柔軟性

Ver1.0
REST API
DB Adapter
Event
Consumer
Red Hat 3scale API Management
REST API
DB Adapter
Event
Publisher
Event
Consumer
バイヤー
EC サイト
UI サービス
バイヤー用UI
API Gateway
Mobile
REST API
DB Adapter
Event
Consumer
Event
Consumer
Mail Adapter
ユーザー
Mail Server
在庫在庫用UI

Ver1.0
サービス分割した場合の
デメリット

Ver1.0
サービス分割した場合のデメリット
サービス分割のデメリット
取り扱うサービス/その下のインフラストラクチャが増大
▸ それぞれのサービスで可用性を高めようとすると複雑で大変
▸ 監視対象が増加し、運用コストが跳ね上がる
▸ サービス間の繋がりが複雑化
○ ボトルネックの場所がわからなくなる
○ 障害が伝播する
▸ ロギングなど直接ビジネス要件とは関係のない機能をサービスごとに実装する必要あり

Ver1.0
OpenShift Container
Platform

84
KubernetesのValue
堅牢化された
コンテナ実行環境
OpenShiftのValue
20年以上にわたるビジネスクリティカルな顧客向け
にEnterprise OSSを提供してきた経験を Trustedなコ
ンテナ基盤に活用
Trust with Red Hat.
システムの自律運用化
自動インストールと Kubernetes運用の自律化は
OpenShiftの主要な機能であり、管理、アップグレー
ドを支援し、難易度の高いコンテナプラットフォーム
の提供を容易化
Manage with simplicity.
コンテナアプリの
本番適用
開発者がコードの提供とすぐに使える豊富なサポー
トを利用することで、開発作業に集中できる環境を提
供
Build fast. Ship first.
リソースの抽象化
Declarative Configuration
クラウドプロバイダごとに異なる実装や
サービスの詳細を知る必要がなく、開発者を特定の
インフラ依存から開放
高度なポータビリティを担保
自己回復性
Self-Healing
　Kubernetesは、現在のシステム状態が望ましい状
態に一致するように動作
システムが不安定になった場合や、
信頼性に影響を及ぼす障害時に、
定義した状態へ自動回復
自動スケーリング
Auto Scaling
起動するインスタンスのスケールアウトの
容易さに加え、
負荷状態に応じてリソース拡充を行うことや、不要リ
ソースの縮退を行うことが可能
Kubernetesの価値とOpenShiftの価値

Ver1.0
OpenShift
Container
Platform
REST API
DB Adapter
Event
Consumer
Red Hat OpenShift
REST API
DB Adapter
Event
Publisher
Event
Consumer
バイヤー
EC サイト
UI サービス
バイヤー用UI
API Gateway
Mobile
REST API
DB Adapter
Event
Consumer
Event
Consumer
Mail Adapter
ユーザー
Mail Server
在庫在庫用UI

Ver1.0
Red Hat OpenShift Service Mesh
[1] Kiali : https://github.com/kiali/kiali
サービスグラフ
Istio + Kiali [1] on Kubernetes

Ver1.0
Jaeger : https://www.jaegertracing.io/docs/1.21/
分散トレーシング
Istio + Jaeger [1] + Kiali on Kuberenetes

Ver1.0
サーキットブレーカー
Istio on Kubernetes の一機能
データベース
アダプタ
REST API
ドメイン
モデル
API 呼び出し
Proxy Proxy
データベース
アダプタ
REST API
ドメイン
モデル
▸ Istio が Kubernetes 上に Pod 展開する際に
Proxy を注入
▸ Pod 間の通信は Proxy 経由に
▸ アプリケーション側のコーディングが不要
▸ サービスに障害が発生すると Proxy が代わり
にエラーを返却
▸ Istio はサーキットブレーカーの他に以下の機
能を有する
▹ 負荷分散
▹ リクエストルーティング
▹ 流量制御
■ カナリアデプロイを実現
▹ タイムアウト / 再送回数決定
▹ フォールトインジェクション
(障害の注入)
Pilot Citadel Galley
Kubernetes の Pod Kubernetes の Pod

Ver1.0
OpenShift Service
Mesh + Red Hat SSO

Ver1.0
[1] Keycloak : https://www.keycloak.org/
アプリケーションの保護
Istio + keycloak[1] on Kubernetes
▸ アプリケーションを変更せずに、ゼロトラストセ
キュリティを構築
▸ 通信をIstioのコンポーネントである
Envoy(Proxy)に仲介させ、mTLSと
JWT(JSON Web Token)によるアクセス制御
を行う
▸ Keycloakの役割
- 認証・認可の実施とアクセストークンの
発行
- アクセストークンの検証
- 認証・認可のアクセス制御を一元管理
(RBAC,ABAC,UBAC等)
Ingress
JWT+mTLS JWT+mTLS
HTTP,gRPC,TCP
Keycloak
JWT+mTLS
access token
authentication,
access token
access token
access token
verification access token

Ver1.0
運用体制や開発体制の
変化

Ver1.0
運用体制や開発体制の変化
組織・体制も変える必要がある
IT 部門 IT 基盤チームが運用・監視それぞれの境界内で運用・監視していく必要あり

Ver1.0
運用を手助けする Operator
運用の知見をコード化し、アプリケーションの運用を自動化する
Kubernetes / OpenShift 上のアプリケーション運用における運
用の知見をコード化し、パッケージ化したもの
アプリケーション運用に必要な以下のような作業を自動的に行
う
▸ インストール
▸ リソーススケーリング
▸ バックアップ
▸ アップデート
運用の知見をコード化

Ver1.0
【参考】Operator Capability Level
AMQ Streams Operator の Capability Level

Ver1.0
REST API
DB Adapter
Event
Consumer
REST API
DB Adapter
Event
Publisher
Event
Consumer
バイヤー
EC サイト
UI サービス
バイヤー用UI
API Gateway
Mobile
REST API
DB Adapter
Event
Consumer
Event
Consumer
Mail Adapter
ユーザー
Mail Server
在庫在庫用UI
OpenShift
Container
Platform
AMQ
Streams
Operator
3scale
Operator

Ver1.0
イベント駆動/
リクエスト駆動

Ver1.0
REST API
DB Adapter
Event
Consumer
イベント駆動 / リクエスト駆動
REST API
DB Adapter
Event
Publisher
Event
Consumer
バイヤー
EC サイト
UI サービス
バイヤー用UI
API Gateway
Mobile
REST API
DB Adapter
Event
Consumer
Event
Consumer
Mail Adapter
ユーザー
Mail Server
在庫在庫用UI
OpenShift
Container
Platform
AMQ
Streams
Operator
3scale
Operator
▸ このサービスってそんなに頻繁に呼ばれないかもしれない
▸ イベントが届いた時だけ起動すればよいかも
▸ 起動していないうちは
CPU やメモリを他のサービスに明け渡すこと
ができるかも

サーバーレスの特徴
98
簡単に
始められる
ステートレス
必要に応じて
スケール
分散され
弾力性がある
イベント
駆動
Red Hat Serverless

なぜサーバーレスなのか？
Red Hat Serverless
テクノロジーはユーティリティである
サーバーレスのアプローチは、オンプレミスで提供する複雑さを抽象化します
いつも通りのビジネスとスピード
↓ 豊富なアーキテクチャとデザイン
↓ 管理とプロビジョニング
↓ キャパシティプランニングセッション
↓ Monoliths and Application Servers
サーバーレスアプローチ
↑ Kubernetesへのシンプルなアプローチ
↑ ワークロードの動的なスケール
↑ 常識的なデフォルト
↑ より実験的に、より詳細に

Knative Cloud Events
Serverless を可能にするもの
Red Hat Serverless

SERVING
アプリケーションと一緒にコンテナにサービスを提供するリクエスト駆動型モデルで、「ゼロにスケールする」ことができます。
Knative
101
Bringing Serverless Applications to Kubernetes
EVENTING
アプリケーションを活性化させるイベントを消費・生成するための共通インフラ。
CLIENT (kn)
コマンドラインやスクリプト内からインタラクティブにリソースを作成可能
Red Hat Serverless

Cloud Events
102
イベントデータを共通の方法で記述するための仕様
一貫性アクセシビリティポータビリティ
https://cloudevents.io/
Red Hat Serverless

OPENSHIFT
OpenShift Serverless
SERVING EVENTING
Red Hat Enterprise Linux CoreOS
Physical Virtual Private cloud Public cloud
Applications Events
F
FUNCTIONS
Knativeの機能を
パッケージ化して拡張し、オ
ペレーターがインストールし
て管理
Red Hat Serverless

✓ OpenShift Service Mesh
Support [doc]
■ Support for JWT
Auth[doc]
■ Custom Domains for
Knative Services[doc]
✓ OpenShift Pipelines
Templates and Tasks
✓ CLI Commands for
Eventing
Red Hat Serverless
Configuration
Revision 1
Revision 2
Revision 3
Routes
Directs
traffic
Functions
Microservices
Containers
Service Mesh Serverless Pipelines

Eventing
■ Brokers
✓ Built-in Event Filtering
✓ Routing based on event types or attributes
✓ Multiple event types
✓ Multi-tenant
■ Channels
✓ Event Fanout to multiple subscribers
✓ Same event type
✓ Single-tenant
Generally Available
Coming with OpenShift Serverless 1.11

Ver1.0
Red Hat Build Of
Quarkus

Ver1.0
Red Hat build of Quarkus
Red Hat build of Quarkus
すべての Java 開発者を Cloud Native に

Ver1.0
Red Hat Fuse / Camel K
https://tomd.xyz/camel-tutorial/
Apache Camel
Apache Camelは、Javaの配管ツールキットのようなものと考えることができます。実際の配管のよう
に、Camelはある地点からデータを受け取り、別の地点にパイプで送ります。その過程で、データを変
更したり、変換したり、他のパイプを経由して送信したりすることができます。

Ver1.0
Red Hat Fuse - Enterprise Apache Camel -
from().to() でシステム同士の連携を実現
Apache Camel
Enterprise Integration Pattern(EIP)を組み合わせて実装
to
from
コンシューマープロデューサー

Ver1.0
Enterprise Integration Pattern

Ver1.0
接続コンポーネントの一例
▸ camel-asn1
▸ camel-atomix
▸ camel-azure
▸ camel-caffeine
▸ camel-couchbase
▸ camel-crypto-cms
▸ camel-digitalocean
▸ camel-dns
▸ camel-drill
▸ camel-elasticsearch5
▸ camel-google-bigquery
▸ camel-google-pubsub
▸ camel-grpc
▸ camel-splunk
▸ camel-spring-cloud
▸ camel-spring-cloud-netflix
▸ camel-thrift
▸ camel-tika
▸ camel-twilio
▸ camel-zendesk
▸ camel-zookeeper-master
▸ camel-yql
▸ camel-aws
▸ camel-elasticsearch-rest
▸ camel-xhcange
▸ camel-wordpres
▸ camel-headersmap
▸ camel-jdbc
▸ camel-json-fastjson
▸ camel-milo
▸ camel-mongodb3
▸ camel-olingo4
▸ camel-openstack
▸ camel-opentracing
▸ camel-pubnub
▸ camel-reactive-streams
▸ camel-reactor
▸ camel-rest-swagger
▸ camel-sjms2

Ver1.0
【参考】API Gateway Pattern & BFF
サービス
API
Gateway
BFF サービス
サービス
UI
▸ UI のためにいくつものAPI を呼び出す必要
がある ▸ UI の代わりにBFF がそのまとめ役を担う
▸ UI には API を見せず、BFF のエンドポイントのみを公開

Ver1.0
Kubernetes Operator Camel K
連携ファイルを
作成
CLIツールによる
実行
OpenShift上で
Integration
コンテナが稼働
from(“knative:channel/xxxx”)
.transform()...
.to(“kafka:topic”)
from(“kafka:topic”)
.to(“http:my-host/api/path”)
$ kamel run integration.yaml
1
2
3

Ver1.0
【参考】Kamelets
車輪の再発明を防ぐ
Kamelets（Kamel route snipp ets）は、Camel Kで導入された新しい概念であり、ユーザーが簡素化されたインターフェイスを介して外部システムに接続できる
よ
うにし、それらの接続の
実装方法に関するすべての低レベルの詳細を隠蔽
します。
Kamelets は、データの「ソース」または「シンク」として機能できます。ソースは外部システムからのデータを消費でき、シンクはデータを外部システムに送信したり、
特定のアクションを実行して結果を取得したりできます。
Kamelets Catalog
OpenShift Container Platform
S3
S3 Source
kamel run
Kafka Sink
既存システムのデータをイベント化する際にカタログ化
Kemelet として自作し OpenShift に登録しておくことも可能
プライベートカタログも予定

Ver1.0
REST API
DB Adapter
Event
Consumer
REST API
DB Adapter
Event
Publisher
Event
Consumer
バイヤー
EC サイト
UI サービス
バイヤー用UI
API Gateway
Mobile
REST API
DB Adapter
Event
Consumer
Event
Consumer
Mail Adapter
ユーザー
Mail Server
在庫在庫用UI
OpenShift
Container
Platform
AMQ
Streams
Operator
3scale
Operator
Camel
K
Operator
Serverless

Ver1.0
OpenShift
Container
Platform
AMQ
Streams
Operator
3scale
Operator
Camel
K
Operator
チェンジイベントのケース
REST API
DB Adapter
REST API
REST API
DB Adapter
DB Adapter
Mail Adapter
在庫
Event
Consumer
Mail Server
Log Miner
EC サイト
UI サービス
Mobile
ユーザー
API Gateway
マーケ用UI
在庫用UI
Serverless
Serverless
Serverless

コンテナとクラウドネイティブアプリケーションの開発
Red Hat Integration
121
Source
▸ Debeziumによるチェンジ
データキャプチャ
API管理
Events & Messaging
Enterprise Integration
Data Integration
▸ 多様なコネクタ
▸ マイクロサービスのオーケスト
レーション
▸ データ変換
▸ ローコードのiPaaS
▸ Camel Kによるサーバーレス
▸ JMS Message Broker
▸ 広域でのルーティング
▸ Apache Kafkaによる
データストリーミング
▸ メッセージングのセルフ
サービス化
▸ API Manager
▸ API Gateway
▸ Istio Service Mesh
Adapter
ツールとメタデータ管理
▸ Service Registry
▸ API Designer

122
PHYSICAL VIRTUAL PRIVATE CLOUD PUBLIC CLOUD
Red HatのCloud-Native Applicationのためのプラットフォーム
APPLICATION SERVICES
App開発と移行
のためのコアツール
ビジネスプロセス
の自動化と最適化
マイクロサービス
の連携を実現
RUNTIMES
INTEGRATION PROCESS AUTOMATION
オンプレ/クラウド/ハイブリッドな
アーキテクチャのためのクラウドネイティブ
Appの作成、実行、運用環境
PHYSICAL VIRTUAL PRIVATE CLOUD PUBLIC CLOUD
コンテナとクラウドネイティブアプリケーションの開発

Ver1.0
linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHat
Thank you.

マイクロサービスと Red Hat Integration

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Recently uploaded

Recently uploaded (10)

マイクロサービスと Red Hat Integration