違いは何ですか？また、その準備方法は？ 例を見てみましょう。 例として、非常に重要なものを取り上げます。誰も実際のインタビューを求めないものです（Googleで）:)
たとえば、ライブラリを設計しましょう。 紙の本の場合、通常のもの。 以下のテキスト全体は、あなたが何ができるか、そして何をすることが重要かを大まかに示すために約1時間で座って書かれました。 混乱を許しますが、私はそう思います（したがって存在します）。
NALSDの質問：公共図書館を設計します。
まず、負荷の特性に関心があるか、または合理的な仮定を自分で行います。 これはスケーラブルなシステムに関する質問であるため、これは100万人の最小都市です。 オプションを検討する価値があります-1つの大きな建物、または地区の図書館とストレージ。 後者の方が合理的であるように思えます。 特に、都市ではなく、都市の場合。
そのため、現時点では1つの都市のシステムに焦点を当てます（いくつかの予約があれば、同様のメカニズムを多くの都市に拡張するために、より高いレベルで適用できます）。 だから、街は百万人です。 推定の便宜上、数値を丸めています-100万人の読者がいる可能性があります。 読者は、互いに独立していつでも読むことができます。 したがって、単純なポアソン過程として把握できます。 しかし、「実行中」のカウントは通常は難しいので、別の簡略化手順を実行し、読者の1％が1日に1本の本を取りたいと思うようにします。 合計で、さらに計算するために、1日あたり10,000冊の本を取ります。
私たちの任務は、100万人以上の都市で、1日に10,000冊の本を発行することを可能にすることです。 現時点では、モノライブラリーまたは地区の問題はすでに解消されています（ちなみに、潜在的な読者になるためには、百万人全体が妥当な時間内にライブラリーに到達できる必要があります。そうでなければ、本を取りたいという欲求はタイムアウトによって確実に落ちます）。 そのため、各ローカルライブラリの容量を評価する必要があります。 人口密度と到達可能性を考慮してこれを行うことは正しいことですが、これはシステム自体に大きな影響を与えないため、計算を簡単にするために、それらを均等に配置すると仮定します。 しかし、これはまだそれらを共有する方法を意味しません。 明らかに、1冊の本で10,000の図書館を街中に均等に配置することは意味をなさないため、意味を理解する必要があります。 次のレベルに進みます。
したがって、1つのライブラリ。 それが理にかなっているために、来る人のほとんどは彼らが必要とする本を見つけなければなりません。 これは、最も人気のあるクエリの記録と予測を保持し、これらの本を準備しておく必要があることを意味します。 次に、品揃えを原則的に維持する必要があります。 ちなみに、ローカルライブラリには少なくとも1000個のアイテムがあり、それらの最上部には多数のコピーがあり、最上部のものが多く、後部のものは少ないはずです。 ライブラリの平均的な本は3日から2週間で読まれます（実際、特性は本によって異なります。ここでは別の分析が必要です）。 つまり、撮影した本は約1週間不足しているため、上位の本は1週間在庫が必要です（その後、返品から回復し始めます）。
平均インフレーション係数を6としましょう。したがって、ストレージ容量は6,000冊から始まります。 「少ない」とは、これが小さなトップにすぎないことを意味しますが、これは場合によっては依然として役立ちます（たとえば、子供用プレイルーム近くのスーパーマーケットに「トワイライト」のある島）が、今は外に置いておきます。
「平衡」状態では、彼らは戻って、ほぼ均等に1日かかり、プラスまたはマイナスのばらつきがありますが、リターンのピーク数の増加を受け入れる能力が依然として必要です（たとえば、休日やファッションの変更などの外部同期のため）。 そうです-シミュレートします。 しかし、ここと今、バッファーとして3分の1を使用します。 合計で、発行可能な6,000冊の書籍と、さらに2,000冊の予備の書籍をサポートしています。
したがって、8000冊の本を保存できるユニットが必要です。 毎日の補充は非常に高価です。つまり、1、2週間です。 2週間で6,000冊の本が返品に偏りがあり、これは1日に約300冊です。 開封時には、8,000冊すべての書籍を採点して、最初の2,000冊を最初に戻る前に発行することができます。 3日間の2000 = 1日あたり約600冊の書籍、およびバッファ= 1日あたり800冊の書籍。
帯域幅とストレージの制限を見積もりましょう。 1冊の本には、平均2センチメートルのリニアスペース、8000冊の160メートルが必要です。 垂直に4回、40メートル回転します。 さらに5メートルのラックに分割し、5メートルの長さの4つの棚からなる8つのラックを取得します。 1人の図書館員（またはロボ図書館員）が2つのラックで作業できます。1冊の本を取り出すには、届くまでに最大5秒、出て行くか本を出すには5秒、逆に5秒、合計15秒かかります。 4人の図書館員が1分間に最大約15冊の書籍、つまり倉庫から1時間に約900冊の書籍を提供します。
リクエストを処理する時間（10秒）、検索（5秒）、受信および発行システムに入る時間（2秒）=> 400本/時間を追加します。 これは、ピーク時のストレージが1時間あたり400冊の書籍を発行できることを意味します。したがって、1日あたり800冊が2営業時間で到達可能です。
今、私たちは他の特性を考慮します：4人で1時間に400冊の本を配るためには、処理ウィンドウの前の列にある待合室に100人を収容する必要があります。 つまり、エントランスグループは、双方向で1時間あたり400人を通過させる必要があります。 メインのリミッターはストレージではなく、ホールとエントランスグループの容量でさえあることがわかります。
これは、より正確な計算でストレージとホールの最適な比率を見つけることが可能になることを意味します。
したがって、ユニットを整理して、上のレベルに戻ります。 ライブラリの合計負荷は1日あたり約10,000冊と見積もられ、1ユニットを1日あたり800冊でカウントしました。つまり、12.5ユニットが必要です。 都市周辺の地理的分布により、1つまたは2つの代替ユニット（都市境界）または3-4（内部）が各リーダーに到達可能になります。これにより、トラフィックのピークや特定の位置に対する需要の増加をわずかにスムーズにできます。
また、いつでもライブラリを閉じることができます（火災、衛生検査、冷蔵庫のハンドルの塗装など）、それらの数が増えると、2つの生命が落ちる可能性が一致するため、スペアユニットが必要です5-6単位ごと。 倉庫で推定在庫を維持する場合、合計で15ユニットが必要なパフォーマンスを確保する必要があります。
推定在庫を維持するために、品揃えの約半分を週に1回または2回（上記の2つと考えていました）更新して、トレンドなどを追跡する必要があります。 つまり、各ユニットは2週間ごとに4,000冊の本を輸送およびエクスポートする必要があります。 インポートとエクスポートのたびに、これらの同じ4,000冊の本を倉庫から削除してから、他の本を保管する必要があります。 1時間あたり400冊で、品揃えの更新には最大負荷で10時間かかります。 これはまだそれほど悪くはないようですが、ここでも大量の負荷がかかると、多くのことがより速くなりますが、品揃えを維持するには集団で作業するよりも5倍かかります。
平均的な本（2cm * 20cm * 30cm）は約1.5l、つまり4000本= 6立方メートルです。 1つのガゼルに簡単に収まります。 1立方メートルの紙の重量は600 kg、つまり6立方メートルは3.6トンです。 ガゼルの積載量は1.5トンなので、3つのガゼルが必要です。 プラス1つのバックアップ。 15個のユニットがあり、2週間ごとに更新されます。均等に配分されているため、別のガゼルを追加する必要があります。
そして、これらのガゼルがどこにどこにあるのかを考える時間がありませんでしたので、関連性を失った本のサプライヤーの倉庫と荷降ろしポイントが図に表示されます...
時間が経ちました。 NALSDの質問でそんなに異常なのは何ですか？ スケーラビリティーは、大規模システム設計で使用する必要があります。 主なものは具体性です。
上記の多くの仮定と仮定を立てましたが、その後の推定はすべて以前のものに基づいています。 数字については、「正しく評価する方法」も与えようとしましたが、それを忘れることは非常に簡単です。疲れて忘れてしまいます。 説明なしにメモリから数字を続けるのはまだ非常に簡単です...しかし、設計は具体的であるため、仮定のいずれかが間違っていることが判明した場合、修正して後で簡単に数え直すことができます。
私が今思い出したように、見積もりのインタビューでは、600のディスクのIOPSを取りました。これは、最近最適化して1つのアレイで苦労したからです。_array_は600 IOPSを出しました... ：D
インタビュー中、インタビュアーはあなたの仮定を修正できます。 または、何らかの種類の制限（知らない、考えない、尋ねない、またはその場でTKの通常の変更だけを追加する）を追加します。 同時に、特定の番号のみを使用して操作しているため、これは番号の簡単な更新になります。
仮定の調整がシステムの再設計を引き起こす場合、これは設計エラーか不正確な調整のいずれかであるか、システムの適用可能性を超えており、これも現実の状況ではまれではありません。 そのような瞬間を見逃さないようにし、設計段階と調整の両方で実際に受け取った数値を評価することが重要です。
SREとして、実際のハードウェアの実際の制限の下で実際のシステムをスケーリングするという観点で考える必要があります。 少量のメモリと膨大な時間コストを交換する優れたアルゴリズムが存在する可能性があります...しかし、実際の条件では、プロセッサコアごとにペタバイトのRAMを配置することはできません。 したがって、ペタバイトのRAMがあれば、少なくとも1万個のプロセッサがあります。 または20。 または30。 そして、与えられた条件の中で、グローバルではなく、今ここで最適なものを探す必要があります。
正確な数字を覚えておく必要はありませんが、順序についてある程度知っておく必要があります。HDDには約100個、SSDには数十万個の同じIOPSがあります。 しかし、これらの数十万は、テラバイトのHDDのコストとテラバイトのSSDのコストの比が3から4分の1になっています。 そして、それはハーネスを数えていません-ラックスペース、それらのためのブレード、スイッチのポート、および請求書がペタバイトになったときにペニーになるのをやめる他のもの。
さあ、椅子に少し寄りかかり、リラックスして、サブスクリプションで新鮮な鶏の卵を供給するシステムを設計してみてください。
英語を話す同僚と共有したい場合は、 英語 （および英語ハブ ）のオプションがあります 。