Go to Qiita Advent Calendar 2024 Top
LoginSignup
22
26

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@nokoxxx1212(noko)

AWSと比較しつつGCPに入門する

Last updated at Posted at 2019-02-23

はじめに

GCPのトレーニングを受けさせていただき、＋自分で少し触ってみて、GCPに入門したときのメモです。
AWSの経験はあるので、基本的にAWSと比べて理解しようとしています。

メモ

01. VPC

VPC01.png

  • 論理的には、Project > Network > Subnet。物理的には、Region > Zone。
    • Project
      • AWSにはない概念（後述）
    • Network
      • AWSのVPC的なものだが、こっちはリージョンをまたげるし、CIDRを持っていない。あくまで論理的なオブジェクトでしかない。（全く違うIPレンジたちをふれる。）
      • リージョン間の通信もインターネットに出ない。内部IPでいける。リージョンをまたいでも同じIPレンジをふれる。
      • 例えば、同一ネットワークなら別リージョンでも内部IPでいける。
      • 例えば、同一リージョンでも別ネットワークならインターネット経由でアクセスする。
    • Subnet
      • なぜいるかというと、リージョンごととかに縛りたいからとか。リソースの管理用。
  • IPアドレス
    • 内部IPはサブネットレンジからDHCP（固定でふらない）。リースは24時間。自動で、名前解決できるようにしてくれている。内部DNSリゾルバ。ネットワークが違うとだめ。
    • 外部IPを固定したいときは予約する。VMは自分のGIPを知らない。PIPだけ。外部IPの確保は、割り当てが外れていると1IPアドレスあたり0.01ドル/hかかるので注意。
    • GCPは基本的に全インスタンスに外部IPをつけようとする。外部IPがつけられたインスタンスが外部に通信しにいくときは、そのインスタンスにつけられた外部IPをsourceIPとして接続しにいく。
  • Firewall rules
    • VMとの間のトラフィックを許可または拒否できる。
    • ネットワークごとに定義する。（ネットワークに紐づく）
    • AWSのSGと違い、送信元/先（ターゲット）とルールセットは別で定義する。
    • ターゲットタグという概念がある。Firewall rulesを作るときに、「このターゲットタグが付いているインスタンスたちがこのルールの対象ですよ」と定義する。そしてVM側にタグをつける。（そっちはラベルとして）
  • GCPプロジェクトを新規作成すると、自動的にdefaultネットワークというVPCを作成するが、ポート22, 3389, ICMPが任意の送信元に対して許可されているので注意。

02. Virtual Machines

VirtualMachines01.png

  • 要するに
    • GCEのインスタンスのこと。EC2みたいなやつ。ちなみにGAEはElasticBeanstalkみたいなやつ。
  • EC2より良さそうなところ
    • インスタンスタイプは、標準タイプもあるが、EC2と違って自分でCPUとメモリを決められる（custom machine）。ただし、割高。
    • Stackdriverが、オーバースペックだと直近9日分を見てレコメンドしてくれる。
    • Live migrateしてくれる。メンテナンスイベントで停止しなくて良い。
    • 一ヶ月の使用率を見て、自動で割引きをしてくれる。（リザーブドインスタンス的に1,3年の予約とかも別途あるが）
      • 同じタイプ、同じゾーンは同一インスタンスとして計算してくれる。
  • 注意事項
    • ネットワークスループットを上げたいときはNICではなくvCPUを上げる。（IOPSも同様）
    • 2vCPUが1物理コア（オンプレからの移行時に注意）。
    • GPUはカスタムマシンしかない。
    • Local SSD disksはVM停止すると継続不可。どこかに上げておく。暗号化も自分で。（Persistent diskはデフォルトで暗号化されている）
    • 東京のリージョンで、ゾーンaは不安定だからcに移動するとかがある？
  • その他
    • NetworkingがNICのこと。ここに Firewall rulesを当てる。
    • コンソールからssh接続可能
    • ネットワークのプレミア階層とスタンダード階層は、基本的にプレミアでよい
      • なるべくインターネットに出ることで安いスタンダード
    • 自分で鍵を作成して登録できる
      • ssh-keygen -o -t rsa -C "ope-user" -b 4096
    • OSを変えるときはBootdiskの設定を変更する。
    • ディスク
      • ゾーン間は移行不可。一度スナップショットを取ること。（スナップショットを介せば、HDDからSSDに変更できる。）
      • リサイズだけなら止めなくて良い。
      • ディスクは読み込み専用であれば複数インスタンスにつけることができる。
      • ローカルSSDはエフェメラルだが性能がでる
      • ディスクIOの性能はディスクサイズとvCPUのコア数に依存する

03. IAM

  • 言わずもがな、AWSのIAMに近い。
  • Projectという単位の上位に、Folders,Organizationがある。
  • Organizationはgsuiteのドメイン。Foldersは階層化できる。部門とかで切ったりする。
  • ユーザと課金アカウントとプロジェクト
  • Cloud IAMのメンバーはGoogleアカウント、サービスアカウント、Googleグループ、GSuiteドメイン
    • ユーザには役割を割り当てる。役割は複数の権限の集まり。
  • 基本的にgsuite前提だが、cloudidentityで50人まで管理できるようになった。
    • 基本GCPの外で管理がよい
    • ここはエンプラ向き？
  • サービスアカウント
    • AWSのIAMロール的なやつ？
    • アプリケーションコードにシークレットキーや認証情報を埋め込まなくてもAPIに対するアプリケーションの認証はシームレスに行われる
    • GCEにはデフォルトで組み込まれていたりもする
    • メールアドレス形式で識別される
    • Authorization Serverに認証しにいき、Tokenを発行してもらう
    • 鍵を発行して、それを元にVMから認証したりする

04. Data Storage Service

Datastorageservices01.png

Google Cloud Storage

GCS01.png

  • AWSのS3的なやつ
  • ストレージクラス
    • Nearline,Coldlineは取得コストがかかる
    • それぞれ、30日・90日以内に取得しようとするとさらに割高
  • オブジェクト単位でACLがかけられる（IAMはバケット単位）
    • 4通りあるが、基本的にはIAM,ACL（ACL設定はgsutilsからのみ）
  • Multi-RegionalとRegionalは変更不可
  • Signed URLで、時間限定アクセス
  • 独自の鍵で暗号化してアップロードもできる
  • ネットワーク下りは課金（0.14ドル/Gとか）

Cloud SQL

  • AWSのRDS的なやつ
  • MySQLとPostgresのみ。バージョンも限られる。
    • Oracleは使えない。今後も対応予定はない？課金体系により。
  • ライブマイグレーションの対象ではない
  • 現在は内部IPでアクセスできる
    • かつてはCloud SQL側からクライアント証明書を発行して、クライアントは接続時にその証明書を指定していた。
  • データ量がテラバイトとかなら、はじめからCloud Spannerの方がよい。

Cloud Spanner

  • Relational DB と Non-Relational DB のいいところどり。
  • 独自のエンジン。癖がある。移行は難しい？
  • リージョンをまたいでのレプリケーションもできる。
  • KMタクシー、リクルートなどが、リアルタイムで大規模なシステムで使っている。

Cloud Datastore

  • NoSQL
  • AWSのDynamoDB的なやつ
  • Kind:テーブル、Entity:行、Property:フィールド、Key:種キー
  • GQLによるクエリでも操作できる

Cloud Bigtable

  • フルマネージドなNoSQL
  • AWSのDynamoDB的なやつ
  • グーグル検索、gmailで使われている
  • 処理ノードとデータノードが別れている。それらの間のアクセス方法を学習する。

05. Resource Management

  • この名前のサービスがあるわけではない
  • PJごとに1つの請求アカウントを紐づけられる
  • Globalという概念がある。Global > Regional > Zonal。
  • リソースの割り当て上限はあるが（インスタンス数など）、AWS同様、申請で緩和できる。
  • リソースを整理するため、ラベルを付与する。
    • チーム、請求先ごと・VMで利用しているコンポーネント・環境識別子・オーナー・状態など
    • ラベルとタグは違う。タグはFirewall rule用。
  • 利用料金のアラート通知設定ができる。
    • BigQueryに取り込んで分析できる。（BigQueryはAWSのAthena的なやつ）

06. Resource Monitoring

Stackdriver

  • AWSのCloudWatchとの違い
    • Stackdriverアカウント一つで、複数のPJを管理できる
      • AWSのアカウントを管理するときは、GCPのPJを一つ切って、そこにAWS Connectorを入れる。
    • alertにDocumentationを設定できる。
    • Incidentsの状態管理ができる。（OPEN->ACKNOWLEDGED->RESOLVED）
    • 他の多くのサードパーティツールと連携できる。（他GCPサービスとも）
  • エラー時の対応例
    • アプリケーションでエラー発生（GAE等）
    • -> Error Reporting でエラーの一覧が確認できる
    • -> Debbugerでコードのエラーを見つける（Error Reportingの画面でも見れるが、エディタ的にソース一式とエラーが合わせて確認できる）

07. Interconnecting Networks

VPN

  • VPN。インターネット回線。
  • VPN gatewaysとIPを作って、それらを転送ルールで紐づける

Cloud Interconnect

  • VPCにつなぐ。専用線。
  • AWSのDirect Connect的なやつ。

Direct Peering

  • Googleの網に直接入る
  1. Load Balancing
  • 設定手順例(1)
    • ①VMインスタンス作成
    • ②VMインスタンスにネットワークタグを付与
    • ③外部IP予約
    • ④ヘルスチェック作成
    • ⑤ターゲットグループ作成 + ヘルスチェックとつなぐ
    • ⑥VMインスタンスをターゲットグループに入れる
  • 設定手順例(2)
    • ①VMインスタンス作成
    • ②VMインスタンスにネットワークタグを付与
    • ③インスタンスグループを作成してVMインスタンスを入れる
    • ④ヘルスチェックを作成する
    • ⑤バックエンドサービスを作成。インスタンスグループ、ヘルスチェックを指定する。（=ロードバランサが作成される）
    • ⑥転送ルール作成。ロードバランサのフロントエンド。
  • 補足
    • 大きくは3種類ある？Global external,regional external,regional internal。
    • LBはフロントエンドとバックエンドから構成される。フロントエンドは転送ルールとかIP、バックエンドはターゲットプールだったりバックエンドサービスだったり？
    • マネージドインスタンスグループ（MIG）
      • テンプレートを用意しておき、そこから起動するインスタンスのグループ。

09. Autoscaling

  • 仕組み
    • MIGごとにオートスケーラが作成される
    • スケーリングポリシーが競合したときは、VMの推奨数が最大のものを選択する。
    • ポリシーを満たすために何台追加すべきか計算して追加する。
  • 設定手順例
    • VMインスタンス作成
    • ->インスタンスのブートディスクからカスタムイメージを作成する
    • ->カスタムイメージやインスタンスタイプを指定して、インスタンステンプレートを作成する
    • ->インスタンスグループを作成する。自動スケーリングをONにして、自動スケーリングポリシーを設定（CPU負荷等）し、テンプレートとMAX台数を設定する。
    • ->インスタンスグループをロードバランサのバックエンドに設定する。

10. Infrastructure Automation with Google Cloud Platform APIs

  • カスタムイメージの実態はtarファイル。GCSに格納される。PJ間で共有できる。（スナップショットとの違いは、共有できる範囲）
  • Startup/Shutdown Scriptsを設定できる。GCSに置いて参照してもよい。

11. Deployment Manager

  • AWSのCloud Formation的なやつ。
  • Terraformでいいのは、、、？
  • ベースのyamlファイルを指定してgcloudコマンドを実行して作成する。yamlファイルからjinjaファイルを指定する。yamlファイルでパラメータを指定。後はjinjaファイル。

12. Managed Service

BigData01.png

Dataproc

  • AWSのEMR的なやつ
  • 24時間以内に処理が完了するのであれば、Preemptive VMs を使えばよい
  • 90秒未満でクラスタが構築できる。

Dataflow

  • Apache BEAM をベースとしたフルマネージドサービス
  • ジョブの途中でもオートスケールする

BigQuery

  • AWSのAthena的なやつ
  • データだけあればいい
  • SQLさえかければいい
  • 料金は下記3つに対してかかる
    • データストレージ
    • SQLクエリの処理量
      • 毎月最初の1TBは無料
      • 日付分割テーブルを推奨
    • ストリーミングインサート（バッチインサートは無料）

Other Services

Datalab

  • Jupyternotebook

Data Studio

  • AWSのQuickSight的なやつ
  • 可視化。URLで共有。

13. Application Infrastructure Services

Cloud Pub/Sub

pubsub01.png

  • AWSのSQS的なやつ
  • 独立したアプリケーションでメッセージの送受信ができる
  • ackを返すのがポイント。subscriptionがsubscriberからackを受け取ったらMessage Storageからデータを削除する。

Cloud Endpoints

  • AWSのAPI Gateway的なやつ
  • apigee

Cloud Functions

  • AWSのLambda的なやつ

Cloud Source Repositories

  • GitリポジトリをプライベートでIAMで管理できる
  • githubのミラーリングができる

14. AppEngine

  • AWSのElastic Beanstalk的なやつ
  • 最近はGKE推し
  • StandardとFlexible。Flexibleは裏がGKE。
  • Standardはミリ秒で起動するし、リクエストがなければ0までスケールダウンする。しかし言語は限られ、リクエストタイムアウトも最大で60秒。
  • コンテナを使いたければFlexible。
  • Standardは専用のAPIで他サービスと連携できる。（ロックインにはなる）

15. Containers

GKE

GKE01.png

  • マスターがマネージド
  • クラスタはmasterとnodeたちで構成される。各nodeではなく、masterに対して命令する。
  • nodeにPodがのる。Podはアプリケーションの単位。一つ以上のコンテナから構成される。
  • podsなどのオブジェクトはラベルで管理。一つ一つのpodではなく、ラベルをつけたpodたちに命令する。
  • サービスは、論理的なポッドのセットと、それにアクセスするポリシーを定義する抽象的なもの。つまり、複数存在するポッドの数やノードの存在を意識せずに抽象的なアクセスを提供する機能が、k8sのサービス。
  • 設定手順例
# マスタとノード3つのクラスタを作成する
# マスタはマネージドなので見えない
$ gcloud container clusters create httploadbalancer --zone $MY_ZONE

# ポート 80 で動作する nginx Docker イメージのインスタンスを実行
$ kubectl run nginx --image=nginx --port=80

# このコマンドで NodePort タイプのサービスを作成すると、クラスタ内のすべてのノードで、ランダムに選択された上位ポート番号（32640 など）を使用してサービスを利用できるようになります
$ kubectl expose deployment nginx --target-port=80 --type=NodePort

# Ingress
# 外部のトラフィックをkubernetesのエンドポイントにルーティングするためのルールをカプセル化
$ vim basic-ingress.yaml
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  backend:
    serviceName: nginx
    servicePort: 80
---

# Ingressを作成
# Ingress は、Compute Engine に HTTP 負荷分散のリソースを作成し、それらをデプロイに接続します
$ kubectl create -f basic-ingress.yaml

# ロードバランサの外部 IP アドレスを確認する
$ kubectl get ingress basic-ingress

16. その他

  • ChromeとかgMailがGoogle Cloud。それを支えるのがGCP。
  • AWSとかAzureはIaaSから始まり、GCPはPaaSから始まった。文化が違う。
  • GCPの操作は、CloudConsoleかCloudShellか。
    • CloudShell : コンソールからターミナルでCLIが実行できる。めちゃ便利。なぜAWSにないのか。ローカルからデータアップロードとかもできる。（5GBまで）
  • マーケットプレイス : かつてのCloudLauncher。仮想マシンだけでなくコンテナも。GKEにスムーズにデプロイできる。

おわりに

思っていたよりAWSとの思想の違いを感じて面白かったです。
グローバルなWebサービスを新規に作るならとても良さそうな一方、内部に閉じた業務システムの移行先としてはまだちょっと、な印象を受けました。

22
26
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
22
26

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?