TL;DR – 概要
"「メールの継続性」とは、人によってその意味が異なります。 かつては、ほとんどの組織がこれについて頭を悩ませることはなかった。数年前にExchangeやMicrosoft 365の管理者に尋ねれば、メールの障害は自然に解消されると答えただろうし、それは間違いではなかった。マイクロソフトのインフラは確かに優れており、SMTPがメールをキューに格納するため、ほとんどの障害は短時間で解消されるからだ。.
もはや、それだけでは全体像を捉えきれていない。停電の時間が短くても、問題はもはや単に：
“「メールはいつ届くのでしょうか？」”
その代わりに、次のようなものになってしまった：
“「メールが使えない状態でも、組織は運営を続けられるのでしょうか？」”
Microsoft 365 のサービス停止は、生産性の低下、コミュニケーションの遅延、ビジネスチャンスの喪失といった影響をもたらしますが、こうした影響は特に大規模な組織において顕著に現れます。.
さらに、次のようなコンプライアンスの枠組みや NIS2, DORAであり SOC 2 は、ビジネス継続性へのこの移行を後押ししています。こうしたフレームワークは、組織に対し、単なるバックアップや復旧にとどまらず、システム停止、サイバーインシデント、サービス中断時においても業務遂行能力を維持するよう求める、より広範な規制動向の一環です。.
Google WorkspaceとMicrosoft 365を並行して運用することで、どのように事業継続を実現できるのか、その点についてすぐに知りたいですか？
エクスプロアe Google Workspace for Business Continuity Google Business Continuity Plus SKUを機能させる技術基盤であるConnecting Softwareによるものです。.
バックアップはデータを保護します。メールの継続性は業務の回復力を支えます。.
Microsoft 365のバックアップソリューションを考える際、通常はデータの復元について懸念を抱くでしょう その後 ある出来事。.
一方、メール業務継続ソリューションは、コミュニケーション、カレンダー、コラボレーション機能を維持できるように設計されています ～の間 その事件。.
その違いが重要になるのは、次のような場合です：
- Microsoft 365 のサービス停止、,
- 入居者の立ち入り拒否、,
- ランサムウェアによる被害事例、,
- アイデンティティの欠如、,
- あるいはサイバー攻撃。.
本当の疑問は、次の通りです：
プライマリ環境が利用できない間、ユーザーはどのように運用を継続すればよいでしょうか？
また、BCP／DRに関する議論が最終的にたどり着く2つの指標が、ここで役立つのです： RTO そして RPO.
従来のバックアップに関する議論では、RTOは通常、影響を受けたシステムやデータを復元するのに必要な時間として測定されるのに対し、RPOは復元ポイントの経過時間（言い換えれば、どれだけの直近のデータが失われている可能性があるか）を表します。.
事業継続に関する議論では、ビジネス機能レベルにおいて、しばしば同じ指標が用いられます。RTOは、ユーザーが再び通信できるようになるまでに組織がどの程度の期間を許容できるかを問うものであり、RPOは、スタンバイの通信環境がどの程度最新の状態である必要があるかを問うものです。.
この区別は、NIS2、DORA、SOC 2、および同様のレジリエンスやコンプライアンスに関する議論において重要となります。なぜなら、重要なのは、障害発生時にも業務機能が継続できるかどうかという点だからです。.
Microsoft 365 のメール継続性対策の比較
要件が次のように変更されると “「混乱の中でも人々がコミュニケーションを取り続けられるようにする」” ITにおけるアーキテクチャ上の課題は、はるかに興味深いものになります。.
軽量な緊急用メールボックスサービスで十分でしょうか？地域ごとの違いを考慮する必要はあるでしょうか？自社でオンプレミスのインフラを利用すべきでしょうか？
ビジネスが実際に必要とする事業継続の水準を達成するためには、検討すべき複数のアプローチとトレードオフが存在します。以下の表では、主なアプローチを比較しています。これらについては、後ほどさらに詳しく検討していきます。.
| アプローチ | 要旨 | ツールの例とベンダー | 強み | よくある懸念事項 |
|---|---|---|---|---|
| クラウド型事業継続サービス | サードパーティがホストする事業継続プラットフォーム | Mimecast、Retarus、Trend Micro | 迅速な展開 運用コストの削減 |
緊急用ウェブメール以外の継続性には限りがある |
| 2つ目の Microsoft 365 テナント | フェイルオーバーに備えて別途用意された Microsoft 365 環境 | マイクロソフト365 | おなじみのマイクロソフトのエコシステム クラウドネイティブアーキテクチャ |
同一ベンダーへの依存、集中リスク |
| Exchange オンプレミス型サーバー | Microsoft 365と同期された独立した Exchange 環境 | マイクロソフト、CB Exchange Server Sync | 業務上の独立性と管理 エンドユーザーにとって馴染み深いマイクロソフトのエコシステム |
インフラの拡充と維持管理 |
| ホットスタンバイとしての Google Workspace | Microsoft 365と同期された独立した Google Workspace 環境 | Google Workspace 事業継続対策、Google Workspace 向け CB Exchange Server Sync | クラウド間の独立性 SharePoint/Google Drive まで拡張可能 |
ユーザー体験、アイデンティティ、マッピングの違い |
適切なモデルは、組織のオペレーショナル・リスクのプロファイル、コンプライアンス上の義務、およびダウンタイムに対する許容度によって異なります。それぞれの選択肢について、さらに詳しく見ていきましょう。.
オプション 1：クラウド型メール事業継続サービス
これは従来からのアプローチの一つです。Mimecast、Retarus、Trend Micro などのベンダーは、緊急時のメールボックスへのアクセス、メールのルーティング、一時的な通信サービスを提供するクラウドベースの事業継続プラットフォームを提供しています。.
その利点は、迅速な導入と運用コストの削減です。.
しかし、企業のチームからは、こうしたプラットフォームが一時的なWebメールへのアクセス以外に、実際にどの程度の業務継続性を提供しているのかという疑問がしばしば寄せられます。ユーザーは、カレンダーの調整や共有メールボックスの利用を継続でき、インシデント発生後も問題なくMicrosoft 365に戻ることができるのでしょうか？
オプション 2: セカンダリ Microsoft 365 テナント
一部の組織では、地域ごとのサービス障害による影響を軽減するため、フェイルオーバー用に（場合によっては別のリージョンにある）Microsoft 365のセカンダリテナントを利用しています。.
これにより、特にセカンダリテナントの管理、ルーティング、アクセスポリシー、および復旧手順が個別に設計されている場合には、レジリエンスを向上させることができます。ただし、リージョン間展開を行っても、Microsoft クラウドエコシステムに対する広範な依存関係が解消されるわけではありません。.
さらに、もうひとつ微妙な問題もあります。セカンダリテナントが本番環境と同じIDプロバイダー（通常は同じEntra IDテナント）を通じて認証を行う場合、ID関連のインシデントやサービス停止が発生すると、両方の環境に同時に影響が及ぶ可能性があります。.
オプション 3：Microsoft 365 と同期されたオンプレミスの Exchange サーバー
3つ目のアプローチは、Microsoft 365と同期した独立した Exchange サーバー環境を維持することです。.
その一例として、Microsoft 365 と同期されたオンプレミスの Exchange Server の利用が挙げられます。.
このモデルでは：
- Microsoft 365 は引き続き主要な運用プラットフォームであり、,
- Exchange Serverは、独立した事業継続環境であり、,
- BCP用のCB Exchange Server SyncとConnecting Softwareの間で同期が確保されます。.
同期には、次のようなものがあります：
- メールボックス、,
- カレンダー、,
- 連絡先、,
- パブリックフォルダ、,
- 配布グループ、,
- およびGALの同期。.
この環境は、独自の Active Directory を使用してオンプレミスで稼働しているため、Microsoft 365 テナントとアイデンティティプレーンを共有する必要はありません。 これはオプション 2 との重要な違いです。つまり、クラウドテナントに対する ID ベースの攻撃が、自動的にオンプレミスの Exchange 環境にまで波及することはありません。これは、前述の「ID 関連の障害」や「テナントのロックアウト」といったシナリオにおいて、直接的な影響を及ぼします。.
オンプレミスでの運用は、組織がエアギャップネットワーク内でこの種のソリューションを必要としている場合にも最適な選択肢となります。オンプレミス版は、データダイオードと組み合わせて使用することで、そのようなシナリオを実現できます。.
一部の組織がこのアーキテクチャを好む理由
業務継続性の要件がより厳しい組織にとって、このアプローチは以下のメリットをもたらします：
- Microsoft 365 からの運用上の独立性、,
- おなじみの Outlook とカレンダーの連続性、,
- インフラストラクチャとフェイルオーバーに対する管理能力の向上、,
- 規制対象または隔離された環境への対応、,
- 生産テナントからのアイデンティティの独立性、,
- また、雲の濃度によるリスクを低減した。.
SharePointやドキュメント共同編集にも依存している組織は、独立した環境や隔離された環境間でSharePointの同期を安全に行うために、Connecting Softwareの「Secure Sync for SharePoint」を活用したドキュメント同期戦略を追加で導入することができます。.
オプション 4：ホットスタンバイとしての Google Workspace
4つ目のアプローチは、オプション3と同じ論理に基づきますが、スタンバイプラットフォームが異なります。オンプレミスのExchange Serverの代わりに、独立した環境としてGoogle Workspaceを使用し、.を介してMicrosoft 365と常に同期を維持します。 .
これにより、組織はMicrosoftのエコシステムに一切依存しない、クロスクラウドのフェイルオーバーオプションを利用できるようになります。これは集中リスクへの懸念を抱える組織にとって重要であり、すでに業務の一部をGoogle Workspaceで運用している組織の間でも人気があります。また、Google Workspaceを利用していない組織であっても、ユーザーは個人的な経験を通じてGoogle Workspaceに慣れ親しんでいることが多く、フェイルオーバーの際に役立ちます。.
このアーキテクチャの詳細、そのアイデンティティモデル、および具体的なトレードオフについては、次回の記事で詳しく解説していきます。.
Connecting Softwareによる「Google Workspaceを活用した事業継続のためのホットスタンバイの実現方法」をご覧ください
フェイルオーバー：復元ウィンドウの削除
従来のバックアップ・復元の手法では、障害が発生した場合、誰かが復元作業を行わなければ、誰も再び作業を再開することができませんでした。.
これには2つの問題があります。1つは手動での操作が必要なこと、もう1つは復元にかかる時間が、復元が必要なデータ量に比例してしまうことです。大規模なテナントの場合、RTOが数日単位になることも珍しくありません。.
クラウドベースのメール継続性サービスは、この問題に対する回避策ではありますが、その機能には限りがあります。.
同期化されたスタンバイ環境では、その手順が不要になります。メールボックス、カレンダー、そして最終的にはドキュメントのコピーが継続的に更新されるため、ユーザーはその環境に切り替えるだけで、そのまま作業を続けることができます。これは「復旧ウィンドウ」のないフェイルオーバーであり、常に最新の状態が維持されるため、RTOの算出から復旧ウィンドウが除外されます。.
そのコストと、ユーザーが電子メールやカレンダー、その他のメールボックス内のコンテンツを利用できないことによるコスト（生産性の低下、成約に至らなかった案件、および該当する場合はコンプライアンスコストなど）を天秤にかける必要があります。.
フェイルバック：手動による調整の回避
フェイルオーバーは、あくまでその一部に過ぎません。いずれプライマリ環境が復旧し、ユーザーは元の環境に戻る必要があります。これがフェイルバックの段階ですが、ここで真に重要なのは、スタンバイ環境で行われたメールの送受信、カレンダーの変更、文書の編集といった操作について、データを失うことなく、また重複を生じさせることなく、どのように処理されるかということです。.
新しいメールやカレンダーの変更、編集された文書は、手作業で本番環境に反映し直さなければならないのでしょうか？これは、エラーやバージョンの混乱、遅延を招きやすい手作業の工程そのものであるため、誰にとっても好ましい仕事ではありません。.
双方向同期により、この整合処理は自動的に行われます。つまり、停止中に加えられた変更は、プライマリ環境が復旧すると、IT部門の介入なしにMicrosoft 365に反映されます。 リスクにさらされるデータは、直近の同期ポーリング間隔（1回の同期処理から次の同期処理までの時間）の間に変更されたものに限られます。この間隔が5分の場合、実質的なRPOは停止時間の全期間ではなく、およそ5分分の変更分となります。ポーリング間隔に合わせてフェイルバックのタイミングを調整することで、RPOをゼロに抑えることが可能です。
なお、ポーリング間隔にはトレードオフがある点に留意すべきである。間隔を短くするとRPOは低下するが、間隔を長くするとオーバーヘッドは軽減されるものの、データ損失が発生する可能性のある期間が長くなる。.
「正しい」メールアーキテクチャというものは、一つだけというわけではありません。.
適切な解決策は、以下の要因によって決まります：
- Microsoft 365への運用上の依存、,
- 許容可能なダウンタイム、,
- 規制上の要件、,
- 社内のIT能力、,
- および業務のレジリエンスに関する目標。.
要件がそれほど厳しくない組織であれば、クラウドベースの事業継続サービスで十分に満足できるでしょう。.
NIS2やDORAの適用対象となる組織、あるいは高いレジリエンス要件が課されている組織は、より強固な運用上の独立性とフェイルオーバー機能が必要となる場合があります。.
最終的な感想
Microsoft 365 は優れた可用性を実現しています。.
しかし、可用性だけでは、運用上の回復力を保証するものではありません。.
組織では、業務中断時においても業務を継続するためには、電子メールの継続性、カレンダーへのアクセス、およびコラボレーションの継続性が不可欠であるという認識がますます高まっています。.
というのも、実際の停電時には、最も重要な問いは次のことではないからです：
“「後でやり直せるかな？」”
それは：
"「このまま運営を続けていけますか？」"
Connecting Softwareによる「Google Workspaceを活用した事業継続のためのホットスタンバイの実現方法」をご覧ください
著者について
記入例 アナ・ネト, テクニカルアドバイザー Connecting Softwareにて。
"私は1997年からソフトウェア・エンジニアであり、最近は書くことと人前で話すことが好きです。この記事について質問やコメントはありますか？ご意見・ご感想をお待ちしております！"
