アトラシアンによる顧客データの管理
Keeping your cloud products and the underlying systems and services they use available and able to withstand the impact of negative or unplanned events is as crucial to us as it is to you. To make sure that your products are there when you need them, we’ve implemented technology, people, and programs to provide business resiliency.
アトラシアンが提供する回復性
アトラシアン製品はサービスとしてのプラットフォーム (PaaS) 環境で動作します。この環境は Micros と non-Micros という 2 つの主要なインフラストラクチャに分けられます。Jira、Confluence、Statuspage、Access、Bitbucket、および Trello は Micros プラットフォームで、Jira Align および Opsgenie は non-Micros プラットフォームで動作します。
いつでもデータとサービスを提供するという目標を見据え、障害発生時にはお客様への影響を最小限に抑えるよう努めています。地理的に分散した複数のデータセンターを活用し、包括的なバックアッププログラムを使用して、定期的にディザスタリカバリとビジネス継続性計画をテストすることで、確実性を高めています。
このページでは、顧客データ管理のライフサイクル全体を管理する方法の概要を説明します。これには、Amazon Web Services (AWS) のネイティブ機能を利用したバックアップによるサービス可用性の確保、ディザスタリカバリ計画を定期的にテストする方法、ディザスタリカバリとビジネス継続性計画の継続的改善へのアプローチなどが含まれます。
はじめに: インフラストラクチャとデータベース
アトラシアンの製品が動作する場所は、大きく 2 つの主要なインフラストラクチャに分けられます。社内では Micros と呼ばれている PaaS (サービスとしてのプラットフォーム) 環境と、non-Micros です。Micros プラットフォームで動作する製品には、Jira、Confluence、Statuspage、Bitbucket、Atlassian Access が含まれます。non-Micros 環境で動作する製品には、Opsgenie と Trello が含まれます。ここでは、簡潔にお伝えするため、アトラシアンを代表する製品である Jira、Confluence、Bitbucket に焦点を当てます。
Jira と Confluence Cloud は、AWS の IaaS (サービスとしてのインフラストラクチャ) を使用して、複数の AWS リージョンでホストされています (具体的には、米国東部、米国西部、アイルランド、フランクフルト、シンガポール、シドニーです。必要に応じて他のリージョンに拡張する計画もあります)。Jira と Confluence Cloud はどちらも、製品のインスタンスごとに、論理的に独立したリレーショナルデータベースを使用しています。一方、Jira または Confluence Cloud に保管された添付ファイルは、アトラシアンのドキュメントストレージプラットフォーム (Media Platform) に格納され、最終的に Amazon S3 に保管されます。
バックアップ
お客様の業種が何であれデータは作成され、データなしではビジネスは存在しないとアトラシアンは認識しています。顧客をないがしろにしないという価値観のもと、データを損失から保護し、広範囲にわたるバックアッププログラムを提供します。
Jira と Confluence Cloud に関して、アトラシアンは Amazon RDS (Amazon Relational Database Service) のスナップショット機能を活用し、RDS インスタンスごとの自動バックアップを毎日作成しています。Amazon RDS スナップショットは、ポイントインタイムリカバリ (特定時点への復元) をサポートできるよう 30 日間保持され、AES-256 暗号化を使用して暗号化されます。
Jira Align では、Amazon RDS スナップショットを 35 日間保持します。
Bitbucket では、データは異なる AWS リージョンにレプリケーションされ、各リージョン内で毎日独立したバックアップが作成されます。
アトラシアンは四半期ごとにバックアップの復元性をテストしています。これらのテストにより発見された課題は Jira チケットとして登録され、修正されるまで追跡されます。
詳細については、当社のデータストレージに関する FAQ をご覧ください。
バックアップ
お客様の業種が何であれデータは作成され、データなしではビジネスは存在しないとアトラシアンは認識しています。顧客をないがしろにしないという価値観のもと、データを損失から保護し、広範囲にわたるバックアッププログラムを提供します。
Jira と Confluence Cloud に関して、アトラシアンは Amazon RDS (Amazon Relational Database Service) のスナップショット機能を活用し、RDS インスタンスごとの自動バックアップを毎日作成しています。Amazon RDS スナップショットは、ポイントインタイムリカバリ (特定時点への復元) をサポートできるよう 30 日間保持され、AES-256 暗号化を使用して暗号化されます。
Jira Align では、Amazon RDS スナップショットを 35 日間保持します。
Bitbucket では、データは異なる AWS リージョンにレプリケーションされ、各リージョン内で毎日独立したバックアップが作成されます。
アトラシアンは四半期ごとにバックアップの復元性をテストしています。これらのテストにより発見された課題は Jira チケットとして登録され、修正されるまで追跡されます。
詳細については、当社のデータストレージに関する FAQ をご覧ください。
バックアップ
お客様の業種が何であれデータは作成され、データなしではビジネスは存在しないとアトラシアンは認識しています。顧客をないがしろにしないという価値観のもと、データを損失から保護し、広範囲にわたるバックアッププログラムを提供します。
Jira と Confluence Cloud に関して、アトラシアンは Amazon RDS (Amazon Relational Database Service) のスナップショット機能を活用し、RDS インスタンスごとの自動バックアップを毎日作成しています。Amazon RDS スナップショットは、ポイントインタイムリカバリ (特定時点への復元) をサポートできるよう 30 日間保持され、AES-256 暗号化を使用して暗号化されます。
Jira Align では、Amazon RDS スナップショットを 35 日間保持します。
Bitbucket では、データは異なる AWS リージョンにレプリケーションされ、各リージョン内で毎日独立したバックアップが作成されます。
アトラシアンは四半期ごとにバックアップの復元性をテストしています。これらのテストにより発見された課題は Jira チケットとして登録され、修正されるまで追跡されます。
詳細については、当社のデータストレージに関する FAQ をご覧ください。
復旧時間と RPO (目標復旧時点) の決定
重要なビジネスデータは決して失われないことが理想です。しかし実際には、データ損失のリスクがゼロのシステムは実現不可能または非常に高価です。しかし実際には、データ損失のリスクがゼロのシステムは実現不可能または非常に高価です。アトラシアンでは、データ損失ゼロシナリオと、アベイラビリティーゾーンの障害を乗り越えるという目標の達成に努める考え方をとっています。一方、ビジネス継続性計画においては、コスト、メリット、リスクの適切なバランスを見つけ、「RTO (目標復旧時間)」と「RPO (目標復旧時点)」を設定することが重要です。
RTO とは、インシデントの後、ビジネスプロセス (またはシステム) が復旧し、バックアップされ、動作するようになるまでの時間を意味します。RPO とは、復旧操作において、失われても組織が許容できる範囲のデータ量を意味します。簡単な例を挙げると、バックアップを毎日取っている場合、その日の終わりにインシデントがあると、前日に取ったバックアップからデータを復旧させることになり、1 日分のデータが失われます。これが RPO です。
アトラシアンではビジネスに与える影響とリスクの評価を行い、チームがクライアントユーザー要件や中断による潜在的な影響に基づいてカスタム RTO と RPO の目標設定を行う際に役立てています。
具体的には、サービスを階層と呼ばれる分かりやすいバケットに分けます。製品、顧客向けサービス、アトラシアンのビジネスシステム、内部ツールには、3 つの階層が定義されています (Tier 1、2、3)。それらの基盤となる階層 (Tier 0) は、すべてが依存する重要なコンポーネントに対して、さらに高い可用性基準を規定しています。
Atlassian は各階層に必須の目標を定義するため、ビジネスに与える影響評価や、構築するサービスの一般的な使用シナリオなどを確認しています。サービス階層は、以下の表に示す可用性、信頼性、RTO、RPO の目標を決定するのに役立ちます。
| Tier 0 | Tier 1 | Tier 2 | Tier 3 | |
|---|---|---|---|---|
| 重要なインフラストラクチャとサービスコンポーネント | Tier 0 サービスは他のすべてのサービスの基本であり、製品を提供するために重要なものです。 | Tier 1 サービスは一般的にアトラシアンの製品、または製品の提供に直接関係するものです。 | Tier 2 サービスは、緊急度が低いか社内向けのものです。 | Tier 3 サービスは、緊急度が低いか社内向けのものです。 |
| サービスの例: | サービスの例 · AWS プラットフォーム · Micros サーバー · コアネットワーク | サービスの例 · Jira および Confluence Cloud · Bitbucket · Jira Align · Trello · Opsgenie | サービスの例 · 画像のエフェクト · 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 が必要となった場合に対応できる、専任の社員とチームを用意しています。社内の運営委員会、リスクの評価、ビジネスへの影響の分析テスト、実際に起きるインシデントまでサポートできるよう、適切なレベルのリソースを保持しています。
概要
アトラシアンは、最高水準の技術と継続的なテストおよび検証を組み合わせ、お客様のデータの可用性、信頼性、回復性を高度に実現します。地理的に多様な複数のデータセンターを運用し、広範囲にわたるバックアッププログラムを保持し、ディザスタリカバリとビジネス継続性計画を定期的にテストして確実性を高めています。さらに、優れた人材と専任リソースを活用し、プロセスを実行しています。