Clever Geek Handbook

請求の回復力を高める方法：Hydraの経験





複雑なシステムを独自に開発する際に、企業がどのような問題を抱えるかについてはすでに書きました。 コメントでは、読者は私たちのプロジェクトの技術的なコンポーネントについてもっと話をするように私たちに頼んだ-電気通信事業者「 ハイドラ 」への請求。



この要求を満たすために、今日はシステムのフォールトトレランスを向上させるためにどのように取り組んだかについてお話します。



課金コンポーネント：信頼性が最も重要な場所



課金は、年中無休で24時間365日稼働する必要があるシステムです。 したがって、すべてのコンポーネントの冗長性が必要です。 課金システムの構成を詳しく見てみましょう。



データ



加入者が消費したサービス、個人口座の残高、支払いの詳細および償却についての情報。 これは最も価値のあるビジネス情報です。つまり、最初に保存する必要があります。







コア



コアは、すべてのデータ操作が実行されるシステムの一部です。 Hydraでは、データと統合されています。ビジネスロジックは、ストアドプロシージャの形式でDBMSに直接配置されています。 データを外部アプリケーションに直接変更することは禁止されています。これはAPIを介してのみ実行できます。 したがって、データを使用できるようにするには、カーネルが動作し続ける必要があります。



AAAサーバー（認証、承認、アカウンティング）



サブスクライバーによって消費されるサービスに関する重要な情報の認証、許可、およびアカウンティングを担当する要素。 ネットワーク機器は、AAAサーバー（サービスへのアクセスを提供するサーバー）と対話します。 AAAサーバーに障害が発生した場合、原則として、加入者は新しいセッションを開いたり、新しいサービスを接続したり、古いサービスを切断したりすることができなくなります。



さらに、そのような状況では、すでに提供されたサービスに関する情報が失われる可能性があります。これは、顧客に不便をもたらすだけでなく、請求失敗時のサービスの「無料」提供にもつながります。 したがって、AAAサーバーは、システム全体の最も機密性の高いコンポーネントの1つです。



支払いゲートウェイ



さまざまな支払いシステムから行われた支払いに関する情報を受け入れます。 ゲートウェイに障害が発生すると、顧客が自分の請求先アカウントに行った支払いに関する情報の通過が遅れます。



場合によっては、これはサービスの品質に悪影響を与える可能性があります。たとえば、すべての加入者が月の初日に決済日を持ち、その日に障害が発生した場合などです。 この時点で支払いゲートウェイに障害が発生すると、購読者は、未払いで切断された場合、個人アカウントを補充できなくなり、サービスへのアクセスを取り戻すことができなくなります。



支払いゲートウェイの操作性は、カーネルの操作性に依存します。これは、カーネルが利用できない場合、口座への資金の受領について他の課金コンポーネントに通知できないためです。 ただし、数時間のダウンタイムで深刻な問題が発生することはほとんどありません。これは、エラーに応答して以前のリクエストが受信された場合、ほぼすべての支払いシステムが自動的に再度支払いを行うため、サービス自体を復元する以外に何もする必要がないためです。



サブスクライバーのアカウントとWebコントロールパネル



課金コントロールパネルとユーザーの個人アカウントがクラッシュした場合、課金自体は引き続き機能しますが、会社の従業員と顧客は一時的にシステムを操作できなくなります。



何をどのように予約しますか？



上記では、課金の主要なコンポーネントと、フォールトトレランスを確保するという点でのそれらの重要性を検討しました。 次に、システムの信頼性を高めるために行った手順について説明します。



一般的なアプローチの説明から始めましょう。 課金コンポーネントは、状態を保存するカテゴリと保存しないカテゴリの2つに大別されます。 状態は伝統的にデータベースに保存されます。2つありますが、通常の操作ではアクティブにデータを交換します。



メインデータベースの予約



メインデータベースには、データとシステムのコアが格納されます。 縮退した3層アーキテクチャを使用します。ビジネスロジック（Oracleのストアドプロシージャと関数）とデータ（テーブル）はDBMSに密接に統合され、ブラウザ（「シンクライアント」）はクライアントとして機能し、Webインターフェイスはカーネルのプログラムシェルとして機能します。 Oracle DatabaseはRDBMSとして使用されるため、製造元が推奨するメインデータベースのバックアップ方法を使用します。



  1. 定期的なバックアップの削除 。 しかし、最も簡単な方法は、特定の困難を抱えています-使用中のデータの回復には時間がかかり、このプロセスの終わりには情報は無関係になります。 Oracleのバックアップを削除するには、 expdpユーティリティを使用できます-小規模なインストール（使いやすく、データが長期間回復します）、およびユニバーサルRMANマネージャー。スケジュールに従って完全バックアップと増分バックアップを削除し、それらを解凍できます。
  2. redo-DBMSログをstandby-serverにコピーしています 。 この方法では、作業データベースからの変更がスタンバイサーバーに適用される「ホット」バックアップを整理できます。 稼働中のサーバーに障害が発生した場合、メンテナンスは現在のデータとともに自動的にまたは手動でバックアップサーバーに転送されます。


バックアップサーバーへの切り替えを高速化するために、ちょっとしたトリックを使用します。 プライマリサーバーとバックアップサーバーには独自のIPアドレスがあります。 それらの上にIPエイリアスがあり、通常はメインサーバーでハングします。 障害が発生した場合、このエイリアスはバックアップサーバーにすばやく「転送」できます。ユーザーは違いに気付かないでしょう。



お申し込み



AAAサーバー（後述）を除くすべてのアプリケーションは、状態をメインデータベースに保存するため、バックアップサーバーでは、正しいバージョン自体のアプリケーション、その構成ファイル、および起動スクリプトのみを保持する必要があります。



アプリケーションはバックアップデータベースと連携するように構成されており、いつでも着信要求を受け入れる準備ができています。これは、バックアップデータベースがアクティブモードに切り替えられた後に処理されます。



AAAサーバーの予約



AAAサーバーは、システムが中断に対して最も敏感なコンポーネントです。 厳密に言えば、課金には適用されませんが、課金と連動します。 アクセスサーバーが利用できなくなるとすぐに、加入者はすぐにこれに気付きます。 許容されるダウンタイムは数分です。それ以外の場合、加入者はあらゆる規模のコールセンターのコールで「いっぱい」になります。



原則として、AAAサーバーは、メインデータベースを備えたサーバーの可用性に依存しないように、サブスクライバーに近い別の物理マシンに配置されます。 これは、AAAサーバーをコアから切断するリスクが高い地理的に分散したネットワークに非常に役立ちます。



アクセスサーバー自体は、自動と手動の2つのモードで予約されています。 自動バックアップを行うには、少なくとも3つの物理サーバーが必要です（ネットワークの切断、netsplitの問題を解決するため）。 手動モードの場合、2台のサーバーで十分ですが、この場合、負荷を切り替える決定は、職務担当者が行う必要があります。



自動フェールオーバーインストールの例を考えてみましょう。





各AAAサーバーは3つのコンポーネントで構成されています。



  1. 加入者プロファイルと消費されたサービスのデータを含むデータベース。
  2. HARDというコードネームのアプリケーション。 次のコンポーネントからのHTTP要求に応答します。
  3. FreeRADIUS-標準のAAAプロトコルを実装するサーバー-RADIUS。 加入者ネットワークと直接通信し、バイナリ形式のリクエストを通常のHTTP + JSON for HARDに変換します。


すべてのAAAサーバー（これはMongoDB）のデータベースは、1つのメインノード（マスター）と2つのスレーブでグループ化されます。 サブスクライバネットワークからのすべての要求は1つのAAAサーバーに送られますが、メインデータベースを備えたサーバーである必要はなく、望ましくない場合もあります。



何かがうまくいかず、コンポーネントの1つが失敗した場合に何が起こるか見てみましょう：





したがって、非グローバル障害が発生しても、サービスへの加入者アクセスが失われることはありません。 何が起こっても、ユーザーは何も気付かない可能性があります。



おわりに



私たちのプロジェクトは8年間開発されており、この間に80以上の実装プロジェクトに参加しました。 私たちは、システムの信頼性と顧客にとっての利便性の向上に常に取り組んでいます。



今後の投稿では、Hydraのアーキテクチャ、テクノロジー、およびその開発に使用されるアプローチについて引き続き説明します。



興味深い情報をお見逃しなく、ブログを購読してください ！


More articles:


All Articles