この記事では、GCPの認定試験であるProfessional Cloud Architectの模擬試験の解説をします。
模擬試験終了後に簡易的な解説は表示されますが、もっと汎用的な関連知識を深めることを目的としています。

設問1:GCPでDataprocを利用する際のベストプラクティスに関する出題

すべての未加工データを取得する必要がある、という点をよく読みましょう。
事例を読むと、全ての車両がネットワークに接続されているわけではないので、GCPへ直接データをストリーミングすることができるのは、
ネットワークメンテナンスポート経由でダウンロードする必要があることが推測できます。
ここまでわかれば、データをHDFSに保存するかCloud Storageに保存するかの2択に絞り込めます。

HDFSとは、Hadoop Distributed File Systemのことで、Dataprocで構築できるHadoopクラスタで扱うのに適した保存方法ですが、これは誤りです。
基本的に、新しいデータをHDFSに保存するような選択肢は正解にはなりません。
なぜなら、Dataprocの大きな特徴の1つに「Cloud Storageに保存されたデータを直接扱える」という点があるからです。
その特徴があるにも関わらず、わざわざHDFSに保存をするのはストレージ容量とそのための開発工数に無駄なコストを発生させることになります。
よって、正解は 「あとで必要な時のために、gsutilを使って簡単にCloud Storageへアップロードが可能であり、いつでもDataprocなどで分析を行うことができる状態にしておく」ようなGCPの利点をアピールするものになります。

設問2:BigQueryとBigTableの違いに関する出題

BigQueryを選んでしまった人や、BigQueryとBigTableで迷った方がいると思います。
どちらでも技術的には可能ですが、ポイントは「グラフ読み込みのレイテンシを最小限に抑える」という点にあります。
BigTableがBigQueryと大きく異なる点は、読み込みと書き込みのレイテンシであることを頭に叩き込んでください。
この2つの選択肢で迷ったときには、レイテンシの低さが要求されているかどうかという点で正解へ辿りつけるはずです。
この問題でも、レイテンシを抑えるBigTableを選択するのが正解になります。

設問3:特にGCPが関係無い出題

特に追加で解説することがないので、本家模試の解説をご覧ください。

設問4:パブリッククラウド導入時の一般的なメリットに関する出題

TCOは総保有コストのことで, OpEx / CapExに関してはググってください。
GCPではストレージの容量やコンピューティングリソースなどは後から増やせるため、容量計画は確実に変更されそうです。
一方でデータセンターの拡張については考慮する必要がなくなるので、難しそうな略語の意味を知らなくても、この問題については正解できそうです。
しかし、TCOくらいは理解しておくと良いでしょう。

設問5:リアルタイムデータを扱うアーキテクチャに関する出題

かなり難しい問題だと個人的に思いますが、丁寧に要件を見ていきましょう。
やりたいことは「集計レポート生成時間の短縮」です。
今なぜそれが遅れているのかを読み解いていくと

現場から送られてきた CSV ファイルを gzip で圧縮した後、FTP 経由でファイルをアップロードし、データ ウェアハウスに配置するまでに3週間かかる

という点が原因であることが推測できます。
つまり、レポートの生成時間を短縮するためには、データをリアルタイムに送信する手段があれば良いことがわかります。
そのためには、現在1%ほどしかない車両のネットワーク接続率を大幅に高める必要があり、データの転送もメンテナンス時にまとめて(バッチ)ではなくリアルタイムに(ストリーミング)配信すれば良いことが推測できます。

GCPでは、Cloud PubSub, Dataflowの2つを用いてリアルタイムデータの処理を行う定番のアーキテクチャがあり、それを想像できるかどうかが問われていると推測できます。

設問6:コンテナの利点に関する出題

コンテナ以外の選択肢は、全てOSに対してミドルウェアの配布や構成の管理を行うものです。
これらを用いると、OSレイヤーを構築する際の冪等性はある程度担保できますが、それを複数の環境をまたいで同期を取るのは難しいです。
構築する時期によってミドルウェアのバージョンが異なってしまうかもしれませんし、時間が経つと特定のミドルウェアはもう配布されていないかもしれません。
コンテナによってOSレイヤーを仮想化することで、コンテナイメージさえあればいつでも同じサービスを起動できるので、環境をまたいでサービスを起動することが容易になります。
また、現時点ではマイクロサービスとコンテナは密接に関係することが多いので、なんとなく正解できた方もいると思います。

設問7:リアルタイムデータを扱うアーキテクチャに関する出題

ポイントは、データの量とリアルタイム性です。
大量のデータをリアルタイムにGCPに送信しようと思ったら、スケーラビリティとグローバルへのレイテンシに優れたPubSubを利用する選択肢を選びましょう。
PubSub トピックにデータを送信してしまえば、データを利用する側はそれぞれ自由なプログラミング言語やインターフェースでトピックに送信されたデータを受信することができるのも魅力的です。

設問8:大規模データの分析と長期保存に関する出題

大量の(TBを超える)ログデータを分析する、という要件にはBigQueryが適しています。
構造化されたログをBigQueryに取り込むことで、SQLでログを整形したりフィルタリングすることができ、分析にとても有用です。
次に、その大量のデータをバックアップとして長期間保存するのに適しているのは、Cloud Storageです。
Cloud Storageには大きく4つのStorage Classが存在し、アクセス頻度が短いものから順に

Storage Class アクセス頻度
Standard いつでも
Nearline 月に1回
Coldline 3ヶ月に1回
Archive 年に1回

設問9:HTTP(S)負荷分散利用時の基本に関する出題

理解すべきポイントがたくさんある良い問題です。
まず、BackendServiceとそのヘルスチェックについて説明します。

GCPでは、ヘルスチェックリクエストに失敗したインスタンスを自動的に再起動する機能があります。
ヘルスチェックリクエストはBackednService内のすべてのインスタンスに送信され、これに失敗したインスタンスにはLoadBalancerからトラフィックが流れません。
よって、問題文の挙動から、何らかの理由でヘルスチェックリクエストに失敗していると推測できますが、インスタンスに curl コマンドで送ったリクエストは成功するとも書いてあります。

ここでファイアウォールへの理解が問われます。
GCPのヘルスチェックは、ヘルスチェックの送信元IPアドレスをファイアウォールルールで明示的に許可をしなければ、そのリクエストが成功することは無く、問題文のように無限にインスタンスが再起動を繰り返します。
どのIPアドレスを許可すればよいのかは、LoadBalancerのタイプによって微妙に異なりますが、全て ドキュメント に記載があります。
以上のことから、正解はヘルスチェックリクエストを通すためのファイアウォールを作成する、となるのです。

後編はこちら