モノリスからマイクロサービスへの移行

こんにちは。モビルスで MOBI VOICE のバックエンドを担当している村中です。

５月にマイクロサービス関連のワークショップに出席しましたので、モノリスからマイクロサービスへの移行について書いてみたいと思います。なお、出席しましたワークショップの内容そのままではなく、私の理解となりますのでご了承ください。

なぜマイクロサービス化するのか

企業は成長するためにより良いサービスを速く提供し競争力を高めていく必要があります。このことを実現する開発手法の一つとして DevOps があります。DevOps では開発チームと運用チームが協力・連携することにより品質を担保しつつ高い頻度でリリースを行えることを目指します。DevOps の成熟度とパフォーマンスを評価するための指標として DevOps Research and Assessment(DORA)があります。ソフトウェアアーキテクチャをマイクロサービス化することにより DORA のパフォーマンスを改善できると言われています。

「Google Cloud で実行されている DevOps 組織の有効性を評価する」
Google Cloud ブログより引用
https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-according-to-dora

モノリスの課題

マイクロサービスと比較されるソフトウェアアーキテクチャにモノリスがあります。モノリスはすべてが 1 つにまとまっているシステムです。１つにまとまっているため、デプロイによる影響範囲が大きくリリースまでに時間がかかってしまいます。

また、特定機能のみスケーリングすることができないです。なお、モノリスがよくない設計という訳ではなくソフトウェアの規模などによりモノリスが適していることもあります。内部構造として分割しているが、敢えて 1 つにまとめているモジュラーモノリスというものもあります。

マイクロサービスの利点

マイクロサービスとはサービスという単位に分割し、ネットワークを介し各サービス間でデータのやりとりをし１つのシステムを実現するものです。モノリスに比べサービスで分かれていることにより個々のコード量が少なくなり理解しやすくなります。サービス単位でのリリースが可能で、サービスごとにスケーラブルです。

なお、サービスごとにデータストアを持つためサービスを跨ぐ処理の場合に最終的にデータの一貫性を補償する結果整合性を担保することになります。また、サービス間で通信を行うためモノリスに比べ複雑になります。

マイクロサービスが適さないケース

マイクロサービスにデメリットがあるようにマイクロサービスが適さないケースもあります。以下はマイクロサービスが適さないケースの例です。

• マイクロサービス化によりコストが見合わない場合
• データに強い一貫性が必要な場合　
• ドメインが単純な場合　
• マイクロサービスにする理由がない場合

マイクロサービス化に向けたチーム設計

コンウェイの法則というものがあり、組織の構造がシステムの構造に反映されると言われています。システムをマイクロサービス化しても組織がサービスごとに分かれていない場合はサービスが疎結合とならず、期待したパフォーマンスを得られない可能性があります。そのため、マイクロサービス化を行うには組織の見直しも必要になります。

マイクロサービスへの分割方法

モノリスからマイクロサービスへ移行するにあたり、サービスへの分割が必要になります。サービスの分割には以下のようなアプローチがあります。

• 主要機能ごとにサービスに分割する
• ドメイン駆動設計の境界づけられたコンテキストを特定しサービスに分割する　
• Peeling the onion(実装から徐々にサービスに分割を進める)

マイクロサービスへの移行方法

モノリスをいきなりマイクロサービスに置き換えてしまうと予期せぬ障害の発生などリスクがあります。そのため、ストラングラーパターンを適用するなどし徐々に移行することでリスクを軽減させます。ストラングラーパターンでは、既存のモノリスを徐々にマイクロサービスへの分割を進め最終的にマイクロサービスに置き換えます。

まとめ

簡単にですがモノリスからマイクロサービスの移行について書きました。マイクロサービスについては多くの書籍があり、今回の記事では概要の紹介ぐらいしか書けていないと思いますが何かのお役に立てれば幸いです。

私が担当している MOBI VOICE はご利用くださるお客様の増加に伴い最適なスケーリングが行えるよう構成の見直しを行うこともあります。現状マイクロサービスでなくマイクロサービス化という話も今のところないですが、リスクを軽減させて移行させるなどマイクロサービス以外でも役立つ考え方があるのではと思っています。

モビルスでは、一緒に働く仲間を募集中です！

興味のある方は、ぜひ採用情報のページをご覧ください！

プロダクト・エンジニアリングLT会 第6回

モビルスでは、開発部門合同で毎月「プロダクト・エンジニアリングLT会」という全員で自由討論をする会を開催しています。先月6月29日に開催した第6回の様子をお届けします！

今回、LT会に参加された方々の発表タイトルは以下の通りです。

1.製品クオリティを上げる〜ランチでリフレッシュ編〜

　QA（品質保証）の仕事は、ソフトウェアや製品の品質を確保するために様々な活動を行うことです。しかし「品質確保は開発アウトプットの検証だけがその方法であるのか？」といった違った目線からアプローチと方法の提案がありました。

2.PoCプロジェクトの成果共有

    ある顧客のオフライン窓口においてモビルス製品を利用した顧客対応のPoCを実施しました。その内容と成果の共有を行いました。

3.モノリスからマイクロサービスへの移行

   開発者が外部セミナーから得た情報を自分なりに咀嚼してその内容を全員に紹介しました。後日別記事で紹介します。

4.MOBIBOTを使えるようにしよう〜MOBIBOTの仕組み編〜

   MOBIBOTをより使いこなすため、BOT開発担当者から仕組みから説明を行いました。

LT会の様子

日々の業務を俯瞰して、新しい提案をされている方も。

ユーザーの声や、製品が使われている現場の様子をシェア

「モノリスからマイクロサービスへの移行」詳細記事をお楽しみに！

全体を通じて「こんな機能あったらよいかも！」や「この場合はどうなるの？」
といった意見や質問が多く出ていました＾＾

モビルスでは、一緒に働く仲間を募集中です！

興味のある方は、ぜひ採用情報のページをご覧ください！

MOBI VOICEで使用している技術紹介

3回目に”書く”担当になったVoice-Tech Product Divisionの三谷智信です。

 

今回は私の担当サービス「MOBI VOICE」を例に、使われている技術やアーキテクチャを紹介したいと思います。

 

MOBI VOICEはざっくり以下のような技術を使用して作られています。

• サーバサイド言語：Go
• フロントサイド言語：React, TypeScript
• データベース：MongoDB, DynamoDB
• インフラ関連（AWS）：ECS, Lambda, S3, SES, CodeDeploy, CloudFormationなど
• その他：Asterisk, Docker, CircleCI, 各種SaaSなど

 

MOBI VOICEは2019年10月にリリースされました。

私はそのリリースの時期にはモビルスに入社していたものの、プロトタイプの段階ではその開発チームに参加しておらず、ある程度基本的な部分が出来て製品化するという段階から任された形になります。

その時は、サーバサイド言語、フロントサイド言語、データベースはすでに決まっていました。

 

当時のモビルスは比較的開発者が自由に言語選定をしており、当時勢いのあったGoを他製品の一部Lambdaで使ったことを皮切りに、製品のサーバサイド言語で使うようになったようです。

Goは比較的実行速度が早いと言われており、静的型付け言語のため、メンテナンスもしやすく、また、電話サービスという特性上会話を続けながら他の処理を並行に走らせることが多いため、並行処理に強いという点がメリットになっています。

なかなかGoを実務で触ってきたという開発者を見つけるのは大変なので、新たにメンバーとして参画してもらう時にはイチから勉強し、徐々に慣れてもらうようにしています。

 

データベースのMongoDBは、モビルスの主力製品であるMOBI AGENTがチャットサービスのため、テキストデータのIn-Outが頻繁に行われるという理由で既に採用されており、それに則った形でMOBI VOICEでも選定されました。

複数サービスを運用する上でもデータベースを統一することはメリットがあり、マネージドサービスのMongoDB Atlasを使い、サービス横断で監視やメンテナンスを行なっています。

MongoDBはスキーマレスのため、サービス開発・運営していく中で頻繁に発生する仕様変更に柔軟に対応できるのが良いところです。MongoDBでもトランザクションが使用できるようになったとはいえ、RDBMSの時とはデータの整合性や持ち方で考え方を変える必要があるので注意が必要です。

Go同様にMongoDBを実務で触ってきたという開発者を見つけるのはなかなか大変なので、新たにメンバーとして参画してもらう時は勉強しつつ徐々に慣れてもらうことが多いです。RDBMSしか触ってこなかった人はここにギャップを感じる人が多いようです。

 

モビルスはインフラはほぼ全てAWSで構成されております。

他製品ではEC2でサーバを立てて各種ミドルウェア等準備してサービスを立ち上げることもあるのですが、MOBI VOICEではECS Fargateを採用しています。

Dockerコンテナで各種ミドルウェア等を管理し、リソースはちょっとした設定とタスク定義の変更で管理できるため、柔軟な運用が可能です。また、オートスケール設定によって急なリクエスト増加にもある程度対応できます。

ちょっと反則的ではありますが、MOBI VOICEでは同じコードをECSのタスク定義を変えることによりシステム内での役割を変えるようなこともしています。これがリソース分散になかなか役立っております。

 

ここまでざっくりとMOBI VOICEの使っている技術の紹介をしてきました。

もっと細かいところの話もしたいのですが、それはいつかこのTech Blogで続きを書きたいと思います。

 

これら技術に興味のある方、モビルスでは一緒に働く仲間を募集しています。

興味のある方は、ぜひ採用情報のページをご覧ください。

 

プロダクト・エンジニアリングLT会 第5回

「プロダクト・エンジニアリングLT会」

モビルスでは、開発部門合同で毎月「プロダクト・エンジニアリングLT会」を開催しています。先月5月18日に開催した第5回の様子をお届けします！

発表タイトル一覧

今回、LT会に参加された方々の発表タイトルは以下の通りです。

1. CSSのline-heightの話
2. 【本日の豆】Backlog キーワード検索
3. SecurePathの今までの開発について
4. さいきんやっているプロジェクト
5. ローカル環境で解決したこと(Apple Siliconでdockerについて)
6. 便利だと思ってたサービス(AWS Config)
7. 読んで面白いと思ったtechニュース

LT会の様子

デザイナーも発表します＾＾

若きエンジニアも発表します（ ´艸｀)

先輩エンジニアもカッコイイ！ヽ(^o^)丿

モビルスでは、一緒に働く仲間を募集中です！

興味のある方は、ぜひ採用情報のページをご覧ください！

モビルスTech Blog 始めます！

ご挨拶

はじめまして！テックブログの記念すべき初回の投稿を担当することになった今井と申します。メッセージングテックプロダクトディビジョンのマネージャーを務めています。

この場を借りて、弊社のテックブログについて紹介させてください。このブログは、我々の製品開発チームが日々直面する挑戦や、それらの課題をどのように解決したのか、また使用している技術やツールの紹介、さらにはシステム開発に役立つTipsなどを皆さんに共有するための場です。

それらを我々エンジニアやデザイナーが気軽に紹介し、皆さんと共有できると嬉しいです。私たちエンジニアチームがどのように頑張っているのかを、皆さんに少しでも感じて頂ければ嬉しいです。

初回は、技術的な話題というより、製品開発の進め方やその過程で感じる課題について少しお話しすることにします。まずは私たちの会社である「モビルス」について紹介させてください。

新オフィスでの撮影Spotにて

「モビルス」とは？

私たちの会社は2011年に設立され、今年で12年目になります。SaaS事業を始めてからもうすぐ7年が経ち、現在では6つのプロダクトまで手がけるようになりました。

私たちのSaaSプロダクトは、常に時流を読み、顧客ニーズや市場状況に応じて進化してきました。これまではカスタマーサクセスチームからの顧客要望やセールスチームからのアイディア、そして開発チームからのリファクタリング要求など、さまざまな声を基にロードマップを作成し、各プロダクトの開発チームがそれに沿って開発を進めてきました。

現在の課題

会社の規模がまだ小さかった頃は、「この機能を追加すればお客様に喜ばれるだろうか？」といった考えや、お客様の要望から着想を得た機能改善を、小さなチームで素早く行ってきました。その頃は、新機能の追加や改善がスピーディーに求められていたため、文書化をあまり行わず、迅速に開発を進めていたという話をよく聞きます。

しかし、今となっては機能の数も大幅に増えてきており、特に最初にリリースしたモビエージェントに至っては、機能数が大量になりました。新機能を追加したり、既存の機能を改修する際には、それに伴って数多くの既存機能を修正する必要が出てきています。それに伴ってテストケースも増加しています。古参のエンジニアならまだしも、新たに入社したエンジニアにとっては、システムが分かりにくく複雑になってしまっています。

現在は、開発すべきタスクを分解し、それを各エンジニアが担当して開発を進めるという方法を採用しています。これまでは各エンジニアがそれぞれ独自の知識を持っていたため、この方法でも大きな問題はありませんでした。しかし、製品の規模が大きくなるにつれて、自分が担当していない部分については理解が追いつかないという問題が出てきています。

クイックミーティングでささっと共有。”立ちっぱ”ではないです(笑)

これから目指していく姿

これからの製品開発においては、個々のエンジニアの知識に頼るのではなく、開発チーム全体で問題に取り組む方法が求められています。新しいエンジニアもどんどん入社しており、これからの更なる機能追加や改善には、チーム全体の力が必要になっています。

私たちは、個々人の力ではなく、チーム全体の力で最大のパフォーマンスを出すことを目指しています。そのためには、様々な方向からの要求をどのように整理し、分析し、それらをどの順番でどのように開発に反映させるか、ということを改めて考える必要があると感じています。そして、その課題にどのように取り組んだのか、その結果どうなったのかを、このテックブログを通じて皆さんにお伝えしていきたいと思っています。

今回の初回投稿では、私たちの製品開発チームが直面している現状や課題について主に触れさせていただきました。次回以降の投稿では、これらの課題に各製品チームがどのように取り組んでいるか、さらにはより具体的な技術的な話題にも触れていきたいと思っています。

これからの投稿を楽しみにしていていただければ幸いです！

モビルスでは、一緒に働く仲間を募集中です！

興味のある方は、ぜひ採用情報のページをご覧ください！