AWS Graviton に甘噛み乗り換え
64bit ARM CPUですが今流行りな感じですねぇ。
正直、転職間際にARMの話はお仕事でもよく出てきました特にAWS絡みで。ええ、笑い話系ですよ。メッチャあるあるなやつです。
M1 MACすげー！とか言ってますが、何がすげぇってIntelアーキテクチャのアプリがほぼ何も考えないので動いちゃうのが凄いんですよね。
なので錯覚されてるのか、そもそも知らないのかの二択っていうやつですがこの日本のIT業界はまず期待を裏切りません。
「安いのでGraviton 使いたい出ちゅー！」
んなバカな！？ と思われる方々、舐めてはいけません。コレは実話です。
CPUアーキテクチャの前に値段というまさにITジャパンテイストの独特の香ばしさです。実際、お安いけど早いCPUのインスタンスという認識で突っ走るわけです。
正直、「これ使いたいんですけど行けますかね？」事前に聞きにきてくれるのは良いのです。
「それ、多分動かないですよ。確認してください」とそーっと耳打ちしてあげられるうちは良いです。
「ARMを費用対効果と効率性から選定いたしました！」(ドヤ顔、ババーーン！）
とか大々的にやってしまうともういけません。プロジェクトの身内からも「それ動くんでしたっけ？」という声が上がっているのにぶち上げてしまうとかヤバいですよ。
最近のビックプロジェクトさんの入れてるミドルウェアは流石にARMとか抑えてるんだなぁとか言ってたら、そっちがまるで対応してないのにお客さんに「ドヤ顔 ババーン！」とかないわ・・・乗っけるアプリのリコンパイルは必要ですとかじゃなくて乗っける側がダメですが・・・
しかもご提案のご本人様たちが「えっ・・・同じLinux乗るのになんで動かないの」ですよ。
AMD64じゃないわよ、ARM64ですわよ・・・調べろや・・・
わかってます、わかってますよー。「これ盛ってるでしょ？面白おかしく言ってるだけでしょ」とか思われる方々。
でも、そんな方々いる一方でビタ一文盛ってないことが起きてしまうのもこの商い。できればそんな場面には出会いたくはないのですが、何故か後日酒の席のネタにこと欠かない出会いが豊富なのは体質なのでしょうか・・・
と、言ってはいますが自分もラズパイ工作とかやってないので、最近で触れたARMと言えばM1 MACぐらいだしM1 MACでゴリゴリ開発とかしてるわけではないのです。
なのでお恥ずかしながら体験も実践していないんですな。それに実際、インスタンスとして安いのも事実です。
例えば t3.mediumを使ってる場合の比較（※オンデマンド,東京リージョン）
t3.mediumのvCPU/メモリを基準に近しいARMインスタンスを列挙してみる
| インスタンスタイプ | 価格(USD/分) | vCPU | メモリ | ネットワークパフォーマンス | 日本円概算（110円換算/月:31日） | 備考 |
| t3.meduim | 0.0544 | 2 | 4GiB | 最大5ギガビット | 4453円 | 今ここ |
| a1.meduim | 0.0321 | 1 | 2GiB | 最大10ギガビット | 2628円 | AWS Graviton 第1世代 |
| a1.large | 0.0642 | 2 | 4GiB | 最大10ギガビット | 5254円 | AWS Graviton 第1世代 |
| t4g.small | 0.0216 | 1 | 2GiB | 最大5ギガビット | 1768円 | AWS Graviton 第2世代 |
| t4g.meduim | 0.0432 | 2 | 4GiB | 最大5ギガビット | 3536円 | AWS Graviton 第2世代 |
| t4g.large | 0.0864 | 2 | 8GiB | 最大5ギガビット | 7071円 | AWS Graviton 第2世代 |
| m6g.meduim | 0.0495 | 1 | 4GiB | 最大5ギガビット | 4051円 | AWS Graviton 第2世代 |
| m6g.large | 0.099 | 2 | 8GiB | 最大5ギガビット | 8102円 | AWS Graviton 第2世代 |
vCPU数、メモリ同容量搭載で同じようなタイプのインスタンスで比較すると露骨にさがるんだよなぁ。
基本的にOSはまず問題ない認識です。だって同じだもの。結局はどのように、何を動かすかによるわけです。
例えば、OSバンドルのパッケージで実現してる三階層（Web/AP/DB）ならまず動いちゃうんでしょうね。
ということで、せっかくDockerやっているしそっちで乗り換えてコスト下げつつ、甘噛み体験をしたいかなと思います。
dockerで動かしてみよう
Amazon Linux 2でdockerで動かすことを前提にしてやってみます。※急増テレワークの環境で対応できるかなを前提にします。
とりあえず利用しているコンテナがARMで動くかの確認ですね。
docher hubにアクセスして利用しているコンテナの対応状況を確認してみましょう、下の図のようにARM 64が含まれていることを確認します。
バージョンや利用したい機能別のコンテナでは対応してない場合もあるのでTagに移動して個別にも確認しておきます。
lastestは対応していることがわかります。
急増テレワークで利用している環境としては残念ながらrocket.chatは公式でARM対応のコンテナはないようです。Mongoは対応してます。
調べるとラズパイでrocket.chatをコンテナで動かすトピックなどあるので、コンテナのbuildを前提に対応すれば動かすことも可能なようです。
インスタンスの作成やらは、a1、t4g、m6gを選ぶだけで違いは何もないです。同じく、docker自体の導入も以前と同じでX86_64でもARMでも違いはないです。
コンテナ自体がARMに対応していれば、pullの時に対応しているコンテナを自然体にとってきてくれるのでこれも何も変わらない。
便利ですね。
【注意点１】
コンテナを移行する前にマッピングしたディレクトリを確認してホストから認識できるユーザ ID/グループ IDを確認しておくのが無難です。ユーザやグループがなければnologinで事前に作っておくと良いかと思います。
【注意点２】
dockerデーモン使うのに便利してるdocker-composeですが残念ながらARMに対応してません。以前に紹介したようにコマンドをダウンロードしてきても動きません。
調べてみると代わりの方法として、docker-compose自体をコンテナとして動かすことで対応ができるみたいです。
Release docker/compose image for armv7 / arm64v8
上のコメントのやり方そのままやるだけです。コマンドを実行すると、コンテナのpullが始まりますが動作ととしては変わりありません。
若干、動きがもっさりですが動くだけでもありがたいので贅沢は言わない。
sudo curl -L --fail https://raw.githubusercontent.com/linuxserver/docker-docker-compose/master/run.sh -o /usr/local/bin/docker-compose sudo chmod + x /usr/local/bin/docker-compose
今後を考えると本当はpodmanでの利用に変えていくのが良いんでしょうね。
RHELはdockerからpodmanに置き換えているし、podmanだとcomposeは使えないので。※アルにはあるんですが、サードパーティノーサンキューが方針らしいのでサポート外っぽい
実際に動かしてみると、以前よりも体感的に表示やレスポンスが早いです。きちんと数字で計測しないですんません、
単純にコストとしてもこれで安くできるのであればARMは選択肢としてはありなわけで、よほどレガシーな仕組みやパッケージミドルウェアさえなければ、新規で開発するなら選択肢としてはARMなんでしょうね。
