大規模ゲームサービスを運営する3社が語る、複雑・大規模なWebサービスを支える技術とは?
2017年2月7日19時30分より、「【DMM GAMES主催!】複雑・大規模webサービスを支える技術勉強会」が開催されました。
募集の開始から330名を超える申し込みが集まり、増席を重ねたものの参加は抽選となりました。当日は当選されたおよそ250名が参加。会場もパンパンです!
DMM.comラボが主催する本イベントでは、大規模なサービスを運営する企業のみなさまがご登壇。サービスに技術をどのように落とし込んでいるのか、裏側ではどのような仕組みが走っているのかなどをご共有いただきました。
当日の登壇者とテーマは次の通りです。
「DMMのゲームプラットフォームで利用している技術やシステム構成、レガシーシステムが抱える課題、解決のためのシステムリプレイスの進め方」
株式会社DMM.comラボ 久保田亙さん
「大規模になったサービスでやるべき基本的なこと」
株式会社ミクシィ 清水勲さん(@isaoshimizu)
「AWS×PHPでの高信頼かつハイパフォーマンスなシステム」
株式会社サイバーエージェント 伊藤皓程さん
それでは内容をご紹介します!
DMMのゲームプラットフォームで利用している技術やシステム構成、レガシーシステムが抱える課題、解決のためのシステムリプレイスの進め方
1人目のご登壇は、株式会社DMM.comラボの久保田亙さんです。
久保田亙(くぼた・わたる)/株式会社DMM.comラボ。東京学芸大学教育学部卒。中規模ソフトウェアハウスにて製造業向けでの勤務後、2015年にDMM.comラボ入社。浦和レッズ好き。
︎■失敗から見えた3つの課題
「DMM.com」では、40以上もの幅広いサービスを展開しています。久保田さんが担当するのはそのひとつである「DMM GAMES」。
2017年1月末現在、「DMM GAMES」は、サービス単体で1800万人を超える会員数を誇り、PCをメインにスマホ、フィーチャーフォンの3デバイスへオンラインゲームを提供。「艦隊これくしょん 」「刀剣乱舞」を始め、数多くの人気作品をこれまでに配信しています。
それらの様々な人気ゲームの提供を支えているのが「DMM GAMESプラットフォーム」です。「DMM GAMESプラットフォーム」は、プロフィールやポイント、課金システムなど共通の機能を管理しています。
「DMM GAMES」の歴史は5年前に始まりました。そして、会員数の増加に応じてサーバー数も倍々で増加。キャッシュを導入・増設したり、データの持ち方を「NoSQL」へ変えたりする「負荷対策」、「Hadoop」の導入による「解析対象データ量の増加」に注力していきました。
現在のシステム構成では、「DMM GAMES」が使用しているサーバー数は900台にもおよびます。内訳はWeb/Appに500台、DB に150台、「Memcached 」に30台、「Redis」に 50台、その他が170台となっています。
「DMM GAMESプラットフォーム」には1日を通して負荷があります。負荷状況は、通常時の最も低いときでも1600アクセス/秒程度。イベントなどのピーク時となると、10万アクセス/秒を記録します。
久保田さんは、この規模になる前、つまり「DMM GAMES」のサービス拡大時に失敗した例を振り返ることで、現行システムが抱える下記3つの課題が見えてきたと話します。
・「DMM GAMESプラットフォーム」の処理能力
→ もともと「DMM.com」のひとつのコンテンツから派生して拡大してきたため、大規模に適したアーキテクチャなのに疑問が残ります。
・「DMM.com」本体との密結合
→「DMM.com」が止まってしまえば、「DMM GAMES」も止まり、「DMM GAMES」が重くなると本体も重くなるという状況。変更時の影響範囲もわかりづらいという問題がありました。
・5年間溜め込んだ技術的負債
→ 「使ってないと思われる処理」や「依存関係を整理して分割したい巨大処理」があっても、怖くて消せない状態でした。
■リプレイスが急務!
この3つの課題に対処するために、現行システムに手を加えるより、「Front」「Application」「Backend/Data」の3軸から全面的にリプレイスのほうがコストがよいとの結論を出します。
リプレイスは、まずApplication、すなわちゲームとの関連が強いレイヤーから開始されました。その際の方針は、ユーザーに影響を与えないで実行するために「システムを止めずに移行」することと、疎結合を目指した「マイクロサービス化」の2つ。
「システムを止めずに移行」の方針は、機能単位でサブドメイン化するなどの工夫をすることで実現。「マイクロサービス化」に関しては、「DDD(ドメインドリブンデザイン)の思想を取り入れたオペレーション設計すること」、セキュリティ面や性能面を鑑みて「環境を最新化すること」、開発手法に「アジャイル、スクラムを積極的に導入すること」で対応します。
現在もこのリプレイスを進めている最中ですが、「DMM GAMES」は徐々に疎結合に移行している段階です。最終的には、DMM本体からは完全に独立していきます。
■リプレイスをして苦労したこと、良かったこと
リプレイス開発を進めていくには既存仕様の確認やテストなどの苦労が多く伴い、社内でも対立がしばしば起こったと久保田さんは説明します。例えば、
・ORマッパー派と反ORマッパー
・Joinの数はどこまでがOKか?
・IDE派とエディタ派
・大クラス主義と小クラス主義
などが挙げられます。
その一方でメリットも多くあり、久保田さんは次の4点を紹介します。
・品質を担保する仕組みが新たに導入でき、レビュー、テストのプロセスが定着した
・仕様、システムの可視化が進んだ
・疎結合となったため、ライブラリなどのバージョンアップが容易になった
・変更のコストやさまざまな制約から自由になり、新しいチャレンジもしやすくなった
最後に「『事業が拡大しているときこそ先を見据えるべき』という教訓をリプレイスという機会から学びました。これからも新しいことにどんどんチャレンジしていきたいです」と久保田さんはまとめました。
当日のスライドはこちらに公開されています。
次のページ :
大規模になったサービスでやるべき基本的なこと