YOS INDEX は省電力を重視した設計により、非常に低い電力消費でありながら、高速な検索ができます。これはハードウェアとソフトウェアの両方に注意を払い無駄を削ぎ落としていく努力により可能となりました。スモールシステムでパワフルなサーチサービスを提供します。私はこのアーキテクチャは今の時代に必要だと考えています。
1. 背景
東日本大震災をきっかけに、電力不足の問題が発生しています。東京電力は2012年の4月以降、電気料金の大幅な値上げを実施しており、社会全体として節電を心がけなければならない状況となりました。当然、IT業界も例外ではありえません。積極的に電力効率の良いアーキテクチャ（設計技術）に転換しなければならない時代となったのです。
2. 設計目標
検索サービスの稼動するノードは最大商品電力の30Ｗ以下で１万人くらいが利用できる事を設計目標にしています。一般的なラップトップパソコンで 20 – 50 W で、デスクトップの場合は 200 – 300Wくらいです。ラップトップパソコンと同程度の消費電力となることから、ざっとノートパソコン程度の計算能力しかないと考えられます。 一般的に使われるサーバーと比較してり非力すぎる環境を前提としていますので、ハードウェアの潜在能力を引き出し、性能を最大化するためにソフトウェアの設計を１から見直し、アプリケーションのフレームワークを再設計することに決めました。
3. 検索サービスの最適化方針
サーチ性能で重要なのはＩＯ性能で特にRead性能が重要です。 IO性能は広帯域化、帯域の有効利用、キャッシュの効率化により性能が上がります。 従って、以下ような最適化が有効と考えられます。
- 高速なストレージを使用する
- マザーボードのメモリー最大搭載容量のメモリーを搭載する
- プログラムを小さくすることでデータキャッシュに使える量を増やす
- キャッシュヒット率を向上する
- 圧縮による効率的なデータ転送を行い帯域を有効利用する
4. ハードウェア
サーバーの冷却システム
稼働中のサーバーは常に発熱しており、CPUは限界温度を超えないように保護回路が働きクロックを抑えて動作しようとします。それでも加熱が続くと熱暴走によりシステムがハングアップしたりCPUが破損します。一般的なサーバーでは、こうならないように空調設備や、ＣＰＵファン、ケースファン、電源ファン等により積極的に冷却装置で熱を取り除きます。サーバーの発熱量に比例して冷却装置の使用電力が増加することになります。実行性能を重視する考え方ではデータセンターの電源設備の限界まで電力を無尽蔵に使うシステムが構築されてしまいます。
逆に、サーバーの発熱量を抑えることが出来れば冷却装置も含めた全体の消費電力を減らすことが出来ると考えられます。即ち、保護回路が働かない温度をねらって稼動させる事で、冷却に消費する電力を抑える事ができれば最も効率が良いはずです。究極的には冷却システムを自然冷却のみに特化して単純化させることが出来ればＣＰＵファン、ケースファン、電源ファンが不要となり冷却に必要な電力は0Wとなります。
低電圧・高性能CPU
冷却システムとしては大型ヒートシンク、ヒートパイプを組み合わせた自然冷却を行うものとします。但し、夏場の気温上昇に対応するために空調は使用することを前提にCPUを選択します。自然対流のみで冷却可能な消費電力の目安は6wと言われていますが、経験的には大型ヒートシンク、ヒートパイプを用いた環境でTDP18Wでも問題なく安定稼動しているので、TDP20Ｗくらいが限界ではないでしょうか。強制冷却システムを排除するために、採用するCPUは自然冷却のみで安定稼動することが絶対条件となります。入手し易いx64系のCPUで省電力を謳っているマルチコアの製品は以下の通りになります。
| 製造プロセス | Intel Core | Intel Atom | AMD Fusion APU |
|---|---|---|---|
| 45nm | Diamondville 8W, Pineview 8.5W, 13W | ||
| 40nm | Desna 5.9W, Ontario 6W, Zacate 18W | ||
| 32nm | Sandy Bridge(20W) | Cedarview 3.5W,6.5W,10W | Zacate 18W |
性能は Sandy Bridge(20W)、Zacate(18W)という順で良いが、手ごろな価格のZacate(40nm)を採用することにしました。プロセスの微細化の利点は、集積度を高め、電力効率を引き上げる効果がありますので、出来る限り最新の製造プロセスを使った方が良いと考えられます。大体2年ごとに次世代のプロセス技術に移行していますので2年毎にCPUを置き換えていく計画が良いと考えられます。
低電圧・広帯域ストレージ
ストレージはHDDドライブを一切使用せずSSDのみとします。ボリューム管理はZFSで行います。 SSDはHDDと比較して消費電力、速度が圧倒的に優れています。SSDのみで構成されたストレージの消費電力は 1W 以下となり、消費電力が少ないので発熱もほとんどありません。 インデックスファイルサイズの4倍以上の容量が必要になります。
5. OSの最適化
64bit OS を使用する
インテル系のCPU(x86)は32bitの場合、他のアーキテクチャのCPUと比較してレジスタが少ないという欠点があって、64bit(x64)で利用できるレジスタが大幅に増え改善されています。32bitより64bitのバリナリの方が一般的には性能が10%から20%程度良くなります。又、32bitの場合は 4GB(実質3.2GB)までしか搭載できなかったが、64bitでは実質無限に搭載できるようになります。デメリットとしてはプログラムのヒープサイズが約30%程増加することが挙げられますが、これはメモリーが安価に購入できる現在では大した問題ではありません。
カーネルを再構築する
OSをサーバー専用に利用する場合は接続しない不要なハードウェアサポート、サービスを削除することができます。OSを最小化することで脆弱性の原因となるコンポーネントが減り、性能面だけでなくメンテナンス効率が良くなるという効果もあります。カーネル再構築することでGENERICカーネルのサイスから大体40%～50%くらい削減できます。
CPUの省電力モードを有効にする
Webサーバーは実はほとんどの場合、待機状態であることが多い。常にフルパワーで待機させておく必要はありません。負荷状況に応じてCPUクロックを制御させます。
6. アプリケーションの最適化
キャッシュ戦略
検索結果は積極的にサーバーでキャッシュされ、次に同じキーワードで検索を行った場合の応答時間は大体10msec未満の応答時間になり、実際に検索処理が行われるより数十倍くらい速い応答時間となります。従って、キャッシュのヒット率を向上させることで大幅な応答時間の向上が期待できます。
キャッシュは次の順番で効果が高いと考えています。
- HTTP Private キャッシュ
- HTTP Proxy キャッシュ
- OSレベルのIOキャッシュ
HTTP Proxy キャッシュシステムは FreeBSD の tmpfsファイルシステム・ドライバー を用います。ファイルシステム・ドライバーが必要に応じてより多くのVMの割り振り、ファイルシステムの容量を動的に増加させます。ファイルを削除された場合にがファイルシステムのサイズを動的に縮小してVMリソースを解放します。HTTP Proxy Cacheに使用されるメモリーは動的に縮退することで、IOキャッシュの容量とのバランスが自己組織的に最適化されます。
HTTPキャッシュも、OSレベルのキャッシュもデータは圧縮された状態で扱われるので空間効率が非常に高い状態となっており、より多くのデータをメモリー上に置くことが出来ます。このことはキャッシュヒット率が向上することを意味しています。
ロードバランサー及びキャッシュサーバー
クアイアントの１リクエストに対応するロードバランサーやキャッシュサーバーの処理は非常に軽いという特徴があり、スレッドプール方式で大量のリクエストを処理する場合にはコンテキストスイッチ する遅延が無視できなくなります。ロードバランサー及びキャッシュサーバーはイベント駆動方式が適していると考えられ、 イベント駆動方式で実装された Nginxを採用しています。実際に同じ目的で ApacheとNginxのパフォーマンスを比較すると Nginxの方が優れてることが分かります。
アプリケーションサーバー
アプリケーションサーバーの処理は重い処理を含む場合があり、イベント駆動方式はシングルスレッドで動くので処理が重いとマルチコアCPUでスケールしなくなります。従って、スレッドプール方式が適しています。検索アプリケーションサーバーとしては Servlet API だけの実装が最適ですので、J2EEの完全な実装を避けると、選択肢としては Tomcat か Jetty になります。パフォーマンスが優秀であった Tomcat7.x を採用しています。