コラム

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

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

CTC 教育サービス

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

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

はじめに

　今回からは、2023年に公開された論文「A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google」を紹介していきます。この論文では、Monarchのアーキテクチャーをリファクタリングする際に、3種類のモデル図を用いて、新しいアーキテクチャーの品質を分析した事例が報告されています。マイクロサービスのアプリケーションを設計する際は、さまざまな図を用いた分析が行われますが、どのような図が適切なのか意見が分かれることもあります。この事例では、シンプルな3種類の図が効果的だったことが報告されており、他の開発プロジェクトの参考にもなりそうです。

Monarchの現行アーキテクチャーとその課題

　Monarchは、Google社内で利用されている、モニタリングシステム専用の時系列データストアです。Monarchのクライアントが送信したデータを多数の「Leaf」に分散保存する、マイクロサービス型のアーキテクチャーになっています。Monarchの詳細については、下記の記事が参考になります。

　これらの記事でも触れているように、2019年の段階で、Monarchは1秒間に約2.2TBのデータを収集しており、その量は継続的に増加しています。その結果、1つのゾーンに配置されるLeafの数は数万に及ぶようになり、システムの可用性と保守性の観点で課題が生じ始めたということです。可用性については、Leafの数が増えるに従って、当然ながら、ハードウェア障害などで一時的に停止するLeafの数も増えるため、「○○%（具体的な値は非公開）のクエリーに対して正常な応答を返す」というSLOを満たすことが難しくなってきました。保守性については、この後で説明するように、現行のLeafはデータ検索に関わる複数の役割を荷なっており、他のコンポーネントに比べてコードが複雑になっているということです。その結果、機能追加が容易ではなく、また、Leafに起因する障害が発生した際に、「Leaf内部のどの部分に問題があるのか」という根本原因の分析に時間がかかるという課題があります。
　これらの課題に対応するために、Leafのアーキテクチャーをリファクタリングして、機能ごとに複数のコンポーネントに分割する活動がスタートしました。

「箱と線」による説明の限界

　図1は、現行のMonarchにおける、データ検索に関わる部分のアーキテクチャーを示した図で、「Computation」「Index」「Data」の3つの役割ごとにコンポーネントが色分けされています。詳細は次回に説明しますが、Leafは、これら3つのすべての役割に関わっています。

fig01

図1 現行のMonarchにおけるデータ検索部分のアーキテクチャー（論文より抜粋）

　そして、開発チームの技術リーダーは、既存のLeafを役割ごとに「Leaf Mixer」「Leaf Index Sever」「（新しい）Leaf」の3つに分割した、図2のアーキテクチャーを提案しました。

fig02

図2 チームリーダーが提案した新しいアーキテクチャー（論文より抜粋）

　しかしながら、この提案に対して、開発チームメンバーからは懸念が表明されました。特に、これらの図だけでは技術的に不明な点が多く、新しいアーキテクチャーが必要な性能要件を満たすことが確認できないことが問題でした。問題点は、大きくは次の3つになります。
　まず、これらの図では、コンポーネント間が矢印で結ばれていますが、どの方向にどのような順番でAPIの呼び出しが行われるのかが分かりません。APIの呼び出しのチェーンが深くなると、その分だけ処理のレイテンシーは長くなります。これらの図では、リファクタリング前後でのレイテンシーの変化が十分に評価できません。
　次に、それぞれのコンポーネントの並列性が曖昧です。それぞれの図には「Leaf」と書かれた箱が3つありますが、同一の役割を持ったLeafを負荷分散のために複数デプロイしているのか、異なる役割を持ったLeafが3つあるのか判別できません。どの部分の処理がどれだけ並列化できるのかがわからなければ、性能の評価ができません。
　最後に、アプリケーションのモジュール構造が曖昧です。図2では、「Leaf」と書かれた箱の中に他の箱が描かれています。しかしながら、Leaf自体が複数のバイナリーから構成されていることを示すのか、1つのバイナリーに含まれる複数のモジュールを示しているのかが分かりません。

ユーザーシナリオを起点とした3種類の図

　前述の問題について議論した結果、これらの図は、コンポーネント間の静的な関係と、API呼び出しのチェーンという動的な関係を同時に示そうとしているために混乱を招いていることが分かりました。このような場合、教科書的には、UML（統一モデリング言語）で定義されたコンポーネント図やシーケンス図を使い分けることになりますが、UMLは複雑すぎて実際のプロジェクトでは使いづらいというのが一般的な見解です。そこで彼らは、厳密なUMLの定義にはこだわらず、性能評価が必要なユーザーシナリオを起点とした、次の3種類の図を利用することにしました。

「Quality attribute scenario」：性能評価の対象とするユーザーシナリオ
「Scenario based component diagram」：シナリオに関係したコンポーネント図
「Scenario based sequence diagram」：シナリオ実行時のシーケンス図

　これらを用いた議論により、開発チームメンバーが懸念する品質要件に対する影響を明確にすることができました。具体的な内容については、次回の記事で解説を続けます。

次回予告

　2023年に公開された論文「A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google」に基づいて、Monarchの現行アーキテクチャーの課題、そして、それをリファクタリングする際に開発チームが経験した問題を説明しました。特に、新しいアーキテクチャーの性能を正しく評価する上で必要な情報を図示して、開発チーム内で適切な議論を進めるには、上述の3種類の図が利用できることを説明しました。
　次回は、具体的な図の内容と、これらを用いた新しいアーキテクチャーの評価について解説を進めます。

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