アプリノードが停止しても Semaphore を利用可能に

文書化されたアクティブ・アクティブ構成では、複数の Semaphore アプリケーションノード、共有の PostgreSQL または MySQL データベース、Redis による調整、HTTP と WebSocket に対応したロードバランサーを使います。各ノードには適切な共有設定と、一意の HA 識別子が必要です。アプリケーションノードと併せて依存サービスの可用性も計画してください。プロセスを 1 つ追加するだけでは、構成全体に必要な共有状態と調整機能は提供されません。

ここで説明するのは、対等なアプリケーションノードがサービスに参加するアクティブ・アクティブ構成です。専用のプライマリノードとパッシブな待機ノードには依存しません。現在の HA ガイドで対応する設計を設定し、可用性に関する一般的な表現から、別のアクティブ・パッシブ参照構成を推測しないでください。別の構成が必要な場合は、デプロイ前に状態管理とフェイルオーバーの動作を解決してください。

いいえ。文書化された HA 設計では、共有の PostgreSQL または MySQL データベースと Redis が必要です。データベースは、参加ノードに共通のアプリケーション状態の保存元です。別のストレージを使った単一ノード構成から移行する場合は、移行、バックアップ、検証を別の作業として計画します。必要なデータが共有データベースに保存され、提供されることは、アプリケーションノードの追加前にテストしてください。

それらのコンポーネントには、個別の耐障害性戦略が必要です。Semaphore の複数ノード設計が、データベースのフェイルオーバー、冗長ロードバランサー、高可用な Redis を自動で作成するわけではありません。各依存サービスの障害ドメイン、復旧手順、能力要件を特定してください。クライアントのリクエストからタスク結果までの全経路をテストし、アプリケーションノードの台数だけでなく、利用者が使うサービスを可用性計画でカバーします。

アプリケーションノードが複数あるだけで、進行中の実行が途切れないと考えないでください。動作は実行経路、障害が起きたコンポーネント、運用しているリリースによって異なります。ステータス報告やランナーの関与を含め、依存するタスクのライフサイクルをテストしてください。同様に、すべてのバージョン変更を無停止のローリング更新が保証された操作として扱わず、アップグレードの互換性とマイグレーションを計画してください。UI の可用性とタスクの継続性は異なる要件です。

高可用性は Enterprise の機能です。必要な稼働時間、保守手順、復旧目標、既存のデータベースとロードバランサーのサービスから検討を始めてください。文書化された構成で不足を特定し、代表的な環境でノードの切り離し、依存サービスの復旧、バックアップをテストします。これらが事業上重要な要件である場合、アーキテクチャの相談が役立ちます。結果を決めるのは単一機能の切り替えではなく、デプロイ全体だからです。

そのために、アクティブなアプリノードを負荷分散された 1 つのサービスアドレスの背後に配置します。ロードバランサーは、利用不能なノードへのリクエストを停止し、HTTP と WebSocket の両方に対応する必要があります。稼働を続けるノードも、プロジェクトを提供するには共有データベース、Redis、一致するアプリケーション設定へのアクセスが必要です。

いいえ。複数の実行場所はランナーが担います。高可用性は Semaphore のアプリケーション層を対象とし、ランナーはタスクの実行場所と到達できるシステムを対象とします。本番構成では、共有 UI と API のための HA アプリノードと、プライベートインフラの近くのプロジェクトランナーを併用できます。