QCon London英国のネオバンク Revolut の主席エンジニアである Andrzej Grzesik 氏は、最近開催された QCon London で (対面式の技術カンファレンスが主流だった時代に)、同社が 1 年以上稼働している Java 11 への移行について講演しました。
Revolutは2015年7月に設立され、現在では世界中に2,200人の従業員、1,000万人を超える小売ユーザー、34万人を超えるビジネスユーザーを擁しています。
Javaの問題は、Java 9で導入された新しいモジュールアーキテクチャや多くの機能の廃止などの変更により、Java 8向けに作成されたアプリケーションが修正なしでは動作しないことが多いことです。また、Javaは現在6ヶ月ごとのリリースサイクルを採用しており、3年ごとの長期サポート（LTS）リリースを除き、最新バージョンのみがサポートされています。Java 11はJava 8後の最初のLTSリリースでした。2014年3月にリリースされたJava 8は古いバージョンであるにもかかわらず、実稼働環境で最も人気のあるバージョンです。Grzesik氏が参照した最近の小規模な調査では、開発者の58%がJDK 8を使用していることが示されました。
JDK 8の一部はJDK 11で削除されるとGrzesik氏は警告した。これにはWebサービススタックも含まれる。
新しいライフサイクルは、ほとんどの組織にとってLTSリリース以外への移行が現実的ではないことを意味します。例えば、本稿執筆時点での最新バージョンはJDK 13ですが、まもなくサポートが終了します。JDK 14も間もなくリリースされますが、ごく最近までGradleビルドツールはJDK 14で動作しませんでした。これは、互換性のないGroovy言語を使用しているためです。これは、このような短命リリースで発生する可能性のある問題の一例にすぎません。
RevolutはJavaアプリケーションをDockerコンテナにデプロイし、Java Sparkというフレームワークを使用しています。「アノテーション駆動型の問題のデバッグは面倒なので、Springは使用していません」とGrzesik氏は言います。「金融会社として、私たちは厳しい監視の目にさらされているので、迅速に行動し、何も壊さないようにしなければなりません」
同行は昨年、FCA（金融行動監視機構）からコンプライアンスに関する質問を受けた。FCA認可の電子マネー機関である同行は、今年初めに3億8,700万ポンドの資金調達ラウンドを実施し、評価額が40億ポンドに達した。
はい、すべてのアプリがアップグレードされました
なぜRevolutはアップグレードしたのか？グルゼシク氏はいくつかの理由を挙げた。どれも決定的なものではなかったものの、彼が重視したのは、移行は避けられないということだった。「いずれにせよアップグレードは必要だった。ソフトウェアに新しい機能が追加されるからだ」と彼は述べた。しかし、実際には技術的なメリットもあることが判明した。
同氏はまた、「優秀な人材を雇うのが容易になる」とも指摘した。開発者が働く場所を選べるなら、Javaの最新バージョンを扱える仕事を選ぶ可能性が高くなるからだ。
JDK 11のライセンスはJDK 8とは異なり、Oracleは配布に商用ライセンスを必要としています。「Oracle JDKは廃止しました。ライセンスは非常に複雑で、面倒だと感じています」とGrzesik氏は述べました。解決策は、同じコードと修正をすべて利用できるOpenJDKを使用することでした。
Revolut のアプローチは、部分的なアプローチではなく、すべてのアプリを Java 11 にアップグレードすることでした。
問題はいくつかありました。最大の問題は依存関係に関するものでした。自分のコードは修正できますが、依存しているライブラリやツールが動作しない場合、できることは限られます。さらに、Grzesik氏は、ベンダーやコミュニティが互換性を発表した瞬間が、必ずしもすぐに使える状態になるとは限らないと述べました。「公式サポートは必ずしも期待通りに動作することを意味するわけではありません」と彼は述べました。彼は例として、JDK 11を「2.20.1以降」正式にサポートしていたものの、実際にはそれ以降のバージョンまで対応していなかったモックフレームワークMockitoを挙げました。同社はFlywayというデータベース移行ツールでも同様の問題を抱えていました。徹底的なテストが不可欠です。
「テストケースの数は数万に上ります」と彼は語った。
Grzesik 氏は、JEP 320 に記載されている Web サービス スタックなど、JDK 8 の一部が JDK 11 で削除されると警告しました。
チームは時刻の精度に関する複雑な問題に直面しました。JDK 9以降、java.time.Clockの精度はOSによって異なります。そのため、例えばPostgresデータベースを扱う際に問題が発生し、「一部のコードでは3桁を想定、他のコードでは6桁を想定」といった問題が発生しました。
その結果、「奇妙なバグやテストの失敗が大量に発生する」とGrzesik氏は述べた。彼の解決策は、時間操作を制御するラッパー関数を使用することで、一貫性を保つことだ。
Grzesik氏は、いくつかの問題とその対処法について説明しましたが、実際のアプリケーションで発生する問題はそれぞれ異なります。Oracleは独自の移行ガイドをこちらで公開しています。
最新の状態を保つこと以外に、どのような利点があるのでしょうか?
いくつかの例が挙げられました。その一つがCompact Stringです。Java 8の文字列は内部的にchar配列を使用しますが、Java 9以降はbyte配列を使用します。Grzesik氏は、「2バイト文字を使用しない場合、メモリ使用量は半分になります」と述べました。
JDK 10以降、ガベージコレクション（GC）がマルチスレッド化されたことも改善点の一つです。これにより、アプリケーションに短時間の停止が発生しなくなりました。「人間の感覚レベルで停止のないサービスを実現するために、GCのチューニングで魔法をかける必要はありません。これはJDK 8と比べて画期的なことです」と彼は述べています。
当初の懐疑論にもかかわらず、VARの採用は好調である
JDK 10以降、Javaはvarキーワードによる型推論をサポートしています。「最初は少し警戒していましたが、この機能はすぐに普及しました。実際、varを使う人は好んで使っています。文字数が少なく、読みやすくなっているからです。通常、varが置き換えるコードはごく簡単です」とGrzesik氏は述べ、Revolutのあるプロジェクトでvarの採用がどのように増加したかを示しました。
JDK 11ではコンテナのスケーリングが容易になったとGrzesik氏は述べた。「使用量が増えたら、コンテナにメモリを割り当てるだけです。」Java 11はJava 8（厳密に指定されたコンテナの一部が動作しなくなる原因となった）よりもわずかに多くのメモリを使用するものの、これはメリットと言える。
グルゼシク氏は、オープンソースで無料で利用できるJava Flight RecordとMission Controlも高く評価しました。「これらの優れたツールを使えば、JDK 11アプリケーションを分析できます。」
これはアップグレードの説得力のある根拠となるでしょうか？ トレードオフです。メリットはありますが、痛みのないプロセスではなく、問題も発生します。Grzesik氏が指摘したように、これはすべてのJavaチームがいつかは直面しなければならないアップグレードです。
アップグレードはどのように行うのでしょうか。「まずはアプリケーションをコンパイルしてみて、そこから始めてください」と彼は言いました。®
