こんにちは、イノベーションセンターの加藤です。普段はコンピュータビジョンの技術開発やAI/機械学習（ML: Machine Learning）システムの検証に取り組んでいます。一方で、兼務で生成AIチームに参加し、大規模言語モデル（LLM: Large Language Model）に関する技術の調査を行なっています。 この記事では、日本語のコード生成のデータセットが無い条件下で、進化的モデルマージを活用することで日本語とソースコード生成に特化した大規模言語モデル(LLM)を合成した試みについて紹介します。 目次 目次 モデルマージとは 進化的モデルマージとは 利用したモデル 日本語LLM コード生成特化 MergeKitによる実験 利用モデル マージ用データセット JSQuAD CoNaLa 評価用データセット JCommonsenseQA HumanEval JHumanEval 実験結果 考察 JHumanEvalの回答に必要な日本語能力 CodeLlamaのマージ困難性 まとめ モデルマージとは 学習済みモデルの重みを組み合わせることで、元のモデルの持つ能力を組み合わせたり精度を向上させたりできる手法です。例えばベースモデルの重み に対し、さまざまなハイパーパラメータでファインチューニングした複数の派生モデルの重み があるとき、これらを平均した はmodel soupと呼ばれ元の派生モデルよりも性能が良くなり、かつ入力の変化にも頑健になると言われています 1 。 一方で、ベースとなるLLMの重み に対し数学の問題データでファインチューニングした派生モデル と、ソースコード生成のためのデータセットでファインチューニングした派生モデル があったとします。このとき、派生モデルの重みとベースモデルの重みの差分 はtask vectorと呼ばれ、ファインチューニングによって得られた新しい能力の重みと見なすことができ、これの和を取ることで数学とプログラミング両方に強い新たなLLMの重み を作ることができます。このような差分を線型結合するテクニックはtask arithmetic 2 と呼ばれ、足すだけでなく引くことで特定の性質（例えば攻撃性など）を取り除くという操作も可能とされています。 これらの手法は複数のモデルの出力を合成するアンサンブル手法とは違い、モデルのサイズが変化しないので推論速度が元のモデルから変化しないという利点があります。非線形操作を多量に含んでいるモデルの重みを単純に足し引きする操作は直観的に機能しなさそうですが、実験的にはうまくいく 3 ようで言語モデルや画像生成などさまざまな分野でいろいろなマージモデルが作成されています。 また、重みの合成方法についても単純な線形補間にとどまらないさまざまな手法が提案されています。今回の記事では、task vectorからランダムにパラメータを0にして残りのパラメータをスケーリングするDARE 4 という手法と、マージするパラメータの符号ができるだけ一致するようにいくつかのパラメータを0にするTIES 5 という手法を組み合わせたものを利用します。いずれの手法も、それぞれのtask vectorには能力の発現に実際に寄与するパラメータは少数であるという仮定をおき、そのようなパラメータがもう一方のtask vectorに乱されないように工夫をするというアプローチによって、より性能の良いマージモデルの作成を可能にしています。 進化的モデルマージとは モデルのパラメータを合成する際の重み付け係数やDAREなどにおける非ゼロの密度などは、マージ後の精度を左右する重要なハイパーパラメータです。このハイパーパラメータを探索するために進化的アルゴリズムを活用したのがSakana AIの提案した進化的モデルマージです 6 。この手法は指定されたデータセットの評価指標を最適化するようなパラメータを繰り返し探索するもので、データセット全体に対する評価を何度も実行する必要がある一方で勾配を必要としないという利点があります。Sakana AIが提案した手法はDAREとTIESを併用したマージ手法とCMA-ESと呼ばれる進化的アルゴリズムを組み合わせたもので、モデルマージの際に広く使われているライブラリであるmergekit 7 にも実装されています。この記事では、mergekitに実装された進化的モデルマージを用いて、日本語LLMモデルとコード生成モデルを合成してみました。 利用したモデル マージに利用したモデルを紹介します。モデルマージの制約上、全てのモデルは同じベースモデルから派生している必要があるため、今回はMeta社の基盤モデルであるLlama2 (70億パラメータ)をベースとした派生モデルを合成しました。利用モデルの派生関係は以下の図に示しています。 日本語LLM 日本語を理解できるLLMとして今回は ELYZA Japanese Llama Instruct 7B を利用しました。Llama2をベースに約180億トークンの日本語データセットで追加事前学習したモデルであり 8 、日本語に対する高い処理能力が期待できます。 コード生成特化 マージ用のモデルとして、大部分をソースコードが占める計5000億トークンのデータセットで追加学習し質問応答用にファインチューニングした CodeLlama Instruct と、ソースコードに関する質問応答データセットである Evolved CodeAlpaca を用いてLlama2をファインチューニングした Llama-2-7b-evolcodealpaca の2つを用意しました。 また、比較対象としてCodeLlama Instructに日本語データセットを追加事前学習させた ELYZA Japanese CodeLlama Instruct 7B を用意し、マージモデルがどれくらいこの追加事前学習モデルに匹敵するかを調査しました。 MergeKitによる実験 利用モデル mergekitに実装された進化的モデルマージを用いて、以下の組み合わせでモデルマージを行いました。 ELYZA Japanese Llama Instruct 7B + CodeLlama Instruct ELYZA Japanese Llama Instruct 7B + Llama-2-7b-evolcodealpaca マージモデルと元モデルとの関係は次の図のようになります。 マージ用データセット ハイパーパラメータ探索の際の評価用データセットは以下の2つを利用しました。 JSQuAD 日本語向けの言語理解ベンチマークJGLUE 9 の一部であり、質問応答データセットSQuADの日本語版です。日本語の文章読解能力を評価するために使用しました。回答は文章生成で行いますが、正しい形式で答えさせるために2つの例題をプロンプトに加えています。この工夫によって、LLMに「はい、お答えします。」のような無意味な回答をしないように誘導できます。 指標は exact_match を使いました。これはLLMの出力が想定回答と完全一致した場合に正解とみなすものです。 プロンプトと想定回答の例 入力 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 ### 指示: 与えられた文脈から、質問に対する答えを抜き出してください。 ### 入力: {例題1} ### 応答: {回答1} ### 指示: 与えられた文脈から、質問に対する答えを抜き出してください。 ### 入力: {例題2} ### 応答: {回答2} ### 指示: 与えられた文脈から、質問に対する答えを抜き出してください。 ### 入力: 文脈：梅雨（つゆ、ばいう）は、北海道と小笠原諸島を除く日本、朝鮮半島南部、中国の南部から長江流域にかけての沿海部、および台湾など、東アジアの広範囲においてみられる特有の気象現象で、5月から7月にかけて来る曇りや雨の多い期間のこと。雨季の一種である。 質問：日本で梅雨がないのは北海道とどこか。 ### 応答: 出力 小笠原諸島 CoNaLa CoNaLa 10 はStack Overflowから収集されたプログラミング言語のデータセットであり、質問文と短いPythonプログラムのペアからできています。ソースコード生成の能力を評価するためにこれを利用しました。こちらも2つの例題をプロンプトに加えています。 指標はBLEU 11 が使われます。 プロンプトと想定回答の例 入力 Answer the following instructions in one line of Python code: Instruction: {例題1} Solution: {回答1} Instruction: {例題2} Solution: {回答2} Instruction: send a signal `signal.SIGUSR1` to the current process Solution: 出力 os.kill(os.getpid(), signal.SIGUSR1) 評価用データセット マージ後のモデルの性能を測るために、上記のデータセットに加えて、以下の日本語データセットとプログラミング言語データセットを利用しました。 JCommonsenseQA JSQuADと同様に日本語向けの言語理解ベンチマークJGLUEの一部であり、常識を問うタスクCommonsenseQAの日本語版です。日本語の文章読解能力を評価するためにJSQuADと共に使用しました。3つの例題をプロンプトに加え、選択式で答えさせています。指標は accuracy を使いました。 入出力例 入力 以下は、タスクを説明する指示と、文脈のある入力の組み合わせです。要求を適切に満たす応答を書きなさい。 ### 指示: 与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください： {選択リスト1} ### 入力: {例題1} ### 応答: {回答1} ### 指示: 与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください： {選択リスト2} ### 入力: {例題2} ### 応答: {回答2} ### 指示: 与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください： {選択リスト3} ### 入力: {例題3} ### 応答: {回答3} ### 指示: 与えられた選択肢の中から、最適な答えを選んでください。出力は以下から選択してください： - 掲示板 - パソコン - マザーボード - ハードディスク - まな板 ### 入力: 電子機器で使用される最も主要な電子回路基板の事をなんと言う？ ### 応答: 出力 マザーボード HumanEval HumanEval 12 は関数名とそのドキュメント（説明文）から内部のPython実装を生成させるデータセットです。一般的な文書生成の評価手法とは異なり、実際に実装を動作させてテストが通るかどうかで生成結果を評価しています。変数名が正解と異なっていてもプログラムが正しければ正解とみなされるため、より実用に向いた評価指標といえます。また、人手で作成されたため、少量ながら高品質なデータであることも特徴です。 指標は pass@k が使われ、LLMが 個の答えを生成し1つでも合っていれば正解とみなします。 入出力例 入力 from typing import List def has_close_elements (numbers: List[ float ], threshold: float ) -> bool : """ Check if in given list of numbers, are any two numbers closer to each other than given threshold. >>> has_close_elements([ 1.0 , 2.0 , 3.0 ], 0.5 ) False >>> has_close_elements([ 1.0 , 2.8 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.3 ) True """ 出力 for idx, elem in enumerate (numbers): for idx2, elem2 in enumerate (numbers): if idx != idx2: distance = abs (elem - elem2) if distance < threshold: return True return False テスト def check (candidate): assert candidate([ 1.0 , 2.0 , 3.9 , 4.0 , 5.0 , 2.2 ], 0.3 ) == True assert candidate([ 1.0 , 2.0 , 3.9 , 4.0 , 5.0 , 2.2 ], 0.05 ) == False assert candidate([ 1.0 , 2.0 , 5.9 , 4.0 , 5.0 ], 0.95 ) == True assert candidate([ 1.0 , 2.0 , 5.9 , 4.0 , 5.0 ], 0.8 ) == False assert candidate([ 1.0 , 2.0 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.1 ) == True assert candidate([ 1.1 , 2.2 , 3.1 , 4.1 , 5.1 ], 1.0 ) == True assert candidate([ 1.1 , 2.2 , 3.1 , 4.1 , 5.1 ], 0.5 ) == False JHumanEval JHumanEval 13 はHumanEvalのドキュメント部分を日本語化したもので、日本語を理解しかつソースコードを生成する能力を測ることができます。 入力例 from typing import List def has_close_elements (numbers: List[ float ], threshold: float ) -> bool : """リストnumbersの中に、与えられたthresholdより近い２つの数値が存在するか判定する >>> has_close_elements([ 1.0 , 2.0 , 3.0 ], 0.5 ) False >>> has_close_elements([ 1.0 , 2.8 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.3 ) True """ 実験結果 マージ前、マージ後、比較用モデルそれぞれの評価結果は次のようになりました。 model JSQuAD (2shot, exact match) JCommonsenseQA (3shot) CoNaLa (2shot, bleu) HumanEval (pass@1) JHumanEval (pass@1) (J) ELYZA Japanese Llama Instruct 0.6673 0.7194 0.2743 0.1280 0.0976 (C1) CodeLlama Instruct 0.6855 0.6452 0.3582 0.3293 0.2744 (C2) Llama-2-7b-evolcodealpaca 0.6171 0.58 0.2435 0.3354 0.2683 --- --- --- --- --- --- ELYZA Japanese CodeLlama Instruct 0.6828 0.7373 0.3358 0.3232 0.2378 --- --- --- --- --- --- J + C1 0.3165 0.5505 0.2236 0.0732 0.0610 J + C2 0.6517 0.7051 0.2412 0.3415 0.2134 作成した2つのマージモデルのうち、Llama-2-7b-evolcodealpacaを用いた方(J + C2)は日本語能力(JSQuAD,JCommonsenseQA)を保ったままコード生成の性能を元の日本語LLMから向上させることができ、追加事前学習を行なったELYZA Japanese CodeLlama Instructとほぼ同等のHumanEval, JHumanEval性能を持たせることができました。 考察 JHumanEvalの回答に必要な日本語能力 結果を見ると、JHumanEvalの性能はJSQuADやJCommonsenseQAよりもHumanEvalの性能に相関しているようです。関数ドキュメント程度の文章量ではあまり読解能力や常識を必要としなくてもうまくコード生成ができるようです。HumanEvalでは網羅できないような、長く複雑な仕様文書からのコード生成能力を測る必要がありそうです。 CodeLlamaのマージ困難性 日本語LLMとCodeLLamaをマージすると（J + C1）全ての性能が大きく劣化してしまいました。DAREの論文でも挙げられている通りCodeLlamaは追加学習量が多く、ベースモデルからパラメータが大きくずれているためか上手くマージできないようです。この問題は進化的アルゴリズムによるハイパーパラメータ探索でも解決が難しそうだということがわかりました。 まとめ 進化的モデルマージを利用して日本語LLMとコード生成LLMを合成し、両方の能力を獲得できるか実験しました。結果として、日本語のタスクとコード生成のタスクの両方で性能の良いモデルは作成できたものの、日本語からソースコードを生成するというタスクは設計が難しそうなこと、ベースラインからの差分が大きな派生モデルはハイパラ探索を活用してもマージ困難であることがわかりました。 Model soups: averaging weights of multiple fine-tuned models improves accuracy without increasing inference time. https://arxiv.org/abs/2203.05482 ↩ Editing Models with Task Arithmetic. https://arxiv.org/abs/2212.04089 ↩ モデルマージの理論的な背景について研究している論文に次のようなものがあります。 Task Arithmetic in the Tangent Space: Improved Editing of Pre-Trained Models. https://arxiv.org/abs/2305.12827 ↩ Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch. https://arxiv.org/abs/2311.03099 ↩ TIES-Merging: Resolving Interference When Merging Models. https://arxiv.org/abs/2306.01708 ↩ https://sakana.ai/evolutionary-model-merge-jp/ ↩ https://github.com/arcee-ai/mergekit ↩ https://note.com/elyza/n/na405acaca130 ↩ https://techblog.yahoo.co.jp/entry/2022122030379907/ ↩ https://conala-corpus.github.io ↩ https://huggingface.co/spaces/evaluate-metric/bleu ↩ Evaluating Large Language Models Trained on Code. https://arxiv.org/abs/2107.03374v2 ↩ https://huggingface.co/datasets/kogi-jwu/jhumaneval ↩

はじめに こんにちは、イノベーションセンターの真崎です。 6月にDatabricksの年次カンファレンス Data+AI Summit 2024 が開催され、 AI/BI Genie というDatabricks上のデータを自然言語で検索・分析・可視化できる機能が発表されました。 本記事では、AI/BI Genieについて機能の概要、及び実際に使用した流れを解説します。 Databricksとは Databricksはデータウェアハウスとデータレイクの両方の強みを兼ね備えたデータとAIのためのオープンな統合プラットフォーム「 データ・インテリジェンス・プラットフォーム 」を提供しています。 AI/BI Genieとは AI/BI Genieとは、Databricks上の構造化データに対して自然言語を用いて検索、分析、可視化を行うことができる機能です。 Databricksでユーザーが特定のデータにアクセスして分析したい場合、従来はPythonなどのプログラミング言語やSQLを用いてデータを抽出する必要がありました。 しかし、AI/BI Genieの登場により自然言語を用いて対話的にデータを抽出して分析できるようになりました。 AI/BI Genieの構成要素 ここでは、AI/BI Genieの構成要素であるGenieスペース、及びGenieチャットの概要について解説します。 Databricksのコンソール上で、AI/BI GenieはGenie>Genieスペース>Genieチャットという構造になっています。 Genie、Genieスペース、Genieチャットの役割は以下のようになっています。 Genie Genieスペースを管理する画面 Genieスペース チャットのまとまり Databricksの計算リソースであるクラスター設定やテーブル設定も管理できる チャット Genieと会話するためのインターフェース 会話の履歴はGenieスペース内のチャットごとに管理される Genieスペースでは以下の設定を管理できます。 Title スペースの名前 Description スペースの説明 Default warehouse スペースで使用するクラスター Tables スペースで検索・分析・可視化の対象とするテーブル Sample Question チャットUI上で、質問可能な内容の例を表示する AI/BI Genieの設定方法については 公式ドキュメント を参照してください。 Genieと会話してみる ここでは、AI/BI Genieに対して実際に自然言語でデータの取得を依頼して意図したデータを適切に取得できるか、実際にAI/BI Genieを使用して確認します。 やりたいこと Databricks内のデータから、誰がどのくらいDatabricksにアクセスしているかについて、該当のデータを持つテーブルを検索・集計・可視化する。 アプローチ システムテーブル( system.access.audit  ) は監査ログに関するテーブルとして設計されており、ユーザーアクセスに関するイベントを記録しています。 そのため、今回のアクセス解析はこのテーブルを集計することで実現可能です。 そこで以降では、AI/BI Genieがシステムテーブル( system.access.audit )を使用して正しく集計・可視化できるかを確認します。 ※本記事で扱う システムテーブル は、事前に有効化しておく必要があります。 Genieスペースの作成 まず、 Genieスペースの設定項目 を設定し、Genieスペースを作成します。 AI/BI Genieはユーザーの質問に対してTablesで選んだテーブルを基に情報を検索するので、事前に該当しそうなテーブルを検索対象に入れておきます。 今回はシステムによる自動作成のログテーブルを検索対象にしたいので system.access 配下のテーブルにチェックを入れます。 データ検索 続いて、Genieスペースが作成できると自動でチャットUIに遷移するのでこの画面で会話を始めます。AI/BI Genieに問い合わせをするには画面下部のチャットボックスに質問文を入力します。 まず、目的のデータの集計が行えるテーブルがあるかを自然言語で問い合わせます。 system.access.audit  テーブルからアクセス回数を集計できるということなので、 system.access.audit  テーブルのデータがどういったものか尋ねます。 AI/BI Genieによると、 system.access.audit  テーブルはDatabricks ワークスペース内でのユーザー行動に関する監査ログであるということであり、公式ドキュメントのテーブル定義と合致するため正しい分析設計ができていることが分かりました。 データ集計 これまでと同様に自然言語でAI/BI Genieにユーザーごとのログの集計を依頼をすると、AI/BI Genieが生成したSQL文が実行され、集計結果がインターフェースに表示されます。 なお、AI/BI Genieが実行したSQL文はAI/BI Genieの回答に添付されています。 データ可視化 最後に、AI/BI Genieに上記のカウント結果を円グラフで可視化してもらいました。 AI/BI Genieに関するTips グラフの可視化にはVega-Liteが利用可能 AI/BI Genieが可視化に使うツールは Vega-Lite がデフォルトとなっていますが、matplotlibやseabornなど別のライブラリも使えるかを確認してみます。 AI/BI Genieにpythonのseabornライブラリを用いた可視化を依頼しましたが、AI/BI GenieからはVega-Liteを用いた可視化のみ可能と返ってきました。 実際にAI/BI Genieが可視化したデータを見ると全てのグラフがVega-Liteが対応するjson形式で描画されています。 円グラフ描画時の注意点 AI/BI Genieが生成した円グラフは、デフォルトでは件数順にソートされません。 そのため、AI/BI Genieが理解できるようにソートを指示する必要があります。 以下では未ソートの円グラフとソートされた円グラフの作成方法をそれぞれ見ていきます。 デフォルトの円グラフ（未ソート） まず、AI/BI Genieに詳細を指定せず円グラフを描いてもらうと、件数順のソートなどはされないまま円グラフが可視化されます。 ソートされた円グラフ 件数順のソートができていない旨を指摘すると、AI/BI Genieがコードの問題点をセルフレビューし、新たな円グラフの作成コードを提案します。 ここでAI/BI Genieに対して再度可視化を依頼すると、AI/BI Genieによりソートされた円グラフが可視化されます。 AI/BI Genieへの可視化の依頼方法を工夫することで、ソートされた円グラフを作成できました。 なお、棒グラフや折れ線グラフについては特に質問の仕方を工夫せずとも件数ソートができます。 まとめ 本記事では以下の2点について解説をしました。 AI/BI Genieの概要 AI/BI Genieを用いたデータ検索・集計・可視化 AI/BI GenieはDatabricks上のデータを自然言語で検索・分析・可視化できるDatabricksのサービスです。AI/BI Genieの登場によりDatabricksでのデータ活用がプログラミングを使えないビジネス現場レベルまで浸透することが予想されます。

本記事では6月に開催された DATA+AI Summit 2024 でGeneral Availabilityが発表された Databricks のDeltaLake Universal Formatの機能を使ってクロスプラットフォームでの分析を実現する方法について紹介します。 DeltaLake Universal FormatはDeltaLakeに保存されたデータをApache Icebergなどの異なるフォーマットで読み出すことができるようにする機能です。本記事では実際にDatabricks上でDeltaLake Universal Formatの機能を有効にしたテーブルを作成し、 Amazon Athena からApache Iceberg形式でクエリを発行するサンプルを用いて、機能の使い方と本機能のメリットについて解説します。 目次 目次 はじめに データレイクとOpen Table Format (OTF) Databricks DeltaLake Universal Format DeltaLake Universal Formatを利用したクロスプラットフォームでの分析 DeltaLake Universal Format対応テーブルの作成 DeltaLake Universal Format(Iceberg互換) Tableの確認 Amazon Athenaの設定 Amazon Athenaからのクエリの発行 まとめ 参考文献 はじめに こんにちは、NTTコミュニケーションズの露崎です。 本記事では6月に開催された DATA+AI Summit 2024 でGeneral Availabilityが発表された Databricks のDeltaLake Universal Formatの機能を使ってクロスプラットフォームでの分析を実現する方法について紹介します。 データレイクとOpen Table Format (OTF) DeltaLake Universal Formatを解説するにあたり、前提となるデータレイクとOpen Table Formatについて説明します。 データレイクは構造化データ、非構造化データを扱うことのできる一元的なリポジトリです。データレイクでは未加工かつ多様なデータを格納するため、データを分析するためにはデータベースやデータウェアハウスのような構造化されたデータとして取り扱う必要があります。 Open Table Format (OTF) はこうしたデータレイク上に構造化されたテーブル形式を表現するためのフォーマットであり、ACIDトランザクションなどデータベースで取り扱う操作をデータレイク上のデータに対して実現します。 DeltaLake や Apache Iceberg 、 Apache Hudi は、OTFを提供するOSSのソフトウェアです。SparkやTrinoといったOSS分散処理ソフトウェアはこれらのOTFの機能を通してデータレイク上のデータにテーブル形式でアクセスできます。 従来、これらのOTFはそれぞれのOSSコミュニティで開発されており、分析プラットフォーム毎に対応するフォーマットが異なるため、特定のプラットフォームにロックインされるという課題がありました。 Databricks Databricksはデータウェアハウスとデータレイクの両方の強みを兼ね備えたデータとAIのためのオープンな統合プラットフォーム「データ・インテリジェンス・プラットフォーム」を提供しています。Databricksではデータレイクのテーブルフォーマットとして DeltaLake をサポートしていましたが、こうした互換性の問題を解決する DeltaLake Universal Format 機能のGeneral Availability (GA)を2024年6月のDATA+AI Summitにて発表しました。 DeltaLake Universal Format 引用元: https://www.databricks.com/jp/blog/announcing-delta-lake-30-new-universal-format-and-liquid-clustering DeltaLake Universal FormatはDeltaLakeのフォーマットで保存されたデータをApache Iceberg形式、Apache Hudi形式で読み出すことを可能とするDeltaLakeの機能です。DeltaLake Universal FormatはDeltaLake、Apache Iceberg、Apache Hudiのいずれのテーブルフォーマットも実データは Apache Paruquet 形式で保存されていることを利用し、DeltaLakeへ書き込まれたデータのテーブルフォーマットに関するメタデータをそれぞれのテーブルフォーマットに変換することで異なるテーブルフォーマットでの読み取りをサポートします。 より具体的な利用イメージを掴んで頂くために、以降では実際にDatabricks上でDeltaLake Universal Formatの機能を有効にしたテーブルを作成し、異なるプラットフォームであるAmazon AthenaからApache Iceberg形式でクエリを発行する方法について解説します。 DeltaLake Universal Formatを利用したクロスプラットフォームでの分析 ここではAzure Databricks上に構築したDeltaLake Universal Format対応テーブルをAmazon Athenaで分析するための設定を行なっていきます。 DeltaLake Universal Format対応テーブルの作成 まず、DeltaLake Universal Formatの機能を有効にするためには、テーブルを作成する際に delta.enableIcebergCompatV2 , delta.universalFormat.enabledFormats の2つのプロパティを設定します。 以下は、 uniform_test というカタログに nyctaxi というスキーマを作り、 trips というテーブルを作成するSQLで、DatabrciksのSQL Editorから実行可能です。 SQLの実行にはDeltaLake Universal Formatが利用可能なDatabricks Runtime 14.3LTS以降のRuntimeを使用します。 1 今回はAmazon AthenaからSpark、Iceberg形式で読み取るため、 delta.universalFormat.enabledFormats に iceberg を設定します。 また、このSQLでは Databricksのワークスペースがデフォルトで提供しているNewYorkのタクシーの運転履歴のデータサンプル を実データとしてこのテーブルに入れています。 CREATE CATALOG IF NOT EXISTS uniform_test; -- create test catalog USE CATALOG uniform_test; CREATE SCHEMA IF NOT EXISTS nyctaxi; -- create test schema CREATE TABLE uniform_test.nyctaxi.trips TBLPROPERTIES( ' delta.enableIcebergCompatV2 ' = ' true ' , -- enable iceberg convert ' delta.universalFormat.enabledFormats ' = ' iceberg ' , -- enable iceberg convert ) AS SELECT * FROM samples.nyctaxi.trips; DeltaLake Universal Format(Iceberg互換) Tableの確認 DeltaLake Universal Formatを作成後、機能が有効になっているかどうかを以下のSQLで確認します。 DESCRIBE EXTENDED uniform_test.nyctaxi.trips; このSQLを実行すると nyctax.trips テーブルの情報が表示されます。以下は実行結果の一部抜粋で、このように Converted delta version 、 Converted delta timestamp が表示されていれば、すでにIceberg形式のメタデータが作成されIcebergテーブルとして読み出し可能な状態になっています。 Amazon Athenaの設定 次にAmazon Athenaでこのテーブルを読み出すための設定をします。設定はAthenaのNotebook EditorからEdit Sessionを選択し、セッションのプロパティを設定します。 プロパティには以下を設定します。設定値については検証時の値のためパッケージバージョン等については利用環境に合わせて変更してください。 公式ドキュメント ではIceberg形式でのメタデータ読み取りに必要なプロパティが紹介されていますが、ここでは参照したメタデータから実際のデータの読み取るためにAzure DataLake Storageのアクセスキーも設定していることに注意してください。 Key Value 備考 spark.jars.packages org.apache.hadoop:hadoop-azure:3.2.1 athenaのpyspark versionが3.2.1のためmaven の3.2.1を指定 spark.sql.catalog.spark_catalog org.apache.iceberg.spark.SparkSessionCatalog spark.sql.catalog.spark_catalog.io-impl org.apache.iceberg.aws.s3.S3FileIO azure adlsでもS3FileIOを指定 spark.sql.catalog.unity org.apache.iceberg.spark.SparkCatalog spark.sql.catalog.unity.catalog-impl org.apache.iceberg.rest.RESTCatalog spark.sql.catalog.unity.token <databricksのpersonal access token> 設定方法 spark.sql.catalog.unity.uri <databricksのapi root>/api/2.1/unity-catalog/iceberg iceberg catalogのAPIエンドポイント spark.sql.extensions org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions spark.hadoop.fs.azure.account.key.datalakedatabricksus.dfs.core.windows.net <ADLSのaccess key> OAuth等での設定等は こちら Amazon Athenaからのクエリの発行 Sparkのプロパティ設定が完了すれば、以下のようにAthenaから直接DeltaLake Universal FormatテーブルのデータにSQLを発行できるようになります。SQLを発行する対象のカタログは unity という接頭辞をつけた unity.uniform_test.nyctax.trips という指定形式になります。 catalog_name = "unity.uniform_test.nyctaxi.trips" result = spark.sql(f"SELECT * FROM {catalog_name}") print(result) result.show() まとめ 本記事ではDeltaLake Universal Formatの機能を使ってDatabricksのUnity Catalog上のデータをAmazon Athenaで分析する方法について紹介しました。 このようにDeltaLake Universal Formatを使うと、利用したいプラットフォームへ事前にデータを移動することなく、直接データを参照し分析することが可能になります。こうしたオープンテーブルフォーマットの機能を利用することで、ユーザー側のプラットフォームの選択肢が広がり、より多くのユースケースへ適応できるようになると考えられます。 参考文献 https://www.databricks.com/ https://aws.amazon.com/jp/athena/ https://learn.microsoft.com/ja-jp/azure/databricks/delta/uniform https://docs.delta.io/latest/delta-uniform.html ↩

みなさんこんにちは、イノベーションセンターの益本 (@masaomi346) です。 Network Analytics for Security (以下、NA4Sec) プロジェクトのメンバーとして、脅威インテリジェンス(潜在的な脅威について収集・分析したデータ)の分析をしています。 この記事では、2024年7月20日に開催されたセキュリティカンファレンスHack Fes. 2024にて、登壇したきたことについて紹介します。 ぜひ最後まで読んでみてください。 Hack Fes.について Hack Fes.は、日本ハッカー協会が主催するセキュリティカンファレンスです。 専門知識やスキルを学ぶだけでなく、参加者同士が直接交流できる機会を提供することを目的に開催されています。 堅苦しいイベントではなく、多くの人が集まることで生まれる「ワクワク感」や「楽しさ」を共有し、参加者とともに「お祭り」を作り上げていくことを目指しているセキュリティカンファレンスです。 講演以外にもさまざまなコンテンツが提供されています。 たとえば、協賛企業主催のCTFやステッカーや技術書の交換会が開催されています。 昨年から開催されており、今年で2回目の開催となります。 Hack.Fes2024のタイムテーブルが決まりました！主催のため、代表の杉浦も全ての講演を聴講できないことを心から悔しがっている（実話）ほどの豪華なラインナップとなっております！皆様のお越しをお待ちしております！ https://t.co/SV5ds1YseD — 一般社団法人日本ハッカー協会 (@JapanhackerA) 2024年6月27日 NA4Secについて NA4Secは、「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指した活動をしているプロジェクトです。 NTT Comグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズ（以下、NFLabs.）からもメンバーが参画し、日夜攻撃インフラを追跡しています。 NA4Secの最近の活動については、以下の記事をご覧ください。 フィッシングキットから生成されたサイトの調査 (インターンシップ体験記) 社内で検知された悪性通信を調査したらドメインパーキングだった話 Hack Fes. 2024で登壇した講演について 本イベントにおいて、私は、「ブラウザ通知スパムで見る、悪意あるコンテンツが表示される仕組み」というテーマで登壇させていただきました。 インターネットにはマルウェア配布サイトや詐欺サイトなどの悪意あるコンテンツが展開されています。 本講演では、ブラウザ通知スパムを例にしてどのような仕組みで悪意あるコンテンツが表示されているのか、実例を挙げて紹介しました。 攻撃者が用意した誘導コンテンツで誘導している例の紹介 Webサイトを改竄して誘導している例の紹介 トラフィック配信システムでどのようなことが行われているのか ブラウザ通知スパムが主役となっており、かなりマニアックなネタとなっています。 ネタがネタなので、他のトラックに人が流れてしまわないか心配でしたが、見に来て下さった人がたくさんいて安心しました。 講演する前は少し不安もありましたが、思っていたよりもポジティブな反応をもらえたので、講演して良かったと思いました。 【一言講演紹介】『ブラウザ通知スパムで見る、悪意あるコンテンツが表示される仕組み』～益本 将臣氏　本講演では、悪意あるコンテンツの1つであるブラウザ通知スパムを例にして、攻撃者がどのように被害者を誘導しようとしているのかについて説明する。 https://t.co/SV5ds1Z04b 　 #hackfes2024 — 一般社団法人日本ハッカー協会 (@JapanhackerA) 2024年6月30日 さいごに 私自身、登壇した経験はあまりありませんが、今回の登壇はそこまで緊張しませんでした。 Hack Fes.というワイワイとした場の雰囲気の影響があるのかもしれません。 JSACに登壇したときもそうでしたが、聴講者として参加するのと講演者として参加するのとでは、味わう雰囲気が違うと感じました。 今後も引き続き、外部登壇を通じてセキュリティ業界を盛り上げていければと考えています。 宣伝その1 2024年8月6日・7日に、ラスベガスでBSides Las Vegasが開催されます。 NA4Secからは、以下のテーマで登壇します。 Operation So-seki: You Are a Threat Actor. As Yet You Have No Name. JSAC2024でも登壇したネタであり、あるハクティビストを追跡した内容となっています。 YouTubeでライブ配信されますので、現地に行かなくても視聴できます。 興味がある方は、ライブ配信を視聴してみてください。 ／ イベント登壇情報✨ ＼ ​ ラスベガスで開催されるセキュリティカンファレンス @BsidesLV にて、NTT ComとNFLabs.の社員が登壇🙋 ​ 詳細はこちら⬇ https://t.co/CotWhfcpy1 ​ #ドコモビジネス — ドコモビジネス｜NTTコミュニケーションズ (@NTTCom_online) 2024年7月16日 宣伝その2 2024年9月13日・14日に、名古屋でセキュリティ・ミニキャンプ in 愛知 2024が開催されます。 9月14日の専門講座にて、益本が以下の講義の講師を担当させていただきます。 Phishing Analysis ～ フィッシングサイトの仕組みを学ぶ フィッシング詐欺を取り扱っている内容となっています。 今年の夏の思い出作りに、参加してみてはいかがでしょうか。 セキュリティに興味がある学生のご応募お待ちしております。 2024年9月14日(土) 「セキュリティ・ミニキャンプ in 愛知 2024」専門講座 開催！ 📢学生参加者を募集いたします！ 参加費無料！ ✨申込締切：2024年8月12日（月）16:00まで 情報セキュリティに興味のある学生の皆様のご応募お待ちしています！ #seccamp https://t.co/nYWYQAffx2 — セキュリティ・キャンプ (@security_camp) 2024年7月10日

Hewlett Packard Enterprise (HPE) が主催する最大のテクノロジーカンファレンス、 HPE Discover 2024 が 2024年6月17日から20日に米国ラスベガスで開催されました。 この記事では HPE Discover 2024 に聴講参加して得られた知見について、主にサーバー関係のものを中心に共有します。 はじめに HPE Discover 2024 とは Keynote: Intelligence has no limits 新サーバーの発表 AI 向けサーバー サービスプロバイダー向けのサーバー 興味深かったセッション The future of liquid cooling for data centers Transforming management with Open Source Firmware for SPs Showcase 交流イベント Japan Session おわりに はじめに こんにちは、クラウド&ネットワークサービス部の 福岡 です。 普段は SDPF（Smart Data Platform）クラウドの IaaS である、 ベアメタルサーバー ・ ハイパーバイザーサービス 開発のソフトウェアエンジニアをしています。 今回、これらのサービスの継続提供にあたりサーバー周りのトレンドや動向を把握するために、HPE Discover 2024 に参加しました。 HPE Discover 2024 とは HPE Discover は HPE が年に一度主催する最大のテクノロジーカンファレンスであり、HPE が目指していくビジョンや新サービス、新製品の発表が行われる舞台です。 世界各国から HPE のテクノロジーに興味を持つ多くの参加者が集うことで知られており、今年は日本からも100名以上が参加しました。 会場も並大抵の広さではなく、今年は 11.5万平方メートル（東京ドーム2個分以上）の展示面積を持つ、米国ラスベガスの The Venetian Expo & Convention Center で開催されました。 日本からの参加者の基本的なタイムスケジュール プログラムは 「エッジ」「ハイブリッド・クラウド」「AI」 の 3つのトピック分野を中心に組まれており、300以上のセッション（講演）とデモが提供されました。 セッションはいくつかの種類に分かれており、大部屋で開催される General Session、Spotlight Session では、各分野のリーダーによるトレンド、パートナーシップ、イノベーションについての紹介が行われます。 一方、比較的小さい部屋で開催される Breakout Session では、個別的な製品紹介、事例紹介、ベストプラクティスの共有などが行われます。 Keynote: Intelligence has no limits HPE CEO の Antonio Neri による keynote の内容は、驚くほど AI に関連することが数多く取り上げられていました。 講演では HPE 社製の GPU サーバーを使用したさまざまな産業界の事例紹介をはじめとして、AI によって企業の生産性を向上させ、イノベーションを加速することの重要性が語られました。 講演の後半には NVIDIA CEO の Jensen Huang が登場して、HPE と NVIDIA とのパートナーシップを強化していく旨が述べられ、HPE Private Cloud AI という新しいソリューションの発表がありました。 なお、今年の keynote は昨年にオープンしたばかりの巨大映像施設 Sphere で開催されたのですが、映像のあまりの解像度の高さと迫力に圧倒されっぱなしでした。 Keynote の内容は YouTube に公開されているので、興味ある方はご覧ください。 新サーバーの発表 期間中には新しい HPE ProLiant シリーズのサーバーが4種類発表されました。 そのうち 2種類が AI 向け、残りの2種類がサービスプロバイダー向けです。 AI 向けサーバー HPE ProLiant Compute DL380a Gen12 は、最新の GPU NVIDIA H200 を搭載した初のサーバーです。 NVIDIA H200 は前のモデルの NVIDIA H100 と比較して、メモリサイズが2倍、バンド幅が 1.4 倍と性能が向上したモデルです。 このサーバは 4U の筐体に最大で 8個の NVIDIA H200 GPU を搭載可能であり、GPU 同士は 2-way または 4-way の高速インターコネクト NVLink による接続が可能となっています。 HPE ProLiant Compute DL384 Gen12 は、 Grace Hopper として知られる NVIDIA GH200 チップを搭載した初のサーバーとなります。 NVIDIA GH200 は Arm アーキテクチャの NVIDIA Grace CPU と NVIDIA Hopper アーキテクチャの GPU が密結合している画期的なモデルであり、CPU と GPU 間で共有された大規模なメモリ空間を提供します。 サービスプロバイダー向けのサーバー Accelerate your AI journey with HPE Compute より HPE ProLiant DL320 Gen12 SP と HPE ProLiant DL340 Gen12 SP は、電力あたりのパフォーマンス効率の高さが特徴としていて、 Sierra Forest と呼ばれる最新のサーバー/データセンター向けの CPU、Xeon 6 プロセッサを搭載した初のサーバーです。 Sierra Forest は Xeon 6 プロセッサーのうち、電力効率の高い Eコア (Efficient Core) を採用したモデルであり、1つのダイあたり最大 144個もの CPU コアを搭載しながら、既存のチップと比較して同程度の消費電力を実現すると期待されています。 DL320 と DL340 の違いは筐体のサイズであり、前者は 1U サーバー、後者は 2U サーバーとして提供されます。 興味深かったセッション 個人的に興味深かったセッションの内容を紹介します。 The future of liquid cooling for data centers (Speaker: Jason Zeiler) 1つめは冷却技術に関するセッションです (動画は こちら ) 。 昨今の CPU、GPU は高性能化に伴い発熱量が増加しているため、効率的に冷却することが求められています。 これまでの冷却方式は、ファンを使った空冷方式が主流でしたが、最近では空気よりも熱伝導率の高い液体を用いて熱を取り除く 液冷方式 が注目を集めています。 液冷方式は、空冷方式と比較して冷却能力が高く、ムラのない速やかな冷却を実現するため、高い密度でサーバーを配置したサーバーラックの冷却にも対応できるようになります。 また、電力効率が高く少ない電力で冷却が可能であるため、二酸化炭素の排出量の削減に貢献します。 さらに、冷却ファンの使用を最小限に抑えられるため、静音性が高いこともメリットです。 この講演では、液冷方式の例がいくつか紹介されました。 HPE RDHX , HPE ARCS は従来の冷却方式であり、巡回する冷却水がラック内の空気を冷却し、その冷却された空気がパーツを冷却する方式です。 一方、最新の方式の Direct liquid cooling (DLC) は、冷却プレートを使用して直接パーツを冷却する方式であり、冷却能力、効率ともに従来の方式を上回ります。 DLC は従来の方式と組み合わせて使用することもできますが、特に 100% の冷却を DLC のみで行なっている HPE Cray EX2500/EX4000 シリーズは HPE Discover 2024 の目玉であり、展示会場にも目立って展示されていました。 Showcase にて展示されていた HPE Cray EX4000 Transforming management with Open Source Firmware for SPs (Speaker: Damien Lagneux, Richard McQuaide, and Jean-Marie Verdun) 2つめは BMC (Baseboard Management Controller) に関する発展的な内容のセッションです。 馴染みのない方も多いかもしれませんが、BMC は遠隔で筐体の電源操作やハードウェアの状態を監視するための規格であり 、我々の開発しているベアメタルサービスの中核を担う技術です。 BMC は各ベンダーによって乱立しており、有名どころでいうと HPE 社製の iLO、Dell 社製の iDRAC、Fujitsu 社製の iRMC などがあります。それぞれが独自の機能とインターフェースを持ち、ベンダー間で必ずしも互換性が担保されているとは限りません。また、中身がブラックボックスでデバッグが難しく、古い筐体でベンダーがサポートを終了するとセキュリティ的に脆弱になるという課題もあります。 これらの課題を解決するため、最近 OpenBMC という Linux ベースのオープンソースの BMC 実装が提唱されています。 OpenBMC は標準化されたインターフェースを提供しており、オープンソースであることからベンダーに依存することなく、容易にカスタマイズやデバッグ、およびセキュリティ更新を実施できます。 ただし、現状 OpenBMC は初期状態の筐体にはインストールされていないため、後から OpenBMC をインストールしてパッケージを最新にアップデートする作業が必要になります 1 。 この講演では、このような筐体が数多く存在する環境でも、即座に最新の OpenBMC を使用できるように、OpenBMC を iSCSI デバイスからネットワークベースで立ち上げる方法が紹介されました。 後日発表者の Jean-Marie Verdun 氏とお話しする機会がありましたが、「OpenBMC は尖った技術だから好き嫌い分かれるだろうけど、とにかく試してみてほしい」と言われたのを覚えています。 興味を持たれた方は、関連動画 remote booting BMC: an OpenBMC / iSCSI example を参照してみてください。 Showcase HPE Discover 2024のショーケースの充実ぶりは凄まじく、数万平方メートルの展示空間に多くの企業が製品の実機展示やデモを行っていました。 製品やサービスに関する専門家からインタラクティブに説明を受けられるのが個人的に楽しかったので、セッションの合間を見繕って度々足を運びました。 軽食やドリンクコーナーも至るところにあり、非常に快適な空間でした。 Showcaseでは ガイドツアー も充実しており、英語だけでなく日本語、スペイン語、ポルトガル語など、複数の言語で一日に複数回開催されていました。 ガイドツアーの内容はほとんどがAIに関するもので、自動車の生産工場のオペレーションをAIで効率化する動画を見たり、LLMのトレーニングに必要な高速大容量ストレージについての話を聞いたり、keynoteで発表のあったHPE Private Cloud AIのデモを見ることができました。 特に興味深かったのは、HPE Aruba Networkingのデモで、AIによってネットワークの異常な振る舞いを検知したり、環境に応じたコンフィグを自動生成する様子を実際に見ることができたことでした。 左図は新発表の HPE ProLiant DL384Gen12 (HPE と NVIDIA の CEO のサイン入り)、右図は Direct liquid cooling (DLC) を導入した HPE Cray EX2500 Showcase には、開発中の製品、サービス、ソリューションを独占的に覗き見できる CDA Zone という区域もありました。 この区域はカーテンで覆われており、入り口で具体的な内容を外部に漏らさない旨の誓約書にサインすることで初めて立ち入ることができます。 普段は見ることができないサーバーの深い部分を知ることができ、とても興奮しました。 区域自体は小さく、見逃しやすいため、次回以降に参加される方は注意して立ち寄られることを是非おすすめします。 交流イベント HPE Discoverでは、 Peer-to-Peer Program というプログラムが提供されており、参加者同士で交流する機会があります。 このプログラムは、 1対1形式 と ラウンドテーブル形式 の 2種類がありました。 前者の1対1形式の交流では、同じようなサービスを提供している事業者の方とじっくりと対話して情報交換ができました。 自社と同じ課題を抱えていることや、課題に対する異なるアプローチについて知ることができ、非常に貴重な機会でした。 また、ラウンドテーブル形式の交流では、HPE 社 のシニアリーダーを含む白熱した議論を目にし、HPE 社のビジョンを体感して大きな刺激を受けました。 これらとは別に、HPE 社のエクスパートと個別のトピックについて議論する機会も何回か設けていただき、直近のサーバーのトレンドについて詳細な情報を得ることができました。 ラウンドテーブルの会場の様子 エンタメ寄りのコンテンツも充実しており、夕食の時間帯の Reception や Celebration では、バンド演奏やアルコールが提供される中で、さまざまなバックグラウンドの方と交流を深めることができました。 特に18日の HPE Discover Celebration では、貸切りの Sphere にて、アメリカの超人気ロックバンド Dead & Company の生演奏を堪能できたのは、忘れられない思い出になりました。 Reception / Celebration での交流の様子 海外カンファレンスへの参加は旅費もかかり、時差を乗り切るのも大変ですが、現地にわざわざ赴くことの価値は交流イベントにあることを強く実感しました。 Japan Session 最終日には Japan Session と称するイベントがあり、2時間に渡って日本からの参加者向けに4日間の内容のサマリーが紹介されました。 HPE Discover にはあまりにも多くのコンテンツがあり、とても4日間で全てを吸収するのは難しいと思っていたので、Japan Session はありがたいイベントでした。 交流イベントや他の予定と被っていて聞けなかったセッションの内容や、理解が追いつかず消化不良となっていた部分のフォローアップができて助かりました。 おわりに 目先の業務から離れてひたすらインプットできて、視野を広げることができる良い機会でした。 朝から晩まで予定で埋まっている日々で、非日常で濃密な時間を過ごすことができました。 また、HPE 社員の方々のお力添えもあり、多種多様な交流イベントに参加できたのはとても幸運でした。この場を借りてお礼申し上げます。 HPE Discover 2024 のセッションの一部の動画は YouTube の HPE 公式チャンネル に上がっていますので、この記事を見て興味を持たれた方は是非動画などをチェックしてみてください！ 会場の Venetian ホテルの中を流れる運河前で撮影。一見屋外のように見えるが実は屋内である。 HPE ProLiant Gen11 の一部の筐体には、初期状態では iLO6 が入っていますが、後から OpenBMC を上書きインストールしたり、逆に iLO6 を再インストールできます。 ↩

時系列データ分析ツール「Node-AI」を開発するスクラムチームは、LeSS（Large-Scale Scrum）を参考にした開発プロセスを採用しました。 本記事では、その背景や数か月試した結果について紹介します！ 目次 目次 はじめに Node-AIについて フロントエンドのリプレイスを終えて チーム分割に対する勘所 コンポーネントチームとフィーチャーチーム 実際の運用 チームへの愛着 2チーム体制を続けてきて おわりに 追記 (2025/01/20) はじめに はじめまして、イノベーションセンター Node-AIチームの中野、半澤です。 （中野）Node-AIチームでは2024年4月からスクラムマスターとして活動しております。 過去には研究者やデータサイエンティスト、ソフトウェアエンジニアなど幅広くジョブチェンジして今に至ります。 中野 将尚 | LinkedIn （半澤）Node-AIチームでは開発者としてインフラからフロントまで幅広く関わっております。 また、チームビルディングの話題も興味があるので、そういった話にちょいちょい首を突っ込んでいます。 我々は 「フロントエンドを Vue.js から React にリプレイスしたお話 (前編)」 で紹介した開発体制から次のステップに進んで、 LeSSを参考にした開発プロセスを採用し、運用してきました。 結果としてリリース頻度を約2倍にできましたが、そこに至るまでの裏話や新たに出てきた課題などについてシェアしたいと思います。 Node-AIについて 話の本題へ入る前に、Node-AIについて簡単に紹介します。 Node-AI はノーコードで時系列データのAIモデルを作成できるWEBアプリケーションです。 詳しい説明は 以前の記事 でも説明しているのでそちらをご参照ください。 現在（2024年6月時点）はβ版として公開しており、無料で利用可能です！（一部機能は有料） フロントエンドのリプレイスを終えて Node-AIの開発チームは「フロントエンドのリプレイス」という大規模なプロジェクトを完遂するため、 約10名のソフトウェアエンジニアを以下2チームに分割しておよそ1年半進めてきました。 プロダクト全体を改善するチーム リプレイスに集中して取り組むチーム そして、2023年12月の年末リリースというトラブル発生フラグが立ちまくりのリプレイス作業は何事もなかったようにシームレスに完了し、 これまでの技術では実現できなかった洗練されたUXを提供できたことでお客さまからも喜びの声を多数いただきました。 Node-AIチームは一新されたフロントエンドを武器に、さらにプロダクトを成長させていくため、 新年一発目のお題として、今後のチーム体制について話し合うことになりました。 チーム分割に対する勘所 Node-AIのスクラムチームは基本的に1チーム体制を採用してきましたが、いくつかの場面で一時的にチームを分割した体制を取っていました。 フロントエンドのリプレイスプロジェクトがその一例ですが、他には「SRE的に動くチームとNode-AIの機能開発チーム」で分割したこともあります。 その経験の中で、開発者からは1チーム体制へのネガティブな感情と複数チーム体制に対するポジティブな感情が、振り返りでよく出ていました。 1チーム体制だと人数が多いため、認知負荷やコミュニケーションコストが高く調整ごとやファシリテーションにストレスを感じたり、 スプリントプランニングで分割された各タスクの負荷分散がうまくいかず、動きが遅くなるといったことです。 一方、複数チーム体制においては認知負荷やコミュニケーションコストが下がるためタスクに集中できたり、 より自分事として捉えられチャレンジもしやすくなることで創造的な取り組みも増えたということが、 Fun Done Learn等の振り返りでも可視化されチームの共通認識となっていました。 この話は以下のように スクラムガイド にも記載されていることですし、 他社さんの事例もたくさんあるので目新しい発見ではありません。 スクラムガイド（2020） スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完了するための⼗分な⼤きさがあり、 通常は 10 ⼈以下である。⼀般的に⼩さなチームのほうがコミュニケーションがうまく、⽣産性が⾼いことがわかっている ただ、実際に1チーム体制とチーム分割の体制を両方とも長期間実践することで、 1チーム体制の課題（認知負荷・コミュニケーションコスト・タスクの負荷分散等）をチームが深く認識できていました。 そこで、それら課題の解消を狙いとしてチーム分割を前提に大規模スクラムの各種フレームワーク（LeSS、 Scrum@Scale 、 Nexus 等）の理解と議論を進めました。 コンポーネントチームとフィーチャーチーム Node-AIは多数の技術で構成されており、開発者内でも技術ごとに得手不得手や知識差はあります。 以下に主要な技術要素を挙げます。 これに加えて複雑なシステムの品質を担保するためのテスト技術群などQA的なスキルや、 時にはカスタマーサクセスチームを支援するコンサルタント的な素養も求められます。 時系列データの機械学習 フロントエンド（React） バックエンド（Python/C#） インフラ（パブリッククラウド、Kubernetes） 機械学習については教科書的なことだけでなく、研究開発チームの 成果・ノウハウ も取り込みます。 そのため研究レベルの技術を解釈して実装に落とし込むことも必要になります。 エンジニア約10人を複数のフィーチャーチームに分割した場合、それらのスキルが各チーム内で横断的にカバーできるか、という問いがチームでありました。 結論としてはLeSSの考え方を参考にチームを2つのフィーチャーチームに分割しましたが、 公平に分割すると開発速度に大きく影響しそうなものについて、片方のチームに得意なメンバーを固める体制としました。（一部コンポーネントチーム化） ※ LeSSやフィーチャーチーム・コンポーネントチームについて基本的なことは解説しませんので、 Introduction to LeSS - Large Scale Scrum (LeSS) などをご参照ください。 具体的には、新フロントエンド導入で手薄になっていたE2E試験とフロントエンドの結合試験はある程度形になるまで専門性を持ったメンバーを1チームに寄せました。 まずは1チーム内でスプリントを進めながらノウハウを共有し、その後もう一方のチームに展開する作戦です。 その他の技術も偏りはありますが、チーム内で完結できる能力をもったメンバー構成となっています。 ただ大きめな新機能の設計レベルになると特定の開発者に依存する場合はあるため、完全に分離できているわけではありませんし、 お互いのチームメンバー間で密に連携せざるを得ないことはよくあります。 今のところチーム間で積極的に連携することが何か課題になっている感覚はあまりなく、 むしろコミュニケーションが活性化し、心理的安全性につながっている気がします。 実際の運用 2チーム体制はLeSSを参考に構成することとしましたが、LeSSの形式やプラクティスを積極的に採用するのではなく必要な部分を少しずつ取り入れる形としました。 理由として、1チーム体制時にも継続的に改善に取り組んできた良い面は残したいですし、 各種プラクティスを強制しなければならないほどの課題感はなかったためです。 以下はLeSSを参考にした部分です。 プロダクトバックログは1つ スプリントプランニングは第一部を全体で行い、第二部をチームごとに行う 一方、以下の部分は独自に決めたプロセスです。 デイリースクラムは第一部を全体で行い、第二部をチームごとに行う 振り返り（レトロスペクティブ）は全体で行うことを基本とし、チーム単位で行うかどうかは内容によって決める LeSSではチームごとのデイリースクラムのみが基本ですが、 Node-AIでは全体のデイリースクラム（内部ではOverall朝会と呼んでいる）を開催することにしました。 LeSSといっても2チームで約10人という世の中の大規模スクラムと比較すればまだ少人数です。 全体で予定を合わせることはそこまで大変なことではありません。 Overall朝会では以下のことを実施しています。 今日のイベント、不在者の確認 全体向けに話したいことがあれば共有 両チームは開発問わずさまざまな場面で連携するため、だいたい1日に1議題くらいは話し合っています。 事務処理や全体イベント（リファインメント等）の調整ごと、他チームにも共有したいトピックや相談頭出し等さまざまです。 このOverall朝会は15分をタイムボックスとしていますが1分で終わることもあり、たいていは5分以内で終わります。 レトロスペクティブについては全体で話すだけでも十分に効果的な内容もあるため、 チーム単位でのレトロスペクティブは任意としました。 ただ実際は2回に1回程度の割合でチームごとのレトロスペクティブを実施しています。 スプリントレビューについては臨機応変に調整しています。 多くの場合2名以上のステークホルダーにきていただくため、以下の流れになることが多いです。 最初に参加者全員に対してプロダクトオーナー（PO）からプロダクトゴールに向けた状況やレビューの全体像を説明 招待したステークホルダーの数だけ場所を分かれてレビューを実施 各ステークホルダー向けにインクリメントのレビューを実施（ファシリテーションは開発者） POや開発者はそれぞれのレビュー場所に自由にばらけて議論に参加 最後に全体に対してPOから今後のロードマップ等を共有 ※ スプリントレビュー含めて全てのイベントは基本的にリモートで開催しており、NTT Comのコミュニケーションツール NeWork を使用しています。 NeWorkでは複数の場所に分かれてコミュニケーションしつつ、他の会話にも気軽に参加できるようになっています。 レビュー対象のインクリメントは各チームで内容が異なることもありますが、 1つのスプリントゴールに向けたプロダクトバックログアイテム（PBI）を分担していることもあります。 いずれにせよ、事前にレビューのシナリオを2チームで話し合って準備しています。 また、チームごとに分かれてスプリントレビューを実施するということは基本的にありません。 他チームのインクリメントに関連する次のPBIは次スプリント以降に自分のチームで対応する可能性があり、 そのためにステークホルダーのフィードバックを直接聞く機会は貴重なためです。 また、他の場所で行われたレビューの状況やフィードバックのメモはスプリントレビュー後に全員で眺めながら議論したり、 PBIの種となるペインを抽出する作業も共同で実施しています。 そのようにすることで他チームの開発内容を深く理解することにつながり、 「どちらかのチームしか対応できないPBI」が発生しないようにする効果があると考えています。 チームへの愛着 このようにNode-AIの開発は2チーム体制で進めていくことを合意して運用してきました。 そこで「せっかくチームを分けたのだからチーム名くらい付けよう」という話があがりました。 実は今まで2チーム体制に分けたときは特にこだわったチーム名を付けておらず、 フロントエンドのリプレイス時には「本流チーム」と「リビルドチーム」という何とも味気ない呼び方でした。 新しいチーム名は何か共通の概念で統一したほうがよいとの声が多数だったため、 まずはアイデア出しから始め、「お酒の名前」「何らかの記号」などが挙げられ、多数決で「花の名前」で名づけることになりました。 「花言葉」を使って何らかの意味をチーム名に持たせられるということで各チームが議論し、 結果として「アザレア」「モモ」という花が選ばれました。 アザレアの花（２） | フリー写真素材 Photo-pot モモ（桃）の花 無料フリー写真素材 (freephoto.sakura.ne.jp) ちなみにアザレアの花言葉は「節制」「禁酒」「恋の喜び」、モモの花言葉は「私はあなたのとりこ」「天下無敵」「気立ての良さ」「長命」などのようです。 最初は小恥ずかしさもあった名前ですが、今ではお互いのチームを自然に「アザレア」「モモ」と呼ぶようになり、 事情を知らない人の前でも普通に言ってしまい微妙な空気になることもあります。 またそれぞれaz（azalea）、mm（momo）という略語も浸透したことでSlack等のチャットコミュニケーションで いちいち「リビルドチームは～」とか書かず「mmは～」と書けるためタイピング時間の節約にも役立っています。 またざっくりアザレアは紫色、モモはピンク色だと思うことにして、 タスク管理ツールでもPBI等に色付けをすることで、どちらのチームのタスクなのかが一目でわかるようにもなりました。 チーム名というのはチームへの愛着のわずかな要素ではありますが、最初にやってよかったことの1つだと感じています。 2チーム体制を続けてきて さて、上記の通り2024年1月から2チーム体制を続けてきました。 ここで現状を振り返ると、以下のことがわかりました。 各チームで独立してほとんどのPBIを実施できている 技術的な偏りについてはチーム内/チーム間で少しずつスキトラ（スキルトランスファー）が進んでいるが、まだまだ完全ではない チームを分割したことによる認知負荷やコミュニケーションコストは軽減されているとともに、チーム間連携に大きな問題は発生していない 1.と2.について、現状でも「この人じゃないと難しい」という技術領域はどうしても存在するため、一部のPBIがチームに依存した形となることはあります。 しかし、ほとんどのPBIはどちらのチームでもこなせる状態になっています。 そのためスプリントプランニング時に、どちらのチームでPBIをとるか？でお見合い状態になることもしばしばあります（笑）。 たいていそういった場合はチームメンバーのWillでPBIの担当チームが決まります。 また、チームによって扱う技術領域に偏りが出ないように、前スプリントで扱ったPBIと似たPBIが次のスプリントにある場合は、もう一方のチームが担当するといった工夫もしています。 その場合は必要に応じて他チームの有識者に教えてもらいながらPBIを進めていくこともあります。 （状況によってはもちろん短期的な効率を重視して似たPBIを同じチームで担当することもあります。） 一方で上記に記載している、「この人じゃないと難しい」という技術領域はハイレベルなものや込み入ったものであり、スキトラはなかなか進んでいない状況です。 一朝一夕でスキトラできるものではありませんし、各チームメンバーの興味関心のある技術の違い、キャリアプランも影響してくるため難しい問題です。 3.については本記事を執筆している我々も感じていることですし、レトロスペクティブでもチームメンバーの多くから同様の声が挙がりました。 チームを分割した狙いの1つである「認知負荷/コミュニケーションコストについての負担の軽減」については効果を得ることができたと感じています。 また、レトロスペクティブにて出た内容を一部紹介します。 このレトロスペクティブは2チーム体制になってから3カ月過ぎた4月頭に実施したものです。 ◆良かった点（Keep） リリース頻度が上がった ◆気になる点（Problem） 細かい挙動を把握していない機能が増えた 良かった点として「リリース頻度が上がった」ということが挙がりました。 以前は1スプリント（1週間）で原則1回でしたが、最近では1スプリントで2回、3回と複数リリースできることが増えてきました。 これはより素早い価値検証を可能にするものとなるため、チーム分割により非常に良い効果が出ていると考えています。 具体的に何が理由で「リリース頻度が上がった」のか、大きく2つあると考えています。 1つめはチーム体制以外の効果によるもので、「リプレイスによってコードを修正しやすくなった」からです。 リプレイスによって技術負債が解消して機能追加が容易になり、結果としてリリース頻度の向上に寄与したということになります。 2つめはチームが小さくなったことによる「認知負荷/コミュニケーションコストについての負担の軽減」になります。 認知負荷やコミュニケーションコストが軽減することで、実装に集中できる時間が増えたということになります。 実際に開発者からのコメントでも「タスクを取る迷いは減った（誰かが取るかも…？という迷いが減った）」という意見が出ています。 それに付随して、ある程度チームごとの判断でリリースができるため、各チームが1～2回リリースできている状態です。 一方、気になる点として「細かい挙動を把握していない機能が増えた」が挙がりました。 具体的には、スプリントレビュー時に初めて他チームのインクリメントを見ることが多く、 内容を知らないままスプリントレビューに出てしまうといった問題が出てきました。 これだと他チームのインクリメントに対するフィードバックへの理解が深まらず、関連するPBIが生まれても同じチームが担当する、 といったようにタスクがチームに固定された状態が深刻化すると予想されます。 この改善策として、スプリントレビュー前日にお互いのチームでインクリメントのデモをする取り組みを考えました。 これにより少なくとも他チームのインクリメントがどういったものか理解して翌日のレビューに臨むことができるようになりました。 まだ取り組みを始めたばかりですが、この取り組みによってよりよいレビューを実施できていると感じています。 以下はレトロスペクティブ時の議論の一部のキャプチャになります。 おわりに LeSSを参考に2チーム体制として良い点・悪い点が見えてきました。 しかし、チーム分割の狙いの1つであった「認知負荷/コミュニケーションコストの軽減」には効果があり、 チームメンバーからも好意的に取られていることを考えると、チーム体制変更は正解だったと感じています。 上記で紹介した内容以外にもスクラムを回していく中で問題は現在進行形で出ていますが、 改善を続けていくことでより良いものにしていきたいと考えています。 またNode-AIをユーザにより利用してもらうために、開発者がアプリ開発以外の活動に取り組むことが増えています（以下例）。 カスタマーサクセスチームと連携してユーザの伴走支援をする Node-AIを利用した 学習コンテンツ を作成する これは開発者がユーザの解像度を上げるという点においては良い効果がある一方で、 チーム外とのコミュニケーションコストが増え、開発時間が減る問題も出てきています。 今後はこのあたりの改善も考えていくつもりです。 最後になりますが、この記事を書くにあたって協力いただいた皆さま、Node-AIの開発チームメンバー、 そしてこの取り組みの立ち上げた前スクラムマスターのへ感謝の意を表してこの記事を締めたいと思います。 本当にありがとうございました！ 追記 (2025/01/20) この記事から半年を経て、1チームでのスクラム体制で再出発することになりました。詳しいことはこちらの記事をご覧ください。 engineers.ntt.com

はじめに こんにちは、イノベーションセンターの梶江、原田、佐瀬、江崎、山田です。 NTTコミュニケーションズ株式会社 (以下、NTT Com) は、日本最大級のネットワーク展示会である 「Interop Tokyo 2024（会場：幕張メッセ、会期：2024年6月12日〜14日）」 において構築されるShowNet 1 に対し、昨年に引き続き 2 コントリビューターとしてローカル5G（以下、L5G）システムを提供し、実験試験局の運用に成功しました。 今年はトランスポートNWにNTT研究所のFDN (Function Dedicated Network :機能別専用NW)を使用。オープン光伝送NWを用いた柔軟性のある確定通信を実現。UPFについても、NTT研究所がDPU(Data Processing Unit)を用いて内製開発したdUPF (distributed UPF) 3 を使用しました。 これら新技術と、AWS上にデプロイされたドコモの5Gコア(5GC)をQmonus SDK 4 からあわせてコンロールすることで、より高度なネットワークスライシング制御にチャレンジ。L5Gの特徴である高速大容量・超低遅延・多数同時接続を活かした高精細な音声・映像伝送をShowNetテクニカルツアーという実例で実現しました。本記事ではその構成やスライシング制御手法、技術的なチャレンジ、無線性能測定結果について解説します。 マルチベンダーにおける伝送連携制御 私たちは、高度な情報処理・高機能通信を場所・利用形態を問わず提供可能とする基盤を構築し、端末/デバイス・NW・アプリケーションをエンドツーエンドかつシームレスに連携させることを目標としています。それを達成するには、高機能で多様なネットワークスライシングの要件に対応する5GCと、伝送区間で確定性通信を実現させる仕組み、それらを制御する技術が必要になります。 ネットワークスライシングの説明は 過去の記事 が参考になるため、詳細記載を省略します。今回はAirspan社製の基地局を用いたローカル5G環境を構築。ローカル5Gで使用される周波数帯はライセンスバンドであるため、法令に則って実験試験局免許を取得し運用しました。そのNWで、NTT内製のdUPF、FDN、Qmonus SDKを組み合わせ光伝送レイヤも含めたエンドツーエンドのスライス制御にチャレンジしました。下図が構成となります。順番に解説していきます。 NVIDIA DPUを用いたNTT内製UPF 本構成のUPFでは、NTT ネットワークサービスシステム研究所が内製開発したdUPFを使用しました。NVIDIA社DPUにUPF処理を完全オフロードすることで、5GCと連携する、小型軽量・高性能・高信頼・低消費電力なUPFを実現しました。 また、UPFとしての転送処理だけでなく、NAT・FW・VPN・DPIなど、キャリアネットワークならではの付加価値機能を含め、オープン化が進むDPUハードウェア上で実装・展開することで、ユーザ端末環境やサービスの要件・状態に合わせ、必要となる最適なNW機能・リソースを柔軟に構成可能です。 FDNによる確定通信の実現 基地局〜UPF、UPF〜DN間のトランスポートNWは、NTT ネットワークサービスシステム研究所が開発したFDNによって生成された光伝送路を含む通信路を使用しています。FDNでは、APN 5 上に様々なサービスを収容する専用NWをサービス毎に構築し提供します。APNでの動的な波長制御による伝送パスの割り当てを活用し、FDNに収容するデジタル信号や利用するアプリの特性に応じた最適な専用NWを構築。さらには、無線基盤・コンピューティング基盤との連携制御も目指しています。 今回は、FDNを構築する際に必要となるロスレス・ジッターレスといった確定通信をエンドツーエンドで実現するためにFDN Bridge（WhiteboxTransponder＋WhiteboxSwitch）とそれを制御するためのFDNコントローラを用いました。 FDNコントローラはオーケストレータやアプリからのパスリクエストを受けWhiteboxTransponder及びWhiteboxSwitchを制御することで、200G/400Gといった広帯域の波長パスに対して要求された通信帯域分だけの通信リソースを割り当てることを可能としています。また、APNだけではPoint-to-Pointの通信となってしまいますが、FDN Bridgeで利用する波長パスを選択・振り分けることでより柔軟なネットワーキングを可能としています。NTT ドコモのコントリビューション部分については、  NTTドコモ の ENGINEERING BLOG記事 をご覧ください。 dUPFの性能測定についてはこちらで言及されています。 Qmonus SDKを用いたオンデマンドなスライス払い出し ユーザのリクエストに応じてネットワークスライスを払い出すには、5GC、トランスポートNW、UPFといった異なるドメインの装置それぞれに設定を適用する必要があります。 各装置に対して設定するオーケストレータはQmonus SDK(NTT Com内製のマイクロサービス開発フレームワーク)を採用しました。Qmonus SDKは異なるマイクロサービス間の横断したトランザクション管理を特徴としています。5Gシステムでのスライス操作では、1つの装置に対して複数の設定を直列に投入したり、装置間を跨って設定を投入しなくてはなりません。Qmonus SDKにより5GC、dUPF、FDNそれぞれの装置が持つAPIインタフェースに対して順次設定を投入し、装置間をまたいだトランザクションを保証します。 実験試験局の運用 昨年に引き続き実験試験局免許申請を行い、電波を発波する実験試験局を運用しました。チームメンバーの80%以上が無線従事者免許を保有しており、電波法を尊法し、輪番を組んで運用を行いました。 5G基地局となるgNB装置は廉価且つ簡易な構築・導入が可能な「RU/CU/DU一体型」を特徴とするものを採用。Airspan社の屋内型一体型gNBであるAirVelocity 1901をInterop Tokyo 2024 の会場（幕張メッセの展示ホール4）に設置しました。今回は5Gにおける時刻同期方式にPTP(Precision Time Protocol)を用いました。 PTPは専用の時刻同期用パケットにタイムスタンプを埋め込み、システム間で交換することで双方の時刻を同期する方式です。 これにより1台のPTPタイムサーバーから光ファイバケーブル経由で、高精度な時刻同期を実現できました。 無線性能測定 AirVelocity1901のダウンリンク(以下DL)とアップリンク(UL)の無線性能であるRSRP vs スループットを測定しました。DLのmaxスループットは約650Mbps、ULは約65Mbpsという結果となり、両者ともに高い速度性能が発揮できていることがわかりました。また、DL・UL共に受信電力であるRSRP値が約-100dBmまでmaxスループット値が維持でき、ある程度基地局から離れても最大速度で端末を使用できることが分かりました。 幕張メッセの展示ホール4のShowNetツアーブース周辺での受信電力RSRP値の測定も行いました。ツアーブース内と周辺でRSRPが約ー100dBm(前述のmaxスループットを維持できるRSRP値)を維持しており、ShowNetツアーで音声・映像配信を行うのに問題無いローカル5Gカバーエリアとなりました。 おわりに この記事では、Interop Tokyo 2024（会場：幕張メッセ、会期：2024年6月12日〜14日）において構築されたShowNetにおける、光伝送レイヤも含めたエンドツーエンドのスライス制御の取り組みを紹介しました。今後は、今回の各種性能測定の成果を踏まえ、より多種多様なユースケースに対応できるネットワークスライシングの方式や、NTT Comのネットワークサービスへの応用について検討していきます。この記事に登場したローカル5G基地局はShowNetブースNOCラックの側にある背の高いトラスの先端に設置されています。 是非会場に足を運びご覧になってください。 Interop Tokyo への出展社がインターネットへの接続性を利用して製品の動態展示のほか、来場者のインターネットへのアクセスとしても利用されるネットワーク。また、さまざまな機器・サービスの相互接続性検証を実施するとともに、近未来のサービスアーキテクチャを実際に動かしている形で見ることができる日本最大規模のライブネットワークデモンストレーションでもあります。 https://www.interop.jp/2024/shownet/ ↩ 昨年ShowNet2023でも我々はネットワークスライシングの取り組みを実施しました。 https://engineers.ntt.com/entry/2023/06/14/084318 ↩ 6G Computing Architecture: Distributed, Software Defined Accelerated and AI-enabled( https://www.nvidia.com/en-us/on-demand/session/gtc24-s61898/ ) ↩ Qmonus SDK： NTT Com内製のマイクロサービス開発フレームワーク ↩ APN ：端末からネットワークまで、すべてにフォトニクス（光）ベースの技術を導入し、エンドツーエンドでの光波長パスを提供する波長ネットワーク ↩

はじめに こんにちは、イノベーションセンターの福永です。 NTTコミュニケーションズ株式会社は、日本最大級のネットワーク展示会である「Interop Tokyo 2024（会場：幕張メッセ、会期：2024年6月12日〜14日）」において構築されるShowNet に対して、Celona製品を用いてローカル5G環境を構築しました。 また、ShowNetウォーキングツアー用にローカル5G端末を提供しました。 ローカル5Gの構成について ローカル5Gとは、自治体や企業など通信事業者ではない組織が、自らの建物内・敷地内でユースケースに応じて個別に構築する専用の5Gネットワークをいいます。 5Gには、4Gのインフラを基盤として動作するタイプ (NSA: Non Stand Alone) と5Gのインフラのみで動作するタイプ (SA: Stand Alone) に分けられますが、今回はSA構成で構築しています。 Celonaとは Celonaとは2019年4月設立、カリフォルニア州キャンベルに拠点を置く企業向けプライベート5Gネットワークの新興ベンダーです。 Celonaプライベート5G LANは、組織に容易に導入できるよう設計されています。 設定はすべてCelona Orchestrator上で一元管理されており、ローカル5Gに接続されている各種端末情報を確認することも可能です。 今回の取り組みではCelona製品を利用し、ローカル5Gの環境を構築しました。 事前準備・事前検証 ShowNetに機器を持ち込む前に事前準備や事前検証を行っています。 ローカル5Gの利用にあたり無線局の免許(電波法第四条)の申請が必要であり、Interop Tokyo 2024に向けて屋内でのみ設置可能な周波数帯である4.6GHzの電波の免許を取得しています。 また、スペクトルアナライザで4.6GHzから4.7GHz以内に電波が収まっていることを確認しています。 提供端末について ShowNetウォーキングツアー用に今回私達はローカル5G端末としてiPadを提供しています。 iPadをローカル5Gで利用するためにはいくつか条件があり、その1つがプライバシーの秘匿要件です。 これを満たすためにローカル5G製品ではSUCI(Subscription Concealed Identifier)への対応が必要です。 また、指定されたMCC(モバイル国コード）及びMNC(モバイルネットワークコード)を利用する必要があり、IMSIが999002から始まるSIMカードを利用しています。 MCCが999、MNCが002で始まるIMSIについては、総務省総合通信基盤局電波部移動通信課に対して指定申請を行う必要があり、今回のイベントに向けて申請を行っています。 今回の提供端末は、最新のM4チップのiPadを使用しました。これには物理的なSIMカードを刺すスロットがなく、eSIMのみに対応しています。 アメリカで発売されているiPhoneはすでに物理SIMスロットがなくeSIMだけで今後、日本においても同様にeSIMのみとなる可能性もあるかもしれません。 また、工場やIoTで使用される端末ではeSIMのみに対応する端末もあり、対応が必須となりますが、今回はその実用性も実証できました。 eSIMは大きく分けるとコンシューマ（スマホ向け）とM2M(IoT等の機器向け)の二種類があり、今回はコンシューマ向けのeSIMを利用しています。 その場合、QRコードを読み込んでSIM製造ベンダ側が提供しているeSIMサーバ(SM-DP+)と通信させプロファイルのダウンロードが必要となります。 現地測定について 無線品質の測定はWindows端末にネットワーク測定ツールをインストールして測定しています。 下の散布図は、現地の測定結果で縦軸がスループット(NR PDSCH Tput(Mbps))、横軸が電波強度(NR PCell SS-RSRP (dBm))で表しています。 会場内を歩き回り測定を実施したところ、電波強度が-130dBmを超えたあたりでローカル5Gとの接続が切れることがわかりました。 また、ダウンリンクが500Mbps、アップリンクが70Mbpsを超えたあたりで頭打ちとなっており、会場内での最大スループットはその値までは電波強度と比例関係にあることがみてとれますが、その値が限界となっていることが散布図の傾向から考察できます。 下のヒートマップは会場内の電波強度を色の濃淡で表しています。 展示ホールの4の2箇所から電波を発出しており、中央や奥の展示ホール6に行くにつれて電波強度が弱くなっていることが確認できました。 終わりに 本記事では、Interop会場に構築したローカル5G環境について紹介しました。 今回、屋内環境について検証ができたので、今後は屋外環境での導入検討も進めていく予定です。 今後もローカル5Gについて情報発信していくことにより、多くのお客さまに利用して頂けるよう努めていきたいと思います。 最後までお読み頂きありがとうございました。

こんにちは、クラウド & ネットワークサービス部の井口です。普段は OpenStack を利用した SDPF クラウドの仮想サーバ開発/運用をしています。 昨年 12 月に開催された学生向けの技術広報 1day イベントにて、私は当時新卒 1 年目で運営リーダーとして携わりました。 この記事では、運営リーダーを務めた経験から得た学び・知見を紹介します。 Tech Workshop とは NTT Com が主催する企画の 1 つに「Tech Workshop」 1 というものがあります。主にエンジニア志望学生向けに、現場で活躍する社員とともに手を動かしながら NTT Com の技術や業務を理解できる 1day イベントとなります。大きな特徴として、メンバーの大半が現場のエンジニア社員で構成されており、本業務の傍ら企画・運営を行ない、イベントを主催しています(以降運営チームを Tech Event チームと称します)。 Tech Event チームは技術領域ごとに分かれて活動しています。昨年 12 月及び今年 1 月、私が所属するクラウド分野では、とある OSS をモチーフにしたコーディングイベントを企画し、モブプロ形式 2 で社員/学生問わずワイワイガヤガヤとプログラミングのお題に挑戦していくようなプログラムを開催しました。Step by Step で解き進められる問題を作成していますが、なかなか一筋縄ではいかない課題設定にしているため、参加者の皆さんには良い意味で頭を悩ませていただけたかと思います。 詳しい内容については、同内容で開催した 過去のエントリ をご覧ください。本稿では、そのイベント運営の裏側をお話しします。 イベントを支える運営チーム 紹介した Tech Workshop を始めとするいくつかの技術イベント運営を行なうために、Tech Event チームが組成されています。先に述べた通り、その多くは有志の現場エンジニア社員から構成されており、いくつかの技術分野がある内でクラウドチームだけでも数十人規模となっています。 Tech Event チームの活動の中でも、Tech Workshop は学生が参加することから大きな目玉イベントとなっています。オンラインで実施するため会場設営コストこそ少ないものの、モブプロを題材としながら参加者に NTT Com の事業・取り組み・エンジニア社員への理解度を深めていただくコンテンツを作り上げるため、準備は入念に進められます。そのような背景の下、企画・運営を取り仕切るイベント運営リーダーは、準備を着実に取り仕切り、当日の司会進行含めイベントを必ず成功させなければなりません。 「私がイベント運営リーダーに？！」 〜怒涛の一ヶ月を経験して〜 さて、昨年 12 月のイベント開催から約 1 ヶ月前、Tech Event チームのキックオフミーティングが実施されました。 私は元々イベント運営に強い関心があったわけではありませんが、所属する部署のメンバーが前年度から積極的に本企画運営へ携わってきていたことや、数年前私自身が学生として参加した経験もあり、なにか協力できることがあればいいなという心持ちで参加していました。実際、数十人規模の Tech Event チームクラウドチームの中で 1 年目社員は片手に満たない数であるため、当初は簡単な運営業務に落ち着くのではないかと呑気に考えていました。 そんな気持ちで参加したキックオフにて、なんと部署の先輩から「イベントリーダーをやってみないか？」と声をかけていただきました。はじめは面食らったものの、「新卒社員がイベントリーダーをやってみた」という状況に単純にワクワクしていただけでなく、年次も高く自分より圧倒的に本業が忙しい社員が多い中で、当イベントの流れが頭に入っている自分は誰よりも適任かつチーム全体にとって最適である自負がありました。そしてなにより、まだ何も成していない新卒社員に一定の信頼を置いてお声がけいただけた感謝があったため、この折角の機会を逃すわけにはいかないと、私がリーダーとして携わることを決意しました。 運営のキックオフからイベントの開催までの 1 ヶ月間は、私にとっては新たな経験の連続でした。決意して引き受けたとはいえ、イベントリーダーは本イベントを成功させるための全ての責任を追うプロジェクトマネージャーに相当する役割です。当然、当日運営だけではなくそれまでの事前準備も担います。お題設定などのコアな部分は勿論のこと、当日に向け、関係者との調整やケータリング手配といった雑務など、そのタスクは多岐に渡りました。 私目線で苦労したポイントとしては、以下の 3 点にまとめられます。 タスクマネジメント 先述の通り、イベント開催に向けたタスクは多岐に渡ります。イベントの概要策定、タスクの洗い出し、社内外の連絡、サポートメンバーの勧誘、進行表の作成、当日の資料作成など、考えることは山のように見えました。抜けなく漏れなくタスクを捌いていかなければいけないプレッシャーの中、過去実績とにらめっこしながら、かつ自身の参加経験を思い出し、当日何が必要かといったイメージを具体的な ToDo に落とし込み続ける日々が続きました。 ステークホルダー間の調整 リーダーと共に企画準備・運営の中心となるコアメンバーとの連携は勿論、複数イベントを横断する統括リーダーへの進捗報告、広報へのイベント周知依頼、ケータリングや当日使用するツールの申請・手配など、身近なメンバーを越えたステークホルダーとの調整業務には常に追われ続けることとなりました。社会人 1 年目の私にとってはまだまだ不慣れであり、先輩方に手を差し伸べていただく機会が多い部分でした。サポートを頂きつつも、各調整業務のスケジュール/温度感は特に注視することで、少しでもミスの発生確率を下げられるよう心がけていました。 タイムマネジメント 当然ながら主業務のプロジェクトがあるだけでなく、1 年目向けの部署を越えたジョブローテ研修、技術顧問である twada さんによるソフトウェアエンジニア育成プログラム 3 が同時期に重なったため、四足のわらじでの活動となりました。さすがに入社後で一番忙しかったですね…。自身もスケジュールを強く意識していたほか、運営メンバーにタスクを振る際は事前に締め切りを明確にし、スケジュールビハインドが予想される場合にすぐ共有し次の対応を検討できるような体制作りに努めました。 以上に加え、今回定員を大きく上回る応募があったため、従来に加えて参加者の選考や連絡業務もスケジュール厳守で行なうことになりました。それらを一人でこなすことはもちろんできません。自他部署のメンバーから多大な協力をいただいたほか、先輩方も積極的にアドバイスや相談に乗っていただけたため、何とかイベントを成功させることができました 4 。 一年目の視点で見えたもの 運営者になって感じた Tech Event チームの重要性 先述の通り、私は以前 Tech Workshop に学生として参加しました。当時は NTT Com のエンジニアの方々と直接交流できる良い機会だと考えていた程度でしたが、今回運営側として多くの学生の方との対話を通じたことで、我々自身が持つ課題というのも見えるようになりました。 その代表例は、技術職周辺における企業/事業活動認知には課題が山積している現状です。例えば私が携わるクラウド事業ですが、国内有数のパブリッククラウドを一から内製で開発・運用しているのにも関わらず、NTT Com エンジニアの高い技術力・専門性はおろか、クラウド開発をしていることそれ自体が知れ渡っていない現状を実際に感じることとなりました。私自身も偶然参加した Tech Workshop が無ければ入社を検討しなかっただろうと思うだけでなく、今回のイベントで交流した学生からも、NTT Com のクラウド開発について初めて知ったという声が上がっていました。 今回の Tech Workshop はエンジニア志望の学生に NTT Com の取り組みを体験していただくことを主目的としていましたが、今後もさまざまなイベントの開催・参加を通じ、自社の取り組みを周知していく活動は必要不可欠でしょう。Tech Event チームも more ドコモ 5 に社員インタビュー(なんと 10 人分！)を掲載した他、本チームに関わらず数多くの社員が技術ブログ 6 で社内外での技術情報発信に積極的に取り組んでいます。私も引き続き、より一層 NTT Com の取り組みやその活躍を広く知ってもらえる環境が形成できるよう貢献していきたいと考えています。 リーダーとしての反省 ここは個人的なふり返りとなってしまいますが、まだ本業務でもプロジェクトマネジメントの経験が浅い私にとって、本経験で得た学びは非常に大きいものでした。 特に大きな収穫は、メンバーと協調してプロジェクトを進めるにはまず自分自身がゴールを見据えていることの重要性です。プロジェクトが何を達成しなければならないかという認識を全員で共有できれば、リーダーメンバー問わず自律的に次に成すべき行動が見えてくるものだ、という経験を得ました。 今回至らなかった部分としては、私のオリジナリティを発揮できなかったことでしょう。本イベントは過去にも開催された実績があり、準備段階での参考資料も多く存在しています。それらを元に、期間内に、確実に、チームメンバーの協力を仰ぎながらイベントを無事に終えることを最優先としていたため、自分自身のアイデアを形にできなかったことが反省点です。今回の経験を活かし、本イベント、ひいては Tech Event チーム活動全体がより良いものになるよう、次回に向けて準備しています。期待してお待ち下さい！ 一年目がイベントリーダーを務める意義とは 今回 Tech Event チームメンバーを代表して一年目の私がイベントリーダーを務めさせていただきましたが、本活動を通じて、NTT Com の風土、特に挑戦や改善の道に前向きな環境があることを改めて示せたことに大きな意義があると考えています。 先述の通り、まだまだ入社して日が浅くリーダーとしてもまだまだ微力な私ですが、周りの方々はそれを後押しするだけでなく、共にイベント成功へ向け歩むことができました。社員それぞれの自主性を重んじることに加え、新入社員でも挑戦させてくれる環境があることは、今回私がイベントリーダーを務めたことで名実ともに証明できたのではないでしょうか。また本記事を通じて、常に改善の道へと進もうとする社内風土があり、たとえ技術職であっても(元来 Tech Event チームが現場のエンジニア主体となっていることからも)そのような取り組みが是とされている環境を少しでも感じていただければ嬉しいです。 次回インターンシップのお知らせ ドコモグループでは、今年も Tech Workshop を開催します！ 私が携わるクラウド分野では、より一層クラウド開発について深く知ることができるイベントになるよう現在準備を進めています。クラウドの他にも、ネットワーク、セキュリティ分野でも 1 day イベントが開催されます。 また、サマーインターンシップ 2024 も開催されます。本技術ブログに多数体験談が掲載されている現場受け入れ型インターンシップも下記スケジュールにて開催予定です。 興味を持たれた方は是非ご応募ください。 7 エントリー期間 開催日 Tech Workshop 6/3（月） ～ 6/23（日） 7/7（日）または 7/13（土） 現場受け入れ型インターンシップ 6/3（月） ～ 6/21（金） 8/26（月） ～ 9/6（金） ※ 土日除く Tech Workshop | インターンシップ情報 | NTT ドコモ新卒採用 ↩ Mob Programming - A Whole Team Approach by Woody Zuill | Agile Alliance ↩ ソフトウェアエンジニア育成研修 - twada 塾 - Shines ｜ドコモビジネス｜ NTT コミュニケーションズ ↩ 大きなトラブルなくイベントを終えることが出来ましたが、実は当日の司会進行でガチガチに緊張していた私は、冒頭マイクミュートで話し始めるという失敗をしてしまいました(参加学生の皆さん失礼いたしました)。しかもハードウェア&ソフトウェアの二段構えでミュート芸を披露することに。トホホ…。 ↩ more ドコモ　@NTT ドコモ新卒採用チーム ↩ NTT Communications Engineers' Blog ↩ インターンシップ情報 | NTT ドコモ新卒採用 ↩

はじめに こんにちは、イノベーションセンターの藤田、鈴ヶ嶺です。NTTコミュニケーションズ株式会社 (以下、NTT Com) は、世界最大級のネットワーク展示会である 「Interop Tokyo 2024（会場：幕張メッセ、会期：2024年6月12日〜14日）」 におけるShowNetに対し、コントリビューターとしてローカル5G（以下、L5G）システムに携わりました。その取り組みに付随して、ShowNetと連携しAWS Outposts サーバーを用いたメトリクス監視基盤を構築しました。本記事ではその構成について解説します。 AWS Outpostsは、AWSのハイブリッドクラウド製品です。オンプレミス上に製品を設置してPublic AWSと同じような操作性でインフラストラクチャとサービスを作成できます。詳細については以下のリンクをご参照ください。 https://engineers.ntt.com/entry/2023/03/24/095642 メトリクス監視のアーキテクチャ 5G ネットワークでは通信品質の向上や保守運用のため、各セグメントごとに取得される大量のメトリクスデータを監視・可視化・分析する必要があります。 本アーキテクチャではエッジでのリアルタイム監視に加え、クラウドで大容量のデータを可視化・分析する基盤を構築しました。 エッジではAWS Outposts サーバー上にEC2インスタンスを構築し、EC2にて動作するPrometheusからLNI経由でオンプレミスのメトリクスデータを取得しています 1 。 これによりリアルタイムでパケットのドロップ率やセグメントごとのパケット流量なども可視化できるため、トラブルの早期発見やボトルネックの特定も期待されます。 EC2上のPrometheusで取得したデータはVPC経由でPublic AWS上のAmazon Managed Service for Prometheusに送信され、データを統合して蓄積しています。 エッジで一時的に蓄積することにより、通信量の削減や省電力化が見込まれます。 例えばリアルタイムなアラート処理はエッジ側で実施、モニタリングは全データを送るのではなくn秒間の統計値(平均、中央値)などをクラウドに送信することでデータ量を約1/nに削減できます。 クラウド上での可視化・分析についてはPublic AWSにてAmazon Managed Service for Prometheus、Amazon Managed Grafanaを利用し、スケーラビリティを担保しつつ運用コストを抑える構成にしました。 AWS Outposts サーバーを用いることのメリット AWS Outposts サーバーを用いて監視基盤を構築することは、1から基盤を構築することと比べて、以下のような点でメリットがあります。 Public Cloudサービスとの親和性 統一されたセキュリティの担保 Public Cloudサービスとの親和性 データの転送や集約するためのネットワーク設計や集約基盤との統合を1から作ろうとすると膨大なコストが必要となります。 AWS Outposts サーバー上に構築したEC2インスタンスはPublic AWSのVPCとシームレスに接続可能です。 また、VPCエンドポイントを利用することでインターネットに出ることなくPublic AWSのさまざまなサービスとの統合が簡易に可能となっています。 これらによりオンプレミスにありながらPublic Cloudのサービスとの親和性があることで、自動化やマネージドサービスの恩恵であるオペレーションコストの削減が見込まれます。 統一されたセキュリティの担保 オンプレミスにて監視基盤を構築する場合、多くの設定項目やセキュリティポリシーの統一化や統合は困難です。 AWS Outposts サーバーは、EC2インスタンスへのIAMロール設定やセキュリティグループの設定により、統一されたセキュリティポリシー設計ができます。 加えて、AWS Outposts サーバーはハードウェアまで含めてマネージドなサービスであるため、セキュリティアップデートなどもAWS Outposts サーバーのユーザー側で実施する必要はありません。 またこれらの設定はAWSコンソールやawsコマンド経由で統合的に管理が可能であるため、拠点が多くなった場合も自動化が可能となり、ヒューマンエラーの低減にも繋がります。 まとめ 本記事ではInterop Tokyo 2024のShowNetと連携したAWS Outposts サーバーを用いた5Gメトリクス監視の構成について紹介しました。 今後は更なる自動化を目指すと共にリアルタイム分析のフィードバックやエッジにAIの処理を組み込む検討をしつつ、サービスへの応用について検討していきます。 https://docs.aws.amazon.com/outposts/latest/server-userguide/local-network-interface.html ↩

何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていない――。 この記事では、そうした 組織が記憶喪失になる ことにどう対処していけばよいか、NTT Comの技術顧問である吉羽龍太郎 ( @ryuzee ) さんにふらっと相談してみたら一瞬で突破口が見つかった＆話に奥行きが出た話を共有します。 目次 目次 軽く自己紹介 事の発端 ryuzeeさんの油セール 実際に聞いてみた 新たなる概念：ADR ADRの実践：その1 何を書くか ADRの実践：その2 どこに書くか ADRの実践：その3 どう書くか 相談を受けて試しに書いてみたADR まとめ 軽く自己紹介 イノベーションセンターの小林 ( @ppyv ) です。 開発・検証用PCの開発 に一段落つけた後、社会人学生としてたっぷり2年間学習を積んでいました。 いまはイノベーションセンターで働く社員のみなさんに、よりよく働ける環境を提供するための仕事をしています。 事の発端 最近、同じチームで働いているmahitoからこんな質問がありました。 なんでこのアプリケーションは社内プラットフォームとしてモバイル対応していないんだっけ？ 他の組織から、してないならしてない理由があるんですよねって言われたので その理由はSlackの過去ログを遡って確認できたものの、こうした ちょっとした経緯を調べること に対して30分以上にわたる議論が巻き起こってしまいました。 正直言ってもったいない時間ですし、調べがつくうちはまだいいものの どこを調べたらいいか分からない とか、そもそも 間違った経緯が「発見」される 恐れもあります。 ではどうやってその経緯を記録しておくのがいいのか、との積年の疑問がここで再度噴出したため、ryuzeeさんに相談しに行くことにしました。 ryuzeeさんの油セール NTT Comの技術顧問でありアジャイルコーチでもあるryuzeeさんは、毎週火曜日をNTT Com向けの支援日として空けてくださっています。 特に社員からのアポイントメントがなければ、「油セール」と称してNTT ComのオンラインコミュニケーションツールであるNeWorkにおいでくださいます。 実際に聞いてみた その機会を使ってさっそく質問してみることにしました。 新たなる概念：ADR 小林）……とこういうエピソードがあって、自分は「組織が記憶喪失になる」と呼んでいるんですが、ほかではどうなんでしょうかね。 ryuzee) それはめっちゃあるあるですね。どこ行っても悩んでいると思います。 ただこの問題に対しては、ソフトウェア開発で使われている ADR: Architectural Decision Records っていう手法が役に立つと思います。 ジャブを打ったらいきなりストレート＝新しいキーワードが飛んできました。 ここでADRについて、GitHubのorganization "ADR" がメンテナンスしているサイト adr.github.io から語釈を引きます。 An Architectural Decision (AD) is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture and quality. An Architectural Decision Record (ADR) captures a single AD and its rationale; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM), but ADR usage can be extended to design and other decisions (“any decision record”). （拙訳）アーキテクチャ上の決定 (AD) とは、アーキテクチャ的に重要な機能要件または非機能要件に対処する、合理的なソフトウェア設計上の選択のことです。 アーキテクチャ的に重要な要件 (ASR) とは、ソフトウェアシステムのアーキテクチャと質に大きな影響を与える要件のことです。 アーキテクチャ決定記録 (ADR) は、単一のADとその理論的根拠を記録するためのものです。プロジェクトで作成・維持されるADRの集合は、意思決定のログを構成します。 これらはすべてアーキテクチャナレッジマネジメント (AKM) に含まれる話題ですが、ADRはany decision recordすなわちあらゆる決定の記録として、設計やそのほかの決定にも応用できます。 平たく言ってしまえば、 アーキテクチャ上重要な決定そのもの と、 どういう理由があってその決定をしたのかをまとめた記録 が ADR ということになります。 悩みに対するずばりの回答が10秒で返ってきて面食らいました。 ADRの実践：その1 何を書くか そしてADRの簡単な説明を受けて、思い出したのがこの話でした。 小林）これってコードコメントとかコミットログにはWhyを書けっていうのと同じですか？ ryuzee) あーまさにそうです。HOWはコード見れば分かるので、なんでそれを書いたの？というのを残しておく必要がありますね。 ソフトウェアエンジニアの方は、コードコメントの書き方について指導を受けたことはありませんか？ やってしまいがちなコードコメントとして 何が起きているかを書く というのがありますが、何が起きるかはコードを読めば理解できるので、一般にはコメントとして適当でないとされます。 代わりに、 なぜそのコードにしたのか であるとか、一見して意味・目的がわかりにくいロジックを解説するコメントを書くべきと言われます。 それとこの話は似た構造をしています。 ADRの実践：その2 どこに書くか 次に、ADRを書くにしてもどこに書いておくべきかの話になりました。 ryuzee) ソフトウェア開発に関係していれば、GitHubでいうところのpull request (PR) にWhyを書くのは合理的です。 あとはWebサービス系の会社が規程とかの管理をGitHubで行っている例がありますが、親和性が高いやり方だと思います。 その変更をするに至った背景、なぜ必要と思った、などなど書くべきとされることは会社によってさまざま考えられますが、そういったことをPRに書いておく。 そしてADRのテンプレートを作ってしまえばある程度定型にできるので、ADRテンプレートを満たしていないPRは突っ返すといった対応も容易です。 小林）確かにバージョン管理システムを使えば、変化したところを起点にどのコミットで編集されたかは即座に分かりますね。 ではソフトウェアや、プレーンテキストでなんとかできるものに関連しない分野だとどうしましょう？ ryuzee) 身も蓋もないですが、やっぱりどこかにまとめて書き残しておくしかないです。 ADRを書く先としては、簡単に書けることと簡単に検索できること、この2点を満たすことがとても重要です。 これらのいずれかが欠けるとうまく行きません。 書いてなければ探せないですし、探せなければ書いていないのと同じなので、結果として問題を蒸し返したり、過去の経験をリスペクトしない決定をしてしまったりする。 適切なところはプロジェクトによってさまざまだと思いますので、まずチームでやり方を合意してやってみるのがいいと思います。 アンチパターンとして、例えばこれをWordファイルでやってしまうと書き始めるまでのハードルが高いですし、書いたファイルが散逸しやすい問題があります。 そういった点は注意した方がいいですね。 それからADRが書きつけてあるファイルの保存先が複数箇所になると、これもうまくいきません。結局検索性がないのと同じになってしまいます。 2カ所以上を探すのは大変です。 その点やはりPRは合理的だと思います。自動的に一カ所に固まりますから。 記憶喪失にもバージョン管理システムの力を借りるのがいいのではないかと思います。 Slackの「地層」を探しに行って考古学者になったり、あっちもこっちもと掘り返したりしていると骨が折れます。 「ここを見ればわかる」状態にしておくのが大事だと感じました。 ADRの実践：その3 どう書くか ではどうやってADRを書き始めるか、その点も尋ねてみました。 小林）ではどうやってADRを書き始めたらいいでしょうか。 ryuzee) 例えば今日のこの相談をADRに起こすことを考えるとしましょう。 それなら、「なぜこの話をここに持ち込もうとしたか」をアウトプットするのが重要になります。 小林）確かに今日ここまで会話した内容はすべてHowの話で、Whyの話ではないですね。 なぜと言われると、「なんとなくryuzeeさんならなんか知ってそうだったから」となってしまいますが（笑 ryuzee) よく「Issueから始めろ、Howから始めるな」といいます。 実はHowに詳しい人っていっぱいいるんですよ。だけど、その人が直面しているIssueに詳しい人って、そんなにたくさんはいません。 なんならその人が一番詳しいかもしれない。 なんらかまず書いてみるのをおすすめします。 試してみて振り返って、それでいける or いけないを見るのは王道パターンですよね。 最後の話は目からうろこでした。問題解決なのだからHowを考えるのは当たり前だと思っていましたが、確かにIssueがあるからHowを考えているわけです。 今回で言えば、組織が記憶喪失になってしまうことがIssueなわけで、それに対する一つのHowがADRだといえます。 相談を受けて試しに書いてみたADR アドバイスを受けて、さっそくこの相談をADRにしてみることにしました。 例えば次のようになるでしょう。 タイトル： エンジニアリング組織を運営するための知恵が必要な際の問い合わせ先 背景： 次の通り 「何か決定した事実」は残るが「なぜそう決定したか」の記録が損なわれる事象が連続して発生し、これを仕組みで防止するための手段が何かあるのではと考えた こういった話はryuzeeさんが最も詳しいと思われた（開発組織を動かすプロセスに関するスライドや、発表を見聞きしていたため） 油セールがあるために、ふらっと会話しやすいと思われた もし人違いなら他の人に転送してくれるだろうと思われた 当初課題への対策としてADRを提示してもらえた 決定： まずryuzeeさんに相談し、なんらか回答いただくか、適切な転送先を指南してもらう 状態： 運用中。ryuzeeさんへの相談がしづらい状況（一例として、油セールの中止、技術顧問からの引退）になった際は更新を要する。 これは非常にシンプルな例ですが、もっと込み入った内容を記録しておくことももちろんできます。 こちらのリポジトリでADRのテンプレートがいくつか紹介されており、ほかにどんな項目を書いておくべきか参考になります。 例えば自らのプロジェクトに適用するADRテンプレートをこれらを参考に作ったとして、 その制作経緯・過程をADRとして記録しておくのもよさそうです。 まとめ 同僚のmahitoは、千葉市動物公園に長いこと肉食獣が存在しなかったことに実は理由がなかったことを引き合いに、今回の話を関連付けて次のように述べています。 定期的に見直す話 なぜこうなってるかが残されておらず、現状から誤った類推がされてきたが、調べると理由などなかったと。 組織にもこういう事が多くあり、どうすればという話を @ryuzee さんに先日したら、Architectural Decision Records という話を教えてもらった。 https://t.co/6qMtNRQOBC https://t.co/mUHQKD8pKf — Mahito / まひと (@Mahito) 2024年2月1日 人々の意識に浸透したものは放っておいても残りますが、なぜそうなったかが記録されていないと振り返りもできなければ旧弊を振り切って先へ進むことも難しくなります。 私見では、こうしたルールはできればプロジェクトの最初に、コミュニケーションルールの一環として決められるとよさそうに感じました。 みなさんのプロジェクトでも、この記事がなんらかの参考になれば幸いです。

こんにちは、クラウド&ネットワークサービス部の 福岡 です。 SDPF（Smart Data Platform） クラウドの IaaS である、 ベアメタルサーバー ・ ハイパーバイザーサービス 開発のソフトウェアエンジニアとして働いています。 本記事では、リリースプロセスの改善を目指して QA チームが実施している試験の一部を自動化したことで、チームの底力が爆上がりした事例について紹介します。 SDPF ベアメタルサーバーサービスのミッション 機能リリースまでの流れと課題 課題1: 価値提供までのリードタイムが長くなる 課題2: QA チームの稼働がひっ迫する QA 削減に向けた取り組み 〜自動テストによる代替〜 思いがけない困難 どうやってこの困難に立ち向かったのか 1. 締切のあるタスクと締切のないタスクをセットにして取り組む 2. チームでサービス説明書の読み合わせ会を実施 取り組みの成果 1. QA の稼働削減 2. ソフトウェアの品質向上 3. セキュリティ向上 うれしい副次的効果 〜スキルの底上げ〜 1. サービス仕様の理解が向上 2. QA 試験項目の理解が向上 まとめ SDPF ベアメタルサーバーサービスのミッション ベアメタルサーバーサービス は、NTT コミュニケーションズが提供している Smart Data Platform におけるクラウド/サーバーメニューの1つです。 このサービスは OS インストール済みの物理サーバー（ベアメタルサーバー）をオンデマンドに提供するサービスです。 ユーザーは、物理サーバーのスペック、OS の種類などの情報をポータルの画面から指定することで、数十分後に諸々の設定が完了した物理サーバーにリモートでアクセスできるようになります。 このベアメタルサーバーサービスですが、開発の重要なミッションの1つとして 「最新の OS / ハードウェアの継続提供」 があります。 例えば、我々は物理サーバーにインストールできる OS として Red Hat Enterprise Linux (RHEL) を提供していますが、定期的に公開される RHEL の最新バージョンに可能な限り早く追従することを目指しています。 機能リリースまでの流れと課題 ベアメタルサーバーサービスの機能リリースは以下の流れで行なっています。 IaaS という、小さな不具合が大きな損害に繋がりかねないサービスを提供している以上、個々のプロセスは不可欠なものなのですが、 機能開発が完了してから商用環境にリリースしてユーザーに価値を提供できるようになるまで、およそ3ヶ月ほどかかってしまっているのが現状です。 その中でも大きな割合を占めるのが QA チームによる QA (品質保証) でした。 ベアメタルサーバーサービスでは、リリースまでにかかる QA の期間の長さが原因で、以下のような 2 つの課題が生じていました。 課題1: 価値提供までのリードタイムが長くなる 当たり前の話なのですが、機能開発が完了してからユーザーに価値を提供できるようになるまでのリードタイムが長くなります。 先ほど述べたように、我々のミッションは最新の OS を「可能な限り早く」提供することなので、この問題は致命的です。 課題2: QA チームの稼働がひっ迫する QA チームは我々以外のチームの QA を兼任しているため、慢性的に稼働が足りない状況になりがちです。 我々が依頼する QA の期間が長くなってしまうと QA チームの稼働がひっ迫し、本当に QA が必要なところで QA の稼働が取れず、SDPF 全体の開発が停滞することに繋がります。 QA 削減に向けた取り組み 〜自動テストによる代替〜 これらの課題を解決するため、QA チームに実施してもらっている試験項目を精査し、 自動テスト で代替することを考えました。 QA の試験項目には以下のようにさまざまな項目がありました。 サーバー作成が正常に行われること 作成されたサーバーの設定が想定通りであること GUI の表示が想定通りであること 課金が正しくできること etc... これらの項目のうち、CLI で実装可能である 「サーバー作成が正常に行われること」「作成されたサーバーの設定が想定通りであること」 の2つにスコープを絞れば、QA を自動テストで代替できるのではないかと考えました。 実装イメージは、 Serverspec 等を利用した下記のようなものであり、 提供している OS (VMware ESXi, RHEL, Windows 等、細かいバージョン違いを含めておよそ 20 パターンほど) 全てを対象とする想定でした。 # Chronyの起動と有効化をテスト describe service( ' chronyd ' ) do it { should be_running } it { should be_enabled } end # NTPの停止と無効化をテスト describe service( ' ntpd ' ) do it { should_not be_running } it { should_not be_enabled } end # clond-initのインストール状況とバージョンをテスト describe command( ' cloud-init --version ' ) do its( :stdout ) { should match( / cloud-init 22 \. 1-9 \. el9 / ) } end ... 思いがけない困難 しかし、この取り組みですが、計画したはいいものの一向に進む気配がありませんでした。 OS インストール後のサーバーの状態を試験するという特性上、自動化に工夫 1 が必要になること、および、OS の種類が 20 種類と多く実装稼働がかかることも理由の1つでしたが、それ以外にもっと大きな原因がありました。 それは 「網羅性が低く、かつ、メンテナンスされていない自動テストがすでにそこそこ存在していたこと」 です。 既存のコードの保守改修をしている方は共感していただけるかと思うのですが、このような自動テストを網羅性がある完全なものにするのは、大事な作業ではあるものの、創造性があまりなく面白味にかけます。 すでに存在していることが、逆にモチベーションを阻害します。 また、実装が完成したとしても 「コードレビューが滞りがちになってしまう」 という問題もありました。 これは、今回の自動テストの再実装においては、レビュアーは実装されたものが「網羅性のある完全なテスト」であることを逐一確認する必要があるため、レビュアーの負荷が高くなってしまうことが原因でした。 さらに、 「日々締切のある機能開発に追われている状況」 であったことも相まって、この自動テストの再実装はやらなくても直近で問題がないタスクとして後回しになってしまいました。 どうやってこの困難に立ち向かったのか なんとかしてこの取り組みを推し進めるために、主に2つの工夫を取り入れました。 1. 締切のあるタスクと締切のないタスクをセットにして取り組む 1つめの工夫は、自動テストの再実装をそれ単体のタスクして扱うのではなく、新バージョン OS メニューの開発タスクとをセットで実施するようにしたことです。 例えば RHEL 9.2 メニューの新規開発をするときには、同時に RHEL に関する自動テストを過去バージョンを含めて全て実装し直すことにしました。 新バージョンの OS メニュー開発という締切があるタスクと、自動テストの再実装という締切のないタスクをセットにして実施することによって、インクリメンタルに無理なくこれまでの開発サイクルに組み込むような形で、自動テストの再実装を推し進めることができました。 2. チームでサービス説明書の読み合わせ会を実施 サービス説明書（サビ説）とは、我々が提供するサービスで満たすべき要件が記載されている文書です。 自動テストの実装およびレビューは、この文書をベースにして網羅的かつ正確に行う必要があります。 ただ、文言が全体的に固かったり、OS に関する事前知識が必要だったりと、少しとっつきにくいところがあります。 自動テストのレビューが滞る要因の1つに、レビュアーのサビ説を把握する手間があるのではないかと考え、 事前に自動テストの実装に必要なサービス説明書の読み合わせ会をチーム全体で開催することにしました。 この読み合わせ会の開催によって自動テストで実装すべき内容を強制的にインプットする機会を作ることで、実装後のレビューのコストを下げることができました。 取り組みの成果 自動テストの再実装により QA の短縮およびリリースプロセスの改善が達成できたことで、具体的に以下のような恩恵が得られることになりました。 1. QA の稼働削減 単純計算で、単一の OS あたり 20 時間/人ほどの稼働の削減になりました。 我々はおよそ 20 パターンの OS を提供しているため、 リリースごとに 400 時間/人ほど の稼働の削減ができたことになりました。 2. ソフトウェアの品質向上 先ほどおよそ 20 パターンほどの OS を提供していると述べましたが、QA チームの稼働には限りがあるため、実際のところは重要度の高い OS のみを対象にした QA しかできていませんでした。 それ以外の OS については QA を省略してリリースするということが半ば慣習化 しており、過去にそれが原因でトラブルを発生させてしまったこともありました。 しかし今回の取り組みによって、 全ての OS パターンについての網羅的な試験 を自動テストとして実行できるようになったため、ソフトウェアの品質向上に繋がりました。 3. セキュリティ向上 自動テストの実装により、QA チームの作業期間の短縮ができたので、 短いリードタイムでユーザーに最新の OS メニューの提供ができるようになりました。 これにより、脆弱性対応等の OS のマイナーバージョンのアップデート等の軽微な修正であっても、OS をその都度リリースする選択肢が生まれたため、結果的にセキュリティの向上に繋がりました。 うれしい副次的効果 〜スキルの底上げ〜 元々意図したものではなかったのですが、この取り組みを通して、経験の浅いメンバーを含めた開発メンバー全員のスキルの底上げが実現できました。 1. サービス仕様の理解が向上 ベアメタルサーバーサービスは巨大なサービス 2 であるため、経験が浅いメンバーは 「改修で触ったことがある部分はわかるけれど、それ以外の部分はさっぱり」「実装を断片的に読んだことはあるけど仕様はよく覚えていない」 となりがちでした。 今回の取り組みを通して、開発メンバー全員が一通りサビ説の内容が頭に入っている状態にまで持っていくことができました。 特に経験が長いメンバーに偏りがちな 「サービス仕様に関わる問い合わせ対応」 を全員で分担してできるようになったのは大きな成長でした。 2. QA 試験項目の理解が向上 今回の取り組み前は、試験項目のリストアップを QA チームにやってもらっているのをいいことに、 多くの開発メンバーは試験項目に対して興味が薄い状況でした。 恥ずかしながら 「細かいことはあまり把握していないものの、最終的に不具合があったら QA チームによって指摘されるから問題ない」 という意識で開発を進めていることが多々ありました。 しかし今回の取り組みを通して、QA の試験項目のうち「どこが自動化可能なのか」を真剣にチームで議論したことによって、具体的に何を QA で見てもらっているのかについての理解が向上しました。 その結果、「ここは開発のユニットテストでカバーしていて、ここの GUI との結合部分（or 課金部分）はQA チームに見てもらうことになる」というように、個々の機能について最終的にどこで動作確認をするのか、ということを常に意識した 堅実な開発 ができるようになりました。 まとめ 以下が本記事のまとめとなります。 ベアメタルサーバーサービスではリリースプロセスにおいて時間のかかる QA が課題であった OS インストール後のサーバーの状態を確認する自動テストの再実装をして、QA のプロセスを一部短縮 優先度が低くなりがちな自動テストの再実装を推し進めるために、以下の工夫を導入 締切有りのタスクと締切無しのタスクをセットで行う レビュー負荷の軽減を目的としたサービス説明書の読み合わせ会を実施 結果的にリリースプロセスの改善だけではなく、開発メンバー全員のスキルの底上げを実現 最後になりますが、SDPF クラウドは国内最大級のクラウドサービスです。 開発メンバーは、数千台以上の物理サーバーの操作の自動化をはじめとした、技術的難易度の高い課題に取り組みつつ、日々より良いサービスにしようと邁進しております。 直近ではベアメタルサーバー・ハイパーバイザーチームは「 B26.大規模国産クラウドを支える IaaS (ベアメタルサーバー/ハイパーバイザー) のソフトウェア開発 」というポストで現場受け入れ型インターンシップの募集をしています。 本記事に興味を持った学生の方は是非奮ってご応募ください。 例えば、実行環境ごとに異なるネットワークの設定やライセンス認証まわりの差分吸収や、ハードウェアごとに異なるストレージ周りの差分吸収などの工夫が必要になりました。 ↩ 具体的には、ソースコード行数が 50 万行以上、管理 VM 数が 1000 以上、管理物理サーバー数が数千台以上、といったところです。 ↩

NTTコミュニケーションズ（以下、NTT Com）を含めたドコモグループでは、この夏に サマーインターンシップ2024 を開催します！ この記事では、その中でも NTT Com のリアルな業務を体験できる「 現場受け入れ型インターンシップ 」について紹介します。 現場受け入れ型インターンシップとは 募集ポスト これまでのインターンシップの様子 AI分野 セキュリティ分野 ネットワーク分野 ソフトウェア/クラウド分野 まとめ 現場受け入れ型インターンシップとは NTTドコモや NTT Com の社員と一緒に働きながら、実務を体験していただくインターンシップです。 エンジニアやセールス、ビジネスデザイン、リーガルなど幅広いワークフィールドを取り揃えて、業務体験を通じて仕事の理解を深め、成長機会を提供する内容となっています。 今季は 2024年8月26日（月）～9月6日（金）の土日祝日を除く10日間（2週間） で開催されます。開催場所は、出社＋リモートワークのハイブリッド形式です（出社割合はポストにより異なります）。 募集ポスト 各ワークフィールドの募集ポストについては、ワークフィールドごとのポスト情報をご覧ください。 地域エリア [PDF] ソリューションエンジニア [PDF] プロダクト・サービスエンジニア [PDF] AIエンジニア・データサイエンティスト [PDF] セキュリティエンジニア [PDF] ネットワーク・インフラエンジニア [PDF] 6G・IOWNエンジニア [PDF] セールス [PDF] ビジネスデザイン [PDF] リーガル [PDF] 記載されているポストのうち、受け入れ会社に NTTコミュニケーションズ と記載されたポストが NTT Com での業務です。 これまでのインターンシップの様子 NTT Com のエンジニア系ポストに参加した学生の方々が、これまで開催したインターンシップの体験記をこの NTT Communications Engineers' Blog に寄稿してくれています。 「インターンシップでどんなことに取り組むのだろう？」、「インターンシップを通して何が学べるのだろう？」といった疑問を解消する手助けになれば幸いです。 AI分野 インターンシップでマルチA100 GPUサーバをぶん回してみた - NTT Communications Engineers' Blog （2022年・冬） セキュリティ分野 セキュリティ技術開発のインターンシップに参加させていただきました!! - NTT Communications Engineers' Blog （2021年・夏） インターンシップ体験記 〜セキュリティ運用の健全化を目指すMetemcyberの開発〜 - NTT Communications Engineers' Blog （2022年・冬） インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 - NTT Communications Engineers' Blog （2023年・冬） インターンシップ生があるSaaSを用いた未知のC2脅威を実証してみた - NTT Communications Engineers' Blog （2023年・冬） 攻撃者はいかにしてフィッシングサイトを隠すか？（インターンシップ体験記） - NTT Communications Engineers' Blog （2023年・夏） Pool Partyという攻撃手法を通じてWindowsの深淵を覗いた７日間（インターンシップ体験記） - NTT Communications Engineers' Blog （2024年・冬） フィッシングキットから生成されたサイトの調査 (インターンシップ体験記) - NTT Communications Engineers' Blog （2024年・冬） ネットワーク分野 ネットワーク知識ゼロの大学院生が、NTTコミュニケーションズのインターンシップに参加してみた - NTT Communications Engineers' Blog （2021年・夏） インターンシップ体験記 〜BGP-LSの機能をFRRに実装してみた〜 - NTT Communications Engineers' Blog （2022年・冬） インターンシップ体験記 〜SRv6 L3VPN機能検証〜 - NTT Communications Engineers' Blog （2022年・冬） インターンシップ体験記 〜SR-MPLS IPv6 Underlay 相互接続検証〜 - NTT Communications Engineers' Blog （2023年・冬） インターンシップ体験記 〜SRv6 機能を Pola PCE に実装してみた〜 - NTT Communications Engineers' Blog （2023年・冬） SRv6/SR-MPLS相互接続を実現するための機能をFRRに実装してみた（インターンシップ体験記） - NTT Communications Engineers' Blog （2024年・冬） ソフトウェア/クラウド分野 IoT Connect Gatewayを使ってみた 番外編 ～インターンシップでリリース前の機能を使って開発してみた～ - NTT Communications Engineers' Blog （2021年・夏） IoT Connect Gatewayを使ってみた 番外編 第2回 ～インターンシップでStorage転送機能を使って開発してみた～ - NTT Communications Engineers' Blog （2022年・冬） テレプレゼンスPJ インターン参加レポート - NTT Communications Engineers' Blog （2022年・冬） インターンシップ体験記 〜SDNコントローラの性能改善〜 - NTT Communications Engineers' Blog （2023年・冬） インターン参加記 ～GPUクラスタ管理者への道～ - NTT Communications Engineers' Blog （2023年・冬） TypeScript未経験の学生がSkyWayの開発に取り組んでみた（インターンシップ体験記） - NTT Communications Engineers' Blog （2023年・夏） データプレーンに起きたバグにパッチを当ててみた（インターンシップ体験記） - NTT Communications Engineers' Blog （2023年・夏） パケット爆発を解析してみた（インターンシップ体験記） - NTT Communications Engineers' Blog （2024年・冬） なお、NTT Com のデザイン系ポスト（KOEL）については KOEL公式note 、NTTドコモのエンジニア系ポストについては ドコモ開発者ブログ をご覧ください。 まとめ みなさんもこの夏、ドコモグループのインターンシップに参加して興味分野で熱い夏を過ごしてみませんか？ 気になる開催概要とポスト情報はこちらです（再掲）。 現場受け入れ型インターンシップ エントリーはこちらです。 ドコモグループ マイページ エントリーシートの提出締め切りは 2024年6月21日（金）23:59 です。 なお、今年度は 冬の現場受け入れ型インターンシップは予定されていません 。 興味のある方は、ぜひ夏のインターンシップをご検討ください。 みなさんのご応募をお待ちしています！

この記事では、Ruby の非同期処理ライブラリである Sidekiq を使って定期実行処理を行う Sidekiq-Cron の監視方法について、チームでの方式検討の様子を交えながらご紹介します。 目次 目次 はじめに Sidekiq-Cron について Sidekiq-Cron の cron job の status の監視 既存の status 監視の問題点 既存の監視の仕組みの問題点 負荷が低い監視の仕組みの検討 案1：全 cron job の status を定期的にダンプし、ダンプ結果を読み取って監視する 案2：Redis を直接参照して cron job の status を読み取る 案3：Sidekiq の GUI の html ページの内容をパースして status を取得 [採用] 案4：Sidekiq の GUI に新しいエンドポイントを実装して、そのエンドポイントから status を取得 案5：そもそも複数の cron job の status を監視するのをやめる さいごに 参考 はじめに こんにちは、クラウド & ネットワークサービス部で SDPF のベアメタルサーバー 1 ・ハイパーバイザー 2 の開発をしている山中です。 私のチームでは Ruby でサービスを開発しています。 API リクエスト受付など、さまざまな処理を gem を利用しながら実装しており、中でも定期実行処理は Sidekiq-Cron という gem を利用して実現しています。 先日チームで Sidekiq-Cron の監視の実装について議論している最中、チームメンバーから巧いと言われた実装がありました。 今回の記事では、実装内容を簡単に紹介しながら、普段チームでどういった観点で実装の方式を検討しているかご紹介したいと思います。 Sidekiq-Cron について Rails でもよく使用されている Sidekiq という非同期処理ライブラリを使って、定期実行を可能とする gem です。 定期実行処理は cron job という単位で定義でき、cron job ごとに status を enabled / disabled に設定することも可能となっています。 Sidekiq では、メインであるジョブを処理するプロセスの他に GUI のプロセスも起動でき、Sidekiq-Cron を導入すると以下のように GUI にもページが増え、cron job ごとの status や実行状況などを確認できるようになります。 Sidekiq-Cron の cron job の status の監視 私たちが運用しているサービスでは、各 cron job の status は全て enabled であることが期待値です。disabled があるとサービス影響につながる場合があります。 一方、cron job の status はメンテナンス作業の中で一時的に disabled に変更されることがあり、メンテナンス作業後は status を enabled に戻さなければいけません。 しかし、メンテナンスは人間が行う作業というのもあり、enabled に戻し忘れてしまうという問題が時折発生していました。 私達のチームではこの問題への対策として、enabled に戻し忘れたことに気付けるように一定間隔で status を取得し、enabled ではない場合にアラートを上げるような監視の仕組みも作っています。 既存の status 監視の問題点 この監視の仕組みですが、1つ問題が存在していました。それは1番重要な1つの cron job しか status を監視していなかったという問題です。 この問題により、監視対象ではない cron job の status が長期間 disabled になっていることに気付けなかったという問題が先日発生してしまいました。 振り返りの結果、全て（16個）の cron job の status を監視しようとチームで合意し、実装方式の検討が始まりました。 既存の監視の仕組みの問題点 既存の status 監視では、以下のような Ruby スクリプトを実行して status を取得しています。 （本筋から外れるので説明は割愛しますが、 Consul を使用してスクリプトを定期的に実行しています。） # cron job 名を引数に渡して実行することで status を取得 require ' sidekiq-cron ' < Sidekiq を Redis に接続する記述> job = Sidekiq :: Cron :: Job .find( ARGV [ 0 ]) if job.present? puts job.status else puts "#{ ARGV [ 0 ] } does not exist in cron jobs " exit 1 end 当初は 16個の cron job それぞれについてスクリプトを実行し、それぞれの cron job の status を取得すれば良いと考えていました。 ところが、スクリプト実行時の負荷を計測した結果、16個並列でスクリプトを実行すると CPU 使用率が 75% 以上に高騰してしまうことが判明してしまいました。 status 取得自体の負荷は軽いのですが、Ruby プロセスを起動してライブラリのロードをする部分の負荷が高く、既存の監視スクリプトを安直に16個並列で実行するのはやめようという流れになりました。 負荷が低い監視の仕組みの検討 結論から述べると、最終的にチームで合意したのは以下の案4です。 メンテナンス性や心理的な受け入れやすさ、動作の軽量さなどを考慮した結果、この案を採用することになりました。 ここでは各案の内容と、実際にチームで議論したときに上げられたメリット・デメリットを簡単に紹介します。 案1：全 cron job の status を定期的にダンプし、ダンプ結果を読み取って監視する 1回の Ruby スクリプトの実行で全ての cron job の status を取得してファイルにダンプし、各 cron job の監視ではダンプファイルを読み取って status を取得して監視をするという案です。 メリット 負荷が高い Ruby プロセスの起動やライブラリのロード部分を1回に集約することで負荷の軽減が可能 デメリット cron job の status をダンプする処理を別途実装する必要がある 厳密に現在の cron job の status を取得できるわけではない 仕組みとしてややこしい感が強い 案2：Redis を直接参照して cron job の status を読み取る Sidekiq は Redis にデータを書き込んでいるため、Redis に書き込まれている cron job の status を以下のように redis-cli コマンドで直接取得するというアイデアです。 redis-cli -a <password> -h <redis_address> hget <application_name>:cron_job:<cron_job_name> status メリット Ruby を使用しないため動作が軽い デメリット Sidekiq がラップしている部分（Sidekiq の利用者が本来意識しなくて良い Redis の中身の部分）を意識する必要がある 深いところを直接触りすぎている感がある 案3：Sidekiq の GUI の html ページの内容をパースして status を取得 最初に紹介したように Sidekiq には cron job の status を確認できる GUI が存在します。 以下のように curl で GUI の html ページを取得し、取得結果をパースして status を取得するというアイデアです。 curl -ks -u <user> :< pass> http :/ /<sidekiq_gui_address> / cron / <cron_job_name> | grep -o - E ' enabled|disabled ' メリット Ruby プロセスを新規に起動しないため動作が軽い GUI サーバとして既に起動している Ruby プロセスを利用することで、負荷が高い Ruby プロセスの起動やライブラリのロードを行わなくて済む デメリット html ページのパースは仕組みとして頑健ではない、強引に欲しい値を取得している感がある html ページがパースされることは Sidekiq の作者も想定していないはず Sidekiq のバージョンアップなどによって html ページの構造が変わったときに、値のパースができず監視の仕組みも動かなくなる恐れがある [採用] 案4：Sidekiq の GUI に新しいエンドポイントを実装して、そのエンドポイントから status を取得 cron job の status を取得する GUI のエンドポイントを Ruby のクラス拡張で新規に実装し、実装したエンドポイントから status を取得するというアイデアです。 Sidekiq に GUI があるということは「 各ページを表示するためのエンドポイントの実装があるはず 」というところに着目し、その実装を拡張すれば良いのではないかという流れでこのアイデアを思いつきました。 以下のように Sidkiq の GUI を起動するためのコードを実装し、新しいエンドポイントを実装します。 require ' sidekiq-cron ' < Sidekiq を Redis に接続する記述> use Rack :: Session :: Cookie , secret : SecureRandom .hex( 32 ), same_site : true , max_age : 86_400 module CustomWebExtension def self . registered (app) app.get ' /cron/:name/status ' do @job = Sidekiq :: Cron :: Job .find(route_params[ :name ]) if @job .present? @job .status else "#{ route_params[ :name ] } does not exist in cron jobs. " end end end end Sidekiq :: Web .register CustomWebExtension run Sidekiq :: Web .new メリット 案3と同じく Ruby プロセスを新規に起動しないため動作が軽い html ページという本来パースして値を取得するためのものではない所から欲しい値を取得しているわけではないため、案3よりも強引感がない クラス構造は html ページの構造よりも変化しづらいはずなので、案3 よりも頑健なはず デメリット Sidekiq のライブラリ構造が変わることで、将来的に動作しなくなる可能性がある 基本的にクラス拡張は避けた方が良い 案5：そもそも複数の cron job の status を監視するのをやめる うまく実装できる案が無いのであれば、現状を維持し、問題に遭遇するリスクを許容するという案です。 言わば戦略的撤退ような案ですが、他の議論でも時折このような案を採用することがあります。 さいごに いかがでしたでしょうか？ チームで実装方式について議論するときは、頭を柔らかくして複数の案を考え出し、あえて採用されないであろう案も提示し、その中から現状の最適解を選ぶことで、チーム全員の納得感を高めています。 口頭で話すだけだと各案のデメリットばかりに着目してしまい、議論がなかなか進みませんが、メリット・デメリットを書き下して共有しながら議論を進めることで冷静に各案を比較でき、円滑に議論を進められます。 また、今回採用した案のように、既存ライブラリのモジュールを拡張して新たな機能を簡単に追加できるのは、メタプログラミング 3 が得意な Ruby ならではだと思います。 既存ライブラリのモジュールに手を加えると、ライブラリのバージョンアップなどで将来的に動作しなくなる可能性ありますが、多用しなければ非常に強い効果を発揮すると思います。 みなさんもライブラリのコードの深い部分まで読みつつ、ここぞという場面で独自の拡張を入れてみるのはいかがでしょうか？ 最後になりますが、SDPF クラウドは国内最大級のクラウドサービスです。 開発メンバーは、数千台以上の物理サーバーの操作の自動化をはじめとした、技術的難易度の高い課題に取り組みつつ、日々より良いサービスにしようと邁進しています。 今回紹介した監視の実装など、実際にコードの深い部分まで理解したうえで、自分たちで手を動かして実装方式を検討しています。 直近ではベアメタルサーバー・ハイパーバイザーチームは「 B26.大規模国産クラウドを支える IaaS (ベアメタルサーバー/ハイパーバイザー) のソフトウェア開発 」というポストで現場受け入れ型インターンシップの募集をしています。 本記事に興味を持った学生の方は是非奮ってご応募ください。 参考 SDPF ベアメタルサーバー・ハイパーバイザー関連資料 クラウドサービスのウラオモテ SDPF ベアメタルサーバー/ハイパーバイザー開発における GitHub Actions を活用した CI 事例の紹介 専有型の物理サーバーをオンデマンドに利用可能とするサービス。 https://sdpf.ntt.com/services/baremetal-server/ ↩ ベアメタルサーバー上に vSphere ESXi や Hyper-V など代表的なハイパーバイザーを予めセットアップした状態で利用可能とするサービス。 https://sdpf.ntt.com/services/vsphere/ https://sdpf.ntt.com/services/hyper-v/ ↩ プログラミングコードを記述するコードを記述すること、既存の言語を拡張して動的にコードを変更するといった概念 ↩

はじめに こんにちは、インターン生の 鈴木健吾 です。 私は現在修士 2 年生で、学部 4 年生から研究室や WIDE プロジェクト でネットワークの構築・運用に関わったり、Interop や JANOG などのイベントに足を運んだりしています。 このたび、2024 年 2 月に NTT コミュニケーションズで 2 週間の現場受け入れ型インターンシップに参加させていただいたので、その体験談を執筆させていただきます。 目次 はじめに 目次 参加したインターンシップについて 配属されたチームについて インターンシップの課題 インターンシップで取り組んだこと 障害の再現 障害の解析 ネットワーク側の解析 ファイアウォール 側の解析 ファイアウォールの動作がおかしいことの証明 障害の解決確認 まとめ 反省 感想 メンターからのコメント 次回インターンシップのお知らせ 参加したインターンシップについて 配属されたチームについて 私は 「エンタープライズ向け大規模クラウドサービスを支えるネットワーク開発」 というポストで、NTT コミュニケーションズのサービスの 1 つである Smart Data PlatForm (SDPF) クラウドの NFV チームでインターンに参加させていただきました。 SDPF クラウド とは、エンタープライズ向けのクラウドサービスで、「オンプレミスのネットワークをそのまま持ち込める IaaS」を目標にしています。 下の図は SDPF クラウド のアーキテクチャを表しており、 ネットワーク仮想化技術である EVPN-VXLAN によって ハードウェア VTEP 配下のベアメタルサーバ やソフトウェア VTEP (VXLAN Tunnel End Point) 配下の VM などが L2 で連結されることでカスタマーの要望に合わせた柔軟なネットワークの提供を可能にしています。 私の配属された NFV チームは SDPF クラウドのファイアウォールやロードバランサーのサービス開発などを担当しているチームです。 インターンシップの課題 私が今回取り組んだテーマは、このインターンの 3 ヶ月ほど前に実際に発生した 障害対応の追体験 でした。 その障害の内容とは 「パケット爆発」 で、NFV チームがファイアウォールの更改作業をしていた際にマネジメントネットワークで DDoS 検知が作動したことで発覚しました。 この障害について、簡素化された当時の再現環境が用意され、 「マネジメントネットワークで、ファイアウォール VM にパケットを流しながらその VM を消すと、パケットが爆発する」 という情報からその原因解析に取り組みました。 インターンシップで取り組んだこと 私は 2 週間のインターン期間で、大きく次の 3 ステップで課題を進めました。 障害の再現 障害の解析 障害の解決確認 障害の再現 再現環境では下の図のようなネットワークが用意されていました。 図中で FW はユーザに提供されているファイアウォールを表します。FW のマネジメントインターフェースが繋がっているマネジメントネットワーク（mgmt_nw）とバックヤードネットワーク（backyard_nw）の間にはゲートウェイ（GW）があります。 作業の中心となる VM からは GW 越しに FW に ping などを送ることができます。 この状態からマネジメントネットワークに新たな FW-4(IP アドレス 192.168.1.104)を作成し、VM から ping を打ちながら削除すると、ping 出力画面に突然 「Time to Live Exceeded」 の出力が大量に流れるようになり、パケット爆発を再現できました。 障害の解析 ネットワーク側の解析 最初に、このパケット爆発がどのように収束するのかを調べました。 パケットの爆発を確認してから ping を止めたり、再度送信したりすると、次のことがわかりました。 ping を打つのを止めてしばらくすると、再度送信してもパケットは爆発しない ping を打ち続けているとパケット爆発は終了しない ping を打つのを止めてすぐに再度送信すると、パケットは爆発する 次に、 ファイアウォールに流れるパケットを tcpdump でキャプチャすることで、マネジメントネットワークにどのようなパケットが流れているのかを観察しました。 下の図は VM から（削除済みの）FW-4 に ping のパケットを 1 つだけ送信したときの FW-1 でのパケットキャプチャの結果を示しており、全部で約 18 万個のパケットが流れてきたことがわかりました。 このパケットキャプチャの結果を「送信元 MAC アドレス」や「宛先 MAC アドレス」、「TTL」 に注目して解析すると、FV-1~FW-3 は FW-4 の インターフェースの MAC アドレス宛のパケットを受信して、その TTL を 1 減らし、FW-4 宛に転送していることがわかりました。 これにより、パケット爆発のメカニズムが次のように説明できます。 VM から FW-4 に ping を打っている状態で FW-4 が削除されると、マネジメントネットワークの L2 スイッチ機能によって 全ての FW にパケットがフラッディングされる 各 FW に届いたパケットは 各々 FW-4 宛に転送される 転送されたパケットが 1 と同様に他の全ての FW にフラッディングされ、さらに転送される このプロセスがパケットの TTL が 0 になるまで繰り返される ここまでの解析でファイアウォールが自分のインターフェース宛でないパケットを転送してしまうことがパケット爆発の原因であることがわかりました。 ファイアウォール 側の解析 本来、ネットワーク機器は受信パケットを低いレイヤーから処理し、自分のインターフェース宛でないパケットは L2 の段階で破棄（フィルタリング）するはずです。 それでは何故 FW-1~FW-3 は FW-4 のインターフェース宛のパケットをフィルタリングしないのでしょう。 私は最初に、ユーザの設定したファイアウォールの設定に関連するものがないかを調べました。 しかし、MAC アドレスによるフィルタリングを無効にするような設定（例えばプロミスキャスモードを on にするなど）は見つかりませんでした。 困っていると、次のヒントが与えられました。 この障害は開発環境でのテストでは発生しなかった 開発環境と再現環境の設定の違いは ARP の Passive Learning が有効になっていること ARP の Passive Learning とは、受信した GARP(Gratuitous ARP)を ARP テーブルの学習に利用するというもので、GARP はネットワークに接続されたホストが最初に IP アドレスの衝突を回避するために ARP 要求を送信する仕組みです。 しかし、この設定の有無で MAC アドレスのフィルタリングに影響を与えるとは考えられません。 ここで解析が行き詰まり、ネタバラシが入りました。 実は、この障害の原因はユーザの設定起因やクラウドのバグではなく 「ファイアウォールの OS の不具合」 でした。すなわち、「ファイアウォールの動作がそもそもおかしいこと」だったのです。 サービス環境では、受信パケットに対するフィルタリングが機能していないことに加えて、ARP の Passive Learning が有効になっていたファイアウォールではそのパケットを転送する条件も揃っていたため、このパケット爆発という現象に繋がったのです。 ファイアウォールの動作がおかしいことの証明 ここまでの検証から、今回の障害の原因はファイアウォールのアプライアンス OS の不具合にある、ということがわかりました。 したがって、この障害を解決するためにはベンダーにファイアウォールのアプライアンス OS の不具合を示して、修正してもらう必要があります。 しかし、これまでの検証ではベンダーに対してイメージの実装に不具合があると断言することは難しいです。 なぜなら、この検証は複数のホストが存在する複雑な環境で行われており、ファイアウォールにも ARP の Passive Learning などさまざまな設定がされており、それらが今回の障害に関係するかもしれないからです。 もっとシンプルで端的な検証により、不具合を証明する必要があります。 そこで、下の図のような環境を用意しました。 まず、ファイアウォールは 1 つにし、初期設定のままにします。 ARP テーブルは ARP Passive Learning を用いなくても、コマンドを使って自由に操作できるため、GW と FW-1 の ARP テーブルに 192.168.1.104 というネットワーク上に存在しない架空の IP アドレスと、それに対する架空の MAC アドレスのレコードを挿入しました。 この条件で、架空の IP アドレス & MAC アドレス宛のパケットを FW-1 が転送することを確認できれば、予期せぬ動作の原因がイメージ実装の不具合にあると主張できます。 実際に、これまでと同様に VM から 192.168.1.104 へ ping を打つと、全く同じ現象を再現できました。 障害の解決確認 ここまでの検証と問い合わせは、実際に NFV チームがインターン開始前にやっていたことでした。 すでに新しいイメージが出されており、この新しいイメージで先ほどと同様の検証することで不具合が修正されていることを確かめられるはずです。しかしながら、検証の結果、新しいイメージでもパケットの転送が確認されてしまいました。結局完全解決を見る前にインターンは終わってしまいました。 まとめ 反省 今回は 2 週間のインターンシップに参加させていただきましたが、祝日が挟まったり、大雪の影響を受けたりした結果、実際には 6 日にも満たない短期間で課題に取り組むことになりました。 限られた時間の中でしたが、これまで Linux やネットワーク機器に触ってきたことによる慣れや事前知識、トラブルシューティングの経験のおかげでファイアウォールの解析まで約 1 日半とスムーズに進めることができたと思っています。 しかし、これまでネットワークのトラブルは自身の設定ミスだったり仕様の把握が甘かったりが原因であったため、そもそもの OS がおかしいという発想になかなかなれなかったのが悔やまれます。 ファイアウォールの動作がそもそもおかしいことの証明までノーヒントで辿り着くことができれば完璧でした。 感想 本インターンシップに参加する前は NTT コミュニケーションズの SDPF クラウド というサービスを知らなかったのですが、パブリッククラウドサービスを提供しているという国内有数のとても魅力的なチームでした。 私は本インターンシップで初めてビジネスのネットワークの運用・構築を間近で見ることができ、とても貴重な学びを得られたと感じています。 障害当時のチームの対応履歴も拝見させていただき、ビジネスのネットワークではこれまで私の経験してきたただ直すだけのトラブルシューティングとは異なり、カスタマーを第一に考えた対応が求められることがわかりました。 技術的には、これまで度々耳にしていた EVPN-VXLAN をちゃんと勉強できたことや初めて ARP にフォーカスしたトラブルシューティングができたことがとても学びになりました。 私がこれまであまり経験してこなかった冗長化や自動化の重要さも教えていただき、これから勉強していこうと思いました。 課題以外でも、NFV チームの一員として実際のミーティングに参加させていただいたり、チームに関わるさまざまなお話を聞かせていただいたりと NFV チームのリアルを体験でき、とても有意義なインターンシップでした。 また、他のインターン生や社員さんとの交流の場もたくさん用意していただき、とても楽しいインターンシップでした。 最後に、メンターの石井さんをはじめ NFV チームの皆さん、並びに関わっていただいた社員さんやインターン生に皆さん、このインターンシップに参加させていただいたことに感謝を申し上げます。 メンターからのコメント SDPF クラウドで NFV 開発を担当している石井です。鈴木さん、2 週間お疲れ様でした。 天候の影響もあり予定より日程が少なかったですが、交流イベントにも全参加しつつ、業務も効率よく進めていただきました。 さまざまな要因が考えられる事象の解析にチャレンジいただきましたが、持ち前の知識・経験を生かし、発生している事象から原因の切り分けまで我々の想定を超えて素早く進めることができていました。 幅広い技術力と積極性があり、これからもご活躍されることと思います。心より応援しております。 次回インターンシップのお知らせ ドコモグループでは サマーインターンシップ2024 を開催します。 鈴木さんが参加された 現場受け入れ型インターンシップ も下記スケジュールにて開催予定です。 エントリー期間 開催日 6/3（月） ～ 6/21（金） 8/26（月） ～ 9/6（金）　※ 土日除く 本記事に関連するポストは「 B21.エンタープライズ向け大規模クラウドサービスを支える仮想ネットワークソフトウェア開発 」（PDFファイル、22ページに記載）です。 興味を持たれた方はぜひご応募ください。

はじめに こんにちは、ドコモグループのウインターインターンシップ2023に参加した猪飼です。 普段は、大学院でマルウェアの動的解析に関する研究をしています。 「サイバー攻撃の原理を理解し、攻撃インフラ(マルウェアインフラ)を解明するセキュリティアナリスト」のポストに参加させていただきました。 この記事では、私がインターンシップで取り組んだ内容について紹介します。 NA4Secプロジェクトについて まずは、私がお世話になったNA4Secプロジェクトについて紹介します。 正式には「Network Analytics for Security」というNTTコミュニケーションズ イノベーションセンターのプロジェクトであり、通称NA4Sec（なよせ）と呼ばれています。 NA4Secプロジェクトは、「NTTはインターネットを安心・安全にする社会的責務がある」という理念に基づき、攻撃インフラの解明、撲滅の実現を目指して活動しているプロジェクトです。 参加のきっかけ 現場で業務を体験できるインターンシップを調査していた際、過去にドコモグループのインターンシップを体験した方々のブログを発見しました。ブログの内容が非常に興味深く、「このインターンシップはとても面白そうだな」という印象を受けました。 そこから調べていく間に、セキュリティに関する業務を現場で体験できる点に魅力を感じ、「実際に働く雰囲気を体験したい！」と考え応募しました。また、自分が興味を持っている攻撃インフラに関連するポストが存在したことも、応募の決め手でした。 インターンシップ概要 2/5から2/16までの約2週間、プロジェクトメンバーとして業務を体験させていただきました。 業務はオンラインで実施し、 NeWork というオンラインコミュニケーションツールを活用しました。気軽に相談できる環境・雰囲気であったため、非常に働きやすかったです。 インターンシップにて、「サイバー攻撃の原理を理解し、攻撃インフラ(マルウェアインフラ)を解明すること」をテーマに、私は以下のことに取り組みました。 脅威調査 ペネトレーションテストツールであるCobalt Strikeについて調査し、理解する。 脅威分析1 Cobalt Strikeが悪用された攻撃事例を調査し、ダイヤモンドモデルに基づいて分析する。 脅威探索 デバイス検索エンジンであるCensysを使用し、インターネット上に存在するCobalt StrikeのC2サーバを調査する。 脅威検証 攻撃者が、インフラの秘匿に使用するクローキング技術について調査し、サーバに実装する。 脅威分析2 フィッシングについて調査し、フィッシングキットを解析する。 URLスキャンサービスであるurlscan.ioを使用し、フィッシングサイトを調査する。 今回は、「脅威分析2」について紹介したいと思います。 「脅威分析2」以外の内容に関しては、過去にインターンシップに参加された方の記事が公開されているのでそちらをご覧ください 1 　 2 。 脅威分析：フィッシングキットの解析 私は今回、フィッシングキットの解析に取り組み、以下のワークを行いました。 フィッシングについての調査 フィッシングキットについての調査 フィッシングキットの解析 フィッシングサイトの調査 フィッシング詐欺について フィッシング詐欺とは、通販サイトや会員ページのログイン画面を模倣し、利用者にIDやパスワード、カード情報などを入力させ、情報を搾取する犯罪の一種です。 近年では、フィッシング詐欺の件数は年々増加傾向にあります。フィッシング対策協議会によると、2024年1月に報告された件数は、85,827件でした 3 。 フィッシング詐欺の分業化 フィッシング詐欺の件数が増加している背景として、分業化が考えられます。それぞれの工程を担当する業者が分かれることで、フィッシング詐欺の実行が容易になっています。 以下に、各工程と内容の例を挙げます。 工程 内容 計画 対象の調査・決定 調達 必要ツールや情報の取得 構築 フィッシングサイトの構築 誘導 フィッシングメール、SMSなどの送信 詐取 情報を騙し取る 収益化 盗んだ情報を金銭に変換 強化拡大 攻撃の強化・拡大 フィッシングキットについて フィッシングキットとは、フィッシングサイトを容易に構築可能なテンプレートのことです。高度なスキルを必要とせずにフィッシングサイトの構築が可能となります。このようなフィッシングキットは、秘匿性の高いチャットサービスであるTelegramやダークウェブなどのコミュニティ、配布サイトなどで配布されていると考えられます。 フィッシングキットに含まれるソースコードを解析することで、実装されている調査・解析妨害のテクニックや、通信先といった攻撃者についての知見を得ることができます。また、フィッシングサイトを構築しているファイルのハッシュ値に着目することで、同じフィッシングキットから作成された他のサイトについても調査可能です。 フィッシングキットに含まれるファイルの解析 実際に、フィッシングキットに含まれるファイルの解析に取り組みました。今回対象としたフィッシングキットには3つのファイルが含まれており、各ファイルのソースコードから処理内容を解析しました。 その中で、一部のファイルには、解析を困難にする目的で「難読化」と呼ばれる処置が施されていました。難読化の解除にも取り組みましたが時間が足りず、プロジェクトの方から解除後のソースコードを提供していただき解析を続行しました。自力で難読化を解除できず悔しかったです... 解析から、各ファイルの処理内容、及びフィッシングサイトの挙動は以下の通りだとわかりました。 ファイル 内容 ファイル1 フィッシングサイトを生成し、入力された情報を攻撃者サーバ内のファイル2に送信するphpファイル ファイル2 受け取った入力情報を攻撃者のTelegramやメールに送信するphpファイル ファイル3 メール送信に関する処理が記述されたjsファイル ファイル1が生成したフィッシングサイトに、被害者が情報を入力して送信ボタンをクリックすると、攻撃者サーバに入力した情報が送信されます。この情報をファイル2が受信し、さらに攻撃者のTelegramとメールに送信します。この際、メール送信処理を担当するファイル3も使用されます。 フィッシングサイトの調査 次に、 urlscan.io というサービスを用い、同じフィッシングキットから作成されているフィッシングサイトを調査しました。 urlscan.ioでは、調査対象ページに代理でアクセスし、スクリーンショットや、ブラウザが受信したファイルの一覧、その他の詳細情報を閲覧可能です。また、過去に他のユーザによってスキャンされた結果についても検索できます。 今回、調査した手順は以下です。 urlscan.ioにフィッシングサイトのURLを入力し、過去のスキャン結果を検索します フィッシングサイトを構築するHTMLファイルのハッシュ値を取得します 取得したハッシュ値をurlscan.ioに入力し、同一ハッシュ値を持つサイトのスキャン結果を検索します 同じフィッシングキットから作成されたと考えられるサイトのURLが、900件以上表示されました(2024年2月15日時点) 上記の調査結果より、同一のフィッシングキットから延べ900件以上のサイトが作成された可能性があることが分かりました。 このことから、フィッシング詐欺が増加している一因として、フィッシングキットの流通により、フィッシングサイトの複製が容易になったことが考えられます。 学んだこと 本インターンシップに参加して、さまざまなことを学びました。技術的なことはもちろん、チームで業務を進める雰囲気も体験できました。 以下に学びをピックアップして紹介します。 能動的に情報を収集し、攻撃インフラを発見する体験ができた Cobalt StrikeのC2サーバや、フィッシングサイトのURL調査を能動的に実施した C2サーバのIPアドレスや、フィッシングサイトのURLを発見する経験を積めた セキュリティインシデント事例の調査を体験できた ネット上に公開されている、インシデントに関する記事・情報の調査を実施した Cobalt Strikeを用いた攻撃の流れや脆弱性の悪用、C2サーバに関する情報などの知見を吸収できた 現在でも使用されている攻撃手法や技術について触れられた 攻撃者の視点でクローキングを実装することで、アクセス制御に関する理解が進んだ 年々件数が増加しているフィッシング詐欺について、その背景にあるフィッシングキットの解析を体験できた チームで仕事をする雰囲気を体験できた 情報共有が盛んであり、発言し易い環境を作る重要性を学んだ 疑問点があれば積極的に質問することで、自分が担当している作業の目的が明確になった おわりに 約2週間という期間でしたが、あっという間に過ぎ去ってしまいました。楽しい時間は、過ぎるのが早いです。 今回所属させていただいたNA4Secプロジェクトは、質問や情報共有が非常にしやすい雰囲気であり、素朴な疑問・質問にも丁寧に答えていただきました。また、技術的な学びだけでなく、チームで働く際に必要な事を自分なりに考えるきっかけにもなりました。 受け入れてくださったNA4Secプロジェクトの皆さま、ありがとうございました。 特にインターンシップを担当してくださった神田さん、坪井さん、鮫嶋さんには、非常にお世話になりました。 ありがとうございました。 メンターからのコメント 坪井です。猪飼さん、まずは2週間のインターンシップお疲れ様でした。 今回2週間という短い期間かつ3連休も重なったため、実際に手を動かして作業してもらう期間が短い中、スケジュール通りに予定していた範囲の業務を完遂していただけました。今回のインターンシップではNA4Secの全員と対面で会う機会がなかったものの、NeWorkに参加しているチームメンバに対して積極的に質問をして課題解決をされており、技術スキルだけではなく、社会人としてチームで働くということを経験していただくことができたかと思います。 猪飼さんの持ち前の高いコミュニケーション能力と課題解決能力でこれからもご活躍されることを心より信じています。 次回インターンシップのお知らせ ドコモグループでは2024夏インターンシップを開催します。 猪飼さんが参加された現場受け入れ型インターンシップも下記スケジュールにて開催予定です。 エントリー期間 開催日 6/3（月） ～ 6/21（金） 8/26（月） ～ 9/6（金）　※ 土日除く 詳細については今後順次公開される予定です 4 。 興味を持たれた方はぜひご応募ください。 (5/23追記) サマーインターンシップ2024 の情報が公開され、 現場受け入れ型インターンシップ の受け入れポスト情報も公開されました。 本記事に関連するポストは「 D2.脅威インテリジェンスを生成・活用するセキュリティエンジニア/アナリスト 」（PDFファイル、4ページに記載）です。 参考文献 フィッシング対策協議会 : フィッシング対策ガイドライン 2023年度版 「脅威調査」「脅威分析1」「脅威探索」については、「 インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 」で紹介されています ↩ 「脅威検証」については、「 攻撃者はいかにしてフィッシングサイトを隠すか？（インターンシップ体験記） 」で紹介されています ↩ 月次報告書 | 2024/01 フィッシング報告状況 ↩ 予め マイページ に登録していただければ、インターンシップ募集開始時にメールでお知らせが届きます ↩

はじめに こんにちは、ドコモグループのウインターインターンシップ2023に参加した猪飼です。 普段は、大学院でマルウェアの動的解析に関する研究をしています。 「サイバー攻撃の原理を理解し、攻撃インフラ(マルウェアインフラ)を解明するセキュリティアナリスト」のポストに参加させていただきました。 この記事では、私がインターンシップで取り組んだ内容について紹介します。 NA4Secプロジェクトについて まずは、私がお世話になったNA4Secプロジェクトについて紹介します。 正式には「Network Analytics for Security」というNTTコミュニケーションズ イノベーションセンターのプロジェクトであり、通称NA4Sec（なよせ）と呼ばれています。 NA4Secプロジェクトは、「NTTはインターネットを安心・安全にする社会的責務がある」という理念に基づき、攻撃インフラの解明、撲滅の実現を目指して活動しているプロジェクトです。 参加のきっかけ 現場で業務を体験できるインターンシップを調査していた際、過去にドコモグループのインターンシップを体験した方々のブログを発見しました。ブログの内容が非常に興味深く、「このインターンシップはとても面白そうだな」という印象を受けました。 そこから調べていく間に、セキュリティに関する業務を現場で体験できる点に魅力を感じ、「実際に働く雰囲気を体験したい！」と考え応募しました。また、自分が興味を持っている攻撃インフラに関連するポストが存在したことも、応募の決め手でした。 インターンシップ概要 2/5から2/16までの約2週間、プロジェクトメンバーとして業務を体験させていただきました。 業務はオンラインで実施し、 NeWork というオンラインコミュニケーションツールを活用しました。気軽に相談できる環境・雰囲気であったため、非常に働きやすかったです。 インターンシップにて、「サイバー攻撃の原理を理解し、攻撃インフラ(マルウェアインフラ)を解明すること」をテーマに、私は以下のことに取り組みました。 脅威調査 ペネトレーションテストツールであるCobalt Strikeについて調査し、理解する。 脅威分析1 Cobalt Strikeが悪用された攻撃事例を調査し、ダイヤモンドモデルに基づいて分析する。 脅威探索 デバイス検索エンジンであるCensysを使用し、インターネット上に存在するCobalt StrikeのC2サーバを調査する。 脅威検証 攻撃者が、インフラの秘匿に使用するクローキング技術について調査し、サーバに実装する。 脅威分析2 フィッシングについて調査し、フィッシングキットを解析する。 URLスキャンサービスであるurlscan.ioを使用し、フィッシングサイトを調査する。 今回は、「脅威分析2」について紹介したいと思います。 「脅威分析2」以外の内容に関しては、過去にインターンシップに参加された方の記事が公開されているのでそちらをご覧ください 1 　 2 。 脅威分析：フィッシングキットの解析 私は今回、フィッシングキットの解析に取り組み、以下のワークを行いました。 フィッシングについての調査 フィッシングキットについての調査 フィッシングキットの解析 フィッシングサイトの調査 フィッシング詐欺について フィッシング詐欺とは、通販サイトや会員ページのログイン画面を模倣し、利用者にIDやパスワード、カード情報などを入力させ、情報を搾取する犯罪の一種です。 近年では、フィッシング詐欺の件数は年々増加傾向にあります。フィッシング対策協議会によると、2024年1月に報告された件数は、85,827件でした 3 。 フィッシング詐欺の分業化 フィッシング詐欺の件数が増加している背景として、分業化が考えられます。それぞれの工程を担当する業者が分かれることで、フィッシング詐欺の実行が容易になっています。 以下に、各工程と内容の例を挙げます。 工程 内容 計画 対象の調査・決定 調達 必要ツールや情報の取得 構築 フィッシングサイトの構築 誘導 フィッシングメール、SMSなどの送信 詐取 情報を騙し取る 収益化 盗んだ情報を金銭に変換 強化拡大 攻撃の強化・拡大 フィッシングキットについて フィッシングキットとは、フィッシングサイトを容易に構築可能なテンプレートのことです。高度なスキルを必要とせずにフィッシングサイトの構築が可能となります。このようなフィッシングキットは、秘匿性の高いチャットサービスであるTelegramやダークウェブなどのコミュニティ、配布サイトなどで配布されていると考えられます。 フィッシングキットに含まれるソースコードを解析することで、実装されている調査・解析妨害のテクニックや、通信先といった攻撃者についての知見を得ることができます。また、フィッシングサイトを構築しているファイルのハッシュ値に着目することで、同じフィッシングキットから作成された他のサイトについても調査可能です。 フィッシングキットに含まれるファイルの解析 実際に、フィッシングキットに含まれるファイルの解析に取り組みました。今回対象としたフィッシングキットには3つのファイルが含まれており、各ファイルのソースコードから処理内容を解析しました。 その中で、一部のファイルには、解析を困難にする目的で「難読化」と呼ばれる処置が施されていました。難読化の解除にも取り組みましたが時間が足りず、プロジェクトの方から解除後のソースコードを提供していただき解析を続行しました。自力で難読化を解除できず悔しかったです... 解析から、各ファイルの処理内容、及びフィッシングサイトの挙動は以下の通りだとわかりました。 ファイル 内容 ファイル1 フィッシングサイトを生成し、入力された情報を攻撃者サーバ内のファイル2に送信するphpファイル ファイル2 受け取った入力情報を攻撃者のTelegramやメールに送信するphpファイル ファイル3 メール送信に関する処理が記述されたjsファイル ファイル1が生成したフィッシングサイトに、被害者が情報を入力して送信ボタンをクリックすると、攻撃者サーバに入力した情報が送信されます。この情報をファイル2が受信し、さらに攻撃者のTelegramとメールに送信します。この際、メール送信処理を担当するファイル3も使用されます。 フィッシングサイトの調査 次に、 urlscan.io というサービスを用い、同じフィッシングキットから作成されているフィッシングサイトを調査しました。 urlscan.ioでは、調査対象ページに代理でアクセスし、スクリーンショットや、ブラウザが受信したファイルの一覧、その他の詳細情報を閲覧可能です。また、過去に他のユーザによってスキャンされた結果についても検索できます。 今回、調査した手順は以下です。 urlscan.ioにフィッシングサイトのURLを入力し、過去のスキャン結果を検索します フィッシングサイトを構築するHTMLファイルのハッシュ値を取得します 取得したハッシュ値をurlscan.ioに入力し、同一ハッシュ値を持つサイトのスキャン結果を検索します 同じフィッシングキットから作成されたと考えられるサイトのURLが、900件以上表示されました(2024年2月15日時点) 上記の調査結果より、同一のフィッシングキットから延べ900件以上のサイトが作成された可能性があることが分かりました。 このことから、フィッシング詐欺が増加している一因として、フィッシングキットの流通により、フィッシングサイトの複製が容易になったことが考えられます。 学んだこと 本インターンシップに参加して、さまざまなことを学びました。技術的なことはもちろん、チームで業務を進める雰囲気も体験できました。 以下に学びをピックアップして紹介します。 能動的に情報を収集し、攻撃インフラを発見する体験ができた Cobalt StrikeのC2サーバや、フィッシングサイトのURL調査を能動的に実施した C2サーバのIPアドレスや、フィッシングサイトのURLを発見する経験を積めた セキュリティインシデント事例の調査を体験できた ネット上に公開されている、インシデントに関する記事・情報の調査を実施した Cobalt Strikeを用いた攻撃の流れや脆弱性の悪用、C2サーバに関する情報などの知見を吸収できた 現在でも使用されている攻撃手法や技術について触れられた 攻撃者の視点でクローキングを実装することで、アクセス制御に関する理解が進んだ 年々件数が増加しているフィッシング詐欺について、その背景にあるフィッシングキットの解析を体験できた チームで仕事をする雰囲気を体験できた 情報共有が盛んであり、発言し易い環境を作る重要性を学んだ 疑問点があれば積極的に質問することで、自分が担当している作業の目的が明確になった おわりに 約2週間という期間でしたが、あっという間に過ぎ去ってしまいました。楽しい時間は、過ぎるのが早いです。 今回所属させていただいたNA4Secプロジェクトは、質問や情報共有が非常にしやすい雰囲気であり、素朴な疑問・質問にも丁寧に答えていただきました。また、技術的な学びだけでなく、チームで働く際に必要な事を自分なりに考えるきっかけにもなりました。 受け入れてくださったNA4Secプロジェクトの皆さま、ありがとうございました。 特にインターンシップを担当してくださった神田さん、坪井さん、鮫嶋さんには、非常にお世話になりました。 ありがとうございました。 メンターからのコメント 坪井です。猪飼さん、まずは2週間のインターンシップお疲れ様でした。 今回2週間という短い期間かつ3連休も重なったため、実際に手を動かして作業してもらう期間が短い中、スケジュール通りに予定していた範囲の業務を完遂していただけました。今回のインターンシップではNA4Secの全員と対面で会う機会がなかったものの、NeWorkに参加しているチームメンバに対して積極的に質問をして課題解決をされており、技術スキルだけではなく、社会人としてチームで働くということを経験していただくことができたかと思います。 猪飼さんの持ち前の高いコミュニケーション能力と課題解決能力でこれからもご活躍されることを心より信じています。 次回インターンシップのお知らせ ドコモグループでは2024夏インターンシップを開催します。 猪飼さんが参加された現場受け入れ型インターンシップも下記スケジュールにて開催予定です。 エントリー期間 開催日 6/3（月） ～ 6/21（金） 8/26（月） ～ 9/6（金）　※ 土日除く 詳細については今後順次公開される予定です 4 。 興味を持たれた方はぜひご応募ください。 (5/23追記) サマーインターンシップ2024 の情報が公開され、 現場受け入れ型インターンシップ の受け入れポスト情報も公開されました。 本記事に関連するポストは「 D2.脅威インテリジェンスを生成・活用するセキュリティエンジニア/アナリスト 」（PDFファイル、4ページに記載）です。 参考文献 フィッシング対策協議会 : フィッシング対策ガイドライン 2023年度版 「脅威調査」「脅威分析1」「脅威探索」については、「 インターンシップ体験記 〜Cobalt StrikeのC2サーバ追跡〜 」で紹介されています ↩ 「脅威検証」については、「 攻撃者はいかにしてフィッシングサイトを隠すか？（インターンシップ体験記） 」で紹介されています ↩ 月次報告書 | 2024/01 フィッシング報告状況 ↩ 予め マイページ に登録していただければ、インターンシップ募集開始時にメールでお知らせが届きます ↩

こんにちは、イノベーションセンターの冨樫です。Network Analytics for Security プロジェクトに所属しています。 突然ですが皆さんはドメインパーキングというサービスを知っているでしょうか？詳細については後述しますが、以前イノベーションセンターの検証網でマルウェアに関する悪性通信が検知されたため通信先を調査したところ、ドメインパーキングだったことがあります。本記事ではこの調査を通して得られたドメインパーキングに関する知見とその調査過程を紹介します。また、今回紹介するドメインパーキングの悪用事例や外部インテリジェンスを活用した調査は基礎的な内容ですので、本記事は主に初学者の方の知見にしてもらうことを目的としています。 ドメインパーキングについて アラートの概要 Ursnif について 接続先についての調査 検知されたアラートの危険性について さいごに ドメインパーキングについて ドメインパーキングとは、活用していないドメインを所有している場合にそのドメインを Web 上で保持・管理ができるサービスです。パーキングサービス利用者は DNS の設定を変更し、対象ドメインの NS レコードにパーキングサービスの権威サーバを指定することで、そのドメインの名前解決先をパーキングサービスに変更し訪問者をパーキングサービスに向けることができます。またそのドメイン宛にアクセスするとパーキングサービスが用意したページや広告が表示されるため、利用者はドメインを Web 上に保持させるだけでなく表示された広告へのアクセス数に応じた報酬を受け取ることができます。一方でこのようなパーキングサービスを攻撃者が悪用した事例も確認されています。 一般的に攻撃者が配布するマルウェアに感染するとマルウェアは C&C サーバと通信をすることで感染端末から窃取した情報の送信や新たな悪性のファイルの追加ダウンロードなどを実行することがあります。このような活動に対抗するためアナリストによるマルウェアの解析が日々実施されていて、C&C サーバの IP アドレスが判明した場合にはその IP アドレスは危険性があるものとして周知され、さまざまなブラックリストに追加されます。 しかし攻撃者は C&C サーバの宛先ドメインを攻撃活動を実施していない通常時にはパーキングサービスに登録しておき、攻撃実施時のみ名前解決先を実際の C&C サーバの IP アドレスに変更することがあります。このようにすることでマルウェアを解析されたとしても、通常時であれば C&C サーバの IP アドレスとして検出されるのはドメインパーキングの IP アドレスとなり、本物の C&C サーバの IP アドレスが発見されることを困難にできます。このように攻撃者がパーキングサービスを隠れ蓑にする事例が確認されています。 アラートの概要 本記事の冒頭に記述した通り、以前マルウェアに関するアラートを検知したことがありました。この節ではそのアラートの概要について説明しますが、このアラートから確認できた情報は下記の数点のみでした。 接続先の IP アドレス 接続先が何らかのマルウェアの IoC であること 悪性通信が検知された端末の識別番号 上記の検知された IP アドレスを外部インテリジェンスで調査した結果、この IP アドレスがマルウェア Ursnif の IoC に含まれていることを確認できました。そのため、この時点では組織内の端末が Ursnif と関連する接続先と通信したことが疑われる状況となりました。 Ursnif について Ursnif は 2006 年ごろ確認されたバンキング型トロイで、フィッシングメール等を契機に感染し銀行情報を窃取していました。年々機能が拡張されておりバックドアやランサムウェアとしての機能を持つ亜種も確認されています。確認されている亜種として Gozi、ISFB、LDR4 など多くが存在します。（Gozi、ISFB については Ursnif の別名として使用される場合もあります。） これまで複数の国がターゲットにされており日本に対してもフィッシングメールによる Ursnif のばらまきを実行されたことが確認されています。 接続先についての調査 上述の通り Ursnif に関連する悪性の接続先へのアクセスが疑われる状況だったため、接続先についての調査を実施しました。 アラートから接続先の IP アドレスは把握できたため、まずは外部サービス（ AlienVault OTX ）が提供する Passive DNS を確認したところ、多数のドメインがこの IP アドレスを名前解決先にしていることが分かりました。また所属している AS はパーキングサービスの提供者である Sedo でした。 その後、今回のアラートが上がった端末の利用者にヒアリングを実施したところ、アラート発生時刻において過去に参加したプロジェクトで使用していたドメインにブラウザからアクセスをしていたことが確認でき、これがアラートの契機であることが分かりました。確認のため安全な環境からそのドメインの Web サイトを表示させたところ、やはり Sedo のドメインパーキングのページであり、検知された通信先は Sedo が提供するパーキングサービスであることを確認できました。 以下の画像はパーキングサービスに所属するドメインへアクセスした際の一例です。（本記事のアラートの契機となったドメインではありません。） 検知されたアラートの危険性について 過去のプロジェクトで使用したドメインへのアクセスにより Sedo のパーキングサービスが表示されましたが、これはこのドメインの有効期限が切れて廃止された後に第三者がこのドメインを取得し Sedo に登録したことが原因と考えられます。また、今回アラートが上がった接続先は Ursnif の IoC として周知されていましたが実態はパーキングサイトであり、調査した限りにおいては Ursnif の感染チェーンにおいてパーキングサービスが使用された事例は確認できませんでした。 そのことから、今回のアラートが上がった接続先の IP アドレスは本物の Ursnif の C&C サーバではなく、上述した方法で Ursnif の隠れ蓑にされたことでブラックリストに追加されたと考えられます。つまりアラートは誤検知の可能性が高く危険性は低いと思われます。 さいごに 今回は悪性の接続先（Ursnif）として検知された IP アドレスを調査し、それがパーキングサービスであることを確認しました。一方で Ursnif の感染においてパーキングサービスが利用された前例はなく、今回のアラートが誤検知の可能性が高いと判断できました。 本記事の要点は以下の 2 点と考えています。 以下の要因が重なると悪性でないドメインでもマルウェアの IoC に登録される場合がある あるドメインがパーキングサービスに登録される 攻撃者が C&C サーバの IP アドレスを隠蔽するために C&C サーバのドメインをパーキングサービスに登録する C&C サーバのドメインがパーキングサービスに登録されている時にアナリストがマルウェアを解析し、パーキングサービスの IP アドレスをブラックリストに追加する 悪性の IP アドレスへの接続が検知されたとしてもそれがパーキングサービスであった場合には、誤検知の場合もある ただしパーキングサービスであれば必ずしも危険性がないということはもちろんなく、マルウェアファミリーによってはパーキングサービスから配布が実行された事例もあるため、アラートが上がったマルウェアにそのような事例がある場合には EDR でパーキングサービスにアクセスした後のリダイレクト先を確認するなどの注意をする必要があります。また、マルウェア以外にもパーキングサービスへのアクセスを契機にフィッシングサイトやサポート詐欺サイトが表示された事例も確認されているため、この点についても警戒する必要があります。

こんにちは、イノベーションセンターの冨樫です。Network Analytics for Security プロジェクトに所属しています。 突然ですが皆さんはドメインパーキングというサービスを知っているでしょうか？詳細については後述しますが、以前イノベーションセンターの検証網でマルウェアに関する悪性通信が検知されたため通信先を調査したところ、ドメインパーキングだったことがあります。本記事ではこの調査を通して得られたドメインパーキングに関する知見とその調査過程を紹介します。また、今回紹介するドメインパーキングの悪用事例や外部インテリジェンスを活用した調査は基礎的な内容ですので、本記事は主に初学者の方の知見にしてもらうことを目的としています。 ドメインパーキングについて アラートの概要 Ursnif について 接続先についての調査 検知されたアラートの危険性について さいごに ドメインパーキングについて ドメインパーキングとは、活用していないドメインを所有している場合にそのドメインを Web 上で保持・管理ができるサービスです。パーキングサービス利用者は DNS の設定を変更し、対象ドメインの NS レコードにパーキングサービスの権威サーバを指定することで、そのドメインの名前解決先をパーキングサービスに変更し訪問者をパーキングサービスに向けることができます。またそのドメイン宛にアクセスするとパーキングサービスが用意したページや広告が表示されるため、利用者はドメインを Web 上に保持させるだけでなく表示された広告へのアクセス数に応じた報酬を受け取ることができます。一方でこのようなパーキングサービスを攻撃者が悪用した事例も確認されています。 一般的に攻撃者が配布するマルウェアに感染するとマルウェアは C&C サーバと通信をすることで感染端末から窃取した情報の送信や新たな悪性のファイルの追加ダウンロードなどを実行することがあります。このような活動に対抗するためアナリストによるマルウェアの解析が日々実施されていて、C&C サーバの IP アドレスが判明した場合にはその IP アドレスは危険性があるものとして周知され、さまざまなブラックリストに追加されます。 しかし攻撃者は C&C サーバの宛先ドメインを攻撃活動を実施していない通常時にはパーキングサービスに登録しておき、攻撃実施時のみ名前解決先を実際の C&C サーバの IP アドレスに変更することがあります。このようにすることでマルウェアを解析されたとしても、通常時であれば C&C サーバの IP アドレスとして検出されるのはドメインパーキングの IP アドレスとなり、本物の C&C サーバの IP アドレスが発見されることを困難にできます。このように攻撃者がパーキングサービスを隠れ蓑にする事例が確認されています。 アラートの概要 本記事の冒頭に記述した通り、以前マルウェアに関するアラートを検知したことがありました。この節ではそのアラートの概要について説明しますが、このアラートから確認できた情報は下記の数点のみでした。 接続先の IP アドレス 接続先が何らかのマルウェアの IoC であること 悪性通信が検知された端末の識別番号 上記の検知された IP アドレスを外部インテリジェンスで調査した結果、この IP アドレスがマルウェア Ursnif の IoC に含まれていることを確認できました。そのため、この時点では組織内の端末が Ursnif と関連する接続先と通信したことが疑われる状況となりました。 Ursnif について Ursnif は 2006 年ごろ確認されたバンキング型トロイで、フィッシングメール等を契機に感染し銀行情報を窃取していました。年々機能が拡張されておりバックドアやランサムウェアとしての機能を持つ亜種も確認されています。確認されている亜種として Gozi、ISFB、LDR4 など多くが存在します。（Gozi、ISFB については Ursnif の別名として使用される場合もあります。） これまで複数の国がターゲットにされており日本に対してもフィッシングメールによる Ursnif のばらまきを実行されたことが確認されています。 接続先についての調査 上述の通り Ursnif に関連する悪性の接続先へのアクセスが疑われる状況だったため、接続先についての調査を実施しました。 アラートから接続先の IP アドレスは把握できたため、まずは外部サービス（ AlienVault OTX ）が提供する Passive DNS を確認したところ、多数のドメインがこの IP アドレスを名前解決先にしていることが分かりました。また所属している AS はパーキングサービスの提供者である Sedo でした。 その後、今回のアラートが上がった端末の利用者にヒアリングを実施したところ、アラート発生時刻において過去に参加したプロジェクトで使用していたドメインにブラウザからアクセスをしていたことが確認でき、これがアラートの契機であることが分かりました。確認のため安全な環境からそのドメインの Web サイトを表示させたところ、やはり Sedo のドメインパーキングのページであり、検知された通信先は Sedo が提供するパーキングサービスであることを確認できました。 以下の画像はパーキングサービスに所属するドメインへアクセスした際の一例です。（本記事のアラートの契機となったドメインではありません。） 検知されたアラートの危険性について 過去のプロジェクトで使用したドメインへのアクセスにより Sedo のパーキングサービスが表示されましたが、これはこのドメインの有効期限が切れて廃止された後に第三者がこのドメインを取得し Sedo に登録したことが原因と考えられます。また、今回アラートが上がった接続先は Ursnif の IoC として周知されていましたが実態はパーキングサイトであり、調査した限りにおいては Ursnif の感染チェーンにおいてパーキングサービスが使用された事例は確認できませんでした。 そのことから、今回のアラートが上がった接続先の IP アドレスは本物の Ursnif の C&C サーバではなく、上述した方法で Ursnif の隠れ蓑にされたことでブラックリストに追加されたと考えられます。つまりアラートは誤検知の可能性が高く危険性は低いと思われます。 さいごに 今回は悪性の接続先（Ursnif）として検知された IP アドレスを調査し、それがパーキングサービスであることを確認しました。一方で Ursnif の感染においてパーキングサービスが利用された前例はなく、今回のアラートが誤検知の可能性が高いと判断できました。 本記事の要点は以下の 2 点と考えています。 以下の要因が重なると悪性でないドメインでもマルウェアの IoC に登録される場合がある あるドメインがパーキングサービスに登録される 攻撃者が C&C サーバの IP アドレスを隠蔽するために C&C サーバのドメインをパーキングサービスに登録する C&C サーバのドメインがパーキングサービスに登録されている時にアナリストがマルウェアを解析し、パーキングサービスの IP アドレスをブラックリストに追加する 悪性の IP アドレスへの接続が検知されたとしてもそれがパーキングサービスであった場合には、誤検知の場合もある ただしパーキングサービスであれば必ずしも危険性がないということはもちろんなく、マルウェアファミリーによってはパーキングサービスから配布が実行された事例もあるため、アラートが上がったマルウェアにそのような事例がある場合には EDR でパーキングサービスにアクセスした後のリダイレクト先を確認するなどの注意をする必要があります。また、マルウェア以外にもパーキングサービスへのアクセスを契機にフィッシングサイトやサポート詐欺サイトが表示された事例も確認されているため、この点についても警戒する必要があります。

この記事では、SDPFクラウド/サーバで提供しているファイアウォールサービスについて、数週間かかっていたコントローラのテストを一新し、開発効率/品質向上に繋がった事例を紹介します。 目次 目次 はじめに ファイアウォール サービスとは テストにおける課題 問題1: テスト時間が長い 問題2: テストツールのEOL テスト環境の一新 問題の調査と整理 外部サービスのmock化 apiごとのテスト実装 CIの導入 テスト環境を一新して さいごに はじめに みなさん、こんにちは。 現在、SDPFクラウド/サーバで提供しているファイアウォール/ロードバランサーのサービス開発業務に携わっています、片貝です。 この記事では、数週間かかっていたファイアウォールサービスのテストを一新し、開発効率/品質向上に繋がった事例を紹介させていただきます。 ファイアウォール サービスとは ファイアウォールサービスでは、IaaS環境の上で利用できる仮想ファイアウォールアプライアンスを提供しています。 お客さまからの申し込み(API call/GUI操作)に合わせて、我々で管理/開発するファイアウォールコントローラが基盤となる仮想サーバー作成、NW接続、ファイアウォールの設定投入といった、サービスの提供に必要な操作を実施し、デプロイまでの自動化を実現しています。 テストにおける課題 ファイアウォールサービスでは、リソースの作成や削除といった基本機能はすでに実装されており、現在はお客さまからのフィードバックに基づいた機能追加や改善が行われています。 このような機能追加の開発やリリースにおいて、コントローラへのソフトウェアテスト時にたびたび問題が生じていました。 問題1: テスト時間が長い 1つの問題は、テストにかかる時間が長いことです。 ファイアウォールサービスの開発では、サービスの正常動作を担保するためのテストに2,3週間もの時間がこれまでかかっていました。 その結果以下のような問題が発生していました。 開発効率低下 たった数行の変更でさえも1時間以上の手動確認が必要になるなど、開発時間の多くをテスト実行が占める非効率的な状態でした。また、それによってスケジュールへの影響が出てしまうこともありました。 品質低下 変更ごとに全てのテストを実施すると、時間がかかりすぎて現実的ではないため、必要なテストに絞って実施するしかない状態となっていました。その結果テスト漏れもしばしばありました。 開発者のモチベーション低下 待ち時間が長く確認作業も煩雑であること、待機後のコンテキストスイッチによるコスト増など、開発者にとってストレスが生じていました。 問題2: テストツールのEOL もう1つの問題は、使用しているテストツールのEoLです。 ファイアウォールサービスの開発では社内で独自開発されたテストツールが使用されていましたが、そのツールがEoLを迎えることでサポートが受けられなくなるという問題が生じました。 さらに、既存のテスト実装者がすでにチームを離れており、テストがオーパーツ化していたことや、新規参入者が独自のテストツールの習熟に時間がかかるという問題も発生していました。 テスト環境の一新 上記の問題を解決するため、これまでのテストについての観点や環境を刷新することを決めました。 改善についての過程や方法を含めてその流れを追っていきます。 問題の調査と整理 まずはじめに行ったのが既存テストの調査です。 開発のどのフェーズに時間が掛かっているか、時間がかかる要因としてどんなものがあるか、アンケートを用いて調査し、チーム内で議論を重ねました。 その結果、現在の開発においては機能の追加や改善よりも、その動作確認におけるテストに多く比重が掛かっていることがチーム全体の総意であることがわかりました。 また、遅くなる要因として多く挙げられたのが既存テストの仕組みです。 現行のテストは、ファイアウォールとの結合を含めて全テストが実環境で実行されていたため、 外部サービス(仮想サーバーやネットワークを管理するIaaSコントローラー)との依存関係がある状態でした。 そのことが原因で以下のような問題が発生していました。 ① 外部サービスの計画メンテナンスや一時的なエラーなど、本来テストしたいファイアウォールウォールコントローラ以外が原因でテストが失敗、中断、やり直しになる。 ②そもそも外部サービスのAPI call(仮想サーバの起動やファイアウォールの設定反映待ち)が長い。 その結果、外部結合に伴う処理がテストの開発時間を引き延ばし、問題1で挙げたさまざまな課題を誘発していました。 外部サービスのmock化 上記の調査を通して、外部サービスに依存したテストが問題だとわかったため、解消する取り組みとして外部サービスのmock化を行いました。 具体的には仮想サーバ、ネットワーク操作、ファイアウォールの設定投入などAPI callをhookし、それら動作を模擬する実装に切り替えました。 ファイアウォールの特定通信の可否を確認するテストなどは、実体がなければ詳細なテストは難しいため、外部サービスとの依存が必要となります。 しかし、既存テストのほとんどは構築ロジック(仮想サーバの作成/削除や、ユーザネットワークと繋ぎこむ部分)のテストであり、 外部サービスの挙動を十分に理解し模擬できれば依存は必要ないものとなっていました。 そのためテストの品質を大きく損なうことなく、mock化を通してテストにおける課題を緩和できるだろうと判断しています。 apiごとのテスト実装 mock化を完了させた後はAPIごとのテスト実装です。 mock化した外部サービスを通してテストが実行できるよう、APIごとに新規でテストを実装しました。 ここでは、既存のテストツールのEOLや習熟コストを考え、ファイアウォールコントローラ開発のメイン言語であるPythonのテストツールpytestへの移行も同時に行っています。 全APIで約1300個のテストを新規で単体テストとして作り直しました。 その結果これまで数週間かかっていたテストが1時間以内で終了するようになりました。 Before After テスト所要時間 2,3週間 1h以内 外部結合 あり なし テストツール 社内独自ツール(EoL済み) pytest CIの導入 新規テスト実装を通した時間短縮の結果、頻繁にテスト内容を確認できるようになり、テストも安定してきたため、CIも導入できるようになりました。 開発者はPRの作成や更新のみを行い、それをトリガーとしてテスト環境の作成や実行、Slack通知までを自動化しました。 チーム内で、この通知をマージのゲートとして利用することで、開発者やレビュワーはテストの確認に負担をかけることなく開発を進めることができるようにもなりました。 テスト環境を一新して テスト時間の短縮によって開発効率はもちろん開発者の体験までもが大幅に向上したと感じています。 さらにCIの導入で、バグの早期検出から修正までが容易になり、リリース時の不安やリスクの軽減、サービスの品質向上へ繋がりました。 全ての項目を合わせると4人で半年という期間がかかっていますが、このテスト環境の一新を土台としてスムーズな開発プロセスが確立され、その時間を費やした価値は十分にあると感じています。 ユーザに直接提供する機能の開発ではないですが、こういった開発環境改善はチーム全体の文化の改善や効率性の向上をもたらすものと感じており、今後も取り組みを継続し、より良いサービスの提供に努めていきたいと思っています。 さいごに 今回、SDPFクラウド/サーバのファイアウォールサービスについて、テストを一新し開発効率/品質向上に繋がった事例について紹介させていただきました。 この記事のようにファイアウォールサービスの開発チームでは、新機能の開発/改善に加え、開発のサイクル向上といった取り組みも行い、ユーザへの利益提供のために日々努力しています。 2024年4月現在、一緒に開発を進めてくれるメンバーを募集していますので、 興味を持ってくださった方、以下のリンクから是非詳細をご覧ください。 https://hrmos.co/pages/nttcom0033/jobs/1928706488764108838 皆さまのご応募お待ちしています！