第1章 Google Cloud Platform の特徴
- GCPはPaaSからIaaSにすすんだプラットフォーム
- Google自身がGCPの大きなユーザーの一人
- ライフマイグレーション
- 仮想マシンから物理サーバーへ移動させる技術
- 可溶性が高い
- グローバルネットワーク
- クラウドを利用するには提供社の歴史などを考えてみることが大事
- k8sはBorgというやつ
- 自身がやりたいことに対しｔえあっているのか？ということを検討する必要がある。GCPは「大規模分散コンピューティング」「インフラの隠蔽、共用化」といったことをやっている分野。メリットを理解する必要があります。
第2章 コンピューティングサービス
- GCPのコンピューティングサービスは下記の4つ
- Google Compite Engine: IaaS
- CGoogle App engine: PaaS
- Google Kubernetes Engine: コンテナ
- Google Cloud Functions: ラムダ的な
- GCE
- 永続ディスクサイズは64TBが最大
- 標準、ハイメモリー、ハイCPU、共有コアの四種類
- 共有コア：リソースが小さくて大丈夫なもの。0.2, 0.5コアとか。こいつについては、3TBまでの永続化領域
- ハイCPU: 96コアまで
- ハイメモリー: 624Gバイトまで
- GPUも独自に積んでいる。
- ライブマイグレーション機能は使えない（仮想環境を利用しながら物理環境にマイグレする機能）
- OS
- ディスク
- 課金
- 確約利用割引
- 利用期間をコミット
- やすい
- 継続利用割引
- 利用課金
- たくさん使えば単価が下がる
- プリエンプティブルVM
- やすいやつ
- 起動後24時間以内に必ず停止される
- システム需要に応じて必ず停止される
- Compute Engineの基本機能
- App Engine
- PaaS
- StandardとFlexible
- SE
- 機能制限が多い
- 高いサービスレベルを維持したまま
- FE
- 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
- ドキュメント指向データベース
- NoSQL
- 機能がBigTableより豊富
- BigtableをベースにSQLライクな利用ACIDトランザクション
- Atomic
- Consistency
- Isolation
- Durable
- Google Cloud SQL
- リレーショナル・データベース
- MySQLやPostgresSQLなどのマネージドサービス
- Google Cloud Spanner
- Google Cloud Bigquery
- 解析用
- ストレージサービスの使い分け
- 構造化データでない
- Cloud Storage一択となる
- 耐久性99.9999999(イレブンナイン)
- 構造化データ
- Cloud Storage
- S3相当のサービス
- オブジェクトストレージ
- 独自のCDNを持っている
- エッジという拠点にデータが複製されるので、世界中からアクセスが可能
- バケットとオブジェクト
- ストレージクラス
- オブジェクト似合いしてストレージクラスが設定される
- 可用性、耐久性、最小保存期間、料金が異なる
- 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のコアサービスはこれを利用しているらしい
- 大規模、低レイテンシ、高スループット
- 生い立ち
- ストレージタイプ
- 基本機能
- アクセス制御
- IAMでの制御
- 暗号化
- 自動
- ユーザー指定鍵は利用できない
- バックアップ
- テーブルにデータを書き込むと３台以上のサーバーに自動でレプリケートされる
- 耐久性は高い
- 論理バックアップが七曜な場合はユーティリティを利用したバックアップを検討したい
- 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の基本機能
- Spanner
第4章 ネットワーキングサービス
- ネットワーキングサービスの種類
- 下記の5種類ある
- VPC
- ユーザー自身が定義したVPCネットワーク内でコンピューティングリソースを起動できる
- VPC内のリソース同士をプライベートネットワークでつなげることができる
- プロジェクト内にVPCを作成
- 異なるリージョンに配置されたインスタンスでも同じVPCに所属できる。そのインスタンスはGoogleのプライベートネットワークでアクセスする。
- 異なるVPC内はインターネット経由で通信する
- VPCネットワークとサブネットワーク
- 複数のサブネットを定義可能
- 1サブネットは1リージョン所属
- デフォルトは
- すべてのリージョンに1つのサブネットが作成された状態
- 各サブネットにはRFC1918に従うプライベートIPアドレスがありり、GCPリソースを利用可能
- リージョンとCIDRを指定するだけで、ゾーンにまたがったサブネットを作成可能
- これはGCPの特徴
- マルチゾーン構成がしやすい
- 外部IPアドレス
- GCPプロジェクトごとにIPは確保する
- GCPではエフェメラルな外部IPアドレスを固定された外部IPに変換する機能がある
- 固定IPにプロモートするようにしないといけない
- 下記の2種類存在
- リージョンIPアドレス
- リージョン内でのネットワークの負荷分散
- グローバルIPアドレス
- 複数のリージョンでの負荷分散する
- ネットワーク通信制御
- ステートフルなファイアウォール
- VPCごとにインバウンド、アウトバウンドを設定する
- インバウンドは
- アウトバウンドは、
- すべて可
- タグを設定することが可能。
- タグはインスタンスに付与するラベル。IPを指定せずともタグのみでネットワーク通信制御を行うことができる
- VPCネットワークピアリング
- GCPでは異なるVPC感はインターネット経由
- VPCネットワークピアリング機能を利用するとプライベート接続が可能になる
- IPの重複がなければピリング設定だけで接続可能
- VPCネットワーク間ではピアリングされていれば内部負荷分散機能を利用可能
- VPCピアリングは最大25個まで直接ピアリングされたネットワークを設定することが可能
- 異なるプロジェクト間でも利用可能
- 自社オンプレ → vpn 東京リージョン → ピアリングした外部リージョン
- 限定公開のGoogleアクセス
- VPCネットワークにおける注意点
- Cloud Load Balancing
- ELBのようなアクセス増大する際には事前の申請が不要
- HTTP負荷分散
- HTTPリクエストを世界中のサーバーへ負荷分散する機能
- 1グローバルIPで複数リージョンへの振り分けが可能
- 外部クライアントからのリクエストは最もの遠いPoP (Point of Presence) で終端され、クライアントのアクセス元に最も近いリージョンに配置されたバックエンドインスタンスに転送される
- Google Cloud CDNと連携して、世界中にあるGoogleのPoPを利用してクライアント近くにコンテンツをキャッシュして短い処理を実現する
- 耐障害性も高い
- コンテンツベースでの負荷分散も可能
- Stackdeiver Logging のログビューアーからリクエスト状況を確認することが可能
- ネットワーク負荷分散
- Cloud CDN
- Cloud DNS
- 低レイテンシー、高可用性のサービス
- Cloud DNSでサポートされるレコードタイプ
- Cloud Interconnect
- IPsec VPN
第5章 ビックデータサービス
|
データ収集
|
データ蓄積
|
データ処理・分析
|
データ探索・可視化
|
|
Cloud Pub/Sub
|
|
|
|
|
|
Big Query
|
|
|
|
|
Cloud Dataproc
|
|
|
|
|
|
Cloud Dataflow
|
|
|
|
|
|
Cloud Datalab
|
- BigQueryとDataprocの違い
- 両方ともデータ蓄積、処理、分析ができるが性質やコンセプトが異なる
- お互いを補完するサービスなので、特徴を踏まえて組み合わせて使っていくこと
- Cloud Pub/Sub
- メッセージングサービス
- 低レイテンシ
- 基本概念
- メッセージライフサイクルと内部処理
- 内部リソースには下記が存在する
- トピック
- サブスクリプション
- ライフサイクルは下記のながれ
- システム設計をする上での考慮事項
- Pub/Subはメッセージの順序制御を保証していない。そのため、そこは依存しないようなシステム設計にする必要がある
- 順序制御が必要な場合あdatastoreやCLoud SQLを利用すればできなくはないが大変。非推奨。
- at-least-once配信
- 内部ストレージに保存したメッセージを順番に1回配信する。アプリケーションレベルで受信確認が行われるので、複数回配信もありえる。PussubI/Oを利用すれば、カスタムメッセージID、Cloud Pub/Subが割り当てたIDのメッセージの重複を排除することができる
- 基本機能
- アクセス制御
- 主な利用方法
- BigQuery
- フルマネージドデータウェアハウスサービス
- データウェアハウスとは、、、
- データの保管から管理分析までを行うサービス
- BigQueryは
- ストリーミングデータ収集
- データ保存のストレージサービス
- クエリーエンジン
- Dremelの技術を採用
- 基本概念
- 内部リソース
- ストレージリソース
- クエリリソース
- CPUとRAMの演算能力
- BigQueryを利用する際に意識するリソースは
- システム設計する上での考慮事項
- クエリーの種類
- インタラクティブクエリー
- 即時実行
- 50個の同時実行レート
- バッチクエリー
- キューイングされてクエリリソースがアクティブになったタイミングで実行
- 24時間以内に実行されない場合はインタラクティブクエリーになる
- 数分以内に通常は実行される
- 同時実行の制限なし
- 大量実行はこっちの種類を選択
- データインポートと更新
- データ挿入処理に特化している
- レコード単位でのデータ操作はできない
- データソースから既存テーブルにインポートする場合は、データ追加か上書きしかできない
- データセットとテーブルの単位
- データセットは利用目的の単位で分割したほうが良い
- BigQueryへの接続方法
- クエリーの実行結果
- 実行結果は一時テーブルに24時間自動的に保存される
- 全く同じクエリーを実行した場合には一時テーブル及び永続テーブルの内容を返すのでクエリー課金は発生しない
- クエリーの実行結果はCSVやJSONでダウンロード可能
- 料金
- 定額料金
- オンデマンド料金
- 基本機能
- アクセス制御
- IAMを利用したプロジェクトレベルでのアクセス制御
- データセットレベルでのアクセス制御
- バックアップ
- スナップショットが取得可能
- 標準AQLのスナップショット機能はない
- 暗号化
- 保存時に暗号化
- Cloud KMSも利用可能
- ネットワークセキュリティ
- DatastoreやCloud Storageからデータインポートする際にはGCPのプライベートネットワークを利用した通信が実施
- BigQueryAPIを叩く場合にはインターネット経由でのアクセスになる\\
- 可用性・耐障害性
- モニタリング
- クエリープラン
- 主な利用方法
- アドホックな分析
- Cloud Dataflow
- データ処理パイプラインサービス
- 基本概念
- 利用するためには2フェーズを考える必要がある
- システム設計をする上での考慮事項
- SDKの選択
- データの格納場所とデータ形式
- 格納場所とデータ形式によって、最初のRead処理と最後のWrite処理、PCollectionの表現方法が異なってくる
- テンプレートの利用
- Cloud Dataflowには下記のテンプレートが存在する
- ユーザー定義のテンプレート
- Cloud Storageに格納することでDataflowから呼び出して利用することができる
- Googleが提供するテンプレート
- テンプレートを利用することでパイプラインの再コンパイルが不要になる。
- 基本機能
- アクセス制御
- IAM
- サービスアカウントでパイプラインの実行をする
- Dataflowで初めてリソースが作成される際に自動的に作成される
- データの格納場所としてCloud StorageやBigQueryを指定する場合、ACLを利用したリソースレベルでの権限設定でCloud Dataflowからのアクセスに制限することでデータアクセス観点でのセキュリティレベルを向上することが可能である
- 暗号化
- パイプライン処理の中で作成される一時テータは保存される場合には暗号化され、パイプライン処理が終了したタイミングで破棄される
- ネットワークセキュリティ
- パイプライン処理では、データソースおよびに出力先とCloud Dataflow間のデータ送受信、ワーカーノードのデータ受け渡しの２箇所でのデータ転送が行われる
- スケーリング
- ワーカーノードの最小数、最大数を指定するので、その間であれば自動でスケーリングすることが可能である
- 自動スケーリングを行った場合でも、割当の不均衡だったりリソースの有効活用ができない場合がある。こういった状況の回避のために、動的作業再調整機能が備わっている
- Apache Sparkを利用して実装することも可能だが管理を実施する必要があり、それはそれで大変なのでマネージド・サービスを利用したほうが良い
- 可用性・耐障害性
- 月間SLAは99.9
- モニタリング
- Webベースのモニタリングインタフェースがある
- Cloud Dataflowの主な利用方法
- Cloud Dataproc
- システム設計をする上での考慮事項
- 基本機能
- アクセス制御
- IAMでのプロジェクトレベルのアクセス制御
- 暗号化
- データ保存時にはすべて暗号化
- ユーザー指定の鍵はNG
- ネットワークセキュリティ
- スケーリング
- Cloud DataprocはCompute Engineの特徴を引き継ぐサービス
- 負荷状況に応じた自動スケーリング機能はない
- スケーリングが必要な状況は下記の状況
- ワーカーノードを増やして処理の多重度をあげt、ジョブの実行時間を短くする
- ワーカーノードを減らして処理の多重度をさげ、費用を抑える
- ノード数を増やしてHDFSストレージの容量を拡張する
- scheduled-deletionクラスタとして作成した場合には処理を実行していない日アクティブなクラスタに対して下記の3パターンでクラスタ削除するように実行可能
- 可用性・耐障害性
- マスターノードは3台構成にすることができる（SPOF回避）
- マルチゾーン配置をサポート指定にあので、単一ゾーン障害が発生した場合にはサービスを利用できなくなる
- 単一ゾーン障害を考慮する場合には、その対処wお考える必要がある。
- Cloud Dataprocはマネージド・サービスといいつつ、Compute Engineをインスタンスを利用しているのでその特徴の障害も発生しうる
- 主な利用方法
- Cloud Datalab
- 対話型データ分析、機械学習ツール
- Jupyter Notebookをベースにしたサービス
- 下記をデータソースにしてデータ分析ができる
- BigQuery
- CLoud Machine Learning Engine
- Compute Engine
- Cloud Storage
- 基本概念
- コンテナでパッケージングされている
- Compute engine上で実行する
- SSH接続用のファイアーウォールルールが必要だが、自動的に作成される
- Python, SQKコード、コードの実行結果をノートブックという単位で管理する
- Cloud Source Repositoryに保存される
- Cloud Datalabを利用する上での考慮事項
- ライブラリ
- Auto Shutdown
- 利用時のみ起動することが推奨される
- Auto shutdown機能を有効にすると、一定時間のアイドル時間後に自動で停止する
- 基本機能
第6章 機械学習サービス
- 機械学習には下記が必要
- モデル
- 良いデータ
- 機械学習の補助サービスには2種類存在する
- GCPの機械学習関連サービス
- ただし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つの機能
- GUIはシンプル。下記のみ
- 学習を実行するジョブを実行
- 生成されるモデルを管理
- 用語と動作イメージ
- Cloud AutoML
- α版
第7章 アカウント管理・請求管理
- アカウント請求管理の概要
- GCPプロジェクトには下記が紐付t区
- プロジェクトID
- ユーザーが決められる
- グローバルで一意である必要がある
- プロジェクト名
- ユーザーが決められる
- 重複OK
- プロジェクト番号
- Google側で自動採番
- GCPプロジェクトと請求先アカウントは紐付いている必要がある
- 請求アカウント管理
- GCPプロジェクトを作成すると、GCP使用量を支払うための請求アカウントが紐付いている必要がある
- 割と柔軟な管理が可能
- GCPプロジェクトの管理者とは別に、請求先アカウントの管理者権限のみをもつアカウントを用意することが可能。請求管理だけさせられる。
- 請求管理のための機能
- 予算作成
- アラートの機能
- 課金データエクスポート機能
- Cloud IAM によるアカウント管理
- 基本概念
- ホワイトリスト方式のアクセス管理
- 許可されたの操作のみ実施可能
- IAMで誰がどのようなアクセス権でという権限定義が制御可能
- Cloud IAM Policy
- Cloud IAMで用いるアカウント
- Googleアカウント
- サービスアカウント
- 利用するアプリケーションに属するアカウント
- GCP環境でアプリケーションを実行するときに利用する
- Googleグループ
- 複数のgoogleアカウントやサービスアカウントを管理する際に利用する
- IAMによるアクセス制御をグループに対して実行可能
- IDを確立できないので注意が必要
- G Suiteドメイン
- Cloud Identity ドメイン
- G Suite, Cloud Identityドメインを利用する場合にはGCPプロジェクトの上位にOrganizationという海藻を持つことができる。
- Cloud IAMによるアクセス制御
- アクセス制御を行うには役割を割り当てる必要がある
- リソースに対して許可される操作を<service>.<resource>.<verb>といった形式で指定する。
- compute.machineTypes.list
- IAMでは下記の3種類のRoleがある
- Primitive roles
- プロジェクトレベルで付与する役割。
- 管理者（オーナー
- 編集者（エディター
- 閲覧者（ビュアー
- Predefined Roles
- Custom Roles
- 個別に作成するRole
- プロジェクトメンバーやサービスアカウントに付与できる
- G Suite/Cloud IdentityではOraganization単位でも作成可能
- 筆者の経験では、、、
- GCPプロジェクト管理：数人
- 開発メンバーにはPredifined をしぼって付与
- 必要に応じてCustom role。煩雑にならない程度に。
- Cloud IAMによるポリシー適用
- IAMの定義はOrganization/フォルダ/プロジェクト/リソースの角層レベルで設定可能
- 上位の層で適用されたポリシーは下位層でも有効
- サービスアカウント
- GCPアプリケーションに紐づくアカウント
- アプリケーションを実行する際にユーザーを介さずにGoogleのAPIを呼び出すことが可能
- 役割を与えたサービスアカウント自体をリソースとして扱うことができる
- サービスアカウントを利用することでGCPリソースへのアクセス制御をユーザーと切り離すことができる。
- ユーザーに最小限の権限を与えていなくてもサービスアカウントを利用することでサービスアカウント自身が持つ役割を間接的に持つことになる。
- サービスアカウントはキーペアによるgoogle認証
- サービスアカウントキーにはGoogleが管理するものとユーザー自身が管理するものがある
- ユーザーが管理するキーは補完やローテーションをユーザーが実施する必要があり、多少煩雑である
- GCPにおける監査証跡
- GCPでは役割を付与されたIDの操作ログをCloud Audit Loggingで取得して、確認することができる。
- 下記の2種類のログを取得
- 取得した監査ログを表示するのには下記を利用して確認可能
- 保存期間
- 管理アクティビティログは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つの役割がある
- 運用監視業務を行うためのStackdriver
- Monitoring
- Logging
- ログ収集サービス
- 共通機能
- リソースのグループ化
- Compute EngineやEC2を個々のリソースとして監視するだけではなく、グループ化して監視することが可能
- スケールをするにはグループ全体のリソース状況を監視することが大事
- 「リソース全体でサービス提供可能な状態かどうか」が大事
- 個々のリソースを見た場合にも大事。やばいリソースは切り離すとかができるから
- リソース表示画面
- リソースの使用状況を確認できる
- CPU利用率
- ディスクI/O
- ネットワークトラフィック
- etc
- ダッシュボード機能
- Monitoringには自分で指定したメトリクスをグラフィカルに表示するダッシュボード機能がある
- アラート機能
- メトリクスと対象リソースとしきい値、状態を設定することでアラートを発報
- 通知方法はメールとCloud Console モバイルあぷり、プレミアム階層ではもっとリッチ
- コンピューティングサービスの運用監視
- リソース利用率監視
- Monitoringのメトリクス監視機能
- サーバー死活監視
- MonitoringのUptime Checks機能を利用
- プロセス起動数監視、アプリケーション監視
- Monitoring
- ログ監視
- Logging
- サービスごとに取れるログが違う
- Compute Engine
- 実行オペレーションログ
- OS、ミドルのエージェントログ
- App Engine
- Kubernetes engine
- コンテナログ
- システムログ
- イベント
- URI監視
- 200OKの返却を確認する
- ストレージサービスの運用監視
- Monitoringはの監視メトリクスがデフォルトで用意されている
- Logging
- リソース作成、設定変更のAPI操作ログを取得
- ネットワーキングサービスの運用監視
- Monitoring
- Cloud Load Balancer
- Cloud VPN
- Interconnect
- 多様なデータ量を監視可能
- ビッグデータサービスの運用監視
- Monitoring, Loggingで監視可能
- AWS環境監視
- いろいろ
- 効率的なアプリケーション開発を実現するStackDriver
- Error Reporting
- アプリケーションで発生したエラーを集計・表示するインターフェースを提供
- 設定方法
- 表示内容
- 最も頻繁に発生しているエラーのリストが表示される
- このリストはError Reportingがスタックトレースの内容を分析し、類似したものをグルーピングした結果を表示しており問題となっている内容をじん迅速に把握することが可能
- 通知
- メールまたはモバイルで通知可能
- Trace
- レイテンシに関する情報を収集する
- 設定方法
- App engine SE番では自動
- App Engine FE版、Compute Engine, Kubernetes Engineでは、SDKをインストールするかTrace APIを呼び出すことで利用できる
- 日時解析レポートとカスタム解析レポート
- 日時レポオートとカスタムレポートが提供される
- 分析情報
- 問題が合うr場合にはパフォーマンス分析情報を提示する
- トレースリスト
- 発生したアプリケーションに対するリクエストのリストを表示
- 絞り込みが可能
- トレースの詳細
- トレースリストで表示したURIを選ぶと詳細情報を出すことができるy
- タイムラインでルートスパン、サブスパンが表示
- Debugger
第9章 GCPを利用したWebシステムの設計構築
- List&Shift方式
- 何も変えずにそのまま移行する
- 理由
- 移行後の構成
- Webアプリケーションを以降するのはあまりそこまで大変じゃない。
- でもIaaSにそのまま移行した感じ
- 構成
- Cloud Load Balancing
- Web/AP GCE - DB GCE
- Web/AP GCE - DB GCE
- 運用監視サーバ−（オンプレミス）
- Cloud Storage
- 静的コンテンツ
- 考慮ポイント
- マネージドサービスの活用
- 課題
- インフラ維持が大変
- OSミドルの管理はめんどい
- 突発ピーク対応
- 流量制御
- 余剰リソースの確保
- できればスケーリングアーキがよい
- 新構成
- FrontEnd App Engine
- Cloud Storage
- Cloud DataStore
- Cloud Storage
- 静的コンテンツ
- GKE
- Cloud SQL
- Container Registry
- Stackdriver
- Cloud SQLがボトルネックになりかねない
- Web/APサーバーがマネージドサービス化
- App Engineを利用することでかなりマネージドな状況になる。スケーリングなど。
- しかし制約も大きいので、GKEをバックエンドに利用するなどの工夫が必要
- 現状
- プライベートクラウド
- インターネット公開は
- 公式ホームページのみ
- 帯域細い
- ストレージは不足
- すべてをパブリッククラウドへの移行することは検討していなく、ハイブリッドクラウド構成を検討する