Amazon Builder's Library 輪読会資料 分散システムでのフォールバックの回避

参加しているコミュニティ、Challeng-Every-Monthの輪読会で作成した資料。

Transcript

1. abl輪読会 第６回分散システムでのフォー ルバックの回避 20/3/15(日) 21:00- 発表者:koji/メガネ男 著者
 Jacob Gabrielson アマゾン ウェブ サービスのシニ アプリンシパルエンジニア ABL URL https://aws.amazon.com/jp/builders-library/avoiding-fall back-in-distributed-systems/?did=ba_card&trk=ba_card 1
2. はじめに • 重大な障害への対応策 1. 再試行　　　　　　　　　障害発生後ただちに、又は間をおいて実行。 2. 積極的な再試行　　　　　平行してリクエストを送り、負荷を安定させる。　　　　　　　 3. フォールバック　　　　　機能を限定した状態への移行。 　　　　　　　　　　　　Amazonは基本実装しない 4. フェイルオーバー　　　　(Amazonは)フォールバックと非フォールバック機能 　　　　　　　　　　　　を両方実装し、本番環境でテストし続ける。 2
3. はじめに • 　長期にわたり大きな影響を及ぼす。しかもフォールバック機能そのものの改善も 難しい。 　ゆえにAmazonではフォールバック機能を使わない。 • 　現実では非常事態でシステムがダウンすると、拙いながらも代わりの方法を利用 するだろう。 　例えば空港の案内板システムがダウンしたら、職員が手書きでホワイトボードに フライト時間を書き込むだろう。 　同じ様な発想で、一般的なエンジニアもフォールバック機能を使っている。 3
4. 単一マシン(=非分散型)のフォールバック 1/2 • 　非分散型の場合、重要なアプリケーションは、メモリ割り当てエラーが発生した場 合でも、システムが止まらないように動作し続けなければならない。 • 　malloc()処理で対応しようとしても、メモリ不足でクラッシュ寸前なので対処しよう がないし、実際に起こるメモリ不足をシミュレーションするのは難しくフォールバック 機能はテストしづらい。 　フォールバック機能自体も失敗することがある。 4
5. 単一マシン(=非分散型)のフォールバック 2/2 • 　malloc()処理にメモリを食われるし、システムに予測不能な負荷がかかる可能性 がある。 　めったに機能しないフォールバック機能にバグがあったら危険。 　クラッシュさせる方がよほどよい。 • 　Amazonでは、事前にヒープメモリーを割り当てておいて、malloc()処理を使わな いようにしている。 　例：(PR) EC2 5
6. 分散フォールバック 1/3 • 　分散型マシンなら、お客さんが実際使っているアプリケーションがメモリ不足に なっても、他のマシンのリソースを借りられるので、単一型マシンよりも可用性が高 い。 • 　だからと言って、フォールバック機能を採用するのは問題である。 　分散型の場合、単一型にくらべ、テストもセットアップもより困難。 　復旧にも時間がかかる。 　バグも見つけ辛い。 6
7. 分散フォールバック 2/3 • 　Amazonも2001年に痛い目にあった。 　ウェブサーバーからサプライチェーンデータベースに直接データを参照させると、 データベースが負荷に耐えられない。 　そこで、ウェブサーバー上に個別のキャッシングレイヤーを追加した。 7
8. 分散フォールバック 3/3 • 　エラーが発生した場合、データベースに直接参照するようなフォールバック処理も 構築していたが、キャッシュがほぼ同時にすべて失敗したため機能しなかった。 　その結果、ウェブサーバーが全体がダウン。 　おまけに配送センターまで停止。 • 　フォールバック機能が実装されていたばっかりに、より事態は悪化した。 8
9. Amazon がフォールバックを回避する方法 1/3 • 　そこでAmazonは以下の対策を講じました。 • 　エラーが発生しにくいシステムの構築。 　(PR) 可用性の高いAmazon DynamoDB！ • 　フォールバックによりデータベースに負荷をかけるのではなく、例えば再試行に よって、参照側に障害を処理させるようにする。 • 　(PR) IMAでは、EC2のインスタンスで走らせるための認証情報を提供する必要が あるが、インスタンスに積極的にプッシュしてこれを保有させることで、リクエストに 応じる時に発生する負荷を減らす仕組みを取っている。 9
10. Amazon がフォールバックを回避する方法 2/3 • 　フォールバック処理と非フォールバック処理を両方実装し、どちらも機能している ことを定期的に本番環境で確認する。 　この場合はフォールバックというより、フェイルオーバーに分類される。 10
11. Amazon がフォールバックを回避する方法 3/3 • 　再試行は、エラーに対して高い可用性をもたらす。 • 　ただし、タイムアウトと再試行は混同しやすい。 • 　そこで、Amazon では全体的な再試行率を監視する メトリクスと、再試行が頻繁に発生した場合にチームに 警告するアラームを維持している。 • 　並行してリクエストを出すことで、(すでに負荷がかかっているので)再試行による 余分な負荷の発生がなくなる。 　これは分散システムのクォーラムの読取または書込において実行される。 11
12. まとめ • 　Amazon では、テストが難しいフォールバック戦略を避けている。 • 　並行してリクエストを送る等の積極的な再試行により、余分な負荷の発生しない 仕組みを作り、プライマリシステムの可用性を向上させるようにしている。 • 　どうしてもコードの挙動がおかしく、フォールバックしそうな場合に備え、本番環境 で可能な限り頻繁にフォールバックを実行することで、フォールバックがちゃんと動 作するようにしている。 12