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

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

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

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

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

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

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

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 の利用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 アルゴリズムの変遷は以下のとおり。

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

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

小規模ヒープ時代の GC  
Java の初期の頃はサーバメモリも大きくなく、アプリケーションの実行
を止めて、GC を実行するスループットコレクタが一般的だった。 
GC スレッドアプリケーション
スレッド
アプリケーション
スレッド
いわゆる、Java の
Stop The World

大規模ヒープ時代の GC 
大規模ヒープでは、STW が破滅的なため、アプリケーションを実行しな
がら GC するコンカレントコレクタの利用が一般的だった。 
Old 領域に余裕が
ある場合は、すべて
のスレッドでアプリ
を実行。
Old 領域に余裕がなくなってきて
閾値に達するとコンカレントコレク
タで GC する。GC にスレッドがい
くつか使用されるので、アプリ
ケーションの実行は遅くなる。

Kubernetes における Java 
Kubernetes でアプリケーションをコンテナとして管理するようになると、1
コンテナのコア数、メモリは小さい傾向となるため、これまでのメニーコ
ア、大規模ヒープが利用できる JVM の優位性は必ずしもアドバンテー
ジとは言えない。 
Kubernetes 
VM  VM  VM  VM  VM  VM  VM  VM

The Twelve-Factor App 
I. コードベース 
バージョン管理されている1つのコードベースと複数のデプロイ 
VII. ポートバインディング  
ポートバインディングを通してサービスを公開する 
II. 依存関係 
依存関係を明示的に宣言し分離する 
VIII. 並行性 
プロセスモデルによってスケールアウトする 
III. 設定 
設定を環境変数に格納する 
IX. 廃棄容易性 
高速な起動とグレースフルシャットダウンで堅牢性を最大化する 
IV. バックエンドサービス  
バックエンドサービスをアタッチされたリソースとして扱う 
X. 開発/本番一致 
開発、ステージング、本番環境をできるだけ一致させた状態を保つ 
V. ビルド、リリース、実行  
ビルド、リリース、実行の3つのステージを厳密に分離する 
XI. ログ 
ログをイベントストリームとして扱う 
VI. プロセス 
アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する 
XII. 管理プロセス 
管理タスクを1回限りのプロセスとして実行する 
クラウドネイティブの指針として、12-factor App があるが、アプリケー
ションサーバ時代の実装を大きく変える必要がある。

JDK のコンテナイメージ 
12-factor App の観点からコンテナのサイズは小さければ小さいほどよ
いが、オフィシャルの JDK の docker イメージのサイズは大きい。 
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
openjdk 11 f75c7d826c08 3 weeks ago 605MB

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 で出力される依存
性はアテにならない。また、日本語ロケール等を利用する場合は、以下
のモジュールも必要。

コンテナのサイジング 
kubernetes 環境では、コンテナでスケールアウトするように、1 コンテナ
のサイジングは 1 CPU、1G とする。 
resources:
requests:
cpu: 1
memory: 1G
limits:
cpu: 1
memory: 1G

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 の制限を見ず、母艦のコア数やメモリ
を参照して、エルゴノミクスでチューニングしてしまうため注意が必要。

小規模ヒープ向けの GC チューニング 
コンテナでは 1 プロセス辺りのヒープが小さいため、スループット GC
を採用。 
-XX:+UseParallelGC
-XX:+UseParallelOldGC
-XX:+UseAdaptiveSizePolicy
-XX:MaxGCPauseMillis=3000
-XX:GCTimeRatio=19

ネイティブメモリのチューニング 
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 メモリも最大値を設定。

その他の起動オプション 
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

今後の展望 
今後は、さらなるフットプリントの削減、起動時間の短縮を実現するため
に、GraalVM についてもチャレンジ。 
まずは、Quarkus のネイティブイメージから。

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

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

Semelhante a Java によるクラウドネイティブの実現に向けて (20)