Google Cloudの用語集＆解説集 part.3

Relational DatabaseにはOLTPとOLAPの2種類がある｡最もポピュラーな選択肢である。RDBを使用している場合､テーブルと関連する定義済みのスキーマがある｡強力なトランザクション機能を提供する｡これらのテーブルを複数まとめて変更することができ､すべてのテーブルで更新が成功した場合にのみ変更をコミットすることができる｡そのため､ 1つのトランザクションで複数のテーブルを更新できる。厳格なスキーマで高い一貫性がある。OLTP(Transaction)は行ストレージ、OLAP (Analytics)は列ストレージである。行(row)ストレージでは行ごとに保存し、列(column)ストレージでは列ごとに保存する。小さな取引が沢山あるものではOLTPを使い、ペタバイト級の大規模データを扱いたい場合はOLAPを使う。

On-Line Transaction Processing (オンライントランザクション処理)の略。多数のユーザーが多数の小さなトランザクションを行うアプリで使われるデータベースのことである。銀行アプリや株式取引アプリでは小さな取引が沢山行われる。Google CloudではCloud SQLとCloud Spannerの選択肢がある。RDBの一種である。OLTPデータベースでは行ごとに保存するのでrow(行)ストレージとも呼ばれる。これは少額の取引を処理するのに実に効率的だ｡

Google Managed ServiceではCloudSQLがこれにあたる。Cloud SQLは､ Regional Relational Databaseとして、PostgreSQL, MySQL, SQL Serverをサポートしている｡ CloudSQLは最大数テラバイトのデータをサポートできる｡つまり､ PostgreSQL､ MySQL､ SQLServerのような従来のデータベースが必要で､数テラバイトまでのデータを扱う地域データベースをホストしたいのであれば､ CloudSQLを選べばいいのだ｡Cloud SQLを使う最大の利点は､レプリケーションやパッチ､ データベース管理について心配する必要がないことだ｡これらはすべてGoogleが処理してくれる｡オートストレージ増設や自動バックアップ、リカバリを有効にできる。

Cloud Spannerは無制限のスケールを提供し､複数ペタバイトのデータまで拡張できる｡これは極めて膨大な量のデータである｡Cloud Spannerでは99%超の可用性が得られる。また､ Cloud Spannerは水平スケーリングが可能なグローバル・アプリケーションに推奨される｡世界中にユーザーを持つグローバル・アプリケーションで､RDBを無制限に拡張したいのであれば、これを選ぶ｡Cloud Spannerは､ 管理されたミッションクリティカルで､グローバルに一貫性があり､ スケーラブルなリレーショナルデータベースである｡ Cloud Spannerはグローバル・データベースである。処理ユニット(processing unit)を選べる。

主キーはテーブル内で一意であり､ 主キーに対するクエリーを効率的に行うことができる｡

サーバー証明書を発行できる。

プライマリ・インスタンスに対してリード・レプリカを作成できる｡リード・レプリカを作成すれば､ SQLインスタンスのリード・レプリカを作成でき､リード・レプリカは同じリージョンにも別のリージョンにも作成できる｡(レプリカは前回やった通り、ほぼインスタンスと同意義)。

過去の特定の時点までリカバリーしたいか､何日前までリカバリーしたいか(何日分のログを保存するか)を設定する。

1 nodeより遥かに小さいノードをプロビジョニングできる。1 node = 1,000 processing unit。

インデックスはテーブル内の特定の列に対して作成され、インデックスされた列に関連する場合、検索速度が向上しソート操作も効率的になる。データベースの性能を向上させられる。一方でインデックスを過剰に使用するとデータの挿入、更新、削除の速度が低下する可能性がある。なので適切な列に対してのみインデックスを作成する。検索する列やソートする列があるならインデックス化させることが推奨される。

バケットは､ クラウド・ストレージに置きたいすべてのオブジェクトを入れるコンテナのようなものだ｡ Cloud Storage関連で、part.2 Cloud Storageで詳しく書いた。

Online Analytics Processing(オンライン分析処理)の略。ペタバイト級の膨大なデータを分析できる。複数のアプリケーションから入ってくる膨大な量のデータを持っており､データを分析したい場合に使う。Google Managed ServiceではBigQueryである｡BigQueryはペタバイトスケールの分散データウェアハウスである｡RDBを使用している。OLAPデータベースは列(column)型ストレージであり、列ごとに保存される。列を一緒に保存する利点は２つある。⑴各列が似たようなデータを含んでいるため､非常に高い圧縮率を得ることができる｡ カラム型ストレージを使用すれば､ ペタバイト級のデータを効率的に保存できる｡⑵データをより簡単に配布できる｡複数のノードでクラスタを作り､それぞれのカラムを異なるノードに保存する｡これにより､ 複数のノードにまたがって1つのクエリーを実行することができる｡ OLAPで最も重要なことは､非常に素早くクエリーを実行できることである｡同じテーブルに関連するデータを複数のノードに分散させることで､処理を複数のノードに分散させる｡そのため､ 複雑なクエリーも効率的に実行できる｡OLAPデータベースでは､非常に複雑なクエリを実行し､ クラスタ内の複数のノードに分散して実行することができる｡

SQLを使わないデータベースである。元来、RDBは強力な一貫性とSQL機能を備えてきた｡ SQLなしのデータベースは、スケーラビリティと高性能を実現するために､強力な一貫性とSQL機能をトレードオフにしている｡それほど強力な一貫性は持っておらず、そのほとんどはSQLをサポートしていない。しかし柔軟性に優れている。GoogleにおいてSQLなしのManaged Serviceは２つある。Cloud Fire Store (旧Data Store)と Cloud Big Tableである。アプリの構造を素早く進化させる必要がある場合に NoSQLを使う。

Cloud Data StoreはSQLデータベースを使わずにサーバーレスで管理される｡トランザクションやSQLのようなクエリー、インデックスも提供してくれる｡そのため､トランザクションを伴うモバイルアプリやウェブアプリでは Cloud Data Storeを利用していた｡Fire StoreはData Storeの次のバージョンで､強力な一貫性などさらにいくつかの機能が追加され､ モバイルとウェブクライアントの負債も提供する｡モバイルアプリからデータベースにアクセスしたい場合､Fire Storeを使えば簡単だ｡Cloud Data StoreとFire Storeは､ゼロから数テラバイトの小規模から中規模のデータベースに推奨される｡ Firestoreの特徴は４つある。⑴データストアが階層構造になっている。collection → Document → collection → …というようなデータ構造が作成できる。⑵すべてのフィールドにインデックスが自動的に作成されるが、2つのフィールドを同時にクエリしたい場合､さらに複合インデックスを作成できる。⑶フィルタリングできる。ソートしたり特定の文字列のみを取り出す。⑷インポートとエクスポート。Cloud Storageから容易にデータをexport / importできる。

Cloud Big Tableは､ 管理されたスケーラブルなSQLワイド・カラム・データベースである｡重要なことは､ Cloud Big Tableはサーバーレスではないということだ｡まずインスタンスを作成し､ それからテーブルを作成する｡大規模データ(10テラバイト以上から数ペタバイトのデータ)を持っている場合は､ Cloud Big tableを使うことをお勧めする｡大規模(ペタバイト)な分析や運用のワークロードがある場合､ Cloud Big Tableの利用が推奨される｡ Cloud Big Tableは､ トランザクション・ワークロードには推奨されない｡

インメモリデーターベース。メモリからのデータ検索は､ディスクからのデータ検索よりもはるかに速い｡永続的なデータをメモリに保存することでマイクロ秒のレイテンシを実現する。Google CloudではMemorystoreを使う。MemorystoreはRedisとMemcachedの2つの異なるオプションを提供している｡

データベースからクラウドデータフローを使用してインポートエクスポートジョブを実行できる。

“Role”とは､ 特定のリソースに対して特定のアクションを実行するための権限の集合である｡ Roleに含まれるのは権限だけであり、Roleはメンバーについて何も知らないし誰が追加されても分からない。GoogleとAWSではリソースとアクションは似ているが、ロールとパーミッションの割り当てに関しては全く異なる。ロールは大まかに3種類。⑴ベーシックロール。⑵定義済みのロール。⑶カスタムロール。ベイシックロールは、さらに所有者(owner)と編集者(editor)と閲覧者(viewer)に分けられる。ベイシックロールは本番環境では使用を推奨されておらず、基本的には定義済みのロールを使用することが推奨される。定義済みのロールで足りない場合のみ、カスタムロールを使う。

メンバーにロール(権限)を割り当てるためのもの。Google Cloudでは、ポリシーによってロールをメンバーに割り当てる。適切な権限をもるロールを作成して、そのロールを持つメンバーを割り当てるポリシーを作成する。

policy troublesholderを使えば､ 誰かのアクセスに問題があるか調べられる。もし誰かが何かにアクセスできないと言ったら､ policy troublesholderを使ってトラブルシューティングすることができる｡特定のidの特定のリソースに対するパーミッションをチェックできる。

Google Cloudにおけるベーシックロールは 所有者(owner)､ 編集者 (editor)､ 閲覧者(viewer)の３つである｡viewerは Google Cloudに存在するすべてのリソースに対して読み取り専用のアクションを実行できる｡Editor(編集者)は､ すべてのリソースに対してviewerと編集アクションが使える｡ Ownerはロールとパーミッションを管理できるので､新しいロールと新しいパーミッションを作成できる。一般的に実環境ではベーシックロールは与えない。

事前定義されたロールとは､ Googleによって事前に定義され管理されている細かいロールである｡ Googleは各サービスの内部に､目的によって異なる役割を設けている。storage関連だけでも、管理者(admin)、閲覧者(viewer)、作成者(create)など様々な定義済みのロールがある。基本的にロールの割り当てにはこの定義済みのロールを使う。

定義済みのロールでは不十分な場合もあり､ その場合は独自のカスタムロールを作成できる｡

Compute Engineを使用すると､同じホスト上に複数のVMが作成される｡1台のホスト(物理)コンピュータが複数のゲスト仮想マシン(VM)を実行することを仮想化と言う。仮想化は､ 仮想マシンとハードウェアの間にソフトウェアを必要とし､そのソフトウェアはハイパーバイザーと呼ばれる｡ハイパーバイザーとは､ ハードウェア上で仮想マシンを作成・実行するソフトウェアのことだ｡ハイパーバイザーではハイパーバイザー税がかかる。これはパフォーマンスに対する税金で､通常5～10％の諸経費がかかる｡ハイパーバイザー税を払いたくない場合はベアメタルにできる。ベアメタルの場合､ ハードウェアの上にハイパーバイザーがないため､ Google Cloudはカスタマイズ可能な専用ハードウェアだけを提供する｡ベアメタルでは仮想マシンよりカスタマイズ性は高いが責任も多い。

クラウドが登場する以前､ VMwareは最も人気のある仮想化ソリューションの1つだった｡VMwareのワークロードをクラウドに移行したい場合などに使える。既存のネットワークをGoogle Cloudに接続し､VMware上で稼働しているすべてのワークロードをGoogleCloudに移行すれば、既存のVMwareツールを引き続き使用できる｡

他のクラウドで仮想マシンを稼働させている場合や､ VMwareを使ってワークロードを実行している場合、これを使って Compute Engineに移行できる。移行前に移行後の挙動をテストできる(テストクローン機能)ことや、VMをグループごとに一括して移動できる点が特徴だ。

仮想マシンの使用は古い。コンテナが最新のトレンドである。コンテナでは仮想マシンのレイヤーがないため､コンテナはより効率的でコスト効率が高く､仮想マシンからコンテナに移行することがベストプラクティスとされている。アプリを仮想マシンからコンテナに移行する際にこれを使えば多くの手作業が必要ない。⑴Migrate for Compute Engineを使ってVMをComputeEngineに移行する｡ ⑵Google Compute EngineでVMを実行した後は､Migrate for AnthosとGKEを使用することで､VMをコンテナに移行する｡

DevOpsは「開発(development)」と「運用(operations)」を組み合わせた造語。簡単に言えば、”開発担当と運用担当が緊密に連携して、柔軟かつスピーディーにシステム開発を行う手法”のこと。素早いフィードバックや自動化がポイントである。自動化することで､ 迅速なフィードバックが得られる｡コードをコミットしてすぐにユニットテストが実行されれば､ 素早いフィードバックが得られるし､ コードを修正することもできる｡ 継続的インテグレーションや継続的デプロイ、継続的デリバリーはその目的を達成するために作られたものだ。

継続的インテグレーションとは､ユニットテストとパッケージングを継続的に実行することだ｡コードをコミットしたらすぐに､ユニットテスト､ 統合テストを実行し､デプロイパッケージを作成できる｡テストとパッケージングを継続的に実行することで､何か不具合があればすぐにわかるようにする｡あるコードがコミットされるとすぐに､これを自動的に実行したい｡

パッケージングとユニットテストの実行に加えて､ソフトウェアを実際の環境にデプロイする｡開発環境､ テスト環境､ QA環境にデプロイし､いくつかの自動テストも実行できる｡これにより､本番環境に近い環境でソフトウェアを継続的にテストすることができる｡継続的デプロイメントを使用している場合､デプロイメントに問題が発生した場合､早い段階でそれを知ることができる｡

本番環境に継続的にデプロイする｡1時間ごとに何度もプロダクションにリリースしたりする。継続的デリバリーのアプローチには､承認サイクルが組み込まれているものもある｡だから､ 本当に重要な機能を実装するのであれば､本番にデプロイする前に誰かに承認してもらいたい｡

CICDの一環で行う。あなたのコードが､ 一般的に推奨されているベストプラクティスを満たしているかどうかをチェックする｡コーディング・スタンダードのチェックに加えて､静的なセキュリティ・チェックも行うことができる｡スタンダードチェックでは LinやSonartが使われる。セキュリティチェックではVara codeやStatic Code Analyzerのようなセキュリティコード解析ソフトがを使い、コードを見てコードのセキュリティ問題を特定することができる｡

CICDの一環で行う。自動化されたツールを使ってアプリケーションのセキュリティ上の欠陥を見つけたいと思うだろう｡これらの実行時チェックは､アプリケーションが特定の環境にデプロイされた後に実行される｡これに加えて､ URLテストを実行することもできる｡

ユニットテスト(ミクロレベルのテスト)でよく使われるソフトウェア。ユニットテストは基本的に､ メソッドレベルやクラスレベルで書くテストなので､JユニットPIテストやJasmineのようなものは､ 自動ユニットテストを書くのに使われる｡これらはミクロレベルのテストである｡

統合テスト/システムテストでよく使われるソフトウェア。アプリ全体をテストし、他アプリと統合している場合は他アプリを含めたシステムをテストする。

サニティとは､ アプリケーションに問題がないかを素早く実行しチェックすることで､最も重要なテストケースを実行する｡千のテストケースがあり､ CI/CDサイクル中に一定の間隔ですべてのテストケースを実行したいと思うならリグレッションテストを行う。

Google CloudのCICDツールの１つ。コードをバージョン管理に保存したい場合に推奨される。GitHubに似ているが非公開である。

Google CloudのCICDツールの１つ。docker imageを保存する場所。多くの企業がソースコードからコンテナイメージを構築しているので､CIサイクルの一環としてdocker imageを作成し､それをコンテナ・レジストリにプッシュできる｡

JenkinsはCI/CDパイプラインを作成するために使用されるオープンソースソフトウェアだ｡Google Cloudが推奨するサービスの１つである。また､ Cloud Buildを使用して､ ソースコードと構成からデプロイ可能な成果物をビルドできる｡

Google Cloudが推奨するサービスの１つ。Spinnakerはマルチクラウドの継続的デリバリーを可能にする｡これは､ソフトウェアの変更を高い速度と信頼性でリリースするのに役立つ｡ App EngineやCompute Engine、他のクラウドにもソフトウェアをデプロイできる。

アプリをビルドしていて､そのアプリをdocker imageとしてCloud Runにデプロイできるようにしたい場合、以下のステップを踏む。⑴ソースコードをGitリポジトリのようなもの(Cloud Source repositoriesなど)に保存する。⑵docker imageを構築(ビルド)する。⑶docker imageをコンテナ・レポジトリに保存する。⑷docker imageをCloud Runにデプロイする。これは､ Cloud Buildを使用して実行できる典型的な継続的インテグレーションと継続的デプロイのサイクルである｡

アプリケーションコードと同じようにインフラを作成すること｡インフラのプロビジョニングとコンフィギュレーションを自動化することだ。インフラを手動でプロビジョニングする代わりに､ インフラをプロビジョニングしてくれるスクリプトを書く等。スクリプトで書けば、他の環境でもインフラを容易にプロビジョニングできる。つまりインフラの再現性を高められる。これはDevOpsプラクティスの１つである。重要なことは２つ。

クラウドでインフラをプロビジョニングするための最も人気のあるオープンソースツールはTerraformだ｡ Terraformを使ってGoogle Cloudではコンピュートエンジンの仮想マシンを作成できる。Google CloudではDeployment Managerを使うこともでき、deployment managerのテンプレートを書いて､ インフラストラクチャのプロビジョニングに使う。

仮想マシンをプロビジョニングし､ そこに特定のソフトウェアをインストールしたい場合は､手動で行うことができる｡しかし､ 何千もの仮想マシン・インスタンスがある場合､ 手作業でそんなことはしたくないだろう｡適切なソフトウェアやツールのインストールを自動化したい｡そこで登場するのが構成管理で､Chef Puppet､ Ansible､SaltStackのようなツールが助けになる｡

アプリの裏にあるCPU利用率やメモリ利用率を監視できる。アプリがメモリ不足になり､対策を講じる必要がある場合､アラートを出すこともできる。

すべてのログの一元管理されたリポジトリである。Google Cloudにある複数アプリやマイクロサービス全体で、特定のリクエストに対して何が起こったかを調べられる。App EngineもCloud RunもLoggingやMonitoringとうまく統合されている。アプリで何が起こっているかに加えて、誰かが仮想マシンを起動/停止した利益も見られる。

アプリを作るときには必ずアプリ内で例外が発生する｡これらの例外を監視し､ できるだけ早く修正するようにしたい｡エラーレポートではリアルタイムで例外監視をできる。すべての例外はエラーレポートに保存される。

デプロイしたアプリに問題が発生したが、ローカルマシンでその問題を再現できない。そこで環境に接続し、Cloud Debuggerを使用して問題を直接デバッグできる。

マイクロサービス・アーキテクチャを採用している場合､1つのリクエストが複数のマイクロサービスを経由することがある｡これらのマイクロサービスを横断してリクエストをトレースできるようにしたい｡クラウドトレースではリクエストを追跡して問題把握できる。

Cloud Traceを使って時間のかかっている特定のマイクロサービスを特定した。次にこのマイクロサービスに時間がかかっている理由を突き止めたい。マイクロサービスをさらに深く掘り下げてプロファイリングするのに Cloud Profilerを使う。

GoogleではDevOps＋αとされる｡サイト信頼性エンジニアリングは､アプリのあらゆる側面に焦点を当てる｡たとえば、アプリケーションが利用可能であること､遅延が少ないこと､ パフォーマンスが高いこと､すべてのリソースを効率的に使用していることを確認する｡SREはサービスレベル目標によって管理される。⑴ビジネス要件と技術要件を測定可能な目標に変換する。⑵失敗のコストを減らして迅速に行動する。⑶開発者と所有権を共有する。

“サービスレべル指標”は、サービスがうまくいっているかどうか、データベースがその要件を満たしているかどうか、特定のサービスについて測定したい定量的な側面は何かを判断する指標である｡これを数値化して目標にしたものが”サービスレベル目標”だ。これを踏まえて顧客との間で”サービスレベル合意(SLA/ Service Level Agreement)”を結ぶ。これはSLOと契約書に書かれた合意(=あなたが顧客と合意するもの)である｡SLAは外部との約束でSLOは内部的なものである。なのでSLOはSLAより厳しく設定することで、SLAを常に満たすようにする

サイトの信頼性エンジニアリングで一般的に使用される。ダウンタイムが無ければエラーバジェットは0%のまま。リリースに問題があればエラーバジェットを使い果たし、開発速度をスローダウンさせる。リリースによるダウンタイムが無ければどんどんリリースできる。

アプリに過剰負荷がかかっているとき、一切処理せず､ ソースから直接減らす｡これはAPIの制限を設定するということだ。顧客のタイプに応じて､ その顧客が行うことのできるAPIコールに異なる制限を設定できる｡これはレート制限に似ている｡顧客のタイプに応じて､許可するAPIコールの数が異なるのだ｡これにより、基本的にはアプリケーションの負荷量を減らすことになる｡

サービスの質を下げるとは、Recomendation APIと話す代わりに､ハードコードされた商品セットを返すことができる｡常にこのようなことをしたいわけではないが､余分な負荷がある場合には考慮すべき良い選択肢だ｡

互いに処理が繋がっているマイクロサービスがあるとき、チェーンの一番下にあるマイクロサービスが失敗したとき、その上にあるマイクロサービスが連鎖的に失敗するのを避ける。コールに失敗したマイクロサービスの呼び出しを少しの間停止し、ハードコードされた応答を返す。これがサーキット・ブレーカーと呼ばれるものだ｡

セキュリティの脆弱性を見つける対象を使って攻撃をシミュレートする。

負荷テストを書くのに使えるツールはいくつもある｡Jmeter､ LoadRunner､ Locust､ Gatlingなど｡負荷テストで推奨されるのは､ 可能な限り現実のトラフィックをシミュレートすることだ｡本番環境と同じようなトラフィックで､アプリがどのように動作するかを確認することが目的だ｡

レジリエンスとは､ システムの1つまたは複数の部分に障害が発生した場合でも､システムが許容できる動作を提供する能力のことである｡システムといっても､ 部品はいくつもある｡そして現実の世界では､ これらの部品のいくつかが故障する可能性がある｡レジリエンス・テストのアプローチにはchaos monkeyを使ったカオステストがある。システムの特定のコンポーネントや部品の故障を再現して、システムがそれにどう反応するかを見る。

定義された期間､停電させてみてアプリが問題なく処理されるかを確認する。たとえば、データセンターを計画的に切断したり停電させてみて、挙動を確認する。