GCPクラウドアーキテクトの模擬試験をAWS脳で解説してみる

[Fusic Advent Calendar 2017](https://qiita.com/advent-calendar/2017/fusic) 19日目担当、@Kta-Mです。
IoTのテスト用仮想デバイス作成サービス[mockmock](https://mock-mock.com/ja/)のプロダクトオーナーをしております。

以前より[AWS アドバンスドコンサルティングパートナー](http://www.aws-partner-directory.com/PartnerDirectory/PartnerDetail?Name=Fusic+Co.%2CLtd.&language=%E6%97%A5%E6%9C%AC%E8%AA%9E)の認定を頂いている弊社ですが、今年はmockmockを通じて[ソラコム インテグレーションパートナー](https://soracom.jp/support_partners/integration/fusic/)、[GCP テクノロジーパートナー ](https://cloud.google.com/partners/directory/?hl=ja)と、新たな領域に踏み出した一年でした。

で、ただいまGCPの[クラウドアーキテクト](https://cloud.google.com/certification/cloud-architect?hl=ja)の認定を取るべく、お勉強中です。
GCPの試験、AWSと違って[模擬試験が無料で何度も受けられる](https://cloud.google.com/certification/practice-exam/cloud-architect?hl=ja)んです！しかも正解を教えてくれる！！

ただ、さすがになぜそれが正解なのか解説まではしてくれないので、GCPにまだ慣れていないAWS脳で解説+蛇足をつらつら書いてみます。AWSは知ってるけどこれからGCPの試験を受けるという、かなりピンポイントな方々の手助けになればと思います。

問題と選択肢の順番は固定のようなので、その前提で書いています。模擬試験を受けないことには何を書いてるのか分からないと思うので、受けてきてからここに戻ってきてください！
https://cloud.google.com/certification/practice-exam/cloud-architect?hl=ja

## No.1 (アクセス頻度の低いデータをクラウドに...)
- AWSのS3に相当するCloud Storageのストレージクラスに関する問題。
- 「アクセス頻度が低い」のでまずNearlineへ保存する。
- 5年以上古いものは使わないので削除する。
- ストレージMultiRegionはアクセスされるエリアへの言及がないので違う。
- (参考)ストレージクラス
  - https://cloud.google.com/storage/docs/storage-classes?hl=ja
  - Multi-Regional Storage
      - 複数リージョンで保存(AWSにはない)
      - 世界中からアクセスされるようなデータに使う
      - Regional Storageに比べるとちょっとパフォーマンスが低いので分析対象のデータなんかには向かない
      - AWSにはCross-Region Replicationがあるけど、こちらはバケット名が別になるし、リージョン間データ転送量がかかってしまう。
  - Regional Storage : 1つのリージョンで保存 (AWS S3の標準クラス)
      - 普通の。
  - Nearline : 低頻度アクセス用(AWS S3の標準 – 低頻度アクセスクラス)
      - 月イチ程度でアクセスされるぐらいのデータ向き
      - AWSと同じく取り出し料金が発生する
      - AWSと同じく最小保存期間が30日
      - AWSと違って最小オブジェクトサイズがない
  - Coldline : さらに低頻度アクセス用(AWS Glacier)
      - 年イチ程度でアクセスされるぐらいのデータ向き
      - AWSと同じく取り出し料金が発生する
      - AWSと同じく最小保存期間が90日
      - AWSと違って低レイテンシで取り出せる
  - 低冗長化(Durable Reduced Availability)も一応あるけど非推奨。
- (参考)ライフサイクル
  - https://cloud.google.com/storage/docs/lifecycle?hl=ja
  - AWSと同じく、保存期間によりNearlineへの移行、Cololineへの移行、削除ができる
  
## No.2 (会社のアーキテクチャは以下の図のように...)
- 異なるリージョンからのアクセスが必要なので、Cloud Storageを選択
- (参考)ストレージ比較
  - https://cloud.google.com/storage-options/?hl=ja
  - 非構造化データ
      - Cloud Storage for Firebase : Mobile用
      - Cluod Storage : AWSのS3/Glacier的なやつ
  - 分析用ストレージ
      - Cloud Bigtable : NoSQLのビッグデータデータベース。低レイテンシで高スループット。HadoopやCloud Dataflow、Dataprocと簡単に統合できる
      - Big Query : SQLでの分析が可能なデータウェアハウス。スケーラブルでフルマネージド。
  - RDB
      - Cloud Spanner : 水平スケーリングが可能なRDB。AWSでいうとAurora Serverlessが近い？
      - Cloud SQL : AWSのRDS的なやつ
  - NoSQL
      - Cloud Firestore for Firebase : Mobile用
      - Cloud Datastore : AWSのDynamoDB的なやつ

## No.3 (大規模なウェブ アプリケーションを構築しています...)
- 「独立したプロジェクト」「RFC1918」を満たすのは共有VPC
- (参考)共有VPC
　- https://cloud.google.com/compute/docs/shared-vpc/?hl=ja
  - 同一アカウントの別プロジェクト間でVPCを共有
  - AWSと違ってGCPには「プロジェクト」という概念があって、プロジェクトごとにまるっと別の環境が作られるイメージ。
- (参考)RFC1918
  - https://www.nic.ad.jp/ja/translation/rfc/1918.html
  - プライベートアドレス空間
      - 10.0.0.0	-	10.255.255.255 (10.0.0.0/8)
      - 172.16.0.0	-	172.31.255.255 (172.16.0.0/12)
      - 192.168.0.0	-	192.168.255.255 (192.168.0.0/16)
  - GCPのドキュメントにはわりとよく出てくる
- (参考)VPC
  - https://cloud.google.com/compute/docs/vpc/?hl=ja
  - http://www.mpon.me/entry/2017/04/22/020428
  - AWSと違ってグローバルなプライベート通信スペースを提供
  - AWSと同じくVPC Peeringがある
  - 同一アカウントの別プロジェクト間でVPCを共有できる(共有VPC)
  - Cloud StorageなどのGCPサービスにもプライベートネットワークで接続可能
  - サブネットの予約IPアドレスは4個
      - ネットワーク アドレス（CIDR 範囲の最初のアドレス）
      - デフォルト ゲートウェイ アドレス（CIDR 範囲の 2 番目のアドレス）
      - 予約アドレス（CIDR 範囲の最後から 2 番目のアドレス）
      - ブロードキャスト アドレス（CIDR 範囲の最後のアドレス）
      - AWSは、0,1,2,3,255の5個が予約されている
  
## No.4 (セキュリティカメラの映像を収集して...)
- 最初の30日間は読み込み頻度が高そうなのでRegional
- それ以降はほぼ使われなさそうなのでアーカイブとしてColdlineに移行
- (参考)永続化ディスク
  - https://cloud.google.com/persistent-disk/?hl=ja
  - AWSのEBSにあたる
  
## No.5 (以下に示す Google Cloud Deployment Manager...)
- インスタンステンプレートに、具体的な永続化ディスクが指定されているのがダメ
  - 1台目はOKかもしれないが、2台目からはアタッチできなくてエラーになりそう
  - そもそもインスタンステンプレートに具体的なディスクの指定があるのがダメなのかも
- (参考)オートスケーリング関連の名称
  - マネージドインスタンスグループ(AWSのAuto Scaling Group)
  - インスタンステンプレート(AWSのLaunch Config)
- (参考)永続化ディスクのアタッチ
  - https://cloud.google.com/persistent-disk/?hl=ja
  - 読み書き可能にするのであれば、1台のインスタンスにしかアタッチできない
  - 読み込みのみであれば、AWSと違って複数台のインスタンスにアタッチできる

## No.6 (次の図に示すような CI/CD パイプラインプロセスが...)
- どこかからDockerイメージを作るためのソースを取ってきてコンテナを作成して、それをデプロイする感じ
- (参考)Cloud Source Repositories
  - https://cloud.google.com/source-repositories/?hl=ja
  - プライベートGitリポジトリ
  - GitHubとの同期もできる
- (参考)Cloud Container Builder
  - https://cloud.google.com/container-builder/docs/?hl=ja
  - Cloud StorageまたはCloud Source RepositoryにあるソースコードからDockerイメージを作成
  - 出力はContainer Registoryへ
- (参考)Container Registory
  - https://cloud.google.com/container-registry/?hl=ja
  - プライベートのコンテナイメージを保存できるレジストリ

## No.7 (本番環境トラフィックを提供するアプリケーションを...)
- プロダクションでしかテストできないので、問題が起こっても一番傷が浅い選択肢を選ぶ
- 選択肢1
  - 全アクセスが新アプリの方に行ってしまう。そもそもロールバックは緊急時の手段なので、ロールバックが計画手順に入ってるのは不適切
- 選択肢2
  - 全アクセスが新アプリの方に行ってしまう。ちょっと大げさすぎる気も。オンボードの意味が調べても分からないけど向き先を変えるぐらいの意味かな。。
- 選択肢3
  - 全アクセスが新しいアプリの方に行ってしまう。クライアントのサブセットってなんだろう。
- 選択肢4
  - 一部のアクセスのみ新アプリに行くので、様子見するには最適。問題が起きたときに戻しやすくもある。
- (参考)トラフィックの分割
  - https://cloud.google.com/appengine/docs/standard/java/splitting-traffic?hl=ja
  - AppEngineの機能。
  - トラフィックの配分比率を指定して 1 つのサービスの複数のバージョンにトラフィックを振り分ける。

## No.8 (アプリケーションのマイクロサービスの1つに...)
- 「問題が発生している間に、マシンをデバッグする必要があります」-> 問題の発生をリアルタイムで知りたい
- 選択肢1
  - 日が暮れる
- 選択肢2
  - 方法としては有効かもしれないが、設問とズレてる
- 選択肢3
  - 方法としては有効かもしれないが、設問とズレてる
- 選択肢4
  - 「特定のログ」が発生する分、ログの行数が増えるということ？いずれにせよこれでリアルタイムで問題発生を認識できる。
- (参考)Stackdriver
  - https://cloud.google.com/stackdriver/?hl=ja
  - AWSのCloudWatch + α
  - もともと単体のサービスだったのをGCPが取り込んだらしく、GCPだけでなくAWSやその他オープンソースパッケージとも統合されているとか。
  - Stackdriver Error Reporting
      - 実行中のクラウドサービスで発生したクラッシュ数をカウントして、分析と集計を実施
  - Stackdriver Trace
      - VM,コンテナ,GAEなどのレイテンシ情報を集計、可視化
  - Stackdriver Logging
      - ログ管理、分析
  - Stackdriver Debugger
      - コードの任意の位置でのアプリケーションの状態をキャプチャ
  - Stackdriver Monitoring 
      - ダッシュボード、モニタリング、アラート
      - Slackとも統合できるらしい

## No.9 (Dress4Win は将来的に Google Cloud に...)
- 問題と選択肢の意味がよくわからない。。
- (参考)Google Cloud DataProc
  - https://cloud.google.com/dataproc/?hl=ja
  - クラウドネイティブな Hadoop と Spark
  - AWSのEMR的なやつ
- (参考)Google Cloud Dataflow
  - https://cloud.google.com/dataflow/?hl=ja
  - データ変換フローを定義、実行する
  - AWSのData Pipeline的なやつ

## No.10 (Dress4Win の開発者は、Google Cloud Platform を評価...)
- GAEがマネージドサービス
- Google Cloud SDKを使うことで、プロビジョニングが自動化できる

## No.11 (下のアーキテクチャ図は、ユーザーがアップロードした...)
- 生画像はCloud Storageに入れるのが楽な気がする。GAEに送ってもデータが残らないし、作るの大変だし、コストかかるし、タグ付け処理への受渡しを頑張らなきゃだし。
- タグ付けはCloud Function, 圧縮処理はデータ変換なのでCloud Dataflowを使う
- Cloud StorageへのファイルアップロードをトリガーにCloud Functionを実行できるらしいけど、なんでPub/Subを間に入れてるんだろ。同時実行数の上限にかからないようにとか？
- (参考)Google Cloud Function
  - https://cloud.google.com/functions/?hl=ja
  - AWSのLambdaに相当
  - まだベータ版
- (参考)Google Cloud Pub/Sub
  - https://cloud.google.com/pubsub/?hl=ja
  - AWSのAmazon MQに相当？
  - 多対多の非同期メッセージ サービス

## No.12 (Dress4Win は、クラウドにデプロイされたテスト環境...)
- ペネトレーションテストは自分でしなければならない(Googleに依頼できない)
- 外部からの侵入テストなので、それに近い状況で試さねばならない
  - GCP内部にセキュリティスキャナを置くのは不適切。
  - VPNもプライベートネットワーク内でのアクセスになるので不適切。
- (参考)ペネトレーションテスト
  - https://ja.wikipedia.org/wiki/%E3%83%9A%E3%83%8D%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%86%E3%82%B9%E3%83%88
  - https://cloud.google.com/security/?hl=ja
  - ネットワークに接続されているコンピュータシステムに対し、実際に既知の技術を用いて侵入を試みること。侵入テスト。
  - Googleへ連絡する必要はない
  - テストの影響が他のユーザーのアプリケーションに及ぶことがなようにする必要がある
  
## No.13 (Dress4Winのセキュリティチームは...)
- Google Cloud Shellを使えば満たせる操作ばかり

## No.14 (マルチペタバイトのデータセットをクラウドに...)
- 「ペタバイト」「SQL」「分析」 -> BigQueryしかない
- (参考)BigQuery
  - https://cloud.google.com/bigquery/what-is-bigquery?hl=ja
  - AWSとの対応で言えばDWH繋がりでRedshiftになるらしいけど、BigQueryはフルマネージドだし速い。

## No.15 (米国中部リージョンにある本番環境 Linux 仮想マシンの...)
- スナップショットはグローバルに使えるので、コピーするだけならCloud Storageに上げる必要は無いんだけど、「コピーの管理」のために上げてるのかな。。
- (参考)イメージ VS スナップショット
  - https://www.apps-gcp.com/gce-snapshot-backup/
  - イメージはあくまでオートスケーリングのイメージテンプレート用らしく、AMIと同じように扱うのは違うかも。
  - スナップショットからのインスタンス起動は可能。
  - スナップショットは差分で保存されてくが、イメージは都度まるごと保存する。
  - スナップショットは取得したプロジェクト内でしか使えない。
  - どちらもリージョン間で共有可能

## No.16 (お客様がストレージプロダクトを...)
- IAMではバケット単位でのざっくりとした権限設定しかできないので、ACLを利用する。
- (参考)CloudStorageのIAM制御
  - https://cloud.google.com/storage/docs/access-control/iam?hl=ja

## No.17 (お客様が、会社のアプリケーションを Google Cloud Platform に移行...)
- セキュリティチームは閲覧だけでよいので、組織とプロジェクトの閲覧権限を付与
- (参考)IAMの役割
  - https://cloud.google.com/iam/docs/understanding-roles?hl=ja

## No.18 (最近のソフトウェア更新が原因となり...)
- Cloud Storageの静的データはバージョニングしておけばロールバックできる
- ローリング更新をすると引き返しやすい
- Cloud Deployment Managerは関係ない
- VMのスナップショットからの復元は、スナップショット取った後の更新が消える
- (参考)ローリング更新
  - 複数台のサーバーで稼働しているシステムの更新を1台ずつやることで無停止で行なう手法
  - GCPではこれをやってくれる機能がある！ : Managed Instance Group Updater
  - https://cloud.google.com/compute/docs/instance-groups/updating-managed-instance-groups?hl=ja

## No.19 (企業のウェブ ホスティングプラットフォーム上で...)
- green-blueデプロイモデルはロールバックしやすくするだけで減りはしないような気がするけど。。途中で引き返すのはロールバックにカウントされない？
- カナリアリリースは本番環境でやらないと意味がない。
- マイクロサービス化することで、サービス間が疎結合になってミスが減らせそう。
- (参考)green-blueデプロイ
  - http://www.publickey1.jp/blog/14/blue-green_deployment.html
  - 複数台で稼働しているシステムのデプロイ手法
  - greenバージョンのサーバーとblueバージョンのサーバーを用意して、greenとblueの割合を徐々に変えていくことで入れ替えていく
- (参考)カナリアリリース
  - https://cloudplatform-jp.googleblog.com/2017/04/how-release-canaries-can-save-your-bacon-CRE-life-lessons.html
  - カナリアリリースのコンセプトは、1913 年に生理学者の John Scott Haldane 氏が、一酸化炭素を検出するためにカゴの中の鳥を炭鉱に連れて行ったことが始まりです。かよわい鳥は人間よりもこの無臭ガスに敏感で、ガス漏れが起きているとすぐに木から落ちてしまうため、それが炭鉱員にとってその場から離れるべきサインとなるのです。

## No.20 (リードソフトウェアエンジニアは、新しいアプリケーションの...)
- 問題がよくわからないけど、複数台構成のWebシステムで、サーバー間でセッションが共有されなくても大丈夫なようにするには？ってこと？
- セッションアフィニティの話かな。
  - https://cloud.google.com/compute/docs/load-balancing/http/?hl=ja#session_affinity
  - インスタンスが正常で容量が十分ある限り、同じクライアントからのすべてのリクエストが同じ仮想マシンのインスタンスに送信される。

## あわせて読みたい
- [AWS プロフェッショナルのための Google Cloud Platform](https://cloud.google.com/docs/compare/aws/)
  - 更新日が1年以上前なので情報が古い部分があるけど、AWSとの比較で書いてくれてるので入ってきやすい。
  - ちなみに英語だけど[Azure版](https://cloud.google.com/docs/compare/azure/)もある。すごい。
- [Cloud OnAir](https://cloudplatformonline.com/onair-japan.html)
  - AWSの[オンラインセミナー](https://aws.amazon.com/jp/about-aws/events/webinars/)にあたるのかも。
  - あわせて聴きたい、になるのかな。
 
## まとめ
比較しながら見ていくと、それぞれの思想、生い立ちが垣間見えて面白いですね。
たとえばVPCについては、GCPはグローバル、AWSはリージョン毎だったりするわけですが、Googleのサービスはあまり地域性が無いのに対し、Amazonは各国内での商品販売がメインなのでこんな感じになってるのかなと思いを馳せてみたり。

需要がどれほどあるかは分かりませんが、同じ境遇の人の助けになれば幸いです！