社内支援と外販事業、二面性を持つグリー開発本部の立ち位置

大久保：本日は「変わるもの、変わらないもの：OSSアーキテクチャで実現する持続可能なシステム」と題して、大久保と岩井からお話しいたします。どうぞよろしくお願いいたします。

まず自己紹介をさせていただきます。私は現在、株式会社グリーの開発本部 本部長として、グリーグループがこれまでに蓄積した技術ナレッジを社外のお客様に提供する事業を推進しています。

グリーグループはゲーム事業、VTuber・メタバース事業、出版・アニメ業界、マーチャンダイジングなど、エンターテインメント企業として幅広く事業を展開しています。その中で我々は、グリーホールディングス傘下の子会社として、GREE Platform事業とソフトウェア及びシステム開発事業を担っています。

我々が所属する開発本部は、グリーグループの各事業に対し、技術面から横断的な支援を行っています。そこで蓄積された技術を事業部として社外へサービス提供していく、といったサイクルを回しております。

時代に合わせて変化してきたグリーのアーキテクチャ

24時間365日の稼働を支える基本構成

大久保：本日の本題であるアーキテクチャについて、我々は大きく分けてBtoCとBtoBという、2種類のサービス領域に携わっています。

これらは、ユーザーアカウントの作成フロー、サーバー台数の決定プロセス、ソフトウェア選定、システム特性、運用特性が大きく異なります。例えば、BtoCサービスではOSSを多く選定していますが、BtoBサービスではベンダー製のソフトウェアを採用することが多い、といった特徴があります。

グリーのアーキテクチャの基本構成は、主にこういった複数のシステムを有機的に結びつけています。24時間365日の稼働が求められる本番システムでは、CDNと負荷分散機、キャッシュを組み合わせることでDB負荷を軽減し、冗長化されたDBサーバーを構成しています。

周辺を支える共通サブシステムも重要です。決済共通基盤、ユーザー認証基盤、分析基盤、セキュリティ基盤システムに加え、デプロイサーバーやPrometheus/Grafanaを用いたモニタリング環境、カスタマーサポート向けのツールまで、これらを有機的に結合して、グリーのアーキテクチャを形作っています。

オンプレからクラウド、そしてマルチクラウドへ

大久保：弊社のアーキテクチャは、時代ごとの経済条件や技術革新に応じ、柔軟に変遷を遂げてきました。オンプレミス全盛期からクラウド移行期、そして現在のマルチクラウド活用に至るまで、我々は常にリアーキテクチャを積み重ね、インフラ部隊としての知見を蓄積しております。

少し歴史を振り返りますと、オンプレミス全盛期には国内外10拠点以上のデータセンターで、数万台規模の物理サーバーを運用していました。ミドルウェアなども内製し、ユーザー様へ環境を提供していましたが、2016年からのクラウド移行期には方針を大きく転換しました。クラウド事業者が提供するシステムを有機的に結合させ、内製からSaaSなどの外部サービス活用へとシフトし、システムを最適化させてきました。

直近では、プラットフォームサーバーを完全移行するタイミングで、データセンターの解約を進めると同時に、クラウドサービスを有機的に組み合わせたリアーキテクチャにより、現在の事業サービスを支えています。

ここからは、この直近のリアーキテクチャの具体的な内容について、岩井よりお話しいたします。

個別最適化と全体最適を両立させる、組織と技術の「適応力」

事業部横断組織が求められる2つのもの

岩井：ここからは「ビジネスの成長を加速する株式会社グリーの開発本部の適応力」というタイトルで発表いたします。

まず自己紹介させてください。株式会社グリーでシニアエンジニアをしている、岩井良成と申します。19年に新卒で入社し、直近ではグリープラットフォーム事業のクラウド移行や、内製のユーザー認証・決済基盤「Gamelib」のKubernetesによるリアーキテクチャを担当しておりました。

リアーキテクチャの背景についてお話しする前に、弊社の組織背景について触れさせてください。

開発本部は事業部横断の組織として、社内外の多様な事業を支えています。例えば、2024年に20周年を迎えたSNSプラットフォームとゲーム群からなる「GREE Platform事業」、WFSによる「ネイティブゲーム事業」、そして「VTuber事業」などです。そして、社外の事業に対しても、開発本部として技術を提供してきました。

このように多様なグループ会社があり、それぞれの歴史がある中で、「事業部やプロダクトに最適化されたインフラ組織を提供する」をテーマに掲げています。共通の課題に向き合いながらも、多様な組織、文化、事業フェーズへの適応が求められており、プロジェクトごとにスピード感やサポートの粒度を個別に調整しています。結果として、我々には「組織としての適応力」と「技術の柔軟性」が求められているという背景があります。

画一的な設計を避け、事業に最適な責任分界点を定める

岩井：改めて、本日は「組織の適応力」と「技術の適応力」についてお話しします。

まず1点目の「組織の適応力」とは、事業に個別最適化された技術提供です。私たちは、画一的な設計や責任分界は、事業の成長を妨げると考えています。共通部門が各事業部に対して「この構成、この設計でお願いします」と押し付けることは、成長の足かせになりかねません。

そもそも、社内外の多様な事業に対して完璧にテンプレート化された設計は存在しませんし、それを目指すこと自体に無理があると考えています。そのため、私たちは事業の要件に応じて、多様な役割や責任分界点を設定するようにしています。

例えば、利用するクラウドの選定、あるいはオンプレミスという選択肢。また、インフラ領域の変化に合わせて、事業ごとに最適な役割モデルを構築しています。具体的には、環境全体を開発組織とインフラ組織が共に運用するパターンもあれば、コンテナのビルドまでを開発チームで行い、それ以降のプラットフォーム設計をインフラ組織が担うというパターンもあります。

新技術のバックポートが共通化を加速させる

ここまで個別最適化のお話をしてきましたが、当然ながらそれだけでは横断部門としての限界があると考えています。

開発本部では、年間複数の新規プロダクトのリリースと、既存システムの運用を同一のチーム・組織で並行して行っています。そのため、個別最適化を推し進めるほど共通部門としての業務効率は悪化し、結果として全体最適が損なわれ、ノウハウの蓄積や共有が困難になります。

そこで私たちは「事業に対しては柔軟性を持ちつつ、内部では全体最適の取り組みを継続する」というテーマを掲げて活動しています。例えば、クラウドプロバイダーを跨いだ構成管理やCI/CDの標準化、新技術の横展開を行っています。また、監視などの共通基盤についても、最適化と共通化を重視して設計を改善し続けています。

そして、これが個人的にもっとも重要だと考えているのが「新プロダクトで導入した技術を、着実に既存プロダクトへ展開することで、結果的な共通化を図る」というアプローチです。事業を制限する共通化ではなく、あくまで新しい知見を横に広げて行くことで、組織全体として自然に共通化が図られる状態を目指しています。こうしたサイクル自体も、多様な事業と継続的な新規リリースがあるからこそ実現できる、私たちの強みであると考えています。

マルチクラウド化の課題を打破する、共通基盤「Gamelib」のKubernetes刷新

旧来の相乗り構成によるリスクとポータビリティの限界

岩井：さて、ここからは「技術の適応力」という観点で、横断部門としての標準化とバックポートの事例についてお話しします。事例として、内製の共通基盤システムであるGamelibを取り上げます。

Gamelibは、複数の事業部で利用されているユーザー認証および課金機能の基盤システムです。各ゲームタイトルに対してSDKとAPIの形で機能を提供しています。ログインや決済といった共通機能については、各タイトルで車輪の再発明をするのではなく、中央で一括管理する方針を取っています。決済機能において、内部統制や監査の観点が重要であり、ゲーム側のサーバーロジックとは独立した中央集権的な設計が必要だったという背景があります。

Gamelibは2014年のサービス開始以降、グリーグループの全てのゲームタイトルで採用されています。しかし、タイトル数の増加や運用の長期化によって、複数の課題が発生していました。例えば、ゲーム側の採用クラウドの多様化です。現在グリーでは、主にAWSとGoogle Cloudの利用規模が約半々となっており、共通基盤側にもマルチクラウド対応の需要が増えていました。また、タイトル数の増加によってキャパシティプランニングの複雑化、あるいは横断障害時のリスクが顕在化していました。詳細は後ほどお話しします。

改めて、従来の構成と課題を整理します。Gamelibは、クライアントアプリのSDKとゲームサーバーの両方からアクセスを受け、それを複数プロダクトによる相乗り構成で設計していました。Chef＋JenkinsによるCI構成と、ASG管理のEC2のAPIサーバーです。この構成では、多様なクラウドへの展開や精密なキャパシティプランニングが困難であり、1つの障害が全タイトルに波及する横断障害のリスクを抱えていました。

この相乗り構成においては、新規タイトルがリリースされるたびに、都度キャパシティプランニングで対応してきましたが、タイトル間の影響を排除できないことが大きな懸念となっていました。

Kubernetes/GitOps/KEDAによるモダンなインフラ基盤へ

岩井：改めて課題を整理し、解決の方針を考えていきます。一番に浮かぶのは「多様なクラウドへの展開が困難である」という点です。内製を含むパイプラインやAWSサービス前提の構成がポータビリティを下げていました。ここに対しては、内製の仕組みを廃止した上でAPIサーバー層を抽象化し、別クラウドへの展開を容易にする方針をとっています。

次が「キャパシティプランニングの困難さ」です。ゲームには周年イベントやイベントのリリース、ゲーム性の違いによる独自の負荷傾向があり、特に新規リリース時の不確定要素が大きいという特徴があります。これを解決するため、プロダクト別・ワークロード別にリソースを隔離し、スケール設定を個別に簡潔にする設計を目指しました。

最後は「共通基盤側の横断障害リスク」です。従来も要件や規模に応じて環境を複製して対応していましたが、工数負荷が課題でした。これに対し、プロダクトや規模に関係なく高速に隔離環境を提供できる構成を模索した結果、グリーの標準構成であるKubernetesへのリアーキテクチャを決断しました。

Kubernetesの話が出たため、ここで標準構成について補足します。グリーグループでは2019年以降、原則としてKubernetesを採用しています。AWSとGoogle Cloudを合わせ、ゲーム以外も含めて16のプロダクトがKubernetes上で稼働しており、全ての設計・運用に開発本部が携わっています。結果として、このKubernetesのエコシステムと抽象化能力が、マルチクラウド環境での設計と運用を支えてくれています。

設計にあたり大切にしたのは「新プロダクトでの技術的挑戦とバックポートのサイクル」です。高頻度のリリースを生かして、新規プロダクトでは常に新技術の導入を検証し、その知見を既存のプロダクトへ還元して共通化を図る。Kubernetes構成のリアーキテクチャを通じて、環境固有の課題解決と標準化を達成し、技術的改善のサイクルへと取り込むというのが今回の目的です。

具体的には、APIサーバーを完全にコンテナへ移行し、CI/CDを刷新しGitOpsへ移行。単一の環境だったものをワークロード別にコンテナ分離し、それぞれが独自にオートスケールする構成に作り替えました。

また、プロダクト別のリソース分離も徹底しています。

新規タイトル追加時には、ネームスペースを分けることで、各プロダクトの環境を論理的に分離しています。

この分離レベルについては、事業の要件に応じた複数の選択肢を提供しています。「同一クラスター内でノードのみ分離する」「管理系のリソースは共通化する」「クラスター、AWSアカウント、クラウドを分離する」といったように、柔軟な提供を可能にしました。

この構成は、これまでの積み重ねによって実現したものです。Kubernetesの採用は2019年に始まり、Argo CDについては2020年のプロダクトに採用しています。当時は複数のプロダクトでArgo CDとPipeCDを導入していて、結果的に現在はArgo CDがグリーの標準的なデプロイフローとして定着しています。

また、2022年にはKarpenterを導入しました。当時私たちが解消したと思っていた「ポッドのビン詰め問題」というリソース効率の最適化という課題に対し、有効な解決策になると考えたからです。一般提供された直後に検証を開始し、2022年リリースのプロダクトから導入しています。これも現在のAWS EKSの環境において、標準構成の1つです。

監視についても、2015年から利用しているPrometheusとGrafanaを、EC2、Kubernetes、そしてクラウドベンダーを問わず標準として運用しています。

Gamelibのリアーキテクチャにおいては、KEDAを新たに導入しています。タイトルごとに異なる負荷傾向に対し、多様なスケジュール設定やメトリクスベースのオートスケールを実現しています。このKEDAによる知見も、AWS・Google Cloud問わず標準構成として別のプロダクトへと展開済みです。

高速な環境複製と持続可能な改善サイクルの実現

岩井：Gamelibの新構成にて、2つのゲームタイトルをリリースしています。IaCで管理された標準構成により、本番環境だけでなく、負荷試験やイベント検証用といった一時的な環境も、極めて高速に複製・提供することが可能となりました。結果的に、タイトルリリース時に作られていた関係者による「見守りチャット」の必要もなくなりました。

また、共通基盤を新規リリースの改善サイクルに再度乗せることができました。Kubernetes利用プロダクトの改善を通じて得た恩恵を、この基盤でも受けることができています。今回得られたKEDAの知見も、すでに別プロジェクトへと展開され、循環が始まっています。

現在は、次のリアーキテクチャに関する話も進んでいます。対象は、20年以上の歴史を持つSNS「GREE」です。

今回は自社で運用しているSNS Platformと内製ゲームが対象です。ここには、開発・運用上の課題が集積しています。巨大なモノリス環境でありながら、40以上のリポジトリと複数のサービス管理チーム、各サービスの密結合を内製のデプロイ管理による一元的な排他制御が必要という、Gamelibとは異なる性質を持っています。当然、リアーキテクチャでも異なるアプローチが求められます。

この詳細については「GREE Tech Conference 2025」の「20年以上オンプレサーバで稼働し続けたSNSサービス『GREE』のクラウド移行をやりきったぞ！そしてコンテナ化！」で私の同期が発表しておりますので、ご興味のある方はそちらをご覧ください。

最適なインフラサービスの提供を通じて、社内外の成長を支えるグリー開発本部

岩井：まとめます。私たちのテーマは「継続的な挑戦のサイクルと知見の展開で、個別最適と全体最適の両立」です。常に技術的な挑戦を行い、運用を通じて改善サイクルを回し、そこで得た知見を既存プロダクトへと展開する。この循環こそが、多様な事業部に対して自由度を担保しつつ、組織としての全体最適を維持する道だと考えています。

グリー開発本部が提供する価値とは「社内外を問わず事業や組織のフェーズに応じて変化し続ける最適なインフラサービス」を提供することです。グリーグループ全体の高頻度のプロダクトリリースによって獲得した知見、20年以上運用されているサービスから最新アプリまでを1つの組織で支える技術の多様性、画一的な設計ではない柔軟なアプローチ。これら全てが、私たちの価値だと考えています。

トータルテクノロジー事業が目理す、事業会社ならではの成長コミット

大久保：最後に、これまでお話ししたアーキテクチャの話とも関連する、新事業についてご紹介させてください。

先ほど岩井からお話した通り、我々は状況や変化に応じて、最適なアーキテクチャを提供してきました。こうした知見を社外のお客様にも提供する取り組みを始め、おかげさまで初年度から数多くの引き合いをいただいております。事業として着実な一歩を踏み出せたのは、ご期待いただいたパートナーの皆様のおかげであり、深く感謝しております。

この事業の強みは、本日お話しした「インフラ力」にあります。時代に合わせてアーキテクチャを変遷させてきた経験が、社外のお客様の多様なサービスに対しても、確かな適応力を発揮しています。また、本日は詳しく触れておりませんが、ユーザーの期待に魅力的にアプローチする「UI/UXデザイン力」と「一気通貫での開発力」。この2つが相まって、多くのお客様にご評価いただけているものと分析しております。

もし皆様の中で、大規模なリプレース案件の課題をお持ちの方がいらっしゃれば、ぜひ一度グリーにご相談ください。

現在多くのお引き合いをいただいており、全てをすぐにお受けできるわけではありません。今あるアーキテクチャをどう刷新するべきか、課題解決のために何が必要なのか。それを協議しながら、ともに高みを目指していけるような案件であれば、ぜひご協力させていただきたいと考えております。

具体的な事例としては、NHK様のシステムリプレースに貢献させていただいております。公表されている範囲内のお話しで言うと、Webサイト及びサーバーサイドの詳細設計・実装を支援いたしました。

また、長くお付き合いさせていただいているゲーム会社のテンアンツ様では、サーバーコストの削減からアーキテクチャ設計、運用、アプリケーション支援に至るまで、トータルでサポートさせていただいております。

今回「トータルテクノロジーサービス」として、ロゴも一新いたしました。我々のテクノロジーを通じて、世の中に少しでもバリューを届けられるように、活動の幅を広げていきたいと考えています。ご関心のある方は、ぜひお問い合わせください。良いご縁が生まれることを願っております。

本日は、ご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。