Blog

笠原桃奈ちゃんすき

GCP

 

第1章 Google Cloud Platform の特徴

  • GCPはPaaSからIaaSにすすんだプラットフォーム
  • Google自身がGCPの大きなユーザーの一人
  • ライフマイグレーション
  • 仮想マシンから物理サーバーへ移動させる技術
  • 可溶性が高い
  • グローバルネットワーク
  • クラウドを利用するには提供社の歴史などを考えてみることが大事
  • k8sはBorgというやつ
  • 自身がやりたいことに対しtえあっているのか?ということを検討する必要がある。GCPは「大規模分散コンピューティング」「インフラの隠蔽、共用化」といったことをやっている分野。メリットを理解する必要があります。

第2章 コンピューティングサービス

  • GCPのコンピューティングサービスは下記の4つ
  • GCE
    • 永続ディスクサイズは64TBが最大
    • 標準、ハイメモリー、ハイCPU、共有コアの四種類
    • 共有コア:リソースが小さくて大丈夫なもの。0.2, 0.5コアとか。こいつについては、3TBまでの永続化領域
    • ハイCPU: 96コアまで
    • ハイメモリー: 624Gバイトまで
    • GPUも独自に積んでいる。
      • ライブマイグレーション機能は使えない(仮想環境を利用しながら物理環境にマイグレする機能)
    • OS
    • ディスク
    • 課金
      • 確約利用割引
        • 利用期間をコミット
        • やすい
      • 継続利用割引
        • 利用課金
        • たくさん使えば単価が下がる
    • プリエンプティブルVM
      • やすいやつ
      • 起動後24時間以内に必ず停止される
      • システム需要に応じて必ず停止される
    • Compute Engineの基本機能
      • アクセス制御
        • IAM
        • インスタンス、ストレージ、ネットワークに対するアクセス制御
        • サービスアカウントを設けることで仮想マシンごとにGCPサービスを制御できる
      • 暗号化
        • 自動でやる
        • ユーザーが管理する鍵での暗号化も可能
      • バックアップ
        • スナップショット、イメージ作成
      • 拡張性
      • 対象外生
  • App Engine
    • PaaS
    • StandardとFlexible
      • SE
        • 機能制限が多い
        • 高いサービスレベルを維持したまま
      • FE
        • インスタンスの起動に分単位で時間がかかる
        • バックエンドのインスタンスにCompute Engineを利用しているのでローカルディスクへの書き込みが可能
        • そのため、GCEの利用料に応じた課金が発生する
        • GCEに発生しうる制約
    • Blue-Greenデプロイメント
      • ことなるばージョンのアプリケーションをデプロイする機能がある
      • バージョン指定のURL指定が可能。デプロイ後に確認してから切り替えが可能。
    • Cronサービス
      • キューイングのCronもできる
      • タスクを動かせる
    • セキュリティスキャン
    • App Engineの基本機能
      • アクセス制御
        • IAMを利用したアクセス制御
        • 全体管理?細かいところまで
        • ファイアーウォール系のもの
      • 暗号化
        • SE版はCloud datastoreやCloud Storageが利用される。これらは勝手に暗号化される。
        • FEの場合はGCEを利用するため、データ書き込み時に暗号化される
    • バックアップ
      • App Engineのバックアップ機能はない
      • データを保管する際は外部のデータストアを利用することが一般的(そうなん?)なので不要
  • Kubernetes Engine
    • 設定項目
      • ロケーション
        • どこに配置するか
        • 単一か分散化をせんたく
      • クラスタバージョン
        • マスターのノードに利用するバージョンを指定
      • マシンタイプ
      • ノードイメージ
        • OS
      • サイズ
        • ノード数
      • 自動スケーリング
        • オンにすることで
      • プリエンプティぷぶーど
        • 安いやつ使うかどうか
      • ろーかるSSD
        • 全ノードで利用するディスク数
      • ネットワークサブネット
      • コンテナアドレス範囲
    • Google Container Registry
    • 基本機能
      • アクセス制御
        • IAMとか
      • 暗号化
        • GCEと同様
      • バックアップ
        • 自動
      • 拡張性
        • 各コンテナに必要なCPUとかメモリ利用料を指定できる
      • 耐障害性
        • 自動修復機能
    • Cloud Functions
      • β版
      • 公式ドキュメントを後で読もう
      • コード実行単位での課金(100ミリ秒単位)

第3章 ストレージサービス

  • 下記の五種類存在する
    • google Cloud Storage
      • BLOB
      • オブジェクトストレージ
      • 画像とか
      • 非構造データ
      • S3相当機能
    • Google Cloud bigtable
      • ワイド型ストレージ
      • NoSQL
      • 性能重視
    • Google Cloud Datastore
    • Google Cloud SQL
      • リレーショナル・データベース
      • MySQLやPostgresSQLなどのマネージドサービス
    • Google Cloud Spanner
      • MySQLとか
      • グローバルで水平スケーリング機能を備えたリレーショナル・データベース
      • 高いトランザクション
    • Google Cloud Bigquery
      • 解析用
  • ストレージサービスの使い分け
    • 構造化データでない
      • Cloud Storage一択となる
      • 耐久性99.9999999(イレブンナイン)
    • 構造化データ
      • データ解析用でない
        • リレーショナルデータベース
          • 高調整?
            • Cloud Spanner
            • 水平スケーリング機能 Cloud SQL には備わっていない
            • 制約事項がある
          • その他
        • NoSQL
          • Cloud Datastore
          • Datastoreはサービス規模が拡大しても自動的にスケールする
          • 安価
      • データ解析用
        • 大容量のデータ保存が必要な場合
          • 低レイテンシを必要とする
            • Bigtable
            • はやい
            • 10 msec 以下で応答可能
          • 低レイテンシを必要としない
            • BigQuery
            • 準リアルタイム解析の場合はこちらを採用するのがベター
            • 比較的複雑なクエリを採用できる
  • Cloud Storage
    • S3相当のサービス
    • オブジェクトストレージ
    • 独自のCDNを持っている
    • エッジという拠点にデータが複製されるので、世界中からアクセスが可能
    • バケットとオブジェクト
      • バケット:データを格納する器
        • 格納オブジェクト数の上限はない
      • オブジェクト:データそのもの
        • 最大は 5TB
      • コンソール画面、コマンドライン、クライアントライブラリ、REST API経由
    • ストレージクラス
      • オブジェクト似合いしてストレージクラスが設定される
      • 可用性、耐久性、最小保存期間、料金が異なる
        • Multi-Regional
          • 地理的な冗長性を確保
          • 可用性: 99.95
          • 耐久性: 99.999999999 (nine-nine)
          • $0.026 GB/月
          • 世界中から頻繁にアクセスされるサービス
        • Regional
          • 単一リージョンで稼働
          • 可用性: 99.9
          • 耐久性: 99.999999999 (nine-nine)
          • $0.023 GB/月
          • Compute Engineから頻繁にアクセスされるデータ
        • Nealine
          • 月一回程度のアクセス
          • 可用性: 99.0
          • 耐久性: 99.999999999 (nine-nine)
          • $0.016 GB/月
        • Coldline
          • 年一回程度のアクセス
          • 可用性: 99.0
          • 耐久性: 99.999999999 (nine-nine)
          • $0.01 GB/月
      • Multi-RegionalクラスとRegionalは変更不可
      • デフォルトストレージクラスは随時変更可能
      • 次から格納されるデータがそこのクラスで適用される
      • ライフサイクル管理機能で、格納後の時間に応じて自動で別のクラスに移動できる。
    • アクセス制御
      • IAM
        • 基本はこっち
      • アクセス制御リスト(ACL
        • 細かく制御したい場合はこっち
        • 個々のリソースを制御したい場合はこちらを利用しよう
    • 暗号化
      • ディスクに格納される際に自動的に暗号化される
      • ユーザー指定の暗号鍵を用いて暗号化可能
        • この場合は一部サービスが利用d境内制約
        • 鍵の管理が大変。鍵を新しくする場合過去のデータは古い暗号鍵で暗号化されたまま
        • Cloud KMS (Key management system) がリリースされたがまだ利用できないかも?
    • バックアップ
      • バージョニング機能
        • オブジェクトを上書きするたびに古いものはアーカイブバージョンとして管理する
        • これはデフォルトでは機能
        • アーカイブバージョンも課金対象
        • ライフサイクル管理機能により、古いものは自動削除などの対応が可能
  • Bigtable
    • Apache HBase APIを用いてアクセス可能
    • フルマネージドNoSQLサービス
    • Googleのコアサービスはこれを利用しているらしい
    • 大規模、低レイテンシ、高スループット
    • 生い立ち
      • 10年以上利用されている基盤システム
      • Hadoopのもととなる技術を利用している
      • Apache Hbase Bigtableをべーすに実装された分散データベース
    • ストレージタイプ
      • SSD, HDD を選択可能
      • 切り替え困難
      • パフォーマンスが良いのでSSDを選ぶことをおすすめ
    • 基本機能
      • アクセス制御
        • IAMでの制御
      • 暗号化
        • 自動
        • ユーザー指定鍵は利用できない
      • バックアップ
        • テーブルにデータを書き込むと3台以上のサーバーに自動でレプリケートされる
        • 耐久性は高い
        • 論理バックアップが七曜な場合はユーティリティを利用したバックアップを検討したい
  • Datastore
    • アプリのバックエンドを想定して開発されたNoSQLデータベース
    • サービス規模が拡大しても自動でスケールされて、処理速度が変化しないこと
    • シャーディングとレプリケーションを自動でやる
    • 管理負荷が低い
    • オブジェクト指向データベース
      • RDBと同じ機能を備えているが、オブジェクト指向データベース日会
      • Java/Pythonなどのオブジェクトを永続化可能
      • Datastore
        • カテゴリ:カインド
        • オブジェクト単体:エンティティ
        • 個々のデータ:プロパティ
        • 一意Id:キー
    • コンシステンシー
      • 二種類の整合性レベルを選択できる
        • Strong consistency (強整合性)
          • 更新直後から結果が最新であることが保証される
          • 更新完了まで時間がかかる
        • Eventual Consistency
          • 更新後最新でない結果がが返却されることがある
          • 処理は高速
      • ユースケースにあわせて設計しようね
    • スキーマ設計
      • 利用できるクエリータイプはRDBMSで許可されているものより制限が厳しい
        • 結合オペレーション(JOIN)は利用できない
        • 複数の不等号j封建をもった検索処理がサポートされていない
        • サブクエリーの結果に基づいたデータに対する検索処理がサポートされていない
      • 非正規化を意識する設計が必要
    • 基本機能
      • アクセス制御
        • IAMを利用したアクセス制御
      • 暗号化
        • Datastore上のすべてのデータは自動的に暗号化
        • 鍵はGoogle側で管理されている
      • バックアップ
        • Datastoreに保存されたエンティティに対してCloud Storageにエクスポートする機能が備わっている
        • 書き込みを抑制する機能が備わっているので、そのバックアップデータの整合性を確保できる
  • Cloud SQL
    • Amazon RDsのようなサービス
    • MySQL、Postgresが選択可能
    • Oracle とかは利用不可
    • ジェネレーション
    • Cloud SQLの基本機能
      • 拡張性・耐障害性
        • FailOver replica機能が備わっている
        • マスターインスタンス障害児に自動でフェイルオーバーさせることが可能
        • ストレージの自動拡張機能がそなわっているRDBMSの設計監理から開放される点は利点
        • マスターが存在するゾーンが停止した場合のみfailoverする。ゾーン停止以外の理由でマスターが停止した場合はそれは発動しない
      • アクセス制御
        • IPアドレスでのアクセスポイント
        • ちゃんと制御しないと行けない
        • Cloud SQL Proxyを利用するとかできる
        • IAM
        • DBMSを利用制御も可能
      • 暗号化
        • データ転送中、保存時もすべて暗号化
        • 鍵はクラウド
      • バックアップ
        • 自動バックアップとオンデマンドバックアップが可能
        • 自動は4時間のバックアップ時間枠を指定することにより、その時間枠内で自動バックアップされるh
        • インスタンスで最大7世代がGoogle側で管理される
  • Spanner
    • 高い整合性と大規模水平スケーリングを備えている
    • RDB
    • クラウド前提のRDB設計
      • すきーま:構造化
      • SQL OK
      • 強整合性
      • Active-Active
      • Horizontal Scaling
    • 既存のRDBからのマイグレーションは難しい
    • マルチリージョンサポート
      • 特定のリージョンにルーティングされる
    • 設計上の制約
      • 従来型のCloud SQLは不要?
        • 物理レイアウトを意識した設計
          • ホットスポット(特定のテーブルんい処理が集中すること)を回避しないと期待したパフォーマンスを得られない、
          • インターリーブを利用してデータを分散配置させないようにクラスタ化が必要
        • データ操作や書き込みにSQLは利用できない
          • 読み取りやデータ定義にはSQLをサポートしているが
          • 操作や書き込みにひは利用できない
          • これはGoogleAPI経由でやる必要がある
        • 自動採番機能がない
          • RDBにはあるシーケンス番号をするような機能がないので、あぷりけーしょんがわで実装が必要
    • 基本機能
      • アクセス制御
        • IAM
      • 暗号化
        • 自動
        • ユーザー鍵NG
      • バックアップ
        • 論理バックアップ機能はある
        • 日時バックアップは取得しているため、GCPサポートに依頼することで日時バックアップからのリカバリは可能

第4章 ネットワーキングサービス

  • ネットワーキングサービスの種類
    • 下記の5種類ある
      • Virtual Private Cloud (VPC)
        • GCPリソースのために論理的に分離された仮想ネットワーク
      • Cloud Load Balancing
      • Cloud CDN
        • エッジポイントを提供するサービス
      • Cloud DNS
      • Cloud Interconnect
        • 自社オンプレミス環境からセキュアにネットワーク接続するサービス
  • VPC
    • ユーザー自身が定義したVPCネットワーク内でコンピューティングリソースを起動できる
    • VPC内のリソース同士をプライベートネットワークでつなげることができる
    • プロジェクト内にVPCを作成
    • 異なるリージョンに配置されたインスタンスでも同じVPCに所属できる。そのインスタンスGoogleのプライベートネットワークでアクセスする。
    • 異なるVPC内はインターネット経由で通信する
    • VPCネットワークとサブネットワーク
      • 複数のサブネットを定義可能
      • 1サブネットは1リージョン所属
      • デフォルトは
        • すべてのリージョンに1つのサブネットが作成された状態
      • 各サブネットにはRFC1918に従うプライベートIPアドレスがありり、GCPリソースを利用可能
      • リージョンとCIDRを指定するだけで、ゾーンにまたがったサブネットを作成可能
        • これはGCPの特徴
      • マルチゾーン構成がしやすい
    • 外部IPアドレス
      • GCPプロジェクトごとにIPは確保する
      • GCPではエフェメラルな外部IPアドレスを固定された外部IPに変換する機能がある
      • 固定IPにプロモートするようにしないといけない
      • 下記の2種類存在
    • ネットワーク通信制
      • ステートフルなファイアウォール
      • VPCごとにインバウンド、アウトバウンドを設定する
      • インバウンドは
        • ping, rdp, sshが許可
        • VPC内のすべての通信
        • ユーザー指定VPCではインバウンドはすべて遮断
      • アウトバウンドは、
        • すべて可
      • タグを設定することが可能。
      • タグはインスタンスに付与するラベル。IPを指定せずともタグのみでネットワーク通信制御を行うことができる
    • VPCネットワークピアリング
      • GCPでは異なるVPC感はインターネット経由
      • VPCネットワークピアリング機能を利用するとプライベート接続が可能になる
      • IPの重複がなければピリング設定だけで接続可能
      • VPCネットワーク間ではピアリングされていれば内部負荷分散機能を利用可能
      • VPCピアリングは最大25個まで直接ピアリングされたネットワークを設定することが可能
      • 異なるプロジェクト間でも利用可能
      • 自社オンプレ → vpn 東京リージョン → ピアリングした外部リージョン
    • 限定公開のGoogleアクセス
      • 外部IPがないCompute Engineはインターネット経由でGoogle APIGoogleのサービスにアクセスできない
      • Private Google Accessを利用すれば可能
        • この機能を利用すればVPC内部から下記のエンドポイントにアクセス可能
          • BigQuery
          • Cloud Bigtable
          • Cloud Dataproc
          • Cloud Datastore
          • Cloud Pub/Sub
          • Cloud Spanner
          • Cloud Storage
    • VPCネットワークにおける注意点
      • デフォルトVPCネットワーク
        • Ping, RDP, SSH を行うためのファイアーウォールルールが設けられている
        • そのままつかうなよ
      • 禁止された送信ポート
        • 25 465, 587は送信接続できない
        • SMTPポート
        • サードパーティプロバイダを利用しましょう
          • SendGrid
          • Mailgun
          • Mailjet
  • Cloud Load Balancing
    • ELBのようなアクセス増大する際には事前の申請が不要
    • HTTP負荷分散
      • HTTPリクエストを世界中のサーバーへ負荷分散する機能
      • 1グローバルIPで複数リージョンへの振り分けが可能
      • 外部クライアントからのリクエストは最もの遠いPoP (Point of Presence) で終端され、クライアントのアクセス元に最も近いリージョンに配置されたバックエンドインスタンスに転送される
      • Google Cloud CDNと連携して、世界中にあるGoogleのPoPを利用してクライアント近くにコンテンツをキャッシュして短い処理を実現する
      • 耐障害性も高い
      • コンテンツベースでの負荷分散も可能
      • Stackdeiver Logging のログビューアーからリクエスト状況を確認することが可能
    • ネットワーク負荷分散
      • TCP/SSL UDPプロトコルを利用するレイヤー
      • TCP/SSLに関しては複数リージョンにまたがった負荷分散が可能
      • TCP/UDP負荷分散は単一リージョンでの負荷分散
  • Cloud CDN
    • 世界中に分散しているGoogleのエッジポイントを利用してクライアントの近くにコンテンツをキャッシュする
    • コンテンツ更新時にCDNのキャッシュを削除したい場合は数分で削除可能
  • Cloud DNS
    • レイテンシー、高可用性のサービス
    • Cloud DNSでサポートされるレコードタイプ
      • A
        • アドレスレコード。ホスト名をIPv4にマップする
      • AAAA
        • IPv6アドレスレコード
      • CAA
      • CNAME
      • IPSECKEY
      • MX
        • メールエクスチェンジレコード
      • NAPTR
        • Naming Authority Pointer
      • NS
        • ネームサーバーレコード
      • PTR
        • ポインタレコード
      • SOA
        • Start of authority
        • DNSゾーンに関する信頼できる情報
      • SPF
        • Deplicated
      • SRV
      • SSHFP
      • TLSA
      • TXT
  • Cloud Interconnect
    • 自社オンプレ環境からGCP内のインスタンスに直接アクセスするサービス
    • 下記2種類のオプションがそんざいする
      • Dedicated Interconnect
        • 専用線で直接的な物理接続を行うサービス
        • 帯域は10Gビット/秒
        • ハイブリッドクラウド環境を構築する場合、高帯域のトラフィックを必要とする場合に有効な手段
        • SLA99.99%
  • IPsec VPN

第5章 ビックデータサービス

  • GCP
    • Cloud Pub/Sub
      • メッセージングサービス
    • BigQuery
      • データレイク
    • Cloud DataFlow
      • バッチ/オンラインのデータパイプライン
    • Cloud Dataproc
    • Cloud Datalab
      • データ分析、可視化、機械学習のための分析ツール
データ収集
データ蓄積
データ処理・分析
データ探索・可視化
Cloud Pub/Sub
 
 
 
 
Big Query
 
 
 
Cloud Dataproc
 
 
 
 
Cloud Dataflow
 
 
 
 
Cloud Datalab
  • BigQueryとDataprocの違い
    • 両方ともデータ蓄積、処理、分析ができるが性質やコンセプトが異なる
    • お互いを補完するサービスなので、特徴を踏まえて組み合わせて使っていくこと
  • Cloud Pub/Sub
    • メッセージングサービス
    • 低レイテンシ
    • 基本概念
      • googleapis.comにHTTPSリクエストを投げることでPub/Subにわたすことができる
      • 受信方法は2種類
        • Pull型
          • エンドポイントにHTTPSリクエストを投げることで受信
        • Push型
          • Pub/SubからのHTTPS POSTのリクエストを受け入れることで受信
    • メッセージライフサイクルと内部処理
    • システム設計をする上での考慮事項
      • Pub/Subはメッセージの順序制御を保証していない。そのため、そこは依存しないようなシステム設計にする必要がある
      • 順序制御が必要な場合あdatastoreやCLoud SQLを利用すればできなくはないが大変。非推奨。
    • at-least-once配信
      • 内部ストレージに保存したメッセージを順番に1回配信する。アプリケーションレベルで受信確認が行われるので、複数回配信もありえる。PussubI/Oを利用すれば、カスタムメッセージID、Cloud Pub/Subが割り当てたIDのメッセージの重複を排除することができる
  • 基本機能
    • アクセス制御
      • IAM
      • バックアップ
        • バックアップ、リストアの機能なし
        • 複数ドメインでデータ複製をしているので特に気にする必要なし
      • 暗号化
        • 通信はHTTPS暗号化
        • ストレージに保存される内容も暗号化済み
      • ネットワークセキュリティ
        • エンドポイントはインターネット越し
      • スケーリング
        • 負荷に応じてかってにスケーリング
      • 可用性
  • 主な利用方法
    • ストリーミングデータの受口として配置、バックエンドに配置したData flowなどに非同期で流す
    • コンポーネント疎結合にする
  • BigQuery
    • フルマネージドデータウェアハウスサービス
      • データウェアハウスとは、、、
      • データの保管から管理分析までを行うサービス
    • BigQueryは
      • ストリーミングデータ収集
      • データ保存のストレージサービス
      • クエリーエンジン
    • Dremelの技術を採用
    • 基本概念
      • 内部リソース
        • ストレージリソース
        • クエリリソース
          • CPUとRAMの演算能力
      • BigQueryを利用する際に意識するリソースは
        • テーブル
        • データセット
          • ここのテーブルを論理的に集約できる単位
          • ロケーションやアクセス制御はこの単位で実施
        • ビュー
          • クエリによって定義される仮想的なテーブル
        • ジョブ
          • 利用者が作成したアクション
    • システム設計する上での考慮事項
      • クエリーの種類
        • インタラクティブクエリー
          • 即時実行
          • 50個の同時実行レート
        • バッチクエリー
          • キューイングされてクエリリソースがアクティブになったタイミングで実行
          • 24時間以内に実行されない場合はインタラクティブクエリーになる
          • 数分以内に通常は実行される
          • 同時実行の制限なし
            • 大量実行はこっちの種類を選択
      • データインポートと更新
        • データ挿入処理に特化している
        • レコード単位でのデータ操作はできない
        • データソースから既存テーブルにインポートする場合は、データ追加か上書きしかできない
      • データセットとテーブルの単位
        • データセットは利用目的の単位で分割したほうが良い
      • BigQueryへの接続方法
      • クエリーの実行結果
        • 実行結果は一時テーブルに24時間自動的に保存される
        • 全く同じクエリーを実行した場合には一時テーブル及び永続テーブルの内容を返すのでクエリー課金は発生しない
        • クエリーの実行結果はCSVJSONでダウンロード可能
      • 料金
        • 定額料金
        • オンデマンド料金
    • 基本機能
      • アクセス制御
        • IAMを利用したプロジェクトレベルでのアクセス制御
        • データセットレベルでのアクセス制御
      • バックアップ
        • スナップショットが取得可能
        • 標準AQLのスナップショット機能はない
      • 暗号化
        • 保存時に暗号化
        • Cloud KMSも利用可能
      • ネットワークセキュリティ
        • DatastoreやCloud Storageからデータインポートする際にはGCPのプライベートネットワークを利用した通信が実施
        • BigQueryAPIを叩く場合にはインターネット経由でのアクセスになる\\
      • 可用性・耐障害性
      • モニタリング
        • クエリープラン
    • 主な利用方法
  • Cloud Dataflow
    • データ処理パイプラインサービス
    • 基本概念
      • 利用するためには2フェーズを考える必要がある
        • Cloud Flow プログラムの実行
          • 事前準備
        • パイプラインの実行
          • 実際にデータ変換から格納までを実施
          • Cloud Dataflowジョブと言う単位で実行される
        • PCollection
        • 変換
          • パイプラインで実行される処理単位
          • in/outのPCollectionが必要になる
          • コア変換
            • 利用可能な処理を提供する
          • ルート変換
            • 外部データソースからデータの読み取りを行う
    • システム設計をする上での考慮事項
      • SDKの選択
      • データの格納場所とデータ形式
        • 格納場所とデータ形式によって、最初のRead処理と最後のWrite処理、PCollectionの表現方法が異なってくる
      • テンプレートの利用
        • Cloud Dataflowには下記のテンプレートが存在する
          • ユーザー定義のテンプレート
            • Cloud Storageに格納することでDataflowから呼び出して利用することができる
          • Googleが提供するテンプレート
        • テンプレートを利用することでパイプラインの再コンパイルが不要になる。
      • 基本機能
        • アクセス制御
          • IAM
          • サービスアカウントでパイプラインの実行をする
          • Dataflowで初めてリソースが作成される際に自動的に作成される
          • データの格納場所としてCloud StorageやBigQueryを指定する場合、ACLを利用したリソースレベルでの権限設定でCloud Dataflowからのアクセスに制限することでデータアクセス観点でのセキュリティレベルを向上することが可能である
        • 暗号化
          • パイプライン処理の中で作成される一時テータは保存される場合には暗号化され、パイプライン処理が終了したタイミングで破棄される
        • ネットワークセキュリティ
          • パイプライン処理では、データソースおよびに出力先とCloud Dataflow間のデータ送受信、ワーカーノードのデータ受け渡しの2箇所でのデータ転送が行われる
        • スケーリング
          • ワーカーノードの最小数、最大数を指定するので、その間であれば自動でスケーリングすることが可能である
          • 自動スケーリングを行った場合でも、割当の不均衡だったりリソースの有効活用ができない場合がある。こういった状況の回避のために、動的作業再調整機能が備わっている
          • Apache Sparkを利用して実装することも可能だが管理を実施する必要があり、それはそれで大変なのでマネージド・サービスを利用したほうが良い
        • 可用性・耐障害性
          • 月間SLAは99.9
        • モニタリング
  • Cloud Dataflowの主な利用方法
    • GCPでサービス構築すると、GCPサービス間でデータの授受が発生するその鯛に加工・変換が必要な場合に用いられる。テンプレートを利用すると負荷軽減が可能なので利用が推奨される
      • Google Pub/Sub to Google BigQuery
      • Google Cloud Storage Text to Google Cloud Pub/Sub
      • Google Cloud Pub/Sub to Google Cloud Storage Text
      • Google Cloud Datastore to Google Cloud Storage Text
      • WordCount
        • Cloud Storage 上のテキストファイルを読み取り、含まえる単語の出現頻度をカウントするバッチパイプライン
  • Cloud Dataproc
    • Cloud Dataproc は Hadoop/Sparkのクラスタを提供するフルマネージドサービス
    • いろいろな面倒から開放される
    • Cloud Dataprocの基本概念
      • Compute Engineの上に起動する
      • インスタンスには下記の三種類が存在する
        • マスターノード
        • ワーカーノード
        • プリエンプティブワーカーノード
      • マスターノードはYARN Resource managerやHDFS NameNodeの管理系プロセスが起動する
      • ワーカーノード、プリエンプティブワーカーノードは処理系のプロセスが起動する
      • これらのクラス帯に対してジョブという単位で処理を命令する
  • システム設計をする上での考慮事項
    • 初期化アクション
      • クラスタ構成時に初期化アクションを指定することができる
    • GPUの利用
      • 機械学習用にGPUに接続したCompute Engineを利用することができる
      • プリエンプティブVMは利用できない
  • 基本機能
    • アクセス制御
      • IAMでのプロジェクトレベルのアクセス制御
    • 暗号化
      • データ保存時にはすべて暗号化
      • ユーザー指定の鍵はNG
    • ネットワークセキュリティ
      • 自分で作成したVPC内にCompute Engineが起動するので、自由に通信を制御することができる。パブリックIPを公開しないことでプライベートIP空間でのクラスタ作成が可能
    • スケーリング
      • Cloud DataprocはCompute Engineの特徴を引き継ぐサービス
      • 負荷状況に応じた自動スケーリング機能はない
      • スケーリングが必要な状況は下記の状況
        • ワーカーノードを増やして処理の多重度をあげt、ジョブの実行時間を短くする
        • ワーカーノードを減らして処理の多重度をさげ、費用を抑える
        • ノード数を増やしてHDFSストレージの容量を拡張する
      • scheduled-deletionクラスタとして作成した場合には処理を実行していない日アクティブなクラスタに対して下記の3パターンでクラスタ削除するように実行可能
        • 指定したクラスタアイドル時間を経過した場合
        • 指定した任意の時刻を迎えた倍
        • クラスタ作成時点から数えて、指定した一定時間を経過した場合
    • 可用性・耐障害性
      • マスターノードは3台構成にすることができる(SPOF回避)
      • マルチゾーン配置をサポート指定にあので、単一ゾーン障害が発生した場合にはサービスを利用できなくなる
      • 単一ゾーン障害を考慮する場合には、その対処wお考える必要がある。
      • Cloud Dataprocはマネージド・サービスといいつつ、Compute Engineをインスタンスを利用しているのでその特徴の障害も発生しうる
    • 主な利用方法
      • コネクタを利用することで環境構築の負荷軽減などが可能
        • Cloud Storageコネクタ
          • HDFSに転送すること無く直接ジョブ実行が可能
          • 実行結果のデータをCloud Storageに保存可能
        • BigQueryコネクタ
          • BigQuery上のデータの読み取りや書き込みが可能
        • Cloud BigTableコネクタ
          • Apache HBase 1.0+ APIを利用している
          • HBaseを利用する際にはBigtableを利用可能
  • Cloud Datalab
    • 対話型データ分析、機械学習ツール
    • Jupyter Notebookをベースにしたサービス
    • 下記をデータソースにしてデータ分析ができる
      • BigQuery
      • CLoud Machine Learning Engine
      • Compute Engine
      • Cloud Storage
    • 基本概念
      • コンテナでパッケージングされている
      • Compute engine上で実行する
      • SSH接続用のファイアーウォールルールが必要だが、自動的に作成される
      • Python, SQKコード、コードの実行結果をノートブックという単位で管理する
      • Cloud Source Repositoryに保存される
    • Cloud Datalabを利用する上での考慮事項
      • ライブラリ
        • Jupyter
        • Python
        • GCPサービスのライブラリ
        • が用意されている。
      • Auto Shutdown
        • 利用時のみ起動することが推奨される
        • Auto shutdown機能を有効にすると、一定時間のアイドル時間後に自動で停止する
    • 基本機能
      • アクセス制御
        • 管理者権限での作業が必要
      • バックアップ
        • 自動で取得
        • 10分おき
        • 古いやつは自動で消える
      • ネットワークセキュリティ
        • VPCではファイアーウォール設定がされていてインタネットからアクセスが可能
        • プライベート空間で利用したい場合には別途考慮が必要
      • スケーリング
      • Cloud Datalabの主な利用方法

第6章 機械学習サービス

  • 機械学習には下記が必要
    • モデル
    • 良いデータ
  • 機械学習の補助サービスには2種類存在する
  • GCP機械学習関連サービス
    • 言語処理
      • Cloud Natural Language API
      • Cloud Transition API
    • 音声処理
      • Cloud Speech API
    • 視覚処理
    • その他
      • Cloud Jobs API
  • ただしGoogle機械学習に使っているデータはあくまでも世界に流通している一般的なデータ
  • 独自のデータに関しては自分でやる必要がある
  • 独自サービス
    • Cloud Machine Learning Engine
      • TensorFlowを利用した機械学習プログラムの学習、実行環境
    • Cloud Auto ML
      • 専門知識なしでもいけるやつ
        • Cloud Auto ML Vision
          • 画像データをアップロードしてラベル付けするだけでOK
    • 学習済みAPI
      • REST APIで提供
      • 大容量データはCloud Storageに格納したファイルも利用可能
    • Cloud Natural Language API
      • テキストデータの構造と構文を意味を解析する
      • 機能
        • 構文解析
        • エンティティ解析
          • 通名詞、固有名詞を抽出
        • 感情分析
        • エンティティ感情分析
        • コンテンツの分類
    • Cloud Translation API
      • 異なる言語に翻訳する
      • 110の言語と方言に対応
        • 言語間翻訳
        • 言語の検出
    • Cloud Speech API
      • 音声データをテキストデータに変換する
      • 110の言語に対応(TransitionAPIに対応)
      • 出現回数が多い単語をヒントとして登録することで精度を高めることができる
        • 同期認識
        • 非同期認識
        • ストリーミング認識
    • Cloud Vision API
      • 画像データを解析して情報の抽出や分類を行う
      • 分類
        • 光学式文字認識(OCR
        • ラベル検出
        • クロップヒント
        • 顔検出
        • 画像属性の検出
        • ランドマーク検出
        • ロゴ検出
        • 不適切なコンテンツの検出
        • ウェブ検索
    • Cloud Video Intelligence API
      • 動画を解析する検索する
      • 写っている物体を検出したりする
        • ラベル検出
        • ショットチェンジ検出
        • 不適切なコンテンツの検出
    • 学習済みAPIの利用方針
      • 汎用的なデータ処理なのでそれで解決できる場合
  • 独自モデル作成支援サービス
    • Cloud Machine Learning Engine
      • サービスの概要
        • TensorFlowをGCPのフルマネージドサービス上で稼働するサービス
        • オンプレでもテンソーフローは利用可能だが、インフラのスケールとかが必要になった場合にしんどい
        • 利用者が実行、評価に注力できる
      • 構成
        • 大きく分けて2つの機能
          • GCP上で学習用リソースを構築してTensorFlowで書かれた学習プログラムを実行する
          • 学習済みモデルをAPI化して未知データに対する予測を実効する
        • GUIはシンプル。下記のみ
          • 学習を実行するジョブを実行
          • 生成されるモデルを管理
      • 用語と動作イメージ
        • ジョブ
        • モデル
          • レーニングジョブを実行して得られる学習済みモデル
          • 実体は学習済みのTensorFlowの計算グラフとその設定
        • バージョン
          • 学習済みモデルから生成するモデルバージョン
          • 未知データに対する予測を行うための実行用インスタンスとなる
          • 予測ノードにデプロイされてAPI化される
        • パッケージ
          • レーニングアプリケーションのパッケージ
          • TensorFlowを使って機械学習プログラムを記述したコード、学習実行環境の設定ファイルからなる
          • 標準的なPythonパッケージとして作成する
        • レーニンインスタンス
        • 予測ノード
          • API化の仮想マシン
          • 未知のデータ入力に対して学習済みのモデルで判定する
        • 料金の考え方
          • 料金は下記に対して
            • 学習ジョブ実行
            • モデルを使った予測の実行
            • レーニングジョブの実行に対する料金はトレーニングユニットに対して課金
            • レーニングユニットの1時間あたりの料金は更に事前に指定するスケール階層によって決まる
            • 予測の実行に対する課金は仮想マシンで予測を実行した時間のノード時間で決まる
        • アクセス制御
          • 外部からのアクセス制御は検討不要
          • データやパッケージは配置場所に応じてアクセス制御をする
          • ジョブ、モデルのアクセス制御はIAM
        • ML Engineのランタイムバージョン
          • VMイメージから自動的に生成
          • このバージョンは定期的にアップグレードされている
    • Cloud AutoML
      • α版

第7章 アカウント管理・請求管理

  • アカウント請求管理の概要
    • GCPプロジェクトには下記が紐付t区
      • プロジェクトID
        • ユーザーが決められる
        • グローバルで一意である必要がある
      • プロジェクト名
        • ユーザーが決められる
        • 重複OK
      • プロジェクト番号
    • GCPプロジェクトと請求先アカウントは紐付いている必要がある
  • 請求アカウント管理
    • GCPプロジェクトを作成すると、GCP使用量を支払うための請求アカウントが紐付いている必要がある
    • 割と柔軟な管理が可能
      • 複数のGoogleアカウントを紐付ける
      • 別の請求先アカウントに変更する
      • 複数のGCPプロジェクトを一つにまとめる
      • 利用用途に応じて請求先アカウントを使い分ける
    • GCPプロジェクトの管理者とは別に、請求先アカウントの管理者権限のみをもつアカウントを用意することが可能。請求管理だけさせられる。
    • 請求管理のための機能
      • 予算作成
      • アラートの機能
      • 課金データエクスポート機能
  • Cloud IAM によるアカウント管理
    • 基本概念
      • ホワイトリスト方式のアクセス管理
      • 許可されたの操作のみ実施可能
      • IAMで誰がどのようなアクセス権でという権限定義が制御可能
      • Cloud IAM Policy
    • Cloud IAMで用いるアカウント
      • Googleアカウント
        • GCPを利用するためのユーザーアカウント
        • GmailがIDとなる
      • サービスアカウント
        • 利用するアプリケーションに属するアカウント
        • GCP環境でアプリケーションを実行するときに利用する
      • Googleグループ
        • 複数のgoogleアカウントやサービスアカウントを管理する際に利用する
        • IAMによるアクセス制御をグループに対して実行可能
        • IDを確立できないので注意が必要
      • G Suiteドメイン
        • G Suiteドメインは会社などの1つの組織に所属するすべてのメンバーを含む仮想グループのこと
        • ドメインに紐付いたIDを利用できる。
        • IDを確立できない
      • Cloud Identity ドメイン
        • 一つの組織のメンバーを含む仮想グループ
        • GmailやドライブなどのG Suiteのサービスを利用しないユーザー向けのドメイン
      • G Suite, Cloud Identityドメインを利用する場合にはGCPプロジェクトの上位にOrganizationという海藻を持つことができる。
    • Cloud IAMによるアクセス制御
      • アクセス制御を行うには役割を割り当てる必要がある
        • リソースに対して許可される操作を<service>.<resource>.<verb>といった形式で指定する。
        • compute.machineTypes.list
      • IAMでは下記の3種類のRoleがある
        • Primitive roles
          • プロジェクトレベルで付与する役割。
            • 管理者(オーナー
            • 編集者(エディター
            • 閲覧者(ビュアー
        • Predefined Roles
          • Googleより事前に定義されているGCPの個々のリソースレベルで付与するRole
        • Custom Roles
          • 個別に作成するRole
          • プロジェクトメンバーやサービスアカウントに付与できる
          • G Suite/Cloud IdentityではOraganization単位でも作成可能
          • 筆者の経験では、、、
            • GCPプロジェクト管理:数人
            • 開発メンバーにはPredifined をしぼって付与
            • 必要に応じてCustom role。煩雑にならない程度に。
    • Cloud IAMによるポリシー適用
      • IAMの定義はOrganization/フォルダ/プロジェクト/リソースの角層レベルで設定可能
      • 上位の層で適用されたポリシーは下位層でも有効
    • サービスアカウント
      • GCPアプリケーションに紐づくアカウント
      • アプリケーションを実行する際にユーザーを介さずにGoogleAPIを呼び出すことが可能
      • 役割を与えたサービスアカウント自体をリソースとして扱うことができる
      • サービスアカウントを利用することでGCPリソースへのアクセス制御をユーザーと切り離すことができる。
      • ユーザーに最小限の権限を与えていなくてもサービスアカウントを利用することでサービスアカウント自身が持つ役割を間接的に持つことになる。
      • サービスアカウントはキーペアによるgoogle認証
      • サービスアカウントキーにはGoogleが管理するものとユーザー自身が管理するものがある
        • ユーザーが管理するキーは補完やローテーションをユーザーが実施する必要があり、多少煩雑である
  • GCPにおける監査証跡
    • GCPでは役割を付与されたIDの操作ログをCloud Audit Loggingで取得して、確認することができる。
      • 下記の2種類のログを取得
        • 管理アクティビティログ
          • リソース設定やメタデータを変更する際に保存
          • その他管理操作
        • データアクセス
          • GCPプロジェクト内のデータ生成、変更、読み込みに対するAPI呼び出しが記録
          • 膨大サイズになる
              • BigQuery以外ではDefaultで無効
    • 取得した監査ログを表示するのには下記を利用して確認可能
      • GCPプロジェクトのアクティビティ画面
      • Stckdriver Loggingのログビューア
      • Stackdriver Logging API
      • Cloud SDK
    • 保存期間
      • 管理アクティビティログは400日
      • データアクセスは最大30日

第8章 運用監視サービス

  • 運用監視サービスの種類と使い分け
    • Stackdriver Monitoring
      • メトリクス監視とか
    • Stackdriver Logging
      • API操作とかのログ表示
    • Stackdriver Error Reporting
      • アラート通知
    • Stackdriver Trace
      • レイテンシのレポート
    • Stackdriver Debugger
      • 稼働中の本番環境のコードに対して直接デバック
  • Stackdriverはオンプレ自体より利用してきた運用監視ツールの代替ではない
    • クラウドネイティブなシステム設計を前提としたもの
    • 運用設計が大きく変わる
  • 基本概念
    • 基本階層とプレミアム階層
      • 基本階層は無料
      • プレミアム階層はリソースごとに課金だが、リッチな監視が可能
    • StackdriverアカウントとGCPプロジェクト
      • 1つのStackdriverアカウントに複数のGCPプロジェクトやAWSアカウントを紐付けることで、同じダッシュボードから複数環境のモニタリング情報やその他の情報を監視することが可能。
      • GCPだけじゃない
      • GCPプロジェクトには3つの役割がある
        • ホスティングプロジェクト
          • モニタリング情報を保持するGCPプロジェクト
          • 必ず1つのみ存在する
          • Stackdriverアカウント内で発生した料金はここに課金される
          • モニタリング対象プロジェクトを兼ねることもできる
          • 複数のモニタリング対象プロジェクトを保つ場合はホスティングプロジェクト専用のプロジェクトを分離することが望ましい
        • モニタリング対象プロジェクト
          • 監視対象のリソースを保持するプロジェクト
          • Stackriverアカウントと紐付けることで関しが可能
        • AWSコネクタプロジェクト
          • AWSプロジェクトを監視する際に必要なプロジェクト
          • これを介して情報を取得
          • AWSと接続する際には勝手に作成される
          • 他の用途で利用しないほうが良い
  • 運用監視業務を行うためのStackdriver
    • Monitoring
      • メトリクス、イベント、メタデータを収集して、ダッシュボード上での可視化やアラートの発報を行うモニタリングツール
    • Logging
      • ログ収集サービス
    • 共通機能
      • リソースのグループ化
        • Compute EngineやEC2を個々のリソースとして監視するだけではなく、グループ化して監視することが可能
        • スケールをするにはグループ全体のリソース状況を監視することが大事
        • 「リソース全体でサービス提供可能な状態かどうか」が大事
        • 個々のリソースを見た場合にも大事。やばいリソースは切り離すとかができるから
      • リソース表示画面
        • リソースの使用状況を確認できる
      • ダッシュボード機能
        • Monitoringには自分で指定したメトリクスをグラフィカルに表示するダッシュボード機能がある
      • アラート機能
        • メトリクスと対象リソースとしきい値、状態を設定することでアラートを発報
        • 通知方法はメールとCloud Console モバイルあぷり、プレミアム階層ではもっとリッチ
    • コンピューティングサービスの運用監視
      • リソース利用率監視
        • Monitoringのメトリクス監視機能
      • サーバー死活監視
        • MonitoringのUptime Checks機能を利用
      • プロセス起動数監視、アプリケーション監視
        • Monitoring
      • ログ監視
        • Logging
        • サービスごとに取れるログが違う
          • Compute Engine
            • 実行オペレーションログ
            • OS、ミドルのエージェントログ
          • App Engine
          • Kubernetes engine
            • コンテナログ
            • システムログ
            • イベント
      • URI監視
        • 200OKの返却を確認する
    • ストレージサービスの運用監視
      • Monitoringはの監視メトリクスがデフォルトで用意されている
        • Cloud Storage
        • Cloud SQL
        • Cloud Datastroe
        • Cloud Bigtable
        • Cloud Spanner
      • Logging
        • リソース作成、設定変更のAPI操作ログを取得
    • ネットワーキングサービスの運用監視
      • Monitoring
        • Cloud Load Balancer
        • Cloud VPN
        • Interconnect
      • 多様なデータ量を監視可能
    • ビッグデータサービスの運用監視
      • Monitoring, Loggingで監視可能
    • AWS環境監視
      • いろいろ
  • 効率的なアプリケーション開発を実現するStackDriver
    • Error Reporting
      • アプリケーションで発生したエラーを集計・表示するインターフェースを提供
      • 設定方法
        • App Engine, Cloud Functionsでは自動で利用可能なように構成
        • Compute Engine, k8s Engine, AWS EC2では手動設定が必要
      • 表示内容
        • 最も頻繁に発生しているエラーのリストが表示される
        • このリストはError Reportingがスタックトレースの内容を分析し、類似したものをグルーピングした結果を表示しており問題となっている内容をじん迅速に把握することが可能
      • 通知
        • メールまたはモバイルで通知可能
    • Trace
      • レイテンシに関する情報を収集する
      • 設定方法
        • App engine SE番では自動
        • App Engine FE版、Compute Engine, Kubernetes Engineでは、SDKをインストールするかTrace APIを呼び出すことで利用できる
      • 日時解析レポートとカスタム解析レポート
        • 日時レポオートとカスタムレポートが提供される
      • 分析情報
        • 問題が合うr場合にはパフォーマンス分析情報を提示する
      • トレースリスト
        • 発生したアプリケーションに対するリクエストのリストを表示
        • 絞り込みが可能
      • トレースの詳細
        • トレースリストで表示したURIを選ぶと詳細情報を出すことができるy
        • タイムラインでルートスパン、サブスパンが表示
    • Debugger
      • 本番環境稼働中のアプリケーションに対して直接デバッグするもの
      • 設定方法
        • App Engine SE版は自動的に利用可能な様に構成されている
        • FE版、Compute Engine, k8s engine, EC2は手動設定が必要
      • スナップショット
        • ソースコードの特定行のローカル変数とコールスタックを収集したものをを示す
        • GUI上で指定すればとれる
        • デバッグを行うために下記を指定可能
          • スナップショットの条件
          • スナップショットの式
      • ログポイント
        • ソースコードにログポイントをアドホックに稼働中の本番環境に追加可能
        • 追加後24時間後に自動的に解除される
        • オーバーヘッドはソースコードに通常記載されたロガーと一緒
        • 画面上のログパネルで確認可能
        • App Engineのみログパネルを利用可能

第9章 GCPを利用したWebシステムの設計構築

  • List&Shift方式
    • 何も変えずにそのまま移行する
  • 理由
  • 移行後の構成
    • Webアプリケーションを以降するのはあまりそこまで大変じゃない。
    • でもIaaSにそのまま移行した感じ
    • 構成
      • Cloud Load Balancing
        • Web/AP GCE - DB GCE
        • Web/AP GCE - DB GCE
          • 運用監視サーバ−(オンプレミス)
      • Cloud Storage
        • 静的コンテンツ
    • 考慮ポイント
      • IP
      • OSミドルウェアのアップデート
      • ソフトウェア・ライセンスの考慮
        • プロセッサ、コア単位での課金の場合GCPへの持ち込みhあこんない
  • マネージドサービスの活用
    • 課題
      • インフラ維持が大変
        • OSミドルの管理はめんどい
      • 突発ピーク対応
        • 流量制御
        • 余剰リソースの確保
        • できればスケーリングアーキがよい
    • 新構成
      • FrontEnd App Engine
        • Cloud Storage
        • Cloud DataStore
      • Cloud Storage
        • 静的コンテンツ
      • GKE
        • Cloud  SQL
        • Container Registry
      • Stackdriver
    • Cloud SQLボトルネックになりかねない
    • Web/APサーバーがマネージドサービス化
      • App Engineを利用することでかなりマネージドな状況になる。スケーリングなど。
      • しかし制約も大きいので、GKEをバックエンドに利用するなどの工夫が必要

第10章 GCPを活用したハイブリッドクラウド環境の構築