【連載特集】エンタープライズアジャイルにおける品質担保をどう実現するか ― 第1回　アーキテクチャーの変化

　エンタープライズシステムは、クラウドの普及に伴って、システムアーキテクチャーが大きく変わりました。それは、サーバーレスとも呼ばれるマイクロサービスアーキテクチャーです。1台のサーバーマシンをコンピュータールームに設置する従来のシステムから、クラウド上の複数のコンピュータに分散し、利用頻度の変化に対して、クラウド上のリソースを柔軟に調整することができます。1台のマシンに大きなプログラムを稼働させると、数千万円もする高価なサーバーマシンを用意する必要があります。複数に分散すると、安価なマシンを稼働に応じて、マシンの数を調整します。さらに、障害時対策としても、メインマシンが停止したときに、切り替える時間が必要です。マイクロサービスアーキテクチャーでは、複数のマシンでレプリカが稼働しているため、1台のマシンが停止しても、そのままシステムを稼働し続けることが可能です。

　マイクロサービスとは、マーチン・ファウラー氏の定義したものがほぼ共通認識になっています。基本的には、小さいサービスの集まりでシステムが構成されています。また、サービスは複数のマシンに分散されます。以下に、マイクロサービスの定義を示します。※参照：MartinFowler.com Microservices

・マイクロサービスでは、1 つのアフリケーションを小さいサービスの集まりで構成する

・各サービスは、それぞれのフロセスで稼働している

・サービス間は、HTTP などの軽量なメカニスムで通信が行われる

・ここでいう「サービス」とは、ビジネスの観点で作られたものを指す

・それぞれのサービスは、自動化で独立に配置される

・サービス全体の管理は、最小限で済むようにする。つまりそれぞれのサービスは、異なったプログラミング言語やデータストレージ技術を用いて記述することも許容される

【図1.　マイクロサービスアーキテクチャー】

※「マイクロサービス入門」より引用

　従来からのすべてのモジュールをリンクしたアプリケーションをモノリシックと呼びます。図2．のように、1つのアプリケーションとして、コンパイルした機能やライブラリーにある関数をリンクしたものです。機能が多くなればなるほど、アプリケーションのサイズが大きくなり、サーバーマシンのメモリーなどのリソースが必要になります。今までは、数千万もする大きなサーバーマシンを用意して、サーバーアプリケーションを稼働していました。一方、クラウドにサーバーを置くことになると、大きな1つのマシンより、複数のマシンに処理を分散する方が、コスト的にも安価になります。

【図2.　モノリシックなアプリケーション】

※「マイクロサービス入門」より引用

　マイクロサービスでは、関数やモジュールなど実装していた機能は、サービスと呼ばれます。サービスは、クラウド上、もしくは、サーバーマシンに分散されます。これらのサービスを組み合わせて、システムとして稼働することができます。図3．のように、マイクロサービスは、Dockerなどの分散コンテナでも動作可能で、ポータビリティーも向上します。また、レプリカサービスを立ち上げておくと、ひとつのサービスがクラッシュしても、連動している同じサービスに繋ぐことができ、システムとして、停止することがないようサービスを継続することができます。そのため、マイクロサービスは、バックアップサーバーを用意する従来のシステムとは、異なると言えるでしょう。

【図3.　マイクロサービスによるシステム】

※「マイクロサービス入門」より引用

　マイクロサービスになると、サービス別に開発チームを割り当てが行われます。マイクロサービスに分割された機能の開発は、アジャイル開発が最適です。アジャイル開発は、サービスごとに、本番に配置できるだけでなく、サービスは独立しているので、呼び出し先とのインターフェースを管理していれば、サービスごとに開発、配置が可能です。

　通常、マイクロサービスの開発チームは、開発エンジニア、インフラエンジニア、テストエンジニア、品質管理担当から構成されます。専門の異なるエンジニアが共同作業で、システムを構築していきます。例えば、メルカリの事例では、メリットをスケールとして、捉えています。

※参照：メルカリのマイクロサービスアーキテクチャー採用事例

　マイクロサービスアーキテクチャーによるシステム開発では、DevOpsと統合されるため、アジャイル開発での品質管理が要求されます。すなわち、従来型の開発の結合テストや総合テストを自動化して、DevOpsのパイプラインに組み込みます。自走化することにより、常にテストされ品質管理されたソフトウェアを構築できます。さらに、本番システムに、配置する継続的なデリバリーが可能になります。

　アジャイル開発でのテストによる品質確保は、従来型の開発と同等のテストをするだけで確保できると考えておられる方も多いのではないでしょうか。たしかに、従来は、設計品質のチェックなどにより、テスト以外の品質も担保することができました。一方、アジャイルでは、ペアプログラミングやリファクタリングによって、設計品質を確保しますが、プロジェクトによっては、これらのプラクティスを実施しないこともあります。このとき、設計品質を担保できなくなってしまいます。アジャイルチームは、品質には、どのようなものがあり、どこで品質が担保されているのかを理解していなければいけません。その上で、実施するプラクティスを決めていくことが先決です。

　ゲームやネットサービスの開発では、ほぼアジャイル開発を採用しています。しかし、エンタープライズシステムでは、アジャイル開発が普及していません。それは、品質に対する対応が曖昧だからです。例えば、テスト駆動開発をして、ユニットテストだけをして、ソフトウェアを開発していても、エンタープライズシステムに要求される品質は担保できません。それでは、どのような方法で品質を担保するのか、という議論になります。この回答が現状、確立されているわけではないから、普及率が低いのです。

　第1回は、連載の導入ということで、アーキテクチャーの話を中心に、ソフトウェア品質についての考え方を説明しました。次回以降で、アジャイル開発のテストなどの品質担保のための方法を説明していきます。

全編をまとめてお読みたい方、下記より全文をダウンロードできます。