Bitbucket Data Center のフェイルオーバー

概要

Bitbucket Data Center のアクティブ/アクティブクラスタリング構成の重要なメリットは、高可用性であるということです。1 つのクラスタ ノードがダウンした場合、ユーザーが可用性の低下をほとんど、またはまったく意識することがないように、残りのノードがリクエストへのサービス提供を継続できます。

他のシステムと同様に、Bitbucket Data Center インスタンスの各コンポーネントには、潜在的な障害点とユーザーに対する可用性の損失の可能性があります。そのため、最大限の可用性を確保するため、フェイルオーバー計画を作成することが重要です。このページでは、Bitbucket Data Center を使用してユーザーの可用性を最大化する方法に関する推奨事項を提供します。 

Bitbucket Data Center のコンポーネント

Bitbucket Data Center インスタンスは、以下の図のように接続された複数の専用マシンで構成されます。

クラスタ ノードのフェイルオーバー

Bitbucket ノードのクラスタは、アクティブ/アクティブ フェイルオーバーを提供するため、受信リクエストの負荷を共有します。各ノードは、専用マシン上で実行する完全な Bitbucket インスタンスです。クラスタは Bitbucket Data Center のより複雑なコンポーネントであり、高い可用性に焦点を当てるためには最も重要です。 

Bitbucket Data Center は次の制約を満たす限り、クラスタ ノードに障害が発生しても、ユーザーが可用性の低下をほとんど、またはまったく意識することがないように設計されています。

• ロード バランサは障害を即座に検出し、残りのクラスタ ノードにフェイルオーバー可能です。Bitbucket は、クラスタ ノードの健全性をロード バランサが定期的に確認するために使用できる /status REST リソースを提供しています。クラスタ ノードがダウンした場合、ほとんどのロード バランサは障害を検出し、トラフィックを数秒以内に他のノードに誘導します。
• 1 つ以上のノードがダウンしてもユーザーからのリクエストを処理できるよう、クラスター内に十分容量 (クラスタ ノード) をプロビジョニングしました。ピーク時負荷に必要なノード数より 1 つ以上多くのクラスタでプロビジョニングを行うことを強くお勧めします。 

クラスタ ノードがダウンした場合、積極的に使用しているユーザーはさまざま方法でその障害に気付きます。

• 障害が発生したノードで処理されているオープンな Git クローン、フェッチ、またはプッシュ接続が破損している可能性がありますが、再試行すると成功します。 

• プル リクエストの範囲の設定、ドリフト計算へのコメントの作成、ユーザー ディレクトリの同期など、ダウンしたノードで実行中のバックグラウンド タスクは別のクラスタ ノードに引き継がれるため、完了するまで少し時間がかかる場合があります。 

• クラスタ全体でユーザーの認証資格情報を保存する対策をとっていない限り、不具合のあるノードへセッションが送信されたユーザーはログアウトされ、再度 Bitbucket にログインする必要があります。 ユーザーの認証資格情報を保存し、再度ログインする必要をなくす対策については、以下を参照してください。

• ダウンしたノードのセッションに保存されているその他のデータ (複数ページ フォームの 1 つのページに入力されたフィールドなど) は失われ、再入力が必要となる場合があります。Bitbucket およびアトラシアンが提供するほとんどのアプリはセッションにこれらの状態を保存しませんが、Bitbucket Data Center 用に設計されていないサードパーティ製アプリでは保存される場合もあります。 

セッション データやユーザー認証に関する構成オプションについては、以下の「セッション管理」で詳しく説明します。

ロード バランサによるクラスタ ノードの障害の検出やフェイルオーバーが素早いほど、ユーザーが中断を経験する可能性は低くなります。ほとんどのロード バランサではヘルス チェックの頻度を設定できます。ヘルス チェックの実行間隔は一般に短いほうが望ましいですが、CPU やネットワーク リソースに過剰な負荷を加えることなく /status エンドポイントにポーリングすることを考慮すると、間隔には限度があります。ヘルス チェックの頻度は 1 〜 5 秒間隔にすることを強くおすすめします。 

セッション管理

Bitbucket Data Center は、ロードバランサがセッション アフィニティ (「スティッキー セッション」) を適用したと想定します。そのため、常に、互いのリクエストを同じクラスター ノードに向けます。Bitbucket Data Center は各ユーザーのセッション情報をローカルで、特定のクラスタ ノード上に保持します。これは、パフォーマンスに対する最適な構成です。 

ただし、クラスタがダウンした場合、セッション状態がダウンしたノードに保存されていたユーザーはこの情報を失い、ログアウトされるため。再度ログインする必要があります。この追加ログインを排除できる方法は多数ありますあ、パフォーマンスのトレードオフが存在するため、既定で有効にされている方法はありません。 

Remember-Me 認証を使用する

Remember-Me 認証を使用すると、正常に認証されたユーザーは _atl_bitbucket_remember_me cookie を受け取ります。この cookie はデータベース内に 30 日間保存され、ユーザーはリクエストの転送先となるクラスタ ノードを問わず、再ログインを行わずに再認証できます。 

既定では、Remember-Me 認証は任意です。そのため、Remember-Me 認証を有効にするには、ログイン時にユーザーが [ログインしたままにする] を選択する必要があります。すべてのユーザーで Remember-Me 認証を強制的に有効化するには、bitbucket.properties の auth.remember-me.enabled プロパティを always に設定します。 

Remember-Me 認証を使用すると、cookie の寿命である 30 日間の間、再度ログインする必要がなくなります。その他のセッション情報は保存しません。 

認証で Crowd SSO を使用する

ノードがダウンした場合にユーザーが再度ログインしなくてもすむようにするもう 1 つの方法は、Atlassian Crowd のシングル サインオン (SSO) 機能を使用することです。Crowd SSO が有効になっている場合、Crowd ディレクトリが SSO 用に設定されているユーザーは再度ログインする必要はありません。 

Crowd SSO はユーザーの資格情報の自動認証のみを提供します。その他のセッション情報は保存しません。 

詳細については、「Bitbucket を Crowd に接続する」を参照してください。 

独自のカスタム認証プラグインを使用する

独自のカスタム (社内またはサードパーティ) 認証プラグインを使用している場合、プラグインがクラスタ対応となるよう作成されていれば、追加でのログインを回避することができます。