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