ミクシィのサービスと技術スタック(開発環境)についてまとめてみた　その2

2018年10月に公開した「ミクシィの技術スタックについてまとめてみた」。こちらの記事ですが、SNSやブログ等で反響をいただきました。他の企業さんも、ここ数年で自社の技術スタックの公開する傾向が進んだかと思います。

……「で、第二弾はないの？」という声をチラホラいただきましたので要望にお応えする形で、第二弾を公開。ミクシィを代表するサービス群はもちろん、updateされたサービス、新規開発中のサービスまで、各サービス/事業部で、開発言語・インフラ環境・デプロイツールなどでまとめてドドーンと公開します。

※サービスやプロダクトに該当しないケースは、各事業部で採用している技術を紹介します
※2020年9月30日時点での情報です
※記事ボリュームがありますので、可読性を考慮し2ページに分割しております

【サービスおよび、技術スタック一覧】

目次
モンスターストライク
TIPSTAR
コトダマン
みてね
minimo
SNS mixi
FINDJOB!
6gram
Romi
デジタルエンターテインメント本部新規ゲーム開発

※次ページ　事業部・部門

サービス・プロダクト
※サービス名の()はサービス開始時期

モンスターストライク　(2013年10月～)

サービス/事業部の取り組み

モンスト事業本部の開発室では、世界累計利用者数5,300万人を突破した「モンスターストライク」を中心に様々なサービスを開発している部署です。サーバーサイドでは、オンプレミスに加え、国内外さまざまなクラウドを使用して運用を行っている点が大きな特徴です。

技術スタック

TIPSTAR　(2020年6月～)

サービス/事業部の取り組み　

「TIPSTAR」は、競輪を取り扱ったライブ映像を毎日配信して有料はもちろん無料のコインでも遊べるサービスです。競輪のスポーツやエンターテインメントの要素にフォーカスし、新しい映像コンテンツ、遊び方を提供していくサービスとなっています。サービス想定規模が大きく特定時間にスパイクが発生する要件が見込まれたので容易にスケールできる形と非同期で処理ができる形にしていきました。PFがweb, ios, androidとある中、OpenAPIにてAPIを定義することで各PFで再利用可能な物を用意し効率化しています。

技術スタック

コメント

マネージャー　川又

プロジェクトのリリース計画がコロナなどによる情勢の変化により必要とされる機能やリソースなど大幅な変更がありました。そのため、リソースの再調整をメインとしてpubsubを利用する箇所を増やし非同期で処理できる箇所を増やしスケールしやすい形にアーキテクチャを一部変更するなど行いました。

コトダマン　(2018年4月～　※パブリッシャー変更は2019年11月)

サービス/事業部の取り組み　

コトダマン事業部では「共闘ことばRPG コトダマン」の開発・運用を行っています。『コトダマン』は2019年、パブリッシャー移管を行いXFLAGの一員となりました。言葉を作ってコンボを決める他にはない言葉合わせRPGです。

技術スタック

技術的課題

プロジェクト移管

『コトダマン』は2019年11月にパブリッシャー移管しました。『コトダマン』自体は2周年を向かえています。そのためサービス運用をしながらインフラの移行を行う必要がありました。移管後も負荷が増加しているため、運用フロー見直しやシステムの改修を行っています。

課題解決について

運用タイトルかつ移管されたタイトルのため、絶賛全容把握中です。約1年運用し、今後はゲームの要でもあり、プロジェクト全体に関わるデータやアセットの運用フローを改修していきたいと考えています。

みてね　(2015年4月～)

サービス/事業部の取り組み　

「みてね」は、子どもの人生を丸ごと残せるアルバムを作るというコンセプトで、写真を整理する時間が無いパパやママ、ITに不慣れな方でも使ってもらいやすいサービスを目指しています。

技術スタック

コメント

開発スピードの観点でもっとも高速なもの、継続的な品質管理・向上が可能な開発環境。ネイティブクライアントにおいては、ユニットテストが記述しやすく、常に品質が担保しやすいアーキテクチャを採用。また、できる限り最新の技術を利用することで開発をより高速に・便利に、またエンジニアのモチベーション向上の観点でも、常に新しい環境へ移行する時間を確保するようにしています。
インフラにおいては、コストの観点で最適なもの、ユーザーへのデメリットが最も減らせるものとしてKubernetesを採用してAWS EKSを利用しながら移行を進めている。組織同士の疎結合化は理想。全体として組織における「チーム」がそれぞれの判断で最適・最速の決定を下し、自律的にアクションが取れるような、アジャイルソフトウェア開発体制・それを支えるアーキテクチャや技術スタックを常に模索していきたいです。

マネージャー　酒井

minimo　(2014年1月～)

サービス/事業部の取り組み　

「minimo」は、消費者ユーザーにとっては自分にぴったりのサロンスタッフをお得に探して予約できるアプリです。美容師、ネイリスト、アイデザイナーなど美容サービスを提供側のユーザーにとっては、自分のスマホさえあればすぐに集客を始めることができるアプリです。

技術スタック

コメント

マネージャー　尾関

Bitriseの導入背景について。アプリで使用する CI/CD サービスを探していた際に、iOSの証明書周りの管理がしやすいこと・実行内容を直感的に記述、管理することができたことが導入の決め手になりました。

SNS mixi　(2004年2月～)

サービス/事業部の取り組み　

「mixi」は、最大時には数千万規模のユーザーが利用していたプロダクトで、16年以上の歴史があるSNSです。日記やコミュニティ、足あとなどSNS機能のほか、ソーシャルボタンやゲームプラットフォームなど外部連携機能をもち、独特なコミュニケーションの場を提供しています。

技術スタック

コメント

サービス発足当時からのLAMPスタックを時代に合わせて進化させてきた。インフラ面は保守性の向上のためAWSに移行し、マネージドサービスで独自実装を代替。クライアントの技術はユーザーデバイス環境に合わせて進化。

マネージャー　加藤

技術的課題

1.データセンターを使っていて維持管理コストが高かった
・サーバーの導入や故障対応などにコストがかかる状態だった

2.MySQLをEC2で運用していて維持管理コストが高かった
・不定期なサーバー再起動の対応コストが高かった
・OS管理のコストが高かった

3.クライアント・フロントエンド構成のアップデートが停滞していた
・利用しているバージョンが古かった
・新しいソフトウェアなどの導入が遅れていた

課題解決について

1.AWS移行（2015〜2016）
・マネージドサービスが利用できるように
・サーバーの導入や故障対応のコスト激減
AWS 導入事例

2.DBをMySQLからAuroraに（2018〜2019）
・各種コストが激減
mixi運営者ブログ

3.クライアント・フロントエンド構成のアップデート（2018〜2020）
・バージョンアップを実施
・各種ソフトウェアの導入を行い、効率をよくした

FINDJOB!　(1997年11月～)

サービス/事業部の取り組み

IT・Web業界に特化した有名企業からスタートアップのデザイナー・エンジニア求人を中心に、業界最大級の求人を多数掲載中。独自のマッチング機能であなたに合う企業をお届け。選考前から企業の評価やメンバーが分かるからこそ、不安のない仕事探しを実現します。　

技術スタック

コメント

フロントエンドとバックエンドを分離させた開発フローによって、スピーディな開発・改善サイクルを回せるような技術スタックを目指し、フルリニューアルのタイミングを契機に導入したものです。リニューアル以前の開発では、改善サイクルにおいてフロントエンドがかなりネックとなっていて、逆にバックエンド側のロジックやデータベースなどはコードの寿命が長く使われているものが多い傾向にありました。そのためフロントエンドとバックエンドでは採用目的が多少異り、フロントエンドはスピーディに時代のトレンドを取り込んだデザイン、UIが求められますので、新しいフレームワークを取り込みやすいようにAPIでバックエンドと完全に切り離す設計に。バックエンドは一度作ったAPIはUnitTestによって常に品質を担保し高い品質を保つ事を目的として開発を進めています。

マネージャー　佐々木

技術的課題

• フルリニューアルプロジェクト

従来のシステムはバックエンド・フロントエンド・ミドルウェア・データベース共に老朽化しており、開発コスト、メンテナンスコスト、インフラ運用コストなどが重くなってしまっていたため、システムを全面的に刷新するプロジェクトが始まりました。インフラの問題点としては従来のオンプレミス環境をベースとしたシステムであったため、現代のクラウドシステムでの恩恵を受けることができずAWS上で稼働してはいるものの、内情はオンプレミスでの運用負荷と同様な負荷がかかっていました。本来ならばマネージドサービスを利用すると運用負荷がほぼゼロの状態になるデータベースや、メディアファイル管理、全文検索サーバ等、またオートスケールのような負荷対策などもマネージドサービスがあるにもかかわらずAWSの恩恵を受けることができませんでした。アプリケーション側での問題としては数年に一度訪れるUI/デザイントレンドの刷新を必要とされますが、従来のSSRなWebシステムで徐々に拡張されたシステムのため、UIを少し変えようにもPerlの実装力が必要になることも多く、また歴史のある巨大システムであるため各サブシステム事にその時代のフロントエンド技術を利用しており改修に必要なスキルが機能ごとに異なっている状況で、改修するエンジニア・デザイナー共に非常に高いスキルと歴史的知識が要求されるものでした。

課題解決について

現状考えられる安定していて、かつ運用コストが減るものをベースに技術スタックを決めていきました。

1.コンテナベースのインフラに移行

手動で手順書からプロビジョニングしていたものを、Docker、Docker Composeでのコンテナ環境に移行しました。これによってAWS ECSの恩恵を受けてサーバオートスケールや、自動デプロイ、ブルーグリーンデプロイ等に適合することができ、ワンクリックで安全なデプロイ・ロールバックが可能になりました。また、開発環境、検証環境などの構築も一瞬で用意が可能。Dockerfileを毎日CIでビルドすることでミドルウェア周りのトラブルも未然に防ぐことが可能です。

2.マネージドサービスをどっぷりと使えるように

使いたくても使えない状態でしたが、技術スタック刷新したことにより、各種マネージドサービスから最大の恩恵を受けられるように改善しました。

3.フロントエンド

フロントエンドは流行り廃りが激しいため、数年ごとに訪れるデザインリニューアルの際にも作りやすいように全部Vue.jsに統一して開発を進めました。開発進行中における不具合の数もjQuery等の手続き型UI開発とくらべて宣言型UI開発では不具合の件数が格段に少なくなりました。しかしスタイルに関する不具合はまだ多発するので、まだまだ精進が必要です。

6gram　(2019年12月～)

サービス/事業部の取り組み　

6gramは、アプリ上でカードを発行し、チャージして使うウォレットサービスです。いつもよりもちょっと便利に、みんなで楽しく使うことができます。

技術スタック

Romi　(2020年5月～)

サービス/事業部の取り組み　

Romi事業部では、新規事業として、人と会話ができる家庭用会話ロボットを研究開発しています。スマートスピーカーなど世の中の多くの会話システムは、便利な機能を実現するための手段として会話を使います。一方、私達は便利な機能ではなく、雑談的な会話をして情緒、感情的なニーズを満たすことを目的としています。これはとてもチャレンジングな課題で様々なアルゴリズムを組み合わせて検証を行っています。

技術スタック

技術的課題

1.飽きない自然な会話

2.レスポンスタイムの改善

3.音声認識精度の改善

課題解決について

1.飽きない自然な会話
・ビームサーチによって「最も良い発話」を選ぶのではなく TopP/TopK アルゴリズムによって、「悪くない多様性豊かな発話」を選ぶ
・任意長の過去の発話を発話生成に使えるモデルの開発
・ユーザーの性別など、ユーザー属性に応じた “condition” を導入する
・ユーザーの好みなどを抽出する仕組み（NLU, 現在開発中）

2.レスポンスタイムの改善
・データベースアクセスキャッシュ
・Transformerモデルの推論時の推論途中結果のキャッシュ
・Romiが応答をサーバーに投げているときに上を向くなど UX による体感テンポ感の改善

3.音声認識精度の改善
・ビームフォーミングの角度調整他

デジタルエンターテインメント本部新規ゲーム開発　(??年??月)

サービス/事業部の取り組み

デジタルエンターテインメント本部内で新規モバイルゲームの開発を行なっています。社内の開発ノウハウを生かしながらスピード感を持って開発を進めつつも、ゲームのサーバーサイドでは社内で初めてGCPを採用するなど多くのチャレンジを行なっています。プロダクトの詳細をお伝えできないのが残念ですが、みなさまにお届けできる日を楽しみにしています。　

技術スタック

コメント

サーバーエンジニア　野田

Elixir は既存タイトルでの採用実績があったため、資産を再利用し素早く開発を進めるために採用しました。また、GKE、Cloud Spanner 等のマネージドサービスについてはどちらも運用・開発コストを削減し少人数のチームで生産性の高い開発を行うために採用しています。

技術的課題について

Elixir + Cloud Spannerの採用

ユーザーデータの強い整合性を担保しながら開発・運用コストの削減を行うため、私たちのタイトルではCloud Spannerを採用することにしました。ですが、私たちがサーバーアプリケーション開発に利用している Elixir には一般的な Cloud Spanner ライブラリが存在しませんでした。また、Cloud Spannerの採用を決めた時点ではすでにアプリケーション開発が進んでおり、RDBを利用する実装が入った状態でした。

課題解決について

ライブラリに関しては社内で内製するという選択をしました。内製にあたり開発本部という全社横断の技術支援部署に協力していただき、ライブラリの開発を担当していただきました。その上でアプリケーション側でのニーズや具体的なI/Fを頻繁に相談しながら開発を進めることで、開発中のアプリケーションの Cloud Spanner移行を実現しました。