Toolmapソフトウェアの地図。制約つきで。
実行基盤・ホスティング 種別：マネージドサービス 成熟度 成長中 学習コスト 中

Fly.io

Dockerイメージを世界中のリージョンにVM(Machine)として配置するPaaS

分野「実行基盤・ホスティング」：書いたコードを、自分のパソコンの外で動かし続ける場所。 分野の役割とつながりは分野の解説へ。

別名：Fly、flyctl、Fly Machines

できること

Fly.io ができないこと

  • クレジットカード登録なしでの利用開始(Linked Organizationsを除く全組織で登録必須)
  • Volume(永続ディスク)間の自動レプリケーション(単一障害点になるため、冗長化はアプリ側の設計が前提)
  • 一度拡張したVolumeサイズの縮小
  • リクエスト単位でのゼロ円起点課金(Lambda/Workersのような従量課金ではなく、Machineが起動している間は秒単位で課金され続ける)

制約

先頭の行が、このツールで最も先に当たる制約。値はすべて出典の一次情報で確認したもの。

項目 値 影響 出典 検証日
支払い方法の登録 （主要制約） Linked Organizationsを除くすべての組織でクレジットカード登録が必須 個人の検証目的でも、カード登録なしには一切のリソースを作成できない fly.io
Machineの課金単価(共有CPU、例 アムステルダム) shared-cpu-1x(共有1CPU・256MB RAM)が1秒あたり0.00000078ドル(30日常時稼働で目安月額約2.02ドル)。稼働中のみ課金され、停止・一時停止中はCPU/RAM課金なし 常時起動するサービスは秒単位で費用が積み上がる。オートストップを使わない設計だとアクセスがなくても課金が続く fly.io
Volume(永続ディスク)の最大サイズと拡張制約 1ボリュームの最大サイズは500GB(既定1GB)。拡張はできるが縮小はできない 見積もりを誤って大きめに拡張すると、そのままではサイズを戻せず作り直しが必要になる fly.io
Volumeのレプリケーションと障害耐性 Volume間に組み込みのレプリケーション機能はない。ボリュームを保持するNVMeドライブが故障すると、そのインスタンスのアプリは停止する 本番ではアプリごとに最低2つのボリュームを異なる場所にプロビジョニングすることが公式に推奨されている。1ボリューム構成は単一障害点になる fly.io
データ転送(アウトバウンド)の価格 2024年7月18日以降作成の組織向けで、北米・欧州は0.02ドル/GB、アジア太平洋・南米は0.04ドル/GB、アフリカ・インドは0.12ドル/GB。インバウンドは無料 配信先の地域によって帯域コストが数倍変わる。ユーザーの分布が偏る場合は地域別の見積もりが必要になる fly.io

典型的な落とし穴

  • オートストップ/オートスタートを設定せず常時起動のままにし、アクセスがほぼないアプリでも秒課金が積み上がる
  • Volumeを1つしか作らず、ホスト障害でデータごとアプリが落ちて気づく
  • リージョンやVolumeの配置を意識せず、ユーザーから遠いリージョンにMachineが偏って応答が遅くなる
  • 帯域費用の地域差を見落とし、想定外の地域からのアクセスが多いサービスで転送費用が跳ねる

コスト

課金モデル
従量課金
跳ねる条件

稼働中のMachineは秒単位のCPU/メモリ課金、Volumeは容量課金(月額)、アウトバウンド転送は地域別従量課金。固定の無料利用枠はなく、全組織にクレジットカード登録が必須

出典
fly.io 　検証

代替手段と差分

代替 何が違うか
Render Renderはクレジットカードなしで使える無料インスタンス(スリープあり)を持つが、リージョン選択やVolumeの制御はFly.ioより限定的。Fly.ioは複数リージョンへのMachine配置と秒単位課金を前面に出す代わりに、開始時点でカード登録が必須
AWS Lambda Lambdaはリクエストが来たときだけ課金される従量課金で、アクセスが散発的なら安い。Fly.ioは常駐Machineが前提で、オートストップを使っても起動中は秒課金が続く。WebSocketや常駐プロセスが必要ならFly.io、短時間処理が中心ならLambda
Docker Dockerはコンテナをビルドするための道具そのもので、動かす場所は別に用意する必要がある。Fly.ioはそのDockerイメージをMachine(Firecracker VM)として世界中のリージョンに配置し、ネットワーク・TLS・スケールを引き受ける

選定判断

Dockerイメージを複数リージョンに配置して低遅延で配信したい、WebSocketや常駐プロセスを動かしたい用途では第一候補。カード登録なしで無料に試したい場合や、アクセスが散発的でリクエスト単位課金が有利な場合は、それぞれRenderやLambda/Workers系を検討する

Dockerfile やコンテナイメージを渡すと、Firecracker VM(Machine)として世界中のリージョンに配置できるPaaSで、常駐プロセス・WebSocket・永続ディスク(Volume)・Postgresなどをまとめて運用できる。課金は稼働時間ベースの秒単位課金が基本で、リクエスト単位のサーバーレス課金とは性質が異なる。

利用者が最初に当たる制約はクレジットカード登録の必須化である。個人の検証用途であっても、カードを登録しない限りMachineを1つも作成できない。次に当たるのがVolumeの単一障害点としての性質で、レプリケーション機能を持たないため、本番運用では最低2つのボリュームを分けて持つ設計が公式に推奨されている。