マイクロサービスと「Red Hat OpenShift Container Platform with Runtimes」の基礎知識

マイクロサービスとは

「マイクロサービス」とは、ソフトウェア開発手法の1つで、システムを疎に結合した複数の小さなサービスで実現します。各サービスはそれぞれ独立して動作するように設計し、Web APIなどを通じてデータのやり取りを行います。

マイクロサービスの一番のメリットは、変更のハードルが低く、日々変化していくニーズへ迅速に対応できるシステムを実現できる点です。マイクロサービスでは、システムを独立したサービスに分割するため、業務変更の影響が独立したサービスの範囲に極小化されます。特に、大規模で肥大化しやすい業務システムをはじめ、柔軟で迅速な変化が求められるようなシステムに有効です。

マイクロサービスの考え方自体は古くから存在していましたが、広く認知されるようになったのはJames Lewis, Martin Fowlerが公開したBlog記事からでしょう。最近ではコンテナ技術の普及やクラウドサービスの発展により、マイクロサービスの実現は容易になってきました。

マイクロサービス導入における課題

マイクロサービスは、柔軟で迅速な変化に対応できるシステムの実現に有効ですが、導入においては以下のような課題もあります。

・リソースの増加
サービスを分割して実装するには、サービスそれぞれにOSやミドルウェアなどのリソースが必要となるため、単純にサービス毎に物理マシンや仮想マシン環境を用意するにはコストがかかります。これらのコストは、膨大なサービスを稼働するうえでは無視できない問題となってきます。

・運用負荷の増大
マイクロサービスでは、業務システムを複数のサービスに分割して実装するため、同時に数十～数百ものサービスを運用・管理する必要があります。これらの膨大な数のサービスを安定稼働させるためには、人手に頼った方法では限界が出てきます。

・多様化・複雑化するランタイムソフトウェア/ミドルウェアの管理
各サービスを稼働するためのランタイムソフトウェアやミドルウェアの管理も問題となってきます。マイクロサービスでは各サービスが独立して開発されるため、利用するソフトウェアやそのバージョン管理による品質維持も重要です。

マイクロサービス導入における課題

マイクロサービスを導入するには、他にも様々な課題に対応していく必要があります。以前よりもマイクロサービスの実現が容易になってきたとはいえ、これらの問題への対処は簡単ではありません。しかし、日々発展していくソフトウェアによって、より良い方向に改善されてきています。

本連載ではマイクロサービス導入における課題を解決し、柔軟で迅速な変化に対応できるシステムを実現するためのソフトウェアを紹介していきます。

コンテナによる課題解決

マイクロサービスに欠かせない技術としてコンテナがあります。コンテナとは、アプリケーションや依存するランタイムソフトウェアを1つに格納したものです。OS上にコンテナ基盤を導入し、複数のコンテナでマシンが持つリソースやOSを区切って利用します。

仮想マシンで一般的なハイパーバイザー型仮想化とコンテナ型仮想化との比較を表に示します。

表：ハイパーバイザー型仮想化とコンテナ型仮想化との比較

	ハイパーバイザー型仮想化	コンテナ型仮想化
起動時間	数分	数秒
イメージサイズ	数GB～数十GB アプリケーションやランタイムソフトウェアに加え、OSも含まれる	～数百MB アプリケーションとランタイムソフトウェアのみ
利用可能なゲストOS	原則自由	ホストと同一
他のプラットフォームへの可搬性 (例：オンプレ⇔クラウド)	多くのケースで何らかの変換が必要	イメージをそのまま利用可能
データの取り扱い	ゲスト占有のストレージに保存	コンテナ内に保存されたデータは終了時に消失 必要に応じてコンテナ外に保存
他のゲストとの関係	個別でOSを持つ 各々に個別で仮想ハードウェアが見える	OSを共有しカーネルレベルでリソースを分離 必要に応じて他のゲストと共有可能

仮想マシン等のハイパーバイザー型仮想化と比較すると、コンテナ型仮想化でもプロセスやファイルシステムへの外部からのアクセス遮蔽は可能ですが、コンテナ内にはOSが含まれない分、サイズが軽量かつ起動が高速となります。

また、コンテナは可搬性が高いため、開発者が自身の開発端末で作成したコンテナをそのままパブリッククラウドへ持っていく、といったことも容易となります。これにより大量のマイクロサービスの迅速かつ効率的な配置やサービス単位での柔軟なスケールが可能となり、マイクロサービスによって得られるメリットを最大限にできます。

一方で、マイクロサービスを導入して生じる大量のコンテナを1つ1つ手作業でデプロイしていては、迅速なリリースの妨げとなってしまいます。そこで、コンテナの管理を省力化するためのツールが必要となります。数あるコンテナ管理ツールの中でも、特にシェアが高いのが「Kubernetes」です。

Kubernetesとは

KubernetesはGoogle社内で利用されていたものをオープンソース・ソフトウェア(OSS)として2014年に公開したもので、現在でもコミュニティにおいて精力的に開発されています。

Kubernetesには以下のような機能が搭載されており、コンテナを管理する運用者の手間を大幅に削減します。

・コンテナ間の通信・ロードバランス
Kubernetes内部でDNSを持ち、コンテナのIPアドレスが変わってもサービス名でアクセスできます。また、1つのサービスに同じ役割を果たす複数のコンテナを設定でき、負荷分散や冗長化が可能となります。

・コンテナ障害時の自動再起動
コンテナが何らかの理由で終了した場合、同じイメージを用いた別のコンテナをすぐに起動できます。

・永続ストレージの割り当て
コンテナの中に保存されたデータは、コンテナが終了すると消えてしまいますが、コンテナ外のストレージをコンテナにマウントすることで、仮にコンテナが終了してもデータを保持できます。

・ロールアウト・ロールバック
1つのサービスを構成するコンテナ群を順次アップデートしていく、といったこともKubernetesでは1ステップで実行可能です。アップデートして問題が発生した場合でも、1ステップで元の状態に戻すこともできます。

・コンテナ配置の指定
Kubernetesは原則として複数のノード(コンテナの配置先)で構成されています。Kubernetesは各ノードの状態を見て、一番余裕がある正常なノードに自動でコンテナを配置します。ノードに障害が発生した場合は、そのノードで稼働していたコンテナを別のノードに自動で再配置します。これにより、ノードに何らかの障害が発生しても他のノードで処理を継続できます。また、必要があればコンテナの配置先を指定することもできます。

・宣言的なAPIによる運用負荷の軽減
Kuberenetesは宣言的(Declarative)なAPIを持っています。利用者がAPIを通じて望む結果をKubernetesに「宣言」すると、あとはKubernetesがその内容に従って必要な操作を自動的に実行します。これにより利用者は結果のみを意識すればよく、結果に至る手順を意識する必要がなくなるため、ある程度マイクロサービスの運用負荷を軽減できます。

マイクロサービスを実現する
ランタイムソフトウェアのニーズの変化

コンテナに格納されるランタイムソフトウェアも、コンテナやマイクロサービスと親和性が高いものを利用する必要があります。

旧来のモノリシック型のシステムでは、TomcatやJBoss EAPなどのミドルウェアが稼働する1つのシステム上に業務を集約したアプリケーションを稼働させる構成が一般的でした。このような使われ方では、稼働するミドルウェア数は多くないため、ミドルウェア稼働に必要なリソース量はそこまで重要視されませんでした。

また、通常ミドルウェアは業務中は常に稼働状態であるため、ミドルウェアの起動性能もそれほど重要視されていませんでした。

一方、マイクロサービスを導入するシステムではコンテナ上で複数のサービスが稼働するため、メモリなどのリソースの消費が少ないものが求められます。

なお、業務中は常に固定数のコンテナが稼働するのではなく、業務中の業務負荷など必要に応じてコンテナ稼働数を調整したり、障害時にコンテナの再起動したりといった運用を行うため、ランタイムソフトウェアの起動性能が業務性能にも直結し、起動性能の高さも求められます。

マイクロサービスを実現する
ランタイムソフトウェア

このようなニーズの変化を背景に、マイクロサービスでは、より軽量で起動性能が高いソフトウェアが利用されてきています。

これまでのエンタープライズシステムではJavaが広く利用されてきましたが、軽量性が求められるマイクロサービスでは、JavaだけでなくNode.jsのようなサーバサイドJavaScriptやGo言語のような、より軽量なマイクロサービスを実現できる技術の活用も進んでいます。

一方で、Javaによるマイクロサービスの実現においても、マイクロサービスに特化したソフトウェアや技術が進化し、軽量なマイクロサービスを実現できるようになってきています。今回は、マイクロサービスをJavaで実現する際の代表的なソフトウェアを紹介します。

デファクトで利用されるSpring Boot

「Spring Framework」は、JavaでWebアプリケーションを構築するためのフレームワークです。Java EE仕様に準拠したアプリケーションサーバがEJBなどの標準化された機能をフルセットで提供するのに対して、Spring Frameworkは必要な機能のライブラリのみを選択して利用できることが特徴で、軽量なアプリケーション構築を中心に活用されてきました。

Spring Frameworkのプロジェクトの1つであるSpring Bootが登場すると、マイクロサービスやクラウドでの利用との親和性の高さから利用が広まり、今日ではマイクロサービスをJavaで開発する際のデファクトのOSSとなっています。

Spring Bootの一番の特徴は、ミドルウェアが提供してきた機能をライブラリ(Jar)の形態でアプリケーションに内包することで、アプリケーションが直接JavaVM上で稼働できることです。単体のアプリケーションとして稼働し、必要なライブラリのみがロードされるため、マイクロサービスに要求される軽量性や起動性能の高さを実現しています。

標準仕様に準拠し高速で動作するQuarkus

Jakarta EE(Java EE)に対して、マイクロサービスの標準仕様に相当する規格がEclipse Microprofileです。CDI、JAX-RSといった最小限必要な仕様のJava EEからの踏襲ではあるものの、Java EE仕様を引き継ぐのではなく、基本的にはマイクロサービス、クラウドネイティブで必要な仕様としてリファインされた規格となっています。

Eclipse Microprofileに準拠したOSSには「Thorntail」などがありましたが、残念ながらSpring Bootがデファクトで活用される一方、Eclipse Microprofileに準拠したOSSの普及はこれからの状況でした。

しかし、最近では高速な起動性能を持つ「Quarkus」の登場により、今後の普及が期待されています。

JavaベースのSpring BootなどのソフトウェアはJava仮想マシン上で稼働するため、ネイティブ実装されたソフトウェアと比較して起動性能に課題がありました。QuarkusはGraalVMによるJavaプログラムをネイティブコンパイルする技術を利用することで、Java言語で実装されたソフトウェアでは実現できなかったネイティブプログラムレベルの起動性能を実現しています。

また、Spring Web、Spring DI、Spring Data JPA、Spring Securityといった、SpringのAPIを利用したアプリケーションと互換性を持つためのExtentionも提供されており、Spring Bootの技術者も比較的楽に移行できます。

2020年4月には、Red Hat社からの商用サポート提供も発表されるなど、今後有望なOSSです。

マイクロサービスとの親和性を高めたJBoss EAP

「JBoss EAP」は、Jakarta EE (Java EE)仕様に準拠したアプリケーションサーバです。

一般的にアプリケーションサーバは省リソースで起動性能を要求されるマイクロサービスには不向きとされていましたが、JBoss EAPはコンテナ上でアプリケーションサーバを稼働する際に弱点となっていた、この問題を独自に解決しています。

元々、JBoss Modulesによる独自のローダーにより、Spring Bootなどの軽量なランタイムソフトウェアと同等の起動性能を持っていましたが(参考)、JBoss EAP 7.3ではアプリケーションが利用しない機能を実行ランタイムから除外する機能も提供され、省リソースで起動性能を要求されるマイクロサービス用途に対応しています。

また、Jakarta EE (Java EE)仕様に加えて基本的なEclipse Microprofile仕様にも準拠しているため、例えば、レガシー資産を延命する部分のマイクロサービス化や、Jakarta EE (Java EE)仕様機能を活用しつつマイクロサービスを実現したい場合には有効な選択肢となるでしょう。

マイクロサービスを実現する
Red Hat OpenShift Container Platform with Runtimes

ここまで、マイクロサービスを実現するためのコンテナやランタイムソフトウェアについて説明しました。しかし、マイクロサービスを実現するためには、これらのソフトウェアだけでは解決できない問題があります。

例えば、各サービスで利用するソフトウェアやそのバージョンの品質管理、継続的な業務改善を効率良く行うための運用支援等が必要になります。これらの問題に対する1つの解として、Red Hat社が提供する「Red Hat OpenShift Container Platform with Runtimes」があります。

以降では、Red Hat OpenShift Container Platform with Runtimesに含まれる「OpenShift」(Red Hat OpenShift Container Platform)と、「Red Hat Middleware」について紹介します。

OpenShiftとは

OpenShiftは、Kubernetesをベースにエンタープライズにも適用できるように機能拡張したコンテナ管理ツールです。OpenShiftにはKubernetesで提供されている機能に加えて、ログ収集(EFKスタック)やメトリクス監視(Prometheus)、OTA(Over-The-Air)によるOpenShift環境のローリングアップデート等をはじめとした基盤管理を実現する様々な拡張機能があります。

これら機能の中でも、本連載ではマイクロサービスの開発に関わる「CI/CD」(Continuous Integration/Continuous Delivery)と「Service Mesh」について詳しく解説します。

OpenShiftとは

・CI/CD(Continuous Integration/Continuous Delivery)
継続的にアプリケーションを改善しリリースしていく上では、アプリケーションのビルド、テスト、デプロイおよびリリースのサイクルを迅速に回す必要があります。OpenShiftでは、これら一連の流れを自動化するCI/CDの仕組みが複数準備されています。これにより、品質を落とさずにアプリケーションのライフサイクルを迅速に回すことができます。

・Service Mesh
マイクロサービスで構成された各サービスは独立して稼働しています。アプリケーションの実行時には独立した各サービス間で通信し、リクエストを処理していきますが、各サービス間の接続やトラフィック、セキュリティ等を設定する必要があります。OpenShiftではOSSのIstio、Envoy、JaegerなどをベースとしたService Meshを提供しており、これらを利用して接続状況の管理やトラフィック監視を容易に整備できます。

Red Hat Middlewareとは

マイクロサービスでは、サービス毎に必要なソフトウェアを選んで開発できることもメリットの1つですが、実際にはプロジェクト横断で利用するソフトウェアやそのバージョンを一定管理しなければうまくいきません。利用するソフトウェアを選定してナレッジを集約化したり、複数バージョンや品質の安定していないバージョンの利用を避けたりする必要があります。

Red Hat OpenShift Container Platform with Runtimesで提供されるRed Hat Middlewareでは、Red Hat社が選定したマイクロサービス開発に必要なランタイムがセットで提供されており、ソフトウェアの選定とバージョン管理を個別に意識したくない場合には有効な選択肢となります。

また、Red Hat MiddlewareにはSpring BootやQuarkus、JBoss EAPといったマイクロサービスを実現する際のランタイムに加えて、「Red Hat AMQ」などマイクロサービスの連携に必要なランタイムソフトウェアがセットになっています。

＊　＊　＊

今回は、マイクロサービスとそれを取り巻くソフトウェアについて紹介しました。次回は、実際にマイクロサービスの作り方を紹介します。