ストライプのディスカバリーサービス

毎年、非常に多くの新しいテクノロジー（ KubernetesやHabitatなど ）があり、産業用システムを静かにそして静かにサポートするツールを忘れがちです。 Stripeで数年間使用してきたツールの1つがConsulです。 Consulは、サービスの検出に役立ちます（つまり、数千の異なるサービスが実行されている数千のサーバーを検索し、使用可能なサーバーを特定するのに役立ちます）。 この効果的で実用的なアーキテクチャソリューションは、まったく新しいものではなく、特に注目に値するものではありませんでしたが、世界中のユーザーに信頼性の高いサービスを提供するという目的を忠実に果たしています。

この記事では、次のことについて説明します。

• サービス発見と領事とは何ですか。
• 重要なソフトウェア製品を実装する際に発生したリスクをどのように管理したか。
• 私たちが直面する課題と、これらの課題への対応。

どういうわけか魔法のように機能し、すべての問題を解決することを期待して、新しいソフトウェアを取得してインストールすることはできないことはよく知られています。 新しいソフトウェアの使用はプロセスです。 また、この記事では、産業運用で新しいソフトウェアを使用するプロセスがどのように私たちにとって有益であったかについての例を説明します。

サービス検出とは何ですか？

いい質問です！ ストライプロードバランサーを想像してください。 支払いのリクエストを受け取ります。これはAPIサーバーにリダイレクトする必要があります。 ノースAPI

数千のサーバーがさまざまなサービスを実行しています。 これらのうち、APIサーバーはどれですか？ APIサービスはどのポートで実行されていますか？ Amazon Web Servicesの「素晴らしい」機能の1つは、インスタンスがいつでも失敗する可能性があることです。そのため、準備が必要です。

• APIサーバーを失います。
• 追加の容量が必要な場合は、新しいサーバーを流通に追加します。

ネットワークサービスの可用性ステータスの変化の追跡は、サービス検出と呼ばれます。 これを行うには、 HashiCorpによって開発されたConsulというツールを使用します。

インスタンスがいつでも失敗する可能性があるという事実は、インフラストラクチャが常に実行され、定期的にインスタンスを失い、そのような状況を自動的に解決するため、実際に非常に役立ちます。 したがって、予期しない状況が発生しても、悪いことは何も起こりません。 これは一般的なことです、ルーチンです。 さらに、障害が頻繁に発生する場合、障害を正しく解決するのがはるかに簡単です。

領事の紹介

Consulは、サービスが他のサービスを登録および検索できるようにするサービス検出ツールです。 Consulは特別なクライアントを使用して、実行中のサービスに関する情報をデータベースに書き込みますが、他のクライアントソフトウェアはこのデータベースを使用します。 ここには多くのコンポーネントがあります-何か手を加える必要があります。

Consulの最も重要な部分はデータベースです。 「 api-serviceは IP 10.99.99.99、ポート12345で実行されています。利用可能です。」などのエントリが含まれています。

個々の車が領事に言う：「こんにちは！ ポート12345でAPIサービスを実行しています！ 私は生きている！」

その後、APIサービスにアクセスする必要がある場合、Consulに「どのapiサービスが利用可能ですか？」と尋ねることができます。これに応じて、対応するIPアドレスとポートのリストが返されます。

Consul自体も分散システムです（Consulを含め、いつでもマシンを失う可能性があることに注意してください）。したがって、データベースを同期状態に保つために、ConsulはRaftと呼ばれるコンセンサスアルゴリズムを使用します。

Consul でのコンセンサス構築については、 こちらをご覧ください 。

ストライプの領事：はじめに

最初の段階では、Consulクライアントが搭載されたマシンがサーバーへの可用性に関するレポートを作成する構成に限定しました。 この情報は、サービスの検出には使用されませんでした。 このようなシステムをセットアップするために、 Puppet構成を作成しましたが、それほど難しくないことがわかりました！

そのため、Consulクライアントの潜在的な問題を特定し、数千台のマシンで使用する経験を積むことができました。 初期段階では、Consulを使用してサービスを発見しませんでした。

ここで何が間違っていたのでしょうか？

メモリリーク

インフラストラクチャのすべてのマシンに何らかのソフトウェアを配置すると、間違いなく問題が発生する可能性があります。 ほぼすぐに、Consul統計ライブラリでメモリリークが発生しました。 マシンの1つが100 MBを超えるRAMを占有し、消費量が増加していることに気付きました。 欠点はConsulの間違いであり、 修正しました 。

100 MBは小さなリークですが、急速に増加しています。 一般に、メモリリークは深刻な危険をもたらします。メモリリークが原因で、実行中のマシンを完全に麻痺させることができるプロセスは1つだけだからです。

とても良いので、最初からConsulを使用してサービスを発見しませんでした！ メモリ消費を監視しながら、最初にConsulを複数のバトルサーバーで動作させたことにより、深刻な問題を回避し、ほとんど痛みを伴わずに見つかったエラーを排除することができました。

Service Discoveryの開始

サーバーでConsulを実行しても問題はないと確信しているため、Consulをポーリングするクライアントを追加し始めました。 リスクを軽減するために、次のことを行いました。

• 最初は、限られた範囲でConsulを使用し始めました。
• Consulの停止中も機能し続けるためにバックアップシステムを保存しました。

発生したいくつかの問題を以下に示します。 ここでは、Consulについて文句を言うつもりはありませんが、新しいテクノロジーを使用するときは、システムをゆっくりと展開し、注意することが非常に重要であることを強調したいと思います。

膨大な数のスイッチRaft。 Consulはコンセンサスプロトコルを使用していることを覚えていますか？ Consulクラスター内の1つのサーバーからすべてのデータをそのクラスター内の他のサーバーにコピーします。 プライマリサーバーには多くの入力/出力の問題がありました。ディスクは十分に高速ではなく、Consulのすべての要望を満たす時間がないため、プライマリサーバー全体がフリーズしました。 Raft氏は、「ああ、プライマリサーバーは再び利用できません！」、新しいプライマリサーバーを選択すると、この悪循環が繰り返されました。 Consulは新しいプライマリサーバーの選択に忙しかったが、データベースの書き込みと読み取りをブロックしました（一貫性のある読み取りがデフォルトで設定されているため）。

バージョン0.3では、SSLは完全に壊れていました。 ノード間でデータを安全に交換するために、Consul SSL機能（技術的にはTLS）を使用しましたが、これは次のリリースで正常に壊れました。 修正しました。 これはこの種の問題の例であり、検出するのは難しくなく、恐れるべきではありません（QAサイクルでは、SSLが壊れていて、単に新しいリリースに切り替えなかったことに気付きました）が、開発の初期段階にあるソフトウェアでは非常に一般的です。

リークルーチン。 Consulリーダー選挙の使用を開始しました。Goroutineリークが発生したため、Consulは使用可能なメモリをすべて使い果たしました。 Consulチームの人々がこの問題の解決に大いに助けてくれたので、いくつかのメモリリーク（既に見つかったものではなく、すでに他のもの）をクリーンアップしました。

すべての問題が修正されたとき、私たちはすでにはるかに良い位置にいました。 「最初のConsulのお客様」から「すべての生産上の問題を修正した」までの道のりは、バックグラウンドの作業サイクルを完了するのに1年弱かかりました。

利用可能なサービスを発見するためのConsulのスケーリング

そのため、Consulでいくつかのエラーを見つけて修正しました。 すべてがずっと良くなり始めました。 しかし、最初に話したどのステップを覚えていますか？ Consulに尋ねる場所：「ねえ、どのような種類のマシンがapi-serviceで利用できますか？」そのようなリクエストには定期的に問題がありました。Consulサーバーの応答が遅いか、まったく応答しませんでした。

これは主に、ラフトの切り替え中または不安定な期間に発生しました。 Consulは厳密に一貫性のあるストレージを使用するため、その可用性は、そのような制限のないシステムの可用性よりも常に劣ります。 私たちにとって、最初は特に困難でした。

私たちはまだ切り替えていたので、Consulの仕事の中断は私たちにとって非常に苦痛になりました。 このような状況では、ハードコーディングされたDNS名のセット（たとえば、「apibox1」）に切り替えました。 最初にConsulを展開したとき、このアプローチはうまく機能しましたが、スケーリングと拡張に伴い、次第に実行可能性が低下しました。

領事のテンプレート

Consulから（HTTP APIを介して）サービスの可用性に関する情報を受け取ることに頼ることはできませんでした。 しかし、他のすべてにおいて、彼は私たちに完全に合っていました！

APIを介さずに利用可能なサービスに関する情報をConsulから受け取りたいと考えました。 しかし、それを行う方法は？

OK、Consulは名前（例： monkey-srv ）を取り、1つ以上のIPアドレスに変換します（「これはmonkey-srvが存在する場所」）。 入力で名前を取得し、IPアドレスを返す他の人を知っていますか？ DNSサーバー！ 一般的に、ConsulをDNSサーバーに置き換えました。 方法は次のとおりです。Consul Templateは、Consulデータベースに基づいて静的構成ファイルを生成するGoプログラムです。

Consulテンプレートを使用して、ConsulサービスのDNSレコードを生成し始めました。 monkey-srvがIP 10.99.99.99で実行されていた場合、DNSレコードを生成しました。

monkey-srv.service.consul IN A 10.99.99.99
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードは次のようになります。 また、ここでは、 Consul Templateの実際の構成を見つけることができますが 、これはもう少し複雑です。

 {{range service $service.Name}} {{$service.Name}}.service.consul. IN A {{.Address}} {{end}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「待って、DNSレコードにはIPアドレスしかありませんが、ポートも必要です！」と言う場合、あなたは絶対に正しいでしょう！ DNS Aレコード（最も一般的に見られるタイプ）には、IPアドレスのみが含まれています。 ただし、DNS SRVレコードにはポートを含めることもできるため、ConsulテンプレートはSRVレコードを生成します。

Consulテンプレートをcronで60秒ごとに実行します。 Consulテンプレートには、デフォルトの「監視」モードもあります。このモードでは、データベースに新しい情報が到着すると、構成ファイルが常に更新されます。 最初に追跡モードをオンにしたとき、彼はConsulサーバーに過剰な数のリクエストを送信したため、拒否することにしました。

したがって、Consulサーバーは使用できませんが、内部DNSサーバーには必要なすべてのレコードがあります！ おそらく新鮮ではないかもしれませんが、それは大丈夫です。 DNSサーバーには1つの優れた機能があります。それは、新しい大規模な分散メガシステムではなく、その比較的単純な機能により、突然の故障が起こりにくくなります。 つまり、nslookup monkey-srv.service.consulを実行し 、IPを取得して、最終的にAPIサービスの使用を開始できます。

DNSは分割不可能な、最終的に一貫したシステムであるため、キャッシュと複製を何度も行うことができます（5つの標準DNSサーバーがあり、各DNSサーバーにはローカルDNSキャッシュと他の5つの標準サーバーに関する情報があります）。 したがって、バックアップDNSシステムは、定義上、Consulよりもはるかに信頼性が高くなっています。

ロードバランサーを追加してステータスチェックを高速化する

私たちは、Consulからのデータに基づいて60秒ごとにDNSレコードを更新することについて話しました。 では、APIサーバーを失うとどうなりますか？ DNSが更新されるまで約45秒間、このIPにリクエストを送信し続けますか？ いや！ この物語にはもう1人のヒーロー、 HAProxyがいます。

HAProxyはロードバランサーです。 適切なチェックを設定すると、リクエストの転送先のサービスのステータスを監視できます。 事実上のAPIリクエストはすべてHAProxyを経由します。 仕組みは次のとおりです。

• Consulテンプレートは、60秒ごとにHAProxy構成ファイルを上書きします。
• したがって、HAProxyには常に、使用可能な内部サーバーのほぼ正しいリストがあります。
• マシンがオフラインになると、HAProxyはそれについて十分に迅速に学習します（2秒ごとにチェックを実行します）。

60秒ごとにHAProxyを再起動することがわかりました。 しかし、これは同時に切断しているということですか？ いや 再起動中に接続がリセットされないように、HAProxyグレースフルリスタート機能を使用します 。 同時に、一定量のネットワークトラフィックが失われるリスクもあります（ この記事によると ）が、トラフィックはそれほど大きくないのでこれが問題になります。

サービスのステータスをチェックするために標準のエンドポイントを使用します。 ほとんどすべてのサービスにはエンドポイント/ヘルスチェックがあり、すべてが正常に機能している場合は200を返し、何か問題が発生した場合はエラーを返します。 標準を持つことは非常に重要です。HAProxyでサービスステータスチェックを簡単に構成できるからです。

Consulが落ちた場合、HAProxyの構成はやや無関係ですが、非常に機能的です。

一貫性を可用性に変更する

ストーリーを注意深く読んでいると、開始したシステム（厳密に一貫したデータベースで、すべての更新が保証されている）が、到着したシステム（しばらく遅れる可能性のあるDNSサーバー）とは非常に異なることに気づいたかもしれません1分に達するまで）。 Consulの作業の中断は、サービスを検出する能力に実質的に影響しないため、一貫性の拒否により、より応答性の高いシステムを作成できました。

有用な教訓はこれから学ぶことができます：一貫性には代償が伴います！ 可用性の高いシステムに料金を支払う準備をする必要があります。 また、厳密な一貫性を使用する場合は、必要なことを確認することが重要です。

リクエストを作成するとどうなりますか

この記事では、すでに多くのことを話していたので、どのように機能するかを理解したので、要求が進む経路を見てみましょう。

https://stripe.com/をリクエストするとどうなりますか？ このリクエストはどのようにして適切なサーバーに届きますか？ 以下に、簡単な説明を示します。

1. まず、リクエストはHAProxyが実行されているパブリックロードバランサーの1つに届きます。
2. Consulテンプレートは、stripe.comにサービスを提供するサーバーのリストを構成ファイル/etc/haproxy.confにすでに書き込んでいます。
3. HAProxyは、60秒ごとに構成を再読み込みします。
4. HAProxyはリクエストをstripe.comに転送し、利用可能であることを確認します。

実際には、プロセスはそれほど単純ではありません（追加の層があり、PCI標準に準拠するシステムがあるため、Stripe APIリクエストはより複雑です）が、実装はこの記事で説明されているアイデアに従って実行されます。

つまり、サーバーを追加または削除すると、ConsulはHAProxy構成ファイルを自動的に更新します。 手は何もする必要はありません。

1年以上の平和な生活

改善したいサービスを発見するためのアプローチにはまだ多くのことがあります。 これを行うには、何よりも積極的な開発が必要であり、計画インフラストラクチャとクエリルーティングインフラストラクチャの統合の問題をエレガントに解決する機会があります。

しかし、単純な解決策がしばしば最も正しいと判明するという結論に達しました。 この記事に記載されているシステムは、1年以上も問題なく確実にサービスを提供してきました。 Stripeは、処理されたリクエストの数の点でTwitterやFacebookから非常に遠いという事実にもかかわらず、最大限の信頼性を達成しようとします。 最も有利なソリューションは革新的ではなく、安定した優れたソリューションであることがあります。