分散データベースにおける複雑な障害をエレガントに解決する方法

障害の説明

ACID はトランザクションの 4 つの特性であり、そのうち D (Duration) は永続性を表します。データベースの大きな価値の 1 つは、障害を効果的に処理してデータが失われないようにできることです。分散データベースの発展に伴い、展開の複雑さが増し、データベースが直面する障害シナリオもますます増えています。

一般的なハードウェア障害

次に、一般的なデータセンターの障害確率を見てみましょう。

[[229900]]

「大規模分散システムの構築から得た設計、教訓、アドバイス」ジェフ・ディーン著

ネットワーク障害

上記の障害に加えて、分散システム設計で考慮すべき追加のネットワーク障害がいくつかあります。

スプリットブレインとは、その名前が示すように、ネットワーク障害によりシステムが複数の独立した領域に分割されることを指します。

複数のネットワークプレーンが存在する状況では、一部のネットワークプレーンに障害が発生します。各ネットワークプレーンは論理的であり、ネットワークカードにバインドされていないことが多いため、このエラーは通常は発生しにくいです。ユーザーが構成を誤って調整すると、この障害が発生する可能性があります。システムが複数のネットワークプレーンにまたがる場合は、この障害を考慮する必要があります。

脆弱なデータセンター

実際のところ、データセンターは想像するほど安定していません。次の図は、300 を超えるデータセンターの信頼性を監視する cloudharmony の監視データで、著者が 2017 年 11 月 22 日に取得したものです。

ご覧のとおり、有名な Azure でさえ、主張されている 99.95% を達成していません。詳細にご興味がおありの方は、こちらをご覧ください。

さらに、もう少し詳しい例をいくつか挙げてみましょう。

2017 年 9 月 29 日の Azure Nordic データセンターの停止

ノルディックデータセンターセクションでは、定期的にスケジュールされている日常的な消火システムのメンテナンス中に、消火剤が誤って放出されるという事態が発生しました。これにより、封じ込めと安全のために特別に使用される空気処理ユニット (AHU) が自動的にシャットダウンしました。影響を受けた地域では、システムの過熱を防ぐために、一部のシステムがシャットダウンされ、一部のマシンが再起動されました。 AHU は 35 分後に手動で復旧されました。突然のシステムシャットダウンにより一部のデータの復元が必要になったため、システムは 7 時間後に正常に戻りました。このインシデントにより、一部のユーザーのストレージサービスが利用できなくなりました。

2017 年 2 月 28 日の Amazon S3 の停止

運用保守エンジニアは、会計システムの速度低下の問題を特定する際に、少数のサーバーを削除したいと考えました。その結果、コマンド入力が間違っており、インデックスサブシステムや配置サブシステムのサーバーを含む多数のサーバーが削除されました。その結果、S3 サービスは午前 9 時 37 分から午後 1 時 54 分まで利用できませんでした。最も興味深いのは、AWS サービスヘルスダッシュボードシステムが S3 に依存しているため、障害が発生した時点から午前 11 時 37 分まで、監視ページに障害が表示されなかったことです。この障害により、壁の外のインターネット世界の半分がダウンしたと言われています。

Google Compute Engine は 2016 年 4 月 13 日にサービスを停止しました

世界中のすべての地域で Google Compute Engine サービスが停止され、18 分後に再開されました。この障害は、運用保守エンジニアが未使用の IP ブロックを削除したことが原因でした。ただし、IP 削除操作では構成が適切に同期されませんでした。この操作により、ネットワーク構成システムの整合性チェックがトリガーされました。ネットワーク構成システムが不整合を検出すると再起動し、サービスが中断されました。

2015年5月27日、杭州電信はアリババのネットワークケーブルを切断した。

光ファイバーが切断された後、一部の利用者はサービスを利用できなかったが、2時間後にサービスは復旧した。

寧夏銀行のコアデータベースシステムが2014年7月1日に故障した。

銀行第二部（2014）第187号は正式に国家文書を発行し、寧夏銀行の事故を大まかに次のように説明しています。2014年7月1日、寧夏銀行のコアシステムデータベースに障害が発生し、銀行（他の地域の支店を含む）のすべての預金、引き出し、振替、支払い、デビットカード、オンラインバンキング、ATM、POSサービスが中断されました。

予備的な分析によると、決済業務量が多かった四半期末に、バックアップシステムの異常によりバックアップ保存ディスクの読み書き処理が著しく遅延し、バックアップとメイン保存データに不整合が発生したとのこと。データバックアップ記録操作が中断された後、運用データベースが破損し、クラッシュしました。寧夏銀行の緊急復旧・処理メカニズムが著しく欠如していたため、システム復旧作業はゆっくりと進行した。基幹システムは7月3日午前5時40分まで復旧せず、業務システムは37時間40分にわたり停止し、その間業務はすべて手動で対応した。

障害の分類

データセンターネットワークの相互接続図を見てみましょう

ホスト、スイッチ、ネットワークケーブルなど、図内のハードウェアデバイスはすべて故障する可能性があります。

障害領域ごとに障害を簡単に分類してみます。障害ドメインとは、障害により同時に使用できなくなるコンポーネントのグループです。一般的な障害ドメインには次のものがあります。

ローカルディスク、ネットワークカードの障害、メモリ障害などを含む物理マシン。
電源を共有するデータセンター内のキャビネット
データセンターは複数のネットワーク機器のキャビネットを共有します
一本のファイバーの影響を受けるデータセンター
同じ地域に複数のデータセンターがあり、同じ都市から電力を供給されているか、同じ自然災害の影響を受けています

障害の変化

コンポーネントによって故障の確率は異なります。 Google の調査によると、36°C から 47°C で動作するディスクの故障率が最も高くなります。時間の経過とともに、ディスクの故障率は徐々に増加し、1 年目のわずか 1.7% から 3 年目には 8.6% になりました。

現在では、ディスク障害予測の分野にビッグデータや人工知能を導入し、良好な成果を上げている研究も数多くあります。

データベースのトラブルシューティング

ログシステム

データベースはデータの変更に関するログを記録します。ログにはデータの変更が記録されます。ログの用途の違いにより、REDO ログ、UNDO ログ、REDO/UNDO ログに分類できます。現在、REDOログが人気です。

postgresql ログの構造を見てみましょう。

ログ記録方法の違いにより、ログは次の 2 つのタイプに分けられます。

物理ログ。上の図は物理ログを示しています。再生速度は速いですが、ログの量が多くなります。実装ロジックは比較的単純で、エラーが発生しやすくなります。
論理ログは再生速度が比較的遅く、ログ容量も小さくなります。さらに、MVCC データベースには、ホストマシンに関係なく、スタンバイマシンが独立して GC を実行できるという追加の利点があります。

データベースログシステムには、次の 2 つの重要な原則があります。

WAL の原則では、ページがディスクにフラッシュされる前にログがディスクにフラッシュされる必要があります。ここでのフラッシュは、write を呼び出すだけでよいということではなく、sync 操作も呼び出す必要があることを意味します。適切なタイミングで、通常はトランザクションがコミットされたときに、ログがディスクにフラッシュされ、停電の際にデータを回復できるように、ログをディスクに同期するために sync が呼び出されます。トランザクションがコミットされたときにログをディスクにフラッシュすることに加えて、メタデータ操作が関係している場合は、メタデータの一貫性を確保するために、データをディスクにフラッシュするために sync が呼び出されることがよくあります。
ログシステムによる回復には、完全なログだけでなく、開始点として完全な (おそらく古い) データも必要です。

ログシステムは、データベースだけでなく、システムソフトウェアでも広く使用されている技術です。ログはシステムの変更を表します。リカバリ/バックアップに使用でき、通知システムとしても使用できます。システムのログストリームをマスターすることは、システム全体の状態をマスターすることと同じです。ログは、ログ + ステートマシンとしてより抽象的に理解できます。ログを常に見直してステートマシンの状態を変更することで、ログを送信することで状態の変化をシステム全体の隅々まで伝えることができます。ログシステムに関して、私が見た中で最も人気の記事は、「The Log: What every software engineer should know about real-time data's unifying abstraction」です。ぜひ読んでみることをお勧めします。ログがすべてです。

ログの回復

ログはシステム内のすべての変更を表します。データサイズが 0 から 100G に拡張される場合、ログは少なくとも 100G 以上である必要があります。ログの増加はユーザーによる変更と正の相関関係にあり、継続的に 100% 増加するログを保存できるシステムはありません。

ログによって占有されているストレージスペースを再利用することは避けられない選択です。ログのリサイクルには 2 つの利点があります。

ログが占めるディスク容量を削減する
システム復旧に必要な時間を短縮

実際、MVCC メカニズムが実装されたデータベースでは、ログのリカバリはトランザクションの送信とは関係がないため、ログを指定されたサイズ内で厳密に制御でき、システムの運用と保守に便利です。

上記のデータ復旧には、出発点として完全なデータセットが必要です。実は、その理由は最初のログがリサイクルされたからです。初期状態から最終状態までのすべてのログを保持できれば、ログだけでシステムを復元できます。しかし、すべてのログを保持できるシステムは存在しないことは明らかです。

チェックポイント

チェックポイントはログをリサイクルするために使用されます。チェックポイントのプロセスは次のとおりです。

ドット: 現在のログの位置を記録します。

現在のシステムのメモリ内のすべてのデータをディスクにフラッシュし、sync を呼び出してディスクに同期します。この時点では、WAL 原則に従う必要があります。

チェックポイントログを書き込むか、チェックポイント情報をメタデータとしてディスクにフラッシュします。

チェックポイントの開始点の前にログをリサイクルします。

上記は一般的なチェックポイント方式であり、フルチェックポイントとも呼ばれます。この方法は実装が簡単ですが、チェックポイントが IO ピークであることは明らかであり、パフォーマンスのジッタが発生します。

チェックポイントを実行する別の方法として、増分チェックポイントと呼ばれるものがあります。プロセスは次のとおりです。

バックグラウンド書き込みプロセスでは、ページが最後に変更された順序でフラッシュされます。

チェックポイント: 現在ディスクにフラッシュされているページに対応するログポイントを記録し、チェックポイントログを書き込むか、ディスクをメタデータとしてフラッシュします。

このメソッドは、チェックポイントをバックグラウンド書き込み操作に変換します。チェックポイントを実行するときは、チェックポイントのみを実行する必要があるため、IO ピークが排除され、データベースのパフォーマンスが安定します。

破れたページ

データベースページサイズとディスクセクターサイズは異なることがよくあります。したがって、ページがディスクにフラッシュされるときにシステムの電源が失われると、ページの一部だけがディスクにフラッシュされる可能性があります。この現象を「破れたページ」と呼びます。このページは完全に破損していることに相当し、ログの再生には開始点として完全なデータセットが必要です。現時点では回復できません。

書きかけの文章を処理する方法はいくつかあります。

InnoDB の二重書き込みと pg のフルページ書き込みには同様の原理があります。ページがディスクにフラッシュされる前に、ページはまず他の場所に書き込まれ、その後同期後にページが上書きされます。
バックアップから復元し、バックアップから 1 ページを復元します。

いくつか例外があります:

追加書き込みシステムではこの問題は発生しません。
ページサイズとセクターサイズが同じであれば、このような問題は発生せず、多くのメタデータ設計ではこの点が考慮されることになります。
多くのファイルシステムまたは分散ファイルシステム、RAID カード、またはディスク自体がこの障害に対処できます。半分書き込まれた障害を独自に処理できるハードウェアを使用する場合は、データベースでこの機能を有効にする必要はありません。

ディスクがいっぱいです

データベーストランザクションの送信にはログを書き込む必要があるため、ディスクがいっぱいになる問題は、運用と保守の手段を通じてのみ解決できます。ログを書き込むことができない場合、トランザクションを送信できず、データベースを停止するのと同じことになります。そのため、ディスク障害は一般的に監視によって対処され、ディスク容量が不足しそうになると早期に警告が出されます。

ディスク破損

前述のように、データベースの復旧にはデータとログの完全なセットが必要です。したがって、データやログがディスクによって破損した場合、ログシステムを復元することはできず、他の方法に頼るしかありません。

バックアップ

レベルに応じて、一般的なバックアップ方法は次のとおりです。

完全バックアップ: 従来のデータベースの完全バックアップでは、通常、最初にチェックポイントを実行し、次にチェックポイント後のすべてのデータとログをコピーします。データ量が多い場合、これは重い操作になります。
増分バックアップ: 増分バックアップでもチェックポイントが必要であり、その後、前回のバックアップ以降に変更されたページとチェックポイント以降のログがコピーされます。前回のバックアップ以降に変更されたページを見つけるにはどうすればよいでしょうか?全ページ比較を行うのも 1 つの方法であり、ビットマップファイルを通じてページの変更を記録するのも別の方法です。 Percona は 2 番目の方法を実装します。増分バックアップは重ねて結合できることが多く、完全バックアップと増分バックアップを時系列順に結合することもできます。
ログのアーカイブ: ログのアーカイブとは、指定されたログを定期的にアーカイブすることを指します。

当然のことながら、上記の操作のコストは、フルバックアップ > 増分バックアップ > ログアーカイブの順で大きいものから小さいものの順に並べられます。これら 3 つの方法は、データベースの運用と保守中に、障害 RPO を削減するという目標を達成するために組み合わせられることがよくあります。

Amazon Aurora はほぼリアルタイムのバックアップ機能を実装しており、バックアップ時間は 5 分を超えません。

複数マシンのホットスタンバイ

CPU の焼損、メモリ障害、オペレーティングシステムのバグ、クラッシュなど、さまざまな理由でマシンに障害が発生した場合は、バックアップを使用して復元できます。

ただし、バックアップによる復旧には長い時間がかかることが多く、ビジネス継続性のニーズを満たすことができません。バックアップに加えて、データベースは単一マシンのホットスタンバイと、読み取り専用クエリをサポートするスタンバイマシンをサポートします。

当然のことながら、バックアップマシンは、障害ドメインと顧客の要件に基づいて、アンチアフィニティで展開する必要があります。

マスタースレーブ(カスケード)

各ホストには複数のバックアップマシンを配置でき、各バックアップマシンには複数のカスケードバックアップマシンを配置できます。これは、従来のデータベースの一般的な展開方法です。 Postgres は、マルチレベルカスケードバックアップ (セカンダリ接続) などもサポートしていますが、あまり一般的には使用されていません。この展開方法は、単一のマシンの障害を効果的に処理できます。読み取り専用操作をサポートするスタンバイマシンとして、読み取り負荷を効果的に共有できます。これは遅延読み取り操作であり、それ自体が対応する分離レベルを満たしています。しかし、ホストと合わせて考えると一貫性がありません。

トランザクションコミットのタイミング

ホストトランザクションがコミットされるタイミングに応じて、いくつかのトランザクションコミットレベルがあります。

ホストログがディスクに書き込まれます。この時点で、RTO<1分、RPO>0

ホストログはディスクに書き込まれ、バックアップマシンに送信されます。この時点で、RTO<1分、RPO=0

ホストログはディスクに書き込まれ、ホストログはバックアップマシンに送信されてディスクに書き込まれます。この時点で、RTO<1分、RPO=0

これら 3 つの送信レベルでは、ホストのパフォーマンスはどんどん悪化しています。一般的に、2 番目の方法はローカルバックアップマシンに使用され、3 番目の方法はリモートバックアップマシンに使用されます。

共有ディスク

共有ディスクソリューションは共有ストレージに依存します。スタンバイマシンは読み取り専用であり、書き込みは行いません。スタンバイマシンはディスクに書き込みませんが、ホスト障害後にすぐにプライマリマシンになれるように、メモリ内のログを継続的に再生する必要があります。

明らかに、共有ディスクソリューションのパフォーマンスは、RTO < 1 分、RPO = 0 で、単一のデータサーバーのパフォーマンスと同様です。ただし、ハードウェアの制限により、シャーディングディスクソリューションは同じ都市にのみ適用できます。

技術は螺旋状に進歩します。分散コンピューティングでは、共有ディスクのアイデアも非常に人気があります。ビッグデータ分野で長年定評のある Hadoop、OLTP 分野の新勢力である Aurora、NewSQL 分野の Tidb+Tikv など、多くのシステムが分散ファイルシステム/ストレージシステムに依存し、その上に共有ディスクベースのコンピューティングシステムを構築しています。

マスターマスター

マスター・マスター方式の建築サービスも多く存在し、主流になりつつあります。現在、一貫性の低いビッグデータシステムのほとんどは、マルチマスターアーキテクチャです。著者はビッグデータに精通していないため、ここでは一貫性が強いデータベースシステムのみをいくつか紹介します。

従来の分野では、Oracle RAC と IBM purescale が挙げられます。
シャーディングミドルウェア。多くのインターネット企業は、Tencent tdsql、Alibaba DRDS、ZTE GoldenDB など、独自のミドルウェアを開発しています。 pg-xc、pg-xl、mycat など、オープンソースソリューションも多数あります。ミドルウェアソリューションはインターネットシナリオに適しており、技術的なハードルが低く、ユーザーに対する制限が緩やかです。
FDW (外部データラッパー) はシャーディングに似たソリューションです。現在、Oracle と PG はこのソリューションを使用して、外部データソースをローカルテーブルに直接マップしています。また、外部テーブルから統計情報を抽出するのが難しいなど、多くの制限もあります。
MySQL グループレプリケーションは、レプリケーションプロトコルとして Paxos を使用し、従来のデータベースと組み合わせて新しい探索を行います。
Spanner のようなアーキテクチャで、商用データベースには Spanner と Oceanbase が含まれ、オープンソースデータベースには Tidb と Cockroach が含まれます。

マスター-マスターアーキテクチャのシステムでは、サービスを提供するために常にデータが利用できるため、信頼性が高くなります。これは現在の分散システムの主流のソリューションです。

パクソス/いかだ

Paxos/raft は現在主流の分散レプリケーションプロトコルです。

Paxos プロトコルは、分散システムで合意に達するための最小条件を正確に定義します。 Paxos の原理については、こちらの記事「Paxos アルゴリズムを段階的に理解する」を参照してください。

Paxos は中核的な分散システムの 1 つであり、このアルゴリズムはいくら賞賛しても足りません。 Paxos プロトコルには多くのバリエーションがあり、それを適用する際に注意すべき重要なポイントがいくつかあります。「SRE: Google オペレーションの謎を解明」の第 23 章では、Paxos アプリケーションのいくつかのシナリオと状況について説明します。興味のある人はそれについて学ぶことができます。

いくつかのエンジニアリング信頼性測定

システムコール

どのシステムコールが信頼できるのでしょうか?ほとんどありません。 C 言語で最も問題が発生しやすいシステムコールは malloc です。非常に広範囲に使用されているため、より深いコードロジックでは、メモリ割り当てでエラーが発生すると、対処が非常に困難になります。重要なクローズドモジュールでは、まず十分なメモリ (半自己管理メモリと同等) を申請することをお勧めします。

2 番目にエラーが発生しやすいシステムコールは、IO 関連のコールです。たとえば、IO 呼び出しが失敗した場合、対処するのがより困難になるのは IO の速度低下です。障害が発生した場合、読み取りおよび書き込み操作の速度は期待できません。数十秒、数分、あるいはそれ以上かかるのは正常です。したがって、スピンロックに IO 操作が含まれている場合、システムは崩壊する可能性が高くなります。

ネットワーク間の操作では、ネットワークに期待を抱かないでください。操作の前に、不要なリソースをすべて解放し、呼び出しエラーに備えて、タイムアウトを設定します。非同期モードに切り替えるのは良い選択です。

チェックサム

外部からの損傷やバグによりデータの破損が発生した場合は、チェックサムを使用して検出できます。チェックサムは通常、次の 2 つの状況で使用されます。

データはディスクにフラッシュされるときに計算され、同時にディスクに記録されます。

データの読み取り時に検証します。

ディスクハートビート/接続ハートビート

プロセスの詰まりは避けられません。システム CPU が完全に占有されている場合、または特定のバグが原因で、一部の主要なプロセスがスケジュールされず、特定の情報を送信できなくなる場合があります。いくつかの障害はシステム全体にとって致命的となる可能性があります。

プロセス/スレッドの詰まりを検出する一般的な方法は 2 つあります。

定期的にファイルにアクセスするなど、ディスクハートビートを維持します。ファイルのタイムスタンプが長時間変更されない場合は、プログラムが停止していることを意味します。

外部プログラムがアクセスするためのインターフェースを提供します。外部プログラムは定期的にプロセスにアクセスします。長時間応答がない場合は、プログラムが停止していると考えられます。

バグが原因でプログラムがフリーズした場合、多くの場合、プロセスを強制終了して再起動することで解決できます。

スケジューリング/キュー/優先度/フロー制御

システムパフォーマンスの線形改善を達成することは困難であり、データベースの場合はさらに不可能です。ほとんどのデータベースシステムでは、接続数が増加すると、パフォーマンスはまず一定のレベルまで向上します。接続数が増え続けると、パフォーマンスが低下することがよくあります。

上図は、MySQL 8.0.3 CATS 機能のパフォーマンステスト結果です。 64 を超える接続では、接続数が増えるにつれてパフォーマンスが低下することがはっきりとわかります。

このため、データベースシステムでは一般に接続プールが使用されます。

過度の圧力によりシステムがクラッシュする可能性があります。たとえば、上の図では、FIFO スケジューリングモードでは、512 接続のパフォーマンスが 5 倍近く低下しています。したがって、大規模なシステムでは、接続プールと優先キューはシステムの負荷を効果的に制御できる優れた設計です。同時に、キューの長さを監視することで、システムのこの部分の負荷と処理能力を直感的に確認できます。

オフサイトバックアップ

主流の高可用性ソリューションには 2 つあります。1 つは 2 サイト 3 センター、もう 1 つはマルチサイトアクティブ/アクティブです。

2つの拠点、3つのセンター

従来のデータベースの場合、2 つの場所と 3 つのセンターのソリューションがより一般的です。一般的な展開は、同じ都市に 2 つのセンターがあり、別の場所に 1 つのセンターがあるというものです。

2 つの場所にある 3 つのセンターは、基本的でシンプルな展開アーキテクチャです。メインデータベースに障害が発生すると、リモートセンターは引き継ぐことはほとんどできず、コールドスタンバイとしてのみ機能できます。

一般的に、アプリケーションはメインデータベースに近く、リモートネットワークの待ち時間が大きく、パフォーマンスがメインデータベースほど良くないことがよくあります。
リモートセンターは、ローカルセンターよりもハードウェアの状態が悪い場合が多く、帯域幅や遅延の点でアプリケーション要件を満たさない可能性があります。
オフサイトセンターではサービスを提供できず、リソースが無駄になります。
マスター・スレーブの切り替えが頻繁に行われないと、障害が発生するとリモートセンターでさまざまな問題が発生することがよくあります。上記の記事では、寧夏銀行は破綻の1年前に破綻訓練を実施したが、1年間も訓練を行わなかったら、実際に破綻が起こったときにさまざまな問題が生じることになる。

以下に示すように、共有クラウド上でより信頼性の高いソリューションもあります。

裕福でわがまま。もちろん、パブリッククラウドを大規模に導入すればコストを分散できますが、プライベートクラウドではこのソリューションはより高価になります。

Paxos は、2 つの場所に 3 つのセンターを展開するのには適していません。 Paxos プロトコルには 3 つの同等の障害ドメインが必要であり、1 つの障害ドメインの障害を処理できます。 2 つの場所にある 3 つの中心の断層領域は等しくありません。

市内のレプリケーションは高速ですが、市外のレプリケーションは遅く、パフォーマンスに大きな影響を与えます。

地質災害が発生すると、同じ都市の 2 つのセンターが同時に機能しなくなり、Paxos では対応できません。

複数のライブロケーション

マルチサイトアクティブ/アクティブソリューションでは、次の問題を考慮する必要があります。

リモート環境でのシステムリソースの割り当てに問題があるかどうか。
障害の自己閉鎖: データセンターのネットワーク停止によって地域的な孤立が生じ、システムが使用できなくなるかどうか。特に、データセンターに障害が発生すると、フロー制御システムは他の利用可能な領域に圧力を即座にインポートすることが多く、システムの過負荷が即座に発生する可能性があります。
データセンター間のデータ同期パフォーマンスがニーズを満たすことができるかどうか。

データセンターは非常に高価です。データセンター全体に障害が発生すると、全体的なサービス品質が低下しないようにすることは不可能です。どのようにして効率よくデグレードし、できるだけ多くのデータを利用できるようにするかは、分散システムが重点を置く必要がある問題です。

Google Spanner を例にとると、タイムスタンプの割り当ては分散されており、中央ノードは必要ありません。ユーザーはデータの展開方法を選択できます。データセンターの数が増えるほど、パフォーマンスは低下し、信頼性は高まります。地域的な障害は完全に自己完結的であり、他の部分には影響を及ぼしません。

マルチサイトアクティブアクティブは体系的なプロジェクトです。この大規模なプロジェクトでは、データベースは独自のジョブを実行するだけで済みます。

参考文献

SRE: Google のオペレーションを解読する

Google の高可用性アーキテクチャの概念と実践

スケールの尾

ハードディスクドライブの故障

CAP理論

The Log: すべてのソフトウェアエンジニアがリアルタイムデータの統一的な抽象化について知っておくべきこと

PostgreSQL の WAL 内部

AWS re:Invent 2016: Amazon Aurora を使い始める (DAT203)

Paxosアルゴリズムを段階的に理解する

CloudHarmony データセンター監視