[ GCP ] メガネと学ぶ GCP (8) ストレージ・サービスの特徴を知る

[ GCP ] メガネと学ぶ GCP (8) ストレージ・サービスの特徴を知る

こんばんは、七色メガネです。

今回は Google Cloud Platform (以下,GCP) で提供されるストレージ・サービスについて勉強したことをまとめます。

GCP(Google Cloud Platform) ってなに?

こちらの記事でまとめているので、お時間あればご参照ください。

[ GCP ] メガネと学ぶ Google Cloud Platform (1) GCPって何ぞや?

ストレージ・サービスの全体像

GCPではユーザの目的に合わせた様々なストレージ・サービス(一般的なDBの立ち位置に在るもの)が提供されています。

どのサービスを選択すれば良いのか、と言う点について公式ドキュメントでフローが公開されています。

Firebase はまだベータ版なので選定から外すとすると、注目すべきフロー分岐は次のようなものになります。

  • 扱うデータは構造化されているか?(構造化されていないデータ=動画や画像、規格化されていないテキストなど)
  • 分析業務に使用するか?
  • 低レイテンシーを望むか?
  • リレーショナルデータベースである必要があるか?
  • 拡張性は必要か?

これらの問いに答える形でフローを読み進めると、サービスに用いるべきプロダクトが見えてきますね。

 

Google Cloud Storage

概要

CloudStorage は、画像データや動画データなど構造化されていないデータのためのストレージです。

特徴

オブジェクトとバケット

CloudStorage では、個々のデータは「オブジェクト」として扱われ、「バケット」と言う単位で保存されます。オブジェクトにはサイズ制限がありますがそれを格納するバケットにはサイズ制限が無いため、上限無しでデータ保存を行うことができます(もちろん、使用量に応じた課金が行われますが)。

ストレージ・クラス

オブジェクトには次の4種類「ストレージ・クラス」が存在します。バケットに設定された「デフォルトストレージ・クラス」に従って、そこに格納されるオブジェクトのクラスが決定されます。

  • Multi-Regional
    世界中からアクセスされるようなデータに対して設定すべきクラスです。オブジェクトは「米国(North America and Couth America)」「アジア(Asia and Australia)」などマルチリージョンなロケーションに保存され、地理的な冗長性が担保されます。
  • Regional
    同一リージョンから頻繁にアクセスされるようなデータに対して設定すべきクラスです。広範囲にデータを分散させず、「東京(asia-northeast1)」「ロンドン(europe-west2)」などの単一リージョンに保存します。
  • Nearline
    月に1回程度のアクセス頻度が見込まれるようなデータに対して設定すべきクラスです。前者二つのクラスに比べて若干可用性が落ちますが、その分保存コストが低くなります。
  • Coldline
    年に1回程度のアクセス頻度が見込まれるようなデータに対して設定すべきクラスです。保存コストが最も低く、障害復旧用のデータの保存などに最適です。

ライフサイクル管理

ライフサイクルを設定することにより、保存したオブジェクトの削除やクラスの変更を自動で行うことができます。
例えば、作成後30日が経過したデータは削除する、あるいはストレージ・クラスを変更する、などの操作を行えます。

Regional を Coldline へ、などの変更ができますが、Multi-Regional と Regional だけは相互に変換することができません。
(保存場所のコンセプトが異なるため)

Google Cloud Datastore

概要

Cloud Datastore は、スケーラビリティの高いNoSQLデータベースです。

特徴

SQLライクなクエリ

Datastore はリレーショナル・データベースではなくNoSQLですが、RDBにおけるSQLのようなクエリを使用することができます。
ただしスケーラビリティの実現のため、結合(JOIN)などいくつかのオペレーションはサポートされていません。

スケーラビリティ

データの書き込み、読み込みのいずれにおいてもスケールが可能です。

書き込みの場合は、必要に応じてデータを分散させることでスケールを実現します。
読み込みの場合は、取得されるエンティティ(RDBにおけるレコード)の大きさによってクエリを変更することでスケールを実現します。このオートスケールにより、100件のエンティティを取得するのも100万件のエンティティを取得するのも同じパフォーマンスで実行できます。

整合性

Datastore のクエリでは、次の2種類の整合性レベルのいずれかで結果を返却することができます。

  • 弱整合性
    高速に実行されますが、結果が最新で無いことがあります。
  • 強整合性
    低速で実行されますが、最新の結果を取得します。

 

Google Cloud SQL

概要

Cloud SQL は、PostgreSQL と MySQL をサポートするフルマネージドなデータベースサービスです。

特徴

PostgreSQL と MySQL のサポート

Cloud SQL は 標準のPostgreSQL と MySQL をサポートしているため、迅速な開発とデプロイが可能です。
Oracle はサポートしていません。

フルマネージド

フルマネージドなサービスであり、バックアップや管理、レプリケーションなどの作業をユーザが行う必要はありません。

自動フェイルオーバー

高可用性のために、自動フェイルオーバーの設定を行うことができます。

フェイルオーバーでは、マスターインスタンスと同一リージョン内かつ異なるゾーンの中にフェイルオーバー・レプリカを作成します。
このレプリカに対して、準同期レプリケーション機能によりキャッチされたマスターの変更を適用することで、レプリカにデータがコピーされます。

マスターインスタンスが停止した場合、レプリカにフェイルオーバーされます。
ただし、ゾーンの停止以外の理由でのマスターインスタンスの停止はフェイルオーバー起動のトリガーにはなりません。

Cloud Proxy によるアクセス制御

Cloud SQL へのアクセスはグローバルIPアドレスで行われます。
Cloud SQL へのアクセスを許可する方法はIPアドレスを固定的にホワイトリストに登録するほか、接続元をCloud Proxy に限定する方法があります。

接続を CloudProxy 経由に限定した場合、Cloud SQL への認証処理をCloud Proxy に移譲することが出来ます。

Google Cloud Spanner

概要

Cloud Spanner は、高い整合性と水平スケーラビリティを兼ね備えた分散型RDBです。

特徴

RDBでありながらNoSQLの特徴を兼ね備える

RDBにはスキーマやSQLの概念があり、一貫性のあるトランザクションを実現できますが、NoSQLではそれらの概念はありません。
また逆に、NoSQLは水平スケーラビリティ(スケールアウト)を容易に実現できますが、RDBでは主に垂直スケーラビリティ(スケールアップ)しか実現できません。

Spanner は両者の良いところをピックアップしたRDBです。
スキーマやSQLの概念を持ち、整合性を保ちつつ、データ分散による水平スケーラビリティの実現を可能にしています。

水平スケール(スケールアウト)

通常のRDBではデータベースの拡張が望まれた時、スケールアップ(=垂直スケール。物理的な性能を上げる)かスケールアウト(=水平スケール。サーバの台数を増やす)手法が取られます。しかし前者にはそもそも物理的な限界があり、後者は、RDBがデータ分散を前提としていないためにスケーラビリティの向上に繋がりにくいという問題がありました。

Spanner はRDBでありながら NoSQL の特徴であるデータ分散の機能を取り入れているため、スケールアウトを容易に行うことが出来るようになっています。

通常のRDBとは異なる設計が必要

RDBとNoSQLの機能を持ち合わせる高いパフォーマンスを発揮する代わりに、通常とは異なる視点からのデータベース設計が必要となります。

例えば Spanner では「ホットスポット」が発生します。ホットスポットとはデータが一部のノード(単一のサーバ)に集中してしまい、データ分散ができずにパフォーマンスが低下することがあります。
データは主キーによって分散されるため、ホットスポットが出来ないように主キーの採番処理を実装する必要があります。

 

Google Cloud Bigtable

概要

Bigtable はビッグデータを扱いながら高スループット・低レイテンシを実現した、スケーラビリティの高いNoSQLです。

特徴

大容量かつ高スケーラビリティ

Bigtable は数十億、数千列のスケールに対応しており、規模にして数テラから数ペタバイトなどの超容量データの格納を行うことが出来ます。

低レイテンシー・高スループットを求めるビッグデータへの適正

Bigtable は10ミリ秒以下の安定したレイテンシで読み取り・書き込みのスループットを行うことが出来ます。
超容量のデータを格納できるという特徴と組み合わさり、高いスループット性能を要求するワークロードに最適です。
金融、IoT、フィンテックなどに高い適正をもつストレージです。

ApacheHBase のサポート

業界標準となっている Apach HBase に対する拡張機能がサポートされており、既存の Apache エコシステムとの統合など、オープンソースのビッグデータツールとの連携が容易です。

RDB的操作は行えない

Bigtable は純粋なNoSQLであり、SQLクエリやテーブルの結合など、リレーショナルデータベースでは行える操作は行えません。
(NoSQL でありながら SQLライクなクエリに対応している Datastore の方が特殊なんですね)

Google Cloud BigQuery

概要

BigQuery は、高いスケーラビリティと処理能力を備えた、フルマネージドなエンタープライズ向けのデータウェアハウスです。

特徴

大容量かつ高スケーラビリティで、フルマネージド

BigQuery は超容量のストレージと、高速でクエリを実行するための機構を提供します。
ここではもちろん設備やソフトウェアに料金は発生せず、またフルマネージドであるので機器の管理も全てグーグルに委託することができます。
BigQueryを使用することで、大規模なデータ解析を行うための初期投資が必要なくなります。

低料金

BigQuery において料金は、データの保管とクエリの実行に置いて発生します。しかしその料金設定は非常に低く、大規模なデータ分析における費用的な負担を軽減します。
またSQLクエリを実行する前に dry-run することで、そのSQLによりどれだけの料金が発生するかを事前に確認することが出来ます。
ただし、操作を誤ると費用が膨大なものになる可能性があります。

解析のための超容量データへの高い適正

BigQuery はクエリ実行結果を返却するまでの時間がとても短く、またクエリもSQLライクなものなので、データ分析を手軽に実行することができます。
超容量のストレージとしては Bigtable もありますが、Bigtable は低レイテンシー / 高レスポンシビリティであることを活かし、超容量のデータ保持能力とデータの即時処理が求められる金融やIotの領域に置いてその力を発揮します。
対して BigQuery は超容量とクエリの実行速度の速さが売りであり、超容量かつ分析対象として扱われるデータのストレージとして、高い適性を持っています。

 

まとめ

GCPのストレージは多様ですが、次のような特徴に注目することでより理解を深められるかもしれません。

RDBであるか、NoSQLであるか。

CloudSQL は純粋なRDBであり、既存のアーキテクトからの移行がしやすくサービスのイメージもつきやすいです。ただし、水平スケールには対応していません。
Datastore や Bigtable はNoSQLであり、RDBでは難しかった水平スケールが実現可能です。ただし、RDBで行うようなSQL操作には制限があります。
Spanner はRDBでありながらNoSQLの特徴も備えています。一貫性のあるトランザクションの実現、水平スケールなどが可能です。しかし設計が特殊であり、既存のRDBからの乗り換えなどには工数を要します。

大容量か、そうではないか。大容量であれば、用途は何か。

CoudSQL, Spanner, CloudStorage, CloudDatastore などは超容量のデータのストレージとしてはやや不向きであり、Bigtable や BigQuery を選択するべきです。
Bigtable と BigQuery の大きな違いは、レイテンシーやスループットの能力です。
超容量でありながらリクエストへの即時応答などが求められる金融データなどのストレージとしては、低レイテンシー・高スループットを約束する Bigtable に軍配が上がるでしょう。
データの解析などを主目的とするのであれば、データの操作がしやすく、また料金も低価格である BigQuery に適性があります。

水平スケーリングが可能か

これはRDBとNoSQLの特徴にも被りますが、 Cloud SQL はRDBであるので水平スケーリング(= インスタンスの数を増やす)は不可能です。その代わりレプリケーションやフェイルオーバーについて自動実行機能が備わっています。
Spanner はRDBではありますが水平スケーリングに対応しています。
その他のストレージはNoSQL、あるいはデータウェアハウスであり、水平スケーリング機能を備えています。

 

以上です。ここまでご覧いただき、ありがとうございました!

 

GoogleCloudPlatformカテゴリの最新記事