あなたはおそらくインターネットマップについてすでに聞いたことがあるでしょう。 そうでない場合は、 ここでそれを見ることができ、それについては私の以前の投稿で読むことができます。
この記事では、インターネットマップのサイトがどのように配置されているか、どのテクノロジーがその正常な機能を保証しているのか、マップを見たい大勢の訪問者に耐えるためにどのような手順を踏む必要があるのかについてお話したいと思います。
インターネットマップのパフォーマンスは、インターネット大手の最新テクノロジーによってサポートされています。GoogleのGoogleマップエンジンは地図を表示し、WebリクエストはMicrosoft .netテクノロジーによって処理され、AmazonのAmazon Webサービスはホスティングとコンテンツ配信を提供します。 3つのコンポーネントはすべて、カードの通常の動作に不可欠です。
さらに、カードの内部アーキテクチャに関する大きなシート：主にAWSの賞賛、パフォーマンスの問題、ホスティングコストについても触れます。 あなたが恐れていないなら、猫へようこそ。
Amazon CloundFrontとGoogleマップ
Google Mapsテクノロジーには、タイルの使用が含まれます-タイル-256x256ピクセルの小さな画像からマップ画像が形成されます。 これらの写真に関連する主なポイントは、本当にたくさんあるということです。 画面上に高解像度で地図を表示すると、すべてがこれらの小さな写真で構成されます。 これは、クライアントがモザイクに気付かないように、サーバーが多くの要求を非常に迅速に処理し、同時にタイルを提供できる必要があることを意味します。 マップを表示するのに必要なタイルの総数は合計（4 ^ i）です。ここで、iは0からNまでの値を通ります。Nはズームの総数です。 インターネットマップの場合、ズームの数は14です。 タイルの総数は約3億5,800万個です。 幸いなことに、この天文図は3000万個に減り、空のタイルの生成は放棄されました。 ブラウザコンソールを開くと、多くの403エラーが表示されます。これらは正確にエラーです-タイルがありませんが、このマップは表示されません。 タイルがない場合、正方形は黒の背景で塗りつぶされます。 いずれにしても、3000万タイルも重要な数字です。
したがって、この場合、専用サーバーにコンテンツを配置する標準的なスキームは適切ではありません。 多くのタイルがあり、多くのユーザーがいます。多くのサーバーがあり、遅延に気付かないようにユーザーの近くに配置する必要があります。 それ以外の場合、ロシアのユーザーは良好な応答を受け取り、日本からのユーザーは、ダイヤルアップモデムがカードを見る時間を覚えています。 幸いなことに、Amazonにはこのケースに対する解決策があります（アカマイにも会社がありますが、彼女に関するものではありません）。 これはCloudFrontと呼ばれ、グローバルコンテンツ配信ネットワーク（CDN）です。 コンテンツをどこかに配置し（これをOriginと呼びます）、CloudFrontでディストリビューションを作成します。 ユーザーがコンテンツをリクエストすると、CloudFrontはユーザーに最も近いネットワークのノードを自動的に検索し、そこにデータのコピーがない場合、別のノードまたはOriginからリクエストされます。
データは何度も複製され、高価で脆弱で信頼性の低いストレージではなく、CloudFrontサーバーから配信される可能性が高いことがわかります。 インターネットマップの場合、CloudFront接続により、ハードドライブからのデータがシンガポールシンプルストレージサービス（S3）セグメントに物理的にコピーされ、S3がデータソースとして指定されたCloudFrontのAWSコンソールからディストリビューションが作成されました。 （起源）。 インターネットマップページのコードを見ると、タイルがCloudFrontアドレスd2h9tsxwphc7ip.cloudfront.netから取得されていることがわかります。 最も近いサイトを検出し、コンテンツを最新の状態に保ち、CloudFrontがこれらすべてを自動的に実行します。 やった！
写真では、元のマップがどのようにタイルに分割され、タイルがS3に格納され、そこからCloudFrontにアップロードされ、ノードからユーザーに配信されることがわかります。
Amazon RDS
マップ上でサイト検索を提供するには、サイトとその座標に関する情報が保存されるデータベースが必要です。 この場合、AmazonクラウドにMS SQL Expressがあります。 これは、リレーショナルデータベースサービス（RDS）と呼ばれます。 関係は本当に必要ありません。 テーブルは1つしかありませんが、車輪を再発明するよりも、完全なデータベースを用意する方が適切です。 RDSを使用すると、MS SQLだけでなく、Oracle、MySql、およびおそらく他のものも使用できます。
この図では、ソースマップがRDSデータベースのテーブルにどのように変化するかを確認できます。
Amazon Elastic Beanstalk
おそらく、Amazonクラウドサービスファミリのこの機能が最も印象的でした。 Elastic Beanstalkでは、文字通りワンクリックで、最小限の時間で、またはサイトをオフラインにせずに、負荷のかかったプロジェクトをリリースできます。 リリースがどれほど難しいか、特にインフラストラクチャに複数のサーバーとロードバランサーが含まれる場合は、Elastic Beanstalkがこれをいかに簡単かつエレガントに処理するかに驚くばかりです。 最初の展開では、アプリケーション（環境）に必要なインフラストラクチャ全体（ロードバランサー（Elastic Load Balancer-ELB）、コンピューティングユニット（Elastic Compute Cloud-EC2））を作成し、スケーリングパラメーターを決定します。 大まかに、1つのサーバーがあり、すべての要求がそのサーバーに直接送信される場合、特定のしきい値に達すると、サーバーは負荷への対処を停止し、ほとんどの場合クラッシュします。 時々、彼は以前に完璧に働いていた負荷の下で立ち上がれないことさえあります。 動作モードに入るには、通常ある程度の時間がかかり、絶え間ないリクエストではこれを行うことができません。 一般的に、戦った人は誰でも知っています。
Elastic Beanstalkは、インフラストラクチャのすべての問題を処理します。 実際、MS Visual Studioにプラグインを配置して、詳細を忘れることができます。 彼はバージョン管理、デプロイなどをサポートします。 また、負荷が増加すると、必要な数のEC2インスタンスが作成されます。
図では、Elastic Beanstalkは点線で囲まれており、内部にはELBがあります。ELBは着信リクエストを受け入れ、EC2インスタンスのIISに配信します。
性能と価格
WebサイトHabrahabr.ruに記事が公開された直後、訪問者のストリームがインターネットマップにアクセスしました。 グラフでは、トラフィックが非常に急激に増加し、最初の6時間で30,000人がサイトを訪問し、初日には主にロシアと旧ソ連諸国から約50,000人がアクセスしました。 何かが間違っていると感じて、Elastic Beanstalkは10個のEC2インスタンスを作成し、それらは良い仕事をしました。 サイトへのアクセスに関する問題に関する苦情が報告されています。 マップは自由に表示できます。 しかし、RDSはすぐに死亡しました。最初は検索が非常にゆっくりと開始され、その後断続的に開始され、その後完全に停止されました。 初日のアカウントは約200ドルでした。 S3 + CloudFrontの場合は約100、EC2およびRDSの場合は約50。
得られた経験を研究して、自動スケーリングパラメーターの最適化と再構成を実行しました。 そしてそれは助けた。 週の間に、このサイトは世界中から1日平均30〜5万人が訪れ、何も落ちませんでした。 確かに、初日ほどの急激な流入はありませんでした。
その後、誰かがreddit.comにカードに関する情報を投稿すると、トラフィックが爆発的に増加しました。 日曜日に約50万人がこのサイトを訪れましたが、1つの小さなインスタンスEC2と1つの小さなRDSインスタンスだけが機能しました。 確かに、カードがロードされないという不満が1つありましたが、これはこのような波では普通のことだと思います。
そして、これが最初の週の請求書です
おわりに
単語の雲がITとは関係ないときに、私は情報技術に携わり始めました。 それ以来、多くの変更が行われ、スタンドアロンサーバーの寿命は延びています。 もちろん、クラウドでのホスティングには欠点があります（たとえば、Instagramに問い合わせることができます）。 しかし、私の意見では、ほとんどの懸念をクラウドサービスにシフトする能力は、すべてのリスクを払う以上のものです。 プロジェクトの開発を始めており、品質、可用性、信頼性、およびスケーラビリティが重要である場合、ほとんどの場合はクラウドにいます。