Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マルチテナント型EKSを活用したプラットフォームエンジニアリングの光と闇
Search
pospome
June 21, 2023
Technology
0
2.4k
マルチテナント型EKSを活用したプラットフォームエンジニアリングの光と闇
俺たちの本当にやりたかったDevDay 2023 の登壇資料です。
https://connpass.com/event/282059/
pospome
June 21, 2023
Tweet
Share
More Decks by pospome
See All by pospome
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
9
4.3k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
29
11k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
3.4k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
1.5k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
430
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.2k
(再アップロード)Microservices & APIs
pospome
0
73
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
70
マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム
pospome
3
1.3k
Other Decks in Technology
See All in Technology
Introduction to SwiftUI V2
pohjus
0
100
成長をサポートするピープルマネジメントのやり方
sioncojp
9
1.4k
社内アプリで Cloudflare D1を プロダクト運用してみた体験談(Tokyo)
haochenx
0
130
2024春 注目のWeb系 OSS & SaaS 3選
makies
0
200
Cracking the KubeCon CfP
inductor
2
280
ルーターでプレゼンする
puhitaku
1
3.4k
AWS学習者向けにAzureの解説スライドを作成した話
handy
3
210
高専で制御を、大学でセンシングを学び、次は脳みそ
satoshirobatofujimoto
0
120
Grafana x PagerDuty Better Together
jacopen
1
320
Gemini, Google's Large Language Model
glaforge
0
120
[2024/04/23]tbls活用事例 〜 ビューポイントから データベースを整理してみた話 〜
tosite
0
110
IaCジェネレーターとBedrockで詳細設計書を生成してみた
tsukasa_ishimaru
4
940
Featured
See All Featured
Robots, Beer and Maslow
schacon
PRO
155
7.9k
Design by the Numbers
sachag
274
18k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
A Modern Web Designer's Workflow
chriscoyier
689
190k
No one is an island. Learnings from fostering a developers community.
thoeni
16
2.1k
Agile that works and the tools we love
rasmusluckow
325
20k
Build your cross-platform service in a week with App Engine
jlugia
226
17k
Ruby is Unlike a Banana
tanoku
96
10k
Code Reviewing Like a Champion
maltzj
515
39k
Raft: Consensus for Rubyists
vanstee
133
6.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
14
8.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
356
18k
Transcript
マルチテナント型EKSを活用した プラットフォームエンジニアリングの 光と闇 @pospome
登壇者 名前:pospome(ぽすぽめ) 所属:DMM.com Twitter:@pospome
今回の発表について DMMプラットフォーム x EKS x プラットフォームエンジニアリング
プラットフォームエンジニアリングとは? https://platformengineering.org/blog/what-is-platform-engineering
プラットフォームエンジニアリングとは? ざっくり言うと “プラットフォームチームが開発作業に必要なツールを構築・運用 し、アプリケーションチームに提供することで組織の開発効率を向上させる” こ と。 アプリケーション チーム CDパイプライン プラットフォームチーム
アプリケーション チーム 利用する 構築 & 運用する
他社の例
DMMプラットフォーム 扱う領域:DMM会員、決済、DMMポイント、不正対策など エンジニア数:120名以上 開発チーム数:16チーム マイクロサービス数:約40サービス ピーク時のリクエスト:19,000RPS
EKSを利用している 思想としては “シングルクラスターマルチテナント” である。 DMMプラットフォーム内のアプリケーションチームが相乗りする。 用途 EKS 開発環境用 1クラスター 検証環境用
1クラスター 本番環境用 1クラスター
運用モデルについて
以前のDMMプラットフォームの運用モデル アプリケーションチームが 自分たちで全ての作業をやっていた。 強い独立性とオーナーシップによって、 各チームが自走して開発できていたが、 DMMプラットフォーム全体としての 開発効率は良くなかった。
今のDMMプラットフォームの運用モデル プラットフォームチームが一部の ツールの構築・運用作業を引き受けることで、 アプリケーションエンジニアが 開発に注力できるようになった。
守備範囲の具体例 以下のように守備範囲を切り分けている。 アプリケーションチームはプラットフォームチームへの依頼なしでアプリケーショ ンの開発・運用ができる。 対象 プラットフォームチーム アプリケーションチーム k8s(GKE & EKS)
クラスターの運用 k8sマニフェストの管理 CDパイプライン ArgoCDの構築・運用 ArgoCDを利用したデプロイの実行
AWS Dev Day 2022 の発表内容
光があれば闇もある 実際にやってみて意外と上手くいかない部分(闇)もあったので、 それを共有する。
闇について 主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ
闇について 主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ
コミュニケーションはゼロじゃない 提供する側と利用する側の関係になる以上、 プラットフォームチームと アプリケーションチームの コミュニケーションがゼロになることはない。
DMMプラットフォームの運用モデル このコミュニケーションコストが意外と高い。
プラットフォームチームへの月間問い合わせ数 月間の問い合わせ数は以下である。 問い合わせ対応はローテーションで回している。 • 平均で13件 • 最小4件 • 最大で25件
問い合わせの内訳 問い合わせ内容の内訳 • プラットフォームチームじゃないと解決できないもの … 43% • 今はプラットフォームチームじゃないと解決できないもの … 16%
約60%の問い合わせがプラットフォームチームの対応が必要なものなので、コ ミュニケーションをゼロにするのは無理そう。
コミュニケーションが発生するパターン 1. アプリケーションにトラブルが発生したとき 2. プラットフォームチームが提供する仕組みの詳細を知りたいとき
アプリケーションにトラブルが発生したとき アプリケーションチームが遭遇するトラブルでよくあるもの。 • ポッドが立ち上がらない • 通信がエラーになる • xxxを操作する権限がない
アプリケーションにトラブルが発生したとき トラブルの一次対応はアプリケーションチームが担当することになるので、以下 の作業に時間を取られてしまう。 • 原因の切り分け • 問い合わせ内容の記載
ツール群に対する習熟度の低さ アンケートにて「開発作業で困ることがない」と回答したアプリケーションエンジ ニアは40%程度だったこともあり、 プラットフォームチームが提供するツールへの習熟度が高いと言える状態では ない。 原因の切り分けなどに苦労していると思う。
問い合わせの内訳 問い合わせ内容の内訳 • アプリケーションチームが自分たちで解決できるもの … 16% アプリケーションチーム自身で自己解決できるものを問い合わせてしまうことも ある。
問い合わせのコミュニケーションコストが高い 問い合わせへは24時間以内に返信しており、最優先で対応する方針になって いるが、問い合わせ内容によってはアプリケーションチームを数日待たせること もある。 開発効率が高くなっているのか・・・?
コミュニケーションが発生するパターン 1. アプリケーションにトラブルが発生したとき 2. プラットフォームチームが提供する仕組みの詳細を知りたいとき
プラットフォームチームが提供する仕組みの詳細を知りたいとき プラットフォームチームが提供する仕組みは ドキュメントに書いてあるので、 アプリケーションチームが検索しつつ 開発を進められる世界を目指している。
プラットフォームチームが提供する仕組みの詳細を知りたいとき ドキュメントには “Diátaxis framework” を 採用している。 統一性のあるドキュメントにすることで、 欲しい情報にたどり着きやすくしている。
問い合わせの内訳 問い合わせ内容の内訳 • ドキュメントに書いてなかったもの … 3% • ドキュメントに書いてあるけど見つけてもらえなかったもの … 6%
ドキュメントを整備していても限界はある。
闇:コミュニケーションコストの高さ いずれにせよ現在は問い合わせの6割以上はプラットフォームチームの対応が 必須なものになっているので、コミュニケーションはゼロにできない。 アプリケーションチームの作業リードタイムが長くなってしまうのは回避できな い。
闇について 主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ
プラットフォームチームのタスク優先順位 プラットフォームチームは以下の順番でタスクの優先度を決める。 優先度 タスクの内容 例 高い • 開発が止まってしまう系 • 外部からの攻撃によるリスクが高い系
CDパイプラインの構築 普通 • 多くの人にメリットがある系 サービスメッシュの導入 カナリアリリースの導入 低い • 特定のチームにのみメリットがある系 いろいろ
個別最適化の難しさ プラットフォームチームはあくまで “DMMプラットフォーム全体の開発効率を向 上させるのが目的” なので、 特定のチームにのみメリットがあるものは後回しにせざるを得ない。 アプリケーションチームはそれぞれの最適化が先送りにされてしまうので、開発 体験が悪く感じてしまう。
闇:個別最適化の難しさ 個別最適化を依頼するためのコミュニケーションが発生したり、 話が平行線になったりすることもあるので、 まあまあ時間が取られる。 開発体験が悪いことでコミュニケーションコストが増えてしまう。
今後闇はなくなるのか? 以下によって闇の削減を期待することはできる。 • 自動化の徹底 • アプリケーションチームの習熟度の向上 • 個別最適化へのシフト しかし、技術の進化や組織の変化によって闇がなくなることはないはずである。
プラットフォームエンジニアリングに価値はあるのか? アンケート結果としては約8割のエンジニアが「開発効率が向上した」と回答し ている。 残りの2割は「まだ判断できない」と回答している。
プラットフォームエンジニアリングに価値はあるのか? 常に利用者がいて、メンテされている仕組みを提供することができる。
プラットフォームエンジニアリングに価値はあるのか? 120人のエンジニアが所属するDMMプラットフォームの場合は、 プラットフォームチームを設立し、全体最適化に投資する価値があるように思え る。 しかし、他の開発組織で上手くいくかは分からない。
おわり