ケーススタディ回答例【Dress4Win】
GCP Professional Cloud Architect認定試験で出題されるケーススタディの回答例を作ってみました。
本記事は公式模擬試験とMahesh様の解説を元に作成しました。Mahesh様の動画はYouTubeで複数Partにわたり非常に的確な解説がされているため、非常に参考になりました
はじめに
- この記事はあくまでも回答例です。実際に試験を受ける時点では機能追加・変更があったり、試験問題中で要件が追加・変更され、最適解が変わる可能性があります。
- 各種サービスの最新情報はGCP公式ドキュメントから手に入れましょう
回答例【Dress4Win】
これは Professional Cloud Architect 認定試験で使用される可能性のあるケーススタディの例です。試験問題を補足するコンテキストを提供するためのもので、架空の会社やソリューションのコンセプトについて説明しています。
Dress4Win はインターネットをベースとした会社です。Dress4Win のユーザーは、ウェブアプリやモバイルアプリを使って自分のワードローブの整理や管理を行えます。この会社は、ユーザーとデザイナーや販売店との橋渡しとなるアクティブなソーシャル ネットワーク サービスにも乗り出しています。Dress4Win のサービスの収益源は、広告、e コマース、紹介、フリーミアム アプリ モデルです。Dress4Win の事業は、創設者の自宅に設置された数台のサーバーによる運営から、コロケーション型データセンター内の数百台ものサーバーやアプライアンスを利用する規模にまで拡大しました。しかし、既存のインフラストラクチャの性能ではアプリケーションの急速な拡大に十分に対応できないのが現状です。ビジネスの拡大に対応し、イノベーションを加速したいと考えている Dress4Win は、パブリック クラウドへの完全な移行を予定しています。
- GCPにDev, Test, DRプロジェクトを作り、IAMで権限制御する。
- DRにはCloud VPNで接続し、障害時にスイッチできる仕組みを作る(後述)。
- 典型的なリフト&シフト方式。一部アプリケーションを再構築する。
1. ソリューションのコンセプト
Dress4Win はクラウドへの移行の第 1 段階として、開発環境とテスト環境を移行しようと考えています。また、現在のインフラストラクチャは 1 つのロケーションに集約されていることから、障害復旧サイトも構築します。ただし、既存アーキテクチャのコンポーネントのうち、現状のまま移行できるものと移行前に変更が必要なものの切り分けはまだできていません。
2. 既存の技術的環境
Dress4Win のアプリケーションは 1 か所のデータセンターから提供されています。サーバーの OS はすべて Ubuntu LTS v16.04 です。
- GCEにUbuntu LTS v16.04のVMがあるので、GCEへの単純移行は可能。
- 単純移行ではなく、マネージドサービスに移行できるものがあるか、順番に精査していこう。
データベース:
-
MySQL。ユーザーデータ、インベントリ、静的データのための 1 台のサーバー
-
MySQL 5.7
-
8 コアの CPU
-
128 GB の RAM
-
2 台の 5 TB HDD（RAID 1）
-
データベースサーバをCloud SQLへ移行する。ただし、Cloud SQLで同じメモリ, CPUの組み合わせはないので若干スペックアップorダウンすることになる。HDDはCloud SQLの上限である10TBに収まっているのでOK。
コンピューティング:
- マイクロサービス ベースの API と静的コンテンツを提供する 40 台のウェブ アプリケーション サーバー
-
Tomcat - Java
-
Nginx
-
4 コアの CPU
-
32 GB の RAM
-
WEBAPサーバはGCEのManaged Instance Group(MIG)を使う。
-
GAEでもよいが、JavaのバージョンによってはGAEに対応していない可能性がある。
- 20 台の Apache Hadoop / Spark サーバー:
-
データ分析
-
リアルタイムのトレンド計算
-
8 コアの CPU
-
128 GB の RAM
-
4 台の 5 TB HDD（RAID 1）
-
Dataprocへ移行する。
- メッセージング、ソーシャル通知、イベント用の 3 台の RabbitMQ サーバー:
-
8 コアの CPU
-
32 GB の RAM
-
Pub/Subへ移行する。
- 汎用サーバー:
-
Jenkins、モニタリング、踏み台インスタンス、セキュリティ スキャナ
-
8 コアの CPU
-
32 GB の RAM
-
Jenkins: GCEでリホストする。Cloud Buildよりも、オンプレ/GCP両方で使えるJenkinsサーバをGCEに立てる方がよい。JenkinsはMarketplaceにあるVMを使うことも可能。
-
モニタリング: Cloud Monitoringを使う。
-
セキュリティ スキャナ: Cloud Security Scannerを使う。GAE, GCE, GKEを自動的にスキャンし、クロスサイト スクリプティング（XSS）、Flash インジェクション、混合コンテンツ（HTTPS 内の HTTP）、更新されていない / 安全でないライブラリという 4 種類のよくある脆弱性を検出してくれる。
ストレージ アプライアンス:
-
VM ホスト用 iSCSI
-
ファイバー チャネル SAN - MySQL データベース
-
合計 1 PB のストレージ。400 TB 使用可能
-
NAS - イメージ ストレージ、ログ、バックアップ 合計 100 TB のストレージ。35 TB 使用可能
-
VMホスト: Persistent Disk
-
MySQL用SAN: Persistent Disk複数構成(1PBのプロビジョニングは大変だが..)
-
NAS: GCS
3. ビジネス要件
本番環境を柔軟にスケールできる、信頼性と再現性の高い環境を構築する
クラウドに最適なセキュリティ ポリシーと Identity and Access Management（IAM）を定義し、それらを遵守することでセキュリティを強化する
新しいリソースを迅速にプロビジョニングし、ビジネスのアジリティとイノベーションのスピードを向上させる
アーキテクチャを分析し、クラウドでのパフォーマンス向上のために最適化する
- GCE MIGで柔軟性を確保
- IAMで権限制御。また、環境ごとにprojectを変える
- IoC化し、Deployment Managerでインフラストラクチャを管理
- Stackdriver各種サービスでアーキテクチャの分析
4.技術的要件
クラウドで非本番環境を簡単に作成する
リソースをクラウドにプロビジョニングするための自動化フレームワークを実装する
オンプレミス データセンターまたはクラウドへのアプリケーションのデプロイのための継続的なデプロイ プロセスを実装する
緊急時にクラウドへの本番環境のフェイルオーバーをサポートする
転送時も保存時もデータを暗号化する
データセンターの本番環境とクラウド環境の間を複数のプライベート接続でつなぐ
- Deployment Manager
- Jenkins
- Cloud DNS (DNSフェイルオーバーでDRに切り替える)
- GCPはデフォルトで暗号化済
- VPNを多重化する
5. エグゼクティブの声明
当社の投資家は、現在のインフラストラクチャでコストを抑えながら環境をスケールできるのか、懸念を抱いています。また、競合他社がパブリック クラウド プラットフォームを使用することで先行投資を回避し、その分を優れた機能の開発に回す可能性があることも心配しています。当社のトラフィック パターンは午前中と週末の夜に最も高くなり、それ以外の時間帯は容量の 80% がアイドル状態です。
現在、当社の資本支出は四半期予測を超えています。クラウドに移行した場合、初期の支出は増加すると思われますが、次のハードウェア買い替え時期までには移行は完了すると予想しています。パブリック クラウド戦略の今後 5 年間の総所有コスト（TCO）分析によると、コストは現行のモデルよりも 30～50% 抑えられます。