Wi-Fiの信頼性に関するエイブリーの法律

ルーターの交換： メーカーA：10％破損 メーカーB：10％破損 P（AとBの両方が壊れています）： 10％×10％= 1％ ルーター（またはファームウェア）を交換すると、ほとんどの場合問題が解決します。

Wi-Fiアンプの追加： ルーターA：90％動作中 ルーターB：稼働率90％ P（AとBの両方が機能）： 90％×90％= 81％ ルーターを追加すると、ほとんど常に状況が悪化します。

LTEまたはメッシュネットワークに関係なく、すべてのワイヤレスネットワークは遅かれ早かれ衰退しますが、Wi-FiネットワークはLTE電話接続よりも信頼性が低いと確信できます。 Battlemesh v10カンファレンスでは、私たち全員が、インターネットにアクセスする場合とアクセスしない場合があるオープンネットワークを備えた、実験的に設定が間違っているWi-Fiルーターが多数ある部屋に座っていました。 ネットワークを信頼できる、または信頼できないものにしているものは何ですか？



これらのテクノロジー（分散システムの他の問題に取り組んでいる多くのエンジニアに囲まれていることが判明しましたが、結果として同じ制限を抱えています）でこれらのテクノロジーに数年悩みました。 あるノードまたは別のノードからサービスを取得できる場合、分散システムはより信頼性が高くなります。 サービスが1つのノードと別のノードに依存している場合、信頼性が低下します。 数値は乗法的に結合されるため、ノードが多いほど、サービスはより速く落ちます。



ワイヤレスネットワークに関連しない例を使用する場合、データベースを使用したWebサーバーの操作を想像してください。 2台のコンピューター（実際または仮想）上にある場合、Webサーバーとデータベースサーバーが完全に機能しないと、Webアプリケーションがクラッシュします。 本質的に、このようなソリューションは、Webサーバーを必要とするがデータベースを必要としないシステムよりも信頼性が低くなります。 逆に、2台のデータベースサーバーでフォールトトレラントシステムを編成している場合を考えてみましょう。したがって、一方が故障した場合、もう一方に切り替えます。 プライマリまたはセカンダリサーバーが動作している場合、データベースは機能しますが、これははるかに優れています。 ただし、データベースサーバーをまったく必要としない場合よりも信頼性は低くなります。



Wi-Fiに戻ります。 メーカーAのルーターを持っていると想像してください。Wi-Fiルーターは通常まあまあなので、例として、信頼性が90％であると仮定し、簡単にするために「ユーザーの90％、経験10％迷惑なバグ。」 そのため、ブランドAのルーターを使用しているユーザーの90％は満足し、何のために変更することもありません。 残りの10％は不満であるため、メーカーBから新しいルーターを購入します。これはユーザーの90％でもうまく機能しますが、バグは関連していないため、他の90％で機能します。 つまり、ブランドAのルーターを持っている人の90％が満足しています。 ブランドBルーターを使用している10％の90％も満足しています。 満足度は99％です！ 両方のルーターの信頼性は90％しかありませんが。 だから、誰もがルーターAとルーターBのどちらかを選択できるので、良いものを選択して別のものを捨てるのです。



これは、ソフトウェア（ベンダーファームウェア対Openwrt対トマト）またはプログラムバージョン（v1.0が問題を引き起こすまでv1.0からv2.0にアップグレードできない場合があります）に等しく適用されます。 このプロジェクトには、v1ルーターとv2ルーターがあります。 最初のバージョンは、ほとんどのユーザーにとっては問題なく機能しましたが、すべてのユーザーにとってはうまくいきませんでした。 2番目のバージョンがリリースされたとき、v2ルーターをすべての新しいユーザーと、問題に苦情を申し立てたv1ユーザーに配布し始めました。 ユーザー満足度のグラフを取得したとき、2番目のバージョンのリリース直後にジャンプすることがわかりました。 いいね！ （私のグループはv2ルーターを開発していたため、特に優れていました:)）。 みんなを更新しますか？



実際、必ずしもそうではありません。 問題は、統計がゆがんでいることです。v2では、問題が発生したv1ユーザーのみを更新しました。 v1でv1の問題があるv2ユーザーを「更新」しませんでした（もちろん、それらもありました）。 たぶん、両方のルーターは90％の信頼性がありました。 上記の話はうまく機能し、逆もまた同様です。 同じ現象は、なぜ一部の人々がopenwrtからtomatoに切り替え、このファームウェアの信頼性に熱心に応答するのか、またはその逆の理由を説明しています。 Red HatとDebian、またはLinuxとFreeBSDなどでも同じことが言えます。この現象「すべてがうまくいきます！」はオープンソースの世界で知られています。 単純な確率。 何か問題がある場合にのみ移動するためのインセンティブが必要です。



しかし、方程式の裏側も真であり、メッシュネットワークにとって重要です。 メッシュ回線に複数のルーターをインストールすると、同時に複数のルーターに依存します。そうしないと、ネットワークが崩壊します。 Wi-Fiはこれで有名です。1台のルーターが接続を行いますが、奇妙な動作をします（たとえば、パケットをルーティングしません）。クライアントはまだこのルーターに関連付けられており、誰にも機能しません。 チェーン内のノードの数を増やすと、そのような結果の可能性が急速に増加します。



もちろん、LTE基地局には信頼性の問題もあり、多くの問題があります。 しかし、それらは通常、メッシュトポロジの形式で編成されておらず、各LTEステーションは通常、非常に広いエリアをカバーするため、少数のノードへの依存が形成されます。 さらに、通常、各LTEノードは「大きすぎて倒れる」ため、電話会社がすぐに修正するほど多くの人々に即座に問題を引き起こします。 メッシュネットワーク内の唯一の障害ノードは小さな領域でのみ動作するため、ほとんどの状況では問題はありませんが、この領域を通過するときにのみ問題が発生します。 これはすべて、ほとんどの場合独自のメッシュノードが動作していても、「Wi-Fiメッシュネットワークはバグが多く、LTEは信頼性が高い」という漠然とした印象につながります。 これはすべて統計のゲームです。



解決策：バディシステム

あなたが不適切に行動し始めた場合、友人に言ってみましょう。



ルーターA：90％動作中

ルーターB：稼働率90％

P（AまたはB作業）：

1-（1-0.9）×（1-0.9）= 99％



過去15年ほどで、分散システムの理論と実践は大きく進歩しました。 これで、AND状況をOR状況に変換する方法が基本的にわかりました。 RAID5アレイがあり、ディスクの1つに障害が発生した場合、ドライブを無効にしているため、他のディスクに障害が発生するまでドライブを交換できます。 200ノードのNoSQLデータベースサービスがある場合、他のノードが作業を引き継ぐことができるように、失敗したノードにリクエストが送信されないことを確認します。 いずれかのWebサーバーが冗長Ruby on Railsコードで過負荷になっている場合、ロードバランサーは、最初のサーバーが通常モードに戻るまで、負荷の少ない別のノードにトラフィックをリダイレクトします。



Wi-Fiでも同じことが言えます。ルーターが正常に機能しない場合は、ルーターを修正する前に無効にする必要があります。



残念ながら、Wi-Fiルーターのパフォーマンスは、データベースやWebサーバーのパフォーマンスよりも測定が困難です。 データベースサーバーは簡単にテストできます。 いくつかの要求を実行し、要求ソケットが正しいことを確認してください。 Webサーバーにはインターネット経由でアクセスできるため、1つのテストサービスを開始できます。これにより、すべてのサーバーが定期的に照会され、サーバーが応答しなくなった場合に再起動の必要性が通知されます。 しかし、定義上、メッシュネットワークのすべてのノードが1つの場所から直接Wi-Fiリンクを介してアクセスできるわけではないため、単一の検証サービスは機能しません。



「Wi-Fiバディシステム」と呼ばれる私の提案を次に示します。 類推はこれです：まるであなたとあなたの友人があなたが酔っぱらってバーに行き、バカのように振る舞い始めたかのように。 あなたはあまりにも酔っているので、あなたは必ずしもバカのように振る舞うことを知っているわけではありません。 これを判断するのは難しい場合があります。 しかし、誰がこれを決定できるか知っていますか？ お友達。 通常、彼らも酔っていても。



定義上、すべてのメッシュノードが1つの場所からアクセスできるわけではありませんが、定義により、各メッシュノードは少なくとも1つの他のメッシュノードで使用できると言うこともできます。 そうしないと、メッシュ構造にならず、さらに大きな問題が発生します。 これは、状況を修正する方法を示唆しています。 各メッシュノードは、エンドユーザーになりすまして1つ以上の近隣ノードに接続し、トラフィックがルーティングされているかどうかを時々確認する必要があります。 合格すれば、素晴らしい！ このノードにうまく対処することを伝え、同じ精神で続けます。 そうでない場合は、悪い！ このノードに、彼が車に戻った方が良いと伝えます。 （厳密に言えば、これを実装する最も安全な方法は、ポーリング後に「元気です」というメッセージのみを送信することです。障害が発生したノードは、「あなたの状況が悪い」というメッセージを受信できない場合があります。すばらしい！」一定期間）。



かなり密なメッシュネットワーク（特定のノードペア間に常に2つ以上のルートが存在する場合）では、これによりANDタイプの動作がORタイプの動作に変換されます。 現在、ノード（問題が発生した場合にネットワークから自身を取り出すことができるノード）の追加により、システムの信頼性が向上します。



LTEの冗長性は低いため、メッシュネットワークはLTEよりも有利です。 基地局に障害が発生すると、広いエリアで接続が失われ、電話会社は急いで修理する必要があります。 メッシュノードに障害が発生した場合は、問題を回避し、後で空き時間に修正します。



小さな数学的な例は、大きな進歩を遂げました！



これでは十分ではありませんか？

ウィーンでのBattlemesh v10カンファレンスまたはYouTubeでの私のプレゼンテーションから、 消費者Wi-Fiメッシュネットワークに関するすべてのスライド（pdf） （スピーカーの詳細なメモを含む）を見ることができます。





ご注意

いわゆる「法律」は、より一般的な特殊なケースであり、したがって分散システムのより有用な定理です。 しかし、これはインターネットであるため、1つの特別なケースを選択し、私にちなんで命名しました。 さあ、止めてみて。