AWSエンジニアから見たGCPサービス(DB/ストレージ編)

こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。

前回の記事「元AWSエンジニアがGoogle Cloud Professional Cloud Architectを取得した話」を読んでいただいた方々、ありがとうございます。

こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。前回の記事「PostgreSQLのメモリアーキテクチャを知る」を読んでいただいた方々、ありがとうございます。先日、Google Cloud のProfessional Cloud Architect(以下PCA)を取得する機会があったので今回はその合格までの道のりについてお話しいたします。きっかけきっかけとなったのは、Google Cloudが主催している特別トレーニング「G.I.G.」に参加する機会が巡ってきたことです。GMOアドマーケティングに入社して約1年が経つとともにGCPの業務経験も1年経ち、「ひとま...

 

今回は「AWSエンジニアから見たGCP」をテーマにし、いくつかのDB/ストレージ系のGCPサービスについてAWSと比較し感じた点についてお話いたします。

 

オブジェクトストレージ

Cloud Storage

AWSではS3に相当するストレージサービス。

ストレージクラスの概念や耐久性(イレブンナイン)、ライフサイクルルール/ACLでのアクセス制御などはS3と同様な考え方になっている。

S3と異なる点としては、Cloud Storage自体に組み込みキャッシュという機能が備わっており、一般公開のオブジェクトはCloud Storage ネットワークのキャッシュに一定期間保存されるため、デフォルトでCDNのように動作する点である。

S3で同様のことを実現しようとなると、メタデータをオブジェクトごとに設定したりCloud Frontを使用したり、実現までのステップが増えるので、静的サイトのホスティングを簡易的に試す場合などは非常に便利である。

また、S3からCloud Storageへのデータ転送についてはGCPのTransfer ServiceでサポートされておりGCPコンソール画面から転送ジョブを設定するだけでデータを転送できる。

 

RDB

Cloud SQL

AWSではRDSに相当するサービス。

RDS同様、テラバイト規模のデータを格納でき水平・垂直スケーリングも可能であるが、RDSよりも対応するデータベースが少ない。(RDSはOracleやMariaDBなどにも対応)

これに加えてRDSでは、AWS独自のDBでMySQLの5倍・PostgreSQLの3倍速いといわれているAuroraも使用できる。

また、Cloud SQLに限った話ではないが、RDSの起動時は起動先のVPCとサブネット・セキュリティグループを指定し起動するという構成に対し、Cloud SQLはGCPのCloud SQLネットワークからプライベートサービスアクセスというサービスピアリングを設定し各VPCへ接続させる構成になっており、AWSとGCPでアーキテクチャが異なるため注意が必要。

Cloud Spanner

Cloud Spannerは、リージョンや大陸にまたがってグローバル規模でトランザクションの整合性を提供する高性能分散リレーショナルデータベースサービスであり、近年ではNewSQLとも分類されるものである。

AWSには同様のサービスは現時点で存在せず、Google Cloud 独自のサービスである。

これに加えCloud Spannerの強みとしては、ノードを追加するだけで無制限にスケーリングが可能という点が挙げられる。

そのため、金融系のシステムなどミッションクリティカルなユースケースに最適ではあるがMySQLなどの既存RDBなどのサポートはしておらず、Cloud Spanner特有の制約もあるため実際に導入する際にはハードルは高めである。

 

NoSQL

Cloud Bigtable

フルマネージドでスケーラブルな大規模NoSQLデータベースサービスであり、AWSではDynamoDBに比較的近いサービスである。

DynamoDBと異なる点としては、HBaseのAPIを使用できHadoopなどのビックデータツールとの統合が簡単にできるという点が挙げられる。

そのため、IoTやアドテクなどでのビッグデータの分析用途でも導入できるということも強みと思われる。

また、BigtableはGoogle検索やGmailなどGoogleのコアサービスにも使われているため、信頼性は高い。

Cloud Firestore

フルマネージドで高速なNoSQLドキュメントデータベースで、AWSでいうとDocumentDBに相当するサービスである。

DocumentDBはMongoDBとの互換性をサポートしているが、Firestoreではオフラインサポートの機能が強みとしてある。

クライアント側でネットワークの切断時にデータを更新した場合、ローカルにキャッシュされたFirestoreのデータに更新が反映され、再度ネットワークに繋がった時点で更新したデータがFirestoreに反映される。

そのため、開発者側ではクライアント側でのネットワーク切断時のエラーハンドリングの処理などを考慮する必要がなくなりその分工数が削減できる。

 

その他

Memorystore

インメモリサービスで、AWSではElastiCacheに相当するサービスである。

ElastiCacheもMemorystoreもともにRedisとMemcachedをサポートしている。

ElastiCache for RedisとMemorystore for Redisで比較すると、Memorystore for Redisは単一のノードで構成されるがElastiCache for Redisに関してはクラスタ構成で起動することも可能になっている。

そのため、ElastiCache for Redisでクラスタ構成を構築する場合は、シャードやノードの管理などクラスタ管理に関する知識が必要となってくる。

 

おわりに

簡単ではありますが、今回はDB/ストレージ系サービスについてAWSとGCPのサービスを比較し紹介しました。

GCPを触り始めて1年半が経とうとしていますが、どのクラウドかということは関係なく各サービスの特徴や強みとしている部分について理解した上でサービスを選定するということはとても大切だと日々改めて感じています。

次回以降は、コンピューティング系やデータ分析系などのサービス比較についても執筆しようと思います。