フォールト トレランスと高可用性は大きなトピックであるため、RabbitMQ と Kafka については別の記事に充てます。 この記事は RabbitMQ について、次の記事は Kafka について、RabbitMQ と比較して説明します。 長い記事なので気楽に読んでください。

フォールト トレランス、一貫性、および高可用性 (HA) 戦略と、各戦略によって生じるトレードオフを見てみましょう。 RabbitMQ はノードのクラスター上で実行でき、分散システムとして分類されます。 分散システムに関しては、一貫性と可用性についてよく話されます。

これらの概念は、システムに障害が発生したときにシステムがどのように動作するかを説明します。 ネットワーク接続の障害、サーバーの障害、ハードドライブの障害、ガベージ コレクション、パケット損失、またはネットワーク接続の速度低下によるサーバーの一時的な使用不能。 これらすべてがデータの損失や競合につながる可能性があります。 完全に一貫性があり (データ損失やデータの相違がない)、すべての障害シナリオに対応できる (読み取りと書き込みを受け入れる) 両方のシステムを構築することは事実上不可能であることがわかりました。

一貫性と可用性は対極にあり、どちらを最適化するかを選択する必要があることがわかります。 良いニュースは、RabbitMQ ではこの選択が可能であるということです。 一貫性を高めたり、アクセシビリティを高めたりする方向にバランスを変えるには、このような「オタク的な」レバーが必要です。

どの構成が確認されたレコードによってデータ損失につながるかについては、特に注意を払います。 出版社、ブローカー、消費者の間には責任の連鎖があります。 メッセージがブローカーに送信されると、メッセージを失わないようにするのがブローカーの仕事です。 ブローカーが発行者によるメッセージの受信を確認した場合、メッセージが失われることはないと考えられます。 ただし、ブローカーとパブリッシャーの構成によっては、これが実際に発生する可能性があることがわかります。

単一ノードの復元プリミティブ

回復力のあるキューイング/ルーティング

RabbitMQ には、耐久性と非耐久性の XNUMX 種類のキューがあります。 すべてのキューは Mnesia データベースに保存されます。 永続キューはノードの起動時に再アドバタイズされるため、再起動、システム クラッシュ、またはサーバー クラッシュが発生しても (データが保持されている限り) 存続します。 これは、ルーティング (交換) とキューの回復力があると宣言している限り、キュー/ルーティング インフラストラクチャがオンラインに戻ることを意味します。

揮発性キューとルーティングは、ノードが再起動されると削除されます。

永続的なメッセージ

キューに耐久性があるからといって、そのすべてのメッセージがノードの再起動後も存続するとは限りません。 発行者によって設定されたメッセージのみ 持続可能な （持続的）。 永続的なメッセージはブローカーに追加の負荷をもたらしますが、メッセージの損失が許容できない場合は、他に選択肢はありません。

米。 1. 持続可能性マトリックス

キューミラーリングによるクラスタリング

ブローカーの喪失に耐えるためには、冗長性が必要です。 複数の RabbitMQ ノードを XNUMX つのクラスターに結合し、複数のノード間でキューを複製することで冗長性を追加できます。 こうすることで、XNUMX つのノードに障害が発生した場合でも、データが失われず、利用可能な状態が維持されます。

キューのミラーリング:

• すべての書き込みおよび読み取りコマンドを受信する XNUMX つのメイン キュー (マスター)
• メインキューからすべてのメッセージとメタデータを受信する XNUMX つ以上のミラー。 これらのミラーはスケーリングのために存在するのではなく、純粋に冗長性のために存在します。

米。 2. キューのミラーリング

ミラーリングは適切なポリシーによって設定されます。 ここでは、レプリケーション係数を選択したり、キューを配置するノードを選択したりできます。 例:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (XNUMX つのマスターと XNUMX つのミラー)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

発行者の確認

一貫した記録を達成するには、発行者確認が必要です。 これらがないと、メッセージが失われる危険があります。 メッセージがディスクに書き込まれた後、確認が発行者に送信されます。 RabbitMQ は、受信時ではなく、数百ミリ秒程度の周期でメッセージをディスクに書き込みます。 キューがミラーリングされると、すべてのミラーがメッセージのコピーをディスクに書き込んだ後でのみ、確認応答が送信されます。 つまり、確認を使用すると遅延が増加しますが、データのセキュリティが重要な場合は確認が必要になります。

フェイルオーバーキュー

ブローカーが終了またはクラッシュすると、そのノード上のすべてのキュー リーダー (マスター) も一緒にクラッシュします。 次に、クラスターは各マスターの最も古いミラーを選択し、それを新しいマスターとして昇格させます。

米。 3. 複数のミラーリングされたキューとそのポリシー

ブローカー 3 がダウンします。 ブローカー 2 のキュー C ミラーがマスターに昇格していることに注意してください。 また、ブローカー 1 のキュー C に対して新しいミラーが作成されたことにも注意してください。 RabbitMQ は常に、ポリシーで指定されたレプリケーション係数を維持しようとします。

米。 4. ブローカー 3 が失敗し、キュー C が失敗します。

次のブローカー 1 が落ちます! ブローカーは XNUMX 人だけ残っています。 キュー B ミラーがマスターに昇格します。

図。 5

ブローカー 1 を返しました。ブローカーの損失と回復後にデータがどの程度存続するかに関係なく、ミラー化されたすべてのキュー メッセージは再起動時に破棄されます。 結果が生じる可能性があるため、これは注意することが重要です。 これらの影響については後ほど見ていきます。 したがって、ブローカー 1 は再びクラスターのメンバーになり、クラスターはポリシーに準拠しようとするため、ブローカー 1 にミラーを作成します。

この場合、データと同様にブローカー 1 も完全に失われているため、ミラー化されていないキュー B は完全に失われています。

米。 6. ブローカー 1 がサービスに戻ります

ブローカー 3 がオンラインに戻ったので、キュー A と B は、HA ポリシーを満たすためにその上に作成されたミラーを取り戻します。 しかし、現在はすべてのメイン キューが XNUMX つのノード上にあります。 これは理想的ではありません。ノード間で均等に分散する方が良いです。 残念ながら、マスターのバランスを再調整するためのオプションはあまりありません。 最初にキューの同期を確認する必要があるため、この問題については後でもう一度説明します。

米。 7. ブローカー 3 はサービスに戻ります。 すべてのメインキューが XNUMX つのノード上にあります。

これで、ミラーがどのように冗長性と耐障害性を提供​​するかについて理解できたはずです。 これにより、単一ノードに障害が発生した場合でも可用性が確保され、データ損失が防止されます。 しかし、実際にはもっと複雑なので、まだ終わっていません。

Синхронизация

新しいミラーを作成すると、すべての新しいメッセージが常にこのミラーと他のミラーにレプリケートされます。 マスター キュー内の既存のデータについては、新しいミラーに複製することができ、これがマスターの完全なコピーになります。 また、既存のメッセージを複製しないことを選択して、メイン キューと新しいミラーを時間内に収束させ、新しいメッセージが最後尾に到着し、既存のメッセージがメイン キューの先頭から出るようにすることもできます。

この同期は自動または手動で実行され、キュー ポリシーを使用して管理されます。 例を見てみましょう。

ミラーリングされたキューが XNUMX つあります。 キュー A は自動的に同期され、キュー B は手動で同期されます。 どちらのキューにも XNUMX 個のメッセージが含まれています。

米。 8. 異なる同期モードを持つ XNUMX つのキュー

現在、ブローカー 3 に負けています。

米。 9. ブローカー 3 が落ちた

ブローカー 3 がサービスに戻ります。 クラスターは新しいノード上の各キューのミラーを作成し、新しいキュー A をマスターと自動的に同期します。 ただし、新しいキュー B のミラーは空のままです。 このようにして、キュー A には完全な冗長性が確保され、既存のキュー B メッセージにはミラーが XNUMX つだけ確保されます。

米。 10. キュー A の新しいミラーは既存のメッセージをすべて受信しますが、キュー B の新しいミラーは受信しません。

さらに 2 個のメッセージが両方のキューに到着します。 その後、ブローカー 1 がクラッシュし、キュー A はブローカー XNUMX 上にある最も古いミラーにロールバックします。障害が発生してもデータは失われません。 キュー B では、マスターに XNUMX 個のメッセージがあり、ミラーには XNUMX 個だけのメッセージがあります。これは、このキューが元の XNUMX 個のメッセージを複製していないためです。

米。 11. キュー A はメッセージを失うことなくブローカー 1 にロールバックします。

さらに 1 個のメッセージが両方のキューに到着します。 ここで、ブローカー XNUMX がクラッシュしますが、キュー A はメッセージを失うことなく簡単にミラーに切り替わります。 ただし、キュー B には問題があります。 この時点で、可用性または一貫性のいずれかを最適化できます。

アクセシビリティを最適化したい場合は、ポリシー ha-失敗時のプロモート にインストールする必要があります 常に。 これはデフォルト値であるため、ポリシーをまったく指定しないこともできます。 この場合、基本的に、非同期ミラーでの障害が許容されます。 これによりメッセージは失われますが、キューは読み取りおよび書き込み可能のままです。

米。 12. キュー A は、メッセージを失うことなくブローカー 3 にロールバックされます。 キュー B がブローカー 3 にロールバックし、XNUMX 個のメッセージが失われる

取り付けも可能です ha-promote-on-failure 意味に when-synced。 この場合、キューはミラーにロールバックする代わりに、データを持つブローカー 1 がオンライン モードに戻るまで待機します。 復帰後、メイン キューはデータ損失なくブローカー 1 に戻ります。 データのセキュリティのために可用性が犠牲になります。 ただし、これはデータの完全な損失につながる可能性がある危険なモードです。これについては後ほど説明します。

米。 13. ブローカー 1 を失った後、キュー B は利用できないままになる

「自動同期は使わないほうが良いのですか?」と疑問に思われるかもしれません。 答えは、同期はブロック操作であるということです。 同期中、メイン キューは読み取りまたは書き込み操作を実行できません。

例を見てみましょう。 今では非常に長い行列ができています。 どうすればそのような大きさに成長することができるのでしょうか？ いくつかの理由で：

• キューは積極的に使用されません
• これらは高速キューであり、現時点ではコンシューマーの速度が遅い
• 高速キューで障害が発生し、消費者が追いつきつつあります

米。 14. 異なる同期モードを持つ XNUMX つの大きなキュー

ここでブローカー 3 が倒れます。

米。 15. ブローカー 3 がフォールし、各キューに XNUMX つのマスターとミラーが残る

Broker 3 がオンラインに戻り、新しいミラーが作成されます。 メイン キュー A は、既存のメッセージを新しいミラーに複製し始めますが、この間、キューは使用できなくなります。 データの複製には XNUMX 時間かかり、その結果、このキューのダウンタイムは XNUMX 時間になります。

ただし、キュー B は期間全体を通じて利用可能なままです。 彼女はアクセシビリティのために冗長性をある程度犠牲にしました。

米。 16. 同期中にキューが利用できない状態になる

XNUMX 時間後、キュー A も使用可能になり、再び読み取りと書き込みの受け入れを開始できるようになります。

アップデート

同期中のこのブロック動作により、非常に大きなキューを持つクラスターの更新が困難になります。 ある時点で、マスター ノードを再起動する必要があります。これは、サーバーのアップグレード中にミラーに切り替えるか、キューを無効にすることを意味します。 移行を選択した場合、ミラーが同期していないとメッセージが失われます。 デフォルトでは、ブローカーの停止中、非同期ミラーへのフェイルオーバーは実行されません。 これは、ブローカーが戻るとすぐにメッセージが失われることはなく、損傷したのは単純なキューだけであることを意味します。 ブローカーが切断されたときの動作ルールはポリシーによって設定されます ha-promote-on-shutdown。 次の XNUMX つの値のいずれかを設定できます。

• always= 非同期ミラーへの移行が有効になっています
• when-synced= 同期ミラーのみに移行します。それ以外の場合、キューは読み取りおよび書き込みできなくなります。 ブローカーが戻るとすぐにキューはサービスに戻ります

いずれにせよ、キューが大きい場合、データ損失か利用不能のどちらかを選択する必要があります。

可用性によってデータ セキュリティが向上する場合

決定を下す前に考慮すべき複雑な問題がもう XNUMX つあります。 自動同期は冗長性にとっては優れていますが、データのセキュリティにはどのような影響があるのでしょうか? もちろん、冗長性が向上すると、RabbitMQ は既存のメッセージを失う可能性が低くなりますが、パブリッシャーからの新しいメッセージはどうなるでしょうか?

ここでは、次の点を考慮する必要があります。

• 発行者は単純にエラーを返し、上流のサービスまたはユーザーに後で再試行させることができますか?
• 発行者はメッセージをローカルまたはデータベースに保存して、後で再試行できますか?

発行者がメッセージを破棄することしかできない場合、実際には、アクセシビリティを向上させることでデータのセキュリティも向上します。

したがって、バランスを図る必要があり、解決策は特定の状況によって異なります。

ha-promote-on-failure=when-synced に関する問題

アイデア ha-失敗時のプロモート= 同期時 それは、非同期ミラーへの切り替えを防ぎ、それによってデータ損失を回避することです。 キューは読み取りまたは書き込みできないままになります。 代わりに、データを失うことなくマスターとして機能を再開できるように、クラッシュしたブローカーをデータをそのままにして回復しようとします。

しかし (これは大きな問題ですが) ブローカーがデータを失った場合、キューが失われるという大きな問題が発生します。 データが全部消えてしまった！ メインキューにほぼ追いつくミラーがある場合でも、それらのミラーも破棄されます。

同じ名前のノードを再度追加するには、失われたノードを忘れるようクラスターに指示します (コマンドを使用) Rabbitmqctl 忘れた_cluster_node) し、同じホスト名で新しいブローカーを開始します。 クラスターは失われたノードを記憶していますが、古いキューと同期されていないミラーも記憶しています。 クラスターが孤立したノードを忘れるように指示されると、そのキューも忘れられます。 今、それを再宣言する必要があります。 部分的なデータセットを含むミラーはありましたが、すべてのデータを失いました。 非同期ミラーに切り替えた方が良いでしょう！

したがって、手動同期 (および同期の失敗) と、 ha-promote-on-failure=when-synced、私の意見では、かなり危険です。 ドキュメントには、このオプションはデータセキュリティのために存在すると書かれていますが、これは諸刃のナイフです。

マスターのリバランス

約束どおり、XNUMX つまたは複数のノード上のすべてのマスターの蓄積の問題に戻ります。 これは、クラスターのローリング更新の結果として発生する可能性もあります。 XNUMX ノードのクラスターでは、すべてのマスター キューが XNUMX つまたは XNUMX つのノードに蓄積されます。

マスターのリバランスには、次の XNUMX つの理由から問題が発生する可能性があります。

• リバランスを実行するための適切なツールがない
• キューの同期

リバランスのためのサードパーティが存在する プラグイン、これは正式にはサポートされていません。 RabbitMQマニュアルのサードパーティ製プラグインについて 言われる: 「このプラグインは追加の構成およびレポート ツールを提供しますが、RabbitMQ チームによってサポートまたは検証されていません。 自己責任。"

HA ポリシーを通じてメイン キューを移動する別のトリックがあります。 マニュアルには次のように記載されています 脚本 このために。 それはこのように動作します：

• 既存の HA ポリシーよりも優先度の高い一時ポリシーを使用して、すべてのミラーを削除します。
• ノード モードを使用するように HA 一時ポリシーを変更し、マスター キューの転送先ノードを指定します。
• プッシュ移行用にキューを同期します。
• 移行が完了したら、一時ポリシーを削除します。 初期 HA ポリシーが有効になり、必要な数のミラーが作成されます。

欠点は、キューが大きい場合や厳格な冗長性要件がある場合には、このアプローチが機能しない可能性があることです。

次に、RabbitMQ クラスターがネットワーク パーティションでどのように動作するかを見てみましょう。

接続の喪失

分散システムのノードはネットワーク リンクによって接続されており、ネットワーク リンクは切断される可能性があり、切断されることになります。 停止の頻度は、ローカルのインフラストラクチャまたは選択したクラウドの信頼性によって異なります。 いずれにせよ、分散システムはそれらに対処できなければなりません。 ここでも可用性と一貫性のどちらかを選択する必要がありますが、ここでも良いニュースは、RabbitMQ が両方のオプションを (同時にではなく) 提供することです。

RabbitMQ には XNUMX つの主なオプションがあります。

• 論理的な分割 (スプリット ブレイン) を許可します。 これにより可用性が確保されますが、データ損失が発生する可能性があります。
• 論理的な分離を無効にします。 クライアントがクラスターに接続する方法によっては、短期間で可用性が失われる可能性があります。 XNUMX ノードのクラスターでは完全に利用不能になる可能性もあります。

しかし、論理的な分離とは何でしょうか? これは、ネットワーク接続の喪失によりクラスターが XNUMX つに分割される場合です。 それぞれの側でミラーがマスターに昇格されるため、最終的にはキューごとに複数のマスターが存在します。

米。 17. メインキューと XNUMX つのミラー (それぞれ別のノード上にあります)。 その後、ネットワーク障害が発生し、XNUMX つのミラーが切断されます。 分離されたノードは、他の XNUMX つのノードが外れたことを確認し、そのミラーをマスターに昇格させます。 これで、書き込み可能と読み取り可能な XNUMX つのメイン キューができました。

パブリッシャーが両方のマスターにデータを送信すると、キューの XNUMX つの異なるコピーが作成されます。

RabbitMQ のさまざまなモードにより、可用性または一貫性が提供されます。

無視モード (デフォルト)

このモードではアクセシビリティが保証されます。 接続が失われると、論理的な分離が発生します。 接続が回復したら、管理者はどのパーティションを優先するかを決定する必要があります。 負けた側は再起動され、その側に蓄積されたデータはすべて失われます。

米。 18. 2 つの出版社が XNUMX つのブローカーと関連付けられています。 内部的には、クラスターはすべてのリクエストをブローカー XNUMX のメイン キューにルーティングします。

今、私たちはブローカー 3 に負けています。彼は他のブローカーが落ちたのを見て、自分のミラーをマスターに昇格させます。 このようにして論理的な分離が発生します。

米。 19. 論理分割 (スプリットブレイン)。 レコードは XNUMX つのメイン キューに入り、XNUMX つのコピーは分岐します。

接続は回復しますが、論理的な分離は残ります。 管理者は負ける側を手動で選択する必要があります。 以下のケースでは、管理者はブローカー 3 を再起動します。管理者が送信できなかったメッセージはすべて失われます。

米。 20. 管理者は Broker 3 を無効にします。

米。 21. 管理者がブローカー 3 を起動すると、ブローカー XNUMX がクラスターに参加しますが、そこに残されていたメッセージはすべて失われます。

接続の喪失中およびその復元後、クラスターとこのキューは読み取りと書き込みに使用できました。

自動修復モード

接続を分割して復元した後、クラスタ自体が自動的に損失側を選択する点を除いて、無視モードと同様に動作します。 負けた側は空のクラスターに戻り、キューはその側にのみ送信されたすべてのメッセージを失います。

マイノリティモードを一時停止する

論理パーティション化を許可したくない場合、唯一の選択肢は、クラスターのパーティション化後の小さい側の読み取りと書き込みを破棄することです。 ブローカーは、接続が小規模であると判断すると、作業を一時停止します。つまり、既存の接続をすべて閉じ、新しい接続を拒否します。 XNUMX 秒に XNUMX 回、接続の復元がチェックされます。 接続が回復すると、動作が再開され、クラスターに参加します。

米。 22. 2 つの出版社が XNUMX つのブローカーと関連付けられています。 内部的には、クラスターはすべてのリクエストをブローカー XNUMX のメイン キューにルーティングします。

次に、ブローカー 1 と 2 はブローカー 3 から分離します。ブローカー 3 はミラーをマスターに昇格させる代わりに一時停止し、使用できなくなります。

米。 23. ブローカー 3 は一時停止し、すべてのクライアントを切断し、接続要求を拒否します。

接続が復元されると、クラスターに戻ります。

メイン キューがブローカー 3 にある別の例を見てみましょう。

米。 24. ブローカー 3 のメインキュー。

その後、同じ接続の喪失が発生します。 ブローカー 3 は規模が小さいため一時停止します。 一方、ノードはブローカー 3 が機能しなくなったことを認識し、ブローカー 1 と 2 の古いミラーがマスターに昇格します。

米。 25. ブローカー 2 が利用できない場合は、ブローカー 3 に移行します。

接続が復元されると、ブローカー 3 がクラスターに参加します。

米。 26. クラスターは通常の動作に戻りました。

ここで理解しておくべき重要なことは、一貫性を確保するだけでなく、可用性も確保できるということです。 場合 クライアントをほとんどのセクションに正常に転送します。 ほとんどの状況では、私は個人的に [一時停止マイノリティ] モードを選択しますが、それは個々のケースによって異なります。

可用性を確保するには、クライアントがホストに正常に接続していることを確認することが重要です。 オプションを見てみましょう。

顧客の接続性の確保

接続が失われた後、クライアントをクラスターの主要部分または動作中のノード (XNUMX つのノードに障害が発生した後) に誘導する方法については、いくつかのオプションがあります。 まず、特定のキューは特定のノードでホストされますが、ルーティングとポリシーはすべてのノードにわたってレプリケートされることを思い出してください。 クライアントは任意のノードに接続でき、内部ルーティングによって目的地に誘導されます。 ただし、ノードが一時停止されると接続が拒否されるため、クライアントは別のノードに接続する必要があります。 ノードが落ちた場合、彼にできることはほとんどありません。

私たちのオプション:

• クラスターにはロード バランサーを使用してアクセスします。ロード バランサーはノードを循環するだけであり、クライアントは成功するまで接続を再試行します。 ノードがダウンまたはサスペンドされている場合、そのノードへの接続試行は失敗しますが、それ以降の試行は他のサーバーに (ラウンドロビン方式で) 行われます。 これは、短期間の接続喪失や、ダウンしたサーバーがすぐに復旧する場合に適しています。
• ロード バランサーを介してクラスターにアクセスし、一時停止/障害が発生したノードが検出されたらすぐにリストから削除します。 これを迅速に実行し、クライアントが接続を再試行できれば、一定の可用性が実現されます。
• 各クライアントにすべてのノードのリストを与えると、クライアントは接続時にそのうちの XNUMX つをランダムに選択します。 接続しようとしたときにエラーを受信した場合、接続するまでリスト内の次のノードに移動します。
• DNS を使用して、障害が発生したノードまたは一時停止されたノードからトラフィックを削除します。 これは小さい TTL を使用して行われます。

所見

RabbitMQ クラスタリングには利点と欠点があります。 最も深刻な欠点は次のとおりです。

• クラスターに参加すると、ノードはデータを破棄します。
• 同期をブロックすると、キューが使用できなくなります。

すべての難しい決定は、これら XNUMX つのアーキテクチャ上の特徴から生じます。 クラスターが再結合されたときに RabbitMQ がデータを保存できれば、同期はより高速になります。 ノンブロッキング同期が可能であれば、大規模なキューのサポートが向上するでしょう。 これら XNUMX つの問題を修正すると、耐障害性と可用性の高いメッセージング テクノロジとしての RabbitMQ のパフォーマンスが大幅に向上します。 次のような状況では、クラスタリングを備えた RabbitMQ を推奨することはためらわれます。

• 信頼できないネットワーク。
• 信頼性の低いストレージ。
• 非常に長い行列ができています。

高可用性設定に関しては、次の点を考慮してください。

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore （または autoheal)
• 永続的なメッセージ
• 一部のノードに障害が発生した場合にクライアントがアクティブ ノードに接続できるようにする

一貫性 (データ セキュリティ) を確保するには、次の設定を考慮してください。

• パブリッシャーによる確認と消費者側での手動承認
• ha-promote-on-failure=when-synced、発行者が後で再試行できる場合、および非常に信頼できるストレージがある場合。 それ以外の場合は置く =always.
• ha-sync-mode=automatic (ただし、非アクティブなキューが大きい場合は、手動モードが必要になる場合があります。また、利用できないことでメッセージが失われるかどうかも考慮してください)
• マイノリティモードを一時停止する
• 永続的なメッセージ

耐障害性と高可用性の問題をすべてまだカバーしていません。 たとえば、管理手順 (ローリング アップデートなど) を安全に実行する方法などです。 フェデレーションと Shovel プラグインについても話す必要があります。

他に何か見逃していることがあれば、お知らせください。

私のものも参照してください 投稿するここでは、Docker と Blockade を使用して RabbitMQ クラスターで大混乱を実行し、この記事で説明されているメッセージ損失シナリオのいくつかをテストします。

シリーズの以前の記事：
No.1- habr.com/ru/company/itsumma/blog/416629
No.2- habr.com/ru/company/itsumma/blog/418389
No.3- habr.com/ru/company/itsumma/blog/437446

出所： habr.com