Time Flies

fckey's Tech Blog

Elasticsearch 101

Elasticsearchを使う機会があったのでBasicsをメモ。

Elasticsearchとは?

ElasticsearchApacheプロジェクトの一つである検索用サーバでApache Luceneの上に構築されている。RESTfulなインターフェイスで分散型の構成や全文検索が可能であり、基本的に取り入れるデータの定義、検索クエリ共にJSONで記述される。

仕組み?

ESの導入や基本的な構成はこのあたりのページを見たらだいたいわかると思う。

http://code46.hatenablog.com/entry/2014/01/21/115620 http://engineer.wantedly.com/2014/02/25/elasticsearch-at-wantedly-1.html

基本的にESで重要なのは以下の2点である。

  1. 取り込むデータの定義
  2. 検索の詳細の定義

これらの中でも特にキモとなりそうな点を以下にメモ。

使用方法?

以下では実際にElasticsearchを動かしながらIndexの設定と簡単なクエリの発行を行う。 なお、今回使用した全てのJSONここにある。

取り込むデータの定義

Elasticsearchのインデックスは基本的にはスキーマレスではあるが、取り込むデータのフィールドの定義やdelimiterをmappingにて定義しなけれな成らない。 以下ではデータ整形とフィールド定義の2つのパートに分けて説明する。

データの整形フォーマットの定義

まずここでは取り込むデータの整形フォーマットの定義を行う。以下のJSONmappingの前半部分である。

整形方法の定義はanalyzerに記述され、このanalyzertokenizerfilter の組み合わせによって定義される。 tokenizerは文字列の分割方法を定義し、以下の例にあるngram_tokenは最小2文字、最大3文字のngramを利用する。 filterは分割後の文字列の整形処理を定義するのだが今回は利用しなかった。 analyzertokenizerfilterを組み合わせて複数定義することが可能であり、それぞれのfieldで異なるanalyzerを利用することが可能である。

  "settings": {
    "analysis": {
      "analyzer": {
        "ngram_analyzer": {
          "tokenizer": "ngram_token"
        }
      },
      "tokenizer": {
        "ngram_token": {
          "type": "nGram",
          "min_gram": "2",
          "max_gram": "3",
          "token_chars": [
            "letter",
            "digit"
          ]
        }
      }
    }
  }
フィールドの定義

以下のmappingの後半ではインデックスとして登録される各フィールドのデータ型、使用するanalyzerを定義する。

今回作成するmappingの"sushiya"では、それぞれのフィールドは寿司屋の名前、住所、緯度経度情報を保持する。 ここでは、nameはスペースごとに文字列を分割するデフォルトanalyzerである”whitespace”を使用し、addressに対しては上記にて定義したngam_analyzerを使用した。

 "mappings": {
    "sushiya": {
      "properties": {
        "name": {
          "type": "string",
          "analyzer": "whitespace"
        },
        "address": {
          "type": "string",
          "analyzer": "ngram_analyzer"
        },
        "location": {
          "type": "geo_point",
          "store": "yes"
        }
      }
    }
  }

以上にて定義した寿司屋情報保持用のmappingをsample_mapping_sushi.jsonとして保存し、以下のコマンドにてrestrantインデックスとして定義する。 curl -XPOST localhost:9200/restaurant -d @sample_mapping_sushi.json

データの登録

今回はお気に入りの寿司屋を以下のように定義し登録する。_bulkはまとめてデータを登録するためのパラメータである。

curl -XPOST localhost:9200/_bulk -d ' 
{ "index": { "_index": "restaurant", "_type": "sushiya", "_id": "1" } }
{ "id": "1", "name": "鮨水谷", "location" : [35.66836,139.761106], "address" :"東京都中央区銀座8-7-7" }
{"index": { "_index": "restaurant", "_type": "sushiya", "_id": "2" } }
{ "id": "2", "name": "すきばやし次郎", "location": [35.672614,139.764037], "address" : "東京都中央区銀座4-2-15" }
{ "index": { "_index": "restaurant", "_type": "sushiya", "_id": "3" } }
{ "id": "3", "name": "久兵衛", "location": [35.672614,139.764037], "address" : "東京都中央区銀座8-7-6" }
{ "index": { "_index": "restaurant", "_type": "sushiya", "_id": "4" } }
{ "id": "4", "name": "かねさか", "location": [35.667989,139.762643], "address" :"東京都中央区銀座8-10-3"}
{ "index": { "_index": "restaurant", "_type": "sushiya", "_id": "5" } }
{ "id": "5", "name": "鮨 なかむら", "location": [35.662347,139.729366], "address" : "港区六本木7丁目17−16" }
'

ここでデータの定義について軽く説明すると以下の通りである。

{ "index": <-インデックスの情報について
    { "_index": "restaurant",  <-どのインデックスを利用するか
      "_type": "sushiya",  <-どのマッピングをを利用するか
      "_id": "1"          <-keyとなる任意の文字列
    } }
{ "id": "1", <-先に定義したidと一致するように定義
 "name": "鮨水谷", <-ミシュラン三ツ星(高い)
"location" : [35.66836,139.761106], <-geo_point typeの形式に沿った緯度経度情報
"address" :"東京都中央区銀座8-7-7"   <-銀座は高値の象徴
}

検索の詳細の定義

Elasticsearchの検索はqueryfilterによって行い, 抑えるべき点は

  • queryはscoreに影響する。
  • filterはscoreへの影響はないがキャッシングの有無の選択が可能

という点である。詳しくは公式のリファレンスを追って欲しい。

クエリの定義

ここではまず、簡潔なクエリの定義を行う。以下のクエリは鮨という単語を全てのフィールドに対して検索している。

{
  "query" : {
    "simple_query_string" : {
      "query": "鮨",
      "fields": ["_all"],
      "default_operator": "and"
    }
  }
}  "default_operator": "or"
}

そしてその返り値が以下の通りである。店名に"鮨”をもつ水谷となかむらが含まれている。

  "took" : 4,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 2,
    "max_score" : 0.067124054,
    "hits" : [ {
      "_index" : "restaurant",
      "_type" : "sushiya",
      "_id" : "1",
      "_score" : 0.067124054,
      "_source":{ "id": "1", "name": "鮨水谷", "location" : [35.66836,139.761106], "address" :"東京都中央区銀座8-7-7" }
    }, {
      "_index" : "restaurant",
      "_type" : "sushiya",
      "_id" : "5",
      "_score" : 0.067124054,
      "_source":{ "id": "5", "name": "鮨 なかむら", "location": [35.662347,139.729366], "address" : "港区六本木7丁目17−16" }
    } ]
  }
}
Scoreの定義

さらに、Elasticsearchでは検索スコアの重み付けがクエリ内で可能である。

見ての通り、以下のクエリでは店名に”鮨”が入っていればscoreを10倍し、場所が一定範囲内(六本木駅から2km)の場合はスコアが100倍される。

また他にもアクセスカウントによるsortの定義や、自身で定義した計算式によるscoreの計算も可能であり、非常に柔軟なクエリを記述する事ができる。

{
  "query" : {
    "function_score" : {
      "query" : {
        "simple_query_string" : {
          "query": "鮨 銀座 六本木",
          "fields": ["_all"],
          "default_operator": "or"
         }
      },
      "score_mode": "multiply",
      "boost_mode": "multiply",
      "functions" : [
        {
          "filter" : { "term" : { "name" : "鮨"}},
          "boost_factor" : 10
        },
        {
          "filter" : { "geo_distance" : { "distance" : "2km", "location" : [35.66, 139.73] }},
          "boost_factor" : 100
        }
      ]
    }
  }
}
"sort" : [{ "access_count" : {"order" : "desc", "missing" : "_last"}}]
"script_score" : {
        "script" : "doc[\"access_count\"].value * 100"
      }

おわりに

以上に上げたとおり、Elasticsearchはデータの取り込みもクエリの組み立ても非常に容易に出来る。

最近良く見られるのがElasticsearchとKibanaの組み合わせであり、例えばfulentdで得られたログ情報をElasticsearchに取り込むことでログの整形を容易にし、Kibanaで可視化することでログの分析が簡単に行える。

また、クローリング用のプラグインや、日本語の形態素解析用のプラグインが既に出回っており、Elasticsearchを取り巻く環境は確実にに発展している。 Elasticsearchは簡単に設定ができ強力であるため新しく検索エンジンが必要になった場合には使用をおすすめしたいフレームワークである。

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)

Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築

Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築

広告を非表示にする

アルゴリズムと人、数式と鮨。

アルゴリズムが世界を支配する。

検索エンジンのインデキシングやページランク、高頻度取引、商品のレコメンドエンジンなど今やありとあらゆる所でアルゴリズムが利用されている。もちろん人より精度も速度もアルゴリズムが圧倒時に優っている。

これからは人がアルゴリズムを”使う”というよりは、アルゴリズムが人の意思決定をする事の方が多いだろう*1

そもそも人は考える行為を他に任せるのが好きな生き物だと思う。その一例がインターネットだ。

インターネットは偏在している知をへのアクセスを可能にした。一部の学会所属者のみが読めた論文、海外の情勢や景色、普段は接することのない高齢者と話すことでのみ知り得た戦争の話、職人的技能。そういうものを多くの人間の手が届くものにしたのがインターネットだ。

しかし、インターネットを通して情報を利用し多くの人が思考を加速させるはずだったのだが、人は考える事をすらも外部に頼るようになった。ハードディスクだけでなくCPUすらインターネットの向こう側に任せてしまった。大学生のWikipediaのコピーレポートがいい例だろう。

そして人は他人に頼るだけでなく無機質で感情のないアルゴリズムにも頼っている。映画評論家の勧める映画ではなくアルゴリズムが選んだ自分の好みの映画を選び、編集者が構成した新聞記事ではなくアルゴリズムが選んだニュースを嬉々として読む。

人の役割は次第にアルゴリズム取って代わられ、より正確で素早い結果が得られるようになる。

GoogleAmazonFacebookなど一部の優秀な人々が作っている大きな流れにのり、世界はアルゴリズムに支配される。 良い記事、良い商品は人ではなくアルゴリズムが選び我々に選択肢は与えられない。

一方で、人はアルゴリズムに負けていい部分とそうでない部分があるらしい。その違いなんだろうか。

例えば、Lispで書かれた作曲家エミー。デイヴィッド・コープ氏によって作られたこの作曲家はバッハの曲を学習データとして使用し、多くの曲を生み出した。 エミーが作曲した曲は出来がよく、あるオーケストラ様に作った曲はあまりに感動的でアルゴリズムが作った曲だとはわからない音楽家が居た。 しかし、そういった曲達がアルゴリズムによって出来たものだと知ると「魂がこもっていない」などと避難し、冒涜しているとコープしを殴るものも居た。 楽曲の質は良くとも人に作られたか、アルゴリズムにより作られたかで評価はがらりと変わってしまう。

将棋電王戦ではコンピュータ側が人間のプロに勝ち越した。将棋に詳しくないプログラマからするとコンピュータが勝つのは妥当のように思われる。単純なソートもダイクストラの最短経路も人は速度でコンピュータにはまず勝てない。 それと同様にこの完全情報ゲームで一流のプロ達はコンピュータに負けた。 棋士は歳をとると思考力は落ちるが、積み重ねた経験からくる直感で最善手が見え強者で居続けるという*2。 しかし、多くの解法パターンの中から最適解を見つけ出すコンピュータの側は、ある意味力技で直感力で戦う棋士達に勝った。 これは人類のコンピュータに対する敗北のようにも感じられ、計算能力からすると当たり前のように思われるのだが、同時に何か悔しい気持ちがあるのは自分だけじゃないと思う。

アニメPSYCHO-PASSもコンピュータによる支配と人間による支配の受け止め方に対する示唆に溢れている。 このアニメでは人の犯罪を起こす可能性が数値として表されており、その犯罪係数の高低によって可能な就職先や生活基準が決定さる。さらに係数が一定数を超えると実行していなくても逮捕されてしまう。 作中でこの数値はコンピュータの演算で行われているとされているが、実際は多数の人間の脳をつなぎあわせて導き出されていた、という展開がある。このことが公表されるとまずいという描写があるが、何故だろうか。 アルゴリズムで犯罪者と宣言されることと、人の脳の連結体にそう言われることは何が違うのだろう。

アルゴリズムは合理的な選択をする。疲れは感じず余計な情報にも影響されない。そして人も何かを選択をするとき、突き詰めていけばアルゴリズムと同じ選択をするだろう。 違いは何か。人とアルゴリズムの違いは”無駄”を重要視することじゃないだろうか。 伝統や感情、偏見、見栄など功利的に考えたら省くべきものを人は時に重要視する。本来必要ではないこれらの無駄たちがこそが人を人たらしめているのだろう。

伝統を重視するからこそ機械的に並べられた音符は受け入れられず、単調に動く機械には人は負けたくない。 同時に、人を判断するのは偏見やしがらみを持つ人ではなく、情報を黙って無感情に処理するコンピュータでないと納得がいかない。

無駄を省き正確で素早い意思決定が可能なアルゴリズムはこれから先も我々の生活を確実に向上させるだろう。

それでも僕は生産管理されたネタと機械的に生産されるシャリで作られる鮨より、職人が自身で見分けた魚を捌いたネタと手で重みを感じながら握られたシャリでできた鮨を食べつづけていきたいと思う。

記事に関連した筆者のオススメ

4Gamer.net ― 「ひろゆき」みたいな人間が増えていくと,人類は滅亡する!――川上量生氏との対談企画「ゲーマーはもっと経営者を目指すべき!」年末特別号

世界を支配する10種類のアルゴリズム : ライフハッカー[日本版]

アルゴリズムが世界を支配する (角川EPUB選書)

アルゴリズムが世界を支配する (角川EPUB選書)

世界でもっとも強力な9のアルゴリズム

世界でもっとも強力な9のアルゴリズム

アルゴリズムトレーディング入門 (ウィザードブックシリーズ)

アルゴリズムトレーディング入門 (ウィザードブックシリーズ)

*1:もしかしたら知らないうちに

*2:評価関数の精度と探索エンジンの性能が優れているということだろう

Web系企業のビジネスモデルと収益構造 (印象派)

Web系企業のビジネスモデルについて聞かれたのでWeb系企業関係者でもなんでもない自分がなんとなく考えてみた。

収益モデル

ぱっと思いつくのは以下の感じで、それぞれBtoBとBtoCでモデルに多少違いがあって*1表にちょっとまとめてみるとこんな感じかな。

モデル BtoB BtoC
広告 掲載 アフィリエイト
EC 物販 物販
手数料 仲介サイト オークション
サービス提供 プラットフォーム(ショバ代) プラットフォーム(User向け)
コンテンツ内購入 - ゲーム
  • 広告
    • BtoB 広告を掲載する場の提供をしてお金を貰う企業で広告代理店とかかな。FaceBookなんかは企業広告で稼ぐので我々ユーザーは顧客と言うよりむしろ商品なんだよね。e.g. GoogleFacebook
    • BtoC 広告を掲載するだけじゃ駄目でやりとりがあって初めて利益が発生するモデル。アフィリエイトとかかな。BtoCと言うかは微妙だけど。
  • EC
    • ECに関して物を売って稼げたらという点では企業でも消費者でも同じかな。企業向けだと量が必要そうだし個人向けならマニアックなものを集めてロングテールでやるとか販売戦略は違いそう。e.g. Amazon
  • 手数料
    • BtoB 転職や住宅情報を掲載して取引成約したら取引先の企業から手数料をもらう。
    • BtoC オークションだったりマーケットプレイスみたいにユーザが商品を提供して取引があった場合に手数料をもらう。モデルとしては場を提供して利用者の取引からピンはねする点ではBもCも同じ。
  • サービス提供
    • BtoB 手数料と被りそうだけどプラットフォームを提供してコンテンツの提供者から場所代として売上に応じてピンはね。やっぱりプラットフォーム提供者になれたら強い。e.g. DeNAGREE
    • BoC ユーザがサービスを利用するために課金するモデル。月額制、従量課金制、頭金のみと色々あるけどWebだとやっぱりフリーミアム形式が多い印象かな。 e.g. ニコニコ、Hulu
  • コンテンツ内購入
    • ゲーム等でその中でしか使えないアイテムを販売するモデル。ユーザからしたらお金を使えば使うほどコンテンツから離れ難くなる心理が働くからいい商売だど思う。

今後

現場の人間じゃないから詳しく知らないけどどうなんでしょ。クラウドファンディングなんかはこれから広がっていきそうだと思う。開発者の立場からするとRailsを始めとしたフレームワークが多くあるので学習コストが格段に下がりWebサービスを立ち上げることは簡単にできるようになったけど、これはどうマネタイズするんだろうっていうサービスも多々ある印象。そういうのの大半は広告で小銭を稼ごうとするのかな。

企業がサービスを立ち上げるならこれからはWebのみでなくやはりスマホ等のネイティブアプリも平行して展開して行かないと戦えなさそう。家に帰ってPCを開かずスマホで完結する層が増えたと思うけど、スマホのWebブラウジングってめんどくさいからWebだけだとなかなか使ってもらえないだろうな*2

以上、非Web関係者の印象。

Web開発の基礎徹底攻略 (WEB+DB PRESS plus)

Web開発の基礎徹底攻略 (WEB+DB PRESS plus)

Web業界 受注契約の教科書 Textbook for Business Contracts in the Web Industry

Web業界 受注契約の教科書 Textbook for Business Contracts in the Web Industry

Web ビジネスのためのユニバーサルデザイン成功の法則65

Web ビジネスのためのユニバーサルデザイン成功の法則65

*1:BtoB、Cの分け方はかなり雑。モデルの違いが理解できたらok。

*2:エロくらいかな

オフィスのGoogle化を試みる投資銀行

Banks ‘Googlize’ Their Offices to Land Tech Talent (投資銀行が優秀なITエンジニアを惹きつけるためオフィスをGoogle化する)

投資銀行も優秀なITエンジニアの確保に本気になってオフィス環境から変更していくらしい。

外資投資銀行といえばアルゴリズムによるHFT *1に力を入れているためコンピュータサイエンスや数学・物理学の専門家を多く雇っている。所謂ロケットサイエンティストというやつである。

近年の投資銀行の利益の大半はM&Aや引受業務などの手数料ビジネスよりトレーディングによるサヤ取りによって生み出されるため、より早くより多くの取引を可能にするためのシステム構築に特に熱心になっている。 また、取引に関わる部分以外でも決済システムやドキュメント自動生成などあらゆる面でITに関わり仕事をするため技術力の差がファームの位置づけの差になると言っても過言ではなく、投資銀行は優秀なITエンジニアの確保に余念が無い。

しかし、近年は欲しい人材がシリコンバレーに流れてしまう傾向があるようだ。以前なら給与面でウォール街が人気だったのだろうが、金融危機後はウォール街での給与が落ち込み、逆にシリコンバレーにあるようなスタートアップでは(プチバブルもあって)給与水準が高まっている*2。 この傾向はFacebookTwitterの台頭以降顕著であり、さらに自分の好きなことをして一発当てるアメリカンドリーム的な側面もある。

給与の面では最終的には差はなくなるのだが伝統的で保守的な投資銀行と新興のスタートアップでは労働環境がかなり異なり、お堅いオフィスでスーツを着て働くのとビリヤード台を横目にカジュアルな服装で自由な雰囲気で仕事をするのとでは仕事へのモチベーションが変わってくるだろう*3

特に、GeekでTechyな連中というのはカジュアルでオープンな雰囲気を好む傾向にあるようで、投資銀行でもそういった人材に魅力的に思われる環境づくりを進めていくらしい。 自分の知っている限りでも投資銀行で働くエンジニアは優秀な人が多いと思うので良い人材良い労働環境に囲まれて働きたいのなら選択肢の一つとしてオススメである。

日本のSIerなんかもこういう面から労働環境を改善して優秀な人材に魅力的に感じてもらえるように成れたらと思うのだけどね。(そもそも彼らはGeek的な優秀さは求めてないかもしれないけど。)

*1:High Frequency Trading - 高頻度取引

*2:新卒アナリストの場合、ウォール街のエンジニアは$70k前後、シリコンバレーなら$100kくらい貰えるらしい。

*3:個人的にはスーツでカッチリとキメたビジネスマンもカッコイイとは思う

Uncle BobがCTOなったら開発者にプロフェッショナルとして求めるもの

Clean Codeの著者でありアジャイル開発の第一人者であるRobert Martin (Uncle Bob)がプロフェッショナルなエンジニアとして大切なことは何かを語った動画が面白かったので要点をまとめた。

SCNA 2012: Robert Martin - The Reasonable Expectations of Your CTO on Vimeo

  • We will not ship shit

エンジニアとして最低な制作物を提供するな。我々を雇う人々は我々のコードを読めないし、何をしているのかもわからず良し悪しを測ることも難しい。彼らに出来ることは締め切りを提示することだ。我々エンジニアだけが何が出来上がるのかを知ることの出来る唯一の存在である。自分たちが作り届けるものにプライドを持て。

  • We will Always be Ready

開発が完了しdeploy可能になったときには準備万端であるべき。一ヶ月や二ヶ月deployを待ったり、QAが終わることを待つ必要なんて無いだろう。また、安定化の期間なんて必要とするべきではない。そもそも開発されたコードは最初から安定していなければいけないのだ(一週間くらいの猶予は許すけれど)。

  • Stable Productivity

プロジェクトの開始当初は早く、順調に開発が進むが終わり際は減速するなんてだめだ。プロジェクトが遅延し生産性が落ち、顧客は更なるプログラマの追加を要求するがそれによりコードの質はどんどん低下する。私は常に開発者の生産性が一定であることを期待している。これはおそらく、汚いコードを書くなということである。なぜなら汚いコードは生産性の定価を増長するからである。

  • Inexpensive Adaptability

顧客が変更を要求した時には余分なコストを払うこと無く容易に適応出来るべきである。”Software”はなぜソフトウェアを呼ばれるのか? ”Soft”、つまり、変更が容易であることを期待されている。常にコードの変更が容易な状態に保つことは開発者の責任である。「新しい要求は私達の設計では適応出来ません。」なんていうクソみたいな言葉は聞きたくない。

  • Continuous Improvements

プロフェッショナルなら継続的はコードの質、プロセス、生産性の向上を行うべきである。

  • Fearless Competence

もしひどいコードを見つけたら自身の変更によりコードが壊れることを恐れること無く改善するべきである。プロフェッショナルならコードの変更に恐れを抱いてはならない。私の場合はテストを利用するが、他者には他者のやり方があるだろう。

  • Extreme Quality

汚いゴミを市場に出すな。素早い開発サイクルはゴミを作るためではない。可能な限り高い質のコードを維持できる開発スピードで開発は行われるべきである。

  • We will not dump on QA

QAはバグを見つけるためのものではない。実際のところQAではなにも見つからないべきである。QAはデバッガでもバグを見つけるための奴隷でもない。開発者は最高の質のコードを提供し続けるべきであり、コードが準備万端になるまでQAにdeployするべきではない。

  • Automation

マニュアルのテストなんてするな。ひどい量のマニュアルテストを抱えていたテスターがテスト予算を半減された時に「行うべきでないテストは何ですか?」と相談しに来たことがある (馬鹿げている)。システムは成長し続け、マニュアルテストの予算も大きくなり続ける。手遅れになる前にテストは自動化するべきである。

  • Nothing Fragile

「このコードを変更することで複数のバグが生まれるためコードの変更は行ってなならない」などということは聞きたくない。

  • We cover for each other

我々はチームである。時折プログラマが独立して開発をし誰も他人のコードに触れようとしないことがあるが、あるべき姿ではない。自分の書いたコードを仲間とシェアして欲しいしそれぞれカバー出来るべきである。スポーツでそれぞれのポジションが割り当てられていても状況に応じて柔軟にポジション変更をするのと同じである。プロフェッショナルとしてチームの1人が休暇で居なくなったからといってプロジェクトが止まるなどということはあってはならない。

  • Honest Estimates

締め切りの申し出は特定の日ではなく、幅をもたせて伝えるのが開発者自身のためである。

  • You to say ”No"

無理な要求にはNo.と応えるのがプロフェッショナルの仕事である。マネージャや顧客には無い知識とスキルがあるからこそあなた達は雇われており、その判断をしなければならない。Yes.なんて犬でも言える。

  • Continuous Aggressive Learning

プロフェッショナルならいつまでも同じようなレベルのことばかりしているべきではない。貪欲に学び続けろ。

  • Mentoring

若者をプロフェッショナルへと導くのがプロフェッショナルの役目である。

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

Aqua Data Studioの設定のバックアップ及びPC間データ移行方法

Aqua Data Studio のデータを移行する機会があったのでメモ。

サーバ情報等の設定は全て.datastudioに含まれる。バックアップ、データ移行はこれのコピーで。

OSごとの配置ディレクトリは以下の通り。

Windows = C:\Documents and Settings\USER_HOME\.datastudio
Linux = /home/USER_HOME/.datastudio
OSX = /Users/USER_HOME/.datastudio

OpenSSLの致命的なバグ"HeartBleed"を解説した動画を訳してみた

TechCrunchにOpenSSLのバグであるHeartBleedの解説動画が挙がっていたので訳してみた。 動画はクラウドのセキュリティサービスを提供しているElasticaのCTOであるZulfikar Ramzanによるものである。

[ビデオ]OpenSSLのバグ“Heartbleed”ってどんなの?

一応動画を追いつつ読めるよう多少意訳しつつもあえて発言通りの順序で文を構成してみた。

---以下訳---

SSL/TLSの実装であるOpenSSLに脆弱性が見つかった。

TLSを知らない人のために説明しておくと、Web上で安全な通信を実現するために一般的に使用されるプロトコルである。 TLSSSLの後継であり、今回の文脈でははほぼ同じと考えてもらって良い。

例えば”https”をWebブラウザで見たことがあるだろうがこの状態ではデータが暗号化されて送信されることを期待されており、Webサイトに与えるパスワードや秘匿情報は容易に誰かに盗聴されることはない。ここで、httpsのsはSSLによって暗号化することを意味している。

OpenSSLはTLSプロトコルを実装したものの1つであり最も広く使用されているため、Webを使用する全ての人がその頻度・使い方に関わらず気づかないうちに利用しているだろう。

現在、OpenSSLのバージョン1.0.1とβリリースである1.0.2の実装に脆弱性が有るため攻撃者が容易に情報を解読できてしまう。

このビデオではその攻撃について説明する。

まず、heartbeatとしてというTLSの拡張実装があり、この機能はたとえデータが送られていない場合でもTLSセッションを閉じてしまわないために使用される。 実際の所この機能は有用であり、heartbeatが出来る前はサーバクライアント間でギャップがあり、TLSセッションが意図せず途切れる事があった。また、heartbeatは接続先マシンがまだ利用中であるかの確認にも有用である。

このheartbeatはあるマシンから他のマシンにリクエストを送る時、payloadとそのサイズを送信する。 heartbeatリクエストに対する返信では、リクエスト時に送られたものと同じ内容のpayloadとちょっとしたpaddingが返される。

ここで、攻撃者は1byte程度しかないpayloadと嘘で大きめのサイズ(e.g. 65,636byte)をheartbeatリクエストとして送る。 するとOpenSSLのバグにより、heartbeatリクエストを受けたマシンは実際に受け取ったpayloadの大きさではなく、サイズで示された大きさのpayloadを返信してしまう。

つまり、リクエスト時点では1byteしかないpayloadが返信時には65kbyte以上になってしまうのである。大きくなったpayloadには、OpenSSLが使用しているメモリ上にあるリクエスト時のpayloadの1byteとそれに続く64kbyteが含まれる。 この64kbyteは決して他人に見られるべきではないデータであり、パスワードや秘匿情報、ひどい時には暗号を作成解読する鍵すら含んでいる。

もし攻撃者がこの鍵を保持した場合、彼らは通信を傍受して暗号を解読し、いとも簡単に秘匿情報を得ることが可能である。 さらに、攻撃者が過去の通信を記録していた場合にはそれすら解読可能であり、攻撃者は暗号化されるべき重要な情報を利用して更なる悪事を働くことが可能になる。

また、攻撃者は異なるサイズでのheartbeatに対する攻撃を何度も行うことも可能であり,悪いことに現在の実装ではそれをトレースすることが出来ない。

http://heartbleed.com/ に更に詳しい情報があるので気になる人は確認して欲しい。

---訳終わり---

心配な人はOpenSSL 1.0.1g を使うか、-DOPENSSL_NO_HEARTBEATS オプションを付けて再コンパイルするといいみたいですよ。

いじょ。

マスタリングTCP/IP SSL/TLS編

マスタリングTCP/IP SSL/TLS編