※こちらは先日実施された DeNA インフラエンジニア / SRE MEETUP で話した内容を Blog 記事化したものです！

モバゲーをクラウド移行した際の方針や工夫、解決した課題について三浦から紹介します。

はじめに自己紹介からさせていただきます。私は2008年にDeNAに入社し、開発とインフラを約6年ずつ経験してきました。いまはMobage、Anycaなどのサービスを運用管理するインフラチームのリーダーを務めています。

移行の方針について触れる前に、Mobageについて簡単に紹介します。

今回クラウド移行したMobageは、SNSやゲームプラットフォームを提供して、今年で16年目になります。ガラケーからスタートし、PC、スマホ、アプリでサービスを提供してきました。スライドに挙げているものは全体の機能の一部で、様々な機能を有しています。

Mobageのインスタンス数は約2500、サーバーは500種類以上です。 Webがおよそ100種類、DBがおよそ260種類あります。Web、DBで利用しているミドルウェアはApache、Nginx、MySQLを主に使っています。

クライアントから見ると、WebとDBはシンプルな構成です。ただそれを支えるためにバックエンドには様々な用途のサーバがあります。アバターを表示するための3Dレンダラーや、内製のメール配信daemonであるmobamail、ゲームランキングを集計・結果を返す用途のサーバもあります。

ここまでで長く運用してきたこと、色々な機能を実現するためにサーバの種類が多いことを感じていただけたと思います。

ここからが本題です。 実際にサービス移行時の工夫、苦労したことを紹介します。

技術負債の返済としては3点紹介をします。 CentOS > Ubuntu、system Perl > perlbrew、bind > unbound への切替です。

CentOSからの切替に関しては、セキュリティ事情もあり古いOSから脱却を考え、Ubuntuへの移行を決めました。 アプリケーションを一から動かせるまで持っていく機会はなかなかないので、インストールするパッケージを断捨離して、サービスに必要なものだけに整理しました。 数百のパッケージがありましたが、Ubuntuのデフォルトパッケージを利用、問題があれば追加することで、数十のパッケージの追加で済みました。 次にOS依存箇所の洗い出し、これは実際にやってみてわかったことですが、アプリケーション内にOSに依存するような箇所が意外とあることがわかりました。 簡単なところだとコマンドパス指定、少し珍しいところだとOSデフォルトのユーザの uid, gid が個別指定されているところがあり、同時に改修も行いました。

次がperlbrew化ですが、これが非常に大変でした。 system領域からのPerlの切り離し目的で行いましたが、400以上のパッケージ、古いOSに入っている特定バージョンのミドルウェア依存、コンパイラのバージョン差異によるビルドエラーなどなど依存関係が複雑で解決するために最も時間がかかったところでした。 perlbrew化したことで、アプリケーションと同一の管理方法に揃えることができました。

unbound 導入については、外部への名前解決を内部DNSサーバから分離するという目的で行いました。元々DNSサーバは前段にbind、後段にMyDNSという構成を取っていました。 本の構成ではDNSが詰まると影響が全体に及んでしまうため、構成変更をしたいと考えていたポイントでした。今回機能を引き離せたのは非常に大きな変更でした。

構築時の工夫については、全ての情報を集約して一元管理するようにしました。これは本当にやってよかったと感じたことです。構築担当者目線で、このシートを見れば構築に必要なパラメータが全てわかる、あれこれ調べたりする必要がない。という状態を作りたかったからです。 他にも LB を構築するコマンドをオンプレの config から自動生成するようにしたり、 進捗状況を可視化して状況がすぐにわかるようにしたりと工夫して、時間をかけたい構築に集中できるようしています。

もう一つ工夫した点は、構築・サービスインのコード化です。 オンプレ時からOS installやNW設定をするためのコマンドを用意してコード化していました。これをAWS API利用して同一のことを実現できるようにしました。Chefでのプロビジョニングも同様です。 移行後にオートスケーラーを導入することを見据えていたため、これらのコマンドをラッピングしたツールも準備しました。この準備をしていた結果、いまはwebにはオートスケーラーを導入して運用を開始しています。

安全な切替の工夫についても三点挙げています。 一つ目のテストは当たり前ですが、重要なことでした。QAメンバー、開発者目線、インフラ目線で2ヶ月以上をかけました。実際にここで多くの問題をあぶり出すことができ、QAメンバーにはとても感謝しています。

二つ目はfailbackを前提とした切替です。 AWS切替後にどんな問題が起こるかわからない、備えることが重要だと考え、移行後もなにか問題があればオンプレ環境がすぐに戻せる状態を維持してきました。Memcachedのデータをawsとオンプレで同一に保つことや、MySQLのレプリケーションを継続していました。

三つ目はサービスインのトラフィックコントロールです。 サービスを低い割合で投入して、問題ないかを確認、問題があっても影響を最小化するよう工夫していました。Route53のWeighted Round Robinだったり、内部DNSで利用しているMyDNSでも重み付けをして少しずつAWSにトラフィックを寄せていきました。

移行時の苦労については、MemcachedやRedisが突然サービスアウトされるということが起こりました。直前で触れたとおり、徐々にサービスインしていたにも関わらず本当に突然でした。

サーバリソース上は問題がなく、すぐにテクニカルサポートに連絡して原因究明を図りました。原因はセキュリティグループを利用していると、インスタンスタイプごとにConnection数の制限がありそれにかかっているということでした。この制限になったことはこれまでになかったらしく、非常にレアケースだったようです。

原因がはっきりしたことで、サーバ増設、インスタンスタイプ変更、また事前検知目的でカナリアも導入しました。これはあくまでワークアラウンドとしてやったことで、今後はセキュリティグループを利用しない構成にすることで根本解決を図りたいと考えています。

大きなシステム移行を終えて一段落しましたが、AWS上での運用はこれからです。Mobageは台数も多く、大きなコストチューニングの余地があると考えています。今後の注力ポイントはコストコントロールで、特にインスタンスサイズの適正化、オートスケーリング導入、スポット導入に力を入れて、システム・時間コストの両方を減らしていこうと考えています。

この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！

また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！

Follow @DeNAxTech