マイクロサービスと データ連携 Red Hat Japan 2021 Feb

war war war war / jar 3層アーキテクチャ Java でよく実装されていた (今も？)アーキテクチャ RDBMS 等 AP サーバー プレゼンテーション層 ビジネスロジック層 データアクセス層 ページの描画などを担当する ▸ ページから受け付けたリクエストを処理 ▸ ビジネスロジックを記述する ▸ 状況に応じてデータアクセス層へ依頼を出し、 データの永続化や参照を図る 依存関係 エンティティモデルの永続化 /参照を担当 ▸ 例えば、RDBMS を MongoDB に変更しようとすると、 データアクセス層はもちろん、それに依存している ビジネスロジックやプレゼンテーション層にまで影響が発生 ▸ ビジネスロジックは本来ビジネスルールの変更のみの影響を 受けるべきだが、本アーキテクチャではインフラストラクチャの変 更の影響を受けてしまう Web ブラウザ

REST API 等 DB アダプタ ドメイン モデル 本資料で登場するヘキサゴナルアーキテクチャ [1] 派生のオニオン/クリーンアーキテクチャも存在 [1] : CodeZin 実践DDD本 第4章「アーキテクチャ」 ～レイヤからヘキサゴナルへ～ https://codezine.jp/article/detail/9922 アダプター (外部からデータが入ってくる REST API の口や、データ ベースへ書き込む RDBMS へ接続するアダプター ) アプリケーションサービス (ドメインモデルを活用してビジネスのユース ケースを記述する ) ドメインモデル (ビジネスロジックを閉じ込める ) 依存関係 UI RDBMS 等 FatJar / AP サーバー ▸ 内側のレイヤーは外側のレイヤーからしか呼び出せない ▸ アダプター層はアプリケーションサービスで実装されている ユースケースメソッドを通じて内側の層にアクセスする ▸ インフラの変更 (たとえば RDBMS から MongoDB)によって、 ビジネスロジックを変更する必要がない ▸ ビジネスロジックがいかなる変更にも守られて強固なアプリケーショ ンとなる Web ブラウザ

同期型マイクロサービス

マイクロサービス 同期型マイクロサービスとは 一つ一つのサービスはシンプル ※ 六角形は DDD(Domain Driven Design)におけるヘキサゴナルアーキテクチャ データベース アダプタ REST API アダプタ ドメイン モデル ▸ マイクロサービスごとにデータベースが存在 (データ ベースが不要なサービスも存在 ) ▸ ワークロードにあったデータソースを選択 ▹ トランザクションが必要なサービスは RDBMS を選択 ▹ トランザクションにこだわると新しい 技術はほとんど採用不可に マイクロサービスは以下を引き上げる ▸ メンテナンス性 ▸ テスト容易性 ▸ デプロイ容易性 ▸ 技術的な自由(開発言語、ツール等 ) ▸ スケーラビリティ (必要なサービスのみスケール ) ▸ REST API や gRPC の口を持っている

会計サービス デリバリーサービス なぜ1サービス = 1DBなのか 共有 DB を使用するとスキーマを通して密結合アプリが完成 データベース アダプタ REST API アダプタ ドメイン モデル REST API アダプタ ドメイン モデル データベース アダプタ 1. テーブルの列名ユースケースに合わせ て変更しておくか 1’. あれ？サービスが動かない DB 問い合わせでエラーに・・ 列名変わってる！ 2’. DB に追加した覚えのない住所の列 があるけど REST の問い合わせで返却 できるようにしておこう (会計サービスに住所は不要でサービス肥大化の 原因) 2.うちのマイクロサービスに配達住所が 不足してるから住所の列いくつか 追加しておくか せっかく分離したサービスの密結合を生み出す原因 3. このサービスは速度命だから、 検索性能向上のために DB に インデックス貼っておくか 3’. DB の書き込み性能がすごい 劣化した・・・ 原因は？？ Stripe アダプタ

会計サービス データベース アダプタ REST API アダプタ ドメイン モデル デリバリーサービス 同期型マイクロサービス間のデータ連携 REST API や gRPC などの方法で問い合わせる データベース アダプタ REST API アダプタ ドメイン モデル REST クライアント ▸ 必要なデータは必要なデータを所持しているサービ スに問い合わせる ▸ スキーマ変更は自由に可能 ▸ REST API が DB スキーマの変更を吸収 ▸ 新バージョンリリースに関して A/B テスト、 Blue / Green デプロイメントをできるように しておく トランザクション xxx の会計に 使った決済方法や金額教えて！ Stripe アダプタ

少し複雑になると Netflix では数千のマイクロサービスで構成される データベース アダプタ REST API アプリケーション ドメイン モデル API Gateway データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し

障害発生時 あるサービスに障害が発生 データベース アダプタ REST API アプリケーション ドメイン モデル API Gateway データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し

障害発生時 データベース アダプタ REST API アプリケーション ドメイン モデル API Gateway データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し ▸ このサービスの問題は他のサービスに影響を与えないか

同期型マイクロサービス のデータ連携の課題

障害発生時 同期通信はレスポンスを待ち受ける データベース アダプタ REST API アプリケーション ドメイン モデル API Gateway データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し

障害発生時 同期通信はレスポンスを待ち受ける データベース アダプタ REST API アプリケーション ドメイン モデル API Gateway データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し

障害発生時 同期通信はレスポンスを待ち受ける データベース アダプタ REST API アプリケーション ドメイン モデル API Gateway データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し

この問題に対する解決策 複数の選択肢が存在 Netflix Hystrix 非同期型マイクロサービス Istio -Service Mesh- イベント駆動マイクロサービス

同期通信の障害伝播に対する解決策 Netflix Hystrix 非同期型マイクロサービス Istio -Service Mesh- イベント駆動マイクロサービス

Netflix Hystrix

会計サービス デリバリーサービス サーキットブレーカー Netflix Hystrix データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し データベース アダプタ REST API アプリケーション ドメイン モデル ▸ サービスに送ったまま反応が返ってこないリクエ ストをいくつまで許容するかを決める ▸ サービスが利用不可の場合、キャッシュを利用し たり、即座にエラーとするなどの処理をとることが できる (クライアント側で実装されたフォールバックメソッ ドが呼び出される) ▸ アプリケーションの実装が必要 ▸ Java でしか実装できない ▹ マイクロサービスの自由を奪う フォールバックメソッド 呼び出し Stripe アダプタ

非同期型 マイクロサービス

同期通信の障害伝播に対する解決策 複数の選択肢が存在 Netflix Hystrix 非同期型マイクロサービス Istio -Service Mesh- イベント駆動マイクロサービス

[1] : マイクロサービスとメッセージングのなぜ : https://rheb.hatenablog.com/entry/microservices_messaging 非同期型マイクロサービスとは [1] メッセージングミドルウェアが疎結合の肝に データベース アダプタ アプリケーション ドメイン モデル イベント パブリッシャ コマンド クエリー API <<コマンドチャネル >> <<リプライチャネル >> <<イベントチャネル >> ▸ メッセージングミドルウェアがバッファの役目を担う ▹ アプリケーションに障害が発生してもメッセージ投入者はコマンドを 引き続き投入可能 ▸ メッセージチャネルとコマンド・リプライ・イベントの 3種類のメッセージタイプから構成される (イベントについては後述 ) ▸ 一方通行のデータ連携の場合、リプライチャネルは不要 ▸ REST の代わりにメッセージングミドルウェアのトピック / キューで リクエストを受け付ける ▸ コマンドチャネルにはリクエストが送信される ▸ リプライチャネルにはレスポンスが送信される メッセージングミドルウェア マイクロサービス

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

人の管理ではそのうち限界を迎える 非同期型マイクロサービスを導入しても迎える限界 データベース アダプタ REST API アプリケーション ドメイン モデル API Gateway データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し API 呼び出し 新バージョンリリースしたいけど、周りのサー ビスに影響与えないようにしたい パフォーマンス問題はどこがボトルネックな の？？？ どこかのサービス落ちてる 再起動しなきゃ、どこが落ちてるの？ ノード障害で複数サービス全部逝ったぁ OS のパッチ当てるのどうしたらいいの？ ローリングアップデートできる？ ミドルウェアのパッチ当てるにはどうしたらい いの？

イミュータブル インフラストラクチャの検 討

マイクロサービス運用する際の課題 ▸ この DB って自分のローカル環境だとバイナリがないんだけど ▸ ステージング環境の DB 誰が汚したの？テスト成功しないんだけど ▸ (ビルド、テスト、デプロイ ) × マイクロサービス分が大変・・・ ▸ プロパティや環境変数等の違いでテスト環境と本番環境で動作が違う ▸ 既存のサービスに影響が出ないように新バージョンをデプロイしなければ・・・ ▸ どのサービスがどのサービスを呼び出している？ ▸ 新しいサービス追加したからサービス関連図更新しなくちゃ・・・ ▸ エラー/障害がどのサービスで発生している？ ▸ このサービスで発生している障害って連鎖してない？ ▸ どうやって障害を元に戻す？再起動？ ▸ どのサービスのどの部分が遅くなっている？？ ▸ ミドルウェアのアップデートしなければ 開発者・ビルド担当者 運用者

[1] Kubernetes とは何か : https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/ 自動化され、どこでも同じように動くインフラが必要 Kubernetes [1] サービスディスカバリーと負荷分散 Kubernetes は、DNS 名または独自の IP アドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、 Kubernetes は負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。 ストレージオーケストレーション Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。 自動化されたロールアウトとロールバック Kubernetes を使うとデプロイした コンテナのあるべき状態を記述 することができ、制御されたスピードで実際の状態をあるべき状態に変更することが できます。例えば、 アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用す る作業を、Kubernetes で自動化できます。 自動ビンパッキング コンテナ化されたタスクを実行するノードのクラスターを Kubernetes へ提供します。各コンテナがどれくらい CPUやメモリー(RAM)を必要とするのか をKubernetesに宣言することができます。 Kubernetes はコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。 自己修復 Kubernetes は、処理が失敗したコンテナを再起動し、 コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了 します。処理の 準備ができるまでは、クライアントに通知しません。 機密情報と構成管理 Kubernetesは、パスワードや OAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメー ジを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。

ここからは Kubernetes 前提

[1] Kiali : https://github.com/kiali/kiali サービスグラフ Istio + Kiali [1] on Kubernetes

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

同期通信の障害伝播に対する解決策 複数の選択肢が存在 Netflix Hystrix 非同期型マイクロサービス Istio -Service Mesh- イベント駆動マイクロサービス

サーキットブレーカー 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

イベント駆動 マイクロサービス

同期通信の障害伝播に対する解決策 複数の選択肢が存在 Netflix Hystrix 非同期型マイクロサービス Istio -Service Mesh- イベント駆動マイクロサービス

カートを使用するアプリケーション 真っ先に思いつくのはセッション + DB を使った永続化 商品 B 1 ・・・ 商品 A 1 ・・・ 1. 商品 A をカートに追加 2. 商品 B をカートに追加 3. 商品 A をカートから削除 商品 数量 ・・・ RDBMS 等

RDBMS に保存されるのは最新の状態 状態中心のアプリケーション 商品 B 1 ・・・ 商品 数量 ・・・ RDBMS 等

AI/ML に必要なのは過去のデータ 状態中心のモデルだと過去のデータは手に入らない 商品 B 1 ・・・ 商品 数量 ・・・ RDBMS 等 最新の状態しか手に入らない ▸ 商品 A & B 両方がカートに入っていたという 事実は再現不可 ▸ 商品 A をカートに入れていたという 事実は消える ▸ 商品 A をカートから削除したという 事実も消える

状態の代わりになるもの イベント カートを 作成した 商品 A を追加 した 商品 B を追加 した 商品 A を削除 した 1 2 3 4 操作順 ？

[1]: マイクロサービスとメッセージングのなぜ [概要編] イベントは履歴になる 過去の状態はどう再現するか イベントをリプレイする カートを 作成した 商品 A を追加 した 商品 B を追加 した 1 2 3 ①〜③を順に実行すれば過去の状態を再現可能 ？ 商品 A を削除 した 4 この時点のカートの情報が欲しい カートを 作成した 1 商品 A を追加 した 2 商品 B を追加 した 3

* : DDD : Domain Driven Design ドメイン駆動設計のこと [1] : イベント・ストーミング : https://www.eventstorming.com/ [2]: Event Storming and Spring with a Splash of DDD : https://spring.io/blog/2018/04/11/event-storming-and-spring-with-a-splash-of-ddd イベントを元にマイクロサービスの境界を決定 イベント・ストーミングワークショップ イベント・ストーミング[1] は、発生するイベントを基準として、業務を DDD の 複数ドメインに分割する手法であり マイクロサービス分割粒度を決定する方法としても有用です Event Stormingイメージ図[2] 2. イベントを生成するコマンド を洗い出し(ブルー) 
 1. 業務で発生するイベントを洗 い出し(オレンジ) 
 3. イベント発生条件を 
 洗い出し(イェロー) 
 4. グルーピングすることで、ドメ イン分割


共有データベースをイベントで分解 クラウドネイティブデータパイプラインの構築 Shared Database (RDBMS) ▸ 容易にスキーマ変更ができない ▸ RDBMS はスケールアップしか選択肢がなく高コスト ▸ アプリケーションがデータベースのテーブル 中心のモデルになり可読性や変更性が低下 ▸ サービスに不要なデータを付与しがち ▸ 個々のサービスの責任範囲が巨大化 DB ストリーミング プラットフォーム イベントに変換 In-Memory Cache Object Storage Elastic search アダプタ UI REST API AI/ML モデル トレーニング Kibana 書き込みをトランザクションで正しく 高速にリードを実現 (イベントから最新の 状態をリプレイ ) データパイプラインを構成 (複数分岐 ) データの長期保存 データの分析 アダプタ REST API アダプタ イベントを直接ストリーミングプラットフォー ムへ REST API

Notification サービス Shipping サービス Orders サービス イベント駆動型マイクロサービスの例 ドメインイベントによるデータの連携 データベース アダプタ REST API アプリケーション ドメイン モデル イベントパブ リッシャ データベース アダプタ イベントコン シューマー アプリケーション ドメイン モデル イベント プロデューサー データベース アダプタ イベントコン シューマー アプリケーション ドメイン モデル イベント プロデューサー データベース アダプタ イベントコン シューマー アプリケーション ドメイン モデル イベント プロデューサー データベース アダプタ イベントコン シューマー アプリケーション ドメイン モデル Mail アダプタ API Gateway ストリーミング・ プラットフォーム Billing サービス Inventory サービス

[1] Knative Eventing : https://knative.dev/docs/eventing/ Knative Serving & Eventing [1] on Kubernetes with Istio Trigger Email サービス ログサービス ポイントサービス Trigger Trigger New Event Broker New Event New Event Event Source New Customer created event Event Providers ▸ Knative Serving - サーバーレス - ▹ イベントを契機に起動 ▹ 処理が終わると終了することも可能 (Pod 数0) ▹ 流量制御が可能 ■ バージョン 1 を 80% バージョン 2 を 20% 等 ▸ Knative Eventing ▹ Event Source や Broker(メッセージングミドルウェア )や その他コンポーネントから構成 ▹ ここで登場しているのは一部のみ ▹ イベントを Serving に届ける仕組みを提供 ▸ 既存システムのイベントを取得することが可能 ▸ Knatvie Eventing の構成要素の一つ ▹ 自分に興味があるイベントのみをフィルタ

Knative ユースケース OpenShift Serverless + オブジェクトストレージの例 Topic: Storage 分析: 肺炎のリスク 個人情報 削除 患者 No.451 Name : ジョン・ドゥ RISK リスク >80% No Yes Name : ジョン・ドゥ 診断結果追記 保存 保存 個人情報付きの X線写真データ がオブジェクトストレージの Bucket に投入 オブジェクトストレージ (OCS)が Bucket Notification を Kafkaに 発行 Kafka をイベントソース (KafkaSource) としてサーバー レスアプリケーション (Knative Serving) が自動で画像 分析と診断のプロセスを作成 READ READ 処理した画像を用途ごとに適切な Bucketに保存 Name : ジョン・ドゥ OK 医療機関 研究機関 アーカイブ 診断結果 研究用途

Red Hat Portfolio

Red Hat ミドルウェア製品ポートフォリオ マイクロサービスの開発に活用可能な製品群 AUTOMATION RUNTIMES DATA GRID 既存システムをAPI化し、分散したマイ クロサービスを組み合わせて連携させ る製品群 INTEGRATION ビジネスプロセスの自動化と 最適化 複数クラウドをまたがって開発、デプロイ、管理が可能 アプリケーションを開発する上で コアとなる開発ツール AMQ BROKER

イベント駆動マイクロサービス ドメインイベントによるデータの連携 データベース アダプタ REST API アプリケーション ドメイン モデル イベントパブ リッシャ Orders サービス データベース アダプタ イベントコン シューマー アプリケーション ドメイン モデル イベント プロデューサー Billing サービス データベース アダプタ イベントコン シューマー アプリケーション ドメイン モデル イベント プロデューサー Shipping サービス データベース アダプタ イベントコン シューマー アプリケーション ドメイン モデル イベント プロデューサー Inventory サービス データベース アダプタ イベントコン シューマー アプリケーション ドメイン モデル Notification サービス Mail アダプタ API Gateway ストリーミング・ プラットフォーム Fuse 3scale API Management AMQ Streams Quarkus / JBoss EAP / Spring Boot Decision Manager

Integration Bootcamp バーチャルトレーニングで行うブートキャンプ！！ インテグレーションの基礎を実技演習しながら学べる オンサイトトレーニング：インテグレーションブートキャンプ 　 　AD421 　Camel Integration and Development with Red Hat Fuse on OpenShift 　エンタープライズ統合パターン (EIP) を使用してアプリケーションを 　開発、実装、テスト、およびデプロイする方法の学習 　Java™ 開発者およびアーキテクトを対象とした実践演習形式のコースです。 　Apache Camel、および Camel 開発のサポートで Red Hat が提供する拡張機能や各種ツールに 　ついて学習します。 　学習内容サマリー ▸ 基本ルートと、 Camel との統合ソリューションを作成する ▸ 集約によってメッセージを結合する ▸ Camel テストキットとモックコンポーネントでテストを開発する ▸ REST DSL と Swagger で REST サービスを開発する ▸ Karaf、EAP、Spring Boot にルートをデプロイする ▸ 並行処理でルートのスループットを向上させる ▸ Red Hat Fuse on OpenShift でマイクロサービスをデプロイする 　 　AD240 　Build and Administer APIs with Red Hat 3scale API Management 　Red Hat 3scale API Management による標準手法を使用した API の構築と管理の概要 　開発者および管理者向けの実践的なラボベースのコースで、 API を管理する方法の概要を 　習得できます。 API を収益化、管理、文書化できます。 　学習内容サマリー ▸ 3scale API Management のアーキテクチャと主な機能を理解する ▸ 代表的な API ユースケースと戦略を学ぶ ▸ 3scale API Management デプロイのオプションを調査する ▸ サブスクリプションプランを確立して設定する ▸ API 管理統合を設定してテストする ▸ 開発者ポータルを構成する ▸ Red Hat SSO 統合をセットアップする 本コースは、2つのコースの実機演習を通じて、インテグレーションアプリケーション開発やAPI管理、メッセージング基盤管理の基礎を習得することができます。 Red Hat Integrationの主要コンポーネントであるFuse, 3scaleのハンズオントレーニングをインストラクターの指導のもとで短期間（5日間）で実施する演習形式 の集中トレーニング　※LS120 Red Hat Lerning Subscription Basicが付属されます

マイクロサービス 同期型マイクロサービスとは 一つ一つのサービスはシンプル ※ 六角形は DDD(Domain Driven Design)におけるヘキサゴナルアーキテクチャ データベース アダプタ REST API アダプタ ドメイン モデル Quarkus / JBoss EAP / NodeJS / Spring Boot Decision Manager Data Grid

非同期型マイクロサービス AMQ Broker / AMQ Streams Quarkus / JBoss EAP / Spring Boot データベース アダプタ アプリケーション ドメイン モデル イベント パブリッシャ コマンド クエリー API <<コマンドチャネル >> <<リプライチャネル >> <<イベントチャネル >> メッセージングミドルウェア マイクロサービス

[1] Kubernetes とは何か : https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/ 自動化され、どこでも同じように動くインフラが必要 Kubernetes [1] サービスディスカバリーと負荷分散 Kubernetes は、DNS 名または独自の IP アドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、 Kubernetes は負荷分散し、ネットワークトラフィックを振り分けることができるたため、デプロイが安定します。 ストレージオーケストレーション Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。 自動化されたロールアウトとロールバック Kubernetes を使うとデプロイした コンテナのあるべき状態を記述 することができ、制御されたスピードで実際の状態をあるべき状態に変更することが できます。例えば、 アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用す る作業を、Kubernetes で自動化できます。 自動ビンパッキング コンテナ化されたタスクを実行するノードのクラスターを Kubernetes へ提供します。各コンテナがどれくらい CPUやメモリー(RAM)を必要とするのか をKubernetesに宣言することができます。 Kubernetes はコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。 自己修復 Kubernetes は、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了 します。処理の 準備ができるまでは、クライアントに通知しません。 機密情報と構成管理 Kubernetesは、パスワードや OAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメー ジを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。 OpenShift Container Platform

サーキットブレーカー Istio on Kubernetes の一機能 データベース アダプタ REST API アプリケーション ドメイン モデル API 呼び出し Proxy Proxy データベース アダプタ REST API アプリケーション ドメイン モデル Pod Pod Pilot Citadel Galley OpenShift Container Platform OpenShift Service Mesh (Istio + Kiali + Jaeger)

イベント駆動マイクロサービスII DB ストリーミング プラットフォーム イベントに変換 In-Memory Cache Object Storage Elastic search アダプタ UI REST API AI/ML モデル トレーニング Kibana アダプタ REST API アダプタ REST API AMQ Streams Fuse Ceph Storage / OpenShift Container Storage Data Grid Change Data Capture Quarkus / JBoss EAP / Spring Boot Decision Manager

[1] Knative Eventing : https://knative.dev/docs/eventing/ Knative Serving & Eventing [1] on Kubernetes with Istio Trigger Email service Log service Loyalty points service Trigger Trigger New Event Broker New Event New Event Event Source New Customer created event Event Providers OpenShift Serverless Camel K (Tech Preview) / Camel Kafka Connector (Tech Preview) AMQ Streams Quarkus / Camel K (Tech Preview) ※ サーバーレスに適したフレームワーク

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