Fly.ioの障害は解消済み
(status.flyio.net)- Fly.ioのステータスページは現在 All Systems Operational で、アプリ実行・ダッシュボード・Machines API・リージョン可用性などの主要コンポーネントは稼働中
- 2026年7月1日の Elevated API Errors は、GraphQL APIのエラーとバックグラウンドジョブ処理の問題を修正した後、07:50 UTCに解消
- 6月30日の Delayed Metrics では、一部顧客のfly-metrics.netダッシュボードでメトリクスの遅延・欠落が発生したが、バックログ処理と容量増強後に正常化
- このステータスページは グローバル障害 の更新用であり、影響が限定的なハードウェア障害や孤立したインフライベントは含まれない
- アプリごとの影響はFly Organizationダッシュボードの personalized status page で確認する必要があり、内部インシデントや活動はInfra Logを参照するよう案内されている
現在のサービス状態
- Fly.ioのステータスページは現在 All Systems Operational 状態
- 稼働中と表示されている主な項目は、Customer Applications、Dashboard、Machines API、Regional Availability、Persistent Storage (Volumes)、Deployments、Remote Builds、Logs、Metrics、SSL/TLS Certificate Provisioning、UDP Anycast、Fly Machine Image Registry 1・2、Extensions、Upstash for Redis、DNS、Billing、Managed Postgres
- リージョンの状態も稼働中と表示されており、対象リージョンはAMS、ARN、BOM、CDG、DFW、EWR、FRA、GRU、IAD、JNB、LAX、LHR、NRT、ORD、SIN、SJC、SYD、YYZ
ステータスページの適用範囲
- このページは global incidents の更新用
- 影響が限定的な日常的ハードウェア障害や孤立したインフライベントの更新は含まれない
- アプリに影響しうるすべてのイベントのパーソナライズされた表示は、Fly Organizationダッシュボードの personalized status page で確認する必要がある
- 内部インシデントやその他の活動は Infra Log で確認するよう案内されている
2026年7月1日: Elevated API Errors
- Elevated API Errors は7月1日 07:50 UTCに Resolved となった
- 06:14 UTCに、GraphQL APIとバックグラウンドジョブ処理での elevated errors の調査が開始された
- 06:27 UTCに原因が特定され、修正作業が進められた
- 07:05 UTCに修正が適用され、それ以降はelevated API errorsは見られなくなった
- 一部のダッシュボード操作は、バックグラウンド処理が追いつくまで遅延する可能性があった
- 07:26 UTCにはバックグラウンドジョブが追いつき、APIは完全に稼働中の状態として監視が継続された
2026年6月30日: Delayed MetricsとSIN/NRTのegress IP
- Delayed Metrics は6月30日 22:19 UTCに解消された
- fly-metrics.netダッシュボードの顧客向けメトリクスに問題が発生し、ユーザーには遅延または欠落したメトリクスが表示されることがあった
- 複数ホストの問題によりメトリクス収集が遅延し、一部のmetrics ingestion hostsにおける resource contention が原因として扱われた
- バックログ処理のためにmetrics clusterの処理量を増やし、ingestion trafficの再調整と追加の処理能力投入が進められた
- 6月30日 19:58 UTC時点で、ほぼすべてのメトリクスは追いついていたが、
sinとsydの一部メトリクスは残っていた - Egress IP issues in SIN and NRT は6月30日 14:03 UTCに解消された
- SINとNRTでegress IPを使用する一部のMachinesは、一時的に接続を失うか性能低下を経験した可能性がある
2026年6月26日〜25日: ネットワーク・デプロイ・コントロールプレーンの事象
- IPv6 Connectivity Issues in EWR は6月26日 23:48 UTCに解消された
- upstream providerのIPv6ネットワーク接続の問題がEWRで発生した
- 影響を受けたホスト上にMachinesを持つアプリは、特定のIPv6宛先への接続に影響を受けた可能性がある
- Network maintenance in YYZ は6月26日 08:00〜09:00 UTCに実施された予定メンテナンスで、完了している
- メンテナンス時間内には最大 15分の接続断 が見込まれていた
- Deploys defaulting to Fly-hosted Builders は6月25日 15:38 UTCに解消された
- Depot backed buildersのプロビジョニング遅延を調査する中で、デフォルトの
fly deploy戦略はFly-hosted buildersへ切り替えられた - ユーザーは
fly deploy --depot=trueでDepotベースのデプロイを強制でき、その後fly deploy --depot=falseでFly builderベースのデプロイも可能だった
- Depot backed buildersのプロビジョニング遅延を調査する中で、デフォルトの
- Elevated control plane latency は6月25日 15:18 UTCに解消された
- BOMとNRTリージョンに影響するcontrol plane latencyと飽和が発生した
- これらのリージョンにMachinesを持つアプリは、応答時間の長期化や 502 errors を経験した可能性がある
2026年6月24日〜17日: 北米・SIN/NRTネットワークとログ検索
- Degraded networking in North America は6月24日 06:57 UTCに解消された
- 北米サイト間のネットワーク性能低下が、upstream incidentにより調査された
- 一部のMachinesは、特定経路でパケットロスとより高い遅延を確認した可能性がある
- LAXリージョン発着の一部 6PN Private Networking トラフィックには影響が残っていた
- Network issues in SIN, NRT は6月22日 21:56 UTCに解消された
- upstream providerがSINおよびNRTリージョンでネットワーク問題を抱え、当該リージョンのアプリは到達不能または高いパケットロスを経験した可能性がある
- SIN, NRT network issues は6月22日 19:48 UTCに解消された
- 当初はSINリージョンのupstream network issueとして調査され、その後NRTリージョンのアプリでも特定宛先への到達問題が発生する可能性があることが判明した
- Log search unavailable は6月19日 21:53 UTCに解消された
- Fly Metricsのログ検索パネルと
fly logsコマンドで最初に返されるhistorical application logsに影響した fly logsのストリーミング、ダッシュボードのLive Logsページ、Fly Log Shipper servicesは正常に動作していた- 修正後、historical logsはバックフィルされ、キューに入っていたhistorical logsの大半が検索可能になった
- Fly Metricsのログ検索パネルと
- Network Issues in SIN は6月17日 04:55 UTCに解消された
- SINリージョンでネットワーク接続の問題があり、ホストされているアプリが利用不能になる可能性があった
- 一部のMachinesが到達不能となり、一部のManaged Postgres clustersではフェイルオーバーまたは更新に失敗する可能性があった
1件のコメント
Hacker News の意見
fly.io に載せている私のウェブサイトは、6時間ほど前に5分間ダウンしてすぐ復旧し、その後はずっと正常です
無料の監視サービスが5分ごとにチェックしているので、もっと短いダウンタイムは見逃した可能性もありますが、全体としてはかなり安定していました
アプリケーションの稼働時間も不安定ですが、もっと悪かったのは fly deploy の失敗が理由なく発生するケースでした。あるときはレイヤーがただ止まったままになり、最終的に失敗しましたが、1〜2時間後に何も変更せず同じコマンドを再実行すると正常に動きました
基本的なアプリを5分ごとにデプロイしてみる監視サービス、つまり
fly deployコマンドを定期的に実行して、デプロイがどれくらいの頻度で失敗したり止まったりするのか見てみたいです。おそらく5%程度は説明なく失敗すると思いますし、時間に余裕がないとかなりイライラするレベルですこちらの基準では16分間継続したように見えます
fly.io は事後分析をこちらで公開しています: https://fly.io/infra-log/
最近の事後分析はかなり興味深く、詳細も豊富です。2016年の fly.io の運用インフラの中核コンポーネントは consul という高セキュリティの TLS サーバーで、共有状態を追跡しつつ、サーバー証明書とクライアント証明書の両方を認証する必要がありました
中央集権的な構造だったためスケーラビリティの問題が生じ、fly.io は2020年にこれを置き換える corrosion を作って consul のことをすぐに忘れましたが、完全には取り除けませんでした
その後、2024年10月に consul のルートキー署名鍵が期限切れになり、すべての接続が落ちました。双方向認証を使っているため、全マシンに新しい SSL 証明書を配布するまで復旧できませんでした。何とか30分でやり遂げましたが、すでにドミノ倒しは始まっており、インフラの別の弱点も露呈しました
さらに別の内部サービスでは、独立した TLS キーセットがずっと前に期限切れになっていましたが、consul のキー再発行の過程で再起動するまでは気づかれていませんでした。証明書が有効だった時期に確立していた TCP 接続が、再起動によって切断されたことで表面化したのです。その最中、ロギングツールがネットワークプロバイダーを DDoS のように叩いていました。これほど多くのことが一度に起きた中で、会社を救い、顧客まで守った人たちは本当にすごいと思います
ところが採用ページ [1] では「私たちは技術的負債をあまり信じていない」と言っています
外から見ると、矛盾の合唱のように読めます
[1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...
Fly.io はかなり二面性のあるサービスに見える
https://news.ycombinator.com/item?id=41917436
https://news.ycombinator.com/item?id=35044516
https://news.ycombinator.com/item?id=34742946
https://news.ycombinator.com/item?id=34229751
クラウドプラットフォームが信頼性をきちんと提供できないなら、それに見合う価値はないと思う。単に仮想サーバーを借りてクラウド税を節約したほうがよいかもしれない
ただし、この価格は RAM 256MB のインスタンス基準（https://fly.io/docs/about/pricing/）。それでもその上で意味のあるプロジェクトを動かすことは十分可能だ。Rocket のような Rust ベースの Web サーバーは RAM を約 10MB しか要求しないし、ざっと調べた限りでは基本的な PHP サーバーも収まりそうだ
デプロイ障害はもちろん、ほぼ毎日、何かがランダムに動かなかったり遅延したりしていた
値上げと、上司が自分の Fly 上のプロジェクトで何度も問題を目にしたことが理由で、数か月前に離れざるを得なかった
さらに sqlite バックアップサービスも廃止して削除した。今は GCP に戻り、数々の障害を心配しなくてよくなった
単一の AWS リージョンで運用しながら、世界中の数百万人が使う大企業のサービスも多い。デフォルトから時期尚早な最適化を可能にする何かのように感じる
信頼性の最大化を目標に最適化するなら、それも完全に合理的な選択だ。2024年に UE1 で私たちのほうが優れているとは言わない
参考までに言うと、さまざまなことが悪くなり得るし実際にそうなるが、ここで最もよく目にする可能性が高い障害の形は、デプロイできない期間だ。今回の障害はデプロイ／オーケストレーションの障害だった。数か月前には Rust の並行処理の地雷を踏んでリクエストルーティング全体の障害があったが、そういうことは非常にまれだ
デプロイと状態更新の障害も重大であり、私たちが推奨するようにさまざまな Fly Machines グループへ継続的にデプロイするなら、プラットフォームの大きな機能の一つであるだけに可用性へ影響し得る。これを過小評価するつもりはない
実際、自前のベアメタルサーバーで Firecracker を動かせば、fly.io がやっていることとほぼ同じことをより安くできる
fly.io に対する世間の認識は、すでに回復が難しいほど傷ついているように思う。もう何度謝罪したのかも数え切れない
記事タイトルとは違い、Fly.io API は依然としてアクセス不能だ。つまりユーザーはまだデプロイやデータベースなどにアクセスできないということだ
正確なアップデートは https://community.fly.io/t/fly-io-site-is-currently-inaccess... を見るとよい
Fly.io と Railway.com の両方を使ってみた個人的な経験では、Railway の圧勝だ。Railway のサポートも比較すると素晴らしい
Fly.io は、サポートメールに送ったデータ削除の問い合わせにいまだ返答していない
Railway アプリはこれまで大きなダウンタイムなしにオンライン状態を保っている。まともな代替を探している人には Railway を試してみることを勧める
アイデアは良いが、実際には本格用途で使いたくない
エンドユーザーが信頼性を求めるのは理解しているし、Fly が過去2年間この部分にかなり投資してきたにもかかわらず評判が悪いことも分かっている。しかし、こうした障害は一方のプロバイダーにだけあり、もう一方にはないという性質のものではない。クラウドインフラの構築は誰にとっても簡単なことではない
自分が直接見ただけでも、Fly.io の主要障害はおそらく5回目か6回目だ。他の障害も多く、一部は単に見逃していた可能性が高い
友人にこのサービスを勧めたら、2日以内に障害を2回経験した
Fly.io は本当に気を引き締める必要がある。なぜいまだにそうできていないのかは謎だ。製品は良いが、ホスティングサービスなら安定性が何よりも最優先でなければならない。残りはすべて二の次だ
秘訣は、代替があまりない既存の強者になることのようだ。そうすれば信頼性の面で完全にめちゃくちゃでも、誰もが運用上の失敗をだいたい見逃してくれる
不思議なことに、Turso もほぼ同じ時刻に問題が起き始めていた。CEO が Discord で Fly の障害が原因だと確認していた
Turso はいずれ AWS ティアを提供する予定のように見える
驚きはない。約1年前、低価格に惹かれて fly.io を調べたことがあり、どこでコストを削って利益を出しているのか気になっていた。結局、技術文書に答えを見つけたのだが、fly インスタンスは1台の物理サーバーに固定されており、そのサーバーが死ぬとフェイルオーバーできない、と明確に書かれていた。その部分が今も公式ドキュメントに残っているかは分からない
実際には、サーバーが落ちると、そのインスタンスの最後のスナップショットをバックアップから読み込んで新しいサーバーに載せ、ネットワーク経路を更新し、余剰キャパシティを超える数のサーバーが死なないことを祈る、という意味になる。そうでなければ、データセンターがラックにサーバーを数台追加で挿すまで復旧を待たなければならない
だから障害報告がランダムに見えることもかなり説明がつく。あるアプリは落ち、別のアプリは無事で、あるアプリは5分で戻り、別のアプリはかなり時間がかかる、という具合だ
予算が厳しい事業なら、小さな civo クラスターのような別の選択肢のほうが良さそうだ
「fly インスタンスが1台の物理サーバーに固定されていてフェイルオーバーできない」という部分は、それ以外にどうあるべきだと言っているのか、よく分からない。ライブマイグレーションがあるのは分かるが、その場合でも VM は結局どこかの物理サーバーには「固定」されているのではないか？
それに無料でもない。たとえば GCP で VM がマイグレーションされるときには、体感できる一時的な性能低下がある
プロキシ層が失敗すれば Fly 全体が依然として落ちる可能性はあるが、そういうケースははるかに少ない
繰り返し見えるパターンは、米国の主要な祝日がある週に障害がよく起きるということだ
MS 365/Teams/Exchange も朝に少し問題があり、Fly.io は全面障害で、その後いくつものサイトやサービスがその影響で揺れた
普段は「変更凍結」には反対だが、主要な祝日の前後では 変更凍結は理にかなっていると思う。すべてのチームに、リチャージ、中断、メンテナンスの時間を与えられる
たまたま当番になった B チームに過度なプレッシャーをかけないほうがいい
休暇シーズンにそうした変更も減らそうとすることはできるが、証明書を更新しなければならない場合は？ 重要なセキュリティパッチを適用しなければならない場合は？ サーバー群を再プロビジョニングしなければならない場合は？ ハードディスク容量が不足した場合は？
年中どの時期であっても、運用上の難題を計画だけで避けることはできない
そのうち特別なマーケティング/プロダクト施策が発生し、特殊な価格ロジックには新しいコードと新しい UI ウィジェットが必要になり、トラフィックと負荷が大きく跳ね上がり、凍結中なのに今すぐ出さなければならない状況になる。売上に関わるので経営陣にとっては重要だ
ほとんどのエンジニアリングチームとインフラチームは、プロダクトチームが土壇場まで突き進み、ある程度秘密裏に進めていたため、その事実を知らなかった。結局、高品質な小さな修正は凍結できても、不安定な新機能はきちんと凍結できない
難しい話で、それでも凍結は忘れて、前後も期間中も無理をしない合理的な運用を勧める
「不要な」変更は止められるかもしれないが、その境界はあっという間にグレーゾーンになる
2023年初めの連続障害にも Corrosion 関連の苦痛があった: https://community.fly.io/t/reliability-its-not-great/11253
制約条件をとてもよく知っているわけではないが、ScyllaDB は結果整合性をサポートしており、全体的にかなり柔軟だ。マルチリーダーレプリケーションには CouchDB も選択肢になる