- はじめに
- シングルノード自動化の問題点
- Semaphore UIにおけるアクティブ-アクティブHAとは?
- 高レベルアーキテクチャ
- HAクラスターでのジョブ実行の仕組み
- 複数ランナーによる水平スケーリング
- アクティブ-アクティブSemaphoreデプロイメントのメリット
- 典型的なユースケース
- まとめ
- FAQ
はじめに
多くの自動化プラットフォームは、シングルノードアーキテクチャから始まります。1つのプロセスがUI の提供、ジョブの実行、スケジュールの管理、リアルタイム更新の処理を行います。この構成はシンプルですが、単一障害点も生み出します。そのプロセスが停止すると、自動化も停止します。
大規模なインフラストラクチャ自動化を実行する組織にとって — 特にDevOpsやプラットフォームエンジニアリング環境では — 自動化システムのダウンタイムは深刻な運用リスクとなる可能性があります。
ここでアクティブ-アクティブ高可用性(HA)が登場します。Semaphore UIは、複数のインスタンスが同時に実行され、ワークロードを共有するアーキテクチャをサポートしています。これにより、個々のノードに障害が発生しても自動化が継続され、同時に水平スケーリングも可能になります。
シングルノード自動化の問題点
標準的なデプロイメントでは、1つのSemaphore UIプロセスがすべてのコア機能を担当します:
- Web UIの提供
- APIリクエストの処理
- スケジュールされたジョブの実行
- 自動化タスクの実行
- ブラウザへのリアルタイム更新の送信
このアーキテクチャは小規模なチームやテスト環境では十分に機能します。しかし、重大な制限を導入します。単一のプロセスがダウンすると、システム全体が利用不能になります。 多くのユーザーと自動化ワークフローを持つ本番環境では、以下のようなリスクが生じます:
- 中断されたデプロイメント
- 失敗したスケジュールジョブ
- 運用可視性の喪失
- メンテナンス中のダウンタイム
このボトルネックを解消するために、Semaphore UIはアクティブ-アクティブ高可用性デプロイメントをサポートしています。
Semaphore UIにおけるアクティブ-アクティブHAとは?
アクティブ-アクティブHAアーキテクチャでは、複数の同一のSemaphore UIインスタンスがロードバランサーの背後で同時に実行されます。従来のフェイルオーバーシステムとは異なり、プライマリノードやスタンバイノードはありません。すべてのインスタンスが、UIリクエスト、API呼び出し、スケジュールジョブ、タスク実行を完全に処理できます。
トラフィックはクラスター全体に分散され、1つのインスタンスに障害が発生しても、他のインスタンスが中断なくリクエストを処理し続けます。このアーキテクチャは、システムの信頼性と実行のスケーラビリティの両方を向上させます。
高レベルアーキテクチャ
典型的なアクティブ-アクティブデプロイメントは、いくつかの主要コンポーネントで構成されます。
-
ロードバランサー。 ユーザーはNGINX、HAProxy、クラウドロードバランサーなどのロードバランサーを介して接続します。ロードバランサーは、利用可能なSemaphoreノード間でHTTPおよびWebSocketトラフィックを分散します。
-
Semaphoreノード。 各ノードはSemaphore UIの同一インスタンスを実行します。どのノードでもユーザーリクエストの受信、自動化ジョブの開始、スケジュールタスクの処理、リアルタイム更新の送信が可能です。すべてのノードが同等であるため、アプリケーション層に単一障害点はありません。
-
共有データベース。 すべてのインスタンスはPostgreSQLやMySQLなどの共有データベースに接続します。データベースは、プロジェクト、テンプレート、インベントリ、スケジュール、タスク履歴、ユーザーアカウント、RBAC設定を含む永続データの唯一の信頼できるソースとして機能します。
-
Redis調整レイヤー。 Redisは、複数のノードが単一システムとして動作できるようにする調整レイヤーを提供します。3つの重要な機能を果たします。
- 分散ロックは、一度に1つのインスタンスだけがジョブやステップを実行することを保証します。分散ロックがなければ、複数のノードが同じタスクを同時に実行しようとする可能性があります。
- 共有タスクキューの状態。 Redisはタスクキューを管理し、ジョブが正確に1つのワーカーによって取得されるようにします。すべてのノードが同じキューを参照し、タスクの実行を調整します。
- Pub/Subメッセージングにより、ノードはタスク更新、クラスター通知、キャッシュ無効化、UI状態更新などのイベントをブロードキャストできます。これにより、すべてのノードがリアルタイムで同期されます。
HAクラスターでのジョブ実行の仕組み
マルチノードSemaphoreデプロイメントでは、タスクの実行は調整されたフローに従います。
- ユーザーがタスクをトリガー。ユーザーがUIまたはAPIを通じてジョブを開始します。リクエストはどのSemaphoreインスタンスにも到達できます。
- タスクメタデータが保存される。受信ノードがタスクメタデータをデータベースに書き込み、Redisを通じて作業をシグナルします。
- ノードがタスクを取得。利用可能なノードの1つがRedisからタスクを取得し、分散ロックを取得して、データベースでタスクを実行中としてマークします。
- タスクが実行される。ノードがタスクをローカルで、または分散ランナー/エージェントを介して実行します。進捗とログは継続的にデータベースに書き戻されます。
- 結果がブロードキャストされる。タスク更新はRedis Pub/Subを通じて伝播し、すべてのノードとUIクライアントが同期を維持します。
複数ランナーによる水平スケーリング
高可用性は、タスク実行の水平スケーリングも可能にします。Semaphoreノード自体でのみジョブを実行する代わりに、実行を複数のランナーまたはエージェントに委譲できます。大規模なDevOpsチームにとって、このアーキテクチャはエンタープライズ規模の自動化ワークロードをサポートします:
- インフラストラクチャ全体にワークロードを分散
- 自動化容量のスケーリング
- 影響範囲を制限するための実行環境の分離
- 数千のノードを並列実行
アクティブ-アクティブSemaphoreデプロイメントのメリット
信頼性の向上。 1つのインスタンスに障害が発生しても、他のインスタンスがトラフィックの処理とジョブの実行を継続します。
ダウンタイムなしのメンテナンス。 システムを停止することなく、ノードを更新または再起動できます。
水平スケーラビリティ。 ロードバランサーの背後にSemaphoreノードを追加して容量を増やすことができます。
プライマリノードへの依存なし。 すべてのノードが同等であり、複雑なフェイルオーバーメカニズムが不要です。 クラスター全体での一貫した状態。共有データベースストレージとRedis調整により、すべてのインスタンスが同期を維持します。
典型的なユースケース
アクティブ-アクティブSemaphoreデプロイメントは、継続的な自動化可用性を必要とする環境で一般的です:
- 大規模DevOpsチーム。 多くのエンジニアが一日を通じて自動化タスクをトリガーする組織では、複数のSemaphoreインスタンスにより、ジョブとリクエストを並列処理でき、単一ノードがボトルネックになることを防ぎます。
- エンタープライズインフラストラクチャ。 サーバー、仮想マシン、コンテナの大規模なフリートを管理する企業は、構成とメンテナンスのための自動化に大きく依存しています。高可用性は、重要な自動化ワークフローが運用可能な状態を維持することを支援します。
- CI/CD自動化。 SemaphoreがCI/CDパイプラインの一部として使用される場合、中断はデプロイメントとリリースを遅延させる可能性があります。アクティブ-アクティブデプロイメントは、個々のノードが再起動または障害が発生しても、パイプラインを確実に実行し続けるのに役立ちます。
- プラットフォームエンジニアリング。 プラットフォームチームは、セルフサービス自動化を提供する内部開発者プラットフォームの一部としてSemaphoreを使用することがよくあります。高可用性は、これらの内部サービスが開発チームに対して安定的かつ応答性を維持することを保証します。
まとめ
アクティブ-アクティブ高可用性により、Semaphore UIは単一の自動化サーバーから回復力のある分散システムへと進化できます。UIの提供、スケジューリング、タスク実行を1つのプロセスに依存する代わりに、複数のSemaphoreインスタンスがロードバランサーの背後で協力して動作し、データベースとRedisを通じて状態を共有します。その結果、個々のノードに障害が発生しても利用可能で、ワークロードの増大に応じて水平にスケーリングできる自動化プラットフォームが実現します。
アクティブ-アクティブHAのサポートは、Semaphore Enterpriseエディションで利用可能です。高可用性に加えて、Enterpriseバージョンには、大規模なチームや本番環境向けに設計された機能が含まれています — 高度なRBAC(ロールベースアクセス制御)など、組織がプロジェクト、チーム、環境全体にわたってきめ細かい権限を定義できます。
インフラストラクチャ向けの高可用性自動化プラットフォームを評価している場合は、Enterpriseエディションのトライアルをリクエストして、HAアーキテクチャをテストし、DevOpsワークフローにどのように適合するかを確認できます。
FAQ
アクティブ-アクティブ高可用性とは何ですか?
アクティブ-アクティブ高可用性とは、複数のアプリケーションインスタンスが同時に実行され、すべてがリクエストを処理できることを意味します。プライマリノードは存在せず、どのインスタンスでもトラフィックを処理しジョブを実行できます。
なぜSemaphoreはHAモードでRedisを使用するのですか?
Redisはインスタンス間の調整レイヤーとして機能します。分散ロック、共有タスクキューの状態、Pub/Subメッセージングを提供し、ノードが同じジョブを同時に実行しないようにします。
SemaphoreはHAデプロイメントでどのデータベースをサポートしていますか?
Semaphoreは永続的なシステムデータを保存するための共有データベースとしてPostgreSQLとMySQLをサポートしています。
Semaphoreノードに障害が発生した場合はどうなりますか?
ロードバランサーが単純にトラフィックを残りのノードにルーティングします。実行中のジョブは継続し、新しいジョブは他のインスタンスによって取得されます。
Semaphoreは水平にスケーリングできますか?
はい。追加のSemaphoreノードとランナーを追加して、実行容量を増やし、より大規模な自動化ワークロードを処理できます。