この記事では、GCP の認定試験であるProfessional Cloud Architectの模擬試験の解説をします。 模擬試験終了後に簡易的な解説は表示されますが、もっと汎用的な関連知識を深めることを目的としています。目次 Toggle設問1: GCP でDataprocを利用する際のベストプラクティスに関する出題設問2: BigQuery とBigTableの違いに関する出題設問3:特に GCP が関係無い出題設問4:パブリッククラウド導入時の一般的なメリットに関する出題設問5:リアルタイムデータを扱うアーキテクチャに関する出題設問6:コンテナの利点に関する出題設問7:リアルタイムデータを扱うアーキテクチャに関する出題設問8:大規模データの分析と長期保存に関する出題設問9:HTTP(S)負荷分散利用時の基本に関する出題設問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が存在し、アクセス頻度が短いものから順にアクセス頻度StandardいつでもNearline月に1回Coldline3ヶ月に1回Archive年に1回設問9:HTTP(S)負荷分散利用時の基本に関する出題理解すべきポイントがたくさんある良い問題です。 まず、BackendServiceとそのヘルスチェックについて説明します。GCP では、ヘルスチェックリクエストに失敗したインスタンスを自動的に再起動する機能があります。 ヘルスチェックリクエストはBackednService内のすべてのインスタンスに送信され、これに失敗したインスタンスにはLoadBalancerからトラフィックが流れません。 よって、問題文の挙動から、何らかの理由でヘルスチェックリクエストに失敗していると推測できますが、インスタンスに curl コマンドで送ったリクエストは成功するとも書いてあります。ここでファイアウォールへの理解が問われます。 GCP のヘルスチェックは、ヘルスチェックの送信元IPアドレスをファイアウォールルールで明示的に許可をしなければ、そのリクエストが成功することは無く、問題文のように無限にインスタンスが再起動を繰り返します。 どのIPアドレスを許可すればよいのかは、LoadBalancerのタイプによって微妙に異なりますが、全て ドキュメント に記載があります。 以上のことから、正解はヘルスチェックリクエストを通すためのファイアウォールを作成する、となるのです。後編はこちら