マイクロサービスアーキテクチャ
Netflix は AWS 上で実行されます。彼らはモノリスから始まり、マイクロサービスに移行しました。マイクロサービスに移行する理由は次のとおりです。
- 単一のコードベースに多くの変更が加えられているため、バグを見つけるのが困難でした
- 縦方向のスケーリングが難しくなった
- 単一点障害が多数ありました
マイクロサービスの利点
この投稿では、Netflix から得たマイクロサービスのレッスンの概要を説明します。
マイクロサービスの課題と解決策
マイクロサービス アーキテクチャに関する主な問題は次の 3 つです。
- 依存
- 規模
- 分散
1. 依存関係
依存関係の問題が発生する 4 つのシナリオを次に示します。
i) サービス内リクエスト
クライアント要求により、サービスが別のサービスを呼び出します。言い換えれば、サービス A は応答を作成するためにサービス B を呼び出す必要があります。
サービス内リクエスト
問題は、マイクロサービスの障害が連鎖的な障害を引き起こすことです。解決策は次のとおりです。
- 使用サーキットブレーカーのパターン連鎖的な障害を防ぐため。失敗する可能性のある操作を回避します
- 障害挿入テストを実行して、サーキット ブレーカー パターンが期待どおりに機能するかどうかを確認します。人工的なトラフィックを作成することでそれを実現します
- システムを常に応答可能な状態に保つために、静的ページへのフォールバックを設定します。
- 雷を伴う群の問題を防ぐために指数バックオフをインストールする
しかし、可用性の低下とシステムテストの範囲の拡大が問題になります。個々のマイクロサービスのダウンタイムが重なると可用性が低下するためです。そして、マイクロサービスの数が増加するにつれて、テスト範囲の順列はトン単位で増加します。
したがって、重要なサービスを特定し、重要ではないサービスの障害を回避するバイパス パスを作成することが重要です。
ii) クライアントライブラリ
API ゲートウェイを使用すると、さまざまな種類のクライアント間でビジネス ロジックを再利用できます。
API ゲートウェイは、 APIリクエストをルーティングする中心的なエントリ ポイントです。ただし、次の制限があります。
- ヒープ消費の管理が難しくなる
- 潜在的な論理的欠陥またはバグ
- 潜在的な推移的な依存関係
したがって、解決策は、API ゲートウェイをシンプルにし、新しいモノリスにならないようにすることです。
iii) 持続性
ストレージ層の選択は、CAP 定理によって異なります。言い換えれば、これは可用性と一貫性レベルの間のトレードオフの決定です。
したがって、解決策は、データ アクセス パターンを調査し、適切なストレージを選択することです。
iv) インフラストラクチャー
データセンター全体が故障する可能性があります。したがって、解決策は、多くのデータセンターにわたってインフラストラクチャを複製することです。
Netflixのサービス停止。フォーブス.com
2.スケール
パフォーマンスを維持しながら増加するワークロードを管理するシステムの能力は、スケールと呼ばれます。水平方向のスケーラビリティの 3 つの側面は次のとおりです。
- 可能であればサービスをステートレスにしておく
- ステートレスにできない場合はサービスを分割する
- サービスをレプリケートする
ステートフル サービスとステートレス サービス
スケールの問題が発生する 3 つのシナリオを次に示します。
i) ステートレスサービス
ステートレス サービスの 2 つの品質は次のとおりです。
- インスタンス アフィニティ (スティッキー セッション) はありません。別の言い方をすると、リクエストは同じサーバーにルーティングされません。
- ステートレス サービスの障害は顕著ではない
高可用性を実現するには、ステートレス サービスを複製する必要があります。また、オンデマンド レプリケーション用に自動スケーリングを設定する必要があります。
また、自動スケーリングにより、次の問題の影響が軽減されます。
- 計算効率の低下
- ノード障害
- トラフィックの急増
- パフォーマンスのバグ
データベースとキャッシュはステートレス サービスではありません。
カオス エンジニアリングは、自動スケーリングが期待どおりに機能するかどうかをチェックします。制御された中断を通じてシステムの復元力をテストし、信頼性の向上を保証します。
ii) ステートフル サービス
データベースとキャッシュはステートフル サービスです。大量のデータを保持するカスタム サービスもステートフル サービスです。ステートフル サービスの障害は注目に値するイベントです。
ステートフル サービスのアンチパターンは、レプリケーションを行わずにスティッキー セッションを実行することです。単一障害点が発生するためです。
解決策は、異なるデータセンターにある多数のサーバー間で書き込みを複製することです。そして、読み取りをローカル データ センターにルーティングします。
iii) ハイブリッド サービス
キャッシュはハイブリッド サービスです。ハイブリッド サービスでは、極度の負荷が予想されます。たとえば、Netflix のキャッシュは 1 秒あたり 3,000 万件のリクエストを受け取ります。
ハイブリッド サービスを構築するための最良のアプローチは次のとおりです。
- コンシステントハッシュなどの手法を使用してワークロードを分割する
- リクエストレベルのキャッシュを有効にする
- データベースへのフォールバックを許可する
また、カオス エンジニアリングを使用して、極端なワークロード下でもハイブリッド サービスが機能し続けるかどうかを確認します。
3. 分散
ソフトウェア アーキテクチャの多様性は差異と呼ばれます。分散が増加すると、システムの複雑さも増大します。
スケールの問題が発生する 2 つのシナリオを次に示します。
i) 運用上のドリフト
運用ドリフトは、時間の経過とともに発生する意図しない変動です。これは通常、システムに追加された新機能の副作用です。運用上のドリフトの例は次のとおりです。
- アラートしきい値の増加
- タイムアウトの増加
- スループットの低下
これに対する解決策は、継続的な学習と自動化です。
継続的な学習と自動化
ワークフローは次のとおりです。
- インシデントの解決策を確認する
- 再発を防ぐために適切な修復策を講じる
- 多くのインシデントを分析してパターンを特定する
- インシデント解決からベストプラクティスを導き出す
- 可能であればベストプラクティスを自動化する
- ベストプラクティスの採用を促進する
- そして繰り返します
ii) 多言語
エンジニアが意図的に導入した差異はポリグロットと呼ばれます。これは、異なるプログラミング言語を使用して異なるマイクロサービスを作成した場合に発生します。
これには次のような欠点があります。
- 生産的なツールを入手するには大量の作業が必要
- 運用がさらに複雑になる
- サーバー管理の難しさ
- 多くのテクノロジーにわたるビジネス ロジックの重複
- 専門家になるための学習曲線が長くなる
この問題の解決策は、実証済みのテクノロジーを使用することです。
さらに、ポリグロットは API ゲートウェイの分解を強制しますが、これは良いことです。したがって、Polyglot アーキテクチャを使用する最良の方法は次のとおりです。
- 各テクノロジーのコストに対するチームの意識を高める
- 一元化されたサポートを重要なサービスに限定する
- 影響に基づいて優先順位を付ける
- 実績のあるテクノロジーのプールを提供することで、再利用可能なソリューションを作成します
以下は、Netflix のマイクロサービス アーキテクチャのベスト プラクティスのチェックリストです。
- タスクを自動化する
- アラートのセットアップ
- 動的負荷を処理するための自動スケール
- カオスエンジニアリングによる信頼性の向上
- 一貫した命名規則
- 健康診断サービス
- ブルーグリーン展開による迅速なロールバック
- タイムアウト、再試行、フォールバックを構成する
また、変化は避けられず、変化によって物事は常に壊れます。したがって、最善のアプローチは、より迅速に、ただし互換性を損なう変更を少なくすることです。
さらに、ソフトウェア アーキテクチャをサポートするためにチームを再構築することも役立ちます。
出典 : https://medium.com/@mananshah3654/microservices-lessons-from-netflix-50cc66d8fd45
