経緯
会社の人が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が共存した環境を立ち上げるためのやり方を、ハンズオンで試していくことができます。 どのような定義をいれることによって、インスタンスを使い分けたり、差異を吸収したりできるのかを 作った環境で見比べながらできたので、差分から理解をしやすいワークショップでした。
