Railsのバッチ処理を高速にする方法

古い化石のような技術にも、いいところはあるのだよ。

a1180_006694

Railsで開発していてバッチ処理を書く時に、
毎回runner走らせるのが重くてリソースの無駄遣い。
どうしても好きになれない。

そこで色々考えてみたのだけど、
そもそもバッチで書く処理って単純なものがほとんどだから、
active_recordをわざわざ使う必要ないんじゃない?と。

例えばデータベースがPostgreSQLの場合、


#!/usr/local/bin/ruby

require 'yaml'
require 'pg'

ds = YAML.load(File.read("config/database.yml"))

db = ds[ENV["RAILS_ENV"]]

con = PGconn.connect(db["host"], 5432, nil, nil, db["database"], db["username"], db["password"])

res = con.exec("select * from hoge")

if res.ntuples > 0
    .
    .
    .
end

res.clear()

con.close()

のようなコードで、

cd RAILS_ROOT && RAILS_ENV=[production,development] batch/hoge.rb

とすると高速に動かせる。
database.ymlから接続情報だけ取得して、
後はpgライブラリを使ってそのまま書けばいい。

MySQLなど他のDBでも同じようなことできるはずだよ。

DNSの仕組みをちゃんと理解している?

社内でDNSサーバーの設定の話をしていて、
変更をした際の動作検証の話になった。

慣れてきたら、ログとそのサーバーの問い合わせを確認するだけでいいけど、
慣れないうちは外部サーバーを含めてきちんと確認してね。

という話をしていたのだけど、
設定ファイルの変更方法は理解しているみたいだけど、
そもそもDNSの仕組みをきちんと理解していないなという感じ。

「設定ファイルを変更できること」を求めているわけではなくて、
「仕組みを理解してトラブルにも対応できること」が大事なので、
DNSサーバーが何をしているか簡単に書いてみる。

興味がある方なら技術者じゃなくてもわかるので、
ちょっと遊んでみるといい。

_________________________________________

まず、パソコンをインターネットにつなぐ時、
「DNSサーバー」と呼ばれるサーバーが設定される。
最近だと、接続しているプロバイダの方で自動設定してくれることが多いかな。

このDNSサーバーが pancake.30min.jp というのを、
180.148.170.66 というIPアドレスに変換してくれるのだ。
このIPアドレスがインターネット上の住所みたいなもので、
IPアドレスが分かると、接続ができるようになる。
(IPアドレスでなぜインターネットがつながるかの話はまた別の機会にでも)

では、DNSサーバーは、
世の中に大量にあるドメイン名を、
どうやってIPアドレスに変換しているのだろう?

まず、最初にDNSサーバーは、

a.root-servers.net ~ m.root-servers.net
(aからアルファベット順)

の18か所のIPアドレスしか持っていない。
何か問い合わせがあると、まずこの18か所のどこかにいく。

windowsのコマンドプロンプトで問い合わせを再現してみよう。

root-server

まず問い合わせをするnslookupコマンドを実行。
今回は動作を把握するために、再帰的問い合わせを無効にする。

set norecurse

問い合わせるサーバーを、a.root-servers.netにする。

server a.root-servers.net

として、pancake.30min.jpについて問い合わせをすると、
上記画像のように、

a.dns.jp ~ g.dns.jp が帰ってくる。

.jpについては、これらのサーバーに聞きに行きなさいということだ。
そこで、a.dns.jpにpancake.30min.jpを聞きに行くと。

dns-jp

ようやく弊社のDNSサーバー、
dns.30min.jpとdns2.30min.jpが帰ってくる。
ここにpancake.30min.jpのIPアドレスが書かれている。

DNSサーバーに問い合わせをした場合、
このような問い合わせが順次行われているのだが、
毎回これを聞きに行くと、インターネット上のトラフィックが膨大になる。

そこで、実際にはTTL(Time To Live)という秒数を設定して、
一度他のDNSサーバーに問い合わせをしたら、
TTLの期間中は結果がキャッシュされるようになり、
キャッシュからデータを返すようになる。

キャッシュの生存時間について調べたければ、
nslookupコマンド中の中で、

set d2

としてやると、デバッグモードが有効になり、
問い合わせの結果のTTLなどが詳細に帰ってくる。

新しいjpドメインを取得した時に、
取得した業者でDNSサーバーのIPアドレス設定をすることになるけど、
これは業者の方で、 a.dns.jp ~ g.dns.jp に、
DNSサーバーのIPアドレスの記述を追加するよう、
申請してもらっているわけだ。

それが完了すると、自分のDNSサーバーに問い合わせが来るようになるので、
自分で書く設定が有効になる。

ここまでがDNSの仕組みの話。

_________________________________________

仕組みを理解すると、DNSの設定を変更する際には、
何をすべきかわかるようになる。

例えばIPアドレスの変更を遅延なく行いたい場合。

現在のDNSサーバーのTTLが3600秒(1時間)の場合、
まず、TTLを1秒などに設定変更をする。

変更をした後も、外部に1時間はキャッシュが生存するので、
そのまま1時間待つ。

そうすると、その後の問い合わせ結果は1秒で
キャッシュから削除されるようになるので、
IPアドレスの変更などが即座に世界中に反映されるようになる。
この状態になってから、IPアドレスを変更して、
順調に切り替わっていることを確認したら、
またTTLを適切な長さに戻せばよい。

動作検証には、nslookupやdigなどで外部のネームサーバーを指定して、
そちらに問い合わせを投げてみて、
きちんと変更が反映されていることを確認すればOK。

単に設定ファイルを変更すればいいと考えている
思考停止状態の人も多いけど、
きちんと仕組みを理解して、
運用計画やトラブルシューティングができるようになるといいね。