EC2

Q1. High Performance Cluster(HPC)クラスターをAWSにデプロイしようとしている。t3a.mediumのWindowsサーバで性能チューニングができるパラメータを用意する必要がある。高い帯域性能、PPS(packet per second)、低いインスタンス間レイテンシを確保するためにはどのアーキテクチャを使うべきか。

Enable Enhanced Networking with Elastic Network Adapter(ENA)
Enable Enhanced Networking with Elastic Fabric Adapter(EFA)
Enable Enhanced Networking with Intel 82599 Virtual Function(VF) interface
AWS ParallelCluster

A1. 1. ENAを用いてENを有効にする。

ENAはsingle root I/O virtualization(SR-IOV)を用いて、高いネットワーク性能を実現する。
比較的少ないCPU利用で、高いI/Oパフォーマンスを実現できる
追加の料金はかからない
EFAはENAを単純に強化したもの。追加でOS-bypassの機能が利用できる。
OS-bypassはHPCや機械学習アプリケーションがダイレクトにNetworkInterfaceと接続できるモデル。
ただし、EFAはWindowsでサポートされてません（2020/3時点）

Q2. スポットインスタンスを利用している。max \$0.04/hrでリクエストしてインスタンスを起動し、90分後に\$0.06/hrになりインスタンスは削除された。かかった費用はいくらか？

A2. 起動後１時間経過しているため、ターミネートされた時間まで課金される。よって、$0.04(60min)+$0.02(30min)でコストは$0.06

AWSがインスタンスを中断した場合
- 最初の１時間なら無料
- １時間以降はAmazon Linuxなら使用された時間（秒）
ユーザがインスタンスを中断した場合
- 最初の１時間でも請求。AmazonLinuxは使用した時間（秒）

→OS、Spotブロックか否かによって違うみたい…覚えられません
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/spot-interruptions.html

Q3. あなたはEC2をデプロイしてSGとキーペアを適切に設定してsshができるようにした。その後、請負のエンジニアがアプリを動かすために様々な変更を加えた（.sshフォルダ含む）ところ、プライベートキーは有効にも関わらず、「Server refused our key」errorが発生しsshできなくなった。考えうる原因として適切でないものは何か？

A3. プライベートキーのパーミッションが0777になっている。
この場合は、"Unprotected Private Key File"エラーが発生する。

考えうる原因のリスト

対応する公開鍵がauthorized_keys fileの中にない
authorized_keys fileへのアクセス権がない
.sshディレクトリへのアクセス権がない
authorized_keys file or .sshの名前が適切でない
authorized_keys file or .sshが削除されている
インスタンスが鍵なしで起動されているか、鍵が異なる

Elastic Load Balancer

Q1. パブリックなELBを通るHTTPリクエストの内容を5分ごとにキャプチャしてトラフィックパターンの解析や、トラブルシュートに利用したい。どのように設定をすべきか。

A1. ELBのログ出力機能を有効にする

ELBのコンソールにログ出力を有効にするオプションがある。（デフォルト無効）
ログにはtime, clientIP, Latencies, request paths, responseなどが含まれる
ログは圧縮された状態でS3に格納される。バケットは任意
S3に格納されたログにはAthenaからクエリをかけられる

Q2. Classic Load Balancerの後ろにAutoScaling構成のアプリケーションがある。EC2インスタンスをCLBから外す時、処理中のリクエストが完了するまで解除しないような仕組みにしたい。ただし、インスタンスがunhealthyになった時は、新たなリクエストがCLBから送られてはならない。どうすればよいか？

proxy protocolを設定する
Sticky Sessionを設定する
Connection Drainingを設定する
Cross-zone Load BalancingとSticky Sessionを設定する

A2. ３

まさにconnection drainingの存在理由のような設問
新しいリクエストを送らないようにした後、どれだけの期間connectionを維持するかを設定する
デフォルト300秒、最小1秒〜最大３６００秒

Application Load Balancer

Q1. ALBの後ろにEC2を構成している。ヘルスチェックにはどのプロトコルを用いるか？

A1. HTTP or HTTPS healthcheck
Network Load BalancerのみTCPヘルスチェックを利用できる。

AutoScaling

Q1. オートスケーリング構成のアプリケーションの挙動を確認すると、１時間の間に複数回のスケールアウト、スケールインが確認された。elasticityを維持したまま、コスト最適化を行うにはどうすれば良いか。

A1. クールダウンタイムの変更と、CloudWatchメトリクスのより大きい値への変更を行う。

simple scaling policyを利用している場合、cooldown timeは有効になり、追加のインスタンス起動・削除は、前回のScalingActivityから一定時間経過するまで保留される
手動でスケーリングした場合、デフォルトはcooldown timeが設定されないが、設定の上書きは可能
インスタンスがunhealthyになった場合は、cooldown timeは考慮されず、即座にインスタンスの置き換えが実行される

Q2. オートスケーリングで設定されたアプリケーションのEC2が次々とterminateされてしまうため、モニタリングを自動化して原因を探りたい。どのCLIコマンドを利用するのが良いか？

aws ec2 describe-instances
aws ec2 describe-images
aws ec2 get-console-screenshot
aws ec2 describe-volume-status

A2. aws ec2 describe-instances

直近でterminateされたインスタンス含めて情報を取得できる
StateReason（なぜインスタンスがterminateされたか）も返却される

ref1. スケーリングポリシーの種類

Target tracking scaling
- 特定のメトリクスを基準にスケールする
Step scaling
- ステップ調整値を基準にスケールする
- CPU使用率が50%以上でインスタンス１つ追加、60%で２つ追加など段階的
- スケーリングの途中でもCloudWatchAlermからの通知を処理する
Simple scaling
- 単一のステップ調整値を基準にスケールする
- 基本的にStep scalingを使うことを推奨

公式によると以下らしい…

インスタンス数に比例してメトリクスが増減するような場合は、Target tracking推奨。それ以外の場合は、Step scalingがよいでしょう。

Q3. AutoScalingの中のEC2のターミネートされる評価基準は？

A3.

マルチAZか？ -> Yesなら最も数が多いASGが対象
最も古いローンチコンフィグが設定されているインスタンスが対象
次の課金時間に最も近いインスタンスが対象（自動でコスト最適化される）
最終的にはランダム

Q４. シングルのEC2が1台ある。これをAutoScaling化するには何が必要か？

まずインスタンスを停止する
そのインスタンスを起動するために使ったAMIが存在しないこと
インスタンスがAutoScalingGroupで定義したAZに存在すること
インスタンスがAutoScalingGroupとは異なるAZに存在すること
インスタンスを起動するために使ったAMIが存在すること

A4. 3、5

インスタンスをAutoScalingにアタッチしたい場合は下記を満たしましょう。

インスタンスが起動中
そのインスタンスのAMIが存在する
そのインスタンスが他のAutoScalingGroupのメンバーでない
インスタンスがASGと同じAZに存在する
ASGにELBがアタッチされている場合、インスタンスとELBがいずれもEC2-Classic（CLBの場合のみ）か、同一のVPC内に存在する

AWS Solution Architect Associateへの道〜第１夜

EC2

Elastic Load Balancer

Application Load Balancer

AutoScaling