本「高負荷のアプリケーション。 プログラミング、スケーリング、サポート」

この本では、データを操作するための負荷の高いシステムを開発する際になくてはならない重要な原則、アルゴリズム、トレードオフについて説明します。 この資料は、一般的なソフトウェアパッケージとフレームワークの内部構造の例で検討されています。 この本には、主に分散システムとデータベースを操作する理論的側面に専念する3つの主要部分があります。 読者には、SQLの基本的な知識とデータベースの動作方法が必要です。

レビュー投稿では、「知識、真実、偽り」というセクションを取り上げています。

分散システムの経験がない場合、これらの問題の結果は非常に混乱させる可能性があります。 ホストは確実に何も知らない-ネットワークを介して受信する（または受信しない）メッセージに基づいてのみ推測を行うことができます。 あるノードは別のノードの状態（その上に保存されているデータ、正常に動作するかどうか）を確認できますが、メッセージを交換するだけです。 リモートホストが応答しない場合、ネットワークの問題とホストの問題を区別することができないため、そのステータスを確認する方法はありません。


これらのシステムの議論は哲学に隣接しています：私たちのシステムでは何が真実で、何が偽ですか？ 認知と測定のメカニズムが信頼できない場合、この知識に頼ることができますか？ ソフトウェアシステムは、因果関係の法則など、物理世界の法則に従うべきですか？

幸いなことに、人生の意味を探す必要はありません。 分散システムの場合、動作（システムモデル）に関する仮定を記述し、これらの仮定に一致するように設計できます。 特定のシステムモデルのフレームワーク内でアルゴリズムの正しい動作を検証することが可能です。 これは、基礎となるモデルがほとんど保証を提供しない場合でも、信頼性が達成可能であることを意味します。

ただし、信頼性の低いモデルでシステムの適切な動作を保証することは可能ですが、これは簡単ではありません。 この章の残りの部分では、分散システムの知識と真実の概念について説明します。これは、必要な仮定と保証に対処するのに役立ちます。 第9章では、特定の仮定で特定の保証を提供する分散システムとアルゴリズムのいくつかの例を検討します。

真実はほとんどによって決定されます

非対称障害のあるネットワークを想像してください。ノードは送信されたすべてのメッセージを受信しますが、その送信メッセージはすべて遅延されるか、破棄されることさえあります。 また、正常に動作し、他のノードからリクエストを受信しますが、これらの他のノードは回答を受信しません。 その結果、いくつかのタイムアウトの後、他のノードはアイドル状態を宣言します。 状況はある種の悪夢に変わります。ネットワークから半分切断されたホストが「墓地」に強制的に引きずられ、彼は戦い、「私は生きている！」と叫びます。 しかし、誰も彼の叫び声を聞いていないので、葬列は着実に動き続けています。

少し悪夢のようなシナリオでは、ネットワークから半分切断されたホストは、他のホストからのメッセージの配信の確認応答がないことに気付き、ネットワーク障害があることを理解します。 それにもかかわらず、他のノードは誤って半分切断されたノードを動作不能と宣言し、彼はそれについて何もすることができません。

3番目のシナリオとして、長時間にわたる包括的なガベージコレクションのためにノードが長時間中断されることを想像してください。 そのスレッドはすべて、ガベージコレクションプロセスによってメモリから強制的に削除され、1分間中断されます。したがって、要求は処理されず、応答は送信されません。 他のノードは待機し、再試行し、忍耐力を失い、最終的にノードが動作不能であると宣言し、「霊se車に送信」します。 最後に、ガベージコレクションプロセスが完了し、ノードフローは何も起こらなかったかのように再開します。 残りのノードは、「デッド」と宣言されたノードの完全な健康状態にある「復活」に驚き、目撃者と喜んでチャットを始めます。 最初は、このノードは1分が経過し、「デッド」と宣言されたことを理解していません。彼の観点からは、他のノードとの最後のメッセージ交換の瞬間からほとんど時間が経過しました。

これらの物語の教訓は次のとおりです。結び目は、状況に関する自身の意見だけに頼ることはできません。 分散システムは、単一ノードに完全に依存することはできません。いつでも障害が発生し、障害が発生してシステムを復元できなくなるためです。 代わりに、多くの分散アルゴリズムはクォーラムに基づいて作業を行います。つまり、ほとんどのノードを解決します（セクション5.4の「ノードの1つが失敗した場合のデータベースへの書き込み」セクションの「書き込みおよび読み取りクォーラム操作」セクションを参照）：決定には特定の最小量が必要です複数のノードからの「投票」。 この条件により、特定の1つのノードへの依存を減らすことができます。

これには、ノードが動作不能であると宣言する決定が含まれます。 ノードクォーラムが別のノードが動作不能であると宣言した場合、同時に正常に機能していても、そのノードは1つであると見なされます。 クォーラムの決定に従うには、個々のノードが必要です。

通常、クォーラムはノードの半分以上の絶対大部分です（ただし、他の種類のクォーラムがあります）。 ほとんどの場合、クォーラムにより、個々のノードに障害が発生した場合にシステムが動作します（3つのノードでは1つの障害が許容され、5つでは2つの障害が許容されます）。 この方法は安全です。なぜなら、システムは1つの過半数のみで構成されているためです-同時に2つの過半数であり、その決定が競合することは不可能です。 第9章でコンセンサスアルゴリズムに到達するときに、クォーラムの使用について詳しく説明します。

ホストとロック

多くの場合、システムは何かのインスタンスを1つだけ必要とします。 例：

• 計算能力の分離の状況を回避するために、データベースセクションのリーダーになることができるノードは1つだけです（セクション5.1のサブセクション「ノードのメンテナンスの中断」を参照）。
• 1つのトランザクションまたは1つのクライアントのみが特定のリソースまたはオブジェクトのロックを保持して、競合するエントリまたはその損傷を防ぎます。
• ユーザーを一意に識別する必要があるため、特定のユーザー名を登録できるユーザーは1人だけです。

これを分散システムに実装するには注意が必要です。ノードが「選択」に自信がある場合（セクションの先頭ノード、ロックの所有者、ユーザー名を正常にキャプチャした要求ハンドラー）でも、他のノードのクォーラムがこれに同意するという事実はまったくありません！ ノードは以前はリーダーでしたが、他のノードが（たとえば、ネットワークの中断やガベージコレクションの一時停止のために）動作不能と宣言した場合は、「降格」して別のマスターノードを選択できます。

他のノードのクォーラムが動作不能と宣言したという事実にもかかわらず、ノードが「選択」として動作し続ける場合、十分に慎重に設計されていないシステムで問題が発生する可能性があります。 そのようなノードは、自称「選択された」ノードとして他のノードにメッセージを送信することができ、他のノードがこれに同意すると、システム全体が正しく動作しなくなる可能性があります。

たとえば、図 図8.4は、ロックの誤った実装によるデータ破損を伴うエラーを示しています（これは決して理論上のエラーではありません。HBaseDBMSで頻繁に発生します）。 複数のクライアントがすぐに書き込もうとすると、ファイルが破損するため、ストレージサービスにあるファイルに同時にアクセスできるクライアントが1人だけであることを確認するとします。 ファイルにアクセスする前に、クライアントがロックサービスからリースを義務的に受け取ることにより、これを実装しようとします。

説明されている問題は、セクション8.3のセクション「プロセスの実行中の一時停止」で説明したものの例です。テナントが長時間中断されると、リース契約が失効します。 その後、別のクライアントが同じファイルのリースを受け取り、データの書き込みを開始できます。 作業を再開した後、中断されたクライアントは、有効なリースをまだ持っていると（誤って）信じ、ファイルへの書き込みを続行します。 その結果、2つのクライアントの書き込み操作が混在し、ファイルが破損します。

フェンシングマーカー

図のファイルストレージなどのリソースへのアクセスを保護するためにロックまたはリースを使用する場合 8.4、自分自身を誤って「選出された」とみなしたノードがシステムの残りの動作を混乱させないことを確認する必要があります。 この目的のために、図3に示すようにかなり簡単な方法があります。 8.5。 フェンシングと呼ばれます。

ロックまたはリースが提供されるたびに、ロックサーバーはフェンシングトークンも返すことを想像してください。フェンシングトークンは、ロックが提供されるたびに増加する数値です（たとえば、ロックサービスがそれを増やすことができます）。 また、レコードリクエストがストレージサービスに送信されるたびに、そのようなマーカーを現在のリクエストに含めることをクライアントに要求します。

図 8.5クライアント1は、マーカー33でリースを受信します。その後、長い間中断され、リースの有効期限が切れます。 クライアント2は、マーカー34でリースを受信し（数は単調に増加します）、その後、要求にこのトークンを含む書き込み要求をストレージサービスに送信します。 その後、クライアント1は操作を再開し、マーカー33を含む書き込み操作をストレージサービスに送信しますが、ストレージサービスは既に大きなマーカー番号（34）の書き込み操作を処理したことを記憶し、この要求を拒否します。

ZooKeeperロックをガードトークンとして使用する場合、トランザクション識別子zxidまたはcversionノードのバージョンを使用できます。 ZooKeeperは単調な増加を保証するため、これに必要な特性を備えています。


注：このメカニズムでは、トークン自体の検証でリソース自体がアクティブな役割を果たし、既に処理されているトークンよりも古いトークンでのすべての書き込み操作を拒否する必要があります。 境界マーカーを明示的にサポートしないリソースの制限をバイパスできます（たとえば、ファイルストレージサービスの場合、境界マーカーはファイル名に含まれます）。 ただし、保護をブロックせずに要求を処理しないようにするには、まだいくつかの検証が必要です。

サーバー側でトークンをチェックすることは欠陥のように思えるかもしれませんが、おそらくそれほど悪くはありません。サービスについては、クライアントは次のような異なる優先順位を持つ人々によってしばしば起動されるため、すべてのクライアントが常に「正常に動作する」と仮定するのは不合理ですサービス所有者から。 したがって、サービスが顧客側の意図しない誤ったアクションから自身を保護することをお勧めします。

ビザンチンのグリッチ

フェンシングマーカーは、誤って誤ったアクションを実行するノードを検出してブロックできます（たとえば、リースの期限切れをまだ検出していないため）。 ただし、意図的にシステム保証を弱体化させたいサイトは、偽のマーカーを付けてメッセージを送信することで簡単にこれを行うことができます。

この本では、ノードは信頼できないが「まともな」ノードであると想定しています。ノードの動作は遅くなったり、まったく応答しなかったり（障害が原因）、状態が古くなったり（ガベージコレクションまたはネットワークの遅延のため）が、ノードが彼が答えるなら、彼は「真実を語る」（彼が利用できる情報の枠組みの中でプロトコルの規則に準拠する）。

分散システムの問題は、ノードが「嘘をつく」（任意の失敗または破損した応答を送信する）リスクがある場合、たとえば、ノードが特定のメッセージを実際に受信しなかったことを通知する場合、大幅に悪化します。 この動作はビザンチン断層と呼ばれ、このような信頼できない環境で合意に達する作業はビザンチン将軍の問題として知られています。

一部のノードの誤動作やプロトコルへの準拠の失敗、または侵入者がネットワークに干渉した場合でも、システムが正常に動作し続ける場合、システムはビザンチンの障害から保護されます。 これは、次の状況で重要になる場合があります。

• 航空宇宙産業では、コンピューターのメモリまたはCPUレジスターのデータが放射により破損する可能性があり、予測できない応答を他のノードに送信することになります。 システムの故障は壊滅的な結果につながる可能性があるため（たとえば、航空機のcrash落や搭乗者全員の死亡、ロケットと国際宇宙ステーションとの衝突など）、飛行制御システムをビザンチンのグリッチから保護する必要があります。
• 多くの参加組織を持つシステムの一部の参加者は、他人をだまそうとするか、だまそうとする場合があります。 このような状況では、他のサイトからのメッセージを悪意を持って送信される可能性があるため、サイトは盲目的に他のサイトからメッセージを信頼しないでください。 たとえば、Bitcoinやその他のブロックチェーンなどのピアツーピアネットワークは、中央機関に依存せずにトランザクションが発生したかどうかを相互に信頼しない当事者が同意する方法と見なすことができます。

ただし、この本で説明するようなシステムでは、通常、ビザンチンの障害がないと安全に想定できます。 データセンターでは、すべてのノードが組織によって制御され（したがって、ノードは信頼されています）、放射レベルが十分に低いため、メモリ破損が深刻な問題を引き起こすことはありません。 ビザンチンで保護されたシステム障害を作成するためのプロトコルは非常に複雑であり、そのような組み込みシステムにはハードウェアのサポートが必要です。 ほとんどのサーバー情報システムでは、ビザンチンで保護されたソリューションを使用するには高価すぎます。

同時に、ブラウザなどのエンドユーザーが制御するクライアントから任意の悪意のある動作をWebアプリケーションが予期することは理にかなっています。 したがって、入力の検証、正確性の制御、および出力のエスケープは非常に重要です。たとえば、SQLインジェクション（SQLインジェクション）やクロスサイトスクリプティングを防ぐためです。 ただし、これは通常、ビザンチン障害から保護されたプロトコルを適用せず、サーバーにはクライアントの動作が許容できるかどうかを決定する権限が委任されます。 そのような中央機関が存在しないピアツーピアネットワークでは、ビザンチンの混乱からの保護がより適切です。

ソフトウェアのバグはビザンチンのクラッシュとみなすことができますが、同じソフトウェアがすべてのノードで使用されている場合、ビザンチンのクラッシュ保護アルゴリズムはあなたを救いません。 これらのアルゴリズムのほとんどは、正常に機能するノードの3分の2以上の修飾された過半数を必要とします（つまり、4つのノードの場合、多くても1つが機能しない場合があります）。 このアプローチを使用してエラーの問題を解決するには、同じソフトウェアの4つの独立した実装を使用し、そのうちの1つだけにエラーが存在することを期待する必要があります。

同様に、プロトコル自体が脆弱性、セキュリティ侵害、悪意のある行為から私たちを保護するのは魅力的です。 残念ながら、ほとんどのシステムではこれは非現実的です。 攻撃者が1つのノードに不正にアクセスした場合、ほとんどの場合同じソフトウェアがそれらのノードで機能するため、他のノードにアクセスできる可能性が非常に高くなります。 したがって、従来のメカニズム（認証、アクセス制御、暗号化、ファイアウォールなど）が攻撃に対する主な保護のままです。

「嘘」の弱い形。 ノードは主に「尊敬」されるものと想定していますが、ソフトウェアの弱い「嘘」に対する保護メカニズムを追加することは理にかなっています。たとえば、ハードウェアの問題、ソフトウェアエラー、設定の誤りによる誤ったメッセージなどです。 そのようなメカニズムは、明確な攻撃者から救うことができないため、ビザンチンの破壊に対する全面的な保護とは見なせませんが、これらは信頼性を高めるための簡単で実用的な手順です。 以下に例を示します。

• ネットワークパケットの損傷は、ハードウェアの問題やオペレーティングシステム、ドライバー、ルーターなどのエラーが原因で発生することがあります。通常、TCPおよびUDPプロトコルに組み込まれたチェックサムをチェックすると、破損したパケットがインターセプトされますが、チェックが省略されることもあります。 パケット破損を検出するには、通常、アプリケーション層プロトコルのチェックサムなどの簡単な手段で十分です。
• 公開されているアプリケーションは、ユーザーが入力したデータの正確さを注意深く監視する必要があります。たとえば、値が許容範囲内にあるかどうかを確認し、行の長さを制限して、大量のメモリの割り当てによるサービス拒否を回避します。 ファイアウォールの背後にある組織内で使用されるサービスの場合、入力データのチェックはそれほど厳しくありませんが、値の単純な制御（たとえば、プロトコルの解析中）は害になりません。
• NTPクライアントは、複数のサーバーのアドレスを使用するように構成できます。 同期中、クライアントはそれらすべてに連絡し、エラーを計算し、ほとんどのサーバーが同意する一定の期間があることを確認します。 ほとんどのサーバーが正常に機能している場合、誤った時刻を返す誤って構成されたNTPサーバーは異常と見なされ、同期から除外されます。 複数のサーバーを使用すると、単一のサーバーと比較して、NTPプロトコルのフォールトトレランスが向上します。

実際のシステムモデル

分散システムの問題を解決するために、多くのアルゴリズムが開発されています。たとえば、第9章でコンセンサス問題の解決策を検討します。何らかの利点をもたらすには、これらのアルゴリズムは、この章で説明した分散システムのさまざまな障害に対処できなければなりません。

アルゴリズムは、動作するシステムのハードウェアおよびソフトウェア設定の機能にできるだけ依存しないようにする必要があります。 これには、発生する可能性のある障害のタイプを形式化する必要があります。 これを行うために、システムのモデルを説明します。これは、アルゴリズムが受け入れる仮定を説明する抽象概念です。

タイミングの仮定に関しては、3つのシステムモデルがよく使用されます。

• 同期。 限られたネットワーク遅延、プロセスの一時停止、クロックの不一致を想定しています。 これは、完全なクロック同期やゼロのネットワーク遅延を意味するものではなく、単にネットワーク遅延、プロセスの一時停止、クロックの差の持続時間が一定の上限を超えないことを意味します。 （この章で説明したように）無制限の遅延と一時停止が発生することがあるため、同期モデルはほとんどの実用的なシステムでは非現実的です。
• 部分的に同期。 これは、ほとんどの場合システムが同期として動作することを意味しますが、ネットワーク遅延、プロセスの一時停止、およびクロックの不一致[88]の指定期間を超える場合があります。 これはほとんどのシステムにとって非常に現実的なモデルです。ネットワークとプロセスが正常に機能している時間のかなりの部分-そうでなければ何も機能しません。 ただし、この事実を考慮に入れる必要があります。タイミングに関する想定は、時々粉々に崩れます。 この場合、ネットワークの遅延、一時停止、およびクロックエラーは、任意の大きな値に達する可能性があります。
• 非同期。 このモデルでは、アルゴリズムには一時的な仮定を構築する権利がありません-実際、ここにはクロックさえありません（したがって、待機時間の概念はありません）。 一部のアルゴリズムは非同期モデルに適応できますが、開発者にとっては非常に制限されています。

ただし、タイミングの問題に加えて、ノード障害の可能性も考慮する必要があります。 ノードの最も一般的な3つのシステムモデルを次に示します。

• 障害停止モデル。 ここでは、アルゴリズムはノード障害が致命的であるとだけ考えます。 つまり、ノードはいつでも応答を停止でき、その後は作業が再開されません。
• 障害回復モデル。 ノード障害はいつでも発生する可能性があると想定されていますが、その後、ノードはおそらく未知の期間後に再び応答し始めるでしょう。 このモデルは、ノードに信頼性の高いストレージ（つまり、不揮発性ストレージメディア）があり、障害時にデータが失われないことを前提としています（RAM内のデータは失われたと見なされます）。
• ビザンチン（任意）障害。 最後のサブセクションで説明したように、ノードは他のノードをだまして意図的に誤解させる試みを含め、好きなように実行できます。

実際のシステムのシミュレーションには、通常、部分的に同期した障害復旧モデルが最適です。 しかし、分散アルゴリズムはどのように対処しますか？

アルゴリズムの正確さ

アルゴリズムの正確さの定義を与えるために、その特性を説明します。 たとえば、ソートアルゴリズムの結果には次のプロパティがあります。出力リストの2つの異なる要素の場合、左側の要素は右側の要素よりも小さくなります。 これはリストの並べ替えを記述する正式な方法です。

正しい分散アルゴリズムに必要なプロパティは、同様の方法で定式化されます。 たとえば、ブロック用のフェンシングマーカーを生成する場合、アルゴリズムから次のプロパティを要求できます。

• 一意性-囲んでいるマーカーの2つの要求が同じ値を返すことはありません。
• 値の単調増加-クエリxがマーカーtxを返し、クエリyがマーカーtyを返し、xがyの開始前に終了する場合、tx <ty;
• アクセシビリティ-致命的な障害が発生せず、囲んでいるトークンを要求したノードは、最終的にその要求に対する応答を受け取ります。

アルゴリズムは、システムのこのモデルで発生する可能性があるすべての状況でこれらのプロパティを常に満たす限り、システムの一部のモデルで正しいです。 しかし、それは理にかなっていますか？ すべてのノードまたはすべてのネットワーク遅延で致命的な障害が突然発生すると、アルゴリズムは何もできません。

機能的な安全性と生存性

この状況を明確にするには、機能安全性（安全性）と生存性（生存性）の2種類の特性を区別する必要があります。 上記の例では、一意性と値の単調な増加の特性は、機能的安全性と生存性へのアクセス性に関連しています。

これら2つのタイプのプロパティの違いは何ですか？ 特徴的な機能：存続可能性プロパティの決定における「最後に」というフレーズの存在（そして、はい、あなたは絶対に正しいです：最終的な一貫性は、存続可能性のプロパティです）。

機能安全は、多くの場合、「悪いことは何も起こらなかった」というフレーズと、存続可能性-「時間の経過とともに良いことが起こる」というフレーズによって非公式に説明されます。 しかし、「悪い」と「良い」という言葉は主観的であるため、このような非公式の定義にあまり夢中にならない方が良いです。 機能的安全性と生存性の本物の定義は数学的に正確です。

• 機能安全プロパティに違反している場合、この違反には特定の瞬間があります（たとえば、一意性プロパティに違反している場合は、重複トークンが返される特定の操作を決定できます）。 機能安全機能に違反した場合、損傷はすでに行われていますが、それについては何もできません。
• それどころか、サバイバビリティプロパティはどの時点にも結び付けられていない可能性があります（たとえば、ノードはリクエストを送信できますが、まだ応答を受信できません）が、将来的には（たとえば、応答を受信することによって）満たされることを常に期待しています。

機能安全性と生存性の特性に分割する利点は、複雑なシステムモデルでの作業を簡素化することです。 分散アルゴリズムの場合、システムモデルのあらゆる可能性のある状況で、機能安全特性を常に尊重することがしばしば要求されます。 つまり、すべてのノードまたはネットワーク全体の致命的な障害が発生した場合でも、アルゴリズムは間違った結果を返さないことを保証する必要があります（つまり、機能安全特性が観察されます）。

ただし、サバイバビリティプロパティについては明確化が必要です。たとえば、ほとんどのノードで致命的な障害が発生せず、サービス停止後にネットワークが最終的に回復した場合にのみ、リクエストへの応答を返す必要があると言えます。 部分同期モデルの定義では、システムが徐々に同期状態に戻る必要があります。つまり、ネットワーク中断の期間は限られた時間だけ続き、その後復元されます。

システムモデルを実世界にリンクする

システムモデルと同様に、機能安全性と生存性のプロパティは、分散アルゴリズムの正確性を判断するのに非常に便利です。 ただし、実際にアルゴリズムを実装すると、残酷な現実が引き継がれ、システムモデルが現実の単純化された抽象化にすぎないことが明らかになります。

たとえば、「致命的な障害-復旧」モデルのアルゴリズムでは、通常、信頼性の高いストレージに保存されているデータに致命的な障害が発生していると想定しています。 しかし、ディスク上のデータが破損した場合、またはハードウェアエラーや誤った設定[91]によりデータが消去された場合はどうなりますか？ また、サーバーファームウェアにエラーが含まれており、ハードドライブがサーバーに適切に接続されていても、再起動後にハードドライブの「表示」が停止した場合

クォーラムアルゴリズム（セクション5.4の「ノードの1つに障害が発生した場合のデータベースへの書き込み」のサブセクション「クォーラムの書き込みおよび読み取り操作」を参照）は、ストレージが宣言したデータを記憶するノードに依存します。 ノードの「健忘症」および以前に保存されたデータを忘れる可能性は、クォーラム条件に違反し、その結果、アルゴリズムの正確性に違反します。 おそらく、ほとんどの場合、信頼性の高いストレージは致命的な障害に耐えることができますが、データが失われる可能性があるという前提で、システムの新しいモデルが必要です。 ただし、このモデルを正当化することはより困難です。

アルゴリズムの理論的説明では、特定のことは単に発生しないはずであると述べることができます。また、ビザンチン以外のシステムでは、どの障害が発生し、どの障害が発生しないかを仮定するだけです。 ただし、実際には、この処理がprintf（「あなたは運が悪い」）に落ちて終了（666）しても不可能と思われる事態が発生した場合に対処するために、実装にコードを含める必要がある場合があります。人に。 （これは、コンピューターサイエンスとソフトウェアエンジニアリングの違いです。）

これは、理論的で抽象的なシステムが無価値であることを意味するのではなく、まったく逆です。 問題を理解し、体系的に解決しようとするために考慮できる許容可能な一連の障害を、実際のシステムの複雑さ全体から抽出するのに非常に役立ちます。 システムの特定のモデルでその特性が常に観察されることを実証することにより、アルゴリズムの正確性を証明できます。

アルゴリズムの正確性の証明は、実際のシステムでの実装が常に正しく動作することを意味しません。 しかし、これは非常に良い最初のステップです。理論的な分析は、実際のシステムに隠れたままであり、何らかの異常な状況による仮定の崩壊（タイミングなど）の場合にのみ現れる可能性があるアルゴリズムの問​​題を特定するのに役立ちます。 理論的分析と実証的テストも同様に重要です。

»本の詳細については、出版社のウェブサイトをご覧ください
» コンテンツ
» 抜粋

プログラマー向けクーポンの20％割引- プログラミング