コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第161回　簡易モデル図を用いたマイクロサービスのリファクタリング事例（パート3）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第161回　簡易モデル図を用いたマイクロサービスのリファクタリング事例（パート3） (中井悦司) 2023年10月

はじめに

前回に続いて、2023年に公開された論文「A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google」を紹介します。この論文では、Monarchのアーキテクチャーをリファクタリングする際に、3種類のモデル図を用いて、新しいアーキテクチャーの品質を分析した事例が報告されています。

リファクタリング後のアーキテクチャー

　前回の記事では、下記のユーザーシナリオを例にして、この処理に関連するコンポーネント図とシーケンス図を現行のMonarchのアーキテクチャーに対して示しました。


時系列データ検索：ユーザーは、Monarchにクエリーを送信する。システムは、複数の場所から時系列データを読み込んで、計算処理を行い、正常かつ低遅延で、結果をユーザーに送信する。

　一般的な「箱と線」による説明図とは異なり、これらの図には、品質属性の評価に必要な情報が曖昧さの無い形で示されています。具体的な評価の例はこの後で説明することにして、その前に、リファクタリング後の新しいアーキテクチャーについて、同じ図を示しておきましょう。まず、次の図1がコンポーネント図です。

fig01

図1 新しいアーキテクチャーのコンポーネント図（論文より抜粋）

　現行アーキテクチャーのLeafは、「Index」「Computation」「Data」の3つの役割を持っていましたが、新しいアーキテクチャーでは、これらの役割ごとに「Leaf Index server」「Leaf Mixer」「Leaf」の3つのコンポーネントに分割されています。「Leaf Index server」は、どのデータがどのLeafに保存されているかというデータの配置情報を持ちます。「Leaf Mixer」は複数のLeafからデータを取得して、フィルタリングやジョインなどの集計処理を行います。そして、新しいLeafは、純粋にデータを保存するだけの単純なKey-Valueストアになります。
　そして、次の図2が、これらのコンポーネントを用いた新しいシーケンス図です。

fig02

図2 新しいアーキテクチャーのシーケンス図（論文より抜粋）

　前回と同様に、データを取得するLeafを決定する「Replica Resolution pass」と、決定されたLeafからデータを収集してユーザーに返却する「Query pass」の2つのステップに分解して表示されています。Replica Resolution passについては、データの配置情報を持ったLeaf Index serverが使用されています。そして、Query passでは、Zone MixerがLeaf MixerにAPIリクエストを送信した後、Leaf Mixerが、Leaf Index serverの情報を用いて、Leafから必要なデータを取得・集計するという流れになります。

品質属性の分析例

　それでは、これらの図を用いると、どのような分析ができるのでしょうか?　論文では、可用性に関する分析例が紹介されています。前回の図4を見ると、現行のアーキテクチャーでは、1回の検索処理において、m個のLeafに対してAPIの呼び出しが行われます。これらm個のLeafのどれか1つでも停止していると、この処理全体が失敗します。従って、1つのLeafの可用性をA(L)[%]として、この処理全体における、Leafが関わる部分の可用性はA(L)^m[%]になります。
　一方、今回の図2を見ると、新しいアーキテクチャーでは、m’個のLeaf Index server、k個のLeaf Mixier、(j-i+1)個の新しいLeafが関わっており、それぞれの可用性をA(LI)、A(LM)、A(LN)として、全体の可用性は、A(LI)^m’ × A(LM)^k × A(LN)^(j-i+1) になります。ただし、Leaf Mixerはステートレスなコンポーネントなので、多数のノードで負荷分散しておけば、可用性A(LM)はほぼ100%と見なすことができます。したがって、現行と新しいアーキテクチャー、それぞれの可用性は次になります。


現行のアーキテクチャー：A1 = A(L)^m
新しいアーキテクチャー：A2 = A(LI)^m’ × A(LN)^(j-i+1)

　これらをどのように比較するかですが、まず、単体の可用性を考えると、現行Leafの一部の機能を取り出したものがLeaf Index serverと新しいLeafですので、これら単体の可用性は現行のLeafより低くなることはないでしょう。つまり、


A(LI), A(LN) ≧ A(L)

が成り立ちます。次に、現行のアーキテクチャーでは、全てのLeafにインデックス情報が分散しているのに対して、新しいアーキテクチャーでは、Leafとは独立した、専用のインデックスサーバーが用いられます。したがって、圧倒的に少数のノードにインデックス情報を集約できるはずで、


m’ << m

が成り立ちます。また、前回説明したように、必要なデータを保持したすべてのLeafがm個あって、その中から実際にデータを取得するLeafが(j-i+1)個あるという関係があるので、


j-i+1 < m

が成り立ちます。ここまでの関係をまとめると、簡単な計算で、A1 < A2、つまり、新しいアーキテクチャーの方が可用性は高くなることが分かります。この他には、API呼び出しのチェーンの長さから、レイテンシーの変化を見積もるなども可能になります。

開発者の評価

　ここまでに紹介した簡易モデル図は、Monarchのアーキテクチャーのリファクタリング活動をきっかけに生まれたものですが、Google社内の他の開発チームにも好評で、同じモデル図を利用するプロジェクトも現れ始めたということです。これらのモデル図は、正式なUMLのモデル図よりもシンプルで、専用のツールを使用せずに、Googleスライドで簡単に描けるというメリットもあります。冒頭の論文では、これらのモデル図の特徴を「following the principles of usefulness, simplicity, and non-ambiguity（有用、シンプル、曖昧さを残さない）」という言葉でまとめています。

次回予告

　2023年に公開された論文「 A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google」に基づいて、システムの品質評価に利用できる簡易モデル図の利用例を紹介しました。本文では可用性の分析例を紹介しましたが、論文内では、可用性、保守性、レイテンシー、リソース効率の観点での分析結果がまとめられています。興味のある方は、論文にも目を通してみてください。
　次回は、今回と同じくシステム設計に関わる話題で、デザインレビューのプロセスに関する論文を紹介したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡