マイクロサービス アーキテクチャでは、明確に定義されたサービス境界を通じて障害を分離できます。ただし、他の分散システムと同様に、ネットワーク、ハードウェア、またはアプリケーション レベルの問題が発生する可能性が高くなります。どのコンポーネントも、サービスの依存関係により、コンシューマが一時的に利用できなくなる場合があります。部分的な停止の影響を最小限に抑えるには、特定の種類の停止に適切に対応できるフォールト トレラントなサービスを構築する必要があります。
この記事では、RisingStack の Node.js コンサルティングおよび開発経験に基づいて、高可用性マイクロサービス システムを構築および実行するための最も一般的なテクノロジとアーキテクチャ パターンを紹介します。
この記事のパターンに慣れていなくても、必ずしも何か間違ったことをしているというわけではありません。信頼性の高いシステムを構築するには、常に追加コストがかかります。
更新: この記事では、RisingStack の Node.js 監視プラットフォームである Trace についていくつか言及しています。2017 年 10 月に、Trace は Keymetrics の APM ソリューションと統合されました。ここをクリックして試してみましょう。
マイクロサービス アーキテクチャのリスク
マイクロサービス アーキテクチャは、アプリケーション ロジックをサービスに移行し、ネットワーク層を使用してサービス間の通信を行います。メモリ呼び出しではなくネットワーク経由で通信すると、システムに追加の遅延と複雑さが生じ、複数の物理コンポーネントと論理コンポーネント間の連携が必要になります。分散システムの複雑さが増すと、特定のネットワーク障害が発生する可能性が高くなります。#microservices を使用すると、コンポーネントが個別に失敗するように設定できるため、サービスの正常な低下を実現できます。
モノリシック アーキテクチャに対するマイクロサービス アーキテクチャの最大の利点の 1 つは、チームが独自にサービスを設計、開発、デプロイできることです。彼らはサービスのライフサイクルに対する完全な所有権を持っています。これは、サービスの依存関係は別のチームによって管理される可能性が高いため、チームがサービスの依存関係を制御できないことも意味します。マイクロサービス アーキテクチャでは、プロバイダー サービスは他者によって制御され、コンポーネントは互いに独立して動作するため、リリース、構成、その他の変更の中断により、プロバイダー サービスが一時的に利用できなくなる可能性があることに留意する必要があります。
正常なサービスの低下
マイクロサービス アーキテクチャの最大の利点の 1 つは、コンポーネントが個別に障害を起こした場合に障害を隔離し、適切なサービスの低下を実現できることです。たとえば、写真共有アプリの停止中は、顧客は新しい写真をアップロードできなくなる可能性がありますが、既存の写真を参照、編集、共有することはできます。
マイクロサービスだけでは失敗します (理論上)
分散システム内のアプリケーションは相互に依存しており、数種類のフェイルオーバー ロジック (一部についてはこの記事で後述します) を適用する必要があるため、ほとんどの場合、この種の適切なサービス低下を実現することは困難です。一時的な障害や停止に備えてください。
サービスは相互に依存しており、フェイルオーバー ロジックなしでは同時に失敗します。
変更管理
Google のサイト信頼性チームは、機能停止の約 70% がリアルタイム システムの変更によって引き起こされていることを発見しました。コードの新しいバージョンをデプロイしたり、構成を変更したりするなど、サービスで何かを変更する場合、失敗したり、新しいバグが発生したりする可能性が常にあります。
マイクロサービス アーキテクチャでは、サービスは相互に依存します。だからこそ、失敗を最小限に抑え、その悪影響を最小限に抑える必要があります。変更に伴う問題に対処するには、変更管理戦略と自動ロールアウトを実装できます。
たとえば、新しいコードをデプロイしたり、一部の構成を変更したりする場合は、それらの変更をインスタンスのサブセットに徐々に適用して監視し、デプロイメントが主要なメトリクスに悪影響を与えていることに気付いた場合は自動的に元に戻す必要もあります。
変更管理 – ローリング展開
別の解決策は、2 つの実稼働環境を実行することです。常にいずれか 1 つにのみデプロイし、新しいバージョンが期待どおりに動作することを確認した後でのみ、ロード バランサーを新しいバージョンに向けます。これは、青緑または赤黒展開と呼ばれます。
コードを元に戻すことは悪いことではありません。壊れたコードを実稼働環境に残したままにして、何が問題だったのかを解明すべきではありません。必要に応じて、常に変更を元に戻してください。早いほど良い。
ヘルスチェックとロードバランシング
インスタンスは、障害、デプロイメント、または自動スケーリングにより、常に起動、再起動、停止を繰り返します。一時的または永久的に利用できなくなります。問題を回避するには、ロード バランサーは、顧客やサブシステムのニーズを満たすことができない異常なインスタンスをルートからスキップする必要があります。
アプリケーション インスタンスの健全性は、外部からの観察によって判断できます。これを行うには、GET /health エンドポイントを繰り返し呼び出すか、自己報告を行います。最新のサービス検出ソリューションは、インスタンスから正常性情報を継続的に収集し、正常なコンポーネントにのみトラフィックをルーティングするようにロード バランサーを構成します。
自己修復
自己修復はアプリケーションの復元に役立ちます。アプリケーションが破損した状態から回復するために必要な手順を実行できる場合、自己修復について話すことができます。ほとんどの場合、これはインスタンスの健全性を監視し、長期間にわたって破損した状態にある場合にインスタンスを再起動する外部システムによって実装されます。自己修復はほとんどの場合に優れていますが、場合によっては、アプリケーションを頻繁に再起動することで問題が発生する可能性があります。これは、過負荷またはデータベース接続のタイムアウトにより、アプリケーションが肯定的な正常性ステータスを提供できない場合に発生する可能性があります。
データベース接続の喪失などの微妙な状況に備えた高度な自己修復ソリューションを実装するのは難しい場合があります。この場合、エッジケースを処理し、インスタンスをすぐに再起動する必要がないことを外部システムに知らせるために、アプリケーションに追加のロジックを追加する必要があります。
キャッシュフェイルオーバー
ネットワークの問題やシステムの変更により、サービスが失敗することがよくあります。ただし、これらの停止のほとんどは、自己修復機能と高度な負荷分散により一時的なものであるため、これらの障害中にサービスを動作し続けるためのソリューションを見つける必要があります。ここで、フェイルオーバー キャッシュが役立ち、必要なデータをアプリケーションに提供できます。
通常、フェイルオーバー キャッシュでは 2 つの異なる有効期限が使用されます。短い方は通常の状態でキャッシュを使用できる期間を示し、長い方は障害時にキャッシュされたデータを使用できる期間を示します。
フェイルオーバーキャッシュ
フェイルオーバー キャッシュは、古いデータを提供しないよりも良い場合にのみ使用する必要があることに注意してください。
キャッシュとフェイルオーバー キャッシュを設定するには、HTTP の標準応答ヘッダーを使用できます。
たとえば、max-age ヘッダーを使用すると、リソースが新鮮であるとみなされる最大時間を指定できます。stale-if-error ヘッダーを使用すると、障害が発生した場合にリソースをキャッシュから提供する期間を決定できます。
最新の CDN とロード バランサーは、さまざまなキャッシュとフェイルオーバーの動作を提供しますが、会社用の標準信頼性ソリューションの共有ライブラリを作成することもできます。
再試行ロジック
場合によっては、データをキャッシュできないか、データを変更したいのに、最終的に操作が失敗することがあります。このような場合、しばらくするとリソースが回復するか、ロードバランサーがリクエストを正常なインスタンスに送信すると予想できるため、操作を再試行できます。
再試行ロジックをアプリケーションやクライアントに追加する場合は、再試行回数が多いと状況が悪化したり、アプリケーションの回復が妨げられたりする可能性があるため、注意が必要です。
分散システムでは、マイクロサービス システムの再試行により、他の複数のリクエストまたは再試行がトリガーされ、カスケード効果が開始される可能性があります。再試行の影響を最小限に抑えるには、再試行の回数を制限し、指数バックオフ アルゴリズムを使用して、最大制限に達するまで再試行間の遅延を継続的に増加させる必要があります。
再試行はクライアント (ブラウザー、他のマイクロサービスなど) によって開始され、クライアントはリクエストが処理されるまでまたは処理された後に失敗を認識しないため、冪等性を処理するようにアプリケーションを準備する必要があります。たとえば、購入を再試行する場合、顧客に二重請求を行うべきではありません。各トランザクションに一意の冪等キーを使用すると、再試行が容易になります。
レート リミッターとロード シェダー
レート制限は、特定のクライアントまたはアプリケーションが一定期間に受信または処理できるリクエストの数を定義する手法です。たとえば、レート制限を使用すると、トラフィックの急増を引き起こすクライアントやマイクロサービスをフィルターで除外したり、自動スケーリングで保存できなくなるまでアプリケーションが過負荷にならないようにしたりできます。
優先度の低いトラフィックをブロックして、重要なトランザクションに十分なリソースを提供することもできます。
レートリミッターによりトラフィックのピークを抑制できる
別のタイプのレート リミッターは、同時リクエスト リミッターと呼ばれます。これは、指定された時間より長く呼び出すべきではない高価なエンドポイントがあるが、それでもトラフィックを処理したい場合に便利です。
ロード シェダーを使用するフリートでは、重要なトランザクションにサービスを提供するために十分なリソースを常に利用できるようにすることができます。これは、優先度の高いリクエスト用に一部のリソースを予約し、優先度の低いトランザクションがこれらのリソースをすべて使用することを許可しません。オフローダーは、個々のユーザー リクエストのバケット サイズではなく、システム全体の状態に基づいて決定を行います。アンインストーラーは、進行中のイベントが発生している間もコア機能を動作し続けるため、システムの回復に役立ちます。
レート リミッターとロード シュレッダーの詳細については、Stripe の記事を参照することをお勧めします。
迅速かつ独立して失敗できる
マイクロサービス アーキテクチャでは、サービスがすぐに独立して失敗するようにしたいと考えています。サービス レベルの問題を分離するには、バルクヘッド パターンを使用できます。バルクヘッドの詳細については、このブログ投稿で後ほど説明します。
また、壊れたインスタンスがタイムアウトになるまで待ちたくないので、コンポーネントがすぐに失敗するようにしたいと考えています。リクエストのハングや応答しない UI ほどイライラするものはありません。これはリソースの無駄であるだけでなく、ユーザー エクスペリエンスも台無しにします。私たちのサービスは連鎖しているため、これらの遅延が解消されるまで保留中の操作が発生しないように特別な注意を払う必要があります。
最初に思い浮かぶのは、各サービス呼び出しにきめ細かいタイムアウトを適用することです。このアプローチの問題は、ネットワーク障害やその他の問題は場合によっては 1 つまたは 2 つの操作にしか影響しないため、適切なタイムアウト値が実際にはわからないことです。この場合、タイムアウトしたリクエストが数件だけであっても、リクエストを拒否したくないでしょう。
タイムアウトを使用してマイクロサービスにフェイルファスト パラダイムを実装するのはアンチパターンであり、避ける必要があると言えます。タイムアウトの代わりに、操作の成功/失敗統計に応じたサーキット ブレーカー パターンを適用できます。
パーティション
隔壁は、船体が破損した場合に各セクションを密閉できるように、船舶をセクションに分割するために業界で使用されています。
バルクヘッドの概念をソフトウェア開発に適用して、リソースを分離できます。
バルクヘッド パターンを適用することで、限られたリソースを枯渇から保護できます。たとえば、限られた数の接続で同じデータベース インスタンスと通信する 2 つの操作がある場合、共有の代わりに 2 つの接続プールを使用できます。このクライアントとリソースの分離により、操作がタイムアウトになったり、プールをオーバーコミットしたりしても、他のすべての操作が停止することはありません。
タイタニック号が沈没した主な理由の 1 つは、その隔壁が隔壁の上部から上甲板に水が流れ込み、船体全体が水没するように設計されていたことでした。
タイタニック号の隔壁（機能しなかった）
ブレーカ
操作の継続時間を制限するには、タイムアウトを使用できます。タイムアウトにより操作のハングが防止され、システムの応答性が維持されます。ただし、マイクロサービス通信で静的で微調整されたタイムアウトを使用することはアンチパターンです。なぜなら、非常に動的な環境にあり、あらゆる状況で適切に機能する正しい時間制限を考え出すのはほぼ不可能だからです。
トランザクション固有の小さな静的タイムアウトを使用する代わりに、サーキット ブレーカーを使用してエラーを処理できます。サーキットブレーカーは、実際の電子コンポーネントの動作が同じであるため、その名前にちなんで名付けられています。サーキット ブレーカーでリソースを保護し、回復を支援できます。これらは、繰り返し障害が雪だるま式に発生し、システム全体が停止する可能性がある分散システムでは非常に役立ちます。
特定の種類のエラーが短期間に複数回発生すると、サーキット ブレーカーが開きます。オープンサーキットブレーカーは、実際のサーキットブレーカーが電子の流れを止めるのと同じように、さらなるリクエストをブロックします。通常、サーキット ブレーカーは、基盤となるサービスを再開するための十分な余地を与えるために、一定時間が経過すると閉じられます。
すべてのエラーがサーキット ブレーカーをトリガーするわけではないことに注意してください。たとえば、4xx 応答コードを持つリクエストなどのクライアント側の問題をスキップし、5xx サーバー側の障害を含めることができます。一部のサーキットブレーカーは半開きのままにすることもできます。この状態では、サービスはシステムの可用性を確認するために最初のリクエストを送信し、他のリクエストは失敗します。最初のリクエストが成功すると、サーキット ブレーカーが閉じた状態に戻り、トラフィックが流れるようになります。それ以外の場合は、開いたままになります。
サーキットブレーカー
テストは失敗しました
サービスがさまざまな障害に耐えられることを確認するために、一般的な問題についてシステムを継続的にテストする必要があります。チームをインシデントに備えるために、頻繁に障害をテストする必要があります。
テストのために、インスタンスのグループを識別し、そのグループ内のインスタンスをランダムに終了する外部サービスを使用できます。これにより、単一インスタンスの障害に備えることができますが、リージョン全体をシャットダウンして、クラウド プロバイダーの停止をシミュレートすることもできます。
最も人気のあるテスト ソリューションの 1 つは、Netflix の ChaosMonkey 復元ツールです。
オテロ
信頼性の高いサービスを実装して実行するのは簡単ではありません。それはあなたの側で多大な労力を必要とし、会社のお金もかかります。
信頼性には多くの層と側面があるため、チームにとって最適なソリューションを見つけることが重要です。ビジネス上の意思決定プロセスに信頼性を考慮し、そのために十分な予算と時間を割り当てる必要があります。
キーポイント
-
動的環境やマイクロサービスなどの分散システムでは、障害が発生する可能性が高くなります。
-
サービスは個別に失敗する必要があり、正常な機能低下を可能にしてユーザー エクスペリエンスを向上させます。
-
機能停止の 70% は変更が原因であり、コードを元に戻すことは悪いことではありません。
-
すぐに独立して失敗します。チームはサービスの依存関係を制御できません。
-
キャッシュ、バルクヘッド、サーキット ブレーカー、レート リミッターなどのアーキテクチャ パターンとテクニックは、信頼性の高いマイクロサービスの構築に役立ちます。
| この記事: https://jiagoushi.pro/designing-microservices-architecture-failure#google_vignette | ||
| ディスカッション: Knowledge Planet [チーフ アーキテクト サークル] または WeChat トランペット [ca_cto] を追加するか、QQ グループを追加します [792862318] | ||
| 一般公開なし |
【jiagoushipro】 【スーパーアーキテクト】 アーキテクチャの方法論、アーキテクチャの実践、技術原則、技術トレンドについての鮮やかなグラフィックと詳細な説明。 お待ちしておりますので、ぜひスキャンしてご注目ください。 |
|
| WeChatのトランペット |
[ca_cea] エンタープライズ アーキテクチャ、クラウド コンピューティング、ビッグ データ、データ サイエンス、モノのインターネット、人工知能、セキュリティ、フルスタック開発、DevOps、デジタル化について議論する 50,000 人のコミュニティ。 |
|
| QQグループ |
[285069459] エンタープライズ アーキテクチャ、ビジネス アーキテクチャ、アプリケーション アーキテクチャ、データ アーキテクチャ、技術アーキテクチャ、統合アーキテクチャ、セキュリティ アーキテクチャの詳細な交換。そして、ビッグデータ、クラウドコンピューティング、モノのインターネット、人工知能などのさまざまな新興テクノロジー。 QQ グループに参加して、貴重なレポートや乾物を共有してください。 |
|
| ビデオ番号 | 【スーパーアーキテクト】 建築に関する基本的な概念、モデル、手法、経験が1分ですぐに理解できます。 1日1分、仕組みはおなじみです。 |
|
| 知識の惑星 | [チーフアーキテクトサークル] 著名人に質問したり、連絡を取ったり、プライベートな情報を共有したりしてください。 | |
| ヒマラヤ | [スーパーアーキテクト] 最新のブラックテクノロジー情報と建築体験を道路や車の中で学びましょう。 | [知的な瞬間、ミスター・アーキテクチャーがブラックテクノロジーについて語ります] |
| 知識の惑星 | より多くの友人、職場、技術的なチャットに会いましょう。 | ナレッジプラネット【職場とテクノロジー】 |
| リンクトイン | ハリー | https://www.linkedin.com/in/architect-harry/ |
| LinkedInグループ | LinkedIn アーキテクチャ グループ | https://www.linkedin.com/groups/14209750/ |
| 微博 | 【スーパーアーキテクト】 | 賢い瞬間 |
| ビリビリ | 【スーパーアーキテクト】 | |
| チクタク | 【cea_cio】スーパーアーキテクト | |
| 早い労働者 | 【cea_cio_cto】スーパーアーキテクト | |
| 小さな赤い本 | [cea_csa_cto] スーパーアーキテクト | |
| Webサイト | CIO（最高情報責任者） | https://cio.ceo |
| Webサイト | CIO、CTO、CDO | https://cioctocdo.com |
| Webサイト | アーキテクトの実践的な共有 | https://architect.pub |
| Webサイト | プログラマーによるクラウド開発の共有 | https://pgmr.cloud |
| Webサイト | チーフアーキテクトコミュニティ | https://jiagoushi.pro |
| Webサイト | アプリケーション開発と開発プラットフォーム | https://apaas.dev |
| Webサイト | 開発情報ネットワーク | https://xinxi.dev |
| Webサイト | スーパーアーキテクト | https://jiagou.dev |
| Webサイト | 企業向け技術トレーニング | https://peixun.dev |
| Webサイト | プログラマーの本 | https://pgmr.pub |
| Webサイト | 開発者チャット | https://ブログ.開発者.チャット |
| Webサイト | CPOコレクション | https://cpo.work |
| Webサイト | 最高セキュリティ責任者 | https://cso.pub |
| Webサイト | CIOクール | https://cio.cool |
| Webサイト | CDO情報 | https://cdo.fyi |
| Webサイト | CXO情報 | https://cxo.pub |
ご清聴、転送、いいね、ご視聴ありがとうございます。