【ITニュース解説】Atlassian Cloud Architecture: Organization, Site, Product, and What a Migration Crosses

Atlassian Cloudのアーキテクチャと移行の仕組みを理解することは、システムエンジニアを目指す皆さんにとって、クラウド環境の管理やデータ移行の基本を学ぶ上で非常に重要だ。Atlassian Cloudは、トップに「組織（Organization）」があり、その下に一つまたは複数の「サイト（Site）」が存在する階層構造を持っている。それぞれのサイトには、Jira SoftwareやConfluenceといった「製品（Product）」のインスタンスが一つずつ配置される。そして、「ディレクトリ（Directory）」という要素が、誰がこれらのシステムにアクセスできるかを決定する役割を担っている。普段は意識しなくてもシステムは動くが、例えばデータ移行のような大きな変更を行う際には、この構造を正確に理解していなければ、予期せぬ問題に直面する可能性がある。

最も上位の「組織」は、すべてのサイト、製品、ユーザーレコードを一つにまとめるコンテナのようなものだ。組織は複数のサイトを持つことができ、組織管理者（Organization Admin）という役割を持つ人は、その組織に属するすべてのサイトで自動的にサイト管理者（Site Admin）の権限を持つことになる。この権限は非常に強力で、取り除くことはできない。一方、サイト管理者やアプリ管理者（App Admin）は、組織レベルのセキュリティ設定やユーザー管理を行うことはできない。サイト管理者は担当サイトの範囲でのみ作業ができ、アプリ管理者は特定のアプリケーションの設定のみを担当する。例えば、シングルサインオン（SSO）の設定や組織全体のユーザーアクセス設定は、組織管理者でなければ変更できない重要な項目だ。この権限の違いを理解しないまま移行作業を進めると、必要な設定ができないといったトラブルが発生することがあるため、誰がどの役割を持っているのかを事前に確認することが非常に重要となる。特に、CloudからCloudへの移行では、組織管理者とアプリ管理者の両方の権限を、一人の人物が持っている必要がある場合があるため、注意が必要だ。

ユーザーの認証と認可を司る「ディレクトリ」には、「ローカルディレクトリ」と「IDプロバイダーディレクトリ」の二種類がある。ローカルディレクトリは、Atlassian Cloud内で直接作成されたユーザーアカウントを管理する。対して、IDプロバイダーディレクトリは、外部のIDプロバイダー（例えばOktaやAzure ADなど）と連携してユーザーを管理する。シングルサインオン（SSO）を強制できるのは、このIDプロバイダーディレクトリだけだ。組織レベルでのアカウント停止や削除といった操作は、Atlassian Admin APIを通じて行われるが、その際にも「ディレクトリ」の概念が深く関わってくる。つまり、ユーザー管理の中心にあるのがディレクトリであり、どのディレクトリにユーザーが所属するかによって、適用されるセキュリティポリシーや管理方法が異なることを理解しておく必要がある。

次に、具体的なデータ移行の種類について解説する。Atlassian Cloudへの移行は大きく分けて二つのパターンがある。一つは「Data Center to Cloud移行」、もう一つは「Cloud to Cloud移行」だ。

「Data Center to Cloud移行」では、オンプレミス環境やプライベートクラウドで運用しているData Center製品のデータを、Atlassian Cloudへ移す。この移行には主に「Jira Cloud Migration Assistant (JCMA)」というツールを使用する。このタイプの移行では、移行先のCloud環境に既存の組織やサイト、ディレクトリがない、または関係性が構築されていない状態からスタートするため、これらすべてを新たに構築するようなイメージだ。最も重要な点の一つは、移行されるすべてのエンティティ（例えば、Jiraの課題やプロジェクト、コメントなど）のIDが、Cloud環境で新しく採番されることだ。つまり、Data Centerで使っていた数字IDはCloudでは保持されない。このため、移行後に古いIDを参照しているレポートや外部連携などが正しく機能しなくなる可能性がある。Atlassianは、この問題を解決するために、移行後に旧IDと新IDのマッピング情報を提供するベータ版のAPIを提供しているが、これはあくまで移行後の調整目的であり、恒久的な連携には適さないとされている。ユーザーアカウントも新たに作成されるため、Data Centerのユーザー名とCloudのアカウントを適切に紐付ける作業が必要となる。組織の構成やSSO設定など、組織レベルの作業が必要になるため、早期に組織管理者が関与する必要がある。

もう一つの「Cloud to Cloud移行」は、すでにCloud環境にあるAtlassian製品のデータを、別のCloud環境へ移動するケースだ。例えば、企業買収や組織再編などで、複数のAtlassian Cloudテナントを統合する際などに用いられる。この移行ではJCMAは使用せず、「Copy product data」というツール（管理コンソールでは「データ転送」と表示されることが多い）を用いる。Data Center to Cloud移行とは異なり、Cloud to Cloud移行ではIDが再採番されることはない。Cloudユーザーのアカウントはグローバルに一意であるため、移行先のサイトには新しいアカウントは作成されず、既存のAtlassianアカウントにデータがリンクされる形となる。そのため、IDのマッピングに関する複雑な問題は発生しない。この移行では、移行元の製品に対して組織管理者とアプリ管理者の両方の権限を持つ人物が必要となる。

両方の移行タイプに共通する、いくつかの重要な注意点がある。特に「グローバル権限」と「マーケットプレイスアプリのデータ」は、どちらの移行タイプでもツールによって直接移行されないと明記されている。グローバル権限は手動で再設定する必要があり、マーケットプレイスアプリのデータについては、各アプリのベンダーに直接問い合わせて移行方法を確認する必要がある。また、Cloud to Cloud移行においては「オートメーションフロー」も移行されない項目として挙げられており、手動での再構築が必要となる。これらの「移行されないデータ」を事前に把握し、移行計画に組み込んでおくことが、スムーズな移行を実現するために不可欠だ。

まとめると、Atlassian Cloudの組織、サイト、製品、ディレクトリという基本的なアーキテクチャを理解し、それぞれの管理ロールが持つ権限範囲を把握すること、そしてData Center to Cloud移行とCloud to Cloud移行の違い（特にIDの再生成の有無、必要な管理者ロール、移行されないデータ）を正確に認識することが、システムエンジニアとしてAtlassian製品の移行プロジェクトを成功させるための第一歩となる。移行作業を始める前に、まず移行先の環境の全体像を正確に把握し、どの境界線を越える移行なのかを明確にすることが、あらゆる失敗を避けるための最も重要な準備だと言えるだろう。