Amazon Web Services ブログ
AWS Amplify Hosting のアップグレードされたビルドインスタンス
AWS Amplify Hosting では、決められたインスタンスを使用してウェブアプリケーションを構築してきました。アプリケーションが複雑化し、依存関係管理、アセット最適化、包括的なテストに集中的なビルドプロセスが必要とされるようになると、開発者は生産性とデプロイ速度を維持するために、より強力なビルド環境を必要とするようになります。
Amplify Hosting のビルド環境用のインスタンスをカスタマイズできるようになったことを喜んでお知らせします。この更新により、2 つの新しいインスタンスサイズ (Large, XLarge) が追加され、メモリと CPU リソースが増強されました。開発チームは、これで特定のニーズに合わせて構築リソースをスケーリングできるようになりました。これは特に、大規模な依存関係ツリーの処理、多数の静的アセットの処理、TypeScript コンパイルやパラレルなテストフレームワークのような、メモリ集約的な操作の実行時に有用です。
今までのビルド環境用のインスタンスの課題
大規模なアプリケーションを構築し、重たいワークロードを実行しているお客様は、ビルド時間が長くなり、メモリエラーのため CI/CD が遅くなりビルド失敗が発生することがあります。開発チームが Amplify Hosting を導入する際、さまざまなワークロードに対応できるスケーラブルなビルド環境を求めています。ビルド時間の最適化は存在しますが、8GiB メモリと 4 vCPU のインスタンスサイズのコンテナ構成では、アプリケーションの拡大に限界があります。物理メモリに比べ、仮想メモリ (スワップスペース) の性能ペナルティは非常に大きく、固定環境内でコンピューティング容量やストレージを拡張する効果的な手段はありません。これらのハードウェア上の制約により、ソフトウェアの最適化だけでは根本的な障壁を乗り越えることはできません。
カスタマイズ可能なビルドインスタンスの紹介
Amplify Hosting の新しいカスタマイズ可能なビルドインスタンスにより、開発者はアプリケーションのニーズに最適なコンピューティングリソースを選択できるようになりました。これにより、リソースの制約を排除して、予測可能なビルドパフォーマンスを実現できます。Standard ビルドインスタンスに加えて、Large と XLarge のインスタンスを導入しました。次の表は、Amplify Hosting のすべてのビルドインスタンスオファリングの仕様をまとめたものです。
ビルドインスタンスの仕様
ビルド インスタンス | vCPU 数 | メモリ | ディスク領域 |
---|---|---|---|
Standard | 4 | 8 GiB | 128 GB |
Large | 8 | 16 GiB | 128 GB |
XLarge | 36 | 72 GiB | 256 GB |
アプリ作成時または既存のアプリを後から更新する際に、アプリケーションレベルでビルドインスタンスを構成できます。更新された構成は、アプリのすべてのブランチに適用され、ビルド間でアプリのビルドインスタンスサイズを変更します。ビルドをトリガーしたとき、ブランチに関係なく、アプリのビルドでは、アプリレベルで構成したビルドインスタンスサイズが使用されます。新しいアプリを作成したり、既存のアプリを更新したりするときに、ビルドインスタンスサイズを構成できます。
- Amplifyコンソールを通じて新しいアプリのビルドインスタンスサイズをカスタマイズするには:アプリ設定ステップの間に、下にスクロールして「詳細設定」をクリックします。ドロップダウンリストから、アプリに設定したいビルドイメージを選択します。

図1 – 新しいアプリのビルドインスタンスサイズの設定
- 既存のアプリのビルドインスタンスサイズを Amplify コンソールから変更するには : アプリに移動し、ホスティングタブを開いてから、ビルドの設定を選択します。詳細設定までスクロールダウンし、編集をクリックします。ドロップダウンから、アプリをアップデートしたい ビルドイメージ を選択してください。

図2 – 既存アプリのビルドインスタンスの変更
注: ビルドインスタンスの割り当て処理には、ビルドが開始される前に追加のプロビジョニング時間が必要になる場合があります。大規模なインスタンス、特に XLarge の場合、このオーバーヘッドの時間によりビルド開始前に遅延が発生することがあります。ただし、課金されるのはビルド時間のみで、オーバーヘッド時間は課金されません。
パフォーマンステストの説明
次に、100 を超える静的ページを生成する Next.js アプリケーションを使用して、より強力なインスタンスの価値を実証します。このアプリを Amplify Hosting にデプロイする手順をガイドし、メモリ関連のビルド失敗をデバッグする方法を説明し、アプリケーションのメモリ要件を満たすためにビルドインスタンスをアップグレードする方法をご紹介します。
まず、デフォルト設定を使用して静的アプリを Amplify Hosting にデプロイします。

図3 – アプリページを確認して作成する
デプロイが始まると、Amplify Hosting がリソースをプロビジョニングし、デプロイを進めます。

図4 – デプロイ中
大容量メモリの使用のためのアプリケーションの構成
デプロイが開始されると、最初のビルドで JavaScript のヒープメモリ不足のエラーが発生します。ランタイム環境がヒープメモリを要求すると、ホストの OS がメモリを割り当てます。JavaScript の Node.js V8 ランタイム環境には、ホストのメモリサイズなどの複数の条件によりデフォルトのヒープサイズ制限が適用されています。そのため、Standard と Large インスタンスではデフォルトの Node.js ヒープサイズが 2096MB ですが、XLarge インスタンスでは 4144 MB になっています。

図5 – ヒープサイズのメモリ制限により Deployment 1 が失敗しました
Node.js のデフォルト ヒープメモリ制限の問題を解決するには、ヒープサイズを増やす必要があります。アプリは 8 GiB のメモリを持つ Standard ビルドインスタンスを使用しているため、ヒープサイズを 7000 MB (約 7 GB) に増やす必要があります。これにより、他のプロセスで使用するために、オペレーティングシステム用に約 1 GB のメモリが残ります。そうすれば、意図しない動作を回避できます。
次に、以下のコマンドでビルド仕様を変更し、Node.js のヒープメモリ制限を増やします。
export NODE_OPTIONS ='--max-old-space-size = 7000'
代わりに、NODE_OPTIONS
はアプリ内の環境変数として設定することもできます。詳細については、ドキュメントを参照してください。
これらの変更に対応するように、ビルド仕様ファイルも次のように更新します:
version: 1
frontend:
phases:
preBuild:
commands:
# Set the heap size to 7000 MB
- export NODE_OPTIONS ='--max-old-space-size = 7000'
# To check the heap size memory limit in MB
- node -e "console.log('Total available heap size (MB):', v8.getHeapStatistics().heap_size_limit / 1024 / 1024)"
- npm ci --cache .npm --prefer-offline
build:
commands:
- npm run build
artifacts:
baseDirectory: .next
files:
- '**/*'
cache:
paths:
- .next/cache/**/*
- .npm/**/*
変更したヒープサイズで新しいデプロイをトリガするには、Deployment ページに移動し、Redeploy this version ボタンをクリックします。
しかし、アプリのビルドはまだ失敗します。今度は「Total available heap size (MB): 7048」というログが表示され、ヒープサイズが増えたことを確認できます。興味深いことに、SIGKILL ディレクティブも表示され、オペレーティングシステムがビルドプロセスを強制終了したことがわかります。これは別のメモリ不足エラーを示しています。

図6 – メモリ不足のためデプロイ2が失敗しました
ビルドインスタンスのアップグレード
標準インスタンスのメモリ制限は 8 GiBであり、ヒープサイズをこの制限に近づけて増やしたにもかかわらず、依然としてメモリ不足になっています。この問題を解決するために、ビルドインスタンスを Large にアップグレードします。これにより、ビルドプロセスにより多くのメモリを割り当てることができます。
以下のようにビルド仕様ファイルを更新して、Large インスタンスにデプロイします:
version: 1
frontend:
phases:
preBuild:
commands:
# Set the heap size to 14000 MB
- export NODE_OPTIONS ='--max-old-space-size = 14000'
# To check the heap size memory limit in MB
- node -e "console.log('Total available heap size (MB):', v8.getHeapStatistics().heap_size_limit / 1024 / 1024)"
- npm ci --cache .npm --prefer-offline
build:
commands:
- npm run build
artifacts:
baseDirectory: .next
files:
- '**/*'
cache:
paths:
- .next/cache/**/*
- .npm/**/*
ホスティングタブを開き、ビルド設定を選択して、ビルドインスタンスを更新します。その後、詳細設定までスクロールダウンして編集をクリックします。ドロップダウンから、ビルドイメージを「Large」に選択します。

図7 – ビルドインスタンスのサイズを「Large」に更新
次に、Deployment トページで「このバージョンを再デプロイ」をクリックして、Large インスタンスで新しい Deployment を作成します。また、ビルドログの最初の行にビルドインスタンスの仕様が表示されていることに気付きます。

図8 – Large ビルドインスタンスで進行中のデプロイ3
アプリが正常にデプロイされたことが確認できます。

図9 – アプリのデプロイ完了
まとめ
このブログでは、ビルドインスタンスサイズを設定するためのアプリワークフローの作成と更新方法、および Amplify Hosting でホストされているプロジェクトのメモリ問題を解決する方法について探ってきました。ビルドインスタンスサイズについてさらに詳しく知り、この機能についてもっと学ぶには、Amplify Hosting のドキュメントをご覧ください。ビルドインスタンスの料金に関する情報は、料金ページでご確認いただけます。