"We predict that serverless computing will grow to dominate the future of cloud computing."
—Berkeley CS dept, 'Cloud computing simplified: a Berkeley view on serverless computing'
⇧ 「サーバレス」を制する者は、「クラウドコンピューティング」を制す？
Stateless functions are a great tool that has its place in the cloud computing toolkit, but for Serverless to reach the grand vision that the industry is demanding of a Serverless world while allowing us to build modern data-centric real-time applications, we can't continue to ignore the hardest problem in distributed systems: managing state—your data.
⇧ 「サーバレス」で問題になってるのが、データの状態管理ってことらしいですと。
んで、「Cloudstate」っていうプロジェクトってのは、
The Cloudstate project takes on this challenge and paves the way for Serverless 2.0. It consists of two things:
⇧ 「Serverless 2.0」 に向かって頑張ります、そのために、
の2つに取り組みます、ってことらしいですと。
「TCK」は、おそらく、
A Technology Compatibility Kit (TCK) is a suite of tests that at least nominally checks a particular alleged implementation of a Java Specification Request (JSR) for compliance. It is one of the three required pieces for a ratified JSR in the Java Community Process, which are:
- the JSR specification
- the JSR reference implementation
- the Technology Compatibility Kit (TCK)
⇧ 「Java Specification Request (JSR)」で取り組んでる、Javaに関する実装なんかを確認するための一連のテストである、「Technology Compatibility Kit (TCK) 」を指してるんじゃないかな？
Java Community Processに関するカテゴリ。 このカテゴリの記事のサブジェクトはJava Specification Request (JSR)で開発された、または開発されているJavaプラットフォームテクノロジや仕様である。
⇧ ってな具合ですと。
「サーバーレス」って、「クラウド」でしか実現できないって思っていたんですが、オンプレミスな環境でも実現できるようになるようですかね、まだ実験段階ではあるらしいですが。
あ、どうも、ボクです。
というわけで、「サーバーレス」にレッツトライ～。
結論から申し上げますと、まだ、Javaのチュートリアル的なものが未完？っぽい感じなので、cloudstate を実際に使うところまでは進めてないので、お時間のある方のみご照覧ください。
サーバーレスって？
そも、「サーバーレス」って？
その前に、Webにおいては、サーバサイドが抱える問題があるんだと。その問題とは、
Traditionally, we’ve built and deployed web applications where we have some degree of control over the HTTP requests that are made to our server. Our application runs on that server and we are responsible for provisioning and managing the resources for it. There are a few issues with this.
-
We are charged for keeping the server up even when we are not serving out any requests.
-
We are responsible for uptime and maintenance of the server and all its resources.
-
We are also responsible for applying the appropriate security updates to the server.
-
As our usage scales we need to manage scaling up our server as well. And as a result manage scaling it down when we don’t have as much usage.
まぁ、いろいろ問題はあるんだけど、サーバって常に稼働してるけど、必要な時だけ稼働させれれば、コスト削減できるしね、ってことが一番大きいのかと。
じゃあ、そんないろんな問題を解消してくれる、「サーバーレス」って？
Serverless computing (or serverless for short), is an execution model where the cloud provider (AWS, Azure, or Google Cloud) is responsible for executing a piece of code by dynamically allocating the resources. And only charging for the amount of resources used to run the code.
The code is typically run inside stateless containers that can be triggered by a variety of events including http requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (cron jobs), etc. The code that is sent to the cloud provider for execution is usually in the form of a function.
Hence serverless is sometimes referred to as “Functions as a Service” or “FaaS”.
Following are the FaaS offerings of the major cloud providers:
- AWS: AWS Lambda
- Microsoft Azure: Azure Functions
- Google Cloud: Cloud Functions
元々は、「クラウド」において生まれたアーキテクチャだったらしい。
「クラウド」は、使用した分が課金される仕組みのため、コスト削減するには、必要な時だけ稼働するようにしたら良いんじゃない？って考えが、「サーバーレス」ってことらしい。
「サーバーレス」については、
⇧ 上記サイト様の、「CNCF Serverless Whitepaper v1.0 」ってのが正式な文書ってことになるんですかね？
Serverless 2.0 って？
「cloudstate」 は、「Towards Serverless 2.0」 って言ってるんだけど、「Serverless 2.0」って、どんなものなのか？おそらく、まだ正式な文書は出てないと思うんだけど、
Serverless “2.0” = Serverless “1.0” + FaaS
って言ってる人がおると。
「Serverless 1.0」+「FaaS（Function as a Service）」 であると...
って「Serverless 1.0」が何を指すのかが分からないんだけど、
FaaSでは開発者は実行するプログラムにのみ注力すれば良いため、サーバーレスコンピューティングの実現形態の1つだと言うことができる。
一方で、認証機能やデータベースといった機能をAPIのような形で提供する「Backend as a Service（BaaS）」と呼ばれる形態のクラウドサービスも存在する。このようなサービスを利用することで、開発者はサーバー管理を行うことなく独自のサービスを開発・運用できるようになる。そのため、これらもサーバーレスコンピューティングの実現形態の1つと言われている。
ただ、最近ではこういったサービスはやや下火になりつつあり、サーバーレスコンピューティングという言葉がFaaSと同義で使われることも多いようだ。
⇧ 上記サイト様によりますと、日本だと、
ってなるらしい。
つまり、諸説入り混じると、いまのところ、
ってことになるらしい。
ますます、「Serverless 1.0」が何を指すのか訳が分からんですな。
ちなみに、「FaaS（Fraud as a Service）」っていう言葉もあるらしい。
FaaSとは、コンピューティングの分野における略語。
- Function as a service - クラウドコンピューティングにおけるサービスの種類の一つ。関数や機能といった小さな粒度でサービスを提供すること。サーバーレス・コンピューティング。
- Fraud as a Service - サービスとしての詐欺の意味。ネット上で行われる詐欺などの犯罪に必要な各種のサービスを提供するシステム。米EMCコーポレーション社のセキュリティ製品部門であるRSAセキュリティが2008年11月に提唱した用語。
⇧ ややこしいな～。
cloudstateのアーキテクチャ
まぁ、 むっちゃ端折るけど、
⇧ 全体像は上図のようになるそうです。
「lstio」のような「サービスメッシュ」から「Akka」に通信が来て、「Akka」が「Code」をキックオフする役割を担ってるんですかね？
「Akka」と「Code」は同一の「Pod」におりまして、上図のような「Pod」の構成を、「サイドカーパターン」と呼ぶそうな。この場合、「Code」がメインのコンテナで、「Akka」が補助的な「コンテナ」ってことになるのかな？
oreilly が公開してくれてる情報によると、「サイドカーパターン」っていうのは、「分散システム」における「デザインパターン」の1つらしく、
The first single-node pattern is the sidecar pattern. The sidecar pattern is a single-node pattern made up of two containers.
2. The Sidecar Pattern - Designing Distributed Systems [Book]
⇧ 1つの「ノード」で、2つの「コンテナ」によって構成されてるものを、「サイドカーパターン」と言うんですと。
It contains the core logic for the application. Without this container, the application would not exist.
2. The Sidecar Pattern - Designing Distributed Systems [Book]
⇧ 「コンテナ」の1つはアプリケーションの中心となる存在で、無くてはならないものでありますと。（以降、アプリケーションコンテナ）
In addition to the application container, there is a sidecar container. The role of the sidecar is to augment and improve the application container, often without the application container’s knowledge. In its simplest form, a sidecar container can be used to add functionality to a container that might otherwise be difficult to improve.
2. The Sidecar Pattern - Designing Distributed Systems [Book]
⇧ で、もう一つのほうの「コンテナ」（以降、サイドカーコンテナ）が、「アプリケーションコンテナ」の補助的な役割を受け持つんですと。
その際、「サイドカーコンテナ」は、「アプリケーションコンテナ」とは完全に分離できてる、つまり、疎結合でもありますと。
Sidecar containers are coscheduled onto the same machine via an atomic container group, such as the pod API object in Kubernetes.
2. The Sidecar Pattern - Designing Distributed Systems [Book]
⇧ 「サイドカーコンテナ」は、「Kubernetes」の「Pod」で管理されるのが有名ですかね。
In addition to being scheduled on the same machine, the application container and sidecar container share a number of resources, including parts of the filesystem, hostname and network, and many other namespaces.
2. The Sidecar Pattern - Designing Distributed Systems [Book]
⇧ 「アプリケーションコンテナ」と「サイドカーコンテナ」は、疎結合ではあるけれども、『ファイルシステムの一部、ホスト名とネットワーク、その他の多くの名前空間など、多くのリソースを共有する』とあるので、システム全体としては調和してると。
A generic image of this sidecar pattern is shown in Figure 2-1.
2. The Sidecar Pattern - Designing Distributed Systems [Book]
⇧ イメージ図は上図のようになりますと。
もう一度、「cloudstate」のアーキテクト図の「Pod」（Kubernetesで「コンテナ」を管理してくれるコンポーネントのこと）の部分に焦点を当ててみると、
⇧ まさに、「サイドカーコンテナ」と「アプリケーションコンテナ」いう構成になっていますと。
なので、「Code」のほうにアプリケーションサーバとかがあって、「Akka」からの「gRPC」の通信で、アプリケーションサーバが起動されて、「gRPC」との通信が終了したら、アプリケーションサーバが停止されるってことなんじゃないかな～、と。
たぶん、「サーバレス」な部分って言うとそこぐらいしか思いつかんし...
ちなみに、「分散システムデザインパターン」は日本語版も出てるみたい。
coludstateのインストール要件
そんな「cloudstate」をインストールしてみようと。
その前に、「cloudstate」 のインストールに必要な条件が、かなりある。
⇧ 「Kubernetes」は必須っぽい。「lstio」は「サービスメッシュ」の1種らしく、「サービスメッシュ」を使わないならば不要らしいけど、使うことを推奨らしいっすね。
ちなみに、「サービスメッシュ」は、
In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between microservices, often using a sidecar proxy.
⇧ 「マイクロサービス」を実装する上で避けて通ることのできない、「サービス間通信の複雑さ」を解消するために考え出されたアーキテクチャーらしいです。
Having such a dedicated communication layer can provide a number of benefits, such as providing observability into communications, providing secure connections, or automating retries and backoff for failed requests.
⇧ 「マイクロサービス」化したアプリケーションが通信する際の管理をし易くしようってことですね。
「サービスメッシュ」にも様々な種類があるらしく、それぞれ異なったアーキテクチャーだとは思いますが、イメージ的には、
⇧ 上記サイト様のような感じで、「サービスメッシュ」は、「Control Plane」と「Data Plane」で構成されてますと。
「Data Plane」側で「Kubernetes」で実現した「Pod」に、「Proxy」の役割を担う「コンテナ」を配置し「サイドカーパターン」を実装し、「Control Plane」側で「Data Plane」側を一元管理することで、「マイクロサービス」における通信の課題を解消しますと。
脱線しましたが、「cloudstate」 のインストールに必要なものが、まだあり、
Installation requirements
Installing Cloudstate requires cluster admin, so that the necessary Custom Resource Definitions (CRD) can be installed, and the necessary roles and role bindings can be created.
⇧ 「Kubernetes」で利用する「Custom Resource Definitions（CRD）」や「role」の設定なんかを実施できるように、「cluster admin」の権限が必要らしい。
ちなみに、「Custom Resource Definitions（CRD）」は、
リソース は、Kubernetes APIのエンドポイントで、特定のAPIオブジェクトのコレクションを保持します。例えば、ビルトインの Pods リソースは、Podオブジェクトのコレクションを包含しています。
カスタムリソースは、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。
https://kubernetes.io/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/
⇧ 「Kubernetes API」を拡張したものだけど、最近は、「Kubernetes」の一部が「カスタムリソース」で作られてるんだそうな...木乃伊取りが木乃伊になる？
ちなみに、「role」は、
Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization.
https://kubernetes.io/docs/reference/access-authn-authz/rbac/
⇧ 「Role-based access control (RBAC)」について言ってるんですかね？
RBACリソースは4つのリソースがある。RoleリソースとClusterRoleリソースとRoleBindingリソースとClusterRoleBindingリソース。
⇧ 上記サイト様によりますと、「role」は「Role-based access control (RBAC)」の機能の一部と考えれば良いんですかね？
「cloudstate」は、本当に、「Kubernetes」ありきなんだな～。
Operator requirements
The Cloudstate operator typically gets deployed to its own namespace, for the rest of this guide we will assume that is called cloudstate, and needs permissions to manage deployments, services, roles and role bindings in every namespace that it manages Cloudstate services in. Cloudstate provides a single deployment descriptor, available from the Cloudstate GitHub release page.
The deployment descriptor is built from the descriptors found in the operator deploy directory, and can be modified accordingly if, for example, more fine grained access controls wish to be granted.
⇧ 「Kubernetes」で利用する、「Operator」ってのも作っておいてあげる必要がありますと。
「Operator」ってのは、
Operatorを一言でまとめると、 "アプリケーション特化型のKubernetes Controller" です。
複雑になりがちなStatefulアプリケーションの運用（scaling, backup, failover, upgrade 等）を自動化することがOperatorの役割です。
⇧ 上記サイト様によりますと、「アプリケーション特化型のKubernetes Controller」とありまして、
An Operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl tooling.
⇧ 「Kubernetes」上のデプロイとかの管理を、まとめて管理しちゃおうってことかと。
To be able to make the most of Kubernetes, you need a set of cohesive APIs to extend in order to service and manage your applications that run on Kubernetes. You can think of Operators as the runtime that manages this type of application on Kubernetes.
⇧ 「Operator」なら、「Kubernetes」環境の一元管理ができるでしょ、ってことみたい。
ここまでをまとめると、
- Kubernetes 1.11 or later
- cluster admin ←デフォルトで用意されてる「ClusterRoleリソース」
- Custom Resource Definitions（CRD）
- Operator
- Istio 1.2.0 or later
の4つの用意が必要ですと。
実際には、「cluster admin」はデフォルトで用意されてるらしいので、用意するのは3つですと。
それにしても、分かりにくいドキュメントだわ...
「cloudstate」のインストールを試してる人が、今のところ誰もおらんというね...
「cloudstate」に関わってる人は、普及させる気が無いのかね...
cloudstateをインストールしてみる
というわけで、誰もトライしてる人が見当たらないのですが、「cloudstate」をインストールしてみます。
まずは、Kubernetesの環境ですが、
⇧ 上記記事で構築したものを利用していきます。
ただ、私は、「Kubernetes」に関する知識もほとんど無いので、もし、上記記事の内容を参考にしていただいて動かない場合などはご了承ください。
「Kubernetes」の環境を構成してる仮想マシンが準備できたらば、仮想マシンを起動。
「Operator」は「カスタマイズしたKubernetes Controller」なので、「Kubernetes Cluster」の中の「master node」に該当する仮想マシンにインストールしていく感じになるかと。
というわけで、「master node」に該当する仮想マシンにログイン。
で、残念ながら、仮想マシンを完全に停止した後に、再起動するとKubernetes Cluster環境が駄目になってしまうので、Kubeadmの初期化でKubernetes Cluster環境を作り直す必要がありそうです。
詳細は、
⇧ こちらをご覧ください。
で、Kubernetes Cluster環境が整ってることが確認できたらば、cloudstate用のnamespaceをKubernetes Cluster環境に作成します。
kubectl create namespace cloudstate
そしたらば、cloudstateに必要なoperatorをインストール。バージョンは、適宜、変更してください。今回は、0.5.0にしてます。
kubectl apply -n cloudstate -f https://github.com/cloudstateio/cloudstate/releases/download/v0.5.0/cloudstate-0.5.0.yaml
設定とかはいろいろすべきだとは思いますが、一応、cloudstateが利用できるようにはなったらしい。
GKE（Google Kubernetes Engine）でcloudstateを使う例の紹介で、
If using an event sourced entity, install Cassandra. This can be done from the Google Marketplace, by visiting the Cassandra Cluster, selecting configure, selecting your GCloud project, and then installing it in the Kubernetes cluster you just created. The defaults should be good enough, in our examples we called the app instance name cassandra. Note there is an option to use an in memory store if you just want to test it out, of course, as soon as your pods shut down (or if they are rebalanced), your store will be lost.
⇧ データの永続化をするなら、「Cassandra」とかいうデータベース使えって言ってますね。って言うか、結局、「クラウド」使ってるのかい...
「Cassandra」は、おそらく
Apache Cassandra（アパッチ カサンドラ）は、オープンソースの分散データベース管理システムである。元はFacebook社において大規模データの格納のために開発されたものである。Facebookのデータチームを率いるJeff HammerbacherはCassandraをAmazon DynamoDBのようなインフラストラクチャ上で動作するBigTableデータモデルであると表現している。
⇧ 「Apache Cassandra」のことだとは思うけど。
とりあえず、cloudstate をJavaで利用...準備できてないっぽい？
結局、Serverless の概念が曖昧な感じなんだけど、cloudstate を使ってみますか。
2019年10月5日（土）現在っていうか、記事書き始めてからだいぶ経ってるな、改めて、2020年5月3日（日）現在、使用できる言語としては、
⇧ 「Java」「Javascript」「Go」「Kotlin」の4言語らしい。
半年ぐらい経って、使用できる言語として「Go」「Kotlin」が増えたみたい。
今回は、Javaで。
で、結構、条件があって、
| 項目 | 必要条件 |
|---|---|
| Java Version | JDK 8 以上（推奨：JDK 11） |
| Build tool | 何でも良いらしい |
| protoc | protocコンパイラが必須だけど、ビルドツールにprotocプラグインあるらしい |
| docker | CloudStateは[Docker]を使用してKubernetesで実行されるため |
が、最低限必要らしい。
で、しかも、「Getting started with stateful services in Java」のページを見る限り
⇧ まだ、完全に実装されてないっぽい...
がビーン！
というわけで、もうしばらく待ってみますか。
盛大に時間を無駄にしてしまった（涙）。そして、PCのメモリ的に限界が来てる...
8GBじゃあ致し方ないかな～...
32GBぐらいのメモリのあるPCが欲しい...
今回はこのへんで。
