Google Cloudの用語集&解説集 part.2

Infrastructure as a Service/サービスとしてのインフラの略。Google Cloudではcompute engineであり、AWSではEC2である。仮想マシンを作成し、手動でアプリをデプロイしたりデータベースを仮想マシンにセットアップする。クラウド・プロバイダーは､物理的なハードウェアやネットワークを提供し､仮想マシンインスタンスを作成できるように仮想化ソフトウェアにアクセスできるようにする責任がある｡残りのことについては､ すべて自分に責任がある｡アプリケーションが適切にデプロイされていることを確認し､ オートスケーリングやロードバランシングの世話をする責任がある｡

Platform as a Service/ サービスとしてのプラットフォーム。AWSのElastic Beanstalk､ AzureのApp Service､ Google App Engineが該当する。クラウドの責任範囲が IaaSより広いが自由度は低い。クラウドプロバイダーはOSやオートスケーリングや可用性などに責任を負う。ユーザーはアプリのコードだけに集中できる。PaaSでは、顧客はVM instancesにアクセスできず、カスタム・ソフトウェアをインストールできずOSにもアクセスできない｡

Software as a Service/ サービスとしてのソフトウェア。必要な機能を必要な分だけ利用できるソフトウェアのこと。Gmailや Slackなどが代表例だ。端末へのダウンロードが要らずインターネット環境があればどこからでも利用できる。背後のアプリの設計や詳細を気にする必要はない。

異なる言語で構築されたマイクロサービスを1つの方法でデプロイすることができる。様々な言語で開発されうるマイクロサービスではデプロイが複雑になるが、それを解決できる。人気のあるコンテナ関連ツールがDockerである｡コンテナを使うためには、マイクロサービスごとにdocker imageを作成する｡コンテナの利点は３つ。⑴コンテナは軽量である。⑵コンテナがすべて互いに隔離されている。⑶クラウドニュートラルである(どこでも実行できる)。

複数あるコンテナのデプロイを実際に管理したり、負荷に応じて稼働するコンテナ・インスタンスの数をオートスケールできるようにしたい｡ 複数コンテナのクラスタへのデプロイを管理する｡これらのクラスタはそれぞれ複数のサーバーを持つことができる。コンテナ・オーケストレーターは以下の機能を提供する。⑴オートスケーリング。⑵サービス・ディスカバリー。⑶ロードバランシング。⑷ヘルスチェック(自己治癒力)。⑸ダウンタイムなしのデプロイメント。

100のマイクロサービスがあるかもしれない｡各マイクロサービスのURLを別のマイクロサービスにハードコードしたくない｡各マイクロサービスは､ コンテナ・オーケストレーターに他のマイクロサービスの場所を尋ねることができるので､URLをハードコーディングする必要はない。

docker imageには､ マイクロサービスを実行するために必要なものがすべて含まれている｡ たとえばdocker imageにはプログラミング言語に対応するランタイムが含まれている。なので JavaアプリやPythonアプリを実行できる。また docker imageにはアプリが必要とする依存関係も含まれている。 docker imageさえあれば、ローカルマシンでもクラウドでも同じように実行でき、コンテナを作成することができる。ローカルマシンとデプロイで同じ docker imageを使用できる。

Container as a Service(サービスとしてのコンテナ)。PaaSの種類の１つ。アプリの代わりにコンテナをプラットフォーム上で実行させる｡

Function as a Service (サービスとしての機能)。PaaSの種類の１つ。アプリの代わりに機能を実行する。

サーバーレスとはサーバーがないという意味ではない。サーバーレスを使用している場合でも、バックグラウンドでサーバーを使用している｡サーバーレスとは、サーバーがないのではなく、”サーバーについて気にする必要がない”ということを意味する。サーバーレスでは、サーバーの設定や可用性のスケーリングを心配する必要がなく､コードに集中できる。特徴は２つ。⑴インフラを気にしなくて良い。⑵関数やアプリの呼び出し回数に対して支払が発生する。

クラウドにおけるセキュリティは共有責任である｡ Googleとユーザーはそれぞれ特定の事柄について責任を負う。Google Cloudと顧客の間で責任を共有するのである。それぞれの責任の範囲はPaaSや IaaSなど利用するモデルによって頃なる。

アプリの設定を含むファイル。デフォルトの設定に使われる。これがdescriptor (プログラムからファイルを操作する際、操作対象のファイルを識別・同定するために割り当てられる番号)になる。

デプロイするときバックグラウンドで作成されるパッケージ。パッケージ作成には継続的インテグレーションと継続的デプロイのツールが使われる。このパッケージは Cloud Storageに送られる

Cloud Storageにアップロードされた Deployment packageにアクセスして、それを基にデプロイを実際におこなう。

さまざまなもののアクセス許可を設定する場所。ロール(役割)を与えられる。ロールは3種類。ベーシックロール、定義済みのロール、カスタムロール。part.3で詳しく解説する。

継続的インテグレーションは､ユニットテストとパッケージングを継続的に実行すること｡継続的デプロイは本番環境に近い環境でソフトウェアを継続的にテストする。part.3で詳しく解説する。

アクセス権を持つ者。デプロイを開始したときに自動的に作成される。このサービスアカウントに Cloud Storageにあるデータへのアクセス権( viewerの permission)を与える。part.3で詳しく解説する。

Google Cloudのストレージサービス。詳しくは今回後半で解説する。

特定のマイクロサービスのインスタンス数を増やせる｡マイクロサービスAのインスタンス数を増やしたければ､マイクロサービスAに属するポッドの実行数(Kubernetesクラスタのノード数)を増やす必要がある｡そこでクラスターの自動スケーリングが必要になる｡

複数のコンピュータやサーバーが連携して一つのシステムとして動作する集合体。Kubernetesは、クラスター上でコンテナ化されたマイクロサービス(アプリ)をデプロイ、管理するためのオーケストレーションツール。クラスターのリソースを効果的に活用し、アプリケーションのスケーラビリティや可用性を向上させる。クラスタは “Master Node”, “Worker Node”, “etcd”から構成される。

クラスタの中に複数個作成できる。各ノードにはそれぞれvCPUとメモリ(GB)がある。ノード数＝インスタンス数である。クラスタのノード数を増やすには”gcloud container cluster”でリサイズする(クラスタのサイズを直接変更せず、ノードプールのサイズを変更する)。そうすればインスタンス数の制限を超えてさらにインスタンスを作れる。

ノードが入ってるプールのこと。クラスタ内にノードプールが複数個あって、ノードプールの中にノード(インスタンス)が複数ある。このノードはクラスタ内ではレプリカやポッドと呼ばれる。

クラスター全体を管理する中央の制御ノード。マスターノードには、クラスター内のワーカーノードの管理やスケジューリング、全体的なクラスターの状態を管理する “kube-controller-manager” や “kube-scheduler”などのコンポーネントが含まれる。

実際にアプリやサービスが動作するノード。ワーカーノード上には、コンテナランタイム(Docker)が実行され、クラスター内でデプロイされたコンテナ化されたアプリが動作する。ワーカーノード上には「kubelet」などのコンポーネントが実行され、マスターノードの指示に従ってコンテナを起動・停止・監視する。

クラスターの永続的なデータを保存するための分散型キー・バリューストア。etcdはKubernetesクラスターのコンフィグや状態を保持し、全体の一貫性を確保する。

Kubernetesクラスターを作成する場合､コマンド名はgcloud containerで始まる。Kubernetesクラスタに接続するときにもこれを使って”gcloud container clusters get credentials”とする。つまり､ クラスタを直接操作したい場合､クラスタのノード数を増やしたい場合､ クラスタにノード・プールを追加したい場合は､”gcloud container clusters”コマンドを使う必要がある｡gcloudは､ クラスタを作成するためのGoogle Cloud特有のものだ｡クラスターを作成するには､Google Cloudにアクセスする｡クラスタの削除には”gcloud”を使う。

クラスタに何かをデプロイしたい場合､ マイクロサービスをクラスタにデプロイしたい場合､マイクロサービスを外部に公開したい場合、”kubectl”コマンドを使うことになる。つまり”kubectl”は､Google CloudにデプロイされたKubernetesクラスターであろうと､あるいはローカル・マシンやデータ・センターにデプロイされたKubernetesクラスターであろうと､Kubernetesが存在する場所であればどこでも､ マイクロサービスをデプロイしたいのであれば､ “kubectl”を使うことができるKubernetes専用のコマンド・ラインなのだ｡クラスタに何かをデプロイするには”kubectl”を使うことになるだろう｡

インスタンスのこと。replica=3ならインスタンス数が３つ。それぞれのインスタンスはpodと呼ばれる。つまり、replica数＝インスタンス数＝pod数。”kubectl”ではポッドの数を取得できる。

クラスターのマニュアルスケーリングはリサイズによって行われる｡ポッドのマニュアルスケーリングは､Kubectlを使ってスケールをデプロイする。ただしこれは望ましくない。”kubectl autoscale”でオートスケーリングを設定すべきである。

Web上でのHTTPリクエストが何らかのアクションを引き起こす仕組みやプロセスを指す。HTTPからトリガーするか、Cloud Pub/subやCloud Storageからトリガーするか。

リクエストが入ってきてそれを処理するコンテナが無い場合、Cloud Runは新しいコンテナを立ち上げるが、その立ち上げに時間がかかるとリクエストがその分遅れる。これがcold startsである。なので、最低限コンテナインスタンスを1つ稼働させておくことが推奨される。

“Cloud Run”の中には”Revisions”というタブがある。サービスの中で複数のRevisionを持つことができる。複数のバージョンをリリースすれば､ ここには複数のリージョンが存在することになる｡

VM(仮想マシン)にハードディスクをアタッチする際にはブロックストレージが使われる。Google Cloudのブロックストレージは永続ディスクである。ラップトップやコンピュータにはハードディスクが接続されている。このハードディスクのストレージの種類は Block Storageである。通常､ 1つの仮想サーバーに複数の異なるブロック・ストレージ・デバイスを接続できる。ノートパソコンには､ いくつものハードディスクを取り付けられる｡同様に､仮想サーバーや仮想マシンに複数のブロック・ストレージ・デバイスをアタッチできる｡作成する仮想マシンは特定のホスト上にあり､この仮想マシンをネットワーク上の別の場所にあるブロック・ストレージに接続する｡仮想マシンを作成するとき､ Block Storage Deviceでは永続ディスクかローカルSSDを取り付けられる。これは”boot disk”で選択する。ブートディスクは､ OSがロードされる場所であり、パーシステント・ディスクタイプである｡ 仮想マシンを作成すると､ブートディスクが自動的に仮想マシンにアタッチされる｡ローカルSSDは仮想マシンと同じホスト上に存在するローカルなものである｡

永続ディスクには､ゾーン型とリージョナル型の2種類がある｡違いは､ 永続ディスクからのデータがゾーン間でどのようにレプリケートされるかにある｡ゾーナルでは､ データは1つのゾーンにのみ複製される｡しかし､ 地域のデータは複数のゾーンで複製される｡

複数の仮想マシン間で共有するファイルを作成したい場合は､ファイルストレージを使用する｡ファイル・ストアは､ Google Cloudのファイルストレージである｡同僚とあるファイルを共有したい場合、File Storageを使用する。複数人が共通したファイルに取り組む場合、共有ストレージに置きたい。安全で整理された方法でファイルを共有する方法が望ましい｡ File Storageを使えば、これらのファイルは複数の仮想サーバーで共有される｡Google Cloudの File Storageは File Storeのみである。HHDかSSDを選ぶ。

Google Cloudのオブジェクト・ストレージ・サービスは､ Cloud Storageである｡Google Cloudの object storage serviceは Cloud storageである。クラウドストレージに何かを保存する前に､ バケットを作成する必要がある｡データは2地域以上で保存すると高可用性と低遅延を実現できる。ストレージのサイズは自動的にリサイズされる。

Cloud Storageで選ぶ。”standard”, “nearline”, “coldline”, “archive”から選ぶ。短期間の保管や頻繁にアクセスするデータには”standard”を選ぶ。最低保存期間はなし。データへのアクセスが月に1回以下であれば､”nearline”を選ぶ｡最低保存期間は30日間。データへのアクセスが四半期に1回以下の場合は”coldline”を選ぶ。最低保存期間は90日間。もし長期間のバックアップがあり､ アクセス頻度が1年に1回以下であれば”archive”を選ぶ。最低保存期間は365日間。Google Classのすべての”storage class”は99%超の高い耐久性を持つ。重要なのはbucketレベルでストレージクラスを設定できるということ。同じbucketの中に､ 異なるストレージクラスを持つ異なるオブジェクトを持つことができる。Google Cloudの約束しているSLAは99%であり、”standard”, “nearline”, “coldline”にのみ適用される｡”archive”にはコミットされたSLAはない｡

バケットは､ クラウド・ストレージに置きたいすべてのオブジェクトを入れるコンテナのようなものだ｡ Cloud Storageでは選ぶ。buket名はグローバルで一意でないといけない。buket内のファイルはオブジェクトと呼ぶ。

ファイルは作成時に頻繁にアクセスされる｡一般的に､ 使用量は時間とともに減少する｡ストレージクラス間でファイルを自動的に移動することでコストを削減する｡不要になったファイルを自動的に削除するにはオブジェクトのライフサイクル管理を行う。条件を使ってオブジェクトを特定することができる｡これらの条件は､ オブジェクトが生きているかどうか､ 特定のストレージクラスであるかどうか､作成された時期に基づくことができる｡起こりうるアクションは2種類ある｡⑴ストレージクラスを変更する。⑵削除する。オブジェクト・ライフサイクル管理ではすべて自動化される。