https://cloudplatformonline.com/gcp-jp-googlecloudonboard.html
Googleの考え方
（1）制約を厳しくすることで他の大多数が上手くいくなら制約をつける
制約がないことで、他の大多数の問題が解決するのならどんなことをしても制約を外す。
- AppEngineもこの思想に基づいているので、いろいろできないことがある
（2）リソースを効率よく利用する
CPUは、常に100%の状態にしておきたい。
- IaaSだと、遊休リソースが発生する（Googleから見た時に、1分でも早く解放して、別のタスクに使いたい）
- AWSの場合、時間単位の課金だが、GCPの場合分単位になっている
- 課金単位を細かく設定することで、結果的に遊休リソースを少なくしている
基盤技術
全てのサービスは、コンテナ上で動いている。
2種類のコンテナサービス
- Borg（ボーグ）
- Google社内向けのコンテナサービス
- Kubernetes（クーバネテス）
- Borgの知見を元に、一般向けに実装したもの
数万台のホストサーバーから、空いているものを見つけて、瞬時に展開する。
ビックデータを解析する場合、HDDの呼び出しがボトルネックになる。
BigQueryでは、1TBのデータを、100MBに分割して、数千台のコンテナで実行している。
AppEngine
- コンテナ種類
- Standard Environment: Borgコンテナ
- Flexible Environment: Dockerコンテナ
- ステートレスに作る
- コンテナはいつ落とされるかわからない
- 1分以上かかる処理は、TaskQueueに投げる
- データを持たない
- Cloud Datastore, Cloud Storageに保存
- Cloud SQLは推奨されない
- AppEngineは自動でスケールされるが、Cloud SQLは単一のVMとして動いているので、スケールに手間がかかる
- Cloud Datastoreであれば、AppEngineと同じようにコンテナを増やすことでスケールできる
Cloud Storage
- バケットの種類が豊富なので、選んで使う
- Multi Rqgional: 世界展開する
- Regional: よく使う
- Nearline
- Coldline: あまり使わない
Cloud Bigtable
- 実行スピードが早いが、低レベルのAPIしか提供していない。一般的には、高レベルAPIを提供しているDatastoreを使う
- Bigtable: 2ms
- Datastore: 50ms
- Datastoreの内部はBigtable
実行スピードと、使いやすさのトレードオフ。
Cloud SQL
- もともとあまり力を入れていなかった
- WordPress用だったので、大した性能はいらなかった
- WordPressの内容は、エッジキャッシュに乗るので、DBアクセスはあまりなかった
- 多少使われるようになったので、別途、第二世代として実装した。
前述の通り、GoogleではRDBに力を入れていない。
Datastoreか、Bigtableを使うのが吉。
Compute Engine
- IaaS
オンプレミスから、PaaSへ移行する際の踏み台ぐらいな感じ。
Googleとしてあまり力を入れていないのか、必要な機能はあるけど、大して説明はなく……。
Big Query
- 100億行の正規表現置換を8秒で行う
- インデックスは使わない。毎回、フルスキャン。
- 理由としては、ちょっとずつ手法を変えて分析を行うので、インデックス貼っても無駄だから
機械学習
- サービスとして提供
- Google Photo: 画像のラベリング
- Smart Replay: メールの返信を自動で作成。英語のみ
- APIとして提供
- Vision API: 物体認識、感情認識
- Speech API: 音声認識（多言語対応）