Mythexのサーバーを、ARMに移した理由

9月19日、Mythexの本番バックエンドを、x86サーバーから、より小さなARMベースのAWS Gravitonサーバーへ移しました。データベースも、プラットフォームのデータベースをGravitonのインスタンスへ移しました。きっかけは単純でした。各ユーザーのアプリを実行・ビルドする重い処理を、分離されたプロジェクトごとのサンドボックスに移した後、メインのサーバーのメモリ使用量はピーク時でおよそ3分の1でした。より小さいARMマシンのほうが実際の負荷に合い、月額のサーバー費用を約30%下げられました。

今、サーバーは実際に何をしているのか

以前は、バックエンドのサーバーが多くの作業を直接行っていました。9月半ばごろ、高コストな部分、つまり各プロジェクトのコードの実行、パッケージのインストール、アプリのビルドを、プライベートなクラウドサンドボックス、プロジェクトごとに1つに移し終えました。これにより、各プロジェクトは独立した環境とライブプレビューを持てるようになりました。

自分たちのサーバーに残ったのは、調整の役割です。APIやサンドボックスと公開を管理するオーケストレーター、認証、課金、ゲートウェイです。この作業は安定していて軽いものです。移行後、サーバーのピークは約1.3 GBのメモリで、その3倍ほどの容量のマシンで動いていました。

なぜARMなのか

AWSのGravitonプロセッサは、AWSが設計したARMチップです。同じ費用で、一般に同等のx86インスタンスより多くの処理能力が得られるか、同じ処理能力をより安く得られます。Node.jsのサービス、Docker、Postgresといった私たちのワークロードには、x86に縛られる理由がありません。

移したものは次のとおりです。

アプリサーバー2台：中規模のx86インスタンスから、それぞれ2 GBのメモリを持つ小さなGravitonインスタンスへ。
プラットフォームのデータベース：小さなx86データベースインスタンスから、そのGraviton版へ。

唯一の本当の難点：2つのアーキテクチャ向けのイメージ

ステージング環境は、今も小さなx86サーバーで動いています。本番はARMで動いています。一方のアーキテクチャ向けにビルドされたコンテナイメージは、もう一方では動きません。

そこで、すべてのイメージを、1つのタグの下で両方のアーキテクチャ向けにビルドするようにしました。マルチアーキテクチャのイメージです。Dockerが各マシンで適切なバリアントを自動的に選ぶため、デプロイパイプラインは、どの環境へプッシュしているかを知る必要がありません。代償はCIのビルドが長くなることです。得られるのは、ステージングと本番が、まったく同じタグから、まったく同じコードを実行することです。

移行の前に、ロールバックを計画する

稼働中のサービスのCPUアーキテクチャを変えることは、数分で元に戻せるようにしておきたい種類の変更です。切り替えの前に、次のことを行いました。

以前のサーバーテンプレートのバージョンを、名前付きのロールバック先として残しました。
データベースのサイズを変更する直前に、データベースのスナップショットを取りました。
移行とその巻き戻し方法をカバーするランブックを書きました。

ロールバックは必要になりませんでした。それでも、同じやり方を繰り返すでしょう。

注意すべき点

小さなサーバーは、余裕が少なくなります。そこから次の2つが生じます。

重い処理がこれらのサーバーに戻されると、2 GBでは足りません。 その場合の対処は、x86に戻すことではなく、より大きなGravitonのサイズにすることです。
小さなマシンにはスワップが必要です。 1週間後、これらのサーバーの1台が、技術的にはメモリ不足にならないまま、メモリの圧迫で凍結しました。スワップファイルがなかった話をご覧ください。

得られた教訓

アーキテクチャを変えたら、もう一度測定してください。 重い処理をサンドボックスに移したことで、サーバーに必要なものが変わりましたが、インスタンスのサイズはそれに追いついていませんでした。
マルチアーキテクチャのイメージを使えば、ARMは一般的なウェブのスタックにとって低リスクな勝ちになります。
先にロールバックを書いてください。 使わなかったとしても、変更はより落ち着いたものになります。