- EC2インスタンスのブート時間を40秒から5秒に短縮することが可能
- これは、特定のジョブを処理するために新しいEC2インスタンスが必要な場合に非常に重要
ブート時間が長くかかる理由
- 新しいEC2インスタンスをリクエストすると、AWSは複数の処理を行う:
- 選択したAMIからルートEBSボリュームを作成
- インスタンスにプライベートIPアドレスを割り当て
- インスタンス用のホストを選択
- 実際にマシンをブート
- ハードウェアの電源が入った後も、ブートローダー、カーネル、ユーザー空間プロセスが起動する必要がある。
問題を回避する方法
- 待機中のコンピューティングプールを運用し、ビルド要求をすでに実行中のEC2インスタンスへルーティングする。
- しかし、すべてのジョブに対して経済的に成り立つわけではない。
- GitHub Actionsランナーの場合、各ジョブは専用のEC2インスタンスにルーティングされる。
- 50件の並列ジョブを処理するために50台のEC2インスタンスをオンラインのまま維持するのは現実的ではない。
より速いブート時間
- 特定のジョブに対して不要な処理をしないことが、常に最も速い。
- EC2インスタンスの作成、ブート、アプリケーション起動の各段階を体系的に最適化する。
- インスタンスを一度ブートし、停止した後、必要なときに再びブートする方法を使う。
EBSルートボリュームのストリーミング
- EBSルートボリュームの準備は、EC2インスタンスのブート時間とアプリケーション性能に大きな影響を与える。
- AMIからEBSボリュームを作成する際、データブロックは最初にアクセスされたときにS3から取得される必要がある。
- AWSはすべてのデータブロックを事前にロードする方法を推奨している。
インスタンスを一度だけブートする
- EBS対応インスタンスは停止後に再起動できる。
- 停止したインスタンスでは構成だけが保持され、ルートEBSボリュームの料金のみを支払う。
- インスタンスを一度ブートして初期化処理を実行した後に停止すると、「ウォーム済み」のEBSルートボリュームが作られる。
オートスケーリングのウォームプール
- AWSはEC2 Auto Scaling向けにウォームプールを提供している。
- ただし、オートスケーリンググループはリクエストに反応するまでに時間がかかる。
- 最良の性能を得るために、LaunchInstancesおよびStartInstances API呼び出しを使ってEC2インスタンスを直接起動する。
インスタンスサイズの調整
- ウォーム済みインスタンスのタイプを変更してブート時間を最適化する。
- 初期化処理には安価なインスタンスタイプを使い、実際のジョブ実行時にはより高性能なインスタンスタイプへ変更する。
全体のフロー
- GitHub Actionsランナーインスタンスは次のようなフローをたどる:
t3.largeインスタンスとして作成- 対象VPCにプライベートIPアドレスを割り当て
- カーネルおよびユーザー空間プロセスを一度起動
- インスタンスを停止
- ジョブ要求が到着したら、インスタンスタイプを
m7aに更新して起動
m7aインスタンス容量がない場合は、バックアップタイプに更新して再起動
- このフローにより、ジョブ向けインスタンスの準備時間が40秒から5秒に短縮される。
1件のコメント
Hacker Newsの意見
要約