FileBlogはソフトウェアとして提供されるので、ハードウェア(物理マシン)はお客様自身にご用意いただいております。いわゆるオンプレミス環境での運用を推奨していますが、「Amazon EC2やAzure VMなどのクラウド環境で運用できますか?」という質問をよくいただきます。
-
FileBlogをクラウド環境にインストールして運用できますか?
-
できます。ただし...
FileBlogは、Windows OSのマシンにインストールできるので、Windows仮想マシンにインストールできます。しかし、以下の点で注意が必要です。
- ファイルサーバーをLAN内において、検索エンジン(FileBlog)をクラウドにおくのは性能面で不利である
- 仮想マシンのタイプとして、「バースト型」の安価な仮想マシンは検索エンジン(FileBlog)の初期導入時に向いていない
そもそも、遠隔のインデックス構築は遅い
原則として、検索対象のファイルサーバーと、検索エンジンが稼働するマシン(検索サーバー)とは、高速アクセスが可能な同一LAN内にあることが望ましいといえます。
ファイルサーバーもクラウドにあるならば、クラウドに検索サーバーを設置しても問題ありません。
LAN内にファイルサーバーがあるならば、原則として検索サーバーもLAN内に設置すべきです。なお次のような場合、クラウドに検索サーバーを設置することもやむをえないかもしれません。
- ファイルサーバーが社内にあるが、FileBlog(検索サーバー)の評価環境用に使える物理マシンが社内にない
- ファイルサーバーが社内の複数拠点に分散しており、各拠点にFileBlog(検索サーバー)を構築するのは現実的でない
WAN越しのインデクシング(インデックス構築)は遅いです!クラウドに限らず、遠隔拠点からのインデクシングは遅い。
LANで100万文書のインデクシングが4時間のとき、WAN越しだと3日間ぐらいかかることがあります。(1000万文書なら1ヶ月!)
ファイルサーバーが複数拠点に分散していて、検索サーバーを1台に集約する場合、最大規模のファイルサーバーと同じ拠点にFileBlog(検索サーバー)を構築してください。
仮想マシンタイプについての注意
- Azure VMでは、汎用仮想マシンのタイプを図1にあるような選択肢から選べます。
- Amazon EC2では、図2のようなタイプがあります。
VMのタイプがたくさんありすぎて(数十種類)、どれを選んだらよいか悩んでしまいますが、多くは「最も安いものを選ぶ」傾向にあります。
その結果、よく選ばれるのが「バーストインスタンス」と呼ばれるタイプです。しかし、検索エンジンを運用する場合、このバーストインスタンスには罠があります。
バーストインスタンスとは?
多くのパブリッククラウド環境で仮想マシンを選択するときに、一見して割安に見えるのが「バーストインスタンス」というタイプの仮想マシンです。たとえば、Amazon EC2のTシリーズや、Azure VMのBシリーズがそれにあたります。
Amazon EC2のT3シリーズの t3.small インスタンスは、3.1GHzのCPUをベースラインレベル20%で常時使用でき、「いつでも必要に応じてCPU使用率をバーストできます」と書いてあります。
これは、Webサーバーなど稼働時間のほとんどを何もせず待機状態で過ごすという用途に特化して、価格を引き下げたものです。
バーストは「いつまでも」持続できません
バーストインスタンスは「いつでもCPU使用率をバーストできます」が、残念ながらそのバースト状態がいつまでも持続するものではありません。1時間あたり数分程度の短時間に制限されていることが普通です。たとえば、EC2のt3.smallでは、1時間あたり12分間だけCPUを100%使用することができますが、残りの48分間はベースラインのレベルに制限されます。
保証されたCPU使用率(ベースライン)は小さな字でしか書いてありませんが、ベースラインレベルはインスタンスにより5%~30%程度に制限されています。
Webサーバーとして使うに割安です
これらバーストインスタンスはWebサーバー向けに最適化された価格設定のインスタンスと考えてよいでしょう。
Webサーバーは、稼働時間のほとんどにおいてユーザーリクエストを待っているだけなので、CPU使用率は平均してほぼゼロに等しく、1つのCPUで20台の仮想マシン(20人のクライアント)を稼働させても差支えがありません。20倍のユーザーを詰め込むことで、利用料金を大幅に安くできるのも当然です。
アクセスが集中することが時々ありますが、バーストインスタンスでは一時的(数分間)なアクセス集中時には、CPU使用率を100%まで上げて対処できるようになっているので、利用者を待たせることがないようにできています。
FileBlogの初期導入時に起こる問題
バーストインスタンスの利用は推奨しません
検索エンジンの初期導入時には、全ファイルを読み取って索引を作るインデックスの初期構築が必須です。これは連続的に高い負荷がかかる処理です。実際、100万文書のインデックスの初期構築には数時間から一日程度の時間を要します。
バーストインスタンスの使用では、最初の数分でバースト可能なクレジットを使い果たし、それ以降はCPU能力が20分の1にダウンするので、通常なら数時間で終わる処理が数日から数週間かかります。お客様の目には「処理が止まったように見える」「CPU使用率が100%に張り付いたように見える」「まったく処理が進まない状態が何日も続く」「画面が凍る」などの症状となります。
CPU使用率が100%であるのを見て、「何か不具合があるのでは?」と報告されるケースもあります。CPU使用率は使っている処理のCPU負荷を、使えるCPU能力で割り算したもので、バーストインスタンスでは割り算の分母が劇的に小さくなることでCPU使用率が100%になっているため、処理に異常があるということではありません。
おすすめのインスタンス
FileBlogをクラウドで運用する場合、汎用インスタンスを選ぶようにお願いしています。
AWSならMタイプ(M7iなどのインテルかAMD)、Azure VMならDファミリがおすすめです。決してバーストインスタンス(Azure VMのBファミリ、AWSのTタイプ)を選んではいけません。
汎用インスタンスはバーストインスタンスよりも価格は高めですが、5割増程度の価格で、連続高負荷時の性能が5倍ほどになることがあります。(小さい字で書かれていますが、よく見比べてください)
ファイル数が1000万文書を超えて全件を検索対象にするような場合は、ファイルサーバーと同一のLAN内に物理マシンを用意することをおすすめします。