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

# ケーススタディ回答例【EHR Healthcare】
[GCP試験のケーススタディ](https://cloud.google.com/certification/guides/professional-cloud-architect?hl=ja)に新しく事例企業が加わっていたので
@yota-p さんのまとめにならった分析記事となります。
従来からの[Mountkirk Games](https://qiita.com/yota-p/items/3d2c7889f26d4b951176),[TerramEarth](https://qiita.com/yota-p/items/f384fe21f0702135a202) の分析に関しては @yota-p さんの記事を参照ください。(Dress4Winはスタメン落ちしたようです)

[Helicopter Racing Leagueについてはこちら](https://qiita.com/hokutoh/items/69eaa16a50c2b4140002)です。
# はじめに
- この記事はあくまでも回答例です。実際に試験を受ける時点では機能追加・変更があったり、試験問題中で要件が追加・変更され、最適解が変わる可能性があります。
- 各種サービスの最新情報は[GCP公式ドキュメント](https://cloud.google.com/docs?hl=ja)から手に入れましょう:grinning:

## 会社概要

> EHR Healthcare は、医療業界に電子カルテ ソフトウェアを提供している大手企業です。 多国籍の医療機関、病院、保険会社に Software as a Service（SaaS） ソリューションを提供しています。

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

> EHR Healthcare のビジネスは、医療業界と保険業界の急速な変化によって年々急成長を続けています。 そのため、環境をスケールさせ、障害復旧計画を調整し、 新しい継続的デプロイ機能を導入してソフトウェアをより頻繁に更新する必要が生じています。そこで、 現在のコロケーション施設を Google Cloud に置き換えることになりました。

- 課題
  - 可用性重視
⇒柔軟,迅速なスケーリング or 十分なリソース確保
  - 障害復旧
⇒要冗長構成
  - 継続的デプロイ
⇒要CI/CD

## 既存の技術的環境
> EHR のソフトウェアは現在、複数のコロケーション施設でホストされています。 それらのデータセンターのひとつで間もなくリース期間が終了します。
> 
> 顧客向けアプリケーションはウェブベースで、その多くは最近コンテナ化されており、Kubernetes クラスタのグループで実行されています。データの保存先にはリレーショナル データベースと NoSQL データベースが混在しています（MySQL、MS SQL Server、Redis、MongoDB）。
> 
> EHR は、保険会社とのファイルベースと API ベースのレガシーな統合システムをオンプレミスでいくつかホストしています。 これらのシステムは今後数年の間に置き換えられる予定です。現時点では、 これらのシステムをアップグレードしたり移行したりする計画はありません。
> 
> ユーザーの管理には Microsoft Active Directory が使用されています。 モニタリングには各種のオープンソース ツールが使用されています。 アラートはメールで送信されますが、たびたび無視されます。

- 既存技術からのGCPサービスマッピング
  - Kubernetesクラスタグループ
⇒GKE, オンプレも入ってくるのでAnthos
  - MySQL,MS SQL Server
⇒CloudSQL
  - Redis, MongoDB
⇒Datastore(FireStore), MemoryStore
  - データ移行
⇒Database Migration Service
  - ファイルベース
⇒CloudStorage
  - APIベース
⇒Apigee, API Gateway, Cloud Endpoints
  - MS AD
⇒マルチクラウドで置き換え不要な気もするが[Managed Service for Microsoft Active Directory](https://cloud.google.com/managed-microsoft-ad/docs?hl=ja)か
[Google Cloud Directory Sync](https://support.google.com/a/answer/106368?hl=ja)で取り込み？
   - モニタリング/アラート　メールはダメ
⇒CloudMonitoring


## ビジネス要件
> - 新しい保険会社のオンボーディングをできる限り迅速化する。
- ？
Anthos Config Management？
> - 顧客向けのすべてのシステムで 99.9% 以上の可用性を実現する。
- LoadBalancer, GKEによる水平スケーリング
> - システムのパフォーマンスと使用状況を一元的に可視化し、プロアクティブな対応を可能にする。
- Anthos Service Mesh, CloudMonitoring
> - 医療の動向に関する知見の提供能力を高める。
- BigQuery→Datalab / Data Studio？
> - すべてのユーザーのレイテンシを低減する。
- CloudCDN(コンテンツ),CloudLoadBalancing
> - 法令遵守を維持する。
- ？
個人情報観点だとData Loss Prevention API
漏洩防止観点だと組織ポリシー
社で決めたコンプライアンス要件に適合させるという意味でAnthos Config Management？
追記：
たぶん[これ](https://cloud-ja.googleblog.com/2014/02/google-cloud-platform-hipaa_10.html)を言わせたいのだと思うので、
[HIPAAに準拠したサービスを使用していることを確認](https://cloud.google.com/security/compliance/hipaa/?hl=en#covered-products)や
「GOOGLAとBAAサポート契約を結ぶ」あたりになってくるのだろうか。
> - インフラストラクチャ管理費用を削減する。
- ⇒CI/CDによるマンパワーコスト削減：Anthos Config Management, Container Registry, Cloud Build,
Cloud Deploy, Binary Authorization
　インフラ使用量削減：GKEによるスケーリング
> - 保険会社のデータに基づいて業界の動向を予測してレポートを生成する。
- 分析したい→Bigquery, DataStudio, Vertex AIやAutoML？

## 技術的要件
> - 保険会社への従来のインターフェースを維持し、オンプレミス システムとクラウド プロバイダの両方に接続できるようにする。
> - コンテナベースの顧客向けアプリケーションを、一貫した方法で管理できるようにする。
- Anthos, GKE, 移行にMigrate for Anthos and GKE
Anthos Config Management
AnthosでのCI/CDのまわりの構成等は[GCP公式のAnthosの記事](https://cloud.google.com/anthos#section-8)が参考になると思います。
> - オンプレミス システムと Google Cloud の間に安全かつ高速な接続を提供する。
- DedicatedInterconnect
> - 一貫性のあるロギング、ログの保持、モニタリング、アラートの機能を提供する。
- Anthos Service Mesh→CloudLogging, Cloud Monitoring
> - 複数のコンテナベース環境を維持、管理する。
> - 環境のスケーリングとプロビジョニングを動的に行う。
- CI/CD ⇒Anthos Config Management, Cloud Source, ContainerRegistry, CloudBuild, GKE
Cloud Deploy, Binary Authorization
> - 新しい保険会社からデータを取り込んで処理するためのインターフェースを作成する。
- Pub/Sub, Dataflow

## 経営陣のメッセージ
> 当社のオンプレミス戦略は長年にわたって成功を収めてきましたが、 異なるシステムを扱うチームのトレーニングや、似ているが相互に分離された環境の管理、 そしてサービス停止への対応に多くの時間と費用がかかります。こうした停止の多くは、 システムの構成ミスやトラフィックの急増に対応できないキャパシティ、 一貫性のないモニタリング手法を原因としています。そこで当社では、Google Cloud を採用して、 スケーラブルで耐障害性に優れたプラットフォームを活用したいと考えています。これにより、 複数の環境をシームレスにつなぎ、一貫性のある安定したユーザー エクスペリエンスを提供して、 今後の成長に備えることができます。

# まとめ(Case Study Analysis Template)

Google公式の[Preparing for the Professional Cloud Architect Exam](https://www.cloudskillsboost.google/course_templates/78)では「Case Study Analysis Templateにまとめるといいよ」と記載されています。
また講座にて一例を書いてくれていますのでそちらも記載しつつ、上記メモとともに記載します。


|既存環境|技術的着眼点|提案するソリューション|メモ|
|----|----|----|----|
|顧客向けのアプリケーションはWebベース。多くはKubernetesクラスタ群でコンテナ化されている。|コンピューティング<br>- コンテナ化されたアプリケーション。<br>- クラウドとオンプレミスシステムと統合して稼働させる必要がある。<br>- AutoScaling、低Latency<br>- 堅牢なロギング,監視と,アラートが必要。|- Anthos ClustersとGoogle Kubernetes Engine。<br>- Google Cloudのオペレーションスイート(Cloud MonitoringとCloud Loggingを含む)|公式の例|
|ソフトウェアは複数のコロケーション施設でホスト。 それらのデータセンターのひとつで間もなくリース期間が終了する。|データベース<br>- MySQL、MS SQL Server、Redis、MongoDBを含む複数のデータベース|- MySQL, MS SQL Server⇒CloudSQL<br>- Redis⇒MemoryStore for Redis<br>- MongoDB⇒Mongodb Atlas on Google Cloud|公式の例|
|データの可視化が行われていない|データ用途への要求<br>- 保険会社とそのデータの迅速な取り込み。<br>業界や医療のトレンドを予測するためのデータ分析<br>顧客向けデータシステムの99.9%の可用性。|- Dataflowによる一括/ストリーム処理<br>- BigQueryによるデータ格納と分析|公式の例|
|ユーザーの管理にはMicrosoft Active Directory|ActiveDirectory互換の認証方式|- Managed Service for Microsoft Active Directory<br>- もしくはGoogle Cloud Directory SyncでGoogleアカウントと同期|MS ADを使い続けSAMLによる連携でもいいと思うが、GCPのサービスを使用する方向で考える|
|モニタリングには各種のオープンソースツールを使用。アラートはメールで送信|・モニタリング手法に一貫性を持たせる。システムのパフォーマンスと使用状況を一元的に可視化し、プロアクティブな対応を可能にする。|-Anthos Service Mesh<>-StacDriver Logging/Monitoring/Alert|なぜメールが無視されるのかの理由が記載されていないが、様々なオープンソースから様々な通知が来るようになっていたのをStackDriverに一元化することによって情報の集約を試みる・・・と解釈|
|記載なし|法令遵守<br>- HIPAA遵守<br>- 個人情報の保護|- GCPのHIPAA準拠サービスの確認 / BAAサポート契約<br>- Data Loss Prevention APIによる個人情報のマスク|法令遵守が何を指すかがわからないのでHIPAA観点と個人情報観点で記載。両方とも試験に出る。|