ビザンチン将軍問題（ビザンチンしょうぐんもんだい、英語: Byzantine Generals Problem）とは、相互に通信しあう何らかのオブジェクト群において、通信および個々のオブジェクトが故障または故意によって偽の情報を伝達する可能性がある場合に、全体として正しい合意を形成できるかを問う問題である[1]。フォールトトレラントシステムでの多数決の妥当性や分散コンピューティングの処理の妥当性に関わる問題と言え、二人の将軍問題を一般化したものと言える。 ビザンチン将軍問題に帰結される故障や障害をビザンチン故障（Byzantine Failure、あるいはビザンチン障害）と呼ぶ。また、ビザンチン将軍問題が発生しても全体として正しく動作するシステムをビザンチン・フォールトトレラント性（Byzantine Fault Tolerance）があるという。 ビザンチン将軍問題は、東ローマ帝国（ビザ
JVM は ホスト名を解決すると IP アドレスをキャッシュします。 発生する問題 あるサーバのホスト名が変化しなくても、IP アドレスが変わると、 Java のプログラムからそのサーバにアクセスできなくなることがあります。 具体的には、 AWS の ELB はホスト名が変わらずに IP アドレスだけ勝手に変化することがあるので、そのような場合に、名前解決に失敗します。 もちろんサーバ側の管理者が DNS の A レコードを変更したときにも発生するので、 AWS のみならず一般的に起き得ます。 どのようにキャッシュしている？ キャッシュを保持してある場所 InetAddress クラスがキャッシュを保持しています。 キャッシュが存在する限り、名前解決をしようとしても、キャッシュが参照されます。 キャッシュの有効期間を決定する場所 InetAddressCachePolicy クラスがキャッ
最近何かと話題なCDNですが、そもそもCDNってなんだろう・・・どんなことに使えるんだろう？的なことを書いてみようと思います。 一応先に言っておくと、私はCDN業者に所属したことないのであくまでも利用者として見た時の話を書きます。 また、私の考えであり、様々なワークロードがあるなかでこれがすべてではありませんので、こんな考えもあるんだなぁぐらいに思ってもらえると助かります。 そもそもCDNってなんだろうか そもそもCDNはContent Delivery Networkの略であってCache Delivery Networkの略ではありません。 要はコンテンツをクライアントに対して高速・効率的に配信するためのネットワークです。 良くCDNといえばその成り立ちからキャッシュというイメージはありますが、重要な要素の一つではあるもののCDNの全てではありません。 さらに言えばAkamaiのInt
Microsoft AzureのAzure DNSが引き起こした大規模障害、原因はネットワークデバイスのバグ マイクロソフトのクラウドサービスであるMicrosoft Azureは9月15日にDNSの障害をきっかけにAzure SQL Database、Azure Backup、Visual Studio Team Searvice、Redis Cacheなどをはじめとする多数のサービスに障害が発生、可用性が低下するなどの現象を引き起こしました。 マイクロソフトはこの大規模障害について「Azure status history」のページに9月15日付「Azure Services - Service Interruptions in Multiple Regions」で詳しい報告を書いています。内容をまとめました。 この障害は9月15日11時18分（世界協定時）には現象が確認され、約1時間
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Charles を使うと PC 上に HTTP プロキシを立てて端末の通信をキャプチャし、リクエストやレスポンスの内容を覗いたり書き換えることが出来る。類似のソフトウェアとして Wireshark や Fiddler, Paros がある。 アプリの開発をしていてよくあるのは、APIがスタブで固定値しか返してくれない、異常系エラーのデバッグがやりづらい、という場面だが、Charles なら通信を好きに値を書き換えられるのでこれらに簡単に対処することができる。 Charles は Java アプリなので OS X だけでなく W
前回のクラスフルアドレッシングはIPアドレスの基礎として重要なポイントですが，現在のIPアドレスの割り振りはクラスレスアドレッシングです。CIDRとVLSMというクラスレスアドレッシング技術を学び，IPアドレスの柔軟な割り振り方法を学びましょう。 クラスレスアドレッシング あるサブネット（ネットワーク）で使うIPアドレスの範囲は，IPアドレスとサブネット・マスクの組み合わせで決まります。例えば，192.168.0.0，サブネットマスクが255.255.255.0のときは，コンピュータに割り当てられるのは192.168.0.1～192.168.0.254までです。このクラスフルアドレッシングの場合，クラスCでは最大254台という制限があり数が足りない場合が出てきます。でも，クラスAやBでは大きすぎる場合があります。このため，クラスの境界をなくしたアドレッシング（クラスレスアドレッシング）が主
スーパーインター博士(通称：博士） 某所の某大学にて、情報処理技術を教える博士。専門はネットワーク。 たった一人しかいないゼミ生であるネット君をこきつかう。 どこらへんがスーパーかというと、髪が金髪になって逆立っているところ。 ハイパーネット助手(通称：ネット君） インター博士のただ１人のゼミ生。ネットワークについては全くの素人。 インター博士のゼミに入ったのは、評判の悪い博士から知識を奪い取り、いずれ取って代わろうという策略から。 どこらへんがハイパーかというと、オーラバトラーと共に巨大化するところ。
◆ IPアドレス - VLSM とは VLSM（ Variable Length Subnet Mask ）とは、1つのIPネットワークをサブネットに分割する際に、 複数の長さのサブネットマスクを利用する技術です。VLSMは可変長サブネットマスクとも呼ばれます。 ネットワークを分割する時に例えば「 /27 と /30 」の異なるサブネットを同時に利用する構成のこと。 このように、VLSMはクラスの概念にとらわれないクラスレスアドレッシングの手法の1つと言えます。 VLSMを利用することで、効率的なIPアドレッシングが実現できるのですが、VLSMを対応していない クラスフルルーティングプロトコル（RIPv1）が稼動しているネットワークではVLSMは使用できません。 ◆ IPアドレス - CIDR とは CIDR（Classless InterDomain Routing）とは、IPネットワー
CIDRとプレフィックス CIDRの効果 さて今まで説明してきた、サブネットマスクを使ったIPアドレスの管理方法 を“CIDR（Classless Inter-Domain Routing）”と呼びます。 「サイダー」と読みます。 CIDRは、クラスの概念を使わないIPアドレスの割り当てと、経路情報の集成 を行う技術をいいます。 CIDRは今やインターネットは勿論のこと社内ネットワークにおける、標準的 なIPアドレスの管理方法になっています。 経路集約についてはいずれ紹介していきたいと思います。 サブネットを含めたときのIPアドレスの表記方法でよく使われるのは、 “プレフィックス”を使った表記方法がよく使われます。 “プレフィックス”とは、ネットワークアドレス部分の長さのことで、IPア ドレスに続いて“/”と“ネットワークアドレスのビット数”を表記します。 例えば、 “IP Addres
セキュリティグループは、1 つ以上のインスタンスのトラフィックを制御する仮想ファイアウォールとして機能します。インスタンスを起動するときに、1 つ以上のセキュリティグループとインスタンスを関連付けます。各セキュリティグループに対してルールを追加し、関連付けられたインスタンスに対するトラフィックを許可します。セキュリティグループルールはいつでも変更できます。新しいルールは、セキュリティグループに関連付けられているインスタンスすべてに自動的に適用されます。インスタンスに到達できるトラフィックを許可するかどうかの判断では、インスタンスに関連付けられているすべてのセキュリティグループのすべてのルールが評価されます。 by AWS 要するにファイアウォール。 あるある事例 同じ様なポリシーが乱立 AWS担当者が一人の場合にはあまり起こらないが、複数人で設定を行うと同じ様な設定が複数個作られる。特にた
Details 前提 AWS で EC2 インスタンスを起動すると PublicIP/PublicDNS/PrivateIP がふられる。 PublicIP インターネット（外部）に公開されてるIP。例）54.123.456.78 PublicDNS DNSに登録されるホスト名。例）ec2-54-123-456-78.region.compute.amazonaws.com PrivateIP AWSのネットワーク内のみで使えるIP。例） 172.17.123.45 異なるリージョン間では、PrivateIPは使えない。名前解決するとプライベートIP出てくるけど。そんなの関係ない。 きっかけ EC2のセキュリティグループ設定を、必要最低限のネットワークに限定したい。 セキュリティグループにはIPアドレスも指定できますが、基本的に冗長構成組んでるとサーバ台数増えてくので、IPアドレスをいちい
サーバーやネットワーク機器を管理する際によく使われるのが、機器のリソース情報をネットワーク経由で取得するためのSNMPというプロトコルだ。SNMPではある瞬間のリソース情報しか取得できないが、これらを一定間隔で収集することで、リソースの時間的変化を観測できる。本記事ではこのようなSNMP経由でのリソース情報収集に利用できるツール「Cacti」について紹介する。 シンプルで使い勝手が良いUIが特徴のCacti サーバーやネットワーク機器の情報を取得して表示する管理ツールにはさまざまなものがあるが、昔から使われていたツールの1つに「MRTG（Multi Router Traffic Grapher）」というものがある。MRTGはSNMPというプロトコルを使って対象機器からリソース情報を収集し、グラフなどを作成するソフトウェアだ。MRTGは取得したデータを管理する「RRDtool」というソフトウ
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン（Google Compute Engineでは「ゾーン」）にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド（IaaS）に対応したシステム構築におけるもっとも基本的な考え方です。 しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失う
スタバやホテルなどで WiFi を使うと、たまに共有フォルダが見えていたり、しかも見たらダメそうなファイルが置かれていたりします。 共有フォルダくらいなら都度無効化すればいいかもしれませんが、意外とたくさんのサービスが有効になっています。試しに netstat -an | grep LISTEN してみると、意外とポートがオープンになっていると思います。 これらをしらみつぶしに無効化していくのは大変ですし、認証が必要とはいえオープンになっているのはあまり気持ちのいいものではありません。 ところで Mac OS X には OpenBSD 由来の pf という高機能なファイアウォールが搭載されています。これを使って Mac に対する攻撃（いたずら）を防ぐ設定をしてみました。 <追記> WEP などの脆弱性や、AP での盗聴を防ぐため、公衆無線 LAN では VPN は必須であると言われます。し
こんにちわ。せじまです。今年に入ってからアクティビティトラッカーを二回壊しまして、新しい分野の製品って設計いろいろ難しいんだなと、しみじみ思う今日このごろです。 先日、社内勉強会で Ethernet や CPU などの話をしました。前回のCPUに関する話に続き、今回のスライドも幅広い方に読んでいただけそうな内容かと思いましたので、公開させていただくことにしました。前回のスライドを読んでない方は、できればそちらを読んでいただいてからの方が、より理解が深まるのではないかと思います。 忙しい人のために三行でまとめると 2020年代には、サーバのネットワークインターフェースが 40Gbps 超えてそうな予感 もし Ethernet でそれだけ大量のパケットをさばくなら、（標準化されてないけれど） Jumbo Frame 使わないと厳しいかも 2020年代には、NICやブロックデバイス等、CPUを取
こんにちは！@kakeyangです！ 久しぶりの投稿です。 なぜなら、、、沖縄の八重山諸島に旅行に行ってましたのです！ 楽しかったなぁ（遠い目） 今回は、開発で経験した通信障害の原因とその対策を公開します。 原因がLinuxカーネルの設定だったので、結構苦労しました。。。 障害概要 異なるネットワーク内（片方は弊社ネットワーク）の物理サーバ間（弊社が受信側）でインターネット越しにソケット通信を行う。 毎回ではないが1割程度の割合で、送信側でconnection timeoutを観測。 受信側にはapacheのログが残っていなかったので、webサーバには届いていない。 送信側でtracerouteすると、確かに弊社ネットワーク内には入っている。 弊社ネットワーク内のF/Wから物理サーバの間のどこかで通信が途絶えているっぽい！ というところまではすぐに判明しました。 調査内容 データセンターと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く