Tech Do | メディアドゥの技術ブログ 

株式会社メディアドゥのエンジニアによるブログです。

半年でマイクロサービスを導入して大規模改修プロジェクトを乗り切った話

こんにちは。メディアドゥでシニアエンジニア・スクラムマスターを担当している濱口です。
本記事では、大規模な電子書店システムに対して、いかにしてマイクロサービス導入を進めたのかを解説しています。

用語解説

・MDCMS-SD
電子書店を構築・運用するための機能を提供する電子書店ウェブサイトの構築システム。100以上の電子書店検索から決済まで提供。

スクラム1週間の流れ

今回の開発体制は4人で、とても少人数です。その中でどう開発を進めたかについて言えば、がっちりスクラムとしています。締め切り駆動開発やウォーターフォールではなく、実際に動かしてみて、どれくらいできたかを見ながら進める形です。

そして、次にどこを目指すか、スプリントが安定するかどうかを見るために1ヶ月ならしてみようとか、残作業をタスクと実績で割った上でどれくらいできるかを測ると言った具合です。測らないと絵空事のロードマップというか、リリース間近になるとデスマーチがはじまるのが容易に予測が付くわけです。それだったら、スクラムをきちんと行おうと考えました。

実際のスケジュールは以下のようになります。

この中でスクラムの言葉ではないものとして、火曜日の3つ目に「ビジネス側と進捗および仕様検討」という堅苦しい言葉があります。スクラムの言葉で、スプリントの内容だけを話しても、ビジネス全体で見たときに、やらないといけないものに対してどこまで進んでいるのか説明したり、やった結果として想定と違うものができたけどどうしますかといった相談はこまめに行わないといけません。そうしないと手戻りが発生することになり、一番の悲劇につながります。

火曜日のこの部分はかなり力を入れて、ビジネス側と強力なタッグを組んでいました。

意識したこと

まず意識していたこととして「取次システム側の変更により大きく変更が入る、認識を合わせる」があります。ちょっとふわっとしているのですが。

書店側としては、MDCMS-SDの裏側が切り替わるんですねくらいの認識です。任せておけば、いつの間にか切り替わっているくらいのレベルを当然求めています。しかし、実際には登録されていたデータについて、MDCMS-SDの時の見え方と切り替わった後で変更があると、オペレーションに跳ね返ってきます。オペレーションに関係するものは仕様や要求として管理されます。しかし、仕様を固めたとしても「実はこういったオペレーションがありましたので何とか合わせないと」といったことについて、細かく認識を合わせていました。実際、蓋を開けてみると電子書店ごとの特殊運用や専用部分の仕様把握はたくさん出てきました。

後は実際システム開発を進める中でスプリントレビューでPO(プロダクトオーナー)という明確なロールはなかったのですが、関連している社内部署の部長や課長などに稼働しているものを見せていました。稼働しているといっても裏側の変更なので、JSONやデータベースのレコードレベルでの確認になるのですが。

ただ、こういったレビューはメンバーのモチベーション維持や開発進捗の認識あわせという意味でも大事になります。コマンドラインで実行したらデータが変わりますとか、真っ黒い画面に文字が出るといったレベルであっても、メンバーからビジネス側の方々に対して説明を行っています。技術専門分野じゃない方からすると分かりづらい内容だったとしても、進捗にちゃんと結びついていることをコミュニケーションしていた感じです。

そういった共有、認識合わせ、要望くみ取り、進捗把握そして心理的安全性を重視して回していました。

結果

そうやって6ヶ月経った訳ですが、何とかシステムはできあがりました。そこから期間をかけて書店さんの実際の切り替えを行っていきました。振り返ってみれば、自分たちがGoで書いたシステムが正しく動くと自信を持って言えたのは、ユニットテストのカバレッジが80%を超えていたからだと思います。

最初の移行については、時間がかかるかも知れませんと前置きした上で進めていました。しかし、途中からは作業の殆どはスクリプト化され、当日の手順書すらプログラムで出力していました。移行も2時間で完了するレベルまで最適化が進んでいます。事故もほぼ起こらず進みました。

MDCMS-SD本体について、見積もり時には影響範囲がどれくらいか見えませんでした。しかし、結果的に接続先のドメインを変更する程度(100行程度)にできたことで、影響を掌握できるレベルで着地できました。2019年に開発が終わって、2020年前半には100社の切り替えが完了しています。現在、それから3年経っていますが、障害やバグも起こらずに運用できています。

保守運用については、私含めて最近ミドルレンジになってきたエンジニアと2人でほぼ回せています。NoSQLを使ってみようということで導入したDynamoDBですが、現在7500万件くらいのレコード数がありつつも、レイテンシーは数ミリ秒を維持できています。このDynamoDBでは書誌データ(書籍のメタデータ)や購入履歴などのデータを扱っています。

レコメンドの結果についても機械学習を使っているだけあって、体感として良いお勧め情報が出ているように感じます。定性的にはなりますが、精度が向上しているかもといったフィードバックが得られています。

※この記事は12月9日に行われたサブカル業界Developers 勉強会 Vol.3にて行われたセッションの内容を書き起こした記事です