Jira のフェデレーション - 複数のインスタンスの管理

組織が複数の Jira インスタンスを使用して多数のユーザー向けの環境を実現している場合、これらのインスタンスを 1 つの Jira Data Center インスタンスに統合することをお勧めします。これにより、あらゆる大企業が Jira に求める、管理機能、相互運用、高可用性、およびパフォーマンスを実現できるようになります。 

ただしアトラシアンでは、統合や移行はすべての組織で利用可能なものではないことも理解しています。このような場合、インスタンスのフェデレーションを行うことで、インスタンスの接続性や相互運用性を確保したうえで自律性を実現することができます。本ガイドでは、フェデレーションしたインスタンスの健全性を維持するために役立つ、さまざまな機能とプラクティスについて説明します。

本ガイドに記載されているアプリ (アドオン) の一部は、トップ ベンダーが開発したものではありません。また、一部の方法はお客様の組織のセットアップに適していない場合があります。

フェデレーションに繋がる状況

最初に、フェデレーションにつながる状況について見てみましょう。当社のお客様に関して言えば、複数の Jira インスタンスの実行が必要となる 4 つの主な理由を識別できます。

  • Jira のボトムアップ成長: Jira の低価格ポイントや実用的な価値により、最初は 1 チームで Jira を開始して、その後、独自のサーバー インスタンスを回転させる新しいチームで組織全体へ広げるという場合が良くあります。

  • 合併や買収: 他の組織の買収や合併により、1 つの組織に複数の Jira サーバーが存在する場合があります。
  • 独立した IT 組織: 組織の異なる部門は、独自の IT 組織を運営している場合があります。このことは、他部門とのプロセスや協力が行われてから、後の段階で統合できる並列 Jira システムにつながります。
  • 意図的なフェデレーションのセットアップ: 以下の理由の 1 つまたは複数が、フェデレーテッド Jira システムの意図的なセットアップにつながる場合があります。

フェデレーション環境をセットアップする理由

専用インスタンスの意図的なセットアップへ掘り下げることで、顧客、パートナー、および自分たちの IT 組織の方法をまとめ、これらを実行するためのいくつかの理由を特定することができます。

  • パブリック / プライベート Jira: Jira はパーミッション スキームやユーザー グループを通じて識別されたグループのみが特定のコンテンツにアクセスできるようにする機能を提供しています。ただし、アトラシアン自体を含め、多くの顧客は、社内コンテンツ (開発など) をファイアウォール内の別のインスタンスで実行することを好みます。その場合、外部コンテンツ (サポート / パブリック機能のリクエストなど) をホストする専用インスタンスをセットアップして、顧客とパートナーがアクセスできるようにします。
  • 異なるレベルの複雑性: 少ないユーザーを対象とし、かつ複雑性の主な原因となっている 1 つのプロジェクトがある JIRA インスタンス (顧客フィールド、ワークフローやカスタマイズなど) の例を見てみましょう。この複雑性が全体的なパフォーマンスと JIRA インスタンス全体の安定性に影響するのを防ぐため、プロジェクトを専用 Jira サーバーへ移行するのが合理的です。
  • 新機能の利用と安定性とのバランス: 特定のチームの生産性が新機能 (例: Agile チーム向けの Jira Software の新機能) の利用可否による影響を大きく受けるが、組織の他の部分は新機能よりも実装済みの安定したワークフローやシステムの安定性に重きを置く場合があります。この場合、安定した古いバージョンの本番環境インスタンスを実行しながら、アーリー アダプタ向けに別の生産的な Jira サーバーを運用するオプションを検討できます。

  • 外部顧客要件: 一部の顧客は、組織に対し、他のインフラストラクチャと物理的に離れたシステム上で自分たちのプロジェクトを実行し、データをホストするよう要求する場合があります。これらの要件は、国防契約などの機密プロジェクトの場合に当てはまります。
  • 構成や設定が異なる: Jira の構成機能は、アプリケーションのほとんどすべての懸念に対してスキーマを提供することで有名です。これにより、1 つのインスタンスで多種多様な異なるプロジェクトをホストすることができます。このことは、独自のブランド化や異なる設定を持つことができるよう、1 つのプロジェクトに専用インスタンスが必要とする便利です。これらには、異なる優先順位や解決策、異なる管理者のセット、時間追跡機能を使用するかどうか、およびその他すべての Jira のグローバル設定が含まれます。 
  • 法的要件: データのプライバシー保護法、サーバーの管轄権や政府の調査などにより、特定の Jiraプロジェクトに対して別の管轄権に専用サーバーを置くこと決定する場合があります。このような場合の例として、欧州の企業が、個人の権利と同じ保護レベルでデータ プライバシー法を提供していない EU 外の国でホストされているサーバー上に EU 市民の個人情報データを保護できないことがあります。 
  • 内部サービスとしての Jira: 一部の大企業の顧客では、Jira をサービスとして社内で提供しています。そのような組織には標準構成があり、Jira システムをリクエストする各事業部門に対してそれらの構成を複製することができます。各システムには事業部門固有の管理者がおり、集中 IT 組織はシステム管理のコンピテンシーを保持します。 
  • リスクとダウンタイムの分散: インスタンスが大きくなると、アップグレードにかかる時間も長くなります。そのため、すべてのユーザーが Jira サービスを使えなくなる時間を短縮するためにできることの 1 つとして、インスタンスのサイズを分割して縮小することがあります。これにより、8 時間のアップグレード ダウンタイムを分割し、4 つのシステムに対して 2 時間のダウンタイムに調節することで、それぞれのダウンタイムがユーザーに与える影響を減らすことができます。 

フェデレーションの例として、アトラシアンがさまざまな目的でどのように専用インスタンスを配備しているかを紹介します。

名前目的専用インスタンスで実行する主な理由アプリケーションリンクの例

JAC

新機能要件、変更リクエストやバグを含む、一般向け課題管理インスタンス。ここでの最適な機能は、顧客が課題に投票できる機能です。パブリック / パブリックJAC 課題を JDOG に関する開発の課題とリンクさせる。
SAC外部のサポート インスタンス。課題には機密情報が含まれる場合があるため、課題は報告者 (サポート申請者) とアトラシアンの従業員のみが参照できます。外部顧客要件、パブリック/プライベートLinking between サポートの顧客に表示される) および JDOG (アトラシアンにのみ表示される) をリンクさせる。
JDOGJira チームの試験運用サーバー - 最先端の機能に関するイメージを検証します (Jira は当社の製品ですが、あなたが着想するため、これは非常に特異なケースです)。新機能へのアクセスJAC と SAC をそれぞれバックリンクさせる
HelloJマーケティングから調達および社内 IT に至るビジネス プロセスを実行する社内 Jira。パブリック / パブリック


複数の Jira インスタンスの管理における推奨事項

Jira インスタンスのフェデレーションは、企業顧客の間では非常に一般的です。アトラシアンが過去に行った調査では、数百もの顧客が組織内で 3 台以上の Jira サーバーを運用していました。その結果、フェデレーテッド環境を持つ顧客は珍しいものではなく、大きなコミュニティの一部となります。そのため、アトラシアンでは、フェデレーテッド Jira インタンスの管理や相互運用性を顧客が簡単に行えるようにする機能を開発し、継続的に実装しています。

フェデレーション機能

The ability to have Atlassian products work together is one of the strongest features of Jira, Confluence, and the entire Atlassian stack. One of the best examples of this is the possibility to dynamically list Jira issues within a Confluence page. This same functionality also enables the integration of autonomous Jira instances. The Jira instances, thereby, do not need to run the exact same version as long as all versions contain the Application Links functionality. This makes interoperability in a heterogeneous landscape (e.g. see reasons to federate, "Access to new features") a lot easier.

一言でいえば、アプリケーションリンクの目標は、インスタンス間のリンクと課題の統合を、同一インスタンス内のプロジェクト間の統合のように簡単にすることです。そのため、Jira インスタンス間のアプリケーションリンクがセットアップされた後、以下の統合機能が利用できるようになります。

統合されたアクティビティ ストリーム

アクティビティ ストリームには、作業中のインスタンスだけでなく、接続されている Jira やその他のアトラシアン製品インスタンス (例: Confluence や FishEye) からの更新も表示されます。たとえば、2 つの会社が 1 つのプロジェクトに携わっており、自分たちの Jira インスタンスをリンクさせることで、統合されたアクティビティ ストリームを通じ、パートナーの Jiraでの作業の新しいステータス変更を適用して更新することができます。

統合レポート ダッシュボード

Gadgets that draw their data from another linked and trusted Jira instance can be added to a Jira dashboard. This enables a unified reporting overview of all relevant instances. Next to the standard gadgets, you can also add additional gadgets. The applications are endless – from just one gadget that reports on a specific metrics of another project in another instance, to having one central instance in your federation that runs reporting of all projects in all Jira systems! 

Linking issues is crucial to connecting relevant Jira issues. With remote links, you can not only track dependencies and other relations of issues to other local projects, but to remote projects in other instances as well. 

アプリケーションナビゲーター

アトラシアン製品のアドレスを覚える必要はなくなりました。アプリケーション ナビゲーター ヘッダーを使用することで、Jira インスタンスや、連携しているその他のアトラシアン製品をすばやく切り替えることができます。 

Jira の課題のコピー (Atlassian ラボ、サポート対象外)

アトラシアン ラボ は、Jira インスタンスから別のインスタンスへ課題をコピーできる Jira から Jira への課題コピーを開発してきました。現在まだアトラシアン ラボ内にあり、Atlassian Marketplace で利用できます。ユーザー インターフェイスの理解をより明確かつ容易にし、ユーザー照合アルゴリズムにおけるより多くのカスタム構成や機能強化をサポートしています。このアドオンはアトラシアンではサポートされていません。また、現在のところ、機能しているように思われるかもしれませんが、アトラシアン ラボのステータスとなっているため、依存対象となるプロセスへの組み込みはお勧めしません。

フェデレーテッド検索

複数インスタンスにわたる検索は Jira インストールへの組み込み機能には含まれていませんが、ALM の Jira Client で実現することができます。このアプリは、Jira でのオフライン作業を実現するために設計されたデスクトップ アプリケーションです。これを使用することで無制限の Jira インスタンスへの接続を有効化し、接続の確立後は検索クエリをさまざまなシステムにわたって自動的に実行できます。

フェデレーテッド インスタンスの管理

次のセクションでは、フェデレーテッド Jira インスタンスを効率的に管理するために使用できる Jira 機能について説明します。

集中ユーザー管理

Jira は、単一ソースのユーザー管理、グループ定義、および認証 (SSO) を行う複数の方法を提供しており、複数の Jira インスタンスや他のアトラシアン製品で以下からデータを取得することができます。

    • Crowd: Atlassian's dedicated product to provide centralized identity management with single sign-on for an organization's applications and developer tools. See the chapter on Connecting to Crowd for User Management for more instructions. In case you want to migrate user directories from Jira to Crowd, see Importing Users from Jira to Crowd.
    • LDAP: 分散ディレクトリ情報の保存や管理についての事実上の標準です。LDAP ディレクトリへの接続方法の詳細についての Jira ドキュメントを参照してください。

For an overview of different scenarios on how multiple Jira systems and/or other Atlassian products could interoperate and accomplish centralized user management, see illustrated Diagrams of Possible Configurations for User Management

権限スキームの調整

また、ユーザー グループに対する単一のソースを持つことができることため、複数のシステム全体での権限の調整が容易になります。プロジェクト管理者、システム管理者、社外および社外などのグループを一元化してから、Jira のローカル権限に割り当てることができます。

ワークフロー共有

ワークフロー共有機能は、チームのワークフローを異なる Jira インスタンスを使用している組織内の他のチームと共有する場合や、Atlassian Marketplace を介して他組織の外部関係者と共有する場合に有用な機能です。この機能を使用することで、他の人が公開したワークフローを簡単に使用したり、組織でワークフローをステージング環境から本番環境に移動したりすることができます。また、古い Jira リリースではアプリとして提供されます。

移行、マージおよび分割 

フェデレーテッド環境では、Jira の複数のインスタンスで複数のプロジェクトが実行します。特定の状況では、関与するインスタンスの数を置き換えたり、プロジェクトをそれらの間で動かすことで、フェデレーションの状況を変更することが望ましい場合があります。これは、インスタンスのマージや分割、およびプロジェクト移行を通じて実現できます。  

(warning) Test first! For all the procedures below, we highly recommend performing this procedure on a staging environment first before production systems are touched.

    • プロジェクトを別のインスタンスに移行する - CSV インポート: 1 つのプロジェクトのみを移行する場合、CSV インポーターを使用することをおすすめします。
      1. ターゲット インスタンスでプロジェクトを作成する。 
      2. ソース プロジェクトの課題を CSV 形式でエクスポートする。 
      3. Import it into the target system using the CSV importer and use the wizard to match meta-data to the target instance configuration.

(warning) CSV インポートは課題データ自体の移行のみを行うことにご注意ください。アクティブなオブジェクトに保存されているアプリ データは移行されません。

For more information, please see Importing Data from CSV.

    • 統合 / 移行 - プロジェクトのインポート: 1 つのプロジェクトを移行する方法の 1 つとして、ソース システムでエクスポート機能を使用してから、ターゲットの Jira インスタンスでプロジェクト インポートを使用する方法があります。 
      1. 2 つのインスタンスが Jira およびアプリの同じバージョンを実行していることを確認します。 
      2. また、ソース システム内のプロジェクトに関連するカスタム フィールド、ユーザー グループ、エンティティ (優先順位やステータスなど)、およびスキームが、同じ命名法で、ターゲット システム内に存在することも確認する。
      3. ソース システムからのフルまたは部分 XML エクスポートを実行する。
      4. ターゲット システムに XML ファイルをインポートする。 

See Restoring a Project from Backup

    • インスタンスの分割 - XML バックアップの復元: 復元機能を使用すると、バックアップ / 復元手順を通じて Jira インスタンスの複製を作成できます。 
      1. Set up a new Jira Data Center with the same version of the existing system. (info) This will require a Data Center license. 
      2. ソース システムのフル バックアップを実行します。 
      3. バックアップ ファイルを新しい Jira インスタンスにインポートします。
      4. ソース インスタンスとターゲット インスタンスから削除する重複プロジェクトを選択します。
      5. このオプションは、ターゲット インスタンスがの場合にのみ適用されます。 

詳しい説明については、「Jira アプリケーションの分割」を参照してください。 

(info)同じサーバーで複数の Jira インスタンスを実行することは可能ですが、Jira のエンタープライズ使用には専用ハードウェア / VM をお勧めします。

    • インスタンスの分割 - DB / ファイルシステム レベル: 一部のアプリは、標準 XML エクスポートを通じてエクスポートできない方法で Jira データベースを使用する場合があります。
      • Set up another Jira instance and replicate the application server, database and installation / home directories. For detailed instructions, see staging environment
      • ここに記載されている手順は基本的に、上記の「インスタンスの分割 - フル XML バックアップの復元」と同じですが、今回はネイティブのデータベース バックアップ ツールを使用します。

構成管理

Jira インスタンスのフェデレーテッド システムが増えると、これらのシステムを一元管理する必要性も高まります。お客様はさまざまな方法を実施することで構成管理を実現しています。

    • Version Control System: A VCS like Subversion or GIT can be used to keep track of changes to files such as configuration XMLs or templates and can then be deployed to a staging environment or production system respectively. This approach provides the ability to roll-back changes and having one central overview of all configuration files in all instances.
    • 構成管理ツール: 当社のお客様の多くは、IT システム、バージョンなどをトラッキングするため、構成管理ソフトウェアを使用しています。たとえば、Puppetpuppet-Jira アプリ の組み合わせなどがあります。 
    • Continuous Deployment: CI applications like Bamboo can be used to automatically or manually deploy configuration changes to a Jira's staging environment/ production system.
    • アトラシアン ラボの Jira ワークフロー共有プラグイン (サポート対象外)。上記の「マージ/分割」セクションでも説明しています。ワークフローの維持や構成を一元的に行い、複数の Jira システム全体で共有するために使用できます。

The Jira Auditor app maintains an audit log on configuration changes in Jira. This is especially important when multiple administrators make changes to the same instance. Alternatively, Jira Data Center 8.8 + offers Advanced audit log to track all the events on your Jira instance.

分散環境におけるアジャイル ボード

分散環境で作業する必要がある場合、WatchTower for Jira を使用すると、リモートの Cloud または Server の Jira インスタンスから単一のアジャイル ボードに課題を統合することができます。WatchTower では、Jira のアジャイル ボードでリモート インスタンスの課題に取り組むための単一の管理ポイントが提供されます。WatchTower では、複数の環境にわたる複数のプロジェクトで、コンテキストの切り替えや全体像の把握にかかる時間を節約できます。 

インスタンスを越えたプロジェクトの同期化

一部のシナリオでは、Jira システムが連携され、類似したエンティティを処理している場合、1 つのシステムでの操作がもう片方のシステムに影響を与えるようにするのが望ましい場合があります。これは機能としては提供していませんが、アプリとスクリプトを使用することで実現できます。

    • Backbone Issue Sync for Jira - サポート元: K15t Software GmbH
      Backbone Issue Sync for Jira は、異なる Jira インスタンス間で課題データを同期します。柔軟かつ確実な方法で、部署や B2B の境界を超えてで Jira プロジェクト データを簡単に同期できます。 
    • JJUPIN - Kepler-Rominfo によってサポートされる Jira 用の SIL (Simple Issue Language)。
      JJUPIN アプリは管理者が新しい機能を作成できるよう、Jira に新しいスクリプティング レイヤーを提供します。フェデレート Jira 環境での同期およびシステム横断型ワークフローのソリューションとしてマーケットプレイスで紹介されています。 
    • Jira Enterprise Mail Handler (サポート元: Javahollic Software)
      Jira Enterprise Mail Handler は、本来、受信メールを処理する高度な機能を提供するように設計されたアプリです。これには、Jira アカウントを持たないユーザーや、複数のメール エイリアスを使用するユーザーとのやり取りが含まれます。プロジェクトやフィールド マッピングを通じて、異なるインスタンス間で課題を同期および更新するために使用することもできます。たとえば、課題がインスタンス B で特定の状ステータスにトランジションする場合にインスタンス A で課題を自動作成することができます。ただし、このような自動化をセットアップする場合、両方のインスタンスで同時に課題が更新されると無限ループが発生する可能性があるため、丁寧なテストを行う必要があります。
    • ScriptRunner (サポート元: Adaptavist)
      多くのお客様が Jira のスクリプト機能を増強するために ScriptRunner を使用しています。このアプリは、Groovy、Python (jython)、Ruby (JRuby) および JavaScript などの言語での入力に対応しています。 

複数のインスタンスのアップグレード

Jira 管理マニュアルに記載されているアップグレード手順を手動で繰り返し実行する代わりに、プロセスの一部または全部を自動化する方法を利用できます。

    • 自動バックアップ: Jira コマンドライン インターフェイスを使用して Jira からデータをエクスポートできます (ira CLI は、自動化テストにも非常に便利です)。
    • Symlinks: システム管理者はインストール ディレクトリのみを操作する代わりに、各 Jira バージョン用にディレクトリを管理できます。新しいバージョンがインストールおよび変更されると、リンク記号が変更され、新しいバージョンのフォルダーをポイントするようになります。これは、アトラシアン社内で実績のある方法です。 

高可用性要件のある Jira インスタンスでは、Jira にステージング サーバー セットアップを使用することをお勧めします。ステージング サーバーに別途ライセンスは必要ありません。 

(info)アプリケーション リンクで説明したように、Jira インスタンスが同じバージョンを実行していなくてもアプリケーション リンクを有効化できます。 

複数のインスタンスの HA / フェイルオーバーの計画

Federating Jira instances on one Jira Data Center will enable you to set different availability requirements for your instances. You can certainly leverage the same tools for many instances such as the load balancer (given it runs in HA mode as well) for multiple Jira instances. 

詳細については、「Jira のフェイルオーバー ガイド」を参照してください。

その他のリソース

アトラシアンでは、御社に適したソリューションを選択および実装できるように設計された幅広いサービスとプログラムをご用意しています。Data Center ライセンスに含まれるサービスや有料サービスの詳細については、「エンタープライズ サービス」ページをご覧ください。

最終更新日: 2020 年 10 月 17 日

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

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