Microsoft Azureで無料のVeeam開発およびテストツールを使用するためのシナリオ

AzureクラウドプラットフォームとAzure Marketplaceで提供される独立した開発者のソリューションについて引き続き説明します。 今日、 Azure MarketplaceにあるVeeamの無料ツールの使用シナリオは、VeeamのR＆DディレクターであるAlexander Shirmanovによって説明されています。 Habréへのリンクでは、いつでも他の記事を見つけることができます。 -マイクロソフト、ウラジミールユネフ

今日、私はパブリッククラウドを使用するためのいくつかのシナリオを分析し、それらの助けを借りて、これまで「長い箱の中」に置いていた種類の作業を実行できることを示します。



インフラストラクチャの例を取り上げます。ソフトウェア製品があります。これは、エンジニアが絶えず取り組んでいるアプリケーションです（当然、完璧にするために）。 主なコンポーネントは次のとおりです。

• データベースサーバー（バックエンド）
• 「ミドルリンク」、つまり 基本的な作業タスクを実行するサービス（中間層）
• ユーザーが直接使用するWebサイト（フロントティア）

図1



以前は、製品で作業するために、3つの仮想マシン（各コンポーネントに1つずつ）を展開する必要がありました。 ただし、製品は改善されており、各コンポーネントに複数のロールを含めることができるようになりました。たとえば、Webサイトでは1つではなく複数のVMを使用するため、ロードバランサーが必要になります。 「中間リンク」の負荷も分散されます。 さて、データベースサーバーはSQL Server AlwaysOn可用性グループを使用するようになりました。 その結果、エンジニアが使用するインフラストラクチャは、図2に示す形式になります。









図 2



開発者や製品チームの他のメンバーが使用するテストが実行される環境が、エンドユーザーが通常作業する環境と似ていないことは明らかです。 しかし、実稼働目的で再作成できる必要があるのはまさに彼女のユーザー環境です。

そこで、実稼働のニーズに合わせてテストインフラストラクチャを作成するときに定期的に実行する必要があるタスクの例を共有することにしました。

1.ソフトウェアの開発、テスト、品質管理のためのインフラストラクチャの作成

問題

ソフトウェアの開発、テスト、および品質管理のタスクを実行するためのインフラストラクチャの必要性は、製造会社および小規模な内部開発チームチームにとって緊急です。 大企業がサードパーティのサプライヤからソフトウェアを取得する場合、すべての場合に関連します。サードパーティのサプライヤは、本番環境での動作を保証する必要があります。



もちろん、理想的な世界では、完全にコピーされたユーザーインフラストラクチャを頼りにすることができます。 しかし、私たちの世界は現実のものであり、特に、そのようなコピーの展開に「反対」する理由がいくつかあります。OSに完全にアクセスできるチームは文字通りその場で変更を行うため、変更を管理するのは困難です。 このようなインフラストラクチャの展開には時間と労力がかかり、サポートリソースは限られています。 まあ、多くの場合、企業には単に展開するハードウェアリソースがないだけです。



例に関連してこの状況を考慮してください。IT管理者のリソースは非常に限られているとしましょう。 これまでは、3つの仮想マシン（コンポーネントごとに1つ）を展開するだけで十分でした。 しかし、今ではタスクがより複雑になり、実稼働環境がシミュレートされておらず、ソリューションがテストされていないという事実により、実稼働環境への出力の結果は、以前のバージョンへの完全なロールバックの必要性を含め、かなり暗いものでした。 さらに、そのような制限の条件下では、ユーザー間の開発者とベータテスターは、実際のデータを使用して製品をテストすることができず、リリース後に予期しない結果をもたらしました。



しかし、上記の状況があなたが会った人のカテゴリーに属していない場合でも、おそらく、現在のプロジェクトの一部がリリースしていないリソースの不足のために会社の特定のプロジェクトが中断された場合について聞いたことがあるでしょう。



しかし、パブリッククラウドリソースを使用してこのような問題を解決したらどうでしょうか。

ソリューションオプション

当然、私が使用する実稼働インフラストラクチャに含まれるすべてのマシンに対して、リカバリポイントが定期的に作成されます。 そのため、バックアップの1つをMicrosoft AzureのInfrastructure as a Service（IaaS）クラウドインフラストラクチャに直接復元しようとしました。



その結果、必要なリソースがすべて揃っているだけでなく、ほぼ新鮮な実データ（わずか2時間前）を受け取ったため、エンジニアは本番ソリューションを発行する前に干渉なしで作業を完了できました。



これを行うには、これが必要でした（図3を参照）。

• Veeam Backup＆Replication（またはVeeam Backup Free EditionまたはVeeam Endpoint Backup）を使用して作成されたバックアップ（VBK）
• Microsoft Azureサブスクリプション
• Microsoft Azureへの Veeam Direct Restore
• Microsoft Azure 用 Veeam FastSCP （ Azure VMから\にデータをダウンロードするために使用しました）

クラウドへの復元後、私のサービスのユーザーは、実際の運用インフラストラクチャとまったく同じインフラストラクチャへのアクセスが提供され、さらに、実際のライブデータを操作できました。

2.パッチとアップデートのテスト

誰もがよく知っている別のシナリオを次に示します。 パッチ、ホットフィックス、アップデートなどのテストに理想的な世界 生産インフラストラクチャの正確なコピーを使用し、そこで生産で使用する前に新しい製品を試してみました。 もちろん、実際には、ほとんどのITプロフェッショナルは自由にコピーを自慢することはできません。 代わりに、次のオプションが可能です。

• パッチとアップデートは、いくつかのテストサーバーでチェックされます。 得られた結果に基づいて、変更を実施するための計画が作成され、経営陣に承認のために提出されます。 このオプションには、潜在的に危険な点がいくつかあります。特に、利用可能な依存関係すべてと一緒に更新が常にテストされるわけではありません。
• 「ウェーブ更新」オプション、すなわち 最初に、パッチがサーバーの10％にインストールされ、その状態が1週間監視されます。 その後、別の10％がパッチされ、1週間で残りのすべてがパッチされます。 このアプローチの利点は、重大なエラーが発生してもインフラストラクチャ全体に影響を与えないことですが、マイナスはインフラストラクチャが依然としてリスクにさらされていることであり、このリスクは常に正当化されるとは限りません。

ソリューションオプション

この場合も、パブリッククラウドのリソースを使用します。ここで、本番インフラストラクチャのコピーを作成し、テストが完了したら、切断または破棄できます。 変更計画をテストして文書化し、管理者に送信します。 同時に、スクリーンショットの取得、日記の収集、ビデオの録画などもできます。 など、つまり、必要な情報を便利な方法で収集します。 エンジニアは、パッチのインストール後にインフラストラクチャがどのように動作するかを理解するためにジャーナルエントリが必要になり、スクリーンショットにより、変更の実装プロセスが文書化されていることをマネージャーに確認します。 また、プロセスに関する優れたドキュメントは、同僚の一部が同様の変更を導入する必要がある場合に役立ちます。



実際、テスト環境を作成するために実行した手順は、前のセクションで説明した手順と似ていますが、Microsoft AzureでVMの数を減らす必要がある場合を除きます（設定の数によって異なります）。 たとえば、3つの同一のWebサーバーがある場合、そのうちの1つをテストできます。 同じことがデータベースと「中間リンク」にも当てはまります（図4を参照）。

3.バックアップおよび災害復旧計画のテスト

簡単な質問をしましょう。バックアップをどのくらいの頻度でテストしますか？ 災害復旧計画はどうですか？ 1週間に1回、1か月、1年、それともまったくありませんか？



もちろん、時間、人的資源、これらの目的のために専用の環境を提供する方法がない-常に十分な理由があります。 もちろん、理想的な世界では、これらのテストを実行する必要がありますが、実際にはこれが常に行われるとは限りません。



繰り返しになりますが、パブリッククラウドが助けになります。 バックアップからクラウドインフラストラクチャへの復元には、次のようないくつかの利点があります。

• ローカル機器（ロードバランサー、ルーター、スイッチなど）は必要ありません。
• テストが完了すると、使用されていないリソースをすぐに取り除くことができます
• 追加の機器（ファイアウォール、ルーターなど）は同じクラウドで構成されます
• 災害復旧計画は慎重に検証され、文書化されています。
• インフラストラクチャ全体が事故で破損した場合に、インフラストラクチャをパブリッククラウドに復元する可能性をテストして文書化する絶好の機会

ソリューションオプション

実際、私がすでに上で書いたすべてのことなので、繰り返しはしません。 しかし、私が前に言及していない何かがあります。 インフラストラクチャコンポーネント：ファイアウォール、ロードバランサー、DNSサーバーなどもパブリッククラウドで構成する必要があります。 これは一度だけ行われます（つまり、サブスクリプションの期間全体）-もちろん、何らかのグローバルな再構築の場合を除きます。 しかし、事故が発生した場合は、同一のインフラストラクチャがあり、メンテナンス費用はサブスクリプションの費用に基づいており、高価な機器への投資ではありません。



ITプロフェッショナルは、製造インフラストラクチャをサポートするためにパブリッククラウドを常に使用する傾向があるわけではありません。 ただし、災害復旧計画を準備する際には、このような可能性を考慮する価値があります。 実際、バックアップに切り替える必要がある場合、ネットワークやハードウェアを含む必要なリソースをすぐに自由に使用でき、ブランチのリモートサイトに展開されたインフラストラクチャの正確なコピーのみがそれらと競合できます。

おわりに

インフラストラクチャ全体をパブリッククラウドに完全に転送する必要は必ずしもありません。多くの場合、ハイブリッドアプローチを使用する方が効率的です。 この記事で説明する一般的なタスクのいくつかをパブリッククラウドを使用して解決することは、日常業務で役立ち、開発エンジニアとソフトウェアのエンドユーザーの両方にとって良い仕事になります。

著者について

VeeamのR＆Dディレクター、アレクサンダー・シルマノフ

Azureマーケットプレイス

Azure Marketplaceページで3,300を超えるさまざまなソリューションを見つけることができます。 Azure Marketplaceソリューションストアの詳細については、 ロシア語ポータルをご覧ください。



Azureユーザーは、便利なAzure MarketplaceからVeaamソリューションにすばやくアクセスできます 。 Veeamを今すぐ始めましょう！