この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

オンプレミスのシステム運用をしつつ、クラウドのPoCを経てクラウド移行からその後のシステム運用までをインフラ運用担当者として担当した経験を踏まえ、インフラ運用観点でクラウド移行する際のポイントについて、サーバ移行、ネットワーク移行のシナリオごとに事前に考慮していてよかった点や、想定外だった点、もっとこうしておけばといった点などをざっくりとまとめました。

 

読んだほうがいいかもな方

パブリッククラウド（Azure,AWS,GCP等）への移行を検討している下記のような方かなと思います。
現在オンプレミスで物理環境で運用されている方
自社インフラで仮想化してプライベートクラウドとして利用されている方、
DC事業者等で提供されているプライベートクラウドを利用されている方

 

補足

ここではいわゆるクラウドごとのメリットやデメリットなどには言及しません。
内容はAzureを前提といたしますが、AWSやGCP等でも考え方は変わりません。

 

運用環境

・複数の取引先、関連会社と閉域網でそれぞれ個別に接続されており、業務用件で専用線の回線ごとに双方向、他社から自社、自社から他社への接続がある
・セキュリティに厳しく、インターネットとの通信はDCとし、パブリッククラウド上のインターネットゲートウェイ経由の業務通信は禁止
・データセンター事業者提供のプライベートクラウドからの移行

 

サーバ移行シナリオ

基本方針	クラウドベンダーから提供されているマイグレーションツールを利用したV2V
	ADサーバ：クラウド上にVMを構築してドメインコントローラーに昇格。最終的にFSMOをオンプレ環境から移行
	ファイルサーバ：移行ツールではディスクサイズがサポート対象外だったため、クラウド上にVMを構築してオンプレからクラウドへ日次でデータ同期
移行単位	システム単位の移行
データ同期	DBなどのデータは移行最後に最新化

 

事前に考慮しておいてよかった点

IPアドレスのハードコーディングチェック

クラウドへのマイグレーション方法として「リフト＆シフト」という手法がよく採用されます。
既存システムをそのままクラウドに移行し、その後クラウドに最適化させていく手法ですが、既存システム上で、OSやアプリケーションの設定、開発したアプリのソースコードなどを含めIPアドレスのハードコーディングがある場合、移行後にOSやアプリが正常に動作しないといった問題が発生することがあります。
既存環境と並行してクラウドを利用する場合では既存環境と異なるネットワークで構成することが一般的ですので、
移行前にIPアドレスでハードコーディングしているものを洗い出し、ホスト名で名前解決できるようにしておくといった対応が必要です。

 

よくある例：
メール通知設定のあるアプリケーションでメールサーバがIPアドレスで指定されている
接続先ホストがIPアドレスで指定されている

 

製品のクラウド対応と移行時のライセンス確認

利用しているミドルウェアやアプリケーションが移行予定のクラウドをサポートしているか製品ベンダーに確認しておく必要があります。
サポート外となる場合は以下のような検討が必要になります。
・利用している製品のバージョンを上げることでサポート対象となる場合　→クラウド移行前に製品のバージョンアップが必要
・サポート外となるが、クラウドに依存しない部分の問合せは受け付けてもらえる場合　→クラウド上での動作検証が必要
・一切のサポートが受けられない場合　→類似機能を持つ代替製品を選定して事前検証が必要

製品によっては、クラウド上で利用する場合、追加の保守費用が発生することもあります。
また、移行時は既存環境と移行環境で並行稼働することとなりますので、並行期間のライセンスについて製品ベンダーに確認しておく必要があります。
製品によっては並行期間分の追加ライセンスが必要なこともあります。

 

想定外だった点

マイグレーションツールのバグ

クラウドベンダーから提供されているマイグレーションツールに問題があり、
ツールを利用してV2VしたVMが処理で高負荷になると通信不可となる事象が移行完了後に発生しました。
移行後の正常性確認では問題が発見できなかったたため、システムの稼働に則した性能試験なども移行計画に組み込む方がよいです。

 

検討しておけばよかった点

サーバ/アプリケーションのEOL対応

クラウドベンダーでマイグレーションツールが提供されているため、V2V,P2Vの移行は比較的容易に行えるようになっています。
基本的にはマイグレーションツールでの移行でよいですが、製品やOSのEOLが見えている場合は、 EOLを見越して、クラウド基盤上で新規に仮想マシンを構築しデータ移行するなども検討しておく方がよいです。
もしくはクラウド移行前にEOL対応を済ませてからクラウド移行するということも検討した方がよいかもしれません。

PaaSへの移行

「リフト＆シフト」でリフトした状態は、IaaSレイヤーの移行となりますので、運用基盤がクラウドになったのみとなり既存運用とほぼ変わりません。
初期の「リフト」時からシステムのPaaS化を検討し、PaaSで実装できるシステムはPaaS化することで、OSレイヤの運用がPaaSのマネージドの範疇となり、OSのパッチ適用や日々のメンテナンス作業といったサーバの運用が不要となります。
十分な検証期間を確保できる場合は、「リフト」時からPaaSへ「シフト」することをお勧めします。

 

ネットワーク移行シナリオ

基本方針	既存踏襲
移行単位	クラウド：事前構成 NW機器：全体3回移行　事前に複数回のリハーサル実施

 

事前にに考慮してよかった点

FWルール・ルーティング

オンプレミスからクラウドへの移行要件でFWルールやルーティングなどは既存踏襲となることがよくあります。
オンプレミス上にいわゆる過去の遺産的なよくわからないFWルールやルーティング等が残っている場合、
よくわからないからとそのまま移行したFWルールやルーティングがセキュリティホールになる可能性もあります.
クラウド移行するための通信要件の見直しという観点で、時間が掛かってもFWルール・ルーティング等の精査を行なった上で移行することをお勧めします。

 

要件が合えばお勧めな点

インターネットゲートウェイ

セキュリティ要件によりDCにインターネットゲートウェイを設置しましたが、そういった制約事項がない場合、
自社ホームページや外部向けサービスなど、インターネット上に公開しているサービスは
クラウドにインターネットゲートウェイを設ける構成を推奨します。
オンプレ上にインターネットゲートウェイを持つ場合、通信の上り下りともにクラウドの専用線(Azureの場合：Expressroute)を通る通信経路となりますので、内部通信のみならず、外部通信分の通信帯域など考慮する必要があります。
また、セキュリティ対策を検討するにあたり、DDoS対策や、WAFの利用もオンプレ上で機器を導入して構築・運用することを考えると、クラウド上のサービスを利用することで導入・運用もオンプレ環境より容易になります。

 

想定外だった点

他社専用線

企業によっては、提携先、取引先企業と閉域網の専用線を引き込み業務を行っている場合があります。
専用線経由で他社から自社の業務システムへ接続しているような場合において、以下のような点を考慮する必要があります。
・内部通信でクラウド上のLBで冗長化されたWEBシステムへ接続するケースにおいて、クラウド提供のLBでIPの固定化が可能か。
　NW機器がL4制御(IPアドレス/通信ポート)場合、L7のURL(FQDN）ベースの制御はできないため、　IPアドレスが可変で何かしらのタイミングでIPアドレスが変わる場合に通信できなくなる可能性があります。
　ルーティングやFWルール・ACLでLBのVIPを設定している環境で、LBの仕様で故障時に自動復旧する際、別のIPが割り当てられるようなケースにおいて　NW機器で設定されているLBのIPと異なるため通信できなくなる恐れがあります。
　外部LBを構成してグローバルIPをVIPとし、セキュリティグループで送信元を絞り込み、DCのNW機器にもLBのグローバルIPを内部からクラウド専用線へ通信するように構成して利用する、クラウドのマーケットプレースからLBのアプライアンスを利用する、オンプレ上でLB機器を用意するといった代替手段を検討する必要があります。
　内部LB 利用時にVIPが固定できるかパブリッククラウドにより実装が異なるため移行計画段階で調査・検証が必要です。

 

まとめ

コストに関して

クラウドは、事前に高価なサーバ機器など物理的なインフラストラクチャーを購入する資本的支出ではなく、必要に応じてサービスや製品に支出する運営支出となります。
誰もができる限りコストを抑えたいと考えていると思いますので、インフラ運用観点でのコストが上振れる要素、推奨することを挙げていきます。

 

リザーブドインスタンス

常時起動が必要なサーバーはリザーブドインスタンス(以降RIと略します)を購入することでコスト削減することが可能です。
ただし、購入したRIでCPUやメモリが不足している場合は、変更するタイプのRIを別途購入しなければならず、変更前のRIの利用用途がない場合、RIの不良債権が発生してしまいます。
RI購入前に十分な性能テストを実施して、ピーク時のリソース等を確認した上でRIを購入しましょう。

また利用するパブリッククラウドによっては、利用するリージョンなども関係なくオンデマンドで稼働しているVMの時間当たり一定の利用料での割引プランがあります。
VM全台で時間当たり10ドル以上稼働している場合、その10ドルに対しての割引プランを購入という形となります。（10ドルを超える分はオンデマンド料金で請求）
逆に時間当たり10ドルに満たない稼働の場合は損となります。
RIより割引率は落ちますが、インスタンスタイプやリージョン等の縛りなしで利用できるためRIより柔軟に利用できます。

 

ディスク

VMインスタンスのRIにはディスクの割引は含まれておりません。また、VMのディスクはプロビジョニングしたサイズの課金となります。
VMのディスクサイズは将来のデータ増加分を考慮し余裕を持たせることが必要ですが、不必要なディスクサイズのVM数が多い場合、余剰なディスクサイズの累積で、ボディーブローのようなコスト増となる要因になります。
また、コスト上、ストレージ料金が合算で表示されるため、より見えない状態となり、分析も難しくなります。
適正なディスクサイズでプロビジョニングし、ディスクが不足する場合は拡張/増設するという運用がお勧めです。

例：
50GBあればよいところを200GB割り当てたVMが10台だった場合、
余剰分150GB x 10台 = 1500GBのディスクサイズ分の不要コストが発生することになります。

 

クラウド上のログ収集

クラウドの機能を利用したクラウド基盤のログ収集や、利用しているクラウドサービスのログ収集、構成したOSやアプリケーションのログ収集でデータサイズが増加していきます。
自社のコンプアライアンス要件やセキュリティ要件に則したログの保存期間や、常時分析に使うログや何か調査が必要なときのみ利用するログなど分類することで、提供されているサービスの中からより安価なストレージサービスを利用する、保存期間が過ぎたら自動で削除するといった機能を利用するといった対応で、収集しているデータのコスト管理が可能です。

 

ネットワーク転送データ量

クラウドに向けての通信では課金されませんが、クラウドから出ていく通信は課金の対象となります。
また、複数リージョンを利用しており、リージョン間でデータ転送する際は課金の対象となります。
バックアップ等のサイズが大きいデータをリージョン間で転送している場合、想定外にデータ転送量が増えることがありますのでご注意ください。

 

タグ付け

コスト分析にタグを利用することが可能なため、設計段階からタグを利用することを前提として検討することをお勧めします。
システム単位や環境単位、リソース単位などでタグ付けすることにより、システム単位のコスト算出や、本番環境、開発環境などの環境単位、ディスクなどのリソース単位でコスト分析が可能となり、分析に必要なデータの分類が可能になります。
特に部署ごとにシステムを保持しており、情報システム部から各部署にシステム単位でコスト請求するといった利用形態の場合はタグが必要になります。

 

最後に

個人的にクラウド移行でインフラ運用として一番のメリットと思うのは、物理サーバの管理（お守り）から解放された点です。
サーバはネットワーク機器より故障率が高いため、故障の度にデータセンターへ保守に行くストレスや、機器の保守期限に伴う物理機器のリプレースから解放されただけでも十分すぎるぐらいのメリットだと思います。

最近では金融系の企業でもクラウドへの移行が進んでいますので、検討中の企業の方もクラウドへ移行しましょう。