okuyamaを導入するまでに知っておきたいサーバリソースとの4つの関係

このたび、3回にわたって分散キーバリューストアokuyamaについて連載させていただくことになりました岩瀬です。どうぞよろしくおねがいします。

1. 前回のおさらいと今回の連載について

それでは早速ですが、本連載の対象となる分散キーバリューストアのokuyamaについてご紹介させていただきます。2011年2月の連載では、全4回にわたってアーキテクチャの紹介などをさせていただきました。今回はさらに掘り下げて、導入、運用などの視点からokuyamaの解説をしていきたいと思います。

2. okuyamaが利用するサーバーリソース

ではokuyamaを導入するサーバーとの関係から見ていきたいと思います。サーバーと一口に言っても、スペックも用途もいろいろとあり、それぞれに特性があります。ではokuyamaにはどのようなサーバーが適しているのでしょうか？ここでは主にサーバースペックとokuyamaの関係を見てみましょう。

【関係１】　OSとの関係

筆者は今までokuyamaを使った環境構築を、ほぼRedHat、もしくはCentOSといったLinux系OSで行ってきました。しかし、筆者が開発時に使っているOSはWindows系のため、どちらのOSでも一定時間以上の安定稼働ができることを確認しています。ただ、どちらの場合も64bitで利用したほうが性能的に良い結果が出ていますので、なるべく64bit環境での構築をお勧めします。

またokuyamaは大量のファイルやソケットといったリソースを利用します。そのため、そういったリソースの上限値をOS側で制限している場合はあらかじめ高い値にしておくことをお勧めします。具体的にはLinuxなどの最大同時ファイルオープン数などの値になります。

【関係２】 CPUとの関係

okuyamaはCPUのスペックに大きく影響を受けるため、CPUは重要な要素となります。ではどのような部分に影響を受けるかと言うと、1コアの処理能力よりもコア数です。それはokuyamaのネットワーク部分のアーキテクチャである"タスク別キューイング・メカニズム"に起因します(詳しくは、リンク先の記事を参照)。この仕組みはクライアントからの処理依頼を受信する部分と、依頼を実行する部分を別のスレッドとすることで処理依頼待ちに起因するブロッキングをなくす仕組みです。この仕組みには少なくとも2つ以上のスレッド(正確には、接続処理を行うスレッドも存在します)が並列に稼働することで性能を発揮できるように実装されています。

そのため、マルチコアとシングルコアでは大きく性能が異なります。そして、この並列数を決めているのが、MasterNode.propertiesおよび、DataNode.propertiesの最終行に定義されている図1の内容になります。この定義の"*ParallelExecution"の部分がThread数になり、上から「接続処理」、「受信処理」、「メイン処理」となります。

【関係３】 メモリとの関係

続いてメモリですが、ここでは単純に容量だけにフォーカスします。まずokuyamaはClient、MasterNode、DataNodeで構築されているため、3つの箇所でメモリ量を意識する必要があります。

はじめにClientですが、ここでは頻繁に利用するメソッドを基に、稼働させるアプリケーションサーバーが必要とするメモリ量を検討する必要があります。特にメモリ使用量が多くなる可能性があるメソッド名を図2にまとめます。これらのメソッド全てが、複数のKeyやValueを扱う処理です。