クラウドネイティブとは？普及の背景や代表的な技術を紹介

クラウドネイティブの普及と背景

クラウドネイティブが提唱された背景には、クラウド技術の発展だけではなく、クラウドに関わる開発手法・プロジェクト・概念の存在があります。これらは近年のソフトウェア開発現場の共通言語として急速に広まりつつあります。

アジャイルとDevOps

インターネットとクラウドによりビジネス環境は大きく変化しました。従来、買い切り型で提供されていたITサービスは、定額型のサービスが一般的になりつつあります。このようなサービスでは、利用傾向や顧客の要望が運営企業に日々フィードバックされます。フィードバックを素早く・継続的にサービスに反映することを目的とした開発手法が、アジャイルとDevOpsです。

一般的に、アジャイルは開発プロジェクトの期間を機能単位で短く区切ります。その結果、機能のリリース頻度が多くなり、顧客からのフィードバックを迅速に集め、開発に反映できるのです。またリリース後には必ずチーム内で振り返りを行い、開発プロセスそのものについても改善を行います。

DevOpsは開発と運用の距離をできる限り縮めて組織的な課題を解決し、迅速なサービスの価値向上を行うソフトウェア開発手法です。従来、ITサービスは一度開発が完了すると、そこから先は運用担当が管理を行なっていました。しかし定額型のサービスでは、開発と運用の業務が交互に発生します。そのためシステム開発者・インフラ担当者・サポートチームなど異なる職種の壁を越えて、サービスの開発と運用の課題を定義します。そして組織文化の変化に伴う改善活動を全員で行うのです。

柔軟にコンピュータリソースの確保や削減ができるクラウドは、アジャイル・DevOpsと非常に相性がいい開発手法です。クラウド・アジャイル・DevOpsを適用することで、状況の変化が非常に早いビジネス環境にも追随して価値提供を行えます。

CNCFプロジェクト

CNCFは2015年の設立以来、117のクラウド技術に関するプロジェクトをホストしています。これらのプロジェクトは成熟度のレベル順にSandbox、Incuvated、Graduatedとして分類されます。CNCFがこれらのプロジェクト運営を行うことで、クラウド技術に関する世界標準が示されているのです。特にGraduatedに含まれるKubernetesはクラウドの代表的な技術です。クラウドネイティブを自社で推進する上でも、CNCFがホストするクラウド技術は必ずチェックしておきましょう。

コンウェイの法則

コンウェイの法則は「システム設計は、組織構造を反映させたものになる」という概念です。例えば一つの大きな組織で開発したシステムはモノリシックな構成となります。一方で複数の小さなチームで開発したシステムは、小さなシステムが連携するマイクロサービスの形となります。この考えを逆手にとって、システム設計にあわせて組織構造を反映させる考えが「逆コンウェイの法則」です。クラウドネイティブを推進する上で、システム設計は開発効率に大きな影響を持ちます。組織体制と理想とするシステム設計に乖離があり、システム設計があらぬ方向に進まないように、組織とシステム両面の検討が必要です。

クラウドネイティブの技術

コンテナやマイクロサービスはクラウド時代の代表的な技術です。クラウドが普及したことで、多くの概念やソフトウェアが新たに登場し、今後もその数は増えることが予想されます。ここではCNCFが定義するクラウドネイティブの中でも紹介された、5つのクラウドに関する技術を紹介します。

コンテナ

コンテナはホストOSの環境を利用して、アプリケーション環境に必要な仮想環境を構築する技術です。仮想マシンに比べて環境構築が高速かつ、設定ファイルが非常に軽量で再配布が容易です。従来、仮想環境構築にはOSのインストールが必要で、立ち上げにかかる時間やファイル容量が膨大でした。コンテナはその課題を解決する技術として広く普及しています。

マイクロサービス

マイクロサービスは独立した複数の小さなシステムで、一つのサービスを構成するソフトウェアアーキテクチャです。個々のシステム間はHTTPやgRPCなどで通信を行います。ここのシステムを独立して開発・運用できるため、並行した機能開発や高頻度のリリース、システム毎に異なる技術選定などを実現できます。

一方でマイクロサービスはシステム数に比例して実行環境を構築しなければなりません。これらの環境はコンテナで構築されますが、数が増えると管理コストも肥大化します。Kubernetesではそのような多数のコンテナの監視やデプロイを自動化してくれます。

サービスメッシュ

マイクロサービスを構成するシステム数の増加は、システム間の通信複雑化にもつながります。このような複雑化した通信の、負荷分散や通信トラフィックの最適化の課題をサービスメッシュは解決します。サービスメッシュの代表的なツールはIstioです。

宣言型API

宣言型APIはサービスのあるべき状態を支持するプログラムです。コンテナオーケストレーションツールのKubernetesは宣言型APIの代表的なソフトウェアです。例えば、Kubernetesを利用するユーザはコンテナの起動数を5つと指定します。Kubernetesは5つのコンテナが常に起動するように、コンテナの削除や追加を自律的に制御します。もしKubernetesが命令型APIであった場合、ユーザはコンテナの削除や追加を都度実行しなければなりません。

イミュータブルインフラストラクチャ

従来、長期間のシステム運用ではOSやミドルウェアを個別に更新していました。そのためシステムのインフラはその変更毎に状態が変化します。しかしこのような繰り返しの変更はアプリケーションの動作への影響範囲が不明瞭で、動作保証が難しいという課題を抱えていました。

イミュータブルインフラストラクチャでは運用中の実行環境に変更を加えません。変更が適用された実行環境を新たに立ち上げ、古い環境と入れ替えます。もしデプロイ後にアプリケーションが動作しない場合は、即座に古い環境に戻すことも可能です。実行環境の状態管理が不要となるため、障害や管理コストの削減につながります。

クラウドネイティブアプリケーションとは？

クラウドネイティブアプリケーションはクラウド上での動作を前提としたアプリケーションです。クラウドネイティブの技術により構成することで、スケーラブルで高可用なサービスを実現できます。

クラウドネイティブアプリケーション開発

クラウドネイティブアプリケーション開発で広く受け入れられているのが、「Twelve-Factor Application」という考え方です。2012年にPaaSのHerokuから提唱された考え方で、12個の原則で構成されます。2016年にはクラウド普及を背景に、3つの原則を加えた「Beyond the Twelve-Factor App」が提唱されています。

1. コードベース（Codebase）
   • コードベースとアプリケーションが1対1の関係として管理されており、そこから複数のデプロイが行われます。一般的にはGithubやGitlabといったソース管理ツールが用いられます。
      
2. 依存関係（Dependencies）
   • 全てのアプリケーションの依存関係は、パッケージ管理ファイルで明示的に宣言されます。パッケージは各サービス間で依存関係がなくなるように管理を行い、その変更がシステム全体に影響しないようにします。
      
3. 構成・設定（Configuration）
   • 環境変数などの設定はコード上から厳密に分離して管理を行います。これらの構成情報はコード外の構成管理ツールによって行われ、デプロイ毎に正しい設定が適用されるように管理運用します。
      
4. 補助的サービス（Backing Services）
   • 補助的サービスはデータ ストア、キャッシュ、メッセージ ブローカーなどが該当します。これらの機能はアプリケーションと分離されており、URLを介してアプリケーションからアクセスを行います。
      
5. ビルド、リリース、実行（Build, release, run）
   • ビルド、リリース、実行の工程を厳密に分離します。 それぞれの工程に対しては一意のIDでタグ付けを行い、ロールバックできる機能をサポートする必要があります。 CircleCIやGithubActionなどのツールを用いて実行管理されることが一般的です。
      
6. プロセス（Processes）
   • アプリケーションは、実行中の他のサービスから分離され、独自のプロセス内で実行する必要があります。永続化が必要なデータについてはデータベースなど補助的サービスを用いて外部化します。
      
7. ポートのバインド（Port binding）
   • 個々のアプリケーションは、独自のポートで公開されるインターフェースと機能を含めて、自己完結している必要があります。 これによりアプリケーションへのアクセスが可能になります。
      
8. 並行性（Concurrency）
   • アプリケーションのプロセスは複数のプロセスが並行して処理できるように、プロセスの分離を行います。たとえばHTTPリクエストはWebプロセス、バックグラウンドタスクはワーカープロセスによって処理を行います。
      
9. 廃棄容易性（Disposability）
   • アプリケーションの実行環境が高速に起動・削除できるようにします。これにより素早く柔軟なスケールと、コードや設定に対する変更があった場合に、素早いデプロイを容易にし、本番環境へのデプロイの堅ろう性を高めます。この原則にはコンテナ（Docker）の利用が一般的です。
      
10. 開発と運用環境の一致（Dev/prod parity）
    • 開発・検証・本番環境など、アプリケーションが動作する環境間での差分をできる限り小さく保ちます。差分が大きくなるとデプロイに必要な検証コストなどが肥大化するため、安定的かつ高頻度のリリースが難しくなります。
       
11. ログ（Logs）
    • アプリケーションから出力されるログをイベントストリームとして扱います。出力先となるイベントストリームは一ヵ所所に集約し、データマイニングツールなどを用いて永続化を行います。
       
12. 管理プロセス（Admin processes）
    • データベースのスキーマ変更など、アプリケーション運用に必要な管理タスクは、1回限りのプロセスとして実行されます。管理タスクはアプリケーションの実行環境とは分離された、運用環境で管理されます。
       
13. API ファースト（API First）
    • 全てのコードは別のサービスから使用されると仮定し、エンドポイントを設けます。フロントエンドクライアント、ゲートウェイなどがこれらのエンドポイントを利用します。
       
14. 遠隔監視（Telemetry）
    • アプリケーションとその動作の詳細確認は、その機能に特化したサーバ上で集約して実施します。そのためにはシステム監視に関する機能がアプリケーションに含まれている必要があります。
       
15. 認証・認可（Authentication and authorization）
    • 利用者に固有のIDを割り当てて、利用者の本人確認を行います。またその固有IDに対してサービスが保持する機能へのアクセス権を付与します。

クラウドネイティブアーキテクチャ

クラウドネイティブアプリケーションを実現する上ではクラウドの特性に関する深い理解と、それを考慮した設計が求められます。大手IaaSであるAWS・GCP・Azureでは各社毎に基準となる設計指針を公開しています。

各社毎に表現が異なるものの、その中身はおおむね共通しています。従量課金を考慮した適切なコスト管理。不特定多数からの攻撃を想定した堅ろうなセキュリティ対策。システムの回復性や可用性の実現。利用者数に応じたコンピュータリソースの効率的な利用。システム運用業務の自動化。この5つの要素がクラウドネイティブアーキテクチャを構成する要素と考えられます。

クラウドネイティブの実現

クラウドネイティブを実現する上で、CNCFが公開しているCloud Native Trail MapとCloud Native Landscapeが役立ちます。

Cloud Native Trail Map

Cloud Native Trail MapはCNCFが公開している、クラウドネイティブを実現するための推奨ステップです。ステップは全部で10個あり、その全てを適用する必要はありません。またその順番についても、自社の状況や実現したいシステム環境によって大きく変わります。自社でクラウドネイティブを実現する上で、技術の全体像を把握する指針としての活用がオススメです。10個のステップは以下の通りです。

Cloud Native Landscape

Cloud Native Landscapeはクラウドネイティブ実現を考える企業や開発者を支援するリソースマップです。その全体像はGithubで公開されており、Trail Mapもその一つの要素として公開されています。人によっては、Cloud Native Interactive Landscapeという「クラウド技術を検索できるWebページ」のことをCloud Native Landscapeとして想起する方もいます。クラウドネイティブを実現する過程で、さまざまな角度からソフトウェアの比較を行えます。

まとめ

クラウドは従来のオンプレミス環境と共通する側面も多く残す一方、クラウドならではの特徴も多いです。その可能性を最大限引き出すためには、クラウド技術への深い理解が求められます。そんな中クラウドネイティブはクラウドを推進する企業や開発者にとっての指針となります。

関連サービス