Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Java によるクラウドネイティブ の実現に向けて

774 views

Published on

2019/11/23 JJUG CCC 2019 Fall 発表資料

Published in: Software
  • Be the first to comment

  • Be the first to like this

Java によるクラウドネイティブ の実現に向けて

  1. 1. Java によるクラウドネイティブ
 の実現に向けて
 Shigeru Tatsuta
 2019/11/23 JJUG CCC 2019 Fall

  2. 2. 対象となる方
 ● ソフトバンクにおける Java の開発に興味のある方
 
 ● アプリケーションサーバから、クラウドネイティブへの移行 を検討している方
 
 ● JVM のチューニングに興味のある方
 ※ Kubernetes、Quarkus の内容について興味のある方は、
   14:30 - 15:15 Room M の弊社のセッションの方もご参加ください。

  3. 3. 自己紹介
 竜田 茂 (たつた しげる)
 
 ソフトバンク株式会社
 テクノロジーユニット IT&ネットワーク統括 IT 本部
 
 前職の日本オラクルでは Java アプリケーションサーバ製品の技術サポートを 担当。
 
 2013 年よりソフトバンクに参画し、Java ミドルウェア製品の全社導入支援、お よびリアルタイム処理基盤 Chronos-Core プロジェクト、IBM との提携にともな い IBM Watson のローカライズにも参画。 
 
 現在はプロフェッショナルなテクノロジー集団の実現を目指して、Java でのクラ ウドネイティブな開発、DevOps の実現を推進中。 
 

  4. 4. ソフトバンクのテクノロジーユニット
 ソフトバンクでは、モバイル技術、ネットワーク、IT などのテクノロジーに 関連する部署をテクノロジーユニットという一つの組織として、「営業の 強い会社」から「テクノロジーの強い会社」に生まれ変わろうと取り組ん でいます。
 営業の強い
 会社
 テクノロジー
 の強い会社

  5. 5. ソフトバンクの IT 本部について
 IT 本部はいわゆる情報システム部門で、主にキャリア事業に必要な IT サービスを提供するためシステムを開発・運用しています。
 IT 本部のシステムの多くは Java で開発、あるいは Java 製品を利用し ています。

  6. 6. スポンサーの目的
 ● まずは、JJUG のようなコミュニティに参加して、
 ソフトバンクの IT の認知度を上げるため。
 
 ● JJUG のようなコミュニティに参加、発表してエンジニアの スキル、モチベーションを上げるため。
 
 ● 将来的には採用などでソフトバンクに興味を持ってもらうため。 

  7. 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. 8. カオスな時代
 2005 年以前は、様々な言語が入り乱れてカオスな状態。ObjectWorks などの NRI 社製品が多かった (らしい)

  9. 9. WebLogic の導入
 2006 年、Vodafone を買収し、ソフトバンクモバイルが誕生。この頃から BEA システムズの WebLogic を利用した開発が始まり、ソフトバンクに おける Java の歴史が本格的に始まる。
 JVM は BEA JRockit、GC アルゴリズムは BEA 独自の Mostly Concurrent Garbage Collection。

  10. 10. DI コンテナの時代
 しばらくして、ADSL などの BB 事業にて、DI コンテナである Seasar2 を利用した開発が取り入れ始める。
 JVM は Sun JDK、GC アルゴリズムは Parallel GC の Young 領域大き め。

  11. 11. BEA システムズの買収
 2008 年、BEA システムズはオラクルに買収され、WebLogic は、Oracle WebLogic、JRockit は Oracle JRockit となる。

  12. 12. Exadata V1 の導入
 2009 年、Oracle Exadata V1 が国内の通信事業者としては初めて導入 される。

  13. 13. サン・マイクロシステムズの買収
 2010 年、サン・マイクロシステムズはオラクルに買収され、Sun JDK は、Oracle JDK となる。

  14. 14. Linux の導入
 アプリケーションサーバを稼働させる OS として、RedHat Enterprise Linux が導入される。

  15. 15. OSS 製品の積極導入
 2013 年、オラクル一辺倒な状況を危惧し、OSS 製品を積極的に活用 するために、JBoss EAP の導入が始まる。
 JVM は RHEL の OpenJDK、GC アルゴリズムは CMS (Concurrent Mark Sweep)。

  16. 16. 大規模リアルタイムストリーム処理の時代
 2014 年、増え続ける加入者、パケットサイズに対応するため、大規模リ アルタイムストリーム処理 (Chronos-Core) に挑戦。インメモリ・データ グリッド製品である、JBoss Data Grid、Oracle Coherence が導入され、 ヒープサイズは 100GB に迫る。
 JVM は RHEL の OpenJDK、GC アルゴリズムは CMS 。

  17. 17. Zing JVM の PoC
 大規模リアルタイムストリーム処理の挑戦の際に、Azul Systems の Zing JVM の PoC も実施。
 250 GB ヒープまで起動が確認でき、GC ポーズも良好だったが、価格 的な問題で採用に至らず。

  18. 18. Java 製品監視ツールで Zulu の導入
 SB 内の様々な Java ミドルウェア製品の監視に JMX の監視ツールを 社内開発しており、Zulu JDK を導入。

  19. 19. ビッグデータ処理/AI の時代
 2015 年、ビッグデータ、機械学習/AI の時代となり、Hadoop、Spark、 Kafka が導入される。
 JVM は CentOS の OpenJDK、GC アルゴリズムは CMS 、Kafka で G1GC。

  20. 20. WildFly の導入
 システム統合が推進され、内製プラットフォームが整備されて、WildFly が導入される。
 JVM は CentOS の OpenJDK、GC アルゴリズムは CMS。

  21. 21. アプリケーションサーバレスの時代
 2018 年、Spring Boot が普及され始め、アプリケーションサーバを必要 としない時代となる。
 JVM は CentOS の OpenJDK、GC アルゴリズムは CMS。

  22. 22. コンテナオーケストレータの時代
 2019 年、Kubernetes が普及し、コンテナでのアプリケーション開発が 導入され始める。
 JVM は Zulu JDK、GC アルゴリズムは ParallelGC。

  23. 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. 24. サーバーサイド Java のトレンド
 年代
 IT 本部の開発のトレンド
 
 2005 年以前
 様々な言語が乱立しカオスな状況
 
 2006 年
 Java EE によるシステム開発
 アプリケーション
 サーバの時代
 
 DI コンテナを利用したシステム開発
 2013 年
 OSS の積極利用
 2014 年
 大規模リアルタイムストリーム処理
 2015 年
 ビッグデータの時代
 
 アジャイル開発の導入
 2018 年
 アプリケーションサーバレスな開発
 
 2019 年
 コンテナオーケストレータの利用
 
 Spring Boot が導入されるまで、サーバーサイド Java はアプリケーショ ンサーバにデプロイするものだった。

  25. 25. Java の優位性
 CPU はマルチコア化、サーバの搭載メモリーはどんどん大規模になっ ていく傾向にあった。
 ● JVM は Ruby や Pyhton 等の GIL (Globak Interpreter Lock) を使 用しないため、マルチコアを使いこなすことができる。
 
 ● サーバメモリが大きくなるについて、大規模なヒープが利用できるよ うになり、大規模ヒープを扱うことができる CMS、G1GC、 Shenandoah GC、ZGC などの GC アルゴリズムが豊富。

  26. 26. 小規模ヒープ時代の GC 
 Java の初期の頃はサーバメモリも大きくなく、アプリケーションの実行 を止めて、GC を実行するスループットコレクタが一般的だった。
 GC スレッドアプリケーション スレッド アプリケーション スレッド いわゆる、Java の Stop The World
  27. 27. 大規模ヒープ時代の GC
 大規模ヒープでは、STW が破滅的なため、アプリケーションを実行しな がら GC するコンカレントコレクタの利用が一般的だった。
 Old 領域に余裕が ある場合は、すべて のスレッドでアプリ を実行。 Old 領域に余裕がなくなってきて 閾値に達するとコンカレントコレク タで GC する。GC にスレッドがい くつか使用されるので、アプリ ケーションの実行は遅くなる。
  28. 28. Kubernetes における Java
 Kubernetes でアプリケーションをコンテナとして管理するようになると、1 コンテナのコア数、メモリは小さい傾向となるため、これまでのメニーコ ア、大規模ヒープが利用できる JVM の優位性は必ずしもアドバンテー ジとは言えない。
 Kubernetes
 VM
 VM
 VM
 VM
 VM
 VM
 VM
 VM

  29. 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. 30. JDK のコンテナイメージ
 12-factor App の観点からコンテナのサイズは小さければ小さいほどよ いが、オフィシャルの JDK の docker イメージのサイズは大きい。
 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE openjdk 11 f75c7d826c08 3 weeks ago 605MB
  31. 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. 32. コンテナのサイジング
 kubernetes 環境では、コンテナでスケールアウトするように、1 コンテナ のサイジングは 1 CPU、1G とする。
 resources: requests: cpu: 1 memory: 1G limits: cpu: 1 memory: 1G
  33. 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. 34. 小規模ヒープ向けの GC チューニング
 コンテナでは 1 プロセス辺りのヒープが小さいため、スループット GC を採用。
 -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=3000 -XX:GCTimeRatio=19
  35. 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. 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
  37. 37. 今後の展望
 今後は、さらなるフットプリントの削減、起動時間の短縮を実現するため に、GraalVM についてもチャレンジ。
 まずは、Quarkus のネイティブイメージから。


×