元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2013/08/29

Linuxで2つのファイルの共通行を出力する


機会があったので、調べてみました。

2ファイルの差分はdiffコマンドで取るけど、その逆の共通している部分はどうやって取得するのか。エレガントなやり方はやっぱりgrepコマンドを使うのかしら?


前提

$ diff -c5 {a,b}.txt
*** a.txt	2013-08-28 18:54:49.293055071 +0900
--- b.txt	2013-08-28 18:53:58.517693404 +0900
***************
*** 1,6 ****
  1
- 2
  3
  5
  5
  6
--- 1,6 ----
  1
  3
+ 4
  5
  5
  6

こういう2つのファイルがあったとして・・・


grepで

$ grep -x -f {a,b}.txt
1
3
5
5
6

grepコマンドの"-x"オプションを使うと、こんな感じで、2ファイルの共通部分が出力される。

-x, --line-regexp

パターンが行全体とぴったりマッチしたときにのみ、その行を選択します。 (-x オプションは POSIX で規定されています)

Man page of GREP

通常であれば、共通部分なので、これで事足りると思うけど、↑のケースだと、場合によっては連続するような5の重複をなくしたいってケースもあるかもしれないので、そういう時は、uniqコマンドでもかましておけばOKなのかな。

$ grep -x -f {a,b}.txt | uniq
1
3
5
6

番外(sortとuniqで)

uniqコマンド使うところで思い出したけど、sortコマンドとuniqコマンド組み合わせても出来そう。

ただし、↓のように、"sort"してから"uniq -d"使う以上、全ての行で重複する文字列とかも、1つ(uniq)になって出てしまう。

$ sort {a,b}.txt | uniq -d
1
3
5
6

こんな感じで、sortコマンドで並べ替えてから、uniqコマンドの"-d"オプションで絞り込む。

-d, --repeated

同じ内容が 2 行以上あるものだけを出力する。

Man page of UNIQ

ここまで来ると、違いをしっかり把握すべく、grepのソースコード読んだほうが良さそうだ。・・・が、時間の都合上、一旦To Be Continuedな感じで...(また今度)

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


追記(commで)

commコマンドでも出来ることを教えてもらいました。

comm - それぞれソートされた二つのファイルを行ごとに比較する

Man page of COMM

2ファイルがソート済みの前提ではありますが、↑の例の2ファイル(既にソートされている)だと以下のような結果になりました。

$ comm -1 -2 {a,b}.txt
1
3
5
5
6

2013/08/24

調布市花火大会(2013)

調布市花火大会(2013)


我が家は高台にあるので、遠くで開催されている花火であっても、小さいながらも割と家から観ることができます。

今日は、調布市の花火大会の音が、聞こえてきたので、カメラを最大望遠にして撮ってみました。


調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

調布市花火大会

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

# 夏の写真2013


撮影した全ての写真

2013/08/21

息子さん、生誕1周年

息子さん、生誕1周年


あっという間、だった気もしますが、息子さんが1歳を迎えました。おめでとう!


上記のエントリを書いてから丸1年。やっぱりあっという間でした。

息子は、よくはしゃぎ、よく笑い、よく泣き、よく食べ、そしてよく寝る。色々大変なこともあるけど、親も赤ちゃんのフリーダムさにもすっかり慣れました。


↑の写真と、以降の写真を見比べると、成長したことがはっきりとわかります。

1年前の生まれて間もない時と比べると、体重も3倍近くあるし、力もかなりついてきました。


息子さんの誕生日なので

今日は会社からお休みをもらって、息子さんと一緒に過ごす事にしました。


365 days old 365 days old

左、ご飯を前に何とも言えない抜けた表情の息子さん。

右、その直後、カメラを構えていることに気づいてキリッと構える息子さん。


365 days old 365 days old

もぐもぐもぐ。


365 days old

ケーキを準備しました!


365 days old 365 days old

ケーキを前に「これ、なに〜?」の表情と、「いただきます」してるところ。


ファンタジーキッズリゾート

息子さんが喜ぶかなーと思って、行ってみた。

家にはないおもちゃが一杯で、終始はしゃいでいたので、良かったと思う。


365 days old 365 days old

左は急坂を登る息子さん。

右は終始、バックしまーす、な体制でベソかきながら運転する息子さんw


365 days old 365 days old

三輪車に乗ってみたり、、、料理してみたり、、、


365 days old

ボールと戯れたり、、、


365 days old

とにかく、動きまわりました!そのおかげか、帰りの車の中ではすっかり熟睡しておりました。ハイ。


最後に

365 days old

1歳になった記念撮影を自宅にて。


365 days old

これからもよろしくー。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


# 夏の写真2013

2013/08/17

息子さん、初めてのプール


1歳目前にして、初めてのプール。奥さんの実家にて。

# 夏の写真2013


361 days old

361 days old

361 days old


それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

2013/08/16

by photog63

AWS東京リージョンとBGPピアを確立するとレイテンシはどう変わるか+α


参考までに、AWS(Amazon Web Services)までの通信経路上のASパスの数が短くなったら、どれくらいレイテンシが変わるのか計測してみました。

注意事項として、この手の話は、もちろん環境によって結果が大きく変わるので、参考程度にしかならないかもしれませんが、軽く読んでみてください。

※ 少々長いので、時間がない方は、最後の"考察・まとめ"だけを読んでもらえればOKですw


BGPピアを確立する?

通常、インターネットで目的のホストと通信を行うと、途中途中で多くのネットワーク機器を通過することになります。選択される経路は、接続するネットワークによって大きく異なりますが、(もちろん)そのネットワークからの最適な経路が選択されることにはなります。(ルーターで設定されている)

で、当然そのルートは短ければ短いほど、ネットワーク距離が小さくなり経由する機器の数も減るので、レイテンシ(遅延)は小さくなるはず、というわけです。


以前に、下記エントリでも記載したのですが、

AWSには多くのインターネット接続事業者が、BGPピアをはっています。公開されているものだけでも、↑のエントリに記載している通り、現時点で数百といった規模のものです。

AS同士でピアリングを行うと、隣接同士(Neighborと呼ばれる)になるため、AWSのネットワークとピアをはると、自分の接続するネットワークのお隣さんが、AWSのネットワークになっちゃうわけですね。つまりご近所さんになれる。


ご近所さん的な拠点と、そうではない拠点で、どのくらいネットワークレイテンシが変わるのかしら?ちょっと確認してみるか、ってポイントがこのエントリの趣旨です。


前提

比較対象となるのは、厳密なBefore/Afterが難しいこともあり、都内の割と近めな2拠点から、東京リージョン(ap-northeast-1)の Amazon EC2 インスタンス(サーバ)への通信のレイテンシ(RTT)を計測してみました。

計測方法は、ping(ICMP)を使ったRTTの計測(10回)と、traceroute(ICMP)を使った通信経路の確認です。


現時点で、東京リージョンでAvailableとなっているゾーンは3つありましたので、その3つのZoneそれぞれに対して計測を行っています。

  • (Tokyo Region) ap-northeast-1
    • (Availability Zone) ap-northeast-1a
    • (Availability Zone) ap-northeast-1b
    • (Availability Zone) ap-northeast-1c

尚、「ap-northeast-1{a,b,c}」と呼ばれる3つのAvailability Zoneは、アカウントID毎にマッピングが違うので、注意してください。(私のアカウントが指す"ap-northeast-1a"と、貴方のアカウントが指している"ap-northeast-1a"は違うZoneかもしれない。)

↑の詳細は、昔のエントリですが、以下に詳細を書いています。


ap-northeast-1aに対する計測結果

一時的にAmazon EC2のインスタンスを起動し、割り当てられた以下のPublic IPアドレスに対して諸々を実行しました。

  • 対象ホスト
    • 54.238.12.206 (ec2-54-238-12-206.ap-northeast-1.compute.amazonaws.com)

BGPピア無し

BGPピアをはっていない拠点から。まずは、pingの結果。

$ ping -c 10 54.238.12.206
PING 54.238.12.206 (54.238.12.206) 56(84) bytes of data.
64 bytes from 54.238.12.206: icmp_seq=1 ttl=51 time=4.50 ms
64 bytes from 54.238.12.206: icmp_seq=2 ttl=51 time=4.50 ms
64 bytes from 54.238.12.206: icmp_seq=3 ttl=51 time=4.42 ms
64 bytes from 54.238.12.206: icmp_seq=4 ttl=51 time=4.27 ms
64 bytes from 54.238.12.206: icmp_seq=5 ttl=51 time=4.47 ms
64 bytes from 54.238.12.206: icmp_seq=6 ttl=51 time=4.46 ms
64 bytes from 54.238.12.206: icmp_seq=7 ttl=51 time=4.49 ms
64 bytes from 54.238.12.206: icmp_seq=8 ttl=51 time=4.48 ms
64 bytes from 54.238.12.206: icmp_seq=9 ttl=51 time=4.41 ms
64 bytes from 54.238.12.206: icmp_seq=10 ttl=51 time=4.56 ms
^C
--- 54.238.12.206 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9527ms
rtt min/avg/max/mdev = 4.273/4.458/4.560/0.112 ms

はい。RTTの平均は4.458msecです。


$ traceroute -I 54.238.12.206
traceroute to 54.238.12.206 (54.238.12.206), 30 hops max, 60 byte packets
 1  10.32.xx.xx (10.32.xx.xx)  0.803 ms  1.087 ms  1.111 ms
 2  10.255.xx.xx (10.255.xx.xx)  0.575 ms  0.570 ms  0.561 ms
 3  10.255.xx.xx (10.255.xx.xx)  1.694 ms  1.500 ms  1.753 ms
 4  202.232.xx.xx (202.232.xx.xx)  1.439 ms  1.492 ms  1.486 ms
 5  tky009bb10.IIJ.Net (58.138.112.1)  1.538 ms  1.519 ms  1.519 ms
 6  tky009bf01.IIJ.Net (58.138.80.189)  26.309 ms  25.755 ms  25.741 ms
 7  tky001ix01.IIJ.Net (58.138.80.118)  1.947 ms  1.948 ms  1.953 ms
 8  210.173.176.188 (210.173.176.188)  3.096 ms  3.074 ms  3.066 ms
 9  27.0.0.129 (27.0.0.129)  3.927 ms  3.910 ms  3.900 ms
10  27.0.0.147 (27.0.0.147)  4.016 ms  4.006 ms  3.950 ms
11  ec2-175-41-192-223.ap-northeast-1.compute.amazonaws.com (175.41.192.223)  3.892 ms  4.147 ms  4.126 ms
12  * * *
13  ec2-54-238-12-206.ap-northeast-1.compute.amazonaws.com (54.238.12.206)  4.632 ms  4.551 ms  4.520 ms

次に、tracerouteの結果。

↑を見てもらったら、分かるとおり、この拠点からは、IIJの回線・網内を通り抜け、JPNAP Tokyo(210.173.176.188)でのIX接続を経て、AWS内に入っていく経路となります。


BGPピア有り

次に、AWSとBGPピアを確立している場合です。


$ ping -c 10 54.238.12.206
PING 54.238.12.206 (54.238.12.206) 56(84) bytes of data.
64 bytes from 54.238.12.206: icmp_seq=1 ttl=53 time=3.03 ms
64 bytes from 54.238.12.206: icmp_seq=2 ttl=53 time=3.09 ms
64 bytes from 54.238.12.206: icmp_seq=3 ttl=53 time=2.96 ms
64 bytes from 54.238.12.206: icmp_seq=4 ttl=53 time=2.78 ms
64 bytes from 54.238.12.206: icmp_seq=5 ttl=53 time=2.99 ms
64 bytes from 54.238.12.206: icmp_seq=6 ttl=53 time=2.89 ms
64 bytes from 54.238.12.206: icmp_seq=7 ttl=53 time=2.96 ms
64 bytes from 54.238.12.206: icmp_seq=8 ttl=53 time=2.99 ms
64 bytes from 54.238.12.206: icmp_seq=9 ttl=53 time=5.43 ms
64 bytes from 54.238.12.206: icmp_seq=10 ttl=53 time=2.97 ms

--- 54.238.12.206 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 2.783/3.212/5.435/0.747 ms

まずpingですが、RTTが3.212msecと、さっきより約1.2msecほどRTTが短くなりました。


$ traceroute -I 54.238.12.206
traceroute to 54.238.12.206 (54.238.12.206), 30 hops max, 40 byte packets
 1  10.200.xx.xx (10.200.xx.xx)  0.051 ms  0.112 ms  0.119 ms
 2  10.202.xx.xx (10.202.xx.xx)  0.399 ms  0.517 ms  0.689 ms
 3  10.202.xx.xx (10.202.xx.xx)  3.119 ms  3.159 ms  3.183 ms
 4  10.202.xx.xx (10.202.xx.xx)  0.636 ms  0.696 ms  0.757 ms
 5  * * *
 6  27.0.0.135 (27.0.0.135)  2.343 ms  2.282 ms  2.299 ms
 7  27.0.0.147 (27.0.0.147)  2.551 ms  2.628 ms  2.637 ms
 8  ec2-175-41-192-223.ap-northeast-1.compute.amazonaws.com (175.41.192.223)  2.747 ms  2.917 ms  3.004 ms
 9  ec2-54-238-12-206.ap-northeast-1.compute.amazonaws.com (54.238.12.206)  3.004 ms  2.765 ms  2.819 ms

tracerouteを確認すると、まずホップ数(経由するルーターの数)が先ほどと比べて少なくなっています(13→9)。

10.202.xx.xx(Private)の自拠点を出た後に、他事業者の網内は通らず、27.0.0.xx(Amazon保有)へ入るといった経路を辿っている事が分かります。その結果、経路的にも近くなり、経由する機器の数も減ったことから、ネットワークレイテンシが小さくなったと考えられます。


次に、"ap-northeast-1b"と"ap-northeast-1c"での計測結果ですが、↑とほど同様の傾向が見られたので、コマンドの実行結果だけはって、最後に考察を書いてみます。


ap-northeast-1bに対する計測結果

  • 対象ホスト
    • 54.248.175.152 (ec2-54-248-175-152.ap-northeast-1.compute.amazonaws.com)

BGPピア無し
$ ping -c 10 54.248.175.152
PING 54.248.175.152 (54.248.175.152) 56(84) bytes of data.
64 bytes from 54.248.175.152: icmp_seq=1 ttl=50 time=5.42 ms
64 bytes from 54.248.175.152: icmp_seq=2 ttl=50 time=5.43 ms
64 bytes from 54.248.175.152: icmp_seq=3 ttl=50 time=5.31 ms
64 bytes from 54.248.175.152: icmp_seq=4 ttl=50 time=5.30 ms
64 bytes from 54.248.175.152: icmp_seq=5 ttl=50 time=5.34 ms
64 bytes from 54.248.175.152: icmp_seq=6 ttl=50 time=5.15 ms
64 bytes from 54.248.175.152: icmp_seq=7 ttl=50 time=5.40 ms
64 bytes from 54.248.175.152: icmp_seq=8 ttl=50 time=5.20 ms
64 bytes from 54.248.175.152: icmp_seq=9 ttl=50 time=5.24 ms
64 bytes from 54.248.175.152: icmp_seq=10 ttl=50 time=5.57 ms

--- 54.248.175.152 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9018ms
rtt min/avg/max/mdev = 5.151/5.339/5.572/0.117 ms
$ traceroute -I 54.248.175.152
traceroute to 54.248.175.152 (54.248.175.152), 30 hops max, 60 byte packets
 1  10.32.xx.xx (10.32.xx.xx)  0.746 ms  0.948 ms  0.971 ms
 2  10.255.xx.xx (10.255.xx.xx)  0.664 ms  0.565 ms  0.664 ms
 3  10.255.xx.xx (10.255.xx.xx)  1.649 ms  1.706 ms  1.514 ms
 4  202.232.xx.xx (202.232.xx.xx)  1.506 ms  1.512 ms  1.506 ms
 5  tky009bb10.IIJ.Net (58.138.112.1)  1.562 ms  1.562 ms  1.562 ms
 6  tky008bf00.IIJ.Net (58.138.80.177)  2.355 ms  2.191 ms  2.236 ms
 7  tky001ix01.IIJ.Net (58.138.80.106)  2.214 ms  38.855 ms  38.832 ms
 8  210.173.176.188 (210.173.176.188)  3.193 ms  3.171 ms  3.161 ms
 9  27.0.0.131 (27.0.0.131)  5.147 ms  5.136 ms  5.124 ms
10  27.0.0.155 (27.0.0.155)  4.945 ms  4.937 ms  4.647 ms
11  ec2-175-41-192-219.ap-northeast-1.compute.amazonaws.com (175.41.192.219)  4.722 ms  4.763 ms  4.988 ms
12  * * *
13  * * *
14  ec2-54-248-175-152.ap-northeast-1.compute.amazonaws.com (54.248.175.152)  5.228 ms  5.217 ms  5.197 ms

BGPピア有り
$ ping -c 10 54.248.175.152
PING 54.248.175.152 (54.248.175.152) 56(84) bytes of data.
64 bytes from 54.248.175.152: icmp_seq=1 ttl=52 time=4.02 ms
64 bytes from 54.248.175.152: icmp_seq=2 ttl=52 time=4.07 ms
64 bytes from 54.248.175.152: icmp_seq=3 ttl=52 time=4.02 ms
64 bytes from 54.248.175.152: icmp_seq=4 ttl=52 time=4.00 ms
64 bytes from 54.248.175.152: icmp_seq=5 ttl=52 time=4.10 ms
64 bytes from 54.248.175.152: icmp_seq=6 ttl=52 time=4.11 ms
64 bytes from 54.248.175.152: icmp_seq=7 ttl=52 time=3.82 ms
64 bytes from 54.248.175.152: icmp_seq=8 ttl=52 time=4.20 ms
64 bytes from 54.248.175.152: icmp_seq=9 ttl=52 time=3.98 ms
64 bytes from 54.248.175.152: icmp_seq=10 ttl=52 time=4.01 ms

--- 54.248.175.152 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 3.824/4.036/4.201/0.124 ms
$ traceroute -I 54.248.175.152
traceroute to 54.248.175.152 (54.248.175.152), 30 hops max, 40 byte packets
 1  10.200.xx.xx (10.200.xx.xx)  0.068 ms  0.230 ms  0.262 ms
 2  10.202.xx.xx (10.202.xx.xx)  0.388 ms  0.552 ms  0.666 ms
 3  10.202.xx.xx (10.202.xx.xx)  0.227 ms  0.273 ms  0.306 ms
 4  10.202.xx.xx (10.202.xx.xx)  0.596 ms  0.700 ms  0.745 ms
 5  * * *
 6  27.0.0.137 (27.0.0.137)  3.252 ms  3.380 ms  3.357 ms
 7  27.0.0.155 (27.0.0.155)  3.107 ms  3.207 ms  3.252 ms
 8  ec2-175-41-192-219.ap-northeast-1.compute.amazonaws.com (175.41.192.219)  3.471 ms  3.101 ms  3.323 ms
 9  ec2-54-248-175-152.ap-northeast-1.compute.amazonaws.com (54.248.175.152)  4.038 ms  4.004 ms  3.966 ms

ap-northeast-1cに対する計測結果

  • 対象ホスト
    • 54.238.23.241 (ec2-54-238-23-241.ap-northeast-1.compute.amazonaws.com)

BGPピア無し
$ ping -c 10 54.238.23.241
PING 54.238.23.241 (54.238.23.241) 56(84) bytes of data.
64 bytes from 54.238.23.241: icmp_seq=1 ttl=49 time=6.78 ms
64 bytes from 54.238.23.241: icmp_seq=2 ttl=49 time=6.54 ms
64 bytes from 54.238.23.241: icmp_seq=3 ttl=49 time=6.65 ms
64 bytes from 54.238.23.241: icmp_seq=4 ttl=49 time=6.60 ms
64 bytes from 54.238.23.241: icmp_seq=5 ttl=49 time=6.92 ms
64 bytes from 54.238.23.241: icmp_seq=6 ttl=49 time=6.70 ms
64 bytes from 54.238.23.241: icmp_seq=7 ttl=49 time=6.80 ms
64 bytes from 54.238.23.241: icmp_seq=8 ttl=49 time=6.59 ms
64 bytes from 54.238.23.241: icmp_seq=9 ttl=49 time=6.69 ms
64 bytes from 54.238.23.241: icmp_seq=10 ttl=49 time=6.67 ms

--- 54.238.23.241 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9022ms
rtt min/avg/max/mdev = 6.549/6.697/6.920/0.152 ms
$ traceroute -I 54.238.23.241
traceroute to 54.238.23.241 (54.238.23.241), 30 hops max, 60 byte packets
 1  10.32.xx.xx (10.32.xx.xx)  0.825 ms  1.314 ms  1.466 ms
 2  10.255.xx.xx (10.255.xx.xx)  0.590 ms  0.587 ms  0.577 ms
 3  10.255.xx.xx (10.255.xx.xx)  1.777 ms  1.501 ms  1.820 ms
 4  202.232.xx.xx (202.232.xx.xx)  1.444 ms  1.445 ms  1.443 ms
 5  tky009bb11.IIJ.Net (58.138.112.13)  1.538 ms  1.534 ms  1.535 ms
 6  tky001bf01.IIJ.Net (58.138.80.197)  2.036 ms  2.136 ms  2.114 ms
 7  tky001ix01.IIJ.Net (58.138.80.102)  1.959 ms  2.009 ms  1.985 ms
 8  210.173.176.188 (210.173.176.188)  2.984 ms  3.017 ms  3.006 ms
 9  27.0.0.80 (27.0.0.80)  6.293 ms  6.271 ms  6.274 ms
10  27.0.0.70 (27.0.0.70)  6.148 ms  6.142 ms  6.085 ms
11  ec2-175-41-192-195.ap-northeast-1.compute.amazonaws.com (175.41.192.195)  6.392 ms  6.491 ms  6.747 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  ec2-54-238-23-241.ap-northeast-1.compute.amazonaws.com (54.238.23.241)  6.677 ms  6.976 ms  6.947 ms

BGPピア有り
$ ping -c 10 54.238.23.241
PING 54.238.23.241 (54.238.23.241) 56(84) bytes of data.
64 bytes from 54.238.23.241: icmp_seq=1 ttl=50 time=5.72 ms
64 bytes from 54.238.23.241: icmp_seq=2 ttl=50 time=5.70 ms
64 bytes from 54.238.23.241: icmp_seq=3 ttl=50 time=5.97 ms
64 bytes from 54.238.23.241: icmp_seq=4 ttl=50 time=5.68 ms
64 bytes from 54.238.23.241: icmp_seq=5 ttl=50 time=5.76 ms
64 bytes from 54.238.23.241: icmp_seq=6 ttl=50 time=5.90 ms
64 bytes from 54.238.23.241: icmp_seq=7 ttl=50 time=5.60 ms
64 bytes from 54.238.23.241: icmp_seq=8 ttl=50 time=5.59 ms
64 bytes from 54.238.23.241: icmp_seq=9 ttl=50 time=5.75 ms
64 bytes from 54.238.23.241: icmp_seq=10 ttl=50 time=6.01 ms

--- 54.238.23.241 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 5.598/5.772/6.010/0.136 ms
$ traceroute -I 54.238.23.241
traceroute to 54.238.23.241 (54.238.23.241), 30 hops max, 40 byte packets
 1  10.200.xx.xx (10.200.xx.xx)  0.069 ms  0.066 ms  0.066 ms
 2  10.202.xx.xx (10.202.xx.xx)  0.361 ms  0.517 ms  0.640 ms
 3  10.202.xx.xx (10.202.xx.xx)  0.255 ms  0.255 ms  0.255 ms
 4  10.202.xx.xx (10.202.xx.xx)  0.817 ms  0.831 ms  0.897 ms
 5  * * *
 6  27.0.0.82 (27.0.0.82)  5.559 ms  5.577 ms  5.593 ms
 7  27.0.0.70 (27.0.0.70)  5.163 ms  5.189 ms  5.166 ms
 8  ec2-175-41-192-193.ap-northeast-1.compute.amazonaws.com (175.41.192.193)  5.595 ms  5.229 ms  5.386 ms
 9  ec2-54-238-23-241.ap-northeast-1.compute.amazonaws.com (54.238.23.241)  5.742 ms  5.890 ms  5.784 ms

考察・まとめ

上記の結果を見ていただければわかりますが、今回のサンプルでは、AWSとBGPピアをはることで、ASパスが2から1になっているというケースです。

これくらいだと、距離長はそれほど大きくは変わらないはずので、それほど大きな差はついていないですが、「AWSの上位ネットワークまわりについて - 元RX-7乗りの適当な日々」にも書いたとおり、AWSにはたくさんのASがピアリングしていて、今後もおそらく増えると思われるので、どこから繋いでも、それほど大きなASパスにはならないかもしれません。(もちろん各AS構内のルーターの設定次第です)

一応、今回の計測結果を以下にまとめます。


ZoneBGPピア有BGPピア無
ap-northeast-1a3.212msec4.458msec
ap-northeast-1b4.036msec5.339msec
ap-northeast-1c5.772msec6.697msec

この通り、AWSとBGPピアをはることで、今回はASパスが2から1に減り(数hop減少)、約0.9〜1.3msecレイテンシは小さくなりました。各Zoneともに同じ傾向です。


面白い傾向としては、これまでのtracerouteの計測結果を見ていると、接続元の拠点が同じ場合、3つのどのZoneへの経路にしても、同じIX(接続元からのベストパスによって通るIXは違いますが)を通っていっているという点です。

つまり、↑の表だと、日本国内からの接続でサービスのレイテンシを最大限小さくしたい場合は、(僕のアカウントを使う限りは)ap-northeast-1a*1でサービスを展開すべき、ということになります。

もちろん、↑の数字は誤差の範囲内なので、それほど神経質になる必要はありません。3つのどこでも正直大差はないでしょう。

むしろ、Availability Zoneということで、各Zoneは、IX拠点から、2msec前後の差がつくくらいのネットワーク距離がある、つまりそれなりに離れていることを意味しているのかもしれません。


長くなってしまったので、一旦この辺まで。また続編を書きます。

それでは!それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


あわせて読みたい



まとめ


2013/08/15

by ejharaldseid

tracerouteの色々


インターネットのネットワークに多少なりと興味がある方なら、指定の目的地までの経路探索をしてくれる、みんな大好きtracerouteコマンド。

そんなtracerouteの色々をメモしておきます。


tracerouteの仕組み

既に多くの解説サイトがあるので、そちらに譲りますw

tracerouteはTTLを1ずつ増やしながらパケットを送信することで、経路情報を取得する。 TTLとはパケットの生存期間を表し、ルータを1つ経由することに1ずつ減算される。 ルータはTTLが2以上のパケットが届いた場合、TTLの値を1だけ小さくし次のルータへ転送する。 TTLが1のパケットが届いた場合、届いたパケットを破棄しICMP time exceededパケットを送信者に返す。

tracerouteはまず、TTLを1にセットしたパケットを送信する。最初のルータに届いた時点でTTLがゼロになり、ICMP time exceededメッセージが戻ってくる。このメッセージの送信元アドレスを見れば、最初のルータのIPアドレスがわかる。次にTTLを2にセットして送信すると、今度は2番目のルータからICMP time exceededが戻ってくる。以降、TTLを3、4・・・と増やしていく事で、順にルータのIPアドレスを得る事ができる。

実際には、以上の作業を3回繰り返して行い、応答までの時間を表示する。 経由しているルータが応答せずタイムアウトが発生した場合は、*マークを表示する。 tracerouteで得られる経路情報は往路のみである。反対側からの経路も同じとは限らない。

traceroute - Wikipedia

他、下記のサイトには、図説があったりして、なかなかわかりやすいです。


ICMP/UDP/TCPを使う

↑の仕組みの説明は、ICMPパケットを利用した方法ですが、tracerouteの実装によっては、他にもUDPTCPGREを使ったものなどがあります。

Windows(tracert)では、ICMPパケットが使われていますが、Unix/Linux(traceroute)では、デフォルトでUDPパケットが利用されます。


尚、Ubuntu(Linux)で、tracerouteコマンドのmanを読むと、以下のような指定です。

-I     Use ICMP ECHO for probes

-T     Use TCP SYN for probes

-U     Use UDP to particular destination port for tracerouting  (instead  of
       increasing the port per each probe). Default port is 53 (dns).

-M method
       Use specified method for traceroute operations.  Default  traditional
       udp  method  has name default, icmp (-I) and tcp (-T) have names icmp
       and tcp respectively.
       Method-specific options can be passed  by  -O .   Most  methods  have
       their simple shortcuts, (-I means -M icmp, etc).

※ TCPを利用するケースについては、tcptracerouteというコマンドもある。


あれっ、tracerouteコマンド実行したけど、ほとんど「*」が表示されて経路がよく分からない!(><) ...といった場合でも違うプロトコルを利用すれば、ひょっとしたら好ましい調査結果となるかもしれません。

その場合は、Linuxとかだと↑のオプション通りですが、

$ traceroute -I (IPアドレス or FQDN)

見たいな感じで、オプションを付けて実行してみてください。


UDPを使用するtracerouteは、ポート番号が定まらないためパケットフィルタリングを行っているネットワークでは利用が難しい面があり、特にファイアウォールがある場合は問題になりやすい。 また、最終的な宛先ノードにパケットが到達した際、ICMP Echo requestの場合は単にICMP Echo replyが返されるだけだが、UDPの場合は、たまたまそのポート番号が使われていた等で、期待した動作にならない事がある。

traceroute - Wikipedia

Wikipediaでも上記のような記載がありますが、プロトコルによっては途中経路でパケットを落とされるケースも多く、インターネットで外部に公開しているサービスに向けて調べる場合、多くのケースでTCPパケット(ex. HTTP)が利用されていることが多いので、TCPを使うのが、最も成功率の高い調べ方かもしれません


ちなみに、書籍「インターネットのカタチ」によると、tracerouteの利用可能状況を2008年に調査した論文では、アメリカの計測サーバから、アメリカ国内の2000台のルータに対してtracerouteを実行した結果、ICMPでは全試行の84.5%が経路探索に成功し8.2%が途中経路に「*」が出力、UDPでは全試行の69.2%が経路探索に成功し23.3%が途中経路に「*」が出力という結果だったそうです。UDPよりはICMPを使ったほうが成功率が高い可能性がある、ということですね。


注意点: 戻りの経路について

tracerouteコマンドで調べられるのは、あくまで行きの経路だけです。戻りの経路については、行きとは異なっている可能性があります。

ところで、これまた書籍「インターネットのカタチ」によると、ワシントン大学のreverse traceroute (revtr) プロジェクトが、対象のホストから自ホストまでの経路、つまり戻りの経路を探索できる仕組みを考案しているとのことです。

reverse tracerouteは、tracerouteのようにコマンドではなくて、下記のWebサイトでサービスとして試験提供されています。



ちなみに、"はてなブログ"で試させてもらったところ、以下のような結果がメールで送られてきました。

Thanks for trying our reverse traceroute tool! The resulting data follows:

reverse traceroute from ec2-54-249-30-47.ap-northeast-1.compute.amazonaws.com (54.249.30.47) back to planetlab1.sfc.wide.ad.jp (203.178.143.10)
 0  ec2-54-249-30-47.ap-northeast-1.compute.amazonaws.com (54.249.30.47) 19.332001 ms 18.938 ms 19.063999 ms             dst
 1   (27.0.0.204) 20.726 ms 20.691999 ms 20.736 ms                                                                       sym
 2   (27.0.0.25) 11.235 ms 11.233 ms 10.985 ms                                                                           rr
 3   (27.0.0.23) 10.604 ms 10.575 ms 10.551 ms                                                                           rr
 4  jc-osa302.kddnet.ad.jp (113.157.227.248) 10.684 ms 11.055 ms 11.007 ms                                               -rr
 5  obpjbb205.int-gw.kddi.ne.jp (118.155.199.252) 13.906 ms 13.946 ms 13.917 ms                                          -rr
 6  obpjbb206.int-gw.kddi.ne.jp (118.155.199.253) 10.589 ms 10.68 ms 10.609 ms                                           rr
 7  ix-osa207.kddnet.ad.jp (118.155.199.78) 10.246 ms 10.181 ms 23.028999 ms                                             ts
 8  ge-0-1-v2.cisco3.dojima.wide.ad.jp (203.178.138.47) 10.053 ms 9.749 ms 9.772 ms                                      ts
 9  ve-3761.cisco2.dojima.wide.ad.jp (203.178.136.110) 10.058 ms 9.927 ms 9.932 ms                                       rr
10  ve-51.cisco2.notemachi.wide.ad.jp (203.178.141.142) 1.633 ms 1.644 ms 1.74 ms                                        rr
11  ve-51.foundry6.otemachi.wide.ad.jp (203.178.141.141) 1.688 ms 1.626 ms 1.51 ms                                       tr
12  ve-42.foundry4.nezu.wide.ad.jp (203.178.136.66) 1.49 ms 1.568 ms 2.666 ms                                            -tr
13  ve-46.juniper2.fujisawa.wide.ad.jp (203.178.136.94) 1.85 ms 0.779 ms 0.347 ms                                        -tr
14  ve100.alaxala3.sfc.fujisawa.wide.ad.jp (203.178.137.87) 0.504 ms 0.465 ms 0.474 ms                                   -tr
15  planetlab1.sfc.wide.ad.jp (203.178.143.10) 0.045 ms 0.031 ms 0.03 ms                                                 -tr

The rightmost columns explains how we determined a path. A dash prefix indicates that this hop was determined from the same segment as an earlier hop.
dst - This hop is the destination or the destination's uplink.
sym - We had to assume this hop was symmetric to the forward traceroute in order to generate the path. Note that we always assume that hop1, the destination's uplink, is symmetric, in order to avoid excess probing of endhosts. This assumption will generally be true for endhosts.
tr - This hop was determined from an intersection with a known traceroute.
rr - We used the Record Route option of the Internet Protocol to find this hop.
ts - We used the Timestamp option of the Internet Protocol to find this hop.

See here for more details on the different methods. 

関連ツール

mtr

mtrは、宛先を指定すると、経路を探索し、それぞれの中継地点のルーターに対して、一定間隔でpingを実行し、RTT値やパケロスの統計を記録します。

経路上のネットワークが不調の疑いがある場合など、しばらくmtrを実行して経過観察を行うことで、問題点の切り分けができます。

$ mtr (IPアドレス or ホスト名)

で、実行した結果は、以下のような感じで出力され続けます。


                         My traceroute  [v0.71]
(0.0.0.0)                                       Thu Aug 15 23:56:43 2013
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%  Last   Avg  Best  Wrst StDev
 1. 10.200.xx.xx                      0.0%   0.2   0.3   0.2   0.5   0.1
 2. 10.202.xx.xx                      0.0%   0.5   0.6   0.4   0.8   0.1
 3. 10.202.yy.yy                      0.0%   0.3   0.7   0.2   2.7   0.7
 4. 10.202.zz.zz                      0.0%   1.0   1.0   0.8   1.5   0.2
 5. ???
 6. 27.0.0.135                        0.0%   2.7   2.7   2.6   2.9   0.1
 7. 27.0.0.147                        0.0%   2.9   3.0   2.9   3.0   0.1
 8. ec2-x-x-x-x.ap-northeast-1.compu  0.0%   2.5   2.8   2.5   2.9   0.1

もうちょっと書こうかと思ったのですが、今日は、いったんここまで。(また別エントリで)

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

インターネットのカタチ―もろさが織り成す粘り強い世界―

インターネットのカタチ―もろさが織り成す粘り強い世界―

2013/08/14

2013/08時点のBGPフルルート数


IPv4BGPフルルート数は調べたところ、2006年に20万を超え、2009年には30万突破、2011年終わりに40万を突破し、今日某所でチェックしてみたところ、隣接するNeighborにもよりけりですがIPv4のインターネット経路のフルルート数は、45万〜46万台といったところ。


以下のリンク先で、さくらインターネットさんの網内からは、IPv4だと457,266と表示されていますね。IPv6だと13,607。


フルルート(full toute)とは?

平たく言えば、インターネット上での全経路情報で、インターネット接続を行っている事業者が扱うのですが、詳細は以下のリンク先とかが参考になります。


インターネットのカタチ―もろさが織り成す粘り強い世界―

インターネットのカタチ―もろさが織り成す粘り強い世界―

2013/08/13

by zzpza

AWS Command Line Interface(awscli)を使ってみた


今更な話題ではありますが、Pythonで作られたAWS Command Line Interface(aws-cli: 従来のJavaで動いていたEC2 API Toolsとは別物)を入れて動かしてみました。メモ的な感じで残しておきます。

aws-cliは、pipで管理できるし、これ1つで複数のAWSサービスを扱うことが出来て、かつレスポンスもJSONとかで返ってくるので、なかなか便利です。


$ aws 
autoscaling        ec2                importexport       sns
cloudformation     elasticache        opsworks           sqs
cloudsearch        elasticbeanstalk   rds                storagegateway
cloudwatch         elastictranscoder  redshift           sts
datapipeline       elb                route53            support
directconnect      emr                s3                 swf
dynamodb           iam                ses                

サブコマンド一覧は↑のような感じで、メインどころのAWSサービスはサポートされています。(公式ツールなので、今後も拡充されていくと思います。)


尚、今から説明することは、大体は以下のAWS公式のドキュメントに記載されていまので、こちらを読んでもらってもいいかと思います。(英語)


インストール

僕は、手元のUbuntuさんにインストールしてみました。

$ pip
プログラム 'pip' はまだインストールされていません。 次のように入力することでインストールできます:
sudo apt-get install python-pip

pipコマンドを打って、↑のような感じで出力されたら、まだpip自体が入っていないので、、、


$ sudo apt-get install python-pip

書かれている通りに従って、"python-pip"をインストールしてください。その後、


$ sudo pip install awscli

上記のような感じで、今回お目当ての"awscli"をインストールします。


設定

Access Credentials (Access Key) を、以下のURLとかで確認した上で、


[default]
aws_access_key_id=(Access Key ID)
aws_secret_access_key=(Secret Access Key)
region=ap-northeast-1

こんな感じで、1ファイルに記載して、


$ export AWS_CONFIG_FILE=~/config/awscli.conf

↑みたいな感じで、"AWS_CONFIG_FILE"の環境変数に食わせてやればOKです。


実行してみる

上記の設定まで終わると、あとは普通に実行できると思います。例えば以下のコマンド。

$ aws ec2 describe-regions 
{
    "Regions": [
        {
            "Endpoint": "ec2.eu-west-1.amazonaws.com", 
            "RegionName": "eu-west-1"
        }, 
        {
            "Endpoint": "ec2.sa-east-1.amazonaws.com", 
            "RegionName": "sa-east-1"
        }, 
        {
            "Endpoint": "ec2.us-east-1.amazonaws.com", 
            "RegionName": "us-east-1"
        }, 
        {
            "Endpoint": "ec2.ap-northeast-1.amazonaws.com", 
            "RegionName": "ap-northeast-1"
        }, 
        {
            "Endpoint": "ec2.us-west-2.amazonaws.com", 
            "RegionName": "us-west-2"
        }, 
        {
            "Endpoint": "ec2.us-west-1.amazonaws.com", 
            "RegionName": "us-west-1"
        }, 
        {
            "Endpoint": "ec2.ap-southeast-1.amazonaws.com", 
            "RegionName": "ap-southeast-1"
        }, 
        {
            "Endpoint": "ec2.ap-southeast-2.amazonaws.com", 
            "RegionName": "ap-southeast-2"
        }
    ]
}

こんな感じ。


コマンドの入力補完

とりあえず、このコマンドの入力補完機能は有効にしておきましょう。便利。

$ complete -C aws_completer aws

↑のコマンド(bash用)を実行すると、入力時にタブを押すことで補完が効いたり、コマンド候補が出るようになります。

便利なので必要に応じて、".bash_profile"とかにも書いておいて、最初に読み込まれるようにしておきましょう。


ちなみに、

tcsh
$ complete aws 'p/*/`aws_completer`/'

zsh
$ source aws_zsh_completer.sh

出力フォーマットの変更

ちなみにhelpを読むと、出力フォーマットは、以下3種類から選べるようです。

  • json
  • text
  • table

デフォルトだとJSONで返ってきますね。(さっき↑で実行したもの)

出力フォーマットの変更は、"--output"オプションを使うみたいです。


text
$ aws ec2 describe-regions --output text

ec2.eu-west-1.amazonaws.com	eu-west-1
ec2.sa-east-1.amazonaws.com	sa-east-1
ec2.us-east-1.amazonaws.com	us-east-1
ec2.ap-northeast-1.amazonaws.com	ap-northeast-1
ec2.us-west-2.amazonaws.com	us-west-2
ec2.us-west-1.amazonaws.com	us-west-1
ec2.ap-southeast-1.amazonaws.com	ap-southeast-1
ec2.ap-southeast-2.amazonaws.com	ap-southeast-2

従来のEC2 API Toolsっぽい感じですw


table
$ aws ec2 describe-regions --output table
----------------------------------------------------------
|                     DescribeRegions                    |
+--------------------------------------------------------+
||                        Regions                       ||
|+-----------------------------------+------------------+|
||             Endpoint              |   RegionName     ||
|+-----------------------------------+------------------+|
||  ec2.eu-west-1.amazonaws.com      |  eu-west-1       ||
||  ec2.sa-east-1.amazonaws.com      |  sa-east-1       ||
||  ec2.us-east-1.amazonaws.com      |  us-east-1       ||
||  ec2.ap-northeast-1.amazonaws.com |  ap-northeast-1  ||
||  ec2.us-west-2.amazonaws.com      |  us-west-2       ||
||  ec2.us-west-1.amazonaws.com      |  us-west-1       ||
||  ec2.ap-southeast-1.amazonaws.com |  ap-southeast-1  ||
||  ec2.ap-southeast-2.amazonaws.com |  ap-southeast-2  ||
|+-----------------------------------+------------------+|

リージョン(Region)の変更

ドキュメントを読む限り、以下の3パターンがあるみたいです。

  • AWS_CONFIG_FILE環境変数で指定した設定ファイルの"region"に記載(↑の設定で書いたやり方)
  • AWS_DEFAULT_REGION環境変数に指定
  • awsコマンドで"--region"オプションの指定(↓みたいな感じ)

$ aws ec2 describe-availability-zones --region us-west-1
{
    "AvailabilityZones": [
        {
            "State": "available", 
            "RegionName": "us-west-1", 
            "Messages": [], 
            "ZoneName": "us-west-1a"
        }, 
        {
            "State": "available", 
            "RegionName": "us-west-1", 
            "Messages": [], 
            "ZoneName": "us-west-1b"
        }, 
        {
            "State": "available", 
            "RegionName": "us-west-1", 
            "Messages": [], 
            "ZoneName": "us-west-1c"
        }
    ]
}

プロファイルの使用

設定ファイルにプロファイルを定義しておくと、コマンドの実行時や環境変数で切り替えることができるみたいです。

[default]
aws_access_key_id=(Access Key ID)
aws_secret_access_key=(Secret Access Key)
region=ap-northeast-1

[development]
aws_access_key_id=xxxxxxxxxx
aws_secret_access_key=xxxxxxxxxxxxxxxxxxx
region=ap-northeast-1

[staging]
aws_access_key_id=yyyyyyyyyy
aws_secret_access_key=yyyyyyyyyyyyyyyyyyyy
region=us-west-1

[production]
aws_access_key_id=zzzzzzzzzz
aws_secret_access_key=zzzzzzzzzzzzzzzzzzzz
region=us-east-1

使い方というか指定方法は、、、

  • AWS_DEFAULT_PROFILE環境変数に設定
  • "--profile"オプションで定義したプロファイル名を指定する

とかで制御できるみたいっす。


返ってきたJSONを整形したり、必要なものだけ抽出したり

公式ドキュメントにも書かれていますが、"jq"を使うと必要なものだけ抽出できたり、ハイライト表示してくれたりで、なかなかいい感じです。


例えば、"aws ec2 describe-regions"のRegionNameに対するValueだけとる場合は、以下のような感じです。

$ aws ec2 describe-regions | jq '.Regions[].RegionName'
"eu-west-1"
"sa-east-1"
"us-east-1"
"ap-northeast-1"
"us-west-2"
"us-west-1"
"ap-southeast-1"
"ap-southeast-2"

現在、東京リージョンで稼働中(available)のZoneの一覧とか。

$ aws ec2 describe-availability-zones --region ap-northeast-1 | jq '.AvailabilityZones[] | select(.State == "available") | .ZoneName'
"ap-northeast-1a"
"ap-northeast-1b"
"ap-northeast-1c"

と、こんな感じで色々欲しい値を引っこ抜けます。"jq"の詳しい使い方は、以下のマニュアルまで。


最後に、困ったときは

ヘルプを読みましょー。


$ aws help

とか。以下のようにサブコマンドごとにも用意されています。

$ aws ec2 help

とかとか。

$ aws ec2 describe-regions help

とかとかとか。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考リンク



まとめ


2013/08/12

Synergy

SynergyでCtrl+Alt+Deleteのエミュレートキーが効かない場合


かなり久しぶりにSynergyを使ってみたのですが、SynergyでいうClient(操られる側)にWindows端末を使った場合に、Ctrl+Alt+Deleteのエミュレートキーが送られなかったので、調べたメモ。


SynergyのClientに、Ctrl+Alt+Deleteを送りたい場合は、Ctrl+Alt+Pauseを押下するとエミュレートされて送られるようになっているのですが、どうも対象がWindows端末だと全然送られている気配がない。ちなみに、Clientは、Windows 7 Professional。

調べると、Windows 7(Vistaもかな)では、ソフトウェアからのSAS(Secure Attention Sequence)のシミュレートを有効にさせる必要があるとのこと。あわせてUAC(User Account Control)をOFFる


UACのOFFり方は、ググるとたくさん手順が出てくるので割愛しますが、SASシミュレートのポリシー変更については、

  • "gpedit.msc"を実行して、ローカルグループポリシーエディターを起動。
  • [コンピュータの構成] - [管理用テンプレート] - [Windowsコンポーネント] - [Windowsログオンのオプション] を選択。
  • "ソフトウェアの Secure Attention Sequence を無効または有効にする"を選択して、右クリックからの[編集]。
  • "有効"にチェック。
  • オプションで"サービスとコンピュータの簡単操作アプリケーション"を選択。
  • 最後に"OK"ボタンを押下

と、こんな感じで設定すると、Ctrl+Alt+Pause(Ctrl+Alt+Deleteのエミュレートキー)を受け付けてもらえるようになりました。

ちなみに、Synergyのキーワードで↑の解決方法をググっても英語のサイトばかり出てきたので、もう日本ではSynergyとか、あまり使われていないのかなぁという印象を持ちました。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考

2013/08/11

by mark_212011

muninサーバのチューニングの考え方


色々見ていたら、ちょっと思うところがあったので、tweetしようと書き始めたんだけど、長くなってしまったのでブログに残しておこうと思う。


muninのサーバは、対象ノードが多くなってきたりして、処理が増えてくると、多くのケースでネックになってくるのはCPUとディスクI/Oで、それらの有限なリソースをcronの定期実行が走る5分間隔の間々でいかに効率よくリソースを使うかがmuninサーバのチューニングのポイントだと思っている。


リソースを使いきった=サーバが重い、という図式が成り立つのであれば、リソースを完全に使い切る時間帯を作らない努力/調節をすれば良いわけです。要件によっては、パフォーマンスを最大限出し切る設定(チューニング)が正とは限らないわけです。


つまり、muninのようにビューを提供していて、(バックグラウンドの処理以外の)その表示自体にもそれなりにリソースを食われる前提だとしたら、例えば、5分間隔のうち、全力で30秒でバックグラウンドの処理を終わらせる必要はなくて、200秒くらいかけて緩やかに(余裕を持たせて)処理させて、リソースに余裕を持たせる選択肢もあるということです。これは実行スレッド数と優先度を適切に設定するのが手っ取り早い。


尚、大量の管理ノードがあったとしても、muninではグラフの静的な生成をしない限り、大量のディスクI/Oは発生しないので、ioDriveとかの高速ストレージデバイスは全く不要で、RAIDカードのキャッシュとかtmpfsで十分だと思います。(正しくチューニングすれば、ディスクI/Oの前にCPUにネックがくる。)


と、駄文でございましたm(_"_)m

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


あわせて読みたい


2013/08/10

WRX STI tS

WRX STI tS の外装ライト/ランプ(電装)系を一新した


そういえば、当ブログは関連のブログであることをすっかり忘れておりましたがw

下記エントリにも書いていた通り、WRX STI tSを買ってから、ちょこちょこ弄っていて、せっかくなのできちんと記録しておこうと思います。


まずは、第1弾エントリとして、タイトルの通りですが、外装のライト系で昭和の香りwがしている部分を一新してみました。基本的には、HID+LEDでかためてみました。

具体的には、、、

  • ヘッドライトのHID用バルブ交換 (6000K)
  • フォグランプのHID化 (6000K)
  • ハイビーム用バルブの交換 (5300K)
  • ポジションランプのLED化 (6000K)
  • テールランプのLED化
  • ハイマウントストップランプのLED化
  • バックランプのLED化 (6000K)
  • ライセンスランプのLED化 (6000K)

と、こんな感じです。1つずつ見ていきましょう。


ポジションランプのLED化(6000K)

ポジションランプには、PIAA超TERA Evulution 6000 (T10)を使用。


WRX STI tS

こんな感じに。写真は、ちょっと蒼白く見えていますが、6000Kなので、もっと白い感じです。

(元々は、完全なる昭和の光状態だったので、随分かっこいいですw)


ヘッドライトのHID用バルブ交換(6000K)

WRX STIは標準でHID装備なのですが、純正バルブが4300Kということで、やや黄色目。見た目的に白っぽくしたかったので、基本的には6000Kで統一すべく、HIDバルブを交換。

PIAAALSTARE(アルスター) 6000 (D2S)を採用。


WRX STI tS

こんな感じです。同メーカーの同色温度ということもあって、ポジションランプとの色温度もぴったり合ってます。


フォグランプのHID化(6000K)

ここも昭和の光だったので、思い切ってHIDに変えてみました。最近は、フォグをLEDにする人が多いみたいなんだけど、ヘッドライトと揃えてHIDです。

こいつは、バラストとバルブがセットのもの。PIAA HIDバルブ フォグコンプリートKIT ALSTARE 6000 (HB)


WRX STI tS

期待していた通り、フォグランプがめちゃめちゃ明るくなりました・・・!

こいつも、ヘッドライトにあわせて6000Kです。(黄色化と迷いましたが)


ハイビーム用バルブの交換(5300K)

さて、フロント最後はハイビーム。ここは使用頻度も踏まえて、ハロゲンライトのままバルブだけを交換。

近くのスーパーオートバックスで色々見比べたところ、IPFのものが一番明るかったので、採用してみました。

IPF SUPER LOW BEAM X MERCURY WHITE 5300K (HB3)


WRX STI tS

フロントを全灯させると、こんな感じでめちゃくちゃ明るくなりました。

が、このハロゲンバルブだけIPF製にしたせいか、ちょっとハイビームだけが蒼白い雰囲気になってしまったので、素直にPIAAの5100Kのモデルにしておけばよかったかも。


テールランプのLED化

CyberRさんで取り扱っている、WRX STI(GVB/GVF)専用のLEDテールにしてみました。スモークタイプです。

一応、この商品はスバルディーラーで取り扱いもあって、事前にディーラーの担当者とやり取りし、車検も問題ないことを確認した上での取り付けです。


WRX STI tS

WRX STI tS

今まで少し後姿に迫力が無く物足りなかった感がありましたが、こんな感じでスモークがかかっているテールになって、存在感をアピールする雰囲気に満足。スモール/ブレーキランプに計30発のLEDランプ搭載です。

(点灯時の写真は後ほど)


ハイマウントストップランプのLED化

ハイマウントストップランプは、LED化するにあたって、なかなか決定打がなかったのですが、情報収集していると、Sain製のものが安くて評判が良かったので、チョイスしてみました。

ちなみに、買おうとしたときに売り切れ状態が続いていたため、問い合わせたところ、一品一品手作りされているらしく、少し売り出されてはすぐに売切れてしまう状態とのことでした。(が、親切に次回の入荷のタイミング予定を教えてくださって、購入することができました。)


WRX STI tS

WRX STI tS

先ほど紹介したCyberRさんのLEDテールランプの点灯とあわせて。ブレーキランプ系がLED化されると、随分最近の車っぽく見えてきますw


バックランプのLED化(6000K)

お約束ですが、PIAA超TERA Evulution 6000 (T16)です。基本的にPIAAで統一。

(写真は、後述のライセンスランプとあわせて。)


ライセンスランプのLED化(6000K)

ライセンスランプは、ポジションランプと同じPIAA超TERA Evulution 6000 (T10)を採用。


WRX STI tS

こんな感じで、ライセンスランプも白くなると、かなり最近の車っぽくなりましたw

バックランプをLED化したことで、バックするときも、バックモニタで見る限り、後部が明るくなった気がします。


と、こんな感じで、外装のライト/ランプ系をHID+LEDに置き換えることで、昭和の光を撲滅させてみました。

あと、実はウィンカーポジションランプはそのままだったりするのですが、ここはそれほど気にならないので、そのままにしておくつもりです。(ちなみに、サイドミラーに付いているサイドマーカーは標準でLEDです)

あと、室内のランプについては、、、悩み中。


次回は、冷却装置編の予定。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

2013/08/08

ピアソンショック


朝、TwitterのTLと、下記Publickeyのエントリで知るピアソンショック

英国ピアソングループの技術書を国内で出版していたピアソン桐原は、ピアソングループから離脱し8月1日付けで「桐原書店」として再スタートを切ることを発表しています。

桐原書店としての再出発に伴い技術書の扱いが終了するため、これまでに出版された技術書は在庫限りになることが公式ツイートで明らかにされています。

ピアソンの技術書は書店在庫限りとの見通し。ピアソン桐原社がピアソングループ離脱で(追記あり) ? Publickey

ということで、過去に会社の人に貸してもらって読んだ本で、手元においておきたくなった名著を、ここぞとばかりに何冊かポチりました。

今読んだら、また違う何かを感じられるかもしれないし、改めて読んでみようと思いますよ。


達人プログラマー / 人月の神話

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


人月の神話

人月の神話

2013/08/02

愛用していたテンピュールの枕を買い換えた


変えたといっても、再びテンピュールの(別種類の)枕です。


過去に上記のエントリでも書いたのですが、学生の頃にテンピュールオリジナルネックピローを買って使っていたのですが、もう15年近く使ってくると、すっかりヘタってきてしまい、なんか首が微妙にこってしまうことが、たまにありました。

それを見かねたのか、妻が今年の誕生日プレゼントとして、新しい枕を買ってくれることになりました。


(6月の誕生日の話ですが)早速、東急ハンズのテンピュール売り場へ行って、店員さんに相談&アドバイスをもらいながら、色々テンピュールの枕を試してみたのですが、一番しっくりきたのが、ミレニアムネックピローのMサイズでした。


テンピュール ミレニアムネックピロー

テンピュール ミレニアムネックピロー


このミレニアムネックピローは、凹型のフォルムが特徴的ですが、凹の部分が微妙に薄柔らかい感じで、頭と首が負担のない自然な感じで枕に沈み込み、すごく頭と首の力が綺麗に抜けているような感じです。

色々試した結果、これまで使っていたオリジナルネックピローより力が抜けていて快眠できそうだったので、こちらを選んでみました。


あとサイズ選びはおそらく重要です。正直、しばらく寝てみないことにはベストがわからないと思いますが、少なくともテンピュールコーナーで買うと、店員さんがベストな寝姿勢になっているかを試しながらチェックしてくださるので、参考になるとは思います。


ということで、ミレニアムネックピローに変更してから1ヵ月半ほど経ちましたが、ココ最近は首のコリに悩まされることはなくなりました。やっぱり布団と枕は重要。快眠大事。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


あわせて読みたい


Tempur(R)(テンピュール)ミレニアムネックピローM 70526

Tempur(R)(テンピュール)ミレニアムネックピローM 70526

2013/08/01

新記録


Amazonアソシエイトの売り上げ点数が。大幅に記録更新です(^^)

f:id:rx7:20130811183313p:image


ちなみに、、、

このエントリの影響がでかいのは言うまでもないのですがw

(0円の商品は合計にカウントされていないですが、同時とかその後に買っていただいたものがカウントされているわけですね。)


# と、こんな感じで今月は緩めのエントリを量産したいと思います。

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)