この記事は NTTコミュニケーションズ Advent Calendar 2021 18日目の記事です。 はじめに こんにちは、イノベーションセンターの齋藤　暁です。普段はコンピュータビジョンの技術開発やAI/MLシステムの検証に取り組んでいます。今回は、JetsonでJAXが使えるように環境の構築をしていくのですが、時間の関係上ビルドまでたどりつくことができませんでした。ただ、せっかくなので奮闘記として、どのような方法でエラーハンドリングしたかを残しておきたいと思いますので。自身への戒めという側面もありますが、次にJetsonでJAXを使いたい人が、この方法はクリティカルなエラーハンドリングではないんだということを知っていただくことが嬉しいです。 (JAXは勉強したいと思っているので、ビルドがうまく行った際には、情報を更新したいと考えておりますので、適宜のぞいてみていただけるとビルドできた例を見ることができるかもしれないです。) JAXとは google/jaxから引用 まずJAXについて軽く説明をしたいと思います。 JAXとはAutogradとXLAを組み合わせた機械学習のライブラリです。 特徴的な点としては、JAXがXLAを使ってGPUやTPU上でNumPyをコンパイルして実行できるところです。jitのデコレータによるコンパイルとgradによる自動微分を組み合わせて使用できます。 今後も新しい機能がでることを明言していることから、今後ますます発展するライブラリであると思っています。 モチベーション 現在私は、Jetsonなどのエッジデバイスを用いた映像解析アプリケーションの開発をしています。この開発では、エッジデバイスを含めたモデルの最適な配置についても開発の課題としております。 高速に計算をできれば、よりリアルタイムに近い推論をできる嬉しさがあると考えられます。ただ、JAXは2018年にローンチされたライブラリであるため、エッジデバイスで利用することに適しているのかという議論についてもあまり数がないように思いました。 そのため、今回はJAXをJetsonにそもそもインストールし、使用できるのかという部分から検証したいとモチベーションがあります。 環境構築 ※注意: まだJetsonでJAXを使えるようにできておりません。できた際には、この記事を更新したいと思っていますが、下記の方法では私の環境ではビルドできないことを確認しています。 最初は、Jetson Xavier NXで環境構築を試みたのですが、私の環境ではbuildの途中でメモリが溢れてしまいました。もしかしたらSwap領域を増やせば、落ちないかもしれないですが、今回はJetson AGX Xavierでビルドを行いました。(Jetson Nanoでできたという記事がありますが、Jetson Xavier NXでのビルドで落ちていたので、こちらもどこかでやりたいですね) Jetsonの環境 まず、Jetson環境の構築から始めます。 今回私が使用するJetsonのOSであるL4Tのバージョンは、32.6.1。Jetpackのバージョンは4.6を選択しました。内部ストレージは、32GBしかないため、NvMeのSSD 256GBを増設しました。 bootFromExternalStorage の手順に従ってJetPack4.6をNvMeから起動します。以下に簡単にまとめます。詳しい説明については、githubに載っているのでそちらの参照をお願いいたします。 # Ubuntu18.04 or Ubuntu20.04を入れたx86_64ベースのホストPCを用意します # git cloneでbootFromExternalStorageをインストールします git clone https://github.com/jetsonhacks/bootFromExternalStorage.git cd bootFromExternalStorage . install_dependencies.sh . get_jetson_files.sh # JetsonとホストPCをUSBケーブルでつなぐ # このスクリプトがうまくいくと、Jetson AGX Xavierが起動する . flash_jetson_external_storage.sh # Jetson AGX Xavierに、bootFromExternalStorageをインストールします # 以下のスクリプトを実行することによってcuda、cudnnなどをインストールできます . install_jetson_default_packages.sh JAXの環境構築 .bashrcの一番下に以下を追加します。 sudo vim ~/.bashrc export PATH=/usr/local/cuda/bin${PATH:+:${PATH}} export LD_LIBRARY_PATH=/usr/local/cuda/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} 次に以下のスクリプトを実行してインストールするとビルドが始まります。 source ~/.bashrc #PPAの追加 sudo add-apt-repository ppa:deadsnakes/ppa sudo apt update # 現在(2021.12.15)のJAXは、python3.6を実行環境から外しているため、 # 今後アップデートの際にサポートから外れないように、python3.9を選択しました sudo apt install python3.9 python3.9-dev sudo apt install python3-pip sudo pip3 install virtualenv virtualenv -p /usr/bin/python3.9 jax source ./jax/bin/activate sudo apt-get install python3.9-distutils #必要なライブラリのインストール python -m pip install numpy scipy six wheel sudo apt install g++ #jaxのインストール git clone https://github.com/google/jax cd jax python ./build/build.py おやおや...? 何かエラーが出てますね長いエラーがでているので、とりあえず怪しい部分を抜粋してみます。 #エラー文 [2,118 / 5,712] Compiling llvm/lib/Target/X86/X86ISelLowering.cpp; 50s local ... (8 actions running) [2,155 / 5,712] Compiling llvm/lib/Target/X86/X86ISelLowering.cpp; 216s local ... (8 actions running) ERROR: /home/hoge/.cache/bazel/_bazel_nvidia/a5643b5cc286b9b13a96818003a4a7dd/external/org_tensorflow/tensorflow/python/lib/core/BUILD:49:11: Compiling tensorflow/python/lib/core/bfloat16.cc failed: (Exit 1): gcc failed: error executing command (cd /home/hoge/.cache/bazel/_bazel_nvidia/a5643b5cc286b9b13a96818003a4a7dd/execroot/__main__ ... JetsonのCPUのアーキテクチャはARM64ですが、X86のllvmをコンパイルしていますね。ですので、とりあえずarmのllvm一式をインストールします。 sudo apt-get -y install libllvm-7-ocaml-dev libllvm7 llvm-7 llvm-7-dev llvm-7-doc llvm-7-examples llvm-7-runtime エラー文は変わってますね、今度は /.cache/bazel のパーミッションがないのか? #エラー文 ERROR: /home/nvidia/.cache/bazel/_bazel_nvidia/a5643b5cc286b9b13a96818003a4a7dd/external/llvm-project/llvm/BUILD.bazel:2068:11: Compiling llvm/lib/Passes/PassBuilder.cpp failed: (Exit 4): gcc failed: error executing command とりあえず、パーミッションをこのコマンドで変えてみます。 sudo chmod -R u+rw ~/.cache/bazel/ エラーが止まらない..。 次にできることとして、JetPackを使うと感じることが、ライブラリのバージョンによって動く動かないがあるので、bazelのバージョンによる問題ではないかと仮定しました。 現在のJAXのbranchのbazelのバージョンは、4.2.1です。しかし、bazelのpreinstallができるバージョンを見ているとbazel4.2.1は、JetPack4.6.1に対応していないのかなと思われます。そのため、今回はJAXの最新バージョンを使うのではなく、bazel3.7.2がビルドされるバージョンを使用してみます。 #bazel3.7.2 且つarmに対応しているtagの選択 git checkout -b jax-v0.2.17 #　.cache/bazel/ のパーミッション系の問題が起きないように sudo chmod -R u+rw ~/.cache/bazel/ python ./build/build.py うーん。さっきとエラーが変わっていないような気がします。 numpyのバージョンという線もあるので、一応numpy1.21.4から下げてビルドをしてみましたが、エラーは変わらず..。 #エラー文 ERROR: /home/nvidia/.cache/bazel/_bazel_nvidia/f136147ae544c503f5fd3870723c0471/external/org_tensorflow/tensorflow/compiler/xla/service/cpu/BUILD:393:11: C++ compilation of rule '@org_tensorflow//tensorflow/compiler/xla/service/cpu:ir_emitter' failed (Exit 4): gcc failed: error executing command ここで、タイムアップとなってしまいました。他にも細々とやったのですが、主にやったことが以上となっています。 所感 JetsonでJAXの環境構築にチャレンジしたのですが、冬休みの課題となりました。JAXで遊ぶことは今回達成できませんでしたが、中で何がコンパイルされているのか見ることはできたので、良い勉強になったかと思われます。また、この方法でやれば良いのではという情報を共有してくださる方がおりましたら str.saito＠ntt.com まで教えていただけると嬉しいです。 おわりに 今回は、JAXをJetson AGX Xavierで環境構築をしたかったのですが、まだこれをすれば確実にビルドできる!という方法がなく1週間ほどでは難しかったです。そのため、とりあえずビルドをすることが今後の課題となりそうです。 そして今後は、JAXを使って物体検出のモデルを書いてみたいと思っているので、その際にベンチマークを測れればいいなと思います。(年末年始にチャレンジしてみたい) それでは、明日の記事もお楽しみに！ 参考 @software{jax2018github, author = {James Bradbury and Roy Frostig and Peter Hawkins and Matthew James Johnson and Chris Leary and Dougal Maclaurin and George Necula and Adam Paszke and Jake Vander{P}las and Skye Wanderman-{M}ilne and Qiao Zhang}, title = {{JAX}: composable transformations of {P}ython+{N}um{P}y programs}, url = {http://github.com/google/jax}, version = {0.2.5}, year = {2018}, }

この記事は NTTコミュニケーションズ Advent Calendar 2021 の17日目の記事です。 はじめに こんにちは。プラットフォームサービス本部 データプラットフォームサービス部でSmart Data Platform(SDPF)のサービス企画を行っている安井・小野です。 閲覧頂きありがとうございます。我々は当社が提供しているSDPFサービスを組合わせた具体的な事例紹介をしております。 前回、 第1回目 では、いくつかの組み合わせ事例をご紹介しました。 今年を振り返ってみると、コロナ禍による在宅勤務が推進され、テレワークが大々的に進み、今ではオンラインミーティングツール(Microsoft Teams等)は必要不可欠なツールとなりました。 また、オンライン利用が広がる中、サイバー攻撃を受けるリスクもこれまでよりも高まっており、ランサムウェアの被害が社会問題にもなってきています。 SDPFサービス群の組合せ事例の第2回目の紹介として、「オンラインツール含むMicrosoft社のMicrosoft 365のデータを安全にランサムウェア対策をしてバックアップする」ユースケースについて、 SDPF上でどのように実現するのか、検証確認した結果についてご紹介させていただきます。 背景 Microsoft 365などのSaaSサービスがビジネスツールとして利用が進む ビジネスツールとしてMicrosoft 365の利用拡大は進んでおり、特にコロナ禍でのワークスタイル変革やテレワークの定着化でMicrosoft Teamsをオンラインツールとして利用が増々進みました。 このようなビジネス上でやり取りする重要なデータはSaaS/クラウド上に存在し、Microsoftの標準の機能でもバックアップしていますが、最終的にはデータ保護/管理責任はユーザー側にあります。 そのため、人為ミス対策や退職者データの復旧等に備え、Microsoftもユーザー自身でのバックアップを推奨しています。 ランサムウェア被害が広がり重要データの暗号化等の被害が発生 ユーザー自身がデータ消失のリスク(システム障害、故意/不意のデータ削除等)に備えてバックアップを取得しますが、昨今の情勢から、もう1つの観点で重要な対策を実施する必要があります。 それがランサムウェア対策です。 警察庁での広報資料(p13) では、脆弱性の探索行為等に関する観測状況について記載されており、脅威が増加傾向にあることが確認できます。 実際にランサムウェア被害は社会的な問題にもなり、医療機関にも広がる中、 厚生労働省はサイバー攻撃対策のガイドライン を示しています。 ランサムウェア攻撃への対策としてネットワークの境界対策やエンドポイントでの防御策を講じて感染を回避する入口対策の実施や、感染の検知と対応の事後対策をする体制構築が必要です。 上記を行った上でも実際の被害の発生が続いております。今日では「ランサムウェアに感染した場合でも速やかに復旧できるよう、 データの上書きや改ざんを防止したバックアップを取得しておき、データ暗号化やデータ消失、金銭的な被害を抑える対策を実施する」という考え方が広まりました。 SDPFサービスを利用してどのように実現したか 以降に詳細を記載しますが、NTT Comの各種サービスを組み合わせて実現してみました。 閉域網(Arcster Universal One)から各種クラウドサービスに接続するインターコネクトサービス(Flexible InterConnect)を使ったセキュアな通信経路の確立 安価なストレージサービス(Wasabiオブジェクトストレージ)を使い、かつデータ上書き/改ざんを防止するオブジェクトロック機能を使ったランサムウェア対策の実施 クラウド側の制限に縛られず、オンプレミス環境と同等のサービスレベルを実現するバックアップツール(Arcserve UDP)の利用 上記をお客様自身やSIerの方々で組み上げられることを実際に検証して確認 検証を通じた確認 実際に検証環境を作ってみた Flexible InterConnect (FIC) を活用することにより、 Wasabiオブジェクトストレージ(Wasabi) やMicrosoft 365等様々なサービスと閉域で接続可能。 Arcserve UDP はSDPFクラウド/サーバーのサーバーインスタンス上に導入。 実際に検証を実施してみた ①閉域網を活用したMicrosoft 365データのバックアップとリストア Arcserve UDPを用いて、Microsoft 365の各サービス Microsoft Exchange Online (Exchange Online)、Microsoft SharePoint Online (SharePoint Online)、Microsoft OneDrive (OneDrive)、Microsoft Teams (Teams)のバックアップデータを、 FIC経由でWasabiに保存、Microsoft 365やローカルストレージへリストアを行う検証をしました。 ②クラウドストレージのランサムウェア対策機能の活用 Wasabiに保存したバックアップに対して、Arcserve UDPの2次コピー(復旧ポイントのコピー) 機能を活用し、 Arcserve UDP 8.1からの新機能として選択可能となったオブジェクトロックが有効化されたWasabiを復旧ポイントのコピー先として指定することにより、 指定期間中、復旧ポイントのデータを安全に保持できるか検証しました。 確認後の具体的な気づきポイント 「①閉域網を活用したMicrosoft 365データのバックアップとリストア」では、Microsoft 365の仕様上、Teamsのリストアに関して少しテクニックが必要でした。 例えば、1対1のチャットやチャネル(グループ)のチャットを元の場所にリストアしたいとなった場合、リストアしてもTeams上にはリストアされませんでした。 確認する際は、Exchange Onlineからのリストアのため、Outlookにて確認する必要がありました。 そして、チャネル(グループ)のチャットに関してはチャネル(グループ)に関連づいているメールアドレスが特定のメールボックスを持たない仕様となります。 そのため、チャネル(グループ)のチャットをリストアして確認したい場合は、別の場所へのリストアでリストア先に個人のアカウントを指定し、そのアカウントのOutlookにて確認する必要がありました。 このように、Microsoft 365の仕様上、上記のような確認方法となるサービスもありました。 ですが、Microsoft 365の利用拡大が続いている今、クラウド側の障害や人為ミス等の不具合等でデータを損失した場合でもリストアできることが分かり、有効性が高いことを確認しました。 「②クラウドストレージのランサムウェア対策機能の活用」では、指定した期間中フル権限のユーザーでも上書き・削除等を不可能にする コンプライアンスモード と、 特定の権限を持つユーザーのみ上書き・削除等が可能な ガバナンスモード をそれぞれ確認しました。 利用用途に応じたモードの使い分けにより、被害を抑えるという対策としての有効性が高いことを確認しました。 注意点として、オブジェクトロックを有効化したWasabi上のデータを上書き・削除した場合、別バージョンとして元データが保持されていることを確認できますが、 Wasabiコンソール上から確認する際、バージョン表示モードをオンにしないと元ファイルが上書き・削除されているように見えるため注意が必要でした。 具体的な構成例や設定例の見える化 具体的な構成例や設定例、注意点等の知見についてはKnowledge Centerにて記載しておりますのでご確認ください。記載している情報は2021年12月時点の情報となります。 また、Arcserve社のサイトにて検証で利用した機能等に関する記事やマニュアルも確認できますのでご参考ください。 Knowledge Centerへの記載 Arcserve UDPによるMicrosoft 365のバックアップ＆リストアガイド Arcserve UDP によるMicrosoft 365 のバックアップ速度検証 オブジェクトロックに関する記事 最後に 今後もクラウドへのデータ保存やデータ利活用を気軽に活用できるきっかけを活動を通じて発信していきます。 「ここの記載がわかりにくい」等のご意見や、「SDPFでこんなことができないか」等の疑問がありましたら、以下メールアドレスに対してお気軽にコメント等ご連絡ください。 sdpf-testbed-02＠ntt.comにメールを送る ※お手数ですが＠を全角文字から半角文字に置き換えてください。 それでは、明日の記事もお楽しみに！

AWS Lake Formationでのデータレイク登録からデータアクセスまで この記事は NTTコミュニケーションズ Advent Calendar 2021 の16日目の記事です。 はじめに はじめまして！BS本部SS部の荒井です。データマネジメントに関するプリセールスを担当しています。 今回はアドベントカレンダー企画ということで、 AWS Lake Formation に関する記事を投稿をさせていただきます。 データレイクとAWS Lake Formation 近年データ分析の盛り上がりなどから、散逸している様々な形式のデータを一元管理できるレポジトリ、いわゆるデータレイクを導入するケースが増えてきています（参考： データレイクとは ）。 例えばシステムごとに保存されていた「会員データ」「購入履歴」「問合せ履歴」などのデータをデータレイクに集約することでシステム横断の顧客分析を手軽に行うことができ、利益率向上の施策を検討したり顧客離れの原因を理解することにつながります。 AWSではこのデータレイクを構築するための Lake Formation というサービスがあります。 Lake Formation ではデータカタログや権限管理などデータのマネジメントに関わる様々な機能を持っています。 今日はこの Lake Formation を用いて、以下の流れでデータレイク作成からデータカタログを介したデータアクセスまでの操作に関してお話ししたいと思います。 データレイクを作成する 保持しているファイルをデータレイクに保存する データレイクに保存したファイルのメタデータを自動取得しデータカタログに登録する データカタログを介してファイルの中身にアクセスする 権限周りの設定やフォルダ構成など、ところどころで注意点があるのでこちらも随時説明していけたらと思います。 全体図 全体のイメージは以下になります。 流れに沿うとポイントは以下の通りです。 Lake Formation は裏では Glue の機能をベースに作られているため、ここでも Glue の機能を使います。 データレイクを作成する　⇒　データレイクはAWSだと S3 になります。 保持しているファイルをデータレイクに保存する　⇒　今回は手動で実施します。 データレイクに保存したファイルのメタデータを自動取得しデータカタログに登録する　⇒　メタデータの自動取得は Glue の Crawler を使います。データカタログも Glue の機能です。 データカタログを介してファイルの中身にアクセスする　⇒　今回は手軽にSQLを叩いてアクセスできる Athena を使います。 データレイクを作成する データレイクとする S3 Bucket を作成して Lake Formation に登録します。 以降の作業はAWSのコンソールにログインして実行します。 まずは S3 Bucket を作成します。 S3 に移動 > バケットを作成 設定値で以下を入力（指定がないものはデフォルト） > バケットを作成 バケット名 : 任意の名称 次に作成した S3 Bucket を Lake Formation に登録します。 なお、登録時には IAM Role が必要となりますが通常は AWSServiceRoleForLakeFormationDataAccess というAWSが用意したものを使えば大丈夫です。 ただ、ユースケースによっては自分で作成する必要があります。詳しくは こちら を参照ください。 AWS Lake Formation に移動 初回だと Welcome to Lake Formation のダイアログが出るので、 Add myself > Get Started (データレイク管理者を自分に定義) Data lake locations > Register location 設定値で以下を入力（指定がないものはデフォルト） > Register location Amazon S3 path : 作成した S3 Bucket IAM Role : AWSServiceRoleForLakeFormationDataAccess or 自分で作成した IAM Role これでデータレイクの作成と登録は完了です！ 保持しているファイルをデータレイクに保存する 次に、ファイルをデータレイクに保存します。 本記事では手動で行いますが、 Lambda 等を使って自動化しても大丈夫です。 今回はサンプルデータとしてよく使われるタイタニック号乗客者データを使います。 こちら などからダウンロードしておきます。 S3 > データレイクの S3 Bucket を選択 フォルダの作成 から titanic という名称のフォルダを作成 作成した titanic フォルダにタイタニック号乗客者データ（ titanic.csv ）をアップロード 無事データレイクにデータを保存できました！ （補足） 今回のケースでは titanic フォルダを1つ作成するのみでしたが、より多くの種類のデータを保存する場合にはフォルダ構成は重要です。 この後で Crawler という機能を使ってデータカタログへ自動登録する際に、フォルダ構成に従って精査されたり各種名称が決められるためです。 以下にフォルダ構成の一例を示します。 例えば、サービスAの購買データ、アクセスデータ、会員データを保存する場合を考えます。 まず最初はサービスA用の大きくひとくくりのフォルダを作ります。 <データレイク用S3 Bucket> |- serviceA ←作成 次に、購買データ、アクセスデータ、会員データ用のフォルダ（ buy , access , member ）を作ります。 <データレイク用S3 Bucket> |- serviceA |- buy ←作成 |- access ←作成 |- member ←作成 購買データは年ごとの 2020.csv , 2021.csv というようなファイルだったとします。この場合は、作成した buy フォルダにそのままアップロードします。 <データレイク用S3 Bucket> |- serviceA |- buy | |- 2020.csv ←アップロード | |- 2021.csv ←アップロード |- access |- member アクセスデータは時間ごとの 2200.csv （22時のデータ）, 2300.csv （23時のデータ）というようなファイルで、日ごとのフォルダが必要だったとします。この場合は作成した access フォルダ下に日付のフォルダを作り、その中にアップロードします。 <データレイク用S3 Bucket> |- serviceA |- buy | |- 2020.csv | |- 2021.csv |- access | |- 20210101 ←作成 | | |- 2200.csv ←アップロード | | |- 2300.csv ←アップロード | |- 20210102 ←作成 | | |- 2200.csv ←アップロード | | |- 2300.csv ←アップロード |- member 最後に、会員データは member.csv という1つだけのファイルだったとします。この場合も作成した member フォルダにそのままアップロードします。注意点は、この場合も会員データ用のフォルダ（ member ）を作らないといけなく、 serviceA フォルダ配下にアップロードしてはいけない点です。 <データレイク用S3 Bucket> |- serviceA |- buy | |- 2020.csv | |- 2021.csv |- access | |- 20210101 | | |- 2200.csv | | |- 2300.csv | |- 20210102 | | |- 2200.csv | | |- 2300.csv |- member |- member.csv ←アップロード |- member.csv ←ここにアップロードするのはNG! 上記のようなフォルダ構成を取ると、この後の手順でデータカタログを自動作成した時に buy , access , member というテーブルが作成されます。※今回はこの例のようにはなりません。 データレイクに保存したファイルのメタデータを自動取得しデータカタログに登録する 次に、 Glue の Crawler という機能を用いてデータレイクに保存したファイルのメタデータを自動取得し、データカタログに登録します。 メタデータとはフォーマット（csvやparquetなど）や構造（csvのカラムなど）、保存場所などデータがどのようなものかを表す情報になります。 まず、メタデータを登録する先となるデータカタログのデータベースを作成する作業をします。 Lake Formation > Data catalog 下の Databases > Create database 以下を入力（指定がないものはデフォルト） > Create database Name：任意の名称 また、任意で LF-Tag をデータベースにアサインします。 LF-Tag は Lake Formation Tag の略で、 Lake Formation 内で権限管理などに使えるタグになります。 Lake Formation ではこちらを設定して権限管理することが推奨されています。（この後の手順を進めると以下のように LF-Tag が recommended されているのが確認できます。） ただし、どのような LF-Tag を定義しておくかの設計が事前に必要なのと、データレイク管理者のみが LF-Tag を作成できることは注意が必要です。（参考： LFタグの作成 ） Lake Formation > Permissions 下の LF-Tags > Add LF-Tag Key と Values を設定して Add LF-Tag ここでは LF-Tag の事前の設計が必要ですが、例えば以下のような Key , Values などが考えられます。 Key = env , Values = development, staging, production Key = service , Values = serviceA, serviceB Key = source , Values = titanic, iris 　※今回はこちらを設定します。 iris の方は使用しません。 Databases に戻り、作成したデータベースを選択 > Actions > Edit LF-Tags Assign new LF-Tag を押して、設定したい Key と Values （今回は Key = source , Values = titanic ）を選択して Save 次に、 Crawler で使用する IAMロール を作成し権限を付与します。 権限付与はいくつか必要になりますので少し長いですが、最後に補足で各手順がどのような用途のためなのかをまとめます。 IAM > ロール > ロールを作成 以下を入力（指定がないものはデフォルト） > 最後に ロールの作成 ユースケース： Glue を選択 アクセス権限： AWSGlueServiceRole ロール名：任意の名称 作成した IAMロール を選択 > +インラインポリシーの追加 JSON タブに切り替えて以下を入力して ポリシーの確認 > 名前 に任意の名称を入れて ポリシーの作成 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::<データレイクのS3バケット名>", "arn:aws:s3:::<データレイクのS3バケット名>/*" ] } ] } データベースへの権限付与を以下の手順で実施します。 Lake Formation に移動 > Permissions 下の Data lake permissions > Grant 以下を入力（指定がないものはデフォルト） > 最後に Grant IAM users and roles：上記で作成した IAMロール LF-Tags or catalog resources データベースに LF-Tag を設定した場合は Resources matched by LF-Tags (recommended) を選択 > Add LF-Tag でデータベースに設定した LF-Tag の Key , Values を選択（今回は Key = source , Values = titanic ） 設定していない場合は Named data catalog resources を選択 > Databases で作成したデータベースを選択 Database permissions： Database permissions の Super を選択 データレイク（ S3 Bucket ）への権限付与を以下の手順で実施します。 IAMロール にも手順 10 で S3 Bucket への権限を付与していますが、こちらの手順も必要です。 Permissions 下の Data locations > Grant 以下を入力（指定がないものはデフォルト） > 最後に Grant IAM users and roles：上記で作成した IAMロール Storage locations：データレイクの S3 Bucket を選択 （補足） 各手順で設定したアクセス権限は以下の用途です。 IAMロール への権限付与： データカタログを介さない S3 アクセスに必要　※今回だと Crawler がファイルのメタデータを取得するときに必要 データベースへの権限付与：データカタログのデータベースアクセスに必要　※今回だと Crawler がファイルのメタデータを登録するときに必要 データレイクへの権限付与： S3のデータに向いた データカタログを登録するときに必要　※今回だと Crawler がファイルのメタデータを登録するときに必要 ここまで長かったですが、準備が整ったので Glue の Crawler を作成し、実行します。 Glue に移動 > クローラ > クローラの追加 以下を入力（指定がないものはデフォルト） > 最後に 完了 クローラの名前：任意の名称 Crawler source type : Data stores データストアの選択： S3 インクルードパス：フォルダマークを押して、 データレイク保存 で作成した titanic フォルダ IAM ロールの選択： 既存のIAMロールを選択 IAMロール：上記で作成した IAMロール データベース：上記で作成したデータベース 作成した Crawler を選択 > クローラの実行 完了した後に テーブル へ移動すると、自動的に titanic テーブルが追加されていることを確認できます。これが titanic.csv のメタデータになります。 さらに中身を見てみるとデータの場所や、下にスクロールすると以下のようにカラムの情報が自動的に取得されるところも確認できます。 ここまででメタデータの自動取得とデータカタログへの登録は完了です！ データカタログを介してファイルの中身にアクセスする データへのアクセスができるか、 Athena で確認してみます。 Athena はサーバ不要でS3内のデータにクエリを投げられるサービスです。 クエリを投げる対象のファイルは Glue のデータカタログにメタデータが登録されている必要がありますが、ここまでの手順で登録が完了しているのですぐに使い始めることができます。 Athena へ移動 データベース に設定したデータベースを選択して、 テーブル に titanic テーブルが表示されることを確認 エディタで以下を入力して 実行 SELECT * FROM titanic limit 10; クエリの保存先に関するエラーが出たら、 こちら を参考にしてクエリの出力先のS3を別途作成・設定 実行 がうまくいくと以下のようにデータの中身が表示される Athena を使い、データカタログを用いたデータアクセスをすることが確認できました！ 特にDB等に保存しているわけではないファイルにクエリを投げられるのは便利で、S3に置いてあるファイルに対してちょっとした分析をしたいときなどに手軽に使えます。 今回は単純な SELECT * でしたが、複雑なクエリを投げて分析することも可能です。 終わりに 今回は、AWSの Lake Formation でのデータレイク登録からデータアクセスまでを試してみました。 ご紹介したのはあくまで一例で、 Lake Formation やそのベースとなっている Glue でできることはもっと多くのことがあるので、興味のある方は使い込んでみてください！ AWSを利用してデータレイクを構築するというユースケースは今後増えてくると思いますが、まだ調べてもサンプルケースが出てこない場合が多かったりします。 何か例を探している方がいましたら、この記事が参考になれば幸いです。 ご覧いただきありがとうございました！ それでは、明日の記事もお楽しみに！

はじめまして。データプラットフォームサービス部の橋本です。 今回は、11/20（土）に開催したTechWorkshop「プロのネットワークエンジニアと学ぶ！ISPネットワークのつくりかた」について紹介します。 TechWorkshopとは 各技術分野のプロフェッショナル社員がお届けする、当社の最先端技術を体感し、また身に付けることができるワークショップ形式のプログラムです。 ( 公式ページ より抜粋) 過去にはこのようなワークショップを開催しました。 ソフトウェア開発ハンズオン Kubernetesハンズオン CI/CDハンズオン サイバー攻撃対応ハンズオン ソフトウェアエンジニア座談会 どのワークショップも、公式ページの説明の通り、各分野を主な業務にしている社員が講師となり、かつ自分たちでイベントの企画・運営をしています。 今後もいくつか開催予定ですので、興味のある方は TechWorkshopのページ をウォッチしていただき *1 、ぜひ参加申込をお願いします。 「プロのネットワークエンジニアと学ぶ！ISPネットワークのつくりかた」とは? 本ワークショップ「プロのネットワークエンジニアと学ぶ！ISPネットワークのつくりかた」では、ISPネットワークで利用されているような機器やプロトコルを用いて、ハンズオン形式で実際にネットワークを自分の手で作っていただくといった内容となっています。 ネットワークについていざ勉強しようとしたとき、学校の講義に出たり、書籍を読んだけど実際に触れる機会がない！と思ったことはありませんか？ ネットワークの学習には、費用や環境などの制約により、「実際に手を動かしてネットワークをつくって身につけていく」ということが難しい側面があるのではないかと感じています。 我々はこのような課題に対し、ネットワークを勉強している学生のみなさんにも実際の機器に触れてネットワークをつくることができるような機会を提供することで、より多くの方々にネットワークに興味を持っていただきたいと考えています。 また、実際のネットワークに関連した業務につくNTT Comの社員と身近な距離でふれあい、ネットワークを基盤とした価値を提供するNTT Comの会社そのものにも興味をもっていただければいいなと思っています。 ワークショップは大きく分けて午前の講義と午後のハンズオンの2パートに分かれており、1日を通してISPネットワークのつくりかたを体験していただくことができます。 午前は、ハンズオン形式でのワークショップに取り組む前に、必要なネットワークの概念やプロトコル、運用にあたって考慮すべきことなどを学習します。 午後は、午前の講義で学習したプロトコルや考え方に基づき、実際にネットワーク機器の設定を自らの手で行います。 午前 座学・スライドを用いた講義 ネットワーク/インターネットの概要 ネットワーク設計の考え方．ルーティングとは何か？ 各種プロトコルの紹介(OSPF/BGP/etc...) ISPネットワークを取り巻く課題と技術(運用/DDoS/BGP Flowspec/etc...) 社員のお仕事紹介 午後 ハンズオン 進め方やゴールの説明。基本的なルータのコマンドなどの説明。 インタフェースのアドレス設定 ルーティング(OSPF/iBGP/eBGP/static)の設定 自分の作ったネットワークでインターネットに通信ができるか検証 エクストラステージ 障害を起こしてみよう ルータの設定自動化 ???(参加者だけのお楽しみ) 懇親会 それぞれのパートについて詳しくご紹介します。 (午前)座学・スライドを用いた講義 講義は、実際にISPネットワークの設計・運用に携わっているメンバーを含むNTT Comの社員が行い、現場で実際に用いられている知識やノウハウなどを直接お伝えします。 ルーティングの基礎から1つずつ説明していきます。ルーティングって何？という学生の方でも大丈夫です。すでに理解されている方も、もう一度振り返って再確認します。 講義の後半ではより高レベルな、現代的なネットワーク技術についても紹介します。 講義で気になる点や不明な点がある場合にはチャットを用いて社員がその場でお答えしていきます。 参加者の方々からは活発に質問が飛び交い、中には社員でも回答に悩むような非常に鋭い質問も見受けられました。 社員のお仕事紹介 今回は、お昼ごはんを食べる前に、社員が実際にどのような業務を行っているかを紹介するコーナーを設けてみました。 ネットワークに関する仕事として、多種多様な業務があります。 このハンズオンには、複数の異なる部署からさまざまな業務を経験してきた社員が参加しています。 異なる経験を持つ複数の社員から、業務の幅広さや、実際の現場では具体的にどういうことをやっているのかという現場の声を直接お伝えすることで、よりネットワークやそれにまつわる仕事に興味を持っていただくことができるといいなと考えています。 今回は下記の業務について紹介しました。 OCNのネットワークコントローラを作ってる話 *2 GIN(Global IP Network) US-NOCとトラフィック分析 IXやIPoE関連の業務について 業務についてもたくさん興味を持っていただけたようで、業務紹介をした社員に対して、業務をより深堀りするような質問を多数いただきました。 (午後)ハンズオン さて、お昼ごはんを食べて休憩をとったあとはこのワークショップのメインであるハンズオンに取り組みました。 ハンズオンでは、ミニISPを作るというお題に沿って実施していきます。ISPなので、実際のユーザ相当のネットワークからインターネットに到達できることを満たす必要があります。 耐障害性、運用性などといった様々な視点で考え、複数のプロトコルを用いてルーティングの設定をします。 このミニISP環境は、複数台のルータを仮想環境上に構築しており、5つのルータからなる環境が個人それぞれに割り当てられます。 1人1環境割り当てられているので、他の人と競合したりせず、割り当てられた環境の中で自由に設定を変えることができます。 ネットワーク機器は共同利用者がいる場合が多く、自分1人で占領して使うのが難しいケースがあると思いますが、このハンズオンではあなただけのISPであり、構築から運用、障害試験までを全て経験できます。 この環境を使って、1つずつルータに設定を自らの手で投入していきます。 ハンズオンは参加者数人と社員2名ごとのグループをつくり、step-by-stepで時間を区切って行っていきます。 わからないことがあったり、設定したのにうまく動かない！といったことがあれば同じグループの社員にいつでも質問できます。 社員も理解をより深めてもらうために積極的にサポートします。 1つのステップごとに社員が設定方法や確認方法を解説する時間を設けています。 設定がまったくわからない、設定したはずなのに思い通りに動かなかった、ということがあっても大丈夫です。 この解説で改めて理解を確認し、社員と一緒に設定しましょう。 このように少しずつ段階を踏んで自分のISPネットワークを作っていくと、最後にはお客様のネットワークからインターネットに到達できるようになります。 ある社員いわく、「ping通った時がうれしいからこの仕事はやめられない」だそうです。 これには多くの社員も共感していました。参加者の皆さんにもこの気持ちを感じていただけたなら嬉しく思います。 エクストラステージ ハンズオンで無事お客様にインターネットへの接続性を提供できた方々には、エクストラステージにチャレンジしてもらいました。 エクストラステージは、自分の作ったミニISPネットワーク上で、運用等も視野に入れたより実践的なシナリオを解いていく内容になっています。 詳しくは参加者だけの秘密にしようと思いますが、はじめの1つについて少しだけ紹介します。 それは「自分のISPを構成しているリンクのうち、あるリンクが切れた場合の動きを観察せよ」といった内容です。 ネットワークの設計では通常、あるリンクが切れたり、ノードが故障することを事前に想定した冗長設計をします。 今回はリンクが切れたときにダイナミックルーティングが想定通り動作し、適切なルーティングが行えるか、お客様への影響を小さくすることが出来たかといった観点で観察してもらいます。 ルーティングプロトコルをより詳細に理解してもらうことを狙っています。 経路の切り替わりを、トラフィック量の変化で観察してもらうと、より直感的に理解してもらえるのではないかと考え、今回はSNMPでトラフィック量を可視化するツールを提供してみました。 traceroute などのコマンドと併用して、意図したとおりに切り替わっていることを確認します。 ほかにはconfig設定の自動化などに取り組んでもらえる内容も用意し、実践的な取り組みにもチャレンジしていただきました。 ここまでで午後のハンズオンの内容は終了です。参加者の皆様は普段慣れないルータの設定、コマンド操作、複数台にわたる設定といった、非常に多くの作業をこなし、終わった頃には相当の疲れと達成感があったのではないかと思います。 しかし参加者からは、「もっと長くハンズオンをやりたかった」などの声もあり、想像を超える熱意を嬉しく思っています。今後こういった声にもお答えできるように改善を検討させていただきます！ ハンズオンのあとには休憩を挟んで、参加者と社員を含めて懇親会が行われました。お互いに疲れを癒やし、交流を深めていただける場となりました。 参加者の声 参加者の皆様からは、事後アンケートにて下記のようなコメントをいただきました！ やはり、「実際に手を動かしてつくる」といった部分が好評いただけているようです。 午前中に、わかりやすく丁寧な講義をしていただき、午後からはそれを手を動かして実践できたことで、ルーティングに対する理解が深まったと思う。 ハンズオンでは、BGPやOSPFの基本的な設定から、LPやコストといった実践的な設定に触れることができたので、とても良い経験になりました。 NW入門ではISPがどのようなことに気を付けて他ASとBGPでやり取りしているかよくわかった。 ISPネットワークのリアルな現場を感じられる体験だった。また様々な分野の社員の方々とお会いしNTT Comの事業の幅広さとネットワークだけでも細かな多様な専門性を持つ部分を感じることが出来た。 想像以上に内容の濃いイベントでした。ネットワークの知識は授業で受けた程度だったのでとても勉強になりました。 他の参加者の皆さんもすごく知識があって、これからもっと頑張らないといけないと再認識できました。 ネットワークの勉強をする際の「実際に手を動かして学習する」部分の障壁、座学や本による学習では学びにくい実践的な部分をたくさん吸収していただけたようです。社員としても嬉しい限りです。 また、学生同士でのコミュニケーションも活発に行われており、同年代の参加者同士で互いに切磋琢磨する種になったり、参加者自らの刺激になったようでした。今後も継続してネットワークの分野を盛り上げていっていただけると嬉しいですね！ まとめ この記事では、2021年11月20日に開催した、TechWorkshop「プロのネットワークエンジニアと学ぶ！ISPネットワークのつくりかた」について紹介しました。 ワークショップを通じて、よりネットワークに興味を持っていただけたり、よい刺激となっていたならば幸いです。 社員も学生の素直な疑問や鋭い質問に答えられるように邁進していきます。今後のイベントにもご期待ください。 さてこのTechWorkshopですが、来年1月頃にも同様の内容で開催予定なので、この記事を読んで興味を持った学生の方は、ぜひ参加申し込みをお願いします！ また、「プロのネットワークエンジニアと学ぶ！ISPネットワークのつくりかた」以外にも複数のトピックで開催を予定しています。 NTT Comのイベント紹介のページ から興味のあるトピックに申し込みをしてみてください。皆様のご参加をお待ちしております！ www.ntt.com *1 : NTT Com公式Twitter でもご案内します。 *2 : https://twitter.com/yoshiya_ito

この記事は NTTコミュニケーションズ Advent Calendar 2021 の11日目の記事です。 はじめに ヒューマンリソース部の岩瀬( @iwashi86 )です。普段は、全社の人材開発・組織開発を推進しており、業務の1つとして、"1on1" の全社展開をしております。 本記事では、その"1on1"の効果を高める具体的な技法を紹介いたします。アドベントカレンダーということで、ゆるめに書いてみます。 *1 NTT Com における1on1の目的とは？ 技法を説明する前に、1on1の目的について説明します。技法はあくまで目的達成に向けたHowでしかないためです。 1on1の目的とは何でしょうか？1on1それ自体には、複数の目的が挙げられます。代表的なところで言えば次のようなものでしょうか。 信頼関係の構築 離職率の低下 メンバー育成 目標達成へ向けた支援 etc... どれが正解というものではなく、会社の置かれたコンテキストによって何を目的とするかが変わります。 NTTコミュニケーションズでは、1on1を "メンバーと1対1で行う、メンバーの成長支援を目的としたコミュニケーション" と定義しています。すなわち "成長支援" を主目的として置いているということです。 *2 1on1の効果を高める3技法 この1on1の効果を高めるために、具体的にどのような行動をすれば良いのでしょうか？様々な書籍やセミナーで1on1は解説されていますが、ここでは特に筆者が有効であると考える技法を紹介します。 *3 前提として、マネジメント目線の技法になっています。 1. 観察 -> メモ 1on1でチームメンバーの成長を促すためには、メンバー自身に内省を促し経験学習サイクルを回す必要があります。経験学習サイクルを簡単に表現すると "経験を振り返り、概念化・抽象化し、次の場でTryする" がループする学習モデルのことです。 *4 経験学習サイクルの起点となるのは"経験"です。経験はもちろん、1on1でチームメンバーから聞きだす方法もありますが、おすすめは普段から徹底的にチームメンバーを観察する方法です。たとえば、次のような方法があります。 オンラインでの打ち合わせにおける発言や表情を見ておく(この際は、他の参加者のリアクションも見ておく) SlackやTeamsでの発言に目を通す Pull RequestのReviewコメントを読む 徹底的に観察をすると、「あ、これはすごい！」「うーん、この発言はどうだろう」など様々な気付きがあるはずです。この気付きを忘れないうちに、チームメンバーごとのドキュメントにメモしておきます。（メモしないとすぐに忘れます…） メモした内容は、次の1on1でフィードバックします。具体的には「一昨日のミーティングでの、XXという発言は素晴らしかったね。ミーティングのゴールに一気に近づいたと思います。」というように、その行動と起きた結果について伝えます。そして次の問いを投げかけます。 「あの発言は、どういう考えから生まれたのでしょうか？」 と、良かった要因を掘り起こしにいきます。経験学習サイクルでいう "振り返り -> 概念化・抽象化" をチームメンバー本人に自ら振り返ってもらうようにします。上手く抽象化できれば、次回以降に再現性を高められるようになります。次のTryにつながりやすくなるということです。 この際、上手く概念化・抽象化できることもあれば、そうでないこともあります。マネージャー側から次の問いを投げかけて助け舟を出すこともありますが、個人的には短くとも1分待つ方法をおすすめします。最終的には、自身で自然と内省できると良いので、思考の癖をつけてもらうためです。（この待っている時間は、永遠と感じられることがあります笑） 突然ですが、となりのトトロという映画をご存知でしょうか？劇中の1つのシーンで、登場人物・キャラクターであるサツキ・メイ・トトロらが小さな畑をぐるぐる回って、埋めてある種に向かって「のびろー」と体を上下に伸ばすシーンがあります。 *5 筆者個人のイメージでは、概念化を待つ時間はこれにそっくりでチームメンバの前で、上手く概念化の芽がでてこーい！」と心の中で、常に応援している感じです。 2. 問いの手数を増やしておく 1on1ではチームメンバーのレベルや置かれている状況に応じて、コーチング・ティーチング・カウンセリングなど複数の手法を組み合わせることになります。特にコーチングスタンスで接する場合は、チームメンバー自身のありたい姿や、抱えている課題を気づいてもらうように、複数の問いを投げかけます。この問いも無数にありますが、次のような例があるでしょう。 目標設定 1年後、どんな状態になったらうれしいですか？ ここをこのようにしたい、と思っていることはありますか？ (目標がない場合は) いままでの経験で、一番うれしかったことはなんですか？ 現状確認 いまどのような状況ですか？ 100点満点だと何点ぐらいでしょうか？ 目標に向けて、一番ブロッカーになっているのは何ですか？ 手段検討 課題に対してどのような手段が考えられますか？ 他にどのような方法がありますか？ このような方法もありえますか？ 次のアクション どの方法が最も良さそうでしょうか？(優先順位で1位はどれですか？) いつまでにできそうでしょうか？ 私が手伝えるものはありますか？ このような問いを、ぱっと思いつけるようにしておくと1on1の流れが非常にスムースになります。 *6 ダイアモンド社出版の書籍" 1兆ドルコーチ――シリコンバレーのレジェンド ビル・キャンベルの成功の教え "では、次のように記載されています。 ビルのリスニングは、たいてい山のような質問を伴った。ソクラテス式の対話だ。２０１６年の「ハーバード・ビジネス・レビュー」誌の論文によれば、こうした質問の姿勢は、すぐれた聞き手になるために欠かせないという。 山のような質問をするためには、経験豊富でない限り、事前に質問の引き出しを持っていた方が良いと筆者は考えています。では、どのようにして問いの手数を増やせば良いのだろうか、と思われるかもしれません。質問・問いに関する書籍が多く出版されていますので、2-3冊ほど手にとってメモしておくのが良いと筆者は考えています。 強いて1冊をあげるとすれば翔泳社から出版されている " 対人援助の現場で使える 質問する技術 便利帖 " がおすすめです。1on1特化の書籍ではありませんが、体系的に質問が整理されており、1on1へ応用可能なものばかりです。 3. マネージャー自身も内省する ここまで、チームメンバー自身の経験学習サイクルを回すことで、チームメンバーの成長支援を促す流れで説明してきました。もちろん、1on1はチームメンバーのための時間ではありますが、そこから成長するのはチームメンバーのみではありません。マネージャー自身も成長できます。 そこで、"1on1"という経験を起点として、次の内容を自分の中で振り返りします。 1on1で上手くいったこと、いかなかったことは何だろうか？ なぜ上手くいった、いかなかったのか？ どうすればもっと上手くできただろうか？ 優先順位の高い方法はどれだろうか？ と、まさにここまで紹介してきた2つの技法を自らに適用するわけです。さらに上位のマネージャが、経験から学びを引き出してくれる機会もあると思いますが、その機会を待たねばならないわけではありません。マネージャ自身も内省することで、常に成長することで、チームメンバとお互いに成長する関係が望ましいと、筆者は考えています。その意味で、1on1の最後にチームメンバーに対して「(1on1に限らず)もっとこうすればよくなる、ということはありますか？」と問いかけるのも有効だと考えています。 おわりに ここまで、1on1の3技法を紹介してきました。1つでも参考になる点があれば幸いです。 それでは、明日の記事もお楽しみに！ *1 : 技術ブログですが、1on1の"技法"ということでご勘弁を！ *2 : もちろん全ての1on1の目的を、成長支援に限定しているわけではありません。1on1を行うメンバーの置かれた状況によって、目的は変化します。 *3 : 会社の公式見解ではなく、筆者自身の考えが強く出ています。 *4 : 正確には Concrete Experience -> Reflective Observation -> Abstract Conceptualization -> Active Experimentation です。 *5 : BGMで、風の通り道が流れているシーン *6 : 筆者は、個人用のカンペを持っています。なお、コーチングを学んだ方ならピンとくるかもしれませんが、記事の質問例は GROWモデル に沿った流れです。

この記事は NTTコミュニケーションズ Advent Calendar 2021 の10日目の記事です。 はじめに こんにちは。イノベーションセンターテクノロジー部門の西野と申します。サイバー脅威インテリジェンス（CTI）のさらなる有効活用のため、この1年間サービス化に向けた技術開発を主導してきました。この経験を踏まえ、馴染みのない方にもわかりやすく企業とサイバー脅威インテリジェンスの実際についてお伝えしたいと思います。 サイバー脅威インテリジェンス（CTI）とは サイバー脅威インテリジェンス（CTI = Cyber Threat Intelligence）とは、「サイバー攻撃に関する情報を収集して整理・分析したもの（IOC等を含む）」を指します。会社や団体によって定義に幅はありますが、実用上はこの理解で問題ありません。 一般的に、サイバー脅威インテリジェンスは「サイバー攻撃の緩和や防御」を目的として利用されます。そのため実用上は、サイバー脅威インテリジェンスはIOCを含むことが極めて重要です。Indicators of compromise (IOC)とは、IP・ドメイン・URL・ファイルハッシュ等のサイバー攻撃にみられる直接的な痕跡を示す概念です。IOCが含まれることによって、セキュリティ製品との連携、他のサイバー攻撃と結びつけた分析、該当の検体解析等によるさらなる情報の収集が可能になります。 以降は、サイバー脅威インテリジェンスを「CTI」と表記します。また、CTIの分類にはStrategic/Tactical/Operationalと呼ばれる分類がありますが、本記事ではセキュリティ運用の現場で主に利用されるTactical/Operationalと呼ばれるCTIを対象にします。 CTIの利用目的 Bouwmanら(2020) 1 によって、CTIの利用目的に関する調査が行われました。14人の「CTIの専門家」へのインタビューをまとめたものが図1になります。 図1：CTIの利用目的 利用目的に関して、回答者が言及した割合を以下に示します。 ネットワーク上での検知 (93%) セキュリティ状況の把握 (64%) SOCの優先順位付け (50%) CISO等によるビジネス的な意思決定 (36%) 自分たちが保有しているCTIへの付加情報 (36%) ユーザーへの注意喚起 (29%) 脅威ハンティング (29%) システムの脆弱性管理や機能改修 (21%) 金融詐欺の低減 (14%) このインタビューの結果はCTIの主な利用目的（50%以上）が 「ネットワーク上での検知」「セキュリティ状況の把握」「SOCの優先順位付け」 であると示しています。ネットワーク上での検知やセキュリティ状況の把握にはIOCを利用するため、「CTIがIOCを含むべきだ」と主張する考えは実用的に妥当だとわかります。 企業におけるCTI活用の実際 先ほどの結果は「CTIの専門家」に対するインタビューである点に注意が必要です。実際、私たちが日本国内のいくつかのセキュリティ運用者に対してインタビューをした結果、「CTIに興味はあるが利用はしていない」「CTIを収集しているが上手く利用できていない」「CTIを上手く利用できているか自信がない」と話す言葉を耳にしました。 インタビューをした範囲では、CTIを上手く利用できている日本企業はあまり多くないようです。 また、利用している組織や研究者においても費用対効果の測定やCTIプロバイダーの選定など、さまざまな問題を抱えていることが判明しました。 今回の記事では、「サイバー脅威インテリジェンスの処方箋」として企業におけるCTI活用を CTIの性質 セキュリティ投資 これら2つの側面からみていきたいと思います。 CTIの性質 複数の文献 2   3 をまとめると、CTIで重視される性質は主に4つ（図2）あることが分かります。 意思決定の容易さ (Actionable) 速報性 (Timely) 正確性 (Accuracy) 消費者目線 (Audience-focused) Recorded Future社では「正確性」と「消費者目線」の性質をまとめて「Clear」と表現しています。 図2：良いCTIの特徴 これらの性質が優れているときCTIは「良いCTIである」といわれますが、この中には「客観的に評価できる性質（Timely, Accuracy）」と「利用者にしか評価できない性質(Actionable, Audience-focused)」の両方が含まれていることがわかります。 もし貴方が「CTIを収集しているが上手く利用できていない」と感じているのであれば、CTIを配布している団体や企業に「誰にどう使ってもらうことを想定しているのか？」と聞いてみることが大切です。期待した回答がもらえない場合でも、現状を伝えることが今後配布されるCTIの改善に繋がります。ActionableやAudience-focusedはCTIの利用を容易にする重要な性質ですが、その改善にはフィードバックが欠かせません。CTIの活用は「生産者と消費者が一体となって行う活動である」と改めて認識することが重要です。 TimelyやAccuracyの観点では、複数の情報ソースの比較や、マルウェア解析、パケット解析を用いた情報の裏付けが評価のために役立ちます。CTIの利用と評価は表裏一体の活動です。絶対に必要なスキルとまでは言えませんが、企業におけるCTI活用を考える担当者は 「OSINT」「マルウェア解析」「パケット解析」 に関するスキルの保有者を優先して採用するべきです。 セキュリティ投資 個人/組織におけるサイバーセキュリティのアクションや投資を議論するセキュリティモデルとしては、Lee(2015) 4 によって提唱された「The Sliding Scale of Cyber Security」（図3）があります。これを利用することで「どのカテゴリにおいてCTIへの投資が適切なのか」を前後のカテゴリと比較しながら判断できます。 図3：The Sliding Scale of Cyber Security このセキュリティモデルは連続する5つのカテゴリから構成されます。 Architecture　…　セキュリティを考慮した、システムの計画・構築・維持 Passive Defense　…　脅威に対抗するための自動化されたシステムをアーキテクチャに追加 Active Defense　…　アナリストによるネットワーク内部の能動的な分析を実施 Intelligence　…　インテリジェンスサイクルに基づく能動的なセキュリティオペレーションを実施 Offense　…　アクティブ防衛（hack-back）や法的例外行動の実施 このモデルにおいてセキュリティ投資は、投資カテゴリを左から右へスライドさせる戦略をとります。具体的には「まずアーキテクチャに投資して優れたセキュリティ基盤を作り、次にパッシブ・ディフェンスに投資してシステムを保護し、それでも防げないサイバー攻撃をアクティブ・ディフェンスへの投資で対処する」と道筋を描くことができます。 CTI上のIOCの自動投入なども考えられますが、CTIの利用は主に「Active Defense」以上のカテゴリを対象としたセキュリティ投資（図4）であるとLee(2015)は主張しています。つまり「Architecture」と「Passive Defense」に対して十分な投資が終わったあとでなければ、CTIの利用によるセキュリティ強化の実感は困難です。 CTIの利用を開始する一例として、EDR製品の導入やログ収集基盤の構築が終わった後のタイミングが考えられます。 図4：CTIの利用と組織のカテゴリ またセキュリティ投資では、タイミングだけではなく費用対効果も重要なポイントです。しかし、CTIは単純な利用率による費用対効果の測定ができません。 一例として「水の入った袋」を想像してください。丈夫な袋は水を安全に運べます。袋を破れにくくする工夫も重要です。また、袋が破れていないか確認する工程も必要でしょう。袋に穴が空けば応急処置も大事です。けれど、応急処置ばかりで対処された袋を喜んで持ち帰るお客様はいません。 CTIの利用にも同様のことが言えます。「The Sliding Scale of Cyber Security」のモデルにおいて、セキュリティ強化の大枠は「Architecture」「Passive Defense」への投資で決まりますが、これは検査や応急処置が不要だと主張するものではありません。何よりセキュリティ運用の入れ替えは袋の交換ほど簡単ではなく、サイバー攻撃の被害も袋に空いた穴ほどわかりやすいものとは限りません。 とはいえ、「The Sliding Scale of Cyber Security」で定義されるカテゴリの連続性は、CTIの投資において非常に不可解な状況をもたらします。セキュリティ強化の大枠が強固になればなるほど、収集するCTIが増えれば増えるほど「CTIがほとんど利用されていない状況」が起こりやすくなるからです。一般的なセキュリティ強化では、利用率が低ければ費用対効果が悪いとみなされます。しかし前述の理由により、CTIの利用率は費用対効果の測定に不適切な場合があります。 サイバーリスクベースでの評価など様々な方法で費用対効果の測定は試みられていますが、現在のところCTIの費用対効果の測定に関する業界の標準はありません。 費用対効果がわからなくてもCTIを使う理由 企業におけるCTI活用は費用対効果の不明瞭な状態が一般的です。しかし、それでもCTIが利用される大きな理由は「現実のサイバー攻撃から身を守るには、現実のサイバー攻撃をベースに防御を考えるしかない」からです。 「 MITRE ATT&CK 」と呼ばれるサイバー攻撃の戦術やテクニックの分類手法なども用いつつ、企業は「実際のサイバー脅威」の観点から、自社のセキュリティ対策を継続的に見直し続ける必要があります。 ただ、CTIの分野は理想論やフォーマットばかりが先行している部分も多く、 MISP の習熟や RAWデータからATT&CKへのマッピング など運用上はかなりの困難を伴います。また、CTIの共有やフィードバックの運用に関しても様々な課題が存在し、CTIの共有戦略は学術的にも未解決な問題が山積みの状況です。SOCの現場、リサーチャー、コンサルタントの間でもCTIに関する期待感や運用コストへの考え方は三者三様であり、企業におけるCTI活用はまだまだ過渡期にあることを実感した一年でした。 まとめ CTIは非常に不明瞭な概念で、ほとんど利用されないこともある上に費用対効果も良くわかっていません。しかし、現実のサイバー攻撃をベースにしたセキュリティ対策にはCTIの利用が不可欠です。CTIは主に「ネットワーク上での検知」「セキュリティ状況の把握」「SOCの優先順位付け」のために利用されます。また、CTIの活用は生産者と消費者の協力が重要で、4つの特徴を満たす「良いCTI」を配布してもらうには消費者からのフィードバックが不可欠です。CTIの利用・評価には高いスキルをもつセキュリティエンジニアの配置が重要です。CTIの利用を開始する適切なタイミングの一例はEDR製品の導入やログ収集基盤の構築が終わった後のタイミングで、システムの保護や優れたセキュリティ基盤がない状態でのCTI投資はあまり意味がありません。 企業におけるCTI活用では、ステークホルダーの間で最低限これら5点に関して合意が必要です。 「対処すべき実際の脅威」の決定にCTIを利用する 自身の環境へ「アクション」を起こすためにCTIを収集する 良いCTIの特徴を共有しフィードバックの仕組みを作る 企業がCTIへ投資する適切なタイミングを理解する CTIの費用対効果をCTIの利用率で測定しない おわりに CTIの利用を手放しで推奨することは正直できません。CTIは本来、収集と消費だけでなく生成と配布も含めた一連のサイクルを考える必要があります。しかし、想定されている理想的な運用プロセスは一般的なセキュリティ担当者には重すぎます。また現実のCTIは品質が低いものも多く、CTIの消費にはサニタイジングのプロセスが必ず必要になります。 ただ、それでもなおCTIの利用を各企業が検討する理由は 「実際のサイバー脅威を理解して対抗できる唯一の手段」 だからです。 そして何より、CTI利用者の共通点である「現実のサイバー攻撃を理解する能力とそのモチベーション」はセキュリティ対策に極めて有益な資質です。社内におけるCTI利用者の存在は、 セキュリティシアター とよばれる「なんちゃってセキュリティ」に対抗する強力な予防措置となるでしょう。 明日は、Iwaseさんの「1on1の効果を高める3つの技法」です。お楽しみに！ Xander Bouwman et al., 2020. A different cup of TI? The added value of commercial threat intelligence. USENIX Security Symposium 2020: 433-450 ↩ Scott J. Roberts and Rebekah Brown. 2017. Intelligence-Driven Incident Response: Outwitting the Adversary. O'Reilly Media. ↩ Christopher Ahlberg et al., 2020. The Security Intelligence Handbook Third Edition. CyberEdge Group, LLC ↩ Robert M. Lee. 2015. The Sliding Scale of Cyber Security. SANS Information Security White Papers. ↩

これは NTT Communications Advent Calendar 2021 1 9日目の記事です。 こんにちは、イノベーションセンター RedTeamプロジェクトの久保・山本です。 今回はSafe Mode Boot 2 という攻撃テクニックを私達がMITRE ATT&CKにContributionした話をします。 MITRE ATT&CK Contributionの経緯に先立ち、まずはContribution先であるMITRE ATT&CKを説明します。 MITRE ATT&CKとは MITRE ATT&CK 3 とは、攻撃者の行動を戦術や戦法から分類したナレッジベースです。これはセキュリティ界隈では代表的なフレームワークの1つであり、MITRE社により運営されています。MITRE社はCVE（共通脆弱性識別子） 4 を管理していることでも知られる米国の非営利組織です。 MITRE ATT&CKの利用シーン 私達RedTeamプロジェクトは、攻撃者視点でセキュリティ対策の有効性を評価する技術開発や、組織を横断した業務支援活動をしています。その中でMITRE ATT&CKを度々利用します。例えば、技術開発で各メンバーが取り組む小さなテーマ選定や成果を可視化する際に、先のMITRE ATT&CKのフレームワークを利用しています。また社内やお客様へサイバー攻撃演習を提供し、その評価結果を報告する際にもMITRE ATT&CKを利用します。 セキュリティ業界においてもMITRE ATT&CKはセキュリティ対策の評価のフレームワークとして広く利用されています。セキュリティ製品のアラートが指す攻撃テクニックにMITRE ATT&CKのテクニック番号が記載されることがあります。またMITRE ATT&CKを用いたセキュリティの評価サービスもあります。 Safe Mode Boot Safe Mode Bootとは WindowsにはPCに問題が発生したときに使用する診断用の起動モードとしてセーフモード 5 が用意されています。 セーフモードでは限られたドライバーやサービスを使用してWindowsを起動します。 問題が発生したPCをセーフモードで起動することで、トラブルシュートが可能となり、問題の原因の絞り込みや解決に役立ちます。 一方で、攻撃者はこのWindowsのセーフモードを悪用して、エンドポイントのセキュリティ機能を無効化できます。上述の通りセーフモードでは限られたドライバーとサービスでWindowsを起動するため、AV/EDRなどのエンドポイントセキュリティが起動しない場合があります。攻撃者はこの特性を利用してDefense Evasion 6 を実現しその後の攻撃シナリオを達成できるようになります。 手法を発見した経緯 とある案件にてTLPT 7 のシナリオを遂行するにあたって、Windows上のエンドポイントセキュリティを無効化する必要がありました。 先のMITREでいうところのImpair Defenses: Disable or Modify Tools 8 を達成する必要がありました。 これを実現する一般的な方法としては、以下の２つのアプローチがあります。 エンドポイントセキュリティのプロセス/サービスを止める エンドポイントサービスのサービスレジストリを削除/変更して無効化する しかし、どちらもエンドポイントセキュリティによって妨げられる、または検知されるという問題を抱えていました。例えばサービスレジストリを書き換えて無効化しようとすると検知される恐れがありました。 達成したいこととその手法は明確にあるものの、「エンドポイントセキュリティを無効化するためにはエンドポイントセキュリティを無効化する必要がある」という堂々巡りの状態に陥りました。 半ば諦めかけていたところセーフモードからBootしてAVのSymantec Endpoint Protection(SEP)をDisableする記事 9 を発見し、これを攻撃者視点で利用すれば今回の目的を達成できるのではないかと考えました。 実際に以下のロジックを構築し、目的としていたエンドポイントセキュリティの無効化に成功しました。 Impair Defenses: Safe Mode Boot 目的：Exploitによる攻撃/サービスレジストリの書き換えを検知させないため、一時的にエンドポイントセキュリティを無効化 手段：攻撃対象のPCをセーフモードからBootする Exploitation for Privilege Escalation 目的：サービスレジストリ書き換えのための管理者権限の取得 手段：Exploitによりローカルの権限昇格の脆弱性を突き、一般ユーザからSYSTEMに権限昇格する Impair Defenses: Disable or Modify Tools 目的：エンドポイントセキュリティの恒久的な無効化 手段：サービスレジストリを書き換えてエンドポイントセキュリティを無効化する MITRE ATT&CK Contribution Safe Mode Boot が当時のMITRE ATT&CKになかったため、私達の間でContributionの可能性が浮上しました。以下では、実際にContributionするまでの過程を共有します。 MITRE ATT&CK Contributeの条件 ATT&CKの記載 10 によると、新たなテクニックのContributeの条件は2つあるようです。 テクニックが現時点で公開されているMITRE ATT&CKにないこと テクニックが攻擊者により実際に利用されていること 前者、当時のATT&CKにSafe Mode Bootの記述がないことは既に確認していました。後者のSafe Mode Bootが攻撃者により利用された実例があるかを調査すると、実際にREvil 11 やSnatch 12 、MedusaLocker 13 などの複数のランサムウェアで実例があることを確認できました。 投稿から採用までのタイムライン 条件を満たしていることが確認できたので、約1日で内容を整理してMITRE ATT&CKへ投稿しました。約1ヶ月後に一度返信があったものの、その後約5ヶ月間は音信不通な状態が続きました。もし採用されるのならば、次のバージョンアップと考え、待ちました。そして2021年10月22日のバージョン10の公開と同時に、Safe Mode Bootの採用が明らかとなりました。 Contributionの困難性、希少性、そして価値 今回のContributionの困難性を客観的に示すものはないのですが、希少性はありそうです。Contributorは全世界で308名（内、企業名も含む）で、日本人は私達含めて10名です（MITRE ATT&CK v10公開時点） MITRE ATT&CKは先に触れたようにセキュリティ業界で広く活用されています。今回のSafe Mode BootがMITRE ATT&CKを通じて全世界で参照されることで、世の中のセキュリティ対策が少し高度化する。これがContributionの価値だと私達は考えています。 最後に 私達がTLPTで利用したSafe Mode Bootという手法がMITRE ATT&CK v10でTechinquesの１つとして採用されました。今回のATT&CKへのContributionを通じて世の中のセキュリティ高度化に少し貢献できたと思っています。今後、セキュリティ製品のアラートなどでSafe Mode Bootの表記が記載されることを期待しています。 明日もセキュリティ関係の内容をお送りいたします、お楽しみに。 https://adventar.org/calendars/6680 ↩ https://attack.mitre.org/techniques/T1562/009/ ↩ https://attack.mitre.org/ ↩ https://www.ipa.go.jp/security/vuln/CVE.html ↩ https://support.microsoft.com/en-us/windows/start-your-pc-in-safe-mode-in-windows-92c27cff-db89-8644-1ce4-b3e5e56fe234 ↩ https://attack.mitre.org/tactics/TA0005/ ↩ TLPT(Threat Led Penetration Test)とは、攻撃シナリオにもとづいて疑似的な攻撃をすることで、セキュリティ対策状況を評価する手法です。 ↩ https://attack.mitre.org/techniques/T1562/001/ ↩ https://www.alitajran.com/disable-symantec-endpoint-protection-sep/ ↩ https://attack.mitre.org/resources/contribute/ ↩ https://www.bleepingcomputer.com/news/security/revil-ransomware-has-a-new-windows-safe-mode-encryption-mode/ ↩ https://news.sophos.com/en-us/2019/12/09/snatch-ransomware-reboots-pcs-into-safe-mode-to-bypass-protection/ ↩ https://www.cybereason.com/blog/medusalocker-ransomware ↩

この記事は、 NTT Communications Advent Calendar 2021 7日目の記事です。 はじめに はじめまして！PS本部DPS部門の福島です。 コンテンツデリバリーネットワークというサービスのセールスエンジニアをやっています。 今回はアドベントカレンダー企画と言うことで、Microsoft Power AutomateとTeamsを使って確認事項や締め切り通知を自動化したお話をします。 エンジニアブログとしては、まだこういったRPA（Robotic Process Automation）のお話は未投稿でした。 そこで、コードいらずで誰でも実践しやすいMicrosoft Power Automateで作る RPA が初回記事としてピッタリと思って今回投稿しています。 Microsoft Power Automateとは Microsoft Power Automateは公式サイト( https://powerautomate.microsoft.com/ja-jp/ ) にあるように、確認のプロセスや反復作業などを自動化するためのツールになります。 各デスクトップ上で動作できる無料の Power Automate Desktop と従来のクラウド型サービスである Power Automate があり、前者は各クライアント端末上での自動化に、後者はチーム内のプロセス自動化に、それぞれ長けていると思います。 それぞれアプリケーションも用意されていて、今回説明するPower Automateはブラウザ上でも操作できます。 Desktop版と違い、O365の利用が必要だったり、有償だったりという点はあるのですが、担当全体を巻き込んだプロセスの効率化を実現できます。 やりたかったこと 今回の目的＝実現したいこととしては 「リストから締め切りの近い項目について、通知してくれるRPAの実現」 になります。 うちの担当では、検証機で導入しているツールのライセンスや、監視サービスなどを利用しています。 この利用料について社内で決裁を毎年取っていて、担当の週次定例で決裁期限の近いものがないか、みんなで確認をしています。 ただ、普段その決裁を対応している人がうっかり漏らすと、対応が遅れ、決裁期限を過ぎてしまうということになりかねません。 実際にはそういったうっかりはなかったものの、忘れていたせいで対応を開始したかった時期より遅れてしまうということは、時々起きていました。 そこで決裁について対応期限が近付いているものを、人で確認するのではなく、自動で通知してくれるようなRPAが組めないかと思い、手を出したのがPower Automateになります。 設計 流れの説明 作成に当たり、以下のような流れを想定しました。 　①エクセルの決裁リストを取り込む 　②取り込んだリストから期限の近づいているものを識別する 　③期限の近いものがあればTeamsで色んな人を巻き込んで通知する いくつか準備や段階は踏まなければいけませんが、結果的にこの流れで実現できました。 ①は定例で利用している既存のものがありましたので、そちらを流用することにしました。 ※画像はサンプルです。 ②はそのリストをPower Automateで取り込み、期限について何日前なのか確認する処理になります。 リストでは決裁の実際の期限と別に、その決裁の対応を開始すべき日程も入れてみました。 ③は期限確認した決裁について、近いものがあればTeamsで通知する処理です。 Teamsに投稿することでチームのみんなが見られるようにしています。 また、チームの複数名をメンションすることで、担当者が漏らしても周りの人が気づけるようにしてみました。 事前準備 実際に作成したときは、既に存在しているエクセルの決裁リストを利用しました。 今回はサンプルで用意した先ほどのエクセルを利用して、実際に作成しながら記事にしていきたいと思います。 まずは準備として、エクセルのリストをPower Automateが読み込める形にします。 目視で見やすいリストにするだけではだめで、エクセルの機能として「テーブル化」というものがあり、これを実行する必要があります。 テーブルにしたい範囲を選択して「挿入タブ」の「テーブル」を押すと、テーブルにできます。 これで準備完了です。 テーブルにしたセルを選択しているとき、「テーブルデザイン」というタブが現れるようになります。 後々使いやすいように、テーブルの名前を変えておいてもいいかもしれません。 Power Automateでのフロー作成 ここまでの準備が出来たら実際の設計に移ります。 Power Automateのメニュー画面で「作成」を選択すると、以下のようにフローを作成する画面になります。 今回作りたいのは定期的にリストを確認し、締め切りに近いものが無いか確認する仕組みなので、スケジュール済みクラウドフローで作成していきます。 今回のRPAは、最初の処理としては以下のようにしてみました。 定期実行してくれるトリガーが最初に入っていますので、このフローは設定した頻度で自動実行されるようになります。 その後、締め切り通知してほしいリストが入力されているエクセルファイルを読み込みます。 各処理の名称はわかりやすい形に変更できるのですが、後でどの機能かわかりにくくなるため、処理を挿入する際に表示される機能名は別途（機能名：～～）という形で併記しました。 その後の処理は以下のようになっています。 締切を確認するために現在時刻を「シリアル値」と呼ばれる形に変換しています。 また、この後計算で利用するために、変数の定義として「決裁開始日」「契約開始日」を準備し知恵ます。 コードの知識が不要、と言いつつ複雑な計算式は要求してしまうのですが・・・。 ここではざっくり、以下の計算式を使うと、現在時刻がPower Automate上で扱いやすい形になる、とだけ紹介しておきます。 「値」の入力欄をクリックしたあとに出てくる吹き出しメニューから、式のタブを選択することで入力できます。 div(sub(ticks(startOfDay(convertFromUtc(utcNow(), 'Tokyo Standard Time'))), ticks(startOfDay(convertFromUtc('1899-12-31T00:00:00Z','Tokyo Standard Time')))), 864000000000) Power Automateでは、エクセルから取得する日付を、シリアル値、と呼ばれる形式で管理します。 その対応をやりやすくするために、あらかじめ現在時刻のシリアル値を用意しています。 詳しいことが知りたい場合はGoogleなどで「Power Automate 現在時刻 シリアル値」と検索してみてください。 最後の「Teamsに投稿」の部分は省略表示になっていますが、ここまでがフローの全体像です。 最後のTeamsに投稿する処理については、以下のようにしています。 Apply to eachという、繰り返しの処理を行ってくれる機能を入れて、そこにエクセルから取得したデータ＝valueを設定することで、リスト内の各項目に対して繰り返しの処理を実行してくれるようにしています。 ここも全部説明したいのですが、長くなってしまうので割愛しながら書くと 　①リストにデータが入っていること＝空白でないことを確認し 　②現在確認している項目の、決裁開始日や契約開始日に応じて条件を設定し（条件、条件2、条件3） 　③合致した条件に応じたメッセージを投稿する という流れになっています。 ①と②の間に、念のため型判定の処理も入れています。 これはPower Automateにおいて、エクセルから取得される日付の形式が、通常はシリアル値なのですが、たまにMicrosoftが仕様変更して一時的にタイムスタンプ形式になっているということがあったためそのエラー対策になります。 条件、条件2、条件3 の中で実際にTeamsへメッセージが投稿されています。 やっていることは基本的に３つともすべて同じで、契約開始日や決裁開始日より何日前か、の日数ごとに条件を作成しています。 例として条件2の内部を紹介すると以下のようになっています。 条件2は、決裁期限＝契約開始まで15日を切ったもの、を通知してくれる処理になります。 ※ちなみに　条件 では、1か月前の通知、条件3 では、遡及警告、をそれぞれ担ってます。 決裁開始日が今日の日付を過ぎており、契約開始日まで15日を切っている、ただし契約開始日はまだ先である、という3段階の条件文になっています。 これに合致したときの処理が以下のようになっています。 Teamsの対応するチャネルにメッセージ文を投稿しています。 決裁件名や、いつまでに対応が必要か、などがわかるような投稿文にしてみました。 また <at> </at> で組織ID（主にメールアドレス）を囲うことで、Teamsで使っている「メンション」の機能を利用できます。 これを使って、決裁の担当者のメールアドレスをエクセルに記録しておけば、担当者にメンションで通知させることができます。 実際に投稿されている様子が上の画像の通りになります。 担当者にメンションしつつ、チャネルにも投稿することで担当のメンバーが対応されているか確認しやすくなっています。 作ったうえでの効果 実際に作ってみて担当として効果があったかですが、先にも書いた通り、そもそも対応忘れによる遡及まで発展したケースはこれまでありませんでした。 ただ、対応開始遅れは年に１，２件発生していました。それがこの仕組みを導入してからは発生しなくなっています。 また、人の手で個別に確認する手間もなくなったので、年1回の決裁対応後にリストを更新さえしておけばよく、確認稼働もある程度低減できています。 決裁開始期限、契約期限、という一見ややこしい2つの日付を用意したおかげで、決裁ごとに通知タイミングも柔軟に設計できるようになりました。 これをわざわざ用意した理由は 「各決裁ごとに、対応を始めたい期間に差異があるから」 になります。 例えば海外とのやり取りが発生するような決裁では、見積りのやり取りなど、準備だけで時間がかかります。 そういった対応まで加味して、決裁開始期限、を設定しておけば、決裁開始期限になったときの通知で「あ、そろそろあの会社にメール送っておかないと」というふうに気づきやすくなると思います。 うちの担当においては、この仕組みを導入することで、対応漏れの防止や稼働効率化に一定の効果があったと考えています。 おわりに 新型コロナが日本では落ち着いてきているとはいえ、世界的な感染状況を考えると、リモートワークはまだまだ続けていきたいという方や、そのように指示している企業も多いかもしれません。 リモートワークは通勤などのストレスが無く、自分で働く環境を設計しやすい反面、最大の欠点として「他のメンバーとのコミュニケーションレスに陥りやすい」ということが挙げられると思います。 コミュニケーションレスが原因となって引き起こされる事象は多々あるかと思いますが、今回挙げたような事務対応においても、担当者がちゃんとやっているか、確認しづらくなるということもあるのではないでしょうか。 そんなとき、Teamsなどで担当全体に通知してくれる仕組みがあれば、事務対応の取りこぼしも起こりにくくできます。 また、コロナの感染状況に関わらず、今後は自動化やRPAの活用がどんどん進んでいくことと思います。 今回紹介したのはそれほど大きく稼働を削減するような内容ではありませんが、それでも一定の効果は出せています。 こうした事務作業のところから徐々に自動化を進めて行ければと考えていますし、今回の記事が少しでも皆様のお役に立てれば幸いです。 明日の記事もお楽しみに！ 付録 ここからは今回使用した式の簡単な紹介等になりますので、読み飛ばしていただいても問題ありません。 また、あくまで簡易紹介ですので、詳細は別途Googleなどで調べてください。（社内の方は福島までご質問いただければ時間のある時に回答できるかもしれません） 型判定 最後のTeamsに投稿する処理の繰り返し文で、日付の型判定は以下の式で行いました。 タイムスタンプ：endsWith(string(items('Teamsに投稿（機能名：Apply_to_each）')?['契約開始日']), '.000Z') この式の動的部分は　 items('Teamsに投稿（機能名：Apply_to_each）')?['契約開始日']) 　になります。 これは「Teamsに投稿」と名付けた機能に設定された「value」から、リストの「契約開始日」を見る動的コンテンツになります。 「value」には一番最初に読み込んだエクセルのテーブルに入っているデータが格納されています。 この処理でエクセルから取得された契約開始日が、「000Z」で終わるタイムスタンプ形式になっていないか確認しており、この条件に合致すればタイムスタンプ形式で日付を取得してしまっています。 今のところ、タイムスタンプかシリアル値のいずれかが、Power Automateで利用されている日付表現方式なので、この式に合致しなければ高確率でシリアル値です。 シリアル値での処理を想定して作成されていますので、タイムスタンプで取得した場合は、シリアル値に以下の式で直します。 シリアル値への変換式：div(sub(ticks(items('Teamsに投稿（機能名：Apply_to_each）')?['契約開始日']), ticks(startOfDay(convertFromUtc('1899-12-31T00:00:00Z', 'Tokyo Standard Time')))), 864000000000) 動的コンテンツが入力できない時 動的なコンテンツ、では読み込んだリストの各項目を動的変数のような形で入力可能です。 しかし、場合によっては以下のようにコンテンツが出てきてくれないことがあります。 ちなみに動的コンテンツが出てくるときはこんな感じです。リストの項目が直接入力できるようになってます。 こういうときは、どこか別のところで該当の動的コンテンツや変数を入力していないか確認します。 入力していたら、該当のコンテンツをマウスオーバーしてみてください。 代替テキストとして、式の中身が出てくるはずです。 変数もこのようにどういう式を書けばそれが入力できるのかマウスオーバーすれば確認できます。 動的コンテンツが自動入力できない時や、動的コンテンツ・変数を利用した式を書きたい時には、マウスオーバーすることで、直接入力するための文字列を確認できますので試してみてください。

この記事は NTTコミュニケーションズ Advent Calendar 2021 5日目の記事です。 はじめに データプラットフォームサービス部の増田( @tomo_makes )です。 組織内に点在するデータを一つのプラットフォーム上で融合して利活用を加速する Smart Data Platform ラインナップの1つ、IoTプラットフォーム Things Cloud や、それを活用したソリューションのエンジニアリングマネージャをしています。 お客様企業のデジタルトランスフォーメーションに関する技術コンサルティングも一部行っています。 さて、タイトルの「グラフィックファシリテーション」を聞いて、どんなものを思い浮かべるでしょうか。 講演やパネルディスカッションなどを「魅せる」形で色鮮やかにまとめたものを想起されるかもしれません。しかし「魅せる」ほどのクオリティでなくとも、簡単な図解をカジュアルに描き・共有することは、リモートワーク下で伝えられる情報量を増やし生産性を上げます。 私はこの1年あまり、iPad・Apple Pencil・ Concepts (コンセプト) という無限キャンバス（縦横に描いただけ、描画領域を拡張できる）のドローイングアプリを組み合わせて使っています。手元のメモから始めて、ホワイトボードのようにビデオ会議で画面共有しながら描き、会議のファシリテーションや意識合わせに使うようになりました。 具体的には、以下のシーンで役に立っています。 ミーティング中のクイックな意識合わせに活用する 読書や仕事のメモで、自身の思考を深堀りしたり、共有することに活用する 複数の要素を含む検証・PoCやシステムトラブルを、探索的に解決する 新しい顧客や、新しいプロジェクトのミーティングで活用する チーム内のビジョンを合わせるために活用する ミーティング中のクイックな意識合わせ まず概念図を手描きし、すぐに見せられる手になじんだツールを持つことは、大きな効果を生みます。私の場合はそれがConceptsでした。 少し言葉では伝えづらいなという情報を、図解の力を借りて容易に伝えられます。逆に自分が文脈を理解できているか不安なら、自分の理解を図示し相手に見てもらえば、理解のずれをすぐ指摘してもらえます。 読書やドキュメント通読・共有時のメモ 特に技術書は、本を前後に行き来し、ある概念の実例をいくつか確認してはじめて理解できることが多くあります。目次よりさらに具体のキービジュアルを描き留めておくと、理解や思考の深堀りに役立ちます。こちらは及川卓也ほか著『 プロダクトマネジメントのすべて 』の部内輪読会で使ったメモです。 複数のステークホルダでのPoC要件の意識合わせ ステークホルダが3以上の場合、システム検証という具体的なプロジェクトであっても最初は空中戦になりがちです。それぞれの視点や詳細度で持ち寄られたドキュメントを、1つのキャンバス上に描き出すと、途端に議論が進みやすくなります。（一部マスクしています） 顧客やプロジェクトのミーティング 残念ながらこの場では具体例を出せませんが、ステークホルダ間で大仰な資料を作らず、メモでクイックに情報共有したり相談をする文化も醸成できます。それがプロジェクトの生産性を上げることにつながります。 業務で使っている中で「これどうやってるの」と聞かれたり、ツールを紹介すると愛用される方が多く、今後の紹介用に経験を棚卸ししてみました。読まれた方が、明日からの仕事にちょっと変化を持ち込む、周囲に紹介してみようか、と思うきっかけとなれば幸いです。 グラフィックファシリテーションの効果 (Aggregation - Reframing - Collaboration) 清水淳子著『 Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書 (2017) 』では、以下のステップと効果がまとめられています。ここでは「グラフィックレコーディング」という言葉が使われていますが、議論の「ファシリテーション」に使う「魅せる」だけでない議論の可視化についての理解が深まる本です。 (出典) 清水淳子著『 Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書 』 私自身の仕事に対応づけると、IoT・AI・それらを用いたデジタルトランスフォーメーション（IT活用によるビジネス変革）実現は、複数要素が相互に影響するシステムや定性的な事柄について、仮説を立て作用する・応答を観察する・全体像を徐々に明らかにする・最終的に最も効果が高いポイントを見出す・そこへ作用するアクションをするという探索的なプロセスです。ちょうど某RPGで、暗闇の中たいまつだけを頼りに限られた視野でダンジョンを歩き回る。通った場所を書きとめ徐々に地図を作る。それを頼りに出口や宝箱を探す、という感覚に近い気がします（例が古いですけど）。 特に顧客ヒアリング、プロジェクト初期は、予め準備されたテンプレートなどを埋めることのみで仕事が進むことはありません。そういった時にグラフィックファシリテーションを使います。 Aggregation 何を話すべきかがわかるようになる。話の全体像が見えることで、広い視野で必要な話をするようになる。 発散のフェーズです。経験上「事実や一次情報ベースで発散させきった（情報収集を幅広に行った）上で、そこへ考察を加え収束させること」が大事と感じます。そのため、お客様含む参加者から事実を集めるため、その場作りをし、まずファシリテータになります。そして全体像を知るために、適切に発散させ、すぐに関係しない事実も含め取り上げられているかに気を配ります。各参加者の声を拾い、ファシリテータがわからないものでも、一旦描いてみて、ニュアンスやプロットするべき場所があっているかを確認します。 Reframing 別の視点を発見して前向きになる。偏りを客観的に眺めることで、どういう方向に進めば目的地に着くか明確になる。 考察を加え収束させるフェーズです。一見バラバラに見えた内容を、ひとつのキャンバス上に配置することで、発見が始まります。RPGの比喩では、一旦歩き回ったダンジョンの地図を起こし全体像が見えると、「どうもこの（通路が通っていない不自然な）空間は怪しい。隠し扉や宝箱などがあるのでは。」などの嗅覚が働くことに似ています。 Collaboration 多様性として楽しめるようになる。お互いの考えや専門の違いを安心して共有し、積極的に協力ができる関係になる。 合意と記録、実行のフェーズです。ここまでがうまくいけば、すでに関係者で（真に）合意した実行内容が洗い出せています。あとは納得する分担を決め、実行することで、協力してゴールに近づきます。 リモートワーク下でこその効能 上記の本は、顔を合わせての会議シーンを想定しています。しかし私は、リモートワーク下ではさらに効果が高まるように感じています。 コミュニケーションの形態は、「時間」と「場所」という観点から整理すると、以下3種類が考えられます。 同じ時間、同じ場所 同じ時間、違う場所 違う時間、違う場所 リモートワークが進むと、単純に1つ目の「同じ時間、同じ場所」で起こるコミュニケーションが失われます。3つ目の「違う時間、違う場所」で使われてきた、「文章」や「時間をかけて作った図表」（パワーポイントなど）による伝達が増えます。それにはどうしても時間がかかり、カジュアルに交換できる「形」「位置」「図表」を使ったコミュニケーションは失われたままです。 2つ目の「同じ時間・違う場所」をうまく活用したいところです。「同じ時間、違う場所」でのコミュニケーションは、ビデオ会議でカメラをONにして表情など伝え、より「同じ時間、同じ場所」に近づけることがTipsのひとつとされます。手描きによるグラフィックファシリテーションは、「同じ時間、違う場所」なりに、リッチな視覚情報で会議参加者の目線を合わせ、発言を促進する効果もあります。 やってみよう 以下は、実際にコンセプトを用いて描いた導入ガイドです。 Conceptsの導入とそのTips 「 Concepts (コンセプト) 」を導入します。私自身はiPad・Apple Pencilとの組み合わせで使っていますが、Android版、Windows版もあるようです。まずは無料版で使用感を確認してみてください。アプリ自体はサブスクリプション課金がありますが、これは機能が豊富なデザイナーやアーティスト向けです。ビジネスユースでは無料版または買い切り版で十分でしょう。 使用方法は 公式のマニュアル や、オンライン上にいくつも存在するチュートリアル、ビデオ (一例として 【iPad】Concepts（コンセプト）アプリの紹介や使い方など | ENHANCE ) に譲ります。 以下に、便利だと感じる設定やTipsを列挙します。 設定 > ジェスチャーは以下の設定にする 2本指の「キャンバスの回転を有効にする」チェックを外す 長押しを「投げ輪」ツールに割り当てる 2本指タップを「元へ戻す」に割り当てる 最初は以下の設定で始める 倍率100%とし、グリッドを表示しておき文字を書く ブラシは「ペン 3pt」「ダイナミックペン 12pt」などを使う 描き込みが進んだら、ズームアウト、より太いペンを使うなどして、広いキャンバスを有効に使う 「投げ輪」ツールを使い、描いたものを移動したり、複製する 物理のホワイトボードと異なり、描く位置を間違えたな、と思ったらまとめて「移動」できる システム構成図などは、判断用に複数のパターンを描くときに「複製」が便利 Aggregation - Reframing - Collaborationで、適宜描き込む「レイヤ」「ブラシ」「色」を分ける 例えば、Aggregationには「ペン 3pt」を、Reframing - Collaborationには「ソフト鉛筆 10pt」をといった使い分けをする 「レイヤ」を分けておくと、その表示・非表示切り替えにより、ある時点まで議論を巻き戻したり、再度積み上げたりがやりやすくなる 描き方 Warm Up (Aggregationの準備) まず、 単位時間で共有される情報を最大にするための場作りが必要です。 マウンティングがなく、発言が許容されるポジティブな雰囲気を作りましょう。できれば冒頭に、アイスブレイクなどで全ての参加者が一度は発言した状態を作るとよいです。またファシリテータは、正直に知らないことは知らないと表明し聞き返すなど、謙虚な姿勢を崩さないようにします。描く人と場のファシリテータは同一人物でもよいし、分担することもできます。 Aggregation - 描いていく 再び、清水氏の書籍から引用します。グラフィックスといっても、おもむろに「絵」を描き始める必要はありません。箇条書きから始めて、必要な概念図を足していきます。エンジニアリングにおいては、システム構成図、データモデルなどを簡単に手描きで加えることもできます。 (出典) 清水淳子著『 Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書 』 描くもの (=議論の対象) の全体像が決まっている場合と、決まっていない場合があります。決まっていない場合は、描くことが周辺を発見することにつながります。 例えば、ある複雑な事象を解明するためにシステム構成図を描いた場合、そこに事実を書き込んでいくと、もともと着目した領域の外側に、真に議論したい内容があることがあります。構成図は「複製」を有効活用できます。 新規ビジネスの場合、ビジネスモデルキャンバスや、リーンキャンバス、バリュープロポジションキャンバスなどから始められますが、周辺に詳細を書き込みたい場合もあるでしょう。 慣れている方の場合、そのフェーズにおいて聞きたいことをちりばめていき、デジタルツールの強みを生かして、「複製」「移動」などで位置関係を整えながら、全体の地図を明らかにしていくこともできます。 課題に対応した図解の具体バリエーションや考え方は、以下の書籍が参考になります。 よりビジネス寄りのフレームワーク、抽象思考のトレーニング 平井孝志著『 本質思考 - ＭＩＴ式課題設定＆問題解決 』『 武器としての図で考える習慣 - 「抽象化思考」のレッスン 』 具体的な描き方のトレーニング 日高由美子著『 なんでも図解 - 絵心ゼロでもできる！爆速アウトプット術 』 久保田麻美著『 はじめてのグラフィックレコーディング 考えを図にする、会議を絵にする。 』 Reframing - まとめる 一定描き出している間に、位置関係などを修正していきます。事実に対して考察を加え、グルーピングし、それらの依存関係を矢印などを使い記述します。前述のTipsの通り、レイヤ分けをしておくと、後で切り替えられて便利です。 冒頭の『プロダクトマネジメントのすべて』に、以下のReframingレイヤを加えてみます。 するとこのようになります。一部バラバラに捉えられたもののつながり・構造が見えてきませんか？ Collaboration - 合意と記録、実行 終わったらすぐ、エクスポートメニューから、Slackその他のコミュニケーションチャンネルへ共有できます。カジュアルな意識合わせなどはこれを議事に代えられます。 ひとつ面白い点として、Conceptsはベクターグラフィックス (SVG) 形式でのエクスポートに対応しています。描いたオブジェクトは、ひとつひとつ時系列で記録されています。外部のソフトウェアを使うと、描いた順番に再生することなどもできます。 その他の方法 今回は「 Concepts (コンセプト) 」による手描きを中心に紹介しました。「絵やイラストは得意ではないので自分で手描きをするのはちょっと… 」という方は、 Miro などを使うと付箋やオブジェクトを配置・構成しながら議論を進められ、同様の効果が得られます。 また、Conceptsは共同編集には対応していません。付箋で良ければ Miro など、手描きでの共同編集を行いたい場合はGoogle Jamboard（ただし、無限キャンバスではない）などの活用が考えられます。 例えば、 NTT Communications Digital Showcase 2021 のDXセミナー『 現場主導で始める！映像やIoTを活用したスモールスタートで実現するDX (DX-2) 』では、もともとConceptsを使ったグラフィックファシリテーションから、Miroを用いてより多くのメンバが実施できる形態としたワークショップ例を紹介しています。 おわりに グラフィックファシリテーションや、紹介したツールが、明日からの仕事にちょっと変化を持ち込むきっかけとなれば嬉しいです。 明日の記事も、ぜひお楽しみにお待ちください！

この記事は、 NTT Communications Advent Calendar 2021 4日目の記事です。 こんにちは、イノベーションセンターでSREとして働いている昔農( @TAR_O_RIN )です。主にNTT Comのソフトウェアライフサイクルの改善への取り組みやアーキテクトに関わる仕事をしております。本日は サービスメッシュ を題材に，その中で用いられるEnvoyの活用パターンを手を動かして理解するお話をさせていただきます。 また，昨年までのアドベントカレンダー記事もご興味があればご覧ください！ 2020年 How do you like k3s ? - CoreDNSで作るお家DNS Cacheコンテナ 2019年 TektonでCI/CDパイプラインを手の内化しよう 2018年 DevOpsってこんな仕事！考え方とスキルセットのまとめ 2017年 DockerのnetworkをCalicoでBGP接続する tl;dr サービスメッシュは便利だけど，本当に素敵なのはそのデータプレーンを支える透過型プロキシだと思っています！ The network should be transparent to applications / ネットワークはアプリケーションにとって透過的であるべき 実践的に組み上げられたサービスメッシュを使うのも良いけれど，透過型プロキシの1つである Envoy を利用してその面白さを知ろう Double proxy with mTLS encryption というユースケースをインターネット越しで利用してみます サービスメッシュにおけるEnvoyの役割 サービスメッシュとは 今回の記事ではサービスメッシュ自体の説明を詳しくは実施しませんが，どんな問題を解決しようとしている仕組みなのか簡単にご紹介します。基本的には複数のマイクロサービスを用いて構築されたシステムにおいて，マイクロサービス間の通信をスマートにハンドリングするための概念及びそのソフトウェアのことです。 下記の図はサービスメッシュ実装の1つであるIstioのアーキテクチャ図です。ここで概念として理解しておきたいのは，サービスメッシュはマイクロサービスのトラフィックを転送する プロキシ(データプレーン) と，それらを管理する コントローラ(コントローラプレーン) に役割が分かれていることです。この概念が サービスメッシュ であり，その実装が Istio などの具体的な製品やOSSになります。 少し本題と外れますがネットワークの業界にある程度いると， データプレーン と コントローラプレーン を分離するという考え方はSDNの概念が生まれた頃からよく登場していたと記憶しています。私は学生時代にOpenFlowというSDNの1つを研究題材にしていたのですが，初めてサービスメッシュを見た時はよく似たアーキテクチャだなと感じたことを覚えています。 引用元: https://istio.io/latest/docs/ops/deployment/architecture/ Envoyとは 本日の主役でございます。詳細なお話は 公式ページ に譲ることとして，下記の図で赤く示している Proxyの正体がEnvoy となります。図中の緑の矢印から見て取れるように，数多くの通信を扱うコンポーネントであることが分かるかと思います。特にProxy間の通信を通してService AとService Bを繋いでいるような構成はサービスメッシュの文脈では多く登場します。 本日，具体的に深堀りしていくのはこのプロキシ間で通信するパターンをコントローラなしで作り上げてみて，実際にプロキシを介して通信が行えるのか，プロキシ間はどのように接続されているのか，をおうちのネットワークを活用して動かしてみましょう。 引用元: https://istio.io/latest/docs/ops/deployment/architecture/ インターネット越しでDouble proxyをやってみる Double Proxyについて Double proxyとはサービスメッシュとしてよく出てくるEnvoyの利用パターンの1つで，下記のようにアプリケーション間でEnvoyをサイドカーとして組み込むことでマイクロサービス間や下記の図のようなアプリケーションとミドルウェアとの間を接続する構成です。この構成を作ることで FlaskApp はあたかも隣に PostgreSQL がいるように利用できます。 今回はサンプル例として1対1の接続例となりますが，実際にサービスメッシュとして利用する際はもっと複雑な構成になることが多いでしょう。ミドルウェアへの接続として応用している実例としてはGCPにおける Cloud SQL Auth proxy などが挙げられるでしょう。 mTLSによる暗号化と認証 もう1つ重要なポイントとしてプロキシ間の通信の暗号化と通信相手の認証があります。mTLSでは通信の暗号化にはTLSを用い，相互のプロキシ間の認証には証明書を用います。これにより今日のデモのようにインターネットを超えて通信を起こすような場合でも安全に通信を提供できます。mTLSについてもっと詳しく調べて見たい方は こちらのサイト が参考になるかと思います。 自宅とパブリッククラウドをEnvoyで接続してみよう それでは実際に動作を確認する構成を作ってみましょう！下記の図のようにクライアント，サーバの双方でDockerコンテナを用いてプロキシを立てます。また，プロキシ間の通信にはIPv6を利用することとしました。この記事を読んでいる皆さん向け簡単に流れをご紹介します。 環境 サーバ OS: Ubuntu 20.04.3 LTS Kernel Version: 5.4.0-90-generic Docker Server Version: 20.10.7 Envoy: v1.20.1 ※ 諸般の事情でネットワーク帯域幅が100Mbps制限。 クライアント OS: Ubuntu 18.04.3 LTS Kernel Version: 5.4.0-80-generic Docker Server Version: 20.10.7 Envoy: v1.20.1 構築の流れ Envoyから 素敵な公式手順書 があるので, 基本的にはそれに沿って進めますが一部詰まったところや気になったところを補足していきます。 mTLSに利用する証明書を準備する（これが少し面倒ですが，手順書に沿って進めれば大丈夫です） 認証局(certificate authority)を作成 する 接続に利用するドメイン向けの鍵を生成する 証明書署名要求(CSR)を生成する 証明書に署名する Envoy Configの準備については 公式リポジトリのサンプルコード を参考に編集していきます Client側の参考Envoy Configを下記に示します。 static_resources: listeners: - name: iperf_listener address: socket_address: address: 0.0.0.0 port_value: 12345 # プロキシで通信を受け付けるポート番号なので任意で良い filter_chains: - filters: - name: envoy.filters.network.tcp_proxy typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy stat_prefix: iperf_tcp cluster: iperf_cluster clusters: - name: iperf_cluster type: STRICT_DNS connect_timeout: 10s load_assignment: cluster_name: iperf_cluster endpoints: - lb_endpoints: - endpoint: address: socket_address: address: <ご自身で取得したサブドメイン>.i.open.ad.jp # IPv6のアドレスを直に書くとエラーになるようなのでFQDNを書く port_value: 3022 # 対向のEnvoyとの通信に利用するポートなので任意で良い transport_socket: name: envoy.transport_sockets.tls typed_config: "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext common_tls_context: tls_certificates: - certificate_chain: filename: certs/clientcert.pem # 証明書をEnvoyコンテナにマウントすることを忘れずに private_key: filename: certs/clientkey.pem # 秘密鍵をEnvoyコンテナにマウントすることを忘れずに validation_context: match_subject_alt_names: - exact: edge-proxy-server01.sekinet.example # ご自身で利用するサブジェクトALT名を入れてください trusted_ca: filename: certs/cacert.pem # CA CertsをEnvoyコンテナにマウントすることを忘れずに サーバ側の参考Envoy Configを下記に示します。 static_resources: listeners: - name: iperf_server_listener address: socket_address: address: <EnvoyでLISTENするアドレス> # ここはIPv6アドレスを入れても大丈夫 port_value: 3022　# 対向のEnvoyとの通信に利用するポートなので任意で良い listener_filters: - name: "envoy.filters.listener.tls_inspector" filter_chains: - filters: - name: envoy.filters.network.tcp_proxy typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy stat_prefix: iperf_tcp cluster: iperf3_server_for_client01_cluster transport_socket: name: envoy.transport_sockets.tls typed_config: "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext require_client_certificate: true common_tls_context: tls_certificates: - certificate_chain: filename: certs/servercert.pem　# 証明書をEnvoyコンテナにマウントすることを忘れずに private_key: filename: certs/serverkey.pem # 秘密鍵をEnvoyコンテナにマウントすることを忘れずに validation_context: match_subject_alt_names: - exact: edge-proxy-client01.sekinet.example # ご自身で利用するサブジェクトALT名を入れてください trusted_ca: filename: certs/cacert.pem　　　# CA CertsをEnvoyコンテナにマウントすることを忘れずに clusters: - name: iperf3_server_for_client01_cluster type: static connect_timeout: 10s load_assignment: cluster_name: iperf3_server_cluster endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 172.17.0.2 # ローカルで立ち上げたiperfのアドレス port_value: 5201 # ローカルで立ち上げたiperfのLISTENポート ※ IPv6アドレスのエンドポイントをFQDNで引けるようにするため OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト を利用してます。 Envoyプロキシの立ち上げ 色々な方式がありますが, 基本的には立ち上げ時にEnvoyConfigと証明書に関連するファイルを正しくEnvoyに与えることが出来れば良いです。私の場合は，一度公式のEnvoyコンテナをラップするコンテナをビルドしていますが，同じことができれば公式のEnvoyコンテナをそのまま利用しても構いません。 Client側 Scriptで起動時にEnvoyConfigや証明書関連のファイルをマウントしています。 #!/usr/bin/env bash docker run -d --restart unless-stopped \ --net=host \ --volume $(pwd)/envoy.yaml:/etc/envoy.yaml:ro \ --volume $(pwd)/envoy-certs/ca.crt:/certs/cacert.pem:ro \ --volume $(pwd)/envoy-certs/edge-proxy-client01.sekinet.tokyo.crt:/certs/clientcert.pem:ro \ --volume $(pwd)/envoy-certs/edge.sekinet.example.key:/certs/clientkey.pem:ro \ --name sekinet-edge-gateway-envoyproxy \ sekinet/edge-gateway-envoyproxy Server側 Scriptで起動時にEnvoyConfigや証明書関連のファイルをマウントしています。 #!/usr/bin/env bash docker run -d --restart unless-stopped \ --net=host \ --volume $(pwd)/envoy-backend.yaml:/etc/envoy.yaml:ro \ --volume $(pwd)/envoy-certs/ca.crt:/certs/cacert.pem:ro \ --volume $(pwd)/envoy-certs/edge-proxy-server01.sekinet.tokyo.crt:/certs/servercert.pem:ro \ --volume $(pwd)/envoy-certs/edge.sekinet.example.key:/certs/serverkey.pem:ro \ --name sekinet-edge-gateway-envoyproxy \ sekinet/edge-gateway-envoyproxy ※ 実際にはiper3もDockerで起動していますがここでは割愛します。 iperf3で計測してみる クライアント側でEnvoyプロキシに対してiperf3を走らせます。ポート番号はEnvoyの設定ファイルで指定している番号になるので，必ずしもiperf3 Server側と同じポートである必要はありません。下記の結果では，100Mbps上限の環境下で十分なスループットが出ていることが観測されました。また，少なくとも100Mbps程度ではEnvoyのDouble proxyはボトルネックにはならないという結果が得られました。 sekinet@sekinet:~/envoy-mtls$ iperf3 -c 127.0.0.1 -p 12345 Connecting to host 127.0.0.1, port 12345 [ 4] local 127.0.0.1 port 57018 connected to 127.0.0.1 port 12345 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 23.7 MBytes 198 Mbits/sec 14 4.56 MBytes [ 4] 1.00-2.00 sec 10.9 MBytes 91.2 Mbits/sec 6 4.56 MBytes [ 4] 2.00-3.00 sec 11.7 MBytes 98.5 Mbits/sec 7 4.56 MBytes [ 4] 3.00-4.00 sec 10.4 MBytes 87.5 Mbits/sec 10 4.56 MBytes [ 4] 4.00-5.00 sec 11.9 MBytes 99.5 Mbits/sec 11 4.56 MBytes [ 4] 5.00-6.00 sec 11.5 MBytes 96.4 Mbits/sec 8 4.56 MBytes [ 4] 6.00-7.00 sec 10.8 MBytes 90.6 Mbits/sec 10 4.56 MBytes [ 4] 7.00-8.00 sec 11.7 MBytes 98.5 Mbits/sec 11 4.56 MBytes [ 4] 8.00-9.00 sec 11.1 MBytes 92.7 Mbits/sec 9 4.56 MBytes [ 4] 9.00-10.00 sec 10.9 MBytes 91.7 Mbits/sec 7 4.56 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 125 MBytes 105 Mbits/sec 93 sender [ 4] 0.00-10.00 sec 112 MBytes 93.9 Mbits/sec receiver iperf Done. また，自宅の別のノードからクライアントプロキシに対して計測しても同様の結果が得られました。 [Mac]:~/ iperf3 -c 192.168.1.254 -p 12345 Connecting to host 192.168.1.254, port 12345 [ 5] local 192.168.1.69 port 64173 connected to 192.168.1.254 port 12345 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 16.5 MBytes 139 Mbits/sec [ 5] 1.00-2.00 sec 14.4 MBytes 121 Mbits/sec [ 5] 2.00-3.00 sec 11.4 MBytes 95.1 Mbits/sec [ 5] 3.00-4.00 sec 11.8 MBytes 99.3 Mbits/sec [ 5] 4.00-5.00 sec 11.3 MBytes 94.9 Mbits/sec [ 5] 5.00-6.00 sec 11.0 MBytes 92.1 Mbits/sec [ 5] 6.00-7.00 sec 11.2 MBytes 93.8 Mbits/sec [ 5] 7.00-8.00 sec 11.0 MBytes 91.9 Mbits/sec [ 5] 8.00-9.00 sec 11.9 MBytes 100 Mbits/sec [ 5] 9.00-10.00 sec 10.9 MBytes 91.5 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 121 MBytes 102 Mbits/sec sender [ 5] 0.00-10.01 sec 112 MBytes 93.8 Mbits/sec receiver まとめ 今回はサービスメッシュを切り口に透過型プロキシであるEnvoyを使ってインターネット越しでアプリケーション間を接続する構成を試しました。このような取り組みはサービスメッシュを最初に触るとコントローラによって隠蔽してくれているペインポイントが如実に現れます。例えば証明書の管理やEnvoyConfigの管理，動的なUpdateなどはその最たる例でしょう。この経験を通してコントローラ側に何が求められるか，どんな機能が追加されていくのかを追いかけると少し違った目線でサービスメッシュという技術を楽しめるのではないでしょうか。 また，アーキテクチャとしても従来は拠点間をIPSECやWireguardのようなトンネル型VPNで接続する構成が多かったですが，要件によっては透過型プロキシやサービスメッシュを広域に展開するようなユースケースも選択肢として現れるかもしれません。ぜひ皆さんもおうちネットワークにEnvoyを導入して拠点を超えたアプリケーションを接続してみてください。 それでは、明日の記事もお楽しみに！ 参考 https://www.redhat.com/ja/topics/microservices/what-is-a-service-mesh https://www.envoyproxy.io/docs/envoy/latest/ https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/double-proxy https://i.open.ad.jp/#hosts https://cloud.google.com/sql/docs/mysql/connect-admin-proxy

これは NTT Communications Advent Calendar 2021 3日目の記事です。 こんにちは、イノベーションセンターの松田 ( @take4mats ) です。 当社の Smart Data Platform (SDPF) のサービスラインナップの多くは、お客さまがサービスご利用に必要な操作を統一的に行うための Web UI に加え、同等の Web API を提供しています。 API 仕様は Knowledge Center にてサービスごとに一般公開されているのをご存知でしょうか？ (Knowledge Center で各サービス内の APIリファレンス のページをご覧ください。例えば こちらのリンク ) この一般公開されている API 仕様はサービス開発初期に作成され、開発期間にも重要な役割を果たしています。 本記事では、その中で私が携わったサービスから、 API 仕様ドリブンな開発事例を紹介をします。また、これを後押ししてくれた便利なツールもご紹介します。 OAS と他の REST API 仕様の記述形式 前置きとして OpenAPI Specification (OAS) について少しご紹介します。既に OAS をご存じの方は読み飛ばして下さい。 OAS は REST API を記述、生成、使用、及び視覚化するための機械可読性を持ったインターフェースファイルの仕様です。 Version 2 まで Swagger という名前で知られ、主に SmartBear 社のリードで開発されてきました。 Version 3 からは Linux Foundation 配下のオープンプロジェクトとして、 OpenAPI Initiative がリードしています。執筆時点での最新バージョンは v3.1.0 です。 REST API 仕様の記述形式に OAS を採用することで、以下のようなメリットを享受できます。 書きやすさ: YAML 形式 (あるいは後述のツールによる支援) 読みやすさ: YAML から読みやすい HTML を生成するツールが充実している 記述構文に制約: 仕様がブレにくく、人間同士のコミュニケーションコストも削減される 実装に近い: モックを生成できるツールの存在、 JSON Schema 形式の記述部分がそのままコードに流用できる、等 また、念のための程度の情報ですが、 REST API 仕様の記述形式には OAS 以外にいくつかあります。 PowerPoint や Word (!): 一般的なドキュメントを書く際に手を出しがちかも知れませんが、差分管理や親切すぎるオートコレクト（ダブルクオーテーションなど）、記述形式が自由すぎる点など多数の難点があります。これ以上のコメントは差し控えます。 Markdown などテキスト形式: バージョン管理はしやすくなりますが、記述形式を制限できないために、仕様がファジーになる点は変わりません。読みやすさも実装との距離感も課題ありです。 API Blueprint: OAS 以外にもこういった書きやすく、読みやすく、実行できる形式があります。概ね実現したいことを叶えてくれますが、認知度と周辺ツールの充実度で OAS が秀でていると考えています。 とは言っても「OAS の YAML 書くのつらいんだよね…」という方もいると思いますので、色々と楽できる使い方を書いていきます。 とある SDPF サービスでの開発プロセス事例 ここでは、「 API 仕様ドリブンで開発のプロセスを上手く回せたかな」というケースについて Good とし、そうではない Bad な (そしてありがちな) パターンと対比しながら、フェーズごとに紹介していきます。 最初に絵で比較しておくと、以下の図のとおりです。 開発要件策定 〜 API 仕様ラフ案策定 まず何よりも先に提供するべき機能、実現されるべきことを定義していきます。この時点で提供物をリソースとしてモデリングします（手法の詳細は割愛）。 次にこれに対応する形で API 仕様を作っていきますが、いきなり OAS 形式で書くのも大変です。 リソースのパスやメソッドを好きな形で書きながら、リクエスト・レスポンス例を JSON で書いて、イメージを膨らませます。 OAS 形式の仕様策定 いよいよ本格的な API 仕様記述です。ここでいかに品質高い仕様を作るかが全体の品質とリードタイムを左右すると言っても過言ではない、というのが私の考えです。 Bad でも早く実装に進みたいし、 YAML ばかりを書くのもシンドイ。全システム同じメンバーで兼任してるから曖昧な記述でも大丈夫。そんな誘惑に駆られることもあるかも知れません…。 Good 私個人の見解ですが、どんな人数規模でも、システム間に REST API があるなら仕様記述は緩めずにしっかりやっておきたいです。 仮にチームが小規模でも(自分1人だけだとしても)、人間はエラーをするもの、忘れるものだということを心に刻みます。 実際の執筆によく使うのが、 Stoplight Studio です。 詳細はツール紹介の中で触れますが、直感的なフォームを埋めていくだけで記述でき、一方で生成された YAML の直接編集も可能な頼れるエディタで、執筆作業を楽にしてくれます。 また、 lint 機能として Spectral も利用し、ヒューマンエラーに神経をすり減らすことなく作業を進められます。 そしてこの YAML はアプリケーションコードと同様に GitHub でバージョン管理します。 各システムの実装 いざ、各システムの実装です。 Bad API 仕様書の品質がイマイチだと、仕様の解釈がブレて実装誤りを生みます。 あるいは、仕様の確認のためのコミュニケーションコストが発生します。 なかなか手を動かすことに集中できなくなりますね…。 Good 仕様が上手に運用されていると、その API を提供するバックエンドシステムの実装にも直接的に活かすことが出来ます。 バックエンドの実装言語やフレームワークによっては、 Swagger Codegen などで OAS から自動生成されたコードを流用できるかも知れません。 最低でも、 API リクエストのバリデーション部分に JSON Schema として OAS の一部分を活用できるでしょう。 また、この API を叩いて連携する各システム (フロントエンドや他の連携するシステム) の実装にも、この OAS が役立ちます。 仮にこれらシステムの開発者が別のチーム (更には委託などで社外) だとしても、 OAS のファイルさえ渡せば人と人のコミュニケーションを最低限に抑えることが出来て、全員がより実装に専念できます。 単体試験・結合試験・総合試験 想定した API 仕様通りに作ったことを確認し、実際にシステム間をつないで想定通りに動くことを確認するフェーズですね。 Bad API 仕様の運用がイマイチだと、実装誤りに単体試験の段階で気づくことが出来ません。 いざシステム間を結合試験して上手く行かない、さあどっちが悪い！？みたいな戦いに時間を費やすことになるでしょう…。 Good 単体試験には Stoplight Prism が生成する API クライアント向けのモックサーバーが役立ちます。これによって API クライアント (連携システム) 側では、自身のリクエスト・レスポンスハンドリングを仕様に則って確認することが出来ます。 これによって単体試験の時点で各システムの API 仕様準拠のレベルを上げることが出来て、複数チームの時間を同時に拘束する必要のある結合試験・総合試験をスムーズに進められるようになります。 リリース 開発・試験が完了すると、デプロイして運用フェーズを迎えますが、外部に公開するAPIの場合はそのドキュメントの作成も書かせません。 Bad 公開用ドキュメントをリリース直前に慌てて執筆することになるかも知れません。そしてかなり時間を食うことになるでしょう。また、公開したドキュメントと実装の齟齬が発覚して、ドキュメントあるいは実装の修正なんてこともあるかもしれません…。 Good API 仕様を初期から OAS 形式で記述していると、一般公開のための執筆時間がほぼゼロに出来ます。 OAS の YAML から仕様ドキュメントをホスティングしてくれる有償・無償のサービスを利用したり、あるいはツールを使って YAML から HTML を自動生成し、自前のドキュメントサイトに組み込む事ができます。 今回のケースでは統合されたドキュメントサイトである Knowledge Center に組み込むため、 ReDoc を使った後者の方法を採用しました。 全体 一見面倒そうな OAS での運用ですが、ツールを上手く使うって効率化しつつ、乗り越えていくだけの価値があると考えています。 Bad パターンは色々と極端に思われる方もいるかも知れませんが、こういった幾多の手戻り・ムダを排除し、品質の向上と、開発時間の短縮に大きく貢献するはずです。 私自身もこの経験だけで完璧だとは思っていないので、細かい課題や別のプロジェクトに合わせた改善を重ねていきたいです。 ツール紹介 ここでは、開発プロセス事例で触れたツールを紹介していきます。 Stoplight や ReDoc はとても良いツールだと思うのですが、なかなか日本語の情報がなく、役に立てばという思いもあって記事にしました。 先に API Spec とシステムとツールの関係性を絵で紹介すると下図のようになります。 エディタ: Stoplight Studio 執筆用には2つのビューを持っていて、 Form view では直感的なフォームを埋めていくだけで記述していけるので、 OAS 形式の YAML の構文に自信がなくても記述していくことが出来ます。 裏では実際に OAS 形式の YAML をリアルタイムに生成していて、 Code view でそれを直接編集できます。 request/response のサンプルを複数書く方法のように、 Stoplight Studio を使って初めて理解できた記法もありました。 また、 body の定義の漏れや手間を圧倒的に解消してくれたのもありがたいところです。 ちなみに私の使い方ですが、 Code view の VS Code ライクなコードエディタ画面で直接ざっと書いてから、細かい部分 (request/response body の examples や components/schemas 配下の スキーマなど) の記述に Form view を使う方法が好みです。 編集画面は図のとおりです。左にファイルや API パス、中央が編集画面（下部が example response を定義する場面）、右に Spectral による lint の結果がリアルタイムで表示されています。 私は公式サイトから Mac 版 Desktop App をインストールして使用していますが、 Windows 版やブラウザ版もあります。 Linter: Stoplight Spectral VS Code エクステンションの openapi-lint などで事足りるのですが、 Stoplight 製品群に合わせる目的で Spectral を使うようにしています。 前述の通り、 Studio を使っていれば同梱されていて自動で使うことになります。 GitHub Actions に組み込む自動チェックにもこれを用いています。 NPM でインストール可能なので、 CLI でも javascript の中でも利用可能です。 # インストール npm install -g @stoplight/spectral-cli # OAS 標準ルールだけを使用 echo ' extends: "spectral:oas" ' > .spectral.yml # 検査対象のファイルを指定して実行 spectral lint ./path/to/spec.yaml 独自の拡張ルールも定義できるので、こだわりのある人には更に価値がありそうです。 モック: Stoplight Prism Prism はインストールも簡単で複数の役割をこなせる、とても手軽で便利なプロダクトです。 YAML ファイルを食わせて Docker コンテナとして稼働できるので、どこでも気軽に立ち上げることが出来ます。 Mock モード: クライアント開発用に API サーバーをモックしてくれる 正常リクエストへの応答: API 仕様に沿う形で header/body を自動生成してレスポンス 仕様非準拠のリクエストへの応答: 仕様のどこに準拠していないのか、 body で説明してくれる Validation Proxy モード: Prism には Validation Proxy というモードも有り、 API サーバーのレスポンスの正当性を検証することも可能です。 Mock と Validation Proxy 、2つのモードを図解するとこのようになります。 Mock を実際に動かしてみます。 Spec file は有名な PetStore を利用します。 まずはじめに GET の成功例です。 左が Mock 起動とモニタリングログの様子、右が API client としての HTTPie コマンドの様子です。 無事に 200 応答を受けています。 続いて、 POST に失敗した時の様子です。画面右で、 body に必要な name を抜いた状態で request し、 response 422 が返ってきています。 sl-violation というヘッダに仕様違反の内容が記載されています。 他にも、 Prefer header を付与してレスポンスを指定の example にしたり、 YAML に x-faker extension で追記することで Faker.js を使ったリアルな値を自動生成するなど、凝った使い方もできます。 ここまでの機能が欲しくなるかはわかりませんが、気になる方は 公式 doc をご参照下さい。 HTML の自動生成: ReDoc 作った API 仕様書は自社の Knowledge Center という Web サイトに統合する必要があり、その観点で ReDoc に行き着きました。 ReDoc は静的 HTML を生成してくれるためポータビリティがあり、かつ UI はリッチです。 リリースのサイクルとしては、コードをプッシュ&マージしたら自動生成・パブリッシュできるように GitOps を組んでいます。 利用方法は簡単で、以下のようなコマンドで Docker で起動できます（CLI ツールである redoc-cli を NPM でインストールして使うことも出来ます） docker run -p 8080:80 -e SPEC_URL =https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/examples/v3. 0 /petstore-expanded.yaml redocly/redoc これで localhost:8080 にアクセスするとご覧のとおりです。 Stoplight ファミリーはと言いますと、選定当時は Hosted Docs (Stoplight のサイトで公開される) しか提供されていませんでしたが、最近は Elements という名称で Web コンポーネントとして無償提供されているようです。 自前の Web App にも簡単に埋め込めるし Spec file の実体を Stoplight に預けるわけでもないため、これは良いかも知れません…。 おわりに OAS ドリブンな開発事例と、それに関わるツール紹介というちょっとニッチな？話をしました。 よりよく使ってもらえるプロダクトやアプリケーションを作ることが第一ですが、そのためのプロセスや道具も磨いていきたいものです。 また、今回の開発プロセスにはまだ改善点がありますし、ツール類も日々進化していきますので、しばらくすると自分の中でもベストプラクティスが変わっていきそうです。 この記事が参考になれば幸いですが、お読みいただいた皆さんもぜひ、ご自身のやり方を教えて下さい。 それでは、明日の記事もお楽しみに！

みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする Engineer Empowerment プロジェクトの @Mahito です。 この記事は、 NTT Communications Advent Calendar 2021 2日目の記事です。 今回は社内のソースコードを GitHub Enterprise にとりまとめる活動とそこで遭遇した課題と解決方法についてお話します。 背景 きっかけは「 NeWork のソースコードが見たい」という私の思いつきでした。 これを私が言い出した 2020 年当時、NTT Com ではソースコード管理の方法に決まりはなく、各プロジェクトの判断でバラバラにソースコードリポジトリが導入されていました。ちなみに、私が社内で見かけただけでもソースコードのホスティング先には以下のようなものがありました。 GitHub (Team plan) GitHub (Enterprise Cloud) GitHub (Enterprise Server) GitLab (Community Edition) この他にもあるかもしれませんが、基本的にサービスのソースコードはプロジェクト内に閉じられており、プロジェクト外の人がソースコードを見るためには各プロジェクトと交渉して閲覧するための権限を付与してもらわなければいけいないという状態でした。 このように、各プロジェクト内に閉じてソースコードを管理していることで、社内に情報が共有されず、同じようなライブラリやツールを作る重複開発が発生します。また、使っているライブラリのバグやセキュリティリスクの情報が共有されないなどのデメリットもありました。 このため、社内の開発者の情報共有やコラボレーションを促進するために（あわよくば NeWork のソースコードが見たい）、ソースコードリポジトリを共有することを目指してソースコードリポジトリの統合に向かって動き始めました。 統合に向けた検討と行動 統合に向けた検討でまず考えたのがソースコードリポジトリに「どのように運用するのか」と「何を使うのか」です。 どのように運用するかは以下の３つを考えました。 自分たちでソースコードリポジトリを社内にホスティングを行う 外部のホスティングサービスを利用する 上記２つのミックス 運用を考えた場合に現時点では自分たちで社内すべてのプロジェクトにソースコードホスティングサービスを提供できるだけの稼働を確保するのが難しい状況でした。そのため、2 の外部のホスティングサービスをメインにし、知的財産やお客様情報を扱うなど社内規定で外部のホスティングサービスに載せられないものは自分たちでホスティングするという 3 の案としました。 また運用に関するガイドラインについてもこの取組に協力してくれるエンジニアたちで話しながら案を策定しました。策定したガイドラインは GitHub 上に配置し、 Enterprise のメンバから見られる状態にして、問題や提案があれば Issue や Pull Request で改善をすることにしました。 ホスティングサービスに何を使うのかというところでは、GitHub と GitLab を検討し、社内の決裁から利用状況を確認したところ GitHub を利用しているプロジェクトが多かったので、移行のコストを減らすために GitHub としました。 幸いに、すでに GitHub Enterprise を契約しているプロジェクトも本取り組みに賛同してくれたこともあり、その契約をベースにとりまとめをはじめました。 社内調整 社内のソースコードリポジトリのとりまとめをはじめてしばらくした 2021 年 1 月末に大手企業のソースコードが GitHub 上に流出するという事件がありました。これをきっかけにセキュリティを担当する部から社内での GitHub 利用や運用についての調査が行われました。 幸いにすでに我々が社内の契約状況を把握していたことや運用ルールのベースを作っていたこともあり、セキュリティの担当と情報システムの担当と話し合い、全社のソースコードを我々の取り組みにとりまとめていく方向で合意ができました。 とりまとめへの課題 上記の話し合いの中でこの取組を行うためにセキュリティの担当から提示された課題は以下のようなものでした。 認証とユーザ管理 機密情報の取扱 監査ログ 運用方法 また、我々が取り組みの中で見つけた課題として以下のようなものもありました。 アウトサイドコラボレーターの管理 すでに GitHub にある Organization の移動と管理 以下ではこれらの課題にどのように対応したか、まだしていないかについてをお話をします。 認証とユーザ管理 セキュリティ担当からはセキュリティ対策としてログインに多要素認証を設定すること、会社を退職した社員のアカウントが残っていないことなどのユーザの管理を求められました。 管理すべき対象のユーザは社員と社員以外（協力会社等）の大きく2つに分けられ、それぞれについて対応を考えました。 社員 多要素認証は GitHub 側で ID / Password の認証に加え 2FA （二要素認証）を設定が可能ですが、今回はユーザ管理において後述するユーザプロビジョニング（SCIM）の機能を使いたいこともあり、情報システムの担当が管理する社員録と連携した Azure Active Directory（以下、AAD）を使った Single Sign-on（以下、SSO）を採用しました。 ユーザ管理には System for Cross-domain Identify Management (以下、SCIM)の機能を用いました。上記の社員録と連携した AAD と Security Group を用いて対象の Organization 上のユーザのプロビジョニング / デプロビジョニング を自動化することで、退職した社員は自動的にメンバから外れ、ソースコードリポジトリにアクセス出来なくなります。 社員以外 上記の社員以外の方についてはアウトサイドコラボレーターとしてリポジトリ単位に設定し、こちらは GitHub の 2FA を有効化してもらうことで多要素認証を設定してもらうことにしました。 一方、ユーザ管理が現在頭を悩ませるところとなっています。 GitHub のアウトサイドコラボレーターは Slack のゲストのように「2022 年 3 月 31 日まで有効」という有効期限の概念がなく、アウトサイドコラボレーターの削除は Organization の管理者が行わなければなりません。現在はガイドラインでアウトサイドコラボレーターの管理についての記載はしていますが、このあたりも自動化をしていきたいと考え調査し、下記のリンクのようなアウトサイドコラボレーターの管理を自動化する方法などを調べているところです。（まだ手はつけられていない今後の課題となっています） https://github.com/icub-tech-iit/outside-collaborators 機密情報の取り扱い 基本的にリポジトリに機密情報を置くことはないようにしているのですが、特許に関わるソースコードやお客様情報を含むソースコードも社内には存在しているため、セキュリティ担当からも取り扱いについて考えたほうが良いとのアドバイスを受け、ガイドラインへの記載や運用を整備しました。 クレデンシャルの扱い 社内の利用者向けガイドラインではクレデンシャルの管理には Key Management Service の利用を検討することを前提としています。もしリポジトリに置く場合は暗号化してからリポジトリに置き、暗号鍵はリポジトリ外で管理すること、Private リポジトリであろうと平文で置かないことを記載しています。また、ガイドラインだけでは防げないケースにも備え、今後は GitHub Advanced Security を利用して Secret Scanning の利用も行っていくつもりです。 知的財産、お客さま情報の扱い 先に述べたように、社内の規定により特許などの知的財産や、お客さま情報については社外に持ち出すことが出来ないため、GitHub Enterprise Server を社内に構築し対応していくことにしました。 監査ログ セキュリティ担当からは監査ログとしてある程度の期間保持し、インシデントがあった際に確認ができることを求められました。しかしながら、GitHub の監査ログは 90 日保存、Git 操作の監査ログは 7 日保存という期間のため、セキュリティ担当から求められる期間より短いものでした。 そこで監査ログを定期的に Export して保存する必要があるのですが、 @haeena がサクッと Google Cloud Platform の BigQuery に監査ログを保存する Cloud Function を書いて、必要に応じて監査ログを遡って検索できる状態にしてくれました。また、監査ログの保存状況は Slack Bot を通じて Slack へも通知されるようにも設定されています。（アイコンは大人の事情でカットしてあります） 運用 運用については情報システムの担当から問い合わせ対応やユーザ教育を心配する話がありました。 問い合わせ対応については、GitHub を利用する社内コミュニティを Slack 上で構築し、コミュニティベースで問い合わせ対応を行う仕組みを現在構築中です。また、Git / GitHub の使い方を学んでもらう話は、同じ NTT グループ内でも同様の課題感があると NTT グループ内のイベントでわかりました。そこで、NTT グループのエンジニア有志で Git / GitHub の勉強会を企画し、対応をはじめています。 既存 Organization の移動と管理 以前までは既存の Organization を Enterprise アカウント配下に移動させるためには GitHub 社に連絡をして移動をして貰う必要があり、依頼してから移動するまでの間にタイムラグがありました。 しかし、2021 年 9 月末に Enterprise の管理者が Organization を移動させる機能 がリリースされました。これにより、現在は Enterprise アカウントに参加するプロジェクトが持つ Organization は Enterprise の管理者と Organization の管理者の合意があれば移動させられるようになり統合までのタイムラグがなくなりました。一方で、現在この方法で移動した Organization は Enterprise アカウントの 管理者であっても Organization の操作ができないため、 Organization の管理者から管理者権限を付与してもらう必要がありますが、 ドキュメント を見ると近々 Enterprise の管理者が管理者になっていない Organization の管理者になる機能が提供されるようです。 とりまとめの効果 この取り組みを始めてよかったことが 3 つあります。 1. セキュリティの強化 認証、ユーザ管理、監査ログなど以前は各プロジェクトの自治に委ねバラバラだったところを、SSO 、SCIM、監査ログの保存などでレベルを合わせることが出来るようになりました。 2. 稼働の削減 他部の状況はわからないので弊部の話になるのですが、以前は各プロジェクトごとに契約の決裁していたものを私が取りまとめることで契約稼働の削減ができ、一部のメンバから感謝されています。 3. 社内の GitHub ユーザの情報共有やコラボレーションが行われるようになったこと 以前はどこのプロジェクトがソースコードリポジトリやホスティングに何を使っているのかわからなかったものが可視化されるようになりました。また、この取組について話し合う Slack チャンネルにいるユーザ間で情報共有や課題に対する議論が活発に行われるようになりました。そして、全社で共有する Organization を作ったことによりコラボレーションがはじまりつつあります。本ブログを管理するリポジトリは全社共有の Organization の上に作られており、そこで記事の管理や、レビュー、GitHub Actions によるデプロイが行われています。 おわりに 思いつきから始めた社内のソースコードリポジトリのとりまとめですが、現在 1000 近いアカウント契約数になっており、来年には 1400 を超えるアカウントの利用が見えています。課題はまだまだ山積みですが、この取組に賛同して協力をしてくれる人や応援してくれる人達がいるので引き続きとりまとめていきたいと思います。（ちなみに、 NeWork の初期のコードは別件で見ることが出来たので目的は達成できました） そんなわけで、現在の NTT Com におけるソースコードリポジトリのとりまとめについてでした。 この記事がどこかの社内ソースコードリポジトリのとりまとめの参考になれば幸いです。 明日もお楽しみに。

この記事は 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週間でネットワーク装置の検証の自動実行プログラムの作成ができるところまでスキルアップしてもらうことができました。これは櫻井さんの、物怖じせず疑問に思った点は何でも質問できるキャラクタによるものが大きいと感じました。今後ともぜひ続けていってほしいですね。 インターンシップを通じて開発部門において大きな割合を占める検証という業務を経験して、企業の中でエンジニアがどのように業務を行っているかイメージをもっていただくことができたのではないでしょうか。この経験を活かしてより一層就職活動や研究に励んでいただければ、トレーナーとしても嬉しい限りです。