スケーラビリティの高いウェブサイトを構築するにはどうすればよいでしょうか?

この記事は「拡張性の高いウェブサイトの50の原則」を読んで以下の内容をまとめたものです。

一方で、ブロガーには実際の建築経験がなく、他方で知識が十分に広くないため、本の重要なポイントを体系的に要約し、自分の理解に基づいていくつかの結論を下すことしかできません。

主な内容

本書では、拡張性の高い Web サイトは、ビジネスの発展とユーザーの増加に応じてアーキテクチャを自由に拡張し、Web サイトの急速な発展に容易に対応できるよう、さまざまな側面から 50 の提案を行っています。本書の具体的な内容を見てみましょう:

方程式の簡略化

1 過剰な設計をしない

過剰な設計は、システムの複雑さと保守コストの増大に等しい。しかし、こうした過剰な設計は通常の使用ではほとんど効果がありません。多くの場合、これらはデザイナー自身が重要であると考えている機能、またはおまけの機能ですが、実際にはほとんど役に立ちません。

2 設計時にスケーラビリティを考慮する

設計時には次の設計原則に従う必要があります: 設計時には容量の 20 倍を考慮し、実装時には容量の 3 倍を考慮し、展開時には容量の 1.5 倍を考慮します。プロジェクトを拡大する際の一時的な拡大による困難。

3 計画を簡素化する

パレートの法則に従う必要があり、設計の 20% が作業の 80% を実行するため、時間の 80% を設計の 20% に費やす必要があります。

製品の主要な機能は実際にはいくつかの点に集中しており、これらの点が設計されれば、残りは単なる追加機能です。したがって、このコアビジネスはシンプルで使いやすいものでなければなりません。

4 DNS クエリを削減します

異なるドメイン内のすべてのファイルは、ロード時に DNS クエリを実行する必要があります。たとえば、cnblogs.com と i.cnblogs.com は異なるドメインに属します。その後、DNS にクエリを実行すると、2 回クエリが実行されます。業務量が多い場合には一定の影響が出ます。

5 オブジェクトを可能な限り減らす

ブラウザがオブジェクトにアクセスするときにオブジェクトを読み込む必要があるため。したがって、要求されるファイルの数 (その数はブラウザーの同時読み込みの数に関係します) を減らし、いくつかのオブジェクトを可能な限りマージすることを検討できます。たとえば、アイコン ファイルを 1 つの大きな画像に結合できます。適切な数のファイルを使用すると、ブラウザーのアクセスと読み込みが高速化されます。

6 同じブランドのネットワーク機器を使用する

1つのhttpリクエストが多くの物理デバイスを通過する可能性があるため。ロードバランサー、スイッチ、ルーターなど。したがって、予期せぬ事態を避けるために、同じブランドの機器を使用するようにしてください。

配布作品

7一般的なものには、クラスタリング、負荷分散など、データベースの読み取りと書き込みの分離などが含まれます。

8つのY軸、異なるものを分割する

大規模なシステムでは、登録、購入、クエリ、クラウドディスクなど、異なる機能を分割します。待ってください

9 Z軸、似たようなものを分割します

例えば、ユーザーのレベルに応じて分割したり、ユーザーの地理的位置などに応じて分割します。

水平拡張設計

10 水平拡張計画を設計します

拡張には水平と垂直が含まれます。水平的には、アプリケーションをコピーおよびクローンし、ミニコンピューター クラスターを使用して拡張します。垂直面では、サーバーのハードウェアとネットワーク設備を改善します。

ハードウェアをアップグレードするだけで達成される垂直方向の拡張では、現実的なプレッシャーをほんの少ししか解決できないことが、多くのケースを通じてわかります。しかし、水平方向のクラスタ拡張により、自由にスケーリングを実現できます。

11 経済的なシステムを使用する

上記の原則と同様、高価なサーバーを使用しても、将来的に優れたパフォーマンスが保証されるわけではありません。通常のミニコンピュータ クラスタ拡張機能を使用する必要があります。

12スケールアウトデータセンター

ホット ステーションとコールド ステーションの構成: ホット ステーションを使用してサービスを提供し、ホット ステーションが崩壊した場合、コールド ステーションを使用してサービスを継続するなど、データセンター向けの設計ソリューションは数多くあります。

低コストで動的な通話を実現するには、複数のリアルタイム サイトを使用することをお勧めします。デメリットは、運用とメンテナンスの難易度が高くなるということです。

13 クラウド技術を設計に活用する

クラウドコンピューティングの利点は、ビジネスのピーク時に柔軟に設備を拡張できる仮想化です。また、毎日の処理では、拡張子を返します。

欠点は、仮想環境に適用されるカップリングが増加することです。物理デバイスを使用してサービスを分離すると、仮想化クラウド コンピューティングにおけるビジネス分離エラーのトラブルシューティングに特定の干渉が発生する可能性があることについては後述します。

適切なツールを使用する

14 データベースを合理的に使用する

現在、従来のリレーショナル データベース Oracle や MySQl だけでなく、MongoDB などの比較的新しい非リレーショナル データベース NoSql など、多くのデータベース バージョンが存在します。インメモリ データベース FastDB など、SSD ソリッド ステート ドライブ専用の Aerospike もあります。

ただし、選択に関しては、個人のビジネス ニーズに基づいて決定する必要があります。それはデータベースに速度やセキュリティなどが必要かどうかによって異なります。

15 ファイアウォール、ファイアウォールはどこにでもあります

ファイアウォールは、一部の無効なアクセスを傍受し、フィルタリングできます。通常、一部の CSS、静的ファイル、画像、JS などはファイアウォールでは使用されませんが、重要なビジネスに個人情報が関係する場合に使用されます。適切に設計されたファイアウォールは、Web サイトのパフォーマンスにも一定の影響を与えます。

16 ログファイルを積極的に活用する

さまざまなログやツールを活用して、ビジネスをリアルタイムに監視します。サーバーのメモリやCPUを監視するだけでなく、ビジネスデータも監視します。たとえば、splunk (ログの収集、保存、検索、およびグラフィック表示を提供します)。

繰り返しの作業はしないでください

17 やった作業をすぐに確認しないでください

例えば、データを書き込んだばかりであれば、すぐに読み込まないでください。ただし、一部の顧客は、データが完全であり、失われないことを確認する必要があります。ただし、ログなどに記録される可能性があり、書き込んでから確認するこの方法は推奨しません。

18 リダイレクトを停止します

リダイレクトは一定量の遅延とコンピューティングリソースを消費します。可能な限り避けるべきです

19 タイミング制約の緩和

ほとんどのリレーショナルデータベースはACIDプロパティに注意を払うため、拡張時に特定の問題が発生します。したがって、特定のビジネスのタイミング制約を適切に緩和すると、Web サイトのパフォーマンスを向上させることができます。

例えば、あるウェブサイトでホテルを予約する場合、ユーザーは予約後ホテルのレビューを待つことになります。たとえば、特定の口座でお金を引き出す場合、時間範囲が確認されます。これはタイミング制約を拡張し、Web サイトのパフォーマンスとトランザクションのセキュリティを向上させるためです。

キャッシュを積極的に活用する

20 CDN を活用する

CDN を利用して顧客データやコンテンツを保存できます。一般的なプロセスでは、ユーザーが Web サイトにアクセスすると、CDN サーバーにアクセスし、CDN が DNS クエリを実行して、ユーザーのリクエストをさまざまなサーバーに割り当てます。このサービスを提供する CDN サービス プロバイダーは数多くあります。

21 有効期限ヘッダーを使用する

オブジェクトリクエストを減らすために、さまざまなオブジェクトタイプに有効期限ヘッダーを使用します。共通の HTTP 対応属性は次のとおりです: public no-cahe max-age など。

22 Ajax 呼び出しのキャッシュ

HTTP ヘッダー Last-Modified Cache-Control Expires およびその他の属性を正しく変更します。

23 ページキャッシュを使用する

以前の冬のリクエストに応答し、Web サーバーの負荷を軽減するためにキャッシュします。

24 アプリケーションキャッシュを活用する

例えば、特定の特別なユーザーのリクエストデータをキャッシュします。

25 オブジェクトキャッシュの活用

使用するデータオブジェクトの繰り返しクエリに適しています。たとえば、ショッピング Web サイトは売れ筋商品データをキャッシュします。

26 オブジェクトキャッシュを独自のレイヤーに配置します

拡張とメンテナンスを容易にするために、別のキャッシュレイヤーを使用します。

失敗から学ぶ

27 アクティブラーニング

企業に学習する雰囲気があって初めて、より良い製品を生み出すことができるのです。学習内容は、お客様のビジネス知識もあれば、技術分野や運用保守分野も含まれます。

28 エラーを見つけるためにQAに依存しないでください

テスターや品質保証担当者を雇用する最大の目的は、製品の正しさを検出することです。開発者はコードの正確さに常に注意を払う必要がなく、テストを QA に任せることができるため、コストが削減され、開発速度が向上します。

しかし、QA は問題を発見することのみを担当します。問題を回避する方法は開発者に依存します。

29 ロールバックのないデザインは失敗したデザインです

ここでいうロールバックとは、プロダクトリリースのロールバックを指します。特定のバージョンでバグが発生した場合は、以前に実行可能なバージョンを提供する必要がある場合があります。現時点でロールバックがない場合は、製品を提供できません。

継続的インテグレーションに関する関連コンテンツを学習することをお勧めします。

30 失敗について話し合い、そこから学びましょう

同じ問題で二度失敗してはいけません それぞれの失敗を要約することが不可欠です。

データベースの原則

リレーショナル データベースの ACID プロパティ:

原子性: トランザクションは完全に実行されるか、まったく実行されないかのいずれかです。

一貫性: トランザクションの開始時と終了時にすべてのデータの状態が一貫している必要があります。

分離: トランザクションのパフォーマンスは、データベース上のトランザクションの唯一の操作です。

永続性: トランザクションは完了し、操作は変更できません。

31 コストのかかる関係に注意してください

開発が始まると、特定の列を追加すると非常にコストがかかる可能性があり、設計テーブルの構造を改善する必要があります。

32 正しいデータベースロックを使用する

データベースには、暗黙的ロック、明示的ロック、行ロック、ページロック、範囲ロック、テーブルロック、データベースロックなど、多くのロックの概念があります。

ロックを不合理に使用すると、ウェブサイトのスループットに影響します。

33 多段階提出は使用しないでください

例えば、最初に投票し、次に提出するという2段階の提出。これにより、コミット トランザクションが完了するまで他の操作を実行できないため、スケーラビリティが低下します。

34 select を update に使用しないでください

FOR UPDATE 句により行がロックされ、トランザクション処理の速度が低下するためです。

35 すべてのデータを選択しないでください

たとえば、select * from xxx;

このアプローチの最初の理由は、データの拡張が許可されていないことです。たとえば、もともと 4 つのデータ列があり、業務処理コードは直接記述されます。データの列を追加するとエラーが発生し、さらに不要なデータがクエリされます。

Or inset into xxx names(xxxx);

これはカラム情報が一致しない場合もエラーになります。

フォールトトレラント設計と障害制御

36 「スイムレーン」を使用して障害を分離する

コンテナ、クラスター、プール、シャード、スイムレーンなど、サービスとデータを分割する方法はたくさんあります。スイム レーンとは、各ビジネスが独自のドメインを持ち、スイム レーンを越えて呼び出すことができないことを意味します。

37 単一点障害を信頼しないでください

システム全体がこのモジュールのみを使用する場合、単一点モードで設計されたシステムが多くあり、単一点障害が発生するとシステム全体が崩壊します。

38 システムの直列接続を避ける

例えば、システムは多くのコンポーネントで構成されており、各コンポーネントのセキュリティは 3 つのコンポーネントが直列に接続されている場合、システム全体の可用性は 99.7% になります。

39 機能を有効/無効にできることを確認してください

一部の共有ライブラリやサードパーティサービスについては、機能を有効または無効にする必要があります。

ステートを回避または分散する

40 ステートレスを実現するよう努める

ステートを実装するとスケーラビリティが制限され、コストが増加する

41 ブラウザ側のセッションを可能な限り維持する

一方ではサーバーの負荷を軽減し、他方ではあらゆるリクエストをあらゆるサーバーに送信できます。

42 分散キャッシュを使用してステータスを保存する

拡張を容易にするために独立したキャッシュ層を使用します。 memcached などの分散キャッシュ ソリューションが多数あります。

非同期通信とメッセージバス

43 可能な限り非同期通信を使用する

非同期通信により、各サービスやレイヤー間の独立性が確保できるため、システムの拡張性の向上や結合の低減が容易になります。

44 メッセージバスを拡張できることを確認してください

Y軸またはZ軸拡張、つまりビジネスニーズと機能に応じて拡張するようにしてください。単純なコピーまたはクローン作成では、各メッセージ サブスクライバーのリスナーの数が増加するためです。ビジネスの分離に従って、ビジネスのプレッシャーを分離することができます。

45 メッセージバスの過密を避ける

メッセージのコストと値を比較検討します。

その他の原則

46 サードパーティのソリューション拡張機能は慎重に使用する

企業が問題を抱えている場合、緊急の問題を解決するためにサードパーティを探す必要があります。しかし、これは長期的な解決策ではありません。ソリューションプロバイダーには多くの顧客がおり、あなたの危機は彼らの危機ではないため、重要な瞬間にその任務を遂行することは不可能です。したがって、企業は依然としてある程度のコントロールを持っている必要があります（この言葉は本当に高いです！）。

47 消去、アーカイブ、費用対効果の高いストレージ

不要なデータがある場合は、定期的に削除する必要があります。価値の低い一部のデータは定期的にアーカイブされ、直接削除されます。一部の貴重なデータはバックアップし、すぐにアクセスする必要があります。

48 トランザクション処理におけるビジネスインテリジェンスを削除する

製品の拡張性を向上させるために、製品システムをビジネスシステムから分離する必要があります。

事業拡大時にシステムアーキテクチャによる制約を受けないようにする。

49 監視可能なアプリケーションを設計する

回答を確実にするために、グローバルな監視戦略を設計する必要があります

「問題は発生しましたか?」

「問題はどこで発生しましたか?」

「どのような問題が発生しましたか?」

問題は発生しますか? 「

」「自動的に修復できますか?」

シンプルで優れたアーキテクチャは小さく洗練されている アーキテクチャの解決をオープンソースだけに依存すると、問題は解決してもアプリケーションが肥大化してしまう。