Cassandra の運用¶
ここでは Cassandra の運用方法を説明します。
項目
状態変化のタイミングとリスク¶
Cassandraの運用状態が変化するタイミングと、その時のリスクについて考察します。
計画停止¶
手動やサービスによって、意図したタイミングで停止した場合を想定します。また前提として、Cassandraを停止するタイミングではApplicationServerからの更新要求がないものとします。対応例
フラッシュに成功した場合¶
通常期待される状態です。フラッシュが実行されているためデータ損失はなく、当然ながら対策を検討する必要はありません。
フラッシュに失敗した場合¶
通常は計画停止した場合はフラッシュが実行され停止時のデータが担保されますが、停止時にフラッシュが失敗する場合があります。フラッシュが正常に実行されていないため、メモリ上に存在していたデータが失われます。
異常停止¶
Cassandraが何らかの原因により、意図せず停止した場合を想定します。以下のような状況が想定されます。
- Cassandra内でサービスの継続が不可能な例外（OutOfMemoryError）が発生した場合
- Cassandraのプロセスが強制停止された場合
- Cassandra起動中にOSが停止した場合
フラッシュが実行されていた場合¶
異常停止前にフラッシュが実行される場合があります。フラッシュが実行されているためデータ損失はなく、当然ながら対策を検討する必要はありません。
フラッシュが実行されない、または失敗した場合¶
異常停止前には通常フラッシュが実行されません。もしくは、実行されても失敗する可能性があります。フラッシュが正常に実行されていないため、メモリ上に存在していたデータが失われます。コラム
計画停止、異常停止に関わらず、フラッシュ失敗によるデータ損失のリスクが存在します。
ネットワークの分断¶
Cassandraのノードがネットワークから分断された場合は、データの損失が発生する事はありません。ただし、構成の状態によってはサービスが利用できなくなります。
単一ノードにて構築されている場合¶
Cassandraが復旧するまでIMBoxは利用できなくなります。コラム
単一ノードにて運用する場合は、ネットワークが分断した時点で読み込み/書き込みが行えなくなるため、データ損失は発生しません。
クラスタ構成で構築されている場合¶
ネットワークから分断されたノード数により状況が変化します。サービス継続が可能な台数の場合例えば「ノード数が３台（レプリケーションファクタが３）」の場合に１台が分断された場合、サービスは他の２台のノードで正常に行われます。分断されたノードが再度ネットワークに接続されたタイミングで不足分のデータがレプリケート（コピー）され、通常の運用状態に復旧します。サービス継続が不可能な台数の場合Cassandraが復旧するまでIMBoxは利用できなくなります。例えば「ノード数が３台、レプリケーションファクタが３」の場合に２台が分断された場合、サービスが利用不可となります。サービスが利用不可になり読み込み/書き込みが行えなくなるため、データ損失は発生しません。
リスク対策¶
前項より、基本的にフラッシュの失敗または未実施の場合について対策を取る必要があります。対応策について以下にて幾つかの案を考察します。
計画停止前のフラッシュ実行¶
計画停止前に１度フラッシュ処理を実施します。これにより、計画停止時に実行されるフラッシュの失敗に対するリスクを回避可能です。
定期的なフラッシュ実行¶
Cassandra起動時にcronなどで定期的なフラッシュを実行し、異常停止などによってデータが損失した場合でも、最後にフラッシュを実行した時点までの内容を担保します。コラム
この対策はあくまでもデータ損失の確率や損失量を軽減する対策になります。フラッシュ に関してはこちらを参照してください。コラム
フラッシュ実行の頻度については、運用設計にて要求される条件との調整が必要です。検討が必要な項目として、以下が考えられます。
- データ損失の可能性が許容される最大の時間
- フラッシュの定期実行によるI/O負荷増加によるサービスのレスポンスやサーバ負荷への影響
クラスタ構成の構築¶
Cassandraのクラスタを構築して運用することで、データ損失およびサービス停止の可能性を大きく軽減する事が可能です。このとき、クラスタを構成するノード数は３ノード以上を強く推奨します。
ノード数が２台の場合¶
クラスタを構成するノードが２ノードであった場合には、いずれか１ノードが停止した時点でサービスが継続（データの読み込みおよび書き込みが）不能となります。ただし、サービス継続不可能となった時点でデータの書き込みは行われないため、データの損失は発生しません。
ノード数が３台（もしくはそれ以上）の場合¶
クラスタを構成するノードが３ノード（およびレプリケーションファクタが３）であった場合、いずれか１ノードが停止してもサービスは継続可能です。停止したノードが復旧したタイミングで、停止していたノードに対して不足しているデータがレプリケート（コピー）され、レプリケート終了時に通常の運用状態に復旧します。３ノードのうち２ノードが同時に停止した場合にはサービスが継続不能となりますので、１ノードが停止した段階で復旧処置を行う必要があります。ただし、サービス継続不可能となった時点でデータの書き込みは行われないため、データの損失は発生しません。
まとめ¶
構成毎に有効な対策についてまとめます。
Cassandraを単一ノードにて運用する場合¶
Cassandraを単一ノードにて運用する場合には、異常停止の発生時にデータ損失を完全に防ぐ事は不可能です。異常停止が発生場合の対策として、以下が有効だと考えられます。
コラム
参考情報：弊社の社内システムにおけるCassandraは単一ノードで運用されており、15分間隔でフラッシュを実行しています。２年ほど運用しておりますが、過去に４回ほど直近15分（最大）の投稿データが損失する事象が発生しております。※ 弊社システムは運用試験環境を兼ねているためリリース前(RC版)を利用しており、通常よりもエラー発生確率が高くなっております。
Cassandraをクラスタ構成にて運用する場合¶
クラスタ構成にて運用する場合には、それだけでデータ損失の発生率を大きく軽減する事が可能です。また、メンテナンスなどでクラスタ全体を停止させる必要がある場合、以下の対策を行うことでデータ損失のリスクを軽減可能です。
データの復元¶
データの損失が発生してしまった場合に復元可能なデータは以下になります。
復元可能なデータ¶
IM共通マスタから同期して書き込まれた「ユーザ」や「組織」の情報コラム
専用のジョブ（ジョブネット）を実行することで復元可能です。詳細については、「IMBox仕様書 - ジョブスケジューラ」 を参照してください。
復元不可能なデータ¶
IMBox上で更新された「投稿内容」や「新規に作成したグループ」などはCassandra上のみに保存されております。そのため、データ損失が発生した場合には復元することはできません。コラム
添付ファイルについてはファイルシステム（PublicStorage）上に保存されているため、システム管理者による復旧が可能です。添付ファイルの保存先については、「IMBox仕様書 - アクション -ファイル」 を参照してください。
時刻の調整¶
Cassandra に格納される全てのデータは時刻を持ちます、この時刻は主にクラスタリング環境においてデータの矛盾を解決する為に利用されます。その為、 Cassandra を運用しているサーバ上の時計を変更する等の操作をした場合データの不整合が発生しデータが破損する可能性があります。また、 Cassandra に格納するデータの時刻は Cassandra が実行されているサーバ上ではなく、 Cassandra へ接続するアプリケーション側にて設定する時刻が利用されます。その為、 intra-mart Accel Platform が動作する環境及び Cassandra が実行するサーバ上の時計は全て時刻が合っている必要があります。時刻の統一を行うため、ntpサーバの利用を検討下さい。