Oleg Anastasyev와의 미니 인터뷰: Apache Cassandra의 내결함성

Odnoklassniki는 RuNet에서 가장 큰 Apache Cassandra 사용자이자 세계 최대 사용자 중 하나입니다. 우리는 2010년에 Cassandra를 사용하여 사진 등급을 저장하기 시작했으며 이제 Cassandra는 수천 개의 노드에서 페타바이트 규모의 데이터를 관리합니다. 실제로 우리는 자체 개발도 했습니다. NewSQL 트랜잭션 데이터베이스.
12월 XNUMX일 상트페테르부르크 사무실에서 Apache Cassandra 전용 두 번째 모임. 이번 행사의 주요 연사는 Odnoklassniki Oleg Anastasyev의 수석 엔지니어가 될 것입니다. Oleg는 분산 및 내결함성 시스템 분야의 전문가로서 10년 이상 Cassandra와 반복적으로 협력해 왔습니다. 회의에서 이 제품을 사용하는 기능에 대해 이야기했습니다..

밋업 전날, 우리는 Oleg와 Cassandra와의 분산 시스템의 내결함성에 대해 이야기하고 밋업에서 무엇에 대해 이야기할 것인지, 그리고 이 이벤트에 참석할 가치가 있는 이유를 물었습니다.

Oleg는 1995년에 프로그래밍 경력을 시작했습니다. 그는 은행, 통신, 운송 분야의 소프트웨어를 개발했습니다. 그는 2007년부터 Odnoklassniki의 플랫폼 팀에서 선도적인 개발자로 일하고 있습니다. 그의 책임에는 고부하 시스템, 대규모 데이터 웨어하우스를 위한 아키텍처 및 솔루션 개발, 포털 성능 및 안정성 문제 해결이 포함됩니다. 그는 또한 회사 내에서 개발자를 교육합니다.

-올렉, 안녕하세요! XNUMX월에 일어난 일 첫 만남아파치 카산드라를 주제로 한 , 참가자들은 밤늦게까지 토론이 이어졌다고 하는데, 첫 만남의 소감은 어땠나요?

다양한 회사의 다양한 배경을 가진 개발자들이 각자의 고통, 예상치 못한 문제에 대한 해결책, 놀라운 이야기를 가지고 왔습니다. 우리는 대부분의 밋업을 토론 형식으로 진행했지만, 토론이 너무 많아서 계획된 주제의 XNUMX분의 XNUMX밖에 다루지 못했습니다. 실제 제작 서비스 사례를 통해 모니터링 방법과 대상에 대해 많은 관심을 기울였습니다.

관심이 있었고 정말 좋았어요.

- 발표 내용으로 판단하면, 두 번째 모임 내결함성에 전적으로 전념할 예정인데, 이 주제를 선택한 이유는 무엇입니까?

Cassandra는 가십, 오류 감지, 스키마 변경 전파, 클러스터 확장/축소, 엔트로피 방지, 백업 및 복구 등 사용자 요청을 직접 처리하는 것 이상의 엄청난 양의 기능을 갖춘 전형적인 바쁜 분산 시스템입니다. 모든 분산 시스템과 마찬가지로 하드웨어 양이 증가하면 오류 가능성도 높아지므로 Cassandra 프로덕션 클러스터를 운영하려면 오류 발생 시 동작과 운영자 조치를 예측하기 위해 해당 구조에 대한 깊은 이해가 필요합니다. 수년 동안 Cassandra를 사용한 후 우리는 상당한 전문지식을 축적해왔습니다, 우리는 이를 공유할 준비가 되어 있으며, 매장의 동료들이 일반적인 문제를 어떻게 해결하는지에 대해서도 논의하고 싶습니다.

— Cassandra에 있어서 내결함성이란 무엇을 의미하나요?

무엇보다도, 일반적인 하드웨어 오류(머신, 디스크 또는 노드/데이터 센터와의 네트워크 연결 손실)에서 살아남을 수 있는 시스템의 능력입니다. 그러나 주제 자체는 훨씬 더 광범위하며 특히 운영자 오류와 같이 사람들이 거의 준비하지 못한 오류를 포함하여 오류로부터의 복구를 포함합니다.

— 가장 많이 로드되고 가장 큰 데이터 클러스터의 예를 들어주실 수 있나요?

가장 큰 클러스터 중 하나는 200개 이상의 노드와 수백 TB의 데이터를 포함하는 선물 클러스터입니다. 하지만 분산 캐시로 덮여 있기 때문에 가장 많이 로드되지는 않습니다. 가장 바쁜 클러스터는 쓰기에 수만 RPS, 읽기에 수천 RPS를 처리합니다.

- 우와! 뭔가가 얼마나 자주 깨지나요?

예, 끊임없이! 전체적으로 우리는 6개 이상의 서버를 보유하고 있으며 매주 두 대의 서버와 수십 개의 디스크가 교체됩니다(업그레이드 및 시스템 확장의 병렬 프로세스를 고려하지 않음). 각 유형의 오류마다 수행할 작업과 순서에 대한 명확한 지침이 있으며 가능할 때마다 모든 것이 자동화되므로 오류는 일상적이며 99%의 경우 사용자가 알아차리지 못한 채 발생합니다.

— 그런 거절을 어떻게 처리하시나요?

Cassandra 운영 초기부터 첫 번째 사건부터 백업 및 복구 메커니즘을 개발하고 Cassandra 클러스터 상태를 고려한 배포 절차를 구축했으며, 예를 들어 노드 재시작을 허용하지 않습니다. 데이터 손실이 가능한 경우. 우리는 모임에서 이 모든 것에 대해 이야기할 계획입니다.

— 말씀하신 것처럼 절대적으로 신뢰할 수 있는 시스템은 없습니다. 어떤 유형의 실패에 대비하고 살아남을 수 있나요?

Cassandra 클러스터 설치에 대해 이야기하면 하나의 DC 또는 하나의 전체 DC에서 여러 시스템이 손실되는 경우 사용자는 아무 것도 눈치 채지 못할 것입니다(이런 일이 발생했습니다). DC 수가 증가함에 따라 DC XNUMX개에 장애가 발생하는 경우에도 작동성을 보장하기 시작하는 것을 고려하고 있습니다.

— 내결함성 측면에서 카산드라의 부족한 점은 무엇이라고 생각하시나요?

Cassandra는 다른 초기 NoSQL 저장소와 마찬가지로 내부 구조와 발생하는 동적 프로세스에 대한 깊은 이해가 필요합니다. 단순성, 예측 가능성 및 관찰 가능성이 부족하다고 말하고 싶습니다. 하지만 다른 회의 참가자들의 의견을 듣는 것은 흥미로울 것입니다!

Oleg, 시간을 내어 질문에 답변해 주셔서 정말 감사합니다!

12월 XNUMX일 상트페테르부르크 사무실에서 열리는 밋업에서 아파치 카산드라 운영 분야의 전문가들과 소통하고 싶은 분들을 기다립니다.

오세요, 재미있을 거예요!

이벤트에 등록하세요.

출처 : habr.com