こんにちは。品質保証部の園です。
モバイル端末、何台持っていますか? 管理面倒ですよね!!
積年の問題を解決すべく、OpenSTFとkintoneを組み合わせて、検証用のモバイル端末数十機を管理する仕組みを作りました。はまりどころ含めてご紹介します。
OpenSTFの導入
弊社が抱えていた問題点
製品の試験に使う端末を物理的に貸し出していました。その数ざっと100台ほど。iPhone、iPad、各種Android端末、フィーチャーフォンなどなど、OSのバージョンや画面サイズが異なるものが大量にあります。これらはkintoneで作成した「モバイル端末管理アプリ」を用いて、目当ての端末の利用状況を確認し、運よく空いていれば利用登録、管理棚から持ち出して作業する。という流れです。
この管理方法では、以下のような問題が発生していました。
- アプリ上は利用されていないはずの端末が管理棚に存在しない
- いつの間にか破損・紛失している
- 試験をしたい社員が勤務しているオフィスに、目的の端末がない
最初のふたつだけでも面倒なのですが、複数の拠点をまたいでいるプロジェクトでは3番目の問題も厄介でした。エミュレータで済ませられる場合にはそうしていたのですが、どうしても実機での検証が必要な場合、新たに端末を購入したり、海外拠点へ持っていったりしていました。私自身、ベトナムや上海への出張時に試験用の端末を持参したことが度々あります。
OpenSTFとは?
CyberAgent社が作成したモバイル端末管理用ソフトです。現在、OSSとして開発が進められています。
メインの機能は「モバイル端末の管理」と「接続されているモバイル端末の遠隔操作」です。 例えばMicrosoft SurfaceのようにタッチセンサーのついたPCから使用することで、Webブラウザ上に表示されているモバイル端末を指で操作することができるため、実機に近い感覚で操作できます。
OpenSTFの導入効果
OpenSTFを導入することで、前述の問題がほぼ解決できました。 利用者側からは「端末をロッカーの中から探す手間が省けた」という喜びの声があがった他、PCからの操作(「キーボードが使える」「試験仕様書からのコピペが可能」)が好評でした。 定期的に端末の棚卸(資産管理をするため)を行っていた管理責任者も、手間が減って喜んでくれました。端末を専用のラックにいれてOpenSTFに接続したので、行方不明な端末の捜索や破損事案が減ったのです。
一方、海外拠点からの利用についても、速度的な不満は出ませんでした。私も上海オフィスやベトナムオフィスに出張した際に、東京オフィスにある端末を操作してみましたが、特別遅延は感じられませんでした。 ただし、この感想はあくまで手動でテストした際の感想です。 Seleniumなどを使って自動でテストをする場合は、Selenium(Node)をOpenSTFを設置した拠点に配置するなどして、なるべく遅延をなくす工夫をするべきでしょう。
OpenSTFの導入にともなって実施したこと
このようにOpenSTFの導入効果は高かったのですが、運用開始にたどり着くまでには、いくつかの問題に対処する必要がありました。
LDAP認証の設定
新しいシステムを作る度に新しいユーザー・パスワードの作成を求めていては、ユーザーの利便性を損ない、システムの利用が促進されません。
…というのは半分建前で、ユーザー管理は手間が増えるので、やりたくありません。そこで、OpenSTFのユーザー認証を社内のActive Directoryに連携させることにしました。
LDAP認証を利用するために、OpenSTFの認証サーバーを以下のように設定します。
stf auth-ldap --app-url https://${PUBLIC_IP}/
--port 3000
-t 60
--ldap-url ldap://${LDAP Server}:${LDAP Port}
--ldap-bind-dn "cn=${CN},ou=${OU},dc=${DC},dc=${DC}"
--ldap-bind-credentials ${AD_PWD}
--ldap-search-dn "dc=${Search-DC}"
--ldap-search-field "cn"
--ldap-username-field
通信のSSL化
作成したOpenSTF環境への接続は、社内ネットワークからに限定しています。 とはいえLDAP認証を使用しており、パスワードが暗号化していない経路を通るのは望ましくありません。 以下の2点を実施して、通信をSSL化しました。
- OpenSTFが使うNginxのSSL化
- OpenSTFの起動時に付与するオプションを、HTTPS通信、WSS通信に変更
stf app --auth-url http://${PUBLIC_IP}/auth/ldap/
--websocket-url ws://${PUBLIC_IP}/
--port 3000
↓ 以下のように変更 ↓
stf app --auth-url https://${PUBLIC_IP}/auth/ldap/
--websocket-url wss://${PUBLIC_IP}/
--port 3000
端末管理用のラック関連
モバイル端末は専用のラックに収納し、施錠して管理することにしました。
ラック内にはハブを配置し、ケーブルに繋がれた端末が数十台鎮座しています。一時期ニュースをにぎわしていたような、過充電による爆発炎上は無いと思いますが、機材の異変は素早く察知し、対処したいものです。 異常発熱への対策として、端末/ラック監視を強化し、充電しない時間帯を設けることとしました。
端末の監視
OpenSTFは、端末のバッテリー温度を常に取得しています。
この情報は、OpenSTFのAPIにより外部プログラムから取得可能なので、端末の温度の急激な変化を察知して通知するようなプログラムを構築することが可能です。
ラック全体の温度監視
運用の都合上、モバイル端末が格納されたラックは、サーバールームではなく、執務スペースに配置されています。ラック自体が閉塞された環境になりやすい構造のため、オフィスの暖房と合わせて温度が上昇してしまうことを懸念しました。対策として、USBファンによる送風や、USB温度計による監視を実施しています。
USBファンはPCケース用の120mmを4つ配置。このあたりは静音PCを組んだ経験が生きています。
充電時間の調整
とはいえ、監視していても24時間体制でトラブルに即対処できるわけではありません。弊社の場合、実機での作業は人間による確認作業の割合が高いため、業務時間外の利用はほとんどありません。そこで、稼働がなく対処できない時間帯については端末の充電を止め、トラブルの要因を減らす方針にしました。
OpenSTFが構築されているサーバーと端末は、電源供給型のUSBハブで接続されています。端末の充電時間の調整は、このUSBハブの電源部分に時刻/曜日で電源供給のON/OFFができるタイマーを挟むことで実現しました。これにより、深夜や休日にトラブルが発生する可能性を低減しています。
モバイル端末の利用予約をしたい!
OpenSTFを導入したことで、モバイル端末の管理・利用効率が格段に向上しました。しかし、運用していくと、「端末の予約をしたい」という要望が出てきました。
従来の運用では kintone上の「モバイル端末管理アプリ」を用いて「この期間はこのモバイル端末を占有します」という『予約』が可能でした。プロジェクトの試験期間にあわせて試験用の端末を確保しておくイメージです。OpenSTFには、そういう期間指定の端末管理機能はありません。実際にOpenSTFへアクセスしたら別の人が目当ての端末を使っていた、という取り合いは避けたいものです。
必要なのは、
- kintoneアプリから予約情報を取得して
- (予約時間に)該当の端末が利用中の場合は、端末の利用を終了させ
- 予約者が利用している状態にする
という動作です。
kintoneとOpenSTFを連携しよう
幸い、OpenSTFとkintoneには、共に様々なAPIが用意されています。
このAPIを使い、kintoneに登録された予約期間に、確実に予約した端末を利用できる状態を作ります。
1) kintoneアプリ上の予約情報を確認する
kintoneのAPI「レコード一括取得」を使用し、kintoneのレコード情報を取得することができます。このAPIを使用して、kintone上に作った「モバイル端末管理アプリ」から予約情報を取得します。
2) 予約情報がある場合、該当の端末が利用されていないか確認する
OpenSTFのAPI「GET /devices/{serial}」を使用し、端末のSERIAL_IDを指定して情報を取得することができます。このAPIで情報を取得すると、該当の端末の利用状況がわかります。
3) 利用されている場合は、強制的に利用を中断する
OpenSTFのAPI「DELETE /user/devices/{serial}」を使用し、強制切断を行います。
注意点として、このAPIに付与するAPI-TOKENは利用者のAPI-TOKENにしないと切断することができません。そこで、ログイン情報をもとにLDAPサーバーからメールアドレスを取得し、それをキーとしてOpenSTFのrethincDBからAPI-TOKENを取得します。
4) 該当の端末を予約者が利用している状態に変更する
OpenSTFのAPI「POST /user/devices」を使用し、利用者を強制的に設定します。
こちらのAPIも、(3)と同様に予約者のAPI-TOKENを使用して実行する必要があります。
終わりに
OpenSTFを導入することで、管理しているモバイル端末の半数をラックに格納し、利用者・管理者双方にメリットを提供することができました。ソフトウェアだけではなく、ラックやセンサーなどを含めてうまく運用に乗せられたので、個人的にも満足度が高いです。 今のところOpenSTFはiOS端末を管理できないので、従来の貸し出し方式とハイブリッドな運用になってしまっていますが、そのあたりは今後のアップデートに期待しています。今後は端末の利用状況を分析し、効率の良い端末の破棄/追加も視野に入れていきたいですね。