要約

  • EC2 Macの課金単位は専用ホストで、最低割り当て期間は24時間。インスタンスの停止とホストの解放は別の操作になる。
  • 停止後の清掃では課金が一時停止する一方、同じホストで次のインスタンスを動かせない。料金が発生しない時間にも、納期上の価値がある。

ビルドが早く終わるのは良い知らせだ。ただし、そのために借りたMacを早く返せるとは限らない。EC2 Macでは、開発者の短い仕事が、最低24時間の専用ホスト割り当てを始めることがある。仕事の長さと注文の大きさがそろっていない。

AWSのEC2 FAQは、秒単位の課金と24時間の最低割り当て期間を並べて説明する。AWSはこの最低期間をAppleのmacOSソフトウェア使用許諾契約に対応するためとしている。最低期間を超えた後は、ホストを解放して、それ以降のホスト利用の約束を終えられる。

秒まで正確に測ることと、数秒分だけ注文できることは別だ。計器は細かくても、最初の注文には下限がある。コンパイラーの高速化で短くなるのは処理であって、その下限ではない。

クラウドに入っても、機械は一台

EC2 Macの製品文書によると、請求の単位はDedicated Hostで、そこで動くインスタンスに追加のインスタンス料金はない。一つのホストで動かせるMacインスタンスは一つ。ベアメタルとして提供され、Apple向けアプリの開発、ビルド、テスト、署名などに使える。

企業にとっては、自社の部屋に機材をそろえる前に、クラウド上の開発工程へMacを組み込める利点がある。その便利さと、短い仕事を細切れに買えるかどうかは、別々に評価した方がよい。

同じAWS組織内のアカウントや組織単位でホストを共有することはできる。しかし、共有設定で一台の中に複数のMacインスタンスが増えるわけではない。仕事の順番と、再利用してよい環境の範囲は、利用企業が決める必要がある。

ここで社内の原価計算が難しくなる。ある仕事が新しい割り当てを発生させ、別の仕事はすでに確保した枠を使う。実行時間が同じでも、購入を増やした程度は同じとは限らない。成功したビルドの分数だけで割り勘にすると、何のために一台を追加したのかが見えなくなる。

専用ホストの料金ページにも、EC2 Macは最低24時間の割り当て・課金期間と明記されている。他のホストに示された一般的な60秒の下限を、Macにも当てはめることはできない。該当するホストのオンデマンド課金を終える操作は、ホストの解放である。

無料で待つ時間がある

短い仕事を次々に処理したい企業には、もう一つの時計がある。停止・終了の手順では、Macインスタンスを停止または終了すると、ホスト上で内部SSDの消去、永続的なNVRAM変数のクリア、ファームウェア更新を含む清掃処理が走る。

ホストがpending状態に入ると計測と課金は止まり、この清掃時間の料金は請求されない。同時に、停止したインスタンスの起動も新しいインスタンスの起動も、清掃が終わってホストがavailableに戻るまで待つ。

請求上の空白と、工程上の空白が重なる。前者はうれしい。後者まで無料になったわけではない。次の仕事が急いでいるなら、待ち時間はその仕事の納期へ移る。

文書では、x86 Macの清掃は最大50分、ファームウェア更新が必要なら最大3時間、Apple silicon Macでは最大4.5時間かかる場合がある。毎回その長さを請求されたり待たされたりするという意味の数字ではない。停止直後に別の仕事へ切り替えられるとは限らない、という工程設計の材料だ。

清掃には役割がある。前の用途で残った記憶装置や設定の状態を、新しいプロジェクト名だけで消せるわけではない。節約のために省く工程として扱うより、必要な交代時間として予定に組み込む方が現実的である。

最低期間と清掃中の非課金は、両方とも購入判断に必要だ。特定の清掃時間を最低料金から単純に引く計算例は、今回の資料にはない。その金額は実際の状態履歴と請求で確かめることになる。少なくとも、割り当てられている時間、課金される時間、仕事を実行できる時間を一つの棒グラフに押し込むのは無理がある。

速い処理の前後に、遅い買い物

起動にも準備がある。AWS提供のイメージでは、接続できる状態になるまで約6〜20分とされ、EBSの容量、起動スクリプト、独自イメージのソフトウェアによって延び得る。ビルドのログが測るのは、この前後を除いた中央の仕事である。

互換性のある仕事を既存の割り当てへ集めると、ばらばらの要求ごとに新しい枠を買う機会を減らせる。一方で、環境や隔離の条件が合わない仕事を混ぜれば、別の問題を作る。高い利用率は、それだけでよい購買の証拠にはならない。

すぐ使える環境を残しておく選択にも価値がある。急なリリースを約束するチームと、順番待ちを受け入れるチームでは、求めるサービスが異なる。どちらも短いビルドだから同じ単価で扱える、と考えると、待つ側の時間が原価表から消える。

EC2 MacにはSpotやReserved Instancesはなく、Savings Plansで支出を下げる方法はある。値引きが扱うのは価格だ。清掃中のホストを今すぐ使える能力には変わらない。

実際の仕事の到着間隔と占有率、待つことの損失が分かれば、準備済み環境を保つか解放するかを比較できる。企業が買いたいのは処理した秒数だけなのか、それとも必要な瞬間に始められることなのか。そこが決まらない限り、どれほど精密な秒時計も、正しい注文書を書いてはくれない。