castaneai

Kubernetes上でゲームサーバーをホストする Agones を用いた環境において、CPU負荷にばらつきがあるゲーム群を動かしたいという事例があった。そこで、それぞれのゲームに対する適切なCPU割り当てを決定するために独自の工夫を行ったので、その実装について紹介する。KubernetesにおけるCPU割り当てAgonesのゲームサーバー群の定義（Fleet）ではGameServerの定義ができるが、GameServer の中身はPodであり、Pod内のコンテナ毎にリソース使用量（CPU・メモリ）の要求と制限を設定できる。たとえば次のFleetの例ではゲームサーバーのコンテナ1つにつき CPU: 1コアの要求と制限を設定している。apiVersion: "agones.dev/v1"kind: Fleet# ... (snip) ...          containers:          - name: simple-game-server            image: gcr.io/agones-images/simple-game-server:0.14            resources:              requests:                cpu: "1"              limits:                cpu: "1"このリソースに関する値は一度Podが作られると動的に変更することはできない1。よって、この設定が実際のゲームに対して不適切だと次のような問題が起きる。負荷の低いゲームは、1コアを全然使い切れずリソースに無駄が生じる負荷の高いゲームは、1コアでは性能が足りず動作に悪影響が出るクラウドゲーミング と CPU使用率クラウドゲーミングは多種のゲームを提供していることが多い。CPU負荷が高いゲームもあれば低いゲームもあるが、実際どれくらいの負荷がかかるのかは起動してみないとわからない。さらに、クラウドゲーミングの性質上 ゲーム本体の負荷だけでなく、動画のエンコード処理の負荷も加わる。したがって、「このゲームをクラウドゲーミングで快適に遊ぶにはCPUはnコア分必要だろう」という予測は難しい。クラウド上で起動して動画の配信込みで体験してみないとリソース使用量はわからないのである。つまり、Agones GameServer の CPU Requests に何を設定すればいいか分からない という問題に突き当たる。最初は「とりあえず、2コアぐらい割り当てておけば大抵のゲームは動くかな？」など雑に推測して cpu: "2000m" のように設定したが、推測のままではよくない。「推測するな、計測せよ」という有名な言葉にもある通り計測すべきである。CPU使用率を上手く可視化するKubernetes では kubectl top pod コマンドでPodごとのCPU/メモリ使用率を見ることができる。しかし、このPodごとのCPU/メモリ使用率だけでは情報としては弱い。なぜなら、次の疑問に答えられないからだ。そのPodでは今何のゲームが起動しているのか？そのPodの中で何の処理にどれくらいのリソースが使用されているのか？ゲーム本体、エンコード処理、…それぞれの割合は？それぞれの使用率は YAML の CPU Requests に対してどれくらいの割合か？まずひとつめの疑問「今なんのゲームが起動していのか？」に答えるには、現在起動しているゲームの情報が必要になる。以前の overlayfs の記事 にも書いたが、多くのゲームタイトルを持つクラウドゲーミングでは何のゲームを遊ぶかは動的に決まる。もう少し詳細に言うと Agones GameServer が allocate された後に API 経由でゲームの情報が降ってくる。よって、ゲームの情報まで含めた指標を得るにはゲームサーバー内に独自の実装が必要になる。独自の指標を作る方法として今回は有名な Prometheus を採用した。公式ドキュメントの Instrumenting a Go application | Prometheus にもある通り、promauto というライブラリを使うとGoから簡単にカスタム値を prometheus 向けに公開できる。今回は次のように欲しい情報をラベルに置いた prometheus metrics を定義した。const (    labelGameID        = "game_id"    labelSessionID     = "session_id"    labelProcessName   = "process_name"    labelProcessPID    = "process_pid"    labelPodCPURequest = "pod_cpu_request")var (    labels    = []string{labelGameID, labelSessionID, labelProcessName, labelProcessPID, labelPodCPURequest}    cpuUsages = promauto.NewGaugeVec(prometheus.GaugeOpts{        Name:      "process_cpu_usage_percent",        Help:      "CPU usage percent per second used by the process. (min: 0, max: numCPU*100)",    }, labels)    cpuUtilizationByRequest = promauto.NewGaugeVec(prometheus.GaugeOpts{        Name:      "process_cpu_utilization_percent_by_request",        Help:      "CPU utilization per second corresponding to Pod's CPU requests used by the process. (min: 0, max: 100)",    }, labels))そして2つ目の問い「何の処理にどれくらいのリソースが使用されているのか？」を把握するためにはPod単位ではなくプロセス単位での使用率を取得すればよい。このために shirou/gopsutil: psutil for golang というライブラリを利用した。次のように、起動中のプロセスを列挙してそれぞれのプロセス名とCPU使用率を取得している。type processInfo struct {    process     *process.Process    processName string}func getProcesses(ctx context.Context) ([]*processInfo, error) {    pids, err := process.PidsWithContext(ctx)    if err != nil {        return nil, fmt.Errorf("failed to enumerate pids: %w", err)    }    var pis []*processInfo    for _, pid := range pids {        p, err := process.NewProcessWithContext(ctx, pid)        if errors.Is(err, process.ErrorProcessNotRunning) {            // プロセス一覧取得→NewProcessまでのわずかな隙間にプロセスが終了した場合などはエラーではないのでスキップ            continue        }        if err != nil {            return nil, fmt.Errorf("failed to new process (pid: %d): %w", pid, err)        }        name, err := p.NameWithContext(ctx)        if err != nil {            return nil, fmt.Errorf("failed to get process name (pid: %d): %w", pid, err)        }        pis = append(pis, &processInfo{            process:     p,            processName: name,        })    }    return pis, nil}type processMetrics struct {    CPUUsagePercent float64}func fetchProcessMetrics(ctx context.Context, pi *processInfo) (*processMetrics, error) {    percent, err := pi.process.PercentWithContext(ctx, 0)    if err != nil {        return nil, fmt.Errorf("failed to get CPU percentage (pid: %d, name: %s): %w", pi.process.Pid, pi.processName, err)    }    return &processMetrics{        CPUUsagePercent: percent,    }, nil}func isTargetProcess(pi *processInfo) bool {    // PID:1 (pause container) は無視    if pi.process.Pid == 1 {        return false    }    return true}実はこのmetricsを収集するプロセスと、ゲーム本体、エンコード処理（GStreamer）はそれぞれ別のコンテナなのだが、Kubernetes の shareProcessNamespace を利用することで他コンテナのプロセスの取得を実現している。Pod内のコンテナ構成を図にすると次のようになる。ここでひとつ注意すべきは、gopsutil の Process.PercentWithContext で取得したCPU使用率は ノード全体のCPUに対する使用率であり、Pod の CPU Request に対する使用率ではない ということだ。今回の事例で知りたいのは「Fleet に設定した CPU Request が適正かどうか」なので、CPU Request に対する割合を出したい。そこで、Kubernetes API と Downward API を利用して metrics exporter から自身のPodの CPU Request を取得して、割合を計算できるようにした。apiVersion: "agones.dev/v1"kind: Fleetspec:  template:# ... (snip) ...        spec:          containers:            - name: metrics              env:                - name: MY_POD_NAME                  valueFrom:                    fieldRef:                      fieldPath: metadata.name                - name: MY_POD_NAMESPACE                  valueFrom:                    fieldRef:                      fieldPath: metadata.namespaceimport (    "context"    "fmt"    "os"    "runtime"    v1 "k8s.io/api/core/v1"    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"    "k8s.io/client-go/kubernetes"    "k8s.io/client-go/rest")func getMyPod(ctx context.Context) (*v1.Pod, error) {    namespace := os.Getenv("MY_POD_NAMESPACE")    podName := os.Getenv("MY_POD_NAME")    k8s, err := newKubernetesClient()    if err != nil {        return nil, fmt.Errorf("failed to new kubernetes client: %w", err)    }    return k8s.CoreV1().Pods(namespace).Get(ctx, podName, metav1.GetOptions{})}func newKubernetesClient() (*kubernetes.Clientset, error) {    config, err := rest.InClusterConfig()    if err != nil {        return nil, fmt.Errorf("failed to get in-cluster kubeconfig: %w", err)    }    return kubernetes.NewForConfig(config)}type podResources struct {    TotalCPURequests float64}func getPodResources(pod *v1.Pod) podResources {    var res podResources    for _, container := range pod.Spec.Containers {        res.TotalCPURequests += float64(container.Resources.Requests.Cpu().MilliValue()) / 1000    }    return res}また、この例では Kubernetes APIを直接叩くため、GameServer Pod を実行する Service Account  に対して Pod 情報を読み取れる権限を付けるのも忘れずに。apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: pod-getterrules:  - apiGroups: [""]    resources: ["pods"]    verbs: ["get"]---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  name: get-podssubjects:  - kind: User    name: system:serviceaccount:default:agones-sdk  # namespace: default, service account: agones-sdk の場合    apiGroup: rbac.authorization.k8s.ioroleRef:  kind: Role  name: pod-getter  apiGroup: rbac.authorization.k8s.io---ここまでの実装をつなぎ合わせると、次のようにプロセス毎のRequestに対するCPU使用率をPrometheusに記録できる。func recordMetrics(ctx context.Context, procs map[int32]*processInfo, session *gamesession.Session, podResources *podResources) error {    ps, err := getProcesses(ctx)    if err != nil {        return fmt.Errorf("failed to get processes: %w", err)    }    for _, pi := range ps {        if !isTargetProcess(pi) {            continue        }        if _, ok := procs[pi.process.Pid]; !ok {            procs[pi.process.Pid] = pi        }        metrics, err := fetchProcessMetrics(ctx, procs[pi.process.Pid])        if err != nil {            return fmt.Errorf("failed to get process cpu usage: %w", err)        }        labels := prometheus.Labels{            labelGameID:        session.GameID,            labelSessionID:     string(session.SessionID),            labelProcessName:   pi.processName,            labelProcessPID:    fmt.Sprintf("%d", pi.process.Pid),            labelPodCPURequest: fmt.Sprintf("%f", podResources.TotalCPURequests),        }        cpuUsages.With(labels).Set(metrics.CPUUsagePercent)        cpuUtilizationByRequest.With(labels).Set(metrics.CPUUsagePercent / podResources.TotalCPURequests)    }    return nil}この指標をGrafanaなどのツールで可視化すると以下の画像のような結果が得られる！ラベルにはゲームIDやプロセス名などが入っており、 どのゲームでどのプロセスが、Pod のCPU Requestsに対して何％ぐらい使っているのかが一目瞭然である。これだけの情報があれば次の疑問すべてに答えることができる。そのPodでは今何のゲームが起動しているのか？そのPodの中で何の処理にどれくらいのリソースが使用されているのか？ゲーム本体、エンコード処理、…それぞれの割合は？それぞれの使用率は CPU Requests に対してどれくらいの割合か？ここまでの情報が揃えば、ゲームごとに適切なCPU割り当てがわかってくる。最初に雑に推測した2コア割当でゲームを起動してみて、2コアのCPU Requestに対する使用率を観察する。それを繰り返してゲーム毎に使用率をまとめ、ざっくりと Low, Middle, High のように3段階ほどに分類する。そこから、それぞれの段階に対応する Fleet を作るという戦略がとれる。また、その情報からひとつの Node にどれだけのGameServerを詰め込めるかも概算できる。3段階程度だと、すべてのゲームにぴったりフィットする割り当てとはいかないが、大きなCPUの無駄が生じたりリソース不足でゲームが固まったりすることは結構防げるのではないかと思う。↩

Kubernetes で動くクラウドゲーミングにおけるCPU割当の工夫

<p>クラウド上でゲームを動かす場合、データ（ゲーム本体のデータ・セーブデータ）をどう管理するかは重要な課題のひとつだ。
そこで、自分が開発に携わっている<a href="https://oo.parts">OOParts</a> のデータ管理を支える技術について紹介する。</p>

<h2>ノベルゲームのセーブ事情</h2>

<p>OOPartsで提供されているのは主にビジュアルノベルゲームで、セーブデータの形式や場所は実に多種多様である。
ゲーム本体と同じディレクトリにセーブデータを保存するゲームもあれば、ユーザーディレクトリ（マイドキュメント等）以下に保存するゲームもある。</p>

<p>とにかく様々な保存方式があるため複数メーカーのゲームを提供するとなると <strong>セーブデータの場所を機械的に特定できない。</strong>
唯一言えるのはほとんどのゲームはセーブデータをファイルに保存しているということぐらいだ。</p>

<p>ゲームタイトル毎に設定を持ち、「ゲームAのセーブデータは〇〇で、ゲームBのセーブデータは〇〇で…」とすれば不可能ではないが
これでは新しいゲームタイトルを追加する度に工数がかかるので避けたい。</p>

<h2>セーブデータは「ファイルの変更差分」と考える</h2>

<p>そこで発想を少し変えみることにした。ノベルゲームは一度インストールするとすべてのゲームリソース（テキストや画像、音声など）がディスクに配置され、
ゲーム起動後に動的にダウンロードすることはほぼない。
よって、 <strong>ゲーム起動後に生じたファイルの差分は基本すべてセーブデータ関連</strong> といえる。</p>

<p>このように「ファイルの変更差分はすべてセーブデータ」とすればセーブデータの場所を機械的に特定できるのではないかと考えた。</p>

<h2>overlayfsによる差分検出</h2>

<p>ファイルの変更差分を検出する方法としてはLinuxのinotifyを最初思い浮かべたが、他にも探してみたところ <strong>overlayfs</strong> というファイルシステムを見つけた。
overlayfs は「下層のファイルシステム」と「下層からの変更差分」を重ね合わせてひとつのファイルシステムのように見せるLinuxの機能である。
この特性がそのままノベルゲームのセーブデータ検出に使えるというわけだ。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/c/castaneai/20220511/20220511210305.png" width="611" height="436" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>図のように、下層のファイルシステムをインストール直後のゲームデータとすると、下層からの変更差分がセーブデータとして検出できる。</p>

<p>overlayfs は次のようにLinuxのmountコマンドで作成できる。
下層のディレクトリ (lowerdir)、変更差分のディレクトリ (upperdir)、そして両方を重ねあわせたディレクトリ（この例では <code>/merged</code>）を指定できるようになっている<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>。</p>

<pre class="code lang-sh" data-lang="sh" data-unlink>mount <span class="synSpecial">-t</span> overlay overlay <span class="synSpecial">-o</span> <span class="synIdentifier">lowerdir</span>=/<span class="synIdentifier">lower,upperdir</span>=/<span class="synIdentifier">upper,workdir</span>=/work /merged
</pre>


<p>マウント後、基本的には重ね合わせ後の <code>/merged</code> で作業をする。
そこで下層の <code>/lower</code> にあったものはそのまま残っているし、新しくファイルを作ったり変更を加えたりすることもできるので普通のディレクトリと一見変わらないように感じる。</p>

<p>しかし、内部では面白い構造になっていて、もともとの下層 <code>/lower</code> 以下には何も変更は加わらず、新しく作ったファイルや修正したファイルは上層の <code>/upper</code> に保存されている。よって <strong>ゲーム終了後に <code>/upper</code> の中身を抽出するとセーブデータのみをきれいに取り出せる。</strong>
これでゲームごとに個別の設定を持たずに汎用的にセーブデータを抽出する機能として利用できるようになった。</p>

<h2>Kubernetesによる動的なoverlayfsマウント</h2>

<p>OOPartsのクラウドゲーミングは基本Kubernetes上で動いており、Linuxコンテナ上で<a href="https://www.winehq.org/">Wine</a> を使ってゲームを起動している。
よってコンテナの内部でゲーム起動要求に応じて動的に overlayfs を作り出しゲームプレイ環境を準備している。</p>

<p>これをKubernetes上で実現するためにはいくつかポイントがある。</p>

<ul>
<li>コンテナ内のoverlayfs</li>
<li>コンテナ内でのmountと別コンテナへの反映</li>
<li>下層となるゲームデータをどうやって用意するか</li>
</ul>


<h3>コンテナ内のoverlayfs</h3>

<p>overlayfsはDocker等のコンテナ技術で既によく使われている技術であり、コンテナの実行環境も実はoverlayfsのファイルシステムとなっている。
すでにoverlayfsの環境の上にさらにoverlayfsを被せようとするとdmesgに次のようなエラーが出る。</p>

<pre class="code" data-lang="" data-unlink>overlayfs: filesystem on &#39;/upper&#39; not supported as upperdir</pre>


<p>overlayfsの変更差分を格納するディレクトリはoverlayfs以外のファイルシステムにしなければならない。
よってコンテナ上でoverlayfs mountをする場合はtmpfs等他のファイルシステム上にあるディレクトリを指定すればよい。</p>

<h3>コンテナ内でのmountと別コンテナへの反映</h3>

<p>コンテナ内から普通に mount システムコールを実行すると権限が足りずエラーになってしまう。
たとえば、<a href="https://kazuhira-r.hatenablog.com/entry/20180220/1519112450">Dockerコンテナ内でmountを実行するためには CAP_SYS_ADMIN と apparmor:unconfined というオプションが必要</a> となり、コンテナにかなり強めの権限が必要になる。</p>

<p>セキュリティを考えるとゲームを実行するコンテナに強い権限を与えるのは避けたい。
そこで、overlayfs のマウントは専用のコンテナに任せて、ゲーム実行のコンテナとは分離する手法を取った。
しかし、コンテナが分離するとファイルシステムも分離されてしまうので異なるコンテナ間でマウントを共有する仕組みが必要になる。
そこでKubernetesの機能にある <a href="https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation">Mount Propagation</a> を利用した。</p>

<p>Mount Propagationはあまり聞き慣れない機能かもしれないが、リンク先のドキュメントにある通りコンテナ内でのマウントを他のコンテナにも反映させたり、逆にホスト側のマウントをコンテナ内に反映したりが可能になる機能。
overlayfsのマウントだけを特権コンテナで行い、それをゲーム実行側のコンテナに反映させるという今回の要件にはちょうど良い機能である。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/c/castaneai/20220511/20220511215436.png" width="530" height="380" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>しかし、図を見てもわかる通りコンテナの内側から外側に干渉するためトラブルが発生するとノード全体に悪影響を与えてしまう可能性があるので慎重に使う必要がある。
たとえばアンマウント処理を適切にせずにコンテナが終了するとPodがTerminatingから進まなくなる、なんてことが過去にあった（ノードに直接SSHで踏み込んで修正作業した…）。</p>

<h3>下層となるゲームデータをどうやって用意するか</h3>

<p>当然だがゲームを起動するためにはゲームの完全なデータが必要だ。
ただし、何のゲームが起動されるかはプレイヤーのゲームセッションが開始しないとわからない。よってコンテナイメージに事前にゲームを一緒に含めておくのは厳しい。
また、ゲームデータはサイズが大きく数百MB〜数GBの容量がある。よって起動時にゲームデータをダウンロードするのも厳しい。</p>

<p>そこで、NFS Serverにゲームデータを格納しそれを直接Kubernetesのホストマシンにvolume mountし、overlayfsの下層として指定する。
overlayfsと組み合わせることで保管元のNFS Serverを変更することなく、変更差分つまりセーブデータだけを抽出して別のストレージにアップロードできる。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/c/castaneai/20220511/20220511220409.png" width="841" height="385" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<h2>まとめ</h2>

<p>OOPartsではノベルゲームをクラウド上で動かすにあたり、下層のディレクトリとそこからの差分を重ね合わせるoverlayfsをセーブデータ検出に利用している。
また、Kubernetes上で高速なゲーム起動と一定のセキュリティを満たすためにVolume Mountの機能も活用している。</p>

<p>このようなLinuxやKubernetesの機能をノベルゲームのセーブデータ検出のために使っているというのはなかなか珍しい（？）例だと思うのでなにかの参考になれば幸いです。</p>
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<p>workdir というのも必要だが、これは作業用のディレクトリなので直接触る機会はない。適当にそれ用の一時ディレクトリを作っておけばよい<a href="#fnref:1" rev="footnote">&#8617;</a></p></li>
</ol>
</div>



クラウド上でゲームを動かす場合、データ（ゲーム本体のデータ・セーブデータ）をどう管理するかは重要な課題のひとつだ。そこで、自分が開発に携わっているOOParts のデータ管理を支える技術について紹介する。ノベルゲームのセーブ事情OOPartsで提供されているのは主にビジュアルノベルゲームで、セーブデータの形式や場所は実に多種多様である。ゲーム本体と同じディレクトリにセーブデータを保存するゲームもあれば、ユーザーディレクトリ（マイドキュメント等）以下に保存するゲームもある。とにかく様々な保存方式があるため複数メーカーのゲームを提供するとなると セーブデータの場所を機械的に特定できない。唯一言えるのはほとんどのゲームはセーブデータをファイルに保存しているということぐらいだ。ゲームタイトル毎に設定を持ち、「ゲームAのセーブデータは〇〇で、ゲームBのセーブデータは〇〇で…」とすれば不可能ではないがこれでは新しいゲームタイトルを追加する度に工数がかかるので避けたい。セーブデータは「ファイルの変更差分」と考えるそこで発想を少し変えみることにした。ノベルゲームは一度インストールするとすべてのゲームリソース（テキストや画像、音声など）がディスクに配置され、ゲーム起動後に動的にダウンロードすることはほぼない。よって、 ゲーム起動後に生じたファイルの差分は基本すべてセーブデータ関連 といえる。このように「ファイルの変更差分はすべてセーブデータ」とすればセーブデータの場所を機械的に特定できるのではないかと考えた。overlayfsによる差分検出ファイルの変更差分を検出する方法としてはLinuxのinotifyを最初思い浮かべたが、他にも探してみたところ overlayfs というファイルシステムを見つけた。overlayfs は「下層のファイルシステム」と「下層からの変更差分」を重ね合わせてひとつのファイルシステムのように見せるLinuxの機能である。この特性がそのままノベルゲームのセーブデータ検出に使えるというわけだ。図のように、下層のファイルシステムをインストール直後のゲームデータとすると、下層からの変更差分がセーブデータとして検出できる。overlayfs は次のようにLinuxのmountコマンドで作成できる。下層のディレクトリ (lowerdir)、変更差分のディレクトリ (upperdir)、そして両方を重ねあわせたディレクトリ（この例では /merged）を指定できるようになっている1。mount -t overlay overlay -o lowerdir=/lower,upperdir=/upper,workdir=/work /mergedマウント後、基本的には重ね合わせ後の /merged で作業をする。そこで下層の /lower にあったものはそのまま残っているし、新しくファイルを作ったり変更を加えたりすることもできるので普通のディレクトリと一見変わらないように感じる。しかし、内部では面白い構造になっていて、もともとの下層 /lower 以下には何も変更は加わらず、新しく作ったファイルや修正したファイルは上層の /upper に保存されている。よって ゲーム終了後に /upper の中身を抽出するとセーブデータのみをきれいに取り出せる。これでゲームごとに個別の設定を持たずに汎用的にセーブデータを抽出する機能として利用できるようになった。Kubernetesによる動的なoverlayfsマウントOOPartsのクラウドゲーミングは基本Kubernetes上で動いており、Linuxコンテナ上でWine を使ってゲームを起動している。よってコンテナの内部でゲーム起動要求に応じて動的に overlayfs を作り出しゲームプレイ環境を準備している。これをKubernetes上で実現するためにはいくつかポイントがある。コンテナ内のoverlayfsコンテナ内でのmountと別コンテナへの反映下層となるゲームデータをどうやって用意するかコンテナ内のoverlayfsoverlayfsはDocker等のコンテナ技術で既によく使われている技術であり、コンテナの実行環境も実はoverlayfsのファイルシステムとなっている。すでにoverlayfsの環境の上にさらにoverlayfsを被せようとするとdmesgに次のようなエラーが出る。overlayfs: filesystem on '/upper' not supported as upperdiroverlayfsの変更差分を格納するディレクトリはoverlayfs以外のファイルシステムにしなければならない。よってコンテナ上でoverlayfs mountをする場合はtmpfs等他のファイルシステム上にあるディレクトリを指定すればよい。コンテナ内でのmountと別コンテナへの反映コンテナ内から普通に mount システムコールを実行すると権限が足りずエラーになってしまう。たとえば、Dockerコンテナ内でmountを実行するためには CAP_SYS_ADMIN と apparmor:unconfined というオプションが必要 となり、コンテナにかなり強めの権限が必要になる。セキュリティを考えるとゲームを実行するコンテナに強い権限を与えるのは避けたい。そこで、overlayfs のマウントは専用のコンテナに任せて、ゲーム実行のコンテナとは分離する手法を取った。しかし、コンテナが分離するとファイルシステムも分離されてしまうので異なるコンテナ間でマウントを共有する仕組みが必要になる。そこでKubernetesの機能にある Mount Propagation を利用した。Mount Propagationはあまり聞き慣れない機能かもしれないが、リンク先のドキュメントにある通りコンテナ内でのマウントを他のコンテナにも反映させたり、逆にホスト側のマウントをコンテナ内に反映したりが可能になる機能。overlayfsのマウントだけを特権コンテナで行い、それをゲーム実行側のコンテナに反映させるという今回の要件にはちょうど良い機能である。しかし、図を見てもわかる通りコンテナの内側から外側に干渉するためトラブルが発生するとノード全体に悪影響を与えてしまう可能性があるので慎重に使う必要がある。たとえばアンマウント処理を適切にせずにコンテナが終了するとPodがTerminatingから進まなくなる、なんてことが過去にあった（ノードに直接SSHで踏み込んで修正作業した…）。下層となるゲームデータをどうやって用意するか当然だがゲームを起動するためにはゲームの完全なデータが必要だ。ただし、何のゲームが起動されるかはプレイヤーのゲームセッションが開始しないとわからない。よってコンテナイメージに事前にゲームを一緒に含めておくのは厳しい。また、ゲームデータはサイズが大きく数百MB〜数GBの容量がある。よって起動時にゲームデータをダウンロードするのも厳しい。そこで、NFS Serverにゲームデータを格納しそれを直接Kubernetesのホストマシンにvolume mountし、overlayfsの下層として指定する。overlayfsと組み合わせることで保管元のNFS Serverを変更することなく、変更差分つまりセーブデータだけを抽出して別のストレージにアップロードできる。まとめOOPartsではノベルゲームをクラウド上で動かすにあたり、下層のディレクトリとそこからの差分を重ね合わせるoverlayfsをセーブデータ検出に利用している。また、Kubernetes上で高速なゲーム起動と一定のセキュリティを満たすためにVolume Mountの機能も活用している。このようなLinuxやKubernetesの機能をノベルゲームのセーブデータ検出のために使っているというのはなかなか珍しい（？）例だと思うのでなにかの参考になれば幸いです。workdir というのも必要だが、これは作業用のディレクトリなので直接触る機会はない。適当にそれ用の一時ディレクトリを作っておけばよい↩

overlayfs を用いたクラウドゲームのデータ管理

Agones はなぜ、どのようにPodへの直接接続を実現しているか - castaneaiのブログ

ノベルゲームのテキストをリアルタイムに抽出するツール Textractor がすごい - castaneaiのブログ

Windows: memory-mapped fileの中身を直接見る - castaneaiのブログ

<p>年の瀬になったので、あらためて今年学んだ技術を振り返っていく。</p>

<h2>クラウドゲーミングの開発</h2>

<p>2021年はほぼ全て<a href="https://oo.parts">OOParts</a>のクラウドゲーミング (<a href="https://blog.oo.parts/2021/06/11/release-2021-06-01/">Black Game Streaming Engine v2</a> )の開発に費やした。
経緯は <a href="http://blog.hatena.ne.jp/oliver0521/">id:oliver0521</a> によるCEDECの発表の通りで、Windows Serverのコストが高すぎるのでなんとか改善できないだろうかという話からだった。</p>

<p><a href="https://speakerdeck.com/oliver_diary/number-cedec2021">&#x8FEB;&#x308A;&#x6765;&#x308B;&#x7D76;&#x671B;&#x7684;&#x72B6;&#x6CC1;&#x304B;&#x3089;&#x306E;&#x8131;&#x5374;&#x7269;&#x8A9E; / #CEDEC2021 - Speaker Deck</a></p>

<p>Windows Serverを捨ててLinux + Wineでやれたら素晴らしいなぁという発想は2019年からあったが、Wineでどれくらいゲームが動くのかも未知数なので踏み切れずにいた。また、Windows Server時代に使っていた映像配信のSaaSがLinuxに対応してなかったため、もしLinuxでやるなら配信基盤も自前で作る必要もあり、さすがに夢のまま終わりか…という気持ちで止まっていた。</p>

<p>しかし、ある日GUIアプリをコンテナ上で動かし、Webブラウザから操作できる<a href="https://github.com/nurdism/neko">neko</a> というOSSを発見し、
これを参考にすれば配信基盤が作れるのでは？と思って空いた時間に研究開発を始めた。
そしてひとつのゲームタイトルがLinux + Wine + Dockerで動作し、WebRTC経由でブラウザから操作できるPoCが完成したので、これを社内に伝えたら良い反応が得られ本格的にWindows Serverベースからの移行プロジェクトが始まった。</p>

<p>動作するOSも変わって配信基盤も変わるなら、いっそ全部書き直そうと決意してバックエンドをほぼ全部新規開発した。
この内部の話はGo Conference 2021 Autumnで発表した。</p>

<p><a href="https://castaneai.hatenablog.com/entry/go-conference-2021-autumn-cloud-gaming">Go Conference&#x3067;&#x30AF;&#x30E9;&#x30A6;&#x30C9;&#x30B2;&#x30FC;&#x30DF;&#x30F3;&#x30B0;&#x306A;&#x767A;&#x8868;&#x3092;&#x3057;&#x305F; - castaneai&#x306E;&#x30D6;&#x30ED;&#x30B0;</a></p>

<h2>WebRTC / GStreamer</h2>

<p>配信基盤を自前で作ることになり、WebRTCという技術を採用した。
Pion WebRTCを使ったので0からWebRTCを開発したわけではないが、ゲーム画面の映像・音声を生成する部分とP2P接続の確立（シグナリング）部分はWebRTCでは提供されてないため独自で書く必要がある。</p>

<p>まず、ゲーム画面の映像・音声を生成する部分は<a href="https://gstreamer.freedesktop.org/">GStreamer</a> という技術を採用した。これは<a href="https://selkies.io/">Selkies</a> というリモートデスクトップのOSSが内部で使っていたためそれを参考に配信のパイプラインを構築した。</p>

<p>次にシグナリングについて、当初は<a href="https://github.com/OpenAyame/ayame">Ayame</a> というシグナリングサーバーを用いていたが、Cloud Nativeな環境で扱うにあたって直したい点があったので、Ayameのプロトコルだけ使わせていただきつつ、独自のシグナリングサーバーを開発した。</p>

<p><a href="https://castaneai.hatenablog.com/entry/webrtc-signaling-server-ayu">Ayame&#x4E92;&#x63DB;&#x306E; WebRTC Signaling Server &quot;ayu&quot; &#x3092;&#x4F5C;&#x3063;&#x305F; - castaneai&#x306E;&#x30D6;&#x30ED;&#x30B0;</a></p>

<h2>Kubernetes</h2>

<p>開発したクラウドゲーミング基盤を実サービスとして耐えうる作りにするにはインフラの基盤も重要だった。
Kubernetes、以前からなんとなく知ってたが、わかったようでいまいちわからなかった。そこであれこれ資料を漁るよりも実際にクラスターを立ててクラウドゲーミング基盤を乗せてみるしかない！と思い立ってクラウドゲーミングの一連のプレイが回るところまでとにかくがんばって試行錯誤した。
そしたら急に <strong>Kubernetesのこと…完全に理解したかもしれない… </strong> って思えるほど色々な概念が頭の中でつながって最高だった。こういうものは座学よりも実際にアプリを立てて触って壊したりして覚えるのが一番良いと実感できた例だった。</p>

<p>ゲームのセーブデータ領域を動的に作成するために<a href="https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation">Mount Propagation</a> という機能を使ったらPodがTerminatingのまま残り続ける問題が発生してしまい、原因調査と周辺知識の学習にかなり時間がかかった。しかし、この問題のおかげでkubeletという存在を知り、Kubernetesの内部のコンポーネントの構造や流れが見えて楽しかった。</p>

<p>さらに、クラウドゲーミングのようなStateful Game Serverに適した<a href="https://agones.dev/site/">Agones</a> の採用も重要だった。以前から存在は知っていたものの実運用するとこのような課題があるのかという気付きが多くあった。詳しくは <a href="http://blog.hatena.ne.jp/yu_suke1994/">id:yu_suke1994</a> が発表してくれた。</p>

<p><a href="https://note.com/unasuke/n/n861b9a5f1ebb">&#x306A;&#x305C;&#x6211;&#x3005;&#x306F;&#x30AF;&#x30E9;&#x30A6;&#x30C9;&#x30B2;&#x30FC;&#x30DF;&#x30F3;&#x30B0;&#x57FA;&#x76E4;&#x3092;Kubernetes&#x306B;&#x79FB;&#x884C;&#x3057;&#x305F;&#x306E;&#x304B; #CNDT2021&#xFF5C;&#x3046;&#x306A;&#x3059;&#x3051;&#xFF5C;note</a></p>

<p>他にはKubernetes上でGPUを使ったゲームを提供するためにContainer with GPUな技術について学び、コンテナランタイムやLinuxのデバイス周りの知識がついた。このあたりの知見は <a href="http://blog.hatena.ne.jp/Mitu217/">id:Mitu217</a> が発表してくれた。</p>

<p><a href="https://speakerdeck.com/mitu217/number-k8sjp">Running GPU-bound games on Kubernetes / #k8sjp - Speaker Deck</a></p>

<p>Kubernetesを学ぶにあたってローカル環境で高速なiterationが回せるのは重要だと考え、minikubeやkindの勉強もした。
ローカル環境とリモート環境（主にGKE）での差異をできるだけなくしつつ、お手軽さも失わないためにはどうすればいいかと試行錯誤をした。
結果としてkustomizeや仮想化技術について少し詳しくなった。</p>

<p><a href="https://zenn.dev/castaneai/articles/local-kubernetes-networking">&#x30ED;&#x30FC;&#x30AB;&#x30EB;Kubernetes&#x74B0;&#x5883;&#x306E;&#x30CD;&#x30C3;&#x30C8;&#x30EF;&#x30FC;&#x30AF;&#x3092;&#x653B;&#x7565;&#x3059;&#x308B;</a></p>

<h2>Wine</h2>

<p>LinuxとWebRTCによるクラウドゲーミング基盤が実現可能とわかったのは良かったが、Wineでどれくらいゲームが動くのかという点に関しては不安が残っていた。
実際にOOPartsのゲームタイトルをいくつかWineで動かしてみると意外と多くのゲームが動いた…が、完璧ではなかった。</p>

<p>Wineが完璧ではない以上仕方ないと諦めかけたが、よく考えたらWineはOSSである。これはWine側を修正することだってできるのでは？と思い、Wineへのコントリビュートを始めた。bug trackerに検証結果を提供したり、ときにはパッチを送ってWine本体に取り込んでもらった。これで当初動かなかったゲームがいくつか動くようになった。</p>

<ul>
<li><a href="https://github.com/wine-mirror/wine/commit/8116d4e11cd11ba466c1cd92a6a81ca015e230e0">dsound: Notify DSBPN_OFFSETSTOP earlier. · wine-mirror/wine@8116d4e</a></li>
<li><a href="https://github.com/wine-mirror/wine/commit/d05dd4460c69cb749918a61dbaea35285a5cb8ee">msgsm32.acm: Msgsm32 should not perform PCM-to-PCM conversion. · wine-mirror/wine@d05dd44</a></li>
</ul>


<p>日本語圏のWine開発者というのはまだ少ないように思えたので、次のような記事を書いて今後の新しいContributionをやりやすくする運動もしている。</p>

<ul>
<li><a href="https://zenn.dev/castaneai/articles/wine-video-gstreamer">Wineの動画再生のしくみ、DirectShowとGStreamerの関係</a></li>
<li><a href="https://zenn.dev/castaneai/articles/contributing-to-wine">Wineへコントリビュートする方法</a></li>
</ul>


<p>Wineに関してはまだまだ修正したい箇所があるので現在も進行形でパッチを書いている。
来年にはさらに多くのゲームが動くようにしていきたい。</p>


年の瀬になったので、あらためて今年学んだ技術を振り返っていく。クラウドゲーミングの開発2021年はほぼ全てOOPartsのクラウドゲーミング (Black Game Streaming Engine v2 )の開発に費やした。経緯は id:oliver0521 によるCEDECの発表の通りで、Windows Serverのコストが高すぎるのでなんとか改善できないだろうかという話からだった。迫り来る絶望的状況からの脱却物語 / #CEDEC2021 - Speaker DeckWindows Serverを捨ててLinux + Wineでやれたら素晴らしいなぁという発想は2019年からあったが、Wineでどれくらいゲームが動くのかも未知数なので踏み切れずにいた。また、Windows Server時代に使っていた映像配信のSaaSがLinuxに対応してなかったため、もしLinuxでやるなら配信基盤も自前で作る必要もあり、さすがに夢のまま終わりか…という気持ちで止まっていた。しかし、ある日GUIアプリをコンテナ上で動かし、Webブラウザから操作できるneko というOSSを発見し、これを参考にすれば配信基盤が作れるのでは？と思って空いた時間に研究開発を始めた。そしてひとつのゲームタイトルがLinux + Wine + Dockerで動作し、WebRTC経由でブラウザから操作できるPoCが完成したので、これを社内に伝えたら良い反応が得られ本格的にWindows Serverベースからの移行プロジェクトが始まった。動作するOSも変わって配信基盤も変わるなら、いっそ全部書き直そうと決意してバックエンドをほぼ全部新規開発した。この内部の話はGo Conference 2021 Autumnで発表した。Go Conferenceでクラウドゲーミングな発表をした - castaneaiのブログWebRTC / GStreamer配信基盤を自前で作ることになり、WebRTCという技術を採用した。Pion WebRTCを使ったので0からWebRTCを開発したわけではないが、ゲーム画面の映像・音声を生成する部分とP2P接続の確立（シグナリング）部分はWebRTCでは提供されてないため独自で書く必要がある。まず、ゲーム画面の映像・音声を生成する部分はGStreamer という技術を採用した。これはSelkies というリモートデスクトップのOSSが内部で使っていたためそれを参考に配信のパイプラインを構築した。次にシグナリングについて、当初はAyame というシグナリングサーバーを用いていたが、Cloud Nativeな環境で扱うにあたって直したい点があったので、Ayameのプロトコルだけ使わせていただきつつ、独自のシグナリングサーバーを開発した。Ayame互換の WebRTC Signaling Server "ayu" を作った - castaneaiのブログKubernetes開発したクラウドゲーミング基盤を実サービスとして耐えうる作りにするにはインフラの基盤も重要だった。Kubernetes、以前からなんとなく知ってたが、わかったようでいまいちわからなかった。そこであれこれ資料を漁るよりも実際にクラスターを立ててクラウドゲーミング基盤を乗せてみるしかない！と思い立ってクラウドゲーミングの一連のプレイが回るところまでとにかくがんばって試行錯誤した。そしたら急に Kubernetesのこと…完全に理解したかもしれない…  って思えるほど色々な概念が頭の中でつながって最高だった。こういうものは座学よりも実際にアプリを立てて触って壊したりして覚えるのが一番良いと実感できた例だった。ゲームのセーブデータ領域を動的に作成するためにMount Propagation という機能を使ったらPodがTerminatingのまま残り続ける問題が発生してしまい、原因調査と周辺知識の学習にかなり時間がかかった。しかし、この問題のおかげでkubeletという存在を知り、Kubernetesの内部のコンポーネントの構造や流れが見えて楽しかった。さらに、クラウドゲーミングのようなStateful Game Serverに適したAgones の採用も重要だった。以前から存在は知っていたものの実運用するとこのような課題があるのかという気付きが多くあった。詳しくは id:yu_suke1994 が発表してくれた。なぜ我々はクラウドゲーミング基盤をKubernetesに移行したのか #CNDT2021｜うなすけ｜note他にはKubernetes上でGPUを使ったゲームを提供するためにContainer with GPUな技術について学び、コンテナランタイムやLinuxのデバイス周りの知識がついた。このあたりの知見は id:Mitu217 が発表してくれた。Running GPU-bound games on Kubernetes / #k8sjp - Speaker DeckKubernetesを学ぶにあたってローカル環境で高速なiterationが回せるのは重要だと考え、minikubeやkindの勉強もした。ローカル環境とリモート環境（主にGKE）での差異をできるだけなくしつつ、お手軽さも失わないためにはどうすればいいかと試行錯誤をした。結果としてkustomizeや仮想化技術について少し詳しくなった。ローカルKubernetes環境のネットワークを攻略するWineLinuxとWebRTCによるクラウドゲーミング基盤が実現可能とわかったのは良かったが、Wineでどれくらいゲームが動くのかという点に関しては不安が残っていた。実際にOOPartsのゲームタイトルをいくつかWineで動かしてみると意外と多くのゲームが動いた…が、完璧ではなかった。Wineが完璧ではない以上仕方ないと諦めかけたが、よく考えたらWineはOSSである。これはWine側を修正することだってできるのでは？と思い、Wineへのコントリビュートを始めた。bug trackerに検証結果を提供したり、ときにはパッチを送ってWine本体に取り込んでもらった。これで当初動かなかったゲームがいくつか動くようになった。dsound: Notify DSBPN_OFFSETSTOP earlier. · wine-mirror/wine@8116d4emsgsm32.acm: Msgsm32 should not perform PCM-to-PCM conversion. · wine-mirror/wine@d05dd44日本語圏のWine開発者というのはまだ少ないように思えたので、次のような記事を書いて今後の新しいContributionをやりやすくする運動もしている。Wineの動画再生のしくみ、DirectShowとGStreamerの関係Wineへコントリビュートする方法Wineに関してはまだまだ修正したい箇所があるので現在も進行形でパッチを書いている。来年にはさらに多くのゲームが動くようにしていきたい。

2021年の技術的ふりかえり

<p><a href="https://gocon.jp/2021autumn/">Go Conference 2021 Autumn</a> で Cloud Gaming Platform with Goという発表をした。</p>

<p><iframe id="talk_frame_796073" class="speakerdeck-iframe" src="//speakerdeck.com/player/223db0bd502a46119f5ce7941c70e3d8" width="710" height="399" style="aspect-ratio:710/399; border:0; padding:0; margin:0; background:transparent;" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe> <cite class="hatena-citation"><a href="https://speakerdeck.com/castaneai/cloud-gaming-platform-with-go">speakerdeck.com</a></cite></p>

<p><a href="https://oo.parts/">OOParts</a> のインフラコストが問題になり、2021年に新たにクラウドゲーミングのエンジンを作り直した。
くわしい経緯は以下の資料にまとまっている。</p>

<ul>
<li><a href="https://speakerdeck.com/oliver_diary/number-cedec2021">&#x8FEB;&#x308A;&#x6765;&#x308B;&#x7D76;&#x671B;&#x7684;&#x72B6;&#x6CC1;&#x304B;&#x3089;&#x306E;&#x8131;&#x5374;&#x7269;&#x8A9E; / #CEDEC2021 - Speaker Deck</a></li>
<li><a href="https://note.com/unasuke/n/n861b9a5f1ebb">&#x306A;&#x305C;&#x6211;&#x3005;&#x306F;&#x30AF;&#x30E9;&#x30A6;&#x30C9;&#x30B2;&#x30FC;&#x30DF;&#x30F3;&#x30B0;&#x57FA;&#x76E4;&#x3092;Kubernetes&#x306B;&#x79FB;&#x884C;&#x3057;&#x305F;&#x306E;&#x304B; #CNDT2021&#xFF5C;&#x3046;&#x306A;&#x3059;&#x3051;&#xFF5C;note</a></li>
</ul>


<p>この2つの発表では全体的な経緯とインフラの構築をどうやったかが語られている。
では、アプリケーション部分についても発表したいよねって話になり、Go ConferenceにCFPを送ってこの発表に至った。</p>

<p>内容はスライドを見てもらえればいいとして、この記事では発表内容には入らなかった補足、余談をすこししてみる。</p>

<h2>Goで実装して苦労した点</h2>

<p>発表ではなぜGoを選んだかを中心に良かった点を並べたが、もちろん苦労した点もある。
GoroutinesとChannelは非同期処理を扱いやすいとはいっても、何も考えずに使うと罠にかかる。</p>

<p>まずはGoroutineの寿命管理。goroutineは関数がreturnしない限り終了することはない。
よって適切な寿命管理ができていないと無駄なgoroutineが裏で増え続けることがある。この問題はgoroutine leakと呼ばれる。</p>

<p>特にクラウドゲーミングのように長時間続くセッションを扱っているとgoroutine leakが発生しやすい。
実際にひとつのゲームセッション中に何度も切断接続を繰り返すとgoroutineが増えていく問題が起こったこともある。
pprofのgoroutine dumpを使えば原因特定は容易だが、気をつけているつもりでもうっかりgoroutine leakをやってしまう。
静的解析とかで早めに検出できたらいいのにな〜と感じた。</p>

<p>次に、Channelの扱い。channelは異なるgoroutine間でデータのやり取りをするのに便利だが、問題も起きやすい。
channelのバッファサイズが0の場合、誰かがchannelからデータを受信するまで送信がブロックされる。
よってこのchannelはどのgoroutineが送信しようとしていて、どのgoroutineが受信しようとしているのかを把握しておかないと、
アプリケーション全体が止まってしまった、しかしどこで止まっているのかわからない…という問題に陥りやすい。
単純にバッファサイズを増やせばいいのでは？と考えそうになるが、それでは根本解決にならない（使用メモリを増やして問題を先延ばししているだけだ）。
さらに、channelのclose処理はブロックされないという点や、同じchannelを2回closeするとpanicが発生するといった仕様があるので理解した上で扱う必要がある。</p>

<p>また、pub/subのように1つのデータを複数の受信者に配りたい場合が面倒だった。1つのinput channelと複数のoutput channelからなる構造体を作ったのだが、現時点のGoはgenericsに対応していないためchannelに流すデータの型ごとに構造体を分けるか、<code>interface{}</code> を使って型情報を曖昧にするしかない。</p>

<h2>Go Conferenceの運営について</h2>

<p>オンラインでの勉強会登壇というのは初でちゃんとできるだろうかと不安だったのだが、Go Conferenceの運営の方はSlackへの案内、そして事前のリハーサルまで丁寧にしてくれておかげで当日は何もトラブルなく発表ができたので大変感謝している。</p>

<h2>Ask the speakerについて</h2>

<p>発表後はremoというサービスで発表者に質問できる形式になっているが、このサービスはアカウントを作らないと入室できない上に、仮想空間のような場所で発表者の近くまで移動して通話を開始しないと話しかけられない。よって発表を聞いた人が質問を投げに行くのはハードルが高いのではと感じた。</p>

<p>そのせいか、質問に来た人はほぼいなくて最終的に発表者同士で雑談していたりしてAsk the speakerの時間をすごした。
あまり発表者が集まりすぎても今度はまたその輪の中にいきなり入って質問するというのも勇気がいるし、気楽に聞けるAsk the speakerというのはどうあるべきなのかなぁと考えていた（答えは出てないが…）。</p>

<h2>発表中にあった質問について</h2>

<p>発表後にTwitterなどで見かけた質問らしい投稿がいくつかあったので自分なりの回答を書いておく。</p>

<h4>koはbuildpacksと比べてどうなのか</h4>

<p>buildpacksもkoと同様にDockerfile不要でコンテナイメージを作成できるツールだが、さまざまな言語に対応しているbuildpacksと違ってkoはGoのみに特化しているツールで、buildpacksよりコンパクトでビルド速度が速いのが特徴かと思われる。</p>

<p>Google CloudのブログでDockerやbuildpacksとの速度比較が載っているのでこの記事が参考になる。</p>

<p><a href="https://cloud.google.com/blog/topics/developers-practitioners/ship-your-go-applications-faster-cloud-run-ko">Ship your Go applications faster to Cloud Run with ko | Google Cloud Blog</a></p>

<h4>gocloudにおいて特定サービス固有の機能を使いたくなったらどうするのか</h4>

<p>OOPartsの実装範囲内では特定サービスに依存した機能を使わざるを得ないケースはなかったのだが、
gocloudのドキュメントを見る限り、 <code>As()</code> 関数を使って特定サービスの構造体にキャストするしかないらしい。</p>

<p><a href="https://gocloud.dev/concepts/as/">Using provider-specific APIs &middot; Go CDK</a></p>


Go Conference 2021 Autumn で Cloud Gaming Platform with Goという発表をした。 speakerdeck.comOOParts のインフラコストが問題になり、2021年に新たにクラウドゲーミングのエンジンを作り直した。くわしい経緯は以下の資料にまとまっている。迫り来る絶望的状況からの脱却物語 / #CEDEC2021 - Speaker Deckなぜ我々はクラウドゲーミング基盤をKubernetesに移行したのか #CNDT2021｜うなすけ｜noteこの2つの発表では全体的な経緯とインフラの構築をどうやったかが語られている。では、アプリケーション部分についても発表したいよねって話になり、Go ConferenceにCFPを送ってこの発表に至った。内容はスライドを見てもらえればいいとして、この記事では発表内容には入らなかった補足、余談をすこししてみる。Goで実装して苦労した点発表ではなぜGoを選んだかを中心に良かった点を並べたが、もちろん苦労した点もある。GoroutinesとChannelは非同期処理を扱いやすいとはいっても、何も考えずに使うと罠にかかる。まずはGoroutineの寿命管理。goroutineは関数がreturnしない限り終了することはない。よって適切な寿命管理ができていないと無駄なgoroutineが裏で増え続けることがある。この問題はgoroutine leakと呼ばれる。特にクラウドゲーミングのように長時間続くセッションを扱っているとgoroutine leakが発生しやすい。実際にひとつのゲームセッション中に何度も切断接続を繰り返すとgoroutineが増えていく問題が起こったこともある。pprofのgoroutine dumpを使えば原因特定は容易だが、気をつけているつもりでもうっかりgoroutine leakをやってしまう。静的解析とかで早めに検出できたらいいのにな〜と感じた。次に、Channelの扱い。channelは異なるgoroutine間でデータのやり取りをするのに便利だが、問題も起きやすい。channelのバッファサイズが0の場合、誰かがchannelからデータを受信するまで送信がブロックされる。よってこのchannelはどのgoroutineが送信しようとしていて、どのgoroutineが受信しようとしているのかを把握しておかないと、アプリケーション全体が止まってしまった、しかしどこで止まっているのかわからない…という問題に陥りやすい。単純にバッファサイズを増やせばいいのでは？と考えそうになるが、それでは根本解決にならない（使用メモリを増やして問題を先延ばししているだけだ）。さらに、channelのclose処理はブロックされないという点や、同じchannelを2回closeするとpanicが発生するといった仕様があるので理解した上で扱う必要がある。また、pub/subのように1つのデータを複数の受信者に配りたい場合が面倒だった。1つのinput channelと複数のoutput channelからなる構造体を作ったのだが、現時点のGoはgenericsに対応していないためchannelに流すデータの型ごとに構造体を分けるか、interface{} を使って型情報を曖昧にするしかない。Go Conferenceの運営についてオンラインでの勉強会登壇というのは初でちゃんとできるだろうかと不安だったのだが、Go Conferenceの運営の方はSlackへの案内、そして事前のリハーサルまで丁寧にしてくれておかげで当日は何もトラブルなく発表ができたので大変感謝している。Ask the speakerについて発表後はremoというサービスで発表者に質問できる形式になっているが、このサービスはアカウントを作らないと入室できない上に、仮想空間のような場所で発表者の近くまで移動して通話を開始しないと話しかけられない。よって発表を聞いた人が質問を投げに行くのはハードルが高いのではと感じた。そのせいか、質問に来た人はほぼいなくて最終的に発表者同士で雑談していたりしてAsk the speakerの時間をすごした。あまり発表者が集まりすぎても今度はまたその輪の中にいきなり入って質問するというのも勇気がいるし、気楽に聞けるAsk the speakerというのはどうあるべきなのかなぁと考えていた（答えは出てないが…）。発表中にあった質問について発表後にTwitterなどで見かけた質問らしい投稿がいくつかあったので自分なりの回答を書いておく。koはbuildpacksと比べてどうなのかbuildpacksもkoと同様にDockerfile不要でコンテナイメージを作成できるツールだが、さまざまな言語に対応しているbuildpacksと違ってkoはGoのみに特化しているツールで、buildpacksよりコンパクトでビルド速度が速いのが特徴かと思われる。Google CloudのブログでDockerやbuildpacksとの速度比較が載っているのでこの記事が参考になる。Ship your Go applications faster to Cloud Run with ko | Google Cloud Bloggocloudにおいて特定サービス固有の機能を使いたくなったらどうするのかOOPartsの実装範囲内では特定サービスに依存した機能を使わざるを得ないケースはなかったのだが、gocloudのドキュメントを見る限り、 As() 関数を使って特定サービスの構造体にキャストするしかないらしい。Using provider-specific APIs · Go CDK

Go Conferenceでクラウドゲーミングな発表をした

<img src="https://files.speakerdeck.com/presentations/223db0bd502a46119f5ce7941c70e3d8/preview_slide_0.jpg?19533467" /><div><p>Go Conference 2021 Autumn</p></div>

Cloud Gaming Platform with Go

Ayame互換の WebRTC Signaling Server "ayu" を作った - castaneaiのブログ

Wineへコントリビュートする方法

AgonesとKustomizeを同時に使うときのTips - castaneaiのブログ

Kubernetes APIをGoから使う最初の一歩

Pion WebRTC で RTCP Feedback を受け取る

Wineの動画再生のしくみ、DirectShowとGStreamerの関係

ゲームサーバーの「割り当て」設計

PulseAudio (32bit版)がDocker上で動作しない問題の解決法 - castaneaiのブログ

『みずいろ』HDDフォーマット事件は本当だったのか検証する - castaneaiのブログ

fridaでお手軽Windows APIトレース - castaneaiのブログ

Agonesの挙動をGoでテストする - castaneaiのブログ

<p>Googleが <a href="https://agones.dev/site/">Agones</a> というプロジェクトを進めている。
また、<a href="https://cloud.google.com/game-servers">Google Cloud Game Servers</a>というGoogle Cloud上でAgonesを管理できるサービスを発表したことで話題になった。</p>

<p>このAgonesというプロジェクトが何をするもので、何をしないものなのか？</p>

<p>公式サイトを開くと</p>

<blockquote><p>Host, Run and Scale dedicated game servers on Kubernetes</p></blockquote>

<p>と書いてあり、ゲームサーバーを作るための製品であることがわかる。
しかし、Host, Run and Scaleと言われて具体的にAgonesが何をするライブラリなのかがすぐには想像がつきにくい。</p>

<h2>Agonesはマルチプレイ向けゲームエンジンではない</h2>

<p>ゲームサーバー用のライブラリと聞くと、<a href="https://www.photonengine.com/ja/photon">Photon Engine</a> や <a href="http://www.monobitengine.com/">モノビットEngine</a>のように多数のプレイヤー間のメッセージのやり取りをするためのものを想像するかもしれないが、<strong>Agonesはそうではない。</strong></p>

<p>Agonesはゲームのロジック部分にはほとんど関与せず、<strong>ゲームサーバーが動くインフラを管理しやすくするソフトウェアである。</strong>
また、インフラといっても特にAgonesはKubernetesで管理されたインフラであることが前提となっている。</p>

<h2>Agonesが解決する課題</h2>

<p>では、Agonesはゲームサーバーのインフラのどのような課題を解決しているのか。</p>

<h3>スケールインからの保護</h3>

<p>サーバーの数を負荷に応じて自動で増減するという戦略はよくとられる。
状態をほぼ持たないHTTPサーバーなどであれば大抵はうまくいくのだが、ゲームサーバーとなると少し事情が違ってくる。</p>

<p>ゲームサーバーは複数のプレイヤーがサーバーにつないでいて、プレイ中はずっとつなぎっぱなしの<strong>状態を持つ</strong>。
たとえある瞬間は通信が何もなくても、1秒後にはまた何らかの通信をするかもしれない。
ゲームプレイ中に自動増減による削減（スケールイン）が実行されてしまうと、ゲームが突然中断されてしまう。</p>

<p>そこでAgonesは、ゲームサーバー専用の状態を取得・設定可能として、「このサーバーは現在使用中かどうか」をKubernetes上で管理できる。
その上にAgones独自のオートスケール機能があり、それを使うと使用中のサーバーはスケールインからは保護される。</p>

<h3>プレイヤーの直接接続のサポート</h3>

<p>Webアプリなどでは、クライアント（ブラウザやアプリ）からの接続はまずロードバランサーに行き、そこから後ろに控えてるサーバー群のどれかに分散される、という方式が主流だが、ゲームサーバーはまた事情が違ってくる。</p>

<p>たとえば対戦ゲームであれば、同じマップにいるプレイヤーの動きを他のプレイヤーに高速で伝えなければならない。
そうなると、同じゲームに参加するプレイヤーは同じサーバーに接続することになる。</p>

<p>さらに、一度接続したプレイヤーはひとつの試合が終わるまではずっと同じサーバーにつなぎっぱなしになる。
よって、前段にまずロードバランサーを挟んでそこから分散するというやり方は基本的に通用しない。
プレイヤーは直接ゲームサーバーに接続する必要がある。</p>

<p>そこで、Agonesは「今からこのサーバーを使用したい」という要求にあわせて
動的にIPとポート番号を割り当てて外部から直接接続可能にする仕組みが用意されている。</p>

<h3>その他いろいろ</h3>

<p>他にもサーバーの生存確認や、Prometheus exporterなど便利機能がある。
全部書いてると大変なのでここでは省略。</p>

<h2>Agones は Kubernetes の拡張機能である</h2>

<p>ここまではKubernetes特有の用語を使わずに解説したが、Agonesは実は<a href="https://kubernetes.io/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/">Kubernetesの拡張機能（CRD）</a>である。</p>

<p>KubernetesにはPodやDeploymentといった要素があるが、それに似せつつも機能を拡張したGameServerやFleetという要素を作り出し、
<strong>KubernetesのAPIに則って操作できる</strong>。</p>

<p>これがAgonesのとても重要なポイントで、Agonesを管理する操作はAgones独自のプロトコルなどではなく、<strong>KubernetesのAPIで操作できる。</strong></p>

<p>たとえば現在立っているゲームサーバーを一覧したい場合でも、Kubernetesではおなじみの <code>kubectl</code> コマンドが使える。</p>

<pre class="code lang-sh" data-lang="sh" data-unlink>$ kubectl get gameserver
NAME               STATE   ADDRESS     PORT   NODE       AGE
simple-udp-6mjqg   Ready   <span class="synConstant">10</span>.<span class="synConstant">0</span>.<span class="synConstant">2</span>.<span class="synConstant">15</span>   <span class="synConstant">7020</span>   minikube   3s
</pre>


<p>よって、Agonesはこれからインフラ構築のスタンダートとなっていきそうなKubernetesのAPIに乗っかって、ゲームサーバーも同様にいい感じに管理できるようにしたいよね。というテーマで開発されたソフトウェアだということがわかった（多分）。</p>

<h2>今後Agonesは流行るのかどうか？</h2>

<p>Agonesを使うためにはまずKubernetesを用いたインフラ構成が必須だ。
正直、ゲーム業界ではサーバーをKubernetesで管理するということ自体がまだ目新しく、あまり広まってない印象がある。</p>

<p>よって、まずはKubernetesによるゲームサーバーのインフラ構築が当たり前になっていかないと、Agonesが流行るのはむずかしいだろうなぁと思った。</p>

<p>さらに、Agonesが助けてくれるのはインフラ管理の部分だけである。
ゲームサーバーの実装は結局独自で用意しないといけない（しかも、Kubernetesで動作するようにコンテナ化しないといけない）。</p>

<p>オンラインゲームのサーバー実装というのはWebアプリほど民主化されておらず、
オンラインゲームを作っている企業も頑張って自社でエンジンを作っているか、上で挙げたPhoton Engineのようにインフラまで込みで指定されたものを使っているのが現状である<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>。
よってAgonesを導入できたとして、ゲームサーバーの実装はどうやって作るんだという話になり、なかなか採用しにくいのではないかと思う。</p>

<p>しかし、このまま消えていくかというわけではなくコンテナ技術でサーバーを運用するという流れ自体は加速していると感じるので、ゲーム業界もじわじわとコンテナが当たり前になっていくのではないかと思っている。Agonesは現時点では”早すぎる”かもしれないが、Agonesが解決する課題を把握して実装を学ぶことはやっておいて損はないだろう。</p>
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<p>これはあくまでも自分の観測範囲内での話なので、海外まで目を広げるとオープンなものが広まっているのかもしれない…<a href="#fnref:1" rev="footnote">&#8617;</a></p></li>
</ol>
</div>



Googleが Agones というプロジェクトを進めている。また、Google Cloud Game ServersというGoogle Cloud上でAgonesを管理できるサービスを発表したことで話題になった。このAgonesというプロジェクトが何をするもので、何をしないものなのか？公式サイトを開くとHost, Run and Scale dedicated game servers on Kubernetesと書いてあり、ゲームサーバーを作るための製品であることがわかる。しかし、Host, Run and Scaleと言われて具体的にAgonesが何をするライブラリなのかがすぐには想像がつきにくい。Agonesはマルチプレイ向けゲームエンジンではないゲームサーバー用のライブラリと聞くと、Photon Engine や モノビットEngineのように多数のプレイヤー間のメッセージのやり取りをするためのものを想像するかもしれないが、Agonesはそうではない。Agonesはゲームのロジック部分にはほとんど関与せず、ゲームサーバーが動くインフラを管理しやすくするソフトウェアである。また、インフラといっても特にAgonesはKubernetesで管理されたインフラであることが前提となっている。Agonesが解決する課題では、Agonesはゲームサーバーのインフラのどのような課題を解決しているのか。スケールインからの保護サーバーの数を負荷に応じて自動で増減するという戦略はよくとられる。状態をほぼ持たないHTTPサーバーなどであれば大抵はうまくいくのだが、ゲームサーバーとなると少し事情が違ってくる。ゲームサーバーは複数のプレイヤーがサーバーにつないでいて、プレイ中はずっとつなぎっぱなしの状態を持つ。たとえある瞬間は通信が何もなくても、1秒後にはまた何らかの通信をするかもしれない。ゲームプレイ中に自動増減による削減（スケールイン）が実行されてしまうと、ゲームが突然中断されてしまう。そこでAgonesは、ゲームサーバー専用の状態を取得・設定可能として、「このサーバーは現在使用中かどうか」をKubernetes上で管理できる。その上にAgones独自のオートスケール機能があり、それを使うと使用中のサーバーはスケールインからは保護される。プレイヤーの直接接続のサポートWebアプリなどでは、クライアント（ブラウザやアプリ）からの接続はまずロードバランサーに行き、そこから後ろに控えてるサーバー群のどれかに分散される、という方式が主流だが、ゲームサーバーはまた事情が違ってくる。たとえば対戦ゲームであれば、同じマップにいるプレイヤーの動きを他のプレイヤーに高速で伝えなければならない。そうなると、同じゲームに参加するプレイヤーは同じサーバーに接続することになる。さらに、一度接続したプレイヤーはひとつの試合が終わるまではずっと同じサーバーにつなぎっぱなしになる。よって、前段にまずロードバランサーを挟んでそこから分散するというやり方は基本的に通用しない。プレイヤーは直接ゲームサーバーに接続する必要がある。そこで、Agonesは「今からこのサーバーを使用したい」という要求にあわせて動的にIPとポート番号を割り当てて外部から直接接続可能にする仕組みが用意されている。その他いろいろ他にもサーバーの生存確認や、Prometheus exporterなど便利機能がある。全部書いてると大変なのでここでは省略。Agones は Kubernetes の拡張機能であるここまではKubernetes特有の用語を使わずに解説したが、Agonesは実はKubernetesの拡張機能（CRD）である。KubernetesにはPodやDeploymentといった要素があるが、それに似せつつも機能を拡張したGameServerやFleetという要素を作り出し、KubernetesのAPIに則って操作できる。これがAgonesのとても重要なポイントで、Agonesを管理する操作はAgones独自のプロトコルなどではなく、KubernetesのAPIで操作できる。たとえば現在立っているゲームサーバーを一覧したい場合でも、Kubernetesではおなじみの kubectl コマンドが使える。$ kubectl get gameserverNAME               STATE   ADDRESS     PORT   NODE       AGEsimple-udp-6mjqg   Ready   10.0.2.15   7020   minikube   3sよって、Agonesはこれからインフラ構築のスタンダートとなっていきそうなKubernetesのAPIに乗っかって、ゲームサーバーも同様にいい感じに管理できるようにしたいよね。というテーマで開発されたソフトウェアだということがわかった（多分）。今後Agonesは流行るのかどうか？Agonesを使うためにはまずKubernetesを用いたインフラ構成が必須だ。正直、ゲーム業界ではサーバーをKubernetesで管理するということ自体がまだ目新しく、あまり広まってない印象がある。よって、まずはKubernetesによるゲームサーバーのインフラ構築が当たり前になっていかないと、Agonesが流行るのはむずかしいだろうなぁと思った。さらに、Agonesが助けてくれるのはインフラ管理の部分だけである。ゲームサーバーの実装は結局独自で用意しないといけない（しかも、Kubernetesで動作するようにコンテナ化しないといけない）。オンラインゲームのサーバー実装というのはWebアプリほど民主化されておらず、オンラインゲームを作っている企業も頑張って自社でエンジンを作っているか、上で挙げたPhoton Engineのようにインフラまで込みで指定されたものを使っているのが現状である1。よってAgonesを導入できたとして、ゲームサーバーの実装はどうやって作るんだという話になり、なかなか採用しにくいのではないかと思う。しかし、このまま消えていくかというわけではなくコンテナ技術でサーバーを運用するという流れ自体は加速していると感じるので、ゲーム業界もじわじわとコンテナが当たり前になっていくのではないかと思っている。Agonesは現時点では”早すぎる”かもしれないが、Agonesが解決する課題を把握して実装を学ぶことはやっておいて損はないだろう。これはあくまでも自分の観測範囲内での話なので、海外まで目を広げるとオープンなものが広まっているのかもしれない…↩