Zabbix 5.2の変更点は以下のページに記載されています。

5 What’s new in Zabbix 5.2.0
Release Notes for Zabbix 5.2.0

Zabbix 5.2 はポイントリリースとなり、サポート期間が短いため、実運用では LTS バージョンの利用を推奨します。

Zabbix 5.2 の主な変更点を以下に挙げます。

Scriptアイテムタイプ

Scriptアイテムタイプが追加されました。ユーザー定義のJavaScriptによりHTTP/HTTPSでデータを収集することが可能です。

タイムゾーン設定

フロントエンドのタイムゾーンの設定をグローバルおよびユーザーごとに設定できるようになりました。これまではphpの設定ファイルでのみ指定可能でした。

シークレット(秘密情報)の保存

パスワードなどの秘密情報をHashiCorp Vaultという外部サービスに保存できるようになりました。この値はユーザーマクロとデータベースの認証情報で使用できます。

ユーザーロール(ユーザーの役割)

ユーザーロール(ユーザーの役割)を定義できるようになりました。これによりWeb UIの各機能、APIへのアクセス、障害発生時のアクションへのアクセスなど、細かいユーザー権限の制御が可能になりました。

YAMLファイルのエクスポート・インポート

Zabbixの各種設定をこれまでのXML・JSONに加え、YAML形式でエクスポート・インポートが行えるようになりました。YAMLは可読性が高く、編集も行いやすい形式です。

YAML形式でエクスポートしたテンプレートの内容は以下のようになります。

zabbix_export:
  version: '5.2'
  date: '2020-10-08T08:29:52Z'
  groups:
    -
      name: Templates/Applications
  templates:
    -
      template: 'Template App Apache by HTTP'
      name: 'Template App Apache by HTTP'
      description: |
        Get metrics from mod_status module using HTTP agent.

MQTTプロトコルへの対応

MQTTプロトコルに対応したZabbix agent 2アイテム mqtt.get[] が追加されました。MQTTはIoT向けの軽量なPub/Sub型のデータ配信プロトコルです。

mqtt.get[] アイテムは以下のように使用します。対象のトピックを購読し、文字列もしくはJSON(トピックをワイルドカードで指定した場合)で取得します。

mqtt.get["tcp://host:1883","path/to/topic"]
mqtt.get["tcp://host:1883","path/to/#"]
mqtt.get["ws://host:8080","path/to/topic"]

Webフロントエンド

タブの情報表示

フロントエンドの各種ページのタブに設定済み項目数や有効状態が表示されるようになりました。タブを開かなくても設定の有無が簡単に分かるようになりました。

フィルター設定の保存

障害およびホストのページでフィルターの設定が保存できるようになりました。保存したフィルターはタブで切り替えることができます。

セッションをcookieに保持

フロントエンドのセッション情報をWebサーバ上ではなくユーザーのcookieに暗号化して保持するようになりました。これによりフロントエンドを動作させるWebサーバのロードバランスが可能になります。

インターフェースのないホストが作成可能

インターフェースのないホストが作成できるようになりました。トラッパーアイテムやWebチェックのみ使用するホストで有用です。

メンテナンス期間ページの簡略化

これまで複数のタブに分かれていたメンテナンス期間の設定ページが1つのページにまとまり、操作性が向上しました。

その他の改良点

その他以下のような改良が行われています。

• エージェントのHostnameパラメータに複数のホスト名を記述して、1つのエージェントから複数のホストとしてアクティブチェックを行えるようになりました。これにより1つの物理サーバ上の独立したアプリケーションなどを従来のように複数のエージェントを起動することなく論理的な複数のホストとして分割できます。
• Modbusプロトコルに対応したアイテムが追加されました。
• HTTPエージェントとWebシナリオがダイジェスト認証に対応しました。
• アイテムのエラーを保存前処理で上書きできるようになりました。
• ホストプロトタイプでインターフェースを指定できるようになりました。
• ホストプロトタイプがタグに対応しました。
• エージェントの設定パラメータにUserParameterのディレクトリを指定するUserParameterDirが追加されました。
• SNMPアイテムのテストでバージョン固有のパラメータが指定できるようになりました。
• 取得不可アイテムの更新間隔のグローバルな設定が削除され、各アイテムの更新間隔が使用されるようになりました。
• ユーザーマクロの長さが255から2048文字に拡張されました。
• フロントエンドのデフォルトの言語をインストール時および管理設定で設定できるようになりました。
• 以前はdefines.inc.phpファイルを編集することでのみ設定できた一部のパラメータがフロントエンドで直接設定できるようになりました。
• ダッシュボードの一覧にフィルターが追加されました。
• 長期間の分析のためのトリガー関数が追加されました。
• テンプレートのスクリーンがダッシュボードに変換されました。

Zalando Postgres Operatorとは

Zalando Postgres Operator (以下 Postgres Operator)は、コンテナの管理ツールであるKubernetes上でHA構成のPostgreSQLクラスタを容易に構築できるようにするoperatorです(operatorはKubernetesの機能を拡張するプラグインのような機構です)。本ソフトウェアはドイツのファッション系eコマース企業であるZalando SEによって開発され、自社のサービスで運用されています。本ソフトウェアはMITライセンスの元公開されています。

Operatorについて

OperatorはKubernetes上で動作するアプリケーションの各種管理を自動化するための機能です。従来システム管理者が手動で行っていた、監視、障害時の対応、バックアップ、スケーリングといった様々な操作をプログラムとして記述し、Kubernetesに組み込むことでKubernetesの動作を拡張できます。

また、PostgreSQLに新たなoperatorが必要となるもう一つの要因として、PostgreSQLクラスタはプライマリとレプリカ(スタンバイ)の役割を考慮する必要があり、ステートレスなアプリケーション(例:Webサーバ)のように簡単にレプリカ(複製)を複数台用意することができないことが挙げられます。

Postgres Operatorの機能

Postgres Operatorによりストリーミングレプリケーションを用いたプライマリ1台、レプリカ(スタンバイ)複数台のPostgreSQLクラスタを簡単に構築することができます。

Postgres Operatorの主な機能は以下になります。

• PostgreSQL HAクラスタの管理
• ストリーミングレプリケーション (同期・非同期)
• コネクションプール (PgBouncer使用)
• フェイルオーバー (pg_rewindにより高速な復旧が可能)
• ローリングアップデート
• 論理バックアップ (S3使用)
• WALアーカイブ・PITR (WAL-E、S3使用)

Zalando社による講演

PGCon 2020カンファレンスイベントにてZalando社により行われた講演の資料が公開されています。こちらもあわせて参照ください。
PostgreSQL on K8s at Zalando: Two years in production

検証環境

本記事ではKubernetesのマネージドサービスであるAmazon EKS上でZalando Postgres Operatorを動作させます。
本記事では以下の構成で解説を行います。

• Kubernetes: Amazon EKS (Kubernetesのマネージドサービス)
• ワーカーノード: t3.medium 2ノード
• アーカイブ用ストレージ: Amazon S3
• 作業環境: CentOS 8.1 (VirtualBox上のVM)

なお、EKSクラスタの作成は既に完了しているものとします。EKSの使用方法についてはこちらを参照ください。

検証内容

今回はPostgres Operatorの以下の項目について確認しました。

• Postgres Operator のデプロイ
• Web UI
• PostgreSQL クラスタの作成
• PostgreSQLの動作確認
• フェイルオーバー
• スケーリング
• ローリングアップグレード
• 論理バックアップ
• WALアーカイブ・PITR
• ログ

Postgres Operatorのデプロイ

Postgres OperatorはKubernetesとしては基本的な構成のため、導入は比較的簡単です。

Githubのリポジトリを作業環境にcloneします(もしくはtarballを展開します)。

$ git clone https://github.com/zalando/postgres-operator.git
$ cd postgres-operator/

グローバルな設定はconfigmap.yamlファイルに記述されているので、必要に応じて修正します。
ここではバックアップ先のS3の設定などのグローバルな設定を記述します。

kubectl create -fで各YAMLファイルを適用していきます。

$ kubectl create -f configmap.yaml
$ kubectl create -f operator-service-account-rbac.yaml
$ kubectl create -f postgres-operator.yaml
$ kubectl create -f api-service.yaml

オブジェクトが作成され、正常に動作していることを確認します。

$ kubectl get all
NAME                                     READY   STATUS    RESTARTS   AGE
pod/postgres-operator-85978df8cf-zqwjd   1/1     Running   0          48s

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/kubernetes          ClusterIP   10.100.0.1       <none>        443/TCP    168m
service/postgres-operator   ClusterIP   10.100.197.174   <none>        8080/TCP   22s

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgres-operator   1/1     1            1           48s

NAME                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/postgres-operator-85978df8cf   1         1         1       49s

Web UI

Postgres OperatorにはWeb UIが同梱されており、ブラウザから以下の操作が可能です。

• クラスタの作成・削除
• 複製
• 設定編集
• 状態確認

Web UIのデプロイは同様にkubectlを使用して行います。

$ kubectl create -f ui/manifests/

Postgresクラスタの作成

PostgresクラスタのデプロイはYAMLファイルを作成して適用するか、前述のWeb UIで作成操作を行います。

サンプルのYAMLファイルが同梱されていますので、それを元に設定ファイルを作成します。

• minimal-postgres-manifest.yaml: 最小限の設定
• complete-postgres-manifest.yaml: 各種設定を網羅
• standby-manifest.yaml: スタンバイ専用クラスタ設定

基本的な設定を含む設定ファイルは以下になります。

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: sraoss-minimal-cluster           # クラスタ名の指定
spec:
  teamId: "sraoss"
  volume:
    size: 1Gi                            # ボリュームサイズの指定
  numberOfInstances: 2                   # インスタンス数(マスター+レプリカ)の指定
  users:                                 # DBユーザーの作成
    zalando:  # database owner
    - superuser
    - createdb
    foo_user: []  # role for application foo
  databases:                             # データベースの作成
    foo: zalando  # dbname: owner
  preparedDatabases:
    bar: {}
  postgresql:
    version: "12"                        # PostgreSQLバージョンの指定(9.6～12)
  enableLogicalBackup: true              # 論理バックアップの有効化
  logicalBackupSchedule: "30 00 * * * *" # cron形式のバックアップスケジュール
  enableConnectionPooler: true           # コネクションプールの有効化
  connectionPooler:
    numberOfInstances: 2

これに加え、PostgreSQLのpostgresql.conf、pg_hba.confに相当する追加の設定を行うこともできます。

...
  postgresql:
    version: "12“
    parameters:                          # postgresql.conf内のパラメータの指定
      shared_buffers: "64MB"
      max_connections: "50"
      log_statement: "all“
  patroni:
    initdb:                              # initdb時のパラメータの指定
      encoding: "UTF8"
      locale: "ja_JP.UTF-8"
      data-checksums: "true"
    pg_hba:                              # pg_hba.conf内のパラメータの指定
    - hostssl all all 0.0.0.0/0 md5
    - host    all all 0.0.0.0/0 md5

同様にkubectlで適用します。

$ kubectl create -f test-postgres-manifest.yaml

クラスタの状態を確認します。numberOfInstances: 2の場合は2つのPodが作成されます。各Podがmasterかreplicaかはspilo-roleラベルで確認できます。

$ kubectl get postgresql
NAME                     TEAM     VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE    STATUS
sraoss-minimal-cluster   sraoss   12        2      1Gi                                     113s   Running

$ kubectl get pods -l application=spilo -L spilo-role
NAME                       READY   STATUS    RESTARTS   AGE     SPILO-ROLE
sraoss-minimal-cluster-0   1/1     Running   0          2m19s   master
sraoss-minimal-cluster-1   1/1     Running   0          95s     replica

PostgreSQLの動作確認

Kubernetesクラスタ内の他のPodからは上記のmasterおよびreplicaにアクセスすることができます。

作業環境からpsqlでアクセスしたい場合はkubectlのport-forward機能を利用します。
※ PGMASTERにはmasterのPod名が入ります。

$ export PGMASTER=$(kubectl get pods -o jsonpath={.items..metadata.name} -l application=spilo,cluster-name=sraoss-minimal-cluster,spilo-role=master)
$ kubectl port-forward $PGMASTER 6432:5432

別端末からlocalhost:6432に接続します。なお、接続時にはSSLが必須となります。
※ パスワードはPostgresクラスタ作成時に自動生成されます。

$ kubectl get secret postgres.sraoss-minimal-cluster.credentials -o 'jsonpath={.data.password}' | base64 -d
(パスワード文字列が表示される)
$ export PGSSLMODE=require
$ psql -U postgres -h localhost -p 6432
ユーザ postgres のパスワード:(上記パスワード文字列)
postgres=# create table t (t text); postgres=# insert into t values ('hoge'); postgres=# select * from t; t ------ hoge (1 行)

フェイルオーバー

masterのPodに故障が発生した場合は、自動的にフェイルオーバーしてreplicaがmasterに昇格します。これはPostgres Operatorが使用している、SpiloというPostgreSQLおよびHAを実現するためのテンプレート(Patroni)を含むDockerイメージにより実現しています。

master Podを削除した場合は元replicaがmasterに昇格し、削除したPodが再作成されてreplicaとして復帰します。データサイズが少ない状態ではあるものの、フェイルオーバーは数10秒程度ですばやく完了します。

$ kubectl delete pod sraoss-minimal-cluster-0
pod "sraoss-minimal-cluster-0" deleted

$ kubectl get pods -l application=spilo -L spilo-role
NAME                       READY   STATUS              RESTARTS   AGE   SPILO-ROLE
sraoss-minimal-cluster-0   0/1     ContainerCreating   0          6s
sraoss-minimal-cluster-1   1/1     Running             0          12m   master

$ kubectl get pods -l application=spilo -L spilo-role
NAME                       READY   STATUS    RESTARTS   AGE   SPILO-ROLE
sraoss-minimal-cluster-0   1/1     Running   0          23s   replica
sraoss-minimal-cluster-1   1/1     Running   0          12m   master

masterのプロセス故障が発生した場合は元replicaがmasterに昇格し、元masterはPodを維持したままプロセスを再起動しreplicaに降格します。以下の例ではmaster Pod内に入り、initプロセスを停止させて疑似的にプロセス故障を起こしています。

$ kubectl exec sraoss-minimal-cluster-0 -it /bin/sh
# kill 1

スケーリング

デプロイ済みのPostgresクラスタの設定を変更すると、変更内容に応じてクラスタの状態を自動的に追従させます。
クラスタのPodの数を指定するnumberOfInstancesを2から3に変更すると、Statefulsetsのレプリカ数も2から3に変更され、新しいreplica Podが起動します。

$ kubectl edit postgresql
spec:
  numberOfInstances: 2 -> 3 に修正

$ kubectl get postgresql
NAME                     TEAM     VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE   STATUS
sraoss-minimal-cluster   sraoss   12        3      1Gi                                     53m   Running
$ kubectl get statefulsets
NAME                     READY   AGE
sraoss-minimal-cluster   3/3     14m
$ kubectl get po -l application=spilo -L spilo-role
NAME                       READY   STATUS    RESTARTS   AGE     SPILO-ROLE
sraoss-minimal-cluster-0   1/1     Running   0          50m     master
sraoss-minimal-cluster-1   1/1     Running   0          50m     replica
sraoss-minimal-cluster-2   1/1     Running   0          7m21s   replica

ローリングアップデート

PostgreSQLのマイナーバージョンアップ(Dockerイメージの更新)、およびPostgreSQLの設定変更はローリングアップデートによりサービスの停止なしに行うことができます。なお、メジャーバージョンアップはローリングアップデートでは行えないため、ベースバックアップからクラスタの複製により行う必要があります。

以下、Dockerイメージを更新した場合にローリングアップデートが行われる様子を実際に確認してみます。

Dockerイメージの更新

$ kubectl edit postgresql sraoss-test-cluster
  dockerImage: (旧Dockerイメージ) -> (新Dockerイメージ)
  postgresql:
    version: "12"

ローリングアップデート開始

$ kubectl get postgresql
NAME                  TEAM     VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE     STATUS
sraoss-test-cluster   sraoss   12        2      1Gi                                     9m19s   Updating

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS        RESTARTS   AGE     SPILO-ROLE
sraoss-test-cluster-0   1/1     Running       0          9m24s   master
sraoss-test-cluster-1   1/1     Terminating   0          8m42s

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS              RESTARTS   AGE     SPILO-ROLE
sraoss-test-cluster-0   1/1     Running             0          9m34s   master
sraoss-test-cluster-1   0/1     ContainerCreating   0          8s

元replica Podが再作成され、masterに昇格

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS    RESTARTS   AGE     SPILO-ROLE
sraoss-test-cluster-0   1/1     Running   0          9m39s
sraoss-test-cluster-1   1/1     Running   0          13s     promoted

元master Podの再作成

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS        RESTARTS   AGE     SPILO-ROLE
sraoss-test-cluster-0   1/1     Terminating   0          9m49s
sraoss-test-cluster-1   1/1     Running       0          23s     master

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS              RESTARTS   AGE   SPILO-ROLE
sraoss-test-cluster-0   0/1     ContainerCreating   0          4s
sraoss-test-cluster-1   1/1     Running             0          30s   master

元master Podがreplicaとして復帰

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS    RESTARTS   AGE   SPILO-ROLE
sraoss-test-cluster-0   1/1     Running   0          14s   replica
sraoss-test-cluster-1   1/1     Running   0          40s   master

論理バックアップ

Postgres Operatorでは定期的にAmazon S3に論理バックアップ(pg_dumpall)を取ることができます。なお、論理バックアップからの自動リストア機能はないので、リストアはクラスタ作成後手動で行う必要があります。

前述のconfigmap.yamlでバックアップ先のS3の設定を行います。

logical_backup_s3_bucket: "zalando-backup"
logical_backup_s3_access_key_id: "xxxxxxxxxxxxxxxx"
logical_backup_s3_secret_access_key: "xxxxxxxxxxxxxxxx

Postgresクラスタの設定で論理バックアップを有効にします。スケジュールはcron表記で指定します(以下は毎日0:30に実行)。

  enableLogicalBackup: true
  logicalBackupSchedule: “30 00 * * *"

指定時刻にKubernetesのCronJobとしてバックアップが実行されます。

$ kubectl get cronjob
NAME                                    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
logical-backup-sraoss-minimal-cluster   30 00 * * *   False     0        6m48s           27m

$ kubectl get job
NAME                                               COMPLETIONS   DURATION   AGE
logical-backup-sraoss-minimal-cluster-1593418800   1/1           3s         6m46s

$ kubectl describe job logical-backup-sraoss-minimal-cluster-1593418800
...
Pods Statuses:  0 Running / 1 Succeeded / 0 Failed

S3の以下の場所にバックアップファイルがアップロードされます。

s3://<bucket-name>/spilo/<cluster-name>/<UUID>/logical_backups/<job ID>.sql.gz

WALアーカイブ・PITR

前述のconfigmap.yamlでバックアップ先のS3の設定を行います。なお、EKSクラスタからS3 bucketへのアクセスが許可されている必要があります。

wal_s3_bucket: "zalando-wal-backup"

S3の以下の場所にWALがアーカイブされます。

s3://<bucket-name>/spilo/<cluster-name>/<UUID>/wal/basebackups_00x/
s3://<bucket-name>/spilo/<cluster-name>/<UUID>/wal/wal_00x/

S3のバックアップからクラスタを複製(clone)することでPITRが可能です。PITRの復元位置を指定することもできます。

spec:
  clone:
    uid: "efd12e58-5786-11e8-b5a7-06148230260c"
    cluster: “sraoss-test-cluster"
    timestamp: "2017-12-19T12:40:33+01:00"

ログ

Postges Operator自体はログ管理に関する機能を持ちません。Podのsidecarコンテナをユーザが追加することは可能なので、ログ収集のための補助コンテナを導入し、fluentdと連携するなどの作り込みは必要となります。また、Kubernetesクラスタのログを集約するKubernetes Log WatcherというツールがZalando社によって公開されています。

クラスタの各Podのログはkubectl logsコマンドにより確認できます。

$ kubectl logs sraoss-minimal-cluster-0

また、Pod内のPostgreSQLログは以下のように格納されています。

/home/postgres/pgdata/pgroot/pg_log/
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-0.csv
-rw-r--r-- 1 postgres postgres 277783 Jun 29 06:58 postgresql-1.csv
-rw-r--r-- 1 postgres postgres    205 Jun 29 06:12 postgresql-1.log
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-2.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-3.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-4.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-5.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-6.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-7.csv

おわりに

手動でPostgreSQL HAクラスタを構築するとなるとかなりの手間がかかります。また、Kubernetes上にそれを構築しようとするのはかなり困難です。Zalando Postgres Operatorを用いることで、Kubernetes上のPostgreSQL HAクラスタの構築が非常に容易になります。実際に開発元のサービスで運用されている実績があり、機能的にまだ不十分なところもあるものの、フェイルオーバーなどの重要な機能に関してはしっかりと作り込まれていると感じました。今後の発展が楽しみなソフトウェアといえます。

• Crunchy PostgreSQL Operatorの紹介
• Zalando Postgres Operatorの紹介

Kubernetesの特長

Kubernetesは宣言的設定(マニフェスト)で「あるべき状態」を定義することにより自律的にシステムの管理を行うことが特長です。例えばWebサーバのレプリカ数を3とした場合、現在の状態を定期的にチェックし、サーバの数がそれに満たない場合は新たに起動します。この繰り返しの動作をReconciliation Loop(突合せループ)と呼びます。

Kubernetesでは、これまでシステム管理者が手作業で行っていたサーバの構築と運用管理を自動化することができます。例えば以下のような作業です。

• 定期バックアップ・リストア
• スケールアウト・スケールイン
• ローリングアップデート

Kubernetes上でPostgreSQLを運用するメリット

従来のPostgreSQLデータベースの管理は以下のような問題を抱えていました。

• HA クラスタ環境の構築が面倒
• 監視、バックアップ、障害対策など、運用の手間がかかる
• 負荷の急な増加に即座に対応できない
• データ量増加に伴うディスク容量の不足
• テスト・開発環境の用意が大変

Kubernetes上でPostgreSQLを運用すると以下のようなメリットがあります。

• PostgreSQL HA クラスタ環境を自動的に構築・運用管理できる
• PostgreSQL の検証環境・テスト環境をすぐに構築・削除できる
• バックアップ・リカバリの自動化
• 負荷に応じて、レプリカの台数を増減可能
• Namespace により、PostgreSQL クラスタをサービスごとに隔離可能 (Multi-Tenant)
• 高可用性・耐障害性の向上 (Multi-Cluster、Multi-Zone)
• 必要に応じて、ボリュームサイズ拡張可能
• PostgreSQLのバージョン管理が容易

PostgreSQL Operator

Operatorとは

Operatorとは、Kubernetesの機能を拡張し、様々な運用管理の手順をコードとして記述したものです。Operatorにより、運用の自動化が可能になります。

PostgreSQL Operator

PostgreSQL OperatorはPostgreSQLのデプロイ、バックアップ、障害対応、クラスタ管理、監視などの管理タスクを自動化します。PostgreSQL Operatorの基本的な構成は以下のようになります。

PostgreSQL Operatorの活用例

バックアップ

バックアップジョブを定期的に実行してDBのバックアップを行うことができます。また、WALアーカイブを随時保存します。取得したバックアップやWALアーカイブはAmazon S3(もしくはその互換サービス)に保存できます。

バックアップから複数のテスト環境を複製

保存しておいたWALアーカイブから環境を復元できます。また、これを利用して本番環境のバックアップから複数の環境を複製して、テスト環境として用いるといった用途にも使えます。

高可用性:クラスタ内フェイルオーバー

プライマリのPodに障害が発生した場合、レプリカの1つが自動的にプライマリに昇格します。元プライマリのPodはレプリカに降格して動作を続けます。また、Podが削除された場合は自動的に新しいPodが再作成されます。

高可用性:クラスタ間フェイルオーバー

2つの独立したKubernetesクラスタ間で、S3に保存したWALアーカイブ経由でPostgreSQLのアクティブ・スタンバイクラスタが同期を取ります。アクティブ側のクラスタに障害が発生した場合は手動でフェイルオーバーを行います。

Kubernetesクラスタを物理的に独立した場所に分散配置することでディザスタリカバリに利用することができます。

スケーリング

設定変更によりレプリカの数を動的に増減させることができます。レプリカ数を増やした場合、不足分のレプリカPodが自動的に作成されます。レプリカ数を減らした場合は、余分なレプリカPodが削除されます。

ZalandoとCrunchyについて

現在開発が続けられている代表的なPostgreSQL OperatorとしてZalandoとCrunchyがあります。ここではそれぞれの特長について概要を紹介します。各Operatorの詳細については別記事を参照ください。

基本情報

機能一覧

それぞれの特長

ZalandoもCrunchyも多くの基本的な機能は共通しており、PostgreSQLクラスタに求められる機能は一通り用意されています。

実績の面では、Zalandoは自社のECサイトで実際に数年運用されている実績があります。CrunchyはPostgreSQLの専門家が開発しているという強みがあります。

Zalandoの基本的にKubernetesの標準的な機能を用いて各種操作を行います。Kubernetesの操作に慣れており、設定追加や変更内容を履歴として残すことを重視するのであればZalandoを選択するメリットがあります。また、ZalandoはGUI(Webインタフェース)が同梱されており、ブラウザから管理を行えます。対してCrunchyは専用の管理コマンドが用意されており、操作が容易で効率的というメリットがあります。

Zalandoはローリングアップデートによりダウンタイムなしでマイナーバージョンアップを行えるメリットもあります。対してCrunchyはアップデート時にある程度のダウンタイムが発生します。

Zalandoは監視などの補助的な機能は標準では用意されておらず、用意されている枠組みを使用してユーザーがある程度作り込みを行う必要があります。対してCrunchyはpgAdmin、ログ解析、監視などの便利な機能が標準で含まれていいるため、導入コストは低くなります。

おわりに

本記事では、Kubernetes上でPostgreSQLを運用するメリット、PostgreSQL Operatorの概要と活用例、ZalandoとCrunchyそれぞれの特長について説明しました。

Kubernetes上のアプリケーションでDBを使用する場合や、多数のDBクラスタを迅速に構築したい場合など、PostgreSQL Operatorは様々な活用方法が想定できます。

ZalandoもCrunchyも発展途上のソフトウェアですが、既に多数の機能が実装されており、今後の発展も期待が持てます。

1. 構成

本記事では以下の構成でインストールを行います。

• CentOS 8.1 (1911)
• Zabbix 4.4.5
• Apache httpd 2.4.37 (OS同梱パッケージ)
• PostgreSQL 10.6 (OS同梱パッケージ)
• ZabbixJavaGateway (JMX監視モジュール)
• SNMPTT (SNMPTRAP監視モジュール) ※

※ SNMPTT は RHEL/CentOS 8向けパッケージが提供されていないため、 RHEL 7向けパッケージを流用します。

2. 構築の流れ

本記事ではRPMパッケージを使用して、以下の手順でインストールを行います。

1. パッケージのインストール
2. データベース作成
3. 設定ファイルの編集
4. Zabbixサーバ、エージェント、その他サービスの起動
5. Webフロントエンドから初期設定

3. インストール前の準備

SELinuxが有効になっている場合はdisabledもしくはpermissiveにします。また、firewalldの設定でZabbixサーバへの80、10051番ポートへのアクセスを許可しておきます。

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

Zabbix本体および依存パッケージを各RPMリポジトリからyumコマンドでインストールします。本記事では以下のリポジトリを使用します。

• repo.zabbix.com (Zabbix公式リポジトリ)
• EPEL (RHEL向け拡張パッケージ)

4.1 PostgreSQL のインストール

OSに標準で含まれるPostgreSQL 10.6をインストールします。

# dnf -y install postgresql postgresql-server

4.2 Zabbix のインストール

Zabbixサーバ、Webフロントエンド、Zabbixエージェント、ZabbixJavaGatewayをインストールします。

なお、RHEL/CentOS 8.1ではzabbix-server-pgsqlパッケージが依存しているlibssh2パッケージがリポジトリから削除されているため、インストールに失敗します。このため、libssh2のみRHEL/CentOS 8.0のリポジトリからrpmをインストールしておく必要があります。

# rpm -Uvh http://mirror.centos.org/centos/8.0.1905/AppStream/x86_64/os/Packages/libssh2-1.8.0-8.module_el8.0.0+189+f9babebb.1.x86_64.rpm
# rpm -Uvh https://repo.zabbix.com/zabbix/4.4/rhel/8/x86_64/zabbix-release-4.4-1.el8.noarch.rpm
# dnf clean all
# dnf -y install zabbix-server-pgsql zabbix-web-pgsql zabbix-web-japanese zabbix-apache-conf zabbix-agent
# dnf -y install zabbix-java-gateway

4.3 SNMPTT のインストール

RHEL/CentOS 7.x までの場合はEPELリポジトリのSNMPTTパッケージを利用していました。しかし、現時点では RHEL/CentOS 8 用 EPEL リポジトリには SNMPTT パッケージは含まれていません。このため、暫定的に RHEL/CentOS 7.x 向けの SNMPTT パッケージを使用してインストールを行います。

また、RHEL/CentOS 8からnet-snmp-perlパッケージがリポジトリから削除されたため、net-snmp-perlを利用する機能は使用できないためご注意ください(※必要な場合は net-snmp の SRPM パッケージから rpm をビルドすることが可能です)。

最初にRHEL/CentOS 8向けEPELリポジトリを有効にします。

# rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

CentOSのPowerToolsリポジトリに含まれるperl-Digest-SHA1およびperl-IO-stringyが必要となるため、PowerToolsリポジトリを有効にしてsnmpttパッケージのインストールを行います。

# dnf --enablerepo=PowerTools -y install https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/s/snmptt-1.4-0.9.beta2.el7.noarch.rpm

(注) RHEL 8.xの場合は上記のパッケージはCodeReady Linux Builder for x86_64 (codeready-builder-for-rhel-8-x86_64-rpms)リポジトリに含まれるため、以下のようにしてリポジトリを有効にしてください。

# subscription-manager repos --enable=codeready-builder-for-rhel-8-x86_64-rpms
# dnf -y install https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/s/snmptt-1.4-0.9.beta2.el7.noarch.rpm

あわせてnet-snmp、net-snmp-utilsおよびperl-Sys-Syslogパッケージをインストールします。

# dnf -y install net-snmp net-snmp-utils perl-Sys-Syslog

5. データベースの作成

データベースの初期化を行い、Zabbixのデータベースを作成します。

# PGSETUP_INITDB_OPTIONS="-E utf8 --no-locale" /usr/bin/postgresql-setup --initdb
* Initializing database in '/var/lib/pgsql/data'
* Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log

pg_hba.confを編集し、TCP接続時のパスワード認証を有効にします。

# vi /var/lib/pgsql/data/pg_hba.conf
# IPv4 local connections:
#host    all             all             127.0.0.1/32            ident
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
#host    all             all             ::1/128                 ident
host    all             all             ::1/128                 md5

PostgreSQLを起動し、ユーザおよびデータベースを作成します。

# systemctl start postgresql

# sudo -u postgres createuser --pwprompt zabbix
Enter password for new role:
Enter it again:
# sudo -u postgres createdb -O zabbix zabbix

# zcat /usr/share/doc/zabbix-server-pgsql*/create.sql.gz | sudo -u zabbix psql zabbix

6. Zabbixサーバ設定

ZabbixサーバのDB設定、ZabbixJavaGateway、Zabbixエージェント、フロントエンドのタイムゾーン、およびSNMPTTの設定を行います。

# vi /etc/zabbix/zabbix_server.conf
DBName=zabbix
DBUser=zabbix
DBPassword=<パスワード>

JavaGateway=127.0.0.1
JavaGatewayPort=10052
StartJavaPollers=1

SNMPTrapperFile=/var/log/snmptt/snmptt.log
StartSNMPTrapper=1

# vi /etc/zabbix/zabbix_agentd.conf
Server=127.0.0.1
ServerActive=127.0.0.1
Hostname=(Zabbixエージェントのホスト名) ※Zabbixサーバ上のホストの設定と一致させる必要があります

# vi /etc/php-fpm.d/zabbix.conf
php_value[date.timezone] = Asia/Tokyo

6.1 SNMPTTの設定

snmptrapdの起動オプションを変更します。

# vi /etc/sysconfig/snmptrapd
OPTIONS="-m +ALL -Lsd -On"

snmptrapd.confに、受信したSNMPトラップをSNMPTTに送る設定を追加します。

# vi /etc/snmp/snmptrapd.conf
authCommunity   log,execute,net public
traphandle default /usr/sbin/snmptthandler

snmptthandler-embeddedを使用する場合はtraphandleの代わりに以下を追加します。なお、snmptthandler-embeddedを使用する場合はnet-snmp-perlが必要になります。

perl do "/usr/share/snmptt/snmptthandler-embedded"

snmptt.iniを以下のように変更します。

# vi /etc/snmp/snmptt.ini
#mode = standalone
mode = daemon

#net_snmp_perl_enable = 0
(net-snmp-perlを使用する場合のみ) net_snmp_perl_enable = 1

#net_snmp_perl_best_guess = 0
(net-snmp-perlを使用する場合のみ) net_snmp_perl_best_guess = 2

#sleep = 5
sleep = 1

snmptt.conf に下記を記述すると、すべてのSNMPトラップを「Unknown trap」として受け取り、snmptt.logファイルに出力します。実際には監視したいトラップのOIDごとに設定を行います。

# vi /etc/snmp/snmptt.conf
EVENT general .* "Unknown trap" Normal
FORMAT ZBXTRAP $aA $ar $*

SNMPTTおよびsnmptrapdの起動および自動起動を有効にします。

# systemctl enable --now snmptt snmptrapd

テストトラップを送信し、snmptt.logログファイルにトラップが出力されることを確認します。

# snmptrap -v 2c -c public 127.0.0.1 '' .1.3.6.1.4.1.8072.9999 .1.3.6.1.4.1.8072.9999 s 'Hello'
# cat /var/log/snmptt/snmptt.log
Tue Feb  4 15:43:56 2020 .1.3.6.1.4.1.8072.9999 Normal "Unknown trap" localhost - ZBXTRAP 127.0.0.1 127.0.0.1 Hello

7. Zabbixサーバの起動

Zabbixサーバおよび必要なその他サービスを起動し、同時に自動起動設定も行います。

# systemctl enable --now zabbix-server zabbix-agent zabbix-java-gateway httpd php-fpm

8. Webフロントエンドの設定

Webブラウザから http://(Zabbixサーバのホスト名orIPアドレス)/zabbix にアクセスし、画面の指示に従って初期設定を行います。アクセスできない場合はSELinuxおよびfirewalldの設定が正しく行われているかを確認してください。

設定完了後表示されるログイン画面で初期管理者ユーザ/パスワード(Admin/zabbix)でログインするとダッシュボード画面が表示されます。

右上のユーザープロファイルアイコンから、UserタブのLanguageを「Japanese (ja_JP)」に変更し、「Update」ボタンをクリックすると表示が日本語に切り替わります。

以上でRHEL/CentOS 8.xへのZabbixサーバのインストールは完了です。

9. おわりに

今回はRHEL/CentOS 8.xへのZabbixサーバのインストールについて解説しました。RHEL/CentOS 8.xはまだリリースされてから日が浅く、廃止されたパッケージなどもあるため、現時点ではやや手順が煩雑になります。これらの課題は今後のZabbixのリリースで解消していくものと思われます。

今回はRedisのモジュール機能で可能なことの解説、およびRedisのスポンサーであるRedis Labsや他のサードパーティにより公開されている様々なモジュールの紹介を行います。

Redisモジュールとは

Redisモジュールは、Redisに外部モジュールをロードすることで、Redis本体に手を入れることなく機能拡張できる仕組みです。モジュールは通常C/C++で実装されますが、技術的には他の言語でも実装可能です。

Redisモジュールで可能なこと

RedisモジュールではRedisに以下のような機能の拡張が可能です。新しいコマンドを呼び出したときに実行する処理をすべてモジュール側で実装することもできますし、Redisの機能を利用して実装することも可能です。

• 新しいコマンドの作成
• Redisの機能をモジュールから呼び出す
• 新しいデータ型の作成
• レプリケーション、クラスタにも対応できる (RDB、AOFの永続化処理を実装すればOK)

Redisモジュールのライセンス変更について

Redisのスポンサー企業であるRedis Labsが開発、提供するモジュールについてライセンスの変更が行われました。

対象は RediSearch, RedisGraph, RedisJSON, RedisML, RedisBloom などで、当初のAGPLから、(2018/8) Apache v2.0 modified with Commons Clause -> (2019/2) Redis Source Available License (RSAL)と2回の変更が行われました。これは大手クラウド業者などがRedisモジュールの機能をそのままサービスとして提供することで利益を得る、いわゆるフリーライドを防ぐ意図があります。

なお、Redis本体のライセンスには変更はありません(引き続き3条項BSDライセンスが適用されます)。他のRSALを適用していないモジュールや、ユーザーが実装するモジュールにも制限はありません。

RSALの制限事項

RSALライセンスではソースコードの利用・改変・再配布や、Redisモジュールを使ったサービスや製品の販売は認められています。ただし、以下の開発に使用することは禁止されています。

• データベース
• キャッシュエンジン
• ストリーム処理エンジン
• 検索エンジン
• インデックスエンジン
• 機械学習(ディープラーニング含む)、AIエンジン
• RedisのAPIやRedis Modules APIを公開する製品やサービス

Redisモジュールの作り方

Redisモジュールをビルドするのに必要なものは、Redisの最新版ソースコードに含まれる redismodule.h のみと非常にシンプルです。ライブラリ等依存コンポーネントがないため、手軽に作成することができます。

Redisのソースコードは以下のページからダウンロードできます。通常はStableを使用してください。

https://redis.io/download

サンプルコード

helloworld.randコマンドを実行するとrand()で生成した乱数を返す単純なモジュールです。

#include "redismodule.h"
#include <stdlib.h>

int HelloworldRand_RedisCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
    RedisModule_ReplyWithLongLong(ctx, rand());
    return REDISMODULE_OK;
}

int RedisModule_OnLoad(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
    if (RedisModule_Init(ctx, "helloworld", 1, REDISMODULE_APIVER_1) == REDISMODULE_ERR)
        return REDISMODULE_ERR;

    if (RedisModule_CreateCommand(ctx, "helloworld.rand", HelloworldRand_RedisCommand, "readonly", 0, 0, 0) == REDISMODULE_ERR)
        return REDISMODULE_ERR;

    return REDISMODULE_OK;
}

コンパイル、配置、ロード

$ gcc --shared -fPIC helloworld.c -o helloworld.so
$ sudo cp helloworld.so /var/lib/redis/helloworld.so
$ redis-cli module load /var/lib/redis/helloworld.so
(設定ファイルに書く場合は /etc/redis.conf に以下を追加)
loadmodule /var/lib/redis/helloworld.so

実行

$ redis-cli
127.0.0.1:6379> helloworld.rand
(integer) 855445334
127.0.0.1:6379> helloworld.rand
(integer) 705120217

公開中のモジュールの紹介

ここではRedisモジュールの活用例として、Redis Modulesのページで公開されているモジュールの中から興味深いものについていくつか紹介します。

• RediSearch: 全文検索
• RedisAI/RedisML/neural-redis: 機械学習エンジン
• RedisGraph: グラフDB

RediSearch

RediSearchはRedisに全文検索エンジンを追加するモジュールです。多言語に対応しており、中国語には対応していますが日本語には残念ながら未対応です(工夫により対応することは可能です)。RediSearchはRedis Labs社によりRSALライセンスで配布されています。

RediSearchのビルド手順は以下のようになります(RHEL7系の場合)。

$ sudo yum install cmake3 --enablerepo=epel
$ git clone https://github.com/RediSearch/RediSearch.git
$ cd RediSearch; mkdir build; cd build
$ cmake3 .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
$ make
$ sudo cp redisearch.so /var/lib/redis/
$ redis-cli module load "/var/lib/redis/redisearch.so"

簡単な使い方を以下に示します。

[スキーマを作成]
127.0.0.1:6379> ft.create myidx schema title text weight 5.0 body text url text

[ドキュメントを追加]
127.0.0.1:6379> ft.add myidx doc1 1.0 fields title "Hello World" body "This is a test document." url "http://localhost/"

[検索]
127.0.0.1:6379> ft.search myidx "test" limit 0 10
1) (integer) 1
2) "doc1"
3) 1) title
2) "Hello World"
3) body
4) "This is a test document."
5) url
6) "http://localhost/"

あらかじめ分かち書きを行っておくことで日本語も一応使うことが出来ます。

$ redis-cli --raw ※日本語UTF-8文字列をエスケープせずそのまま出力するため--rawを付加
127.0.0.1:6379> ft.create jpidx schema title text weight 5.0 body text title.orig text weight 0.0 body.orig text weight 0.0
127.0.0.1:6379> ft.add jpidx d2 1.0 fields title "日本語 の テスト" body "これは 試験 用 の 文章 です 。" title.orig "日本語のテスト" body.orig "これは試験用の文章です。"
127.0.0.1:6379> ft.search jpidx 日本語
1
d2
title
日本語 の テスト
body
これは 試験 用 の 文章 です 。
body.orig
これは試験用の文章です。
title.orig
日本語のテスト

neural-redis

neural-redisはRedisにニューラルネットワークによる機械学習エンジンを追加するモジュールです。以下のような特徴があります。

• 非常にシンプルなAPI
• 他のライブラリに依存せず単体で動作
• データ自動正規化
• 別スレッドによるバックグラウンド処理
• 過学習検知付き自動トレーニング
• Salvatore Sanfilippo (Redis開発者)が開発
• 3条項BSDライセンス

他の機械学習・ディープラーニングエンジンとして、Redis Labs社により公開されているRedisMLおよびRedisAIがあります。

neural-redisのビルド手順は以下のようになります。

$ git clone https://github.com/antirez/neural-redis
$ cd neural-redis/
$ make sse
$ sudo cp neuralredis.so /var/lib/redis/
$ redis-cli module load "/var/lib/redis/neuralredis.so"

neural-redis (1) 回帰分析

入力データから数値の予測を行う問題の例として、足し算の答えの予測 (a + b = c)を行います。

ニューラルネットワークの作成

$ redis-cli
127.0.0.1:6379> NR.CREATE net REGRESSOR 2 3 -> 1 NORMALIZE DATASET 50 TEST 10
(integer) 13

学習データを投入

127.0.0.1:6379> NR.OBSERVE net 1 2 -> 3
127.0.0.1:6379> NR.OBSERVE net 4 5 -> 9
127.0.0.1:6379> NR.OBSERVE net 3 4 -> 7
127.0.0.1:6379> NR.OBSERVE net 1 1 -> 2
127.0.0.1:6379> NR.OBSERVE net 2 2 -> 4
127.0.0.1:6379> NR.OBSERVE net 0 9 -> 9
127.0.0.1:6379> NR.OBSERVE net 7 5 -> 12
127.0.0.1:6379> NR.OBSERVE net 3 1 -> 4
127.0.0.1:6379> NR.OBSERVE net 5 6 -> 11

トレーニング開始

127.0.0.1:6379> NR.TRAIN net AUTOSTOP
Training has started

トレーニング結果のテスト

比較的想定に近い結果が出ていることがわかります。

127.0.0.1:6379> NR.RUN net 1 1
1) "2.0505485534667969"
127.0.0.1:6379> NR.RUN net 4 6
1) "10.419864654541016"
127.0.0.1:6379> NR.RUN net 2 3
1) "4.8927350044250488"

neural-redis (2) 分類

入力データをグループ分けする問題の例として、neural-redisにサンプルとして付属しているタイタニック号の乗客の生存予測を行います。

モジュールに同梱されているサンプル

• 入力パラメータ: 乗客の各種属性(チケットクラス、性別、年齢、兄弟・親子の乗船数、チケット料金)
• 分類ラベル: 生存 or 死亡

付属のRubyスクリプトで学習データ(CSV形式)の投入とトレーニング

$ cd neural-redis/examples
$ ruby titanic.rb
Before training
185 prediction errors on 290 items
Still training...
After training
47 prediction errors on 290 items

トレーニング結果のテスト

ファーストクラス、女性、30歳、兄弟・親子なしの場合、95%の確率で生存という結果になりました

$ redis-cli
127.0.0.1:6379> NR.RUN mynet 1 0 0 0 1 30 0 0 200
1) "0.066139459609985352"
2) "0.94962334632873535"

年齢を70歳に上げた場合、95%から92.5%に減少しました。

127.0.0.1:6379> NR.RUN mynet 1 0 0 0 1 70 0 0 200
1) "0.08922017365694046"
2) "0.925819993019104"

70歳、サードクラス、格安チケットのように条件を悪くした場合、生存率が32%と大幅に減少しました。

127.0.0.1:6379> NR.RUN mynet 0 0 1 0 1 70 0 0 20
1) "0.6508185863494873"
2) "0.32001861929893494"

より高度な使い方はneural-redisのgithubページを参照してください。

RedisGraph

RedisGraphはRedisにグラフDB機能を追加するモジュールです。グラフDBはグラフ構造に特化したDBのことです。グラフDBとしてメジャーなNeo4jのグラフクエリー言語であるCypherを採用しており、Neo4jの利用経験があればすぐに使うことができます。
RedisGraphはRedis Labs社によりRSALライセンスで配布されています。

RedisGraphのビルドはやや複雑なため、ここではDockerイメージを使用して実行します。

# docker run -p 6379:6379 -it --rm redislabs/redisgraph

RedisGraphではGRAPH.QUERYコマンドに対してスキーマ名とCypherクエリー文字列を指定して使用します。簡単な使い方を以下に示します。

グラフを作成

例として人同士の関係をグラフとして作成してみます。以下はJohnの友人はFred、Lisaの友人はMaryという関係をグラフ化したものです。

$ redis-cli
127.0.0.1:6379> GRAPH.QUERY People
"CREATE (:Person {name:'John'})-[:friend]->(:Person {name:'Fred'}),
(:Person {name:'Lisa'})-[:friend]->(:Person {name:'Mary'})"
1) 1) "Labels added: 1"
2) "Nodes created: 4"
3) "Properties set: 4"
4) "Relationships created: 2"
5) "Query internal execution time: 3.208423 milliseconds"

クエリ実行

上記で登録した人同士の関係のグラフから、Fred の友人を検索してみます。

127.0.0.1:6379> GRAPH.QUERY People
"MATCH (p1:Person)-[:friend]->(p2:Person)
WHERE p2.name = 'Fred'
RETURN p1.name, p2.name"
1) 1) "p1.name"
2) "p2.name"
2) 1) 1) "John"
2) "Fred"
3) 1) "Query internal execution time: 0.326652 milliseconds"

条件にマッチした数をカウントすることもできます。以下ではMaryの友人の数をカウントしています。

127.0.0.1:6379> GRAPH.QUERY People
"MATCH (p1:Person)-[:friend]->(p2:Person {name:'Mary'})
RETURN count(p1)"
1) 1) "count(p1)"
2) 1) 1) (integer) 1
3) 1) "Query internal execution time: 0.290916 milliseconds"

まとめ

今回はRedisモジュールについて紹介しました。RedisモジュールによりユーザーがRedisに対して自由に機能拡張を行うことができます。HA機能を含むRedisの既存の機能を利用してRedisモジュールを実装することができるため、Redisコア機能の恩恵が得られます。

現在既に様々な高機能なRedisモジュールが提供されており、今後も新しいRedisモジュールの登場が期待できます。

Zabbix 4.4の変更点は以下のページに記載されています。

5 What’s new in Zabbix 4.4.0
Release Notes for Zabbix 4.4.0

Zabbix 4.4はポイントリリースとなり、サポート期間が短いため、実運用ではLTSバージョンの利用を推奨します。

Zabbix 4.4の主な変更点を以下に挙げます。

Zabbix agent 2

Zabbix agent 2と呼ばれる第二世代のエージェントが実装されました。Zabbix agent 2は Go 言語で実装されており、以下の特長があります。

• TCP接続数の削減
• チェックの並列性の向上
• プラグインによる拡張が容易
• 以前の Zabbix エージェントをそのまま置き換え可能

Webhook 通知

Webhook メディアタイプが追加され、 JavaScript によりアラートの拡張が可能になりました。これにより外部スクリプトを使用せずZabbix内で完結したWebベースのアラートの処理が行えます。

具体的な例としては、Webhook通知を使用してSlackへの通知を行うことができます(以下のマニュアルのサンプルを参照)。

4 Webhook

障害の監視データの表示

障害ビューの監視データの表示内容をトリガーの設定でカスタマイズできるようになりました。これにより障害発生時点の監視データではなく最新値を表示させることなどが可能です。

ローレベルディスカバリ

ローレベルディスカバリについて新たに以下が実装されました。

• ブロックデバイスのローレベルディスカバリ (vfs.dev.discovery)
• systemd サービスのローレベルディスカバリ (systemd.unit.discovery) (要 Zabbix agent 2)
• JMX MBeanディスカバリの非 ASCII 文字対応 (jmx.get)
• WMIディスカバリのためのアイテムの追加 (wmi.getall)

安全なエージェントの自動登録

PSK認証およびTLS暗号化された接続を使用した安全なエージェントの自動登録が可能になりました。

保存前処理

保存前処理について新たに以下が実装されました。

• JSON、XML、正規表現によるエラーチェックのカスタムエラー処理を追加
• LLD に XML 関係(XML XPath、XMLエラーチェック)の前処理オプションを追加

新規テンプレート

以下の新規テンプレートが追加されました。

• Nginx
• Apache
• RabbitMQ
• MySQL/MariaDB
• PostgreSQL

PostgreSQLのテンプレート(Template DB PostgreSQL)はUserParameterにより実装されています。詳細については以下を参照ください。

Requirements for PostgreSQL template

フロントエンド

ダッシュボードのウィジェットに様々な改良が行われました。

棒グラフ追加

グラフウィジェットで棒グラフ表示が可能になりました。

グラフ上の集約関数

ダッシュボードのグラフウィジェット上でmin、max、avgなどの集約関数を使用してデータを表示できるようになりました。これにより、累計チェックアイテムを作成することなく集約されたグラフを表示することが可能です。

4 Aggregation in graphs

深刻度ごとの障害数ウィジェットの拡張

深刻度ごとの障害数ウィジェットでホストグループ全体の障害数の合計をまとめて表示できるようになりました。縦横レイアウトが可能です。

Host availability ウィジェットの追加

ホストの稼働状況を集約して表示できるウィジェットが追加されました。インタフェースのタイプごとに稼働状況を表示することが可能です。縦横レイアウトが可能です。

グラフプロトタイプウィジェットの追加

LLDによりグラフプロトタイプから生成されたグラフを格子状に表示できるウィジェットが追加されました。

最新データのアイテムの説明アイコンの追加

[監視データ] – [最新データ]の各アイテムに説明を表示するアイコンが追加されました。

性能

アイテムの設定を格納するitemsテーブルのうちリアルタイムに更新されるフィールド(lastlogsize, state, mtime, error)が item_rtdata テーブルに分割されました。これによりZabbixサーバプロセスとフロントエンドからデータベースにアクセスする際の望ましくないロックが回避されるようになりました。

その他

その他以下のような改良、機能追加、変更が行われました。

• TimescaleDB (PostgreSQLの時系列データ拡張)の正式サポート
• エージェントの自動登録がDNS 名で可能
• ホストディスカバリでホスト名の長さを64文字から128文字に拡張
• データベース監視で複数行・列の返却が可能
• 依存アイテムの上限が999から29999に上昇
• Web監視およびHTTPエージェントでKerberos 認証のサポート
• メディアタイプのエクスポート・インポートが可能
• Jabber、Ez Textingメディアタイプの削除
• トリガーURLで{EVENT.ID}マクロが利用可能

既存の類似の機能

最初にRedisのメッセージ処理に適した既存の機能をいくつか紹介します。

Pub/Sub

RedisはPub/Subメッセージング機能を提供しています。SUBSCRIBE および PUBLISH コマンドにより、 Publisher(発行者)が送信したメッセージを複数の Subscriber(購読者)が受信することができます。PublisherはSubscriberを知っている必要がなく、メッセージを受け取れないPublisherがあってもSubscriberは影響を受けません。ただし、メッセージは保存されないため、SUBSCRIBEしていない期間のメッセージを受け取ることはできません。

Blocked list

Redisのリスト型はメッセージキューとして使うことができ、 BLPOP および BRPOP コマンドにより、リストの先頭もしくは末尾からデータ(メッセージ)の到着を待って受信することができます。複数のクライアントが同時に受信を待つことができますが、1つのメッセージを受け取った時点でそのメッセージは削除されるので、1つのメッセージを受け取れるのは1つのクライアントのみとなります。

ストリームの特徴

Redisストリームは前述のPub/SubおよびBlocked listに対して大幅に強化された機能をもちます。

Redisストリームは以下のような特徴があります。

• データを時系列で持つ追記型データ構造
• 各データは任意の複数のフィールドを持つことができる
• データを取得しても過去のデータを残せる
• 時間の範囲を指定して複数のデータを読み出せる
• コンシューマグループの概念によりクライアントをグループ化して協調動作できる

ストリームのデータ構造

Redisストリームのデータ構造自体は比較的シンプルです。

Redisストリームは追記専用のデータ構造です。各エントリは固有のIDを持ちます。IDは単調増加し、データ追加時にIDを指定しない場合は現在時刻から「<タイムスタンプ>-<連番>」の形式で自動生成されます。1つのエントリは任意の数のフィールドと値のペアで構成されます。

使用例

監視データをストリームに保存することを想定した場合の例

一定時間ごとに監視ツールで計測した監視データを時系列でストリームに保存するという用途を想定します。ここではストリームは単に時系列のデータ構造として使用し、1レコードにホストID、監視項目とその値を保存するものとします。

データを追加

XADDコマンドでストリーム名、ID、フィールド名と値を指定してデータを追加します。IDに「*」を指定するとIDを自動生成します。

> XADD history * hostid 1234 cpu.util 1.2
"1565915608548-0" (←自動生成されたID)
> XADD history * hostid 1350 mem.used 65.3
"1565915613858-0" (←自動生成されたID)
...

全範囲のメッセージを取得

XRANGEコマンドは指定した範囲のIDのデータを取得します。「-」は最小のID、「+」は最大のIDを意味するので、以下のコマンドはすべてのデータが取得されます。

> XRANGE history - +
1) 1) "1565915608548-0"
   2) 1) "hostid"
      2) "1234"
      3) "cpu.util"
      4) "1.2"
2) 1) "1565915613858-0"
   2) 1) "hostid"
      2) "1350"
      3) "mem.used"
      4) "65.3"

最初から1つ分のメッセージを取得

XREADコマンドは指定したIDより大きいIDを持つデータを取得します。ID 0 (0-0)は最小のIDを意味するので、ストリームの最初からデータを取得することになります。COUNTオプションで一回で取得するデータの数を指定できます。

> XREAD COUNT 1 STREAMS history 0
1) 1) "1565915608548-0"
   2) 1) "hostid"
      2) "1234"
      3) "cpu.util"
      4) "1.2"

簡易チャットの例

Slackのような複数チャンネルを持ち、過去の履歴も含めて参照可能なチャットシステムを簡易的に再現してみます。

チャンネル作成、発言

XADDコマンドでチャンネル名のストリームにメッセージを追加します。ストリームが存在しない場合は自動的に作成されます。格納するデータはメッセージ本体と発言者とします。

> XADD #channel * msg "channel #channel created."
"1565932257598-0"
> XADD #channel * msg "こんにちは" user "Taro"
"1565932327972-0"
> XADD #channel * msg "@Taro こんにちは!" user "Hanako"
"1565932387775-0"

新規に参加したユーザがチャンネルの最初からメッセージを取得

XREADコマンドでチャンネルの最初からすべてのメッセージを取得します。

> XREAD STREAMS #channel 0
1) 1) "#channel"
   2) 1) 1) "1565932257598-0"
         2) 1) "msg"
            2) "channel #channel created."
      2) 1) "1565932327972-0"
         2) 1) "msg"
            2) "こんにちは"
            3) "user"
            4) "Taro"
      3) 1) "1565932387775-0"
         2) 1) "msg"
            2) "@Taro こんにちは!"
            3) "user"
            4) "Hanako"

※UTF-8 文字列は実際にはエスケープされて出力されますが、分かりやすくするためそのまま記述しています。なお、redis-cliコマンドに–rawオプションを付けて起動するとそのまま出力できます。

新着メッセージを待つ(タイムアウト60秒)

XREADコマンドにBLOCKオプションを付けると、新しいメッセージが追加されるまで指定時間待ちます。IDに「$」を指定すると、XREADコマンドを発行した後に追加されたメッセージのみが対象となります。

> XREAD BLOCK 60000 STREAMS #channel $

誰かが60秒以内に発言する

> XADD #channel * msg "Redis Streamsでチャットを作ってみたよ" user "Jiro"
"1565932616524-0"

XREAD BLOCK が返り、メッセージが取得される

1) 1) "#channel"
   2) 1) 1) "1565932616524-0"
         2) 1) "msg"
            2) "Redis Streamsでチャットを作ってみたよ"
            3) "user"
            4) "Jiro"
(2.75s)

次のメッセージを待つ(既にあれば即座に取得)

連続してメッセージを取得する場合は前回取得した最後のIDを指定することに注意してください。再度「$」を指定してしまうと、途中のメッセージが抜け落ちる恐れがあります。

> XREAD BLOCK 60000 STREAMS #channel 1565932616524-0

監視データを複数クライアントで並列処理することを想定した場合の例

1つめの例で保存した監視データをコンシューマグループを利用し、複数のクライアントで協調して処理することを想定します。

ストリーム history に対してコンシューマグループ group1 を作成

XGROUPコマンドでコンシューマグループを作成します。IDに「0」を指定するとストリーム history の最初からデータを読み込みます。

> XGROUP CREATE history group1 0
OK

グループのメンバー C1 が他のメンバーによってまだ読まれていないデータを1つ読む

XREADGROUPコマンドでコンシューマグループを使用してデータを取得します。ここではコンシューマのメンバー「C1」としてデータを読みます。コンシューマがまだ存在しない場合は自動的に作成されます。IDに「>」を指定すると、他のコンシューマに送信されていない新しいメッセージを要求します。

> XREADGROUP GROUP group1 C1 COUNT 1 STREAMS history >
1) 1) "history"
   2) 1) 1) "1565915608548-0"
         2) 1) "hostid"
            2) "1234"
            3) "cpu.util"
            4) "1.2"

グループのメンバー C2 が他のメンバーによってまだ読まれていないデータを1つ読む

続いてメンバーC2が同様にデータを取得します。先程C1により取得されたデータではなくその次のメッセージが返ります。

> XREADGROUP GROUP group1 C2 COUNT 1 STREAMS history >
1) 1) "history"
   2) 1) 1) "1565915613858-0"
         2) 1) "hostid"
            2) "1350"
            3) "mem.used"
            4) "65.3"

C1 が取得したがペンディング状態のデータを確認

XREADGROUPでIDに「0」を指定すると、そのメンバーが取得し、かつペンディングとなっている(XACKを返していない)データが返ります。

> XREADGROUP GROUP group1 C1 STREAMS history 0
1) 1) "history"
   2) 1) 1) "1565915608548-0"
         2) 1) "hostid"
            2) "1234"
            3) "cpu.util"
            4) "1.2"

取得したデータが正常に処理できたことを伝える

コンシューマが取得したデータを正常に処理できたら、そのことをサーバにXACKコマンドで伝えることで一連の処理が完了します。XACKで指定したデータはペンディングエントリリストから削除されます。

> XACK history group1 1565915608548-0
(integer) 1

> XREADGROUP GROUP group1 C1 STREAMS history 0
1) 1) "history"
2) (empty list or set)

さらにデータを読む

以降も同様にメンバーC1、C2でデータを取得し、処理完了を通知します。

> XREADGROUP GROUP group1 C1 COUNT 1 STREAMS history >
1) 1) "history"
   2) 1) 1) "1565933823472-0"
         2) 1) "hostid"
            2) "1234"
            3) "proc.num[httpd]"
            4) "5"
> XREADGROUP GROUP group1 C2 COUNT 1 STREAMS history >
1) 1) "history"
   2) 1) 1) "1565933855023-0"
         2) 1) "hostid"
            2) "1350"
            3) "cpu.util"
            4) "0.3"

読んだことを確認

> XACK history group1 1565933823472-0
(integer) 1
> XACK history group1 1565915613858-0 1565933855023-0
(integer)

おわりに

今回はRedisストリームについて紹介しました。Redisストリームのデータ構造自体はシンプルですが、データにアクセスするための豊富な機能が用意されています。これにより、単純な時系列データの保存から大規模なメッセージングシステムまで、非常に柔軟な使い方が可能となっています。

2ノードで完結させたい場合や、その他のリソースもあわせて管理したい場合はPacemaker/Corosyncを使用するのが便利です。Pacemakerには標準でRedisのリソースエージェントが含まれているため、比較的容易にRedisのクラスタを構築することができます。

前提

以下の環境を前提とします。今回はOS標準のPacemakerを使用します。

• OS: CentOS 7.4
• パッケージ:
  • redis-5.0.5-1.el7.remi
  • pacemaker-1.1.19-8.el7_6.4
  • corosync-2.4.3-4.el7

RedisとPacemakerのクラスタ構成は以下のようになります。

Pacemakerのインストールと初期設定

両方のノードに必要なパッケージをインストールします。なお、Redisのインストールおよびマスター・スレーブレプリケーションの設定は完了しているものとします。

# yum install corosync pacemaker pcs fence-agents-all

クラスタを新規作成します。

server1# pcs cluster auth server1 server2 -u hacluster -p (haclusterユーザのパスワード) --force
server1# pcs cluster setup --name cluster1 server1 server2

corosync.conf の quorum の設定に以下を追加します。これは2ノードクラスタで片方のノード単独で起動できるようにするために必要です(理由は後述します)。

quorum {
    provider: corosync_votequorum
    two_node: 1
    wait_for_all: 0  ★追加
}

クラスタを起動します。

server1# pcs cluster start --all

server1# pcs status
Cluster name: cluster1
Stack: corosync
Current DC: server1 (version 1.1.19-8.el7_6.4-c3c624ea3d) - partition with quorum
Last updated: Mon Jul  1 16:57:00 2019
Last change: Mon Jul  1 16:56:58 2019 by root via cibadmin on server1

2 nodes configured
0 resources configured

Online: [ server1 server2 ]

No resources


Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

今回は動作確認のためSTONITHを無効化し、1回の障害検知でフェイルオーバーするように設定します。

# pcs property set stonith-enabled=false
# pcs resource defaults resource-stickiness=INFINITY migration-threshold=1

Pacemakerリソースの作成

仮想IPリソースを作成します。

# pcs resource create VIP ocf:heartbeat:IPaddr2 
  ip=192.168.237.150 cidr_netmask=24 nic=eth1 
  op monitor interval=10s

Redisのマスター・スレーブリソースを作成します。Pacemakerのマスター・スレーブリソースは、複数のノードに複製され、主従関係をもつリソースです。リソースエージェントは resource-agents パッケージに含まれる ocf:heartbeat:redis を使用します。以下の例では、redisリソースおよびそのマスター・スレーブリソースを一度に作成しています。マスター・スレーブリソースはデフォルトで「<リソースID>-master」(redis-master)という名前が付きます。

# pcs resource create redis ocf:heartbeat:redis 
  op start timeout=300s 
  op monitor interval=5s 
  op monitor interval=3s role=Master 
  master

VIPリソースとRedisのマスター・スレーブリソースのマスター側を colocation 制約で同じサーバに結び付けます。

# pcs constraint colocation add VIP with master redis-master score=INFINITY

この時点でリソースは起動しますが、一度両ノードのPacemakerを停止します。設定中にリソースを起動させたくない場合は先に両ノードをスタンバイモード(pcs node standby/unstandby)にしておいてもよいです。

server2# systemctl stop pacemaker
server1# systemctl stop pacemaker

クラスタの起動

Masterにしたいノード(server1)でPacemakerを起動します。

server1# systemctl start pacemaker
server1# pcs status
Cluster name: cluster1
Stack: corosync
Current DC: server1 (version 1.1.19-8.el7_6.4-c3c624ea3d) - partition with quorum
Last updated: Fri Jul 19 14:20:49 2019
Last change: Fri Jul 19 14:15:52 2019 by root via crm_attribute on server2

2 nodes configured
3 resources configured

Online: [ server1 ]
OFFLINE: [ server2 ]

Full list of resources:

 VIP    (ocf::heartbeat:IPaddr2):       Started server1
 Master/Slave Set: redis-master [redis]
     Masters: [ server1 ]
     Stopped: [ server2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

server1ですべてのリソースの起動が完了したことを確認したら、server2のPacemakerを起動します。

server2# systemctl start pacemaker

しばらく待ち、リソースの起動が正常に完了すると以下のようになります。

# pcs status
Cluster name: cluster1
Stack: corosync
Current DC: server1 (version 1.1.19-8.el7_6.4-c3c624ea3d) - partition with quorum
Last updated: Fri Jul 19 14:24:24 2019
Last change: Fri Jul 19 14:15:52 2019 by root via crm_attribute on server2

2 nodes configured
3 resources configured

Online: [ server1 server2 ]

Full list of resources:

 VIP    (ocf::heartbeat:IPaddr2):       Started server1
 Master/Slave Set: redis-master [redis]
     Masters: [ server1 ]
     Slaves: [ server2 ]

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

# pcs constraint
Location Constraints:
Ordering Constraints:
Colocation Constraints:
  VIP with redis-master (score:INFINITY) (rsc-role:Started) (with-rsc-role:Master)
Ticket Constraints:

Redisのレプリケーションが正常に行われていることを確認します。

server1# redis-cli info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.237.102,port=6379,state=online,offset=1372,lag=0

server2# redis-cli info replication
# Replication
role:slave
master_host:server1
master_port:6379
master_link_status:up

また、MasterノードにVIPが割り振られていることを確認します。

server1# ip -4 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.237.101/24 brd 192.168.237.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet 192.168.237.150/24 brd 192.168.237.255 scope global secondary eth1
       valid_lft forever preferred_lft forever

server2# ip -4 addr show dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.237.102/24 brd 192.168.237.255 scope global eth1
       valid_lft forever preferred_lft forever

フェイルオーバー

RedisのMasterプロセスに障害を発生させ、server2がMasterになることを確認します。

server1# killall redis-server
server1# pcs status
Cluster name: cluster1
Stack: corosync
Current DC: server1 (version 1.1.19-8.el7_6.4-c3c624ea3d) - partition with quorum
Last updated: Fri Jul 19 15:34:23 2019
Last change: Fri Jul 19 15:33:18 2019 by root via crm_attribute on server2

2 nodes configured
3 resources configured

Online: [ server1 server2 ]

Full list of resources:

 VIP    (ocf::heartbeat:IPaddr2):       Started server2
 Master/Slave Set: redis-master [redis]
     Masters: [ server2 ]
     Stopped: [ server1 ]

Failed Actions:
* redis_demote_0 on server1 'not running' (7): call=49, status=complete, exitreason='',
    last-rc-change='Fri Jul 19 15:33:18 2019', queued=0ms, exec=85ms


Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

redis リソースをクリーンアップし、server1がSlaveとして復旧することを確認します。

server1# pcs resource cleanup redis
Cleaned up redis:0 on server2
Cleaned up redis:0 on server1
Cleaned up redis:1 on server2
Cleaned up redis:1 on server1
Waiting for 1 replies from the CRMd. OK

# pcs status resources
 VIP    (ocf::heartbeat:IPaddr2):       Started server2
 Master/Slave Set: redis-master [redis]
     Masters: [ server2 ]
     Slaves: [ server1 ]

リソース起動時の注意点

Pacemaker/Corosyncの2ノードクラスタのデフォルトでは、両ノードのPacemakerが起動した時点でリソースを起動します。この場合、RedisのMasterとSlaveはほぼ同時に起動し、Masterの準備が完了していない状態でSlaveが接続しようとするため、レプリケーションの開始に失敗する場合があります。これを防ぐため、上記手順ではCorosyncの設定を変更し、Masterの起動を待ってからSlaveを起動するようにしています。

Redis Cluster

Redis Cluster は Redis 3.0 で実装されました。Redis Cluster はマルチマスター構成をとり、データは複数のRedisサーバに自動的に分散されます(シャーディング)。これにより書き込み負荷を分散させることができます。Redis Cluster は一部のノードが故障しても動作を継続し、ある程度の可用性を提供しますが、多数のノードが利用不可となった場合は動作を停止します。各マスターノードにはスレーブを持たせ、可用性を向上することができます。クラスタの最小構成は3マスターノードとなります。

Clusterが使用するポートは通常のポートに加え、クラスタの通信用に+10000したポート番号を使用します(6379の場合は16739)。

シャーディング

Redis Cluster はクラスタ全体で16384個(0～16383)のhash slotをもちます。各ノードにhash slotの一部分が割り当てられます。例えば以下のようになります。

• ノードA: 0～5460 の hash slot
• ノードB: 5461～10922 の hash slot
• ノードC: 10923～16383 の hash slot

クライアントがキーを登録するとき、キーごとにhash slotの値を計算し、対応するノードにデータが格納されます。キーからhash slotの値を求めるアルゴリズムは以下のようにシンプルなものとなります。

HASH_SLOT = CRC16(key) mod 16384

各ノードのhash slotは後から自由に移動することができるため、後からノードを追加したりノードを削除することが可能です。

Cluster の設定

本来は複数台のマシンで動作させますが、今回は1台のマシン上でポート番号を変えて6台の Cluster ノードを作成します。

ノードごとに個別のディレクトリを作成し、既存の redis.conf をコピーして設定を行います。

# mkdir cluster-test
# cd cluster-test/
# mkdir 7000 7001 7002 7003 7004 7005
# cp /etc/redis.conf 7000
# vi 7000/redis.conf
# cp 7000/redis.conf 7001
# vi 7001/redis.conf
...
# vi 7005/redis.conf

同サーバ上で動かすため、ファイル名が重複しないように適切に設定を行います。

port 7000
pidfile "/var/run/redis_7000.pid"
logfile "/root/cluster-test/7000/redis.log"
dbfilename "dump-7000.rdb"
appendonly yes
appendfilename "appendonly-7000.aof"
cluster-enabled yes
cluster-config-file nodes-7000.conf

各ノードを起動します。

# redis-server 7000/redis.conf
# redis-server 7001/redis.conf
# redis-server 7002/redis.conf
# redis-server 7003/redis.conf
# redis-server 7004/redis.conf
# redis-server 7005/redis.conf

正常にプロセスが立ち上がり、 redis.log にエラーが出力されていないことを確認します。

# ps auxww|grep redis
root 2939 0.1 0.1 153952 2772 ? Ssl 14:23 0:00 redis-server 0.0.0.0:7000 [cluster]
root 2980 0.1 0.1 153952 2768 ? Ssl 14:24 0:00 redis-server 0.0.0.0:7001 [cluster]
root 2985 0.2 0.1 153952 2768 ? Ssl 14:24 0:00 redis-server 0.0.0.0:7002 [cluster]
root 2990 0.2 0.1 153952 2772 ? Ssl 14:24 0:00 redis-server 0.0.0.0:7003 [cluster]
root 2995 0.3 0.1 153952 2776 ? Ssl 14:25 0:00 redis-server 0.0.0.0:7004 [cluster]
root 3000 0.7 0.1 153952 2776 ? Ssl 14:25 0:00 redis-server 0.0.0.0:7005 [cluster]

/var/lib/redis 以下に各ノードの AOF およびクラスタ設定ファイルが作成されます。

# ls -l /var/lib/redis/
合計 24
-rw-r--r--. 1 root root 0 6月 28 14:23 appendonly-7000.aof
-rw-r--r--. 1 root root 0 6月 28 14:24 appendonly-7001.aof
-rw-r--r--. 1 root root 0 6月 28 14:24 appendonly-7002.aof
-rw-r--r--. 1 root root 0 6月 28 14:25 appendonly-7003.aof
-rw-r--r--. 1 root root 0 6月 28 14:25 appendonly-7004.aof
-rw-r--r--. 1 root root 0 6月 28 14:25 appendonly-7005.aof
-rw-r--r--. 1 root root 114 6月 28 14:23 nodes-7000.conf
-rw-r--r--. 1 root root 114 6月 28 14:24 nodes-7001.conf
-rw-r--r--. 1 root root 114 6月 28 14:24 nodes-7002.conf
-rw-r--r--. 1 root root 114 6月 28 14:25 nodes-7003.conf
-rw-r--r--. 1 root root 114 6月 28 14:25 nodes-7004.conf
-rw-r--r--. 1 root root 114 6月 28 14:25 nodes-7005.conf

次に、クラスタを作成します。 –cluster-replicas 1 はマスターごとに1つのレプリカ(スレーブ)を配置することを意味します。
なお、 Redis 3.0、4.0 の場合は redis-cli の代わりに redis-trib.rb という外部ツールを使用する必要があります。

# redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 
127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 
--cluster-replicas 1

自動的にマスターとレプリカの割り当てが行われます。よければ yes を入力します。

>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 127.0.0.1:7004 to 127.0.0.1:7000
Adding replica 127.0.0.1:7005 to 127.0.0.1:7001
Adding replica 127.0.0.1:7003 to 127.0.0.1:7002
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: 70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111 127.0.0.1:7000
slots:[0-5460] (5461 slots) master
M: a5b82da0c32957954a3da1e16a3629083a8d5d8c 127.0.0.1:7001
slots:[5461-10922] (5462 slots) master
M: a18a55b7a4790c2bd1bd7fae057caa4144a03a52 127.0.0.1:7002
slots:[10923-16383] (5461 slots) master
S: 4d18eed5d6cdfc394f8cfa14a3655147393e3627 127.0.0.1:7003
replicates a5b82da0c32957954a3da1e16a3629083a8d5d8c
S: 04a2ad5e2b0ea06bc9d90c3ab3c4214b2ac5cce9 127.0.0.1:7004
replicates a18a55b7a4790c2bd1bd7fae057caa4144a03a52
S: 0a0dfeb8456c6bff470eddb24edae8743d6422ff 127.0.0.1:7005
replicates 70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
...
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111 127.0.0.1:7000
slots:[0-5460] (5461 slots) master
1 additional replica(s)
S: 0a0dfeb8456c6bff470eddb24edae8743d6422ff 127.0.0.1:7005
slots: (0 slots) slave
replicates 70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111
S: 04a2ad5e2b0ea06bc9d90c3ab3c4214b2ac5cce9 127.0.0.1:7004
slots: (0 slots) slave
replicates a18a55b7a4790c2bd1bd7fae057caa4144a03a52
M: a5b82da0c32957954a3da1e16a3629083a8d5d8c 127.0.0.1:7001
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
M: a18a55b7a4790c2bd1bd7fae057caa4144a03a52 127.0.0.1:7002
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: 4d18eed5d6cdfc394f8cfa14a3655147393e3627 127.0.0.1:7003
slots: (0 slots) slave
replicates a5b82da0c32957954a3da1e16a3629083a8d5d8c
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

クラスタの構成が正常に完了すると [OK] All 16384 slots covered. というメッセージが出力されます。
なお、マスターとレプリカの組み合わせを自分で決定したい場合は、
最初にマスターのみでクラスタを構成した後、マスターを指定してレプリカを1つずつ追加していきます。

# redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002

# redis-cli --cluster add-node 127.0.0.1:7003 127.0.0.1:7000 --cluster-slave --cluster-master-id 70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111
# redis-cli --cluster add-node 127.0.0.1:7004 127.0.0.1:7001 --cluster-slave --cluster-master-id a5b82da0c32957954a3da1e16a3629083a8d5d8c
# redis-cli --cluster add-node 127.0.0.1:7005 127.0.0.1:7002 --cluster-slave --cluster-master-id a18a55b7a4790c2bd1bd7fae057caa4144a03a52

任意のノードに redis-cli で接続し、 cluster nodes コマンドを実行するとノードの一覧を取得することができます。これは nodes-7000.conf とほぼ同じ内容になります。

# redis-cli -p 7000 cluster nodes
0a0dfeb8456c6bff470eddb24edae8743d6422ff 127.0.0.1:7005@17005 slave 70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111 0 1561702297172 6 connected
70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111 127.0.0.1:7000@17000 myself,master - 0 1561702298000 1 connected 0-5460
04a2ad5e2b0ea06bc9d90c3ab3c4214b2ac5cce9 127.0.0.1:7004@17004 slave a18a55b7a4790c2bd1bd7fae057caa4144a03a52 0 1561702299186 5 connected
a5b82da0c32957954a3da1e16a3629083a8d5d8c 127.0.0.1:7001@17001 master - 0 1561702296161 2 connected 5461-10922
a18a55b7a4790c2bd1bd7fae057caa4144a03a52 127.0.0.1:7002@17002 master - 0 1561702298000 3 connected 10923-16383
4d18eed5d6cdfc394f8cfa14a3655147393e3627 127.0.0.1:7003@17003 slave a5b82da0c32957954a3da1e16a3629083a8d5d8c 0 1561702298181 4 connected

Clusterの動作確認

redis-cli に -c を付けるとクラスタモードになります。これで動作を確認します。

# redis-cli -c -p 7000
127.0.0.1:7000> set foo 1
-> Redirected to slot [12182] located at 127.0.0.1:7002
OK
127.0.0.1:7002> get foo
"1"
127.0.0.1:7002> set bar 2
-> Redirected to slot [5061] located at 127.0.0.1:7000
OK
127.0.0.1:7000> get bar
"2"
127.0.0.1:7000> get foo
-> Redirected to slot [12182] located at 127.0.0.1:7002
"1"
127.0.0.1:7002> get hoge
-> Redirected to slot [1525] located at 127.0.0.1:7000
(nil)
127.0.0.1:7000> incr foo
-> Redirected to slot [12182] located at 127.0.0.1:7002
(integer) 2
127.0.0.1:7002> get foo
"2"

キーに応じてslotが変化し、対応するノードに自動的に接続を切り替えていることがわかります。

Clusterのクエリの制限

Clusterではキーごとに格納されるノードが異なるため、クライアント側でキーに対応するノードを知る必要があります(対応するノードはサーバから通知されます)。また、キーが複数のノードにまたがっている場合、複数のキーをまとめて取得する mget のようなコマンドは失敗します。

複数のキーを同じノードに割り当てたい場合、ハッシュタグ({ } で囲まれた文字列)を利用することができます。キーの一部に {…} という文字列を含めることで、 { } 内の文字列のみが hash slot の計算に使用されるようになります。以下の2つのキーは同一の hash slot となり、同じノードに格納されます。

{foo}hoge
{foo}fuga

フェイルオーバー

7000番ポートのmasterに障害を発生させます。

# kill 2939
# ps auxww|grep redis
root 2980 0.1 0.1 156512 3256 ? Ssl 14:24 0:07 redis-server 0.0.0.0:7001 [cluster]
root 2985 0.1 0.1 158560 3284 ? Ssl 14:24 0:07 redis-server 0.0.0.0:7002 [cluster]
root 2990 0.2 0.2 167264 4144 ? Ssl 14:24 0:07 redis-server 0.0.0.0:7003 [cluster]
root 2995 0.2 0.1 160608 3372 ? Ssl 14:25 0:07 redis-server 0.0.0.0:7004 [cluster]
root 3000 0.2 0.1 160608 3376 ? Ssl 14:25 0:07 redis-server 0.0.0.0:7005 [cluster]

cluster nodes の表示が fail となります。

# redis-cli -p 7001 cluster nodes
70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111 127.0.0.1:7000@17000 master,fail - 1561703162227 1561703160916 1 disconnected 0-5460
a5b82da0c32957954a3da1e16a3629083a8d5d8c 127.0.0.1:7001@17001 myself,master - 0 1561703190000 2 connected 5461-10922
a18a55b7a4790c2bd1bd7fae057caa4144a03a52 127.0.0.1:7002@17002 master - 0 1561703189000 3 connected 10923-16383
04a2ad5e2b0ea06bc9d90c3ab3c4214b2ac5cce9 127.0.0.1:7004@17004 slave a18a55b7a4790c2bd1bd7fae057caa4144a03a52 0 1561703190193 3 connected
0a0dfeb8456c6bff470eddb24edae8743d6422ff 127.0.0.1:7005@17005 slave 70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111 0 1561703189185 1 connected
4d18eed5d6cdfc394f8cfa14a3655147393e3627 127.0.0.1:7003@17003 slave a5b82da0c32957954a3da1e16a3629083a8d5d8c 0 1561703188000 4 connected

しばらくすると自動的に7000番ポートのmasterのslaveである7005番ポートのノードがmasterに昇格し、フェイルオーバーが完了します。

# redis-cli -p 7001 cluster nodes
70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111 127.0.0.1:7000@17000 master,fail - 1561703162227 1561703160916 1 disconnected
a5b82da0c32957954a3da1e16a3629083a8d5d8c 127.0.0.1:7001@17001 myself,master - 0 1561703238000 2 connected 5461-10922
a18a55b7a4790c2bd1bd7fae057caa4144a03a52 127.0.0.1:7002@17002 master - 0 1561703240648 3 connected 10923-16383
04a2ad5e2b0ea06bc9d90c3ab3c4214b2ac5cce9 127.0.0.1:7004@17004 slave a18a55b7a4790c2bd1bd7fae057caa4144a03a52 0 1561703242665 3 connected
0a0dfeb8456c6bff470eddb24edae8743d6422ff 127.0.0.1:7005@17005 master - 0 1561703242000 8 connected 0-5460
4d18eed5d6cdfc394f8cfa14a3655147393e3627 127.0.0.1:7003@17003 slave a5b82da0c32957954a3da1e16a3629083a8d5d8c 0 1561703240000 4 connected

7000番ポートのRedisを再度起動すると、7005番ポートのmasterのslaveとして立ち上がり、再同期が行われます。

# redis-server 7000/redis.conf
# redis-cli -p 7001 cluster nodes
70ed8f0f72ee70d2b55adfa722fcf1f9eb0c8111 127.0.0.1:7000@17000 slave 0a0dfeb8456c6bff470eddb24edae8743d6422ff 0 1561703557658 8 connected
a5b82da0c32957954a3da1e16a3629083a8d5d8c 127.0.0.1:7001@17001 myself,master - 0 1561703558000 2 connected 5461-10922
a18a55b7a4790c2bd1bd7fae057caa4144a03a52 127.0.0.1:7002@17002 master - 0 1561703559675 3 connected 10923-16383
04a2ad5e2b0ea06bc9d90c3ab3c4214b2ac5cce9 127.0.0.1:7004@17004 slave a18a55b7a4790c2bd1bd7fae057caa4144a03a52 0 1561703556649 3 connected
0a0dfeb8456c6bff470eddb24edae8743d6422ff 127.0.0.1:7005@17005 master - 0 1561703558000 8 connected 0-5460
4d18eed5d6cdfc394f8cfa14a3655147393e3627 127.0.0.1:7003@17003 slave a5b82da0c32957954a3da1e16a3629083a8d5d8c 0 1561703558667 4 connected

おわりに

今回はRedisの標準機能の一つであるRedis Clusterについて紹介しました。Redis Clusterは必要なサーバ台数が多くなるものの、負荷分散と可用性を両立させることができます。

次回はPacemakerを用いたRedisの冗長化について紹介します。

前回のRedisの紹介では、Redisの特長や導入手順、基本的な使い方についてご紹介しました。本稿では、インメモリデータベースのデータ永続化についてご紹介します。

Redisはインメモリデータベースであるため、サーバプロセスが終了するとメモリ上のデータも消えてしまいます。そこで、Redisはサーバプロセス終了後もデータを保持するための2種類の機能が用意されています。

RDB

Redisでは特定の時点のスナップショットをRDBファイルとして保存することができます。RDBはデータベースのダンプファイルに相当します。SAVEコマンドおよびBGSAVEコマンドで現時点のスナップショットを保存できます。また、設定により、一定の書き込み数と時間の経過により自動的にデータを保存することもできます。デフォルトの設定は以下のようになっており、条件を満たした場合にデータが自動保存されます。なお、「save “”」と設定することで自動保存を無効化することも可能です。

• 900秒後に1個以上のキーが変更
• 300秒後に10個以上のキーが変更
• 60秒後に10000個以上のキーが変更

save 900 1
save 300 10
save 60 10000

RDBファイルはRedisの起動時に自動的に読み込まれ、前回終了時のデータが復元されます。

AOF (Append Only File)

多くの場合は前述のRDBファイルの自動保存でも十分ですが、サーバプロセスの障害や電源断などが発生した場合、直近の数分程度のデータを失う可能性があります。

この問題を回避するのがAOF (Append Only File)となります。

AOFはデータベースのWAL/REDOログに似た書き込みログで、すべての書き込みコマンドが追記で記録されます。AOFはデフォルトでは1秒ごとにfsyncによりディスクに同期される(appendfsync everysec)ので、データを失う可能性のある期間は1秒以内に抑えられます。なお、1回の書き込みごとにfsyncを呼び出すようにする(appendfsync always)こともできますが、非常に遅くなります。

AOFはデフォルトでは無効です。以下の設定で有効にすることができます。また、RDBと同時に使用することもでき、AOFとRDBを両方有効にすることが推奨されています。

appendonly yes

AOFファイルはRedisの起動時に自動的に読み込まれます。AOFファイルとRDBファイルの両方が存在する場合はAOFファイルが優先されます。なお、AOFファイルが存在しない状態でAOFを有効にして再起動すると空のAOFファイルを作成するため、すべてのデータが初期化されてしまうのでご注意ください。

バックアップ

RDB

前述の通り、SAVEコマンドもしくはBGSAVEコマンドで現時点のデータのスナップショットをRDBファイルに保存することができます。SAVEコマンドは他のクライアントからのアクセスをすべてブロックしてしまうため、通常はバックグラウンドでデータを保存するBGSAVEコマンドを使用します。BGSAVEコマンドが完了したかどうかはLASTSAVEコマンドで確認できます。RDBファイルはRedisサーバプロセス終了時にも保存されます。

127.0.0.1:6379> save #保存が完了するまで他の操作はすべてブロックされる
OK
127.0.0.1:6379> lastsave #最終保存時刻(Unix時間)を確認
(integer) 1559267764
127.0.0.1:6379> bgsave #バックグラウンドで保存(すぐに処理が返ってくる)
Background saving started
127.0.0.1:6379> lastsave #最終保存時刻が更新されていることを確認
(integer) 1559267778

RHEL 7 / CentOS 7のRemiリポジトリのRedisパッケージでは、デフォルトで以下の場所にRDBファイルが保存されます。

/var/lib/redis/dump.rdb

このファイルを別の安全な場所に保存します。なお、RDBファイルはアトミックに作成されるので、中途半端な状態のファイルを保存してしまう心配はありません。

# cp /var/lib/redis/dump.rdb /path/to/redis-dump-YYYYMMDD.rdb

redis-check-rdbコマンドでRDBファイルの正常性を確認することができます。

# redis-check-rdb /tmp/redis-backup-20190531.rdb
[offset 0] Checking RDB file /tmp/redis-backup-20190531.rdb
[offset 26] AUX FIELD redis-ver = '5.0.5'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1559268270'
[offset 67] AUX FIELD used-mem = '1860912'
[offset 83] AUX FIELD aof-preamble = '0'
[offset 85] Selecting DB ID 0
[offset 14677] Checksum OK
[offset 14677] o/ RDB looks OK! o/
[info] 6 keys read
[info] 0 expires
[info] 0 already expired

AOF

RDBのみ有効にした状態からAOFを有効にするには以下のようにします。なお、redis.confのみ修正して再起動すると、前述の通りすべてのデータが初期化されてしまうのでご注意ください。

# redis-cli config set appendonly yes
OK
# vi /etc/redis.conf
appendonly no
↓ 修正
appendonly yes

デフォルトでは以下の場所にAOFファイルが保存されます。

/var/lib/redis/appendonly.aof

AOFは追記型のため、RDBに比べてファイルサイズが大きくなります。そのためバックアップの取得にはRDBが適しています。BGREWRITEAOFコマンドでAOFを再構成し、ファイルサイズを縮小できます。再構成は自動でも行われます。

# ls -l /var/lib/redis/
合計 64152
-rw-r--r--. 1 redis redis 65614804 5月 31 11:32 appendonly.aof
-rw-r--r--. 1 redis redis 21887 5月 31 11:33 dump.rdb
# redis-cli bgrewriteaof
Background append only file rewriting started
# ls -l /var/lib/redis/
合計 48
-rw-r--r--. 1 redis redis 21887 5月 31 11:37 appendonly.aof
-rw-r--r--. 1 redis redis 21887 5月 31 11:33 dump.rdb

redis-check-aofコマンドでAOFファイルの正常性を確認することができます。

# redis-check-aof /var/lib/redis/appendonly.aof
The AOF appears to start with an RDB preamble.
Checking the RDB preamble to start:
[offset 0] Checking RDB file /var/lib/redis/appendonly.aof
[offset 26] AUX FIELD redis-ver = '5.0.5'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1559269522'
[offset 67] AUX FIELD used-mem = '1859808'
[offset 83] AUX FIELD aof-preamble = '1'
[offset 85] Selecting DB ID 0
[offset 14677] Checksum OK
[offset 14677] o/ RDB looks OK! o/
[info] 6 keys read
[info] 0 expires
[info] 0 already expired
RDB preamble is OK, proceeding with AOF tail...
AOF analyzed: size=65614804, ok_up_to=65614804, diff=0
AOF is valid

リストア

RDB

AOFは無効で、RDBのみ使用している場合は以下のようにしてリストアします。

1. Redisを停止

# systemctl stop redis

2. RDBファイルを書き戻す

# mv /var/lib/redis/dump.rdb /var/lib/redis/dump.rdb.bak
# cp /path/to/redis-dump-YYYYMMDD.rdb /var/lib/redis/dump.rdb
# chown redis:redis /var/lib/redis/dump.rdb

3. Redisを起動

# systemctl start redis

AOF

AOFファイルからリストアする場合は次のようにします。

1. Redisを停止

# systemctl stop redis

2. AOFファイルを書き戻す

# mv /var/lib/redis/dump.rdb /var/lib/redis/dump.rdb.bak (RDBも有効の場合)
# mv /var/lib/redis/appendonly.aof /var/lib/redis/appendonly.aof.bak 
# cp /path/to/redis-appendonly-YYYYMMDD.aof /var/lib/redis/appendonly.aof
# chown redis:redis /var/lib/redis/appendonly.aof

3. Redisを起動

# systemctl start redis

RDB (AOF有効時)

AOFを有効にしている場合にRDBファイルからリストアする場合は注意が必要です。前述の通り、AOFファイルがない場合は起動時に空のAOFファイルを作成し、そちらを参照するため、RDBファイルを配置しても無視されてデータが初期化されてしまいます。そのため、以下の手順のように、AOFを一時的に無効化してRDBファイルからリストアした後AOFを再作成し、AOFの設定を有効化する必要があります。

1. Redisを停止

# systemctl stop redis

2. RDBファイルを書き戻す

# mv /var/lib/redis/dump.rdb /var/lib/redis/dump.rdb.bak
# mv /var/lib/redis/appendonly.aof /var/lib/redis/appendonly.aof.bak
# cp /path/to/redis-dump-YYYYMMDD.rdb /var/lib/redis/dump.rdb
# chown redis:redis /var/lib/redis/dump.rdb

3. AOFを無効化してRedisを起動

# vi /etc/redis.conf
appendonly yes → appendonly no

# systemctl start redis

4. AOFファイルを書き出す

# redis-cli bgrewriteaof
Background append only file rewriting started
# redis-cli info | grep aof_rewrite_in_progress
aof_rewrite_in_progress:0
# ls -l /var/lib/redis/
合計 80
-rw-r--r--. 1 redis redis 14677 5月 31 15:21 appendonly.aof
-rw-r--r--. 1 redis redis 21887 5月 31 11:37 appendonly.aof.bak
-rw-r--r--. 1 redis redis 14677 5月 31 15:19 dump.rdb
-rw-r--r--. 1 redis redis 21887 5月 31 14:33 dump.rdb.bak

5. AOFを有効化してRedisを再起動

# systemctl stop redis
# vi /etc/redis.conf
appendonly no → appendonly yes
# systemctl start redis

おわりに

Redisはインメモリデータベースですが、データの永続化が可能となっています。Redisのバックアップ・リストアも非常に簡単で、AOFにより耐障害性の向上も図ることができます。しかしながら、RDBとAOFを両方使用する場合の操作については注意が必要なところがあります。