目標は「SREが関与しなくても開発者が作業できる世界をつくること」 DMMの挑戦：「Cloud Operator Days Tokyo 2022」セミナーレポート＃6
Cloud Operator Days Tokyo 2022のセッション「DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善」にてDMMのpospome氏は、別の目的で構築されたKubernetes環境の運用を引き継ぐときに起きた課題とその解決方法について紹介した。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
「あるサービス用に開発した仕組みを全社共通の仕組みに変える」といったアプローチは決して珍しくない。一から仕組みを構築するよりは、先行事例としてうまくいっているものを流用したり機能拡張させたりする方が失敗は少ないからだ。
ただ、特定の目的に合わせて作った仕組みに汎用（はんよう）性を持たせることは簡単ではない。関係者なら誰でも使えるように環境を整備する必要があるし、運用の方法も全社での利用に合わせて変更しなければならない。
Cloud Operator Days Tokyo 2022のセッション「DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善」でDMMのpospome（ぽすぽめ）氏（マイクロサービスアーキテクトグループ SRE＜Site Reliability Engineering＞チーム）は、そうした「別の目的で構築された仕組み」の運用を引き継ぐときに起きた課題とその解決方法について紹介した。
DMMサービスの共通プラットフォームをKubernetesで構築
DMMのpospome（ぽすぽめ）氏のアイコン
pospome氏が所属する部署「DMMプラットフォーム」は、DMMの各種サービスで利用する共通機能（会員登録、決済、不正対策、認証認可など）を提供している。在籍するエンジニアは約120人、開発チームは16チーム、マイクロサービスは約40サービス、ピーク時のリクエスト数は秒間1万4000リクエストに上るという。
同氏は「マイクロサービスアーキテクトグループ SREチーム」の一員として、DMMプラットフォームのインフラに関するエコシステムを構築し、組織全体の開発効率とセキュリティレベルを向上させるというミッションを持つ。
DMMプラットフォームではインフラとして「Google Kubernetes Engineクラスタ」（以下、GKEクラスタ）を採用しており、オンプレミスで稼働中のマイクロサービスを移行しているさなかだ。
当初、APIゲートウェイ専用のクラスタとして構築されたGKEクラスタをDMM共通のクラスタとして利用することになり、pospome氏をはじめとするSREチームが引き継ぐことになった。運用が安定するまでには幾つかの課題を解決する必要があったという。
運用に必要な仕組みが整っていないGKEクラスタ
まず課題になったのは「安定運用させる仕組みが不足していたこと」だ。もともと全社用に構築されたものではないため、引き継いだときにはアラートやモニタリングの設定、アップグレードのルールといった「全社で運用するときに必要な仕組みが整っていなかった」とpospome氏は振り返る。
pospome氏は早速、基本的な運用の仕組みから構築を始めた。運用監視サービス「Datadog」を導入し、メトリクスやSLO（Service Level Objective）を整備、GKEクラスタのアップグレードのルールも定義した。さらに、GKEをはじめとする各種設定の見直しを実施した。ここで言う各種設定とは、ローカルノードキャッシュの有効化、ステートメトリックスやRBAC（ロールベースアクセス制御）の導入、Datadogエージェントのセットアップなどだ。
「その他、SREチームで運用定例ミーティングを行い、DatadogのメトリクスやSLOを確認して問題を話し合い、もし問題があればタスク化して優先度を付けて対処するといった取り組みも進めた」
こうした取り組みの結果、ようやく運用が安定し出した。一方で、新たな気付きもあった。それは「Kubernetesの運用には専任のチームが不可欠」ということだ。
「Kubernetesが進化するスピードは速く、それに追従しつつ、片手間で周辺のエコシステムを運用することは難しい。専任チームを作り、マルチテナント化して『組織としてKubernetesをどう使うか』という戦略を立てる必要があると感じた。専任チームがいない状態でKubernetesを採用しても、コンテナ管理実行環境の『Google Cloud Run』や『Amazon ECS』の下位互換にしかならないだろう」
専任チームは必要だが人が足りない、どうする？
次の課題は「マンパワー不足」だ。当時、SREチームのメンバーはpospome氏を含め2人しかいなかったのだ。
もちろん採用活動はしていたが、条件に合うエンジニアがそう簡単に採用できるわけもなく、当面は2人で頑張るしかないとpospome氏は覚悟を決めていたという。ただ、同氏も根性論で乗り切るつもりはなく、ある秘策を練っていた。
「仮に今すぐエンジニアが採用できたとしても、現状のままではサービスがスケールするごとにエンジニアを追加で採用しなければならず、非効率だ。そうであればこの機会に、GKEの利用者や稼働するアプリケーションが増えても自動でスケールし、エンジニアを増やさなくても運用できる仕組みを構築した方が建設的と考えた」
SREチームが関与しなくても開発者が作業できる世界をつくる
“スケールする仕組みづくり”としてpospome氏が手を付けたのは「Kubernetesのマニフェストをモノレポ（Monorepo：1つのリポジトリで全てのコードを管理する手法）で管理する」「マニフェストファイルの新規作成を自動化する」「利用者（開発者）向けのCD（継続的デリバリー）パイプラインを整備する」「RBACで権限を管理する」だ。
マニフェストをモノレポで管理することで、開発するサービスごとにリポジトリを作成する必要がなくなる。新たなアプリケーションを開発する場合も、権限を設定したディレクトリを用意するだけで済む。「マニフェストを更新できるのは、アプリケーションを管理する開発者だけに制限する。ディレクトリに権限を設定すればそれが可能だ。こうすることで、SREチームに確認を取らなくても開発者が作業できるようになる」とpospome氏は解説している。
マニフェストファイルの新規作成も自動化した。開発者は「GitHub Actions」で作ったテンプレートにコンテナイメージのURLやポート番号などを入力するだけで、SREチームの承認なしでマニフェストファイルを作成できる。
「自動で作成できるといっても、最低限の保護（pospome氏は“ガードレール”と例えた）は必要だ。そこで『リクエストのリミット指定があるか』『非推奨のAPIのバージョンを使っていないか』など“生成されたマニフェストファイルが適切かどうか”をCI（継続的インテグレーション）でチェックする仕組みを作った」
さらに、開発者向けにCDパイプラインの仕組みも整えた。CDパイプラインとして「Spinnaker」を採用し、SREチームの承認なしで開発者がパイプラインを作成したりデプロイしたりできるようにした。また、RBACによる権限管理については、開発者自身で管理する仕組みにした。
pospome氏は「“スケールする仕組み”を実現するためには、開発者にオーナーシップを持たせることが重要だ。開発者だけで作業が完結すれば『SREチームが関与しなくてもいい世界』が実現する」と指摘している。
「もう1つのポイントは、アプリケーション単位でリソースを管理することだ。今日の企業では2〜3カ月といった短い期間で組織体制が変わることは珍しくない。組織に関連した仕組みにしてしまうと組織変更のたびにSREチームが作業しなければならなくなる。組織ではなくアプリケーションに関連させることでその影響を防ぐことができる」
「事故りながら前に進む」で知見を蓄積
安定した運用を実現し、スケールする仕組みも構築した。次に課題になったのは「Kubernetesの知見をどのように蓄積するか」だ。これについてpospome氏は「事故りながら知見を得た」と語る。言い換えれば「軽微な失敗を繰り返し、対処法を学ぶ」ということだろう。
「“あるノードのロードアベレージが極端に高い”という事象が発生したら、『特定のPod（クラスタで実行されているプロセス）を削除する必要がある。だからそのためのサービスを導入しよう』といった具合に、発生した課題とその対処法を知見として蓄積した。ただ、失敗を前提としてはいてもDMMプラットフォーム全体に影響が出ては困るので、Datadog監視による異変の検知、メトリクスの確認、本番環境で問題が起こっていないかどうかをチェックするサンプルアプリケーションを開発するなど、影響範囲を抑える工夫をした」
pospome氏を含むSREチームにとって幸運だったのは、こうした“知見の蓄積”に時間をかけられたことだ。「引き継いだときは、オンプレミスからGKEクラスタにアプリケーションを移行しはじめたばかりで、ゆっくりとアプリケーションが増えているといった状況だった。そのため、余裕を持って取り組みを進めることができた」とpospome氏は振り返る。
理想は「開発チームが自立してエコシステムを理解すること」
ここまでpospome氏は「SREチームがいなくても開発者が作業を進められる環境」を整えてきた。ただ、いくら仕組みを構築しても開発者自身がKubernetesやCDパイプラインについて理解していなければ、結局「SREチームがいないと作業できない」といった事態が起こり得る。
「理想としては開発者自身がエコシステムについて学習し、理解度を高めることだ。しかし、独学で学ぶにはエコシステムの学習コストは高く、サポートが必要だ。とはいえSREチームが全面的にサポートしてしまうとスケールしない仕組みになってしまう」
そこでpospome氏は「学習コストを下げる仕組み」の構築に取り掛かった。まず作成したのは、Kubernetes回りのシステムアーキテクチャやCDパイプラインの使い方などをまとめた「利用者（開発者）向けドキュメント」だ。
「このドキュメントは開発者が困らないように“ありとらゆる情報が載っているもの”という扱いだ。SREチームが新しい仕組みを作った場合は必ずセットでドキュメントを作成するようにしている。作って終わりではなく、開発者から質問が来たときにはその質問内容を補完するような記述があるかチェックし、なければ追記するという運用にした」
このドキュメントには、SREチームが実際に使っているサンプルアプリケーションを関連付けした。pospome氏は「Datadogやパイプラインの設定は新しいサービス開発にも役立つと考え、開発者が自分で探すことができるようにした」と説明している。
「最も力を入れているのは情報共有だ。どんなドキュメントやアプリケーションを作って見てもらえない、気付いてもらえないと意味がないからだ。共有方法としてはテックリードが集まるミーティングとSlackを活用している。テックリードミーティングではドキュメントの周知やサンプルアプリケーションの更新情報を共有し、テックリードを通じて各チームのエンジニアに情報を伝えられる。Slackにはテックリードミーティングで伝えた内容を全て列挙し、『テックリードが伝え漏れる』という事態を回避している」
pospome氏はまとめとして次のように語る。
「一から始める場合、人が少なかったり、知見がなかったりという課題はどうしてもついてまわる。とはいえ、人がそろうまで待つというのは現実的ではない。スモールスタートではじめ、ステップ・バイ・ステップでいい仕組み、いいチームを構築するのがよい進め方だと考えている」
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。