なぜコンテナは普及しないのか？ という観点から、コンテナや Kubernetesについて解説する当連載。第2回ではコンテナを使う必要はあるのか、コンテナ技術と物理/仮想サーバ技術では、システムのアーキテクチャがどう変わるかについて整理していきます。
コンテナを使う必要はあるのか
「自社ではコンテナ技術を導入する必要があるのだろうか」というお悩みの声を聞くことがあります。重要なのは、コンテナを使うこと自体が良いわけでも悪いわけでもないということです。
コンテナ技術はただのイチ技術要素です。ここまでに記載したようなコンテナの強みを正しく理解し、使う必要があれば利用し、使う必要がなければ使わない、と判断することが重要です。
いつ使うのか
前述に挙げたような「企業 IT (正確には社内向け IT)」では、ワークロードが予測できるため、学習コストのかかるコンテナ技術を用いる積極的な理由がありませんでした。
一方で、デジタル・トランスフォーメーション (DX) の背景等で社外向けサービスを作ることになったとしましょう。最も重要なのは「なんのために、どんなサービスを作るか (WHY/WHAT) 」というビジネス的観点ではありますが、次の段階では「どのように実装するか (HOW) 」も重要になってきます。
このときには、スケーラビリティを得るため、また開発効率とスピードを高めるため、そして最新の IT シーズを活かすために、クラウドやコンテナの利用が必要になるかもしれません。
また社内向けシステムであっても、実験的な情報系システムの取り組み等であれば、スモールスタートからの将来的な全社展開を視野に入れて、コンテナやサーバレスのアーキテクチャを検討することもあります。
人材確保の観点
また別の観点として人材確保の観点でも、組織が使う技術要素は重要になります。組織がモダンなアーキテクチャのアプリケーションを擁している・最新技術を使っている・ "イケてる" 開発体制がある・それらを外部発信する文化がある、といった状態であれば、組織に優秀な技術者が自然と集まってくることに繋がります。
しかしながら「現時点で、最新技術を扱える技術を持った技術者が社内にいない」「新たに採用したくても "イケてる" 技術者が応募してこない」「 "イケてる" 技術者が応募してくれるためには最新技術を使わないといけない……」という「卵が先か、ニワトリが先か」状態になってしまうことも悩みの一つです。
このようなときに、多くの企業では “クラウド・ネイティブ” なクラウドインテグレーター (筆者の所属している G-gen やその親会社のサーバーワークスが該当) に技術的な支援を仰ぎ、伴走してもらいながら組織を作っていくケースも、近年はよく見られます (モダンな開発体制を作ったり、企業内に CCoE を組織するときにも、この手法が用いられます) 。
このように、最新技術を持つパートナーの力を借りて組織をクラウド化・モダン化する手法は、 Google が紹介するクラウド導入フレームワークである The Google Cloud Adoption Framework でも触れられています (以下ブログの 2-3-8. 外部の知見 を参照ください) 。
この外部パートナーの活用が、先ほど「このような状況を打破し、コンテナ・アーキテクチャなどのモダンなアーキテクチャを採用できるようになるためのアイデア」と述べたものです。
なおこの技術人材という観点は、企業にとっては今以上に深刻に捉えなければいけないかもしれません。 IT 人材の流動性はますます高まっていますし 2022 年現在の筆者の感覚ではいわゆる「 IT エンジニア 35 年定年説」は実態と異なります。この状況では、優秀な技術者ほど、レガシー技術のみを扱う会社から逃げてしまいます。 IT 技術者が技術に関する知識とスキルを身に着けて一定のステージへ進むと、より新しくおもしろい技術を扱いたくなりますし、それがエンジニアのプロ意識だからです。
とはいえ、企業には守りの IT と攻めの IT の両方が必要です。優秀な技術者に会社にいてもらうために研究・開発だけをやってもらったり、攻めの IT だけを担当してもらうというわけにはいきません。現代の日本企業は、お金のリソース配分と同等以上に、人材のリソース配分や社内でどのように流動性を持たせて技術者を異動させるか、また評価制度を設計するかという難しい課題があるといえます。
問いへの答え
「コンテナを使う必要はあるのか」という問いに対しての返答は、以下のようにまとめられるでしょう。
- コンテナ技術は、社内向けシステムでは必須とは言い切れない。一方で社外向けサービスや実験的アプリ等を作る際に有効である可能性がある
- IT 人材確保のためには最新技術を使っていることを社外にアピールすることは有効
- 体制が無い初期段階ではクラウド・ネイティブなパートナーによる支援も視野に入れ、モダンな開発を取り入れることを検討する
アーキテクチャがどう変わるか
次に、技術的な観点で、コンテナ技術と物理/仮想サーバ技術では、システムのアーキテクチャがどう変わるかということについて補足したいと思います。
結論から言うと、システムのアーキテクチャは大幅に変わる可能性があります。アプリケーション開発者も、インフラエンジニアも、このアーキテクチャの違いを正しく理解する必要があります。
コンテナアプリケーションにおけるアーキテクチャでは、イミュータブルインフラストラクチャという言葉と、ステートレスアプリケーションという言葉が重要になります。
イミュータブル
イミュータブルは「不変の」を意味する英単語です。
従来のように、サーバを構築し、ミドルウェアをインストールし、サーバ内に配置した設定ファイルにより設定を管理する、という方法はイミュータブルではありません。非イミュータブルな設計においては、サーバを「育て」「お守りをする」必要があります。また永続化するデータやセッションファイルなどの一時情報は、サーバのストレージに保存されます。このため、サーバの中身は「可変である」と言えます。またそれゆえに、サーバのストレージのバックアップを取る必要がありますし、障害の際はサーバの中身を含めた復旧が必要となります。
これに対してイミュータブルなインフラでは、サーバの中身は「不変」です。永続化データやセッション情報などは外部のデータストアに永続化しますし、設定値はコードでバージョン管理されます。障害が起きたサーバ/コンテナはすぐさま廃棄し、新しいサーバ/コンテナをイメージから新しく作り直します。このイミュータブルなインフラでは、管理工数は大幅に減るうえ、水平スケールが容易になります。
ステートレス
ステートレスは「状態を持たない」ことを意味しています。
従来型の物理・仮想サーバのアーキテクチャは、ステートレスの対義語である「ステートフル」であることが一般的です。ステートフルなアプリケーションとは、アプリケーションやサーバが状態を保持することを指します。いわゆるサーバが「データを腹に持つ」のがステートフルなアプリケーションです。例えばあるアプリケーションサーバがローカルディスクにセッションファイルを保存する仕組みの場合、そのアーキテクチャはステートフルです。
サーバが冗長化されているとしても、とあるセッション中のユーザーは常に同じサーバにアクセスする必要がありますし、アクセス減少にあわせて仮想サーバが減る (スケールイン) する場合でも、セッションが残っているサーバは削除されると、セッション情報が失われてしまいます。
反対に、コンテナはステートレスであり「データを腹に持たない」のが原則です。保存するべきデータは全てコンテナ外部のデータベース等のストレージに保存します。永続化すべきデータはデータベースに保存しますし、セッション情報の保存には NoSQL データベースや Redis や Memcached などのインメモリ・データベースが使われます。
サンプルアーキテクチャ (仮想サーバ)
物理・仮想サーバを用いる従来型アーキテクチャは以下のようなものです。
サーバが冗長化されている場合、セッションファイル等をサーバ内に持つステートフルアーキテクチャであるため、ロードバランサーのセッション維持の仕組みにより同じサーバにアクセスを割り振ります。
デプロイは手作業で行うことが多く、サーバは一度構築したら、めったに増えたり減ったり (水平スケール) しません。ただし、クラウド環境のおいては、ロードバランサーの下にぶら下げた仮想サーバを停止・起動することで数を調整することができます (停止している間、サーバの CPU/Memory あたりの料金は発生しません) 。
サーバは非イミュータブルであり、一度構築したサーバを維持・管理する必要があります。
構成図は Google Cloud のアイコンを使っています。 Cloud Load Balancing や Compute Engine 、 Cloud SQL といったサービスで構成を実現できます。
従来型、と記載したもののネガティブな意味ではありません。よく知られている構成であるため、既存の開発の枠組みなどを適用できる点にメリットがあります。
サンプルアーキテクチャ (コンテナ)
一方で (あくまで例ですが) コンテナを用いたアーキテクチャは以下のようになります。
コンテナは、仮想サーバではなく Google Kubernetes Engine や Amazon ECS 、 Amazon EKS などのマネージドなコンテナオーケストレーションサービスで起動されます。これらを使う場合、ホスト OS はクラウドサービス側で管理するため、開発者側では考慮が必要なくなります。
コンテナはステートレスなインフラとして利用され、 データを “腹に持ち” ません。セッション情報などは Redis や Memcached といったインメモリ・データベースに "外出し" します。
コンテナやサーバレスのアーキテクチャでは、データベースへのセッション数が非常に多くなるケースがあります。多数のセッションを支えられるよう、データベースも伝統的なリレーショナルデータベースではなく、分散アーキテクチャの NoSQL データベースが用いられることがあります。ただし必ずしも NoSQL を使う必要があるわけではなく、ワークロードに応じて適切なデータベースを判断します。
このように、コンテナを用いると、データベースやセッション管理の方法などにも波及して考慮が必要になります。
構成図は Google Cloud のアイコンを使っており、 Cloud Load Balancing 、 Googke Kubernetes Engine 、 Memorystore などのマネージドサービスを用いています。
※本記事はG-genから提供を受けております。著作権は同社に帰属します。
[PR]提供：G-gen
