ケーススタディ回答例【TerramEarth】
GCP Professional Cloud Architect認定試験で出題されるケーススタディの回答例を作ってみました。
本記事は公式模擬試験とMahesh様の解説を元に作成しました。Mahesh様の動画はYouTubeで複数Partにわたり非常に的確な解説がされているため、非常に参考になりました
はじめに
- この記事はあくまでも回答例です。実際に試験を受ける時点では機能追加・変更があったり、試験問題中で要件が追加・変更され、最適解が変わる可能性があります。
- 各種サービスの最新情報はGCP公式ドキュメントから手に入れましょう
回答例【TerramEarth】
これは Professional Cloud Architect 認定試験で使用される可能性のあるケーススタディの例です。試験問題を補足するコンテキストを提供するためのもので、架空の会社やソリューションのコンセプトについて説明しています。
TerramEarth は鉱業および農業向け重機を製造しています。売上のおよそ 80% は鉱業向けで、残りの 20% は農業向けです。同社は現在、500 を超えるディーラーとサービス センターを 100 か国に保有しています。同社の使命は顧客の生産性を上げる製品を製造することです。
1. ソリューションのコンセプト
2,000 万台の TerramEarth の車両が稼働しており、1 秒あたり 120 項目のデータがそこで収集されます。データは車両にローカル保存され、車両の点検時にアクセスして分析できます。データはメンテナンス ポート経由でダウンロードされます。この同じポートが運転パラメータの調整にも使用できるため、現場にいながらにして新しいコンピューティング モジュールで車両をアップグレードできます。
およそ 20 万台の車両は携帯電話回線に接続されており、そこからはデータを直接収集できます。1 日 22 時間の運転時間中に毎秒 120 項目の割合でデータが収集されるため、回線に接続された車両から収集されるデータは 1 日あたり合計約 9 TB になります。
- かなりの量のデータが発生している。ビッグデータと言ってよい。
- Cloud IoT Core+Pub/Sub+Dataflow+BQとしたいところだが・・・
- 収集したデータを分析に使うのでDWHはBQの方が適しているように思えるが、BQのinsertは100,000行/秒の制限がある！
- TerramEarthは200,000台のデバイスが毎秒データを送ってくるのでBQでは受け止めきれず、BigTableにせざるを得ないと思われる(公式模試の解説より)。
- この後の要件を読んでいくと、データを一旦ストレージに溜めることになる。Pub/SubとDataflowの間にGCSを挟む可能性あり。
- 収集したデータのさらなる分析にはCloud Machine Learningなどの機械学習の利用を検討する。
2. 既存の技術的環境
TerramEarth の既存のアーキテクチャを構成するのは、米国の西海岸に拠点を置くデータセンターにある Linux ベースのシステムと Windows ベースのシステムです。このシステムは現場から送られてきた CSV ファイルを gzip で圧縮した後、FTP 経由でファイルをアップロードし、データ ウェアハウスに配置します。この処理には時間がかかるため、集計レポートに使用されるのは 3 週間前のデータです。
このデータがあるため、TerramEarth は交換部品の在庫をあらかじめ確保し、車両の計画外停止時間を 60% 削減できています。しかしデータが古いため、交換部品が入るまで最長で 4 週間も車両が使えない顧客もいます。
3. ビジネス要件
車両の計画外停止時間を 1 週間未満に短縮する。
自社製品の使われ方に関してさらに多くのデータをディーラー網に提供し、新しい製品やサービスをより適切に提案できるようにする。
急成長を続ける農業ビジネスでの種子供給業者や肥料供給業者を中心にさまざまな企業と提携し、魅力的な製品やサービスを共同で顧客に提供できるようになる。
- 提案にMLモデルの利用を検討する。
- Cloud Endpointsなどによって外部連携用APIを公開する。
4. 技術的要件
単一のデータセンターでの管理にとどまらず、アメリカの中西部と東海岸へのレイテンシを短縮する。
バックアップ戦略を策定する。
機器からデータセンターへのデータ転送のセキュリティを向上させる。
データ ウェアハウス内のデータ品質を向上させる。
お客様のデータと機器のデータを使用して、お客様のニーズを予測する。
- us-west, us-eastにリソースをロケートする。
- GCSでDR用のストレージを構成する。
- セキュリティ向上のためにCMSKを使ってもよいが、特にマストではない。
- データ品質のためにDWH上のデータをBQやDataflowなどで加工することを検討する。
- 顧客・機器データを使ったMLモデルを構築し、予測に役立てる。
5. アプリケーション 1: データの取り込み
カスタム Python アプリケーションでは、アップロードされたデータファイルを単一のサーバーから読み取り、データ ウェアハウスに書き込みます。
コンピューティング:
- Windows Server 2008 R2
-
16 基の CPU
-
128 GB の RAM
-
10 TB のローカル HDD ストレージ
-
Cloud IoT Coreでデータを収集、Pub/Subを経由してGCSに溜める。
-
データ処理は2案ある。
-
GCS+GCE+BigTable: GCEにサービスアカウントを設定。BigTableを読めるようにしておく。
-
GCS+Dataflow+BQ: サーバレスにできるのでメリットがありそうだが、Dataflowのコストが気になるところ。
6. アプリケーション 2: レポート
ビジネス アナリストが日次レポートを行い、修理が必要な機器を確認するために既製のアプリケーションを使用しています。10 人（5 人が西海岸、5 人が東海岸）のチームのうち、2 人のアナリストだけがレポート アプリケーションに同時に接続できます。
コンピューティング
- 既製のアプリケーション。物理的な CPU の数に関連付けられたライセンス
- Windows Server 2008 R2
- 16 基の CPU
- 32 GB の RAM
- 500 GB の HDD
データ ウェアハウス
-
単一の PostgreSQL サーバー
-
RedHat Linux
-
64 基の CPU
-
128 GB の RAM
-
4 台の 6 TB の HDD（RAID 0）
-
DWHは移行しなくてもよい。もしくはDatastudio。
-
PostgreSQLはBigTable(かBQ)に移行。
7. エグゼクティブの声明
当社は競合他社よりも低コストでより良い車両を作ることができるため、これまでずっと製造のプロセスで競争力を維持してきました。しかし、さまざまな手法を取り入れた新しい製品が絶えず開発されており、当社には業界の次なる変革の波に乗るスキルが欠落していることが懸念材料です。私の目標は、自社のスキルを磨くと同時に、徐々にイノベーションを進めて目の前にある市場のニーズに対応することです。