クラウド
Data Center 9.17
バージョン

Jira Service Management ガードレール

Performance and scaling

このページの内容

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

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

コミュニティに質問

このページで説明する内容は、最新の長期サポート バージョンである Jira Service Management 5.4 に適用されます。

背景

アトラシアンは、大手顧客のニーズをサポートすることを約束しています。その取り組みには、製品のパフォーマンスとスケーラビリティの継続的な改善が含まれます。インスタンス内のデータ量は、パフォーマンスと安定性の問題の要因になる可能性があります。インスタンスが大きくなるにつれて、時間の経過とともにパフォーマンスが低下するリスクも増えます。多くの場合は段階的に低下するため、チームに重大な影響を及ぼす状況に達するまで気付かれない可能性があります。

次の表では観察されたパフォーマンスと安定性への影響を説明して、リスクを軽減するために実行できるいくつかのアクションを提案しています。ガードレールは、一部の大手顧客の実際の経験と、スタンドアロンの Jira Service Management インスタンスでのパフォーマンス テストに基づいています。ガードレールは、必ずしもすべての組織の経験を表すものではありません。

パフォーマンスと安定性に関する重大な問題が発生するリスクを軽減する方法には、次のようなものがあります。

  • アプリの変更。たとえば、パフォーマンスを向上させるために新しいアプリ バージョンにアップグレード、またはユーザーの管理方法を変更します。

  • インフラストラクチャの変更。たとえば、メモリや CPU を増設、またはクラスターやミラーを実行します。

  • フットプリントを削減するためのデータ クリーンアップ アクティビティ。たとえば、アーカイブ、またはモノリス サイトを分割します。

これらはハード制限ではなく、一部の製品インスタンスは既にこれらのしきい値を超えている可能性があることにご注意ください。異なるデータ タイプ間の相互作用やサイトの負荷など、さまざまな要因によって次に示すような潜在的な影響が発生する可能性とその影響の程度が決まります。あらゆるタイプのリスクと同様に、リスクを特定して計画を立てることが不可欠です。そうすれば、これらのアクションに優先順位付けて将来のパフォーマンス問題の可能性を減らすのに役立ちます。

ガードレールとは

製品ガードレールとはデータ タイプに関する推奨事項であり、潜在的なリスクを特定してインスタンス最適化ジャーニーの次のステップに関する意思決定をサポートするように設計されています。

Jira Service Management ガードレール

次のガードレールは、スケール リスクを特定して軽減し、インスタンスのクリーンアップに関する意思決定を下すのに役立ちます。

サービス レベル アグリーメント (SLA)

CONTENTTYPE

プロジェクトあたりの SLA の数 

ガードレール

プロジェクトあたり 30 件の SLA

この数を調べる方法

プロジェクトごとの SLA の数を調べるには、次の SQL クエリを実行します。

SELECT p.pkey AS "Project Key", 
	COUNT(*) AS "SLA Count"
FROM "AO_54307E_TIMEMETRIC" tm
LEFT JOIN "AO_54307E_SERVICEDESK" sd ON tm."SERVICE_DESK_ID" = sd."ID"
LEFT JOIN "project" p ON sd."PROJECT_ID" = p.id
GROUP BY p.pkey ORDER BY p.pkey;

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • SLA の計算にかかる時間コストは、プロジェクトあたりの SLA の数に比例して増加します。

  • SLA が計算されて課題で利用可能になるまでに時間がかかる場合があります。

緩和オプション

SLA 目標

CONTENTTYPE

SLA 目標の数

ガードレール

SLA あたり 100 件の目標
プロジェクトあたり 400 件の SLA 目標

この数を調べる方法

SLA ごとの目標数を調べるには、次の SQL クエリを実行します。

SELECT g."TIME_METRIC_ID" AS "SLA ID", COUNT(*) AS "Goals Count"
FROM "AO_54307E_GOAL" g
GROUP BY g."TIME_METRIC_ID" ORDER BY g."TIME_METRIC_ID";

プロジェクトごとの SLA 目標の数を調べるには、次の SQL クエリを実行します。

SELECT p.pkey AS "Project Key", 
	COUNT(*) AS "Goals Count" 
FROM "AO_54307E_TIMEMETRIC" tm 
	LEFT JOIN "AO_54307E_SERVICEDESK" sd ON tm."SERVICE_DESK_ID" = sd."ID" 
	LEFT JOIN "project" p ON sd."PROJECT_ID" = p.id 
	LEFT JOIN "AO_54307E_GOAL" g ON g."TIME_METRIC_ID" = tm."ID"
GROUP BY p.pkey ORDER BY p.pkey;

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • SLA の計算にかかる時間コストは、プロジェクトあたりの SLA 目標の数に比例して増加します。

  • SLA が計算されて課題で利用可能になるまでに時間がかかる場合があります。

緩和オプション

アセット オブジェクト スキーマ

CONTENTTYPE

オブジェクト スキーマの数

ガードレール

1000 個のオブジェクト スキーマ

この数を調べる方法

次の REST エンドポイントは、各オブジェクト スキーマの高レベル統計を取得します。 /rest/insight/latest/analytics/schema

オブジェクト スキーマの数を調べるには、返された応答内の schemaId の数を数えます。

返された応答の形式

[ { "schemaId":x,
"totalObjectCount":x,
"totalObjectTypeCount":x,
"totalAttributeCount":x,
"numberOfObjectsLinkedToIssues":x,
"numberOfObjectsWithUniqueAttribute":x,
"numberOfAutomationRules":0x
"numberOfAutomationIfs":x,
"numberOfAutomationWhens":x,
"numberOfAutomationThens":x,
"maxNumberOfObjectsByObjectType":x,
"averageNumberOfObjectsByObjectType":x,
"maxNumberOfAttributesByObjectType":x,
"averageNumberOfAttributesByObjectType":x },
...
]

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 新しいオブジェクト スキーマを作成するときにパフォーマンスが低下します。

  • 一部の AQL 検索には時間がかかります。

  • Jira Service Management のパフォーマンス全般に影響を与えます。

緩和オプション

  • 未使用または不要なオブジェクト スキーマを確認して削除します。

アセット オブジェクト タイプ

CONTENTTYPE

オブジェクト スキーマあたりのオブジェクト タイプの数

ガードレール

オブジェクト スキーマあたり 500 個のオブジェクト タイプ

この数を調べる方法

次の REST エンドポイントは、各オブジェクト スキーマの高レベル統計を取得します。 /rest/insight/latest/analytics/schema

オブジェクト スキーマのオブジェクト タイプの数を調べるには、返された応答内の totalObjectTypeCount フィールドを参照します。

返された応答の形式

[{"schemaId":x,
"totalObjectCount":x,
"totalObjectTypeCount":x,
"totalAttributeCount":x,
"numberOfObjectsLinkedToIssues":x,
"numberOfObjectsWithUniqueAttribute":x,
"numberOfAutomationRules":0x
"numberOfAutomationIfs":x,
"numberOfAutomationWhens":x,
"numberOfAutomationThens":x,
"maxNumberOfObjectsByObjectType":x,
"averageNumberOfObjectsByObjectType":x,
"maxNumberOfAttributesByObjectType":x,
"averageNumberOfAttributesByObjectType":x},
...
]

または、次の SQL クエリを実行します。

SELECT obj_schema."OBJECT_SCHEMA_KEY", 
	COUNT(*) AS "Object Types Count"
FROM "AO_8542F1_IFJ_OBJ_TYPE" AS obj_type
INNER JOIN "AO_8542F1_IFJ_OBJ_SCHEMA" AS obj_schema ON obj_type."OBJECT_SCHEMA_ID" = obj_schema."ID"
GROUP BY obj_schema."OBJECT_SCHEMA_KEY";

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 500 個のオブジェクト タイプでは、次のアクションでパフォーマンスが低下することがわかっています。

    • オブジェクト スキーマのオブジェクト タイプを拡張する

    • オブジェクト スキーマのページを表示する

    • 新規オブジェクトの作成

緩和オプション

  • オブジェクト スキーマを複数のオブジェクト スキーマに分割してオブジェクト タイプを分散することをご検討ください。

アセット オブジェクト

CONTENTTYPE

オブジェクトの数

ガードレール

オブジェクト スキーマごとに 500 k 個のオブジェクト（この制限にはアーカイブされたオブジェクトは含まれません）

インスタンスあたり 200 万個のオブジェクト - 主に重いオブジェクトが使用されています。つまり、次のようなオブジェクトです。

  • インバウンド/アウトバウンドの参照を介して、他の多数のオブジェクトにリンクされている

  • カスタム フィールドを介して多数の課題にリンクされている

インスタンスあたり 500 万個のオブジェクト - 主に軽いオブジェクトが使用されます。

この数を調べる方法

オブジェクト スキーマあたりのオブジェクト数を調べるには、次のいずれかの方法をお勧めします。

  • [アセット] > [オブジェクト スキーマ] に移動します

    "オブジェクト スキーマ" ページ"オブジェクト スキーマ" ページ

  • 次の REST エンドポイントを使用して、各オブジェクト スキーマの高レベル統計を取得します。/rest/insight/latest/analytics/schema. 返された応答内で各オブジェクト スキーマの totalObjectCount フィールドを参照します。

    返された応答の形式

    [{"schemaId":x,
    "totalObjectCount":x,
    "totalObjectTypeCount":x,
    "totalAttributeCount":x,
    "numberOfObjectsLinkedToIssues":x,
    "numberOfObjectsWithUniqueAttribute":x,
    "numberOfAutomationRules":0x
    "numberOfAutomationIfs":x,
    "numberOfAutomationWhens":x,
    "numberOfAutomationThens":x,
    "maxNumberOfObjectsByObjectType":x,
    "averageNumberOfObjectsByObjectType":x,
    "maxNumberOfAttributesByObjectType":x,
    "averageNumberOfAttributesByObjectType":x},
    ...
    ]

インスタンス内のオブジェクトの数を調べるには、次の SQL クエリを実行します。

SELECT count(*) as "Asset Objects Per Instance"
FROM "AO_8542F1_IFJ_OBJ";

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • アセット検索機能は、オブジェクト数の増加と比例して遅くなります。

  • 固有の属性値をチェックしてオブジェクトを作成するのに必要な時間は、オブジェクトの数に比例して増加します。

緩和オプション

  • オブジェクトを検索するときオブジェクトの数が多いほど AQL 検索のパフォーマンスが低下するため、可能な場合はクエリの開始時に検索スコープをオブジェクト スキーマからオブジェクト タイプに絞り込むことをお勧めします。たとえば、アトラシアンのテストでは、AQL 検索の objecttype=x and attribute_name having outboundReferences() と attribute_name having outboundReferences() を比較すると、前者のほうが 2 倍速く実行されることが示唆されています。

  • 可能な場合はオブジェクトの削除を検討します。

  • JVM メモリを推奨値以上に増やすことを検討します。

アセット属性

CONTENTTYPE

オブジェクト タイプあたりの設定された属性の数

ガードレール

オブジェクト タイプあたり 100 個の設定された属性

この数を調べる方法

次の REST エンドポイントは、各オブジェクト スキーマの高レベル統計を取得します。 /rest/insight/latest/analytics/schema

オブジェクト タイプごとに設定された属性の平均数と最大数を調べるには、返された応答内でそれぞれ maxNumberOfAttributesByObjectType と averageNumberOfAttributesByObjectType フィールドを参照します。

返された応答の形式

[{"schemaId":x,
"totalObjectCount":x,
"totalObjectTypeCount":x,
"totalAttributeCount":x,
"numberOfObjectsLinkedToIssues":x,
"numberOfObjectsWithUniqueAttribute":x,
"numberOfAutomationRules":0x
"numberOfAutomationIfs":x,
"numberOfAutomationWhens":x,
"numberOfAutomationThens":x,
"maxNumberOfObjectsByObjectType":x,
"averageNumberOfObjectsByObjectType":x,
"maxNumberOfAttributesByObjectType":x,
"averageNumberOfAttributesByObjectType":x},
...
]

または、次の SQL クエリを実行します。

SELECT 
    ch."ID", 
    obj_type."NAME",
    count(*) AS "Attribute Count"
FROM "AO_8542F1_IFJ_OBJ_TYPE_ATTR" AS obj_attr_type
    INNER JOIN "AO_8542F1_IFJ_OBJ_TYPE" AS obj_type  ON obj_type."ID" = obj_attr_type."OBJECT_TYPE_ID"
    inner join "AO_8542F1_IFJ_OBJ_SCHEMA" as ch on obj_type."OBJECT_SCHEMA_ID" = ch."ID" 
GROUP BY 
    ch."ID", 
    obj_type."NAME"
order by ch."ID"

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • オブジェクト タイプに設定された属性の数を増やすと、オブジェクト グラフの表示が著しく遅くなります。

緩和オプション

  • 不要な属性を削除します。

アセット属性の値

CONTENTTYPE

すべてのオブジェクトに保存されている属性値の数

ガードレール

2500 万個の属性値 - 主に重いオブジェクトが使用されます。次のようなオブジェクトが該当します。

  • インバウンド/アウトバウンドの参照を介して、他の多数のオブジェクトにリンクされている

  • カスタム フィールドを介して多数の課題にリンクされている

5000 万の属性値 - 主に軽いオブジェクトが使用されます。

この数を調べる方法

インスタンス内の属性値の数を調べるには、次の SQL クエリを実行します。

SELECT count(*) as "Assets Attribute Values per Instance"
FROM "AO_8542F1_IFJ_OBJ_ATTR_VAL";

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • オブジェクトの属性値の数が増えるにつれて、アセットの検索機能の速度が線形的に低下します。次のようなクエリなど、費用のかかる検索クエリではその傾向が顕著です。

    • 未解決の課題にリンクされている大量のオブジェクトをフィルタリングする

    • having outboundReferences() を使用する

  • 固有の属性値をチェックしてオブジェクトを作成するのに必要な時間は、オブジェクトの数に比例して増加します。

このガードレールは、事実上すべてのオブジェクトが単一のオブジェクト スキーマ内で作成されるという最悪のシナリオを想定して設定されています。オブジェクトがより均等に分散されていれば、パフォーマンスへの影響はそれほど大きくならないと考えられます。

緩和オプション

  • オブジェクトを検索するときオブジェクトの数が多いほど AQL 検索のパフォーマンスが低下するため、可能な場合はクエリの開始時に検索スコープをオブジェクト スキーマからオブジェクト タイプに絞り込むことをお勧めします。たとえば、アトラシアンのテストでは、AQL 検索の objecttype=x and attribute_name having outboundReferences() と attribute_name having outboundReferences() を比較すると、前者のほうが 2 倍速く実行されることが示唆されています。

  • 可能な場合はオブジェクトの削除を検討します。

  • JVM メモリを推奨値以上に増やすことを検討します。

最終更新日 2024 年 11 月 6 日

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

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.