マイクロサービスの“アレコレ”を徹底討論、最適解は本当にJavaなのか?
- ありがとうございます!
- いいね!した記事一覧をみる
マイクロサービスについて、本当にユーザーは理解しているか?
まず製品ベンダー代表のレッドハット 須江 信洋氏が「残念ながら日本の開発現場では、マイクロサービスを使い熟すケースはそれほど多くないようです」と実情を語った。
「アプリを小さくして組み合わせ、柔軟な組成でビジネスを動かすマイクロサービスですが、日本ではエンドユーザーがSIerに丸投げすることが多く、要件定義だけで内容までは興味を持ちません。SIerも従来通りモノリシック(注1)に作ったほうがラクという話になってしまいます」(須江氏)
続いて、日本オラクルの古手川 忠久氏が「お客さまはマイクロサービスの技術や方法論をある程度は理解されていると思います。ですが、既にモノリシックなシステムを抱えている現状では、マイクロサービスを活かせる場所がないと感じているようです。とはいえライフサイクルが異なるフロントとバックに分けて開発する動きも一部にあります。ただ、それをマイクロサービスと呼ぶのは少し違うかもしれません」と感想を述べた。
これを受け、Javaコミュニティ代表のロジ子さんが「マイクロサービスは理解されていますが、うまくつながっていません。モノリシックなJavaEEからアプリを切り出せず、結果的に大きなコンテナが動いているだけです。ただ徐々にアプローチとして進んでいくでしょう」と、ユーザーの立場から発言した。
どういうアプローチでマイクロサービスの導入を進めるべきか?
上田氏は「マイクロサービスの状況については、皆さんほとんど同じ意見だと思います。しかし、このまま放っておくこともできません。そこでJavaEEを中心としたエンタープライズシステム向けに、マイクロサービスを導入する場合、どんなアプローチが良いか教えてください」と質問を投げかけた。しかし同氏は「マイクロサービス化のためのアプリ分解は、実はそれほど難しくないと思います。アプリとデータとビジネスをモジュラー化し、疎結合でデザインしないと、マイクロサービスの良さが生きてきません。そこで私が最近たどり着いた1つの結論が“ドメイン駆動設計”という手法です。それを利用して、ビジネスレベルから、きちんと疎結合のアーキテクチャを考えるべきでしょう」と自論を展開した。
これに上田氏も「DDD(Domain-Driven Design)を使うわけですね」と同意した。
一方、古手川氏は「最近一番ピンと来たのは、ある書籍に“マイクロサービスはスイッチではなくダイヤルです”と書いてあったこと。オン/オフでマイクロサービス化するのではなく。ダイヤルのように一番良い場所に合わせていくことがポイントになります。マイクロサービスにも良し悪しがあるので、どうツマミを回すのか、お客さまと一緒に考えることが大事。むしろベンダーが、モノリスとマイクロサービスが共存する新しいIT世界を補完できるようにしないと、マイクロサービスが定着しないと思います」と違う角度で考えを披露した。
上田氏は「確かにそういう選択肢もあります。何でも大きなシステムにマイクロサービスを使うのは違うかも」と納得し、実務で手を動かすコミュニティの意見を訊ねた。
ロジ子さんは「須江さんが言うように、あくまでマイクロサービスは手段で、マイクロサービスが正しく、モノリスは駄目というのは極論です。必要に応じて適切なアーキテクチャで作ることが重要。私たちも、仮にお客さまがマイクロサービスにしたいと要望しても、適さなければ軌道修正することを心がけています」と強調した。
マイクロサービスを後押しするためのユーザーの支援
もう1つのポイントとして、上田氏は「最終的にはユーザーが理解していることが大事」とし、「何か支援や後押しする活動はしていますか?」と三者に訊ねた。須江氏は「パートナー向けトレーニングとして、今年から多くの無償eラーニングコースを提供しています。コミュニティ活動を重視し、無料のハンズオンやマテリアル、OpenShift(注2)や、Apache kafka(注3)などの環境も積極的に使えるように、敷居を下げていく活動を展開しようと考えています」とオープンソース企業としての支援を明らかにした。
注3 Apache kafka:大規模ストリームデータを扱える分散メッセージングシステム。
ロジ子さんは「ユーザーグループでナイトセミナーをやっています。マイクロサービス関連やJavaゴリゴリの濃い話もあります。開発言語やフレームワーク、SpringBootやSpringFramework(注4)など、いろいろなセミナーも開催しているので、そういうところで勉強していただければと思います」とコミュニティ活動を紹介した。
マイクロサービスの開発にJavaは本当に適しているのか?
その上で上田氏は「ではマイクロサービス向きの言語は何でしょうか? 今回の討論テーマは、マイクロサービスに対するJavaの最適解ですが、本当にJavaが良いのでしょうか?」と各人に疑問を投げかけた。古手川氏は「まずナレッジを持つ技術者が多く、マイクロサービスの多くの先駆者がJavaベースで開発している事実があります。Javaはエコシステムが良くて、優秀なIDEや、気の利いたライブラリもあります。開発スピードやトータルコストなども含め、大規模なほどメリットが出ます。ベンダー非依存で整理されたAPIを体系的に決めて尊重するJavaの風土もあります。マイクロサービスにはMicroProfile(注5)があり、ベンダーロックインもされません」とJavaの優位性を強調した。
一方、須江氏は「実はスタートアップで仕事をしていたとき、一度Javaに絶望しました。マイクロサービスのプロセスチェーンが20や30という数になるとメモリ効率が悪くなるからです。諦めてJavaScriptやPythonで開発した時期がありましたが、それもハッピーではなく、Javaのライブラリのほうが充実していることが分かりました。基幹システムでJava以外の言語を使うなら、覚悟とノウハウと人が必要です。最近はGraalVM(注6)を使ったネイティブ・イメージ化によって起動速度やメモリ消費量の問題も解決でき、改めてJavaに再度ベットするのも悪くない選択肢だと思います」と自身の経験を交えて説明した。
マイクロサービスとJavaが向かっていく方向性とは?
最後に上田氏は「これからマイクロサービスやJavaが発展していくにはどうすべき?」と、今後の展望について各人に訊ねた。須江氏は「やはりエンタープライズ系の開発者が、まだマイクロサービスを十分に体感できておらず、自分の道具箱に入ってない印象です。まずは怖がらずに、ちょっと使ってみましょう。小さいプロジェクトからでも良いので、実際に触れて勘所をつかむ経験を積んでみると良いでしょう。すでに新たな選択肢があり、自分のシステムがもっと改善できる余地があると気づいていただければうれしいですね」と見解を示した。
古手川氏は「マイクロサービスはスイッチではなくダイヤルだと言いましたが、そのメリットとデメリットの両方に向き合い、見極める目を持つことが重要です。今後は何かしらの形でマイクロサービスを検討しなければなりません。しかし勘違いしてはいけない点が、マイクロサービスは手段であり、目的ではないので、その辺のバランスよく考えること。そういう意味でオラクルをアドバイザー的に位置づけていただけるように、我々も日々精進しています。いずれにしてもモノリスとマイクロサービスの混在環境をうまくまとめられるソリューションを紹介していけるように頑張っていきたいです」と抱負を語った。
ロジ子さんは「皆さんの仰せの通りで、あくまでマイクロサービスは実装手段であって、目的ではありません。新しいものは触りたくないという方々もいらっしゃいますが、触ってみないと評価もできませんので、食わず嫌いにならず、選択肢の幅を広げてください。ベンダーさんが講座やセミナーやハンズオン的なものを提供しているので、ニュートラルな立場でのマイクロサービスを一度試してメリットを実感していただき、使うかどうかの判断をする理論武装をして、お客さまと対峙してほしいと思います」とアドバイスした。
最後に上田氏は「我々のようなユーザー企業に求められるものは、専門的な知識よりも皆さんが指摘した“道具”を選ぶことでしょう。いわばワインのソムリエみたいな仕事」と語る。
「ソムリエは、料理や雰囲気に合うワインを選びます。マイクロサービスも同様です。最低限の知識を持ちつつ、ぜひテイスティングをしてもらいたいです。またシステムはカットオーバー後が本番なので、メンテナンスビリティも大切。そういう面も考慮に入れて、モノリスを続けるのか、一部をマイクロサービス化するのか、ユーザー企業側で判断すべきでしょう。業界を引っ張っていくベンダーやコミュニティの方々と手を携えながら、マイクロサービスとJavaで業界が盛り上がっていければうれしいですね」(上田氏)
本セッション含め、「Oracle Developer Days 2022 Spring」のセッション動画や各資料はアーカイブサイトにて公開中(登録不要)
▶︎ Oracle Developer Days 2022 Spring アーカイブサイト