この記事の目的
Clouds StarterがKindle・Udemyにてしている問題集の一部を公開します。
この記事の問題を解くことで、本番レベルの問題に慣れるだけでなく、どういった観点が本番で問われるかを確認することができます。
本シリーズのリンク
Part7：https://qiita.com/clouds-starter/items/5373f85685c621fbe548
Part9：https://qiita.com/clouds-starter/items/c6b51f967033ecb7d84b
問題集（Udemy・Kindle）
Udemy
【Google Cloud】
Associate Cloud Engineer：https://www.udemy.com/course/google-cloud-associate-cloud-engineer-z/?referralCode=6F46C7AAC19A25BE1728
Professional Cloud Architect：https://www.udemy.com/course/google-cloud-professional-cloud-architect-i/?referralCode=2533A3214C4439F57A42
Professional Data Engineer：https://www.udemy.com/course/google-cloud-professional-data-engineer-s/?referralCode=B50B6D7F8849CCCF6B6E
【AWS】
Cloud Practitioner：https://www.udemy.com/course/2022aws-10-650/?referralCode=6B63C1D36EA602B66A02
Machine Learning：https://www.udemy.com/course/aws-30-b/?referralCode=62C2C02B9127E6DFE9F6
Kindle
Google Cloud認定Professional Cloud Architect：https://amzn.to/3GQw2XT
Google Cloud認定Professional Data Engineer：https://amzn.to/339Az9Z
その他問題集：
https://amzn.to/34LKAu9
##問題（#22~#24)
####Q22：
あなたの会社は、外部ユーザーがファイルをアップロードして共有できるように、モノリシックな3層のアプリケーションを開発しました。このソリューションは簡単には拡張できず、信頼性にも欠けています。開発チームは、マイクロサービスと完全なマネージドサービスのアプローチを採用するために、アプリケーションを再構築したいと考えていますが、その努力が価値あるものであることをリーダーに納得させる必要があります。
どのような利点をリーダーに強調すべきでしょうか？
A. 新しいアプローチでは、コストが大幅に削減され、基礎となるインフラの管理が容易になり、CI/CDパイプラインを自動的に管理できるようになります。
B. モノリシックなソリューションは、Dockerを使ってコンテナに変換することができます。生成されたコンテナは、Kubernetesクラスターにデプロイすることができます。
C. 新しいアプローチでは、インフラストラクチャとアプリケーションの切り離し、新機能の開発とリリース、基盤となるインフラストラクチャの管理、CI/CDパイプラインの管理とA/Bテストの実行、そして必要に応じたソリューションの拡張が容易になります。
D. このプロセスは、Migrate for Compute Engineで自動化できます。
#####解説：
Google Cloudの公式な見解として、マイクロサービスに移行する理由は以下のように要約されます。
アプリケーションをマイクロサービスに分割すると、次のような利点があります。その多くはマイクロサービスが疎結合であることに起因しています。
- マイクロサービスは個別にテストしてデプロイできます。デプロイ単位が小さいほど、デプロイが容易になります。
- 異なる言語やフレームワークで実装できます。マイクロサービスごとに、ユースケースに最適なテクノロジーを自由に選択できます。
- 異なるチームで管理できます。マイクロサービス間の境界により、1 つのチームが 1 つまたは複数のマイクロサービスを簡単に管理できます。
- マイクロサービスに移行すると、チーム間の依存関係が緩和されます。各チームは、依存しているマイクロサービスの API のみを考慮し、マイクロサービスの実装方法やリリース サイクルなどについて考える必要はありません。
- 障害に対する設計が簡単になります。サービス間に明確な境界があるので、サービスが停止した場合の対処方法を決定しやすくなります。
モノリシックなシステムと比較した場合、マイクロサービスには次のような欠点があります。
- マイクロサービス ベースのアプリを構成するサービスの相互関係が明確でない場合が多く、システム全体の複雑さは増大する傾向があります。
- モノリシックなシステムの内部と異なり、マイクロサービスはネットワークを介して通信を行うため、セキュリティ上の問題が発生することがあります。この問題を解決するため、Istio はマイクロサービス間のトラフィックを自動的に暗号化しています。
- サービス間のレイテンシのため、モノリシック アプローチと同じレベルのパフォーマンスを実現するのが困難な場合があります。
- システムの動作は、単一のサービスに起因するのではなく、多くのシステムとシステム間のやり取りによって引き起こされます。このため、本番環境でのシステムの動作を把握することは難しくなります（可観測性が低くなります）。Istio は、この問題の解決策となります。
したがって正解は以下の通りです。
「新しいアプローチでは、インフラストラクチャとアプリケーションの切り離し、新機能の開発とリリース、基盤となるインフラストラクチャの管理、CI/CDパイプラインの管理とA/Bテストの実行、そして必要に応じたソリューションの拡張が容易になります。」
#####参照：
https://cloud.google.com/architecture/migrating-a-monolithic-app-to-microservices-gke
#####正解： C
####Q23：
アップデートが必要なApp Engineアプリケーションがあります。現在のアプリケーションのバージョンを置き換える前に、本番トラフィックでアップデートをテストしたいと考えています。
どのようにすればよいでしょうか？
A. Instance Group Updater を使用してアップデートを展開し、部分的なロールアウトを作成することで、カナリアテストを行うことができます。
B. App Engine アプリケーションに新しいバージョンとしてアップデートを展開し、新しいバージョンと現在のバージョンでトラフィックを分割する。
C. 新しいVPCにアップデートを配置し、Google'のグローバルHTTPロードバランシングを使用して、アップデートと現行のアプリケーションの間でトラフィックを分割する。
D. 新しいApp Engineアプリケーションとしてアップデートを配置し、Google'のグローバルHTTPロードバランシングを使用して、新しいアプリケーションと現在のアプリケーションの間でトラフィックを分割する。
#####解説：
App Engine上でトラフィック分割を行う方法を選択する必要があります。
トラフィックの分割は、App EngineのA/Bテスト用の機能として存在するため、この機能を使用することが適切です。
トラフィック分割機能を使用すると、トラフィックの配分比率を指定して同じサービスの複数のバージョンにトラフィックを振り分けることができます。
トラフィックの分割により、バージョン間で A/B テストを実行することが可能になり、機能をデプロイする際のペースを制御できます。
したがって正解は以下の通りです。
「App Engine アプリケーションに新しいバージョンとしてアップデートを展開し、新しいバージョンと現在のバージョンでトラフィックを分割する」
#####参照：
https://cloud.google.com/appengine/docs/standard/python/splitting-traffic
#####正解： B
####Q24：
GCP上にMicrosoft SQL Serverをセットアップする必要があります。経営陣は、GCPリージョン内のいずれかのゾーンでデータセンターが停止した場合に、ダウンタイムが発生しないようにすることを要求しています。
要件を達成するためにするべきことは何ですか？
A. 高可用性を有効にして、Cloud SQLインスタンスを構成する。
B. Cloud Spannerインスタンスをリージョン別インスタンス構成で構成する。
C. Windows Failover Clusteringを使用したAlways On Availability Groupsを使用して、Compute Engine上でSQL Serverを設定する。ノードを異なるサブネットに配置する。
D. Windows Failover Clusteringを使用してSQL ServerのAlways On Availability Groupsを設定する。ノードを異なるゾーンに配置する。
#####解説：
高可用性（HA）構成の目的は、ゾーンまたはインスタンスが利用できなくなったときのダウンタイムの削減です。
これは、ゾーンでサービスが停止した場合や、インスタンスが破損した場合に発生することがあります。
HA を使用すれば、クライアント アプリケーションで引き続きデータを使用できるようになります。
HA 構成は「クラスタ」とも呼ばれ、データの冗長性を確保します。
HA 向けに構成された Cloud SQL インスタンスは「リージョン インスタンス」とも呼ばれ、構成されたリージョン内のプライマリ ゾーンとセカンダリ ゾーンに配置されます。
したがって正解は以下の通りです。
「高可用性を有効にして、Cloud SQLインスタンスを構成する」
#####参照：
https://cloud.google.com/sql/docs/sqlserver/high-availability
https://cloud.google.com/compute/docs/instances/sql-server/configure-availability
#####正解： A