こんにちは。並河(@namikawa)です。
すっかり秋の足音が聞こえてまいりました。秋といえば食欲の秋。ラーメンの秋です。
会社では最近新しい方がたくさん入社してきてくれていて嬉しい限りで、エンジニアやデザイナーも増えてきています。
面接をしていても「社内の雰囲気ってどんな感じなんですか〜?」なんて聞かれることも多いので、ちょっと最近入社されたエンジニアの方のデスクを紹介してみようと思います。
弊社では、入社される方全員に、業務で使うマシンの希望を伺っているのですが、エンジニア・デザイナーは MacBook Pro を選択される方がほとんどです。エンジニアの場合はそれに 32 インチの 4K モニターを一緒に貸与することが多く、デザイナーは EIZO のモニター(27インチ、2枚等)とか希望を伺いながら決める感じです。
参考までに、池田さんが書いてくれた、4Kモニターを使っているレポートのエントリを貼っておきます。
本日のエンジニアのデスク
・・・で、こちらの方は、ErgoDox!!というエルゴノミクス的なキーボードをご使用で、なんというか姿勢が良い!さすがですねw
分離型のキーボードを使っていると、こんな感じでノートが中央に置けるんですね。スペースが広く使えて良さそうです。
少しでも社内の雰囲気が伝わりましたでしょうか・・・?各エンジニアのデスクを見てると、結構個性やこだわりが出ていて面白いなぁと思います。
こんな感じで、またシリーズ的に紹介してみたいと思います。嫌がられなければ・・・w
閑話休題、そろそろ無線LANの話を
最近、全社的にたくさん入社される方がいて、一定規模になってきたベンチャー企業が、いよいよ情シスまわりどうするの?的な問題が強くなってきたと感じている日々なのですが、そのうちの1つの業務が社内ネットワークまわり。
下記のエントリーでも torigaki さんが書いてくれていますが、弊社オフィスでは数台の無線LANアクセスポイントがありまして、時折不調になったりしています。
構成としては、オフィスの社内LANについては、YAMAHAの機器で構成していて、無線LANのAPが計7台動いており、内訳は下記のような感じです。
- WLX302 : 5台
- WLX402 : 2台
で、無線LANが不調になる、という事象には問題になるパターンが何種類かある気がしていまして、ざっくり書くと、
- APには繋がっているが、スループットが不安定になり、すごく遅くなる。
- APには繋がっているが、通信できなくなる。(DHCP経由でクライアントにIPアドレスが付与されないケースもある)
- APのメモリ使用量が急増し、再起動がかかってしまう。
振る舞いとしてはこういったパターンが見えます。
で、色々と設定を変えながら切り分けを行った結果、部分的に改善が見られまして、まだ改善途中ではあるのですが、その内容を簡単にまとめておこうと思います。
YAMAHA のメーカーサポートについて
最初に書いておくと、後述の試行錯誤の過程で、YAMAHAのサポートには連絡・相談させてもらっていて、Debugログの提出をしながら解析をしていただいたのですが、結論からすると原因は究明されていません。
尚、YAMAHAのサポートの方は、大変丁寧に対応していただきまして、感謝しております。
試してみたこと
WLX402 の 2.4GHz 帯を利用しないようにする
実は前のオフィスでにいた時も、時折、WLX402 が不安定になることがありまして、その時に調べた時は、随分とまわりに無線LANのSSIDがありまして、干渉が見受けられたのと、AP周辺での需要がなかったこともあり、2.4GHz帯の利用をやめて、その結果、安定したことがありました。
それもあり、今回も 2.4GHz 帯の ON/OFF を試してみましたが、結果は変わりませんでした。
送信出力と受信レートの調整
社内MTGで移動していると、遠くのAPにつながったまま通信が継続することがあったため、送信出力を少し弱めたのと、受信レートで低レートで接続されないように調整した。
通常利用において、多少良くなかったかな、という体感はできたのですが、上記で挙げた問題の1つである「APには繋がっているが、スループットが不安定になり、すごく遅くなる。」の解決には至りませんでした。(なぜか6Mbpsでの接続が有効となり切られない)
DFSの影響を受けないチャンネル調整
5.0GHz帯のチャンネルについては、一部が気象レーダー等、各種レーダーシステムで利用されており、これらに影響を与えないよう、無線LANアクセスポイントには、DFS (Dynamic Frequency Selection) という機能が用意されています。
DFSがレーダー波を検出することで、使用チャンネルの変更が行われるということで、であればレーダーシステムの使用しない W52 (36ch/40ch/44ch/48ch) に固定してみるのも試してみましたが、こちらは症状変わらずでした。レーダーシステムの影響ではない、と。
チャンネル設定の確認
Mac OS 標準のワイヤレス診断ツールでスキャンした感じだと、オフィス近辺は飛んでいる SSID も多く、無線LAN的には過酷な環境であることはわかっていまして、前オフィス同様にチャンネル設定は自動で、チャンネル範囲は選べるものを全て選択していました。
ところが、見える化ツール (ステータスをモニタリングするYAMAHA社の無線AP標準ツール) を見ていると、CRCエラーレートがそれなりにある状態。
ワイヤレス診断ツールで眺めている感じ、 5.0GHz帯でさえも、社内のいくつかあるAPのほとんどが、36チャンネルに集中して自動設定されていたりしていました。
チャンネルの自動設定があまり期待できない可能性があるので、これはきちんとチャンネルを干渉しないようセグメンテーションする必要があると思い、2.4GHz帯については、極力干渉しないように場所を考慮しつつ、チャンネルを直接指定して分散させました。5.0GHz帯については、チャンネル設定は自動のままにしつつ、チャネル幅を小さくし、自動チャンネル選択範囲を増やしつつ、干渉しないよう、W52/W53/W56 からバランスよくAPごとに選びようにしました。
その結果、社内のいくつかのポイントで干渉がそれほど起きていないことを確認できました。
あわせて、前述していた受信レートの設定が、少し攻め気味に設定していた部分があったので、Basicレートを 11Mbps(2.4GHz)/12Mbps(5.0GHz) まで落としました。
この辺までで、問題として挙げていた「APには繋がっているが、スループットが不安定になり、すごく遅くなる。」この点はほぼ解消できたと思っています。あとの2つの問題も発生頻度が少なくなりました。 ひょっとしたら干渉が(おそらく)かなりマシになった点が寄与しているのかもしれません。
さいごに
オフィスの無線LAN運用は、複数台の無線APを協調的に動作させたりとか、様々な外部要因が影響することで、なんだかんだ色々トラブルが潜在的に潜んでいることがあり、運用の難しさを感じています。
基本的には問題に対して、ロギング・モニタリングをちゃんとやるのと、解決のための仮説を立てて、1つずつ地道に切り分けていくしかないとは思っています。解決手段の仮説が出尽くしたところでプロに頼もうとは考えていますが、エンジニアとしてついトラブルシューティングしてしまいますね・・・。(致命的な問題であれば、解決最優先となるので、また別の話になりますが。)
一旦こんな感じで、問題が出たタイミングで試行錯誤しながら今後もやっていこうかと思っています。
最後に、、、毎度で恐縮なPRタイムですが、弊社ではエンジニア・デザイナーを絶賛大募集しておりますので、少しでも気になれば、カジュアルにランチでもしながらお話しさせてくださいー!
弊社は、今年オフィスの引っ越しを行ったのですが、オフィスビルの隣には有名なカレー屋(ボンディ)さんがありますので、美味しいカレーでも食べながら是非!
少しでもご興味があればお手数ですが @namikawa まで、お気軽にDM等いただければと思います。
それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́
(@namikawa が書いた過去記事)
- Linuxでユーザアカウントを無効化するエトセトラ
- /etc/hosts で同じホスト名に違うIPアドレスを設定したらどうなるか
- 何気に便利に使えるかもしれない authorized_keys のオプション
- Linuxでinodeが枯渇した場合にどうやって調査するか
- アスタミューゼの開発組織と採用に関するQAアレコレ
- Linuxでディスクキャッシュとして使える「bcache」を試してみた
- Google Compute Engine のディスク(SSD)ベンチマークを取ってみた
- nginx + ngx_mruby でSSL証明書の動的読み込みを実現して、作業がとても楽になった話
- クラウドにあるステージング環境のシステムコスト大幅削減を進めている話
- 企業向けエンジニアブログの作り方