「私の靴の中を歩く」-やめて、マークされていますか？

2019年以降、ロシアには必須の表示法があります。法律はすべての商品グループに適用されるわけではなく、商品グループの強制ラベル表示の発効条件は異なります。最初に必須のラベルに該当するのは、タバコ、履物、医薬品であり、後に香水、繊維、牛乳などの他の商品が追加されます。この立法革新により、生産の瞬間から最終消費者が購入するまでの製品のライフチェーン全体を追跡することを可能にする新しいITソリューションの開発が促進されました。



X5では、ラベル付けされた商品を追跡し、政府やサプライヤーとデータを交換するシステムは「Markus」と呼ばれています。どのようにして誰が開発したのか、どのような技術スタックがあるのか​​、そしてなぜ私たちが誇りに思うものがあるのか​​を順番に説明しましょう。

実HighLoad

「Markus」は多くの問題を解決します。その主なものは、情報システムX5とラベル付き製品の状態情報システム（GIS MP）間の統合相互作用であり、ラベル付き製品の動きを追跡します。また、プラットフォームは、私たちが受け取ったすべてのマーキングコードと、オブジェクト間でのこれらのコードの移動の全履歴を保存するので、マークされた製品の再分類を排除できます。ラベル付き商品の最初のグループに含まれていたたばこ製品の例では、たばこの1つのトラックのみに約60万パックが含まれており、それぞれに独自のコードがあります。そして、私たちのシステムのタスクは、倉庫と店舗の間のそのような各パックの動きの合法性を追跡およびチェックし、最終的にエンドユーザーへの実装の許容性をチェックすることです。そして、1時間あたり約125,000の現金取引を記録します。また、そのような各パックがどのように店に入ったかを記録することも必要です。したがって、オブジェクト間のすべての動きを考慮すると、年間数百億のレコードが予想されます。

チームM

「Markus」はX5内のプロジェクトと見なされていますが、製品のアプローチに従って実装されています。チームはスクラムに取り組んでいます。プロジェクトの開始は昨年の夏でしたが、最初の結果は10月になって初めて得られました。彼らのチームは完全に組み立てられ、システムアーキテクチャが開発され、機器が購入されました。現在、チームには16人がおり、そのうち6人はバックエンドとフロントエンドの開発に従事しており、3人はシステム分析に従事しています。さらに6人が、手動、ロード、自動テストおよび製品サポートに関与しています。さらに、SREスペシャリストがいます。



私たちのチームのコードは開発者だけでなく、ほとんどすべての人が自動テスト、ロードスクリプト、自動化スクリプトのプログラミングと記述の方法を知っています。製品サポートでさえも高度な自動化が必要なため、私たちはこれに特別な注意を払います。私たちは常に、以前にプログラムしたことがない同僚にアドバイスを提供し、小さなタスクを機能させるように努めています。



コロナウイルスのパンデミックに関連して、私たちはチーム全体をリモート作業に転送し、すべての開発管理ツールの可用性、JiraとGitLabで構築されたワークフローにより、この段階を簡単に通過できました。離れた場所で過ごした数か月は、チームの生産性がこれに影響されないことを示しました。多くの仕事の快適さが増したため、唯一のことは十分なライブコミュニケーションがないことです。

遠く離れたチームミーティング

リモート会議

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

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



「Markus」によるビジネスプロセスの実行を成功させるには、それぞれ順番にいくつかの技術的な問題を解決する必要がありました。



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



この問題を解決するために、アーキテクチャへのマイクロサービスアプローチを選択しました。同時に、サービスの責任範囲を理解することは非常に重要でした。プロセスの詳細を考慮して、それらをビジネスオペレーションに分割しようとしました。たとえば、倉庫での受け入れはそれほど頻繁ではありませんが、非常に膨大な作業です。その間、受け取った商品の単位に関する情報を可能な限り迅速に州の規制当局から入手する必要があります。倉庫自動化システムに必要な情報。しかし、倉庫からの発送ははるかに集中的に行われますが、同時に少量のデータで処理されます。



私たちはすべてのサービスをステートレスの原則に基づいて実装し、Kafkaセルフトピックと呼ばれるものを使用して、内部操作をステップに分割することも試みます。これは、マイクロサービスがそれ自体にメッセージを送信するときです。これにより、リソースを集中的に使用する操作の負荷を分散し、製品のメンテナンスを簡略化できますが、後でさらに詳しく説明します。



外部システムとの対話用のモジュールを個別のサービスに分離することにしました。これにより、頻繁に変更される外部システムのAPIの問題を解決でき、ビジネス機能を備えたサービスに実質的に影響を与えません。







すべてのマイクロサービスはOpenShiftクラスターにデプロイされ、各マイクロサービスのスケーリングの問題を解決し、サードパーティのサービス検出ツールを使用しないようにします。



タスク2.プラットフォームサービス間で高負荷と非常に集中的なデータ交換を維持する必要性：プロジェクトの起動フェーズでのみ、毎秒約600の操作が実行されます。トレーディングオブジェクトがプラットフォームに接続すると、この値は最大5000 op / secになると予想されます。



このタスクは、Kafkaクラスターをデプロイし、プラットフォームマイクロサービス間の同期通信をほぼ完全に破棄することで解決しました。すべての操作が非同期であるとは限らないため、システム要件の非常に注意深い分析が必要です。同時に、ブローカーを介してイベントを送信するだけでなく、必要なすべてのビジネス情報をメッセージで送信します。したがって、メッセージのサイズは最大で数百キロバイトになる可能性があります。 Kafkaでのメッセージの量の制限により、メッセージのサイズを正確に予測する必要があります。必要に応じて、メッセージを分割しますが、分割は論理的であり、業務に関連しています。

たとえば、商品が車に届いたら、箱に分けます。同期操作の場合、個別のマイクロサービスが割り当てられ、厳密な負荷テストが実行されます。 Kafkaを使用すると、別の課題が発生しました。Kafka統合でサービスをテストすると、すべての単体テストが非同期になります。 Embedded Kafka Brokerを使用して独自の実用的なメソッドを作成することにより、この問題を解決しました。これにより、個々のメソッドの単体テストを作成する必要がなくなるわけではありませんが、Kafkaを使用して複雑なケースをテストすることをお勧めします。



サービスの操作中に例外が発生したり、Kafkaバッチで作業しているときにTraceIdが失われないように、ログのトレースに多くの注意を払いました。最初の質問で特別な質問がなかった場合、2番目のケースでは、バッチのすべてのTraceIdをログに記録し、トレースを続行するために1つを選択することを強制されます。その後、最初のTraceIdを検索すると、ユーザーはトレースがどのトレースで継続したかを簡単に見つけることができます。



目的3.大量のデータを保存する必要性：たばこだけで年間10億を超えるラベルがX5に送信されます。彼らは一定かつ迅速なアクセスを必要とします。合計で、システムはこれらのマークされた商品の移動の履歴に関する約100億のレコードを処理する必要があります。



3番目の問題を解決するために、MongoDB NoSQLデータベースが選択されました。 5つのノードのシャードを構築し、各ノードに3つのサーバーのレプリカセットを作成しました。これにより、システムを水平方向にスケーリングし、新しいサーバーをクラスターに追加して、フォールトトレランスを確保できます。ここで、別の問題に直面しました-水平方向にスケーラブルなマイクロサービスの使用を考慮に入れて、mongoクラスターのトランザクション性を保証します。たとえば、システムのタスクの1つは、同じマーキングコードで商品を転売する試みを検出することです。ここで、オーバーレイは誤ったスキャンまたは誤ったレジ操作で表示されます。そのような重複は、Kafkaで処理される1つのバッチ内と、並行して処理される2つのバッチ内の両方で発生する可能性があることがわかりました。したがって、データベースを照会して重複をチェックしても何も起こりませんでした。各マイクロサービスについて、このサービスのビジネスロジックに基づいて個別に問題を解決しました。たとえば、領収書については、バッチ内にチェックを追加し、挿入時に重複を表示するための個別の処理を追加しました。



操作の履歴を持つユーザーの作業が最も重要なことに影響を与えないように-私たちのビジネスプロセスの機能-すべての履歴データを、Kafkaを通じて情報を受信する別のデータベースを持つ別のサービスに分離しました。したがって、ユーザーは、現在の操作に関するデータを処理するサービスに影響を与えることなく、分離されたサービスで作業します。



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



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







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



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







最近では、原因を取り除いた後（たとえば、外部システムの操作性を復元した後）、対応する欠陥を分析用に確立した後、サポートによってメッセージを再送信できるインターフェースを実装しました。これは、自己トピックが役立つ場所です。長い処理チェーンを再開しないように、希望のステップから再開できます。

プラットフォーム操作

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



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



私たちの過ちを繰り返さないために、パイロット中に発見されたすべてのケースは自動テストに反映されます。多数の自動テストと単体テストが存在するため、回帰テストを実行し、修正プログラムを数時間で投入できます。



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