ヤフーにおけるWebサービスのアクセスコントロール
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、R＆D統括本部 開発推進室 セキュリティプラットフォーム技術 セキュリティスペシャリストの戸田 薫です。 今回は、ヤフーにおけるWebサービスのアクセスコントロールについてご紹介します。 ヤフーでは、会社組織やWebサービスの運営面でいろいろなアクセスコントロールを行っています。 アクセスコントロールをする目的には、いくつも理由がありますが、たとえば、以下の理由が挙げられます。 お客様やパートナーの情報を守らなければなりません。 サーバの制御を奪われ、攻撃に利用されてはいけません。 システムの不正な利用を予防しなければなりません。 今回は、ヤフーのWebサービスにフォーカスして説明をします。 インターネットからヤフーへ
ネットワーク性能のチューニング (Sun Fire T2000編)
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Sun Fire T2000には4ポートのGbEが装備されているので、これを束ねれば理論的には4Gbpsのスループットが出ます。しかし、Sun Fire T2000はうまくチューニングしないと、CPUに余裕がある場合でも低いスループットしかでないので注意が必要です。 Solaris 10のTCP/IPスタックについては、「特集記事: Solaris OS ネットワーキング -- マジックの種明かし」が詳しいです。これによると、着信パケットをデバイスの割込みからTCPの出口まで、squeueというデータ構造を使って1つのCPUで処理することがわかります。この場合のCP
Geekなぺーじ : 2009年2月17日 世界的インターネット経路障害解説
2009年2月17日に発生した世界的なインターネット経路障害に関しての解説、及びその後調べたことです。（参考：インターネットが壊れました）。 BGPとは何かに関しての解説も書いたので、インターネット通信技術そのものに関して知りたい方はそちらもご覧下さい。 何が発生していたのか？ チェコのプロバイダが非常に長いAS pathを流してしまい、その長いAS pathを受け取ったルータがBGP peerを切れたり上げたりを繰り返しました。 BGPのpeerが切れた次の瞬間に、また接続し直してpeerが復活し、そしてまた問題のAS path情報を受け取って切れるという状況を繰り返してしまったようです。 BGP peerが切れるのは、パケットがISP間で転送されなくなるという事なので、世界中で「到達出来ない場所」が発生しました。 この障害は約1時間弱続きました。 問題をトリガーしたチェコのプロバイダと
さくらインターネット移行記#2 VPN越しのMySQLレプリケーション
前回さくらiDCに移転し始めた、ということを書いたのですが、あれから一ヶ月ちょっとが経過しましてその後も順調に iDC への移転が進んでいます。すでにラックもいくつか借りて、サーバーも数十台がさくら iDC で稼動しています。回線がこれまでよりも高速なバックボーンに接続されつつ、帯域幅も大きくなったことから、移転したサービスによってはこれまでよりもパフォーマンスが出ているサービスもあります。うち比較的大きなデータを扱うフォトライフも移転を完了していますが、おかげさまで画像の読み出しがかなり速くなったのが体感できるぐらいスループットが向上しました。 既存サービスを移転するにあたって、どういった構成でそれを行っているかをちょっと紹介してみようと思います。 移転当初は、既存のはてなのサービスとはあまり関係していないサーバー群から手を付けました。例えば広告のシステムといった、はてなのデータベースを
cookieのサイズはパフォーマンスに影響を与えるか - bits and bytes
私は "回線が早くなった現在、データの転送よりもコネクションの確立にかかるオーバーヘッドの方が大きい" という根拠のない信念を持っています。 だから、今ではバイト数を節約するよりも、Vitamin Features » Serving JavaScript Fast のような方法でコネクションを抑えることのほうが速度的には効果があるだろう、考えていました。 そんなところに おぎろぐはてな - Cookieがパフォーマンスに与える影響 経由で Performance Research, Part 3: When the Cookie Crumbles » Yahoo! User Interface Blog に、クッキー500バイトでレスポンスを15ms改善できるという記事を見つけて、単純に500バイトを15msで割ったら300Kbps程度で日本じゃあり得ない遅さですが、小さいファイルの場
TAKESAKO @ Yet another Cybozu Labs IE6でja.wikipedia.orgが遅い件をHTTPキャプチャしてみる
最速インターフェース研究会 :: 最近IE6でWikipedia日本語版の表示が異常に遅いのはKeepAliveのせい 2月初めぐらいからか、キャッシュが空の状態で日本語版のWikipediaを表示すると、IE6が1分間ほど固まる、という不具合があるそうだ。 で、Proxomitronでレスポンスとか調べてみてたりしたのだけれど、プロキシ経由だと問題なく表示される。 これ、私が普段仕事で使っているIE6でも再現していたので、HTTP Debugging Proxy - Fiddlerを使ってブラウザのHTTP通信をキャプチャして調べてみました。 （※2007/02/13追記：upload.wikimedia.orgで対策され、既に本現象は解消されています） どうやら画像ファイルhttp://upload.wikimedia.org/wikipedia/ja/b/bc/Wiki.pngの読み
終了いたしました。
作者ホームページサービス（hp.vector）は終了いたしました。 長らくのご利用、ありがとうございます。 ご不明な点があれば、お問い合わせページをご覧の上、お問い合わせください。 ※15秒後にトップページに戻ります。 (c) Vector HOLDINGS Inc.All Rights Reserved.
リバースプロキシ ＆ ロードバランサ ― Pound
リバースプロキシ ＆ ロードバランサ(reverse-proxy and load-balancer)で、 リバースプロキシ ： ブラウザからのリクエストを１台以上のバックエンド・サーバに渡す（バックエンド・サーバからは、Pound が動作しているマシンからのリクエストにみえる）。 ロードバランサ ： 複数台のバックエンド・サーバにリクエストを分配する（優先順位の設定可）。 SSLラッパ ： ブラウザからのHTTPSリクエストをHTTPでバックエンド・サーバにリクエストする（HTTPしかサポートしていないサーバをHTTPS対応にできる）。 HTTP/HTTPS サニタイザー ： 要求の正当性を確認し、正しいもののみを受け入れる。 フェイルオーバー ： バックエンド・サーバのヘルスチェックを行い、ダウンしているサーバにはリクエストを送らない。復帰を検出したら自動的に通信を再開する。 リクエス
Ultra Monkey:
チャットボットサービスは年々その市場規模を拡大していますが、その中でも高い効果を実感でき、比較的安価に利用できることで人気なチャットプラスというサービスがあります。 チャットボットを導入したいけどサービスごとにどんな違いがあるのかわか...
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
こんなに簡単！ Linuxでロードバランサ (3) : DSAS開発者の部屋
前回はkeepalivedを使ってWebサーバを冗長化してみました。 今回はkeepalivedのもう一つの機能であるVRRPを使って、ロードバランサ自身を冗長構成にしてみたいと思います。 ┌─────┐ │ client │ └──┬──┘ │[10.10.31.200] │ ━━━━━━━┯━━━━┷━━━━━┯━━━━━━━━━ 10.10.31.0/24 │ │ │ │ │ ←(10.10.31.10) → │ │ ←{10.10.31.100}→ │ [10.10.31.11]│ │[10.10.31.12] ┌─┴─┐ ┌─┴─┐ │ lv1 │ │ lv2 │ └─┬─┘ └─┬─┘ [192.168.31.11]│ │[192.168.31.12] │ ←(192.168.31.10)→│ │ │ ━━━━━━┯┷━━━━━━━━━━┷┯━━━━━━━━ 192.168.3
DSAS開発者の部屋:ネットワークパケットを覗いちゃえ
レイヤを問わず (ethernet から HTTP や SMTP まで) 、ネットワーク絡みのトラブルシューティングや挙動の確認をするときにパケットの流れが見られると非常に有益です。 開眼すると「パケットの流れが目で見える」そうですが、私などはまだまだ修行が足りず裸眼では見えないので、tcpdump というツールを使って見ています。 tcpdump はその名前があまりよくないと私は思っていて、"tcp" だけでなく udp やICMP や ethernet フレームまで覗ける超強力ツールです。 というわけで tcpdump の簡単な説明を書いてみます。 tcpdumpについて tcpdump は UNIX 系の OS で使えるツールなのですが、Windows 用にはWinDumpという CUI のツールがあり、tcpdump と同じように使えます。 GUI がお好みの方は、後でも紹介するE
LimeChat
1ウィンドウで複数のサーバに接続できる 充実したキー操作で、快適な操作感を実現 詳細に渡るカスタマイズ機能 軽快で安定した動作 インクリメンタル検索で快適なログ検索 JavaScript でスクリプトを書ける
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.ethereal.com/
Wireshark
Fiddler HTTP Debugger - Fiddler
CLON - 2006/12/30 - もしかして typo？ 機能
http://neta.ywcafe.net/000639.html
http://ultramonkey.jp/papers/lvs_tutorial/html/
ネットワーク構築 A to Z [I]～基礎から始める最適ネットワーク設計～