2019-10-02

社内無線LAN環境改善のためにやったこと (2019/Summer)

こんにちは。並河(@namikawa)です。

すっかり秋の足音が聞こえてまいりました。秋といえば食欲の秋。ラーメンの秋です。

会社では最近新しい方がたくさん入社してきてくれていて嬉しい限りで、エンジニアやデザイナーも増えてきています。

面接をしていても「社内の雰囲気ってどんな感じなんですか〜？」なんて聞かれることも多いので、ちょっと最近入社されたエンジニアの方のデスクを紹介してみようと思います。

弊社では、入社される方全員に、業務で使うマシンの希望を伺っているのですが、エンジニア・デザイナーは MacBook Pro を選択される方がほとんどです。エンジニアの場合はそれに 32 インチの 4K モニターを一緒に貸与することが多く、デザイナーは EIZO のモニター（27インチ、2枚等）とか希望を伺いながら決める感じです。

参考までに、池田さんが書いてくれた、4Kモニターを使っているレポートのエントリを貼っておきます。

本日のエンジニアのデスク

f:id:astamuse:20191001191856j:plain

・・・で、こちらの方は、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 が書いた過去記事）

2019-09-18

Pythonでも型を明記しよう

Python

f:id:astamuse:20190918114322j:plain

こんにちは、Scalaエンジニアのnishikawaです。今回はpythonについて少し話したいと思います。

Pythonって世間では

ライブラリが充実している
インタプリタ言語でコーディングから実行までが手軽

という印象が強く、初心者やプログラムが本職じゃない人からも好かれる言語だと思います。特に動的型付けによりスクリプトっぽい書き味に加え、オブジェクト指向プログラミングや関数型プログラミングなど、色んなスタイルでコードを組めるのも人気の一つなのではないかと思っております。

そんなPython、書き捨てレベルのコードならいざ知らず、本気で何か組もうと思うとある問題に差し掛かります。

それは

コードを書いているうちにどのようなデータを扱っているかを見失う

ということです。

これを読んでいる人は「そんなことないでしょw」と思うかもしれませんが、少しでもそのアプリから離れると途端に何をやってたか分からなくなることは少しプログラムを組んだことある人なら誰しも経験があると思います。これは動的型付け言語あるあるだと個人的には思っています。

これを解決するには型を宣言するのが一番でPython3からではそれができます。

そもそもPythonにはどんな型があるのか

Pythonにはどんな型があるのか代表的なものと自分が少し気になったものを以下にまとめてみました。

組み込み型	説明
bool	真偽値
int	整数
float	浮動小数点数
complex	複素数
list	リスト
tuple	タプル
str	文字列
bytes	バイトオブジェクト
bytearray	可変バイトオブジェクト
memoryview	バッファプロトコルをサポートするオブジェクトの内部データへ直にアクセスすることができるオブジェクト
set	集合型
dict	マッピングオブジェクト（俗にいう連想配列やハッシュマップ）

複素数のcomplexやmemoryviewなんかは目からウロコでした。（複素数の型があるとか斬新w）

Pythonで型を宣言しながら変数を定義してみる

では、本題の型の宣言を行いながら変数を定義してみます。

書式は簡単で変数の直後にコロン区切りで組み込み型を定義します。

<変数名>: <組み込み型>

以下はREPLで変数宣言して値を代入し、出力した時の例

>>> zero: int = 0
>>> print(zero)
0
>>>

変数宣言時の例

>>> def test_print(txt: str):
...     print(txt)
...
>>> test_print("test")
test
>>>

実装時に型を宣言した方がいいと思った場所

ここまで型について色々書いてきましたが、最後にpythonでアプリケーションを実装する上で最低限こういう場合に型の宣言を入れておいた方がいいなと思った箇所をまとめておきます（備忘的な意味も込めて）

メソッド宣言時の引数と返り値
フィールドメンバー
生成したインスタンスを格納するための変数

メソッド宣言時の引数と返り値

メソッドを宣言する時、何をするものなのかをメソッド名に込めて実装することは多いと思いますが、メソッド名やコメントだけではどういうデータをインプットにどういうアウトプットを出すのかを見失うことがあります。そのため引数やメソッドの返り値の型を明確にすることでこの問題を回避できます。

フィールドメンバー

クラス内に定義するフィールドメンバーの型定義も重要なポイントだと思います。フィールドメンバーはクラスがどういう属性のデータを格納しているかを知るにはとてもいい情報だと思うからです。

これらの情報をしっかり書き込むことで、クラスの改修時や設計の見直しにも役立つと思います。

生成したインスタンスを格納するための変数

これはどちらかというとIDE用にあるといいなという感じです。IDEで全く型を定義しないでコーディングを行うと補完機能が使えないことが多々あります。そのため型の定義はやった方がいいと思います。

もっと言うとIDEの機能を最大限に活かすなら全ての変数の型を定義した方がいいと思います。

まとめ

Pythonはバージョンが3になってからより多くの機能が追加されました。変数に型を明示してもどんな値も受け入れてしまうなど、依然として型の重要性は低いですが、少なくとも人間がコーディングを行う限り今回紹介した型を明示的に表記できる機能は地味ながらとても重要だと思います。

この機能を活用してpythonのコードをより良いものにしてみてはいかがでしょうか。　

2019-07-24

PostgreSQL のバグ修正状況を調べてみた。

DB PostgreSQL Python データ開発エンジニア

はじめに

初めてこちらのblogに登場いたします。データエンジニアのt-sugai です。
今年の1月頃からアスタミューゼにJOINしています。
前職はJavaをメインとしたアプリケーションエンジニア……だったと思うのですが、エンジニアはエンジニアでいっしょくたの組織でした。そして最近は運用やDBAのような仕事を任されることが多かったこともあり、アスタミューゼではデータエンジニアとして働いています。

今日はデータエンジニアらしくデータベースのお話をしようと思います。

アスタミューゼで利用されているPostgreSQL

f:id:astamuse:20190724095444j:plain

国内外の特許の情報をはじめ、様々な技術情報を持っているアスタミューゼですが、RDBMSとしては主としてPostgreSQLを利用しています。（もちろん、RDB以外のDBMSもデータの量や特性、利用目的に応じていろいろ使っているのですが、今回はRDBのお話です）
私が入社する以前の話ですが、PostgreSQLを9.6にUpgradeした話も書かれています。

そう、世界にイノベーションを起こすための原石たり得るアスタミューゼの技術情報を保管しているDBなので、世の中の流れに追随して適切にバージョンアップしていかなければなりません。
論理レプリケーションが使えれば、バックアップの考え方はもちろん、準リアルタイムでのデータ加工についても利用方法が広がるでしょうし、大規模データに対してのSELECTではパラレルクエリーの効果だって期待できます。
さあ、早くPostgreSQL12にしましょう！
おっといけない、12はまだbetaだった。でも11なら正式リリースから半年以上経ったし、そろそろアップグレードしましょう！！

冷静な視点

新しもの好き、なによりも便利な機能とPostgreSQLが大好きな私はともかくとして、インフラ・事業に責任を持つ部長の namikawa からは

「ちょっと落ち着け。当たり前だが客観的にみて安定したといえるバージョンを使うようにしたい。バグ曲線みたいなものを参考にしながら、今後も使えるアップグレード方針を検討してほしい」

という、至極まっとうなリクエストが出たのでした。

PostgreSQL の開発プロセス

PostgreSQLはオープンソースのDBMSです。そして、近年のOSSプロジェクトにしては珍しい（と思う）のですが、基本的に本体の開発に関する議論はすべてMailing List（ML）で行っており、Issue Trackerに類するものがありません。
そうなるといわゆるバグ曲線的なものはすぐには得られませんね。
ないものは仕方がないのですが、「たぶん大丈夫だとおもうからUpgradeしようぜ」とはさすがに私もいえません。
このリクエストをいただくときに、「アスタミューゼでの話ではないが、某DBMSをうかつにUpgradeしてひどいバグを踏んでデータが壊れた経験がある」などという話をされていたのでなおさらです。

代替手段はないか？

要は新規リリース直後の、多くの人に使っていただいたからこそ出てきた不具合修正が収束してきていることがわかれば良いのです。
修正の情報が一番わかりやすそうなのはリリースノートじゃないでしょうか。
ということで、PostgreSQLのリリースノートを眺めてみましょう。
コミットメッセージなどでもよく使われる表現ですが、不具合の修正に類することは、ほぼ必ず「FIX 〜」という記述になっているように見受けられます。
これを数え上げたら、割とそれっぽい情報として代替できないでしょうか？

ところで Jupyter Notebook というやつがあるよね。

と、いうことで、スクレイピングというのもおこがましいレベルの話ではありますが、リリースノートのページをいくつか巡回して、内容を抽出して数え上げて、なんなら最後にグラフにでもできるとうれしいですね。

ここまで考えたとき、こういうのは「PythonとJupyterNotebookを使うといいぜ」と心のどこかで囁く声が聞こえた気がしました。勝手知ったる curl と grep と sed と awk 、あとはスプレッドシートでもあればどうにかなってしまいそうな気もしましたが、その場合次回アップグレード時などにもう一度やるのが面倒くさそうだったし、なによりも私はデータエンジニアに転向したのです。Pythonとももっと仲良くなりたい。そんな気持ちでJupyter手習いをやってみようと思ったのでした。

最近はDockerという便利なものがあるので、ちょっと使ってみたいくらいの用途だったら

$ docker pull jupyter/datascience-notebook
$ docker run --name notebook -p 8888:8888 jupyter/datascience-notebook

こんな感じでサクッと環境が作れてしまいます。簡単ですね。

プログラミングしてみる。

PythonやJupyter NotebookのTIPSについては、ほかに詳細なドキュメント・記事が豊富にありますし、ここですべてを解説することはしませんが、やってみたことをいくつかご紹介してみようと思います。

今回書いたソースコードは github.com/t-suga/postgresql_release_checkに置いておきます。

後半でデータをソートしたり分割したりするところで試行錯誤が多くなりすぎて力尽きました。
もう少しきれいにできたような気もするのですが……精進いたします。

Webページの取得とデータ抽出

HTTPリクエストは、 requests 、 DOMのパースには BeautifulSoup というライブラリがよく使われているようなので、これを使ってみました。正規表現には re 、集計には pandas グラフには matplotlib という定番ライブラリです。

これらを使えば、リリースノートのページから Fix〜 の記述を抽出して、数え上げることは簡単です。累積のFix数にするためには cumsum というメソッドを使いました。

PostgreSQLは初版からリリースノートがありますが、EOLになっているものまでスクレイピングすることはないでしょう。今回は9.3以降を対象とするようにしました。

初回の失敗。

当たり前ですが、素朴にやるとプロットはリリースごとになります。
そして、もちろんですが日々のアップデートには既存バグの改修というのもあり、そういったバックポートされるようなFixがあるため、このグラフはいつまでたっても収束しているようには見えなくなってしまいます。

リリースの間隔を考慮し、グラフを調整する。

リリースごとにリリース日を収集するようにして、リリース日の差分を取ることにします。
今回は、間隔の比が保存できていればいいと割り切って大分横着をしてしまいましたが、どうにかマイナーバージョン1を0として、リリースまでの期間が横軸になるようにデータを成形することができました。
このあたりもう少しきれいな方法があれば是非教えていただきたいです。

最後に、古いメジャーバージョンのものはそれだけ累積バグ数が大きくなりますが、ある一定のところまできたらあまり意味がないはずです。ということで、縦軸は対数にしてしまいます。

そんな感じで得られたグラフがこちらです。

f:id:astamuse:20190724095114p:plain — 得られたグラフ

グラフを読み解く。

といっても、一目瞭然で、きれいにほぼ同型のグラフになっています。
一番新しい11のラインすらもほぼ安定のカーブに半ば程度到達しており、10に関しては峠は越えたなという感じでしょう。
バージョン全体を概観すると、PostgreSQLはリリースから大体半年も経てば安定し始めており、1年経てばほぼ十分に安定すると考えてよさそうです。