LoginSignup
52
40

More than 5 years have passed since last update.

Fusic Advent Calendar 2017Day 19fusic
@Kta-M

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

Posted at

Fusic Advent Calendar 2017 19日目担当、@Kta-Mです。
IoTのテスト用仮想デバイス作成サービスmockmockのプロダクトオーナーをしております。

以前よりAWS アドバンスドコンサルティングパートナーの認定を頂いている弊社ですが、今年はmockmockを通じてソラコム インテグレーションパートナー、GCP テクノロジーパートナー と、新たな領域に踏み出した一年でした。

で、ただいまGCPのクラウドアーキテクトの認定を取るべく、お勉強中です。
GCPの試験、AWSと違って模擬試験が無料で何度も受けられるんです！しかも正解を教えてくれる！！

ただ、さすがになぜそれが正解なのか解説まではしてくれないので、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)も一応あるけど非推奨。
  • (参考)ライフサイクル

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に移行
  • (参考)永続化ディスク

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 パイプラインプロセスが...)

No.7 (本番環境トラフィックを提供するアプリケーションを...)

  • プロダクションでしかテストできないので、問題が起こっても一番傷が浅い選択肢を選ぶ
  • 選択肢1
    • 全アクセスが新アプリの方に行ってしまう。そもそもロールバックは緊急時の手段なので、ロールバックが計画手順に入ってるのは不適切
  • 選択肢2
    • 全アクセスが新アプリの方に行ってしまう。ちょっと大げさすぎる気も。オンボードの意味が調べても分からないけど向き先を変えるぐらいの意味かな。。
  • 選択肢3
    • 全アクセスが新しいアプリの方に行ってしまう。クライアントのサブセットってなんだろう。
  • 選択肢4
    • 一部のアクセスのみ新アプリに行くので、様子見するには最適。問題が起きたときに戻しやすくもある。
  • (参考)トラフィックの分割

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 に...)

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
  • (参考)Google Cloud Pub/Sub

No.12 (Dress4Win は、クラウドにデプロイされたテスト環境...)

  • ペネトレーションテストは自分でしなければならない(Googleに依頼できない)
  • 外部からの侵入テストなので、それに近い状況で試さねばならない
    • GCP内部にセキュリティスキャナを置くのは不適切。
    • VPNもプライベートネットワーク内でのアクセスになるので不適切。
  • (参考)ペネトレーションテスト

No.13 (Dress4Winのセキュリティチームは...)

  • Google Cloud Shellを使えば満たせる操作ばかり

No.14 (マルチペタバイトのデータセットをクラウドに...)

No.15 (米国中部リージョンにある本番環境 Linux 仮想マシンの...)

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

No.16 (お客様がストレージプロダクトを...)

No.17 (お客様が、会社のアプリケーションを Google Cloud Platform に移行...)

No.18 (最近のソフトウェア更新が原因となり...)

  • Cloud Storageの静的データはバージョニングしておけばロールバックできる
  • ローリング更新をすると引き返しやすい
  • Cloud Deployment Managerは関係ない
  • VMのスナップショットからの復元は、スナップショット取った後の更新が消える
  • (参考)ローリング更新

No.19 (企業のウェブ ホスティングプラットフォーム上で...)

  • 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システムで、サーバー間でセッションが共有されなくても大丈夫なようにするには？ってこと？
  • セッションアフィニティの話かな。

あわせて読みたい

まとめ

比較しながら見ていくと、それぞれの思想、生い立ちが垣間見えて面白いですね。
たとえばVPCについては、GCPはグローバル、AWSはリージョン毎だったりするわけですが、Googleのサービスはあまり地域性が無いのに対し、Amazonは各国内での商品販売がメインなのでこんな感じになってるのかなと思いを馳せてみたり。

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

52
40
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
52
40