雑談

明けましておめでとうございます。

ツチノコの親分です。
本年もどうぞよろしくお願いいたします。

昨年はあまり出番のなかった親分ですが、
今年はネタ専門で時々参加しようかなと思ってます。

さて、このブログですが、
社内においては、いかにバズるか?をモチベーションにありとあらゆる記事にチャレンジしていますが、
社外の方にもこのブログのアカウントを提供しております。

いろんなサイトからいろんな情報を頂いての今がありますので、
実は有用な情報で恩返しすることも重要なミッションだと思っています。
我々だけではなく皆さんの恩返しもお手伝いができれば、より良い場所になっていくと考えてますので、
そんな思いの方がいらっしゃいましたら、ぜひアカウントをリクエストしていただければと思います。

学生の方も大歓迎ですし、軽いネタでも大歓迎です。

そんな親分の昨年のオススメ軽ネタは

本当にあった怖い話 〜 Load Average編 〜

です。

ちなみに昨年の記事での親分のお気に入りは

技術書、それも売れるやつを書きたい人へ、編集者からのアドバイス

スタートアップのデータ処理・分析基盤、作るか、使うか

つながらない無線LAN!?(2/3) 調査編

でした。
※社外ツチノコさんの記事が二つですよ。

 

ということで、今年も宜しくお願い致します。

セキュリティ

みなさんは大丈夫なのかもしれませんが、2点ほど危ないなあと思ったので書き留めておきます。

9月24日、bashにCriticalな脆弱性が発見されCVE-2014-6271として注意喚起が行われた。これに対してパッチは公開されたようですが、完全に対応が出来ていなかったため、CVE-2014-7169として新たに注意喚起が行われている状況です。

そして、9月26日、CVE-2014-7169に対応したパッチが公開されセキュリティアドバイザリーがなされています。

こうやって近しい日付で2段階に注意喚起が行われているため昨日の段階で対応された方は次の日に同じ話題となっていても同じ脆弱性のことを言ってるんだなと安心しきってしまう恐れがあるように思います。4桁目を変えてはありますが番号も似ているし危ないなあと思った次第です。

対応するパッチに不備があると、注意喚起も新規に発行されるようになっているんだとは思いますがこのあたりをちゃんと認識しておく必要があるようですね。

■CVE-2014-6271
https://access.redhat.com/security/cve/CVE-2014-6271
redhatのerrata発行(セキュリティアドバイザリー)
https://rhn.redhat.com/errata/RHSA-2014-1293.html

■CVE-2014-7169
https://access.redhat.com/security/cve/CVE-2014-7169
redhatのerrata発行(セキュリティアドバイザリー)
https://rhn.redhat.com/errata/RHSA-2014-1306.html

また、もう一つの注意点として
# yum update bash
などで対応されると思いますが、例えばパブリックミラーにより同期が間に合わず修正版が上がっていないところも見受けられます。アップデートは必要がないと出ていても別のミラーには存在していることがありますので7169に対応しているバージョンなのかどうかをちゃんと確認することをおすすめします。

OS(x86_64) CVE-2014-6271 CVE-2014-7169
RHEL5 bash-3.2-33.el5.1 bash-3.2-33.el5_11.4
RHEL6 bash-4.1.2-15.el6_5.1 bash-4.1.2-15.el6_5.2
RHEL7 bash-4.2.45-5.el7_0.2 bash-4.2.45-5.el7_0.4

雑談

みなさんもご存じのネックストラップ

こちらをご覧ください

IMG_1092

先がない。。。
※分かりずらいですが本来はこの先にカードホルダー部があるんです。

カードホルダー部分がごっそりと無くなっています。幸い警察に届けられ手元に戻ってきたのですが悪用されないとも限りません。拾ってくださった方。本当にありがとうございました。この場をお借りしてお礼申し上げますm(_ _)m

気をつけなきゃいけないということで、何名かのエンジニアの巻き取りリールの紐部分を調査してみたところ、

こんなんでました。

IMG_1094

確実にもうすぐ切れます。時間の問題です^^;

これはなんとか対策しなくちゃいけないねと考えていたところ

ある、エンジニア(shinonome)から

「インフラエンジニアたるもの冗長化必須じゃないですか( ̄∇ ̄)v ドヤッ!」と

こんなん見せられました。

IMG_1089

 

かっけー!!!(東京ドームの総監督風)

リールを冗長化してるやつがいるなんて

すごいというかなんというか職業病ということで片づけることにします。

みなさんも紐の確認してみてくださいね。同じような方いるかもです。

それではさようなら。

追記

スケールアウト/分散型

IMG_1144

CDN, DNS

昨日、geekなページのあきみち氏ご本人からアカマイの本をいただいたので、早速、読んでみました。

いただいた本↓
Geekなページ:『アカマイ 知られざるインターネットの巨人』を書きました

Akamaiのsurerouteサービスがispにどのような影響を与えるのか、
また、そのサービスはもろ刃の剣でありispに対する優位性が変化してきているというくだりが面白かったです。
あきみちさん献本ありがとうございました。

ところで、この本を読んでいて、ふと
パブリックDNSとCDNの相性問題を思いだしまして、突然ではありますが調べてみようと思い立ってしまいました^^;

一度、こう思ってしまうと寝る間を惜しんで調べてしまうところがツチノコ親分の性なんでしょうかね。

では調査結果を共有します。

googleの運用する8.8.8.8や8.8.4.4などのパブリックDNSは巷ではCDNとの相性は良くないと言われています。

確かに8.8.8.8はanycastのアドレスで台湾に設置されているサーバに振られます。

かつてはakamaiやその他のCDNを利用しているサイトのFQDNで名前解決を行うと台湾のサーバに振られるようになっていました。

結構前の話なので最近はどうなっているのかコマンドを叩いて調べてみます。

akamaiの場合

これを見ると8.8.8.8でもJPのエッジサーバに振り分けられています。
8.8.8.8は間違いなくRTTをみてもTRACEをみても国内のサーバではなさそうです。

limerightの場合

limerightは台湾にエッジがなく香港に設置されているのかもしれません。
いずれにしても台湾のDNSに対しては香港のエッジが返されています。
8.8.8.8を利用した環境においてlimerightを利用しているサイトを利用すると海外のサーバに飛ばされパフォーマンスが低下する可能性があります。

cdnetworksの場合

ここはまた違った結果が。。
KDDIが買収する前は韓国資本の会社
ここの会社はもしかすると、アジア地域のanycastのアドレスは標準で韓国のエッジに飛ばすようになっているのかもしれません。
いずれにしても8.8.8.8を利用しCDNをcdnetworksを利用したサイトを訪れる際は韓国へ飛ばされパフォーマンスが低下する恐れがありそうです。

この3社の結果をまとめると
Akamaiだけが台湾の8.8.8.8でも日本のエッジが返されるようになっている。

ここから見えることは
※あくまで想像です。^^;

8.8.8.8を利用してもakamaiであれば遅延が発生しない

googleとakamaiは仲良しでgoogleがakamaiに顧客のIPを渡している可能性がある。

渡していないのであればJPアドレスなのか否かの情報は渡している可能性がある。

というところでしょうかね。

結論

改善はしている。ただしAkamaiだけで。

パブリックDNSを利用するにはまだ早いかもしれません。
※過去の記事で8.8.8.8に話しをしているのですが浅はかだったかもしれません。^^;

利用するにしても日本国内のpublic dnsを利用するといったところでしょうか。

推測を含んでいる部分が多く、
いろんな誤解が含まれている可能性がありますのでご指摘いただけると助かります。

コマンド, 小ネタ

pingでsearchをかけるといろいろと出てくるpingライクなコマンド

みんなどんな役割を持っているんだろうか。

いわずと知れたpingのように各プロトコルで応答の確認を行うコマンドであり、

fping,httpingなど監視ツールと組み合わせて利用されることも多いんだと思いますが、

普段使いできそうなコマンドはあるのでしょうか。

さっそく、調べてみました。

fping:
複数のipにping
ioping:
簡易的なディスクレイテンシーモニタリング
omping:
マルチキャストとユニキャストで応答確認
hping:
icmp,udp,tcpなどいろんなパケットを生成し応答確認
arping:
イーサネットレベルの応答確認
2ping:
特定の2ホストでどちら側のホストに問題があるのか確認できる。
httping:
httpレスポンス詳細が確認できる。

結果、下記の三つのコマンドは覚えておいても損はないかなと思いました。

一つずつ確認していきます。

  1. httpingはウェブサーバで遅延しているときにどの部分で遅延が発生しているのかが確認できる。
  2. arpingはipバッティングがないかどうかの確認ができる
  3. iopingは実運用下の中でディスクのレイテンシーの悪化状況を確認できる。

1.httping

名前解決が完了するまでの時間
+サーバへ接続するまでの時間
+リクエストがサーバに受け付けられるまでの時間
+サーバが最初のデータをスタートするまでの時間
+データの転送が完了しコネクションがクローズされるまでの時間
=合計

がわかります。

これでどこの部分で遅延が発生しているのかが具体的にわかるようになります。

2.arping

このようにIPのconflictの確認が可能です。

このコマンドを運用に組み込んでIPバッティングを防いだりできます。


3.ioping

このように実稼働環境においてレイテンシーの変化を確認し増強のタイミングを見極めることができます。

ちなみに、pong2というOpenGLを利用した3Dゲームがあります。

3Dのピンポンゲームです。aptでサクっと入ります。画面はこんな感じ^^

pong2

PAGE TOP