この記事は Calendar for DMMグループ Advent Calendar 2021 | Advent Calendar 2021 - Qiita の5日目の記事です。
5日目はプラットフォーム事業本部マイクロサービスアーキテクトチームのpospomeが担当します。
この記事ではDMMプラットフォームにおけるマイクロサービスアーキテクトの働きについて説明します。
マイクロサービスアーキテクトとは?
マイクロサービスアーキテクトという職種は"マイクロサービスアーキテクチャを前提とした組織において、組織的な技術戦略を策定、推進する"という役割を持ちます。 この職種が一般的に存在するかどうかは不明なので（あまり聞かない）、この定義はpospomeが実際にDMMプラットフォームで担っている役割をそのまま書いたものです。 どういった問題を解決する職種なのか? 具体的にどういったことをするのか? という点は後述します。
>この職種が一般的に存在するかどうかは不明
2020年のデブサミでグーグル・クラウド・ジャパンの中井さんが言及しているので、 pospomeが知らないだけでそういった職種が一般的に存在しているのかもしれないです。 ちゃんとした定義もあるかもしれないですね。
デブサミ2020【13-E-5】Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜 #devsumiE #devsumi|togetter.com
DMMプラットフォームが抱える課題
DMMプラットフォームが抱える課題、それは"サイロ化"です。 サイロ化というのはチーム間や部署間で必要な連携（コミュニケーション）が取れておらず、組織全体として業務効率が悪くなるという現象です。
DMMプラットフォームは以下の領域を扱っており、所属するエンジニア数だけでも100名を超える規模です。 組織規模が大きいので、2015年くらいからマイクロサービスアーキテクチャを採用して開発をしています。
- 認証認可
- 決済
- 不正対策
- 会員
- ポイント
- カスタマーサポート
[INFO]
たまに社外の人から「DMMってマイクロサービスやってるんですか?」と質問されるのですが、
実は結構前からマイクロサービス化されています。
DMMプラットフォームは歴史的経緯もあり、この規模の組織で完全にサイロ化していました。 組織内にエコシステムが存在せず、各チームがスタートアップのように完全に独立して動いていました。 スタートアップのように独立して動くとは言え、大きい組織ならではのコミュニケーションパスの多さは存在するので、 スタートアップと同じようにスピーディに動けるわけではありません。 大きな組織特有のエコシステムも存在せず、コミュニケーションが少ないわけでもない、中途半端な状態です。
マイクロサービスアーキテクチャというのは各チームが独立して開発をしたり、技術選定をしたり、いわゆる"オーナーシップ"を持たせた状態であることが好ましいです。 そういった意味ではDMMプラットフォームは究極にオーナーシップを持ったチームで構成されているので、 理想的な組織体制に見えるかもしれません。 しかし、何事にも限度があります。
各チームが究極にオーナーシップを持った結果、DMMプラットフォームはプラットフォームとしての全体の開発効率や技術戦略という観点を持たない組織になっていました。 これは各チームが同じような作業をし、同じような罠にハマり、これといった情報共有もしないという状態です。
各チームが自由に開発してしまうので、テクノロジースタックはバラバラです。 pospomeが入社したときの話ですが、利用しているプログラミング言語だけでも9種類を超えていました。 テクノロジースタックが違いすぎて情報共有したくてもできなかったのかもしれません。
DMMプラットフォームはDatadogを利用しているのですが、APMのトレースは各チームやアプリケーションの単位で閉じていました。 サービスマップも全く繋がっていませんでした。 ログには複数のトレースIDが存在します。 どれを利用すればログが紐づくのか分かりませんし、検索した結果本当にすべて紐付いているのかも分かりません。
アクセスログの保存も各チームのCloud Logging, Cloud Watch Logsで閉じているケースがあり、 他チームのアプリケーションのアクセスログを見るためにはそのチームのGCP ProjectやAWS Accountにログインするアカウントを発行してもらう必要があります。 最終的に全エンジニアが全チームのログインアカウントを持つことになりそうです。 その状態で適切な権限管理ができるのでしょうか。
大きな組織の強みである知見共有やエコシステムなどがほぼなかったので、 pospomeはDMMに入社して真っ先に「なんかもっと全体的にいい感じにしないといけない」と思いました。 ここまでの話でDMMプラットフォームにおけるマイクロサービスアーキテクトが解決する課題が分かったのではないでしょうか。
マイクロサービスアーキテクトチームとは?
こういったDMMプラットフォームが抱える課題を解決するためにpospomeが設立したのが"マイクロサービスアーキテクトチーム"です。 このチームはその名の通りマイクロサービスアーキテクトとしてDMMプラットフォームが抱える共通の技術課題を解決するためのチームです。 設立した手前pospomeが責任者を務めています。
ポイントは"共通の技術課題"という部分です。 DMMプラットフォームは会員や決済などの領域を扱いますが、それらを担当するチームはすでに存在します。 そのため、それらの領域特有の技術戦略にマイクロサービスアーキテクトチームが深く介入することはありません。 あくまで各チームにオーナーシップを持ってもらいつつも、各チームが拾いきれない部分（どこのチームが担当するか明確ではない部分）を拾っていきます。
マイクロサービスアーキテクトチームは以下の職種で構成されます。
- サーバサイドエンジニア
- SRE
サーバサイドエンジニアはサーバサイド領域の課題を解決します。 具体的にはDMMプラットフォームの認証認可基盤の開発やアプリケーションレイヤの技術戦略を考えます。
SREはインフラ領域の課題を解決します。 具体的にはk8sを中心としたアプリケーションプラットフォームを構築します。 便宜上"SRE"という名称にしていますが、 業務内容としては "クラウドインフラエンジニア" & "プラットフォームエンジニア" & "SRE" を兼任しています。 これらの役割を明確にするほどエンジニア数がいないので、実質"インフラ周りを全部やる"という感じです。
最初はpospomeの1人チームで始まったこともあり、チームとして開発に着手できたのがちょうど1年前（2020/11）くらいです。 1年間で解決できる課題はたかが知れているので、解決しなければいけない課題は山積みです。
[INFO]
チーム名に"マイクロサービスアーキテクト"という単語を使っているのは、
今までDMMプラットフォームに存在しなかった組織的な技術戦略というものに取り組んでいくということを明確に示して、
「組織的な技術戦略に関わる部分はマイクロサービスアーキテクトチームに任せよう、相談しよう」
という文化を作りたかったからです。
名前は大事。
マイクロサービスアーキテクトとしての働き
マイクロサービスアーキテクトやチームの説明が終わったので、DMMプラットフォーム内での働きの一部を紹介します。
マイクロサービスアーキテクチャ全体の設計
DMMプラットフォームではシステムアーキテクチャを大きく変える場合、それを実装するチームが Design Doc を書くというルールがあります。 例えば "新しいマイクロサービスを作る" がそれに当たります。
[INFO]
Design Docというのは"そのシステムをどうやって作るのか?"というを書いた設計書のようなものです。
"システムアーキテクチャを大きく変える場合Design Docを書く"
というルールもマイクロサービスアーキテクトチームが作りました。
今ではDMMプラットフォームに限らず、なぜかDMM全体でDesign Docが書かれています。
なぜDMMプラットフォーム以外に広がったのかは謎です。
マイクロサービスアーキテクトチームは各チームから提出される Design Doc をレビューすることによって、 DMMプラットフォームのマイクロサービスアーキテクチャ全体の設計を確認することができます。
マイクロサービスアーキテクトチームが担当するのはあくまでレビューなので、Design Docを書くのは実装を担当するチームになります。 そして、どういったシステムアーキテクチャにするかという最終的な決定権も実装を担当するチームにあります。 これは"そのシステムを開発、運用するチームが最終的な責任を持つことになるから"です。 ただし、その決定が他チームやマイクロサービスアーキテクチャ全体に影響を及ぼす場合は、各チームやマイクロサービスアーキテクトチームと相談しながら方針を決定します。
Design Docのレビューによるメリットは以下です。
- 各チームが抱える課題を認識できる（それを解決するエコシステムを作ることに繋がる）
- 第3者の観点によってアーキテクチャとしての妥当性を保証できる
- マイクロサービスアーキテクトチームをハブとしてDMMプラットフォーム内で技術的な知見の共有ができる
今までサイロ化していて知見共有してこなかった組織でいきなり「知見共有してください」といっても効果は望めません。 マイクロサービスアーキテクトチームはDesign Docをレビューする過程で各チームが持つテクノロジースタックを確認することができるので、 これを利用して各チーム同士のコミュニケーションのハブとなり「このチームでxxxを使っているみたいなので、相談してみてください」と案内するようにしています。
組織的な技術戦略を考える際に重要となるのが各チームのニーズです。 必要とされるものを作っていかなければ意味がありません。 そういった背景もあり、Design Docのレビューによる各チームとのコミュニケーションはとても重要な機会となります。 実際にここから得られた課題がロードマップに反映されることは少なくないです。
一方でマイクロサービスアーキテクトチームのレビュー待ちが発生することで、開発スピードが落ちてしまうというデメリットもあります。 マイクロサービスアーキテクトチームではそれを極力防ぐために、レビューを30分〜1時間ほどのミーティングで口頭によるコミュニケーション1回で済ませるようにしています。
システムアーキテクチャに不備がある場合はチームに持ち帰って検討してもらうことになるので、 必ず1回で済むとは限りませんが、 そもそも開発方針に問題がある状態で開発を進めるわけにはいかないので、 そういった手戻りによって開発スピードが落ちるのは許容しています。
レビューではエンドポイントのURL設計やテーブル設計といった詳細はレビューしません。 あくまでシステムアーキテクチャレベルのレビューにとどめています。 詳細までレビューしようと思うと、実装対象のことを深く知る必要があり、そこに時間を割くことができないからです。
デファクトスタンダードな技術の選定と利用推進
DMMプラットフォームは各チームがサイロ化した結果、テクノロジースタックがバラバラでエコシステムを作りたくても作れない状態でした。 マイクロサービスアーキテクトチームではこれを解消するために、 DMMプラットフォームとしてのデファクトスタンダードな技術を選定し、利用を推奨しています。
例えば、バックエンドサーバはGo言語で実装することを推奨しています。 これによって以下のようなドキュメントベースの知見共有が有効になりました。
ちなみに、pospomeがブログで書いた以下の記事も元々は社内での質問に対する回答をまとめ直したものです。
Goのアーキテクチャとフレームワークについて|www.pospome.work
Goでゼロ値の構造体を生成することを防ぐべきかという話|www.pospome.work
マイクロサービスアーキテクトチームのコードレビューによってGoの知見を共有することも可能になりました。
コードレビューではGoのことはもちろんですが、プログラミング原則やレイヤ構造など言語に依存しない部分もレビューすることになるのでpospomeが想定した以上に各チームから好評です。
マイクロサービスアーキテクトチームによるコードレビューでは"Pull Requestは2日以内にレビューする"などのデッドライン制を採用しておらず、 "週xxx時間をPull Requestのレビューに使用することができる。レビューしきれなかったものは来週レビューする。"というバジェット制を採用しています。 つまり、あくまでベストエフォート型のサポートです。 そのため、レビュー対象のPull Requestはマイクロサービスアーキテクトチームによる Approve がなくても各チームの判断で自由にマージすることができます。 これはマイクロサービスアーキテクトチームのレビュー待ちによる開発スピードの低下を防ぐためです。 Design Docのレビューに限らず、"各チームにオーナーシップを持たせることによって開発スピードの低下を防ぐ"という取り組みは可能な限りあらゆる部分で適用しています。 ベストエフォート型とはいえ"Pull Requestをマージした1ヶ月後にレビューする"というはさすがに遅すぎるので、あまりにレビュー対応が遅くなる場合は別の手段を考えることになります。 コードレビューの方法も基本的にレビュー担当者に一任しており、GitHub上のコメントでやりとりしたり、Zoomを利用してペアプロをしたり、やりやすい方法でやってもらっています。
例として挙げたプログラミング言語に限らず、テクノロジースタックをある程度統一することによってチーム間で知見共有ができるようになったので、"テックリードミーティング"のような場を設けることもできました。
前述したDatadogのトレースやサービスマップがつながっていないという課題も "デファクトスタンダードな技術の選定と利用推進" という観点でマイクロサービスアーキテクトチームがオーナーシップを持って進めています。
今までバラバラだったテクノロジースタックを統一するのは簡単ではありません。 特に各チームの学習コストを削減する仕組みは重要です。 上記で紹介したドキュメントやコードレビューはチーム間の知見共有を目的に提供しているものですが、 各チームの学習コストを削減するという側面もあります。 "新しい技術を導入したけど、結局誰も使わず負債化した"というのはよく聞く話ではないでしょうか。 そういったことがないようにマイクロサービスアーキテクトチームでは選定した技術に対して責任を持ち、 各チームを積極的にサポートしています。
デファクトスタンダードな技術の利用はあくまで推奨なので強制ではありませんが、 マイクロサービスアーキテクトチームが開発するエコシステムはデファクトスタンダードな技術を前提に作られるので、 それらのエコシステムを利用することができなくなるデメリットはあります。 デファクトスタンダードな技術以外を利用する場合は、 このデメリットとその技術を利用するメリットを各チームで比較して判断してもらうことになります。
ここで挙げたGo言語の例とDatadogの例はマイクロサービスアーキテクトチームの取り組みのほんの一部ですが、 なんとなくどういった働きをするのかがイメージできたかと思います。
組織設計
マイクロサービスアーキテクトチームは主にサーバサイド領域とインフラ領域を扱うチームです。 これはチームの設立者であるpospomeのテクノロジースタックに依存しています。
しかし、DMMプラットフォームはサーバサイドとインフラ以外にも扱わなければいけない技術領域があります。 それが"Webフロントエンド"と"UIデザイン"です。 マイクロサービスアーキテクトチーム（pospome）がここを担当するのは難しいので、フロントエンドチームを設立しました。 このチームはDMMプラットフォームのWebフロントエンドとUIデザインの戦略を担当するチームです。 フロントエンドチームの責任者はpospomeではなく、フロントエンド領域に知見のある方にお願いしています。
コンウェイの法則にもあるようにマイクロサービスアーキテクチャの全体設計や組織的な技術戦略では組織体制が重要になります。 コンウェイの法則を逆手に取った"逆コンウェイの法則"によって、アーキテクチャ設計（技術的な観点）から組織体制を見直していくのもマイクロサービスアーキテクトの責務の1つです。 現在はQA領域の改善を計画中です。
開発業務
今までの内容でマイクロサービスアーキテクトチームは手を動かして開発しないのではないか?と思っている方がいるかもしれませんが、 マイクロサービスアーキテクトチームは認証認可領域とアプリケーションプラットフォームの開発を担っているので、 通常の開発業務も行っています。 むしろこれがメイン業務です。 サーバサイドエンジニアはGo+GCPでマイクロサービスを開発していますし、SREはGKE,EKSを中心としてアプリケーションプラットフォームを構築しています。 DMMプラットフォームが抱える課題を解決するために、どういった仕組みをどのように提供するか?をゼロから設計し、実装し切るのは意外と難しいものです。 しかし、ここはマイクロサービスアーキテクト特有の働きというわけではないので、詳しい説明は割愛します。
マイクロサービスアーキテクトの大変さ
"組織の技術戦略をリードする"という表現だとマイクロサービスアーキテクトに対してなんとなくカッコいいイメージを持つかもしれませんが、 100人規模の組織に対して技術戦略を浸透させるという性質上、泥臭い仕事も少なくありません。
DMMプラットフォームが抱える課題の中には自分たちが手を動かして解決できる問題ばかりではありません。 各チームに何かしらの対応を依頼することで解決しなければならないものもあります。 その場合は、進捗をスプレッドシートで管理して、定期的に着手しているか声をかけて・・・ということが必要になります。
何かしらの仕組みを自分たちで実装する場合も、 各チームのニーズとユースケースを確認する必要があるので、まずはヒアリングから入ります。 1日がミーティングで埋まることも珍しくありません。
Design Docのレビューという文脈でも言及していますが、 マイクロサービスアーキテクトチームは各チームに利用してもらう仕組みを作る必要があるので、 ヒアリングにはそれなりに工数をかけますし、 その仕組みを利用しているエンジニアからのフィードバックも積極的に取りに行きます。
自分たちが開発した仕組みを使ってもらうためのドキュメントも重要です。 1日中ひたすら利用者向けドキュメントを書くこともあります。 ドキュメントにはマイクロサービスアーキテクトチームへの問い合わせを削減したり、 各チームのエンジニアの学習コストを削減する効果があるので、 コストパフォーマンスを考慮して最低限必要となるドキュメントを揃えるようにしています。
DMMプラットフォームのマイクロサービスアーキテクトは技術力、ドキュメントスキル、コミュニケーションスキルというエンジニアの総合力が試されるポジションです。 サーバサイドエンジニアであっても、SREであっても、どれかが欠けていると100人規模の組織で技術戦略を進めることは難しくなってしまいます。 pospome個人としては "楽しい50%, 辛い50%" というところでしょうか。 100人規模の組織を扱うのは楽ではありません。(´・ω・`)
マイクロサービスアーキテクトを導入する際の苦労
サイロ化したDMMプラットフォームに"組織的な技術戦略"を導入するのは意外と大変だったのでは?と思う方がいるかもしれません。 現場からの反発があったり、上司の許可を得られなかったり・・・というのは簡単に想像できるケースだと思います。 しかし、幸運にもそういったことはありませんでした。
マイクロサービスアーキテクトチームの設立自体は直接CTOと話をしてトップダウンでサクサク進めることができましたし、 現場で働くエンジニアもGoを積極的に採用してくれたり、Design Docを書いてくれます。 今ではslackやミーティングなど、DMMプラットフォーム内のあらゆるコミュニケーションで当たり前のように"Design Doc"という単語が飛び交いますし、"開発作業に着手する前にDesign Docを書く & マイクロサービスアーキテクトチームにレビューを依頼する"という文化も定着しています。
このような取り組みを始める前にpospomeがやったことと言えば、マイクロサービスアーキテクトチームとして"どのような世界を実現したいのか?"を共有する場を設けたことくらいでしょうか。 これも批判的な意見はなく「とりあえずやってみよう」という雰囲気で終わりました。 組織的な技術戦略の推進には上層部の理解と現場の協力が必須なので、この点はとても助かっています。
[INFO]
マイクロサービスアーキテクトチームの技術戦略は元々DMM全体を対象にしていましたが、
DMMの組織規模で新規チームが全体の技術戦略を変更するのは不可能です。
そこでCTOと相談した結果、
"まずはDMMプラットフォームからスモールスタートする" という結論に至りました。
「スモールといってもエンジニア数は100人を超えるのでスモールでもないのでは?」
ということには後で気づきました。
最後に
今回はDMMプラットフォームのマイクロサービスアーキテクトの働きについて説明しました。 ある程度大きい組織ならではの働きであり、マイクロサービスアーキテクチャや組織的な技術戦略は、その組織の状態や抱える課題によって最適解が異なります。 どこまで参考になるかは分かりませんが「DMMはこういうことやってるんだなー」と記憶の片隅で覚えてもらえると嬉しいです。
Calendar for DMMグループ Advent Calendar 2021 | Advent Calendar 2021 - Qiita の6日目は miyazato-hayato-san です。(｀・ω・´)ゞ
参考
以前書いたやつです。
マイクロサービスアーキテクトという役割｜www.pospome.work
宣伝
マイクロサービスアーキテクトやマイクロサービスアーキテクトチームの働きに興味がある方はぜひpospomeとカジュアル面談しましょう。
