JBoss EAPによるクラウドネイティブのススメ

Transcript

1. JBoss EAPによる クラウドネイティブのススメ
2. 伊藤ちひろ (Chihiro Ito) OpenJDK コミッタ Quarkus コントリビュータ 日本Javaユーザグループ 幹事 OpenShift SSA Runtimes担当@ Red Hat 　　: @chiroito 自己紹介 Profile 2
3. 今日伝えたいこと 3 ▸ 修正量はほんの少しでいけます ･ ただし、Java EEの仕様をちゃんと使っていること ▸ サンプルアプリ ･ https://github.com/chiroito/cloud-native-monolith/ JBoss EAPを使って、既存のモノリスをクラウドネイティブ化しよう
4. モノリスを生かす 4 参考資料[1]：Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% (https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90) 参考資料：スタートアップのためのマイクロサービス入門 (https://aws.amazon.com/jp/blogs/startup/techblog-microservices-introduction/) 従来のビジネス側からの要求は モノリスが適している。ビジネス側の 要求は変化が少なくマイクロサービ スへの移行はメリットがない。 マイクロサービスへの移行と比べ、 少ない修正でモノリスのアプリケー ションをクラウドに対応できる。 44.4%の企業がコスト削減を期待。 ITの持続性に対応できている企業 は10%。 クラウドの機能に対応することで、こ れらを実現しやすくなる。 少しの変更でクラウドに対応 コスト削減とリスク低減を実現 オープンシアターで伝えたこと モノリスを維持したままアプリケーションをクラウドの機能に対応させましょう
5. 5 Gartner、オンプレミスに関する最新の展望を発表 (https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20240304) Gartner、2024年に向けて日本企業が押さえておくべきクラウド・コンピューティングのトレンドを発表 (https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20231115-cloud) 従来のオンプレはなくなる Gartnerによると、従来のオンプレを 提供するベンダーや、それを使用す るインテグレータはいなくなる Gartnerによると、今後はクラウドの 能力をオンプレで提供する Newオン プレミスが主流になる。これを使うに は新たなスキルの獲得が必要 AWS は「マイクロサービスが適して いるシステムは限られ、良くできてい るモノリスが一番である」と述べてい る。Amazonはマイクロサービスから モノリスへ移行した。 Newオンプレミスが主流に マイクロサービスの理由はない 理由 クラウドに対応しないシステムは、稼働できる場所と運用してくれる人がいなくなる
6. 6 マイクロサービスにしないモノリスをクラウドに対応しましょう クラウドに対応して、クラウドの能力を活用したモノリスを構築 少しの修正で移行 (後述) サービス モノリス アプリケーション モノリス インフラ 業務 業務 業務 Cloud Native Monolith アプリケーション クラウドネイティブ インフラ※ 業務 業務 業務 ※クラウド or Newオンプレミス
7. 7 みなさんに目指していただきたいこと これらを今実現するのではなく、早めにできるようにする ことが最初のゴール
8. 8 アプリケーションが状態を持つ場合には、その 状態をインメモリな外部記憶装置へ保存する ように修正します。アプリケーションの修正は 不要で設定のみです。 ステートレス 担当者が作業を1つずつするのではなく、 1つの まとまったプロセスとして実行します。また、ロ グなどの情報も自動的に収集されるようにしま す。 運用管理 アプリケーションの接続先を環境変数で変えら れるようにします。コードや設定ファイル上で 直接記載している部分を修正します。 外部変数 コードをSubversionやGitによるリポジトリで管 理し、ビルドツールに依存関係を明記すること でアプリケーションを自動的にリリースできるよ うにします。 コード一元管理 Cloud Native Monolithに必要な作業例 一般的なThe Twelve Factorsを選択可能な4つのカテゴリに分類して適用します
9. 9 実現に必要な作業例
10. 10 ▸ 送受信先の設定をデプロイ時に外から変更できるようにする Cloud Native Monolithに必要な作業例 １ 接続先を全て外部変数にすることで、全ての環境で同一の成果物を使用できる The 12 Factors III.設定 IV.バックエンドサービス VII.ポートバインディング X.開発/本番一致 設定で変更できるホスト名とポート番号 固定化されているホスト名とポート番号 Cloud Native Monolith DB Cloud Native Monolith DB DB Cloud Native Monolith Cloud Native Monolith 本番環境 結合試験環境 総合試験環境 Monolith DB Monolith DB DB Monolith Monolith 本番環境 結合試験環境 総合試験環境 全ての環境で完全に同じアプリケーションとAPサーバが動く 自動化で同じように構築しても、 動いているアプリケーションやAPサーバは全て異なる これまでの環境 これからの環境 TODO: インフラ チーム アプリ チーム 結合試験 総合試験 本番 設定 構築 構築
11. 11 他にも、Eclipse MicroProfile の MicroProfile Config もサポートしている環境ではこれを使用して外部変数化する方法もあります。 JBoss EAP では JBoss EAP XP で MicroProfile Config を使用できます。 JBoss EAPでInitialContextを使うにはnamingサブシステムのドキュメントをごらんください Cloud Native Monolithに必要な作業例 １ 固定されている接続先を外部変数化する修正例 The 12 Factors III.設定 IV.バックエンドサービス VII.ポートバインディング X.開発/本番一致 String url = “http://dokoka.com”; URL url = new URL(url); Context initialContext = new InitialContext(); String url = (String) initialContext.lookup("java:comp/dokoka/url"); or String url = System.getProperty(“url”); <datasource jndi-name="java:/jdbc/db"> <connection-url>dokoka-db.com</connection-url> </datasource> <datasource jndi-name="java:/jdbc/db"> <connection-url>${env.POSTGRES_URL}</connection-url> </datasource> OSの環境変数 POSTGRES_URL から取得 ソースコードの例： 設定ファイルの例： Java EE/Jakarta EEの仕組みを使い、 アプリケーションサーバから取得 OSの環境変数を取得
12. 12 ▸ 整合性を保つため、正常時は全て反映、障害時は全て元に戻す ▸ アプリケーションが状態を HTTPセッションとして持たなくする Cloud Native Monolithに必要な作業例 ２ アプリケーションが状態を持たないことで、耐障害性に優れ、自由にスケールできるようになる The 12 Factors VI. プロセス VIII. 並行性 IX. 廃棄容易性 Cloud Native Monolith Cloud Native Monolith HTTPセッションスト ア モノリス モノリス HTTP セッション HTTP セッション HTTP セッション HTTP セッション HTTP セッション 移行 モノリス DB トランザクション begin commit rollback トランザクションによる整合性担保 HTTPセッションを外部化 TODO:
13. 13 Cloud Native Monolithに必要な作業例 ２ 処理の成功時には全て反映し、失敗時は全て元に戻します The 12 Factors VI. プロセス VIII. 並行性 IX. 廃棄容易性 CDIの例 public class NanikaBean2{ @Transactional public XXX someMethod(){} } CDI の @Transactional JTA の Transaction EJBのトランザクション Jakarta EEの仕様（修正不要） データ整合性を保ちましょう • 一般的にはトランザクションを使用 ◦ begin ◦ commit ◦ rollback
14. 14 上記はタグに含まれるいくつかの属性を省略しています。 HTTPセッションは Red Hat Data Grid に格納できます。 Red Hat Data Grid の構築と、アプリケーションサーバにほんの少しの設定だけが必要で、アプリケーションの変更は不要です。 Cloud Native Monolithに必要な作業例 ２ HTTPセッションを外部に持ちましょう The 12 Factors VI. プロセス VIII. 並行性 IX. 廃棄容易性 <?xml version="1.0" encoding="UTF-8"?> <web-app> <distributable/> </web-app> web.xml
15. 15 ▸ Maven / Docker / Ansible / Teraform などビルドツールを使用する ▸ 依存関係など必要な情報をコードで定義する Cloud Native Monolithに必要な作業例 ３ 全ての情報をコードとして一元管理することで、全ての環境で同一のリリースを使用できる The 12 Factors I. コードベース II. 依存関係 V. ビルド、リリース、実行 ソースコード リポジトリ CI/CD 手動ビルド WAR / EAR コンテナ 仮想マシン テスト環境 本番環境 デプロイ 成果物 TODO:
16. 16 成果物として仮想マシンを作成できますが、ここでは省略しています。 WildFly Docker image (https://github.com/jboss-dockerfiles/wildfly) Cloud Native Monolithに必要な作業例 ３ 成果物によってツールは異なるが、簡単な定義のみで対応できる The 12 Factors I. コードベース II. 依存関係 V. ビルド、リリース、実行 FROM quay.io/wildfly/wildfly ADD nanika-app.war /opt/jboss/wildfly/standalone/deployments/ コンテナイメージを作成 <project> <groupId>org.dokoka</groupId> <artifactId>nanika-app</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>pom</packaging> <properties> <root.dir>${project.basedir}</root.dir> </properties> <dependencies> <dependency> <groupId>jakarta.servlet</groupId> <artifactId>jakarta.servlet-api</artifactId> <scope>provided</scope> </dependency> </dependencies> </project> WARを作成
17. 17 成果物として仮想マシンを作成できますが、ここでは省略しています。 Cloud Native Monolithに必要な作業例 ３ 成果物によってツールは異なるが、簡単なコマンドのみで対応できる The 12 Factors I. コードベース II. 依存関係 V. ビルド、リリース、実行 mvn package WARを作成 WAR docker build --tag=nanika-app . コンテナイメージを作成 コンテナ mvn wildfly:deploy docker run -it nanika-app 成果物を作成 成果物 デプロイ
18. 18 ▸ 各チームは自身を介せず他のチームが目的を達成できるようにする ▸ 開発・構築・運用のフローから人を排除する Cloud Native Monolithに必要な作業例 ４ 運用で必要な作業をツール化またはサービス化することで目的を達成する時間を短縮 The 12 Factors XI. ログ XII. 管理プロセス ログUI アプリチームがインフラチームにロ グの収集を依頼 インフラチームがログを収集する ツールをアプリチームに提供 インフラチームがログを可視化する UI をアプリチームに提供 アプリチームがログを参照したい場合の例： TODO: PC APサーバ ログ インフラ チーム アプリ チーム PC APサーバ ログ インフラ チーム アプリ チーム 収集 ツール 提供 使用 依頼 APサーバ ログ 自動 格納 ログ収集場所 アプリ チーム 参照 これまで これから
19. Cloud Native Monolithに必要な作業例 ４ 19 アプリケーションに定義を書くことで自律的に運用対象に含められ、構築負荷を低減 主な運用作業 ▸ アプリのデプロイ ▸ ログ・メトリクスの収集 ▸ 死活監視 ▸ 縮退運転からの回復 ▸ スケールアウト これまではインフラ担当者が 全ての運用の設定や監視を実施 Cloud Native Monolith アプリケーション ログ収集 死活監視 スケール アウト 定義 メトリクス 収集 アプリケーションのデプロイ時に監視に必要な場所 を定義し、環境が自動的にそれを監視 定義 定義 インフラ チーム Monolith アプリケーション ログ収集 死活監視 メトリクス 収集 設定 監視 設定 The 12 Factors XI. ログ XII. 管理プロセス これまでの環境 これからの環境
20. Cloud Native Monolithに必要な作業例 ４ 20 アプリケーションに定義を書くことで自律的に運用対象に含められ、構築負荷を低減 上記はEclipse MicroProfile Healthと同Metricsを活用する例です。ランタイムによって独自の方法を提供していることもあります。 The 12 Factors XI. ログ XII. 管理プロセス <dependency> <groupId>org.eclipse.microprofile.metrics</groupId> <artifactId>microprofile-metrics-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> メトリクスの収集 <dependency> <groupId>org.eclipse.microprofile.health</groupId> <artifactId>microprofile-health-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> 死活監視 @Liveness @ApplicationScoped public class SimpleHealthCheck implements HealthCheck { @Override public HealthCheckResponse call() { return HealthCheckResponse.named("test check").up().build(); } } @Counted(name = "requestCount")
21. 21 準備ができあがりました
22. Red Hat製品群を含む構成例 22 他社ミドルウェアが RHEL, Podman および OpenShift をサポートしているかどうかは、そのミドルウェアの提供ベンダーへご確認下さい Cloud Native Monolith をさまざまな環境で稼働できる アプリケーション Red Hatミドルウェア (JBoss EAP) 他社ミドルウェア (APサーバ) Red Hatミドルウェア + 他社ミドルウェア Red Hatミドルウェア + 他社ミドルウェア JBoss EAP RHEL RHEL + Podman OpenShift OpenShift Azure App Services オンプレ IaaS PaaS
23. 23 JBoss Enterprise Application Platform Jakarta EE (旧Java EE)に準拠したクラウドネイティブなアプリケーションサーバ ▪ Web管理コンソール ▸ オープンソースのJavaアプリケーションサーバー ･ Jakarta EE仕様に準拠 ･ 13年の長期サポート（7.x系のELS2まで含めた場合） ▸クラウドネイティブにも対応 ･ ２秒程度の高速起動(スケールが必要な環境に最適) ･ 低メモリ(リソース効率が良い) ▸ 価格体系 ･ ライセンス料金不要な低コストなサブスクリプションモデル
24. Red Hat OpenShift Container Platform 24 Red Hat が提供するKubernetesベースの New オンプレミスプラットフォーム Virtual Private cloud Bare metal Public cloud Edge エンタープライズに求められる機能を Kubernetesに付随し、サポートすることで、ビジネス価値に直結する機能を提供しています。 アプリケーション開 発の効率化に重きを置く点 が、インフラ運用の効率化に取り組むことを目的とした Kubernetes単体利用と大きく異なる点です。 ミドルウェア の管理 クラスタの ロギングや監視 コンテナの セキュリティ クラスタ アップグレード コンテナの動的 ビルド/デプロイ
25. 25 JBoss EAP on OpenShift JBoss EAP on OpenShift JBoss EAP アプリケーションを動かすためのOpenShiftの主な特徴 クラウドネイティブ開発への道 - クラウドネイティブ開発技術を導入 例 MicroProfile, 12 factor principles 複数回のビルドとデプロイの選択肢 - ➢ テンプレート ➢ Helm chart ➢ JBoss EAP Operator ➢ カスタム 自動スケール - リソース使用量に基づく OpenShiftに組み込まれた自動スケーリング を活用する 安全な停止 - 処理中の処理やトランザクショ ンはシャットダウン処理の前に完了するか ロールバックされる* クラスタリングをサポート - クラスタに参加する他 のJBoss EAPを見つけるためにKubernetesのAPI を活用するようにJBoss EAPのJGroupsを設定 HTTPS 設定 - 実行時にテンプレートやhelm チャートによって自動化されたHTTPSの設定 * この機能はJBoss EAP Operatorによって提供される
26. Red Hat Data Grid 26 データを冗長化しつつ負荷を均等に分散し、自律的にデータを制御するKVSのキャッシュ製品 300TPS Data Grid アプリ DBMS アプリ DBMS 3000TPS以上 セッションを格納 Data Grid Data Grid Webアプリ APサーバ • JBoss EAP
 • WAS Libetyなど
 ▸ 処理の高速化 アプリ→DBMS間の性能ネックをData Gridで 性能を10倍以上向上 国内外の豊富な利用実績(公開可能範囲のみ記載) ･ 楽天銀行様、松井証券様など多数 ･ 海外投資銀行(Oracle Coherenceからの移行)など多数 ▸ HTTPセッションを外部化 WebアプリのHTTPセッションを外部化して、ステートレス 化。またHTTPセッションは冗長化され、システムの可用性を 確保
27. 27 APサーバ固有の実装を検出 アプリケーションはAPサーバ固有の機能を使用しているこ とがあります。それらの機能は標準 APIではないため、他の APサーバでは動きません。Migration Toolkitは、APサー バ固有の機能を検知し、移行に必要な対応をサポートしま す Java EE から Jakarta EE への移行 過去の標準仕様であるJava EE から、最新の標準仕様で あるJakarta EEへの移行をサポートします。クリックだけで 一括移行できることもあります。 Migration Toolkit アプリケーションサーバの独自機能や古い仕様などを抽出し、アプリケーションの移行をサポート ▪ 移行ツールの解析結果例
28. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you