Mirai Translatorがマイクロサービスアーキテクチャを採用した理由
みらい翻訳ではリーン開発に取り組み、マイクロサービスアーキテクチャを目指しているという。「新しいアイデアを素早くサービスに仕上げて、そのサービスから得られるデータをもとに新しいアイデアを生み出す……その仮説検証サイクルを高速に繰り返すことで、素晴らしいサービスを生み出していく」というリーンスタートアップに基づいた開発を高速で行うためである。
みらい翻訳の開発速度は、デプロイの頻度と、設計からリリース完了までの期間を表すリードタイムという指標で計測している。現状ではデプロイは週に1回程度、リードタイムは1週間～1か月以上に渡ってしまうものもある。宮田氏は「デプロイ頻度が1日に1回かそれ以上という会社も最近は増えているので、私たちもそこを目指していきたい」と話す。
同社において開発速度が遅くなってしまう原因には、「修正対象の競合が多い」ことと「リリースプロセスが複雑」であることの2つがある。提供している機械翻訳アプリケーション「Mirai Translator」は、複数のチームで開発を行っているのだが、各チームが修正したいモジュールが競合しやすいために、リリースタイミングの調整に大きな手間がかかり、リードタイムが延びてしまう。さらにリリースプロセスが複雑で、リリース作業そのものに5日もかかることもある。
競合しやすい原因として宮田氏は「私たちのMirai Translatorは技術負債を抱えたモノリシックなものになっているからだと考えています」と述べた。各機能が密結合になっている部分が非常に多く、デプロイ単位がシステム全体になっているために機能単位でのリリースができないのだ。この課題を解決するために、Mirai Translatorでマイクロサービスアーキテクチャを採用することになった。マイクロサービスアーキテクチャとは、複数のサービスで1つのシステムを構成するアーキテクチャ構造のことだ。マイクロサービスアーキテクチャの場合、次の利点と欠点がある。
利点
- サービス単位でデプロイできる
- サービス間の依存が発生しにくい
欠点
- サービス間のトランザクションを保てない
- 全体のデプロイや運用は複雑化
- モノリスでは不要な技術が必要
このような欠点があってもマイクロサービスアーキテクチャを採用することにしたのは、次の3つの理由からである。まず「サービス単位でのデプロイを可能にしたい」ため。サービス単位でデプロイができれば、チーム間でのリリースのタイミング調整が不要になり、リードタイムを減らせる可能性がある。
2つ目に「モノリスのリファクタリングによる解決は困難」なため。各機能が密結合になっている状態を改修するには、サービスの停止を伴う大規模な改修で難易度が高いことが予想される。
3つ目の理由は「トランザクションの必要箇所は少ない」だ。現在の使用状況から、結果整合性でも良い箇所が多いと考えられた。問題はいかにしてマイクロサービスアーキテクチャへと移行していくか、である。
マイクロサービスアーキテクチャへの移行に伴って浮上する技術基盤の問題
Mirai Translatorがマイクロサービスアーキテクチャへ移行するにあたって、ビッグバンリライトとストラングラーパターンの2つの方法が考えられた。ビッグバンリライトは年単位の時間をかけて作って、一気にマイクロサービスアーキテクチャに置き換えるという方法である。宮田氏は「非常にリスクが高いためにできないだろうと考えています。ビジネス的に新機能開発を止められないため、リソースも社内だけでは足りないという問題もあります」とビッグバンリライトを採用しない理由について説明した。採用されたのは、ストラングラーパターンである。
ストラングラーパターンとは、小さい単位で開発して置き換えていく手法のことだ。これであればリスクが低く、なおかつ新規開発を止めずに済む程度の開発リソースを残すことができると考えられる。残された課題は、技術基盤がまだ足りていないということだ。モノリスだったときは不要だった技術基盤が、マイクロサービスアーキテクチャに移行することによって必要になるのである。
必要になる技術としては、サービス間の非同期なメッセージング基盤が考えられる。マイクロサービスアーキテクチャに移行しても、サービス間の依存関係はまったくなくなるわけではないため、サービス間の通信がどうしても必要になる。しかし例えばREST APIを同期的に呼び出すといったことをしてしまうと、それはサービス間の密結合になってしまい、モノリスのころと何も変わらない。そのためサービスは非同期なメッセージングによる通信が必要になる。
またモノリスからサービスへのデータ同期基盤も必要になる。ストラングラーパターンを採用するということは、一部分はマイクロサービスで稼働し、残りの部分はモノリスで稼働しているという、いわゆるダブルメンテの状態が一定期間存在することになる。その間、マイクロサービスを抱えるDBとモノリスのDBとの間に依存関係が生まれるパターンがどうしても存在してしまうことが予想されている。そのためダブルメンテの間、モノリスからマイクロサービスへとデータを同期させる基盤が必要になるのだ。
そしてもう一つはユーザーリクエストサービスとモノリスに振り分ける基盤だ。ダブルメンテのため、このリクエストはモノリスに、このリクエストはマイクロサービスに、というように振り分けるProxy的な基盤が必要だ。宮田氏は「大まかなマイクロサービスへ向けたロードマップとして、まず技術基盤を構築して、続いてマイクロサービスの試験実装をやってみてうまくいったら、主要機能のマイクロサービス化というふうにやっていければいいなと考えています。いま現在は技術基盤を作り上げることに集中しています」とみらい翻訳で取り組んでいる、マイクロサービスアーキテクチャへの向けたロードマップと現在の状況について話した。
