AWS移行あるある

こんにちは。富士ソフト北村と申します。この記事は、Japan APN Ambassadors Advent Calendar 2021 の ４日目のエントリです。APN Ambassador is 何？と言う方は、APN Ambassadorsってなんだ？2021年度版をご参照ください。なお、記載内容は富士ソフトを代表したものではなく、私の個人的な意見ということをご了承ください。

今日は、「AWS移行あるある」と題してオンプレからAWSに移行した（移行しようとしている）時によく聞く話を書いていきたいと思います。

コストあるある

AWSに移行したらコスト下がるって聞いたのに逆に上がったんだけど。なんて話を時々聞きます。多くの場合は以下の３つのどれかなことが多いです。

比較対象の問題
オンプレでアサインしてるリソースをそのままアサインして移行すると多くの場合サーバ・ストレージ費用としては上がります。理由は簡単でAWSの利用料にはDC代（ラック代、電気代など）、ネットワーク代、ハードウェアメンテナンス費用などが含まれています。なので単純に機器代と比較すると高く見えます。

サイジングの問題
オンプレでは多くの場合、大き目なサイズで購入しています。それはサイジングが間違っているとHWを買いなおしになるリスクがあるので余分に買わざるを得ないためです。AWSではいつでもサイズを変更できるのでギリギリを攻めても問題ありません。

上げっぱなしにしている
オンプレでは買ってしまえばサーバが起動してようと停止していようと変わるのは電気代程度だと思います。しかしAWSでは多くのサービスで起動している時間だけ課金されます。例えば、開発機やステージング機などは使わないときは落としておくことにより費用を下げられます。それらを時間になったら自動で上げて自動で落とすなどということも簡単にできます。

プロジェクトあるある - ロードマップの重要性

「今年中にAWS移行せよ！」と上から命令が。どうすればいいんだ。。。
なんて話も時々聞きます。

色々夢が膨らみ、あれもこれもと思うかもしれませんが、1年という期間でできることは限られます。長期、短期の視点でのゴール設定とAWS利用を開始するにあたってガイドラインを作成することをお勧めします。

移行方針は大きく分けると以下の2パターンになると思います。

1. 費用対効果が高いシステムからリアーキしてAWSに最適化した形で移行
2. オンプレ(DCなど)を廃止してランニングを削減する

1.の方式を取るのは、とにかく開発サイクルを上げてジャストインタイムでシステムをリリースしていく。あるいは、試行錯誤を繰り返して成熟させていくといった開発にシフトしたい場合です。今までウオーターフォール開発で外注に出していたがそのスピードではシステムをリリースするころには需要が変わっているといった動きの速いビジネスに対応するにはハードウェアの準備がなく、様々な開発パーツをサービスとして提供しているAWSは最適です。

2.の方式を取るのは主にインフラ部署主体で移行が行われる場合です。日本の大企業ではITインフラを見ている部門とシステム開発を受け持つ部署が別でIT基盤についてはインフラ部門が受け持っているというパターンが多いです。そういった場合、サイジングや、使用時間の設定などによってコストを見直していうことから着手していくことになります。

また、移行に先立ってAWSの利用方針について社内で決まりを作っておくのも大切です。
AWSはクレジットカードとメールアドレスさえあればアカウントを開設でき、インターネットがあればどこからでも接続可能です。もちろん制限を加えることも可能ですが、そういったことを決めておかないと各部署で勝手にAWSアカウントを取得してシステムを作り、収拾がつかない状態になりかねません。

ロードマップ例
1. アセスメント実施 - 自社ITリソースの確認・調査(ホストや非Intelアーキ機があったりすると単純リホストはできないのでリアーキ検討が必要)
2. 移行計画・PoC実施・ガイドライン策定- リホスト(マシンイメージ移行)、リアーキ(作り直し)など方針や移行ツールの計画、ガイドライン作成
3. 移行実施・運用 - 移行を実施し運用に乗せる

規模にもよりますが、100台以上のサーバからなるシステムで考えると最短でも1年以上は掛かると思います。
行き当たりばったりでいきなり3.から実施してもできなくはないと思いますが、運用でとても苦労することになると思います。

プロジェクトの推進にはCCoE(Cloud Center of Excellence)と呼ばれるチームを作ることをお勧めします。クラウド化は大きな変化です。会社単位で実現するにはインフラ、アプリ、セキュリティ、経営と言った層をぶち抜いた推進が必要になることが少なくありません。

計画段階でぜひ、PoC(Proof of Concept)を実施してください。机上の空論にならないためにも実際にやってみることがとても重要です。オンプレと違いAWSでPoCを実施するにはハコスト的にもードルが低いと思います。

移行ツールあるある

リアーキする人はこの記事を読むまでのことはなく、バリバリとAWSサービスを使いこなししていると思いますので、ここではリホストツールあるあるを書いていきたいと思います。

AWSで無償で使えるツールがいくつかあるのですが、現在はAWS Application Migration Serviceの利用が推奨されています。元々VMimportというツールでVMwareのVMDKやOVFをインポートするツールがあったのですが、そこからAWS Server Migration ServiceというvCenterから直接イメージを抜き出してAWS上に仮想マシンを自動作成するツールに進化しました。また、CloudEndureというOS上からマシンイメージをバックアップして移行するツールをAWS社が買収しCloudEndure Migrationという名前で無償できる様になったのですが、CloudEndureの技術を吸収し再編して完全に自社のサービスとして出してきたのがAWS Application Migration Serviceです。今後はこのツールに集約されるようです。

さて、前置きが長くなりましたが、マシンイメージ移行するときのあるあるを書いておきたいと思います。

基本IPアドレスは変わる
技術的には同一IPでそのまま立ち上げることは可能ですが同一IPをオンプレとAWSで同時に利用することはできないので、ネットワーク一発切り替えが必要になります。この方法で一晩で切り替えられるのは精々数十台規模なのでそれより多い台数を移行する場合はIPアドレスを変更した上で並行稼働テストを実施することをお勧めします。

差分転送は上書きされる
イメージ移行ツールで言う差分転送というのは、差分バックアップの様なもので、そのイメージから復元したサーバは当然元のサーバと同じものになります。何が言いたいかというと、一度、移行ツールで複製起動してIPアドレスやDNS参照などを変更しても、最終的に最新のデータを元のサーバから差分同期した場合、設定情報は元に戻ってしまうということです。なので、こういった移行では移行時に実施する手順をできる限り自動化することが重要です。

ELBあるある
サーバと一緒に負荷分散装置を入れていることは良くあると思いますが、AWSではELBという負荷分散サービスがあります。しかし、一般的なオンプレの負荷分散装置でできるソースIPパーシステンスができないことや、ELB(NLB除く)を通過するときにアクセス元のIPアドレスはELBのIPに変換されてサーバに届く点などが異なります。ELBに置き換えを検討している場合は、PoCなのでよく確認しましょう。

おまけ

固定IPはやめましょう！
何も考えずにAWSに移行した時に最初に困るのがIPアドレス直指定してるサーバです。AWSの可用性は一台のサーバが落ちないようにするのではなく、複数のサーバで組んでおいて落ちても大勢に影響ない様にするというアプローチです。また、AWSではマルチAZ（AZ≒データセンター)で冗長を組むことが推奨でAZが変わるとIPアドレスも変わります。故に冗長化はDNS名で行うことになります。オンプレでVMwareなどを使っていると基本、IPアドレスが変わらない形で冗長を組んでしまうことが多いですが移行するときは、ここを変える必要があります。例えば、RDSのマルチAZ構成を組めば常に動作している方のIPを返してくれるのですが、時々、起動した時に一度だけDNS名をIPに変換してそれ以降は同じIPにアセスすると言った実装のアプリケーションを見かけます。この場合、マルチAZでRDSを組んでも切り替わらないのでご注意を。