社内の基盤を活かして爆速開発を実現するために重視したマイクロサービステンプレートの5つの要点

マイクロサービス テンプレートリポジトリ プラットフォームエンジニアリング

はじめに

はじめまして、MonotaROのCTO-Officeに所属する伊藤と申します。

github.com

recruit.monotaro.com

MonotaROでは現在、継続的なリアーキテクチャの一環として一部機能へのマイクロサービスアーキテクチャ導入/移行に取り組んでいます。

以前のブログ記事に記載の通り、私は昨年2023年３月にMonotaROに入社し、4月頃からAVLサービスという新しいマイクロサービスを開発するチームに所属することになりました。

その頃に私が感じていたのは、転職された方の多くが感じるかもしれない転職後の喪失感の類でした。

転職後の二つの喪失感への対応

MonotaROに転職した際、私が抱いた喪失感は二つありました。一つ目は前職で培ったドメイン知識が全くなくなってしまったこと、そしてもう一つは前職で利用できていたマイクロサービス開発のための内部開発者プラットフォーム/ポータル（IDP）のようなものがなかった（ないよう見えた）ことでした。この喪失感を克服するために、特に後者に対して、私自身がストリームアラインドチームの一員として取り組みを始めることにしました。（注: その当時の私は内部開発者プラットフォーム/ポータルという言葉と概念は知りませんでしたが、わかりやすさのために、今の私の知識に基づいて当時感じたこと/思ったことを表現しています。以後も同様です）

本記事では後者の取り組みの過程と成果について述べます。

所属チームの現状とMonotaROのアプリケーション/サービス共通基盤（所謂プラットフォーム）

所属チームの状況

私の所属しているチームは、以前のこちらの記事で触れたように、AVLサービスの開発を早期に行うことが求められていました。また、AVLサービス以後も新規に複数のマイクロサービスの開発も見込まれていました。しかしながら、チーム内外にマイクロサービスの開発経験者はほとんどいませんでした。一方で、私自身は前職でストリームアラインドチームの一員として、GoやGitHub Actionsを活用したマイクロサービス開発を経験済みでした。

社内プラットフォームの状況

昨年4月頃、社内の色々な方と会話していくうちに、MonotaROにはセルフサービス化の前提となる"基盤"がないわけではなく、基盤自体はある程度整っていたことがわかりました。k8sクラスタのためのコンテナ基盤（EKS、GKE）や、ログ基盤（fluentdとGoogle Cloud Logging、BigQueryの組み合わせ）などがあり、利用されていることがわかりました。

ただし、それらに対するリソース作成や設定といった作業は、開発者自身が手でコーディングするか、もしくは、SREに設定をJIRAやSlackで依頼することで行われていました。また、その時点（2023年4月時点）ではそれらの手順の一部がドキュメント化されていなかったり、記載がすでに古くなっていたり、属人化していました。

加えて、その頃、当社では全社的にBitBucketからGitHubに移行している時期だったため、CI/CDパイプラインとしてそのまま使えるようなGitHub Actionsは社内にはまだありませんでした。

マイクロサービス開発のためのテンプレートの導入

前述のプラットフォーム及び所属チームの現状を踏まえ、マイクロサービスを開発するためのテンプレートを作ることにしました。テンプレートには、マイクロサービス実装とアプリケーションマニフェストのテンプレートリポジトリや共通ライブラリからなります。それらには、CI/CDのためのGithub Actions、アプリケーションマニフェスト、基盤活用を前提としたオブザーバビリティに関する実装や設定が含まれます。

これにより、AVLサービス開発チームはその工数を、マイクロサービス実装に伴う非機能要件に関するコーディングや設定に時間を割くことなく、ドメインロジックの設計や実装にフォーカスできるようになりますし、今後、そのテンプレートを軸にプラットフォームエンジニアリングの文脈でいう所謂ゴールデンパスやセルフサービス化された社内プラットフォーム、IDPを構築する礎になると考えました。

開発のロケットスタート：テンプレートの早期提供

AVLサービス開発のリズムを生み出し、ロケットスタートを切りたかったため、テンプレートをできるだけ早期に提供するよう心掛けました。最初は非常に荒い作りではあるものの一通りきちんと動作する初期バージョンを実装し、それをチームに提供しました。これにより開発のロケットスタートがきれたと同時に、AVLサービスを開発しながら他メンバーと共にそれをブラッシュアップしていくという良い流れができました。

テンプレート作成の5つの要点

開発中に発生した要件に対応できるよう、チームメンバーと共にテンプレートをブラッシュアップしていきました。その設計/実装の際に気をつけた点を以下にまとめてみました。

1. ベンダー非依存なObservabilityの実装

テンプレートのアプリケーションコードからはできるだけベンダー固有(Datadogなど）のSDKに依存しないようにし、OpenTelemetryのSDKにできるだけ依存するようにすることで、ベンダーロックインを防ぎ、将来的にベンダーを切り替える際にもコードの変更を最小限に抑えることができるようにしました。また、分散トレースについてはDatadogが主に使われていましたが、分散トレースに対応しているのはごく一部でした。そのため、PythonのDatadogのSDK (ddtrace) を用いたサービスからOpenTelemetryのSDKを用いた新しいサービスを呼び出した場合にトレースが繋がることを確認するための調査や実験も行い問題ないことを確認しました。

2. CI/CDを早期に提供（特にLinterを最初期に）

テンプレートの初期の時点でCI/CDに関するGitHub Actionsを整えました。特にLinterは重要だと考えました。Linterを後から導入すると、既存のコードに対して大量の修正が必要になるためです。

3. APIプロトコルとして、JSON over HTTPとgRPCの双方をサポート

当社のAPI開発はスキーマファーストに行われていないようでしたが、個人的にはスキーマファーストであるべきと思っており、protoファイルによるスキーマファースト開発前提の作りにしました。ただし、当社では当時gRPCは使われていなかったため、gRPCによるAVLサービスの呼び出しに何らかの障壁がある可能性がありました（疎通などで）。もしものワークアラウンドとしてJSON over HTTPによるAPI呼び出しもできるようにconnect-goを用いることにしました。

4. 最低限の薄いフレームワーク

テンプレートに含まれる共通ライブラリは、最低限の薄いフレームワークとして実装しました。このフレームワークの目的はあくまでエンジニアがドメインに関するコーディングにのみ時間を割ける時間を増やすことであり、開発者の自由を奪うものではありません。そこでこのフレームワークでは、エラーハンドリング、ログ出力、トレース、設定の読み込み、HTTP/gRPCサーバーの起動などの必要最低限だが実装するのが面倒な部分のみを開発者に提供するように心掛けました。この心掛けの副次的な作用により、共通ライブラリの初期バージョンを迅速に提供することもできました。

5. セントラルProtobufリポジトリの提供

protoファイルからGo/Python/TSのSDKを自動生成するセントラルProtobufリポジトリを用意し、サービス呼び出しチームへのスキーマ共有とSDK提供を容易にしました。 成果 昨年2023年4月頃から開発開始したAVLサービスは、2023年9月頃に本番環境へとリリースされました。最終的には下記のような構成で稼働しています。

現在の取り組み (2023年10月以降)と今後の展開

現在、私は別の新たなマイクロサービスの開発に携わっています。そのマイクロサービスの開発において、上記のGoによるテンプレートリポジトリや共通ライブラリを活用しています。

ただし、MonotaROのシステムの既存実装の多くはPythonで書かれているため、既存のPython資産をそのまま活用してAPI/マイクロサービスとしたい場合にはGoのテンプレートリポジトリ/共通ライブラリは役に立ちません。そこで、当然なのですが、Pythonのテンプレートリポジトリや共通ライブラリにも取り組み始めようとしているところです。

加えて、AVLサービスを開発していく過程で、私は各種基盤の設定手順について深く理解する機会を得ました。その理解を元にセルフサービス化されたプラットフォームに近づく一歩として、それらの手順を自動化を目指したツールを開発しました。ツールの名称はDevKitとしました。ミッション、ビジョン、ユーザーストーリーなどを順に設定し実装を進め、最終的に、設定コードのPR作成、テンプレートリポジトリの適切なクローニング、サービスカタログの更新などを実現するツールをGo言語で開発しました。

このツールは現在最小機能製品（MVP）の段階であり、今後も改善のための取り組みを続けていく予定です。具体的には、DevKit CLIをAPIパートとCLIパートに分割し、APIパートをBackstageと連携させるなどを検討中です（下記はそのイメージ図）。

成果が得られ次第、引き続き本ブログを通じて報告したいと思います。この記事が何かしらの参考になれば幸いです。

さいごに

本記事に私が書いた取り組みやこれまでのテックブログの様々な記事の取り組みにより徐々にエンジニアが働きやすい技術的な環境（プラットフォーム）が整いつつあると感じています。しかしまだまだやるべきことはたくさんあります。弊社ではプラットフォームをさらに整備していきたい方や、整いつつあるプラットフォーム上でお客様に新たな価値をもたらす開発をしていきたい方、どちらもやりたい方など、モノタロウでは随時エンジニアの採用募集をしております。モノタロウのエンジニアと話してみたいという方は下記のカジュアル面談登録フォームからご応募お待ちしております！