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

アトラシアンでは、特に顧客向けのサービスにおいて、エンタープライズ規模の複数の開発ツールを使用しています。例として、次の 2 つのサービスがあります。

これらのサービスは個別の Jira Data Center インスタンスで実行されています。現在まで、両方のインスタンスで合計 190 万件のチケットを追跡し、約 480 万ユーザーのユーザー ベースを利用しています。 

アトラシアンでの Jira Data Center インスタンスの使用方法

getsupport.atlassian.com と jira.atlassian.com は両方とも、すべてのタイムゾーンにわたる顧客とアトラシアン社員によって使用されます。これは、これまでに取り上げたインスタンスよりもはるかに大きなユーザー ベースに変換されます。公開サービスのため、高可用性と優れた応答時間を維持する必要があります。これにより、エンタープライズ レベルの高い負荷においても Jira Software Data Center と Jira Service Desk Data Center のパフォーマンスを確保可能であることを実演しています。


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

コンテンツ

次の統計情報は、各インスタンスのサイズとデータの複雑性を示すのに役立ちます。 

統計情報

getsupport.atlassian.com

jira.atlassian.com

課題 126 万以上 661,000
プロジェクト 38 140
カスタム フィールド 157 224
ワークフロー アクティブ 21 94
合計 45 242
合計ユーザー数 11 万以上 368 万以上
グループ 148 61
コメント 86 万以上 138 万以上
権限スキーム 84 91
課題セキュリティ レベル 6 23
カスタム フィルター (共有) 8,500 3,500

トラフィック

次の統計情報は、各インスタンスがサポートする負荷の量を示すのに役立ちます。


統計情報
getsupport.atlassian.com jira.atlassian.com

1 時間当たりのアクティブなデータベース コネクション数

月平均

62 62
週平均 62 62
ピーク 65 63
HTTP レベルのスループット


1 時間あたりの合計平均 22,500 以上 37,000 以上
1 時間当たりの最大数 約 43,000 約 51,000

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

平均して、1 時間当たり約 5000 の同時接続ユーザー 平均して、1 時間当たり約 3500 の同時接続ユーザー


参考情報

  • 1 時間あたりのアクティブなデータ コネクションでは、サンプルとして 2018 年 5 月の 1 か月のトラフィック データを使用しています。1 時間当たりの同時接続ユーザー数および HTTP レベル スループットでは、低トラフィックとなる週末の時間をフィルタリングするため、2018 年 6 月の連続した 5 営業日のトラフィック データを使用しています。
  • 1 時間あたりのアクティブなデータベース コネクション: DatabaseConnections メトリックを通じてこれを追跡します (「Amazon RDS メトリックとディメンション」を参照)。これらのオープンなコネクションのほとんどは、事前に割り当てられています。ピークと平均との偏差が小さいため、データベースの最小スレッド プールが適切に設定されていることがわかります。
  • 1 時間当たりの同時接続ユーザー数: 1 時間のうちに作成された、新しい承認済みセッションの数を数えました。これらのユーザーはその 1 時間の間、サイト上に滞在しているとみなします。
  • HTTP レベルのスループット: ロード バランサ経由で行われたリクエストの数を数えました。

両方のインスタンスで選択された 12 時間のトラフィック サンプルを使用すると、ほとんどのユーザーが、課題の作成、ダッシュボードの表示やその他のアクティビティよりも課題の表示に時間を費やしていることがわかります。

アトラシアンのサポートおよび開発チームもこれらのサービスを使用して、顧客やパートナーと共同でチケットを追跡しています。このため、社外のユーザーとのコラボレーションのために、これら両方のサービスが必須となります。

いずれのインスタンスも 1 日を通じてトラフィック量が非常に多く、ほとんどの場合は予測可能な、スパイクがあります。これらは Data Center インスタンスであるため、高い可用性を実現しており、個々のノードの障害は致命的な問題にはなりません。したがって、アップタイムの維持よりもパフォーマンスの管理に集中することができます。 

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

Jira Data Center インスタンスは、個別の Amazon Web Services (AWS) 仮想プライベート クラウド上でホストされています。これらは、データベースとアプリケーション クラスターに使用されているノードを除き、同じトポロジーおよび構成を使用しています。 

機能 インスタンス タイプ Number (番号)
getsupport.atlassian.com jira.atlassian.com
Jira アプリケーション

c5.9xlarge

m4.4xlarge 3
データベース (Amazon RDS Postgresql)

db.m4.4xlarge

db.m4.2xlarge 1
ロードバランサー AWS Application Load Balancer 1
ストレージおよびファイル システム Elastic File System  3


getsupport.atlassian.com のJira アプリケーション内の各ノードは、1 つのローカル 240 GB ディスクを使用し、/rootJira インデックス キャッシュを保存します。jira.atlassian.com では、アプリケーション クラスター ノードは、/root に 40 GB ディスクJira インデックス キャッシュに 30 GB ディスクを個別に使用します。getsupport.atlassian.com インスタンスには jira.atlassian.com と比較して約 2 倍の数の課題があり、このためにディスク サイズには大きな違いがあります。さらに、両方のインスタンスのアプリケーション クラスターはオートスケールを行いません (アトラシアンではサポートしていないため)

ノード タイプと各アプリケーション ノード ディスクのサイズを除き、getsupport.atlassian.com と jira.atlassian.com の構成は同一です。


Component

設定

データベース (Amazon RDS Postgresql) データベース ノードはシングルインスタンス用の高可用性を有効化した汎用 SSD ストレージを使用しています。
ロードバランサー ロード バランサにはターゲット グループが 1 つだけあります。
ストレージおよびファイル システム

各インスタンスでは次のそれぞれについて、3 つの Elastic File System 共有ボリュームを使用します。

  • 共有構成
  • 共有ホーム
  • 共有バイナリ
JVM 24 GB の最大ヒープ サイズ (G1 ガベージ コレクターを使用)

連携サービス

getsupport.atlassian.com インスタンスではユーザーがインストールしたアプリが 43 jira.atlassian.com では 40 個が有効になっています。いずれのインスタンスも OpenID を使用し、Active Directory ストアに対してユーザーを直接認証します。

次の表は、各インスタンスでリンクされているアトラシアン アプリケーションの組み合わせを示しています。

アトラシアン アプリケーション getsupport.atlassian.com jira.atlassian.com
Jira 11 13
Confluence 5 8
Bitbucket 0 2
Bamboo 0 17
Fisheye / Crucible 0 2
その他 1 1

監視戦略

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

各インスタンスでアップデートの頻度が異なります。getsupport.atlassian.com はエンタープライズ リリースのたびに更新され、jira.atlassian.com は各フィーチャー リリースで更新されます。また、それぞれに対して最新のバグ修正リリースも即座に適用されます。

ほとんどのアップデートでは、過去に発生したサービス停止や深刻な問題を防ぐための修正や最適化が行われています。アップデート頻度を考慮すると、1 つのリリースで設定したしきい値が次のリリースでは利用できなくなる可能性があるため、アラートの設定が困難な場合があります。当社の経験では、リリースをまたいで問題が継続することはめったにありません。

アトラシアンで使用しているアラートでは、幅広い範囲の潜在的な問題に焦点を当てると同時に、過去に発生したことのない問題についても警告しています。このアラートは、複数のリリースを通じ、未知のものを含む新しい問題について一貫して警告します。次のセクションでは、アトラシアンで使用しているアラートと使用プラクティスについて説明します。

継続的なスパイクに焦点を当てる

getsupport.atlassian.com と jira.atlassian.com のいずれでも、リソースの使用率を上げる可能性があるトラフィックのスパイクが標準的に発生します。これらの急増は致命的なレベル (CPU 使用率の 90 % など) になる場合がありますが、Jira ではこれらのほとんどを問題なく復旧できます。したがって、メトリックが特定のしきい値に到達した際のアラートを設定すると、多くの偽陽性が検出される可能性があります。

アトラシアンでは、継続的なスパイクを監視します。ノード メトリックが長時間酷使されたとき、つまり、メトリックが特定のしきい値内にある時間が長すぎるタイミングを取得します。これを行うため、各ノード アラートに 3 つのディメンションを設定します。

  1. 時間間隔
  2. 警告レベル
  3. 重要レベル

アトラシアンではサードパーティ製の監視ツールを使用して、特定のメトリックのサンプルを取得し、メトリックが設定した期間に特定のしきい値内にとどまっているかどうかを計算しています。これにより、ノードの空きディスク容量が 10 % 未満になったタイミングなどを無視することができます。代わって、空きディスク容量が 10 分間の間 10 % 未満になると、アラートを受け取ります。

ノード

追跡するメトリック 期間 (分) 警告レベル 重要レベル

IOWait
I/O 操作が完了するの待機する間、CPU がアイドル状態になっている時間を追跡します。 

10 > 15 %  > 30 %

システム CPU 時間
カーネル スペース内で CPU が消費する時間の量を表します。 

5 > 80 % > 90 %

残りディスク容量
使用量に対応できるようにディスク容量を拡張するか、ストレージ関連の問題についてさらに確認する必要があるかどうかを、早い段階で知っておく必要があります。

10 < 10 % なし

使用可能なメモリ
各ノードに使用可能な物理 RAM が十分に残っていることを確認する必要があります。

5 < 5 % < 3 %

JVM

アトラシアンでは、Jira のプロセスが稼働中かどうかを定期的に確認するため、サードパ-ティ製のツールを使用しています。また、次のアラートを使用して、すべてのアプリケーション クラスター ノードの JVM の健全性を監視しています。これらのアラートは、インスタンスの速度が低下している可能性がある場合や、ノードがオフラインになりそうな場合に警告を表示するのに役立ちます。 

追跡するメトリック 期間 (分) 警告レベル 重要レベル

ガベージ コレクション時間
ガベージ コレクションでの CPU 時間が多すぎると、アプリケーション ノードの速度が低下します。

5 > 10 % > 20 %

Java ヒープ メモリの消費量
この警告は、使用中の最大 Java ヒープ メモリを追跡します。このアラートのトリガー頻度が多すぎる場合、メモリ リークや、JVM ヒープの微調整が必要な可能性があります。

5 > 90 % > 95 %

HTTP レスポンスの監視 

アトラシアンでは、getsupport.atlassian.com および jira.atlassian.com の HTTP レスポンス時間を測定し、パフォーマンスの簡単な概要を取得しています。このために、米国の 3 つのリージョンから両方のインスタンスに定期的に ping を送信しています。担当の管理者は次の場合に通知を受け取ります。

  • HTTP レスポンス時間が 7-10 秒 (警告)
  • HTTP レスポンス時間が 10 秒以上 (致命的)
  • ping が 200 (OK) と 302 (リダイレクト) 以外の HTTP リターン コードを返す

ログの切り替え

アトラシアンでは、ログをリアルタイムで別のサーバーに保存しています。これにより、すべてのノードからのログを組み合わせ、クラスター全体を分析することができます。特定のノードの問題を追跡する必要がある場合に備え、それぞれのログ ストリームのステートメントにはノード ID を含めています。 

ログの整理と保存を別のサーバーで行っているため、各ノードでは古いログを 1 時間ごとに削除できます。各ノードは 5 時間より古いログを自動的に削除します。この処理を自動化することで、ログがディスク容量を消費しすぎるのを防ぎます。ノードでディスクの空き容量がなくなるとデータベースは応答しなくなり、これが発生するとインスタンス全体がオフラインになるため、データベースでは特にこの処理が重要になります。 


Atlassian が提供するサービス

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

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



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

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

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