ユーザーアクションサービス:モノリスからクラウドへ

Souhaib Guitouni)(2020年6月23日)

はじめに

歴史的に、BlaBlaCarのバックエンドは大きなPHPモノリスでした。これにより、機能をすばやく反復して構築することができましたが、長期的には、把握、維持、および進化することは容易ではありませんでした。ここ数年、私たちはこの古いモノリスを分解し、サービス指向アーキテクチャに移行してきました。

この記事は、この移行をどのように管理しているかについてのストーリーの1つであり、途中で私たちを助けたツール。テクニカルスタックの選択、一般的なアーキテクチャ、および使用したツールに関するフィードバックについて説明します。

I —理由

BlaBlaCarの活動が拡大するにつれて、モノリシックアーキテクチャを持つことがますます増えています。主な理由は次のとおりです。

  • モノリスは生きているため、結合に陥ります。
  • チームが別々のバックログで作業することは、同じコードベースで編成するのが困難です。
  • モノリスは初心者にとっては理解しにくいものです。
  • 上記のすべてにおいて、新しい機能は非常にコストがかかります。

これが、ここ数年、プラットフォームをSOAアーキテクチャに再設計している理由です。探しているもの:

  • 機能スコープのサーバー:サービスは単一の機能を管理し、その実装方法に完全に責任を負います。
  • 独立して進化できる疎結合サービス。チームは自分のペースで作業および展開できます。
  • コードの所有権が増えるため、サービスの範囲が定義され、範囲が狭くなり、チームがサービスをより簡単に維持および運用できるようになります。

II —ユーザーアクションの範囲と履歴

独立したサービスにされる最新のラインは、ユーザーアクションでした。これらは、コミュニティリレーションチームがユーザーの問題を診断して解決するのに役立ちます。たとえば、払い戻しや異常の検出、不正行為の追跡などです。

ご想像のとおり、ユーザーの操作の量は膨大です。歴史的に1つのSQLテーブルとして、コードのこの部分にはパフォーマンスの問題がありました。毎回解決策を見つけましたが、拡張に伴い、問題はますます大きくなりました。

  • 最初の解決策の1つは、クエリを高速化するためのインデックスを作成することでした。
  • もう1つは、シャーディングすることでした。データベースを複数のテーブルに分割します。

それでも、これらのソリューションは限界に達し、時間の経過とともにパフォーマンスの問題が発生し始めました。

III —データストレージ

1 —NoSQLへの道

データストアの選択は、主に技術に基づいていました要件:

  • 大量のデータがあります
  • 大量の挿入
  • 1秒あたりの読み取り数が多く、新しいデータとパフォーマンスが必要です
  • 妥当な時間でフィルタリングできる可能性

分散により大量のデータを保存および操作し、次の場合にスケーリングできるため、明らかにNoSQLデータベースを探していました。必要です。

2 —マネージドサービス

また行きたかったメンテナンスのコストを削減するためのマネージドサービスを備えています。 HbaseやCassandraのような分散データベースは、データベース管理チームに調達する困難さで有名です。さらに重要なことに、アプリケーション開発チームにとって、データベースインフラストラクチャの問題の修正に時間を費やすのではなく、ユーザーアクションを処理するロジックの作成に集中したかったのです。また、アプリケーションの範囲が広すぎないため、新製品をテストする機会でもありました。何か新しいものを試してみたかったのです!

3 —最終的な選択

次の理由でBigtableに選ばれました。

  • ボリューム:ほとんどのSQLデータベースとは異なり、インスタンスは1秒あたり10.000の挿入を処理できるため、大量のデータを処理するように設計されているため、 3つのノードのみの最小限の構成。
  • スケーラビリティ:スケーラブルで複製が簡単で、データバージョンを管理することもできます。
  • 管理コスト:マネージドサービスです。
  • パフォーマンス:これはGCPサービスであり、GKEにデプロイされたサービスと同じインフラストラクチャ内にあるため、優れたパフォーマンスを実現できます。

III —移動中の列車から別の列車へのジャンプ

難しいことモノリスからサービスへの移行は、外部の観点からサービスの継続性を提供し、データの損失をなくすことです。

これを提供するために、新しいサービスを実行し、古いシステムを機能させ続け、両方にRESTを介して新しいアクションを書き込むことにしました。次のステップは、履歴データをモノリスから新しいサービスに移動することです。この操作によりdoubleが作成される可能性があるため、最初のデータロードで重複排除を処理する必要があります。 3番目のステップは、古いシステムではなく、新しいサービスから読み取ることです。最後のステップは、サービスですべてが機能したら、モノリス部分とレガシーSQLデータベースをシャットダウンすることです。

IV—データの移動

1 —MySQLからBigtableへ

ターゲットデータストアとは何か、どのようにデプロイするかを決定したので、次のことを考え始めました。モノリスから新しいデータベースにデータを移動する方法。このような操作は重要であり、移行ジョブは次のようにする必要があります。

  • シンプルで開発が容易:データベースコネクタの複雑さ
  • 高性能:膨大な量を読み取るためデータ量が多い場合は、できるだけ早く結果を出したい
  • 信頼性:データの損失を避けたい
  • 再起動が簡単:問題が発生した場合に備えて、できることを求めていました多くの手動操作を行わずに再起動するだけで、どこにでもシェルスクリプトがあり、複雑な手順が必要です
  • 変換を許可する:最終的なBigtableを取得するには、複数のMySQLデータベースとテーブルのデータを結合する必要がありました。手動でスクリプト化。

2 — ApacheBeamとDataflow

Google Cloudが提供する分散管理サービスであるDataflowを使用することを選択しました。これにより、ユーザーはバッチモードとストリーミングモードでデータを移動できます。

一方、Apache Beamは、分散スクリプトのコーディングに使用されるフレームワークです。 。その後、Dataflow、Spark、Flinkなどの多くの分散エンジンで実行できます。言い換えると、複数のエンジンで理解できる変換を定義するための抽象化レイヤーです。

Apache Beamのもう1つの優れた点は、 MySQLとBigtableの両方を含む複数のデータソースへのすぐに使えるコネクタがあること。そこで、データ変換を作成し、Mysqlレガシーテーブルから読み取り、それらを結合して、結果をBigtableに配置しました。

2 —どのように進みましたか?

移行の実行中にいくつかの観察を行いました:

  • MySQLにとっては大変な作業でした:パフォーマンスの問題を回避するために、重要なデータベースで実行することは絶対に避けなければなりません。この問題を回避するために、このようなタスク用に作成されたレプリカデータベースで実行しました。 Dataflow並列マシンがMySQLを使い果たすことを示した監視サービス(Prometheus / Grafana)の実行を追跡しました。
  • Bigtableにとっても簡単ではありませんでした。3台のマシンの小さなインスタンスがあり、30.000の挿入を行うことができました。毎秒。複数のDataflowジョブを実行する場合は、それをはるかに超えます。したがって、並列に配置するマシンの数を慎重に検討してください。最大数にするとお金が失われるためです。
  • MySQL Beamコネクタはデータをストリーミングしません。MySQLコネクタはSQLステートメントを実行し、待機します。応答全体をロードして続行します。これにより、大量のデータをロードする場合にRAMに問題が発生します。したがって、メモリ例外が発生しないように、ユーザーの範囲をテストして定義する必要があります。

V —バックエンドサービス

複数のアーキテクチャパターンが可能でした。将来進化する可能性があり、最初のステップからのライブトラフィックを使用して段階的に構築できるアーキテクチャを採用したいと考えていました。

リアクティブフレームワークであるSpringWebFluxを使用してサービスを作成することにしました。 、非ブロッキングリクエストがあり、機能エンドポイントでのパフォーマンスが向上します。 Springとの最適な統合のためにReactorを使用しました。

1 — Bigtable

統合テストは、複数のペイロード/ヘッダーを使用してAPIを呼び出し、応答が期待どおりかどうかを確認します。そのためには、実際のテストが必要だったため、サービスの背後にBigtableインスタンスが必要でした。

このインスタンスは、毎回同じ状態から開始するために、実行ごとにクリーンアップする必要があります。

解決策は、BigtableクライアントSDKにあるBigtableエミュレーターを使用することでした。 SDKは非常に豊富で、管理者の管理や監視などの機能が豊富です。

2 —導入とインフラストラクチャ

当社のGCPインフラストラクチャは、GoogleKubernetesとIstioの上にあります。私たちはHelmとFluxですべてを管理します。インフラストラクチャの詳細については、ブログに他の記事が掲載されています。

もちろん、サービスには従来の監視、ログ記録、アラートの終了があり、それらがないと、ライブで実行することはできません。 、Prometheus / GrafanaとELKに基づいています。

最終的な考え

大量のデータを管理するために、スケーリング機能のおかげでBigtableに行きました。Bigtableキーイングパターンを使用したデータスキーマの定義、オンプレミスデータベースからマネージドNoSQLへの大量のデータの移動、全体のテストと監視など、複数の課題がありました。

最初に、サービスを導入しました オンプレミスのデータセンターで、GCPに移行することで、レイテンシを3で割った。 コミュニティリレーションズチームの応答時間が短縮され、ワクワクしています。