本文主要依据微サービス、"安定性リスクの防止" および "障害の影響を軽減する" という 2 つの側面から、安定性の構築に直面する一般的な問題を簡単に紹介しています。
1. 安定性リスクの防止#
マイクロサービスアーキテクチャにより、マイクロサービスの機能はより内包され、イテレーション速度が向上しますが、サービスの依存関係の複雑さが増し、それにより安定性の構築の難しさが増します。依存関係の複雑さは、上流サービス、自身のサービス、下流サービスの関係に抽象化できます。安定性リスクの防止の主なアプローチは、これら 3 つのリスクを防ぐことです。
1.1 上流リスクの防止#
トラフィック制限、入力検証。
上流リスクの防止では、一般的には **"トラフィックの増加"と"入力エラー"** のリスクを防ぐことが重要です。予測されるトラフィックの増加には、事前に容量評価を行い、関連する対応策を準備することができます。予期しないトラフィックの増加に対しては、事前に設定されたトラフィック制限の計画に依存します。
トラフィック制限の目的は、自己保護または影響の隔離です。コアトラフィックの制限後、影響を評価し、拡張容量または一時的なトラフィック制限の閾値の調整を行うことができます。
"入力エラー" の一般的な例は、範囲パラメータの制限がないことです。たとえば、予想されるのは 1 日のデータのみのクエリですが、リクエストパラメータに 1 か月のクエリが渡され、インターフェースに制限がないため、データベースが圧力に耐えられずにダウンしてしまいます。
1.2 下流リスクの防止#
強い依存関係の解除、ダウングレード、弱い依存関係の検証、トラフィックの切り替え計画。
業界では、** 異常が発生しても、コアビジネスプロセスに影響を与えず、システムの可用性に影響を与えない依存関係を弱い依存関係と呼びます。** 下流リスクを解除する最も直接的な方法は、下流の強い依存関係を解除することです。
- システムの設計時に、システムの強い依存関係と弱い依存関係を包括的に分析し、オンラインでのトラフィックを収集して依存関係をさらに分析することができます。
- 過去のビジネスを改善し、機能、エクスペリエンス、および安定性の観点で妥協する必要があります。安定性を確保するために、下流の依存関係の障害時には、非コア機能を削減して、コア機能が常に利用可能であることを確保します。
弱い依存関係には、ダウングレードの計画が必要です。Sentinel などのさまざまなオープンソースのトラフィック制御コンポーネントを使用できます。計画の実行効率を確保するためには、ビジネスコードのエラーハンドリングと自動フューズ機能を組み合わせることがより推奨される方法です。
ダウングレード方法の選択は、ビジネスのダウングレードの影響度に大きく関連しています。一般的に、大きな影響を与える場合は手動でダウングレードし、影響が小さいか、後で自動的に修正できる機能の場合は、自動ダウングレードを検討できます。
強い依存関係を解除できない場合は、リスクを軽減するためのいくつかの方法を検討し、安定性を向上させ、大きな問題を回避します。
- MySQL では、単一のシャードの影響を軽減するために、十分な数のシャードを追加することができます。
- 緊急時のバックアップ計画を策定し、良好なユーザーエクスペリエンスを提供する必要があります。
- 単一のデータセンターの障害時には、トラフィックの切り替えを優先する必要があります。
1.3 自己リスクの防止#
アーキテクチャリスク、容量リスク、トラフィックの切り替え計画、オンライン変更の規範、開発およびテストの品質保証。
基本的なことは、冗長なデプロイメント、アクティブアクティブのトラフィック切り替えによって単一障害点を回避することです。弾力性のあるクラウド、自動スケーリングにより、容量リスクを減らすことができます。定期的なセンチネル負荷テスト、エンドツーエンドの負荷テスト、モジュールレベルの負荷テストにより、容量評価を行います。
オンラインの問題と構成の変更が原因で発生するオンラインの事故のほとんどです。したがって、開発とテストの品質を向上させ、オンラインの変更規範を厳守することが自己リスクを防ぐための重要なポイントです。
開発の品質を向上させるためには、特に安定性の観点から、開発者は自動化テストケースを作成する意識を持つ必要があります。短期的には、テストケースの作成には開発の時間コストがかかりますが、テストケースは後のイテレーションのテスト効率とコード品質を大幅に向上させることができます。コアビジネスシステムでは、継続的なイテレーションが必要ですので、長期的にはテストケースのコストは受け入れられるものです。
2. 障害の影響を軽減する#
人は間違いを com するため、障害は避けられません。リスクを防ぐだけでなく、障害の影響を軽減するためのいくつかの対策が必要です。
2.1 自己インターフェースのダウングレード#
コアリンクの上流依存関係を明確にし、インターフェースの能力をダウングレードする。
ビジネスリンクの一部として、自身のサービスが上流のコアリンクの強弱の依存関係を明確にする必要があります。上流が自身のサービスに弱い依存関係を持つ場合、依存されるインターフェースがインターフェースの能力をサポートすることを保証する必要があります。上流が自身のサービスに強い依存関係を持つ場合は、上流が自身のサービスへの強い依存関係を解消するための取り組みを検討する必要があります。解消できない場合は、チャネルの構築やその他の上流への影響を軽減する方法を検討する必要があります。例えば、ユーザー向けの障害案内メッセージ、公告などです。
要するに、自身のサービスの安定性だけでなく、上流の自身のサービスへの依存関係にも注意を払い、それに対応する計画を立てることで、自身のサービスの障害が上流に与える影響を軽減する必要があります。ここでのインターフェースの能力のダウングレードは、先述の依存関係のダウングレードとは異なるものです。ここでのインターフェースの能力のダウングレードは、自身のサービスの能力のダウングレードであり、上流のサービスへの影響を減らすことを目的としています。これは、サービスが異なるレベルにある場合の異なる計画です。
2.2 障害の検知と特定#
モニタリングアラート、障害の原因特定、緊急対応プロセス。
コアサービスの指標やビジネス指標のモニタリングとアラートは、できるだけ 100% カバーするようにします。カバレッジは一つの側面ですが、アラートのタイムリネスと正確性も非常に重要です。リンクの可観測性、ログのトレース性、サーバーのパフォーマンスの可視化を行うことは、障害の検知と原因特定の有効なツールです。
指標の構築時には、メトリック指標の標準化を検討することで、理解コストを削減し、問題の特定効率を向上させることができます。
コア指標のアラートのタイムリネスと正確性を向上させるためには、特定の方向からの重点的なモニタリングを検討することで、メンテナンスコストを削減することができます。ビジネス結果指標のモニタリングを推奨します（プロセス指標は問題の特定を支援するために使用できます）。その理由は、ビジネスプロセス指標は多く、頻繁に変更される可能性があり、複数のシステムをまたがって分散しているためですが、その結果は収束する傾向があります。