Odnoklassniki は、RuNet における Apache Cassandra の最大のユーザーであり、世界最大のユーザーの 2010 つです。 当社は XNUMX 年に写真の評価を保存するために Cassandra の使用を開始し、現在 Cassandra は数千のノード上のペタバイト規模のデータを管理しています。実際、独自のデータも開発しました。 .
12 月 XNUMX 日にサンクトペテルブルクのオフィスで次のイベントを開催します。 。 イベントの主な講演者は、オドノクラスニキのチーフエンジニアであるオレグ・アナスタシエフ氏です。 オレグは分散型フォールトトレラント システムの分野の専門家であり、10 年以上にわたって Cassandra と協力し、繰り返し働いています。 .
ミートアップの前夜、私たちは分散システムのフォールトトレランスについて Cassandra と話し、ミートアップで何を話すのか、そしてなぜこのイベントに参加する価値があるのかを尋ねました。
オレグがプログラミングのキャリアを始めたのは 1995 年に遡ります。 彼は銀行、通信、運輸分野のソフトウェアを開発しました。 彼は 2007 年から Odnoklassniki のプラットフォーム チームの主要な開発者として働いています。 彼の責任には、高負荷システム、大規模なデータ ウェアハウス向けのアーキテクチャとソリューションの開発、ポータルのパフォーマンスと信頼性の問題の解決が含まれます。 彼は社内で開発者のトレーニングも行っています。
- オレグ、こんにちは！ XNUMX月に開催されました 、Apache Cassandra に捧げられた、参加者によると、議論は夜遅くまで続いたそうです。最初のミートアップの感想を教えてください。
さまざまな企業のさまざまな背景を持つ開発者が、それぞれの苦しみ、問題に対する予想外の解決策、そして驚くべきストーリーを携えてやって来ました。 ミートアップの大部分はディスカッション形式で行うことができましたが、議論が多すぎて、予定されていたトピックの XNUMX 分の XNUMX しか触れることができませんでした。 実際の運用サービスの例を使用して、何をどのように監視するかに多くの注意を払いました。
興味があってとても気に入りました。
- 発表から判断すると、 フォールト トレランスに専念する予定ですが、なぜこのトピックを選択したのですか?
Cassandra は、ユーザーのリクエストに直接対応するだけでなく、ゴシップ、障害検出、スキーマ変更の伝播、クラスターの拡張/縮小、アンチエントロピー、バックアップとリカバリなどの膨大な機能を備えた典型的な多忙な分散システムです。 他の分散システムと同様に、ハードウェアの量が増えると障害が発生する可能性が高くなります。そのため、Cassandra 実稼働クラスターの運用では、障害発生時の動作やオペレーターのアクションを予測するために、その構造を深く理解する必要があります。 Cassandra を長年使用した後、 、それを共有する準備ができています。また、ショップの同僚が典型的な問題をどのように解決するかについても話し合いたいと思います。
— Cassandra に関して言えば、耐障害性とは何を意味しますか?
もちろん、まず第一に、マシン、ディスク、またはノード/データセンターとのネットワーク接続の喪失など、典型的なハードウェア障害にシステムが耐えられる能力です。 しかし、このトピック自体はさらに幅広く、特に、オペレーターのミスなど、ほとんど準備ができていない障害を含む障害からの回復が含まれます。
— 最も負荷が高く最大のデータ クラスターの例を挙げていただけますか?
私たちの最大のクラスターの 200 つはギフト クラスターです。XNUMX を超えるノードと数百 TB のデータがあります。 ただし、分散キャッシュでカバーされているため、最も負荷がかかるわけではありません。 最もビジーなクラスターは、書き込みで数万 RPS、読み取りで数千 RPS を処理します。
- おお！ どれくらいの頻度で何かが壊れますか?
！ 合計で 6 台を超えるサーバーがあり、毎週、数台のサーバーと数十台のディスクが交換されます (マシン フリートのアップグレードと拡張の並行プロセスは考慮していません)。 障害の種類ごとに、何をどの順序で実行するかについて明確な指示があり、可能な限りすべてが自動化されているため、障害は日常的に発生し、99% のケースではユーザーは気付かないうちに発生します。
――そのような拒否にはどう対処しますか？
Cassandra の運用開始当初から最初のインシデントが発生したときから、私たちはバックアップとそこからのリカバリのメカニズムに取り組み、Cassandra クラスタの状態を考慮して、たとえばノードの再起動を許可しない導入手順を構築しました。データ損失の可能性がある場合。 これらすべてについてミートアップで話す予定です。
— おっしゃるとおり、絶対に信頼できるシステムはありません。 あなたはどのような種類の失敗に備え、生き残ることができますか?
Cassandra クラスターのインストールについて話す場合、XNUMX つの DC または XNUMX つの DC 全体で複数のマシンが失われたとしても、ユーザーは何も気づきません (これは実際に起こっています)。 DC数の増加に伴い、XNUMX台のDCに障害が発生した場合の運用性の確保に着手したいと考えています。
— 耐障害性の観点から Cassandra に欠けているものは何だと思いますか?
Cassandra は、他の多くの初期の NoSQL ストアと同様に、その内部構造と発生する動的なプロセスを深く理解する必要があります。 シンプルさ、予測可能性、観察可能性に欠けていると言えます。 しかし、他の会議参加者の意見を聞くのは興味深いでしょう。
オレグさん、質問に答えるために時間を割いていただき、ありがとうございました！
12 月 XNUMX 日にサンクトペテルブルクのオフィスで開催される交流会で、Apache Cassandra の運用分野の専門家とコミュニケーションを取りたい方をお待ちしています。
さあ、面白くなりますよ！
出所： habr.com