xv6にネットワーク機能を実装した : DSAS開発者の部屋
在宅勤務に移行してから1ヶ月半ほど経過しました。通勤という概念が消滅したおかげで午前中から活動できるようになった @pandax381 です。 要約 フルスクラッチで自作した TCP/IP プロトコルスタックを xv6 に組み込み、一通りの機能が動作するようになりました。 I publish the implementation of TCP/IP network stack on xv6. I ported my user-mode TCP/IP stack, which was originally developed for learning, and added the e1000 driver and socket system calls. Some parts are still not enough, but they are working.https://t.co/nh
さよなら Parse : DSAS開発者の部屋
はじめに 世界中の利用者の指先と視線を凝固させた突然の発表からまもなく 1年、Parse.com の全サービスが いよいよ 2017年1月28日（土）に終了します。拡張性が高く高機能でありながら使い勝手の良い優れたサービスだったので終息が惜しまれます。 https://parse.com/ 手元では 2年ほど前に IoT の実験として試作した以下のしくみ「Anpi」で Parse.com を採り入れました。 mbed と Parse で作る高齢者世帯安否確認システム - 当ブログ 一般に BaaS の主な目的はアプリケーションの対向サーバ側機能を代替・補完することにあり、サーバの管理運用やサーバ側コード開発に踏み込むコストを抑制しアプリ本体の開発に注力可能となることが利用者にとってのメリットですが、Parse にはサーバ上でユーザコードを実行することのできる「Cloud Code」というし
#ISUCON 4 本戦で5位でした (lily white) : DSAS開発者の部屋
結果発表 にある通り、 KLab から参加した3チームは、 2チームが8000点前後の過密地帯で、 lily white だけがほんの少し飛び出て5位でした。 1位、2位が Cache-Control 勢、 3, 4 位が Public/Private ネットワーク束ねた勢だと思われますが、 lily white は API は public, 動画は private と使い分けたため、 片側の帯域を使い切った 過密地帯から少し上に出ることができて5位でした。 以下、時系列でどんな事をやっていたのかを残していきます。 前日: 休み、モニタリング環境準備 実は ISUCON 本戦への参加をカンファレンスでの講演と同じ休出扱いにしてもらって、 前日は振替休日として家族サービスと休息に割り当てました。 おかげで去年や予選時と違って途中で集中力を切らさず最後まで頑張れました。 一応モニタリングツー
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある : DSAS開発者の部屋
下記の文章は、PHPのセッションIDに対する攻撃についてFull Disclosure MLに2010年に投稿された文章を和訳したものです。訳者の意見としては、攻撃の成立条件は極めて厳しく、そこまで深刻度は高くないと考えています。 とはいえ、疑似乱数列への攻撃がどのように行われるのか、その可能性を示す文章は比較的珍しいもののように思います。暗号論的に安全な疑似乱数とは何か、なぜ必要なのかといった内容を間接的に教えてくれる面白い文章だと感じましたので、今回翻訳してみました。 （以下、原文の和訳です） 原文：http://seclists.org/fulldisclosure/2010/Mar/519 Advisory (c) 2010 Andreas Bogk <andreas () andreas org> Product:PHP Version:5.3.2 以降 脆弱性の種類:暗号論的な
WebSocket アプリの負荷分散 : DSAS開発者の部屋
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
Isucon用Webサーバーrecaro : DSAS開発者の部屋
11/3に開催された #isucon2 に、隣の席の @pandax381 と一緒に、チーム双龍として参加してきました。 結果は惨敗だったのですが、そのレポートを書く前に、 #isucon2 で使う予定だった秘密兵器 recaro について紹介します。 recaro とは recaro はカーネル空間で動く httpd + memcached サーバーです。 httpd サーバーは @pandax381 が作成した tkhttpd で、 memcached は kmemcached というプロジェクトが 未完成のまま放置されていたのを見つけて、私がデバッグ＆高性能化したものです。 (KLab/kmemcached) 通常のnginx+memcachedだと ネットワーク <- TCP/IP ]-> nginx <-[ TCP/IP ]-> Memcached ([] はシステムコール) と
過負荷をかわす Apache の設定 : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ＋ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
チューニンガソンで優勝してきました : DSAS開発者の部屋
7/9(土)にチューニンガソン というイベントに参加して優勝してきたので、その報告と、何を考えてどんなチューニングをしたのかを 記憶の範囲で公開したいと思います。 今回のチューニンガソンのお題は、WordPress(ja) + php + Apache + MySQL で、 ab を使って wp-comment.php 経由でコメントのポストをすることで計測が行われました。 MySQLとApacheを立ち上げたらWordPressが動く環境が渡され、そのWordPress自体は設定ファイルを含めて 改造が一切禁止、WordPressの実行をショートカットするチートも禁止です。 0. 試合前日 環境がAWSとAMI Linuxということは事前に公開されていたため、前日にAWSに登録して少しだけAMI Linuxを 触ってみました。yumベースだけどCentOSと違って結構新しいバージョンが用
チューニンガソン2で2位でした : DSAS開発者の部屋
10/1(土)にチューニンガソン2 というイベントに参加してきました。 もちろん前回に引き続き優勝を 目指していたのですが、今回は残念ながら2位でした。 今回もどんなチューニングをしていたのかの記録を公開します。 （ちなみに優勝したのは元KLabの濱野さんで、同じく メモを公開されています。） 今回のチューニンガソンのお題は、 Wikipedia の高速化で、 MediaWiki と Wikipedia の データが入った MySQL のデータには修正を加えずに、ランダムな100ページの表示速度を競いました。 マシンはメモリ1GBでデュアルコアのものが2台で、今回はWebサーバーの部分は自由に構成できます。 1. ボトルネックの確認 とりあえず AMI Linux の標準の php + apc で計測したところ、1ページの表示に1秒くらい使っています。 またphpか！ということで、やっぱり
phpを高速化する computed goto : DSAS開発者の部屋
前回 インタプリタ型言語を高速化する computed goto で紹介したcomputed gotoを、「phpでも使えないの？」という声が社内であったので、 php のソースコードを見たところ、特定のビルド手順で php でも computed goto が使えることが判りました。そのビルド手法とベンチマーク結果を紹介しておきます。 php の VM のソースコードは、phpソースパッケージ中の Zend/ というディレクトリの中にあります。zend_vm_で始まる幾つかのファイルのうち、 zend_vm_execute.h というファイルが命令ディスパッチが実装されているファイルで、このファイルは zend_vm_gen.php というスクリプトで生成されています。そして、 zend_vm_gen.php のオプションで、命令ディスパッチの方法を選択できます。(phpのビルドにphp
DSAS開発者の部屋:Android アプリケーションが起動するまでの流れ
プログラム開発のために Android 上でアプリが起動するまでの過程を調べてみました。備忘をかねて、ソースコードをひと通り追跡した記録をここに控えます。 まとめ ※クリックすると大きな図が開きます Zygote（ザイゴート）プロセスは、Android システムブート時に起動し DalvikVM 本体と Android プログラムの実行に必要なダイナミックリンクライブラリと Java のクラスライブラリをロードした状態で待機する常駐プロセスである Zygote プロセスの目的は、同プロセスを fork することによりプログラム実行用のプロセス環境を素早く効率的にシステムへ提供することにある UNIX ドメインソケット /dev/socket/zygote が Zygote プロセスへのインターフェイスであり、同ソケットにプロセス生成要求を送出すると Zygote はプロセス fork を実
Twisted vs Tornado vs Go で非同期Webサーバー対決 : DSAS開発者の部屋
昨日の takada-at の記事で「サーバー側では単純に100ms待ってからレスポンスを返すだけのページを用意しておき、」とあったのですが、今日はそのサーバー側の話をします。 もともとこのサーバーを作った動機は、takada-at が作成中の負荷試験システムがちゃんと並列に負荷をかけられるかどうかを検証するためでした。 すぐにレスポンスを返してしまうと、負荷試験スクリプトがきちんと並列に負荷をかけられなくても PV/sec が出てしまいます。 そこで、 epoll を使って高速に並列接続を扱えるTwistedフレームワークを使って、100msの遅延をしつつ数千PV/secに耐えるWebサーバーを作ってみました。 さらに、同じく epoll を使っている Tornado や Go にも興味があったので、こちらでも同じものを作成し、パフォーマンスを比較してみました。 コード まずは、コードを
最速TCPサーバーの条件 〜逆襲の Erlang と Haskell の挑戦〜 : DSAS開発者の部屋
釣った反響に応えて echo サーバーを改良していて PyCon JP の発表資料作成が進みません。 自業自得です。 methane です。 Erlangとは何だったのか でのベンチマーク結果では Erlang のスコアが奮わなかったのですが、 github で 性能改善する pull request をいただきました。 性能が悪かった原因ですが、実は backlog がデフォルトだと 5 で、ベンチマーク開始時の 大量の接続要求を捌ききれていないという状況でした。 高負荷サイトのボトルネックを見つけるには で紹介されている事例と同じ現象ですが、こちらのほうが backlog が小さく、 しかもベンチマーク用クライアントはほぼ同時に大量に接続をしてくるという条件で よりシビアに現象が発生してしまいました。 この問題が修正された Erlang は、 Go を超えて一気にランキング上位に踊り出
負荷試験ツール「インターネット破壊」を公開しました : DSAS開発者の部屋
負荷試験ツール インターネット破壊を公開しました。 こちらはずっと社内で負荷試験に使用していたツールです。社内で使用していたものなので、ソーシャルアプリ向けの機能などが多少追加されていますが、もちろんんそれ以外のWebアプリケーションでも使用できます。 基本的にはApache JMeterのようなWebアプリケーションむけのシナリオ負荷試験ツールです。コマンドラインオペレーションだけで実行でき、サーバー上で簡単に負荷試験を実施できるのが特徴です。POSTリクエストなどはもちろん、レスポンスのチェックやUserAgentの偽装、ランダムな値をパラメーターにセットする機能も実装しています。 注意: 当然ながら自分の管理下にないサイトに向けて負荷試験ツールを実行するのは絶対にやめてください。非常に危険です。 物騒な名前がついていますが、これは完全にわたしの小児的感性の趣味によるところです。地震で
パケットリピータ「stone」を Android へポーティング : DSAS開発者の部屋
オープンソースの多機能パケットリピータソフトウェア「stone」を Android 用にビルドしてみました。 当初は個人的に使用することが目的でしたが、原作者の仙石 浩明 (Hiroaki Sengoku) さんの了承のもと、ビルドずみバイナリを含むリソース一式を非正式版として公開します。他のプラットフォームで stone の便宜に馴染んでいる方はお試し下さい。なお、stone 本体の使用方法等についてはこの記事では触れません。公式サイトの解説記事を参照して下さい。 ■ Download (2015年5月 記事を更新） プロジェクト一式を GitHub へ移動しました。以下のリポジトリを参照して下さい。ビルドずみの実行形式も収めています。 ・ https://github.com/mkttanabe/stone-Android-NDK 以下の説明ではこのソフトウェアを「本ソフトウェア」と呼
こんなに簡単！ Linuxでロードバランサ (2) : DSAS開発者の部屋
前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
apache module 開発事始め : DSAS開発者の部屋
先日は，必要に迫られて Apache 1.3 の mod_access を改造したという話を書きました．その時は単にあるものを改造しただけでしたが，ふと思い立って，一から Apache 2.0 用のモジュールを書いてみました．書く上で色々 Web サイトを探してみたのですが，あまり日本語の入門向けの文章が見あたらなかったので，開発する上で分かったこと(と言うほど大したものじゃないですが)をまとめておこうと思います． フェーズには，例えばそのリクエストを受け付けるか拒否するかを決めるフェーズや，リクエストされた URI と実際のディスク上のファイルとの間の対応付けを解決するフェーズ，そしてもちろん実際のレスポンスを生成するフェーズ等があります．hook 関数を挿入するポイントはこれらのフェーズになりますが，もちろんその全てのフェーズのための関数を用意する必要はありません．また個別の設定を施す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
