タグ別アーカイブ: トラフィック

ナースコールが消える? 福井大病院に見る近未来の医療現場 (1/3) – ITmedia エンタープライズ

ICTインフラの刷新による効果の一例では、無線系のトラフィックが従来の5分の1から10分の1程度に減少した。山下氏によると、かつては診療開始時刻などに端末からシステムへのアクセスが集中し、CT画像など大容量データを含むトラフィックが発生していたが、シンクライアント化によって転送されるデータ量は大きく減った。

シンクライアント化で帯域も節約。従来のクラサバ型では大量のデータを端末側でも処理していたという

同時にマルチデバイス化も実現し、ICTの利便性が大きく向上。従来は必要なデータを専用端末でしか利用できず、医師や看護師らが病室と専用端末のある場所を往復しなければならないことも。この他にも「実はApple好きの医師が多く、従来はApple製品を利用できないなどの不満があったものの、シンクライアント化でなくなった」という効果も得られたという。

引用元: ナースコールが消える? 福井大病院に見る近未来の医療現場 (1/3) – ITmedia エンタープライズ.

さくらインターネット、HTTP 503エラーを回避する無料機能「リソースブースト」、突発なアクセス集中に対応 -INTERNET Watch

さくらインターネット株式会社は22日、レンタルサーバーサービスのトラフィック制限値を一時的に緩和する無料機能「リソースブースト」を提供開始した。

「リソースブースト」は、コントロールパネルからワンクリックで有効にできる

突発的なアクセスの集中などに対し、通常の数倍のアクセス処理能力に拡張できる。リソースブーストの設定は、コントロールパネルからワンクリックで有効にできる。有効期間は、開始ボタンを押した2日後の24時までで、次回使用可能になるのは14日後。

また、コントロールパネルからリソース状況を表示するリソースグラフを提供。CPU使用時間、転送量、PV数、ユニークユーザー数、HTTP 503エラー発生回数、HTTP 503エラーが発生したユーザー数を確認できる。

引用元: さくらインターネット、HTTP 503エラーを回避する無料機能「リソースブースト」、突発なアクセス集中に対応 -INTERNET Watch.

Geekなぺーじ:BGPフルルートは必要か?GREEの事例

GREEのビジネスモデル上、同社ASに対するアクセスの99%がモバイル網からです。日本国内モバイルキャリア3社との通信が、GREEへのアクセスの99%なのです。要は、日本国内モバイルキャリア3社との通信に極端に偏ったトラフィックを扱うという運用だったわけです。

フルルートを持つというのは、世界中の全てのネットワークへの経路を持つということですが、GREEにとってはフルルートは特に必要なものとは言えない状況です。たとえば、地球の裏側に到達するための経路を持っていたとしても、GREEはそれを使うことはなかったのです。

そういった背景もあり、GREEは、日本国内モバイルキャリア3社のパーシャルルート(Partial Route)と、デフォルトルート(Default Route)だけをトランジット提供者から受け取ることによって経路数を削減するという選択をしました。この変更によってGREEのBGPルータが扱う経路数が劇的に減少しました。2012年夏の障害当時40万経路だったものが、パーシャルルート+デフォルトルートに変えたことによって約2600経路まで減りました。2014現在は、さらに経路数が減って約1800になっているとのことでした。

フルルートをやめたことによって、ハイスペック機器にリプレースすることなく、運用し続けられているそうです。

引用元: Geekなぺーじ:BGPフルルートは必要か?GREEの事例.

コンテナベースのWP/DrupalホスティングPantheonが$21.5Mを調達, デベロッパツールの充実へ | TechCrunch Japan

Pantheonのホスティング技術は、今のWebホスティングの主流である仮想マシンではなくコンテナを使用する。それと、同社のインフラストラクチャが相まって、各サイトにきわめて高い可利用性と、トラフィックスパイクの強力な吸収能力を提供する。

引用元: コンテナベースのWP/DrupalホスティングPantheonが$21.5Mを調達, デベロッパツールの充実へ | TechCrunch Japan.

アノニマスが開発。インターネットなしでデータ通信を行える無線「AirChat」 « WIRED.jp

ネットから人々を遮断したり、デモの最中に携帯電話で連絡を取ることを不可能にしたりする。これはなにも、ディストピアSFのシナリオではない。電話やインターネットといった情報通信が破壊されるケースは、エジプトやシリアだけでなくリベラルなサンフランシスコのような場所でも確認されているし、天災の際にも起こりうることだ。

しかし、こうした状況下でも、インフラや通信事業者を必要とせずに、万人の手に届く手段がある。「無線」だ。

このアイデアをもとに、LuzSecやAntisec(いずれもハッカーたちが行った作戦だ)から生まれたアノニマスのメンバーのグループが最近立ち上げたのが、「AirChat」。コンピューター間で通信を行い、データ共有に利用できる、無線を用いたネットワーキングシステムだ。

行われる通信は暗号化することができ、ユーザーはトラフィックをプロキシやTorネットワーク(オープンソースの匿名通信システム)を通過させて、匿名性を確保することもできる。要するに、情報アクティヴィストの戦争のための本格的なキット、なのだ。

現在、プロジェクトは初期段階にある。システムのテストが行われ、チャットをしたり(音声通話を含む)、画像を送信することが可能になった。それだけでなく、ごくわずかでも共有されている接続があれば、インターネットに接続してTwitterやニュースをチェックすることができた。

引用元: アノニマスが開発。インターネットなしでデータ通信を行える無線「AirChat」 « WIRED.jp.

ヤフーは「フィーチャーフォン」を捨てさり、「スマデバ」に注力する | TechCrunch Japan

関係者に聞くところでは、すでにヤフー社内は「スマホというか、スマデバ(スマートフォンやタブレットスマートデバイス)のKPIしか見ていないと言ってもいいくらい」な状況だそう。実数までは聞けなかったが、Yahoo!ニュースのアプリなどもトラフィックを集めているとのことだ。

引用元: ヤフーは「フィーチャーフォン」を捨てさり、「スマデバ」に注力する | TechCrunch Japan.

月間通信量規制について思うこと | 無線にゃん

そういう意味では、ソフトバンクにだけはちょっとだけ賢い人がいるんです。締め日を三つに分割している。だから、トラフィックの集中は三分の一で済むんです。もともとそういう料金システムだったってのもありますが、これは規制の効果という意味で、他の二社に比べて圧倒的な差です。いくら周波数が多くても周波数間の負荷分散はそれほど上手く進むものではありませんから、周波数の多寡に関係なく、月初の品質はソフトバンクが今後飛びぬけてくることになるはずです。それでも、同じ日に多くの人の規制が一斉に解除されるという「月単位規制」は余りに馬鹿げていると私は思いますけどね。

引用元: 月間通信量規制について思うこと | 無線にゃん.

参加レポート: LINE Developer Conference (Infra Day) | Developers.IO

1つはIDC内部でのConnection Timeoutの発生について。LINEのシステムではインターネットを介した通信だけでなくサーバ間通信も多く発生する仕組みとなっているそうですが、そのサーバ間通信が行われるIDC内部のL2スイッチでパケット廃棄が多発する自体が発生したとのこと。トラフィック量としてはL2のスループット性能以下であり問題無くスイッチング出来るはずだったのですが、原因としては瞬間的にトラフィックがバーストした際にL2スイッチのバッファがオーバーフローしパケットが廃棄されてしまっていたそうです。なおこの現象は連続してトラフィックが発生している場合では問題が無く、バースト時のみに発生するとのこと。なかなか切り分けが難しいトラブルですね。LINEのようなメッセージサービスは性質上バーストが起こりやすく(例えばイベントで何かが起きた場合、サッカー日本代表がゴールを決めたとき等。またオフィシャルアカウントはフォロワーに一度に数十万人に対してメッセージを送るため瞬間メッセージ流量が跳ね上がるそうです)、対策としてバッファサイズの大きなL2スイッチに変えたり、バーストが発生しやすいようなサーバは独立したネットワークに分離するなどを行われたそうです。

引用元: 参加レポート: LINE Developer Conference (Infra Day) | Developers.IO.

Snapchatを支える技術:768台のRedisをGoogleクラウドで構築 #gcpja – Qiita

Snapchatの成功のカギがGCPのPaaSであるApp Engineであったことは、じつは昨今のImmutable InfraやDockerのムーブメントに通じるところがある。それは、

App EngineではアプリケーションをDisposableかつStatelessでShared Nothingに設計しなくてはならない

アプリケーションをVMではなく超軽量なコンテナで運用し大規模にスケールアウトさせる

構成管理とデプロイをRepeatableにしてバージョンアップやフェイルオーバーに手間をかけない

といった点だ(ただしApp EngineにはDockerほどのプラットフォーム透過性はない)。例えばApp EngineにGoのアプリケーションをデプロイすると、およそ50ms(!)ほどでコンテナが起動し、トラフィックのスパイクがあるとまたたく間に数100や数1000の規模でオートスケールする。また、アプリケーションのImmutable設計が強制されるおかげで、大規模なバージョン切り替えやデータセンター間フェイルオーバーさえGoogle任せにできる。

引用元: Snapchatを支える技術:768台のRedisをGoogleクラウドで構築 #gcpja – Qiita.

Facebookページリーチ激減り、ただ乗り終了のお知らせ : ギズモード・ジャパン

Facebookを宣伝に活用している企業はみなお金を払わないと、いいね全員に投稿を届けられないことになります。

ナイキは1%でも16万人だから結構な数ですけど、僕が好きなNYのレストラン「Pies ‘n’ Thighs」なんて3281いいね!しかない(大体は最新情報が本当に欲しい地元民だと思うのだけど)ので数十人しかリーチできなくなる計算。もっと小さな店だと、ひとり…とか。それもリーチした相手が本当に読んだとして、ですからねぇ…。

1、2%で嫌なら、もちろん広告料を払えば全員に配ってもらえます。が、大企業だとお値段もそれなりになりそうですね。

「企業にとっては大激変だ」と情報元は言ってました。パニックされると困るので、フェイスブックは「戦略の方向転換」という奥歯に物の挟まったような呼び方をして1社ずつ説明してます。でも手遅れかも。マジソン街(米広告業界)ではちょっと前からエンゲージメント数が「激減り」した話がもう噂になってるので。

教訓はふたつ。まず、「ブランド」は所詮ブランド、いくら身近にフレンドリーに見えても所詮は宣伝ってことですね。ナイキが新作シューズの写真を無料で何百万人に一斉配信できなくなっても困るのはナイキだけ。まあ、ちっちゃな店や人も自己PRに使えなくなっちゃいますが。やっと獲得したフォロワーもカーテンで仕切られて、お金出さないと出してきてもらえないなんて、これまで一生懸命やってきた人はバカを見ますね。

教訓その2。フェイスブックも所詮は会社、慈善事業でも非営利でもアートプロジェクトでもないってことです。 儲けは二の次で、綺麗なもの、いいね取れるものを作れば、儲けは空から降ってくる、なーんてのはテック業界が植えつけた幻想、まやかしです。世界のナイキが儲けなきゃならないようにフェイスブックも儲けなきゃならなくて、単に後者の無料トラフィック誘導のホースが干上がって悲鳴をあげるのは前者ということで。

引用元: Facebookページリーチ激減り、ただ乗り終了のお知らせ : ギズモード・ジャパン.