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

俺たちの本当にやりたかったDevDay 2023 の登壇資料です。
https://connpass.com/event/282059/

Transcript

1. マルチテナント型EKSを活用した プラットフォームエンジニアリングの 光と闇 @pospome
2. 登壇者 名前：pospome（ぽすぽめ） 所属：DMM.com Twitter:@pospome
3. 今回の発表について DMMプラットフォーム x EKS x プラットフォームエンジニアリング
4. プラットフォームエンジニアリングとは? https://platformengineering.org/blog/what-is-platform-engineering
5. プラットフォームエンジニアリングとは? ざっくり言うと “プラットフォームチームが開発作業に必要なツールを構築・運用 し、アプリケーションチームに提供することで組織の開発効率を向上させる” こ と。 アプリケーション チーム CDパイプライン プラットフォームチーム アプリケーション チーム 利用する 構築 & 運用する
6. 他社の例
7. DMMプラットフォーム 扱う領域：DMM会員、決済、DMMポイント、不正対策など エンジニア数：120名以上 開発チーム数：16チーム マイクロサービス数：約40サービス ピーク時のリクエスト：19,000RPS
8. EKSを利用している 思想としては “シングルクラスターマルチテナント” である。 DMMプラットフォーム内のアプリケーションチームが相乗りする。 用途 EKS 開発環境用 1クラスター 検証環境用 1クラスター 本番環境用 1クラスター
9. 運用モデルについて
10. 以前のDMMプラットフォームの運用モデル アプリケーションチームが 自分たちで全ての作業をやっていた。 強い独立性とオーナーシップによって、 各チームが自走して開発できていたが、 DMMプラットフォーム全体としての 開発効率は良くなかった。
11. 今のDMMプラットフォームの運用モデル プラットフォームチームが一部の ツールの構築・運用作業を引き受けることで、 アプリケーションエンジニアが 開発に注力できるようになった。
12. 守備範囲の具体例 以下のように守備範囲を切り分けている。 アプリケーションチームはプラットフォームチームへの依頼なしでアプリケーショ ンの開発・運用ができる。 対象 プラットフォームチーム アプリケーションチーム k8s(GKE & EKS) クラスターの運用 k8sマニフェストの管理 CDパイプライン ArgoCDの構築・運用 ArgoCDを利用したデプロイの実行
13. AWS Dev Day 2022 の発表内容
14. 光があれば闇もある 実際にやってみて意外と上手くいかない部分（闇）もあったので、 それを共有する。
15. 闇について 主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ
16. 闇について 主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ
17. コミュニケーションはゼロじゃない 提供する側と利用する側の関係になる以上、 プラットフォームチームと アプリケーションチームの コミュニケーションがゼロになることはない。
18. DMMプラットフォームの運用モデル このコミュニケーションコストが意外と高い。
19. プラットフォームチームへの月間問い合わせ数 月間の問い合わせ数は以下である。 問い合わせ対応はローテーションで回している。 • 平均で13件 • 最小4件 • 最大で25件
20. 問い合わせの内訳 問い合わせ内容の内訳 • プラットフォームチームじゃないと解決できないもの … 43% • 今はプラットフォームチームじゃないと解決できないもの … 16% 約60%の問い合わせがプラットフォームチームの対応が必要なものなので、コ ミュニケーションをゼロにするのは無理そう。
21. コミュニケーションが発生するパターン 1. アプリケーションにトラブルが発生したとき 2. プラットフォームチームが提供する仕組みの詳細を知りたいとき
22. アプリケーションにトラブルが発生したとき アプリケーションチームが遭遇するトラブルでよくあるもの。 • ポッドが立ち上がらない • 通信がエラーになる • xxxを操作する権限がない
23. アプリケーションにトラブルが発生したとき トラブルの一次対応はアプリケーションチームが担当することになるので、以下 の作業に時間を取られてしまう。 • 原因の切り分け • 問い合わせ内容の記載
24. ツール群に対する習熟度の低さ アンケートにて「開発作業で困ることがない」と回答したアプリケーションエンジ ニアは40%程度だったこともあり、 プラットフォームチームが提供するツールへの習熟度が高いと言える状態では ない。 原因の切り分けなどに苦労していると思う。
25. 問い合わせの内訳 問い合わせ内容の内訳 • アプリケーションチームが自分たちで解決できるもの … 16% アプリケーションチーム自身で自己解決できるものを問い合わせてしまうことも ある。
26. 問い合わせのコミュニケーションコストが高い 問い合わせへは24時間以内に返信しており、最優先で対応する方針になって いるが、問い合わせ内容によってはアプリケーションチームを数日待たせること もある。 開発効率が高くなっているのか・・・?
27. コミュニケーションが発生するパターン 1. アプリケーションにトラブルが発生したとき 2. プラットフォームチームが提供する仕組みの詳細を知りたいとき
28. プラットフォームチームが提供する仕組みの詳細を知りたいとき プラットフォームチームが提供する仕組みは ドキュメントに書いてあるので、 アプリケーションチームが検索しつつ 開発を進められる世界を目指している。
29. プラットフォームチームが提供する仕組みの詳細を知りたいとき ドキュメントには “Diátaxis framework” を 採用している。 統一性のあるドキュメントにすることで、 欲しい情報にたどり着きやすくしている。
30. 問い合わせの内訳 問い合わせ内容の内訳 • ドキュメントに書いてなかったもの … 3% • ドキュメントに書いてあるけど見つけてもらえなかったもの … 6% ドキュメントを整備していても限界はある。
31. 闇：コミュニケーションコストの高さ いずれにせよ現在は問い合わせの6割以上はプラットフォームチームの対応が 必須なものになっているので、コミュニケーションはゼロにできない。 アプリケーションチームの作業リードタイムが長くなってしまうのは回避できな い。
32. 闇について 主に以下の2点が闇になっている。 1. コミュニケーションコストの高さ 2. 個別最適化の難しさ
33. プラットフォームチームのタスク優先順位 プラットフォームチームは以下の順番でタスクの優先度を決める。 優先度 タスクの内容 例 高い • 開発が止まってしまう系 • 外部からの攻撃によるリスクが高い系 CDパイプラインの構築 普通 • 多くの人にメリットがある系 サービスメッシュの導入 カナリアリリースの導入 低い • 特定のチームにのみメリットがある系 いろいろ
34. 個別最適化の難しさ プラットフォームチームはあくまで “DMMプラットフォーム全体の開発効率を向 上させるのが目的” なので、 特定のチームにのみメリットがあるものは後回しにせざるを得ない。 アプリケーションチームはそれぞれの最適化が先送りにされてしまうので、開発 体験が悪く感じてしまう。
35. 闇：個別最適化の難しさ 個別最適化を依頼するためのコミュニケーションが発生したり、 話が平行線になったりすることもあるので、 まあまあ時間が取られる。 開発体験が悪いことでコミュニケーションコストが増えてしまう。
36. 今後闇はなくなるのか? 以下によって闇の削減を期待することはできる。 • 自動化の徹底 • アプリケーションチームの習熟度の向上 • 個別最適化へのシフト しかし、技術の進化や組織の変化によって闇がなくなることはないはずである。
37. プラットフォームエンジニアリングに価値はあるのか? アンケート結果としては約8割のエンジニアが「開発効率が向上した」と回答し ている。 残りの2割は「まだ判断できない」と回答している。
38. プラットフォームエンジニアリングに価値はあるのか? 常に利用者がいて、メンテされている仕組みを提供することができる。
39. プラットフォームエンジニアリングに価値はあるのか? 120人のエンジニアが所属するDMMプラットフォームの場合は、 プラットフォームチームを設立し、全体最適化に投資する価値があるように思え る。 しかし、他の開発組織で上手くいくかは分からない。
40. おわり