Developer_Webinar_Series_2020_Digest

Slide 1

Slide 1 text

ハッシュタグ #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

Slide 17

Slide 17 text

ハッシュタグ #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.

Slide 27

Slide 27 text

ハッシュタグ #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回質問と回答ダイジェスト

Slide 34

Slide 34 text

ハッシュタグ #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回質問と回答ダイジェスト

Slide 40

Slide 40 text

ハッシュタグ #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回質問と回答ダイジェスト

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text