はじめに
DMMグループAdvent Calendar 2023 の22日目を担当する、いっぬ（@yuyu_hf）です。
プラットフォーム事業本部 MSAグループ 認可チームで、DMM Platformの認可のマイクロサービスの開発・運用をしています。
「マイクロサービス」という言葉が広く知られるようになり、さまざまな規模の開発チームで採用したという話を聞くようになりました。しかし、採用した後にマイクロサービス特有の大変さに気づくことも多く、採用すると開発現場でどのような大変さがあるかまではあまり知られていないと思っています。
私が所属するプラットフォーム事業本部では「DMM Platform」と呼ばれる、決済・会員・認証などのDMMのプロダクトが共通で利用する仕組みを提供するプラットフォームを開発しています。DMM Platformではマイクロサービスを採用し、決済・会員・認証などのドメインごとにプロダクトおよびチームが分割されています。
本記事では私が開発・運用を通して感じた、マイクロサービスを採用する大変さについて、いくつかのエピソードを紹介します。
大変だと思ったエピソード
チームを横断した知見の共有
マイクロサービスを採用すると、組織内の知見の共有難易度が高くなる可能性があります。
私が入社する前からDMM Platformではマイクロサービスを採用し、サービスごとに開発チームが分かれていました。チームごとに技術選定を行い、チームを横断して知見を共有する仕組みも無かったため、組織内にたまった知見を活かせないといった開発効率が悪い状態に陥っていました。「別々のスタートアップが集まったような組織」といえば分かりやすいと思います。そのような組織で具体的にどのような問題があったかについては、以下のpospomeさんのスライドをご覧ください。
DMMプラットフォームのマイクロサービス戦略 オーナーシップの落とし穴
チームを横断して知見を共有するために、新たに作った仕組みの1つとしてレビューシステムを紹介します。
DMM Platformでは、各マイクロサービスで利用する技術をある程度統一し、技術戦略の1つとする上で今回Goを採用しました。マイクロサービスを新規で作成する場合はGoで開発し、既存の場合はGoでリライトしています。以前は、PHPやJavaで開発することが多く、またその当時はGoで開発できる知見を合わせ持つエンジニア自体が少ない状況でした。そのため、今回はGoで開発する知見を、チームを横断して共有を行うために、レビューシステムの運用を始めました。
レビューシステムでは、Goとソフトウェアアーキテクチャについて知見があるエンジニアがDMM Platformのマイクロサービスのコードレビューにレビュアーとして参加します。レビュアーはGoの書き方からDDDの導入支援まで、さまざまなサポートをします。
レビューシステムの導入によって開発効率がどれくらい改善されたかは、定量的には評価できていません。定性的な評価として、レビューシステムを利用している現場のエンジニアの感想を定期的に集めています。現場のエンジニアの反応は割と好評でした。
私は、レビューシステムを立ち上げてからの約1年間はレビュアーをつとめました。レビューシステムは現在も運用されており、レビューシステムの運用開始から現在まで、レビューシステムがどのように進化しているかは、以下のpospomeさんのスライドをご覧ください。
組織のコード品質を向上させる “レビューシステム”の取り組み
ログ基盤の構築
私がプラットフォーム事業本部に入ったときには、すでにマイクロサービスを採用していましたが、共通のログ基盤や分散トレーシングといった各サービスを横断して監視する仕組みはありませんでした。当時は、例えばログはチーム内で閉じており、マイクロサービスで何か問題が発生したときには原因調査に時間がかかっていました。
DMM Platformではマイクロサービスを横断して監視するためのログ基盤として、Datadogを採用しました。Datadogを採用した後は、各サービスに共通してDatadogを利用するためのルールを作成し、ログやトレースをDatadogへ送るように各チームに依頼・対応してもらう必要がありました。
以下のように、対応状況をspreadsheetで管理し、マイクロサービスを管理する各チームの対応可能なスケジュールを確認しながらDatadogの導入を進めていきました。
ログ基盤の構築が始まってから2年以上が経ち、マイクロサービスのログとトレースのほとんどがDatadogで確認できるようになりました。以下のように各サービスのトレースから、依存するサービスのトレースと、トレースに紐づくログを確認できるようになっています。
車輪の再発明の防止
DMM Platformではマイクロサービスを採用し、開発チームはサービスごとに分かれていました。チームごとに技術選定し、以下のような同じような仕組みを作成していて開発効率が悪い状態に陥っていました。
- マイクロサービスでアクセスログを出力するミドルウェア
- マイクロサービスを動作させるインフラ環境
- マイクロサービス用のCI/CDの仕組み
- 負荷試験用のスクリプトやインフラ環境 など
本記事では負荷試験の開発効率を改善したことについて説明します。
負荷試験をするときに、各チームで負荷試験用のスクリプトやインフラ環境を1から作成しており開発効率が悪い状態でした。また、マイクロサービスの開発では依存するサービスのパフォーマンスを考慮する必要があります。ですが、負荷試験結果のレポートのフォーマットや管理場所がチームごとに異なっていたため、依存するサービスのパフォーマンスをすぐに確認できない状態でした。これらの問題を解決するために、DMM Platformのマイクロサービスが共通で利用できる負荷試験基盤を作成しました。
負荷試験基盤は以下のようなアーキテクチャで構成されています。開発者は事前に用意されたテンプレートに沿って設定ファイルと試験スクリプトを書くだけで、k8s上にスケール可能な負荷試験のインフラ環境が立ち上がり、負荷試験を実施してくれます。
負荷試験結果のレポートは共通のフォーマットで出力し、DMM Platformの開発者であれば誰でも閲覧できる場所でホストしてチームを横断した知見の共有をできるようにしています。
具体的にどのような負荷試験基盤を作ったかは以下のスライドをご覧ください。
マイクロサービスは費用がかかる
大変だったことではないですが、マイクロサービスを採用すると費用が高くなる可能性があり、アクセスログを例に説明します。
モノリスのアプリケーションでは1つのリクエストに対して1件のアクセスログを出力しています。マイクロサービスを採用すると、1つのリクエストに対して依存するサービス分のアクセスログを出力します。例えば、DMMのプロダクトがDMM Platformを利用する場合、最低3つのマイクロサービスを利用するので1つのリクエストに対して4件のアクセスログを出力します。モノリスのアプリケーションに対してアクセスログを保存する費用が4倍多くかかります。
会社の事情で具体的な金額は書けませんが、DMM Platformのログ費用はとても高額です。ログに限らず、安易にマイクロサービスを採用するとモノリスと比較してインフラ費用が高くなる可能性があります。
まとめ
本記事ではマイクロサービスを採用する大変さについて、私が実際に開発を通して経験したエピソードをいくつか紹介しました。マイクロサービスを採用するときに参考にしてみてください。
マイクロサービスについて深く理解するには、マイクロサービスを採用している組織で、開発をするのが一番の近道だと考えています。認可チームではDMM Platformのマイクロサービスを支える認可の仕組みを開発しており、現在サーバーサイドエンジニアを募集しています。マイクロサービスの認可の仕組みに興味がある人は、以下のリンクからカジュアル面談または本選考をぜひ申し込んでみてください。
