ACE#04

ACE#03 – ACE#04 – ACE#05
R – F

お疲れ様でした!ACE#04のクイズ終了しました。

解答スコアは %%SCORE%% / %%TOTAL%% 問正解です。

%%RATING%%


あなたの選択した答えは強調表示されています。
問題1
毎晩実行されるバッチワークロードでは、多数の仮想マシン (VM) が使用されています。このワークロードはフォールト トレラントで、一部の仮想マシンが終了しても問題ありません。現在の仮想マシン (VM) のコストは高すぎます。どのように対応しますか。
A
メンテナンス イベントをシミュレートしたテストを実行します。テストが成功した場合、将来のジョブを実行する際に、プリエンプティブルな N1 標準 VM を使用します。
B
マネージド インスタンス グループを使用してテストを実行します。テストが成功した場合、将来のジョブを実行する際に、マネージド インスタンス グループで N1 標準 VM を使用します。
C
メンテナンス イベントをシミュレートしたテストを実行します。テストが成功した場合、将来のジョブを実行する際に N1 標準 VM を使用します。
D
N2 の代わりに N1 標準 VM を使用してテストを実行します。テストが成功した場合、将来のジョブを実行する際に N1 標準 VM を使用します。
問題 1 の説明および補足 
プリエンプティブル VM インスタンス
重要な要件はコストを削減することであり、一部の仮想マシンが終了しても問題ないことから、プリエンプティブル VM が理想的な選択となります。

※プリエンプティブル VM インスタンス
プリエンプティブル VM は、通常のインスタンスよりはるかに低価格で作成、実行できるインスタンスです。ただし、他のタスクがリソースへのアクセスを必要とする場合、Compute Engine がこのインスタンスを停止(プリエンプト)する可能性があります。プリエンプティブル インスタンスは Compute Engine の余剰のキャパシティを利用する機能であり、使用できるかどうかは利用状況に応じて異なります。
アプリがフォールト トレラントであり、インスタンスで生じる可能性のあるプリエンプションに対応できる場合、プリエンプティブル インスタンスで Compute Engine のコストを大幅に削減できます。たとえば、バッチ処理ジョブは、プリエンプティブル インスタンス上で実行できます。これらのインスタンスのいくつかが処理中に停止する場合、ジョブは遅くなりますが、完全に停止することはありません。プリエンプティブル インスタンスは、既存のインスタンスの負荷を増やさずにバッチ処理タスクを完了し、通常インスタンスの追加に対する正規価格を支払う必要もありません。
参考URL:プリエンプティブル VM インスタンス
問題2
マネージド インスタンス グループとしてウェブアプリケーションをデプロイしています。このアプリケーションの新しいバージョンを徐々にデプロイする必要があります。ウェブアプリケーションは現在、ライブのウェブトラフィックを受信しています。デプロイ中に使用可能な容量が減少しないようにする必要があります。どのように対応しますか。
A
maxSurge を 0 に設定し、maxUnavailable を 1 に設定して、 rolling-action の start-update を実行します。
B
インスタンス テンプレートを更新した新しいマネージド インスタンス グループを作成します。そのグループをロードバランサのバックエンドサービスに追加します。新しいマネージド インスタンス グループ内のすべてのインスタンスが正常になったら、古いマネージド インスタンス グループを削除します。
C
maxSurge を 1 に設定し、maxUnavailable を 0 に設定して、 rolling-action の start-update を実行します。
D
新しいアプリケーションバージョンで新しいインスタンス テンプレートを作成します。既存のマネージド インスタンス グループを新しいインスタンス テンプレートで更新します。マネージド インスタンス グループ内のインスタンスを削除して、マネージド インスタンス グループが新しいインスタンス テンプレートを使用してインスタンスを再作成できるようにします。
問題 2 の説明および補足 
基本のローリング更新の開始
rolling-action の start-update を使用して、maxSurge を 1 に設定し、maxUnavailable を 0 に設定して、ローリング アップデートを実行することができ、容量を減らすことなくインスタンスを 1 つずつリサイクルすることができます。

※基本のローリング更新の開始
基本的なローリング アップデートとは、すべてのインスタンスが意図する最新の構成に更新されるまで、MIG のすべてのインスタンスに段階的に適用されるアップデートです。ローリング アップデートでは、最新の構成にあるインスタンスが自動的にスキップされます。更新中にオフラインにすることが可能なインスタンス数、インスタンス間での更新待機時間、新しいテンプレートの影響範囲(全体または一部)など、ローリング アップデートのさまざまな設定を制御できます。

※最大サージ
maxSurge オプションを使用すると、自動更新中に MIG が targetSize を超えて作成できる新しいインスタンスの数を構成できます。たとえば、maxSurge を 5 に設定すると、MIG は新しいインスタンス テンプレートを使用して、ターゲット サイズを超える最大 5 つの新しいインスタンスを作成します。maxSurge の値が大きくなるほど更新速度は上がりますが、インスタンスの追加による費用がかかります。

maxUnavailable オプションを使用すると、自動更新中に常時利用できないインスタンスの数を構成できます。たとえば、maxUnavailable を 5 に設定すると、更新の際、同時にオフラインになるのは、5 つのインスタンスだけです。このパラメータを使用して、更新がサービスに与える影響の度合いと、更新をデプロイする速度を制御します。
参考URL:基本のローリング更新の開始

■以下は間違いです。
・インスタンス テンプレートを更新した新しいマネージド インスタンス グループを作成します。そのグループをロードバランサのバックエンドサービスに追加します。新しいマネージド インスタンス グループ内のすべてのインスタンスが正常になったら、古いマネージド インスタンス グループを削除します。
・新しいアプリケーションバージョンで新しいインスタンス テンプレートを作成します。既存のマネージド インスタンス グループを新しいインスタンス テンプレートで更新します。マネージド インスタンス グループ内のインスタンスを削除して、マネージド インスタンス グループが新しいインスタンス テンプレートを使用してインスタンスを再作成できるようにします。
→インスタンス テンプレートを更新する必要がないため、間違いです。

・maxSurge を 0 に設定し、maxUnavailable を 1 に設定して、 rolling-action の start-update を実行します。
→maxSurge を 0 に設定し、maxUnavailable を 1 に設定すると容量が減少するため間違いです。
問題3
Google Cloud Platform で実行する単一のバイナリアプリケーションがあります。インフラストラクチャの CPU 使用率に基づいて、アプリケーションを自動的にスケーリングすることにしました。組織のポリシーにより、仮想マシンを直接使用することが求められています。アプリケーションのスケーリングは、運用効率が高く、できるだけ早く完了させる必要があります。どのように対応しますか。
A
インスタンス テンプレートを作成し、そのテンプレートを時間帯に応じてスケールアップ/ダウンするマネージド インスタンス グループで使用します。
B
Google Kubernetes Engine (GKE) クラスタを作成し、水平 Pod 自動スケーリングを使用してアプリケーションをスケーリングします。
C
サードパーティ製のツールを使用して、Stackdriver の CPU 使用率のモニタリングに基づいて、アプリケーションのスケールアップとスケールダウンの自動化を構築します。
D
インスタンス テンプレートを作成し、自動スケーリングを設定したマネージド インスタンス グループでテンプレートを使用します。
問題 3 の説明および補足 
インスタンスのグループの自動スケーリング
マネージド インスタンス グループは、仮想マシンを直接使用するのに役立ち、自動スケーリングによって需要に応じてスケーリングすることができます。

※インスタンスのグループの自動スケーリング
マネージド インスタンス グループ (MIG) には、負荷の増減に基づいて、MIG から仮想マシン (VM) インスタンスを自動的に追加または削除できる自動スケーリング機能が備わっています。自動スケーリングによって、トラフィックの増加をアプリで適切に処理できると同時に、リソースの必要性が低下した場合は費用を削減できます。自動スケーリング ポリシーを定義すると、測定された負荷と構成したオプションに基づいてオートスケーラーが自動スケーリングを実行します。
自動スケーリングでは、負荷が多くなると MIG に VM が追加され(スケールアウト、スケールアップとも呼ばれます)、VM の必要性が低下すると VM が削除されます(スケールインまたはスケールダウン)。
参考URL:インスタンスのグループの自動スケーリング

■以下は間違いです。
・サードパーティ製のツールを使用して、Stackdriver の CPU 使用率のモニタリングに基づいて、アプリケーションのスケールアップとスケールダウンの自動化を構築します。
→外部ツールの使用は、好ましくないオプションであるため間違いです。

・インスタンス テンプレートを作成し、そのテンプレートを時間帯に応じてスケールアップ/ダウンするマネージド インスタンス グループで使用します。
→スケジュールに基づくスケーリングでは、需要に応じたスケーリングを効果的に利用できないため間違いです。

※スケジュールに基づくスケーリング
スケジュールに基づく自動スケーリングでは、予想される負荷に対する容量を事前にスケジューリングすることで、ワークロードの可用性を向上させることができます。マネージド インスタンス グループ (MIG) でワークロードを実行する場合、繰り返しの負荷パターンや 1 回限りのイベントに対して必要な数の仮想マシン (VM) インスタンスをスケジューリングできます。ワークロードの初期化に時間がかかり、予想される負荷の急増が発生する前にスケールアウトする場合は、スケーリング スケジュールを使用します。
参考URL:スケジュールに基づくスケーリング

・Google Kubernetes Engine (GKE) クラスタを作成し、水平 Pod 自動スケーリングを使用してアプリケーションをスケーリングします。
→Google Kubernetes Engine (GKE) クラスタがスケーリングをサポートしています。一方で、仮想マシンを直接使用するという要件を満たしていないため間違いです。

※水平 Pod 自動スケーリング
Kubernetes クラスタにワークロードを初めてデプロイする段階では、明確なリソース要件を把握することはできません。使用パターン、外部依存関係などの要因でリソース要件がどのように変化するのかは予測できません。水平 Pod 自動スケーリングを使用すると、さまざまな状況でワークロードが一貫して機能することを確認できます。また、必要なときにのみ追加容量分を支払うことで、費用を管理できます。
指標からワークロードのリソース不足や低使用率を予測するのは必ずしも簡単なことではありません。HorizontalPodAutoscaler は、次のタイプの 1 つ以上の指標に基づいて、ワークロード内の Pod 数を自動的にスケーリングします。
参考URL:水平 Pod 自動スケーリング
問題4
あなたの会社では、数週間前から App Engine アプリケーションでマーケティングアプリケーションを自動スケーリングで運用しており、順調に推移しています。しかし、マーケティングチームが大規模なキャンペーンを計画しており、大量のバーストトラフィックが発生することが予想されます。アイドル状態のインスタンスが常に 3 つあることを確認するにはどうすればよいですか?
A
app.yaml で min_idle_instances プロパティを設定します。
B
app.yaml で min_instances プロパティを設定します。
C
手動スケーリングに切り替えて、app.yaml の idle_instance_count プロパティを使用します。
D
手動スケーリングに切り替えて、app.yaml の burst_traffic_protection プロパティを True にします。
問題 4 の説明および補足 
スケーリングの要素
min_idle_instances プロパティを設定することで、常に稼働している最小のアイドルインスタンスを持つことができます。

※スケーリング タイプ
自動スケーリングは、リクエスト率、レスポンスのレイテンシなどのアプリケーションの指標に基づいてインスタンスを作成します。それぞれの指標のしきい値、および常時稼働する最小数のインスタンスを指定できます。
参考URL:スケーリング タイプ

※スケーリングの要素
min_idle_instances : 動作を継続中で、このバージョンのトラフィックの処理に対応できる追加のインスタンスの数
App Engine は、target_cpu_utilization や target_throughput_utilization などのスケーリング設定に基づいて、現在のアプリケーション トラフィックを処理するために必要なインスタンスの数を計算します。min_idle_instances を設定すると、計算されたインスタンスの数に加えて実行するインスタンスの数を指定できます。たとえば、App Engine がトラフィックの処理に 5 つのインスタンスが必要と計算し、min_idle_instances を 2 に設定した場合、App Engine は 7 つのインスタンスを実行します(トラフィックに基づいて計算された 5 つと、min_idle_instances で追加された 2 つ)。

ただし、トラフィックを受信しているかどうかにかかわらず、指定されたインスタンス数分の料金が請求される点に注意してください。以下のことに注意してください。

・最小数を小さく設定すると、アイドル時間にかかるランニング コストは低く抑えられますが、負荷の急増があった場合にすぐに対処できるインスタンスの数が少なくなります。
・最小数を大きく設定すると、アプリケーションがリクエスト負荷の急増に対応できるようになります。App Engine では、受信リクエストを処理するために最小数のインスタンスが常に実行されています。指定された数のインスタンスについては、リクエストを処理しているかどうかにかかわらず、そのインスタンス数分の料金が請求されます。

アイドル インスタンスの最小数を設定すると、保留レイテンシがアプリケーションのパフォーマンスに与える影響は小さくなります。
参考URL:スケーリングの要素

■以下は間違いです。
・手動スケーリングに切り替えて、app.yaml の burst_traffic_protection プロパティを True にします。
・手動スケーリングに切り替えて、app.yaml の idle_instance_count プロパティを使用します。
→手動スケーリングでは最小限の実行インスタンスが提供されないため間違いです。

・app.yaml で min_instances プロパティを設定します。
→min_instances は最小のアイドルインスタンス数の設定に用いることができないため間違いです。App Engine がこのモジュール バージョンに対して作成するインスタンスの最小数です。
問題5
Cloud Storage バケットに、外部の企業と共有したいオブジェクトがあります。そのオブジェクトには機密データが含まれています。このコンテンツへのアクセスは、4 時間後に削除したいです。外部の企業は、ユーザーベースの特定のアクセス権限を付与できる Google アカウントを持っていません。最も少ない手順で最も安全な方法を使用したいと考えています。どうしたらいいですか。
A
Storage バケットを静的ウェブサイトとして設定し、オブジェクトの URL を企業に提供します。4 時間後に、Storage バケットからオブジェクトを削除します。
B
外部の企業がアクセスできるように、新しい Cloud Storage バケットを作成します。オブジェクトをそのバケットにコピーします。4 時間後にそのバケットを削除します。
C
オブジェクトのアクセスを「公開」に設定し、オブジェクトのライフサイクル管理を使用して 4 時間後にオブジェクトを削除します。
D
4 時間の有効期限を持つ署名付き URL を作成し、その URL を企業と共有します。
問題 5 の説明および補足 
Cloud Storage : 署名付き URL
ファイルを Cloud Storage に保存し、署名付き URL を使用すると、Google アカウントを必要とせずに、ファイルを企業と迅速かつ安全に共有することができます。

※署名付き URL
署名付き URL は、Google アカウントを持っているかどうかにかかわらず、URL を所有しているユーザーに、期限付きのリソース アクセス権を提供できます。
シナリオによっては、ユーザーの Google アカウントによって Cloud Storage へのアクセスを制御することが望ましくなく、むしろアプリケーション固有のロジックを使ってアクセスを制御したい場合があります。このような場合には、一般にユーザーに署名付き URL を提供し、ユーザーにそのリソースについて期間限定で読み取り、書き込み、削除のアクセス権を与えることで対処します。署名付き URL を作成するときに有効期限を指定します。URL が期限切れになるまで、または URL の署名に使用された鍵がローテーションされるまで、URL を知っている人であれば誰でもそのリソースにアクセスできます。
参考URL:署名付き URL

■以下は間違いです。
・Storage バケットを静的ウェブサイトとして設定し、オブジェクトの URL を企業に提供します。4 時間後に、Storage バケットからオブジェクトを削除します。
・外部の企業がアクセスできるように、新しい Cloud Storage バケットを作成します。オブジェクトをそのバケットにコピーします。4 時間後にそのバケットを削除します。
→迅速なソリューションではなく、ソリューションをホスト、共有、および停止するための手作業が必要となるため間違いです。

・オブジェクトのアクセスを「公開」に設定し、オブジェクトのライフサイクル管理を使用して 4 時間後にオブジェクトを削除します。
→すべてのユーザーがデータを共有するための安全な方法ではなく、パブリックとしてマークされるため間違いです。
問題6
あなたの会社では、プロジェクトのために毎月予算を確保しています。あなたは、プロジェクトの支出が自動的に通知され、上限に近づいたときに対策を講じることができるようにしたいと考えています。どうしたらいいでしょうか?
A
GCP コンソールで、BigQuery への請求データのエクスポートを設定します。総支出を照会する保存済みビューを作成します。
B
月間総予算の 50%、90%、100% など、希望するパーセンテージの予算アラートを作成します。
C
予算と同額の月間限度額を設定したクレジットカードを用意します。
D
App Engine の設定で、1 日の予算を月間予算の 1/30 に設定します。
問題 6 の説明および補足 
予算と予算アラートの設定
予算アラートでは、しきい値を設定し、それを超えた場合にアラートが自動的にトリガーできます。

※予算と予算アラートの設定
プロジェクトの計画とコストの管理を支援するために、予算アラートを設定することができます。予算アラートを設定すると、特定の金額に向かって支出がどのように増加しているかを追跡できます。予算アラートは、請求先アカウントまたはプロジェクトのいずれかに適用することができ、予算アラートを特定の金額に設定したり、前月の支出に合わせることができます。アラートは、支出が予算の一定割合を超えた場合に、請求管理者と請求先アカウント ユーザーに送信されます。
参考URL:予算と予算アラートの設定

■以下は間違いです。
・GCP コンソールで、BigQuery への請求データのエクスポートを設定します。総支出を照会する保存済みビューを作成します。
→このソリューションでは自動アラートをトリガーせず、チェックもすぐには行われないため間違いです。

・App Engine の設定で、1 日の予算を月間予算の 1/30 に設定します。
→App Engine には予算設定がないため間違いです。

・予算と同額の月間限度額を設定したクレジットカードを用意します。
→予算と同額の月間限度額を設定したクレジットカードはアラートを出さないため間違いです。料金は使用量に応じて増加します。
問題7
複雑な Deployment Manager のテンプレートを大幅に変更し、プロジェクトにコミットする前に、定義されたすべてのリソースの依存関係が適切に満たされていることを確認したいと考えています。また、変更内容について最も迅速なフィードバックを得たいと考えています。どのように対応しますか。
A
同じ構成の別のプロジェクトに対して Deployment Manager のテンプレートを実行し、障害をモニタリングします。
B
GCP コンソールの Stackdriver Logging ページで Deployment Manager 実行のアクティビティをモニタリングします。
C
同じプロジェクトで --preview オプションを使用して Deployment Manager のテンプレートを実行し、相互に依存するリソースの状態を観察します。
D
Python で作成された Deployment Manager のテンプレート内で、詳細なログステートメントを使用します。
問題 7 の説明および補足 
構成をプレビューする
・同じプロジェクトで --preview オプションを使用して Deployment Manager のテンプレートを実行し、相互に依存するリソースの状態を観察します。
→Deployment Manager には、どのようなリソースが作成されるかを確認するためのプレビュー機能があるため正解です。

※構成をプレビューする
構成ファイルを作成した後で、デプロイの作成前に構成をプレビューできます。構成をプレビューすることで、Deployment Manager が作成するリソースの中で、実際にはインスタンス化されないリソースを確認できます。Deployment Manager サービスは次の方法で構成をプレビューします。
1.テンプレートを含め、構成を完全にデプロイします。
2.デプロイと「シェル」リソースを作成します。
insert() リクエストを実行するときに preview クエリ パラメータを使用して構成をプレビューできます。
参考URL:構成をプレビューする
お疲れさまでした。 クイズが完了したら、「クイズの結果を見る」ボタンをクリックしてください。あなたが完了していないアイテムは、間違いのマークがされます。 クイズの結果を見る
問題は全部で 7 問。全て答えられるように頑張りましょう!
リスト
戻る
網掛け部分は完了した項目です。
12345
67ゴール
戻る
error: コンテンツの複製・転用は禁止されております。