正しいDNSホスティングサービスの切り替え方

tech

自分でDNS権威サーバを運用してる人は自分でちゃんとやんなさい、と思うのでここでは扱いません。

以下の手順は、自分のドメインのDNS権威サーバに、DNSホスティングサービスを使っている人向けの情報です。

移転先のDNSホスティングサービスと契約する

どこかを探してまずは契約。

将来またどこかに乗り換える時に備えて、NSレコードを設定変更可能なところをオススメします。旧サービスの契約終了前までに、新サービスが利用開始できていることが必須です。
たいして高いサービスでもないので、1〜2か月ぐらい両方契約しておくぐらいのつもりでいると、何かで困っても慌てなくて良いと思います。

移転先のDNSホスティングサービスで、ゾーン情報を整備

必要なTXT/MX/A/CNAME等を登録します。

旧DNSホスティングサービスで設定しているものと、基本的に同じ内容を用意して下さい。
変更の必要が確定しているレコードについては、TTLを短くしておくと良いでしょう。
短く、といっても10分ぐらいで良いんじゃないかと思います。僕は5分より短く設定したことはありません。

このタイミングでwwwサーバも移転をとか、そんなことは考えないほうが無難です。

移転元でNSレコードを変更

通常メニューではNSレコードの設定変更ができないDNSホスティングサービスもあるみたいですが、ここはサービス提供者に掛け合ってでもやりたいところ。

example.com IN NS 新DNSホスティングサービスのDNS権威サーバ1
example.com IN NS 新DNSホスティングサービスのDNS権威サーバ2

こんな具合に。
このNSレコードのTTLは普通で良いです。(10分とかにしないという意味で。)

だけど、もう解約してしまうユーザに特別対応してくれる事ってあまり期待できそうにないですね。

ドメインの登録情報を変更

ネームサーバの設定を、新DNSホスティングサービスのDNS権威サーバに変更して下さい。

待つ。

ドメインの登録情報変更が反映されてから、以下の時間だけ待ちます。(※ドメインの登録情報は申請から設定完了までにタイムラグがあります。)

.jpドメイン: 1日
.orgドメイン: 1日
.comドメイン: 2日
.netドメイン: 2日
.infoドメイン: 1日
.bizドメイン: 2時間
.mobiドメイン: 1日
こんだけ書けばもういいか。

これらは、それぞれのドメインの権威サーバ(親)が標準で設定しているNSレコードのTTLです。
通常のDNSホスティングサービスがDNS権威サーバ(子)で設定しているNSレコードのTTLはこれより短い場合がほとんどなので、意識して長いTTLを設定するような事をしていなければ、上記の時間待てば良いです。

便宜上これを平行期間とでも呼びましょうか。

旧DNSホスティングサービスを解約(利用停止)

平行期間を経たら、古いDNS権威サーバ(子)は残して置いても良い事がないどころか悪い場合があるので、設定を削除してもらって下さい。

ゆっくりとその他レコードの変更

www.example.jp のAを変えるとかね。このとき、前述のようにTTLを短くしていると、きっとそのTTLの時間内に切り替わってくれることでしょう。

旧DNSホスティングサービスでの利用期間がまだ残っている場合は、旧側でも同様の変更をしておくと良いでしょう。
これは行儀の悪いDNSキャッシュサーバ対策で、平行期間を経ていれば本来不要であるはずのものです。

検討

どんなDNSホスティングサービスを選ぶべき？
  • 浸透って言わないところｗ
  • NSレコードが指定できるところ(TTLは指定できなくて良い)

あと、TTLはレコードごとに設定できるものなので、ゾーン全体で一律のTTLしか設定出来ないサービスはダサいなって思います。

旧DNSホスティングサービスでNSレコードが変更できないんだけど？

こんなこともありますよね。
そのときは、平行期間を過ぎたらすぐにでも旧環境を停止して下さい。

この場合、旧DNSホスティングサービスで設定していたNSレコードのTTL値の時間だけ、「あれ？名前？あれ？」ってことがあるかもしれませんが、これは待つほかありません。

(NSレコードのTTLを5分にしてるお名前.comってコレを狙ってたのかしら…と、新たな発見。これは驚いた。)

まとめ

  • DNSホスティングサービスにはNSレコード設定変更が可能なところを選びましょう。
  • NSレコードのTTLを5分にするDNSホスティングサービスは、意外なところで問題収束を早めているようで驚きます。

DNSホスティングサービスの切り替えと、NSレコードのTTLについて

移転手順を書いてみたきっかけは、↓これなんだけど
http://d.hatena.ne.jp/inuz/20120308/p1
この文章を書いてみたら、新しくわかった事があるので、元の主張を一部訂正します。

これを書く前に思っていたこと
  • 移転元のDNSホスティングサービスで設定しているDNS権威サーバ(子)のNSレコードのTTL値は、移転開始から終了までにかかる期間に影響しない。これは通常DNS権威サーバ(親)のNSレコードのTTL値がより長いものに設定されているためである。
  • 移転終了とは、一般のDNSキャッシュサーバ全てで古いNSレコードのキャッシュが消えて、新しいDNS権威サーバ(子)が参照されるようになるまでを指す。
  • 旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更出来ない場合において、旧権威サーバ(子)の応答に付随するAuthority Sectionの内容を以って、当該ドメインのNSレコードについてキャッシュのTTLを更新しをてしまうDNSキャッシュサーバがある問題に対応するには、旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更する以外には、旧権威サーバ(子)を停止する他なく、旧権威サーバ(子)のNSレコードのTTL値の長短とは関連しない。
  • 旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更出来る場合においても、TTL値の長短は移転終了と関連しない。

(の、ばっかりだな。読みにくい。)

これを書いた後に思っていること
  • 移転元のDNSホスティングサービスで設定しているDNS権威サーバ(子)のNSレコードのTTL値は、移転開始から終了までにかかる期間に影響しない。これは通常DNS権威サーバ(親)のNSレコードのTTL値がより長いものに設定されているためである。
  • 移転終了とは、一般のDNSキャッシュサーバ全てで古いNSレコードのキャッシュが消えて、新しいDNS権威サーバ(子)が参照されるようになるまでを指す。
  • 旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更出来ない場合において、旧権威サーバ(子)の応答に付随するAuthority Sectionの内容を以って、当該ドメインのNSレコードについてキャッシュのTTLを更新しをてしまうDNSキャッシュサーバがある問題に対応するには、旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更する以外には、旧権威サーバ(子)を停止する他ないが、旧権威サーバ(子)のNSレコードのTTL値を短く設定することで、旧権威サーバ(子)の停止から正常化までの期間を短縮できる。
  • 旧権威サーバ(子)においてNSレコードを新権威サーバ(子)に変更出来る場合においても、TTL値の長短は移転終了と関連しない。


考えを変えたところを赤文字にしました。


DNSって難しいね。

おしまい。

NSサーバ移転に伴うNSレコードおよびそのTTL変更に関して

tech

TwitterID:@inuwarumonoというのは僕のことです。

Twitterにて@ockeghemさんというか、徳丸浩さんとNSサーバ移転について
教えて頂いたり意見させて頂いたり、やりとりをさせて頂きましたが
僕の言いたかった事が正しく伝えられなかったことと、僕が正しく理解できて
いなかったことなどを、ブログの形にまとめます。

まずは経緯、背景から触れて、次に争点を整理し、検討を加えて最後にまとめます。

経緯

きっかけは徳丸さんのこのツイートでした。

これに対して、NSレコードのTTLが5分というのに意味がない点には完全同意ですが、
僕は徳丸さんの言われた意図を誤認して次のようなお返事をしました。

本当に良く読めよって感じですが、「5分に設定してもすぐ切り替わらないから意味がない」という誤認をしました。
そこで、NSがすぐに切り替わらない理由として、上位NSに設定されたTTLがそこに関わっているという事を説明しようとしました。

その後すぐに

というお返事を頂き、旧権威DNSサーバ上のNSレコードの設定変更が出来ない点を言われていた事に気づいて、話は終了かと思われたのですが

このお返事から、その後のやりとりにつながります。

背景

「DNSの浸透問題」

浸透問題には、いくつか種類があって、JPRS森下さんがInternet Week 2011で
説明された以下のスライドが大変わかりやすいので参照させて頂きます。
http://internet.watch.impress.co.jp/img/iw/docs/494/798/html/s08.jpg.html

いくつかある点のうち

  • DNSキャッシュサーバで、古いNSレコードがキャッシュされているため、旧権威サーバにレコードを問い合わせてしまう問題
  • 古いNSレコードのTTLが、旧権威サーバの設定不備によってリセットされてしまって、DNSキャッシュサーバ上のキャッシュから消えなくなる問題

このあたりが、後の話に関連します。

NSレコード、NSレコードに指定したDNSサーバ名のAレコードの、2重管理問題

ドメイン: example.jp. のNSサーバが、ns1.example.jp., ns2.example.jp. の2つある場合を例に書きます。

上位NS(a.dns.jp.)には、以下のレコードが登録されています。

example.jp.             86400   IN      NS      ns1.example.jp.
example.jp.             86400   IN      NS      ns2.example.jp.
ns1.example.jp.         86400   IN      A       192.168.0.1
ns2.example.jp.         86400   IN      A       192.168.0.2

.jpドメインの場合、TTLは1日になっていて、これは変更できません。


対して、ns1.example.jp., ns2.example.jp. では移転に備えて10分にしてみた、という状況だと仮定します。

example.jp.               600   IN      NS      ns1.example.jp.
example.jp.               600   IN      NS      ns2.example.jp.
ns1.example.jp.           600   IN      A       192.168.0.1
ns2.example.jp.           600   IN      A       192.168.0.2

ここで重要なのは、TTLだけが異なる同じ内容のレコードがある、ということです。


一般のDNSサーバは、どちらのNSレコードをキャッシュするのか？という点が大変問題で
後述のTTLをいくら短くしても〜という事の理由になる部分です。

一般のDNSキャッシュサーバがどちらのNSレコードをキャッシュするかというと
上位NSに記載されているNSレコード、つまり長いTTLのものがキャッシュされている
ケースがあります。

悲しいことに僕は、なぜそうなるかを体系的に説明できず、経験的にそうなっている
ケースを知っているというだけで、僕の主張のとても弱い部分です。

上位NSに聞くと、Authority として応答するし、自NSに聞くと、Answerとして応答する。
キャッシュサーバでどちらが優先されるのか？というあたりの理解に乏しいので
上記についての間違いはご指摘頂けると大変ありがたいです。



さて、長くなりましたがここまでを背景とします。


争点

意見の一致を見れなかった部分は2つあると思います。

浸透問題が不可避という点

浸透問題は複数の問題を内包しているので、どの問題が避けられないと言われていたか、僕は理解できていませんでした。

  • DNSキャッシュサーバで、古いNSレコードがキャッシュされているため、旧権威サーバにレコードを問い合わせてしまう問題

この点、僕は不可避だと思います(後述)

  • 古いNSレコードのTTLが、旧権威サーバの設定不備によってリセットされてしまって、DNSキャッシュサーバ上のキャッシュから消えなくなる問題

これは、設定不備を正せば回避可能で、そこに異論はありません。


http://internet.watch.impress.co.jp/docs/event/iw2011/20111201_494798.html
ここで言われているbindの最新版では、この状況でも問題発生しないように、
キャッシュアルゴリズムが改善されているものと読み取りましたが、具体的な内容はまだ調べていません。
(AUTHORITY SECTIONで返ってくるNSをキャッシュに取り込まない、という実装なんじゃないかと想像)


このあたりが僕の中で整理できたのはこの文章を書き始めてからで、
度重なるメンションで徳丸さんの時間を奪ってしまった事をお詫びします。


TTL短縮で、最終的なNS移転完了を短縮できるか

最終的なNS移転完了というのは、旧権威サーバにクエリが来なくなるまで、です。

旧権威サーバにDNSクエリが届かないようになる、というのは言い換えれば
旧権威サーバに向いたNSレコード(またはそのAレコード)のキャッシュが
世の中のDNSキャッシュサーバから消えるときです。


世の中のDNSキャッシュサーバが、example.jp. のNSレコードをキャッシュするまでのシナリオは以下の通りで

受けた問い合わせに対して、(.からjp.のnsレコードを引いた後に) .jpのNSサーバに、example.jp. の NSレコードを問い合わせる。

その結果は上位NSのTTLを伴って

このように応答されます。

世の中のDNSキャッシュサーバは、権威サーバでなく、上位NSに設定されたNSレコードをキャッシュしている事がある、ということです。
ここで重要なのは、上位NSから委譲を受けているはずの権威サーバの設定にかかわらず、NSレコードがキャッシュされている点です。

つまり、権威サーバ上のNSレコードのTTLをどのように変更しようとも、世の中のDNSキャッシュサーバがそれを
キャッシュしてくれるとは限らないということです。


古いNSレコードをキャッシュしているDNSキャッシュサーバは、example.jp.内のレコード、たとえば www.example.jp. を引く場合

このように、古いNSレコードが残っている限り、example.jp.内のレコードは古いNSサーバに問い合わせる事になります。

検討

旧権威サーバでは、自ゾーンについて、以下のように設定しておく事が推奨されます(浸透問題その2の理由)。

example.jp.   86400 IN NS ns3.example.jp.
example.jp.   86400 IN NS ns4.example.jp.

この設定がされた状態で、DNSキャッシュサーバからAレコードを問い合わせるクエリが来た場合

旧権威サーバは、新権威サーバに問い合わせを流すような事をするかというと、これはしないと思います。


また、

;; ANSWER SECTION:
www.example.jp.       3600    IN      A       192.168.0.100

;; AUTHORITY SECTION:
example.jp.          86400    IN      NS      ns3.example.jp.
example.jp.          86400    IN      NS      ns4.example.jp.

;; ADDITIONAL SECTION:
ns3.example.jp.       3600    IN      A       192.168.0.3
ns4.example.jp.       3600    IN      A       192.168.0.4

このような応答をDNSキャッシュサーバが受け取った時に、これを受け取ったDNSキャッシュサーバは
NSレコードの更新を行うものでしょうか。

DNSキャッシュサーバが、NSレコードの更新を行う事は十分期待できると思いますが

  • この場合において、TTLが短く設定されている事は関連しない
  • DNSキャッシュサーバはこの一台だけではないので、最長1日かかる事には変わりがない

十分減らす事は可能そうだけれど、上位NSが設定した長いTTLによる影響を、
権威サーバ側で短くすることは出来ない、という主張でした。


まとめ

結局僕が言いたかった点は、浸透問題に対してどうということじゃなく、
権威サーバ側でNSレコードのTTLをいじっても無意味です、ということでした。

× TTLを短くすると、早く新権威サーバへの移行が完了する
○ TTLを短くしておいたほうが、より多くのノードに早く新権威サーバを見せる可能性が高まる

ということで、以上になります。

長くてあまりまとまっていないものを読んで頂き、ありがとうございました。

※togetterに時系列で並べてみました
http://togetter.com/li/269765

ISUCONに参加してきた

tech

まずは運営のライブドアの皆さま、楽しいイベントをありがとうございました。


さて、俺id:inuzことTwitterID: inuwarumonoは同じ会社のアプリ屋2名と一緒に、チーム名「ツヤマ倶楽部」として出場してきたのでそのメモ/レポートを。

出場者3名とも名前はツヤマさんでは全然なくて、ツヤマというのは弊社技術部門の最高責任者の名前。(会社名は非公開)。

俺はインフラ/ミドルウェア屋なので、主にOSやらミドルウェアの最適化を考える担当。あとの2名はアプリケーション側からの切り口での改善と、それに伴うミドルウェアの最適化。両面からのアプローチというのが当初の作戦だった。

事前準備が肝、ということでツヤマ倶楽部の面々が考えていた事前対策は以下のとおり。

  • DBのクエリ解析が肝になるはず。的確にボトルネックを探すには断然クエリアナライザ。
  • パフォーマンスモニタリングが重要、でもまぁsarで良いか
  • OSのメモリパラメタチューニング練習しとこう
  • WebサービスってインフラチューニングよりよっぽどHTML最適化のほうが高速になるよね
  • あとはアプリを見ないと何とも言えないね

みたいな感じ。結果から言えば大げさだったり、的外れだったり。それぞれの考察を軸に当日を振り返りたい。

クエリ解析について

当日もらったアプリは想像をはるかに超えた単純さだった。もっと大規模なアプリケーションが相手だと思っていた。想像の10分の1以下のシンプルさで、これにはとても驚かされた。

大規模環境を想像していたツヤマ倶楽部の面々が何を用意したかというと、クエリの頻度・クエリごとの実行時間など、クエリの種類ごとの情報が詳細に把握できるように、MySQLのクエリアナライザ。なんと有償ツール、のトライアル版。これでどんなSQLが来ても完璧にチューニング対象を特定できる！と思って用意していたのだ。

MySQLのクエリアナライザを使ってみた感覚としては「マジ使える」「すげぇ欲しい」。

アプリとDBの間にMySQL Proxyを挟んでクエリを盗む形で組み込むのだけど、これがもう涙ものの使いやすさなので、詳細は http://www-jp.mysql.com/products/enterprise/query.html ここでも見てもらいたい。MySQLサーバの負荷で悩む御仁にはぜひ一度は試してもらいたい。

当日の話に戻すと、このクエリアナライザのセットアップを始めてすぐの時点で、さらっとアプリを読んだだけで、サイドバーのクエリがボトルネックであることはわかってしまった。ちょっと見ればわかるレベルで明らかだった。超優秀有償クエリアナライザ意味なし状態。

超優秀有償クエリアナライザは、数値的裏付けで最新コメントクエリの遅さを示してくれただけだったけど(数字忘れたけど95%以上の負荷がアレだった)、僕らにとってのメリットはこのツールが超優秀で超使えることがわかったこと。本当にオススメです。有償だけど、これはその価値を認めざるをえない(値段は知らんが)。

ちなみにMySQL Proxyとluaスクリプトを組み合わせて解析ツールを自作出来そうな気がするのだけど、プレースホルダを使ったクエリでうまくデータが取れないなど、事前検証をしたメンバによると、はまりどころがあったそう(時間がかけられず解決はしていないらしい)。

パフォーマンスモニタリング

とりあえずもらった4台すべてで yum install sysstat した。パフォーマンス記録の基礎中の基礎。/etc/cron.d/sysstat をいじって5秒ごと取得に変えた。並行して、手元の画面では vmstat 1 して眺めた。

けっこうみんなtopを使っていたようだけど、俺はvmstatのほうが好きだ。理由は何だろう？履歴が同じ画面に残るからかな？あと、cs を眺めることが多いかもしれない。cs=コンテキストスイッチがやたらと発生するシステムはCPUネックになっている事が多い。このシステムなら普段からcsこんぐらい発生してるしな、みたいな感覚値っていうのかしら。運用者の慣れのようなものがvmstatにはある気がする(俺の場合だけか)。俺がtopをあまり使わないのは、どのプロセスが重いかなんて、1サーバあたり1ワークロードで作ってる限り自明すぎて情報にならないから？とか想像する。ターミナルの行数を下回る程度で複数のプロセスが回るシステムや、CGIみたいにプロセスがぽこぽこforkされるシステムなら使う、そんな感じか。

OSパラメタチューニング

高速なシステムを作ろうと思ったら、ディスクI/Oを発生させたら負け、これはもう全チームが当たり前に持っているセオリーだろう。そんでもって、みんなmemcachedとかメモリキャッシュ機構を実装するんだろうなと思った。

当たり前のことをやってみんなと同じになってもつまらないと思い、以下のような事を考えていたが、これは現場では採用しなかった。

  • LinuxのファイルシステムIOに極端なwriteバッファと遅延書き込みを設定
  • 突然死すると当然のごとくデータロストになる(のでサービス環境では絶対ありえない設定)
  • OS領域とアプリ領域が別ファイルシステムなら気兼ねなく設定やりなおし可能だな

要するに、アプリケーションがファイルに読み書きしているつもりのファイルシステムIOを、LinuxのVFSレイヤでメモリにのっけちゃおう！というアイディア。ファイルシステムのマウントをwritebackに設定して、/proc/sys/vm以下のページキャッシュに関するパラメタを変更しまくれば良い。

採用しなかった理由は簡単で

  • やっぱりOSもアプリも同じファイルシステムだった
  • Dom0からの支援が得られない以上、面白くてトリッキーなだけでメリットの少ない実装は選択できない(writeback設定ミスで再起動不能だとツラすぎる)

こんな感じかしら。インフラ屋的に面白いだけで、isuconの趣旨と離れるしね。(突然死＝データロストは、"いいかんじ"ではない)

あとは、ハードウェアはきっと Xeon 5600番台の64bitだろうから、Kernelイメージ作って持ってく？とか言ってたけど、やっぱりDom0操作がない環境で実行するにはリスクを感じたので、渡されたKernelそのままを使った。

HTMLチューニング

先に書いた大規模なシステムを想像していた、というのは要するにLivedoorブログほとんどそのままみたいなアプリを想像していたということ。そして計測ツールは、ブラウザのような動作をするツールなんじゃないかという想像もあった。
結果この想像はどちらも間違っていたのだけど(実際に運営側になったつもりで想像していたらそれがほとんど不可能な事は想像できたはずなのだけど)、通常のWebサイトへのアクセスを高速化しようと考える場合、サーバやアプリの改善よりじつはよっぽどHTMLの改善のほうが「効く」んだ。

Yslowみたいなツールを使って「サイト高速化」を検討した事がある人にはわかると思うけれど、HTMLを改善すると下手なサイトなら、一ページあたりのHTTPリクエスト数を半数以下にできたりする。この時、単純計算にせよサーバ負荷は半分になるから、HTMLの改善がどれだけ効果が高いかわかって頂けると思う。そして、これをisuconでもやってやろうと思っていた。

レギュレーションには「Dom構造を変えず」とか「見た目が変わらなければ」とか、HTMLに関する内容も含まれていたから、渡されたアプリがCSS/JSファイルだけで30個、画像ファイルが50個あるようなサイトだったらアプリなんてほっといてHTML改善だけで一位になれるな、なんて思っていたわけだ。

ここでも俺の想像は大外れをしていて、目論見はまったくハズレてしまった。md5値を取られたんじゃ1バイトも変更できない。


実際にアプリを見て

なんでか俺は勝手に、CGIを前提にしたPerlスクリプトが渡されるんだと思っていた。mod_perlとかfast_cgiに載せるところから始めることになるだろうな、という想像をしてたから、本当に面喰った。
Perlのアプリケーションサーバなんていう実装をロクに知らず、Starmanは初見どころか俺は名前すら知らなかった。

スレッドを増やす方法もわからないし、純粋にアプリ負荷なのか、Starmanのオーバヘッドなのか、Starmanのセッションハンドリング性能ってどうなの？とか、知らないことだらけ。サイドバーによるDB負荷は早々に解消してアプリケーションサーバ負荷にボトルネックはシフトしていたから、Starmanについて知らなすぎる状況には少し冷や汗が出た。

そこで、俺は知らないアプリケーションサーバを勉強する時間惜しんで、Apache + mod_psgi にすることにした。PSGIの存在ぐらいは知ってたので、こう決めてしまうまでは早かったと思う。

mod_psgi自体のインストールはさっくりと終了。Apache + mod_psgi では FindBin が動かなくなったので、フルパスをベタ書きに変えた。そんだけでアプリは動いてくれた。ここまでは簡単だったけど、リクエストをぶんぶん回していると、急に500エラーが返るように。原因はDBIのSegmentation faultで、これにはお手上げ。mod_psgiとの相性なのか何なのか、ここに時間を使ってしまったのは間違ってたと今なら思う。結局Starmanに戻すしかなかった。

あとはフロントのApacheを自前コンパイルのApache2.2(moduleそぎ落とし版;mpm=worker)に置き換えてnginxと遜色ない感じにして(ほんとだよ)、接続数パラメタをいじったり、MySQLのメモリチューニングと起動プロセス数をいじったり、いろいろやったけど、思うような結果に導けなかった。

思うような結果が得られなかった理由はkeep-aliveで、ここに気付かなかったから。kazeburoさんあんた鬼だよ。脱帽です。参りました。

ツヤマ倶楽部はボトルネックが見つからないと悩み、的外れなチューニングに終始したために、上位陣に大きく水をあけられたまま終わったので、そりゃ悔しいよ。

その他

DBネックがアプリネックに移らない場合には、DBのレプリをやろうと思っていた。アプリサーバとレプリサーバを同居。DBにもアプリを設置。リバースプロキシでPOSTリクエストが来たらDBに投げて書き込み、その他はアプリサーバに投げる構成。
アプリ＋レプリ子をUNIXソケットで繋ぐとメリットありそうだったし、リバースプロキシが更新リクエストと参照リクエストを分解する構成って面白いなーって思った。memcachedを置くならリバースプロキシで。
DBネックがすぐにアプリサーバに移ったからこれはやらなかったけど、アイディアとしては嫌いじゃない。
実際の仕事の場だと、アプリがクソでも修正できない場合があったりして、ミドルウェア以下でなんとかする場面があるので、俺の脳みそはアプリをいじらずに高速化するには、みたいな思考が染みついているらしい。ここに気付いたのも個人的には収穫。

最後に

ログ吐くのもやめちゃおうぜ、とか力石みたいなチューニングも議論してたけど、その段階に達する前にボトルネックに気付けなかったし、時間足りなかったし、時間ができたら復習しようかと思っている。


懇親会の後手を挙げて「俺インフラ屋だから、次はウチでやる」って言ったのは俺なんだけど、酒の席の戯言だと思って流してもらえると嬉しい。上司には話してみるけど期待はしないでね。準備を想像するに、課題作るだけでも大変なことだよこれは。正直あれを作り上げられるだけのメンツはなかなかいませんよ。

ほんと運営の皆さま御苦労さまでした。社内にも最初はまじでー？みたいな声があったみたいだけど、ここまでの完成度に持ってこれるライブドアの技術部隊は素晴らしいです。今の仕事がつまらなかったら転職考えたいレベル。


参加者のみなさんもお疲れさまでした。面白かったね。

RFC 6217 Regional Broadcast Using an Atmospheric Link Layer

雰囲気リンク層を使った地域的なブロードキャスト、かなぁ。


これまだ読んでないのでわからん。一見して意味が頭に入らないので分かりにくいくせに大して面白くない類だと思っている。

RFC 6214 Adaption of RFC 1149 for IPv6

RFC1149のIPv6対応

Abstract

   This document specifies a method for transmission of IPv6 datagrams
   over the same medium as specified for IPv4 datagrams in RFC 1149.

概要

このドキュメントは、RFC1149でのIPv4データグラムのための定義と同じ媒体を使ったIPv6データグラムの伝送方法を定義する。

1.  Introduction

   As shown by [RFC6036], many service providers are actively planning
   to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses.
   This will affect all service providers who have implemented
   [RFC1149].  It is therefore necessary, indeed urgent, to specify a
   method of transmitting IPv6 datagrams [RFC2460] over the RFC 1149
   medium, rather than obliging those service providers to migrate to a
   different medium.  This document offers such a specification.

1. 導入

[RFC6036]で示されたとおり、多くのサービスプロバイダが急激なIPv4アドレス枯渇を和らげるために、盛んにIPv6環境を整備しようとしている。この事は、[RFC1149]を実装している全てのサービスプロバイダに影響する。これらサービスプロバイダへ別な媒体へ移行をお節介に促すよりは、RFC 1149の媒体を使ったIPv6データグラムの転送方法[RFC2460]を定義する事は必要で、急務である。

      • -

俺訳ここまで。
これね、RFC1149って何のことかって言うと、かの有名な「鳥類キャリアによる IP データグラムの伝送規格」ですよ！！！鳥でIPv6をやろうとすると、link-localアドレスどうすんのよ、とかただの焼き直しかと思いきや意外と面白い。

余計な事を考えているなう

その他

まただいぶ空いたな。

もう子どもたちは夏休みだし、あと一週間もすると海にはクラゲが出てくるんじゃないかと思う季節に桜もないだろ、と思ってブログデザインを変えてみた。暇なんじゃないぜ。

今何を考えているか、それは「コミュニケーション」「知識」「ノウハウ」「資料」「報告」「進捗」「課題」みたいな単語でまとめられそうなテーマ。ざーっくりと一言でいえば「情報」だ。

情報という単語はとにかく広い。広すぎて、みんなの頭の中は違った分類や体系が出来上がっている。この「分類や体系」というのがやっかいなんだ。俺はこれを共通化したいと思っている。みんなが考えているモノの考え方、分類やその体系を共有できたら！これはとんでもない力を生むんじゃないかと思っている。

俺は自称インターネット屋さんだとか言ってるけど、要するにシステム屋なので、「分類や体系」を一つの「システム」に落とし込みたいと思っている。

「システム」には３要素しかない。「入力」「処理」「出力」こんだけ。

みんなの頭の中、情報の分類や体系をシステム化する、というのはどういうことか。システムを単純化して３つに表わしたこのモデルを、みんなの頭の中に適用してかんがえてみる。

みんなが「入力」として得ている情報がある。情報の入れ方にはどんなのがあるかしら？「メール」「電話」「Web」「口頭」「新聞」「テレビ」…もっとあるかな。雑多な情報源だ。みんな同じ仕事をしているからには、ここもシンプルにする事ができそうだ。

みんなで同じメールを読む必要はないよね。一人にかかってきた電話の内容ってみんなに伝えなきゃいけないかもしれないね。Webの情報って鵜呑みにすると火傷するかもね。口頭でしか伝わらない情報って蓄積も検索も出来ないよね。

みんなへの情報の入力は、「共有するところはする」「みんなで同じ情報を持つ必要がないことだってある」という事を考える必要がある。情報を受け取った先のアクションを見ながら。

ちなみに、ここで「実現性」は後に回す。アイディア段階では自由度を制限しないほうが好き。

次に「処理」を考えてみようか。

みんなが受け取った情報をどうやって「処理」しているか、これは単純な議論に出来ないだろうと思う。だけど何かの「出力」を出すために「処理」をしていることだけは間違いない。だから「出力」を起点に「処理」をモデル化するのが良い気がする。逆にいえば、「出力」が固まってしまえば「処理」は自ずと決まってくるんだとおもう。

最後に「出力」だ。みんなの頭の出力って何だろうね。口頭、メール、資料、いろんな形がある。これらは全て目的に応じて使い分けているように思える。

出力の目的に応じた分類や共通化が鍵になるとここで気づく。

誰かの頭の中の「出力」は、次の誰かの頭の中への「入力」でもあるんだ。「処理」が「出力」の形によって自ずと決まる仮定が間違っていなければ、情報の入出力がキレイに設計できる事が、みんなの頭の中のシステム化の成功に繋がる。

みんなの頭の中をシステム化するということは、みんなの頭の中への入力や、頭の中からの出力をシステム化するという方針でおおむね固まった。

文字化け

その他

はてな記法を忘れるほど書いてないぜ。

インターネット屋さんをやっていると、セミナー開催の案内とかのイベント案内がよく届く。今日はその中から一部抜粋。

本メールは、弊社Webサイトからの製品ダウンロードやイベント参加いただいた方にお送りしています。
配信停止は末尾をご覧ください。このEmailの閲覧に問題がある場合は下記リンクよりご覧ください。
In case of MOJIBAKE, Please click below.
http://example.com/software/vendor/in/US

MOJIBAKE!! と驚いた。そりゃわかるけども。「文字化けの時はこっちを呼んでね」←これが文字化けしちゃしょうがないだろうから、こう書くのは仕方がない事だが…。

でもMOJIBAKEは、もはやTSUNAMIとかKAIZENみたいな国際語なのかもしれないよ。知らんけど。

http://en.wikipedia.org/wiki/Mojibake

なんかへーへー、って感じじゃない？
その前に文字化けするようなメール送ってくんじゃねーよ、って思う。本当に文字化けしていたし。