はじめに
- この記事は、Qiitaアカウントの整理のため、別のアカウントで投稿した過去の記事を移行してきたものです。全く同様の記事があるかもしれませんが、盗作等ではありませんのであしからずご容赦ください。
- 過去記事 投稿日：2019年07月04日
GCP Cloud OnBoard Tokyo アーキテクトデザイン講座
2019/06/28@Google 六本木オフィス
アーキテクトデザイン講座
「アーキテクチャ原則とパターンで学ぶ、実践的な GCP 使いこなし講座」
- ハッシュタグ：#GoogleCloudOnBoard
アーキテクト原則
-
どうやって作りますか？
- Small is beautiful
- 1つのプログラムには1つのことをうまくやらせる
- わかりやすい、保守しやすい，システムリソースにやさしい、ほかのツールと組み合わせやすい
- Make each prgram do one thing well
- 疎結合
-
マイクロサービスを適用するか否か：ケースバイケース
- 中央管理が難しいもの
- 中央管理化するほうが統制が取りやすいので、その場合はモノリスもあり
-
コンピュートの要件とプラットフォームのマップ
- VM
- Compute Engine
- サーバレス
- App Engine
- Cloud Functions
- コンテナ
- Kubernetes Engine
- サーバレスとコンテナの中間？
- Cloud Run(New)
- AppEngineに近いが、Cloud RunはDocker コンテナを対象としている
- AppEngineに対応していない言語等をDockerコンテナとしてサーバレス稼働が可能
- Cloud Run(New)
- 大規模サーバ環境であればKubernetesも選択肢
- 通常規模はサーバレスが第1選択肢だろう
- App Engine
- FlexibleとStandardの違い
- 言語の制約
- flexibleだとApp Engine上でVM稼働→Docker コンテナ稼働 が可能
- 起動時間が遅くなる（Flexible）
- スタンダード第2世代ランタイムでコンテナ稼働に頼らずに制約を取り除こうとしている
- ｇVisorを使った隔離メカニズム
- App EngineはWEBアプリケーション
- HTTP/Sリクエストレスポンス
- ステートレス
- Starndardの制約：リクエストタイムアウト60秒
- Flexibleの制約：スピンアップに時間がかかる
- FlexibleとStandardの違い
- Cloud Run
- マネージドKnative（オープンソース）＝OSSによってベンダーロックインが防げる
- コンテナで任意のコードを実行
- オートスケール
- GKEにもデプロイ可能（Cloud Run on GKE）
- 基本HTTP/Sのステートレス
- 制約：WEBアプリケーションのみ、現状ベータ
- ※GAにならずにベータのままだとSLA違反（返金等）が適用されない
- Cloud Functions
- HTTP Function もしくはバックグラウンドFunctionによるトリガー実行
- Node,Python
- Pub/SubやCloud Storageを使ったサーバレス
- 実行環境を考えたくない場合にFit
- データ変換（ETL）
- GKE
- 5分でKubernetesをセットアップ
- Write Once,Run Anywhere
- GKEはクラスタ自動管理
- Compute Engine
- Cloud Launcher
- VM
-
プラットフォームの選択肢
- マネージドサービスが使えないかまず考える
- マイクロサービス・アーキテクチャの考え方にのっとってアプリケーション機能を分解してみる
-
コンテナはレイヤを移動できる
- Cloud Run ー Kubernetes Engine － Compute Engine
-
データベースの選択肢
- Cloud SQL
- RDBのマネージドサービス
- MySQL,PostgreSQL
- 年内にMS SQLServer
- 自動レプリケーション
- READレプリカ、Failoverレプリカ
- マネージドバックアップ
- 制約
- MySQL 5.6,5.7,PostgreSQL 9.6
- ディスク最大10TB
- 4000同時コネクション（MySQL）
- 500同時コネクション（PostgreSQL）
- コンフィグレーションの制約
- 計画停止
- Cloud Spanner
- フルマネージドのグローバルスケール分散DB
- Google独自開発、Googleサービス（Gmail等）で利用されている
- 分散DBでありながら、一貫性と可用性を両方保つ
- ゾーン間、リージョン間の自動レプリケーション
- Spannerは分散DB：特性を考えて設計する必要がある
- テーブルデータはスプリットに分割され、それぞれ特定のサーバに割り当てられる
- INTERLEAVEすることで、スプリット境界を制御し、関連データを同一サーバに持たせることができる
- ホットスポット問題：分散データベースで、分散がうまくいかなかった場合、特定のサーバへのアクセスが集中する問題が起こりえる
- 主キーの工夫によりデータを分散させる
- 高性能要件を持ったアプリケーション向き
- 高い可用性要件を持ったアプリケーション向き
- DBのシャーディングを手動で行いたくない場合
- 制約
- 高コスト
- 既存DBとの互換性（独自のテーブル設計が必要）
- リージョン間レプリケーションの提供エリアが限定
- Cloud Datastore
- フルマネージドのNoSQLデータベース
- もともとはGAE
- REST/gRPC APIを介してアクセス
- スキーマレス
- 自動スケール
- 冗長性が組み込まれている
- ACIDトランザクションをサポート
- GAEのバックエンドとして最適
- 可用性重視
- 制約
- 属性クエリの制約
- 書き込み性能（高い書き込み性能を求めるならBigTable）
- ※後継のFireStoreにサービスが置き換わっていく予定
- Cloud Storage
- データのライフサイクル管理が設定可能
- 365日経ったらNearlineに移す
- 1095日経ったらColdlineに移す
- といった設定が可能
- データのライフサイクル管理が設定可能
- Cloud SQL
-
WEBアプリケーションのパターン
- 静的ホスティング
- Cloud Storageでホスティング可能（WEBサーバ機能あり）
- 独自ドメインのマッピングも可能
- 独自ドメインだとHTTPSアクセス不可
- →ロードバランサかますとかで対応
- 独自ドメインだとHTTPSアクセス不可
- 独自ドメインのマッピングも可能
- 署名付きURL：Googleアカウントなしでも一時的アクセス許可が可能
- Cloud Storageでホスティング可能（WEBサーバ機能あり）
- GAE基本パターン
- App Engineをフロントに置き、動的APIをホスティング バックエンドにストレージ配置
- ロードバランサ不要
- App Engineをフロントに置き、動的APIをホスティング バックエンドにストレージ配置
- GKE基本パターン
- Cloud LBを前段に配置し、複数ZoneにKubernetesEngineを分散配置（GKEの「リージョナルクラスタ」）
- LoadBalancerはGKEのKubernetesオブジェクトを作成すると自動的に構成される
- GKE外部DBパターン
- Kubernetes上でステートを持たず、バックエンドの外部DBにステートを保持するパターン
- マルチプラットフォームパターン
- Cloud LoadBalancerでURLパスによってバックエンド（GKE,GCE,GCSなど）に振り分ける
- CDNパターン
- Cloud CDNはCloud Load Balancerと一体化している
- ログ収集パターン
- GCE,App Engine,GKE等のアプリケーションの後ろにStackdriver Loggingを配置、一時保管→設定ベースでBigQuery,CloudStorage にエクスポート
- ログ収集のリアルタイム処理パターン
- Stackdriver LoggingからCloud Pub/Subをメッセージハブする
- →Pub/SubのイベントをトリガーにしてCloud Dataflow,Cloud Functionsにてストリーム処理→データストアへ
- ログ収集外部システム連携パターン
- Stackdriver LoggingからPub/Sub→gRPC/HTTPSでAPIコール
- もしくはCloud Storageに保管し外部転送
- 連携のパターン
- クラウドと既存のデータセンター連携
- イベント送信パターン
- クラウド外部から少量のデータをリアルタイム送信
- HTTPS経由でPub/Subに飛ばす
- クラウド外部から少量のデータをリアルタイム送信
- クラウド：様々な要因が絡むため不具合も多い
- 失敗したときの例外ハンドリング：エクスポネンシャルバックオフ
- アプリケーション連携パターン（オンプレとクラウド）
- プライベートIP空間を使って、オンプレとクラウドのアプリケーションを密結合（IPSec VPN または占有インターコネクト）
- 静的ホスティング
セキュリティ
- ユーザ
- 認証、認可
-
Cloud Identity
- マネージドID管理サービス
- すべてのGoogle製品で利用されているもの
-
ディレクトリ同期ツール
- Google Cloud Directory Sync
- オンプレのADやLDAPから同期、シングルサインオン的な認証が可能
- 無償提供
- Google Cloud Directory Sync
-
Titan Security Key
- セキュリティキーを使った2段階認証
- Googleが作成したファームウェア
- フィッシング体制のあるハードウェアトークン
- ※ワンタイムパスワードは必ずしも万全ではない
-
Andoroidセキュリティキー
- 2要素認証用
-
Identity Platform（旧称CICP）
- 自社のアプリにユーザID管理機能を追加
- サードパーティーのIDをアプリケーションに組み込み可能（Facebook、Twitterなど）
-
IAM
- 認可の仕組み
- 誰が、どういう操作を、何に対してできるかを設定、管理
-
サービスアカウント
- 個々のユーザではなく、アプリケーションや仮想マシンに付与する特別なGoogleアカウント
- 個々でログイン用に使うのではなく、アプリケーションやVMが利用するアカウント
-
IAMのロール
- Primitive Roles:基本の役割
- オーナー、編集者、閲覧者の３つのみ
- Predefined Roles:事前定義された役割
- サービスごとなど、狭い範囲のアクセス権
- Custom Roles:カスタムの役割
- Primitive Roles:基本の役割
-
IAM Conditions
- IAMの役割を割り当てる際の条件として、属性を指定できる
- 属性例：
- 接続元のIPアドレスレンジ
- デバイス
- 日付曜日、時間帯
-
Policy Intelligence
- ポリシーをより正しく理解することでリスクを低減する
- IAMRecommender：機械学習により、ユーザごとに適切なロールを推奨
- Access Troubleshooter：アクセス権限委関連するエラー原因を調査解決
- Validator：リソースに対するアクセス設定がベストプラクティスに沿っているか検証
-
GCEリソースレベルIAM
- Compute Engineに付属する各種リソースに個別にアクセス権限を設定できる
-
組織とリソース階層
- 組織
- フォルダ
- プロジェクト
- リソース
- プロジェクト
- フォルダ
- 組織
-
組織ポリシー
- 組織に対して制限を設定できる
- 対象のリソース階層の子孫は組織ポリシーを継承する
- 組織に対して制限を設定できる
-
Identity-Aware Proxy（IAP）
- ゼロトラストを実装したBeyond Corpがベース
- G Suiteと組み合わせた物理セキュリティキーの2段階認証
-
IAP for TCP forwarding
- Google認証とTCP転送機能をマネージドサービスとして提供
- 外部IPのないVMインスタンスに、IAPを経由してTCPトンネルを作成
- 踏み台ホストがなくてもVMインスタンスへログインできる
-
ユーザ管理のベストプラクティス
- IDの一元管理
- 自動化
- 2段階認証
- 最小限の権限
- ユーザではなくグループに対してロールを付与する
-
- 認証、認可
- アプリケーションデータ
- 暗号化、脆弱性チェック
- デフォルトですべてのデータが暗号化される
- バケットロックと保持ポリシー
- GCSをWORM（Write-Once-Read-Many）ストレージとして利用
- 改ざん防止、変更不可
- データ保管要件に対応する必要がある金融系など
- KMS(Key Management Services)
- デフォルトの暗号化、顧客管理のカギによる暗号化、顧客が提供するカギによる暗号化のそれぞれについて暗号化カギを管理
- Cloud DLP API Data Loss Prevention
- 個人情報の漏洩を防ぐための機能
- 個人情報などの機密情報を自動識別
- マスキング、日付シフト、フォーマット指定した暗号化や変換
- 画僧にも対応
- 再識別リスクの分析（ｋ－匿名性）
- どこにあるコンテンツでも、DLP APIに送ることが可能
- Google側には保存されない
- Cloud Data Loss Prevention ユーザインターフェース
- Google Cloud ユーザ保護サービス
- WebRISK API
- Phishing Protection
- reCAPTHCA Enterprise
- Cloud Security Scanner
- GAP、GCE,GKE上のコードの脆弱性を検出
- XSS,Flashインジェクション、平文パスワードなどを検出
- Container Registry 脆弱性スキャン
- プライベートなコンテナレジストリにpushされたコンテナイメージを自動でスキャン
- アプリケーション・データセキュリティのベストプラクティス
- データ暗号化
- 情報漏洩を防止
- DLP APIを使う、DLPをシステムに組み込む
- アプリの脆弱性を自動検出
- コンテナイメージに潜む脆弱性を検出
- インフラストラクチャ
- VMインスタンス、コンテナ、ネットワーク
- OS Login
- IAMの設定だけで、OSへのログインを管理（OS上で設定する必要がない）
- 管理者権限の有無等もふくめて、IAM上で管理
- Shielded VM
- セキュアで検証可能なVM
- VMが低レベルで改ざんされていないことを保証
- Container-Optimized OS
- GCE,GKEで利用可能な安全軽量なOS
- ChromiumOSベース
- 大部分がread Only
- 自動OSアップデート
- シリアルコンソールアクセス
- VMインスタンスのシリアルコンソールへ接続
- 監査ログの記録も可能
- Binary Authorization
- 開発中に信頼された認証局による署名がデプロイに必要
- Cloud NAT
- NATのマネージメントサービス
- 従来のNATソリューションとは異なり、VMインスタンス等を使わないSoftware-definedサービスとして実装
- 複数IP付与可能
- リージョン内で冗長化
- ファイアウォールルール
- プロトコルやポート、IPのほかにタグを利用したルールの定義が可能
- Google Cloud Load Balancing
- 複数リージョンにあるサーバを1つのLBだけでカバーできる
- グローバルで1つのIPアドレス
- 自動でスケール（事前申請不要）
- ヘルスチェック
- Cloud Armor
- HTTPSロードバランサに付属可能な高度なセキュリティ機能
- DDoS対策
- IPアドレスのWhitelist/BlackList
- HTTPSロードバランサに付属可能な高度なセキュリティ機能
- 共有VPCネットワーク
- 組織内の「複数プロジェクト」間でのプライベート通信を可能とする
- プロジェクト間は基本的には接続不可
- 組織内の「複数プロジェクト」間でのプライベート通信を可能とする
- VPC Service Control
- 仮想的なサービス境界を構築し、境界内でのみAPIアクセスが可能
- ACLの設定誤り
- 外からの攻撃
- 不正な内部ユーザの持ち出し
- などから防御
- 仮想的なサービス境界を構築し、境界内でのみAPIアクセスが可能
- VPC Service Control 境界ブリッジ
- プライベートGoogleアクセス
- Google マネージドサービスへのプライベートなアクセスを提供
- 外部IPではなく、内部IPアドレスを使用してGoogle APIと接続
- オンプレホスト用のプライベートGoogleアクセス
- オンプレのセキュリティ境界をクラウドまで延長
- インフラストラクチャのベストプラクティス
- VM/OS/コンテナを保護
- Globalなロードバランサ
- 外部IPアドレスを最小限に
- 情報漏洩の可能性を最小化する
- セキュリティのための運用
- 監査ログ
- 誰が、何を、どこで、いつを記録
- Stackdriverロギングに蓄積
- ファイアウォールルールロギング
- ルール毎にロギングのON/OFFができる
- TCP,UDPのみが対象
- デフォルトルール、暗黙ルールに対するログ設定はできない
- VPC Flow Logs
- VPC内部のログを取得
- Cloud Security Command Center
- ダッシュボード的なUIでクラウドのリソースを可視化し、脅威を防止
- 脅威を検出し対応
- 柔軟なプラットフォームでセキュリティのニーズを満たす
- Event Thread Detection
- ログを自動スキャンし、疑わしいイベントを検出する
- Security Health Analitics
- GCPインフラストラクチャの設定をスキャンし、設定上の問題を検出する
- Access Transparency
- Googleのサポートエンジニアが顧客のリソースにアクセスしたログを記録
- アクセス理由やリソース、日時、操作を行った場所
- Googleのサポートエンジニアが顧客のリソースにアクセスしたログを記録
- セキュリティ運用のベストプラクティス
- 監査ログ取得
- 必要なログを判断して個々に設定をONにする
- 脆弱性を管理する
- Security Command Centerをダッシュボードとして使う
- Access Transparency
- ログ運用
- 長期保存が必要なログは、GCSやBigQueryなどにエクスポートする
- 監査ログ取得
- 監査ログ