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内に存在する