🎃
AppMeshアーキテクチャの可視性をリソースグラフから考える
スクラップ記事の実装補足として、グラフ分析や運用ツールの可能性を考える。
グラフ構築
LOAD CSV WITH HEADERS FROM 'file:///appmesh_data.csv' AS row
CREATE (n)
SET n = row,
n:`${row.type}`
- appmesh_data.csvヘッダ
id,type,name,label,namespace,cluster,relation_type,relation_name - type列をラベルとしてノードを作成
- その他列は全てプロパティとなる
LOAD CSV WITH HEADERS FROM 'file:///appmesh_node_backends.csv' AS row
MATCH (n {id: row.id})
WHERE row.relation_name IS NOT NULL
SET n.backends = split(row.relation_name,',')
- appmesh_node_backendsヘッダ
id,type,name,label,namespace,cluster,relation_type,relation_name - Virtual Nodeのバックエンド情報を既存ノードのプロパティとして設定する
- Virtual Nodeとバックエンドは
1:Nのため、配列として扱う
AppMeshのリソースグラフ分析
バックエンドが無いVirtual Node（メッシュ内の終端）
MATCH (n {type: "VirtualNode"})-[]-(nn)
WHERE n.backends is null
RETURN n,nn
特定エンドポイントに依存する通信経路
MATCH (n)-[r:REQUEST_TO]-(nn {type: "VirtualService"})
WHERE nn.name = "__CloudMap_FQDN__"
RETURN n,r,nn
入出力の多いノード
MATCH (n)
OPTIONAL MATCH (n)<-[in]-()
WITH n, COUNT(in) as inbound
OPTIONAL MATCH (n)-[out]->()
WITH n, inbound, COUNT(out) as outbound
WHERE n.type in ['VirtualService', 'VirtualNode']
RETURN n.name, n.type, inbound, outbound, inbound + outbound as total_path
ORDER BY total_path DESC
最後に
グラフ構造は暗黙的に理解しているアーキテクチャを答え合わせしてくれて良い、という感想。Webアプリ開発の文脈でいうと、コンテンツ管理にも適しているかもしれない。
（ボトルネックはどこか、データ構造として重要な/コスト高めのコンテンツは何か、等）
cypherクエリの学習コストは低いはずだが、現在は mcp-neo4j という選択肢もあるのでWebアプリとしてはユースケースを考えやすい。
Discussion