Distributed Architecture Reconstruction of Polyglot and Multi-Repository Microservice Projects
本論文は、モジュール化された技術固有のエクストラクターを利用することで、ポリグロットかつマルチリポジトリのマイクロサービス・プロジェクトに対してデータを統合し正確なドキュメントを生成することにより、既存の制限を克服する分散型静的アーキテクチャ再構成のための新しいフレームワークを提案するものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
想像してみてください。そこには、何百もの小さな、独立した近隣地域からなる、巨大で賑やかな都市があります。それぞれの近隣地域（マイクロサービス）は、異なるチームによって構築され、異なる素材（プログラミング言語）を使用し、それぞれ独自のスタイルに従っています。ある場所はレンガ（Java）でできており、ある場所は木材（Python）で、またある場所はガラス（Go）でできています。
問題は、誰もこの都市の完全な地図を持っていないことです。元の設計図は紛失しているか、古くなっているか、あるいは元の建築家しか理解できない言語で書かれています。これらの近隣地域は非常に速いスピードで変化し、個別に構築されているため、一度に都市全体の巨大な地図を描こうとするのは悪夢のような作業です。都市全体を一度に見ようとすると、交通渋滞に陥りますし、一つの近隣地域が変化するたびに、地図全体を引き直さなければならなくなります。
この論文は、この問題を解決するための新しいツール「ModARO」を紹介しています。その仕組みを、簡単な比喩を用いて説明します。
1. 「専門のスカウト」（抽出器 / Extractors）
あらゆる種類の建築素材を理解できる一つの巨大で超知能なロボットを雇う代わりに、著者たちは「抽出器（Extractors）」と呼ばれる専門のスカウトのチームを作り上げました。
- 仕組み: 各スカウトは、たった一つのことの専門家です。あるスカウトは「Java」の設計図を読むことだけを知っています。別のスカウトは「Docker」コンテナのことだけを知っています。また別のスカウトは「YAML」設定ファイルのことだけを知っています。
- 魔法: JavaのスカウトにPythonの読み方を教える必要はありません。ただ、JavaのスカウトをJavaの近隣地域に送り込むだけです。彼らは周囲を見渡し、重要な詳細を見つけ出し、それを標準化されたメモ帳に書き留めます。
- 記憶を持たない: これらのスカウトは「記憶喪失」です。彼らは前の近隣地域で見たことを覚えていません。目の前にある特定の建物だけを見ます。これにより、彼らは高速に動作し、混乱することもありません。
2. 「共通のメモ帳」（モデル / The Model）
スカウトが仕事を終えると、彼らはメモを自分たちだけで持ち続けることはしません。彼らは調査結果を共通のメモ帳（JSONモデル）に書き込みます。
- このメモ帳には、全員が合意した特定のフォーマットがあります。
- もしJavaのスカウトが「ドア」（APIエンドポイント）を見つけたら、それを書き留めます。もしPythonのスカウトが「窓」（データベース接続）を見つけたら、それも書き留めます。
- 全員が同じメモ帳のフォーマットを使用しているため、Javaの近隣地域の情報とPythonの近隣地域の情報を、最終的に結合させることができます。
3. 「オーケストレーター」（アルゴリズム / The Orchestrator）
スカウトを管理する指揮者（再構成アルゴリズム）が存在します。
- 指揮者は、「よし、この建物を調べよう」と言います。
- Javaのスカウトがそれをチェックし、メモを追加します。
- 指揮者は、新しいメモが追加されたのを見て、「ああ、ここにJavaのファイルがあることが分かったので、次はDockerのスカウトを呼んで、コンテナがあるかどうかを確認させよう」と判断します。
- これが、新しい情報が見つからなくなるまでループの中で繰り返されます。指揮者は、もし二人のスカウトが同じ行に矛盾する内容を書き込もうとした場合、システムが混乱して地図がめちゃくちゃにならないよう、システムを停止させてフラグ（エラー）を立て、人間が修正できるようにします。
4. 「分散型マップ」（マルチリポジトリ再構成 / Distributed Map）
これがこの論文の最大の革新です。かつて、地図を描くためには、すべての近隣地域からすべての設計図を集めて、一つの巨大な部屋に集め、それらをすべて一緒に見なければなりませんでした。これは遅く、都市の「独立した」精神を損なうものでした。
新しいアプローチは分散型です：
- 独立した作業: 各近隣地域は、自分たちの家を建てたり更新したりしている間に、自分自身の「ミニマップ」を描きます。彼らは他の近隣地域が終わるのを待つ必要はありません。
- 組み立て: 後で、これらのミニマップが持ち込まれ、LEGOブロックのようにカチッと組み合わされます。
- 「ゴースト」の接続: 時として、ある近隣地域が「『Test-Service』という場所にメールを送る」と言うことがあります。彼らは、それがまだ別の近隣地域にあるため、その正確な住所やIDをまだ知りません。システムは、「『Test-Service』という名前の『誰か』にメールを送る」と記述することを許可します。すべてのミニマップが組み合わされたとき、システムは自動的にドットを繋ぎ、「Test-Service」の送信側と「Test-Service」の受信側を一致させます。
なぜこれが優れているのか？
- 「一律の解決策」は不要: あらゆるプログラミング言語を一度に理解しようとする、複雑で壊れやすいシステムを作る必要はありません。新しい言語が現れるたびに、新しいスカウト（抽出器）を追加するだけで済みます。
- スピード: 各近隣地域が独自のマップを作成するため、都市全体を止めることなく、一つのサービスのマップを更新できます。
- 柔軟性: 既存のツールを利用できます。もし既にJavaコードを分析するツールを持っているなら、それを「スカウト」のスーツで包むだけで、チームに加えることができます。
要約すると、この論文は、小さく専門化されたチームが、複雑なシステムの一部を独立して文書化し、その後、それらの断片を自動的に縫い合わせて、全体のアーキテクチャの完全で正確な姿を作り上げる、そのようなシステムを構築しています。しかも、作業中に他の部分についてのすべてを知っておく必要はありません。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。