急に外部APIとの通信が "dh key too small" で失敗するようになったのはなぜ？
こんにちは。最近TRAVEL Nowの開発にも顔を出すようになったうなすけです。今回はTRAVEL Nowの開発において発生した問題について書こうと思います。
外部API連携部分で突然のエラー
TRAVEL Nowでは、外部のOTAと連携し、旅行商品を皆さんに提供しています。 そんな数多くのAPIのうち、ある特定のAPIで次のような例外が発生して通信ができなくなってしまいました。
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: dh key too small)
それも、本番環境でのみ発生します。
始めはこのエラーについてよく理解しておらず、 http.verify_mode = OpenSSL::SSL::VERIFY_NONE を指定してみたり、 apt install ca-certificates をしてみたりしたのですが、エラーの解決には至りませんでした。
翌朝、詳しく原因調査
翌日、腰を据えて調査にかかりました。
まず、 curlの結果を見てみます。
$ curl -v https://example.com # 実際は異なるURL # ...snip... * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (OUT), TLS alert, handshake failure (552): * error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small * Closing connection 0 curl: (35) error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small
production環境では、上記のように失敗してしまいます。しかしstaging環境では……
$ curl -v https://example.com/ # 実際は異なるURL # ...snip... > GET / HTTP/1.1 > Host: dh1024.badssl.com > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.10.3 (Ubuntu) < Date: Mon, 29 Jul 2019 06:08:23 GMT < Content-Type: text/html < Content-Length: 568 < Last-Modified: Thu, 11 Jul 2019 17:37:21 GMT < Connection: keep-alive < ETag: "5d2773d1-238" < Cache-Control: no-store < Accept-Ranges: bytes < # ...snip...
成功してしまいます。
OpenSSLのバージョンが環境ごとに違う？
さて、 "dh key too small" というエラーメッセージで検索をすると、OpenSSLをアップグレードしたためにエラーが出る、という情報が出てきます。
そこで、環境ごとのOpenSSLのバージョンを確認してみます。
# staging $ openssl version OpenSSL 1.1.0j 20 Nov 2018
# production $ openssl version OpenSSL 1.1.1c 28 May 2019
このように、production環境ではstaging環境よりも新しいOpenSSLが使用されていることがわかりました。
なぜこうなっているのかはさておき、このバージョン間でOpenSSLに入った変更を確認してみます。
OpenSSL 1.1.1 からデフォルトの鍵長が変更された
OpenSSL 1.1.1 でのCHANGELOGを確認すると……
*) Change the default RSA, DSA and DH size to 2048 bit instead of 1024. This changes the size when using the genpkey app when no size is given. It fixes an omission in earlier changes that changed all RSA, DSA and DH generation apps to use 2048 bits by default. [Kurt Roeckx]
という記述が見付かりました。
commitはこれになります。
実際にQualys SSL Labs で、問題のAPIで使用されているDH鍵の鍵長を確認してみたところ、1024 bitsでした。
なぜOpenSSLのバージョンが上がってしまったのか？
DH鍵の強度が不足しているために通信ができないことが判明したのはいいですが、ではなぜOpenSSLのバージョンが突然変化したのでしょう？
TRAVEL Now では、サーバーの実行環境はDockerによってコンテナ化されています。だからこそ、stagingとproductionでOpenSSLのバージョンが異なるという事態は不可解です。
調査のため、 debian openssl 1.1.1 で調べ、パッケージ情報を見てハッと気付きました。
Debian -- Details of package openssl in buster
「buster……？」
そう、Debianの最新安定版のbusterが、2019年7月6日にリリースされていたことをすっかり忘れていました。
そして、Dockerflieに指定していたFROM は、 FROM ruby:2.6.3 です。
Docker Hubを確認しに行くと……
無印の 2.6.3 は busterがbaseに使用されるようになっています！
このPull Requestによると、busterが使われるようになったのは7月11日からのようですね。
原因
つまり、原因をまとめると……
- 対象のAPIがDH鍵の鍵長として1024 bitsを使用している
- OpenSSL 1.1.1 から DH鍵の鍵長はデフォルトで2048 bitsとなった
- OpenSSL 1.1.1系 がインストールされるようになったDebian busterがリリースされた
- Docker公式のRubyイメージでbusterをbase imageとして使うようになった
という流れによって、今回の問題が発生したことになります。
DH鍵の鍵長における問題点
そもそも、なぜOpenSSL 1.1.1 から DH鍵の鍵長はデフォルトで2048 bitsとなったのでしょうか？
詳しく調べると、DH鍵交換には "Logjam Attack" と呼ばれる脆弱性があり、発表時点で鍵長として 512 bitsを使用するのをやめ1024 bits 以上、可能なら2048 bits以上を使用することが対策として提示されています。
今回のデフォルトの鍵長を2048 bitsにする修正は、直接この脆弱性と関係がある訳ではなさそう1ですが、デフォルトの状態でより安全になったということになるのでしょうか。
対応
原因から、対応としては stretch を使用すればよさそうです。
$ docker run -it --rm buildpack-deps:stretch bash root@3ef99d19ca47:/# openssl version OpenSSL 1.1.0k 28 May 2019
よって、以下の1行の変更で、こちら側の対応は完了です。
-FROM ruby:2.6.3 +FROM ruby:2.6.3-stretch
また、APIを提供しているサービス運用事業者にも、上記のような調査結果、対応方法をまとめて連絡しました。先方の対応が完了し次第、再度buster baseのイメージを使用するよう変更するつもりです。
まとめ
- Docker化しているからといって、実行環境が完全に固定されているという思い込みは危険
- Docker imageのtagはなるべく詳細になるよう記述する
2.6よりも2.6-busterなど
ちなみに、同様の挙動をするURLとして、https://badssl.com が https://dh1024.badssl.com/ を提供しています。皆さんも、 buildpack-deps:stretch や buildpack-deps:buster などの Docker image で curl -v https://dh1024.badssl.com/ の結果を見てみてはいかがでしょうか。
2019-08-20 修正
「Ruby公式Dockerイメージ」という記述をしていましたが、Dockerによる公式Rubyイメージであり、事実と異なるので記述を修正しました。@knuさん、ご指摘ありがとうございます。
また、追記の情報をより詳細にし、誤字の修正しました。@whywaitaさん、@orisanoさんありがとうございます。
-
2011年以降、認証局で安全のためRSAの鍵長に2048 bitsを要求するのが一般的であるためとのこと https://github.com/openssl/openssl/issues/8737 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf↩
社内GPU機の構成をItamaeで管理するようにしたことと、その反省点について
⚠️⚠️ 注意 ⚠️⚠️
この記事の内容は2019年6月における弊社の状況についてまとめたものになります。内容を参考にする場合は注意してください。
こんにちは。機械学習についてはド素人のうなすけです。何もわかりません。この記事では、機械学習に使用しているGPU搭載社内PCにItamae recipeを用意した話をします。
不調になったGPU機
弊社には、TITAN Vを2枚積んだマシン(以下GPU機)があります。データ解析チームはそのマシンを利用して機械学習を行い、様々なモデルを作成してCASHやTRAVEL Nowのサービス改善に貢献しています。
ところがある日から、GPU機で学習を進めているうちに突然電源が落ちたり、そもそも起動しないということが頻繁に発生するようになってしまいました。
このGPU機はBTOとして購入したものなので、販売元に修理を依頼しました。結果、どうやら物理的な異常は解決したようなのですが、OSが初期化された状態で返却されてきました。
……帰ってきたGPU機に対し、OSの再インストールから各種ライブラリの導入までをデータ解析チーム内で行なっていたのですが、ライブラリのバージョンの組み合わせによっては、学習タスクを実行しているうちにOSごと落ちてしまうという現象が多々発生していました。
なので、僕が構成管理ツールを導入し、ライブラリ群のバージョンの固定と学習環境の再現性を確保することにしました。
Ubuntu 18.04.02 LTS のインストール
TensorFlow公式ドキュメントに記載されている、GPU supportも含むインストールは、18.04 もしくは 16.04 の場合が記載されています。16.04を選択する理由はないので、18.04.02 をインストールしました。
⚠️ 反省点
ここでインストールした Ubuntu は以下からダウンロードできる日本語Remixです。
よくよく考えると、別にデスクトップ環境を使いたい訳ではないので Ubuntu Serverを入れたほうがよかったのではないかと思いました。
GUIがあったら嬉しい場面もごくまれにありますが、次にOSの再インストールが必要になったときにはUbuntu Serverを入れようかなと思っています。
機械学習環境の構築
さて、勝負はここからです。
ちなみにデータ解析チームからは、以下の構成の場合に学習を完了させることができなかった、という報告を受けました。
nvidia-driver-410- CUDA 10
- cuDNN 7.4.2
※ 今後出てくるRubyのコード片はItamae recipeの一部として実行されているものです。
GPUドライバーのインストール
18.04.02 (以下Bionic) で、標準でインストールできるNVIDIAのプロプライエタリなグラフィックボードのドライバーは nvidia-driver-410 です。
が、しかし nvidia-driver-410 では学習を終了させられなかったとのことから、 以下ppaを追加し nvidia-driver-390 をインストールしてみることにしました。
execute 'add graphics-drivers ppa' do command 'sudo add-apt-repository --yes ppa:graphics-drivers/ppa' not_if 'test -e /etc/apt/sources.list.d/graphics-drivers-ubuntu-ppa-bionic.list' end # require reboot if it installed package 'nvidia-driver-390'
ただ、インストールしてから学習を実行することを何度か繰り返した結果、どうやら nvidia-driver-410 のほうが安定することが判明し、最終的には nvidia-driver-410 をインストールしました。
CUDAのインストール
CUDAも、TensorFlowのドキュメントでは10をインストールするように記述されていますが、前述のように9系をインストールします。
そのためには、17.04 用のパッケージを追加しなければいけないようです。
「ホントに？」と思いながらも試してみましたが、どうやらこれでもインストールでき、動作するようなのでこのまま進めることにしました。
# /etc/apt/sources.list.d/cuda.list deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1704/x86_64 /
remote_file '/etc/apt/sources.list.d/cuda.list' do mode '644' end remote_file '/etc/apt/sources.list.d/nvidia-machine-learning.list' do mode '644' end execute 'add nvidia publey' do command <<~CMD sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1704/x86_64/7fa2af80.pub CMD not_if 'apt-key list | grep cudatools@nvidia.com' end execute 'apt update' package 'cuda-toolkit-9-0' package 'nvidia-cuda-toolkit'
しかし、この状態で cuda-9-0 というパッケージをインストールしようとすると、以下のエラーで止まってしまいます。
$ sudo apt install cuda-9-0
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
cuda-9-0 : Depends: cuda-runtime-9-0 (>= 9.0.176) but it is not going to be installed
Depends: cuda-demo-suite-9-0 (>= 9.0.176) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
これは最終的には nvidia-compute-390 というパッケージが見つからないことが原因です。しかしこのパッケージは、先程インストールした nvidia-driver-390 というmetapackageに含まれているという情報があります。
どういうことなのでしょう 🤔
ただ、この状態でも nvcc -V の結果に Cuda compilation tools, release 9.1, V9.1.85 とあるので、cudaが使用できる状態になっていると判断してよさそうです。(腑に落ちませんが)
cuDNNのインストール
libcudnn パッケージもインストールする必要があります。ただし、7系は落ちるということなので他のバージョンのインストールを検討しなければなりません。
しかし7より新しいバージョンは NVIDIA Developer Program Memberでないと入手できないようです。
ところで弊社はNVIDIA Inceptionプログラムの日本パートナーに認定されており、NVIDIA Developer Programのアカウントを持っているので、cuDNN 9 のtarballをそこからダウンロードしました。
(cudnnのtarballは400MB弱あるので、git repositoryに含めるのであればgit-lfsを使用する必要があるでしょう)
remote_file '/home/foo-user/cudnn-9.0-linux-x64-v7.6.1.34.tgz' execute 'extract and deploy cudnn lib files' do command <<~CMD tar -xvf cudnn-9.0-linux-x64-v7.6.1.34.tgz sudo cp -P cuda/lib64/* /usr/local/cuda-9.0/lib64/ sudo cp cuda/include/* /usr/local/cuda-9.0/include/ sudo chmod a+r /usr/local/cuda-9.0/include/cudnn.h CMD not_if 'test -e /usr/local/cuda-9.0/include/cudnn.h' end
⚠️ 反省点
nvidia-docker2 を導入して、Docker コンテナ内で学習を実行させるようにすれば、最低限のパッケージ導入で環境構築ができたのではないかと思います。その場合、必要なのは nvidia-driver-* だけになるのでしょうか？
tensorflow/gpu.Dockerfile at master · tensorflow/tensorflow · GitHub を見る限りではそう判断してよさそうですが……
これについてはデータ解析チームと協力しながら調査をしてみたいと考えています。
最終的に入ったものたち
- Ubuntu 18.04.02 LTS
nvidia-driver-410- CUDA 9.1
$ lsb_release --all No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic $ nvidia-smi Fri Jun 28 18:57:47 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 410.104 Driver Version: 410.104 CUDA Version: 10.0 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 TITAN V Off | 00000000:17:00.0 Off | N/A | | 29% 42C P8 26W / 250W | 0MiB / 12036MiB | 0% Default | +-------------------------------+----------------------+----------------------+ | 1 TITAN V Off | 00000000:65:00.0 On | N/A | | 33% 47C P8 31W / 250W | 139MiB / 12033MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 1 1350 G /usr/lib/xorg/Xorg 59MiB | | 1 1799 G /usr/bin/gnome-shell 78MiB | +-----------------------------------------------------------------------------+ $ nvcc -V nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2017 NVIDIA Corporation Built on Fri_Nov__3_21:07:56_CDT_2017 Cuda compilation tools, release 9.1, V9.1.85
いろいろ試行錯誤してこのような結果になりました。このあたりのベストプラクティス (このバージョンの組み合わせは相性悪い、など) がありましたら教えていただけると助かります。
まとめ
Itamaeを導入しつつ環境構築していくことによって、複数ライブラリのバージョンによる相性問題との格闘を楽に行なうこができました。が、しかし修理に出す前の時点で、そもそも構成管理ツールを導入して再現性のある機械学習環境を構築しておくべきでした。
今後、様々なライブラリのアップデートや何らかの構成の変化なども、しっかりItamae recipeとしてコード化していくことで、データ解析チームの速を止めないようにしていきたいです。
JSAI2019に参加してきました
こんにちは、株式会社バンクのデータ解析チームです。 6/4（火）～6/7（金）に新潟で開催された「2019年度人工知能学会全国大会（JSAI2019）」に参加してきたので、そのレポートをお届けします！ 今回はチームから3人参加したのでそれぞれの印象に残った発表をそれぞれ簡単に紹介していきます。
人工知能学会（JSAI）の紹介・参加経緯
人工知能学会（JSAI）は1年に1度、6月に行われる人工知能技術に関する発表を行う学会で、毎年違う県で開催されます。今回は第33回目で新潟県新潟市（朱鷺メッセ 新潟コンベンションセンター）で行われました。今年の参加者は3000人近くと年々増加しており、人工知能技術への関心の高まりを感じます。
データ解析チームは自社サービスである「CASH」や「TRAVEL Now」のデータと日々向き合っています。今どんな研究がなされているか、他社でどのような取り組みが行われているか、といった発表の聴講を通して、プロダクトへ反映できそうな新たな技術・知見を得るために参加しよう、ということになりました。
発表レポート
それではデータ解析チームのメンバーがそれぞれ印象に残ったと感じた発表を簡単に紹介していきます。 （説明に用いた図はそれぞれの講演PDFより引用しております）
視線データを活用した深層学習による胸部X線写真の診断的分類*1
局所画像を追加入力とする深層学習による自動診断モデルの研究でした。 自動診断を行う研究は以前にもありましたが、こちらの研究では写真全体の画像に加えて 「診断時に医師が凝視している領域」の画像も入力として与えることができるモデルとなっていました。
「全体を俯瞰した後に局所部分に注目する」という、より実世界での人間の動きを再現できるようなモデルを再現して医師の知見をモデルに反映して診断精度を向上させているのが印象的でした。
CASHでも熟練の査定員が凝視している領域の画像データセットを作成し、査定員の集合知のようなモデルを構築することで自動真贋査定システムにも応用できるような発見のある発表でした。
機械学習を用いた地域間の仮想通貨フローの可視化*2
Bitcoinユーザーの地域推定モデル構築の研究です。 Bitcoinの特徴として匿名性が挙げられますが、ユーザーやBitcoinの流れを追跡することは不可能ではありません。 こちらの研究では、Bitcointalk.orgの投稿データとBitcoinトランザクションデータのパターンの類似性を利用してユーザーの地域推定を行っています。 本研究では構築したモデルを用いて匿名性を持っているBitcoin市場であっても物理的距離の近いユーザー同士が主に取引していることを明らかにしましたが、これは取引所やサービス系会社がハブの役割をしており、このハブの活動パターンは地域的特徴を強く持っているためでした。 Bitcoinは基本的にどの仮想通過取引所でも扱っているのでこのようなパターンが見られますが、アルトコインはまた違った動きをするのであろうと思われます。
深層学習を用いた不動産間取り図のグラフ化と物件検索への応用*3
物件検索サイトの間取り図を用いて間取り構造のグラフ化を行い、その応用として類似物件の検索に役立てるという研究です。各部屋や階段などとの具体的な隣接関係（ここでの隣接は、単に隣り合わせではなく行き来可能であることを意味する）をグラフ化することで、単に見かけが似ているかどうかではなく、より住居での現実行動に即した類似性を見出せるというものです。
類似度としてグラフ間のMCS(Maximum Common Subgraph)をみていますが、簡単な間取りだとスコアが一致する例も少なくないように見え、別の類似度手法やメタ条件と組み合わせるとよりよい類似度の計算が行えそうな気がしました。
実際に行き来できるかの制約条件がどのくらい検索のユーザ体験に寄与できるかは不明ですが、個人的には痒いところに手の届く改善に繋げられそうでビジネス的な価値のある研究に思えます。
まとめ
以上、簡単ですが人工知能学会2019の参加報告をさせていただきました。
昨年鹿児島で開催された人工知能学会にも聴講参加させていただきましたが、AI技術の最先端に触れられることや参加されている他の企業の方や学生の皆様と議論ができる大変貴重な場だと思っております。
まだまだ少人数で未熟なチームではありますが、今後ともサービスをより便利に使いやすくするために取り組んでいきます。会場等で私達を見かけたら是非お声がけください。
References
*1: 井上 大輝, 木村 仁星, 中山 浩太郎 et al. “視線データを活用した深層学習による胸部 X 線写真の診断的分類“. 第33回人工知能学会全国大会, 2019. (https://confit.atlas.jp/guide/event-img/jsai2019/1H3-J-13-02/public/pdf?type=in 2019/6/10確認)
*2: 全 珠美,水野 貴之. "機械学習を用いた地域間の仮想通貨フローの可視化". 第33回人工知能学会全国大会, 2019. (https://confit.atlas.jp/guide/event-img/jsai2019/1P2-J-13-03/public/pdf?type=in 2019/6/10確認)
*3: 山田 万太郎, 汪 雪婷, 山崎 俊彦, 相澤 清晴. “深層学習を用いた不動産間取り図のグラフ化と物件検索への応用“. 第33回人工知能学会全国大会, 2019. (https://confit.atlas.jp/guide/event-img/jsai2019/3N4-J-10-03/public/pdf?type=in 2019/6/10確認)
社内で開発したAI技術を全社員に知ってもらうために
こんにちは。 株式会社バンクのデータ解析チームの齋藤 (id:tstomoki) です。
バンクにおけるデータ解析チームとは
まず、「データ解析チーム」って何をしているのかという話ですが、 基本的にバンクのプロダクト全てに関して下記を行っております。
- 様々な判断や意思決定をデータや数値を使ってサポート
- 課題に対してのデータ分析と問題解決のための予測モデルを構築, etc.
大企業におけるAIチームとBIチームとインフラチームなどで分担しているような業務を全てまとめて行っているのがこのデータ解析チームです。
※ Artificial Intelligence: 機械学習技術を用いたサービス改善
※ Business Intelligence: データ分析の結果を用いた意思決定のサポート
これまでどんなものを作ってきたのか
そんなデータ解析チームでは CASH や TRAVEL Now で使用できるように、機械学習モデルを解析APIとして作成しています。
また、プレスリリースにもあるように、NVIDIA Inceptionプログラムの日本パートナーにも認定していただき、オンプレミスなGPU環境などを使用して、CASHの商品画像やサービスのユーザ情報を入力とした大規模なネットワークモデルなどの構築を行えるようになりました。
例えばその中の１つとして、「ブランドタグ分類API」というAPIがあります。
CASHでは、一部のブランドについてはアイテム全体の写真に加えてこちらのようなタグの写真も送ってもらえるような仕組みになっています。
※ 本ブログ内のアイテム画像は社内で撮影
このようなブランドタグの写真を入力に
画像のブランドタグが申請通りのブランドなのか
というような推定を行い、未然に虚偽申請を防ぐことでアイテムの査定などに活かしています。
社内でプロダクトを知ってもらうために
先日、弊社代表の光本がTwitterでもつぶやきましたが、これまでにデータ解析チームが作成し・サービス導入したAPIもかなり多くなってきております。
CASHのデータ解析チームが開発して社内で活用してる解析API、今見たらいろいろあった！これ以外にももちろんたくさんある！便利！ pic.twitter.com/dUQch5p4HN
— Yusuke Mitsumoto 光本勇介 (@Yusuke_Tokyo) 2019年4月18日
このようなAPIは、サービスでの問題ベースで開発が進められることが多いです。 ですが、学会等で発表された最新技術をベースに「なんとなく使えそうだな」というようにテクノロジードリブンでAPIの開発が行われる場合があります。
そのようなAPIは、我々からサービス側に働きかけないとAPIが存在することすら認知されないので、先述のツイートにもあったようにAPI一覧ページを全社に公開して呼びかけています。
また、一覧から対象のAPIを選択すると以下のように実際のレスポンスも確認することができるため、手軽にテストしてもらうことで、サービス導入のアイディアなどを膨らませてもらうこともできます。
実際にアプリ側のエンジニアに導入を依頼する際にも、(もちろんAPI仕様書等は作成しますが)こちらのページを参照することで、説明もしやすくなるのでおすすめです。
まとめ
今回はデータ解析チームから初の投稿ということで、
- データ解析チームがどのようなチームなのか
- 社内でどのような工夫をしているのか
について記載させていただきました。
まだまだ少人数で未熟なチームではありますが、今後ともサービスをより便利に使いやすくするために取り組んでいきます。
次回はデータ解析チームのメンバーが2019年度 人工知能学会全国大会 (第33回)を聴講予定なのでそちらについての記事を書きたいと思っております。
オフィスネットワークを刷新し、Cisco Merakiを導入しました。
今回する話
みなさんこんにちは。株式会社バンクの うなすけ (id:yu_suke1994 )と id:HolyGrail です。 先日、オフィスのネットワークを刷新し、Cisco Merakiを導入しました。
今回は
- オフィス人数と社内ネットワークの変遷
- 機材とサービス選定の話
- 自前でセットアップを行った話
について弊社における事例を紹介いたします。
オフィス人数と社内ネットワークの変遷
さて、我々のようなベンチャー企業だと、創業期は家庭用のWi-Fiルーターでも業務が滞りなく行えます。しかし、10人、20人と従業員が増えるにつれ、家庭用のWi-Fiルーターから、SOHOや業務用のルーターや無線アクセスポイント（以下、無線AP）を導入しないとインターネットが詰まったり、色々な問題が発生します。 そして、人員の増加に伴う移転のタイミングで専門の業者に社内ネットワーク環境の構築を依頼するというケースが多いかと思われます。
弊社の場合
弊社は、現住所に移転するタイミングで無線APを3つに増設しました。業者に構築もお願いし、従業員と来訪者とでSSIDの分割とVLANへの収容、VLAN間での通信の遮断などの基本的なネットワークの設定を行いました。
しかし、ワイヤレスLANコントローラの導入には至らず、各自が自席から一番近い無線APのSSIDを選択して接続するという、前時代的な運用を要求せざるを得ない状態が長く続いてしまいました。 また、無線APのスペックがよくないのか、20端末程度がぶらさがるだけで顕著な通信速度の低下や無線APからの切断が発生し、不満の声も多く挙がりました。
そこで、ある程度の規模の会社に所属している友人らに相談し、社内ネットワーク刷新に向けて業者や機器選定をすることになりました。
機材とサービス選定の話
さて、今回の刷新にあたり弊社では「Cisco Meraki」と「Mist」を比較検討する流れとなりました。
Cisco Meraki
Cisco Meraki(以降Meraki)は、前述のワイヤレスLANコントローラーなどの管理機器を全てクラウド上に置き、SSIDの設定、サイトフィルタリングから周波数設定までのあらゆる設定をWebブラウザ上で行うことのできる、クラウド管理型ネットワークシステムです。日本国内でも、検索するといくつもの導入事例が見つかります。
Mist
Mistは上記Merakiの特徴に加えて仮想ビーコンによって得た位置情報などを元に、機械学習技術によって更なる運用の簡素化を目指すクラウド管理型ネットワークシステムです。
選ばれたのはMerakiでした
比較検証するにあたって、MerakiとMist、どちらも検証端末を借りて社内で試用してみました。
そして比較検討した結果
- 社内でも環境設定等を行うにあたり日本語のUIが用意されている
- 国内での採用実績がすでに多くあり、Cisco Merakiの担当者とも直接やりとりができる状態にある
- スイッチ、ルータなどのレイヤーまで含めてMerakiのクラウドシステム上で管理を行うことができる
といった点から今回はMerakiを採用するに至りました。
自前でセットアップを行った話
さて、機器とサービスの選定が完了し、いざベンダーに依頼をというところであるニュースが流れてきます。
そう、DMMからのMBOです。なので、今後は自己資本で会社を運営していかなければなりません。となると、無駄なコストはできるだけ削減する必要があります。 そこで、ベンダーからはネットワーク機器の購入のみ行い、施工と設定については自分達で行うことになりました。
設置の様子
というわけで、MerakiのSwitchとAPがオフィスに届いたので、設置、そして設定を行いました。
結果
Merakiの導入によって、社内のSSIDが統一され、社員に快適なインターネット環境を提供することができるようになりました。
また、Wi-Fiが使えるというだけではなく、実はMerakiはAPIを公開しているので、これで色々と遊ぶこともできそうです。
Merakiのネットワークに接続してみたい方(？)、是非オフィスに遊びに来てください。
追記
4/24 19時
脚立について、推奨されていない使用方法をしている画像を削除しました。脚立の安全な使い方については、以下をご覧ください。ご指摘いただきありがとうございます。
脚立の安全な使い方 | 製品の安全な使い方 | サポート | 梯子、脚立のパイオニア 長谷川工業株式会社
4/25 14時
一部、本文を修正しました。
