HighLoad++、Evgeniy Kuzovlev (EcommPay IT): 100000 分間のダウンタイムで XNUMX ドルの損失が発生した場合の対処方法

誰もが開発とテストのプロセス、スタッフのトレーニング、モチベーションの向上について話しますが、サービスのダウンタイムが XNUMX 分でも莫大な費用がかかる場合、これらのプロセスだけでは十分ではありません。 厳格な SLA に基づいて金融取引を実行する場合はどうすればよいですか? 開発とテストを不要にして、システムの信頼性と耐障害性を高めるにはどうすればよいでしょうか?

次回の HighLoad++ カンファレンスは、6 年 7 月 2020 日と XNUMX 日にサンクトペテルブルクで開催されます。 詳細とチケットは、 リンク。 9月18日00時。 HighLoad++ モスクワ 2018、デリー + コルカタ ホール。 論文や プレゼンテーション.

エフゲニー・クゾブレフ（以下、EC）： - 友達、こんにちは！ 私の名前はクゾブレフ・エフゲニーです。 私は EcommPay 会社の出身で、特定の部門は企業グループの IT 部門である EcommPay IT です。 そして今日はダウンタイムについて、つまりダウンタイムを回避する方法、回避できない場合にその影響を最小限に抑える方法について話します。 このトピックは次のように述べられています:「100 分間のダウンタイムのコストが 000 ドルの場合はどうするか?」 将来を見据えると、私たちの数字は同等です。

EcommPay IT は何をしますか?

私たちは誰ですか？ なぜ私はここあなたの前に立っているのですか？ なぜ私にここで何かを言う権利があるのでしょうか？ ここでさらに詳しく何を話すのでしょうか?

EcommPay グループ企業は国際的な買収企業です。 当社は、ロシア、ヨーロッパ、東南アジア（全世界）など、世界中で支払いを処理します。 当社には9つのオフィスがあり、総従業員数は500名で、そのうち約半数弱がITスペシャリストです。 私たちが行うすべてのこと、私たちがお金を稼ぐすべてのことは、私たち自身でした。

私たちはすべての製品を自分たちで作成しました (そして、非常に多くの製品があります。当社の大型 IT 製品ラインには約 16 の異なるコンポーネントがあります)。 私たちは自分自身で書き、自分自身を開発します。 そして現時点では、私たちは XNUMX 日に約 XNUMX 万件のトランザクションを実行しています (おそらく数百万件という言い方が正しいでしょう)。 当社は設立してまだ XNUMX 年ほどのかなり若い会社です。

6年前、彼らがこのビジネスに加わったとき、それはそのようなスタートアップでした。 彼らはアイデアによって団結し（アイデア以外には何もありませんでした）、そして私たちは走りました。 他のスタートアップと同様に、私たちはより速く走りました...私たちにとって、スピードは品質よりも重要でした。

ある時点で私たちは立ち止まりました。私たちは、もはやそのスピードと品質で生活することは不可能であり、まず品質に焦点を当てる必要があることに気づきました。 現時点では、正確でスケーラブルで信頼性の高い新しいプラットフォームを作成することにしました。 彼らはこのプラットフォームの作成を開始しました (投資、開発、テストを開始しました) が、ある時点で、開発とテストでは新しいレベルのサービス品質に到達できないことに気づきました。

新しい製品を作り、生産を開始しますが、それでもどこかで問題が発生します。 そして今日は、開発とテストを方程式から外して、新しい品質レベルに到達する方法 (私たちがどのように達成したか、私たちの経験について) について話します。 運用で何が利用できるのか、つまり運用自体で何ができるのか、品質に影響を与えるためにテストに何を提供できるのかについて説明します。

ダウンタイム。 操作の戒め。

常に主要な基礎ですが、今日実際に説明するのはダウンタイムです。 ひどい言葉だ。 ダウンタイムがあると、すべてが悪いことになります。 私たちはそれを引き上げるために走っており、管理者はサーバーを保持しています。あの歌で歌われているように、サーバーが落ちないことを神は禁じています。 今日はこれについてお話します。

私たちがアプローチを変え始めたとき、私たちは 4 つの戒めを作りました。 それらをスライドに示しました。

これらの戒めは非常に単純です。

• 問題をすぐに特定します。
• さらに早く取り除いてください。
• 理由を理解するのに役立ちます (開発者向けに後で説明します)。
• そしてアプローチを標準化します。

ポイント 2 に注目していただきたいのですが、私たちは問題を解決しているのではなく、問題を解決しているのです。 決断することは二の次です。 私たちにとって最も重要なことは、ユーザーがこの問題から保護されることです。 それは何らかの隔離された環境に存在しますが、この環境はそれと一切接触しません。 実際に、これら XNUMX つの問題グループを検討し (いくつかはより詳細に、いくつかはそれほど詳細ではありません)、私たちが何を使用しているか、解決策においてどのような関連経験があるかをお話しします。

トラブルシューティング: トラブルはいつ発生し、どう対処すればよいですか?

しかし、順番どおりに始まりません。ポイント 2 から始めます。問題を素早く解決するにはどうすればよいでしょうか。 問題があります。それを修正する必要があります。 「これについてはどうすればいいでしょうか？」 - 主な質問。 そして、問題を解決する方法を考え始めたとき、トラブルシューティングで従わなければならないいくつかの要件を自分たちで開発しました。

これらの要件を明確にするために、「いつ問題が発生するのか」という質問を自分自身に問いかけることにしました。 そして、問題は次の XNUMX つのケースで発生することが判明しました。

• ハードウェア障害。
• 外部サービスが失敗しました。
• ソフトウェア バージョンの変更 (同じ展開)。
• 爆発的な負荷の増加。

最初の XNUMX つについては説明しません。 ハードウェアの誤動作は非常に簡単に解決できます。すべてを複製する必要があります。 これらがディスクの場合は、ディスクを RAID で組み立てる必要があります。これがサーバーの場合は、サーバーを複製する必要があります。ネットワーク インフラストラクチャがある場合は、ネットワーク インフラストラクチャの XNUMX 番目のコピーを提供する必要があります。それを複製します。 そして、何か障害が発生した場合は、予備電源に切り替えます。 ここでこれ以上何かを言うのは難しいです。

XNUMX つ目は、外部サービスの障害です。 ほとんどの人にとって、このシステムはまったく問題ありませんが、私たちにとってはそうではありません。 当社は支払いを処理するため、ユーザー (カード データを入力する) と銀行、支払いシステム (Visa、MasterCard、Mira など) の間に立つアグリゲーターです。 私たちの外部サービス (決済システム、銀行) は失敗する傾向があります。 私たちもあなたも (そのようなサービスを利用している場合) これに影響を与えることはできません。

それではどうすればいいでしょうか？ ここには XNUMX つのオプションがあります。 まず、可能であれば、このサービスを何らかの方法で複製する必要があります。 たとえば、可能であれば、トラフィックをあるサービスから別のサービスに転送します。たとえば、カードがズベルバンク経由で処理された場合、ズベルバンクに問題が発生した場合、トラフィックを[条件付きで]ライファイゼンに転送します。 XNUMX 番目にできることは、外部サービスの障害に迅速に気づくことです。そのため、レポートの次の部分で応答速度について説明します。

実際、これら XNUMX つのうち、特にソフトウェア バージョンの変更に影響を与えることができます。つまり、展開のコンテキストや負荷の爆発的な増加のコンテキストで、状況の改善につながるアクションを実行できます。 実際、それが私たちがやったことです。 ここでもう一度、ちょっとしたメモを…

これら XNUMX つの問題のうち、いくつかはクラウドがあればすぐに解決されます。 Microsoft Azhur、Ozone クラウドを使用している場合、または Yandex または Mail から当社のクラウドを使用している場合は、少なくともハードウェアの誤動作が問題となり、ハードウェアの誤動作のコンテキストではすべてがすぐに正常になります。

当社は少し変わった会社です。 ここでは誰もが「Kubernets」やクラウドについて話しています。私たちには「Kubernets」もクラウドもありません。 しかし、多くのデータセンターにはハードウェアのラックがあり、私たちはこのハードウェアで生活しなければならず、そのすべてに対して責任を負わなければなりません。 したがって、この文脈で話をします。 それで、問題点について。 最初の XNUMX つは括弧内に取り出されています。

ソフトウェアのバージョンを変更します。 拠点

当社の開発者は本番環境にアクセスできません。 何故ですか？ 私たちは PCI DSS 認定を受けているというだけで、開発者には「製品」に参入する権利がないだけです。 以上です。 全然。 したがって、開発責任は、開発がリリース用のビルドを送信した時点で終了します。

私たちが持つ XNUMX 番目の基盤は、これも非常に役に立ちますが、文書化されていない独自の知識がないことです。 あなたも同じだといいのですが。 そうしないと問題が発生するからです。 この文書化されていない独自の知識が適切なタイミングで適切な場所に存在しない場合、問題が発生します。 特定のコンポーネントのデプロイ方法を知っている人が XNUMX 人いるとします。その人は休暇中か病気で不在です。つまり、問題があります。

そして私たちがたどり着いた第三の基礎。 私たちは、痛み、血、涙を経てそれに到達しました。たとえエラーがなかったとしても、ビルドにはエラーが含まれているという結論に達しました。 私たちはこれを自分たちで決めました。何かをデプロイするとき、何かを運用環境に導入するとき、ビルドにはエラーが発生します。 私たちのシステムが満たさなければならない要件を形成しました。

ソフトウェアのバージョンを変更するための要件

次の XNUMX つの要件があります。

• すぐに展開をロールバックする必要があります。
• 導入の失敗による影響を最小限に抑える必要があります。
• そして、並行して迅速にデプロイできなければなりません。
  まさにその順番ですね！ なぜ？ まず第一に、新しいバージョンをデプロイするときは速度は重要ではありませんが、何か問題が発生した場合にすぐにロールバックして影響を最小限に抑えることが重要であるためです。 しかし、実稼働環境に一連のバージョンがあり、そのバージョンにエラーがあることが判明した場合 (突然、デプロイメントは行われていなかったが、エラーが発生しました)、その後のデプロイメントの速度が重要になります。 これらの要求を満たすために私たちは何をしてきたのでしょうか? 私たちは次の方法論を採用しました。

  
  
  これは非常によく知られていますが、私たちが発明したことはありません。これは Blue/Green デプロイです。 それは何ですか？ アプリケーションがインストールされているサーバーのグループごとにコピーが必要です。 コピーは「ウォーム」です。トラフィックは存在しませんが、いつでもこのトラフィックがこのコピーに送信される可能性があります。 このコピーには以前のバージョンが含まれています。 そして、展開時に、コードを非アクティブなコピーにロールアウトします。 次に、トラフィックの一部 (またはすべて) を新しいバージョンに切り替えます。 したがって、トラフィック フローを古いバージョンから新しいバージョンに変更するには、アクションは XNUMX つだけです。アップストリームのバランサを変更し、あるアップストリームから別のアップストリームに方向を変更する必要があります。 これは非常に便利で、素早い切り替えと素早いロールバックの問題を解決します。

  ここで、2 番目の質問に対する解決策は最小化です。つまり、トラフィックの一部だけを新しい回線、新しいコードを持つ回線に送信できます (たとえば、2% とする)。 そして、この 100% は 100% ではありません。 デプロイメントの失敗によりトラフィックが 2% 失われた場合、それは恐ろしいことですが、トラフィックの 5% が失われた場合、それは不快ではありますが、怖いことではありません。 さらに、場合によっては (すべてではありませんが) 同じユーザーが FXNUMX キーを押すと、別の動作中のバージョンに移動するため、ユーザーはこれに気付かない可能性がほとんどです。

  ブルー/グリーン展開。 ルーティング

  ただし、すべてがそれほど単純な「ブルー/グリーン デプロイ」というわけではありません...すべてのコンポーネントは XNUMX つのグループに分類できます。

  • これはフロントエンド (クライアントに表示される支払いページ) です。
  • 処理コア。
  • 支払いシステム (銀行、MasterCard、Visa など) を操作するためのアダプター。

  ここにはニュアンスがあります。ニュアンスは行間のルーティングにあります。 トラフィックを 100% 切り替えるだけであれば、これらの問題は発生しません。 しかし、2% に切り替えたい場合は、「どうすればよいでしょうか?」という疑問が生じます。 最も単純なことは単純明快です。ランダムな選択によって nginx でラウンド ロビンを設定でき、左側に 2%、右側に 98% を設定できます。 しかし、これが常に適切であるとは限りません。

  たとえば、この例では、ユーザーは複数のリクエストでシステムと対話します。 これは正常です: 2、3、4、5 リクエスト - システムは同じである可能性があります。 そして、すべてのユーザーのリクエストが最初のリクエストが来たのと同じ行に来ることが重要である場合、または (XNUMX 番目の点) すべてのユーザーのリクエストが切り替え後に新しい行に来ることが重要である場合 (ユーザーは、より早く作業を開始できたはずです)システム、切り替え前)、 - このランダムな分散はあなたには適していません。 次に、次のオプションがあります。

  
  
  最初のオプションは最も単純で、クライアントの基本パラメータ (IP ハッシュ) に基づきます。 IP を持っており、それを IP アドレスで右から左に分割します。 次に、私が説明した XNUMX 番目のケースがうまく機能します。デプロイメントが行われた時点で、ユーザーはすでにシステムの操作を開始しており、デプロイメントの瞬間からすべてのリクエストは新しい行 (たとえば、同じ行) に送られます。

  何らかの理由でこれが合わず、ユーザーの最初のリクエストが届いた回線にリクエストを送信する必要がある場合、選択肢は XNUMX つあります...
  最初のオプション: 有料の nginx+ を購入できます。 スティッキー セッション メカニズムがあり、ユーザーの最初のリクエストに応じてセッションをユーザーに割り当て、それをいずれかのアップストリームにバインドします。 セッション存続期間内の後続のすべてのユーザー要求は、セッションが投稿されたのと同じアップストリームに送信されます。

  すでに通常の nginx を持っていたため、これは私たちには合わなかったのです。 nginx+ への切り替えは、費用がかかるということではなく、私たちにとって多少苦痛であり、あまり適切ではなかっただけです。 たとえば、「Sticks セッション」は、「Sticks セッション」では「どちらか」に基づくルーティングが許可されていないという単純な理由で機能しませんでした。 そこでは、たとえば、IP アドレス、IP アドレスと Cookie、ポストパラメータなどによって、「Sticks セッション」が何を行うかを指定できますが、「どちらか」はより複雑です。

  したがって、XNUMX 番目の選択肢にたどり着きました。 私たちは nginx をさらに強化しました (これは openresty です)。これは同じ nginx で、さらに最後のスクリプトのインクルードをサポートしています。 最後のスクリプトを作成し、「オープンレスト」を指定すると、ユーザーリクエストが来たときにこの最後のスクリプトが実行されます。

  実際、私たちはそのようなスクリプトを作成し、自分自身を「openresti」に設定し、このスクリプトでは連結「Or」によって 6 つの異なるパラメーターを並べ替えています。 XNUMX つまたは別のパラメータの存在に応じて、ユーザーがあるページ、別の行、または別のページにアクセスしたことがわかります。

  ブルー/グリーン展開。 長所と短所

  もちろん、もう少しシンプルにすることも可能でした (同じ「スティッキー セッション」を使用) が、ユーザーが XNUMX つのトランザクションの XNUMX つの処理の枠組み内で対話するだけではないというニュアンスも持たせています...しかし、支払いシステムも私たちと対話します。私たちが (支払いシステムにリクエストを送信することによって) トランザクションを処理した後、クールバックを受け取ります。
  そして、回路内ですべてのリクエストでユーザーの IP アドレスを転送し、IP アドレスに基づいてユーザーを分割できる場合は、同じ「Visa」に次のように言うことはなくなります。 (Web サイトおよびロシアで) 国際的になるように...追加フィールドにユーザーの IP アドレスを入力してください。プロトコルは標準化されています。」 彼らが同意しないことは明らかです。

  
  
  したがって、これは私たちにとってはうまくいきませんでした。私たちは openresty を実行しました。 したがって、ルーティングを使用すると、次のようになります。

  したがって、ブルー/グリーン展開には、前述した利点と欠点があります。

  XNUMX つの欠点:

  • ルーティングを気にする必要があります。
  • XNUMX 番目の主な欠点は費用がかかることです。

  この動物園全体を維持するには、XNUMX 倍のサーバー、XNUMX 倍の運営リソース、XNUMX 倍の労力が必要です。

  ところで、利点の中には、これまで言及していなかったもう 50 つの利点があります。それは、負荷が増加した場合に備えて予備があることです。 負荷が爆発的に増加し、多数のユーザーがいる場合は、50 対 2 の分布に XNUMX 行目を含めるだけで、サーバーの増加の問題が解決されるまで、すぐにクラスター内に xXNUMX サーバーが存在することになります。

  迅速な導入を行うにはどうすればよいですか?

  最小化と迅速なロールバックの問題を解決する方法について説明しましたが、「迅速にデプロイするにはどうすればよいか?」という疑問が残ります。

  
  
  ここでは短くて簡単です。

  • CD システム (継続的デリバリー) が必要です。それなしでは生きていけません。 サーバーが XNUMX 台ある場合は、手動で展開できます。 もちろん、約 XNUMX 台のサーバーと XNUMX 個のハンドルがあります。展開するだけでも、この部屋と同じくらいの規模の部門を設置できます。
  • デプロイは並行して行う必要があります。 デプロイメントが順次に行われる場合は、すべてが問題になります。 通常は XNUMX 台のサーバーが使用されますが、XNUMX 日中 XNUMX 台のサーバーを展開することになります。
  • 繰り返しますが、加速のために、これはおそらくもう必要ありません。 通常、展開中にプロジェクトがビルドされます。 Web プロジェクトがあり、フロントエンド部分があり (そこで Web パックを実行し、npm をコンパイルします。そのようなもの)、このプロセスは原則として短時間です (5 分ですが、この 5 分間は批判的になってください。 たとえば、私たちはそのようなことは行わず、この 5 分間を削除し、アーティファクトをデプロイするのはそのためです。

    アーティファクトとは何ですか? アーティファクトは、すべてのアセンブリ部品がすでに完成している組み立てられたビルドです。 この成果物は成果物ストレージに保管されます。 かつて、私たちはそのようなストレージを XNUMX つ使用していました - それは Nexus で、現在は jFrog Artifactory でした。 次に、PHP で書かれたアプリケーションの一部をそこに組み込みます。 「Nexus」はもはや適切ではなかったため、ほぼすべてのものをアーティファクタライズできる jFrog Artefactory を選択しました。 このアーティファクト リポジトリには、サーバー用に収集した独自のバイナリ パッケージを保存するようになりました。

  爆発的な負荷の増加

  ソフトウェアのバージョン変更についてお話しました。 次に起こるのは負荷の爆発的な増加です。 ここで私が言っているのは、おそらく負荷の爆発的な増加という意味であり、まったく正しいことではありません...

  私たちは新しいシステムを書きました。それはサービス指向で、ファッショナブルで、美しく、どこでもワーカー、どこでもキュー、どこでも非同期です。 そして、そのようなシステムでは、データはさまざまなフローを流れる可能性があります。 最初のトランザクションには 1、3、10 番目のワーカーを使用でき、2 番目のトランザクションには 4、5、XNUMX 番目のワーカーを使用できます。 そして今日、朝には最初の XNUMX つのワーカーを使用するデータ フローがあり、夕方には劇的に変化し、すべてが他の XNUMX つのワーカーを使用するとします。

  そして、ここで、ワーカーを何らかの方法でスケールし、サービスを何らかの方法でスケールし、同時にリソースの肥大化を防ぐ必要があることがわかります。

  
  
  要件を定義しました。 これらの要件は非常に単純です。サービスの検出とパラメータ化が存在することです。リソースの減価償却という XNUMX つの点を除いて、すべてがこのようなスケーラブルなシステムを構築するための標準です。 私たちは、サーバーが熱くなるほどリソースを償却する準備ができていないと言いました。 私たちは労働者を管理する「Consul」と「Nomad」を採用しました。

  なぜこれが私たちにとって問題なのでしょうか? 少し遡ってみましょう。 現在、約 70 の決済システムが稼働しています。 たとえば、午前中にトラフィックがズベルバンクを通過し、その後ズベルバンクが停止したため、別の決済システムに切り替えます。 ズベルバンク以前は 100 人の従業員がいましたが、その後は別の決済システムのために 100 人の従業員を大幅に増やす必要があります。 そして、これらすべてが人間の参加なしで起こることが望ましいです。 なぜなら、人間が参加するのであれば、そこに 24 時間 7 日座っているエンジニアがいるはずで、エンジニアはこの作業だけを行うべきです。70 台のシステムがある場合、このような障害は定期的に発生するからです。

  そこで、オープン IP を持つ Nomad に注目し、独自の Scale-Nomad - ScaleNo を作成しました。これは、ほぼ次のことを行います。キューの増加を監視し、ダイナミクスに応じてワーカーの数を増減します。キューの。 これを実行したとき、私たちは「オープンソース化できるかもしれない」と考えました。 それから彼らは彼女を見た - 彼女はXNUMXコペイカほどの単純な人でした。

  これまでのところオープンソース化はしていませんが、レポートの後、突然、そのようなものが必要であることに気づいた後、それが必要になった場合は、最後のスライドに私の連絡先が記載されていますので、私に手紙を書いてください。 3～5名様以上お集まりいただければ協賛させていただきます。

  
  
  使い方？ 見てみましょう！ 今後の展望: 左側に監視の一部があります。これは XNUMX 行で、上部はイベント処理時間、中央はトランザクション数、下部はワーカー数です。

  よく見ると、この写真には欠陥があります。 一番上のチャートでは、チャートの 45 つが 2 秒以内にクラッシュし、支払いシステムの 5 つがダウンしました。 すぐに、トラフィックが 10 分で流入し、ワーカーがいない別の決済システムでキューが増大し始めました (リソースを利用しませんでした - それどころか、リソースを正しく処分しました)。 私たちは暖房を使いたくありませんでした。従業員の数は XNUMX ～ XNUMX 人程度でしたが、対応できませんでした。

  最後のグラフは「こぶ」を示していますが、これは単に「Skaleno」がこの量を 2 倍にしたことを意味します。 そして、グラフが少し下がったときに、グラフを少し減らし、ワーカーの数が自動的に変更されました。 それがこの仕組みです。 ポイントXNUMX「理由を早く解消する方法」についてお話しました。

  監視。 問題を素早く特定するにはどうすればよいでしょうか?

  さて、最初のポイントは「問題をいかに早く特定するか」です。 監視！ 私たちは特定のことをすぐに理解する必要があります。 すぐに理解すべきことは何ですか?

  
  
  三つのこと！

  • 私たちは自分自身のリソースのパフォーマンスを迅速に理解し、理解する必要があります。
  • 私たちは障害を迅速に理解し、外部にあるシステムのパフォーマンスを監視する必要があります。
  • XNUMX 番目のポイントは、論理エラーを特定することです。 これは、システムが機能しており、すべての指標によればすべてが正常ですが、何かが間違っている場合です。

  おそらくここではそんな素晴らしいことは何も言いません。 私はキャプテン・オブビアスになります。 市場にあるものを探しました。 「楽しい動物園」があります。 現在の動物園はこんな感じです。

  
  
  Zabbix を使用してハードウェアを監視し、サーバーの主要な指標を監視します。 データベースにはOKmeterを使用しています。 最初の XNUMX つに適合しない他のすべてのインジケーターには「Grafana」と「Prometheus」を使用します。一部のインジケーターは「Grafana」と「Prometheus」を使用し、一部のインジケーターは「Grafana」と「Influx」および Telegraf を使用します。

  1,5 年前、私たちは New Relic を使用したいと考えていました。 すごいことに、何でもできます。 しかし、彼女は何でもできるので、とても高価です。 サーバーの数が 15 千台に増えたとき、あるベンダーが私たちのところに来て、「来年に向けて契約を結びましょう」と言いました。 私たちは価格を見て、「いいえ、そんなことはしません」と言いました。 現在、私たちは New Relic を放棄しており、約 XNUMX 台のサーバーが New Relic の監視下に残っています。 その価格はまったく法外なものであることが判明した。

  そして、私たち自身で実装したツールが 15 つあります。これは Debugger です。 最初はそれを「バガー」と呼んでいましたが、英語の先生が通りかかり、大笑いして「デバッガー」と名前を変更しました。 それは何ですか？ これは、システムの「ブラック ボックス」のような各コンポーネントで、実際には 30 ～ XNUMX 秒でコンポーネントの全体的なパフォーマンスのテストを実行するツールです。

  たとえば、外部ページ (支払いページ) がある場合は、それを開いてどのように表示されるかを確認するだけです。 これが処理中の場合は、テスト「トランザクション」を送信し、この「トランザクション」が到着することを確認します。 これが支払いシステムとの接続である場合は、可能な限り、それに応じてテスト リクエストを発行し、すべてが問題ないことを確認します。

  モニタリングにとって重要な指標は何ですか?

  主に何を監視するのでしょうか? 私たちにとって重要な指標は何ですか?

  
  

  • フロントの応答時間/RPSは非常に重要な指標です。 彼はすぐに、あなたに何か問題があると答えました。
  • すべてのキューで処理されたメッセージの数。
  • 従業員の数。
  • 基本的な正確さのメトリクス。

  最後のポイントは「ビジネス」、「ビジネス」の指標です。 同じことを監視したい場合は、主要な指標となる 5 つまたは 10 つのメトリクスを定義する必要があります。 私たちの指標はスループットです (これは、合計トランザクション フローに対する成功したトランザクションの数の比率です)。 15、XNUMX、XNUMX 分間隔で何かが変化する場合、それは問題があることを意味します (急激に変化する場合)。

  私たちのボードの XNUMX つの例は次のようになります。

  
  
  左側には 6 つのグラフがあり、これは線に応じて、ワーカーの数とキュー内のメッセージの数を示しています。 右側 – RPS、RTS。 以下は同じ「ビジネス」指標です。 そして、「ビジネス」メトリクスでは、中央の XNUMX つのグラフで何か問題が発生したことがすぐにわかります。これは、私たちの背後にあるシステムが停止したことにすぎません。

  私たちがしなければならない XNUMX 番目のことは、外部決済システムの衰退を監視することでした。 ここでは、分散システムをトレースできるメカニズム、標準、パラダイムである OpenTracing を取り上げました。 そして少し変わりました。 標準の OpenTracing パラダイムでは、個別のリクエストごとにトレースを構築すると言われています。 これは必要なかったので、要約、集計トレースでラップしました。 私たちは、背後にあるシステムの速度を追跡できるツールを作成しました。

  
  
  グラフは、支払いシステムの 3 つが 20 秒以内に応答を開始したことを示しています。問題が発生しています。 さらに、この問題は問題が発生すると 30 ～ XNUMX 秒間隔で反応します。

  そして、存在する監視エラーの XNUMX 番目のクラスは、論理監視です。

  正直に言うと、私たちはこのスライドに何を描けばよいのかわかりませんでした。私たちは自分たちに合ったものを長い間市場で探していたからです。 何も見つからなかったので、自分たちでやるしかありませんでした。

  
  
  論理監視とはどういう意味ですか? 想像してみてください。あなたは自分自身をシステム (たとえば、Tinder クローン) にします。 あなたがそれを作り、立ち上げました。 成功したマネージャーのヴァシャ・パプキンは、自分の携帯電話にそれを入れ、そこに女の子を見つけ、彼女を好きになりました...そして、同様のものはその女の子には送られません-同じビジネスセンターの警備員ミハリチに送られます。 管理人は階下に行き、「なぜこの警備員ミハリチは彼にとても気持ち良く微笑んでいるのだろうか？」と疑問に思いました。

  このような状況では...私たちにとって、この状況は少し違って聞こえます。なぜなら、これは間接的に経済的損失につながる評判の損失だからです。 私たちの状況はその逆です。たとえば、成功したとして取引を実行したが失敗した場合 (またはその逆)、直接的な経済的損失を被る可能性があります。 ビジネス指標を使用して、成功したトランザクションの数を経時的に追跡する独自のツールを作成する必要がありました。 市場には何も見つかりませんでした！ これはまさに私が伝えたかったアイデアです。 この種の問題を解決するものは市場には何もありません。

  これは、問題を迅速に特定する方法についてでした。

  導入の理由を判断する方法

  私たちが解決する XNUMX 番目の問題グループは、問題を特定し、それを取り除いた後、開発やテストの理由を理解し、それに対して何かを行うのが良いでしょう。 したがって、調査する必要があり、ログを収集する必要があります。

  
  
  ログについて話している場合 (主な理由はログです)、ログの大部分は ELK スタックにあり、ほぼ全員が同じものを持っています。 ELK ではない人もいるかもしれませんが、ギガバイト単位でログを書き込んでいれば、遅かれ早かれ ELK に行き着くでしょう。 それらはテラバイト単位で書き込まれます。

  
  
  ここで問題が発生しました。 私たちはそれを修正し、ユーザーのエラーを修正し、そこにあったものを掘り出し始め、Kibana に登り、そこでトランザクション ID を入力し、このようなフットクロスを取得しました (たくさん表示されています)。 そして、この足布には何も明らかではありません。 なぜ？ はい、どのパーツがどのワーカーに属し、どのパーツがどのコンポーネントに属するかが明確ではないためです。 そしてその瞬間、私たちはトレース、つまり私が話したのと同じ OpenTracing が必要であることに気づきました。

  私たちは XNUMX 年前にこれを考え、市場に注目したところ、そこには「Zipkin」と「Jaeger」という XNUMX つのツールがありました。 「イェーガー」は実際、そのような思想的後継者であり、「ジプキン」の思想的後継者である。 Zipkin ではすべてがうまくいきますが、集計方法が分からず、トレースにログを含める方法が分からず、時間トレースのみが分からない点が異なります。 そして「イェーガー」もこれを支持した。

  私たちは「Jager」を検討しました。アプリケーションをインストルメント化でき、API で記述することができます (ただし、当時の PHP の API 標準は承認されていませんでした。これは XNUMX 年前のことですが、現在はすでに承認されています)。まったくクライアントではありませんでした。 「よし」と私たちは考え、独自のクライアントを書きました。 何が得られたでしょうか？ おおよそ次のようになります。

  
  
  Jaeger では、メッセージごとにスパンが作成されます。 つまり、ユーザーがシステムを開くと、受信リクエストごとに 1 つまたは 2 つのブロックが表示されます (3-XNUMX-XNUMX - ユーザーからの受信リクエストの数、ブロック数)。 ユーザーにとって使いやすいように、ログと時間トレースにタグを追加しました。 したがって、エラーが発生した場合、アプリケーションはログに適切な Error タグを付けます。 エラー タグでフィルタリングすると、エラーのあるこのブロックを含むスパンのみが表示されます。 スパンを拡大すると次のようになります。

  
  
  スパンの内側には一連のトレースがあります。 この場合、これらは XNUMX つのテスト トレースであり、XNUMX 番目のトレースはエラーが発生したことを示しています。 同時に、ここでは時間トレースが表示されます。上部に時間スケールがあり、このログまたはそのログがどのような時間間隔で記録されたかがわかります。

  したがって、物事はうまくいきました。 私たちは独自の拡張機能を作成し、それをオープンソース化しました。 トレースを使用したり、PHP の「Jager」を使用したりする場合は、次のように拡張機能がありますので、ぜひ使用してください。

  
  
  この拡張機能があります。これは OpenTracing API のクライアントであり、php-extention として作成されています。つまり、これをアセンブルしてシステムにインストールする必要があります。 XNUMX年前と何も変わっていませんでした。 現在、コンポーネントのようなクライアントが他にもあります。 ここでの選択はあなた次第です。コンポーザーを使用してコンポーネントを作成するか、拡張機能を使用するかです。

  企業基準

  三つの戒めについて話しました。 XNUMX 番目の戒めは、アプローチを標準化することです。 これは何についてですか? それはこれについてです:

  
  
  なぜここに「企業」という言葉が入っているのでしょうか？ 私たちが大企業や官僚的な会社だからではありません。 私はここで「企業」という言葉を、あなたを含め、すべての会社、すべての製品が独自の基準を持つべきであるという文脈で使いたかったのです。 どのような基準があるのでしょうか?

  
  

  • 配備規制があります。 彼なしでは私たちはどこへも移動できません。 週に約 60 回、つまりほぼ常時デプロイを行っています。 同時に、例えば配備規制の中で金曜日の配備はタブーとしておりまして、原則として配備はしておりません。
  • 書類が必要です。 たとえそれが当社の RnD スペシャリストのペンの下で生まれたとしても、ドキュメントがなければ、新しいコンポーネントはまったく実稼働環境に入りません。 私たちは彼らに、展開手順、監視マップ、およびこのコンポーネントがどのように機能するか、トラブルシューティング方法についての大まかな説明 (プログラマが書ける程度) を要求します。
  • 私たちは問題の原因を解決するのではなく、問題を解決します - すでに述べたことです。 ユーザーを問題から守ることは私たちにとって重要です。
  • クリアランスはございます。 たとえば、2 分以内にトラフィックの XNUMX% が失われた場合は、ダウンタイムとはみなされません。 これは基本的に統計には含まれていません。 それがパーセンテージでより多くの場合、または一時的な場合は、すでにカウントされています。
  • そして私たちは常に事後分析を書きます。 私たちに何が起こっても、本番環境で誰かが異常な行動をとった状況は事後分析にも反映されます。 事後検証とは、自分に何が起こったのか、詳細なタイミング、それを修正するために何をしたか、そして（これは必須のブロックです！）今後このようなことが起こらないようにするために何をするかを書く文書です。 これは必須であり、その後の分析に必要です。

  ダウンタイムとは何ですか?

  
  
  これは一体何をもたらしたのでしょうか？

  これにより、過去 6 か月間での安定性指標は 99,97 でした (安定性に関して特定の問題があり、これはクライアントにも私たちにも適していませんでした) という事実が生じました。 これはそれほど多くないと言えます。 はい、私たちには努力すべきことがあります。 この指標のうち、約半分は、いわば、私たちの安定性ではなく、私たちの目の前にあり、サービスとして使用されている Web アプリケーション ファイアウォールの安定性ですが、クライアントはこれを気にしません。

  私たちは夜寝ることを学びました。 ついに！ 半年前にはできませんでした。 この結果に関して、2 つ注意しておきたいと思います。 昨夜、原子炉の制御システムに関する素晴らしい報告がありました。 このシステムを作成した人に私の声が聞こえるなら、「2% はダウンタイムではない」という私の言葉は忘れてください。 あなたにとって、たとえ XNUMX 分であっても XNUMX% はダウンタイムです。

  それだけです！ あなたの質問。

  
  

  バランサーとデータベースの移行について

  聴衆からの質問（以下、B）： – こんばんは。 このような管理者レポートをありがとうございます! バランサーについての短い質問です。 WAF があるとおっしゃいましたが、つまり、ある種の外部バランサーを使用していると理解しています。

  EK: – いいえ、当社のサービスはバランサーとして使用されます。 この場合、WAF は私たちにとってもっぱら DDoS 防御ツールです。

  で： – バランサーについて一言お願いします。

  EK: – すでに述べたように、これは openresty 内のサーバーのグループです。 現在、排他的に応答する 5 つの予約グループがあります。つまり、openresty のみを実行するサーバーであり、トラフィックのみをプロキシします。 したがって、私たちがどのくらいの量を保持しているかを理解するには、現在、数百メガビットの通常のトラフィック フローがあります。 彼らは対処し、気分が良く、無理をすることさえありません。

  で： ――素朴な疑問も。 こちらはBlue/Green展開です。 たとえば、データベースの移行では何をしますか?

  EK: - 良い質問！ ブルー/グリーン展開では、回線ごとに個別のキューがあります。 つまり、ワーカーからワーカーに送信されるイベント キューについて話している場合、青の線と緑の線には別個のキューが存在します。 データベース自体について話している場合、意図的に可能な限り絞り込み、実質的にすべてをキューに移動し、データベースにはトランザクションのスタックのみを保存します。 また、トランザクション スタックはすべての行で同じです。 このコンテキストのデータベースでは、コードの両方のバージョンがトランザクションで何が起こっているかを認識する必要があるため、データベースを青と緑に分割しません。

  皆さん、私もあなたたちに刺激を与えるちょっとしたご褒美を用意しています。それは本です。 そして、最優秀質問として表彰されるはずです。

  で： - こんにちは。 ご報告ありがとうございます。 質問はこれです。 あなたは支払いを監視し、通信するサービスを監視します...しかし、ある人がどういうわけか支払いページにアクセスして支払いを行い、プロジェクトがその人にお金を入金したことをどうやって監視するのでしょうか? つまり、マーチャントが対応可能であり、コールバックを受け入れたことをどのように監視するのでしょうか?

  EK: – この場合の「加盟店」とは、決済システムとまったく同じ外部サービスです。 私たちは販売者の応答速度を監視します。

  データベースの暗号化について

  で： - こんにちは。 少し関連した質問があります。 PCI DSS の機密データがあります。 転送する必要があるキューに PAN をどのように保存するのか知りたいのですが。 暗号化を使用していますか? そして、これは XNUMX 番目の質問につながります。PCI DSS によれば、変更 (管理者の解任など) があった場合にはデータベースを定期的に再暗号化する必要があります。この場合、アクセシビリティはどうなりますか?

  
  
  EK: - 素晴らしい質問ですね！ まず、PAN をキューに保存しません。 原則として、私たちには PAN をクリアな形式でどこにも保存する権利がないため、特別なサービス (「Kademon」と呼びます) を使用します。これは XNUMX つのことだけを行うサービスです。入力としてメッセージを受信し、送信します。暗号化されたメッセージを送信します。 そして、この暗号化されたメッセージとともにすべてを保存します。 したがって、キーの長さは XNUMX キロバイト未満であるため、これは深刻で信頼性があります。

  で： – 今は 2 キロバイト必要ですか?

  EK: – つい昨日まで 256 だったような気がします... さて、他にはどこがあるでしょうか?!

  したがって、これが最初です。 そして第二に、既存のソリューションは、再暗号化手順をサポートしています。3 つのペアの「keks」（キー）があり、暗号化する「デック」を提供します（キーはキーであり、デックは暗号化するキーの派生です）。 。 そして、この手順が開始されると (XNUMX か月から±数か月まで定期的に発生します)、新しい「ケーキ」のペアをダウンロードし、データを再暗号化します。 当社では、すべてのデータを削除し、新しい方法で暗号化する別のサービスを提供しています。 データは、暗号化されたキーの識別子の隣に保存されます。 したがって、新しいキーでデータを暗号化するとすぐに、古いキーは削除されます。

  場合によっては、手動で支払いを行う必要がある場合もあります...

  で： – つまり、何らかの操作に対して返金が届いた場合でも、古いキーを使用して復号化しますか?

  EK: - はい。

  で： – それでは、もう XNUMX つの小さな質問です。 何らかの障害や落下、インシデントが発生した場合、手動で取引を進める必要があります。 そのような状況があります。

  EK: - はい、時々。

  で： – このデータはどこから入手したのですか? それとも自分でこの保管施設に行きますか？

  EK: – いいえ、もちろん、サポートのためのインターフェースを含むある種のバックオフィス システムがあります。 トランザクションがどのようなステータスにあるのかがわからない場合 (たとえば、支払いシステムがタイムアウトで応答するまで)、アプリオリにわかりません。つまり、完全な自信を持ってのみ最終ステータスを割り当てます。 この場合、トランザクションを手動処理用の特別なステータスに割り当てます。 翌日の朝、サポートは、これこれのトランザクションが支払いシステムに残っているという情報を受け取るとすぐに、このインターフェイスで手動で処理します。

  
  
  で： – いくつか質問があります。 その 99,97 つは、PCI DSS ゾーンの継続です。回路をどのように記録しますか? この質問は、開発者がログに何でも書き込める可能性があるためです。 XNUMX 番目の質問: ホットフィックスはどのように展開しますか? データベース内のハンドルを使用することは XNUMX つのオプションですが、無料のホットフィックスがある場合があります。その手順は何ですか? XNUMX 番目の質問は、おそらく RTO、RPO に関連するものです。 可用性は XNUMX で、ほぼ XNUMX でした。しかし、私が理解しているところによると、XNUMX 番目のデータ センター、XNUMX 番目のデータ センター、XNUMX 番目のデータ センターがあると思います。それらの同期、複製、その他すべてをどのように行うのですか?

  EK: - 最初のものから始めましょう。 最初の質問はログに関するものでしたか? ログを書き込むとき、すべての機密データをマスクするレイヤーがあります。 彼女はマスクと追加のフィールドを確認します。 したがって、ログには、すでにマスクされたデータと PCI DSS 回路が含まれています。 これは、テスト部門に割り当てられる通常のタスクの XNUMX つです。 彼らは、開発者が何かを書き留めていないことを制御するために、書き込んだログを含む各タスクをチェックする必要があります。これは、コードレビュー中の定期的なタスクの XNUMX つです。 その後のチェックは、情報セキュリティ部門によって週に XNUMX 回程度定期的に実行されます。最終日のログが選択的に取得され、テスト サーバーから特別なスキャナー アナライザーを介してすべてがチェックされます。
  ホットフィックスについて。 これは当社の配備規制に含まれています。 ホットフィックスについては別の条項を設けています。 私たちは、必要なときにホットフィックスを XNUMX 時間体制で展開していると考えています。 バージョンが組み立てられ、実行され、成果物が得られるとすぐに、サポートからの電話でシステム管理者が常駐し、必要なときにすぐにデプロイされます。

  「フォーナイン」について。 私たちが今持っている数字はまさに達成されたものであり、私たちは別のデータセンターでそれを目指して努力しました。 現在、XNUMX 番目のデータ センターがあり、それらの間のルーティングを開始していますが、データ センター間のレプリケーションの問題は、まさに重要な問題です。 私たちはさまざまな手段を使って一度にそれを解決しようとしました。同じ「タランチュラ」を使用しようとしましたが、うまくいきませんでした。すぐにお伝えします。 そのため、最終的に「sens」を手動で注文することになりました。 実際、システム内の各アプリケーションは、データセンター間で必要な「変更完了」同期を非同期で実行します。

  で： – XNUMX本目を手に入れたのなら、なぜXNUMX本目を手に入れなかったのですか？ まだ誰もスプリットブレインを持っていないので...

  EK: – しかし、私たちにはスプリットブレインはありません。 各アプリケーションはマルチマスターによって駆動されるため、リクエストがどのセンターに送信されたかは私たちにとって重要ではありません。 データ センターの XNUMX つが故障し (これに依存しています)、ユーザーのリクエストの途中で XNUMX 番目のデータ センターに切り替わった場合、実際にこのユーザーを失う可能性があるという事実に備えています。 しかし、これらは単位、絶対単位になります。

  で： - こんばんは。 ご報告ありがとうございます。 本番環境でいくつかのテスト トランザクションを実行するデバッガについて話しました。 しかし、テストトランザクションについて教えてください。 どれくらいの深さまで行きますか？

  EK: – コンポーネント全体の全サイクルを通過します。 コンポーネントの場合、テスト トランザクションと運用トランザクションの間に違いはありません。 しかし、論理的な観点から見ると、これは単にシステム内の別個のプロジェクトであり、テスト トランザクションのみが実行されます。

  で： ―どこで切るんですか？ ここにコアが送信されました...

  EK: – この場合、私たちはテストトランザクションのために「Kor」の背後にいます...私たちはルーティングのようなものを持っています：「Kor」はどの支払いシステムに送信するかを知っています - 私たちは偽の支払いシステムに送信します、それは単にhttp信号を与え、それだけです。

  で： – 教えてください、あなたのアプリケーションは XNUMX つの巨大なモノリスで書かれていましたか、それともいくつかのサービスまたはマイクロサービスに分割されましたか?

  EK: – もちろん、モノリスはありません。サービス指向のアプリケーションがあります。 私たちのサービスはモノリスでできていると冗談を言っていますが、実際には非常に大規模です。 マイクロサービスと呼ぶのは難しいですが、分散マシンのワーカーがその中で動作するサービスです。

  サーバー上のサービスが侵害された場合...

  で： –それでは次の質問です。 たとえそれがモノリスだったとしても、あなたは、これらのインスタント サーバーが多数あると言いました。それらはすべて基本的にデータを処理します。問題は、「インスタント サーバーの XNUMX つまたはアプリケーションが侵害された場合、個々のリンクは、何らかのアクセス制御があるのでしょうか？ どちらが何ができるでしょうか？ どのような情報を得るには誰に連絡すればよいですか?

  
  
  EK: - はい、間違いなく。 セキュリティ要件は非常に厳しいものです。 まず、オープンデータの移動があり、ポートはトラフィックの移動が事前に予測されるポートのみです。 コンポーネントが 5-4-3-2 経由でデータベース (たとえば、Muskul と) 通信する場合、5-4-3-2 のみがそのコンポーネントに対してオープンになり、他のポートや他のトラフィック方向は使用できなくなります。 さらに、当社の本番環境には約 10 個の異なるセキュリティ ループがあることを理解する必要があります。 たとえアプリケーションが何らかの形で侵害されたとしても、これは別のネットワーク セキュリティ ゾーンであるため、攻撃者はサーバー管理コンソールにアクセスすることはできません。

  で： – この文脈で、私にとってより興味深いのは、サービスと特定の契約を結んでいるということです。サービスで何ができるか、どのような「アクション」を通じて相互に連絡できるか...そして、通常の流れでは、特定のサービスがいくつかのサービスを要求します。もう一方の行には「アクション」のリストが表示されます。 彼らは通常の状況では他人に頼ることはないようで、他の責任領域を抱えています。 そのうちの XNUMX つが侵害された場合、そのサービスの「動作」を中断することができるでしょうか?

  EK: - わかりました。 通常の状況で別のサーバーとの通信が許可されている場合は、「はい」です。 SLA 契約によれば、最初の 3 つの「アクション」のみが許可され、4 つの「アクション」は許可されないということは監視されません。 当社では原理的に回路に対して 4 レベルの保護システムをすでに導入しているため、これはおそらく冗長です。 私たちはインサイドのレベルではなく、輪郭で自分たちを守ることを好みます。

  Visa、MasterCard、ズベルバンクの仕組み

  で： – あるデータセンターから別のデータセンターへのユーザーの切り替えについての点を明確にしたいと思います。 私の知る限り、Visa と MasterCard は 8583 バイナリ同期プロトコルを使用して動作しており、混在しています。 そして、私が知りたかったのは、今、切り替えということは、直接「Visa」と「MasterCard」なのでしょうか、それとも支払いシステムの前、処理の前なのでしょうか？

  EK: - これはミックス前です。 私たちのミックスは同じデータセンターにあります。

  で： – ざっくり言うと、接続ポイントはXNUMXつですか？

  EK: – 「Visa」と「MasterCard」 – はい。 単純に、たとえば XNUMX 番目のミックス ペアを取得するために個別の契約を締結するには、Visa と MasterCard がインフラストラクチャにかなり多額の投資を必要とするからです。 これらは XNUMX つのデータ センター内で予約されていますが、万が一、Visa と MasterCard への接続が混在している当社のデータ センターが停止した場合、Visa と MasterCard との接続が失われることになります...

  で： – 予約はどのようにして行うことができますか? Visa では原則として XNUMX 回の接続しか許可されていないことは知っています。

  EK: – 彼らは機器を自分たちで供給します。 いずれにせよ、内部は完全に冗長化された機器を受け取りました。

  で： – スタンドはConnects Orangeのものですか？

  EK: - はい。

  で： – しかし、この場合はどうでしょうか。データセンターが消滅した場合、どうやってそれを使い続けることができるのでしょうか? それともただ交通が止まっただけでしょうか？

  EK: - いいえ。 この場合、トラフィックを別のチャネルに切り替えるだけですが、当然のことながら、私たちにとってもクライアントにとってもコストが高くなります。 ただし、トラフィックは Visa や MasterCard への直接接続を経由せず、条件付きの Sberbank を経由します (非常に大げさです)。

  ズベルバンクの従業員を気分を害した場合は、心からお詫び申し上げます。 しかし、我々の統計によると、ロシアの銀行の中でズベルバンクが最も頻繁に破綻している。 ズベルバンクで何かが落ちない月はありません。

  
  
  

  いくつかの広告 🙂

  いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

  アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com