Webアプリケーションのスケーラブルな設計
これがこの質問に対して間違ったスタック交換サイトである場合は、申し訳ありません。これを別の場所で尋ねるべきかどうか教えてください。
最近インタビューに行ってきました。インタビューはシニアフルスタックエンジニアのポジション向けでした。そのインタビューで、私は質問されました：
スケーラブルなWebアプリケーションをどのように設計しますか
質問はスケーラビリティに焦点を合わせましたが、それは現代の応答性の高いアプリケーションという意味で意図されました。
答えはなるべく忠実に再現していきます。
私の回答は、いくつかの良い点はあるものの、彼らが期待するものとは正確に一致しておらず、上級レベルではなく中級レベルのポジションに応募する場合に期待する回答に近いと言われました。
私の答えがどのように改善されるのか興味があります。
答え：
さて、考慮すべき3つの事柄、フロントエンド、バックエンド、データベースがあります。私は主にReact、DjangoおよびMongoDBの経験があるため、これらのテクノロジーを想定します。
フロントエンドから始めて、JavaScriptバンドルを含むhtmlファイルを提供します。バンドルのサイズを最小化し、できるだけ速くそれを取得したいので、なしで実行できるライブラリがあるか、部分的にしかインポートできないライブラリがあるかどうかを確認します。たとえば、loadashは部分的なインポートを許可し、ライブラリ全体をバンドルすることを回避します。また、バックエンドに対して行うリクエストの数と、一度に取得する情報の量にも注意が必要です。アイテムの非常に長いリストを表示する必要がある場合は、一度にすべてのデータをフェッチするのではなく、無限スクローラー戦略を採用します。私が見るもう1つのことは、domツリーが再レンダリングされるときに実行する計算の数を最小限にするために、rselectのようなものを使用することです。
バックエンドに移動すると、RESTfulアーキテクチャーになります。私たちのDjangoビューはさまざまなメソッドとエンドポイントにマッピングされ、それらの役割はデータベースとの通信です。私はより低いレベルのpymongoではなくmongoengineを使用します。1つだけにすることはできませんでしたこれをロードバランサーの下にデプロイします。もう1つ確実なことは、すべてをhttps経由で提供することです。セキュリティを向上させるために、すべてのhttpトラフィックをhttpsにリダイレクトします。
データベースの場合、水平方向にスケーリングできるようにするために、クラスターが必要になります。パフォーマンスを最適化するために、データベースにインデックスを付けます。さらに、負荷をより均等に分散するために、読み取りと書き込みに異なるマシンを使用するようにしました。
スタックの3つのコンポーネントのそれぞれに関するスケーリングに関して最も重要なことは何ですか？
スケーリング以外に、最新のWebアプリケーションの他の機能は何ですか？
この質問に対する完全で完全な答えは何ですか？
私の見解では、あなたはいくつかの詳細に入るのが速すぎます。私は答えを次のように概説します：
- スケーラビリティの必要性に言及し、これはどういう意味ですか？必要に応じてサイトを利用する人を増やす？結果として、応答時間など（いわゆる品質）は（大幅に）変更されるべきではありませんか？これは、スケーラブルなアーキテクチャを構築することを意味します。
- スケーラブルなアーキテクチャーとは、望ましい認識された品質属性（上記の応答時間など）を維持できるように要素（ソフトウェア、サーバー）を追加できることを意味します。
- 次に、1..nレイヤーとレイヤーあたり1..mサーバーのスケーラブルなアーキテクチャを示します。 （一例として参照 https://www.guru99.com/n-tier-architecture-system-concepts-tips.html
- このアーキテクチャへのより大きなクエリの影響、アクセスのピークの影響などを示す必要があります
- 最後に、あなたが言及しているような例に行くことができます。通常、ポイント4を完了すると、どこかで詳細を尋ねられます。
入力の質問「スケーラブルなWebアプリケーションをどのように設計しますか」に関連して-応答性はスケーラビリティとはあまり関係がありません。言及できるのは、Webサーバーから結果を動的にロードするクライアント側のライブラリの使用法です。