Cassandra Eyed Operations

私が勤務する会社の主なプロジェクトは、Facebookおよびモバイルアプリケーションでの広告インプレッションの最適化に専念しています。 現在までに、このプロジェクトは1か月あたり最大4億人のユニークビジターにサービスを提供し、1,000を超える仮想サーバーで実行されています。 1日24時間処理する必要のあるサーバーの数とデータの量は、システムのスケーラビリティと安定性に関連する多くの興味深い問題を開発者にもたらします。



インプレッションの最適化は大きなプロセスであり、その一部の1つは、バナーのライフサイクルに関連する一連のイベント（保存、表示、クリック、コンバージョンなど）の保存と分析です。すべてはイベントレコードの保存から始まります。 各イベントは多数のサーバーのいずれかで発生し、明らかな理由により、チェーン全体を1か所でサービスしようとします。この場合、散在する部分を全体として組み立てる方法を心配する必要はありません。 しかし、実際には、サーバーがクラッシュしたり、ネットワークが機能しなかったり、ソフトウェアがアップグレードされたり、過負荷になったりすると、何も起こりません。一般に、さまざまな理由で、連続したイベントが異なるサーバーや異なるデータセンターで処理される場合があり、そのための準備が必要です。



解決する必要があるタスクは、次の条件下でイベントのシーケンスに関する情報を保存、検索、変更する方法でした。

• イベントは異なるサーバーおよび異なるデータセンターで発生する可能性があります（米国の東海岸と西海岸、ヨーロッパ）
• イベントの間隔-1秒未満から数日
• 最終イベントが受信されるまでに（変換など）、チェーン全体に関する情報が手元にあるはずです
• 情報の寿命は約10日間です。その後、TTLを介して、できれば自動的に削除する必要があります
• 読み取り/書き込みイベントの速度-毎秒数百または数千
• 応答時間：望ましい-最大10ms、許容-50ms以内、最大-最大100ms
• ハードウェア障害、ネットワーク、アップグレードに関係なく、情報は「常に」利用可能でなければなりません
• システムは容易に拡張可能である必要があります。新しいサーバーの追加、データセンターは他のサービスに対して透過的に発生する必要があります（指定された制限内の応答時間の低下は許容されます）。

最後の2つのポイントはビジネスにとって非常に重要であり、日中は冷静に業務を遂行し、夜間はぐっすり眠りたい場合、運用エンジニアにとっては不可欠です。





タスクにある程度の確信が得られるまでには、cassandraの純粋に探索的な利用に関する個人的な経験はほとんどありませんでした。 経験は非常に前向きで、さらに、適切に設計されており、活発なコミュニティ、真剣な企業、開発者がいることは明らかでした。 これらすべてを合わせて、それがタスクに理想的に適合するという事実に加えて、実際の戦いでそれを試すという決定を決定しました。

鉄の選択

最大の懸念は、応答時間フレームの要件でした-10ms。 監視する必要がある2番目のパラメーターは、あらゆる種類のcassandraの内部タスク（圧縮、修復など）の空きディスク領域の可用性です。 第三に、鉄は事故の場合に簡単に交換でき、拡張中に追加できるように「シンプル」でなければなりません。

応答時間

Cassandraは非常に高速に記録できます。 これは、データがメモリ内のテーブルとコミットログに分類されるという事実によって保証されます。つまり、ディスクへの書き込みは常に連続して行われ、ディスク上で大きな動きはありません（したがって、コミットログとランダムアクセスが発生するテーブルを保持することをお勧めします異なるドライブ）。



読み取り速度は多くのパラメーターに依存し、最終的には、データがメモリに完全に収まらない場合はディスクへのランダムアクセスの速度に依存し、リクエストに応答するために必要なデータが異なるサーバーにある場合はネットワーク速度に依存します。 読み取り応答の遅延に対処する方法には、RAMの増加、圧縮テーブル（cassandra 1.0.xのバージョンに含まれる）の使用、データの場所とレイアウトの慎重な計画、およびデータベースクエリがあります。 ご覧のとおり、すべてが運用の手中にあるわけではないため、ある程度の余裕を持って計画する必要があります。



見積もりとテストの結果、8ギガバイトのRAM、テーブルを保存するための15000rpm SASディスク、およびコミットログ用の通常の7200rpm SATAのオプションについて検討することにしました（同じオペレーティングシステムとCassandra自体が同じディスクにインストールされました）



プロセッサモデルの選択はそれほど重要ではありません。IntelプロセッサQ9400 @ 2.66GHz、X3470 @ 2.93GHzを使用しています。



状況によってはJVMのガベージコレクションに高いコストがかかるため、8ギガバイトメモリとJVMメモリのデフォルトのcassandraパラメータの選択には、その後の調整が必要でした。



現在、cassandraの応答時間はほぼ常に5ミリ秒以内であり、圧縮中に30ミリ秒に増加し、ネットワークの問題が発生した場合は100ミリ秒のレベルに短時間で飛び出します。

空きディスク容量

テーブルの空きディスク領域の可用性は非常に重要です。 いいえ、それは単に重要です。 これを弱くフォローしている場合、1つ以上のノードが予期せず動作不能になっていることがあります。 イベントレコードのサイズに、同時に保存されるレコードの予想数と複製係数を掛け、その結果をリング内のノードの数で除算することにより、ディスク上のデータ量を計算しました。



通常の動作モード（圧縮の欠如、新しいノードの追加）のCassandraでは、ディスク領域の少なくとも50％が必要です。これは、最も近い圧縮が一時的に2倍になり、失敗した場合の修復プロセスによって消費領域が3倍になるためです。 したがって、ディスクのボリュームをトリプルマージン（300Gを取得）で取得し、Nagiosでディスク使用量のレベルを設定します：警告-30％、クリティカル-50％。 今日まで、練習は計算の正確さを確認します。通常の状況では、時々警告に飛び、決して重要ではありません。 修復中、占有スペースは50〜60％、場合によっては最大70％に上昇します。

試運転

パッケージ

運用する前に、cassandra自体とすべての必要なローカル設定、Muninプラグイン、およびNagiosチェックの両方を含むDebianパッケージを準備しました。 新しいノードを開始するときの手動作業は最小限に抑えられます。ディスクを手動でパーティション分割し、初期トークンを手動で割り当てます。



このクラスターは、アメリカ東海岸の1つのデータセンターにある2つのノードから始まり、他のデータセンターのノードのペアが徐々に1つのリングに追加されました。 地理を考慮せずにノードをリングに追加するという決定は誤りでした。ヨーロッパのデータセンターに接続する必要があるとすぐに、アメリカとヨーロッパ間の100ミリ秒のレベルでのデータセンター間の遅延が必要な応答時間に耐えられないことが明らかになったためです。 幸いなことに、Cassandraには、データセンターによるレプリカのローカライズを制御できるメカニズムがあります-NetworkTopologyStrategy。これは、負荷がかかったときに直接切り替える必要がありました。 テストリングでの実験の後、システムへの影響を最小限に抑えながら、これを簡単に行う方法が明らかになりました。 切り替え直後の数分間、データの一部は読み取りにアクセスできませんでしたが、実際には誰も気付きませんでした。

データセンター

現在、クラスタは6つのデータセンターの12のノードで構成されています。 新しいデータセンターの立ち上げには、必要な構成のサーバーの注文、ディスクのマークアップ、新しいノードに必要な初期トークンの選択、およびパッケージのインストールが含まれます。 データレプリカの初期ロード時間（最大60G）を考慮して、新しいサーバーでの起動手順全体には最大1時間かかります。

監視と文書化

cassandraの実験段階でさえ、Muninプラグインが作成され、ノードに関するすべての必要な情報（各キースペース/カラムファミリーの応答時間、読み取り、書き込み、圧縮など）が提供されました。 並んでいる、各ノードのデータ量、ディスク上のテーブルの数など など これらのスケジュールの存在は、長期的に何が起こるか、または修復、圧縮などの内部手順の間に何が起こるかを理解するために非常に重要です。



異なるパラメーター間の相関関係を明確にすることで、クラスターの寿命の困難な数分でベースの応答時間の増加を回避する方法を理解できます。



DatastaxからOpsCenterを使用しようとしました（長期的にだけでなく、リアルタイムモードで単一のセンターからノードを管理することも可能になります）が、ソフトウェア構成の特定の問題により、使用できません-現在の状態を要約する独自のモニターを作成する必要がありました1つのブラウザウィンドウで最も重要なメトリックの値。 通常の夜間モードでの2つのサーバーからの出力の例：

ノード名	lat、msを読み取る	lat、msを書き込む	読み取り、ops / s	書き込み、ops / s	ディスク、％	Java、％	データ、G	ストリーム送信G	ストリーム、送信％	ストリーム、recv G	ストリーム、recv％	コンプ、 G	コンプ、 ％
node1	0.7	0.6	66.7	10.8	15.0	60.1	39.4	0.0	0.0	0.0	0.0	0.0	0.0
node2	0.7	0.6	66.5	10.3	15.0	20.7	39.7	0.0	0.0	0.0	0.0	0.0	0.0

同じ2つのサーバーですが、2番目のサーバーは修復です。

ノード名	lat、msを読み取る	lat、msを書き込む	読み取り、ops / s	書き込み、ops / s	ディスク、％	Java、％	データ、G	ストリーム送信G	ストリーム、送信％	ストリーム、recv G	ストリーム、recv％	コンプ、 G	コンプ、 ％
node1	4.1	0.6	54.3	9.5	17.1	60.1	44.9	0.0	0.0	0.0	0.0	0.0	0.0
node2	2.6	0.5	54.5	9.5	18.5	55.2	48.9	1.9	22.3	0.0	0.0	2.5	1.2

さらに、企業のwikiで、またはcassandraに関連するすべての問題に関する詳細なコメントの形式で、主要な手順を文書化しました。

詰め込まれたコーン

NTS

最初から犯した間違いは、ネットワークトポロジ戦略ではなくシンプル戦略の使用であり、リモートデータセンターでノードが起動されるとすぐに問題が発生しました。 すぐにNTSを使用することを妨げるものはありませんでしたが、外出先でエラーを修正する必要がありました。 これで、各データセンターにデータのレプリカを1つ保持するように、レプリケーションが調整されました。 NetworkTopologyStrategyを使用すると、クラスターのトポロジを記述することができます-どのデータセンター、どのラックにこのノードまたはそのノードが配置され、その後、Cassandraがデータへのアクセスを最適化します。 レコードまたは読み取り値はローカルで処理され、このデータセンターの必要なノードが利用できない場合にのみ、クライアントは別のノードからのデータを期待します。

クライアントファイラー

アプリケーションはjavaで記述されており、Hectorライブラリを使用してデータベースを操作します。 Hectorは十分に賢く、接続用のクラスターノードを選択するためのさまざまなポリシーをクライアントに提供します。 最初に停止したオプション-各クライアントは、最速の応答を受信したノードで動作し、直感的に正しいように見えましたが、現実は残酷であることが判明しました-ノードの1つが他のノードよりも著しく速く応答すると、すべてのクライアントがそれに急いで行きました実際に彼にDDoSを与えました。 負荷の増加によりノードの応答が遅くなると、全員が急いで別のノードに移動しました。 データセンター内のノードの負荷が均等に分散されるように、クライアントはデータセンター内のすべての「生きている」ノードを円で囲みます。 ノードが100ミリ秒以内に応答しない場合、クライアントは自身のノードを「デッド」としてマークし、時々呼び出してステータスを確認します。 これで問題は完全に解決しました。

圧縮、修理

Cassandraは、キーごとにソートされたSSTableテーブルの形式でデータをディスクに保存します（各テーブルのいくつかの補助ファイルとともに）。 MemTableテーブルがメモリからディスクにフラッシュされると、各新しいSSTableが作成されます。 記録されると、SSTableは変更されません。 古いSSTableとデータを削除する唯一の方法は、圧縮手順を使用することです。この手順では、複数の（またはすべての）SSTableを1つに収集します。 このアセンブリでは、多くの重要な作業が行われます。古い廃棄（削除されたデータマーカー）は削除され、古いTTLデータは削除済みとしてマークされ、それらの廃棄は新しいSSTableに配置されます。 圧縮の種類によってはバックグラウンドで自動的に実行されるものと、手動でトリガーできるものがあります。 この圧縮の結果、新しいテーブルが表示され（通常は、より少ない数とボリュームで）、まだ古くなっていないトゥームストーンとデータの混合で構成されます。



テーブルの重い圧縮/マージ操作の影響の減少は、マージ頻度（それに対応するテーブルのサイズ）、最適な並列度（並列マージの数の減少により、操作時間は増加しますが、ディスクの負荷は減少します）および圧縮操作の許可されたディスクトラフィックにあります。



修復操作は、レプリカ間でデータと廃棄標識を同期します。 Cassandraには、レプリカの1つへの記録が初めて失敗した場合のために、外出先で同期ツールがありますが、これらのツールはすべて100％の保証を提供するものではありません。 そのため、一部のデータ処理シナリオでは、定期的に修復を実行することをお勧めしますが、一部では修復が必要です。 ノード間（およびデータセンター間）のかなり大量のデータの転送がこのプロセスに関与する可能性があるため、修復の直前にデータの不一致を最小限に抑えることが重要です。 最適な修復手順の選択とその準備にはかなり時間がかかりました。操作が難しく、あまり頻繁に実験しないためです。



その結果、次の修理スタートアップ戦略を開発しました。手順は週に1回夜間に開始されます。 以前は、小さなColumnFamilyの場合、ディスク上のテーブルの完全なマージが実行され（このプロセスはほとんどリソースを消費しません）、大きなColumnFamilyの「古い」（4日以上）テーブルの完全なマージが実行されます。 後者の操作は、一方で多くの墓石をきれいにし、他方で比較的少ないリソースを消費します。 修復が開始されるまでに、最小限のデータがディスクに保存され、ノード間の差分と同期をそれぞれ計算するプロセスには最小限の時間（約1時間）がかかります。



修復は特にネットワークの問題に悩まされます-同期中に接続が長時間（分）中断されるか、大きなパケット損失がある場合、TCP経由で発生するノード間の交換がスタックします。 cassandraの新しいバージョンでは、このようなハングのタイムアウトを指定できます。

メモリとガベージコレクション

もう1つの微妙な点は、JVMメモリの使用です。 特に、並列圧縮および修復中にヒープの負荷が増加します。 デフォルトのパラメータはあなたに適していないかもしれません、あなたは実験する必要があります。

推奨事項

• 負荷の性質と、アプリケーションに提供する必要があるパラメータをできるだけ早く決定します。 詳細については、タスクマネージャーにお問い合わせください。 分析に基づいて鉄を設計します。 開発者にデータベースストレージを慎重に設計するよう依頼してください。
• 応答時間が重要な場合は、空き容量とディスク速度とRAMを確保してください。
• ノードで同じハードウェアとソフトウェアを使用し、動物園を繁殖させないでください。
• すべてを詳細に監視します。 問題を分析するためにどのデータが必要かは事前にはわかりません。
• 新しいノードのインストールを自動化します。
• cassandraのデータのライフサイクルを詳細に理解します。データの保存場所と保存場所、読み取り方法、データベースからの離脱方法。

結論

過去1年間で、3つのクラスターを立ち上げました。そのうち2つは実動プロジェクトで、1つは開発中です。 一般に、Cassandraは、注意を払う必要がある操作の楽園であると言えます。 鉄の頻繁な障害、個々のサーバーの交換/追加、定期的なアップグレード、さまざまな設定とプロセスを備えた稼働中のノードでの継続的な実験にもかかわらず、運用の年にわたって、別のノードでのcassandraまたはクラスター全体の離脱に関する単一の問題はありませんでした。 最終的に、その安定性とスケーラビリティの両方が1つの基本原則によって保証されます。すべてのノードが同じ役割を果たし、緊密に接続されていません。