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