はじめに
G-gen の杉村です。コンテナや Kubernetes という用語が目立って聞かれるようになってからかなりの年月が経ちました。しかしながら 2022 年現在の企業 IT において、これらの技術はほとんど使われていないのが実態です。その根拠や、ここで言う「企業 IT 」が何かは、後述します。
企業 IT を生業とされている情報システム部門のエンジニアの方々や IT ベンダーの方々にとっては、コンテナやアプリケーションモダナイゼーションといった用語を、知識としては知っていても実際に使った、あるいは 実践したことがない方が多いでしょう。
なぜ、コンテナは "普及しない" のでしょうか (あるいは、本当は普及しているのでしょうか) 。また、この状況はしばしば「日本は遅れている」「レガシーだ」などと、悪い事のように表現されますが、果たして本当に悪いことなのでしょうか。
当連載では、そういった疑問について考察してみたいと思います。第1回ではそもそもコンテナやKubernetesとは何か、日本ではコンテナが普及しているのかについて解説し、第2回ではコンテナを使う必要はあるのか、コンテナ技術と物理/仮想サーバ技術では、システムのアーキテクチャがどう変わるかについて整理していきます。
この記事は主に、これまであまりコンテナや Kubernetes 、クラウドといった技術に触れてこなかった方々、特に、コンシューマー向けサービスではなく企業や官公庁の組織内向け IT を生業とされているような方々に読まれることを想定しています。コンテナやアプリケーション・モダナイゼーションの必要性の可否を判断する際の参考にしていただければ幸いです。
コンテナとは、 Kubernetes とは
コンテナ、 Kubernetes といった用語について簡単に確認します。これらの用語については既に多数の Web サイト、記事、書籍などで解説されていますので、当記事では数行のおさらいに留めたいと思います。その他の用語については、後の考察中でも解説します。
コンテナ
親となるサーバ (「ホスト OS」) 上で稼働する、軽量な仮想環境のことです。オープンソースである Docker による実装がデファクトスタンダードであり、コンテナといえば、ほぼ間違いなく Docker のコンテナのことを指しています。
Docker では定義ファイルを元にコンテナイメージをビルド (生成) し、そのイメージから個々のコンテナが起動します。そのため、インフラのコード管理、バージョン管理にも繋がります。
コンテナオーケストレーション
コンテナは小さな仮想環境であり、起動や停止の概念があります。何らかの障害によりコンテナが停止してしまった場合、それに誰かが気づいて、再び起動してあげなければいけません。また、ユーザーのアクセスの増減に合わせてコンテナを増減 (スケーリングといいます) するなど、コンテナには様々な管理タスクがあります。
しかし、コンテナは親となるサーバ (ホスト OS) の上で起動します。このホスト OS が複数存在し、しかも各ホスト OS で大量のコンテナが起動していたら、これらを全て管理するのには大変な工数がかかることは想像に難くないでしょう。
複数のサーバにまたがる大量のコンテナを、統合管理する仕組みがコンテナオーケストレーションです。代表的なコンテナオーケストレーションの実装として Kubernetes や Amazon Elastic Container Service (Amazon ECS) などがあります。
Kubernetes
Kubernetes は Google が開発した、オープンソースのコンテナオーケストレーションの仕組みです。
当初は Google が開発・メンテナンスしていましたが、現在では Cloud Native Computing Foundation という財団がメンテナンスをしています。コンテナオーケストレーションにおいては、 Kubernetes が事実上のデファクト・スタンダードとなっています。
Google Cloud (GCP) にはマネージドな Kubernetes サービスである Google Kubernetes Engine (GKE) があります。 Amazon Web Services (AWS) も同様に、 Amazon Elastic Kubernetes Service (Amazon EKS) を持っています。
コンテナや Kubernetes を使う理由
コンテナのメリット
コンテナのメリット (強み) は、以下のようなものが挙げられます。
スケーラビリティが高い
定義ファイルからコンテナを起動すると、秒単位の速さで新しい環境が起動します。アクセス数が激しく変動するようなアプリケーションでは、この起動スピードがものをいいます。クラウドと組み合わせると「アクセス数が少ないときはコンテナの数は少なく」「アクセス数が増えたときに、必要に応じてコンテナが増える (ホスト OS はクラウドが管理しているので気にしなくて良い)」といった利用が可能になります。
開発効率が高い
コンテナは定義ファイルを雛形として定義することができます。定義ファイルを基にしてイメージをビルドし、そこからコンテナを起動するだけで、一瞬にして多数の仮想環境が同じようにできあがります。そのため、ミドルウェアなどの動作環境を簡単に統一でき、開発効率が向上します。
これが物理サーバや仮想サーバであれば「本番環境(1号機, 2号機……)」「ステージング環境」「開発環境」のように複数の環境を用意し、それぞれに OS 、 ミドルウェア、設定ファイルを構築しなければいけません。運用が長くなると、いつの間にか各環境間で設定が異なるものになっていた、という事態が当たり前に発生します。コンテナでは、それを防ぐことができます。
また、コンテナを用いたアプリケーション開発においては CI/CD (継続的インテグレーション・継続的デリバリ) がしばしばセットで使われます。これにより、コンテナの開発効率向上というメリットを最大限に享受することができます。CI/CD ではコードの変更、コンテナのビルド、テスト環境へのデプロイ、承認を経て本番環境への展開、といった一連の流れが自動化されます。
デプロイの柔軟性
コンテナのアーキテクチャでは、小さいコンテナを多数用いることで、例えばアプリケーションのバージョンアップをする際に「10個のコンテナが本番稼働している。そのうちまずは5個だけをアップデートし、一部のユーザーのトラフィックだけをその新バージョンに流す。動作に問題がなければ残りの5個もアップデートする」のような展開が可能です。
このように工夫されたアプリケーションの展開方法を総称してデプロイ戦略と呼びます。有名なデプロイ戦略としてローリングアップグレード、カナリアリリース、Blue/Green デプロイなどがあります。
可搬性 (モビリティ) が高い
コンテナは定義ファイルで定義されているので、実行環境が変わっても、そのまま別環境に持っていくことができます。動作する場所がオンプレミスの物理サーバでも、 AWS でも、 Google Cloud (GCP) でも、コンテナを持っていきさえすれば同じように動作します。
コンテナが使われるシーン
コンテナは以下のようなユースケースで使われていることが多いでしょう。
- コンシューマ向け Web サービス
- ECサイト
- スマートフォンアプリのバックエンド
- ゲームのバックエンド
これらのケースでコンテナが使われている理由は、先述したコンテナの強みがフルに活かされるからです。
コンシューマ向けである Web サービスや EC サイト、スマホアプリやゲームなどは、コンシューマ向けであるがゆえに、利用ボリューム (ワークロード、と表現されます) が変動しやすいです。テレビ CM を打った、 SNS でバズった、スキャンダルが報道された……などの理由で、運営側からは想像もつかない勢いでワークロードが変動することがあります。
こういった際に、コンテナのスケーラビリティが高いという強みが活かされます。
また、これらコンシューマ向けサービスは、ビジネス展開のスピードが非常に早いです。世の中の動きやビジネス状況の変化に応じてビジネスが変化するのに合わせて、アプリケーションも同様にかなりの早さで変化することが求められます。そのようなアプリケーションでは、一日に数回、月に数十回といった頻度のデプロイを行うことすらあります。
このときに、コンテナの開発効率が高い、デプロイの柔軟性といった強みが活かされるのです。
日本におけるコンテナ
日本ではコンテナが普及しているのか
少し前になりますが、2021年ころの複数の調査結果によると、日本企業のおよそ2～4割がコンテナの導入を検討している、もしくは実際に導入していることが示されています。
コンテナがどのようなシステムに使われているのか、その内訳までを示す情報は無いものの、おそらく前述のコンシューマ向けサービスが中心であると考えられます。
日本企業のうち2～4割という数字は、多くの読者にとって思ったより多いのではないのでしょうか。また、実感とは離れているのではないでしょうか。実感と離れている理由は、コンテナを扱う技術者の少なさと、後述する「社内システムとしての企業 IT」ではコンテナが普及していないから、ということが理由として考えられます。
企業 IT でコンテナが使われない理由
企業 IT とコンテナ
ここに述べる「コンテナが使われない企業 IT 」とは、企業や官公庁に存在する以下のようなシステムです。
- 顧客管理システム
- 受注・調達・生産・在庫管理等システム
- 会計管理システム
- 人事・労務システム
- メールサーバ・ファイルサーバ等
- その他、企業や官公庁等の組織内で使われる情報システム全般
これらは、先ほどコンテナが使われるユースケースとして挙げたコンシューマ向けサービスではなく、組織内の利用者向けのシステムです。情報システム部門や、情報システム部門を主な顧客としている IT ベンダーにとっては、このような社内向けシステムを扱うことが多いはずです。
そしてこのようなシステムでは、ごく一部の先進的な事例を除いて、コンテナや Kubernetes といった技術がほとんど使われていないことに気がつくと思います。 また多くの社内システムではパッケージ製品が利用されますが、パッケージでは一部の製品を除いてはコンテナに対応していないことが多いでしょう。
その理由は、先述した「コンテナの強み」の裏返しです。
理由1：利用ボリュームが予測できるため、柔軟なスケールの必要がない
企業 IT では、利用者数が事前に概ね決まっており、急激な変動はありません。入退社、人事異動、月初や月末に利用ボリュームが集中するシステムなどはありますが、コンシューマ向けサービスほどの急激で予測困難な変化ではありません。それゆえに、予め最大ボリュームに合わせてサイジングが可能です。
もしクラウドの仮想サーバなどを用いていれば、利用が少ないときはサーバを停止しておき、利用が増えるタイミングで起動すれば、これらのようなある程度予測可能なワークロードには十分対処できます。停止・起動処理を自動化することも難しくありません。
このように、枯れた技術であり習得も容易な物理サーバや仮想サーバで対処ができるので、あえて学習コストのかかるコンテナを利用するモチベーションが働かないのです。
理由2：開発体制がない
コンテナにおいては、開発体制が従来とは異なります。物理・仮想サーバを前提とした開発体制では「インフラ担当」「アプリ (業務) 担当」に大きく分かれていることが多いでしょう。しかし、コンテナを前提とした開発となると、この境目が曖昧になります。
コンテナでは、インフラがミドルウェアを含めてコンテナ定義ファイルにより定義されます。そしてコンテナの開発効率向上のメリットを最大限に享受するため、 CI/CD (継続的インテグレーション・継続的デリバリ) とセットで用いられることが多いです。こうなるとアプリケーション担当者が「インフラ (クラウド環境) をある程度理解する」「これまでインフラ担当者が行っていた範囲を巻き取る」といった状況が起こります。一方でインフラ担当者の役割は「ネットワーク」「セキュリティ」「ガバナンス」「クラウド環境操作権限を開発者へ効果的に移譲する」などに集中していきます。
さらに重要なことに、これまで完全に分断されてきた (場合によっては仲が悪いこともある) インフラチームとアプリチームですが、コンテナ化に際してはこれまで以上に密に連携することが求められるでしょう。
このような開発体制の変化に、情報システム部門側も IT ベンダ側も追随できていないケースが多いといえます。あるいは、そのような変化が必要とされることをそもそも認識していないこともあります。この認識の欠如は「当社ではコンテナ開発のノウハウがありません」というセリフに繋がっていきます。
理由3：クラウドを使っていない
コンテナの強みであるスケーラビリティ向上は、パブリッククラウドとセットで用いることで発揮されます。コンテナ自体は軽量で起動も数秒でできるとはいえ、コンテナはホスト OS の上で動いています。そしてホスト OS は物理的/仮想的なサーバ上で動いています。コンテナがスケールするには、結局のところ、サーバもスケールすることが必要なのです。
ですから、企業・官公庁が自組織で持つ物理サーバのうえでコンテナを動かす場合は、コンテナのスケーラビリティのメリットが得づらいということが分かると思います。コンテナが少ないときはサーバのリソースが余りますし、コンテナが増えたときは逆に足りなくなるからです。 (ただし、組織が多量の物理コンピューティングリソースを所有しており、ワークロードが集中する時間帯の異なる多くのシステムを擁している場合は、この限りではありません。)
パブリッククラウドでは、仮想サーバを必要に応じて増やしたり、減らしたりすることができますので、コンテナのスケーラビリティを活かすことができます。裏を返すと、パブリッククラウドを使っていない組織では、スケーラビリティのメリットが得づらいということになります。
日本のコンテナ技術者が増えない理由
上に挙げた3つの理由は、あくまで「社内システムにコンテナが使われない理由」でした。しかしながらここから発展して日本の技術者にコンテナを扱える技術者が増えづらい理由も説明がつきます。それは日本の IT 技術者の多くが、先に挙げたような“社内システム”を扱う技術者であるからです。
エンタープライズクラスの企業の IT 投資の多くは、社内の基幹システムの保守・運用、そしてハードウェア老朽化やソフトウェアサポートの期限を契機に行われる基幹システムのリプレイスに当てられています。それゆえに "IT 技術者" の大半は (所属がユーザー企業だろうと IT ベンダーであろうと) そのような基幹システムのいわゆる「お守り」に当てられています。そして、前述の理由で社内システムにはほとんどコンテナが用いられません。
これが原因となり、日本ではコンテナ技術を持つ技術者が生まれづらい状況があるように思われます。そのため要員確保が難しいままであり、コンシューマ向けサービスを開発する際でも、コンテナ・アーキテクチャを自信を持って選択できない状況に繋がるのではないでしょうか。またこのような状況では、社内システム向けパッケージ製品も、コンテナ対応は進みません。
このような状況を打破し、コンテナ・アーキテクチャなどのモダンなアーキテクチャを採用できるようになるためのアイデアやそもそもコンテナを使う必要はあるのかという点については、第2回で解説します。
※本記事はG-genから提供を受けております。著作権は同社に帰属します。
[PR]提供：G-gen
