前回は FileMaker Server 16 の WebDirect （WebDirect 16）の構成をマスタサーバ 1 台構成にした場合と、ワーカマシン 5 台構成にした場合とで、スレッド数（接続数）や Ramp-up（全スレッドを生成するまでの時間）の条件を変更しながらパフォーマンス計測を行いました。
本稿では ワーカマシン 5 台構成で WebDirect 16 のロードバランスがどのように機能するのかを見てみます。
本稿では ワーカマシン 5 台構成で WebDirect 16 のロードバランスがどのように機能するのかを見てみます。
【ワーカマシン5台構成のイメージ】
 |
サーバ 5 台構成時 のロードバランス
複数のワーカマシンで構成される WebDirect 16 は Webクライアント（ブラウザ）からリクエストを受信すると、より負荷の低いマシンにそのリクエストを割り当てます（ロードバランス）。
下図は異なる 5 台のクライアント PC のブラウザから WebDirect にログインしたところですが、より負荷の低いワーカマシンにリクエストが割り振られていることがわかります。
下図は異なる 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 実行時のワーカ割り振りの状態です。
たとえば、テスト 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 リクエスト程度の範囲に、安定運用可能なリクエスト頻度の目安があるのかもしれません。
ただ、所要時間は 60 秒なので、この結果を実運用に適用できると仮定すると、ユーザがリクエストを発行してから 60 秒程度、待たされることになります。Ramp が 60 秒、つまり 1 秒に 10 弱のリクエストの場合は、ユーザの待ち時間が数値上はほぼ無くなります。1 秒あたり 10～100 リクエスト程度の範囲に、安定運用可能なリクエスト頻度の目安があるのかもしれません。
マスタ1台構成 vs ワーカ5台構成
最後に、下図は500スレッドの処理を完了するまでの時間を、1 サーバ構成と 5 ワーカマシン構成でパフォーマンスを比較した折れ線グラフです。折れ線の左の部分は、7 秒間に 500 のスレッドからのリクエストを処理する場合、1 サーバ構成の方が 5 ワーカ構成より有利であることを示しています。
本テストは 7 秒～90 秒という短い時間内で終了してしまうテストなので、より長い時間、継続的に負荷がかかるようなケースには当てはまらないかもしれませんが、ワーカを増やせば実行速度も増す、と単純に想定することはできないことを示していると思います。
本テストは 7 秒～90 秒という短い時間内で終了してしまうテストなので、より長い時間、継続的に負荷がかかるようなケースには当てはまらないかもしれませんが、ワーカを増やせば実行速度も増す、と単純に想定することはできないことを示していると思います。
（亀）
