システムデザインの対策準備を第三章を見てください。InterviewCatではシステムデザインに大事なコンセプトを紹介しその実用例を述べていきます。
以下の内容について説明していきます。
- システムデザインのパターン
- APIデザイン
- 覚えておきたい数字
- Cache
- Replication
- Sharding
- Retry
- Circuit Breaker (サーキットブレーカー)
- Message queue
- データベース：SQL vs noSQL
- リーダー選挙 Leader election
- 全文検索について
- 位置検索
- HTTP Polling vs HTTP Long Polling vs WebSockets
- 実用例
- 質問例
システムデザインのパターン
APIデザイン
最初はAPIデザインから入るので
- CRUD（Create, Read, Update, Delete)の役割
- ステータスコード：200 OK, 404 Not Found, 500 Internal Server Errorなど
- リクエストとレスポンスのフォーマット：JSONかXMLかCSVなど
- URI（Uniform Resource IdentifierIの設計
覚えておきたい数字
Availabilityについて
Availability（可用性）は、サービスが利用可能な時間の割合であるアップタイム（またはダウンタイム）で定量化されることが多い。可用性は一般的に9の数で表され、99.99%の可用性を持つサービスは、9が4つあると表現されます。
Availability（可用性）はfault tolerance（耐障害性）とresiliency回復力と似ているところがあるが詳しくはこちらの「耐障害性と回復力について教えてください」を参考にしてください。
Availability level | Allowed unavailability window |
per year | |
90% | 36.5 days |
95% | 18.25 days |
99% | 3.65 days |
99.5% | 1.83 days |
99.9% | 8.76 hours |
99.95% | 4.38 hours |
99.99% | 52.6 minutes |
99.999% | 5.26 minutes |
SLAを99.99%にするとサービスを止められる時間が年に1時間もないのでデータベースのメンテナンスなどしたいときどうしてもzero downtimeを考えるのがきついのでサービスの種類によってゆるくしていくのが一般的です。例えばAmazon S3 (Standard)のSLAは99.9%以下としています。
Latency について
execute typical instruction | 1/1,000,000,000 sec = 1 nanosec |
fetch from L1 cache memory | 0.5 nanosec |
branch misprediction | 5 nanosec |
fetch from L2 cache memory | 7 nanosec |
Mutex lock/unlock | 25 nanosec |
fetch from main memory | 100 nanosec |
send 2K bytes over 1Gbps network | 20,000 nanosec |
read 1MB sequentially from memory | 250,000 nanosec |
fetch from new disk location (seek) | 8,000,000 nanosec |
read 1MB sequentially from disk | 20,000,000 nanosec |
send packet US to Europe and back | 150 milliseconds = 150,000,000 nanosec |
ぜひ覚えておきたいのが：