ITのサービス提供形態（アプリケーションおよびインフラ）は時代を経て、今ではさまざまな仮想化環境を選択可能になっている。
直近のトレンドとしては「クラウドネイティブ」なサービス提供形態が注目され、そのサービスの一般的な実装アプローチであるコンテナ仮想化環境とCI/CDなどの継続的サービス開発形態が提案の場面で頻出している。
ただしベンダーを含めた提案チームとユーザーとの間で、この「クラウドネイティブ」という言葉が詳細に定義されておらず、認識の齟齬が発生しやすい状況にある。
そこで本稿では、あらためてクラウドネイティブとは何かを定義し、なぜ昨今求められているのかを基本的な要素から考え、何を満たすことでクラウドネイティブなサービス提供を実現できるのか、あらためて検討する。
さらに、いま最も現実的なクラウドネイティブ実現のアプローチであるコンテナ基盤の特徴や過去の仮想化環境と比較した優位性を確認する。なおコンテナ基盤の構成については、現状最も利用実績の多いKubernetes Containerを前提とする。
では以下に、ユーザーが現在求めるITサービス基盤の必要要素、およびクラウドネイティブの要素について詳しく見ていこう。
ITサービス基盤の必要要素とクラウドネイティブ
ITサービス基盤には、当初から以下が求められてきた。
・サービスを使用するユーザーの満足度向上
・開発／運用コストの最小化
とくにサービスに対するユーザー満足度については昨今、ユーザー同士がSNSで盛んに情報共有する背景もあり、今まで以上に安定的なサービスの提供に加え、ユーザーフィードバックの迅速な吸い上げと反映が求められている。ただしこれらの要求に応えようとすると、当然ながらそれに比例して開発・運用コストが増加していくのは明らかである。
上記の2点について、ブレークダウンした具体的な要望を図表1に示す。
クラウドネイティブは、これらに対してどのように応えるサービス基盤なのだろうか。Cloud Native Computing Foundation（以下、CNCF）では、クラウドネイティブとは以下のような要件を満たすサービス基盤であると定義している。
「クラウドネイティブ技術はパブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらす。
このアプローチの代表例にコンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがある。
これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現する。
これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに実行できる。CNCFは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持し、このパラダイムの採用を促進したいと考える。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにする」（CNCF クラウドネイティブ Definition）
着目すべきは青字に記載したとおり、クラウドネイティブの定義は、必ずしもクラウドやコンテナの使用を前提にしていないことである。最も代表的なアプローチとしてコンテナ技術が挙げられているものの、それが必須ではないことを提案側は認識しておく必要がある。
では、要素として挙げられている「回復性」「管理力」「可観測性」「疎結合システム」「堅牢な自動化」によって、どこまで企業側のニーズに応えられるかを図表2に示す。
ここで明らかなように、クラウドネイティブの要素を実現することで企業側ニーズへの対応が可能となり、かつ堅牢な自動化の恩恵を受けてコストも抑えられる。
では、「回復性」「管理力」「可観測性」「疎結合システム」「堅牢な自動化」とは、具体的に何を実施すれば要素として十分なのだろうかを次に考えてみよう。
クラウドネイティブの要素
堅牢な自動化については言葉のとおりなので本稿では省略する。その他の要素について、以下のようにブレークダウンして検討する。
回復性
クラウドネイティブにおける回復性とは、「基盤の障害時やリソース枯渇時に、ユーザーが意識することなくAutomaticに復旧・拡張が行われる状態」を指している。
自己回復性／自己最適化の特性を備えながら、無停止更新にも対応できるような構成を意識することが重要である。
具体的にそれらを担保するには異常状態の検知と状態分析、分析結果による具体的対応の実行がループされている状態を目指す必要がある。この「定常状態」「監視・検知」「状態分析」「実行」のループを図示したのが、図表3である。
管理力
クラウドネイティブでの管理力とは、「基盤を構成する要素の起動・停止・変更などを一括して管理し、それらの申請やテスト承認を含めた業務プロセスまで効率的に行える仕組みを用意している状態」を指している。
立ち上げからテスト、リリースまでを含めた一連の開発プロセスをどれだけ自動化しているかが重要であり、管理力の低い状態であると、プロセス内での承認など、とくに人を介する項目で遅延が発生しやすくなる。
それらを防ぐには、常にサービスやシステムの全体構成が開発者と承認者との間で共有され、リリースまでのプロセスが自動化されており、稼働対象の基盤に依存しないリリース方法を確立する必要がある。
このような、「システム資産の共有と適切な管理」「業務プロセスまで含めたシステム化と高いユーザービリティ」「複数環境の管理範囲拡大」を示したのが図表4である。
可観測性
クラウドネイティブでの可観測性とは、「どこで、いつ、何のシステム要素が連携しているかを把握できる状態」を指している。
前述の回復性や管理力の向上により、新しいアプリケーションやインフラが即時に拡張／新設できるようになった場合、その都度、増減する観測対象をダイレクトに把握する必要がある。
そのため可観測性では、「観測対象からの能動的な観測データ送信」が有用であるとされる。またそれにより、観測ツール側には不特定多数の対象から五月雨式にデータが送られてくるので、それらを分類／整理して表示すること、高いユーザービリティで羅列・表示できることが求められる。
このような、「能動的なテレメトリー・データの集約」「集約されたデータの解析」「複雑な監視構造を簡潔に確認できるユーザービリティ」を示したのが図表5である。
疎結合システム
クラウドネイティブでの疎結合システムとは、「2つ以上の基盤構成要素が、ゆるやかに結びついている状態」を指す。これはシステム基盤というより、アプリケーション側の構成に近い要素となる。
各機能を司るシステムが、相互の仕様変更に影響されない形で結合している状態を指しており、各機能がAPI経由で呼び出されることを前提に構成する。
回復性や管理力の向上により、迅速にサービスを追加・更新することに対して、自身と関連の強い（自プログラムと結びつきが強い）機能への開発時期調整やテスト調整などのリードタイムをできるだけ解消するために、疎結合システムの実装が推奨される。
ここまで、クラウドネイティブが目指す要素を一般的な概要レベルで説明してきた。次に、これらを実現するには具体的な技術要素として何が必要かを解説する。
クラウドネイティブ実現に必要な技術要素
CNCFでは、これまでに述べたクラウドネイティブの要素を満たすためにTrail Mapを示している（図表6）。
ここでは、具体的な技術要素として以下を挙げている。
1 CONTAINERIZATION
アプリケーション稼働環境をコンテナ化し、あらゆるサイズおよび依存関係を含めて機能を最小単位で分割する。
2 CI/CD
変更、テスト、デプロイまでが一貫して連続されるように、継続的インテグレーション／継続的デリバリーを実施する。
3 ORCHESTRATION&APPLCATIONDEFINITION
コンテナ化されたアプリケーションを自動的に展開・管理・拡張する。
4 OBSERVABILITY&ANALYSIS
稼働コンテナのトレーシング、ロギング、モニタリングソリューションを選択する。
5 SERVICEPROXY, DISCOVERY, &MESH
細分化されたサービス間通信でのサービス発見（Service Discovery）や分散トレーシングなどの機能を分離し、サービスメッシュ化する。
6 NETWORKING&POLICY
コンテナ化されたサービス間、または外部とコンテナ間におけるネットワーク接続性およびネットワークポリシーを構成する。
7 DISTRIBUTEDDATABASE&STORAGE
単一もしくはHA構成のデータベース以上のパフォーマンスや回復力、拡張性が必要な場合に分散型データベースを検討する。
8 STREAMING&MESSAGING
JSON-REST以上のパフォーマンスが必要な場合に、RPC FrameworkであるgRPCやmulti-modal messaging systemであるNATSなどの使用を検討する。
9 CONTAINERREGISTORY&RUNTIME
コンテナのランタイムイメージをスキャン、認証、保管する管理方式を検討する。
10 SOFTWAREDISTRIBUTION
TUF（The Update Framework）と呼ばれる開発者のソフトウェア更新時のセキュリティ担保のために、攻撃者からリポジトリや署名キーを保護する。
CNCFではクラウドネイティブなサービス実現に向けて上記の項目を順番に実行するアプローチを提唱しているが、すべてを実行する必要はなく、ユーザーのニーズに合わせた取捨選択があってしかるべきである。
本稿のテーマである「ユーザーが求めるITサービス基盤」には、以下の要素が最低限必要になると考える。
CONTAINERIZATION
CI/CD
ORCHESTRATION&APPLCATIONDEFINITION
OBSERVABILITY&ANALYSIS
CONTAINERIZATIONは現状、最も回復性の高い仮想化ソリューションである。
CI/CDとORCHESTRATION&APPLCATIONDEFINITIONにより開発からリリースまでのプロセスを自動化して管理力を高め、OBSERVABILITY&ANALYSISにより可観測性の高いソリューションを構成する。
ここで重要なのは、クラウドネイティブなサービスの提供にはクラウドやコンテナなどの技術提供方式や仮想化の改修だけでは十分ではなく、さらにベンダーだけの開発方式やプロジェクト管理の変更では実現できない点である。
開発からリリースまでには開発者だけでなく承認者、つまりユーザー側の体制や管理方式を改修しなければ、本当の意味でクラウドネイティブなシステムは完成しないことを意識しておかねばならない。
それでは以下に、実現方法として現在最も一般的なアプローチであるKubernetes Containerを取り上げ、これまでの仮想化と比較しながら、クラウドネイティブなサービスを構成するソリューションとして有用なのかどうかを解説する。
Kubernetes Container
コンテナの仮想化は、これまでのOS仮想化とは異なった仮想化方式であり、個別のOSを必要としないため起動イメージが軽量である点が特徴として挙げられる。
Kubernetesはコンテナおよびコンテナ管理のソリューションとして幅広く適用されており、各クラウドベンダーも自社サービスとしてKubernetesをベースにソリューションを展開している。
コンテナ仮想化の起動イメージの軽量さは単純に起動スピードの短縮にとどまらず、スピード短縮による回復性の高さであったり、起動イメージの可搬性が高いことによる管理力の向上などにも寄与しており、クラウドネイティブなサービス基盤を構成するソリューションとして有用である。
図表7に、コンテナ起動イメージがこれまでの仮想化方式のイメージと比較して軽量であることのメリットを示す。
ただしコンテナ基盤にするだけでは、クラウドネイティブサービスは実現できない。運用に関わるCI/CDや、可観測性を保つためのOBSERVABILITY&ANALYSISなどの対応を同時に実施しなければ、オペレーションに関する負荷が爆発的に増加する性質も同時にもち合わせている。そのため同じく重要なソリューションとして、ユーザーと会話する必要があるだろう。
図表8に、コンテナ仮想化環境がクラウドネイティブサービスにおいて、これまでの仮想化環境と比較して優位である点、憂慮しなければならない点を各要素別にまとめる。
クラウドネイティブなサービスを目指したソリューションとして一般的であるコンテナ仮想化技術を用いることは、回復性や疎結合システムを実現するうえで大きな効果をもたらす。
ただしそれと引き換えに、管理対象の増加や運用方針を再度検討する必要がある。基本的には全面移行という形ではなく、今までのサーバー仮想化と並行しながら最小構成での開発で効果検証することが多いが、その場合にはダブルオペレーションが発生することになる。
このあたりを理解したうえでユーザーに提案することで、コンテナ仮想化の運用についてユーザーと認識の齟齬なく進めることが重要である。
次に、筆者自身が関わったプロジェクト事例を紹介しておく。
これはAWSによりコンテナ仮想化技術を構築し、ここで述べたような管理力強化を狙いに、CI/CDの仕組みをユーザーとともに運用設計・システム構成した例である。
開発からリリースまでのプロセス内で、開発者であるベンダーと承認者であるユーザーの役割を明確に分離することで、開発者による誤った本番環境への反映を防ぐ。
またコード開発からコンテナへのデプロイをサービス内で自動化することで、開発していないコードが誤ってデプロイされるなどの人的ミスを防ぐ効果も期待できる。
これらの運用を実現するには、これまで説明したとおり、ユーザーも含めたプロジェクト全体でサービスリリース手段を検討する必要があり、場合によってはユーザー側の体制変更などが発生するケースも想定される。
運用フェーズに入ってから認識の齟齬による出戻りが発生しないよう、提案の段階で運用役割については認識合わせをしておく必要があるので、そのことは常に意識しておくべきである。図表9に、CI/CD運用に関する事例の具体的な内容を示す。
以上、本稿はクラウドネイティブが具体的に何を目的としたサービスであるかを今一度見直し、ユーザーとの認識の齟齬をなくし、製品ありきではなく、よりユーザーの環境に即した提案や設計を行えるように執筆した。
目指すべき姿とそれを実現するための手段を、合理性をもって取捨選択して提供することは、ユーザーの信頼につながり、ひいては個々人のエンジニアとして価値を高めることになると思う。
著者
小関 裕晶
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウドプラットフォーム#1
アドバイザリーITスペシャリスト
2009年、日本アイ・ビー・エム システムズエンジニアリング入社。金融業のお客様基盤保守チームのメンバー／リーダーを経験し、その後自動車業界のお客様にてAWSを中心にクラウド・コンテナ基盤の要件定義・構築・保守チームをリード。近年は、Infrastructure As Codeを用いた基盤構成の自動化案件にも従事。
［i Magazine・IS magazine］
