分散システムのコードレビューチェックリスト

マイクロサービス アーキテクチャは、現在ソフトウェア エンジニアリング コミュニティで広く採用されている手法です。このアーキテクチャ スタイルを採用する組織は、ビジネス ロジックの実装の複雑さに加えて、分散障害の複雑さにも対処する必要があります。

分散コンピューティングの誤りは十分に文書化されていますが、見つけるのは困難です。その結果、大規模で信頼性の高い分散システム アーキテクチャを構築することは困難な問題となります。結果として、非分散システムでは適切に見えるコードでも、ネットワーク相互作用の複雑さを Web に導入すると大きな問題になる可能性があります。

数年にわたって本番コードで障害モードに遭遇し、さまざまなコードでその原因を突き止めてきた結果、私は (他の多くの人と同様に) より一般的な障害モードのいくつかを特定しました。これらは企業や言語スタックによって若干異なりますが (社内のインフラストラクチャとツールの成熟度によって異なります)、これらの 1 つ以上が運用上の問題の原因となることがよくあります。

ここでは、分散環境でのシステム間通信に関連するコードをレビューするために使用する基本的なチェックリストとして機能するコード レビュー ガイドラインをいくつか示します。これらの方法はすべて常に当てはまるわけではありませんが、いずれも非常に基本的な質問なので、これを機械的にリスト化し、不足している項目にマークを付けてさらに議論することは、便利で安心できると思います。そういう意味では、これはおそらく常に従いたくなるようなばかげたリストです。

リモート システムを呼び出すときに、リモート システムに障害が発生するとどうなりますか?

どれだけメンテナンスを考慮してシステムを設計しても、いつかは故障します。これは、本番環境でソフトウェアを実行する上での事実です。バグ、インフラストラクチャの問題、トラフィックの急増、無視された緩やかな減少などにより失敗する可能性がありますが、失敗しました。呼び出し元がこの障害をどのように処理するかによって、アーキテクチャ全体の回復力と堅牢性が決まります。

• エラー処理パスを定義する: エンド ユーザーの目の前でシステムがクラッシュするのを放置するのではなく、コード内にエラー処理パスを明確に定義することが不可欠です。適切に設計されたエラー ページ、エラー メトリックを含む例外ログ、フォールバック メカニズムを備えたサーキット ブレーカーなど、エラーは明示的に処理する必要があります。
• 回復計画を作成する: コード内のすべてのリモート操作を考慮し、中断された作業を再開するために何を行う必要があるかを把握します。ワークフローは、障害ポイントからトリガーできるようにステートフルな状態を維持する必要がありますか?失敗したペイロードをすべて再試行キュー/データベース テーブルに投稿し、リモート システムが復旧したときに再試行しますか? 2 つのシステムのデータベースを比較し、何らかの方法で同期させるスクリプトはありますか?実際のコードが展開される前に、明確で、できれば体系的な復旧計画を実装して展開する必要があります。

リモート システムの速度が低下するとどうなりますか?

これは、リモート システムが正常に動作しているかどうかわからないため、完全な障害よりも危険です。この状況に対処するには、常に次の点を確認する必要があります。

リモート システム コールには常にタイムアウトを設定します。これには、リモート API コール、イベント パブリッシング、およびデータベース コールのタイムアウトが含まれます。私はこの単純な欠陥を非常に多くのコードで発見したので、衝撃的ではあるが、予想外でもない。何らかの理由でリモート システムが応答しなくなった場合に待機してリソースを無駄にしないように、呼び出し内のすべてのリモート システムに対して制限された適切なタイムアウトが設定されていることを確認します。

• タイムアウト後の再試行: ネットワークとシステムは信頼性が低く、再試行はシステムの回復力にとって絶対に必要です。再試行により、システム間の相互作用における多くの「バグ」が排除されることがよくあります。可能であれば、再試行時に何らかのバックオフ（固定、指数）を使用します。再試行メカニズムに少しジッターを追加すると、少し余裕ができます。負荷が大きい場合は、呼び出されるシステムを部屋内に配置すると成功率が向上する可能性があります。再試行のもう 1 つの側面はべき等性です。これについては、この記事の後半で説明します。
• サーキットブレーカーを使用する: この機能を事前にパッケージ化した実装は多くありませんが、企業が社内で独自のラッパーを作成しているのを見たことがあります。このオプションがある場合は、ぜひ実践してください。そうでない場合は、構築に投資することを検討してください。エラーが発生したときにフォールバック状況を定義する明確に定義されたフレームワークを持つことの良い前例があります。
• タイムアウトを失敗のように扱わないでください。タイムアウトは失敗ではなく、未定義の解決をサポートする方法で処理する必要がある未定義の状況です。タイムアウトが発生した場合でもシステムが同期を維持できるように、明確な解決メカニズムを確立する必要があります。これらには、単純な調整スクリプトからステートフル ワークフロー、デッドレター キューなどが含まれます。
• バッチ処理を制御された方法で使用します。処理するデータが大量にある場合は、ネットワークのオーバーヘッドを排除するために、リモート呼び出し (API 呼び出し、データベースの読み取り) を 1 対 1 で実行するのではなく、バッチで実行します。ただし、バッチ サイズが大きいほど、全体的な待ち時間が長くなり、失敗する可能性のある作業単位が大きくなることに注意してください。したがって、バッチ処理はパフォーマンスとフォールト トレランスを向上させるために最適化されます。

システムを構築するとき、他の人は

• すべての API はべき等である必要があります。これは、API タイムアウトを再試行することの裏返しです。呼び出し元は、API が安全に再試行でき、予期しない副作用が発生しない場合にのみ再試行する必要があります。 API とは、同期 API と任意のメッセージング インターフェイスを意味します。クライアントは同じメッセージを 2 回発行できます (またはブローカーは同じメッセージを 2 回送信できます)。
• 応答時間とスループットの SLA を明確に定義し、それに準拠するようにコードを作成します。分散システムでは、発信者を待たせるよりも、早く失敗する方がはるかに優れています。確かに、スループット SLA を達成するのは困難です (分散レート制限自体を回避するのは困難です) が、これらの問題を回避したい場合は、SLA を認識し、積極的に通話を失敗させる規定を用意する必要があります。もう 1 つの重要な側面は、ダウンストリーム システムの応答時間を把握して、システムが処理できる最高速を判断できるようにすることです。
• バッチ API の定義と制限: バッチ API を公開する場合、最大バッチ サイズを明確に定義し、必要な SLA によって制限する必要があります。これは、SLA を実現した場合に必然的に生じる結果です。
• 事前に可観測性について考えましょう。可観測性とは、システムの内部を見なくてもシステムの動作を分析できることを意味します。システムについてどのような指標を収集する必要があるか、また、これまで尋ねたことのない質問に答えるためにどのようなデータを収集する必要があるかについて、事前に考えてください。次に、このデータを取得するためにシステムを計測します。これを行うための強力なメカニズムは、システムのドメイン モデルを識別し、ドメインで何かが発生するたびにイベントを発行することです (例: 要求 ID 123 を受信し、要求 123 に対する応答が返される - これら 2 つの「ドメイン」イベントを使用して、「応答時間」と呼ばれる新しいメトリックを導出する方法に注意してください。生データ >> 事前に決定された集計)。

一般的なガイドライン

• プロアクティブなキャッシュ: ネットワークは不安定なので、データの使用方法にできるだけ近い形で、できるだけ多くのデータをキャッシュします。もちろん、キャッシュ メカニズムはリモート (別のマシンで実行されている Redis サーバーなど) にすることもできますが、少なくともデータを制御ドメインに持ち込み、他のシステムの負荷を軽減できます。
• 失敗の単位を考慮する: API またはメッセージが複数の作業単位 (バッチ) を表す場合、失敗の単位は何でしょうか。ペイロード全体が一度に失敗するか、または個々のユニットが独立して成功または失敗するか。部分的に成功した場合、API は成功コードまたは失敗コードで応答しますか?
• システムのエッジで外部ドメイン オブジェクトを分離する: これは長期的に見るともう 1 つの問題です。再利用の名の下に、他のシステムのドメイン オブジェクトをシステム全体で使用すべきではありません。これにより、私たちのシステムが他のシステムのエンティティのモデリングに結合され、他のシステムが変更されるたびに、多くのリファクタリングを行うことになります。常に独自のエンティティ表現を構築し、外部ペイロードをそのスキーマに変換してから、システム内で内部的に使用する必要があります。

これらのガイドラインが、分散システム コードにおける最も一般的なバグの削減に役立つことを願っています。簡単に適用できて非常に効果的な他の考慮事項があると思われる場合は、ぜひお聞かせください。ここに追加できます。