こんにちは。エンジニアリンググループで主にITインフラ全般を担当しているshibataです。
今回はエン転職のサーバリプレイスでオンプレミスからクラウドへのインフラ基盤移行を行った際に、気を付けたポイントや、移行方法について記載したいと思います。

はじめに

プロジェクト対象のエン転職というサービスについて簡単に説明します。
エン転職は弊社の運営するサービスの中で最も規模の大きい、会員数800万人を超える中途採用向けの求人サイトです。
「失敗したら割とマズいことになるプロジェクトなんだなー」と思っていただければ幸いです。

移行の背景

サーバ老朽化のため、オンプレミスを継続するのか、クラウド移行へ舵をきるのか判断する必要がありました。
それぞれのメリットを洗い出し、エン転職というサービスの性質を考えたときにどちらが最適なのか。
失敗できないプロジェクトなので、実績を重視しオンプレミスを継続するのが一番リスクの小さい選択でした。
しかし、将来の事を考え、リスクを取ってでもクラウド移行を行うことがプロダクトにとって大きなプラスになると判断いたしました。
具体的な判断のポイントは以下になります。

メリット
〇リソースの追加が容易（ハードウェアの将来的なスペックを考える必要がなくなる）
オンプレミスの場合は3-5年後に必要になるリソースを計算してハードウェアの選定・導入を進める必要があります。
プロダクトの急速成長などでリソースを追加する場合、早くとも1,2カ月の時間が必要になります。
エン転職は成長中のプロダクトで、急速なアクセス増加にも対応可能な環境が求められていました。

〇ハードウェア障害の対応などの現地作業が不要になる
数年間利用することになるのでバッテリーやディスクの障害は必ず発生します。
機器（部品）交換は迅速に行う必要があり、最優先での対応を求められることも多いと思います。
弊社の場合では、データセンタは遠方にあるため、現地へ向かうだけでも結構なコストになっていました。

〇新サービスの導入・連携が容易
エン転職への新機能の追加・改修でクラウドの新サービスを利用したいケースが考えられました。
移行検討時点でもCDNや検索エンジンサービスを利用していたため、今後益々利用が増えることは明確でした。
マネージドサービスを利用することで、自前で設計構築するよりも素早く導入可能で、リリーススピードの向上にも繋がります。

デメリット
〇ランニングコストの増加
あとで詳しく記載しますが、リホストによる移行を考えていたため、費用はオンプレミスに比べて高くなってしまいます。
ただ、移行後の対応でオンプレミスより下げることは可能なのでネックにはなりませんでした。

〇カスタマイズが難しい
インスタンスのスペックが決められていているため、要件にピッタリのインスタンスは用意できません。
特に最大スペックでも要件が満たせない場合には、構成変更を検討する必要があります。

〇セキュリティ要件
会社によっては個人情報を含むDBサーバをAWS上に置いてよいのかが問題になるケースがあります。また、IDS/IPSの利用もできません。
弊社の場合、DBサーバをAWS上に移設することは問題ありませんでしたがIPSを利用していました。
エージェント型のソフトウェアを導入することも検討しましたが、オンプレミス環境と違いアップデートが容易に行えるため、
適宜アップデートを実施することで回避することとしました。

クラウドベンダーの選定

AWS,Azure,GCPのどれを選ぶのかも重要なテーマでした。
それぞれの利点を考え、最終的にはAWSを利用することに決定しました。
ある程度リスクを取れるプロジェクトだったらGCPを選んでいたかも知れません。

〇AWS
シェアNo1で圧倒的に資料が多いです。社内に知見のある者も多く、相対的に学習コストが低くなります。
何か不具合が発生したとしても、調べれば大体解決策が見つかります。

〇Azure
移行対象の大部分でWindowsを利用していたため、サービスとの親和性は一番高かったです。
ただ、将来的にWindowsからLinuxへの移行も考えられたため見送りとなりました。

〇GCP
googleのインフラが利用でき、技術的に一番モダンな実装が可能なイメージです。
当時、コンテナ化が進んでいく中でkubernetesがサポートされているのも大きかったです。
ただ、資料が少なく、実装や障害対応時の不安が拭いきれませんでした。

移行方針

安全第一でリスクを減らすことを最重要視しました。
サービス稼働率やコストダウンを優先する場合には、手順が大きく変わってくると思います。
大きく分けて以下の2点が論点になります。

〇段階的に移行を行うのか、全て同時に移行するのか。
複数回メンテナンスが入るより、長時間でも1回のメンテナンスで終わらせる方がサービスへの影響が少ない点、メンテナンスの調整にかかるコストが大きい点、部分移行による問題が発生するリスクなどを考えて全て同時に移行することを選択しました。

〇リホストのみ実施するのか、リファクタリングまで実施するのか。
リファクタリングまで実施することでランニングコスト面でもメリットを出すことができますが、改修コストが大きくなり、問題発生のリスクが大きくなります。
基本的にはリホストのみの行い、安定稼働が確認できてからリファクタリングを実施することとしました。
※リホスト …ハードウェアのみ移行すること
※リファクタリング … クラウドベンダーが提供するサービスを利用できるように、構成の最適化を図ること

サーバ構築と移行作業

クラウド上に構築を進める中で、大きめの変更を加える必要があったポイントをピックアップして記載します。

〇ネットワーク
プロダクトごと移行しますが、オンプレミス環境との通信がゼロになる訳ではありません。
オンプレミス環境との、セキュアで帯域保障された回線が必要でしたのでDirect Connectサービスを利用しました。
切替当日は大量のデータ転送を行うため、一時的に契約帯域幅を増幅しました。

〇ドメインコントローラ
オンプレミス環境とクラウド環境で独立した環境にすると、アカウント連携が反って大変になります。
ドメインコントローラに関しては、オンプレミス環境とレプリケーションを構成し、切替当日にFSMOの移行を行う形にしました。

〇ファイルサーバ
EC2上に冗長性やパフォーマンスを維持したままファイルサーバを構築するのは難しいです。
S3への移行を行い、接続するアプリ側の改修をすることとしました。
同期を定期的に実施して、切替当日の同期に掛かる時間を短縮しました。
※現在はAWSのサービスが増えているため、そのまま移行も可能かも知れません

〇バックアップサーバ
ファイルサーバと同様、EC2で構築するのは難しいのでS3上にバックアップを取得するように変更しました。

〇データベースサーバ
可能であればRDSに移行を考えていましたが、機能が制限されていることもあり機能要件を満たせませんでした。
EC2上に構築することにしましたが、ディスク性能に不安があったため、ディスク分割を行いIOPSを分散させました。
マイグレーションを構成し、当日のメンテナンスを短くすることも考えましたが、マイグレーションの構成にメンテナンスが必要になる点と、安全性を一番に考え、フルバックアップからリストアする形に落ち着きました。

まとめ

オンプレミスからクラウドへの移行でどこに注意を払い、どのように進めたのかをお伝えしました。
現在はリファクタリングを行い、コスト面でもメリットが出るモダンな構成へのシフトを進めています。

デジタルプロダクト開発本部では一緒に働く仲間を募集しています。
この記事を読んで、少しでも興味の沸いた方はぜひ下記募集ページをご確認ください。