みなさんEC2使ってますか？
EC2はサーバーの物理的な管理をAWSに一任できるIaaSサービスです。また、ECSなどのサービス基盤としても利用されています。
なので個人的には、今後サーバレスサービスが普及しても、裏でずっと動き続ける超重要サービスだと思っています。
そんなEC2について、改めて勉強できるオンラインセミナーがあったので参加しきました
インスタンスの選び方からコスト最適化、AI基盤の話など盛りだくさんの内容でした！
EC2を改めて学び直したい方、ぜひこのレポートを読んでいただければと思います
※AMDさん、Intelさんのセッションもありましたが、自分の理解が全然追いつかなかったので割愛しています。。。
まずは基本のおさらい！Amazon EC2 の概要とインスタンスタイプの選び方
- EC2とは
- 必要な時に必要な計算リソースを確保可能な仮想サーバーサービス
- サービス基盤は独自のNitro Systemを採用
- 現在は600種類のインスタンスタイプを選ぶことができる
- インスタンスタイプの読み方
- 以下の4要素からインスタンスタイプの名前が決まっている
- インスタンスファミリー
- 大まかなスペックの方向性
- 汎用、コンピューティング最適化など、5つのカテゴリに分類可能
- インスタンス世代
- 数字が大きいほど新しい世代、高性能でコスパも良くなっている
- 追加機能
- 今までは付いたり付かなかったりしていたが、CPUタイプが増えてきたため、第6世代からはCPUタイプを表す記号(i,a,g)が必ず付与することになった
- インスタンスサイズ
- vCPUやメモリ、ネットワーク帯域など、インスタンスのスペックを表す
- インスタンスファミリー
- 以下の4要素からインスタンスタイプの名前が決まっている
- インスタンスファミリーの種類
- 選び方
- 汎用タイプ（Mファミリー）を基準にすることがおすすめ
- C,M,R
- メモリ要件に合わせて選択
- C：メモリが少なくていい場合
- R：より大きいメモリが必要な場合
- メモリ要件に合わせて選択
- T
- 一番安い、一定のスペックを提供できなくてもいい場合に使用
- I,H,D
- インスタンスストアを使用可能
- 高速なディスクアクセスが必要な場合に選択
- その他特殊なワークロード向け
- 高速コンピューティング
- 機械学習、グラフィクス、動画処理など
- Macインスタンス
- ベアメタルのみ提供
- HPC最適化インスタンス
- 高速コンピューティング
- 選び方
- インスタンスタイプ最適化のポイント
-
「推測するな計測せよ」
- クラウドなら実際に検証を行うことが可能なので、本番ワークロードで実際に検証することを推奨する
- 継続的なモニタリングと見直し
- 新しい世代のインスタンスを積極的に使う、など
-
「推測するな計測せよ」
Amazon のカスタムシリコン AWS Graviton プロセッサー
- Gravitonプロセッサ
- AWSが自社開発しているプロセッサ
- なぜ自社で開発するのか？
- AWSの多種多様なサービスに最適なプロセッサが必要
- サービス提供スピードの向上、運用の効率化を図る
- 上記を合わせることで、さらなるイノベーションを提供することが可能になる！
- なぜ自社で開発するのか？
- 価格対性能比が非常に高い、安価に利用可能
- エネルギー効率も非常に高い
- Gravitonプロセッサを利用することでサスティナビリティにも貢献可能
- 最新の世代はGraviton3、Graviton3E
- AWSが自社開発しているプロセッサ
- 技術的特徴
- マネージドサービスでもGravitonを選択可能
- マネージドサービスはプロセッサを意識することは少ない、そのためGravitonへの切り替えも非常に簡単にできる
- ハイパフォーマンスの秘密
- 1つのvCPUに対して1つの物理コアを割り当てる
- Graviton以外は2つのvCPUに対して1つの物理コアを割り当てている
- CPU負荷が非常に高い時であっても、ほぼ変わらないレイテンシを示す
- AutoScalingに使うCPU使用率の閾値をギリギリに設定することが可能
- 1つのvCPUに対して1つの物理コアを割り当てる
- マネージドサービスでもGravitonを選択可能
- Graviton導入成功の秘訣
- ターゲット
- マネージドサービス
- ECSやEKSも実はGravitonに向きである
- その他普通に使用しているEC2ほぼ全てに対応可能
- Windowsはarmプロセッサに対応していないのでGraviton使用不可
- プログラムがコンパイル言語で書かれている場合は注意が必要
- マネージドサービス
- 利用時にはテクニカルガイドを参照
- 導入成功のために
- 新規開発で使ってみる
- 組織内のマインドセットを徐々に変えていく
- マネージドサービスからGravitonを利用して心理的障壁をなくしていく
- 検証を入念に実施する
- ソースコードレベルでの自動チェックができるPorting Advisor for Gravitonを利用
- ターゲット
HPCワークロードを加速するHPC インスタンスと構成パターン
- 2種類のHPCワークロードに分けて考える
- 密結合
- 複数のノードを跨いでジョブを処理させる
- 大規模なジョブを処理する場合に採用
- ネットワーク遅延などが課題になってくる
- 活用できるAWSサービス
- EFA
- 低レイテンシのネットワークアダプタ
- FSx for Lustre
- ハイパフォーマンスワークロードに対応可能
- ParallelCluster
- Linuxサーバーのクラスターを構成することができるサービス
- HPC特化型EC2インスタンス
- Hpcで始まるインスタンスタイプが該当
- EFA
- 疎結合
- ノード1つにつき複数のジョブを処理させる
- 小規模な処理を大量に実行する
- ノード間通信がないのでスケールしやすい
- 計算リソースのキャパシティ管理やコスト管理が課題になる
- AWS Batch
- コンテナベースのバッチ処理サービス
- スケジューラー、計算ノードの管理をマネージドに利用できる
- ECS、EKSどちらも採用できる
- コンピューティングプラットフォームとしてはEC2とFargateいずれも選択可能
- コンテナベースのバッチ処理サービス
- R7izインスタンス：疎結合ワークロードに最適なインスタンス
- スポットインスタンス
- AWSの空きキャパシティを使用するので安く利用できるが、中断が発生する可能性が高い
- AWS Batchでスポットインスタンスを活用することができる
生成系AI の学習向け Amazon EC2 の選択肢
- 大規模学習を支える技術
- コンピュート
- 大容量デバイスメモリ、高速アクセラレータが必要
- 適するインスタンスの種類
- NVIDIA GPU搭載インスタンス
- P4d/P4de, P5(プレビュー)
- intel Habana Gaudi 搭載インスタンス
- DL1
- AWS Trainium搭載インスタンス
- Trn1/Trn1n
- 高性能、低電力、低コストを両立したインスタンスタイプ
- NVIDIA GPU搭載インスタンス
- ネットワーク
- 広帯域のインターコネクトが必要
- 低レイテンシネットワークを使用できるEFAを活用
- 上記のインスタンスでは、いずれもEFAを利用可能
- 大規模モデルの学習には、Trn1n, P5タイプが特におすすめ
- 広帯域のインターコネクトが必要
- コンピュート
Amazon EC2 コスト最適化 基礎編
- 最適化の観点
- 設計の見直し
- 購入オプション見直し
- その他
- 未使用インスタンスは停止 or 終了、起動時間のスケジュール管理
- 設計見直し
- インスタンスタイプの再選定を行う
- サイズ変更やファミリーの変更
- 世代変更
- CPUタイプ変更
- Gravitonに変更すると、よりコストメリットが見込める
- インスタンスタイプの再選定を行う
- 購入オプション見直し
- スポットインスタンスの採用
- 価格変動があるが、あくまで緩やかな変化にとどまっている
- 「失敗に強いワークロード」に最適
- スポットインスタンスアドバイザーを利用すると過去履歴に基づいたシミュレーションが可能
- 購入オプション採用案
- SavingsPlan
- 無停止、長期間利用に最適
- データベースなど
- SavingsPlanとスポットインスタンスの併用
- 最低限の必要リソースはわかるが、負荷の増減がよく起こる場合に最適
- WebサーバーやAPIサーバーなど
- オンデマンドインスタンス
- 最低限の必要リソースが読めない、長期利用をコミットしにくい、などの場合に最適
- ビデオストリーミングサービスなど
- SavingsPlan
- Cost Explorerの活用
- 「サイズの適正化に関する推奨事項」を利用することで、推奨事項の提案を受けることができる
- 利用時は有効化する必要がある
- Instance Schedulerの活用
- インスタンスの停止時間がわかっていれば、その時間にインスタンス自動停止を実装可能
- CFnテンプレートが提供されている
- スポットインスタンスの採用
スタディサプリ/Quipperを支えるデータベースをGravitonへ移行せよ! ところでインスタンスストアの性能は大丈夫? 気になったので検証してみた
- インフラ構成
- 巨大なEC2上で稼働するMongoDBが今回のターゲット
- i3en.24xlargeを使用していた
- 巨大なEC2上で稼働するMongoDBが今回のターゲット
- インスタンス選定
- 性能要件を洗い出した結果、インスタンスストアがあるインスタンスファミリーを選定した
- EBSへの乗り換えも検討したが、コスト高になるため断念
- 複数インスタンスを実際に利用し、パフォーマンス性能を比較した
- Gravitonが一番コスト最適化が見込める結果となったため、Gravitonを採用
- アプリケーションのベンチマークにはDatadog Notebookを利用
- 性能要件を洗い出した結果、インスタンスストアがあるインスタンスファミリーを選定した
- 移行に際して
- 注意点
- Ansibleがx86前提で作成されていたため、Graviton向けに書き換えた
- 移行実施の結果、特に問題なく動いた！
- MongoDBトータルで70%のコスト減に成功！
- 注意点
新しいインスタンスタイプを活用して賢くコスト削減する方法
- インスタンスタイプを新しい世代に変更するメリット
- アプリケーションの変更が不要
- CPUアーキテクチャが同じである場合はプログラムの改修が不要になる
- 利用料金を安くできる（可能性がある）
- インスタンスタイプを変更する見込みがある場合は、Compute Saving Plansがおすすめ
- 割引率が高い
- インスタンスタイプの変更にも対応可能
- インスタンスタイプを変更する見込みがある場合は、Compute Saving Plansがおすすめ
- 性能が向上する
- 性能比較を実施した結果、新しいインスタンスタイプの方が性能向上することがわかった
- アプリケーションの変更が不要
- 注意点
- ENAドライバのバージョン
- ENAドライバのバージョンアップが必要な場合がある
- バージョンアップしないと正常に起動できなかったり、パフォーマンスに問題が起こったりする
- 対応OSの確認
- Amazon Linuxは対応範囲広め
- 対応していない場合は、インスタンスタイプを変更できずエラーが表示される
- 対応リージョンとAZの確認
- 東京リージョンでも利用できないインスタンスタイプがあるが、アップデートも頻繁にあるので情報はチェックしておくべき
- EBS帯域幅の確認
- 帯域幅が下がることがあるので注意
- ENAドライバのバージョン
ニコンの光学設計におけるAWS ParallelClusterの利用事例
- 光学シミュレーションについて
- シミュレーションを実施し、開発中の製品の評価している
- オンプレでクラスターを組んでいたが、混雑してしまい処理できないジョブが発生してしまった
- シミュレーションにかかる時間とコストを削減したい
- ParallelClusterの採用
- オンプレからの移行
- ジョブ管理システムをSlurmに移行すればOK、意外と簡単だった
- クラスター規模も柔軟に変更可能、高速化も見込める
- 現在はオンプレとAWSを並行運用し、徐々に移行している
- 運用
- クラスターにユーザーデータを持たせないアーキテクチャに変更
- 新しいインスタンスタイプ、ParallelClusterの新バージョンを気軽に試せるようになった
- 管理ノードインスタンス
- シミュレーションを実行しないので処理性能がそこまで高くないT系インスタンスを採用
- 計算ノードインスタンス
- バッチ処理を実行
- インスタンスタイプは限定せず、ユーザー側で都度選択できる方式に
- 課題に対する効果
- ピーク時でも十分な計算ノード数を確保できるようになった
- 年間の予算も半分に！
- オンプレからの移行