数年前、私たちは、企業に展開された私たち自身のメールサービス、特に小規模で独自のシステム管理者がいないメールサービスは、良いというよりも厄介なものであることを提案しました。 そして、時間の経過とともに、電子メールの保管と処理の責任をアウトソーシングの特別なサービスに移す人がますます増えています。 そこで、ドメイン用のメールを取得しました。
時間が示すように、私たちは間違えていませんでした。今日、YandexドメインのメールはRunetで最も人気のあるメールサービスです。 合計で、20万を超えるドメイン名と約350万のメールボックスがトラフィックルールに接続されています。 毎日約200個のドメインがトラフィックルールに接続されています。 この記事では、トラフィックルールがどのように機能するかを説明し、コメントではご質問にお答えします。
SDAは、その存在の過程で多くの追加機能を獲得しました：アドレス帳との統合、jabberサーバーのサポート、メーリングリスト、ユーザーの以前のサーバーからのメールのインポート、そしてもちろん、リクエストを自動化するための外部API。 たとえば、Yandex.Mail for Domainsで再認証せずに、そのサイトで承認されたサードパーティサイトのユーザーがすぐにメールボックスに落ちたことを確認するよう長い間求められました。 また、APIを使用して、このパスワードなしの認証方法を実装できました。
トラフィックルールが提供するすべての機会には、Yandex製品などのさまざまなコンポーネントとの統合が必要です。 本質的に、トラフィックルールは、ドメイン管理者の制御下にある異種のコンポーネントを統合する統合サービスです。
SDAはドメインから始まります。ドメインに接続し、ドメインの所有者とSDA管理者が同じ人物であることを確認する必要があります。 何らかの理由でドメインがDNSレベルでSDAから切断されることがあります。 所有権を確認し、ドメインのステータスを確認するために、リレーショナルDBMSの複数のチェックキューリポジトリサーバーとMongoDBに基づく分散ロッククラスターで構成されるチェックキューシステムを使用します。
ドメインサイトまたはゾーンのDNSサーバーをホストするサーバーに過負荷がかからないように、後続の各検証チェックは、5分から24時間の間隔で増加します。 ドメインステータスのチェックはより頻繁に行われます-一定の時間間隔で約4時間ごとに1回。 このアプローチにより、チェックの作業キューの負荷を大幅に削減できます。 ドメインが確認されるとすぐに、管理者はすべての基本機能を使用できるようになり、メールボックスを作成できます。
普遍的なアプローチを維持し、エラーの数を減らすために、他のYandexコンポーネントが必要な情報を交換するために使用できるドメイン用の内部メールAPIを開発しました。 たとえば、パブリックドメインメールAPIはそのようなコンポーネントの1つです。 パブリックAPI呼び出しは、ユニバーサル内部API呼び出しに変換されます。 SDA Webインターフェースのアクションは、内部APIメソッドも呼び出します。
必要なアクションに応じて、内部API呼び出しハンドラーは特定のYandexコンポーネントにアクセスできます。 新しい機能を設計する際の基本原則は、すでに別の場所に保存されている情報をSDA側に保存しないことです。 例外は、実行時間に重要な要求に対してのみ行われます。要求はキャッシュする必要があります。
たとえば、新しいメールボックスを作成するには、Passportに新しいユーザーを作成し、そのユーザーのMailのストレージを初期化し、ドメイン管理者が選択したとおりに新しいメールボックスを構成する必要があります。
ドメインで共有アドレス帳が有効になっている場合、メールボックスを作成または削除するメソッドへの各呼び出しには、ドメイン帳を変更するためのアドレス帳APIへの追加の呼び出しが伴います。 したがって、新しいドメイン受信者に関する情報がすぐに検索可能になります。 また、jabberの共有連絡先リストが有効になっている場合、ユーザーはjabberサーバー側の連絡先リストにも追加する必要があります。
このような統合では、サービスの応答時間と発生する可能性のあるエラーの処理が非常に重要です。 エラーには主にネットワークと論理の2種類があります。 完全を期すために、サービスのリストと、サービスとトラフィックルールの統合の機能を見てみましょう。
パスポート
実際、これはトラフィックルールの主要なデータソースであり、データベースほど重要ではありません。 Passport SDAでは、HTTP経由で内部APIを介して通信します。 パスポートのエラーは重大です。 Passportがエラーを返した場合、またはPassportとの通信に失敗した場合、エラーをユーザーにブロードキャストし、データベースまたは他のサービスで既に実行されたアクションをキャンセルします。 したがって、さまざまな統合サービス間のトランザクション操作がサポートされています。各コマンドには、その対抗策-操作をキャンセルするコマンドがあります。
郵便
これは、ドメイン管理者がトラフィックルールを通じて管理する重要なサービスです。 メールボックスの作成には多くの計算が必要なので、バックグラウンドで実行されます。 登録を完了するには、アトミック操作のキューが必要です。ボックスを開く、ドメインの基本設定を適用するなど。 この場合のネットワークエラーはそれほど重大ではないため、問題が発生した場合、別の分散キューで操作が遅くなるまで冷静に延期されます。このキューのプロセッサは、障害発生後1日以内にボックスを再構成しようとします。
DNS
3つのトラフィックルールドメインのうち約1つが、YandexサーバーでDNSゾーンをホストしています。 DNSバックエンドのエラーは、ネットワーク障害が発生し、データベースに完全に書き込めない場合にのみ重大と見なされます。 他のすべての場合、ユーザーの問題を解決するアルゴリズムがトリガーされます。
たとえば、ドメインの委任時に、Yandexは以前のDNSサーバーからレコードの一部をコピーするため、ユーザーはゾーンを正確に転送するという面倒な作業を行う必要がありません。 この場合、ルートドメインレコードがCNAMEタイプである場合に状況が発生する可能性があり、これは標準と矛盾します。 このようなCNAMEレコードを持つユーザーは、自分のドメインでYandex.Mailを有効にすることはできません。したがって、インポートするとき、そのようなレコードはスキップされます。
ロギングとロギング
大規模なファームと同様、プロトコルはどこにもありません。 SDAは、他のYandexコンポーネントとのすべての相互作用の詳細なログを保持します。 多くの場合、これらのログは、ユーザーが気付く前に問題を見つけることができます。 サービスが迅速かつ効率的に機能するように、システムログを監視するための特別なソフトウェアを監視します。 大規模な事故やエラーの場合、リクエストの処理時間が大幅に増加したり、応答にエラーが表示されたりすると、システム管理者は数分以内にこれに気付き、昼夜を問わず修正を開始します。 しかし、次回については。
質問を待っています！