2019-04-02

WiFi APによる中継と、複数Raspberry Piと複数APの登録・接続

 屋内位置情報システム(IPS)を構築する際には、ビーコン信号を Raspberry Pi (以下、RP と呼ぶことがあります)などのワイヤレスの受信機で受信し、さらにそこから WiFi を介してサーバに送るといった状況が発生します。
受信機と有線LAN間を結ぶのモノが WiFiアクセスポイント(以下、AP と呼ぶことがあります)です。
 APは通常、LANケーブルにより有線ハブに接続されていますが、LANケーブルの引き回しが困難なこともあります。その場合、親機のAPのみをLANケーブルで有線ハブに接続し、子機APは親機APへの中継器として使用します。

 今回、中国TP-LINK社の TL-WR802N(写真)を使用し、どのように中継器を構成ができるのかテストしてみました。ちなみに、この製品の電力要件は 5V/1A で、Micro USBケーブルを介してモバイルバッテリと接続して稼働するため、LANケーブルの敷設と電源供給が難しい屋外でのテストで威力を発揮します。
 あるAP と RP 等のデバイスの間隔が離れすぎてしまいAPがデバイスのWiFi信号を十分な強度で拾えないような場合、他のAPを中継器として使用します。
屋外でのIPSテスト。Raspberry Pi (RP) と TL-WR802N、共にモバイルバッテリだけで1日は十分稼働する。

 また、本稿の後半では、多数の RPと AP を効率的に登録及び切り替えする方法について考えます。

WiFi の中継タイプ

 TL-WR802N は以下のいずれの中継タイプであっても、子機AP2~4を経由して親機AP1に接続することができました。ただ、設定時にはブラウザから接続できなくなったりすることも多く、モードを変更するとそれまで行った設定が飛んだりで、癖がある製品であるように思いました。
 尚、上の写真のように障害物の無い環境では、AP間は70m程度の距離があっても電波を送受信できました。未検証ですが、下表の直列型にすれば70m×5で350mはWiFi通信できるものと推定されます。

WiFi中継タイプ イメージ
直列型
スター型
折衷型
注:通常、AP1 は有線ハブに接続され、RPを社内LANに接続する。

NetworkManager の nmcli による WiFi接続と管理

 小社では Raspberry Pi のネットワークインタフェース設定には NetworkManager を採用したため、ここでは NetworkManager による WiFiアクセスポイント(AP)接続の登録方法と切替方法についてご紹介します。
 ※屋内位置情報システム(IPS)で RP などの受信機と APを多数運用する場合、一括管理できる仕組みも併せて考慮する必要が出てきます。

Wifi 接続の登録方法

 NetworkManager を使って WiFi AP (SSID) を登録する方法は以下の 3 とおりがあります。 尚、以下、AP と SSID はほぼ同義に使用されていることがあります。

  1. GNOME を使う(GUI)

     GNOME が利用できる環境では、GUI によりAP(SSID)を設定できます。NetworkManager インストール時に GNOME をインストールしなかった場合は、以下のコマンドを実行することにより、GNOME をインストールします。
    sudo apt-get install network-manager-gnome
    コマンド実行後に Raspberry Pi を再起動すると、画面上部に以下のアイコンが表示されるようになります。

     新規に接続を作成する場合は、上記の NetworkManager アイコンをクリックします。現在の接続状態と、利用可能な AP の一覧が表示されますので、その中から接続したい AP を選択します。

     たとえば、tpctp1 に接続したい場合は、以下のように選択します。
     利用可能一覧に AP が表示されていない場合は、その他のネットワークを選択すると、さらに接続可能な AP が表示されますので、そのなかから選んで接続します。


     この要領で接続をすると、多くの場合は AP の DHCP 機能により IP が割り振られることになります。
     固定 IP を振り直したい場合は、NetworkManager アイコンを右クリックし、「接続を編集する...」メニュー項目を選ぶと、登録済の接続情報の一覧が表示されますので、そのなかから変更対象の接続を編集します。


  2. nmcli コマンドを使う

     GNOME を使用しない場合は、nmcli コマンドで接続管理ができます。
     基本的には以下のシナリオで作業を行います。

    1. 既存の AP に接続要求

      以下のコマンドを実行することにより、任意の AP に接続
      nmcli d wifi connect SSID password PASSWORD
      (赤字部分が指定したい SSID とパスワード)
      上記の指定情報をもとに接続が試行されます。接続に成功すると接続設定ファイルが /etc/NetworkManager/system-connections/ ディレクトリ配下に作成されます。
    2. 上記で作成された接続ファイルに固定 IP アドレス、および DNS サーバの IP アドレスを設定

      以下のコマンドを実行することにより、1. で作成された接続設定ファイルに固定 IP アドレスと DNS サーバの固定 IP アドレスが登録されます。
      nmcli connection mod SSID 802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.psk PASSWORD ipv4.method manual ipv4.addresses "192.168.3.10/24" ipv4.gateway "192.168.3.1" ipv4.dns "192.168.3.100"
      赤字部分が編集対象となる SSID とそのパスワード )
      ここでは、固定IP アドレスとして 192.168.3.10、デフォルトゲートウェイが 192.168.3.1、DNS サーバが 192.168.3.100 であることを想定しています。
    3. 再接続による変更内容の反映

      接続設定ファイルを書き換えが終わったら、一度接続を停止し、再度接続することにより、変更内容を反映させます。
      nmcli connection down SSID
      nmcli connection up SSID

  3. シェルスクリプトで一括登録する

    使用する Raspberri Pi(RP) 端末と WiFiアクセスポイント(AP) の台数が少数であれば、GNOME で簡単に設定を行えますが、その数が数十台になると GNOME で一台一台、設定および管理するのは時間的、労力的に厳しくなります。

     そこで前述の nmcli コマンドにより、自動接続および接続ファイル生成を繰り返し、複数の Raspberry Pi に複数の AP を登録するシェルスクリプトを作成して実行するようにします。

    以下のシナリオで作業を行います。

    1. 事前に登録対象の SSID と パスワードを格納した設定用のファイルを準備

      ここでは、タブ区切りで SSID およびパスワードの組み合わせを記述したファイル(ssid.txt)を用意します。
      たとえば、このように記述します。
      ssid.txt
      tpctp1    111111
      tpctp2    222222
      tpctp3    333333
      

    2. 一括 SSID 登録シェルスクリプト (tpccon.sh) を準備

      事前に、引数として渡す Raspberry Pi の固定 IP アドレス、デフォルトゲートウェイ、DNS サーバの IP アドレスを記述しておきます。
      以下の 4~6 行目の ip、gateway、dns 変数の内容を任意のものに書き換えます。

      tpccon.sh
      #!/bin/sh
      
      ip="192.168.3.10"
      gateway="192.168.3.1"
      dns="192.168.3.100"
      
      sh delcon.sh
      sh _subcon.sh $ip $gateway $dns

    3. 既存の接続ファイルを削除するためのシェルスクリプト(delcon.sh)

      すでに登録済の接続ファイルが存在する場合、接続コマンドを実行する度に、「MySSID 1」、「MySSID 2」、「MySSID 3」のような同じ SSID に番号が付番されたファイルが生成されてしまいます。

      このため、後々の接続管理を容易にするために、事前に既存の接続ファイルを削除するためのシェルスクリプト(delcon.sh)を用意します。
      前述の ssid.txt ファイルに登録されている SSID を順に読み込み、その名前がついている接続を削除します。

      delcon.sh
      #!/bin/sh
      
      # delete access point files
      
      DATA=`cat ssid.txt`
      
      while read line
      do
          ssid=${line% *}
          sudo nmcli connection delete $ssid
          sudo nmcli connection delete "$ssid 1"
          sudo nmcli connection delete "$ssid 2"
          sudo nmcli connection delete "$ssid 3"
          sudo nmcli connection delete "$ssid 4"
          sudo nmcli connection delete "$ssid 5"
      done << FILE
      $DATA
      FILE

      このサンプルスクリプトでは、1~5 までの冗長な接続ファイルが存在する可能性を考慮して固定で 5 まで強制的に削除するようにしています。存在している接続ファイルの一覧を取得して、それらを全て削除するようにすると良いのですが、今回は手抜きをしました。

    4. SSID を自動登録するためのシェルスクリプト(_subcon.sh)

      1. の ssid.txt に指定されている情報を順に読み出し、SSID を登録するシェルスクリプト(_subcon.sh)を作成します。
      このシェルスクリプトは呼び出し元の tpccon.sh の引数を取るため、サブスクリプトとして動作します。このため、便宜的に先頭にアンダスコアを入れてあります。

      _subcon.sh
      
      #!/bin/sh
      
      ip=$1
      gateway=$2
      dns=$3
      
      # version
      ver=`sudo NetworkManager -V | cut -c 1`
      
      # create available access point files
      sudo nmcli d wifi rescan
      
      DATA=`cat ssid.txt`
      
      while read line
      do
          ssid=${line% *}
          pwd=${line#* }
          sudo nmcli d wifi connect $ssid password $pwd
      
      
          if [ $ver -lt 1 ]; then
              sudo nmcli connection mod $ssid 802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.psk $pwd ipv4.method manual ipv4.addresses "$ip/24 $gateway" ipv4.dns "$dns"
          else
              sudo nmcli connection mod $ssid 802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.psk $pwd ipv4.method manual ipv4.addresses "$ip/24" ipv4.gateway "$gateway" ipv4.dns "$dns"
      
          fi
      
          #reload and activate the connection
          sudo nmcli connection down id $ssid
          sudo nmcli connection up id $ssid
      
      done << FILE
      $DATA
      FILE
      

      これで一括 SSID 登録シェルスクリプトの準備が整いました。

    5. 一括 SSID 登録シェルスクリプト (tpccon.sh) を実行

      tpccon.sh を実行することにより、既存接続の削除→接続登録の順で全自動で処理が実行されます。
      sh tpccon.sh
      上記を実行すると、1. で定義した ssid.txt の一番最後に登録されている AP(SSID)に接続されます。
    6. TeraTermによる一括登録
      端末一台を設定するのであれば、ターミナル上で上記のコマンドを実行します。複数台の端末に対し同時に AP 登録したい場合は、TeraTerm などの一括コマンド発行ができるツールを使用して tpccon.sh を実行します。
    7. 登録状況の確認

      登録済みの接続と接続状態を知るには以下のコマンドを実行します。
      nmcli d wifi list

    8. なお、接続ファイルの実体は、/etc/NetworkManager/system-conntections ディレクトリ配下にあります。 以下のように、/etc/NetworkManager/system-conntections に tpctp1、tpctp2、tpctp3 の接続ファイルが正しく作成されていることが確認できます。

      【重要】
      使用する OS のバージョンにより、インストールされる NetworkManager のバージョンが異なることがあり、またこのバージョンの相違によって指定方法も異なるという問題があります。
      このため、一様のコマンド実行では、端末によっては設定ファイルの書き換えができないというトラブルが発生する可能性があります。

      現時点で当方が把握している情報としては以下のものがあります。

      バージョン 0.9.10.0 --- ipv4.addresses オプションに IP アドレスとゲートウェイアドレスをセットにして記述する必要あり
      バージョン 1.6.2.0 --- ipv4.addresses オプションに IP アドレス、 ipv4.gateway オプションにデフォルトゲートウェイアドレスを個別に指定する必要あり

      このため、上記のスクリプトでは、バージョンの番号別にオプション設定が切り替わるように記述してありますので、現時点では NetworkManager のバージョンが混在する環境でも動作するようになっています(今後さらにコマンド仕様が変更される可能性があります)。

Raspberry Pi の接続 

起動時の接続

 電源を投入すると、前回のシャットダウンまで接続されていた AP に接続されます。
このとき、そのAP への接続に失敗すると、NetworkManager によって他の登録済みの AP に自動接続されます。

接続先の変更

 Raspberry Pi 端末の接続先を変更したい場合は nmcli connection up コマンドを使用します。
nmcli connection up tpctp1

 複数の Raspberry Pi の AP(SSID) を一括して変更するには、TeraTerm などの接続ツールを使って複数の Raspberry Pi にログインし、以下のブロードキャスト(一括)コマンドを発行すると良いと思います。
 以下は、接続済みの端末に向けて tpctp2 という接続名の AP に一括接続切替をするためのコマンドです。
sudo nmcli connection up tpctp2
 ※ TeraTerm などのツールを使って接続切替要求を発行する場合は、sudo を付ける必要があります。TeraTerm では接続済みの端末のうちいくつかを選択(限定)して、ブロードキャストコマンドを実行することもできます。

検討課題

 iPhone では WiFi AP 毎に『自動接続』をOFFできますが、これに相当する nmcli コマンドが見当たりません。テストを行っている場合等、特定の AP のみに接続を限定したいことがあると思うのですが...。connection down というコマンドがありますが、これはAP への接続を停するだけで、iPhoneで言うところの「『自動接続』をOFF」にはならないため、電波状況によっては接続が復活してきてしまう模様です。

(亀)




2018-08-31

FileMaker Server の運用をオンプレミス、AWS、FileMaker Cloud で比較してみる

[本文へ移動]

コロナ蔓延により 優位性増すクラウド

本稿は2018年8月の記事で、クラウドとオンプレミスを項目別に評価(下表参照)しています。
 同表内のBCPの項ではクラウド(AWS/FMC)が優位にありますが、昨年の台風19号や今回のコロナの蔓延により、各企業・団体でのBCPの"重み"は急激に増しています。インフラ構築とその運用をすべてリモートで行えるAWS等のクラウドは、テレワーク/在宅勤務の観点からも優位です。

 土屋企画では、FileMakerシステムの移行を含むAWSインフラ及びテレワークシステムの構築を支援・実施致します。

参考リンク(土屋企画のWebサイト):
■AWSとテレワーク
■リモート開発とテレワーク
■Amazon connect と FileMaker WebDirect による CIT の無料試用サービスについて
(2020年5月1日加筆)

ローカル → EC2  vs  ローカル→Workspaces→EC2
 ~ FileMakerクライアントの実行速度を比べる ~

「FileMaker Cloud やAWS EC2 の FileMaker Server が遅い!」と感じていませんか? Amazon EC2 上の FileMaker Serverに、3つのクライアント(ローカルPC直接続、WorkSpace 1、WorkSpace 2)からアクセスし、データベースのソート速度を比較してみました。


(2020年5月14日加筆)

Amazon Connect と FileMaker WebDirect 19 による CTI


 Amazon Connect と FileMaker WebDirect 19 を連携させ、 CTI(Computer Telephony Integration) の主要機能の1つである「着信時顧客情報ポップアップ」を実現する事例をご紹介します。



(2020年6月15日加筆)

(以下、本文)
2017年7 月の FileMaker Cloud リリース以来、FileMaker Server のクラウド環境での運用も増えているようです。これにより企業では FileMaker Server 導入時に、オンプレミス(自社サーバ)、AWS EC2(Amazon社が提供するクラウドサービスで、ユーザは 自身で適切な Windows OS を選択て、FileMaker Server のインストールを行う)、FileMaker Cloud(FileMaker 社が Amazon マーケットプレースで提供する AWS EC2上で稼働する  FileMaker Server プラットフォーム)の 3 つのプラットフォームから選択することになります。

 ユーザはこれら3つのサービスでどれが自社に最適なのか悩むところですが、結論的なことを先に言ってしまうと、システム担当者がいない会社では FileMaker Cloud がお勧めです。FileMaker社が提供するチュートリアルに沿って設定を行えば、通常は数十分で FileMaker Server の準備が完了します。従来からある素の AWS EC2 に比べると、FileMaker Cloud は簡単です。

 オンプレミスかクラウドかはほとんどの場合、企業・組織がもつサーバポリシーによりほぼ自動的に決まってしまうかと思われます。データの秘匿性、セキュリティを重視する会社ではクラウド自身を禁止しているところもありますし、基幹システムはオンプレミスで、その他はクラウドに出すところ、IT部門の人員を削減するためサーバは全てクラウドにするところもあります。逆にサーバの仮想化をすすめ自社のサーバ室ですべてを運用することによりコストダウンを図る会社もあります(当社はこの形態に近いです)。

 本稿では、オンプレミス、AWS EC2、FileMaker Cloud の3つのプラットフォームを機能面と費用面から比較しています。機能については項目別に点数をつけていますが、企業・組織により各項目の重みは大きく異なるので、点数は参考値としてご覧ください。

 なお、3者とも FileMaker Server 17 の年間ライセンスを 25 使用することを前提としています。また、FileMaker Cloud はラインセンスのクラウドへの持ち込み(Bring Your Own License: BYOL)を前提としています。

 始めに機能・運用環境を比較してみます。FileMaker 社の公式ページ FileMaker ServerとFileMaker Cloudの比較 をベースに、さらに検討が必要と思われる項目を追加し、オンプレミス、AWS EC2、FileMaker Cloud 別に点数をつけてみました。

表1. オンプレミス、Amazos Web Service、FileMaker Cloud の機能・運用環境比較
No 比較項目 オンプレミス
(OP)
AWS EC2
(AWS)
FileMaker Cloud
(FMC)
説明
1 初期費用(ハード/ソフト) 1 5 5 表2参照
2  運用費用(ハード/ソフト)
4
3
2
表2及び表3参照
3  ハードウェア導入時の手間
2
4
4
OP:ハードウェア/UPS/バックアップ機器等の選定と購入が面倒
AWS:インスタンスタイプの選定のみ。OPに比べ簡単
FMC:インスタンスタイプの選定のみ。OPに比べ簡単
4  OS(選定/インストール/設定)
2
4
5
OP:自社で OS の選定、インストール、各種設定が必要
AWS:OSの選択は必要だが、インストールは不要
FMC: OS 選定もインストールも不要
5  FileMaker Server セットアップ
2
3
5
OP:自社ですべて行うため時間と労力がかかる
AWS:同上
FMC:20分程度(他に比べ簡単)
6  FileMakerライセンスの柔軟性
3
3
2
OP/AWS:自社で FMS ライセンスを用意する必要あり
FMC:AWS MarketPlace から BYOL、またはライセンス込みの FMC オプションを 選択可能。
AWS のユーザ登録とサーバ(EC2)、ストレージ(EBS)の指定が必要。
詳しくはFileMaker Cloud の購入方法を参照。
7  OS・ハードウェアの監視・管理
2
4
5
OP:社内担当者の負担大。
AWS:OS等ソフトウェアは社内担当者が管理、ハードウェアはAmazonにお任せ。
FMC:社内担当者の負担は最小。FMC 側でリアルタイム監視、OS更新通知、ソフトウェアパッチの自動通知
8  バックアップ
5
5
1
OP/AWS:サーバ管理者が計画、設定を行う必要があるが、バックアップスケジュールを自由に設定でき、単独ファイルのバックアップ、フルバックアップ等、柔軟な設計が可能。
FMC:FMC 側で自動メンテナンスを有効にすることによって自動バックアップ可能だが、サーバ環境の AWS スナップショットとなるため、バックアップスケジュールの柔軟性は低い。
FileMaker Cloud のバックアップの操作 を参照。
AWSスナップショットのバックアップはデフォルトで 20分ごとに実行される。一週間で計 504個のバックアップが保持され、古いものから順次自動削除される。よって、一週間より前のバックアップが必要な場合、他のバックアップ方法が必要となる。
バックアップのリストアは EBS ボリュームにスナップショットをアタッチする。ファイル単位の復旧は面倒(関連記事:FileMaker Cloud and Manual Backup Restore(英語))。
9  スケーラビリティ
2
4
4
OP:非仮想化環境の場合、ストレージ/メモリ/コア数の拡張には物理サーバ等のハードの入れ替えが伴うが、仮想マシンであれば拡張は容易で、費用は発生しない。
AWS/FMC:ストレジの拡張、サーバのアップグレードはオンラインで行えるが、拡張すれば運用コストもアップする。
10  最大アクセス数(FM社検証値)
5
5
3
OP/AWS:最大500 同時アクセス
FMC: 最大 100 同時アクセス
11  アップタイム(継続稼働)
3
4
4
OP:会社のポリシーと管理者の力量に依存。
AWS/FMC:99.99% のアップタイム(理論値と思われる。表外のコラム参照。
12  BCP(災害時復旧)
2
4
4
OP:災害被災時は焼失等により復旧不能となる可能性あり。同時被災の可能性が少ない遠隔地ストレージへのバックアップが推奨される。
AWS/FMC:OPに比べ影響を受ける可能性は少ないと思われるが、被災可能性は無いとは言えない。
13  ネットワーク
5
3
3
OP:LAN専用の場合、インターネット環境に影響されない。WANの場合は回線品質に依存する。
AWS/FMC:インターネット接続必須。実行速度はAWSのインスタンスタイプに加え、自社が使用する回線品質にも依存する。OPに比べ、WANの構築は容易。
14  サーバ証明書
3
3
3
OP/AWS:自前の証明書をインストールする必要あり
FMC:Comodoの試用版SSL証明書が付属(90日)
15  サーバ認証
4
4
3
OP/AWS:FileMaker ユーザアカウント認証、Active Directory/Open Directory および OAuth 2.0 アイデンティティプロバイダを使用した外部認証
FMC:FileMaker ユーザアカウント認証、 OAuth 2.0 アイデンティティプロバイダを使用した外部認証
16  サーバサイドスクリプト
5
5
2
OP/AWS:サーバ管理者が計画、スケジュール設定
FMC:スケジュール機能は限定的
17  ESS
5
5
2
OP/AWS:ESS使用可
FMC:ESSアダプタ以外は ESS 使用可
18 ODBC/JDBC
5
5
4
OP/AWS:ドライバのインストールが必要
FMC:ドライバのインストールが必要、専用ドライバの提供あり
19  プラグイン
5
5
3
OP/AWS:使用可能
FMC:一部対応していないものがある可能性あり
20  カスタムWeb with PHPおよびXML
5
5
-
OP/AWS:使用可能
FMC:使用不可
21  FileMaker Data API
3
3
3
OP/AWS:使用可能
FMC:使用不可
注:
本機能は1ライセンスあたり年間24GB のアウトバウンド転送量が付属するが、この転送量を超過するとライセンスを追加購入するが必要ある
土屋企画評価
73
86
67

 2019年8月14日、DNS の問題により、FileMaker Cloud for AWS にアクセスできない問題が発生しました。

 FileMaker Cloud の DNS障害について  [FileMaker Community]



 2019年8月23日、AWSの東京リージョンで大規模な障害が発生しました。



 同日17時現在、当方で利用している東京リージョンの AWS EC2 にはアクセスできましたが、AWSの Service Health Dashboard をみると、まだ完全復旧はしていないようです。9時~17時までの8時間、システムが停止している会社もあるかも知れません。

 上記のような障害は頻繁に発生するものではないと思いますが、クリティカルなシステムでは想定しておかないといけないですね。

 AWSかオンプレミスか、最先端のAmazon AWS vs 自社システム部門… 明日はどっちだ!

参考:
2018年からAWS東京リージョンでもリージョン間VPCが可能になっていて、リージョン間クラスタの構築が可能だそうです(参考記事)。今回の障害発生時、リージョン間クラスタは機能したのでしょうか。


 次に初期費用をシミュレーションしてみます。下表が、オンプレミス、AWS EC2、FileMaker Cloud 導入時に発生する諸費用となります。

 当然ですが、オンプレミスは自前のサーバが必要となります。サーバが無い、あるいは既存のサーバに空きが無い場合、サーバを購入しなければなりません。

 これに対し、AWS および FileMaker Cloud は、初期費用としてサーバ証明書と FileMaker 年間ライセンス費用のみとなるので、初期費用を抑えることができます

表2. サーバ仕様と初期費用比較
No. オンプレミス
(OP)
AWS EC2
(AWS
FileMaker
Cloud(FMC)
補足
1  サーバ証明書
(COMODO 企業認証タイプ SSL)
¥27,864 ¥27,864 ¥27,864 ・金額は消費税込み。
・FileMaker Cloud はComodo試用版SSL証明書が付属(90日)するが、90日以降の運用を想定して料金に追加
2  FileMaker Server
年間ライセンス費用
¥390,000 ¥390,000 ¥390,000  
3  サーバ配置場所
自社
AWS AWS  
4  リージョン
自社
東京 東京 「東京」のAWS正式呼称:Asia Pacific (Tokyo)。FileMaker Cloud の場合、アジアで選択できるリージョンは、東京とシドニーのみ
5  フルフィルメント・オプション
AIM AIM AIM:Amazon Machine Image (64bit アーキテクチャ)
6
 サーバタイプ
(インスタンス種別)
EC2(t2.large)
EC2(t2.large)
 
7
 HDD/EBS
(追加ストレージ)容量
1000GB
40GB
40GB
FileMaker Cloud は40GBがデフォルトで付属
8
 メモリ
8GB
8GB
8GB
 
9  コア数 2 2 2  
10
 CPU
Intel Xeon
Intel Xeon
Intel Xeon
 
11  クロック
3.3GHz
3.3GHz
3.3GHz
 
12  OS
Win Svr 2016
Win Svr 2016
CentOS Linux
Win Svr 2016:Windows Server 2016
13  サーバハードウェア初期費用
¥300,000
¥0
¥0
OPはUPS、バックアップ機器等のサブシステム費用を含まず
初期費用計 ¥717,864 ¥417,864 ¥417,864  
備考:

年間ライセンスと永続ライセンスはどちらがお得なのか

同一バージョンの FileMaker Server を 3 年以上使する場合、永続ライセンス(買い切り)を購入したほうがコスト安となります。
 とういのは、FileMaker Server を 25ユーザで運用する場合、年間ライセンスは 39万円、これを 3年間使用し続けるとすると年間ライセンスは 117万円となり、この費用は永続ライセンスの金額と同額となるからです。
 よって、3年以上を超えて長く運用すればするほど永続ライセンスがお得です。

 なお、永続ライセンス自体は FileMaker Cloud で使用できない点にご注意ください。
 
 最後に月々の運用コストを比較してみましょう。

表3. 運用コスト月額概算比較
No. セットアップ項目 オンプレミス
(OP)
AWS EC2
(AWS)
FileMaker Cloud(FMC) 補足
1  1日の稼働時間(H)
24
24
24
 
2  消費電力(W)
400
400
400
ラックマウントサーバ Dell R330 相当の消費電力
3
 30日分の消費電力(kW)
288
288
288
400W X 24H X 30日÷1000 として計算
4  電力単価*2
¥17.60
東京電力の料金(夏季)
AWS/FileMaker Cloud は電力請求なし
5  電気代
¥5,068.80
AWS/FileMaker Cloud は電力請求なし
6  AWS の時間単価
$0.13   EC2(t2.large)
7
 FileMaker Cloud の時間単価
$0.117 EC2(t2.large)
8  30日分の料金
$93.60 $84.240 24H × 30日 × 上記時間単価(割引適用無し)
9 9 AWSのストレージ料金(40GB)
$4.80 料金に含む FileMaker Cloud で割り当てられる EBS (40GB)
目安
10  アウトバウンド転送料金 (50GB) ¥0 $6.86 $6.86 保守用のデータ転送として 50GB を想定
11  AWS/FileMaker Cloud 料金合計
$105.26 $91.10  
12  米国ドル為替レート
(2018/08/29 時点)
¥111.15
¥111.15
 
運用費用月額計*1
¥5,069
¥11,700 ¥10,126 *OPは高負荷状態を想定、冷却空調費用含まず


FileMaker Cloud の申し込みの柔軟性について

FileMaker Cloud のライセンスは、 BYOL(既存のライセンスの持ち込み) とマーケットプレース(5/10/25/100ユーザライセンス)での購入に分類できます。
 請求に関しては hourly(時間請求) と annual(年間請求)という分類になります。

 一見、簡単なようにみえますが、以下のようなことを考慮する必要があります。
  1. FileMaker Server の永続ライセンスは使用できない。但し、永続ライセンスを年間ライセンスに変換すれば Cloudでの使用が可能。
    永続ライセンスを年間ライセンスに変換し、FileMaker Cloud に適用するまでの手順が公式動画で紹介されています。
  2. BYOL はリザーブド・インスタンス(インスタンスの年間契約)を選択できないため、hourly (時間請求)の一択になる。
  3. BYOL を使用しない場合、hourly(時間請求)または annual (年間請求)を選択できるが、ユーザ数の区切りが 5ユーザ、10 ユーザ、25 ユーザ、100 ユーザの 4 択になる。同時アクセスユーザ数が 30 など、中途半端になる場合はコスト高になる可能性がある。
  4. annual を選択すると途中解約やダウングレードができない。この件に関するサポートやアップグレードの要望がある場合は要問合せ(英語)
FileMaker Cloud 自身の操作では、 BYOL を AWS のリザーブド・インスタンスに適用できない件は、FileMaker 公式のオンラインコミュニティでも議論されています。
 参考:BYOL to a reserved instance on FileMaker Cloud (英語)

 スレッド内でも言及されていますが、あらかじめ AWS でリザーブド・インスタンスを購入しておいて、後で FileMaker Cloud の BYOL に結びつけるという裏技もあるようです。ただし公式対応ではないため、微妙です。
 参考:Using an AWS Reserved Instance with FileMaker Cloud (英語)

まとめ

すでに社内に仮想環境があるのであれば、仮想マシンを一つ作成するだけで FileMaker Server 環境を構築できますので、FileMaker Cloud の必要性は低いと思います。これはAWS 等のクラウドを運用中の企業でも同様です。

 社内にサーバ技術者がいない、いろいろ考えず手っ取り早く FileMaker を試用したいといった場合には、 FileMaker Cloud が威力を発揮すると思います。ただ、FileMaker AWS への登録、キーペアの作成、FileMaker Cloud 申し込み、FileMaker Cloud へのキーペア紐づけ等の設定は最低限必要になるのでご留意ください。


■ FileMaker Cloud 関連情報(随時更新)
FileMaker Cloud のチュートリアル(18/09/04追記)

FileMaker Cloud スターティングガイド(18/09/04追記)

FileMaker Cloud Support ページ [英語](18/09/03追記)
FileMaker Cloud に関するサポート情報がコンパクトに表形式でまとめられています。



参考リンク:
*本稿執筆にあたり、以下を参考にしています。
FileMaker ServerとFileMaker Cloudの比較 [公式サイト]
FileMaker Cloud 技術仕様 [公式サイト]
ファイルメーカー、「FileMaker Cloud」の日本リリースを発表 [公式サイト]
料金単価表‐電力(従来からの料金プラン) [東京電力]