GCPを座学的に学習した際のメモ

CloudStorage

特徴

• データを保管するとその一連のバイトがObjとして扱われ固有のキー（URL）でアドレス指定できる
• Webと相性の良いストレージ
• スケーラブルなのでプロビジョニング不要
• 耐久性と可用性に優れたデータ保存可能
• ファイルシステムではない
• バケットで管理される
• 暗号化される
• GCPの他のサービスからアクセス可能
• バージョニングを採用しているので、毎回全てのデータが上書きされる（要はバージョンが作成されてバージョンを指定することで復元が可能）

種類

Multi-regional

• 複数のGCPリージョンに保存可能（高いが冗長性が担保されている）
• 頻繁にアクセスするデータに適している（WebApp、Game、MobileApp…）

Regional

• GCPリージョンに保存できる（安いが冗長性がない）
• 上記２つは高パフォーマンスのObj Storage
• ComputeEngine, VM, Ku8sEngineの近くにデータを保存する場合に適している（データ集約型の計算パフォーマンスが向上）

Nearlline

• アクセス頻度が低いものに適している
• データの読み取りが１ヶ月に一回のものなど。
• データを保存しておいて月一で分析に使用する場合など

Coldline

• 安価で耐久に優れた
• 年に一回などのもの
• 障害復旧など
• データ移行はChromeを使用している場合はドラッグ&ドロップでいける
• テラバイトやペタバイトを超える場合はOnlineTransferやStorageTransferServiceやTransferApplianceなどがある

CloudBigtable

• ビッグデータ用のNoSQLサービス
• データを低密度で行に取り込む
• 永続のハッシュテーブル（キーとペアの構造）だとみなされることが多い
• 高スループットでの読み書きに対応
• 運用と分析に最適
• ApatchのHBaseと同じAPIを使用（互換性がある）

なぜHBaseからBig Tableに乗り換える？

• スケーラビリティ
• アップグレードや再起動などの管理タスクを透過的に処理
• 処理中にも保存時にも暗号化される

GoogleCloudSQLとGoogleCloudSpanner

• スキーマを用いてデータの一貫性と正確性を保つ
• トランザクションに役立つ
• 成功か失敗のどちらかだから
• MySQLかPostgreSQLから選択可能
• ComputeEngine内で独自にSQLを使うことも可能
• CloudSQLを選ぶ理由
• 複数のゾーンで展開している
• ネットワークファイヤウォールがある。
• 他のサービスやGCPからアクセスが可能
• 水平スケーリングが必要な際は Spaner

GoogleCloudDataStore

• NoSQL
• 主にAppEngineアプリの構造化データ格納
• AppEngineとComputeEngineをまたぐソリューションを構築する際にこれを統合ポイントにできる
• シャーディングとレプリケーションは自動
• クエリも可能
• 小規模オペレーションは無料

Ku8s engine

• ComputeEngine -> Ku8s engine -> AppEngineの立ち位置
• PaasのようなスケーラビリティとIassのようなOSとハードウェアの抽象化層を提供
• ハードウェアではなくOSを仮想化している
• ノードはCompute Engineで実行されるVM
• コンテナ -> Pod -> Node -> Clusterとなっている
• Podを全世界に公開したいならロードバランサを使用する
• Serviceとは一連のポッドをグループ化して安定したエンドポイントを提供する
• PodそれぞれのIPアドレスを使用してしまうと（ロードバランサなしで）Podが破壊された際に毎回IPアドレスを変更しなければならない
• PodのCPU使用率が80%を超えたら自動的にPodが増える
• ローリングアップデート
• 一つづつPodを更新していき、ダウンタイムをなくしてバージョンを更新できる

Anthos

• オンプレとクラウドのハイブリッド、マルチクラウドコンピューティング
• オンプレとクラウドのいいとこ取りをしたい時に用いる
• 両方にKu8sEngineをインストールしていれば、GCPMarketPlaceを通じて両者のアプリケーションと通信可能

AppEngine

• PaaSである。
• コードを提供するだけでいい。
• 自動的にスケールする。
• WebAppやバックエンドに向いている。
• 無料枠がある。
• スタンダード環境
• サポートされているのはJava、Python、PHP、Goのみ
• サンドボックスで管理される。
• 全てのリクエストは６０秒でタイムアウト
• 任意のサードパーティアプリはインストールできない
• フレキシブル環境
• コンテナで管理される
• ComputeEngineのVMのDockerコンテナで実行される

Cloud function

• イベント駆動型でイベントが発生時に発火する関数のこと。
• サーバーやランタイムバイナリを機にする必要がない
• 使用料金は不要
• 関数の実行時間分の料金を100ミリ単位で支払う
• JSのファンクションをトリガーとして設定することもできる

Deployment Manager

• yamlファイルもしくはPythonファイルを渡してあげることによって構築可能
• テンプレートとして使用することができるので変更がとても容易
• テンプレートを保管して、バージョンを管理するならCloud Source Repositoriesを使用する

StackDriver

• モニタリング、ロギング、診断用のGCPツール
• インフラ、VM、コンテナ、ミドルウェア、アプリ層、ログ、指標、トレースなどにアクセス可能

BigData

• 統合サーバーレスプラットフォーム
• リソース使用料だけ

Cloud Dataproc

• データセットのサイズが明らかな場合
• クラスタサイズを自分で管理する場合

CLoud Dataflow

• データパイプラインはバッチデータとストリーミングに対応
• クラスとの起動不要
• インスタンスのサイズ変更不要

BigQuery

• ペタバイト規模の低下価格のフルマネージド分析データウェアハウス
• インフラの管理は不要
• SQL使用可能
• 従量課金製
• CloudStorageやCloudDataStoreからデータを読み取る
• BigQueryに胃病あたり最大１０万桁をストリーミング
• ストレージとの計算処理が分離されるのでクエリとデータストレージの料金は別々

CloudPub/Sub

• 個別のアプリ間でメッセージを送受信できる
• Pub -> パブリッシャー　Sub -> サブスクライバー
• １秒あたり１００万件以上のメッセージを処理可能
• ストリーミングデータを分析する場合にはCloudDataFlowとPub/Subを組み合わせて使用

ML

• 事前トレーニング済みモデルを備えてある
• カスタムモデルも生成可能
• TensorFlowはGCPでやるべき
• 大量のオンデマンドリソースとトレーニングデータが必要
• 構造化データ
• MLを利用して分類タスクと回帰タスクを行うことができる
• レコメンデーションを基本としてパーソナライズ、クロスセル、アップセルに対応できる
• 非構造データ
• 画像分析に使用
• テキスト分析、ブログ分析、言語識別、トピック分類など

Cloud vision API

• 画像の内容を理解することができる

Cloud speech API

• 音声をテキストに変換できる
• 文字起こしや翻訳

Cloud natural language API

• 自然言語解析に役立つ

Cloud translation API

• 翻訳

Cloud video intelligence API

• 各種形式の動画にアノテーションを付与
• 動画内の主要エンティティを識別して出現するタイミングを特定
• 動画コンテンツの検索と検出が可能に
• まだベータ