🔎

オンプレ→クラウド移行で絶対に外せない“テスト/移行”のポイントまとめ

に公開
インフラ
Test
クラウド
移行
オンプレ
idea

はじめに

オンプレで長く運用してきたシステムをクラウドへ移行する――
一見シンプルな作業に見えて、実際に着手すると
「どこから考えればいいのか」途端に輪郭がぼやけてきます。

そこで本記事では、クラウド移行で“最低限ここは押さえておきたい”という観点を
見積・設計・テスト/移行・運用の4フェーズに分けて整理しました。
今回はその中でも 「テスト/移行」フェーズについて解説します。

現場でつまずきがちなポイントにも触れながら、
できるだけ多くの環境で応用できる内容を目指しています。

これからクラウド移行を検討する方、
すでにプロジェクトに関わっている方の参考になれば幸いです。

筆者について

入社から10年ほど、オンプレシステムの開発・保守・運用に携わってきました。
あるタイミングでクラウドを扱う部門へ異動となり、
オンプレ歴の長いエンジニアがクラウドへ踏み出す際に感じたギャップや気付きをもとに、
本記事を執筆しています。

クラウド移行で“最初に”考えるべきテスト/移行のポイント

テスト計画

テストフェーズ分解

クラウド、オンプレにかかわらず、テストとしてはざっと以下に分解できます。

テストフェーズ一覧

  • 単体テスト(UT)
  • 結合テスト(IT)
  • 性能テスト
  • 障害テスト
  • 監視テスト
  • 運用テスト

単体テスト(UT)

単体テストは設定値の確認が主な内容です。
というのもクラウドの場合、
機能が動くかどうかについてはクラウドベンダーが保証してくれているため、
誤りがあるとすれば設定値になるためです。

結合テスト

結合テストでは、複数のコンポーネント間のテストを実施します。
オンプレ環境のみのテストと違い複数のマネージドサービスを利用するため、
利用する機能ごとに抜けもれなくテストケースを作成する必要があります。

結合テスト実施内容

  • マネージドサービスを利用する機能(ストレージや名前解決、時刻同期 等)
  • クラウドの管理機能の利用(権限、コスト確認 等)
  • 運用処理の実行方式を変更した処理(サーバ停止起動、バックアップ、リストア 等)
  • 他オンプレシステムなどの外部システムとの接続

オンプレ→クラウドの案件の場合、
オンプレの際に使用したテストケースを流用して作成する場合もあるかもしれません。
その場合より抜け漏れが発生しやすくなるので、改めて1つ1つの機能をテストする意識を持ちましょう。

性能テスト

性能設計で机上確認した性能が実際に出るのかを確認します。
実際に処理を流してみての確認となりますが、以下注意が必要です。

性能テスト実施する上での注意点

  • 処理を一回流すのではなく、負荷のかかった状態を想定したテストも実施すること
  • 1週間、1か月という単位で処理を繰り回しで流すテストも実施すること
  • 外部システムと接続がある場合、外部システムへの影響を考慮すること
  • 移行時の際のデータ移行の性能も観点とすること

設計の記事でも書きましたが、
どこがボトルネックになりうるのかは事前にチェックしておくとよいです。
想定通りの性能が出なかった場合に、チューニングが必要なポイントが探しやすくなるためです。

障害テスト

障害テストはシステム内の各コンポーネントで障害が発生した際の動きや復旧方法のテストです。
クラウド環境の場合、インフラ部分はクラウドベンダーの責任範囲となるため、
実際に障害を起こしてのテストが難しい場合があります。

そういった場合もテストをあきらめるのではなく、
各コンポーネントで障害が発生した場合の動きや外部への影響を整理しておくことで、
実際に障害が発生した際に混乱なく対応することができます。

クラウドサービスによっては、
疑似的に障害が起きた場合と同じ状況を作れるサービスを提供していることもあるので、
そういったツールを使うことで品質を高めることができます。

監視テスト

オンプレ→クラウドにシステムを更改した場合、
高確率で監視のやり方にも変更が入っているかと思います。
そのため、以下に挙げるような監視項目を網羅的に確認する必要があります。

クラウドシステムの監視テスト項目

  • 死活監視
  • リソース監視
  • サービス/プロセス監視
  • ログ監視
  • マネージドサービス監視

ただ監視できるかだけでなく、
閾値や監視条件の確認も網羅的にできるとリリース後のトラブルは減らせます。

またクラウド化に伴い、
マネージドサービスの監視も含め一元的にモニタリングできるような構成としてる場合は、
想定通りの経路でモニタリングできているかもチェックするようにしましょう。

運用テスト

システムはリリースして終わりではなく、定期/非定期の運用作業が発生します。
これらの作業をスムーズに行うために、運用手順書のテストを実施する必要があります。

おそらく多くの現場で開発担当と運用担当は分かれているため、
開発担当で作成した手順書を運用担当が実施することになると思います。

手順書を作成して終わりでなく、実際に運用担当に手順を実施してもらい、
運用受け入れが可能かしっかりと時間をとって検証するのが理想です。

移行計画

移行方式検討

オンプレ→クラウドへシステム更改する場合、
オンプレで持っているデータをクラウドに移行する必要があります。

データの移行方式はいくつかあり、その中で環境に合わせた最善の移行方式を選ぶ必要があります。
環境によるため一概には言えませんが、
以下移行方式を検討する上で大切な考慮ポイントをいくつか挙げます。

移行方式検討のポイント

  • クラウドサービスを利用した移行が可能か
  • オンプレ→クラウドの移行経路は確立しているか
  • 移行時に移行データの暗号化等セキュリティ対策はどの程度必要か
  • 移行後に移行データの正常性確認は可能か
  • 複数移行方式がある場合にコストを考慮できているか

移行経路のNW帯域確認

クラウドへの移行の場合、一部を除いてNW経路のデータ移行となります。
多くの場合、複数システムでその帯域を共有している場合が多いと思います。

移行時は大量のデータがその帯域を流れるため、
更改前のシステムや他のシステムに影響が出ない時間帯で移行を実施することが必要になります。
その影響が出ない時間の中でデータ移行を終えることができるかという点も、
性能テスト等で確認しておくことが肝要です。

もし、NW伝送が難しい場合、
オフラインでデータをクラウドに運ぶサービスもあるので利用を検討しましょう。
(AWSでいうSnowball等)

テスト/移行フェーズの要点をもう一度整理

最後にテスト/移行フェーズで最低限気を付けたほうが良いポイントについて
チェックリスト化しました。
クラウド化を検討する際に参考になれば幸いです。

✅ テスト/移行フェーズ チェックリスト

▼ テスト計画
　■ 設定値確認のテスト
　■ マネージドサービスのテスト
　■ クラウド管理機能のテスト
　■ 運用処理等オンプレからの変更点のテスト
　■ 負荷や繰り回しの性能テスト
　■ 各コンポーネントの障害発生時の動きや影響を整理
　■ 網羅的な監視テスト
　■ 実機検証を前提とした運用受け入れ

▼ 移行計画
　■ NW経由の移行可否の確認
　■ 移行時の各方面への影響確認
　■ 移行方式のコスト比較
　■ 移行時のデータ伝送の性能確認

Discussion