Developer_Webinar_Series_2020_Digest

Transcript

1. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 1 モノリスなレガシーアプリケーションのマイクロ サービス化など、クラウドやコンテナと親和性 の良いアーキテクチャへとモダナイズする方 法論について、 Red Hatのベストプラクティス などをベースにお話します。 Cloud Nativeを見据えたアプリケー ションアーキテクチャとレガシーモダナ イゼーション 松田 絵里奈 Senior Specialist Solution Architect, Red Hat K.K. コンテナベースでの DevOpsのプロセスのベ ストプラクティスや、開発環境自体のコンテナ 化によって開発環境の構築や維持にかかる 労力を削減できる CodeReady Workspacesを ご紹介します。 コンテナ時代の開発ツールチェインと 開発プロセスのベストプラクティス 須江 信洋 Associate Manager of Specialist Solution Architect / OpenShift Specialist, Red Hat K.K. マイクロサービスやサーバーレスの実践にお ける課題や考慮点と、その対策としてのサー ビスメッシュや分散トレーシングについて紹介 します。また、メッセージング (イベント)による 分散インテグレーションについても簡単に紹 介します。 マイクロサービス/ サーバーレス実践入門 笹川 博幸 Specialist Solution Architect, Red Hat K.K. 新旧アプリケーションや多様な SaaS利用など で進むシステム分散化に対処するためには、 全てのシステムをセキュアに連携する APIの 設計、実装、デプロイ、管理を行う基盤が必 要です。ここではそれらをアジャイルに実現す るための手法をお話しします。 これからのシステム連携を実現する デジタル基盤とアプローチ 杉本 拓 Senior Specialist Solution Architect, Red Hat K.K. JavaEEアプリケーション・サーバーのコンテナ 対応状況、マイクロサービスに適した MicroProfileの動向、そして JavaをCloud Nativeに変容させる革新的なフレームワーク であるQuarkusについて紹介します。 クラウド/コンテナを前提とした時代の アプリケーション実行環境の選択 伊藤 ちひろ Specialist Solution Architect, Red Hat K.K. Cloud Native なアプリケーションを実現する 際にボトルネックとなりがちなレガシーの巨大 な RDBMS をどのように解体していけばよい か、どのようにデータ連携をすれば良いかを ご紹介します。 Cloud Nativeなデータパイプラインの 作り方とオープンハイブリッドクラウド への展開 小杉 研太 Specialist Solution Architect, Red Hat K.K. 第１回 第２回 第３回 第４回 第５回 第６回 概要 概要 概要 概要 概要 概要 Developer Webinar Series 2020 Digest
2. ハッシュタグ #RHdevjp Red Hat Developer Webinar Series 2 レッドハット株式会社 
 シニアソリューションアーキテクト　松田　絵里奈 
 Cloud Nativeを見据えた
 アプリケーションアーキテクチャと
 レガシーモダナイゼーション

3. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 3 本セッションでお話すること
 レガシーアプリケーションを
 クラウドネイティブなアプリケーションに移行する際の
 重要なポイントとおすすめの移行方法

4. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 4 立ちはだかる壁
 • モノリシックなアプリケーションをどう分割するか？
 • 長きにわたるメンテナンスによりコードがスパゲティ状態
 • ドキュメント未整備のためブラックボックス化
 • ウォーターフォール開発から脱却しなければとは思うが、経験がない
 
 
 　　　　さて、どうする？

5. ハッシュタグ #RHdevjp 5 “ルール駆動開発”をおすすめします
 ルール駆動開発の詳細については、ぜひWebinar本編をご覧ください！
6. ハッシュタグ #RHdevjp 第1回質問と回答ダイジェスト # 質問 回答 1 デシジョンサービスとして切り出した 際に、複数のルールがある場合は、 ルールごとに別モジュールに分割し ますか？ 「デシジョンサービス」単位で１つのモジュールとします。細かくルール 単位で関数呼び出しのようにしてしまうと、呼び出し元と呼ばれる ルール側が蜜に相関してしまうため、適切ではありません。 一度のデータのやり取りで、関連するルールをすべて一括実行できる ように設定すべきです。 2 現行コードを一切見ずに移行を行う ことが本当に可能なのでしょうか？ 現行コードを最初に見てしまうと、そこに実装されている手続き的な処 理にとらわれてしまい、本来必要な要件を見失い、不要な処理まで移 行してしまうことがあります。現行コードを見ずに、要件ヒアリングから はじめて、それでもどうしても結果が現行と一致しない場合にのみ、ピ ンポイントで現行コードを見に行くようにするのが効率的です。 3 「幹となるルール」はどのように決め るのでしょうか？ １〜２回のヒアリングで得られる、業務担当者が皆知っているような業 務ルールを根幹ルールとします。つまり、業務担当者側にとっての 「幹」を基準とします。 6 Copyright 2020 Red Hat K.K.
7. ハッシュタグ #RHdevjp Red Hat Developer Webinar Series 7 レッドハット株式会社 Associate Manager of Specialist Solution Architect 須江 信洋 (nosue@redhat.com) コンテナ時代の開発ツールチェインと 開発プロセスのベストプラクティス
8. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 8 本セッションでお話すること • コンテナの適用によって開発プロセスがどう変わるか?
 • コンテナを使いこなすためにはどうすればよいか?
 • 開発者のワークスペースをコンテナ化したら?

9. ハッシュタグ #RHdevjp 9 Continuous Integration and Continuous Delivery (CI/CD) Code Run Debug Build Int Test Package Deploy Stage GIT COMMIT RELEASE LOCAL DEVELOPMENT CONTINUOUS INTEGRATION CONTINUOUS DELIVERY ... Kubernetes? Kubernetes? Kubernetes? (1)コンテナ化はCI環境から 始めるのがオススメ (2)プロダクション環境では Kubernetesが(ほぼ)必須 (3)ローカル開発環境も Kubernetesで集中管理
10. ハッシュタグ #RHdevjp コンテナベース・アプリケーションの設計原則 https://www.redhat.com/ja/resources/cloud-native-container-design-whitepaper Copyright 2020 Red Hat K.K. 10
11. ハッシュタグ #RHdevjp New Editor: ブラウザの中で実行されるVS Code ▸エディターのコンテナ化: ゼロインストールと構成の自動化 Eclipse Theia拡張 最先端のエディター体験を提供 ビルトイン: ⌁ Languages Server Protocol ⌁ Debug Adapter Protocol VSCode extensionsとの互換性 NEW EDITOR Copyright 2020 Red Hat K.K. 11
12. ハッシュタグ #RHdevjp # 質問 回答 1 CI/CDのパイプラインを作る場合に JenkinsとTektonとどちらがおすすめ ですか？ どちらも一長一短がありますので、ケースバイケースで使い分けていた だくのがよいかと思います。 Jenkinsは実績や豊富なプラグインがあり ますが、常時稼働するサーバーが必要なのでリソース利用の観点では 不利ですし、コンテナ対応はネイティブ機能ではないのでいろいろ工夫 が必要です。Tektonはサーバーレスアーキテクチャでリソース利用は 効率的ですが、まだまだ発展途上であり、エコシステムも限られていま す。しかし、コンテナやクラウドネイティブなアプリケーションの開発には 適しており、特にKubernetes/OpenShift上でビルドを行う場合にはイン テグレーションが容易です。 2 OCPでIoT、AI等の様子(要素?)入れ た設計は可能でしょうか。 事例があれ ば共有いただければと思います。 可能ですし、実際にそのような使い方をしている事例もあります。 https://www.openshift.com/learn/topics/ai-ml OpenShiftの機能をうまく活用いただくことで、 AI/MLのワークフローを DevOps対応/セルフサービス化していくという使い方が多いです。 OpenShift/Kubernetes上でAI/MLのワークフローを実装するための オープンなリファレンスアーキテクチャ (OpenDataHub)も公開しており ますのでご参考になさってください。 https://opendatahub.io/docs.html 12 Copyright 2020 Red Hat K.K. 第2回質問と回答ダイジェスト
13. ハッシュタグ #RHdevjp Red Hat Developer Webinar Series 13 レッドハット株式会社 ソリューションアーキテクト 伊藤 ちひろ クラウド/コンテナを前提とした時代の アプリケーション実行環境の選択
14. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 14 本セッションでお話すること • ランタイムの選択には何を考慮しないといけないのか • Red Hat が持つランタイム ･ Jakarta EE ･ MicroProfile
15. ハッシュタグ #RHdevjp Fast Monolith 既存、Java EE、 Spring MVC Java EE MSA Monolith解体、 Enterprise Java MSA Fast Monolith （Java EE、 Spring） Tomcat Spring Boot / MVC Web Tomcat、 Spring MVC、 SpringBoot 新規開発 リアクティブJava Java EE – Monolith からマイクロサービス へ /新規開発 リアクティ ブ リアクティブ Java /ポリグ ロットMSA リアクティ ブJS リアクティブク ライアント/ サーバーサイ ドJavaScript 新規開発 ポリモーフィッ ク JavaScript サー バーレ ス FaaS 既存アプリケーション Spring MSA Java MSA 新規開発 Java / Spring MSA エンタープライズアプリケーションの全景 新規アプリケーション 15
16. ハッシュタグ #RHdevjp Copyright © 2020 Red Hat K.K. All Rights Reserved. Red Hat Runtimes ハイブリッドクラウド環境におけるアプリケーション開発のツールとランタイム クラウドネイティブなアプリケーショ ンの開発に最適化: ✓ すぐに始められる ✓ 簡単にコンテナ化 ✓ DevOpsの自動化 ✓ ツールとプロセスの標準化 ✓ JDKの完全なサポート OpenShiftとKubernetesのサービスに最適化 Red Hatの開発ツール、CI/CDツール、セキュリティサービスと連携 アプリケーションマイグレーションツールキット Python, Go, .Net などのRed Hatによるサポート (ただしSLAは異なります) LAUNCH SERVICE JAVA WEB JBOSS WS JAVA/JAKARTA EE JBOSS EAP, OPEN LIBERTY JAVA SE OPENJDK SERVERLESS CLOUD FUNCTIONS* SPRING SPRING BOOT JAVASCRIPT NODE.JS DISTRIBUTED DATA DATA GRID MESSAGING AMQ BROKER SSO MICROPROFILE THORNTAIL, OPEN LIBERTY REACTIVE VERT.X SECURITY JAVA.NEXT QUARKUS* *Coming Soon 前 回 の 振 り 返 り
17. ハッシュタグ #RHdevjp 第3回質問と回答ダイジェスト # 質問 回答 1 Quarkusを利用する場合、Red Hat からサポートが提供されますか ? 第3回の Webinar ではサポートを提供していないと話しましたが、そ の夜に Red Hat から Quarkus が GA されました。これによって Red Hat Runtimesのサブスクリプションを購入いただくことで Red Hat の サポートを受けられます。 2 Quarkus をネイティブイメージで実 行するともの凄く軽量に、高速に起 動するとのことですが他にはメリット やデメリットはあるのでしょうか Quarkus をネイティブイメージで使う時に GraalVM を使用していま す。そのため、GraalVM の制約は Quarkus も同様に制約となりま す。たとえば Java のリフレクションが使えないなどが上げられます。 Quarkus は依存関係に外部ライブラリを追加するだけで使用できる ようになりますが、その外部ライブラリがリフレクションを使用している 場合にはネイティブイメージにすることができません。 3 どのフレームワークも一長一短があ るとの話でしたが、Quarkusが苦手 としている機能、あるいはマイグレー ションのユースケースに合わないの はなんでしょうか？ Quarkus でもモノリスのアプリケーションを作り、巨大なプロセスとし て動かすことは可能です。しかし、アプリケーションサーバと比べると Quarkusは想定する役割がことなるため巨大なリソースプールを効率 よく管理する機能などは劣ると言えます。この場合、モノリスのアプリ ケーションを複数の小さなプロセスとして動かすことなどで補えます。 17 Copyright 2020 Red Hat K.K.
18. ハッシュタグ #RHdevjp レッドハット株式会社 ソリューションアーキテクト 笹川 博幸 マイクロサービス/サーバーレス 実践入門 Red Hat Developer Webinar Series 18
19. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. • アプリケーションアーキテクチャの変遷 • マイクロサービスの課題を解決するサービスメッシュ • マイクロサービスを可視化する分散トレーシング • サーバーレスアーキテクチャとイベントベースアプリケーション • イベントベースアーキテクチャを実現するメッセージングミドルウェア • イベントベースアーキテクチャを実現するアプリケーションランタイム 本セッションでお話すること 19
20. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 20 https://www.infoq.com/articles/kubernetes-workloads-serverless-era/ アプリケーションアーキテクチャの変遷 20
21. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. メリット • 開発者に要求する運用上の知見を必要最小限にとどめる • 分散トレーシングによるサービスの詳細情報の確認 • ポリシーベースのセキュリティを透過的に有効化 • インテリジェントルーティングから カオスエンジニアリングまで • 強力な可視化とモニタリング機能 OpenShift Service Mesh サービス間通信に最適化した専用ネットワーク層 https://blog.openshift.com/red-hat-openshift-service-mesh-is-now-available-what-you-should-know/ 21
22. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. OpenTracing プロトコル実装 - MicroProfile の仕様にも含まれる • サービス間のコンテキスト情報の伝搬 • サービス間トランザクションのモニタリング • 根本原因の分析 ･ なぜリクエストがタイムアウトしたのか ? ･ なぜサービスxがfail overしたのか? • サービス間の依存関係の分析 ･ 動的なService Discovery ･ リスクの発見と最小化 • パフォーマンス/レイテンシ の最適化 ･ 一番時間のかかっているサービスは ? ･ どこから最適化すべきか判断する情報を提供 Jaegerによる分散トレーシング 22
23. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. Service Microservice Function > 単一の目的 > ステートレス > 独立してスケーリング > 自動化 > 単一のアクション > エフェメラル > 自律的 > 疎結合 サーバーレスアーキテクチャへの進化 f( ) 23
24. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. イベント駆動型マイクロサービス アプリケーション メッセージング ミドルウェア 24
25. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. Red Hat AMQ 全体像 クラウドや IoT に対応した標準技術をベースとした柔軟な エンタープライズメッセージング AMQ Online (Messaging-as-a-Service) - メッセージング機能をセルフサービス化 - OpenShiftコンテナ基盤をベースとし、セルフマネージドと Red Hatマネージドの形態で利用 可能 AMQ Broker - ストア & フォワード - 揮発性 & 持続性 - JMS 2.0フルサポート - 優れたパフォーマンス AMQ Interconnect - 高性能なダイレクトメッセー ジング - 分散メッセージング基盤 AMQ Streams - Apache Kafkaベース - ストリーミングプラット フォーム - 持続性のあるpub/sub - 再送可能ストリーム 標準 プロトコル 対応 多言語対応 クライアント 統合管理機能 メッセージング機能を提供するRed Hat AMQ 25
26. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. Supersonic. Subatomic. Java. 26
27. ハッシュタグ #RHdevjp # 質問 回答 1 マイクロサービスとサーバーレスの使い分け が難しいように感じました。サーバーレスが適 している具体的なユースケースはどんなもの でしょうか? サーバーレスはイベント駆動のアプリケーション、実行に時間のかかる処理等が適して いると思われます。 (例えばIOT等でセンサーからデータを吸い上げたタイミングで時間のかかる分析処理を 動かす、等) マイクロサービスの構成はすぐにレスポンスを返したい等、常時起動しておく必要のある アプリケーションが適していると思われます。 2 Jaeger が Red Hat Runtime に追加されたと のことですが、OpenShift ではない環境でもサ ポートされますか？ 今の所OpenShift上でのサポートに限定されるようです。 3 サーバーレスといえば AWS Lambdaがよく使 われていますが、 Lambdaとの互換性はありま すか? 各ベンダーが独自にサーバーレスを実装してきた為、イベントの定義を統一する Cloud Eventsというプロジェクトが発足されました。 このCloud Eventsの仕様に沿ってアプリケーションを実装していた場合、 基本的には互換性が保たれるはずです。 4 Redhat Service MeshはOSSのISTIO Envoy と何か違いはありますか？ OpenShift Service MeshはIstioにプラスしてJaeger, Kiali, Prometheus, Grafanaとセッ トで提供されます。 これにより、分散トレーシングやメトリックの可視化等がより手軽に行えるようになりま す。 また、Operatorという仕組みを使って運用できる為、インストールや管理等が素の OSSと 比べてより簡単に行えるようになります。 27 Copyright 2020 Red Hat K.K. 第4回質問と回答ダイジェスト
28. ハッシュタグ #RHdevjp レッドハット株式会社 スペシャリストソリューションアーキテクト 杉本 拓 これからのシステム連携を実現する デジタル基盤とアプローチ Red Hat Developer Webinar Series 28
29. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 29 Developer Webinar 第5回のテーマ • カスタマージャーニーとAPI • API活用のベストプラクティス • APIファーストのアプローチ • APIのトレンド • デジタル基盤を実現するRed Hatのミドルウェア製品
30. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 30 カスタマージャーニーを実現するデジタル基盤 顧客接点となる 様々なチャネル バックエンドにある 様々な企業システム 顧客の行動に応じた ネクストアクション メール Fax Web テキスト モバイル 音声 代理店 CMS CRM SAP オンライン 商談の提案 代理店からの 電話 支払い処理 の実施 注文処理と 配送手続き ERP SaaS 顧客の 行動 (イベント) 顧客にとって関連性の高い情報を 顧客が望むチャネルを通じて提供 DB データ収集 API 最適化 自動化
31. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. ”適切なAPIを作る”にはアウトサイドインの考え方が重要であり、 APIをプロダクトとして捉え、デザイン思 考のプロセスを取り入れてAPIを設計していくAPIファーストのアプローチが必要 31 APIファーストのアプローチ フィードバック APIの設計に関す るフィードバック 実装 設計に基づいて APIを実装 APIの プロトタイプ APIのモックを作成 してテスト APIの アイデア創造 どのようなAPIが有 効か？ 問題提起 ユーザのペインは 何か？ 共感 潜在的なユーザと の会話 ユーザから共感を得られる問題を再定義する ユーザからのフィードバックをアイデアに取り込む プロトタイピングの過程で生まれたア イデアをAPIに取り込む フィードバックを通じて問題を再定義する フィードバックを通じてユーザに関する理解がより深まる
32. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 32 相互補完的に使うことが重要 顧客エンゲージメントのデジタル基盤を検討するにあたっては、何か１つの技術要素ですべてが 網羅できる訳ではなく、またある技術要素が別の技術要素を完全に置き換えるものでもないた め、それぞれの長所・短所を把握した上で適材適所で使い分けることが重要
33. ハッシュタグ #RHdevjp Copyright 2020 Red Hat K.K. 33 デジタル基盤を実現するRed Hat製品 OpenShift クラスタ イベントストリーミング API管理 インテグレーション ルールによる最適化 GW GW Kafka 用 ストレージ チャネル SaaS / CRM Web FTP Mobile Partner 他システム SAP DB ERP Other アプリケーション Red Hat 3scale API Mgmt Red Hat Runtimes Red Hat Fuse Red Hat AMQ Red Hat Decision Manager Red Hat Process Automation Manager Red Hat OpenShift Container Storage Red Hatミドルウェア製品 (Runtimes/Integration/Process Automation)
34. ハッシュタグ #RHdevjp # 質問 回答 1 APIを提供する粒度が悩ましいのですが、どの ようなレベル・単位で APIを提供するとよいか、 ベストプラクティスはありますか ? APIの粒度と言った時に、 API（サービス）の実装の粒度の話と APIのインタフェースとして の粒度を分けて考える必要があります。 APIというのはあくまでインタフェースなので、 バックエンドの実装の粒度には縛られず顧客目線でどういった機能が必要なのか、論理 的な単位でAPIファーストのアプローチで設計していくべきであり、 API（サービス）の実装 あるいはマイクロサービスの実装の粒度としては、マイクロサービス単体でデプロイ可能 な単位がマイクロサービスとして適した粒度になります。 2 Microcks は API を使う側のためのテストツー ルでしょうか。 はい、そうです。 MicrocksはAPIドキュメントからモックを作って、モックサーバとして機能 する製品で、APIを使う側はそのモックサーバに対して APIリクエストを行うことができるよ うになるのでテストを行ったり、 APIのプロトタイピングを行うことができるようになります。 ただ、現時点では Microcksはコミュニティプロジェクトであり、 Red Hatからの正式サポー トのある製品とはなっておりません。 3 APIの仕様書をOpenAPIで記述しています が、API Gatewayにインポートすることで APIを 実装しています。 OpenShiftでこのようなAPI仕 様書 (yamlファイル)からAPIのエンドポイントを 作成する製品はありますでしょうか？ Red Hat Integrationにも含まれる3scaleというAPI管理製品にはAPI Gatewayも含まれ ており、3scaleにOpenAPIのドキュメントを取り込んで APIのエンドポイントを API Gatewayに登録し、そのAPIを管理することができるようになります。なお、 3scaleは OpenShift上で動作します。 34 Copyright 2020 Red Hat K.K. 第5回質問と回答ダイジェスト
35. ハッシュタグ #RHdevjp Cloud Nativeなデータ パイプラインの作り方と オープンハイブリッドクラウ ドへの展開 Red Hat K.K. Specialist Solution Architect 小杉 Red Hat Developer Webinar Series 35
36. ハッシュタグ #RHdevjp 36 企業における典型的なデータパイプラインと課題 データの生成 RDBMS データの利用 ETL DWH API • RDBMS の性能向上は基本的にスケールアップ ◦ 性能向上に伴い、コストパフォーマンスが悪化 ◦ スケールアップには上限がある • RDBMS が苦手なワークロードが増加 ◦ IoT 機器の計測データやアプリケーションが発生させるイベント ◦ リレーショナルデータベースでは苦手とする時系列・構造化データ • Schema Evolution が困難 ◦ 書き込み時にスキーマを確定する必要がある - Schema on Write • Command と Query で効率的な格納方式が異なる ◦ セカンダリインデックス作成により、 Command の性能が劣化 ◦ インデックス作成により、ストレージ容量圧迫
37. ハッシュタグ #RHdevjp ステートソーシングからイベントソーシングへ 37 商品 ID 在庫 1 100 2 30 3 50 … … ID 商品名 製造者 ID 1 商品 A … 2 商品 B … 3 商品 C … … … … • 在庫追加機能 • 在庫参照機能 • 在庫引当機能 最新の状態を管理=トランザクションが必須 1. カート作成 2. カートに商品 A を追加 3. カートに商品 B を追加 4. カートから商品 A を削除 イベントソーシング ステートソーシング イベントをすべて保存する イベントストア 現在の状態を表現する データストア イベントリプレイ ドメインイベントを保存、ドメインイベントは不変
38. ハッシュタグ #RHdevjp 巨大な RDBMS を脱却するパターン 38 CQRS CDC Command Query Responsibility Segregation コマンド・クエリ責務分離 Change Data Capture Event Sourcing イベント・ソーシング Data Virtulization データ仮想化
39. ハッシュタグ #RHdevjp CQRS + ES + Data Virtualization + CDC の適用 39 データの生成 RDBMS データの利用 Object Storage API 全文検索エンジン CDC リアルタイム連携 LBMB インメモリキャッシュ Command Service 仮想 DB Command Service Connector Query Service SQL on Hadoop / Spark • 書き込みを RDBMS にし、Integrity を保証 • RDBMS は検索されないため、不要なインデックスは不要 • 用途ごとのデータソースへデータを分離 • レガシー分解用の仮想 DB を作成 • イベントを LBMB に書き込み、イベントは不変 • 仮想 DB を使用して RDBMS 分解の準備
40. ハッシュタグ #RHdevjp # 質問 回答 1 既存システムへのワークロードを分析、再構成するこ とでボトルネックは移動すると思います。従来は RDBMS などベンダーにより保証されていた部分が 縮小すると思うのですが、アーキテクチャ移行に伴う コストとして考慮しなければならないのでしょうか。 考慮する必要があると思います。ボトルネックは移動して例えば LBMB からメッセージを取り出すとこ ろに変わってくると思います。そこをうまく調整しないと LBMB 上にメッセージが滞留してメッセージが 消えるということもあり得るので、取り出す側もスケール可能な仕組みを提供することが必要になって きます。 2 Red Hatからデータ仮想化を行う製品は提供されて いますか? 過去に Red Hat JBoss Data Virtualization を提供していました。データ仮想化の OSS Teiid を Upstream としているのですが現在は マイクロサービスに適した形で提供されており、 Tech Preview 版をお試しいただくことが可能となっています。 3 イベントドリヴンなアーキテクチャを考える上で途中で 処理が失敗した場合はどうしたらいいですか。 SAGA パターンなどを考慮して通常のイベントの処理とは逆にキャンセルのイベントを流すということ をやったり、調整役を用意して途中で処理が失敗したらキャンセルイベントを流せるような仕組みを整 えておく必要があります。 4 登場する技術が非常に増え、今までの RDBMSの技 術だけでなく、とても多くの技術に習熟する必要があ るように感じています。どの要素技術から学習していく のが効率よく仮想化につなげていけるのでしょうか。 Kubernetes、さらにその上で動くマイクロサービスの学習がいいのではないかと思います。マイクロ サービスパターンの書籍には今回ご紹介した CQRS やイベントソーシングパターンも掲載されていま す。 あとは Kafka も一押しです。マイクロサービスを REST の同期通信だけで実現すると障害が連鎖す るため、疎結合化するために Apache Kafka を挟むアーキテクチャをとることもできます。 40 Copyright 2020 Red Hat K.K. 第6回質問と回答ダイジェスト
41. ハッシュタグ #RHdevjp Thank you. 41 Red Hat Developer Webinar Series