ホームページ >バックエンド開発 >PHPチュートリアル >大規模 Web サイトのアーキテクチャの進化と知識システム_PHP チュートリアル
大規模 Web サイトのアーキテクチャの進化と知識システム_PHP チュートリアル
- WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBオリジナル
- 2016-07-13 10:37:52953ブラウズ
LiveJournal や eBay など、大規模な Web サイトのアーキテクチャの進化を紹介する記事はこれまでにもいくつかあり、非常に参考になりますが、その理由を詳細に説明するよりも、それぞれの進化の結果について詳しく述べているように感じます。このような進化の後、多くの学生がなぜ Web サイトにこれほど複雑なテクノロジーが必要なのかを理解するのが難しいと感じているという事実に加えて、この記事を書くことを思いつきました。通常の Web サイトから大規模な Web サイトのプロセスにおける比較的典型的なアーキテクチャの進化プロセスと、習得する必要がある知識システムについて説明します。これが、インターネットで働きたいと考えている学生にいくつかの予備的な概念を与えることができれば幸いです。業界:) この記事が新しいアイデアを呼び込む役割を果たすことができるように、記事に間違いがある場合はさらに提案をお願いします。
アーキテクチャ進化の最初のステップ: Webサーバーとデータベースを物理的に分離
最初は、いくつかのアイデアにより、インターネット上にWebサイトを構築しましたが、この時点では、ホストがインターネット上にある可能性さえありました。この記事では、アーキテクチャの進化のみに焦点を当てているため、この時点でホストはすでにホストされており、Web サイトには特定の特性があるため、一定の帯域幅を持っていると仮定します。何人かの人々が訪問し始めますが、徐々にシステムの負荷が高まり、応答速度がどんどん遅くなっていることがわかります。このとき、データベースとアプリケーションが相互に影響を与えていることがより明らかになります。アプリケーションに問題があると、データベースにも問題が発生しやすくなり、データベースに問題が発生すると、アプリケーションにも問題が発生しやすくなります。そこで、アプリケーションとデータベースを物理的に 2 つのマシンに分離するという進化の最初のステップに入りました。現時点では、新しい技術要件はありませんが、影響があることがわかり、システムは以前の応答速度に復元され、データベースとデータベースによって相互に影響を与えることなく、より高いトラフィックをサポートできるようになりました。応用。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
アーキテクチャの進化のこのステップには、基本的に技術的な知識システムの要件はありません。
アーキテクチャの進化の第 2 ステップ: ページ キャッシュの増加
訪問者が増えると、応答速度が再び遅くなり始めることに気づきます。データベースにアクセスする操作が多すぎると、データ接続の競争が激しくなり、応答が遅くなります。ただし、データベース接続をオープンしすぎると、データベース マシンへの負荷が非常に高くなります。したがって、データベース接続リソースの競合とデータベース読み取りの負荷を軽減するために、キャッシュ メカニズムの使用を検討してください。この時点では、まず、Squid および他の同様のメカニズムを使用して、システム内の比較的静的なページ (ページなど) をキャッシュすることを選択できます。 1 ～ 2 日で更新されます) (もちろん、ページを静的にするソリューションを使用することもできます)。これにより、プログラムを変更せずに、Web サーバーへの負荷を大幅に軽減し、データベース接続リソースの競合を減らすことができます。 . それで、比較的静的なページをキャッシュするために Squid を使い始めました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
Squid などのフロントエンド ページ キャッシュ テクノロジ。それをうまく使いたい場合は、イカメソッドやキャッシュ無効化アルゴリズムなどの実装を深くマスターする必要があります。
アーキテクチャ進化の第 3 ステップ: ページ フラグメント キャッシュの追加
キャッシュ用に Squid を追加した後、システム全体の速度は確かに向上し、Web サーバーへの負荷も減少し始めましたが、アクセス数が増加すると、システムが再び少し遅くなり始めることがわかりました。Squid などの動的キャッシュの利点を味わった後、現在の動的ページの比較的静的な部分もキャッシュできるのではないかと考え始めました。 , そこで、ESI などのページ フラグメント キャッシュ戦略のようなものを使用することを検討しました。そこで、動的ページの比較的静的なフラグメント部分をキャッシュするために ESI を使用し始めました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
ESI などのページ フラグメント キャッシュ テクノロジ。これをうまく使用したい場合は、 ESI などの実装もマスターする必要があります。;
アーキテクチャ進化の第 4 ステップ: データ キャッシュ
ESI などのテクノロジーを使用してシステムのキャッシュ効果を再度改善した後、システムへの負荷は実際にさらに軽減されましたが、アクセス数が増加すると、検索後にシステムの速度が低下し始める可能性があります。ユーザー情報の取得など、データ情報を繰り返し取得する箇所があったので、このデータ情報もキャッシュできないかと検討し、変更後のデータをローカルメモリにキャッシュしました。システムの応答速度は再び回復し、データベースへの負担も大幅に軽減されました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
マップデータ構造、キャッシュアルゴリズム、選択したフレームワーク自体の実装メカニズムなどを含むキャッシュテクノロジー。
アーキテクチャ進化の 5 番目のステップ: Web サーバーの追加
好調な時期は長くは続かず、システムのアクセス数が再び増加すると、Web サーバー マシンへの負荷が相対的に上昇することがわかりました。この時点で、Web サーバーを追加することを検討し始めました。これは、可用性の問題を解決すると同時に、単一の Web サーバーがダウンした場合に使用できなくなることを防ぐためでもあります。 Web サーバーを追加する場合、次のような問題が発生します。
1. この時点で通常考えられる解決策は、Apache 独自の負荷分散ソリューションです。 LVS などのソフトウェア負荷分散ソリューション; 2. ユーザーセッションなどのステータス情報の同期を維持する方法。現時点で検討されるソリューションには、データベースへの書き込み、ストレージへの書き込み、またはセッションの同期が含まれます。情報およびその他のメカニズム
3. 以前にキャッシュされたユーザー データなどのデータ キャッシュ情報の同期を維持する方法。現時点で通常考慮されるメカニズムには、次のような同様の機能を作成する方法が含まれます。ファイルのアップロードは引き続き正常に動作します。現時点で通常考えられるメカニズムは、共有ファイル システムまたはストレージの使用です。これらの問題を解決した後、最終的に Web サーバーの数が 2 つに増加し、システムは最終的に以前の速度に戻りました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
しばらくの間、システムのアクセス数が急速に増加するという幸福を味わった後、システムが再び速度を落とし始めていることに気付きました。検索した結果、データベースの書き込みおよび更新操作中にデータベース接続リソースの競合が非常に激しく、システムの速度が低下することがわかりました。現時点で利用できるオプションにはデータベースのクラスタリングとサブが含まれます。 - データベース戦略に関しては、データベースのサポートがあまり優れていないため、サブデータベースを実現するには元のプログラムを変更する必要があることがより一般的になります。 -データベース、はい、目標は達成され、システムの回復は以前よりもさらに速くなりました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
しかし同時に、データ量の増加とサブデータベースの進歩に伴い、データベースのより適切な設計、チューニング、メンテナンスを行う必要があるため、これらの側面におけるテクノロジーが必要になります。はまだ非常に要求が厳しいです。
アーキテクチャ進化の 7 番目のステップ: テーブル シャーディング、DAL、分散キャッシュ
システムが実行を続けると、データ量が大幅に増加し始めますが、この時点ではクエリがまだ少し遅いことがわかります。データベースが分割された後、サブデータベースのアイデアに従って、サブテーブルの作業を開始します。おそらく、この時点で、必然的にプログラムにいくつかの変更が必要になることがわかります。アプリケーション自体は、サブデータベースやサブテーブルなどのルールを考慮する必要があり、まだ少し複雑なので、さらに追加するかどうかを考えました。 サブデータベースとサブテーブルへのデータアクセスの実装には、一般的なフレームワークが使用されます。これは eBay のアーキテクチャにおける DAL に相当します。もちろん、この一般的なフレームワークは、テーブルが完成した後に作業を開始するまで待機する可能性もあります。同時に、この段階で以前のキャッシュ同期ソリューションでは問題が発生する可能性があります。データ量が多すぎるため、キャッシュをローカルに保存して、分散キャッシュを使用する必要があります。計画が立てられたため、さらなる調査と拷問の後、最終的に大量のデータ キャッシュが分散キャッシュに転送されました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
サブテーブルもビジネス部門のようなもので、関連するテクノロジーは動的ハッシュになります。アルゴリズム、一貫性のあるハッシュ アルゴリズムなど。
DAL には、データベース接続管理 (タイムアウト、例外)、データベース操作制御 (タイムアウト、例外)、データベースとテーブルのシャーディング ルールのカプセル化など、多くの複雑なテクノロジが含まれます。
アーキテクチャ進化の 8 番目のステップ: Web サーバーを追加します
サブデータベースとテーブル サブデータベースの作業が完了した後、データベースへの負荷は比較的低いレベルに下がりました。再び毎日のアクセス数を監視し始めました。ある日突然、システムへのアクセスが再び遅くなり始めたことがわかりました。それは正常でした。その後、Web サーバーを確認したところ、Apache が多くのリクエストをブロックしており、各リクエストの数も比較的高速であることがわかりました。列に並んで待つ必要があり、応答速度が遅いため、一般的に、この時点ではある程度のお金があるので、ここに Web サーバーを追加します。課題:
1. Apache のソフト ロードまたは LVS ソフト ロードは、膨大な Web アクセス (要求された接続数、ネットワーク トラフィックなど) のスケジュールに耐えることができません。資金が許せば、解決策は購入することになります。 F5、Netsclar、Athelon などのハードウェア負荷。資金が許可されない場合、解決策は、アプリケーションを論理的に分類し、負荷クラスター内の別のソフトウェアに分散することです。
2.同期、ファイル共有、その他のソリューションにはボトルネックがあり、改善する必要があるかもしれません。おそらく、この時点で、Web サイトのビジネス ニーズを満たす分散ファイル システムが状況に応じて作成されるでしょう。 Web サイトのトラフィックが増加したとき、解決策は Web サーバーを継続的に追加することでした。
アーキテクチャ進化の第9ステップ: データの読み書きの分離と安価なストレージソリューション
ある日突然、この完璧な時代が終わりに近づいていることに気づき、データベースの悪夢が現れました。追加により、データベースとテーブルがデータベースとテーブルに分割されています。現時点では、データベースの読み取りと書き込みの比率が非常に高いことに気づくかもしれませんが、もちろん、データの読み取りと書き込みを分離するソリューションを実装するのは簡単ではありません。データベースに保存されたデータは無駄であるか、データベース リソースを過剰に消費するため、この段階で形成される可能性のあるアーキテクチャの進化は、データの読み取りと書き込みを分離し、BigTable などのより安価なストレージ ソリューションを作成することです。 。 このステップが完了した後のシステムの図を見てください:
データの読み取りと書き込みの分離には、データベースのレプリケーション、スタンバイ、その他の戦略の深い理解と自己実装テクノロジも必要です。
安価なストレージ ソリューションには、OS ファイル ストレージの深い理解と理解が必要です。また、ファイルで使用される言語の実装を深く理解していることも必要です。
アーキテクチャ進化の第10ステップ: 大規模分散アプリケーションの時代と安価なサーバー群の夢の時代へ
上記の長くて苦痛なプロセスを経て、私たちはついに再び完璧な時代を迎えました継続的な増加により、Web サーバーはより高いアクセス数をサポートできるようになります。人気が高まるにつれて、さまざまな機能の需要も急激に増加し始めます。 Web サーバー上に元々デプロイされていた Web アプリケーションがすでに非常に大きく、複数のチームがそれに変更を加え始めたとき、それは非常に不便であり、基本的にどのチームも多かれ少なかれそれを繰り返す必要があることがわかりました。巨大なアプリケーションパッケージを N 台のマシンにコピーして起動するには時間がかかり、問題が発生したときの確認も容易ではないため、デプロイとメンテナンスも非常に面倒です。特定のアプリケーションのバグによりサイト全体が利用できなくなる可能性が非常に高く、チューニングが不十分であるなどの他の問題もあります (マシンにデプロイされたアプリケーションがすべてを行う必要があるため、基本的にターゲットを絞ったチューニングを実行することができません) ) などの分析に基づいて、システムを責任に応じて分割することを決定し始めたので、通常、このステップには時間がかかります。多くの課題:
1. 分散化した後は、高性能で安定した通信フレームワークを提供する必要があり、さまざまな通信およびリモート呼び出し方法をサポートする必要があります。
2. 巨大なアプリケーションを変換するには、長時間かかるため、ビジネス組織とシステムの依存関係の制御が必要です。
3. この巨大な分散アプリケーションの運用と保守の方法 (依存関係の管理、運用状況の管理、エラー追跡、チューニング、監視と警報など)。
このステップの後、システム アーキテクチャは比較的安定した段階に入ります。同時に、このアーキテクチャと学習した経験を組み合わせて、大量の訪問とデータをサポートするために多数の安価なマシンの使用を開始することもできます。増加するトラフィックをサポートするさまざまな方法が他にもあります。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
このステップには多くの知識システムが含まれており、通信、リモート通話、メッセージメカニズム、深く理解して習得するには、理論、ハードウェア レベル、オペレーティング システム レベル、および使用される言語の実装を明確に理解する必要があります。
運用と保守には、多くの場合、分散並列コンピューティング、レポート、監視テクノロジー、ルールと戦略などを習得する必要があります。
ウェブサイト全体のアーキテクチャの古典的な進化プロセスは、上記の比較と同様です。 もちろん、各ステップで実行される計画と進化の手順は異なる場合があります。さらに、Web サイトのビジネスが異なるため、専門的および技術的なニーズも異なります。もちろん、このブログでは、データベース クラスターやデータ マイニングなど、ここで言及されていないテクノロジーの進化プロセスについて詳しく説明します。 、検索などがありますが、実際の進化のプロセスでは、より多くのトラフィックをサポートするために、ハードウェア構成、ネットワーク環境のアップグレード、オペレーティング システムの変更、CDN ミラーリングなども使用されます。実際の開発プロセスでは、大規模な Web サイトでは、上記のことだけでなく、セキュリティ、運用と保守、運用、サービス、ストレージなども行う必要があります。この記事を書くのは実際には簡単ではありません。これは、大規模な Web サイト アーキテクチャの進化に関するさらなる紹介につながる可能性があります。:)追記: 最後に、LiveJournal アーキテクチャの進化に関する記事をいくつか紹介します:
LiveJournal のバックグラウンド開発から大規模な Web サイトのパフォーマンス最適化手法を検討する
http://blog.zhangjianfeng.com/article/743
またここから: http://www.danga.com/words/現在の LiveJournal Web サイトのアーキテクチャに関する詳細情報を見つけることができます。