##いよいよ試用環境の構築・・
前回は、MemSQLの概要や導入ターゲット領域等の解説をしましたが、今回よりいよいよ試用導入編に入ります。まずは、MemSQL社のホームページに入って頂き、「Try Free」ボタンを選択します。
各項目に必要事項を登録してください。
最新版では、V7Betaを使ってMemSQL社が提供するクラウドサービス（海外リージョンで展開しています）のHeliosでのトライアルも選択できますが、あるレベル以上の詳細が仕組み上隠蔽されますので、今回の記事では物理サーバ環境への導入を選択していきます。
パスワードを設定します。
正しく認証されると、登録したメールアドレス宛に確認の為のメールが発送されます。
正式にMemSQL社より確認の為のメールが届いたら「Verify Email Address」を選択します。
正式に処理が完了すると、ブラウザにインストールの手順を説明するページが出てきますので、今回のターゲットである「Download & Install Anywhere」から作業を開始します。
##今回のハードウエア構成・・
今回の試用に用いるハードウエア構成は以下の通りです。
（１）CPU Intel Core i7 (4 Core 8 Thread）
（２）メモリ 32GB
（３）SSD 256GB
MemSQL社が提案している基本的な構成として8vCPU, 32GBメモリ構成がありますので（もちろん、ワークロードの特性によっては、1台のメモリを大きくしたりする設計も有りますが、基本的にこの数字の組み合わせを覚えておいて頂ければと思います）それに準じた物理構成にしました。
実際には、今回の評価を進める際に「どういったハードウエア構成にするか？」といった根本的な問題に関して、「極めて単純にほぼ同じ構成（CPUとメモリ）」が「丁度良い台数」空いていたというだけの話なのですが、実はこの単位（ストレージを除いて）がMemSQL社がプロモーションの一環として進めている、フリーの試用ライセンスを構成するのに丁度都合が良い！というポイントがあります。
MemsQL社が提供する試用ライセンスの条件は、
に詳しく記述がありますが、基本的にはMemSQL 6.7.13以降（今回ご紹介しているV6.8はこれに該当します）では、ユニットの概念に基づいたライセンスがサポートされるようになり（以前は、メモリ空間に対して設定されていました）、MemSQLカスタマーポータル（今回ご紹介している手順で付与されるライセンスは此処で管理されます）で生成されるすべての新しいライセンスは、ユニットベースのライセンスになります。
また、ユニットはｖCPU数（8 vCPU/システム以下）とRAM（32 GB/システム以下）の組み合わせを基準としていて、構成するMemSQLクラスター内におけるリーフノードを受け持つホストマシンの数に対して適用されます。またハイパースレッディングが有効かどうかに関係なく、プロセッサとしてで使用可能な仮想コアの数を対象としてカウントするという事なので、この辺を十分ご注意頂き試用環境を構築して頂ければと思います。
むむむ・・・ここで素朴な疑問が生まれてくるかと思います・・・・
正式に登録されたカスタマーポータルのライセンスには、**「4 Units Capacity...」**と表記されていると思います。さて、この4ユニットとは・・・？？
現在MemSQL社よりフリーで提供されるライセンスの場合、原則的にアグリゲータノードはライセンス対象のユニットに計算されない方式になっています。実践編以降で各ノードの役割等について解説していきますが、とりあえずは、アプリケーション側から見てデータベースに見えるアグリゲータノードと、実際にデータを抱え込んでSQL処理の殆どを行うリーフノードの2種類が有ると覚えておいてください。
では、この4ユニットは・・・・
はい、ご想像の通り後者のリーフノードの数になり、この数を厳密に抑える形でフリーの試用ライセンスが提供されています。また、この数は幾つかのルールが存在し、その辺の情報もMemSQL社より公式ホームページ上で公開されています。
ホームページでは、AWSのEC2における基本的な構成と、それらの場合にMemSQLのフリー試用ライセンスの場合、どのようにノード数に換算するかの例が出ています。
その中から表を抜粋すると
| Type | Memory | vCPU | Unit | |
|---|---|---|---|---|
| (1) | m5.2xlarge | 32 | 8 | 1 |
| (2) | c5.2xlarge | 16 | 8 | 1 |
| (3) | i3.2xlarge | 61 | 8 | 2 |
| (4) | r5.2xlarge | 64 | 8 | 2 |
| (5) | m5.4xlarge | 64 | 16 | 2 |
| (6) | m4.10xlarge | 160 | 40 | 5 |
2番目の項目がメモリ容量で、3番目の項目がvCPU数で、3番目がそれらに対応するライセンス上のユニット数になっています。
では、少し内容を解説しておきたいと思います。
(1)の構成が基本構成で、クラスター構成のお約束である均等＆シンメトリックな構成を組める、一番バランスの良い構成になります。MemSQL社の定義では、前述のとおり8vCPU & 32GBメモリを単位としますので、ユニット数を１個消費する形になります。
(2)の構成は、一見メモリが16GBと少ない構成なので、0.5！という形に見えますが、実際にはvCPUが8個になっていますので、こちらの数字が優先されてユニット数１とカウントされます。
(3),(4)の場合は、vCPUは1ユニット範囲に収まっていますが、メモリが32GBの2倍（切り上げで計算されます）になりますので、今度はこのメモリ容量側が優先されて2ユニット消費の計算になり、もちろん双方のパラメータが綺麗にx2になる(5)のケースも2ユニット消費の計算として扱われる事になっています。
(6)のようなケースは、相当リッチでなかなか見ない構成なのですが、最終的なPoC等の場合には出てくる事がある組み合わせになります。
この場合は・・
40vCPU ÷ 8vCPU = ５
160GB ÷ 32GB = ５
となり、ユニット数換算で4を超えてしましますので、個別に申請ベースのエンタープライズ版期間限定試用ライセンスが必要になります。
では、これらの組み合わせより小さい場合・・・・
技術的に言うと、ハードウエアの最小要件定義を超えていればMemSQLのノードとして動作しますが、現実的に今度はvCPUの数やメモリの容量ではなく、純粋に4台というユニット数で制限されますので、意図的に小規模x4でのテスト等を想定されない限り、MemSQL社の推奨する組み合わせで試用頂く事をお勧め致します。
####余談ですが・・・・
上記のカウントルールは、クラスター内のリーフノードにのみ適用されるため、アグリゲーターノードはライセンスユニットの計算の一部に入らない仕組みになっています。これは、活用編以降で説明する事になるかとは思いますが、例えばマスターアグリゲータに子分を複数（チャイルドアグリゲータ）設定して、配下のリーフを共有する形で、データベースの入り口を最適化（スケール）させる事が出来る事を意味しています。
また、今回の一連の解説の後半回では、小規模ですが分散構成を作る方法も解説したいと考えていますが、その際のハードウエア構成もこの初期試用環境と同じハードウエアの組み合わせで行う予定です（今回のハードウエアと同様に、秋葉原工場で作成したものですが・・（汗））
##ソフトウエア的な準備・・
前述のハードウエアにCentOS7の基本パッケージを導入しておきます。コマンド・ドリブンでバリバリ進めても良いのですが、管理コンソール等がGUIベースで提供されますので、基本構成のGUIベースサーバ構成でインストールする事にします。
あと。。。諸々の検証等がシンプルに進むように、今回の試用環境ではFirewalldを外しておく事にしました。外し方はCentOS７ですので
% sudo yum -y remove firewalld
でいけるかと。
それと、OS環境を最新にしておくことも忘れずに実施しておきます。
% sudo yum -y update
ソフトウエアの準備は基本的にこれでOKです。
##OS層の最適化について・・（参考情報）
MemSQLをH/W層から組み上げる場合、OS側に幾つかの初期設定等が推奨されていますので、以下に簡単に紹介しておきます。
まずは、分散クラスター自体の性能を最適化するために、セットアップ時に考慮すべき点と推奨事項は以下の通りです。但し、基本的にハードウエアとソフトウエアの要件を除いて、その他の設定に関してはオプション扱いになっていますので、必ず作業を行わなくてなならない！という事ではありません。
###ハードウエア要件
技術的なMemSQLノードの最小構成は、4個のCPUコアと8GBのRAMが利用できる環境になりますが、実際には最小基準は前述のvCPU数とメモリ容量からスタートするようにしてください。
###ソフトウエア要件
ソフトウエアを導入する要件としては、最低限必要なLinuxカーネルバージョンは2.6.32と指定されていますが、実際にはパフォーマンス上の理由から、MemSQL社の推奨としてカーネル3.10以降での実行が推奨されています。MemSQL社からの現在の推奨プラットフォーム（OS）は以下の通りです。
（１）RHEL / CentOS 6または7（バージョン7を推奨）
（２）Debian 8または9（バージョン9を推奨）
###クラウド環境で展開する場合の留意事項
MemSQLを利用する環境がクラウド上に展開される場合は、原則的に全てのインスタンスを地理的に単一の地域に設置しなければなりません。
また、ネットワーク環境に関して、拡張ネットワーキングをサポートするインスタンスタイプを利用する場合、必ずその機能（または同様の機能）を有効にするようにしてください。
###ネットワークポート設定について・・
MemSQLは、2階層から構成される分散処理を前提とした仕組みになっていますので、連携作業が間違いなく行われるようにファイアウォールを含めたネットワーク環境を構築しなければなりません。今回の試用環境では、この辺の作業を単純化するために意図的なファイアウォールサービスの削除を実施して各種の検証を行いますが、実環境に組み込む際等では、以下の情報を参考に設定を行ってください。
####前提条件
（１）データベースクライアントがMemSQLアグリゲーターに接続できるようにします
（２）クラスター内のすべてのノードがMemSQLプロトコルを介して互いに通信できるようにします（ポート：3306）
（３）管理および監視ツールに接続できるようにします
####使用するポート情報
[TCP : 3306 -> インバウンドおよびアウトバウンド]
MemSQLが使用するデフォルトのポートで、クラスタ内通信に関係する全てのノードで利用します。
また同様に、クライアントが接続してくる各アグリゲーターでもこのポートは利用されます。
[TCP : 22 -> インバウンドおよびアウトバウンド]
ホストマシンがツール関連の処理で利用します。
[TCP : 443 -> アウトバウンド]
パッケージ検証用の公開リポジトリキーの取得に使用します。
また同様にMemSQLのAPTまたはYUMパッケージをダウンロードする際にも必要になります。
[TCP : 8080 -> インバウンドおよびアウトバウンド]
MemSQL Studioのデフォルトポート（Studioを実行しているホストマシンにのみ必要です。）になります。
また、デプロイメント環境でこのデフォルト値を使用できない場合には、別途サービスポートの値の変更構成は可能です。
##ハードウェアの推奨事項
前述の仕様要件とは別に、最適なパフォーマンスを得る為のハードウェア推奨事項がMemSQL社より提示されています。
（１）CPU ホストマシン毎に8個のvCPU
（２）メモリ コア毎に少なくとも4GB、リーフノードごとに最小32GB
（３）ストレージ メインメモリの少なくとも3倍の容量を各ノードにストレージシステムとして準備し、カラムストアを多用する場合などでは、この領域にSSDストレージの適用検討を推奨
###ハードウェアを決定する際の考慮事項
（１）MemSQLがメモリ上に展開するテーブルの大きさは、構成するホストマシンのメモリの量に依存し、メモリを増やすと使用可能なデータストレージの容量を増やすことが出来ます。またこの場合は、クラスター構成を考慮したハードウェアとソフトウェアの仕様が同じマシンでMemSQLリーフノードを実行することを強くお推奨しています。
（２）MemSQLは、SSE4.2およびAVX2命令セット拡張をサポートするアーキテクチャ向けに内部を最適化していますが、これらをサポートしていないx64システムで正常に実行させる事が可能です。
（３）カラムストアテーブルへの負荷が高いケースでは、SSDストレージを適用する事により全体のバランスを整える事が出来るので、HDDストレージで構成した場合と比較して性能を大きく改善する事が可能です。
（４）Cluster-on-Dieがサポートされている場合、MemSQLをネイティブにインストールし、BIOSにアクセス可能な状況では、システムBIOSでCluster-on-Dieを有効にする必要があります。（Haswell-EP以降のCPUを搭載したマシン等）またこの設定を有効にすると、プロセッサごとに複数のNUMA領域が公開され、MemSQLが特定のノードをこれらのNUMAノードにバインドすることが出来るようになり、NUMA領域を効果的に活用出来ると同時に、MemSQLのパフォーマンスを向上させる事が可能となります。
##ソフトウェアの推奨事項
前述の基本的なOS要件に加えて、以下の項目に関して稼働を支えるLinux OSの最適化を検討する事により、MemSQLの稼働効率をより向上させる事が期待できます。(これらのチューニング手順は、クラスタ内の各ホストマシンで均等に実行する必要があります)
###Linux vm設定を構成する
MemSQLでは、memsql-admin、memsqlctl、MemSQL Opsなどの標準環境を稼働させる場合に、幾つかのvm周辺の設定を再構成する事により、システム稼働時のメモリエラーが発生する可能性を最小限に抑えることが期待出来ますので、可能であれば検討される事をお勧めします。
一般的なパラメータのデフォルト値は次の通りですが、
vm.max_map_count 1000000000
vm.min_free_kbytes システムRAMの1％または4 GBのいずれか小さい方に設定
MemSQLが提供しているツール関連で、不具合に基づく値とその意味と設定方法を示すエラーメッセージが表示される場合があります。この様な場合には、/sbin/sysctlに対して以下に示す様な操作を行う事で、それぞれの値を手動で設定出する事が可能です。
% sudo sysctl -w vm.max_map_count=1000000000
% sudo sysctl -w vm.min_free_kbytes=658096
###NUMAサポートを有効にする
MemSQLを稼働させるホストマシンのCPUが、Non-Uniform Memory Access（NUMA）をサポートしている場合、MemSQLはそれを利用してMemSQLノードをNUMAノードにバインドする事が可能です。
この機能を活用してMemSQLノードをNUMAノードにバインドさせると、個々のMemSQLノードが対応するCPUと連結されたデータのみにアクセスするようになるため、構成されているテーブルが展開されているメモリ内データへのアクセスを高速化する事が可能になります。一方、このCPUサポートを無視してNUMAを使わない構成の場合では、オバーヘッドの高いクロスNUMAノードメモリアクセスによるパフォーマンスの大幅な低下が発生する場合があります。（一般的にNUMAの構成は、インストールプロセスの一部として実行する必要がありまが、必要に応じて後でこの展開を再構成する事も可能です）
MemSQLでNUMAバインディングを実行する場合は、numactl最初にインストールする必要があります。
各ホストマシンで次の手順は以下の通りです。
（１）各ホストにログインして、numactlパッケージをインストールします。
DebianベースのOSの場合： % sudo apt-get install numactl
RHEL / CentOSの場合： % sudo yum install numactl
（２）numactl --hardwareを実行して、マシンのNUMAノードの数を確認します
例：numactl --hardware
available: 2 nodes (0-1)
結果の出力は、このマシンに2つのNUMAノードがあり、0と1の番号が付けられていることを示しています。
###Transparent Huge Pagesを無効にする
MemSQLの稼働に際しては、クラスター内のすべてのノード（マスターアグリゲータ、チャイルドアグリゲータ、およびリーフ）でブート時にTransparent huge Pages（THP）を無効にすることをお推奨しています。
この作業を実施しない場合、稼働の状況によりクエリの実行時間が一貫しなくなる可能性が想定されます。
THPを無効にするには、次の行をrc.local終了行の前に追加し（存在する場合）、ホストマシンを再起動して実施します。
Debianベースのディストリビューションの場合は、/etc/rc.d/rc.localに以下を追加します。
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
echo no > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
RHEL/ CentOSディストリビューションの場合は、/etc/rc.localに以下を追加します。
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
echo 0 > /sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag
echo no > /sys/kernel/mm/redhat_transparent_hugepage/khugepaged/defrag
注意点：
Red Hat Enterprise Linux 7バージョン以降で/etc/rc.d/rc.localは、ユーザーに対してデフォルトでは実行許可が有りませんので、実行権限を追加する為に次のコマンドを実行します。
% chmod +x /etc/rc.d/rc.local
###Network Time Protocolサービスをインストールして実行する
ntpdをインストール・実行し、クラスター内のすべてのノードでシステム時間が同期していることを確認します。
Ubuntu系Debianベースのディストリビューションの場合：
% sudo apt-get install ntpd
RHEL / CentOSディストリビューションの場合：
% sudo yum install ntp
###オンプレミス・カラムストアのパフォーマンスに関する推奨事項
MemSQLのカラムストアでは、EXT4およびXFSファイルシステムをサポートしており、またこの領域でNVMeデバイスを用いる場合は（最近の各Linuxで多くの改善が行われ、性能向上と安定性が確保出来るようになったので、性能を必要とするカラムストア側には、SSD等のデバイスを推奨しています）3.0 +シリーズのカーネルの使用を前提に構成するようにしてください。（例：CentOS 7.2は3.10カーネルを使用）
また、NVMeドライブを使用する場合は、Linuxで次のパラメーターを設定します（/etc/rc.localへ実施）
＃Set ${DEVICE_NUMBER} for each device
echo 0 > /sys/block/nvme${DEVICE_NUMBER}n1/queue/add_random
echo 1 > /sys/block/nvme${DEVICE_NUMBER}n1/queue/rq_affinity
echo none > /sys/block/nvme${DEVICE_NUMBER}n1/queue/scheduler
echo 1023 > /sys/block/nvme${DEVICE_NUMBER}n1/queue/nr_requests
###ファイル記述子と最大プロセス制限を増やす
MemSQLクラスターは、アグリゲーターとリーフの間で、かなりの数のクライアント接続とサーバー接続を使用し、要求されるクエリとクラスター操作を実行する関係上、事前にこれらの接続を考慮したLinuxファイル記述子と最大プロセス制限の調整を検討するようにしてください。また、この調整不足により発生する不具合としては、パフォーマンスの著しい低下と接続制限エラーの可能性が考えられます。
実際に該当するulimit設定を行う場合は、/etc/security/limits.confファイルで設定するか、または直接シェルコマンド経由で行う事で実施が可能です。
例えば、/etc/security/limits.confファイルをrootユーザーとして編集し、次の行を追加する事でmemsqlユーザーのオープンファイル制限と最大ユーザープロセス制限を永続的に増やすことが出来ます。
memsql soft NOFILE 1000000
memsql hard NOFILE 1000000
memsql soft nproc 128000
memsql hard nproc 128000
注意点：
変更されたulimit設定を有効にするには、MemSQLノードを再起動してください。
###スワップスペースを作成する
RAMの緊急バッキングストアとして機能するスワップ・パーティション（または専用デバイス上のスワップファイル）を作成することを検討してください。MemSQLはその特性上メモリを広範囲に使用するため、MemSQLがメモリ不足になった場合に、オペレーティングシステムがすぐにプロセスの強制終了を開始しないように回避策を準備しておく事が非常に重要になってきます。スワップ領域の設定と構成の詳細については、ディストリビューションのドキュメントを参照してください。
##最後に
また、今回ご紹介しているフリー試用ライセンスに対するサポート等は有りませんので、自己責任・自己解決を前提にお使い頂くようにお願い致します。なお、コミュニティー的な情報交換の場がありますので、疑問点等があればそちらに問い合わせてみるのも良いかもしれません。
##謝辞
本解説に転載させて頂いているスクリーンショットは、一部を除いて現在MemSQL社が公開されている公式ホームページの画像を使わせて頂いております。また、本内容とMemSQL社の公式ホームページで公開されている内容が異なる場合は、MemSQL社の情報が優先する事をご了解ください。