Pankration 2024でEC2インスタンスガチャの話をしてきた
8/24-25に開催されたJAWS Pankration 2024でEC2インスタンスガチャの話をしてきました。
Pankrationは世界中のAWSのタイトルホルダーや従業員の人たちが、24時間ぶっ通しでAWSの話をするクレイジーなイベントです。
My Session
「Project "Instance Lottery"」（日本語だと「EC2インスタンスガチャ」）というタイトルで登壇させていただきました。なんでこんな発表を？と思った方は、レコーディングや資料を見ていただければと思いますが、登壇までのことや、当日時間の関係でお話しできなかったことを少し書き残しておこうと思います。
登壇概要ページ
レコーディング
登壇資料
登壇までのこと
4年に1回のイベントということで是非登壇したいと思ってはいたのですが、実際CfPを提出したのは〆切5分前くらいだったと思います。それも、いくつか考えていたネタを捨てて、〆切30分前に思いついたものを特急で仕上げたというドタバタでした。
仕事柄、英語での発表準備はよくあるので特に抵抗感はなかったのですが、仕事関連の話は一切できないので業務で得た知見を共有できるわけでもなく、突出した知見の共有ができるわけでもないので、自分のCfPがこのクレイジーなイベントに見合うものなのか？という自問自答は結構ありました。Acceptの連絡いただいた時は正直びっくりしましたが、実行委員長の吉江さんにCfPは公平に選んだと言っていただけて大分気持ちが楽になったのを覚えています。
タイトル通り、夏休みの自由研究的な感じでやろうと思っていたのですが、いろいろあって夏休みを取ることができず、Pankrationの翌日も登壇が入ってしまい、〆切2週間前くらいから半泣き状態でやっていたのも、終わってみればよい思い出ですｗ
当日話せなかったこと
測定方法について
時間の関係でお話しできなかったのですが、測定方法を決めるまでが実は一番大変でした。最初に検討したのは次のようなアプローチでしたが、いずれも今回の目的には合いませんでした。
- ICMP ping
- RDSはICMPに応答しないため使用不可。
- nc (netcat)
- RDSのマニュアルでは疎通確認の手段としても紹介されていますが、出力結果に含まれている時間情報の精度が不十分。
- RDSのマニュアルでは疎通確認の手段としても紹介されていますが、出力結果に含まれている時間情報の精度が不十分。
-
VPC FlowLogs
- 指定した時間（最小1分）のパケットがアグリゲーションされてしまうため、測定時の各試行のデータを分離できない。
- 精度がミリ秒で不十分。
これらが使えなさそうなことはある程度予想通りで、簡単な測定ツールを作るつもりでしたが、測定条件に関して少し調査をしてみたところ、Googleがレイテンシベンチマークについて興味深い記事を公開していました。
- レイテンシの測定は、ほとんどの場合 netperf(TCP_PR) が適している
- netperfは測定条件を調整するオプションが豊富で柔軟性が高い
- 実際のアプリケーションのユースケースに近いTCPを使用する
- 測定間隔の差異によって測定値が大きく異なることがある（特に測定間隔が小さい場合）
- 例えば、単純に測定するとping（デフォルトだと1秒間隔）はnetperfの測定値の2倍以上の値を返すことがある
この記事の内容を踏まえて、測定感覚を過度に小さくせず1秒おきとすることにしました。
最初はいろんなインスタンスタイプで実行することを踏まえて、ポータビリティの高いGolangで測定ツールを作っていたのですが、同じ処理を1秒おきに繰り返しているだけにも関わらず、RDSへの接続から切断までのターンアラウンドタイムにバラつきが多いことに気づきました。tcpdumpのログを見ると、切断時にクライアントからFIN+ACKを送信するパターンといきなりRSTを送るパターンがあり、なぜかRDS側から切断されるケースもあって、ちょっと調べた程度では要因に辿り着けませんでした。いろいろ試して最後にPythonでPsycopg 3を使う場合が、一番安定したシーケンスを得られることに気づいたという感じです。
結果的には、ターンアラウンドタイム (TAT) はインスタンス内のオーバーヘッドによる変動が大きく、RTTとの相関が低くてレイテンシの判断には使えない、という結論になりましたが、同じ処理を書き直してはtcpdumpのログとの睨めっこで減っていく時間にめっちゃ焦りを感じてました。
分析について
Glue DataBrewのプロファイリング機能を使うとデータの統計値などが簡単に得られ、きれいなビジュアライゼーションで確認することができます。測定手法の妥当性を検証するにあたってDataBrewがとても便利だったので、本番の測定結果の分析でもDataBrewを使うつもりでレシピを作り込んでいたのですが、どうやらDataBrewは入力ファイル毎にレシピの処理を実行することはできなさそうでした。（ファイルごとにデータセットを作ればできるけど、ファイル数が1万以上あり非現実的）
これは私の理解が不十分だっただけで、データの前処理を目的とするサービスなのでそういうものではないと言われればそうかという気もしますが、残り数日といった段階で判明したので冷や汗ものでした。結果的にはS3からデータを全部DLして、Google ColabでPythonを使って分析することでなんとか分析に漕ぎ着けました。SageMaker Notebookインスタンスを起こす心の余裕すらなかったｗ
大量インスタンスの起動について
ガチャにあたっての大量インスタンスの起動には、Auto Scalingグループを使用しました。測定に必要なものが入ったカスタムAMIを用意しておいて、ユーザデータで測定パラメータを与えるようにしました。最初の様子見ではオンデマンドを使用していましたが、ほとんどがスポットインスタンスと考えていただいて良いと思います。スポット割り当て戦略は「料金キャパシティ最適化」で、vCPUは2つ以上、メモリは1GB以上のインスタンスタイプならよしとしましたが、a1.largeはインスタンスの起動時のチェックに時間がかかったあげく失敗することが多かったので除外しました。
曜日等による変動要因を考慮すると時間をかけて測定した方がよいのですが、何分時間がなく一晩ほどでの測定となりました。自分のアカウントでは同時起動可能なスポットインスタンス数が256台だったので、クォータの引き上げをリクエストしました。512台への引き上げは叶わず320台になりましたが、3時間ほどで対応いただけたので、途中から台数を増やして時短に繋げることができました。引き上げをお願いしたクォータの名称は「All Standard (A, C, D, H, I, M, R, T, Z) Spot Instance Requests」です。
最初は大量の台数のインスタンスを起動したまま寝ることに怯えてましたが、どっからか吹っ切れてました。とはいえ、個人アカウントでこの台数を見ることはもうない気がする。
以下に、IaCジェネレータで生成したCFnテンプレートを貼っておきます。念の為desiredは0にしてありますが、試される際はお気をつけください。
AutoScalingAutoScalingGroup00pankrationasg00pk1r6:
UpdateReplacePolicy: Retain
Type: AWS::AutoScaling::AutoScalingGroup
DeletionPolicy: Retain
Properties:
LoadBalancerNames: []
ServiceLinkedRoleARN: arn:aws:iam::<ACCOUNT_ID>:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling
CapacityRebalance: true
TargetGroupARNs: []
Cooldown: '300'
AvailabilityZones:
- us-west-2a
- us-west-2b
- us-west-2c
- us-west-2d
DesiredCapacity: '0'
HealthCheckGracePeriod: 300
MetricsCollection: []
MaxSize: '300'
NewInstancesProtectedFromScaleIn: false
MinSize: '0'
TerminationPolicies:
- Default
AutoScalingGroupName: pankration-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
Version: $Latest
LaunchTemplateName: pankration-instance
LaunchTemplateId: lt-0208b492a4fecd1b9
Overrides:
- InstanceRequirements:
CpuManufacturers:
- amazon-web-services
ExcludedInstanceTypes:
- a1.large
VCpuCount:
Min: 2
BurstablePerformance: included
MemoryMiB:
Min: 1024
MaxSpotPriceAsPercentageOfOptimalOnDemandPrice: 80
InstancesDistribution:
OnDemandAllocationStrategy: lowest-price
OnDemandBaseCapacity: 0
SpotAllocationStrategy: price-capacity-optimized
OnDemandPercentageAboveBaseCapacity: 0
VPCZoneIdentifier:
- !Ref EC2Subnet00subnet0c0ff9d9af211b8f200WjGG4
- !Ref EC2Subnet00subnet0145517ea9bb50ea20049JWu
- !Ref EC2Subnet00subnet0c091a56fc2517cc400S6NcM
- !Ref EC2Subnet00subnet0de1b50fa6e21ba61007a9Eu
DesiredCapacityType: units
Tags:
- Value: pankration
Key: Project
PropagateAtLaunch: true
HealthCheckType: EC2
検証結果について
今回の測定データからは、AZまたぎだと稀に3ミリ秒未満くらいのスパイクはあるものの、インスタンスをリプレースする必要があるようなものではないという結論に至りました。また、結論に影響するものではありませんが、スパイクのサイズについては、インスタンスタイプによっては検証台数が十分でなく、母集団の特性が捉えられていないのではないかと思われる点もありました。Bedrockで生成された要約は非常に素晴らしい精度で驚きましたが、この点についての記載が誤っている (due to a larger smaller sample size) のでご注意ください。
当初目標の10万台で評価できていればこの点もクリアになった可能性はありますが、その場合Configに50万円以上の課金が発生していたはずで想像するだけで恐ろしいです。
イベントについて
"No Border"というテーマを支える同時翻訳システムの開発、24時間イベントの企画から準備、運営と、メンバーのみなさんには感謝しかありません。イベント中も小板橋さんがリアルタイムでトラシューやエンハンスをされていたり、米澤さんがBedrockで要約を生成されていたりと驚きの連続でした。VoicePingのAsk the speakerコーナーも素晴らしく、海外のスピーカーや毎回足を運んでくれる吉江さんとオフラインのような感じでコミュニケーションが取れたのも驚きでした。
CBのSlackでProgram LeadのJasonがイベントを紹介してくれていましたが、終了後もグローバルのAPNブログのWeekly Roundupで紹介されていたり、Jeff Barrにも言及されていて、AWS関係者にも注目のイベントだったようです。
最後に豪華Swagを紹介！プレーリーカードはさっそくイベントで活用させていただきました。
登壇者の方のブログ
自分が見つけられたものを載せていますが、他にもあるよって方はコメントで教えてください。
Discussion