2人のJavaエキスパートが考える、クラウドネイティブ時代にJava開発者に求められるスキルとは

　ヤフーでは、2017年頃よりプラットフォームのモダナイゼーションを進める中で、Javaを標準言語のひとつとして位置付けました。現在はCI/CDなども導入し、ビジネススピードの変化に対応できる基盤が確立。運用・拡大フェーズに入ったことで、新たな課題やその解決に取り組んでいます。Javaの最新情報に加え、Javaを活用したモダナイゼーションに取り組む際にはどんな課題があり、開発や運用上でどんな工夫が必要なのか。ヤフーでJavaを活用したモダナイゼーションに取り組んだ高見拓也氏と、Java Championの寺田佳央氏に語っていただきました。

2人のJavaエキスパートが注目するJavaの新機能

──お二人はJavaに関してどのような取り組みをしていますか。

高見拓也氏（以下、高見）：ヤフーには2012年に入社し、広告主向けのプラットフォームをJavaで刷新するプロジェクトを担当しました。現在は、Javaを用いた新しい開発業務を担当しつつ、全社のJava開発をサポートする言語サポートチームを兼務し、日々の現場の課題解決や、研修チームと協業で研修の企画などに携わっています。また2021年10月には第11代黒帯～プログラミング言語（Java）～に任命されました。

寺田佳央氏（以下、寺田）：Java Championとしては、最新のJavaの動向などを日本のコミュニティで発信するほか、所属企業のマイクロソフトでは、Javaのクラウド・アドボケイトとしてマイクロソフト・プラットフォームにおけるJavaの利用促進や啓蒙活動を行っています。特に、エンタープライズシステムにおけるJavaを活用したモダナイズやマイクロソフトが提供するサービスの実装方法やトラブルシューティングなど、Javaに関することに幅広く携わっています。

──現在、Javaのどんな機能に注目していますか。

寺田：個人的に最も注目しているのは「仮想スレッド（Virtual Thread）」です。現在はプレビューですが、これが正式にリリースされると今までの非同期実装の部分がずいぶんと書きやすくなります。

　また「クラス・データ共有」をはじめ、起動時間の高速化への取り組みが行われています。それ以外にもGraal VMを利用してJavaのコードから、LinuxやMac、Windowsなど各OS専用のバイナリを作って素早く起動できるような機能もあるので、今までJavaが苦手としていた起動時間の短縮についてかなりの改善が行われています。Javaの素晴らしさは一度起動すると安定して稼働するところなので、これまでJavaを検討する際に躊躇していた部分の改善が行われているところには注目していただきたいですね。

高見：私も仮想スレッドにはすごく期待しています。ヤフーでもリアクティブプログラミングを導入するためにSpring WebFluxに載せ替えようとしているのですが、今のアプリケーションはそのまま乗せられないので、作り直ししているんです。ただ、リアクティブプログラミングはデバッグが難しいため、仮想スレッドによって非同期処理が楽になるだろうと期待しています。

寺田：デバッグだけではなく、初めてMonoやFluxを使う時は最初、とまどいますよね。

高見：Stream APIと一緒じゃないかと思うんですけど、Collection処理ではなくて幅が広いので、簡単に書けないですからね。

寺田：そうですね。リアクティブプログラミングは、どこでサブスクライブさせるかという問題もありますからね。

高見：他にも、GraalVMを積んだネイティブJavaに期待しています。

　ヤフーでもモダン化が進み、サーバレスでもプライベートクラウド上にプラットフォームを構築しているのですが、Javaでは運用に耐えられず、採用できない状況になっています。

　TypeScriptを採用するケースが多く、エンジニアの習得する技術が増え、保守性や開発スピードが遅くなるという問題もありました。

　Jakarta EE 10の新機能であるCore Profileを見てみると、GraalVMをはじめマイクロサービスに適した軽量化にしっかりと取り組んでいることが分かったので、自分たちが進む方向とJavaの本流が進む方向が合っているんだと安心しました。

寺田：Jakarta EEに取り組んでいた人間として、お待たせしましたという感じです（笑）。

高見拓也（たかみ・たくや）氏

　ヤフー株式会社 MSグループ MP統括本部 広告開発本部所属。第11代・第12代黒帯～プログラミング言語（Java）～。大手SIerにて、自治体・金融機関系のシステム開発に従事後、2012年ヤフー入社。入社後、広告システムに従事し、広告主向けプラットフォームをJavaを使って刷新するプロジェクトを担当。Javaを用いた開発業務を担当しつつ、全社のJava開発をサポートする言語サポートチームを兼務。2021年より、黒帯～プログラミング言語（Java）～として活動している。

最新のJavaに追随していくためには

──ヤフーや、寺田さんが支援している企業では、新しいJavaにどのようにキャッチアップしていますか。

高見：私たちは昨年11月にようやくシステムのモダン化が完了し、技術的負債を清算したところです。最新動向についてのキャッチアップはこれからですね。モダン化に5年もかけてしまったので、その分レガシーになってしまった分の維持・メンテナンスに取り組んでいます。

　小さなサービスでは、最新のJavaに追従しているものもあるのですが、そこに対してJavaサポートメンバーがアクションできていないのが、悩ましいところです。

寺田：国内外のさまざまな企業をサポートしていますが、企業によってそれぞれ状況が大きく異なります。古いシステムからモダナイズされたお客さまは、既存のコードがあるので、古いJavaを使っているケースもあります。

　実際、海外のとある自動車メーカーは、Java 8がベースとなっています。一方、これから新しくシステムを作っていくお客さまは、Java 17をベースに考えるなど、企業によってバラツキがあるという状況です。

　以前はJava 8が多かったのですが、最近はJava 11、Java 17も増えています。コンテナ化するにはJava 8よりもJava 11やJava 17の方がメリットを得られるからです。そのためJava 8を使っているお客さまに対しても、「いきなりは難しいかもしれませんが、Java 11やJava 17に上げていきましょう」という話は常にしています。

　例えば、Java 9以降、アプリケーションを専用に動かすカスタムJREをモジュール化することで、Dockerイメージを軽量化できるようになりました。このように新しいバージョンにアップデートすることで、最近の環境で動かすのに便利な機能が入っています。移行コストというデメリットはあるので、お客さまのステータスを見ながら、バージョンアップしてもらうよう支援しています。

高見：2022年度の下期に入ってから、私たちもJava 17に上げようと動いています。Java 8から17へのバージョンアップなので、課題がいろいろ出るかと思っていましたが、意外にすんなりとバージョンアップできています。Javaは後方互換が素晴らしいですね。

寺田：実はJavaは8からのバージョンアップが一番大変なんです。なぜなら9になったところで、XML関連の機能が大幅に削除されたからです。そこができればそれ以降は比較的簡単にバージョンアップできると思います。

高見：確かに9の壁と社内では言っていました。ですが、いろいろな人が文献を出していたので、それを参考にしたら思った以上にすんなりとバージョンアップが進みました。

　実はモダン化を早く進めるためにSpring Bootを採用し、現在、社内ではSpring Boot一択になっているのですが、私自身は、その状況を危惧しています。というのもSpringは、Java EEやJakarta EEなどエンタープライズの仕様を全部うまく隠してくれます。そのため、Java EEやJakarta EEの動向をウォッチできないエンジニアが増えているんです。サーブレットやWebコンテナの基礎も分からず、サーバサイドを実装しているエンジニアが増えてくることを懸念しています。

寺田：私も同じようなことを感じています。少し、Javaから話は逸れますが、GitHubにCopilotという機能が出てきました。

　GitHub Copilotは、OpenAIの技術を使って、プログラマーが書きたいコードをAIが推測して自動的に補完してくれるサービスです。通常、コード補完というと1行レベルじゃないですか。ですがCopilotは2～30行のコードが一度に出てくるんです。これを見たときに便利だなと思った一方で、危険だなと思いました。

　ちゃんとコードを理解している人が、自分が書きたいコードは確かにこの通りだと、ボタン一発で書けるようになるのはよいのですが、初心者がこれを使った時に、AIが出したコードだから間違いないと考え、それをそのままコミットする。すると、自分が想定しないロジックを埋め込まれて世に出てしまう可能性があります。初心者だと正しいコードかどうか正しい状況がわかりませんからね。怖いことだと思いました。

高見：パターン化やテンプレート化が進むのは良いですが、それを選ぶ力を養わないと危ないですね。

寺田佳央（てらだ・よしお）氏

　Java Champion、マイクロソフト・コーポレーション シニア・クラウド・アドボケイト。

　2001年、サン・マイクロシステムズ株式会社に入社しGlassFishエバンジェリストとして活動。2010年、オラクルのサン買収後、日本オラクル株式会社でJavaエバンジェリストとして活動。Javaの最新技術情報の提供や、Javaコミュニティ活動の活性化を、日本Javaユーザ・グループ（JJUG）と共に行ってきた。2015年7月、日本マイクロソフト株式会社に転職し、転職後もなおJavaエバンジェリストとして、マイクロソフト・プラットフォームにおけるJavaの利用促進・啓蒙活動を実施中。2016年7月、日本人で2人目となるJava Championに就任。2018年7月より、マイクロソフト・コーポレーションで日本人初のクラウド・アドボケイトとして活動を開始。JJUG幹事の一員でもある。

PHPからJavaに移行して実感したJavaのメリット

寺田：ヤフーでは、PHPからJavaに移行されたそうですね。Javaに移行してよかった点について教えていただけますか。

高見：PHPはスクリプト言語なので、素早くデプロイができるというメリットがあります。ですが、文字列も数値も日付も同じデータで扱うところが、業務アプリケーションだと不具合の温床になりやすい。

　一方、Javaはタイプセーフという考え方で書かれているので、そのような不具合はありません。私のようなアプリケーションエンジニアだと、業務のデータモデルやデータ構造をそのままシステムに落としやすいというのもメリットです。また日付が文字列だと、コンパイルエラーにするという思想がエンジニアに普及したことで、インターフェース設計の質が上がりました。

　またテストフレームワークが優れているところもメリットです。CI/CDなどユニットテストの自動化によって、テストの終盤になってのクリティカルな不具合も減りつつあります。テスト全体の工数が圧縮できるので、デプロイの回数が増えるというメリットもあります。バージョンアップしても、普通に今までのアプリケーションが動くのは安心感があります。

寺田：大人数での開発という点ではいかがでしょう。

高見：大規模なシステムにJavaは向いていると思います。何より、コミュニケーションのコストが減るのが良いですね。「データの項目は日付ですか？ 数字ですか？ 文字列ですか？」というやり取りが減るところからはじまり、ドキュメント化も優れています。

　これまではドキュメント化するツールを内製で作って運用していましたが、最近はドキュメント化ツールもいろいろあるので、コミュニケーションも採りやすくなりました。本当に業務の食い違いが大きく減りました。意味のある会話ができていると感じます。

寺田：私も友人から大規模なシステムを開発するのは、Javaが楽という話をよく聞きます。特にメンテナンス性が優れているのが良いと。バグが出ても、静的型付き言語なので、間違っていたらコンパイルが通らない安心感があるとよく言っています。

コンテナ化・マイクロサービス化にあたり考慮すべきポイント

寺田：モダナイゼーションを経て、現在はどのような構成でシステムを動かしていますか。

高見：これまで実行環境はオンプレミスが中心でしたが、現在はPaaSやCaaSに移行しています。PaaSやCaaSの土台として採用しているのがKubernetesです。Kubernetesをベースにした自前のプラットフォームを構築し、現在移行しているところです。CI/CDも回せるようになり、技術的負債を返済でき、ビジネスの変化に対応できる基盤を手に入れることができました。

　ですが、課題もあります。課題の一つは、当社のシステムはJava 8が大半を占めており、Javaの知見についてガラパゴス化していること。私たちがJavaへの移行を始めた17年はJava 9がリリースされたばかりでしたが、その後、Java 11のLTS版がリリースされ、一昨年はJava 17のLTS版がリリースされました。この5年間で例えば、オラクルがJava EEをEclipse Foundationに移管して、Jakarta EEを設立した出来事がありましたが、こういった最新情報への追随には、組織としてまだまだ課題が残ります。

　もう一つは、クラウドネイティブになりつつあるものの、なりきれていないところです。メトリクスの収集はさまざまなツールを使っていますが、集約ができていません。そのため「このメトリクスをみるならこのツールを使う」というように、ツールの使い方に右往左往しています。そのためJavaのヒープがどういう状況なのかが判断できないのです。耐障害性を考えるとクラウドネイティブになりきれていないと思います。

　そこで現在は、商用プラットフォームを導入し、コンテナが落ちる前にメトリクスを取れるようにするなどの対策を採っています。集約化が今ひとつ実現していないことと、開発者自身でまだ異常値を判断できていないことも課題です。

寺田：実際に今、アウトオブメモリが発生してたときに、ヒープダンプをどんな感じで出しているのでしょう。

高見：Kubernetesにマウントしたストレージにヒープダンプを溜めて後から取りに行くという方法を採っています。

寺田：すべてのPodを永続ボリューム（PersistentVolume）でマウントさせているということですね。ですが、永続ボリュームをマウントさせると、アプリケーションレベル、Podレベルのスケールがしづらくなる傾向があるんですよね。

高見：ヒープダンプを取得するときは、テスト環境や実行環境を変えてPodを減らしてもらい、PrometheusやJMXを使って動いているときに監視をしてもらっています。Grafanaを使えば時系列に見えるので、変な兆候から落ちるまでの断末魔を取れるのでそこで分析することを推奨しています。

寺田：あまりに情報を取り過ぎると、アプリケーションのパフォーマンスに影響は出ませんか。

高見：常駐型のPodは、それほどパフォーマンスは変わりません。Apache Airflowなどのジョブ管理のPodは、JavaのアプリケーションだとCPU負荷が上がって取りづらいというのはあります。

寺田：みなさん、やはりその辺に苦労しているんですね。

　私もいろいろな方とお話しする際には、例えばログに関して基本的には外部出力を勧めています。ログを収集するエージェントがしっかりメモリを持っていないとログをうまく吐き出すことができないからです。

高見：ログの収集に関しては、当社では開発当初から力を入れていたので、そこに関するパフォーマンス劣化はありませんでした。ログの流量制限が、現在の課題となっています。

寺田：コンテナ化においては、ログ管理の実装はしっかり考えないといけないポイントの一つですね。以前のエンタープライズ系のシステムだと、一回ログとして出力した後に収集して、メトリクスを読み取ったりしていましたが、ログをなんでも垂れ流してしまうと、ネットワーク側に負荷がかかってしまいます。そう考えると、クリティカルな情報はログに書いてはいけないという発想になります。

　アプリケーションのログを取る際においても、これは後の解析で必要なら、標準出力にログを出してそのまま自動的に送るのではなく、別のストレージやデータベースに保存するように実装する必要があります。コンテナ化やKubernetes化すれば、今までのノウハウを使えるわけではありません。そのシステムや構成に合わせて、実装を考えることが必要です。

高見：データベースなどの別のストレージにログを保存する方式を採用しているシステムがあります。とはいえ、アプリケーションで使用するデータを保存するものなので、積極的に採用できる方式ではありません。また、容量の限界もあるので、どのくらい溜まったら削除するということも含めて設計する必要がありますね。

寺田：これらのことはモダナイズ化する上で、コンテナに限らず、IaaSでもPaaSでも考えなければいけないことだと思います。

高見：IaaSやオンプレミスの頃は自分たちのシステムだけに特化して考えればよかったことが、全体を見て考えなければならないので、一気に難しくなりますね。

寺田：マイクロサービスを実装し、コンテナ化をして動かす場合でも、パフォーマンスやレイテンシー、反応速度まで考えるのであれば、同じノードで動かす、一つのPodの中にマルチコンテナ化するなど、考えなければならないことはさらに広がります。

高見：トラブルシューティングまで考えて設計することが今まで以上に求められるようになると思います。

寺田：おっしゃる通りです。数年前からKubernetesやマイクロサービス化を考える際には、Design for Failureを元に、障害を起きることを前提にシステム作りをしましょうと話しています。

モダナイズを考えるにあたって重要な「7R」

──日本の会社が今後モダナイズを進めていくためにはどうすればよいでしょうか。

寺田：新規にサービスを作っていく場合は、できる限り最新のテクノロジーや手法を採用して、失敗をしてもそこから学んでいけば、比較的容易にモダナイズを進めることができると思います。

　一方、既存のシステムをモダナイズしていきたい企業の場合は、いきなりモダナイズをゴールにするのではなく、今あるシステムを3年後、5年後先にはどうしていきたいのか、また今の課題は何なのか、それらをしっかり把握した上で、モダナイズを考える必要があります。その際に使ってもらいたいのが、リホスト、リプラットフォーム、リファクタ、リアーキテクト、リビルド、リプレース、リタイアの「7R」です。

　まずは、どのRを適用すればよいのかを考えることからモダナイズは始まります。中でも日本企業に考えていただきたいのがリタイア。古いシステムをいつ、EOLさせ、新しいものを作っていくのか。リタイアさせる決断ができない企業が多いような気がするからです。

高見：5年前に欲しかったですね。おっしゃるとおり、リタイアはすごくパワーを使いますからね。

寺田：リタイアも、Kubernetesやコンテナを活用してバージョニング化すれば、やりやすいと思います。例えばバージョン1とバージョン2のPodを1年間併存させ、1年後にバージョン1をEOLするという移行プランを考えておけばよいのです。変更に強いシステムを作る上でリタイアは重要なポイントだと思います。

高見：バージョニング戦略は、5年間のモダナイズで当社でも浸透しました。新しい移転先を作り、移行期間をおき、終わったら消すというサイクルがエンジニアの間で当たり前になりつつあります。

エンジニアはこれからの新しい未来を創っていく貴重な存在

──お二人の今後のチャレンジについて教えてください。

高見：モダナイズは終わりましたが、ヤフーのエンジニアはまだJavaを使いこなせているとは言えません。Javaエンジニアを育成して、JJUG（日本Javaユーザーグループ）にどんどん参加してもらいたいです。ヤフーってJavaに強いよねと言われるようになりたいですね。

寺田：エバンジェリストやアドボケイトという仕事をしていましたが、コロナ禍によりオンラインが主流になるなど、仕事のやり方が大幅に変わりました。JJUGでは昨年12月に、コロナ禍以降、初めてオンラインとオフラインのハイブリッドでイベントを開催しました。このようにオフラインで直接会って、話す機会をもう一度取り戻していく。これが今年の私のチャレンジです。オンラインの良さはあるのですが、対面だからこそできる話の内容があります。そういった個々のニーズに対して応えていくためにも、オフラインで話をする機会を増やしたいですね。

──最後にJava開発者へのメッセージをお願いします。

寺田：開発者には「Engineers can change the world」という言葉を贈りたいと思います。エンジニアはこれからの新しい未来を創り、世界を変えていける貴重な存在です。企業の歯車の一つというエンジニアでも、世界を変えていくだけの力を持っています。自分たちが将来を創っていくんだという気持ちを持って、成長していっていただきたいと思います。

　Javaも一時、終わったと言われた時代がありました。そこからV字回復以上に盛り上がり、世界中の開発者からから注目される言語となっています。Javaでよりよいシステムを作ってほしいですし、すべてのJavaの開発者がそれぞれの環境で幸せになってほしいと思います。

高見：寺田さんがおっしゃるようにエンジニアが世界を変えられる立場です。そしてそれを変えるための有効な手段としてJavaがある。Javaは世界を変えられる道具だと思います。ぜひ、多くの人に活用してほしいと思います。

---

著：中村仁美
写真：丸毛透