Java によるクラウドネイティブ の実現に向けて
- 1. Java によるクラウドネイティブ の実現に向けて Shigeru Tatsuta 2019/11/23 JJUG CCC 2019 Fall
- 2. 対象となる方 ● ソフトバンクにおける Java の開発に興味のある方 ● アプリケーションサーバから、クラウドネイティブへの移行 を検討している方 ● JVM のチューニングに興味のある方 ※ Kubernetes、Quarkus の内容について興味のある方は、 14:30 - 15:15 Room M の弊社のセッションの方もご参加ください。
- 3. 自己紹介 竜田 茂 (たつた しげる) ソフトバンク株式会社 テクノロジーユニット IT＆ネットワーク統括 IT 本部 前職の日本オラクルでは Java アプリケーションサーバ製品の技術サポートを 担当。 2013 年よりソフトバンクに参画し、Java ミドルウェア製品の全社導入支援、お よびリアルタイム処理基盤 Chronos-Core プロジェクト、IBM との提携にともな い IBM Watson のローカライズにも参画。 現在はプロフェッショナルなテクノロジー集団の実現を目指して、Java でのクラ ウドネイティブな開発、DevOps の実現を推進中。
- 5. ソフトバンクの IT 本部について IT 本部はいわゆる情報システム部門で、主にキャリア事業に必要な IT サービスを提供するためシステムを開発・運用しています。 IT 本部のシステムの多くは Java で開発、あるいは Java 製品を利用し ています。
- 6. スポンサーの目的 ● まずは、JJUG のようなコミュニティに参加して、 ソフトバンクの IT の認知度を上げるため。 ● JJUG のようなコミュニティに参加、発表してエンジニアの スキル、モチベーションを上げるため。 ● 将来的には採用などでソフトバンクに興味を持ってもらうため。
- 7. IT 本部における Java の歴史 年代 IT 本部の開発の開発のトレンド Java の主なトピック 2005 年以前 様々な言語が乱立しカオスな状況 2006 年 Java EE によるシステム開発 BEA WebLogic の導入 DI コンテナを利用したシステム開発 Tomcat/Seasar2 の導入 2009 年 Exadata 採用 Linux の利用 2013 年 OSS の積極利用 Redhat JBoss EAP の導入 2014 年 大規模リアルタイムストリーム処理 インメモリデータグリッド (JBoss Data Grid/Coherence) の導入 2015 年 ビッグデータの時代 Hadoop、Spark、Kafka の導入 アジャイル開発の導入 WildFly の導入、OpenShift の導入 2018 年 アプリケーションサーバレスな開発 Spring Boot の導入、Micro Profile の検討 2019 年 コンテナオーケストレータの利用 Azure Kubernetes Service、Zulu、Quarkus の利用
- 8. カオスな時代 2005 年以前は、様々な言語が入り乱れてカオスな状態。ObjectWorks などの NRI 社製品が多かった (らしい)
- 9. WebLogic の導入 2006 年、Vodafone を買収し、ソフトバンクモバイルが誕生。この頃から BEA システムズの WebLogic を利用した開発が始まり、ソフトバンクに おける Java の歴史が本格的に始まる。 JVM は BEA JRockit、GC アルゴリズムは BEA 独自の Mostly Concurrent Garbage Collection。
- 10. DI コンテナの時代 しばらくして、ADSL などの BB 事業にて、DI コンテナである Seasar2 を利用した開発が取り入れ始める。 JVM は Sun JDK、GC アルゴリズムは Parallel GC の Young 領域大き め。
- 11. BEA システムズの買収 2008 年、BEA システムズはオラクルに買収され、WebLogic は、Oracle WebLogic、JRockit は Oracle JRockit となる。
- 12. Exadata V1 の導入 2009 年、Oracle Exadata V1 が国内の通信事業者としては初めて導入 される。
- 14. Linux の導入 アプリケーションサーバを稼働させる OS として、RedHat Enterprise Linux が導入される。
- 15. OSS 製品の積極導入 2013 年、オラクル一辺倒な状況を危惧し、OSS 製品を積極的に活用 するために、JBoss EAP の導入が始まる。 JVM は RHEL の OpenJDK、GC アルゴリズムは CMS (Concurrent Mark Sweep)。
- 16. 大規模リアルタイムストリーム処理の時代 2014 年、増え続ける加入者、パケットサイズに対応するため、大規模リ アルタイムストリーム処理 (Chronos-Core) に挑戦。インメモリ・データ グリッド製品である、JBoss Data Grid、Oracle Coherence が導入され、 ヒープサイズは 100GB に迫る。 JVM は RHEL の OpenJDK、GC アルゴリズムは CMS 。
- 17. Zing JVM の PoC 大規模リアルタイムストリーム処理の挑戦の際に、Azul Systems の Zing JVM の PoC も実施。 250 GB ヒープまで起動が確認でき、GC ポーズも良好だったが、価格 的な問題で採用に至らず。
- 18. Java 製品監視ツールで Zulu の導入 SB 内の様々な Java ミドルウェア製品の監視に JMX の監視ツールを 社内開発しており、Zulu JDK を導入。
- 19. ビッグデータ処理/AI の時代 2015 年、ビッグデータ、機械学習/AI の時代となり、Hadoop、Spark、 Kafka が導入される。 JVM は CentOS の OpenJDK、GC アルゴリズムは CMS 、Kafka で G1GC。
- 20. WildFly の導入 システム統合が推進され、内製プラットフォームが整備されて、WildFly が導入される。 JVM は CentOS の OpenJDK、GC アルゴリズムは CMS。
- 21. アプリケーションサーバレスの時代 2018 年、Spring Boot が普及され始め、アプリケーションサーバを必要 としない時代となる。 JVM は CentOS の OpenJDK、GC アルゴリズムは CMS。
- 22. コンテナオーケストレータの時代 2019 年、Kubernetes が普及し、コンテナでのアプリケーション開発が 導入され始める。 JVM は Zulu JDK、GC アルゴリズムは ParallelGC。
- 23. JVM、GC アルゴリズムの変遷 年代 IT 本部の開発の開発のトレンド 主な JVM 主な GC アルゴリズム 2005 年以前 様々な言語が乱立しカオスな状況 2006 年 Java EE によるシステム開発 BEA JRockit Mostly Concurrent Garbage Collection DI コンテナを利用したシステム開発 Sun JDK Parallel GC 2013 年 OSS の積極利用 OpenJDK Concurrent Mark Sweep 2014 年 大規模リアルタイムストリーム処理 OpenJDK、Zulu JDK Concurrent Mark Sweep 2015 年 ビッグデータの時代 OpenJDK G1GC アジャイル開発の導入 OpenJDK Concurrent Mark Sweep 2018 年 アプリケーションサーバレスな開発 OpenJDK Concurrent Mark Sweep 2019 年 コンテナオーケストレータの利用 Zulu JDK Parallel GC 主な JVM、GC アルゴリズムの変遷は以下のとおり。
- 24. サーバーサイド Java のトレンド 年代 IT 本部の開発のトレンド 2005 年以前 様々な言語が乱立しカオスな状況 2006 年 Java EE によるシステム開発 アプリケーション サーバの時代 DI コンテナを利用したシステム開発 2013 年 OSS の積極利用 2014 年 大規模リアルタイムストリーム処理 2015 年 ビッグデータの時代 アジャイル開発の導入 2018 年 アプリケーションサーバレスな開発 2019 年 コンテナオーケストレータの利用 Spring Boot が導入されるまで、サーバーサイド Java はアプリケーショ ンサーバにデプロイするものだった。
- 25. Java の優位性 CPU はマルチコア化、サーバの搭載メモリーはどんどん大規模になっ ていく傾向にあった。 ● JVM は Ruby や Pyhton 等の GIL (Globak Interpreter Lock) を使 用しないため、マルチコアを使いこなすことができる。 ● サーバメモリが大きくなるについて、大規模なヒープが利用できるよ うになり、大規模ヒープを扱うことができる CMS、G1GC、 Shenandoah GC、ZGC などの GC アルゴリズムが豊富。
- 26. 小規模ヒープ時代の GC Java の初期の頃はサーバメモリも大きくなく、アプリケーションの実行 を止めて、GC を実行するスループットコレクタが一般的だった。 GC スレッドアプリケーション スレッド アプリケーション スレッド いわゆる、Java の Stop The World
- 27. 大規模ヒープ時代の GC 大規模ヒープでは、STW が破滅的なため、アプリケーションを実行しな がら GC するコンカレントコレクタの利用が一般的だった。 Old 領域に余裕が ある場合は、すべて のスレッドでアプリ を実行。 Old 領域に余裕がなくなってきて 閾値に達するとコンカレントコレク タで GC する。GC にスレッドがい くつか使用されるので、アプリ ケーションの実行は遅くなる。
- 28. Kubernetes における Java Kubernetes でアプリケーションをコンテナとして管理するようになると、1 コンテナのコア数、メモリは小さい傾向となるため、これまでのメニーコ ア、大規模ヒープが利用できる JVM の優位性は必ずしもアドバンテー ジとは言えない。 Kubernetes VM VM VM VM VM VM VM VM
- 29. The Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと複数のデプロイ VII. ポートバインディング ポートバインディングを通してサービスを公開する II. 依存関係 依存関係を明示的に宣言し分離する VIII. 並行性 プロセスモデルによってスケールアウトする III. 設定 設定を環境変数に格納する IX. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する IV. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う X. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ V. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する XI. ログ ログをイベントストリームとして扱う VI. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する XII. 管理プロセス 管理タスクを1回限りのプロセスとして実行する クラウドネイティブの指針として、12-factor App があるが、アプリケー ションサーバ時代の実装を大きく変える必要がある。
- 30. JDK のコンテナイメージ 12-factor App の観点からコンテナのサイズは小さければ小さいほどよ いが、オフィシャルの JDK の docker イメージのサイズは大きい。 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE openjdk 11 f75c7d826c08 3 weeks ago 605MB
- 31. alpine とカスタム JRE alpine と、Java9 からの jlink によるカスタム JRE でまずはコンテナイ メージを可能な限り小さくする。 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE zulu.custom 11 2ca39f1ed611 17 seconds ago 69.3MB --add-modules jdk.localedata --include-locales=en,ja,*-IN Spring Boot は厳密には fatJar ではないので jdeps で出力される依存 性はアテにならない。また、日本語ロケール等を利用する場合は、以下 のモジュールも必要。
- 32. コンテナのサイジング kubernetes 環境では、コンテナでスケールアウトするように、1 コンテナ のサイジングは 1 CPU、1G とする。 resources: requests: cpu: 1 memory: 1G limits: cpu: 1 memory: 1G
- 33. Java 8 以降のコンテナ対応 -XX:+UseContainerSupport Java 10 以降で追加され、CGroup の CPU やメモリの制限を適切にハンドリングできるようになる。 UseCGroupMemoryLimitForHeap は Java 11 で廃止。デフォルトで有効だが、明示的に指定。 -XX:InitialRAMPercentage=50 コンテナが利用できるメモリに対する初期ヒープサイズのパーセンテージ。InitialRAMFraction は Java 10 で 廃止。 -XX:MinRAMPercentage=50 コンテナが利用できるメモリに対する最小ヒープサイズのパーセンテージ。MinRAMFraction は Java 10 で廃 止。 -XX:MaxRAMPercentage=50 コンテナが利用できるメモリに対する最大ヒープサイズのパーセンテージ。MaxRAMFraction は Java 10 で廃 止。 Java 8 では、コンテナの CGroup の制限を見ず、母艦のコア数やメモリ を参照して、エルゴノミクスでチューニングしてしまうため注意が必要。
- 34. 小規模ヒープ向けの GC チューニング コンテナでは 1 プロセス辺りのヒープが小さいため、スループット GC を採用。 -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=3000 -XX:GCTimeRatio=19
- 35. ネイティブメモリのチューニング Eden Survior From To Tenured Metaspace Compressed Class Space Code Cache Stack Direct Buffer C heap Java ヒープ Native メモリ -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=64m -XX:CompressedClassSpaceSize=64m -XX:MaxDirectMemorySize=32m Java ヒープだけでなく、Metaspace 等の Native メモリも最大値を設定。
- 36. その他の起動オプション Java 9 以降は -Xlog オプションが追加されており、これまでの -XX:+PrintGCDetails などが廃止されており注意が必要。 -Xlog:gc*=info::time,uptime,level,tags -XX:+ExitOnOutOfMemoryError -Djava.net.preferIPv4Stack=true -Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom