System Design Trainerとは？
System Design Trainerは、システム設計面接の練習に使えるインタラクティブなホワイトボードです。シナリオを選択し、AWSまたはAzureのコンポーネントをキャンバスにドラッグして、アーキテクチャとして接続し、決定論的なキャパシティシミュレーションを実行できます。
シミュレーターは、各コンポーネントがサポートできるトラフィック量を推定し、システムのボトルネックを特定して、アーキテクチャ上のリスクを強調表示します。設計が完成したら、キャパシティ計算だけでは判断できないスケーラビリティ、信頼性、データ設計、記述した説明などの選択をJevが評価できます。
主な機能
- インタラクティブなアーキテクチャキャンバス： ホワイトボードは、
@xyflow/reactを通じてReact Flowで構築されています。 - 体系的な練習： 4つの章にわたる15のレベルが用意されています。
- ライブキャパシティモデリング： 各ノードに使用率と、サポート可能なユーザー数の推定値が表示されます。
- アーキテクチャ診断： シミュレーターは、単一障害点、ロードバランサーの不足、クライアントとデータベースの直接接続を検出します。
- コストと可用性の推定： スループット計算に加えて、追加の指標を提供します。
- 面接官形式の評価： Jevはスケーラビリティ、信頼性、データ設計、記述した説明を採点し、次に改善すべき点を提案します。
- カスタムテクノロジー： Kafka、MongoDB、NGINXなどのテクノロジーを入力できます。Jevはそれらのアーキテクチャ上の役割を分類し、アプリケーションがキャパシティプロファイルを割り当てられるようにします。
- ローカルでの進捗管理： 設計とシナリオの進捗はブラウザーに保存されます。
- フリープレイ： 体系化されたレベル以外でも、自由に使えるホワイトボードを利用できます。
プロジェクトのインストールと実行
1. 依存関係をインストールする
リポジトリをクローンまたはダウンロードし、ターミナルでそのディレクトリを開いて、npmの依存関係をインストールします。
npm install2. ローカル環境ファイルを作成する
同梱されている環境テンプレートを.env.localにコピーします。
cp .env.example .env.local3. Jevを設定する
実際のJevの回答を受け取るには、.env.localにTYPESAFE_API_KEYの値を追加します。Jevは@typesafe-ai/sdkを使用してlib/server/jev.tsに実装されています。
APIキーがなくてもアプリケーションは実行できます。その場合、Jevの回答は明確にラベル付けされたモックにフォールバックするため、外部評価なしでワークフローの残りの部分を試すことができます。
4. 開発サーバーを起動する
npm run devトレーナーを使い始めるには、開発サーバーが表示するローカルアドレスを開きます。
最初のシステム設計演習を完了する
- プロンプトを選択する。 100万人のユーザー向けインフラの設計など、シナリオを選択します。各シナリオには、固定されたユーザー数と要件が設定されています。
- 目標を読む。 各レベルには必須目標とオプションのボーナス目標があり、設計を実行したときにチェックされます。
- クラウドコンポーネントを追加する。 適切なAWSまたはAzureのコンポーネントをホワイトボードにドラッグします。
- アーキテクチャを接続する。 シナリオに応じて、クライアント、ネットワークコンポーネント、アプリケーションサービス、キャッシュ、キュー、データベースの間にリクエストパスとデータパスを作成します。
- 設計を実行する。 使用率、サポート可能なユーザー数の推定値、可用性、コスト、アーキテクチャの警告を確認します。
- ボトルネックを解消する。 負荷の高いコンポーネントや構造上の警告をもとに設計を更新し、もう一度実行します。
- Jevにフィードバックを依頼する。 準備ができたら、設計と記述した説明を送信して評価を受けます。
レベルのスコアリング方法
必須目標をすべて達成すると星を1つ獲得できます。ボーナス目標を1つ達成するごとに、星をもう1つ獲得できます。星はXPを付与し、ランクに反映されます。進捗はブラウザーに保持されます。
第4章では、Azure Architecture Centerのリファレンスアーキテクチャを再構築します。これらのレベルのいずれかをクリアすると、トレーナーから元のアーキテクチャへのリンクが表示されます。
キャパシティモデルを理解する
キャパシティエンジンはlib/simulate.tsにあります。これは決定論的に動作し、AIは使用しません。ピーク負荷は、次の関係式を使ってシナリオから算出されます。
DAU × 1日あたりのリクエスト数 ÷ 86,400 × ピーク係数モデルはこの負荷を読み取りと書き込みに分け、接続されたグラフを通じてUsersノードから伝播させます。
一般的なコンポーネントがトラフィックに与える影響
- CDN： シナリオでエッジキャッシュ可能と指定されたトラフィックの一部を吸収します。
- キャッシュ： ヒット率に応じて読み取りを吸収します。モデルは、兄弟配置によるキャッシュアサイドとインライン配置の両方をサポートします。
- キュー： 書き込みを同期パスから切り離し、平均リクエストレートに向けて平滑化します。
- 兄弟コンポーネント： 同じ種類のコンポーネントは負荷を均等に分割します。たとえば、2つのアプリケーショングループに接続されたロードバランサーは、それらの間でトラフィックを分散します。
- SQLデータベース： 書き込み容量は1つのプライマリによって制限されます。
- NoSQLデータベース： 書き込み容量はパーティション数に応じて拡張されます。
各ノードは、利用率と、supports ~N users（約N人のユーザーをサポート）という推定値を報告します。この推定値は、シナリオのユーザー数を利用率で割って算出されます。システム全体の容量は、サポート可能ユーザー数の推定値が最も低いボトルネックによって決まります。
設計反復の例
すべてのクライアントトラフィックを1つのアプリケーションコンポーネントに直接送り、そこからデータベースへ送る設計を考えてみましょう。シミュレーションを実行すると、信頼性に関する警告とともに、アプリケーションまたはデータベースがボトルネックとして明らかになる場合があります。
その後、適切な分散、キャッシュ、非同期処理、またはデータコンポーネントを追加してアーキテクチャを見直せます。たとえば、ロードバランサーの背後にある同等のアプリケーショングループでアプリケーショントラフィックを分散し、キャッシュのヒット率に応じてデータベースの読み取りを減らし、キューによって書き込みを同期処理の経路から切り離せます。変更するたびにモデルを再実行し、ボトルネックが別の場所へ移ったか確認してください。
容量の推定値が高いからといって、設計が自動的に正しいとは限りません。Jevを使って、信頼性、データ設計、スケーラビリティにおけるトレードオフと、選択の根拠を評価してください。
Jevを効果的に使う
決定論的シミュレーターは、計算した数値を事実としてJevに提供します。Jevは、スループットの計算式だけでは扱えない判断を担います。
- 評価スコア: スケーラビリティ、信頼性、データ設計、記述された説明を評価します。
- 改善項目の選択: 次に改善すべき対象を選択します。
- チェックリストの判断: シナリオのチェックリスト項目ごとに1つのNoulを生成します。
- カスタムコンポーネントの分類: 入力したテクノロジーにアーキテクチャ上の役割を割り当て、トレーナーが対応する容量プロファイルを適用できるようにします。
より有用なフィードバックを得るには、記述する説明を具体的にしてください。トラフィックの流れ、スケーリングの前提、障害対応、読み取りと書き込みのパターン、そして各主要コンポーネントを配置する理由を説明します。
高度なヒント
すべてのコンポーネントではなく、ボトルネックを最適化する
システムがサポートできるユーザー数は、制約となるコンポーネントの上限までです。まず、サポート可能ユーザー数の推定値が最も低いノードから着手してください。設計を変更した後は、ボトルネックを解消したことで別のボトルネックが明らかになる可能性があるため、シミュレーションを再実行します。
同期処理と非同期処理の経路を比較する
キューは書き込みを同期リクエストの経路から切り離し、平均負荷に合わせて平準化します。シナリオで非同期処理が許可されている場合は、モデルを使って直接書き込む経路とキューを介するアーキテクチャを比較してください。
キャッシュの配置を試す
シミュレーターは、cache-asideパターンで兄弟コンポーネントとして使われるキャッシュと、インラインに配置されたキャッシュを認識します。配置とヒット率が下流の読み取りトラフィックに与える影響を確認してください。
構造上の警告に注意する
利用率だけに注目しないでください。単一障害点、ロードバランサーの欠落、クライアントからデータベースへの直接接続がないか確認します。これらの警告は、実効容量が十分な場合でも、信頼性やセキュリティに関する設計上の弱点を明らかにすることがあります。
カタログの数値の出典を確認する
容量、可用性、コストのデータはlib/catalog.tsで定義されています。各数値には出典が含まれており、コンポーネントプロパティカードに表示されます。値は、公式上限、公式SLA、ベンダーベンチマーク、仮定、または公開された上限がないサービスに分類されています。
- 公式上限: アカウントレベルのリクエストスロットルなど、公開されているAWSまたはAzureのクォータ。
- 公式SLA: ベンダーが約束する月間稼働率。
- ベンダーベンチマーク: 公開された性能値。ただし、保証値ではありません。
- 仮定: ベンダーの数値がない場合にモデル化された値。このプロジェクトでは、すべてのコストも仮定として扱います。
- 公開された上限なし: 独立してスケールするとしてモデル化されたサービス。そのため、ボトルネックにはなりません。
READMEには、これらの出典を最後に確認したのは2026年9月であると記載されています。クラウドのクォータは変更されるうえ、多くは引き上げ可能なので、シミュレーション結果は保証ではなく推定値として扱ってください。
シナリオを調べる、または拡張する
シナリオの定義はlib/scenarios.tsに保存され、15個の構造化されたレベルはlib/levels.tsで定義されています。練習用プロンプトを追加する場合は、lib/scenarios.tsにシナリオを追加してください。
ブラウザーでの永続化を理解する
キャンバスの設計はシナリオごとにlocalStorageへ保存され、進捗もブラウザーに保持されます。ブラウザーのストレージは、現在のブラウザープロファイルと環境に固有であることに注意してください。
まとめ
System Design Trainerは、インタラクティブなクラウドアーキテクチャキャンバス、決定論的な容量モデリング、構造化された目標、Jevによる設計レビューを組み合わせています。シミュレーターで測定可能な挙動を検証し、警告で構造上の問題を見つけ、Jevでシステム設計面接に求められる論理展開とトレードオフ分析を改善してください。