mojavy.com

dnsimpleでダイナミックDNSをつかう

December 23, 2014 at 08:02 PM | categories: web, dns |

dnsimple

dnsimple ではAPIからのDNSレコードアップデートができるので、簡単にダイナミックDNSがつかえる。

手順は以下の通り。

普通にdnsimpleでAレコードを登録する
登録したレコードのrecord idをしらべる。 record id は管理画面のURL https://dnsimple.com/domains/example.com/records/<record id>/edit をみればわかる。
レコードを更新するスクリプトをcronに登録する。スクリプトは http://developer.dnsimple.com/ddns/ でダウンロードできる。 RECORD_IDには上記の値、DOMAIN_IDにはApexドメインを設定する。

TCPの黒歴史：謎のオプションskeeterとbubbaについて

February 13, 2014 at 06:00 PM | categories: web, history |

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

TCP options: Bubba and Skeeter

以下意訳です。

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

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

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

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

参考

Kastenholz, Frank ↩
たぶんDave Bridgham のこと http://en.wikipedia.org/wiki/FTP_Software ↩
トンボのことらしい ↩
でかい人のことらしい ↩

あなたのgithub pagesを無料で高速化する方法

February 13, 2014 at 09:10 AM | categories: web, github |

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

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

Faster, More Awesome GitHub Pages

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

デフォルトのgithub pagesのドメイン( username.github.io ) を使用している場合
カスタムサブドメイン ( www.example.com ) を使用している場合
Apexドメイン ( example.com ) を使用している場合
- お名前.comからDNSimpleに移行する場合
その他参考
まとめ

デフォルトの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便利

The satisfaction of not having to use GoDaddy! らしい ↩
登録ドメイン数に応じて自動的にプランが切りかわるようです。 ↩

全文検索システムの比較 - Elasticsearch vs Solr vs Amazon CloudSearch

February 10, 2014 at 01:05 AM | categories: solr, aws, elasticsearch, web |

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

候補の選定方法

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

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

Solr

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と大体同等のスケーラビリティを備えるようになった。

参考リンクまとめ

所感

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

追記

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

http://stackoverflow.com/questions/2271600/elasticsearch-sphinx-lucene-solr-xapian-which-fits-for-which-usage ↩
昔のSolrは単純なレプリケーションとシャーディングしかなかったので、クラスタを構築するのは大変だった ↩

ウェブエンジニアのためのオンラインツールまとめ

November 20, 2012 at 02:30 AM | categories: web, tips |

The Web engineer's online toolboxというまとめ記事が便利そうだったので、実際に試しつつ抄訳してみました。(一部のコメントと体裁は変えています。)

一覧

RequestBin

httpリクエストを保存するエンドポイントを作ってくれる。

Create a RequestBin のボタンをクリックするとURLが表示されるので、そこをHTTPクライアントからたたくとRequestBin側にリクエスト内容が記録される。ソースも公開されてるのでローカルで立ちあげることもできる。

githubのwebhookのhelpも参考にどうぞ。

Hurl

httpリクエストを実行してくれる。パーマリンクも作ってくれるので、POSTリクエストもコピペで他の人と共有できる。

類似サービス: REST test test , Apigee console

httpbin

HTTPリクエスト側でレスポンスのHTTP status codeやレスポンスやリダイレクト、cookieなどを制御できる。HTTPクライアントのテストに便利。

類似サービス: UrlEcho

REDbot

HTTPのリソースをチェックしてくれる。問題を検出したら改善案のサジェストもしてくれる。

類似サービス: HTTP lint

類似サービス: HTML lint

類似サービス: Down for everyone or just me, Pimgdom ping service

類似サービス: Swagger

おわりに

いくつかのツールはサーバに負荷をかけてしまう可能性があるので注意してつかってください。
他にもなにかあれば教えてもらえるとうれしいです。