セロリの50の色合い

Celeryと呼ばれるPython開発者の間で広く知られているフレームワークを飼いならす方法を知りたい場合は、ここにいます。 また、Celeryがプロジェクトで自信を持って基本的なコマンドを実行したとしても、fintechの経験が未知の側面を開く可能性があります。 フィンテックは常にビッグデータであり、それに伴いバックグラウンドタスク、バッチ処理、非同期APIなどの必要性があるためです。





モスクワPython Conf ++でのCeleryに関するOleg Churkinのストーリーの美しさは、負荷のかかったCeleryの設定方法と監視方法に関する詳細な指示に加えて、有用なアイデアを借りることができるということです。





講演者とプロジェクトについて： Oleg Churkin（ Bahusss ）は8年間さまざまな複雑さのPythonプロジェクトを開発しており、Yandex、Rambler、RBC、Kaspersky Labなどの有名企業で働いています。 現在、techlideはfintech-status StatusMoneyになっています。



プロジェクトは、アカウント、トランザクション、商人などのユーザーの大量の財務データ（1.5テラバイト）で動作します。 毎日最大100万のタスクを実行します。 たぶん、この数値は誰かにとってはそれほど大きくないように思えるかもしれませんが、適度な容量の小さなスタートアップの場合、これは大量のデータであり、開発者は安定したプロセスに向かう途中でさまざまな問題に直面しなければなりませんでした。



オレグは仕事のキーポイントについて話しました：

• フレームワークを使用して解決したいタスクは何ですか、なぜCeleryを選択したのですか。
• セロリがどのように役立ったか。
• 負荷がかかった状態でCeleryを構成する方法。
• セロリの状態を監視する方法。

そして、彼はCeleryに欠けている機能を実装するいくつかの設計ユーティリティを共有しました。 判明したように、2018年にはこれが可能になります。 以下は、一人称レポートのテキスト版です。

発行

次のタスクが必要でした：

• 個別のバックグラウンドタスクを実行します。
• タスクのバッチ処理を行います 。つまり、一度に多くのタスクを起動します。
• プロセスExtract、Transform、Loadを埋め込みます。
• 非同期APIを実装します 。 非同期フレームワークを使用して非同期APIを実装できるだけでなく、完全に同期することもできます。
• 定期的なタスクを実行します。 Cronを使用して実行できるプロジェクトもありますが、定期的なタスクなしで実行できるプロジェクトは1つではありませんが、より便利なツールがあります。
• トリガーアーキテクチャの構築：トリガーをトリガーするには、データを更新するタスクを実行します。 これは、バックグラウンドでデータを事前に計算することにより、ランタイム容量の不足を補うために行われます。

バックグラウンドタスクには、電子メール、プッシュ、デスクトップなど 、あらゆる種類の通知が含まれます。これらはすべて、トリガーによってバックグラウンドタスクで送信されます。 同様に、財務データの定期的な更新が開始されます。



バックグラウンドでは、たとえばユーザーの不正行為をチェックするなど、さまざまな特定のチェックが実行されます。 金融系の新興企業では、ユーザーが銀行口座をシステムに追加できるようにし、すべてのトランザクションを確認できるため、 データセキュリティに特に多くの労力と注意が払われています 。 詐欺師は、たとえば、盗まれたアカウントの残高をチェックするために、私たちのサービスを悪用することができます。



バックグラウンドタスクの最後のカテゴリは、 メンテナンスタスクです 。何かを微調整し、確認、修正、監視などを行います。



一括通知の場合、 バッチ処理が使用されます。 ユーザーから受け取る大量のデータは、次のような特定の方法で計算および処理する必要があります。 バッチモード。



同じ概念には、従来のExtract、Transform、Loadが含まれます。

• 外部ソースからデータを読み込む（外部API）;
• 未処理のままにしてください。
• データを読み取って処理するタスクを実行します。
• 処理されたデータを適切な場所に適切な形式で保存するため、たとえば後でUIで使用するのに便利です。

非同期APIが単純なポーリングリクエストを使用して実行できることは秘密ではありません。フロントエンドはバックエンドでプロセスを開始し、バックエンドは定期的に自身を起動するタスクを起動し、結果を「注ぎ」、データベースの状態を更新します。 フロントエンドは、ユーザーにこのインタラクティブな状態を示します-状態が変化しています。 これにより、次のことが可能になります。

• 他のタスクからポーリングタスクを実行します。
• 条件に応じて異なるタスクを実行します。

私たちのサービスでは、今のところこれで十分ですが、将来はおそらく何か他のものを書き直す必要があります。

ツール要件

これらのタスクを実装するには、ツールに次の要件がありました。

• 野心を実現するために必要な機能。
• 松葉杖のないスケーラビリティ 。
• 仕組みを理解するためにシステムを監視します。 バグレポートを使用しているため、Sentryとの統合は、Djangoとの場違いではありません。
• 多くのタスクがあるため、 パフォーマンス 。
• 成熟度、信頼性、積極的な開発は明らかです。 サポートおよび開発されるツールを探していました。
• ドキュメンテーションの妥当性- どこにもドキュメンテーションはありません 。

どのツールを選択しますか？

これらの問題を解決するための2018年の市場の選択肢は何ですか？



かつてそれほど野心的ではなかったタスクのために、私はいくつかのプロジェクトでまだ使用されている便利なライブラリを書きました。 操作は簡単で、バックグラウンドでタスクを実行します。 しかし、同時に、ブローカーは必要ありません（ Celeryも他のユーザーも）、スプーラーを備えたuwsgiアプリケーションサーバーのみが、別のワーカーとして開始されます。 これは非常に簡単なソリューションです。すべてのタスクは条件付きでファイルに保存されます。 単純なプロジェクトではこれで十分ですが、私たちのプロジェクトでは十分ではありませんでした。



どういうわけか私たちは考えました：

• セロリ（GitHubで10Kスター）;
• RQ（GitHubで5Kスター）;
• Huey（GitHubの2Kスター）;
• Dramatiq（GitHubの1Kスター）;
• Tasktiger（GitHubで0.5Kスター）;
• 気流？ ルイージ

有望な候補者2018

ここで、 Dramatiqに注目したいと思います。 これは、セロリのすべての短所を知っていて、すべてを非常に美しく書き直すことにした熟練したセロリのライブラリです。 Dramatiqの利点：

• 必要なすべての機能のセット。
• 生産性の向上。
• すぐに使えるプロメテウスの歩tryとメトリックのサポート
• 小さくて明確に記述されたコードベース、コードの自動再読み込み。

しばらく前、Dramatiqにはライセンスに関する問題がありました。最初にAGPLがあり、次にLGPLに置き換えられました。 しかし、今では試すことができます。



しかし、2016年には、セロリに加えて、特別なことは何もありませんでした。 私たちはその豊富な機能が気に入っており、それでも理想的なタスクに適していました。

• すぐに使用できる定期的なタスクがありました。
• いくつかのブローカーをサポート。
• DjangoおよびSentryと統合。

プロジェクトの特徴

さらなるストーリーがより理解しやすいように、私たちの背景についてお話します。



Redisをメッセージブローカーとして使用します 。 私は、Redisがメッセージを失い、メッセージブローカーに適応していないという多くの話と噂を聞いたことがあります。 実稼働環境では、これは確認されていませんが、結局のところ、RedisはRabbitMQよりも効率的に動作するようになりました（少なくとも、明らかに、問題はブローカーとの統合コードにあります）。 バージョン4では、Redisブローカーが修正され、再起動中にタスクが失われることがなくなり、非常に安定して動作するようになりました。 2016年、CeleryはRedisを放棄してRabbitMQとの統合に注力する予定でしたが、幸いなことに、これは実現しませんでした。



Redisで問題が発生した場合、深刻な高可用性が必要であれば、Amazonのパワーを使用するため、Amazon SQSまたはAmazon MQに切り替えます。



結果を保存するために結果バックエンドを使用しません。必要な場所に結果を保存し、希望する方法でチェックすることを好みます。 Celeryがこれを行うのは望ましくありません。



peforkプールを使用します 。つまり、 並行性を高めるためにプロセスの別個のフォークを作成するプロセスワーカーです。

作業単位

セロリを試したことはないが、やろうとしている人々を最新のものにするために、基本的な要素について議論します。 セロリの作業単位は課題です。 電子メールを送信する簡単なタスクの例を示します。



シンプルな関数とデコレーター：

@current_app.task def send_email(email: str): print(f'Sending email to email={email}')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タスクの開始は簡単です。関数を呼び出すと、タスクはランタイム（send_email（email = "python@example.com"））またはワーカーで実行されます。つまり、バックグラウンドでのタスクの効果です。

 send_email.delay(email="python@example.com") send_email.apply_async( kwargs={email: "python@example.com"} )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

高負荷のもとで2年間セロリと仕事をしてきましたが、私たちは良い形の規則を導き出しました。 たくさんの熊手がありました、それらを回避する方法を学びました、そして、私は方法を共有します。

コード設計

タスクには異なるロジックが含まれる場合があります。 一般に、Celeryは、タスクをファイルまたはパッケージタスクに保持したり、どこからでもインポートしたりするのに役立ちます。 1つのモジュールで多数のビジネスロジックを取得することもあります。 私たちの意見では、アプリケーションのモジュール性の観点からの正しいアプローチは、タスクのロジックを最小限に抑えることです。 パズルはコードの「トリガー」としてのみ使用します。 つまり、タスク自体にロジックは含まれませんが、バックグラウンドでコードの起動をトリガーします。

 @celery_app.task(queue='...') def run_regular_update(provider_account_id, *args, **kwargs): """...""" flow = flows.RegularSyncProviderAccountFlow(provider_account_id) return flow.run(*args, **kwargs)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他のクラスを使用する外部クラスにすべてのコードを配置します。 すべてのタスクは基本的に2行で構成されます。

パラメーター内の単純なオブジェクト

上記の例では、特定のIDがタスクに渡されます。 使用するすべてのタスクで、 小さなスカラーデータ id のみを転送します。 Djangoモデルをシリアル化して送信しません。 ETLでも、大きなデータBLOBが外部サービスから送られてくる場合、まずそれを保存してから、IDでこのBLOBをすべて読み取って処理するタスクを実行します。



これを行わないと、Redisで消費されたメモリの非常に大きな混合が見られました。 メッセージはより多くのメモリを占有し始め、ネットワークの負荷が高くなり、処理されるタスク（パフォーマンス）の数が低下します。 オブジェクトが完了している限り、タスクは無関係になり、オブジェクトはすでに削除されています。 データをシリアル化する必要がありました-すべてがPythonのJSONでシリアル化されているわけではありません。 タスクを再試行するときに、このデータをどう処理するかをすばやく決定し、再度取得し、それらのチェックを実行する機会が必要でした。

パラメーターでビッグデータを転送する場合は、もう一度考えてください！ 問題の情報量が少ない小さなスカラーを転送し、タスクのこの情報から必要なものすべてを取得することをお勧めします。

べき等問題

セロリ開発者自身がこのアプローチを推奨しています。 コードセクションが繰り返される場合、副作用は発生せず、結果は同じになります。 これは、特に多くのサービスとの相互作用がある場合、または2フェーズコミットがある場合、必ずしも簡単に達成できるとは限りません。



しかし、すべてをローカルで実行すると、受信データが存在し関連性があることを常に確認でき、実際に作業してトランザクションを使用できます。 1つのタスクに対してデータベースへのクエリが多数あり、実行時に問題が発生する可能性がある場合は、トランザクションを使用して不要な変更をロールバックします。

下位互換性

アプリケーションをデプロイしたときに、いくつかの興味深い副作用がありました。 使用するデプロイのタイプ（青+緑またはローリング更新）に関係なく、古いサービスコードが新しいワーカーコードのメッセージを作成する状況が常に存在し、その逆も同様です。そしてそこにトラフィックが行きました。



リリース間の後方互換性を維持する方法を学ぶまで、バグを見つけてタスクを失いました 。 下位互換性とは、このタスクにどのパラメーターが入力されても、リリース間でタスクが安全に機能することです。 したがって、すべてのタスクで「ゴム」署名（** kwargs）を作成しています。 次のリリースで新しいパラメーターを追加する必要がある場合、新しいリリースでは** kwargsから取得しますが、古いリリースでは取得しません-何も壊れません。 署名が変更され、Celeryがそのことを知らないとすぐに、クラッシュし、タスクにそのようなパラメーターがないというエラーが表示されます。



このような問題を回避するためのより厳密な方法は、リリース間でタスクキューをバージョン管理することですが、実装するのは非常に困難であり、現時点ではバックログに残しています。

タイムアウト

数が足りないか、タイムアウトが正しくないために問題が発生する場合があります。

タスクにタイムアウトを設定しないのは悪です。 これは、タスクで何が起こっているか、ビジネスロジックがどのように機能するかを理解していないことを意味します。

そのため、すべてのタスクのグローバルなものも含めて、すべてのタスクがタイムアウトでハングアップし、タイムアウトも特定のタスクごとに設定されます。



添付する必要があります ：soft_limit_timeoutおよびexpires 。



Expiresは、タスクがどれだけ並んでいることができるかです。 問題が発生した場合に、タスクがキューに蓄積されないようにする必要があります。 たとえば、ユーザーに何かを報告したいが、何かが起こり、明日だけタスクを完了することができる場合-これは意味がなく、明日はメッセージが関連しなくなります。 したがって、通知の有効期限はかなり短くなっています。



eta（countdown）+ visibility _timeoutの使用に注意してください。 FAQでは、Redisのこのような問題、つまりRedisブローカーのいわゆる可視性タイムアウトについて説明しています。 デフォルトでは、その値は1時間です。1時間後にワーカーがタスクの実行を開始していないことがわかると、ワーカーはそれをキューに再度追加します。 したがって、カウントダウンが2時間の場合、1時間後にブローカーはこのタスクがまだ完了していないことを検出し、同じタスクをもう1つ作成します。 そして2時間で、2つの同一のタスクが完了します。

予想される時間またはカウントダウンが1時間を超える場合、Redisを使用すると、当然、ブローカー接続設定でvisibility_timeout値を変更しない限り、タスクが重複します。

再試行ポリシー

繰り返し実行できるタスク、または失敗する可能性のあるタスクには、再試行ポリシーを使用します。 ただし、外部サービスを圧倒しないように慎重に使用します。 指数関数的なバックオフを指定せずにタスクをすばやく繰り返すと、外部サービス、またはおそらく内部サービスがそれに耐えられない可能性があります。



パラメータretry_backoff 、 retry_jitterおよびmax_retriesは、特にmax_retriesを明示的に指定すると便利です。 retry_jitter-少しの混乱をもたらし、タスクが同時に繰り返されないようにするパラメーター。

メモリリーク

残念ながら、メモリリークは非常に簡単であり、それらを見つけて修正することは困難です。

一般に、Pythonでメモリを操作することは非常に議論の的です。 リークが発生する理由を理解するために多くの時間と神経を費やします。そして、コードにさえ漏れていないことがわかります。 したがって、プロジェクトを開始するときは常に、worker_max_memory_per_child というワーカーにメモリ制限を設定します。



これにより、OOM Killerがいつかは登場せず、すべてのワーカーが殺されることはなく、すべてのタスクが失われることはありません。 セロリは、必要に応じてワーカーを再起動します。

タスクの優先度

他の誰よりも早く、他の誰よりも早く完了しなければならないタスクが常にあります-今すぐ完了しなければなりません！ それほど重要ではないタスクがあります-日中に完了させてください。 このため、タスクには優先度パラメーターがあります。 Redisでは、非常に興味深い動作をします-優先度が追加された名前で新しいキューが作成されます。



私たちは異なるアプローチを使用します- 優先順位のために別々のワーカー 、つまり 昔ながらの方法で、異なる「重要性」を持つセロリの労働者を作成します。

 celery multi start high_priority low_priority -c:high_priority 2 -c:low_priority 6 -Q:high_priority urgent_notifications -Q:low_priority emails,urgent_notifications
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Celery multi startは、1台のマシンで同じコマンドラインからCelery構成全体を実行するのに役立つヘルパーです。 この例では、ノード（またはワーカー）を作成します：high_priorityとlow_priority、2と6は同時実行です。



2つのhigh_priorityワーカーは、常にurgent_notificationsキューを処理します。 誰もこれらのワーカーを使用しません。彼らはurgent_notificationsキューから重要なタスクのみを読み取ります。



重要でないタスクには、low_priorityキューがあります。 他のすべてのキューからメッセージを受信する6人のワーカーがいます。 また、low_priorityワーカーがurgent_notificationsにサブスクライブし、high_priorityワーカーが対処できない場合に支援できるようにします。



この古典的なスキームを使用して、タスクに優先順位を付けます。

抽出、変換、ロード

ほとんどの場合、ETLは一連のタスクのように見え、各タスクは前のタスクから入力を受け取ります。

 @task def download_account_data(account_id) … return account_id @task def process_account_data(account_id, processing_type) … return account_data @task def store_account_data(account_data) …
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例には3つのタスクがあります。 Celeryには、分散処理へのアプローチと、 チェーン関数を含むいくつかの有用なユーティリティがあり、3つのタスクから1つのパイプラインを作成します。

 chain( download_account_data.s(account_id), process_account_data.s(processing_type='fast'), store_account_data.s() ).delay()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セロリはパイプラインを分解し、最初のタスクを最初に実行し、次に受信したデータを2番目に転送し、2番目のタスクが返すデータは3番目に渡されます。 これが、シンプルなETLパイプラインの実装方法です。



より複雑なチェーンの場合、追加のロジックを接続する必要があります。 ただし、1つのタスクでこのチェーンに問題が発生すると、チェーン全体がバラバラになることに注意してください 。 この動作が望ましくない場合は、例外を処理して実行を継続するか、例外によってチェーン全体を停止します。



実際、内部のこのチェーンは、すべてのパラメーターを持つすべてのタスクを含む1つの大きなタスクのように見えます。 したがって、チェーン内のタスクの数を乱用すると、非常に高いメモリ消費とプロセス全体のスローダウンが発生します。 数千のタスクのチェーンを作成するのは悪い考えです。

バッチタスク処理

ここで最も興味深いのは、200万人のユーザーにメールを送信する必要がある場合に何が起こるかです。



すべてのユーザーに対してこのようなバイパス関数を作成します。

 @task def send_report_emails_to_users(): for user_id in User.get_active_ids(): send_report_email.delay(user_id=user_id)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、ほとんどの場合、関数はユーザーIDを受け取るだけでなく、一般的にユーザーテーブル全体を消去します。 各ユーザーには独自のタスクがあります。



このタスクにはいくつかの問題があります。

• タスクは順番に起動されます。つまり、最後のタスク（200万番目のユーザー）は20分で開始され、このタイムアウトまでに既に動作する可能性があります。
• すべてのユーザーIDは最初にアプリケーションメモリにロードされ、次にキューにロードされます-delay（）は200万タスクを実行します。

タスクフラッドと呼びます。チャートは次のようになります。



労働者がゆっくりと処理を開始するタスクの流入があります。 タスクがマスターレプリカを使用し、プロジェクト全体がクラックし始め、何も機能しない場合、次のことが起こります。 以下は、数時間にわたってDB CPU使用率が100％だったプラクティスの例です。正直なところ、なんとか怖がってしまいました。



問題は、ユーザー数の増加に伴ってシステムが大幅に劣化することです。 スケジューリングを扱うタスク：

• より多くのメモリが必要です。
• より長く実行され、タイムアウトによって「殺される」ことができます。

タスクのフラッディングが発生します。タスクはキューに蓄積され、内部サービスだけでなく外部サービスにも大きな負荷がかかります。



労働者の競争力を低下させようとしましたが 、これはある意味で役立ちます-サービスの負荷が軽減されます。 または、内部サービスをスケーリングできます 。 しかし、これはジェネレーターの問題の解決にはなりません。 そして、外部サービスのパフォーマンスへの依存に影響を与えることはありません。

タスク生成

私たちは別の道を取ることにしました。 たいていの場合、今すぐ200万タスクすべてを実行する必要はありません。 これらの文字がそれほど重要でない場合、すべてのユーザーに通知を送信するのに通常4時間かかることがあります。



まず、 Celery.chunksを使用してみました 。

 send_report_email.chunks( ({'user_id': user.id} for user in User.objects.active()), n=100 ).apply_async()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

イテレータにもかかわらず、すべてのuser_idがメモリにロードされるため、これにより状況は変わりませんでした。 そして、すべての労働者は一連のタスクを取得し、労働者は少し休みますが、最終的にはこの決定に満足しませんでした。



ワーカーにrate_limitを設定して、1秒あたり特定の数のタスクのみを処理するようにしました。実際にタスクに対して指定されたrate_limitはワーカーのrate_limitであることがわかりました。 つまり、タスクにrate_limitを指定した場合、これはタスクが毎秒70回実行されることを意味しません。 これは、ワーカーが1秒間に70回実行することを意味します。また、ワーカーに何があるかによって、この制限は動的に変更される可能性があります。 実際の制限rate_limit * len（ワーカー）。



ワーカーが開始または停止すると、合計rate_limitが変更されます。 さらに、タスクが遅い場合、ワーカーが埋めているキュー内のすべてのプリフェッチがこれらの遅いタスクで詰まります。 ワーカーは、「ああ、このタスクはrate_limitにあります。もう実行できません。 そして、キュー内の次のタスクはすべてまったく同じです-ハングさせてください！」-そして彼は待っています。

チャンフィフィケーター

最終的に、私たちは独自のライブラリを作成することを決定し、Chunkificatorと呼ばれる小さなライブラリを作成しました。

 @task @chunkify_task(sleep_timeout=...l initial_chunk=...) def send_report_emails_to_users(chunk: Chunk): for user_id in User.get_active_ids(chunk=chunk): send_report_email.delay(user_id=user_id)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

sleep_timeoutとinitial_chunkを取り、新しいチャンクで自分自身を呼び出します。 チャンクは、整数リスト、または日付または日時リストの抽象化です。 このチャンクを持つユーザーのみを受け取る関数にチャンクを渡し、そのチャンクに対してのみタスクを実行します。



したがって、タスクジェネレーターは必要な数のタスクのみを実行し、大量のメモリを消費しません。 写真はこんな感じになっています。



ハイライトは、スパースチャンクを使用することです。つまり、データベース内のインスタンスをチャンクIDとして使用します（一部はスキップされる可能性があるため、タスクが少なくなる可能性があります）。 その結果、負荷はより均一になり、プロセスは長くなりましたが、誰もが生きていて、ベースは緊張していません。



このライブラリは Python 3.6+用に実装されており、GitHubで入手できます。 修正する予定のニュアンスがありますが、今のところdatetime-chunkにはpickleシリアライザーが必要です-多くはこれを行うことができません。



いくつかの修辞的な質問-これらの情報はどこから来たのですか？ 問題があることをどのようにして発見したのですか？ 問題がまもなく重要になり、すでに解決し始める必要があることをどのように知っていますか？



答えは、もちろん監視です。

モニタリング

私はモニタリングが本当に好きです。私はすべてをモニターし、脈拍に指を当てるのが好きです。 パルスに指を置かない場合、レーキを常に踏むことになります。



標準的な監視の質問：

• 現在のワーカー/同時実行性構成は負荷を処理しますか？
• タスク実行時間の低下とは何ですか？
• タスクはどれくらいの時間並んでハングしますか？ 突然、行はすでに混雑していますか？

いくつかのオプションを試しました。 CeleryにはCLIインターフェースがあり、非常に豊富であり、以下を提供します。

• 検査-システムに関する情報。
• 制御-システム設定の管理。
• パージ-キューをクリア（不可抗力）;
• イベント-実行中のタスクに関する情報を表示するためのコンソールUI。

しかし、実際に何かを監視するのは難しいです。 ローカルのフリルや、実行時にrate_limitを変更したい場合に適しています。



注： CLIインターフェースを使用するには、実動ブローカーにアクセスする必要があります。



Celery Flowerを使用すると、CLIと同じことができますが、Webインターフェースを使用する必要がありますが、それだけではありません。 ただし、いくつかの単純なグラフを作成し、その場で設定を変更できます。



一般に、セロリフラワーは、小さなセットアップですべてがどのように機能するかを確認するのに適しています。 さらに、HTTP APIをサポートしています。つまり、自動化を記述している場合に便利です。



しかし、私たちはプロメテウスに落ち着きました。 彼らは現在のエクスポーターを奪いました：それのメモリリークを修正しました。 タイプ例外別にメトリックを追加。 キュー内のメッセージ数のメトリックを追加。 Grafanaのアラートと統合し、喜ぶ。 GitHubにも投稿されています 。 こちらで確認できます 。

Grafanaの例

上記はすべての例外の統計です：どのタスクのどの例外。 以下は、タスクを完了する時間です。

Celeryには何が欠けていますか？

これは緑豊かなフレームワークであり、多くのものがありますが、欠落しています！ 次のような十分な小さな機能がありません。

• 開発中にコードを自動的にリロードします -このCeleryをサポートしていません-再起動します。
• Prometheusのメトリックはそのまま使用できますが、Dramatiqは可能です。
• タスクロックの サポート -一度に1つのタスクのみが実行されます。 あなたは自分でそれを行うことができますが、DramatiqとTasktigerには、同じ種類の他のすべてのタスクがブロックされることを保証する便利なデコレータがあります。
• 1つのタスクのRate_limit-ワーカーではありません。

結論

Celeryは多くの実稼働環境で使用されるフレームワークであるという事実にもかかわらず、3つのライブラリ（Celery、Kombu、およびBilliard）で構成されています。 これら3つのライブラリはすべて共同開発者によって開発されており、1つの依存関係を解放してアセンブリを破壊する可能性があります。



したがって、何らかの方法で既に整理し、アセンブリを決定論的にしたことを願っています。



実際、結論はそれほど悲しいものではありません。 セロリは、当社の負荷下でフィンテックプロジェクトのタスクに対応しています。 私たちはあなたと共有した経験を得ました。あなたは私たちの解決策を適用したり、それらを改良したり、あなたのすべての困難を克服したりすることができます。



監視はプロジェクトの重要な部分であるべきであることを忘れないでください 。 監視によってのみ、どこに問題があるのか​​、何を修正、追加、修正する必要があるのか​​を見つけることができます。



コンタクトスピーカーOleg Churkin ： Bahusss 、 facebook 、 github 。

次の大きなモスクワPython Conf ++は、4月5日にモスクワで開催されます。 今年は、実験モードですべてのメリットを1日で満たそうとします。 これに劣らないレポートがあり、ストリーム全体が、有名なライブラリと製品の外国の開発者に割り当てられます。 さらに、金曜日はアフターパーティにとって理想的な日であり、ご存知のように、これはコミュニケーション会議の不可欠な部分です。



専門のPythonカンファレンスに参加してください。 ここでレポートを送信し、チケットを予約してください。 それまでの間、準備が進行中です。モスクワPython Conf ++ 2018に関する記事がここに表示されます。