The Doppler Quarterly (日本語) 春 2016

ゼロダウンタイムの移行テクニカルガイド Jonathan Baier、 Prakash Patil クラウドテクノロジーのパートナーとの連携によるアプリケーション移行の経験で、さまざまなエンタープライズアプリケーションのポートフォリオを見てきた結果、一定のパターンがあることが明らかになっています。クラウドに移行するほとんどの組織には、さまざまなレベルのレガシーアプリケーションがありますが、その一部はクラウド環境に適している一方で、大幅なリファクタリングが必要なものもあります。ミッションクリティカルなアプリケーションでは、移行中に長期間にわたるダウンタイムを確保する余裕はありません。このような場合、ゼロダウンタイムの移行を実装することが少なくありません。ゼロダウンタイムの移行はビジネスの中断を軽減するには効果的ですが、注意深く取り組むことが求められます。余分なセットアップ作業が生じ、新システムへの切り替えに厳密な調整が必要になるため、従来の「リフトアンドシフト」型の移行に比べて合計の時間とコストが増大します。しかし、より重大な点は、ゼロダウンタイムいう要請によって一般に移行および検出プロセス全体がショートカッ 8 | THE DOPPLER | 2016 年春号トされることです。つまり、交換サーバーが構築されて初期テストが完了すると、チームは古いシステムの作業に余分な時間を費やす必要はなくなるため、この反対のアプローチが正しいことがわかるのです。ゼロダウンタイムの利点が十分なビジネス価値とインパクトを持つアプリケーションの場合、検出と依存関係のマッピングにさらに多くの時間を費やす必要があります。既存のシステムと並行して、重複したシステムが稼働しテストされても、システムを切り替える前にあらゆる面で完全なテストを行うのは難しい場合があります。よく言われるとおり、「実際に本番環境で実行されていなければ、本番環境での実行とはまったく異なる」のです。もちろん、アプリケーションのインパクトが非常に高く、余分な作業に投資する価値があるケースもあるのも確かです。この記事の以降のセクションでは、最新のゼロダウンタイム移行で私たちが直面した課題について詳しく説明します。移行の背景前四半期の The Doppler で特集されたように、 AVID Technologies 社は自社のインフラストラクチャの大部分を、フルマネージドのプライベートデータセンターから AWS に移行しました。ほとんどのアプリケーションは COTS ( 商用オフザシェルフ ) であり、リフトアンドシフト移行に適していました。ただし、 2 つのミッションクリティカルなアプリケーションは、停止するとビジネス上大きな影響があるため、ゼロダウンタイムの移行が必要でした。いずれのアプリケーションにも、他のアプリケーションやシステムからの数多くの依存関係がありました。これら 2 つのアプリケーションの移行プロセス全体を通じて多くの課題がありました。その一部を次に示します。 • 構成管理に関する知識のギャップ • 互換性の問題により、 AWS ELB (Elastic Load Balancer) を使用する代わりにHAProxy ベースのロードバランサーをプロビジョニングする • ほぼ 2TB のデータを同期し、移行の間に同期を保持するまた、あらゆる可能性を考慮したテスト計画を作成するのが困難でした。レガ

The Doppler Quarterly (日本語) 春 2016 | Page 10