Tweet
Tweet

Slide 1

Slide 1 text

Red Hat Application Foundationsから学ぶ アーキテクチャー入門 レッドハット株式会社 2022.11.27 スペシャリストソリューションアーキテクト 瀬戸 智 1 JJUG CCC 2022 Fall 16:00～ Track:D #jjug_ccc_D

Slide 2

Slide 2 text

2 2022年2月からRed Hat所属 スペシャリストソリューションアーキテクト JBoss EAP、Quarkusなどを担当 日本Javaユーザーグループ幹事 自己紹介：瀬戸智

Slide 3

Slide 3 text

本題に入る前にお知らせ 3

Slide 4

Slide 4 text

4 ▸ 2023年前半にリリース ▸ 2022年中にベータ版リリース ▸ ベースになるのはWildFly 27 ※すべては予定であり予告なく変更になる可能性があります。 The road to JBoss EAP 8 https://developers.redhat.com/articles/2022/06/24/road-jboss-eap-8 https://rheb.hatenablog.com/entry/road-jboss-eap-8 (日本語翻訳) JBoss EAP 8 Coming Soon! (Jakarta EE 10対応)

Slide 5

Slide 5 text

5 https://www.wildfly.org/news/2022/09/29/WildFly26-Beta-Released/ https://www.wildfly.org/downloads/ Java SE 11、Java SE 17で実行可能 WildFly 27 Now Available! (Jakarta EE 10対応)

Slide 6

Slide 6 text

6 ▸ MicroProfile 5.0(Jakarta EE 9API使用)から依存ライブラリのパッケージ名がjavaxから jakartaへ変更されていたため対応が保留されていた。 ▸ Jakarta EE 10のリリースに伴い対応が行われている。 ▸ 次はMicroProfile 6(Jakarta EE 10ベース)対応のもの ▸ 詳しくは以下の記事を。 https://quarkus.io/blog/road-to-quarkus-3/ Quarkus Coming Soon! (MicroProfile 6対応)

Slide 7

Slide 7 text

7 参考情報(OpenShift) OpenShiftのサブスクリプション＆サポート契約にはQuarkusのサポートが含まれます。

Slide 8

Slide 8 text

ここから本題 8

Slide 9

Slide 9 text

9 E-Wordsより https://e-words.jp/w/%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3.html アーキテクチャーとは

Slide 10

Slide 10 text

10 ▸ 銀の弾丸はありません。 ▸ 特定の場合に特に有効というのはあります。 ▸ 今回のセッションでは良い場所、悪い場所両方とも記載するように心がけています。 ･ 悪い場所があるから使わないほうが良いとかではないよ！ ▸ すべてはトータルでのメリット・デメリットで判断してください。 アーキテクチャーの選択について

Slide 11

Slide 11 text

11 ▸ モノリスからマイクロサービスへ ▸ Red Hat Application Foundationsとは ▸ アプリケーションの分割とトランザクション ▸ 多くのサーバーで整合性を担保していく ▸ アプリケーションをこれ以上大きくしないようにする ▸ 急なアクセス量の変化(オートスケーリング)に対応する ▸ アプリケーションの開発速度を加速する 目次

Slide 12

Slide 12 text

モノリスから マイクロサービスへ 12

Slide 13

Slide 13 text

13 全部を一台に乗せるモノリスから小さなマイクロサービスへ 拡張や需要スパイクに 備えて過剰気味に確保 されたサーバーリソー ス 最初からあるアプリ群 後乗せしたアプリ群 サーバーと同サイズのMW 業務・機能ごとに アプリを分割 ワークロードに応じて 個別スケール アプリは追加される

Slide 14

Slide 14 text

14 ▸ モノリスからマイクロサービスへ ▸ Red Hat Application Foundationsとは ▸ アプリケーションの分割とトランザクション ▸ 多くのサーバーで整合性を担保していく ▸ アプリケーションをこれ以上大きくしないようにする ▸ 急なアクセス量の変化(オートスケーリング)に対応する ▸ アプリケーションの開発速度を加速する 目次

Slide 15

Slide 15 text

Red Hat Application Foundationsとは 15

Slide 16

Slide 16 text

16 https://www.redhat.com/en/resources/application-foundations-datasheet EAPとRed Hat Application Foundationsの関係 含まれないもの: ● Fuse 6 / AMQ 6 / Vert.X / PAM / DM ● All Managed Application Services API管理 データ変換 サービスオーケストレーション イベントバス データストリーミング シングルサインオン Javaアプリケーションフレーム ワーク インメモリ分散データストア Migration Toolkit for Applications ● AMQ Streams ● AMQ Broker ● Debezium Change Data Capture ● Service Registry ● Camel 3 (CEQ, CK, CSB) ● Fuse 7 ● 3scale API Management ● Node.js ● Red Hat JBoss EAP ● Red Hat build of Quarkus ● Spring Boot ● Red Hat build of OpenJDK ● Red Hat JBoss Web Server ● Red Hat Data Grid ● Red Hat Single Sign On(keyCloak) ● Migration Toolkit for Applications

Slide 17

Slide 17 text

17 ▸ Application FoundationsにはJBoss EAPが含まれておりJakarta EEのユースケース に完全対応 ▸ Application Foundationsには多数の製品が含まれ、Jakarta EEでカバーできない領域を MicroProfileに準拠したQuarkusや他の特化したミドルウェアでカバー可能 ▸ JBoss EAPはJakarta EE仕様に準拠しておりポータビリティがあるのは当然だが、 それ以外のミドルウェアについても100%OSSなので、ロックインの心配はない Application Foundationsを選択する理由

Slide 18

Slide 18 text

18 ▸ モノリスからマイクロサービスへ ▸ Red Hat Application Foundationsとは ▸ アプリケーションの分割とトランザクション ▸ 多くのサーバーで整合性を担保していく ▸ アプリケーションをこれ以上大きくしないようにする ▸ 急なアクセス量の変化(オートスケーリング)に対応する ▸ アプリケーションの開発速度を加速する 目次

Slide 19

Slide 19 text

アプリケーションの分割と トランザクション 19

Slide 20

Slide 20 text

20 ▸ コンピューターにおける一処理の単位。 ▸ ここからここまでの処理に成功したか、失敗したか。 ▸ 成功だったらコミット(処理の確定)、失敗だったらロールバック(処理の切り戻し)。 ▸ いわゆるACID特性が保たれている。 ▸ 複数サーバーにまたがってトランザクションを担保したい場合は特別な考慮が必要。 トランザクションとは

Slide 21

Slide 21 text

アプリケーションの分割 クライアント フロントエンド サーバー バックエンド サーバー(+ DB) この中でトランザクション を担保したい。

Slide 22

Slide 22 text

AMQ Broker(JMS、ActiveMQ Artemis) イベント駆動型アーキテクチャ 22 ▸ フル機能のメッセージ指向ミドルウェアのブローカー ･ ピュアJavaで高性能のメッセージブローカー ･ 柔軟な永続化方式: 高性能なジャーナル or JDBC ･ 高可用性: シェアードSAN or シェアードナッシング レプリケー ション ･ 柔軟なクラスタリング ▸ 様々なキューイングのオプション、メッセージの永続化、管理 方式 ▸ 複数のプロトコルとクライアント言語をサポート ･ AMQP 1.0, MQTT, STOMP, OpenWire, HornetQ ･ Java JMS, C++, .NET, Python, Javascript, NodeJS Clients Source Artemis

Slide 23

Slide 23 text

23 ▸ 複数のサーバー間でトランザクションを担保するための仕組み。 2フェーズコミット(2相コミット)

Slide 24

Slide 24 text

24 2フェーズコミット(コミット時) フロント バック1 バック2 複数のサーバーへのデータの書 き込みと、書き込みが正しくでき たのかの確認を行う (フェーズ1) フェーズ1のすべてのサーバーの 応答を待ってからコミットを行う。 (フェーズ2)

Slide 25

Slide 25 text

25 2フェーズコミット(ロールバック時) フロント バック1 バック2 一つでもエラーになった場合は他 のサーバーも含めてすべてロー ルバックを行う。 (フェーズ1)

Slide 26

Slide 26 text

26 2フェーズコミット(うまくいかない例) フロント バック1 バック2 コミット時に一つのサーバーでエ ラーになった場合はどうすればい いのか？(フェーズ2) 一つのサーバーからだけ応答が 返ってこない場合にどうすればい いのか？(フェーズ1,2)

Slide 27

Slide 27 text

27 2フェーズコミット(数が増えた場合) フロント バック1 バック2 今は2台だけど台数が増えてきた 場合、どこまでこの仕組みは耐え れるのか？

Slide 28

Slide 28 text

28 ▸ 多数のサーバー間でトランザクションを担保する仕組みがあるが、よく知られたいく つかのケースでうまく動かない。 ▸ それを認識したうえで、どうしてもトランザクションを担保したい場合はAMQ Broker(JMS、ActiveMQ Artemis)を使用することで、実現することができる。 ここまでのまとめ

Slide 29

Slide 29 text

29 ▸ モノリスからマイクロサービスへ ▸ Red Hat Application Foundationsとは ▸ アプリケーションの分割とトランザクション ▸ 多くのサーバーで整合性を担保していく ▸ アプリケーションをこれ以上大きくしないようにする ▸ 急なアクセス量の変化(オートスケーリング)に対応する ▸ アプリケーションの開発速度を加速する 目次

Slide 30

Slide 30 text

多くのサーバーで 整合性を担保していく 30

Slide 31

Slide 31 text

31 ▸ AMQ Broker(JMS、ActiveMQ Artemis)を使用することで複数サーバー間でトランザク ションの担保ができるが、サーバーが多くなると無理が出てくる。 ▸ トランザクションを使わずに、処理が正しく行われていたら結果が正しくなる状態(結 果整合性)を目指すことで、多くのサーバーがある場合でも無理なくデータの整合性を 担保することができる。 整合性の担保

Slide 32

Slide 32 text

AMQ Streams(Apache Kafka) イベント駆動型アーキテクチャ 32 Source Apache Kafkaをベースとしたエンタープラ イズデータストリーミングプラットフォー ム

Slide 33

Slide 33 text

33 Apache Kafka ● 2010年にLinkedInで開発され、2011年に オープンソース化されたストリーミング データのための分散システム ● 長期間キューをためておくことを前提と したアーキテクチャ ● 非常に高いスループットと低レイテンシ ーで大量データを処理 ● 容易に水平スケール ● クラスタリングにより高い耐障害性 ● 大量のコンシューマも処理可能 ● データはjsonでやり取りをする

Slide 34

Slide 34 text

34 LinkedIn の開発者がApache Kafka を設計したのはなぜか？ ▸ リアルタイムログのような高いボリュームのイベントストリームをサポートするための ハイスループットを実現したい ▸ オフラインシステムからの定期的なデータロードを可能とする大容量バックログを取り 扱いたい ▸ 伝統的なメッセージングのユースケースを取り扱うために低遅延である必要がある Apache Kafka

Slide 35

Slide 35 text

Kafkaを使用したデータ連携 クライアント フロントエンド サーバー バックエンド サーバー(+ DB) フロントエンドサーバーは kafkaにキューとして貯める バックエンドサーバーはkafka を参照して処理をする。

Slide 36

Slide 36 text

36 ▸ トランザクション処理を使った整合性は強整合性とも呼ばれ、すべての状態で必ず整 合性が取れている状態が保証される。 ▸ Kafkaを利用した結果整合性は短時間だがデータの整合性が取れていない時間が発生す る。が、多くの場合はこれで十分に期待通りの動作をする。 ▸ 多くのウェブアプリでは一覧画面の表示はリアルタイムではデータベースと同期 がとれていないはずだが、少し昔の情報を参照しても特に何も感じていない。 トランザクション処理から結果整合性へ

Slide 37

Slide 37 text

37 ▸ データを失わないように作ると最低一回の処理は行えるようになるが、二回以上の処 理が行われてしまうことがある。 ▸ 同じデータが何回処理されても同じ結果になるように作る必要がある。(冪等性) ▸ バックエンドサーバーでキューを取り出した後にバリデーションエラーが発生しても ロールバックが行えないため、フロントエンドサーバー側で十分にバリデーションを 行う必要がある。 ▸ バックエンドサーバーでロールバック用のデータを作ることもできるが、ロール バック処理の自前での実装は大変。 AMQ Streams(Apache Kafka)を使う上での注意

Slide 38

Slide 38 text

38 ▸ 多数のサーバー間でトランザクション制御を行うのは難しいので、その場合は結果整 合性を取るようにする。 ▸ その場合に使用できるのがAMQ Streams(Kafka)。 ▸ 使う場合はトランザクションがないことによるいくつかの実装上の注意が出てくる。 ここまでのまとめ

Slide 39

Slide 39 text

39 ▸ モノリスからマイクロサービスへ ▸ Red Hat Application Foundationsとは ▸ アプリケーションの分割とトランザクション ▸ 多くのサーバーで整合性を担保していく ▸ アプリケーションをこれ以上大きくしないようにする ▸ 急なアクセス量の変化(オートスケーリング)に対応する ▸ アプリケーションの開発速度を加速する 目次

Slide 40

Slide 40 text

アプリケーションをこれ以上 大きくしないようにする 40

Slide 41

Slide 41 text

41 アプリケーションを分割するのにも時間がかかる 移行に数か月～数年 その間は2重メンテ 最初からあるアプリ群 後乗せしたアプリ群 サーバーと同サイズのMW 業務・機能ごとに アプリを分割 ワークロードに応じて 個別スケール アプリは追加される 新機能の追加を両方に

Slide 42

Slide 42 text

42 https://microprofile.io/ ▸ データベースを監視し、データの変更点をキャプチャする ▸ トランザクションログをベース ▸ スナップショットの取得, フィルタリング機能 など ▸ オープンソース, 非常に活発なコミュニティ Debezium

Slide 43

Slide 43 text

43 Debeziumによる チェンジデータキャプチャ アーキテクチャ データソースをモニタリングして 行単位でその変更をキャプチャ AMQ Streams Kafkaに取り込まれたデータを参照

Slide 44

Slide 44 text

Debeziumコネクタ 44 Source ● General Availability ○ MySQL ○ Postgres ○ MongoDB ○ SQL Server ○ DB2 (Linux only) ○ Oracle (LogMinerを使用) Application Foundationsでサポートしているデータベース ※Upstream版では他のデータベースへのコネクタも提供されています。 https://debezium.io/releases/1.9/

Slide 45

Slide 45 text

Using Change Data Capture for Stack Modernization: Demo Debeziumで全文検索を追加 既存システムを 小売店の在庫や売上を 管理するための レガシーアプリケーション データの保持のために使用 データベース更新イベントを キャプチャして公開します ● kafka トピックの管理 ● メッセージの受信と保存 ● コンシューマーがイベントの 読出しをできるようにする 製品データの更新分を、elasticsearch の インデックスに追加します データをインデックス化し、 全文検索の機能を強化します REST APIを通して 製品の検索を実施します 既存システムの検索機能を強化 リアルタイムで情報を集計し、常に最新の情報を検索することが可能に 新規で作った場所は旧アプリとは 別管理とすることができる。

Slide 46

Slide 46 text

46 ▸ テーブルを直接インターフェースとして外部に公開することになるので公開後のテー ブルの変更時に影響が出る。 ▸ なんでもかんでも公開すればよいというものではない。 ▸ ただし、データ連携のフォーマットはjson形式で一般的なものなので、 Debeziumから剥がすことは簡単に行える。 ▸ 有効化するときにDBの設定が必要になる場合がある。 Debeziumを使う上での注意

Slide 47

Slide 47 text

47 ▸ Debeziumを使うことで既存のアプリケーションに手を加えずに新しいアプリケーショ ンへデータ連携を行える。 ▸ 新旧システムの並行開発をしているときに特に有用。 ▸ ただし、データベースのテーブルレイアウトを外部に参照させてしまうことになるの で注意が必要。 ここまでのまとめ

Slide 48

Slide 48 text

48 ▸ モノリスからマイクロサービスへ ▸ Red Hat Application Foundationsとは ▸ アプリケーションの分割とトランザクション ▸ 多くのサーバーで整合性を担保していく ▸ アプリケーションをこれ以上大きくしないようにする ▸ 急なアクセス量の変化(オートスケーリング)に対応する ▸ アプリケーションの開発速度を加速する 目次

Slide 49

Slide 49 text

急なアクセス量の変化(オート スケーリング)に対応する 49

Slide 50

Slide 50 text

従量課金では最小限のサーバーにしたほうが都合が良い クライアント ロードバランサー サーバー

Slide 51

Slide 51 text

51 ▸ 即座にサーバーが起動すると急激なリクエスト数の増加にも対応ができる。 ▸ サーバーの起動に時間がかかる場合、事前にリクエスト数の増加を予測してサーバー を起動させておく必要がある。 サーバーが増える＝サーバーが起動する

Slide 52

Slide 52 text

52 ▸ 旧来のJava EEサーバーは起動が遅いと言われがちだが、JBoss EAPの起動は早い。 ▸ デフォルトだと数秒～十秒程度で起動する。 ▸ Webサーバーに必要な機能のみに限定すればもっと早い。 JBoss EAPの起動は早い

Slide 53

Slide 53 text

53 ▸ アプリケーションを小さく作る。 ▸ 読み込むものが少なければそれだけ早くなる。 ▸ アノテーションを使わない、読み込まない設定にする。 ･ 起動時にすべてのクラスを舐める必要が出てくるのでその分遅くなる。 ･ もともとJavaは遅延クラスロードの機能を備えている。 ▸ 過剰なリソースの確保を起動時に行わない。 ･ DB接続コネクションプールとか。 Java EE(Jakarta EE)サーバーの起動を早くする

Slide 54

Slide 54 text

54 ▸ デフォルトで1秒～2秒程度。 ▸ 十秒程度が待てない場合はこちらを使用する。 ▸ QuarkusはJavaでは主流な動的DIではなく、静的DI(コンパイル時DI)を行っているため 起動時にすべてのクラスを舐める必要がない。 Quarkusの起動はもっと早い

Slide 55

Slide 55 text

55 https://quarkus.io/ ▸ GraalVMはJavaをネイティブコンパイルする。 ▸ デフォルトで数十ミリ秒。 ▸ メモリ使用量も低減。 Quarkus+GraalVMの起動はもっと早い

Slide 56

Slide 56 text

56 ▸ QuarkusはGraalVMでのコンパイルを前提に設計されているため、特別な設定はほぼ不 要。(Windowsでも、Macでも、Linuxでも) ▸ GraalVMをインストールして、pom.xmlにプロパティを追加するだけ。 https://ja.quarkus.io/guides/building-native-image GraalVMでのコンパイルの仕方

Slide 57

Slide 57 text

57 ▸ Quarkusはコンパイル時にDIを行うため、コンパイルの時間が多少延びる。 ▸ ただし、アプリケーションが巨大でなければ問題にはならない程度。 ▸ GraalVMはコンパイル時に多大な時間がかかる。 ･ 数分以上。 ▸ GraalVMにはよく知られたいくつかの制限がある。 https://www.graalvm.org/22.0/reference-manual/native-image/Limitations/ Quarkus、GraalVMを使う上での注意

Slide 58

Slide 58 text

58 ▸ 他のサーバーにセッション情報を共有、コピー(セッションレプリケーション)できる ようにアプリケーションを作っておくと負荷分散がやりやすい。 ▸ JBoss EAPはInfinispan(インメモリデータグリッド)を内蔵しており、セッション レプリケーションを単独で行える。 ▸ セッション共有用のサーバーを別で作る場合も(Red Hat DataGrid) ▸ そもそもセッションを使わないようにする場合もある。 ･ Quarkusはデフォルトではセッションを使えないようになっている。 (参考)セッションレプリケーション

Slide 59

Slide 59 text

59 ▸ オートスケーリングのためにはサーバーの起動は早い方が良い。 ▸ JBoss EAPは一般的なJava EEサーバーよりも起動が早い。 ▸ Quarkusはもっと起動が早いが、コンパイルが多少遅くなる。 ▸ GraalVMはもっと起動が早いが、コンパイルがかなり遅くなる。 ここまでのまとめ

Slide 60

Slide 60 text

60 ▸ モノリスからマイクロサービスへ ▸ Red Hat Application Foundationsとは ▸ アプリケーションの分割とトランザクション ▸ 多くのサーバーで整合性を担保していく ▸ アプリケーションをこれ以上大きくしないようにする ▸ 急なアクセス量の変化(オートスケーリング)に対応する ▸ アプリケーションの開発速度を加速する 目次

Slide 61

Slide 61 text

アプリケーションの開発速度を 加速する 61

Slide 62

Slide 62 text

62 ソフトウェア開発データ白書 2018-2019 https://www.ipa.go.jp/ikc/publish/whitepaper_dl.html システム開発の工程にかかる時間 テストの比率が増えている

Slide 63

Slide 63 text

63 改良開発時のテスト工数の増加 ▸ 新規開発時はすべての新規開発した機能だけをテストしていればよい。 ▸ 改良開発時は修正したところに加えて既存機能のテストも必要になる。 ･ ＝回帰テスト(リグレッションテスト)

Slide 64

Slide 64 text

64 テストの時間を減らす ▸ 手動で行っているとどうしても時間がかかる ･ テスト作業で手作業が必要な量を減らしていく。

Slide 65

Slide 65 text

65 テストの時間を減らす-テスト項目の標準化 ▸ テストケースの作成の省力化をするために、どの画面でも行うテストを共通項目としてくくりだ し、一元管理をする。 ▸ どの工程でどういった確認をするべき項目の整備＝テスト観点の整備。

Slide 66

Slide 66 text

66 テストの時間を減らす-静的解析 ▸ findbug、pmd等の静的解析ツールを使う。 ▸ 動かすまでもなくソースコードを見ればバグってるのがわかるよねというのを見つけてくれるツ ール。 ･ Stringを==で比較しているとか。 ･ テスト工数を半分に削減できたプロジェクトもあり。 ▸ フレームワークの特性に合わせてプロジェクト内でよくある不具合を自分たちでルールとして追 加することも可能。 ▸ アプリケーションの移行時に静的解析をして非互換をチェックするツールがRed Hat Application Foundations に含まれるMigration Toolkit for Applications。

Slide 67

Slide 67 text

67 テストの時間を減らす-テストの自動化 ▸ JUnit等を使ってテストを自動化する。 ･ JBoss EAP(Java EE/Jakarta EEサーバー)に使えるJUnit用のサポートツールがArquillian (Red Hat製のOSS) 。 ･ QuarkusにはJUnit用のサポートツールが内蔵されている。 ▸ Red HatのOpenShiftはKubernetesにCI/CDツール(Tekton、Jenkins)のサポートが追加されてい る。 ▸ テストの自動化にかける工数はそこそこかかるので数回しか使わないものであれば作らないほう が良い。

Slide 68

Slide 68 text

68 (補足)テストの自動化はやっておいた方が良い。 ▸ 業務側の修正だけではなく、使用しているライブラリ、ミドルウェア、さらにOSのいたるとこ ろに不具合、特にセキュリティバグが含まれている可能性があり、また、見つかった時に即座に 適用をする必要がある場合がある。 ･ 特にインターネットに公開されているサーバーの場合、外部からのアタックが当然のように される。 ･ 例としてはLog4shell、Spring4shell、Heartbleed等たくさん・・・・ ▸ WAF(Web Application Firewall)等を使うことで危険性を大幅に削減することはできる。 ･ WAFの防護は完全ではないということは認識する必要がある。

Slide 69

Slide 69 text

69 テストの時間を減らす-テスト環境構築の自動化 ▸ クラウドのAPIを使用して自動でテスト環境を構築する。 ･ オンプレの場合でもOpenShift(Kubernetes)等の仮想化ツールを入れることでAPIを使って のテスト環境の構築が可能に。 ▸ Ansible(Red Hat製オートメーション製品)でネットワーク、サーバー等の操作のテンプレートを 作成し、何回でも作り直せるようにする。 ▸ Podman(Red Hat製のDocker互換ソフトウェア)でサーバー構成のテンプレートを作成して Ansibleと組み合わせてより迅速に構築を行う。

Slide 70

Slide 70 text

70 ▸ 改良開発時は回帰テストのぶんだけテスト工数がかかるようになる。 ▸ テスト工数を減らすためには手作業を減らす必要がある。 ここまでのまとめ

Slide 71

Slide 71 text

71 ▸ 今回紹介しなかったよくある課題(ex. シングルサインオン)のためのソリューション (ex. Red Hat SSO)が他にいくつもあります。 ▸ ぜひメリット・デメリットを比較してよいシステムを作ってください。 まとめのまとめ

Slide 72

Slide 72 text

linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Red Hat is the world’s leading provider of enterprise open source software solutions. Award- winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you 72