Fly.ioを使う前に見ておきたい仕組みと料金

contents 10
  1. 01 Fly.ioとは
  2. 02 Fly.ioの主な特徴
  3. 03 Fly.ioの料金体系:従量課金制の詳細
  4. 04 Fly.ioのアーキテクチャと設計思想
  5. 05 実践:Fly.ioでのアプリケーションデプロイメント
  6. 06 Fly.ioと他のクラウドサービスの比較
  7. 07 Fly.ioの運用上の考慮事項
  8. 08 Fly.ioのユースケース
  9. 09 まとめ
  10. 10 参考文献

Deploy app servers close to your users · Fly

Fly.ioとは

Fly.ioは、アプリケーションを複数の地域に配置し、利用者に近い場所で実行することを重視したクラウドプラットフォームです。Dockerfileや一般的なWebフレームワークを前提に扱えるため、既存の小さなアプリケーションから試しやすい構成になっています。

筆者も小さなインスタンスを現在進行形で動かしていますが、月額が5ドル未満に収まっているため、請求は発生していません。実際、毎月の請求メールでも、default personal organizationの請求額が5ドル未満の場合は徴収せず、請求額を100%割り引く旨が示されています。ただし、これは「無料枠」というより、少額請求が免除されている状態として理解したほうが安全です。Fly.ioの公式ドキュメントでも、無料アカウントや無料枠は存在しないと説明されています。一方で、公式コミュニティでは、最初に作成されるpersonal organizationについて、5ドル未満の請求免除が適用されると案内されています。

この記事では、Fly.ioの基本的な仕組み、料金、デプロイの流れを確認しながら、どのような用途で検討しやすいかを整理します。


Fly.ioの主な特徴

グローバルマルチリージョン配置とAnycastルーティング

Fly.ioは世界35地域にデータセンターを配置し、エンドユーザーに近いリージョンでアプリケーション自体を実行する設計を採っています。

従来の集中型クラウドでは、地理的に遠いデータセンターへの通信が遅延の主要因となります。Fly.ioではアプリケーションインスタンス自体を複数リージョンに配置し、Anycast IPによって最寄りのインスタンスへルーティングします。各リージョンのインスタンスは独立して動作するため、CDNのようなキャッシュではなく、実際のアプリケーションロジックが各地域で実行されます。

Fly Machines:高速起動VM技術

Fly.ioの中核技術である「Fly Machines」は、ハードウェア仮想化コンテナ(Hardware-virtualized containers)として動作し、サブ秒レベルでの起動・停止を実現します。これは以下の特徴を持ちます:

  • 即座のスケーリング: 単一のHTTPリクエストから数週間の連続稼働まで、柔軟にライフサイクルを制御
  • 低レベル制御: REST APIまたはflyctlコマンドで、マシンの数・リソース配分・地域配置を細かく管理
  • 高速起動: 従来の仮想マシンやコンテナオーケストレーションと比較して、起動時間が大幅に短縮

この技術により、トラフィックパターンに応じて自動的にインスタンスを増減させるオートスケーリングが、従来のクラウドサービスよりも効率的かつ高速に実行されます。

多様な技術スタック対応

Fly.ioは以下のフレームワーク・言語に対応しており、Dockerfileなしでもコンテナを自動生成できます:

  • Webフレームワーク: Rails、Phoenix、Django、Laravel、Node.js、.NET
  • 静的サイト: Astro、Next.js、Hugo
  • プログラミング言語: Go、Rust、Python、JavaScript、TypeScript、Ruby

特にRailsやPhoenixなど、Ruby/Elixirエコシステムとの親和性が高く、これらのフレームワークに最適化されたデプロイメント体験が提供されています。

Managed PostgreSQLとデータベース戦略

Fly.ioは「Managed Postgres」サービスを提供し、以下の機能を標準搭載しています:

  • 自動バックアップ: データの定期的なバックアップと復元機能
  • 高可用性フェイルオーバー: プライマリノード障害時の自動切替
  • 暗号化: 保存データと通信データの両方を暗号化
  • グローバル分散配置: アプリケーションと同様に、データベースも地理的に近い場所に配置可能

データベースをアプリケーションと同一リージョンに配置することで、レイテンシを最小化し、より一貫性のあるパフォーマンスを実現します。


Fly.ioの料金体系:従量課金制の詳細

Fly.ioは「Plans get complicated, so we just charge based on usage」という方針のもと、複雑なプラン体系を排除し、実際に使用したリソースのみを課金する従量課金制を採用しています。

コンピュートリソース(Fly Machines)の料金

起動中のマシン

共有CPU(Shared CPU):

以下は公式サイトから抜粋した料金表です(最終更新: 2025年10月26日)。

Region: Japan (nrt) の料金:

CPU(s)RAMPrice/secondPrice/hourPrice/month
shared-cpu-1x (1 shared)256MB$0.00000098$0.0035$2.54
512MB$0.00000161$0.0058$4.18
1GB$0.00000287$0.0103$7.45
2GB$0.00000540$0.0194$13.99
shared-cpu-2x (2 shared)512MB$0.00000196$0.0071$5.08
1GB$0.00000322$0.0116$8.36
2GB$0.00000575$0.0207$14.90
4GB$0.00001080$0.0389$27.98
shared-cpu-4x (4 shared)1GB$0.00000392$0.0141$10.17
2GB$0.00000645$0.0232$16.71
4GB$0.00001149$0.0414$29.79
8GB$0.00002159$0.0777$55.96

料金は地域によって異なります:

  • 最安値: Secaucus, NJ (US) (ewr) / Ashburn, Virginia (US) (iad)
  • 日本: Tokyo (nrt) - 上記表の料金

Singapore (sin) - 日本より若干安価です。気持ち程度。

パフォーマンスCPU(Performance CPU):

スペック月額料金(USD)
1コア、2GB RAM$32.19
2コア、4GB RAM約$64〜

※地域によって価格が異なる場合があります。

停止中のマシン

マシンを停止している間は、ルートファイルシステム(rootfs)のストレージのみが課金対象となります:

  • ストレージ料金: 1GB あたり $0.15/月(30日間停止時)

この仕組みにより、使用頻度の低いアプリケーションやステージング環境を低コストで維持できます。

GPU料金

機械学習や高度な計算処理が必要な場合、以下のGPUインスタンスが利用可能です:

GPU種類時間料金(USD)
A10$1.50
L40S$1.25
A100 40GB PCIe$2.50
A100 80GB SXM$3.50

ストレージ料金

Fly Volumes:

  • 料金: $0.15/GB/月(プロビジョニング容量ベース)

Volume Snapshots:

  • 料金: $0.08/GB/月
  • 無料枠: 最初の10GBは無料

ネットワーク関連料金

サービス料金(USD)
専用IPv4アドレス$2/月
単一ホスト証明書$0.10/月
ワイルドカード証明書$1/月
データ転送$0.02〜$0.12/GB(地域により変動)

その他サービス

Fly Kubernetes:

  • 基本料金: $75/月
  • 追加: コンピュート・ストレージの従量課金

サポートプラン:

プラン月額料金(USD)
Standard$29
Enterprise$2,500〜

割引オプション

年間契約による「マシン予約」を利用することで、最大40%の割引が適用されます。長期運用が見込まれるプロダクション環境では、コスト最適化の選択肢として検討する価値があります。


Fly.ioのアーキテクチャと設計思想

エッジファーストの分散アーキテクチャ

Fly.ioは「エッジファースト」の設計思想を採用しており、従来のリージョンベースのクラウドとは異なるアプローチを取っています。具体的には以下の特徴があります:

  • Anycast IPアドレス: 単一のIPアドレスで全世界に配信し、DNSではなくネットワークレベルで最適なロケーションへルーティング
  • 自動レプリケーション: アプリケーションを複数地域に自動配置し、障害時の冗長性を確保
  • 地理的近接性: ユーザーに最も近いエッジでコードを実行し、バックエンドとのやり取りを最小化

この設計により、グローバル展開が前提のSaaSやコンテンツ配信サービスにおいて、従来のCDN+アプリケーションサーバーの二層構成を統合し、シンプルなアーキテクチャで高パフォーマンスを実現します。

コントロールプレーンとデータプレーンの分離

Fly.ioは、管理操作を担う「コントロールプレーン」と、実際のアプリケーション実行を担う「データプレーン」を明確に分離しています:

  • コントロールプレーン: flyctl CLIやMachines APIを通じて、デプロイ・スケーリング・設定変更を実施
  • データプレーン: Fly Machines上でアプリケーションが実行され、エンドユーザーのリクエストを処理

この分離により、管理系の障害がアプリケーションの稼働に影響を与えない堅牢性を実現しています。

セキュリティとコンプライアンス

Fly.ioは以下のセキュリティ機能を提供します:

  • KVMハードウェア分離: 各マシンは独立したVMとして実行され、他のテナントから完全に分離
  • メモリセーフな実装: Rust/Goスタックによる実装で、メモリ関連の脆弱性を最小化
  • SOC2 Type 2認証: 第三者監査による信頼性担保
  • SSO対応: エンタープライズ向けのシングルサインオン統合

これらの機能により、企業のセキュリティポリシーに準拠した運用が可能です。


実践:Fly.ioでのアプリケーションデプロイメント

flyctl CLIのインストール

Fly.ioの操作には、公式コマンドラインツール「flyctl」を使用します。

macOS(Homebrew):

brew install flyctl

Linux(スクリプトインストール):

curl -L https://fly.io/install.sh | sh

Windows(PowerShell):

iwr https://fly.io/install.ps1 -useb | iex

インストール後、アカウント認証を実施します:

fly auth login

ブラウザが開き、Fly.ioアカウントでログインすると、CLIとの連携が完了します。

新規アプリケーションの作成とデプロイ

ステップ1: アプリケーションの初期化

既存のプロジェクトディレクトリで以下を実行します:

fly launch

このコマンドは対話式で以下を実施します:

  1. アプリケーション名の設定
  2. デプロイ先リージョンの選択
  3. PostgreSQLデータベースの作成有無
  4. 初回デプロイの実行

Fly.ioは、プロジェクトのソースコードを解析し、適切なDockerfileまたはビルドパック設定を自動生成します。Rails、Phoenix、Djangoなどの主要フレームワークは自動検出されます。

重要: デフォルトでは高可用性のため2マシン(インスタンス)が起動します。Discord BotやWebSocket常時接続型アプリケーションなど、単一マシンで動作させる必要がある場合は、fly scale count 1 で明示的に1マシンに設定してください。複数マシンが同時に動作すると、イベントの重複処理などの問題が発生する可能性があります。

ステップ2: 設定ファイルの確認

fly.tomlファイルがプロジェクトルートに生成されます。このファイルは、アプリケーションの構成を定義します:

app = "my-app"
primary_region = "nrt"  # 東京リージョン

[build]

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0

主要な設定項目:

  • app: アプリケーション名(グローバルで一意)
  • primary_region: プライマリリージョン(例: nrt = 東京)
  • internal_port: アプリケーションがリスンするポート
  • auto_stop_machines / auto_start_machines: オートスケーリング設定
  • min_machines_running: 最低稼働マシン数(0に設定すると完全にアイドル時は停止)

ステップ3: デプロイ実行

アプリケーションをデプロイします:

fly deploy

デプロイプロセスでは以下が実行されます:

  1. コンテナイメージのビルド
  2. Fly.ioレジストリへのプッシュ
  3. 指定リージョンでのマシン起動
  4. ヘルスチェック実施
  5. トラフィックの新バージョンへの切替

デプロイ完了後、アプリケーションのURLが表示されます(通常は https://my-app.fly.dev)。

ローカルでDockerイメージをビルドしてデプロイ

デフォルトではFly.io側でイメージをビルドしますが、ローカル環境でDockerイメージをビルドしてからデプロイすることも可能です。これは、複雑なビルド環境や特定のDocker設定が必要な場合に有効です:

flyctl deploy --local-only

複数の設定ファイルを使い分ける場合は、--config オプションで指定できます:

flyctl deploy --config fly.dev.toml --local-only

ローカルビルドのメリット:

  • ビルド環境を完全に制御可能
  • ビルドキャッシュをローカルで管理
  • 複雑なマルチステージビルドやビルド引数の扱いが容易
  • CI/CDパイプラインでの柔軟な統合

注意点:

  • ローカルマシンのアーキテクチャ(ARM64/AMD64)に注意が必要
  • Apple Siliconなど異なるアーキテクチャの場合は、--build-arg でプラットフォームを指定

環境変数とシークレット管理

機密情報(APIキー、データベース認証情報など)は、シークレットとして管理します:

fly secrets set DATABASE_URL="postgres://user:pass@host/db"
fly secrets set API_KEY="your-secret-key"

設定されたシークレットは暗号化され、環境変数として実行時にアプリケーションに注入されます。

シークレットの一覧確認:

fly secrets list

マルチリージョンデプロイメント

グローバル展開を実現するには、複数リージョンにマシンを配置します:

fly scale count 2 --region nrt  # 東京に2台
fly scale count 2 --region lax  # ロサンゼルスに2台
fly scale count 2 --region fra  # フランクフルトに2台

各リージョンに配置されたマシンは、自動的にAnycast IPを通じて最適なトラフィックを受信します。ユーザーは地理的に最も近いリージョンにルーティングされ、低遅延なアクセスが実現されます。

ログ監視とデバッグ

リアルタイムログを確認するには:

fly logs

特定のマシンのログのみを表示:

fly logs --instance <instance-id>

アプリケーション内のconsole.logや例外は、このログストリームに出力されます。運用中の問題切り分けや、パフォーマンス分析に活用できます。


Fly.ioと他のクラウドサービスの比較

AWS/GCP/Azureとの違い

項目Fly.ioAWS/GCP/Azure
デプロイ速度数秒〜数十秒数分〜数十分
グローバル展開標準機能(追加料金なし)複雑な設定・追加料金が必要
料金体系シンプルな従量課金複雑な階層料金
エッジ実行ネイティブ対応限定的(Lambda@Edge等)
開発者体験CLI中心、シンプル多機能だが複雑

Fly.ioは、大規模なエンタープライズ向けの多様なサービス群よりも、「シンプルで高速なグローバル展開」に特化しています。スタートアップやSaaSプロダクトにおいて、初期段階から国際展開を前提とする場合に特に有効です。

Herokuとの比較

項目Fly.ioHeroku
価格従量課金、低コスト固定プラン、高コスト
グローバル展開35地域、標準対応限定的(US/EU)
スケーリングサブ秒自動スケール手動/遅延あり
カスタマイズ性Docker対応、柔軟ビルドパック固定

Herokuの代替としてFly.ioを選択する事例が増えており、特に2022年のHeroku無料プラン廃止以降、多くの開発者がFly.ioへ移行しています。

Vercel/Netlifyとの比較

項目Fly.ioVercel/Netlify
対象フルスタックアプリ静的サイト・SSR
バックエンド完全制御可能Serverless Functions限定
データベースManaged Postgres外部サービス統合
実行時間制限なしあり(関数タイムアウト)

VercelやNetlifyは主にフロントエンド・静的サイトに最適化されているのに対し、Fly.ioはバックエンドAPIやデータベースを含むフルスタックアプリケーションの実行に適しています。


Fly.ioの運用上の考慮事項

コスト最適化のポイント

  1. オートスケーリング設定: min_machines_running = 0 に設定し、アイドル時にマシンを完全停止
  2. リージョン選択: 必要な地域のみに配置し、過度な分散を避ける
  3. ストレージ管理: 不要なボリュームスナップショットを定期削除
  4. マシンサイズ最適化: 過剰なスペックを避け、実際のリソース使用量に合わせた調整

トラブルシューティング

マシンが起動しない場合

ヘルスチェック設定を確認します。fly.tomlで適切なヘルスチェックエンドポイントが設定されているか確認してください:

[checks]
  [checks.alive]
    type = "http"
    path = "/health"
    interval = "15s"
    timeout = "10s"

アプリケーションが/healthエンドポイントで200を返すことを確認します。

デプロイが遅い場合

Dockerイメージのサイズが大きい場合、ビルド・転送に時間がかかります。マルチステージビルドを活用し、最終イメージサイズを最小化します:

# ビルドステージ
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 本番ステージ
FROM node:18-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]

ログが出力されない場合

アプリケーションの標準出力(stdout/stderr)がFly.ioログに統合されます。ログライブラリの設定で、ファイル出力ではなく標準出力を使用するよう設定してください。


Fly.ioのユースケース

リアルタイムWebアプリケーション

WebSocketやServer-Sent Eventsを使用するチャットアプリケーション、リアルタイム通知システムなどでは、遅延の小ささが効きます。エッジ展開により、地域差を抑えた双方向通信を設計しやすくなります。

グローバルAPIサービス

RESTful APIやGraphQL APIを世界規模で展開する場合、Fly.ioのマルチリージョン配置により、各地域のユーザーに均一なレスポンスタイムを提供できます。

マイクロサービスアーキテクチャ

複数の小規模サービスを独立してデプロイ・管理できるため、マイクロサービス構成に適しています。各サービスを個別にスケールさせることで、リソース効率を最大化できます。

エッジコンピューティング

CDN的な役割を担いつつ、動的なコンテンツ生成や認証・認可処理をエッジで実行したい場合、Fly.ioの設計は検討に値します。


まとめ

Fly.ioは、アプリケーションを利用者に近い地域で動かすための仕組みを、比較的少ない設定で扱えるクラウドプラットフォームです。高速起動するFly Machines、複数リージョンへの配置、従量課金制といった特徴により、リアルタイム性が必要なWebアプリケーションや、早い段階から海外利用を想定するサービスで検討しやすい選択肢になります。

料金体系は実使用量ベースで透明性が高く、停止中のマシンはストレージのみの課金となるため、開発環境やステージング環境を低コストで維持できます。年間契約による最大40%の割引オプションも、プロダクション環境の長期運用において有効なコスト最適化策となります。

flyctl CLIによるデプロイ体験は、HerokuやVercelに近い簡潔さを持ちながら、Docker対応による柔軟性もあります。RailsやPhoenixといった既存フレームワークとの統合も用意されており、構成によっては既存プロジェクトからの移行も現実的です。

一方で、データベースの配置、複数リージョン運用、停止中マシンの扱いなどは事前に確認しておく必要があります。Fly.ioは万能な置き換え先というより、アプリケーションをどこで動かすかを強く意識したいときに効く選択肢です。

参考文献

share Twitter Facebook