2009年12月04日(金) << 前の日記 | 次の日記 >>
これまでの12月04日 編集

■1Google Public DNSを使ってみた次の記事 >> このエントリーをはてなブックマークに追加

Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] のサービスが開始されたので、早速試してみた。
正引きを切り替えるのは、自分の手元で既にDNSサーバを稼動させていると、メリットが薄い感じがするのだけど、ログ整理のための逆引きに関してはメリットが出そうだ。
特定のプログラムだけDNSをスイッチする方法を考えたのだけど、リゾルバのライブラリにはそういう仕組みは備わっていないようなので、コードの方に手を入れないと難しい。chrootして切り換えてやる手はあるにはあるけども大掛かり過ぎる。
Perlのコードで、gethostbyaddrを使っているものがあったので、 Net::DNS[http://www.net-dns.org/] に書き換えるのと一緒に、 Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] に対応させてみた。
my $resGoogleDns;
sub googleDns($) {
  my $ipaddr = shift;

  $resGoogleDns ||= Net::DNS::Resolver->new(nameservers => ['8.8.8.8', '8.8.4.4']);
  my $query = $resGoogleDns->search($ipaddr, 'PTR');
  if (! $query) {
      return $ipaddr;
  }
  foreach my $rr ($query->answer) {
    if ($rr->type eq "PTR") {
      return $rr->ptrdname;
    }
  }
  return $ipaddr;
}
といった感じ。既に、 Net::DNS[http://www.net-dns.org/] を使っているコードだったら、
  $res = Net::DNS::Resolver->new;
とかやってresolverインスタンスを作っているところを、
  $res = Net::DNS::Resolver->new(nameservers => ['8.8.8.8', '8.8.4.4']);
と、DNSのアドレスを指定してやるだけで、 Google Public DNS[http://code.google.com/intl/ja/speed/public-dns/] 対応になる。
自分のところのDNSにキャッシュされていれば通信時間分損をすることになるけれども、Google DNS側にキャッシュがあれば、相手方が遅いDNSサーバだったり、応答が無い場合に待たされない分のメリットがある筈だ。
残念ながら、ウチの場合は自分のところのDNSキャッシュに既に乗っている確率が高かったのか、あまり高速化が出来なかった。
複数のプロセス使って、並列にクエリを投げてやれば、結果は違ってくるかも知れない。

■ 関連記事

■2 はてなでは買いだめしている[http://d.hatena.ne.jp/rx7/20091125/p1][サーバ管理]<< 前の記事 このエントリーをはてなブックマークに追加

数年前、おしごとでサーバ管理をしていた頃の話。ホスティング、ハウジング共に自作サーバーを使っていた。
当時は、安定性が要求されるネットワークサーバーに自作機を使うと言うのは非常識なことだったので、お客さんにもなぜわざわざ自作サーバを使うのかと訊かれたものだった。

自作サーバを使う主なメリットは2つ感じていて、ひとつは、自作サーバカンファレンスでも触れられている通り、アーキテクチャを自分で決められること。
このメリットは今より当時の方が大きくて、当時は今の様に細かいカスタマイズをすると高く付いたし、サーバと名が付くPCはそれだけで高かった。
一方、デスクトップPCは、安いものを選べばI/Oのパフォーマンスが出ないマザーボードが採用されていて、PC全体の性能を求めるともれなく高性能なそして高価なグラフィックカードが採用されていたり、高速なそして高価なCPUが採用されているという状況だったからだ。
そういう中にあって、枯れたマザーに、一クラス下のCPUを使い、容量よりも実績でHDDを選ぶことができるメリットは大きかった。

もうひとつ、自作サーバはつぶしが利いた。故障に備えてパーツをストックしておくにしても、不要になったサーバを「つぶす」にしても、使い回しが利いた。
もちろん、一定のメーカーの同一製品を一括購入すれば、そういうことは考えなくても良いのだけれど、お客さんにあわせてサーバを調達する都合で、製品を揃えるのは難しかったのだ。

リンク先のまとめにもあるけれども、自作サーバを使うためには、「ハードウェアトラブルを自分たちで解決する覚悟」が必要だし、トラブルを自分たちで解決する積りであれば、メーカ製PCの保守や保証はむしろ邪魔になるし、リース契約は柵になる。

逆に、自作サーバを使っていて一番困ったことは、経理上の処理だった。どの部品がどのお客さん用に使われているのかとか、在庫管理はFIFOなのかFILOなのかとか、お客さんが使わなくなったサーバの部品を使って、日記用サーバ作ったけどどうよとか、そういう問題が、実は一番面倒な問題だった。
こういう面でも、自作サーバを使うのはリース契約とは対極にいると感じる。
そういうことがあって、「はてなでは買いだめしている」ことが印象深かった。

■ 関連記事

今日のつぶやき

以上、1 日分です。

指定日の日記を表示

前月 2009年12月 翌月
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project