wikipaintings.orgを例として使用するAmazon Webサービスの使用

尊敬されるコミュニティは、アマゾンウェブサービスを使用してインターネットプロジェクトを開発した私の経験について学ぶことに興味があると思います。



プロジェクト全体が完璧だと言うつもりはありませんが、このプロジェクトの作成に役立った主なソリューションについて説明しようと思います。 私たちに働きかけたWikipedia.orgは、1か月に120億ページを提供します。そのため、最初から人気の成長に向けてコードを準備しようとしました。



wikipaintings.orgとは-www.wikipaintings.org/en/About

開発の最初の段階と次の段階の主なタスクは終了しました。サイトを埋めるためにボランティアを引き付けます。



絵画が退屈だと思われる場合は、Archimboldの創造性を試してみてください-www.wikipaintings.org/en/giuseppe-arcimboldo/spring-1573#supersized-artistPaintings-184903



絵画スタイルの分類を最終的に理解することに興味がある場合は、 www.wikipaintings.org / en / paintings- by-styleへようこそ



さて、今、Hubbraeffektomサイトを配置した後（まだ配置していない場合-すべての友人へのリンクをスローします）、主なもの-技術的なヒントに移りましょう。

技術プラットフォーム

このプロジェクトは、ASP.NET MVC、LINQ2SQL、MS SQL Server 2008 R2、およびJQueryを使用して完了しました。 AWSがJAVA / PHP開発者により重点を置いていることは秘密ではありませんが、私は特に恵まれているとは感じませんでした。

開発者への私のアドバイスを、Webアプリケーションの従来の層の順に検討することを提案します。

データベース

ビジネスオブジェクトの集中データベースから始めました-見積もりによると、かなり強力なインスタンスが、近い将来（現時点ではHigh Cpu Mediumインスタンス）に必要な数の典型的なクライアントリクエストを処理できます。 最も一般的なHTTPリクエストの場合、必要なすべてのデータを返すSQLクエリが1つだけ実行されるようにしました。このシナリオでスケーリングが最も難しいのはデータベースです。

データベースにファイルを保存することを強く「いいえ」と言うことが重要です。 SQL Server 2008の高度な機能にもかかわらず、これは間違った方法です。 EC2がElastic Computing Cloudの略であることは偶然ではありません。最初のサーバーは単なるプロセッサであり、その主な目的は保存ではなく読み取りです。

最初は、ユーザーファイルが多すぎてどのドライブにも収まらないため、S3でのそれらの場所は無限で非常に信頼性の高いファイルストレージです。 おそらく最初は遅いように見えるかもしれませんが、その速度は変わらず、1プロセスまたは1000で動作します。

複雑なクエリの結果をデータベースレベルでキャッシュします。 1つのストアドプロシージャにカプセル化された絵画やアーティストのあらゆる種類の検索があります。 キャッシングキーとして、すべてのパラメーターを記録し、別のユーザーが同じタグまたはスタイルをクリックすると、データベース内に適切なオブジェクトのIDの準備済みリストが既にあります。 また、ページングを使用する場合に結果を即座に提供できます。

メインと一緒に従属オブジェクトをパックします。 たとえば、画像は画像の行にシリアル化されたXMLとして保存され、アーティストの行には同じXMLとして保存されます。 はい、これはあまり美しくありませんが、各サブクエリは少なくとも0.0005秒です。ページにすべてのペイントを描画する場合、この時間に200を掛ける必要があります。

「アプリケーションのパフォーマンスを最適化するために隠しデータを開く」という記事も非常に役立ちます。 ）

C＃/中間層

ページのレンダリング時間と各主要操作を追跡します。 最近、 stackoverflowプロファイラーが強調表示されましたが、一般的には、自分で簡単なことをすばやく行うことができます。 BeginRequest-初期化、EndRequest-では、ページがN秒以上レンダリングされていないことを確認します。 さらにレンダリングされる場合-エラーログにエントリを書き込みます。 どのステップがかかるかを理解する必要がある場合は、アプリケーションの経過時間を記録するコードを配置します。 パフォーマンスのチューニングの効果を視覚的に確認するために、このようなログをマスターページの最後にhtmlコメントとして表示しても問題はありません。

「ランダムアクション」コントローラーメソッドを作成します。これは、セレンなどを学習するよりもはるかに簡単で、loadimpactなどの簡単なテストでアプリケーションのさまざまな機能の速度をテストできます。

ネストされたループに注意してください。 各ステップでWhere（）を使用して配列を通過する無害なレンダリングサイクルは、1/10秒かかります。 配列を辞書に変換する前の同じサイクルは、すでに100分の1秒で完了しています。

Linq2sqlを使用している場合でも、同じSPから複数のテーブルを返します-これは可能であり、うまく機能します。 0.005秒でPKによってオブジェクトの基本サンプルのオーバーヘッドを推定します。 このような操作がサイクルを繰り返すと、経済は何度も成長します。 たとえば、ストアドプロシージャは、写真だけでなく、それを書いたアーティストも返します。

一度に1つのレコードではなく、バッチでデータを読み取ります。 これが、絵画の検索結果の表示の仕組みです。 C＃で画像のリストを受け取った後、idアーティストのリストを作成し、1つのサブクエリで辞書に読み込んでから、読み取ったオブジェクトを対応する画像に割り当てます。

ASP.NETによって移植された自然な形式のコンポーネントアプローチをページレイアウトに使用しないでください。 これは、各コンポーネントの最小限のパラメーターを意味し、実際には、各コンポーネントがユーザーを読み取り、権限をチェックし、プライベート設定を読み取ります。 要求の正確な時間に有効なシステムコンテキストを取得します。必要に応じて、必要な情報がすべて収集され、1回だけ読み取られます。

outputcacheに依存しないでください。 これはクールで高速であり、使用する必要があります-サーバーの負荷を軽減しますが、万能薬ではありません。 たとえば、2010年5月18日には、1万9,000のページビューがあり、そのうち8500が異なる（Googleアナリティクスによる）。 さらに、各プロセスには独自の出力キャッシュがあります。つまり、メモリコストは、システム内のオブジェクトの数xサーバーの数に比例します。 パラメーターを持たないメインページの場合、キャッシュ期間は非常に長くなる可能性があり（15分）、まれなページの場合、このリンクがハブで公開される場合に30秒を設定します。 一方、ajaxリクエストは十分にキャッシュされます。多くのパラメーターがなく、頻繁に繰り返され、結果として、原則としてHTMLページの結果よりも少なくなります。

別々のプロジェクトで複雑な部品を取り出します。 一般的なクラウドサーバーはかなり脆弱ですが、いくつかのサーバーが存在する可能性があります。 たとえば、別のWebサービスでサムネイルの生成を削除しました。これにより、別のサーバーにサムネイルを配置して、インポート時の画像のダウンロード速度を向上させることができました。

今できないことを先送り-Amazonは、優れた高速で無限の安価なツールキューを提供しています（このサービスのコストは1か月あたり10セント未満です）（ソースコード2を参照）。

共有メモリを使用します。 たとえば、写真のページ（http://www.wikipaintings.org/en/giuseppe-arcimboldo/portrait-of-eve-1578）では、このアーティストによる他のページの同じ絵を示しています。 各アーティストの絵画に関する最小限の必要な短い情報を記憶に留めて、このページの生成時間を2.5倍に短縮しました。 もちろん、Velocityを使用することもできますが、開発中のWindows 7のサポートが不足していることが問題になっています。 Webアプリケーションがリモート経由で通信する独自​​のWindowsサービスを作成しました。 実際、これはSystem.Web.Caching.Cacheの典型的な繰り返しですが、すべてのインスタンスで同じデータセットをサポートしています。

クライアント部

さまざまなツールを使用して出力をテストします-YSlow、 Pagespeed 、Firebugなどのユーティリティはあなたの親友です。

クラウドフロントに移行できるものすべて。 明らかに-写真、サムネイルだけでなく、2つのCSSファイル（通常の1つ、1-gzip）にまとめてそこに書き込みます。 .gz Safariは理解できないため、.gzip拡張子は重要です。 この手法は、コード例1で示されています。

有効期限の割り当て-デフォルトでは、S3はこれを行いません（サンプルコード＃1を参照）。 トラフィックの時間と費用を節約できます。 この操作とs3での静的ファイルの管理には、一般的にcloudberryをお勧めします。

ページの読み込み速度を上げるための重要なニュアンスは、異なるサブドメインへのリクエストの割り当てです。 httpプロトコルでは、一度に1つのサーバーに対して3つ以上の要求を許可しません。 ブラウザは最大5つのリクエストを行いますが、100以上の画像を含むページの読み込みには10秒以上かかりました。 画像をサブドメインに分割し、良好なチャネルを条件として、同じページの読み込みが最大8倍高速になりました。 これを行うには、cloudfrontに一連のドメインを作成し（uploads0、uploads1、... uploads8があります）、目的のドメインを擬似ランダムに選択します。 Cookieがリクエストごとに送信されないように、このために別のドメインを登録することはさらに良いことですが、この妄想を考慮しました。

ページを表示するのに必要な以上の情報をダウンロードしないでください。他のすべては、ajaxを介して後でダウンロードできます。 ページの読み込みが速いほど、ユーザーの忠誠心が高まります。 主なことは、データを読み込むときに適切で適切なアニメーションを作成することです。

展開の推奨事項

データベース用に1つのインスタンスを集中的に使用し、負荷分散管理下でページをレンダリングするマイクロインスタンスのセットを使用します（Windows Server 2008 R2 Coreの構成に関する記事を参照してください 。

負荷分散自体は非常に便利に使用できます。それを操作するためのGUIがあります。 Amazonが6〜60秒（設定）の間隔でチェックするシステムステータスページを提供することをお勧めします。 2つの（おそらくそれ以上の）否定的な結果（タイムアウトまたはエラーコード）の場合、インスタンスは「異常」と宣言され、リクエストは他のサーバーに送られます。 作業容量が復元された後、作業に再び含まれます。

最初の1年間に1つのロードバランシングが無料で提供されます。

Bacupベースは、個別のEBSディスクで毎日行われます。 ホストシステムまたはWindows自体に何が起こっても、コントロールパネルを使用して、このディスクを1つの仮想サーバーから切断し、新しい仮想サーバーに接続し、タンクを上げて作業を続行できます。 緊急時のシステムの復元力を高めるための追加手順として、このドライブのスナップショットを自動的に作成できます。

開発プロセス

開発プロセスが果たす役割は少なからずありました。 プロジェクト段階の固定費に依存せず、毎週新しい安定した作業バージョンを発行しました（確かに遅延はありましたが）。

反復中、チーム全体が3〜4個のメインタスクに集中し、満足するまで作業を続けました。

次のバージョンのリリース後、実際の生活と実際のユーザーはしばしば調整を行い、1-2の機能が次の変更に進みました。

このプロセスは計画の面でひどいですか？ ただし、結果として各タスクに時間を事前に割り当てる標準的なアウトソーシングよりもはるかに優れた機能を発揮します。 また、二流のタスクがないという事実の両方で動機付けに大きな効果があり、将来の変更を快適にするために一定のリファクタリングをサポートします。

重要なのは、未知のもののタイミングと建設予算ではなく、ゴミにならない製品であり、おそらく、アジャイルアプローチで作業できることをクライアントに認めさせてください。

結論

一般的に、一見したところサーバーが弱く、価格が高いにもかかわらず、Amazonは「明るい未来」に備えてプロジェクトを構築するのに役立つ信頼性の高いプラットフォームとしての地位を確立しています。

少しの作業に投資する準備ができている場合は、いつでもチャンスを利用してお金を節約し、ホスティングコストを通常のサーバーのコストのレベルに近づけることができます。

便利なリンク

1. S3を使用する

2. SQSを使用する

3. Micro Intsance用のWindows Server 2008 R2コアの構成

4. SQL Server-隠しデータを開いてアプリケーションのパフォーマンスを最適化する

5. stackoverflowからのWebアプリケーション用のミニプロファイラー