オンプレミスで動いていたサービスをAWSに移行した話
井上 耕輔
こんにちは。フルスタックエンジニア(自称)の井上です。
今回は、とあるサービスをオンプレミスからAWSに移行した事例をご紹介します。
経緯
リクルートライフスタイルでは、いくつかのオンプレミスおよびクラウド環境からサービスの特性に合わせて適した環境を選択しています。
今回AWSに移行したサービスは、元々新規事業向けに提供されているオンプレミス環境で運用されていました。
しかしサービスの伸長によりトラフィックも増加傾向にあり、近い未来に性能上の問題が発生するのは明らかで、
またサポート体制なども含めたサービスレベルとしても要求されるものと乖離が起き始めていました。
そのような状況で本格的にインフラ移行の検討を開始しました。
移行先の選定
移行先を選定する際、主に以下の点を重視して検討しました。
- 今後の成長を見越して素早く、かつ継続的にスケールできる
- 少人数体制でも効率的に運用が可能で、スケールした状態でも運用負荷が増えない
- エンジニアが試行錯誤しやすく、開発スピードを維持できる
- 現状からコスト効率が大きく悪化しない
移行先の候補もいくつかありましたが、少人数の開発体制でスピードを維持しつつサービスを運用していくためには最も適していると考え、AWSに決めました。
リクルートライフスタイルのAWS利用
リクルートが運営するサービスとしてセキュリティなど一定の要件を満たした状態で、サービス運営できるように以下のような機能を持った共通基盤が整備されています。
- ID管理
- WAF
- メールGW
- ログ基盤
- 監視
- CI
- etc.
これにより各サービス担当のエンジニアは担当サービスの範囲に注力できるため、素早く安全な環境構築が可能となっています。
また共通基盤チームはサービスデスクとしての機能もあり、困ったときは随時相談できるため、AWSに不慣れなエンジニアでも（ある程度の環境構築スキルがあれば）構築が進められます。
構成
Ruby on Railsで構築された一般的な構成のサービスです。
構成図では簡略化していますが、もちろんMulti-AZで冗長化されています。
スケジュール
今回2ヶ月という短期間で完全移行することに決めた最大の要因は、サービスの成長を加速させる機能開発やUI/UX改善を可能な限り止めないようにするためです。
成長期のサービスはナマモノなので、成長のための土台作りで成長のための施策を止める矛盾は極力避けたいと考え、以下の方針で移行計画を立てていきました。
- 運用を効率化しつつ拡張性を維持するため環境構築の自動化を進める
- 短期間で確実に移行するため、アプリケーションの改修は最小限に抑える
実際にアプリケーションに手を入れたのは、ファイルストレージをNFSからS3に変更するための対応くらいでした。
(といってもNFS前提で組まれていたため対応箇所はそれなりにありましたが)
またデプロイもS3経由に変更したため、同時にデプロイスクリプトを作成しています。
実はAWS移行を機会にDBMSをMySQLからAuroraに変更することや、CloudFrontを利用して静的リソースの配信高速化を行うことも考えていました。
しかしリスクは高く無いとはいえ、検証中に何かしらの問題が発生した場合に原因の切り分け難易度が上がる点や、スケジュールを圧迫する可能性を考慮して今回のスコープから外しました。
社内・社外ともに複数のシステム連携を行っていることにより、不具合発生時の影響範囲が広く、確実に移行を成功させることを優先するための判断でした。
結局、連携機能の一部で構成変更に起因する不具合が発生し、移行直前まで対応に追われたことを考えると、良い判断だったのかなと思います。
得られたもの
移行時点で約2倍のトラフィックを捌けることを期待していましたが、（少々インスタンスタイプの調整が必要だったものの）ほぼ想定通りの性能が出ており、さらにインフラ運用に関わるコストも削減することができました。
何よりも今後の拡張性が担保できたことで、継続的に安定したサービス運営が可能になりました。
また、これまで不可能だった本番相当の構成で負荷試験を行うことができるようになり、安心して新機能のリリースに望むことができるようになったのも大きなメリットの一つです。
今回はスコープには入れなかったのですが、オートスケールなどマネージドサービスの利点を取り入れることにより、サービス運用をさらに進化させていく予定です。
まとめ
順調に移行を進めることができた要因として、リスクを最小限に抑える方針を取ったことも1つです。
しかしそれ以上に、エンジニアがアプリケーションだけでなくミドルウェアまで把握していたこと、
また別の視点でビジネスモデルや運用フローの理解があったことが重要だったと考えています。
これにより取捨選択が迫られたときに、サービスとしての優先度という軸をぶらさずに判断することができました。
「サービスに寄り添いながら、サービスとともに成長していける」これがフルスタックエンジニアとしての一つの選択肢ではないでしょうか。