改めてEC2について学び直そう！〜「夏の Amazon EC2 祭り 2023 最新インスタンス活用編」参加レポート〜

みなさんEC2使ってますか？

EC2はサーバーの物理的な管理をAWSに一任できるIaaSサービスです。また、ECSなどのサービス基盤としても利用されています。
なので個人的には、今後サーバレスサービスが普及しても、裏でずっと動き続ける超重要サービスだと思っています。

そんなEC2について、改めて勉強できるオンラインセミナーがあったので参加しきました

https://pages.awscloud.com/eib-ec2-case-study-230720-reg.html

インスタンスの選び方からコスト最適化、AI基盤の話など盛りだくさんの内容でした！
EC2を改めて学び直したい方、ぜひこのレポートを読んでいただければと思います

※AMDさん、Intelさんのセッションもありましたが、自分の理解が全然追いつかなかったので割愛しています。。。

# まずは基本のおさらい！Amazon EC2 の概要とインスタンスタイプの選び方

- EC2とは
    - 必要な時に必要な計算リソースを確保可能な仮想サーバーサービス
    - サービス基盤は独自のNitro Systemを採用
    - 現在は600種類のインスタンスタイプを選ぶことができる
- インスタンスタイプの読み方
    - 以下の4要素からインスタンスタイプの名前が決まっている
        - インスタンスファミリー
            - 大まかなスペックの方向性
            - 汎用、コンピューティング最適化など、5つのカテゴリに分類可能
        - インスタンス世代
            - 数字が大きいほど新しい世代、高性能でコスパも良くなっている
        - 追加機能
            - 今までは付いたり付かなかったりしていたが、CPUタイプが増えてきたため、第6世代からはCPUタイプを表す記号(i,a,g)が必ず付与することになった
        - インスタンスサイズ
            - vCPUやメモリ、ネットワーク帯域など、インスタンスのスペックを表す
- インスタンスファミリーの種類
    - 選び方
        - 汎用タイプ（Mファミリー）を基準にすることがおすすめ
        - C,M,R
            - メモリ要件に合わせて選択
                - C：メモリが少なくていい場合
                - R：より大きいメモリが必要な場合
        - T
            - 一番安い、一定のスペックを提供できなくてもいい場合に使用
        - I,H,D
            - インスタンスストアを使用可能
            - 高速なディスクアクセスが必要な場合に選択
        - その他特殊なワークロード向け
            - 高速コンピューティング
                - 機械学習、グラフィクス、動画処理など
            - Macインスタンス
                - ベアメタルのみ提供
            - HPC最適化インスタンス
- インスタンスタイプ最適化のポイント
    - **「推測するな計測せよ」**
        - クラウドなら実際に検証を行うことが可能なので、本番ワークロードで実際に検証することを推奨する
    - 継続的なモニタリングと見直し
        - 新しい世代のインスタンスを積極的に使う、など
   


# Amazon のカスタムシリコン AWS Graviton プロセッサー

- Gravitonプロセッサ
    - AWSが自社開発しているプロセッサ
        - なぜ自社で開発するのか？
            - AWSの多種多様なサービスに最適なプロセッサが必要
            - サービス提供スピードの向上、運用の効率化を図る
            - 上記を合わせることで、さらなるイノベーションを提供することが可能になる！
    - 価格対性能比が非常に高い、安価に利用可能
    - エネルギー効率も非常に高い
        - Gravitonプロセッサを利用することでサスティナビリティにも貢献可能
    - 最新の世代はGraviton3、Graviton3E
- 技術的特徴
    - マネージドサービスでもGravitonを選択可能
        - マネージドサービスはプロセッサを意識することは少ない、そのためGravitonへの切り替えも非常に簡単にできる
    - ハイパフォーマンスの秘密
        - 1つのvCPUに対して1つの物理コアを割り当てる
            - Graviton以外は2つのvCPUに対して1つの物理コアを割り当てている
            - CPU負荷が非常に高い時であっても、ほぼ変わらないレイテンシを示す
                - AutoScalingに使うCPU使用率の閾値をギリギリに設定することが可能
- Graviton導入成功の秘訣
    - ターゲット
        - マネージドサービス
            - ECSやEKSも実はGravitonに向きである
        - その他普通に使用しているEC2ほぼ全てに対応可能
            - Windowsはarmプロセッサに対応していないのでGraviton使用不可
            - プログラムがコンパイル言語で書かれている場合は注意が必要
    - 利用時にはテクニカルガイドを参照
        - https://github.com/aws/aws-graviton-getting-started
    - 導入成功のために
        - 新規開発で使ってみる
        - 組織内のマインドセットを徐々に変えていく
            - マネージドサービスからGravitonを利用して心理的障壁をなくしていく
        - 検証を入念に実施する
            - ソースコードレベルでの自動チェックができるPorting Advisor for Gravitonを利用
                - https://aws.amazon.com/jp/about-aws/whats-new/2023/01/porting-advisor-graviton/



# HPCワークロードを加速するHPC インスタンスと構成パターン

- 2種類のHPCワークロードに分けて考える
- 密結合
    - 複数のノードを跨いでジョブを処理させる
    - 大規模なジョブを処理する場合に採用
    - ネットワーク遅延などが課題になってくる
    - 活用できるAWSサービス
        - EFA
            - 低レイテンシのネットワークアダプタ
        - FSx for Lustre
            - ハイパフォーマンスワークロードに対応可能
        - ParallelCluster
            - Linuxサーバーのクラスターを構成することができるサービス
        - HPC特化型EC2インスタンス
            - Hpcで始まるインスタンスタイプが該当
- 疎結合
    - ノード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
                - 高性能、低電力、低コストを両立したインスタンスタイプ
    - ネットワーク
        - 広帯域のインターコネクトが必要
            - 低レイテンシネットワークを使用できるEFAを活用
            - 上記のインスタンスでは、いずれもEFAを利用可能
                - 大規模モデルの学習には、Trn1n, P5タイプが特におすすめ

# Amazon EC2 コスト最適化 基礎編

- 最適化の観点
    - 設計の見直し
    - 購入オプション見直し
    - その他
        - 未使用インスタンスは停止 or 終了、起動時間のスケジュール管理
- 設計見直し
    - インスタンスタイプの再選定を行う
        - サイズ変更やファミリーの変更
        - 世代変更
        - CPUタイプ変更
            - Gravitonに変更すると、よりコストメリットが見込める
- 購入オプション見直し
    - スポットインスタンスの採用
        - 価格変動があるが、あくまで緩やかな変化にとどまっている
        - 「失敗に強いワークロード」に最適
        - スポットインスタンスアドバイザーを利用すると過去履歴に基づいたシミュレーションが可能
            - https://aws.amazon.com/jp/ec2/spot/instance-advisor/
    - 購入オプション採用案
        - SavingsPlan
            - 無停止、長期間利用に最適
            - データベースなど
        - SavingsPlanとスポットインスタンスの併用
            - 最低限の必要リソースはわかるが、負荷の増減がよく起こる場合に最適
            - WebサーバーやAPIサーバーなど
        - オンデマンドインスタンス
            - 最低限の必要リソースが読めない、長期利用をコミットしにくい、などの場合に最適
            - ビデオストリーミングサービスなど
    - Cost Explorerの活用
        - 「サイズの適正化に関する推奨事項」を利用することで、推奨事項の提案を受けることができる
        - 利用時は有効化する必要がある
    - Instance Schedulerの活用
        - インスタンスの停止時間がわかっていれば、その時間にインスタンス自動停止を実装可能
        - CFnテンプレートが提供されている
            - https://aws.amazon.com/jp/solutions/implementations/instance-scheduler-on-aws/

# スタディサプリ/Quipperを支えるデータベースをGravitonへ移行せよ! ところでインスタンスストアの性能は大丈夫? 気になったので検証してみた

- インフラ構成
    - 巨大なEC2上で稼働するMongoDBが今回のターゲット
        - i3en.24xlargeを使用していた
- インスタンス選定
    - 性能要件を洗い出した結果、インスタンスストアがあるインスタンスファミリーを選定した
        - EBSへの乗り換えも検討したが、コスト高になるため断念
    - 複数インスタンスを実際に利用し、パフォーマンス性能を比較した
        - Gravitonが一番コスト最適化が見込める結果となったため、Gravitonを採用
    - アプリケーションのベンチマークにはDatadog Notebookを利用
- 移行に際して
    - 注意点
        - Ansibleがx86前提で作成されていたため、Graviton向けに書き換えた
    - 移行実施の結果、特に問題なく動いた！
    - MongoDBトータルで70%のコスト減に成功！

# 新しいインスタンスタイプを活用して賢くコスト削減する方法

- インスタンスタイプを新しい世代に変更するメリット
    - アプリケーションの変更が不要
        - CPUアーキテクチャが同じである場合はプログラムの改修が不要になる
    - 利用料金を安くできる（可能性がある）
        - インスタンスタイプを変更する見込みがある場合は、Compute Saving Plansがおすすめ
            - 割引率が高い
            - インスタンスタイプの変更にも対応可能
    - 性能が向上する
        - 性能比較を実施した結果、新しいインスタンスタイプの方が性能向上することがわかった
- 注意点
    - ENAドライバのバージョン
        - ENAドライバのバージョンアップが必要な場合がある
        - バージョンアップしないと正常に起動できなかったり、パフォーマンスに問題が起こったりする
    - 対応OSの確認
        - Amazon Linuxは対応範囲広め
        - 対応していない場合は、インスタンスタイプを変更できずエラーが表示される
    - 対応リージョンとAZの確認
        - 東京リージョンでも利用できないインスタンスタイプがあるが、アップデートも頻繁にあるので情報はチェックしておくべき
    - EBS帯域幅の確認
        - 帯域幅が下がることがあるので注意

# ニコンの光学設計におけるAWS ParallelClusterの利用事例

- 光学シミュレーションについて
    - シミュレーションを実施し、開発中の製品の評価している
    - オンプレでクラスターを組んでいたが、混雑してしまい処理できないジョブが発生してしまった
    - シミュレーションにかかる時間とコストを削減したい
- ParallelClusterの採用
    - オンプレからの移行
        - ジョブ管理システムをSlurmに移行すればOK、意外と簡単だった
        - クラスター規模も柔軟に変更可能、高速化も見込める
        - 現在はオンプレとAWSを並行運用し、徐々に移行している
    - 運用
        - クラスターにユーザーデータを持たせないアーキテクチャに変更
        - 新しいインスタンスタイプ、ParallelClusterの新バージョンを気軽に試せるようになった
    - 管理ノードインスタンス
        - シミュレーションを実行しないので処理性能がそこまで高くないT系インスタンスを採用
    - 計算ノードインスタンス
        - バッチ処理を実行
        - インスタンスタイプは限定せず、ユーザー側で都度選択できる方式に
    - 課題に対する効果
        - ピーク時でも十分な計算ノード数を確保できるようになった
        - 年間の予算も半分に！