Yandex.Mailインフラストラクチャが13年間でどのように成長したか

21世紀の20年で、メールは人と人とのやり取りだけではありません。 ユーザーは、メールが日々のタスクの解決、時間の節約、不足している情報の提案に役立つことを期待しています。 Yandex.Mailには、ユーザーの生活を少し楽にする新しいタッチを常に追加しています。 本日は、Yandex.Mailが13年で行ってきた道をあなたと一緒にやり直し、サービスのアーキテクチャとインフラストラクチャの開発に特に注意を払いたいと思います。







Yandex.Mailの最初のバージョンがPHPで作成され、文字がメタ情報の隣のリレーショナルデータベースに直接保存されたことを覚えている人はほとんどいません。 それほど遠くない2000年では、メールサービス全体が1ダースのサーバーに収まりました。 サーバー自体は完全に手動モードで保守されました。ディスク構成からオペレーティングシステムのインストールまで、自動化は行われませんでした。

2002年

放棄しなければならなかった最初のものはPHP言語でした。 当時は、開発を支援するよりも頻繁に干渉していました。







周りには一流のPerl専門家がたくさんいて、Perl自体のライブラリはすでに膨大な数になっており、 Apache + Perlを使用してメールを書き直しました。 速くて簡単になりました。

2005年

もう少し時間が経ち、既存のApacheマルチプロセスモデルは負荷に対処しなくなりました。 別の問題がPerlインタープリターとメタ情報リポジトリへの接続の機能によって作成されました。 その結果、Apache 2のベータ版を含む一連の実験の後、Baidaと呼ばれる独自のモジュラーアプリケーションサーバーを作成しました。 スレッドとイベントループ要求処理モデルの両方を使用でき、言語インタープリター（JSなど）を含む拡張機能を接続するのに非常に便利です。 サーバーは、ほとんどのYandex.Mailコードと同様に、C ++で記述されています。 多くの点で、これはネットワーク交換およびスレッド処理用のライブラリであり、増加する負荷でサービスが動作することを保証するために必要でした。



操作を容易にするために、ステータスのリアルタイム監視がこのサーバーに組み込まれています。 さらに、Perlを完全に放棄しました。 代わりに、別のBaidaモジュールが作成されました-Web Mail Interfaceには、XScriptインタープリター（XMLパーサーとXSLT変換エンジン）が含まれています 。 別の機能は、リレーショナルメタストレージへの接続のプールと、このプールの効率的な管理です。

2006年

大量のデータを含むリレーショナルリポジトリにメッセージ本文を保存しても機能しないことが明らかになりました。 そのため、Mulcaと呼ばれる特殊なレターリポジトリの注文がありました。 このテクノロジーは、8年間の開発でそれほど多くのアーキテクチャの変更を受けていませんが、ストレージのサイズは何倍にも成長しています。 現在、メールを除き、Yandex.Diskにファイルを保存するために使用されます。



個別のストレージの発売以来、サーバー上のディスクサブシステムの構成を実験しました。異なるRAIDレベルを試し、デバイスを大きなパーティションに結合しました。 RAID5構成は最も長く続きましたが、対処する必要がある欠陥がありました。RAID5では、チェックサムの計算と、書き換えられたときのブロックの再読み取りが必要であり、書き込み速度が低下しました。 アレイを再構築する必要がある場合、そのパフォーマンスも長時間低下します。







その後、 SCSIではなくSATAドライブの実験を開始しました。 RAID5を使用しない場合、SATAディスクは、構成でRAID5に組み込まれたSCSIとほぼ同じデータアクセス速度を提供します。 構成を最適化するか、フォールトトレランスを確保する独自のソリューションを考案する必要がありました。

2007年

MulcaのRAIDアレイを完全に放棄し、別のサーバーのディスクサブシステムではなく、ストレージレベルでフォールトトレランスを提供することにしました。 しばらくして、小容量の高性能SCSIディスクを大容量のSATAディスクに置き換えました。 個別のファイルシステムへの移行とディスクレベルでの冗長性の拒否により、リソースをローカルで適切に節約できました。 SATAへの移行に伴い、新しいストレージボリュームの試運転が大幅に加速しました。 ディスクに障害が発生した場合、別のデータセンターの2番目のコピーからデータをコピーしました。 同時に、有名な郵便の壁が最初に登場しました。







このダッシュボードの開発は、システム管理者によって開始され、運用、開発、およびマネージャーによる状況の認識をまとめるのに役立ちました。 最も重要な数字を特定し、目立つ場所に掛けて、製品に関係するすべての人がそれがどのように感じられるかを確認できるようにしました。 ところで、壁の外観は長年にわたってあまり変化していません。 Yandex全体のこの壁から、重要な情報を備えた吊りパネルとプロジェクターの伝統はなくなりました。



従来のPOP3は時間とともに進化しました。Baidaモジュールから、独立したデーモンに変わり、メタリポジトリのレプリカからデータを読み取ることを学びました。 ほぼ同時期に、IMAPが必要であることが明らかになり、POP3の開発で得た経験を使用して、IMAPをゼロから作成し始めました。 IMAPの現在のバージョンは4番目の行であり、そこで停止する予定はありません。



zMailer SMTPサーバーはメールの配信に使用され、その制限を感じ始めました：アーキテクチャでは、着信接続ごとに新しいプロセスを作成し、キューが大きくなると非常に急速に劣化するため、着信接続をうまく受け入れませんでした。 パッチを適用しましたが、これは問題の解決にはあまり役立ちませんでした。 別のテクノロジーが必要であることが明らかになりました。 多くの議論の後、私たちはPostfixに切り替えることにしました。それは大きなキューでより良く動作します。 もちろん、配信エージェントをPostfixからリポジトリに書き換える必要がありました。

2008年

私たちは、手紙の配達速度を​​確保するという任務を自ら設定しました。 当時、手紙は平均して数秒で配達され、そのような配達時間は良いと考えられていました。 しかし、メールはインスタントメッセージングシステムと同等の速度である必要がありました。



まず、新しい配信エージェントFastsrvを作成し、最初にzMailerに組み込み、次にPostfixに組み込みました。 Fastsrvには実質的にキューがなく、メタデータベースへの常時接続が維持されます。 メール受信クラスターにインストールされました。 受信した手紙をユーザーの受信ボックスにすぐに入れようとしました。うまくいかなかった場合にのみ、配信キューに入れました。 そのため、ほとんどの手紙はほとんどすぐに配達され始めました。 チャート上の通常の写真からの配信キューは問題の象徴になり、監視に反映しました。



さらに、レターを送受信するためのキューを分割しました。これにより、1つのパーツに問題が発生した場合に、サービスパーツを機能させ続けることができます。



次に、Postfixをメールに置き換えます。 独自のSMTPサーバーNwSMTPを呼び出しました 。 これは、無制限の数の接続を処理できるイベントベースのサーバーとして考案されました。 有名なNGINX Webサーバーも同様に配置されていますが、当時はSMTPプロキシをサポートしていませんでした。 それで私たちはほとんどすぐに手紙を受け取り始めました。 NwSMTPの開発は非常に興味深いものでした。ロールアウトは非常に頻繁に発生し、時には1時間あたりのバージョンに応じて行われました。 新しいバージョンを組み立てた直後に、1つの生産マシンに展開され、何が起こっているのかを監視しました。 このような効率により、製品を非常に迅速にリリースできました。 NwSMTPという名前はここから来たもので、Next Week SMTPの略語です。ほとんどのタスクは7日間で完全な開発サイクルを経て、サーバー開発チームは「いつこれを行うのですか」という質問に答えます。



2008年半ば、Jabberサーバーを立ち上げたときに、実験として新しい手紙のリアルタイム通知を行いました。 ステージングシステムの速度を低下させないために、通知はUDPプロトコルに従って機能し、内部にはXMPPパッケージへの変換に便利なXMLデータが含まれていました。 今日、「XML over UDP」に関するジョークは笑顔を引き起こしますが、大きな制限といくつかの通知の損失はありましたが、当時はうまくいきました。

2009年

この時点で、Yandex.Mailでいくつかのインターフェイスが同時に機能していました。 Neoはインタラクティブではありませんでした。HTMLページはWMI内で生成されました。 Modernにはインタラクティブが含まれていましたが、同じアーキテクチャで構築されました。







私たちは、最も必要なものだけをロードするインターフェースを考え出すことにしました-今何が変わったのか。 一連の実験の後、プラットフォームを準備し、そのようなサービスが機能することを証明しました。 だから、Dariaインターフェースが生まれました。それは今メールで見ることができます。







ダイナミクスへの移行により、リクエストの構造は大きく変わりました。 このときまでに、nginxサーバーは十分に開発されていたので、Baidaの前に配置して、メールの統計情報を返すことにしました（このときまでに、たとえばPeopleで既に使用されていました）。 Dariaとともに、サーバー側でインタープリター言語を実行する実験を行いました。 クライアントとサーバーで同じプログラミング言語が使用されているため、主に利便性のためにJavascriptを停止しました。 Baidaサーバーの下で、彼らはTraceMonkeyでモジュールを作成しましたが、残念ながらV8を統合することは不可能でした。 すでに人気がありましたが、当時のV8はスレッドプログラミングモデルで動作しませんでした（V8の最新バージョンでは、この欠陥は修正されました）。



Nginxを使用すると、さまざまなURLをさまざまな方法で処理できます。また、ロジック自体、添付ファイルの配布を分割し、古いインターフェイスを削除してクラスターを分離しました。 これにより、更新と操作の展開が大幅に簡素化され、システム全体を個別のコンポーネントに分解することもできました。 作業メールの主な方法はセカンダリから独立し、システム全体がより安定しました。



今年はスレッドを作成しましたが、もちろんスレッドはデータベースの構造と負荷に大きな影響を与えました。



従来、メールボックスのサイズには制限があり、Yandex.Mailも例外ではありませんでした。 しかし、この制限を解除する時が来たと判断しました。 この決定により、規制が変更されました。 以前にストレージの負荷とサイズを計算できた場合、無限ボックスではすべてが少し複雑になります。 格納する必要があるデータの量をいつでも言うことはできませんでした。 現時点では、1日あたり約1テラバイトのデータを追加しました。 比較のために、今日は1日あたり120 TBを節約します。

ドキュメントビューアーに関する別のストーリー

どういうわけか、ドキュメント表示サービスの人気を確認したいと思いました。 Pythonでプロトタイプを非常に迅速に開発し、ドキュメントをHTMLに変換するOpenOfficeファームを作成することができました。 彼らは、バーストに対する保護のためにサービスの前にnginxを置き、ドキュメントのリポジトリにアクセスするためのモジュールを追加し、それを動作させました。 この形式では、プロトタイプは数年間続き、監視、最適化、および二次的な機能で大きくなりました。 現在、ビューアの2番目のバージョンが動作していますが、ほぼ同じ技術で動作します。

2010年

今年は、メールによる検索を完全にやり直しました。 その時点で存在していた実装は、作業の速度と検索結果の品質の両方で私たちに適合しませんでした。 検索処理の結果、文字の実際の検索が機能し、1日あたり数千万件のリクエストに対応するだけでなく、その他のYandex.Mail関数も使用するシステムが作成されました。



メールサービスを自分のドメインに接続できるようにするために、ますます求められています。 そこで、ドメイン用のメールサービスが登場しました。 最小限の変更で既存のコンポーネントに基づいて開発および起動されたという事実は注目に値します。 これは、さまざまな場所から断片的に情報を収集する完全統合サービスであるため、ドメイン管理者に表示できます。



その後、2010年に、社内のYandexの通信（同僚が多くの手紙を書いている）をYandex.Mailテクノロジーに翻訳するという素晴らしい仕事をしました。 ドメインのメールとほぼ同じように機能しますが、会社の他の内部サービスと統合されています。 ほとんどすべての新しい機能は、最初に企業メールでテストされ、機能がデバッグされ、洗練され、その後すべてのユーザーが使用できるようになります。

2011年

HTTPSを使用して送信データを保護するようユーザーに積極的に提供し始め、デフォルトでメールによる安全な作業を有効にしました。 このソリューションは、一方ではYandex.Mailでの作業をより安全にし、もう一方では接続パラメーターの設定に取り組む必要がありました。 従来のメールは、キープアライブ値が大きい長いHTTPS接続で機能します。 ただし、スマートフォンでは、この接続モードが制限されたり、奇妙な動作をすることがよくあります。 HTTPS接続では、ハンドシェイクに追加のオーバーヘッドが発生します。ブラウザーが接続を開いたままにしたくない場合、または開いたままにできない場合は、各リクエストに追加のコストがかかります。 狭いチャネルと弱い電話プロセッサでは、この時間が顕著になります。 デフォルトでHTTPSを有効にした直後に、メールインターフェースの読み込み時間グラフがどのように成長するかを確認し、理由を見つけて問題を解決するのに時間がかかりました。 別の問題は、HTTPSを介したメッセージのHTTPコンテンツの表示、たとえば、タグを介して追加された画像でした。 画像をキャッシュし、HTTPS経由で送信できる別のサービスを構築しました。その後、レターに挿入された画像をプロキシのリンクに置き換えました。 そのようなサービスを設計するとき、オープンリダイレクトの出現を防ぐことが重要です。信頼できるホストからURLを開く機能、および保護レベルを追加しても、パフォーマンスが著しく低下することはありません。 このタスクに対処しました。



その後、非リレーショナルデータウェアハウスを使用した最初の実験が始まりました。 NoSQL（ MongoDB ）に翻訳された最初のサービスはアドレス帳でした。 この時点まで、メールの操作には、外部の非リレーショナルストレージテクノロジーとの戦闘経験がありませんでした。 この実験は成功しました-アドレス帳はまだ連絡帳をMongoDBに保存しています。



一方、Yandexはトルコでの打ち上げの準備を進めていました。 サービスの場合、これはローカライズの必須サポートを意味し、インターフェースの翻訳は作業のほんの一部です。 実際、同じコードベースで別の製品（Turkish Yandex.Mail）を準備して発売しました。 それらは機能が多少異なりますが、開発中に覚えておく必要があります。 アクセスを高速化するために、静的コンテンツを配信するサーバーをヨーロッパにインストールしたため、ネットワークはさらに分岐されました。



開発プロセスに変更が加えられました。 上記のWeb Mail Interfaceは、スクラムとアジャイル開発テクノロジーの使用を開始しました。 新しい機能の継続的な計算のサイクルを実装することができました。各機能または欠陥修正は個別にレイアウトされますが、同時に完全な生産サイクルが通過します。サーバー、そしてクラスター全体に。 このプロセスにより、新製品の要件の出現に非常に迅速に対応し、欠陥を排除できます。

私たちの日々

Yandex.Diskの発売により、機器の動作プロトコルが大幅に変更されました。 ドライブは、メールと同様に、Mulcaを使用してユーザーファイルを保存しますが、同時に、ダウンロードされた情報の量はメールを数回超えます。 毎月、少なくとも5つのサーバーラックをMulcaに追加して、手紙やファイルを確実に保管できるようにします。 コアネットワークとDC内部のネットワークの帯域幅要件も比例して増加しています。 データ量は、長期的にはラックの設置計画から新しいデータセンターの開設計画に移行したほどです。



メールボックスを復活させるために、オープンソースからユーザーのアバターを収集して表示するEvaテクノロジーを開発および開始しました。 すべてのアバターは、他の開発に基づいた特別なストレージにスケーリング、トリミング、キャッシュされます-Elliptics -GPLライセンスの下で配布されるフォールトトレラントな分散キーバリューストレージ。



手紙に記載されている組織のカードは、製品の問題に対する迅速な解決策の別の例です。 企業に関する情報は、2週間に1回程度頻繁に更新されません。 残りの時間は単なる静的な出力であり、これらの組織の数は少なく、ほんの数万人です。 カードの表示の問題を解決するために、キャッシュされた静的htmlファイルを使用することにしました。これは、組織のドメインに代わってハッシュで利用できます。 タスクは迅速に解決され、高いパフォーマンスとフォールトトレランスを提供しました。



テクノロジー「マーカー」により、特定のタイプの文字から有用な情報を自動的に選択することが可能になりました。 たとえば、この技術では、航空券から情報を抽出し、レターからイベントを抽出します。 このサービスの背後には、多くのメンテナンス作業があり、毎日約100台のサーバーと数千万のリクエストがあります。







一方、インターネット上で大きな変化が起きています。 IPv4アドレス空間が終わり、2012年6月6日はIPv6 Dayと見なされます 。 このイベントのために、IPv6ネットワークで動作する内部アーキテクチャを準備しました。 現在、IPv6はmail.yandex.comドメインおよびメールの送信で機能します。 すべてのコンポーネントおよびすべてのドメインでIPv6の完全なサポートに積極的に取り組んでいます。



長い間私たちに適していたXScriptは、メールの仕事から完全に除外されました。 メールは、短いAPI呼び出しを介してバックエンドと通信する静的なWebアプリケーションになりました。 呼び出しはまだBaidaのWMIサーバーによって内部的に処理され、そのモジュールの1つを介してブロードキャストされます。



メールコレクターは、IMAPを使用してメールを収集する方法を学びました。 IMAPは、はるかに有用な情報を送信します。つまり、メール収集プロセスがはるかに効率的になりました。



私たちの大小さまざまな過去、既存、未来の各テクノロジーの背後には、システム管理者、開発者、管理者という真のプロフェッショナルエンジニアがいます。 まだ誰も解決していないタスクを愛し、Yandex.Mail開発の歴史の中で数ページを書くことを嫌がらず、誰もが技術の最前線に立つ準備ができている人たちが来るとき、私たちはいつも幸せです。