intra-mart Accel Platform Cassandra管理者ガイド 第15版 2018-12-01

9. Cassandra の運用

ここでは Cassandra の運用方法を説明します。

9.1. 状態変化のタイミングとリスク

Cassandra の運用状態が変化するタイミングと、その時のリスクについて考察します。

9.1.1. 計画停止

手動やサービスによって、意図したタイミングで停止した場合を想定します。
また前提として、Cassandraを停止するタイミングではApplicationServerからの更新要求がないものとします。

コラム

対応例

  • 停止前にApplicationServerを停止する。
  • nodetool drain コマンド を実行し、書き込み要求を受け付けなくする。

drain の実行時には、同時にフラッシュも実行されます。

  • フラッシュに成功した場合
    通常期待される状態です。フラッシュが実行されているためデータ損失はなく、当然ながら対策を検討する必要はありません。
  • フラッシュに失敗した場合
    通常は計画停止した場合はフラッシュが実行され停止時のデータが担保されますが、停止時にフラッシュが失敗する場合があります。
    フラッシュが正常に実行されていないため、メモリ上に存在していたデータが失われます。

9.1.2. 異常停止

Cassandraが何らかの原因により、意図せず停止した場合を想定します。

コラム

以下のような状況が想定されます。

  • Cassandra内でサービスの継続が不可能な例外(OutOfMemoryError)が発生した場合
  • Cassandraのプロセスが強制停止された場合
  • Cassandra起動中にOSが停止した場合
  • フラッシュが実行されていた場合
    異常停止前にフラッシュが実行される場合があります。
    フラッシュが実行されているためデータ損失はなく、当然ながら対策を検討する必要はありません。
  • フラッシュが実行されない、または失敗した場合
    異常停止前には通常フラッシュが実行されません。また、実行されても失敗する可能性があります。
    フラッシュが正常に実行されていないため、メモリ上に存在していたデータが失われます。

コラム

計画停止、異常停止に関わらず、フラッシュ失敗によるデータ損失のリスクが存在します。

9.1.3. ネットワークの分断

Cassandraのノードがネットワークから分断された場合は、データの損失が発生する事はありません。
ただし、構成の状態によってはサービスが利用できなくなります。
  • 単一ノードにて構築されている場合
    Cassandraが復旧するまでIMBoxは利用できなくなります。

    コラム

    単一ノードにて運用する場合は、ネットワークが分断した時点で読み込み/書き込みが行えなくなるため、データ損失は発生しません。
  • クラスタ構成で構築されている場合
    ネットワークから分断されたノード数により状況が変化します。
    • サービス継続が可能な台数の場合
      例えば「ノード数が3台(レプリケーションファクタが3)」で運用中に1台が分断された場合、サービスは他の2台のノードで正常に行われます。
      分断されたノードが再度ネットワークに接続されたタイミングで不足分のデータがレプリケート(コピー)され、通常の運用状態に復旧します。
    • サービス継続が不可能な台数の場合
      Cassandraが復旧するまでIMBoxは利用できなくなります。
      例えば「ノード数が3台、レプリケーションファクタが3」の場合に2台が分断された場合、サービスが利用不可となります。
      サービスが利用不可になり読み込み/書き込みが行えなくなるため、データ損失は発生しません。

9.2. リスク対策

前項より、基本的にフラッシュの失敗または未実施の場合について対策を取る必要があります。
対応策について以下にて幾つかの案を考察します。

9.2.1. 計画停止前のフラッシュ実行

計画停止前に1度フラッシュ処理を実施します。
これにより、計画停止時に実行されるフラッシュの失敗に対するリスクを回避可能です。

9.2.2. 定期的なフラッシュ実行

Cassandra起動時にcronなどで定期的なフラッシュを実行し、異常停止などによってデータが損失した場合でも、最後にフラッシュを実行した時点までの内容を担保します。

コラム

この対策はあくまでもデータ損失の確率や損失量を軽減する対策になります。
フラッシュ に関してはこちらを参照してください。

コラム

フラッシュ実行の頻度については、運用設計にて要求される条件との調整が必要です。
検討が必要な項目として、以下が考えられます。
  • データ損失の可能性が許容される最大の時間
  • フラッシュの定期実行によるI/O負荷増加によるサービスのレスポンスやサーバ負荷への影響

9.2.3. クラスタ構成の構築

Cassandraのクラスタを構築して運用することで、データ損失およびサービス停止の可能性を大きく軽減する事が可能です。
このとき、クラスタを構成するノード数は3ノード以上を強く推奨します。
  • ノード数が2台の場合
    クラスタを構成するノードが2ノードであった場合には、いずれか1ノードが停止した時点でサービスの継続(データの読み込みおよび書き込み)が不可能となります。
    ただし、サービス継続不可能となった時点でデータの書き込みは行われないため、データの損失は発生しません。
  • ノード数が3台(またはそれ以上)の場合
    クラスタを構成するノードが3ノード(およびレプリケーションファクタが3)であった場合、いずれか1ノードが停止してもサービスは継続可能です。
    停止したノードが復旧したタイミングで、停止していたノードに対して不足しているデータがレプリケート(コピー)され、レプリケート終了時に通常の運用状態に復旧します。
    3ノードのうち2ノードが同時に停止した場合にはサービスが継続不可能となりますので、1ノードが停止した段階で復旧処置を行う必要があります。
    ただし、サービス継続不可能となった時点でデータの書き込みは行われないため、データの損失は発生しません。

9.2.4. まとめ

構成毎に有効な対策についてまとめます。

9.2.4.1. Cassandraを単一ノードにて運用する場合

Cassandraを単一ノードにて運用する場合には、異常停止の発生時にデータ損失を完全に防ぐ事は不可能です。
異常停止が発生場合の対策として、以下が有効だと考えられます。
  • 停止前のフラッシュ実行
  • 定期的なフラッシュ実行

コラム

参考情報

弊社の社内システムにおけるCassandraは単一ノードで運用されており、15分間隔でフラッシュを実行しています。
2年ほど運用しておりますが、過去に4回ほど直近15分(最大)の投稿データが損失する事象が発生しております。
※ 弊社システムは運用試験環境を兼ねているためリリース前(RC版)を利用しており、通常よりもエラー発生確率が高くなっております。

9.2.4.2. Cassandraをクラスタ構成にて運用する場合

クラスタ構成にて運用する場合には、それだけでデータ損失の発生率を大きく軽減する事が可能です。
また、メンテナンスなどでクラスタ全体を停止させる必要がある場合、以下の対策を行うことでデータ損失のリスクを軽減可能です。
  • 停止前のフラッシュ実行

9.3. データの復元

データの損失が発生してしまった場合に復元可能なデータは以下になります。

9.3.1. 復元可能なデータ

IM共通マスタから同期して書き込まれた「ユーザ」や「組織」の情報

コラム

専用のジョブ(ジョブネット)を実行することで復元可能です。
詳細については、「 IMBox 仕様書 」-「 ジョブスケジューラ 」を参照してください。

9.3.2. 復元不可能なデータ

IMBox上で更新された「投稿内容」や「新規に作成したグループ」などはCassandra上のみに保存されております。
そのため、データ損失が発生した場合には復元することはできません。

コラム

添付ファイルについてはファイルシステム(PublicStorage)上に保存されているため、システム管理者による復旧が可能です。
添付ファイルの保存先については、「 IMBox 仕様書 」-「 添付ファイル保存先 」を参照してください。

9.4. 時刻の調整

Cassandra に格納される全てのデータは時刻を持ちます、この時刻は主にクラスタリング環境においてデータの矛盾を解決する為に利用されます。
その為、 Cassandra を運用しているサーバ上の時計を変更する等の操作をした場合データの不整合が発生しデータが破損する可能性があります。
また、 Cassandra に格納するデータの時刻は Cassandra が実行されているサーバ上ではなく、 Cassandra へ接続するアプリケーション側にて設定する時刻が利用されます。
その為、 intra-mart Accel Platform が動作する環境、および、 Cassandra が実行するサーバ上の時計は全て時刻が合っている必要があります。
時刻の統一を行うため、ntpサーバの利用を検討してください。

9.5. タイムアウト

CassandraサーバのDisk I/Oの速度によっては、データの読み込み時、および、書き込み時にタイムアウトが発生する可能性があります。
タイムアウトの発生頻度を下げるためには、cassandra.yamlのrpc_timeout_in_msの設定値を調整してください。
デフォルトでは10000(10秒)となっています。
間隔が長いと応答速度が遅くなる可能性がございます。
お客様の環境や運用に合わせ、必要に応じて間隔を設定してください。