2017-12-30

Androidを使用した多数移動体位置監視モデル

 前稿前々稿では iBeacon を使用した商品の存否確認に関するモデル(定位置ビーコン監視モデル)について記しました。これらのモデルは iBeacon を使用するため、その電波の到達範囲は0m~100m程度であるため、iBeacon(あるいは iBeacon を取り付けた商品)がその範囲を超えて出ていってしまうと、当然のことながらビーコン監視端末は iBeacon の存在を認識できなくなります。
 今回は前二稿とは趣を変え、モバイル端末を物品に取り付けることによってその位置を適時把握するモデルを考えるとともに、そのモデルに則したプロトタイプを作成・試用してみました。

多数移動体位置監視モデル

 本モデルでは、数十~数百、数千の移動する商品、物品、人などの物体に モバイル端末を取り付け、地図上にその所在地を表示しています。

 下図のように、モバイル端末のインターネット接続にはMVNOが提供する移動体通信網を使用し、端末はGPSにより得られた自身の位置情報をアプリケーションサーバ経由でDBサーバに送ります。DBサーバは送られてきた端末の位置情報を保存します。また、各端末の位置の地図上表示も、PC等のブラウザからアプリケーションサーバを介して行います。

多数移動体位置監視モデルの概要図
図1 ― モデル概要

通信端末について

 当初、上図端末には Raspberry Pi  等のシングルボードコンピュータを使用する予定だったのですが、検討を進めていくうちにコスト増のモデルになり得ることがわかりました。

 具体的には、まず、ラズパイにSIMドングルやGPSモジュール(ドングル)を載せる必要が出てくるわけですが、実用面を考慮するとユーザに容易にシャットダウンしてもらうための電源On/Offスイッチ、電源供給が遮断された場合に備え、UPSも準備する必要があります。

 これらのモノは全て自前で調達して設定しなければならないため、価格、性能評価や設定の労力、携帯性、収納性等がネックとなります。ラズパイは途中まで設定やテストを行ったのですが、結局 Android 端末を使用することにしました。
 Android であれば All-in-One で低価格(¥5千前後~)で入手でき、携帯性・耐衝撃性(移動時にコネクタ/ケーブル類が外れる可能性がほぼ無い)に優れ、電源周りで気を遣うことがなく、安定性・信頼性も実績十分です。
今回のテストに使用した Android フォントタブレット
今回使用したAndroidフォンとタブレット、OUKITEL社(写真左から3/4番目は¥5千/台で購入できた)

移動体通信会社(MVNO)

 本モデルでは多数の Android 端末を使用してインターネット通信を行うため、通信費用はできるだけ抑制したいところです。最近は格安MVNOの登場で、1GB程度のデータ量であれば月額¥500程度で利用できるので、後述のようなシステム仕様であれば1端末月額¥500で運用可能と思われます。
 ただ、今回作成・テストするプロトタイプシステムでは、IoT 通信に特化したデータ通信サービスを展開する SORACOM を試用してみることにしました。
 SORACOM を採用するメリットは主に2つあります。一つは少ないデータ量の通信では費用を低く抑えられること、もう一つは SORACOM API を通じてSIMを制御したり、通信状況を取得することができる点です。SORACOM の実際の使用感については後述します。

システム構成とプロトタイプ開発

 これまでの経緯より、モバイル端末には Android、モバイル通信には SORACOM を使用することに決めました。アプリケーションサーバ(App Server)とデータベースについては、前者を node.js + express.js、後者を FileMaker Server 16 としました。Google Maps API は アプリケーションサーバが Android から取得した位置情報をもとに住所情報を取得する際、またPC/タブレット等でAndroidの位置を Google Map 上に展開する際に使用します(図2参照)。
Android 端末によるデバイス位置管理システムの構成
図2 ― システム機能概要

ハイブリッドアプリとアプリケーションサーバの仕様と処理分担

 Android の GPS から経緯度情報を引き出すには、Android Studio 等でネイティブアプリを作成するか、HTML5/Cordova 等によりハイブリッドアプリを開発することになりますが、今回は iOS 等への対応も視野に入れ、ハイブリッドアプリを採用することにしました(上図の tpcgeo.apk、以下、tpcgeoアプリ)。tpcgeoアプリはアプリケーションサーバに経緯度情報を送信するだけの単純なモノです。Google Maps API を介した住所情報の取得やデータの加工、データベースの更新といった多くの処理は、アプリケーションサーバ上の tpcgeo_server.js と tpcsql.js(前回記事参照) が担います。
 Android 側にあまり仕事をさせないのは、通信量を抑えるというコスト上の理由と、外部で使用するモバイル端末から送信する情報の量は必要最低限にするというセキュリティ上の理由によります。

プロトタイプのテスト

 上記の仕様に従ってそれぞれのアプリケーションを作成し、Android とアプリケーションサーバに必要なアプリケーションやファイルをインストールした状態で、SORACOM SIM(SORACOM Air/Global plan01s)の導入を行いました。図2のように2つのサーバにも必要なシステムをインストールし、テスト開始です。

まず、データベースを起動し、次にアプリケーションサーバで node.js/express.js 上で動作する tpcgeo-servers.js をコマンドプロンプトから起動します。

アプリケーションサーバで tpcgeo-server.js を起動
図3 ― アプリケーションサーバのプロンプトで tpcgeo-server.js を起動

次に、Android 上で tpcgeoアプリ を起動し、位置情報を送信する回数(Requests)と送信間隔(Interval、ミリ秒で指定)を指定します。下図では、10秒間隔で20回、自身の位置情報を送信するように設定されています。“Start”をタップすると、位置情報のアプリケーションサーバへの送信が開始されます。

tpcgeo 実行画面 (Android)
図4 ― Android でハイブリッドアプリ=tpcgeo 実行画面

アプリケーションサーバ上の tpcgeo-server.js が Android から位置情報を受信すると、Google Maps API に位置情報を送り、その戻り値として住所情報を取得します。そして必要なデータ加工を行った後にデータベースへの書き込みを行います。これらの処理が成功すと、tpcgeo-server.js を実行するプロンプト画面には以下のような実行履歴が表示されます。

プロンプト画面に表示される tpcgeo-server.js の実行ログ
図5 ―  tpcgeo-server.js のプロンプト上に表示される実行履歴

 プロンプトに update[OK] が表示されている場合、FileMaker データベースの位置データ(下図のLatitude、Longitude、Altitude等、白地のフィールド)の更新が成功したことを意味します。
Tpc Geo 端末管理画面(FileMaker)
図6 ― 端末の位置情報等を表示する FileMaker アプリ
オレンジの部分は SORACOM API から取得する SIMの状態、課金情報等。 

 各端末の位置は、PC等のブラウザで Google Map 上に表示できます。

各端末の位置が Google Map 上に展開される
図7 Windows Edge で Google Map 上に表示した各端末
データベースから取得した各端末の位置情報に基づき、Google Maps API を介して地図上に端末をマッピング

 赤地のマーカ(端末名)をクリックすると、詳細がポップアップ表示されます。

ピンのクリックによって住所情報をポップアップ表示
端末の所在住所等詳細がポップアップ表示される


SORACOM Global について

 前述のように今回は通信にSORACOM社の提供する SORACOM Air/Global plan01s というサービスを利用しました。本サービスに必要な費用は SIM 1枚当たり、以下のとおりです(2017/12/30現在)。
  • 初期費用(SIM本体含む):US$5
  • 基本料金:US$1.8/30日
  • データ通信料:US$0.2/MB
ご覧のように初期費用が約500円と非常に低いため、本サービスは多くの IoT/M2M システムのテスト環境構築には適していると思われます。
 ただ、今回の Android ベースのプロトタイプ・システムに類似したシステムを“常時”稼働させようとすると、通信量が想像以上に発生し、月額¥500 の MVNO に比べると割高になると考えられます。
 その理由は Android OSとその付属アプリが予期しない多くの通信を行うからです。No root タイプの Firewall を導入して不要な通信を遮断・監視しようとしても、Firewall を回避して発生する通信が発生するため、これがかなりの量に及びます(なお、Android の Firewall については、NetGuard の開発者・M66B さんが BBS 上で参考になるレスを書いています)。
 
 では、常時稼働ではなく、限定的に稼働するようなシステムではどうでしょうか?たとえば、Android 端末が 1カ月の 80%は社内や倉庫内にあり、その間通信を必要としないケース、あるいは特定時間帯、特定期間にのみ通信を必要とするケース。これらのケースであれば、SORACOM のほうが割安となる可能性があります。というのは、SORACOM API を使用することにより、特定の時間、あるいは特定の条件下で SIM のサービスを停止させたり、一定の通信量を超過した場合は管理者にメールや SMS で通知を行うシステムを構築できるからです。


(亀)


IoT/M2M関連リンク

2017-11-14

FMクライアントからサーバ上のODBC/node.js経由でデータベースをCRUDする

 FileMaker(以下、FM)から FileMaker Server (以下、FMS)上のデータベースに接続し、SQLクエリでデータを CRUD する場合に考えられる方法は、通常は以下の2つです。

  1. FM クライアント機に ODBC を入れて、SQL を実行スクリプトステップを使用する
  2. FM クライアント機に ODBC は入れ、ODBCはサーバにのみ入れ、サーバサイドスクリプトで SQL を実行スクリプトステップを使用する

 1. のデメリットは、全てクライアントにODBCを入れる必要があり、保守が面倒なこと、
 2. のデメリットは、サーバサイドスクリプト内はデバッガが使用できず、またクライアントで実行する場合と動作が異なることがあること、です。
また、「\"」のエスケープが面倒で醜いというのは両者に共通した欠点と思います。

 さて、上記の2つの方法のデメリットを回避する方法として、サーバに ODBC/node.js と当方で開発した tpcsql.js を置き、FM クライアントから FMS に対して SQL を発行して CRUD する方法をご紹介します。

 以下で詳述のデータベースサーバ側でクエリ文を待ち受けする Node.js スクリプト tpcsql.js は、以下のページより無償ダウンロードいただけます。

tpcsql.js を使った CRUD テスト方法

以下、環境構築の方法を記します。

注:
  • cURLを使用するため、FileMakerクライアント は Ver.16 以降が必須となります。
  • FMSは Ver16 でのみ検証を行っています。  
  1. FMS 16 の Admin Console で ODBC/JDBC を有効にします。

  2. FM 付属の FileMaker ODBC ドライバを、サーバにインストールします。
    クライアントへのODBCのインストールは不要です。
  3. FMS サーバ環境に Node.js をインストールします。
  4. 上記のサイトより、tpcsql.js をダウンロードし、サーバ 上の任意の場所に配置します。
  5. tpcsql.js に付属の Readme.txt に従って、Node.js 関連パッケージ群をインストールします。
  6. コマンドプロンプト画面から、node tpcsql.js と入力し、Enter キーを押下します。
    以下のようなメッセージが画面に表示されたら、クエリ待ち受け状態となります。

    ここでは、Web サーバのデフォルトポート 80 で待ち受けしますが、すでに他の Web サーバが稼働中の場合は、tpcsql.js に記載されているポート番号を変更(例: 80→8080)し、再起動してください。
  7. 付属のサンプルファイル「TpcQueryTester10.fmp12」 をFMSに配置し、公開します。
    FMクライアントからアクセスできるように、必要に応じて、ファイヤウォールの設定を変更します。
  8. FMクライアントを起動し、上記7で公開したTpcQueryTester10.fmp12 を開きます。
    ログイン情報は tpcsql.js に付属のドキュメントを参照してください。
  9.  [URI]フィールドの hostname の部分を FMS16 のホスト名、または IP アドレスに変更し、“Go”ボタンを押してみてください。

    上記で、[odbcDriver]、[host]、[uid]、[pwd]、[database]フィールドは、FMS16 側から見た場合の設定をあらかじめ入力してありますので、そのまま “Go”で実行できます。
  10. 以下のようにクエリ結果が [result]フィールドに戻ってきたら成功です。
  11.  Data テーブルには 1000 件分のテストデータがあらかじめ登録されています。
    クエリ内容を変更することによって、CRUD 操作をお試しいただけます。
 本稿では データベースは FileMaker Server を使用していますが、MySQL や SQL Server など、ODBC対応であれば他のデータベースでもここに記載した方法は使用できると思います。

tpcsql.jsの他のプラットフォームでの利用

 当初、tpcsql.js は Raspberry Pi 等で iBeaconの情報を収集・加工し、リモートのデータベースをSQLで簡単にCRUDするという M2M な利用を意図して企画したのですが、「FMクライアントから使えたら便利かも?」と思い、公開することにしました。
 もともと、FMのサーバサイドで「SQLを実行」がサポートされているので、「?」な方もいらっしゃるかと思いますが、「役にたったよ」という方が現れたらウレシイです。
 尚、tpcsql.js のラズパイでの利用は、稿を改めてご紹介できればと思います。


(亀澤)

IoT/M2M関連リンク

2017-09-07

太古の FileMaker システムを延命させる! ― 後日談


 今年の4月に FileMaker Pro 5.5 を運用する Windows Server 2008 (32bit版、Remote Desktop Serviceを運用)をP2Vにより仮想マシン化するプロジェクトに関する記事を書きました。
 あれから4カ月、先月末、ようやく納品が終わりました。いろいろあってとっても苦労しました、トホホ… 以下、古いFileMakerシステムを仮想マシン化して Hypervisor 上で運用したい、という方の参考に多少ともなれば幸いです。

1. FileMaker Pro 5.5/6を仮想マシン上で運用する

今回、特に問題となったのは、仮想マシン上のFileMaker Pro 5.5/6(FMP)からFMSにアクセスしたときの操作が極端に遅くなること。今回、新マシン(下図のVM)と旧マシン(下図Win Server 2008)上の FMP から FileMaker Server 5.5(FMS)上の郵便番号.fp5(レコード12万件)に対しソートを実行し、この実行時間を遅速判断の1つの基準としました。




 12万件ソートの時間計測は、異なる5つのHypervisor機(Dell PowerEdge 2台、HP Proliant 1台、Lenovo X 2台)上に仮想マシンを作成し、様々なチューニングを試しながら繰り返し行いましたが、最速で20秒、最遅では2分強と、サーバ個体やNICの設定により結果が大きく異なったのには閉口しました。

 では、仮想マシン上の Remote Desktop Service に FMP を乗せ、FMSにアクセスするシナリオで、旧マシンに比べ仮想マシンが遅い場合の対処方法を小社の今回の経験からご紹介します。

※一つずつ試してください。
  1. 物理NICが Broadcom NetXtreme Gigabit Ethernet の場合、NICの詳細設定で Virtutal Machine Queues を Disable にするとともに、Hyper-V Manager の仮想マシンの「ネットワークアダプター」で「仮想マシンキューを有効にする」のチェックを解除。
  2. NICの詳細設定で、「TCP/UDP Checksum Offload (IPv4)」と、「TCP/UDP Checksum Offload (IPv6)」を Disable にする。
  3. Hyper-V Manager で、(普通のネットワークアダプターではなく)レガシネットワークアダプターを構成する。
  4. ネットでHyper-Vのチューニング情報を漁って試す(例:Performance Tuning for Hyper-V Servers)。
  5. そもそもロジックボード設計が Hyper-V に適していない→マシンを変える
 小社の今回の経験では、上記3が有力と思います。5の状況にならないようにするには、導入前にベンダーのSEに聞いてみるか、導入実績のあるサーバを導入するか、試用機を借りて事前テストする、位でしょうか。


2. FileMaker Server 5.5 を仮想マシン上で運用する

これについては、レガシネットワークアダプターよりも、普通のネットワークアダプタの方が有利(速い)というテスト結果です。

 同じ仮想マシンであるにもかかわらず、サーバとして利用するのと、クライアントで利用するのとで、採用すべき仮想NICの構成が異なるというのは不思議です。

(土屋)


■ FileMaker 5/6等レガシーシステム関連記事

まだまだいける FileMaker 5.5/6 ― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる! ― 後日談FileMaker(17/09/07投稿)
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる!(17/04/25投稿)
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う(16/05/25投稿)
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。

2017-06-27

FileMaker データベース認証に oAuth を利用する

 FileMaker 16 の新機能を使用して弊社在庫管理システムテンプレート『FMEasy在庫』の機能を拡張するというテーマで、前回までに WebDirect を使用した宅配便送状の印刷と、AfterShipから配送データを取得してアプリ内で荷物追跡情報を表示する方法をご紹介してまいりました。今回はその締めくくりとして、oAuth による FileMaker データベース(以下、FileMaker DB)へのログインについてご説明します。

 一回目:FileMaker と WebDirect 16 で宅配便送状を印刷し、配送状況を追跡する
 二回目:cURL と REST API を使用し、FileMaker アプリ内で配送状況を追跡

oAuth 認証で FileMaker にログインし、出庫画面から送状発行と追跡をする
出庫画面から運送業者の送状を発行し、配送状況を追跡するまでの流れ

 oAuth は一連のデータベース操作の窓口を担う認証機能になりますが、FileMaker DB にパスワードを記憶させないという利点があります。

オープン認証 (oAuth) をざっと説明

 oAuth を簡単に説明すると、外部の Web サービスに登録されているユーザ情報を使うことによって、アプリケーションに代理ログインできるしくみです。Google アカウントや Microsoft アカウントなどを使って外部サービスにログインされた方もいらっしゃると思います。

 FileMaker 16 が oAuth 対応になり、通常の FileMaker アカウントの代わりに Google、Microsoft Azure Active Directory、および Amazon アカウントを使って FileMaker データベース(以下、FileMaker DB)にログインできるようになりました。


oAuth 経由で FileMaker にログインするための事前準備

 oAuth で FileMaker DB にログインするためには、以下のものをそろえる必要があります。

  1. FileMaker Server 16 と必要数分のアクセスライセンス
  2. 有効なドメインのサーバ証明書
  3. クライアント ID、シークレット、テナント ID (Asure の場合)
  4. oAuth 用ログインユーザアカウント

FileMaker で oAuth を有効にする方法

 oAuth 経由で FileMaker にログインするための具体的な手順を以下に示します。
ここでは、Google アカウントを例に進めていくことにします。

 作業の手順は FileMaker 公式にまとめられていますので、以下もご参照ください。
 オープン認証 (OAuth) 資格情報を使用したソリューションへのアクセス

  1. FileMaker Server にサーバ証明書をインポートします。
    FileMaker Server Admin Console にログインし、データベースサーバ→セキュリティの順にすすみ、「データベース接続に SSL を使用する」にチェックをつけて“証明書のインポート...” ボタンをクリックします。

    カスタムサーバ証明書をインストールする
    SSL を有効にし、証明書のインポートを選択する


     証明書のインポートダイアログが表示されますので、署名入りの証明書ファイル、プライベートキーファイル、中間証明書ファイルを指定してインポートします。

    カスタム証明書インストール用ダイアログ
    カスタム証明書インポートのダイアログ
  2. FileMaker Server を再起動します。
  3. http://console.developers.google.com/ にログインします。
  4. 認証情報→認証情報を作成の順にすすみ、「oAuth クライアント ID」 を選択します。

    oAuth クライアント ID を登録
  5. oAuth 同意画面を選択し、メールアドレスとサービス名を入力して保存します。
    oAuth 同意画面を登録
    oAuth 同意画面を登録
  6.  アプリケーションの種類の選択ページでは、「ウェブアプリケーション」を選択し、任意の名前を指定してから、リダイレクト先を指定します。

    oAuth のリダイレクトリンク先を登録
    oAuth 認証をウェブアプリケーションにし、そのリダイレクト先を指定する

    リダイレクト先は https://ドメイン名/oauth/redirect になるように指定します。
  7. 無事 oAuth クライアント ID が作成されると、以下のようなダイアログが表示されますので、クライアント ID とクライアントシークレットをメモしておいてください。

    oAuth クライアント ID とクライアントシークレットをメモする
    oAuth クライアントのクライアント ID とクライアントシークレットを取得する
  8. 再び FileMaker Server Admin Console にログインします。データベースサーバ→セキュリティの順にすすみ、クライアント認証を 「FileMaker と外部サーバーアカウント」に変更して設定を保存します。
    クライアント認証を「FileMaker と外部サーバアカウント」に変更
    クライアント認証を「FileMakerと外部サーバーアカウント」に変更する
  9. 外部サーバーアカウントとして Google の歯車アイコンをクリックすると、Google の設定ダイアログが表示されますので、手順 7. でメモしておいた Google クライアント ID と Google クライアントシークレットを入力し、“保存”ボタンをクリックします。
    Google クライアント ID とシークレットを入力する
    Google クライアント ID と Google クライアントシークレットを入力
  10. FileMaker Server を再起動し、手順 11. の Google アカウントのスライダーを有効にします。

 これで FileMaker Server で oAuth が使えるようになりました。

補足事項:
  • サーバ証明書をインポートした直後は、FileMaker Server を再起動しても FileMaker Server が証明書を認識しない場合があります。その場合は、いったんサーバ機を再起動すると認識されることがあります。
  • サーバ証明書のインポートに失敗した場合は、FileMaker Server のディレクトリでコンソールウィンドウを開き、fmsadmin certificate delete コマンドを実行すると、カスタム証明書を削除することができます。削除後はいったん FileMaker Server を再起動してから、証明書のインポートをやりなおしてみてください。


FileMaker データベースファイルへのユーザアカウントの登録

 FileMaker Server 側の oAuth 認証受付の準備が終わったら、データベースファイルにログインユーザアカウントを登録します。

  1. FileMaker Pro から管理者権限でデータベースファイルを開き、FileMaker のメニューより「管理」→「セキュリティ」の順に進みます。
  2. アカウントの一覧が表示されますので、認証方法を「Google」にし、そして「ユーザ名」にはGoogleにログインするためのメールアドレスをフルで指定します。

    oAuth ログイン用アカウントを FileMaker DB に登録する
    アカウント管理画面に oAuth ログイン用のユーザアカウントを登録する
  3. 同じ要領で、クライアント数分のアカウントを登録します。
補足事項:
  • 分離モデルを採用している FileMaker データベースシステムの場合は、関連するすべてのファイルに oAuth 用のアカウントを登録する必要があります。


oAuth による FileMaker データベースのログイン

 oAuth による FileMaker ログインの設定が終わったら、実際にログインして動作を確認します。

FileMaker Pro16 によるログイン

 FileMaker Server 16 で公開されているデータベースファイルに FileMaker Pro 16 クライアントからアクセスすると、以下のようなダイアログが表示されます。

oAuth 対応の FileMaker Pro 16 ログインダイアログ
oAuth 対応のFileMaker Pro 16 ログイン画面
ここで、Google ボタンをクリックすると、以下のようなアカウント選択ページが表示されますので、適切なアカウントを選択し、パスワードを入力してログインします。

FileMaker DB にログインする Google アカウントを選択
ログインする Google アカウントを選択
上図は、Web ブラウザに Google アカウントが記録されている場合のページですが、Web ブラウザにアカウントが記録されていなければ Google ログイン用のメールアドレスを入力するよう促されますので、正しいメールアドレスを入力します。

 Google アカウントのログインに成功すると、以下のようなダイアログが表示されますので、“許可”をクリックします。

ブラウザから表示される FileMaker プログラムの実行許可を求めるダイアログ
プログラムの実行許可

 すると FileMakerアプリの画面に戻ります。後の操作は FileMaker のユーザ権限にしたがって通常通りに行えます。

oAuth による FileMaker ログイン直後の Main Menu 画面(FileMaker)
oAuth によるFileMaker ログイン直後の FMEasy在庫 Main Menu 画面

WebDirect によるログイン

 WebDirect 用の公開リンクにアクセスし、開きたいデータベースファイルをクリックすると、以下のようなログインページが表示されます。

oAuth 対応 WebDirect サインインページ
WebDirect 用の oAuth 対応サインインページ


 ここで、Google ボタンをクリックすると、以下のようなアカウント選択ページが表示されますので、適切なアカウントを選択し、パスワードを入力してログインします。

WebDirect にログインする Google アカウントを選択
ログインする Google アカウントを選択

 
 Google アカウントのログインに成功すると、WebDirect で FileMaker DBが開きます。


oAuth による FileMaker ログイン直後の Main Menu 画面(WebDirect)
oAuth による WebDirect ログイン直後の FMEasy在庫 Main Menu 画面

懸案事項

 oAuth は事前設定さえ済ませてしまえば、あとはログインを許可するアカウントを FileMaker DBに登録するだけで使えるようになりますが、運用にあたっては以下のような問題が発生する可能性がありますので、ご留意ください。
  1. ログインに成功すると、FileMaker を終了しても、oAuth で管理される外部 Web サービスのセッションが残る
    これは他の Web サービスのセッション管理機能に依存しますが、Google の場合 FileMaker を終了させても、二回目以降に FileMaker DB にログインしようとすると、パスワードの入力を求めてこず、そのままログインできてしまいます。
  2. Web ブラウザにログインパスワードが保存されていると、第三者に勝手にログインされる恐れがある
    個人の専用パソコンからのアクセスなら、パスワード入力の手間が省けて便利ですが、複数のユーザで一つのパソコンを共有利用している場合は、勝手にログインされてしまう可能性があります。
 各自パスワード管理をしっかりやってね、で解決すればよいのですが、手軽さゆえ思わぬトラブルにつながりそうな機能なので、oAuth ログインを許可するアカウントのユーザ権限は入力・照会レベルにとどめるような工夫は最低限必要かと思います。


 oAuth の危険性を指摘する記事もネットで見つかりますので、日ごろから目を通しておくとよいですね。


 参考記事:第147回 便利と危険は裏返し 〜 知っておきたい、OAuthの仕組み 〜 (TDK Techno Magazine)




 土屋企画では FileMaker システムの受託開発およびコンサルティングを請けたまわっております。お問い合わせはこちらよりお願い致します。

 その他の在庫関連記事を読む

(亀)




2017-06-26

cURL と REST API を使用し、FileMaker アプリ内で配送状況を追跡

 前回は在庫管理テンプレート『FMEasy在庫』をカスタマイズし、宅配便の送状を印刷・登録するところまでをご説明しました。

 前回の記事: FileMaker と WebDirect 16 で宅配便送状を印刷し、配送状況を追跡する
 参考:FMEasy在庫 IWP/WD R1.5


AfterShip による配送状況の追跡
出庫画面から運送業者の送状を発行し、配送状況を追跡するまでの流れ


 本稿では、出荷後の配送状況の追跡機能を実装する方法(上図の7.と8.)について説明していきます。
 機能の実装に入るまえに、FileMaker から出荷物の配送状況を取得するしくみについて触れます。

世界402社と日本3社の配送業者の追跡データAPIを提供する AfterShip

  FileMaker 単体では宅配便の配送状況の情報を取得することはできません。このため、各宅配業者が提供する追跡サービスを使用することになります。

 これまでは、データ受信の窓口となる API サービスを利用するためには宅配業者別に手続きが必要になり、API 接続手順の把握とシステムへの追跡機能の実装までに大変な手間と時間がかかってしまったのですが、AfterShip という荷物追跡サービスは世界 402 社の配送業者の追跡データ API を提供しており、その中に日本のヤマト運輸、佐川急便、日本郵便の 3 社も含まれています。

 AfterShip が対応している日本の宅配便会社(Japan を選択)

 つまり、AfterShip の API を利用すれば、これら 3 社の配送状況の追跡をまとめて処理でき、FileMaker の送状発行機能と連携させることによって、送状の印刷から荷物追跡までがトータルに行えるようになります。

AfterShip の利用料金について


 2017年6月26日現在、AfterShip は 1月あたり 100 個までの出荷物の追跡が無料となっています(Basic プラン)。
 100 個を超える荷物を追跡するには、その個数に応じた料金が適用される Premium プラン、10万個を超える場合は個別対応の Enterprise プランという料金が適用されます。

 価格プランはこちらを参照してください。
 https://www.aftership.com/pricing

 たとえば、一月あたり 10,000 個なら $173/月、50,000 個なら $573/月となりますので、出荷量に応じた追跡計画を立てることができます。


7. AfterShip に配送状況を問い合わせる


 AfterShip の API サービスを利用するまえに、AfterShip へのユーザ登録が必要になります。

 AfterShip ユーザ登録・ログインページ
 https://secure.aftership.com/signup/

 google アカウントをお持ちの方は、google アカウントでログインするだけで自動的に AfterShip に登録されます。

 FileMaker から AfterShip API を利用できるようにするには、さらに API Key の取得と配送業者の登録が必要になります。

  1. AfterShip API Key を取得する

    AfterShip へのユーザ登録が終わったら、設定ページから API の順に進み、API Key を取得します。 
     通常は登録完了時に自動的にデフォルトの API Key が付与されますのでそれを使えばよいですが、必要に応じて Key を追加生成することもできます。

    AfterShip API key の取得

  2. 追跡対象の配送業者(couriers)を登録する

    出荷物の追跡を行いたい配送業者を登録します。設定ページから couriers の順に進み、inactive 入力ボックスに japan と入力すると、日本の配送業者が表示されますので、その中から必要な業者を選びます。

     以下の図は、ヤマト運輸の選択まで終わったところです。

    配送業者(couriers)の登録ページでヤマト運輸の登録が終わったところ


 それでは、いよいよ FileMaker からAfterShip を呼び出すための設定をします。
 AfterShip API は REST 形式になっており、配送状況の追跡を行うためには基本的に以下の情報が必要となります。
  • AfterShip API への URI(https://api.aftership.com/v4/
  • 配送会社識別コード(slug)
  • 送状番号(tracking_number)
 配送会社識別コードと送り状番号は FileMaker のユーザインタフェースから登録できるようにしておき、AfterShip API からの応答データを登録するためのフィールド群も用意します。

 下図の赤で囲んだ部分をご覧ください。ポータルの 2 段目が AfterShip から取得する追跡データを保存するためのフィールド群です。荷物(送状)の追跡を行う場合は、当然[送状No]も必要になります。


 AfterShip API の公式ドキュメントはこちらです。

 AfterShip API Documentation
 https://www.aftership.com/docs/api/4/overview

 それでは、このドキュメントに従って、FileMaker から AfterShip API に接続してみましょう。

 AfterShip への送状番号の登録


 AfterShip 経由で荷物の配送状況を追跡するには、先に送状番号を AfterShip に登録しておく必要があります。

 登録用の URI は https://api.aftership.com/v4/trackings/ になります。
 この URI に送状情報を POST メソッドで送信すれば、AfterShip に登録されます。

 php で記述した場合、たとえばこのようになります。

PHP

<?php

    //build header 
    $header = array( 

        'Content-Type: application/json',
        'aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXX'

    ); 


    //build invoice data
    $data = Array(
        'tracking' => Array(
            'slug' => 'taqbin-jp',
                'tracking_number' => '44361185XXXX',
                'title' => 'YAMATO POST TEST'
        )
    );  

 
    //post data using curl
    $curl = curl_init();
    curl_setopt( $curl, CURLOPT_URL, 'https://api.aftership.com/v4/trackings' );
    curl_setopt( $curl, CURLOPT_CUSTOMREQUEST, 'POST' );
    curl_setopt( $curl, CURLOPT_HTTPHEADER, $header ); 
    curl_setopt( $curl, CURLOPT_POSTFIELDS, json_encode( $data ));
    curl_setopt( $curl, CURLOPT_SSL_VERIFYPEER, true );
    curl_setopt( $curl, CURLOPT_RETURNTRANSFER, true );
    $result = curl_exec( $curl );
    $json = json_decode( $result );
    curl_close( $curl ); 

?> 

 $header の中に json データ送信を宣言し、 aftership-api-key を指定します。
 $data の中に指定している slug がヤマト運輸を示す taqbin-jp、 tracking_number が送状番号、title が AfterShip の中で送状の識別を用意にする任意のタイトルになります。
 送信結果は最終的に $json 変数に格納されます。

 これを FileMaker の 「URL から挿入」ステップで記述すると、たとえばこのようになります。

FileMaker

変数を設定 [ $data; 値:
JSONSetElement ( "" ; 
        [ "tracking.tracking_number" ; "44361185XXXX" ; JSONString ];
        [ "tracking.slug" ; "taqbin-jp" ; JSONString ]; 
        [ "tracking.title" ; "YAMATO POST TEST" ; JSONString ] 
    )
 ]
URL から挿入 [ $json; "https://api.aftership.com/v4/trackings"; 
    cURL オプション: "-H \"Content-type: application/json\" " & 
        "-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" " & 
        "-d " & $data ] 
    [ ダイアログなし; SSL 証明書の検証 ]


 php に比べると指定方法に多少コツがいりますが、かなりシンプルになりますね。

 $data の中に送状情報を組み立てておき、これを「URL から挿入」ステップの cURL オプションの -d オプションの中に指定することによって送信します。

 cURL オプション:
 "-H \"Content-type: application/json\" --- ヘッダオプション。json 形式のデータ送信を宣言
 "-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" --- ヘッダオプション。aftership-api-key を指定
 "-d " & $data --- データオプション。$data に格納されているデータを送信

 送信結果は $json 変数に格納されますので、その中から必要項目を取り出せばよいことになります。

AfterShip API から戻される結果

 AfterShip API の戻り値は json 形式になります。前述の例では $json 変数に戻ってくるので、これを解析して利用します。
 データは一行で返りますので、これを FileMaker Pro 16 の JSONFormatElements 関数を通すと見やすいフォーマットに整形されますので、戻りデータを確認する際に有用です。

 JSONFormatElements( $json ) の結果はたとば以下のようになります。

JSON

{
 "data" : 
 {
  "tracking" : 
  {
   "active" : true,
   "android" : [],
   "checkpoints" : [],
   "created_at" : "2017-06-24T13:08:42+00:00",
   "custom_fields" : null,
   "customer_name" : null,
   "delivery_time" : 0,
   "destination_country_iso3" : null,
   "emails" : [],
   "expected_delivery" : null,
   "id" : "594e645ab6ee5fcf0b7XXXXX",
   "ios" : [],
   "last_updated_at" : "2017-06-24T13:08:42+00:00",
   "note" : null,
   "order_id" : null,
   "order_id_path" : null,
   "origin_country_iso3" : null,
   "shipment_delivery_date" : null,
   "shipment_package_count" : 0,
   "shipment_pickup_date" : null,
   "shipment_type" : null,
   "shipment_weight" : null,
   "shipment_weight_unit" : null,
   "signed_by" : null,
   "slug" : "taqbin-jp",
   "smses" : [],
   "source" : "api",
   "tag" : "Pending",
   "title" : "YAMATO POST TEST",
   "tracked_count" : 0,
   "tracking_account_number" : null,
   "tracking_destination_country" : null,
   "tracking_key" : null,
   "tracking_number" : "44361185XXXX",
   "tracking_postal_code" : null,
   "tracking_ship_date" : null,
   "unique_token" : "deprecated",
   "updated_at" : "2017-06-24T13:08:42+00:00"
  }
 },
 "meta" : 
 {
  "code" : 201
 }
}


 ここで、"meta" :{"code" : 201} が登録成功を示すシステムコードです。このコードが返れば AfterShip のブラウザ管理画面の追跡リスト上にこの送状データが表示されるようになります。
 また、このコードを拾って FileMaker テーブルのフィールド(下図の[ステータスコード])に登録したい場合は、以下のように関数を指定します。

 JSONGetElement ( $json ; "meta.code" )

 同じ要領でタイトルを下図の[aftershipタイトル]に登録する場合は、関数を以下のように指定します。

 JSONGetElement ( $json ; "tracking.title" )

 AfterShip への登録日時を下図の[ステータス]に登録するには、JSONGetElement ( $json ; "date.tracking.created_at" )と指定します。

AfterShip に送状情報を登録した直後の様子

 “登録”ボタンにより AfterShip に送状を登録した後に、ブラウザでAfterShipの送状管理画面を見ると、下図のようになっています。

AfterShip に登録された送状の一覧

8. 配送状況の問い合わせ結果を FileMaker に登録する

 AfterShip に配送状況を照会する


 AfterShip に荷物を登録後、配送状況を追跡するための URI は https://api.aftership.com/v4/trackings/配送業者コード(slug)/送状番号(tracking_number) になります。
 この URI に???送状情報を GET メソッドで送信すれば、AfterShip から配送状況が JSON 形式のデータで戻されます。

 AfterShip への配送状況の問い合わせを FileMaker の 「URL から挿入」ステップで記述すると、たとえばこのようになります。

FileMaker

URL から挿入 [ $json; "https://api.aftership.com/v4/trackings/" & 
    "taqbin-jp" & "/" & 
    "44361185XXXX"; 
cURL オプション: "-H \"Content-Type : application/json\" " & 
    "-H \"aftership-api-key: cfa68bc1-5b9b-4ba2-b3c8-XXXXXXXXXXX\" & "\" " ] 
[ ダイアログなし; SSL 証明書の検証 ]


 登録のときより照会の方が単純ですね。
 これによって $json 変数に配送状況の照会データが戻ります。
 照会に成功すると、 "meta" :{"code" : 200} が返ります。
 オプション解説、およびデータの読み出し方法の基本については、前述の登録方法の項をご覧ください。


 なお、最終の配送状況のみを戻したい場合は、 URI を https://api.aftership.com/v4/last_checkpoint/配送業者コード(slug)/送状番号(tracking_number)  にすればよいです。


 下図は各送状の“照会”ボタンを実行し、[ステータス](一般ユーザ向けに配送状況を表示)と[ステータスコード](システム管理者向けにシステムコードを表示)の更新が完了したときの画面です。

送状情報を AfterShip に問い合わせたときの様子

  上図では最終ステータスのみを記録するように作成していますが、機会があれば[追跡履歴]の取り出し方も説明できればと思います。


外部サービスを使うデメリットについて

 FileMaker 単体でできないことは外部サービスの力を借りることになりますが、導入時は魅力的に見えたサービスであっても、継続運用していくうちに様々な問題に直面することがあります。
そこで最後に外部サービスを利用する際の注意点をいくつか挙げておきます。
 
  1. バージョンアップに伴い、従来の呼び出し方法では動作しなくなる
    FileMaker と外部サービスとの連携が取れなくなる恐れがあります。
    外部サービスを導入する場合は、こまめなチューニングも考慮する必要があります。
  2. 無料サービスが有料化される
    そのサービスなしでは業務が回らない場合に、予期せぬコスト増大を招く恐れがあります。
  3. 良心的に見えた料金が値上がりする
    サービス提供側が料金を値上げするのはよくあることです。その場合、上記と同様にコスト増大が発生します。
  4. 社外秘のデータが外部に把握される
    サービスの内容にもよりますが、たとえばアンケート収集・解析サービスや、SNSサービス、翻訳サービスなど、社内用のデータを外部サービスと連携させて利用する必要がある場合、機密情報を外部サービスに流さないように注意を払うことはもちろんのこと、サービス提供会社の安全性やセキュリティ対策なども調査する必要があります。
  5. 終了する
    有料、無料にかかわらず、サービス提供側の事情でサービスが終了すると、そのサービスがシステムにとって重要なポジションを占める場合には、代替サービスの選定やシステム修正等の手間が増えることになります。


  FileMaker 16 の機能追加によって、外部 Web サービスとの親和性が向上しましたが、本格的にサービスを導入をするには、上記のような問題を視野に入れたうえでプロジェクトを設ける必要がありますので、発注側、受注側双方の理解が重要かと思います。


(亀)



 土屋企画では FileMaker システムの受託開発およびコンサルティングを請けたまわっております。お問い合わせはこちらよりお願い致します。



 

FileMaker と WebDirect 16 で宅配便送状を印刷し、配送状況を追跡する

 FileMaker 16 では cURL、JSON、oAuth などの Web 関連機能が多数搭載されました。これらを使用すると、ネット時代に適応した多様なソリューション開発ができそうです。

 そこで本稿では、弊社在庫管理テンプレート『FMEasy在庫』を使い、出庫画面に宅配便の送状発行機能と、出荷後に荷物を追跡する機能を追加する方法を考えてみます。


 参考:FMEasy在庫 IWP/WD R1.5


注:
 本稿は『FMEasy在庫』のユーザでない方でも、宅配送状の設計やWebDirect 16 によるPDF出力の方法、cURL/JSONを使用した荷物追跡機能の実装に関しては参考にはなるかと思います。


 処理の流れはざっと下図のようになります。本稿では2.~6.について説明致します。


出庫画面から運送業者の送状を発行し、配送状況を追跡するまでの流れ

1. oAuth による認証

 上図の冒頭部分のoAuth による認証については、別稿にてご案内したいと思います。

2. 出庫登録をする

 出庫登録は『FMEasy在庫』テンプレートにあらかじめ搭載されている機能のため、ここでは説明を省略します。
 『FMEasy在庫』は基本機能は無償でご使用いただけますので、出庫機能をお試しになりたい方はこちらからダウンロードしてください。

3.送状を登録する

 出庫(売上)伝票の作成後に物品を発送するための宅配便送状を登録するためのインタフェースを用意します。

 まず送状データを管理するための送状テーブルを新設し、リレーションシップ画面で出庫テーブルと送状テーブルをリレートします。詳細は省略しますが、1件の出庫データについて複数の宅配便送状を登録するように設計すると、複数個口に対応できるようになります。
 既存の出庫レイアウトにタブオブジェクトを配置し、出庫タブに出庫明細関連フィールド、送状タブに送状関連フィールドを配置します(下図参照)。

1出庫伝票に対して複数の宅配便送状を登録できるように設計しましょう 

 ポータルの上段には宅配送状とその印刷に必要なフィールドが、下段には荷物追跡に必要なフィールドが配置してあります。送状テーブルの設計時に参考にしてください。
 下段の荷物追跡関連フィールドには、外部 Web サービス(AfterShip)に配送状況を問い合わせ、その結果を自動入力します。この追跡機能については、別稿にて詳細を説明します。

 『FMEasy 在庫』をご利用のお客様へ 


 『FMEasy 在庫』を FileMaker 16 の WebDirect で開くと、下図のようにボタンの欠けが発生することがあります。

『FMEasy 在庫』の出庫画面を WebDirect 16 で表示すると一部のボタンが欠ける

 これは FileMaker WebDirect の上位互換性によって生じる問題のため、お客様の方でFileMaker Pro 16 を使ってボタン幅を調整してください。
 

4.WebDirect から PDF 出力できるようにする

 宅配便の送状フォーマットに準じたレイアウトを用意してておき、“印刷”ボタンをクリックして送状を出力します。 複数の宅配便や代引等に対応するとき場合は、その分だけレイアウトを用意し、スクリプト実行時に適切なレイアウトを選択します。
 FileMaker 16 の WebDirect は PDF 出力対応になりましたので、ここでは送状の“印刷”ボタン実行時に送状を PDF 出力するようにスクリプトを組んでみます。

 FileMakerクライアント情報は Get ( アプリケーションバージョン ) 関数を使うことによって取得できます。
 クライアントが WebDirect の場合は、Web Publishing Engine を含む文字列が返ります。WebDirect からのアクセス時に「レコードを PDF として保存」ステップを実行するようにします。 下図で赤く囲んだ部分が WebDirect アクセス時の PDF 出力関連部となりますので、参考にしてみてください。

「送状印刷Btn」スクリプト(赤囲み部分が WebDirect 向け PDF 出力ステップ部分)

注:
少し調べてみたのですが、iOS(iPad/iPhone)に対応した水平プリンタは存在しないようです。

5.送状を水平プリンタで印刷する

 前述の「送状印刷Btn」スクリプトでは、FileMaker Pro クライアント使用時には印字データが直接プリンタへ送られますが、WebDirect 使用時には サーバ上で送状のPDFが作成され、そのPDFファイルを開いて印刷することになります。

WebDirect では PDF のダウンロードとPDFの処理方法をユーザが選択する必要があるので、少し面倒

6.送状番号のバーコードを読み取って登録する

 宅配便の送状を印字したら、バーコードリーダーや iPhone などのバーコードスキャン機能を使い、送状に記載されている送状番号のバーコードを「送状タブ」上の[送状No]フィールドに登録できます。バーコードを読み取るか、手入力により[送状No]に登録すると下図のようになります。

送状のバーコードをスキャナで読み取り、[送状No]フィールドに入力したところ


 次回は、出荷後の荷物の追跡を FileMaker で行う方法についてご紹介します。




 ※土屋企画では FileMaker によるシステムの受託開発およびコンサルティング業務を請けたまわっております。業務関連のご質問はこちらよりお寄せ願います。


(亀)

2017-06-14

FileMaker WebDirect 16 のロードバランス

 前回は FileMaker Server 16 の WebDirect (WebDirect 16)の構成をマスタサーバ 1 台構成にした場合と、ワーカマシン 5 台構成にした場合とで、スレッド数(接続数)や Ramp-up(全スレッドを生成するまでの時間)の条件を変更しながらパフォーマンス計測を行いました。 
 本稿では ワーカマシン 5 台構成で WebDirect 16 のロードバランスがどのように機能するのかを見てみます。
【ワーカマシン5台構成のイメージ】

サーバ 5 台構成時 のロードバランス

 複数のワーカマシンで構成される WebDirect 16 は Webクライアント(ブラウザ)からリクエストを受信すると、より負荷の低いマシンにそのリクエストを割り当てます(ロードバランス)。
 下図は異なる 5 台のクライアント PC のブラウザから WebDirect にログインしたところですが、より負荷の低いワーカマシンにリクエストが割り振られていることがわかります。
FileMaker Server 16 Admin Console のステータス画面
 上図のような低負荷の状態では WebDirect のロードバランスが適正に機能していることが確認できます。ちなみに、ワーカマシン 1 は Webサーバ機能の他に、データベースサーバ機能とロードバランスの機能も担うため、他のワーカマシンの負荷が相当程度高くなるまでの間、自身では HTTPリクエストを処理しないようです。
 次に、WebDirect の負荷を増減させるとどうなるのか、Apache JMeter を使ってテストしてみました(下図)。

【表1】
No ワーカ数 スレッド ループ Ramp
(秒)
 
リクエスト/秒 所要時間(秒) 失敗数 1Recの平均作成時間(秒) 備考
1 5 500 1 0.5 1000 46 128 0.092  1回計測
2 5 500 1 2 250 58.5 1.5 0.117  2回計測
3 5 500 1 5 100 60 0 0.120  1回計測
4 5 500 1 7 71.4 49 0 0.098  1回計測
5 5 500 1 30 16.7 48 0 0.096  5回計測
6 5 500 1 40 12.5 48 0 0.096  5回計測
7 5 500 1 60 8.3 60 0 0.120  1回計測
8 5 500 1 90 5.6 92 0 0.184  1回計測

 本テストは 500 スレッド(≒500ユーザ)から 、出庫伝票(出庫ヘッダレコード1と出庫明細レコード1)を作成する FileMaker スクリプトを実行し、最初のリクエスト発行から 500 件目の出庫伝票の作成が完了するまでの[所要時間(秒)]を計測しています。Ramp は 500 スレッドを生成する時間です。
 たとえば、テスト No.1 では 500 のスレッドを 0.5 秒の間に作成し、最後のレコードが作成し終わるまでの[所要時間(秒)]が 46 秒であったことを示しています。[失敗数]は本来 500 件の出庫伝票が作成されるべきところ作成に失敗した件数を示しており、No.1 では 128 件の失敗(伝票未作成)が発生しました。下図は No.1 実行時のワーカ割り振りの状態です。


Ramp が 0.5 では接続がワーカマシン 1 に極端に集中してしまう

 0.5 秒間に 500 スレッドが発生する高負荷状態ではワーカマシン 2 に割り振りが集中し、ロードバランスが適正に機能せず、128件のレコード作成処理が失敗しています。

 次にテスト No.4 ( Ramp:7秒)のロードバランスを見てみましょう(下図)。ワーカマシン 3、5 への割り振りが大分多いですが、ワーカ 2、4 にも 80 程度のスレッドが割り振られています。
 
500 同時接続で Ramp 7 秒 のときのサーバ割り当ての様子

 下図は Ramp を 60 秒にしたときの割り振り状態です。ワーカマシン 2~4 にはほぼ均等にスレッドが割り振られていて、ワーカマシン 1 (マスタ)は若干少なめに割り振られています。

500 同時接続で Ramp 60 秒 のときのサーバ割り当ての様子

  以上のように、WebDirect 16 は短い時間に極端にアクセスが集中すると、ロードバランスが適に機能しない可能性があります。アクセスの間隔が長くなるに従い、HTTP リクエストが各ワーカマシンに均等に割り振られるようになると思われます。

エラーが発生しない適正なリクエスト頻度

 下図は表1 をグラフ化したものです。Ramp が 2 秒迄だとエラーが発生しますが、Rampが 5 秒になると全 500 スレッドがエラー無く終了します。500 スレッド÷ 5 秒で 100 スレッド/秒、つまり1秒間に 100 のリクエストであればエラーが発生しません。
 ただ、所要時間は 60 秒なので、この結果を実運用に適用できると仮定すると、ユーザがリクエストを発行してから 60 秒程度、待たされることになります。Ramp が 60 秒、つまり 1 秒に 10 弱のリクエストの場合は、ユーザの待ち時間が数値上はほぼ無くなります。1 秒あたり 10~100 リクエスト程度の範囲に、安定運用可能なリクエスト頻度の目安があるのかもしれません。



マスタ1台構成 vs ワーカ5台構成

 最後に、下図は500スレッドの処理を完了するまでの時間を、1 サーバ構成と 5 ワーカマシン構成でパフォーマンスを比較した折れ線グラフです。折れ線の左の部分は、7 秒間に 500 のスレッドからのリクエストを処理する場合、1 サーバ構成の方が 5 ワーカ構成より有利であることを示しています。
 本テストは 7 秒~90 秒という短い時間内で終了してしまうテストなので、より長い時間、継続的に負荷がかかるようなケースには当てはまらないかもしれませんが、ワーカを増やせば実行速度も増す、と単純に想定することはできないことを示していると思います。



(亀)