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

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

Transcript

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

   View Slide

2. 登壇者
   名前：pospome（ぽすぽめ）
   所属：DMMプラットフォーム
   Twitter:@pospome
   

   View Slide

3. 今回の発表内容について
   DMMプラットフォーム
   x
   マイクロサービスアーキテクチャ
   x
   オーナーシップ
   x
   アマゾン ウェブ サービス(AWS)
   

   View Slide

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

   View Slide

5. DMMプラットフォームのマイクロサービス歴
   DMMプラットフォームは約6,7年前から
   マイクロサービスアーキテクチャを採用している。
   ＊当時選択したテクノロジースタックはオンプレ&Java&MySQLだった。
   

   View Slide

6. マイクロサービスにおける開発体制で重要なこと
   マイクロサービスにおける開発体制では
   独立性の高い小さいチームを作れるかが重要になる。
   

   View Slide

7. 独立性の高い小さいチームとは?
   以下の2つの方針を利用して説明することができる。
   1. Two-Pizza Team Rule
   2. You build it, you run it.
   

   View Slide

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/
   

   View Slide

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/
   

   View Slide

10. 独立性の高い小さいチームとは?
    独立性の高い小さいチームの要件は以下である。
    1. 小さいチームを作ってコミュニケーションパスを減らす。
    2. オーナーシップを持たせる。
    3. 開発チームは開発から運用まで担当する。
    

    View Slide

11. 独立性の高い小さいチームのメリットとは?
    組織内のコミュニケーションコスト、調整コストを削減し、
    目的を達成するために必要な権限を持つチームが
    単独で物事を進められるようになる。
    “コミュニケーションパスが多い”, “承認が必要” という
    大きい組織ならではの問題を回避するための戦略と見ることができる。
    

    View Slide

12. pospomeが入社した直後の
    DMMプラットフォームはどうだったのか?
    ＊約3年前の話
    

    View Slide

13. 小さいチームを作ってコミュニケーションパスを減らす
    入社直後に確認することができず判断できないが、
    DMMはスモールチームを推奨しているので満たしていたはず。
    チーム内のコミュニケーションパスも限定されていると思う。
    

    View Slide

14. オーナーシップを持たせる
    ワンチームで完結するようなオーナーシップを持っていた。
    ● 開発
    ● プロダクト設計
    ● テクノロジースタックの選定
    ● 採用
    

    View Slide

15. 開発チームは開発から運用まで担当する
    ワンチームで完結するようになっていた。
    ● CI
    ● リリース（CD）
    ● IaC
    ● オンコール対応
    ● 利用者の問い合わせ対応
    

    View Slide

16. pospomeが入社した直後の
    DMMプラットフォームは悪くなさそう
    

    View Slide

17. しかし、開発効率は高くなかった
    

    View Slide

18. 当時のDMMプラットフォームの状態
    DMMプラットフォーム内で利用されていたプログラミング言語
    1. PHP
    2. Java
    3. JavaScript
    4. TypeScript
    5. Go
    6. Kotlin
    7. Elixer
    8. Python
    9. Scala
    10. Ruby
    

    View Slide

19. 当時のDMMプラットフォームの状態
    DMMプラットフォーム内で利用されていたアプリケーション実行環境
    ● オンプレ
    ● Amazon Elastic Compute Cloud(EC2)
    ● Amazon Elastic Container Service(ECS)
    ● AWS Lambda(Lambda)
    ● その他パブリッククラウドのアプリケーション実行環境
    

    View Slide

20. テクノロジースタックがバラバラすぎる
    1. チーム同士の技術的な知見共有が難しかった。
    2. エコシステムの構築が難しい。
    3. 組織内での人員調整や組織変更で一時的に開発効率が下がる。
    大きな組織だからこそ取れる戦略を取ることができない。
    

    View Slide

21. 強いオーナーシップは
    テクノロジースタック以外にも影響を与えた
    

    View Slide

22. ログがチームに閉じている
    他チームのアプリケーションのアクセスログを確認するために
    そのアプリケーションのAWSアカウントのログ閲覧権限が必要になる。
    マイクロサービス環境だと困ってしまう。
    API GatewayチームのAWSアカウント
    API Gatewayのログ
    決済チームのAWSアカウント
    決済アプリケーションのログ
    

    View Slide

23. ログ以外もバラバラ・・・
    以下のような問題もあった。
    マイクロサービスでは必須となるルールが統一されていなかった。
    ● 認証方法が統一されていない。
    ● マイクロサービス同士の依存関係が分からない。
    ● HTTPリクエストに紐づくトレースがつながらない。
    

    View Slide

24. 究極にサイロ化しており、
    スタートアップの集合体のようだった
    

    View Slide

25. なぜサイロ化したのか
    pospomeが入社する前の話なので詳細は分からない。
    

    View Slide

26. この問題をどうやって解決するのか?
    各チームの個別最適化から全体最適化に移行する必要がある。
    ● テクノロジースタックの統一
    ● 開発ルールの標準化
    

    View Slide

27. 個別最適化のイメージ
    DMM会員チーム
    独自のテクノロジースタック
    独自の開発ルール
    プロダクト設計
    採用
    決済チーム
    独自のテクノロジースタック
    独自の開発ルール
    プロダクト設計
    採用
    

    View Slide

28. 全体最適化のイメージ
    DMM会員チーム
    プロダクト設計
    採用
    決済チーム
    プロダクト設計
    採用
    共通のテクノロジースタック
    共通の開発ルール
    

    View Slide

29. 全体最適化の程度
    全体最適化の程度
    小さい 大きい
    各チームの要件
    満たせる 満たせない
    

    View Slide

30. 全体最適化のイメージ
    DMM会員チーム
    プロダクト設計
    採用
    決済チーム
    プロダクト設計
    採用
    共通のテクノロジースタック
    共通の開発ルール
    独自のテクノロジースタック
    独自の開発ルール
    独自のテクノロジースタック
    独自の開発ルール
    

    View Slide

31. 全体最適化 = オーナーシップの程度設計
    全体最適化というのは、
    開発チームに与えるオーナーシップの程度（権限の強さ）を
    適切なものに再設計するということである。
    

    View Slide

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/
    

    View Slide

33. Amazonの例
    社内に共通のビルドシステムや
    デプロイシステムが存在し、
    それを活用することで
    機械的にベストプラクティスを
    浸透させている。
    組織としての戦略やサポートが存在する。
    https://aws.amazon.com/jp/builders-library/going-faster-with-continuous-delivery/
    

    View Slide

34. DMMプラットフォームにとっての最適を定義する
    他社の事例をそのまま適用することはできない。
    ● エンジニアの人数が違う
    ● エンジニアのスキルレベルが違う
    ● ビジネス領域が違う
    ● 抱えている課題が違う
    

    View Slide

35. 全体最適化をどう進めたのか?
    

    View Slide

36. 専門チームの必要性とトップダウン
    DMMプラットフォーム規模の全体最適化は専門チームが
    フルコミットしないと難しい。
    120人のエンジニアの承認を得て進めるのも難しいので、
    改善活動自体もある程度トップダウンで進める必要がある。
    

    View Slide

37. 全体最適化への投資
    全体最適化によって各チームが今まで利用していたテクノロジースタックの一
    部が利用できなくなるので、短期的な開発効率は下がってしまう。
    全体最適化は未来に向けた投資なので、
    DMMプラットフォームとしての意思決定と投資が必要になる。
    最終的にCTOに相談して全体最適化を進める承認を得た。
    

    View Slide

38. マイクロサービスアーキテクトグループの設立
    全体最適化を担当するための組織である。
    ● 認証認可チーム
    認証認可領域を担当する。
    ● SREチーム
    インフラ領域を担当する。
    ● Developer Productivity Team
    認証認可、インフラ領域以外を担当する。
    

    View Slide

39. 運用モデルについて
    サービス開発・運用における
    役割を図にしたものである。
    役割が分かれているほど
    コミュニケーションコストが
    高くなり、開発効率が悪くなる。
    https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/fully-separated-operating-model.ht
    ml
    

    View Slide

40. 今までのDMMプラットフォームの運用モデル
    アプリケーションエンジニアが
    自分たちでインフラを運用する。
    

    View Slide

41. 今後目指すDMMプラットフォームの運用モデル
    今後目指すべき姿に近い。
    SREチームが各チームに向けて
    必要な仕組みを提供する。
    120人のエンジニアが利用する
    共通インフラを開発する必要がある。
    

    View Slide

42. SREチームの活動について
    

    View Slide

43. SREチームの最初の一歩
    ログ/メトリクスの共通ルールを定義し、各チームに徹底してもらう。
    DMMプラットフォームではDatadogにそれらを集約している。
    HTTPリクエストに紐づくログの検索や
    トレース情報の確認が可能になった。
    マイクロサービス間の依存関係も可視化できるようになった。
    

    View Slide

44. システムアーキテクチャ図
    Datadog
    

    View Slide

45. アプリケーション実行環境の統一
    ● クラウド上に共通利用するアプリケーション実行環境を構築する。
    120人が共通利用するものを構築する必要がある。
    ● アプリケーション実行環境にはk8sを採用した。
    マルチテナント型になっており、
    1アプリケーション1namespaceという構成で
    論理的なリソース境界を定義している。
    

    View Slide

46. SREチームのAWSアカウント
    Amazon Elastic Kubernetes
    Service (EKS)
    システムアーキテクチャ図
    Datadog
    マイクロサービス
    青色はSREチームが管理するもの。
    灰色は開発チームが管理するもの。
    

    View Slide

47. DMMプラットフォームはマルチクラウド
    今まで開発チームに強いオーナーシップをもたせた結果、
    開発チームが利用しているクラウドもバラバラだった。
    どちらかに寄せ切るのが難しかった。
    

    View Slide

48. SREチームのAWSアカウント
    Amazon Elastic Kubernetes
    Service (EKS)
    システムアーキテクチャ図
    Datadog
    マイクロサービス
    他のパブリッククラウド
    k8s
    マイクロサービス
    

    View Slide

49. CDツールの統一
    CDツールとしてはArgoCDを採用した。
    

    View Slide

50. SREチームのAWSアカウント
    Amazon Elastic Kubernetes
    Service (EKS)
    システムアーキテクチャ図
    Datadog
    マイクロサービス
    他のパブリッククラウド
    k8s
    マイクロサービス
    ArgoCD
    

    View Slide

51. コンテナレジストリの統一
    CDに伴ってコンテナレジストリも共通のものを提供している。
    

    View Slide

52. SREチームのAWSアカウント
    Amazon Elastic Kubernetes
    Service (EKS)
    システムアーキテクチャ図
    Datadog
    マイクロサービス
    他のパブリッククラウド
    k8s
    マイクロサービス
    ArgoCD
    Container
    Registry
    

    View Slide

53. SREチームが管理するもの
    各チームが開発に必須となるものから優先的に用意している。
    ● Datadog
    ● k8s
    ● CD
    ● コンテナレジストリ
    

    View Slide

54. SREチームが管理しないもの
    各チームにオーナーシップを持たせるものは管理しない。
    ● CI
    ● DB（RDS, DynamoDB, etc）
    ● インメモリキャッシュ（Elasticache）
    ● オブジェクトストレージ（S3）
    ● などなど・・
    

    View Slide

55. SREチームが管理しないもの
    各チームが管理するAWSリソースは各チームのAWSアカウントで
    管理してもらっている。
    各チームのAWSアカウントとk8sが存在するAWSアカウントは
    AWS Transit Gatewayで接続されている。
    

    View Slide

56. SREチームのAWSアカウント
    Amazon Elastic Kubernetes
    Service (EKS)
    Transit Gateway を利用したVPC接続
    Datadog
    マイクロサービス
    他のパブリッククラウド
    k8s
    マイクロサービス
    Transit
    Gateway
    ArgoCD
    開発チームの
    AWSアカウント
    RDS
    CI
    Container
    Registry
    

    View Slide

57. 共通インフラにおける各チームの独立性
    インフラ領域のテクノロジースタックを統一しているが、
    各チームが必要性以上に独立性を失ってしまうと意味がない。
    

    View Slide

58. 各チームの独立性を保つ仕組み
    

    View Slide

59. 共通インフラの利用申請 & 権限変更
    共通インフラの利用者は
    単一のGitHubリポジトリで
    Terraformによって管理している。
    利用者による申請&開発チームによる承認が
    可能となっている。
    

    View Slide

60. アプリケーションのデプロイ（ArgoCD）
    ImageOpsによって開発チーム自身がアプリケーションを
    任意のタイミングでデプロイできる。
    他チームのアプリケーションをデプロイすることはできない。
    

    View Slide

61. アプリケーションのk8sマニフェスト変更
    単一のGitHubリポジトリで各アプリケーションの
    マニフェストファイルを管理している。
    開発者自身が任意のタイミングで変更することができるが、
    GitHubのCODE OWNERSによってファイルの権限を管理しているので、
    他チームのマニフェストファイルを変更することはできない。
    

    View Slide

62. 利用者ドキュメント
    各チームが自分たちで調べてインフラを
    利用できるようにする。
    学習コストも削減できる。
    

    View Slide

63. 仕組みを提供し、自由に使ってもらう
    開発チームが自分たちで安全に操作できる仕組みを提供することで、
    開発チームの独立性を損なわないようにしている。
    

    View Slide

64. インフラにおける全体最適化の悩みどころ
    

    View Slide

65. オーナーシップ vs 権限管理
    共通インフラで各チームに合わせた細かい権限設定をするために
    仕組みを作り込むのは大変。
    現在の権限管理は性善説ベースの部分が多いが
    「誰がいつ何をしたのか」は追えるようになっており、
    致命的な問題を防ぐための最低限の対策は用意している。
    

    View Slide

66. 技術の詳細をどこまで隠蔽するか?
    例：k8sのマニフェストファイルをどこまで抽象化するか?
    SREチームが技術の詳細を隠蔽する仕組みを提供すると、
    開発チームの細かい要件を満たすことができなかったり、
    SREチームとのコミュニケーションが発生してしまう可能性がある。
    

    View Slide

67. 技術の詳細をどこまで隠蔽するか?
    DMMプラットフォームでは技術の詳細をほぼ隠蔽せず、
    素の状態で使ってもらっている。
    自分たちが使う技術は自分たちで理解してないと
    開発・運用をワンチームで完結させることは難しいと思っている。
    それにかかる学習コストも投資として割り切る。
    

    View Slide

68. 技術の詳細をどこまで隠蔽するか?
    DMMプラットフォームは元々強いオーナーシップを持っていたので、
    この方針に倒せる環境だった。
    

    View Slide

69. 共通インフラが開発チームの要求を満たせるか?
    共通インフラを構築する前に開発チームに要求をヒアリングし、
    可能な限り要求を満たす仕組みを目指す。
    開発の優先度とスケジュールも確認する。
    開発チームの要求に妥当性があるかどうかはケースバイケースなので、
    単に要求を満たすだけでなく、ディスカッションすることになる。
    

    View Slide

70. 開発チームがSREチームへ依存するようになる
    開発チームがオーナーシップを持って解決すべき問題を
    SREチームに頼ってしまうケースがチラホラある。
    最初は新しいテクノロジーに対する習熟度が低く、
    責任境界を判断できないこともあり、こういった形になってしまう。
    SREチームは開発者が自立して作業できるように
    サポートする必要がある。
    

    View Slide

71. 現在のDMMプラットフォーム
    

    View Slide

72. 現在の全体最適化の状況
    DMM会員チーム
    プロダクト設計
    採用
    決済チーム
    プロダクト設計
    採用
    プログラミング言語, アプリケーション実行環境 , CD, Log/Metrics
    CI, DB選定, クラウド選定, QA CI, DB選定, クラウド選定, QA
    

    View Slide

73. 解決できた課題
    当時のDMMでは難しかったことを少し実現できるようになってきた。
    1. 各チームの知見共有
    2. エコシステムの開発
    3. 特定のプロジェクトに人を寄せる
    

    View Slide

74. デファクトスタンダードを選択しない自由
    各チームの判断によって
    ”デファクトスタンダードを選択しない”ことも許容している。
    しかし、DMMプラットフォームの技術戦略（エコシステム）の恩恵を
    受けれないので、メリデメを判断してもらうことになる。
    

    View Slide

75. 全体最適化に対するアンケート結果
    全体最適化を進めて2年ほど経ったタイミングでアンケートを取った。
    結果は良好だが、まだ投資フェーズであることがわかる。
    「共通インフラは開発効率の向上に貢献していますか?」
    ● 貢献していると思う … 80%
    ● まだ判断できないが将来的には貢献すると思う … 15%
    ● 自分たちで構築するのと変わらない … 5%
    

    View Slide

76. まとめ
    ある程度大きな開発組織の場合は
    オーナーシップの程度を設計することが重要である。
    単にオーナーシップを与えるのではなく、
    開発チームをサポートする組織的な技術戦略の考慮も必要である。
    そういったものを考慮した上で個別最適化に倒すのも戦略としては
    問題ないと思っている。
    

    View Slide

77. ご清聴ありがとうございました
    

    View Slide