Confluence Data Center のサンプル デプロイメントおよび監視戦略

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

アトラシアンでは、エンタープライズ規模の複数の開発ツールを使用しています。Confluence Data Center インスタンスは、約 2,400 人の Atlassian のフルタイム従業員によって世界中で使用されています。 

Confluence の使用の背景

コラボレーションとオープン コミュニケーションはアトラシアンの文化に不可欠であり、このコラボレーションの多数が Confluence で行われています。2018 年 4 月現在、合計 6,500 スペース14,930,000 件のコンテンツ アイテムがあります。インスタンスのトラフィックの 6 時間のスナップショットでは、1 時間あたり平均で 341,000 回の HTTP コールが発生しています (HTTP コールのピークは 1 時間あたり 456,000 回です)。Confluence Data Center 負荷プロファイルに基づくと、コンテンツとトラフィックの両方について、このインスタンスは "" と分類されます。 

負荷とスケールの詳細はこちらをクリック

これらの情報は 2018 年 4 月 30 日に収集されました。


コンテンツ

統計情報
添付ファイル2,424, 000
コメント1,976, 000
ページ686,000
ブログ投稿60,000
下書き32,500

規模

統計情報
合計スペース数6,500
サイト スペース1,500
パーソナル スペース5,000
コンテンツ (すべてのバージョン)

14,930, 000

コンテンツ(現在のバージョン)6,350, 500
ローカル ユーザー

11,000

ローカル グループ8,500


参考情報

  • コンテンツ (すべてのバージョン) は、インスタンス内のすべてのページ、ブログ投稿、コメント、およびファイルのすべてのバージョンの総数です。これは、Confluence データベースの CONTENT テーブルの行の総数です。
  • コンテンツ (現在のバージョン) は、インスタンス内のページ、ブログ投稿、コメント、およびファイルの総数です。これには、ページ、ブログ投稿、またはファイルの過去のバージョンは含まれません。
  • ローカル ユーザーは、データベースと同期されているローカルおよびリモート ディレクトリのユーザー アカウントの数です。これには、アクティブなアカウントと非アクティブなアカウントとの両方が含まれています。

ロード

以下の統計は、2018 年 4 月の標準的な営業日の午前 9:00 から午後 3:00 (シドニー時間) のものです。これらの時間に、Confluence 使用率のピークとディップがキャプチャされ、インスタンスが受け取るトラフィックの種類も示されます。

統計情報

平均

ピーク

1 時間あたりの HTTP コール数

341,000

456,000

1 時間あたりの同時接続ユーザー数

222

277

トラフィック プロファイルでは、1 時間あたり 350,000 から 700,000 回の HTTP コールがカバーされます。ここでの平均はしきい値以下ですが、1 時間のピークは 456,000 回でした。インスタンスでは平均トラフィックとピーク トラフィックの両方が提供されていため、負荷を "" と分類しました。

アトラシアンの Confluence Data Center インスタンスは、営業時間中に各拠点で多用されているため、すべてのアトラシアン メンバーの生産性を維持するには、パフォーマンスを確保する必要があります。インスタンスは高可用性構成であるため、個々のノードの障害はインスタンスにとって致命的ではありません。これにより、適切なパフォーマンスを維持することに重点を置き、サイトの実行の維持のための労力を減らすことができます。 

インフラストラクチャとセットアップ


アトラシアンの Confluence Data Center インスタンスは Amazon Web Services (AWS) Virtual Private Cloud にホスティングされており、以下のように構成されています。 

機能

インスタンス タイプ

数値

ロードバランサーAWS Application Load Balancer2
Confluence アプリケーションc5.2xlarge (Amazon Linux を実行)4
Synchrony アプリケーション (共同編集用)c5.large (Amazon Linux を実行)2
データベース (Amazon RDS Postgresql)m4.xlarge1
共有ホーム ディレクトリElastic File System (2.1 TiB)1

負荷分散は、専用の Virtual Traffic Manager (VTM) とアプリケーション ロード バランサーで管理されます。Atlassian VTM は、以下の機能を実行します。

  1. 同一ドメイン上の異なる Atlassian インスタンス間のトラフィックのルーティング
  2. 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 にも接続されています。

監視戦略

ここで説明している戦略は、Atlassian のビジネス要件や利用可能なリソースに適用されるものです。ニーズやイベントは企業環境ごとに異なり、それに応じて別の戦略が必要になる可能性があります。Atlassian のテクニカル アカウント マネージャーにご相談ください。

アトラシアンのパフォーマンス監視戦略は Apdex 0.7 を目標として構築されていますが、0.4 以上を維持しています。このインデックスでは、応答時間 1 秒を許容しきい値、4 秒を超えると不満しきい値と仮定しています。

Apdex インデックスでは、インスタンスの一般的な満足度を維持することが、満足しているユーザーの割合の維持につながります。詳細については、「Apdex の概要」を参照してください。

Apdex レベルを許容レベル内に維持することは、大きな処理の遅延を引き起こす可能性のある潜在的な問題について、インスタンスをアクティブに監視していることを意味します。これらのアラート、監視戦略、およびアクション プランの多くは、アトラシアンで過去に発生した障害で、短期間で解決したり、回避したりするために学んできた事項に基づいています。 

以下の表では、監視アラートと、トリガーされたときに何を行うかを示しています。 

一般的な負荷

追跡するメトリックアラート レベルアラートがトリガーされたときの対応

長時間実行されているタスク
スペースが大きくなると、一部のタスクでメモリの問題が発生する可能性があります。

ユーザーが次のようなタスクを開始すると、監視ツールが通知します。

タスクが継続して実行されている場合、1 時間ごとにアラートが送信されます。

タスクが停止し、他のアラートをトリガーするようになったら、通常はノードを再起動してタスクを削除します。

また、ユーザーに連絡し、他のオプションについて話し合います。たとえばスペースのエクスポートの場合、エクスポートするスペースのサイズを減らしたり、ステージング サーバからエクスポートすることを検討します。

ネットワーク スループット
これをチェックすることでインスタンスの健全性を測定し、不審な外部アクティビティ (DDoS など) を検出します。

20Mbps 以上 (2018 年 4 月現在)

他のメトリックを調査し、スループットを増加させたほかの要素 (高いユーザー トラフィック以外) があるかどうかを確認します。スループットによってアラートがトリガーされる回数を継続的に確認し、インフラストラクチャとアラート レベルを再度調整する必要があるかどうかを確認します。

アクティブなデータベース コネクションの数
多数のアクティブなデータベース コネクションがあると、Confluence が遅くなる可能性があります。 

1000 を超えるコネクション

m4.xlarge ノード タイプでは、最大 1,320 のコネクションがサポートされます。ノードがアラートをトリガーして、接続が増え続ける場合、ローリング リスタートを実行します。 

バグ (具体的にはデータベース コネクションのリーク) によってこのアラートがトリガされてる可能性もあるため、Confluence のチケットの作成も行います。日まで、弊社のインスタンスがこのアラートをトリガしたことはありません。

ノード CPU 使用率
データベースまたはアプリケーション ノードの CPU 使用率が高い場合、ノード固有の問題が発生している可能性があります。これらの問題はインスタンスの速度を低下させる可能性があります。

アプリケーション ノードについて、2 つの CPU 使用率アラートを設定しています。

  • 50 % (警告)
  • 70 % (エラー)

データベース ノードについても同様です。

  • 80 % (警告)
  • 95 % (エラー)

アプリケーション ノードが警告アラートをトリガすると、ヒープ ダンプとスレッド ダンプを取得し、詳細に調査します。インスタンスがクラッシュしそうな場合は、ローリング リスタートを実行します。

今日まで、アラートがトリガーされると、データベース ノードは常に自力で回復しています。

ガベージ コレクタの停止
長時間の停止は、クラスタ メンバーシップでの問題を引き起こす可能性があります。

このメトリックは、開発フィードバック用にも追跡しています。停止情報によって、不要なオブジェクトを多数作成している Confluence の領域を特定できます。これらの領域を分析して、Confluence の改善に役立てます。

ガベージ コレクターの 5 秒以上の停止

通常、このアラートではアクションは不要ですが、潜在的な機能停止の可能性の警告として役立ちます。ここで収集したデータによって、その他の機能停止の根本的な原因を診断することもできます。

ガベージ コレクターがこのアラートを頻繁にトリガーする場合、インスタンスのヒープの調整が必要かどうかを確認します。

ロードバランサー

追跡するメトリックアラート レベルアラートがトリガーされたときの対応

タイムアウト回数
バックエンド ノードが処理できなくなったときにタイムアウトをリクエストします。

1 時間で 300 回のタイムアウト

短時間で大量のタイムアウトが発生した場合、通常、そのあとに他のアラートが発生します。トリガーされたアラートと他のメトリックを調査し、機能停止や同様の問題が差し迫っているかどうかを確認します。

ノード ヘルス
ロード バランサーは、定期的にクラスタ ノードのヘルスをチェックします。チェックに失敗したノードは切断され、後でチェックに合格すると再接続されます。すべてのノードが同時に切断されると機能が停止します。

詳細については、「ロード バランサーの構成オプション」を参照してください。

ロード バランサーがノードを切断または再接続したタイミング

ノードが切断されたら、その状態を確認し、必要に応じて再起動します。また、他のトリガされたアラートをチェックし、ノードが切断された原因を確認します。

内部サーバー エラー
ロード バランサーが内部サーバー エラー (エラー コード 500) を返す場合、通常はリクエストを処理するバックエンド ノードが存在しません。
ロード バランサーで 1 秒間に 10 回を超える内部サーバー エラーが発生した時

トリガーされた他のアラートをチェックし、特定のサブシステム (データベースやストレージなど) に問題があるかどうかを確認します。

ストレージ

追跡するメトリックアラート レベルアラートがトリガーされたときの対応
共有ホームのファイル システムの I/O
I/O が多いとファイル アクセスの速度が低下し、タイムアウトする可能性があります。
PercentIOLimit が 98 より大きくなったとき。これは、共有ホームのファイル システム I/O が制限値である 98 % を超えていることを意味します。詳細については、「Amazon CloudWatch による監視」を参照してください。I/O 制限を増やす必要があるかどうかを調査します。
ディスク容量
使用量に対応できるようにディスク容量を拡張するか、ストレージ関連の問題についてさらに確認する必要があるかどうかを、早い段階で知っておく必要があります。

ディスクの空き容量について、異なるレベルの 2 つのアラートを設定しています。

  • 30 % (警告)
  • 10 % (エラー)


空き容量が不足しているが消費率が通常のままの場合、ストレージの空き容量を拡大します。

ディスクの消費率が異常に急増した場合、異常な動作を示しているプロセスがあるかどうかを確認します。これには、過去 24 時間以内に消費されたディスク容量の確認も含まれます。

安定性の監視

以下のアラートは、インスタンスの全体的な安定性に関係します。パフォーマンスの問題に対処する作業のほとんどがシステム停止の防止につながるため、これらのアラートはあまりトリガーされません。

追跡するメトリックアラート対象イベントアラートがトリガーされたときの対応

一般的なエラー条件
インスタンスが停止した場合、その原因となったログを調査して新しいエラーがないかどうかを確認します。特定のエラーがシステム停止を予期していると判断した場合、それに関するアラートを追加します。

アラートに含める一般的なエラーの一部:

アラートが作成されるエラーのほとんどは、それらによるシステム停止を防ぐ方法とともに、Confluence ナレッジベースに記載されています。

Hazelcast クラスタ メンバーシップ
既定では、ハートビートが 30 秒以内に送信されない場合、Hazelcast によってノードが削除され、再追加されます。アトラシアンでは、これを 60 秒以内に行うように設定しています。
ノードがクラスターから削除されて再追加されたとき 

影響されたノードでログ分析、スレッド ダンプ、ヒープ ダンプを実行します。これらのいずれかがクラスタ パニックを示しているか、システム停止が予期される場合、ローリング リスタートを実行します。

クラスタ パニック
重大なエラーであり、通常は Confluence の完全な再起動が必要です。

すべてのクラスタ パニック。アトラシアンの監視ツールでは、そのインスタンスで過去に発生したパニックの関連イベントについて、アプリケーション ログが確認されます。

Confluence の完全な再起動を実行します。これは、すべてのアプリケーション ノードをシャットダウンし、1 つずつ起動することを意味します。

関連情報については、「Data Center のトラブルシューティング」と「Confluence Data Center のトラブルシューティング」を参照してください。

アラートしないメトリック

以下のメトリックに関するアラートは設定されていませんが、異常なスパイクやディップは定期的に監視しています。他のアラートがトリガーされたときや、Apdex が降下し始めた場合にも、これらを確認します。

追跡するメトリック監視プラクティス

JVM メモリ
定期的にインスタンスを監視し、JVM がメモリ不足になっていないことを確認しています。関連情報については、「'OutOfMemoryError Java heap space' エラーで Confluence がクラッシュする」を参照してください。

JVM のメモリが少なくなり始めたら、ヒープ ダンプとスレッド ダンプを取得します。いずれかのダンプでクラッシュが予期される場合、ローリング リスタートを実行します。


アクティブな HTTP スレッドの数
定常的に使用するスレッドが多くなると、アプリケーション デッドロックが発生する可能性があります。

このメトリックにおける異常なスパイクがデッドロックなどの問題と一致する場合、影響する各ノードを再起動します。

そうでない場合、スレッド制限を調整したり、さらなる調査のためにスレッド ダンプを取得したりします。関連情報については、「ヘルス チェック: スレッド制限」を参照してください

Atlassian が提供するサービス

当社では、ニーズの変化、アプリケーションの改善、新しい知見などに基づいて、インスタンスや監視戦略を再構成する可能性があります。独自の Data Center インスタンスのデプロイや互換性のある監視戦略の構築に関してガイダンスが必要な場合、アトラシアンのテクニカル アカウント マネージャーお問い合わせください

アトラシアンのプレミア サポート チームは、お客様のアプリケーションのデプロイメントがユーザーのニーズを完全に満たしていることを確認するためにヘルス チェックを実行し、アプリケーションとログを慎重に分析します。ヘルス チェックでパフォーマンスのギャップが判明した場合、プレミア サポートがお客様のデプロイメントで実施可能な変更を提案いたします。


最終更新日: 2019 年 2 月 21 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.