DNS の TCP による問い合わせ

Amazon EC2上に2台のサーバを作り、その上で内部向けDNSサーバを動かしたときに、DNS は TCP でも問い合わせできるのだと改めて知った。

server1 と server2 があり、server1 で DNS サーバが稼働している。server1 から server1 に対して nslookup すると瞬時に答が返ってくるのに、server2 から server1 に対して nslookup するとワンテンポ遅れる。おそらく1秒未満の遅れだが、こんなに遅いはずがない。

実は、server1 と server2 の間で udp/53 の通信が許可されていないことが原因だった。Amazon EC2 では、同じセキュリティグループのインスタンス同士でも、明示的に許可してやらなければ通信できない。Passive mode の FTP を使いたかった関係上、TCP は全通しにしてあったが、UDP は閉じたままだった。

こういうときリゾルバは、UDP での通信を試みたあとに、TCP を試す。この UDP の失敗を待つ時間が、ワンテンポの遅れになっているのだろう。DNS における TCP はゾーントランスファーでのみ使われるものと思っていたが、通常の問い合わせでも使われることを学んだ。

RFC 1035 Domain Implementation and Specification を見ると、UDP でも TCP でも使えるけど、オーバーヘッドの少ない UDP の方が好ましいと書かれていた。

4.2. Transport

The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance. Zone refresh activities must use virtual circuits because of the need for reliable transfer.

実装上は、UDP のデータグラムサイズを超える場合や、今回のように UDP での問い合わせに失敗した場合に TCP が使われるようになっているようだ。

室内アンテナで地デジ化

実家をようやく地デジ化した。工事は自前。工事といっても、室内アンテナをケーブルでテレビにつないだだけだ。

最初、アマゾンで八木アンテナのUWPAと5mのケーブルを買った。計5,000円ほど。これをテレビに直結してそのまま映ればいいなと思ったのだが、まったく映らなかった。場所は埼玉県南部。東京タワーの電波が問題なく入るはずの地域だ。

そこで、家に一台しかない、40インチ近いテレビを2Fに運び、ベランダに出て室内アンテナの位置と向きを工夫すると、ほぼ問題ないレベルで映るようになった。なるほど。数十センチの差で映りがかなり変わるとは聞いていたが、確かにその通りだ。

アンテナ設置場所の基本は、高く、高く。そして適切な向き。ベランダにただ取り付けるだけでも実用上の問題は無さそうだったが、より高く上げることにした。もちろん素人なので、屋根の上には上がりたくない。ベランダに長い棒を立てて、その上に取り付けよう。

「長い棒」として、物干し竿を買ってきた。2本に分かれた竿をつなげると3m近くにまでなり、そこからさらに伸ばすこともできるスグレモノが1,280円。取り付ける室内アンテナは風の抵抗を大きく受けることもなく、軽いので、強風の際にも強度は問題ないだろうと考えた。雷も、周囲のアンテナのほうがはるかに高いので、心配ない。

ケーブルは4Cの30mを2,480円で購入。アンテナケーブルは3C、4C、5Cといろいろある。この数字は太さを表す。太いほど電波の減衰が少ない。映りを良くしたいなら5Cのほうがいいが、太く重く曲げにくいので、室内の取り回しがしにくい。まじめに測っていないものの、20mケーブルでは足りないと予測された。2階のベランダからエアコンの穴を通して引き込み、階段を通り抜けて1階のテレビまで引っ張っていくには、30mくらい必要なはずであった。実際は27mくらいを使った。大正解。

アンテナとテレビをケーブルでつなぐためには、ケーブルの両端にF型接栓というコネクタをつける必要がある。ケーブルの被覆を1cmほど剥いて、コネクタを差し込む。初めてでも1個つけるのに10分はかからないと思う。慣れた人なら3分あれば十分かもしれない。こちらに詳しい説明があった。

映りは上々。必要なチャンネルがすべて入った。大雨、大雪の際にどうなるかはまだわからないが、まずはよくできた。室内や階段の上方を黒いケーブルが這っていていて美しくはない。でも、合計1万円前後と数時間の手間で地デジ化できたので、満足している。

まとめ ― 室内アンテナで地デジ化するときに必要なもの
・室内アンテナ(室内といっても、ベランダに取り付けられるようになっているものが多い)
・アンテナケーブル(5C、4C、3Cなど数種の太さがある)
・F型接栓 2個(ケーブルの太さに合ったものを購入する)
・多少の工具(アンテナケーブルに接栓をつけるときに必要。カッターでも問題ない)

Amazon EC2 Spot Instances をウェブサーバに使う

Spot Instance は通常のインスタンスの約1/3の価格で使える激安サーバ。入札価格を超えるとインスタンスが停止してしまうので、ウェブサーバには使えない。データ処理などの非同期で、今すぐじゃなくていいけどいつかは動いてほしいような処理に適している。ウェブサーバは、いつ来るかわからないユーザからのリクエストに応えなくてはならないので、スポットインスタンスのような動いたり止まったりするサーバには向かない。 でも激安なのだから、ウェブサーバにも使ってみよう、と思い立ってやってみた。どうするか。入札価格を通常のインスタンスと同じ(今回は$0.085/hour)にしてみるのである。通常のインスタンスの価格を超えないという保証はまったくないが、そこまで価格が上がることも、そう度々あるもんじゃないだろうと前向きに考えている。入札価格で課金されるわけではない。あくまでも時価で課金される。極端な話、1時間あたり$100で入札しておけば、まず落ちることのない、それでいて常にスポットインスタンス価格のサーバになる(と期待している)。 そんなうまい話あるのか。動かし始めて7時間。今のところ順調に動いている。何か落とし穴があるのかもしれないが、しばらくこれで続けてみる。ところでこのウェブサーバは、「だいたいいつも動いていて欲しいけど、たまに止まっているくらいなら、まあ許す」というサービスを提供している。さすがに重要なサービスで試す勇気はまだない。でも思い込みを捨ててゼロベースで考え直すと、世の中、それでいいサービスはたくさんあるんじゃないだろうか。止まったら再起動すればいいという割り切りと、1/3の価格を天秤にかけてみよう。

1時間あたり2~3円のサーバ : Amazon EC2 Spot Instances

2009年12月14日、Amazon は新しい価格体系の EC2インスタンス「スポットインスタンス」をアナウンスした。株価のように価格が変動するインスタンスで、ユーザが決めた入札価格がその時点の価格を上回っている間、インスタンスが起動し続ける。 驚きなのはその価格。直近の履歴を見ると、1時間あたり$0.026~$0.035あたりを変動している。つまり、1時間2-3円程度でサーバが借りられる。1ヶ月起動し続けたら2000円くらい。
<div class="separator" style="clear: both; text-align: center;"></div>
ユーザのリクエストを直接処理するウェブサーバやデータベースサーバに使うのは難しいが、いつ動いてもいいような処理なら劇安でこなせる。例としてAmazonは、画像・動画処理、科学技術計算、金融分析などへの利用を勧めている。ウェブアプリケーション本体に使うことはできなくても、溜まったデータをバッチ処理して利用状況を集計するなどの用途には問題なく使える。 今までの EC2 だけでも価格破壊だったのに、リアルタイム性を要しないデータの処理コストが、さらに1/3に下がった。コスト急減の影に新しい商売あり。うまい適用分野さえ見つければ、ビジネスの種になりそう。

Spot Instance をリクエストする。1時間あたり $0.028 で。
<div class="separator" style="clear: both; text-align: center;"></div>
リクエスト直後のステータスは Open。まだインスタンスは動いていない。
<div class="separator" style="clear: both; text-align: center;"></div>
現在価格が $0.026 なので、しばらく待っているとインスタンスが起動する。
<div class="separator" style="clear: both; text-align: center;"></div>
1時間だけ動かしてみた。料金は $0.03。1セント未満が切り上げられた。
<div class="separator" style="clear: both; text-align: center;"></div>
料金の詳細。確かに $0.026 で課金されている。
<div class="separator" style="clear: both; text-align: center;"></div>

ssh を用いたパスワードなしの自動バックアップ

ServerA から ServerB へ ssh で自動バックアップを取る。

serverA でパスフレーズ無しの鍵を作成する。
<pre>$ ssh-keygen -t dsa -N “” -f ~/.ssh/backup_from_serverA_to_serverB
Generating public/private dsa key pair.
Your identification has been saved in
/home/userA/.ssh/backup_from_serverA_to_serverB.
Your public key has been saved in
/home/userA/.ssh/backup_from_serverA_to_serverB.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx userA@serverA
The key’s randomart image is:
+–[ DSA 1024]—-+
 
+ . .
o o . .
+ .
S + .
. = o
*. ..
o++o .o
ooo++. E
+—————–+
</pre>
serverA から serverB へ公開鍵をコピーする。
<pre>$ scp ~/.ssh/backup_from_serverA_to_serverB.pub userB@serverB:~
</pre>
serverB で authorized_keys に公開鍵を追加する。
<pre>$ cat backup_from_serverA_to_serverB.pub » ~/.ssh/authorized_keys
</pre>
serverB で追加した公開鍵に制限を課す。パスフレーズなしのこの鍵では、特定の処理しかできないようにする。
<pre>$ vi ~/.ssh/authorized_keys
</pre>

<pre>from=”serverA”,command=”cat > /backup/serverA/proj_date +%Y%m%d_%H%M.tar”,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-dss xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
</pre>
serverA でバックアップスクリプトを cron で動作させる。
<pre>$ sudo vi /etc/cron.daily/backup
</pre>
<pre>#!/bin/sh

DATETIME=date +%Y%m%d_%H%M

echo “Archiving…“
tar zcf /tmp/proj_${DATETIME}.tgz /proj

echo “Sending the archive to serverB…“
cat /tmp/proj_${DATETIME}.tgz
ssh -i ~/.ssh/backup_from_serverA_to_serverB serverB -l userB
</pre>