AWS試験対策: EC2

概要

勉強メモ

Enhanced Network

SR-IOV (ネットワークインターフェース？)

• ENA: 低レイテンシー1
• EFA: HPCがある場合に適用可能
  最新のインスタンスタイプで利用可能。古いインスタンスではドライバがvifとなる。新しいインスタンスタイプ (t3)ではドライバーがenaと表示される

Placement Groups

EC2インスタンスをAWS内にどのように配置するか
3種類のストラテジー

• Cluster: すべてのEC2インスタンスを単一AZに配置することで低遅延・高スループット。AZ障害で死ぬ。ビッグデータ用や低遅延アプリなどに向いている
• Spread: すべてのEC2が異なるハードウェアに配置する。ただし、1つのreplacement groupあたり1つのAZに最大7つまでしかインスタンスを作成できない。数に制限があるので多すぎないアプリ、可用性が必要なアプリ。
• Partition: 1つのAZに最大7つまでパーティションを作成できる。1つのパーティションには多数のEC2インスタンスを作成できる。各パーティションはAWSのハードウェアラックに相当する。パーティションはAZを跨ぐとこもできる。100以上のインスタンスを所属可能。パーティションごとに障害の被害が独立。分散処理など

Create Placement Groupから作成する。グループ名、ストラテジー、Partioion数を指定する
EC2インスタンス作成時に、詳細設定からPlacement Groupを選択する

shutdown behaviorについて

OS内部からshutdownすると、EC2インスタンスが停止する場合と終了 (削除)される場合がある。
Terminate ProtectionによりAWSコンソールやCLIから誤って削除されることを防げる.
Terminate Protection有効化時は、AWSコンソール上での停止操作は拒否されて誤って削除されることを防げる。ただし、OSでのshutdownコマンドによる削除は防げない (動作はshutdown behaviorの設定に依存する)

EC2起動のトラブルシューティング

• InstanceLimitExceeded: リージョンごとのvCPUの最大数に到達したエラー。
  • デフォルトの最大数は64
  • オンデマンドインスタンスとスポットインスタンスはvCPU数に制限がある。よって、このエラーはオンデマンドインスタンスとスポットインスタンスにのみ適用される
  • 解決法
    • 別のリージョンでインスタンスを作成する
    • AWSに制限数の引き上げを申請する
• InsufficientInstanceCapacity: インスタンスを起動した特定のリージョンにおいて、AWSがオンデマンドインスタンスに対して十分なキャパシティを確保できないエラー (AWS側の問題)
  • 解決法
    • 数分待ってリトライする
    • 複数のインスタンスを同時に作成しようとしている場合は、少数で試してみる
    • インスタンスサイズを変更して作成し、後から別のインスタンスタイプにする
    • 別リージョンの利用
• InstanceTerminatesImmediately: 起動したインスタンスがすぐに終了した場合
  • EBSの容量が上限に達しているか、EBSが破損しているか、ルートEBSが暗号化されており復号化のためのKMSキーにアクセスする権限がない。またはバックアップされたAMIであれば特定のファイルが足りないなど
  • AWSのEC2コンソールで原因の説明文を確認する

EC2のsshのトラブルシューティング

• EC2 instance connectでEC2にsshするには、インバウンドルールで特定のIPを許可する必要がある。IPはリージョンごとにAWSから指定されている

購入オブション

• オンデマンド
  • 使った分だけ払う
  • コストは最も高いが前払いはない
  • 短気でいいが中断が許されない場合
• リザーブド
  • 最大72%ディスカウント。インスタンスタイプ、リージョン、テナンシー、OSを指定する
  • 1年、3年で契約
  • 前払いするとより安くなる
  • 不要になればMarketPlaceで売却可能
  • コンバーチブル・リザーブド (インスタンスタイプ、リージョン、テナンシー、OSを途中で変更可能)
• saving plan
  • 特定のインスタンスタイプではなく、時間あたりの料金で長期契約
  • 料金を超える使用量はオンデマンドの価格が適用される
• スポットインスタンス
  • 最も安いが途中で無くなる可能性ある。最大90%OFF
  • ユーザが指定した価格よりもスポット定義価格が安い場合に起動する設定が可能
  • バッチ処理や分散処理など。
  • スポットリクエストは1回のみと永続化がある
    • インスタンスをキャンセルする場合は、スポットリクエストをキャンセルした後にインスタンスを削除する必要がある
  • Spot Fleets
    • スポットインスタンス+オンデマンド
    • スポット価格は時価なのでオンデマンドより高い場合や上位のインスタンスタイプの方が安い場合などがある。
    • 複数パターンのインスタンスを定義して、最安のパターンでEC2を起動する
• Dedicated Hosts
  • 客のユースケースに特化したEC2インスタンスの容量を持つ実際の物理サーバを契約する
  • コンプライアンス要件がある場合など
  • オンデマンド・リザーブドで契約可能
  • 同じAWSアカウントの他インスタンスとHWを共用する可能性ある。配置は指定不可
• キャパシティ予約
  • AZを指定してオンデマンドを予約する
  • 割引はない
  • 起動の有無に関わらず料金は請求される

Burstable Instance (T2/3)

• クレジットを消費してCPUに高負荷をかけることができる。
• CPUの負荷が低い場合は、クレジットが返ってきて再利用できる
• クレジットを使い切ると、CPUの使用率がベースラインに下げられる
• Unlimitedのインスタンスを使うと、クレジットによる上限がなくなる代わりに、追加でお金を払うことになる。

Elastic IPs

• インスタンスにアタッチしている間は無料。
• インスタンス間でアタッチし直すことで、インスタンス障害を隠せる
• 1アカウントで5個までもてる。

CloudWatchメトリクス

• デフォルトは5分間隔でメトリクスを収集。詳細モニタリングを有効化すると1分間隔
• カスタムメトリクスは1分間隔。高解像にすると最高1秒間隔
• メトリクス
  • クレジット
  • トラフィック量
  • インスタンスステータス、システムステータス
  • インスタンスストアの読み書き
• RAMは取得できない (頻出)。
• Unified CloudWatch Agentを導入してCloudWatchにログを送る。エージェントの設定をする場合はSSM Parameter Storeを利用する
• procstat Pluginを使うと、実行中のプロセスの情報を取得することができる。
• CloudWatchの利用にはEC2に適切なIAMロールを付与する必要がある
  • Serverロールを利用するとSSM Parameter Storeから設定を取得できる
  • Adminロールを利用するとSSM Parameter StoreへのPutもできる

status check

\これらは試験で2〜3問の焦点になる可能性があるため、違いを理解しておきましょう。

• システムステータスチェック (SYSTEM status checks)

  システムステータスチェックは、インスタンスが実行されているAWSシステムを監視します。

  例：基盤となるホストの問題

  • ネットワーク接続の喪失
  • システム電力の喪失
  • 物理ホスト上のソフトウェアの問題
  • ネットワーク到達可能性に影響を与える物理ホスト上のハードウェアの問題

  対処方法：

  • AWSがホストを修正するのを待つ、または
  • インスタンスを新しいホストに移動する（EBSバックのインスタンスの場合、インスタンスを停止して再起動する）

• インスタンスステータスチェック (INSTANCE status checks)

  インスタンスステータスチェックは、個々のインスタンスのソフトウェアおよびネットワーク設定を監視します。

  例：問題の例

  • 不適切なネットワークまたはスタートアップ構成
  • メモリ不足
  • ファイルシステムの破損
  • 不適合なカーネル

  対処方法：

  • インスタンスの再起動、または
  • インスタンスの構成変更

Hibernate (休止状態)

• RAMにあったものをルートEBSボリュームのファイルに書き込むことで、起動を高速化する
  • EBSの暗号化と十分な容量が必要
• RAMの状態を保存したい場合や、起動に時間がかかる場合に有効
• キープできるのは60日以内