PR

マイクロサービスを導入すれば、システムの変更速度を上げることができる。サービスを疎結合につなぐことで、機能変更に伴う各種調整が不要になるからだ。ただし導入の前提として、データ一貫性を始めとする制約を押さえておく必要がある。

 マイクロサービスアーキテクチャーが注目を浴びています。本連載では、段階的にマイクロサービスを導入していくための設計手法を解説します。第1回は、改めてマイクロサービスとは何かを掘り下げ、システムに与える影響を説明します。特にエンタープライズシステムの場合、マイクロサービスの導入には強い制約があるため、その点を理解しておく必要があります。

変更時間の多くは調整時間

 システム開発において大きなテーマの1つは「システムの変更速度を上げる」ことです。近年、このテーマに対して主に技術面からの取り組みが進んでおり、それらが総称としてマイクロサービスと呼ばれています。まずはマイクロサービスが、この問題をどのように解決できるのか整理します。

 システムの変更速度に大きな影響を与えるのは、対象となる機能の変更作業そのものではありません。その作業によって引き起こされる機能間にまたがった調整であり、大きく3点が挙げられます。

 1つは影響調査です。ある機能の挙動を変更する際に、その変更が他機能にどのような影響を及ぼすかを確認する必要があります。例えば、A機能の仕様変更に伴い、ある関数が変更される場合、その関数を利用している全てのロジックを調査し、それらを利用している機能に影響がないことを確認する必要があります。仮に影響があると分かれば、その機能に対しても修正作業が必要になります(図1)。

図1●変更に伴う影響調査に時間がかかる
図1●変更に伴う影響調査に時間がかかる
[画像のクリックで拡大表示]

 もう1つはリグレッション(回帰)テストです。1点目に挙げた影響調査に抜けもれがないことを確認する必要があります。そこで変更した機能に対するテストを実施するだけではなく、関係する機能、あるいは網羅的に全機能に対して「動作が変更されていないこと」を確認するテストを行う必要があります。リグレッションテストでは、正常動作を確認するためのテストケースを実施します。

 また、リリース調整の時間も考慮に入れる必要があります。同時に複数の機能に対して変更を行い、それらを同時にリリースする場合、最も変更に時間がかかる機能にリリース日を合わせる必要があります。

 このように、ある機能を変更する場合に費やされる時間には、純粋にその機能を変更してテストする作業だけではなく、他機能への影響調査、あるいは影響がないことを確認するテストを含めなければなりません。また同時リリースを考慮すれば、一番時間がかかる機能が作業完了するまで待つ必要もあるのです。

この記事は有料会員限定です

「日経SYSTEMS」定期購読者もログインしてお読みいただけます。

日経クロステック有料会員になると…

専門雑誌8誌の記事が読み放題
注目テーマのデジタルムックが読める
雑誌PDFを月100pダウンロード

日経電子版セット今なら2カ月無料