OpenShiftで始める企業のコンテナ活用。基礎から導入／使いこなしのポイント、組織体制まで

記事をシェアする:

「デジタル変革を加速するためにアプリケーションの開発／リリースのサイクルをスピーディーに回せるようにしたい」「アプリケーションを物理インフラから切り離し、クラウドなどを柔軟に活用できるようにしたい」といった目的からコンテナの活用を検討する企業が増えています。本記事では、コンテナの仕組みやDocker、Kubernetesといったコンテナ技術の基本、そして企業向けのコンテナ管理基盤として注目を集める「Red Hat OpenShift」を活用する際のポイントや企業にOpenShiftを導入する際の考慮点などについて、書籍『OpenShift徹底活用ガイド』の執筆陣が解説します。

1.コンテナは“インフラとアプリの明確な分離”を初めて実現したサーバー技術
2.コンテナはサーバー仮想化よりもポータビリティーが高く、リソース消費が少ない
3.KubernetesはOSSのコンテナ管理基盤
4.OpenShiftは企業向けのコンテナ管理基盤
5.OpenShiftを使うメリット──より早く、簡単に
6.OpenShiftの提供形態は？ どれを選ぶべきか？
7.既存アプリケーションをコンテナ化する際のポイントは？
8.OpenShiftで運用管理はどう変わるのか？
9.組織／体制をクラウドネイティブにどう対応させるか？

 

 

 

コンテナは“インフラとアプリの明確な分離”を初めて実現したサーバー技術

コンテナとは、サーバー上で高い集約率／リソース効率を実現しながらアプリケーションを動かすための技術です。初めに、従来のサーバー技術と比較しながらコンテナ技術の特徴を説明します。

メインフレームの時代から長い間、企業システムはCPUやメモリー、ストレージなどから成るサーバーという枠組みの上でOSやアプリケーションを動かすという構成でシステムを組んできました。UNIXサーバーやPCサーバーの時代にも、この構成に変わりはありませんでした。

その後に登場するサーバー仮想化技術では、物理的なサーバー上で仮想化した多数のサーバー（仮想サーバー）を動かしますが、仮想サーバーも含めて「サーバーとOS、アプリケーションが1セットで実行される」という構成は同じでした。

この構成に大きな変化をもたらしたのがコンテナ技術です。コンテナ技術の大きな特徴は、これまで1セットだったOSとアプリケーションを切り離して運用する点です。

従来はサーバーとOSのインフラ部分とアプリケーションが1セットだったことから、アプリケーションの開発からデプロイまでの工程にアプリケーション開発部門とインフラ部門という2つの組織がかかわっていました。

これに対して、コンテナ技術ではアプリケーションをコンテナ内にパッケージングすることにより、開発部門だけでアプリケーションの開発からデプロイまでを行い、インフラ部門はインフラの運用管理に集中できるようになります。開発（アプリケーション）と運用（インフラ）を明確に分離し、アプリケーション開発／リリースのサイクルを迅速化できることから、デジタル変革（DX）に力を入れる企業の多くがコンテナの採用を進めているのです。

 

コンテナはサーバー仮想化よりもポータビリティーが高く、リソース消費が少ない

コンテナについての理解を深めるために、サーバー仮想化技術との違いについてもう少し見ていきましょう。

仮想化技術では、ゲストOS内のライブラリー（Windowsの場合ならDLL）を使ってOSの機能を呼び出しながらアプリケーションが動作するため、ライブラリーとアプリケーションの間の互換性が重要になります。例えば、あるアプリケーションが最新のライブラリーを必要とすることからOSをバージョンアップしたところ、同じOS上で動く他のアプリケーションが動かなくなってしまったといったことが起こります。

一方、コンテナ技術ではアプリケーションをライブラリーとセットでコンテナイメージとしてパッケージングし、インフラ（サーバーとOS）から分離してコンテナエンジン（図中のDocker Engine）上で動かします。OSをバージョンアップした場合でもアプリケーションに影響が及ぶことは、ほとんどありません。これにより、コンテナにパッケージングしたアプリケーションはサーバー仮想化よりも高いポータビリティーを備え、多くのプラットフォーム上で実行することが可能となります。

また、サーバー仮想化技術ではCPUやBIOSのエミュレーションが必要なため、仮想サーバーの起動に多くの時間がかかります。それに対して、コンテナはOS内の1プロセスとして実行されるため、数ミリ秒程度で高速に起動します。OSが含まれないので、コンテナイメージのファイルは仮想イメージと比べてサイズが小さいことも特徴です。

 

KubernetesはOSSのコンテナ管理基盤

コンテナ技術の実装プロダクトとしてはオープンソース・ソフトウェア（OSS）の「Docker」がよく知られています。Dockerを使うと1サーバー内で多くのコンテナを動かすことができますが、コンテナの数が増えてくると、やがて1台では足りず複数のサーバーを並べて動かすようになります。ただし、Dockerが対象とするのは1サーバー上のコンテナです。システム規模によっては数百、数千にもなる各サーバー上のコンテナエンジンを個別に管理するのは大変なため、それらをクラスター化して効率的に管理するために開発されたプロダクトの1つが「Kubernetes」です。

Kubernetesは、クラスター管理用の「マスターノード（Master Node）」と個々のコンテナエンジンが動く「ワーカーノード（Worker Node）」などでクラスターを構成します。現在、IBMやRed Hatなど世界中の主要なITベンダーが開発に参加しており、コンテナ管理技術のデファクトスタンダードの地位を確立しています。

また、Kubernetesはコンテナクラスターの管理機能のほかにも、システム負荷に応じてコンテナのインスタンス数を増減させる機能や負荷分散機能など、便利な機能を多数提供しています。

Dockerを単体で使う場合、これらの仕組みは開発者自身が用意しなくてはなりません。それらを提供することによってコンテナをより扱いやすくするプロダクトがKubernetesなのです。

 

OpenShiftは企業向けのコンテナ管理基盤

Kubernetesを使えば複数のコンテナエンジンをクラスター化して扱えるようになりますが、その環境を企業システムとして求められる水準で運用していくためには、システム監視やセキュリティーなどの機能が不可欠です。また、DXなどで迅速にアプリケーションを開発／リリースしていく目的でコンテナを使う場合、継続的インテグレーション（CI）や継続的デリバリー（CD）の仕組みを各種OSSによって構築することも必要です。

これらの作業を一般のユーザー企業が自力で行い、Kubernetesをサポートなしで利用していくためには高い技術力が求められます。例えば、Kubernetesの動作に問題が見つかったら自分で原因を調べて対応し、それが未知の不具合である場合は自分でコードを書いて修正しなければなりません。

また、コンテテ環境はOSとコンテナエンジン、コンテナオーケストレーション、監視など、さまざまなレイヤーから成り、それぞれを構成するソフトウェアの間の互換性を保たなくてはなりません。これをユーザー企業が自ら行うのは大変です。

そこで、Kubernetesに各種の機能を追加して拡張し、企業水準のコンテナプラットフォームを短期間で構築して少ない負担で運用できるようにと登場した商用プロダクトが「Red Hat OpenShift」です。OpenShiftは、大きく次の3種の機能を提供します。

• Cluster Service：コンテナクラスターの監視／管理の機能などを提供
• Application Service：マイクロサービス環境の構築／管理機能などを提供
• Developer Service：アプリケーション開発のためのCI/CDツールなどを提供

OpenShiftは「オペレーター」と呼ばれる管理機能でコンテナ管理の煩雑な作業を自動化しており、利用に際して何か問題が生じた際にはRed Hatのサポートが受けられます。同社がコンテナ環境の各レイヤーの互換性を事前に検証した修正やアップデートのパッチも提供しており、常に品質の高いコンテナ環境を利用することができます。

 

OpenShiftを使うメリット──より早く、簡単に

下図に示すのは、KubernetesとOpenShiftでコンテナイメージを作ってアプリケーションをデプロイするまでの流れを比較したものです。

Kubernetesの場合、アプリケーション開発部門が作ったソースコードと、インフラ部門が作成したDockerファイルを基にして手作業でコンテナイメージをビルドします。次にアプリケーションの実行に必要な設定などを行ったうえでアプリケーションをリリースしますが、通常はこれらの工程に1〜5日のリードタイムがかかります。

一方、OpenShiftでは「S2Iビルダーイメージ」というコンテナイメージの雛型にアプリケーションのソースコードを登録すると、自動的にビルドが行われてコンテナイメージが自動生成されます。

また、インフラ運用部門はテンプレートを使って社内で利用するさまざまなコンテナイメージをカタログ化できます。アプリケーション開発部門はそれらのカタログの中から必要なコンテナイメージを選び、デプロイボタンをクリックするとアプリケーションが自動的にリリースされます。これにより、Kubernetesを直接使う場合と比べてリードタイムを大幅に短縮することができるのです。

さらに、OpenShiftではCI/CDの環境もボタンを1クリックするだけで簡単に作れるだけでなく、CI/CD環境を構成するツールのアップデートも自動的に行われます。さまざまなOSSツールから成るCI/CD環境の管理が不要となり、開発者はアプリケーション開発に専念できるようになるのです。

使用するCI/CDツールに関しても、OpenShiftはさまざまな選択肢を用意しています。

上図の白地で示したツールはKubernetesに備わる機能、青地で示したものはOpenShiftで追加されるCI/CD機能とツールです。企業はこれらの中から自社に適したツールを選び、簡単な操作で高度なCI/CD環境を作れるのです。

 

OpenShiftの提供形態は？ どれを選ぶべきか？

OpenShiftは現在、セルフマネージド（Self-Managed）型とホステッド・サービス（Managed）型の2種類の形態で提供されており、環境構築の方法はそれぞれ異なります。プロジェクトの特性に合ったサービスをお使いください。

• セルフマネージド型：自分でOpenShiftをインストールして環境を作り、運用管理を行う。環境構築や運用管理に手間と時間がかかるが、カスタマイズ性が高く、さまざまなプラットフォームにインストールできる

• ホステッド・サービス型：IBMなどのクラウド・ベンダーがマネージド・サービス（IBMの場合はRed Hat OpenShift on IBM Cloud）として提供するものであり、各社のサービスポータルで注文すると、すぐにインストールが行われてOpenShiftの環境を利用できる

例えば、スモールスタートでスピーディーに進めたければホステッド・サービスが向いていますし、自社で細かくカスタマイズした環境を作るにはセルフマネージド型が必要です。最近は構築や運用管理に割ける人的リソースがないというお客様が増えていますが、その場合はホステッド・サービス型が適しています。

 

既存アプリケーションをコンテナ化する際のポイントは？

既存のアプリケーションをコンテナ化するためにOpenShiftを使いたいというお客様は多いでしょう。その際のポイントは大きく3つあります。

①アプリケーションイメージ（コンテナイメージ）の設計
コンテナは、アプリケーションやライブラリー、ミドルウェアなどとセットでパッケージングしたコンテナイメージから生成されたインスタンスとして動作します。このイメージ・ファイルをどう設計するかがポイントの1つとなります。

従来型のアプリケーションでは、実行に伴って生成されるログなどのさまざまなデータが残ることが普通です。それに対して、コンテナ化したアプリケーションの場合、スケールダウンなどでコンテナインスタンスが削除されると、メモリー上のデータは全て消失します。したがって、消失しては困るデータやログを保存するための設計が必要になります。

②責任分担の設計
前述のように、コンテナはインフラとアプリケーションを明確に分離できることがメリットの1つですが、インフラ部門がミドルウェアまで担当している組織では問題が生じる可能性があります。コンテナではアプリケーションとミドルウェアをまとめてパッケージング（コンテナイメージ化）するため、インフラ部門が引き続きミドルウェアまで担当する場合は、アプリケーション開発部門とインフラ部門の双方がコンテナイメージの管理にかかわり運用が煩雑化する恐れがあります。この場合、担当領域の変更が必要になるかもしれません。

③周辺システムの設計
これまで使ってきた運用管理ツールやジョブ管理ツールが、そのままではコンテナ上で動かない場合があります。OS上でエージェントを動かして監視などを行っていた場合は、監視用サーバーを新たに立てるなどの工夫が必要になるかもしれません。

 

OpenShiftで運用管理はどう変わるのか？

OpenShiftによるクラウドネイティブなアプリケーションの開発／運用では、従来から大きく考え方が変わる部分があります。

▶監視／ロギングの注意点
コンテナをベースにしたアプリケーションは、サーバーの数が動的に増減したり（スケールアップ／スケールアウト）、停止／再起動したりするなど、環境が動的に変わることが大きな特徴です。そのようなアプリケーションを監視するうえで気を付けるべきことは、頻繁に構成情報が変わる各コンポーネントを直接見るのではなく、ユーザーの体験などサービスの健全性や継続性を中心にモニタリングすることです。

ロギングの考え方も変わります。これまでは、何か問題が生じた際にはサーバーにログインして事象を確認するのが一般的でした。しかし、コンテナではサーバーがダウンするとログが消失する場合がありますし、そもそもコンテナインスタンスにログインして操作することは推奨されていません。ログは外部で集約して管理し、それに対してツールなどで解析を行って問題解決を図ることが基本となります。

▶変更管理の注意点
OpenShiftによるコンテナ環境では、変更管理の考え方も従来と変わります。

例えば、これまでのシステム管理では、システムに動的な変更が生じることはなく、設定変更も頻繁に行わないのが一般的でした。

それに対して、コンテナをベースにしたクラウドネイティブなシステムでは動的かつ自動的に構成が変わりますし、アプリケーションも早いペースで改修します。そのため、従来型のシステム環境を前提にした変更管理のアプローチを続けたのでは、クラウドネイティブのメリットを得られない可能性があります。これまでのような静的ドキュメントベースではなく、Infrastructure as Codeのアプローチを取り入れてコードベースで構成や変更の管理を行うことが必要となります。

 

組織／体制をクラウドネイティブにどう対応させるか？

最後に、コンテナを活用したクラウドネイティブなシステムの開発／運用を行う組織／体制について触れておきたいと思います。

次に示す図は、従来型のSoR（Systems of Record）なシステムの開発／運用を行う組織と、SoE（Systems of Engagement）などクラウドネイティブなシステムの開発／運用を行う“モード2”などと呼ばれる組織で重視される価値観や目的、文化などの違いを示したものです。

ご覧のように、それぞれの組織では価値観や文化が大きく異なることを理解するのが大切です。

例えば、「クラウドネイティブの技術を取り入れたが、そのメリットを生かせていない」と悩むお客様の中には、これまでなじんできたSoRの体制や組織にクラウドネイティブの技術や考え方を無理にはめ込もうとしているケースが見られます。この場合、クラウドネイティブの利点であるアジリティーなどが犠牲になる一方、SoRが重視する堅牢性などが損なわれることとなり、結果としてそれぞれの良さが減じてしまいます。

両者は別物と理解し、SoEに関しては別のルールや文化（モード2）を作って運用することが必要だと筆者らは感じています。2つの体制や仕組みを運用するのは効率が悪いと思われるかもしれませんが、最初は分けて運用しながら最終的には2つを融合させる流れで進めることが、すでに確立したSoRのやり方を生かしつつ、新たにSoEの取り組みを進めるうえで有効なのです。

なお、IBＭではコンテナを活用したクラウドネイティブな開発に取り組まれるお客様に対して、さまざまなサービスを提供しています。OpenShiftを使ったクラウドネイティブな開発／運用の仕組みや体制構築のためのクラウド・サービスや構築支援サービスを提供しているほか、それらの取り組みの大本となるDX推進やアジャイル開発の導入などの取り組みもご支援しています。コンテナの活用に関心をお持ちのご担当者は、私たちに何でもご相談ください。

 

関連情報

• クラウド・サービス
• Red Hat OpenShift on IBM Cloud
• クラウド・アプリケーション開発のコンサルティング・サービス
• アプリケーション・モダナイゼーションのコンサルティングとサービス