Atlassian Cloud
Atlassian Cloud アーキテクチャと運用プラクティス
Atlassian Cloud アーキテクチャとアトラシアンが利用している運用プラクティスの詳細
概要
アトラシアンのクラウド製品とデータは、業界をリードするクラウド プロバイダーである Amazon Web Services (AWS) でホストされています。アトラシアン製品はサービスとしてのプラットフォーム (PaaS) 環境で動作します。この環境は Micros と non-Micros という 2 つの主要なインフラストラクチャに分けられます。Jira、Confluence、Jira Product Discovery、Statuspage、Access、Bitbucket は Micros プラットフォームで、Opsgenie と Trello は non-Micros プラットフォームで動作します。
分散型サービス アーキテクチャ
この AWS アーキテクチャによって、アトラシアンのソリューション全体で使用される多数のプラットフォームや製品サービスがホストされています。これには、メディア、アイデンティティ、コマース、エディターなどのエクスペリエンスなど、複数のアトラシアン製品全体で共有されて利用されるプラットフォーム機能のほか、Jira 課題サービスや Confluence アナリティクスなどの製品固有の機能が含まれます。
図 1
アトラシアンの開発者は、Micros と呼ばれる社内で開発した PaaS (サービスとしてのプラットフォーム) を通じて、これらのサービスをプロビジョニングします。これによって、共有サービス、インフラストラクチャ、データ ストア、セキュリティとコンプライアンス管理の要件を含む管理機能のデプロイが自動で調整されます (上の図 1 参照)。通常、アトラシアン製品は、Micros によって AWS にデプロイされる複数の「コンテナー化」されたサービスで構成されています。アトラシアン製品では、リクエストのルーティングからバイナリ オブジェクト ストア、認証/承認、トランザクションの UGC (ユーザー生成コンテンツ) やエンティティ関係ストア、データ レイク、共通ロギング、リクエスト追跡、監視性、分析サービスに至るまで、コア プラットフォーム機能を使用されています (下の図 2 参照)。これらのマイクロサービスは、次のプラットフォーム レベルで標準化された承認済みの技術スタックによって構築されています。
図 2
マルチテナント アーキテクチャ
クラウド インフラストラクチャに加えて、アトラシアンは製品をサポートする共有プラットフォームを備えたマルチテナント マイクロサービス アーキテクチャを構築して運用しています。マルチテナント アーキテクチャでは、クラウド製品の運用に必要なデータベースやコンピューティング インスタンスなど、単一のサービスを複数のお客様に提供します。各シャード (基本的にはコンテナー、下の図 3 参照) には複数のテナントのデータが含まれますが、各テナントのデータは分離されていて他のテナントからアクセスできません。アトラシアンではシングル テナント アーキテクチャを提供しておりませんので、ご注意ください。
図 3
アトラシアンのマイクロサービスは最小権限を念頭に構築されています。ゼロデイ エクスプロイトの範囲を最小限に抑えて、クラウド環境内のラテラル ムーブメント (侵入拡大) の可能性を低減するように設計されています。それぞれのマイクロサービスには独自のデータ ストレージがあり、その特定のサービスの認証プロトコルによってのみアクセスできます。つまり、他のサービスには、その API に対する読み取りまたは書き込みアクセス権はありません。
アトラシアンはテナントごとに専用のインフラストラクチャを提供するのではなく、マイクロサービスとデータの分離に注力しています。これによって、多くのお客様が利用するデータであっても、1 つのシステムでアクセスする範囲は限定されます。ロジックが切り離されてデータ認証と承認はアプリケーション レイヤーで行われるため、リクエストがこれらのサービスに送信されると、このデータ認証と承認が追加のセキュリティ チェックとして機能します。したがって、マイクロサービスがセキュリティ侵害を受けても、特定のサービスが必要とするデータに対するアクセスのみに制限されることになります。
テナントのプロビジョニングとライフサイクル
When a new customer is provisioned, a series of events trigger the orchestration of distributed services and provisioning of data stores. These events can be generally mapped to one of seven steps in the lifecycle:
1. コマース システムでは当該のお客様に関する最新のメタデータとアクセス制御情報がすぐに更新されて、その後プロビジョニング連携システムで一連のテナントと製品イベントを通じて「プロビジョニングされたリソースの状態」がライセンスの状態と統一されます。
テナント イベント
テナント全体に影響を与えるイベントで、次のいずれかに当てはまります。
- 作成: テナントが作成され、新しいサイトに使用される
- 破棄: テナント全体が削除される
製品イベント
- アクティブ化: ライセンス製品またはサードパーティ アプリのアクティブ化の後
- 非アクティブ化: 特定の製品またはアプリの非アクティブ化後
- 一時停止: 特定の既存製品の一時停止後、所有する特定のサイトへのアクセスを無効にする
- 一時停止解除: 特定の既存製品の一時停止の解除後、所有するサイトへのアクセスを可能にする
- ライセンスの更新: 特定の製品のライセンスのユーザー数およびそのステータス (アクティブ/非アクティブ) に関する情報を含む
2. お客様のサイトを作成して、そのお客様に適した製品セットをアクティブ化します。サイトのコンセプトは、特定のお客様にライセンスされた複数の製品のコンテナーです (例: ＜site-name＞.atlassian.net の Confluence と Jira Software)。
図 4
3. Provisioning of products within the customer site in the designated region.
When a product is provisioned it will have the majority of its content hosted close to where users are accessing it. To optimize product performance, we don't limit data movement when it's hosted globally and we may move data between regions as needed.
For some of our products, we also offer data residency. Data residency allows customers to choose whether product data is globally distributed or held in place in one of our defined geographic locations.
4. お客様のサイトと、製品のコア メタデータと構成を作成して保存します。
5. ユーザー、グループ、権限など、サイトと製品の ID データを作成して保存します。
6. サイト内の製品データベース (例: Jira 製品ファミリー、Confluence、Compass、Atlas) をプロビジョニングします。
7. 製品ライセンス アプリをプロビジョニングします。
図 5
上の図 5 では、お客様のサイトが単一のデータベースやストアだけでなく、分散型アーキテクチャ全体でどのように展開されているかを示しています。これには複数の物理/論理的な場所が含まれており、メタ、構成、製品、プラットフォームの各データ、その他の関連サイト情報が格納されています。