User Action Service : Monolith에서 클라우드로

(Souhaib Guitouni) (2020 년 6 월 23 일)

소개

역사적으로 BlaBlaCar의 백엔드는 거대한 PHP 모놀리스였습니다. 기능을 빠르게 반복하고 구축 할 수 있었지만 장기적으로는 파악, 유지 및 발전하기가 쉽지 않았습니다. 지난 몇 년 동안 우리는이 오래된 모놀리스를 해체하고 서비스 지향 아키텍처로 이동했습니다.

이 기사는이 전환을 관리하는 방법에 대한 이야기 ​​중 하나이며, 우리를 도와 준 도구입니다. 기술 스택 선택, 일반 아키텍처 및 우리가 사용한 도구에 대한 피드백을 다룰 것입니다.

I — 이유

BlaBlaCar의 활동이 확장됨에 따라 모 놀리 식 아키텍처를 갖는 것이 점점 더 많아집니다. 제한은 주로 다음과 같은 이유 때문입니다.

  • 모놀리스가 작동하면 결합 상태가됩니다.
  • 팀이 별도의 백 로그에서 작업하도록하는 것은 동일한 코드 기반에서 구성하기 어렵습니다.
  • 모놀리스는 신규 이민자에게 이해하기 어렵습니다.
  • 위의 모든 사항에 대해 새로운 기능은 매우 비용이 많이 듭니다.

이것이 지난 몇 년 동안 플랫폼을 SOA 아키텍처로 재 설계 한 이유입니다. 검색 :

  • 기능적으로 범위가 지정된 서버 : 서비스는 단일 기능을 관리하고이를 구현하는 방법을 전적으로 책임집니다.
  • 독립적으로 발전 할 수있는 느슨하게 결합 된 서비스. 팀은 자신의 속도로 작업하고 배포 할 수 있습니다.
  • 더 많은 코드 소유권을 통해 서비스가 정의되고 범위가 더 축소되어 팀이 더 쉽게 유지하고 운영 할 수 있습니다.

II — 사용자 작업의 범위 및 기록

최신 독립 서비스로 만들어 질 것은 사용자의 행동이었습니다. 커뮤니티 관계 팀이 환불, 이상 징후 감지 또는 사기 행위 추적과 같은 사용자 문제를 진단하고 해결하는 데 도움이됩니다.

예상 할 수있는 사용자 행동의 양은 엄청납니다. 역사적으로 하나의 SQL 테이블로서이 코드 부분에는 성능 문제가있었습니다. 우리는 매번 해결책을 찾았지만 확장으로 문제가 점점 더 커졌습니다.

  • 첫 번째 해결책은 쿼리를 더 빠르게 만들기 위해 색인을 만드는 것이 었습니다.
  • 다른 하나는 샤딩하는 것이 었습니다. 데이터베이스를 여러 테이블로 만들었습니다.

그래도 이러한 솔루션은 한계에 도달했으며 시간이 지남에 따라 성능 문제가 발생하기 시작했습니다.

III — 데이터 저장소

1 — NoSQL로가는 길

데이터 저장소의 선택은 주로 기술 요구 사항 :

  • 대량의 데이터가 있습니다.
  • 대용량의 삽입
  • 초당 여러 번 읽기, 새로운 데이터 및 성능이 필요함
  • 적당한 시간 내에 필터링 할 수있는 가능성

분명히 NoSQL 데이터베이스를 찾고있었습니다. 배포를 통해 많은 양의 데이터를 저장하고 조작하고 필요합니다.

2 — 관리 형 서비스

또한 관리 서비스를 통해 유지 관리 비용을 절감합니다. Hbase 및 Cassandra와 같은 분산 데이터베이스는 데이터베이스 관리 팀에 제공하는 어려움으로 유명합니다. 더 중요한 것은 응용 프로그램 개발 팀의 경우 데이터베이스 인프라 문제를 해결하는 데 시간을 소비하는 대신 사용자 작업을 처리하는 논리를 만드는 데 집중하고 싶었습니다. 또한 적용 범위가 너무 넓지 않기 때문에 신제품을 테스트 할 수있는 기회이기도했습니다. 새로운 것을 시도해보고 싶었습니다.

3 — 최종 선택

다음과 같은 이유로 Bigtable에 선택되었습니다.

  • 볼륨 : 대부분의 SQL 데이터베이스와 달리 인스턴스는 초당 10.000 개의 삽입을 처리 할 수 ​​있으므로 대량의 데이터를 처리하도록 설계되었습니다. 노드가 3 개 뿐인 최소 구성입니다.
  • 확장 성 : 확장 가능하고 복제하기 쉬우 며 데이터 버전도 관리 할 수 ​​있습니다.
  • 관리 비용 : 관리 형 서비스입니다.
  • 성능 : GKE에 배포 된 서비스와 동일한 인프라에 있기 때문에 우수한 성능을 제공 할 수있는 GCP 서비스입니다.

III — 움직이는 기차에서 다른 기차로 점프

모놀리스에서 서비스로 이동하는 것은 외부 관점에서 서비스의 연속성을 제공하고 데이터 손실이 없도록하는 것입니다.

이를 제공하기 위해 우리는 새 서비스를 실행하고 이전 시스템을 계속 작동시키고 두 가지 모두에서 REST를 통해 새 작업을 작성하기로 결정했습니다. 다음 단계는 과거 데이터를 모놀리스에서 새 서비스로 이동하는 것입니다. 이 작업은 두 배가 될 수 있으므로 초기 데이터로드에서 중복 제거를 처리해야합니다. 세 번째 단계는 이전 시스템 대신 새 서비스에서 읽는 것입니다. 마지막 단계는 서비스에서 모든 것이 작동하면 모 놀리 식 부분과 레거시 SQL 데이터베이스를 종료하는 것입니다.

IV — 데이터 이동

1 — MySQL에서 Bigtable로

이제 대상 데이터 저장소가 무엇이고 어떻게 배포 될 것인지를 결정 했으므로 모놀리스에서 새 데이터베이스로 데이터를 이동하는 방법. 이러한 작업은 중요하며 마이그레이션 작업은 다음과 같아야합니다.

  • 간단하고 개발하기 쉬움 : 복잡성은 데이터베이스 커넥터입니다.
  • 고성능 : 읽기가 엄청납니다. 가능한 한 빨리 결과를 얻고 자합니다.
  • 신뢰성 : 데이터 손실이 없도록했습니다.
  • 재시작 용이성 : 문제가 발생할 경우를 대비하여 많은 수동 작업없이 간단히 다시 시작하기 만하면 어디서나 쉘 스크립트와 복잡한 절차를 사용할 수 있습니다.
  • 변환 허용 : 최종 Bigtable 데이터베이스를 얻기 위해 여러 MySQL 데이터베이스 및 테이블의 데이터를 결합해야했습니다. 수동으로 스크립팅됩니다.

2 — Apache Beam 및 Dataflow

Google Cloud에서 제공하는 분산 관리 형 서비스 인 Dataflow를 사용하기로 결정했습니다.이 서비스를 통해 사람들은 Batch 및 스트리밍 모드에서 데이터를 이동할 수 있습니다.

반면 Apache Beam은 분산 스크립트를 코딩하는 데 사용되는 프레임 워크입니다. . 그런 다음 Dataflow, Spark, Flink와 같은 많은 분산 엔진에서 실행할 수 있습니다. 즉, 여러 엔진에서 이해할 수있는 변환을 정의하는 추상화 계층입니다.

Apache Beam의 또 다른 멋진 점은 MySQL과 Bigtable 모두 중에서 여러 데이터 소스에 대한 기본 커넥터가 있습니다. 그래서 우리는 데이터 변환을 생성하여 Mysql 레거시 테이블에서 읽고, 결합하고 결과를 Bigtable에 넣었습니다.

2 — 어떻게 되었습니까?

마이그레이션을 실행하는 동안 몇 가지 관찰을 수행했습니다.

  • MySQL에게는 매우 힘든 작업이었습니다. 성능 문제를 방지하기 위해 어떤 방법 으로든 중요한 데이터베이스에서 실행하지 않아야합니다. 이 문제를 피하기 위해 우리는 그러한 작업을 위해 만들어진 복제 데이터베이스에서 실행했습니다. Dataflow 병렬 머신이 MySQL을 소진하는 것을 보여준 모니터링 서비스 (Prometheus / Grafana)에서 실행을 추적했습니다.
  • Bigtable도 쉽지 않았습니다. 30.000 개의 삽입을 제공 할 수있는 머신 3 개의 작은 인스턴스가있었습니다. 초당. 여러 Dataflow 작업을 실행하면 그 이상이됩니다. 따라서 최대 수를 사용하면 비용을 잃을 수 있으므로 병렬로 보유 할 머신 수를 현명하게 생각하십시오.
  • MySQL Beam 커넥터는 데이터를 스트리밍하지 않습니다. MySQL 커넥터는 SQL 문을 실행하고 대기합니다. 계속하려면 전체 응답을로드합니다. 많은 데이터를로드하면 RAM에 문제가 발생합니다. 따라서 메모리 예외로 끝나지 않도록 사용자 범위를 테스트하고 정의해야합니다.

V — 백엔드 서비스

다양한 아키텍처 패턴이 가능했습니다. 미래에 발전 할 수 있고 첫 번째 단계부터 실시간 트래픽으로 단계적으로 구축 할 수있는 아키텍처로 가고 싶었습니다.

우리는 반응 형 프레임 워크 인 Spring WebFlux를 사용하여 서비스를 만들기로 결정했습니다. , 비 차단 요청을하고 기능적 엔드 포인트에서 더 나은 성능을 제공합니다. Spring과의 최상의 통합을 위해 Reactor를 사용했습니다.

1 — Bigtable과의 통합 테스트

통합 테스트는 여러 페이로드 / 헤더를 사용하여 API를 호출하고 응답이 예상대로인지 확인합니다. 이를 위해서는 실제 테스트를 원했기 때문에 서비스 뒤에 Bigtable 인스턴스가 필요했습니다.

이 인스턴스는 매번 동일한 상태에서 시작되도록 각 실행에서 정리해야합니다.

해결 방법은 Bigtable 클라이언트 SDK에있는 Bigtable 에뮬레이터를 사용하는 것이 었습니다. SDK는 매우 풍부하며 관리자 관리 및 모니터링과 같은 더 많은 기능을 제공합니다.

2 — 배포 및 인프라

Google GCP 인프라는 Google Kubernetes 및 Istio 위에 있습니다. Helm과 Flux로 모든 것을 관리합니다. 인프라에 대한 자세한 내용을 다루기 위해 블로그에 다른 기사가 올 것입니다!

물론 서비스에는 클래식 모니터링, 로깅 및 경고 종료가 있었지만 서비스가 없으면 실시간으로 실행할 수 없습니다. , Prometheus / Grafana 및 ELK를 기반으로합니다.

최종 생각

많은 양의 데이터를 관리하기 위해 확장 기능 덕분에 Bigtable을 선택했습니다.Bigtable 키 지정 패턴을 사용하여 데이터 스키마를 정의하고, SQL 온 프레미스 데이터베이스에서 관리 형 NoSQL로 대량의 데이터를 이동하고, 전체를 테스트하고 모니터링하는 등 여러 가지 문제가있었습니다.

처음에는 서비스를 배포했습니다. 온 프레미스 데이터 센터에서 GCP로 이동하여 지연 시간을 3으로 나누었습니다. 우리의 커뮤니티 관계 팀은 이제 더 빠른 응답 시간을 가지고 있으며 매우 기쁩니다.