非常に短い答え
その鍵は建築です。方法は、分割して征服することです。アプローチはリラックスすることです。
もう少し長い答え
建築
建物の最も重要なコンポーネントは、そのアーキテクチャです。壁と床、窓と天井、つまり構造自体の要素で空間が形成される方法。建築家の目的は、壁を設計することではありません。彼は実際の仕事の副次的な部分としてそれらを設計します。つまり、壁によって形成される空間を設計します。私たちは壁を持つために建物を建てるのではなく、内部に空間を持つために建物を建てます。
私たちはまず、ソフトウェアに求める機能を設計します。次に、それを可能にするための詳細、つまり製品の構築について説明します。私たちが使用するテクノロジーは主なものではなく、壁であり、私たちが本当に求めているのは空間そのものです。
構築しているソフトウェアに何を求めているかをよく理解することで、エンジニアリングははるかに簡単になり、ほぼ自動化されたプロセスになります。技術的な問題は、よく理解された定義と幸いなことに明白な解決策とともに現れ始めます。
分割統治
優れたアーキテクチャの非常に重要な尺度の 1 つは、ソリューションのコンポーネントを明確に定義することです。全体像のこれらのコンポーネントを個別に見ることができれば、作業を別々の部分に分割できます。その後、別々のものを構築して連携させることができます。
リラックス
たぶん、このタイトルは、テキストにユーモアを加えようとしているように聞こえるかもしれません。いいえ、誤解しないでください。優れたアーキテクチャがあれば、Web サーバー、データベース サーバー、エンジニア、顧客、ユーザー、その他の世界もリラックスできます。そうでない場合は、アーキテクチャの作業に戻る必要があります。
は？
ねえ、私はここで何について話しているのですか？それはいくつかの段落と 3 つのタイトルであり、ソフトウェア以外のソフトウェア用語は 1 つも使用しませんでした。このような抽象的なおしゃべりは、一日中何もすることがなく、怠惰に歩き回り、話し、話し、話している人のためのものです... 私たちはソフトウェアの人々であり、これを行う時間がありません。ねえ、ハサン、短くして..！
わかりました、試してみます。しかし、まずはリラックスしましょう...それから、いくつかの実際の例を見てみましょう。
例
専門家および個人向けの Web パブリッシング サービスを開発しているとしましょう。すべてのクライアントは、当社のシステムで実行される独自の Web サイトを持ちます。これらの Web サイトは、訪問者の数が非常に少ない通常の個人の Web サイトである場合もあれば、当社のビジネスが運が良ければ、他のクライアントの一部が NY Times のような大規模な出版物である場合もあります。
2 種類のスケーラビリティの問題を解決する必要があります。1 つは、ますます多くのクライアントを持ち、より多くの Web サイトを運営するようになるにつれて、ビジネスとシステムをスケーリングすることです。これは、2 つ目の問題に比べて非常に簡単な問題です。2 つ目の問題は、単一の Web サイトをスケーリングして、より多くの訪問者、より多くのデータ、このデータで実行するアプリケーションを増やしていくというものです。
「どのようにスケーリングするか」という問題を「どのように分割するか」と書き直して、解をより明確に見ることができます。何かを小さな断片に分割できれば、それらの断片を実行するためのリソースを追加して水平方向に拡張することで、スケーリングできます。
データと、そのデータを処理するアプリケーションが用意されます。1 つのデータベース サーバーと 1 つの Web サーバーがあり、これをスケーラブルにしようとしているとします。
サービスのために実行する Web サーバーについて考えます。これらのマシンにデータを保持しない場合、それらは一般的で同等のコンポーネントになり、このデータを他の世界とやり取りするデータ バックエンドの小さなクライアントになります。Web サーバーを軽く、愚かで、空にしておくことで、増え続けるリクエストを簡単に処理できるようにすることができます。
わかりました、Web サーバーをただのばかげたプロキシに変えることは、最も賢明な考えではありません。私たちは何かをする必要があり、アプリケーションを実行する必要があります。また、私たちのアーキテクチャでは Web サーバーが最も簡単に増殖できるため、これらの Web サーバーでできるだけ多くのことを実行したいと考えています。この難しい問題については、以下の「Dividing Smarter」というタイトルで続けます。その前に、現在検討中のアーキテクチャの種類と、それがどのように拡張可能かを見てみましょう。
ロード バランサーを使用して、多くの Web サーバーを並行して実行し、DNS を使用して (要求がシステムに到達する前であっても) 複数のロード バランサーに多くの Web サイトをグループに分割します。たとえば、a.com、b.com、c.com からロード バランサー 1、a-very-big-website.com からロード バランサー 2、... ロード バランサーの各グループ、一連の Web サーバー、およびデータベースサーバーは、システム内に別の宇宙を作ります。今では、数百万の Web サイトを所有し、これらの個別のユニバースを無制限に追加することでシステムを拡張できます。当社のマーケティング部門が提供できる数の Web サイトで、多くのクライアントにサービスを提供できます。最初の問題はすでに解決されています。大きな大きなウェブサイトを運営するのはどうですか？
分割をよりスマートに
もちろん、個別の Web サイトの場合のように、単一の Web サイトを個別の宇宙に分割することはできません。しかし、これは私たちが何も分割できないという意味ではありません。分裂と征服を続けていきます。これを行うには、解決する問題を詳しく調べる必要があります。
ウェブサイトとは？Web ページ、ファイルなどのサポート コンテンツ、画像cssやjsビデオ ファイルなどのマルチメディア コンテンツ、データ、大量のデータ。クラウド コンピューティング システムが提供する CDN と優れたストレージ サービスのおかげで、静的ファイルはもはや私たちの問題の重要な部分ではありません...
私たちが実際に行っているのは、Web ページのレンダリングです。上記では、Web サーバーを、データベース バックエンドへの非常に軽量で汎用的なインターフェイスと考えていました。ユニバースでアプリケーションを実行する方法はまだ解決していません。今こそそれを行う時です。
当社のシステムへのすべてのリクエストはサイトに届き、そのサイトで実行されているアプリケーションによって処理されます。Web サーバーが最初に行うことは、リクエストがどのサイトに属しているかを判断することです。私たちのデータベース サーバーでは、ホスト名とサイトを照合するテーブルを保持しています。新しいクライアントの Web サイトがあるたびに、このサイトと一致するように、このテーブルに 1 つ以上のドメインを追加します。Web サーバーへのすべてのリクエストで、データベース サーバーにクエリを実行し、ロードするサイトを決定します。良い？
いいえ、良くありません。それはひどいです。なんで？
大きな数、小さな数
少数のウェブサイトがあります。しかし、非常に多くのリクエストがあります。ユニバース上の Web サイトの数は、ブログ サイトのコメントなどの他の種類のデータよりも頻繁に変化しません。このテーブルは、確立されたユニバースで 1 日に数回更新されます。このような小さな (数千のレコード、小さな!) データベースに対して、すべてのリクエストに対して 1 日中何度もクエリを実行するのは賢明ではありません。これを行う賢明な方法は、このテーブルのコピーを Web サーバーに保持し、更新されたときにのみ更新することです。サイト リストが更新されたことをどのように知ることができますか? テーブルのバージョン番号として番号を持つ行を保持できます。更新ごとに、この数を増やすことができます。または、最終更新のタイム スタンプを保持することもできます。Web サーバーは、データベース サーバーでこの番号を確認し、それをローカルのメモリ内バージョンと比較できます。テーブルが新しい場合、ローカルのメモリ内コピーを上書きして、データを再度プルします。このようにして、数千のクエリを小さな数に減らすことができます。大きな数、小さな数...
この時点で、建物に使用する材料が重要になり始めました。どの言語、どのような種類のプラットフォームとデータベース システムなどです。現在、それらはアーキテクチャの動作を改善または悪化させる可能性があるため、重要です。たとえば、テーブルの更新の場合、データベース サーバーは更新について Web サーバーに通知するメカニズムを持つことができます。このようにして、さらに進んで、ドメイン サイト テーブルの不要なクエリを完全に削除します。したがって、選択したシステムがそのようなメカニズムを提供する場合、これらのシステムがアーキテクチャに適していることを意味します。
ソフトウェアに何を求めているかをよく理解していれば、スマートな方法で物事を分割することが自動的に行われます。データベース サーバーのスケーリングは非常に困難です。一緒にいるにはデータが必要なので。Web サーバーの数を増やすことで、制限なく水平方向にスケーリングします。ただし、データベース サーバーの場合、これは適用されません。データベースサーバーはデータへのアクセスを維持する必要があり、マシンには効率的な方法でスケーリングできない制限があります。
すべてのデータベース システムは、シャーディングやシェアード ナッシング アーキテクチャなどのスケーリング方法を提供します。これらを使用しなければならない場合があります。しかし、フォーラム、ブログ、および他の場所で人々が経験を共有しているのを見ると、私見ですが、人々はこれらをあまりにも積極的かつ間違って使用しています. 彼らはデータベースをどんどん大きくしていき、「スケールする時が来ました。いくつかのシャードを追加しましょう」と言いました。これらすべてのアプリケーションの 99% はブラインド ランニングです。人々は問題をソフトウェアに任せ、魔法のように解決されることを期待します。残念ながら、彼らは魔法がないことにすぐに気付きます。
数値に注意して、盲目的な解決策から身を守る必要があります。大きな数、小さな数です。また、システムの内部の仕組みを理解し、材料を多用するのではなく、建築を通じて問題を解決することによっても。
ここにアーキテクチャ ソリューションがあります: Architected Solution ( Calatravaによる)。
優れたアーキテクチャではなく、材料に依存するその他のソリューションを次に示します。[ブラインドラン ソリューション 1 ]、[ブラインドラン ソリューション 2 ]
違いは自分で判断してください。
データベース サーバーをどのようにスケーリングできますか? テーブルを途中でやみくもに分割する代わりに、データについて再考することができます。ユーザー アカウント情報をサイト テンプレートから分離できますか? もちろん、なぜですか？古いデータと新しいデータ用に別のデータベース サーバーを保持することはできますか? 特に検索機能を考慮すると、もう少し難しいです。しかし、なぜですか？
やみくもにではなく、賢く分けましょう！もう分割できない場合があることは承知しています。でもさあ、私たちの何人が Google や Facebook で働いているでしょうか?
-- やあ、非常に大きなデータ セットがあり、実行すると...
――シュッ。まず、戻ってデータセットを確認します。それは本当に大きなデータセットである必要がありますか?
ほとんどの場合、そうではありません。私たちはそれを認めたくないだけです...
移行方法
すべてをゼロから再構築するには時間がかかり、多くの企業では余裕がありません。より良い方法は、すべてのコンポーネントを書き直さずに現在のシステムを構築することです。代わりに、それらをコンポーネントとして分離して再定義します。これは主に分析であり、その後に小さな変更が加えられます。システム上のすべての関数呼び出しは、簡単に分岐点になる可能性があります。その時点から、システムを 2 つの部分に分けることができます。
ほんの数時間、現在のシステムを楽しく見てみるだけで、それらのピースを分割する方法について多くのアイデアが得られます。それらを分割したら、すべてを再構築して新しいシステムを少しずつ再構築するのは非常に簡単です。私が建物を持っていて、同じ土地にもっと大きな建物が必要な場合、すでにそこに住んでいるすべての人々を移動させずに新しい建物を建設するのは非常に難しい仕事です。しかし、不可能ではありません。建物ではなくソフトウェアに関しては、はるかに簡単です。そう？
リラックス
ソフトウェアです。柔らかいです。データをコピーし、テストを行い、すべてを削除し、さらに 100 万回コピーできます。アーキテクチャが適切に設計されていれば、ミスによって壊滅的な事態が発生することはありません。6 人掛けのディナー テーブルを 60 人のゲストに提供できるテーブルに変えるのは非常に困難です。しかし、ソフトウェアは...ソフトウェアであり、私たちはそのようなことを簡単に行うことができます. リラックス。
-- 上記の質問は、ほんの数段落でカバーするのが不可能な領域に触れています。質問のこの部分に基づいています。詳細に飛び込むことなく、一般的な形式で物事を言及しようとしました. 私の原則の実践的な応用例をいくつか挙げようとしましたが、この短いテキストには多くの未解決の点が残されていることを知っています。コメントでの批判や質問に感謝します。
