はじめに

多くの自動化プラットフォームは、シングルノードアーキテクチャから始まります。1つのプロセスがUI の提供、ジョブの実行、スケジュールの管理、リアルタイム更新の処理を行います。この構成はシンプルですが、単一障害点も生み出します。そのプロセスが停止すると、自動化も停止します。

大規模なインフラストラクチャ自動化を実行する組織にとって — 特にDevOpsやプラットフォームエンジニアリング環境では — 自動化システムのダウンタイムは深刻な運用リスクとなる可能性があります。

ここでアクティブ-アクティブ高可用性(HA)が登場します。Semaphore UIは、複数のインスタンスが同時に実行され、ワークロードを共有するアーキテクチャをサポートしています。これにより、個々のノードに障害が発生しても自動化が継続され、同時に水平スケーリングも可能になります。

シングルノード自動化の問題点

標準的なデプロイメントでは、1つのSemaphore UIプロセスがすべてのコア機能を担当します:

このアーキテクチャは小規模なチームやテスト環境では十分に機能します。しかし、重大な制限を導入します。単一のプロセスがダウンすると、システム全体が利用不能になります。 多くのユーザーと自動化ワークフローを持つ本番環境では、以下のようなリスクが生じます:

このボトルネックを解消するために、Semaphore UIはアクティブ-アクティブ高可用性デプロイメントをサポートしています。

Semaphore UIにおけるアクティブ-アクティブHAとは?

アクティブ-アクティブHAアーキテクチャでは、複数の同一のSemaphore UIインスタンスがロードバランサーの背後で同時に実行されます。従来のフェイルオーバーシステムとは異なり、プライマリノードやスタンバイノードはありません。すべてのインスタンスが、UIリクエスト、API呼び出し、スケジュールジョブ、タスク実行を完全に処理できます。

トラフィックはクラスター全体に分散され、1つのインスタンスに障害が発生しても、他のインスタンスが中断なくリクエストを処理し続けます。このアーキテクチャは、システムの信頼性と実行のスケーラビリティの両方を向上させます。

高レベルアーキテクチャ

典型的なアクティブ-アクティブデプロイメントは、いくつかの主要コンポーネントで構成されます。

  1. ロードバランサー。 ユーザーはNGINX、HAProxy、クラウドロードバランサーなどのロードバランサーを介して接続します。ロードバランサーは、利用可能なSemaphoreノード間でHTTPおよびWebSocketトラフィックを分散します。

  2. Semaphoreノード。 各ノードはSemaphore UIの同一インスタンスを実行します。どのノードでもユーザーリクエストの受信、自動化ジョブの開始、スケジュールタスクの処理、リアルタイム更新の送信が可能です。すべてのノードが同等であるため、アプリケーション層に単一障害点はありません。

  3. 共有データベース。 すべてのインスタンスはPostgreSQLやMySQLなどの共有データベースに接続します。データベースは、プロジェクト、テンプレート、インベントリ、スケジュール、タスク履歴、ユーザーアカウント、RBAC設定を含む永続データの唯一の信頼できるソースとして機能します。

  4. Redis調整レイヤー。 Redisは、複数のノードが単一システムとして動作できるようにする調整レイヤーを提供します。3つの重要な機能を果たします。

HAクラスターでのジョブ実行の仕組み

マルチノードSemaphoreデプロイメントでは、タスクの実行は調整されたフローに従います。

  1. ユーザーがタスクをトリガー。ユーザーがUIまたはAPIを通じてジョブを開始します。リクエストはどのSemaphoreインスタンスにも到達できます。
  2. タスクメタデータが保存される。受信ノードがタスクメタデータをデータベースに書き込み、Redisを通じて作業をシグナルします。
  3. ノードがタスクを取得。利用可能なノードの1つがRedisからタスクを取得し、分散ロックを取得して、データベースでタスクを実行中としてマークします。
  4. タスクが実行される。ノードがタスクをローカルで、または分散ランナー/エージェントを介して実行します。進捗とログは継続的にデータベースに書き戻されます。
  5. 結果がブロードキャストされる。タスク更新はRedis Pub/Subを通じて伝播し、すべてのノードとUIクライアントが同期を維持します。

複数ランナーによる水平スケーリング

高可用性は、タスク実行の水平スケーリングも可能にします。Semaphoreノード自体でのみジョブを実行する代わりに、実行を複数のランナーまたはエージェントに委譲できます。大規模なDevOpsチームにとって、このアーキテクチャはエンタープライズ規模の自動化ワークロードをサポートします:

アクティブ-アクティブSemaphoreデプロイメントのメリット

信頼性の向上。 1つのインスタンスに障害が発生しても、他のインスタンスがトラフィックの処理とジョブの実行を継続します。

ダウンタイムなしのメンテナンス。 システムを停止することなく、ノードを更新または再起動できます。

水平スケーラビリティ。 ロードバランサーの背後にSemaphoreノードを追加して容量を増やすことができます。

プライマリノードへの依存なし。 すべてのノードが同等であり、複雑なフェイルオーバーメカニズムが不要です。 クラスター全体での一貫した状態。共有データベースストレージとRedis調整により、すべてのインスタンスが同期を維持します。

典型的なユースケース

アクティブ-アクティブSemaphoreデプロイメントは、継続的な自動化可用性を必要とする環境で一般的です:

まとめ

アクティブ-アクティブ高可用性により、Semaphore UIは単一の自動化サーバーから回復力のある分散システムへと進化できます。UIの提供、スケジューリング、タスク実行を1つのプロセスに依存する代わりに、複数のSemaphoreインスタンスがロードバランサーの背後で協力して動作し、データベースとRedisを通じて状態を共有します。その結果、個々のノードに障害が発生しても利用可能で、ワークロードの増大に応じて水平にスケーリングできる自動化プラットフォームが実現します。

アクティブ-アクティブHAのサポートは、Semaphore Enterpriseエディションで利用可能です。高可用性に加えて、Enterpriseバージョンには、大規模なチームや本番環境向けに設計された機能が含まれています — 高度なRBAC(ロールベースアクセス制御)など、組織がプロジェクト、チーム、環境全体にわたってきめ細かい権限を定義できます。

インフラストラクチャ向けの高可用性自動化プラットフォームを評価している場合は、Enterpriseエディションのトライアルをリクエストして、HAアーキテクチャをテストし、DevOpsワークフローにどのように適合するかを確認できます。

Request an Enterprise Trial

FAQ

アクティブ-アクティブ高可用性とは何ですか?

アクティブ-アクティブ高可用性とは、複数のアプリケーションインスタンスが同時に実行され、すべてがリクエストを処理できることを意味します。プライマリノードは存在せず、どのインスタンスでもトラフィックを処理しジョブを実行できます。

なぜSemaphoreはHAモードでRedisを使用するのですか?

Redisはインスタンス間の調整レイヤーとして機能します。分散ロック、共有タスクキューの状態、Pub/Subメッセージングを提供し、ノードが同じジョブを同時に実行しないようにします。

SemaphoreはHAデプロイメントでどのデータベースをサポートしていますか?

Semaphoreは永続的なシステムデータを保存するための共有データベースとしてPostgreSQLとMySQLをサポートしています。

Semaphoreノードに障害が発生した場合はどうなりますか?

ロードバランサーが単純にトラフィックを残りのノードにルーティングします。実行中のジョブは継続し、新しいジョブは他のインスタンスによって取得されます。

Semaphoreは水平にスケーリングできますか?

はい。追加のSemaphoreノードとランナーを追加して、実行容量を増やし、より大規模な自動化ワークロードを処理できます。