ケーススタディ
会社概要
HipLocal は、近くにいる人々の間のコミュニケーションを促進するように設計されたコミュニティ アプリケーションです。スポーツイベントの企画や開催、企業が地域社会とつながるために利用されています。HipLocal は最近ダラスのいくつかの地域でサービスを開始し、急速に世界的な現象に成長しています。ハイパーローカルなコミュニティコミュニケーションとビジネスアウトリーチのユニークなスタイルは、世界中で需要があります。
エグゼクティブステートメント
私たちはナンバーワンのローカルコミュニティアプリです。地域コミュニティ サービスをグローバルに展開する時が来ています。私たちのベンチャー キャピタルの投資家は、メンバーが互いに 10 マイルまたは 10,000 マイル離れていても、急速な成長と、オンラインになる新しいローカル コミュニティや仮想コミュニティに同様の素晴らしい体験を提供したいと考えています。
ソリューションコンセプト
HipLocal は、世界中の顧客により良いサービスを提供するために、最新の機能を備えた既存のサービスを新しい地域で拡張したいと考えています。彼らは、これらの地域をタイムゾーンでサポートするための新しいチームを雇用してトレーニングしたいと考えています。アプリケーションがスムーズに拡張され、明確な稼働時間データが提供されることを確認する必要があります。
既存の技術環境
HipLocal の環境は、オンプレミスのハードウェアと Google Cloud Platform で実行されるインフラストラクチャが混在しています。
HipLocal チームはアプリケーションをよく理解していますが、世界規模のアプリケーションの経験は限られています。
現在の技術環境は次のとおりです。
* 既存の API は、GCP でホストされている Compute Engine 仮想マシン インスタンス上で実行されます。
* 状態は GCP の単一インスタンスの MySQL データベースに保存されます。
* データはオンプレミスの Teradata/Vertica データ ウェアハウスにエクスポートされます。
* データ分析はオンプレミスの Hadoop 環境で実行されます。
※アプリケーションにはログ機能がありません。
* 稼働時間の基本的な指標があります。API が応答しない場合、アラートが頻繁に発生します。
ビジネス要件
HipLocal の投資家は、その拠点を拡大し、見られる需要の増加をサポートしたいと考えています。彼らの要件は次のとおりです。
* アプリケーションの利用可能性を新しい地域に拡大します。
* サポートできる同時ユーザー数を増やします。
* ユーザーが異なる地域に旅行する場合でも、一貫したエクスペリエンスを確保します。
* ユーザーのアクティビティ指標を取得して、製品を収益化する方法をより深く理解します。
* 新しい地域の規制 (GDPR など) への準拠を確保します。
* インフラストラクチャ管理の時間とコストを削減します。
* Google が推奨するクラウド コンピューティングのプラクティスを採用します。
技術的要件
* アプリケーションとバックエンドは、使用状況のメトリクスとモニタリングを提供する必要があります。
* API には強力な認証と承認が必要です。
* ログ記録を増やし、データをクラウド分析プラットフォームに保存する必要があります。
* 柔軟なスケーリングを容易にするためにサーバーレス アーキテクチャに移行します。
* 安全な方法で内部アプリへの承認されたアクセスを提供します。
HipLocal は、オンコール エンジニアの数を減らし、手動によるスケーリングを排除したいと考えています。
どの 2 つのサービスを選択すべきでしょうか? (2つお選びください。)

実稼働環境にデプロイされたアプリケーションがあります。新しいバージョンがデプロイされると、アプリケーションが運用環境のユーザーからトラフィックを受信するまで、いくつかの問題は発生しません。影響と影響を受けるユーザーの数の両方を削減したいと考えています。
どの導入戦略を使用する必要がありますか?

あなたの会社は、新しい API を Compute Engine インスタンスにデプロイしました。テスト中、API は期待どおりに動作しません。アプリケーションを 12 時間以上監視して、アプリケーションを再デプロイせずにアプリケーション コード内の問題を診断したいと考えています。どのツールを使用する必要がありますか?

アプリケーションは Google Kubernetes Engine (GKE) クラスターにデプロイされます。アプリケーションの新しいバージョンがリリースされると、CI/CD ツールは spec.template.spec.containers[0].image 値を更新して、新しいアプリケーション バージョンの Docker イメージを参照します。デプロイメント オブジェクトが変更を適用するときは、新しいバージョンのレプリカを少なくとも 1 つデプロイし、新しいレプリカが正常になるまで以前のレプリカを維持する必要があります。
以下に示す GKE Deployment オブジェクトにどの変更を加える必要がありますか?

あなたは、コンテナファーストのアプローチを採用する金融サービス会社で働いています。チームがマイクロサービス アプリケーションを開発している コンテナ イメージを作成し、回帰テストを実行し、そのイメージを Artifact Registry に公開する Cloud Build パイプラインがある 回帰テストに合格したコンテナのみが Google Kubernetes Engine (GKE) にデプロイされるようにする必要があるクラスタ GKE クラスタでは Binary Authorization がすでに有効になっています。次に何をする必要がありますか?