内部製品を外部にする方法。 Yandex.Trackerチームの経験

最近、タスクとプロセスの管理システムであるYandex.Trackerを外部ユーザー向けに開きました。 Yandexは、サービスの作成だけでなく、キッチンでのCookieの購入にも使用します。

ご存知のように、会社が小さいほど、使用できるシンプルなツールは多くなります。 午前中に各従業員に個人的に挨拶できる場合、Telegramでチャットすれば十分です。 別々のチームが現れると、個人的に全員に挨拶することが不可能になるだけでなく、タスクのステータスが混乱する可能性があります。

内部Yandex.Trackerのチケットヘッダー内の単語の雲

この段階では、プロセスの透明性を維持することが重要です。すべての関係者は、いつでもタスクの作業の進捗状況を知ることができます。たとえば、作業チャットのストリームで消えないコメントを残すことができます。 小規模なチームの場合、トラッカーは会社の生活からの最新ニュースを含む一種のニュースフィードです。

本日、Habrahabrの読者に、Yandexがトラッカーを作成することを決めた理由、それを内部に配置する方法、およびそれを開くために直面​​した困難について説明します。

Yandexは現在、6000人以上を雇用しています。 その部分の多くは異なる規模のチームを持つ独立したスタートアップとして組織されているという事実にもかかわらず、次のフロアで何が起こっているのかを常に理解する必要があります-彼らの仕事はあなたのものと重なることができ、それらの改善はあなたを助け、一部のプロセスはその逆ですあなたに悪影響を及ぼす可能性があります。 このような状況では、たとえば、Slackの別のワークスペースから同僚を呼び出すことは困難です。 特に、さまざまな方向からの多くの人々にとってタスクの透明性が重要な場合。

ある時点で、有名なJiraの使用を開始しました。 これは優れたツールであり、その機能は原則として全員に適していますが、社内サービスと統合することは困難でした。 さらに、誰もが懐中電灯なしでナビゲートできる単一のスペースを必要とする数千人の規模で、Jiraは見落とされなくなりました。 また、サーバー上では機能していましたが、負荷がかかっていました。 Yandexは成長し、チケットの数も増加し、新しいバージョンへの更新にはますます時間がかかりました（最後のアップグレードには6か月かかりました）。 何かを変える必要がありました。

2011年末には、問題を解決するためのいくつかのオプションがありました。

• 古いトラッカーのパフォーマンスを向上させます。 アイデアを捨てた、なぜなら 他の人の製品のアーキテクチャを自分でやり直すのは悪いことです。 これは、少なくとも更新を終了することを意味します。
• トラッカーをいくつかの独立したコピー（インスタンス）に分割して、それぞれの負荷を減らします。 このアイデアは新しいものではなく、同様の場合に大企業で使用されています。 その結果、エンドツーエンドのレポート、フィルタリング、リンク、コピー間のタスク転送は機能しません。 これはすべて、会社にとって重要でした。
• 別のツールを入手してください。 トラッカーの可能なオプションを調べました。 それらのほとんどは容易なスケーラビリティを許可しません。つまり、インフラストラクチャの改善とその後のニーズへの変更のコストは、独自の開発のコストよりも高くなります。
• トラッカーを作成します。 危険なオプション。 それは成功の場合に最も自由と機会を与えます。 失敗した場合、重要な開発および計画ツールの1つに問題があります。 ご想像のとおり、このオプションを選択しました。 期待されるプロは、短所とリスクを上回りました。

独自のトラッカーの開発は2012年1月に始まりました。 トラッカーチーム自体が、プロジェクトの作業を開始してから数か月後に新しいサービスにタスクを転送した最初のチームです。 その後、残りのチームを移動するプロセスが始まりました。 各チームは機能に関する要件を提示し、解決し、トラッカーが新しい機能で大きくなりすぎた後、チームを移送しました。 すべてのチームの完全な移転とJiraの閉鎖には2年かかりました。

しかし、少し戻って、新しいサービス用にコンパイルされた要件のリストを見てみましょう。

• 耐障害性。 聞いたことがあるかもしれませんが 、会社はDCの1つをシャットダウンする演習を定期的に開催しています。 サービスでは、ユーザーとチームの両方が気付かないうちに、演習の開始時に手動でアクションを実行する必要なく、それらを体験する必要があります。
• スケーラビリティ。 トラッカーのタスクには制限事項がありません。 開発者または管理者は、7年前に閉じられたタスクだけでなく、今日のタスクも検討する必要があります。 これは、古いデータを削除またはアーカイブできないことを意味します。
• 社内サービスとの統合。 多くのYandexチームは、長期計画サービス、バージョン管理システム、従業員のカタログなどとの統合により、多くのサービスと緊密に連携する必要がありました。

また、要件を収集するときでさえ、トラッカーの作成に使用するテクノロジーを決定しました。

• バックエンド用のJava 7（現在はすでに8）。
• Node.js + BEMHTML +フロントエンド用のi-bem。
• メインデータウェアハウスとしてのMongoDB：自動フェールオーバー、高速、シャーディングを簡単に有効化する機能、スキーマレス（タスクのカスタムフィールドに便利）。
• 任意のフィールドによる迅速な検索と集約のためのElasticsearch。 選択には、サジェスト、パーコレーター、およびその他の弾性バンのアナライザーの柔軟な設定も役割を果たしました。
• ZooKeeper for Discoveryバックエンドサービス。 バックエンドは相互に対話して、キャッシュを無効にし、タスクを分散し、独自のメトリックを収集します。 ZooKeeperとクライアントの助けを借りて、ZooKeeperの発見を非常に簡単に整理できます。
• サービスとしてのファイルストレージ。ユーザーの添付ファイルを保存するときに、レプリケーションとバックアップの頭痛の種を取り除きます。
• 外部サービスとの通信のためのHystrix。 連鎖的な停止を防ぐために、問題が発生した場合は隣接するサービスをロードしないでください。
• httpsおよびレート制限を終了するためのNginx。 実践が示しているように、Java内でhttpsを終了することはパフォーマンスの観点からは良い考えではないため、このタスクをnginxに転送しました。 レートリミッターは、彼の側で整理することもより信頼できます。

その他のパブリックおよび内部Yandexサービスに関しては、サービスのパフォーマンスマージンとスケーラビリティの要件についても考慮する必要がありました。 状況を理解するための例。 システム設計の初期には、約100万のタスクと3000人のユーザーがいました。 現在、このサービスにはほぼ900万のタスクと6,000人を超えるユーザーがいます。

ちなみに、内部トラッカーのユーザー数はかなり多いにもかかわらず、ほとんどのリクエストは、統合されたYandexサービスのAPIを介してトラッカーに送られます。 メインロードを作成するのは彼らです：

以下では、営業日の真ん中に回答のパーセンタイルを見ることができます。

サービスの将来の負荷を定期的に評価しようとします。 1〜2年の予測を行い、 Lunaparkの助けを借りて、サービスがそれに耐えることを確認します。

このグラフは、タスク検索APIが500〜600 rps後にのみ顕著な数のエラーを出し始めることを示しています。 これにより、内部顧客からの負荷の増加とデータ量の増加を考慮して、2年で負荷に耐えることができると推定できました。

サービスの高負荷に加えて、ユーザーがこれに気付かないように処理する必要がある他の不快なストーリーが発生する可能性があります。 それらのいくつかをリストします。

1. データセンターの障害。
   
   非常に不快な状況であるにもかかわらず、運動のおかげで定期的に発生します。 これはどうなりますか？ 最悪の場合は、mongaマスターが無効なDCにあった場合です。 ただし、この場合でも、自動フェイルオーバーのため、開発者または管理者の介入は必要ありません。 弾力性では、状況はわずかに異なります。一部のデータは単一のコピーでした。 レプリケーションファクター1があります。したがって、すべてのシャードが再びバックアップされるように、生き残ったノードに新しいシャードを作成します。 一方、バックエンド上のバランサーは、無効化されたDCのインスタンスで実行された要求の接続のタイムアウト、または要求が欠落しているDCに行き戻ってこなかった作業バックエンドからのエラーを受け取ります。 状況に応じて、バランサーは要求を繰り返すか、ユーザーにエラーを返すことがあります。 しかし、最終的に、バランサーは切断されたDCからのインスタンスが彼に利用できないことを理解し、DCがとにかく動作せず、そこに負荷を戻す時が来た場合、バックグラウンドでチェックするリクエストの送信を停止します。

   
   
   
   
   
   
   

2. ネットワークの問題が原因で、バックエンドとベース/インデックス間の接続が失われました。
   
   一見シンプルな状況。 バックエンド上のバランサーは定期的にその状態をチェックするため、バックエンドがベースに到達できない状況は非常に早く現れます。 そして、バランサーは再びこのバックエンドから負荷を取り除きます。 すべてのバックエンドがデータベースとの接続を失うと、それらがすべて閉じられ、最終的にリクエストの100％に影響する危険があります。

   
   
   
   
   
   
   
3. トラッカーの検索でのクエリの負荷が高い。
   
   タスクによる検索、そのフィルタリング、ソート、および集約は、非常に労働集約的な操作です。 したがって、最も厳しい負荷制限があるのはAPIのこの部分です。 以前は、リクエストで私たちを攻撃した人を手動で見つけて、負荷を減らすように頼みました。 現在、これはますます頻繁に発生しているため、レート制限を含めることで、過度にアクティブなAPIクライアントに気付かないようにすることができました。

Yandex.Tracker-みんなのために

他の企業は私たちのサービスに何度も興味を持っていました-彼らはYandexを去った人々から私たちの内部ツールについて学びましたが、トラッカーを忘れることはできませんでした。 そして、昨年、私たちは世界に参入するためにトラッカーを準備することに決めました-他の会社のためにそれから製品を作るために。

私たちはすぐに建築に取り組み始めました。 サービスを数十万の組織に拡大するという大きな課題に直面しました。 これに先立ち、このサービスは、ニーズとニュアンスのみを考慮に入れて、当社のいずれかで長年にわたって開発されました。 現在のアーキテクチャには強力な改善が必要であることが明らかになりました。

その結果、2つのソリューションがありました。

組織ごとに個別のインスタンス	数千の組織をホストできるインスタンス
長所： すでに記述されたコードの変更の最小数 短所： 高価なリソース 複雑な監視 計算と移行の複雑さ	長所： リソースの合理的な使用 高速展開と比較的迅速な移行 簡単な監視 短所： 労働投入

明らかに、外部ユーザーに対するサービスの安定性は内部ユーザーと同じくらい重要であるため、複数のデータセンターでデータベース、検索、バックエンド、フロントエンドを複製する必要があります。 これにより、最初のオプションの保守がはるかに難しくなりました。多くの障害点が得られました。 したがって、最後のオプションとして2番目のオプションを選択しました。

プロジェクトの主要部分を書き直すのに2か月かかりました。そのような作業は記録的な時間でした。 それでも、待機しないように、専用ハードウェアでトラッカーのコピーをいくつか作成したため、フロントエンドと関連サービスとの相互作用をテストする何かがありました。

それとは別に、設計段階でも、内部と外部の両方のトラッカーに対して1つのコードベースを維持するという基本的な決定を下したことに注意する価値があります。 これにより、プロジェクト間でコードをコピーすることなく、リリースの速度を遅くしたり、内部トラッカーに表示された直後にリリースの機会を逃したりすることがなくなります。

しかし、結局のところ、すべてのアプリケーションメソッドに別のパラメーターを追加するだけでは不十分であり、次の問題も発生しました。

1. ゴムでないモンガとエラスティック。 データを1つのインスタンスに入れることは不可能であり、弾性は多数のインデックスにとって悪いものであり、mongaはすべての組織に対応できませんでした。 そのため、バックエンドはいくつかの大きなインスタンスに分割され、それぞれが割り当てられた組織にサービスを提供できます。 各インスタンスはフォールトトレラントです。 同時に、組織をそれらの間でドラッグすることもできます。
2. 組織ごとにcronタスクを実行する必要。 ここでは、各タスクの問題を個別に解決する必要がありました。 どこかでプルデータをプッシュに置き換えました。 どこかで、1つのcronタスクが組織ごとに個別のタスクを生成しました。
3. 各組織の異なるタスクフィールドのセット。 それらを操作するための最適化が利用できるため、それらのために個別のキャッシュを作成する必要がありました。
4. インデックスマッピングの更新。 トラッカーが新しいバージョンに更新されたときに発生するかなり一般的な操作。 マッピングの増分更新のメカニズムが追加されました。
5. 外部ユーザーに対してAPIを開きます。 レートリミッターを追加し、サービスAPIへのアクセスをブロックする必要がありました。
6. まれな活動のサポートサービスを提供しています。 当社のサポートおよび開発者は、組織のユーザーデータを参照する権利がありません。つまり、すべてのアクションは会社の管理者が実行する必要があります。 インターフェースに多数の管理パネルを追加しました。

別のポイントはパフォーマンス評価です。 多くの変更があったため、作業の速度、インスタンスに適合する組織の数、およびサポートされているrpを評価する必要がありました。 そのため、以前にテストトラッカーで多数の組織にデータを入力した後、定期的な発砲を行いました。 結果に基づいて、負荷境界を決定しました。その後、新しい組織を新しいインスタンスに配置する必要があります。

トラッカーの別の特別な専用インスタンスを作成して、 デモバージョンを配置しました。 それに入るには、Yandexにアカウントを持っているだけで十分です。 一部の機能はブロックされています（たとえば、ファイルのダウンロードなど）が、トラッカーの実際のインターフェイスに慣れることができます。