アトラシアンによる顧客データの管理


アトラシアンが提供する回復性

アトラシアンのクラウド製品は、高いパフォーマンスを発揮するよう設計され、最高水準のテクノロジーを用いて構築されているため、お客様はいつでも必要なときにデータとサービスを使用できます。アトラシアンは顧客データとサービスの回復性を重視しています。私たち自身も、お客様と同じ製品スイートを使用しているのです。

いつでもデータとサービスを提供するという目標を見据え、障害発生時にはお客様への影響を最小限に抑えるよう努めています。地理的に分散した複数のデータセンターを活用し、包括的なバックアッププログラムを使用して、定期的にディザスタリカバリとビジネス継続性計画をテストすることで、確実性を高めています。

このページでは、顧客データ管理のライフサイクル全体を管理する方法の概要を説明します。これには、Amazon Web Services (AWS) のネイティブ機能を利用したバックアップによるサービス可用性の確保、ディザスタリカバリ計画を定期的にテストする方法、ディザスタリカバリとビジネス継続性計画の継続的改善へのアプローチなどが含まれます。

バックアップの管理

はじめに: インフラストラクチャとデータベース

アトラシアンの製品が動作する場所は、大きく 2 つの主要なインフラストラクチャに分けられます。社内では Micros と呼ばれている PaaS (サービスとしてのプラットフォーム) 環境と、Non-Micros です。Micros プラットフォームで動作する製品には、Jira、Confluence、Statuspage、Atlassian Access が含まれます。Non-Micros 環境で動作する製品には、Bitbucket、Opsgenie、Trello が含まれます。ここでは、簡潔にお伝えするため、アトラシアンを代表する製品である Jira、Confluence、Bitbucket に焦点を当てます。

Jira と Confluence Cloud は、AWS の IaaS (サービスとしてのインフラストラクチャ) を使用して、複数の AWS リージョンでホストされています (具体的には、米国東部、米国西部、アイルランド、フランクフルト、シンガポール、シドニーです。必要に応じて他のリージョンに拡張する計画もあります)。Jira と Confluence Cloud はどちらも、製品のインスタンスごとに、論理的に独立したリレーショナルデータベースを使用しています。一方、Jira または Confluence Cloud に保管された添付ファイルは、アトラシアンのドキュメントストレージプラットフォーム (Media Platform) に格納され、最終的に Amazon S3 に保管されます。

Bitbucket Cloud のサービスと機能は、バージニア州アッシュバーンに位置する NTT コミュニケーションズ (NTT) のデータセンターで実行される一連のサービスによって提供されます。バックアップは、カリフォルニア州サンタクララにある NTT のデータセンターと AWS の両方に保管されます。Bitbucket Cloud の顧客データは PostgreSQL と NetApp ファイラーに格納されています。

バックアップ

お客様の業種が何であれデータは作成され、データなしではビジネスは存在しないとアトラシアンは認識しています。顧客をないがしろにしないという価値観のもと、データを損失から保護し、広範囲にわたるバックアッププログラムを提供します。

Jira と Confluence Cloud に関して、アトラシアンは Amazon RDS (Amazon Relational Database Service) のスナップショット機能を活用し、RDS インスタンスごとの自動バックアップを毎日作成しています。Amazon RDS スナップショットは、ポイントインタイムリカバリ (特定時点への復元) をサポートできるよう 30 日間保持され、AES-256 暗号化を使用して暗号化されます。

Bitbucket のバックアップは物理的な NTT データセンターと AWS の両方に格納されます。

アトラシアンは四半期ごとにバックアップの復元性をテストしています。これらのテストにより発見された課題は Jira チケットとして登録され、修正されるまで追跡されます。

詳細については、当社のデータストレージに関する FAQ をご覧ください。

複数のデータセンターとアベイラビリティーゾーンを活用して高可用性を実現

ハリケーン、地震、津波は身近で起きているわけではありませんが、リスクがゼロとは言い切れません。データを地理的に異なる場所にバックアップ (および複製) し、何が起きても復元できるようにすることが不可欠です。

アトラシアンは、世界中の複数のリージョンにおいて可用性の高い AWS のデータセンター施設を利用することで、これを実現しています。AWS のリージョンはそれぞれ地理的に異なるロケーションに存在し、アベイラビリティーゾーン (AZ) と呼ばれる複数の独立したロケーションを保有しています。たとえば、米国西部 (米国の西海岸) というリージョンには、us-west-1a (北カリフォルニア) と us-west-1b (オレゴン) という 2 つの AZ があります。どちらも同じリージョンに属していますが、地理的には隔離されています。

各 AZ は、他の AZ の障害から隔離され、同リージョン内の他の AZ に低コストで低遅延のネットワーク接続を提供できるよう設計されています。このマルチゾーンの高可用性は防御の第一線であり、AZ の障害があっても、マルチ AZ デプロイ環境で実行されるサービスは影響を受けません。

Jira と Confluence は、Amazon RDS のマルチ AZ デプロイモードを利用しています。マルチ AZ デプロイでは、Amazon RDS は同じリージョンの異なる AZ において同期スタンバイレプリカをプロビジョニングして維持し、冗長性とフェイルオーバー機能を提供します。AZ フェイルオーバーは自動化され、通常は 60 〜 120 秒で実施されます。そのため、管理者による介入なしに、データベースオペレーションを可能な限り迅速に再開できます。これらのリージョン、AZ、レプリケーションの概念は、以下の図で説明されています。Opsgenie、Statuspage、Trello、Jira Align も、レプリカとフェイルオーバーそれぞれのタイミングにわずかな差異はあるものの、同様のデプロイ戦略を使用しています。

Bitbucket の場合、すべてのプライマリデータベースサーバーは NTT データセンターに存在しています。レプリケーションノードとバックアップは、NTT データセンターと AWS の両方に格納されています。本番データは、バージニア州アッシュバーンの NTT データセンターとカリフォルニア州サンタクララの NTT データセンターの両方で、ミラーリング技術を用いて常にレプリケートされます。Bitbucket の本番データは、プライマリサイトからセカンダリサイトへ、2 時間ごとにレプリケートされます。レプリケーションの遅延は平均 10 〜 20 分で、最大でも 4 時間以内です。

復旧時間と RPO (目標復旧時点) の決定

重要なビジネスデータは決して失われないことが理想です。しかし実際には、データ損失のリスクがゼロのシステムは実現不可能または非常に高価です。しかし実際には、データ損失のリスクがゼロのシステムは実現不可能または非常に高価です。アトラシアンでは、データ損失ゼロシナリオと、アベイラビリティーゾーンの障害を乗り越えるという目標の達成に努める考え方をとっています。一方、ビジネス継続性計画においては、コスト、メリット、リスクの適切なバランスを見つけ、「RTO (目標復旧時間)」と「RPO (目標復旧時点)」を設定することが重要です。

RTO とは、インシデントの後、ビジネスプロセス (またはシステム) が復旧し、バックアップされ、動作するようになるまでの時間を意味します。RPO とは、復旧操作において、失われても組織が許容できる範囲のデータ量を意味します。簡単な例を挙げると、バックアップを毎日取っている場合、その日の終わりにインシデントがあると、前日に取ったバックアップからデータを復旧させることになり、1 日分のデータが失われます。これが RPO です。

アトラシアンではビジネスに与える影響とリスクの評価を行い、チームがクライアントユーザー要件や中断による潜在的な影響に基づいてカスタム RTO と RPO の目標設定を行う際に役立てています。

具体的には、サービスを階層と呼ばれる分かりやすいバケットに分けます。製品、顧客向けサービス、アトラシアンのビジネスシステム、内部ツールには、3 つの階層が定義されています (Tier 1、2、3)。それらの基盤となる階層 (Tier 0) は、すべてが依存する重要なコンポーネントに対して、さらに高い可用性基準を規定しています。

For each tier, we’ve defined mandatory targets by reviewing, amongst other things, business impact assessments and typical usage scenarios for the services we build. Our service tiers help determine availability, reliability, RTO and RPO targets as set out in the table below.

         
  Tier 0 Tier 1 Tier 2 Tier 3
重要なインフラストラクチャとサービスコンポーネント Tier 0 サービスは他のすべてのサービスの基本であり、製品を提供するために重要なものです。 Tier 1 サービスは一般的にアトラシアンの製品、または製品の提供に直接関係するものです。 Tier 2 サービスは、緊急度が低いか社内向けのものです。 Tier 3 サービスは、緊急度が低いか社内向けのものです。
サービスの例:

サービスの例

· AWS プラットフォーム

· Micros サーバー

· コアネットワーク

サービスの例

· Jira および Confluence Cloud

· Bitbucket

サービスの例

· 画像のエフェクト

· CAC

サービスの例

· 分析、BI データの受信

RPO* 1 時間未満 1 時間未満 8 時間未満 24 時間未満
RTO** 4 時間未満 6 時間未満 24 時間未満 72 時間未満

*RPO – 目標復旧時点 – 障害時に損失したデータ

**RTO – 目標復旧時間 – 障害時におけるサービスの復元

アトラシアンでは、関連のサービスが RPO および RTO 目標を確実に達成するために、サービスオーナーに責任を割り当てています。

 

ディザスタリカバリのテスト

アトラシアンはディザスタリカバリ (DR) プログラムの一環として、定期的にディザスタリカバリのテストを実施し、継続的な改善に努めています。これは、お客様のデータとサービスが、信頼性と回復性を保持していることを確認する目的で行われます。スケジュールされたテストの他に臨時テストも実施し、これらには次の要素が含まれています。

ドキュメント - 重要なサービスと顧客向けサービス (Tier 0 と Tier 1 など) に関しては、四半期ごとにバックアップドキュメントのレビューを行い、正確性と完全性/通用性を確認します。特定された問題はすべて文書化され、社内で Jira チケットとして登録され、修正されるまで追跡されます。

プロセス - 重要なサービスと顧客向けサービス (Tier 0 と Tier 1 など) に対して、四半期ごとに実際の技術的なバックアップ/リカバリプロセスのテストを実施し、RTO 目標と RPO 目標がサービス階層の分類に基づいて達成されているか判断します。テストによって特定された問題は Jira チケットとして登録され、修正されるまで追跡されます。

回復性とフェイルオーバー – AZ 全体にわたる回復性レベルの定期的なテストと臨時テストを実施し、アトラシアンが最小限のダウンタイムで AZ 障害を処理できるか確認します。リージョン全体に障害が発生するとは考えにくいですが、リージョンのフェイルオーバーも定期的にテストし、リージョンの回復性を継続的に改善しています。

システム - Site Reliability Engineering (SRE) チームと製品エンジニアリングチームは、サービス全体でさまざまな指標を継続的に監視し、ユーザーに優れた操作性を提供できるよう努めています。サービス指標の特定のしきい値を超える事態があった場合は、SRE チームのメンバーに自動アラートが通知されるように設定されています。そのため、インシデント対応プロセスで即時にアクションを取れます。

ディザスタリカバリダッシュボード - DR ダッシュボードが社内で維持されています。重要なサービスと顧客向けサービス (Tier 0 と Tier 1 など) の監視、メンテナンス、テストに関する Jira チケットが一元的に追跡され、ドキュメントの確認とバックアップ/リカバリプロセスが時間どおりに完了するようになっています。

DR テストとシミュレーション – DR テストを年次ベースと臨時ベースで実施しています。アトラシアンでは DR テストの一環として机上訓練を行い、DR チームが潜在的なインシデントのさまざまなシナリオを確認します。机上訓練では異なるシナリオをテストし、リカバリプロセスにおけるギャップを特定します。机上訓練のシナリオには、地震、火事、自然災害、復旧訓練、テストなどがあります。DR テストの実施後はテストのアウトプットを記録分析し、継続的な改善に向けた次のステップの範囲を決定するため議論を行います。改善の取り組みは Jira チケットに登録し、修正されるまで追跡します。

アトラシアンのテストとプロセスは技術的に厳格ですが、それらを実施する社員に関しても基準を定めています。したがって、DR プログラムには以下の人員に関する要素が含まれています。

Site Reliability Engineer (SRE) – SRE は継続的かつ定期的な DR 会議に参加し、重要なサービスを代表する立場にあります。リスクとコンプライアンスのチームと共に DR のギャップを特定し、必要に応じて修正に注力します。

ディザスタリカバリの推進者 - 各製品/サービスチーム (基盤となるサービスを含む) で DR の推進者が任命され、その製品/サービスにおける DR の実装を監督および管理し、サービス階層の要件を満たすよう努めます。

リーダーシップ - エグゼクティブとシニアマネジメントチームも DR プロセスに参加し、継続的に関与します。リーダーシップチームが加わることで、回復性戦略においてビジネスと技術両方の目標が達成されます。

広範囲にわたるビジネス継続性対策と計画

アトラシアンは、強力なビジネス継続性 (BC) と DR 機能を維持し、業務の中断が発生した場合にお客様への影響を最小限に抑えられるよう努めています。BC と DR プログラムに関する主な原則は次のとおりです。

継続的な改善 – アトラシアンは、運用効率、自動化、新技術、実証済みのプラクティスを通じて、回復性を確実に向上できるよう努めています。

テストを通じた保証 – 定期的にスケジュールされたテストと継続的な改善の適用を通して、最適な回復性を達成できるのだとアトラシアンは理解しています。

専任リソース – アトラシアンでは、顧客向け製品において BC と DR が必要となった場合に対応できる、専任の社員とチームを用意しています。社内の運営委員会、リスクの評価、ビジネスへの影響の分析テスト、実際に起きるインシデントまでサポートできるよう、適切なレベルのリソースを保持しています。

概要

アトラシアンは、最高水準の技術と継続的なテストおよび検証を組み合わせ、お客様のデータの可用性、信頼性、回復性を高度に実現します。地理的に多様な複数のデータセンターを運用し、広範囲にわたるバックアッププログラムを保持し、ディザスタリカバリとビジネス継続性計画を定期的にテストして確実性を高めています。さらに、優れた人材と専任リソースを活用し、プロセスを実行しています。