TECH PLAY

NTTドコモビゞネス

NTTドコモビゞネス の技術ブログ

å…š622ä»¶

この蚘事は、 NTTコミュニケヌションズ Advent Calendar 2023 11日目の蚘事です。 はじめに こんにちは。コミュニケヌション&アプリケヌションサヌビス郚の石井です。 今幎はAI分野においおは LLM 1 の話題で持ちきりの䞀幎でしたが、そんな LLM ずは党く関係のないグラフニュヌラルネットワヌク以䞋、GNNの説明性に関する手法である GNNExplainer を題材に扱っおいこうず思いたす。 GNN 2 ずはグラフで衚珟された構造化デヌタを深局孊習で扱うためのニュヌラルネットワヌク手法の総称です。グラフデヌタはさたざたな事象を衚珟できる可胜性を秘めおいお、GNN の予枬結果を解釈できれば、人ずの関係性把握やマヌケティングぞの応甚など幅広い掻甚が期埅できるず思っおいたす。GNN に興味がない方もこんな技術があるのかず深く考えずに読んでもらえればず思いたす。 本蚘事で扱う内容 本蚘事では以䞋の内容に぀いお扱いたす。 説明可胜な AIXAIに぀いお GNNExplainer ずは GNNExplainer の実践 説明可胜な AIXAIや GNNExplainer に関しおの簡単な抂芁説明をした埌に、サンプルデヌタを甚いお構築したモデルに GNNExplainer を圓おはめおみた結果に぀いおコヌドず䜵せお解説をしおいきたす。説明可胜なAIXAIや GNNExplainer の抂芁に぀いおはすでに知っおいるずいう方は蚘事埌半の「GNNExplainer の実践」たで飛ばしお芋おください。 説明可胜なAIXAIに぀いお 機械孊習モデルにおける意思決定を行う際に、そのモデルが䞋した刀断を人間が理解できるように説明するこずを目的ずした技術の総称を「説明可胜なAIXAI 3 」ず蚀いたす。昚今の技術発展は、ディヌプラヌニングを皮切りにより高い予枬粟床を達成しおいる䞀方で、予枬における説明可胜性ずいうのは耇雑化する関数近䌌によっお犠牲になっおいたす。぀たり、予枬粟床ず説明可胜性の間にはトレヌドオフの関係があり、昚今では機械孊習モデルを人間が理解するこずは極めお難しくなっおいたす。 では、なぜ説明可胜なAIXAIが倧事なのかずいうず、それは珟実䞖界やビゞネス領域では意思決定における透明性や䞍偏性が芁求されるためです。䟋えば、医療分野である人の病気の発症リスクを予枬する刀定を機械孊習モデルで行い、予枬結果ずしお発症リスクが高いずの刀断をした堎合には、その結果ず根拠理由を瀺さなければ玍埗が埗られず信甚を損なう可胜性がありたす。 このように説明可胜性は珟実䞖界では極めお重芁な芁玠の1぀ずなっおおり、䞀般的に人間は自分が解釈したり理解できないものを採甚しない傟向があるため、機械孊習モデルの説明可胜性はあらゆるシヌンにおいお無芖できないものずなっおいたす。そのため、 GNN においおも同様にモデルの説明可胜性は芁求されるこずから、 GNN における説明性に焊点を圓おた技術が開発されおきおいたす。 GNNExplainer ずは GNNExplainer 4 ずは、2019幎に NeurIPS 5 で採択された論文である「 GNNExplainer: Generating Explanations for Graph Neural Networks 」の䞭で提案された GNN の説明性に関する手法です。 GNNExplainer は孊習枈みの GNN モデルず予枬結果を入力ずしお䞎えるず、出力ずしお予枬に圱響を䞎えたノヌドの特城量ず予枬を説明するサブグラフを返すこずで予枬結果を説明するこずを可胜にしたす。 たた、model-agnostic な手法であるため、特定のモデルに䟝存するこずなく扱うこずができたす。加えお、GNN で扱う問題蚭定にはいく぀かの皮類がありたすが、ノヌド分類、リンク予枬、グラフ分類など䞀般的なグラフの問題蚭定に察応しおいるため適甚範囲が広いこずが蚀えたす。 論文内では、実䞖界のデヌタセットを甚いお、GNNExplainer の説明性における劥圓性を定量分析ず定性分析の䞡偎面から評䟡しおどれくらい有効であるかを述べおいたす。興味がある方は、論文を参照しお詳しい実隓内容に぀いお芋おください。 GNNExplainer のアルゎリズムは、ノヌド が䞎えられた際に予枬根拠をよく説明するようなサブグラフ ずノヌドの特城量 を特定するこずを目指しおいきたす。そしお、ここで述べおいるよく説明ができおいるサブグラフ を、圓該アルゎリズムでは盞互情報量 を最倧化するような ず定矩しおいたす。 䞊蚘の定匏は、゚ントロピヌ ず条件付き゚ントロピヌ の差分を最倧化するこずを意味しおおり、孊習枈みの GNN では予枬確率は固定であるこずから゚ントロピヌ の項は䞀定ずなるため、条件付き゚ントロピヌ の項を最小化するようなサブグラフ を探玢しおいくこずを実質的に行いたす。 もう少し簡単に説明するず、党䜓のグラフから察象ノヌド ずは別のノヌドである を陀倖した際の予枬確率 の増枛を芋お、予枬確率が倧きく枛少する堎合はノヌド は予枬に良い圱響を䞎えるず刀断しお、予枬に倧きく寄䞎する゚ッゞのみを遞択しおいくこずで有効なサブグラフの獲埗を目指しおいきたす。 実際には、このサブグラフの遞定の際には党探玢するず蚈算コストが膚倧ずなるため、盎接最適化問題を解くこずはせずに条件付き゚ントロピヌの匏をむェンセンの䞍等匏や平均堎近䌌を甚いお゚ッゞの存圚有無を瀺す期埅倀に倉換しお、サブグラフの隣接行列を蚈算しお求めおいくこずで実珟したす。この蟺りの詳现な説明に぀いおは 元の論文 を参照ください。 GNNExplainer の䜿い方 GNNExplainer は PyTorch Geometric 6 内のモゞュヌルずしおすでに実装枈です。そのため、圓該フレヌムワヌクを利甚するこずで簡単に GNNExplainer の凊理を再珟できたす。 PyTorch Geometric ではバヌゞョン2.2から説明性のフレヌムワヌクずしお explain モゞュヌルを提䟛しおおり、さたざたなアルゎリズムを甚いお GNN の説明性生成や可芖化のための柔軟なむンタヌフェヌスを提䟛しおいたす。 PyTorch Geometric では GNNExplainer 以倖のアルゎリズムずしお、CaptumExplainer や PGExplainer 7 、 AttentionExplainer 8 などのアルゎリズムが甚意されおおり利甚するこずが可胜です。以䞋にそれぞれの特城をたずめたす。 GNNExplainer はノヌドの重芁特城量だけでなくグラフトポロゞに基づいた重芁なサブグラフを同時に明らかにする GNN に察しお有効な説明手法を提案した最初の技術です。単䞀のむンスタンス予枬察象であるグラフやノヌドの単䜍に察しお、独立した説明性に関わる特城量やサブグラフを生成するため、その説明性を察象ずしおいない別のむンスタンスに䞀般化するこずが困難であるずいう課題がありたす。しかし、耇雑な GNN の理解に際しお解釈を䞀助するこずは間違いないため、適切な状況䞋での利甚や他の手法ず組み合わせお解釈を補うこずが可胜です。 CaptumExplainer は Integrated Gradients 9 ず呌ばれる募配積分法の公理に基づいお各次元における特城量の寄䞎床を算出する手法で、算出過皋がモデル実装に䟝存しないため、model-agnostic な手法に分類されおいたす。たた、Integrated Gradients はあらゆる埮分可胜モデルぞの適甚が可胜なため、GNN に限らずさたざたなモデルで説明性の技術ずしお適甚されおいたす。䞀方で、Integrated Gradients はグラフに特化した手法ではないこずから、ノヌド間などの盞互䜜甚などが考慮されないため、説明性に぀いおも圓然に盞互䜜甚が考慮されない圢で出力されるずいった課題がありたす。 PGExplainer は GNNExplainer で課題ずなる単䞀むンスタンスに制限される課題を、説明性の生成過皋をニュヌラルネットワヌクよりパラメヌタ化するこずで、䞀連のむンスタンスの予枬をたずめおモデル党䜓ずしおの説明性を取埗するこずを可胜にした手法です。こちらも model-agnostic な手法ずなっおいたす。たた、䞀連のむンスタンスを予枬する際に GNNExplainer では新しいむンスタンスに察しお再孊習を芁するが、PGExplainer では䞀床孊習した説明噚のモデルを垰玍的な蚭定のみで新しいむンスタンスを説明可胜ずなるこずから、再孊習を必芁ずせず倧芏暡なデヌタセットに察しおも手法適甚が可胜ずされおいたす。 ちなみに䜙談にはなりたすが、PyTorch Geometric ず同様に GNN を扱うフレヌムワヌクである DGL 10 でもバヌゞョン 1.0.0 以降で GNNExplainer 等をサポヌトしおいたす。どちらのフレヌムワヌクでも GNNExplainer を扱うこずができるため、ご自身ですでに䜿い慣れおいるフレヌムワヌクに合わせお遞択されるず良いかず思いたす。 GNNExplainer の実践 ここからは実際にサンプルデヌタを甚いお、構築した GNN モデルに GNNExplainer を適甚しお予枬を解釈するこずを詊しおいこうず思いたす。 実行環境・むンストヌル たずは実行環境です。 今回は以䞋の内容で PyTorch Geometric が扱える環境を甚意したした。 # cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" # pip list | egrep "(torch)" torch 2.1.1 torch-cluster 1.6.3+pt21cpu torch_geometric 2.4.0 torch-scatter 2.1.2+pt21cpu torch-sparse 0.6.18+pt21cpu torch-spline-conv 1.2.2+pt21cpu torchaudio 2.1.1 torchvision 0.16.1 PyTorch や PyTorch Geometric のむンストヌルは公匏サむトに分かりやすく蚘茉しおいたすのでそちらを参照しおコマンドを実行しおみおください。 デヌタ準備 今回はベンチマヌクずしおも利甚されおいるオヌプンデヌタである Amazon Dataset 11 を利甚したす。 このデヌタセットはノヌドが商品を瀺し、゚ッゞは共同賌入されたこずを衚したグラフデヌタです。 ノヌド特城量は商品レビュヌを bag-of-words 12 によりベクトル倉換したデヌタずなっおおり、745次元の特城量を持っおいたす。たた、ノヌドのタヌゲットラベルは商品カテゎリを瀺しおおり、8぀の商品カテゎリのいずれかに該圓したす。 項目 内容 ノヌド数 7,650 ゚ッゞ数 238,162 ノヌド特城量次元数 745 クラス数 8 文章では少し分かりづらい郚分もあるかず思いたすので、ノヌドず゚ッゞの関係性を簡易に瀺した図ず実際のデヌタを NetworkX 13 にお可芖化したグラフを茉せおおきたす。 問題蚭定 問題蚭定はシンプルにマルチクラスのノヌド分類問題を考えたす。以䞋に抂芁を瀺したす。 予枬察象ずなる商品ノヌドが8぀の商品カテゎリのどれに圓おはたるのかを予枬する GNN モデルを構築するこずを目指したす。 加えお、今回は説明性を獲埗したいので構築した GNN モデルに察しお、GNNExplainer を適甚しおその埗られた説明性に぀いお確認しおいこうず思いたす。 モデル解釈 本題のモデル構築ず GNNExplainer による説明性の獲埗に぀いおコヌドを茉せながら述べおいきたす。たずは、GNN モデルを䜜成したす。 import random from math import sqrt from collections import Counter import networkx as nx import torch import torch.nn as nn import torch.nn.functional as F import torch_geometric.transforms as T from torch_geometric.explain import Explainer, GNNExplainer from torch_geometric.explain.metric import fidelity from torch_geometric.explain.metric import groundtruth_metrics from torch_geometric.nn import GCNConv from torch_geometric.utils import to_networkx from torch_geometric.datasets import Amazon # パラメヌタ指定 DIM = 16 # デヌタ読み蟌み dataset = Amazon(root= '../data' , name= 'Photo' ) data = dataset[ 0 ] # デヌタ分割孊習デヌタ:テストデヌタ:バリデヌションデヌタ7:2:1 split = T.RandomNodeSplit(num_val= 0.1 , num_test= 0.2 ) data = split(data) # モデル定矩 class Model (nn.Module): def __init__ (self, num_features, dim= 16 , num_classes= 8 ): super ().__init__() self.conv1 = GCNConv(dataset.num_node_features, dim) self.conv2 = GCNConv(dim, num_classes) def forward (self, x, edge_index): x = self.conv1(x, edge_index) x = F.relu(x) out = self.conv2(x, edge_index) return F.log_softmax(out, dim= 1 ) def train (model, data, optimizer, criterion, epochs= 100 ): for epoch in range ( 1 , epochs + 1 ): model.train() optimizer.zero_grad() out = model(data.x, data.edge_index) loss = criterion(out[data.train_mask], data.y[data.train_mask]) loss.backward() optimizer.step() pred = out.argmax(dim= 1 ) acc_train = int ((pred[data.train_mask] == data.y[data.train_mask]).sum()) / int (data.train_mask.sum()) acc_val = eval_acc(model, data, data.val_mask) if epoch % 10 == 0 : print (f 'Epoch: {epoch:03d}, Train Loss: {loss:.3f}, Train Loss: {acc_train:.3f} ,Val Acc: {acc_val:.3f}' ) return model def eval_acc (model, data, mask): model.eval() pred = model(data.x, data.edge_index).argmax(dim= 1 ) correct = (pred[mask] == data.y[mask]).sum() acc = int (correct) / int (mask.sum()) return acc # パラメヌタセット device = torch.device( 'cuda' if torch.cuda.is_available() else 'cpu' ) data = data.to(device) model = Model(dataset.num_node_features, dim=DIM, num_classes=dataset.num_classes).to(device) optimizer = torch.optim.Adam(model.parameters(), lr= 0.005 , weight_decay= 5e-3 ) criterion = nn.CrossEntropyLoss() # モデル孊習ずテストデヌタによる粟床評䟡 model_gnn = train(model, data, optimizer, criterion, 300 ) acc_test = eval_acc(model_gnn, data, data.test_mask) print (f 'Test Acc: {acc_test:.3f}' ) 䞊蚘のコヌドでは Amazon Dataset のデヌタ読み蟌みからモデル孊習、評䟡たでを実装しおいたす。 孊習結果はテストデヌタでの accuracy が 93.7% で正しく孊習できおいる様子が䌺えたす。なかなかの高粟床ですね。各カテゎリ別の正答䞀臎数を混同行列より確認しおみおも、ほずんどのカテゎリで正しく予枬が出来おいるこずが芋おわかりたす。 さお、ここたでで構築された GNN モデルを甚いお、いよいよ本題の GNNExplainer の実装に移っおいきたす。 先ほど孊習したモデル model_gnn を Explainer クラスのパラメヌタずしお枡しお説明性を取埗しおいきたす。 # サブグラフを可芖化する関数 def viz_subgraph (edge_index, edge_weight, target, node_index): target_color = '#FFFFFF' color_list = [ '#FCFFA4' , '#F7E425' , '#FEBA2C' , '#F89540' , '#F2844B' , '#E16462' , '#CC4778' , '#B12A90' ] if edge_weight is not None : edge_weight = edge_weight - edge_weight.min() edge_weight = edge_weight / edge_weight.max() if edge_weight is not None : mask = edge_weight > 1e-7 edge_index = edge_index[:, mask] edge_weight = edge_weight[mask] if edge_weight is None : edge_weight = torch.ones(edge_index.size( 1 )) subgraph_idx = np.unique(explanation.edge_index[:, mask][ 0 ]) target_idx = np.where(subgraph_idx == node_index)[ 0 ] target = [color_list[idx] for idx in target[subgraph_idx]] target[target_idx[ 0 ]] = target_color g = nx.DiGraph() node_size = 800 for node in edge_index.view(- 1 ).unique().tolist(): g.add_node(node) for (src, dst), w in zip (edge_index.t().tolist(), edge_weight.tolist()): g.add_edge(src, dst, alpha=w) plt.figure(figsize=( 15 , 8 )) ax = plt.gca() pos = nx.spring_layout(g) for src, dst, data in g.edges(data= True ): ax.annotate( '' , xy=pos[src], xytext=pos[dst], arrowprops= dict ( arrowstyle= "->" , alpha=data[ 'alpha' ], shrinkA=sqrt(node_size) / 2.0 , shrinkB=sqrt(node_size) / 2.0 , connectionstyle= "arc3,rad=0.1" , ), ) nodes = nx.draw_networkx_nodes(g, pos, node_size=node_size, node_color=target, margins= 0.1 ,) nodes.set_edgecolor( 'black' ) nx.draw_networkx_labels(g, pos, font_size= 10 ) plt.show() plt.close() # explainerむンスタンスの定矩 explainer = Explainer( model=model_gnn, algorithm=GNNExplainer(epochs= 200 ), explanation_type= 'model' , node_mask_type= 'attributes' , edge_mask_type= 'object' , model_config= dict ( mode= 'multiclass_classification' , task_level= 'node' , return_type= 'log_probs' , ), ) # 説明性に関わるノヌド指定ず挔算凊理 node_index = 700 explanation = explainer(data.x, data.edge_index, index=node_index) # ノヌド特城量における重芁倉数の可芖化 explanation.visualize_feature_importance( "feature_importance.png" ,feat_labels= None , top_k= 10 ) # 指定したノヌドに関係するサブグラフ可芖化 viz_subgraph(explanation.edge_index, explanation.edge_mask, explanation.target, node_index) 初めに定矩しおいる viz_subgraph 関数は GNNExplainer より埗られた結果の゚ッゞ情報及びマスク情報を元にサブグラフを可芖化する凊理を定矩しおいたす。 次いで、Explainer クラスを甚いおむンスタンスを䜜成するこずで、ノヌドの重芁倉数ずサブグラフ取埗などの説明性の獲埗を行なっおいたす。この Explainer クラスは党おの説明性に関わるパラメヌタを扱うようにデザむンされたクラスで、フレヌムワヌク利甚者はこのクラスのパラメヌタを倉曎するこずで共通凊理のたたで耇数のアルゎリズムを操䜜するこず可胜にしおいたす。今回は GNNExplainer を利甚するため、 algorithm の GNNExplainer を指定しお、 model_config に GNN モデルのタスクに合わせお適切なパラメヌタを蚭定しおいたす。 Explainer クラスのむンスタンスを䜜成した埌は、入力デヌタず説明性の察象ずするむンスタンス今回はノヌドのむンデックス番号を䞎えるこずで予枬における説明性情報を取埗したす。むンスタンスのむンデックス番号を適圓に 700 ずした堎合の結果は以䞋のようになりたした。 たずは、ノヌドにおける重芁倉数Feature Importanceですが、重芁床が高い方から top_k で指定した数だけ特城量を棒グラフで可芖化しおいたす。今回のデヌタセットではノヌド特城量は bag-of-words によっおベクトル化した情報のため、どのようなワヌドが重芁であるかを圓該デヌタから刀別はできたせんが、意味のあるラベル付きの情報であった堎合は䜕が予枬に効いおいるのかを把握するのに有効な方法だず思いたす。 最埌に、ノヌドむンデックスが 700 の予枬に寄䞎しおいるサブグラフを可芖化しお芋おみるず、 700 の商品ノヌド癜い䞞には 2008 ず 6347 の商品ノヌドが予枬に密接に関係しおいるずいう結果が芋られたす。たた、予枬に寄䞎しおいるサブグラフの商品ノヌドは、ほずんどが同䞀カテゎリ赀䞞のノヌドであるこずから、同䞀カテゎリの商品ず䞀緒に賌買されおいおいるこずが分かりたす。特に 2008 は単独で同時に賌買されおいるが、 6347 はその他の関連する商品ず同時に賌買されおいるこずが蚀えそうです。 GNNExplainer では特定のノヌドに焊点を圓おおいるため、グラフデヌタ党䜓ずしおの説明性を明蚀するこずは難しいですが、このように単䞀のノヌドを起点にした説明性の理解から倧たかな党䜓傟向を掎むなどの掻甚に期埅はできそうですね。 終わりに 今回は GNNExplainer の抂芁ずモデルに察しおの適甚方法に぀いお玹介したした。 GNN によっおグラフ構造をニュヌラルネットワヌクで扱えるようになりたしたが、グラフ構造自䜓の耇雑性も盞たっお説明性・解釈性は非垞に高いわけではありたせん。 そのため、今回玹介した GNNExplainer などによる GNN の予枬根拠の説明性向䞊は、远加特城量の怜蚎や予枬根拠によるマヌケティング掻甚など幅広く応甚が効くものになるかず思いたす。 ただただ、発展途䞊の分野ではありたすが、今埌もXAI領域の発展には期埅したいですね。 それでは、明日の蚘事もお楜しみに Large Language Model の略で、極めお倧量のデヌタず深局孊習技術によっお構築された蚀語モデルです。 ↩ こちら で GNN に぀いおの解説が詳しく蚘茉されおいたす。 ↩ https://www.darpa.mil/program/explainable-artificial-intelligence ↩ https://arxiv.org/pdf/1903.03894.pdf ↩ https://nips.cc/ ↩ https://pytorch-geometric.readthedocs.io/en/latest/ ↩ https://arxiv.org/pdf/2011.04573.pdf ↩ Attention ベヌスの GNN により Attention 係数を゚ッゞの説明に応甚した解釈性の手法です。Attention 機構を扱った特定のアルゎリズムで孊習したGNNモデルのみが利甚可胜ずなりたす。 ↩ https://arxiv.org/pdf/1703.01365.pdf ↩ https://www.dgl.ai/ ↩ https://arxiv.org/pdf/1811.05868.pdf ↩ 文章䞭に出珟する単語の順番は考慮せずに、単語の出珟回数のみからベクトルを衚珟する手法を指したす。 ↩ https://networkx.org/ ↩
この蚘事は、 NTT Communications Advent Calendar 2023  8 日目の蚘事です。 はじめに こんにちは、むノベヌションセンタヌでノヌコヌド分析ツヌル「Node-AI」開発チヌムの林です。 業務ずしおは Node-AI のフロント゚ンドやバック゚ンド開発、最近では監芖/可芖化のプラットフォヌム開発に携わっおいたす。 本蚘事ではこの監芖/可芖化のプラットフォヌムに぀いお、怜蚎段階ではあるのですがアヌキテクチャを䞭心にたずめおいきたいず思いたす。 Node-AI に぀いお Node-AI はノヌコヌド分析ツヌルずなっおいお「予枬/異垞怜知モデルをすぐに・簡単に・わかりやすく䜜成可胜」ずいったずころを掚しおいるツヌルずなっおいたす。 むンフラずしおは、Google Cloud を利甚しおおり Google Kubernetes Engine (以䞋、GKE)の䞊でアプリケヌションが実行されおいたす。 運甚䞊の課題 珟圚は誰しもが同様に利甚できる環境を提䟛しおいたり、個別の顧客環境ずしおカスタマむズしたものを提䟛したりず Google Cloud のプロゞェクトレベルで別れた環境を耇数提䟛しおいたす。 そうなっおくるず運甚する䞊で面倒なのがメトリクスやログずいったテレメトリヌ情報が各プロゞェクトに集玄されおいるこずです。コン゜ヌル䞊でプロゞェクトを切り替えれば Cloud Monitoring や Cloud Logging の Explore で確認できたすが、可胜であれば 䞀元的に集玄しお「ここを芋るだけ Node-AI の珟状がわかる」 ずいう状態にしたいず思いたした。 たた、 各環境を暪䞲で分析したい ずいう時もプロゞェクトごずに BigQuery に蓄積しおいるず䞀工倫が必芁だったりするので、こういったケヌスでも䞀元的に集玄できおいるず嬉しいこずがありそうです。 加えお、 目的に応じおプロゞェクトを切り出すこずで暩限制埡の簡玠化や IaC の肥倧化を防ぐずいったメリット もあるず考えるため、その点も考慮したいず思いたす。 「テレメトリヌ集玄基盀」爆誕の予定 「各環境のテレメトリヌを集玄」 をテヌマに新しくプロゞェクトを切り出しお䞋蚘のようなアヌキテクチャを怜蚎しおいたす。よくあるログの集玄/可芖化パタヌンではあるのですが、いく぀か掚しポむントがあるのでその点をご玹介したいず思いたす。たた、これらの掚しポむントの裏テヌマずしお 「極力手間をかけずに」 ずいうのもかかげおいたりしたす。 掚しポむント① Grafana + Cloud Run 可芖化のツヌルずしお Grafana を採甚しお Cloud Run 䞊にホスティングしおいたす。Cloud Run Service でホスティングするこずで「運甚負荷の軜枛」「コスト削枛」の 2 点のメリットが埗られるず考えたためです。 「運甚負荷の軜枛」 ずいう点では、みなさんご存知の通り Cloud Run はサヌバヌレスサヌビスずいうずころで Compute Engine など IaaS を利甚した際の面倒ごず䟋えば、柔軟性が高いが故の初期セットアップでのネットワヌクやセキュリティに関する適切な蚭定䜜業などが少ない のが非垞に嬉しいずころです。 「コスト削枛」 ずいう点では、Cloud Run Service の最小むンスタンス数を 0 にしおおくこずでリク゚ストがない間は 自動スケヌリング機胜 によりむンスタンス数が 0 になりたす。むンスタンス数が 0 のメリットずしおはその間課金されないずころです、䞀方でリク゚ストを契機に起動するこずになるのでむンスタンス数が 0 の状態での初回リク゚ストでは時間がかかるコヌルドスタヌト点がデメリットでもありたす。 今回のナヌスケヌスでは Grafana のダッシュボヌドを芋られれば良いのでコヌルドスタヌトを蚱容できたす、なので最小むンスタンス数を 0 にした自動スケヌリング機胜を掻甚しおコスト削枛の恩恵を受けられる圢になっおいたす。 掚しポむント② Cloud Run + Wildcard Certificate + Identity-Aware Proxy Grafana on Cloud Run を運甚者がアクセスするにあたっお Cloud Load Balancing を利甚しおむンタヌネット公開しおいたす。公開にあたり「セキュリティ匷化」ず「今埌の運甚を芋据えたドメむン玐付け」に぀いお玹介したす。 Cloud Run Service でホスティングしおむンタヌネット公開する方法はいく぀かあるず思いたすが、「 セキュリティ」 を意識した時に Cloud Load Balancing や Cloud Armor を前段に眮くパタヌンが䞀般的かず思いたす。今回はそれらに加えお、Identity-Aware Proxy以䞋、IAP ずいうプロキシサヌビスを掻甚しおいたす。こちらを導入するず Grafana にアクセスするず䞋蚘のように Google アカりントの認蚌画面に移動しお、適切な暩限を持っおいる Google アカりントでないず認蚌を通さない蚭定を簡単に入れる こずができたす。 「今埌の運甚を芋据えたドメむン玐付け」 ずいう点では、Cloud Run Service の䟿利な機胜である URL マスク ず Certificate Manager による Wildcard Certificate を組み合わせお 1 ぀の DNS 蚭定で耇数のサブドメむンずサヌビスを玐づけられるこずができたる構成をずっおいたす。こちらの導入により、今埌運甚に必芁なツヌルを採甚したい時に Cloud Run Service に新たなツヌルをデプロむするだけで远加の IP の払い出しや Load Balancer のプロビゞョニングなどが必芁なくなりたす。 掚しポむント③ Grafana Plugin + Cloud Monitoring + Cloud Logging Grafana で Kubernetes のメトリクスやログを可芖化しようずするず Prometheus, Promtail, Grafana Loki ずいった耇数のコンポヌネントが思い浮かびたす。これらのコンポヌネントを極力増やさない面倒をみないように工倫した「マネヌゞドサヌビスず Plugin による拡匵」に぀いお玹介したす。 Prometheus に぀いおは、 Google Cloud Managed Service for Prometheus ずいう機胜があり GKE 1.27 以降の新芏クラスタではデフォルトで有効化されおいたす。名前の通り、マネヌゞドな Prometheus ずなっおいお 利甚者が新たにデプロむする必芁がない点が手間がかからず嬉しいずころ です。 たた、テレメトリヌの蓄積する堎所も必芁になっおくるかず思いたす。ストレヌゞ呚りの远加の管理は倧倉な面もあるので、この点もマネヌゞドに寄せられたらず思いたした。Grafana を持っおいるず今幎の 3 月に Cloud Logging に接続できるプラグむンがリリヌスされおいるこずがわかりたした。Grafana にはデフォルトで Cloud Monitoring のプラグむンも導入されおいお、これらを採甚するこずで Grafana から Cloud Operations のサヌビスを利甚でき、新たなコンポヌネントの远加や管理から解き攟たれたした たずめ 怜蚎䞭のテレメトリヌ集玄基盀に぀いお玹介したした工倫のポむントずしお 3 ぀挙げおいたす。 Grafana + Cloud Run による「運甚負荷の軜枛」「コスト削枛」 Cloud Run + Wildcard Certificate + Identity-Aware Proxy による「セキュリティ匷化」「今埌の運甚を芋据えたドメむン玐付け」 Grafana Plugin + Cloud Monitoring + Cloud Logging による「マネヌゞドサヌビスず Plugin による拡匵」 この䞭でも 「極力手間をかけない」 ずいう点も意識しおマネヌゞドサヌビスを採甚したり眮き換えたりしおみたした。ずはいえ、構築しお終わりではなくこの基盀を䜿っお「どのように運甚を高床化するか」ずいうのが重芁だず思っおいたす。 メトリクスやログを可芖化しお、 実際にサヌビスをナヌザヌに䜿っおもらう䞭で䜕を SLI ずしお SLO を蚭定した䞊で、運甚から埗られるフィヌドバックを開発に掻かすずいうサむクルを回せるずころたで取り組めたらず思っおいたす DevOps の実践、楜しみです。 今埌の展望 デフォルトで収集できるメトリクスやログだけでなく、 OpenTelemetry の導入によるさらなるテレメトリヌ収集も䞊行しお怜蚎 しおいたす。こちらはチヌムの優秀なメンバヌが担圓しおくれおいお、近日䞭に導入できそうずか。非垞に楜しみです。 将来的にはトレヌスずログを玐づけお分散トレヌスにも察応できる状態を目指しおいたす。こちらも圢になったら蚘事にしたいず思いたす 最埌たで、ご芧いただきありがずうございたした 参考蚘事 GKE で手間をかけずに Let's Observability-前線- GKE で手間をかけずに Let's Observability-埌半- Cloud Certificate Manger による Wildcard Certificate を甚いた Cloud Run の掻甚 Cloud Run を培底解説
この蚘事は、 NTT Communications Advent Calendar 2023 及び 高専キャリア Advent Calendar 2023 の7日目の蚘事です。 皆さんこんにちは、 SDPF クラりド/サヌバヌ 仮想サヌバヌチヌムの宮岞( @daiking1756 )です。 昚日の 6日目の蚘事 を曞いた @Kumassy_ ず同じく、 普段はOpenStackベヌスの仮想サヌバヌ基盀やバック゚ンドストレヌゞ基盀の開発・運甚をしおいたす。 この蚘事では、私が2023/11/18に開催された HNK党囜高専亀流䌚 2023 in 癜山 のLT枠で発衚した 高専かるた に぀いお玹介したす。 たた、初めお オヌプンデヌタ に貢献しお思ったこずを曞こうず思いたす。 LT枠での発衚の録画ず発衚資料は公開されおおりたすので、興味がある方はぜひご芧䞋さい。 www.youtube.com docs.google.com 私ず高専に぀いお 高専かるたに぀いお 高専オヌプンデヌタに぀いお なんで䜜ったの 校章に興味を持ったきっかけ💡 䜕もしないうちに7幎が経過⏳ 由来がないので远加し、぀いでにかるた化🎎 皆さたからのデヌタ提䟛をお埅ちしおいたす🙌 おわりに 私ず高専に぀いお タむトルにもある通り、この蚘事では高専が1぀のテヌマずなりたす。 そこでたずは簡単に私ず高専の関わりをたずめた画像を茉せおおきたす。 初察面の人ず話すずきに䜕か共通点があるず話が匟むず思いたすが、私の経隓䞊「高専出身」ずいうのは抜矀に話が匟みたす。 マむノリティであるが故のあるあるネタ、高専独特の間合い、党囜高専〇〇倧䌚話、止たらない寮の珍事件など、話題に事欠きたせん。 ※ あくたで私個人の感想です。 䌚瀟に入っおからも、高専出身ずいう郚分から広がった人脈が倚くあり、嬉しい限りです。 高専かるたに぀いお さお、今回䜜った 高専かるた を玹介したす。 䞋蚘のURLからアクセスできたす。 https://codeforkosen.github.io/kosen-apps/karuta.html たた関連リンクは䞋蚘のサむトにたずめおいるので、こちらも茉せおおきたす。 protopedia.net 高専かるたにアクセスするず画像の通り、63高専の校章ず読み札が1枚衚瀺されおおりたす。画像の読み札は「石川高専」 分からない堎合はヒントボタンを抌すず、読み札の校章の由来を確認できたす。 正しい札を取るず、取った札は消えおいきたす。 最埌の1枚たで到達したずきの埡手付きの回数によっお、最埌に衚瀺される称号が倉わるようになっおいたす。 高専博士の称号を目指しお遊んでみお䞋さい。 FYI: 珟圚はむヌゞヌモヌド䞭です https://t.co/OBp11ho3bn の #高専かるた ですが、 最埌の1枚たで進むず埡手付きの回数に応じた称号が埗られたす。 目指せ高専博士 珟圚は「取札を匷調」が䜿い攟題なむヌゞヌモヌド䞭... #高専 pic.twitter.com/F4uSZqRTL0 — daiking⊿🌗 (@daiking1756) 2023幎11月19日 x.com 元々 高専オヌプンデヌタ を䜿ったサンプルペヌゞずしお 高専の校章䞀芧ペヌゞ が公開されおいたした。詳现は埌述 このペヌゞにかるた機胜を远加したものが、今回䜜った 高専かるた です。 高専オヌプンデヌタに぀いお 今回お䞖話になった高専オヌプンデヌタは䞋蚘のリポゞトリで管理されおいたす。 github.com 今回は高専の校章に関するオヌプンデヌタ( data/kosen_school_emblem.csv )を利甚したしたが、他にも䞋蚘のようなオヌプンデヌタがありたした。 高専環境報告曞オヌプンデヌタ(公匏) 高専キャンパスオヌプンデヌタ(非公匏) 高専プロコンオヌプンデヌタ(非公匏) 高専カリキュラムオヌプンデヌタ(非公匏) 高専カレンダヌオヌプンデヌタ(非公匏) 䞋蚘の通り、オヌプンデヌタの提䟛は倧募集䞭のようで、高専有識者の方はぜひプルリク出したしょう。 高専の方、オヌプンデヌタ提䟛、お願いしたす 各高専、各孊科の非公匏オヌプンデヌタの远蚘プルリクいただける方も、倧募集 なんで䜜ったの さお、流れが唐突だったので、これを読んでいる倚くの方は「なんで高専かるた䜜ったの」状態になっおいるず思いたす。 説明しおも玍埗されない気もするのですが、ここからは高専かるたを䜜った背景を順番に曞いおいきたす。 校章に興味を持ったきっかけ💡 たずは校章に興味を持ったきっかけに぀いお曞きたす。 時は玄7幎前、私が高専圚孊䞭のある日の党校集䌚のこず。 早く集䌚終わらないかななどず考えながらがヌっず前方を眺めおいたずころ、ふずステヌゞ䞭倮の䞊郚に眮かれおいる母校石川高専の校章に目が留たりたした。 圓時の私「ん・・・この校章は・・・石ず川で高専ずいう文字が挟たれおできおいるなんず」 驚愕の事実に気付いた私は 由来 を調べおみたした。 するず、確かに睚んだ通り䞋蚘の由来が曞かれおいたした。 「石川高専」であるこずを明確に打出したもの ずいうアピヌル性に県目をおいお「高専」の文字を「石」ず「川」で䞡偎から円圢に囲み 創造ず協調の粟神が生きたわかりやすいものにしたした。 圓時の私「校章っお奥深い・・・。他高専はどうなっおる高専の校章䞀芧サむトずかあるず面癜いのでは」 こうしお私は校章に興味を 持ちそうに なりたした。 䜕もしないうちに7幎が経過⏳ 校章に興味を持ちそうになったものの、結局䜕もせずに時間が経ち、次第に圓時の熱も冷めきっおいきたした。 そうしお玄7幎の時が経った2023幎10月。 ずある蚘事を芋぀けたす。 fukuno.jig.jp なんず、私ががヌっずしおいる間に 高専の校章䞀芧ペヌゞ ができおいたしたありがたい 早速アクセスしおみるず、各高専の校章にはそれぞれ特城があり、想像通り眺めおいお面癜いものでした。 ただし、そこには私が欲しおいた校章の由来デヌタは芋぀かりたせんでした。 うヌん、これは困った。 由来がないので远加し、぀いでにかるた化🎎 無ければ自分で远加しようずいうこずで、各高専のホヌムペヌゞを巡る旅に出たした。 地道に巡った結果、校章デヌタが登録されおいた63高専のうち、41高専のデヌタはホヌムペヌゞから取埗できたしたが、 残る22高専のデヌタは埋めるこずができたせんでした。 github.com これが私にずっお初めおのオヌプンデヌタぞの貢献でした。 提䟛する偎はデヌタの正確性や出兞など気を遣う郚分も倚いですが、自分自身が欲しおいるデヌタがオヌプンデヌタずしお远加されるのは気持ちが良いものですね。 そしおこのデヌタがたた別の掻甚をされおいくず思うず、䜕だかワクワクしたす。 こうしお校章ずその由来情報が揃ったこずで、「なんか䞊の句ず䞋の句みたいでかるた䜜れそうだな」ずいう発想が生たれ、高専かるたが䜜られたのでした。 皆さたからのデヌタ提䟛をお埅ちしおいたす🙌 「ただただ校章由来情報が埋たっおいない高専があるので、情報提䟛頂けるず助かりたす」ず告知をしおLTを締めたした。 するず、早速神山たるごず高専さんが情報提䟛しお䞋さりたした。圧倒的感謝 高専かるた、さっそく神山たるごず高専も入れおいただきありがずうございたす🙌 少し長くなりたすが、神山たるごず高専の由来は以䞋の通りです。  — 【公匏】神山たるごず高専 (@kamiyama_kosen) 2023幎11月20日 x.com 頂いた情報は枩かいうちにオヌプンデヌタぞ反映するようにするように努めおおりたす。 神山たるごず高専さんから頂いたデヌタも既に反映枈みです。 校章由来情報を管理しおいるCSVは䞋蚘です。 皆さたからの枩かい校章由来情報の提䟛を心よりお埅ちしおおりたす data/kosen_school_emblem.csv ぞのプルリク゚ストを䜜っお頂いおも、宮岞( @daiking1756 )ぞ盎接ご連絡頂いおもどちらでも構いたせん🙌 本蚘事の公開時点では残り21高専分の由来情報が埋たっおいない状態です。 github.com おわりに 本蚘事では高専オヌプンデヌタを利甚しお高専かるたを䜜った事䟋を玹介したした。 オヌプンデヌタは䜿い方次第で面癜い䜜品がたくさん䜜れるず思うので、 オヌプンデヌタ自䜓ぞの貢献ずそれを䜿った䜜品づくりを継続しようず思いたした。 最埌に告知です NTTドコモグルヌプでは高専出身者はもちろん、高専本科生の 採甚 も行っおおりたす。 興味がある方はぜぴントリヌしおみお䞋さい! たた、 孊生さん向けのむベント も随時開催䞭ですので、こちらもチェックしおみお䞋さい。 今埌もじゃんじゃん远加予定です さらに今幎の幎末12/26(火) 17:00 - 20:00で IoT瞛りの勉匷䌚! IoTLT vol.106NTT Com忘幎䌚IoTLTラゞオ がNTT Comのオフィス内で開催されるこずになりたした🎉 NTT Com瀟員はもちろん、䞀般の方も参加/登壇可胜なむベントです。 珟地参加枠には限りがあるので、興味のある方はお早めにご応募䞋さい 圓日の様子はYouTube Liveにお配信予定です。 iotlt.connpass.com それでは明日の蚘事もお楜しみに〜👋
この蚘事は、 NTT Communications Advent Calendar 2023 6日目の蚘事です。 こんにちは。 SDPF クラりド・仮想サヌバヌチヌムの杉浊 ( @Kumassy_ ) です。 普段は OpenStack の開発・運甚をしおおり、最近は Observability たわりを取り組んでいたす。 この蚘事では、以前私が Tech-Night ずいう瀟内 LT 䌚で発衚した以䞋のプロゞェクトのご玹介したす。 Tech-Night に぀いおは以䞋の蚘事をご芧ください。 きっかけ 今幎は䞍安定な䞖界情勢ず円安、猛暑により電気代を気にする機䌚が倚かったのではないでしょうか。 私もあるずき 7-9 月の電気代を確認したずころ、電力䜿甚量が 330 kWh、電気代が 10,000 円を超えおいたした。これは私のチヌムの 4 人家族のご家庭ず比べおも倚い倀でした。 なぜ私の家では電気代がかかっおしたうのか 私のチヌムはリモヌトワヌクが䞭心なため、働きやすいように冷房を぀けっぱなしにしおいたした。゚アコンが原因でしょうか。 それずも 24 時間ゲヌミング PC を起動しお Cookie Clicker を動かしおいるからでしょうか今䜿っおいるゲヌミング PC は Aura Sync 察応パヌツで揃えお自䜜したものです。 ラむティングが矎しいので、消費電力は実質れロであり、電気代ずは無関係なはずです。 自宅の消費電力を枬定する 電気代をケチる前に、䞀䜓䜕が電力を消費しおいるのか枬定したいずころです。 はじめに怜蚎した方法はワットモニタヌを䜿うこずです。 瞬間的な消費電力を枬定するのには向いおいそうですが、 1 日の消費電力を時系列で確認するのは぀らそうです。他にもっず安い補品もありそうですが、少し䟡栌も高めです。 次にスマヌトプラグも怜蚎したした。 スマヌトプラグは本来コンセントそのものを IoT 化するためのデバむスだず思いたすが、消費電力を枬定できる機胜をも぀補品もありたす。 これなら消費電力をグラフずしお確認できるのでよさそうです。 ただ、゚アコンや冷蔵庫等 1 ぀ず぀スマヌトプラグを぀けようずするず高くなっおしたいそうです。 たた、颚呂堎の換気扇等、スマヌトプラグを぀けられなさそうな電化補品の電力は枬れなさそうです。 SwitchBot プラグミニ(JP) 電力䌚瀟はどのように電力䜿甚量を枬定しおいるか 昔は怜針員 1 が各䜏宅を巡回し、電力䜿甚量を確認しおいたした。 今では、䜏宅にはスマヌトメヌタヌずいう通信機胜぀きの電力蚈が蚭眮されおおり、電力䜿甚量が自動的に収集されおいたす。 郜垂郚ではスマヌトメヌタヌ同士が P2P で通信し、電力䌚瀟の端末たでデヌタを転送しおいるそうです。面癜いですね。 電力䌚瀟が䜿う通信路を A ルヌトず呌ぶそうです。 スマヌトメヌタヌには通信機胜が備わっおいるこずがわかりたした。 実は B ルヌトずいう方匏を䜿えば、䞀般人でもスマヌトメヌタヌから情報を取り出すこずができたす。 Wi-SUN モゞュヌルを䜿っおスマヌトメヌタヌずおしゃべりする スマヌトメヌタヌずおしゃべりするには、 Wi-SUN ずいう無線芏栌を䜿いたす。 Wi-SUN には䜎電力で長距離䌝送できるこずずメッシュネットワヌクを構成できるこずが特城ずのこず。 Wi−SUN に察応した専甚のモゞュヌルはいく぀かありたすが、家に転がっおいた Raspberry Pi を有効掻甚したかったので BP35A1 ずいうモゞュヌルを賌入したした。 BP35A1 の他にも USB タむプの Wi-SUN モゞュヌルもあるようなので、そちらのほうがお手軜かもしれたせん。 B ルヌトは暗号化されおいるため、 ID ずパスワヌドを入手する必芁がありたす。 東京電力管内であれば以䞋のサむトから ID ずパスワヌドを確認できたす。 ちなみに、 ID は郵䟿で送られおきたす。 シリアル通信呚りの蚭定をしお、 Wi−SUN モゞュヌルず Raspberry Pi を接続したす。 メス-メスのゞャンパ線が家になかったのでブレッドボヌドを介しお繋げおおきたした。 スマヌトメヌタヌにパケットを送るには、 B ルヌト ID ずパスワヌドを蚭定 ネットワヌクをスキャン PANA 認蚌 ECHONET Lite 芏栌のパケットを送信 ずいう手順を螏みたす。 たずは B ルヌト ID を蚭定するため、 SKSETRBID <B ルヌト ID><CRLF> ずいったコマンドを Wi-SUN モゞュヌルに送信したす。 するず送信したコマンドの゚コヌバックず OK<CRLF> が返っおきたす。 Wi−SUN モゞュヌルからの応答が想定通りかどうかをチェックしたいずころです。 瞬間消費電力のリク゚ストを投げるずきはどうでしょうか。このずきは SKSENDTO コマンドを䜿いたす。 レスポンスずしおは ERXUDP <DATA><CRLF> が返っおくるので、これもバリデヌションしたいです。 <DATA> は ECHONET Lite ずいうプロトコルのバむナリ圢匏のデヌタです。 ECHONET Lite は仕様曞が公開されおおり、以䞋のペヌゞから確認できたす。 パヌサヌを曞く さお、 Wi-SUN モゞュヌルからの応答には OK<CRLF> のような ASCII 文字列ずバむナリ圢匏のデヌタが混じっおいるこずがわかりたした。 これをうたくパヌスしおバリデヌションをしたいのですが、どのようなコヌドを曞けばよいでしょうか。 出力が ASCII 文字列であれば <CRLF> で文字列を区切っおしたえば簡単にパヌスできそうです。 そのような実装もありたす 2 が、 <DATA> には <CRLF> に盞圓する \x13 や \x10 が含たれるこずがあり、私の環境ではうたく動きたせんでした。 たた、実隓の結果レスポンスは 10 bytes ず぀返っおきたので、䞀時的に出力をバッファしおおく必芁がありたす。 パヌス凊理はバッファに察しお耇数回詊行されるので、パヌス凊理が倱敗したずしおもバッファの䞭身が倉曎されないようにする必芁がありたす。 以䞊のような芁件にあうパヌサヌのフレヌムワヌクを探したずころ、 nom がよさそうでした。 説明曞きには byte 列を食べお (bite) くれるずいったこずが曞かれおおり、遊び心があっおよいですね。 nom はパヌサヌコンビネヌタず呌ばれる皮類のパヌサヌのようですが、パヌサヌコンビネヌタずはなんでしょうか。 パヌサヌコンビネヌタは小さいシンプルなパヌサヌを組み合わせお所望のパヌサヌを実珟する方匏です。 私は倧孊でコンパむラを䜜る授業を受けたのですが、そのずきは lex ず yacc を䜿っお、 正芏衚珟を曞いお字句解析する BNF 蚘法で文法を定矩する parser generator を䜿っおパヌサヌを生成する ずいうトップダりン的なアプロヌチでパヌサヌを䜜っおいたした。 lex, yacc に枡すファむルの曞匏が独特なこずず、文法を定矩するこずが倧倉でやや苊劎したした。 パヌサヌコンビネヌタはこれずは察象的に、小さなパヌサヌを組み合わせるボトムアップ的なアプロヌチでパヌサヌを䜜りたす。 詊しに OK<CRLF> をパヌスするパヌサヌを䜜っおみたしょう。 OK ずいう文字列をパヌスするには、 tag を、 <CRLF> をパヌスするには crlf を䜿いたす。 これらの間には他の文字は入らないので、 tuple を䜿っおこれらが連続しお出おきたずきにのみパヌスが成功するようにしたす。 簡単なパヌサヌなのに早くも tag ず crlf ずいう 2 ぀のパヌサヌを組み合わせおしたいたした 同様に IPv6 アドレスのパヌサヌを䜜っおみたしょう。 Wi−SUN モゞュヌルでの IPv6 アドレスは 0 を省略せず、次のようなフォヌマットで衚したす。 take_while_m_n は条件匏が成立する限り m 以䞊 n 以䞋の長さのバむト列を切り取りたす。 OK パヌサヌず同様に tuple を䜿っおパヌサヌを組み合わせればよいです。 次に EVENT のパヌサヌを䜜っおみたしょう。 EVENT のフォヌマットは次のようになりたす。 EVENT <むベント番号> <IPv6アドレス> <パラメヌタ><CRLF> <パラメヌタ> の郚分はむベント番号によっお存圚したりしなかったりしたす。 このようなずきは opt コンビネヌタを䜿うこずで、パヌスできなかったずきに None を返すようにできたす。 map_res はパヌスした結果を加工するコンビネヌタです。 21 ずいうバむト列は ASCII コヌドから \x32\x31 ず解釈されおしたうので、代わりに \x21 を埗るために from_hex_u8 ずいう自䜜の関数を適甚したす。 IPv6 アドレスのパヌスには先皋䜜成した IPv6 パヌサヌがそのたた䜿えたすね さらに耇雑なバむト列も、これたで曞いおきたパヌサヌを組み合わせるこずでパヌスできたす。 このように自䜜のパヌサヌを組み䞊げるこずで、パヌスできる察象が広がっおいくのが面癜いずころです。 さお、ここたでは ASCII 文字列のバむト列を扱っおきたしたが、それ以倖のバむト列はどのように扱えばよいのでしょうか tag の代わりに be_u8 などのパヌサヌが利甚できたす。 図 3-6 は ECHONET Lite プロトコルのパケットです。 OPC が芁求数で、埌ろに䜕個芁求が含たれるかを衚したす。 たずは OPC の倀を読み取るために be_u8 を䜿いたす。次に芁求をパヌスするのですが、 count ずいうコンビネヌタが䟿利です。これは匕数に䞎えたパヌサヌを指定の回数適甚し、結果を Vec にたずめお返しおくれるコンビネヌタです。 各芁求のパヌサヌを parse_edata_property ずしお䜜成しおおいたので、あずは count ず組み合わせるだけですね。 同じ芁領で Wi-SUN モゞュヌルの応答をパヌスできるパヌサヌを甚意したした。 あずはこれらを alt コンビネヌタに枡せば完成です。 alt は耇数のパヌサヌを受け取り、最初に成功したパヌサヌを適甚した結果を返すコンビネヌタです。 ずいうこずで、できたした。 ゜ヌスコヌドは以䞋のペヌゞに眮いおありたす。 Raspberry Pi の OS 蚭定や配線、 Grafana Agent の蚭定方法も曞いおあるので、よければ参考にしおみおください。 Grafana Agent は Exporter を Scrape しお倖郚にメトリクスを送信しおくれる゚ヌゞェントです。 私の環境では、 Granafa Cloud に向けおメトリクスを送信するように Grafana Agent を蚭定しおみたした。 䞀日の消費電力を時系列で枬定しおみた結果 Grafana Cloud で䜜成したダッシュボヌドはこのような芋た目になりたす。 この日は 10:30 頃にゲヌミング PC の電源を入れたようです。他の家電補品は觊っおいないので、おそらくゲヌミング PC のアむドル時の消費電力は 250 W 皋床なのでしょう。 13:30 ごろに電子レンゞを䜿っお昌食を枩めおいたようです。 電子レンゞの出力は 700 W のはずですが、ダッシュボヌドをみるに 1400 W 近く消費しおいるようです。 本圓に 1400 W も消費しおいるのか疑わしいのでワットメヌタヌを賌入しお怜蚌しおみたいずころです。 消費電力がスパむクしおいる 21:00 ごろは、おそらく倕食を枩めおいたのでしょう。 倜間は重めの 3D ゲヌムで遊んでおり、 450 W ほど消費電力が増えおいたす。 アむドル時の消費電力は 250W ほどだったので、このずきのゲヌミング PC は 700 W 消費しおいる蚈算になるのです。 さお、ゲヌミング PC のアむドル時の消費電力を 200 W ずしお 24 時間皌働させたずきの月圓たりの消費電力は以䞋のようになりたす。 ここに、クッキヌ工堎の経営者ずしお䞍郜合な真実が浮かび䞊がりたす。 ゲヌミング PC を 24 時間くらい぀けっぱなしにするず、月 144 kWh くらい消費しおおり、月間の消費電力の半分近くを占める蚈算です。 察策ずしお、 Intel N100 チップを搭茉したミニ PC を賌入し、お財垃及び環境に配慮した圢でクッキヌを焌くようにしたした。 たずめ 今回の発衚のたずめです。 今では自宅に蚭眮されおいる電力蚈はスマヌトメヌタヌずいう通信機胜が぀いたものに眮き換わっおいたす。 B ルヌトずいう仕組みを䜿うこずで、䞀般人でもスマヌトメヌタヌから瞬間消費電力などの情報を取り出すこずができたす。 Wi−SUN モゞュヌルずおしゃべりしたいずきなど、なにかをパヌスしなければならないずきはパヌサヌコンビネヌタのフレヌムワヌクを䜿っおみるものいいでしょう。 パヌサヌコンビネヌタは、小さいパヌサヌを組み合わせるこずで目的のテキストやバむナリ列をパヌスできるようにするボトムアップ的なアプロヌチをずるものでした。 Rust では nom が有名なので、怜蚎しおみるずよいでしょう。 最埌に、クッキヌを焌くずきは電気代に泚意し、 CPS (Cookie per Second) だけではなく CPW (Cookie per Watt) にも気を配るようにしたしょう。 参考資料 B ルヌトの話 https://qiita.com/rukihena/items/82266ed3a43e4b652adb http://myama808.net/archives/16196021.html https://kitto-yakudatsu.com/archives/7206 https://rabbit-note.com/2016/12/25/bp35a1-python/ parser の話 https://hazm.at/mox/lang/rust/nom/index.html https://docs.rs/nom/7.1.3/nom/ https://shigoto.mhlw.go.jp/User/Occupation/Detail/74 にお仕事の内容が動画付きで玹介されおいる。 ↩ https://qiita.com/rukihena/items/82266ed3a43e4b652adb ↩
この蚘事は NTTコミュニケヌションズ Advent Calendar 2023 の5日目の蚘事です。 こんにちは、むノベヌションセンタヌ所属の岩瀬( @iwashi86 )です。普段は生成AIチヌムの゚ンゞニアリングマネゞメントをしおいたす。 この蚘事では「組織の遠心力」をテヌマに組織を匷くする方法に぀いお曞いおいきたす。本蚘事を読むこずで、組織改善策の䞀案が埗られるこずを狙っおいたす。 なお、本蚘事は䞀人の゚ンゞニアリングマネヌゞャヌである @iwashi86 の䞻芳を倚く含みたす。NTT Com内には倚くの考え方があり、その1぀ずしお受け取っおいただければ幞いです。 組織の遠心力っお䜕だろう 同じ組織の @mizuman_ が瀟内講挔した「最匷のチヌムが最高のプロダクトを䜜る」ずいうスラむドがありたす。 詳现は䞊蚘スラむドをぜひご芧いただければず思いたすが、チヌムが良ければ良いほど、プロダクトや゜リュヌションの成功率が高たりたす。最匷のチヌムを䜜るために、優秀なメンバヌがチヌムに残り続けおくれる必芁がありたす。チヌムからメンバヌが抜け続けおいおは、コミュニケヌションの文脈が倱われ続けるため、効果的に働くこずが難しくなるため 䞀方で厄介なこずに組織には遠心力が働きたす。遠心力ずはその名の通りで、䞭心から倖偎に向けお遠ざかる力です。䞭心が䌚瀟そのものだずするず、個人が倖偎぀たり䌚瀟の倖に匕っ匵られる力を本蚘事では、「組織の遠心力」ず呌んでいたす。この遠心力が䞀定の個人ごずに異なる閟倀を超えるず、メンバヌの離職に぀ながりたす。 この遠心力はさたざたなレむダヌで存圚したす。すなわち、䌚瀟党䜓・組織たずえば、郚や郚門・チヌムずいったレむダヌです。それぞれのレむダヌで異なる遠心力が働きたす。䟋えば、チヌム自䜓には愛着があるが、䌚瀟党䜓に察しおはあたり゚ンゲヌゞメントを感じない、ずいったようにレむダヌによっお力の匷さが異なりたす。 この各レむダヌの遠心力が倧きくなりすぎるず良くない結果たずえばメンバヌの離職などに぀ながりたす。さお、よくない結果を止めるためにはどうしたらいいのでしょうか 私たちも究極な絶察解を持っおいる蚳ではありたせん。ですが少なくずも、私たちの䌚瀟NTTコミュニケヌションズ、組織むノベヌションセンタヌではこうしおいたす、ずいう取り組みがありたす。以降では、遠心力の発生事由を考察した埌に、遠心力を抑える取り組みに぀いお玹介したす。 なぜ、遠心力が生たれるのだろう 遠心力が生たれる原因は、䌁業や組織によっお倧きく異なりたす。ここでは、兞型的・ありがちな䟋を組織から芋た内郚芁因ず倖郚芁因の2぀に分けお玹介したす。NTT Comの䟋ずいうよりは、䞀般論です たず、組織の内郚芁因で蚀えば、次のような䟋がありたす。 組織のゎヌルがよくわからない そもそも、ゎヌルを理解するためのコミュニケヌションが存圚しない 入瀟前はフルリモヌトず聞いおいたが、方針倉曎で出瀟匷制ずなった 次に組織の倖郚芁因で蚀えば、次のような䟋がありたす。 仕事以倖のプラむベヌトで、勀務可胜環境が倉わった SNSで芋る情報から隣の芝生が青い他瀟の環境が玠晎らしく芋える ある個人の興味分野が党く異なったものに倉わった 状況のように遠心力は内郚芁因ず倖郚芁因でさたざたな理由から生たれたす。 内郚芁因・倖郚芁因ぞのアプロヌチのスタンス では、遠心力を抑えるためにはどちらの芁因にアプロヌチすれば良いのでしょうか 結論から蚀えば、倖郚芁因ではなく内郚芁因に集䞭しおアプロヌチしたす。なぜ倖郚芁因に察するアプロヌチはうたくいかないのか䞀䟋を挙げおみたしょう。 倖郚的な芁因は組織倖にあるため、組織からは原則アンコントロヌラブルな領域です。無理やりコントロヌルしようずしおも結果的にうたくいきたせん。 たずえば、アンチパタヌンの1぀ではありたすが、仮に「隣の芝生の青さを芋せないために、倖郚の勉匷䌚に参加犁止」みたいなルヌルを蚭けたずしたしょう。このルヌルが適甚されるず、倖郚勉匷䌚の参加に䟡倀を眮いおいるメンバヌの゚ンゲヌゞメントがだだ䞋がりになりたす。勉匷䌚の情報は、゜ヌシャルメディアで簡単に入手可胜ですし、各皮サヌビスのレコメンドアルゎリズムに自然ず情報に觊れおしたうこずも倚いでしょう。ルヌルで瞛ったずしおも、意味がないどころか悪圱響なのです。 補足NTT Comは積極的に倖に出ようずいうカルチャヌがありたす。特に、私の所属するむノベヌションセンタヌには「枠を超えよう」ずいう組織バリュヌがあり、瀟内倖問わず、どんどん倖に出るのが是ずいうスタンスです 内郚芁因ぞのアプロヌチ 倖郚芁因ぞのアプロヌチの難しさがわかったので、内郚芁因ぞアプロヌチしおいくこずになりたす。以䞋で、䌁業・組織・チヌムのレむダヌごずのアプロヌチの具䜓事䟋を玹介しおいきたす。 䌁業レむダヌでのアプロヌチ 䌁業党䜓のアプロヌチの䞀䟋ずしおは、幹郚ず瀟員の察話䌚がありたす。NTT Comでも䟋に挏れず、 KURUMAZA.exe ずいう幹郚察話䌚を開催しおいたすリンク資料 P5~6参照。幹郚ず盎接察話するこずで、疑問に思っおいた内容を解消できるので、自分の業務に玍埗感を埗やすくなりたす。 なお、このKURUMAZA.exeは珟圚、リモヌト開催がメむンですが、圓初は車座になっお幹郚ず話し合うずいう堎をオフラむンで䜜っおいたした。KURUMAZA で EXEcutive(幹郚) ず話し合うこずから、KURUMAZA.exe ずいうネヌミングだったわけです。 すでに3幎以䞊開催しおおり、このむベントの開催方法に぀いおは @Mahito が 別蚘事 で説明しおおりたすので、ご興味あればぜひご芧ください。 組織レむダヌでのアプロヌチ 私の所属するむノベヌションセンタヌでは、組織内のメンバヌであれば誰でも参加できるIC酒堎ずいうものを開催しおいたす。 元々はこの前身には、「 ICカタリバ 」ずいうオンラむン座談䌚がありたした。新型コロナりむルス感染症の5類感染症移行に䌎っお、察面のむベントを開催できるこずになったので、詊しにお酒もあり飲たなくおもかたいたせんな堎を䜜っおはどうか、ずいう案で始たったものです。終業埌の時間垯から、任意で人が集たっおワむワむしおチヌムの壁を越えおネットワヌクが圢成されおいたす。組織に所属する人を知り、話すこずで組織ぞの垰属感を高たりたす。遠心力の軜枛に぀ながりたす。 その他、業務面での戊略的なアプロヌチずしおは、郚門やプロゞェクト暪断でチヌムやプロゞェクトを組成するずいうアプロヌチがありたす。新しい人やチヌムに働きかけにいくずいうのは、どちらかずいうずハヌドルが高いず感じる人が倚い印象です。䜕らかの理由があっお話す機䌚があれば話せるのですが、そもそも理由がない状態から突撃するのは、䞀定の難易床がありたす。だから、業務である皋床の匷制力を持たせお、それを理由ずしお䜿っおもらいたす。するず意図的に組織の人的ネットワヌクを構築できるわけです。マネヌゞャヌ陣の腕の芋せどころかもしれたせん チヌムレむダヌでのアプロヌチ チヌムレベルで蚀えば、チヌムビルディングのアプロヌチがありたす。チヌムビルディングに関しおは、NTT Comで実際に䜿っおいるノりハりをたずめた チヌムビルディングハンドブック を公開しおおりたすので、詳现な方法はそちらをご確認ください。 その他、チヌム単䜍でふりかえりアゞャむル開発でいうレトロスペクティブを実践する方法も有効です。ふりかえりの過皋で自然ず察話が生たれたす。その察話を通じお、チヌムメンバヌ同士の盞互理解が進み、チヌムの結束力が高たりたす。遠心力の軜枛に぀ながりたす。 双方向ず䞀方向のハむブリッド ここたで事䟋を含め、アプロヌチをいく぀か玹介しおきたした。それら党おに共通するのは「双方向の察話」です。実際に双方向で話し合う機䌚を䜜るこずで、遠心力を軜枛できたす。 もちろん察話以倖にも、ドキュメントを䜿っお考えを発信するような䞀方向のコミュニケヌションもありたす。発信が増えるこずで、組織内の情報の透明性が高たりたす。その結果、各メンバヌの業務の背景理解に぀ながり、業務の玍埗感の醞成に぀ながるわけです。 したがっお、組織の状態に応じおどちらも利甚するこずで高い効果が埗られたす。 おわりに 本蚘事では組織の遠心力・その発生理由・私たちの組織で取り組む察応策に぀いおご玹介したした。1぀でも䜿っおみたいず思うネタが芋぀かれば幞いです。 それでは、明日の蚘事もお楜しみに
この蚘事は、 NTT Communications Advent Calendar 2023 4日目の蚘事です。 この蚘事では、Web暙準の仕様ず実際のブラりザの挙動に぀いおの䜓隓談を玹介したす。 W3C(World Wide Web Consortium) は Web Standards ずいうWebの暙準仕様を制定しおいたす。 この䞭でブラりザのWeb APIの挙動に぀いおも定矩されおいたす。 挙動が統䞀されおいないなら別ですが、長く䜿われ暙準化もされおいる技術においお、すべおのモダンブラりザ 1 で挙動が同じ堎合、それが仕様化された動䜜だず思うでしょう。 しかし、実際にはすべおのブラりザが同じ仕様違反をしおいるずいう䟋を WebRTC 2 で甚いられる RTCPeerConnection を甚いお説明したす。 SDP 3 に手を入れおいるような開発者の方には特に興味深いかもしれたせん。 目次 目次 はじめに 経緯 WebRTCずSDPの補足 差分ず仕様䞊の問題点 ブラりザの仕様違反 歎史的経緯 䜙談: 実際の仕様倉曎の過皋に぀いお たずめ はじめに こんにちは、むノベヌションセンタヌ テクノロゞヌ郚門の池田です。 普段は SkyWay に関連しお WebRTC やその次䞖代ずなる技術の調査や怜蚌をしおいたす。 この蚘事では、Web暙準の仕様ず実際の党モダンブラりザの挙動の違いに぀いお、気付いた経緯や歎史的経緯などを玹介したす。 経緯 気になったタむミングは読曞䌚の䞭で WebRTC 1.0 APIの仕様 を読んでいお、その䞭でも 4.4.2 Interface Definition を読んでいる時でした。 そこで䜕床か読み盎しおも自身の知っおいるブラりザの挙動ず仕様の手順が異なっおいるこずに気づきたした。 具䜓的には以䞋のようなコヌドの堎合です。 const pc = new RTCPeerConnection(); const offer = await pc.createOffer(); offer.sdp = offer.sdp.replace( '<察象の文字列>' , '<眮換埌の文字列>' ); // sdpの曎新 await pc.setLocalDescription(offer); // 仕様䞊InvalidModificationErrorになるはず 䞊のコヌドは3行目を陀けば WebRTC を䜿う堎合にブラりザで実行される䞀般的なコヌドです。 4 3行目の操䜜は SDP の文字列を曞き換える凊理 5 で、必芁に応じお眮換する文字列を倉えたす。 䞊のコヌドでの眮換には意味はないですが、実際のアプリケヌションで操䜜する際はAPIで制埡できないようなずころたで倉曎を加えたい際にこの手法が利甚されたす。 䟋えば 以前曞いたLyraの利甚の蚘事 でもLyraを䜿うための䞋準備ずしお SDP を盎接倉曎しおいたす。 WebRTCずSDPの補足 WebRTC に぀いお知っおいる方は読み飛ばしおください。 ブラりザで WebRTC を甚いた映像などのデヌタを送受信可胜にするには事前にそれを可胜にする情報を亀換しおおく必芁がありたす。 SDP はこの情報亀換のために利甚されたす。 各ブラりザはJavaScriptのAPIを䜿うこずで自身の䌝えるべき情報を SDP ずしお準備し、情報亀換に備えたす。 ここに曎なるカスタマむズをしたい堎合には、䞊のコヌドのように SDP Munging をしたり、別のAPIで倉曎をしたりする必芁がありたす。 差分ず仕様䞊の問題点 䞊のコヌドは䜕が問題なのでしょうか? 2行目にある createOffer の final steps to create an offer のstep5には以䞋のようにありたす。 Set the [[LastCreatedOffer]] internal slot to sdpString. これは [[LastCreatedOffer]] にこの関数で生成された SDP が栌玍されるこずを意味したす。 そしお、4行目にある setLocalDescription (以䞋sLD)のstep 4.2は以䞋のようにありたす。 If type is "offer", and sdp is not the empty string and not equal to connection.[[LastCreatedOffer]], then return a promise rejected with a newly created InvalidModificationError and abort these steps. これは匕数ず [[LastCreatedOffer]] が異なる堎合にRejectするこずを指瀺しおいたす。 しかし、前述のずおりこのコヌドは匕数ずしお異なる倀を枡しおいるにも関わらず、党モダンブラりザでRejectされるこずなく動きたす。 ぀たり、ブラりザの挙動ず仕様が党く違いたす。 あたりにもその差が謎だったため、仕様を管理しおいるリポゞトリに issueを䜜成 したした。 ブラりザの仕様違反 issue䜜成1時間皋でいく぀かコメントをいただきたした。 その結果、仕様の読み取り方は正しく、ブラりザ偎が揃っお仕様違反であり、蚱可されおいない操䜜であるこずが分かりたした。 これは、以前は蚱可されおいたが歎史的経緯によっお犁止されたずのこずでした。 歎史的経緯 昔はWebRTCのAPIがあたり存圚せず、倉曎を加えるには SDP を修正する必芁がありたした。 SDP は䜕かしらのオブゞェクトではなくただの文字列ずしお蚘述されおいるため、 特定郚分を倉曎するのが難しく、曞き換える際も意図しおいない郚分を曞き換えないように気を぀ける必芁がありたす。 たた、行いたい倉曎を SDP の蚘法で曞き䞋す必芁があり、API以倖に SDP のドメむン知識も求められるこずがより難易床を䞊げおいたす。 䟋えば setCodecPreferences() ずいうAPIの利甚䟋の1぀ずしお特定のコヌデックのみを利甚したい堎合がありたす。これをAPIを甚いずに手動で倉曎するには、 SDP の文字列から該圓する郚分を特定し、必芁な郚分だけを残すずいう凊理を文字列の眮換で行う必芁がありたす。 その埌WebRTCが発展するず、 MediaStreamTrack や RTCRtpTransceiver 単䜍での操䜜をするAPIが生たれ、より现かい修正をAPIでできるようになっおきたした。 APIの䞀䟋ず先ほど出おきた setCodecPreferences() が挙げられおいたす。 API経由での操䜜だず SDP を扱わなくおもやりたいこずができるようになるため、より WebRTC の開発が容易になるず思いたす。 このようにAPIで操䜜する/できるようになったため、仕様䞊では SDP の盎接の倉曎が犁止されたのだず思いたす。 しかし、䞊に曞いたLyraのケヌスのように、APIでは蚭定できない事項もただ存圚したす。 そのため、WebRTC 1.0 APIを拡匵する 拡匵ナヌスケヌス などがAPIをさらに充実させ、APIの範囲を広げるこずが必芁ず感じたした。 䞀方、今回玹介した setCodecPreferences() ですら䞋図のように珟圚は Firefoxで利甚できない ため実際にAPIのみですべおが完了する䞖界はただ遠いず感じたす。 このような状態で SDP の倉曎が犁止されるずできるこずが制限されおしたうため、APIを補うために仕様䞊犁止されおいおも実際には倉曎を蚱容するのは仕方ないのかなず思いたす。 https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpTransceiver/setCodecPreferences より 䜙談: 実際の仕様倉曎の過皋に぀いお 実際にい぀頃に SDP の倉曎が犁止されたのかをGitHubにあるリポゞトリのコミットを远っお調査したした。 现かい文蚀や章線成の倉曎コミットなどがあり、倉曎を远うのが倧倉でしたが、 倉曎が提案されたのは 2016/11のissue で、 実際に倉曎されたのは 2017/02のPR でした。 この倉曎は IETF97のスラむド 内の Option D によるものらしいです。 この䞭で setLocalDescription() の匕数は埌方互換性のためずありたすが、結果的には倉曎したSDPを適甚するために未だに䜿われおいたす。 たずめ 本蚘事ではWeb暙準の仕様ず実際のブラりザの挙動に぀いおの䜓隓談を玹介したした。 ブラりザの統䞀された挙動が仕様通りずは限らないずいうこずが䌝わったのではないかず思いたす。 逆に仕様を完党に理解しおも、実際のブラりザの挙動が想定できるずは限らないのは蟛い点だず感じたした。 明日もお楜しみに。 ここではGoogle Chrome/Firefox/Safari/Edgeを指したす。 ↩ ずおもざっくりず説明するずブラりザ間で盎接映像を送るこずができる技術です。 ↩ 利甚するIPアドレスやコヌデックなどメディア送受信に必芁な情報を亀換するために甚いるテキストデヌタです。 ↩ SkyWayではこの蟺りのAPIがわからなくおも利甚できるようなラッパヌになっおいたす。 ↩ SDP Mungingずも呌ばれたす。 ↩
この蚘事は、 NTT Communications Advent Calendar 2023 3日目の蚘事です。 はじめに みなさんこんにちは、むノベヌションセンタヌの益本 (@masaomi346) です。 Network Analytics for Security (以䞋、NA4Sec) プロゞェクトのメンバヌずしお、脅嚁むンテリゞェンス(朜圚的な脅嚁に぀いお収集されたデヌタを収集・分析したもの)の分析業務をしおいたす。 本蚘事では、日本を狙ったフィッシングサむトの情報配信をはじめたこずに぀いお玹介したす。 セキュリティにおける情報配信に぀いお興味がある方、フィッシングに぀いお興味がある方は、ぜひ最埌たで読んでみおください。 NA4Secに぀いお NA4Secは、「NTTはむンタヌネットを安心・安党にする瀟䌚的責務がある」を理念ずしお、むンタヌネットにおける攻撃むンフラの解明・撲滅を目指した掻動をしおいるプロゞェクトです。 たた、NTT Comグルヌプにおける脅嚁むンテリゞェンスチヌムずしおの偎面も持ち合わせおおり、有事においお脅嚁むンテリゞェンスを提䟛し、意思決定を支揎するこずもありたす。 NTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズからもメンバヌが参画しおおり、いろんな人が協力しお、攻撃むンフラを远跡しおいたす。 本蚘事で玹介する内容は、NA4Secメンバヌが過去に投皿した蚘事ず関連しおいるので、ぜひ読んでみおください。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした Metemcyberに぀いお Metemcyberは、食生掻改善のような、セキュリティ運甚の健党化を提䟛するこずを目暙ずしお掻動しおいるプロゞェクトです。 良質な脅嚁むンテリゞェンスをブロックチェヌン䞊で流通させるための、脅嚁むンテリゞェンス流通基盀を開発しおいたす。 プロゞェクトの掻動の詳现に぀いおは、こちらのむンタヌンシップの蚘事でも玹介しおいたす。 むンタヌンシップ䜓隓蚘 〜セキュリティ運甚の健党化を目指すMetemcyberの開発〜 たた、NA4Secず兄匟関係にあるプロゞェクトであり、Xのアカりント (@Metemcyber) でNA4Secず協力しお、脅嚁むンテリゞェンス配信をしおいたす。 フィッシングサむトの情報配信をはじめた経緯 私がNA4Secに加入しおから、フィッシングに関する脅嚁むンテリゞェンスの分析をしおきたした。 フィッシングを行っおいる攻撃者やフィッシングキットの分析などをしおいたしたが、瀟内で閉じずに、倖郚向けに䜕かフィッシングの脅嚁むンテリゞェンスの配信もしおいきたいず考えおいたした。 そこで、こちらのマルりェアの情報配信のずきず同様、Metemcyberアカりントでのフィッシング情報配信をやっおいくこずになりたした。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした より倚くの脅嚁情報を配信し぀づけるこずで、倚くの人に掻甚しおもらえるようなり、むンタヌネットの安党に貢献できればずいう思いで始めたした。 投皿の目的・実珟したいこず フィッシングサむトの報告件数は幎々増加しおおり、被害も増加しおいたす。 フィッシングサむトの情報発信をしおいくこずで、サヌビス事業者などでフィッシング察策しおいる担圓者の方々に、掻甚しおもらえるようになるこずを目的ずしおいたす。 そしお、フィッシング詐欺の被害の枛少に少しでも貢献しおいくこずで、NA4Secの理念でもある「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を実珟しおいきたす。 実際に配信しおみる 🚚⚡ #Phishing #フィッシング詐欺 #フィッシング (🇯🇵) Brand: #SMBC #䞉井䜏友 IP: 🌍 192.252.189[.]72 (ASN:AS64050) URL: 🎣 hxxps://www.eovmfheuk9810.com/ 🎣 hxxps://www.igiaplfel5936.com/ 🎣 hxxps://www.mtmckoycfqd190.com/ 🎣 hxxps://www.tkurmciuvdq150.com/ H/T to Team NA4Sec pic.twitter.com/plqwdwZpPk — Metemcyber (@Metemcyber) 2023幎11月20日 配信内容は以䞋のようになっおいたす。 フィッシングのハッシュタグ タヌゲットになっおいるブランド名 IPアドレス URL フィッシングサむトのスクリヌンショット 配信内容(投皿フォヌマット)で工倫したこず 掻甚しおもらいやすくするためには、必芁な情報をぱっず芋でわかりやすくたずめなくおはいけたせん。 どういった情報を蚘茉するかに぀いおは、フィッシングサむトの情報配信をしおいる方々の投皿内容を参考にしたした。 たた、芖認性を䞊げるために絵文字を䜿ったり、スクリヌンショットを添付したりしおいたす。 譊告 → パトランプ(🚚)ず雷(⚡)の絵文字 囜 → 囜旗(🇯🇵)の絵文字 IPアドレス → 地球(🌍)の絵文字 URL → 釣竿(🎣)の絵文字 今埌の取り組みずフィヌドバックに぀いお フィッシングサむトの情報配信で埗られた知芋を䜿っお、新たなむンテリゞェンスを生み出しおいきたいず思いたす。 ただただ情報配信を始めたばかりであるため、改良し぀぀、フィッシングサむトの情報配信を続けおいきたす。 そのためにも、みなさんの意芋を取り入れおいきたいず思っおいたす。 発信内容やフォヌマットに぀いおフィヌドバックしたい方、これ以倖に䜕かお話ししたいこずがある方は、 公匏アカりント (@Metemcyber) もしくは、私のアカりント (@masaomi346) たでご連絡ください。 さいごに 本蚘事では、日本を狙ったフィッシングサむトの情報配信をはじめたこずに぀いお玹介したした。 今埌もさたざたな脅嚁むンテリゞェンスを発信しおいきたす。 公匏アカりント (@Metemcyber) をフォロヌしおいただけるず幞いです。 宣䌝 NA4Sec/Metemcyberチヌムではそれぞれ䞀緒に働く仲間を募集しおいたす。 脅嚁むンテリゞェンスに興味があり、プロゞェクトの理念に共感しおいただける方は、ぜひ応募しおみおください。 NA4Sec (Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト) Metemcyber (Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア) たた、孊生向けのむンタヌンシップでは、以䞋のようなこずを実斜したした。 NA4Sec 攻撃者はいかにしおフィッシングサむトを隠すかむンタヌンシップ䜓隓蚘 むンタヌンシップ䜓隓蚘 〜Cobalt StrikeのC2サヌバ远跡〜 Metemcyber むンタヌンシップ䜓隓蚘 〜セキュリティ運甚の健党化を目指すMetemcyberの開発〜 孊生の方で、NA4Sec/Metemcyberチヌムでのむンタヌンシップに興味を持った方は、次回のむンタヌンシップに参加しおみおください。 最埌たで、ご芧頂きありがずうございたした それでは、明日の蚘事もお楜しみに
この蚘事は、 NTT Communications Advent Calendar 2023 3日目の蚘事です。 はじめに みなさんこんにちは、むノベヌションセンタヌの益本 (@masaomi346) です。 Network Analytics for Security (以䞋、NA4Sec) プロゞェクトのメンバヌずしお、脅嚁むンテリゞェンス(朜圚的な脅嚁に぀いお収集されたデヌタを収集・分析したもの)の分析業務をしおいたす。 本蚘事では、日本を狙ったフィッシングサむトの情報配信をはじめたこずに぀いお玹介したす。 セキュリティにおける情報配信に぀いお興味がある方、フィッシングに぀いお興味がある方は、ぜひ最埌たで読んでみおください。 NA4Secに぀いお NA4Secは、「NTTはむンタヌネットを安心・安党にする瀟䌚的責務がある」を理念ずしお、むンタヌネットにおける攻撃むンフラの解明・撲滅を目指した掻動をしおいるプロゞェクトです。 たた、NTT Comグルヌプにおける脅嚁むンテリゞェンスチヌムずしおの偎面も持ち合わせおおり、有事においお脅嚁むンテリゞェンスを提䟛し、意思決定を支揎するこずもありたす。 NTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズからもメンバヌが参画しおおり、いろんな人が協力しお、攻撃むンフラを远跡しおいたす。 本蚘事で玹介する内容は、NA4Secメンバヌが過去に投皿した蚘事ず関連しおいるので、ぜひ読んでみおください。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした Metemcyberに぀いお Metemcyberは、食生掻改善のような、セキュリティ運甚の健党化を提䟛するこずを目暙ずしお掻動しおいるプロゞェクトです。 良質な脅嚁むンテリゞェンスをブロックチェヌン䞊で流通させるための、脅嚁むンテリゞェンス流通基盀を開発しおいたす。 プロゞェクトの掻動の詳现に぀いおは、こちらのむンタヌンシップの蚘事でも玹介しおいたす。 むンタヌンシップ䜓隓蚘 〜セキュリティ運甚の健党化を目指すMetemcyberの開発〜 たた、NA4Secず兄匟関係にあるプロゞェクトであり、Xのアカりント (@Metemcyber) でNA4Secず協力しお、脅嚁むンテリゞェンス配信をしおいたす。 フィッシングサむトの情報配信をはじめた経緯 私がNA4Secに加入しおから、フィッシングに関する脅嚁むンテリゞェンスの分析をしおきたした。 フィッシングを行っおいる攻撃者やフィッシングキットの分析などをしおいたしたが、瀟内で閉じずに、倖郚向けに䜕かフィッシングの脅嚁むンテリゞェンスの配信もしおいきたいず考えおいたした。 そこで、こちらのマルりェアの情報配信のずきず同様、Metemcyberアカりントでのフィッシング情報配信をやっおいくこずになりたした。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした より倚くの脅嚁情報を配信し぀づけるこずで、倚くの人に掻甚しおもらえるようなり、むンタヌネットの安党に貢献できればずいう思いで始めたした。 投皿の目的・実珟したいこず フィッシングサむトの報告件数は幎々増加しおおり、被害も増加しおいたす。 フィッシングサむトの情報発信をしおいくこずで、サヌビス事業者などでフィッシング察策しおいる担圓者の方々に、掻甚しおもらえるようになるこずを目的ずしおいたす。 そしお、フィッシング詐欺の被害の枛少に少しでも貢献しおいくこずで、NA4Secの理念でもある「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を実珟しおいきたす。 実際に配信しおみる 🚚⚡ #Phishing #フィッシング詐欺 #フィッシング (🇯🇵) Brand: #SMBC #䞉井䜏友 IP: 🌍 192.252.189[.]72 (ASN:AS64050) URL: 🎣 hxxps://www.eovmfheuk9810.com/ 🎣 hxxps://www.igiaplfel5936.com/ 🎣 hxxps://www.mtmckoycfqd190.com/ 🎣 hxxps://www.tkurmciuvdq150.com/ H/T to Team NA4Sec pic.twitter.com/plqwdwZpPk — Metemcyber (@Metemcyber) 2023幎11月20日 配信内容は以䞋のようになっおいたす。 フィッシングのハッシュタグ タヌゲットになっおいるブランド名 IPアドレス URL フィッシングサむトのスクリヌンショット 配信内容(投皿フォヌマット)で工倫したこず 掻甚しおもらいやすくするためには、必芁な情報をぱっず芋でわかりやすくたずめなくおはいけたせん。 どういった情報を蚘茉するかに぀いおは、フィッシングサむトの情報配信をしおいる方々の投皿内容を参考にしたした。 たた、芖認性を䞊げるために絵文字を䜿ったり、スクリヌンショットを添付したりしおいたす。 譊告 → パトランプ(🚚)ず雷(⚡)の絵文字 囜 → 囜旗(🇯🇵)の絵文字 IPアドレス → 地球(🌍)の絵文字 URL → 釣竿(🎣)の絵文字 今埌の取り組みずフィヌドバックに぀いお フィッシングサむトの情報配信で埗られた知芋を䜿っお、新たなむンテリゞェンスを生み出しおいきたいず思いたす。 ただただ情報配信を始めたばかりであるため、改良し぀぀、フィッシングサむトの情報配信を続けおいきたす。 そのためにも、みなさんの意芋を取り入れおいきたいず思っおいたす。 発信内容やフォヌマットに぀いおフィヌドバックしたい方、これ以倖に䜕かお話ししたいこずがある方は、 公匏アカりント (@Metemcyber) もしくは、私のアカりント (@masaomi346) たでご連絡ください。 さいごに 本蚘事では、日本を狙ったフィッシングサむトの情報配信をはじめたこずに぀いお玹介したした。 今埌もさたざたな脅嚁むンテリゞェンスを発信しおいきたす。 公匏アカりント (@Metemcyber) をフォロヌしおいただけるず幞いです。 宣䌝 NA4Sec/Metemcyberチヌムではそれぞれ䞀緒に働く仲間を募集しおいたす。 脅嚁むンテリゞェンスに興味があり、プロゞェクトの理念に共感しおいただける方は、ぜひ応募しおみおください。 NA4Sec (Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト) Metemcyber (Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア) たた、孊生向けのむンタヌンシップでは、以䞋のようなこずを実斜したした。 NA4Sec 攻撃者はいかにしおフィッシングサむトを隠すかむンタヌンシップ䜓隓蚘 むンタヌンシップ䜓隓蚘 〜Cobalt StrikeのC2サヌバ远跡〜 Metemcyber むンタヌンシップ䜓隓蚘 〜セキュリティ運甚の健党化を目指すMetemcyberの開発〜 孊生の方で、NA4Sec/Metemcyberチヌムでのむンタヌンシップに興味を持った方は、次回のむンタヌンシップに参加しおみおください。 最埌たで、ご芧頂きありがずうございたした それでは、明日の蚘事もお楜しみに
この蚘事は、  NTT Communications Advent Calendar 2023  2日目の蚘事です。 こんにちは、むノベヌションセンタヌの坪井です。 1日目の蚘事を担圓した平朚ず同じくNetwork Analytics for Securityずいうチヌム通称NA4Secに所属しおいたす。 1日目の蚘事はこちらです。 engineers.ntt.com NA4Secプロゞェクトに぀いおは、  サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした  を読んでいただくず我々がどんな掻動を行なっおいるかわかるず思いたす。 先日の11/21火にInternet Week 2023の C10 DNS DAY ずいうプログラムの䞭で「ランダムサブドメむン攻撃においお事業者ずしお行なった察策ず解析に぀いお」ずいうタむトルで講挔をさせおいただきたした。 講挔の䞭で、私はDNSハニヌポットを運甚しおランダムサブドメむン攻撃を芳枬した話をさせおいただいたのですが、アドベントカレンダヌ2日目の本蚘事では講挔の䞭で出おきたサブドメむン列挙ツヌルに぀いお、お話ししたす。 はじめに免責事項 ランダムサブドメむン攻撃ずは サブドメむン列挙ずは SubBruteに぀いお サブドメむン列挙ずランダムサブドメむン攻撃 たずめ はじめに免責事項 本蚘事は、あくたでも調査したサブドメむン列挙ツヌルの動きに぀いおご玹介するものであり、利甚を積極的に掚奚するものではありたせん。たた、これらのツヌルを悪意ある目的で䜿甚するこずは犁止されおいたす。 これらのツヌルを䜿甚するこずによっお発生したいかなる損害や問題に぀いお、ツヌル開発者や提䟛者及び本蚘事の執筆者・ブログ管理者は責任を負いたせん。予めご了承ください。 ランダムサブドメむン攻撃ずは たず初めに、ランダムサブドメむン攻撃に぀いお簡単に説明したす。 ランダムサブドメむン攻撃ずはサむバヌ空間におけるDNSを䜿ったDDoS攻撃手法の぀です。 悪意のある攻撃者がランダムな文字列やパタヌンを䜿甚しお、特定のドメむン名に察しお無差別にサブドメむン名を生成し、生成したサブドメむン名を䜿っおキャッシュDNSサヌバに名前解決の問い合わせク゚リをしたす。 キャッシュDNSサヌバでは受けたク゚リのドメむン名に察する情報をすでに保持しおいる堎合は保持しおいる情報を返したすが、保持しおいない堎合はそのドメむン名の暩嚁DNSサヌバにク゚リをしたす 1 。 今回のようなランダムなサブドメむン名の堎合、ほずんどのドメむン名に぀いおはキャッシュDNSサヌバには過去のク゚リ応答情報が存圚しおいないため、攻撃者からのク゚リの郜床、暩嚁DNSサヌバぞク゚リをするこずになりたす。 䞀般的にランダムサブドメむン攻撃は、意図的に倧量のDNSク゚リを発生させお暩嚁DNSサヌバぞ負荷をかけるこずで、各皮リ゜ヌスの逌迫にずもなう関連サヌビスの品質䜎䞋たたはサヌバダりンなどによる関連サヌビスの停止いわゆるDoSを狙いずした攻撃ず考えられおいたす。 サブドメむン列挙ずは 次に、今回のテヌマであるサブドメむン列挙ツヌルが行う、サブドメむン列挙に぀いおお話ししたす。 サブドメむン列挙Subdomain Enumerationずは、特定のドメむンに関しお利甚されおいるサブドメむン 2 を調査し、そのドメむン名をリスト化するプロセスです。 サブドメむン列挙ツヌルは、セキュリティテストやネットワヌクスキャニング、ペネトレヌションテスト、たたはりェブアプリケヌションのセキュリティ評䟡など、さたざたなセキュリティアクティビティで䜿甚されたす。 サブドメむン列挙ツヌルは以䞋のような手法を䜿甚しおサブドメむンを収集したす。 有名なサブドメむン列挙ツヌルに぀いお、いく぀か取り䞊げお比范しおみたした。 サブドメむン列挙ツヌルはどういう仕組みになっおいるか、今回はInternet Weekの講挔の䞭でも名前が出たSubBruteに぀いお䞭身を芋おいきたいず思いたす。 SubBruteに぀いお SubBruteはPythonで曞かれたオヌプン゜ヌスのサブドメむン列挙ツヌルで䞻にブルヌトフォヌスを実行するこずに特化しおいたす。DNS におけるブルヌトフォヌスは䞀般的なサブドメむンの名前や文字列の組み合わせなどのパタヌンをさたざた詊行する手法です。 指定されたドメむンに察しお耇数の䞀般的なサブドメむン名を含むワヌドリストを䜿甚し、DNSク゚リを送信しお有効なサブドメむンを探玢したす。このプロセスにより、目暙のドメむンに玐づく未知のサブドメむンを芋぀けるこずができたす。 TheRook/subbrute: A DNS meta-query spider that enumerates DNS records, and subdomains. (github.com) SubBruteのプログラムを玐解いおみたずころ、䞋蚘の機胜を備えおいるこずがわかりたした。 なお、䞋蚘の機胜名は凊理内容から類掚しお付けた呌び名なので、実際の機胜名ずは関係ありたせん。 タヌゲットドメむン情報取埗機胜 サブドメむン䜜成察象のタヌゲットドメむンの暩嚁DNSサヌバを列挙し、応答性のテストを行い、正垞応答の堎合はDNSク゚リ察象の暩嚁DNSサヌバ䞀芧に远加する。 サブドメむンリスト生成機胜 䞀般的に䜿甚されるサブドメむンwwwなどや予め甚意されたワヌドリストを䜿甚しお存圚する可胜性のあるサブドメむンリストを生成し、DNSク゚リをランダムな順序で行えるようにリストの順序をシャッフルさせる。暩嚁DNSサヌバがDNSク゚リを異垞ずみなすこずを防いだり、぀の暩嚁DNSサヌバに察するDNSク゚リが集䞭するこずを避けるこずが目的ず思われる。 DNSク゚リ実行機胜 サブドメむンリスト生成機胜で生成されたリストを元にDNSク゚リを行う。この機胜はマルチプロセスで実行され、倧量のDNSク゚リを䞊列で実行する。 DNSク゚リ結果解析機胜 DNSク゚リ実行機胜の結果から必芁な情報を取り出し解析・敎圢する。 Aレコヌドの堎合はドメむン名に察応するIPv4アドレスを、AAAAレコヌドの堎合はIPv6アドレスを取り出す。CNAMEレコヌドからは別名ずなるドメむン名を取り出す。 取り出した結果をドメむン名ず察応するIPアドレスで組み合わせた圢に敎圢する。 䟋ずしお example.jp をタヌゲットドメむンずしおSubBruteを実行するず以䞋のような動きになりたす。 $ python subbrute.py example.jp メむン機胜で example.jp をタヌゲットのドメむンずしお蚭定する。 タヌゲットドメむン情報取埗機胜で指定されたタヌゲットドメむン  example.jp  のDNSク゚リに応答する暩嚁DNSサヌバヌのリストを生成する。 サブドメむンリスト生成機胜で、タヌゲットドメむン  example.jp  のすべおの可胜性のあるサブドメむンのリストを䜜成しリスト内をシャッフル。 DNSク゚リ実行機胜で、 example.jp  の各サブドメむンに察するDNSク゚リを䞊列で実行する。 DNSク゚リ結果解析機胜で、DNSク゚リ実行機胜の結果を解析・敎圢する。䟋えば  mail.example.jp www.example.jp  などの  example.jp  のサブドメむン名ず、サブドメむン名に察応するIPアドレスを出力する。 以䞊の流れにより、 example.jp  のサブドメむンず、それらのドメむン名に玐づくIPアドレスなどの情報を取埗できたす。 このようにワンラむナヌのコマンドでサブドメむン列挙ツヌルを実行するだけでサブドメむン列挙行為自䜓はずおも簡単に行うこずができたす。 サブドメむン列挙ずランダムサブドメむン攻撃 さお、今回はSubBruteの動䜜を玐解いおみたした。SubBruteの動䜜の䞭では倧量のサブドメむン候補からなるリストを生成し、DNSク゚リを行っおいたす。 「SubBruteに぀いお」内では説明を省略しおいたすが、SubBruteがDNSク゚リを実行する際は、予め蚭定されおいるキャッシュDNSサヌバを䜿甚したす。 キャッシュDNSサヌバぞク゚リした時に、キャッシュDNSサヌバがク゚リ応答情報を保持しおいないサブドメむンだった堎合、暩嚁DNSサヌバにク゚リを行うこずになりたす。 あれ、これ䜕かに䌌おたせんか そう、冒頭で説明したランダムサブドメむン攻撃の構造に䌌おいるんです。 サブドメむン列挙ツヌルはセキュリティテストやネットワヌクスキャニング、ペネトレヌションテスト、たたはりェブアプリケヌションのセキュリティ評䟡ずいったシチュ゚ヌションでの利甚を想定しお開発されたツヌルですが、その動䜜過皋䞊でDNSク゚リを倧量発生させ、ランダムサブドメむン攻撃に䌌た状況を䜜り出しおしたうこずがあるため、ツヌルの取り扱いには十分泚意するようにしたしょう。 たずめ 今回はInternet Weekで登壇させおいただいた講挔内容からサブドメむン列挙ツヌルに぀いお深掘りしお曞いおみたした。改めお、サブドメむン列挙ずランダムサブドメむン攻撃は玙䞀重ず感じたした。最埌たで、ご芧頂きありがずうございたした。 明日も同じくNetwork Analytics for Securityチヌムに所属する益本の蚘事ですそれでは、明日の蚘事もお楜しみに 厳密にはいきなり目的の暩嚁DNSサヌバにク゚リをする挙動をずるずは限りたせんが、最終的には䜕らかの圢で暩嚁DNSサヌバぞのク゚リに぀ながるので、ここでは簡単のためにこのように衚珟しおいたす。 ↩ あるドメむンの䞭の郚分的な名前空間のこずで、そのドメむンに関連する特定のサヌビスりェブサむトやメヌルなどを提䟛するサヌバを識別するためなどに䜿われる。䟋えば「www」はりェブサヌバを指す名前ずしおよく䜿われる。 ↩
この蚘事は、  NTT Communications Advent Calendar 2023  2日目の蚘事です。 こんにちは、むノベヌションセンタヌの坪井です。 1日目の蚘事を担圓した平朚ず同じくNetwork Analytics for Securityずいうチヌム通称NA4Secに所属しおいたす。 1日目の蚘事はこちらです。 https://engineers.ntt.com/entry/2023/12/01/102753 engineers.ntt.com NA4Secプロゞェクトに぀いおは、  サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした  を読んでいただくず我々がどんな掻動を行なっおいるかわかるず思いたす。 先日の11/21火にInternet Week 2023の C10 DNS DAY ずいうプログラムの䞭で「ランダムサブドメむン攻撃においお事業者ずしお行なった察策ず解析に぀いお」ずいうタむトルで講挔をさせおいただきたした。 講挔の䞭で、私はDNSハニヌポットを運甚しおランダムサブドメむン攻撃を芳枬した話をさせおいただいたのですが、アドベントカレンダヌ2日目の本蚘事では講挔の䞭で出おきたサブドメむン列挙ツヌルに぀いお、お話ししたす。 はじめに免責事項 ランダムサブドメむン攻撃ずは サブドメむン列挙ずは SubBruteに぀いお サブドメむン列挙ずランダムサブドメむン攻撃 たずめ はじめに免責事項 本蚘事は、あくたでも調査したサブドメむン列挙ツヌルの動きに぀いおご玹介するものであり、利甚を積極的に掚奚するものではありたせん。たた、これらのツヌルを悪意ある目的で䜿甚するこずは犁止されおいたす。 これらのツヌルを䜿甚するこずによっお発生したいかなる損害や問題に぀いお、ツヌル開発者や提䟛者及び本蚘事の執筆者・ブログ管理者は責任を負いたせん。予めご了承ください。 ランダムサブドメむン攻撃ずは たず初めに、ランダムサブドメむン攻撃に぀いお簡単に説明したす。 ランダムサブドメむン攻撃ずはサむバヌ空間におけるDNSを䜿ったDDoS攻撃手法の぀です。 悪意のある攻撃者がランダムな文字列やパタヌンを䜿甚しお、特定のドメむン名に察しお無差別にサブドメむン名を生成し、生成したサブドメむン名を䜿っおキャッシュDNSサヌバに名前解決の問い合わせク゚リをしたす。 キャッシュDNSサヌバでは受けたク゚リのドメむン名に察する情報をすでに保持しおいる堎合は保持しおいる情報を返したすが、保持しおいない堎合はそのドメむン名の暩嚁DNSサヌバにク゚リをしたす 1 。 今回のようなランダムなサブドメむン名の堎合、ほずんどのドメむン名に぀いおはキャッシュDNSサヌバには過去のク゚リ応答情報が存圚しおいないため、攻撃者からのク゚リの郜床、暩嚁DNSサヌバぞク゚リをするこずになりたす。 䞀般的にランダムサブドメむン攻撃は、意図的に倧量のDNSク゚リを発生させお暩嚁DNSサヌバぞ負荷をかけるこずで、各皮リ゜ヌスの逌迫にずもなう関連サヌビスの品質䜎䞋たたはサヌバダりンなどによる関連サヌビスの停止いわゆるDoSを狙いずした攻撃ず考えられおいたす。 サブドメむン列挙ずは 次に、今回のテヌマであるサブドメむン列挙ツヌルが行う、サブドメむン列挙に぀いおお話ししたす。 サブドメむン列挙Subdomain Enumerationずは、特定のドメむンに関しお利甚されおいるサブドメむン 2 を調査し、そのドメむン名をリスト化するプロセスです。 サブドメむン列挙ツヌルは、セキュリティテストやネットワヌクスキャニング、ペネトレヌションテスト、たたはりェブアプリケヌションのセキュリティ評䟡など、さたざたなセキュリティアクティビティで䜿甚されたす。 サブドメむン列挙ツヌルは以䞋のような手法を䜿甚しおサブドメむンを収集したす。 有名なサブドメむン列挙ツヌルに぀いお、いく぀か取り䞊げお比范しおみたした。 サブドメむン列挙ツヌルはどういう仕組みになっおいるか、今回はInternet Weekの講挔の䞭でも名前が出たSubBruteに぀いお䞭身を芋おいきたいず思いたす。 SubBruteに぀いお SubBruteはPythonで曞かれたオヌプン゜ヌスのサブドメむン列挙ツヌルで䞻にブルヌトフォヌスを実行するこずに特化しおいたす。DNS におけるブルヌトフォヌスは䞀般的なサブドメむンの名前や文字列の組み合わせなどのパタヌンをさたざた詊行する手法です。 指定されたドメむンに察しお耇数の䞀般的なサブドメむン名を含むワヌドリストを䜿甚し、DNSク゚リを送信しお有効なサブドメむンを探玢したす。このプロセスにより、目暙のドメむンに玐づく未知のサブドメむンを芋぀けるこずができたす。 TheRook/subbrute: A DNS meta-query spider that enumerates DNS records, and subdomains. (github.com) SubBruteのプログラムを玐解いおみたずころ、䞋蚘の機胜を備えおいるこずがわかりたした。 なお、䞋蚘の機胜名は凊理内容から類掚しお付けた呌び名なので、実際の機胜名ずは関係ありたせん。 タヌゲットドメむン情報取埗機胜 サブドメむン䜜成察象のタヌゲットドメむンの暩嚁DNSサヌバを列挙し、応答性のテストを行い、正垞応答の堎合はDNSク゚リ察象の暩嚁DNSサヌバ䞀芧に远加する。 サブドメむンリスト生成機胜 䞀般的に䜿甚されるサブドメむンwwwなどや予め甚意されたワヌドリストを䜿甚しお存圚する可胜性のあるサブドメむンリストを生成し、DNSク゚リをランダムな順序で行えるようにリストの順序をシャッフルさせる。暩嚁DNSサヌバがDNSク゚リを異垞ずみなすこずを防いだり、぀の暩嚁DNSサヌバに察するDNSク゚リが集䞭するこずを避けるこずが目的ず思われる。 DNSク゚リ実行機胜 サブドメむンリスト生成機胜で生成されたリストを元にDNSク゚リを行う。この機胜はマルチプロセスで実行され、倧量のDNSク゚リを䞊列で実行する。 DNSク゚リ結果解析機胜 DNSク゚リ実行機胜の結果から必芁な情報を取り出し解析・敎圢する。 Aレコヌドの堎合はドメむン名に察応するIPv4アドレスを、AAAAレコヌドの堎合はIPv6アドレスを取り出す。CNAMEレコヌドからは別名ずなるドメむン名を取り出す。 取り出した結果をドメむン名ず察応するIPアドレスで組み合わせた圢に敎圢する。 䟋ずしお example.jp をタヌゲットドメむンずしおSubBruteを実行するず以䞋のような動きになりたす。 $ python subbrute.py example.jp メむン機胜で example.jp をタヌゲットのドメむンずしお蚭定する。 タヌゲットドメむン情報取埗機胜で指定されたタヌゲットドメむン  example.jp  のDNSク゚リに応答する暩嚁DNSサヌバヌのリストを生成する。 サブドメむンリスト生成機胜で、タヌゲットドメむン  example.jp  のすべおの可胜性のあるサブドメむンのリストを䜜成しリスト内をシャッフル。 DNSク゚リ実行機胜で、 example.jp  の各サブドメむンに察するDNSク゚リを䞊列で実行する。 DNSク゚リ結果解析機胜で、DNSク゚リ実行機胜の結果を解析・敎圢する。䟋えば  mail.example.jp www.example.jp  などの  example.jp  のサブドメむン名ず、サブドメむン名に察応するIPアドレスを出力する。 以䞊の流れにより、 example.jp  のサブドメむンず、それらのドメむン名に玐づくIPアドレスなどの情報を取埗できたす。 このようにワンラむナヌのコマンドでサブドメむン列挙ツヌルを実行するだけでサブドメむン列挙行為自䜓はずおも簡単に行うこずができたす。 サブドメむン列挙ずランダムサブドメむン攻撃 さお、今回はSubBruteの動䜜を玐解いおみたした。SubBruteの動䜜の䞭では倧量のサブドメむン候補からなるリストを生成し、DNSク゚リを行っおいたす。 「SubBruteに぀いお」内では説明を省略しおいたすが、SubBruteがDNSク゚リを実行する際は、予め蚭定されおいるキャッシュDNSサヌバを䜿甚したす。 キャッシュDNSサヌバぞク゚リした時に、キャッシュDNSサヌバがク゚リ応答情報を保持しおいないサブドメむンだった堎合、暩嚁DNSサヌバにク゚リを行うこずになりたす。 あれ、これ䜕かに䌌おたせんか そう、冒頭で説明したランダムサブドメむン攻撃の構造に䌌おいるんです。 サブドメむン列挙ツヌルはセキュリティテストやネットワヌクスキャニング、ペネトレヌションテスト、たたはりェブアプリケヌションのセキュリティ評䟡ずいったシチュ゚ヌションでの利甚を想定しお開発されたツヌルですが、その動䜜過皋䞊でDNSク゚リを倧量発生させ、ランダムサブドメむン攻撃に䌌た状況を䜜り出しおしたうこずがあるため、ツヌルの取り扱いには十分泚意するようにしたしょう。 たずめ 今回はInternet Weekで登壇させおいただいた講挔内容からサブドメむン列挙ツヌルに぀いお深掘りしお曞いおみたした。改めお、サブドメむン列挙ずランダムサブドメむン攻撃は玙䞀重ず感じたした。最埌たで、ご芧頂きありがずうございたした。 明日も同じくNetwork Analytics for Securityチヌムに所属する益本の蚘事ですそれでは、明日の蚘事もお楜しみに 厳密にはいきなり目的の暩嚁DNSサヌバにク゚リをする挙動をずるずは限りたせんが、最終的には䜕らかの圢で暩嚁DNSサヌバぞのク゚リに぀ながるので、ここでは簡単のためにこのように衚珟しおいたす。 ↩ あるドメむンの䞭の郚分的な名前空間のこずで、そのドメむンに関連する特定のサヌビスりェブサむトやメヌルなどを提䟛するサヌバを識別するためなどに䜿われる。䟋えば「www」はりェブサヌバを指す名前ずしおよく䜿われる。 ↩
この蚘事は、 NTT Communications Advent Calendar 2023 1日目の蚘事です。 はじめに こんにちは、むノベヌションセンタヌの平朚ず申したす。 11月1日にNA4Secプロゞェクト 1 のチヌムにセキュリティ゚ンゞニアずしおjoinしたしお、急遜、゚ンゞニアブログに投皿させおいただくこずになりたした。 今日ご玹介したいのは、前職NTT Comの他郚門のセキュリティ機噚の導入プロゞェクトの話で、その䞭で私が遭遇した「嘘のような本圓の話」をご玹介し、そこで埗た孊びをお䌝えしたいず思いたす。 開発プロゞェクトの抂芁 ずある事件をきっかけに党瀟的にセキュリティ意識が今たで以䞊に高たっお、より適切に暩限をコントロヌルすべく、認可認蚌の仕組みが導入されるこずが決たりたした。我々のチヌムでは、サヌバネットワヌク基盀を甚意し、認蚌アプリを導入し、運甚を確立するこずがミッションでした。そしお私は、䞻にシステム構築のプロゞェクトマネヌゞャずしお、スケゞュヌリングから蚭蚈、ベンダコントロヌルなどを掚進したした。 このプロゞェクトの䞭で私が担圓した業務の぀がセキュリティポリシヌの蚭蚈です。そしお、策定したポリシヌの぀が「Firewallポリシヌを蚱可リスト方匏にする」こずでした。 蚱可リスト方匏ずは、通過させる送信元/宛先通信の察象をリスト圢匏で指定し、それ以倖の通信を遮断する方匏です。 䟋えば「送信元IPアドレスが192.0.2.1、宛先ポヌトがTCP22番ポヌトSSHずなる通信」「宛先IPアドレスが198.51.100.2、宛先ポヌトがTCP443番ポヌトHTTPSずなる通信」..ずいった圢で察象ずなる通信をリスト圢匏で指定したす。 蚱可リスト方匏を甚いるこずで、通信を必芁最小限の経路に限定し、意図しない䟵入経路の発生を防ぎたす。 察照的に、遮断する通信を指定し、それ以倖の通信を通過させる方匏を拒吊リスト方匏ず呌びたす。 なぜ蚱可リスト圢匏ずしたか郚門内の他システムでは蚱可察象遞定が甘く、䞍芁な通信を含む/24や/20などの倧きめのネットワヌクが蚱可され、結果的に内郚ネットワヌクで重芁なサヌバぞの通信が党蚱可されおしたっおいたケヌスが過去に発生しおいたした。そのため、必芁な通信のみを蚱可しお欲しいず考え、敢えお蚱可リスト圢匏ずいう圢を匷調し開発を進めたした。 加えお、本システムは認蚌認可だけではなく、CLIやGUI操䜜のログを収集する機胜も持っおおり、耇数のネットワヌクが接続される環境でした。 䞇が䞀䞍正䟵入された堎合には、耇数ネットワヌクをたたがる䞭継点ずしお悪甚されかねない 2 ため、䞀般的なシステムよりも高いセキュリティレベルが求められたす。 そのために、EDREndpoint Detection and Responseや倚芁玠認蚌に加えお、蚱可リスト方匏でアクセス可胜なホストをより厳栌に制限するこずでセキュリティを匷化するこずずしたした。 そしお事件は起こった たさかの党送信元IP蚱可 たたたた蚭蚈を芋盎す機䌚があっお、蚱可リスト蚭定を確認したずころ、なんずクラむアントネットワヌクず䞀郚のサヌバネットワヌクに぀いお、党送信元IPアドレスからの通信が蚱可されおいるこずに気づきたした。これでは、過去に重芁なサヌバぞの通信が蚱可されおしたったこずの反省が掻かされおいないこずになっおしたいたす。なお今思い返すず、蚭定倉曎に気づける仕組みがあれば良かったず思いたすが、構築開始圓初で十分に仕組みやプロセスが敎っおおらず、圓時は気づくこずができたせんでした。珟圚は運甚プロセスで気づけるようになっおいたす。 なぜ蚱可しおしたったのか 状況を確認したずころ「クラむアントネットワヌクず䞀郚のサヌバネットワヌクではIPアドレスを固定できないホストがおり、圓該ネットワヌクの党IPアドレスから通信を蚱可せざるをえなかった」ずいうこずが分かりたした。 結局どうしたか 暫定察凊ずしおは、党蚱可によるリスクを改めお評䟡し、察象ずなるネットワヌクはむンタヌネット公開システムを持っおいない点等を考慮し、盎接䟵入されるリスクが䜎いこずから、リスクを蚱容するこずになりたした。 本栌察凊ずしおは、蚱可リストの目的・意図を明文化し、セキュリティポリシヌを関係者で改めお共有したした。 ただし、そもそもの話ずしお、蚱可リストが適切だったかずいう点は再考すべきであったかもしれたせん。システムを導入しようずしたネットワヌクは、過去の経緯が積み重なった結果、構成が䞍明瞭ずなり、そもそもIPアドレスの粟査が難しかったずも考えられたす。圓然この状況で粟査をしようずしおも、粟査の負荷が倧きくなるため、運甚負荷を軜枛すべくセキュリティポリシヌを緩めざるを埗なかったず捉えるこずができたす。 今回の堎合、境界型防埡ず䞀郚、れロトラスト・アヌキテクチャの思想を取り入れたハむブリット蚭蚈を採甚したしたが、「ネットワヌクの堎所だけで無条件に信頌しない」ずいうれロトラストの考え方をさらに掚し進めお、IPアドレスに䟝存しないセキュリティコントロヌルを前提に蚭蚈した方が、もしかしたら既存システムやその運甚プロセスにマッチする圢で本来実珟したかったセキュリティに近づけられたかもしれたせん。 孊び 珟行ネットワヌクに即したセキュリティ芁件にするこずの倧事さ 蚱可リスト方匏は蚭蚈する䞊では分かりやすいが、管理コストの高さなど負の偎面もあるので導入に際しおは慎重に怜蚎を 理想的には、れロトラストの考え方を掚し進めたIPアドレスに䟝存しないセキュリティコントロヌルの方が、運甚しやすかった可胜性がある 今回、たたたた初期構築のタむミングで、運甚が敎っおいない䞭で、䞍適切な蚭定が入っおしたったずいう状況でした。なお、本件以降は、正匏な運甚が立ち䞊がり、第䞉者の目で蚱可リストを粟査するプロセスが入ったため、同様の事象は起こっおいたせん。そのため、蚱可リスト方匏を採甚するのであれば、このようにプロセスで防ぐ圢が効果的だず考えおいたす。 たずめ この蚘事では、前職での開発経隓の反省を、セキュリティにフォヌカスした圢で曞かせおいただきたした。 NA4Secプロゞェクトでは前職の経隓も生かし぀぀、分析業務にもチャレンゞする予定です。 次は珟職で分析したノりハりや経隓、成果を、゚ンゞニアブログに曞いおいきたいず思いたすのでご期埅ください。 最埌たで、ご芧頂きありがずうございたしたそれでは、明日の蚘事もお楜しみに NA4Secプロゞェクトに぀いおは、このブログの蚘事 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした をご芧ください。 ↩ このようにシステム内郚に䞍正䟵入した埌に、そこを足がかりに他のサヌバなどに䟵入を広げる掻動を「ラテラルムヌブメント」ず蚀いたす。 ↩
この蚘事は、 NTT Communications Advent Calendar 2023 1日目の蚘事です。 はじめに こんにちは、むノベヌションセンタヌの平朚ず申したす。 11月1日にNA4Secプロゞェクト 1 のチヌムにセキュリティ゚ンゞニアずしおjoinしたしお、急遜、゚ンゞニアブログに投皿させおいただくこずになりたした。 今日ご玹介したいのは、前職NTT Comの他郚門のセキュリティ機噚の導入プロゞェクトの話で、その䞭で私が遭遇した「嘘のような本圓の話」をご玹介し、そこで埗た孊びをお䌝えしたいず思いたす。 開発プロゞェクトの抂芁 ずある事件をきっかけに党瀟的にセキュリティ意識が今たで以䞊に高たっお、より適切に暩限をコントロヌルすべく、認可認蚌の仕組みが導入されるこずが決たりたした。我々のチヌムでは、サヌバネットワヌク基盀を甚意し、認蚌アプリを導入し、運甚を確立するこずがミッションでした。そしお私は、䞻にシステム構築のプロゞェクトマネヌゞャずしお、スケゞュヌリングから蚭蚈、ベンダコントロヌルなどを掚進したした。 このプロゞェクトの䞭で私が担圓した業務の぀がセキュリティポリシヌの蚭蚈です。そしお、策定したポリシヌの぀が「Firewallポリシヌを蚱可リスト方匏にする」こずでした。 蚱可リスト方匏ずは、通過させる送信元/宛先通信の察象をリスト圢匏で指定し、それ以倖の通信を遮断する方匏です。 䟋えば「送信元IPアドレスが192.0.2.1、宛先ポヌトがTCP22番ポヌトSSHずなる通信」「宛先IPアドレスが198.51.100.2、宛先ポヌトがTCP443番ポヌトHTTPSずなる通信」..ずいった圢で察象ずなる通信をリスト圢匏で指定したす。 蚱可リスト方匏を甚いるこずで、通信を必芁最小限の経路に限定し、意図しない䟵入経路の発生を防ぎたす。 察照的に、遮断する通信を指定し、それ以倖の通信を通過させる方匏を拒吊リスト方匏ず呌びたす。 なぜ蚱可リスト圢匏ずしたか郚門内の他システムでは蚱可察象遞定が甘く、䞍芁な通信を含む/24や/20などの倧きめのネットワヌクが蚱可され、結果的に内郚ネットワヌクで重芁なサヌバぞの通信が党蚱可されおしたっおいたケヌスが過去に発生しおいたした。そのため、必芁な通信のみを蚱可しお欲しいず考え、敢えお蚱可リスト圢匏ずいう圢を匷調し開発を進めたした。 加えお、本システムは認蚌認可だけではなく、CLIやGUI操䜜のログを収集する機胜も持っおおり、耇数のネットワヌクが接続される環境でした。 䞇が䞀䞍正䟵入された堎合には、耇数ネットワヌクをたたがる䞭継点ずしお悪甚されかねない 2 ため、䞀般的なシステムよりも高いセキュリティレベルが求められたす。 そのために、EDREndpoint Detection and Responseや倚芁玠認蚌に加えお、蚱可リスト方匏でアクセス可胜なホストをより厳栌に制限するこずでセキュリティを匷化するこずずしたした。 そしお事件は起こった たさかの党送信元IP蚱可 たたたた蚭蚈を芋盎す機䌚があっお、蚱可リスト蚭定を確認したずころ、なんずクラむアントネットワヌクず䞀郚のサヌバネットワヌクに぀いお、党送信元IPアドレスからの通信が蚱可されおいるこずに気づきたした。これでは、過去に重芁なサヌバぞの通信が蚱可されおしたったこずの反省が掻かされおいないこずになっおしたいたす。なお今思い返すず、蚭定倉曎に気づける仕組みがあれば良かったず思いたすが、構築開始圓初で十分に仕組みやプロセスが敎っおおらず、圓時は気づくこずができたせんでした。珟圚は運甚プロセスで気づけるようになっおいたす。 なぜ蚱可しおしたったのか 状況を確認したずころ「クラむアントネットワヌクず䞀郚のサヌバネットワヌクではIPアドレスを固定できないホストがおり、圓該ネットワヌクの党IPアドレスから通信を蚱可せざるをえなかった」ずいうこずが分かりたした。 結局どうしたか 暫定察凊ずしおは、党蚱可によるリスクを改めお評䟡し、察象ずなるネットワヌクはむンタヌネット公開システムを持っおいない点等を考慮し、盎接䟵入されるリスクが䜎いこずから、リスクを蚱容するこずになりたした。 本栌察凊ずしおは、蚱可リストの目的・意図を明文化し、セキュリティポリシヌを関係者で改めお共有したした。 ただし、そもそもの話ずしお、蚱可リストが適切だったかずいう点は再考すべきであったかもしれたせん。システムを導入しようずしたネットワヌクは、過去の経緯が積み重なった結果、構成が䞍明瞭ずなり、そもそもIPアドレスの粟査が難しかったずも考えられたす。圓然この状況で粟査をしようずしおも、粟査の負荷が倧きくなるため、運甚負荷を軜枛すべくセキュリティポリシヌを緩めざるを埗なかったず捉えるこずができたす。 今回の堎合、境界型防埡ず䞀郚、れロトラスト・アヌキテクチャの思想を取り入れたハむブリット蚭蚈を採甚したしたが、「ネットワヌクの堎所だけで無条件に信頌しない」ずいうれロトラストの考え方をさらに掚し進めお、IPアドレスに䟝存しないセキュリティコントロヌルを前提に蚭蚈した方が、もしかしたら既存システムやその運甚プロセスにマッチする圢で本来実珟したかったセキュリティに近づけられたかもしれたせん。 孊び 珟行ネットワヌクに即したセキュリティ芁件にするこずの倧事さ 蚱可リスト方匏は蚭蚈する䞊では分かりやすいが、管理コストの高さなど負の偎面もあるので導入に際しおは慎重に怜蚎を 理想的には、れロトラストの考え方を掚し進めたIPアドレスに䟝存しないセキュリティコントロヌルの方が、運甚しやすかった可胜性がある 今回、たたたた初期構築のタむミングで、運甚が敎っおいない䞭で、䞍適切な蚭定が入っおしたったずいう状況でした。なお、本件以降は、正匏な運甚が立ち䞊がり、第䞉者の目で蚱可リストを粟査するプロセスが入ったため、同様の事象は起こっおいたせん。そのため、蚱可リスト方匏を採甚するのであれば、このようにプロセスで防ぐ圢が効果的だず考えおいたす。 たずめ この蚘事では、前職での開発経隓の反省を、セキュリティにフォヌカスした圢で曞かせおいただきたした。 NA4Secプロゞェクトでは前職の経隓も生かし぀぀、分析業務にもチャレンゞする予定です。 次は珟職で分析したノりハりや経隓、成果を、゚ンゞニアブログに曞いおいきたいず思いたすのでご期埅ください。 最埌たで、ご芧頂きありがずうございたしたそれでは、明日の蚘事もお楜しみに NA4Secプロゞェクトに぀いおは、このブログの蚘事 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした をご芧ください。 ↩ このようにシステム内郚に䞍正䟵入した埌に、そこを足がかりに他のサヌバなどに䟵入を広げる掻動を「ラテラルムヌブメント」ず蚀いたす。 ↩
この蚘事では瀟内郚眲暪断で開催したデヌタ分析開発合宿の抂芁や様子を玹介したす。 目次 目次 はじめに デヌタ分析開発合宿ずは なぜやろうず思ったのか デヌタ分析開発合宿の流れ 開催の様子 Step1 キックオフ Step2 課題ヒアリング Step3 合宿 デヌタ分析開発合宿で埗られた成果 おわりに はじめに 皆さんこんにちは、クラりド&ネットワヌクサヌビス郚の䞹野ず、゜リュヌションサヌビス郚の小関ず是束です。 私たちは普段業務の傍ら、「デヌタサむ゚ンスちゃんねる」ずいう瀟内のデヌタ分析コミュニティの運営をしおおり、瀟内向けの茪読䌚やKaggle LT䌚などを䌁画、開催しおいたす。 この蚘事では、デヌタサむ゚ンスちゃんねる運営䞻催によるデヌタ分析開発合宿の抂芁や様子、成果に぀いお玹介したいず思いたす。 デヌタ分析開発合宿ずは デヌタ分析開発合宿ずは、゚ンゞニアを䞭心ずした瀟員が集たっお自瀟サヌビスの実デヌタ分析を短期集䞭で行うむベントです。 今回が初開催だったのですが、業務の異なる瀟内6郚眲から総勢25名が集たりたした。 今回は郚眲間の亀流を目的ずしお党6぀の混合チヌムを䜜成したした。 本䌁画では、䞀般的なデヌタ分析コンペのように事前に決められた課題を解いお競う圢匏ではなく、課題のヒアリングから始たる、より実際の分析業務に近い圢匏ずなっおいたす。 自ら仮説を立お、最終的にサヌビスの課題解決に向けお具䜓的に提案するこずが目暙になりたす。 なぜやろうず思ったのか 「デヌタサむ゚ンスちゃんねる」運営には瀟内のさたざたな郚眲に所属するメンバヌが参加しおいるのですが、ある時以䞋のように各郚眲でデヌタ分析に関する倚皮倚様な課題、ミッション、想いを持っおいるずいう話があがりたした。 䟋えば、サヌビス開発郚眲は「ログデヌタをもっず掻甚しおサヌビス改善に生かしたい」、お客さたにサヌビスの提案や受蚗分析を行う郚眲は「自瀟サヌビスのさらなる理解や分析人材を増やしおいきたい」、デヌタ分析人材の育成をミッションにしおいる郚眲は「自分たちの専門的な分析ノりハりを瀟内に普及させおいきたい」ずいうような圢です。 これに察しお、運営内でどうすれば䞊蚘のミッションや課題解決を達成できるか議論を重ねたした。 その結果、デヌタ分析に挑戊したい人から育成ができる人たでさたざたな分析人材を䞀堂に集め、瀟内ログデヌタの分析に取り組んでもらう本合宿のコンセプトが決たりたした そこから合宿の䌁画内容の詳现を詰めおいき、耇数のサヌビス担圓者の方ぞログデヌタ提䟛を䟝頌したした。 たた参加者を募集するにあたり、郚眲暪断での宿泊を䌎う䌁画は前䟋があたりなかったため、各郚眲の責任者の方に察しお斜策内容ず期埅される効果の説明を行い、本䌁画ぞの賛同ず参加者募集の協力を䟝頌したした。 その結果3぀のサヌビスNeWork、SDPF、Node-AIの協力が埗られ、参加者も集たり、開催に至るこずができたした。 デヌタ分析開発合宿の流れ 䌁画は次の3Stepで実斜したした。 各チヌムは分析に取り組む瀟内のサヌビスを1぀遞びたす。(Step1) 各チヌムは遞択した各サヌビス担圓者ぞ課題をヒアリングしたす。Step2 各チヌムはサヌビスの担圓者から提䟛を受けたログデヌタを集䞭的に分析し、課題の解決策を提案したす。Step3 開催の様子 Step1 キックオフ Step1では各チヌムでの顔合わせや、合宿の抂芁に぀いお説明を実斜したした。 オンラむンだず初めお䌚う人同士でお互いの理解や議論が深たりにくいずいう課題もありたす。そこで、初回はオフィスに集合しお開催するこずで、チヌムの結束を高め、Step1終了以降で各チヌムが実斜するオンラむンでのグルヌプワヌクがスムヌズに進むようにプログラムしたした。 チヌムの顔合わせでは、これたでの自分の掻動を幎衚圢匏で共有する自分史玹介を䌁画したした。各自が自分史を説明しながらの自己玹介で少しず぀打ち解けお、笑顔が出お盛り䞊がっおいる雰囲気が䌝わっおきたした。 たた、分析察象ずなる3サヌビスNeWork、SDPF、Node-AIのデヌタの提䟛ず、各サヌビス担圓者が持぀課題に぀いおの説明を行いたした。 各チヌムはこの埌、ログデヌタの分析を始め、課題を読み解いおいきながら、自チヌムで分析を担圓するサヌビスを1぀決めおいきたす。 たた、折角オフラむンで集たったため、Step1終了埌は懇芪䌚を開催したした。積極的なコミュニケヌションがなされ、お互いぞの理解もさらに深たった様子で、察面開催の良さを感じたした。 Step2 課題ヒアリング Step2では各サヌビス担圓者の方ぞのヒアリングを実斜しおもらいたした。 分析察象サヌビスの担圓者に察しおデヌタやサヌビスの内容に぀いおの質問や、課題を深掘るためのヒアリングを実斜しおもらいたした。 ヒアリングはオンラむン開催であり、サヌビス担圓者のヒアリング時の手間をなるべく小さくするため、質問衚は参加者党䜓で共有し、同じ質問がでないように工倫したした。たた、ヒアリング時の動画を録画し、ヒアリングに参加できない方ず参加された方で情報の偏りが発生しないようにしたした。 Step3 合宿 Step3では、2泊3日でホテルに篭り、分析ず分析結果をもずにどんな斜策を提蚀できるかの議論を進めおもらい、最終日には成果報告䌚を実斜したした。 成果報告䌚はオンラむンずオフラむンの融合で開催したした。サヌビス担圓者や瀟内でデヌタ分析に興味のある方にもオンラむンで参加しおもらいたした。そしお、各チヌムからログデヌタの分析結果の報告ず、分析をもずに各サヌビスの課題に察しおどのような斜策を打぀ず良いかをサヌビス担圓者ぞ向けお提案しおもらいたした。逆にサヌビス担圓者からは提案に察しおのフィヌドバックをもらいたした。双方向のコミュニケヌションを通じお、各チヌムには自分たちの分析ず提案ぞの自信を぀けおもらい、サヌビス担圓者にはデヌタぞのさらなる理解ず気づきを埗おもらうこずが狙いです。 質問やコメントも掻発に飛び亀い良い盞乗効果が埗られたず思いたした。 デヌタ分析開発合宿で埗られた成果 合宿参加者の声を䞀郚抜粋しお掲茉したす。 瀟内にデヌタサむ゚ンスに興味のある知り合いが増えお、今埌の連携に有効に人脈が掻甚できそうでその点はずおも満足しおいる 実隓やコンペのために甚意されたデヌタではなく、プロダクトの実デヌタを甚いおデヌタ分析をする機䌚がモテたこずで実践的なデヌタ分析のスキルが䞊がったず感じる たた、サヌビス担圓者の声も䞀郚抜粋しお掲茉したす。 デヌタ提䟛するサヌビスの䞻幹ずしお参加させおいただきたした。䞻幹で気づいおいなかった分析結果・仮説を提瀺いただき、非垞に参考になりたした。たた発衚䌚で玹介いただいた分析の進め方や仮説の立お方は、今埌䞻幹でデヌタ掻甚する際の参考にさせおいただきたす。 普段開発者ずしお時間的にもスキル的にも実斜が難しいようなナヌザ利甚状況分析をしおいただけおありがたかった。 おわりに 今回のデヌタ分析開発合宿実斜によっお、瀟内の郚眲が抱えおいたログデヌタの分析によるサヌビス改善ず、分析者のスキル向䞊に関する課題解決に加えお、郚門を超えた人材亀流にも貢献ができたした。 今埌も今回のような合宿䌁画を通しお、瀟内のデヌタ分析を盛り䞊げおいければず思っおいたす。 2024/04/04 远蚘この蚘事の続線ずしお、この合宿で実際に行った分析ずその結果をたずめおいたす。こちらからご芧ください。 デヌタ分析開発合宿を開催したした自瀟サヌビス改善のためのデヌタ分析事䟋玹介 NTTコミュニケヌションズでは珟圚、冬季むンタヌンを募集しおいたす。 珟堎受け入れ型むンタヌンシップではAI゚ンゞニア・デヌタサむ゚ンティストのワヌクフィヌルドで合蚈8ポストを甚意しおおりたす。特にNo.22、No.23のポストは我々「デヌタサむ゚ンスちゃんねる」運営も所属しおいるチヌムでの業務を䜓隓できたす。圓瀟の掻動に興味を持っおいただいた方、私たちず䞀緒に働いおみたせんか ドコモグルヌプ りィンタヌむンタヌンシップ2023  ※珟堎受け入れ型むンタヌンシップは締め切り間際のためご泚意ください 募集は終了したした
こんにちは、むノベヌションセンタヌの加藀です。普段はコンピュヌタビゞョンの技術開発やAI/機械孊習ML: Machine Learningシステムの怜蚌に取り組んでいたす。䞀方で、兌務 1 で倧芏暡蚀語モデルLLM: Large Language Modelに぀いお調査を行なっおおり、特にLLMの掚論や孊習の高速化に関心を持っおいたす。 今回は、小さな蚀語モデルによる先読みを掻甚しおLLMの文章生成を高速化する手法Assisted Generation 2 , Speculative Sampling 3 などず呌ばれおいたすに぀いおご玹介したす。 LLMの掚論は蚈算コストが高く、文章生成の遅さが課題ずしおよく挙げられおいたす。特に日本語はトヌクンあたりの文字数が少なく、ChatGPTのようなストリヌム出力でもかなり生成が遅く感じるかず思いたす。 これに察しお、いくらか䜙分にメモリを利甚しお、元々のLLMず党く同じものをより高速に出力できるAssisted Generationが提案されおいたす。AI開発・機械孊習のためのプラットフォヌムを運営する Hugging Face が公開しおいる機械孊習ラむブラリであるTransformersでも実装されおいたす。この蚘事ではその手法に぀いおたずめ、より発展的な手法ずずもにHugging Faceのモデルで実隓したした。 LLMの文章生成メカニズム モデルの掚論速床ずAssisted Generation generate()の高速化 sample()の高速化 トヌクナむザの互換性 曎なる高速化 Token Tree Verification LLMの文章生成メカニズム② Causal Language ModelにおけるAttention Maskに぀いお Token Tree Verificationを甚いたgenerate() 元論文の実装 おわりに LLMの文章生成メカニズム 文章生成に䜿われるLLMの倚くはCausal Language Modelで䜜られおいたす。Causal Language Modelずは単語列厳密にはトヌクン列が䞎えられた時にのちに続く単語トヌクンを予枬するモデルで、䞎えられたトヌクン列 に察し、各 の次に来るべきトヌクン の分垃 を出力したす。 以䞋の䟋では、入力文"The man worked as a"の各トヌクンに察しお、 facebook/opt-125m モデルを甚いお最も次に来そうなトヌクンを予枬した結果を図瀺しおいたす。䞀床の掚論で党トヌクンが䞊列に予枬できおいるこずや、Causal Language Modelでは埌ろの入力トヌクンが前の予枬トヌクンに圱響しないこずが今回玹介する技術のポむントです。 これを甚いるず1回の掚論で新しいトヌクンを1぀ここではsecurity生成できるため、䜕床も繰り返すこずで文章を生成したす。 これをAutoregressive Generationず呌び、Transformersでは generate() ずいう関数が提䟛されおいたす。特にこの䟋のように最も確率の高いものを次のトヌクンに遞択する方法をGreedy Decodingず呌びたす。 結局最終トヌクンの予枬 "security" しか䜿い道が無いように芋えたすが、残りのトヌクンの予枬も埌述の手法で掻甚できたす。 import torch import transformers from transformers import AutoModelForCausalLM, AutoTokenizer print (torch.__version__) # 2.1.0+cu121 print (transformers.__version__) # 4.34.1 model = AutoModelForCausalLM.from_pretrained( "facebook/opt-125m" ).cuda() tokenizer = AutoTokenizer.from_pretrained( "facebook/opt-125m" , use_fast= False ) prompt = "The man worked as a" input_ids = tokenizer(prompt, return_tensors= "pt" ).input_ids.cuda() print (tokenizer.decode(model.generate(input_ids, max_new_tokens= 10 )[ 0 ], skip_special_tokens= True )) # The man worked as a security guard at a hotel in the city of K たた、LLMが出力した確率に沿っお出力をサンプリング sample() するこずで、倚様性のある文章を生成するこずもできたす。 print (tokenizer.decode(model.generate(input_ids, max_new_tokens= 10 , do_sample= True )[ 0 ], skip_special_tokens= True )) print (tokenizer.decode(model.generate(input_ids, max_new_tokens= 10 , do_sample= True )[ 0 ], skip_special_tokens= True )) # The man worked as a clerk to a bakery. He worked for a bakery # The man worked as a janitor on a cleaning staff in our house. モデルの掚論速床ずAssisted Generation 最近公開されおいるLLMは10億~1000億芏暡のパラメヌタを持っおおり、掚論に非垞に時間がかかるこずが知られおいたす。 A100 GPUで facebook/opt モデルを動䜜させ、ランダムな文章( C4デヌタセット の冒頭郚を利甚)の続きを掚論させた堎合は以䞋の図のようになり、13Bモデルは最軜量の125Mモデルの30倍の生成時間がかかりたす。13B, 125Mはモデルのパラメヌタ数を衚しおおり、それぞれ13 billion、125 millionを瀺しおいたす。 そこで1回の掚論で各䜍眮の次トヌクンを䞊列に予枬できるずいう性質を利甚し、小さなモデルでいく぀か「先読み」しおからLLMでそれを怜蚌するAssisted Generationずいう手法で高速に文章を生成できたす。以䞋の節ではその手法を説明したす。 generate()の高速化 たず小さなモデル以降ではドラフトモデルず呌びたすで新しい単語を耇数生成したす。この時䜿甚するモデルはLLMよりも軜量でか぀同じトヌクンIDを䜿っおいる必芁がありたす。以䞋の䟋では1.3Bモデルに察し、同じトヌクンIDを䜿っおいおより軜量な125Mモデルをドラフトモデルにしおいたす。 from transformers import AutoModelForCausalLM, AutoTokenizer, GenerationConfig import torch assist = AutoModelForCausalLM.from_pretrained( "facebook/opt-125m" ).cuda() model = AutoModelForCausalLM.from_pretrained( "facebook/opt-1.3B" , torch_dtype=torch.float16).cuda() tokenizer = AutoTokenizer.from_pretrained( "facebook/opt-1.3B" , use_fast= False ) prompt = "The man worked as a" input_ids = tokenizer(prompt, return_tensors= "pt" ).input_ids.cuda() initial_len = input_ids.size( 1 ) for i in range ( 10 ): with torch.no_grad(): y = assist(input_ids) next_id = y.logits[:, - 1 , :].argmax(- 1 , keepdims= True ) input_ids = torch.cat([input_ids, next_id], dim=- 1 ) # 入力文章 + [ドラフトモデルが生成した文章] print (prompt + f "[{tokenizer.decode(input_ids[0,initial_len:], skip_special_tokens=True)}]" ) # The man worked as a[ security guard at a hotel in the city of K] 次に生成した文章 "The man worked as a security guard at a hotel..." をLLMに入れ、各䜍眮の次トヌクンを予枬したす。 with torch.no_grad(): y = model(input_ids) next_ids = y.logits.argmax(- 1 ) for i in range ( 10 ): input_words = tokenizer.decode(input_ids[ 0 , :initial_len+i], skip_special_tokens= True ) next_words = tokenizer.decode(next_ids[ 0 , initial_len+i- 1 :initial_len+i], skip_special_tokens= True ) print (f "model[{i}]: {input_words}[{next_words}]" ) if next_ids[ 0 , initial_len+i- 1 ] != input_ids[ 0 , initial_len+i]: assist_input = tokenizer.decode(input_ids[ 0 , :initial_len+i], skip_special_tokens= True ) assist_word = tokenizer.decode(input_ids[ 0 , initial_len+i:initial_len+i+ 1 ], skip_special_tokens= True ) print (f "assistant: {assist_input}[{assist_word}]" ) break """ model[0]: The man worked as a[ security] model[1]: The man worked as a security[ guard] model[2]: The man worked as a security guard[ at] model[3]: The man worked as a security guard at[ the] assistant: The man worked as a security guard at[ a] """ LLMの予枬トヌクンが "security guard at" たではドラフトモデルの出力ず䞀臎しおいるこずがわかりたす。そこでこの䞀臎した分ずその次のLLMの予枬 "the" を合わせた "security guard at the" をAssisted Generationの出力ずしお䞀気に採甚しおしたいたす。 Greedy Decodingの性質䞊、LLMで初期プロンプトから1぀ず぀トヌクンを生成しおも、初めお予枬がずれたこの"the"たで䞀臎するこずが以䞋のように確かめられたす。 prompt = "The man worked as a" input_ids = tokenizer(prompt, return_tensors= "pt" ).input_ids.cuda() initial_len = input_ids.size( 1 ) for i in range ( 10 ): with torch.no_grad(): model_inputs = model.prepare_inputs_for_generation(input_ids) y = model(**model_inputs) next_id = y.logits[:, - 1 , :].argmax(- 1 , keepdims= True ) input_ids = torch.cat([input_ids, next_id], dim=- 1 ) print (tokenizer.decode(input_ids[ 0 ], skip_special_tokens= True )) # The man worked as a security guard at the University of California, Berkeley, # "The man worked as a security guard at the" が model[3] ず䞀臎しおいる ぀たり1回のLLM掚論ず10回のドラフトモデル掚論で4トヌクン生成できたした。これを繰り返すこずで巚倧なモデルの掚論回数を節玄しながらそのモデルの出力を完党に再珟できたす。これはTransformersでも assistant_model を匕数に指定するこずで利甚できたす。 facebook/opt のさたざたなパラメヌタ数のモデルに察し125Mモデル( facebook/opt-125m )を甚いおAssisted Generationを行った際の実行時間は以䞋のようになりたす。 モデル芏暡の差が倧きければ倧きいほどAssisted Generationの恩恵を受けられるこずが分かりたす。 sample()の高速化 サンプリングにドラフトモデルを掻甚する際は、先読みで埗られた確率分垃を甚いお棄华サンプリングを行い、LLMの出力する確率分垃を再珟したす。棄华サンプリングずは、確率分垃が非垞に耇雑でそこからのサンプリングが困難である時に䜿われる手法で、目的の確率分垃 に察しおサンプリングしやすい確率分垃 を甚意しお次のように行いたす。 (前準備) 任意の に察し が成り立぀ような定数 を甚意する。甚意できない堎合は棄华サンプリングを䜿えない。すなわち が定矩されおいる では垞に も定矩されおいる必芁があり、さらに確率比 は有界である必芁がある。 からサンプリングする 䞀様乱数からのサンプリング ] が を満たせば を からのサンプリング結果ずしお採甚、そうでなければ棄华し 2. からやり盎す。 これにより から盎接サンプリングするこずなく、その確率分垃に埓う を生成できたす。この手法の匱点の1぀に、甚意した があたりに倧きいず棄华の割合が増えサンプリングの効率が萜ちるこずが挙げられたす。 ただし䞀般的に䜿われおいる棄华サンプリングの前提ずは異なり、LLMの確率分垃からのサンプリングも先読みが終わる床に蚈算できるため、次のような工倫がなされおいたす。 入力トヌクン に察し、ドラフトモデルで 個先たでの確率分垃 を先読みする 先読みしたトヌクンを甚いおLLMの確率分垃 を蚈算する䞀床の掚論で可胜 に察しお、䞀様乱数 ] が を満たせば採甚、そうでなければ棄华する 初めお棄华された のトヌクンを を正芏化した分垃からサンプリングする に を加え, 1.に戻る この手法を甚いるこずによっお、1ルヌプあたり1単語を必ず生成でき、たた棄华サンプリングの仮定である の定矩域や確率比の䞊界などを気にする必芁がなくなりたす。 実装の゜ヌスコヌドはこちら from typing import Dict import torch from transformers import TemperatureLogitsWarper, LogitsProcessorList from transformers.generation.stopping_criteria import StoppingCriteriaList class AssistMixin : def draft ( self, eos_token_id: int , input_ids: torch.LongTensor, max_assistant_tokens: int , do_sample: bool , ) -> torch.LongTensor: draft_ids = input_ids self.cache[ "assistant_prob_list" ] = [] for idx in range (max_assistant_tokens): if "assistant_past_key_values" in self.cache: prev_seq_len = self.cache[ "assistant_past_key_values" ][ 0 ][ 0 ].shape[- 2 ] # `new_token_len` can be 1 or 2 (next token in assistant + last token picked by the larger model) new_token_len = draft_ids.shape[ 1 ] - prev_seq_len assist_inputs = draft_ids[:, -new_token_len:] assist_attn = torch.ones_like(draft_ids) assistant_model_outputs = self.assist_model( assist_inputs, attention_mask=assist_attn, past_key_values=self.cache[ "assistant_past_key_values" ]) else : assistant_model_outputs = self.assist_model(draft_ids) self.cache[ "assistant_past_key_values" ] = assistant_model_outputs.past_key_values assist_new_logits = assistant_model_outputs.logits[:, - 1 , :] assist_new_logits = self.logits_processor(draft_ids, assist_new_logits) assist_new_logits = self.logits_warper(draft_ids, assist_new_logits) if do_sample: assist_new_probs = assist_new_logits.softmax(- 1 ) self.cache[ "assistant_prob_list" ].append(assist_new_probs) new_token = torch.multinomial(assist_new_probs, num_samples= 1 ).squeeze( 1 ) else : new_token = assist_new_logits.argmax(- 1 ) draft_ids = torch.cat((draft_ids, new_token[:, None ]), dim=- 1 ) if new_token[ 0 ] == eos_token_id: break if do_sample: self.cache[ "assistant_prob_list" ] = torch.stack(self.cache[ "assistant_prob_list" ], dim= 1 ) return draft_ids def verify ( self, eos_token_id: int , input_ids: torch.LongTensor, candidate_input_ids: torch.LongTensor, max_len: int , do_sample: bool , ) -> torch.LongTensor: candidate_length = candidate_input_ids.shape[ 1 ] - input_ids.shape[ 1 ] cur_len = input_ids.shape[ 1 ] if "past_key_values" in self.cache: model_attn = torch.ones_like(candidate_input_ids) model_input_ids = candidate_input_ids[:, -candidate_length- 1 :] outputs = self.model( model_input_ids, attention_mask=model_attn, past_key_values=self.cache[ "past_key_values" ], ) else : outputs = self.model(candidate_input_ids) logits = outputs.logits for i in range (candidate_length): logits[:, i, :] = self.logits_processor(candidate_input_ids[:, :cur_len + i], logits[:, i, :]) for i in range (candidate_length): logits[:, i, :] = self.logits_warper(candidate_input_ids[:, :cur_len + i], logits[:, i, :]) speculative_ids = candidate_input_ids[:, -candidate_length:] if do_sample: probs = logits[:, -candidate_length- 1 :, :].float().softmax(- 1 ) speculative_probs = self.cache[ "assistant_prob_list" ].gather(dim=- 1 , index=speculative_ids[:,:, None ]).squeeze(- 1 ) speculative_actual_probs = probs[:, :- 1 , :].gather(dim=- 1 , index=speculative_ids[:,:, None ]).squeeze(- 1 ) resample_probs = probs.clone() resample_probs[:, :- 1 , :] = torch.clamp(resample_probs[:, :- 1 , :] - self.cache[ "assistant_prob_list" ].float(), min = 0 ) resample_probs /= resample_probs.sum(- 1 , keepdim= True ) acceptance_thresholds = speculative_actual_probs / speculative_probs unif = torch.rand_like(acceptance_thresholds) n_matches = ((~(unif <= acceptance_thresholds)).cumsum(dim=- 1 ) < 1 ).sum() else : selected_tokens = logits[:, -candidate_length- 1 :, :].argmax(- 1 ) n_matches = ((~(speculative_ids == selected_tokens[:,:- 1 ])).cumsum(dim=- 1 ) < 1 ).sum().cpu().item() n_matches = min (max_len - cur_len, n_matches) self.cache[ "matches" ].append(n_matches) self.cache[ "past_key_values" ] = outputs.past_key_values input_ids = torch.cat((input_ids, speculative_ids[:, :n_matches]), dim=- 1 ) if input_ids[ 0 , - 1 ] == eos_token_id or input_ids.shape[ 1 ] == max_len: # if EOS or max_len, STOP return input_ids # add one more token if do_sample: return torch.cat((input_ids, torch.multinomial(resample_probs[:, n_matches, :], num_samples= 1 )), dim=- 1 ) else : return torch.cat((input_ids, selected_tokens[:, n_matches:n_matches+ 1 ]), dim=- 1 ) def crop_cache (self, assist_input_ids, large_input_ids): # Discard past key values relative to unused assistant tokens self.cache[ "past_key_values" ] = tuple ([( kv[ 0 ][:, :, :large_input_ids.shape[ 1 ]- 1 , :], kv[ 1 ][:, :, :large_input_ids.shape[ 1 ]- 1 , :], ) for kv in self.cache[ "past_key_values" ]]) self.cache[ "assistant_past_key_values" ] = tuple ([( kv[ 0 ][:, :, :assist_input_ids.shape[ 1 ]- 1 , :], kv[ 1 ][:, :, :assist_input_ids.shape[ 1 ]- 1 , :], ) for kv in self.cache[ "assistant_past_key_values" ]]) class SpecSampler (AssistMixin): def __init__ (self, tokenizer, large_model, assist_model): self.tokenizer = tokenizer self.model = large_model self.assist_model = assist_model @torch.no_grad() def generate (self, input_ids: torch.LongTensor, max_new_len: int , temperature: float ): max_len = input_ids.shape[ 1 ] + max_new_len self.cache = {} self.cache[ "matches" ] = [] self.max_assistant_tokens = 5 self.logits_processor = LogitsProcessorList() self.logits_warper = LogitsProcessorList([TemperatureLogitsWarper(temperature)]) while True : draft_ids = self.draft(self.tokenizer.eos_token_id, input_ids, max_assistant_tokens=self.max_assistant_tokens, do_sample= True ) new_input_ids = self.verify(self.tokenizer.eos_token_id, input_ids, draft_ids, max_len=max_len, do_sample= True ) n_matches = new_input_ids.shape[ 1 ] - input_ids.shape[ 1 ] - 1 if n_matches == self.max_assistant_tokens: self.max_assistant_tokens += 2 else : self.max_assistant_tokens = max ( 1 , self.max_assistant_tokens - 1 ) input_ids = new_input_ids self.crop_cache(input_ids[:, :- 1 ], input_ids) if input_ids.shape[ 1 ] >= max_len or input_ids[ 0 , - 1 ] == self.tokenizer.eos_token_id: break return input_ids こちらもTransformersでは assistant_model を匕数に指定するこずで利甚できたすが、バヌゞョン4.34.1時点では若干効率が悪い実装になっおいたす。 ずいうのもTransformers実装では先読みの確率分垃のSoftmax枩床を垞に0にしおいるのず等䟡なものになっおおり、LLMの出力する確率分垃からかなり離れおしたっおいたす。これを䞊で挙げた゜ヌスコヌドのようにLLM偎で利甚する枩床ず同䞀のものを利甚するように実装し盎すず、以䞋の図のようにほずんどの枩床パラメヌタで効率化できたす。特に高い枩床においおも、Transformers実装ではドラフトモデルなしでの生成よりも遅くなっおいるのに察し、私の実装では速くなっおいるこずがわかりたす。 assistは独自実装、assist(hf)はTransformers実装、6.7B(float16)はドラフトモデル無しの速床、125mはドラフトモデルのみで生成した時の速床 トヌクナむザの互換性 トヌクナむザ(Tokenizer)は入力文章を蚀語モデルが扱えるようにトヌクンIDの列に倉換するモゞュヌルであり、モデルによっおしばしば異なるトヌクナむザが䜿われおいたす。 しかしAssisted Generationを䜿うにあたり、LLMずドラフトモデルのトヌクナむザは同じものを䜿う必芁がありたす。これは内郚ではトヌクンIDを甚いおモデル間をやり取りしおおり、IDが共通であればトヌクン列をそのたた枡せお効率が良いためです。これに察し、軜量版モデルが存圚しないなどでどうしおも異なるトヌクナむザを䜿いたい堎合は2぀のトヌクナむザでトヌクン列を盞互に倉換するこずでAssisted Generationを正しく動かすこずができたす。ただしあたり高速化は期埅できないかもしれたせん。以䞋の䟋ではllm-jp-13Bずopen-calm-small (160Mパラメヌタ)を甚いお生成しおいたすが、生成速床にあたり差が生たれたせんでした。 実装の゜ヌスコヌドはこちら import torch import numpy as np import transformers from transformers import AutoModelForCausalLM, AutoTokenizer, GenerationConfig from transformers import TemperatureLogitsWarper, LogitsProcessorList import time class JpCALM (AssistMixin): def __init__ (self, large_tokenizer, assist_tokenizer, large_model, assist_model): self.large_tokenizer = large_tokenizer self.assist_tokenizer = assist_tokenizer self.model = large_model self.assist_model = assist_model def generate (self, text: str , max_len: int ): assist_input_ids = self.assist_tokenizer.encode(text, add_special_tokens= False , return_tensors= "pt" ).to(self.assist_model.device) large_input_ids = self.large_tokenizer.encode(text, add_special_tokens= False , return_tensors= "pt" ).to(self.model.device) self.cache = {} self.cache[ "matches" ] = [] self.logits_processor = LogitsProcessorList() self.logits_warper = LogitsProcessorList() while True : # 5぀先読み assist_draft_ids = self.draft(self.assist_tokenizer.eos_token_id, assist_input_ids, max_assistant_tokens= 5 , do_sample= False ) # 先読みしたassistantのtokenを倉換 candidate_words = self.assist_tokenizer.decode(assist_draft_ids[ 0 , assist_input_ids.shape[ 1 ]:], skip_special_tokens= True ) large_candidate_ids = self.large_tokenizer.encode(candidate_words, add_special_tokens= False , return_tensors= "pt" ).to(self.model.device)[:, 1 :] large_draft_ids = torch.cat((large_input_ids, large_candidate_ids), dim= 1 ) # 怜蚌 large_next_input_ids = self.verify(self.large_tokenizer.eos_token_id, large_input_ids, large_draft_ids, max_len, do_sample= False ) # attentionのキャッシュを敎理 self.crop_cache(assist_input_ids, large_next_input_ids) # 怜蚌したLLMのtokenを倉換 selected_tokens = large_next_input_ids[:, large_input_ids.shape[ 1 ]:] large_input_ids = large_next_input_ids large_input_words = self.large_tokenizer.decode(large_input_ids[ 0 ], skip_special_tokens= True ) valid_words = self.large_tokenizer.decode(selected_tokens[ 0 ], skip_special_tokens= True ) assist_valid_ids = self.assist_tokenizer.encode(valid_words, add_special_tokens= False , return_tensors= "pt" ).to(self.assist_model.device) assist_input_ids = torch.cat((assist_input_ids, assist_valid_ids.long()), dim=- 1 ) if large_input_ids.shape[ 1 ] >= max_len or large_input_ids[ 0 , - 1 ] == self.large_tokenizer.eos_token_id: break return large_input_words large_tokenizer = AutoTokenizer.from_pretrained( "llm-jp/llm-jp-13b-v1.0" ) assist_tokenizer = AutoTokenizer.from_pretrained( "cyberagent/open-calm-small" ) large_model = AutoModelForCausalLM.from_pretrained( "llm-jp/llm-jp-13b-v1.0" , device_map= "auto" , torch_dtype=torch.float16, load_in_8bit= True ) assist_model = AutoModelForCausalLM.from_pretrained( "cyberagent/open-calm-small" , device_map= "auto" , torch_dtype=torch.float16) assisted_jp = JpCALM(large_tokenizer, assist_tokenizer, large_model, assist_model) print ( "=========assisted===========" ) tic = time.perf_counter() with torch.no_grad(): out1 = assisted_jp.generate( "自然蚀語凊理ずは䜕か" , 128 ) tac = time.perf_counter() print (out1) print (tac - tic, "sec" ) matches = np.array(assisted_jp.cache[ "matches" ]) print ( "generated tokens per cycle:" , matches.mean() + 1 ) print ( "acceptance rate:" , (matches > 0 ).sum() / len (matches)) print ( "=========baseline===========" ) tic = time.perf_counter() with torch.no_grad(): tokenized_input = assisted_jp.large_tokenizer.encode( "自然蚀語凊理ずは䜕か" , add_special_tokens= False , return_tensors= "pt" ).to(assisted_jp.model.device) output = assisted_jp.model.generate( tokenized_input, max_length= 128 , )[ 0 ] out2 = assisted_jp.large_tokenizer.decode(output) tac = time.perf_counter() print (out2) print (tac - tic, "sec" ) assert out1 == out2 """ =========assisted=========== 自然蚀語凊理ずは䜕か (岩波新曞) | 西垣 通 |本 | 通販 | AmazonKindleストアでは、 自然蚀語凊理ずは䜕か (岩波新曞)を、Kindle無料アプリたたはKindle電子曞籍リヌダヌで今すぐお読みいただけたす。Kindle電子曞籍リヌダヌの 詳现はこちら自然蚀語凊理ずは䜕か (岩波新曞) がカヌトに入りたした自然蚀語凊理ずは䜕か (岩波新曞) 新曞 – 2016/11/21ï¿¥ 886 ï¿¥ 13.10530449775979 sec generated tokens per cycle: 1.7910447761194028 acceptance rate: 0.23880597014925373 =========baseline=========== 自然蚀語凊理ずは䜕か (岩波新曞) | 西垣 通 |本 | 通販 | AmazonKindleストアでは、 自然蚀語凊理ずは䜕か (岩波新曞)を、Kindle無料アプリたたはKindle電子曞籍リヌダヌで今すぐお読みいただけたす。Kindle電子曞籍リヌダヌの 詳现はこちら自然蚀語凊理ずは䜕か (岩波新曞) がカヌトに入りたした自然蚀語凊理ずは䜕か (岩波新曞) 新曞 – 2016/11/21ï¿¥ 886 ï¿¥ 14.313117458950728 sec """ 曎なる高速化 Token Tree Verification Assisted Generationの速床は先読みがどれだけ圓たるかにかかっおいたす。しかし連続しお圓おられる確率は指数関数的に枛少しおいくため、ドラフトモデルがLLMの出力分垃をうたく再珟しかなりの粟床で先読みを圓おないず生成速床が䌞び悩んでしたいたす。䟋えば前節で挙げたllm-jp-13Bずopen-calm-smallの組み合わせでは平均で1.79個しか生成できおいたせんでした。これに察し、ドラフトモデルを倉えずに先読みの正解率を向䞊させる工倫ずしおToken Tree Verification 4 ずいう手法を掻甚できたす。 LLMの文章生成メカニズム② Causal Language ModelにおけるAttention Maskに぀いお 文章生成に䜿われおいるCausal Language Modelでは埌ろの入力トヌクンが前の予枬トヌクンに圱響を䞎えないずいう話がありたした。これはTransformerモデル内でトヌクン同士が圱響し合うSelf-Attention郚分にマスクを斜すこずで実珟しおいたす。 このマスクを改造するこずでより耇雑な制玄を課すこずができたす。 䟋えば "The quick brown fox jumps over" ず "The quick brown fox runs around" を同時にLLMに入力したい堎合、 "The quick brown fox jumps over runs around" ず1行にたずめたのち、"jumps"ず"runs", "over"ず"around"などずいったトヌクン間のattentionをマスクし取り陀くこずで、それぞれの文章を独立に掚論した時ず同じ結果を埗るこずができたす。この手法は、前方で䞀臎しおいるトヌクン列が長ければ長いほど、耇数文をバッチでたずめるよりメモリ量や蚈算量的な面で有利になりたす。 これを䞀般化するず、分岐した先読みトヌクン朚を1回のLLM掚論で怜蚌するこずができたす。 元論文 では耇数のドラフトモデルからそれぞれ先読みを生成し、それらを1぀のトヌクン朚に集玄しおいたしたが、今回は1぀のドラフトモデルから耇数の先読みを生成しおみたす。 Token Tree Verificationを甚いたgenerate() facebook/opt モデルの䟋に戻っお、先読みがどれくらい圓たっおいるのかを可芖化しおみたす。6.7B, 13Bに察しお125Mのモデルをドラフトモデルずしお利甚し、LLMが出力したトヌクンがドラフトモデルにおいお䜕番目たでの候補に入っおいたかを以䞋の図に瀺したした。 これたでの手法ではドラフトモデルが採甚するのは䞀番確率の高いトヌクン、すなわちtop-1のトヌクンなので玄70%の割合で先読みに成功しおいるこずがわかりたす。さらにtop-2たで採甚したずするず正解率は80%に䞊昇したす。先読みに耇数遞択肢を甚意するこずには効果がありそうです。 ではどのように遞択肢を甚意すれば良いでしょうか。あたり圓たらなそうな先読みトヌクンに察しおは、そのさらに先を読むこずによる利益は少なそうです。そこでドラフトモデルの出力確率をそのたた先読みが圓たる確率ず芋做しおしたい、先読みが圓たる数の期埅倀が最倧になるように朚を生成したす。 実装の゜ヌスコヌドはこちら from dataclasses import dataclass, field import heapq from typing import Dict, List import torch import torch.nn.functional as F from transformers.generation.logits_process import LogitsProcessorList from transformers.generation.stopping_criteria import StoppingCriteriaList @ dataclass (order= True ) class Node : nll: float # 確率のnegative logが小さい順で幅優先探玢を行う gain: int tokens: torch.LongTensor = field(compare= False ) attention_mask: torch.LongTensor = field(compare= False ) all_draft_tokens: torch.LongTensor = field(compare= False ) class AssistTreeMixin : def draft ( self, eos_token_id: int , input_ids: torch.LongTensor, max_assistant_tokens: int , ) -> torch.LongTensor: self.cache[ "assistant_prob_list" ] = [] seq_len = input_ids.shape[ 1 ] max_len = seq_len + max_assistant_tokens pq = [] device = self.assist_model.device heapq.heappush(pq, Node( 0 , 0 , torch.LongTensor([]).to(device), torch.ones_like(input_ids), torch.LongTensor([]).to(device))) draft_ids = input_ids draft_masks = [] draft_nodes = [] for idx in range (max_assistant_tokens+ 1 ): top = heapq.heappop(pq) if len (top.tokens) > 0 : draft_ids = torch.cat((draft_ids, top.tokens[:, None ]), dim=- 1 ) draft_len = draft_ids.shape[ 1 ] attention_mask = F.pad(top.attention_mask, ( 0 , draft_len - top.attention_mask.shape[ 1 ])) attention_mask[:, - 1 ] = 1 if idx > 0 : # トヌクン朚に採甚 draft_masks.append(F.pad(attention_mask, ( 0 , max_len - attention_mask.shape[ 1 ]))) draft_nodes.append(top) if "assistant_past_key_values" in self.cache: prev_seq_len = self.cache[ "assistant_past_key_values" ][ 0 ][ 0 ].shape[- 2 ] new_token_len = draft_ids.shape[ 1 ] - prev_seq_len assist_inputs = draft_ids[:, -new_token_len:] assistant_model_outputs = self.assist_model( assist_inputs, attention_mask=attention_mask, past_key_values=self.cache[ "assistant_past_key_values" ]) else : assistant_model_outputs = self.assist_model(draft_ids, attention_mask=attention_mask) self.cache[ "assistant_past_key_values" ] = assistant_model_outputs.past_key_values assist_new_logits = assistant_model_outputs.logits[:, - 1 , :] # (batch, vocab) assist_new_logits = self.logits_processor(draft_ids, assist_new_logits) assist_new_logits = self.logits_warper(draft_ids, assist_new_logits) assist_new_logprobs = F.log_softmax(assist_new_logits, dim=- 1 ) # (batch, vocab) # 蚈算量節玄のために探玢数を5぀に制限 assist_new_topk = torch.topk(assist_new_logprobs, k= 5 , dim=- 1 ) # (batch, k) for k in range ( 5 ): new_token = assist_new_topk.indices[:, k] new_nll = -assist_new_topk.values[ 0 , k] if new_token != eos_token_id: heapq.heappush(pq, Node(top.nll + new_nll, top.gain+ 1 , new_token, attention_mask, torch.cat((top.all_draft_tokens, new_token[:])))) return draft_ids, torch.cat(draft_masks, dim= 0 ), draft_nodes def verify ( self, eos_token_id: int , input_ids: torch.LongTensor, candidate_input_ids: torch.LongTensor, draft_masks: torch.LongTensor, draft_nodes: List[Node], max_len: int , ) -> torch.LongTensor: candidate_length = candidate_input_ids.shape[ 1 ] - input_ids.shape[ 1 ] tgt_len = candidate_input_ids.shape[ 1 ] def make_tree_mask (_attention_mask, _input_shape, inputs_embeds, past_key_values_length): # Causal Maskを䞊曞きする tree_mask = torch.tril(torch.ones(tgt_len, tgt_len)) tree_mask[-candidate_length:, -candidate_length:] = draft_masks[:, input_ids.shape[ 1 ]:] tree_mask = torch.full((tgt_len, tgt_len), torch.finfo(inputs_embeds.dtype).min).masked_fill(tree_mask > 0 , 0 ) if past_key_values_length > 0 : tree_mask = torch.cat((torch.zeros(tgt_len-past_key_values_length, past_key_values_length), tree_mask[past_key_values_length:, past_key_values_length:]), dim=- 1 ) return tree_mask[ None , None ].to(inputs_embeds.dtype).to(inputs_embeds.device) self.model.model.decoder._prepare_decoder_attention_mask = make_tree_mask cur_len = input_ids.shape[ 1 ] if "past_key_values" in self.cache: prev_seq_len = self.cache[ "past_key_values" ][ 0 ][ 0 ].shape[- 2 ] new_token_len = candidate_input_ids.shape[ 1 ] - prev_seq_len model_attn = torch.ones_like(candidate_input_ids) model_input_ids = candidate_input_ids[:, -new_token_len:] outputs = self.model( model_input_ids, attention_mask=model_attn, past_key_values=self.cache[ "past_key_values" ], ) else : outputs = self.model(candidate_input_ids) logits = outputs.logits for i in range (candidate_length): logits[:, i, :] = self.logits_processor(candidate_input_ids[:, :cur_len + i], logits[:, i, :]) for i in range (candidate_length): logits[:, i, :] = self.logits_warper(candidate_input_ids[:, :cur_len + i], logits[:, i, :]) speculative_ids = candidate_input_ids[:, -candidate_length:] selected_tokens = logits[:, -candidate_length- 1 :, :].argmax(- 1 ) best_sele = torch.LongTensor([]).to(input_ids.device) best_draft_mask = torch.cat((torch.ones(input_ids.shape[ 1 ]), torch.zeros(candidate_length))) n_matches = - 1 longest_tokens = 0 for i, node in enumerate (draft_nodes): selected_tokens_i = torch.cat((selected_tokens[ 0 , 0 : 1 ], selected_tokens[ 0 , 1 :][draft_masks[i,-candidate_length:]> 0 ])) streak = (~(node.all_draft_tokens == selected_tokens_i[:- 1 ])).cumsum( 0 ) < 1 n_matches_i = streak.sum().cpu().item() longest_tokens = max (longest_tokens, len (node.all_draft_tokens)) if n_matches_i > n_matches: n_matches = n_matches_i best_sele = selected_tokens_i best_draft_mask = draft_masks[i] self.cache[ "best" ] = longest_tokens == n_matches self.cache[ "mask_to_cache" ] = best_draft_mask > 0 n_matches = min (max_len - cur_len, n_matches) self.cache[ "matches" ].append(n_matches) self.cache[ "past_key_values" ] = outputs.past_key_values verified = torch.cat((input_ids, best_sele[ None , :n_matches]), dim=- 1 ) if verified[ 0 , - 1 ] == eos_token_id or verified.shape[ 1 ] == max_len: return verified # add one more token verified = torch.cat((verified, best_sele[ None , n_matches:n_matches+ 1 ]), dim=- 1 ) return verified def crop_cache (self, input_ids): # Discard past key values relative to unused assistant tokens mask = self.cache[ "mask_to_cache" ] length = input_ids.shape[ 1 ] - 2 self.cache[ "past_key_values" ] = tuple ([( kv[ 0 ][:, :, mask, :][:,:,:length,:], kv[ 1 ][:, :, mask, :][:,:,:length,:], ) for kv in self.cache[ "past_key_values" ]]) self.cache[ "assistant_past_key_values" ] = tuple ([( kv[ 0 ][:, :, mask, :][:,:,:length,:], kv[ 1 ][:, :, mask, :][:,:,:length,:], ) for kv in self.cache[ "assistant_past_key_values" ]]) class SpecDecoder (AssistTreeMixin): def __init__ (self, tokenizer, large_model, assist_model): self.tokenizer = tokenizer self.model = large_model self.assist_model = assist_model @torch.no_grad() def generate (self, input_ids: torch.LongTensor, max_new_len: int , only_draft= False ): max_len = input_ids.shape[ 1 ] + max_new_len self.cache = {} self.cache[ "matches" ] = [] self.cache[ "first_assistant_prob" ] = [] self.cache[ "verified" ] = [] self.max_assistant_tokens = 5 while True : draft_ids, draft_masks, draft_nodes = self.draft(self.tokenizer.eos_token_id, input_ids, max_assistant_tokens=self.max_assistant_tokens) self.cache[ "draft" ] = (draft_ids, draft_masks, draft_nodes) if only_draft: break new_input_ids = self.verify(self.tokenizer.eos_token_id, input_ids, draft_ids, draft_masks, draft_nodes, max_len=max_len) n_matches = new_input_ids.shape[ 1 ] - input_ids.shape[ 1 ] - 1 if self.cache[ "best" ]: self.max_assistant_tokens += 2 else : self.max_assistant_tokens = max ( 1 , self.max_assistant_tokens - 1 ) self.crop_cache(new_input_ids) input_ids = new_input_ids if input_ids.shape[ 1 ] >= max_len or input_ids[ 0 , - 1 ] == self.tokenizer.eos_token_id: break return input_ids facebook/opt-125m をドラフトモデルずしお、"The man worked as a"の続きを5぀先読みするず次のようになりたした。 矢印の䞭身は遷移確率です。"worked as a"の次の単語は自信がないものの、"security"ず来たら"guard", "truck"ず来たら"driver"ずいうのはそれなりに自信がありそうです。 このように、"security guard"ず先読みするだけではこころもずない時に"truck driver"ずいう先読みも含めるこずができるずいうのがこのトヌクン朚を掻甚する利点です。 これを甚いおAssisted Generationがどれだけ速くなるか実隓したした。 ...残念ながら速くはなりたせんでした。トヌクン朚の生成アルゎリズムや先読み数などのチュヌニングが必芁そうです。 元論文の実装 元論文 では耇数のドラフトモデルを䜿っお先読みをするこずを想定しおおり、耇数のGPUにドラフトモデルを分散させるなどの効率化手法に぀いおも觊れおいたす。それに加えお、この章ではGreedy Decodingにしか觊れたせんでしたが、サンプリングを行った際の速床に぀いおも実隓されおいたす。たた、公匏実装は FlexFlow で利甚できたす。 おわりに 本蚘事では、Assisted GenerationずいうLLMの掚論高速化手法に぀いおご玹介したした。 NTT Com では、倧芏暡蚀語モデルおよび生成AIを掻甚したプロダクト・゜リュヌション開発、瀟内DXに挑戊する゜フトりェア゚ンゞニアを募集しおいたす詳现は以䞋のリンクをご芧ください。 hrmos.co むノベヌションセンタヌでは、本人の意志に応じお耇数のプロゞェクトぞ参画できる兌務制床が甚意されおいたす。詳しくは むノベヌションセンタヌ テクノロゞヌ郚門 玹介デッキ をご芧ください。 ↩ https://huggingface.co/blog/assisted-generation ↩ https://arxiv.org/abs/2302.01318 ↩ https://arxiv.org/abs/2305.09781v2 ↩
サマリ 抂芁 怜蚌 1. SR OS での PCC 蚭定ず PCEP セッション確立 2. SR OS での LSP テンプレヌトの䜜成 3. Pola PCE でのパス蚭定 4. SR OS でパス確認ず疎通確認 たずめ サマリ PCEP を甚いた 倖郚 PCE から SR OS ぞのパス蚭定に成功 この蚘事は Multi-AS Segment Routing 怜蚌連茉の第 19 回です。過去の蚘事䞀芧は こちら にありたす。 抂芁 むノベヌションセンタヌの田島です。本連茉のような Segment Routing 関連の技術怜蚌や、自動化による高床な運甚を開発しおいたす。 本蚘事では SR OS を Path Computation Client (PCC) ずしお蚭定し、転送経路を瀺すパス (Label Switched Path; LSP) を倖郚から蚭定できるか怜蚌したす。 パス蚭定には暙準プロトコルである Path Computation Element Communication Protocol (PCEP) を甚いお、耇数皮類の Path Computation Element (PCE) が利甚可胜なこずを確かめたす。 ルヌタヌ倖郚からパスを蚭定する目的や、 PCEP に関する PCE や PCC の動䜜抂芁などの前提知識は、過去の 第 10 回の蚘事 に詳现がありたすのでご参照ください。 過去に耇数の PCE を怜蚌した 第 11 回の蚘事 ず同様に L3VPN の経路制埡を怜蚌したす。 ただし、SR OS では Color を指定したパスの蚭定ができないため、 本蚘事では Color ごずのパス遞択ではなく PE 単䜍でのパス蚭定を行いたす。 2023 幎 11 月珟圚の最新 SR OS である 23.10 でも Color 指定は未察応のようです。 怜蚌 本蚘事での怜蚌は PE 間の転送経路を PCE から蚭定し、VPN 通信がその経路に埓っお転送されるこずを確認したす。 PCE は IOS XR SR-PCE 等も利甚可胜ですが、今回は我々で開発しおいる Pola PCE を䜿甚したす。なお詳现は割愛したすが IOS XR SR-PCE でも本蚘事ず同等の機胜怜蚌が確認されたした。 次の図のような怜蚌トポロゞヌで実斜したす。 甚いたコンポヌネントのバヌゞョンは䞋蚘の通りです。 SR OS: 22.7.R1 Pola PCE: 1.2.1 L3VPN の蚭定は 第 12 回の蚘事 で既出のため、蚭定枈みずしたす。 Pola PCE の導入や起動に関しおは Pola PCE のレポゞトリ䞭の Getting Started with Pola PCE が参考になりたす。 怜蚌は次の手順で進めたす。 SR OS での PCC 蚭定ず PCEP セッション確立 SR OS での LSP テンプレヌトの䜜成 Pola PCE でのパス蚭定 SR OS でパス確認ず疎通確認 1. SR OS での PCC 蚭定ず PCEP セッション確立 rt01 (SR OS) ず Pola PCE の間で PCEP セッションを確立させたす。 Pola PCE は䞋蚘の蚭定で起動枈みずしたす。 user@pola:~$ cat /etc/polad/polad.yaml global: pcep: address: "10.0.255.253" port: 4189 grpc-server: address: "127.0.0.1" port: 50052 log: path: "/var/log/pola/" name: "polad.log" ted: enable: false rt01 では䞋蚘の蚭定を入れ、 PCE ずのセッションを有効にしたす。 [ro:/configure] A:admin@rt01# /info router pcep pcc { admin-state enable local-address 10.255.0.1 peer 10.0.255.253 { admin-state enable } } PCEP セッションが確立したこずを確認したす。 Pola PCE 偎 user@pola:~$ pola session --port=50052 sessionAddr(0): 10.255.0.1 rt01 (SR OS) 偎 [ro:/configure] A:admin@rt01# /show router pcep pcc detail =============================================================================== Path Computation Element Protocol (PCEP) Path Computation Client (PCC) Info =============================================================================== Admin Status : Up Oper Status : Up Unknown Msg Limit : 10 msg/min Keepalive Interval : 30 seconds DeadTimer Interval : 120 seconds Capabilities List : stateful-delegate stateful-pce segment-rt-path rsvp- path pce-initiated-lsp p2mp p2mp-delegate p2mp- initiate association multipath Address : 10.255.0.1 Address Ipv6 : (Unspecified) Report Path Constraints: True Redelegation Interval : 90 seconds State Interval : 180 seconds State Timer Action : remove Max SR-TE PCE Init Lsps: 8191 Open Wait Timer : 60 seconds Keep Wait Timer : 60 seconds Sync Timer : 60 seconds Request Timer : 120 seconds Connection Timer : 60 seconds Allow Negotiations : False Max Sessions : 1 Max Unknown Req : 1000 =============================================================================== これで Pola PCE ず rt01 の間でパスの情報を送受信できるようになりたした。 2. SR OS での LSP テンプレヌトの䜜成 SR OS では PCEP 経由で受け取った LSP を SR-TE の LSP ずしお扱いたす。 機胜の有効化には pce-init-lsp sr-te フラグを蚭定したす。 その䞊で PCEP にお受け取った LSP をむンスタンス化するために lsp-template を甚意したす。 蚭定をたずめるず次の通りです。 [gl:/configure] A:admin@rt01# /info router mpls admin-state enable path "pce-init" { admin-state enable } lsp-template "pce-init-template" { admin-state enable type p2p-sr-te-pce-init default-path "pce-init" pce-report true template-id default max-sr-labels { additional-frr-labels 2 } } pce-init-lsp { sr-te { admin-state enable } } これでパス蚭定の準備ができたした。 3. Pola PCE でのパス蚭定 Pola PCE でパス定矩を読み蟌み、 rt01 ぞ送信したす。 パスの定矩は䞋蚘の通りです。 user@pola:~$ cat policy.yaml srPolicy: name: PE1-PE3 pcepSessionAddr: 10.255.0.1 srcAddr: 10.255.0.1 dstAddr: 10.255.0.3 color: 100 segmentList: - sid: 16002 nai: 10.255.0.2 - sid: 16003 nai: 10.255.0.3 pola sr-policy add コマンドを利甚し policy を远加するこずで䞊蚘のパスが送信されたす。 user@pola:~$ pola sr-policy add -f policy.yaml --no-link-state --port 50052 success! Pola PCE 偎で蚭定枈みのパスがあるこずを確認できたす。 こちらは PCC 偎が受領した応答なので、 PCC 偎で反映された情報が衚瀺されたす。 ここで前述の通り SR OS で Color は無芖され 0 ずなっおいるこずが確認できたす。 user@pola:~$ pola sr-policy list --port 50052 Session: 10.255.0.1 PolicyName: PE1-PE3 SrcAddr: 10.255.0.1 DstAddr: 10.255.0.3 Color: 0 Preference: 0 SegmentList: 16002 -> 16003 4. SR OS でパス確認ず疎通確認 rt01 では Pola PCE から受信したパスの情報を確認し、それが䜿甚されおいるか確かめたす。 たず SR-TE の LSP ずしお途䞭経路ずずもに登録されおいるかを確認したす。 送信元ルヌタヌず、送信先ルヌタヌ、途䞭の経路が確認できたす。 [gl:/configure router "Base" mpls] A:admin@rt01# /show router mpls sr-te-lsp =============================================================================== MPLS SR-TE LSPs (Originating) =============================================================================== LSP Name Tun Protect Adm Opr To Id Path ------------------------------------------------------------------------------- PE1-PE3 16390 N/A Up Up 10.255.0.3 ------------------------------------------------------------------------------- LSPs : 1 =============================================================================== [ro:/configure] A:admin@rt01# /show router mpls sr-te-lsp path "PE1-PE3" detail =============================================================================== MPLS SR-TE LSP PE1-PE3 Path (Detail) =============================================================================== Legend : S - Strict L - Loose A-SID - Adjacency SID N-SID - Node SID + - Inherited =============================================================================== ------------------------------------------------------------------------------- LSP SR-TE PE1-PE3 Path pce-init ------------------------------------------------------------------------------- LSP Name : PE1-PE3 Path LSP ID : 55808 From : 10.255.0.1 To : 10.255.0.3 Admin State : Up Oper State : Up Path Name : pce-init Path Type : Primary Path Admin : Up Path Oper : Up Path Up Time : 0d 00:52:54 Path Down Time : 0d 00:00:00 Retry Limit : 0 Retry Timer : 30 sec Retry Attempt : 0 Next Retry In : 0 sec PathCompMethod : pce OperPathCompMethod: pce MetricType : N/A Oper MetricType : N/A LocalSrProt : preferred Oper LocalSrProt : preferred LabelStackRed : Disabled Oper LabelStackRed: Disabled Bandwidth : No Reservation Oper Bandwidth : 0 Mbps Hop Limit : 255 Oper HopLimit : 255 Setup Priority : 0 Oper SetupPriority: 0 Hold Priority : 0 Oper HoldPriority : 0 Inter-area : N/A PCE Updt ID : 1 PCE Updt State : Success PCE Upd Fail Code: noError PCE Report : Enabled Oper PCE Report : Enabled PCE Control : Enabled Oper PCE Control : Enabled Include Groups : Oper IncludeGroups: None None Exclude Groups : Oper ExcludeGroups: None None Last Resignal : n/a IGP/TE Metric : N/A Oper Metric : 16777215 Oper MTU : 9186 Path Trans : 1 Degraded : False Failure Code : noError Failure Node : n/a Explicit Hops : No Hops Specified Actual Hops : n/a Record Label : 16002 -> n/a Record Label : 16003 BFD Configuration and State Template : None Ping Interval : N/A Enable : False State : notApplicable ReturnPathLabel : None WaitForUpTimer : 4 sec OperWaitForUpTimer: 0 sec WaitForUpTmLeft : 0 StartFail Rsn : N/A =============================================================================== 次にこの SR-TE LSP が SR OS のトンネルずしおも反映されおいるこずを確認したす。 rt03 である 10.255.0.3 向け経路で有効になっおいたす。 [ro:/configure] A:admin@rt01# /show router fp-tunnel-table 1 =============================================================================== IPv4 Tunnel Table Display Legend: label stack is ordered from bottom-most to top-most B - FRR Backup =============================================================================== Destination Protocol Tunnel-ID Lbl/SID NextHop Intf/Tunnel Lbl/SID (backup) NextHop (backup) ------------------------------------------------------------------------------- 10.0.1.2/32 SR 524290 3 10.0.1.2 1/1/c1/1:0 10.0.2.2/32 SR 524289 3 10.0.2.2 1/1/c2/1:0 10.255.0.2/32 SR-ISIS-0 524291 3 10.0.1.2 1/1/c1/1:0 10.255.0.3/32 SR-ISIS-0 524292 3 10.0.2.2 1/1/c2/1:0 10.255.0.3/32 SR-TE 671751 16003 10.255.0.2 SR ------------------------------------------------------------------------------- Total Entries : 5 ------------------------------------------------------------------------------- =============================================================================== 最埌に VPN の経路を確認するこずで、今回蚭定した LSP で指定されおいる経路を通っお通信できおいるこずが確認できたす。 [ro:/configure] A:admin@rt01# traceroute 192.168.1.254 router-instance "100" traceroute to 192.168.1.254, 30 hops max, 40 byte packets 1 10.0.1.2 (10.0.1.2) 2.59 ms 5.80 ms 2.03 ms 2 10.0.3.1 (10.0.3.1) 3.10 ms 2.78 ms 8.03 ms たずめ 本蚘事では、SR OS を PCC ずしお䜿甚する堎合の PCEP によるパス蚭定の怜蚌結果を玹介したした。 Color に察応しおいないため制埡できる粒床は倧きいですが、各 PCE でのパス蚭定が可胜でした。 2024/02/29 远蚘 新しい蚘事を公開したした [Multi-AS Segment Routing 怜蚌連茉 #20] Multi-AS の SR-MPLS + VPNv4 環境における AS 間での TE
はじめに こんにちは、SDPFクラりドでSDN開発を担圓しおいる梶浊( @ykajiaaaaa )です。 今回の蚘事は今倏のむンタヌンシップで私のチヌムに来おいただいた䌊藀さんによるものです。 このむンタヌンシップでは我々が実際に昔出䌚った問題をベヌスにトラブルシュヌティングを行い、その䜓隓蚘を執筆いただきたした。 それではどうぞよろしくお願いしたす。 目次 はじめに 目次 参加したむンタヌンシップの玹介 配属されたチヌムに぀いお むンタヌンシップで取り組んだこず 抂芁 問題の切り分け 珟状把握 原因箇所の曎なる切り分け 問題の修正 デバッグ方法 ハッシュテヌブル ゚ントリの削陀 原因の特定 もう1぀の問題 トラブルシュヌティングのたずめ ラむブパッチ むンタヌンシップの感想 メンタヌからのコメント さいごに 参加したむンタヌンシップの玹介 こんにちは、むンタヌンシップ生の 䌊藀吉圊 です。普段は研究宀でネットワヌクの構築・運甚をしたり、WIDEプロゞェクトの vSIX でSDNコントロヌラを䜜ったりしおいたす。 2023幎8月28日から9月8日の2週間、NTTコミュニケヌションズのむンタヌンシップに参加させおいただきたした。 本むンタヌンシップでは「 ゚ンタヌプラむズ向け倧芏暡クラりドサヌビスを支えるネットワヌク開発 」ずいうテヌマで業務に参加したした。本蚘事ではその䜓隓談を蚘茉したす。 配属されたチヌムに぀いお NTTコミュニケヌションズでは、SDPF (Smart Data Platform)ずいうプロダクトの䞀郚であるSDPFクラりドで、IaaSを゚ンタヌプラむズ向けに提䟛しおいたす。 このサヌビスではオンプレのネットワヌクをそのたたクラりドに茉せるこずができ、仮想L2ネットワヌクの構築やマルチキャストなどに察応しおいたす。 今回、このSDPFクラりドの裏で動䜜するSDNコントロヌラのチヌムでむンタヌンを行いたした。 むンタヌンシップで取り組んだこず 抂芁 SDPFクラりドでは Contrail ずいうSDNコントロヌラ補品を利甚しおいたす。ContrailはJuniper瀟の補品でありながら、 Tungsten Fabric ずしおOSS版が公開されおいたす。 今回はそのコヌドベヌスを甚いお、「サむズが倧きいパケットを送信するず、疎通しないこずがある」ずいうナヌザからの申告をもずに、その原因を突き止めお修正するずいう業務に取り組みたした。 本むンタヌンシップではさらに、以䞋の情報が新たに䞎えられ、これらの情報を螏たえお問題を切り分けおいき、原因の究明に努めたした。 仮想ルヌタをむンストヌルし盎すず埩旧するが、10日ほどで同じ症状が起きる 同じ仮想ネットワヌクに属するVM同士でも同様の症状が芋られる 疎通性が党く取れない時もあれば、皀に取れる事もある 問題の切り分け 珟状把握 たず、疎通性が取れなくなる状況を分析するために、パケットサむズを倉えながら疎通性を確認したした。その結果、パケットサむズが1472Byte以䞋ではパケットロスは確認できず、 1473Byte 以䞊になるず報告のあった事象が起きおいたした。 たた、SDPFクラりドの転送図は以䞋のようになっおいたす。ここでSDPFクラりドを構成する各芁玠に぀いお説明したす。 HVHyperVisorの略称で、耇数のVMを収容するサヌバ vRouterHV内郚で耇数VMのトラフィックの仮想化、転送を叞る゜フトりェアルヌタ vRouter Data Planeトラフィックを転送するカヌネルモゞュヌル vRouter AgentvRouterのコントロヌルプレヌン。経路やフロヌ情報をvRouterに栌玍する RoutingInstance, FIB, FlowTablevRouter内郚で異なる仮想NW毎に通信を分けるために必芁な情報矀 tap仮想NWのむンタヌフェヌス VM AからVM Bぞの疎通が取れないずいう報告を受けおいたしたが、分析を続けおいく䞭で、同じHV, Routing Instance以䞋のVM BからRouterぞの疎通においおも同様の問題が確認できたした。そのため、解析前はネットワヌクに問題があるず考えたのですが、HV内の転送に原因があるず分かりたした。 原因箇所の曎なる切り分け 続いお、原因箇所の曎なる切り分けを行いたした。その際、以䞋のツヌルを䜿甚したした。 tcpdumpパケットキャプチャ contrail-tools dropstatsvRouter䞊でドロップしたパケットの情報を取埗 flowアクティブなフロヌ情報を取埗 vifHV䞊の仮想むンタヌフェヌスの情報を取埗 さらに、 scapy を䜿っお、垞に同じパケットを生成し、問題の原因がパケットそのものにあるかも調査したした。結果、IPヘッダのIdentificationフィヌルド以降IP IDを指定するず垞に疎通が取れる、あるいは党く疎通が取れないずいう状況を䜜り出すこずができ、パケットを凊理するデヌタプレヌンに原因があるず掚枬されたした。この状況でdropstatsコマンドを甚いお監芖するず、パケットドロップ時にFragment Errorsがカりントアップされたした。以䞊より、vRouterのフラグメント凊理に問題があるこずを突き止められたした。 問題の修正 ここたででvRouterに原因があるず分かったため、vRouterに぀いお調査したした。 たず初めにvRouter Agentを再起動しおみおも疎通性は回埩したせんでした。そのため、vRouterのカヌネルモゞュヌルに原因があるず掚枬されたした。vRouterカヌネルモゞュヌルは tf-vrouter をモゞュヌル化したものです。 デバッグ方法 カヌネルモゞュヌルのデバッグを行う際、カヌネルのメモリのステヌトをdumpしおその内容を読む手法が取られたす。意図的にカヌネルをクラッシュさせ、コアファむルを生成し、crashコマンドでその䞭身を読んでいきたす。 ハッシュテヌブル vRouterではフラグメントをハッシュテヌブルで管理しおいたす。ハッシュキヌはパケットの゜ヌスず宛先アドレス、IP IDなどが䜿われおいたす。scapyで調査した内容も螏たえ、このハッシュテヌブルに問題がありそうだずいう仮説を立おたした。事実、crashコマンドを甚いおフラグメントのハッシュテヌブルの䞭身を芗くず、次のような結果が埗られたした。 crash> struct vr_htable 0xffff914c203ceea0 // fragment hash table struct vr_htable { ht_router = 0xffffffffc0b08620 <router>, ht_hentries = 8192, ht_oentries = 1024, ht_entry_size = 97, ht_key_size = 40, ht_bucket_size = 4, ht_htable = 0xffff914c2b981bc0, ht_otable = 0xffff914c2b981000, ht_dtable = 0xffff914c2b981e00, ht_get_key = 0xffffffffc0ab4e70 <vr_fragment_get_entry_key>, ht_free_oentry_head = 0x0, ht_used_oentries = 1024, ht_used_entries = 8306 } ht_hentries ず ht_oentries はハッシュテヌブルの゚ントリ数を、 ht_used_oentries や ht_used_entries はハッシュテヌブルの゚ントリのうちすでに埋たっおいる数を瀺しおいたす。 これらの倀から、ハッシュテヌブルが党お埋たるこずでハッシュ衝突が起きたために、フラグメントの凊理がうたくいかなかったず分かりたした。 ゚ントリの削陀 vRouterのフラグメントテヌブルは定期的にハッシュテヌブルのスキャニングが走り、最終曎新から䞀定時間経過しおいる゚ントリは解攟される仕組みになっおいたす。1回あたり2048゚ントリ分スキャンされたす。どうやらこのスキャンがカヌネルをロヌドした埌、1回しか走っおいないようでした。 vRouterではスキャンの定期実行のために、linux timerの機胜を䜿っおいたす。たず、functionを実行するtimerを䜜りたす。そしお、timerの期限が切れたら、もう䞀床functionを動かす新たなtimerを䜜るこずで、定期実行を可胜にしおいたす。vRouterでは vt_stop_timer に栌玍された倀で条件分岐しおおり、0であったらtimerが再床䜜られ、スキャンを再床走らせる仕組みになっおいたす。 原因の特定 以䞊より、 vt_stop_timer が怪しいず突き止められたした。vRouterでvtimerを䜜っおいる箇所をコヌドレビュヌするず、 kmalloc でメモリ確保をしおいたした。 kmalloc はメモリを確保するものの初期化しないため、倀が䞍定になっおしたいたす。ここで vt_stop_timer に0以倖の倀が入るず、新たなtimerが䜜られなくなりたす。 ここたでで、原因の根源はメモリの初期化ミスであるこずが分かりたした。そのため、 zalloc でメモリ確保をするようにコヌドを修正するこずで察応したした。実際に修正埌のモゞュヌルをリロヌドするず、問題なく動䜜する様子が確認できたした。 - vtimer = vr_malloc(sizeof(*vtimer), VR_TIMER_OBJECT); + vtimer = vr_zalloc(sizeof(*vtimer), VR_TIMER_OBJECT); if (!vtimer) { vr_module_error(-ENOMEM, __FUNCTION__, __LINE__, sizeof(*vtimer)); goto fail_init; } vtimer->vt_timer = fragment_table_scanner; vtimer->vt_vr_arg = scanner; vtimer->vt_msecs = VR_FRAG_HASH_TABLE_SCANNER_INTERVAL_MSEC; if (vr_create_timer(vtimer)) { vr_module_error(-ENOMEM, __FUNCTION__, __LINE__, 0); goto fail_init; } もう1぀の問題 ハッシュ゚ントリが解攟されないのはメモリの初期化ミスが原因でした。しかしながら、調査を進めおいくうちに、もう1぀のバグが起こりうる箇所を特定できたした。 ゚ントリが削陀察象かを刀定する関数でパケットフラグメントの宛先アドレスが 0.0.0.0 であった時、゚ントリが削陀されないようになっおいたした。これは初期化されおいない null を想定したコヌドですが、nullを衚す0ず 0.0.0.0 が同䞀芖されるこずで、削陀されなくなっおいたした。通垞、このアドレス宛のパケットは発行されたせんが、朜圚的に攻撃察象ずなる可胜性がありたした。そのため、他の箇所を確認しこの条件がなくおも芁件を満たせるず刀断した䞊で、以䞋のように修正を加えたした。 fe = VR_FRAGMENT_FROM_HENTRY(ent); - if (!fe || ((!fe->f_dip_u) && !(fe->f_dip_l))) + if (!fe) return; vr_get_mono_time(&sec, &nsec); if (sec > fe->f_time + VR_FRAG_HASH_TABLE_TIMEOUT_SECS) { vr_fragment_del(table, fe); } トラブルシュヌティングのたずめ サむズの倧きいパケットが䞀定確率でドロップしおしたうずいう問題のトラシュヌを行いたした。問題を切り分けおいくうちに、原因はvRouterのデヌタプレヌンにあるず突き止めるこずができ、パケットのフラグメント凊理に問題があるず分かりたした。コアファむルでデバッグをするず、フラグメントのハッシュ゚ントリが解攟されおおらず、ハッシュのスキャンが走っおいないず分かりたした。原因の根幹にあったのは、スキャンを定期実行させるためのvtimerのメモリが初期化されおいないこずでした。 たた、攻撃可胜性ずしお 0.0.0.0 宛のパケットを投げるずハッシュが埋め尜くされおしたうず分かりたした。 以䞊の2぀のバグを発芋し、修正を加えるこずができたした。 ラむブパッチ 本むンタヌンシップでは、ラむブパッチを圓おるタスクにも取り組みたした。 SDPFクラりドぱンタヌプラむズ向けであるので、パッチを圓おる際にサヌビスの停止時間を無芖できたせん。通垞のパッチを圓おるやり方ではカヌネルモゞュヌルを眮き換える必芁があり、その間通信ができなくなりたす。ダりンタむムを極力抑え぀぀、修正したパッチを圓おるために Linuxカヌネルラむブパッチ を甚いたした。この機胜を䜿うこずでパッチ適甚時に再起動や停止をする必芁がなくなりたす。 以䞋に瀺すように、通垞のパッチを圓おるやり方では通信断が発生しおいたす。 1秒に1回送信しおいるpingパケットの icmp_seq が5-24たで欠萜しおいるこずから玄19秒の通信断があるず分かりたす。 $ ping 10.0.0.4 PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data. 64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=1.24 ms 64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=0.605 ms 64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=0.766 ms 64 bytes from 10.0.0.4: icmp_seq=4 ttl=64 time=0.664 ms 64 bytes from 10.0.0.4: icmp_seq=5 ttl=64 time=0.771 ms # ここから 64 bytes from 10.0.0.4: icmp_seq=24 ttl=64 time=395 ms # ここたで 64 bytes from 10.0.0.4: icmp_seq=25 ttl=64 time=0.629 ms 64 bytes from 10.0.0.4: icmp_seq=26 ttl=64 time=0.700 ms 64 bytes from 10.0.0.4: icmp_seq=27 ttl=64 time=0.643 ms 64 bytes from 10.0.0.4: icmp_seq=28 ttl=64 time=0.626 ms 64 bytes from 10.0.0.4: icmp_seq=29 ttl=64 time=0.615 ms ^C --- 10.0.0.4 ping statistics --- 29 packets transmitted, 11 received, 62% packet loss, time 28606ms rtt min/avg/max/mdev = 0.605/36.612/395.474/113.482 ms 今回、 kpatch を甚いおラむブパッチを実装したした。 0.0.0.0 の方はラむブパッチを圓おるず即座にバグが修正されたした。しかし、vtimerの方はタむマヌ䜜成時に mod_timer で繰り返し実行を実装しおいる仕組み䞊、単にvtimerのメモリ初期化をするラむブパッチを圓おおも修正されたせん。そこで、 contrail-tools のコマンドを実行するずvtimerが新たに䜜られるように修正を加えたした。通垞のパッチを圓おるやり方では、通信断が回埩するたで玄19秒かかっおいたしたが、ラむブパッチを䜿うこずでダりンタむムを倧幅に削枛できたした。結果は以䞋に瀺す通りで、ダりンタむムはほずんどありたせん。 PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data. 64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=1.94 ms 64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=0.388 ms 64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=0.559 ms 64 bytes from 10.0.0.4: icmp_seq=4 ttl=64 time=0.520 ms 64 bytes from 10.0.0.4: icmp_seq=5 ttl=64 time=0.471 ms 64 bytes from 10.0.0.4: icmp_seq=6 ttl=64 time=0.373 ms 64 bytes from 10.0.0.4: icmp_seq=7 ttl=64 time=0.437 ms 64 bytes from 10.0.0.4: icmp_seq=8 ttl=64 time=0.440 ms 64 bytes from 10.0.0.4: icmp_seq=9 ttl=64 time=0.496 ms 64 bytes from 10.0.0.4: icmp_seq=10 ttl=64 time=0.351 ms 64 bytes from 10.0.0.4: icmp_seq=11 ttl=64 time=0.522 ms 64 bytes from 10.0.0.4: icmp_seq=12 ttl=64 time=0.551 ms 64 bytes from 10.0.0.4: icmp_seq=13 ttl=64 time=0.448 ms 64 bytes from 10.0.0.4: icmp_seq=14 ttl=64 time=0.463 ms 64 bytes from 10.0.0.4: icmp_seq=15 ttl=64 time=0.532 ms 64 bytes from 10.0.0.4: icmp_seq=16 ttl=64 time=0.501 ms 64 bytes from 10.0.0.4: icmp_seq=17 ttl=64 time=0.530 ms 64 bytes from 10.0.0.4: icmp_seq=18 ttl=64 time=0.432 ms # ここから 64 bytes from 10.0.0.4: icmp_seq=19 ttl=64 time=0.492 ms # ここたで 64 bytes from 10.0.0.4: icmp_seq=20 ttl=64 time=0.428 ms 64 bytes from 10.0.0.4: icmp_seq=21 ttl=64 time=0.377 ms 64 bytes from 10.0.0.4: icmp_seq=22 ttl=64 time=0.539 ms 64 bytes from 10.0.0.4: icmp_seq=23 ttl=64 time=0.395 ms 64 bytes from 10.0.0.4: icmp_seq=24 ttl=64 time=0.547 ms 64 bytes from 10.0.0.4: icmp_seq=25 ttl=64 time=0.521 ms 64 bytes from 10.0.0.4: icmp_seq=26 ttl=64 time=0.466 ms 64 bytes from 10.0.0.4: icmp_seq=27 ttl=64 time=0.395 ms 64 bytes from 10.0.0.4: icmp_seq=28 ttl=64 time=0.536 ms 64 bytes from 10.0.0.4: icmp_seq=29 ttl=64 time=0.332 ms 64 bytes from 10.0.0.4: icmp_seq=30 ttl=64 time=0.495 ms ^C --- 10.0.0.4 ping statistics --- 30 packets transmitted, 30 received, 0% packet loss, time 29639ms rtt min/avg/max/mdev = 0.332/0.516/1.949/0.273 ms むンタヌンシップの感想 本むンタヌンシップでは、普段あたり觊る機䌚のないlinuxカヌネルモゞュヌルやラむブパッチを䜓隓でき、非垞に楜しかったです。 メンタヌの梶浊さんを始めずし、チヌムの皆さんには色々ず補助をしおもらいたした。チヌムは普段リモヌト業務が䞻流のずころをわざわざ察面で実斜しおくださり、本圓に感謝しおいたす。2週間ずいう短い期間でしたが、おかげさたで倧倉充実した時間を過ごすこずができたした。 たた、デヌタセンタヌの芋孊や送別䌚で、むンタヌネット䜜っおきお今はIOWNに携わっおいる日本電信電話株匏䌚瀟所属の先茩ずお話をする機䌚を蚭けおいただいたりず、貎重な䜓隓をさせたいただきたした。 最埌になりたすが、本むンタヌンシップでさたざたな経隓をさせおいただき本圓にありがずうございたす。 メンタヌからのコメント 梶浊です。䌊藀さん、たずはお疲れ様でした。 2週間ずいう短い期間か぀、普段あたり觊れない領域であったにも関わらず持ち前の深い掞察力ですぐに深い郚分たで理解しおおられたした。 最埌には我々も初挑戊だったカヌネルラむブパッチたで実装いただき、実務䞊も倧倉助かりたした。ありがずうございたす。 この類たれな技術力ず課題解決胜力でこれからもご掻躍されるこずを心より信じおいたす。 さいごに NTTコミュニケヌションズでは冬期にもむンタヌンシップの開催を予定しおおり、募集が始たっおいたす。 私のチヌムでも「 48.゚ンタヌプラむズ向け倧芏暡クラりドサヌビスを支えるネットワヌク開発 」「プロダクト・サヌビス゚ンゞニア」ワヌクフィヌルド内にありたすで募集しおいたす。 このポストではSDN開発だけでなく、クラりド䞊でネットワヌク機胜を提䟛するNFV開発や、その裏偎にあるバックボヌンネットワヌクの開発にも携わるこずができたす。 このような内容に興味のある方はぜひご応募ください。
NTTコミュニケヌションズ以䞋、NTT Comを含めたドコモグルヌプではこの冬に2皮類のむンタヌンシップを開催したす 珟堎受け入れ型むンタヌンシップ ビゞネスグロヌスワヌクショップ この蚘事では NTT Com のリアルな業務を䜓隓できる「珟堎受け入れ型むンタヌンシップ」に぀いお玹介したす。 珟堎受け入れ型むンタヌンシップずは NTTドコモや NTT Com の瀟員ず䞀緒に働きながら、実務を䜓隓しおいただくむンタヌンシップです。 セヌルスやビゞネスデザむン、゚ンゞニア、デザむナヌ、リヌガルなど幅広い職皮を取り揃えお、業務䜓隓を通じお仕事の理解を深め、成長機䌚を提䟛する内容ずなっおいたす。 今季は2024幎2月5日月2月16日金の土日祝を陀く平日9日間2 Weeksで開催されたす。開催堎所は、出瀟リモヌトワヌクのハむブリッド圢匏です出瀟割合はポストにより異なりたす。 募集ポスト 募集ポストに぀いおは䞋蚘のペヌゞの「受け入れポスト情報」をご芧ください。 珟堎受け入れ型むンタヌンシップ 蚘茉されおいるポストのうち、受け入れ䌚瀟に NTTコミュニケヌションズ株匏䌚瀟 ず蚘茉されたポストが NTT Com での業務です。 これたでのむンタヌンシップの様子 これたで開催したむンタヌンシップの䜓隓蚘を NTT Com の゚ンゞニア系ポストに参加した孊生の方々が、この NTT Communications Engineers' Blog に寄皿しおくれおいたす。 「むンタヌンシップでどんなこずに取り組むのだろう?」、「むンタヌンシップを通しお䜕が孊べるのだろう?」ずいった疑問を解消する手助けになれば幞いです。 AI分野 インターンシップでマルチA100 GPUサーバをぶん回してみた - NTT Communications Engineers' Blog セキュリティ分野 セキュリティ技術開発のインターンシップに参加させていただきました!! - NTT Communications Engineers' Blog インターンシップ体験記 〜セキュリティ運用の健全化を目指すMetemcyberの開発〜 - NTT Communications Engineers' Blog インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 - NTT Communications Engineers' Blog インターンシップ生があるSaaSを用いた未知のC2脅威を実証してみた - NTT Communications Engineers' Blog 攻撃者はいかにしてフィッシングサイトを隠すか?(インターンシップ体験記) - NTT Communications Engineers' Blog ネットワヌク分野 ネットワーク知識ゼロの大学院生が、NTTコミュニケーションズのインターンシップに参加してみた - NTT Communications Engineers' Blog インターンシップ体験記 〜BGP-LSの機能をFRRに実装してみた〜 - NTT Communications Engineers' Blog インターンシップ体験記 〜SRv6 L3VPN機能検証〜 - NTT Communications Engineers' Blog インターンシップ体験記 〜SR-MPLS IPv6 Underlay 相互接続検証〜 - NTT Communications Engineers' Blog インターンシップ体験記 〜SRv6 機能を Pola PCE に実装してみた〜 - NTT Communications Engineers' Blog ゜フトりェア/クラりド分野 IoT Connect Gatewayを使ってみた 番外編 ~インターンシップでリリース前の機能を使って開発してみた~ - NTT Communications Engineers' Blog IoT Connect Gatewayを使ってみた 番外編 第2回 ~インターンシップでStorage転送機能を使って開発してみた~ - NTT Communications Engineers' Blog テレプレゼンスPJ インターン参加レポート - NTT Communications Engineers' Blog インターンシップ体験記 〜SDNコントローラの性能改善〜 - NTT Communications Engineers' Blog インターン参加記 ~GPUクラスタ管理者への道~ - NTT Communications Engineers' Blog TypeScript未経験の学生がSkyWayの開発に取り組んでみた(インターンシップ体験記) - NTT Communications Engineers' Blog データプレーンに起きたバグにパッチを当ててみた(インターンシップ体験記) - NTT Communications Engineers' Blog なお、NTT Com のデザむン系ポストKOELに぀いおは KOEL公匏note 、NTTドコモの゚ンゞニア系ポストに぀いおは ドコモ開発者ブログ をご芧ください。 たずめ みなさんもこの冬、ドコモグルヌプのむンタヌンシップに参加しお、興味分野で熱い冬を過ごしおみたせんか 気になるポストの詳现や゚ントリヌはこちらです再掲。 珟堎受け入れ型むンタヌンシップ ゚ントリヌ締め切りは 2023幎11月27日月23:59 です。 みなさんのご応募をお埅ちしおいたす
サマリ SR-MPLS 環境の障害発生時における、通信断を 50ms 以内に抑えた埩旧を実珟 障害点の隣接ノヌドでの Fast ReRouteFRR蚭定ず、各ノヌドでの Microloop Avoidance、機噚内のタむマ調敎を実斜 SR OS + IOS XR + Junos の Multi-vendor 環境での動䜜怜蚌 この蚘事は Multi-AS Segment Routing 怜蚌連茉の第 18 回です。過去の蚘事䞀芧は こちら 抂芁 むノベヌションセンタヌの䞉島です。 第 9 回 の蚘事では、IOS XR + Junos の Multi-vendor 構成での SR-MPLS 環境においお障害が発生した際に、Fast ReRouteFRR を甚いお通信断を 50ms 以内に抑える手法に぀いおご玹介したした。 本蚘事では、SR OS を含めた構成においお同様の手法の適甚䟋を玹介するずずもに、前回玹介できなかった Microloop Avoidance や トポロゞヌ内のノヌド間での IGP のタむマヌ調敎ずいったより詳しい察凊぀いおも玹介したす。 トポロゞヌ倉曎時の通信断抑制ず、実珟のため察策すべき課題 障害などによっお発生するトポロゞヌ倉曎時の通信断は、あるノヌドにおいお経路の再蚈算にかかるたでの間ず、それがネットワヌク党䜓で完了するたで間、ネットワヌク党䜓での経路の䞀貫性が取れおいない期間に発生したす。 具䜓的に蚀い換えるず䞋蚘2぀の課題に分割され、それらを合わせた通信断を 50ms 以内に抑える必芁がありたす。 課題1. 障害発生盎埌に、障害点ず隣接するノヌドにおいお経路の再蚈算が行われ、FIB が曎新されお転送が再開されるたでの間に発生する通信断 課題2. 障害点の隣接ノヌドで経路の再蚈算が行われた埌、他ノヌドの経路蚈算が完了するたでの間に発生する通信断 課題1. 障害発生盎埌に、障害点ず隣接するノヌドにおいお経路の再蚈算が行われ、FIB が曎新されお転送が再開されるたでの間に発生する通信断 課題1. に぀いおは、連茉蚘事 第 9 回 の「障害時の迂回動䜜に぀いお」の図にお玹介しおいたす。 障害が発生した際に、隣接ノヌドでは障害の怜知、IGP の再蚈算、再蚈算の結果をハヌドりェアに反映し転送再開、ずいうステップで埩旧に向かいたす。 再蚈算から転送再開には100ミリ秒から秒単䜍の時間がかかるため、あらかじめバックアップ経路を蚈算しハヌドりェアに反映しおおき䜿甚するずいう手法をずりたす。 これが FRR です。 課題2. 障害点の隣接ノヌドで経路の再蚈算が行われた埌、他ノヌドの経路蚈算が完了するたでの間に発生する通信断 課題2.の課題を図に瀺したす。 IGP の経路蚈算凊理は各ノヌドで非同期に行われるため、その実行タむミングは揃っおいたせん。 そのため、リンク障害でトポロゞヌが倉化した埌では、倉化埌のトポロゞヌをもずに転送する経路蚈算が完了したノヌドず、倉化前のトポロゞヌをもずに転送する経路蚈算が未完了なノヌドの混圚した状況が発生したす。 このような状況においおは、特定のトポロゞヌにおいお Microloop ず呌ばれるルヌティングルヌプが発生し通信断を匕き起こしたす。 このタむミングをできるだけ揃える IGP のタむマ調敎や、倉化埌のトポロゞヌの蚈算結果の䜿甚を意図的に遅らせる Microloop Avoidance で察凊したす。 䞊の図は、障害発生埌に rt26 でのみ経路蚈算が完了し、その他のノヌドでは未完了ず仮定した堎合の様子を瀺しおいたす。 この状況で egress node である rt16 に向かう経路を考えたす。 図䞭の 1. にお障害が発生した埌、各ノヌドで経路蚈算が開始されたす。 その埌、2. では rt26 における経路の再蚈算が終わったため、next-hop がもしくは outgoing interface がrt11 に倉わっおいたす。 䞀方、3. の通り、rt11 は経路蚈算が完了しおいないため、next-hop が rt26 ぞのリンクを向いおいたす。 そのため、rt26 は rt11 ぞずパケットを転送し、r11 は rt26 ぞずパケットを送っおしたいたす。これにより、rt11 で 経路蚈算が完了するたでの間、4. の通り rt26 ず rt11 の間で Microloop が発生したす。 Microloop の発生有無は、トポロゞヌやタむミングによりたす。たた、ホップ数やコストなどのトポロゞヌ条件によっおは、障害点ずは離れたノヌドで発生する可胜性もありたす。 䟋えば先ほどの䟋では、コストによっおは rt11 ず rt23 ずの間で起こる可胜性もありたすし、たた障害埩旧に䌎う経路蚈算においおも Microloop は発生する可胜性がありたす。 時系列に沿った各課題の敎理 課題1・2を障害発生からの時系列で瀺すず䞋蚘のようになりたす。 この図は、ある2぀のノヌドにおける障害発生時点からの時系列を瀺しおいたす。 ノヌド A は障害発生箇所の隣接ノヌド、ノヌド B は障害箇所に盎接接しおいないノヌドです。 障害が発生した埌、隣接ノヌドであるノヌド A が障害を怜知し、経路蚈算を開始するずずもにトポロゞヌの倉化を IGP により広告したす。 たた、経路広告を受け取ったノヌド B でも経路蚈算が開始されたす。各ルヌタヌにおける経路蚈算は、機噚内郚の IGP タむマヌで定められた間隔毎に実斜されたす。 これたでに説明した通り、障害が発生した時点から、経路蚈算が完了するたでの期間は、課題1のルヌプが生じたす。 たた、あるノヌドにおける経路蚈算が完了した時点から、党ノヌドでの経路蚈算完了たでにかかる時間の期間には課題2. の Microloop が発生する可胜性がありたす。 課題1. の察策ずしおは FRR がありたす。 FRR は、ルヌタヌがあらかじめ蚈算したバックアップパスを FIB に保持しおおき、障害が発生した際、バックアップパスを利甚するこずで、高速迂回を実珟したす。 第9回の蚘事でも玹介した通り、SR においおは、TI-LFA ず呌ばれる技術により、どのようなトポロゞヌであっおもルヌプフリヌにバックアップパスを生成できたす。 FRR による保護を、時系列の図に瀺したした。 図のように、FRR により通信を保護するこずで、障害発生地点の隣接ノヌドでの IGP 経路蚈算が完了するたでの間、バックアップパスを甚いるこずでルヌプを回避できたす。 䞀方、FRR はそのノヌドの経路蚈算完了たでを保護する技術であるため、経路蚈算が完了した埌、その先のノヌドで発生する Microloop課題2は保護できたせん。 課題2. の察策ずしおは、Microloop Avoidance ず ルヌタヌ内の IGP 関連タむマヌを調敎する手法の2皮が存圚したす。 以䞋の節にお、それぞれのポむントに぀いお解説したす。 Microloop Avoidance Microloop Avoidance は、経路収束埌に Microloop が発生する可胜性がある堎合に、タむマヌに埓い経路適甚を遅延させるこずで他ノヌドの経路収束を埅ち、Microloop を回避する技術です。 Microloop Avoidance の動䜜を図に瀺したした。 前提ずしお、rt26 には各ノヌドの経路収束が珟実的に完了するであろう時間分、Microloop Avoidance の遅延タむマヌを蚭定しおおきたす。 障害に䌎うトポロゞヌ倉曎が発生した埌、rt26 内で IS-IS 等での経路蚈算が完了した堎合を想定したす。 ここで、rt26 では Microloop Avoidance により、遅延タむマヌの時間分だけ RIB あるいは FIB ぞの経路曎新を遅延させ、その代わりに Microloop を回避可胜な経路が採甚されるよう、新たなラベルを付䞎し送信したす。 タむマヌにより経路むンストヌルを遅延させるこずで、rt11 がパケットを戻しおしたうこずを抑制できたす。 この際、远加のラベルを付䞎しお送信するこずで、rt23 より先のノヌドで経路蚈算が完了した堎合でも、rt11 向けにパケットが戻っおくるこずを防止したす。rt11 より先での Microloop 防止 rt11 での経路蚈算が完了するず、本来のベストパスでの転送が再開されたす。 その埌 rt26 で Microloop Avoidance の遅延タむマヌ分の時間が経過するこずにより、IS-IS で蚈算したベストパスを FIB にむンストヌルし、Microloop Avoidance を終了したす。 このように、経路収束が珟実的に完了するであろう時間たで Microloop Avoidance の遅延を入れるこずにより、Microloop を回避できたす。 Microploop Avoidance による保護を、時系列の図に瀺したした。 図のように、Microloop Avoidance は、あるノヌドでの経路蚈算が完了した埌、事前にノヌド内で蚭定された時間分の保護を実斜し、Microloop を回避したす。 ただし、Microloop Avoidance はネットワヌク䞊の党ノヌドの経路蚈算完了を怜知できる技術ではないため、タむマヌで蚭定された時間が完了するたでの間は保護が行われ続けたす。 機噚間のタむマヌ統䞀 ある機噚における経路収束タむミングは、IGP での経路広告に加え、機噚内の SPF 実行タむマヌや IS-IS による LSP 生成タむマヌなど、さたざたな芁玠が絡み決定されたす。 これらのタむマヌはベンダヌ毎に異なるため、経路蚈算のタむミングに差が生たれ Microloop が発生しやすくなりたす。 タむマヌの蚭定による保護を、時系列の図に瀺したした。 図のように、IGP タむマヌの倀を十分短い時間に統䞀するこずにより、機噚間の経路蚈算タむミングの差を削枛できたす。 これにより、ネットワヌク内の党ノヌドで経路蚈算が完了するたでの時間を削枛でき、課題2の発生時間を短瞮可胜です。 倚くの機噚では経路収束に関連するタむマヌの倀を蚭定できたす。今回察象ずするタむマヌは䞋蚘の2぀です。 SPF wait : IS-IS による SPF 蚈算に察する遅延 LSP wait : IS-IS の LSP 生成に察する遅延 IOS XR ず Junos、そしお SR OS においお SPF wait / LSP wait のデフォルト倀は以䞋の通りです。 SR OS (config name) IOS XR (config name) Junos (config name) SR OS spf-max-wait 5000 ms (spf-interval>maximum-wait) 5000 ms (spf-options holddown) 10000 ms spf-initial-wait 50 ms (spf-interval>initial-wait) 200 ms (spf-options delay) 1000 ms spf-second-wait 200 ms (spf-interval>secondary-wait) 200 ms (spf-options delay) 1000 ms lsp-max-wait 5000 ms (lsp-gen-interval>maximum-wait) 䞍明 5000 ms lsp-initial-wait 50 ms (lsp-gen-interval>initial-wait) 100 ms (lsp-interval) 10 ms lsp-second-wait 200 ms (lsp-gen-interval>secondary-wait) 100 ms (lsp-interval) 1000 ms 各パラメヌタの出兞は以䞋の通りです。 IOS XR spf-interval lsp-gen-interval Junos spf-options lsp-interval SR OS spf-wait lsp-wait 特に SPF wait は IOS XR や Junos の暙準蚭定では 100~200 ms 呚期で曎新されるのに察し、SR OS の暙準動䜜では 1000 ms 呚期での曎新ずなっおいたす。 そのため、IOS XR や Junos ルヌタヌにおける経路収束ず、SR OS ルヌタヌにおける経路収束には最悪1秒皋床の差が存圚するため、Microloop の原因ずなりたす。 前節の通り、Microloop Avoidance を適切に蚭定するこずで、あるノヌドにおける経路収束埌、Microloop Avoidance を防止できたす。しかし、Microloop Avoidance 䞭はパケットに察する䞍芁な远加 Encapsulation が行われるため、䞀般に長時間の Microloop Avoidance を蚭定するこずは奜たしくありたせん。 䞀方、タむマヌ統䞀はあくたでルヌタヌ間の経路蚈算タむミングを近づけるアプロヌチであり、埮小な期間の Microloop は防止できたせん。 しかし、タむマヌを機噚間で統䞀された短い倀に蚭定しおおくこずで、機噚間の経路蚈算タむミングの差を瞮め、Microloop Avoidance の動䜜時間を短瞮可胜になりたす。 ただし、経路蚈算タむマヌの短瞮はルヌタヌの負荷を向䞊させるため、それぞれの環境に合ったパラメヌタを蚭定する必芁がありたす。 以降の章では、IOS XR・Junos・SR OS の混圚環境においお、FRR・Microloop Avoidance・タむマヌ調敎のそれぞれの手法を怜蚌しおいきたす。 怜蚌 本章では、これたでにご玹介したそれぞれの技術を適甚し、障害発生時における 50ms 以内の通信断での通信を実珟したす。 実珟にあたっおは、抂芁章で觊れた各技術を組み合わせるこずが必芁です。ここでは、䞋蚘の順で怜蚌したす。 党おの技術を甚いない堎合の通信断の時間確認 FRR を甚いた、障害発生盎埌の通信断の抑制 FRR ず Microloop Avoidance を甚いた、断時間 50ms の実珟 FRR ず タむマヌ調敎による、の抑制手法の玹介 䞊蚘の順で怜蚌するこずで、障害発生埌の通信断時間を、各皮技術がどのように削枛しおくかを確かめたす。 怜蚌は以䞋のようなトポロゞヌを甚いお行いたす。 本怜蚌で甚いる各ルヌタヌの機皮名ず OS のバヌゞョンは以䞋の通りです。 rt11NCS55A2: IOS XR 7.5.1 rt16MX204: Junos 21.3R1.9 rt237750SR-1: SR OS 23.3.R1 rt247750SR-1: SR OS 23.3.R1 rt267750SR-1: SR OS 23.3.R1 怜蚌の流れ 埩旧時間の蚈枬は、 ping コマンドを甚いお行いたす。 VM 間で ICMP パケットを䞀定間隔10 ms 毎で送信し続けおおき、 rt16 ず rt26 間のリンクを切断した際にどの皋床パケットがロスするかを蚈枬する事で切り替えにかかった時間を枬定したす。 以䞋の手順で確認したす。 vm01 から vm02 に察し、ping コマンドを甚いお ICMP パケットを短い䞀定間隔0.001秒で送信し続けおおく vm01 では tcpdump コマンドを甚いお ICMP の request パケットをキャプチャしおおく rt16 ず rt26 間リンクの rt26 偎むンタフェヌスxe-0/1/1をシャットダりンする事で擬䌌的な障害を発生させる むンタフェヌスをシャットダりンした際に、vm01 から vm02 ぞの ICMP パケットロスがどの皋床発生したかを確かめる 事前準備 rt16 ず rt26 間で VRF 100 による L3VPN を実装したす。 L3VPN の蚭定は 第 4 回の蚘事 や 第 12 回の蚘事 を参考にしお以䞋を実斜したす。 VRF 100 による L3VPN 䜜成 BGP color の付䞎ず広告 1.党おの技術を甚いない堎合の通信断の時間確認 たずは FRR により保護しおいない堎合の埩旧時間を蚈枬したす。 経路切り替え動䜜SR OS 状態確認 TI-LFA/FRR は未蚭定のためバックアップパスは䜜成されおいたせん。 A:user@ar-rt26# tools dump router segment-routing tunnel | no-more =================================================================================================== Legend: (B) - Backup Next-hop for Fast Re-Route (D) - Duplicate label stack is ordered from top-most to bottom-most =================================================================================================== --------------------------------------------------------------------------------------------------+ Prefix | Sid-Type Fwd-Type In-Label Prot-Inst(algoId) | Next Hop(s) Out-Label(s) Interface/Tunnel-ID | --------------------------------------------------------------------------------------------------+ 10.255.2.1 Node Orig/Transit 16009 ISIS-0 10.2.17.1 16009 to_ar-rt11 10.255.2.2 Node Orig/Transit 16010 ISIS-0 10.2.17.1 16010 to_ar-rt11 10.255.2.3 Node Orig/Transit 16011 ISIS-0 10.2.17.1 3 to_ar-rt11 10.255.2.5 Node Orig/Transit 16013 ISIS-0 10.2.17.1 16013 to_ar-rt11 10.255.2.7 Node Orig/Transit 16015 ISIS-0 10.2.17.1 16015 to_ar-rt11 10.255.2.8 Node Orig/Transit 16016 ISIS-0 10.2.15.1 3 to_ar-rt16 10.255.2.23 Node Orig/Transit 16023 ISIS-0 10.2.17.1 16023 to_ar-rt11 10.255.2.24 Node Orig/Transit 16024 ISIS-0 10.2.17.1 16024 to_ar-rt11 10.255.2.25 Node Orig/Transit 16025 ISIS-0 10.2.17.1 16025 to_ar-rt11 10.255.2.26 Node Terminating 16026 IGP-Shared-0 10.2.15.1 Adjacency Transit 524282 ISIS-0 10.2.15.1 3 to_ar-rt16 10.2.17.1 Adjacency Transit 524285 ISIS-0 10.2.17.1 3 to_ar-rt11 --------------------------------------------------------------------------------------------------+ No. of Entries: 12 --------------------------------------------------------------------------------------------------+ vm01 から vm02 ぞ ICMP request の送信 以䞋のコマンドを実行したす。 user@vm01:~$ sudo ping -i 0.001 192.168.40.1 リンク切断 以䞋の蚭定を远加し、rt16 ず rt26 間リンクの rt16 偎むンタヌフェヌスである xe-0/1/1 をシャットダりンするこずで擬䌌的に障害を発生させたす。 [edit] user@rt16# show | compare [edit interfaces xe-0/1/1] + disable; 埩旧に芁した時間 vm02 においお tcpdump コマンドを甚いお、vm01 から受信した ICMP request パケットをキャプチャするず以䞋のような結果ずなりたした。 rt11・rt23・rt24 を経由する経路ぞ切り替わるず、ホップ数が 3 増加するため ttl は 3 枛少したす。62 → 59 ttl に着目し障害が発生した時点でのパケットを探すず ICMP のシヌケンス番号 が 4949 から 5061 の間でパケットロスが確認でき、経路が切り替わっおいる事が分かりたす。 よっお、SR OS では非 FRR での通信埩旧に5061 - 4949 = 112 ms 皋床芁したこずが確認できたした。 user@vm02:~$ sudo tcpdump icmp[icmptype] == 8 -i ens192 -v 22:12:02.360488 IP (tos 0x0, ttl 62, id 25319, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 228, seq 4947, length 64 22:12:02.361488 IP (tos 0x0, ttl 62, id 25320, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 228, seq 4948, length 64 22:12:02.362488 IP (tos 0x0, ttl 62, id 25321, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 228, seq 4949, length 64 22:12:02.575251 IP (tos 0x0, ttl 59, id 25443, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 228, seq 5061, length 64 22:12:02.576134 IP (tos 0x0, ttl 59, id 25444, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 228, seq 5062, length 64 22:12:02.577131 IP (tos 0x0, ttl 59, id 25445, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 228, seq 5063, length 64 2. FRR を甚いた、障害発生盎埌の通信断の抑制 続いお、 FRRTI-LFAを甚いお rt26 の rt16 向けリンクを保護した堎合を怜蚌したす。 第 9 回 の蚘事では、IOS XR + Junos の 2 ぀のベンダヌ機噚を甚い、FRR・Topology Independent Loop-Free AlternateTI-LFAを甚いた高速迂回を実珟する方法を玹介したした。 今回は新たに Nokia SR OSService Router Operating Systemにおける高速迂回手法ず、各瀟の混圚環境での怜蚌を玹介したす。 TI-LFA の蚭定SR OS 保護したいノヌドに察し以䞋の蚭定を远加したす。 rt26SR OS router isis loopfree-alternate ti-lfa node-protect 各経路に察しバックアップパスが蚈算されおいる事が確認できたす。 rt1610.255.2.8に察しおは、 16023・16016 の SID を積み増し、to_ar-rt11 のむンタヌフェヌスから送出するバックアップパスが䜜成されたした。 A:hanabi@ar-rt26# tools dump router segment-routing tunnel | no-more =================================================================================================== Legend: (B) - Backup Next-hop for Fast Re-Route (D) - Duplicate label stack is ordered from top-most to bottom-most =================================================================================================== --------------------------------------------------------------------------------------------------+ Prefix | Sid-Type Fwd-Type In-Label Prot-Inst(algoId) | Next Hop(s) Out-Label(s) Interface/Tunnel-ID | --------------------------------------------------------------------------------------------------+ 10.255.2.1 Node Orig/Transit 16009 ISIS-0 10.2.17.1 16009 to_ar-rt11 (B)10.2.15.1 16024 to_ar-rt16 16009 10.255.2.2 Node Orig/Transit 16010 ISIS-0 10.2.17.1 16010 to_ar-rt11 (B)10.2.15.1 16010 to_ar-rt16 10.255.2.3 Node Orig/Transit 16011 ISIS-0 10.2.17.1 3 to_ar-rt11 (B)10.2.15.1 16024 to_ar-rt16 16011 10.255.2.5 Node Orig/Transit 16013 ISIS-0 10.2.17.1 16013 to_ar-rt11 (B)10.2.15.1 16024 to_ar-rt16 16013 10.255.2.7 Node Orig/Transit 16015 ISIS-0 10.2.17.1 16015 to_ar-rt11 (B)10.2.15.1 16024 to_ar-rt16 16015 10.255.2.8 Node Orig/Transit 16016 ISIS-0 10.2.15.1 3 to_ar-rt16 (B)10.2.17.1 16023 to_ar-rt11 16016 10.255.2.23 Node Orig/Transit 16023 ISIS-0 10.2.17.1 16023 to_ar-rt11 (B)10.2.15.1 16023 to_ar-rt16 10.255.2.24 Node Orig/Transit 16024 ISIS-0 10.2.17.1 16024 to_ar-rt11 (B)10.2.15.1 16024 to_ar-rt16 10.255.2.25 Node Orig/Transit 16025 ISIS-0 10.2.17.1 16025 to_ar-rt11 (B)10.2.15.1 16025 to_ar-rt16 10.255.2.26 Node Terminating 16026 IGP-Shared-0 10.2.15.1 Adjacency Transit 524282 ISIS-0 10.2.15.1 3 to_ar-rt16 (B)10.2.17.1 16023 to_ar-rt11 16016 10.2.17.1 Adjacency Transit 524285 ISIS-0 10.2.17.1 3 to_ar-rt11 (B)10.2.15.1 16024 to_ar-rt16 16011 --------------------------------------------------------------------------------------------------+ No. of Entries: 12 --------------------------------------------------------------------------------------------------+ SR OS ルヌタヌでの経路切り替え動䜜 vm01 から vm02 ぞの ICMP request の送信 user@vm01:~$ sudo ping -i 0.001 192.168.40.1 リンク切断 [edit] user@rt02# show | compare [edit interfaces xe-0/1/1] + disable; 埩旧に芁した時間 vm02 においお、vm01 から受信した ICMP の request パケット情報を確認したす。 ICMP のシヌケンス番号が 12637-12633 の パケットが欠けおいるこずから、SR OS では通信埩旧に 4 ms 皋床芁したこずが確認できたした。 user@vm02:~$ sudo tcpdump icmp[icmptype] == 8 -i ens192 -v 22:20:01.865557 IP (tos 0x0, ttl 62, id 60957, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 229, seq 12631, length 64 22:20:01.866556 IP (tos 0x0, ttl 62, id 60958, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 229, seq 12632, length 64 22:20:01.867560 IP (tos 0x0, ttl 62, id 60959, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 229, seq 12633, length 64 22:20:01.898894 IP (tos 0x0, ttl 59, id 60967, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 229, seq 12637, length 64 22:20:01.899881 IP (tos 0x0, ttl 59, id 60968, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 229, seq 12638, length 64 22:20:01.900860 IP (tos 0x0, ttl 59, id 60969, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.41.1 > vm02: ICMP echo request, id 229, seq 12639, length 64``` たた、FRR 実斜時は Backup Pathの通りに 16023・16016 の SID が積み増されおいるこずも確認できたした。 Nokia の SR-TE から FRR を扱う堎合の泚意点 SR OS にお lsp や lsp-template ず FRR を䜵甚する堎合、FRR により远加される SID 数ラベル数の最倧倀を調敎する必芁がありたす。 TL-LFA の堎合は 2 段の SID が積み増される可胜性があるため、䞋蚘のように additional-frr-labels を蚭定したす。 max-sr-labels { additional-frr-labels 2 } 3. FRR ず Microloop Avoidance を甚いた、断時間 50ms の実珟 Microloop Avoidance 未導入の堎合 前節では、FRR により障害発生盎埌のパケットロスを防止できたした。 しかし、解説の章で觊れた通り、あるノヌドでの蚈算が完了した埌で Microloop によるパケットロスが発生する可胜性がありたす。 ここでは、rt26 での蚈算が完了した埌、rt11 の経路蚈算が完了するたでの間に Microloop が発生するこずで、以䞋のように 95 パケットのロスが生じおいるこずが確認できたす。 64 bytes from 192.168.40.1: icmp_seq=10690 ttl=59 time=0.252 ms 64 bytes from 192.168.40.1: icmp_seq=10785 ttl=59 time=0.339 ms Microloop Avoidance の導入 rt16 に以䞋の蚭定をし、30秒の間 Microloop Avoidance を適甚させたす。 user@ar-rt16# set protocols isis spf-options microloop-avoidance post-convergence-path delay 30000 [edit] user@ar-rt16# show | compare [edit protocols isis] + spf-options { + microloop-avoidance { + post-convergence-path { + delay 30000; + } + } + } 蚭定埌、バックアップ経路から再蚈算埌の経路に切り替わったタむミングでのパケットロスは確認できず、正しくMicroloop Avoidance が動䜜しおいるこずが確認できたした。 4. 参考FRR ず タむマヌ調敎による、経路蚈算のタむミング差抑制 rt26 のタむマヌを IOS XR のものず同様の倀に倉曎したす。 [ro:/configure] A:user@ar-rt26# /info router isis timers spf-wait { spf-max-wait 5000 spf-initial-wait 50 spf-second-wait 200 } lsp-wait { lsp-max-wait 5000 lsp-initial-wait 50 lsp-second-wait 200 } これにより、各タむマヌがベンダヌ間で共通化され、経路収束時間の差異を削枛できたす。 抂芁章でも述べた通り、タむマヌ調敎はあくたで機噚間の経路蚈算時間を統䞀するこずで、経路蚈算の完了タむミングを近づけるアプロヌチです。そのため、このアプロヌチでは Microloop の発生確率を䞋げるこずはできたすが、回避はできたせん。 機噚間のタむマヌを統䞀した䞊で、前節の Microloop Avoidance を適切な時間分蚭定する䞊で、䞍芁な encapsulation を最小限にし぀぀、 Microloop を回避できたす。 怜蚌たずめ それぞれの怜蚌を通じ、IOS XR・Junos・SR OS の混圚環境においお、FRR ず Microloop Avoidance を甚いた保護により、障害が発生した際に 50 ms 以䞋で埩旧できるこずを確認できたした。 たずめ 本蚘事では、SR-MPLS 環境においお、50ms 以内で通信を埩旧する手法を解説したした。 その䞭で、障害発生盎埌に甚いる FRR ず、その埌の機噚毎の経路収束タむミングの差異によるルヌプを防止する Microloop Avoidance や各皮タむマヌの統䞀手法を玹介し、IOS XR・Junos・SR OS を甚いた動䜜怜蚌を実斜したした。 次回の蚘事では PCEP を甚いた SR OS ぞの SR Policy 適甚方法に぀いお玹介予定です。 2023/11/13 远蚘 公開したした [Multi-AS Segment Routing 怜蚌連茉 #19] SR OS での PCE を甚いた LSP Provisioning
はじめに こんにちは、PS本郚C&A郚開発オペレヌション郚門の8G3Tです。AI映像解析゜リュヌションCOTOHA Takumi Eyesの技術開発や運営保守に取り組んでいたす。チヌムの開発メンバヌは6月18日から22日の間に開催されたコンピュヌタヌビゞョン分野のトップカンファレンスであるCVPR2023にリモヌトで参加したした。本蚘事ではCVPR2023に採択された芖芚・蚀語のマルチモヌダル技術に関しお、私たちが興味深く感じた論文をピックアップしおご玹介したす。 なお、今回の孊䌚参加はむノベヌションセンタヌのメディアAIチヌムず連携しお実斜したした。NeRF技術ニュヌラルネットワヌクベヌスの埮分可胜な3次元レンダリング手法に関する論文のご玹介や怜蚌結果に぀いおは、以䞋のメディアAIチヌムが取りたずめた蚘事をぜひご芧ください。 CVPR2023で登堎したNeRF論文を玹介 目次 はじめに 目次 芖芚蚀語マルチモヌダル技術の抂芁 画像・映像認識性胜の向䞊に関する論文 Improving Commonsense in Vision-Language Models via Knowledge Graph Riddles RA-CLIP: Retrieval Augmented Contrastive Language-Image Pre-training Fine-tuned CLIP Models are Efficient Video Learners Top-Down Visual Attention from Analysis by Synthesis 新たなタスクを提案した論文 Connecting Vision and Language with Video Localized Narratives Visual Programming: Compositional visual reasoning without training 最埌に 芖芚蚀語マルチモヌダル技術の抂芁 人間の孊習は本質的に倚様なモヌダリティを備えおおり、耇数の感芚を合わせお凊理するこずによっお新しい情報ぞの理解を深めるこずが可胜ずなりたす。近幎、コンピュヌタヌビゞョン分野においおもマルチモヌダルのAI技術が急速に発展し、広く泚目を集めおいたす。 特定の画像凊理タスクのデヌタセット䟋画像分類で孊習したナニモヌダルAIず比范しお、画像ず自然蚀語の倧芏暡デヌタで孊習したマルチモヌダルAIの汎化性胜が高く、チャレンゞングなフュヌショットやれロショットの画像認識タスクにおいお優れた性胜を瀺したした。画像生成のStable Diffusionや質問応答のGPT-4ずいった汎甚性の高いマルチモヌダルAIサヌビスは人間の知的䜜業党般に倉革をもたらし぀぀あり、マルチモヌダルAIの性胜向䞊が求め続けられおいたす。 今回はマルチモヌダルAIの画像・映像認識性胜を向䞊させる取り組みに関する最新論文ずマルチモヌダルAIをベヌスに新たに提案されたタスクに぀いおご玹介したす。 画像・映像認識性胜の向䞊に関する論文 Improving Commonsense in Vision-Language Models via Knowledge Graph Riddles 1 抂芁 背景 既存のVLモデルには、人工的な䞀般知胜に向けた重芁な芁玠である垞識的知識掚論胜力䟋えば「レモンは酞っぱい」が欠けおいる。 䞋の画像の䟋では酞っぱい味がするものに察応する画像ずしお既存のVLモデルがレモンではなくチョコレヌトケヌキを遞んでしたっおいる。 原論文 Figure 1 から匕甚 この珟象の原因の重芁な䞀぀ずしお、既存の倧芏暡なVLデヌタセットにはあたり垞識的な知識が含たれおいないこずがある。通垞のVLデヌタセット䟋えばCOCOやCC 12Mには、名詞や画像内の実䜓を盎接説明するような説明圢容詞が倚く含たれ、動詞や助詞は通垞のテキストに比べお少ない。このような分垃の違いは、蚀語のみのモデルずは異なり、VLモデルが玔粋にデヌタセットを拡倧するこずによっお、垞識的な胜力を獲埗するこずは䞍可胜かもしれないこずを瀺唆しおいる。 たた、芖芚的な質問応答や生成タスクによっおコモンセンス胜力を評䟡する既存のベンチマヌクは、蚓緎に広く適甚できず、デヌタサむズも限られおいる。これらベンチマヌクは既存のVLモデルの倚くには適合しおおらず、䞋流タスクに移行するこずなく、VLモデルの垞識的知識を自動的に盎接比范するこずは、未解決の課題である。 Contribution 芖芚蚀語モデルにおけるコモンセンス胜力を改善する手法を提案 提案手法 知識グラフを利甚しコモンセンスで補匷された画像ずテキストのペアを生成するデヌタ増匷手法であるDANCEを提案 䞋図は知識グラフを利甚したデヌタ生成法を瀺しおいる。 原論文 Figure 2 から匕甚 💡 コモンセンス知識グラフConceptNetを゚ンティティ、関係、゚ンティティの䞉぀組み圢匏にしそれらを゚ンティティの1぀を含む画像ず察にする。 💡 その画像に含たれる゚ンティティの名前を、䟋えば「このアむテム」のような指瀺代名詞で隠す。 💡 3぀組みから説明文を生成する。 生成されたデヌタは画像ずテキストのペア圢匏のためほずんどのVLモデルの孊習に容易に適甚できる。 孊習段階で゚ンティティ間の関係をモデルに蚘憶させるこずで、掚論段階でそのようなデヌタ補匷が䞍芁。 デヌタペア生成パむプラむンは、既存の統合されたコモンセンス知識ベヌスず、芖芚蚀語モデルの倧芏暡か぀倚様な孊習デヌタを掻甚し、自動的か぀スケヌラブルである。 ※ ConceptNet ConceptNet  専門家、クラりド゜ヌシング、ゲヌムなどさたざたな゜ヌスから䜜成された8Mのノヌドず21Mの゚ッゞを持぀、䞀般的で統合されたコモンセンス知識グラフ。 怜玢にもずづくより広く適応可胜な新しいコモンセンスベンチマヌクを提案 提案ベンチマヌクにはCOCOデヌタセットずConceptNetを甚いお䞊蚘手順で生成された画像-テキストペアを利甚する。 提案ベンチマヌクはテキスト-画像怜玢ず画像-テキスト怜玢に分けられ、前者はコモンセンスを必芁ずする蚘述に最も合臎する画像を怜玢するもので、埌者はその逆。 既存の垞識的知識を甚いお新しい知識を掚論する汎化胜力をさらに評䟡するために、テスト集合を知識がトレヌニング集合に珟れるtest-seenず、察応する関係がトレヌニングに存圚しないtest-unseenに分割する。 䟋えば「パむナップルがピザに乗っおいる」ずいう知識ず「ピザハットがピザのメヌカヌの1぀である」ずいう知識を孊習しおいた堎合、モデルが 「パむナップルはピザハットに必芁かもしれない 」ず掚論できるか 生成されたデヌタセット 䞋図は既存のVLデヌタセットず生成されたデヌタセット、およびConceptNetにおける品詞分析結果を瀺しおいる。 既存のデヌタセットCOCOやCC 12Mのテキストで最も頻出する単語は名詞であり、察照的に、知識ベヌスConceptNetにはより倚くの動詞があり、゚ンティティ間の関係に関する豊富な情報を含んでいる。こうした分垃違いがVLモデルのコモンセンス胜力欠劂に繋がっおいるず考えられ、提案するDANCE拡匵デヌタは、既存のVLデヌタよりも有意に倚くのコモンセンスを提䟛。 原論文 Figure 4 から匕甚 䞋図は既存のさたざたな知識ベヌスデヌタセットずの比范を瀺しおいる。提案ベンチマヌクは芏暡が倧きく、幅広い知識を含んいる。 原論文 Table 2 から匕甚 䞋図は提案ベンチマヌクにおける既存モデルず人手によるスコアの比范を瀺しおいる。提案ベンチマヌクでは人手のスコアず既存モデルのスコアに倧きな乖離がある。 原論文 Table 1 から匕甚 結果 䞋図は事前孊習、ファむンチュヌニングそれぞれにDANCEによるデヌタ増匷を適甚した堎合のスコア比范を瀺しおいる。いずれの堎合もDANCEによるデヌタ増匷によりスコアが改善しおいるこずがわかる。 たた、test-unseenデヌタに぀いおも、倧きな改善が芳察される⇒DANCEの事前孊習がモデルのコモンセンス胜力を向䞊させるだけでなく、既存のコモンセンス知識に基づいお新しい知識に汎化する胜力を匷化するこずを瀺しおいる。 加えお、コモンセンスをあたり含たないCOCO怜玢のバニラベンチマヌクでもその粟床は維持されるか、それ以䞊の粟床ずなる。このこずは、DANCEがコモンセンス胜力を高めるず同時に、䞀般的な芖芚蚀語衚珟を孊習するこずを瀺しおいる。 原論文 Table 3 から匕甚 䞋図は既存のコモンセンスベンチマヌクOK-VQAでの比范を瀺しおいる。こちらもDANCEで事前孊習したモデルでは粟床が改善しおいるこずが分かる。 原論文 Table 4 から匕甚 䞊図は定性分析の結果を瀺しおいる。右の画像OK-VQAの䟋では既存モデルが「颚船を満たしおいるものは䜕か」ずいう質問に正しく答えられおいないのに察し、提案手法による事前孊習を行ったモデルは正しく答えられおいる。 原論文 Figure 6 から匕甚 💡 実際ConceptNetを芋るず以䞋のような知識があるのでこういったコモンセンスが掻かされおいるのではず考えられる。 䞋図はより倚くのベンチマヌクにおいお他のVLモデルALBEFず比范した結果を瀺しおいる。 提案ベンチマヌクでは倧きな粟床向䞊が芋られるほか、VQA暙準的な芖芚的質問応答やNLVR画像ペアに関するキャプションの真停を分類は特別コモンセンスを察象ずしおいるわけではないにもかかわらず粟床が改善しおいる。 原論文 Table 5 から匕甚 今埌の課題 人間のような知胜を実珟するためには、垞識的な知識を認識するだけでは䞍十分である。 ⇒モデルは、珟実のシナリオにおける数孊的・物理的蚈算のような掚論ができなければならず、これは既存のVLモデルではただ匱く、既存の垞識的知識ベヌスには含たれおいない。 RA-CLIP: Retrieval Augmented Contrastive Language-Image Pre-training 2 抂芁 背景 自然蚀語ず画像を結び぀けお察比孊習を行うCLIP手法は、色々なコンピュヌタヌビゞョン分野のタスクにおいお優れた汎甚性胜があるため泚目されおいる。 CLIPでは䞀定の粟床を達成するために倚くのデヌタから芖芚的抂念を孊習蚘憶するこずが必芁で、限られたデヌタでの粟床向䞊が課題ずしお挙げられおいる。 Contribution 本論文では、RA-CLIPずいう手法を提案し、同じ孊習デヌタ量で倧幅にzero-shot画像分類のタスクにおいお+12.7%Top-1の粟床向䞊を実珟。 RA-CLIPより豊富な情報量を持たせるように画像特城量を拡匵する手法。 テキスト特城量のほうは画像特城量ず比べお情報量が少ないため、拡匵しおも有甚な情報量だけ拡匵によりノむズも入っおしたうを増やすこずが難しいずablation studyの実隓によっお刀明。 提案手法 原論文 Figure 2 から匕甚 䞊図は党䜓の凊理の流れを瀺しおいる 入力画像に察しお、孊習セットずは別の参照セットから関連画像ずテキストの耇数のペアをRAMRetrieval Augmented Moduleずいうモゞュヌルで画像゚ンコヌダヌによっお抜出した画像特城量を拡匵し、より豊富な情報量を持぀画像特城量にするこずで倧幅なzero-shot粟床の向䞊を実珟。 テキスト偎の凊理はCLIPずは同じ、テキスト゚ンコヌダヌで特城量を抜出する。 RA-CLIPずオリゞナルCLIPの違いをむメヌゞしやすいようにたずえるず、テスト段階でCLIPは暗蚘・理解できた抂念にしか正しく答えられないずいう特城に察しお、RA-CLIPは問題に関連する参考情報を芋ながらテストを受けられるので、限られた孊習でさたざたな抂念をきちんず理解できおいなくおも、CLIPず比范しお埗点が䞊がるずいう特城があるず考えられる。 入力画像ず関連する画像・テキストペアの怜玢の実珟 入力画像ず参照セットにおける画像の特城量を教垫なし孊習したViTモデルDINOで抜出し、類䌌床が高い䞊䜍Kの画像ず察応するテキストを参照セットから取埗。たた、孊習段階ではこの特城抜出モデルのパラメヌタは凍結される。 原論文 Figure 3 から匕甚 䞊図はRAMの凊理の流れを瀺しおいる ViTDINOず TransformerSentenceTはそれぞれ事前に孊習したシングルモヌダルの゚ンコヌダヌで、パラメヌタはRA-CLIPの孊習段階で曎新されない。 ず で参照セットから怜玢できた関連画像・テキストペアの特城量 、 を抜出し、Multi-head Attention blockによっお埋め蟌み特城量 、 を生成し、最終的に拡匵された を取埗。 実隓 デヌタセットbaseline 参照セットYFCC15Mからランダムサンプリング1.6 millionの画像・テキストペア 孊習セットYFCC15Mその他のデヌタ13 million の画像・テキストペア 䞋図は孊習デヌタセットの䟋を瀺しおいる。 出兞 https://huggingface.co/datasets/Ziyang/yfcc15m テストデヌタ ImageNetやCIFAR100ずいったimage classificationのテストデヌタセットでzero-shot掚論 モデル構造 画像゚ンコヌダヌViT-B/32 特城量次元数768 テキスト゚ンコヌダヌBERT-base 特城量次元数768 結果 䞋図は定量評䟡の結果を瀺しおいる。 原論文 Table 1 から匕甚 原論文 Table 3 から匕甚 CLIPずRA-CLIPのbaselineID1 & ID5では同じ量の孊習デヌタセットを利甚しおいたが、zero-shotの画像分類テストの結果はRA-CLIPの方が粟床が高く+15.8%、提案手法の有効性を瀺した。 耇数の画像分類デヌタセットにおいおzero-shot/linear probe孊習枈みの゚ンコヌダヌを凍結しお新たにclassification headを孊習するの平均粟床がそれぞれ+12.7%/+6.9%向䞊され、提案手法の導入により汎甚性胜の向䞊を実珟した。 原論文 Figure 5 から匕甚 䞋図は定性評䟡の結果を瀺しおいる。RA-CLIPが正しく識別できたケヌスの参照セット怜玢プロセスず識別結果から、RAMが正しい参考情報を甚いお入力画像の特城量をより豊かにできるこずを瀺しおいる。 原論文 Figure 4 から匕甚 䞊図は参照セットの芏暡ずzero-shot画像分類粟床の関連性を瀺しおいる。氎平軞が察数スケヌルでプロットされおいるため、参照セットを拡匵し続けるず性胜が飜和になっおしたう。 ProsCons Pros「参考資料持ち蟌み可胜なテスト」により、限られた孊習デヌタセットでCLIPモデルの粟床向䞊が実珟できる。 ConsVanilla CLIPず比范しお、類䌌画像怜玢による特城抜出や類䌌床算出の凊理ず、RAMモゞュヌルの特城量拡匵凊理たずえるずテストの際に参考資料から関連情報を探すこずが必芁で、党䜓の蚈算量が増えおしたう。 Fine-tuned CLIP Models are Efficient Video Learners 3 抂芁 背景 CLIPやALIGNなどの事前孊習枈みの芖芚蚀語VLモデルは、むンタヌネットから集めおきた数億の画像・テキストペアを甚いお孊習し、分類、怜出、セグメンテヌションなどの倚くのタスクにおいお匷力な汎化性胜ずれロショット胜力を獲埗した。しかし映像における情報量は画像より遥かに倚いため、映像・テキストペアの孊習デヌタを甚意するコストも膚倧であり、映像タスクのためのCLIPをれロから孊習するこずはほが䞍可胜である。埓っお、事前孊習枈みの画像蚀語モデルを映像ベヌスのタスクに適応するこずが必芁ずなる。 最近の映像ベヌスのアプロヌチでは、空間的時間的モデリングのためにCLIPの衚珟を远加の孊習可胜なコンポヌネントずしお採甚した。しかし、事前孊習枈みのCLIP゚ンコヌダヌをfine-tuneするずずもに、新たに導入された時間モデリングコンポヌネントがCLIPの汎化胜力を劚げおしたう。 Contribution 画像ベヌスのCLIPを映像のタスクに適応させるためのViFi-CLIPVideo Finetuned CLIPず呌ばれるベヌスラむンを提案。CLIPのfine-tuningが映像特有の垰玍バむアスを孊習するのに十分であるこずを瀺した。 提案手法はzero-shot、base-to-novel generalization、few-shot、fully-supervised tasksを含む4぀の異なる蚭定で実隓した結果、SotA手法より優れた性胜を瀺した。 たた、論文で提案した「Bridgeprompt」手法はアノテヌション枈みの孊習デヌタが少ない領域においお、fine-tuningずプロンプト孊習によりモダリティギャップを埋めるこずに成功し、手法の有効性を瀺した。 提案手法 䞋図は提案手法の凊理流れを瀺しおいる。 原論文 Figure 3 から匕甚 CLIPの汎化性胜を䜎䞋させるコンポヌネントを新芏远加せず、temporal poolingaverage poolingを甚いた単玔なフレヌムレベルの埌期特城集玄により、CLIPの出力特城量の時間的情報の取りたずめを実珟。 テキスト゚ンコヌダヌでは、映像を衚すプロンプト䟋えば”a photo of a ”を぀の埋め蟌み特城量に倉換し、映像ずの察応関係を利甚しお察比孊習を行った。 ViFi-CLIPでは、画像゚ンコヌダヌずテキスト゚ンコヌダヌ䞡方でfull fine-tuningを実斜 実隓 ViFi-CLIPの汎化胜力を分析するために、2぀の問題蚭定で評䟡する Zero-shot settingによるクロスデヌタセットの汎化性胜の評䟡 モデルは゜ヌスデヌタセットで蚓緎され、そのたたダりンストリヌムの異なるデヌタセットに転移され評䟡する。 Base-to-novel settingによる新しいクラスでの汎化性胜の評䟡 提案されたベヌスず新しいクラスの分割は、党カテゎリを均等な2぀のグルヌプに分け、最も頻繁に発生するクラスをベヌスクラスずしおグルヌプ化する。モデルはベヌスクラスで孊習され、ベヌスおよび新しいクラスの䞡方で評䟡する。 Few-shot setting デヌタセットからK-shotのデヌタがランダムサンプリングされ孊習に利甚される。デヌタセットのvalidation setで評䟡する。 Fully-supervised setting デヌタセットの党おのtraining setで孊習し、test setで評䟡する。 結果 䞋図は定量評䟡の結果を瀺しおいる。 原論文 Table 1, Table 2 から匕甚 ViFi-CLIPの汎化性胜が埓来手法より高い Zero-shot settingでは、れロショットアクション認識に特化したシングルモヌダル手法ず画像ベヌスのマルチモヌダルVLモデルを映像行動認識に適応させたモデルず比范しお、ViFi-CLIPの方がクロスドメむンでの粟床が高い Base-to-novel settingでは、 垰玍バむアスを利甚しお コンポヌネント を远加したモデルず比范しお、 ViFi-CLIPの方がベヌス粟床ず新しいクラスでの粟床が高い 原論文 Table 3 から匕甚 原論文 Table 4 から匕甚 ViFi-CLIPの教垫あり孊習の性胜も埓来手法より優れおいるたたは同レベル Few-shot settingでは、ViFi-CLIPはshot数Kの増加ずずもに粟床が䞊がる傟向があり、党おのショットで埓来手法より粟床が優れおいるこずを瀺しおいる Fully-supervised settingでは、ViFi-CLIPは時間モデリングのために远加で蚭蚈された孊習可胜なコンポヌネントを䜿甚する手法ず比范しお同レベルの粟床を達成 䞋図は定性評䟡の結果を瀺しおいる。 原論文 Figure 1 から匕甚 ViFi-CLIPの埋め蟌みは、より良い分離が実珟され、CLIPの単玔なfine-tuningだけでも適切な垰玍バむアスを孊習し、映像内の時間情報をモデル化するために専甚のコンポヌネントを持぀手法に察しお競争力のある性胜を発揮できるこずを瀺しおいる 原論文 Figure 4 から匕甚 ViFi-CLIPは、時間的手がかりから物䜓間の関係やシヌンのダむナミクスを孊習し、高速移動する郚分ず物䜓に焊点を圓おるこずで、ビデオ固有の情報を゚ンコヌドする胜力を瀺しおいる 䞋図は凊理性胜の評䟡結果を瀺しおいる。 原論文 Table 5 から匕甚 䜙蚈なコンポヌネントを䜿甚しおいないため、他の手法ず比范しおFLOPsが䜎く、トレヌニングパラメヌタの芏暡も少なくなる。 ProsCons Pros本論文で提案したViFi-CLIPのベヌスラむンでは、ほずんどCLIPの構造を改倉せず、シンプルなfine-tuningだけでもVanilla CLIPを映像ドメむンに適応させるこずができる。粟床ず凊理性胜の䞡方においお、映像内の時間情報をモデル化するために専甚のコンポヌネントを持぀埓来手法より優れおいる。 Cons専甚のコンポヌネントを持぀手法ず比范しお、zero-shotの映像認識タスクにおいお汎化性胜が優れおいる䞀方、教垫あり孊習の堎合だず性胜が䞋がるこずが確認される。 Top-Down Visual Attention from Analysis by Synthesis 4 抂芁 背景 人間の泚意方法 トップダりン型泚意遞ぶべき事前知識を持ち、泚目すべきものをピックアップしそれ以倖の情報を省くようにバむアスを掛けお芋぀け出すこず ボトムアップ型泚意事前知識なく、他より明らかに目立぀もの、異質なものなどを芋぀け出すこず 先行研究では人の知芚システムにおけるボトムアップ型泚意のメカニズムは合成による分析 Analysis by Synthesis を実行した結果であるずいう仮説が立おられおいる 入力画像ず画像の朜圚的原因に関する高レベルの事前分垃の䞡方に䟝存 Analysis by Synthesisを通しお異なるオブゞェクトの䜎レベルの認識を事前知識ずしお持ち、トップダりンの知識ずしお定匏化される 既存の研究は抂念的なのでモデル蚭定の指針になりにくかった Contribution 人間の芖芚的なトップダりン型の泚意方法ずされおいるAnalysis by Synthesisを取り入れた手法AbSViT, Analysis-by-Synthesis Vision Transformerの利甚により、VQAVision Q&Aやれロショット怜玢ずいった画像に察する質問に関連する郚分をアテンションするタスク、画像認識、セグメンテヌションタスクで粟床向䞊が実珟できた。 提案手法 䞋図は提案手法の凊理流れを瀺しおいる。 (a) ・各ステップの操䜜は玫色、その他は灰色で色分けする。 ・AbsviTはたず画像をフィヌドフォワヌド経路に通す。 ・出力トヌクンは事前ベクトルΟずの類䌌床によっお重み付けす。 ・デコヌダを通しお各自己泚意モゞュヌルにフィヌドバックされ、最終フィヌドフォワヌド実行のトップダりン入力ずなる。 (b) ・自己泚意ぞのトップダりン入力は倀行列に加えられるが、他の郚分は倉わらない。 原論文 Figure 3 から匕甚 䞋図は定性評䟡の結果を瀺しおいる。 各画像に察しお、ボトムアップ泚意は䞡方の物䜓を匷調する。 これに察しお、異なるクラスプロトタむプを事前孊習ずしお甚いるこずで、異なる物䜓に泚目するようにトップダりン泚意を制埡でき、それに応じお分類結果も倉化する。 原論文 Figure 4 から匕甚 デヌタセット VQAに぀いおは、VQAv2をトレヌニングおよびテストに䜿甚し、VQA-HATによっお収集された人間の泚意ず泚意マップを比范する。れロショット画像怜玢にはFlickr30Kを䜿甚する。 画像分類に぀いおは、ImageNet-1KINで孊習ずテストを行い、IN-Cの砎損画像、IN-Aの敵察的画像、IN-RずIN-SKの分垃倖画像でもテストを行う。セマンティックセグメンテヌションに぀いおは、PASCAL VOC、Cityscapes、ADE20Kでテストしおいる。 䞋図はVision-Language Taskの結果を瀺しおいる。 原論文 Table 1 から匕甚 原論文 Figure 6 から匕甚 䞋図は画像の分類, ロバスト性の結果を瀺しおいる。 原論文 Table 2 から匕甚 原論文 Figure 7 から匕甚 トップダりンのアテンション蚭蚈から埗られるオブゞェクト䞭心の衚珟は、砎損した画像、敵察的な画像、分垃倖の画像に察する汎化を可胜にする。 結論 著者らは、芖芚的なトップダりン型の泚意方法であるAbSAnalysis-by-Synthesisずスパヌス再構成の機胜的等䟡性に関する先行研究から、 目的志向的なトップダりン倉調を行うこずで、AbSず同様のスパヌス再構築を最適化するこずを瀺した。その結果、トップダりン型の泚意を再珟できるこずを瀺した。 たた、著者らは、AbSを倉動的に近䌌するトップダりン倉調ViTモデルであるAbSViTを提案した。AbsViTは制埡可胜なトップダりン泚意を達成し、V&Lタスク、画像分類、ロバスト性においおベヌスラむンよりも改善するこずを瀺した。 新たなタスクを提案した論文 Connecting Vision and Language with Video Localized Narratives 5 抂芁 VisionLanguageのこれたでの研究 Image Captioning静止画に察しお、キャプションの䞀郚の単語をGrounding結び぀け Localized Narrative アノテヌタヌが自分で画像を説明しながら、説明しおいる領域をマりスで指定→音声ずマりスポむンタが同期しおいるため、各単語の芖芚的なGroundingが正確に行える Video Localized Narratives本論文静止画→動画に拡匵 静止画ず動画の違い 静止画ある䞀瞬のみ蚘述 VS 動画オブゞェクト間の関係性や盞互䜜甚など䞀連のむベントを蚘述 動画の堎合より詳现なNarrativeをアノテヌション可胜である。動画の脈略を参照できる可胜性が増え、察象物のco-reference共参照問題の解決にも぀ながるe.g. 同䞀の名詞オりムがNarrative䞭に耇数回出珟し、か぀異なるむンスタンスを瀺す堎合、オりムの现かな芋た目の違いや動䜜などで参照先の曖昧性を回避できる Contribution Video Localized Narrrativesをアノテヌションするプロトコルを提案 アクタヌ動画の登堎人物人、オりム、背景などごずに説明 受動関係が明確になるこずで耇雑なむベントを正確に蚘述e.g. 人がオりムを觊る/オりムが人に觊られおいる キヌフレヌムごずに説明 動画に察しお説明しようずするず、顕著なオブゞェクト䞻圹のみを蚘述する可胜性が高い 䜜成したデヌタセットをVideo Narrative Grounding (VNG)ずVideo Question Answering (VQA)ぞ適甚 埓来のVideo Narrative Grounding (VNG) 䞋図はVNGのタスク定矩を瀺しおいる。 入力映像、説明文Narrative、説明文䞭の名詞の䜍眮 出力参照されたオブゞェクトのフレヌムごずのセグメンテヌションマスク 原論文 Figure 5 から匕甚 提案手法 ベヌスラむン ReferFormer を拡匵 䞋図はReferFormerの凊理流れを瀺しおいる。 ReferFormerは映像から特城を抜出するためのVisual Encoderず、説明文から特城条件付きク゚リ特城を抜出するためのText Encoderで構成される。 Text Encoderから抜出した 単語ごずの特城量  )をプヌルしお、文党䜓の特城量 ずする これらの぀のモヌダルの特城量をDecodeしおフレヌム毎のセグメンテヌションマスクを埗る 原論文 Figure 2 から匕甚 ReferFormerの課題 文党䜓の特城を甚いおいるが、これが有効なのは「文党䜓が1぀のオブゞェクトを蚘述する堎合」 VNGでは぀の動画に察しお耇数のアクタヌオブゞェクトが存圚するためそぐわない ReferFormer-VNG提案手法 アクタヌごずの Narrativeの名詞に限定しお 単語ごずの特城量 を抜出、それらをプヌルしお文党䜓の特城量ずする。 2぀の異なるオりムをセグメンテヌションに分ける堎合、最初の「オりム」のNarrativeの名詞に察しおReferFormer-VNGを実行し、次の「オりム」は回目ず異なるNarrativeの名詞の特城を䜿っお2回目に実行する。 本論文ではMouse Traceは孊習・評䟡には䜿っおいない。VQAデヌタセットを䜜成する際のみに䜿甚。 デヌタセット 䞋図はVNGのデヌタセットを瀺しおいる。既存デヌタセットに察しお、物䜓間の盞互関係を含む状況説明narrativeずその堎所マりス䜍眮を付䞎する。 原論文 Table 1 から匕甚 䞋図はOVIS/UVO-ViDLN提案デヌタセットを瀺しおいる。 OVISずUVOに察しお、状況説明narrativeずその堎所マりス䜍眮を付䞎する すべおの単語圢容詞、動詞を含むをマりス䜍眮をトレヌスしおGrounding 原論文 Figure S1 から匕甚 䞋図は OVIS を瀺しおいる。 video segmentation甚デヌタセットe.g. person, fish, vehicle, horse, sheep  出兞 http://songbai.site/ovis/ 䞋図は UVO を瀺しおいる。 video segmentation甚デヌタセットe.g. person, car, chair, bottle  出兞 UVO論文 Figure 3 Ego4D 䞀人称芖点のみ 䞀郚の名刺のみを矩圢でGrounding Epic-Kitchens キッチン内のみ すべおの名詞をピクセル単䜍でGrounding 実隓 評䟡尺床 & Measure ず の平均 空間的な正しさ認識結果ずGroundTruthのマスクのIoU クラスの正しさ各マスクのクラス認識結果のF倀; PrecisionずRecallの調和平均 デヌタセット OVIS-ViDLN, UVO-ViDLN 加算名詞のみを採甚e.g. car, parrotし、stuff categoriese.g. sky, waterは陀倖。 Method/Dataset OVIS UVO Baseline(Full narrative) 22.9 25.8 Baseline(Noun) 25.7 35.6 Proposed(Best) 32.7 46.4 結論 著者らは、動画に察するキャプショングを解くためのデヌタアノテヌションのプロトコルずデヌタセットを構築し、ベヌスラむンの手法を提案した。 手法自䜓はシンプルで効果的ではあるものの、アクタヌの数だけReferFomer-VNGを実行するために耇雑な説明文に察する蚈算コストが高い。 Visual Programming: Compositional visual reasoning without training 6 抂芁 背景 これたでの汎甚AIシステムを構築するための䞻なアプロヌチぱンド・ツヌ・゚ンドで孊習可胜なモデルを甚いた倧芏暡な教垫なし事前孊習ず、それに続く教垫ありマルチタスク孊習だった。しかしこのアプロヌチでは、各タスク甚に敎備されたデヌタセットが必芁なので、汎甚AIシステムに耇雑なタスクを実行させるには、無限ずも蚀えるデヌタセットが必芁になる。したがっお、このアプロヌチで汎甚AIシステムを耇雑なタスクが実行できるように拡匵するこずは困難である。 䟋えばテレビ番組「ビッグバン★セオリヌ」に登堎する7人のメむンキャラクタヌをこの画像にタグ付けするずいうタスクを考える。 このタスクを実行するために、システムはたず指瀺の意図を理解し、顔を怜出し、知識ベヌスからビッグバン★セオリヌの䞻芁登堎人物のリストを取埗し、登堎人物のリストを䜿甚しお顔を分類し、認識された登堎人物の顔ず名前を画像にタグ付けするずいう䞀連のステップを実行する必芁がある。 これらの各ステップを実行するさたざたな芖芚システムや蚀語システムが存圚するが、自然蚀語で蚘述されたこのタスク党䜓を実行するこずは、珟状の゚ンド・ツヌ・゚ンドで蚓緎されたシステムの範囲を超えおいる。 出兞 https://cvpr2023.thecvf.com/media/cvpr-2023/Slides/22652.pdf Contribution 人々が実行したいず思うような耇雑で倚様なタスクに察応する汎甚AIシステムを提案 提案手法 倧芏暡蚀語モデルの文脈内孊習胜力を利甚し、タスク固有のトレヌニングを必芁ずせず、自然蚀語で蚘述されたタスクを、゚ンド・ツヌ・゚ンドに特化した孊習枈みモデルや他のプログラムで凊理できるような単玔なステップに分解するこずで、耇雑で幅広いタスクに察応できる、 VISPROG ずいうシステムを提案。 VISPROGは、ビゞュアルデヌタ単䞀の画像たたは画像のセットず自然蚀語呜什の入力からステップのシヌケンスVISPROGプログラムを生成し、それを実行しお解ず包括的で解釈可胜な根拠の䞡方を埗る。 生成されたプログラムの各行は、垂販のコンピュヌタビゞョンモデル、画像凊理サブルヌチン、たたはpython関数など幅広いモゞュヌルのうちの1぀を呌び出し実行するこずでプログラムの埌続郚分で消費される可胜性のある䞭間出力を生成する。 䞋図の「Factual Knowledge Object Tagging」の䟋では、VISPROGによっお生成された芖芚的プログラムは、顔怜出噚、知識怜玢システムずしおのGPT-3、およびオヌプン語圙画像分類噚ずしおのCLIPを呌び出しお、目的の出力を生成する。 原論文 Figure 1 から匕甚 LLMによるプログラム生成 VISPROGは、GPT-3に自然蚀語で蚘述された呜什ず垌望する高レベルプログラムの䟋をプロンプトし、GPT-3の文脈内孊習胜力を利甚しお、実際の呜什甚のプログラムを出力する。 䞋図は画像線集タスクに察するプロンプトを瀺しおいる。これらコンテキスト内のプログラム䟋は手動で曞かれおおり、通垞、画像を添付するこずなく構築可胜。 VISPROG プログラムの各行プログラムステップは、モゞュヌル名、モゞュヌルの入力匕数名ずその倀、出力倉数名で構成される。GPT-3が各モゞュヌルの入出力タむプや機胜を理解できるように、説明的なモゞュヌル名䟋"Select"、"ColorPop"、"Replace"、匕数名䟋"image"、"object"、"query"、倉数名䟋"IMAGE"、"OBJ"を䜿甚。 これらのむンコンテキストの䟋は、新しい自然蚀語呜什ずずもにGPT-3に䟛絊され、画像やその内容を芳察するこずなく、VISPROGは入力画像䞊で実行可胜なプログラム䞋図の埌段を生成し、蚘述されたタスクを実行する。 原論文 Figure 3 から匕甚 モゞュヌル 䞋図はVISPROGで実珟可胜な映像解析凊理を瀺しおいる。 VISPROGは珟圚、画像理解、画像操䜜生成を含む、知識怜玢、算術・論理挔算などの機胜を実珟する20のモゞュヌルをサポヌトしおいる。 原論文 Figure 5 から匕甚 VISPROGでは、各モゞュヌルは䞋図の通りPythonクラスずしお実装され、 (i)行を解析しお入力匕数名ず倀、出力倉数名を抜出する (ii)孊習枈みニュヌラルモデルを含む可胜性のある必芁な凊理を実行し、出力倉数名ず倀でプログラム状態を曎新する (iii)VISPROGの凊理の流れを芖芚的に確認できる メ゜ッドを持぀。 モゞュヌルクラスを実装しお登録するだけでVISPROG に新しいモゞュヌルを远加するこずもできる。 原論文 Code 1 から匕甚 プログラムの実行 プログラムの実行はむンタヌプリタヌが行う。むンタヌプリタヌは、以䞋のような流れで動䜜する。 (i)プログラムの状態倉数名ずその倀を察応付けた蟞曞を入力で初期化 (ii)その行で指定された入力で正しいモゞュヌルを呌び出しながら、プログラムを行ごずにステップ実行 (iii)各ステップの実行埌、プログラム状態をステップの出力名ず倀で曎新 芖芚的根拠の提瀺 各モゞュヌルクラスには、モゞュヌルの入力ず出力をHTMLスニペットで芖芚的に芁玄するメ゜ッドも甚意されおいる。 むンタヌプリタヌは、すべおのプログラムステップのHTML芁玄を繋ぎ合わせお、プログラムの論理的正しさを分析し最終的な出力を怜査するために䜿甚できる芖芚的根拠䞋図を提瀺できる。 こうした芖芚的な根拠は、ナヌザヌが倱敗の理由を理解し、パフォヌマンスを向䞊させるために自然蚀語呜什を最小限に調敎するこずも可胜にする。 原論文 Figure 4 から匕甚 実隓 VISPROGは、倚様で耇雑な芖芚タスクに適甚できる柔軟なフレヌムワヌクを提䟛する。 本実隓では空間掚論、耇数画像に関する掚論、知識怜玢、画像生成ず操䜜の4぀のタスクで評䟡を実斜した。 各タスクで䜿甚された入力、出力、およびモゞュヌルは䞋図の通り。 原論文 Figure 5 から匕甚 Compositional Visual Question Answering VISPROGの構成的で倚段階の芖芚的質問応答タスクGQAぞの適性を確認した。 GQAタスクのためのモゞュヌルには、オヌプン語圙のロヌカラむズ、VQAモゞュヌル、バりンディングボックスの座暙や空間的前眮詞above、leftなどが䞎えられた画像領域を切り取る関数、ボックスを数えるモゞュヌル、Python匏を評䟡するモゞュヌルなどがある。 䟋えば、「小さなトラックは、ヘルメットをかぶっおいる人々の巊偎にあるか、右偎にあるか」ずいうような質問に察しお、VISPROGは、たず「ヘルメットをかぶっおいる人々」をロヌカラむズし、その人々の巊偎たたは右偎の領域を切り出し、その偎に「小型トラック」があるかどうかをチェックし、あれば「left」、なければ「right」を返す。 プロンプト䜜成ではトレヌニングセットから31のランダムな質問に、垌望するVISPROGプログラムを手動でアノテヌションする。GPT-3には、GQAの各質問に回答するコストを削枛するために、このリストからランダムに抜出された、より少ないサブセットを提䟛する。 Reasoning on Image Pairs (NLVR) VQAモデルは単䞀の画像に関する質問に答えるように孊習されるが、実際には、画像コレクションに関する質問に答えるシステムが必芁ずされるかもしれない。 䟋えば、あるナヌザヌが䌑暇䞭の写真アルバムを解析し、次のような質問に答えるようシステムに求めた堎合「゚ッフェル塔を芋た翌日、私たちはどのランドマヌクを蚪れたか」 VISPROGが耇数画像の孊習デヌタで蚓緎するこずなく、単䞀画像VQAシステムを䜿甚しお、耇数画像を含むタスクを解決する胜力をNLVRベンチマヌクで確認する。 通垞、NLVRの課題に取り組むには、画像ペアを入力ずするカスタム・アヌキテクチャをNLVRの蚓緎セットで蚓緎する必芁がある。察しおVISPROGは、耇雑なステヌトメントを、個々の画像に関するより単玔な質問ず、算術挔算子および論理挔算子を含むpython匏ず、画像レベルの質問に察する回答に分解するこずでこれを実珟する。 プロンプト䜜成ではNLVRの蚓緎セットで、16のランダムなステヌトメントに぀いおVISPROGプログラムをアノテヌションする。これらの䟋のいく぀かは冗長類䌌したプログラム構造であるため、4぀の冗長なものを削陀しお12䟋のキュレヌトされたサブセットも䜜成する。 Factual Knowledge Object Tagging 名前も知らない画像の䞭の人物や物䜓䟋えば有名人、䌁業のロゎ、人気の車ずそのメヌカヌ、生物の皮等を識別したい状況においお、こうしたタスクを解決するには、人物、顔、物䜓をロヌカラむズするだけでなく、倖郚の知識ベヌスで事実知識を調べ、分類のためのカテゎリヌセットを構築する必芁がある。 このタスクを、事実知識オブゞェクト・タギングFactual Knowledge Object Taggingず呌び、VISPROGはGPT-3を暗黙の知識ベヌスずしお䜿甚する。䟋えばGPT-3に”テレビ番組「ビッグバン★セオリヌ」の䞻な登堎人物をカンマ区切りで列挙せよ”ずいった自然蚀語プロンプトで問い合わせるこずでカテゎリヌセットを生成し、埗られたカテゎリヌセットを、ロヌカリれヌションや顔怜出モゞュヌルによっお生成された画像領域を分類するCLIP画像分類モゞュヌルの分類先ずしお利甚する。 このタスク甚には14のむンコンテキストのプログラム䟋を䜜成する。これらのむンコンテキストプログラム䟋には画像は関連付けられおいない Image Editing with Natural Language テキストからの画像の生成はStable Diffusionなどのモデルにより、ここ数幎で目芚たしい進歩を遂げおいるが、「Daniel Craigの顔を:pで隠す」非特定化たたはプラむバシヌ保護、「Daniel Craigのカラヌポップを䜜成し、背景をがかす」オブゞェクトの匷調衚瀺などのプロンプトを凊理するこずは、ただ難しい。 こうしたオブゞェクトの眮き換え等のような高床な線集を実珟するには、たず関心のあるオブゞェクトを特定し、眮き換えるオブゞェクトのマスクを生成し、元の画像ずマスクおよびその䜍眮に生成する新しいピクセルの説明を䜿甚しお、画像むンペむンティングモデル本研究ではStable Diffusionを呌び出す必芁がある。VISPROGは、必芁なモゞュヌルずサンプルプログラムを備えおいれば、こうした非垞に耇雑な呜什を簡単に扱うこずができる。 このタスクでは知識タグ付けず同様に、関連する画像のないむンコンテキストの䟋を 10 個䜜成する。 結果 プロンプトサむズの圱響 GQAずNLVRでは、むンコンテキストの䟋が倚いほど性胜が向䞊するこずが䞋図から分かる。 原論文 Figure 6 から匕甚 たた、NLVRでは、VISPROGの性胜はGQAよりも少ないプロンプトで飜和しおいるが、これはNLVRのプログラムが必芁ずするモゞュヌルがGQAよりも少なく、それらのモゞュヌルを䜿甚するためのデモがGQAよりも少ないためであるず考えられる。 汎甚胜力 䞋図は各タスクにおけるVISPROGの結果を瀺しおいる。 GQAずNLVRではプロンプト戊略を倉曎した堎合の結果を合わせお報告しおいる。たた、知識タギングず画像線集ではプロンプトずしお䞎える自然文呜什のチュヌニングを行った堎合の結果も報告しおいる。 原論文 Table 1, Table 2, Table 3, Table 4 から匕甚 前者2぀ではVILTモデルずの比范を行っおおり、GQAではVILTモデルの性胜を䞊回っおいる。NLVRでは性胜が䞋回っおいるが、VISPROGはれロショットでNLVRタスクを実行するのに察しお、VILT-NLVRはNVLRでファむンチュヌニングされおいるので、VILT-NLVRでの結果は性胜の䞊限の目安であり、VISPROGがそれに近い粟床であるこずがわかる。GQAの方で粟床が䞊回っおいるのはVISPROGが利甚しおいるVQAモゞュヌルがVILT-VQAのため 埌者2぀では既存モデルでは単䜓でこのようなタスクを行えるモデルがないこずから特定のモデルずの比范はされおいないが、䞀定のレベルでこれらタスクを実行できるこずず、呜什チュヌニングによっおさらなる性胜向䞊が可胜なこずを瀺しおいる。䞋図はVISPROGの珟圚のモゞュヌルセットで可胜な画像線集の䟋であり、幅広い操䜜が可胜であるこずを瀺しおいる。 原論文 Figure 7 から匕甚 芖芚的根拠の有甚性 VISPROG による芖芚的根拠は、倱敗䟋の培底的な分析を可胜にする。 䞋図は今回の4タスクにおいお玄100サンプルず぀゚ラヌ分析した結果を瀺しおいる。GQAでは誀ったプログラムが゚ラヌの䞻な原因であり、サンプルの16%に圱響を及がしおいるずいうこずを瀺しおいる。このこずから、倱敗した問題に類䌌した、より倚くのむンコンテクスト䟋を提䟛するこずによっお、゚ラヌ発生率が改善される可胜性があるこずが分かる。同様にNLVRではVQAモデルをNLVR甚のより優れたVQAモデルに眮き換えるこずで、知識タギングや画像線集タスクでは「リスト」ず「遞択」モゞュヌルの実装に䜿甚されるモデルを改善するこずで、゚ラヌを倧きく枛らせるず考えられる。 原論文 Figure 9 から匕甚 たた、䞋図は芖芚的根拠によっお明らかになったロヌカリれヌション゚ラヌが、ロヌカリれヌションモゞュヌルにずっおより良いク゚リになるように、ナヌザがどのように呜什を修正するかを瀺した䟋である。他にも䟋えば、知識怜玢のためのより良いク゚リを提䟛するこずや、Selectモゞュヌルのためのカテゎリ名を提䟛しお、そのカテゎリに属するセグメント化された領域に怜玢を制限するこずが含たれる 実際に知識タギングや画像線集の結果を芋るず呜什チュヌニングが性胜向䞊に有効であるこずがわかる。 原論文 Figure 8 から匕甚 今埌の課題 VISPROGのような汎甚芖芚システムの性胜をさらに向䞊させるためにはナヌザヌのフィヌドバックを取り入れる新しい方法の研究が必芁である。 最埌に 本蚘事では、マルチモヌダルAIに関するCVPR2023の論文をいく぀かピックアップしおご玹介したした。NTT Comは今たでナニモヌダルAIの研究開発をメむンに取り組んで、自動翻蚳サヌビスCOTOHA Translatorや議事メモ䜜成をサポヌトするCOTOHA Meeting Assist、映像解析゜リュヌションCOTOHA Takumi Eyesずいったサヌビスを展開しおきたした。今埌はChatGPTなどのマルチモヌダルAI技術の掻甚も芖野に入れお、実蚌実隓や研究開発を進めおいきたす。 Ye, S., Xie, Y., Chen, D., Xu, Y., Yuan, L., Zhu, C., Liao, J. Improving Commonsense in Vision-Language Models via Knowledge Graph Riddles. In CVPR2023. ↩ Xie, C. W., Sun, S., Xiong, X., Zheng, Y., Zhao, D., Zhou, J. RA-CLIP: Retrieval Augmented Contrastive Language-Image Pre-Training. In CVPR2023. ↩ Rasheed, H., Khattak, M. U., Maaz, M., Khan, S., Khan, F. S. Fine-tuned clip models are efficient video learners. In CVPR2023. ↩ Shi, B., Darrell, T., Wang, X. Top-Down Visual Attention from Analysis by Synthesis. In CVPR2023. ↩ Voigtlaender, P., Changpinyo, S., Pont-Tuset, J., Soricut, R., Ferrari, V. Connecting Vision and Language with Video Localized Narratives. In CVPR2023. ↩ Gupta, T., & Kembhavi, A. Visual programming: Compositional visual reasoning without training. In CVPR2023. ↩
TOC サマリ 抂芁 怜蚌 - IP Precedence 条件による TEL3VPN Per-Flow Steering - 怜蚌項目ずトポロゞヌ 怜蚌手順 1. Underlay & VPN & メトリック の蚭定 2. LSP の定矩 3. ip-filter の定矩 4. ip-filter を VPN の ingress interface に適甚 5. ip-filter、LSP が適甚されおいる事を確認 6. 疎通確認 怜蚌 - CoS 条件による TEL2VPN Per-Flow Steering - 怜蚌項目ずトポロゞヌ SR OS を PE ずしお甚いる際の L2VPN Per-Flow Steering の実珟方法 怜蚌手順 1. Underlay & メトリック の蚭定 2. EVI の蚭定 3. PXC の蚭定 4. PXC を甚いた EVI 間の接続 5. LSP の定矩 6. EVI ず LSP の関連付け 7. mac-filter の定矩ず EVI ぞの適甚 8. 疎通確認 たずめ サマリ SR-MPLS で構成されたネットワヌクにおいお、Per-Flow Steering を実珟 SR OS で IP Precedence に基づいた Traffic Engineering (TE) の怜蚌に成功 SR OS で Class of Service (CoS) に基づいた TE の怜蚌に成功 この蚘事は Multi-AS Segment Routing 怜蚌連茉の第 17 回です。目次は こちら 抂芁 むノベヌションセンタヌの岩田です。普段の業務では Multi-AS Segment Routing に関する技術怜蚌や、ベンチャヌ䌁業ぞの技術支揎でスマヌトフォンアプリケヌション開発業務などを行なっおいたす。 第 8 回 の蚘事で IOS XR + Junos の 2 ぀のベンダヌ機噚で構成される L3VPN においお 指定した 5-tuple や IP Precedence に関する条件に埓っお TE を実珟する方法を玹介したした。 今回は新たに Nokia SR OSService Router Operating Systemを加えた 3 ぀のベンダヌ機噚から構成される環境においお、IP Precedence 条件に埓う TE ず、CoS 条件に埓う TE を実珟する方法を玹介したす。 怜蚌 - IP Precedence 条件による TEL3VPN Per-Flow Steering - 怜蚌項目ずトポロゞヌ 以䞋のような構成で、IP Precedence に基づく TE が実珟できるかを怜蚌したす。 なお本蚘事では䞋蚘のバヌゞョンで怜蚌したした。 rt01: SR OS 22.7.R1 rt02: IOS XR 7.4.1 rt03: Junos 21.3R1.9 rt04: SR OS 22.7.R1 怜蚌手順 以䞋の手順で怜蚌したす。 Underlay & VPN & メトリック の蚭定 LSP の定矩 ip-filter の定矩 ip-filter を VPN の ingress interface に適甚 ip-filter、LSP が適甚されおいる事を確認 疎通確認 1. Underlay & VPN & メトリック の蚭定 蚭定は省略したす。Underlay & VPN の蚭定は 第 12 回 を、メトリックの蚭定は 第 15 回 の蚘事をそれぞれ参照ください。 以䞋のように L3VPN が構築できおいる事を確認したす。 rt01 [ro:/configure] A:user@rt01# /show router bgp routes vpn-ipv4 =============================================================================== BGP Router ID:10.255.0.1 AS:65000 Local AS:65000 =============================================================================== Legend - Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid l - leaked, x - stale, > - best, b - backup, p - purge Origin codes : i - IGP, e - EGP, ? - incomplete =============================================================================== BGP VPN-IPv4 Routes =============================================================================== Flag Network LocalPref MED Nexthop (Router) Path-Id IGP Cost As-Path Label ------------------------------------------------------------------------------- u*>i 65000:100:192.168.123.0/24 100 None 10.255.0.4 None 20 No As-Path 524284 u*>i 65000:100:192.168.123.254/32 100 0 10.255.0.4 None 20 No As-Path 524284 ------------------------------------------------------------------------------- Routes : 2 =============================================================================== rt04 [/] A:user@rt04# /show router bgp routes vpn-ipv4 =============================================================================== BGP Router ID:10.255.0.4 AS:65000 Local AS:65000 =============================================================================== Legend - Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid l - leaked, x - stale, > - best, b - backup, p - purge Origin codes : i - IGP, e - EGP, ? - incomplete =============================================================================== BGP VPN-IPv4 Routes =============================================================================== Flag Network LocalPref MED Nexthop (Router) Path-Id IGP Cost As-Path Label ------------------------------------------------------------------------------- u*>i 65000:100:192.168.23.0/24 100 None 10.255.0.1 None 20 No As-Path 524284 u*>i 65000:100:192.168.23.254/32 100 0 10.255.0.1 None 20 No As-Path 524284 ------------------------------------------------------------------------------- Routes : 2 =============================================================================== 2. LSP の定矩 IP Precedence が 3 の時に適甚する LSP を蚭定したす。 [ex:/configure router "Base" mpls] A:user@rt01# info path "rt01_rt03_rt04" { admin-state enable hop 10 { sid-label 16003 } hop 20 { sid-label 16004 } } lsp "for_precedence3" { admin-state enable type p2p-sr-te to 10.254.0.4 primary "rt01_rt03_rt04" { } } 3. ip-filter の定矩 受信したパケットの IP Precedence の倀に応じお適切な LSP を適甚するために ip-filter を定矩したす。 [ex:/configure] A:user@rt01# info filter ip-filter for_cust-a filter-id 1 entry 1 { match { dscp cs3 } action { forward { vprn-target { bgp-nh 10.255.0.4 vprn "cust-a" lsp "for_precedence3" } } } } entry 100 { action { accept } } 4. ip-filter を VPN の ingress interface に適甚 定矩した ip-filter を cust-a の sapservice access point の ingress パラメヌタずしお適甚したす。 [gl:/configure] A:user@rt01# /info service vprn "cust-a" interface "to_cust-a" sap 1/1/c3/1:0 admin-state enable ingress { filter { ip "for_cust-a" } } 5. ip-filter、LSP が適甚されおいる事を確認 定矩した filter が適甚されおいるこずず、パケットの転送先が指定した LSP になっおいるこずを確認したす。 [/] A:user@rt01# show filter ip "for_cust-a" | no-more =============================================================================== IP Filter =============================================================================== Filter Id : 1 Applied : Yes Scope : Template Def. Action : Drop Type : Normal Shared Policer : Off System filter : Unchained Radius Ins Pt : n/a CrCtl. Ins Pt : n/a RadSh. Ins Pt : n/a PccRl. Ins Pt : n/a Entries : 3 Sub-Entries : 4 Description : (Not Specified) Filter Name : for_cust-a ------------------------------------------------------------------------------- Filter Match Criteria : IP ------------------------------------------------------------------------------- Entry : 1 Description : (Not Specified) Log Id : n/a Src. IP : 0.0.0.0/0 Src. Port : n/a Dest. IP : 0.0.0.0/0 Dest. Port : n/a Protocol : Undefined Dscp : cs3 ICMP Type : Undefined ICMP Code : Undefined Fragment : Off Src Route Opt : Off Sampling : Off Int. Sampling : On IP-Option : 0/0 Multiple Option: Off Tcp-flag : (Not Specified) Option-pres : Off Egress PBR : Disabled Primary Action : Forward (VPRN Target) BGP NH Address : 10.255.0.4 Router : 100 LSP : for_precedence3 Service Label : 16 Extended Action : None Secondary Action : None PBR Down Action : Forward (entry-default) Downloaded Action : Primary Dest. Stickiness : None Hold Remain : 0 Ing. Matches : 0 pkts Egr. Matches : 0 pkts Entry : 100 Description : (Not Specified) Log Id : n/a Src. IP : 0.0.0.0/0 Src. Port : n/a Dest. IP : 0.0.0.0/0 Dest. Port : n/a Protocol : Undefined Dscp : Undefined ICMP Type : Undefined ICMP Code : Undefined Fragment : Off Src Route Opt : Off Sampling : Off Int. Sampling : On IP-Option : 0/0 Multiple Option: Off Tcp-flag : (Not Specified) Option-pres : Off Egress PBR : Disabled Primary Action : Forward Ing. Matches : 75 pkts (5970 bytes) Egr. Matches : 0 pkts =============================================================================== たた、LSP が Up しおいるこずも確認したす。 [/] A:user@rt01# show router mpls sr-te-lsp =============================================================================== MPLS SR-TE LSPs (Originating) =============================================================================== LSP Name Tun Protect Adm Opr To Id Path ------------------------------------------------------------------------------- for_precedence3 4 N/A Up Up 10.254.0.4 ------------------------------------------------------------------------------- LSPs : 1 =============================================================================== 6. 疎通確認 以䞋のように、想定した TE を実珟できおいる事が確認できたした。 IP Precedence が 3 の時の TE 結果 user@vm01:~$ traceroute 192.168.123.1 -t 96 -n -q 1 traceroute to 192.168.123.1 (192.168.123.1), 30 hops max, 60 byte packets 1 192.168.23.254 1.997 ms 2 10.1.3.2 3.714 ms 3 192.168.123.254 3.606 ms 4 192.168.123.1 3.549 ms それ以倖のパケットの時の TE 結果 user@vm01:~$ traceroute 192.168.123.1 -n -q 1 traceroute to 192.168.123.1 (192.168.123.1), 30 hops max, 60 byte packets 1 192.168.23.254 1.192 ms 2 10.1.2.2 2.918 ms 3 192.168.123.254 2.497 ms 4 192.168.123.1 2.484 ms たた、パケットカりンタを確認するず受信したパケットが各 entry に振り分けられたこずが確認できたす。 [/] A:user@rt01# show filter ip "for_cust-a" counters =============================================================================== IP Filter =============================================================================== Filter Id : 1 Applied : Yes Scope : Template Def. Action : Drop Type : Normal Shared Policer : Off System filter : Unchained Radius Ins Pt : n/a CrCtl. Ins Pt : n/a RadSh. Ins Pt : n/a PccRl. Ins Pt : n/a Entries : 3 Sub-Entries : 4 Description : (Not Specified) Filter Name : for_cust-a ------------------------------------------------------------------------------- Filter Match Criteria : IP ------------------------------------------------------------------------------- Entry : 1 Ing. Matches : 25 pkts (1950 bytes) Egr. Matches : 0 pkts Entry : 100 Ing. Matches : 100 pkts (7920 bytes) Egr. Matches : 0 pkts =============================================================================== 怜蚌 - CoS 条件による TEL2VPN Per-Flow Steering - 怜蚌項目ずトポロゞヌ 以䞋のような構成の L2VPN 䞊で、CoSClass of Serviceに基づく TE を実珟できるかを怜蚌したす。 なお本蚘事では䞋蚘のバヌゞョンで怜蚌したした。 rt01: SR OS 22.7.R1 rt02: IOS XR 7.4.1 rt03: Junos 21.3R1.9 rt04: Junos 21.3R1.9 SR OS を PE ずしお甚いる際の L2VPN Per-Flow Steering の実珟方法 SR OS においお、L2VPN Per-Flow Steering を行うためのコマンドや機胜はないため、 以䞋に瀺す構成のように、耇数の EVPN Instance (EVI) ずむンスタンス間を接続するための port cross-connect(PXC)、mac-filter の機胜を組み合わせお実珟する必芁がありたす。 rt01 においお、察向 PErt04から送られおきたパケットは pbf においお受信したす。 vm01 から受信したパケットは pbf で受信した埌、CoS の倀に応じお pbf_cos7 か pbf_default ぞパケットを転送し、 pbf_cos7 、 pbf_default から送信したす。 これを実珟するためには、以䞋の芁件を満たすように蚭定する必芁がありたす。 芁件 1  CoS に基づいた EVI ぞの転送を優先するため、 PBF を行う EVI (EVI 4000) は EVPN で経路を受信させない 仮に EVI 4000 に察向 rt04 の経路が存圚するずそちらが優先され、転送甚 EVI が䜿甚されなくなるためです。 芁件 2 転送甚 EVI が 察向 MAC アドレスずポヌトの組み合わせを誀っお孊習しないように、EVPN 越しに受け取った BUM トラフィックをパケット転送甚の EVI (EVI 14000、EVI 24000) ぞ転送させない 仮に EVI 4000 から EVI 14000 に BUM を転送しおしたうず、EVI 14000 はその送信元 MAC アドレスをみお、転送先を EVPN 経路ではなく EVI 4000 に戻るポヌトぞ指定するテヌブルを䜜成しおしたい、 EVI 4000 ず EVI 14000 の間でルヌプが発生するためです。 怜蚌手順 以䞋の手順で怜蚌したす。 Underlay & メトリック の蚭定 EVI の蚭定 PXC の蚭定 PXC を甚いた EVI 間の接続 LSP の定矩 EVI ず LSP の関連付け mac-filter の定矩ず EVI ぞの適甚 疎通確認 1. Underlay & メトリック の蚭定 省略したす。 Underlay & VPN の蚭定は 第 13 回 を、メトリックの蚭定は 第 15 回 の蚘事をそれぞれ参照ください。 2. EVI の蚭定 PBF 甚のむンスタンス 1 ぀ず、転送甚のむンスタンス 2 ぀、蚈 3 ぀のむンスタンスを立おたす。 芁件 1 を満たすために経路送受信を reject するポリシヌを䜜成し、以䞋のように適甚したす。 PBF 甚のむンスタンス vsi import 時に適甚する経路を受信しない 転送甚のむンスタンス vsi export 時に適甚する経路を送信しない 経路送受信を拒吊するためのポリシヌ [gl:/configure] A:user@rt01# info policy-options policy-statement "all-reject" entry 1 { action { action-type reject } } PBF 甹 EVI [gl:/configure service vpls "pbf"] A:user@rt01# info admin-state enable service-id 4000 customer "cust-a" bgp 1 { route-distinguisher "10.255.0.1:4000" vsi-import ["all-reject"] route-target { export "target:65000:4000" import "target:65000:4000" } } bgp-evpn { evi 4000 mpls 1 { admin-state enable auto-bind-tunnel { resolution filter resolution-filter { sr-isis true } } } } sap 1/1/c4/1:4001 { admin-state enable } CoS が 0デフォルト倀のパケット転送甚 EVI [gl:/configure service vpls "pbf_default"] A:user@rt01# info admin-state enable service-id 14000 customer "cust-a" bgp 1 { route-distinguisher "10.255.0.1:14000" vsi-export ["all-reject"] route-target { import "target:65000:4000" } } bgp-evpn { evi 14000 mpls 1 { admin-state enable auto-bind-tunnel { resolution any } } } CoS が 7 のパケット転送甚 EVI [gl:/configure service vpls "pbf_cos7"] A:user@rt01# info admin-state enable service-id 24000 customer "cust-a" bgp 1 { route-distinguisher "10.255.0.1:24000" vsi-export ["all-reject"] route-target { import "target:65000:4000" } } bgp-evpn { evi 24000 mpls 1 { admin-state enable auto-bind-tunnel { resolution any } } } 3. PXC の蚭定 EVI 同士を接続するために PXC を蚭定したす。 PXC には物理ポヌトを消費するモヌドず消費しないモヌドがありたすが、本蚘事の怜蚌では埌発で開発された埌者を䜿甚したす。 以䞋のように pxc port を接続し、EVI 同士を接続したす。 pxc-1.a: pbf_default <-> pxc-1.b: pbf pxc-2.a: pbf_cos7 <-> pxc-2.b: pbf PXC の詳しい仕様を知りたい方は こちら を参照ください。 card 1 { card-type iom-1 mda 1 { mda-type me6-100gb-qsfp28 xconnect { mac 1 { loopback 1 { bandwidth 100 } loopback 2 { bandwidth 100 } } } } } port-xc { pxc 1 { admin-state enable port-id 1/1/m1/1 } pxc 2 { admin-state enable port-id 1/1/m1/2 } } port 1/1/m1/1 { admin-state enable } port 1/1/m1/2 { admin-state enable } port pxc-1.a { admin-state enable ethernet { mode hybrid encap-type dot1q } } port pxc-1.b { admin-state enable ethernet { mode hybrid encap-type dot1q } } port pxc-2.a { admin-state enable ethernet { mode hybrid encap-type dot1q } } port pxc-2.b { admin-state enable ethernet { mode hybrid encap-type dot1q } } 蚭定した PXC port が Up しおいるこずを確認したす。 A:user@rt01# /show port =============================================================================== Ports on Slot 1 =============================================================================== Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/ Id State State MTU MTU Bndl Mode Encp Type MDIMDX ------------------------------------------------------------------------------- 1/1/c1 Up Link Up conn 100GBASE-LR4* 1/1/c1/1 Up Yes Up 9212 9212 - hybr dotq cgige 1/1/c2 Up Link Up conn 100GBASE-LR4* 1/1/c2/1 Up Yes Up 9212 9212 - hybr dotq cgige 1/1/c3 Up Link Up conn 100GBASE-LR4* 1/1/c3/1 Up Yes Up 1506 1506 - hybr dotq cgige 1/1/c4 Up Link Up conn 100GBASE-LR4* 1/1/c4/1 Up Yes Up 9212 9212 - hybr dotq cgige 1/1/c5 Up Link Up conn 100GBASE-LR4* 1/1/c5/1 Up No Down 9212 9212 - hybr dotq cgige 1/1/c6 Up Link Up conn 100GBASE-LR4* 1/1/c6/1 Up No Down 9212 9212 - hybr dotq cgige 1/1/m1/1 Up Link Up anchor 1/1/m1/2 Up Link Up anchor =============================================================================== Ports on Slot A =============================================================================== Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/ Id State State MTU MTU Bndl Mode Encp Type MDIMDX ------------------------------------------------------------------------------- A/1 Up Yes Up 1514 1514 - netw null faste MDI A/3 Down No Down 1514 1514 - netw null faste A/4 Down No Down 1514 1514 - netw null faste =============================================================================== Ports on Port Cross Connect 1 =============================================================================== Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/ Id State State MTU MTU Bndl Mode Encp Type MDIMDX ------------------------------------------------------------------------------- pxc-1.a Up Yes Up 9208 9208 - hybr dotq cgige pxc-1.b Up Yes Up 9208 9208 - hybr dotq cgige =============================================================================== Ports on Port Cross Connect 2 =============================================================================== Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/ Id State State MTU MTU Bndl Mode Encp Type MDIMDX ------------------------------------------------------------------------------- pxc-2.a Up Yes Up 9208 9208 - hybr dotq cgige pxc-2.b Up Yes Up 9208 9208 - hybr dotq cgige =============================================================================== 4. PXC を甚いた EVI 間の接続 PXC を Virtual Private LAN Service (VPLS) の SAP ずしお蚭定するこずで EVI に PXC port を接続したす。 芁件 2 で述べた EVI pbf においお EVPN 経由で受け取った BUM トラフィックを PXC ぞ流さないようにするため、split horizon group の蚭定を bgp-evpn ず sap pxc-x.b:0 の階局ぞ远加したす。 [gl:/configure] A:user@rt01# info service vpls "pbf" { bgp-evpn { split-horizon-group "SHG-pbf" } split-horizon-group "SHG-pbf" { } sap pxc-1.b:0 { admin-state enable split-horizon-group "SHG-pbf" } sap pxc-2.b:0 { admin-state enable split-horizon-group "SHG-pbf" } } vpls "pbf_cos7" { sap pxc-2.a:0 { admin-state enable } } vpls "pbf_default" { sap pxc-1.a:0 { admin-state enable } } 各 EVI で PXC が玐づいおいるこずが確認できたす。 [/] A:user@rt01# show service id 4000 sap =============================================================================== SAP(Summary), Service 4000 =============================================================================== PortId SvcId Ing. Ing. Egr. Egr. Adm Opr QoS Fltr QoS Fltr ------------------------------------------------------------------------------- pxc-1.b:0 4000 1 none 1 none Up Up pxc-2.b:0 4000 1 none 1 none Up Up 1/1/c4/1:4001 4000 1 mac 1 none Up Up ------------------------------------------------------------------------------- Number of SAPs : 3 ------------------------------------------------------------------------------- =============================================================================== [/] A:user@rt01# show service id 14000 sap =============================================================================== SAP(Summary), Service 14000 =============================================================================== PortId SvcId Ing. Ing. Egr. Egr. Adm Opr QoS Fltr QoS Fltr ------------------------------------------------------------------------------- pxc-1.a:0 14000 1 none 1 none Up Up ------------------------------------------------------------------------------- Number of SAPs : 1 ------------------------------------------------------------------------------- =============================================================================== [/] A:user@rt01# show service id 24000 sap =============================================================================== SAP(Summary), Service 24000 =============================================================================== PortId SvcId Ing. Ing. Egr. Egr. Adm Opr QoS Fltr QoS Fltr ------------------------------------------------------------------------------- pxc-2.a:0 24000 1 none 1 none Up Up ------------------------------------------------------------------------------- Number of SAPs : 1 ------------------------------------------------------------------------------- =============================================================================== 5. LSP の定矩 転送甚の各 EVI にお受信した経路に察し、蚭蚈に埓った LSP を定矩するこずで EVI ぞ関連付けを行いたす。 定矩した LSP ず EVI の関連付けには admin-tag 機胜を甚いたす。 Dynamic TE の LSP ず admin-tag を定矩したす。 [gl:/configure routing-options] A:user@rt01# info admin-tags { admin-tag "tag-igp-metric" { } admin-tag "tag-te-metric" { } route-admin-tag-policy "RATP-igp" { include "tag-igp-metric" { } } route-admin-tag-policy "RATP-te" { include "tag-te-metric" { } } } [gl:/configure router "Base" mpls] A:user@rt01# info path "metric-te-path" { admin-state enable } lsp "dynamic-metric-IGP" { admin-state enable type p2p-sr-te to 10.255.0.4 vprn-auto-bind true path-computation-method local-cspf metric-type igp admin-tag "tag-igp-metric" { } primary "metric-te-path" { admin-state enable } } lsp "dynamic-metric-TE" { admin-state enable type p2p-sr-te to 10.255.0.4 vprn-auto-bind true path-computation-method local-cspf metric-type te admin-tag "tag-te-metric" { } primary "metric-te-path" { admin-state enable } } 6. EVI ず LSP の関連付け EVI の経路 import 時に admin-tag を指定するこずで特定の LSP ず玐づけたす。 [gl:/configure policy-options] A:user@rt01# info community "target-4000" { member "target:65000:4000" { } } policy-statement "import-cos7" { entry 1 { from { community { name "target-4000" } } action { action-type accept admin-tag-policy "RATP-te" } } } policy-statement "import-default" { entry 1 { from { community { name "target-4000" } } action { action-type accept admin-tag-policy "RATP-igp" } } } [gl:/configure service vpls "pbf_default"] A:user@rt01# info bgp 1 { vsi-import ["import-default"] } [gl:/configure service vpls "pbf_cos7"] A:user@rt01# info bgp 1 { vsi-import ["import-cos7"] } 7. mac-filter の定矩ず EVI ぞの適甚 CoS=7 のパケットのみを pxc-2.b:0 、その他を pxc-1.b:0 ぞ転送する filter を定矩し、 pbf の SAP interface ぞ適甚したす。 [gl:/configure filter mac-filter "for_vpls-4000"] A:user@rt01# info filter-id 4001 entry 1 { match { dot1p { priority 7 mask 7 } } action { forward { sap { vpls "pbf" sap-id pxc-2.b:0 } } } } entry 10 { action { forward { sap { vpls "pbf" sap-id pxc-1.b:0 } } } } 䜜成した filter が適甚されおいる事ず、パケットの転送先が指定した LSP になっおいる事を確認したす。 [/] A:user@rt01# show filter mac "for_vpls-4000" =============================================================================== Mac Filter =============================================================================== Filter Id : 4001 Applied : Yes Scope : Template Def. Action : Drop Entries : 2 Type : normal Description : (Not Specified) Filter Name : for_vpls-4000 ------------------------------------------------------------------------------- Filter Match Criteria : Mac ------------------------------------------------------------------------------- Entry : 1 FrameType : Ethernet Description : (Not Specified) Log Id : n/a Src Mac : Undefined Dest Mac : Undefined Dot1p : 7/7 Ethertype : Undefined DSAP : Undefined SSAP : Undefined Snap-pid : Undefined ESnap-oui-zero : Undefined Primary Action : Forward (SAP) Next Hop : pxc-2.b:0 Service Id : 4000 PBR Target Status : Up Secondary Action : None PBR Down Action : Drop (entry-default) Downloaded Action : Primary Dest. Stickiness : None Hold Remain : 0 Ing. Matches : 22829 pkts (2417234 bytes) Egr. Matches : 0 pkts Entry : 10 FrameType : Ethernet Description : (Not Specified) Log Id : n/a Src Mac : Undefined Dest Mac : Undefined Dot1p : Undefined Ethertype : Undefined DSAP : Undefined SSAP : Undefined Snap-pid : Undefined ESnap-oui-zero : Undefined Primary Action : Forward (SAP) Next Hop : pxc-1.b:0 Service Id : 4000 PBR Target Status : Up Secondary Action : None PBR Down Action : Drop (entry-default) Downloaded Action : Primary Dest. Stickiness : None Hold Remain : 0 Ing. Matches : 30271 pkts (3202038 bytes) Egr. Matches : 0 pkts =============================================================================== 8. 疎通確認 CoS の倀に応じおそれぞれ適切な経路が遞択され TE が実珟できおいるかどうかは、 monitor port コマンドを甚いお各ポヌトから送信されおいるパケットの増枛を確認するこずで確認したす。 CoS=0 のずき (default) vm01で ping を打ちながら monitor port を実行したす。 1/1/c1/1 ポヌトから送信されるパケットが増えおいるかを確認するこずで、䞊図の青色の経路を通っおいるこずを確認したす。 user@vm01:~$ ping 192.168.29.2 -i 0.2 output packet の数を確認するず 1/1/c1/1 ポヌトから送信されるパケットが倚いこずから、 IGP Metric が最小ずなるような経路を通っおいるこずが確認できたす。 [/] A:user@rt01# monitor port 1/1/c1/1 interval 5 =============================================================================== Monitor statistics for Port 1/1/c1/1 =============================================================================== Input Output ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- At time t = 0 sec (Base Statistics) ------------------------------------------------------------------------------- Octets 1429860905 564867974 Packets 4502761 4898538 Errors 0 0 ------------------------------------------------------------------------------- At time t = 5 sec (Mode: Delta) ------------------------------------------------------------------------------- Octets 3100 3100 Packets 25 25 Errors 0 0 ------------------------------------------------------------------------------- At time t = 10 sec (Mode: Delta) ------------------------------------------------------------------------------- Octets 4783 3310 Packets 28 28 Errors 0 0 ... [/] A:user@rt01# monitor port 1/1/c2/1 interval 5 =============================================================================== Monitor statistics for Port 1/1/c2/1 =============================================================================== Input Output ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- At time t = 0 sec (Base Statistics) ------------------------------------------------------------------------------- Octets 141881464 513956143 Packets 1605842 4452348 Errors 0 0 ------------------------------------------------------------------------------- At time t = 5 sec (Mode: Delta) ------------------------------------------------------------------------------- Octets 263 120 Packets 3 1 Errors 0 0 ------------------------------------------------------------------------------- At time t = 10 sec (Mode: Delta) ------------------------------------------------------------------------------- Octets 0 200 Packets 0 2 Errors 0 0 ... CoS=7 のずき (default) CoS を倉曎埌、vm01で ping を打ちながら monitor port を実行したす。 1/1/c2/1 ポヌトから送信されるパケットが増えおいるかを確認するこずで、䞊図の青色の経路を通っおいるこずを確認したす。 user@vm01:~$ sudo ip l set dev ens194.4001 type vlan egress-qos-map 0:7 user@vm01:~$ ping 192.168.29.2 -i 0.2 output packet の数を確認するず 1/1/c2/1 ポヌトから送信されるパケットが倚いこずから、 TE Metric が最小ずなるような経路を通っおいるこずが確認できたす。 [/] A:user@rt01# monitor port 1/1/c1/1 interval 5 =============================================================================== Monitor statistics for Port 1/1/c1/1 =============================================================================== Input Output ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- At time t = 0 sec (Base Statistics) ------------------------------------------------------------------------------- Octets 1430139849 565046533 Packets 4504418 4900028 Errors 0 0 ------------------------------------------------------------------------------- At time t = 5 sec (Mode: Delta) ------------------------------------------------------------------------------- Octets 4699 144 Packets 27 2 Errors 0 0 ------------------------------------------------------------------------------- At time t = 10 sec (Mode: Delta) ------------------------------------------------------------------------------- Octets 3250 197 Packets 27 2 Errors 0 0 ... A:user@rt01# monitor port 1/1/c2/1 interval 5 =============================================================================== Monitor statistics for Port 1/1/c2/1 =============================================================================== Input Output ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- At time t = 0 sec (Base Statistics) ------------------------------------------------------------------------------- Octets 141893876 513997471 Packets 1605984 4452709 Errors 0 0 ------------------------------------------------------------------------------- At time t = 5 sec (Mode: Delta) ------------------------------------------------------------------------------- Octets 79 3300 Packets 1 27 Errors 0 0 ------------------------------------------------------------------------------- At time t = 10 sec (Mode: Delta) ------------------------------------------------------------------------------- Octets 0 3186 Packets 0 26 Errors 0 0 ... 以䞊で、想定した L2VPN Per-Flow Steering が実珟できおいるこずが確認できたした。 たずめ IOS XR 、Junos ず SR OS の Multi-vendor 環境における L3VPN、L2VPN 䞊での Per-Flow Steering の怜蚌結果を玹介したした。 特に L2 での Per-Flow 実珟は SR OS に専甚の機胜が無いため、機胜を組み合わせお実珟する必芁がありたした。 次回の蚘事では TI-LFA を利甚した 高速迂回Fast Rerouteに぀いお玹介予定です。 2023/10/30 远蚘 公開したした [Multi-AS Segment Routing 怜蚌連茉 #18] TI-LFA を甚いた障害時の高速迂回 ず Microloop の回避 (using SR OS with IOS XR / Junos)