Java EEを“クラウド・ネイティブ”にするために必要なこと──開発責任者のアニール・ガー氏が語った

Oracle Java & Developers編集部
2017-01-05 14:00:00
  • このエントリーをはてなブックマークに追加

クラウド時代を支えるプラットフォームとなるために、Java EEはどうあるべきか──2016年12月に都内で開催されたイベントのために来日したJava EE開発責任者のアニール・ガー氏が、日本の開発者に直接説明した。

クラウド・ネイティブ時代の鍵を握るDevOpsとマイクロサービス


米国オラクル オラクル・クラウド・プラットフォーム/アプリケーション・デベロップメント担当バイスプレジデントのアニール・ガー氏

 2016年9月に米国サンフランシスコで開催された「JavaOne 2016」において、米国オラクルはJava EEをクラウド時代にふさわしいプラットフォームにすべく新たな提案を行うと発表した。マイクロサービスやDevOpsなどの新たな技術潮流の重要性が高まる中、Java EEではそれらにどのようなかたちで対応していくのか。2016年12月、米国オラクルでJava EEの開発を統括するアニール・ガー氏が来日し、都内で開催されたイベント「Javaで創るクラウド時代のエンタープライズ開発 ~マイクロサービス、DevOpsとJavaの最新動向~」(日本オラクル主催)の基調講演でオラクルの提案の狙いと、その詳細を解説した。

 基調講演の冒頭、ガー氏はまずアプリケーション開発の領域における近年のトレンドに触れながら、次世代のイノベーションを担う鍵となる“クラウド・ネイティブ”を中心に話を展開した。

 ガー氏によれば、昨今のエンタープライズ・アプリケーション開発のターゲットは、大きく3種類に分類される。

 「今日、多くの企業は異なる性格を持つ3種類のソフトウェアを開発/運用しています。1つは変化の少ないレガシーなソフトウェア(Core Software)、2つ目は既存のビジネスを支えているソフトウェア(Differentiation Software)、そして3つ目は市場の変化にいち早く対応しながら次世代のイノベーションを作り出していくソフトウェア(Innovation Software)です」(ガー氏)


※クリックすると拡大画像が見られます

 これらのうち、現在、特に重要性が高まっているのが、3つ目のイノベーションを生み出すソフトウェアの領域だ。この領域では、クラウドの潜在能力を最大限に活用できるクラウド・ネイティブなソフトウェアが活躍するとガー氏は話す。

 それでは、クラウド・ネイティブなソフトウェアとはどのようなものなのか。これは「クラウドの潜在能力を最大限に引き出す新たなスタイルのアーキテクチャに基づいており、次のような要素によって特徴付けられる」(ガー氏)という。

  • DevOps
  • * as a Service
  • マイクロサービス
  • 分散コンピューティング

※クリックすると拡大画像が見られます

 ガー氏は、上記4つのうち、特に「DevOps」と「マイクロサービス」について、その本質を詳しく説明した。

DevOpsのための開発/運用環境の整備も必須。マイクロサービスへの取り組みでは組織構造にも注意

 まずDevOpsだが、これはクラウド・ネイティブなソフトウェアを構築/運用するうえで不可欠な要素となる。今日のビジネス要求に応えるためには、ソフトウェアをより早く開発し、細かな修整を適時加えることが重要となっているが、従来の開発手法や環境でそれらを合理的に実現するのは困難である。DevOpsでは、開発/運用環境についてあらゆる工程を自動化し、継続的なデプロイメントを実現しつつ、ソフトウェア開発と運用とを同じ視点で測定/評価し、チーム内の課題解決を実現していく。

 また、ガー氏は「信頼性についてどのように考えるかも大きな課題です」と指摘する。エラーへの対処法を十分に検討し、動的に解決していく必要がある。さらに、サービスは基本的にステートレスで作り、ステートやコンフィギュレーションはサービスの外部で管理するような構成が望ましいという。


※クリックすると拡大画像が見られます

 クラウド・ネイティブなソフトウェアには、新たな機能をできるだけ早くリリースし、何度も作り替えていくための開発プロセスが必要になる。このようなソフトウェアのアーキテクチャに適しているのが、アプリケーションを小さなサービスの集合体として構成するマイクロサービスである。

 加えて、ガー氏は「Conwayの法則」を例に挙げながら、「マイクロサービスへの取り組みを成功させたいと考えるなら、組織の構造にも注意を向ける必要があります」と促した。Conwayの法則とは、「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というものだ。

 「ソフトウェアは、ユーザー・インタフェース(UI)、アプリケーション、データ・ストア、インフラといった具合に階層化された構造を持ちます。モノリシックなアプリケーションの場合、各階層ごとに担当するチームが分かれるケースが多いでしょう。しかし、このようなチーム構成は、チーム間で意思疎通の齟齬や問題解決の優先度の違いなどを生じさせ、結果として生産性が低下しやすいのです。

 それを避けるために、マイクロサービスの開発では、全ての階層を担当する小さなチームが沢山存在するような組織構造にすべきです。この場合、チーム内でサービスに関する全ての問題を解決できるため、素早いレスポンスを発揮することができるでしょう」(ガー氏)


※クリックすると拡大画像が見られます

 ガー氏は、企業がマイクロサービスに取り組むきっかけにも言及した。これについては、次の3パターンが考えられるという。

  • (1)既存のアプリケーションを複数のマイクロサービスに分割する
  • (2)既存のアプリケーションに、マイクロサービスによって機能を追加する、または置き換える
  • (3)全く新たなアプリケーションをマイクロサービスで作る

 (1)は改修の規模が巨大になるため推奨しないが、シンプルなアプリケーションならば選択の余地がある。また、(2)は長期的なマイグレーションに向けた現実的なアプローチだと言える。そして、企業が新たなサービスを始める場合、当然ながらマイクロサービスを選択すべきである(3)。

 開発者の中には、1つのマイクロサービスのサイズはどの程度が適切かで悩む方もおられるだろう。ガー氏によれば、これに対する明確な解はないが、個人的な経験では1つのチームが7、8人で構成される程度の大きさが理想的だという。

 マイクロサービスのパッケージングおよびデプロイについては、それぞれのサービスを個別にパッケージングして専用のコンテナで展開するのが基本となる。アプリケーションの実行に必要となるものは、JVMも含めて全てコンテナ内にパッケージングされ、コンテナ単位で管理される。


※クリックすると拡大画像が見られます