MSC (Mediterranean Shipping Company) 社を支える Azure Site Recovery

2020年1月22日 に投稿済み

Program Manager II, Azure Site Recovery

本日の Q&A 投稿では、Microsoft Azure Site Recovery エンジニアリング部門のプログラム マネージャー Siddharth Deekshit 氏による、MSC 社のインフラストラクチャおよび運用部門 IT 責任者 Quentin Drion 氏へのインタビューをご紹介します。今回の話題は、輸送とロジスティックのグローバル企業である MSC 社による Azure Site Recovery (ASR) の導入プロセスです。Azure で回復性を実現するための詳細については、このホワイトペーパーをご覧ください。

はじめに Azure への統合を含め、MSC 社が行っている変革のプロセスについて伺いたいと思います。Azure は現在、ビジネスにどのように役立っていますか?

MSC は海運会社なので、世界中でコンテナーを運んでいます。私たちは長年にわたって、コア ビジネスを管理するために独自のソフトウェアを開発してきました。子会社の規模に合わせて各種のソフトウェアを用意し、オンプレミスで実行していたので、これらすべてのビジネス アプリケーションをサポートするために、オンプレミスに多数のリソースを確保する必要がありました。そこで数年前に、子会社の規模によらず、すべてのビジネス ワークロードを Azure 内に統合することを決定しました。移行時には、オンプレミスのワークロードを停止してから、Azure でホストされたソフトウェアの使用を開始し、サービスとして子会社に提供しています。この新しい計画は、社内の IT チームによって一元的に管理されています。

すばらしい話ですね。統合は Azure を使用することの大きなメリットです。Azure に移行することで、その他にどのようなメリットがありましたか?

私たちにとっての大きなメリットは自動化です。これは大幅な進歩でした。Azure で提供される統合と自動化の API からさまざまな機能を利用することで、環境のデプロイをわずか数時間で行えるようになったのです。それまでは、ハードウェアを注文し、セットアップして構成する必要があったので、はるかに長い時間がかかっていました。今では、セットアップだけでなく、ハードウェアのサポートや保証についても心配する必要はなくなりました。環境はすべて仮想化されているので、回復ポイントの目標 (RPO)、回復時刻の目標 (RTO)、セキュリティを同じレベルで世界中のすべての子会社に提供できます。

RTO や RPO の話が出たので、Site Recovery について伺いたいと思います。Site Recovery を使用する前は、どのような運用体制でしたか?

実は、Azure へのワークロードの移行を開始したときには、いまだに従来型のアプローチを採用していました。つまり、1 つの Azure リージョンでプライマリの運用ワークロードを実行し、別のリージョンにディザスター リカバリー用のインフラストラクチャ一式をセットアップして管理していたのです。このように、Azure でのディザスター リカバリー (DR) は、オンプレミスのデータセンターで使われる従来型のアプローチで始めたのですが、その後、Site Recovery の機能について時間をかけて調査しました。この調査といくつかのテストから得られた結果に基づき、私たちは 2、3 年にわたって展開していた実装を変更して Site Recovery に切り替えることを決断しました。これにより、別のリージョンで DR 用の Azure Virtual Machines を実行し続ける必要がなくなったので、最終的にコストを大幅に削減することができました。さらに、管理作業も楽になりました。既存のワークロードでは、以前のアプローチに比べて RPO と RTO が向上しています。そのため、全社的に大きなメリットが得られました。

とても参考になる話です。Site Recovery を使用する上で最も懸念していた点は何でしょうか? あなたのチームはテストを行ったそうですが、Site Recovery が正しい選択だと確信した理由を教えてください。

テストの結果からそう判断しました。以前は、DR 用のリージョンに切り替えるために多くの作業を手動で行い、ドメイン ネーム システム (DNS) の設定やその他のネットワーク設定が正しいことを確認していたので、多くの制約があったのです。テストを行ってみると、手動での作業に比べて、Site Recovery は魔法のようにスムーズに動作し、プライマリ リージョンで障害が発生しても、わずかな作業で済むことに驚かされました。私たちのアプリケーションは DR 用のリージョンで再起動したので、必要な作業は、アプリケーションの上位層を管理して、正常に起動したことを確認することだけでした。アプリケーションの再起動には注意を払っていました。Site Recovery が機能することは確信していたので、仮想マシンについては心配していませんでしたが、データベース エンジンが原因で問題が起こるかもしれないと考えていたからです。Site Recovery がうまく機能することがわかったのは、嬉しい驚きでした。すべてのチームは、このソリューションにとても満足しており、運用チームの一員として、この種のテクノロジに移行することに付加価値を見出しています。管理部門にいる私たちも同様です。保有していても実際には使用されていなかった Virtual Machines の数が減り、コスト削減につながったからです。

Site Recovery の導入プロセスについてお聞かせください。

その時点で、社内で開発した主要なアプリケーションが 6 つか 7 つ、Azure にデプロイされていたと思います。テストの候補として、これらのアプリケーションから 1 つを選び、そのテストは成功しました。次に、運用環境にあるさまざまなアプリケーションを試しましたが、それらについても大きな問題はありませんでした。唯一問題になったのは、大容量ディスクの扱いでした。当初は大容量ディスクの一部はサポートされませんでしたが、この問題はすぐに解決され、その後は面倒なことはありませんでした。テストの成功に基づき、プラットフォーム上にあるすべてのアプリケーションで Site Recovery を使用するようにして、ディザスター リカバリーを実現しました。

Azure Virtual Machines で現在実行しているワークロードについてお聞かせください。Virtual Machines で実行しているアプリケーションを、何人のユーザーが日々の業務で使用しているのですか?

これらはコア ビジネス向けのアプリケーションです。もちろん、基盤となる主要なインフラストラクチャがありますが、私たちが提供しているのは Azure の Citrix フロントエンドで利用できる社内開発のビジネス アプリケーションです。これらのアプリケーションでは、コンテナーの予約や顧客登録などを行います。さまざまなワークロードが輸送工程に関わっているのです。ユーザーに関して言えば、一部のアプリケーションは 5,000 人を超えるユーザーによって使用されており、彼らにとって日々の業務で欠かせないものになってきています。

非常に多くのユーザーに使用されているのですね。DR のソリューションとして Site Recovery を信頼してくれることを嬉しく思います。これらのワークロードのアーキテクチャについて話していただけますか?

ほとんどは Windows ベースのワークロードで、世界規模で最も使用されているソフトウェアは 3 層アプリケーションです。私たちは、SQL 上のデータベース、中間層サーバー、アプリケーション サーバー、いくつかの Web フロントエンド サーバーを運用しています。現在開発している新しいアプリケーションについては、マイクロサービスがベースになっています。また、特定の用途に使用されている Linux サーバーもあります。

Linux 環境の移行についての話をお聞かせください。

Site Recovery は、Linux ワークロードでも非常にうまく機能します。しかし、私たちは最初にわずかなミスをしてしまいました。Red Hat が提供する Satellite という製品を環境のアップデート用に使用したいと考えていましたが、Satellite を使用する場合は Virtual Machines の管理方法を変更できないことに気付かなかったのです。これは最初に定義する必要があり、後から変更することはできません。その他、「ライセンス持ち込み」のしくみはとてもうまく機能し、Site Recovery では特に役立っています。

シームレスな体験を得られていることを嬉しく思います。その他に Site Recovery について印象に残った点や、他の組織にとって参考になると思われることはありますか?

私は、訓練を簡単に実行できる機能が気に入っています。従来型のアプローチでは、ディザスター リカバリーの完全なテストを行うたびに、その準備に多くの時間とリソースが必要でした。私たちは数週間前に Site Recovery を使用して完全な環境でテストを行ったのですが、その準備はとても簡単でした。復旧リージョンへの切り替えは高速で、ワークロードをプライマリ リージョンに戻す操作も簡単に終わりました。ですから、私が強調したいのは Site Recovery が本当に使いやすいという点です。

この作業をもう一度最初から行う必要があるとしたら、Site Recovery の導入方法は違ったものになるでしょうか?

もっと早くから使い始めるでしょう。はじめに従来のアクティブ/パッシブ型アプローチを採用していなかったら、会社の時間とコストを節約できたと思います。しかし、私たちは今回の移行プロセスがうまくいくと確信していたので、それ以外の点では、大きな違いはないだろうと思います。私たちが次に取り組みたいと考えているのは、Azure Site Recovery サービスを使用して、Hyper-V 上のオンプレミス仮想マシンで実行されているワークロードをレプリケートすることです。これらのアプリケーションはまだ Azure に移行されていないので、少なくともディザスター リカバリーの手順を確立しておく必要があります。また、VMware 仮想マシンがいくらか残っているので、Hyper-V への移行プロセスの一環として、それらをレプリケートしたいと考えています。現在は、これらの作業について検討しています。

Site Recovery を検討中のお客様や現在使用しているお客様へのアドバイスはありますか?

私のアドバイスは、小規模でもいいので、早くから使い始めようと提案することです。1 つの小さなアプリケーションが対象であっても、Site Recovery を使い始めれば、その付加価値がわかるので、Site Recovery の提供するサービスが信頼でき、自分たちですべてを行う必要はないということを運用チームに納得させることができるでしょう。

すばらしいアドバイスですね。私の質問は以上です。MSC での経験をお話いただいき、ありがとうございました。

Azure で回復性を実現するための詳細を確認する