新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング | Amazon Web Services
Amazon Web Services ブログ 新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング Elastic Load Balancing(ELB)は、Auto ScalingとAmazon CloudWatchを含む3つの組みの一部としてローンチした2009年以来、AWSの重要な要素になっています。それから、私たちは多数の機能を追加し、そしてApplication Load Balancerをリリースしました。コンテナで稼働するアプリケーションに対するアプリケーションレベルでのコンテンツベースルーティングをサポートする様に設計されており、Application Load Balancer はマイクロサービス、ストリーミング、リアルタイムワークロードと相性が良いです。 長年にわたって、私達のお客様はあらゆる規模のwebサイトや、アプリケーシ
[PDF] 08/25の通信障害概説
08/25の通信障害概説 Matsuzaki ‘maz’ Yoshinobu <maz@iij.ad.jp> maz@iij.ad.jp 1 観測されている概要 • 2017/08/25 12:22JST頃 • AS15169が他ASのIPv4経路をトランジット開始 • ⽇頃流通しない細かい経路が⼤量に広報 • これによりトラヒックの吸い込みが発⽣ • 国内の各ASで通信障害を検知 • 2017/08/25 12:33JST頃 • AS15169がトランジットしていた経路を削除 maz@iij.ad.jp 2 観測された問題のBGP経路概要 • 経路数 • 全体で約11万経路 (⽇本分が約25000経路) • /10から/24まで幅広い経路(半数程度が/24) • 通常流れていない細かい経路が多かった • AS PATHは概ね “701 15169 <本来のAS PATH>” • 広報元A
8月25日に発生した大規模通信障害をまとめてみた - piyolog
2017年8月25日12時過ぎより、Webサイトにつながらない等の接続障害とみられる事象が複数発生しました。また同時間帯にNTTコミュニケーションズ、KDDIから障害報告が発表されています。ここでは関連情報をまとめます。 インシデントタイムライン 日時 出来事 8月25日 正午過ぎ Googleが誤った経路情報を送信。 〃 12時22分 NTTコミュニケーションズのOCNバックボーンで通信障害発生。 〃 12時24分 KDDIのサービスで通信障害発生。 〃 以降 日本国内の複数のサービス等で接続障害が発生。 〃 送信後8分以内 Googleが誤設定情報を修正。 〃 12時39分 KDDIの通信障害が復旧。 〃 12時45分 NTTコミュニケーションズの通信障害が復旧。 〃 夕方頃 各組織で発生した障害が概ね復旧。 8月26日 Googleが誤設定を認め、謝罪する声明を発表。 8月29日 総
［続報］OCNの通信障害、米グーグルによる誤った経路情報の大量送信が原因か
2017年8月25日、NTTコミュニケーションズ（NTTコム）のインターネット接続サービス「OCN」で発生した通信障害に関して、インターネット通信関連の識者は誤った経路情報が大量に流れたことが原因ではないかとの見方を示した。ここでいう経路情報はルーターがBGP（Border Gateway Protocol）というプロトコルを使って交換するものだ。 日本ネットワークインフォメーションセンター（JPNIC）の岡田雅之氏は、NTTコムは複数の組織と対等な関係でネットワークの経路情報をやり取りしているが（これを「ピアリング」という）、そのうちのある組織が誤った経路情報を大量に流したのではないかと話す。その結果、「NTTコムを介してインターネットに接続していた企業のルーターが、大量の経路情報を受け取り高い負荷がかかり、一部はフリーズしたような状態に陥るなどして通信障害につながったのではないか」（岡
ネットワークでなぜ遅延が生じるのか
入門 Kubeflow ～Kubernetesで機械学習をはじめるために～ （NTT Tech Conference #4 講演資料） 2020年1月31日 株式会社NTTデータ / NTT DATA Yuki Nishizawa ↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤：たった一つのプ
なぜネットワーク運用自動化が進まないのか Why is it difficult �to automate network operation
2015/4/24に開催された wakamonog x ssmjp x BIGLOBE = wasabi イベントで発表した資料です。http://ssmjp.connpass.com/event/13173/ This is lightning talk presentation for study event in Tokyo.Read less
high-performance packet filtering with pflua — wingolog
Greets! I'm delighted to be able to announce the release of Pflua, a high-performance packet filtering toolkit written in Lua. Pflua implements the well-known libpcap packet filtering language, which we call pflang for short. Unlike other packet filtering toolkits, which tend to use the libpcap library to compile pflang expressions bytecode to be run by the kernel, Pflua is a completely new implem
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
DMM inside
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
久々に絶対読め本が来た - L'eclat des jours(2014-05-13)
_ 久々に絶対読め本が来た オライリーの高さんから、ハイパフォーマンスブラウザネットワーキングを頂いた。 どんな本かもわからなかったけど書影を張った甲斐があった（わけないだろうな）。実に良い本を頂けた。どうもありがとうございます。 この本は、名前の書名の通りに受け取ると妙にピンポイントだけど（なぜなら、ブラウザネットワーキングをハイパフォーマンスさせるための技術書だとしか読めないし、ブラウザネットワーキングって妙な言葉だけど、Webブラウザにしか関係しなさそうに読める）、全然違う。 この本は、小手先の技術書ではない。 だから、ネットワークにパフォーマンスを要求するためには、まずネットワークとは何でどのような技術で、どのような種類があり、それぞれにおいてどのような制約や特徴があるのか、からきちんと説明がある。 最初は、レイテンシ（遅延のこと。遅延といったって、伝播遅延、伝送遅延、処理遅延、キ
急増するLINEインフラの課題と対応 « LINE Engineers' Blog
こんにちは。今回はITサービスセンターより、インフラ運営の観点から急増するLINEインフラの課題と対応について記させていただきます。 はじめに 先日開催したLINE Developer Conference（インフラ編）には大勢の方にいらしていただきました。カンファレンスでは、LINEサービスが始まってから約2年の間に我々はどういった方法でインフラ運営を行い、またどんなことに悩んできたのかを、システム、データベース、ネットワークの観点からそれぞれ発表させていただきました。 カンファレンスはLINE株式会社が様々な技術をどのように使い、どのように運用を行っているのか。現在どのような技術的なことに取り組んでいるのか日本のエンジニアの皆さんに知っていただくために開催されました。結果としてインフラ編では150名の定員に対して430名のご応募をいただいたとのことでLINEサービスに対する関心の高さを
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
18 Commands to Monitor Network Bandwidth on Linux server
Network monitoring on Linux This post mentions some linux command line tools that can be used to monitor the network usage. These tools monitor the traffic flowing through network interfaces and measure the speed at which data is currently being transferred. Incoming and outgoing traffic is shown separately. Some of the commands, show the bandwidth used by individual processes. This makes it easy
Docker networking basics & coupling with Software Defined Networks
Docker networking basics & coupling with Software Defined Networks This presentation reminds Docker networking, exposes Software Defined Network basic paradigms, and then proposes a mixed-up implementation taking benefits of a coupled use of these two technologies. Implementation model proposed could be a good starting point to create multi-tenant PaaS platforms. As a bonus, OpenStack Neutron inte
AWS Solutions Architect ブログ
とはいえ、VPCは物理的な線があり、NICがあるいわゆる物理環境と違うのも事実です。そしてAWSがサポートしていないことがいくつかあることがわかっています。それはIPv6対応であり、Multicast対応であり、イーサネットフレームのコピーであったりします。そんなことを実現するために、トンネリングがしばしば使われます。 その方法は多数知られています。パケットをいじる以上、そのいじり方に応じてトレードオフがあり、それぞれの目的のために実装も異なります。標準化されている方法としては、IP-in-IP (rfc1853)、Generic Routing Encapsulation (rfc2784)が、よく使われています。また、ネットワークデバイスの仮想化技術として知られるTUNとTAPもよく使われています。乱暴ですが、これらをまとめると次のようになります。
A tcpdump Tutorial with Examples
A tcpdump Tutorial with Examples 50 ways to isolate traffic for cybersecurity, network administration, and other technical roles Introduction Overview of tcpdump Basics of traffic isolation Getting Started with tcpdump Viewing traffic on an interface Viewing HTTPS traffic Limiting packets Information Security Examples Capturing credentials Monitoring suspicious domain traffic SMB Traffic Capturing
サーバの仮想NICに準仮想化ドライバ(virtio-net)が使用できるようになりました
さくらのクラウドでは、幅広いOSで利用可能なIntel PRO/1000を標準仮想NICとして提供していましたが、本日より準仮想化ドライバ(virtio-net)への変更が可能となりました。これにより、virtio-netに対応したOSにおいては安定性や性能の向上、低CPU負荷といった効果が期待できます。 本機能は、サーバに「@virtio-net-pci」タグを付与することで有効化されます。詳しい設定方法は「特殊タグ一覧」のページを参照ください。 ※パブリックアーカイブのWindows2008、Windows2012で作成したサーバはvirtio-netに非対応のため、タグを付与しないでください(virtio-net対応アーカイブは近日の公開を予定しています)。 参考: ベンチマーク結果 参考として、弊社にてベンチマークテストを行った結果を示します。e1000(Intel PRO/100
いかにしてベンチャーの社内ネットワークを構築するか - UNIX的なアレ
情シス担当者なんていない 現在、nanapiは社員数30名弱くらいの会社規模です。アルバイトさんを含めると70名くらいになりますが、そのうちエンジニアは私を含めて8名。このくらいの会社の規模だと、まだ情シス的な仕事を専門的にやるような人はいません。 当然、ネットワークの専門家もまだ弊社にはいないので必然的にエンジニアの誰かがこのあたりを担当することになります。ベンチャーにおいてだいたいの場合、こういった技術的な行き場の分からない仕事ってのはCTOがやるもんです。 しかし、情シス的な仕事って本当に難儀な仕事。動いてて当たり前、高速で当たり前、ちょっとでもネットワークが遅くなるものならその時点ですでに障害です。 外注するという選択肢もありますが、何かしら社内でネットワークのトラブルがあれば少なくともその瞬間はたぶん僕が対応するなり調査するなりすることになります。どうせそうなるのであれば、自分で
LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
