Google Cloud Platformエンタープライズ設計ガイド　vol.2

こちらの続きです。

Google Cloud Platform　エンタープライズ設計ガイド

ストレージサービス

GCPのストレージサービスには
Cloud Storage
CloudBigtable
CloudDataStore
CloudSQL
CloudSpanner
がある。（BigQueryは後述）

各サービスの使い分けとして
構造化データであるか/データ解析が必要か/高い拡張性が必要か/RDBである必要があるか/低レイテンシが必要かで分けられている。

【構造化データ】
格納データが画像データやテキストデータなど、構造化されていない場合
CloudStorage一択となる。これは99.999999999(イレブンナイン)%の年間耐久性を実現するよう設計された容量無制限のストレージサービスで使い勝手がいい。システム内・システム間でのデータの受け渡しやアプリケーションの配布などデータ保存以外でも多く利用される。

【データ解析】
大容量のデータを保管し、データ解析用とで利用する場合にはBigtable　or BigQueryが候補である。どちらもペタバイトまでの拡張性・高い検索機能を持つ。

【低レイテンシ】
BigtableとBigQueryの違いはレイテンシによる
Bigtable：同一リージョン内のComputeEngineインスタンスからのリクエストであれば１０ミリ秒以内の応答が可能。
単純なクエリしか処理できないものの高い応答性能が求められるリアルタイム解析においては有用。
（はやいレスポンスが必要なサービスなどには有用と推測）
BigQuery：ミリ秒単位を必要としない分析・バッチ処理によるデータ解析用途において適性をもつ。ヒアカクテキ複雑なクエリを処理できる。

【リレーショナルデータベース：RDB】
DataStore：SQLライクな問い合わせとACIDトランザクションをサポート
が、構造はRDBと異なり、複数テーブルの結合など複雑なクエリには対応していない。データストアとしてRDBが必要となる場合はCloudSQLかSpannerが候補。
DataStore：サービス規模が拡大しても自動的にスケールし、い処理速度も変化しない。比較的廉価。RDBを必要としない際の候補。【高拡張性】CloudSQL：処理負荷に応じてインスタンスを変更する水平スケーリング機能は備わっていない。→Read性能が不足するちおリードレプリカによるスケールアウト、Write性能が不足するとリソース拡張のスケールアップ必要になる。
（リードレプリカ：データベースの負荷分散のために作成される、参照専用の複製。）
Spanner：大規模かつグローバルに水平スケーリングが可能。高い拡張性があるが、CloudSQLに比べると利用する際の制約事項があり既存RDBの置き換え用途として癖のあるサービスである点は注意

以上をまとめるとこんな感じ。

Cloud　Storage

テキスト・画像ファイル格納向けストレージ。
Amazon　S3相当サービス。一般にオブジェクトストレージと呼ばれる。
独自のコンテンツ配信ネットワーク機能を持ち「エッジ」と呼ばれる拠点に自動的にデータ複製されるため世界中からアクセスされる際、分散アクセスが可能。（like AWS　CloudFrontサービス内包)
主な活用シーン：ファイルの政敵配信（画像・動画）、GCPで動作する各種サービスのデータストア、バックアップ、アーカイブデータの保管。

【バケットとオブジェクト】
プロジェクト内にバケットというデータ格納の器を設定しそこへオブジェクト（データ）を格納する。
プロジェクトはGCPサービス管理・課金管理・ユーザー権限管理の基本単位
１オブジェクト≧５TBの容量制限だが、バケット内のオブジェクト数には制限がないため実質無制限の容量利用が可能。
オブジェクトの操作：コンソール画面・コマンドライン(gsutil)・クライアントライブラリ・REST　API経由でアクセス可能
(gsutil：GCS(Google Cloud Storage)をコマンドラインから操作できるPythonアプリケーションのこと）
(REST　API:HTTPの技術を最大限活用する、シンプルな設計方法、「何のリソースを」「どのように」操作するかをURIやHTTPメソッドで表現する、リソース指向の設計、セッションなど状態を管理せず、必ずそのリクエストで処理が完結する)

【ストレージクラス】
４種類に分類：可用性/耐久性/最小保存期間/料金　が異なる
地理的な冗長性：Multi-Regional
特定リージョン内での利用：Regional
データバックアップ用：NearLine
長期保管するアーカイブ用途：Coldline

デフォルトストレージクラスは随時変更が可能。変更した後格納したオブジェクトは変更後のストレージクラスとなりバケット内の既存オブジェクトのストレージクラスはそのままである。
ライフサイクル管理機能をりようすることで一定期間経過したらNearLine、さらに時間がたてばColdlineにするといった設定ができる。

CloudStorageの基本機能

【アクセス制御】
Cloud IAMとアクセス制御リスト（ACL)を利用
→基本的にはIAMで制御し、個々のオブジェクトへの細かい制限をACLで管理

【暗号化】
他機能と同様に書き込まれる前に自動的に暗号化されて保存される。
これはデフォルト機能で追加料金の発生はなし

【バックアップ】
バージョニング機能：オブジェクトの変更履歴を確保する機能
オブジェクトの上書き・削除のたびに変更前のオブジェクトをアーカイブバージョンとして自動的に作成。有効にするにはgsutilツールなどを利用
例） gsutil versioning set on gs://[ BUCKET_ NAME]
※アーカイブバージョンも課金対象となるためバージョニング機能を有効にする際は前述したライフサイクル管理機能と併用を推奨。
新しいバージョンがアーカイブされた際、最も古いバージョンを自動で削除するといった管理が可能となる。

Bigtable

Apache Hbase APIを通じてアクセス可能なフルマネージドサービス方のNoSQLデータベースサービス。Googleのコアサービス（検索エンジンやGoogleMap,GoogleEarth,Gmailなど）を支えている分散型DBで、高性能かつスケーラビリティが高い。
数百PBまでシームレス、かつ自動でスケーリングし、秒間数千万件処理が可能。
主に、広告やIoTデータ、金融取引のデータ、株価の変動データなど大規模、低レイテンシ、高スループットが求められる用途で活用される。Apache Hbase APIを使用して構築されたシステムの代替として利用可能。
※RDBでのSQLクエリやテーブル結合、複数行トランザクションはサポート外なので利用シーンの検討は必要

【ストレージタイプ選択】
Bigtableのインスタンス、クラスタ作成の際、ストレージとしてSSDかHDDを選択する。切り替えの際、既存のインスタンスからデータをエクスポートして新規インスタンスにデータのインポートが必要となるため切り替え困難な場合もある。Bigtableの特徴である低レイテンシ・高スループットのためにもSSDを推奨。

Bigtableの基本機能

【アクセス制御】
IAMでのPJレベルでのアクセス制御。

【暗号化】
すべてのデータは操作中、保存中を問わず自動的に暗号化される。暗号かぎはGoogle側で管理されておりユーザー指定の暗号かぎを指定できない。

【バックアップ】
テーブルにデータを書き込むと３台以上のサーバに自動でレプリケートされるため耐久性は高い。
(レプリケート：同じシステム環境が2セット（稼働系と待機系）用意され、データ同期も図られているため、万が一、稼働系に障害が発生した時にも、待機系に切り替えるだけで業務を継続すること)
ただ、ユーザによる誤操作やアプリケーションバグなどによる損失をリカバリするための倫理バックアップ機能（スナップショット機能のようなもの）は提供されていない点は注意が必要。

DataStore

アプリケーションのバックエンドを想定して開発されたスケーラビリティの高いNoSQLDB。ACIDトランザクション、SQLライククエリ、インデックスなど一般的なWebアプリケーションで求められる機能を備えている。従来はAppEngine向け昨日だったがDataStore独立のサービスとなり、ComputeEngineからも利用可能となった。
最大の特徴：サービス規模が拡大し続けても自動的にスケールされ、処理速度が変化しないこと。
データサイズのセットではなく結果セットのサイズに応じてクエリをスケールしていることに起因。結果セットに１００件のエンティティが含まれるクエリは１００件のエンティティを検索した場合でも同じ処理速度が期待できる。
シャーディング（データを複数サーバに分散させる機能）とレプリケーションを自動的に処理し、アプリケーションの負荷に応じてシームレス、かつ自動でスケールするため開発負荷が低い。

AppEngineのデータストアとして利用されるケースが多い（どちらも自動的にスケールするのでシステム全体を自動的にスケールさせることが容易であるため）

【オブジェクト指向DB】
RDBと同じ機能を多く備えているが、性質的にはオブジェクト指向型DBに近い。

【コンシステンシ】
強整合性と結果整合性の二つを選択可。どちらにおいても整合性の保証はあり、更新情報がどのタイミングで反映されるかが異なるのみ。
Strong　Consistensy(強整合性）：更新直後から結果が最新であることを保証（更新完了まで時間がかかる）
Eventual Consistency(結果整合性）：更新後、最新ではない結果が返されえることがあるが、処理は高速で実行される。

【スキーマ設計】
実行できるクエリタイプは一般的なRDBMSより制限が厳しい。特徴的なものとして
結合オペレーション（Join句）がサポート外複数の不統合条件を使った検索がサポート外サブクエリの結果に基づいたデータに対する検索処理がサポート外
上記を踏まえスキーマ設計は非正規化を志向する必要がある。

DataStoreの基本機能

【アクセス制御】
IAMを利用したプロジェクトレベルのアクセス制御。ただIAM権限をキャッシュに保存しているため役割の変更反映に５分ほどかかる。

【暗号化】
ディスクに書き込む前に自動で暗号化、暗号かぎはGoogleが管理。ユーザ指定は不可。

【バックアップ】
保存されたエンティティに対しCloudStorageにエクスポートする機能がある。また、書き込みを抑止する機能が備わっておりバックアップ取得時に書き込みを抑止することでバックアップデータの整合性を確保できる。

Cloud SQL

クラウド上でRDBを利用できるサービス。
Amazon　RDS相当、OSやDBのインストールと設定は実施済みの状態で提供されバッチ適用やバックアップも自動で実施される。オンライントランザクション処理システムやオンプレミスの既存システムからの移行でRDBを必要とする際に重宝されるサービス。
DBエンジンとしてMySQLとPostgreSQLが選択可能。OracleDB,MicrosoftServerが選択できない。
※これはAmazon RDSと比較した際のウィークポイント。

Cloud　SQLの基本機能

【拡張性・耐障害性】
Failover Replica機能：マスターインスタンスの障害時、自動でフェイルオーバさせることが可能。
（フェイルオーバー：現用系コンピュータサーバ/システム/ネットワークで異常事態が発生したとき、自動的に冗長な待機系コンピュータサーバ/システム/ネットワークに切り換える機能）
また、負荷分散を目的としたRead Replica,ストレージの自動拡張機能が備わっており煩雑になりがちなRDBMSの設計・管理から解放される点は大きなメリット。
※ただFailover Replicaはマスタが存在するゾーンが停止した場合のみの適用、ゾーンの停止ではない理由で停止するとフェイルオーバーされない。

【アクセス制御】
接続ポイントはIPアドレスとなっており、適切な制御を行わないとインターネットのどこからでも接続可能となる。制御方法として
・接続可能なIPアドレスをホワイトリスト形式で管理
・接続元をCloud SQL Proxyに限定する形式
Cloud SQL Proxyを利用するメリット：静的IPアドレスを登録する必要がなくなるほか、Cloud SQLとの間で送受信されるトラフィックが自動で暗号化されセキュアなアクセスが可能。
IAMを利用したプロジェクトレベルのアクセス制御、インスタンスレベルのアクセス制御。

【暗号化】
データてんそうちゅおよびデータベース保存時もすべて自動で暗号化される。暗号かぎはGoogleが管理、ユーザ指定は不可。

【バックアップ】
自動バックアップ、もしくはオンデマンドによるバックアップ取得。
自動バックアップ：４hのバッファ時間枠を指定することで時間内で自動的バックアップが行われ各インスタンスでサイダイ世代がGooglede管理。
バックアップからの復元は元のインスタンスへの復元、同一プロジェクト内の別のインスタンスに復元も可能。

Spanner

高い整合性と大規模水平スケーリングの機能を備えた従来のRDBとNoSQLのいいとこどりを実現したRDBサービス。
Cloud SQLやAmazon RDSはオンプレ用に開発されたRDBのクラウド版ととらえられるがSpannerはクラウドを前提に設計されたRDBサービス。
SpannerはCAP定理に反しているように思えるが、
（CAP定理：一貫性、可用性、ネットワーク分断への耐性の３つを同時実現することは不可能）様々な工夫によってCAP定理の制約を緩和。
例：ネットワークの分断が発生した際、１００％の可用性を追い求めるのではなくデータの整合性確保を選択するアーキテクチャを構築。それでも稼働率は99.999％（ファイブナイン）に設定されている。
主な活用例：大規模水平スケーリングとマルチリージョンサポートを生かせるシステム。
（リージョン：データセンターが存在する独立した地域のこと）
アーキテクチャはDataStoreに近く、従来型RDBに比べ設計上の制約が存在し、既存RDBからの移行は簡単ではない。主な制約は以下。
・物理レイアウトを意識したスキーマ設計の必要性
ホットスポットを回避したスキーマが必要
（ホットスポット：テーブルの処理が特定のノードに集中してしまうことでパフォーマンスが低下すること）
そのために主キーの選択を慎重に行う必要がある。アクセスが多い場合はインターリーブを用いてデータを分散配置させないようにクラスタ化する必要がある。
（インターリーブ：データを何らかの領域（空間、時間、周波数など）で不連続な形で配置し、性能を向上させる技法を指す）
・データの操作・書き込みにSQLはりようできない
データの定義にはSQLをサポートするが、操作・書き込みではサポートしていない。APIやクライアントライブラリ経由での実行が必要。
・自動裁判機能がない
構造上、主キーの値が単調増加するとホットスポットが発生する可能性があるため機能としてあえて備えていない。

Spannerの基本機能

【アクセス制御】
IAMを利用したインスタンスレベルの制御、DBレベルでのアクセス制御。

【暗号化】
データ転送中、およびデータベース保存時もすべて自動的に暗号化。
暗号かぎはGoogleがかんり、ユーザ指定は不可。

【バックアップ】
データ損失リカバリの倫理バックアップ機能はなし。Google側で日次バックアップを取得しているためGCPサポートに依頼することで日次バックアップからのリカバリは可能。


少し長くなりましたがストレージはしっかり学びたかったので。。。

次はネットワーキングサービスへ続く。