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を共用する。一方、コンテナアプリケーションではコンテナ1つ1つにIPアドレスが付与される。1つのVM上でも、コンテナが変われば個別のIPでアクセスできる。
 
 

ハイブリッドクラウドと
マルチクラウドでのコンテナの価値

 
 企業のITインフラとしてクラウドを利用する場合、現時点でもそれぞれの強みに応じて複数のクラウドベンダーを使い分けるユーザーが増えている。今後、複数のパブリッククラウドやオンプレミスのプライベートクラウド化がますます進むと予想される。このようなインフラ環境下で、最も重要なのが標準化である。
 
 現状では、クラウド各社やプライベートクラウド、オンプレミス間で利用できるAPIや運用管理ツールは固有で、共通性のないことが多いため、稼働環境が増えるたびに固有のIT管理コスト(スキル・運用)が発生する。今後の企業価値を決定づけるアジャイルやCI/CDを進化し続けるには、ITインフラ運用管理を限りなく省力化する必要がある。Kubernetesはオンプレミスのプライベートクラウドを含むマルチなハイブリッドクラウド環境で、個々の独自性を隠蔽抽象化し、標準化を実現する(Column 3)。
 
 

 

著者|

佐々木 幹雄

 
日本アイ・ビー・エム株式会社
システム事業本部 Power Systemsテクニカル・サポート
コンサルタントITスペシャリスト
 
AS/400誕生とほぼ同時期からIT業界に関わる。IBM i やPC、ネットワーク機器など一般企業のIT基盤の提案・構築、アーキテクトなどを幅広く経験。IBM i エバンジェリストとしての活動もある。
 

 

・・・・・・・・

特集|IBM iのマイクロサービス化

 
 
 
 
 
 
 
・・・・・・・・
 

Column 1 OpenShiftかKubernetesか
Column 2 どこでもKubernetes
Column 3 ミドルウェアのコンテナ化対応
Column 4 SCNは戦略策定のためのフレームワーク
Column 5 ハイブリッドクラウド移行(中期)計画を作る
Column 6 アジャイルはSoEだけのものか?
Column 7 IBM iサービスとDb2 for iサービス
Column 8 IBM iのクラウドサービス
Column 9 コンテナテクノロジーを導入しても、イノベーションは起きない

[i Magazine 2020 Spring掲載]