DMMプラットフォームのマイクロサービス戦略 オーナーシップの落とし穴

AWS Dev Day 2022 Japan の発表資料です。

Transcript

1. DMMプラットフォームの マイクロサービス戦略 オーナーシップの落とし穴
2. 登壇者 名前：pospome（ぽすぽめ） 所属：DMMプラットフォーム Twitter:@pospome
3. 今回の発表内容について DMMプラットフォーム x マイクロサービスアーキテクチャ x オーナーシップ x アマゾン ウェブ サービス(AWS)
4. DMMプラットフォームについて 扱う領域：DMM会員、決済、DMMポイント、不正対策など エンジニア数：120名以上 開発チーム数：16チーム マイクロサービス数：約40サービス ピーク時のリクエスト：14,000RPS
5. DMMプラットフォームのマイクロサービス歴 DMMプラットフォームは約6,7年前から マイクロサービスアーキテクチャを採用している。 ＊当時選択したテクノロジースタックはオンプレ&Java&MySQLだった。
6. マイクロサービスにおける開発体制で重要なこと マイクロサービスにおける開発体制では 独立性の高い小さいチームを作れるかが重要になる。
7. 独立性の高い小さいチームとは? 以下の2つの方針を利用して説明することができる。 1. Two-Pizza Team Rule 2. You build it, you run it.
8. Two-Pizza Team Rule とは? • チームのサイズを小さくすること。 コミュニケーションパスを減らす。 • オーナーシップと責任を与えること。 チームが責任を持ち、 自分たちの判断で 物事をすすめることができる。 https://aws.amazon.com/jp/blogs/news/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high-performing-agile-orga nizations-part-1-jp/
9. You build it, you run it. とは? 開発チームが開発から運用まで一貫して担当することで、 利用者からのフィードバックを得て、 サービスの品質を向上させることである。 “開発から運用まで”という部分によって、 DevOpsの文脈で紹介されることもある。 https://aws.amazon.com/jp/blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/
10. 独立性の高い小さいチームとは? 独立性の高い小さいチームの要件は以下である。 1. 小さいチームを作ってコミュニケーションパスを減らす。 2. オーナーシップを持たせる。 3. 開発チームは開発から運用まで担当する。
11. 独立性の高い小さいチームのメリットとは? 組織内のコミュニケーションコスト、調整コストを削減し、 目的を達成するために必要な権限を持つチームが 単独で物事を進められるようになる。 “コミュニケーションパスが多い”, “承認が必要” という 大きい組織ならではの問題を回避するための戦略と見ることができる。
12. pospomeが入社した直後の DMMプラットフォームはどうだったのか? ＊約3年前の話
13. 小さいチームを作ってコミュニケーションパスを減らす 入社直後に確認することができず判断できないが、 DMMはスモールチームを推奨しているので満たしていたはず。 チーム内のコミュニケーションパスも限定されていると思う。
14. オーナーシップを持たせる ワンチームで完結するようなオーナーシップを持っていた。 • 開発 • プロダクト設計 • テクノロジースタックの選定 • 採用
15. 開発チームは開発から運用まで担当する ワンチームで完結するようになっていた。 • CI • リリース（CD） • IaC • オンコール対応 • 利用者の問い合わせ対応
16. pospomeが入社した直後の DMMプラットフォームは悪くなさそう
17. しかし、開発効率は高くなかった
18. 当時のDMMプラットフォームの状態 DMMプラットフォーム内で利用されていたプログラミング言語 1. PHP 2. Java 3. JavaScript 4. TypeScript 5. Go 6. Kotlin 7. Elixer 8. Python 9. Scala 10. Ruby
19. 当時のDMMプラットフォームの状態 DMMプラットフォーム内で利用されていたアプリケーション実行環境 • オンプレ • Amazon Elastic Compute Cloud(EC2) • Amazon Elastic Container Service(ECS) • AWS Lambda(Lambda) • その他パブリッククラウドのアプリケーション実行環境
20. テクノロジースタックがバラバラすぎる 1. チーム同士の技術的な知見共有が難しかった。 2. エコシステムの構築が難しい。 3. 組織内での人員調整や組織変更で一時的に開発効率が下がる。 大きな組織だからこそ取れる戦略を取ることができない。
21. 強いオーナーシップは テクノロジースタック以外にも影響を与えた
22. ログがチームに閉じている 他チームのアプリケーションのアクセスログを確認するために そのアプリケーションのAWSアカウントのログ閲覧権限が必要になる。 マイクロサービス環境だと困ってしまう。 API GatewayチームのAWSアカウント API Gatewayのログ 決済チームのAWSアカウント 決済アプリケーションのログ
23. ログ以外もバラバラ・・・ 以下のような問題もあった。 マイクロサービスでは必須となるルールが統一されていなかった。 • 認証方法が統一されていない。 • マイクロサービス同士の依存関係が分からない。 • HTTPリクエストに紐づくトレースがつながらない。
24. 究極にサイロ化しており、 スタートアップの集合体のようだった
25. なぜサイロ化したのか pospomeが入社する前の話なので詳細は分からない。
26. この問題をどうやって解決するのか? 各チームの個別最適化から全体最適化に移行する必要がある。 • テクノロジースタックの統一 • 開発ルールの標準化
27. 個別最適化のイメージ DMM会員チーム 独自のテクノロジースタック 独自の開発ルール プロダクト設計 採用 決済チーム 独自のテクノロジースタック 独自の開発ルール プロダクト設計 採用
28. 全体最適化のイメージ DMM会員チーム プロダクト設計 採用 決済チーム プロダクト設計 採用 共通のテクノロジースタック 共通の開発ルール
29. 全体最適化の程度 全体最適化の程度 小さい 大きい 各チームの要件 満たせる 満たせない
30. 全体最適化のイメージ DMM会員チーム プロダクト設計 採用 決済チーム プロダクト設計 採用 共通のテクノロジースタック 共通の開発ルール 独自のテクノロジースタック 独自の開発ルール 独自のテクノロジースタック 独自の開発ルール
31. 全体最適化 = オーナーシップの程度設計 全体最適化というのは、 開発チームに与えるオーナーシップの程度（権限の強さ）を 適切なものに再設計するということである。
32. オーナーシップの設計 = ガードレール オーナーシップを重要視しているAmazonも さすがに無法地帯というわけではない。 https://aws.amazon.com/jp/blogs/news/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high-performing-agile- organizations-part-2-jp/
33. Amazonの例 社内に共通のビルドシステムや デプロイシステムが存在し、 それを活用することで 機械的にベストプラクティスを 浸透させている。 組織としての戦略やサポートが存在する。 https://aws.amazon.com/jp/builders-library/going-faster-with-continuous-delivery/
34. DMMプラットフォームにとっての最適を定義する 他社の事例をそのまま適用することはできない。 • エンジニアの人数が違う • エンジニアのスキルレベルが違う • ビジネス領域が違う • 抱えている課題が違う
35. 全体最適化をどう進めたのか?
36. 専門チームの必要性とトップダウン DMMプラットフォーム規模の全体最適化は専門チームが フルコミットしないと難しい。 120人のエンジニアの承認を得て進めるのも難しいので、 改善活動自体もある程度トップダウンで進める必要がある。
37. 全体最適化への投資 全体最適化によって各チームが今まで利用していたテクノロジースタックの一 部が利用できなくなるので、短期的な開発効率は下がってしまう。 全体最適化は未来に向けた投資なので、 DMMプラットフォームとしての意思決定と投資が必要になる。 最終的にCTOに相談して全体最適化を進める承認を得た。
38. マイクロサービスアーキテクトグループの設立 全体最適化を担当するための組織である。 • 認証認可チーム 認証認可領域を担当する。 • SREチーム インフラ領域を担当する。 • Developer Productivity Team 認証認可、インフラ領域以外を担当する。
39. 運用モデルについて サービス開発・運用における 役割を図にしたものである。 役割が分かれているほど コミュニケーションコストが 高くなり、開発効率が悪くなる。 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/fully-separated-operating-model.ht ml
40. 今までのDMMプラットフォームの運用モデル アプリケーションエンジニアが 自分たちでインフラを運用する。
41. 今後目指すDMMプラットフォームの運用モデル 今後目指すべき姿に近い。 SREチームが各チームに向けて 必要な仕組みを提供する。 120人のエンジニアが利用する 共通インフラを開発する必要がある。
42. SREチームの活動について
43. SREチームの最初の一歩 ログ/メトリクスの共通ルールを定義し、各チームに徹底してもらう。 DMMプラットフォームではDatadogにそれらを集約している。 HTTPリクエストに紐づくログの検索や トレース情報の確認が可能になった。 マイクロサービス間の依存関係も可視化できるようになった。
44. システムアーキテクチャ図 Datadog
45. アプリケーション実行環境の統一 • クラウド上に共通利用するアプリケーション実行環境を構築する。 120人が共通利用するものを構築する必要がある。 • アプリケーション実行環境にはk8sを採用した。 マルチテナント型になっており、 1アプリケーション1namespaceという構成で 論理的なリソース境界を定義している。
46. SREチームのAWSアカウント Amazon Elastic Kubernetes Service (EKS) システムアーキテクチャ図 Datadog マイクロサービス 青色はSREチームが管理するもの。 灰色は開発チームが管理するもの。
47. DMMプラットフォームはマルチクラウド 今まで開発チームに強いオーナーシップをもたせた結果、 開発チームが利用しているクラウドもバラバラだった。 どちらかに寄せ切るのが難しかった。
48. SREチームのAWSアカウント Amazon Elastic Kubernetes Service (EKS) システムアーキテクチャ図 Datadog マイクロサービス 他のパブリッククラウド k8s マイクロサービス
49. CDツールの統一 CDツールとしてはArgoCDを採用した。
50. SREチームのAWSアカウント Amazon Elastic Kubernetes Service (EKS) システムアーキテクチャ図 Datadog マイクロサービス 他のパブリッククラウド k8s マイクロサービス ArgoCD
51. コンテナレジストリの統一 CDに伴ってコンテナレジストリも共通のものを提供している。
52. SREチームのAWSアカウント Amazon Elastic Kubernetes Service (EKS) システムアーキテクチャ図 Datadog マイクロサービス 他のパブリッククラウド k8s マイクロサービス ArgoCD Container Registry
53. SREチームが管理するもの 各チームが開発に必須となるものから優先的に用意している。 • Datadog • k8s • CD • コンテナレジストリ
54. SREチームが管理しないもの 各チームにオーナーシップを持たせるものは管理しない。 • CI • DB（RDS, DynamoDB, etc） • インメモリキャッシュ（Elasticache） • オブジェクトストレージ（S3） • などなど・・
55. SREチームが管理しないもの 各チームが管理するAWSリソースは各チームのAWSアカウントで 管理してもらっている。 各チームのAWSアカウントとk8sが存在するAWSアカウントは AWS Transit Gatewayで接続されている。
56. SREチームのAWSアカウント Amazon Elastic Kubernetes Service (EKS) Transit Gateway を利用したVPC接続 Datadog マイクロサービス 他のパブリッククラウド k8s マイクロサービス Transit Gateway ArgoCD 開発チームの AWSアカウント RDS CI Container Registry
57. 共通インフラにおける各チームの独立性 インフラ領域のテクノロジースタックを統一しているが、 各チームが必要性以上に独立性を失ってしまうと意味がない。
58. 各チームの独立性を保つ仕組み
59. 共通インフラの利用申請 & 権限変更 共通インフラの利用者は 単一のGitHubリポジトリで Terraformによって管理している。 利用者による申請&開発チームによる承認が 可能となっている。
60. アプリケーションのデプロイ（ArgoCD） ImageOpsによって開発チーム自身がアプリケーションを 任意のタイミングでデプロイできる。 他チームのアプリケーションをデプロイすることはできない。
61. アプリケーションのk8sマニフェスト変更 単一のGitHubリポジトリで各アプリケーションの マニフェストファイルを管理している。 開発者自身が任意のタイミングで変更することができるが、 GitHubのCODE OWNERSによってファイルの権限を管理しているので、 他チームのマニフェストファイルを変更することはできない。
62. 利用者ドキュメント 各チームが自分たちで調べてインフラを 利用できるようにする。 学習コストも削減できる。
63. 仕組みを提供し、自由に使ってもらう 開発チームが自分たちで安全に操作できる仕組みを提供することで、 開発チームの独立性を損なわないようにしている。
64. インフラにおける全体最適化の悩みどころ
65. オーナーシップ vs 権限管理 共通インフラで各チームに合わせた細かい権限設定をするために 仕組みを作り込むのは大変。 現在の権限管理は性善説ベースの部分が多いが 「誰がいつ何をしたのか」は追えるようになっており、 致命的な問題を防ぐための最低限の対策は用意している。
66. 技術の詳細をどこまで隠蔽するか? 例：k8sのマニフェストファイルをどこまで抽象化するか? SREチームが技術の詳細を隠蔽する仕組みを提供すると、 開発チームの細かい要件を満たすことができなかったり、 SREチームとのコミュニケーションが発生してしまう可能性がある。
67. 技術の詳細をどこまで隠蔽するか? DMMプラットフォームでは技術の詳細をほぼ隠蔽せず、 素の状態で使ってもらっている。 自分たちが使う技術は自分たちで理解してないと 開発・運用をワンチームで完結させることは難しいと思っている。 それにかかる学習コストも投資として割り切る。
68. 技術の詳細をどこまで隠蔽するか? DMMプラットフォームは元々強いオーナーシップを持っていたので、 この方針に倒せる環境だった。
69. 共通インフラが開発チームの要求を満たせるか? 共通インフラを構築する前に開発チームに要求をヒアリングし、 可能な限り要求を満たす仕組みを目指す。 開発の優先度とスケジュールも確認する。 開発チームの要求に妥当性があるかどうかはケースバイケースなので、 単に要求を満たすだけでなく、ディスカッションすることになる。
70. 開発チームがSREチームへ依存するようになる 開発チームがオーナーシップを持って解決すべき問題を SREチームに頼ってしまうケースがチラホラある。 最初は新しいテクノロジーに対する習熟度が低く、 責任境界を判断できないこともあり、こういった形になってしまう。 SREチームは開発者が自立して作業できるように サポートする必要がある。
71. 現在のDMMプラットフォーム
72. 現在の全体最適化の状況 DMM会員チーム プロダクト設計 採用 決済チーム プロダクト設計 採用 プログラミング言語, アプリケーション実行環境 , CD, Log/Metrics CI, DB選定, クラウド選定, QA CI, DB選定, クラウド選定, QA
73. 解決できた課題 当時のDMMでは難しかったことを少し実現できるようになってきた。 1. 各チームの知見共有 2. エコシステムの開発 3. 特定のプロジェクトに人を寄せる
74. デファクトスタンダードを選択しない自由 各チームの判断によって ”デファクトスタンダードを選択しない”ことも許容している。 しかし、DMMプラットフォームの技術戦略（エコシステム）の恩恵を 受けれないので、メリデメを判断してもらうことになる。
75. 全体最適化に対するアンケート結果 全体最適化を進めて2年ほど経ったタイミングでアンケートを取った。 結果は良好だが、まだ投資フェーズであることがわかる。 「共通インフラは開発効率の向上に貢献していますか?」 • 貢献していると思う … 80% • まだ判断できないが将来的には貢献すると思う … 15% • 自分たちで構築するのと変わらない … 5%
76. まとめ ある程度大きな開発組織の場合は オーナーシップの程度を設計することが重要である。 単にオーナーシップを与えるのではなく、 開発チームをサポートする組織的な技術戦略の考慮も必要である。 そういったものを考慮した上で個別最適化に倒すのも戦略としては 問題ないと思っている。
77. ご清聴ありがとうございました