超高速のPostgreSQLとしてGreenplumを気軽に使う
はじめに ビッグデータ、データサイエンスという言葉の流行を大きく後押ししたのは大規模なスケールアウト、分散処理を可能としたHadoopの存在です。しかしデータサイエンティストは日々のデータ処理作業において必ずしも複数台のマシンを必要とするような大規模な処理ばかり行っているわけではありません。自身の開発用ワークステーション1台で完結するような処理も多数存在します。 2016年ではもはや当たり前ですが、多くのワークステーションはマルチコアのCPUを搭載しており、CPUがボトルネックになるようなデータ処理をマルチコアを活かして並列処理する重要性は高まっています。しかし、意外に多くのソフトウェアが、この当たり前に期待される「マルチコアを活かして単一ワークステーション上で高速並列処理すること」が出来ていません。 この悩みから、筆者は過去にテキストデータ処理を簡単にマルチコア対応にするJavaフレーム
POODLE攻撃の検知とJavaによる検証コード
はじめに SSLv3のパディングに注目した攻撃手法であるPOODLEは、以前こちらのブログのエントリで取り上げたことがあるBEASTとCRIMEに非常によく似た攻撃です。今回はこのPOODLEについて、一般的な視点とはやや異なる、筆者独自の意見を述べてみたいと思います。 必ずしもSSLv3を無効にする必要はない POODLEの対策として書かれている情報はそのほぼ全てが「SSLv3を無効にする」というものですが、個人的には技術的にもう少し踏み込んで考えてみても良いのではないかと感じます。私は以前のエントリで次のように指摘しています。 BEASTもCRIMEも、意図しないリクエストが飛ばされ、そこにCookieが自動的に含まれてしまう点を攻撃するという意味で、CSRF攻撃の一種だと言えるでしょう。BEASTが発表されたらBEAST対策（RC4にする/TLSをバージョンアップする）を行い、CRI
Java1.7のSSLサーバでRC4を優先する方法
はじめに 以前このブログにおいて『Tomcatなど、Java製のサーバでBEAST対策を行う方法』というエントリを書きました。このエントリでは『JavaではSSL通信時に、基本的にサーバ側ではCipherSuiteの優先順位を決定することができず、クライアントが送ってくるCipherSuiteのリストが優先される』ことを示しました。また、この制限を回避するためのJSSEライブラリのハックについて紹介しました。 しかしこの方法はJava1.6系を前提としたもので、Java1.7では同じ方法を採ることができません。今回は、Java1.7系で使える手法をご紹介します。 jsse.jarを動かせなくなった Java1.6ではjsse.jarのみをJRE配下のディレクトリから取り出し、別の場所(/usr/local/jsse/lib/)に置くという方法を採りました。JavaアプリケーションサーバのT
ベイジアンネットワークを使ったウェブ侵入検知
はじめに 私たちが提供しているSaaS型のWAFサービス、Scutum（スキュータム）では、より高精度な攻撃検知を実現するために、ベイジアンネットワークの技術を利用しています。今回は「ウェブセキュリティ」「不正検知」「異常検知」「攻撃検知」といった観点から、ベイジアンネットワークについて解説します。 ベイジアンネットワークとは？ ウィキペディアによると、ベイジアンネットワークは次のようなものです。 ベイジアンネットワーク（英: Bayesian network）は、因果関係を確率により記述するグラフィカルモデルの1つで、複雑な因果関係の推論を有向グラフ構造により表すとともに、個々の変数の関係を条件つき確率で表す確率推論のモデルである。 非常に的を射た説明ですが、「わかっている人にはわかるし、わかっていない人にはわからない」という感じもするかもしれません。基本からしっかり理解したいという場合
CDNはじめました
はじめに 私たちが提供するSaaS型のWAFサービス、Scutum(スキュータム)に、CDNオプションが追加されました（CDNオプションについて、くわしくはこちらのページを参照ください）。今回は、主に開発者の視点から、このCDNオプションサービスの紹介をさせていただきたいと思います。 AkamaiのCDNサービスを利用 ScutumのCDNオプションにおいて、実際のCDNのサービスとしては、Akamaiを利用しています。Akamaiは言わずと知れたCDN界の巨人で、日本国内にも数多くのCDNサーバ（CDNにおいてエンドユーザへのコンテンツ配信に使われるサーバはPoPサーバ、エッジサーバなどとも呼ばれますが、ここではCDNサーバで統一します）を持っています。既に多くのサイトで利用されており、国内の著名なマスメディアのサイトなどでも広く利用されています。 AkamaiはCDN業界では老舗的な存
Amazon EC2のデータ転送量と課金まとめ
はじめに クラウドサービスの代名詞でもあるAWS(Amazon Web Services)が待望の東京リージョンを開設してしばらく経ちました。我々Scutum(スキュータム)はSaaS型のWAF(Web Application Firewall)サービスであるため、AWSのEC2のようなIaaS型のインフラ上に積極的に展開をおこなっています。本エントリではその際にポイントとなる、EC2でのデータ転送量への課金について調べてみました。 (クリックで拡大します) このエントリの内容はオフィシャルのウェブページやインターネット上の情報を元にしたものであり、実情と異なっている可能性もあるのでご注意ください。また、価格は東京リージョンのものとなっています。 AWSの複雑な課金体系 AWSの特徴のひとつとして、課金の仕組みが非常に複雑であることが挙げられます。これは高いオンデマンド性を実現するために仕
Amazon EC2 Spot Instanceが安い！
以前、IaaS型クラウドにおけるハードウェアの陳腐化についてというエントリで書きましたが、Scutumでは開発や検証用に、シンガポールのEC2でSpot Instanceを使用しています。c1.mediumのインスタンスを中心に数台を常に使用している状況ですが、これまで一度も価格上昇による停止を受けたことはありません。東京でも状況はそれほど変わらず安定した価格推移が続いているようです。 これを受けて、先日ビットフォレスト社内の技術会議において、これからEC2を使う際に、より積極的にSpot Instanceを使ってはどうかという方向のプレゼンを行いました。今回はその資料を公開します。
時系列ビッグデータを手軽に可視化するHadoopアプリケーション、Dunkhead
Dunkheadとは Dunkheadはタイムスタンプ付きのテキストデータ（アクセスログなど）を手軽に可視化するためのソフトウェアです。Hadoop上で動作するMapReduceアプリケーションであるため、データのサイズが大きい、いわゆるビッグデータの場合にも使用することができます。 Dunkheadは、入力データとなるログをもとに、サーバ監視ツールなどで見られるような、横軸が時間、縦軸が目的の値となる画像を出力します。下記の例はNASAのスペースシャトル、ディスカバリー号のミッションの際に記録された、NASAのウェブサーバのアクセスログをDunkheadで可視化したものです(こちらについて、詳しくは『HadoopとDunkheadでNASAのウェブサーバのアクセスログを解析・可視化する』を参照ください)。 各種サーバのアクセスログなどは、特に活用することなく、いつのまにか大量に溜まってし
テキストデータ処理を簡単にマルチコア対応にするJavaフレームワーク、MCPの実装
はじめに ログファイルなどの行指向のテキストデータを加工するタスクでは、多くの場合、awkやsed、あるいはperlなどのプロセスをパイプで組み合わせる、いわゆるワンライナー的なアプローチがよく使われます。また、ワンライナーでは収まりきらないようなちょっと込み入った処理を行いたい場合などは、各自得意なプログラミング言語でコードを書くことになります。このとき、多くの場合は、標準入力から1行ずつデータを読み込み、順番に処理していくというアプローチになるかと思います。 しかしこのようなアプローチには大きな欠点があります。それはCPUリソースを1コア分しか消費できないということです。grepのような簡単な処理で、CPUリソースではなくI/Oがボトルネックになる場合はそれでもまったく問題ありませんが、CPUがボトルネックになるような場合には、1つのコアだけでなく、マルチコアを使うことによって、処理が
IaaS型クラウドにおけるハードウェアの陳腐化について
はじめに 私たちが提供しているSaaS型のWAFサービス、Scutum(スキュータム)では、今年の春に開発環境を物理サーバからEC2へ移行しました。より安い料金でサーバを使用するため、シンガポールリージョンでSpot Instanceを使用しています。価格が非常に安く、また変動幅も少ないことから、お買い得感のあるサーバをかなり安定して稼働させることができています。 今回はこのEC2に開発環境を移行する過程で気がついた、EC2（あるいは、他のIaaS型クラウドサービス）を使用する上で気をつけたい、クラウドのハードウェアについてまとめてみたいと思います。 開発環境の目的 EC2に構築した開発環境の主な目的はパフォーマンステストです。シグネチャのチューニングやエンジン部のコードの変更などによってシステムのスループットにどのような影響が出るのかを常に把握しておくため、安定した環境が必要となります。
MongoDBとメモリ使用量
はじめに WAF「Scutum（スキュータム）」ではサービス開始時より、データストアとしてmemcachedとpgpool II+PostgreSQLを利用しています。これらはどれも安定して動いており満足しているのですが、最近になってより柔軟にデータを取っていきたいというニーズが高くなってきたため、MongoDBの導入を行いました。まだ完全なリプレースまでは至っていませんが、元々のデータベースのスキーマ構造がシンプルであることもあり、数ヶ月以内にはpgpool II+PostgreSQLの部分をMongoDB（Replica Sets）で置き換えることができるのではないかと思っています。 MongoDBにとっての「メモリ使用量」 MongoDBを導入するにあたり、Linux(X86_64）上でMongoDBを動作させたときのメモリの消費について、簡単にですが調べてみました。まず参考にしたの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
