Confluence Data Center のサンプル デプロイメントおよび監視戦略
アトラシアンでは、エンタープライズ規模の複数の開発ツールを使用しています。Confluence Data Center インスタンスは、約 2,400 人のアトラシアンのフルタイム従業員によって世界中で使用されています。
Confluence の使用の背景
コラボレーションとオープン コミュニケーションはアトラシアンの文化に不可欠であり、このコラボレーションの多数が Confluence で行われています。2018 年 4 月現在、合計 6,500 スペースに 14,930,000 件のコンテンツ アイテムがあります。インスタンスのトラフィックの 6 時間のスナップショットでは、1 時間あたり平均で 341,000 回の HTTP コールが発生しています (HTTP コールのピークは 1 時間あたり 456,000 回です)。Confluence Data Center 負荷プロファイルに基づくと、コンテンツとトラフィックの両方について、このインスタンスは "大" と分類されます。
アトラシアンの Confluence Data Center インスタンスは、営業時間中に各拠点で多用されているため、すべてのアトラシアン メンバーの生産性を維持するには、パフォーマンスを確保する必要があります。インスタンスは高可用性構成であるため、個々のノードの障害はインスタンスにとって致命的ではありません。これにより、適切なパフォーマンスを維持することに重点を置き、サイトの実行の維持のための労力を減らすことができます。
インフラストラクチャとセットアップ
アトラシアンの Confluence Data Center インスタンスは Amazon Web Services (AWS) Virtual Private Cloud にホスティングされており、以下のように構成されています。
機能 | インスタンス タイプ | 数値 |
|---|---|---|
| Load balancer | AWS Application Load Balancer | 2 |
| Confluence アプリケーション | c5.2xlarge (Amazon Linux を実行) | 4 |
| Synchrony アプリケーション (共同編集用) | c5.large (Amazon Linux を実行) | 2 |
| データベース (Amazon RDS Postgresql) | m4.xlarge | 1 |
| 共有ホーム ディレクトリ | Elastic File System (2.1 TiB) | 1 |
負荷分散は、専用の Virtual Traffic Manager (VTM) とアプリ ロード バランサで管理されます。Atlassian VTM は、次の 2 つの役割を果たします。
- 同一ドメイン上の異なる Atlassian インスタンス間のトラフィックのルーティング
- Confluence Data Center インスタンスの SSL のターミネーション
Synchrony クラスタには 2 つのノードがあり、XHR フォールバックが有効で、内部 Synchrony プロキシは使用しません。インスタンスでは、ストレージに Amazon Elastic File System (2.1 TiB) も使用されます。
各ノード タイプについては、インスタンス タイプについての AWS ドキュメント (特に「汎用インスタンス」と「コンピュート最適化インスタンス」) を参照してください。
連携サービス
この Confluence Data Center インスタンスでは、70 個のユーザー インストール アプリ が有効であり、次のアトラシアン アプリケーションにリンクされています。
- 5 つの Jira Software および Service Desk
- 7 つの Confluence
- 2 つの Bitbucket
- 11 個の Bamboo
- 2 つの Fisheye / Crucible
このインスタンスは、ユーザー管理用に Crowd にも接続されています。
監視戦略
アトラシアンのパフォーマンス監視戦略は Apdex 0.7 を目標として構築されていますが、0.4 以上を維持しています。このインデックスでは、応答時間 1 秒を許容しきい値、4 秒を超えると不満しきい値と仮定しています。
Apdex インデックスでは、インスタンスの一般的な満足度を維持することが、満足しているユーザーの割合の維持につながります。詳細については、「Apdex の概要」を参照してください。
Apdex レベルを許容レベル内に維持することは、大きな処理の遅延を引き起こす可能性のある潜在的な問題について、インスタンスをアクティブに監視していることを意味します。これらのアラート、監視戦略、およびアクション プランの多くは、アトラシアンで過去に発生した障害で、短期間で解決したり、回避したりするために学んできた事項に基づいています。
以下の表では、監視アラートと、トリガーされたときに何を行うかを示しています。
一般的な負荷
| 追跡するメトリック | アラート レベル | アラートがトリガーされたときの対応 |
|---|---|---|
長時間実行されているタスク | ユーザーが次のようなタスクを開始すると、監視ツールが通知します。
タスクが継続して実行されている場合、1 時間ごとにアラートが送信されます。 | タスクが停止し、他のアラートをトリガーするようになったら、通常はノードを再起動してタスクを削除します。 また、ユーザーに連絡し、他のオプションについて話し合います。たとえばスペースのエクスポートの場合、エクスポートするスペースのサイズを減らしたり、ステージング サーバからエクスポートすることを検討します。 |
ネットワーク スループット | 20Mbps 以上 (2018 年 4 月現在) | 他のメトリックを調査し、スループットを増加させたほかの要素 (高いユーザー トラフィック以外) があるかどうかを確認します。スループットによってアラートがトリガーされる回数を継続的に確認し、インフラストラクチャとアラート レベルを再度調整する必要があるかどうかを確認します。 |
| アクティブなデータベース コネクションの数 多数のアクティブなデータベース コネクションがあると、Confluence が遅くなる可能性があります。 | 1000 を超えるコネクション | m4.xlarge ノード タイプでは、最大 1,320 のコネクションがサポートされます。ノードがアラートをトリガーして、接続が増え続ける場合、ローリング リスタートを実行します。 バグ (具体的にはデータベース コネクションのリーク) によってこのアラートがトリガされてる可能性もあるため、Confluence のチケットの作成も行います。今日まで、弊社のインスタンスがこのアラートをトリガしたことはありません。 |
ノード CPU 使用率 | アプリケーション ノードについて、2 つの CPU 使用率アラートを設定しています。
データベース ノードについても同様です。
| アプリケーション ノードが警告アラートをトリガすると、ヒープ ダンプとスレッド ダンプを取得し、詳細に調査します。インスタンスがクラッシュしそうな場合は、ローリング リスタートを実行します。 今日まで、アラートがトリガーされると、データベース ノードは常に自力で回復しています。 |
ガベージ コレクタの停止 このメトリックは、開発フィードバック用にも追跡しています。停止情報によって、不要なオブジェクトを多数作成している Confluence の領域を特定できます。これらの領域を分析して、Confluence の改善に役立てます。 | ガベージ コレクターの 5 秒以上の停止 | 通常、このアラートではアクションは不要ですが、潜在的な機能停止の可能性の警告として役立ちます。ここで収集したデータによって、その他の機能停止の根本的な原因を診断することもできます。 ガベージ コレクターがこのアラートを頻繁にトリガーする場合、インスタンスのヒープの調整が必要かどうかを確認します。 |
Load balancer
| 追跡するメトリック | アラート レベル | アラートがトリガーされたときの対応 |
|---|---|---|
タイムアウト回数 | 1 時間で 300 回のタイムアウト | 短時間で大量のタイムアウトが発生した場合、通常、そのあとに他のアラートが発生します。トリガーされたアラートと他のメトリックを調査し、機能停止や同様の問題が差し迫っているかどうかを確認します。 |
ノード ヘルス 詳細については、「ロード バランサーの構成オプション」を参照してください。 | ロード バランサーがノードを切断または再接続したタイミング | ノードが切断されたら、その状態を確認し、必要に応じて再起動します。また、他のトリガされたアラートをチェックし、ノードが切断された原因を確認します。 |
| 内部サーバー エラー ロード バランサーが内部サーバー エラー (エラー コード 500) を返す場合、通常はリクエストを処理するバックエンド ノードが存在しません。 | ロード バランサーで 1 秒間に 10 回を超える内部サーバー エラーが発生した時 | トリガーされた他のアラートをチェックし、特定のサブシステム (データベースやストレージなど) に問題があるかどうかを確認します。 |
ストレージ
| 追跡するメトリック | アラート レベル | アラートがトリガーされたときの対応 |
|---|---|---|
| 共有ホームのファイル システムの I/O I/O が多いとファイル アクセスの速度が低下し、タイムアウトする可能性があります。 | PercentIOLimit が 98 より大きくなったとき。これは、共有ホームのファイル システム I/O が制限値である 98 % を超えていることを意味します。詳細については、「Amazon CloudWatch による監視」を参照してください。 | I/O 制限を増やす必要があるかどうかを調査します。 |
| ディスク容量 使用量に対応できるようにディスク容量を拡張するか、ストレージ関連の問題についてさらに確認する必要があるかどうかを、早い段階で知っておく必要があります。 | ディスクの空き容量について、異なるレベルの 2 つのアラートを設定しています。
| 空き容量が不足しているが消費率が通常のままの場合、ストレージの空き容量を拡大します。 ディスクの消費率が異常に急増した場合、異常な動作を示しているプロセスがあるかどうかを確認します。これには、過去 24 時間以内に消費されたディスク容量の確認も含まれます。 |
安定性の監視
以下のアラートは、インスタンスの全体的な安定性に関係します。パフォーマンスの問題に対処する作業のほとんどがシステム停止の防止につながるため、これらのアラートはあまりトリガーされません。
| 追跡するメトリック | アラート対象イベント | アラートがトリガーされたときの対応 |
|---|---|---|
一般的なエラー条件 | アラートに含める一般的なエラーの一部:
| アラートが作成されるエラーのほとんどは、それらによるシステム停止を防ぐ方法とともに、Confluence ナレッジベースに記載されています。 |
| Hazelcast クラスタ メンバーシップ 既定では、ハートビートが 30 秒以内に送信されない場合、Hazelcast によってノードが削除され、再追加されます。アトラシアンでは、これを 60 秒以内に行うように設定しています。 | ノードがクラスターから削除されて再追加されたとき | 影響されたノードでログ分析、スレッド ダンプ、ヒープ ダンプを実行します。これらのいずれかがクラスタ パニックを示しているか、システム停止が予期される場合、ローリング リスタートを実行します。 |
| クラスタ パニック 重大なエラーであり、通常は Confluence の完全な再起動が必要です。 | すべてのクラスタ パニック。アトラシアンの監視ツールでは、そのインスタンスで過去に発生したパニックの関連イベントについて、アプリケーション ログが確認されます。 | Confluence の完全な再起動を実行します。これは、すべてのアプリケーション ノードをシャットダウンし、1 つずつ起動することを意味します。 関連情報については、「Data Center のトラブルシューティング」と「Confluence Data Center のトラブルシューティング」を参照してください。 |
アラートしないメトリック
以下のメトリックに関するアラートは設定されていませんが、異常なスパイクやディップは定期的に監視しています。他のアラートがトリガーされたときや、Apdex が降下し始めた場合にも、これらを確認します。
| 追跡するメトリック | 監視プラクティス |
|---|---|
JVM メモリ | JVM のメモリが少なくなり始めたら、ヒープ ダンプとスレッド ダンプを取得します。いずれかのダンプでクラッシュが予期される場合、ローリング リスタートを実行します。 |
| アクティブな HTTP スレッドの数 定常的に使用するスレッドが多くなると、アプリケーション デッドロックが発生する可能性があります。 | このメトリックにおける異常なスパイクがデッドロックなどの問題と一致する場合、影響する各ノードを再起動します。 そうでない場合、スレッド制限を調整したり、さらなる調査のためにスレッド ダンプを取得したりします。関連情報については、「ヘルス チェック: スレッド制限」を参照してください。 |