この記事は NTTコミュニケーションズ Advent Calendar 2021 の1日目の記事です。 NTT Com Advent Calendar 2021 開幕 こんにちは。NTT Com Engineers' Blog企画チームです。 NTT Comは、Advent Calendar 2021を今年も実施します！ 今年も色々な技術ジャンルの記事が続いていきますので乞うご期待。 私自身どんな記事が出てくるのかとても楽しみです。 過去のNTT Com Advent Calendar 2020年のアドベントカレンダー 2019年のアドベントカレンダー 2018年のアドベントカレンダー 2017年のアドベントカレンダー NTT Com Engineers' Blog 公開から半年経って ここでは、NTT Com Engineers' Blog 公開から半年時点での振り返りとしてアクセス数を始めとした数字や、ブログ運営上の工夫点などをご紹介したいと思います。 半年で公開した記事数とアクセス数の推移 半年間で20本のブログ記事を公開できました。 社内で執筆してくださった方並びに読者の皆様ありがとうございました。 月 アクセス数 公開した記事数 2021-07 6,374 3 2021-08 4,322 5 2021-09 13,613 3 2021-10 5,637 3 2021-11 6,441 6 アクセスの多かった記事TOP3 １位 次世代の監視技術 - Telemetry技術のご紹介 engineers.ntt.com 2位 Microsoft365 Microsoft Exchange Onlineの監査ログ（前編） engineers.ntt.com 3位 開発者ブログをリニューアルしました! engineers.ntt.com このランキングは7/28-11/30の期間でのPVで出しているため、公開が早かった記事ほど有利なランキングです。 面白い記事ですので、この機会にぜひご覧ください。 半年での20本の記事カテゴリーを振り返ってみると、NTTコミュニケーションズという事でネットワークの記事だらけになるかと思いきや、上位カテゴリーに「機械学習」「メディアAI」「セキュリティ」「IoT」等、多様な分野の記事が集まってきたのは嬉しく思ってます。 ブログ運営上の工夫 社内で執筆者や読者を増やすために、社内でPRも繰り返しました。 Lunch Time KURUMAZAへの登壇 Lunch Time KURUMAZAとは、昼休み時間にご飯を食べながら集まり情報共有や意見交換を行う社内イベントです。 この場で、NTT Com Engineers' Blogの狙いやリニューアルによって変わった記事執筆環境を説明して、企画チームやブログ記事執筆者を勧誘しました。 社内コミュニティで勧誘 社内にある様々なSlackチャネルやその他コミュニティをウォッチして、記事化したら面白そうなイベントや取り組みを見つけては、声をかけまくりました。 記事公開のお知らせ 新しい記事が公開されると広報のTwitterアカウントやSlackや社内ポータルサイトで宣伝しました。 #エンジニアブログ でコンピュータビジョン分野における世界最高峰の国際会議ICCV21の論文＆コード紹介【後編】を公開しました！ https://t.co/l97QOo0Dce 本記事は後編となっており、引き続きICCV21の論文と実際にコードを動かした結果を紹介しています。 ぜひご覧ください！ — NTTコミュニケーションズ (@NTTCom_online) 2021年11月12日 来年に向けて NTT Com Engineers' Blog 公開最初の半年は、情報発信をしたくなったときに「NTT Com Engineers' Blogがあった」と思ってもらえるように、社内での知名度アップを狙って活動しました。 2022年は、社外の認知度を向上させるべく面白い記事のPRや次世代のスターの発掘を頑張っていきたいです。 明日は、Mahitoさんの「GitHub Enterprise を契約してとりまとめてる話」です。

はじめに こんにちは、データプラットフォームサービス部でIoT Connect Gateway開発チームのTech Leadをしている 栗原良尚(@yoshinao) です。 前回の記事投稿からしばらく時間が経過してしまいました。 今回は、実際にRaspberry Piのセットアップならびに ICGWの設定、AWSにデータを転送するところまでご紹介したいと思います。 また、 2021年10月18日のニュースリリース でご案内しておりますように、IoT Connect Gatewayの新機能の提供を開始しました。 今回の機能拡充によってNTT ComのIoTプラットフォームである Things Cloud のサポートを開始しました。 新規メニューとして、従来メニューのIoTプラットフォームに接続できる スタンダード に加え、 イベント と ファンクション というラインナップが追加されました。 スタンダード 各種クラウドサービスのIoTプラットフォームに接続するために 必要な暗号変換機能とクラウドアダプタ機能が利用可能です。 今回のリリースで Things Cloud のほかに、お客様のオンプレミス環境 に対応できるよう 汎用HTTPサーバ にも対応しています。 イベント 各種クラウドのメッセージングサービスに接続することで、クラウドで提供しているAI/MLといったようなPaaSやSaaSサービスをより簡単に活用できる機能 ファンクション 各種クラウドのサーバーレスコンピューティングサービスやFaaS(Function as Service)に接続することで、データの前処理やより開発に注力することを目的とした機能 準備する物 1. ICGWに対応したSIM ICGWをご利用の場合は、別途ICMS対応SIMが必要となります。 申し込み、トライアルのご相談は記事下部にあるご連絡先よりお問い合わせください。 2. USBドングル(UX302NC)またはモバイルルータ 今回はUX302NCRとAtermの設定を紹介しています 3. IoTデバイスとして利用できる機器(Raspberry Pi4) 今回はRaspberry Pi4を利用していますが、省電力化、小型化が必要な場合は、Raspberry Pi zeroのほうがおすすめです。 Linuxが動作すれば同様の手順で接続は可能です。 Raspberry Piのセットアップ Raspberry Pi OSインストール作業 Raspberry Pi を使うためには、SDカードにOSを インストールが必要になりますが、公式の Raspberry Pi Imagerを使うことで簡単にインストールが可能になります。 Raspberry Pi Imagerダウンロード先 1. Raspberry Pi Imagerの起動 OSのインストールはRaspberry Pi Imagerを利用するのが一番簡単です。 2. OSの選択 今回はRaspberry Pi純正のOSを選択しましたが、サードパーティ製のOSも選択可能です。 3. インストール先のMicro SDの選択 書き込みをおこなうSDカードを選択してください 4. 書き込み開始 Writeボタンを押して、SDにイメージを書き込みを開始します。 たったこれだけでOSのインストールが可能です。本当に便利になりましたね。 モバイル網への接続 Raspberry PiをICMSのSIMを利用してICGWに接続するには、以下の２通りの方法があります。 モバイル回線接続用パラメータは下記ページをご参照の上設定をお願いいたします。 ICGW IoT Device設定情報 1.Raspberry PiとモバイルルータをWifi接続利用 モバイルルータがある場合は、簡単に試すことが可能な方法です。 ここでは、Atermを使った場合の設定例を示します。 下記の設定のように ICGW IoT Device設定情報 に記載されて いる情報を設定することで、Raspberry PiからWifi経由でICGWに接続が可能です。 確認画面でWAN側状態の項目でIPアドレスが付与されていると正常に接続されています。 2.Raspberry PiにUSBドングル接続して利用 こちらの方法は、設定が多少複雑ですが、Raspberry Piと一体化することで 給電の簡素化可能です。 設定手順の概要は以下の通りです。 Raspberry PiにUSBドングルを設定 wvdalを利用し、モバイル網に接続 Raspberry Pi起動時、USB接続時に自動接続する設定 USBドングルの設定方法に関しては、別記事にてご紹介したいと思います。 接続確認 Raspberry Piが NTT Comのネットワークに接続されていることを確認 pi@raspberrypi:~ $ whois `curl inet-ip.info` --snip-- Network Information: [ネットワーク情報] a. [IPネットワークアドレス] 210.225 . 74.128 / 25 b. [ネットワーク名] VUTM-NW3 f. [組織名] エヌ・ティ・ティ・コミュニケーションズ株式会社 g. [Organization] NTT Communications Corporation Customer Service Department m. [管理者連絡窓口] RS22452JP n. [技術連絡担当者] RS22452JP ICGW設定手順 ここではICGWを利用して、AWS IoTCoreに接続する設定をご紹介します。作業ステップは以下の通りです。 SIMの情報登録 認証情報の登録 データ転送先設定 Step1.SIMの情報確認＆設定 DeviceName, Optionデータを必要に応じて設定可能です。 これらの情報ならびに、IMSI, MSISDN, IMEI, HSNの情報は、MQTTのトピックや、転送先URL、データで置換可能になります。 Step2.認証情報の登録 各種クラウドごとに提供されている認証情報を登録します。 AWS IoTCoreの場合はX.509を選択してください。 AWS IoTCoreの認証鍵はAWS IoTCoreの モノの作成 の際に一度しかダウンロードできませんのでご注意ください。 Step3.データ転送先設定 下記は、AWS IoTCoreにHTTPで接続する場合の設定方法です。 MQTTも同様の設定をすることで利用可能になります。 ICGWを利用することで、既存のデバイス設定を変更することなく、本ポータルより設定変更や、データ転送先の変更、暗号鍵の交換などが簡単に行うことが可能です。 また、本設定画面からSIM設定画面で保持している個別デバイスの識別情報をトグルスイッチのON/OFFで付加しデータ転送が可能です。 ICGW経由でメッセージを送信 IoT機器で利用されるプロトコルは様々ありますが、ICGWでは現在のところ最もメジャーに利用されている HTTP 、これから需要が見込まれる MQTT に対応しています。 TCP などの他プロトコルに関しては、ご要望が多ければ優先して対応していきたいと考えております。 ぜひ、ブックマークのコメントやブログ末尾の連絡先に、ご意見を聞かせていただければ幸いです。 ICGWの送信先のEndPointは以下の通りです。 HTTP http://an1.icgw.ntt.com/ MQTT an1.icgw.ntt.com:1883 HTTP の場合は、ICGWのEndPoint以下のPathを任意に設定が可能です。 また MQTT の場合は、topicを指定することで、複数の用途を切り替えて ご利用が可能です。 HTTPを利用してデータを送信 curlを利用してHTTPを使ってデータを送信 以下では、デバイスからHTTPメッセージをICGW経由でAWS IoTCoreに 送信するコマンドと、実行結果を示します。 レスポンスメッセージには、AWS IoTCoreのレスポンスがそのまま返却されます。 送信コマンド curl -X POST \ --data '{"message": "TEST AWS HTTP"}' \ "http://an1.icgw.ntt.com/" 実行結果 pi@raspberrypi:~ $ curl -X POST \ > --data '{"message": "TEST AWS HTTP"}' \ > "http://an1.icgw.ntt.com/" { "statusCode" : 200 , "body" :{ "result" : "ok" , "detail" :{ "message" : "OK" , "traceId" : "ac0f5453-a268-048b-f965-2f2a270de847" }}} MQTTを利用してデータを送信 MQTTのメッセージを送信する場合は、mosquittoコマンドが利用できるように 下記パッケージのインストールを実施してください。 mosquitto以外にも様々なパッケージやSDKがありますので、お好みに合わせて ご利用ください。 インストールパッケージ sudo apt-get install mosquitto-clients Mosquittoを利用してICGWにPublishする方法 以下では、デバイスからMQTTメッセージをICGW経由でAWS IoTCoreに送信するコマンドと、実行結果を示します。 送信コマンド mosquitto_pub \ --host an1.icgw.ntt.com \ --port 1883 \ --id hoge \ --debug \ --topic hoge \ --message '{"message": "TEST AWS MQTT Pub"}' 実行結果 pi@raspberrypi:~ $ mosquitto_pub \ > --host an1.icgw.ntt.com \ > --port 1883 \ > --debug \ > --topic hoge \ > --message '{"message": "TEST AWS MQTT Pub"}' Client mosqpub | 12805-raspberry sending CONNECT Client mosqpub | 12805-raspberry received CONNACK ( 0 ) Client mosqpub | 12805-raspberry sending PUBLISH (d0, q0, r0, m1, 'hoge' , ... ( 32 bytes)) Client mosqpub | 12805-raspberry sending DISCONNECT Mosquittoを利用してICGWにSubscribeする方法 以下では、デバイスでAWS IoTCoreから送信されるメッセージを デバイス側で待受るためのコマンドと、実行結果を示します。 待受コマンド mosquitto_sub \ --host an1.icgw.ntt.com \ --port 1883 \ --debug \ --topic hoge 実行結果 AWS IoTCoreからテストデータを送信した場合の実行結果 pi@raspberrypi:~ $ mosquitto_sub --host an1.icgw.ntt.com --port 1883 --debug --topic hoge Client mosqsub | 13732-raspberry sending CONNECT Client mosqsub | 13732-raspberry received CONNACK ( 0 ) Client mosqsub | 13732-raspberry sending SUBSCRIBE (Mid: 1 , Topic: hoge, QoS: 0 ) Client mosqsub | 13732-raspberry received SUBACK Subscribed (mid: 1 ): 0 Client mosqsub | 13732-raspberry received PUBLISH (d0, q0, r0, m0, 'hoge' , ... ( 33 bytes)) { "message" : "TEST AWS MQTT Sub" } AWS IoT Coreでの確認方法 AWSでRaspberry Piから送信したデータを確認 AWS IoT CoreのMQTTテストクライアントの トピックをサブスクライブする を利用することで、HTTPやMQTTで送信したデータを確認できます。 上記HTTPとMQTTのPublishで送信した内容が hoge というtopicでSubscribeできる 事を確認します。 AWSでRaspberry Piから送信したデータを確認 同様にAWS IoT CoreのMQTTテストクライアントの トピックに公開する を利用することで、データをクラウド側からRaspberry Piに送信可能です。 上記MQTTのSubscribeでデバイスに送信した場合の送信内容を示しています。 今回は、AWS IoT Coreにデータ送受信を行う方法をご紹介しましたが、GCP、Azure、Things Cloudの各種サービスも同様の手順で、簡単にデバイスとクラウドサービス間のデータ送受信が可能です。 これらの機能を利用することで、センサデバイスのデータの可視化が可能になります。 また、収集したデータをクラウドサービスで分析させ、結果をデバイスにフィードバック制御することも可能になります。 この記事を見て頂いて、なにか作ってみようかな？とイメージが湧きましたら幸いです。 次回予告 次回は、センサからのデータ取得方法、クラウド側にアップロードしたデータを利用した可視化などをご紹介したいと思います。 to be continued... ※この画面は、Raspberry Piに接続したGPSモジュールで位置測位データをICGW経由で ThingsCloudにて可視化した内容です。 ICGWに関するお問い合わせ先 トライアル、サービス導入に関するお問い合わせ 資料請求・お問い合わせフォーム 開発チームへのお問い合わせ icgw-dev＠ntt.com までメールでお寄せください。 ※お手数ですが＠を半角文字に置き換えてください

目次 はじめに インターンシップ応募動機 体験内容 MQTT通信の理解 テーマを考える 送信する環境を作る IoT Connect Gatewayの設定 Things Cloudの設定 評価 インターンを終えた感想 はじめに こんにちは、この度NTTコミュニケーションズの職場体験型インターンシップ(エンジニアコース)に参加させていただきました森田と申します。 現在、大学院でIoTの研究をしています。 アクアリウム、釣り、バイクなどを趣味にしています。ものづくりが好きなので、魚を飼うというよりは設備に興味があり、水族館で魚を見るというよりはその裏側の濾過装置を見て楽しんでます。バイクに乗るというよりは、バッテリーからリレー電源を取り出して機材を取り付けて遊んでます。 今回はNTTコミュニケーションズのインターンシップで、「 IoT Connect Gateway 」のリリース前の機能（注：記事執筆時点。2021年10月18日にリリース）を利用してサービス開発してみる機会をいただいたので、その体験談についてまとめます。よろしくお願いいたします。 なお、この記事作るにあたって、開発チームの方の記事も参考にしています。 IoT Connect Gateway を使ってみた 第1回 〜ICGWのご紹介〜 インターンシップ参加にあたって IoTは家庭だけではなく、企業、都市をデータ化することで最適な提案ができると思っています。 大きなネットワークを所有しているNTTコミュニケーションズはユーザに寄り添った研究開発を行っており 大学での研究では得られないものを学ぶことができると感じ興味を持ちました。 その中でも、 SDPF に追加されたばかりの「 IoT Connect Gateway 」はデバイスとインターネットの間を支える重要な役目があり、通信の理解を深めたいと思い参加しました。 体験内容 2週間で体験したインターンシップの内容をまとめます。 1. ゲートウェイ, MQTT通信の理解 MQTTプロトコルのメリットについて教わりました。今回教わるまではHTTPやHTTPSを 利用するのでいいのではないか？と思っていましたが、MQTTが軽量なプロトコルで メッセージサイズを小さくしたり、機器同士の効率的なメッセージングにメリットが あることなどを教えて頂きました。 IoT Connect Gatewayの特徴 でも紹介されている 閉域網がなくてもセキュアにクラウド接続を実現 処理負荷がかかる暗号化処理をサービス側で実施 暗号化通信によるデータ転送量を抑制 クラウドアダプタ機能で各種クラウドサービスに簡単接続 についても詳しく教えていただきました。 図1 IoT Connect Gatewayの仕組み メインはセキュア接続だと思いますが、実際にサービスを使って開発をしてみて、個人的には 特徴4 に魅力を感じています。 センサから収集したデータを可視化するためのシステムは、クラウド側に構築することで柔軟に機能拡張が可能ですが、ハードウェアの機能拡張は頻繁にできない課題があります。 ICGWはこのようなハードウェアとソフトウェアの開発スピードの差を埋めてくれて、長期的な価値がありそうだと感じました。 2. テーマを考える 初めにmosquittoを利用し、ICGWでMQTT通信する方法を学びました。今回は、リリース前のICGW新機能を利用してサービスを考える課題に挑戦しました。 そこで、私はNTTコミュニケーションズが提供しているIoTプラットフォームサービスである Things Cloud を利用することにしました。 偶然、私が所属している研究室にRaspberry Piがたくさんあったので、これらを使って課題に取り組みました。Things Cloudは、 デバイス管理 、 可視化 、 ストリーム処理 を簡単に実現できるIoTプラットフォームでとても利用しやすそうであることがわかりました。 以下、私が提案したサービスです。 図2 今回提案したサービス IoTデバイスをたくさん用意して可視化するとより面白い発見ができそうです。今回は自宅の部屋とベランダに1台ずつ、計2台のRaspberryPiで検証しました。 3. 「センサデバイスの開発」〜データ送信する環境を作る〜 今回の環境 機材, 端末 MacBookAir(Big Sur 11.5.2, M1) RaspberryPi3 Model B ×2 温湿度センサSHT31-D ×2 利用サービス IoT Connect Gateway Dashboard Things Cloud センサのプログラムに関しては秋月電子の説明書を参考に作りました。 https://akizukidenshi.com/download/ds/akizuki/AE-SHT3x_manu_v1.0.pdf 取得した値を10進数に変換して温度変換式に代入します。 室内と室外の温度と湿度(4値)を送信しなければいけないため少し工夫しました。 RaspberryPiは同一Wi-Fiに接続されているため、ICGW側では1つのデバイスとして認識されています。 そのため、カスタムテンプレートを作成してICGW側で4値を認識できるようにしました。 また、mosquittoでは、別々のデバイスのデータを一括送信できないのでpython内でcsvに記述して送信するという方法をとりました。4値を認識できるように室外ラズパイのcsvファイルは先頭２行が空いているのがポイントです。 2台のRaspberryPiとデータの送信方法 ※注釈 実際のICGWのサービスでは、モバイルネットワーク経由で利用できるため、このような 工夫は必要なくご利用いただけます。 今回のインターンの開発環境では、簡易的にインターネット経由で実施したため別途 このような工夫が必要でした。 211はプリセットの温度テンプレートとなっています 998~996をカスタムテンプレートとしてThings Cloudに作成しました。 ICGWではThingsCloudで定義したテンプレート番号を設定することで、データをThings Cloudに対応したフォーマットに変換する機能を持っています。 参考 ・ https://developer.ntt.com/iot/docs/users-guide/device-management/#smartrest-templates ・ https://developer.ntt.com/iot/docs/device-sdk/mqtt/ RaspberryPiのセンサ値取得のコード↓ import time import smbus import subprocess def tempChanger (msb, lsb): #msbを8bitずらしてlsbとつなげる mlsb = ((msb << 8 ) | lsb) return (- 45 + 175 * int ( str (mlsb), 10 ) / float ( pow ( 2 , 16 ) - 1 )) #変換式にあてはめる def humidChanger (msb, lsb): mlsb = ((msb << 8 ) | lsb) return ( 100 * int ( str (mlsb), 10 ) / float ( pow ( 2 , 16 ) - 1 )) i2c = smbus.SMBus( 1 ) i2c_addr = 0x44 #I2c用 i2c.write_byte_data(i2c_addr, 0x21 , 0x30 ) time.sleep( 0.5 ) while 1 : i2c.write_byte_data(i2c_addr, 0xE0 , 0x00 ) data = i2c.read_i2c_block_data(i2c_addr, 0x00 , 6 ) #値確認用 print ( str ( '{:.6g}' .format(tempChanger(data[ 0 ], data[ 1 ]))) + "C" ) print ( str ( '{:.6g}' .format(humidChanger(data[ 3 ], data[ 4 ]))) + "%" ) print ( "------" ) #書き込み動作 f = open ( 'out.csv' , 'w' , encoding= 'UTF-8' ) f.write( str (tempChanger(data[ 0 ], data[ 1 ]))+ ' \n ' ) f.write( ',' ) f.write( str (humidChanger(data[ 3 ], data[ 4 ]))+ ' \n ' ) f.close() cmd = "mosquitto_pub --host an1.icgw.ntt.com --port 1883 --debug --qos 0 --topic s/us -f out.csv --id-prefix client" #1値のみ: --message '&s' % (tempChanger(data[0], data[1])) proc = subprocess.run(cmd, shell = True ) cmd = "mosquitto_pub --host an1.icgw.ntt.com --port 1883 --debug --qos 0 --topic s/uc/templateMorita02 -f out.csv --id-prefix client" #1値のみ: --message '&s' % (tempChanger(data[0], data[1])) proc = subprocess.run(cmd, shell = True ) time.sleep( 10 ) 写真のように室内と室外に設置しました。 電源用USBケーブルを窓に挟んで、外に出しました。インターン中に雨が降らなくてよかったです。 図3 室内のRaspberryPi 図4 室外のRaspberryPi 4. 「IoT Connect Gatewayの設定」〜転送先クラウドの設定〜 次にICGW側の設定を行いました。 端末情報の設定 ポータルを利用し、接続したいデバイスのIPアドレスやDevice名などの情報を登録します。 ここで、登録した情報は、転送先クラウドに付加情報として転送したり、センサデータに 補完できるようです。 図5 IoT Connect Gateway Dashboard 転送先クラウドの情報の設定 今回は、MQTTを利用して、Things Cloudにセンサ情報を転送します。 以下のようにTypeをThings Cloud、ProtocolはMQTTSを選択しました。 ICGWのダッシュボードでは、転送したいクラウドの設定後、デバイスをグループ に紐付けることで、簡単に目的のクラウドサービスに接続することが可能になります。 端末情報を他のグループに付け替えることで、転送先を切り替えることも可能になる そうです。 図6 ICGWグループ管理 接続先のクラウドをThings Cloud, 変換プロトコルをMQTTS(port8883), テンプレートを先ほど説明した211,998,997,996に設定します。 5.「Things Cloudの設定」〜センサデータを可視化〜 SCADAを利用した動的なGUI作成 Things Cloudでは様々なIoTデータの可視化を、あらかじめ準備されたウィジェットというパーツを組合せ、ローコードで実現できます。そのひとつがSCADAウィジェットで今回はこちらを利用しました。 今回のインターンで初めて知りました。 大きな施設やインフラから得られる情報をネットワークを通じて一か所に集めて1枚の図にして監視、制御するものらしいです。 今回は、私の家の見取り図を元に、室内と室外の温度をリアルタイムで監視できるようにしました。 使用ソフトはInkspaceでXMLを使って記述します。 図7 Inkspaceを使ったSCADAの作成 以上で準備ができました。ターミナル上でSSHでRaspberryPiと接続し、デバイス内にあるPythonのコードを実行します。 センサデータをグラフ化 まずは取得した4つの値(室内の温度と湿度、室外の温度と湿度)をThings Cloudを使って可視化します。 図8 温度と湿度の可視化 エアコンをつけているため、室内の温度は27℃付近を上下していることが分かります。想像以上に簡単な温度調整をしていました。最新のエアコンはもう少し良い制御をしているかもしれません。 図9 Things Cloudのダッシュボード これはThings Cloud上で編集したダッシュボードです。ダッシュボードは、ウィジェットの組合せで構成されます。SCADAウィジェットで現在の温度や湿度、他のウィジェットでアラーム等をリアルタイムで監視できるようにしました。 センサデータの分析、活用 IoTのセンサデータは、ただ可視化するだけでなく、そのデータを利用して、ユーザに通知をできることが 重要であると考えました。 そこで、センサデータから得た値をもとにアラート通知する仕組みを考えてみました。 下の図10は室内の温度と室外の温度を表しています。室内は常にエアコンをつけています。 図10 温度のみを抽出 14時~19時までを測定しており、夜になるにつれて室外の温度のほうが涼しくなってきます。エアコンをつけておくよりも、窓を開けた方が、環境に良いです。この時にThings Cloudがアラームを出します。 図11 アラームの検出 これが実際のアラーム検出画面です。 図12 アラームと連動したメールの送信 また、アラームとメールを組み合わせることによって、室内温度が30度を超えたときにメールを自動送信するというのも使ってみました。 個人的には緊急のアラームはメールではなく、LINEなどのアプリで通知してほしいと思いました。(メールは一日に3回くらいしか見ないので) ただ、Things Cloudの「 CEPスクリプトを書く 」を使えば作れそうな感じがしました。 5. ICGWチームでのインターンの感想 本インターンでは「IoT Connect Gateway」を用いたMQTT通信とThings Cloudを利用例を提案しました。実際に自分で作ることによって、製品がどのように使われているか体感できました。もう２週間あるなら、家だけではなく、モバイルで通信できるようなものに取り組みたかったです。 私が通信を専攻して間もないというところで、かなり知識が不足していました。なので、このインターンで学ぶことがたくさんありました。また、開発チームの皆さんとお話しさせていただくことで、NTT コミュニケーションズや通信についての興味が湧きました。 ICGWの皆さん2週間お世話になりました。 NTT コミュニケーションズのインターンを終えた感想 インターンを通して良かったと思った点は3つあります。 1. 会社の人と雰囲気を知れた 最初に思ったことは、NTT コミュニケーションズは想像以上に堅くないということです。 2週間スーツを着なくちゃいけないと思っていましたが、そんなことはありませんでした。 また、テレワーク率がとても高く、時代に柔軟に対応していると感じました。 決まった時間に出社し、ミーティングに参加し、退社するという日常は社員の方にとっては 当たり前かもしれませんが、学生にとっては貴重でした。 一緒に生活することによって会社で働くというイメージを鮮明にさせることができました。 2. 技術的な課題を知ることができた 実際にサービスを開発をされている方とお話しする機会は、多くないので貴重な経験や 開発の課題やそれをどう乗り越えたかの話を聞くことができました。 IoTサービスを実現するには、ネットワークの知識だけでなく、クラウドサービスやハードウェアなど様々な幅広い知識が必要であると感じ、改めて不足している周辺知識や各領域の課題を認識できました。 また、インターンの最後に学生同士の共有会がありました。今回のインターンは自分以外の学生は何をしているか分からない状態だったのですが、NTTコミュニケーションズはICTに関する幅広い業務を実施しており、社会基盤を 支えていることを知ることができ、とても勉強になりました。 知らない単語ばかりだったので、あまり理解ができませんでしたが、半年後には理解できるように精進します。 3. まともな生活習慣になった インターンシップに参加する上で怖かったことが、何も理解できなくて2週間何もできないという状態と、寝坊してご迷惑をおかけすることでした。 適度な緊張感をもって参加できたので一度も寝坊することなく参加できました。それどころか、インターンシップが終わった後でも、9時前には起きる習慣がついたのでとても良かったです。 最後に、今回のインターンシップは、研究や、就職活動をする上で貴重な経験となりました。 NTT コミュニケーションズ ICGWチームの皆さん、Things Cloudチームの皆さん、ヒューマンリソース部の皆さん2週間ありがとうございました。 トレーナーからのコメント 森田さんのトレーナーを務めたICGWチームの岩田です。 今回のインターンでは、森田さんにICGWとThings Cloudを実際に触りながらユースケースを考えて頂きました。 大学院でIoTにまつわる研究を始められたということで、IoTやIoTのサービスについて学習する良い機会になればと思いこのようなコースを企画しました。短い期間ということもあって我々からSIMやIoTデバイスなどをご用意できなかったのですが、森田さんの方で積極的に研究室からRaspberryPiやセンサを持ち込んでくださり、非常に内容の濃いインターンになったと我々も感謝しております。 森田さんの持ち味である素直な姿勢で我々やThings Cloudチームからのアドバイスも吸収してくださったので、短期間でこのような素晴らしい成果を残せたのだと思います。 このインターンで得られた経験を今後の森田さんの研究活動に役立ててもらえると我々も嬉しいです！ 2週間お疲れ様でした！

はじめに こんにちは、イノベーションセンターの鈴ヶ嶺・齋藤です。本記事は 前回の記事 の後編となっており、引き続き ICCV2021 の論文を紹介します。 engineers.ntt.com 論文紹介 Swin Transformer: Hierarchical Vision Transformer using Shifted Windows(ORAL PAPER & Marr Prize Best Paper) Swin Transformerとは この論文では、NLPで汎用バックボーンとして活用されているTransformer 1 の適用範囲を拡大して、コンピュータビジョンにおいても汎用バックボーンとして使用可能とするVision Transformer(ViT) 2 ベースの Swin Transformer を新たに提案しています。 これまでの映像分野におけるViTの課題は、主に2つあります。まず1つ目がスケールの違いです。単語トークンなどの固定化されたスケールのものとは異なり、映像ではスケールが大幅に変化する可能性があります。2つ目の違いはSelf-Attentionの計算量は画像サイズの二乗で増加し、大きな計算量が必要となる点です。これらの課題に対して、階層的な特徴マップにより様々なスケールの画像に対応し、かつ計算量を画像サイズに対して線形の計算量に削減する手法を提案しています。 Swin Transformerは次のようなアーキテクチャで構成されています。 原論文から引用 まず初めに、Patch Partitionでは、以下の従来のViTと同様に画像をパッチとして分割して線形写像します。 An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale から引用 その後の処理は、後述するPatch MergingとSwin Tranformer Blockの2つで構成されるStageの繰り返しとなっています。 Patch Merging 原論文から引用 Patch Mergingでは隣接されたそれぞれのチャンネル数Cの2x2のパッチを連結して、チャンネル数4Cの1つの特徴に変換して線形射影しています。これにより大域的な特徴抽出を維持しつつ、ネットワークが深くなるにつれトークンの数を減らすことでSelf-Attentionの計算量の増加を線形に削減する貢献をしています。 Swin Transformer Block 原論文から引用 アーキテクチャの図3(b)から分かるように、Swin Transformer Blockでは通常のMulti-head Self-Attention(MSA)をWindowsベースのW-MSAとShifted WindowsベースのSW-MSAに置き換えています。W-MSAはパッチをWindowごとに分割しSelf-Attentionを計算を効率化させることで計算量を二乗から線形に削減しています。しかしW-MSAのみで構成するとWindow間の接続がないため、そのモデリングの表現に限界があります。そこで効率的な計算を維持しつつ、Window間の接続を与えるため、上記の画像のようにWindowをシフトさせた層のSW-MSAの2つで構成します。SW-MSAでは、上記の例のようにWindow数が4から9へと増加し計算コストも増加する課題があります。この課題に対して、次の画像のようにcyclic shifttという小さなWindowsを反対側に移動させてまとめることでWindows数を一定にする方法を提案しています。また、隣接していないパッチがWindow内にある場合はSelf-Attentionの計算時にはmask処理することで対応しています。 原論文から引用 実験結果 ImageNet-1K 3 を学習させて比較した結果が次のようになっています。既存手法である通常のViT-B 4 と既存のViTベースのモデルでstate-of-the-artな手法であるDeiT-B 5 と計算量が同等にしたSwin-Bを比較しています。またSwin-T, Swin-S, Swin-Lはそれぞれの計算量が0.25倍, 0.5倍, 2倍に設定されています。 原論文から引用 上記の画像から、同程度のモデルサイズ同士の精度(acc)を比較するとSwin-TはDeiT-Sを1.5%上回り、Swin-BはDeiT-Bを1.4%上回る結果であることが分かります。 次にCOCO 6 データセットを用いてObject DetectionとSegmentationの実験をしました。 box AP(Average Precision)とmask APのそれぞれのstate-of-the-artな手法であるCopy-paste 7 とDetectoRS 8 を比較しています。 原論文から引用 上記の結果のtest-devにおいて提案手法のSwin-L(HTC++)は、box APについてはCopy-pasteを2.7上回る58.7、mask APについてはDetectoRSを2.6上回る51.1という結果であることが分かります。 実際に動作させた結果 MMDetection が必要となるため get_started.md を見てインストールしておきます。 まず、次のように推論用の inference.py を用意します。 import sys import torch from mmdet.apis import init_detector, inference_detector, show_result_pyplot from mmcv import Config import mmcv # setup arg ## mmdetection config ## ex: 'configs/swin/mask_rcnn_swin_tiny_patch4_window7_mstrain_480-800_adamw_1x_coco.py' config_file = sys.argv[ 1 ] ## checkpoint file ## ex: 'checkpoints/mask_rcnn_swin_tiny_patch4_window7_1x.pth' checkpoint_file = sys.argv[ 2 ] ## input image path img = sys.argv[ 3 ] ## output image path out = sys.argv[ 4 ] # init model device = torch.device( 'cuda:0' if torch.cuda.is_available() else 'cpu' ) model = init_detector(config_file, checkpoint_file, device=device) # inference result = inference_detector(model, img) # save the results model.show_result(img, result, out_file=out) 以下が実際に動作させたものになります。 git clone --depth 1 https://github.com/SwinTransformer/Swin-Transformer-Object-Detection.git cd Swin-Transformer-Object-Detection # setup pretrain model mkdir checkpoints wget https://github.com/SwinTransformer/storage/releases/download/v1. 0 . 3 /mask_rcnn_swin_tiny_patch4_window7_1x.pth -P checkpoints # setup inference.py # vim inference.py # setup input data # cp /path/to/input_img.jpg . python inference.py \ configs/swin/mask_rcnn_swin_tiny_patch4_window7_mstrain_480-800_adamw_1x_coco.py \ checkpoints/mask_rcnn_swin_tiny_patch4_window7_1x.pth \ input_img.jpg \ output_img.jpg 街中を撮影した画像を入力して推定した結果が次のようになっています。 MMDetectionのフレームワーク上で実装されているため、簡単に人物や車のObject detectionやSegmentationのタスクについて処理可能であることが分かります。 所感 NLPから映像分野にTransformerの適用を拡大させるために、階層的な特徴マップを用いて線型の計算量に削減したこの提案手法は非常に有用であると思い紹介しました。今後、映像分野におけるViTのさらなる発展を期待しています。 GANcraft: Unsupervised 3D Neural Rendering of Minecraft Worlds(ORAL PAPER) GANcraftとは ポスターにセンスを感じてしまい、今回解説をすることにしました。 GANCraftでは、マインクラフトで作った世界をリアルな世界に変換しています。 前提としてマインクラフトは、視点を自由に動かすことができます。 そのため、リアルな画像に変換する場合、自由に動かせる視点に対して変換する必要があります。それにあたり重要になる関連研究として、NeRF-Wがあります。NeRF-Wとは、様々な画角、天候などのオクルージョンを含む画像など様々な条件で撮影された複数の画像から、新しい視点からの画像を合成する研究です。 NeRF-Wをそのまま適用して、この変換をすれば良さそうです。 しかし、今回の対象であるマインクラフトの画像に対して、複数の画角から撮影したリアルな画像の正解データを用意するのが難しいという問題点があります。 その問題を解決する手法として GANCraft を提案しています。マインクラフトとそれに対するリアルな画像のペアとなる正解データがない場合、疑似的な正解データをGANで生成し、NeRF-Wを適用することでその問題を解決しています。提案手法は4つのベースライン手法と比較した実験において、全ての結果でその有効性を示していました。 Oral Presentation Videoから引用 モデルの説明 原論文から引用 まず、マインクラフトの画像に対してセグメンテーションマスクをかけます。その後SPADE 9 によりマスクに基づくリアルな画像を生成します。次に、実画像を使う場合、Adversarial lossを用いてスタイル特徴を抽出するStyle encoderを行います。擬似的なGround Truth画像を使う場合、Adversarial loss、perceptual loss、L1、L2を組み合わせてStyle encoderを行い、スタイル特徴量を抽出します。スタイル特徴量とMLPを用いてボリュームレンダリングを行い、画像ではなくピクセルごとの特徴ベクトルを生成します。ボリュームレンダリングの方法に、3次元の色と密度を予測するNeRF-Wを使います。NeRF-Wで、ボリュームレンダリングするのは、地上にあるブロックだけではありません。空を表現するために、GANcraftでは、環境マッピングで空を表現しています。環境マッピングで表現された空を先程紹介した、ボリュームレンダリングによって2次元特徴マップに変換します。NeRF-Wによりピクセルごとの特徴量マップを出した後に、CNNを用いて、ピクセルごとの特徴マップをGround Truth or 擬似的なGround Truth画像と同じ大きさになるように、画像の変換を行っています。 実験結果 セグメンテーションと実画像のペアを作るために、100万枚の風景画像にそれぞれに対して、DeepLabV2 10 を用いて182クラスのCOCO-STAFFセグメンテーションラベルを付与しています。 原論文から引用 実験におけるベースラインは、MUNIT 11 、SPADE、wc-vid2vid 12 、NSVF-Wの4つを用意しています。 評価の指標には、人間の好みのスコアを示す指標を設定し、評価を行なっております。 評価者は、 どちらの映像が見ていて違和感がないか リアルな映像はどちらか の質問を用意し、2つの映像を比較してもらう評価を行なっていました。結果としては、提案されたGANcraftの手法がいずれの手法よりも映像に違和感がなくリアルな映像であると評価されました。 Multimodal unsupervised image-to-image translation. ECCV, 2018. 実際に動作させた結果 自身の実行環境は、Ubuntu18.04、Single NVIDIA RTX3090です。 GANCraftは、Imaginaireをフレームワークとして用いています。そのため、最初にImaginaireのインストールを行います（ 公式マニュアル ）。 インストールの方法は、3つ示されていました。 シェルスクリプト Docker Anaconda それぞれの方法で実行してみたのですが、私の環境ではうまく構築できませんでした。 また、 以下のように nvcr.io/nvidia/pytorch:21.06-py3 を含むDockerfileを作り環境構築をしようとしたのですがその方法もエラーが解消できませんでした。 From nvcr.io/nvidia/pytorch:21.06-py3 ... ... そのため、 nvcr.io/nvidia/pytorch:21.06-py3 をdocker pullしその中で、以下のスクリプトを実行しました。 以下は、ホストPCのterminalで実行したスクリプトです。 sudo docker pull nvcr.io/nvidia/pytorch:21.06-py3 sudo docker images #nvcr.io/nvidia/pytorch:21.06のIMAGE IDをメモしておきます sudo docker run -it --gpus all ${IMAGE_ID} bash コンテナの中に入り、以下のスクリプトを実行します。今回は、学習済みモデルを使用して推論しました。 # コンテナの中に入ったら、以下のコードをworkspaceのディレクトリで実行します apt-get update && apt-get upgrade #libgl1-mesa-devをインストールしないと推論できないため注意 apt-get install -y libgl1-mesa-dev git clone https://github.com/nvlabs/imaginaire cd imaginaire bash scripts/install.sh python scripts/download_test_data.py --model_name gancraft # 3種類の事前学習済みモデルが用意されています # demoworld, landscape, survivalislandの中から選択します python -m torch.distributed.launch --nproc_per_node=1 inference.py \ --config configs/projects/gancraft/ { world_name } .yaml \ --output_dir projects/gancraft/output/ { world_name } 左側がマインクラフトのワールドをセグメンテーションマスクした画像。右側がセグメンテーションマスクを元にGANCraftを用いて、生成した画像となります。論文で草、砂、雪、木、水のブロックが滑らかな現実世界の存在しそうなブロックに変換されて描写されていることが分かります。空の描写に関しても、リアルな空に近く感じました。 demoworldの事前学習済みモデルの出力結果 landscapeの事前学習済みモデルの出力結果 survivalislandの事前学習済みモデルの出力結果 所感 GANCraftのポスターを見てポスターの使い方に思わず笑ってしまいました。 GANCraftを用いてマインクラフトで、リアルタイムにこの綺麗な描写で遊ぶことは、まだ実現されていないです。いつか、こんなにリアルな描写でも遊べたら楽しそうですね! 最後に ここまで前編・後編を通してICCV2021で発表された論文をご紹介しました。コンピュータービジョンのトップカンファレンスに実際に参加し、今回は掲載された論文を実際に手を動かしてみました。論文で提案していたことを実際に目で見て有効性を実感しとても楽しかったです。 NTT Comでは、今回ご紹介した論文調査、画像や映像、更には音声言語も含めた様々なメディアAI技術の研究開発に今後も積極的に取り組んでいきます。 アカデミックな研究に注力したくさん論文を書きたい 最新の技術をいちはやく取り入れ実用化に結び付けたい AIアルゴリズムに加え、AI/MLシステム全体の最適な設計を模索したい という方々に活躍していただけるフィールドがNTT Comには多くあり、一緒に技術開発を進めてくれる仲間を絶賛募集中です。 Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. Attention is all you need. In Advances in Neural Information Processing Systems, pages 5998–6008, 2017. ↩ Alexey Dosovitskiy, Lucas Beyer, Alexander Kolesnikov, Dirk Weissenborn, Xiaohua Zhai, Thomas Unterthiner, Mostafa Dehghani, Matthias Minderer, Georg Heigold, Sylvain Gelly, Jakob Uszkoreit, and Neil Houlsby. An image is worth 16x16 words: Transformers for image recognition at scale. In International Conference on Learning Representations, 2021. ↩ Jia Deng, Wei Dong, Richard Socher, Li-Jia Li, Kai Li, and Li Fei-Fei. Imagenet: A large-scale hierarchical image database. In 2009 IEEE conference on computer vision and pattern recognition, pages 248–255. Ieee, 2009. ↩ Alexey Dosovitskiy, Lucas Beyer, Alexander Kolesnikov, Dirk Weissenborn, Xiaohua Zhai, Thomas Unterthiner, Mostafa Dehghani, Matthias Minderer, Georg Heigold, Sylvain Gelly, Jakob Uszkoreit, and Neil Houlsby. An image is worth 16x16 words: Transformers for image recognition at scale. In International Conference on Learning Representations, 2021. ↩ Hugo Touvron, Matthieu Cord, Matthijs Douze, Francisco Massa, Alexandre Sablayrolles, and Herve J ´ egou. Training ´ data-efficient image transformers & distillation through attention. arXiv preprint arXiv:2012.12877, 2020. ↩ Tsung-Yi Lin, Michael Maire, Serge Belongie, James Hays, Pietro Perona, Deva Ramanan, Piotr Dollar, and C Lawrence ´ Zitnick. Microsoft coco: Common objects in context. In European conference on computer vision, pages 740–755. Springer, 2014. ↩ Golnaz Ghiasi, Yin Cui, Aravind Srinivas, Rui Qian, TsungYi Lin, Ekin D Cubuk, Quoc V Le, and Barret Zoph. Simple copy-paste is a strong data augmentation method for instance segmentation. arXiv preprint arXiv:2012.07177, 2020. ↩ Siyuan Qiao, Liang-Chieh Chen, and Alan Yuille. Detectors: Detecting objects with recursive feature pyramid and switchable atrous convolution. arXiv preprint arXiv:2006.02334, 2020. ↩ Taesung Park, Ming-Yu Liu, Ting-Chun Wang, and Jun-Yan Zhu. Semantic image synthesis with spatially-adaptive normalization. In CVPR, 2019. ↩ Liang-Chieh Chen, George Papandreou, Iasonas Kokkinos, Kevin Murphy, and Alan L Yuille. DeepLab: Semantic image segmentation with deep convolutional nets, atrous convolution, and fully connected crfs. IEEE TPAMI, 2017. ↩ Xun Huang, Ming-Yu Liu, Serge Belongie, and Jan Kautz. ↩ Arun Mallya, Ting-Chun Wang, Karan Sapra, and Ming-Yu Liu. World-consistent video-to-video synthesis. In ECCV, 2020. ↩

お久しぶりです。データプラットフォームサービス部の花川です。 最近は気温の変化が激しいですね。みなさまも体調を崩さないようご自愛ください。 さて、今日は、11月7日(日)に開催した第1回TechWorkshop「現場のエンジニアと一緒に解く！コーディング体験」についてご紹介です! 本イベントは、今月下旬にも再度開催予定なので、この記事を読んで興味を持った学生の方は、参加申込をお待ちしております! *1 TechWorkshopって? 公式ページ の説明は以下の通りです。 各技術分野のプロフェッショナル社員がお届けする、当社の最先端技術を体感し、また身に付けることができるワークショップ形式のプログラムです。 過去にはこのようなワークショップを開催しました。 ISPネットワーク構築・運用体験 Kubernetesハンズオン ソフトウェアエンジニア座談会 CI/CDハンズオン どのワークショップも、公式ページの説明の通り、各分野を主な業務にしている/業務に使っている社員が講師となり、かつ自分たちでイベントの企画からしているものとなります。 今年度もいくつか開催予定ですので、興味のある方はぜひ参加申込をお願いします *2 。 「現場のエンジニアと一緒に解く！コーディング体験」とは このイベントは、TechWorkshopの中でも珍しい、NTT Comで実際にソフトウェアを開発している社員と学生さんでチームを組んで、とあるお題に沿ってコードを書いてもらうイベントです。 コードを書く体制として、 モブプログラミング(モブプロ) を採用しています。 つまり、社員/学生問わずワイワイガヤガヤと1つの画面を見ながらプログラミングのお題に挑戦してもらいます。 このワイワイガヤガヤを通して、「NTT Comのソフトウェアエンジニアがどんな感じなのか」だったり自分の技術のいい点や今後キャリアを考えたときの課題を感じてもらおうという趣旨です。 イベント自体は、数年前から開催しており、直近数回はとあるOSSをモチーフにした「お題」を作って取り組んでもらっています。 お題は、できるだけNTT Comでの開発の普段の業務に近くなるよう選んでおり、かつ取り組む背景も「業務で必要になった」体としています。 また、お題に対してStep by Stepで解けるように問題を設定しています。 とはいえ、これに沿ってただ作っていくのもつまらないので、"ちゃんと考えて作らないと"Stepを進めるにつれて難しくなるよう設定をしています。 当日の様子 今回のTechWorkshopは、学生さんが33人、社員が13人が参加しました。 また、このご時世ですのでZoomを使ったリモート開催となりました。 参加社員の多くはSmart Data Platformの開発に携わるエンジニアで、他にも社内フレームワークの開発やNWを活用したサービス開発のエンジニアも参加しています *3 。 当日のプログラムは、ざっくり以下の5つでした。 なお、当日のモブプロセッションでは replit というオンラインで同時編集できるIDEサービスを利用しています。 講義 モブプロ セッション1 モブプロ セッション2 解説 懇親会 (この記事では触れません) 講義パート まずは、モブプロを体験したことのない参加者も多いため、簡単にモブプロの紹介をしました。 その後、実際チームに分かれて、アイスブレイクということで自己紹介をしたり、練習問題に取り組んでもらったりします。 モブプロ セッション1 セッションでは、このようにワイワイと「これはこうだ」「いやこうだ」みたいな感じでディスカッションしながら楽しんでいるようでした。 セッションが終わった後は、同様にチームでコードレビューやふりかえりを実施して、社員を含めた参加者全員で学びを共有したりしました。 ちなみに、出題の意図通り、とあるStepで設計が行き詰まるチームも多かったようです。 モブプロ セッション2 後半も、チームメンバーをシャッフルした上で同じお題にチャレンジしてもらいました。 前半の経験やふりかえりを元に、きれいな設計や実装ができているチームが多かったようです。 見づらいですが、上手く動いて「ヤッター」とみんなで喜ぶなど、和気あいあいとした雰囲気でコードを書いています。 セッションの終わりには再度コードレビューやふりかえりを実施してもらいました。 問題の理解度も深まっていたのか、コードレビューではより具体的に「普段社員が設計や実装のときに注意していること」や、普段の業務風景などいろいろな質問のやり取りが行われていました。 解説 解説では、今回の問題のテーマとなったOSSの紹介や、なぜこういった題材にしたのかを簡単に説明しました。 が、ネタバレになるのでここの説明は省略します! 気になる人はぜひこのイベントに参加してください! 参加者の声 参加アンケートには、こんなコメントが寄せられていました。 多くの方に「ためになった」「楽しかった」と思ってもらえたようで、企画した社員一同とても嬉しいです。 メンバーの方と意見を出し合いながら開発を進めることができ、チーム開発やモブプログラミングの楽しさを感じた 同じ学生同士でコーディングの仕方の違い、伝え方、聞き方、考え方について色々感じることができた 実際に運用されているサービスをもとにしたテーマを扱ったため、考え方など勉強になった おわりに この記事では、11月7日(日)に開催された第1回TechWorkshop「現場のエンジニアと一緒に解く！コーディング体験」について、紹介しました。 例年このようなイベントを企画運営していますが、参加する学生のみなさんが楽しくなると同時に、社員も楽しい時間を過ごせるイベントとなるよう心がけています。 やはり、自分たちが楽しむことで、イベント全体がより良いものになりますからね。 今後も、TechWorkshopを始めとして、参加する人たち全員が楽しめるイベントを企画運営していければと思っています! ここで耳寄り情報ですが、同じ内容で11月28日(日)に第3回 TechWorkshop「現場のエンジニアと一緒に解く！コーディング体験」として開催予定です。 応募締切は11月14日(日)となっていますので、この記事を読んで興味を持った学生の皆さんはぜひご応募ください! www.ntt.com *1 : 参加申込多数の場合、抽選にて決定いたします *2 : TechWorkshopは学生が対象となっています *3 : 懇親会後の写真なのでみんなゆるい感じで写っています

はじめに こんにちは、イノベーションセンターの鈴ヶ嶺・齋藤です。普段はコンピュータビジョンの技術開発やAI/MLシステムの検証に取り組んでいます。10月11日から17日にかけて、コンピュータービジョン分野におけるトップカンファレンスのひとつである ICCV2021 がオンラインで開催され、NTT Comからは複数名が参加しました。ここでは、会議の概要と参加メンバー2名からICCV2021の論文紹介をします。 ICCV2021 ICCV（International Conference on Computer Vision）は、2年ごとに開催されるコンピュータービジョン分野におけるトップカンファレンスのひとつです。2021年は10月11日から17日にかけて、オンラインで開催されました。 アクセプトされた国の比率は上記のようになっており、中国とそれに続いてアメリカが多数を占めていました。一昨年のICCV2019からおよそ1800件の投稿が増えて6152件が投稿されました。そのうちの26%である1612件の論文が採択される結果となりました。また、口頭発表には3.4%の210件が選ばれました。 論文紹介 ここからは参加メンバーが気になったICCV21の論文と実際にコードを動かした結果を紹介します。 COMISR: Compression-Informed Video Super-Resolution(ORAL PAPER) COMISRとは 今までの多くの映像の超解像手法は圧縮を考慮せず、低解像の動画から高解像の動画に変換しています。しかし、日常で使用しているwebやモバイルのコンテンツの多くは圧縮されています。この論文では、そのようなコンテンツを対象として、圧縮情報を用いた映像の超解像手法を提案しています。 COMISR 1 は、Recurrentモデル 2 をベースにしています。一般的な動画圧縮には、イントラフレームと呼ばれる他のフレームを予測するのに用いられる参照フレームを使用します。イントラフレームは独立に圧縮され、他のフレームはそのイントラフレームからの差分情報のみを使用して復元することから高い圧縮率を達成することが可能となります。このイントラフレームの位置はランダムに選択され事前には分からないため、Recurrentモデルのような前後関係を踏まえた特徴を抽出可能なモデルが使用されます。また、Recurrentモデルはメモリ消費も少なく動画の様々な推論タスクに適しています。 次の画像が、手法の全体像です。提案手法は、主に3つのモジュールのBi-directional Recurrent Module, Detail-aware Flow Estimation, Laplacian Enhancement Moduleから構成されます。 原論文から引用 Bi-directional Recurrent Module Bi-directional Recurrent Moduleを用いることで前方と後方からのフレーム予測に対して一貫性を強制し、精度を向上させています。まず初めに、入力された低解像の画像を後述するDetail-aware Flow Estimationにより高解像のオプティカルフローを推定します。次に、推定した高解像画像に後述するLaplacian Enhancementによりラプラシアン残差を付加してspace-to-depthを経て高解像画像の生成処理をします。 Detail-aware Flow Estimation Detail-aware Flow Estimationでは、隣接する低解像、高解像の画像の差分を表現したオプティカルフローを推定することであるフレームの次のフレームを生成します。上記の全体像ではフォワードの際の例が示されており、隣接する低解像の画像2つを連結したものを入力としてフローを推定します。その際には、直接フローをアップサンプリングするのではなく追加でdeconvolution層を通します。このようにして、end-to-endな学習や高周波の詳細な特徴を獲得することが可能となります。 Laplacian Enhancement Module ラプラシアン残差は、多くの視覚タスクで使用されており非常に有用な詳細情報です。しかし、この情報はアップスケーリングネットワークでは容易に失われてしまうため、ラプラシアン残差を高解像の予測フレームに追加することで補完します。具体的には次の式のようにガウシアンフィルターを用いて残差を追加します。 原論文から引用 実験結果 提案したCOMISRモデルをVid4 3 、REDS 4 をCRF23で圧縮したデータセットを使用して既存の超解像モデルと比較した結果が次のようになります。提案手法は大幅な性能向上を達成しました。 原論文から引用 次に、Vid4のいつかの結果を示します。定性的に比較してCOMISRが最も復元されていることが分かります。 原論文から引用 実際に動作させた結果 次のツールを事前に準備しておきます。 ffmpeg gsutil 以下が実際に動作させたものになります。 git clone --depth 1 https://github.com/google-research/google-research.git cd google-research/comisr # install package pip install -r requirements.txt # オリジナル動画を準備します (origin.mp4) # cp /path/to/origin.mp4 . # 解像度の確認 ffprobe -v error -select_streams v:0 -show_entries stream =width,height -of csv = s =x:p = 0 origin.mp4 # 1920x1440 # オリジナル動画を低解像に変換します (lr_4x.mp4) ffmpeg -i origin.mp4 -crf 0 -vf scale =480:-1 lr_4x.mp4 # 解像度の確認 ffprobe -v error -select_streams v:0 -show_entries stream =width,height -of csv = s =x:p = 0 lr_4x.mp4 # 480x360 # 低解像動画を圧縮します (lr_4x_crf25.mp4) ffmpeg -i lr_4x.mp4 -vcodec libx264 -crf 25 lr_4x_crf25.mp4 # download pre-trained model gsutil cp -r gs://gresearch/comisr/model/ . # input, target dataを準備します mkdir -p data/hr/linux_kernel ffmpeg -i origin.mp4 -r 60 data/hr/linux_kernel/img%05d.png mkdir -p data/lr_4x/linux_kernel ffmpeg -i lr_4x.mp4 -r 60 data/lr_4x/linux_kernel/img%05d.png mkdir -p data/lr_4x_crf25/linux_kernel ffmpeg -i lr_4x_crf25.mp4 -r 60 data/lr_4x_crf25/linux_kernel/img%05d.png # 出力先を用意します (output_dir) mkdir output_dir # 推論実行開始 export PYTHONPATH= $( dirname $ ( pwd )) python inference_and_eval.py --checkpoint_path=model/model.ckpt --input_lr_dir=data/lr_4x_crf25 --targets=data/hr --output_dir=output_dir # 結果 ## output_dir/linux_kernel/output_img00001.png ## output_dir/linux_kernel/output_img00002.png ## ... 今回は、詳解Linuxカーネル第3版の本を対象として実験してみました。以下は結果の抜粋です。 オリジナル画像 低解像画像 出力結果 ぱっと見ると、なかなか綺麗に処理されていると思われます。次に、もっと細部に注目して見ていきましょう。 こちらの結果は左下の「O'REILLY オライリー・ジャパン」という文字に着目しています。アルファベットの「O'REILLY」については綺麗に復元されていることが分かります。カタカナの「オライリー・ジャパン」については、「ミライリー・ジャパン」のように読める文字として復元される結果になりました。おそらく、「オ」は潰れてしまい人間の目で見ても非常にわかりづらいので復元するのが難しい結果となったと考えられます。その他のカタカナについては人間が見ても読める文字に復元されています。 こちらの結果は水晶を磨く人物画像に着目しています。水晶の細かな模様についてはあまりに潰れすぎており復元が難しいですが、人物の顔や服の模様などがある程度綺麗に復元されていることが分かります。 所感 超解像の対象として圧縮されたコンテンツに着目した手法を提案している実用面での有用性を感じました。 また、フレーム予測による圧縮技術から着想を経てBi-directional Recurrentを採用した点や高周波情報を追加する工夫がされている点が素晴らしいと感じ紹介させていただきました。 SOTR: Segmenting Objects With Transformers SOTRとは SOTR 5 とは、Segmenting Objects With Transformersの略で、インスタンスセグメンテーションのタスクにおいて、CNNとTransformerを組み合わせたモデルの提案を行なっています。SOTRは、この論文でTwinTransformerを新しく提案し、そこではEncoderが画像の縦方向と横方向のみをAttentionするようになるため、時間とリソースの効率を良く且つ精度の向上を達成したことが示されています。効率よく計算できる理由として、縦横の2次元のAttentionの計算オーダから画像の縦横方向の2つをそれぞれ1次元にAttentionの計算する((縦方向の要素数x横方向の要素数) 2 から (縦方向の要素数) 2 +(横方向の要素数) 2 )ためです。 原論文から引用 まず見ていただきたいのは、Figure 1の図です。ベンチなどの大きいオブジェクトに対しては、これまでのMaskR-CNN 6 などのモデルでもセグメントが可能でした。しかし、画像左上と右上にあるような、小さい画像に対してのセグメントの精度は高いとは言えませんでした。これについては、後ほどSOTRを動かしてみるので、目で見てわかるほどの違いを体感可能です。SOTRでは、画像の左上や右上の図のようにかなり小さいオブジェクトに対しても、セグメントを高精度に行うことができています。それを可能にしたのが、CNNとトランスフォーマーを組み合わせたモデルとなります。 原論文から引用 原論文から引用 モデルの概要について説明します。まず、BackboneはFPNの機構を用いて、P2~P6までの特徴量マップを求めます。先程Transformerでは、Positional Embeddingを行いTwin Transformerを実行し、Kernel HeadとClass Headを出力します。SOTRで提案されているTwin Transformerでは、各パッチとその行と列のみをAttentionしています。インスタンスのクラス分類は、ここで説明を行なったTransformer ModuleのClass Headから行います。Multi level Upsampling Moduleでは、Transformer Moduleから出力された低解像度なP5の特徴量マップを取得し、各層P2〜P4でアップスケーリングと結合を最終的にH×W特徴マップを作ります。マスクの予測のために、Transformer Moduleから出力された、Kernel Headを畳み込みKernelとMulti level Upsampling Moduleから出力されたH×W特徴マップを掛け合わせ、マスクを生成します。 実験結果 原論文から引用 上のテーブルはTwin TransformerとMask R-CNNやSOLO 7 などのインスタンスセグメーテーションのモデルの精度を比較したものとなります。学習用データセットは、MS COCO train2017 8 。評価用データセットは、test-devを使用しています。論文著者の学習環境は、32GのRAMを搭載したNvidia V100、4枚で学習されフレームワークにはPyTorchとDetectron2を用いています。結果として、SOTRがテーブルで示している他モデルよりも6つの評価指標のうち5つ(AP,AP50,AP75,APM,APL)において高い精度を示していました。 実際に動作させた結果 まず、SOTRはdetectron2上で動作させるためにはdetectron2, SOTRのセットアップをする必要があります。インストールするスクリプトを流しても良いのですが、PCの環境が汚れてしまうため、今回はDocker&Jupyter Notebookを立て、検証しました。自身の実行環境は、Ubuntu18.04、Single NVIDIA RTX3090です。 FROM nvidia/cuda:11.1.1-cudnn8-devel-ubuntu18.04 MAINTAINER Satoru Saito ENV DEBIAN_FRONTEND noninteractive RUN apt-get update && apt-get install -y \ python3-opencv ca-certificates python3.7-dev git wget sudo python3.7-distutils python3-pip cmake git wget sudo ninja-build && \ rm -rf /var/lib/apt/lists/* #python install RUN python3.7 -m pip install --upgrade pip RUN python3.7 -m pip install numpy RUN ln -sv /usr/bin/python3.7 /usr/bin/python && \ python -V # create a non-root user ARG USER_ID=1000 RUN useradd -m --no-log-init --system --uid ${USER_ID} appuser -g sudo RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers USER appuser WORKDIR /home/appuser ENV PATH= "/home/appuser/.local/bin:${PATH}" RUN wget https://bootstrap.pypa.io/get-pip.py && \ python get-pip.py --user && \ rm get-pip.py # install dependencies # See https://pytorch.org/ for other options if you use a different version of CUDA RUN pip install --user tensorboard cmake pycocotools RUN pip install torch==1.8.0+cu111 torchvision==0.9.0+cu111 torchaudio==0.8.0 -f https://download.pytorch.org/whl/torch_stable.html RUN pip install --user 'git+https://github.com/facebookresearch/fvcore' RUN pip --no-cache-dir install absl-py==0.10.0 backcall==0.1.0 cachetools==4.0.0 chardet==3.0.4 cloudpickle cycler==0.10.0 cython dataclasses decorator==4.4.2 future==0.18.2 fvcore==0.1.dev200325 grpcio==1.27.2 idna==2.9 ipykernel==5.2.0 ipython==7.13.0 ipython-genutils==0.2.0 jedi==0.16.0 jupyter-client==6.1.1 jupyter-core==4.6.3 kiwisolver==1.1.0 markdown==3.2.1 matplotlib numpy==1.18.2 oauthlib==3.1.0 opencv-python pandas==1.0.3 parso==0.6.2 pexpect==4.8.0 pickleshare==0.7.5 pillow==7.0.0 portalocker==1.6.0 prompt-toolkit==3.0.4 protobuf==3.11.3 psutil==5.7.0 ptyprocess==0.6.0 pyasn1==0.4.8 pyasn1-modules==0.2.8 pydot==1.4.1 pygments==2.6.1 pyparsing==2.4.6 pytz==2019.3 pyyaml==5.3.1 pyzmq==19.0.0 requests==2.23.0 requests-oauthlib==1.3.0 rsa==4.0 scipy==1.4.1 seaborn==0.10.1 six==1.14.0 tabulate tensorboard tensorboard-plugin-wit==1.6.0.post2 termcolor==1.1.0 tornado==6.0.4 tqdm==4.43.0 traitlets==4.3.3 urllib3==1.25.8 wcwidth==0.1.9 werkzeug==1.0.0 yacs==0.1.6 networkx==2.3 python-Levenshtein Polygon3 shapely graphviz # install detectron2 RUN git clone https://github.com/facebookresearch/detectron2 detectron2_repo # set FORCE_CUDA because during `docker build` cuda is not accessible ENV FORCE_CUDA= "1" # This will by default build detectron2 for all common cuda architectures and take a lot more time, # because inside `docker build`, there is no way to tell which architecture will be used. ARG TORCH_CUDA_ARCH_LIST= "Kepler;Kepler+Tesla;Maxwell;Maxwell+Tegra;Pascal;Volta;Turing" ENV TORCH_CUDA_ARCH_LIST= "${TORCH_CUDA_ARCH_LIST}" RUN pip install --user -e detectron2_repo # Set a fixed model cache directory. ENV FVCORE_CACHE= "/tmp" WORKDIR "/home/appuser" ENV PATH= "/home/appuser/.local/bin:${PATH}" # Jupyter Notebook RUN pip install jupyter && \ mkdir /home/appuser/.jupyter && \ echo "c.NotebookApp.ip = '*'" \ "\c.NotebookApp.port = '8888'" \ "\nc.NotebookApp.open_browser = False" \ "\nc.NotebookApp.token = ''" \ > /home/appuser/.jupyter/jupyter_notebook_config.py EXPOSE 8888 WORKDIR "/home/appuser/detectron2_repo" RUN git clone https://github.com/easton-cau/SOTR.git RUN cd /home/appuser/detectron2_repo/SOTR && \ sudo python setup.py build develop 以上のDockerfileをbuild&runします。 TerminalからJupyterの起動し、任意のディレクトリに SOTR_R101_DCN をダウンロードをします。また、自身の解析したい画像のパスを --input に指定し以下のコードを走らせると推論を始めます。 python SOTR/demo/demo.py \ --config-file SOTR/configs/SOTR/R_101_DCN.yaml \ --input hoge.jpg --output ./SOTR/outputs/ \ --opts MODEL.WEIGHTS ./SOTR/SOTR_R101_DCN.pth 今回私は、MSCOCO val2017から一枚を選び推論をしました。一枚目の画像は、Methodが、MaskR-CNNでBackboneがResNet50 9 。2枚目は、MethodがSOTRでBackboneがResNet DCN101となります。2枚を比較すると、奥にいる小さい人のセグメントが上がっていることが分かります。直感的にも、精度が向上していることが分かりました。ここからは、私の考察になってしまうのですがTwin Transformerが、MaskR-CNNと比較し小さい物体のセグメントをできている理由として、Transformer層で画像の縦横をピクセル単位でAttentionを行なっているため、局所的な特徴量の抽出が可能になっているのではないかと考えられます。今回は、定量的な評価はしないのですが、機会があれば検証したいです。 maskR-CNN ResNet50 SOTR ResNet DCN101 所感 ここでは、インスタンスセグメンテーションのタスクにおいて、CNNとTransformerを組み合わせたモデルについて説明しました。オリジナルのTransformer Encoderよりも、メモリの消費量を減らし且つ、精度の向上が論文中に示されていたので、興味を持ちご紹介しました。 最後に ここまで前編では、ICCV2021の概要と発表された論文の一部をご紹介しました。後編も引き続き気になった論文を紹介するのでぜひご覧になってください。 NTT Comでは、今回ご紹介した論文調査、画像や映像、更には音声言語も含めた様々なメディアAI技術の研究開発に今後も積極的に取り組んでいきます。 アカデミックな研究に注力したくさん論文を書きたい 最新の技術をいちはやく取り入れ実用化に結び付けたい AIアルゴリズムに加え、AI/MLシステム全体の最適な設計を模索したい という方々に活躍していただけるフィールドがNTT Comには多くあり、一緒に技術開発を進めてくれる仲間を絶賛募集中です。 Li, Yinxiao, Pengchong Jin, Feng Yang, Ce Liu, Ming-Hsuan Yang, en Peyman Milanfar. “COMISR: Compression-Informed Video Super-Resolution”. In Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV), 2543–52, 2021. ↩ Takashi Isobe, Xu Jia, Shuhang Gu, Songjiang Li, Shengjin Wang, and Qi Tian. Video super-resolution with recurrent structure-detail network. In ECCV, 2020. ↩ Jie Liu, Wenjie Zhang, Yuting Tang, Jie Tang, and Gangshan Wu. Residual feature aggregation network for image superresolution. In CVPR, 2020. ↩ Seungjun Nah, Sungyong Baik, Seokil Hong, Gyeongsik Moon, Sanghyun Son, Radu Timofte, and Kyoung Mu Lee. Ntire 2019 challenge on video deblurring and superresolution: Dataset and study. In CVPR Workshops, 2019. ↩ Guo, Ruohao, Dantong Niu, Liao Qu, en Zhenbo Li. “SOTR: Segmenting Objects With Transformers”. In Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV), 7157–66, 2021. ↩ Kaiming He, Georgia Gkioxari, Piotr Dollár, and Ross Girshick. Mask r-cnn. In Proceedings of the IEEE international conference on computer vision, pages 2961–2969, 2017. ↩ Xinlong Wang, Tao Kong, Chunhua Shen, Yuning Jiang, and Lei Li. SOLO: Segmenting objects by locations. In Proc. Eur. Conf. Computer Vision (ECCV), 2020. ↩ Tsung-Yi Lin, M. Maire, Serge J. Belongie, James Hays, P. Perona, D. Ramanan, Piotr Dollár, and C. L. Zitnick. Microsoft coco: Common objects in context. In ECCV, 2014. ↩ Kaiming He, Xiangyu Zhang, Shaoqing Ren, and Jian Sun. Deep residual learning for image recognition. In Proceedings of the IEEE conference on computer vision and pattern recognition, pages 770–778, 2016. ↩

はじめに こんにちは。プラットフォームサービス本部 データプラットフォームサービス部でSmart Data Platform (SDPF) のサービス企画を行っている安井・小野です。閲覧頂きありがとうございます。 DX推進にはデータ利活用が不可欠です。その実現には多くの困難が伴います。 当社では、そんな状況の解決をお手伝いすべくSDPFを提供しています。ここでは、当社が提供しているSDPFを皆様に知って頂くために、具体的な利用例と取り組みについてご紹介します。 Smart Data Platform (SDPF) とは SDPFは、企業に点在するデータを1つのプラットフォーム上でシームレスに融合。データを整理して利活用しやすくすることで、 日々の活動から産まれるデータを企業成長のエンジンに変える、次世代のプラットフォームです。 多くのお客様にご利用頂いてます当社の回線サービス(Arcstar Universal One、OCN、モバイル)を起点として、クラウド上に多くのデータを蓄積し、 そのデータを使用目的に応じて利活用するデータ活用基盤のような形でご利用いただけます。 SDPFは約60ものサービスの集合体で、データ利活用に有効なサービスを多くラインナップしています。 2021年5月にはサービスラインナップ、ポータルサイト、お客様導線の見直しを実施し、よりお客様が使いやすいサービスにすべく改善を続けています。 お客様にご利用頂くために - 複雑化する業務課題への対応 お客様が自らの業務課題を解決するにあたり、これまではお客様自身やSIerの方々が数多くのサービス機能を1つ1つ確認しながら、 自身で組み合わせを行い最適なサービス組み合わせを探してこられたかと思います。 我々はそのお手伝いをさせて頂くことを目的に、お客様の業務課題をあらかじめ想定して、複数サービスを組み合わせた動作確認や機能検証を行いました。 そして、これらの取り組みで得られた知見や手順を Smart Data Platform Knowledge Center にTIPSとして記載する取り組みを実施しています。 以降では複数サービスを組み合わせて検証できる環境を作るところから始めた、サービス企画チームの取り組みをご紹介します。 検証を通じた確認 実際に検証環境を作ってみた 「オンプレ/DC疑似環境(SDPF-LAB＠川崎)　～　 Flexible InterConnect (FIC) 　～　SDPFクラウド/サーバー」 ユーザー環境に近づけるため、下図のようにあえてオンプレ環境や専用線についても作成し、構築の工数や注意点などを実際に確認してみました。 実際に検証を実施してみた ①クラウドへのリフト＆シフトの実現、閉域網やクラウド型ストレージを利用したバックアップ基盤の活用 Arcserve UDP を用いてオンプレ環境のバックアップデータを、 FIC経由で Wasabiオブジェクトストレージ(Wasabi) に保存、 さらに IaaS Powered by VMware (IPV) 環境にリストアを行う検証をしました。 ②クラウドへのリフト＆シフトの実現、開発環境のクラウド化と匿名化した本番データの活用 SDPFサービスの1つである データ匿名化ツール(tasokarena) を利用。 Terraform、AnsibleといったInfrastructure as Code (IaC)ツールを活用し、環境構築の簡易化と匿名データ活用の検証をしました。 ③多様なサービスに対応するログ蓄積基盤の構築とその活用 Wasabiへのデータ格納ツールやWindows・LinuxへのWasabiマウントツール、さらにログ管理ツールといった複数のツールを活用することにより、 ログの蓄積・活用するための検証をしました。 確認後の具体的な気づきポイント ①の事例ではArcserve UDPやWasabiについてのまとまった情報が記載されているサイトが少なく、かつ確認に時間を要しました。 例えばWasabiのバケットに対するアクセス制限のポリシー設定や、FIC経由でWasabiにバックアップを行う場合に、 Wasabiのアドレスをルーティング設定する必要がある等、時間を掛けて要件確認していきました。 以下はWasabiのバケットに対するアクセス制限のポリシー設定の書き方となります。 Wasabi Management Consoleで対象バケットを選択して「Settings」マーク（歯車のマーク）をクリックし、 「POLICIES」タブをクリックして、表示された画面でポリシーを設定します。 ※「IPアドレスx/サブネット」の個所でアクセスを許可したいIPアドレスで設定する。複数ある場合はカンマ（,）で区切って指定します。 ---- { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "IPアドレス1/サブネット", "IPアドレス2/サブネット" ] } } } ] } ---- 他にもArcserve UDPの各エージェントで管理者アカウント以外のユーザーを使用する場合等、注意点がありました。 このように利用者目線で実際に使ってみて分かったことが多々ありました。 こういった点を、お客様が使いたいときに速やかにご利用できることを目指してKnowledge Centerへ記載しました。 お客様への見える化 Knowledge Centerでは検証を通して得られた知見や手順を記載していますが、オファリングサイトでは概要的な利用イメージをご理解いただくための内容を記載しています。 概要的な部分を確認したい場合はオファリングサイトをご確認ください。 オファリングサイトへの記載 Knowledge Centerへの記載 最後に 実際の構築活動を通じて、複数のサービスを組み合わせる際の手順的なコツであったり、組み合わせによっては注意点が存在したりすることが分かりました。 これからもお客様目線で実際に手を動かし、実用性のあるSDPFの組み合わせ構成を作っていき、 分かりやすくお伝えするためにKnowledge Centerへの記載拡充を行っていきます。 「ここの記載がわかりにくい」等のご意見や、「SDPFでこんなことができないか」等の疑問がありましたら、以下メールアドレスに対してお気軽にコメント等ご連絡ください。 sdpf-testbed-02＠ntt.comにメールを送る ※お手数ですが＠を全角文字から半角文字に置き換えてください。 ありがとうございました。

はじめに こんにちは、インターン生の櫻井幸大です。普段は大学院で 社会基盤インフラマネジメント について研究をしています。 今回私は 9月16日から30日にかけて、約2週間に渡り行われた職場体験型インターンシップ（エンジニアコース）に参加させて頂きました。この記事ではインターンシップの体験記として、どんな内容に取り組んだのか、職場の環境はどのような感じなのかをご紹介します。 インターンシップ参加の経緯 梅雨に入ろうとするくらいの時期に就活を始めた私は（と言ってもただ某大手就活サイトに登録申請を送りやった気になっていただけですが）、夏前までは「インターンシップか～、どこかの会社に行ってみなくちゃな～」と漫然と思い過ごしていました。しかしいざ大学が夏休みに入ると、周りの友人が次々とインターンを開始する中で「もしかして自分もそろそろマズいのでは」と焦りを抱え始めました。 自分のやりたいことに思いを巡らせる中、インフラ工学を専攻している立場として、「 インフラ関連の会社なら自分も何かにコミット出来るのかも 」「 どうせインフラを扱うなら時代の超々最先端を行く情報基盤について勉強したい 」と思い描くようになりました。 そのままの流れで情報基盤の会社を検索し、技術や知識もなくただ熱意だけを込めた ESを書き上げ、志望部署の欄に「ネットワーク基盤」と丸をつけそのままエイヤっと提出したところ、とても幸運なことに合格の通知を頂くことが出来ました。 以上の経緯で、NTTコミュニケーションズさんのところで二週間の実習に励む運びとなりました（ちなみに体験型ワークショップの方には見事に落選しました）。 インターンシップに参加する前は NTTコミュニケーションズという会社について知っている単語はOCNのみで、長距離の通信をやっている会社なんだな～というぼんやりとした理解に留まっていました（それも公式のYoutubeで見た情報です）。 NTTコミュニケーションズが MVNO事業をやっているということも知らずにmobile関連の部署で実習させて頂くこととなり「ほんとによくこんな体たらくで合格なんてもらえたな…」と今でも思っています。 インターンシップで取り組んだこと インターン前半期 このようにネットワークの基礎中の基礎も知らないままインターンシップに参加することとなった私ですが、もちろんこのまま業務に携わるわけにはいかないので、基礎の基礎を勉強するところからスタートしました（ここで初めてネットワークの階層モデルを知りました。当時の私はほんとにそういうレベルでした）。 勉強はトレーナーの方がほぼ付きっきりで見て下さったので、実際に使用される機器に触りながら、他に類を見ない速度で知識・技術を身に着けることが出来ました。とても楽しくワクワクしながら勉強できたことを今でも強く覚えています。トレーナーの方のピンポイントかつ丁寧で熱心な教育していただいたおかげもあり、たった一週間でゼロレベルの状態から BGPを用いた簡単なルーティングが出来るようにまでなりました。 ネットワークの基礎を学ぶのと同時に、配属されたグループの方々にはPCRF（モバイルのポリシー制御システムを司る機能）の更改についてや、今をときめく5G・Local 5Gの技術についての説明を受ける貴重な機会を頂きました。特に現状の携帯網で使われているEPC（スマートフォンから送られるパケットが基地局からインターネットに抜けるまでに通過する部分）の中の仕組みについてのお話や、これが5Gになって5G COREへとガラリと変革する、といった内容がとても面白かったです。 総じて、前半期では 技術の基礎から今起こっている問題や実際の事業現場のお話まで、非常に幅広い内容のお話を聞く機会を提供して頂けました。 配属されたグループにおいて、たくさんの人からが何をどう思いながらお仕事に取り組んでいらっしゃるのかを吸収することが出来ました。この期間で自分の中で会社のイメージはかなり大きく良く変わりました。 インターン後半期 インターンシップの後半では「次期ネットワークに更改するにあたり検討されているClos Fabricネットワークを構成する機器が、ルーティング広告の負荷に耐えられるのかを検証するシステムを構築する」という実際の業務に少しだけ関わらせて頂きました（といっても自分の方から何かを提案させていただくというものではなく、実際の開発の現場を体験するといった内容です）。 ネットワークは構成機器がそれぞれのルーティングテーブルを正しく保持することでパケットのやり取りが可能となり、これが正確でなければきちんとパケットが正しく伝達できません。 今回新しく導入が検討されているClos Fabricネットワークでは、EVPN/VXLANというプロトコルを用いてルーティングのアドバタイズが行なわれています。ネットワークが正しく使えるかどうかを確かめるためには、アドバタイズされた通知を受けて各構成機器がきちんとルーティングテーブルを更新しているかどうかを検証することが必要です。 プロトコルエミュレータを用いて行うこの検証を自動化する仕組み（アドバタイズをもとにルーティングテーブルが更新されているかを確かめる仕組み）について、今回自分が実習の中で制作に携わらせて頂きました。 開発は、Dockerを用いて仮想化された実行環境上で行いました。コンテナ技術とは OSの上で開発環境の切り離しを行いプロセス分離による処理の軽量化を実現した仮想化技術のことであり、これによってハードウェアの状態と切り離した状態の中で開発環境を動かすことが可能となります。こうすることで開発する個人の状態に依存しない開発環境の整備が出来るようになっていました。 更に、今回携わったチームにおける開発環境では、GitLabを利用することで多人数での同時的なコード開発・デバッグを実現する環境が整っていました（流石はソフトウェア開発分野の最先端の最前線）。Gitのシステムを初めて使わせてもらうこととなり、開発のツリーに自分の足跡をほんの少しでも残せたことが、とても嬉しかったです。 ちょうど自分のインターンシップ時期が次期ネットワークへの移行を模索している段階と重なったということで、ネットワークの網が張り替わる、まさに時代の変わり目に立ち会えたかのように感じました。 また、ネットワークが更改される作業にほんの一部分ですが携わることができ、そこに携わる社員の方々からたくさんのお話を伺うことを通じてシステムの増築・保守・維持管理・あるいはその先の未来に向けて俯瞰的な眼差しを持って基盤を創るのが大切だなぁ、と学びました。 今日の情報インフラ分野ではもの凄いスピードで技術革新が生み出され続けていく中で、自分も負けじと知識・技術を吸収し続ける、勉強し続け現場に応用していくことが改めて必要であると気づかされたような気がしています。 インターンシップを振り返って インターンシップを終えて私の抱く NTTコミュニケーションズの今のイメージは、「 将来の情報基盤に向けて挑戦を重ねる会社である 」と感じています。インターンシップ期間中に何度か配属されたグループの定例会に参加させて頂いたのですが、そこでの議題の内容が非常に濃く自分の中で印象に残っています。 システム間のリクエスト処理の仕組みや次期装置の更改に向けてのアジェンダを話し合う方々の姿を見て、 次の社会の下支えを積極的に創る熱意 を私は感じ取りました。その中のほんの小さな一端にでも自分の二週間が関われたことを、とても嬉しく感じました（Gitのログに名前を刻めたことが自分の何よりの宝物です）。 インフラは何かをするための基盤であり、なくてはならない下部のレイヤーです。だからといって使えればいいという簡単なものではなく、将来や時代を見据えた俯瞰的で総合的なアプローチが重要であると私は考えます。NTTコミュニケーションズは情報基盤を積極的により良くしようと果敢に挑戦されている、ということを会社で働く方々のお話を聞いて肌で感じましたし、「 志を高く熱意を持って社会に貢献したい 」という方にオススメの会社であると私は感じます。また、凄い人から凄い内容を学ぶ仕組みが充実しておりますので、「 自分の技術力を向上させていきたい 」という技術的な上昇志向の高い人にもオススメの会社と言えます。 また、今回のインターンシップは最初から最後まで全てリモート環境での実施とはなりましたが、それでも多くの方々に熱心に実習を支えて頂き、 社員の方々の温かさ というのも非常に色濃く感じました。 Slack等で何かを聞けばすぐ的確に答えて下さるトレーナーさんの優しさや、インターン生一人ひとりに業務用のパソコンを送付してくださったヒューマンリソース部さんのご厚意もあり、快適に、とても楽しく実習に取り組むことが出来ました。本当にありがとうございました。 さて、これから秋も深まる中、就職活動も次のフェーズへと移行していきます。今回のインターンシップでは無知の状態から情報インフラの分野に飛び込んでみて、ほんの少しの基礎を学ぶのと同時に、情報分野の果てしない広大さに打ちひしがれました。しかし、たくさんの人のお話を直に伺う中で「熱意」に関してはより一層高まったように感じます。 もちろん道は険しいのですが、「今の自分に何が足りないのか」はなんとなくでも見えてきたような気がしてますし、インターンで学んだ内容を精一杯活かしてより一層社会貢献できるようなエンジニアになれるよう、勉強にも尽力していければと思っています（もちろんESにも技術面からのアピールポイントを書けるように頑張ります）。NTTコミュニケーションズの皆さん、二週間という短い期間でしたが、本当にありがとうございました。 トレーナーからのコメント 今回インターンシップを担当した プラットフォームサービス本部データプラットフォームサービス部の溝口です。 櫻井さんは、ネットワーク関連の技術スキルは確かにほとんどゼロの状態でしたが、この2週間でネットワーク装置の検証の自動実行プログラムの作成ができるところまでスキルアップしてもらうことができました。これは櫻井さんの、物怖じせず疑問に思った点は何でも質問できるキャラクタによるものが大きいと感じました。今後ともぜひ続けていってほしいですね。 インターンシップを通じて開発部門において大きな割合を占める検証という業務を経験して、企業の中でエンジニアがどのように業務を行っているかイメージをもっていただくことができたのではないでしょうか。この経験を活かしてより一層就職活動や研究に励んでいただければ、トレーナーとしても嬉しい限りです。

はじめに こんにちは、インターンシップ生の田畑（GitHub: TBT0328 ）です。 9月16日から30日の2週間、NTTコミュニケーションズのインターンシップに参加させていただきました。 この記事では、インターンシップでどのようなことをしたのかを紹介します。 概要 今回私は、NTTコミュニケーションズ イノベーションセンターで制御システムネットワークのセキュリティ可視化技術である OsecT （オーセクト）の開発に関する業務を行いました。 今回のインターンシップは新型コロナウイルス感染拡大防止のため、全日リモート形式での実施でした。 参加のきっかけ 大学の研究室の先輩から「実際の業務（もしくはそれに近い業務）に携われるからとても楽しいよ！」と熱い（？）アピールを受け、ぜひとも参加したいと思い応募しました。 参加前の面接では、インターンシップでの業務内容を複数提示していただき、インターン生がやりたい内容に合わせてくれる柔軟性の高いインターンシップだと感じました。 インターンシップ内容 OsecT内で動くツールや仕様の一部変更、最新のLTSへのアップデートをDockerを使用してプログラム作成などを行いました。 ソースコードの管理はGitHubを使用しており、研究室でのコード管理とはまた違った、実際の業務環境で作業しました。 私自身、DockerやGitHubを使った経験があまりなく、GitHubへのPullRequestの投げ方や、Dockerfileの書き方などの基本的なことから教えていただきました。 下図はGitHubへのPushやDockerfileの書き方に悪戦苦闘して長くなってしまったコミット履歴です。 また、人が書いたコードの読み方や実装後のテスト方法などを教えていただきながら、OsecTのサービス化に向けて役に立てるようなことができたと感じています。 業務環境 全日リモート形式での開催ということで、自宅から参加しました。 NTTコミュニケーションズから、インターンシップで使用するPC、インターンシップ期間中の昼食代相当のチケットを支給していただきました。 OsecTの開発は自前のPCを使い、トレーナーの方やチームの方々とはSlackで連絡を取り合いました。 また、期間中毎日、インターンシップの進捗報告と今後の方針を相談する朝ミーティングを開いていただきました。 下図は朝ミーティング後のタスク確認の様子です。 イベントへの参加 期間中はすべてリモートということで、実際にオフィスに行くことはなかったのですが、複数の社内イベントに参加させていただきました。 NTTコミュニケーションズの技術顧問との対話会 インターンシップ生を対象にしたスペシャルイベントとして、NTTコミュニケーションズの技術顧問の方々との対話会を開催していただきました。 技術顧問との対話会と聞いて堅いイベントだと思っていたのですが、とてもカジュアルな対話会でした。 技術顧問の方々が実際にどのような業務・支援しているのか、技術顧問の方々が感じるNTTコミュニケーションズの印象など、リアルな職場を知ることができる対話会でとても勉強になりました。 イノベーションセンター内業務共有会 インターンシップ後半に差し掛かり、イノベーションセンターに所属するインターンシップ生同士での業務内容の共有会を開催していただきました。 期間中どのような業務を行ったか、どのようなことを学んだのかを発表していくという流れで、自分以外のインターン生が行った内容や、他チームが行っている業務について知ることができるイベントでした。 期間中はOsecTに関する業務を行っていたので、他インターン生が参加したプロジェクトやその有用性を多く学べる機会でした。 KOELによるデザイン研修 イノベーションセンター内のデザイン部門である KOEL の方々によるデザイン研修会を開催していただきました。 「デザイン思考」や「デザインプロセス」についてや、KOELがデザインした 「NeWork」 を開発する段階での具体的なデザイン思考についてお話をしていただきました。 アイデアの創出の前にすべきことや、それぞれのデザインプロセスで有用なフレームワークについて学ぶことができ、研究室での活動では得難い視点でとても新鮮で勉強になりました。 TechLunch NTTコミュニケーションズではランチの時間帯に、気軽に参加できる勉強会であるTechLunchが不定期に開催されており、インターン生も参加させていただきました。 今回は「リモートネイティブ新入社員のリアル」というテーマでイノベーションセンターの新入社員の方々に各々取り組んだ仕事についてお話していただきました。 新入社員が感じたリモート形式のメリット・デメリット、不安に感じることなどをお聞きでき、社員のリアルを知れました。 また、お話を聞きながら、他の社員の方が「〇〇に関してはもう少し深堀りしたほうがいいね」などと発言していらして、意見を発信しやすい環境なのだと感じました。 インターンシップを振り返って 今回のインターンシップを通して、様々なことを学ぶことができました。 Dockerを使った開発の進め方や、Gitを用いたコード管理などの技術的な部分はもちろん勉強になったのですが、それよりも、業務の進め方や業務を行う上での考え方がとても勉強になったと感じています。 作業が詰まったときに素早く相談する大切さ タスクとタスクの間の空き時間や、テスト中の空き時間をいかに利用するか タスクの優先順位、取捨選択、割り振りのスピーディーさ リモートでプロジェクトメンバとのこまめな連絡、簡潔かつ必要な情報の先出し意識の高さ これらを学べました。 また、社員同士の活発な、まめな連絡を見て、意見を発信しやすい環境なのだなと再認識しました。 おわりに 夏季インターンシップの内容や感想について書かせていただきました。 約2週間、OsecTに関する業務に携わらせいただいて、技術的にも成長できました。 また、業務を行う上で必要なスキルを持っているか、足りないスキルや考え方はどのようなものなのかを学ぶことができました。 今後の研究活動などにも活かす事ができるとても有意義な経験をさせていただきました。 NTTコミュニケーションズの皆様、大変お世話になりました。ありがとうございました。 トレーナーからのコメント 田畑さんのトレーナーを務めた鍔木（GitHub: takuma0121 ）です。 まずはインターンお疲れさまでした。 10日間という非常に短い期間でしたが、GitHubやDockerだけでなくパケット解析ツールのZeekなど初めて使うツールを学びつつ、OsecTの実装というアウトプットまで出せました。 また、フルリモートということで対面での業務はできませんでしたが、朝ミーティングやSlackを通じてコミュニケーションしつつ上手く業務に取り組めたのではと考えています。 このインターンの経験を研究や将来の仕事に少しでも活かしていただけると、トレーナーである私も嬉しいです。 インターンお疲れさまでした！

マネージド&セキュリティサービス部 セキュリティサービス部門 インシデントレスポンスチームの濱崎と戸祭です。 今回は、 前回 紹介したビジネスメールサービス「Microsoft Exchange Online」の監査ログについて、の後編となります。 前の記事（ 前編 ）ではログの種類と取得方法について説明しました。 後編ではログを記録しておくための設定方法について説明します。 目次 目次 前編の要約 ログの設定 Exchange Online Powershellへの接続 Unified Audit Log（統合監査ログ）の有効化 Mailbox Audit Log（メールボックス監査ログ）の設定 ログの保持期間の延長 まとめ 前編の要約 前編 では、以下のログの概要と、NTT Comでの調査に最低限必要なログの取得方法を説明しました。 Unified Audit Log（統合監査ログ） AzureADサインインログ Mailbox Audit Log（メールボックス監査ログ） Admin Audit Log（管理者監査ログ） Message Trace（メッセージ追跡） 後編では、これらのログを記録しておくための設定方法を説明します。 ログの設定 前編 で紹介したログは、既定では取られていない可能性があるため、ログを確実に残せるよう設定の確認と変更を推奨します。 またログの保存期間も既定では短いため、保存期間の延長を検討する必要があります。 この節では、Powershellを用いた適切なログ取得設定と保存期間の延長方法について紹介します。 Exchange Online Powershellへの接続 まずExchange Online Powershellに管理者権限をもつユーザでログインします。 > Install-Module -Name ExchangeOnlineManagement > Import-Module ExchangeOnlineManagement > Connect-ExchangeOnline -UserPrincipalName <User Principal Name, メールアドレス等> Unified Audit Log（統合監査ログ）の有効化 Unified Audit Logは、現在では基本的には既定で有効 1 です。 しかしライセンスや過去の設定によっては有効でない場合があるため確認を推奨します。 UnifiedAuditLogIngestionEnabled がTrueになっているかを以下のコマンドで確認します。 > Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled UnifiedAuditLogIngestionEnabled : True Falseになっていた場合、次の方法でTrueにしてください 7 。 > Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true （ただしNTT Com IRチームの検証用環境では上記コマンドの前に Enable-OrganizationCustomization の実行が必要でした。また反映まで数時間待つ必要がありました 8 。 エラーが出る場合はお試しください。） Mailbox Audit Log（メールボックス監査ログ）の設定 Mailbox Audit Logは、設定上では有効になっていても検索ができない、既定では取れない項目があるなど一部わかりにくい箇所があります。 基本的な設定をはじめとした、いくつかのポイントをご紹介します。 組織の既定の設定で監査が無効になっていないかを確認 監査の有効無効は、組織の既定、および各メールボックスごと、各ユーザごとに設定できます。 ただし公式のドキュメント 9 に以下のようにあることから、現在は各メールボックスごとの監査の有効無効の設定は無視され、常に組織の既定の設定が優先されるようです。 Turning off mailbox auditing on by default has the following results: Mailbox auditing is not enabled for new mailboxes and setting the AuditEnabled property on a new or existing mailbox to True will be ignored. Currently, you can't disable mailbox auditing for specific mailboxes when mailbox auditing on by default is turned on in your organization. そのため一番重要になる組織の既定の設定で、メールボックス監査が無効にされていないかを確認します。 > Get-OrganizationConfig |Select-Object -ExpandProperty AuditDisabled False もしTrue（監査が無効）だった場合、以下の方法でFalseにします。 > Set-OrganizationConfig -AuditDisabled $false ユーザごとに監査をバイパスしていないかを確認 組織の既定の設定で監査が有効になっている場合でも、ユーザごとに監査を無効にできます。 以下の方法でこの機能がFalseになっていることを確かめます。 MailboxIdentityとしてユーザ名やメールアドレスを渡します。 > Get-MailboxAuditBypassAssociation -Identity <MailboxIdentity> | Format-List AuditByPassEnabled AuditBypassEnabled : False もしTrue（監査をバイパス）になっていた場合、Falseに切り替えます。 > Set-MailboxAuditBypassAssociation -Identity <MailboxIdentity> -AuditBypassEnabled $false ユーザごとに行う必要があるため、スクリプトで自動化することを推奨します。 監査ログ検索を可能にする 既定でメールボックスの監査は有効になっていますが、公式ドキュメント 9 には以下のように注意書きがあります。 If mailbox auditing already appears to be enabled on the mailbox, but your searches return no results, change the value of the AuditEnabled parameter to $false and then back to $true. つまり監査が有効になっているように見えても、Microsoft 365 コンプライアンスセンターやPowershellコマンドレット等での監査ログ検索ができない場合があります。その際はメールボックスごとの監査の有効無効( AuditEnabled パラメータ)を切り替えて再び有効にすることが必要です。 #有効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $true #無効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $false #再び有効化 > Set-Mailbox -Identity <MailboxIdentity> -AuditEnabled $true メールボックスごとに行う必要があるため、スクリプトで自動化することを推奨します。 「高度な監査」を有効化 E5/A5/G5といったライセンスを使用すれば、「高度な監査」を使用してより詳しいログの調査が可能です 10 。 中でも有用なものは、 MailItemsAccessed イベントと SearchQueryInitiated 系イベントです。 MailItemsAccessed イベントはメールの閲覧を記録します。 読まれたメールが特定できる ため、漏洩した情報の特定に利用できます。 SearchQueryInitiated 系イベントは検索内容を記録します。攻撃者がどのような情報を探していたのか、意図をつかみやすくなります。 ただし、単一のメールボックスで1,000イベント/日と大量の監査レコードが生成された場合、そのメールボックスに関する MailItemsAccessed のログ生成が打ち切られるという注意点があります 11 。 「高度な監査」が有効になっているかは、次の手順で確かめることができます 12 。 Microsoft 365 管理センター > ユーザー > アクティブなユーザー > ユーザーをクリック > ライセンスとアプリ から右に出るペインのアプリ欄を見て、Advanced Auditingにチェックが入っていることを確認します。 高度な監査が有効になっている例 メールボックス操作の記録設定 Mailbox Audit Logは、ユーザ種別ごとにどんな操作を記録するか設定できます。 確実に必要なログを残すため確認することを推奨します。 公式ドキュメント 13 では以下の記述があるため、特にメールボックスオーナーについての設定は注意が必要です。 メールボックスオーナーの操作を監査すると、大量のメールボックス監査ログ エントリが生成される可能性があるため、既定では無効となっています。 （なお、NTT Com IRチームの検証環境では最初からメールボックスオーナーの監査が有効化されていたようでした。） ユーザ種別は3つあり、 AuditAdmin , AuditDelegate , AuditOwner です。 ユーザ種別ごとにロギング可能な操作一覧 9 を参考に、少なくとも同ページ表中の * マークが付いているものが有効になっていることを確かめてください。 次のようにして、ロギングされる操作の一覧を表示できます。例として以下ではメールボックスオーナー ( AuditOwner )に関して表示しています。 > Get-Mailbox <identity of mailbox> | Select-Object -ExpandProperty AuditOwner Update MoveToDeletedItems SoftDelete HardDelete UpdateFolderPermissions UpdateInboxRules UpdateCalendarDelegation ApplyRecord MailItemsAccessed Send もしメールボックスオーナーに関して MailItemsAccessed がロギングされない設定であった場合、以下のコマンドで有効にします。 > Set-Mailbox -Identity <identity of mailbox> -AuditOwner @{Add="MailItemsAccessed"} （コマンドでデフォルト設定と完全に同一か確認したり、デフォルト設定に戻したりすることも可能です。本記事のスコープ外なので詳しくは公式ドキュメント 9 を参照してください。） また、前セクションで触れた SearchQueryInitiated 系イベントのロギングをメールボックスオーナーに対して有効化します。 > Set-Mailbox -Identity <identity of mailbox> -AuditOwner @{Add="SearchQueryInitiated"} 以上の操作は全てのユーザのメールボックスに対して行うことが望ましいため、スクリプトでの自動化を推奨します。 ログの保持期間の延長 デフォルトでの保持期間は以下の通りです。 設定を変更する、ライセンスを契約する等でできる限り期間を伸ばしておくのが安心です。 ログ名 デフォルト保持期間 延長方法 UnifiedAuditLog (統合監査ログ) 90日-1年 2 ライセンス契約 *1 MailboxAuditLog (メールボックス監査ログ) 90日 9 AuditLogAgeLimit の値を増やす 13 AdminAuditLog (管理者監査ログ) 90日 3 - （オンプレミス版Exchangeなら可） 6 MessageTrace (メッセージ追跡) 90日 4 - Azure AD サインインログ 30日 5 - 将来のインシデント時にデータが残っていないと取れる対処の選択肢が狭まってしまいます。 以上を参考に、できる限り長期間のログを保持するようにしておくことをお勧めします。 更に長期間ログを保持したい場合、SIEMを使用することを推奨します。ログの活用も容易になります。 まとめ 前編 ではMicrosoft Exchange Online に関するログの種類と取得手順を説明し、後編ではログを記録しておくための設定方法を説明しました。 2つを併せて、来たるインシデントへの備えとしてご活用ください。 ログの分析については、各ログの意味の理解や、大量のログを処理しながらの頻度分析、アノーマリ分析、インテリジェンスを活用しての調査が必要となります。機会があれば別記事で解説したいと思います。 [1] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/turn-audit-log-search-on-or-off?view=o365-worldwide [2] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/audit-log-retention-policies?view=o365-worldwide [3] : https://docs.microsoft.com/en-us/exchange/security-and-compliance/exchange-auditing-reports/view-administrator-audit-log [4] : https://docs.microsoft.com/ja-jp/exchange/monitoring/trace-an-email-message/run-a-message-trace-and-view-results [5] : https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-reports-data-retention [6] : https://docs.microsoft.com/ja-jp/exchange/policy-and-compliance/admin-audit-logging/admin-audit-logging?view=exchserver-2019#admin-audit-log-age-limit [7] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/search-the-audit-log-in-security-and-compliance [8] : https://forum.devolutions.net/topics/31378/how-to-use-powershell-with-office-365-through-rdm [9] : https://docs.microsoft.com/en-us/microsoft-365/compliance/enable-mailbox-auditing?view=o365-worldwide [10] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/advanced-audit?view=o365-worldwide [11] : https://docs.microsoft.com/en-us/microsoft-365/compliance/mailitemsaccessed-forensics-investigations?view=o365-worldwide [12] : https://docs.microsoft.com/ja-jp/microsoft-365/compliance/set-up-advanced-audit?view=o365-worldwide [13] : https://docs.microsoft.com/ja-jp/exchange/policy-and-compliance/mailbox-audit-logging/enable-or-disable?view=exchserver-2019 *1 : Unified Audit Log（統合監査ログ）についてはライセンスによって異なり、E5などの上位のライセンスで高度な監査が有効な場合（既定で有効）、一部のRecodeTypeをもつログの保存期間が1年となります 2 。また特別なアドオンライセンスを契約すれば、最大で10年間保持することが可能です 10 。

マネージド&セキュリティサービス部 セキュリティサービス部門 インシデントレスポンスチームの濱崎と戸祭です。 今回は、Microsoft社がMicrosoft 365 (Office 365) 内で提供するビジネスメールサービス「Microsoft Exchange Online」の監査ログについて、不正アクセスの観点でお話します。 本記事は前後編に分かれており、前編ではログの概要と取得について説明します。 後編 ではログを記録しておくための設定について説明します。 はじめに Microsoft Exchange Onlineへの不正アクセスが発生した場合、いつ発生したか、どのアカウントが被害にあったか、どのようなデータが閲覧・持ち出されたか、どのような攻撃の踏み台にされたか、などを明らかにする必要があります。 ところが、Microsoft Exchange OnlineはAzureAD等いくつかのコンポーネントが連携しあって提供されており、調査に必要なログもまとまって管理されていません。また、Microsoft公式ドキュメントでも、どこにどのようなログが保存されているかインシデントレスポンスの観点で体系的にまとめられたものがありません。加えて、GUIでのログ閲覧機能では一部の情報が欠落するなどの問題があることが知られています。 いざというときにこのような調査ができるよう、事前に把握・準備しておくべき次の内容について簡単にまとめて紹介します。 不正アクセス調査に備えて取得すべきログの種類 （前編） ログの取得方法（前編） ログの設定方法（ 後編 ） なお、本記事の内容は、2021年9月執筆時点での公開情報とNTT Com IRチームで検証用に取得したライセンスでの検証結果に基づきます。商用ライセンスのグレードや契約形態によって、一部異なる事実が含まれる可能性があります。また、Microsoft社は不定期に仕様を変更しています。今後も仕様が変わる可能性がある点、ご了承ください。 目次 はじめに 目次 Microsoft Exchange Onlineとは 不正アクセス調査時に有用なログ Microsoft 365のUnified Audit Log (統合監査ログ) Azure Active Direcotryのサインインログ Exchange Onlineの監査ログ Exchange OnlineのMessage Trace ログ （メッセージ追跡ログ） ログ取得 Powershell vs 管理コンソール（ブラウザ）vs API ログ取得実施手順の概要 事前準備 1. 全ユーザに関するログの取得 2. 攻撃に関与した疑いのあるユーザのログ取得 まとめ Microsoft Exchange Onlineとは 　Microsoft Exchange Onlineは、Microsoft社が提供するメールホスティングサービスであり、同社が古くから提供しているMicrosoft Exchange Server機能をクラウド上で提供するものです。構築や運用の難易度が高いExchange Serverの管理から解放されること、また事業の継続性の確保(BCP) や柔軟な働き方を支援するインフラに適していることから、多くの企業に導入されています。 　一方で、攻撃者目線に立つと、世界中のどこからでもアクセス可能なメールサーバの存在は、メールデータの窃取が従来に比べて行いやすくなることを意味します。実際、ニュースや報道においてMicrosoft 365への不正アクセス事例が数多く報告されており、NTT Comにおいても相談数が増えているのが現状です。また、以前にNTT Comの旧技術ブログで紹介したように、ラテラルフィッシング攻撃も問題となっています。これらの攻撃の有無を確認するためにログが重要な情報源となります 1 。 不正アクセス調査時に有用なログ Microsoft Exchange OnlineはMicrosoft 365の一部として提供されています。また、Microsoft 365はAzureADをID管理として利用しているなど、いくつかのコンポーネントが連携しています。それぞれのコンポーネントがログを取得しており、ログの粒度や内容も異なることが、インシデントレスポンスにおけるログ調査を複雑にします 2 。 Microsoft 365, Exchange Online, Azure AD, ログ閲覧できる管理用サイトの関係性の図 上図のように、Azure ADやExchange Online等の各種サービスのログ情報の一部が、左のUnified Audit Logに収集されます。 しかしUnified Audit Logのみを見ればよいわけではありません。完全に同じログが収集されるわけではないためです。 以降では、それぞれのコンポーネントにおけるログサービスの名称や機能のうち特に不正アクセス調査に有用なログを紹介します。 Microsoft 365のUnified Audit Log (統合監査ログ) Microsoft 365が提供する各アプリケーション（Exchange Online, Sharepoint等）の監査ログを統合管理したもの 各アプリのそれぞれのログのうち、 一部が Unified Audit Logに転送される AzureADのサインインログやExchange Onlineの転送ルールの作成等が含まれるため、調査に有用 主に次の3つの方法で閲覧、ダウンロード可能 *1 Microsoft 365 コンプライアンスセンター > ソリューション > 監査 Exchange Online Powershellを利用したダウンロード 3 APIでのダウンロード Unified Audit Logの表示例 Azure Active Direcotryのサインインログ 4 ユーザのサインインに関する記録を提供 サインインに関する、日時、ユーザ名、送信元IPアドレス、サインインに使用したアプリケーション名、ブラウザ名等が記録されている 意図しないサインインかどうかの判定に利用可能 次の3つの方法で閲覧、ダウンロード可能 Azure AD 管理センター 5 > 監査ログ > サインイン Powershellを利用したダウンロード 6 APIを利用したダウンロード Azure AD 管理センターから閲覧可能なサインログ Exchange Onlineの監査ログ 主にMailbox Audit Log(メールボックス監査ログ)と Admin Audit Log(管理者監査ログ)に記録 各メールボックスに対するログインやメールアイテムの削除、受信ルールの追加／削除／変更などのログを提供 メール閲覧、検索のログを提供（「高度な監査」が使用できるライセンスでのみ利用可能） SessionIdを使いログインと操作のログを紐づけ 7 、攻撃者による メール閲覧履歴 や 転送ルールの作成 や削除されたスパムメール送信履歴の調査などに利用可能 主に次の3つの方法で閲覧、ダウンロード可能 Exchange 管理センター > (左下の) 従来のExchange 管理センター> コンプライアンス管理 > メールボックス監査ログのエクスポート、管理者監査ログのエクスポート Exchange Online Powershellを利用したダウンロード 8 , 9 APIを利用したダウンロード Exchange管理センターの監査ログ閲覧／ダウンロード画面 Exchange OnlineのMessage Trace ログ （メッセージ追跡ログ） メールの送受信ログを提供 攻撃者によるメール転送やスパム攻撃の踏み台有無の調査に利用可能 主に次の3つの方法で閲覧、ダウンロード可能 「Exchange管理センター」 -> メールフロー -> メッセージ追跡 Exchange Online Powershellを利用したダウンロード 10 APIを利用したダウンロード 11 Exchange管理センターから閲覧可能なMessage Traceログ ログ取得 推奨するログ取得方法や、実際の手順をコマンドレベルで説明します。 インシデント発生時の初動対応としてのログ保全や、平時に期限切れで消えてしまうログの定期的な保全などにお役立てください。 ただしログを記録しておくための設定をしておかないと、一部取得できないログがあります。設定方法については 後編 で説明するため、そちらも併せて参照することを推奨します。 Powershell vs 管理センター（ブラウザ）vs API ログを取得する手段としていくつかの方法が提供されていますが、NTT ComではPowershellコマンドレットでの取得を推奨しています。 Web の管理センター経由のログダウンロードでは一部のログの欠損が確認されています。その旨通知は出ずログの欠損に気付くことができないため、信頼できるログ取得の観点からは不向きと言えます。 一方でPowershellの場合、ログが欠損せず信頼性の点で優れています。さらにログ取得操作の自動化が容易で、そのため簡易的な操作で多くのログを扱えるログ取得ツールが有志により提供されています。以上の点でPowershellの使用を推奨します。 なお、APIも同様に信頼性と自動化の利点を持ち、ツールやシステムに組み込む際には有用です。しかし単に情報取得に使うには使用方法が複雑であるため、Powershell のほうが使いやすいと考えます。 注意点として、Powershellでたくさんのリクエストを送ると一定時間ロックされる可能性があるため、適切にリクエストレートを制限する必要があります。 ログ取得実施手順の概要 すべてのログをダウンロードすることが望ましいと言えますが、ログのダウンロード数上限やログサイズの観点から、ユーザ数の多い環境では一部のログのみダウンロードすることが現実解と言えます。 ここでは、NTT Comにおける調査に最低限必要なログをダウンロードする方法を紹介します。 なお、大規模テナントの場合、これらの方法でもダウンロード数上限に達し十分なログが取れない場合があります。大規模テナントをご利用されている場合は、SIEMの使用を推奨します。 ログの取得は次の流れで行います。 攻撃に関与したユーザを特定するため、サインインログを中心とした全ユーザに関するログ取得 1の解析により判明した攻撃に関与したユーザの詳細ログ取得 これらのログを取得するため、NTT Comでは次の2つのツールを利用します。これらの使い方について詳細に説明します。 HAWK 12 Office 365 Extractor 13 事前準備 各種ツールの日本語対応 HAWKやOffice 365 Extractorは現時点では日本語に完全対応はしていないためCSVに日本語が出力できません。これを回避するため Powershell console 上で次のコマンドを実行してから各種ツールを実行してください。 function Export-Csv(){ $input | Microsoft.PowerShell.Utility\Export-Csv @args -Encoding UTF8 } なお、一度 Poweshell console を閉じると、上記設定は無効化されます。Powershell console 起動の都度実行してください。 ExchangeOnlineManagement module のインストール Install-Module -Name ExchangeOnlineManagement 1. 全ユーザに関するログの取得 HAWKでのログ取得 次の通りにPowershellでコマンドを打ち、HAWKでログ取得します。 # HAWKのインストール > Install-Module -Name HAWK # HAWKを使う準備 > Import-Module HAWK # テナントの全ユーザについてログ取得 > Start-HawkTenantInvestigation 実行途中で指定したフォルダに、結果のファイルが出力されます。 Office 365 Extractorでのログ取得 Office 365 Extractorをダウンロードした後、スクリプトを実行します。 > .\Office365_Extractor.ps1 特定の種類のログを取得するため、3を入力します。 Following actions are supported by this script: 1 Show available log sources and amount of logging 2 Extract all audit logging 3 Extract group audit logging 4 Extract specific audit logging (advanced mode) 5 ReadMe 6 Quit Select an action: 3 取得したいログ種別としてAzureを選択するため、2を入力します。 1: Extract all Exchange logging 2: Extract all Azure logging 3: Extract all Sharepoint logging 4: Extract all Skype logging 5: Back to menu Select an action: 2 取得対象とするユーザとして全ユーザを指定するため、1を入力します。 Would you like to extract log events for [1]All users or [2]Specific users >: 1 Extracting the Unified Audit Log for all users... 取得期間を入力します。Enterキーだけを押すと本日から90日間前までが設定されます。 Please enter start date (format: yyyy-MM-dd) or ENTER for maximum 90 days: Please enter end date (format: yyyy-MM-dd) or ENTER for today: 取得間隔を分単位で入力します。 ログ取得に利用しているExchangeOnlinePowershellが一度に5,000件までしか取得できないため、細かく分割して取得することでその制限を回避するための設定です。 短くしすぎると、取得間隔を短くしてのリトライが発生して効率が落ちます。 ログが少ない環境では14400分（10日間）など長くすると早く終わります。 Recommended interval: 60 Lower the time interval for environments with a high log volume Please enter a time interval or ENTER for 60: 14400 この後、認証が求められますが、多要素認証を設定している場合は、最初に出る認証画面はキャンセルを押してください。次に別な認証画面が出るので、そちらでログインしてください。ログ取得が実行され、結果はファイルとしてカレントフォルダに出力されます。 2. 攻撃に関与した疑いのあるユーザのログ取得 全ユーザに関するログの分析により判明した（もしくはすでに明らかになっている）攻撃に関与した疑いのある特定ユーザごとに、より詳細なログを取得します。 可能であれば全ユーザに対して詳細なログを取得することが望ましいですが、ユーザ数が多い場合は現実的でないため、攻撃者の関与が疑われるメールアカウントに限定して取得しています。 HAWKでのログ取得 > Start-HawkUserInvestigation <ユーザのメールアドレス> Office 365 Extractorでのログ取得 スクリプトを実行します。 > .\Office365_Extractor.ps1 全種別のログを取得するため、2を入力します。 Following actions are supported by this script: 1 Show available log sources and amount of logging 2 Extract all audit logging 3 Extract group audit logging 4 Extract specific audit logging (advanced mode) 5 ReadMe 6 Quit Select an action: 2 取得対象として特定ユーザを指定するため、2を入力します。 Would you like to extract log events for [1]All users or [2]Specific users >:2 ログを取得したいユーザのメールアドレスをカンマ区切りで入力します。 Provide accounts that you wish to acquire, use comma separated values for multiple accounts, example (user1@example.com,user2@example.com) >: user1@example.com, user2@example.com これ以降の手順はテナントの全ユーザのログ取得時と同様です。 MessageTraceログの取得 最後に、攻撃者の関与が疑われる特定ユーザに関して、MessageTraceからメールの送受信ログを取得します。 本手順により最大で過去90日、50,000件のログが取得可能です。(過去10日以内の最大1,000件のデータで十分でしたら Get-MessageTrace コマンドレットを使用する方がより簡単です。) まずExchange Online Powershellに接続します。管理者権限のあるアカウントを使用してください。 > Import-Module ExchangeOnlineManagement > Connect-ExchangeOnline -UserPrincipalName <User Principal Name, メールアドレス等> ログ生成クエリを発行します。 (例では -SenderAddress で送信アドレスを指定しています。 -RecipientAddress を使えば受信アドレスを指定できます。) > Start-HistoricalSearch -ReportTitle "test" -StartDate 2019/12/1 -EndDate 2020/1/20 -ReportType MessageTrace -SenderAddress adminuser1@example.com JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test NotStarted 0 タスクの進行状況を確認します。 StatusがNotStartedになっているためまだ開始されていません。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test NotStarted 0 タスクの進行状況を確認します。 StatusがInProgressになっているため実行中です。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test InProgress 0 タスクの進行状況を確認します。 StatusがDoneになっているため実行完了しています。 > Get-HistoricalSearch JobId SubmitDate ReportTitle Status Rows ErrorCode ErrorDescription ----- ---------- ----------- ------ ---- --------- ---------------- 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX 2020/01/15 6:24:53 test Done 2 JobIdを指定し詳細情報を確認します。下記のFileUrlに記載のURLに、ブラウザでアクセスしログをダウンロードできます。 > Get-HistoricalSearch -JobId 7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX | Format-List (...略...) FileUrl : https://admin.protection.outlook.com/ExtendedReport/Download?Type=OnDemandReport&RequestID=7308a7ca-2a05-46cf-XXXX-XXXXXXXXXXXX ReportStatusDescription : Complete – Ready for download ReportType : MessageTrace (...略...) まとめ 本記事では Microsoft Exchange Online 関係のログの概要と、ログ取得方法を説明しました。 どのようなログが取れるかを知っておくことは、いざというとき有効活用するために必要不可欠です。 その一助となるべく公開された本記事をご活用いただけると幸いです。 冒頭で述べたとおり、 後編 ではログを記録しておくための設定について説明します。よろしければそちらもご覧ください。 https://developer.ntt.com/ja/blog/b097ce00-8942-43c6-bad4-842087f8dc6b ↩ https://blogs.technet.microsoft.com/junichia/2015/10/28/office-365-azure-adintuneazure-rms/ ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-unifiedauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-sign-ins ↩ https://aad.portal.azure.com/ ↩ https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-powershell-reporting ↩ https://techcommunity.microsoft.com/t5/security-compliance-and-identity/contextualizing-attacker-activity-within-sessions-in-exchange/ba-p/308710 ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-mailboxauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/search-adminauditlog?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/powershell/module/exchange/get-messagetrace?view=exchange-ps ↩ https://docs.microsoft.com/ja-jp/previous-versions/office/developer/o365-enterprise-developers/jj984335(v=office.15) ↩ https://github.com/Canthv0/hawk ↩ https://github.com/PwC-IR/Office-365-Extractor ↩ *1 : 他にも複数のダウンロード方法が提供されています。詳しくはMicrosoft社にお問い合わせください。

はじめに こんにちは、イノベーションセンター テクノロジー部門の小倉 ( @Mahito ) です。 普段は Engineer Empowerment Project のリーダーとして、エンジニアのはたらく環境を良くする取り組みや NTT Tech Conference や勉強会などのエンジニアが楽しく働くための取り組みをしています。 今回は社内で行った TechNight というイベントで発表した YAML の文法についての話を記事にしたものです。 もともとの発表は、YAML の記法について調べてるうちに「YAML こんなこと出来るのか」となったのでまとめたものでした。 YAML とは 公式サイト ( The official YAML Web Site ) ではこう書かれています。 YAML is a human friendly data serialization standard for all programming languages. また、Wikipedia ( YAML - Wikipedia ) では初期の意味と現在の意味が違うと書いてありました。 YAMLは再帰的に定義された頭字語であり "YAML Ain't a Markup Language"（YAMLはマークアップ言語じゃない）の意味である。初期には "Yet Another Markup Language"（もうひとつ別のマークアップ言語）の意味と言われていたが、マークアップよりもデータ重視を目的としていたために後付されてできた名前である。 現在の最新バージョンは 1.2 で 12 年近く更新されていません。 ( 最後のパッチは 2009-10-01 ) 表記方法 階層構造の表現 YAML はインデントを使い階層構造で内容を表現します。ただし、 インデントにはタブが使えずスペースのみが使えます 。（インデントはスペース 2 個単位ですることが多いそうです） 始まりと終わり YAML ドキュメントは 任意 で --- から開始して、 ... で終わらせることができます。 これは、YAML 形式の一部で、ドキュメントの最初と最後を示し、これらを用いることで 1 つのファイル内に複数の YAML ドキュメントを埋め込むことができます。 --- # やることリスト（ブロック形式） - ブログを書く - イベントの企画 - 技術調査・検証 ... --- # 買い物リスト（インライン形式） [ トマト, 卵, サラダ油 ] 1 つのドキュメント内に複数の YAML ドキュメントが埋め込まれている場合、プログラミング言語によっては load / safe_load では 1 つの YAML ドキュメントしか読めない、またはそもそも読み込みできないものがあります。 ( Ruby ) では複数のうち先頭の 1 つの YAML ドキュメントしか読めません。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .safe_load(yml) end # => ["ブログを書く", "イベントの企画", "技術調査・検証"] Python では yaml.composer.ComposerError: expected a single document in the stream が返されます。 import yaml with open ( 'sample.yml' ) as f: docs = yaml.safe_load(f) for doc in docs: print (doc) # => yaml.composer.ComposerError: expected a single document in the stream 1 つのドキュメント内に複数の YAML ドキュメントがあるファイル読み込む際は load_stream ( Ruby )や load_all ( Python ) を使うとまとめて読むことができます。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .load_stream(yml) end # => [["ブログを書く", "イベントの企画", "技術調査・検証"], ["トマト", "卵", "サラダ油"]] なお、 --- を "directives end"、 ... を "document end" と呼ぶそうですが、わかりにくいということで、 --- を YAML 1.1 で使われいた "document start" という名前に戻そうという RFC が上がっています。 私は --- が YAML に書かれているのを見たことがありますし、何なら使ってもいましたが、「YAML の先頭にある記号でなくても良い」程度にしか意識してきていませんでした。さらに、 ... はまったく見たことがなかったので、今回調べて初めて知りました。 コメント 行頭、もしくはスペースの後に番号記号 "#" を指定すると、その後はコメントになります。 # 行頭コメント [ トマト, 卵, サラダ油 ] # これもコメント リスト - を並べることでリスト表現が可能です。 --- # 果物一覧 - りんご - みかん - いちじく - もも 上記はブロック形式ですが、インデントを使わずにインライン形式で [..., ..., ] と表現することもできます。 --- # 果物一覧 [ りんご, みかん, いちじく, もも ] 連想配列 key: value とすることで連想配列の表現が可能です。 --- # 果物と色の組み合わせ一覧 りんご : 赤 みかん : オレンジ いちじく : 白と赤 もも : ピンク # => {"りんご" => "赤", "みかん" => "オレンジ", "いちじく" => "白と赤", "もも" => "ピンク"} リスト同様にインライン形式で {key1: value1, key2: value2, } と表現することもできます。 { りんご : 赤, みかん : オレンジ, いちじく : 白と赤, もも : ピンク } key:value と : の後ろにスペースを空けないと、文字として扱われてしまいます。 key:value # => "key:value" また、 : のあとのスペースもしくは改行はマッピングに利用されるので次のような c: という表現はエラーとなります。 windows_drive : c: # => (<unknown>): mapping values are not allowed in this context at line 1 column 17 (Psych::SyntaxError) マッピング以外の意図で : を利用する際は、 : の後ろにスペースや改行をいれない、もしくは '' や "" で括れば利用できます。 windows_path : c:\windows c_drive : 'c:' d_drive : "d:" # => {"windows_path"=>"c:\\windows", "c_drive"=>"c:", "d_drive"=>"d:"} "" ではエスケープを使用できる点が、 '' との違いです。 single quote : 'エスケープが使えません\n' double_quote : "エスケープが使えます \n " # => {"single quote"=>"エスケープが使えません\\n", "double_quote"=>"エスケープが使えます\n"} 複雑なキーマッピング YAML では "? " ( ? とスペース)を使うと複雑なキーを生成できます。 (出典) Example 2.11. Mapping between Sequences ? - Detroit Tigers - Chicago cubs : - 2001-07-23 # => {["Detroit Tigers", "Chicago cubs"]=>[#<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>]} 上の ["Detroit Tigers", "Chicago cubs"] がキー、下の 2001-07-23 が Value となります。 同様に Key に連想配列も指定可能です。 ? { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {{"New York Yankees"=>"Atlanta Braves"}=>[#<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>]} ちなみに "? " を外すと下の : 以下は無視されます。 { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {"New York Yankees"=>"Atlanta Braves"} ? を使うことで value を null にした連想配列の作成も可能です。 (出典) Example 2.25. Unordered Sets --- ? Mark McGwire ? Sammy Sosa ? Ken Griff # => {"Mark McGwire"=>nil, "Sammy Sosa"=>nil, "Ken Griff"=>nil} このあたりも YAML の公式ドキュメントを見て初めて知った機能です。 連想配列の key に配列や連想配列を利用したり、連想配列の value を null にするなど、今まで使ったことがない機能ですが知っておくといつの日にか使う機会が訪れるやもしれませんね。 Bool の扱い Bool型値 (True/False) は複数形式で指定可能です。 a : yes b : no c : True d : TRUE e : false # => {"a"=>true, "b"=>false, "c"=>true, "d"=>true, "e"=>false} 連想配列のキーに yes や true , no などを使うと想定しない動きをするので注意が必要です。 yes : "We can" # => {true=>"We can"} もし先頭を yes にする場合は文字として設定する必要があります。 "yes" : "We can" # => {"yes"=>"We can"} 複数行に分けた表現 文字列は、 | または > を使用して複数行に分けることができます。 | を使用して複数行に分けた場合には、改行と、末尾にあるスペースが含まれます。 pipe_lines : | 複数行の文章は '|' を使うことで 楽に書けます。　 # => {"pipe_lines"=>"複数行の文章は\n'|' を使うことで\n楽に書けます。　\n"} > を使うと改行を折り返してスペースに置き換えます。 long_text : > 長い文章は '>' を使うことで 1行で書けます # => {"long_text"=>"長い文章は '>'を使うことで 1行で書けます\n"} どちらの場合もインデントは無視されます。 > を使う場合で改行をしたいときは以下の2つを用いて改行できます。 改行だけの空白行 インデント後に値を記入 long_text_lines : > a b c d e f # => {"long_text_lines"=>"a b\nc d\n e\nf\n"} | や > の機能は知っていましたが、 > の改行で「インデント後に値を記入」は知らない機能でした。 この機能はインデントを含めた改行になるのでちょっと使い方が限られますが知っておくと便利な仕様ですね。 タグと型 YAML は型を明示していない場合、暗黙的な型付けがされます。明示的な型付けは ! のシンボルを使ったタグで示されます。 date : 2021-09-02 not-date : !!str 2021-09-02 # => { # "date"=>#<Date: 2021-09-02 ((2459460j,0s,0n),+0s,2299161j)>, # "not-date"=>"2021-09-02"} デフォルトのタグ URI は tag:yaml.org,2002: です。その中で定義されている型のタグは以下のとおりです。 Collection Types map omap pairs set seq Scalar Types binary bool float int merge (省略記法 << ) null str timestamp value yaml 参照 ： Language-Independent Types for YAML™ Version 1.1 タグの URI を明示的に切り替える場合は %TAG ! tag:hoge.com,2002: のように設定します。 上記のようにデフォルトで定義されているタグの呼び出しは !!str のようにエクスクラメーションマーク 2 つ ( !! ) , アプリケーション特有のローカルタグの呼び出しはエクスクラメーションマーク 1 つ ( ! ) と別れています。 例: omapを指定 --- !!omap - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => {"yesterday"=>"2021-09-01", "today"=>"2021-09-02", "tomorrow"=>"2021-09-03"} 例: omapなし --- - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 例: mapを指定 --- !!map - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 余談 1.10 など末尾に 0 が入る数字を明示的に表現するためには文字にする必要があります。 !!float 型では末尾の 0 が表示されないので注意が必要です。 --- - 1.10 - !!float 1.10 - '1.10' # => [1.1, 1.1, "1.10"] タグと型の機能も全く知らない機能でした。 型の機能は調べている中で便利だと感じたのでこれから使っていきたい機能です。 アンカーとエイリアス YAMLは & でアンカーを設定し、 * で参照が可能です。さらに << もしくは !!merge を使うことで、参照先の値の変更も可能です。 --- !!omap - default : &default user : root password : password db_url : localhost:3306 - development : *default - production : <<: *default db_url : production:3306 # => {"default"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "development"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "production"=>{"user"=>"root", "password"=>"password", "db_url"=>"production:3306"}} 上記の例では default というアンカーを設定し、development はそのまま参照、poroduction は db_url を変更をしています。 エイリアスとアンカーも見たことはあるけどうまく使えてなかった機能です。 今回調べたことで理解が深まったので今後は使っていきたいです。 YAMLの今後 ここまで紹介してきた現在のバージョンは "YAML 1.2 - 3rd Edition, Patched at 2009-10-01" です。 このバージョンは 12 年近く更新されていませんでしたが、今年の 5 月に突然次期バージョンへのRFCが始まっています。 YAML Spec RFCs GitHub 上で Template をベースに PR 形式で RFC を受け付けているので、興味があればリポジトリを覗いてみて、提案があれば RFC を書いてPRをしてみてはいかがでしょう。 まとめ 普段何気なく使っている YAML ですが、まだ知らない、うまく使えていない機能がありました。 この記事では YAML のすべてを紹介できてはいませんが、もしこの記事を読んで YAML に興味を持っていただけたのであれば、一度 YAML の公式ページ を読んでみることをおすすめします。 また、YAML の新しいバージョンが動き出しているので、そちらも興味があればチェックしてみてはいかがでしょう。 参考 YAML Ain’t Markup Language (YAML™) Version 1.2 YAML - Wikipedia (英語) YAML - Wikipedia (日本語) YAML 構文 - Ansible Document Language-Independent Types for YAML™ Version 1.1

はじめに こんにちは、イノベーションセンター テクノロジー部門の小倉 ( @Mahito ) です。 普段は Engineer Empowerment Project のリーダーとして、エンジニアのはたらく環境を良くする取り組みや NTT Tech Conference や勉強会などのエンジニアが楽しく働くための取り組みをしています。 今回は社内で行った TechNight というイベントで発表した YAML の文法についての話を記事にしたものです。 もともとの発表は、YAML の記法について調べてるうちに「YAML こんなこと出来るのか」となったのでまとめたものでした。 YAML とは 公式サイト ( The official YAML Web Site ) ではこう書かれています。 YAML is a human friendly data serialization standard for all programming languages. また、Wikipedia ( YAML - Wikipedia ) では初期の意味と現在の意味が違うと書いてありました。 YAMLは再帰的に定義された頭字語であり "YAML Ain't a Markup Language"（YAMLはマークアップ言語じゃない）の意味である。初期には "Yet Another Markup Language"（もうひとつ別のマークアップ言語）の意味と言われていたが、マークアップよりもデータ重視を目的としていたために後付されてできた名前である。 現在の最新バージョンは 1.2 で 12 年近く更新されていません。 ( 最後のパッチは 2009-10-01 ) 表記方法 階層構造の表現 YAML はインデントを使い階層構造で内容を表現します。ただし、 インデントにはタブが使えずスペースのみが使えます 。（インデントはスペース 2 個単位ですることが多いそうです） 始まりと終わり YAML ドキュメントは 任意 で --- から開始して、 ... で終わらせることができます。 これは、YAML 形式の一部で、ドキュメントの最初と最後を示し、これらを用いることで 1 つのファイル内に複数の YAML ドキュメントを埋め込むことができます。 --- # やることリスト（ブロック形式） - ブログを書く - イベントの企画 - 技術調査・検証 ... --- # 買い物リスト（インライン形式） [ トマト, 卵, サラダ油 ] 1 つのドキュメント内に複数の YAML ドキュメントが埋め込まれている場合、プログラミング言語によっては load / safe_load では 1 つの YAML ドキュメントしか読めない、またはそもそも読み込みできないものがあります。 ( Ruby ) では複数のうち先頭の 1 つの YAML ドキュメントしか読めません。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .safe_load(yml) end # => ["ブログを書く", "イベントの企画", "技術調査・検証"] Python では yaml.composer.ComposerError: expected a single document in the stream が返されます。 import yaml with open ( 'sample.yml' ) as f: docs = yaml.safe_load(f) for doc in docs: print (doc) # => yaml.composer.ComposerError: expected a single document in the stream 1 つのドキュメント内に複数の YAML ドキュメントがあるファイル読み込む際は load_stream ( Ruby )や load_all ( Python ) を使うとまとめて読むことができます。 require ' yaml ' open( ' sample.yml ' , ' r ' ) do |yml| p YAML .load_stream(yml) end # => [["ブログを書く", "イベントの企画", "技術調査・検証"], ["トマト", "卵", "サラダ油"]] なお、 --- を "directives end"、 ... を "document end" と呼ぶそうですが、わかりにくいということで、 --- を YAML 1.1 で使われいた "document start" という名前に戻そうという RFC が上がっています。 私は --- が YAML に書かれているのを見たことがありますし、何なら使ってもいましたが、「YAML の先頭にある記号でなくても良い」程度にしか意識してきていませんでした。さらに、 ... はまったく見たことがなかったので、今回調べて初めて知りました。 コメント 行頭、もしくはスペースの後に番号記号 "#" を指定すると、その後はコメントになります。 # 行頭コメント [ トマト, 卵, サラダ油 ] # これもコメント リスト - を並べることでリスト表現が可能です。 --- # 果物一覧 - りんご - みかん - いちじく - もも 上記はブロック形式ですが、インデントを使わずにインライン形式で [..., ..., ] と表現することもできます。 --- # 果物一覧 [ りんご, みかん, いちじく, もも ] 連想配列 key: value とすることで連想配列の表現が可能です。 --- # 果物と色の組み合わせ一覧 りんご : 赤 みかん : オレンジ いちじく : 白と赤 もも : ピンク # => {"りんご" => "赤", "みかん" => "オレンジ", "いちじく" => "白と赤", "もも" => "ピンク"} リスト同様にインライン形式で {key1: value1, key2: value2, } と表現することもできます。 { りんご : 赤, みかん : オレンジ, いちじく : 白と赤, もも : ピンク } key:value と : の後ろにスペースを空けないと、文字として扱われてしまいます。 key:value # => "key:value" また、 : のあとのスペースもしくは改行はマッピングに利用されるので次のような c: という表現はエラーとなります。 windows_drive : c: # => (<unknown>): mapping values are not allowed in this context at line 1 column 17 (Psych::SyntaxError) マッピング以外の意図で : を利用する際は、 : の後ろにスペースや改行をいれない、もしくは '' や "" で括れば利用できます。 windows_path : c:\windows c_drive : 'c:' d_drive : "d:" # => {"windows_path"=>"c:\\windows", "c_drive"=>"c:", "d_drive"=>"d:"} "" ではエスケープを使用できる点が、 '' との違いです。 single quote : 'エスケープが使えません\n' double_quote : "エスケープが使えます \n " # => {"single quote"=>"エスケープが使えません\\n", "double_quote"=>"エスケープが使えます\n"} 複雑なキーマッピング YAML では "? " ( ? とスペース)を使うと複雑なキーを生成できます。 (出典) Example 2.11. Mapping between Sequences ? - Detroit Tigers - Chicago cubs : - 2001-07-23 # => {["Detroit Tigers", "Chicago cubs"]=>[#<Date: 2001-07-23 ((2452114j,0s,0n),+0s,2299161j)>]} 上の ["Detroit Tigers", "Chicago cubs"] がキー、下の 2001-07-23 が Value となります。 同様に Key に連想配列も指定可能です。 ? { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {{"New York Yankees"=>"Atlanta Braves"}=>[#<Date: 2001-07-02 ((2452093j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-12 ((2452134j,0s,0n),+0s,2299161j)>, #<Date: 2001-08-14 ((2452136j,0s,0n),+0s,2299161j)>]} ちなみに "? " を外すと下の : 以下は無視されます。 { New York Yankees : Atlanta Braves } : [ 2001-07-02, 2001-08-12, 2001-08-14 ] # => {"New York Yankees"=>"Atlanta Braves"} ? を使うことで value を null にした連想配列の作成も可能です。 (出典) Example 2.25. Unordered Sets --- ? Mark McGwire ? Sammy Sosa ? Ken Griff # => {"Mark McGwire"=>nil, "Sammy Sosa"=>nil, "Ken Griff"=>nil} このあたりも YAML の公式ドキュメントを見て初めて知った機能です。 連想配列の key に配列や連想配列を利用したり、連想配列の value を null にするなど、今まで使ったことがない機能ですが知っておくといつの日にか使う機会が訪れるやもしれませんね。 Bool の扱い Bool型値 (True/False) は複数形式で指定可能です。 a : yes b : no c : True d : TRUE e : false # => {"a"=>true, "b"=>false, "c"=>true, "d"=>true, "e"=>false} 連想配列のキーに yes や true , no などを使うと想定しない動きをするので注意が必要です。 yes : "We can" # => {true=>"We can"} もし先頭を yes にする場合は文字として設定する必要があります。 "yes" : "We can" # => {"yes"=>"We can"} 複数行に分けた表現 文字列は、 | または > を使用して複数行に分けることができます。 | を使用して複数行に分けた場合には、改行と、末尾にあるスペースが含まれます。 pipe_lines : | 複数行の文章は '|' を使うことで 楽に書けます。　 # => {"pipe_lines"=>"複数行の文章は\n'|' を使うことで\n楽に書けます。　\n"} > を使うと改行を折り返してスペースに置き換えます。 long_text : > 長い文章は '>' を使うことで 1行で書けます # => {"long_text"=>"長い文章は '>'を使うことで 1行で書けます\n"} どちらの場合もインデントは無視されます。 > を使う場合で改行をしたいときは以下の2つを用いて改行できます。 改行だけの空白行 インデント後に値を記入 long_text_lines : > a b c d e f # => {"long_text_lines"=>"a b\nc d\n e\nf\n"} | や > の機能は知っていましたが、 > の改行で「インデント後に値を記入」は知らない機能でした。 この機能はインデントを含めた改行になるのでちょっと使い方が限られますが知っておくと便利な仕様ですね。 タグと型 YAML は型を明示していない場合、暗黙的な型付けがされます。明示的な型付けは ! のシンボルを使ったタグで示されます。 date : 2021-09-02 not-date : !!str 2021-09-02 # => { # "date"=>#<Date: 2021-09-02 ((2459460j,0s,0n),+0s,2299161j)>, # "not-date"=>"2021-09-02"} デフォルトのタグ URI は tag:yaml.org,2002: です。その中で定義されている型のタグは以下のとおりです。 Collection Types map omap pairs set seq Scalar Types binary bool float int merge (省略記法 << ) null str timestamp value yaml 参照 ： Language-Independent Types for YAML™ Version 1.1 タグの URI を明示的に切り替える場合は %TAG ! tag:hoge.com,2002: のように設定します。 上記のようにデフォルトで定義されているタグの呼び出しは !!str のようにエクスクラメーションマーク 2 つ ( !! ) , アプリケーション特有のローカルタグの呼び出しはエクスクラメーションマーク 1 つ ( ! ) と別れています。 例: omapを指定 --- !!omap - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => {"yesterday"=>"2021-09-01", "today"=>"2021-09-02", "tomorrow"=>"2021-09-03"} 例: omapなし --- - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 例: mapを指定 --- !!map - yesterday : !!str 2021-09-01 - today : !!str 2021-09-02 - tomorrow : !!str 2021-09-03 # => [{"yesterday"=>"2021-09-01"}, {"today"=>"2021-09-02"}, {"tomorrow"=>"2021-09-03"}] 余談 1.10 など末尾に 0 が入る数字を明示的に表現するためには文字にする必要があります。 !!float 型では末尾の 0 が表示されないので注意が必要です。 --- - 1.10 - !!float 1.10 - '1.10' # => [1.1, 1.1, "1.10"] タグと型の機能も全く知らない機能でした。 型の機能は調べている中で便利だと感じたのでこれから使っていきたい機能です。 アンカーとエイリアス YAMLは & でアンカーを設定し、 * で参照が可能です。さらに << もしくは !!merge を使うことで、参照先の値の変更も可能です。 --- !!omap - default : &default user : root password : password db_url : localhost:3306 - development : *default - production : <<: *default db_url : production:3306 # => {"default"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "development"=>{"user"=>"root", "password"=>"password", "db_url"=>"localhost:3306"}, # "production"=>{"user"=>"root", "password"=>"password", "db_url"=>"production:3306"}} 上記の例では default というアンカーを設定し、development はそのまま参照、poroduction は db_url を変更をしています。 エイリアスとアンカーも見たことはあるけどうまく使えてなかった機能です。 今回調べたことで理解が深まったので今後は使っていきたいです。 YAMLの今後 ここまで紹介してきた現在のバージョンは "YAML 1.2 - 3rd Edition, Patched at 2009-10-01" です。 このバージョンは 12 年近く更新されていませんでしたが、今年の 5 月に突然次期バージョンへのRFCが始まっています。 YAML Spec RFCs GitHub 上で Template をベースに PR 形式で RFC を受け付けているので、興味があればリポジトリを覗いてみて、提案があれば RFC を書いてPRをしてみてはいかがでしょう。 まとめ 普段何気なく使っている YAML ですが、まだ知らない、うまく使えていない機能がありました。 この記事では YAML のすべてを紹介できてはいませんが、もしこの記事を読んで YAML に興味を持っていただけたのであれば、一度 YAML の公式ページ を読んでみることをおすすめします。 また、YAML の新しいバージョンが動き出しているので、そちらも興味があればチェックしてみてはいかがでしょう。 参考 YAML Ain’t Markup Language (YAML™) Version 1.2 YAML - Wikipedia (英語) YAML - Wikipedia (日本語) YAML 構文 - Ansible Document Language-Independent Types for YAML™ Version 1.1

こんにちは、イノベーションセンターの三島です。 本記事では、次世代の監視技術として期待されるTelemetry技術についてご紹介します。 この記事について 本記事では下記の3点を共有します。 従来の監視技術が抱える課題とTelemetryの可能性 Telemetryの技術概要と、各社の実装状況 NTT Comのネットワーク上で検証し得られた知見と、期待されるユースケース 従来の監視技術が抱える課題 ネットワーク運用においては、障害検知やパフォーマンス分析のため監視技術が重要となります。 従来のネットワークでは、SNMP（Simple Network Management Protocol）と呼ばれる技術が広く利用されています。 SNMPの仕組みを図1に示します。SNMPはUDPベースなネットワーク監視技術です。データモデルはMIB（Management Information Base）と呼ばれるデータベースに定義されており、ベンダ共通の標準MIBと固有の拡張MIBが存在します。 SNMPの情報取得者をSNMP Manager、情報発行者をSNMP Agentと呼びます。情報の取得手法として、SNMP Managerがリクエストベースに情報を取得するPollingと、SNMP Agentがトリガーベースに情報を送信するTrapが存在します。 従来のSNMPが抱える課題として、下記の3点が挙げられます。 高負荷な処理構造 マルチベンダ環境における管理の煩雑さ N対N構成での規模性の限界 1.高負荷な処理構造について図2に示します。 ネットワーク監視ではトラフィック量や機器の負荷情報（Memory・CPU・温度等）の取得が求められます。しかしSNMPのPollingはリクエストベースであるため、高精細な情報を取得するために間隔を狭めると、CPU負荷の増大と処理時間の増加が課題となります。 2.マルチベンダ環境における管理の煩雑さについて図3に示します。 SNMPでは標準MIBが乏しく、例えばCPU使用率等のパラメータを取得できない課題が存在します。 そのため、マルチベンダな環境で同じ情報を取得するためには、機種ごとに固有な拡張MIBのOID（Object ID）を指定する必要があり、管理コストが増大します。 3.N対N構成での規模性の限界について図4に示します。 大規模なネットワークでは、データ利活用のため複数のデータ利用者が同じ機器の情報を取得することが考えられます。（例えば利用者Aはトラフィック量を可視化のために取得し、利用者Bはインターフェース状態をDown検知のために取得するなど） SNMPではAgentとManagerを1対1のUDPで接続して監視するため、N対N構成ではAgent/Managerの組み合わせ分のUDP接続が必要となり、受信側で処理可能なメッセージに限界が生じます。 また、送信先・監視先ごとに異なる値を取得したい場合、組み合わせに応じてSNMP Agent/Managerに定義する必要があり、管理コストが増大します。 まとめとして、SNMPは下記3種の課題を抱えています。 高負荷なプロトコル構造による取得可能な情報精度の低下と、リアルタイム性の損失 標準MIBの乏しさによるマルチベンダ環境における管理の煩雑さ N対N構成構築時の規模性の課題 これらを解決する監視技術として、Telemetry技術が期待されています。 Telemetryについて Telemetryは次世代のネットワーク監視技術であり、各社による検討や実装・OpenConfig等による標準化が進められています。 Telemetryは、一般的には下記3つの特徴を持つよう設計されています。 SNMPと比較し低負荷なプロトコル設計による高精細でリアルタイムな情報取得 OpenConfigによるベンダフリーな情報取得 Pub/Subモデルの導入が容易な設計による高い規模性 これらの特徴から、前節で挙げたSNMPの課題を解決する技術として期待されています。 Telemetryは、Pub/Subモデルと呼ばれるデータの送受信モデルを採用しています。 Pub/Subモデルについて図5に示します。 Pub/Subモデルは下記3つの要素から構成されます。 Publisher: 発行者 (送信者)。メッセージを発行する Broker: 仲介者。メッセージを仲介する Subscriber: 購読者 (受信者)。メッセージを取得し活用する Pub/Subモデルの利点として、① メッセージの送信者・受信者がお互いを直接認識する必要がなく、非同期かつ疎結合である点、②Brokerを介して1対N、N対N構成が取れるため、規模性の高い点 が挙げられます。情報はTopicという属性で管理され、Publisher・SubscriberはTopicを指定することにより情報を送信・受信します。 図6にTelemetryのパイプライン構成を示します。 Telemetryパイプラインは下記の要素から構成されます。 Publisher: データの発行元であるネットワーク機器 Broker: Pub/Subの多重化を行う仲介役 Subscriber: データの受け取り・利用をするアプリケーション Pub/Subモデルの利点は失われますが、上記の構成以外にPublisherとSubscriberを直結する構成も可能です。 以降でそれぞれの要素について解説します。 Publisher Publisherはメッセージの発行者であり、下記の3つの要素から構成されます。 監視対象となるネットワーク機器 監視対象機器とCollectorを繋ぐTransport部分 Publisherからデータを受信するCollector 監視対象機器に関する概念として、情報モデルと接続方式の分類についてご説明します。 機器の情報モデルには、主にOpenConfig・ベンダネイティブの2種が存在します。OpenConfigはベンダニュートラルな利用を想定して標準化が進められているネットワークコンフィグのモデルであり、YANGに従い定義されています。一方ベンダネイティブは製品ごとに固有の情報モデルであり、一般的にOpenConfigよりも対応状況が良く、扱うことのできる情報も豊富な傾向があります。 機器が発行する情報は、Sensor-Pathと呼ばれるデータパスにより予め指定されており、決められた間隔でメッセージを発行し、Collectorへと送信します。 下記にSenrsor-Pathの例を示します。Sensor-PathはYANGのツリー構造に合わせて情報を取得するためのデータパスであり、SNMPにおけるOIDに近い概念です。 OpenConfig: Interfaceに関する情報全般（Configuration/State/Statistic含む） “/interfaces/” OpenConfig: Interfaceごとの入力パケットカウンタ（単位: byte） “/interfaces/interface/state/counters/in-octets” OpenConfig: xe-0/0/0の入力パケットカウンタ（単位: byte） “/interfaces/interface[name='xe-0/0/0']/state/counters/in-octets” Juniper ベンダネイティブ: Interfaceに関する情報全般 “/junos/system/linecard/interface/” 例のように、深いパスを指定することで取得する情報を細かく指定できます。 また、OpenConfigとベンダネイティブでは同じ情報を取得する場合でも異なるパスを指定する必要があります。 2021年8月時点の実装では、同じOpenConfigでもベンダにより対応状況が異なるため、各社のドキュメントを確認し取得するSensor-Pathを決める必要があります。 次に接続方式の違いについてご説明します。Telemetryでは、情報を発行するPublisherと受け取るCollectorの接続方向により、Dial-InとDial-Outの接続方式が存在します。図7にそれぞれぞれの概念を示します。 Dial-InはCollectorがPublisherに接続する手法です。利点としてはgRPCによる自動化を行っているネットワークの場合、機器に設定されたgNMIを利用して情報を取得できるため、Telemetry用追加設定の不要な点が挙げられます。 一方Dial-OutはPublisherがCollectorに接続する手法です。利点としてはCollector側が監視するPublisherのリストを管理する必要がないためCollectorをステートレスに設計可能であり、Dial-Inに比べて規模性が高い点や、Publisher側にもACLによる制御が不要となる点が挙げられます。 上記より、特別な理由がない場合は管理コストを考慮しDial-Outを採用することをお勧めします。ただし、例えばgRPCによる運用自動化を行っているネットワークなどでは、Dial-InのTelemetryが容易に導入可能な場合もあります。また、2021年8月時点では、ベンダによりDial-In/Dial-Outの対応状況が異なるため、注意が必要です。 次にTransport部分について説明します。Transportは監視対象デバイスとCollectorを繋ぐ転送の役割を持ちます。 TransportはEncodingとEncapsulationの要素から成り立ちます。 Encoding: メッセージの形式。JSON、GPBなどから選択可能 Encapsulation: 通信形式。TCP/UDPやgRPC、NETCONFなどを選択可能 SNMPはUDPによる通信のみを採用していましたが、Telemetryではメッセージをどのような形式で記述し、どのような通信形式で送るかを決めることができます。取得したい情報の性質や、運用で既に採用しているプロトコルなどを考慮しながら決めることをお勧めします。 CollectorはPublisherが発行したメッセージを受信する役割を持ちます。2021年8月時点の主なCollector実装を下記の表にご紹介します。 ベンダ OSS実装 ベンダ純正実装 ※Subscriber機能も兼ねる Arista ockafka Openconfigbeat Arista CloudVision Cisco Pipeline Telegraf/Fluentd等の専用Plugin Crosswork Health Insights Juniper Jtimon Telegraf/Fluentd等の専用Plugin Paragon Insights SONiC gnxi（単発で取得するCLIツール） gNMIc - 上記でご紹介したベンダ純正実装は、単体のCollectorではなくSubscriberとしての可視化や自動化の機能を備えています。 Collectorごとに特徴や存在する機能が異なるため、例えばPublisherのグループ化やKafkaとの連携など、必要な機能を考慮し選定することをお勧めします。 Broker Brokerはメッセージの仲介者であり、Message Queueが該当します。 Message Queueはメッセージを中継する要素であり、主な実装としてはApache Kafkaや、Public CloudにおけるCloud Pub/Sub・SQSなどが挙げられます。 一般的な実装では、クラスタリングやミラーリングなど、冗長化を行う仕組みを持つことが多いです。図8に一般的なBrokerのMessage Queue的な役割を示します。 Publisherが発行するメッセージにはTopicとデータが含まれています。Brokerは受信したメッセージをTopicごとのキューに格納した後、Subscriberからの購読に応じてメッセージを送信します。 Subscriber Subscriberはメッセージの受信者であり、データを受け取り利用する要素です。 Subscriberはユースケースごとに様々な機能・パイプラインを持ちます。一般的には①リアルタイムな監視 & 詳細な情報に基づく可視化・分析、②アラート、③設定の自動化/自己治癒 などが考えられます。 検証構成と取得結果 ここからは、NTT Com内にて実施した検証についてご紹介します。 今回の構成では、NTT Comの社内ネットワーク環境において検証を実施しました。図9に構成図の一部を示します。 検証ではPublisher/Subscriberをそれぞれ多重化し、Brokerに収容しています。 監視対象の機器はArista・Cisco・Juniperと、Whiteboxな伝送装置に搭載されたSONiCの4ベンダを採用しています。また、SubscriberはオンプレミスのGrafanaによる可視化を行うと同時に、Google Cloud Platform上のKafkaにミラーリングを行い、Public Cloudと連携が行えることも検証しました。 図10、図11にそれぞれから取得した実際のデータをJSON形式で示します。 図10はArista機器で発行し、ockafkaを通じ取得したデータの例です。図の通り、データは単発のJSON型となっています。 一方、図11はその他の機器から取得したデータの例です。図の通り、Juniper/TelegrafではネストされたJSON型になっており、SONiC、gNMIcはJSON型の中にリストが含まれています。また、Cisco/Pipelineでは複数のJSON型がリストに含まれる形式であることがわかります。 このようなデータは直接InfluxDBに取り込むことができないため、整形処理が必要となります。LogstashやTelegrafといったコレクタには整形機能が存在しますが、デバッグが難しい、複雑な条件分岐を書きにくいなど、汎用性に問題がありました。 そこで、今回の検証ではデータ整形機を作成し対応しました。図12にデータ整形機を含めたフローを示します。 作成したデータ整形機は、まずKafkaから生データが含まれるTopicを購読し、データを取得します。取得したデータをPython Scriptで整形した後、Kafkaに対して取得したものとは異なるTopicでメッセージを発行します。これにより、Subscriberがデータ整形機の発行したTopicを指定することで、整形後のデータを取得できるようにしています。 図13に、実際に取得したデータをGrafanaで可視化した例を示します。 今回の検証では、TelemetryとSNMPで、Interfaceの受信したTraffic量の可視化を行いました。Telemetryは1000ms（Junosのみ2000ms）、SNMPでは負荷を考慮し、一般的に1分以上の間隔で取得することが多いですが、今回はPrometheusが取得可能であった15秒間隔でデータを採り、比較しています。 図13ではマイクロバーストの検知を想定しバーストトラフィックを生成しております。結果の通り、Telemetryではリアルタイムで複数のスパイクが観測されますが、SNMPでは、Pollingによる遅延が入った後、なだらかな山となり可視化が行われていることが読み取れます。 検証を通じて得られた知見 ここからはNTT Com内での検証を通じて得られた知見と期待されるユースケースをご紹介します。 導入時に考慮すべき点として、下記3点が挙げられます。 1. 対象機種ごとにパラメータを分ける手法の検討 現時点のTelemetryでは、ベンダごとに①Collector、②Dial-In / Dial-Out、③OpenConfig/ベンダネイティブの選択を含めたSensor-Path などのパラメータを指定する必要があります。 マルチベンダ環境における効率的な管理のため、例えばNetbox・Zabbix等でデバイス情報を管理しているネットワークでは、それらの情報と組み合わせ、ベンダごとに設定を切り替える仕組みを開発することで、管理コストを下げることが期待できます。 2. データの保持期間と粒度 Telemetryはms単位での情報取得が可能であるため、取得した大量のデータを長期にわたって保持することが現実的ではありません。 そのため、Telemetry導入の際にはデータの保持期間や保持する時間的な粒度などの事前検討が必要となります。 これらに該当するユースケースは主に ① 取得した瞬間の閾値による処理（その瞬間の詳細なデータが必要）、② 障害発生後の切り分け（1日-2日以内の詳細なデータが必要）の2種が想定されます。①、②どちらのユースケースでも、詳細なデータは1日-2日のみ保持し、それを過ぎたものはデータを時間単位などで集約して保持すれば良いと考えます。 3. 監視基盤の性能 2.の内容とも関連しますが、Telemetryを導入する際にはネットワーク規模と取得データと量・保持期間に従い、事前に監視基盤のメモリやストレージ等のリソースを計算しておく必要があり、導入前の検証が必須となります。 Telemetryに期待されるユースケース これまでの結果より、現時点のユースケースとして下記の3点を考えています。 シングルベンダ環境におけるリアルタイムな情報収集 gNMIを通じたコンフィグ投入等、自動化技術との組み合わせ 他の監視技術との連携 1.については、OpenConfigでの実装が追いついていない部分もベンダネイティブなSensor-Pathにより情報を取得でき、またベンダごとの独自機能や純正Collectorの利用が可能です。さらに、ベンダ固有の実装（Cisco Event Driven TelemetryやMellanox What Just Happened等）を利用できるなどの利点が存在します。 2.については、共有のgNMIを利用して監視・自動化が可能である利点を生かし、Telemetryにより振る舞いを監視し、閾値や機械学習ベースでのコンフィグ変更・自己治癒などの利用が考えられます。 3.については、例えばTelemetryのStatisticをxFlowのリアルタイムなフローと組み合わせ利用する、SyslogアラートをトリガーとしTelemetryのState・Statisticを保存するなど、高精細な情報を生かす手法が考えられます。 またどの用途についても、今後OpenConfig対応の充実やCollector・Dial-Out対応などの統一により、マルチベンダ対応が進むことにより、より利用しやすい技術となると期待しています。 まとめ NTT Comでの技術検証を通じ、Telemetryの下記3点の特徴を検証しました。 SNMPと比較し低負荷な設計によるリアルタイムな情報取得 OpenConfigによるベンダフリーな情報取得 Pub/Subモデルの導入が容易な設計による高い規模性 2021年8月時点の実装では、リアルタイムな情報取得はms単位での情報取得・低負荷なプロトコル設計等により期待通りの強みがありますが、マルチベンダ性に課題があるというのが検証から得られた所感です。 OpenConfigの対応状況やCollectorの統一については、これからますます実装が進むと予想されるため、今後の発展に期待しています。 付録 今回の検証で用いた各機器のコンフィグ例を共有します。お手元での検証にご利用ください。 なお、これらコンフィグ例は現状有姿で提供され、NTT Comは明示的・黙示的を問わず一切の保証をせず、何ら責任を負いません。 Arista 本体側はgNMI設定か専用デーモンを立ち上げるかの2択。 EOS 4.22以降ではgNMI設定が推奨されている。 本体側 - gNMI設定 management api gnmi transport grpc Telemetry port <Port> ip access-group <ACL名> provider eos-native ! 本体側 - 専用デーモン設定 ※ OpenConfigの場合はTerminAttrをOpenConfigに読みかえる。 daemon TerminAttr exec /usr/bin/TerminAttr -disableaaa -grpcaddr <CollectorのIP addr>:<Port> ip access-group <ACL名> no shutdown ! Collector - ockafaka（Dockerでの立ち上げ例） 手順は 公式リポジトリ を参照。 $ docker pull aristanetworks/ockafka $ docker run aristanetworks/ockafka -addrs <Publisher Addr>:<Port> -kafkaaddrs <Kafka Addr>:<Port> -kafkatopic arista_eos_telemetry -subscribe <PATH> Collector - openconfigbeat（Dockerでの立ち上げ例） 手順は 公式リポジトリ を参照。 % git clone https://github.com/aristanetworks/openconfigbeat.git // openconfigbeat.ymlを編集 openconfigbeat: addresses: ["<Publisher Addr>"] default_port: <Port> paths: ["interfaces/interface/name"] username: "<Username>" password: "<Password>" output.kafka: hosts: ["<Kafka Addr>:<Port>"] topic: <Topic名> // openconfigbeat.ymlを/直下に配置するようDockerfileを編集 % docker build -f ./Dockerfile -t openconfigbeat:latest . --no-cache=true % docker run -d --net=host --name openconfigbeat openconfigbeat:latest Cisco IOS-XR 本体側 - Dial-Out設定 telemetry model-driven destination-group <destination-group名> vrf <VRF名> address-family ipv4 <Collector Addr> port <Port> encoding <エンコーディング手法> protocol <トランスポートのプロトコル> ! ! sensor-group <sensor-group名> sensor-path <sensor-path> ! subscription <subscription名> sensor-group-id <sensor-group名> sample-interval <Interval(ms)> destination-id <destination-group名> source-interface <インターフェース名> ! ! 本体側 - TPA（Third Party Applications）設定 IOS-XR標準のマネジメントVRF以外でTelemetryを扱う場合に必要。 vrf <VRF名> address-family ipv4 update-source dataports active-management ! ! ! Collector - Pipeline 手順は 公式リポジトリ を参照。 pipeline.confを編集後、 $ docker run -d --net=host [--volume <local>:/data] --name pipeline pipeline:<version> [collector] stage = xport_input type = grpc encap = gpbkv listen = :<Port> [kafka] stage = xport_output type = kafka encoding = json_events brokers = <Kafka Addr>:<Port> topic = <Topic名> [inspector] stage = xport_output type = tap file = /data/dump.txt datachanneldepth = 1000 Juniper 本体側 - Dial-In設定 set system services extension-service request-response grpc clear-text address <Publisher Addr> set system services extension-service request-response grpc clear-text port <Port> set system services extension-service request-response grpc skip-authentication set system services extension-service notification allow-clients address <Collector Addr> Junos 20.2R1以降でDial-Outにも対応している が、対応するOSSのCollector実装が存在しないため未検証。 Collector - Telegraf Juniper公式のCollector実装である jtimon も存在するが、Kafkaとの連携機能が存在しないため本検証ではTelegrafのモジュールを採用。 [[inputs.jti_openconfig_telemetry]] servers = ["<Publisher Addr>:<Port>", "<Publisher Addr>:<Port>"] # 取得対象を複数指定可 username = "<Username>" password = "<Password>" client_id = "telegraf" # 取得対象の機器内(ルータ等)でユニークである必要がある # 1つの機器に対して複数プロセスからsubscribeする場合は、 # 異なる文字列にする sample_frequency = "2000ms" sensors = [ "/interfaces/interface[name=vme]/state", "/system", "/components", "/junos" ] retry_delay = "1000ms" str_as_tags = false [[outputs.kafka]] brokers = ["<Kafka Addr>:<Port>"] topic = "<Topic名>" data_format = "json" SONiC 本体側 - Telemetryサービスの設定 # vi telemetry-service.yaml apiVersion: v1 kind: Service metadata: name: telemetry-svc spec: type: NodePort ports: - port: <Port> protocol: TCP selector: app: usonic # kubectl apply -f telemetry-service.yaml kubectl get svc を実行し、待ち受けポートを確認しておく。 Collector - gNMIc 手順は 公式ページ 参照。 # vi gnmic.yml targets: <Publisher Addr>:<Port>: subscriptions: - port_stats skip-verify: true username: <Username> password: <Password> insecure: true subscriptions: port_stats: target: COUNTERS_DB paths: - <Sensor-Path> mode: stream stream-mode: sample sample-interval: 5s encoding: json outputs: output1: type: kafka address: <Kafka Addr>:<Port> topic: <Topic名> format: json debug: true

はじめに IoT Connect Gatewayとは？ IoT Connect Gatewayの特徴 閉域網がなくてもセキュアにクラウド接続を実現 処理負荷がかかる暗号化処理をサービス側で実施 暗号化通信によるデータ転送量を抑制 クラウドアダプタ機能で各種クラウドサービスに簡単接続 IoT Connect Gatewayにかける思い CI/CDの取り組みとサービスリリース Infrastructure as Code Test as Code GitOps 個人的な思い 最後に 次回予告 ICGWに関するお問い合わせ先 はじめに こんにちは、データプラットフォームサービス部でIoT Connect Gateway開発チームのTech Leadを している 栗原良尚(@yoshinao) です。 この度、NTT Com Engineers' Blogオープンに合わせて、開発をおこなっているIoT Connect Gatewayについてご紹介、情報発信をできる機会をいただきました。閲覧頂きありがとうございます。 Engineers' Blogでは、単なるサービス紹介だけでなく、IoT Connect Gatewayの使い方や、どんな事ができるのか？などのレシピや周辺技術を実験や電子工作を通じて発信していきたいと思っております。 また、皆様からのリクエストやフィードバックを通じて、双方向の情報発信、みなさまの声を次期開発に活かしたいと考えておりますのでリクエストやコメントを頂けますと幸いです。個人的にも記事投稿の励みになります（笑） どうぞ、よろしくお願い致します。 IoT Connect Gatewayとは？ IoT Connect Gateway（ICGW） とは、NTT Comが 2021年4月6日にリリース したIoT向けGatewayサービスです。 このサービスは、IoTセンサーやデバイスで収集したデータをクラウドやお客様のサービスに簡単かつセキュアに転送するためのゲートウェイサービスです。 ICGWでは、IoTデバイスからの通信をNTT ComのGatewayで一度終端することで、IoTデバイス側に必要な機能をオフロードしたり、転送先を切り替えたり、デバイス側に機能追加必要なく様々な付加価値を利用することが可能になります。 ICGWは、NTT Comが提供している SmartDataPlatforｍ(SDPF) のIoTカテゴリのサービスで、 IoT Connect Mobile Type S と組み合わせてご利用が可能です。 今後も他のSDPFサービスのシームレスな連携を目指すことで、一つのプラットフォーム上でシームレスに融合、データを整理して利活用を容易にすることを目指しています。 IoT Connect Gatewayの特徴 以下に、現在のサービスの特徴をご紹介します。 1. 閉域網がなくてもセキュアにクラウド接続を実現 IoTデバイスからクラウドにセキュアにデータを送信したい場合、個別に閉域網で接続する、デバイスからデータ暗号化して送信するといった方法がありますが、どちらもコストがかかるという課題があります。 ICGWは、モバイル網とインターネットの境界に位置し、IoTデバイスからICGWの区間はモバイル網でセキュアに、ICGWからクラウドサービスに接続する時は、ICGWで暗号化(HTTPS/MQTTS) することでセキュアで安価なサービス接続を実現しています。 2. 処理負荷がかかる暗号化処理をサービス側で実施 IoTデバイスから暗号化したデータを送信する場合、デバイス側で暗号化を行うことになりますが、いくつかの課題に直面することがあります。 暗号化によってIoTデバイスの消費電力が大きくなってしまう IoTデバイスの製造コストが高くなってしまう ICGWは、これらの課題をサービス側で暗号化を行うことで解決します。端末側で暗号化の暗号化能力を気にする必要はありません。 また、鍵の交換などの作業もサービス側で一括して実施できるので、端末ごとの個別設定は必要なくなるというメリットがあります。 3. 暗号化通信によるデータ転送量を抑制 IoTデバイスから暗号化通信を行う場合、暗号化によるプロトコルオーバヘッドが発生し、暗号化しない通信と比較してデータ通信料が多くなるという課題があります。 ICGWでは、IoTデバイスからICGW区間は、閉域のモバイル網を利用するため、暗号化を必要とせずセキュアにデータを転送可能です。また、サービス側で暗号化処理を行うため、セキュアかつデータ通信量を節約することが可能です。 4. クラウドアダプタ機能で各種クラウドサービスに簡単接続 ICGWでは、暗号化と合わせて、各種クラウドサービスの差異を 意識することなく簡単に接続できるクラウドアダプタを提供しています。 この機能によって、IoTデバイスに利用クラウドに合わせた接続パラメータなどの個別の設定や開発のコストを削減することが可能となります。 各種クラウドサービスは、頻繁に機能アップデートや新規サービスを展開していますが、既に展開済みのIoTデバイスに、これらのアップデートを追従していくことは困難です。 しかしICGWを利用している場合、簡単に転送先サービスの変更や新機能が利用可能になります。 これはすでに展開済みのIoTデバイスを管理する上でも大きなメリットとなります。また、長期運用の観点では、暗号化プロトコルのアップデートや追従ができる点も重要になります。 現在対応中のクラウドサービス クラウドサービス プロトコル AWS IoTCore HTTP MQTT GCP IoTCore HTTP MQTT Azure IoTHub HTTP MQTT 現在、NTT ComのIoTプラットフォームである Things Cloud のクラウドアダプタやその他の新アダプタ対応についても現在開発を行っていますので、ご期待ください。 IoT Connect Gatewayにかける思い CI/CDの取り組みとサービスリリース ICGWの開発は、スピーディーに新機能を開発し、いち早くお客さまに提供するためにDevOpsチームとして開発、運用を行っています。 新機能開発・提供を実現するために以下のようなことをICGWのDevOpsチームでは取り組んでいます。このあたりの話もブログ投稿などでお話できればと思ってます。 1. Infrastructure as Code ICGWの環境構築作業は Terraform を利用し、コード管理で 開発環境、テスト環境、商用環境の構築を行っています。 これにより、新機能をリリースするために必要となる構成変更や拠点の追加をスピーディーに実現することが可能になりました。 2. Test as Code スピード感をもった開発も重要ですが、品質も重要ですので これまで通り品質を担保し、開発するための仕組みとして UnitTest, E2E Testなどの検証作業をGitHub Actionsで自動化することで従来の検証時間を削減しています。 また新機能追加でデグレが発生していないかをチェックし、品質を担保する仕組みを実現しています。 3. GitOps これまでの開発では、コード開発以外の作業や多大な時間が必要でした。 そこで、コンテナ化や Argo CD や Helm を利用することで、CI/CDを実現し開発者が開発に集中できる環境を実現し、商用環境に適応していくという仕組みを作りました。 また、Stg環境では、開発中の新機能を先行的にお客様やIoTデバイスベンダの方にトライアルして頂くなどの取り組みもすすめています。 個人的な思い このICGWは、私が小さなころから好きな 電子回路の世界 と大学院から夢中になった ネットワークやクラウドの世界 をつなぐサービスとして非常に思い入れがあるサービスです。 このサービス開発をはじめて、趣味でIoTデバイスをRaspberry PiやM5Stackなどを利用して色々と開発していますが、その根底には、 「つくるひと」 でありたいという思いがあると思っています。 以下の動画は2007年頃、とある番組の1000回放送記念CMとして１度だけ放送されたもので、リアルタイムに見て衝撃を受けたものです。 当時、分野をネットワークに変えて大学院進学するか悩んでおり、その後も、博士後期課程に進むか就職するかなど、いつも人生の大きな分岐点をこれまで支えてきてくれた大切な動画なので、紹介させてください。 この動画の中で、息子がただただ聞いてくる「なんでこの会社にしたの？」という無邪気な質問に対して、私達は自身の勤める社名に置き換えた時、「自分の子供が納得する答え」、「自分自身が納得できる答え」を出せるでしょうか？ 私の場合、「なんでNTT Com/NTTグループにしたの？」という質問に対して、父親の回答である「つくる人になりたかった」を 「つくる人であると共に、つなぐ人になりたかった」 と息子に自身をもって言えるよう、これからもサービス開発に取り組みたいとおもっています。 最後に IoTサービス関係者、クラウドサービス提供者などみなさんと共に、 私達の技術が誰かの何かの役に立ちたい 、またその先にいる 利用者の幸せに貢献できれば という思いをもって、これからもサービス開発を続けていきたいと思っています。 それがNTT Comが掲げる Re-connect X と自分は思っています。 この思いは、弊社のNTT Com Engineers' Blog投稿者の共通の思いであると思っています。そんな会社にしていきたいと思っていますので、これからも NTT Com ならびに NTT Com Engineers' Blog をよろしくお願い致します。 次回予告 今回は、ICGWのご紹介とICGWにかける思いの投稿になってしまいましたが、次回はICGWの使い方や、ICGWを使った電子工作やアプリの記事を投稿する予定です。 to be continued... ICGWに関するお問い合わせ先 トライアル、サービス導入に関するお問い合わせ 資料請求・お問い合わせフォーム 開発チームへのお問い合わせ メールを送る ※お手数ですが＠を半角文字に置き換えてください

こんにちは、デジタル改革推進部の河合と浅野です！ 私たちデジタル改革推進部では、普段から全社で使うためのデータ分析環境の開発・提供を行っています。 今回は社内でデータ分析コンペティションを開催したのでその内容を報告します。 社内データ分析コンペティションとは？ 社内にある様々なデータ活用課題をコンペティション形式に落とし込み、全社で知恵をしぼって解こうという試みです。 もともと、データサイエンスの界隈ではKaggleやatmaCupと呼ばれる分析力を競うコンペが行われており、課題や技術を集団で共有して解く文化があります。 今回はそれらを参考に、社内のデータを使ったコンペを 6/21~7/2 の２週間にかけて初開催しました。 開催にあたって期待したことは、以下の３つです。 様々な部署に散らばっているサービス特有のドメイン知識、データ、分析技術を一箇所に集める 優れたソリューションを集合知によって短期間で探し出す データ活用人材の育成や発掘 上記を満たすために、KaggleやatmaCupを参考にコンペのルールを工夫して作りました。 具体的には下記のような点です。 予測結果の設定 特定期間に過学習してしまうのを避けるため、予測範囲を2種類に分けて評価する。 一方は予測値を投稿すると即時計算されるpublic scoreに、もう一方は最終日まで結果がわからず順位決めに使われるprivate scoreとして評価する。 情報共有に対する評価 参加者は分析結果を適宜共有する（Discussion）ことができ、そこにいいねやコメントをつけることが可能。いいね数が上位の方も表彰対象とする チームでの参加も可能とする コンペのテーマと進め方 第一回のテーマとして、インターネットのトラフィック量(※通信量のこと)の将来予測を設定しました。 必要な分析技術の範囲としては、複数地域のトラフィックを予測する多変量の時系列予測となります。スコアとしては平均絶対パーセント誤差(MAPE)を使いました。 コンペティションは以下のようなスケジュールで実施しました。 6/21(月) 開会式:　テーマの説明 6/22(火) 初心者向け講座#1 データの読み込みからベースラインのsubmitまでのチュートリアル 6/24(木) 初心者向け講座#2 応用コンテンツの紹介。 EDA/validation評価について 6/28(月) もくもく会#1 6/29(火) もくもく会#2 7/2(金) ~17:30 コンペ終了 7/6(火) 結果発表・閉会式 7/14 成績上位者の発表. 分析内容の共有会 今回のイベントはフルリモートのオンライン開催でしたが、 コンペ初参加の方でもイベントに入りやすいように、初心者向け講座を複数回 また分析作業内容や疑問点を解消するためのもくもく会も複数回実施しました。 これらに参加すれば、誰でも共有されたサンプルコードを使って 予測結果を作って投稿できるような形にしています。 コンペ環境 デジタル改革推進部では、NTTcom内のデータ活用を推進するためDLXと呼ばれる全社員が使える分析基盤を開発しています。 今回はこの分析基盤にコンペ参加者に向けてJupyter labベースの環境を用意し、PythonやRを使って分析できるようにしました。 データセットはhadoop上に置き、trinoと呼ばれる分散SQLクエリエンジンを使って自由に参加者がSQLを叩いてアクセスできるようになっています。 また、某コンペサイトを参考に、社内コンペサイト「Saggle」を用意し、予測結果の投稿やコードの共有ができるようにしました。 分析Notebookの共有 リーダーボード 結果 ５０名を超えるエントリーをいただき、最終的なsubmit回数は800回を超えました。 参加者の予測誤差のスコア(public)の推移は以下のような感じでした。 コンペが進むにつれ全体のスコアが良くなっていく様子がみて取れます。 一方でprivate scoreの方も合わせて見てみると、分析コンペでありがちな過学習が発生していたのがわかります。 今回はsubmit回数の制限を行わなかったこともあり、public scoreを追い求めすぎてprivate scoreが下がり、最終順位が下がる(shake down)という悲しい思いをされた参加者が多かったと思います。 順位発表後には、スコア上位者の方に使った手法を解説していただきました。 参加者の声 開催後、参加者の方からアンケートを取ったところ 課題がやや難しかったという意見もありましたが、 「知識が無いなりにも操作ができる環境・サンプルコード準備を始め、基礎的な質問への応援サポートに感謝感謝でした」「初めてのコンペ参加でしたが、ディスカッションも盛り上がり、いろいろな気付きがあって大変楽しむことができました」 といった意見を多数いただくことができました。 このうち90%以上の方から、「次回開催があれば他の社員にも参加をお勧めしたい」と回答をいただき、社内でも非常にポジティブな意見をいただくことができました。 まとめ 今回は社内の実データを使った分析コンペの開催報告でした。 今回の分析コンペによって下記のような結果が得られました。 共通のデータを使って多様なスキルやバックグラウンドを持つ社員が議論しながら一つの分析課題に取り組むことができた 2週間という短い期間でデータの理解とより高精度な予測モデルを作成することができた 初めてコンペに参加した方/分析知識がなかった方を含め50名以上の方が、データ分析、予測までできるようになった 今後は、アイデアソンなどもう少し範囲を広げて分析コンペを定期開催できるよう目指していきたいと考えています。 これからもコムのデータ活用が盛んになり、業務やサービスをよりよくしていけるように取り組んでいきます！

職場体験型インターンシップ（エンジニアコース）募集中です！ (~2021/8/20) 本インターンシップは、実際に各分野でエンジニアとして働いているNTTコミュニケーションズの社員と一緒に働くことで、実際の開発現場を肌で感じて頂くことができるインターンシップです。 業務体験を通じて、NTTコミュニケーションズにおけるエンジニアの仕事が理解できるだけでなく、職場体験を通してみなさん自身が成長を実感できる内容になっています。 参加者からは「エンジニアの仕事が理解できた」「自分の活躍のイメージが湧いた」などの声も毎年多数頂いています。 また、参加いただいた学生の方から、次のようなアウトプットもいただいております。 NTTコミュニケーションズでインターンシップをしてきました!! NTTコミュニケーションズ インターンシップレポート 働くイメージを持ちたい方、自分のスキルや能力がどのように活かせるのかを知りたい方はぜひご応募ください！ 募集中のエンジニア種別は次のとおりです。 AIエンジニア ソフトウェアエンジニア ネットワークインフラエンジニア セキュリティエンジニア テレプレゼンスエンジニア その他詳細情報は、 募集ページ をご覧ください。みなさんのご応募をお待ちしております！ ※新型コロナウイルス感染状況により、開催の中止・開催内容の変更等の可能性があります。 ※夏インターンで実施するものは、エンジニアコースのみとなります。

こんにちは、イノベーションセンターの田良島です。普段はコンピュータビジョンの技術開発や検証に取り組んでいます。7月27日から30日にかけて、画像の認識と理解技術に関する国内会議の MIRU2021 が開催され、NTT Comからは計4名が参加し2件の発表をしました。 7/27(火)-7/30(金)にオンラインで開催される、画像の認識・理解シンポジウム( #MIRU2021 ) において、弊社イノベーションセンターから2件の研究成果を発表します！ 映像AI分野の研究者・エンジニア・学生が集う国内最大級の学会です。 学生は参加費無料✨ ぜひご参加ください▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月27日 画像の認識・理解シンポジウム( #MIRU2021 ) において、本日28日(水)のプログラムに、弊社の田良島が登場します！ ■15:00-15:30　口頭発表（ショート2） ■17:15-18:30　インタラクティブ1-2 「One Shot Deep Model for Multi-Actor Scene Understanding」 詳細はこちら▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月28日 画像の認識・理解シンポジウム( #MIRU2021 ) にて、弊社の丹野、市川、島田、木村、泉谷が研究成果を発表します！ ■7/29(木) 15:45-17:00 「プロセスデータおよび炉内映像Optical-Flowに基づくマルチモーダル深層学習によるごみ焼却プラントの蒸気量推定」 詳細はこちら▼ https://t.co/4RKvofBCSg — NTTコミュニケーションズ (@NTTCom_online) 2021年7月29日 ここでは、参加メンバーでMIRUの報告をしたいと思います。 ※なお私たちのチームでは、2021年8月4日現在エントリー受付中の 職場体験型インターンシップ に、 AI/MLシステムとの統合を志向した、メディアAI技術の研究開発 というポストを出しています。学生さんであればどなたでも応募可能です、ご興味あればぜひエントリーを検討ください！ MIRU2021 MIRUはコンピュータビジョンや画像映像認識を扱う国内最大級の学会です。個人的には、MIRUは SSII と並んで画像映像認識を対象とした国内学会の二大巨頭をなしている印象があります。MIRUの方がよりアカデミックな雰囲気 今年は過去最多の1,428名の参加があった とのことで、この技術分野の勢いをひしひしと感じます MIRUの発表区分(招待講演等を除く)には口頭発表(ロング、ショート)とインタラクティブ発表があり、前者は査読があります。今回NTT Comからは、口頭発表(ショート)1件とインタラクティブ発表1件を行いました。以下ではまず、口頭発表の機会をいただいた "One Shot Deep Model for Multi-Actor Scene Understanding" についてご紹介します。 NTT Comからの発表 この研究では、不特定多数の人物(アクター)が写る映像を入力としてそのシーンを認識する問題に取り組んでいます。より具体的には、アクターを検出・追跡することに加え、各個人がとる動作と、アクターが集団でとる行動とを認識するという問題です。集団の行動は、チームスポーツでのセットプレイをイメージしていただくと分かりやすいかもしれません。アクターはシーンの中でお互いに影響を及ぼし合うので、特に個人の動作や集団の行動の認識では、アクター間の相互作用を捉えることも重要になってきます。 アプローチとして、アクターの検出・追跡・個人動作認識・集団行動認識の各サブタスクにState-of-the-art(SOTA)の方法を適用するというものがまず思いつきます。ですがこのアプローチには、全体の処理が冗長でかつ時間がかかってしまう問題があります。どのサブタスクにも何かしらの深層学習モデルを用意することになり、かつそれらはしばしば同じバックボーンであったりするので、当然と言えば当然です。一方で各サブタスクについて考えてみると、例えば同一人物は前後のフレームで同じ動作を継続している可能性が高いなど、それらは少なからず関係し合っていることに気が付きます。サブタスクは関係し合っているのに各々は独立に解くというアプローチには、改善の余地がある気がしてきました。 このモチベーションのもと、本研究では上記の全サブタスクを解くための特徴をワンショットで出力可能なモデルを提案しています。モデルは、各フレームから検出、追跡、行動/動作認識のための特徴抽出を担う畳み込みニューラルネットワーク(CNN)、行動/動作特徴をその相互作用を考慮して変換するニューラルネットワーク(Relation Encoder)とから構成しています。Relation Encoderでは、Transformer 1 で採用されているMulti-Head Attentionを拡張し、アクターの見え方と位置どちらの情報もふまえた特徴変換を実現しているところがポイントです。 Volleyballデータセット 2 という代表的なベンチマークで評価したところ、各サブタスク毎にSOTAを適用するアプローチと同等の性能を、全体で約半分のモデルサイズおよび2倍の処理速度で実現できることが確認できました。 発表はZoomのウェビナーで実施し、およそ450名の方に聴講いただきました。またインタラクティブ発表はoViceで実施し、多くの方と直接ディスカッションさせていただきました。MIRU運営の皆様や聴講・質疑くださった皆様、まことにありがとうございました。この分野の競争は本当に激しいなと感じていますが、来年以降もぜひ私たちの取り組みを発表していけるよう頑張りたいです。 気になった発表 こんにちは、イノベーションセンターの鈴ヶ嶺です。普段は、クラウド・ハイブリッドクラウド・エッジデバイスを利用したAI/MLシステムに関する業務に従事しています。私からは3件気になった発表をご紹介します。 L1-2 動的光線空間のシングルショット撮影 概要 時間成分を含んだ動的な光線空間をシングルショット撮影から復元する手法を提案していました。光線空間とは様々な角度から撮影した画像を利用した多視点画像群で3次元ディスプレイなどに応用されます。従来的なカメラアレイでは装置の大規模化という課題、レンズアレイ型のplenoptic cameraでは一台のカメラで撮影できる代わりに視点ごとの空間解像度が低下するという課題があります。 例: 大規模なカメラアレイシステム 3 提案法では、1台のカメラの開口面と撮像面で得られる情報を適切に2次元上に符号化し、CNNで5次元の動的な光線空間を復元し高解像度、高フレームレートを実現していました。さらにハードウェアによる検証も実施しており、実応用上の有効性も示していました。 所感 1台のカメラにある開口面と撮像面の関係が光線空間を表現していることを利用し、それを2次元空間上に符号化し復元する発想が面白かったです。さらにハードウェアでも検証が成功しており、今後の応用が期待される研究でした。 L2-1 連動する骨格動作の表現に適した時空間特徴の学習による人物運動予測法 概要 人物骨格動作の予測モデルにおいて動作特徴を時間的・空間的に集約するアーキテクチャを提案していました。 人物運動予測モデルには、2つ課題があります。まず直前の動作が支配的なケースや、長期的な動作が支配的なケースなど参照すべき特徴が異なる時間的問題です。次に、局所的な動作のみを考慮すれば良いケースと大域的な動作を考慮しなければならないケースなど参照する特徴が異なる空間的問題です。提案法では、時間的問題に対してMultiscale Temporal Convolution 4 のそれぞれの中間層を用いて参照時間の異なる特徴を表現することで時間的に集約しています。空間的問題に対しては、Encoderでは位置ベースの空間に出力し、Decoderに角度ベースの空間を入力として利用していました。それぞれの空間は位置と回転ベクトルのヤコビ行列から2つの特徴量空間間のヤコビ行列を生成して写像されます。これらの手法から、高い性能を示す予測結果を提示していました。 所感 EncoderとDecoderで位置と角度という異なる特徴を用いることで空間的に頑健な予測モデルにしている点が面白かったです。実際のデモを見ても高い精度で予測されており、興味深い研究でした。 L5-3 An Improved Inter-intra Contrastive Framework for Self-supervised Video Representation Learning 概要 この発表では、動画に関する対照学習 5 の手法Inter-Intra Contrastive(IIC) 6 を改良したIICv2を提案していました。 IICの全体像 主にIICv2は3つの要素が拡張されています。1つ目がAnchorであるフレーム群からFrame repeating, Temporal shuffling, Clip rotationなど操作をして対照学習の負例を生成するintra-negative sampleです。2つ目は画像に対してのStrong data augmentations 7 です。3つ目はContrastive lossが適用される空間に表現をマッピングする小さなネットワークであるprojection head 8 です。実験結果として UCF101 9 , HMDB51 10 のデータセットにおいて最新のSOTAを上回る結果を示していました。 所感 動画に対する対照学習において、負例の生成方法や効果的なデータの水増し法などの様々な改良をしており勉強になりました。最終的な性能も現在のSOTAを上回っており、今後の参考にしたいと思いました。 こんにちは、イノベーションセンター新入社員の齋藤です。普段は、今回一緒に参加している鈴ヶ嶺と同じく、クラウド・ハイブリッドクラウド・エッジデバイスを利用したAI/MLシステムの研究開発をコンピュータビジョンを題材に取り組んでいます。私からも3件気になった発表をご紹介します。 L1-3 Can Vision Transformers Learn without Natural Images? arXiv:2103.13023 概要 Vision Transformer(ViT) 11 の性能は、学習に用いるデータセットサイズに強く影響を受けることが知られていますが、大規模なデータセットを用意するにはコストや倫理の問題が生じます。この研究では、数式から画像とラベルを自動生成する FractalDB 12 を用いてViTの事前学習を行うと、自然画像とその正解ラベルを用いて学習した場合とほぼ同精度が得られる、つまり自然画像を用いることなくViTの事前学習は可能だという驚くべき結果が示されています。 評価 ・FractalDBで事前学習したViTとImageNet-1k 13 ,Places-365 14 などを事前学習させたViTを比較した実験 ・FDSL(FractalDB-10k)とSSL(Jigsaw 15 , Rotation 16 , MoCov2 17 , SimCLRv2 18 )の比較実験を行っています。 Computer Vision and Pattern Recognition (CVPR). (2009) 248–255 DeiTsで事前学習済みのFractalDB-1k/10kがImageNet-100/Places-30のモデルを上回り、ImageNet-1k/Places-365を上回ることはできませんでした。ですが、ImageNet-1kと肉薄した性能を持っていることが実験から分かりました。 FractalDB-10KはSimCLRv2よりも若干精度を上回った結果を出しました。また、C10、VOC12、P30においては精度を上回った結果を出しています。 所感 今後、研究が発展することにより様々なタスクへの応用可能性が高いため、楽しみな研究の1つになりました。ソースコードもオープンソースで公開されているので、手元で試してみたいとも思います。 L2-4 Lightning-fast Virtual Try-on without Paired Data and Direct Supervision 概要 この研究では、弱教師あり学習を用いて、仮想試着を提案しています。仮想試着とは、Sourceの画像に対して、Targetの服に着せ替える技術のことで、応用先として、アパレルのECショップなどがあります。従来手法の、アノテーションコスト、メモリの消費量、テスト速度の問題を解決するものとして、本発表の手法 (LiVIRT) を提案しています。エンジンの中身としては、3つのネットワークを用いています。その中で無駄を取り払うなどの工夫によるネットワークの高速化を行っています。 評価 データにペアデータがある場合の実験では、教師あり学習の手法(CP-VTON 19 , SieveNet 20 )とLiVIRTの比較を行い、教師あり学習とほぼ同じ精度で仮想試着ができています。 ペアデータが存在する場合の実験においても、精度が良いことが実験で示されています。 所感 私が試したことのある仮想試着は、実際に着ている感があまりありませんでした。仮想試着の技術はECサイトのUX向上に大きく影響すると思うので、興味深く発表を聞かせていただきました。 L5-1 複屈折反射特性の計測に基づく材質識別 概要 材質識別は、資源の開発やリサイクル、自動運転など様々なシーンで求められる技術です。この研究では、複屈折反射特性から抽出された特徴量をU-net 21 に入力してクラス分類を行っています。 評価 79種類の材質を、金属・木材・布・樹脂・石材に材質クラスの識別を行っています。U-netと比較する手法としては、k近傍法を用いています。結果として、5種類の材質クラスの識別平均正解率は、U-netで0.90、k近傍法で0.87となり、U-netを用いた方が正解率が高いことが確認できました。 所感 複屈折反射特性から特徴量を求めている点が面白いと感じました。モデルのバックボーンを変えた場合の精度変化も気になるところです。 最後に MIRU2021の模様をご紹介しました。NTT Comでは、今回ご紹介した学会での発表調査はもちろんのこと、画像や映像、更には音声言語も含めた様々なメディアAI技術の研究開発に今後も積極的に取り組んでいきます。また一緒に技術開発を進めてくれる仲間も絶賛募集中です。 アカデミックな研究に注力したくさん論文を書きたい 最新の技術をいちはやく取り入れ実用化に結び付けたい AIアルゴリズムに加え、AI/MLシステム全体の最適な設計を模索したい という方々に活躍していただけるフィールドが弊社には多くあり、いくつか新卒採用のポジションを用意する予定です。エントリーの受付開始は2022年1月以降となる予定ですが、よろしければぜひ新卒採用ページをウォッチしていただけると嬉しいです さらに冒頭でも述べた通り、2021年8月4日現在、NTT Comでは 夏の職場体験型インターンシップ のエントリーを受付中です。私達のチームからも、AIエンジニアカテゴリに AI/MLシステムとの統合を志向した、メディアAI技術の研究開発 というポストを出しています。インターンを通じて、会社やチームの雰囲気、そして私たちの取り組みを知っていただく機会にできればと考えています。皆様のご応募、心からお待ちしています！ Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., … & Polosukhin, I. (2017). Attention is all you need. In Advances in neural information processing systems (pp. 5998-6008). arXiv:1706.03762 ↩ Ibrahim, M.S., Muralidharan, S., Deng, Z., Vahdat, A., & Mori, G. (2016). A Hierarchical Deep Temporal Model for Group Activity Recognition. 2016 IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 1971-1980. ↩ 裸眼立体ライブ映像システムを支えるカメラアレイの開発 https://news.mynavi.jp/photo/article/20080625-cameraarray/images/004l.jpg ↩ Lea, C., Flynn, M. D., Vidal, R., Reiter, A., & Hager, G. D. (2017). Temporal convolutional networks for action segmentation and detection. In proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (pp. 156-165). arXiv:1611.05267 ↩ Khosla, P., Teterwak, P., Wang, C., Sarna, A., Tian, Y., Isola, P., … & Krishnan, D. (2020). Supervised contrastive learning. arXiv preprint arXiv:2004.11362. arXiv:2004.11362 ↩ Tao, Li, Xueting Wang, and Toshihiko Yamasaki. “Self-supervised video representation learning using inter-intra contrastive framework.” Proceedings of the 28th ACM International Conference on Multimedia. 2020. arXiv:2008.02531 ↩ Grill, J.-B., Strub, F., Altche, F., Tallec, C., Richemond, P. H., ´Buchatskaya, E., Doersch, C., Pires, B. A., Guo, Z. D., Azar, M. G. et al.: Bootstrap your own latent: A new approach to self-supervised learning, Advances in Neural Information Processing Systems (2020) ↩ Chen, T., Kornblith, S., Norouzi, M., & Hinton, G. (2020, November). A simple framework for contrastive learning of visual representations. In International conference on machine learning (pp. 1597-1607). PMLR. ↩ Soomro, K., Zamir, A. R. and Shah, M.: UCF101: A dataset of 101 human actions classes from videos in the wild, arXiv preprint arXiv:1212.0402 (2012). ↩ Kuehne, H., Jhuang, H., Garrote, E., Poggio, T. and Serre, T.: HMDB: A large video database for human motion recognition, IEEE International Conference on Computer Vision, pp. 2556–2563 (2011). ↩ Dosovitskiy, A., Beyer, L., Kolesnikov, A., Weissenborn, D., Zhai, X., Unterthiner, T., … & Houlsby, N. (2020). An image is worth 16x16 words: Transformers for image recognition at scale. arXiv preprint arXiv:2010.11929. arXiv:2010.11929 ↩ H. Kataoka, K. Okayasu, A. Matsumoto, E. Yamagata, R.Yamada, N.Inoue, A. Nakamura, and Y. Satoh. Pre-training without Natural Images. In Asian Conference on Computer Vision (ACCV), 2020. arXiv:2006.10029 ↩ Deng, J., Dong, W., Socher, R., Li, L.J., Li, K., Fei-Fei, L.: ImageNet: A LargeScale Hierarchical Image Database. In: The IEEE International Conference on ↩ Zhou, B., Lapedriza, A., Khosla, A., Oliva, A., Torralba, A.: Places: A 10 million Image Database for Scene Recognition. IEEE Transactions on Pattern Analysis and Machine Intelligence (TPAMI) 40 (2017) 1452–1464 ↩ Noroozi, M., & Favaro, P. (2016, October). Unsupervised learning of visual representations by solving jigsaw puzzles. In European conference on computer vision (pp. 69-84). Springer, Cham. ↩ Gidaris, S., Singh, P., Komodakis, N.: Unsupervised Representation Learning by Predicting Image Rotations. In: International Conference on Learning Representation(ICLR) (2018) arXiv:1803.07728 ↩ Chen, X., Fan, H., Girshick, R., & He, K. (2020). Improved baselines with momentum contrastive learning. arXiv preprint arXiv:2003.04297. arXiv:2003.04297 ↩ Chen, T., Kornblith, S., Swersky, K., Norouzi, M., & Hinton, G. (2020). Big self-supervised models are strong semi-supervised learners. arXiv preprint arXiv:2006.10029. arXiv:2006.10029 ↩ Bochao Wang, Huabin Zheng, Xiaodan Liang, Yimin Chen, Liang Lin, Meng Yang.“Toward Characteristic-Preserving Image-based Virtual Try-On Network”.arXiv preprint arXiv:1807.07688. arXiv:1807.07688 ↩ Surgan Jandial, Ayush Chopra, Kumar Ayush, Mayur Hemani, Abhijeet Kumar, Balaji Krishnamurthy.“SieveNet: A Unified Framework for Robust Image-Based Virtual Try-On”.arXiv preprint arXiv:2001.06265. arXiv:2001.06265 ↩ O. Ronneberger, P. Fischer, T. Brox, ”U-net: Convolutional networks for biomedical image segmentation”, MICCAI, 2015 ↩

こんにちは、イノベーションセンターの前田です。今回は、前回に引き続き、私のチームで開発中の制御（OT）システム向けセキュリティ対策技術OsecT（オーセクト）についてご紹介します。 前回の記事（前編）では、以下の内容をご紹介しました。 OTネットワークの概要 OTネットワークのセキュリティ対策と課題 OsecTの概要 OsecTのネットワーク可視化機能の詳細 本記事では、 OsecTの脅威検知機能の詳細 について、ご紹介します。 前編のおさらい 工場・ビル等のスマート化に伴い、OTネットワークのセキュリティリスクも高まっています。しかし、OTのネットワークは閉域ネットワークとして構築されてきたことや独自OS・プロトコルが多数利用されてきたことから、セキュリティ対策が進んでいない現状があります。こうした状況を受けて、NTT Comでは、OTのセキュリティ対策技術OsecT（オーセクト）を開発しています。 OsecTには、 守るべき資産や通信の可視化を行うネットワーク可視化機能 と、 不正に接続された端末やサポート切れのOSを利用する端末等を検出した際のアラート機能（脅威検知機能） の2つの機能があります。 以降では、OsecTの脅威検知機能の詳細について、開発の工夫点などを交えながらご紹介します。 ※OsecTは現在開発中の技術であり、正式リリース時には仕様・画面イメージが変わる可能性が大いにあります。 脅威検知機能 OTの守るべき資産・ネットワークを可視化し、資産台帳の最新化や監視ポイントの明確化等が行えたら、次のステップとして有用なのが脅威検知機能になります。 こちらの機能もネットワーク可視化機能と同様に、オフラインのトラヒックデータを元に定期アセスメント等で利用する使い方もできますが、リアルタイムのトラヒックデータをミラーリングで取り込んで脅威検知機能で処理し、発出されるアラートを監視する使い方が有効です。 OsecTでは、以下の7つの脅威検知機能を開発中です。機能毎にコンテナを分けることで、必要なものだけを選択して導入できる作りにしています。 また、各脅威検知機能は、次のいずれかに属しています。 学習期間を定めてその期間を正常状態として学習し、検知期間において、学習モデルと異なる振る舞いが観測された場合にアラートを発出する「アノマリ検知」 セキュリティの脅威につながる通信パターンやサポート切れのOS情報などを事前定義したルールに基づき検知期間の通信をチェックし、ルールにマッチした場合にアラートを発出する「ルールベース検知」 新規端末検知 こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{IPアドレス, MACアドレス}の組み合わせを学習して、学習モデルに登場しない{IPアドレス, MACアドレス}の組み合わせの通信が観測された場合にアラートを発出しています。 アラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{IPアドレス, MACアドレス}の組み合わせに加えて、当該端末を特定しやすいように、MAC Vendorの情報を、また、当該端末が不正なものだった場合にアクセス先を特定できるように、当該端末がクライアントとなって利用しているサービスと宛先IPアドレス、当該端末がサーバとなって利用しているサービスと送信元IPアドレス、の情報を表示しています。こちらのアラートを見ることで、計画されていない端末がネットワークに接続された際などに早期発見することができます。 ネットワークホワイトリスト こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{送信元IPアドレス, 送信元ポート番号, 宛先IPアドレス, 宛先ポート番号, プロトコル}の組み合わせを学習して、学習モデルに登場しない組み合わせの通信が観測された場合にアラートを発出しています。 OTの独自サービスのプロトコルの中には、一般的な通信サービスの振る舞いとは異なり、送信元ポート番号が固定値で、宛先ポート番号がランダム or 範囲の値を取るものがあります。こちらの特徴を考慮せずにネットワークホワイトリストの学習モデルを作成すると、学習モデルの行数（テーブル数）が膨大になる問題があります。OsecTでは、こうしたサービスの通信を自動判別・集約して効率的に学習しています。 学習モデルは、例えば、以下のようなものが作成され、4行目や7行目が前述の仕組みで集約された箇所になります。 また、ネットワークホワイトリストのアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{送信元IPアドレス, 送信元ポート番号, 宛先IPアドレス, 宛先ポート番号, プロトコル}の組み合わせに加えて、当該IPアドレスに紐づく端末や利用サービスを特定しやすいように、IPアドレス部分にマウスカーソルを合わせた際に、端末の情報を吹き出しで表示するようにしています。こちらのアラートを見ることで、平常時とは異なる宛先への通信や平常時に利用していない不審なサービスの通信などを早期発見できます。 OTコマンドホワイトリスト こちらは、アノマリ検知に属し、OTプロトコルのL7情報を用いた脅威検知機能になっています。 現在は、ビルのオートメーション・制御に利用されるBACnet/IPに対応しており、学習期間のトラヒックデータに登場する、{送信元IPアドレス、宛先IPアドレス、BACnet/IPのL7情報}の組み合わせを学習して、学習モデルに登場しない組み合わせの通信が観測された場合にアラートを発出しています。 OTコマンドホワイトリスト（BACnet/IP）のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、未学習の{送信元IPアドレス、宛先IPアドレス、BACnet/IPのL7情報}の組み合わせに加えて、当該IPアドレスに紐づく端末や利用サービスを特定しやすいように、IPアドレス部分にマウスカーソルを合わせた際に、端末の情報を吹き出しで表示しています。こちらのアラートを見ることで、平常時とは異なるBACnetサービス（コマンド）通信の発生を早期発見でき、例えばビルシステムの保守作業スケジュール等と突合して適切な通信かを確認することで、異常を特定できます。 流量ベースライン検知 こちらは、アノマリ検知に属し、学習期間のトラヒックデータに登場する、{送信元IPアドレス, 宛先IPアドレス}のペア毎に、各時間帯のトラヒック量（パケット数、バイト数）をベースに、各時間帯で取り得るトラヒック量の範囲（上限値と下限値）を推定して、その値を学習モデルとして保存します。検知期間では、学習されたトラヒック量の上限値を上回る/または下限値を下回る通信が観測された場合にアラートを発出します。また、OTでは決められた時間に機械的に通信する端末が多く存在するため、{src_ip, dst_ip}のペア毎に、各時間帯での通信の有無を学習して、平常時は通信が発生する時間帯にもかかわらず、通信が発生しなくなった場合にもアラートを発出しています。 OTでは、工場等が稼働している日なのか、非稼働の日なのかによって、通信量や頻度の傾向が大きく異なる場合があるため、こちらの機能では、非稼働日や非稼働の時間帯を設定できるようにしています。非稼働日・時間帯の場合は、稼働日とは別のベースライン（上限値と下限値）を作成して検知に利用します。 流量ベースライン検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、送信元IPアドレス、宛先IPアドレス、アラート種別（上限値を上回った/下限値を下回った/通信が停止した）、データ種別（パケット数/バイト数）、観測した通信量、学習された通信量の上限値、学習された通信量の下限値、通信断の判定に利用されるカウンタの値などを表示しています。また、他の脅威検知と同様に、IPアドレスにマウスカーソルを合わせた際の端末情報の吹き出し表示もあります。 例えば、画像の2行目では、2019/08/20 6:30において、10.1.0.232から10.1.0.55へのパケット数が学習された上限値の483個に対して、10052個観測されており、上限値を超えたことでアラートが発出されています。 流量ベースライン検知ではさらに、通信量の変化や異常性を分かりやすくするために、次のような時系列グラフで、観測された通信の詳細を確認できるようにしています。 こちらのグラフでは、赤線が学習された上限値、青線が学習された下限値、黒線が観測値を表しています。また、グラフ上の点にマウスカーソルを合わせることで、観測された値や通信に含まれるサービスの内訳を吹き出しで表示しています。さらに、こちらの画面で分析に必要な情報が極力完結するように、画面右には、送信元IPアドレスと宛先IPアドレスに紐づく端末の詳細情報を表示しています。こちらのアラートや通信の詳細ページを見ることで、平常時からの急激な通信量の増加や攻撃等でのシステム停止による通信断などを早期発見できます。 周期異常検知 こちらは、アノマリ検知に属し、BACnet/IPに特化した脅威検知機能となっています。学習期間のトラヒックデータに登場する、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ毎に、信号処理技術を用いて、通信周期（60秒に1回、通信発生など）を抽出して学習します。検知期間では、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}毎に、通信周期を抽出し、学習された周期と比較して、周期外の通信が発生した場合、または周期的な通信が消失した場合にアラートを発出します。 こちらは、NTTの社会情報研究所で考案された 技術 がベースとなっており、複数のビルの通信データを分析して得られたノウハウに基づき、アルゴリズムの構築、特徴量・各種パラメータの設定を行っています。 周期異常検知の学習モデルは、次のようになっています。 こちらでは、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ毎に、学習された通信周期(PRI)、学習時に非周期として判定された通信数(non_periodic)、最終判定されたモデル(period=通信に周期性あり、non=通信に周期性なし、period_and_non=通信に周期性ありとなしが混在)などを表示しています。学習された通信周期(PRI)の項目は、(時間間隔, 通信回数)で表記されるようになっており、例えば、(62, 3)は、62秒毎に3回ずつの通信が発生することを意味しています。また、周期性なしの場合は(-1, 1)が表示されます。なお、1行目の[(62, 3), (-1,1)]は、通信を分解した際に、周期性のある通信と非周期の通信が混在していることを意味しています。 また、周期異常検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、アラートの内容(Non Periodic communication=周期外通信の発生、Lost Communication=周期通信の消失)、{送信元IPアドレス, 宛先IPアドレス, BACnet/IPのL7情報}の組み合わせ、ホバーで端末の詳細情報を表示しています。こちらのアラートを見ることで、BACnet/IPにおける不正なコマンドの挿入や通信断を早期発見できます。 サポート切れOS端末検知 こちらは、ルールベース検知に属します。サポート切れOSの一覧表を事前ルールとして保持しており、検知期間のトラヒックデータの中に登場する{IPアドレス, MACアドレス}の組み合わせ毎にOSを推定し、サポート切れOSの一覧表の内容とマッチする場合にアラートを発出しています。 前編でご紹介したネットワーク可視化機能でも、OS推定情報を表示していますが、あちらは主に定期アセスメント等で利用することを想定しているため、様々なメトリックを利用して、少しでも古いOSの疑いがあれば表示するようにしているのに対して、脅威検知機能は主にリアルタイムにアラートを監視する使い方を想定しているため、運用者の負担を軽減する（誤検知を減らす）ように、確実性が高く、改ざんが困難なメトリックのみを利用してOS情報を推定しています。 サポート切れOS端末検知のアラート画面は、次のようになっています。 こちらでは、当該通信が発生した時刻、{IPアドレス, MACアドレス}の組み合わせ、OS情報に加えて、当該端末を特定しやすいように、MAC Vendorとホスト名の情報を、また、当該端末が不正なものだった場合にアクセス先を特定できるように、当該端末がクライアントとなって利用しているサービスと宛先IPアドレス、当該端末がサーバとなって利用しているサービスと送信元IPアドレス、の情報を表示しています。こちらのアラートを見ることで、サポート切れのOSを利用する端末がネットワークに接続された際に早期発見できます。 シグネチャ検知 こちらは、ルールベース検知に属します。セキュリティの脅威につながる通信パターンの情報（シグネチャ）を事前ルールとして保持しており、シグネチャの内容に合致する通信が観測された場合に、アラートを発出しています。 こちらの機能では、オープンソースのIT向けIDS(Intrusion Detection System)である「 Suricata 」と、Proofpoint社が配布している ルールファイル （シグネチャ）を利用しています。 ルールファイルには、セキュリティの脅威につながる通信パターンを表すルールが複数記載されていますが、一例を挙げると、次のようなものがあります。 alert http $HOME_NET any -> any any (msg:"ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted"; flow:established,to_server; content:"Authorization|3a 20|Basic"; nocase; http_header; content:!"YW5vbnltb3VzOg=="; within:32; http_header; content:!"Proxy-Authorization|3a 20|Basic"; nocase; http_header; threshold: type both, count 1, seconds 300, track by_src; reference:url,doc.emergingthreats.net/bin/view/Main/2006380; classtype:policy-violation; sid:2006380; rev:13; metadata:created_at 2010_07_30, updated_at 2020_08_28;) Suricataのルールのフォーマットは、以下のようになっています。 action: シグネチャにマッチした際のアクション（例では、alert） header: ルールを適用するプロトコル、IPアドレス、ポート番号、通信の向き（例では、http $HOME_NET any -> any any） rule options: オプション（例では、(msg: から 28;) までの括弧で囲まれた部分） 上記の例は、http通信かつ監視対象のネットワークから任意のポート、宛先への通信を検査し、rule optionsで指定された条件を満たした場合に、"ET POLICY Outgoing Basic Auth Base64 HTTP Password detected unencrypted"(ベーシック認証でHTTPパスワードが暗号化されていないことを検出したという意味)のアラートを発出するルールになっています。 rule optionsには、細かなマッチ条件などを;で区切って複数指定可能で、例えば、 flow:established,to_server; content:"Authorization|3a 20|Basic"; の部分は、フローが確立していてclient→server方向であること、ペイロードに"Authorization: Basic"が含まれること、を表しています。 正確なルールの読み方は、 公式ドキュメント をご参照ください。 OsecTでは、Suricataの出力結果を、次のようなアラート画面として表示しています。 こちらでは、当該通信が発生した時刻、送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号、プロトコル、マッチしたルールの内容とカテゴリ、Severity（1: high, 2: medium, 3: low）を表示しています。また、他の脅威検知機能と同様に、極力こちらの画面だけで必要な情報を確認できるように、ホスト情報をホバー表示しています。 こちらのアラートを見ることで、脆弱性を含む古いJavaの利用や平文でのパスワードのやり取りなど、セキュリティの脅威につながる通信の発生を早期発見できます。 アラート統合画面 OsecTでは、ここまでにご紹介した7つの脅威検知機能のアラートをまとめて確認できる画面も作成しています。 こちらは、日常的にアラートを監視する際にメインで利用する画面をイメージして作成しています。送信元IPアドレスや宛先IPアドレスなどの条件を設定して、アラートをフィルタリングできるため、特定のIPアドレスに着目して、複数の脅威検知のアラートの有無を横断的に確認したい場合などにも利用できます。 最後に 今回は、NTT Comで開発中のOTセキュリティ対策技術であるOsecTの脅威検知機能についてご紹介しました。工場等のスマート化を推進していく上では、これまであまり検討が進められていなかった、OTのセキュリティ対策を考えることが非常に重要になってきます。本記事の内容が、ご検討のお役に立ちましたら幸いです。また、本記事の感想やフィードバックもお待ちしております。 ※2021年6月現在、OsecTの実証実験のトライアル利用者様を募集しております。無償でご利用頂けますので、国内に制御システムをお持ちの製造業・インフラ事業者の方で実際にお試ししたいという方がいらっしゃいましたら、是非 こちら からご応募頂けますと幸いです。

イノベーションセンターの小林です。普段は、ある日は部内情シス、ある日は情報セキュリティオペレーションをやっています。以前の開発者ブログに寄稿したこともあり、今回の開発者ブログリニューアルにもかかわりました。 今回のリニューアルにあたっては、各記事に対する社内レビューと記事公開のプロセスを「いい感じ」にしたいよねとの声があり、現時点ではそれなりに満足いくものを作れました。その中身を少しご紹介します。 レビュー 以前の開発者ブログの頃から、寄稿された記事は有志によるレビューを通してから公開するようにしていました。主に見ていたのは文法的な間違いがないか、NTT Comの統一表現を使っているか、明らかな事実誤認や錯誤がないか、といったポイントです。このレビューの仕組み自体は、リニューアルにかかわった面々とのディスカッションを踏まえて、今回のリニューアル後も引き続き行うことにしました。 かつてのレビューは、Google DocsやWordなどで寄稿者がまとめた原稿に、レビュワーがコメントをつけて寄稿者に戻し、寄稿者が内容を修正した後ブログプラットフォームへ投稿する流れになっていました。このプロセス自体は一応動くには動くものの、開発者ブログの中身としてはあまり「いい感じ」の状態ではないね、との話はずいぶん前からありました。 どうしたか 今回のリニューアルに際し、次のような仕組みを作りました（説明のため一部割愛しているところがあります）。 簡単な流れはこうです。 寄稿者にはMarkdown形式で原稿を書いてもらい、画像（あれば）とともにGitHubにコミットします。そのコミットをpull requestにしてもらいます（図中の1）。 レビュワーは従来通り内容をチェックし、問題なければマージします（図中の2）。 マージをきっかけにGitHub Actionsによるデリバリプロセスがスタートし、原稿と画像を読み込んでブログプラットフォームのAPI経由で記事を送信、最終的に公開される仕組みです（図中の3と4）。 図中では表現していませんが、1でpull requestをオープンした時点でもGitHub Actionsが起動し、Linterによる文法・表現のチェックを行うようにもしました。記事が長いと見落としがちな表記揺れにも気づきやすくなります。 得られたこと GitHubのpull request機能に備わっているコメント機能（ソースコードの行を指定してコメントがつけられる）を使えるようになったこと、また変更前後の差分をすぐ引き出せるようになったことが大きいです。Google Docsでも任意の箇所にコメントをつけたり、修正を提案する機能もありますが、解決済みとしたコメントや修正を受け入れた箇所を後から探すことには困難が伴います。 また、ブログプラットフォーム本体の、投稿権限を持つユーザーをいたずらに増やさなくて済む点も挙げられます。投稿したい人はGitHubへのアクセスさえあればよく、プラットフォーム側のユーザー管理にかかる手間が削減できます。寄稿者にしてみても、エンジニアにとっては使い慣れた道具であるGitHubでライティングができることは、新たな学習コストをかける手間が省けます。 今後 GitHubとGitHub Actionsを中心としたエコシステムでは、まだいろいろできることがありそうです。 画像の適切なリサイズ、記事サムネイルの生成など画像に関する処理 表現チェックの自動化（textlintを使うなど） 社内Slackに新着投稿の通知を出して、コミュニティを盛り上げる……などなど 寄稿者、レビュワーほか開発者ブログにかかわる人にとって「いい感じ」のプラットフォームにしていければいいなとも思います。 もちろん読者の皆様にもメリットがある話だと思っています。「簡単に書ける」ことがNTT Com内に知れ渡れば、きっと隠れた寄稿者がどんどん出てきて、皆様にもどんどん新しい記事をお届けできる、はず。 今後の開発者ブログのコンテンツにもご期待ください！