10 Tips for Building Resilient Payment Systems
https://shopify.engineering/building-resilient-payment-systems
Shopifyのブログ
1. Lower Your Timeouts
timeoutを短くする
RubyのNet::HTTPのデフォルトタイムアウトは60秒だが長すぎる
デフォルトがあるだけましで、Goのhttp.ClientやNode.jsのhttp.requestにはデフォルトがない
タイムアウトはデータベースなど他のレイヤーにもあるので注意
MySQLのMAX_EXECUTION_TIME
select @@MAX_EXECUTION_TIME;
PostgreSQLの statement_timeout
show statement_timeout;
最適なタイムアウト時間はモニタリングによって決定すべきだが、5秒から始めるのは妥当
エンドユーザーの目線からすれば5秒待つだけでけっこうひどい
2. Install Circuit Breakers
タイムアウトが短時間に頻発していたらcircuit breakerをオフにしてリクエストさせない
システムがダウンしている可能性が高い
成功しないリクエストがタイムアウトするのを待つ必要はない
semianのようなツールを使う
ただし銀の弾丸ではない
サーキットブレイカーの理解・設定・運用は容易ではなくシステムに複雑性を持ち込むことになる
3. Understand Capacity
Little's law
キャパシティ＝スループット×レイテンシ
リクエストの流量に適切な制限をかける必要がある
rate limitやload shedding
4. Add Monitoring and Alerting
過負荷によってシステムダウンする前に
GoogleのSRE本では4つの指標を掲げている
レイテンシ
1つの作業単位を処理するのにかかる時間
Circuit breakerでは、故障が非常に速く発生し、グラフが誤解を招くことがある
トラフィック
新しい仕事がシステムに入ってくる速度で、通常1分あたりのリクエスト数で表される
エラー
予期せぬことが起こる割合のこと。たとえば決済では、決済の失敗（業務エラー）とシステムエラーを区別していて、後者を指す
飽和状態
システムの総容量に対して、システムがどの程度の負荷を受けているか
システムのどのレイヤーにおいても、使用されるメモリと利用可能なメモリの量、またはスレッドプールのアクティブなスレッドと利用可能なスレッド総数の量に相当する
5. Implement Structured Logging
構造化ログを使いMachine readableにする
分散システムではcorrelation identifier (識別子)を使うと便利
複数のコンポーネントのログにIDが出るので関連するログを簡単に見つけられる
6. Use Idempotency Keys
決済処理中に信頼性の低いネットワークによる問題が発生する確率は100万分の1だが、Shopifyの規模ではこれは1日に何度も起きるレベル
Idempotency-Keyを使用し、冪等にする
ShopifyではULIDを用いており、高スループットのシステムではUUIDv4からULIDにIdempotency Keyを変更することで、INSERT文の時間が50%短縮されたことが確認された
7. Be Consistent With Reconciliation
reconciliationによりパートナーとの記録の整合性を確認する
不一致があれば自動的に修正し、不可能な場合は調査して開発者が修正する
8. Incorporate Load testing
Little's lawは有用だが現実的には処理時間は一様に分布しているわけではない
100%の飽和状態を達成できず、70~80%あたりでキューに溜まるサイズが大きくなり、キューでの待ち時間がクライアントのタイムアウトに至ると実質的にサービスはダウンしてることになる
ベンチマーカーを使ってE2Eテストを行っている
9. Get on Top of Incident Management
障害は回避できないので備えておく
Slack botへのコマンドでインシデントプロセスを開始し、プロセスを機械的に説明・記録する
10. Organize Incident Retrospectives
インシデントから1週間以内にPostmortemを行う