Skip to content

Commit 489a25e

Browse files
ido777serima
andauthored
[Imported] ja: Update some translations, Fix dead links (#432)
* ja-Translation: Follows #433 * ja-Translation: Follows #350 * ja-Translation: Follows #348 * ja-Translation: Follows #439 * ja-Translation: Follows #351 * ja-Translation: Follows #411 * ja-Translation: Follows #328 * ja-Translation: Follows #441, #108 * ja-Translation: Follows #400 * ja-Translation: Follows #321 * Update README-ja.md --------- Co-authored-by: Ryo Shibayama <[email protected]>
1 parent e2b23cf commit 489a25e

File tree

1 file changed

+16
-11
lines changed

1 file changed

+16
-11
lines changed

README-ja.md

+16-11
Original file line numberDiff line numberDiff line change
@@ -278,6 +278,7 @@
278278
* [システム設計面接で成功するには?](https://web.archive.org/web/20210505130322/https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/)
279279
* [システム設計面接](http://www.hiredintech.com/system-design)
280280
* [アーキテクチャ、システム設計面接への導入](https://www.youtube.com/watch?v=ZgdS0EUmn70)
281+
* [システム設計テンプレート](https://leetcode.com/discuss/career/229177/My-System-Design-Template)
281282

282283
## システム設計課題例とその解答
283284

@@ -443,7 +444,7 @@
443444
分散型コンピュータシステムにおいては下の三つのうち二つまでしか同時に保証することはできない。:
444445

445446
* **一貫性** - 全ての読み込みは最新の書き込みもしくはエラーを受け取る
446-
* **可用性** - 受け取る情報が最新のものだという保証はないが、全てのリクエストはレスポンスを必ず受け取る
447+
* **可用性** - 受け取る情報が最新のバージョンだという保証はないが、全てのリクエストはレスポンスを必ず受け取る
447448
* **分断耐性** - ネットワーク問題によって順不同の分断が起きてもシステムが動作を続ける
448449

449450
*ネットワークは信頼できないので、分断耐性は必ず保証しなければなりません。つまりソフトウェアシステムとしてのトレードオフは、一貫性を取るか、可用性を取るかを考えなければなりません。*
@@ -454,7 +455,7 @@
454455

455456
#### AP - 可用性と分断耐性(availability and partition tolerance)
456457

457-
レスポンスはノード上にあるデータで最新のものを返します。つまり、最新版のデータが返されるとは限りません。分断が解消された後も、書き込みが反映されるのには時間がかかります。
458+
レスポンスは読み込み可能なデータの中で最も新しいものを返しますが、データが最新であるとは限りません。分断が解消された後も、書き込みが反映されるのには時間がかかります。
458459

459460
[結果整合性](#結果整合性) を求めるサービスの際にはAPを採用するのがいいでしょう。もしくは、外部エラーに関わらずシステムが稼働する必要がある際にも同様です。
460461

@@ -463,6 +464,7 @@
463464
* [CAP 理論を振り返る](http://robertgreiner.com/2014/08/cap-theorem-revisited/)
464465
* [平易な英語でのCAP 理論のイントロ](http://ksat.me/a-plain-english-introduction-to-cap-theorem)
465466
* [CAP FAQ](https://github.com/henryr/cap-faq)
467+
* [CAP 理論](https://www.youtube.com/watch?v=k-Yaq8AHlFA)
466468

467469
## 一貫性パターン
468470

@@ -492,7 +494,7 @@
492494

493495
## 可用性パターン
494496

495-
高い可用性を担保するには主に次の二つのパターンがあります: **フェイルオーバー****レプリケーション** です。
497+
高い可用性を担保するには相補的な次の二つのパターンがあります: **フェイルオーバー****レプリケーション** です。
496498

497499
### フェイルオーバー
498500

@@ -545,7 +547,7 @@ DNSは少数のオーソライズされたサーバーが上位に位置する
545547

546548
[CloudFlare](https://www.cloudflare.com/dns/)[Route 53](https://aws.amazon.com/route53/) などのサービスはマネージドDNSサービスを提供しています。いくつかのDNSサービスでは様々な手法を使ってトラフィックを捌くことができます:
547549

548-
* [加重ラウンドロビン](http://g33kinfo.com/info/archives/2657)
550+
* [加重ラウンドロビン](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)
549551
* トラフィックがメンテナンス中のサーバーに行くのを防ぎます
550552
* 様々なクラスターサイズに応じて調整します
551553
* A/B テスト
@@ -634,7 +636,7 @@ CDNを用いてコンテンツを配信することで以下の二つの理由
634636
* ランダム
635637
* Least loaded
636638
* セッション/クッキー
637-
* [ラウンドロビンもしくは加重ラウンドロビン](http://g33kinfo.com/info/archives/2657)
639+
* [ラウンドロビンもしくは加重ラウンドロビン](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)
638640
* [Layer 4](#layer-4-ロードバランシング)
639641
* [Layer 7](#layer-7-ロードバランシング)
640642

@@ -760,7 +762,7 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#通
760762
<p align="center">
761763
<img src="images/Xkm5CXz.png">
762764
<br/>
763-
<i><a href=https://www.youtube.com/watch?v=w95murBkYmU>Source: Scaling up to your first 10 million users</a></i>
765+
<i><a href=https://www.youtube.com/watch?v=kKjm4ehYiMs>Source: Scaling up to your first 10 million users</a></i>
764766
</p>
765767

766768
### リレーショナルデータベースマネジメントシステム (RDBMS)
@@ -826,7 +828,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ
826828
<p align="center">
827829
<img src="images/U3qV33e.png">
828830
<br/>
829-
<i><a href=https://www.youtube.com/watch?v=w95murBkYmU>Source: Scaling up to your first 10 million users</a></i>
831+
<i><a href=https://www.youtube.com/watch?v=kKjm4ehYiMs>Source: Scaling up to your first 10 million users</a></i>
830832
</p>
831833

832834
フェデレーション (もしくは機能分割化とも言う) はデータベースを機能ごとに分割する。例えば、モノリシックな単一データベースの代わりに、データベースを **フォーラム****ユーザー****プロダクト** のように三つにすることで、データベース一つあたりの書き込み・読み取りのトラフィックが減り、その結果レプリケーションのラグも短くなります。データベースが小さくなることで、メモリーに収まるデータが増えます。キャッシュの局所性が高まるため、キャッシュヒット率も上がります。単一の中央マスターで書き込みを直列化したりしないため、並列で書き込みを処理することができ、スループットの向上が期待できます。
@@ -840,7 +842,7 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ
840842

841843
##### その他の参考資料、ページ: federation
842844

843-
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=w95murBkYmU)
845+
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs)
844846

845847
#### シャーディング
846848

@@ -1076,7 +1078,7 @@ NoSQLに適するサンプルデータ:
10761078

10771079
##### その他の参考資料、ページ:  SQLもしくはNoSQL
10781080

1079-
* [最初の1000万ユーザーにスケールアップするために](https://www.youtube.com/watch?v=w95murBkYmU)
1081+
* [最初の1000万ユーザーにスケールアップするために](https://www.youtube.com/watch?v=kKjm4ehYiMs)
10801082
* [SQLとNoSQLの違い](https://www.sitepoint.com/sql-vs-nosql-differences/)
10811083

10821084
## キャッシュ
@@ -1520,6 +1522,7 @@ RESTはデータを公開することに焦点を当てています。クライ
15201522

15211523
### その他の参考資料、ページ:
15221524

1525+
* [APIセキュリティチェックリスト](https://github.com/shieldfy/API-Security-Checklist)
15231526
* [開発者のためのセキュリティガイド](https://github.com/FallibleInc/security-guide-for-developers)
15241527
* [OWASP top ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet)
15251528

@@ -1621,6 +1624,8 @@ Notes
16211624
| 複数のデータセンターからデータを配信するサービスの設計 | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
16221625
| オンラインの複数プレイヤーカードゲームの設計 | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)<br/>[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
16231626
| ガーベッジコレクションシステムの設計 | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)<br/>[washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |
1627+
| APIのRate Limitを設計する | [https://stripe.com/blog/](https://stripe.com/blog/rate-limiters) |
1628+
| (NASDAQやBinanceのような)株式取引所を設計する | [Jane Street](https://youtu.be/b1e4t2k2KJY)<br/>[Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)<br/>[Go Implemenation](http://bhomnick.net/building-a-simple-limit-order-in-go/) |
16241629
| システム設計例題を追加する | [Contribute](#contributing) |
16251630

16261631
### 実世界のアーキテクチャ
@@ -1724,9 +1729,9 @@ Notes
17241729
* [Microsoft Engineering](https://engineering.microsoft.com/)
17251730
* [Microsoft Python Engineering](https://blogs.msdn.microsoft.com/pythonengineering/)
17261731
* [Netflix Tech Blog](http://techblog.netflix.com/)
1727-
* [Paypal Developer Blog](https://devblog.paypal.com/category/engineering/)
1732+
* [Paypal Developer Blog](https://medium.com/paypal-engineering)
17281733
* [Pinterest Engineering Blog](http://engineering.pinterest.com/)
1729-
* [Quora Engineering](https://engineering.quora.com/)
1734+
* [Engineering](https://www.quora.com/q/quoraengineering)
17301735
* [Reddit Blog](http://www.redditblog.com/)
17311736
* [Salesforce Engineering Blog](https://developer.salesforce.com/blogs/engineering/)
17321737
* [Slack Engineering Blog](https://slack.engineering/)

0 commit comments

Comments
 (0)