変わるもの、変わらないもの：OSSアーキテクチャで実現する持続可能なシステム

by gree_tech

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2011年にグリー株式会社（現：グリーホールディングス株式会社）へ⼊社。国内外スタジオのゲームタイトルリリースに携わった後、全社横断プロジェクトのPMとして、数多くの組織課題の解決に尽⼒する。 2018年より複数の要職(セキュリティ‧決済基盤‧データテクノロジー)を歴任 ‧オンプレミス∕クラウドを含む⼤規模商⽤インフラの責任者 ‧アプリケーション開発組織の⽴ち上げ、事業組織化など 2025年より株式会社グリー開発本部⻑に就任。グリーグループの商⽤環境で蓄積したナレッジやノウハウを活かし、社外向けの新規事業を推進。前年⽐150%の事業成⻑を実現し、現在に⾄る。⼤久保将株式会社グリー開発本部⻑

Slide 3

Slide 3 text

Copyright © GREE, Inc. All Rights Reserved. グリーグループ概要社名：グリーホールディングス株式会社代表者：代表取締役会⻑兼社⻑最⾼経営責任者⽥中良和設⽴： 2004年12⽉7⽇資本⾦： 100百万円事業内容：ゲーム事業、VTuber事業、IP事業、DX事業、投資事業従業員数： 1,520⼈（グループ全体‧2025年9⽉末現在）売上⾼： 57,111百万円（グループ全体‧2025年6⽉期）営業利益： 4,860百万円（グループ全体‧2025年6⽉期）

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © GREE, Inc. All Rights Reserved. BtoCとBtoBサービスの特徴ユーザアカウントの作成サーバ台数の決定ソフトウェアの選定システム特性運⽤特性不特定多数の「消費者」がサービス規約に沿って⾃ら登録サービスの「負荷予測や状況」に合わせて柔軟に決定利⽤環境に合わせてソースコードレベルで改変が可能で、ライセンス費⽤も不要な「オープンソースソフトウェア」を選定システムの⼀部に障害が発⽣してもユーザ影響を限定できる「可⽤性重視」ユーザのサービス利⽤を極⼒妨げないために「無停⽌メンテナンス」を前提とした運⽤情報システム部⾨が特定の「利⽤者」または「連携システム」に対して払い出し「サービス導⼊時に要件」に合わせて決定サービス導⼊時に要件に合致する機能と性能を満たし不具合時にはサポートを依頼できる「ベンダー製ソフトウェア」を選定システムに障害が発⽣すれば、それ以前に巻戻る等、ユーザの混乱を抑えられる「⼀貫性重視」ユーザの混乱を抑えられるために計画的に「メンテナンスウインドウ」の設置を前提とした運⽤従来の典型的なBtoCサービス従来の典型的なBtoBサービス

Slide 9

Slide 9 text

Copyright © GREE, Inc. All Rights Reserved. グリーアーキテクチャの基本構成  時代時代で諸々の理由で刷新していくが、本質的な基本構成は変わらない 24/365 本システム ● CDN ● 負荷分散機 ● cache DBへの重い処理 ● DB  共通サブシステム ● 決済共通基盤/ユーザ認証基盤（内製） ● 分析基盤 ● セキュリティ基盤システム ● deploy システム運⽤サブシステム ● モニタリング(Prometheus + Grafana) ,CS(Zendesk),サポートツール（内製） ● SaaS(PagerDuty) 運営サブシステム ● CS(Zendesk),サポートツール（内製）

Slide 10

Slide 10 text

Copyright © GREE, Inc. All Rights Reserved. アーキテクチャの歴史事業環境の変化を受けながら、無停⽌リアーキテクチャを積み重ね、インフラ部隊としての経験を蓄積 - 国内外に10拠点を超えるDC - 数万台規模の物理サーバ - OSS - 認証基盤、決済基盤、分析基盤等は全て内製 - 選任EN 200⼈ - AWSへプロダクトリリース - 購⼊サーバの有効活⽤とのバランシング - OSS - 認証基盤、決済基盤、分析基盤等は全て内製 - AWSへ主要プロダクトを移⾏ (1年で数千台) - OSS - ユーザ認証/決済基盤の内製再開発 - その他共通基盤のSaaS化活⽤が開始 - Google Cloud 活⽤開始 - ベンダーロックを回避 - 事業/プロダクト区分で使い分け - OSS - ユーザ認証/決済基盤の内製再開発(GCP向け) 本⽇の後半の内容 2013 2015 2016 2018 2022 現在 - platform機能サーバの完全移⾏開始 - DC解約 - 決済基盤のみ内製を維持管理オンプレ全盛期クラウド開始クラウド移⾏マルチクラウドオンプレ解約

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © GREE, Inc. All Rights Reserved. 2019年にグリー株式会社（現：グリーホールディングス株式会社）へ新卒⼊社。以降現在に⾄るまでインフラストラクチャ部に所属。⼊社時より RDBMS/KVS の専⾨チームを兼務し、2021年より新規ゲームタイトルのインフラ設計‧⽀援のチームを主務とし、複数タイトルの Kubernetes でのリリースを担当。 2025年までは GREE Platform 事業のクラウド移設に尽⼒。並⾏して内製のユーザー認証‧決済基盤である Gamelib の Kubernetes へのリアーキテクトを主導。岩井良成株式会社グリーシニアエンジニア

Slide 13

Slide 13 text

Copyright © GREE, Inc. All Rights Reserved. 事業部横断組織として、社内外の多様な事業を⽀える ● GREE Platform 事業 ( 20周年を超える SNS Platform + ゲーム ) ● ゲーム事業（ WFS ） ● VTuber事業（REALITY） ● 社外の事業に関しても開発本部として独立して技術を提供株式会社グリーの開発本部が⽀える事業事業部やプロダクトごとに最適化された「インフラ組織」を提供する ● 共通部門でありながら多様な組織、文化、事業のフェーズに対応する必要がある ● 求めるスピード感やサポートに応じて個別でプロジェクトを調整する組織としての適応力、技術としての柔軟性が求められる

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright © GREE, Inc. All Rights Reserved. 事業別に最適化されたインフラサービスの提供画⼀的な設計や責任分界は、事業の成⻑を妨げる ● 共通部⾨として各事業に対して画⼀的な業務を⾏うことは、事業の成⻑を妨げる ● 社内外の多様な事業を完璧にテンプレート化できる設計は存在しない事業の要件に応じて多様な役割、責任分界点を設計する ● 複数のクラウド事業者やオンプレミス環境を含めて事業に応じて対応 ● 定義の変化し続ける「インフラ」という領域で個別に設定した責任分界点で対応する ○ 環境全体を開発組織とインフラ組織共に開発‧運⽤していくパターン ○ コンテナのビルドまでを開発組織で⾏い、プラットフォームをインフラ組織で設計‧運⽤するパターン

Slide 17

Slide 17 text

Copyright © GREE, Inc. All Rights Reserved. 適応⼒を⽀える共通化個別最適化だけでは横断部⾨として限界がある ● 開発本部は年間複数プロダクトの新規リリースと既存の運⽤を並⾏し続けている ● 個別最適化を推し進めるほどに、共通部⾨としての業務効率が悪化 ● 全体最適が損なわれ、ノウハウの蓄積‧共有も困難に事業に対しては柔軟性を持ちつつ、内部での全体最適化の取り組みを続ける ● クラウドプロバイダを跨いだ構成管理やCI/CD、新規技術の横展開 ● 監視などの共通基盤についても、最適化と共通化のバランスを重視して設計を改善 ● 新プロダクトで導⼊した技術を既存プロダクトへも展開することで共通化を図る ○ 事業を制限する共通化ではなく、新しい知⾒をバックポートする共通化 ○ 多様な事業と継続的な新リリースによって⽀えられているサイクルでもある

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright © GREE, Inc. All Rights Reserved. 内製共通基盤システム「Gamelib」の事例 Gamelib とは ● 複数事業部で利⽤されているユーザー認証機能‧課⾦機能の基盤システム ● 共通機能の提供と、決済機能の内部統制‧監査を⽬的とした中央集権型の設計 ● 消滅都市(2014年)以降のグリーグループのゲームタイトル全てで採⽤タイトル数の増加や運⽤の⻑期化によって複数の課題が発⽣ ● ゲーム側採⽤クラウドの多様化による共通基盤側のマルチクラウド対応の需要増 ● タイトル数の増加によるキャパシティプランニングの複雑化 ● タイトル数の増加による共通基盤障害時の横断影響のリスク

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Copyright © GREE, Inc. All Rights Reserved. 個別の課題と⽅針多様なクラウドへの展開が困難 ● 内製を含むパイプラインや AWS サービス前提の構成がポータビリティに課題 → 内製の仕組みを廃⽌した上で、APIサーバー部分を抽象化し他クラウド展開を容易に共通基盤障害の横断影響リスク ● 従来も要件や規模に応じて環境を分離してきたが、対応⼯数に課題 → プロダクトの規模によらず、⾼速に隔離された環境を提供できる構成へキャパシティプランニングが困難 ● プロダクト別の異なる負荷傾向が混在し、特に新規リリース時は不確定要素が多い → プロダクト別‧ワークロード別にリソースを隔離することでスケール設計を簡潔に現在のグリーでの標準構成である Kubernetes 構成へリアーキテクト

Slide 25

Slide 25 text

Copyright © GREE, Inc. All Rights Reserved. Kubernetes の採⽤とこれまでの実績グリーグループのゲームタイトルは2019年以降原則 Kubernetes を採⽤ ● AWS/Google Cloud で計16のプロダクトを Kubernetes でリリース ○ その全ての設計‧運⽤に開発本部がアサインされている ● Kubernetes のエコシステムと抽象化がマルチクラウドの設計と運⽤を⽀えている新プロダクトでの技術的挑戦のサイクルと、既存のプロダクトへのバックポート ● ⾼頻度のリリースを活かして新プロダクトでは常に新技術の導⼊や検証を⾏っている ● 並⾏して既存のプロダクトへもバックポートする事で共通化を推進するサイクル ○ 新規リリースの設計と運⽤が同じメンバーであることを活かした体制 Kubernetes 構成へのリアーキテクトを通じて、環境固有の課題解決と標準化を達成し、技術的改善のサイクルへ取り込む

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright © GREE, Inc. All Rights Reserved. 現在のグリー標準構成へのリアーキテクト API サーバーを Kubernetes 管理 ● API サーバーをコンテナへ移⾏ ● CI/CD を刷新し GitOps へ移⾏ ● ワークロード別のオートスケールプロダクト別にリソースを分離 ● 各プロの環境を論理的に分離 ● 分離レベルは複数選択肢を提供 ○ Nodeを分離する構成 ○ Cluster ごと分離する構成等

Slide 30

Slide 30 text

Copyright © GREE, Inc. All Rights Reserved. 現在のグリー標準構成へのリアーキテクト Kubernetes 内の構成もまた、これまでの積み重ねでできている ● ArgoCD(2020~) ○ 当時 PipeCD と⽐較で同時導⼊ ● Karpenter(2022~) ○ Pod の瓶詰め問題解消⽬的 ○ ⼀般提供直後から検証を開始 ● Prometheus+Grafana(2015~) ○ AWS 利⽤開始当初から利⽤ ○ 構成/クラウドを問わず標準利⽤ ● KEDA(2025~) *本環境で初回採⽤ ○ 多様な負荷傾向への対策で導⼊ ○ その後他プロへも展開済み

Slide 31

Slide 31 text

Copyright © GREE, Inc. All Rights Reserved. リアーキテクトの結果 Gamelib 新構成にて既に2つのゲームタイトルをリリース済み ● IaC管理された標準構成によって、⾼速な環境の複製が実現 ● 負荷試験専⽤やイベント出展⽤環境など⼀時的な環境も⾼速で提供が可能に ● タイトルリリース時に関係者による “⾒守り” チャットが作られる事も無くなった共通基盤を新規リリースの改善サイクルに再度載せることができた ● Kubernetes 利⽤プロダクトの改善全ての恩恵を今後も受けることができる ● 今回のリリースでの KEDA 採⽤もまた、他環境へ展開することができた

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Copyright © GREE, Inc. All Rights Reserved. GREE : ソーシャルゲームプラットフォーム 2004年から、20年以上開発運⽤されているプロダクト ● SNS Platform: SNS 及びログインやコイン情報、ユーザー情報を扱う ● ゲーム(内製ゲーム): グリー社内で開発しているゲーム ● ゲーム(3rd様ゲーム): 他社企業様により GREE Platform 上で提供されるゲーム開発‧運⽤上の課題も集積 ● 巨⼤なモノリス環境でありながら、40以上のリポジトリと複数のサービス関連チーム ● 各サービスの密結合を、内製のデプロイ管理システムで⼀元管理‧排他制御

Slide 34

Slide 34 text

Copyright © GREE, Inc. All Rights Reserved. GREE : ソーシャルゲームプラットフォーム 2004年から、20年以上開発運⽤されているプロダクト ● SNS Platform: SNS 及びログインやコイン情報、ユーザー情報を扱う ● ゲーム(内製ゲーム): グリー社内で開発しているゲーム ● ゲーム(3rd様ゲーム): 他社企業様により GREE Platform 上で提供されるゲーム開発‧運⽤上の課題も集積 ● 巨⼤なモノリス環境でありながら、40以上のリポジトリと複数のサービス開発チーム ● 各サービスの密結合を、内製のデプロイ管理システムで⼀元管理‧排他制御先ほどの共通基盤とは元の設計や開発体制が全く異なるよって、リアーキテクトの⽅針や設計についても、異なるアプローチが必要

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Copyright © GREE, Inc. All Rights Reserved. まとめ株式会社グリー開発本部の提供する価値: 社内外を問わず、事業や組織に応じて変化する最適なインフラサービスの提供 ● グリーグループ全体の⾼い頻度でのプロダクトリリースによって獲得した知⾒ ● 20年以上の運⽤サービスから最新のアプリまで、ひとつの組織で⽀える技術の多様性 ● 画⼀的な設計ではなく、技術課題に応じて変化する多様なアプローチの選択肢継続的な挑戦のサイクルと知⾒の展開で、個別最適と全体最適を両⽴する ● 継続的に技術的な挑戦を⾏い、運⽤を通じて改善サイクルを回し続ける ● 得られた知⾒を既存プロダクトへ展開し、個別最適化と全体最適化のバランスを取る