コラム

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

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

CTC 教育サービス

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

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

はじめに

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

ユーザーシナリオを起点とした分析

　Monarchのように、多数のコンポーネントからなるマイクロサービスのアプリケーションの場合、システムの挙動にはさまざまなパターンがあります。そのため、これらすべてをモデル図で表そうとしてもうまく行きません。図が複雑になりすぎて、分析が困難になります。そこで、Monarchの開発チームは、リファクタリングに伴う品質変化のインパクトが大きいユーザーシナリオを特定して、そのシナリオに関連するコンポーネントとその動作のみをモデル図として表現しました。具体的には、次の「時系列データの検索処理」になります。

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

　このシナリオには、一般的に言うところの「機能要件」と「非機能要件」が含まれていますが、技術的には、機能要件と非機能要件は相互に関わるもので、独立に検討しても意味がありません。そこで、この論文では、具体的なSLOとして表されるべき品質要件をQuality Attribute（品質属性）と呼び、評価対象の品質属性ごとに、「Quality attribute scenario」と呼ばれる図を作成しました。図1は、上記のユーザーシナリオに対して、実際に評価対象とした品質属性です（表内の数値はサンプルで、実際の値は非公開）。

fig01

図1 評価対象となる品質属性（論文より抜粋）

　一例として、Availability（可用性）に対するQuality attribute scenarioは、図2になります（図内の数値はサンプルで、実際の値は非公開）。

fig02

図2 Availability（可用性）に対するQuality attribute scenario（論文より抜粋）

　Quality attribute scenarioは、次の5つの要素を必ず含んでおり、評価対象の品質属性とそれに関わるシステムの動作を開発者同士で明確にコミュニケーションすることが可能になります。

Source：シナリオを開始するエンティティ
Stimulus：システムからの応答を要求するイベント
Artifacts：イベントによって稼働するシステムコンポーネント
Response：システムコンポーネントの動作内容
Response measure：システムコンポーネントの動作に対する測定可能なメトリック

ユーザーシナリオに基づいたコンポーネント図とシーケンス図

　前述のQuality attribute scenarioには、Artifacts、すなわち、このシナリオに関わるシステムコンポーネントが含まれていますが、この図だけでは、具体的な個々のコンポーネントは分かりません。これを示すのが、図3のコンポーネント図（Scenario based component diagram）になります。

fig03

図3 現行のアーキテクチャーに対応したコンポーネント図（論文より抜粋）

　ここでは、リファクタリング前の現行のアーキテクチャーに対応したコンポーネントが示されています。UML（統一モデリング言語）で定義されたいくつかのルールを取り入れており、前回の図1よりも整理された印象があります。具体的な違いとしては、図2のユーザーシナリオに関連するコンポーネントだけが示されている点と、「Provided Interface（丸印）」「Required Interface（半丸印）」により、APIを呼び出す方向が明確になっている点があります。また、それぞれのコンポーネントは、必ず、1つの箱で表現されます。負荷分散のために同じコンポーネントが複数デプロイされることもありますが、論理的には1つのコンポーネントととらえます。負荷分散によって変化するのは、該当コンポーネントの可用性や応答時間といった品質属性に関わる数値ですので、これらの数値を計算する際に考慮します。
　一方、この図の目的は、検討対象のユーザーシナリオに関わるコンポーネントを明確にすることですので、APIを呼び出す順序などの動的な情報は含まれていません。動的な情報については、図4のシーケンス図（Scenario based sequence diagram）で表します。

fig04

図4 現行のアーキテクチャーに対応したシーケンス図（論文より抜粋）

　こちらも現行のアーキテクチャーに対応した図になります。ここでは、ユーザーの検索要求に応じて、データを取得するLeafを決定する「Replica Resolution pass」と、決定されたLeafからデータを収集してユーザーに返却する「Query pass」の2つのステップに分解して表示されていますが、実際には、これらのステップは連続して実行されます。この図では、API呼び出しの順序に加えて、呼び出しの数も示されています。例えば、図4の右上の箱には「Leaf_1..m」とありますが、これは、m個のLeafに対して並列にAPIコールが行われることを示します。
　ここで、Replica Resolution passの役割について補足しておきます。Monarchでは、同じデータが複数のLeafにレプリケーションされていますが、図4の上図におけるm個のLeafは、必要なデータを保持したすべてのLeafを表します。それぞれのLeafの稼働状況（負荷）などの情報を取得して、実際にデータを取得するLeafを選択するのがReplica Resolution passです。ここで選ばれたLeafが、図4の下図に「Leaf_i..j」で示された(j-i+1)個のLeafになります。
　このシーケンス図を利用すると、APIコールのチェーンの全体像と各ステップで呼び出されるコンポーネントの数が明確になります。この情報を利用する事で、このシーケンス全体の可用性やレイテンシーを定量的に分析することが可能になります。