Part2 ： マイクロサービスの基礎知識～アプリケーションをコンテナ化する価値と特徴

 

　マイクロサービス化したアプリケーションは、コンテナ上で稼働する。コンテナはよく仮想マシン（VM）と比較される。仮想マシンのハイパーバイザーに相当するのが、コンテナとなる（図表1）。

 

 

 

　コンテナ内に、アプリケーション実行に必要なソフトウェア一式（アプリケーションとJavaクラスライブラリなど）をパッケージ化して各実行環境へ配布する。

 

　コンテナで最もメジャーなのはDockerだが、最近はそれ以外のコンテナ（たとえばcontainerd、rkt、cri-oなど）も普及の兆しがある。

 

　大雑把に説明すると、コンテナはコンテナアプリケーションの稼働に必要なロジックや機能だけをパッケージしている。コンテナアプリケーションを実環境で業務稼働させる際には、図表2のようにさまざまなインフラ機能をコンテナの外で実装する必要がある。

 

 

 

　コンテナをシステム的に実行するのに必須の機能群は、コンテナオーケストレーションと呼ばれるソフトウェアで提供される。コンテナオーケストレーションとして最もメジャーなのが、Kubernetes（省略形k8s）である。Kubernetesはオープンソースソフトウェアのため、OSS文化やスキルにある程度精通した技術者が必要だが、そのハードルを下げ、高品質でKubernetesを業務運用するために、ベンダーが技術サポート付きでKubernetesをパッケージ化して販売している場合もある。代表例はRed Hat社のOpenShiftである（Column 1）。

 

　Kubernetesの管理するコンテナは、一般的にはLinuxベースのOS上で稼働する。現在では主だったクラウド基盤上のほとんどで、Kubernetesがサポートされている。Power Systemsの場合はRHEL（Red Hat Enterprise Linux）とAIX上での稼働がサポートされる。IBM i上ではKubernetes、Dockerともに現時点でサポートされていない（Column 2）。

 

 

 

　アプリケーションをコンテナ化する意義を、図表3で説明する。

 

 

 

　たとえば仮想サーバー上で実行するレガシーなJavaアプリケーションはEARファイル形式で構築されるが、このEARアプリケーションを実行するには下層の実行環境となるサーバーOSとJDK、Javaクラスライブラリを稼働環境ごとに同一に揃える必要がある。

 

　これに対してコンテナ化したモダナイズJavaアプリケーションの場合、配布するアプリケーションイメージが実行に必要なモジュール一式を含んでいるため、コンテナが稼働するLinuxなどのOSがあれば、どこでもアプリケーションを実行できる。

 

　コンテナでモダナイズされたアプリケーションは、環境依存性が最小化される。これは複数クラウド、オンプレミス間でのアプリケーションの移植性を高めるだけでなく、従来の開発でよく問題になる本番環境とテスト環境、開発環境の予期しない差異（たとえば特定ソフトウェアのバージョンが違うなど）に起因したトラブルの防止・撲滅、インストールする環境ごとにパラメータを適正に修正する作業工数やミスの排除にも貢献する。

 

　コンテナ化を別な視点で見ると、「アプリケーション実行環境の分界点が移動すること」とも言える。レガシーなアプリケーションではOS＋アプリ実行必須スタック（JDKなど）とアプリケーションモジュールとに分離していたものが、コンテナの場合はアプリケーションモジュールの下位層はLinuxとDockerのようにより汎化された要件で済み、インフラ構築・保守の複雑さを簡素化できる。

 

　コンテナ化した場合の考慮点としては、配布するアプリケーションイメージのサイズが、従来のEARファイル（KB単位）などに比べて、コンテナでは100MB以上と飛躍的に大きくなる点に注意が必要である。

 

 

 

　コンテナ（デファクトであるKubernetes）の価値を以下にまとめる。

 

 

・ 「Build once、run anywhere」アプリのインフラ依存性を排除する
・ 固有の（開発・運用）スキルを排除し標準化する

 

 

・ アプリケーションのインストール時に、環境に合わせて設定するパラメータを減らし単純化する
・ 動作環境を意識せずに、どこでも動くアプリケーションを構築できる

 

 

・ 環境構築時間の削減と標準化を推進する

 

　もう1つ、レガシーなアプリケーションとコンテナ化したアプリケーションの差異として、アプリケーションがアクセス可能なIPアドレスにも違いがある（図表4）。

 

 

 

　レガシーなアプリケーションではVM（OS）レベルでIPアドレスが付与され、OS上で稼働する複数のアプリケーションはそれらのIPを共用する。一方、コンテナアプリケーションではコンテナ１つ１つにIPアドレスが付与される。1つのVM上でも、コンテナが変われば個別のIPでアクセスできる。

 

 

 

　企業のITインフラとしてクラウドを利用する場合、現時点でもそれぞれの強みに応じて複数のクラウドベンダーを使い分けるユーザーが増えている。今後、複数のパブリッククラウドやオンプレミスのプライベートクラウド化がますます進むと予想される。このようなインフラ環境下で、最も重要なのが標準化である。

 

　現状では、クラウド各社やプライベートクラウド、オンプレミス間で利用できるAPIや運用管理ツールは固有で、共通性のないことが多いため、稼働環境が増えるたびに固有のIT管理コスト（スキル・運用）が発生する。今後の企業価値を決定づけるアジャイルやCI／CDを進化し続けるには、ITインフラ運用管理を限りなく省力化する必要がある。Kubernetesはオンプレミスのプライベートクラウドを含むマルチなハイブリッドクラウド環境で、個々の独自性を隠蔽抽象化し、標準化を実現する（Column 3）。

 

 

---

 

佐々木 幹雄

 

PART 1　DX推進に向けた基幹システムの対処法
DX推進に向けた基幹システムの対処法 ～クラウドネイティブな手法でモダナイズする

 

PART 2　マイクロサービスの基礎知識
アプリケーションをコンテナ化する価値と特徴

 

PART 3　IBM iマイクロサービス化の進め方
基本はRESTの付加とサービス粒度を考慮したプログラム分割

 

PART 4　IBM i資産をREST化する手法
統合APサーバーを活かしたREST化からリファクタリングの注意点まで

 

PART 5　IBM i開発手法のモダナイゼーション
IBM i アプリケーション開発環境をDevOps化する

 

PART 6　IBM i マイクロサービス化のゴール
ハイブリッドクラウド化とマイクロサービス化でDXを目指す

 

････････