GCPIT・資格

【GCP Professional Cloud Architect認定試験】ケーススタディ回答例:TerramEarth

※この記事にはプロモーションが含まれています。
スポンサーリンク

GCP初学者
GCP初学者

GCP Professional Cloud Architectのケーススタディが読み解けない(泣)

おつまみ
おつまみ

そのお悩み解決します!

GCP Professional Cloud Architect認定資格を勉強している皆さん!

試験問題に出てくるケーススタディはもう読みましたか?

  • 分からない用語だらけで、何が書いてあるか全然わからない。
  • どのようなサービスが使用できるかよく分からない。

私の第一声です。同じように思った方も多いはず。

そこで、今回はケーススタディの1つである【TerramEarth】を構成図付きで解説します。
GCP Professional Cloud Architect認定資格を受験する方の参考になれば嬉しいです。

それではどうぞ!

本記事の対象者
  • これからGCP Professional Cloud Architect認定資格を受験予定の方
  • ケーススタディ例が読み解けなくて悩んでいる方
諸注意

ケーススタディとは

GCP Professional Cloud Architect認定試験ではケーススタディと呼ばれる、架空の会社をテーマにしたクラウド導入事例が引用されます。

このケーススタディのビジネス要件・技術要件に合わせて適切なサービスを選択する問題が出題されます。

試験中にケーススタディの内容を表示することができるため覚える必要はありませんが、事前に内容を理解しておくと、スムーズに適切なサービスを選択することができるようになりますよ!

それでは、さっそくケーススタディをみていきましょう。

ケーススタディ:TerramEarth

会社概要

TerramEarth は鉱業および農業向け重機を製造しています。同社は現在、100 か国に 500 を超えるディーラーとサービス センターを展開しています。 同社の使命は顧客の生産性を上げる製品を製造することです。

ケーススタディ: TerramEarth

会社概要からは、TerramEarth は各国にサービスを展開している製造業ということが分かりますね。

ソリューションのコンセプト

現在、200 万台の TerramEarth 社製の車両が稼働しており、同社は毎年 20% の成長率を記録しています。これらの車両は、稼働中に多数のセンサーからテレメトリー データを収集します。 フリート管理を円滑にするために、重要なデータの一部は車両からリアルタイムで送信されます。 それ以外のセンサーデータは収集・圧縮され、毎日、車両が拠点に戻ったときにアップロードされます。 各車両によって、通常、毎日 200〜500 メガバイトのデータが生成されます

ケーススタディ: TerramEarth

コンセプトからは、2種類のデータが大容量で連携されているということが分かりますね。

・テレメトリーデータ(リアルタイム)
・センターデータ(日次)

全体をまとめるとこのようになります。

既存の技術的環境

TerramEarth 社の車両データの集約と分析を行うインフラストラクチャは Google Cloud に置かれ、 世界中のクライアントにサービスを提供しています。センサーデータの量は増加しており、 2 か所の主要な製造工場から取得され、在庫管理およびロジスティクス管理のためのレガシー システムが置かれたプライベート データセンターに送信されます。このプライベート データセンターでは Google Cloud との複数のネットワーク相互接続が構成されています。ディーラーと顧客向けのウェブ フロントエンドは Google Cloud で実行され、ここから在庫管理機能と分析機能を利用できます。

ケーススタディ: TerramEarth

既存の技術的環境からは、現在どのような構成になっているかが分かります。
整理すると、このようになります。

1つずつ解説していきますね。

①GCP上では車両データの集約と分析を実施。
→リアルタイムデータがあるため、集約にはDataflow
→分析にはBigTableBigQuery

GCP初学者
GCP初学者

BigTableとBigQueryの違いがわからないよ。。

どちらを使うか悩みどころですね。
この後のビジネス要件で、「車両の誤動作を予測」というキーワードが出てきます。予測分析や機械学習分析にはBigQueryが相性が良いので、こちらを使っていそうですね。

ポイント:BigTableとBigQueryの使い分け
  • BigTableはNoSQL型のデータベース
    データの読み書きが多く、レイテンシー要件がシビアなサービスに使用されることが多い。
    (例)IoT・アドテック・フィンテック等
  • BigQueryはSQL型のデータウェアハウス
    大規模データのSQL ベース分析やレポートに使用されることが多い。
    (例)予測分析・機械学習分析等

    詳細は公式のドキュメント「Bigtable と BigQuery: その違いは何か」に記載されてます。参考にしてみてね!

②レガシーシステムでは在庫管理・ロジスティクス管理
③Google Cloudとは複数のネットワーク接続
④GCP上ではディーラーと顧客向けのウェブフロントエンドがあり、在庫管理機能と分析機能が利用可能。
→ウェブフロントエンドは、スケールの拡張を自動でおこなってくれるApp Engine
→在庫管理機能と分析機能はマイクロサービスとして、Google Kubernetes Engine(GKE)

ビジネス要件

・車両の誤動作を予測および検出し、タイムリーな修理が可能になるように、ディーラーに部品を迅速に出荷する。
・クラウドの運用コストを削減し、季節性に対処する。
・開発ワークフローのスピードと信頼性を高める。
・コードやデータのセキュリティを損なうことなく、リモートのデベロッパーの生産性を確保する。
・ディーラーとパートナー向けのカスタム API サービスを作成するデベロッパーへ提供する、 柔軟でスケーラブルなプラットフォームを構築する。

ケーススタディ: TerramEarth

ここからが今回構成を変更していく要件になります。
要件ごとに使用できるサービスを紹介していきますね。

・機械学習モデルを構築するVertexAI、オープンソースのフレームワークTensorFlowを使用して収集したデータの予測分析・機械学習分析を行うことができます。

・監視のモニタリングツールStack driverで運用コストの削減ができます。

・デベロッパーツールCloud Build/Cloud Deploy(総称してCI/CD)で開発ワークフローのスピードと信頼性を高めることができます。

・ID管理を行うCloud Identity、きめ細かいアクセス制御が行えるIAMでセキュリティを確保できます。

・APIの一元管理可能なGoogle Cloud APIでAPIプラットフォームを提供できます。

技術的要件

・運用への支障なく段階的にクラウドに移行できるように、レガシー システムに対する HTTP API アクセスのための新しい抽象レイヤを作成する。
・すべての CI / CD パイプラインを刷新し、 デベロッパーがスケーラビリティの高い環境にコンテナベースのワークロードをデプロイできるようにする。
・デベロッパーが、セキュリティとガバナンスを損なうことなくテストを実行できるようにする。
・社内およびパートナー デベロッパーのためのセルフサービス ポータルを構築し、 新しいプロジェクトの作成、データ分析ジョブのためのリソースのリクエスト、API エンドポイントの一元管理を可能にする。
・キーとシークレットの管理に、クラウドネイティブのソリューションを使用して、 ID ベースのアクセスを最適化する。
・アプリケーションとネットワークのモニタリングおよびトラブルシューティングに必要なツールを改善し、 標準化する。

ケーススタディ: TerramEarth

・API を設計、保護、分析、スケーリングすることができるApigeeでAPIアクセスを管理できます。

・ビジネス要件③,④と同じく、Cloud Build/Cloud Deploy(CI/CD)、Cloud IdentityIAMを使用します。

・セルフサービスポータルにはウェブフロントエンドと同じApp Engineを使用します。

・暗号鍵の管理ではCloud Key Managementを使用します。

・ビジネス要件②と同じく、監視のモニタリングツールStack driverでモニタリング・トラブルシューティングが行えます。

経営陣のメッセージ

当社は、お客様の立場に立ち、優れた顧客サービスと車両のダウンタイムの最小化を実現することで競争力を維持してきました。 複数のシステムを Google Cloud に移行し終えたため、現在は、トップクラスのオンラインフリート管理サービスをお客様に提供し、ディーラーのオペレーションを改善するための新たな方法を模索しています。 5 年先を見据えた戦略として、新製品のパートナーエコシステムの構築を掲げています。そのために、 パートナーによる当社データへのアクセスを可能にし、車両の自律的な運用を促進するとともに、 残りのレガシーシステムをクラウドに移行する道筋を付けたいと考えています。

ケーススタディ: TerramEarth

最後の経営陣のメッセージでは、残りのレガシーシステムをクラウドに移行すると記載されています。

そのためには2種類のデータを直接GCP上に集約する必要がありますね。

・リアルタイムデータ→Cloud IoT Core
・センサデータ→Bigtable,Cloud Storage

を使用することで、レガシーシステム内の管理をGCP上に移すことができます。

最終的には、このような構成図でまとめることができます。

まとめ:ケーススタディを把握して、合格を掴もう!

回はGCP Professional Cloud Architect認定資格のケーススタディの回答例【TerramEarth】を紹介しました。

本番試験では、ケーススタディの内容を表示することができるため覚える必要はありませんが、内容を理解しておくと、スムーズに適切なサービスを選択することができるようになりますよ。

本記事がGCP Professional Cloud Architect認定資格を受講する方の参考になれば嬉しいです。

それでは、これからも一緒に学んで、自己価値を高めていきましょう~!

最後まで、お読み頂きありがとうございました!

コメント

タイトルとURLをコピーしました