「私の靴で歩いています」 - 待ってください、靴にマークは付いていますか？

ロシアでは2019年から表示義務に関する法律が施行されている。 この法律はすべての商品グループに適用されるわけではなく、商品グループごとに表示義務の発効日も異なります。 タバコ、靴、医薬品が最初に義務表示の対象となり、香水、繊維製品、牛乳などの他の製品も後に追加される予定です。 この法的革新により、製品の生産から最終消費者による購入、そしてそのプロセスのすべての参加者（国自体と、商品を販売するすべての組織の両方）に至る製品のライフチェーン全体を追跡できる新しい IT ソリューションの開発が促されました。義務的なラベル表示。

X5 では、ラベル付き商品を追跡し、国やサプライヤーとデータを交換するシステムは「マーカス」と呼ばれます。 誰がどのように開発したのか、その技術スタックはどのようなものなのか、そしてなぜ当社が誇るべきものがあるのか​​を順番に説明しましょう。

リアルハイロード

「マーカス」は多くの問題を解決しますが、主な問題は、ラベル付き製品の移動を追跡するための、X5 情報システムとラベル付き製品の状態情報システム (GIS MP) 間の相互作用の統合です。 このプラットフォームは、当社が受け取ったすべてのラベル コードと、オブジェクト間でのこれらのコードの移動履歴全体も保存し、ラベル付き製品の再グレーディングを排除するのに役立ちます。 ラベル付き商品の最初のグループに含まれていたタバコ製品の例を使用すると、トラック 600 台分のタバコに約 000 パックが含まれており、それぞれに独自のコードが付いています。 そして、私たちのシステムの役割は、倉庫と店舗の間でのそのような各パックの移動の合法性を追跡および検証し、最終的に最終購入者への販売の許容性を検証することです。 また、125 時間あたり約 000 件の現金取引を記録しており、そのような各パックがどのようにして店内に搬入されたかも記録する必要があります。 したがって、オブジェクト間のすべての移動を考慮すると、年間数百億のレコードが発生すると予想されます。

チームM

Marcus は X5 内のプロジェクトとみなされているにもかかわらず、製品アプローチを使用して実装されています。 チームはスクラムに従って作業します。 このプロジェクトは昨年の夏に始まりましたが、最初の結果が得られたのは 16 月になってからでした。私たち自身のチームが完全に編成され、システム アーキテクチャが開発され、機器が購入されました。 現在、チームは XNUMX 名で構成されており、そのうち XNUMX 名はバックエンドとフロントエンドの開発に携わっており、そのうち XNUMX 名はシステム分析に携わっています。 さらに XNUMX 人が手動テスト、負荷テスト、自動テスト、および製品メンテナンスに携わっています。 さらに、当社には SRE スペシャリストがいます。

私たちのチームでコードを書くのは開発者だけではありません。ほぼ全員が、自動テスト、ロード スクリプト、自動化スクリプトのプログラミングと作成方法を知っています。 製品サポートでも高度な自動化が必要なため、私たちはこれに特に注意を払っています。 私たちは常に、これまでプログラミングをしたことがない同僚にアドバイスして手助けし、取り組むための小さなタスクをいくつか与えるよう努めています。

コロナウイルスのパンデミックにより、私たちはチーム全体をリモートワークに移行しましたが、開発管理用のすべてのツールが利用可能になり、Jira と GitLab で構築されたワークフローにより、この段階を簡単に通過することができました。 数か月間リモートで過ごした結果、チームの生産性が低下することはなかったことがわかりました。多くの人にとって、職場での快適さは向上しましたが、唯一欠けていたのはライブコミュニケーションでした。

リモートチームミーティング

リモートワーク中の会議

ソリューションの技術スタック

X5 の標準リポジトリおよび CI/CD ツールは GitLab です。 コードの保存、継続的なテスト、テスト サーバーと運用サーバーへの展開にこれを使用します。 また、開発者がコードに加えた変更を少なくとも 2 人の同僚が承認する必要がある場合には、コード レビューを実施します。 静的コード アナライザー SonarQube と JaCoCo は、コードをクリーンに保ち、必要なレベルの単体テスト カバレッジを確保するのに役立ちます。 コードへのすべての変更は、これらのチェックを通過する必要があります。 手動で実行されるすべてのテスト スクリプトは、その後自動化されます。

「Marcus」によるビジネス プロセスの実装を成功させるには、多くの技術的問題を順番に解決する必要がありました。

タスク 1. システムの水平方向のスケーラビリティの必要性

この問題を解決するために、私たちはアーキテクチャに対してマイクロサービス アプローチを選択しました。 同時に、サービスの責任範囲を理解することが非常に重要でした。 プロセスの内容を考慮して、業務に分割してみました。 たとえば、倉庫での受け入れはそれほど頻繁ではありませんが、非常に大規模な作業であり、その際、受け入れられる商品の単位に関する情報を州規制当局から迅速に取得する必要があり、その数は600000回の配送でXNUMX万個に達します。 、この製品を倉庫に受け入れることができるかどうかを確認し、倉庫自動化システムに必要なすべての情報を返します。 ただし、倉庫からの出荷ははるかに強度が高くなりますが、同時に少量のデータで動作します。

私たちはすべてのサービスをステートレス ベースで実装し、Kafka セルフトピックと呼ばれるものを使用して内部操作をステップに分割しようとさえしています。 これは、マイクロサービスがそれ自体にメッセージを送信するときであり、これにより、リソースを大量に消費する操作の負荷のバランスが取れ、製品のメンテナンスが簡素化されます。これについては後ほど説明します。

私たちは、外部システムと対話するためのモジュールを別のサービスに分離することにしました。 これにより、業務機能を持つサービスにほとんど影響を与えることなく、外部システムのAPIが頻繁に変更される問題を解決することができました。

すべてのマイクロサービスは OpenShift クラスターにデプロイされているため、各マイクロサービスのスケーリングの問題が解決され、サードパーティの Service Discovery ツールを使用しなくても済みます。

タスク 2. プラットフォーム サービス間で高負荷および非常に集中的なデータ交換を維持する必要性: プロジェクトの立ち上げフェーズだけでも、600 秒あたり約 5000 の操作が実行されます。 小売店が当社のプラットフォームに接続するにつれて、この値は XNUMX ops/秒まで増加すると予想されます。

この問題は、Kafka クラスターをデプロイし、プラットフォームのマイクロサービス間の同期対話をほぼ完全に放棄することで解決されました。 すべての操作を非同期にできるわけではないため、システム要件を非常に注意深く分析する必要があります。 同時に、ブローカーを通じてイベントを送信するだけでなく、必要なすべてのビジネス情報もメッセージで送信します。 したがって、メッセージのサイズは数百キロバイトに達する可能性があります。 Kafka のメッセージ サイズ制限では、メッセージ サイズを正確に予測する必要があり、必要に応じてメッセージを分割しますが、分割は論理的なものであり、ビジネス オペレーションに関連しています。
たとえば、車で到着した商品を箱に分けます。 同期操作の場合、個別のマイクロサービスが割り当てられ、徹底的な負荷テストが実行されます。 Kafka を使用すると、別の課題が発生しました。Kafka の統合によりすべての単体テストが非同期になることを考慮してサービスの動作をテストするということです。 私たちは、Embedded Kafka Broker を使用して独自のユーティリティ メソッドを作成することで、この問題を解決しました。 これにより、個々のメソッドの単体テストを作成する必要がなくなるわけではありませんが、Kafka を使用して複雑なケースをテストすることを好みます。

サービスの操作中または Kafka バッチの操作中に例外が発生したときに TraceId が失われないように、トレース ログには細心の注意が払われました。 最初のケースで特別な問題がなかった場合、XNUMX 番目のケースでは、バッチに付属するすべての TraceId をログに記録し、トレースを続行する XNUMX つを選択する必要があります。 その後、元の TraceId で検索すると、どのトレースが継続されたのかが簡単にわかります。

タスク 3. 大量のデータを保存する必要がある: タバコだけでも年間 1 億以上のラベルが X5 に集まります。 継続的かつ迅速なアクセスが必要です。 合計すると、システムはこれらのラベル付き商品の移動履歴の約 10 億件の記録を処理する必要があります。

5 番目の問題を解決するために、NoSQL データベース MongoDB が選択されました。 3 つのノードのシャードを構築し、各ノードには XNUMX 台のサーバーのレプリカ セットがあります。 これにより、システムを水平方向に拡張してクラスターに新しいサーバーを追加し、フォールト トレランスを確保できます。 ここで、水平方向にスケーラブルなマイクロサービスの使用を考慮して、mongo クラスターでのトランザクション性を確保するという別の問題が発生しました。 たとえば、私たちのシステムのタスクの XNUMX つは、同じラベル コードを使用して製品を再販売しようとする試みを識別することです。 ここでは、レジ係による誤ったスキャンまたは誤った操作によってオーバーレイが表示されます。 このような重複は、処理されている XNUMX つの Kafka バッチ内と、並行して処理されている XNUMX つのバッチ内で発生する可能性があることがわかりました。 したがって、データベースにクエリを実行して重複をチェックしても何も得られませんでした。 マイクロサービスごとに、このサービスのビジネス ロジックに基づいて問題を個別に解決しました。 たとえば、チェックについては、バッチ内にチェックを追加し、挿入時の重複の出現について別の処理を追加しました。

ユーザーによる操作履歴の操作が最も重要なこと、つまりビジネス プロセスの機能にいかなる影響も及ぼさないようにするため、すべての履歴データを別個のデータベースを備えた別個のサービスに分離し、Kafka を通じて情報も受け取ります。 。 このようにして、ユーザーは、進行中の操作でデータを処理するサービスに影響を与えることなく、分離されたサービスを操作できます。

タスク 4: キューの再処理と監視:

分散システムでは、データベース、キュー、外部データ ソースの可用性に関して問題やエラーが必然的に発生します。 Marcus の場合、そのようなエラーの原因は外部システムとの統合です。 タイムアウトを指定して誤った応答に対するリクエストを繰り返し実行できるようにしながら、同時にメイン キュー内の成功したリクエストの処理を停止しないソリューションを見つける必要がありました。 この目的のために、いわゆる「トピックベースの再試行」コンセプトが選択されました。 メイン トピックごとに、誤ったメッセージが送信される XNUMX つ以上のリトライ トピックが作成され、同時にメイン トピックからのメッセージ処理の遅延が解消されます。 インタラクションスキーム -

このようなスキームを実装するには、このソリューションを Spring と統合し、コードの重複を避ける必要がありました。 Web サーフィン中に、Spring BeanPostProccessor に基づく同様のソリューションを見つけましたが、それは私たちにとって不必要に面倒に思えました。 私たちのチームは、コンシューマを作成するための Spring サイクルに統合し、さらに Retry Consumer を追加できる、よりシンプルなソリューションを作成しました。 私たちは Spring チームにソリューションのプロトタイプを提供しました。ご覧のとおりです。 ここで。 再試行コンシューマの数と各コンシューマの試行回数は、ビジネス プロセスのニーズに応じてパラメータを通じて設定されます。すべてが機能するには、あとはアノテーション org.springframework.kafka.annotation.KafkaListener を追加するだけです。これは、すべての Spring 開発者にとって馴染みのあるものです。

すべての再試行後にメッセージを処理できなかった場合、メッセージは Spring DeadLetterPublishingRecoverer を使用して DLT (デッド レター トピック) に送られます。 サポートの要請に応じて、この機能を拡張し、DLT、stackTrace、traceId に含まれるメッセージ、およびそれらに関するその他の有用な情報を表示できる別のサービスを作成しました。 さらに、すべての DLT トピックに監視とアラートが追加され、実際に、DLT トピックにメッセージが表示されると、欠陥を分析して修正する必要があります。 これは非常に便利です。トピックの名前によって、問題がプロセスのどの段階で発生したかがすぐにわかり、根本原因の検索が大幅にスピードアップされます。

最近では、原因を排除し (外部システムの機能を復元するなど)、もちろん分析のために対応する欠陥を確立した後、サポートを利用してメッセージを再送信できるインターフェイスを実装しました。 ここでセルフトピックが役に立ちます。長い処理チェーンを再起動しないように、目的のステップから再起動できます。

プラットフォームの運用

このプラットフォームはすでに生産的に稼働しており、毎日配送と出荷を実行し、新しい配送センターと店舗を接続しています。 パイロットの一環として、このシステムは「タバコ」と「靴」の製品グループで動作します。

当社のチーム全体がパイロットの実施に参加し、新たな問題を分析し、ログの改善からプロセスの変更に至るまで、製品を改善するための提案を行っています。

私たちの間違いを繰り返さないために、パイロット中に見つかったすべてのケースが自動テストに反映されます。 多数の自動テストと単体テストが存在するため、文字通り数時間以内に回帰テストを実施し、ホットフィックスをインストールできます。

現在、私たちはプラットフォームの開発と改善を続けており、常に新しい課題に直面しています。 ご興味がございましたら、次の記事でソリューションについて説明します。

出所： habr.com