このレッスンは日本語に自動翻訳されたもので、まだ人によるチェックを受けていません。表現に違和感がある場合は、英語の原文が正となります。
すべての大規模アプリケーションは、同じ基本的な構成要素から組み立てられます。面接官は、あなたが新しいテクノロジーを発明することを期待していません。彼らは、あなたが特定の問題に対して適切なコンポーネントを選択して組み合わせることを望んでいます。このレッスンでは、あらゆる設計インタビューで使用するツールキットについて説明します。
Web はその中核として、クライアントがリクエストを送信し、サーバーがリクエストを処理し、応答が戻ってくるという単純なモデルに従っています。しかし、最新のシステムは、スケール、信頼性、パフォーマンスを処理するために、これら 2 つのエンドポイントの間にレイヤーを追加します。
一般的なリクエストは、クライアント → CDN → ロード バランサー → API ゲートウェイ → アプリケーション サーバー → キャッシュ → データベースを通過する可能性があります。各レイヤーは特定の問題を解決し、各レイヤーが「いつ」必要になるかを理解することで、有力な候補者と平均的な候補者を区別します。
面接では、詳細に入る前に、必ずクライアントとサーバー間の高レベルなフローを概略的に説明することから始めます。構造化された思考を示します。
単一サーバーの容量は有限です。ロード バランサーは、次のような戦略を使用して、受信リクエストを複数のサーバーに分散します。
ロード バランサーは ヘルス チェックも実行し、異常なサーバーをプールから自動的に削除します。クラウド環境では、AWS ALB や Azure Front Door などのサービスがこれを透過的に処理します。
ソーシャル メディア フィード サービスは、書き込みよりも 10 倍多くの読み取りを受け取ります。ユーザーが同じキャッシュウォームサーバーに一貫してアクセスできるようにするのに最適な負荷分散アプローチはどれですか?
キャッシュは、頻繁にアクセスされるデータを消費者の近くに保存します。それは複数のレベルで存在します。
|レイヤー |例 |レイテンシ | |----------|-----------|----------| |ブラウザキャッシュ |静的アセット、API レスポンス | ~0ms | | CDN |画像、CSS、JS ファイル | ~10-50ms | |アプリケーションキャッシュ | Redis、Memcached | ~1-5ms | |データベースキャッシュ |クエリ結果キャッシュ | ~5-10ms |
キャッシュの無効化 は、コンピューティングにおける最も困難な問題の 1 つとして知られています。一般的な戦略には、TTL (存続時間)、ライトスルー (書き込みごとにキャッシュを更新)、キャッシュアサイド (アプリケーションがキャッシュを明示的に管理) などがあります。
Phil Karlton の有名な言葉、「コンピュータ サイエンスで難しいことは 2 つだけです。それはキャッシュの無効化と名前付けです。」は非常に広く引用されているため、システム設計の面接では事実上通過儀礼となっています。
適切なデータベースの選択は、最も影響力のある設計上の決定の 1 つです。
SQL データベース (PostgreSQL、MySQL) は、ACID トランザクション、強整合性、構造化スキーマを提供します。データに明確な関係があり、結合を伴う複雑なクエリが必要な場合に威力を発揮します。
NoSQL データベース にはいくつかの種類があります。
サインイン してディスカッションに参加
あなたは、頻繁に変更される半構造化データ (ユーザー タイプごとに異なるフィールド) を含むユーザー プロファイルを保存するシステムを設計しています。どのデータベース タイプが最も適合しますか?
すべての操作に即時応答が必要なわけではありません。メッセージ キュー (RabbitMQ、Apache Kafka、AWS SQS) はプロデューサーとコンシューマーを分離し、次のことを可能にします。
Kafka は特筆に値します。Kafka は単なるキューではなく、分散イベント ログであり、複数のコンシューマが同じイベント ストリームを独立して処理できるイベント駆動型アーキテクチャを可能にします。
|側面 |モノリス |マイクロサービス | |----------|----------|----------| |導入 |単体 |独立したサービス | |スケーリング |すべてを一緒にスケールする |個々のサービスを拡張する | |複雑さ |より簡単に始められる |運用上のオーバーヘッド | |データ |共有データベース |サービスごとのデータベース |
モノリスを開始し、必要に応じてマイクロサービスを抽出します。 ほとんどの面接官は、マイクロサービスが分散システムの複雑さ (ネットワーク障害、データの一貫性、展開のオーケストレーション) を引き起こすこと、および必ずしも正しい選択ではないことを認識している候補者を高く評価します。
Netflix が数年かけてモノリスからマイクロサービスに移行したことは有名です。しかし、数十億のトランザクションを処理する Shopify は依然としてモジュール式のモノリスを実行しています。特定の企業にとって、一方のアプローチが他方よりも優れている要因は何でしょうか?
CAP 定理では、分散システムは 3 つのうち 2 のプロパティのみを同時に保証できると述べています。
分散システムではネットワークの分断が避けられないため、実際の選択は CP (可用性よりも一貫性) か AP (一貫性よりも可用性) のどちらかになります。
あなたは、不正な残高が経済的損失を引き起こす可能性がある銀行取引システムを設計しています。どの CAP トレードオフを優先する必要がありますか?
システム設計の面接に入るときは、次の構成に従ってください。
Instagram、Uber、Spotify など、あなたが毎日使用しているシステムについて考えてみましょう。このレッスンで使用されている可能性のある構成要素を特定できますか?ロードバランサーはどこに配置されますか?何がキャッシュされるのでしょうか?どのデータベース タイプがそのデータ モデルに適合しますか?
次は、これらの基本を適用して URL 短縮ツールを最初から設計します。