クラウドネイティブが盛り上がっているので、概要と、関連団体と、サービスメッシュと、サーバーレスと、ハイブリッド/マルチクラウドについて調べてみた

この記事は ラクス Advent Calendar 2019 の18日目の記事です！

先日は @Y-Kanoh さんのAIBOの記事でした！
AIBOもいろんなAPIが公開されているのを初めて知りました！
（高額なのに購入されてて、すごいです…。）

はじめに

はじめまして！
株式会社ラクスパートナーズのさとうと申します。

Qiitaはいつも読者側で投稿したことがなかったので、今回が初投稿です。

社内の肩書はクラウドエンジニアで、普段はAWS上でのインフラ管理・構築・検証を主に行っています。

最近クラウド界隈ではクラウドネイティブ技術が盛り上がっており、私も多分に漏れず今年は情報収集に明け暮れました。
クラウドネイティブ技術やその周辺情報については様々なメディアで取り上げられており、Qiitaにも多くの投稿がありますが、
今回は自身の今年1年のまとめとして、「クラウドネイティブの概要」「関連団体」「サービスメッシュ」「サーバーレス」「ハイブリッド/マルチクラウド」についてまとめてみました！

クラウドネイティブ概要

最初に、クラウドネイティブの定義や技術の変遷についてざっくりまとめてみたいと思います。

定義

クラウドネイティブ技術のプロジェクトを多数ホストしている団体、Cloud Native Computing Foundation (CNCF)が定義している内容が、同団体のGithubリポジトリに公開されています。

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。

また、atmarkITの記事で、青山真也さんと草間一人さんの対談でも分かりやすくまとめられています。
草間一人×青山真也 クラウドネイティブ対談

変遷

いろいろな情報を参考にしたのですが、ソースを忘れてしまいました・・・。
ざっくりとした個人的なまとめとしては、

1. 情報技術の発達とともに、サービス・アプリケーションが複雑/肥大化してきたり、ビジネス展開・開発と運用の迅速化が必要になってきて、今までのやり方（オンプレミスでの管理、モノリシックアーキテクチャ、仮想マシン上でのアプリケーション展開、人の介在する割合が多い運用など）ではキツくなってきた
2. そのため、アプリケーションをマイクロサービスアーキテクチャにしてアプリケーション1つ1つの容量を小さくしたり、迅速性と再現性が高くマイクロサービスと相性が良いコンテナ技術を採用した。また拡張性・柔軟性があり、インフラ管理が少ないパブリッククラウドサービスを利用するようになってきた
3. そしたらコンテナが多すぎて管理がキツくなってきたので、コンテナオーケストレーションで管理を自動化しつつ、宣言的なAPIやインフラコード化を実現した
4. そしたらネットワークが複雑になりすぎたのでサービスメッシュができた
5. また、インフラ管理をほとんど意識しないサーバーレス技術もできた
6. んで、こういった技術を総称して、クラウドネイティブ技術って呼ぼうぜ！！！

みたいな感じでしょうか？
すっごい見辛いまとめで申し訳ありません・・・。
2～3あたりは並行で進んできた部分もあると思うので、完全に順番分けはできないかもしれません。
また、間違っている部分も大いにあると思うので、ご指摘あればよろしくお願い致します！

関連団体

次に、クラウドネイティブ技術に関わる団体についてまとめたいと思います。
団体と一口に言うと範囲が広すぎますので、今回は上述のCNCFおよび、そのCNCFをホストしているThe Linux Foundation (LF)にフォーカスを当てたいと思います。

The Linux Foundation (LF)

画像出典：https://www.linuxfoundation.jp/

LFは、Linuxを始めとした、多数のオープンソースプロジェクトをホストしている非営利団体です。
本当に多数のプロジェクトをホストしていますが、例えば以下のようなプロジェクトがあります。

• いわずもがなのLinux
• 自動運転やコネクテッドカーの技術を開発しているAutomotive Grade Linux
• Jenkinsなどの継続的デリバリーツールのプロジェクトをホストしているContinuous Delivery Foundation (CDF)
• AI、機械学習のプロジェクトをホストするThe LF AI Foundation
• フロントエンドのデータクエリ言語GraphQL関連のプロジェクトをホストするThe GraphQL Foundation
• ブロックチェーン関連のプロジェクトをホストするHyperledger
• JavaScript関連のプロジェクトをホストするThe OpenJS Foundation（2019年3月にJS FoundationとNode.js Foundationが統合されて誕生）
• エッジコンピューティングのプロジェクトをホストするLF Edge
• オープンソースのCPU命令セットであるRISC-Vの仕様策定や、エコシステム開発を行っているRISC-V Foundation

現在のIT業界で話題になっている技術のほとんどが網羅されている印象です。
ホストしているプロジェクトの推定開発コストは16B USD(約1.7兆円) 、関連イベントに参加するエンジニアは年間35,000人とのことです。ヤバいですね。
そしてCNCFも、このLF傘下のプロジェクトのひとつです。

Cloud Native Computing Foundation (CNCF)

画像出典：https://jp.linkedin.com/company/cloud-native-computing-foundation

CNCFは、上述の通り、オープンソースのクラウドネイティブ技術のプロジェクトをホストするLF傘下の団体です。

組織体制

Github上に憲章がまとめられており、以下のようなことが記載されています。

1．使命　
財団の使命は、クラウドネイティブコンピューティングをユビキタスにすることです。
Cloud Native Computing Foundationは、オープンソースのベンダー中立プロジェクトのエコシステムを促進および維持することにより、このパラダイムの採用を促進しようとしています。最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。

5．理事会　(Governing Board)
CNCF理事会は、CNCFのマーケティングおよびその他のビジネスの監督と予算決定を担当します。

6．技術監視委員会　(Technical Oversight Committee (“TOC”))
TOCは、CNCFの技術ビジョンを定義および維持します。理事会が設定したCNCFの範囲内で新しいプロジェクトを承認し、プロジェクトの概念アーキテクチャを作成します。プロジェクトの調整、プロジェクトの削除またはアーカイブを実施します。

TOCは、毎月第1火曜日の午前8時に会議を行い、毎月第3火曜日にプロジェクトのプレゼンテーションを行っているようです。（ https://github.com/cncf/toc ）
ここにはまとめきれませんが、とてもしっかりとした組織体制で運営されているようです。
非営利団体の組織運営というものを知りませんでしたが、ここまでしっかりとやっていてすげぇなーと思いました。（小並感）

プロジェクト

現在ホストしているプロジェクトは多数ありますが（プロジェクト一覧）、2019年11月現在Graduatedレベルとなったプロジェクトには、下記があります。
（プロジェクトのレベルについては後述します。）

• Kubernetes：Googleで開発された、コンテナーオーケストレーションツール
• Prometheus：SoundCloudで開発された、システムモニタリングツール
• Envoy：Lyftで開発された、レイヤー7プロキシツール
• CoreDNS：Kubernetesクラスタ内でPodの名前解決やサービスディスカバリに利用される、軽量かつ高速なDNSサーバー
• containerd：Docker®の一部として開発された、ハイレベルコンテナランタイム
• Fluentd：Treasure Dataで開発された、ロギングツール
• Jaeger：Uberで開発された、分散トレースシステム
• Vitess：YouTubeで開発された、MySQLインスタンスのクラスター展開・スケーリング・管理ツール

画像出典：https://www.cncf.io/projects/

Journey Report

いくつかのプロジェクトは、変遷をJourney Reportとしてまとめて公開しています。
コントリビューター数やコミット数、国や企業別の貢献度など、様々な視点でまとめられていて、面白かったです。

• Kubernetes Project Journey Report
• Envoy Project Journey Report
• Prometheus Project Journey Report

TrailMap, LandScape

CNCFは、現在のクラウドネイティブ技術をLandScapeとしてまとめています。
また、クラウドネイティブ技術を取り入れる方法としてTrailMapを紹介しています。
画像が大きいので記事には貼りませんが、気になる方はリンクや他記事を参考にしていただければと思います。

しかし、TrailMapについては、上述の青山真也さんと草間一人さんの記事でいろいろと突っ込まれていました・・・。

プロジェクトのレベル

CNCFでは、ホストしているプロジェクトのレベルを明確に定めています。

画像出典：https://www.cncf.io/projects/

レベル	要件
Sandbox	CNCFのTOC（Technical Oversight Committee: 技術監視委員会）から最低2人のスポンサー
Incubating	最低3つの独立したエンドユーザーが本番環境で正常に使用、健全な数のコミッター、明確なバージョン管理、公式リファレンス実装etc
Graduation	少なくとも2つの組織のコミッター、コアインフラストラクチャイニシアチブベストプラクティスバッジを達成および維持、CNCF行動規範を採用、プロジェクトのガバナンスとコミッターのプロセスを明確に定義etc

他にもしっかりとした要件があるようなので、ご興味があればこちらを参照してください。

メンバーシップ

現在CNCFに加入している企業はこちらで確認することができます。
メガパブリッククラウドはもちろんのこと、Apple、AlibabaやHuaweiなどの中国企業など、そうそうたる企業が名を連ねています。
国内企業では主に、Fujitsuがプラチナメンバーとして、NECがゴールドメンバーとして加入しています。

会員費用や特典

CNCFのメンバーには、下記のクラスと特典があるようです。

クラス	費用	特典
プラチナ	$370,000	理事会に1人の代表者任命、理事会の小委員会または投票メンバーに1人の代表者指名、Webや資料の目立つ場所にロゴ配置、エンドユーザーでもある場合その全権限
ゴールド	$120,000	ゴールドメンバー5人ごとに理事会に1人の代表者を任命、最大3人のゴールド代表者を任命、エンドユーザーでもある場合その全権限
シルバー	企業規模別、最大$50,000	シルバーメンバー10人ごとに理事会に1人の代表者を任命、最大3人のシルバー代表者を任命、エンドユーザーでもある場合その全権限
エンドユーザー	企業規模別、最大$4,500	エンドユーザーアドバイザリーコミュニティに参加、エンドユーザーテクニカルアドバイザリーボードに1人の代表者を指名
アカデミック	$1,000	各種ミーティングへの参加、KubeConなどのスポンサーシップ割引、Webや資料にロゴ表示
非営利	$500	アカデミックと同じ？

参考：https://www.cncf.io/about/join/

翻訳が良くできず詳しくわからない部分もありますが、有名企業が高いクラスの会員になっているのは、理事会への代表者任命などの理由があるのかなと思いました。
もちろん、オープンソースの貢献という理由もあると思いますが、トレンドの技術を主導できる立場になることは、特にIT企業としては高い費用を払ってもなる価値があるのかな、と調べていて感じました。

サービスメッシュ

次に、サービスメッシュについてまとめました。

定義

定義ですが、「クラウドネイティブ技術」のように明確な定義を示しているものは見つかりませんでした。
上述のCNCFのブログでサービスメッシュについて述べている記事がありましたので、ここではそれを抜粋します。

サービスメッシュは、サービス間通信を処理するための専用インフラストラクチャレイヤーです。最新のクラウドネイティブアプリケーションを構成する複雑なサービストポロジを介した信頼性の高いリクエスト配信を担当します。

私としては、「クラウドネイティブ概要」で記したように、コンテナ＋マイクロサービスで通信が複雑になってきたから、通信の可視化と割り振り＋障害連鎖の防止のために利用するもの、という印象です。

構成

画像出典：https://www.nginx.com/blog/what-is-a-service-mesh/

次に、サービスメッシュのアーキテクチャーです。
管理側のコントロールプレーンと、サービスのサイドカープロキシ（主にEnvoy）のデータプレーンで構成されます。
サービス間通信をサイドカープロキシに仲介させることで、アプリケーションの実装を変更することなく、トラフィック管理やセキュリティ、テレメトリーを実現するようです。

Qiitaでは、@mamomamoさんがとても分かりやすくまとめてくださっていました。
https://qiita.com/mamomamo/items/92085e0e508e18bc8532

プロジェクト、サービス

次に、プロジェクトやサービスについてです。

CNCFのLandScapeには、主なサービスメッシュのプロジェクトについてまとまっています。
また、こちらのサイトでは、主要なサービスメッシュの比較がわかりやすくまとまっていました。

ここでは、いくつか抜粋し、簡単な紹介をしたいと思います。

Istio

画像出典：https://landscape.cncf.io/
公式ウェブサイト：https://istio.io/

おそらく、一番有名なサービスメッシュではないかと思います。
現状、最も機能が豊富なようで、サービスメッシュのデファクトスタンダートといえそうな印象です。

開発主体	バージョン	プロキシ	プラットフォーム	オープンソース
Google、IBM、Lyft	1.4.2	Envoy	Kubernetes, Consul & Nomad	〇

Linkerd

画像出典：https://landscape.cncf.io/
公式ウェブサイト：https://linkerd.io/

LinkerdはCNCFのIncubatingプロジェクトで、最初に開発されたサービスメッシュのようです。

開発主体	バージョン	プロキシ	プラットフォーム	オープンソース
Buoyant	2.6	Linkerd2 proxy	Kubernetes	〇

AWS App Mesh

公式ウェブサイト：https://aws.amazon.com/jp/app-mesh/

AWS App Meshは、AWSが提供しているマネージドサービスのサービスメッシュです。
App Mesh自体の利用は無料で、コンテナと共にデプロイされたプロキシが使用するEC2インスタンスやFargateのCPU/メモリに対してのみ料金が発生するようです。
AWS内のサービスですが、パートナー企業として、DataDogやHashiCorp、Tetrateなどの企業が名を連ねています。

開発主体	バージョン	プロキシ	プラットフォーム	オープンソース
AWS	-	Envoy	ECS, Fargate, EKS, EC2	-

Consul Connect

画像出典：https://landscape.cncf.io/
公式ウェブサイト：https://www.hashicorp.com/products/consul/

Consul Connectは、TerraformやVagrantなどで有名なHashiCorpが開発しているサービスメッシュで、オープンソース版とエンタープライズ版があるようです。

開発主体	バージョン	プロキシ	プラットフォーム	オープンソース
HashiCorp	1.6	デフォルトはEnvoyだが変更可	Consul, Nomad, Kubernetes	〇

Kuma

画像出典：https://landscape.cncf.io/
公式ウェブサイト：https://kuma.io/

KumaはKong社が開発しており、2019年9月10日にオープンソースで提供を開始した、新しいサービスメッシュです。
今までのサービスメッシュよりも、使いやすさに念頭を置いているとのことです。
atmarkITにリリース時の記事が掲載されていました。

開発主体	バージョン	プロキシ	プラットフォーム	オープンソース
Kong	0.3	Envoy	Kubernetes, VMs	〇

サーバーレス

次に、サーバーレス技術についてまとめました。

定義

まず、定義についてです。
上記でいろいろと述べたCNCFですが、サーバーレス技術に関してもホワイトペーパーをまとめています。
このホワイトペーパーは英語なのですが、嬉しいことにatmarkITに日本語翻訳版が載っています。

以下、定義の抜粋です。

サーバレスコンピューティングとは、「サーバ管理を必要としないアプリケーションの構築と実行の概念」です。 これは、1つまたは複数の関数としてバンドルされたアプリケーションがプラットフォームにアップロードされた後、 その時々のニーズを正確に反映した実行、スケーリング、請求が行われる、よりきめ細かなデプロイメントモデル を表しています。
サーバレスコンピューティングとは、「コードをホストして実行するためにサーバを使用しない」という意味では ありません。運用エンジニアがもはや必要とされないという意味もありません。むしろ、「 サーバレスコンピューティ ングの利用者が、サーバのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティプランニ ングに時間とリソースを費やす必要がなくなった」という考え方を指しています。代わりに、これらのタスクと機能 は全てサーバレスプラットフォームによって処理され、開発者および IT／運用チームから完全に抽象化されます。

当たり前の話ですが、「サーバーがない」わけではなく、「サーバー管理を必要としない」ということのようです。

また、サーバーレスの変遷や技術については、Microsoftの川崎さんが分かりやすい資料を公開して下さっています。

プロジェクト、サービス

次に、プロジェクトやサービスについてです。
またまたCNCFですが、Landscapeに現在のサーバレスのプロジェクトやサービスがまとめられています。
画像出典：https://landscape.cncf.io/format=serverless

AWS LambdaやAzure Functionsなどのマネージドサービスは多数の記事があると思いますので（言い訳）、
今回は、この中からServerless FrameworkとKnativeについて、簡単な紹介をしたいと思います。

Knative

画像出典：https://landscape.cncf.io
公式ウェブサイト：https://knative.dev

Knativeは、Google、IBM、Red Hat、Pivo​​tal、SAPなどが開発している、Kubernetesをベースとしたサーバーレスプラットフォームです。
Kubernetesの各種タスク（コンテナのビルド、構成ファイルの生成、ネットワークルールやロギングの設定など）を隠蔽して管理を簡素化し、Kubernetesでのサーバーレスなワークロードの実行を可能にすることを目的としているようです。

Knativeは「Serve」と「Event」というコンポーネントで成り立っており、Serveはリクエスト受信/ルーティング/スケールを行い、Eventはイベントトリガーのセットアップを行うようです。
元々は「Build」というコードのビルドやパッケージングを行うコンポーネントもあったようなのですが、現在は分離してTektonというGoogleが開発しているCI/CDツールとなったようです。
（参考：https://www.atmarkit.co.jp/ait/articles/1909/20/news068.html ）

Serverless Framework

画像出典：https://landscape.cncf.io
公式ウェブサイト：https://serverless.com

Serverless FrameworkはServerless, Inc.が開発している、サーバーレスアプリケーションの構成管理ツールです。
AWS、Azure、GCP、Alibaba Cloud、Knativeなど様々なプラットフォームに対してデプロイでき、サーバーレス版のTerraformといった印象です。
オープンソースエディションとプロエディションがあり、プロエディションはさらにフリー、チーム、エンタープライズとクラスが分かれています。
Qiitaでは、@horike37さんが使い方を分かりやすくまとめて下さっていました。( https://qiita.com/horike37/items/b295a91908fcfd4033a2 )

ハイブリッド/マルチクラウド

最後に、ハイブリッド/マルチクラウドについてまとめたいと思います。

2019年に、GoogleがAnthos、MicrosoftがAzure Arcというハイブリッド/マルチクラウドプラットフォームを発表しました。

画像出典：https://cloud-ja.googleblog.com/2019/07/bringing-hybrid-and-multi-cloud-to-our-apac-customers-with-anthos.html

画像出典：https://azure.microsoft.com/ja-jp/services/azure-arc/

どちらも自社クラウド上のリソース、オンプレミス、他社クラウドのリソースを一括管理できるという点では似ていますが、
AnthosはKubernetesクラスターをベースに、Azure ArcはKubernetesクラスターに加えてWindowsとLinuxベースのサーバーも一括管理できるという点が異なっているように見受けられます。

一方、AWSはハイブリッドクラウド環境として、AWS Direct Connectを提供していたり、今年のre:InventでAWS OutpostsのGAを発表しましたが、マルチクラウドに関してはまだ言及していないように思います。
　

三社の方針の違いは、TechTargetの記事でまとめられています。
また、Azure Arcに関しては、@Yoshiyuki03さんがまとめてくださっていました。( https://qiita.com/Yoshiyuki03/items/99a6c42e5f24085da14b )

また、IBMはMulticloud Managerというサービスを展開しており（こちらもKubernetesベース？）、
Oracle Cloudは、Azureとの相互接続を発表しています。

この流れの理由として、ベンダーロックインを避けたいユーザーニーズもあると思いますが、パブリッククラウド首位のAWSから顧客を奪いたいという狙いもあるのでしょうか。

まとめ

情報をまとめていく中で、以下の点を今後意識していきたいなと感じました。

• Kubernetesを軸にしたエコシステムはもの凄い勢いで拡大しているので、Kubernetesへの理解を深めていく
• Kubernetesなどのクラウドネイティブ技術の情報を得るために、LFやCNCFの動きを追っていく
• ハイブリッド/マルチクラウドの流れが進みそうな印象があるので、1つのパブリッククラウドプロバイダーの理解・技術を深めるのも大事だが、各プロバイダーの特色を把握することや、ハイブリッド/マルチクラウドも提案・構築できるようになる

正直、今回は裾野を広げすぎた感がありました・・・。
サービスメッシュ、サーバーレス、ハイブリッド/マルチクラウドに関しては、簡単な情報のまとめだけで「やってみた」まではいけなかったので、今後は実際に触ってみて理解を深めたいと思います。

明日は @west-c さんの投稿になります！お楽しみに！