griddb.github.io

— はじめに —

本書はGridDBの提供する設計・構築・運用について説明したものです。

本書は、GridDBを用いたシステム開発を行う設計者、GridDBの運用管理を行う管理者の方を対象としています。

本書は、以下のような構成となっています。

　

— 概要 —

GridDBの特徴

GridDBは、高性能でかつ拡張性と可用性を備えた分散NoSQL型のデータベースで、以下の特徴があります。

　

■データモデルとサポートするインターフェース

Key-Valueを発展させたデータモデルです。RDBのテーブルに相当するコンテナに対して、データを格納します。

データモデル
データモデル

NoSQLインターフェースのクライアントAPIやSQLライクなクエリ言語TQLだけでなく、NewSQLインターフェースとしてJDBC/ODBCやSQLも利用可能です。

NoSQL/NewSQLインタフェース
NoSQL/NewSQLインタフェース

　

■可用性

GridDBは、複数のノード（サーバプロセス）で構成されたクラスタで動作します。

ノードで障害が発生した場合、クラスタが自動的に障害を検知して、障害が発生したノードの役割を他のノードに移してクラスタの稼動を継続することができます。 また、クラスタ内ではデータを複製して複数のノード上に多重配置(レプリケーション)しています。 ノードに障害が発生した場合でも、クラスタが自動的にレプリカを再配置するため(自律的データ配置)、継続的にデータアクセスすることができます。

可用性
可用性

　

■拡張性

GridDBのクラスタの性能を向上させるには、ノードが稼働するサーバをスケールアップする方法だけでなく、クラスタにノードを追加するスケールアウトも選択することができます。

スケールアウトでのシステム拡張はオンラインで行うことができます。また、スケールアウトでシステムに追加したノードには、システムの負荷に応じて適切にデータが配置されるため、運用も容易です。

拡張性
拡張性

　

■高速性

データベースの実行待ちとなる時間をできるだけ少なくするために、GridDBでは、CPUコア・スレッドごとに専有するメモリとデータベースファイルを割当て、排他、同期処理の待ちをなくしています。

高速性
高速性

また、高速化のために、他にも以下の機能を持ちます。

詳細は、『GridDB 機能リファレンス』をご参照ください。

　

GridDBのアーキテクチャ概要

設計・構築・運用に必要なGridDBアーキテクチャの概要について説明します。

　

スレッド構成

ノードには、さまざまな処理を行うスレッド(サービスと呼びます)が複数存在します。 ノードのスレッド構成と処理内容を説明します。

スレッド
サービスの構成
スレッド名称 スレッドの処理内容
トランザクションサービス ロウの登録、検索処理などのトランザクション処理や、データベースファイル書き込み処理などを行う
チェックポイントサービス チェックポイント処理を行う
クラスタサービス ハートビートや、ノードの参加・離脱などのクラスタ構成処理を行う
シンクサービス パーティション再配置の際にデータ同期のための長期同期、短期同期処理を行う
システムサービス 運用管理操作の要求を受け付ける
SQLサービス SQL処理を行う

　

　

データ管理

データを管理するデータベースファイルとトランザクションサービスは、一対一の関係にあります。

このデータベースファイルには、複数コンテナを管理するパーティションという内部構造があります。 各トランザクションサービスは、ひとつのパーティションのみを操作するため、他のトランザクションサービスとの排他処理なく実行可能です。

ひとつのノードが管理するパーティション・スレッド・ファイルの関係
ひとつのノードが管理するパーティション・スレッド・ファイルの関係

　

　

ファイル構成

ノードが管理するファイルには、定義ファイルやデータベースファイルなどのファイルがあります。ファイルの構成と内容について説明します。

ノードが管理するファイル構成
ノードが管理するファイル構成

　

上記に説明したとおり、データベースファイルとして、パーティション単位に、データファイル、チェックポイントログファイル、トランザクションログファイルを持ちます。

更新に同期してデータをシーケンシャルにトランザクションログファイルに書き込むトランザクションログ処理により、トランザクション保証を行います。 また、メモリ上の更新データをブロック単位にデータファイルとチェックポイントログファイルに定期的に保存するチェックポイント処理により、データの永続化を行います。

　

メモリ構造

GridDBは、ディスクI/Oを減らし、効率的に処理を行うために各種メモリエリアを持ちます。

メモリ
メモリ
名称 内容
データベースバッファ 読み込んだデータをキャッシュするためのI/Oバッファです。
データファイルから読み込んだデータイメージ（ブロック）をメモリ上にキャッシュします。データベースバッファのサイズが大きい程、ブロックがメモリ上にキャッシュされやすくなるため検索および登録性能が向上します。
ノード上にデータベースバッファの領域はひとつで、複数のトランザクション処理スレッドが共有して使用します。
トランザクション処理用メモリエリア ロウの登録や検索処理などを行うトランザクション処理スレッドが使用する領域です。
SQL中間結果格納バッファ SQL処理中の中間結果を格納するための領域です。
中間結果がバッファのメモリサイズ上限を超える場合は、一時的にSQL中間結果用スワップファイルに書き出します。
SQLワークメモリエリア SQL処理において、ジョインや集計などの途中結果を一時的に格納するための領域です。

GridDBは、メモリとディスクの両方を用いるハイブリッド方式のデータベースです。 メモリをデータのキャッシュとして用いてアクセスを高速化し、データをディスクに格納して大容量データの管理を実現しています。メモリのサイズが大きい方がより多くのデータがメモリ上にキャッシュされるため、ディスクI/Oが減って性能が向上します。

クラスタ管理

GridDBは、複数のノードでクラスタを構成します。

ノードには「マスタ」と「フォロワ」という二つの役割があります。 マスタはクラスタ全体の管理を行います。 マスタ以外のノードはすべて「フォロワ」になります。

クラスタが開始する時には、クラスタを構成するノードのひとつが必ず「マスタ」になり、フォロワはマスタからの指示に基づいて同期などのクラスタ処理を行います。 マスタノードはGridDBが自動的に決定します。 もしマスタノードに障害が発生した場合、フォロワノード群から新たなマスタを自動で決定してクラスタの稼動を継続します。

また、クラスタ内ではデータを複製して、複数のノード上にデータ(レプリカ)を多重配置します。 レプリカの中で、マスタのデータをオーナ、複製したデータをバックアップと呼びます。 クラスタを構成するいずれかのノードに障害が発生した場合でも、レプリカを使用することで処理を継続できます。 ノード障害発生後のデータ再配置もシステムが自動的に行うため(自律的データ配置）、特別な運用操作は不要です。 障害対象のノードに配置されていたデータはレプリカから復旧され、自動的に設定されたレプリカ数となるようにデータは再配置されます。

レプリカ
レプリカ

レプリカは、パーティション単位で作成します。クラスタにノード増設/削除を行った場合は、パーティションを自動で再割り当て・再配置することにより、各ノードにレプリカを分散配置します。

　 　　

— 物理設計 —

システムの非機能要求を実装するために必要なGridDBの設計項目について説明します。

設計のポイント

システムで実現すべき非機能要求として、IPAにより「非機能要求グレード」が定義されています。以下にその一部を引用します。

非機能要求グレード2018 利用ガイド[解説編]　「非機能要求グレードの6大項目」より 　　(c)2010-2018 独立行政法人情報処理推進機構

非機能要求 大項目 要求の例 実現方法の例
可用性 ・運用スケジュール(稼働時間・停止予定など)
・障害、災害時における稼働目標		 ・機器の冗長化やバックアップセンターの設置
・復旧・回復方法および体制の確立
性能・拡張性 ・業務量および今後の増加見積り
・システム化対象業務の特性(ピーク時、通常時、縮退時など)		 ・性能目標値を意識したサイジング
・将来へ向けた機器・ネットワークなどのサイズと配置＝キャパシティ・プランニング
運用・保守性 ・運用中に求められるシステム稼働レベル
・問題発生時の対応レベル		 ・監視手段およびバックアップ方法の確立
・問題発生時の役割分担、体制、訓練、マニュアルの整備
移行性 ・新システムへの移行期間および移行方法
・移行対象資産の種類および移行量		 ・移行スケジュール立案、移行ツール開発
・移行体制の確立、移行リハーサルの実施
セキュリティ ・利用制限
・不正アクセスの防止		 ・アクセス制限、データの秘匿
・不正の追跡、監視、検知
・運用員などへの情報セキュリティ教育

これらの非機能要求を満たすために必要なGridDBの設計項目は、以下になります。

設計内容は、システム要件のレベルや内容によって大きく変わりますが、GridDBの特徴である可用性および性能・拡張性を生かすために考慮すべき設計ポイントを中心に説明します。

　

データ領域の設計

GridDBのデータは、ブロック、コンテナ、テーブル、ロウ、パーティションという単位でデータ管理されています。これらのデータ領域の設計は、可用性および性能・拡張性を決める重要な要因となります。

パーティション
パーティション
処理スレッドとパーティション、データベースファイルの関係
処理スレッドとパーティション、データベースファイルの関係

　

[メモ]

　

下記項目の設計ポイントについてまとめます。

　

ブロックサイズ

ブロックとは、コンテナのロウデータやメタ情報などを格納するための物理的なデータ単位であり、GridDBのディスクI/Oの最小単位です。

ブロック
ブロック

ブロックのサイズは64KB、1MB、4MB、8MB、16MB、32MBから選択します。デフォルトは64KBで、通常はデフォルト値のままで変更不要です。

ただし、ブロックサイズにより、コンテナのカラム数の上限値が異なります。 ブロックサイズ64KBの場合のカラム数の上限値より多くのカラムを作成する場合は、ブロックサイズを変更してください。 上限値の詳細は『GridDB 機能リファレンス』の「システムの制限値」をご参照ください。

■ブロックに格納するデータ

ブロックに格納するデータは、ロウのデータやコンテナのメタ情報、索引データなどの種類があります。データの種類ごとに分類してブロックに格納します。

ブロック種別 説明
metaData コンテナのメタ情報を格納するブロック
rowData コンテナ(期限解放設定なし)のロウのデータを格納するブロック
mapData コンテナ(期限解放設定なし)の索引のデータを格納するブロック
batchFreeRowData コンテナ(期限解放設定あり)のロウのデータを格納するブロック
batchFreeMapData コンテナ(期限解放設定あり)の索引のデータを格納するブロック

また、ひとつのブロックには、複数のコンテナのデータを格納します。アプリケーションから登録・更新された順にブロックに格納します。 時間または種類が近いデータをまとめてブロックに格納することで、データが局所化してメモリ効率が向上します。期間を条件とするような時系列データの検索処理を、少ないリソースで高速に行えます。

関連するパラメータ

[メモ]

パーティション数

クラスタ上のデータ管理の仕組みとして、コンテナをパーティションと呼ぶデータの入れ物で管理します。

ひとつのノードが管理するパーティション・スレッド・ファイルの関係
ひとつのノードが管理するパーティション・スレッド・ファイルの関係

パーティション数のデフォルトは128です。通常はデフォルト値のままで変更不要ですが、以下の条件式を満たさない場合はパーティション数を増やす必要があります。

パーティション数 >= トランザクションサービスの並列度 × クラスタの構成ノード数

関連するパラメータ

[メモ]

　

処理スレッド数

GridDBノードは1つのプロセスから構成されています。プロセス内にはさまざまな処理を行うスレッド（サービスと呼びます）が複数存在します。

ここでは、サービスの中で「トランザクションサービス」と「SQLサービス」の並列度を決定します。

サービスの構成
サービスの構成
スレッド名称 スレッド数
(デフォルト)		 スレッドの処理内容
トランザクションサービス 4　(設定可) ロウの登録、検索処理などのトランザクション処理や、データベースファイル書き込み処理などを行う
チェックポイントサービス 1　 チェックポイント処理を行う
クラスタサービス 1 ハートビートや、ノードの参加・離脱などのクラスタ構成処理を行う
シンクサービス 1 パーティション再配置の際にデータ同期のための長期同期、短期同期処理を行う
システムサービス 1 運用管理操作の要求を受け付ける
SQLサービス 4　(設定可) SQL処理を行う

各サービスが行う処理を「イベント」と言います。サービスはひとつのイベントキューを持ち、イベントキューに登録されたイベントを順次処理します。他のサービスに処理を依頼する時には、そのサービスが持つイベントキューにイベントを登録します。

サービスが処理するイベント
サービスが処理するイベント

[メモ]

　

検索や登録の並列性能に特に影響するスレッドは、トランザクション処理を行うスレッド(トランザクションサービス)とSQLの処理を行うスレッド(SQLサービス)です。 ノードを稼動するマシンのCPUコア数に合わせて、これらの処理スレッドの並列度(concurrency)を設定します。

並列度設定の目安は以下になります。

[メモ]

関連するパラメータ

[メモ]

　

チェックポイント処理

チェックポイント処理は、データベースバッファ上の更新されたブロックをデータファイル、チェックポイントログファイルに書き込む処理です。

チェックポイント実行周期をパラメータで設定できます。通常は、パラメータはデフォルト値のままで変更は不要です。

チェックポイント処理の実行
チェックポイント処理の実行

また、チェックポイント実行時、チェックポイントログファイルへブロック管理情報を分割で書き込みます。この分割数はパラメータで設定できますが、通常はデフォルト値のままで変更は不要です。設定値を大きくすることで、チェックポイントログファイルへの1回の書き込み量を減少させることができますが、ノード起動時のリカバリ時間が増える可能性があります。

チェックポイント処理は、以下のタイミングで実行されます。

タイミング 内容
定期 一定周期で自動的に実行する(周期はパラメータで指定。定期実行を一時的に無効に設定することもできる)
手動 ユーザがgs_checkpointコマンドを実行した時に実行する
ノード起動/停止 ノード起動時のリカバリ処理の後、およびノードの通常停止の時に自動的に実行する
長期同期開始/終了 長期同期処理を開始/終了する時に自動的に実行する

データファイルの圧縮を指定することもできます。データファイルを圧縮することで、データ量に伴って増加するストレージコストを削減できます。 データ圧縮の機能の詳細については『GridDB 機能リファレンス』の「データブロック圧縮」をご参照ください。

関連するパラメータ

[メモ]

　 　　　

ファイル構成

GridDBノードが稼働中に作成および出力するファイルには、データベースファイルやバックアップファイルなどの種類があります。

データベースファイルおよびバックアップファイルは、ファイルサイズが大きくなることやディスクI/Oが性能に大きく影響することから、ストレージの容量やI/O性能を考慮して適切な配置ディレクトリを指定してください。

データベースファイルとその他の出力ファイル
データベースファイルとその他の出力ファイル

配置ディレクトリは、デフォルトではGridDBホームディレクトリ(/var/lib/gridstore)下のディレクトリになります。

出力ファイル一覧

関連するパラメータ

[メモ]

メモリ領域の設計

GridDBは、メモリとディスクの両方を用いるハイブリッド方式のデータベースです。 メモリをデータのキャッシュとして用いてアクセスを高速化し、データをディスクに格納して大容量データの管理を実現しています。

下図のように、メモリのサイズが大きい方がより多くのデータがメモリ上にキャッシュされるため、ディスクI/Oが減って性能が向上します。 メモリサイズの大きさはGridDBの性能に大きく影響するため、システムの性能要件やデータ量を考慮して設計を行います。

メモリとディスクの併用
メモリとディスクの併用

　

GridDBノードには、用途に応じて様々なバッファやメモリエリアがあります。主なメモリは以下の通りです。

メモリ
メモリ
名称 内容
データベースバッファ 読み込んだデータをキャッシュするためのI/Oバッファです。
データファイルから読み込んだデータイメージ（ブロック）をメモリ上にキャッシュします。データベースバッファのサイズが大きい程、ブロックがメモリ上にキャッシュされやすくなるため検索および登録性能が向上します。
ノード上にデータベースバッファの領域はひとつで、複数のトランザクション処理スレッドが共有して使用します。
トランザクション処理用メモリエリア ロウの登録や検索処理などを行うトランザクション処理スレッドが使用する領域です。
SQL中間結果格納バッファ SQL処理中の中間結果を格納するための領域です。
中間結果がバッファのメモリサイズ上限を超える場合は、一時的にSQL中間結果用スワップファイルに書き出します。
SQLワークメモリエリア SQL処理において、ジョインや集計などの途中結果を一時的に格納するための領域です。

　

メモリ領域の設計では、各メモリ領域の上限サイズや関連するパラメータの値を設計する必要があります。 特にポイントとなるのが「データベースバッファ」と「SQL処理用メモリエリア」のメモリサイズです。

メモリ
メモリ

システムの性能に最も影響がでるのは「データベースバッファ」のサイズです。 物理メモリの容量に余裕があれば、このバッファに出来るだけ多くサイズを割り当てることを推奨します。

SQL処理用メモリバッファのサイズについては、システムで使用する代表的なSQLクエリで評価を実施して、メモリサイズを設定してください。

　

下記項目の設計ポイントについてまとめます。

　

データベースバッファ

データファイルから読み込んだブロックをメモリ上にキャッシュするための領域です。

データベースバッファのサイズが大きい程、データのブロックがメモリ上にあるため、検索および登録性能が向上します。

バッファのサイズ上限値は、ノード定義ファイルで指定します。 バッファの空きが無くなった時は、LRUで古いブロックをデータファイルに書き出して空き領域を作り、ファイルから残りのブロックを読み込みます。ファイルからの読み込み/ファイルへの書き込み処理をスワップ処理と呼びます。 もし、ブロックが使用中で書き出せずに空き領域を作れない場合は、バッファサイズを一時的に拡張します。処理が終了して領域が不要になると、サイズ上限値まで縮小します。

バッファの内部は、パーティション単位で分割して使用します。パーティションごとのサイズは、データ量やアクセス状況に応じてノードが動的に決定します。

データベースバッファ
データベースバッファ

ノード起動直後は、データベースバッファに何もブロックが読み込まれていないため、起動直後の検索や登録処理では頻繁にブロックの読込みによるスワップ処理が発生して性能が遅くなる場合があります。

関連するパラメータ

関連する情報の確認方法

トランザクション処理用メモリエリア

ロウの登録や検索処理などを行うトランザクションサービスが使用するメモリエリアです。各トランザクションサービスは、処理に必要なサイズ分のメモリをメモリエリアから確保して使用します。1回のトランザクション処理が終了すると、確保していたメモリをメモリエリアに戻します。

トランザクションサービスの数（並列度）の値は、/dataStore/concurrency(デフォルト4)になります。

トランザクション処理用メモリエリア
トランザクション処理用メモリエリア

メモリエリア上のメモリが全て使用中で、トランザクションサービスに必要なメモリを確保できない時はエラーになります。

トランザクションサービスでは、TQLでの数千万ヒットのクエリを実行、巨大なサイズのBLOBの登録、MultiPutによる巨大なサイズのデータの一括登録などの処理でメモリを多く使う場合があります。 トランザクションの処理内容や、トランザクションサービスの数(並列度/dataStore/concurrency)に応じて、メモリエリアのサイズ上限値を設定する必要があります。

関連するパラメータ

関連する情報の確認方法

　

SQL処理用メモリエリア

SQL処理用のメモリエリアには、SQL中間結果格納バッファとSQLワークメモリエリアがあります。

SQL中間結果格納バッファは、SQL処理におけるスキャンやジョインなどのタスクの中間結果のテーブルのデータを格納するためのメモリです。 中間結果がバッファのメモリサイズ上限を超える場合は、一時的にSQL中間結果用スワップファイルに書き出します。

SQLを利用した大量データに対する分析クエリを実行する場合は、データベースバッファとのバランスを考慮しながらできるだけ値を大きくすることを推奨します。

SQLワークメモリは、SQL処理におけるタスクの処理で使用するメモリです。ワークメモリについては、デフォルト値を変更する必要はありません。

ただし、中間結果格納バッファとワークメモリのサイズは、次の式を満たすように設定してください。

満たさない場合は、中間結果用スワップファイルへの書き出しが頻発してしまいます。

関連するパラメータ

関連する情報の確認方法

　

その他のメモリ

コンテナ、データファイル管理情報保持用メモリ

処理用のバッファ以外にも、コンテナやファイルの管理情報を保持するためにメモリを使用します。次の2つのメモリのサイズは、それぞれコンテナ数とデータ容量に比例して大きくなります。

　

コンテナ設計

コンテナの最適な設計はシステムやアプリケーションの要件によって大きく異なります。 本節ではコンテナ設計の参考になる基本的なポイントを説明し、関連する情報を示します。

推奨する設計

日々生成されるデータは時系列コンテナに格納

コンテナの種別にはコレクションと時系列コンテナの2つがあります。

まずは、格納するデータに対して時系列コンテナが利用できるかを検討し、 時系列コンテナが利用できない場合にのみコレクションの利用を検討します。

IoTシステムのように機器のセンサデータやログが時々刻々生成され、増加していく 場合は、時系列コンテナを使いましょう。時系列コンテナは時系列データの格納と 参照に対して最適化されているため、データベースバッファの利用効率がコレクションを 利用したときと比べて高くなります。

また、時系列コンテナには、時系列データ特有の演算機能があります。この機能への理解を深めると、コンテナ設計に役立ちます。

[参考]

コンテナは少数より多数

1つのコンテナに対する処理は、1台のノードの1つの処理スレッドで行われます。そのため、 少数のコンテナにそれぞれ大量のデータを格納するようなコンテナ設計を行うと、ノードの 処理並列度(マルチコア)が活かせません。また、特定のノードにアクセスが集中することにも 繋がるため、ノードを増設した場合に性能がスケールアウトしません。

例えば、時系列データの場合は、次のようにデータソースごとに時系列コンテナを作成します。

また、同種のデータであっても、クラスタのノード数 * ノードあたりの処理並列度を目安とした 複数のコンテナに分割することを推奨します。

複数のコンテナの操作を直列に実行してしまうと、性能の低下に繋がります。 分割したコンテナは一括処理機能を使ってなるべく並列に処理しましょう。

[参考]

データに合った方法でコンテナを分割する

コンテナを分割する方法は3つあります。

検索の条件やデータの特徴に合わせて、適切な分割方法を選択しましょう。

[参考]

最小限の索引が最大限の性能を引き出す

システムのデータ検索条件に合わせて適切に索引を作成することで、検索性能を 向上させることができます。1つのコンテナには複数の索引を作成することが できますが、必要最低限としなければなりません。

なぜなら、索引のデータがデータベースバッファを圧迫するためです。 メモリサイズが潤沢ではないシステムにおいて、余分な索引をつけてしまうと、 バッファヒット率が下がってスワップ処理が多くなり、性能低下に繋がります。

必要のない索引を後から削除することもできますが、対象のコンテナに大量の ロウが既に格納されている場合、削除完了までに長い時間を要することがあります。 そのため、あらかじめ十分に設計し、必要な索引のみを作成するようにしましょう。

主キーによる検索のみでデータの絞り込みを行えるようにコンテナを設計すると、 自然と最小限の索引になります。また、そのような設計を行った場合、自ずと コンテナを分割することになるため、各ノードの処理並列度を活かせるように なります。

また、効果的な索引を作成するには、SQLの最適化 ルールを参考にしてください。

[参考]

　

クラスタ構成設計

クラスタ構成設計では、システムの稼働率やRTOなどの可用性の要件に合わせて、以下の項目を設計する必要があります。

GridDBは、複数のノード（サーバプロセス）で構成されたクラスタ上に、レプリカ（データ）を自律的に配置し、クラスタ全体の管理を行うマスタノードを自動的に決定します。ノードに障害が発生しても、フェイルオーバによってクライアントアプリケーション(NoSQLインタフェース)からの処理を継続することができます。

フェイルオーバ
フェイルオーバ

　　

クラスタ構成ノード数

クラスタを構成するノードの台数によって、何台まで同時にノード障害が発生してもクラスタのサービスが継続できるかが異なります。

システムの稼動率を満たすために、同時にダウンするノードは何台まで許容できるかでクラスタを構成するノード数を決めます。

[メモ]

また、ノードがダウンした場合には、自動的に以下の復旧処理を行います。

パーティション（レプリカ）再配置は、ノードダウンによるクラスタ縮退だけでなく、クラスタ拡張時にも発生します。

再配置を行う際にバックアップのデータがオーナよりも古い場合、クラスタは差分のデータをバックアップノードへ転送してオーナとバックアップの同期をとります。

クラスタ再構成における同期処理
クラスタ再構成における同期処理

上記の同期処理は、サーバが自動で行うため、設計が必要な項目はありません。

　

障害検知（ハートビート）

クラスタは、ノード間のハートビートによって、障害を検知します。 ノードの生存を確認するために、マスタは一定周期で全フォロワにハートビートを送信します。 ハートビートを受信したフォロワは、応答をマスタに返します。

ハートビート
ハートビート

また、フォロワはマスタからのハートビートが届いていることを確認するために、ハートビートの受信時間を一定周期で確認します。

ハートビートでは、マスタとフォロワ間で最新のデータを反映するために、構成ノード情報やパーティション情報管理テーブルの情報も一緒にやり取りします。

一定周期の時間は、マスタとフォロワともにデフォルト5秒(gs_cluster.jsonの/cluster/heartbeatIntervalの値)です。

関連するパラメータ

レプリカ処理（レプリカ数、処理モード）

GridDBでは、データの可用性のために、レプリカを作成して複数ノードで分散して保持します。これにより、ノード障害が発生した場合でも残りのノード上のレプリカを使ってデータへのアクセスを継続することができます。

以下に、レプリカ、レプリカを作成するレプリケーション、および障害からレプリカを復旧する同期処理の仕組みの設計ポイントについて説明します。

　

レプリカ

レプリカは以下のような特徴を持ちます。

レプリカ数はシステムの稼動率として、何台のノードの多重障害までデータアクセスを保証するべきかによって決めます。

多重障害とは、複数のノードで障害が発生して一度にダウンすることです。

レプリカ数3で多重障害のノード2台の場合
レプリカ数3で多重障害のノード2台の場合
レプリカ数3で多重障害のノード3台の場合
レプリカ数3で多重障害のノード3台の場合

レプリカ数を増やすと可用性は上がりますが、以下のような影響があります。

レプリカ数の目安は以下になります。

　

関連するパラメータ

[メモ]

　

レプリケーション処理

データの登録や削除などのトランザクション処理で更新したデータは、ディスクに書き込んで永続化することでノード障害発生時などのデータ欠損から保護します。 また、更新したデータをバックアップのノードにレプリケーションで転送して複製することで可用性を高めます。

トランザクションログの書き込みとレプリケーション
トランザクションログの書き込みとレプリケーション

トランザクション処理におけるログファイルへの書き込みやレプリケーションには同期や非同期のモードがあり、システムの可用性や性能要件に応じて選択します。

以下に、トランザクションログとレプリケーションのモードの組合せと、それぞれの処理の流れや性能などを説明します。

モードの
組合せ		 処理の流れ 性能 アプリケーションにトランザクション処理の完了を通知した時点のデータの状態
[1]
ログ:
非同期(1秒)

レプリケーション:
非同期

(デフォルト値)		 ログ非同期とレプリケーション非同期 高速 ・1秒以内に更新データをフラッシュする

・バックアップノードにデータ転送(受信は未確認)
[2]
ログ:
非同期(1秒)

レプリケーション:
準同期		 ログ非同期とレプリケーション準同期 やや高速 ・1秒以内に更新データをフラッシュする

・バックアップノードにデータ転送完了
[3]
ログ:
同期

レプリケーション:
非同期		 ログ同期とレプリケーション非同期 やや低速 ・更新データをフラッシュ完了

・バックアップノードにデータ転送(受信は未確認)
[4]
ログ:
同期

レプリケーション:
準同期		 ログ同期とレプリケーション準同期 低速 ・更新データをフラッシュ完了

・バックアップノードにデータ転送完了

トランザクションログの書き込みモード・レプリケーションモード設定の目安は以下になります。

関連するパラメータ

[メモ]

　

クライアントフェイルオーバタイムアウト

ノード障害が発生しても、ノードやクライアントAPI(NoSQLインタフェース)のフェイルオーバ機能により、アプリケーションは継続してデータにアクセスすることができます。

ノード障害が発生した時のフェイルオーバの仕組みを、障害発生から復旧までの流れに沿って詳細に説明します。

流れ 図 説明
(1)クライアントの処理要求 <p>障害発生時のフェイルオーバの流れ1</p> ①クライアントは、クライアントAPIを用いて、コンテナに対する操作を要求します。
クライアントAPIは、操作対象のコンテナAを格納しているノード1に接続して操作を行います。
(2)障害発生 <p>障害発生時のフェイルオーバの流れ2</p> ②クライアントからの要求処理中に、ノード1で障害が発生してダウンします。
(3)自動復旧1 <p>障害発生時のフェイルオーバの流れ3</p> ③クライアントAPIは、ノード1との接続が切れたため、自動的に処理をリトライします。

④クラスタは、ノード1がダウンしたことを自動的に検知して、残りのノードでクラスタを再構成します。
(4)自動復旧2 <p>障害発生時のフェイルオーバの流れ4</p> ⑤クラスタは、ノード1上のオーナの代わりとして、ノード2のバックアップをオーナに変更します。
バックグラウンドで別のノードにバックアップを作成します。
(5)処理継続 <p>障害発生時のフェイルオーバの流れ5</p> ⑥クライアントAPIは、新たにコンテナAのオーナとなったノード2に接続して、自動的に処理をリトライします。

クライアントは処理を継続でき、エラーは発生しません。

クライアントAPIがアクセスしているパーティションのノードに障害が発生した場合、クライアントAPIは処理を自動的にリトライします。 リトライしている間に、クラスタの自律的データ配置によってパーティションが復旧した場合、クライアントAPIは自動的に処理を継続します。 リトライする時間「フェイルオーバタイムアウト」は、アプリケーションの接続処理のプロパティで変更することができます。

[メモ]

関連するパラメータ

　

ネットワーク設計

GridDBでは、ノードとクラスタ２種類のネットワークを設計する必要があります。

　

ノードのネットワーク構成

GridDBノードは、クライアントや他のノードと様々なネットワーク通信を行います。その通信経路には、以下のような種類があります。

ノードに対する通信
ノードに対する通信
No. 項目 通信経路 説明
A トランザクション処理 ・クライアント-ノード
・ノード間		 ・NoSQLインタフェースを通じたデータ操作のための通信
・トランザクションのレプリケーション処理のための通信
B SQL処理 ・クライアント-ノード
・ノード間		 ・NewSQLインタフェースを通じたデータ操作のための通信
・SQLの並列分散処理のための通信
C 運用管理操作 クライアント-ノード 運用管理の操作要求を受け付けるための通信
D クラスタ管理 ノード間 ノードの生存を確認するためのハートビートやクラスタ管理情報を授受するための通信
E 同期処理 ノード間 パーティションの再配置によるデータ同期処理のための通信

GridDBの主な運用ツールはこれらの通信を使用します。

運用ツールの使用するネットワーク通信
運用ツールの使用するネットワーク通信
運用ツール 使用する通信
統合運用管理GUI(gs_admin) A. トランザクション処理
B. SQL処理
C. 運用管理操作
インタプリタ(gs_sh) A. トランザクション処理
B. SQL処理
C. 運用管理操作
運用コマンド(gs_joincluster,gs_statなど) C. 運用管理操作
エクスポート/インポートツール(gs_export,gs_import) A. トランザクション処理
B. SQL処理

[メモ]

関連するパラメータ

[メモ]

また、TQLやSQLによるデータ操作では、NoSQL/NewSQLインタフェースを通じてクラスタに接続して処理を行いますが、SQLによるデータ操作はノード間での分散処理を行うため、ノード間の通信量が多くなります。

NoSQL/NewSQLインタフェースを用いてデータ操作を行った時の通信の流れ
NoSQL/NewSQLインタフェースを用いてデータ操作を行った時の通信の流れ

ノードのネットワークに関して設計すべき点は、ポート番号、帯域幅です。それぞれの設計のポイントについて説明します。 　

　

ポート番号

GridDBのノードが使用するポート番号には次の種類があります。

デフォルトでは以下の番号を使用します。もし他のアプリケーションなどで既に使用済みの場合は、デフォルトのポート番号を変更する必要があります。

ネットワーク通信
ネットワーク通信
No 項目 内容 ポート番号
A トランザクション処理 トランザクション処理を行うための通信用ポート 10001
B SQL処理 SQL処理を行うための通信用ポート 20001
C 運用管理操作 運用管理の操作要求を受け付けるための通信用ポート 10040
D クラスタ管理 ノードの生存を確認するためのハートビートやクラスタ管理情報を授受するための通信用ポート 10010
E 同期処理 パーティション再配置によるデータ同期処理のための通信用ポート 10020

接続方式としてマルチキャスト方式を使用する場合には、以下の3つのポート番号も使用します。

No 項目 ポート番号
F トランザクション処理用マルチキャスト 31999
G SQL処理用マルチキャスト 41999
H クラスタ管理用マルチキャスト 20000

　

帯域幅

GridDBでは多くのデータを通信するため、ネットワークの帯域は10GbEの利用を推奨します。

特にデータ量が多くなる通信経路は以下の3箇所です。

データ量が多いネットワーク通信
データ量が多いネットワーク通信

　

データ通信量が多くネットワーク帯域が不足する場合には、複数のNICを用いて帯域を増やすことを推奨します。

例) 通常の場合

例) 通信量の多い場合

　

クラスタのネットワーク構成

ノード間でクラスタを構成し、クライアントと通信する方法として、マルチキャスト方式、固定リスト方式、プロバイダ方式の3つの接続方式があります。 各接続方式のメリット・デメリットを説明します。ネットワーク環境に合わせて、いずれかひとつの接続方式を選択します。

接続方式
接続方式

　

方式名 内容 設定・構築 ノード増設時の停止 ネットワーク環境
マルチキャスト方式 マルチキャスト通信を行う。 ○
定義ファイルの記述が容易		 ○
クラスタ停止不要		 ×
全ノードとクライアントを同一サブネットに配置しないと通信できない
固定リスト方式 全ノードのアドレス一覧をクライアントとノードに設定する。
アドレス一覧を基にユニキャスト通信を行う。		 ×
定義ファイルの記述が複雑		 ×
クラスタ停止が必要		 ○
環境の制約はない
プロバイダ方式 全ノードのアドレス一覧をプロバイダに設定する。
クライアントとノードはプロバイダからアドレス一覧を取得してユニキャスト通信を行う。		 ×
プロバイダの構築作業が必要		 ○クラスタ停止不要 ○
環境の制約はない

マルチキャスト通信が使用できる環境では、マルチキャスト方式を推奨します。(接続方式はクラスタ定義ファイルで指定します。デフォルトではマルチキャスト方式が設定されています。)

ただしマルチキャスト方式の場合は、ネットワーク環境に制約があるため注意が必要です。

マルチキャスト方式では、マルチキャスト通信の制限のため、クライアントとすべてのノードを同一サブネットに配置する必要があります。もし別のサブネットに存在している場合は、マルチキャスト通信できないため、ネットワーク上の全ルータでマルチキャストルーティングの設定を行う必要があります。

マルチキャスト方式
マルチキャスト方式

また、AWSなどのクラウド上ではマルチキャスト通信が使用できない場合があります。これらのマルチキャスト通信を使用できないケースでは、固定リスト方式またはプロバイダ方式を選択してください。

固定リスト方式とプロバイダ方式を比較した場合、設定や環境構築の面では固定リスト方式の方が容易です。プロバイダ方式では、アドレス一覧を提供するWebサービスを構築する必要があります。

一方、ノード増設に強いのはプロバイダ方式です。プロバイダが持つアドレス一覧の情報を変更すれば良いので、クラスタの停止は必要ありません。固定リスト方式の場合は、クラスタ定義ファイルを書き換え る必要があるのでクラスタ停止が必要です。クライアント側の接続用APIの指定も変更する必要があります。 よって、ノードの増設が見込まれるシステムの場合は、プロバイダ方式を推奨します。

[メモ]

各接続方式の詳細について、以下にまとめます。

　

マルチキャスト方式

マルチキャスト方式は、通信にマルチキャストを使用する方式です。マルチキャストとは、ひとつの送信元から、特定の複数の送信先に、同じデータを同時に送る通信のことです。

マルチキャスト方式
マルチキャスト方式

マルチキャスト方式を使用する場合は、クライアントとクラスタの全ノードをすべて同じサブネットに配置してください。もし別のサブネットに存在している場合は、そのままではマルチキャスト通信はできませんので、ネットワーク上の全ルータでマルチキャストルーティングの設定を行う必要があります。

マルチキャスト方式の場合、ノードはネットワークをポーリングして、マルチキャスト通信で一定周期で送信されたデータを受信します。即時受信しないので、通信開始までに一定周期分の時間が最大かかります。この周期の時間はクラスタ定義ファイルで指定できます。

関連するパラメータ

[メモ]

　

固定リスト方式

固定リスト方式は、クラスタの全ノードのIPアドレスを、クライアントと各ノードに明示的に指定する方式です。アドレス一覧を基にユニキャスト通信を行います。

固定リスト方式
固定リスト方式

　

関連するパラメータ

[メモ]

　　

プロバイダ方式

プロバイダ方式は、クラスタの全ノードのIPアドレス一覧を配信するWebサービスを設置する方式です。クライアントや各ノードは、まずプロバイダにアクセスして、クラスタの全ノードのIPアドレスを取得します。

プロバイダ方式
プロバイダ方式

ノードは、起動時にプロバイダからアドレス一覧を取得します。その後も一定周期でプロバイダから最新のアドレス一覧を取得します。そのため、ノード増設などの場合はプロバイダのアドレス一覧を変更すれば、自動的にノードに情報が反映されます。

　

関連するパラメータ

[メモ]

　

外部と内部の通信を分離するネットワーク構成

目的

GridDBノードが行う通信のうち、トランザクション処理とSQL処理の通信は、それぞれ2種類の通信経路を持ちます。 その2種類とは、クライアント-ノード間のクライアント通信(外部通信)と、ノード間のクラスタ内部通信です。 その両方が同じネットワークインタフェースを介して通信を行います。

システムの規模が大きくなると、外部通信、内部通信共に流量が多くなり、ネットワークが性能のボトルネックになり得ます。

また、システムの構成上、クライアント通信のインタフェースを外部ネットワークに、クラスタ内部通信のインタフェースを 内部ネットワークにそれぞれ分離しなければならない場合もあります。

GridDBでは、それらのケースに対応するため、トランザクション処理とSQL処理の通信それぞれに対して、クライアント通信用の ネットワークインタフェースとクラスタ内部通信用のネットワークインタフェースを割り当てることが可能です。これにより、 外部と内部の通信を分離するネットワーク構成にできます。

ネットワークインタフェースの分離
ネットワークインタフェースの分離
No. 項目 通信経路 説明
A トランザクション処理 クライアント-ノード間 NoSQLインタフェースを通じたデータ操作のための外部通信
A’ トランザクション処理 ノード間 トランザクションのレプリケーション処理のための内部通信
B SQL処理 クライアント-ノード間 NewSQLインタフェースを通じたデータ操作のための外部通信
B’ SQL処理 ノード間 SQLの並列分散処理のための内部通信

ノードのネットワーク構成

外部と内部の通信を分離するネットワーク構成にするには、最初にノードのネットワーク構成を設定します。

関連するパラメータ

[メモ]

serviceAddressとlocalServiceAddressにそれぞれ異なるネットワークインタフェースのIPアドレスを指定します。 複数のノードでクラスタを構成する場合は、すべてのノードの設定が必要です。

また、トランザクション処理用、SQL処理用以外のserviceAddressも省略せずに設定することを推奨します。

例)

"cluster":{
    "serviceAddress":"192.168.10.11",
    "servicePort":10010
},
"sync":{
    "serviceAddress":"192.168.10.11",
    "servicePort":10020
},
"system":{
    "serviceAddress":"192.168.10.11",
    "servicePort":10040,
          :
},
"transaction":{
    "serviceAddress":"172.17.0.11",
    "localServiceAddress":"192.168.10.11",
    "servicePort":10001,
          :
},
"sql":{
    "serviceAddress":"172.17.0.11",
    "localServiceAddress":"192.168.10.11",
    "servicePort":20001,
          :
},

クラスタのネットワーク構成

ノードのネットワーク構成に合わせて、クラスタのネットワーク構成を設定します。

マルチキャスト方式の場合、特別な設定は不要です。マルチキャスト形式を参照ください。

固定リスト形式の場合、クラスタ定義ファイルに設定するアドレス一覧にlocalServiceAddressの情報を追加する 必要があります。

例)

"notificationMember": [
    {
        "cluster":           {"address":"192.168.10.11", "port":10010},
        "sync":              {"address":"192.168.10.11", "port":10020},
        "system":            {"address":"192.168.10.11", "port":10040},
        "transaction":       {"address":"172.17.0.11", "port":10001},
        "sql":               {"address":"172.17.0.11", "port":20001},
        "transactionLocal":  {"address":"192.168.10.11", "port":10001},
        "sqlLocal":          {"address":"192.168.10.11", "port":20001}
    },
    {
        "cluster":           {"address":"192.168.10.12", "port":10010},
        "sync":              {"address":"192.168.10.12", "port":10020},
        "system":            {"address":"192.168.10.12", "port":10040},
        "transaction":       {"address":"172.17.0.12", "port":10001},
        "sql":               {"address":"172.17.0.12", "port":20001},
        "transactionLocal":  {"address":"192.168.10.12", "port":10001},
        "sqlLocal":          {"address":"192.168.10.12", "port":20001}
    },
          :
          :

プロバイダ形式の場合、プロバイダから返却するアドレス一覧にlocalServiceAddressの情報を追加する 必要があります。

例)

[
    {
        "cluster":           {"address":"192.168.10.11", "port":10010},
        "sync":              {"address":"192.168.10.11", "port":10020},
        "system":            {"address":"192.168.10.11", "port":10040},
        "transaction":       {"address":"172.17.0.11", "port":10001},
        "sql":               {"address":"172.17.0.11", "port":20001},
        "transactionLocal":  {"address":"192.168.10.11", "port":10001},
        "sqlLocal":          {"address":"192.168.10.11", "port":20001}
    },
    {
        "cluster":           {"address":"192.168.10.12", "port":10010},
        "sync":              {"address":"192.168.10.12", "port":10020},
        "system":            {"address":"192.168.10.12", "port":10040},
        "transaction":       {"address":"172.17.0.12", "port":10001},
        "sql":               {"address":"172.17.0.12", "port":20001},
        "transactionLocal":  {"address":"192.168.10.12", "port":10001},
        "sqlLocal":          {"address":"192.168.10.12", "port":20001}
    },
          :
          :

なお、クライアントからの接続は、通常のネットワーク構成と同様に、serviceAddressに指定した ネットワークインタフェースを介して行います。

[注意]

セキュリティ設計

アクセス制御

セキュリティ設計では、アクセスするユーザ数やデータのアクセス範囲などの一般的なセキュリティ要件を検討した後、それに基づいて次の点を設計する必要があります。

　

GridDBでは、ユーザごとにデータにアクセスする範囲を分ける場合には、「データベース」機能を用いてアクセス範囲を分離することができます。

一般ユーザは複数のデータベースに対するアクセス権を持つことができますが、データベースをまたがったSQL検索(異なるデータベース上のコンテナのジョインなど)はできないため、 ひとりのユーザがアクセスするコンテナはなるべくひとつのデータベースにまとめることを推奨します。

データベースとSQL検索
データベースとSQL検索

ユーザの役割

ユーザ 役割
管理ユーザ データベース、一般ユーザを作成します。一般ユーザにデータベースへのアクセス権を付与します。
一般ユーザ アクセス権が付与されたデータベースにアクセスして、データ登録や検索などの操作を行います。

操作手順

一般ユーザとデータベースを作成して、アクセス権を付与する手順を説明します。ここでは「ALL」権限を付与するものとします。

  1. 管理ユーザでクラスタに接続します。
$ gs_sh
gs> setcluster cluster myCluster 239.0.0.1 31999 // 接続先のクラスタの情報を設定
gs> setuser admin admin       // 管理ユーザのユーザ名とパスワードを指定
gs> connect $cluster          // クラスタに接続
gs[public]>
  1. 一般ユーザを作成します。
gs[public]> createuser userA password
  1. データベースを作成します。
gs[public]> createdatabase databaseA
  1. 一般ユーザにデータベースへのアクセス権を付与します。
gs[public]> grantacl ALL databaseA userA

　

暗号化

GridDBでは、クライアントとGridDBクラスタ間の通信をSSLで保護することができます。詳細は『GridDB 機能リファレンス』を参照ください。

一方、データベースファイルに保存しているデータは暗号化していません。外部から直接アクセスできない安全なネットワーク上への配置を推奨します。

　

監視設計

GridDBクラスタの監視設計のポイントについて、以下にまとめます。GridDBの稼働状況やリソースの使用状況の確認は、パフォーマンスの最適化、障害発生の未然回避のために必要です。監視項目は、システムのサービスレベルにより異なります。

これらの監視項目は、以下のようにZabbixを使用して監視することもできます。

Zabbixのダッシュボード構成例
Zabbixのダッシュボード構成例

Zabbix用の監視テンプレートについては、『GridDB 監視テンプレートfor Zabbix 説明書』をご参照ください。

　

バックアップ設計

バックアップの目的

ハードウェアの多重障害やアプリケーションの誤動作によるデータ破壊に備えるために、バックアップを採取します。

設計のポイント

一般的に、バックアップ・リストア要件は、システムのサービスレベルより定義します。 検討項目は以下です。

GridDBでは、以下のバックアップ・リストア方式を提供します。上記で定義した要件を満たす方式を選択してください。

バックアップ方式 復旧時点 特徴 (○：メリット、×：デメリット)
クラスタ管理によるレプリカ自動作成 障害直前時点 ○：クラスタ設定でレプリカ数を指定すれば、クラスタがノード間で自動的にレプリカを作成、管理します。
×：レプリカ数以上HWが同時破損した場合、もしくは人的ミスが発生した場合には対応できません。
gs_exportツールによるデータのエクスポート データのエクスポート時点
※コンテナごと		 ○：必要なデータのみバックアップでき、バックアップサイズを小さくすることができます。
×：エクスポートツールを実行するため、運用中のクラスタに負荷をかける可能性があります。
×：データの復旧には、データの再インポートが必要です。
×：エクスポートはコンテナごとに処理するため、コンテナごとに復旧時点が異なる可能性があります。
オフラインバックアップ クラスタ停止時点 ○：ノード間で復旧時点が異なることはありません。
×：バックアップコピー完了までクラスタ停止が必要です。
ノードによるオンラインバックアップ（フル+差分・増分) バックアップ採取時点
※ノードごと		 ○：GridDBバックアップコマンドを利用して、オンラインでバックアップが取得できます。
×：バックアップの取得完了のタイミングにより、ノード間で復旧時点が異なることがあります。
ノードによるオンラインバックアップ（自動ログ） 障害直前時点 ○：GridDBバックアップコマンドを利用して、オンラインでバックアップが取得できます。また、障害直前時点まで復旧が可能です。
×：トランザクションログから最新状態にリカバリするため、リカバリ時間が長くなることがあります。
ファイルシステムレベルのオンラインバックアップ（スナップショット等） スナップショット取得時点 ○：OSのスナップショットやストレージのスナップショットと連携してバックアップを行うことでバックアップの実行時間を短くすることが可能です。
×：各ノードに対して同時にスナップショットを実行しても、トランザクションログの書き込みモードがDELAYED_SYNCの場合、ノード間で１秒程度ずれが発生する場合があります。
ファイルシステムレベルのオンラインバックアップ（スナップショット等+自動ログ） 障害直前の時点 ○：OSのスナップショットやストレージのスナップショットと連携してバックアップを行うことでバックアップの実行時間を短くすることが可能です。
×：トランザクションログから最新状態にリカバリするため、リカバリ時間が長くなることがあります。

　

バックアップ方式の選択の目安は以下になります。

バックアップの要件や用途 バックアップ方式
レプリカ数以上のHW同時破損もしくは人的ミスによるデータ損失を許容できる場合 クラスタ管理によるレプリカ自動作成
バックアップすべきデータを選択できる場合 gs_exportツールによるデータのエクスポート
バックアップ実行時に、システム停止可能な場合 オフラインバックアップ
バックアップ実行時に、システム停止できない場合 ノードによるオンラインバックアップ（＋自動ログバックアップ）
データベースファイルが巨大で、時間内にオンラインバックアップが終わらない場合 ファイルシステムレベルのオンラインバックアップ（スナップショット+自動ログ）

　

バックアップ・リストアの方法

各バックアップ方法について、バックアップやリストアにかかる時間やメリット・デメリットを説明します。 操作の詳細は『GridDB 機能リファレンス』を参照ください。

　

オフラインバックアップ

オフラインでバックアップを採取します。

クラスタと全ノードを停止して、OSのコマンドやストレージのスナップショットによってデータベースファイルをコピーします。全ノードでのコピー完了後に、ノードとクラスタを起動します。

オフラインバックアップ
オフラインバックアップ
   
メリット - クラスタを停止してからバックアップを採取するので、ノード間で復旧時点が同じになります。
- ノードを停止して採取したバックアップなので、リストアが高速です。
デメリット - クラスタ・ノードの停止が必要なので、サービスの稼動を停止できないシステムでは利用できません。
バックアップ時間 データベースファイルのコピー時間
復旧時点 クラスタ停止時点
リカバリ時間 バックアップファイルコピー時間

　

オンラインバックアップ

クラスタ稼動中に、オンラインで各ノードのバックアップを採取します。

オンラインバックアップは、バックアップファイルの作成方法で大きく2つの方法があります。

オンラインバックアップ
オンラインバックアップ

2つの方法の大きな違いは、次の点になります。

方法 復旧時点
ノードによるオンラインバックアップ ノードごとのバックアップ採取完了時点
→ノードごとにバックアップするデータ量が異なるので、完了時点が大きくずれる場合がある
ファイルシステムレベルのオンラインバックアップ ノードごとのスナップショット取得時点
→ノード間でスナップショット取得時間をそろえれば、復旧時点をほぼ同じにすることができる

　

ノードによるオンラインバックアップ

ノードによってオンラインバックアップを採取する方法を説明します。

フルバックアップ

データベース全体をバックアップします。

ノード単位でバックアップコマンドを用いてフルバックアップを指示すると、ノードがデータベースファイルのすべてのデータをコピーしてバックアップファイルを作成します。

   
メリット - 差分・増分バックアップよりもリストアが高速です。( リカバリ時間：フル < 差分 < 増分 )
- クラスタを稼動中にバックアップを採取できます。
デメリット - データベースファイルのすべてのデータをコピーするため、バックアップに時間がかかります。( バックアップ時間：増分 < 差分 < フル )
- 複数世代のバックアップを保管する場合、データベースファイルのサイズ×世代数のディスク容量が必要になります。
- 復旧時点はノードごとのバックアップ採取完了時点になるので、ノード間での復旧時点に差ができる場合があります。
バックアップ時間 ノードがバックアップファイルを作成する時間(データベースファイルのサイズに依存する)
復旧時点 ノードごとのバックアップ採取完了時点。
リカバリ時間 バックアップファイルコピー時間
差分バックアップ

基点となるフルバックアップ(ベースライン)を採取した後、ベースラインからの更新分のみをバックアップします。

ノード単位でバックアップコマンドを用いて差分バックアップを指示すると、ノードがベースラインからの更新データのみをコピーしてバックアップファイルを作成します。

   
メリット - フルバックアップよりはバックアップが高速です。( バックアップ時間：増分 < 差分 < フル )
- 増分バックアップよりもリカバリが高速です。( リカバリ時間：フル < 差分 < 増分 )
- クラスタを稼動中にバックアップを採取できます。
デメリット - 増分バックアップよりはバックアップに時間がかかります。
- 復旧時点はノードごとのバックアップ採取完了時点になるので、ノード間での復旧時点に差ができる場合があります。
バックアップ時間 ノードがバックアップファイルを作成する時間(ベースライン以降の更新データ量に依存する)
復旧時点 ノードごとのバックアップ採取完了時点
リカバリ時間 バックアップファイルコピー時間
差分のあるブロックのリカバリ時間
増分バックアップ

基点となるフルバックアップ(ベースライン)を採取した後、前回バックアップ時点からの更新分のみをバックアップします。前回バックアップ時点は、ベースライン、差分、増分のいずれかのバックアップを実行した時点を指します。

ノード単位でバックアップコマンドを用いて増分バックアップを指示すると、ノードが前回バックアップ時点からの更新データのみをコピーしてバックアップファイルを作成します。

   
メリット - フルバックアップや差分バックアップよりもバックアップが高速です。( バックアップ時間：増分 < 差分 < フル )
- クラスタを稼動中にバックアップを採取できます。
デメリット - ベースラインまたは差分バックアップ以降の増分バックアップをすべてリストアする必要があるため、フルバックアップや差分バックアップよりはリストアに時間がかかります。( リカバリ時間：フル < 差分 < 増分 )
- 復旧時点はノードごとのバックアップ採取完了時点になるので、ノード間での復旧時点に差ができる場合があります。
バックアップ時間 ノードがバックアップファイルを作成する時間(前回バックアップ時点以降の更新データ量に依存する)
復旧時点 ノードごとのバックアップ採取完了時点
リカバリ時間 バックアップファイルコピー時間
差分、増分ブロックリカバリ時間

　

自動ログバックアップ

基点となるフルバックアップ(ベースライン)を採取した後、トランザクションログをバックアップディレクトリに収集します。

   
メリット - 最新のトランザクションログがバックアップファイルに反映されるので、障害直前の状態までリストアすることができます。
デメリット - 通常運用中に自動的にトランザクションログをコピーするので、運用に多少の負荷がかかります。
- リストアに時間がかかります。
バックアップ時間 なし（ベースラインの作成後は自動的にログをコピーするので、バックアップを実行する必要はありません)
復旧時点 障害直前の時点
リカバリ時間 バックアップファイルコピー時間
トランザクションログに格納された更新ログのリカバリ時間

　

ファイルシステムレベルのオンラインバックアップ

ファイルシステムレベルのオンラインバックアップについて説明します。

LVMスナップショットやストレージのスナップショット機能を用いてオンラインバックアップを実行できます。 バックアップに要する時間を大幅に短縮できるほか、クラスタの各ノードの復旧時点を可能な限りそろえることができます。

データベースファイルが巨大な場合に、利用を検討してください。

   
メリット - LVMやストレージのスナップショット機能を利用して、巨大なデータベースファイルを高速に処理することができます。
- 自動ログバックアップと組合わせて、最新の状態まで戻すことも可能です。
デメリット - LVMやストレージのスナップショット機能が必要です。
- 各ノードに対して同時にスナップショットを実行しても、トランザクションログの書き込みモードがDELAYED_SYNCの場合、ノード間で１秒程度ずれが発生する場合があります。
バックアップ時間 なし
復旧時点 スナップショット取得時点
リカバリ時間 バックアップファイルコピー時間

　

— 構築 —

本章では、GridDBのインストールや環境設定方法、アンインストールの方法について説明します。

　

GridDBのメディア・RPMの構成

GridDBのインストールメディアには、以下のディレクトリ構成でファイルが格納されています。

   RHEL/          RHEL,CentOS用RPMパッケージ
   Ubuntu/        Ubuntu Server用debパッケージ
   Windows/       Windows用C-API, JDBC, ODBC
   misc/          データベースファイル移行ツール, サンプルなど
   Fixlist.pdf    モジュールの修正履歴
   Readme.txt     Readme

パッケージには以下の種類があります。

分類 パッケージ名 ファイル名 内容
サーバ griddb-ee-server ・griddb-ee-server-X.X.X-linux.x86_64.rpm
・griddb-ee-server_X.X.X_amd64.deb		 ノードモジュールと運用ツールの一部が含まれます。
クライアント
(運用ツール)		 griddb-ee-client ・griddb-ee-client-X.X.X-linux.x86_64.rpm
・griddb-ee-client_X.X.X_amd64.deb		 さまざまな運用ツールが含まれます。
Web UI griddb-ee-webui ・griddb-ee-webui-X.X.X-linux.x86_64.rpm
・griddb-ee-webui_X.X.X_amd64.deb		 統合運用管理GUI(gs_admin)が含まれます。
Javaライブラリ griddb-ee-java-lib ・griddb-ee-java-lib-X.X.X-linux.x86_64.rpm
・griddb-ee-java-lib_X.X.X_amd64.deb		 Javaのライブラリ、JDBCドライバが含まれます。
Cライブラリ griddb-ee-c-lib ・griddb-ee-c-lib-X.X.X-linux.x86_64.rpm
・griddb-ee-c-lib_X.X.X_amd64.deb		 Cのヘッダファイルとライブラリが含まれます。
Web API griddb-ee-webapi ・griddb-ee-webapi-X.X.X-linux.x86_64.rpm
・griddb-ee-webapi_X.X.X_amd64.deb		 Web APIアプリケーションが含まれます。
Pythonライブラリ griddb-ee-python-lib ・griddb-ee-python-lib-X.X.X-linux.x86_64.rpm
・griddb-ee-python-lib_X.X.X_amd64.deb		 Pythonライブラリが含まれます。
Node.jsライブラリ griddb-ee-nodejs-lib ・griddb-ee-nodejs-lib-X.X.X-linux.x86_64.rpm
・griddb-ee-nodejs-lib_X.X.X_amd64.deb		 Node.jsライブラリが含まれます。
Goライブラリ griddb-ee-go-lib ・griddb-ee-go-lib-X.X.X-linux.x86_64.rpm
・griddb-ee-go-lib_X.X.X_amd64.deb		 Goライブラリが含まれます。

※: X.X.XはGridDBのバージョン

　

インストール

インストール前の環境確認

GridDBのハードウェア要件・ソフトウェア要件を満たしていることを確認します。要件については「リリースノート」をご参照ください。

ノードの時刻同期

クラスタを構成するノードにおいては、OSの時刻に差がないことが前提です。 ノード間でOSの時刻に乖離がある状態で運用することは推奨されません。GridDBではノード間での時刻合わせは行っていません。

各ノードのOSの時刻が乖離していると、以下のような問題が発生する可能性があります。

複数ノードのクラスタ構成の場合は、NTPを使用した時刻同期を推奨します。NTPではslewモードを使用してください。

[注意]

インストールするパッケージの選択

実行するモジュールやマシンの用途によって、インストールが必須なパッケージが異なります。

用途 インストール必須のパッケージ
GridDBノードを実行する場合 サーバ　　　　　　　 　：griddb-ee-server
クライアント(運用ツール) 　：griddb-ee-client
Javaライブラリ　　　　　：griddb-ee-java-lib
運用ツールを実行する場合 クライアント(運用ツール)　：griddb-ee-client
Javaライブラリ　　　　　：griddb-ee-java-lib
アプリケーションを開発する場合 開発するアプリケーションのプログラミング言語に対応するライブラリ

[メモ]

例えば、以下のマシン構成を構築する場合、それぞれインストールするパッケージは以下の通りです。

マシン構成例
マシン構成例
マシン 利用用途 インストールするパッケージ
A. GridDBノードを稼働するサーバマシン GridDBノードを稼働します。運用ツールも実行します。 griddb-ee-server
griddb-ee-client
griddb-ee-java-lib
B. リモートで運用ツールを実行するマシン リモートからGridDBノードやクラスタに対して運用ツールを実行します。 griddb-ee-client
griddb-ee-java-lib
C. アプリケーション開発マシン Cのアプリケーションを開発します。 griddb-ee-c-lib

[メモ]

　

インストールの手順

インストールするパッケージに応じて、インストールの手順は以下のようになります。

実行No. 実行内容 実行が必要な場合
1 パッケージのインストール 共通
2 OSユーザの設定 サーバパッケージ(griddb-ee-server)
または
クライアントパッケージ(griddb-ee-client)をインストールしたマシンの場合
3 ネットワークの環境設定 サーバパッケージ(griddb-ee-server)をインストールしたマシンの場合
4 ノードの環境設定 サーバパッケージ(griddb-ee-server)をインストールしたマシンの場合
5 運用ツールの環境設定 クライアントパッケージ(griddb-ee-client)をインストールしたマシンの場合
6 ライブラリの環境設定 ライブラリパッケージをインストールしたマシンの場合

例えば、次のような用途別のマシンの場合はそれぞれ以下のインストール手順になります。

インストール手順
インストール手順

パッケージのインストール

GridDBを利用するマシンに対して、必要なパッケージをインストールします。

[CentOS実行例]

$ cd  <CD－ROMまたはDVD-ROMのマウントパス＞/RHEL/rpm
$ sudo rpm -ivh griddb-ee-server-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
User gsadm and group gridstore have been registered.
GridDB uses new user and group.
   1:griddb-ee-server          ########################################### [100%]
$
$ sudo rpm -ivh griddb-ee-client-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
User and group has already been registered correctly.
GridDB uses existing user and group.
   1:griddb-ee-client          ########################################### [100%]
$
$ sudo rpm -ivh griddb-ee-java-lib-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
   1:griddb-ee-java-lib        ########################################### [100%]
$
$ sudo rpm -ivh griddb-ee-c-lib-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
   1:griddb-ee-c-lib           ########################################### [100%]
$
  :
  :
  :

[メモ]

[注意]

サーバパッケージ(griddb-ee-server)、またはクライアントパッケージ(griddb-ee-client)をインストールすると、以下の設定を自動的に行います。

OSユーザの設定

サーバパッケージ(griddb-ee-server)、またはクライアントパッケージ(griddb-ee-client)をインストールしたマシンには、本設定を行う必要があります。

サーバパッケージまたはクライアントパッケージをインストールすると、OSユーザgsadmが作成されます。 gsadmにはパスワードが設定されていないので、パスワードを設定してください。

[実行例]

$ sudo passwd gsadm

次に、利用可能なプロセス数とオープン可能なファイル数の上限値を変更し、リソースを多く使えるようにしてください。/etc/security/limits.confに設定してください。

[limits.confの設定例]

gsadm soft nproc 16384
gsadm hard nproc 16384
gsadm soft nofile 65536
gsadm hard nofile 65536

gsadmで再ログインすると、設定が反映されます。ulimit -aで設定内容をご確認ください。

ネットワークの環境設定

サーバパッケージ(griddb-ee-server)をインストールしたマシンには、本設定を行う必要があります。

GridDBノードを稼動するためには、ホスト名とIPアドレスが対応付けられている必要があります。

まず、ホスト名とIPアドレスの対応付けを確認します。 ホストとIPアドレスの設定を確認する「hostname -i」コマンドを実行してください。 以下のようにマシンのIPアドレスが表示される場合は設定済みですので、本節のネットワーク設定の作業は不要です。

以下のようなメッセージやループバックアドレス127.0.0.1が表示される場合は、設定が行われていません。 以下の1から3の手順を実施してください。

　

ネットワークの設定手順

  1. OSで設定されているホスト名とIPアドレスを確認する
  1. ホスト名とIPアドレスの対応付けを設定する
  1. 設定されたことを確認する

　

ノードの環境設定

ノードを稼働するマシンには、本節の設定を行う必要があります。それ以外のマシンの場合は、設定は不要です。

定義ファイルの設定を行います。ノードを稼働するマシンの1台で環境設定した後、定義ファイルを他のマシンに配布します。

ノードの環境設定
ノードの環境設定

パラメータ設定

ノードの定義ファイルには、ノード定義ファイル”gs_node.json”とクラスタ定義ファイル”gs_cluster.json”の2種類があります。

　

管理ユーザの設定

管理ユーザは、運用コマンドの実行や、管理者権限のみ許可されている操作を実行する際に用います。

インストールによって、次の管理ユーザがデフォルトで作成されます。

管理ユーザ パスワード
admin admin
system manager

セキュリティ上の安全のため、デフォルトの管理ユーザのパスワードを変更してください。 管理ユーザのパスワードの変更は、gs_passwdコマンドを使用します。

[実行例]

# su - gsadm
$ gs_passwd admin
Password:（パスワードを入力します）
Retype password:（パスワードを再入力します）

　

新規に管理ユーザを作成する場合は、gs_adduserを使用します。 管理ユーザ名は”gs#”で始まる必要があります。gs#以降は1文字以上のASCII英数字ならびにアンダースコア「_」を使用可能です。文字数の上限は64文字です。

[実行例]

# su - gsadm
$ gs_adduser gs#newuser
Password:（パスワードを入力します）
Retype password:（パスワードを再入力します）

　　

管理ユーザの情報は、ユーザ定義ファイル(/var/lib/gridstore/conf/password)に保存されます。

[メモ]

サービスの設定

サービスによってノードは自動起動します。

起動と同時にクラスタ構成も行う場合は、サービスの設定が必要になります。 詳細は『GridDB 運用ツールリファレンス』を参照ください。

定義ファイルの配布

ノードを稼働するマシンの1台で環境設定した後、定義ファイルを他のマシンに配布します。

　

運用ツールの環境設定

利用する運用ツールの環境設定を行います。 各ツールの設定方法の詳細は、『GridDB 運用ツールリファレンス』を参照ください。

　

ライブラリの環境設定

Pythonライブラリ

Pythonライブラリを利用するには、下記コマンドにより、Pythonパッケージ(griddb_python)をインストールします。gsadmユーザで実行します。

$ pip install /usr/griddb/lib/python

Node.jsライブラリ

Node.jsライブラリを利用するには、下記のようにライブラリを各種パスに含める必要があります。

$ export LIBRARY_PATH=${LIBRARY_PATH}:/usr/griddb/lib
$ export NODE_PATH=/usr/griddb/lib/nodejs
$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/griddb/lib/nodejs

Goライブラリ

Goライブラリを利用するには、下記のようにライブラリを各種パスに含め、ビルドする必要があります。

$ export LIBRARY_PATH=${LIBRARY_PATH}:/usr/griddb/lib
$ export GOPATH=$GOPATH:/usr/griddb/lib/go
$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/griddb/lib/go
$ go install griddb/go_client

Windows上でアプリケーション開発を行う場合

JDBCを利用したアプリケーション開発

Windows上でGridDBにアクセスするアプリケーションやBIツールなどと連携した開発をJava言語のライブラリを用いて行うには、JDBCドライバを用います。

GridDBのインストールメディアにJDBCドライバのファイルが格納されています。インストールメディアの\Windows\JDBCフォルダ下のjarファイルを、アプリケーションの参照するフォルダにコピーしてご利用ください。

ODBCを利用したアプリケーション開発

Windows上でGridDBにアクセスするアプリケーションやBIツールなどと連携した開発をC言語のライブラリを用いて行うには、ODBCドライバを用います。 『GridDB ODBCドライバ説明書』を参照してインストール・環境設定してください。

　

アンインストール

GridDBが不要となった場合には、インストールされているパッケージをアンインストールします。以下の手順でアンインストールを実行してください。

  1. インストールされているパッケージを確認する
  2. アンインストールする

[CentOS実行例]

// インストールされているパッケージを確認する
$ sudo rpm -qa | grep griddb
griddb-ee-server-X.X.X-linux.x86_64
griddb-ee-client-X.X.X-linux.x86_64
griddb-ee-java-lib-X.X.X-linux.x86_64
griddb-ee-c-lib-X.X.X-linux.x86_64

// アンインストールする
$ sudo rpm -e griddb-ee-server
$ sudo rpm -e griddb-ee-client
$ sudo rpm -e griddb-ee-java-lib
$ sudo rpm -e griddb-ee-c-lib

[CentOS実行例]

[注意]

定義ファイルやデータファイルなど、GridDBホームディレクトリ下のファイルはアンインストールされません。（Ubuntu Serverの場合、ディレクトリが削除できない等の警告が出力される場合がありますが問題ありません。）不要な場合は手動で削除してください。

— 運用 —

障害発生時の対応

GridDBを用いたシステムの構築時やシステムの使用時に問題が発生した場合は、どのような問題がどのような状況で発生したかを、実行した動作やエラーコードなどから確認します。 状況確認後、対策を検討/実行します。

ノードの場合の対応

ノードのイベントログファイルには、ノード内部で発生した例外などのイベントに関するメッセージやシステム稼働情報を記録します。

ノードの動作に問題がある場合には、ノードのイベントログを参照して、エラーや警告のメッセージが出力されていないか確認してください。 クラスタは複数のノードで動作しているので、すべてのノードのイベントログでメッセージの有無を確認する必要があります。

　 　

アプリケーションの場合の対応

クライアントAPI(NoSQL/NewSQLインタフェース)を利用したアプリケーションの実行でエラーが発生した場合は、クライアントAPIが出力するエラーコードとエラーメッセージを確認します。

クライアントAPIごとに、エラーコードやエラーメッセージの取得方法は異なります。各リファレンスをご参照ください。

エラーコードの番号を『GridDB エラーコード』で参照してエラーの原因を確認し、対策を実施してください。

エラーの原因がアプリケーションではなくノード側の場合は、エラーが発生した時刻のノードのイベントログを確認することで、エラー発生時のノードの状況を確認します。

例) Java APIの場合

　 　

運用ツールの場合の対応

運用ツールでエラーが発生した場合は、運用ツールのログファイルを参照して、発生したエラーの内容を確認します。

主な運用ツールのログファイルの出力先は以下の通りです。

運用ツール 出力先 出力先の指定方法
運用コマンド(gs_joinclusterなど) /var/lib/gridstore/log gsadmユーザの環境変数GS_LOG
統合運用管理GUI(gs_admin) /var/lib/gridstore/admin/log ログ設定ファイル(WASのディレクトリ/webapps/gs_admin/WEB-INF/classes/logback.xml)
シェルコマンドgs_sh /var/lib/gridstore/log ログ設定ファイル(/usr/griddb/prop/gs_sh_logback.xml)
パラメータlogPath
エクスポート/インポートツール /var/lib/gridstore/log プロパティファイル(/var/lib/gridstore/expimp/conf/gs_expimp.properties)
パラメータlogPath

例) gs_startnodeコマンドのログファイル　　　　ファイル名：gs_startnode.log

2014-10-20 15:25:16,876 [25444] [INFO] <module>(56) /usr/bin/gs_startnode start.
2014-10-20 15:25:17,889 [25444] [INFO] <module>(156) wait for starting node. (node=127.0.0.1:10040 waitTime=0)
2014-10-20 15:25:18,905 [25444] [INFO] <module>(192) /usr/bin/gs_startnode end.

[メモ]

　

構成管理

ノードの増設

設計のポイント

システム初期稼働時は低コストの最小台数でスタートし、データが増加してリソースが不足した時はノードを増設してスケールアウトすることができます。

システムのデータ容量の増加を見積もり、ノード増設のタイミングを計画します。

データ量の増加に伴うノード増設
データ量の増加に伴うノード増設

システム稼働中に以下のようなリソース不足の状態になった場合には、スケールアウトを検討してください。

　

増設の手順

ノードの増設は、クラスタが停止できる場合には停止して行うことを推奨します。稼働中にオンラインで増設することもできます。

  1. 新マシンにGridDBの環境を構築する
  1. アプリケーションや運用ツールの設定、クラスタ構成のスクリプトを修正する
  1. ノードを増設する

パラメータの変更

ノード定義ファイル(gs_node.json)やクラスタ定義ファイル(gs_cluster.json)でノードやクラスタの動作を設定します。 ノードを起動した後やクラスタ稼働中にパラメータを変更できるかどうかは次の3つのパターンがあります。

変更可否 内容
変更不可 ノードを一度起動した後は、設定値を変更することはできません。変更する場合は、データベースを初期化する必要があります。
変更可(再起動) 定義ファイルの設定値を変更し、ノードを再起動すると設定値が反映されます。
変更可(オンライン) ノード・クラスタ稼働中にオンラインでパラメータを変更できます。変更にはコマンドgs_paramconfを用います。ただし、オンラインで変更した内容は永続化されないので、定義ファイルの内容を手動で書き換える必要があります。書き換えない場合は、再起動によって元の設定値に戻ります。

オンラインのパラメータ変更手順

  1. パラメータ変更コマンドgs_paramconfで変更を実施する
  1. パラメータが変更されたことを確認する
  1. 変更したパラメータを定義ファイルに手動で書き換える。

[メモ]

　

データ移行

新しいマシンへのデータ移行の方法

マシンのリプレースなどのために、現在稼動しているクラスタと同じ設定の新しいクラスタを構築するための方法を説明します。

このようなケースでは、ノードを停止してデータベースファイルを物理的にコピーするだけでデータ移行できます。

  1. 新マシンにGridDBをインストールします。
  1. 定義ファイルをコピーします。
  1. 現在稼動しているクラスタを停止します。
  1. データベースファイルをコピーします。
  1. 新マシンでクラスタを稼動します。

　

DB互換性が無い場合のデータ移行の方法

GridDBのバージョンアップなどでDB互換性が無い場合には、データをエクスポート・インポートしてデータ移行する必要があります。

エクスポート・インポートは、データ容量やディスクI/Oの性能によって時間がかかる場合があります。

  1. クラスタ上の全データをエクスポートします。

  1. GridDBをバージョンアップインストールします。

  2. 全データをインポートします。

[メモ]