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

最初、アマゾンで八木アンテナの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個（ケーブルの太さに合ったものを購入する）
・多少の工具（アンテナケーブルに接栓をつけるときに必要。カッターでも問題ない）

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

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>

mysqldump

mysqldump コマンドを使うだけなのだが、バックアップ専用のアカウントをつくるたびに、どの権限が必要だったろうかと迷う。
1. サーバ側で dump 用ユーザを作成する。ここではユーザ名を backup とする。SELECT, SHOW VIEW, LOCK TABLES, RELOAD 権限が必要。ローカルサーバで mysqldump する場合は、さらに FILE 権限も必要。

<pre>mysql> grant select, show view, lock tables, reload on . to backup@192.168.0.111 identified by ‘<パスワード>';

SELECT
バックアップ対象テーブルを読み取るのに必要。
SHOW VIEW
VIEWをダンプするのに必要。
LOCK TABLES
整合性を持った状態でダンプするのに必要。mysqldump 実行時に --skip-lock-tables を付ける場合は不要。
RELOAD
mysqldump が FLUSH TABLES を実行するために必要。
</pre>
ネットワーク接続を TCP wrapper や iptables で制限している場合はそちらの解除も忘れずに。

<pre>$ cat /etc/hosts.allow
...
mysqld: 192.168.0.111
</pre>
2. クライアント（リモート）側で mysqldump を実行する。

<pre>mysqldump --host=192.168.0.100 --user=backup --password=<パスワード> --lock-all-tables > DB名.sql
</pre>
ダンプ中の insert などで整合性が保てなくなっても良い場合は、--skip-lock-tables をつける。この場合は LOCK TABLES 権限は不要だし、ダンプ中に更新が止まることもない。

mysqlhotcopy

テーブルをロックして、データベースディレクトリをそのままコピーする。mysqldump よりもコストが低いが、同じホスト内でしか使えない。また、MyISAM と ARCHIVE テーブルでのみ利用可能。

ファイルシステムのスナップショット

MySQL 上で FLUSH TABLES WITH READ LOCK した上で、ファイルシステムレベルでスナップショットを取る。同じホスト内でしか使えないが、更新停止時間は mysqldump や mysqlhotcopy よりも格段に短い。スナップショットを取るのは一瞬ということになっているが、Amazon EBS の場合はコマンドが Java で書かれているため、実際には数秒止まる。経験上10秒を超えたことはない。ファイルシステムに XFS を用いて、こんなスクリプトでバックアップしている。

<pre>#!/bin/sh

EC2_HOME=/usr/local/ec2/ec2-api-tools-1.3-41620
EC2_PRIVATE_KEY=/mnt/pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx.pem
EC2_CERT=/mnt/cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem

MYSQL_USER=<ユーザ名>
MYSQL_PW=<パスワード>

MOUNT_POINT=/mnt/vol1
VOLUME=vol-xxxxxxxx

MYSQL_CRED="-u$MYSQL_USER -p$MYSQL_PW"

mysql $MYSQL_CRED -e "flush tables with read lock;"
mysql $MYSQL_CRED -Nse "show master status" > $MOUNT_POINT/mysql/master_snapshot_position
mysql $MYSQL_CRED -Nse "show slave status" > $MOUNT_POINT/mysql/slave_snapshot_position

xfs_freeze -f $MOUNT_POINT
ec2-create-snapshot $VOLUME
xfs_freeze -u $MOUNT_POINT

mysql $MYSQL_CRED -e "unlock tables;"
</pre>
レプリケーションしてスレーブ側でバックアップする

レプリケーション構成で、バックアップ専用のスレーブを設ける。そのスレーブでどんなに長時間ロックしようとも、システムには影響が出ない。

レプリケーション

上記の他の手法とは意味合いが異なるが、レプリケーションもバックアップのひとつだ。リアルタイムに別サーバにバックアップされるので、ハードウェア障害に強く、最新のデータまで守れる。ただし間違って DROP TABLE したなどの操作ミスもリアルタイムに伝播するので、人為的ミスやアプリケーションバグには弱い。

RAID, DRBD, ...

デバイスレベルでリアルタイムバックアップという意味で、MySQL のレプリケーションと同じ強みと弱みを持つ。

バックアップ手法は、リアルタイム系（フロー）とスナップショット系（ストック）に大きく分かれる。データを守るという観点からは、リアルタイムバックアップ（レプリケーション、RAID）でハードウェア障害に備えつつ、スナップショットで操作ミスに備えるという構成でシステムを組むことになる。