Google Professional Cloud デベロッパーの運用と信頼性Google Professional Cloud Developer Operations and Reliability

C. アプリケーション ログ ファイルをカスタム ソースとして構成することは、Stackdriver Logging Agent をインストールした後の重要な手順です。これには、エージェントの構成ファイルでアプリケーションのログ ファイルへのパスを指定することが含まれ、エージェントはカスタム ログ ファイルの場所と解析方法を認識します。

C. Configuring the application log file as a custom source is the crucial step after installing the Stackdriver Logging Agent. This involves specifying the path to the application's log file in the agent's configuration files, so the agent knows where to find and how to parse your custom log files.

それはCです

it's C

ログを読み取るには、StackDriver でログ ソースを構成する必要があります。

We need to configure the log source in StackDriver ager to read the logs.

StackDriver エージェントをインストールした後、送信されるログの読み取り元となる新しいソースを構成する必要があります。

After installing StackDriver agent, you need to configure the new source from which to read the logs to be sent

最初にC、次にD

first C then D

APIにログ出力を許可する必要があります。
https://cloud.google.com/logging/docs/agent/ops-agent/authorization
まず B を実行し、次に C を実行します。

私はBに投票します。

API must be allowed to output logs.
https://cloud.google.com/logging/docs/agent/ops-agent/authorization
First, do B, then do C.

I vote for B.

Cが正解です

C is correct

Cが正しい

C is right

答えはCです

Answer is C

Stackdriver に送信するので、答えは C になります。

Send to Stackdriver so answer is C then

答えはCです

Answer is C

C が私の答えです。

C is my answer.

アプリケーションログがデフォルトのログディレクトリにない限り、答えはCになるはずです
https://cloud.google.com/logging/docs/agent/configuration

I think answer should be C unless your application log is in the default log directory
https://cloud.google.com/logging/docs/agent/configuration

正しい答えは次のとおりではないと思います。A) クラウド関数は監視に関するものではありませんが、監視にクラウド関数を使用するという記述を 1 つ見つけました: https://cloud.google.com/solutions/serverless-web-performance-monitoring-using-cloud-functions 。ただし、前述の記事は WEB ページのパフォーマンスに関するものであり、多くの努力が必要です。質問には監視するサービスの種類に関する情報がありません。そのため、答えは D) - 「Stackdriver Monitoring を使用してリソースを監視し、アラートを生成する」とすべきだと思います。

I don't think the correct answer is A) Cloud Functions are not about monitoring at all, but I have found one mention of using cloud functions for monitoring: https://cloud.google.com/solutions/serverless-web-performance-monitoring-using-cloud-functions . But the mentioned article is about WEB page performance and it does require a lot of efforts. The question does not have info about the kind of service to monitor, so I think the answer should be D) - "Use Stackdriver Monitoring to monitor resources and raise alerts"

これは間違いなくDです

This is D for sure

D. Stackdriver Monitoring を使用してリソースを監視し、アラートを生成します。

Stackdriver Monitoring は、Google Cloud リソースとアプリケーションにすぐに使えるカスタム モニタリング機能を提供します。これにより、特定のシステム メトリックがユーザー定義のしきい値に違反した場合に通知するアラート ポリシーを作成できます。これは、長い開発時間を必要とせずに、リソースの監視とサービスの低下に関するアラートを設定するための迅速かつ効果的な方法です。

D. Use Stackdriver Monitoring to monitor resources and raise alerts.

Stackdriver Monitoring provides out-of-the-box and custom monitoring capabilities for Google Cloud resources and applications. It allows you to create alerting policies that notify you when certain system metrics violate user-defined thresholds. This is a quick and effective way to set up alerts for resource monitoring and service degradation without the need for extensive development time.

ここでは Stackdriver Monitoring が最適なオプションです。

Stackdriver Monitoring is the best option here.

D
エラー報告はサービスの低下に関するものではなく、監視を使用してアラートを送信します。
https://cloud.google.com/error-reporting/docs/notifications

D
Error Reporting is not about service degradation, more, Error Reporting uses Monitoring to send alerts.
https://cloud.google.com/error-reporting/docs/notifications

D はモニタリングに適しています。
このサイトが提供する「正しい」答えには困惑していますが、その答えは 80% の確率で間違っています。

D is correct for monitoring.
I'm baffled by the "correct" answers given by the site, 80% of the time they are wrong.

Dが正解です

D is correct

Dが正解です

D is correct

Dが正しいです

D is right one

紛争の監視と提起には StackDriver Monitoring を使用する必要があります。

StackDriver Monitoring should be used to monitor and raising the disputes.

これは間違いなくDです

This is D for sure

ここではDが正解です。

D is correct answer here.

答えはDです

Answer is D

ハッシュ テーブルには一意の値が格納されます。

Hash Table will store unique values.

B. 特定の数値を効率的に見つけるためのハッシュ テーブル。

B. A hash table for the efficient to find a spzcific number.

B. ハッシュテーブル。ハッシュ テーブルを使用すると、データの迅速な挿入と検索が可能になります。これは、この場合、特定の口座番号の取引金額を迅速に検索し、合計に追加する場合に役立ちます。リンクされたリスト、2 次元配列、およびカンマ区切りの文字列は、この目的にはそれほど効率的ではありません。

B. A hash table. A hash table allows for fast insertion and lookup of data, which would be useful in this case for quickly looking up the transaction amount for a given account number and adding it to the total. A linked list, two-dimensional array, and comma-delimited string would not be as efficient for this purpose.

AとCは明らかに間違っています。

ハッシュ テーブルでは、単一のキー (口座番号) に複数の値 (金額) を格納することはできませんが、これはまさに必要なことです。

2 次元配列を使用して、すべてのカップルの口座金額を保存できます (タイムスタンプは役に立ちません)。
したがって、私が選んだ答えはCです。

A and C are obviously wrong.

With hash tables, you cannot store multiple values (amounts) in single key (account number), but this is exactly what you need to do.

Two dimensional array can be used to store all the couples Account-amount (timestamp is useless).
So my selected answer is C.

B が正しいです

B is correct

アカウント番号をキーとするハッシュ テーブル、タイムスタンプはこの質問には役に立たないため、安全に破棄できます。

Hash table with the account number as the key, the timestamp is useless for this question, so we can safely discard it.

この場合、ハッシュテーブルを使用する場合、キーはアカウント名+タイムスタンプである必要があるため、リンクリストの方が良いと思います

in this case, if you use hashtable, the key must be account name+ timestamp, so I think linkedlist is better

ハッシュテーブルは正しいようです - https://open4tech.com/array-vs-linked-list-vs-hash-table/

Hash Table seems right - https://open4tech.com/array-vs-linked-list-vs-hash-table/

B が正解です

B is the correct answer

Cloud Monitoring は、CPU、メモリ、ネットワーク、ディスク使用量などの幅広い指標を提供し、パフォーマンスのボトルネックやリソースの制約を特定するのに役立ちます。

Cloud Logging は主にログの収集と分析を目的としています。アプリケーションの動作に関するある程度の洞察は得られますが、Cloud Monitoring ほど包括的ではありません。

Cloud Monitoring provides a wide range of metrics, including CPU, memory, network, and disk usage, which can help identify performance bottlenecks and resource constraints.

Cloud Logging is primarily for collecting and analyzing logs. While it can provide some insights into application behavior, it's not as comprehensive as Cloud Monitoring.

最良の答えは D です。Cloud Trace を使用してパフォーマンスのボトルネックを探します。

その理由は次のとおりです。

トラブルシューティングのための Cloud Trace: Cloud Trace は、アプリケーションを介したリクエストのフローを理解するのに役立つ分散トレース ツールです。パフォーマンスのボトルネックを特定し、遅い呼び出しを特定し、潜在的な障害領域を強調表示できます。これはまさに、HipLocal が時折発生するアプリケーション障害のトラブルシューティングに必要なものです。

The best answer is D. Use Cloud Trace to look for performance bottlenecks.

Here's why:

Cloud Trace for Troubleshooting: Cloud Trace is a distributed tracing tool that helps you understand the flow of requests through your application. It can pinpoint performance bottlenecks, identify slow calls, and highlight potential areas of failure. This is exactly what HipLocal needs to troubleshoot their occasional application failures.

B. 仮想マシンに Cloud Logging エージェントをインストールします。

時折発生するアプリケーション障害のトラブルシューティングを行うために、HipLocal は、アプリケーション内で何が起こっているかについての洞察を提供する詳細なログを収集する必要があります。これを実現するための最も直接的なアプローチは、仮想マシンに Cloud Logging エージェントをインストールすることです。 Cloud Logging エージェントは、VM 上で実行されているさまざまなアプリケーションやシステム コンポーネントからログを収集します。これは、問題の診断に非常に役立ちます。

B. Install the Cloud Logging agent on the virtual machines.

To troubleshoot occasional application failures, HipLocal needs to collect detailed logs that provide insights into what's happening within their applications. Installing the Cloud Logging agent on the virtual machines is the most direct approach to achieving this. The Cloud Logging agent will collect logs from various applications and system components running on the VMs, which can be invaluable for diagnosing issues.

私ならBと一緒に行きます。

I would go with B.

Cが正解です

C is the correct answer

B.
A: いいえ。これは VM の起動に失敗した場合、または API に関係のないその他の場合に発生します。質問には、VM の障害やシナリオについては言及されていませんでした。
B: はい。
C: いいえ。モニタリング エージェントはメモリなどのメトリクスを収集するためのものです。 APIとは関係ありません。
D: いいえ。質問に API は完璧に動作するが遅いというようなことが記載されている場合、これは有効です。

B.
A: No. This is for VM boot failed or other not related to API. The question didn't mention VM failed, nor the scenario.
B: Yes.
C: No. Monitoring agent is for metrics collection, such as memory. Not related to API.
D: No. If the question stated something like the API works perfectly but slow, then this would be valid.

彼らにはログがないため、ログを調査できるようにログエージェントを追加する必要があります。 Tracr はレイテンシーの問題のためのものであり、ここでは問題ではありません。

They don't have logging so need to add logging agent so we can have logs to study. Tracr is for latency issue and it's not the issue here.

Dが正解です

D is correct

ここで私が間違っているかもしれませんが、Cloud Trace もこのユースケースには適していますね。
リファレンス - https://cloud.google.com/trace

迅速な自動問題検出
Trace は、プロジェクトからトレース データを継続的に収集して分析し、アプリケーションのパフォーマンスに対する最近の変更を自動的に特定します。これらのレイテンシの分布は、分析レポート機能を通じて利用でき、時間やバージョンごとに比較でき、アプリのレイテンシ プロファイルの大幅な変化を検出すると、Cloud Trace が自動的に警告します。

I might be wrong here, but Cloud Trace is also kind of suitable for this use case, isn't it?
Reference - https://cloud.google.com/trace

Fast, automatic issue detection
Trace continuously gathers and analyzes trace data from your project to automatically identify recent changes to your application's performance. These latency distributions, available through the Analysis Reports feature, can be compared over time or versions, and Cloud Trace will automatically alert you if it detects a significant shift in your app's latency profile.

はい、ログがないので B になるはずです

Yep they don’t have any logging so it should be B

Bも正解です。

B is correct too.

Cが正解です

C is correct answer

C. 現在の単一インスタンスの MySQL インスタンスを Cloud SQL に置き換え、高可用性を構成します。

HipLocal の復元力向上の要件を考慮し、ビジネスと技術的なニーズを考慮すると、高可用性（HA）構成を備えた Cloud SQL に移行するのが最適な選択です。 Cloud SQL は、データベースのメンテナンス、バックアップ、スケーラビリティを簡素化するフルマネージド データベース サービスです。 Cloud SQL の高可用性構成により、別のゾーンにフェイルオーバー レプリカが存在することが保証され、障害が発生した場合に自動フェイルオーバーが提供されるため、デプロイメントの復元力が向上します。

C. Replace the current single instance MySQL instance with Cloud SQL, and configure high availability.

Given HipLocal's requirements for improved resilience and considering their business and technical needs, moving to Cloud SQL with a high availability (HA) configuration is the most suitable choice. Cloud SQL is a fully managed database service that simplifies database maintenance, backups, and scalability. The high availability configuration in Cloud SQL ensures that there is a failover replica in a different zone, which provides automatic failover in case of an outage, thus improving the resilience of the deployment.

D が正解です。クラウド SQL は追加の構成なしで冗長性を提供します。

D is the correct answer a cloud sql provide redundancy without further configuration.

C が正解です。

C is correct.

Cが正解です。

C is the correct answer.

Cが正解です

C is correct

おそらく C ですが、その実装を使用したいと考えています -> B

Probabilly is C, but they want use their implementation -> B

正解はCです

Correct Answer is C

Cが正解です

C is correct

MySQL;したがって、Cloud SQL を使用してください

https://cloud.google.com/sql/docs/mysql/高可用性

答えはCです

MySQL; so use Cloud SQL

https://cloud.google.com/sql/docs/mysql/high-availability

Answer is C

C が正解です。

C is correct.

Cが正解です

C is correct

Cに投票

Vote C

https://cloud.google.com/appengine/docs/standard/python/application-security:
「Google Cloud Web Security Scanner は、App Engine アプリをクロールし、開始 URL の範囲内のすべてのリンクをたどり、できるだけ多くのユーザー入力とイベント ハンドラを実行しようとすることで脆弱性を検出します。」

https://cloud.google.com/security-command-center/docs/concepts-web-security-scanner-overview:
「Web Security Scanner のカスタム スキャンは、古いライブラリ、クロスサイト スクリプティング、混合コンテンツの使用など、アプリケーションの脆弱性の発見に関する詳細な情報を提供します。」

Cが正解です

https://cloud.google.com/appengine/docs/standard/python/application-security:
"The Google Cloud Web Security Scanner discovers vulnerabilities by crawling your App Engine app, following all that links within the scope of your starting URLs, and attempting to exercise as many user inputs and event handlers as possible."

https://cloud.google.com/security-command-center/docs/concepts-web-security-scanner-overview:
"Web Security Scanner custom scans provide granular information about application vulnerability findings, like outdated libraries, cross-site scripting, or use of mixed content"

C is correct

ここではCが正解です。

https://cloud.google.com/appengine/docs/standard/python/application-security

C is correct answer here.

https://cloud.google.com/appengine/docs/standard/python/application-security

C. Cloud Profiler を使用して、アプリケーション内のどの機能に最も長い時間がかかるかを判断します。

Cloud Profiler は、アプリケーションのパフォーマンス特性を分析して理解するのに役立つ、Google Cloud が提供するツールです。これにより、アプリケーションがどこに時間を費やしているか、どれだけの CPU とメモリを使用しているか、どの関数やメソッドが最も時間がかかっているかを確認できます。これは、ローカル開発中には明らかではないが、Compute Engine インスタンスなどの本番環境では明らかになるパフォーマンスのボトルネックを診断する必要がある場合に特に役立ちます。

C. Use Cloud Profiler to determine which functions within the application take the longest amount of time.

Cloud Profiler is a tool provided by Google Cloud that helps you analyze and understand the performance characteristics of your application. It allows you to see where the application spends its time, how much CPU and memory it uses, and which functions or methods are the most time-consuming. This is particularly useful when you need to diagnose performance bottlenecks that are not apparent during local development but become evident in a production environment, such as a Compute Engine instance.

Cが正解です

C is correct

A は不正解です。「私のマシンでは動作したが、Google Cloud では動作しない」という議論は決して有効ではありません。
B は不正解です。デバッガーのスナップショットでは、アプリケーションを単一時点でのみ確認できるからです。
C は正解です。機能ごとのレイテンシーと過去のレイテンシー情報が提供されます。
D は不正解です。D は機能しますが、多くの作業が必要であり、明確で最適な選択ではないからです。

A is incorrect because the argument “it worked on my machine” but doesn’t work on Google Cloud is never valid.
B is incorrect because Debugger snapshots only lets us review the application at a single point in time.
C is correct because it provides latency per function and historical latency information.
D is incorrect because while it works it requires a lot of work and is not the clear, optimal choice.

選択肢 C が正解です。 Cloud Profiler は、アプリケーションのパフォーマンスの問題を特定できるパフォーマンス分析ツールです。アプリケーション内のさまざまな関数の実行に費やされた時間に関する詳細な情報が提供されるため、パフォーマンスの問題の原因を特定するのに役立ちます。オプション A は、クラウド サポートにチケットを提出しても問題の診断には役立たないため、適切な解決策ではありません。オプション B は、クラウド デバッガのスナップショットは特定の時点での変数の状態に関する情報を提供しますが、さまざまな関数の実行にかかった時間に関する情報は提供しないため、適切な解決策ではありません。オプション D は、アプリケーションにロギング コマンドを追加し、Cloud Logging を使用すると、レイテンシの問題が発生した場所を特定するのに役立ちますが、さまざまな機能の実行にかかった時間に関する情報は得られないため、適切な解決策ではありません。

Option C is the correct answer. Cloud Profiler is a performance analysis tool that allows you to identify performance issues in your application. It provides detailed information about the time spent executing different functions in your application, which can help you identify the cause of the performance issue. Option A is not a good solution because filing a ticket with Cloud Support will not help you diagnose the problem. Option B is not a good solution because Cloud Debugger snapshots provide information about the state of variables at a specific point in time, but they do not provide information about the time spent executing different functions. Option D is not a good solution because adding logging commands to the application and using Cloud Logging can help you identify where the latency problem occurs, but it will not provide information about the time spent executing different functions.

Cが正解です

C is the correct answer

Cが正解です

C is correct

正解はCです

Correct is C

正解はCです

Correct answer is C

これは C である必要があります

This should be C

私にとっての解決策は A と C です。
https://cloud.google.com/trace/docs/zipkin

for me the solution is A and C:
https://cloud.google.com/trace/docs/zipkin

Zipkin としての AC は、レイテンシの問題に関するデータを収集するために使用され、SD トレースの目的は、アプリケーション コードのレイテンシをより正確に把握できるようにすることです。

AC as Zipkin is used for to gather data for latency issues and SD trace purpose is to enable us to have a better view on the application code latency

実行する必要がある 2 つの手順は次のとおりです。

B. Fluentd エージェントを使用してデータを収集します。 Fluentd は、複数のクラウド プロバイダーで実行されている API バックエンドなど、さまざまなソースからログとメトリクスを収集するための優れたツールです。ネットワーク遅延データを収集し、分析のために集中場所に送信するように構成できます。
C. Stackdriver Trace を使用してレポートを生成する。 Stackdriver Trace は、アプリケーションのパフォーマンスを理解するのに役立つ分散トレース システムです。これを使用してネットワーク遅延データを収集および分析し、ボトルネックやパフォーマンスの問題についての洞察を得ることができます。

The two steps you should take are:

B. Use Fluentd agent to gather data. Fluentd is a great tool for collecting logs and metrics from various sources, including your API backend running on multiple cloud providers. It can be configured to collect network latency data and send it to a centralized location for analysis.
C. Use Stackdriver Trace to generate reports. Stackdriver Trace is a distributed tracing system that helps you understand the performance of your applications. It can be used to collect and analyze network latency data, providing insights into bottlenecks and performance issues.

複数のクラウド プロバイダーに分散されている API のネットワーク遅延に関するレポートを生成するには、通常、トレース データを収集して分析する必要があります。

A. Zipkin コレクターを使用してデータを収集します。Zipkin は、サービス アーキテクチャにおけるレイテンシーの問題のトラブルシューティングに必要なタイミング データの収集に役立つ分散トレース システムです。 Zipkin コレクターを使用すると、API バックエンドが実行されている場所に関係なく、API バックエンドからトレース データを収集できます。このトレース データは、さまざまなサービス呼び出しの遅延についての洞察を提供します。

C. Stackdriver Trace を使用してレポートを生成する: Stackdriver Trace (Google Cloud のオペレーション スイートの一部) を使用すると、リクエストがアプリケーションを通じてどのように伝播するかを分析し、API の詳細なレイテンシ レポートを受け取ることができます。すでに Google Cloud で Stackdriver を使用している場合は、その使用を拡張して、他のクラウド プロバイダから収集されたトレース データも分析できます。

For generating reports on network latency for an API that is distributed across multiple cloud providers, you would typically need to gather trace data and then analyze it:

A. Use Zipkin collector to gather data: Zipkin is a distributed tracing system that helps gather timing data needed to troubleshoot latency problems in service architectures. You can use Zipkin collectors to gather trace data from your API backend regardless of where it's running. This trace data can provide insights into the latency of different service calls.

C. Use Stackdriver Trace to generate reports: Stackdriver Trace (part of Google Cloud’s operations suite) allows you to analyze how requests propagate through your application and receive detailed latency reports for your API. If you are already using Stackdriver on Google Cloud, you can extend its usage to analyze trace data collected from other cloud providers as well.

解決策は AC です。
https://cloud.google.com/trace/docs/zipkin

solution is AC:
https://cloud.google.com/trace/docs/zipkin

複数のクラウド プロバイダーで実行されている API のネットワーク遅延に関するレポートを生成するには、次の 2 つの手順を実行する必要があります。

A. Zipkin コレクターを使用してデータを収集します。Zipkin は、API に対して行われたリクエストのレイテンシーに関するデータの収集に役立つ分散トレース システムです。これにより、システム内を流れるリクエストを追跡でき、サービスのパフォーマンスについての洞察が得られます。 Zipkin コレクターを使用して複数のクラウド プロバイダーからデータを収集し、レポートを生成して API のレイテンシーを分析できます。

C. Stackdriver Trace を使用してレポートを生成する: Stackdriver Trace は、複数のサービスにわたるリクエストのトレースに役立ち、アプリケーションに関する詳細なパフォーマンス データを提供する分散トレース システムです。これにより、API とその依存関係のパフォーマンスを視覚化して分析できます。 Stackdriver Trace を使用すると、複数のクラウド プロバイダで実行されている API のネットワーク レイテンシに関するレポートを生成できます。

したがって、正しい選択肢は A と C です。

The two steps you should take to generate reports for the network latency of your API running on multiple cloud providers are:

A. Use Zipkin collector to gather data: Zipkin is a distributed tracing system that helps you gather data about the latency of requests made to your API. It allows you to trace requests as they flow through your system, and provides insight into the performance of your services. You can use Zipkin collectors to collect data from multiple cloud providers, and then generate reports to analyze the latency of your API.

C. Use Stackdriver Trace to generate reports: Stackdriver Trace is a distributed tracing system that helps you trace requests across multiple services and provides detailed performance data about your applications. It allows you to visualize and analyze the performance of your API and its dependencies. You can use Stackdriver Trace to generate reports about the network latency of your API running on multiple cloud providers.

Therefore, the correct options are A and C.

正解は次のとおりです。A. Zipkin コレクターを使用してデータを収集し、C. Stackdriver Trace を使用してレポートを生成します。

Zipkin コレクターを使用すると、複数のクラウド プロバイダーで実行されているインストルメント化されたアプリケーションからデータを収集できます。 Stackdriver Trace を使用して、このデータに基づいてレポートを生成できます。

Fluentd エージェントを使用するオプション B は、API のネットワーク遅延に関するレポートの生成には関係しません。

オプション D は Stackdriver Debugger を使用し、API のネットワーク レイテンシに関するレポートの生成には関係しません。

Stackdriver Profiler を使用するオプション E は、API のネットワーク レイテンシに関するレポートの生成には関係ありません。

The correct answer would be: A. Use Zipkin collector to gather data and C. Use Stackdriver Trace to generate reports.

Using Zipkin collector will allow you to gather data from your instrumented application running on multiple cloud providers. Stackdriver Trace can then be used to generate reports based on this data.

Option B, using Fluentd agent, is not related to generating reports on network latency for an API.

Option D, using Stackdriver Debugger, is not related to generating reports on network latency for an API.

Option E, using Stackdriver Profiler, is not related to generating reports on network latency for an API.

BDは正しい

BD are correct

https://cloud.google.com/trace/docs/zipkin#frequently_asked_questions
Zipkin サーバーを使用して Zipkin クライアントからトレースを受信し、それらのトレースを分析のために Cloud Trace に転送します。

https://cloud.google.com/trace/docs/zipkin#frequently_asked_questions
use a Zipkin server to receive traces from Zipkin clients and forward those traces to Cloud Trace for analysis.

CE。 E はレイテンシー Cloud Profiler を表します。トレースには zipkin も使用できますが、より良いトレースが可能です

CE. E for latency Cloud Profiler. For tracing can be use also zipkin but better tracing

AとCが正解です。

A and C are correct solution.

AC
A: 複数のクラウドプロバイダーをサポートするため
https://cloud.google.com/trace
データを Cloud Trace に送信するための Zipkin トレーサー。 App Engine で実行されているプロジェクトは自動的にキャプチャされます。

C: ネットワーク遅延のレポートを生成します。
https://cloud.google.com/trace/docs/quickstart#analysis_reports_window

AC
A: to support multiple cloud providers
https://cloud.google.com/trace
Zipkin tracers to submit data to Cloud Trace. Projects running on App Engine are automatically captured.

C: to generate reports for the network latency
https://cloud.google.com/trace/docs/quickstart#analysis_reports_window

ここでは「レイテンシ」がキーワードであるため、C が答えの 1 つになります。 Stackdriver トレース

https://cloud.google.com/trace/docs/zipkin:
「Zipkin クライアントからトレースを受信し、それらのトレースを分析のために Cloud Trace に転送します。」

Aはもう一つの答えです

"latency" is the key word here so C is one of the answers; Stackdriver Trace

https://cloud.google.com/trace/docs/zipkin:
"receive traces from Zipkin clients and forward those traces to Cloud Trace for analysis."

A is the other answer

答えはACだと思います

I think the answer is AC

プロファイラーはパフォーマンス分析に使用されるため、私にとっては C と E です。

for me it is C and E, as profiler is used for performance analysis

私はBCと一緒に行きます

I would go with BC

Collectd はエージェントの監視に使用されます
Fluentd はクラウド ロギング エージェント用です

Collectd is used for Monitoring agents
Fluentd is for cloud logging agent

Bさんに同意

Agree with B

B が正しいです

B is correct

このオプションは、Bigtable または BigQuery にデータをエクスポートする必要がないため、最も費用対効果が高くなります。また、メトリクスとログをリアルタイムで関連付けることができるため、最も効率的なオプションでもあります。

This option is the most cost-effective because it does not require you to export any data to Bigtable or BigQuery. It is also the most efficient option because it allows you to correlate the metrics and logs in real time.

Promethius メトリクスと Cloud Logging ログを相関させる: これら 2 つのログを比較する必要があります。 Promethius は、アプリケーションで使用されるライブラリの依存関係となる外部メトリクスです。 Apple と Apple を比較するには、Prometheus 指標を GCP に導入する必要があり、それらを外部指標として扱うようにクラウド モニタリングを構成する必要があります。

Correlate Promethius metrics and Cloud logging logs: We need to compare these two logs. Promethius is an external metrics which can be a library dependency used in the application. To compare Apple vs apple, we need to bring Prometheus metrics to GCP and should configure Cloud monitoring to treat them as an external metric.

このオプションを使用すると、Cloud Monitoring を使用して Prometheus 指標を表示し、ログからログベースの指標を作成できます。これにより、メトリクスとログを 1 か所で関連付けることができます。 Cloud Monitoring を使用すると、アラート ルールとダッシュボードを設定することもでき、パフォーマンスの問題をリアルタイムで低コストで特定してトラブルシューティングするのに役立ちます。
関連付けを実行したり通知を設定したりするためにデータを別のストレージにエクスポートする必要はありません。すべて Cloud Monitoring の機能を利用して直接実行できます。

This option allows you to use Cloud Monitoring to view the Prometheus metrics and create log-based metrics from the logs. This allows you to correlate the metrics and logs in one place. By using Cloud Monitoring, you can also set up alerting rules and dashboards which can help you to identify and troubleshoot the performance issues in real-time and with low costs.
It's not necessary to export the data to another storage to perform the correlation and to set up notifications, it can all be done directly in the Cloud Monitoring, taking advantage of its features.

Dは正しいです

D is correc

ここでは D が妥当な選択です。

D is a fair choice here!

正解はDです

Correct Answer is D

私も D さんの意見に同意します…コストを最小限に抑えたい = アラート機能が組み込まれた Cloud Monitoring を使用する

I agree with D as well … looking for minimizing the costs = use Cloud Monitoring which has alerting bult-in

選択肢 D に同意する

Agree with Option D

質問に「最初のもの」と記載されているため、選択肢 A に同意します

I agree with Option A, as the question states “first one”

最小限のリスク: 製品カタログは e コマース Web サイトの基礎的なコンポーネントであるため、最初に製品カタログを移行すると、リスクが最小限に抑えられます。支払いや注文処理など、収益を生み出す中核的なプロセスには直接影響しません。
独立した機能: 製品カタログは比較的独立しており、主にフロントエンドと製品データベースに統合されています。これにより、アプリケーションの他の重要な部分を中断することなく、分離と移行が容易になります。
早期検証: プロダクト カタログを移行すると、より複雑な機能に進む前に、移行プロセスを検証し、インフラストラクチャをテストし、Google Cloud の経験を積むことができます。
将来の移行のための基盤: 製品カタログの移行が成功すると、将来のより複雑な機能の移行の準備が整います。これは、Google Cloud 上でマイクロサービス アーキテクチャを構築するための強固な基盤を提供します。

Minimal Risk: Migrating the product catalog first minimizes risk because it's a foundational component of your ecommerce website. It doesn't directly impact the core revenue-generating processes like payment or order fulfillment.
Independent Functionality: The product catalog is relatively independent, with integrations primarily to the frontend and product database. This makes it easier to isolate and migrate without disrupting other critical parts of the application.
Early Validation: Migrating the product catalog allows you to validate your migration process, test your infrastructure, and gain experience with Google Cloud before moving on to more complex functionalities.
Foundation for Future Migrations: A successful product catalog migration sets the stage for future migrations of more complex features. It provides a solid foundation for building out your microservices architecture on Google Cloud.

依存関係が少ないので、A を使用します。

I will go with A as it has less dependencies.

A はリストの最初の MVP 項目である必要があります。
重要なのは、移行の初期段階でのリスクを回避することです。

A should be the first MVP item in the list.
Key is to avoid risks in the initial stages of transition.

https://cloud.google.com/architecture/migrated-a-monolithic-app-to-microservices-gke#example_migrated_a_shopping_cart

参照されているガイドに基づくと、答えは D. フロントエンド、カート データベース、在庫システム、および支払い処理システムと統合されているショッピング カートを移行します。このガイドでは、依存関係と複雑さのレベルが最も少ない機能を最初に移行することを推奨しています。ショッピング カート機能は、提示されている他のオプションよりも依存関係が少なく、複雑さが少ないものです。これにより、リスクを最小限に抑えながら、ビジネスに価値を提供し、より複雑な機能のさらなる移行が可能になります。

https://cloud.google.com/architecture/migrating-a-monolithic-app-to-microservices-gke#example_migrating_a_shopping_cart

Based on the guide referenced, the answer would be D. Migrate the Shopping cart, which has integrations to the frontend, cart database, inventory system, and payment processing system. The guide recommends migrating functionality with the least dependencies and level of complexity first, which the shopping cart functionality has fewer dependencies and less complexity than the other options presented. This will minimize risk while still providing value to the business and allowing further migration of more complex functionality.

https://cloud.google.com/architecture/migrated-a-monolithic-app-to-microservices-gke#example_migrated_a_shopping_cart
答えA

https://cloud.google.com/architecture/migrating-a-monolithic-app-to-microservices-gke#example_migrating_a_shopping_cart
Answer A

Aが正しいです

A is correct

A が正解です。

A is correct.

私は C に投票します。これは、一時的な中断が Web サイト上のすべての売上に影響を及ぼさない唯一のサービスです (フロントエンドに埋め込まれていないため)。

I will vote C. It is the only service where a temporary disruption will not impact all sales on the website (because it is not embedded in the frontend).

オプション A に同意します。最小限の機能を移行することで中断を最小限に抑えるためです。

Agree Option A , in order to keep the disruption as minimum as possible by migrating minimum features

はい、Aに投票します

Yes, I vote A

彼はアプリケーションのすべてではなく、「一部」のみを GCP に移行しました。

He migrated only 'some' of applications, not all of them to GCP.

既存のインフラストラクチャの活用: このアプローチでは、すでに投資している既存のモニタリング プラットフォームを活用できます。それを捨てるのではなく、Google Cloud の強力なモニタリング サービスとロギング サービスと統合します。
仕組み:
Cloud Logging と Monitoring: Cloud Logging を使用してクラウド アプリケーションからログを収集し、Cloud Monitoring を使用して指標をモニタリングします。
アラート: ログと指標の事前定義されたしきい値またはパターンに基づいてアラートを送信するように Cloud Monitoring を構成します。
統合: これらのアラートを Cloud Monitoring から既存のオンプレミス モニタリング プラットフォームに転送するメカニズムをセットアップします。これには、Webhook、メッセージ キュー、またはその他の統合方法の使用が含まれる場合があります。

Leverage Existing Infrastructure: This approach allows you to take advantage of the existing monitoring platform you've already invested in. You're not throwing it away, but rather integrating it with Google Cloud's powerful monitoring and logging services.
How it works:
Cloud Logging and Monitoring: Use Cloud Logging to collect logs from your cloud applications and Cloud Monitoring to monitor metrics.
Alerting: Configure Cloud Monitoring to send alerts based on predefined thresholds or patterns in your logs and metrics.
Integration: Set up a mechanism to forward these alerts from Cloud Monitoring to your existing on-premises monitoring platform. This could involve using a webhook, a message queue, or other integration methods.

Dさんと一緒に行きます。

I will go with D.

D. Cloud Logging と Cloud Monitoring を使用してログを取得し、モニタリングし、アラートを送信します。それらを既存のプラットフォームに送信します。
オンプレミスの監視プラットフォームをクラウド監視プラットフォームと統合することを目的としている場合、これは有効なオプションです。これにより、すべてのアプリケーションのパフォーマンスを総合的に把握できます。

また、Google Cloud の Stackdriver サービスを使用して、オンプレミスとクラウドの両方でモニタリング、ロギング、トレースを統合することもできます。 Stackdriver を使用すると、すべてのアプリケーションのパフォーマンスを統合して表示し、問題の根本原因を追跡できます。

D. Use Cloud Logging and Cloud Monitoring to capture logs, monitor, and send alerts. Send them to your existing platform.
is a valid option if your aim to integrate the on-premise monitoring platform with the cloud monitoring platform, this way you can have a holistic view of all your application performance.

You can also use Google Cloud's Stackdriver service to integrate the monitoring, logging and tracing across both on-premise and cloud. Stackdriver can be used to get unified view of all your application performance and trace the root cause of an issue.

Dが正解です

D is correct

Dに投票

Vote D

私はAに投票します

I vote for A

選択肢 D に同意する

Agree with Option D

私はBに投票します
https://cloud.google.com/architecture/distributed-load-testing-using-gke

I vote B
https://cloud.google.com/architecture/distributed-load-testing-using-gke

B が正しいです。

B is correct.