DNS, wifi, イベント

Internet Week 2016に参加してます!

15171040_236303366783504_4489887932392932020_n

インターネットの技術者たちが集まり、最新技術から基礎の話しを持ち寄って喧々諤々するイベントです。
DMM.comラボもインターネットを通じてサービスを提供していることもあり、チームメンバーも興味あるセッションを聞いたり、弊社で使用しているネットワークについてお話しをさせていただきました。

・Wi-Fi”再”入門 見えない電波を知識で見抜く~社会的課題も交えて~
登壇者:熊谷暁

slack-for-ios-upload-1slack-for-ios-upload-2

会場は、ほぼ満員!!
電波を光にたとえWi-Fiの基礎知識から、細かいプロトコルの話、本当は怖いWi-Fiセキュリティ知識について話をしてきました。
とてもボリューミーな内容で、話しきれない!といった様子が印象的でした。
登壇後も参加者さんから質問が飛び交い、盛り上がったセッションでした。

・ネットワーク機器の本当のスペックを見抜く
・DNS DAY
登壇者:高嶋 隆一

slack-for-ios-upload-3

こちらもほぼ満席!
弊社のDNS構成について、お話をさせていただきました。
掴みはもちろん、艦これの秋イベントについて。
会場から笑いが沸き、弊社コンテンツの知名度の高さに驚きました。
セッションは、昨今のセキュリティ問題や、オリンピックなども話題に上がり盛り上がりました。

今回は有料セッションということで、発表資料をすぐに公開することができないのが残念ですが、公開可能になった際は、こちらのブログでお知らせさせていただきます。

また、DMM.comラボでは協賛ブースも出しております。
15284053_236303373450170_116789358700428722_n

会場にいらした際には、お立ち寄りください!

MQ, イベント


こちらのブログでもお知らせしましたが、オープンソースカンファレンス 2016 Tokyo/Fallで、弊社大山がMQについて、お話をしてきました。
img_0339

ツチノコブログでも話題に上がるMQの話を聞いて私なりにかみ砕いてレポートしようと思います!

そもそもMQとは?

MQはえむきゅーと読みます。not もきゅ(*´ω`*)
アプリケーション上でプロセス間のやりとりをサポートする処理方式のことです。

osc2016-mq-3-638

プロセスAとプロセスBがそれぞれ処理を走らせた際、お互いの処理が終わるのを待たずに処理を終えることができます。
プロセスを放り込めばMQにお任せできるので、システムの裏側でよく使われている手法です。

なぜMQなのか?

osc2016-mq-17-638

分散システムを単純にできる!
システムを作るときにシンプルな構成にできることもポイント。
-高可用性がある
-拡張性がある

 

MQにはいろいろある!

osc2016-mq-19-638

代表的なプロトコル/実装の特徴を紹介

AMQP(RabbitMQ)
MQTT(ActiveMQ)
STOMP(NewtMQ)
Kafka
ZeroMQ

AMQP(RabbitMQ)

Advanced Message Queuing Protocol
柔軟なメッセージルーティングができる。

MQTT(ActiveMQ)

軽量なプログラム。
ヘッダサイズが小さく、確実にメッセージを発行してくれる。

Kafka

順序付け負荷分散の両方を提供できる。
メッセージを格納し、キャッシュするためのファイルシステムに依存している。

まとめ

  • 万能なMQはない!
  • 用途にあった適切なMQを選択するのが大事。
  • Broker-MQ でパフォーマンス出したかったら NATS 使えばいいと思う!
    (但し、諸所の制約 (トランザクションなし、永続化しない、at-most-once な到達保証) を許容できるならば…)

発表資料

イベント, インフォメーション

オープンソースカンファレンス 2016 Tokyo/Fall

http://www.ospn.jp/osc2016-fall/

【開催概要】

日程 11月5日(土) 10:00~18:00(展示:11:00~17:30)
11月6日(日) 10:00~17:30(展示:10:00~16:00)
会場 明星大学 日野キャンパス 28号館 2F(OSC受付)
(多摩モノレール 「中央大学・明星大学駅」から大学まで直結。会場まで徒歩6分)
内容 オープンソースに関する最新情報の提供
・展示 – オープンソースコミュニティ、企業・団体による展示
・セミナー – オープンソースの最新情報を提供
主催 オープンソースカンファレンス実行委員会

【登壇情報】

登壇者 XaaS部
大山 裕泰
登壇日時 11月5日(土)13:00~13:45
登壇内容 マイクロサービスを支える MQ を考える
マイクロサービスアーキテクチャに見られるような、分散したシステムを有機的に結びつけ、一つの大きなサービスを提供するシステムにおいて MessageQueue (MQ) は非常に重要な役割を果たします。
MQ は単なる各システム間のメッセージの仲介役としてだけではなく、負荷平準、可用性の向上、スケーラビリティを担保するといった役割も同時に果たすことができます。
ただサービスの形態が異なるように、システムも様々な形態が存在し、システムの形態によってMQ に求められる要件も異なります。例えば、冒頭で述べたような認証や決済、コンテンツサービスなど様々なシステムと連携したアプリケーションや、様々なサービスから送られるログを集計し分析する基盤、または大量のサーバのメトリクスを集計するパフォーマンス監視基盤など、様々な形態の仕組みにおいて、それぞれ MQ に共められる要件は異なり、それらの要件を満たす様々な MQ の実装が存在します。
本セッションでは、こうした MQ の実装の一つとして開発した NewtMQ について、これが一体どういうものかについての紹介と、どういったユースケースで効果を発揮するかについて議論してみたいと思います。

 

 

Scality Japan SDS Day 2016 Tokyo

https://omniattend.com/seminar/scality-jp/sds-day-2016

 

【開催概要】

日程 11月22日10:30-17:30(受付開始 10:00)
会場 コングレスクエア日本橋
内容 国内・海外の事例公演多数。
SDSとオブジェクトストレージの今とこれからが1日で分かる。
主催 スキャリティ・ジャパン株式会社

【登壇情報】

登壇者 配信インフラ構築運用部
渡辺宣彦
登壇日時 11月22日(火)10:30-12:10
登壇内容 国内ユーザー企業様による成功事例講演②
弊社の動画配信で導入した事例を紹介します。

Internet Week 2016

https://internetweek.jp/

【開催概要】

日程 2016年11月29日(火)から12月2日(金)の4日間
会場 ヒューリックホール&ヒューリックカンファレンス
内容 インターネットの発展を推進する
インターネットに関する議論の場・交流の場を提供する
セミナー開催によるインターネット基盤技術の普及を図る
主催 一般社団法人日本ネットワークインフォメーションセンター(JPNIC)

【登壇情報】

登壇者 XaaS部
高嶋隆一
登壇日時 12月1日(木)11:10 ~ 12:00
登壇内容 ネットワーク機器の本当のスペックを見抜く
ユーザー企業における機器検証とは、

サービスに必要な機器を選定する過程で実施されるケース
それらに先立って情報収集する段階で実施されるケース
等が考えられます。

本セッションではどんなプロセスの中でどんな機器検証が必要になってくるのか、 ユースケースをまじえてお話しできればと思います。

登壇日時 12月1日(木)13:15 ~ 18:45
登壇内容 DNS DAY
コンテンツプロバイダから見た権威DNSサーバ

・想定されるユースケース
・ユースケース毎に用いられる実装
・ユースケース毎の注意点

について共有し、議論できればと思います。

登壇者 ツチノコ企画室
熊谷 暁
登壇日時 12月1日(木)13:15~15:45
登壇内容 Wi-Fi”再”入門 見えない電波を知識で見抜く~社会的課題も交えて~
Wi-Fiの基礎技術と電波の知識
Wi-Fiの応用ノウハウと最新技術トピック
Wi-Fiを取り巻く課題

最後に

オープンソースカンファレンス 2016 Tokyo/FallとInternet Week 2016はイベントに協賛しているのでブースを出します!
ぜひ、ブースにも遊びに来てくださいね。

また、phpcon 2016では、会場ネットワークを構築するメンバーに弊社エンジニアも参加しております!
イベントに参加される皆さまは、ぜひ!会場WiFi使用してくださいね(^o^)

 

JANOG, イベント, インフォメーション, ツチノコNOC

こちらの記事で募集をかけさせていただいたツチノコNOC(仮)のメンバーが決まりました!
ご応募いただいた皆さまありがとうございました٩( ‘ω’ )وツチノコNOCは、来年1月のJANOG39ミーティングの会場ネットワークを構築するために、社内・社外・学生を含めて27名のメンバーで構成されたチームです。

キックオフミーティングを開催しました

先週末、キックオフミーティングが開催されました!
テレビ会議を使用して金沢や仙台からも会議に参加していただきました。

20161006_210722img_9285img_9290

ミーティングでは、JANOG39ミーティングの会場ネットワークをどんなものにしたいかを共有しました。
”すぐ動いて、すぐ壊せるやつを作りたい!” から ”OpenStackでやりたい”
など、たくさんのやりたいこと案が出てきました。

チーム分けをしました

今回は、チームを4つに分けました。
チームの役割について説明をし、自身が携わりたいチームを選んでもらいました。
サーバもネットワークもやりたい!という人は、どちらにも所属していいルールです。

役割 仕事内容
ネットワーク
  • ネットワークの物理設計、論理設計を行なう
  • アドレス管理、VLAN管理を行なう
  • ネットワーク機材の設定を行なう
WiFi
  • 機器(無線AP, スイッチ)の配置場所を決める
  • 会場内の配線図を作成する
  • ケーブルを準備する
  • WLC、AP等のWiFI機器の設定を行なう
サーバ
  • サーバ(DHCP, DNS cache, 監視など) の設計と設定と行なう
サポート
  • 外部との調整を行なう
  • 内部スケジュール調整を行なう
  • ドキュメント管理責任者
  • ツチノコNOCのPR, SNS係, 撮影係

img_9289

どのチームも満遍なく人が振り分けられていい感じ♪
なかなか「サポート」に手が挙がらなかったのはご愛敬です。

暫定リーダを決めてチーム分けは完了し、この日は解散となりました。
続きはオンライン上でチームに分けれて意見を出し合いながら、どんな構成でいくかを決めていいきます。

さいごに

普段の業務はiOSアプリの開発、社内SEといったインフラ寄りではないメンバー、学生、インフラエンジニア
とバラエティ豊かなメンバーで構成されたツチノコNOCがどんな会場ネットワークを作ってくれるのか今から楽しみです!

今後もツチノコNOCについて情報を発信していければと思っております!
どうぞ、ご期待ください。

ICTSC, イベント, コラム, ネットワーク

こんにちは、saiです。
「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト(以下、トラコン)にて運営委員を務めさせて頂きました。

第6回トラコンでは15問の問題が学生の手によって出題されました!

今回は、私が担当した問題の内一つを紹介していきます。

タイトル:調子が悪いんでしょうか?

問題文

ある日、AWS内で弊社のWebサーバを稼動させることになりました。
ただしネットワークに割ける予算が少なかったために古いネットワーク機材を使用しています。
先日、本格稼動をする前に複数人で確認したところ、どうにも「見れるページ」と「見れないページ」が存在するようです。
また、状況によっては「見れないページ」も「見れる」場合があるそうです。
早急に原因を解明し、誤った設定内容を修正してください。修正後、報告もお願いします。
尚、変更するのはサーバのみでお願い致します。

見れないページ : URL

ServerIPaddress : ****
認証情報 【ID】: ****
【Password】: ****

FirewallIPaddress : ****
認証情報 【ID】: ****
【Password】:****


** 補足
問題を起こしている箇所を修正し、原因と修正内容を報告できれば対策を行えたものとします。*1

 *1  どういう状態になるとゴールなのかを記載していなかった為。又、全ての環境でMTUキャッシュクリアの方法をMTUというワードを出さずに周知できなかった為、補足させていただきました。

 

問題解説

この問題は、問題文と各種設定から原因を見つけていく問題でした。
AWS関連の情報やMTUについて詳しく知っていればピンとくるかもしれない問題ですが、そうでない場合難しい問題となったかもしれません。
また、解く際にWiresharkを用いたりすれば、MSS値周りの情報からヒントを見つける事が可能でした。

 

キーポイント

  • AWSのデフォルトMTU値が9001である
  • FW(vyosA)でicmpが全て拒否されている為、PathMTUDiscoveryまで拒否されている(PathMTUDiscoveryBlackhole問題)
  • 経路上のルータ(vyosB)のMTU値が800になっている
  • 結果、サイズが800byte*2を越えるWebページだけが見れなくなってしまう

  *2 実際には約600byte〜700byteくらい

 

解説

この問題では、一部Webページが見れない状況にありました。
その原因は、PathMTUDiscoveryが拒否されている事(PathMTUDiscoveryBlackhole)とMTUによってパケットがドロップしてしまう事でした。

まず前者についてですが、PathMTUDiscoveryはICMP type3 code4を用いMTUの低いルータ側から送信されます。
しかし、その先にあるファイアウォールがICMP全てをドロップしてしまう為、PathMTUDiscoveryが届かずデータの再送信が行われません。
その為、PCとAWS間のMSSが設定されたままパケットが送信され、途中経路のルータでパケットがドロップしてしまう状況が生まれます。

また、sshをすると通信の始めにクライアント側が大きいパケットを流すため、PathMTUDiscoveryがクライアント側に流れます。
そうすると、一時的にクライアント側のMTU値が800になるため、Webページを見れる状態になります。
しかし、これは恒久的な対策ではないため、これだけを解決策として報告した場合は間違いとなります。

今回、ファイアーウォールではなくサーバの設定を変更する問題となっているので、
サーバのMTU値を恒久的に800にあわせる設定を入れた事と、PathMTUDiscoveryBlackHoleについて触れていれば正解となります。
ただし、今回の状況から800というMTU値を推察するのは難しいだろうという事から、サーバのMTU値の設定はどの値にしていても間違いはないものとし、修正箇所と原因に気づければ正解としました。

 

解法

上記で大まかな解説は行っていますが、詳しい解き方については以下をご参照ください。

問題文からヒントを探す

この問題では、「一部見れないページがある」という現象が発生していました。
しかし、そのままではMTUが原因だとなかなか見つけられないかと思います。
なので、「AWS」や「古いネットワーク機材を使っている」というワードを文面に盛り込む事で、環境の違いを強調していました。
この文面から、環境によって引き起こされているトラブルではないか?と考えると解きやすかったかもしれません。

 

手元にある情報から探す

では、本当にページが見れないのか実行してみましょう。
(ブラウザでも確認はできますが、今回はcurlで実行してみました)

# curl -v http://hogehoge/
* About to connect() to hogehoge port 80 (#0)
*      Trying hogehoge ... connected
* Connected to hogehoge ( hogehoge ) port 80 (#0)
> GET / HTTP/1.1
> User-Agent : curl/~~~
> Host :  ipaddress
> Accept :  */*
>

上の結果から、コネクションは張れるけれどページが見れないという状態を確認できます。
また、この時のパケットをwireshark等で確認すると、3WAYHandshake時にMSSで9001という値が交換されています。
(これはWebServerへsshしifconfigする事でもわかります。)
そして、ssh時に帰ってきているパケットを見ると

「ネクストホップのmtuは800だよ」

というicmpパケット(PathMTUDiscovery)が来ているため経路上のMTU値も判断できるのです。
ここまで来ると、なんだかMTU怪しいなと感じませんか?

 

原因を特定する

さて、経路上のMTU値が低い事がわかりましたが、果たしてそれが原因なのでしょうか?
それを特定するためにはFWのコンフィグを見る必要があります。
FWには以下のような設定が入っていました。

・firewallをeth0にセット
・デフォルトアクションはドロップ
・許可するポート番号は80番と22番

つまり、HTTP(80/tcp)とssh(22/tcp)以外は通過できない状態にあったのです。
では整理も兼ねて、現状分かっている情報でトポロジ図を作ってみましょう。

このようになりますね。
それでは、これによってどのような事が起きるのでしょうか?
名前から先にお伝えすると、PathMTUDiscoveryBlackholeという現象が起きています。

PathMTUDiscoveryBlackholeとは・・・
経路上に異なるMTU値が存在していても、 Path MTU Discovery によって通信することができるようになりますが、適正なMTU値を伝達するためのICMP(type3 code4)パケットを送信元に送信しない設定や、途中の経路でICMPがフィルタリングされている場合には、以下のような問題が発生します。以下のような状態の事をPath MTU Discovery Black Holeといいます。

詳しくは以下のリンクへ
引用元 : http://www.infraexpert.com/info/5.2adsl.htm – ネットワークエンジニアとして

 

では以上の事を踏まえ、Webページを参照しようとした場合の流れを考えていきましょう。

Webページを参照する時の流れ

1.ユーザがWebページをサーバにリクエスト
2.3WAYHandshake時に交換したMSSに合わせてサーバがWebページを送信
3.通信経路上にあるネットワーク機器のMTU値が低いため、Webページを受け取れない
4.通信経路上のネットワーク機器(MTU800)がPathMTUDiscoveryをサーバに向かって送信する
5.FWによってPathMTUDiscoveryが拒否される
6.PathMTUDiscoveryBlackholeが発生し、Webページが読み込まれない

通信の流れを文章で書くと、このような形になっていたわけですね。
つまりここを解決できればなんとかなりそうですね!

対処する

そうなると、対処方法としては以下の二つが挙げられます。

・FWでicmpを通すように設定変更を行う (PathMTUDiscoveryのみ許可する場合はtype3code4のみ指定)
・サーバ側のMTUを経路上の最小MTU値に合わせる

このどっちかを行えば、今回の現象を回避できそうです。
ただし、問題文には以下のような記述があります。

尚、変更するのはサーバのみでお願い致します。

ということは、今回はサーバ側のMTUを変更すればよさそうですね。
それではサーバのMTU値ですが

今回の環境だと、このファイルに追加記述する事で変更できます。
追加する内容は以下になります。

これで保存した後に、インタフェースをアップし治す事でMTU値が反映されます。

以上で、対応完了となります。

尚、以上のMTU設定に加え、PathMTUDiscoveryBlackholeについて触れていると完答となっていました。

 

 

まとめ

「PathMTUDiscovery問題」如何だったでしょうか?
序盤の方では「よく見る事」と「気づき」が重要になっていたので、難しい問題になったかもしれません。
そもそもこの問題自体、問題作成や検証にものすごく時間がかかった問題なので、私自体苦労して作っていました。
「MTUは暗黒大陸」なんて言われる事もあるようなので、この問題を通じてMTUの重要さとめんどくささが伝わればと思います!

PAGE TOP