Jira Data Center のサンプル デプロイメントおよび監視戦略
アトラシアンでは、特に顧客向けのサービスにおいて、エンタープライズ規模の複数の開発ツールを使用しています。例として、次の 2 つのサービスがあります。
- getsupport.atlassian.com (uses Jira Service Management to manage support requests)
- jira.atlassian.com (Jira Software を使用した各製品の機能開発およびバグ修正の追跡)
これらのサービスは個別の Jira Data Center インスタンスで実行されています。現在まで、両方のインスタンスで合計 190 万件のチケットを追跡し、約 480 万ユーザーのユーザー ベースを利用しています。
Jira Data Center 8.4 の監視機能
この記事の公開の数か月前にリリースされた Jira Data Center 8.4 では、いくつかの監視機能を追加しました。Jira Data Center デプロイメントのパフォーマンスの監視方法の最新情報については、「Jira Data Center の監視」を参照してください。
アトラシアンでの Jira Data Center インスタンスの使用方法
getsupport.atlassian.com と jira.atlassian.com は両方とも、すべてのタイムゾーンにわたる顧客とアトラシアン社員によって使用されます。これは、これまでに取り上げたインスタンスよりもはるかに大きなユーザー ベースに変換されます。公開サービスのため、高可用性と優れた応答時間を維持する必要があります。これにより、エンタープライズ レベルの高い負荷においても Jira Software Data Center と Jira Service Management Data Center のパフォーマンスを確保可能であることを実演しています。
アトラシアンのサポートおよび開発チームもこれらのサービスを使用して、顧客やパートナーと共同でチケットを追跡しています。このため、社外のユーザーとのコラボレーションのために、これら両方のサービスが必須となります。
いずれのインスタンスも 1 日を通じてトラフィック量が非常に多く、ほとんどの場合は予測可能な、スパイクがあります。これらは Data Center インスタンスであるため、高い可用性を実現しており、個々のノードの障害は致命的な問題にはなりません。したがって、アップタイムの維持よりもパフォーマンスの管理に集中することができます。
インフラストラクチャとセットアップ
Jira Data Center インスタンスは、個別の Amazon Web Services (AWS) 仮想プライベート クラウド上でホストされています。これらは、データベースとアプリケーション クラスターに使用されているノードを除き、同じトポロジーおよび構成を使用しています。
| 機能 | インスタンス タイプ | 数値 | |
|---|---|---|---|
| getsupport.atlassian.com | jira.atlassian.com | ||
| Jira アプリケーション | m4.4xlarge | 3 | |
| データベース (Amazon RDS Postgresql) | db.m4.2xlarge | 1 | |
| Load balancer | AWS Application Load Balancer | 1 | |
| ストレージおよびファイル システム | Elastic File System | 3 | |
Each node in getsupport.atlassian.com's Jira application cluster uses one local 240GB disk, storing both /root and Jira index cache. In jira.atlassian.com, the application cluster nodes use a separate 40GB disk for /root and 30GB disk for the Jira index cache. The getsupport.atlassian.com instance has almost double the number of issues compared to jira.atlassian.com, which accounts for the large difference in disk size. In addition, both instances' application clusters do not auto-scale (as we don't support this).
Other than the node types and the size of each application node's disk, getsupport.atlassian.com and jira.atlassian.com are configured identically:
コンポーネント | 構成 |
|---|---|
| データベース (Amazon RDS Postgresql) | データベース ノードはシングルインスタンス用の高可用性を有効化した汎用 SSD ストレージを使用しています。 |
| Load balancer | ロード バランサにはターゲット グループが 1 つだけあります。 |
| ストレージおよびファイル システム | 各インスタンスでは次のそれぞれについて、3 つの Elastic File System 共有ボリュームを使用します。
|
| JVM | 24 GB の最大ヒープ サイズ (G1 ガベージ コレクターを使用) |
Application nodes | 各ノードでは、スワッピングも無効化されています。これは、スワッピングにより、Jira のパフォーマンスが低下する可能性があるためです。 代わりに、G1 ガベージ コレクターを使用して最大ヒープ サイズを 24GB に設定しています。これにより、ノードは常に十分なメモリを確保できるようになります (つまり、スワップは不要になります)。 |
連携サービス
The getsupport.atlassian.com instance has 43 user-installed apps enabled, while jira.atlassian.com has 40. Both instances use OpenID to authenticate users directly against an Active Directory store.
次の表は、各インスタンスでリンクされているアトラシアン アプリケーションの組み合わせを示しています。
| アトラシアン アプリケーション | getsupport.atlassian.com | jira.atlassian.com |
|---|---|---|
| Jira | 11 | 13 |
| Confluence | 5 | 8 |
| Bitbucket | 0 | 2 |
| Bamboo | 0 | 17 |
| Fisheye/Crucible | 0 | 2 |
| その他 | 1 | 1 |
監視戦略
We keep a different update cadence for both instances; getsupport.atlassian.com gets updated every Long Term Support release, and jira.atlassian.com with each feature release. We quickly apply the latest bug fix release for each as well.
ほとんどのアップデートでは、過去に発生したサービス停止や深刻な問題を防ぐための修正や最適化が行われています。アップデート頻度を考慮すると、1 つのリリースで設定したしきい値が次のリリースでは利用できなくなる可能性があるため、アラートの設定が困難な場合があります。当社の経験では、リリースをまたいで問題が継続することはめったにありません。
アトラシアンで使用しているアラートでは、幅広い範囲の潜在的な問題に焦点を当てると同時に、過去に発生したことのない問題についても警告しています。このアラートは、複数のリリースを通じ、未知のものを含む新しい問題について一貫して警告します。次のセクションでは、アトラシアンで使用しているアラートと使用プラクティスについて説明します。
継続的なスパイクに焦点を当てる
Both getsupport.atlassian.com and jira.atlassian.com get regular traffic spikes that can drive up resource usage. These spikes can sometimes hit critical levels (for example, 90% of CPU usage), but Jira can recover gracefully from most of them. Because of this, setting an alert for when metrics hit certain thresholds can set off many false positives.
アトラシアンでは、継続的なスパイクを監視します。ノード メトリックが長時間酷使されたとき、つまり、メトリックが特定のしきい値内にある時間が長すぎるタイミングを取得します。これを行うため、各ノード アラートに 3 つのディメンションを設定します。
- 時間間隔
- 警告レベル
- 重要レベル
アトラシアンではサードパーティ製の監視ツールを使用して、特定のメトリックのサンプルを取得し、メトリックが設定した期間に特定のしきい値内にとどまっているかどうかを計算しています。これにより、ノードの空きディスク容量が 10 % 未満になったタイミングなどを無視することができます。代わって、空きディスク容量が 10 分間の間 10 ％ 未満になると、アラートを受け取ります。
ノード
| 追跡するメトリック | 期間 (分) | 警告レベル | 重要レベル |
|---|---|---|---|
IOWait | 10 | > 15 % | > 30 % |
システム CPU 時間 | 5 | > 80 % | > 90 % |
残りディスク容量 | 10 | < 10 % | なし |
使用可能なメモリ | 5 | < 5 % | < 3 % |
JVM
アトラシアンでは、Jira のプロセスが稼働中かどうかを定期的に確認するため、サードパ－ティ製のツールを使用しています。また、次のアラートを使用して、すべてのアプリケーション クラスター ノードの JVM の健全性を監視しています。これらのアラートは、インスタンスの速度が低下している可能性がある場合や、ノードがオフラインになりそうな場合に警告を表示するのに役立ちます。
| 追跡するメトリック | 期間 (分) | 警告レベル | 重要レベル |
|---|---|---|---|
ガベージ コレクション時間 | 5 | > 10 % | > 20 % |
Java ヒープ メモリの消費量 | 5 | > 90 % | > 95 % |
HTTP レスポンスの監視
We measure the HTTP response time of getsupport.atlassian.com and jira.atlassian.com to get a quick overview of their performance. To do this, we periodically ping both instances from three US regions. Our on-duty admins are automatically notified whenever:
- HTTP レスポンス時間が 7-10 秒 (警告)
- HTTP レスポンス時間が 10 秒以上 (致命的)
- ping が 200 (OK) と 302 (リダイレクト) 以外の HTTP リターン コードを返す
ロード バランサの ヘルス チェック
30 秒ごとに、ロード バランサで自動化されたヘルス チェック リクエストが実行されます。リクエストは 29 秒後にタイムアウトとなり、その時点でもう一回リクエストが実行されます。
ロード バランサで連続して 2 回タイムアウトが発生すると、unhealthy というラベルが付けられます。ヘルス チェック リクエストは継続されます。そのあとに連続して 2 回ヘルス チェックに成功すると、ロード バランサに再び healthy というラベルが付けられます。
ロード バランサに unhealthy のラベルが付けられると、アトラシアンの当直の管理者に通知が送信されます。管理者が調査を開始する時間までに healthy になっていた場合、管理者はロード バランサの回復にかかった時間を確認します。
ログの切り替え
アトラシアンでは、ログをリアルタイムで別のサーバーに保存しています。これにより、すべてのノードからのログを組み合わせ、クラスター全体を分析することができます。特定のノードの問題を追跡する必要がある場合に備え、それぞれのログ ストリームのステートメントにはノード ID を含めています。
ログの整理と保存を別のサーバーで行っているため、各ノードでは古いログを 1 時間ごとに削除できます。各ノードは 5 時間より古いログを自動的に削除します。この処理を自動化することで、ログがディスク容量を消費しすぎるのを防ぎます。ノードでディスクの空き容量がなくなるとデータベースは応答しなくなり、これが発生するとインスタンス全体がオフラインになるため、データベースでは特にこの処理が重要になります。
Atlassian が提供するサービス
また、重要なイベントが発生した際に、ボトルネックを分析してアラートを表示するために使用できる、多数のモニターを導入しました。詳細は、「Jira Data Center の監視」を参照してください。