Clever Geek Handbook

Airy-サイトのクラウド



最近、新しいサービスを開始しました-サイトのクラウド、 Air.rf。 サイトのクラウドは、サイト全体が明るく、透明で、風通しが良く、高速な場合です。 写真、スクリプト、複雑なサーバーロジック、データベース、およびDDoSを使用してこれを省略することはできません。 これは、サイトが飛ぶときです。 夢を実現しました。プラットフォーム、内部機能、クライアントロジックに関係なく、どのサイトでもクラウドに配置できるようになりました。 そして、すべてのデバイスおよびすべてのユーザーで、より高速で信頼性の高いものになります。 また、最小のサイトと最大のサイトの両方で利用できます。



はい、それは西部のCloudFlareのように見えます。 元のモデルも同じです。 しかし、その地理によると、ロシアの広大さでのみ。 そして、別の方法で開発する予定です。



PS Now Airiはベータ版であり、最初のユーザーを積極的に募集していますが、サービスは既に商用運用に移行しており、信頼性が優先されます。





建築



最初は、サービスのいくつかのコンポーネントを作成し、責任のレベルを最大限に分割することを計画しました。 しかし、後で、データの整合性とシステムのフォールトトレランスに関するさまざまな制限により、次のアーキテクチャに到達しました。



サービス全体は地理的に独立したノードに分割され、ユーザーはIPアドレスとDNSレコードに応じて特定のノードに誘導されます。 DNSレコードは地理的にバランスが取れています（ノードに障害が発生した場合、ローカルユーザーを短時間で別のノードにリダイレクトできます）。

  1. DNSレイヤー。 各ノードは、最大のフォールトトレランスを実現するためにLVSで構成されたサーバーのペアです。 さらに、異なるDNSサーバー上のゾーンは、地域ごとに異なる応答を行い、ジオバランスを作成します。
  2. バランシング層（LVS）。 全体の負荷をかける主なマシン。 また、サイトのドメインに応じて、DDoS保護に接続し、さまざまなFEO-CDNサーバーに要求を再配布するように設計されています。
  3. FEO-CDNレイヤー（フロントエンド最適化およびコンテンツ配信ネットワークから）。 各ノードは、プロキシサーバーのキャッシュおよび最適化クラスターです。 このレイヤーのアーキテクチャについては長い間考えていましたが、サイトの作業とサーバー負荷の両方を可能な限り最適化する方法については引き続き考えています。 現在、4レベルのキャッシュとプロキシがあります。

    1. フロントエンドレベル。コンテンツを圧縮（gzip経由）するだけで、必要に応じて最終的なHTMLページサイトをキャッシュします。 キャッシュにリクエストがない場合は、さらにリクエストをプロキシします。 指定されたコンテンツの統計を収集します。
    2. 最適化レベル。 ここでは、ページスピードが展開され、遅延読み込みと動的なページキャッシュが改善されています。 使用されるアルゴリズムに関して最も難しいレベル。 キャッシュ以外のリクエストはすべて下位レベルに送信されます。
    3. キャッシングレベル。 すべての静的および可能であれば動的をキャッシュします。 可能であれば、キャッシュからすべてを提供します。 そうでない場合は、ソースサイトを要求します。 また、低レベルのリクエストを記録し、ソースサイトからのデータの解凍を提供します。




バランスと回復力



実装中に、サービス（またはサイト）障害のいくつかのシナリオを考慮しました。 基本的なものを次に示します。

  1. ノードのDNS層に障害が発生-LVSペアの2番目が接続されています。 両方のサーバーに障害が発生すると、他のノードのDNSレイヤーがDNSクエリに（まったく同じ内容で）応答し始めます。
  2. ノードのバランシングレイヤーのLVSペアの両方のサーバーに障害が発生します。 この場合、DNSバランシングにより、要求は他のノードに自動的にルーティングされます。
  3. 失敗（過負荷）FEO-CDNレイヤー-このレイヤーに追加の予備サーバーを自動的に接続します。 使用可能なサーバーがない場合は、前のシナリオに従って進みます-サイトを別のノードに転送します。
  4. チャネル（DDoS）は1つまたは複数のノードで過負荷になります-バランシングの「問題」レイヤーのQRatorを自動的に接続します。
  5. ソースサイトがクラッシュします（使用できなくなります）。 サイトがキャッシュされており、利用できない期間がキャッシュの有効期間より短い場合、ユーザーは何も気付きません。 使用不可期間が1日未満の場合、キャッシュからページを発行し続けます。 動的サイトの場合、個別のポリシー（スタブページ、キャッシュされたコンテンツ、またはリダイレクト）。


主な問題領域とリスクはアーキテクチャによって排除されたため、99.9％のフォールトトレランスについて話すことができます。



加速の仕組み



最も困難で興味深いのは、加速の仕組みです。 ほとんどのサイトに適したいくつかのオプションから収集した、利用可能なPage Speedフィルターを分析しました。 彼らはそれに応じて加速レベルを呼び出しました：安全（サイトへの害が保証されていない場合）、最小（サイトを害するリスクが最小の場合）、最適（ほとんどのサイトに適し、大幅な加速を提供しますが、潜在的に危険）および最大（最もリスクが高く、最も効果的なオプション）。 さらに、必要に応じて、すべてのパラメーターを手動で調整します（製品のセットアップに関する既存のポリシー-WEBO Site SpeedUpに完全に準拠）。



デフォルトでは、すべての静的サイトオブジェクトが長時間キャッシュされ、すべてのテキストオブジェクトが確実にアーカイブされることを強調します。 さらに、ファイルの統合、ページのコンテンツへの小さなオブジェクトの組み込み、遅延ロードとローカルストレージのロジック、および複数のドメインとデータの使用：画像のURIを使用できます。 一般的に、すべてをカスタマイズしたい人のための完全な詰め物。 そして、サイトの速度と信頼性のレベルを他のすべての人に保証します。



リクエストのジオバランシング（サイト訪問者が最も近いサーバーからサイトオブジェクトを受信する）とともに、「ワンクリックで」サイトの速度に関するすべての問題を解決します。



関税



私たちはできるだけユーザーフレンドリーになりました-無料（1か月あたり50 GBの発信トラフィック）から最大（5万ルーブル）までの関税を提供します。 平均的なサイトは、1か月あたり1000〜2000ルーブルで接続できます（これには、1か月あたり100〜250 GBのトラフィックが含まれ、1か月あたり最大10万ユーザーで十分です）。



接続



接続には主に2つのタイプがあります。DNSサーバーの変更によるものと、CNAMEによるwwwの同義語です。 最初のケースでは、wwwなしでのみアクセス可能なドメイン（air.rfなど）を接続します。ジオバランシングを完全に制御できるように、ドメインをサーバーに委任する必要があります。



2番目のタイプの接続は、wwwまたは両方を介してのみアクセスできるサイトに適しています。 後者の場合、wwwのないサイトからwwwのあるサイトにリダイレクトし、そのサイトのDNSレコードを作成する必要があります 

  www IN CNAME cloud.airee.ru。


その後、サイトはクラウドを介して提供され始めます。



もちろん、これらすべてのアクションは、アプリケーションの送信後に実行する必要があります 。 まだすべてのRunetドメインにサービスを提供していません:)



近い将来、クラウドを管理するための個人アカウントが表示されます。



質問やコメントをお待ちしております。 私たちの目標は、エアネットをRuNetにサイトを配置する際の事実上の標準にすることです。


More articles:


All Articles