ガンホーが明かす「ラグナロクオンライン」AWS移行後の苦労：特集：百花繚乱。令和のクラウド移行（12）（2/2 ページ）

[石川俊明，＠IT]

既存の物理サーバからどのように移行するか

　「移行では、物理サーバから仮想サーバへ移行するP2V（Physical to Virtual）ツールや仮想サーバから仮想サーバへ移行するV2V（Virtual to Virtual）ツールの利用を検討したが、利用するメリットが感じられなかった。そのため、全てのサーバを、『Amazon Elastic Compute Cloud』（EC2）を新規構築して移行する形にした」

EC2を活用したラグナロクオンラインのサーバ構成

　フロント部分もバックエンド部分も、Amazon マシンイメージ（AMI）を新たに作成し、T2／T3インスタンスを起動。そこにサーバ側のプログラムを設置したり、DBを構築したりした。他には、ROに関係する以下の機能をAWSに移行した。

• DNSサーバ：Amazon Route 53
• メール配信（SMTP Server）：Amazon Simple Email Service（Amazon SES）
• 集計バッチ：AWS Batch／AWS Lambda
• 一部Webサイト：Amazon Lightsail
• 一部API：Amazon API Gateway＋AWS Lambda

　「サーバ側は全てEC2で構築した。ROのプログラムはPentium III搭載サーバで実行していた負荷の低いプログラムだったため、基本的にT2インスタンスで実行し、負荷の高い部分をT3インスタンスで運用するようにした。また、DCにMicrosoft SQL Serverを導入していたため、『Amazon RDS』にするか『SQL Server on EC2』を検討したが、コストを理由に『SQL Server on EC2』にした」

コードを誰も触れないレガシーアプリケーションを移行できるのか

　しかし、ROのクラウド移行に当たっては2つの課題があった。ROはC++で開発されていたが、ソースコードが古く、元のプログラムを誰も触れない状態であること、NAT（Network Address Translation）環境下で実行されることが考慮されていないプログラムになっていたことだ。

　「各サーバのグローバルIP／プライベートIPがDBに保存され、サーバプロセス起動時に自分のIPをキーとして通信先のサーバIPなどの情報を取得する仕組みが構築されていた。AWS環境下ではグローバルIPアドレスを割り当てられないため、何も設定せずにプログラムをAWSで運用することはできなかった。そこで、管理サーバとその他でDBを分割し、EC2インスタンスに固定IPアドレスのElastic IPを割り当て、DBに登録するIPアドレスをElastic IPとプライベートIPに変更した」

　サーバ移行については、ROの構築移行を何度か繰り返していたため、大きく変更せずに先述した課題をクリアさせて移行を実現したという。

AWS移行後の苦労

　菊池氏は、AWS移行後にハマった2つのポイントを紹介した。

　1つ目はCPUクレジットの枯渇問題だ。EC2のT2インスタンスでは、CPUの使用率が高まったときにインスタンスのスペック以上にCPUを稼働させられる「バースト機能」を持つ。これを利用するには「CPUクレジット」というリソースが必要で、これが枯渇した場合は、バースト機能を利用できず、システム側が高負荷な状態になってもCPUはT2インスタンスの標準動作のままとなり、サーバの動作や通信に問題が発生する。

　ROの場合、管理サーバとZone（ゲーム）サーバで通信ができないとZone障害が発生する仕様があった。そして、CPUクレジットが枯渇した結果、プロセスは立ち上がっているが、管理サーバとZoneサーバが通信できず、管理サーバはZoneサーバが落ちていると誤認識して障害につながった。

　菊池氏はこの問題についてAWS側のエンジニアと協議し、CPUクレジットが枯渇した場合でもバースト機能が利用できるUnlimited機能をT2／T3インスタンスの両方で有効化させて解決したという。

　2つ目は、EC2インスタンスが落ちた際に起きたトラブルだ。EC2インスタンスでは障害が発生した際に、「StatusCheckFailed」の値を「Failed」にする。具体的には、AWSの物理ホスト側起因の問題なら「StatusCheckFailed_System」、設定ミスやメモリ不足など利用者側起因の問題なら「StatusCheckFailed_Instance」という値をFailedにする。

　ROの場合、StatusCheckFailedのどちらかが発生してすぐ復旧したような状況で、インスタンス自体は正常に動作していてもROが正常に動作しておらず、その発見が遅れることがあったという。現在はStatusCheckFailedが発生したらSlackに通知して状況を確認する運用だが、今後は自動で対応する仕組みを取り入れる予定だという。

移行して良かった点

　菊池氏は最後に、AWS移行で良かった点を振り返り講演を締めくくった。

　「3年かけてDCからAWSに移行するプロジェクトを進めているが、詰まるところを想定しながら進めたため、比較的簡単に移行でき、安定稼働できている。またマネージドサービスの活用で運用自動化にも取り組めている。コスト面でいえば、『AWS CloudWatch』による一元監視が実現できるため、サードパーティーの監視ソフトや、監視用サーバの構築、監視用サーバの監視が不要になった。DCとAWSを並行稼働させている現在は、保守費用は10％の削減だが、今後、その他のシステムもAWS移行を進めれば、2019年以降は55％のコスト削減を実現できると考えている。他方で、今までオンプレの業務しか取り組んでこなかったメンバーがクラウドに関する知識を蓄積したりスキルを向上させたりして、AWSを活用して新しいことをやろうとする流れも出るようになって良かった。ROのクラウド移行事例が参考になれば幸いだ」

この移行事例のポイント

• 全てのシステムを一気に移行させようとするのではなく、リスクが少ないシステムについて、移行後の懸念点を洗い出し、問題点をつぶしてから移行させることができるくらいスケジュールを見積もっている
• コストの見積もりでは、データセンターやサーバの費用単体を見るだけではなく、OS／ソフトウェアなどの保守費用も含め、移行中、移行後の範囲まで試算しており、移行のメリットを明確化している
• 移行用のツールを活用せず、新規構築したEC2インスタンスに載せる形を採ったことで組織内にクラウドと周辺領域の知識を蓄積させている

特集：百花繚乱。令和のクラウド移行〜事例で分かる移行の神髄〜

時は令和。クラウド移行は企業の“花”。雲の上で咲き乱れる花は何色か？どんな実を結ぶのか？　徒花としないためにすべきことは？　多数の事例取材から企業ごとの移行プロジェクトの特色、移行の普遍的なポイントを抽出します。

特集：百花繚乱。令和のクラウド移行〜事例で分かる移行の神髄〜