CNDT 2022、DMMのアーキテクトが解説するSREと開発の責任境界とリソース管理の実際

CNDT 2022から、合同会社DMM.comのアーキテクトが社内向けKubernetesプラットフォームにおける運用チームであるSREと、アプリケーション開発チームにおける共有基盤の管理と運用の実際を解説するセッションを紹介する。これは「マイクロサービスとK8sにおける責任境界設計とリソース管理」と題されたセッションで、プレゼンテーションを行ったのはpospome氏だ。

●動画：マイクロサービスとk8sにおける責任境界設計とリソース管理

タイトルは大仰だが、その内はマイクロサービスで構成されたDMMのシステムをSREが担当する部分とアプリケーション開発チームが担当する部分に分け、役割分担の背景と実際に実装したツールの解説というものだ。

DMM社内システムの責任分担とその背景、実際のオペレーションを解説

pospome氏のタイトルはアーキテクトだが、プラットフォームチームに所属していると自己紹介を行っているところから、SREチームの視点からの発表と言える。

まずはDMMのプラットフォームの利用者となるグループに関して解説を行った。エンジニア数は120名以上、開発チームが16、共通のインフラストラクチャーを担当するSREチームが存在し、約40のマイクロサービスで構成されたサービスを提供しているという。

DMMのシステム概要

その開発チームと運用チームが使うプラットフォームは、AWSとGCPを併用しているとしてマネージドのKubernetesとCDについてはArgoCD、コンテナレジストリーはGCPのArtifact Registry、監視にはDatadogなどが利用されていると紹介された。後半で解説されるが、ソースコートの管理はGitHub、ワークフローとしてGitHub Actionsを使っているという。

GKEとEKSを併用するインフラストラクチャー構成

インフラストラクチャーについては以下のスライドで解説されている。どうしてAWSとGCPの併用なのか？ については特に説明がなかった。

DMMのインフラストラクチャー構成図

ここからシステムに関して誰が責任を持つのか？ という責任境界に関する解説が始まった。アプリケーションを実行するインフラストラクチャーについて、Kubernetesを利用していることは説明済みだが、アプリケーションを開発するエンジニアとインフラストラクチャーを管理するエンジニアの中間に位置する立場、例えば、Podの構成を定義するマニフェストファイルは誰が書くのか？ についてはさまざまなケースが有り得る。DMMにおいてはノードのキャパシティプランニングはSREが、ポッドのキャパシティプランニングは開発チームがそれぞれ責任を負うとして、マニフェストファイルについても内容を決定するのは開発チームであることが説明された。

マニフェストの内容を決める開発チームメンバーは、アプリケーションに関する知識に加えてインフラストラクチャーであるKubernetesの知識も要求される。DMMにおいてはこれが最適解ということだろう。

DMMのアプリケーション開発チームの責任範囲

ここではマニフェストの設定は開発チームの責任と説明されているが、実際にはマイクロサービスが実行される際のパラメータの入力は開発チームが行い、テンプレートを用意するのはSREというのがDMMの現在の方針である。

Kubernetesのnamespaceの中はすべて開発チームの責任

この方針については一元管理と個別管理という二つに分類して、そのメリットとデメリットを説明している。

インフラストラクチャーとアプリケーションの中間に位置する部分をどう管理するのか

一元管理の場合は効率が良く、エコシステムの導入も容易だが、しかしリソース単位で細かな設定や個別に対応が必要な場合の対応が難しいと説明。特に問題として挙げられていたのは、アプリケーション開発チームが管理をSREに任せた場合のコミュニケーションコストであることが強調されている。これについては学習コストとコミュニケーションコストとのバランスであると説明し、実際には「コミュニケーションコストは永遠にゼロにはならない」と語った。

後半は具体的にインフラストラクチャーの実装に利用しているツールの解説に移った。DMMのプラットフォーム管理に用いられている2つのツール、Super TerraformとOsirisのそれぞれについて説明。Super TerraformはKubernetesのマニフェスト以外を管理するIaCツール、OsirisはKubernetesのマニフェストファイルだけを管理するツールであると説明した。

Super Terraformの利用例を解説

セルフサービスを指向しているようで、申請者がSlackから行えるようになっていることを説明した。

新たにマイクロサービスを作る場合はGitHub Actionsからワークフローを起動

ワークフローから必要なリソースが作成される

マイクロサービスの新規作成は誰でもできるようになっているが、実行はGitHub Actionsのワークフローで行われる。また新規にマイクロサービスを作成する場合は、デザインドキュメントのレビューが必要なので、その部分で承認サイクルが回っていると説明。また組織は常に変化するため、マイクロサービスのリソース管理の中にリアルな組織構造を取り入れない工夫などが行われていると解説した。ただし、Kubernetesのマニフェストを変更しただけでは実際のクラスターへの変更は行われない、ワークフローを起動する必要があるなど宣言的な部分と手続き的な部分が絡み合っているように見える。またCIに関してもまだ改善する点が多いなど、反省点についても紹介された。

開発チームがアプリケーション開発から運用まで責任を持つという部分は、CNDT 2020で講演を行ったメルカリのシステムとかなり近い発想だろう。パブリッククラウドの利用という意味では、DMM.comとメルカリのセッション内容には近い点がある。一方、SLOやテストの難しさなどについても言及しているメルカリのセッションに比べて、DMM.comのセッションでは責任分担とデプロイ作業の具体的な方法についてのみ解説が行われていたのがやや残念と言える。

●参考：CNDT2020シリーズ：メルペイのマイクロサービスの現状をSREが解説

ワークフローとマニフェストの役割をどう分けるのか、宣言的な部分と手続き的な部分をどういう考えで分けているのか。これらの点に関するより深い考察があれば、他の組織においても参考になるポイントは多数あるだろうと思われる。またセキュリティの考え方などについても、次の機会があれば解説して欲しいと思わせるセッションだった。