QUESTION

ある会社は、Amazon EC2 のインスタンス群で分析基盤を運用し、AWS Compute Optimizer を有効にしています。得られる推奨では、メモリが逼迫しているインスタンスを判断できません。負荷は四半期の締めの時期にだけ大きく跳ね上がります。ソリューションアーキテクトは、締めの時期の使われ方まで踏まえた適切なサイズを、Compute Optimizer から得られるようにする必要があります。 ソリューションアーキテクトは、どのステップの組み合わせを完了する必要がありますか。 (2 つ選択)

1 / 1
複数選択してください
正解A, C

解説

サイズの見直しの推奨が的を外すときに、材料になる指標と分析される期間の両方を補う

  • 1メモリが逼迫しているインスタンスを判断できません推奨のもとになる材料に、届いていない指標があります。標準のメトリクスにメモリの使用率が含まれないため、まず送り始めることが前提になります
  • 2四半期の締めの時期にだけ大きく跳ね上がりますデフォルトの分析の対象期間に、その山が入らない可能性があります。期間そのものを延ばさない限り、締めの時期の使われ方が推奨に反映されるかどうかは推奨を見る時期に左右されます。
  • 3締めの時期の使われ方まで踏まえた適切なサイズ推奨そのものを作り直すのではなく、推奨のもとになる条件をそろえることが要求です。候補の絞り込み方を変える案や、出た推奨を保管する案では材料と期間が動きません
A正解

対象のインスタンスに CloudWatch エージェントを導入し、メモリの使用率を収集する。

AWS Compute Optimizer は Amazon CloudWatch のメトリクスを分析して推奨を出しますが、Amazon EC2 の標準のメトリクスにはメモリの使用率が含まれていません。メモリの使用率が分析の対象になるのは、CloudWatch エージェントを導入したインスタンスか、対応するオブザーバビリティ製品(Datadog、Dynatrace、Instana、New Relic)から取り込む設定をしたインスタンスに限られます。

エージェントを導入して使用率を送り始めるとメモリが逼迫しているインスタンスも判断の材料に入り、標準のメトリクスだけでは判定できなかったメモリの過不足が推奨に表れます。どちらの経路も用意せずに待っていても、メモリを根拠にした推奨は出ません。

B不正解

Compute Optimizer の推奨設定で、候補に含めるインスタンスファミリーにメモリ最適化を加える。

Compute Optimizer には推奨の出し方を調整する設定があり、どのインスタンスファミリーを候補に含めるかを指定できます。メモリ最適化のファミリーを候補に加えると、推奨として提示されるタイプの範囲が変わります。

ただし変わるのは提示される候補の絞り込み方だけで、メモリの不足を示す材料も分析される期間も動きません。いま出ていない推奨が、この設定で出てくるわけではありません。

C正解

Compute Optimizer で拡張インフラストラクチャメトリクスを有効にする。

Compute Optimizer がデフォルトで分析するのは直近の 14 日の利用状況で、四半期の締めにだけ現れる山は締めから 14 日が過ぎると分析の期間から外れます。そのままでは、締めの時期の使われ方が推奨に入るかどうかが、推奨を見る時期に左右されます。

有効にすると分析の対象になる期間が最大 93 日まで延び、締めの時期を含む長い周期の変動を踏まえた推奨が得られます。Amazon EC2 インスタンスや Auto Scaling グループ配下のインスタンスに適用でき、追加の費用がかかる機能です。

D不正解

Amazon CloudWatch で、メモリの使用率が高いインスタンスを知らせるアラームを作成する。

メモリの使用率にしきい値を置いてアラームを作れば、逼迫したときに気づけるようになります。監視の対策としては妥当です。

ただしアラームは状態を知らせる仕組みであって、推奨を作る材料になりません。Compute Optimizer が読むのは届いているメトリクスそのもので、メモリの使用率が送られていなければアラームのしきい値も判定できず、対策の順序が逆になっています。

E不正解

Compute Optimizer の推奨を四半期ごとに Amazon S3 へ書き出し、締めの時期のものを保管する。

Compute Optimizer の推奨は Amazon S3 へ書き出して残せます。締めの時期に書き出したものを保管しておけば、そのときの推奨をあとから見返せます。

ただし書き出されるのはそのときの分析の対象期間で作られた推奨で、対象期間は直近側へずれていきます。締めの時期を含む推奨を得られるかが書き出す時期の合わせ方に左右され、期間そのものを広げるほうが確実です。

ポイント

AWS Compute Optimizer の推奨の質は、どの指標が届いているかどれだけの期間を見たかの 2 つで決まります。
指標の側でつまずくのがメモリの使用率です。EC2 の標準のメトリクスにメモリは含まれないため、CloudWatch エージェントを導入するか対応する製品から取り込まない限り、メモリを根拠にした推奨は出ません。
「CPU には余裕があるのに重い」状況でも、標準のメトリクスだけではメモリの逼迫が推奨に表れません。メモリの指標が無いとき、Compute Optimizer はメモリを減らす推奨を避けようとするだけで、メモリが足りないことは判定できません。
期間の側はデフォルトでは直近の 14 日しか見ません。月末や四半期末にだけ現れる山は、直近 14 日に入っている間しか反映されません。
分析の期間は 14 日・32 日・93 日から選べますが、93 日を選ぶには拡張インフラストラクチャメトリクスの有効化が必要で、四半期の周期を確実に含められるのはこの 93 日だけです。