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的な基盤が必要だ。宮田氏は「大まかなマイクロサービスへ向けたロードマップとして、まず技術基盤を構築して、続いてマイクロサービスの試験実装をやってみてうまくいったら、主要機能のマイクロサービス化というふうにやっていければいいなと考えています。いま現在は技術基盤を作り上げることに集中しています」とみらい翻訳で取り組んでいる、マイクロサービスアーキテクチャへの向けたロードマップと現在の状況について話した。
リードタイム短縮で行われたデプロイ改善――ブランチ戦略の見直しとCI/CDツールの置き換え
SREチームの川村氏にバトンタッチして、セッションが続けられた。川村氏の講演テーマはリリースプロセスにおけるデプロイ改善。リリースのリードタイムを短縮することで開発者の負担を減らし、よりリーンな開発を目指せるようにするために行われたのが、ブランチ戦略の見直しとCI/CDツールの置き換えである。
Mirai TranslatorのアプリケーションのソースコードはGitHubで管理し、ブランチ戦略としては git-flowをベースにしている。Mirai Translatorではベーシックやエンタープライズなど複数のプランが用意されており、プランごとにVPCレベルでリソースが分かれる構成になっている。さらに、ステージング環境と商用環境があり、それぞれの環境ごとにプランのリソースが存在する。商用環境のコピーがステージング環境にある状況である。そしてプランと環境ごとにGitHubのリポジトリにリリースブランチが存在し、ブランチごとにビルドとデプロイを行っているのだ。
プラン・環境ごとにブランチが分かれているためコードベースが環境ごとに異なり、ブランチごとのコミットを気にしなくてはならないという問題がある。ほかにも、リリースブランチごとにビルドを行う、プルリクエストを作るなどの負担が生じる。そして、プランが増えるとその分デプロイの負担も増えていくため、リリースの負担がどんどん増えていくのである。
これらの課題を解消するために、次の3つの変更が行われた。
- 単一のリリースブランチからデプロイできるようにブランチ戦略を変更
- リリースブランチでビルドした成果物もプラン・環境ごとに単一にした
- デプロイはすべてのプランおよび環境で同一の成果物を使用する
リリースブランチは単一にして、同じ成果物を各プラン環境にデプロイするように変更したのである。合わせてデプロイ用にChatOpsも開発し、ステージ環境と商用環境のデプロイタイミングが異なるのでその制御の手段として、Slackからのコマンド実行でデプロイを行えるようにした。
2つ目がCI/CDツールの置き換えである。CI/CDの実装をより柔軟に行いデプロイの効率化や処理の追加・変更を素早く行うため、CI/CDツールをCircleCIからGitHub Actionsに置き換えた。GitHub Actionsの利点としては、ソースコードをGitHub上で管理しているためGitHub上でデプロイまで完結できること、ワークフローの細分化や再利用性が良いのでコードのメンテナンスがしやすいことがある。ほかにもOpen ID Connectをサポートしているため、 GitHub側でAWSのデプロイをするときに使用するクレデンシャル情報の管理が不要になるなどがある。
ツールを変更するにあたっての難易度について川村氏は「CircleCIとGitHub Actionsのワークフローの定義が、どちらもyamlでしたので、移行の難易度はそんなに高くなかったと考えています」と話した。
こうした改善により、リリースのリードタイム短縮とデプロイ安全性向上が実現した。まだ商用リリースがされていないが、リリースのリードタイム短縮は5日から2日に短縮される見込みである。デプロイの安全性向上については改修で単一の成果物を使用するようになったため、環境ごとのビルドや環境差分を気にする必要がなくなっている。今回の取り組みで改善は終わりではない。今後はデプロイとリリースの分離やアプリケーションのインフラのコンテナ化などを行い、リリースのサイクルの高速化などを目指していく。川村氏は「それ以外にもやりたいことはいろいろ山積みの状態です」と語った。
