D3.js v4 の Hierarchical Edge Bundling を理解する(2)

はじめに

前回 は cluster layout で階層データを描いていました。ここから Hierarchical Edge Bundling にいく……前にこれをちょっと変えます。上下方向(水平・垂直方向)に広げて描いていた階層を円周上にレイアウトしてみたいと思います。

参考

• Radial Dendrogram - bl.ocks.org

Sample Code

サンプルコードはこれ

• d3-radial-cluster-layout.js
• d3-radial-cluster-layout.html

こういう図ができる。

変わらないところ

データの取り扱いや cluster layout で各ノードの座標を決めるところまでは同様。というか、ノードや path の描画もほぼ同じ。

変わるところ

座標系を極座標に変換している、というところがちがいます。

    var radius = Math.min(width/2, height/2);
 
    var cluster = d3.cluster().size([360, radius]);

これは、各ノードの x 座標を角度(degree)、y 座標 (root nodeからの垂直方向の距離)を半径(原点からの距離)として設定しています。

path の描画

変更しているのは d3.line() ではなく d3.radialLine() にして極座標指定で線を描いているところ。

    var line = d3.radialLine()
        .curve(d3.curveBundle.beta(0.85))
        .radius(function(d) { return d.y; })
        .angle(function(d) { return path_angle(d.x); });
    svg.selectAll("path")
        .data(links)
        .enter()
        .append("path")
        .attr("d", function(d) {
                return line([
                    d.source,
                    { "x" : d.source.x, "y" : (d.source.y + d.target.y)/2 },
                    { "x" : d.target.x, "y" : (d.source.y + d.target.y)/2 },
                    d.target
                ]);
            });

function path_angle(x) {
    return rad(x);
}

とりあえず素直に前回作ったものを変換してみた。すると上の図のようになる…。root node ("Eve") の x 座標自体が角度として設定されるので、そのまま変換するとちょっと不格好な path になる。まあ、parent node 〜 child node の path にはもともと方向性があるので、そのまま変換すると偏りが出てしまうのだな。ここはもうちょっと工夫が必要。

ノードの描画

これも極座標を直交座標に変換している。90度 (Math.PI/2) ずらしているけど、これは d3.radialLine().angle() が -y (12時) のところを起点とするため。(参照 : d3/d3-shape: Graphical primitives for visualization, such as lines and areas.)

    // circle (overwrite path)
    svg.selectAll("circle")
        .data(nodes.descendants())
        .enter()
        .append("circle")
        .attrs({
            "cx" : node_x,
            "cy" : node_y,
            "r" : node_size/2
        })
        .append("title")
        .text(function(d) { return d.data.name; });

function node_angle(x) {
    return rad(x) - Math.PI/2;
}
function node_x(d) {
    return d.y * Math.cos(node_angle(d.x));
}
function node_y(d) {
    return d.y * Math.sin(node_angle(d.x));
}

描画上のトリック

    var svg = d3.select("body")
        .append("svg")
        .attrs({"width" : width,
                "height" : height})
        .append("g")
        .attr("transform", "translate(" + width/2 + "," + height/2 + ")scale(0.8,0.8)");

円形レイアウトにしたので、座標系の原点を SVG 領域の真ん中にシフトさせています(センタリング)。縮小するのは前回と同じではみだし防止。

D3.js v4 の Hierarchical Edge Bundling を理解する(1)

はじめに

最近、某プロジェクト用の補助ツールとかを作るために D3.js - Data-Driven Documents を触ってるんですね。で、Hierarchical Edge Bundling - bl.ocks.org みたいなのを描きたいなあとおもったんですが、壁がありまして。

• そもそもこのサンプルスクリプト自体が(自分にとっては)複雑で何をやっているのかわからない…
  • もともと javascript 自体ほとんど描いたことがない状態から始めているので、ますますわからない。この辺はちょっとは勉強したつもりですが、言語仕様とかについての理解はまだ曖昧なところがあります。なので、この記事の中で使われている用語やそもそもの理解について、不適切なものがあったり誤りがあったりする可能性があります。
• D3.js v4 になったら (2016/6月) いろいろ変わったところがあって、過去のサンプルスクリプトや参考書の類いがそのままは使えない
  • v4 でのあれこれについては 細かすぎて伝わらないD3 ver.4の話 とかを参照…。

D3.js の本は2冊ほど買ってたんですけどね。サンプルコードの類いは v3 ベースなので、v4 でやろうとすると結構違うんですよね。

エンジニアのための データ可視化[実践]入門 ~D3.jsによるWebの可視化 (Software Design plus)

とかね。処理そのものは参考になるものの D3.js v4 ではどう書けばいいのかがわからない…。

ともあれ地道に試すしかない。処理の流れとしては cluster layout があって、それをさらに bundle layout で変換するというカタチらしい。まずは階層化データの取り扱いと cluster layout を理解しよう。各レイアウトの基本的なサンプルコードは svg要素の基本的な使い方まとめ を参考にしています。

Sample Code

サンプルコードはこれ

• d3-cluster-layout.js
• d3-cluster-layout.html

こういう図ができる。

データの準備

d3/d3-hierarchy にあるサンプルデータそのまま使ってまずは試してみる。

    var data = {
        "name": "Eve",
        "children": [
            { "name": "Cain" },
            {
                "name": "Seth",
                "children": [
                    { "name": "Enos" },
                    { "name": "Noam" }
                ]
            },
            { "name": "Abel" },
            {
                "name": "Awan",
                "children": [
                    { "name": "Enoch" }
                ]
            },
            { "name": "Azura" }
        ]
    };

こうした階層化されたデータを作る方法については、d3.nest() を使うとか d3.stratify() を使うとかあるみたいなんだけど、その辺はまた追々…。

階層化されたノードオブジェクトの生成

var root_node = d3.hierarchy(data);
console.log("root_node");
console.log(root_node);

大本の階層化データを変換して、階層化されたノードオブジェクトをつくる。基本的にデータ構造は同じだけど、これによって、各ノードに階層構造のメタデータ等が付随する Node オブジェクトに変換される。

• depth : root node からの深さ (root だと 0)
• height : leaf node からの高さ (leaf だと 0)
• parent : 親ノードへの参照
• children : 子ノードのリスト

このとき、元のデータの children という accessor function で子ノードの情報を参照する、というのがデフォルトになっているので注意。もし元データに children 以外の名前で子ノードの情報を持たせているのであれば、d3.hierarchy(data, function(d) { return d.foobar; }) みたいに 子ノードアクセスのための accessor function を指定してやれば良いはず。

レイアウトの設定

階層化された Node オブジェクトのデータを描画するために、特定のレイアウトでオブジェクトの位置決めをする。今回使うのは cluster layout になる。(参照 : d3/d3-hierarchy: 2D layout algorithms for visualizing hierarchical data.)

    var node_size = 20;
    var cluster = d3.cluster()
        .size([width, height]);
    var nodes = cluster(root_node);
    var links = nodes.links();

    console.log("clustered nodes");
    console.log(nodes);
    console.log("clustered nodes (leaves)");
    console.log(nodes.leaves());
    console.log("clustered nodes (ancestors)"); // from root
    console.log(nodes.ancestors());
    console.log("clustered nodes (descendants)"); // from root
    console.log(nodes.descendants());
    console.log("clustered links");
    console.log(links);

ここで描画したい大きさに基づく実際のレイアウトが決まって座標情報が付与される。

• x,y : ノードの座標(x,y)

レイアウトの描画

ノードの描画

ノードを扱うためのメソッドがいくつかあるので、それを使いつつノードやノード間の線(path)を描画していく。

• leaves : leaf になっているノードのリスト (この例だと, [Cain, Enos, Noam, Abel, Enoch, Azura])
• ancestors : (特定の Node の)親ノードのリスト (「祖先」一覧)
• descendants : (特定の Node の)子ノードのリスト (「子孫」一覧)

サンプルでは root 以下全部のノードをまとめて全部描いてる。

    // circle (overwrite path)
    svg.selectAll("circle")
        .data(nodes.descendants())
        .enter()
        .append("circle")
        .attrs({
            "cx" : function(d) { return d.x; },
            "cy" : function(d) { return d.y; },
            "r" : node_size/2
        })
        .append("title")
        .text(function(d) { return d.data.name; });

ノード間の線(path)の描画

nodes.links() で、各ノード間の path (始点・終点) 情報が取れる。

ので、これを元に線を描く。

    var line = d3.line()
        .curve(d3.curveBundle.beta(0.85))
        .x(function(d) { return d.x; })
        .y(function(d) { return d.y; });
    svg.selectAll("path")
        .data(links)
        .enter()
        .append("path")
        .attr("d", function(d) {
                return line([
                    d.source,
                    {"x" : d.source.x, "y" : (d.source.y + d.target.y)/2 },
                    {"x" : d.target.x, "y" : (d.source.y + d.target.y)/2 },
                    d.target
                ]);
            });

端点(d.source, d.target)だけだと直線になってしまうので、中間点を適当に作って曲線を描画してある。

描画上のトリック

素直に SVG の領域全体に描くと…

こうなる(はみ出す)ので、ちょっと縮小した上で "ずらす" 処理を入れてあります。

    var svg = d3.select("body")
        .append("svg")
        .attrs({"width" : width,
                "height" : height})
        .append("g")
        .attr("transform", "scale(0.8, 0.8)translate(20, 20)");

覚えておくこと

• 元データを変換していく
  • データ構造
  • 見た目のデータ

Tokyo Open Infra Users Group #15 #toiug 参加メモ

Tokyo Open Infra Users Group #15 - Tokyo Open Infra Users Group | Doorkeeper に参加してきたのでいつものメモ。ちなみに、Mesos 周りの話はあまり知識がないので間違えたことを書いてあるかもしれません…。

前フリ

Axsh 山崎さん

今日の話の概要

• 2016年度の研究開発の中のひとつ。
  • FW(Firewall)運用しているネットワークチーム。
  • 社内の人からFW変更依頼を受けて修正する
  • 管理している機械がすごく多い。変更依頼の回数もすごく多い。何回もやっているとルーチンワークでも失敗する
• 自動化?
  • 設定操作の自動化 → 設定の流し込みがはやくなるだけ。設定の流し込みでミスするのではなく、設定自体を間違えていることが問題。
  • 設定流し込みの前にテストができないか?
  • そういうシステムを検証するためのプライベートクラウドを作ろう、という提案。
• OpenVDC : WakameVDC ...より、もっとシンプルで軽量なもの。Mesos ベースの IaaS Controller
  • • シンプルだけどベーシックな機能は同じ感じ。
    • OpenVNet と組み合わせてネットワークも作れる
• 使うFWは現物にしたい。チップセットの違いとかも必要なので。
  • 物理機器を仮想ネットワークに組み込んで、現物のシステムをシミュレートして、テストしよう。
• 仮想ネットワーク…Terraformをつかう
  • テストして、確からしいというのがわかったら本番環境に入れる。
  • L2以上はエミュレート。IPアドレスとかも本番同等。
• 将来的には?
  • Azure etc, public cloudとかもくっついた本番システムを模擬できるように、仮想で作る検証環境側にも public cloud くっつけられるように。

OpenVDC Overview

Axsh ふじわらさん

OpenVDC

• IaaSのようなもの
• 目的と、現状で来ているところの話。

やりたいといわれていたこと

• テスト環境を作るためのミドルウェアがほしい。OpenStackとかでもできるだろうけど、「テスト」では作って壊すの繰り返し。ユースケースにフィットするような基盤で、かつ、難しくないやつを。
• IaaS, VM管理などが機能として挙がるけど。今回テスト対象したいのは、VMもあるけど、どちらかというと物理のNWデバイス。Ciscoとか。
  • 現状まだNWデバイスへのプロビジョニングとかはやってないけど今後は考える。
  • 現状、デモとして見せられるのは、IaaS的な動きの部分。
    • 前半は使い方中心

プロジェクト

• 2016/10月くらいから。
  • https://github.com/axsh/openvdc
  • Golang base, CIのところで shell も。

つかいかた

• 前作(WakameVDC)が機能が多すぎて使うほうも作るほうもインストールも大変だったので、可能な限り簡単にする方向。Golangを選択理由もそこから。シングルバイナリアプリが簡単に作れるので。DBもパス。
  • Mesos を使うことは決まっていた…
• 機能
  • VM操作
  • NW機器操作……Mesosベースだと厳しい
• 前作、コマンドラインパラメータがたくさん。引数として与えるときに訳が分からなくなる。引数増やすよりはリソースを定義する仕組みがあったほうがいいだろう。

一番短い使い方

• Open vdc run [template] → インスタンスID
• openvdc console [instanceid] → インスタンスへの接続
• openvdc destroy [instanceid] → インスタンスへの停止・削除

• NWのテスト、end-to-end の操作。
  • VMの中にコマンド入れてパケット受ける、

現状の実装

• openvdc help : 10個くらいのコマンド。これ以上増やす予定はあまりない。

リソース

• Template : JSON file
  • json schema を使いたかったので json, 最近のエディタが json support すごい。VSCode でテンプレート書くとき。最初にスキーマRLを入れる → いきなりそのブロックにかけるキーワードとか全部補完できるようになる。
  • オプション増やすより定義ファイルでエディタに任せる感じで。bash-completion とかやるより json に寄せたほうが、という方向。schema url がNW上にないといけないし、エディタがNWにつながらないといけないけど。
• テンプレート書いたらどこに置いておくか?
  • テンプレートリポジトリみたいなのを作ろうと。 axsh/openvdc/特定のパス以下、NW download, Git
    • Homebrew, crates.io みたいなのがネタ元。github 自体を rubygems.org みたいに使う。

いまはLXC対応だけど、将来的には qemu 対応とか

• スイッチなんかも定義ファイル結構ないとだめだろう。NW機器対応するとエントリ増えていくかも
• いまはVMしかないのでVM/フォルダのみだけど。

Commandline 書くよりは json 書くのを頑張るツール。

• schema に description かけるので、ドキュメントを充実させるともうちょっと補完動作がリッチになるはず。
  • command line + dataset でうごく
• git がちょっと難しい
  • Windows で開発。Homebrew は git 前提。Windowsでやるのが厄介。Golangのなかにgit突っ込めないかな…
• Golangで書いてるからOSは何でも動く。
  • autotest が動くのは linux only

アーキテクチャ

• Mesos
• 作っている部分は CLI
  • gRPC通信しているだけ。Mesos executor agent みたいな感じで。
  • Mesos が zookeeper 使っているので便乗してそっちにデータを核
• NW機器プロビジョニングはMesosとは別に作ってぶら下げるような想定。

主なプロセス

• openvdc (gRPC client)
• scheduler (gRPC server)
• executor

つかっているもの

• Mesos
  • 中央のDBがないスケジューラ
  • メッセージのやり取りの仕組みと各言語向けにそれを使うライブラリを提供しているだけ。
• Zookeeper にクラスタ情報だけがある。各サーバにはmesos agent, サーバの空き容量だけ監視して、Mesos master にレポートしている。Mesosの半分はnagiosみたいな動作でできている。
  • Mesos master は scheduler がぶら下がると開いている Agent にパスする。scheduler-agentでリソースほしいほしくないをネゴる。
  • Mesos user がつくるのは scheduelr
    • unix process 起動をすごい先のほうに投げて、終わったら返ってくるみたいな感じ

困ったところ

Mesos

• scheduler 作ったもののテストが難しい。meeeaging base...offerもらってジョブを投げる→executorまでとどいている、というのが全部見えないと確証が持てない。unit test レベルでやれることがあまりない。
• Agentありき → スイッチの中に入れられない。Agent 単位でしか仕事してくれない。10台マシンがあれば10エージェント必要。外部監視みたいなのもない。空きCPU/MEM/GPU みるだけ。好きなリソースを定義する、みたいなのはない。
  • いまのところ VM 割り当て処理までかな。
  • 今回のテストの話→物理NWききをどこかに引き込む。引き込んだスイッチがAgentを持っているというのではだめか?
    • 空いているかどうかを見たいのは何か : テスト対象NW機器のリソースをみて、そのリソースを使うタスクを振る(ISDNポートがあるからこれを振る、とか。任意のattribute定義するというのがあるけど融通が利かない。GPU/rack/area,... key-value, set-dataが使える程度。
• Mesos, 割り当てをする → CPU資源を有効に使う、というところにフォーカス。
  • 外部モニタリングスクリプト受け付けられればまだよかったけど…

Zookeeper

• Mesos cluster + agents の管理に zookeeper がいる
  • ジョブ管理しない
• scheduler がジョブ管理する
• Mesos は中央集権的DBはいらないけど、使う側は何らかの形でデータを管理しないといけない
  • いろんなミドルウェアをセットアップしないといけなくなる…と、大変。(Middleware Hell やめたい)
  • なので OpenVDC は zookeeper を main DB としてつかう。
• zookeeper
  • 広くは key-value store : どこまで一貫している(cojsistent)か?
    • 分散したノードがどこまで同じデータをちゃんと持つか : "Write" consistent but not "read".
    • ひとつのコネクションの間で、ひとつの key に2回書く→3回目読み込みするとどっちが読み取られるかわからない。「ひとつのコネクション」でも。
    • sync する命令がある。入れないとだめそうなのでこれから。
  • ひとつの value は

gRPC

• あまり dis るところがない
• proto buffer
  • request/response の struct map が面倒だったのでRESTful APIでなく code generation する
• RPCでこまることはない。stream, auth, intercepter(データちょっと書き換えたりしたいとか) なども。
• http2 なのでTLSで暗号化されるし。

今後

• 夏くらいまでに
  • NW機器への scheduling
• テスト → 大量にリソース持ってきて一気にリリースする。
  • Mesos はそういうのに向いてない。サーバはぜんぶ offer を非同期にやる。ひとつのサーバがあふれるようなリクエスト(大量にサーバほしい）にたいしてどう動かすか。リソースがない時に割り当てできないからテストできない、みたいなのを返すのが、Mesosの枠組みだけだと難しい。
  • bulk instance scheduling: netflix fenzo, Mesosを便利に使うライブラリ、似たようなことをやっている。
    • ステート持っちゃうんだけど…

CLAY: OpenVNet + OpenVDC + Terraform = Automatic Network Infrastructure Testing

Axsh アンドレさん

Tokyo Open Infra Users Group

• Infra, OSS, DevOps

CLAY

• いろんな技術をひとつにする
• まだプロトタイプ
  • OpenVDC の上で動くけど OpenVDC もまだプロトタイプなので。

使っているもの

• Terraform + git, jenkins, openvdc, ...

課題

• 商用NWの管理。たくさんの機器、いろいろな種類の機器。
• いろんなものがつながっているので、ひとつだけ変えてもうまくいかない。全体がうまく動かないといけない。
  • downtime, security risk, long time to debug...
• ソフトウェアに似ている
  • CI
  • plan → code → build → test → deploy →
    • code から先は自動で動かす。
    • test は商用環境のコピーでやる。ソフトウェアだと簡単。
    • OpenVDCはそれ自体もCIしている。

商用環境のコピーはテストのために必要になる。

• そこで OpenVNetをつかう
  • SDN → "ちょっと嘘をつくこと"　→ 何かのふりをする

CLAY

• https://github.com/qb0C80aE/clay
• Golang
  • GUI がある (pottery) (REST API)
  • 赤アイコンは仮想/青アイコンは物理 : 物理NWと仮想NWをつなぐ
  • dialogue generate
  • testcase generate
• 物理デバイスも仮想ネットワークにつなげてつかう
  • 全部の物理NWを仮想で再現できるわけじゃない。
  • 今回は Juniper SSG : 仮想版はない。テスト環境用にこれは買うしかない。ただしほかのデバイスはシミュレートする。

技術

• OpenVDC, OpenVNet : 仮想リソースの操作 + 接続
• terraform + git : コード化・コード管理

Architecture

• Clay は rest api を提供。
  • GUI(pottery) 経由でapi発行 (あるいはコード書いて直接API)
• terraform
  • インフラをコード化する
• cray は terraform code + testcase code を生成して git reops にいれる
  • → jenkins : git polling して変更されたソースをチェック → 自動で terraform apply してテストを実行する
• terraform → openVNet + OpenVDC で環境を作る
  • サーバに物理NICたくさんつけて物理NW機器をつけて引き込み

…という技術の組み合わせのことを "Liquid Metal" と呼んでいる

• • Metal が好きだから!
  • いろんな形になる

デモ

• Pottely ( https://github.com/qb0C80aE/pottery )
  • テストしたいNWのデザイン
  • Physical DIagram : 物理FW + 仮想L2SW/VM
• 商用環境でのFW管理がこまってる
  • Kompilla が複数のノードを telnet でまたいで設定を変える
  • 別な tftp server からイメージ持ってきて再起動する
• OpenVDC
  • CLIだけじゃなくて terraform plugin も作っててそっちを使ってる

この先の話。

• devops : operator には CI がない。
  • git にコード書いて同じプロセスに参加させたい。手順書→レビュー→本番で動かない。これをかえる。テストを書いて動いたら本番環境に入れる流れに。
• 一緒にプロトタイプ開発、検証してくれる人を募集中です!

コメント

ネットワークのテスト、特に物理ハードウェアをターゲットにしたネットワークのテスト、という点では GitHub - net-tester/net-tester: Acceptance test tool for physical networks と同じ課題感・目的ですね。ただ実行のアプローチがちょっと違うか。個人的には OpenVDC/OpenVNet を使った方法はテスト環境そのものの形式的な定義・テストケース生成などを志向しているイメージかな。NetTester は「受け入れテスト」としてどういうやり方ができるかという方向。あと物理構成(物理リンク)操作するしないとかターゲットにしている「物理ネットワーク」に対する考え方がちょっと違うか。NetTester はNW構成はもう全部物理的に作ってある方向で、end-to-end でテストトラフィックを吐くノードだけ用意仕様みたいな感じかな。OpenVDC/VNet はテスト対象の物理NW機器が一部あってあとは定義に基づいてネットワーク自体も仮想的に組み上げる感じかな。

どちらも最終的には、CI/CDとか「ネットワークの運用・開発のプロセス」というところに向かうと思われる。そこでどういう課題が出てどんなやり方ができるのか、というところが気になるところですね。「物理NW機器」を使う以上インスタンスが簡単に生成できないとかいろんな制限があるので、そこら辺が課題になりそうです。