経緯
会社の人がGravitonがこの後重要になってくるからGraviton勉強してきてとAWSのアーキテクトの人にお願いした結果、
このワークショップを案内されて受けてきました。
受ける前の私
- GravitonってEC2みたいなAWSのサービスか何かか？って認識
- マルチアーキテクトって何がいいのか、流行ってるのかな
でてくる用語すらわかってない何もわかってない状態がスタート時点だった。
Gravitonからマルチアーキテクトの必要性について
Gravitonとは
GravitonはAmazonが設計したarmベースのプロセッサ
AWSのサービスで最適化されるように設計してるそう。
Appleが独自のプロセッサを作ったりしてるように
Amazonも他社に振り回される要素を減らしたいので、推してる。
てことは、Intelのx86系よりGravitonを搭載してるインスタンスの方を安く、性能もでるようになっていきそう。
使える状態にしていった方が受けれる恩恵はありそうである。
詳細は以下の資料に記載してあります。
[https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-Graviton_0430_v1.pdf]
CPUの差の影響
PCゲームなどで聞きますが、RyzenのCPUだとラグが発生するなどが起きます。
アプリケーションも同じでCPUがx86かarmかで動作が変わってきます。
今後使っていった方がいいGravitonはarm。
それに対して、2024/5時点でメインとなるCPUはIntelのx86。
CPUに差分があっても移行できるOR動作するアプリになっていけるのがベストになっていきそうです。
マルチアーキテクトとは
Dockerなどのコンテナサービスは以下をまとめてイメージ化してました。
- アプリケーション
- ライブラリ
- OS
マルチアーキテクトではこれにCPUが追加され、以下がセットになってます。
- アプリケーション
- ライブラリ
- OS
- CPU
ワークショップでは、CPUの種類ごとにNodePoolを定義しておくことによって、
たてるインスタンスがx86だったら、x86用の定義をもとにコンテナをたちあげてくれるようになります。
マルチアーキテクトに対応した場合のメリット
１番はスポットインスが有効に使えること
2024/5時点ではx86系のインスタンスの方がAWSのリソースは潤沢だそうです。
つまり、スポットインスタンスに割り当てられやすいです。
それに対して、オンデマンドインスタンスはarmの方が安いそうです。
そのため、マルチアーキテクト構成にすることによって、費用を抑えることができます。
CPUの移行検証ができること、性能最適になるかの検証ができること
armに移行していく際、過渡期に複数のCPU構成で動かしてくことによって、影響を少なくしながら検証ができます。
ハンズオンの概要
- 各CPUによるDockerイメージによるビルド
x86と異なり、armのイメージはどのように作るのかを実践できた - CPUの種類を指定したコンテナをそれぞれ立ち上げ
- 各CPUを定義するためのNodePoolsを作成
CPUごとのテンプレに依って、差分を吸収していると捉える - x86でもarmでも同じようにコンテナが立ったり、割合を決めて両のCPUが共存するクラスターを作る
全体でarmとx86が共存した環境を立ち上げるためのやり方を、ハンズオンで試していくことができます。
どのような定義をいれることによって、インスタンスを使い分けたり、差異を吸収したりできるのかを
作った環境で見比べながらできたので、差分から理解をしやすいワークショップでした。