自分がこれまでの人生で、自分では予期できないけれど、そのおかげで人生が大きく変わり今の自分がある、そして今もなおその流れに乗り続けられている、そんな「たったひとつの乗るべき電車」とはなんだっただろうか。 今月で自分は35歳になるわけだが、なんとなく自分の人生の折返し地点間近に来ているという感覚がある。 そこで、まだまだ35年という短い人生でありながらも、そこそこの今の自分がある、そのために自分が乗るべきだった「たったひとつの電車」について振り返ってみた。 小学3年生から漠然と中学受験の勉強の波に飲まれ、右も左もわからないまま、気がついたら大学に来ていたように思える。 その過程では、自分が乗るべき電車があったかどうかすら気がついていなかっただろうし、ひょっとすると何度か電車が来ていたかもしれないが、そのことすら気づかずボーッとしていたように思える。 ただ周りが勉強するから、親が勉強を促してく
今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法（PoC）について紹介します。 その前に、まずは前提の一致ということで、僕は以前から、Webサーバプロセスの性質について、プロアクティブ性とリアクティブ性という分類について述べてきました。 プロアクティブ性とリアクティブ性について簡単にまとめると、以下のようになります。 Webサーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピュータリソースを使用しないように設計することも重要である． 単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリテ
7年前の僕はひとたび外に出ると何者でもないエンジニアでした。会社で周りよりも仕事を覚えてこなすのが少しだけ早い、会社の独自仕様に詳しい、それぐらいだったように思います。 ある日、自分が本屋に行ってふと一冊の技術雑誌を開いた時に、そこに書かれている技術はほとんどわからず、自分の得意分野の技術でさえ、社内でやっていることは当たり前のこととして書かれていた上で、さらにそれを高度に一般化し解決する技術が解説されていました。それを見た時に、自分の技術が単に社内独自の業務を経験的に知っているだけであったことになんとなく気付かされました。 ただ、この雑誌に書いている人は本当にプロフェッショナルな専門家なのだろうとしばらくは思っていたのですが、後に執筆陣も自分と同様に会社で働いているエンジニアであり、何も状況は変わらないことに気づき、その人達の経験に基づく一般化された知識とその応用力、それを可能とする視座
hb.matsumoto-r.jp 以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。 とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。 そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい） そこで一旦、最低限socket()システムコールとconnect()システムコールで接続する時のパケットをtcpdumpで眺
本記事は、mruby advent calendar 2016の23日目の記事です。22日は、ore_publicさんのruby製のコマンドラインツールをmrubyに置き換えるでした。 mrubyインタプリタ、mrubyの実装的にはmrb_state構造体なのですが、一つのプロセスの中で複数mrb_stateを作らざるを得ない場合に、複数のmrb_state間でデータを共有して使いたい場合がありませんか？ふむふむなるほど、やはり皆さん共有したいようですね。 これまでは、mrb_state間でデータをコピーする際にドキュメントに書かれていない知識を使って頑張ってやる必要があったのですが、それを簡単にできるように、mrubyのC APIを拡張するmrbgemのmruby-pointerを作りました。 github.com 今回はその使い方を説明します。 典型的な使い方 例えば、とあるmrb_s
Webサーバのベンチマークをとるのが趣味になりつつあるmatsumotoryです。 Webサーバのベンチマークについては、abからはじまりwrk等を使っていたのですが、最近ではほぼh2loadを使っています。 h2loadはnghttp2というHTTP/2ライブラリのアプリケーションに含まれているツールですが、 HTTP/2（SPDYも）とHTTP/1.xに両対応している ベンチマーク側の同時スレッド数を増やせる TLS及びSNIもサポートしている 最小、最大、平均、標準偏差あたりもちゃんとでる ので、色々プロトコルを変えつつ同じベンチマークツールで、値の目安を出すにはとても重宝しています。 Nghttp2: HTTP/2 C Library - nghttp2.org 実行結果のサンプルは例えば以下、 $ h2load -c 100 -n 10000 https://localhost:
この記事は、mruby advent calendar 2015の16日目の記事です。 画像やstaticコンテンツ配信系はHTTP/2が有利な状況が幾つかあるので、ついでにHTTP/2を喋る画像変換サーバのプロトタイプをmrubyで作ってみました。ベースはもちろんtrusterdです。なんていったってmrubyのHTTP/2サーバですからね！！ 最近また開発を再開しておりまして、昔はh2oやnghttp2のベンチマークに一緒に比較対象として入れてもらったりしていたのですが、しばらく離れているうちに皆さん先へ先へと行ってしまわれたので、また追いつけるようにセッセと勉強しながら実装しだしております。 github.com その他、trusterdについてはこの辺とか、 qiita.com この辺を見ていただくと良いかと思います。 hb.matsumoto-r.jp trusterdのビルド
CPUやメモリ、IOといったリソースの制限下でとあるコマンドを実行させたい場合に、cgroup上に何かgroupを作ったりしてからcgexecを実行して、実行後はそのgroupを消す、といったような一手間かかる方法がほとんどでした。 実行後のgroupも綺麗にしたい、といった所まで考えるとなかなか手間がかかっていたので、それらを全てワンラインでできるrconというワンバイナリで動くツールを作りました。 github.com 例えば、負荷サーバでの調査ツールを流す際に、CPUとかIOとかを制限しつつドロドロ実行したい場合等に便利です。Linuxのcgroup対応した環境でのみ動きます。 使い方 ほぼREADME通りなのですが、オプションは代替以下のようになっています。 --memは変なので--memoryに変更しました!! ./rcon --help Usage: rcon [options
昨日、ngx_mrubyのTCPロードバランシング機能に対応した記事を書きました。 hb.matsumoto-r.jp というのも、実は以下に説明するようなFluetnd+Norika+GrowthForecastを利用したスケールアウト型のシステムを簡単に作りたかったからです。 ということで、まずはプロトタイプ設計みたいなものをフワっと考えてみました。 実現したい事 まずやりたいこととして、 1000台以上のサーバ群からのFluentdによるTCPデータをそれぞれの転送元サーバに紐づく任意のバックエンドサーバに振り分けたい 転送元サーバ群はそれほど増減しない バックエンドサーバをスケールアウト型に増やす場合に、転送元サーバの設定は変更したくない 転送されたログは転送先サーバ内でグラフ化されるので、任意のHTTPクライアントによって取得したい転送元サーバのグラフ画像を適切なバックエンド（F
nginxのv1.9あたりからOSS版でも使えるTCPロードバランシング機能をmrubyでプログラマブルに制御できるようにngx_mrubyでもサポートしました。 github.com これで、HTTPやHTTP/2だけでなくTCPのロードバランシングでもmrubyによって通信をプログラマブルに制御できるようになったわけです。 nginxのTCPロードバランシング機能は、nginx内部ではstreamモジュールとして、httpモジュールとは別で実装しているため、ngx_mrubyでも一から実装し直す必要がありました。 ということで少し面倒だなぁと思っていたのですが、ちょうど、僕の最近やりたい事としてTCPのロードバランサをもう少しプログラマブルに書きたいというのがあって、色々とTCPロードバランサを探したり、既存のソフトウェアで設定を試行錯誤するよりも、自分でnginxのTCPロードバラン
といっても、既存のmruby-mrbgem-templateをもう少し使いやすくしただけですが。 以下の記事を受けて、もう少し簡単にしたいなぁと。 inokara.hateblo.jp ksss9.hatenablog.com 使い方 まずはいつもどおりmgemをcloneして、 git clone https://github.com/matsumoto-r/mruby-mrbgem-template.git && cd mruby-mrbgem-template/ その中にある template_config.rb を自分の作りたいmgemの設定にします。この場合、作りたいmgemはmruby-exampleで、カレントディレクトリ（mrbgem_prefix）にディレクトリを掘りたいとします。 params = { :mrbgem_name => 'mruby-example', :
mrubyの機能拡張には、mrbgem（以下mgem）という所謂CRubyでのgemのような拡張モジュールを使います。mgemを開発していくと、もちろん以前作ったmgemの機能を再利用したい場合や、すでに存在する優れたmgemを使ってさらなる機能を実装したい場合が多くなるはずです。 昔は、mrubyのbuild_config.rbに粛々と依存するmgemを羅列していって、ビルドして依存関係に関する警告が出たらそのmgemを追加していくというかなり面倒な作りになっていました。 ですが、今は開発したmgemの所謂設定であるmrbgem.rakeファイルに依存関係を書いておくと、自動的にそれをmgem-listと呼ばれるmgemの登録リポジトリから検索してビルドしてくれるようになっており、以前と比べると非常に簡単になっています。 つまり言い換えると、mgem-listに登録していないmgemに関
福岡の博多で開催されたHacker Tackleという技術イベントで、「HTTP/1.xとHTTP/2が混在する時代のウェブサイト設計とmruby in HTTP serverの可能性」というタイトルでお話をしてきました。 hackertackle.github.io HTTP/2に関しては既に素晴らしい発表が幾つかされており、特に今年のYAPC::Asia 2015で id:kazuhooku さんと id:Jxck さんが発表されたHTTP/2の内容は素晴らしいです。今回の僕の発表で同じような所を喋ってもどうしても二番煎じになってしまうため、よりサーバ実装についてや実際に使う時にHTTP/2のどういう特徴がチューニングに関わってくるかという話を、mruby組込みをまじえてお話しました。特に、サーバプッシュや優先度制御、それを制御するための方法について言及しています。また、現在公開できる
社内での新卒研修を中心になってやってくれている okkunの提案で、キャリア・キーノートという取り組みを行っており、その中でWebオペレーション研修の記念講演ということで、恐縮にも自身のキャリアキーノートについて発表する機会を頂けたのでお話してきました。 研究の内容については、 okkun の以下の記事が参考になるかと思います。 blog.hifumi.info 技術者・研究者という立場から自分の人生を振り返ったような内容になり、これまでの自身の苦悩や絶望、そこからのブレイクスルーなどを振り返り話す事ができる良い機会となりました。 僕が技術者・研究者としてこれまでやってきて得た教訓を、教訓が得られたエピソードと共にまとめました。 話している中で色々な事を思い出し、あの時の葛藤や苦悩、さらには絶望した時の感情が沢山沸き上がってきましたが、それでも今自分はこうやって楽しく技術を学べている事に本
virtualingとは、わりとセキュアでCPUやメモリ・IOといったリソースの制御が可能なプロセス実行環境上で、設定や構成を変える事なくミドルウェアのようなプロセスを動作させることができるツールです。実装はmrubyです。 github.com hb.matsumoto-r.jp リソース制御なので、例えばプロセスのメモリ使用量の上限を制限していた場合に、その制限を超えると従来通りOoM-Killerが走るわけですが、virtualingの特徴的な機能として、そのイベントを自動で検知し任意のRubyブロックをコールバックする機能があります。 それを利用して、今回はOoM-Killer判定が下されたイベントを検知したら、メモリ制限値を自動で拡張していくような処理を試してみました。 virtualingの設定 設定はRubyで書く事ができます。今回は、OoM-Killerを検知した時にOoM
Kazuho's Weblog: jailing - chroot jailを構築・運用するためのスクリプトを書いた virtuald + ipalias + cgroup + これで快適に「そこそこ隔離したサービス環境」作っていきましょー / “Kazuho's Weblog: jailing - chroot jailを構築・運用するためのス…” http://t.co/aweVwa9kDX— MATSUMOTO, Ryosuke (@matsumotory) 2015, 5月 14 まずは昨日サクッとこういうのを作られたkazuhoさんのjailingを見ていて、こういうのやっぱり面白いなー素晴らしいなーと思いつつ、そういえば僕もmrubyでこういうの書くとか宣言していたなーというの思い出しました。 mruby-cgroup、mruby-capability、mruby-criuがで
1年前ぐらいにab-mrubyという、Rubyでabコマンドをプログラマブルに操作・拡張できるツールを作っていたのですが、それを業務のとある環境で使ってみたところまぁまぁ良かったのでその使い方を紹介しようと思います。 github.com というのも、特定の条件でベンチマークで負荷をかけていくとプロセスがハングするという状況があって、その状況を再現するためにabコマンドでベンチマークをかけていたのですが、abコマンドのオプションがパッと見わかりずらかったり、どのホストのどのパスにベンチマークをかけているかなどをドキュメントで書いていて、 あれ、これRubyのDSLで表現した方がわかりやすくない？ と思って、ab-mrubyを作っていたことを思い出し、Rubyで書いてみました。 target_hosts = ["test001.example.jp", "test002.example.jp
4月からペパボで働いているわけですが、前々から噂できいていたメモリリークの問題について、ペパボではわりと大規模かつ高負荷な環境でngx_mrubyを使ってくれているのでその環境を見ながらメモリリークを改善してみました。 状況的には、16時間動かしていると導入している環境のngx_mrubyを組み込んだnginxが1GBぐらいメタボっていました。 実装や幾つかの調査情報をみつつ、以下の2点においてメモリリークが発生していました。 mrubyが例外をあげて5xx系のエラーコードを返す時 mruby_set系のディレクティブを使っている時 上記のそれぞれにおいて、C側で生成したオブジェクトをarenaに登録したまま、不要になったにも関わらずarenaからオブジェクトを除外してGCさせるように処理できていなかった事が問題でした。 これらを、ほぼ同等の改修によってmrb_gc_arena_save(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く