2019年、IBMの社員としてKubernetesの普及と提案活動に携わる中（業界の人々と会話し、海外出張し、英語や日本語のドキュメントを読みあさり、講演したり、本やブログを執筆する中で）で感じたことを書いてみたが、いろいろ整理できていない脈絡のない記事になってしまった。

注意：これは個人の見解であり勤務する会社を代表するものではありません。

2019年 Kubernetesの現状

Kubernetesは、CNCFのプロジェクトとして始まって、まる4年が経過した2019年12月までに、参加企業が500社を超え、目ざましい拡大を果たしている。ITビジネスの先進的企業が使用するアップストリームのKubernetesの発展だけでなく、クラウド事業者大手 AWS,Azure,GCP,Aribaba,IBM Cloudなどが、Kubernetesに対応するサービスを提供している。さらに、2019年末の時点では企業の情報システムのユーザーが安心して利用できるサポートが得られるKubernetesをコアとする製品が出揃ったと言える。

現在、Kubernetesで成果をあげている日本企業は、ECサイト、ソーシャルコミュニティ、コンテンツ提供と広告宣伝などのインターネットでビジネスを展開する企業が中心であり、その特徴は以下と言える。

ユーザーの多くがスマホやタブレットからアクセスするため同時アクセス数が大きい
ラッシュ時、交通機関のトラブル時、悪天候時など、ピーク性が極めて高い
新規コンテンツ開始や既存コンテンツ更新が頻繁
一つのサイトの中に複数のサービスが混在
サイトがアクセスできないと企業ブランドにキズがつくなど、企業価値を左右するため責任重大
ユーザー同士のコミュニティとして、同報通知、チャット、音声通話など多彩なサービス提供
ユーザーの行動特性を分析しての広告宣伝配信などが、一つの収益源となっている

この様な企業では、コンテナの運用基盤を利用することで、仮想サーバーで構築する配信基盤と比べても、サービス運用業務の負荷軽減に成功している。

ハードウェアや仮想サーバーからアプリケーションを隔離して、可搬性やスケールの容易性を高める
コンテナ化によりアプリケーションの安定性が向上し障害を減らせる
メトリックス、ログなどのモニタリングや分析といった業務を集中管理することで管理工数を削減
コンテナのオーケストレーターは、SDS,SDNなどと連携して、実行基盤構築を自動化
CICDの仕組みと連携して、リリースの自動化や、ロールバックなどが容易になる
サービスメッシュやゼロダウンスケールなどの機能が追加され、マイクロサービス化の敷居が低くなる
クラスタの仮想化により、平行開発用やテスト用で、本番と同じ条件の環境構築が容易になる

この次の段階として、2020年は企業の情報システムによるKubernetes導入が、ますます活発になることを願いたい。

情報システム部門が、Kubernetesを本番環境として活用する際の課題

クラウドとソフトウェア製品の事業者の期待とはうらはらに、IDCの調査によれば、注目されているほど企業の情報システムにおいて、DockerコンテナやKubernetesの本番導入は進んでいないとのレポートがある。この本番導入が進まない原因となる課題について、IDC調査結果[1]などを踏まえながら考えてみたい。

調査結果、概況

IDC調査結果の概要として、主要 3点で、まとめると以下のようになった。

Dockerコンテナは導入構築やテスト/検証に時間を要し、本番運用になかなか移れていない状況
45.5%が、アップストリームKubernetesを使用し、次いで、19.8%が、RedHat OpenShift を使用
オンプレミスが45.5%、IaaSが31.4%、PaaS/CaaSが23.1%となり、IaaSとPaaS/CaaSを合わせると54.5%となり、クラウドサービスを利用する割合が半数。同社が2019年4月に国内の企業及び組織468社に対してアンケート形式で実施。

企業の情報システムでは、本番運用に踏み出せないという実態は、筆者の現場感覚とも一致しているように感じる。

調査結果導入動機

この時期に、企業の情報システム部門が、なぜKubeneteの導入に踏み切ったのか興味深い。その主な導入動機は、アプリケーション開発にコンテナを導入した結果、サービス運用もKubernetesにするという流れのようだ。これはハンズオン研修の参加者の反応からも、同意できる調査結果である。

インフラの使用効率向上とコスト削減
アプリケーション開発者の生産性の向上
アプリケーションの信頼性/可用性の向上
アプリケーション運用の効率向上とコスト削減
アプリケーション開発/リリーススピードの向上

海外の状況（個人的な理解）

2019年5月のバルセロナで開催された KubeCon Europe 2019 で、たまたま話をした米国人は、カード決済の有名な会社の情報システム部門の社員だった。彼は自社での実績は無いと語っていたが、Kubernetesについて非常に良く調べており、その知識に関心させられた。そこで不思議に思い「それほど理解しているのに、どうして、Kubernetesを導入しないのか?」と訪ねたところ、「既存システムを変更することは適切では無いので、適用可能な新しいシステム構築の機会があれば取り組みたい。現在はそのための情報収集なんだ」と答えてくれた。この話で、全てが同じという訳では無いが、日本の状況を考えても、そのような様子を伺い情報収集するユーザー企業は多いと思う。

話は変わって、CNCFが2400人を対象に、2018年にまとめた調査レポート[2]について、興味深い点を列挙してみた。

導入前のリリースサイクル 1〜2回／年であった。Kubernetes導入後は、毎週(20%)、毎月(18%)、毎日(15%)、随時(14%)に増えた。
リリースの方法として、自動化されている(42%)、手作業(27%)、自動と手動のハイブリッド(25%)となっている。
リリースのツールは、Jenkins (70%), Terraform(27%)
Kubernetesクラスタのノード数 6〜20 (16%), 21〜50(14%),51-100(11%)
調査対象者が、どこでKubernetesを使っているか? パブリッククラウド(77%), オンプレミス(64%),プライベートクラウド(50%)

断片的な情報であるが、リリースサイクルを短く頻繁に実施したい要求に対してKubernetesが導入され、CIツールを利用して自動化する。そして規模としてノード数では6〜100ノードで構成される規模が約40パーセントとなる。

日本企業の情報システムでコンテナの導入を阻む理由

日本企業の情報システムの方々と、Kubernetesやコンテナの導入の課題について、意見を交換したことによって、以下の様な課題があるように思う。

企業情報システムでは、コンテナを適用するのに適切な新規アプリケーション開発が、たくさん有る訳ではない
既存システムのモダナイズでは、これまで積み重ねた実績のある運用を、コンテナに合わせて変更することが困難である。
既存システムのサーバー運用とコンテナ運用では、考え方が大きく異なるが、懸念事項を払拭できないために開始できない。
コンテナの運用は、社内エンジニアがOSSを組み合わせて構築するなど、企業情報システムに馴染みのないカルチャーがある。
企業情報システムでは、アプリケーションごとに担当するベンダー決まっており、ベンダーの能力によってはコンテナ化が進まない。
アプリケーションの開発を外部委託する場合、CICDは予算内で要件を満たせるかの見積もりが難しいため、採用が難しい。

インターネット・ビジネス企業と比較すると、企業の情報システム部門では、それほど強くコンテナ活用の必要性を実感していない。また、外部依存体質がコンテナ活用の推進を不要なものにしているという印象を受ける。しかしながら、海外の例から、DevOpsの取り組みと合わせて導入することで、リリースの負担が軽くなることから、企業の俊敏性の一つが改善されるとも言える。

コンテナ化推進検討の失敗例

筆者が大企業の情報システムの責任者と対話する中で解ってきたKubernetesやコンテナの導入が進まないという「コンテナ推進検討の失敗例」について触れておきたい。

クラウドネイティブ技術は、過去からの反省を元に開発されてきたものであり、優れた効果が得られる技術である。しかし、決して万能ではなく、未成熟な部分も少なくはない。そのため、対象とするアプリケーションが適切なものであるか、良く吟味する必要がある。さらに、コンテナは、DevOpsやCICDを実践することなしに、導入の利点を理解することはできない。そして、既存のレガシーなアプリケーション開発とサーバー運用のスタイルを踏襲していたのでは、運用の手間が増えるだけで、成果を得ることができない。さらに、アプリ開発の生産性向上やシステム運用者の負担軽減こそが、重要なテーマとなるべきであるが、競合製品同士の不毛な機能比較となってしまう。

ここに挙げた失敗例は、簡潔にまとめて、箇条書きにする。

複雑で依存関係が多いステートフルなワークロードを適用対象に選定する
十分なCI/CDやDevOpsの経験がないまま検討を進める
クラウドネイティブの考え方を学ばず、現状の運用の考え方に当てはめようとする
アプリ開発者とシステム運用者が参画せず、ツールの機能比較で検討が進む

K8sを企業情報システムで導入するロードマップの提案

筆者が、Kubernetesの導入について、サポートしてきた経験から、企業の情報システム部門がコンテナ化を推進して、Kubernetesで本番運用するまでの一般的共通的なロードマップについて、提案を試みてみたい。

Kubernetesは画期的なツールである反面、本番運用に至るまでの学習コストが高いことでも、良く知られている。そのため、段階を踏みながら、関係者の理解を深めていくことが大切なんだと思う。

段階-1 企業内に、コンテナの開発と運用に関する技術スキルを身に着ける。

DockerコンテナやKubernetesの利用価値について考え、スキルを習得する動機を獲得する第一歩は、具体的に知ることからと考える。次に最初に学ぶべきテクノロジーのキーワードを列挙する。

Dockerコンテナ
Kubernetes
GitHubなどのGitリポジトリ
DockerとKubernetesの間をつなぐ、コンテナレジストリ

段階-2 アプリケーション開発について、DevOpsやCICDという言葉で、言い表わされるツールを活用した開発経験を積み重ねる。

アプリケーション開発者が理解して、やる気になってもらえることが、Kubernetesの導入を成功させる上で重要と考える。開発者にとってのKubernete導入の価値は、CICDツールを実行するための基盤である。具体的には、コードを編集して、Gitリポジトリにコミット＆プッシュした後、テスト環境にデプロイするまでの工程を自動化できる点が大きい。

コードリポジトリの活用を手始めとして、アプリケーションの開発のルーチンワークの自動化を進めていくことで、コンテナの便利さ、適切な利用法を具体的に理解していくことができる。

アプリケーションのソースコードを、GitHubやGitLabなどのコードリポジトリで管理
開発チームのメンバーが、コードリポジトリを活用して、課題のトラッキング、コードの修正依頼、ブランチを利用した修正コードの品質確認
コードリポジトリとインテグレーションツール（Jenkinsなど）を連携させて、コード修正後のリント検査、自動ビルドと簡単なテストが実施
インテグレーションツールの活用範囲を拡大して、コンテナのビルドとリポジトリ登録までを自動化
インテグレーションツールのビルド工程の中で、ソフトウェアモジュールの脆弱性などの検査を拡張
コンテナリポジトリでの脆弱性検査
テスト環境への自動デプロイとテスト実施

段階-3 コンテナ化したアプリケーションの運用基盤スキル向上を進める

クラウドは、目的とするスキルを手っ取り早く習得する上でも、便利なツールである。例えば、オンプレミスで運用することが条件であっても、企業システム運用を前提とした学習用環境では、クラウドを活用することを推奨したい。オンプレやクラウドに関わらず、本番環境を構築してシステムを運用する上では、メトリックス、ログ分析、イベント通知の順で、本番運用に必要なスキルを向上させると良い。

メトリックス監視: CPUやメモリの使用率、ネットワークのパケット受信と送信などの量的把握、トラフィック中のエラーの発生率などの管理
ログ分析: アプリケーション、ミドルウェア、インフラが出力するメッセージやログファイルの集中管理と、ログ分析ツールのスキル獲得
イベント通知: メトリックス管理やログ分析ツールとイベント通知システムへの連携、インシデント・トラッキングツールなどと連携

レガシーなウェブアプリケーションをコンテナ化して運用する場合、従来のロードバランサーのクッキーによるセッション固定化の機能を外せない場合がある。そのようなケースでは、イングレスコントローラーを併用することも考えなければいけない。

オンプレミスでは、HA-Proxy や NGINX Ingress コントローラーとの連携
クラウドサービスでは、クラウドサービスのロードバランサー、アプリケーション・ロードバランサーなど
ステートレス化の対比として、クラウドのキャッシュサービスの使用方法、または、RedisクラスタなどをKubernetes上に構築する方法

Kubernetesの重要な機能の一つには、ハードウェアや仮想サーバーの計算資源のコストを無駄にしない様に、一つのクラスタ上に、複数のアプリケーションの実行環境を共存させるKubernetesクラスタの仮想化ができる点である。しかし、技術的な知識を十分蓄積するまでは共存利用はお勧めしない。一つのkubernetesクラスタ上に複数の環境を構築するためには、以下の様な理解が必要とされる。

名前空間に設定情報や秘匿性情報を保存する考え方
名前空間 (Name Space) とリソース使用のデフォルト値、上限値の設定方法
名前空間ごとのサービスアカウント、役割基準のアクセス制御(RBAC)、ユーザーアカウントとの対応づけ
クラスタネットワークと名前空間によるアクセス制御。（名前空間 AとBの間でのアクセス禁止と許可などスキル)

Kubernetesクラスタを、企業情報システムへ適用する際に、データベース・サーバーの問題は避けて通ることができない。クラウド環境では、クラウドサービスのデータベースを利用することで、データベース運用の負担から逃れることができる。しかし、オンプレミス環境でKubernetesクラスタを利用する場合には、この問題を避けて通ることができない。

しかし、一方で、SQLデータベースのコンテナを、Kubernetes上で簡単にHA構成として動作させることもできるが、その際の考慮点を挙げておく。

Kubernetesのコンテナは、一般に随時停止できる一時的な存在として扱われるが、SQLデータベースのソフトウェアは、データを保持するステートフルなコンテナであるため、特別な注意を払って運用する必要がある。
一般的なSQLデータベースでは、ACID特性を維持するために、アクティブ・スタンバイのHA構成が必要とされ、Kubernetesクラスタ外部に、データ保全性が担保されたストレージ装置と連携させる必要がある。
コンテナとストレージ装置の接続プロトコルの理由により、I/O性能は、物理サーバーほど高く出来ないないため、高いTPSを要求される用途には向かない。物理サーバー同等のトランザクション性能は出ないことを念頭におく必要がある。
Kubenetesのコントローラーの一つ Statefulsetが適しているが、制約もあるので、Deploymentの適用も考慮する。

段階-4 マイクロサービスを企業情報システムに適用する際の考慮

マイクロサービスは、予算が完結する組織単位にシステムを細分化して、自律性を高めることで、予算の制約、システム間連携の制約を少なくして、サービスの機能改善を加速する効果がある。また、サービスを複数の隔離されたマイクロサービスで構築することによって、システムの可用性を高めることができる。つまり、一部の障害が、他のシステムに波及しないため、全体が停止することを回避することができる。肥大化した企業システムは、規模が大きく様々なインタフェースを保つため複雑で、把握が難しい。そのため、新規に人材を採用して第一線で活躍するまでに数年もかかる。その点で、小さく細分化されたマイクロサービスであれば、人材を早期に戦力化できる。

この特性をもつマイクロサービスは、インターネットでポータルサイトなどを提供する企業にとって、大きなの利点をもたらすが、大企業の基幹システムをマイクロサービス化には障壁も多い。その例を、筆者の経験から挙げて見たい。

製造業や金融業など、大企業の基幹システムをマイクロサービス化は、高いスキルの人材、長いプロジェクト期間、膨大なコストが必要なことが予想され推進を賛成するものは少ない。
情報システム依存度が高いとされる航空業界の基幹システムは、重要なサブシステムごとに分割され、相互にメッセージングで疎結合化されているため、全体障害を回避すると共に、部分的な移行が可能となっていることから、基幹システムを改めてマイクロサービス化する必要性は無いかもしれない。
ECサイトの普及によって、取り扱い量が年々増える宅配便サービスは、膨大な量の荷物を処理する物流の自動化装置からのトラッキング情報、貨物の配送経路処理など、強力なトランザクション性能を主とするワークロードであることから、コンテナに適さない。

しかし、ここに挙げた基幹システムは、いづれも、ネットバンキング、航空券の予約、登場手続き、宅配の集荷、受け取りなど、スマートフォンのアプリと連動して我々の生活を便利で快適なものにしてくれている。この様に、基幹システムの周辺で、スマートフォンを通じて、一般消費者へサービスを提供する部分では、利便性を素早く向上させるためにも、マイクロサービス・アーキテクチャを駆使してシステム設計することは、望ましいことであると思う。

段階-5 実践

情報システム部門内で、段階-4までの考慮点について議論できるようになれば、適切な方法でKubenetesを適用していくことができる。あとは具体的に実装を進め、経験を積んでいけば良いと考える。

OpenShiftの概要と特徴について

IBMが、Redhat社を買収したことにより、積極的にOpenShiftを提案する立場となった。そこで、OpenShiftを利用する理由について整理する。

CNCFのKubernetesのマイナーバージョンは、年3回リリースされ、2世代前までサポートされるため、約8ヶ月間サポートが継続される。その後は、バグや脆弱性が発見された場合は、それ以降のリリースについてのみ対応が適用される。つまり、ユーザーは8ヶ月ごとにバージョンアップを続けなければならない。このようなCNCFから配布されるソースコードやバイナリコードは、アップストリーム（上流）Kubernetesと呼ばれ、ベンダーが製品化する前のKubernetesという意味で、そう呼ばれている。現在、急速な発展段階にあって、その勢いを妨げるべきではない。という意見が多い。そのため、LTS(Long Term Support)バージョンといったものは存在していない。

企業の情報システムにKubernetesを適用する場合、約8ヶ月でバージョンアップを繰り返すのは大変な負担となる。そのような問題を解決することができるのが Red Hat社が提供するOpenShiftである。Red Hatの社員は、Kubernetesの開発者として数多く参加しており、Gitリポジトリを参照すると良く解る。OpenShiftは、Red Hatが利用するだけではなく、Kubernetesの発展に対しても多くの貢献を果たしている企業である。そのことから、Kubernetesの先進的な機能がいちはやく製品化されることが期待される。

OpenShiftは、ダウンストリーム（下流）のKubernetesとも呼ばれ、Red Hat社が独自に拡張を加え、使い易さと長期間のサポートを適用する Kubernetesである。

さらに、OpenShiftの企業向け対応は、それだけではない。

Kubernetesの特徴を生かした導入には、DevOpsが重要であることを前述したが、DevOpsのツール群は、ほとんどがOSSである。この様なOSSを組み合わせて利用することは、普段からOSSを利用していないソフトウェア技術者にとって敷居が高い。この問題をOpenShiftは解決してくれる。つまり、情報システム部門でも、OpenShiftに組み込まれたツールによって利用の技術的な敷居が下がり、Kubernetesの環境でDevOpsを始めやすい。さらに本格的な活用に、Jenkinsと連動されることも想定されている。

企業の情報システムを常に悩ませる重要課題は、セキュリティである。Linuxを中心としてOSSを利用する者にとって、脆弱性対策は注意を払っておかなければならない。Red Hat社の Linuxは、企業向けのLinuxとして、脆弱性対応に力を入れ、米国の情報セキュリティ機関とも連携して、脆弱性対応のパッチをいちはやく提供することで有名である。コンテナのベースイメージに、Red hat Enterpirise Linux を利用することで、一般的に利用されるコンテナのベースイメージよりも高い脆弱性サポートを受けることができる。

企業の情報システムでKubernetesを採用するのであれば、OpenShiftを大変重要なツールと言える。

CICDツール+レジストリサービスと統合されたKubenetes+DevOps環境
長期間のサポートが受けられるKubernetesプラットフォーム
RHELの脆弱性サポートを受け継ぐ、企業向けセキュリティサポート

IBMが取り組んでいる IBM Cloud Paks について

Red Hat社を買収する以前から、IBM は、Kubernetes のオンプレミスで利用可能な IBM Cloud Privateという製品を提供してきた。こちらは、アップストリームのKubernetesに、付加機能を加えたもので、Ubuntu Linux または RHEL にインストールすることができる。このプラットフォーム上で、IBMの伝統的なミドルウェアを流れを受け継ぐ WebShphere Liberty や Message Broker などのコンテナを利用することができた。

しかし、この製品では、企業の情報システム向けの製品としては、不完全なものであった。つまり、コアにはアップストリームのKubernetesが利用されており、前述の問題を解決する必要があった。

Red Hat社を買収することによって、OpenShiftが、企業の情報システム向け製品であるという特徴と、IBMのミドルウェア製品を合体させることができた製品が IBM Cloud Paksである。これによって、より完全な企業の情報システム向けの Kubernetes + ミドルウェアのパッケージが出来上がった。

IBM Cloud Paks には、以下のような複数のパッケージがあり、これらが全て同一のプラットフォーム OpenShiftで稼働するため、運用管理の工数削減が期待される。OpenShiftによってKubernetesの長期サポートが可能となり、その上で動作するミドルウェアなどソフトウェア製品は、コンテナで提供される。したがって、容易なバージョンアップ、モニタリングやログ分析などの作業は共通化される。また、Kubernetes のワーカーノードとなる部分は、使い回しができるなど、企業の情報システムへの投資を無駄にしない。

Applications アプリケーション開発と運用の環境
Data データの収集、編成、分析の統合と簡素化
Integration　API管理、メッセージングとイベント、高速転送
Automation ビジネスプロセスの自動化
Multicloud management マルチクラスター管理、エッジ管理
Security セキュリティのツールを統合

IBMの新しい取り組みとして、IBM Cloud Paks Applications に含まれる OSSとして開発を進める DevOpsツール Kabanero がある。この特徴は、デベロッパーにとっての開発環境を自由に選べる点がる。つまり、Eclipse, Visual Studio Code, コマンドラインを通じて利用できる。そして、Kubernetes環境で実行するために必要な足場(Scaffold)となるコードを生成してくれる。

Kubernetesの実行環境では、コンテナに内包するべき機能要件がある。それらの機能を、開発者自身が調べて間違いなくコードを実装することは、間違いないく生産性にとってマイナスである。そのような問題に対処するために、Kabanero と呼ばれるOSSツールは、開発者の開発言語とフレームワークの選択に合わせた足場となるコードを生成してくれる。

例えば、Java では、Microprofile や Spring のフレームワークを利用したスカッフォルドコードを生成する。その足場となるコードには、コンテナのビルドのためのDockerfile、Kubenetes Operator のYAMLなどが含まれ、Kubernetesについて経験の少ない開発者でも、効率よくKubernetesで動作することを前提にしたコンテナ化アプリケーションを開発することができる。さらに、CIツールとの連携も開発が推進されており、足場となるコードだけでなく、CICDパイプラインの生成までが自動化される見込みである。

このように企業情報システムの開発言語として Java は中心的存在であり、このような情報システム資産を有効に活用しながら、次の世代に対応していける。このOSSは、Javaだけでなく、Python、Node.js、Rustなどのプログラミング言語やフレームワークにも対応が進められている。

OpenShiftは、企業向けKubernetesの堅牢なコンテナ実行環境であり、これからのオペレーティングシステムと言える。そして、IBM Cloud Paksは、その上に、企業の情報システム向けの開発と運用のサポートする総合環境と言える。

参考URL:

[1] DockerコンテナとKubernetesの導入率は微増 - IDCの調査, https://news.mynavi.jp/article/20190704-853537/
[2] CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%, https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/

2019年 Kubernetes について活動して感じたことのまとめ