マルチテナント型EKSを活用したプラットフォームエンジニアリングの光と闇

by pospome

Slide 1

Slide 1 text

マルチテナント型EKSを活用したプラットフォームエンジニアリングの光と闇 @pospome

Slide 2

Slide 2 text

登壇者名前：pospome（ぽすぽめ）所属：DMM.com Twitter:@pospome

Slide 3

Slide 3 text

今回の発表について DMMプラットフォーム x EKS x プラットフォームエンジニアリング

Slide 4

Slide 4 text

プラットフォームエンジニアリングとは? https://platformengineering.org/blog/what-is-platform-engineering

Slide 5

Slide 5 text

プラットフォームエンジニアリングとは? ざっくり言うと “プラットフォームチームが開発作業に必要なツールを構築・運用し、アプリケーションチームに提供することで組織の開発効率を向上させる” こと。アプリケーションチーム CDパイプラインプラットフォームチームアプリケーションチーム利用する構築 & 運用する

Slide 6

Slide 6 text

他社の例

Slide 7

Slide 7 text

DMMプラットフォーム扱う領域：DMM会員、決済、DMMポイント、不正対策などエンジニア数：120名以上開発チーム数：16チームマイクロサービス数：約40サービスピーク時のリクエスト：19,000RPS

Slide 8

Slide 8 text

EKSを利用している思想としては “シングルクラスターマルチテナント” である。 DMMプラットフォーム内のアプリケーションチームが相乗りする。用途 EKS 開発環境用 1クラスター検証環境用 1クラスター本番環境用 1クラスター

Slide 9

Slide 9 text

運用モデルについて

Slide 10

Slide 10 text

以前のDMMプラットフォームの運用モデルアプリケーションチームが自分たちで全ての作業をやっていた。強い独立性とオーナーシップによって、各チームが自走して開発できていたが、 DMMプラットフォーム全体としての開発効率は良くなかった。

Slide 11

Slide 11 text

今のDMMプラットフォームの運用モデルプラットフォームチームが一部のツールの構築・運用作業を引き受けることで、アプリケーションエンジニアが開発に注力できるようになった。

Slide 12

Slide 12 text

守備範囲の具体例以下のように守備範囲を切り分けている。アプリケーションチームはプラットフォームチームへの依頼なしでアプリケーションの開発・運用ができる。対象プラットフォームチームアプリケーションチーム k8s(GKE & EKS) クラスターの運用 k8sマニフェストの管理 CDパイプライン ArgoCDの構築・運用 ArgoCDを利用したデプロイの実行

Slide 13

Slide 13 text

AWS Dev Day 2022 の発表内容

Slide 14

Slide 14 text

光があれば闇もある実際にやってみて意外と上手くいかない部分（闇）もあったので、それを共有する。

Slide 15

Slide 15 text

闇について主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ

Slide 16

Slide 16 text

闇について主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ

Slide 17

Slide 17 text

コミュニケーションはゼロじゃない提供する側と利用する側の関係になる以上、プラットフォームチームとアプリケーションチームのコミュニケーションがゼロになることはない。

Slide 18

Slide 18 text

DMMプラットフォームの運用モデルこのコミュニケーションコストが意外と高い。

Slide 19

Slide 19 text

プラットフォームチームへの月間問い合わせ数月間の問い合わせ数は以下である。問い合わせ対応はローテーションで回している。 ● 平均で13件 ● 最小4件 ● 最大で25件

Slide 20

Slide 20 text

問い合わせの内訳問い合わせ内容の内訳 ● プラットフォームチームじゃないと解決できないもの … 43% ● 今はプラットフォームチームじゃないと解決できないもの … 16% 約60%の問い合わせがプラットフォームチームの対応が必要なものなので、コミュニケーションをゼロにするのは無理そう。

Slide 21

Slide 21 text

コミュニケーションが発生するパターン 1. アプリケーションにトラブルが発生したとき 2. プラットフォームチームが提供する仕組みの詳細を知りたいとき

Slide 22

Slide 22 text

アプリケーションにトラブルが発生したときアプリケーションチームが遭遇するトラブルでよくあるもの。 ● ポッドが立ち上がらない ● 通信がエラーになる ● xxxを操作する権限がない

Slide 23

Slide 23 text

アプリケーションにトラブルが発生したときトラブルの一次対応はアプリケーションチームが担当することになるので、以下の作業に時間を取られてしまう。 ● 原因の切り分け ● 問い合わせ内容の記載

Slide 24

Slide 24 text

ツール群に対する習熟度の低さアンケートにて「開発作業で困ることがない」と回答したアプリケーションエンジニアは40%程度だったこともあり、プラットフォームチームが提供するツールへの習熟度が高いと言える状態ではない。原因の切り分けなどに苦労していると思う。

Slide 25

Slide 25 text

問い合わせの内訳問い合わせ内容の内訳 ● アプリケーションチームが自分たちで解決できるもの … 16% アプリケーションチーム自身で自己解決できるものを問い合わせてしまうこともある。

Slide 26

Slide 26 text

問い合わせのコミュニケーションコストが高い問い合わせへは24時間以内に返信しており、最優先で対応する方針になっているが、問い合わせ内容によってはアプリケーションチームを数日待たせることもある。開発効率が高くなっているのか・・・?

Slide 27

Slide 27 text

Slide 28

Slide 28 text

プラットフォームチームが提供する仕組みの詳細を知りたいときプラットフォームチームが提供する仕組みはドキュメントに書いてあるので、アプリケーションチームが検索しつつ開発を進められる世界を目指している。

Slide 29

Slide 29 text

プラットフォームチームが提供する仕組みの詳細を知りたいときドキュメントには “Diátaxis framework” を採用している。統一性のあるドキュメントにすることで、欲しい情報にたどり着きやすくしている。

Slide 30

Slide 30 text

問い合わせの内訳問い合わせ内容の内訳 ● ドキュメントに書いてなかったもの … 3% ● ドキュメントに書いてあるけど見つけてもらえなかったもの … 6% ドキュメントを整備していても限界はある。

Slide 31

Slide 31 text

闇：コミュニケーションコストの高さいずれにせよ現在は問い合わせの6割以上はプラットフォームチームの対応が必須なものになっているので、コミュニケーションはゼロにできない。アプリケーションチームの作業リードタイムが長くなってしまうのは回避できない。

Slide 32

Slide 32 text

闇について主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ

Slide 33

Slide 33 text

プラットフォームチームのタスク優先順位プラットフォームチームは以下の順番でタスクの優先度を決める。優先度タスクの内容例高い ● 開発が止まってしまう系 ● 外部からの攻撃によるリスクが高い系 CDパイプラインの構築普通 ● 多くの人にメリットがある系サービスメッシュの導入カナリアリリースの導入低い ● 特定のチームにのみメリットがある系いろいろ

Slide 34

Slide 34 text

個別最適化の難しさプラットフォームチームはあくまで “DMMプラットフォーム全体の開発効率を向上させるのが目的” なので、特定のチームにのみメリットがあるものは後回しにせざるを得ない。アプリケーションチームはそれぞれの最適化が先送りにされてしまうので、開発体験が悪く感じてしまう。

Slide 35

Slide 35 text

闇：個別最適化の難しさ個別最適化を依頼するためのコミュニケーションが発生したり、話が平行線になったりすることもあるので、まあまあ時間が取られる。開発体験が悪いことでコミュニケーションコストが増えてしまう。

Slide 36

Slide 36 text

今後闇はなくなるのか? 以下によって闇の削減を期待することはできる。 ● 自動化の徹底 ● アプリケーションチームの習熟度の向上 ● 個別最適化へのシフトしかし、技術の進化や組織の変化によって闇がなくなることはないはずである。

Slide 37

Slide 37 text

プラットフォームエンジニアリングに価値はあるのか? アンケート結果としては約8割のエンジニアが「開発効率が向上した」と回答している。残りの2割は「まだ判断できない」と回答している。

Slide 38

Slide 38 text

プラットフォームエンジニアリングに価値はあるのか? 常に利用者がいて、メンテされている仕組みを提供することができる。

Slide 39

Slide 39 text

プラットフォームエンジニアリングに価値はあるのか? 120人のエンジニアが所属するDMMプラットフォームの場合は、プラットフォームチームを設立し、全体最適化に投資する価値があるように思える。しかし、他の開発組織で上手くいくかは分からない。

Slide 40

Slide 40 text

おわり