クラウドネイティブを推進する約500団体が参画する CNCF (Cloud Native Computing Foundation)に、クラウドネイティブの定義が公開されている。これは、IT業界で働く者の基礎知識であると言えるので、クラウドネイティブの定義を詳細に調べた結果を以下にまとめる。
CNCFとは
CNCFは2015年7月に発表され、約50社が集まり2016年1月に正式発足した。最初の発表から4年後2019年11月のメンバーは約500団体で、大手クラウド事業者、ミドルウェア企業、ハードウェア製造企業、オープンソース・ソフトウェア企業、大学、その他非営利団体などが加入している。
CNCFは、The Linux Foundationの下で運営され、クラウドとコンテナに関連する横並びの活動として、Cloud Foundry Foundation、Xen Project, Open Container Initiativeがある。
次の図は、CNCFランドスケープと名付けられたWebページの全体図と一部の拡大である。ここにはカテゴリごとにグループ化され、CNCFが推進するOSSプロジェクト、参加企業のプロプライエタリ・ソフトウェアとオープンソース・ソフトウェアが混在して配置されている。
クラウドネイティブの定義
CNCFランドスケープから読み取れる様に、CNCFのクラウドネイティブの掲げる思想の元に、500団体が参画して、活動が続いている。つまり、CNCFが定義するクラウドネイティブは、業界として公式な見解とみなすことができる。このことは、IT業界で働く者にとって、大変重要な基礎知識と言える。
クラウドネイティブの定義は、CNCFのドキュメントが置かれたGitHubに、日本語を含む各言語で記載されている。
クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型API(declarative APIs)があります。
これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。
Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。
参考URL: https://github.com/cncf/toc/blob/master/DEFINITION.md
最初の段落で、対象範囲と価値が述べられ、アプローチの代表例が明記されている。さらに、次の段落では、アプローチによって得ることができる効果が示される。そして、三つ目の段落で、特定ベンダー主導ない中立な立場であることを民主化という言葉で表現して、ユーザーやコミュニティ中心に進めることが宣言されている。
この中で注目するべき点は、アプローチであり、それがイノベーションの推進力となるからである。アプローチは、英語で「接近する」を意味する以外に、問題などへの「取りかかり」を意味があることから「推進方法」と意訳できると考える。
クラウドネイティブの特徴的アプローチ
クラウドネイティブのアプローチに挙げられたキーワードに注目して、それぞれの内容について概要をまとめる。
- コンテナ
- イミュータブル・インフラストラクチャー
- マイクロサービス
- サービスメッシュ
- 宣言型API(declarative APIs)
- コンテナオーケストレーター Kubernetes
- モニタリングとロギング
1.コンテナ
コンテナとは、アプリケーションのコードと、Linux OSを含む、すべての依存関係をパッケージ化したソフトウェアの一式である。そして、コンテナは、OSレベルで仮想化して、複数のコンテナを OS カーネル上で直接実行する。言い換えると、仮想マシンのようなハードウェアスタックの仮想化、すなわち、ソフトウェアによってハードウェアの振る舞いを再現した上でOSを稼働させることをしない。そのため、コンテナは、ファイル換算でサイズが小さく、プロセスのように起動が早く、少ないメモリ容量で実行できる。
コンテナは、Linuxカーネルの機能を使って実現されるが、Docker社によって、その標準が作られ、コンテナは、ある環境から別のサーバー上の環境へ簡単に移動できる。つまり、アプリケーションをサーバー環境から分離して自由な移動を可能にする。このことは、開発環境、テスト環境、本番環境で、アプリケーションは均一な環境で稼働させることができることを意味し、後述のイミュータブル・インフラストラクチャーを実現する一つの方法である。
参考資料:
- What is a Container?, https://www.docker.com/resources/what-container
- What's a Linux container?, https://www.redhat.com/en/topics/containers/whats-a-linux-container
- What are Containers and their benefits, https://cloud.google.com/containers/
2.イミュータブル・インフラストラクチャー
コンテナへ移行だけではデメリットしかない。コンテナ移行に加えてイミュータブル・インフラストラクチャーの概念を取り入れた開発と運用サイクルを回すことで、クラウドネイティブのメリットを受けることができる重要なポイントである。
2.1.この手法の概要と名前の由来
イミュータブル(不変の)・インフラストラクチャー(Immutable infrastructure)は、ITサービス運用における アプリケーションのデプロイ、および、サービス管理の手法である。この手法では、アプリケーションの構成要素(components)に変更が発生した場合、本番環境の中で変更するのではなく、変更済みのアプリケーションのコードと依存するソフトウェア一式を再デプロイして置き換える手法である。
アプリケーションのコードと依存するソフトウェア一式とは、アプリケーションの実行コード、プログラミング言語ランライム環境、OSライブラリ、ミドルウェアのクライアントライブラリ、設定ファイルなど、アプリケーションを実行に必要なソフトウェアのセットである。
従来のITサービス運用では、アプリケーションのコードなど構成要素に変更の必要がある場合、本番サービスを中断して、または、サービス継続中に、ソフトウェアの構成要素の変更が実施されてきた。
しかし、イミュータブル・インフラストラクチャーでは、稼働中であっても、前述の一式を丸ごと置き換える。例えば、ソフトウェアのセットの中で一つの要素に変更に必要があった場合でも、そのセットの中で部分的変更を行うのではなく、ソフトウェア一式を再アセンブルして置き換える。ここで、アセンブルと呼ぶ理由は、アプリケーションのソースコードからのコンパイル、コンテナのビルド、ライブラリのインストール、設定ファイルの配置、起動シェルスクリプトのセットなど、必要となるパーツ（ファイル）を集めて組み立てるように、一式を作成するからである。 ここでソフトウェアの一式としている実態は、コンテナとなっているケースと、ディレクトリとファイルのセットのケースがある。
イミュータブル・インフラストラクチャーと呼ばれる理由は、ソフトウェアの一式としてアセンブルされた状態から変更できないためである。具体的には、プログラム言語のライブラリの一つに変更がある場合でも、一部を変更するのではなく、一式を作りなおす。そして、新たに作りなおした一式を、本番環境にデプロイする前に、アプリケーションの正常稼働を確認する。
つまり、イミュータブル・インフラストラクチャーは、アプリケーションが依存する基盤となるソフトウェアが、随時変更されない、不変であることを意味する。
2.2.解決する課題
アプリケーションのコードと、その基盤となるソフトウェアに変更がある場合に、一部を変更して使い続けるのではなく、一式を作りなおす手法は、様々なメリットをもたらす。
- 実行環境の一部を変更するのではなく、変更時は一式を作り直して再デプロイするため、構成のドリフト（揺らぎ）を軽減
- 脆弱性が発見されたソフトウェアを変更と品質の担保が容易となることから、脆弱性による攻撃の脅威を軽減
- 複数の固有設定や複数バージョンのファイルから、リストアするのではなく、一式を置き換えるため、予定外の停止時間を軽減
- 繰り返し一式をデプロイする結果として、十分にテストされ検証済みの共通イメージを構築
- イミュータブル・インフラストラクチャーは、アプリケーションのコードと依存するソフトウェア一式の運用に必要な自動化を促進
- イミュータブル・インフラストラクチャーは、ITの複雑さを軽減して、障害発生を減少させる
- アプリケーションが更新されるたびに、テスト済みの最新のインスタンスが開始されるため、サーバーのパッチ適用や構成の変更が不要となり、変更を追跡して管理する必要が無い。
- アプリケーションの更新後に問題が発生した場合、以前の既知の正常なインスタンスにロールバックが簡単
- 個々のサーバー内のコンポーネントを変更しないため、予測できない動作やコード変更の意図しない結果が生じる可能性を削減
イミュータブル・インフラストラクチャーの効果は、アプリケーションのコードと依存するソフトウェア一式を形成し、デプロイのサイクルを繰り返すことから得られる。
アプリケーションをコンテナへ移行するだけでは、クラウドネイティブのメリットを受けることはない。むしろ、それまでのサーバー運用と同じことを実施していては、デメリットが大きい。つまり、コンテナへ移行と合わせて、イミュータブル・インフラストラクチャーの概念を取り入れた開発と運用サイクルを回すことで、クラウドネイティブのメリットを受けることができるようになる。
2.3 The Twelve-Factor App という手法
PaaS (Platform As a Service ) は、利用者自身がコンテナをビルドすることは無いが、アプリケーションが依存するOSやライブラリ等の基盤を変更できない点で、イミュータブル・インフラストラクチャーの実装形態の一つである。そのため、クラウドネイティブのドキュメントなどからも、参考にするべき手法であるとして、The Twelve-Factor App が参照されている。
The Twelve-Factor Appは、もともと Herokuプラットフォーム上での仕事の経験を元に書かれたアプリケーションの設計原則である。Herokuは、アプリケーションのコードとマニフェストを共に登録することで、そのサービスの内部で、ビルドしてコンテナ化して実行する。そして、データベースなどのアプリケーションに必要なサービスは、メニューから選択して対応づけることで、アプリケーションのコードからアクセスできる。つまり、Heroku は PaaSである。類似する機能を持つソフトウェアに、Cloud Foundry や、Red Hat OpenShift の S2I機能がある。
以下にThe Twelve-Factor Appのサマリーを挙げておく。
| No | プラクティス | 説明 |
|---|---|---|
| 1 | コードベース | バージョン管理されている1つのコードベースと複数のデプロイ |
| 2 | 依存関係 | 依存関係を明示的に宣言し分離する |
| 3 | 設定 | 設定を環境変数に格納する |
| 4 | バックエンドサービス | バックエンドサービスをアタッチされたリソースとして扱う |
| 5 | ビルド、リリース、実行 | ビルド、リリース、実行の3つのステージを厳密に分離する |
| 6 | プロセス | アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する |
| 7 | ポートバインディング | ポートバインディングを通してサービスを公開する |
| 8 | 並行性 | プロセスモデルによってスケールアウトする |
| 9 | 廃棄容易性 | 高速な起動とグレースフルシャットダウンで堅牢性を最大化する |
| 10 | 開発/本番一致 | 開発、ステージング、本番環境をできるだけ一致させた状態を保つ |
| 11 | ログ | ログをイベントストリームとして扱う |
| 12 | 管理プロセス | 管理タスクを1回限りのプロセスとして実行する |
The Twelve-Factor Appは、Heroku を想定して書かれたもので、コンテナをベースとしたオーケストレーターに適用するには、少々読み替えが必要となる。その様な適用法の記事がインターネット上あるので、参考資料に挙げておく。
参考資料 :
- immutable infrastructure, https://searchitoperations.techtarget.com/definition/immutable-infrastructure
- How do you build 12-factor apps using Kubernetes?, https://www.mirantis.com/blog/how-do-you-build-12-factor-apps-using-kubernetes/
- Kubernetes & 12-factor apps, https://medium.com/ibm-cloud/kubernetes-12-factor-apps-555a9a308caf
3.マイクロサービス
コンテナなどの技術を使用して、そして、イミュータブル・インフラストラクチャーの概念を取り入れたアプリケーションに、残る課題は、スケーラビリティ、可用性、そして、リリースまでの期間短縮である。特にスマートフォンやタブレットが、アプリケーションのクライアントターミナルとして普及することで、次の段階の対策が必要となっている。
これら前述に挙げた課題に対するソリューションとして注目されるのが、マイクロサービスである。
マイクロサービスは、マイクロサービス・アーキテクチャーとも呼ばれ、アプリケーションを構築するためのアーキテクチャ上のアプローチである。アプリケーションは、一つの実行単位で動作するのではなく、小さな機能ごとに分割され、それぞれが独立したサービスとして動作するために、マイクロサービスと呼ばれる。
独立した小さな単位のサービスは、以下の特性を有する。
- 保守とテストが簡単
- サービスどうしが疎結合
- 独立してデプロイ可能
- ビジネス機能を中心に編成
- 小さなアプリケーションチームが所有
これらの特性により、開発サイクルを短くすることができ、より早くビジネスの要求に対応できる。また、小さな機能単位に分割して、独立して稼働するため、デベロッパーが把握するべき範囲が少なくなるので、学習期間が短くなり、デベロッパーの早期の戦力化が可能となる。
非機能要件の観点からは、一つのマイクロサービスに問題があっても、全体へ与える影響が限定的になり、可用性が向上する。同一のマイクロサービスの数を増やして並列度を高くすることで、処理性能をスケールできる。
このマイクロサービスには利点も多いが、下記に挙げるような欠点も特徴である。これは一つのモノリスから、細分化することに由来する欠点である。
- 同一モジュール内でメソッド等をコールから、独立したサービスへのアクセスに変わるため、複雑化する
- 小さくても独立した単位のアプリケーションとなるため、データベースやHTTPサーバーなどの重複が増え、効率は下がる
マイクロサービスには利点も多いが、欠点も大きいので、アプリケーションは、最初からマイクロサービスアーキテクチャーで作るべきではない。とする議論もある。最初はモノリスから始めてモジュール化し、モノリスが問題になったらマイクロサービスに分割するのが良いとされる。
参考資料:
- Microservice Architecture, https://microservices.io/
- Microservices, https://martinfowler.com/articles/microservices.html
- What are microservices?, https://www.redhat.com/en/topics/microservices/what-are-microservices
4.サービスメッシュ
マイクロサービスの導入を決めた際に、運用に立ちはだかる最大の課題は、複雑化への対処である。
例えば、Kubernetesの基本機能(サービス)だけを使用したマイクロサービス間の連携では、マイクロサービス相互の依存関係や通信状態、特定のマイクロサービスの処理時間といった、システム内部の活動状況が把握できない。このような管理レベルで、本番サービスに適用した場合、マイクロサービスの一部にスローダウンが発生すると、問題箇所を特定したり、部分的にスケールするなどの対処の判断が難しくなる。
この課題に取り組むのが、サービスメッシュである。つまり、サービスメッシュはマイクロサービスを運用する上で重要なインフラストラクチャ・レイヤーである。
サービスメッシュとは、ネットワーク上のサービスを抽象化して、マイクロサービス間に、信頼性と高速な通信を提供することを基本に、可観測化、アプリケーションの識別、ロードバランシング、認証、暗号化が含まれる。
サービスメッシュの仕組みを簡単に説明する。ネットワークを流れるリクエストは、サービスメッシュが提供するプロキシによって、マイクロサービスへの経路が決められる。このプロキシの存在によって、サービスメッシュを利用するためのコードを各マイクロサービス内部のコードに組み込む必要は無い。このプロキシは、KubernetesのPodオブジェクトのサイドカーと呼ばれる機能を利用して、コード変更不要の利便性を提供する。
さらに、代表的なサービスメッシュの中央コントローラーは、サービスメッシュ内部の接続の調整と協調機能を担う。具体的にコントローラーは、アクセス制御、ネットワークと性能の管理、そして、Kubernetesにようなコンテナ実行環境と統合である。
サービスメッシュのOSSプロジェクトには、以下がある。
- Istio Google, IBM などで開発。様々なデプロイメントの形態に対応
- Linkerd Buoyant,IncがCNCFに寄贈 CNCFプロジェクトで推進
- Network Service Mesh L2/L3のネットワークのサービスメッシュを実現
- Envoy Istioで利用するプロキシで、通常はサービスメッシュに分類されない。
- Conduit 独自の超軽量プロキシを仕様
- Red Hat OpenShift Service Mesh Istio、Kiali、Jaegerをベースとして、OpenShift v4から提供開始
様々なサービスメッシュが乱立する状態で、共通の標準を定義を目指す Service Mesh Interface（SMI）がある。Kubernetesで実行されるサービスメッシュの仕様であり、さまざまなプロバイダーが実装できる共通の標準を定義する。 https://github.com/deislabs/smi-spec
分散トレーシング
サービスメッシュと合わせて利用されるのが、分散トレーシングである。これは、マイクロサービスで構築したアプリケーションのプロファイルと監視に使用される。特に障害が発生した箇所とパフォーマンスの低下の原因を特定するために用いられる。
マイクロサービスでは、リクエストに応答を返すまでに、さらに複数のマイクロサービスを呼び出す。そのため、コードをトレースしただけでは、アプリケーションの動作を理解し、問題をトラブルシューティングすることができない。このような課題に対処するためのツールでCNCFのプロジェクトを以下にリストする。
- OpenTelemetry 分散トレーシングの仕様
- Jaeger Go,Java,Node,Python,C++など対応
- Zipkin C#,Go,Java,JavaScript,Ruby,Scala,PHP他に対応
- OpenTracing 言語 Go,Java,PHP,Python,Rubyなど,対応トレーサー Jaeger,Datadogなど
参考資料 :
- What's a service mesh? And why do I need one?, https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/#_ga=2.111844161.453151037.1572081779-129353835.1572081779
- "Service mesh data plane vs. control plane" by Matt Klein の日本語訳, https://qiita.com/seikoudoku2000/items/d4c6b41337f03df0e005
- What is a service mesh, and how does it relate to networking?, https://searchnetworking.techtarget.com/answer/What-is-a-service-mesh-and-how-does-it-relate-to-networking
- What Is A Service Mesh?, https://avinetworks.com/what-are-microservices-and-containers/
5.宣言型API (Declarative APIs)
クラウドネイティブのソフトウェアのAPIは、宣言型APIを採用している。この方式を採用することで、自律的な動作や制御が期待できるため、アプリケーションのサービス運用の複雑さが軽減され、シンプルになる。そして、AI技術を活用した高度な自律的な自動運用への期待もできる。
宣言型APIとは、次の挙げる手続き型プログラミング言語やオブジェクト指向型プログラミング言語から、コールすことができて、目的とする状態をAPIを通じて対象に指示する。
APIで目的とする状態の指示を受けたソフトウェアは、その状態を維持するように、自律的に動作する。例えば、アプリケーションのインスタンスを3つ起動した状態を指示した場合、そのインスタンスの一つが何かの障害で停止すると、代替のインスタンスを起動して、インスタンス数 3 を維持するように振る舞う。
KubernetesのAPIでは、URLを指定してHTTPSプロトコルでRESTサービスをアクセスして利用する。さらに、プログラミング言語から利用しやすいように、Python, Go, Javaなどのライブラリが提供される。宣言型APIとして設計された KubernetesのAPIは、手続き型プログラミング言語のように実行すべき命令を順に記述して操作するAPIではなく、Kubernetesのオブジェクトの望まれる状態を、JSONやYAML形式で与えるAPIである。
参考資料 :
- 手続き型言語【procedural language】命令型言語/imperative language, http://e-words.jp/w/%E6%89%8B%E7%B6%9A%E3%81%8D%E5%9E%8B%E8%A8%80%E8%AA%9E.html
- Declarative programming, https://en.wikipedia.org/wiki/Declarative_programming
- https://kubernetes.io/docs/concepts/overview/kubernetes-api/
6.コンテナオーケストレーター
ここまで挙げてきたクラウドネイティブな要素を実現するためのプラットフォームとして、コンテナオーケストレーターがある。これまでに幾つかのコンテナオーケストレーターが提案されてきたが、本番運用に提供可能なものは Kubernetes と言っても過言ではない。
以下にKubernetes(以下K8s)の代表的な機能を列挙する。これらの機能を基礎にして、クラウドネイティブなソフトウェアが動作する。
- 複数のコンテナを連携させる組み合わせ利用する機能
- 負荷に応じてコンテナ数を増減するスケールアウト機能
- 無停止でアプリケーションを更新するロールアウト＆ロールバック機能
- ストレージ装置の論理ボリュームをコンテナにマウントする永続ストレージ機能
- 障害等によって失ったコンテナを自己修復する機能
- クラスタを論理的に分割して、共存環境同士が影響しない様に、リソース使用量の上限を制御する機能
- クラスタを構成するノード間を横断的にアクセスできるクラスタネットワーク機能
- 稼働状態を見守るCPU使用時間、メモリ使用量、通信量などメトリックスとログの集中管理機能
CNCFがリリースするK8sは、企業が製品化する前のアップストリームK8sと呼ばれ、最先端の機能を利用できる一方で、リリースサイクルが短く、運用には高度なスキルが要求される。これに対して、Red HatがK8sを製品化した OpenShift Container Platform(以下OCP)では次の特徴をもつ。
- OCPでは、CICD機能とコンテナレジストリ機能が統合されている
- 上流K8sの保守9ヶ月で終了に対して、OCPは長期のサブスクリプションサポートがある
- OCPは、RedHat認定コンテナなど企業利用に適する脆弱性対応がある
上記の理由から、OCPは、企業利用でのK8s運用に適している。
7.モニタリングとロギング
クラウドネイティブでは、、ロギングとメトリックスモニタリングは、個々のコンテナに設定するのではなく集中管理する。つまり、コンテナは、独立した仮想サーバーのように動作する。従って、これまでのように、各コンテナにログを蓄積して、個々にライフサイクルを管理することもできる。しかし、それではコンテナを維持管理する必要となるため、イミュータブル・インフラストラクチャーの利点が損なわれる。
コンテナのCPU使用時間やメモリ使用量などメトリックスは、コンテナオーケストレーターが単位時間あたりの統計値を持っている。そのため、メトリックス監視システムは、コンテナオーケストレーターを通じて情報を取得できる。
ログ管理システムがログを収集する方法として、2つのルートがある。一つ目は、ログ転送のサイドカーを利用する方式で、サイドカーは、ファイルに書き出されたログ情報をログ管理システムへ転送し、コンテナ内部にファイルが蓄積しないように処理する。二つ目は、コンテナ内部の標準出力と標準エラー出力を、コンテナオーケストレーター経由でログ管理システムへ転送する方法である。
前述のどちらもアプリケーションのコンテナ上のコードに変更を加えることなく、メトリックスやログを集中管理できるため、コンテナの突然の置換えに対して情報が失われることがない。
これらモニタリングシステムを自社で運用することを望まない企業も少なくなくない。そのため、モニタリングシステムは、OSSとしてインストールするタイプ、それから、クラウドのSaaS型サービスタイプなど、複数が提供される。
メトリックスのモニタリングシステム
3つのパターンがあり、Kubernetes上にデプロイして利用、外部のサーバーにインストールして利用、KubernetesにエージェントをインストールしてSaaSとして利用などがある。
CNCFホストのプロジェクト
- Prometheus メトリックス データ収集と時系列管理
- Cortex メトリックス データ収集と時系列管理
CNCF参加企業のOSS
- Grafana グラフィカル表示
- Kiali Istio Service Meshのための表示 (RedHat)
- Weave Scope コンテナ連携状態などのグラフィカル表示
CNCF参加企業のクラウド型サービス
ログ管理システム
- Fluentd ログのフィルタリングと転送ツール CNCFプロジェクト
- Elastic サーチエンジンをログ管理システムとして利用
- Grafana Loki Prometheusに似たログ管理システム
- Logstash ログの転送と処理ツール
クラウドネイティブの課題と解決策
マイクロサービスは、今日のサービス志向アーキテクチャ(SOA)のデジャブの様だと評する声もある。もちろん、マイクロサービスは、現実的なボトムアップな展開を目指し、使用する技術も洗練されシンプルである。それでも、マイクロサービスによる利益と引き換えに、複雑性が増すことによって、運用が難しくなることは避けがたい。例えば、アプリケーションのコンテナ数を増やして水平スケールしたとしても、データベースに性能をスケールする機能が無ければ、ユーザーの要求に答えることができない。
前述のCNCFランドスケープには、クラウドネイティブ推進の課題に取り組むプロジェクトが多数登録されている。特にCNCFが支援（ホスト）するプロジェクトは、重要度の高いものが多い。注意点としては、それぞれのプロジェクトの成熟度は様々であり、ただちに、本番サービスの運用に適用できるとは限らない。また、CNCFからリリースされるオープンソースを、ユーザー企業が運用できるか、十分なスキルを保有するかなども考慮しなければならない。
CNCFに多くのOSSプロジェクトが活動している。ここに、CNCFがホストするプロジェクトの例を3つほど挙げておく。
- Vitess (ビッテス) NoSQLのスケーラビリティとMySQLを統合して、スケーリング可能なデータベースを実現する
- TiKV (タイケビー) 分散トランザクション機能を持った、キーバリューストアのデータベース
- OpenEBS コンテナ接続ストレージ(CAS)のアーキテクチャを用いてスナップショットとクローン、バックアップとリストアを実現する
僅か4年のクラウドネイティブの取り組みは、IT業界の長い歴史から見れば、始まったばかりである。現在は黎明期であり、これからの発展と貢献を期待したい。
参考資料:
* 8 ways to make sure you really need microservices, https://www.zdnet.com/article/8-ways-to-test-your-readiness-for-microservices/
まとめ
クラウドネイティブは、何かのソフトウェアを導入することで、クラウドネイティブになるものではなく、それに適した開発と運用の考え方、推進方法が欠かせない。そして、マイクロサービスには大きな利点と欠点があり、この欠点を補うため サービスメッシュなどのツールや標準などの整備が進んでいる。しかし、マイクロサービス化という道は、ビジネスの課題を解決するための一つの選択肢であり、採用に当たっては適切な判断が必要であることも忘れてはいけない。
宣言的APIは、運用管理を大幅に省力化が期待でき、Kubernetesでも利用される。また、メトリックスとロギングは、従来と大きく異なり、個々のコンテナに設定しない。これにはサイドカーやコンテナオーケストレーターを通じて、対象のコンテナに変更を加えることなく、監視システムへ連携する。
取り巻く環境として、スマートフォン、タブレット そして、IoT などの活用は、ビジネスの駆動力となっており、アプリケーション、すなわち、情報システムには、厳しい非機能要件が提示されるようになってきた。これに対応するには、課題も少なくないが、クラウドネイティブと共に進むことが、ベストプラクティスであると考える。