20年間 SNS サービス「GREE」を支えた技術の刷新と、長期運用サービスの Kubernetes へのリアーキテクト

by gree_tech

Embed

Start on current slide

Slide 1

Slide 1 text

20年間 SNS サービス「GREE」を支えた技術の刷新と、長期運用サービスの Kubernetes へのリアーキテクト株式会社グリー開発本部インフラ事業部 AI & Infra Solutionsグループ ID1チーム岩井良成大迫裕樹

Slide 2

Slide 2 text

岩井良成株式会社グリーアソシエイトマネージャー / リードエンジニア 2019 年グリーに新卒入社これまで RDBMS/KVS の専門チームを兼務ネイティブゲームを Kubernetes でリリースいま長期運営タイトルのアーキテクチャ刷新に PM とエンジニアの 2 つの立場で取り組む 2

Slide 3

Slide 3 text

アジェンダ ● GREE を支えてきた共通基盤とその課題 ● 設計と実装 ● 移行の進め方 ● これから 3

Slide 4

Slide 4 text

GREE を支えてきた共通基盤とその課題 4

Slide 5

Slide 5 text

GREE は SNS を 20 年以上運用し、ゲームも提供してきた GREE 自社ゲーム自社ゲーム自社ゲーム外部デベロッパーのゲーム外部デベロッパーのゲーム SNS プラットフォーム（GREE Platform） SNS の機能、ログイン、コイン、ユーザー情報、開発者向け API ネイティブゲーム GREE とは構成も運用も異なる GREE のプラットフォームを使わず、ゲームごとに単独のアプリとして配信する 2019 年以降に出したタイトルは、すでに Kubernetes で動いている GREE は 2004 年に SNS として始まり、2007 年から自社のゲームを、2010 年から GREE Platform を提供している 5

Slide 6

Slide 6 text

対象は共通構成のうちアプリケーションサーバー層 SNS プラットフォーム自社ゲーム Proxy / LB Proxy / LB アプリケーションサーバー（Apache + PHP）アプリケーションサーバー（Apache + PHP） DB KVS DB KVS DB と KVS は今回の対象外。アプリケーションサーバーの層だけを置き換える 6

Slide 7

Slide 7 text

コードは 57 のリポジトリを 1 つにまとめたモノリスだった /home/gree（1 本のツリー） 57 のリポジトリ全タイトルのコードが 1 本のツリーに共通のコードオンプレミス時代、別のゲームにすぐ転用できるよう、まとめて入れていた SNS の機能 symlink で 1 本のツリーに見せる構成プラットフォーム自社ゲーム（6 タイトル）管理と運用のツール直接呼ぶ実体は 57 のリポジトリをそれぞれ clone したものだった相互の参照が増え、密結合になっていたあるタイトルは 23 種類のサービスを PHP の中で直接呼んでいたどのタイトルも、57 のリポジトリすべてを含むツリーで動いていた 7

Slide 8

Slide 8 text

前回のあらすじクラウドへの移行を完了 1 万台以上のオンプレミスのサーバーを、 VM のままクラウドへ移した妥協したことオンプレミスで作ってきたサーバー管理とデプロイの仕組みは、密結合のまま持ち込んだコンテナ化の設計リポジトリごとのイメージを 1 つの Web サーバーに統合する設計と、試算まで進めた昨年の発表資料 speakerdeck.com/gree_tech 今年は、アプリケーションサーバーをコンテナにし、デプロイとサーバー管理を Kubernetes に移している話 8

Slide 9

Slide 9 text

サーバーの管理とデプロイには独自のシステムを 3 つ使っていたデプロイシステム server.in Release Master デプロイサーバーとスクリプトサーバー管理システムリリース管理システム 57 のリポジトリを 1 本のツリーにまとめ、デプロイサーバー同士で中継しながら、各サーバーへ並列に rsync で送る。物理サーバーの台帳で、修理の依頼まで扱った。オンプレミスとの並行運用中もデプロイシステムが依存し、クラウドでも使い続けた。リリース作業の依頼をジョブとして受け付け、同じサーバーやサービスへの作業が重ならないように排他をかけて順に実行する。約 21 年 2005 年から約 20 年 2006 年から約 14 年 2012 年から主に PHP で約 9 千行 PHP で約 1.7 万行 Rails で約 1 万行コードを配る仕組みに、サーバーの管理と作業の制御の機能が順に足されてきた 9

Slide 10

Slide 10 text

デプロイの作業には、どれも複数のシステムが関わっていた独自のデプロイ・サーバー管理システムデプロイシステム server.in Release Master 作業中身何を配るかリポジトリの組み合わせと雛形 ● どこへ配るか台帳の役割と状態でデプロイ先を決める ● ● ● どう配るか排他をかけ、LB から外して rsync で送る ● ● ● サーバーをどう増やすか台帳に登録し、雛形から配って LB に入れる ● ● ● ● 1 つのシステムを変えると他も直す必要があり、一部だけを改修できなかった 10

Slide 11

Slide 11 text

リアーキテクトを決めた理由部分的に直せない・1 つを変えると、他も直す必要がある・デプロイの制約で、負荷に応じたオートスケールが使えない全体を知る人が減る・中心のリポジトリだけで、数百人が関わった・全体を知る人は、時間とともに減っていくこれからも安定したインフラ環境を提供するため、リアーキテクトを決めた・独自のデプロイとサーバー管理をやめ、アプリケーションサーバーをコンテナにして Kubernetes に載せる・近年のネイティブゲームは、すでに Kubernetes の標準構成で動いていて、GREE とは構成も運用も異なる・その標準構成に揃え、インフラ組織のより多くの人が、このサービスをメンテナンスできる状態にする 11

Slide 12

Slide 12 text

設計と実装 12

Slide 13

Slide 13 text

大迫裕樹株式会社グリーシニアリードエンジニア 2019年にグリーへ新卒入社。 Kubernetes やモニタリング領域を中心に、クラウドインフラの設計・構築・運用に従事。近年は GREE サービスのインフラ環境リアーキテクトに携わる。 13

Slide 14

Slide 14 text

昨年ここで話したことアーキテクチャそのものの話 ● VM で動作する巨大なモノリスをリポジトリ単位のコンテナイメージに分割 ● Kubernetes 側で統合し、1 つの web サーバーとして動作 ● アプリケーションは改修なし 14

Slide 15

Slide 15 text

(再掲) アーキテクチャ図狙いどおりに機能し、アーキテクチャレベルの変更は無かった 15

Slide 16

Slide 16 text

アーキテクチャをどう作ったか ● 拡張では届かないと見切る (2020 年) ● 最良の設計案に欠けたピースを探す (2023 年) ● 基盤の細部を詰める (2024 年) ● サービスに適用する (2023〜2026 年) 16

Slide 17

Slide 17 text

① 拡張では届かないと見切る 17

Slide 18

Slide 18 text

始まりはオートスケールの検討だった ● 目的はコスト最適化 ● VM で動く web サーバーを対象に、既存基盤を拡張 – スケジュールベースのスケーリングで、サーバー費用を大きく削減 – 拡張部分はクラウドネイティブな作り ● 負荷ベースのスケーリングは、既存基盤の拡張では実現できず見送り課題は内製のデプロイとサーバー管理との密結合にあった 18

Slide 19

Slide 19 text

過去の試みでは拡張を選んだ以前にもリアーキテクトのプロジェクトがあった ● Kubernetes でコンテナ化 ● 内製システム (デプロイやサーバー管理) を維持 ● デプロイ経路を既存の経路から派生 ● 移行できたのは、データ依存が少なく運用がシンプルなサービスのみスモールスタートしやすかったが、制約が残り複雑化とリリースの柔軟性の低下を招いた 19

Slide 20

Slide 20 text

作り込みが複雑さを生んだ最大の課題は仕組みの複雑さと、それを理解するためのコンテキストの高さ独自の作り込みサービスごとの作り込み・データの扱いを独自のパッケージングとデプロイで実現・データの特性から生じる課題や制約にサービスごとのイメージや CI で対処・仕組みが複雑になり、メンテナンスも困難・サービスごとの最適化はできたが管理の負担と認知コストが高い独自にも、サービスごとにも作り込まない。汎用的な知識で理解できる、共通の構成にする 20

Slide 21

Slide 21 text

② 最良の設計案に欠けたピースを探す 21

Slide 22

Slide 22 text

要件は既存の仕組みから導いた内製のデプロイとリリース管理が実現・担保していたことを言語化 (再掲) 新しい仕組みが満たすべき要件 ● ビルド時間とデプロイ時間が十分に短いこと ● 個別にリリースとロールバックを制御できること ● 各サーバーで使うリポジトリを選択できること ● 現行運用と両立すること ● アプリケーション側の変更を必要としないこと 22

Slide 23

Slide 23 text

従来の基盤は課題ごと捨てた過去の試み今回内製システムを維持し既存の経路から派生させる基盤を課題ごと捨てる基盤とともに課題も引き継ぐリリース管理システムのみ維持しデプロイ基盤をゼロベースで作り直す課題を引き継がないために、拡張ではなく作り直しを選んだ 23

Slide 24

Slide 24 text

最良の設計案には、ピースが 1 つ欠けていた ● ● ● 複数の設計案を検討最良の設計案は、リポジトリごとのイメージを Kubernetes 側で 1 つの web サーバーに統合する構成イメージの作成・取得・展開までは Kubernetes とエコシステムが強力に支援欠けていたのは、展開したデータを web サーバーから参照する機構だった 24

Slide 25

Slide 25 text

欠けたピースを探し当てた ● ● ● データのコピーを伴わずに複数のイメージを扱う方法を模索調査の過程で Linux の mount propagation を発見サイドカーから emptyDir へ bind mount し、コンテナをまたいだファイル参照を可能に (昨年紹介した仕組み) 最後のピースも Linux と Kubernetes の標準機能で実現した 25

Slide 26

Slide 26 text

どの要素も標準の仕組みで実現した要素従来 (VM) 過去の試み今回パッケージングなし内製スクリプト docker (crane) アップロード内製スクリプト (ファイル同期) 内製スクリプト docker (crane) ダウンロード内製スクリプト (ファイル同期) Kubernetes + 内製 Kubernetes サーバー構築手動 Kubernetes + 内製 Kubernetes ワークロード管理手動 Kubernetes Kubernetes CI・マニフェスト管理 — サービスごと共通独自の仕組みを標準の仕組みで置き換えサービスごとに作っていたものを共通基盤に集約した 26

Slide 27

Slide 27 text

③ 基盤の細部を詰める 27

Slide 28

Slide 28 text

判断軸に沿って細部を決めた判断軸 ● ● 汎用的な知識で理解でき、長期間メンテナンスできること多くのチームのリリースが続く中でも移行の各フェイズを通して安全に運用できること ○ 事前構築・並行運用・移行後層決めることビルドどこでビルドし、どう共通化するか実行環境どのベースイメージを使い、起動時に生成していた設定をどう渡すか設定と反映設定ファイルをどう配り、変更をいつ反映するか web サーバー内の構成何を残し、何を廃止するか 28

Slide 29

Slide 29 text

web サーバー内の構成は、既存の構成管理を精査して決めた ● アプリケーションから見た実行環境は変えないことを原則とする ● 構成管理の cookbook は流用せず、すべて精査して Dockerﬁle に書き直す – 24 リポジトリ、63 recipe、2,200 行 ● recipe をツリー状に辿り、1 項目ずつ「いる / いらない / 別の形でやる」を判断 – 7 割は廃止もしくは別の形に置き換え – 決めきれないものは無理に削らず残す方針後の移行で、web サーバー内の構成に起因するサービス障害は起きなかった 29

Slide 30

Slide 30 text

④ サービスに適用する 30

Slide 31

Slide 31 text

スコープを絞って段階的に実績を作ったスコープ最初の導入先確かめたこと 1 コア技術 (コンテナ間のファイル参照) ネイティブゲーム (GREE サービス外) そのプロダクトの起動を高速化し不具合なく動くこと 2 アプリケーション基盤比較的単純な社内サービス設計どおりに動くこと 3 アプリケーションを含む全体移行難易度が比較的低いプロダクト各プロダクトのアプリケーションが移行前と変わらず動くこと順番実績が次のスコープへ進む根拠になった 31

Slide 32

Slide 32 text

本番までの検証を設計する 1 検証環境まず動作を確認 2 QA 専任部署によるリリース前のチェックを、コンテナ環境で実施 3 staging 本番に近い構成で確認 4 実経路での社内向けプレビュー経路は本番のまま、社内にだけ公開。本番への投入前に、残った差分を発見 5 本番へ段階投入比率を上げながら移行 32

Slide 33

Slide 33 text

移行の過程で、既にあった問題が見えた環境が変われば成立しない前提が埋め込まれていた前提対応環境ごとの違いをアプリケーションの中で判定既存の実装の課題としてアプリケーション側を修正設定ファイルのリリースの安全をリポジトリ外の仕組みで担保リポジトリ内で担保できるようリリースの仕組みを修正基盤側で無理に吸収せず、問題の根本を明確化し修正した 33

Slide 34

Slide 34 text

まとめ ● 課題を引き継がないために、拡張ではなく作り直しを選んだ ● 独自に作り込まず、どの要素も標準の仕組みで実現した ● 長期のメンテナンス性と移行中の安全を軸に、細部を決めた ● スコープを絞って段階的に実績を作った ● 移行で見えた既存の問題は、基盤側で無理に吸収せず根本を修正した 34

Slide 35

Slide 35 text

移行の進め方 35

Slide 36

Slide 36 text

ドメイン知識と Kubernetes の知識を持ち寄るチームドメイン知識 Kubernetes の知識 GREE とプロダクトを長く運用してきたエンジニアアプリと従来の環境を知っているメンバーメンバーメンバーメンバー両方を知るメンバーネイティブゲームを普段リリースしているエンジニア Kubernetes での運用を知っているメンバーメンバーメンバーメンバーメンバー両方を知るメンバーを中心に、ドメイン知識に強い人と Kubernetes に強い人が教え合いながら進めている新しい基盤は近年のネイティブゲームと同じ標準構成なので、ここで覚えたことは他のタイトルでも使える 2 つの知識を持ち寄り、両方を知るメンバーを中期の計画で増やしている 36

Slide 37

Slide 37 text

移行の途中で、記録にない前提が次々に見つかった開発環境を置き換える QA の工程で確かめる本番の一部に投入する各段階で問題を見つけ、原因を調べて対応したアクセス制御が複数の層に分かれていたデプロイサーバーで手作業をしていた Apache、アプリ、iptables などに同じ許可リストがあった composer install や git pull を手で実行していたデプロイサーバーにだけファイルがあったステージングで SSH 前提の運用があった手で置いたロックファイルや submodule の実体 SSH で設定を書き換えるジョブを GitOps に置き換えたプロダクトの担当者や歴の長いエンジニアと話して前提を一つずつ確かめ、新しい設計に組み込むか、取り除いた 37

Slide 38

Slide 38 text

サーバーを増やす時間と、デプロイの時間の変化インフラの観点サーバーを増やす時間コンテナ化の前コンテナ化の後数時間サーバーを新しく構築（手作業）約 20 分構築済みのサーバーを起動（時刻に合わせて） Pod を起動数分利用者（プロダクト）の観点変更をデプロイする時間（最大のタイトル）コンテナ化の前 rsync で配布コンテナ化の後イメージのビルドが挟まる（2〜7 月）ビルドを改善すぐ約 50 分約 20 分 crane append への切り替えと最適化（7 月）差分ビルド（9 月〜）約6分リポジトリにはコードだけでなく、本来は分けたいアセットも含まれ、イメージが大きいので、ビルドと push に時間がかかる改善の効果は、インフラの指標と利用者から見た変化の両方で確かめる 38

Slide 39

Slide 39 text

リアーキテクトで変わったこと従来新しい基盤仕組みと知識デプロイとサーバー管理独自の 3 システムが密結合 Kubernetes と GitOps で、部品ごとに直せる運用できる人独自の仕組みを知る人だけ標準構成に揃え、対応できる人が増えたサーバーの構成 cookbook が全部を扱い、ずれうる Dockerﬁle とマニフェストに分け、ずれない障害の復旧 LB から外れ、人が作り直す人の手を介さずに復旧する（オートヒーリング）台数の増減独自の仕組みが時刻だけで起動 KEDA が負荷と時刻の両方で、数分で増減するパッケージの更新 SSH で 1 台ずつ、リリースも止めるイメージを 1 回作り直すだけ。リリースは止めないサービスの可用性と運用運用の対象が 1 台ずつのサーバーからマニフェストに変わった 39

Slide 40

Slide 40 text

現在地とこれから社内サービス自社ゲーム（6 タイトル）プラットフォームの基盤新しい基盤で稼働移行中次の対象いまここサーバー管理システムを先に移した 2 タイトルが本番で稼働 1 タイトルが本番の一部で稼働残りのタイトルも順に移す SNS プラットフォームの基盤自社ゲームの後に進める移行の準備を始めている次はプラットフォームの基盤を移す 40

Slide 41

Slide 41 text

振り返って受け継いで、渡していく GREE を支えてきた仕組みの役割を言葉にし、標準の技術に引き継いだインフラも、後の世代に受け継いでいくために、やるべきことをしていく 41