flock(1)を使うのが一番安全かつ簡単

LOCKFILE=/tmp/my.lockfile

(
    flock -n 200 || exit 1

    # do something
) 200>$LOCKFILE

タイムアウトを設定したければ-wオプションをつかえばよい。

リードライトロックとしてつかえるので、更新系のスクリプトは1つしか起動したくないけど参照系は並列実行を許す、みたいなことも比較的簡単にできる。

TCPについて調べてたら、skeeterとbubbaという謎のオプションを見つけた。 調べてみたところ、TCPを策定した人達の黒歴史らしい。

• TCP options: Bubba and Skeeter

以下意訳です。

あー、これは忘れられそうもないんだけど黒歴史だね。

ben levyとstevと私¹ がFTPをやってたときにつくったものなんだ。 Bridghan²とstevがけしかけたんだけど、アイディアはシンプルで、鍵管理システムなしに暗号化できるように、デフィー・ヘルマン鍵共有をtcpで直接するためのものだった。 それには認証の仕組みは想定してなくて、パスワードみたいなものが共有されている前提だったんだ。 シンプルな実装で大体は動いてたんだけど、介入者攻撃には脆弱だったのが欠点だった。

なんで"skeeter"³ と"bubba"⁴ かって？それはstevに聞いてくれ。

なかなかセンスのあるネーミングですね。気になる人はstev氏に聞いてみてください。

参考

• Transmission Control Protocol (TCP) Parameters
• Re: [tcpm] IANA TCP options registry ...

このブログはgithub pages上に構築していますが、github pagesに引きずられて自分のブログも重くなるということが時々ありました。

がんばってブログを書いた次の日にアクセスできなくなってたりすると悲しいので何とか高速かつ安定した配信をする方法ないかなーと思って調べてみたところ、なんとgithub pagesに置いたコンテンツをCDNから配信させることができるようになったらしいです!

Faster, More Awesome GitHub Pages

どういうドメインでgithub pagesを配信しているかによって対応方法は違うので以下を読んで各自適切な設定をして下さい。

目次

デフォルトのgithub pagesのドメイン( username.github.io ) を使用している場合

既に対応しています。 なにもやる必要はありません。

カスタムサブドメイン ( www.example.com ) を使用している場合

CNAMEの向き先をusername.github.io に向けるだけで対応できます。

Apexドメイン ( example.com ) を使用している場合

Apexドメインというのはサブドメインでない基本のドメイン部分のことで、そこを直接github pagesにIPに向くようにAレコードに設定している場合です。

この場合はDNSのプロバイダがALIASレコードをサポートしていれば、ALIASが username.github.io を向くようにすることで対応できます。

ALIASレコードに対応していない場合は残念ながらCDNを有効にできません。ちなみにお名前.comはALIASには対応していないので、その場合は他のDNSプロバイダに移行するしかありません。

お名前.comからDNSimpleに移行する場合

このブログは残念ながらお名前.comでApexドメインをgithub pagesのIPに向けていたのでDNSimpleに移行することにしました。以下はお名前.comからDNSimpleに移行した際の手順です。

なお、この場合はタイトルに反して無料ではありません。

(ちなみにここではドメインの移管はせずに、DNSの設定だけをDNSimpleに移しました)

1. DNSimpleに登録する

DNSimpleはユーザビリティに主眼を置いたDNSサービスのようで¹ 、APIでDNSレコードを更新したりAWSやHerokuやgithub pagesといったクラウドサービスとの連携が簡単にできます。

DNSimple

登録時に対象ドメインを聞かれるので、そのとき移行したいドメインを入力します。

ちなみに月額3ドルから² ですが30日は無料でつかえます。誰かを紹介すると、紹介した人とされた人の両方の無料期間が伸びます。上のリンクにはキャンペーンコードが埋め込まれているので、この記事を読んだ人はぜひ上のリンクから登録してください。

登録が完了するだけで一通りのUIが使えるようになりますが、DNS機能が有効になるのは決済情報を入力してからです。

2. DNSimpleでgithub pagesとの連携を開始する

dnsimpleの管理画面 に行くとServicesというボタンがあるのでそこからgithub pagesと連携を開始します。

3. ネームサーバの設定をする

お名前.com の以下のページの「他のネームサーバーを利用」からDNSimpleのネームサーバを指定します。

https://www.onamae.com/domain/navi/ns_update/input?btn_id=navi_menu_domain_nsupdate_leftmenu_12

登録するサーバは以下です。

• ns1.dnsimple.com
• ns2.dnsimple.com
• ns3.dnsimple.com
• ns4.dnsimple.com

参考 - DNSimple Name Servers

この段階ではお名前.com側で設定しているAレコードはそのまま残しておきます。変更するのはネームサーバのみです。 そうしておかないと、ネームサーバの変更が伝搬するまでの間にお名前.comに問いあわせが来た場合NXDOMAIN扱いになってします。

4. dnsの更新を確認する

更新前は以下

% dig mojavy.com
mojavy.com.             259     IN      A       207.97.227.245

もしくは以下

% dig mojavy.com
mojavy.com.             259     IN      A       204.232.175.78

のようになっていたはずですが、反映が完了すれば上記とは違うIPが返ってくるはずです。 反映までには時間がかかるので気長に待ちます。完全に反映されるには3日ほどかかるようです。

% dig mojavy.com
mojavy.com.             3600    IN      A       103.245.222.133

% dig taksatou.github.io
taksatou.github.io.     2973    IN      CNAME   github.map.fastly.net.
github.map.fastly.net.  15      IN      A       103.245.222.133

5. CDNの確認

webpagetest のような計測ツールを使ってもいいですが、CDNからのレスポンスはX-xxxのようなヘッダがつくようなのでcurlでも確認できます。

% curl -v mojavy.com 2>&1  > /dev/null  | grep 'X-'
< X-Served-By: cache-ty67-TYO
< X-Cache: HIT
< X-Cache-Hits: 5
< X-Timer: S1392104522.668435574,VS0,VE0

もう完全に反映されたと思ったらお名前.com側で設定しているAレコードは無効にして大丈夫です。

その他参考

• https://help.github.com/articles/setting-up-a-custom-domain-with-pages

まとめ

• github pagesをつかえば無料でCDNから配信できる!
• Apexドメインは慎重に使うべきだったという教訓を得た
• DNSimple便利

Elasticsearch、Solr、及び Amazon CloudSearchの比較検討を行った。

目次

候補の選定方法

候補を選定するにあたって、以下の特徴をもっていることを前提とした。 LuceneやGroongaを使えば何でもできるが、ここでは対象としない。

• ウェブベースのインターフェースを持つ
• インデックスの更新はほぼリアルタイムに反映される
• スケールアウトが容易

Solr

https://lucene.apache.org/solr/

Luceneをバックエンドにした全文検索システム。バージョン4になってから大幅に機能が増強された。

長所

• 実績が十分ある
• 機能豊富

短所

• クラスタを構築して運用するには手間がかかりそう
• SolrCloudはzookeeperに依存するためサーバ台数もかさむ

Elasticsearch

http://www.elasticsearch.org/

Solrと同じくLuceneをバックエンドにした全文検索システム。開発者の言¹によると、Solrより洗練された分散モデルで² 、使いやすいAPIを備えている。

長所

• アーキテクチャやUIが今風
• クラスタの構築が簡単
• KibanaやLogstashと連携できる
• Percolate APIというpush通知のような機能を簡単に実装するためのものがある

短所

• 後発な分ノウハウの蓄積にやや不安が残る
• 未実装機能がいくらかある(あった。現時点(2014-02-09)では機能的にはほぼ追いついているように見える http://solr-vs-elasticsearch.com/ )

Amazon CloudSearch

http://aws.amazon.com/jp/cloudsearch/

AWS上で提供されている全文検索システム。EC2と同じく時間とトラフィックで課金される。現時点ではまだベータ。

長所

• 自動的にスケーリングしてくれる(エントリ数、リクエスト数に応じてインスタンスが自動的に増える)
• pdfやdocをそのまま送るだけでも適当にうまくやってくれる
• DynamoDBのデータをそのまま流してインデックスできる

短所

• 現状では東京リージョンがない
• テキスト解析のカスタマイズが限定的。現状、Stemming, Stopwords, Synonymsのみカスタム可能。
• N-gramとか形態素解析は自前で処理してからアップロードする必要がある
• ヒット位置を取る方法がない
• テキスト本文をインデックスと一緒に格納することはできない

比較項目別のまとめ

拡張性

SolrもElasticsearchもLuceneをバックエンドにしているので、Luceneでできることは基本的にはどちらでもできるはず。 Amazonは現状ではあまり拡張性はない。

性能

基本性能はSolrもElasticsearchも大差はなさそう。 Amazonは自動的にノードが追加されるので性能の問題はなさそう。ただし、ノードが自動追加されるタイミングとその時の挙動は未確認。

安定性

数年先行している分Solrがよいと思われるが、Elasticsearchも既に十分本番稼動実績はある。 Amazonはベータなので未知数。

リアルタイムデータ更新

いずれもほぼリアルタイムに更新できる。

日本語対応

SolrとElasticsearchはほぼ同等。kuromojiやmecabをつかえば形態素解析もできる。 Amazonはそれ自体では対応していないが、Luceneのtokenizer等を使って自前で前処理することで対応は可能。

スケーラビリティ

Amazonは完全に自動的にスケールアウトしてくれる。 Elasticsearchはインデックスのシャード数を作成時に決めておく必要があるが、スケールアウトは容易だと思われる。 Solrはv4からはElasticsearchと大体同等のスケーラビリティを備えるようになった。

参考リンクまとめ

• http://stackoverflow.com/questions/10213009/solr-vs-elasticsearch
• http://stackoverflow.com/questions/2271600/elasticsearch-sphinx-lucene-solr-xapian-which-fits-for-which-usage
• http://blog.kakipo.com/trouble-with-fluentd-and-elasticsearch/
• https://github.com/atilika/kuromoji
• http://www.elasticsearch.org/blog/percolator/
• http://blog.feedbin.me/2013/11/10/powering-actions-with-elasticsearch-percolate/
• http://docs.aws.amazon.com/cloudsearch/latest/developerguide/text-processing.html
• http://blog.mikemccandless.com/2011/06/lucenes-near-real-time-search-is-fast.html
• https://wiki.apache.org/solr/Solr4.0
• http://www.slideshare.net/kucrafal/battle-of-the-giants-apache-solr-vs-elasticsearch

所感

後発な分Elasticsearchが一番洗練されているように思います。 Solrは無難に導入できそうですが、スケールアウトが必要になったとき手間がかかりそうです。 Amazonはメリットも多いですが、現状では制限が多いので使いづらいと思います。

追記

• 2014/02/12 23:59:13： ElasticSearch → Elasticsearchに直しました