反省点は事前の洗い出しとテスト項目の不足　DMMがオンプレからAWSに移行したときの苦労

オンプレミスのオンラインサロン事業部が抱えていた課題

仲里新吾氏：ここからは私、仲里から発表します。題材は「オンプレ（オンプレミス）環境からクラウドへ」です。はじめに軽く自己紹介をします。DMM入社後、水の販売を経て、出会いサービスの担当。それから競輪などのサービス担当を経て、現在はオンラインサロンのバックエンドに参加しています。

今回のトピックですが、まずはじめにクラウド移行の目的、そして移行内容、これからのこと、最後にまとめとなります。

まずオンラインサロンで抱えている課題です。担当しているサロンサービスでは、システム面でさまざまな課題を抱えていました。まず1つ目は拡張性。サーバーの台数やスペックを容易に増減できないという状況でした。

DMMはオンプレをまるっと用意していて、拡張の際は人依存で対応してもらうなど、安いメリットもあったので、そこはトレードオフとの関連性ではあるんですが、現状ではちょっと拡張性の悪い状態でした。

2つ目に監視です。アクセスログを見る場合は、サーバーなどに直接入って確認をしていました。3つ目に継ぎはぎな設計です。サービスリリースからさまざまな機能追加をやってきましたが、その都度選択していた結果、継ぎはぎな設計になっている部分があり、柔軟な設計が難しくなっている状態です。

今回の対象は、拡張性および監視の部分です。Lift&ShiftのLiftの部分の話です。先ほど挙げた問題点があり、不具合や案件の対応に時間がかかるなどの負債がありました。そこでまずは柔軟性と監視部分の強化のため、オンプレからクラウドへの移行案件が立ち上がりました。

移行プロジェクトチームは部の垣根を越えた7名で構成

移行案件のチーム体制は、私たちが参加しているサロン事業部から開発メンバー4人、SRE部から1人、インフラ部から1人です。ここでDMMでのSRE部とインフラ部とは何かを少しだけ紹介します。

SRE部は、事業部に寄り添ってサービス開発を支援する部署です。AWSの構築や、それに関連する各種運用整備の場面で、今回のAWS移行案件でも多く支援をしてもらいました。

インフラ部は、DMMのシステム基盤を構築運用している部署です。今回サロンでは、オンプレをまるっと管理してくれていました。この7名体制で移行案件に取り組みました。

スケジュールは、6月から12月半ばまでの半年間、移行案件に費やしました。当初の予定では3ヶ月あればできるかなと思っていたのですが、実際に計画を立てて進めていった結果、半年ほどかかりました。

クラウド移行前と移行後の環境の比較

移行前の環境と、移行後の環境を軽く説明します。移行前はWebサーバーや、DB、ファイルサーバーや、メール、すべてをオンプレでまるっと管理していました。

今回はそれらをそのままAWSのほうに移行しました。基盤レベルのものはひととおり移行しましたが、のちほど説明するCloudEndureで移行したとき、VMの中身自体はそのまま流用しています。

各種アプリケーションのライブラリのバージョンなどは現行のままです。その理由は、バージョンアップした場合の影響が大きいからです。バージョンなどはそのままにしていて、これは今後の課題として検討中です。

それぞれをどういうものに置き換えたかですが、DBに関してはオンプレ環境からmysqldumpで、AWSのaurora mysqlに流し込みを行いました。DNSはDMMのDNSサーバーからRoute53。WebサーバーはCloudEndureを利用して、VMイメージごとAWS EC2に移行しています。

画像キャッシュサーバーはVMからS3に変更して、キャッシュサーバーはNginxからCloudFrontへ変更しました。ほかの変更一覧は資料のとおりです。

移行によって拡張性と監視の部分が改善した

今回の移行に伴い、改善したポイントは大きく2つです。1つ目は、柔軟なサーバースペックへの変更。サーバースペックの変更や台数の変更が容易になり、負荷に応じて対応できるようになりました。インスタンスタイプの変更や、オートスケーリングで負荷に合った設定にしています。

2つ目は監視の強化です。オンプレ時代はZabbixを使っていましたが、New Relicに変更した結果、負荷のかかっている処理の調査などが容易になりました。

今回の移行ですが、主に環境をまるっと移行するということで、アプリケーションや、仕様などの変更は行いませんでした。それでも既存への修正が必要な部分が大きく分けて4つありました。

1つ目がIP制限周りです。オンプレ時に許可していたIPを、クラウド移行時にも利用できるようにするという部分です。

2つ目がハードコーディング部分。ドメイン名の部分が一部ハードコーディングされていたので、動的に変更できるように修正しました。3つ目が外部サービス情報です。オンプレで許可していたものを、クラウドからも許可できるように変更しました。

4つ目がデプロイ方法です。オンプレ時はJenkinsを利用していましたが、現在はcircleciを利用しています。

案件を進めるうえで出てきた課題の数は、ざっとですが162個。いくつか紹介すると、デプロイをどうするかなど、利用モジュールの反映方法が決まっておらず途中で決めるという問題が出たり、実際に移行を進めていくうえで、サービスが動かなくなったりしました。この原因は、セキュリティグループの追加が足りなかったというものでした。ほかにも、フレームワークの問題で、想定していた監視ツールが利用できないなど、ほぼ毎日と言っていいほど課題が出てきたので、それらに対応しながら進めていく状態でした。

移行プロジェクトの反省点は事前の洗い出しとテスト項目の不足

今回案件を進めるうえでの考慮すべきだった点、反省点です。1つ目が事前の洗い出し不足が多かった点です。IP許可や移行に関して対応すべきことが途中で出てきて、結果スケジュールが押してしまいました。

2つ目がテスト項目不足です。今回はあくまでアプリケーションの修正は最低限だったため、重要な部分を主にテストしていましたが、機能の細かい仕様の部分で、リリース後に不具合を出してしまったことがいくつかありました。

本番での検証、ステージングとの差分も反省点です。実は一度リリースしたあとに検証で問題が出て、リリースを延期した事実があります。原因は、EFSの遅延の問題だったのですが、ステージングと本番での環境差異から、ステージングでは気づけなくて、本番で不具合を起こしてしまいました。

今回発表した内容は、拡張性と監視のLift部分です。残るShiftのツギハギな設計の部分は、次の発表者の萩原さんがお話をすると思います。

まとめです。システムそのままの環境を移行するだけだと考えていましたが、蓋を開けたら対応しなくてはいけないことが多くありました。やってみないとわからないこともあると思いますが、事前の調査や、チームの認識合わせをはじめに固める必要があったと思いました。

以上をもちまして、発表は終了です。ご清聴ありがとうございました。