Tech Sketch Bucket of Technical Chips by TIS Inc.

Passive OS Fingerprint を node.js から利用してみた。

Pocket

Passive OS Fingerprint

インターネットは広く標準化されているTCP/IPプロトコルで通信をしていますが、インターネット上のすべてのコンピュータが同じ実装を共有しているわけではありません。
そのために、それぞれに実装されたプロトコルスタックの癖や、致命的ではないバグと言うべきような微妙な挙動の差異があります。

本記事はそのプロトコルスタックの癖やバグを解析し自前のデータベースと照合することで、通信相手のOS、ネットワーク環境(NAT/Proxyの有無)、起動時間などを受動的に取得するソフトウェアであるp0fの動作原理の説明およびその動作環境を作成します。

それに加えて、アプリケーションでの利用例としてアクセスしてきたマシンのOSなどの情報を表示するWebアプリケーションをnode.jsを用いて作成します。

PostgreSQLの同期レプリケーションを検証してみた

Pocket

企業向けシステムのOS, Webサーバー, アプリケーションサーバーにオープンソースのソフトウェア(以下OSS)が普通に使われるようになってきていますが、データベースにOSSのPostgreSQL, MySQLを使うのが当たり前になった、とはまだまだ言えない状況です。

その理由の1つは「可用性を確保するソリューション不足」だと思います。実際、PostgreSQLやMySQLにOracle RACに匹敵する高性能、高可用性を実現するソリューションはなく、秒単位で停められないシビアな可用性を求めるシステムには商用製品のDBが今後も使われるでしょう。

ただ、世の中のシステムはほどほどの可用性を安価に実現したいケースが多く、OSSのデータベースを使ったソリューションが現実味を帯びてきます。例えば、PostgreSQLやMySQLに組込まれたレプリケーション機能を使えば、複数サーバー間のデータを同期するクラスタを安価に構築できます。

ここではOSSのデータベースでクラスタを構築する際によく使われるレプリケーション機能に焦点を当て、 PostgreSQLのバージョン9.1から実装された同期レプリケーション機能を検証してみます。

Meteorを使ったリアルタイムチャットアプリケーション

Pocket

はじめに

デモ動画 が何とも印象的なJavascript Framework 「Meteor」 を使ってシンプルなチャットアプリを作ってみました。
現状ではDBに対して変更を加える際に認証ロジックが存在しないため、実用的なアプリを作ることは難しいですが、DB=ソース=画面表示が常に同期している感覚と、クライアントブラウザからDBを変更しているかのような感覚はなかなか新鮮です。時間の無い人はデモ動画だけでも見てみると 頭を抱えられる 面白いかと思います。
#自分はデモ動画を見た後、頭を抱えてなんだこれ・・・と呟いていました。

Meteorの特徴については綺麗にまとまっている記事があるので、ここで改めて解説はせず、以下の記事に任せたいと思います。

リアルタイムチャットアプリ

さて、Meteorの特徴を掴むためにサンプルアプリを作ってみました。
Meteorの性質を考えるとリアルタイム性が高い物が向いていると思われる為、部屋毎に別れて話し合えるチャットアプリを作り、meteor.com上で公開しています。

Simple Chat: http://simple_chat.meteor.com/

Simple Chatのソースコード: https://github.com/tech-sketch/meteor_chat

複数のブラウザで同じページを開いておくと、1つのブラウザで投稿した内容が、リアルタイムに全ブラウザに反映されるのがわかるかと思います。
また、毎時00分にはサーバ側から部屋Aに対して自動的に時報が配信されます。1時間に1回なのでちょっと確認しづらいですが、部屋Aを表示しておくとサーバ側から配信されたメッセージがリアルタイムに反映されるのが分かるかと思います。

続いてコードを見てみたいと思います。

リアルタイム分散処理Stormの耐障害性は?

Pocket

techsketch-banner-OSS+startingblock(700x65).jpg

リアルタイム分散処理とは

「ビッグデータ」処理のためにHadoopを用いますと、「複数のマシンに大量データ処理を分散して飛躍的に性能を向上する」ことが容易に可能となります。
ところがHadoopの弱点としまして、ビッグデータをいったん蓄積し、バッチで一括処理する形態で処理が行われますので、処理データが発生してからそれに対する処理結果が得られるまで必ずタイムラグが発生します。このため、クレジットカードの不正アクセス検知、センサーデータなどでの異常値検出のようなリアルタイムなレスポンス(低レイテンシー)が要求されるビッグデータ分野へのHadoopの適用は向いておりません。
このような随時発生する大量データ(ストリーミングデータ)を、蓄積せずにリアルタイムに処理する「リアルタイム分散処理」が求められています。
今回は、リアルタイム分散処理のソリューションとしてTwitter社より公開された Storm に着目し、サンプルアプリケーションでは実装されていないデータが正常に処理されたかを判断する機能等の、Stormの耐障害性を中心に紹介していきます。