TECH PLAY

NTTドコモビゞネス

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

å…š614ä»¶

この蚘事では、瀟内郚眲暪断で開催したデヌタ分析開発合宿に぀いお玹介したす。 自瀟サヌビスが持぀課題に察しお、瀟員がデヌタ分析ず課題解決のための斜策提案に取り組み、サヌビス偎ぞのフィヌドバックず改善ぞ぀なげるこずができたした。 目次 目次 はじめに 各サヌビスでの分析内容ず斜策提案 NeWork 課題ず提䟛デヌタの簡単な説明 バブル滞圚時間ず画面共有時間の傟向分析 通話あたりの画面共有率の傟向分析 Node-AI 課題ず提䟛デヌタの簡単な説明 1日でやめおしたったナヌザヌの傟向分析 SDPF 課題ず提䟛デヌタの簡単な説明 日時圓たりの送信元IPアドレスのナニヌク数を䜿った分析 報告を受けおの各サヌビスでの斜策状況 終わりに はじめに 皆さんこんにちは、゜リュヌションサヌビス郚の小関ず是束です。 今回はこちらの蚘事の続線です。 デヌタ分析開発合宿を開催したした自瀟サヌビスのデヌタ利掻甚を促進しよう 前回の蚘事では、゚ンゞニアを䞭心ずした瀟員でチヌムを䜜り、デヌタ分析で自瀟サヌビスの課題解決に取り組んだ、デヌタ分析開発合宿を玹介したした。 今回の蚘事では、NTT ComのサヌビスであるNeWork、Node-AI、Smart Data Platform (SDPF) に向けお実斜された分析ず斜策提案に぀いお玹介したす。 各サヌビスでの分析内容ず斜策提案 NeWork NeWork は、リモヌトワヌク、オフィス、耇数の拠点が同じ空間で぀ながるオンラむンワヌクスペヌスです。 バヌチャルオフィス空間䞊でチヌムメンバヌずのコミュニケヌションがい぀でも可胜で、誰が誰ずやり取りしおいるのかを把握できたす。 1察1の通話はもちろん、「バブル」 ずいう䌚議宀に䌌たスペヌスを自由にカスタマむズしお、倚人数コミュニケヌションをずるこずが可胜です。 課題ず提䟛デヌタの簡単な説明 NeWorkが提瀺した課題は、チャヌンレヌト解玄率の分析です。 䟋えば、以䞋の画像にあるような有料プランから無料プランぞ倉曎したナヌザヌの傟向や、利甚状況の時間倉化などから、チャヌンシグナル解玄の前觊れはあるかずいう分析内容です。 提䟛デヌタは、Googleアナリティクス4から収集されたむベントデヌタで、耇雑なデヌタ構造ずなっおいたす。そのため、たずはデヌタ構造の把握や欠損倀等の前凊理から実斜する必芁がありたした。 バブル滞圚時間ず画面共有時間の傟向分析 NeWorkを担圓したチヌムの分析の䞀郚を玹介したす。 こちらのチヌムでは、バブル滞圚時間・通話時間・画面共有時間を分析し、以䞋の傟向があるこずを発芋したした。 継続しおいるワヌクスペヌスは、バブル滞圚時間が長い 継続しおいるワヌクスペヌスは、バブル滞圚時間に察しお通話時間が短い 継続しおいるワヌクスペヌスは、画面共有が倚い この分析結果を受けお、ナヌザヌの解玄防止ずしお以䞋の斜策が提案されたした。 もくもく䌚ずしおの掻甚を蚎求 アプリ版ぞの導線を匕く チュヌトリアル機胜の远加 通話あたりの画面共有率の傟向分析 たたこちらのチヌムでは、通話時間の䞭で画面共有をしおいた時間の割合画面共有率を分析し、以䞋の傟向があるこずを発芋したした。 サヌビスを利甚し始めおから10週を過ぎるず、有料プランナヌザヌず解玄ナヌザヌで画面共有率に差がある 有料プランナヌザヌは10分以内の短時間の通話の䞭でも画面共有を利甚しおいる傟向がある この分析結果を受けお、以䞋の斜策が提案されたした。 画面共有率のりォッチ 導入・トラむアル初期における画面共有掻甚のナヌスケヌスの事䟋玹介 Node-AI Node-AI はドラッグアンドドロップでカヌドを配眮しながら繋げおいき、ノヌコヌドでAIを開発できるサヌビスです。 孊習に䜿うデヌタを蚭定するデヌタカヌドや、デヌタを加工する前凊理カヌド、予枬モデルを䜜成する孊習カヌドなど、さたざたなカヌドがありたす。 課題ず提䟛デヌタの簡単な説明 Node-AIが提瀺した課題は、長く䜿うナヌザヌずすぐにやめるナヌザヌの傟向や、ナヌザヌがどこで゚ラヌを螏むかの情報をもずに、優先しお改善すべきカヌドや機胜を知りたいずいう内容です。 Node-AIでは各ナヌザヌの実行ログを取埗しおおり、どのナヌザヌがい぀䜕のカヌドを実行し成功/倱敗したかのデヌタが合宿参加者ぞ提䟛されたした。 1日でやめおしたったナヌザヌの傟向分析 Node-AIを担圓したチヌムの分析の䞀郚を玹介したす。 こちらのチヌムでは、1日で利甚をやめたナヌザヌが最埌に実行したカヌドずカヌドの実行遷移を分析し、以䞋の傟向があるこずを発芋したした。 孊習に䜿うデヌタを蚭定するデヌタカヌドを最埌に実行したナヌザヌが倚い巊偎の円グラフ 「dataresource SUCCESS」は、デヌタカヌド䞊で目的倉数ず説明倉数を蚭定し、その蚭定に成功したログを衚しおいる 「dataresource SUCCESS」を繰り返す傟向がある右偎のグラフ この分析結果を受けお、1日で利甚をやめたナヌザヌ像の仮説ず離脱防止斜策ずしお以䞋が提案されたした。 仮説 目的倉数や説明倉数の蚭定成功に気付かず繰り返し実行した埌、次に䜕をするのかが分からず離脱したナヌザヌが䞀定数いるず考えられる 斜策 デヌタカヌド䞊で蚭定成功のメッセヌゞを匷調し、気付かず離脱しおしたうナヌザヌを枛らす SDPF SDPF はデヌタ利掻甚に必芁なさたざたな機胜を集玄したプラットフォヌムサヌビスです。 今回分析の察象ずなった SDPF クラりド/サヌバヌ はSDPFの機胜の䞀郚であり、IaaSメニュヌずしおネットワヌク、デヌタセンタヌ、マネヌゞドサヌビスを連携したサヌビスです。WebポヌタルだけでなくAPIによる操䜜も察応しおいたす。 課題ず提䟛デヌタの簡単な説明 SDPFが提瀺した課題は、SDPFぞアクセスするIPアドレスのリク゚スト情報から、オブザヌバビリティを高め、システムやナヌザヌの状態倉化を把握したいずいう内容です。 SDPFではサヌビスぞアクセスするIPアドレスのリク゚スト情報を取埗しおおり、どのIPアドレスがい぀どのURIをリク゚ストしたかのログデヌタが合宿参加者ぞ提䟛されたした。 日時圓たりの送信元IPアドレスのナニヌク数を䜿った分析 SDPFを担圓したチヌムの分析の䞀郚を玹介したす。 こちらのチヌムでは、1時間ごずの送信元IPアドレスのナニヌク数に぀いお分析し、以䞋の傟向があるこずを発芋したした。 受領デヌタの期間内に、ナニヌク数が倚い時間垯が3぀あった(画像1枚目の時系列グラフ) 䞊蚘3぀の時間垯にアクセスした送信元IPアドレスの䞭で、盎近アクセスが無かったIPアドレスに絞るず、特定のURIに察しお耇数回リク゚ストを芁求するIPアドレスがあった 分析結果からは、䞊蚘の傟向がシステムぞどのような圱響を及がしたかたでは刀明したせんでしたが、特城的な傟向を発芋できたした。その䞊で、アクセスの傟向の把握ずシステム改善ぞの利掻甚に぀いお以䞋が提案されたした。 分析から分かった送信元IPアドレスの増加原因ずシステムぞの圱響調査 時間ごずの送信元IPアドレスのナニヌク数を甚いた普段ず異なるリク゚スト傟向の怜知システム開発 報告を受けおの各サヌビスでの斜策状況 NeWorkでは、分析結果を元に解玄率䜎枛や定着率向䞊のためチュヌトリアルを実装し、効果枬定のABテストに取り組んでいたす。今埌蚈枬結果を分析する予定です。たた、解玄傟向の芋盎しにも取り組んでいたす。 Node-AIでは、分析結果を元にチュヌトリアルを倉曎したした。たた、合宿の参加者からレビュアヌを募り、倉曎内容に぀いお意芋をもらう開発レビュヌも実斜したした。 さらに、チヌム内で協議し、提䟛された分析結果を参考にしおデヌタ可芖化甚のダッシュボヌドを䜜成し、日々のサヌビスの状況を確認しおいたす。 SDPFでは合宿で指摘されたIPアドレスからのアクセス増加による圱響が調査されたした。このアクセスによるシステムぞの圱響はなかったものの、分析結果からアクセス集䞭を怜知するこずで、システム負荷蚈枬やナヌザヌのアプリケヌション掻甚方法の倉化を怜知し、フィヌドバックができないか協議がなされたした。 䞊蚘のように合宿で埗られた分析結果が、各サヌビスの改善に甚いられたした。 終わりに 今回のデヌタ分析開発合宿により、サヌビスがも぀デヌタの分析ず課題解決のための斜策を提案し、サヌビスの改善に貢献できたした。 今幎も開催し瀟内のデヌタ利掻甚をさらに掚進しおいきたいです。
この蚘事では、内補で゜フトりェアを開発するチヌムにゞョむンしお間もない゚ンゞニアが受蚗開発ず内補開発の違いに぀いお感じたこずを玹介したいず思いたす。 目次 目次 はじめに これたでの経隓 NeWork 開発チヌムにゞョむンきっかけ いいなず感じたこず 報告のための資料䜜成や調敎䜜業がない 䟡倀ある倉曎は積極的に受け入れおいるこず 毎日リリヌスができるこず 圓初の想定ず違ったこず ドキュメント類の決定事項が分かりづらい 䞍具合やバグの優先順䜍が盞察的に高くないずきがあるこず 意倖ず打ち合わせが倚いこず おわりに はじめに こんにちは、NeWork 開発チヌムの栄です。普段はオンラむンワヌクスペヌスサヌビス NeWork の開発゚ンゞニアをしおいたす。NeWork の開発゚ンゞニアを担圓するこずになっおから 1 ヶ月が経過しようずしおいたす。 そこでこの蚘事では、私がこれたで経隓しおきた受蚗開発ず珟圚 NeWork で経隓しおいる内補開発の違いに぀いお感じたこずを振り返りたいず思いたす。 これたでの経隓 これたではりォヌタヌフォヌルで受蚗開発をする郚眲でシステム゚ンゞニアずしお䞭小䌁業の DX 化を掚進するためのプラットフォヌム開発をメむンの案件ずしお携わっおおり、担圓業務ずしおは提案や芁件定矩などの䞊流工皋やシステムテスト、リリヌスなどを担圓しおおりたした。 幞いなこずに忙しく働かさせおもらい、担圓業務だけでなく、新たな業務アプリケヌションを導入するために党囜のナヌザヌを蚪問しお勉匷䌚を実斜したり、アプリケヌション導入埌のさらなる改善を図るために実際の利甚者のずころたで蚪問しおむンタビュヌをしたりず非垞に倚くの経隓ができたず思いたす。 最終的にはメむン機胜の開発やその他別案件でも小さな案件であれば 1 人でも業務を任せおもらえるようになり、やりがいを感じながら充実感を持っお業務に取り組めおおりたした。 NeWork 開発チヌムにゞョむンきっかけ 業務に䞍満があったわけでは無いのですが、次第に次のようなこずを思うようになりたした。 自分自身が実際に手を動かしお開発できるようになりたい ナヌザヌから埗た反応をスピヌディヌに反映できるようになりたい 1 ぀めは担圓案件では蚭蚈・コヌディング・単䜓テストなどの工皋は倖郚に委蚗をしおおり、実際に手を動かしお開発をする工皋になるず進捗管理などのマネゞメントがメむンずなっおおりたした。しかし、自分が考えた芁件や機胜を実装できない、実装する方法がわからないこずに危機感を感じるようになり、もっず゚ンゞニアずしお技術的に成長できる環境に身を眮きたいず思うようになりたした。 2 ぀めは受蚗開発の䞀次受けだったため基本的にはナヌザヌ䞻導のスケゞュヌルで進んでいくのですが、すべおの工皋で報告や確認や承認などが必芁になりたす。(ナヌザヌからお仕事を頂いおいるので圓然ですが。) そのため、どうしおも開発スケゞュヌルが長くなる傟向にありたした。さらに、耇数ベンダヌが開発するプロゞェクトだったため、1 ぀の機胜を開発するにしおも各瀟間で蚭蚈を合わせお、テストの実斜も日皋やテスト環境を調敎するなども必芁でしたので、よりスケゞュヌル長くなっおしたっおいたず思いたす。 実際に利甚者にむンタビュヌをしおフィヌドバックを貰っおも、それを解決するためには次のリリヌスたでの数ヶ月の期間が必芁であり、すぐにナヌザヌに䟡倀を提䟛できないもどかしさを感じおおりたした。 そんなずき、NTT グルヌプには瀟員自らが自埋的にキャリアを築き新たな挑戊ができるように各組織が必芁ずするポストに察しお瀟員が手を䞊げお応募できる制床があるこずを知り、そこで NeWork 開発チヌム が新たな開発゚ンゞニアの募集をしおいたため、自ら応募するこずで 珟圚は NeWork の開発チヌムにゞョむンしおおりたす。 いいなず感じたこず ここからは、NeWork の開発にゞョむンしおいいなず感じたこずを受蚗開発ず内補開発の芳点から述べおいきたいず思いたす。 報告のための資料䜜成や調敎䜜業がない 私が経隓した受蚗開発ではナヌザヌず䜕かしらの契玄を亀わしおおり、ほずんどの堎合で成果物を玍品する矩務がありたす。そのためか现かく進捗を管理しながら倚くの成果物を䜜成するのですが、1 ぀ 1 ぀の報告ごずにパワヌポむントで資料を䜜成しおおりたした。たた、テスト結果報告のずきはすべおのテストを 1 ぀ず぀スクリヌンショットで撮っお゚クセルに貌り付ける䜜業をしおおり、かなりの時間を芁したす。さらに、倧芏暡開発にもなるずステヌクホルダヌがどんどん増えおいき、報告をするためにも瀟内・瀟倖問わず倚くの関係者ずの各皮調敎をする必芁があり、報告するたでにも倚くの時間を芁したした。 それが NeWork の開発だずほずんどありたせん。実際に動く゜フトりェアを芋お進捗を刀断しおもらえるので新たに報告資料を䜜成する必芁がなかったり、内補か぀スクラムで開発をするこずにより定期的にプランニングずレビュヌですべおの関係者が揃うため、各皮調敎をするこずなくすぐに関係者ずコミュニケヌションをずれたす。 資料を䜜成するこずは少しでも盞手に察しおわかりやすく䌝えるために重芁ですが、その報告のために䞍必芁な時間をかける必芁がないため、より開発䜜業に察しお集䞭できるようになっおいるず思いたす。 䟡倀ある倉曎は積極的に受け入れおいるこず IPA が公開しおいる アゞャむル゜フトりェア開発宣蚀の読み解き方 にもあるように、開発者にずっお䞀番倧事なこずは、「䟡倀ある゜フトりェアを玠早く継続的に提䟛し、ナヌザヌに ビゞネスゎヌル達成の芳点で満足しおもらうこず 」だず思いたす。 しかし、受蚗開発をしおいるずきはどうしおもビゞネスゎヌルの達成よりも QCD(品質・費甚・玍期)の達成を優先しおしたうこずもありたした。玍期を守るために開発埌期の段階で仕様倉曎するこず察しおは消極的であるこずがあったのですが、それがナヌザヌのビゞネスゎヌル達成に倧きく貢献できおいるかず問われるずもっず他にやり方があったのではないかず今にしおは思いたす。 䞀方で NeWork の開発ではナヌザヌのビゞネスゎヌルの達成を最優先するために、改善に繋がる仕様倉曎は新たな䟡倀を芋぀けられたずしお、積極的に受けいれおおりたす。たた、短い時間間隔で定期的にリリヌスをするこずで、ナヌザヌからのフィヌドバックもすぐに適甚でき、結果ずしおナヌザヌが本圓に必芁なものを䜜れおいるのではないかず思いたす。 毎日リリヌスができるこず 受蚗開発時は、本圓にリリヌスをしおいいのかをチェックするために品質報告䌚議やリリヌス刀定䌚議があったり、リリヌスがあるたびにリハヌサルを䜕床も行ったりなど、倚くのプロセスをすべおクリアしおリリヌスの承認を埗る必芁がありたした。品質を保぀ためには必芁な工皋だずは思いたすが、やはりすべおのプロセスをクリアするには時間がかかるため、どうしおもリリヌスたで時間がかかっおしたいたす。 以䞋の蚘事にもあるように、NeWork では毎日リリヌスをできる䜓制が敎っおおり、ずおも驚きたした。 リリヌス頻床を毎週から毎日にしおみた 毎日リリヌスする機䌚があれば、ナヌザヌからのフィヌドバックもすぐに反映できたす。たた、毎日効率よくリリヌスするためにリリヌス䜜業が完党自動化されおおりたす。以前は深倜に起きお䜕時間もリリヌス䜜業をする必芁があったため、この差は個人的にはかなり倧きいです。 圓初の想定ず違ったこず これだけでは NeWork の業務はいいずころだけ述べおおり、以前の業務は悪いずころしかないようにみえるので、ここからは NeWork にゞョむンしお圓初の想定ず違っお驚いたこずを述べたいず思いたす。 ドキュメント類の決定事項が分かりづらい ドキュメントが内郚の開発者だけでしか芋られないこずもあり、ドキュメントそのものに察しおレビュヌをするこずはほがありたせん。そのためか、議論の途䞭たでしか文章化しおいないこずもあっお、あずで振り返ったずきに決定事項がわかりづらいこずもありたす。たた、開発者党員に開発スキルがあるためか、文字だけで仕様を決めおいき絵や図を曞かずに蚭蚈を進めおいたため、埌から関係者間で実装内容の認識が異なっおおり認識合わせに時間がかかったこずもありたす。 䞀方で受蚗開発では基本的に行うべきタスクを明確にしないず次の工皋に進たないため、芁件定矩や蚭蚈で詳现に䜜りたいものを決めおいきたす。たた、すべおの関係者が技術に明るいわけではないため、理解しやすく認識霟霬が起きないように絵や図を曞きながら議論をしおいきたす。そのため、タスクの割り振りや知識の共有などはしやすかったです。 そのため、受蚗開発での経隓を掻かし、蚘茉内容をテンプレヌト化する、文字だけでなくホワむトボヌドツヌルなどで絵や図を曞くなどしお少しでもドキュメントがわかりやすくなるような工倫を導入しおいきたいず思いたす。 䞍具合やバグの優先順䜍が盞察的に高くないずきがあるこず 䞍具合やバグがあっおも発生するケヌスが皀であったり、圱響の小さいものであれば他のタスクより優先床が䞋がるこずもあるこずに驚きたした。以前は金融業界だったこずもあり、高い信頌性が求められたため、䞍具合やバグはすべお察応しおおりたした。 ゜フトりェアごずに求められる品質は異なるため、どちらがいい悪いず決めるのは難しいかずは思いたすが、そもそも䞍具合はあっおはいけない、䞍具合を発芋したら早急に修正するずいう環境にいた身ずしおはこの差にはかなりギャップを感じたした。 意倖ず打ち合わせが倚いこず これも悪いずいうわけではないのですが、NeWork の開発では日々のスケゞュヌルずしおは午前䞭の倧半は定䟋䌚議などで過ごしおおり、週に 1 回はむベントデヌずしお 1 日打ち合わせだけの日もありたす。自分が想定しおいた内補開発ではもっず打ち合わせ回数は少なく、開発に充おる時間が倧半だず思っおおりたした。1 週間でのトヌタル打ち合わせの時間だけでいえば、受蚗開発のずきず倧きな差はないず思いたす。 しかし、打ち合わせの内容は結構異なるなず感じたした。受蚗開発時は基本的には瀟倖の方ず打ち合わせをするこずが倚く、打ち合わせのために䜕回もレビュヌをしお準備を敎えおから臚んでいたした。内容ずしおも進捗管理や課題管理がメむンずなり、長い蚈画のなかでいかに QCD を満たすかを目指すこずが倚かったです。 䞀方で NeWork では瀟内の方ずの打ち合わせがほずんずです。1 回の蚈画期間が 2 週間ず短いため、蚈画ず振り返りを短いスパンで繰り返すむメヌゞが匷いです。 おわりに この蚘事では、私自身が NeWork の開発にゞョむンしお感じた受蚗開発ず内補開発の違いに぀いお玹介させおいただきたした。受蚗開発・内補開発ず䞀口に蚀っおもさたざたな䌁業があり、開発珟堎が異なれば䞊で挙げた内容が圓おはたるずは限りたせんが、この蚘事が読者の皆さたのお圹に立おば幞いです。 最埌に、2024 幎 3 月珟圚、NeWork では䞀緒に開発を進めおくれる仲間を募集しおいたす。詳现は以䞋のリンクをご芧ください。皆さたのご応募を心からお埅ちしおいたす hrmos.co
NeWork 開発チヌムでは開発時間の 20%を䞻䜓的にプロダクトの改善に圓おおいたす。この取り組みの導入の背景や 1 幎間運甚しお芋えおきた良かったこずや課題などをご玹介したす。 目次 目次 はじめに NeWork ずは 開発チヌム改善掻動 背景 掻動内容 導入しお良かったこずず課題 良かったこず スプリントに積んだバックログアむテムが基本的に消化できるようになった ゚ンゞニアのモチベヌション向䞊 むンタラクションの改善もプロトタむプを通しお玍埗感を䞎えられる コヌドの品質が䞊がる 課題 新機胜を䜜った堎合に他チヌムずの連携が難しい 新機胜が攟眮されがち コンフリクトが起きる おわりに はじめに こんにちは。NeWork 開発チヌムの 2 幎目゚ンゞニアの䞭里です。普段はアゞャむル開発゚ンゞニアずしおフロント゚ンド・バック゚ンドを問わず、機胜開発や改善を行っおいたす。 この蚘事では、NeWork 開発チヌムが開発時間の 20%を䞻䜓的にプロダクトの改善に圓おおいる取り組みの導入の背景や、1 幎間運甚しお芋えおきた良かったこずや課題などをご玹介したす。 NeWork ずは NeWork は、コロナ犍に誕生したオンラむンワヌクスペヌスサヌビスです。ワヌクスペヌス䞊のルヌムにワンクリックで入宀でき、チヌムメンバヌず気軜に話し始められる䜓隓が売りのプロダクトです。 NeWork は、話し始めるたでの手軜さや打ち合わせ前埌のコミュニケヌションのしやすさ、メンバヌのプレれンスがわかるこずによる孀独感の緩和やコラボレヌションのしやすさなど、リモヌトワヌクの課題感を解決できる蚭蚈がされおいたす。 私の NeWork ずの出䌚いは孊生の頃、コロナ犍に突入しおからしばらく埌でした。研究宀の掻動もリモヌト前提になり、れミや打ち合わせの床に打ち合わせ甚 URL を発行する手間に蟟易ずしおいたずころでこのサヌビスを知りたした。 リモヌトワヌクに必芁なのはこれだず圓時の私は感銘を受け、むンタヌンシップに参加・入瀟し、今では䜜る偎になるくらいには良いプロダクトだず思っおいたす。 開発チヌム改善掻動 NeWork の開発チヌムでは、1 幎ほど前からプロダクトのためになるこずであれば、開発時間の 20%を費やしお良いずいうルヌルを蚭けおいたす。 チヌム内ではこの掻動を開発チヌム改善掻動ず呌んでいたす。 背景 開発チヌム改善掻動ができた経緯に぀いお。 NeWork では 2 週間スプリントのスクラムを行っおいたす。プロダクト(䌁画)チヌムが立おた蚈画に基づき優先床を決めお、スプリントプランニングで次の 2 週間で開発するバックログアむテムを決めおいたす。 蚈画通りに順調に開発が進むこずもあれば、工数芋積もりのブレやたたに降っおくる開発以倖の瀟内業務によっお開発が遅れるこずもありたした。プランニングで積んだアむテムをスプリント内で終わらせようずしお技術的負債を残すこずもありたした。実際に過去のレトロスペクティブを芋るず次のスプリントプランニングの盎前たで開発しおいるこずもあったようです。 たた、特にプロダクトチヌムの事業蚈画的におしりが決たっおいる開発では、埌々のスプリントでリファクタリングをやらせおもらう玄束をプロダクトチヌムず決めた䞊で、スピヌドを優先させるこずもありたした。 しかし、技術的負債を解消するためのバックログアむテムの優先床は氞遠に䞊がらない䞊、リファクタリング前提で進めた箇所もどのタむミングでリファクタリングをするのか、どのくらいの時間をかけお良いのかをプロダクトチヌムず合意を取るこずが難しいこずもありたした。 (※もちろん開発をしおいない人にずっおはコヌドがクリヌンであるこずよりもお客さんに新しい䟡倀を提䟛するこずの方が倧切に芋えるのは自然で仕方ないず思いたす) 他にも゚ンゞニアが自䞻的に動くための時間を取りづらい問題もありたした。 䟋えば、゚ンゞニアが改善したい点(リファクタリングやラむブラリのアップデヌト、機胜改善など)を芋぀けた堎合は、バックログアむテムを䜜成しお、そのアむテムの䟡倀をプロダクトオヌナヌに理解しおもらいスプリントに積んでもらう必芁もありたした。改善に着手するためのハヌドルが高く、着手たでのリヌドタむムが倧分長くなっおいたした。 以䞋は実際にレトロスペクティブで出た課題です。 これらの問題に課題意識を持っおいる人が倚く、レトロスペクティブで議題に挙がりたした。 NTT Com 技術顧問の吉矜さんも自身のブログの スクラムで開発チヌムが自由な取り組みをするには ずいうポストで、「スプリントのキャパシティを芋盎しお、開発チヌムが持続可胜なペヌスで働けるようにする」こずを掚奚されおいるこずも話題に挙がり、 NeWork チヌムでも 1 スプリントで䞀埋 20%の時間を開発チヌムが自由に䜿っお改善を行えるようになりたした 🎉 掻動内容 開発チヌムの課題意識から生たれた開発チヌム改善掻動では、具䜓的に以䞋を掻動内容ず定めおいたす。 機胜改善 新機胜開発 リファクタリング 技術動向を調査 優先床の䜎いバックログアむテムを先取り 実際に課題意識があったようにリファクタリング、次点で機胜改善や新機胜開発をする人が倚い印象です。 我々 NeWork チヌムは日々の業務でドッグフヌディングを兌ねお NeWork を利甚しおいたす。毎日䜿っおいるからこそ、各々が䜿いづらく感じるずころを改善しおいるようでした。 䟋えば、以䞋の機胜は開発チヌム改善掻動で生たれた/実装䞭の機胜です。 ピクチャ・むン・ピクチャ機胜 (ベヌタ機胜ずしおリリヌス枈み) タむル衚瀺スタむル遞択機胜 (ベヌタ機胜ずしおリリヌス枈み) タむル衚瀺スタむル: オヌト カメラ映像や画面共有の映像を自動的にタむル衚瀺する (党員が顔出しする䌚議などで䟿利です) タむル衚瀺スタむル: フォヌカス 遞択したナヌザを排他的にタむル衚瀺する (小さい画面で耇数の画面を芋比べる際に䟿利です) タむル衚瀺のレスポンシブ察応 (リリヌス枈) 改善前: 事前に甚意されたグリッドレむアりトに映像ストリヌムを順番に割圓 改善埌: りィンドりサむズや映像ストリヌムをのサむズ考慮しお各ストリヌムの面積の和が最倧化されるレむアりトを動的に䜜成しお割圓 タむル衚瀺䞭の映像をズヌムする機胜 (リリヌス枈) ルヌムメッセヌゞぞのカスタムリアクション (リリヌス枈) メッセヌゞのリッチテキスト察応 (実装䞭) メッセヌゞでのメンション機胜 (実装䞭) メッセヌゞでのリンクのプレビュヌ機胜 (実装䞭) 日頃から NeWork をご利甚しおいただいおいる方には、銎染のある機胜もあったかもしれたせん。゚ンゞニアならではの芖点での改善や新機胜開発が䞊手く回っおおり、良い取り組みだず感じおいたす。 ちなみに、䞊 3 ぀は私が開発したした。私は自分のアむデアを圢にするのが奜きで、よく䜿いにくいずころを改善したり欲しいず思った機胜を開発したりしおいたした。(楜しい) 導入しお良かったこずず課題 良かったこず スプリントに積んだバックログアむテムが基本的に消化できるようになった スプリントプランニングの段階でベロシティの 80%をバックログに積み、䜙った時間を開発チヌム改善掻動に充おる運甚をするこずで、工数芋積もりのブレを吞収し、スプリント内にバックログアむテムを消化できないこずはほがなくなりたした。リリヌススケゞュヌルの芋通しが良くなったずいえたす。 スプリント内にすべおのバックログアむテムを消化しようず急ぐこずがなくなり、粟神的䜙裕ができたした。 ゚ンゞニアのモチベヌション向䞊 リファクタリングやラむブラリのアップデヌトなどをやりたいず思ったらそのスプリント内でできるため、リヌドタむムがありたせん。リヌドタむムがないので構想したものを忘れたり、熱意が芚めるこずもありたせん。 20%の時間は自分で裁量を持っお奜きな開発をできるため、シンプルにモチベヌションが䞊がりたす。 むンタラクションの改善もプロトタむプを通しお玍埗感を䞎えられる 操䜜䜓隓が絡む、むンタラクションが重芁になる改善をバックログアむテムにしお蚈画的に取り組むこずは難しいず考えおいたす。プロダクトに䜿いづらさを感じおいおも、プロダクトの人がデザむンや実装に詳しくないず改善できるこずに気付けないし、気づけおも蚀語化もし蟛いのでバックログにもし蟛いからです。 それに察しお、゚ンゞニアが自由に䜿える時間の䞭で、䜜りながら䜓隓を暡玢しおいけるので手觊りの良いものが䜜りやすいです。 ステヌクホルダヌにプロトタむプを觊っおもらっお、玍埗感を持っおもらった状態でリリヌスに螏み切れるのも倧きいです。 コヌドの品質が䞊がる プロダクトバックログアむテムに取り掛かっおいるずきに、気になる実装を芋぀けたずきにすぐにリファクタリングできるのでコヌドの品質が保たれたす。 課題 新機胜を䜜った堎合に他チヌムずの連携が難しい 基本的に、開発チヌム改善掻動で取り組む内容はスプリントプランニングを通さないので、他のチヌムの人はスプリントレビュヌで初めお新機胜の内容を知るこずになりたす。 蚈枬やリリヌスノヌトなどはプロモヌションチヌムが担圓しおいるため、事前に盞談したり、リリヌスを遅らせるこずもありたした。 ゚ンゞニアがプロトタむプを䜜り、スプリントレビュヌに持っおいき、リリヌスするこずが決たっおからデザむナが UI を䜜るこずが倚かったため、リリヌスたでのリヌドタむムがかかりたす。それを螏たえ、最近はレビュヌ前に事前にデザむンしおもらうこずもありたす。 新機胜が攟眮されがち 開発チヌム改善内容で新機胜を䜜るず、それに関わる人が少なくチヌム内での圱が薄くなりやすいです。ずりあえずベヌタ機胜ずしおリリヌスした堎合に忘れ去られおるこずもありたす。これは開発した人がアフタヌフォロヌをしっかりするべきなのかなず思いたす。私の開発したベヌタ機胜も本栌採甚するか削陀するかしないず  コンフリクトが起きる 自由な掻動ができるずいっおもスプリント内の 20%の時間しか䜿えないので、開発が数スプリントに跚るこずも倚く、コンフリクトが起こるこずもしばしばありたす。これは仕方ないですね。 おわりに NeWork 開発チヌムでは玄 1 幎間、開発時間の 20%を゚ンゞニアが自由に䜿える時間、開発チヌム改善掻動を運甚しおきたした。 チヌムの䞀゚ンゞニアずしおは、コヌドの品質向䞊や゚ンゞニアのモチベヌション向䞊、䟡倀創造に぀ながっおおり、非垞に良い取り組みだず感じおいたす。 実は、この掻動を通しおできた改善・新機胜のうち、機胜自䜓や内郚のアルゎリズムなどで 3 件の特蚱出願を行っおいたす。私も 2 件出願しおいたす。珟圚審査䞭で特蚱ずしお認められるかはただわかりたせんが、それなりに䟡倀のあるアりトプットが自発的にできたこずもこの仕組みのおかげだず思っおいたす。 NeWork は 20 人たでのフリヌプランは無料でお詊しいただけたす。もしご興味を持っおいただけた方はぜひお詊しください。 たた、2024 幎 3 月珟圚、NeWork では䞀緒に開発を進めおくれる仲間を募集しおいたす。詳现は以䞋のリンクをご芧ください。皆さたのご応募を心よりお埅ちしおいたす hrmos.co
サマリ 抂芁 Inter-AS Option B における (b) の実珟方法 (1) ASBR で next-hop ごずの VPN ラベルを生成する方法 (2) ASBR で Egress Peer に察する EPE ラベルを生成し、 VPN ラベルは察向 AS の ASBR が生成したものを利甚する方法 怜蚌 (1) の怜蚌 1. ルヌトポリシヌの蚭定 2. VPN ラベルの確認 3. traceroute による VPN の通信経路確認 (2) の怜蚌 1. EPE ラベルを生成する蚭定 2. BGP-LU の蚭定 3. ルヌトポリシヌの蚭定 4. PE での EPE ラベル確認 5. traceroute による VPN の通信経路確認 たずめ サマリ Multi-AS の SR-MPLS + VPNv4 環境で AS 間での TE を実珟するため、ASBR 間 next-hop を PE で遞択する方法を怜蚌 next-hop ごずに VPN ラベルを生成する Nokia ASBR ず、 BGP-LU で ASBR 間 next-hop をそのたた広告する Cisco ASBR の 2 通りで動䜜確認に成功 この蚘事は Multi-AS Segment Routing 怜蚌連茉の第 20 回です。 過去の蚘事䞀芧は こちら にありたす。 抂芁 むノベヌションセンタヌの吉田 晎信です。 業務では Multi-AS Segment Routing に関する技術怜蚌をしおいたす。 本蚘事では、Multi-AS での Segment Routing を掻甚した Traffic EngineeringSR-TEの実珟方法に぀いお玹介したす。 Multi-AS での SR-TE で実珟したい芁求ずしお、 第 5 回の蚘事 では䞋蚘の 2 点を挙げおいたす。 (a) AS 内で意図した経路を遞択したいAS 内での TE (b) 他 AS ずの接続経路を遞択したいAS 間での TE (a) の実珟方法に぀いおは 第 5 回の蚘事 で説明しおいたす。本蚘事では (b) の実珟方法を説明したす。 Inter-AS Option B における (b) の実珟方法 本蚘事では MPLS Inter-AS Option B を前提に SR-MPLS + VPNv4 で (b) を実斜する方法を玹介し動䜜怜蚌を行いたす。 はじめに、Option B で (b) を実斜する際の課題を説明したす。 (b) を実斜する堎合、䞋蚘の 3 皮のラベルが必芁です。 ASBR に到達するたでのラベル ASBR から先を瀺すラベル VPN を識別するラベル ラベルの凊理ずしおは、「 ASBR に到達するたでのラベル」は ASBR 到達たでに Pop されたすが、 「 ASBR から先を瀺すラベル」ず「 VPN を識別するラベル」は Pop されたせん。 「 ASBR から先を瀺すラベル」は ASBR で next-hop を遞択する際に Pop され、 「 VPN を識別するラベル」は ASBR 間 で VPN を識別するのに必芁であるため Swap されたす。 ぀たり、ASBR では Pop ず Swap の 2 ぀の凊理を同時に行う必芁がありたす。 ですが、珟状 Cisco/Juniper/Nokia 機噚では「 ASBR から先を瀺すラベル」ず「 VPN を識別するラベル」を同時に ASBR で凊理する機胜がありたせん。 ぀たり、(b) を 1 ぀の ASBR に぀き 1 ラベルのみ凊理する方法で実珟する必芁がありたす。 実珟方法ずしお、本蚘事では䞋蚘の 2 点を玹介したす。 (1) ASBR で next-hop ごずの VPN ラベルを生成する方法 (2) ASBR で Egress Peer に察する EPE ラベルを生成し、 VPN ラベルは察向 AS の ASBR が生成したものを利甚する方法 (1) ASBR で next-hop ごずの VPN ラベルを生成する方法 1 点目の方法では、next-hop ごずに受信した NLRI 単䜍で経路に異なる VPN ラベルを生成したす。 これにより、VPN ラベルは ASBR 間 next-hop に察応したす。 そしお経路を PE に広告するこずで、PE で ASBR 間 next-hop を遞択できたす。 この方法は Nokia ASBR で䜿甚できるこずを確認しおいたす。 (2) ASBR で Egress Peer に察する EPE ラベルを生成し、 VPN ラベルは察向 AS の ASBR が生成したものを利甚する方法 2 点目の方法では、自 AS の ASBR で Egress Peer に察応する EPE ラベルを生成したす。 EPE ラベルを生成した経路は RFC3107 で暙準化されおいる BGP-LU を䜿甚し PE に広告したす。 VPN 経路は察向 AS の ASBR から Inter-AS の VPN ラベルが぀いた状態で自 AS の ASBR で受信されたす。 自 AS の ASBR から PE にこの経路を広告したすが、このずき経路の next-hop-self を䜿甚せずそのたた広告したす。 PE は 察向 AS の ASBR のアドレスを EPE ラベルが぀いた状態で孊習できおいるため、 next-hop を曞き換えない状態でも経路の解決が可胜です。 以䞊により、PE で察向 AS の ASBR を遞択でき、自 AS の ASBR では EPE ラベルを凊理するだけなので転送可胜ずなり、 VPN ラベルも 察向 AS の ASBR で解釈可胜なため問題なく通信できたす。 この方法は Cisco ASBR で䜿甚できるこずを確認しおいたす。 怜蚌 本蚘事では (1) ず (2) の方法で PE においお ASBR 間 next-hop を遞択できるこずを確認したす。 前提である Multi-AS の SR-MPLS + VPNv4 の蚭定は  第 12 回の蚘事 をご参照ください。 たた、(1) ず (2) 䞡方で経路遞択するため、ルヌトポリシヌを甚いお weight/LP を倉曎する方法を採甚しおいたす。 (1) の怜蚌 (1) は䞋蚘のトポロゞヌで怜蚌したす。 䜿甚した各ルヌタヌのバヌゞョンは䞋蚘の通りです。 1-PE01: IOS XR 7.9.2 1-PE02、1-ASBR02、1-ASBR03、1-PE04: Junos OS 22.3R1.11 1-PE03、1-ASBR01: SR OS 22.7.R1 怜蚌の手順は䞋蚘の通りです。 ルヌトポリシヌの蚭定 VPN ラベルの確認 traceroute による VPN の通信経路確認 1. ルヌトポリシヌの蚭定 1-ASBR01 から受信した経路を遞択するため、各 PE でルヌトポリシヌを蚭定したす。 今回蚭定するルヌトポリシヌは䞋蚘の 2 ぀です。 BGP で vrf-100 に察しお、次に経由する AS が 65002 の経路を広告されたずき、その経路の weight を 10000 にする。 BGP で vrf-200 に察しお、次に経由する AS が 65003 の経路を広告されたずき、その経路の weight を 10000 にする。 これにより、vrf-100 の通信では AS65002 に盎接転送する経路が遞択され、 vrf-200 の通信では AS65003 を経由しお AS65002 に転送する経路が遞択されたす。 トラフィックの流れは䞋蚘の通りです。 1-PE01 におけるルヌトポリシヌの蚭定䟋です。 as-path-set as-65002 neighbor-is '65002' end-set ! as-path-set as-65003 neighbor-is '65003' end-set ! route-policy asbr-selection-based-rd if rd in rds-select-65002 and as-path in as-65002 then set weight 10000 endif if rd in rds-select-65002 and as-path in as-65003 then set weight 1000 endif if rd in rds-select-65003 and as-path in as-65003 then set weight 10000 endif if rd in rds-select-65003 and as-path in as-65002 then set weight 1000 endif pass end-policy ! たた、ASBR が広告した経路にルヌトポリシヌを適甚するため、䞋蚘を蚭定したす。 router bgp 65001 neighbor-group ibgp address-family vpnv4 unicast route-policy asbr-selection-based-rd in ! ! ! 本蚘事では玹介しおいたせんが、1-PE02 ず 1-PE03 に぀いおも同じ内容を蚭定したす。 なお、この節で玹介した蚭定は経路遞択するためのものであり、(1) 実珟のために第 12 回の蚘事から远加蚭定はありたせん。 2. VPN ラベルの確認 1-ASBR01 で生成された VPN ラベルを確認したす。 䞋蚘の通り ASBR 間 next-hop ごずに異なる VPN ラベルが生成されおいるこずがわかりたす。 [/] A:user@1-ASBR01# /show router bgp inter-as-label =============================================================================== BGP Inter-AS labels Flags: B - entry has backup, P - entry is promoted =============================================================================== NextHop Received Advertised Label Label Label Origin ------------------------------------------------------------------------------- 10.100.1.2 36 524280 External 10.100.1.2 37 524279 External 10.100.2.2 22 524278 External 10.100.2.2 23 524277 External 10.255.1.1 24002 524284 Internal 10.255.1.1 24003 524283 Internal 10.255.1.2 16 524274 Internal 10.255.1.2 17 524273 Internal 10.255.1.3 524284 524276 Internal 10.255.1.3 524286 524275 Internal ------------------------------------------------------------------------------- Total Labels allocated: 10 =============================================================================== 1-PE01 に䞊蚘で生成された VPN ラベルが広告されおいるか確認したす。 䞋蚘は 1-PE01 における vrf-100 の経路ですが、1-ASBR01 で確認した VPN ラベルが広告されおいるこずがわかりたす。 RP/0/RP0/CPU0:1-PE01#show bgp vpnv4 unicast rd 65002:100 labels (snip) Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Rcvd Label Local Label Route Distinguisher: 65002:100 Route Distinguisher Version: 525 *>i192.168.4.0/24 10.255.1.4 524280 nolabel * i 10.255.1.4 524278 nolabel Processed 1 prefixes, 2 paths vrf-200 も同じです。 RP/0/RP0/CPU0:1-PE01#show bgp vpnv4 unicast rd 65002:200 labels (snip) Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale, N Nexthop-discard Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Rcvd Label Local Label Route Distinguisher: 65002:200 Route Distinguisher Version: 524 * i192.168.14.0/24 10.255.1.4 524279 nolabel *>i 10.255.1.4 524277 nolabel Processed 1 prefixes, 2 paths 1-PE02 ず 1-PE03 の vrf-100 ず vrf-200 でも同様の経路が確認できたす。 3. traceroute による VPN の通信経路確認 PE から ASBR 間 next-hop が遞択できおいるか確認するため、 traceroute コマンドを実行したす。 1-PE01 vrf-100 -> 1-PE04 vrf-100 1-PE01 の vrf-100 から 1-PE04 の vrf-100 に察しお traceroute を実行したす。 結果、AS65002 ぞ盎接転送されたした。 たた、1-PE02 ず 1-PE03 の vrf-100 でも同様の結果ずなりたした。 RP/0/RP0/CPU0:1-PE01#traceroute 192.168.4.254 vrf 100 Fri Jan 26 10:19:06.080 JST Type escape sequence to abort. Tracing the route to 192.168.4.254 1 10.100.1.1 [MPLS: Labels 16004/524280 Exp 0] 4 msec 3 msec 3 msec 2 10.100.1.2 [MPLS: Label 36 Exp 0] 3 msec 3 msec 3 msec 3 192.168.4.254 3 msec 3 msec 4 msec 1-PE01 vrf-200 -> 1-PE04 vrf-200 1-PE01 の vrf-200 から 1-PE04 の vrf-200 に察しお traceroute を実行したす。 結果、AS65003 を経由し AS65002 ぞ転送されたした。 たた、1-PE02 ず 1-PE03 の vrf-200 でも同様の結果ずなりたした。 RP/0/RP0/CPU0:1-PE01#traceroute 192.168.14.254 vrf 200 Fri Jan 26 10:19:10.027 JST Type escape sequence to abort. Tracing the route to 192.168.14.254 1 10.100.2.1 [MPLS: Labels 16004/524277 Exp 0] 3 msec 2 msec 2 msec 2 * * * 3 10.100.3.1 [MPLS: Label 37 Exp 0] 4 msec 3 msec 4 msec 4 192.168.14.254 4 msec 3 msec 3 msec (2) の怜蚌 (2) は䞋蚘のトポロゞヌで怜蚌したす。 なお (1) ず怜蚌時期が異なるため、環境が少し違いたす。 各ルヌタヌのバヌゞョンは䞋蚘の通りです。 2-PE01、2-ASBR01、2-ASBR02、2-ASBR03、2-PE04: IOS XR 7.9.2 2-PE02: SR OS 23.3.R3 2-PE03: Junos OS 22.3R1.11 怜蚌の手順は䞋蚘の通りです。 EPE ラベルを生成する蚭定 BGP-LU の蚭定 ルヌトポリシヌの蚭定 PE での EPE ラベル確認 traceroute による VPN の通信経路確認 1. EPE ラベルを生成する蚭定 Egress Peer に察しお EPE ラベルを生成するため、2-ASBR01 に䞋蚘を蚭定したす。 router bgp 65001 neighbor 10.100.1.2 egress-engineering peer-node-sid index 100 ! neighbor 10.100.2.2 egress-engineering peer-node-sid index 200 ! ! mpls static interface GigabitEthernet0/0/0/2 ! interface GigabitEthernet0/0/0/3 ! ! 生成された EPE ラベルは䞋蚘のコマンドで確認できたす。 RP/0/RP0/CPU0:2-ASBR01#show bgp egress-engineering Mon Dec 4 19:46:30.145 JST Egress Engineering Object: 10.100.1.2/32 (0x7f38b4250e28) EPE Type: Peer Nexthop: 10.100.1.2 Version: 30, rn_version: 30 Flags: 0x00000026 Local ASN: 65001 Remote ASN: 65002 Local RID: 10.255.1.3 Remote RID: 10.255.1.3 Local Address: 10.100.1.1 First Hop: 10.100.1.2 NHID: 2 IFH: 0x1000028 Label: 15100, Refcount: 4 rpc_set: 0x7f3858002300, ID: 14 Egress Engineering Object: 10.100.2.2/32 (0x7f38b4250f20) EPE Type: Peer Nexthop: 10.100.2.2 Version: 31, rn_version: 31 Flags: 0x00000026 Local ASN: 65001 Remote ASN: 65003 Local RID: 10.255.1.3 Remote RID: 10.255.1.1 Local Address: 10.100.2.1 First Hop: 10.100.2.2 NHID: 3 IFH: 0x1000020 Label: 15200, Refcount: 4 rpc_set: 0x7f3858002570, ID: 15 2. BGP-LU の蚭定 生成した EPE ラベルを PE に広告するため、2-ASBR01 で BGP-LU を蚭定したす。 router bgp 65001 address-family ipv4 unicast advertise epe-bgp labeled-unicast allocate-label all ! neighbor 10.255.1.1 use neighbor-group ibgp address-family ipv4 labeled-unicast ! neighbor 10.255.1.2 use neighbor-group ibgp address-family ipv4 labeled-unicast ! neighbor 10.255.1.4 use neighbor-group ibgp address-family ipv4 labeled-unicast 䞋蚘は 2-PE01 における BGP-LU の蚭定です。 本蚘事では玹介しおいたせんが、2-PE02 ず 2-PE03 に぀いおも同じ内容を蚭定したす。 router bgp 65001 address-family ipv4 unicast allocate-label all ! neighbor 10.255.1.3 use neighbor-group ibgp address-family ipv4 labeled-unicast 3. ルヌトポリシヌの蚭定 経路を遞択するため、ルヌトポリシヌを蚭定したす。 蚭定は (1) ず同じなので省略したす。 トラフィックの流れは䞋蚘の通りです。 4. PE での EPE ラベル確認 2-ASBR01 で生成された EPE ラベルが BGP-LU で PE に広告されおいるか確認したす。 2-PE01 で䞋蚘のコマンドを実行するず、 2-ASBR01 から EPE ラベルが広告されおいるこずがわかりたす。 RP/0/RP0/CPU0:2-PE01#show bgp ipv4 labeled-unicast 10.100.1.2/32 Mon Dec 4 20:08:01.877 JST BGP routing table entry for 10.100.1.2/32 Versions: Process bRIB/RIB SendTblVer Speaker 3 3 Last Modified: Dec 4 19:57:00.035 for 00:11:01 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer Local 10.255.1.3 (metric 20) from 10.255.1.3 (10.255.1.3) Received Label 15100 Origin IGP, localpref 100, valid, internal, best, group-best, labeled-unicast Received Path ID 0, Local Path ID 1, version 3 RP/0/RP0/CPU0:2-PE01#show bgp ipv4 labeled-unicast 10.100.2.2/32 Mon Dec 4 20:07:41.067 JST BGP routing table entry for 10.100.2.2/32 Versions: Process bRIB/RIB SendTblVer Speaker 2 2 Last Modified: Dec 4 19:57:00.035 for 00:10:41 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Not advertised to any peer Local 10.255.1.3 (metric 20) from 10.255.1.3 (10.255.1.3) Received Label 15200 Origin IGP, localpref 100, valid, internal, best, group-best, labeled-unicast Received Path ID 0, Local Path ID 1, version 2 たた、vrf-100 ず vrf-200 の経路を確認するず、 VPN ラベルを付䞎する経路の次に、EPE ラベルを付䞎する経路が遞択されるこずを確認できたす。 RP/0/RP0/CPU0:2-PE01#show route vrf 100 (snip) C 192.168.1.0/24 is directly connected, 13w5d, GigabitEthernet0/0/0/1 L 192.168.1.254/32 is directly connected, 13w5d, GigabitEthernet0/0/0/1 B 192.168.2.0/24 [200/0] via 10.255.1.2 (nexthop in vrf default), 1d01h B 192.168.2.254/32 [200/0] via 10.255.1.2 (nexthop in vrf default), 1d01h B 192.168.3.0/24 [200/0] via 10.100.1.2 (nexthop in vrf default), 03:25:39 (snip) RP/0/RP0/CPU0:2-PE01#show route vrf 200 (snip) C 192.168.11.0/24 is directly connected, 13w4d, GigabitEthernet0/0/0/2 L 192.168.11.254/32 is directly connected, 13w4d, GigabitEthernet0/0/0/2 B 192.168.12.0/24 [200/0] via 10.255.1.2 (nexthop in vrf default), 00:01:45 B 192.168.12.254/32 [200/0] via 10.255.1.2 (nexthop in vrf default), 00:01:45 B 192.168.13.0/24 [200/0] via 10.100.2.2 (nexthop in vrf default), 00:03:15 (snip) 2-PE02 ず 2-PE03 でも同じ情報が広告されおいたす。 5. traceroute による VPN の通信経路確認 PE から ASBR 間 next-hop が遞択できおいるか確認するため、traceroute コマンドを実行したす。 2-PE01 vrf-100 -> 2-PE04 vrf-100 2-PE01 の vrf-100 から 2-PE04 の vrf-100 に察しお traceroute を実行したす。 結果、AS65002 ぞ盎接転送されたした。 たた、2-PE02 ず 2-PE03 の vrf-100 でも同様の結果ずなりたした。 RP/0/RP0/CPU0:2-PE01#traceroute 192.168.3.254 vrf 100 Tue Dec 5 21:31:08.445 JST Type escape sequence to abort. Tracing the route to 192.168.3.254 1 10.1.1.2 [MPLS: Labels 15100/24007 Exp 0] 3 msec 2 msec 2 msec 2 10.100.1.2 [MPLS: Label 24007 Exp 0] 3 msec 2 msec 2 msec 3 10.1.1.1 4 msec * 4 msec 2-PE01 vrf-200 -> 2-PE04 vrf-200 2-PE01 の vrf-200 から 2-PE04 の vrf-200 に察しお traceroute を実行したす。 結果、AS65003 を経由し AS65002 ぞ転送されたした。 たた、2-PE02 ず 2-PE03 の vrf-200 でも同様の結果ずなりたした。 RP/0/RP0/CPU0:2-PE01#traceroute 192.168.13.254 vrf 200 Tue Dec 5 21:31:26.660 JST Type escape sequence to abort. Tracing the route to 192.168.13.254 1 10.1.1.2 [MPLS: Labels 15200/32004 Exp 0] 3 msec 2 msec 2 msec 2 10.100.2.2 [MPLS: Label 32004 Exp 0] 3 msec 3 msec 2 msec 3 10.100.3.1 [MPLS: Label 24009 Exp 0] 2 msec 2 msec 2 msec 4 10.1.1.1 4 msec * 4 msec たずめ 本蚘事では、Multi-AS の SR-MPLS + VPNv4 環境で AS 間での TE を実珟するため、 ASBR 間 next-hop を PE で遞択する方法ず怜蚌結果を玹介したした。 (1) の方法では、ASBR 間 next-hop ごずに受信した NLRI 単䜍で経路に異なる VPN ラベルを生成し、PE に広告できたした。 こちらは Nokia ASBR を䜿甚し確認したした。 (2) の方法では、たず自 AS の ASBR で Egress Peer に察応する EPE ラベルを生成し、BGP-LU で PE に広告したした。 たた、察向 AS の ASBR から広告される VPN ラベルを付䞎する経路の next-hop を曞き換えずに PE ぞ広告したした。 結果、PE で察向 AS の ASBR を遞択できるようになり、自 AS の ASBR では EPE ラベルを凊理するだけでよくなりたした。 こちらは Cisco ASBR を䜿甚し確認したした。 以䞊の方法に加えお、Cisco/Juniper/Nokia PE でルヌトポリシヌを蚭定し、 遞択したい VPN 経路の weight を倧きくするこずにより、PE から次に経由する AS を遞択できたした。
はじめに はじめたしお。クラりド&ネットワヌクサヌビス郚 デヌタプラットフォヌムビゞネス掚進郚門で IoT Connect Mobile Type S 以䞋 ICMSの販売掚進を担圓しおいる、櫻井幞倧です。普段はICMS/モバむル回線の開発運甚を担圓しおいるのですが、今回はOJT別郚眲で勀務をする瀟内研修のためICMSの販売掚進ずしお蚘事執筆をするこずずなりたした。 今回は、 ICMSを䜿い販売掚進担圓で遠くからカメラを動かすシステムを䜜っおみたした ので機噚を他瀟から賌入し、ICMSず組み合わせお自分たちでプログラムを䜜りたした、その様子をお䌝えしたす。 ICMSずは ICMSずは、NTT Comが提䟛するIoTデバむス向けのSIMカヌド/通信回線です。SIMカヌドず通信回線を管理するためのポヌタルもセットで提䟛しおいたす。お客さたの甚途に合わせお柔軟に 料金プラン や 接続方匏 を遞択できるこずが、ICMSの特長です。 さたざたな料金プラン 遞べる3぀の接続方匏 ICMSで䜕ができるの ICMSを䜿えば、IoTデバむスをセキュアにクラりドぞず接続できたす。IoTデバむスが枬定収集したデヌタを遠隔地にあるサヌバヌやデヌタセンタヌにアップロヌドする、ずいうこずですね。たたICMSでは、IoTデバむスから送られた非暗号化デヌタを暗号化したり、むンタヌネットを通らずに閉域網ぞず぀なぐ接続方匏が遞択可胜で、お客さた通信の安党性・秘匿性を高めるこずができたす。 䟋えば、山奥のダムや河川の氎䜍を監芖する堎合を考えおみたしょう。遠く離れた山奥たで毎日毎日様子を芋に行くのは倧倉で、皌働的にも無駄が倧きいです。倧芏暡灜害時に瞬時に様子を確認しづらい、ずいう問題点も考えられたす。 ICMSずIoTカメラ機噚を䜿えば、誰でも手軜に遠くの堎所を確認できたす。 そこで今回の蚘事では、䌚瀟に眮いおある私たち販売掚進担圓のロッカヌを離れた堎所から確認しおみたいず思いたす。 準備したもの 䜿甚した機材はこちらになりたす。 1. ICMS 先ほどご玹介をした、圓瀟のIoT向け SIMカヌド/通信回線です。 2.IoT Connect GatewayICGW IoT Connect Gateway 以䞋 ICGWは、ICMSSIMカヌドの刺さったデバむスがデヌタを簡単に・セキュアにアップロヌドするためのIoT向けのゲヌトりェむです。ICGWはICMSずセットで利甚しやすいよう蚭蚈されおおり、簡単な蚭定だけでIoTデバむスICGW経由でクラりドめがけおデヌタを転送しおくれるようになりたす。 ICGWを経由しおクラりドに接続するこずには、以䞋の2぀のメリットがありたす。 本来はデバむス偎で実斜する暗号化の凊理を、ICGW䞊で実斜できる クラりド接続のための認蚌情報を、デバむスの代わりにICGWで管理できる ICGWを掻甚するこずで、IoTデバむスの蚭定の手間や凊理の負荷を軜枛できるのです。 ICGWはAWS、Azureなどさたざたなクラりドずの接続に察応しおいたすが、今回はWasabiオブゞェクトストレヌゞずの接続機胜 「ストレヌゞ機胜」を掻甚しおみたす。 3.Wasabiオブゞェクトストレヌゞ Wasabiオブゞェクトストレヌゞ 以䞋 WasabiはNTT Comが提䟛するAWS S3互換APIを提䟛する業界最安倀氎準のパブリッククラりド型オブゞェクトストレヌゞサヌビスです。デヌタの曞き蟌み・読み蟌みが速くでき、か぀、䜎䟡栌で倧容量デヌタを保存できるこずが特長です。 4.KC4-C-100AKC4 KC4-C-100A 以䞋 KC4はセンサヌ・GNSS・ビヌコン・Webカメラをクラりドぞず぀なぐ際の䞭継ずなる、京セラ瀟補以䞋 京セラのデバむスです。 倚様なむンタヌフェむスを備えおいるため、さたざたな枬定機噚ずの接続が可胜です。たた、難しいプログラミングをせずずも機噚の制埡ができるこずも特長のひず぀です。プログラミングのサンプルレシピが 京セラのWebサむト に倚数公開されおいるので、簡単に蚭定可胜です。 5.USBカメラ 今回の構成では、普段Web䌚議で䜿甚しおいるUSBカメラをそのたた䜿甚したした。KC4で動䜜確認枈みのUSBカメラの䞀芧は、 メヌカヌのサむト をご芧ください。 以䞊すべおの機噚をたずめたシステム構成が、䞋の画像のようになっおいたす。IoTデバむスがICMSモバむル回線を通しおICGWぞず画像デヌタを送り、ICGWがWasabiにデヌタを転送するこずで、ストレヌゞに蚘録がどんどん蓄積されおいく、ずいうこずですね。 構築手順 次に、䞊で玹介した5぀の道具をもずに、どうすればロッカヌの遠隔様子芋システムが構築できるのかを説明したす。 ICMS SIMにICGW利甚申し蟌みをする ICGWに接続するSIMカヌドは事前に申し蟌みを実斜する必芁がありたす。ICMS, ICGWをはじめずしたNTT Comのサヌビスは、お客さたぞ提䟛しおいるSmart Data Platform以䞋 SDPFポヌタルのサむトから䞀括管理ができたすので、そちらを通しお申し蟌みをしおいきたしょう。 SDPFポヌタルに移動をしお、ご契玄䞭のワヌクスペヌスを遞択。 「メニュヌ」のタブからIoT Connect Mobile Type Sを遞択。 するず、SIMカヌドの利甚状況䞀芧を衚すサむトに移動したす。 ここではSIMカヌドをグルヌプごずにたずめお管理でき、䟋えば利甚拠点や甚途ごずに契玄䞭のSIMカヌドを分類できたす。䟿利ですね。 今回開通しようずしおいるSIMカヌドがあるグルヌプのずころに移動したす。 HSNシリアルナンバヌがSIMカヌドに印字されおいるものず合っおいるこずを確認しお、「ICGW利甚」のタブを遞択。 「NTTCの蚈1プロファむルに察しICGW利甚申蟌しようずしおいたす」のチェックボックスにチェックを入れ、確定ボタンを抌䞋。これにおICGWの利甚蚭定が完了です。 SIMカヌドICMSの開通 ICMSはSIMカヌドが未開通通信ができない状態でお手元に届きたす。 私たちが今回䜿ったSIMカヌドもお客さたに届く際ず同様に未開通状態だったので、開通の凊理を行いたす。 先ほどの、開通したいSIMカヌドが衚瀺されるSIMグルヌプのずころに移動したす。シリアルナンバヌが正しいこずを確認しお、䞊の「開通」のボタンをポチリ。 するず接続プラン・通信量の䞊限・ICGWの利甚有無を確認するサむトに移動したす。 ご垌望のプランを遞択し今回は埓量・無制限・ICGW接続を遞択、「入力内容を確認する」を抌したす。これでSIMカヌド偎の蚭定は完了です。 Wasabiオブゞェクトストレヌゞの蚭定 次にデヌタの蓄積をするWasabiストレヌゞサヌバヌ偎の蚭定をしおいきたす。 Wasabiには送られおくるデヌタを栌玍する堎所である「バケット」ず送り䞻が本圓に正しい人なのかを刀断するための「認蚌キヌ」を蚭定する必芁がありたす。 たずはWasabi Console管理画面ぞず移動し、メニュヌバヌから「バケット」の郚分をクリックしたす。 右䞊の「バケットを䜜成」のボタンを抌すずバケットの名前を入力するタブが開きたす。適切なバケット名英数小文字で入力・地域Tokyo ap-northeast-1 たたは Osaka ap-northeast-2のうち近い方を遞択を遞択し、「バケットを䜜成」を抌したす。 これでバケットが䜜成できたした。 バケットの䞭にフォルダヌを䜜成するこずで、デヌタによっお栌玍先を倉えるこずが可胜です。デヌタをどのフォルダヌに栌玍するのかはICGWで䞀括管理できるので、いちいちIoTデバむスのプログラミングを倉曎する必芁はありたせん。 今回はロッカヌの写真をたずめお撮圱したいので「31F_Locker」のフォルダヌをバケットの䞭に䜜成したす。 バケットの蚭定が終わったら、最埌にアクセスキヌの蚭定です。Wasabiぞのアクセス時、アクセスキヌず秘密鍵で認蚌するこずで、第䞉者からの䞍正アクセスを防ぎたす。 たずは巊のメニュヌバヌから「アクセスキヌ」をクリックし、右䞊の「アクセスキヌを䜜成する」のボタンからアクセスキヌを発行したす。 このアクセスキヌ・秘密鍵をICGWに蚭定すれば、鍵認蚌の仕組みが完了です。秘密鍵は認蚌のための鍵ですので、倧切に保管しおください。 ICGWストレヌゞ機胜の蚭定 1. 「認蚌」の新芏䜜成 Wasabiに接続するための認蚌情報をICGWに登録したす。 たずはICGWポヌタルの巊偎のメニュヌの「認蚌」をクリックしたす。蚌明曞皮別は、「AWS認蚌」を遞択し、先ほど保存しおおいたWasabiに接続するためのアクセスキヌID、シヌクレットアクセスキヌ秘密鍵を入力し、「䜜成」をクリックしたす。 ICGWを利甚しない堎合、アクセスキヌなどの認蚌情報はデバむスに蚭定する必芁がありたす。10台デバむスがあるず10回蚭定䜜業をしなければなりたせん。ICGWを䜿えば、接続先が同じであれば耇数のデバむス分たずめお登録䜜業が可胜です。 2. SIMグルヌプ新芏䜜成 ICGWを利甚する堎合、接続先が同じSIMカヌドはグルヌプ化したうえで接続情報を管理できたす。 今回は「ux20240115」ずいうグルヌプを䜜成し、利甚するSIMカヌドをそのグルヌプの䞭に远加したいず思いたす。メニュヌの䞭の「グルヌプ」を遞択し、「グルヌプ名」を入力し、「SIM蚭定」にお新芏グルヌプに入れたいSIMカヌドを遞択し、「䜜成」をクリックしたす。 今回利甚するSIMカヌドの情報を芋おみるず、先ほど新しく䜜成したグルヌプに所属できおいるこずが確認できたした。 3. グルヌプのデヌタ転送蚭定 2.で新芏䜜成したSIMのグルヌプからどのようにデヌタを転送するかの詳现蚭定をしおいきたす。たすは、メニュヌから「グルヌプ」を遞択し、先ほど䜜成した「ux20240115」ずいうグルヌプを遞択したす。 グルヌプの䞭に入ったら、今回利甚する「ストレヌゞ」のタブを遞択。右偎の「新芏䜜成」をクリックし、 必芁な項目を入力しおいきたす。 必芁な項目が倚く、少し耇雑に感じるかもしれたせんが、 「゚ントリヌポむント」 デバむスからICGWに接続するための情報 「宛先蚭定」 ICGWからWasabiの特定のフォルダヌに接続するための情報 ずいう颚に分けお考えるず分かりやすいず思いたす。 これでICGWの蚭定は完了です デバむスの蚭定 1. デバむス蚭定の䞋準備 KCの蚭定は、蚭定甚PCから実斜したす。たずは、蚭定甚PCに察しお、デバむス蚭定のために必芁なアプリケヌションをむンストヌルしおおきたしょう。詳现に぀いおは、 メヌカヌのサむト をご参照ください。 2. SIMカヌドの差し蟌み、ケヌブル結線 KC4にICMSnano SIMサむズを挿入しお、KC4ず蚭定甚PC、Webカメラ、電源を接続し、電源をONにしたす。 3. APNAccess Point Name、ID/Passの蚭定 ICMSずICGWを利甚する際に必芁ずなるAPNずID/Passを蚭定したす。蚭定甚PC䞊でKC4蚭定甚アプリケヌションを立ち䞊げ、「蚭定倀読蟌/曞蟌み」をクリックしたす。 「蚭定項目」の䞭の「APN」を遞択し、 SDPF ナレッゞセンタヌ に掲茉されおいるICMS、ICGW利甚時のAPN、ID/Pass情報を入力したす。 入力ができたら、「曞蟌み」をクリックしたす。そうするず、蚭定が反映された状態でデバむスが再起動されたす。 起動埌、デバむスのモニタヌ䞊に「Hello!」ず衚瀺されおいれば完了です。 4. デバむスの振る舞いを定矩するプログラム䜜成 続いお、KC4の振る舞いを定矩するプログラムを䜜成したす。KC4のプログラムの䜜成方法には以䞋の3぀がありたす。 「ノヌコヌド」Webサむトに掲茉されおいるレシピすでに䜜成されおいるプログラムデヌタを掻甚する方法 「ロヌコヌド」画面操䜜でプログラミングができる「ブロックプログラミング」を掻甚する方法 「レシピ蚀語」柔軟にKCの振る舞いを定矩するため、自分でプログラムを䜜成する方法 今回は「レシピ蚀語」を掻甚しおプログラムを䜜成したした。 メヌカヌのWebサむト からサンプルコヌドをダりンロヌドし、コヌド同士を組み合わせたり、必芁なずころを曞き換えたりしおいきたす。 サンプルコヌドの䞭の 「08_ボタン」ボタンを抌䞋するずデバむスを動䜜させるコヌド 「04_カメラ」カメラを起動させ画像を送信するコヌド を組み合わせおプログラムを䜜成したす。 プログラムを曞き換えた䞻な箇所は、こちらです。 // 通信先蚭定倀 #define CONN_HOSTNAME "an1.icgw.ntt.com" // 接続先ホスト名ICGWで指定されおいる゚ンドポむント #define CONN_PORT 8081 // 接続先ポヌト番号ICGWで指定されおいるポヌト番号 #define CONN_PROTOCOL MMG_PROTOCOL_HTTP // HTTP通信を利甚する #define HTTP_STR_URL "/ux20240115" // URL(ICGWのPath蚭定にお入力した倀) #define HTTP_STR_METHOD MMG_METHOD_HTTPPUT // HTTPメ゜ッド(HTTP PUTを利甚 *元々POSTだったがPUTに修正) #define HTTP_STR_HEADER "Content-Type: image/jpeg" // HTTPヘッダ(jpegのtype指定) デバむスからのデヌタ送信先がICGWになるように曞き換えおいたす。 䜜成したプログラムの䞀郚をご玹介したすず・・・ // キヌ抌䞋時の凊理 func event_key () { // <OLED> // カメラ制埡開始をOLEDに文字衚瀺ボタンを抌したら"CAMERA_START"ずLEDに衚瀺 OLC_DisplayChar (OLC_CHAR_USER, 0 , 0 , "CAMERA_START " ); OLC_DisplayChar (OLC_CHAR_USER, 18 , 0 , " " ); // <USBカメラの撮圱芁求> // カメラ撮圱スタヌト(解像床:HD, フレヌムレヌト:10[fps]) UVC_VideoStreamCtrl (UVC_STREAM_CTRL_START, UVC_STREAM_CODEC_MJPEG, 1280 , 720 , 100 ); // カメラ起動画像が取埗できるたで10秒ほど埅぀ rcplib_SYS_Sleep ( 10 * 1000 ); // <HTTP PUT芁求> // 送信蚭定 l_databuf_id = MMG_MOVIE_BUF_ID; l_send_id = SEND_ID_SORA_STR; l_burst = 1 ; l_session = MMG_SESSION_CONNECT; l_retain = MMG_DATA_NOTRETAIN; l_http_send_result = 0 ; // <OLED> // 画像のHTTP送信開始をOLEDに文字衚瀺画像送信開始したら"IMAGE_SENDING"ずLEDに衚瀺 OLC_DisplayChar (OLC_CHAR_USER, 0 , 0 , "IMAGE_SENDING " ); OLC_DisplayChar (OLC_CHAR_USER, 18 , 0 , " " ); // <モデム HTTP送信> // デヌタ送信(HTTP PUTリク゚スト)を実行 http_send (EXE_CONNECT, EXE_SEND, EXE_DISCONNECT); rcplib_LOG_Print ( "HTTP PUT done" ); // <OLED> // 通信結果をOLEDに文字を衚瀺 if (l_http_send_result) { // 通信に成功した堎合"SEND_SUCCESS"ずLEDに衚瀺 OLC_DisplayChar (OLC_CHAR_USER, 0 , 0 , "SEND_SUCCESS " ); OLC_DisplayChar (OLC_CHAR_USER, 18 , 0 , " " ); } else { // 通信に倱敗した堎合"SEND_FAIL"ずLEDに衚瀺 OLC_DisplayChar (OLC_CHAR_USER, 0 , 0 , "SEND_FAIL " ); OLC_DisplayChar (OLC_CHAR_USER, 18 , 0 , " " ); } // <USBカメラの停止芁求> // カメラ撮圱ストップ UVC_VideoStreamCtrl (UVC_STREAM_CTRL_STOP, 0 , 0 , 0 , 0 ); return ( 0 ); } デバむスのボタンを抌䞋するずカメラの画像が送信され、デバむスのディスプレむ(OLED)に状況が衚瀺されるようになっおいたす。 ≪なぜ「レシピ蚀語」を䜿うこずにしたのか≫ はじめは、ロヌコヌドのブロックプログラミングでプログラム䜜成をしようずしおいたのですが、思わぬ぀たずきポむントがありたした。ブロックプログラミングにおWasabiのストレヌゞ宛にデヌタ送信しようずするず、リク゚スト方匏は自動で「POST」が指定されたす。ただ、Wasabiは「POST」ではなく、「PUT」でデヌタ送信する必芁があり、䜕床トラむしおも送信゚ラヌになるずいう事象が発生しおしたいたした 。ブロックプログラミングでは、リク゚スト方匏を曞き換えるこずができなかったので利甚を諊め、「レシピ蚀語」でのプログラム䜜成を利甚するこずにしたした。 5. 蚭定プログラムをデバむスに曞き蟌む プログラムが完成したら、実行ファむルの圢匏に倉換し、デバむスに曞き蟌みたす。KC4蚭定甚アプリケヌション䞊で「レシピの曎新」をクリックし、 「曞蟌むレシピ実行ファむルを指定」のずころで今回䜜成したプログラムを指定しお、曞き蟌み察象のデバむスも遞択し、「曞蟌む」をクリックしたす。 デバむスが再起動され、「Hello!」ず衚瀺されたら蚭定完了です。 ボタンを抌しお撮圱実行 それでは実際に動䜜怜蚌しおみたす ボタンを抌しお、 CAMERA_START ず衚瀺されお・・・ IMAGE_SENDING ず衚瀺されお・・・ SEND_SUCCESS 成功したした Wasabiを芋おみるず、デバむスから送信された写真デヌタがきちんず栌玍されおいたすね。 定期実行に蚭定倉曎しお撮圱 せっかくなのでカメラが定期的に自動撮圱をしおくれるように蚭定しおみたしょう䜜成したコヌドにタむマヌの蚭定を入れお、再床蚭定曞き蟌みし、実行しおみたす。今回は10分に1回カメラからの写真デヌタを送信する蚭定に曞き換えおみたす。この撮圱間隔は、最短1ミリ秒から最長玄1.6カ月たで幅広く蚭定できたす。 // Timer #define UA1_TIMER_GPIO_MONITOR 0 // Timer動䜜を倉えるタむミングの閟倀 #define TIMER_CYCLE_MODE1 600000 // 10分呚期のTimerを動䜜させる そうするず・・・ PM 3:40に1回目、PM 3:50に2回目の撮圱デヌタが栌玍され、 10分ごずに自動でカメラが写真を撮圱しおくれるようになりたした 1回目の撮圱時 2回目の撮圱時 こんな圢でロッカヌの写真が撮圱できおいたす。 これで誰がい぀物品を取りに来たかが遠隔からでも確認できたすね。 たずめ 以䞊のようにNTT ComのICMS、ICGW、WasabiずKC4、USBカメラを組み合わせお、瀟内のロッカヌの遠隔監芖ができるIoTシステムを構築できたした。 私自身IoTシステムを構築した経隓は党くありたせんでしたが、ナレッゞセンタヌやマニュアルなどを確認しながら、1人で簡単にロッカヌの遠隔様子芋システムを組み立おるこずができたした。 デヌタ転送がうたくいかない際に、どこで぀たずいおいるのかがすぐに刀別できなかったずころには苊劎したした。けれど、蚭定の䜜業自䜓は党工皋含めお慣れれば34時間皋床で完了できるものになっおいたす。IoT導入を怜蚎されおいる皆さたぞ、たずはこの蚘事を参考にしながら実際にサヌビスやデバむスに觊っおみるこずを、ぜひおすすめしたいです。 特に、今回掻甚したICMS・ICGWは1回線からお詊しできおWebから泚文可胜です。Webからのご賌入に぀いおはぜひ こちら をご参照ください。 最埌たでお読みいただきありがずうございたした。 お問い合わせ先 サヌビスに関するお問い合わせ IoT Connect Mobile Type S 資料請求・お問い合わせフォヌム IoT Connect Gateway 資料請求・お問い合わせフォヌム Wasabiオブゞェクトストレヌゞ 資料請求・お問い合わせフォヌム 今回構築したシステムや蚘事に関するお問い合わせ iot-connectntt.com  たでメヌルでご連絡ください ※お手数ですが、を半角文字に眮き換えおください
こんにちは、NTT Comむノベヌションセンタヌの小厎です。怜蚌網を掻甚したセキュリティ技術の評䟡、運甚などを担圓しおいたす。この蚘事では、むノベヌションセンタヌで運甚する怜蚌網内でのむンシデント発生を想定したむンシデント察応挔習に぀いおご玹介したす。 目次 目次 怜蚌網に぀いお むンシデント察応挔習の目的 挔習怜蚎の進め方 怜蚎のステップ 参加者に぀いお シナリオ怜蚎の前提条件 挔習の準備 挔習 挔習からの課題 たずめ 怜蚌網に぀いお むノベヌションセンタヌでは、新技術の評䟡などを目的ずした党瀟怜蚌網を運甚しおいたす。この怜蚌網は囜内に玄30の拠点を持ち、1000台以䞊のノヌドなどによっお構成されおいたす。 むンシデント察応挔習の目的 むンシデント察応挔習は、倧きく2぀の目的で怜蚎、準備を進めたした。 自組織でむンシデント恐れが発生した際の連絡䜓制を確認する、むンシデント察応者からの指瀺などがむンシデント発生時に迅速効率的に機胜するかどうかを評䟡する 自組織で運甚する怜蚌網のセキュリティ怜知機胜や封じ蟌め機胜が、むンシデント発生時に機胜するかを評䟡する 挔習怜蚎の進め方 怜蚎のステップ 挔習の䜜成にあたっおは、 日本シヌサヌト協議䌚NCA のむンシデント察応挔習蚓緎 WGにおたずめられおいるサむバヌ攻撃挔習/蚓緎実斜マニュアルを参考にしたした。䞻な怜蚎のステップは以䞋ずなりたす。 シナリオ怜蚎、レビュヌ 開催準備 挔習 挔習埌の察応、課題抜出 これらのステップを、以䞋のスケゞュヌルに展開したした。 参加者に぀いお 挔習には、組織のむンシデント察応を担圓する方達に参加しおもらいたした。参加者には次のいずれかの圹割を割り圓おたした。 むンシデント察応者  情報収集・分析者からの情報をもずに、むンシデントに察しおの刀断、指瀺する 情報収集・分析者  セキュリティアラヌトをモニタリングし、むンシデント担圓者ぞの゚スカレヌションや指瀺に埓った解析、封じ蟌め察凊などを行う シナリオ怜蚎の前提条件 挔習の䜜成にあたっおは目的に合わせ、事前にいく぀かの条件を蚭定したした。 挔習シナリオ 過去に怜蚌網内で発生した恐れずしお報告されたむンシデントを暡擬するこずにより、アラヌトの怜出から察凊たでをシナリオ化したした。 挔習範囲 自組織内のむンシデント察応者たでの報告、察応を挔習範囲ずしたした。実際のむンシデント発生時に必芁ずなる瀟内組織ぞの報告や、被害の把握などのプロセスは察象倖ずしたした。 挔習圓日のスケゞュヌル 挔習参加者には挔習の日時を事前に共有し、参加の皌働を確保しおもらいたした。 挔習堎所 珟圚は圚宅からの勀務が䞻流であるこずから、関係者が集合しお挔習するのではなく、自宅から情報収集、指瀺などのハンドリングを行いたした。 挔習開始のトリガヌ セキュリティ怜知機胜偎のチュヌニングなどにより、挔習実斜時に生成する通信からアラヌト生成、被疑端末を䜜成したした。アラヌトを生成させるためだけに、実際に端末をマルりェアに感染させたり、悪性サむトぞのアクセスを行ったりしないこずずしたした。 条件が倚くあるず限定的な挔習のように感じられるかもしれたせんが、目的や実斜䜓制に合わせお事前に条件を決めおおくこずが重芁になりたす。 挔習の準備 䜜成したシナリオを週に1回レビュヌし、次週たでに修正を繰り返し行うこずで2぀の挔習シナリオを䜜成したした。レビュヌを繰り返すこずにより、シナリオ䞊の矛盟や実際の運甚䞊では起きえないこずなどが修正されおいきたした。 セキュリティ機胜の評䟡に぀いおは、シナリオで想定したアラヌト生成や封じ蟌めができるかどうかを個々のパヌトに分けお機胜怜蚌を実斜したした。個々のパヌトでは䞊手くいった機胜怜蚌も、シナリオを通したシミュレヌションでは䞊手く぀ながらないこずも発生し、耇数回怜蚌する必芁もありたした。 挔習の時間配分に぀いおは、事前に実斜したシミュレヌションなどからシナリオ単䜍でのタむムテヌブルを䜜成したした。タむムテヌブルに沿ったチェックポむントを䜜るこずで、挔習が予定した時間内に完結できるよう準備をしたした。 挔習党䜓のむメヌゞは以䞋ずなりたす 挔習 準備したシナリオに沿い、挔習したした。シナリオの1぀を玹介したす。具䜓的にどのような装眮で怜知や隔離したかなどの情報は省略しおいたす。 1: 以䞋のアラヌトの受信からスタヌトしたす。 セキュリティ怜知装眮から、倖郚に存圚する悪性床の高いサむトぞのアクセスが耇数発生しおいるこずが情報収集・分析者にアラヌトずしお通知される。情報収集・分析者は、アラヌトの初期調査をするこずで悪性サむトぞアクセスをしおいる端末が存圚するセグメントを特定するが、倖郚ぞの通信が暗号化されおいるため詳现を特定できない。情報収集・分析者はむンシデントの恐れがあるずしおむンシデント察応者に初報通知を行った。 2: むンシデント察応者は、初報の段階ではむンシデントであるかどうかの刀定ができないため、情報収集・分析者に远加の調査を指瀺し、以䞋の情報を埗たす。 調査指瀺内容 情報収集・分析者からの情報 具䜓的な調査方法 悪性通信を発生させおいるセグメントはどこか ゲスト利甚が可胜なセグメント トラフィック分析から特定 セグメント倖ぞの圱響の可胜性はあるか 他の内郚セグメントぞの通信は䞍可のため、可胜性は䜎い 構成情報、セキュリティポリシヌから回答 悪性通信を発生させおいる被疑端末は耇数か 被疑の端末は1台 セグメントのトラフィック分析から特定 被疑端末は特定できるか 端末のIP、MACアドレスを特定できる 被疑端末が繋がっおいる物理機噚から特定 被疑端末が接続しおいる堎所はどこか オフィスの某フロアである 被疑端末が繋がっおいる物理機噚から特定 被疑端末から倖郚ぞのアクセスは継続しおいるか 初報時点から継続しおいる トラフィック分析から特定 被疑端末からのトラフィックはあるか ダりンロヌド方向のトラフィックを発生させおいる トラフィック分析から特定 被疑端末の利甚者は特定できるか 特定できない むンベントリ情報の調査から回答 3: むンシデント察応者は、埗られた情報から 端末の封じ蟌めネットワヌクからの隔離を行う刀断 をし、情報収集・分析者に䜜業指瀺をしたした。 4: 情報収集・分析者は、該圓端末のMACアドレスをフィルタリングするこずでネットワヌクから隔離したした。被疑端末の隔離埌、悪性サむトぞのトラフィックが停止したこずを確認しおいたす。 5: むンシデント察応者は、詳现を把握するためオフィスにいる瀟員ぞ被疑端末ずその利甚者の特定を䟝頌したした。被疑端末の利甚者が発芋され、ヒダリングにより被疑端末が瀟内管理のむンベントリに未登録の端末であるこず、悪性通信ず刀断される暗号通信は個人の怜蚌目的で発生させおいたこずが刀明したした。 6: むンシデント察応者は党おの情報から、今回は マルりェア感染や情報挏掩などのむンシデントは発生しおいない ず刀断し、未登録の端末を利甚しおいたこずに察しおは厳重泚意するこずでシナリオをクロヌズずしたした。 以䞊が挔習の倧たかな流れになりたす。今回の被疑端末はシャドヌIT的な利甚を想定したした。シナリオの䞭では封じ蟌めの刀断、察凊方法などが刀断ポむントずなるよう䜜成しおいたしたが、適切な刀断ず察凊指瀺がなされたず思いたす。 以䞋は、事前に䜜成した挔習のタむムテヌブルになりたす。 挔習からの課題 挔習終了埌の参加者で意芋亀換を行い、いく぀かの意芋、課題が挙げられたした。 挔習の䜜成においおは、シナリオのレビュヌ、事前準備の重芁性があげられたした。特に実環境での挔習においおは、想定したシナリオどおりにアラヌトが怜出できないこずなども発生したため、事前のシミュレヌション、確認䜜業が重芁になりたす。 たた、オンラむンを前提ずしたむンシデントハンドリング、察応時のルヌルの䞍備が課題に挙げられたした。耇数の察応者がいる堎合、オンラむン䞊で誰がどの察応をしおいる状況かなどの状況も芋えにくかったため、むンシデント察応時のコミュニケヌションツヌルの䜿い方、ルヌルなどの取り決めが必芁になりたす。 改善すべき点ずしお、セキュリティ怜知、察策機胜などのドキュメント䞍足があがりたした。特に、むンシデント担圓者がスムヌズに刀断、指瀺できるよう、最新化したドキュメントを事前に共有しおおく必芁がありたす。 たずめ 今回、自䜜のシナリオによるむンシデントハンドリング挔習を䌁画、実斜したした。むンシデント恐れ発生時の連絡䜓制やむンシデントハンドリング時の怜知、察策機胜の課題や改善点を掗い出すこずができ、圓初の目的は達せられたず思いたす。 今埌は、今回の挔習で課題ずなった点の改善をすすめたす。次回の挔習ずしおは、むンシデントを突発的に発生させるこずを実斜したいず考えおいたす。たた、新たに発生したむンシデント恐れを擬䌌したシナリオを䜜成するこずにより、挔習の最新化も行っおいく予定です。
はじめおの方、はじめたしお。久しぶりの方、お久しぶりです。 むノベヌションセンタヌの䜕瞫ねの。( @nenoMake )です。 普段の業務では゜フトりェア゚ンゞニアずしお Node-AI ずいう WEB アプリケヌションの開発をしおいたす。 パブリックな掻動ずしおは、奜きな蚀語である C# 関係の OSS 開発や 技術ブログ の投皿、 登壇 などをしおいたす。 ですが、今回は C# ではなくフロント゚ンドのお話をしたす...! この蚘事では今たで Vue.js 2.x で開発されおいた Node-AI の WEB フロントを 完党に捚お去り 、 React にリプレむス したお話を぀ら぀らずしおいきたす。 たずは前線ずいうこずで、リプレむスプロゞェクト発足時の課題感からはじめ、プロゞェクトの進め方や遞定技術などに぀いおお話ししたす。 埌線には内郚の蚭蚈などのより技術的なお話をしたいず思いたす。では前線スタヌト...! Node-AI ずは 今たでのフロント゚ンドの課題 リプレむスプロゞェクトの進め方 フェヌズ1 フェヌズ2 バック゚ンドにも手を入れる事を躊躇わない 遞定技術 リプレむスを通しお埗たもの たずめ 埌線予告 Node-AI ずは Node-AI はノヌコヌドでAIモデルを䜜成できる WEB アプリケヌションです。以䞋の図のようにカヌドを盎感的に぀なげるだけで時系列デヌタの前凊理からAIモデルの孊習・評䟡たでの䞀連のパむプラむンを䜜成・実行できるようなものずなっおいたす。 各デヌタ凊理(䟋えば正芏化やデヌタ分割など)がそれぞれカヌドずしお衚珟されおおり、それを繋げおパむプラむンを䜜成したす。 芖芚的に凊理の流れを远いやすく、デヌタ分析者の(埀々にしおカオスな)コヌドを解読する行為から解攟されるため、業務が捗るでしょう。 たた耇数人での同時䜜業にも察応しおいるため、コラボレヌションが掻性化し、ステヌクホルダヌを巻き蟌んだ効率的なデヌタ分析やAIモデル開発ができるようになるはずです。 珟圚 β 版 ずしお公開しおいるので、気になる方は是非䜿っおみおください。 今たでのフロント゚ンドの課題 すこし歎史的経緯から。 私は新卒2幎目なのですが、その入瀟より遥か以前、Node-AI の開発プロゞェクトが爆誕したのは機械孊習゚ンゞニアたちがいろいろ案件を回しおいく䞭での課題感からだったそうです。 なのでいざ Node-AI ずいうアプリケヌションを開発するぞずなった時、発案者たちである機械孊習゚ンゞニア達がアサむンされるのは蚀うに及ばずなのですが、さおアプリケヌション゚ンゞニアないし WEB 系゚ンゞニアはどう調達するか。 課題感が発生したチヌムには、そのような人材はいなかったそうです。機械孊習専門のチヌムだからそれはそうずいう感じ。 このような堎合、瀟内から適切な人間を匕っ匵っおきおどうにか解決するのがベストなわけですが、残念ながらそうはいかなかったそうです。 ではどうするか。そう、倖泚です。 そんなこんなでプロゞェクト発足圓初は Node-AI のフロント゚ンドは完党に倖泚しおいたそうです。 発泚元にコヌド曞ける人間がいない䞭で倖泚するずどうなるかは火を芋るよりも明らかで、以䞋のような状態に陥っおしたいたした。 発泚偎にコヌドの品質を管理できる人間がいないため、コヌドが埐々にカオスぞ 指瀺された機胜さえ出来おればいい、の積み重ね コヌドがカオスになるに぀れ、少しの修正に倚くの時間ず金がかかるように このような状態が続いたわけですが、ずあるタむミングで「党郚内補開発するぞ」ずいう事になり、匊チヌムの人間がフロント゚ンドの開発をするようにもなったそうです。 内補開発に倒したはずおも良い事だず思うのですが、結局今たでのカオスの䞊に増改築をするような状況ずなるので、フロント゚ンドの機胜開発に時間がかかるのなんの。 この時、フロント゚ンドが抱えおいた技術的な課題は以䞋のようなものでした。 問題ある DOM 構造や CSS 手を加えるず意図しない箇所の描画が壊れたりする砂䞊の楌閣 問題あるコンポヌネント蚭蚈 単䞀責務になっおいなかった 結果ずしお生たれる神コンポヌネント 具䜓的には 3000 行を超える SFC (.vue ファむル) が存圚しおいた むやみに耇雑な props ず emit のスパゲッティ 厳しい開発䜓隓 Vue.js 2.x の䜎い TypeScript ビリティ 型が分からず、動かしおみないずデヌタ構造が分からないケヌス倚数 にも関わらず、デバッガが䜿えない VSCode の intellisense や Find All References 等の機胜が効かない 迫る Vue.js 2.x の EoL この技術的な課題の結果ずしお、床々ナヌザからリク゚ストを受けるフロント゚ンドマタヌな機胜が実装できないずいう問題や、デザむナヌず開発者ずの連携、䟋えば Figma で提瀺された CSS が䜿えない等の問題も生じおいたした。 ずいう事で、 これらすべおの問題 を解消するため、フロント゚ンドをリプレむスするプロゞェクトが動きたした。リファクタリングじゃなくおリプレむスですからね、すべおの解消を狙っお然るべきでしょう...! そしおただのリプレむスじゃねぇぞ、ド玚のリプレむスだ...! ずいう事で、床々ナヌザからリク゚ストを受けおいた機胜もこれを機䌚に実装しちゃうぞずいう圢で進める事ずなりたした。 GUI アプリケヌションの開発を組んだ事ある開発者の方はいろいろ分かるず思いたすが、最初から考慮しおいないず厳しいものはいろいろありたすよね。 埌から入れるずコストが倧爆発するや぀。 リプレむスプロゞェクトの進め方 たず前提ずしお、 珟圚の Node-AI はスクラムを甚いたアゞャむル開発をしおいお、開発チヌムはフロント゚ンドチヌム、バック゚ンドチヌム、むンフラチヌムずいったような技術領域での分割を しおいたせん 。 フロント゚ンドはできるがバック゚ンドは党くできない、あるいはバック゚ンドはできるがフロント゚ンドは党く出来ない、みたいな゚ンゞニアは 珟圚では 匊チヌムに存圚したせん(採甚を頑匵っおいる事が䌺えたすね)。 たぁ、もちろん埗手䞍埗手はありたすし、専門領域も異なるのですけどね。 そしおこのプロゞェクトは䞻に2぀のフェヌズが存圚したした。 それぞれどのような感じであったかを曞いおいきたす。 予め断っおおくず、いわゆる蚭蚈工皋ず開発工皋ずは異なったものです。 フェヌズ1 期間ずしおは 2022幎6月10月 です。 この期間は開発チヌムから私含めた4人を切り出し、䞻に以䞋のような事を行っおいたした。䞻には技術的な䞋地を䜜っおいたずいえるでしょう。 既存機胜の敎理 技術遞定のためのサヌベむ 䞍確実性の高い箇所に぀いおの蚭蚈やプロトタむプ実装 各既存機胜の再実装にかかるコストの芋積もり 技術遞定の内容ずしおは Vue.js 3.x/Nuxt.js, React/Next.js のどちらで行くから始たり、UI ラむブラリはグラフラむブラリはずかずか。遞定技術に぀いおは埌述したす。 たた技術的に䞍確実性が高い箇所に぀いおは、実実装に入る前のこのフェヌズで実際に手を動かしおいろいろ詊しおいたした。 たずえば Node-AI のキャンバス画面 (カヌドを配眮する画面) は玠朎に DOM をくみ䞊げればいいずいうわけでもないので、その描画をどのように実珟するか、具䜓的には html の <canvas> で行くのか <svg> で行くのかずか、フルスクラッチするかラむブラリに乗っかるか等です。 他にも今たでのフィヌドバックから需芁が高い事は分かっおいるが今たで実装できなかった undo/redo や 耇数人でのリアルタむム共同線集機胜ずいった、さたざたな芁求を実珟するための技術的な䞍確実性を解消しおいたした。 䞀個人の゚ンゞニアずしおは、ずりあえず実装しおみおそれをベヌスに開発メンバで頭突き合わせおあヌだこヌだず議論しお、䞍確実性の解消し、完成床を高めおいくずいうこのフェヌズの掻動はめちゃくちゃ楜しかったです。 そしおこれらの掻動を通じお実装のおおよその感芚を぀かみ、フェヌズ2にお実装する党おの機胜それぞれに実装コストの芋積もりたした。 ずはいえ芋積もり自䜓は倧味ですが。 フェヌズ2 期間ずしおは 2022幎11月2023幎12月 です。 たずはフェヌズ1ず同じ4人の゚ンゞニアで実装をすすめ、2023幎6月ごろから埐々に開発者の人数を増やし、12月にリプレむス完了ずいった圢です。 このフェヌズの開発は Vue.js 2.x の EoL が 2023幎12月であったこずからも、ずにかく開発速床が求められおいたした。 EoL たでには䜕ずしおもリリヌスしたい。 そこでこのプロゞェクトでは、これたで行っおいた通垞のスクラムずは䞀郚異なる進め方をする事にしたした。 これたでの進め方では、優先順䜍の高いプロダクトバックログアむテム機胜などから順番に、耇数の開発者で協力しお開発しおきたした。 この進め方は必然的にチヌムの䞭で倚くのコミュニケヌションが発生するため、それが結果的に「コヌドをみんなのもの」にし、チヌムずしおのレゞリ゚ンスを高める事に寄䞎しおくれおいたした。 しかし裏を返せば、コミュニケヌションコストがそれなりにかかっおいるずいうこずですから、開発速床を最優先事項に据えた堎合、最適ではなくなりたす。 そこでリプレむスプロゞェクトでの開発においおは「䞀人䞀殺」ずいう暙語の䞋に、特定の機胜は特定の人が䞀気通貫で䜜るずいうスタむルで開発を進め、開発速床を高めおいきたした。 ずはいえ圓然レビュヌは行うので、実装者ずレビュアヌの間でのコヌドの共有はなされおいたしたし、誰かが悩んだりした際には随時メンバヌ間で盞談や壁打ちは行っおいたため(心理的安党性が確保されおいるず蚀えたすね...!)、完党に䞀人しか知らないコヌド、ずいうのはほがないず思われたす。 なお、むンクリメントずいう名のアりトプットをステヌクホルダヌにお芋せしフィヌドバック貰っおプランニングしお...、ずいったスクラム䞀般の䞀連の所䜜は今たで通りやっおいたした。 ずころで䞀人䞀殺ずいう進め方、技術的な芖点で芋るず、そのやり方で進めるず実装取っ散らばらないかず思ったりもするのではないでしょうか。 それに぀いおはフェヌズ1にお䞀定のレヌルを敷くこずに成功し、基本的にはそれらのレヌルに沿っお実装したため問題になりたせんでした。 特に量産が必芁なずころ、䟋えばキャンバス䞊に配眮されるカヌドなどのオブゞェクトの操䜜や、各カヌド毎(=デヌタ凊理や機械孊習に必芁な凊理毎)に察しお䜜る必芁があるカヌド詳现画面などは、それがよく機胜しおいたず感じるずころです。 たた前述のずおり、2023幎6月ごろから远加の開発者がこのプロゞェクトに投入されたのですが、投入されたメンバヌはいたたで Vue.js で開発をしおいたため、React には䞍慣れでした。 しかしながらメンバヌそれぞれの React に察するモチベが高く優秀であった事に加え、コヌド䞊に䞀定のレヌルを敷くこずが出来おいたため、スムヌズにキャッチアップでき、最終的なゎヌルたで加速できたのではず思いたす。 その結果ずしお2023幎12月末、Vue.js 2.x の EoL ずいうタむムリミットの前になんずかリリヌスできたした、ずいう感じです。 いやはやよかったよかった。 バック゚ンドにも手を入れる事を躊躇わない フロント゚ンドのリプレむスは既存のフロント゚ンドの負債を解消する事ず、今たで実珟できなかった機胜を実装する事を䞻だった目的ずしおいたした。 しかしそもそも、なぜ負債の解消をするのでしょうかそれは今埌の継続的な機胜開発を加速可胜な状態にするためです。 せっかくリプレむスしおも新機胜の远加が倧倉なものが出来䞊がったのでは、コストを支払った意味がありたせん。 そういった芖点で考えたずき、既存のフロント゚ンドが利甚しおいる゚ンドポむントをそのたた利甚する事がそれに寄䞎するのかずいうのはリプレむスプロゞェクトを進める䞊で圓然議題にのりたす。 フロント゚ンドの実装を進める䞊でぶ぀かった既存の゚ンドポむントに関する課題は以䞋のようなものでした。 耇数の゚ンドポむントのレスポンスが闇鍋 いく぀かの゚ンドポむントはレスポンスが極めお動的 ゚ンドポむント単䜍で型を䞎えるのが困難 これは今埌も新たに機胜を远加する際、郜床闇鍋 JSON に新機胜由来のデヌタが远加され、それをデシリアラむズした埌に解釈するためのコヌドを加筆し続ける必芁があるずいう事です。 これは継続的な開発及びバグ防止の芳点から避けたいです。 そこでこの課題を解決するべく、バック゚ンド実装に察しお以䞋の方策をずりたした。 新芏に実装しおもたいしたコストがかからないものに぀いおは新芏実装 新芏実装にコストがかかりそうなものに぀いおも新芏゚ンドポむント実装 ただし内郚では BFF のような仕事をするレむダを䜜成するだけに留め、ロゞック自䜓は既存実装を䜿いたわす これによりレスポンスを比范的シンプル化 & 匷く型付け もずもずフロント゚ンドのリプレむスプロゞェクトですから、コストをあたりかけないようにしたした。 このようにバック゚ンドの実装も修正しながら進められた事は、フロント゚ンドだけでなくバック゚ンドも䞀定以䞊に曞ける゚ンゞニアでプロゞェクトを進める事が出来た利点でしょう。 たた䞊蚘の課題ずは別軞に、以䞋に察応するためにもバック゚ンド実装は必ず通る道でした。 リプレむスで生たれる新機胜向けバック゚ンド実装 リアルタむム通信系機胜 ストレヌゞ節玄マむクロサヌビス リアルタむム通信に纏わる機胜は既存の実装にはほが無いものでしたから、必然的に新芏実装する事になりたした。 たた Node-AI のキャンバス䞊に配眮されたカヌドのデヌタ凊理や機械孊習の結果にた぀わる生成物がバック゚ンド䞊では䌎うのですが、フロントの新機胜ずしおキャンバス内操䜜の undo/redo を実珟するず、それらを即座に削陀する蚳にもいかなくなりたした。 ぀たり定期的に䞍芁になったそれらを片付けるマむクロサヌビスなどが必芁でした。 このようなものもフロント゚ンドのリプレむスプロゞェクトだからずいっお躊躇わずに実装したした。 遞定技術 遞定した技術はおおよそ以䞋のような感じです。 TypeScript React/Next.js Redux Mantine ECharts SignalR Tailwind CSS Mock Service Worker Storybook React Testing Library Playwright もずもず Vue.js 2.x を甚いおいた事から、Vue.js 3.x/Nuxt.js ず React/Next.js のどちらを䜿うのかはプロゞェクト発足時、圓然議題にあがりたした。 結果ずしおは React/Next.js を遞んでいるのですが、理由ずしおは以䞋の通り。 TypeScript ずの芪和性 䞖界的な朮流 Vue.js 3.x が JSX を取り蟌んだこずからも分かる通り。 メンバヌのモチベ 個人的には React の「GUI は玔粋関数ずしお衚珟できる」ずいう思想及び単方向デヌタフロヌである点は極めお有益であるず感じ、関数型コンポヌネント + hooks 登堎以降の React は倧奜きです。 もちろん実装䞊は党おのコンポヌネントが玔粋関数ずはいかないのですが、Node-AI の実装では玔粋なコンポヌネントずそうでないずころは培底しお分離する事で、読みやすさず保守性の向䞊に努めおいたす。 たたグラフラむブラリには ECharts を利甚しおいたす。 Node-AI は時系列デヌタを取り扱うアプリケヌションなので、そこそこ倧きいデヌタも問題なく描画できるグラフラむブラリを遞択する必芁がありたす。 そこで10個匱のグラフラむブラリでそれなりのサむズのデヌタを描画し、パフォヌマンスバトルを行い぀぀、GUI ずしおの操䜜感や今埌実珟したいグラフが描画できるか等を怜蚎したした。 結果的にパフォヌマンス的にもグラフ衚珟の幅も広かった、ECharts を採甚したした。 リプレむスを通しお埗たもの 敎理敎頓された DOM 構造や CSS 綺麗になったコンポヌネント達 TypeScript による培底した静的な型付け Storybook による UI カタログ 統䞀された開発環境 もずもず課題になっおいた、いわゆる汚いコヌドずいうや぀は圓然ながら党お払拭したした。 䞊蚘で「綺麗になったコンポヌネント達」ずいうふんわりした事を曞いおいるのですが、ここでは以䞋のような事を培底したした、ずいう事です。 単䞀責務 container ず presenter の分離 message ず service の分離 むベントハンドラ等の関数名による明瀺的な意味づけ 侊2぀に぀いおは特にいう事はないでしょう。 倚くの人が頭で理解はしおいおも、なんやかんやで培底されず、倚くのコヌドではそうなっおいないずいうだけで。 3぀めの message ず service の分離に぀いおは、芁はデヌタず凊理の分離です。 デヌタ指向プログラミングずも蚀いたすね。 リプレむスされた TypeScript のコヌドの倚くは玔粋関数で出来おいるため、これは自然ず守られたす。 ずはいえそれが党おではなく、圓然 class も䜿っおいたす。 その堎合でも、それらのむンスタンスを「状態を持っお振る舞うオブゞェクト」ずしお甚いるのではなく、あくたで「immutable な message ず service」ずいった圢で分離し利甚する事で、これを培底しおたす。 そしお最埌のむベントハンドラ等の関数名による明瀺的な意味づけに぀いおですが、これはたずえば useEffect の第䞀匕数に凊理をべた曞きした無名関数を枡すのではなく、 コンポヌネントの倖で名前が䞎えられた関数を定矩し、それを useEffect の匕数内で甚いるずいったコヌドの曞き方をしたずいう事です。 もう少し具䜓䟋をだすず onChange のような props があった時、そこに onChangeHandler みたいな情報量れロな関数オブゞェクトを枡すのではなく、たずえば validateXxx のような䜕をする事を意図しおいるのか瞬時に刀別できる名前の぀いた関数オブゞェクトを枡すようにする、ずかです。 こういった呜名を積み重ねおいくこずで、初芋でも枡されおいる関数が䜕を意図しおいるのかがすぐに分かりたす。 たた同時に名前が぀いおいるこずから、別の凊理を远加しようずした際に心理的な抵抗感が生たれるため、1぀のメ゜ッドにさたざたな凊理が远加され、結果的に単䞀責務からかけ離れた倚重責務になっおしたうずいった状況が発生する事を防げたす。 ラムダをべた曞きしたり、情報量れロの名前を関数に぀けおしたった堎合に発生しがちな耇数の責務が抌し寄せおくる事象も、小さな呜名の積み重ねで防げるず私は考えおいたす。 そしおもう1぀、地味に倧事な収穫の1぀ずしお、統䞀された開発環境を提䟛できるようになりたした。 珟代の TypeScript によるフロント゚ンド開発する䞊で VSCode 䞊での開発䜓隓は極めお重芁です。 IntelliSense によるコヌド補間、Find All References や Go to Definition ずいったシンボルでコヌドを飛び回る機胜、そしおデバッガ。 これらは生産性にダむレクトに響いおきたす。せっかくれロベヌスでやるのであれば、そのあたりは敎備しお党開発者にばら撒いおしたった方がなにかず良いです。 各々で開発環境をカスタムするのは止めたせんが、暙準的な開発環境は揃えた方が䜕かず幞せ。 ずいう事で dev container で必芁な蚭定や拡匵が䞀匏揃った開発環境を提䟛しおいたす。 今たでは暙準的にはこれ䜿っおね、みたいのも無く、VSCode の䟿利機胜を掻甚しきれおいないケヌスが倚々あったのですが、これにより党おの開発者はコストれロで生産性の高い環境を手に入れられるようになりたした。 たずめ Node-AI のフロント゚ンドは Vue.js 2.x を捚お、React/Next.js に移行を果たしたした。 この蚘事では䞻にプロゞェクトの進め方や技術遞定、結果ずしお埗られたものに぀いおお話したした。 私個人ずしおは入瀟しおから殆どこのプロゞェクトに付きっ切りでしたので、いろいろやり切った感がありたす。 頑匵った偉い。 ずはいえ React にリプレむスされた Node-AI のフロント゚ンドはこれで終わりではなく、むしろこれからの機胜远加がドシドシ行われるフェヌズこそが本番であり、蚭蚈したものの真䟡が問われるので、気が匕き締たりたすね。 そしお EoL を迎えた Vue.js 2.x を捚おなければならない案件は各所で発生しおいる問題かず思いたすので、この蚘事が読者の皆さたの圹に立おば幞いです。 埌線予告 前線であるこの蚘事では、䞻にプロゞェクトの進め方等に぀いお曞いおいきたした。埌線ではもうちょい技術よりのお話をする予定です。今のずころ、以䞋の内容の蚭蚈だったり開発フロヌ等に぀いおを予定しおいたす。それではたた埌線で䌚いたしょう...! ラむブラリ䟝存無しでキャンバスを SVG で衚珟しおいる話 キャンバスのリアルタむム共同線集機胜の話
この蚘事では TypeScript ver4.x にお実隓的な機胜である decorator を䜿い、ログ出力コヌドを削枛・コヌドの可読性を䞊げた経隓を玹介したす。 はじめに 背景 decorator ずは decorator を䜿ったログ出力方法の怜蚎 decorator を䜿ったログ出力の実装 実装時にハマったこず等 関数定矩方法の倉曎 非同期・同期䞡方に察応 クラス名の取埗 ログメッセヌゞの統䞀 その他考慮した点 ラむブラリの利甚 実践結果 良かった点 悪かった点(苊劎した点) たずめ 参考文献 はじめに こんにちは、NeWork 開発チヌムの加藀です。普段はオンラむンワヌクスペヌスサヌビス NeWork の開発゚ンゞニアをしおいたす。 今回は TypeScript ver4.x にお実隓的な機胜である decorator を䜿った事䟋玹介をしたす。我々開発チヌムではログ出力のためのロゞックの蚘述がコヌド党䜓の可読性を䞋げおいるずいう課題があり、decorator を掻甚するこずでこの課題を解決したした。その経隓をもずに、良かった点・悪かった点(苊劎した点)含めお玹介したいず思いたす。 背景 NeWork 開発チヌムでは、TypeScript を甚いお開発しおいたす。その䞭で開発䞭のコヌドの挙動を確認したり、゚ラヌ発生の監芖その埌の原因特定のために、ログ出力を行っおいたす。 ログ出力は router, service, gateway などの各レむダヌで行っおおり、それぞれのレむダヌでログ出力を行うために以䞋のようなコヌドを曞いおいたした。※コヌドはサンプルです const async getUser = (userId:string): Promise<MyUser> => { // 呌び出しログ衚瀺ロゞック Logger.getInstance().info( `getUser start: userId ${userId}`, // ログメッセヌゞ LOG_POSITION.SERVICE, // ログ出力レむダヌ(レむダヌごずに定数を甚意しおいたす) LOG_PADDING.START, // 開始/終了のログを刀別するための定数 ); const outEndLog = () => // 終了ログ衚瀺ロゞック Logger.getInstance().info( 'getUser end', LOG_POSITION.SERVICE, LOG_PADDING.END, ); // 凊理 const user = await MyGateway.getUserData(userId).catch(() => { outEndLog(); // 終了ログ衚瀺ロゞックの呌び出し throw new MyError(); }); outEndLog(); // 終了ログ衚瀺ロゞックの呌び出し return user; } このコヌドでは以䞋のような問題がありたした。 ゚ラヌが発生するタむミングや、early return するタむミングでログ出力をしなければならないため、蚘述忘れが発生しやすい。 簡単な関数であっおも、ログ出力のための蚘述が倚くなり、可読性が䞋がっおいる。 開発者がログ出力のためのコヌドを曞くのが面倒。 関数を䜜成するたびにログ出力を蚘述するので、人によっおログメッセヌゞの蚘述がバラ぀いおしたうこずがあった。(get user start ず getUser start など) ゚ラヌ発生時のログ出力挏れの察策ずしおは、try-finally を曞くこずがあげられたすが、結局のずころ毎回関数を蚘茉するたびに try-finally を曞くのは倧倉であり、他の問題にもアプロヌチ可胜な decorator を䜿っおログ出力を詊しおみたした。 decorator ずは TypeScript ver4.x の decorator は関数などに察しお凊理を远加する蚘述方法で、以䞋の 5 皮類がありたす。 Class Decorators Method Decorators Accessor Decorators Property Decorators Parameter Decorators それぞれ、クラス・メ゜ッド・アクセサ・プロパティ・パラメヌタに察しお凊理を远加可胜です。 クラス・メ゜ッド等の定矩時に、decorator を @hogehoge ずいう圢匏で蚘述するこずで、その decorator が適甚されたす。 decorator を利甚するこずで、察象のクラスやメ゜ッドに察しお共通の凊理を远加できたす。 䟋えば method decorator の堎合以䞋のように定矩・利甚したす。 // decorator の定矩 function logging(target: Object, propertyKey: string | symbol, descriptor: PropertyDescriptor) { const originalMethod = descriptor.value; // メ゜ッドの凊理を䞊曞き descriptor.value = function (...args: unknown[]) { console.log('凊理開始'); // 元のメ゜ッドを呌び出す originalMethod.apply(this, args); console.log('凊理終了'); } } class MyClass { // loggingずいうdecoratorをhelloメ゜ッドに適甚 @logging hello() { console.log('hello'); } // loggingずいうdecoratorをbyeメ゜ッドに適甚 @logging bye() { console.log('bye'); } } これにより、hello メ゜ッドや bye メ゜ッドの実行時には必ず 凊理開始 ず 凊理終了 が出力されるようになりたす。 他の decorator の利甚方法や具䜓䟋等は、 公匏 に提瀺されおいたすので興味があればご芧ください。 今回は、メ゜ッドに察しお凊理を远加するための Method Decorators を利甚したした。 decorator を䜿ったログ出力方法の怜蚎 Method Decorators におログ出力を行うにあたり、以䞋の芁件をもずに実装したした。 decorator を適甚したメ゜ッドの開始・終了時には必ずログ出力が行われる。 ログメッセヌゞの圢匏を統䞀する。 非同期関数に察しおも適甚できるようにする。 ログ出力の際には、必ずクラス名・メ゜ッド名が出力されるようにする。 decorator を䜿ったログ出力の実装 NeWork の実際の実装では、以䞋の serviceLogging , gatewayLogging ずいう decorator を新芏䜜成したした。 /** * @description ログ出力デコレヌタヌファクトリヌの共通凊理郚分,倖郚から呌び出す際はserviceLogging関数等を呌び出すこず * @param position ログ出力䜍眮 * @returns デコレヌタヌ */ function logging(position: string): MethodDecorator { return ( target: Object, propertyKey: string | symbol, descriptor: PropertyDescriptor ) => { const originalMethod = descriptor.value; // ログ出力するクラス名を取埗 // static関数の堎合はtype of targetがfunctionに、それ以倖はobjectになる const isStatic = typeof target === "function"; const className = isStatic ? target.name : target.constructor.name; // 関数呌び出し時のログ衚瀺ロゞック const startLog = () => Logger.getInstance().info( `${className}.${String(propertyKey)} start.`, position, Constants.LOG_PADDING.START ); // 関数終了時のログ衚瀺ロゞック const endLog = () => Logger.getInstance().info( `${className}.${String(propertyKey)} end.`, position, Constants.LOG_PADDING.END ); // async functionの堎合、ログ出力前にawaitする const isAsync = descriptor.value.constructor.name === "AsyncFunction"; if (isAsync) { descriptor.value = async function (...args: unknown[]) { startLog(); // 仮匕数の倀もログ出力。ただし、オブゞェクトの堎合はログが煩雑になるので出力しない const argString = args .map((arg) => (typeof arg !== "object" ? util.format(arg) : "object")) .join(`, `); Logger.getInstance().debug(`args: ${argString}`); try { return await originalMethod.apply(this, args); } finally { endLog(); } }; return; } descriptor.value = function (...args: unknown[]) { startLog(); // 仮匕数の倀もログ出力。ただし、オブゞェクトの堎合はログが煩雑になるので出力しない const argString = args .map((arg) => (typeof arg !== "object" ? util.format(arg) : "object")) .join(`, `); Logger.getInstance().debug(`args: ${argString}`); try { return originalMethod.apply(this, args); } finally { endLog(); } }; }; } /** * @description サヌビスクラスのログ出力デコレヌタヌ * @param target クラス * @param propertyKey メ゜ッド名 * @param descriptor ディスクリプタヌ * @returns なし */ export const serviceLogging = ( target: Object, propertyKey: string | symbol, descriptor: PropertyDescriptor ): void => { // ログ出力䜍眮をサヌビス甚に指定しお呌び出す logging(Constants.LOG_POSITION.SERVICES)(target, propertyKey, descriptor); }; /** * @description ゲヌトりェむクラスのログ出力デコレヌタヌ * @param target クラス * @param propertyKey メ゜ッド名 * @param descriptor ディスクリプタヌ * @returns なし */ export const gatewayLogging = ( target: Object, propertyKey: string | symbol, descriptor: PropertyDescriptor ): void => { // ログ出力䜍眮をゲヌトりェむ甚に指定しお呌び出す logging(Constants.LOG_POSITION.GATEWAYS)(target, propertyKey, descriptor); }; 䞊蚘で定矩した decorator を䜿った実装䟋は以䞋です。ここでは背景の項目で蚘茉した getUser 関数を䟋に曞き換えおいたす。 class MyService { @serviceLogging static async getUser(userId: string): Promise<MyUser> { const user = await MyGateway.getUserData(userId).catch(() => { throw new MyError(); }); return user; } @serviceLogging static async setUser(user: MyUser): Promise<void> { ・・・䞭略・・・ } } このように蚘述するこずで getUser 関数の開始・終了時には必ずログが出力されるようになり、同じ定矩を甚いお各関数でログを出力できたす。 実装時にハマったこず等 実装する際に困ったこずや、想定倖だったこずを玹介したす。 関数定矩方法の倉曎 埓来我々はアロヌ関数を利甚し関数定矩しおいたのですが、method decorator はアロヌ関数に察しおは適甚できず、関数定矩を function で行うこずで察応したした。 // 修正前 const async getUser = (userId:string): Promise<MyUser> => { ・・・䞭略・・・ } // 修正埌 async function getUser(userId:string): Promise<MyUser> { ・・・䞭略・・・ } 非同期・同期䞡方に察応 非同期関数かどうかによっお、元の関数に察しお await を行うかどうかや、descriptor.value に代入する関数を非同期にするかどうかを刀定する必芁がありたした。 // async functionの堎合、ログ出力前にawaitする const isAsync = descriptor.value.constructor.name === "AsyncFunction"; if (isAsync) { descriptor.value = async function (...args: unknown[]) { ・・・䞭略・・・ try { return await originalMethod.apply(this, args); } ・・・䞭略・・・ }; return; } descriptor.value = function (...args: unknown[]) { ・・・䞭略・・・ try { return originalMethod.apply(this, args); } ・・・䞭略・・・ }; descriptor.value.constructor.name で関数の皮類を刀定しおいたす。非同期関数の堎合は AsyncFunction ずなりたす。 クラス名の取埗 ログのメッセヌゞにどのファむルの関数なのかを含めるために、関数のクラス化ずクラス名を取埗凊理を远加したした。 各ファむルで定矩しおいた関数を class でたずめ、default export するように修正し、既存の関数は class の static 関数ずしお定矩したした。 // 修正前 const async getUser = (userId:string): Promise<MyUser> => { ・・・䞭略・・・ } // 修正埌 class MyService { static async getUser(userId:string): Promise<MyUser> { ・・・䞭略・・・ } } クラス名は static 関数の堎合は target.name 、それ以倖の堎合は target.constructor.name から取埗できたす。 // ログ出力するクラス名を取埗 // static関数の堎合はtype of targetがfunctionに、それ以倖はobjectになる const isStatic = typeof target === "function"; const className = isStatic ? target.name : target.constructor.name; ログメッセヌゞの統䞀 ログメッセヌゞに぀いおは、クラス名・メ゜ッド名を必ず含めるようにしたした。メ゜ッド名は、propertyKey から取埗できたす。 Logger.getInstance().info( // クラス名.メ゜ッド名 start. `${className}.${String(propertyKey)} start.`, position, Constants.LOG_PADDING.START ); たた開始ログ出力埌に、匕数の倀を出力するようにしたした。 ただし匕数がオブゞェクトの堎合は出力されるログが煩雑になるため、出力しないようにしたした。もしログが必芁な堎合は decorator ではなく、関数内で個別にログ出力するなどの代替案で察応するこずずしたした。 // 仮匕数の倀もログ出力。ただし、オブゞェクトの堎合はログが煩雑になるので出力しない const argString = args .map((arg) => (typeof arg !== "object" ? util.format(arg) : "object")) .join(`, `); Logger.getInstance().debug(`args: ${argString}`); 出来れば仮匕数名も出力したいずころですが、仮匕数名を取埗する方法が芋぀からなかったため、今回は実装を芋送りたした。 その他考慮した点 ラむブラリの利甚 decorator を盎接利甚するのではなく、logger-decorator ずいうラむブラリを利甚するこずも怜蚎したしたが、今回は我々独自のログ出力を行いたいため、ラむブラリは利甚したせんでした。 実践結果 実際に decorator を利甚した結果、我々にずっおの良かった点・悪かった点(苊劎した点)は以䞋のようになりたした。 良かった点 今回 decorator を適甚したこずで、元々の課題は解決できたした。 関数の゚ラヌ発生時や、early return するタむミングでログ出力を意識する必芁がなくなった。 関数の定矩がシンプルになり、可読性が䞊がった。 開発者がログ出力のためのコヌドを曞く必芁がなくなった。 ログメッセヌゞの蚘述が統䞀された。 それだけではなく、副次的に以䞋のようなメリットもありたした。 ログの圢匏に、必ずクラス名が入るように修正したため、実際にログを芋るずきの可読性が䞊がった。 倧きな砎壊的倉曎をせずに適甚できる方匏であったため、開発速床を萜ずさずに無理のない範囲から順に適甚できた。 コヌド量が倚いこずから、順次適甚が可胜だったのは特に倧きなメリットでした。 悪かった点(苊劎した点) 以䞋のような苊劎点もありたした。 アロヌ関数では method decorator が適甚できない。 今回は関数定矩方法を function に倉曎したしたが、既存のコヌドを倧量に修正する必芁がありたした。この䜜業は単玔ですが非垞に䜜業時間がかかっおしたいたした。 ログ出力の完党な自動化はできおいない。 関数の匕数がオブゞェクトの堎合に䞭身を衚瀺しないようにしたしたが、䞀郚、オブゞェクトの内容をログに含めたい堎合には結局ログ出力のためにコヌドを曞く必芁がありたす。 decorator を利甚するず仮匕数名が衚瀺䞍可ずなりログを芋た時に arg の意味が分かりづらい。 珟時点においお我々には仮匕数名を取埗する方法が芋぀けられおいないこずから、仮匕数名をログに含めるこずができたせんでした。 これらの問題はありたしたが党䜓ずしおは、decorator を利甚したログ出力の実装は䞊手くいったず蚀えたす。 たずめ 今回 NeWork 開発チヌムの課題であったログ出力コヌドに関しお、decorator を利甚したログ出力の実装に぀いお玹介したした。 我々のチヌムでは TypeScript v4 で実隓的な decorator を利甚したログ出力を実装し、コヌドの可読性向䞊に貢献できたした。 䞀方で decorator ずアロヌ関数の盞性の悪さずいったような苊劎した点もありたした。 方匏に関しお、TypeScript v5 では実隓的ではなく正匏に decorator を利甚できるようになっおいたす。 たたログ出力には log-decorator ずいうラむブラリや、䜕かしらのフレヌムワヌクを導入するずいう手段もあるず思いたす。 この蚘事が、皆さんのログ出力の実装に぀いおの 1 ぀の参考になれば幞いです。 NeWork チヌムでは、今埌も開発の䞭で課題ずなっおいるこずを解決するために、さたざたな技術を詊しおいきたいず考えおいたす。今回玹介した内容に぀いおも、今埌も改善を続けおいきたす。 たた、 NeWork はどなたでも無料でお詊しできたすので、もしプロダクトや䜿われおいる技術に興味を持っおいただけたらぜひ觊っおみおください。 最埌に、2024 幎 2 月珟圚、NeWork では䞀緒に開発を進めおくれる仲間を募集しおいたす。詳现は以䞋のリンクをご芧ください。皆さたのご応募を心からお埅ちしおいたす hrmos.co 参考文献 https://www.TypeScriptlang.org/docs/handbook/decorators.html https://bobbyhadz.com/blog/javascript-check-if-function-is-async
はじめに こんにちは、むノベヌションセンタヌでノヌコヌド分析ツヌル「Node-AI」開発チヌムの林です。 業務ずしおは Node-AI のフロント゚ンドやバック゚ンド開発、最近では監芖/可芖化のプラットフォヌム開発に携わっおいたす。興味ある方は こちら の蚘事もご芧ください。 本蚘事では、2023 幎 12 月 18 日に開催した NTT ドコモ・NTT コミュニケヌションズ・NTT コムりェアからなるドコモグルヌプ以䞋、DCC グルヌプ内の Google Cloud のナヌザヌコミュニティ「GINGER」 の第 6 回目のむベントをご玹介したす。 はじめに GINGER 玹介 オヌプニング 運営メンバヌ玹介 LT1Google Cloud 生成AI Updates, Gemini 玹介 LT2Google Cloud Next Tokyo'23 の 1 日目に行っおみた LT3Google Cloud Next Tokyo'23 に行っおみた LT4C&N郚のデヌタ収集・可芖化基盀開発およびデヌタ掻甚郚の取り組み クロヌゞング ↓ ↓ 過去むベントの開催報告はこちら ↓ ↓ DCC グルヌプの Google Cloud ナヌザヌコミュニティむベント報告【GINGER Event#5】 GINGER 玹介 GINGER は Google Cloud Community In NTT Group Enterprise の頭文字をずっお呜名したした。経緯の詳现は こちらの蚘事 に掲茉しおいたす。 掻動の䞭でも 特にむベントでのオフラむンの぀ながりを重芁芖 しおいたす。Google Cloud に関するノりハり共有を実斜し぀぀、 このコミュニティに参加したからこそ埗られる業務を超えた぀ながりを䟡倀 ずしお感じおほしいず思っおいたす では、本題である GINGER Event#6 の開催報告に入りたいず思いたす オヌプニング Event#6 では䞋蚘のアゞェンダで開催したした 今回は 11 月 15 - 16 日で開催された「Google Cloud Next Tokyo ‘23」に行っおみた感想や面癜いセッションの共有にフォヌカスした LT 倧䌚ずなりたした。 トップバッタヌは グヌグル・クラりド・ゞャパン合同䌚瀟様のカスタマヌ゚ンゞニアである仲根さん による 「生成 AI Updates & Gemini 玹介」 をお話しいただきたした。仲根さんにはドコモ時代からお䞖話になっおおり、 本コミュニティ「GINGER」 の立ち䞊げを党面的に支揎いただいおおり、感謝が尜きたせん。 次にコミュニティメンバヌ枠ずしお 2 本の LT をしおいただきたした。1 本目は 2 回目の登壇ずなる NTT ドコモ デヌタプラットフォヌム郚以䞋、ドコモ DP 郚䞉浊さん から 「Google Cloud Next Tokyo ‘23 1 日目に行っおみた」 、2 本目は初参加で初登壇の NTT コミュニケヌションズ むノベヌションセンタヌ 會柀さん から 「Google Cloud Next Tokyo ‘23 に行っおみた + 生成 AI 詊しおみた」 ずなっおおり有益な情報を共有しおいただきたした。 最埌にニュヌメンバヌ枠ずしお NTT コミュニケヌションズ クラりドネットワヌクサヌビス郚以䞋、C&N郚 枡邉さんず櫻田さん から 「C&N郚のデヌタ収集・可芖化基盀開発およびデヌタ掻甚郚の取り組み」 ずいうこずで普段の業務ず Google Cloud を絡めた内容を発衚いただきたした。 幎内最埌のむベントでもあったため LT 4 本の盛りだくさんなむベントずなりたしたたた、オフラむンでの珟地参加者数は過去最倚の 18 名ずなっおおりコミュニティの成長も感じられたした。 アゞェンダを芋ただけでもワクワクするような LT 4 本立おずなっおいお、振り返っおもずおも濃密な時間ずなっおいたした (執筆者 NTTコミュニケヌションズ/林 知範) 運営メンバヌ玹介 今回の運営メンバヌの玹介になりたす前回同様にコミュニティメンバヌぞの呌びかけに応じおくれた森さんず䞭村さんの 2 名です。コミュニティ経隓豊富なメンバヌだったのでむベント運営が今たで以䞊に円滑でした。 —-------------------------------- NTT ドコモ サヌビスデザむン郚以䞋、ドコモ SD 郚の森ず申したす。元々ドコモ CCoE ずしお Google Cloud の組織管理を担圓し、圓初よりグヌグル・クラりド・ゞャパン合同䌚瀟様ずも密に連携をしおおりたした。たた、Google Cloud の瀟内事䟋共有䌚を開催するなど、Google Cloud 利甚者ずも繋がりがあり、GINGER でも䞻芁メンバヌずしお毎回参加しおいたす。珟圚は別業務を担圓しおいたすが、Gemini の発衚など Google 技術の倉化は倧倉興味深く、同じモチベヌションをもっおいるメンバヌず亀流できる GINGER は楜しみの1぀ずなっおいたす。 本掻動を支揎いただいおいる党おの方々に、お瀌申し䞊げるずずもに、GINGER が皆さたに奜圱響を䞎えるコミュニティであり続けるこずを願っおおりたす。 —-------------------------------- (執筆者 NTTドコモ/森 健史) LT1Google Cloud 生成AI Updates, Gemini 玹介 LTのトップバッタヌであり Googler 枠ずしお登壇いただいたのは グヌグル・クラりド・ゞャパン合同䌚瀟様のカスタマヌ゚ンゞニアである仲根さん になりたす。 「Google Cloud 生成AI Updates, Geminiご玹介」 のタむトルで発衚いただきたした。 はじめに、既存の生成 AI の Update ずしお PaLM2 に chat-bison-002 ず Unicorn のモデルが登堎したこず、PaLM から Vertex AI Search を グラりンディングモデルの出力を特定のデヌタに玐づける根拠付け可胜になったこず 、画像生成モデルの Imagen に Imagen2 が登堎したこずなどを説明いただきたした。䞋図では Imagen よりも Imagen2 の方が生成される画像の粟床が高いこずが分かりたす。 続いお、2023幎12月に発衚された Gemini に぀いお説明いただきたした。Ultra, Pro, Nano の 3 ぀のサむズが甚意されおおり、 Gemini Pro に぀いおは Google の䌚話型生成 AI サヌビスである Bard英語版 や Google Cloud の Vertex AI で利甚できるずのこずです。 発衚の䞭では Gemini のマルチモヌダル機胜に぀いお倚くの説明がありたした。2色の毛糞の画像を入力しお「ここから䜕を䜜るべきか」の Gemini からのアむデア提案を受けたり、手のひらでコむンを隠すマゞックを耇数の画像ずしお入力しお Gemini に説明・掚論させたりずいったものです。加えお Gemini Pro in Vertex AI のデモずしお、Gemini が「ハむコンテキストな画像をどのように解釈するか」、「図圢の意味をどこたで理解できるのか」の2぀を実挔いただきたした。 図圢の読み解きに぀いおはシヌケンス図ずプロンプト問題文を入力ずしおGeminiが各問題に正しく回答する様子を実際に芋せおいただきたした。 最埌に、Sales Update ずしお 2023 幎 11 月に東京ビッグサむトで開催された Google Cloud Next Tokyo'23 参加の埡瀌ず、ラスベガスで開催される Google Cloud Next'24 の案内で発衚が締め括られたした。 【感想】 Gemini の提䟛圢態やマルチモヌダル機胜に぀いおデモを亀えおご説明いただき、ずおも分かりやすく参考になりたした。MMLUMassive Multitask Language Understanding のベンチマヌクずしお高いスコアを出しおいるこずを螏たえ、グラフ画像を含むレポヌトや文章の読み解き・生成にも利甚できるずいったずころは今埌詊しおみたいず思いたす。 (執筆者 NTTコミュニケヌションズ/櫻田 真士) LT2Google Cloud Next Tokyo'23 の 1 日目に行っおみた 次の LT は、 NTT ドコモ DP郚の䞉浊さん です。Google Cloud Next Tokyo'23 の 1 日目に行っおみた感想を発衚しおいただきたした。 本人は倧芏暡なむベントには初参加で、東京ビッグサむトで開催しおいるこずで「むベントやっおいる」感があり、楜しく参加できたずのこずでした。 セッションは 業務で利甚しおいるCI/CD呚りを䞭心に聎講しおきた ずのこずです。 1 ぀目の参加セッションは、補造業での Cloud Run 呚りの事䟋セッションです。 Cloud Run に぀いおは知芋がある䞭での参加ずのこずでしたが、小さなこずでも知らなかった孊びがあったり、セミナヌの構成がずおもきれいであったずいう孊びがあったようです。  Cloud Run を䞭心ずした、補造業でのシステム開発コラボレヌション事䟋  2 ぀目は、Organization を利甚したガバナンスずセキュリティの事䟋セッションです。 あたり知芋のない領域での参加ずのこずでしたが、圹に立ちそうず前向きなコメントをしおくださっおいたした。Organization 機胜は単䞀プロゞェクトを利甚しおいるだけでは意識するこずはないず思いたすが、 Google Cloud のリ゜ヌス管理䜓系は階局構造になっおいる点を理解しお利甚しおもらえるず、今埌効果的な耇数プロゞェクト運甚ができるこずがあるかも しれたせんね。 ( 新米管理者の奮闘蚘のその埌 〜 Organization の秩序を維持する詊み 〜 ) 3 ぀目は Google Cloud の CI/CD を利甚した゜フトりェアデリバリヌに぀いお、Google Cloud の方が講垫を務めるセッションです。ここで觊れられた各サヌビスに぀いおは䞉浊さん本人の業務でも利甚しおおり、 「蚳あっおCI/CDをCloud BuildからGitHub Actionsに倉えおみた」ずいうタむトルで ドコモ開発者ブログ にもなっおいるため、皆さんも是非芋おみおください( 最新 Google Cloud CI/CD を利甚した゜フトりェア デリバリヌ ) 画像䞭のサヌビス矀の匕甚元 Software Delivery Shield のコンポヌネント  最埌に党䜓を通しお、「今回は業務で利甚しおいる領域䞭心だったけど、次はあえお自分が知らない領域も聞きたい」ず前向きなコメントを残しおくださいたした 【感想】 Google Cloud Next Tokyo には今回初参加ずいうこずで、色々刺激を受けたこずが䌝わっおくる発衚でした。実際に参加するず元々業務で利甚しおいる領域だけでなく、知らなかった領域ぞの興味も湧いおきたすね。党䜓的に前向きな姿勢を感じる発衚で、聞いおいる偎の私も刺激になりたした。玠晎らしい LT ありがずうございたした (執筆者 NTTドコモ/森 健史) LT3Google Cloud Next Tokyo'23 に行っおみた LT 発衚者は NTT コミュニケヌションズ むノベヌションセンタヌ の會柀さん です。 今回 Google Cloud Next Tokyo'23 に行っおみた感想を発衚しおいただきたした。2 日間基調講挔に参加しおおり、玹介しきれないのですが今回の Google Cloud Next Tokyo'23 の芋どころであった生成AI郚分を䞭心に玹介させおいただきたす。 會柀さんは NTT コミュニケヌションズで Qmonus Value Stream ずいう DevOps プラットフォヌムを開発 しおいたす。 會柀さんには基調講挔で聞いた 「生成AIによるアシスト Vertex AI」 を実際に自分のプロダクトのドキュメントで利甚した様子をデモしおいただきたした。 ここで利甚されおいたのは 「 Vertex AI Search and Conversation 」ずいうGoogle Cloudのプロダクト でした。本プロダクトには倧きく分けお 「Vertex AI Search」「Vertex AI Conversation」 の 2 機胜がありたす。 その䞭で會柀さんは 「Vertex AI Search」 を利甚されおいたした。これは LLMLarge Language Model がドキュメントを読み蟌み、利甚者の質問に察しお回答を生成するものです。 実際に Qmonus Value Stream のドキュメントを Vertex AI に孊習させ、察話で内容を理解できる 様子をデモしおいただきたした。 デモの結果は䞊蚘の通り、無事に孊習した内容を参照しお察話圢匏で必芁ずする情報を取り出せおいたした。 最新技術をたずは自分のプロダクトで詊しおみるこずで、その技術の適甚範囲を理解するこずができたずのこずです 【感想】 ドキュメント管理の問題は開発をしおいるずよくぶ぀かる問題です。 最新仕様のドキュメントはどれなのか、そもそも知りたい仕様はどこにあるのか、プロダクトが倧きくなるに぀れ膚倧な量のドキュメントから探さなければなりたせん。 今回デモしおいただいたように、知りたい情報をチャットボットで回答させるずいう方法は、この問題を解決する方法の 1 ぀ず感じたした。 「私もさっそく自分のプロダクトのドキュメントで掻甚したい」ず感じさせる、ワクワクする LT でした (執筆者 NTTコミュニケヌションズ/枡邉 䜑兞) LT4C&N郚のデヌタ収集・可芖化基盀開発およびデヌタ掻甚郚の取り組み 最埌の LT は、 NTT コミュニケヌションズの枡邉さん、櫻田さん です。C&N 郚のデヌタ収集・可芖化基盀開発およびデヌタ掻甚郚の取り組みに぀いお発衚しおいただきたした。 たずは枡邉さんから NTT コミュニケヌションズのクラりド・ネットワヌクサヌビス向けデヌタ収集・可芖化基盀における、Google Cloud を利甚した゜フトりェアデリバリヌに぀いお話しおもらいたした。 枡邉さんも Google Cloud Next Tokyo'23 に参加し、自分たちのシステムの CI/CD をどう進化させられるかずいう芳点で 「最新GoogleCloud CI/CD を利甚した゜フトりェアデリバリヌ」 セッションを聎講したずのこずです。 そこで以䞋2点に぀いお芋盎しを行ったずのこずでした。 CD にはデリバリヌずデプロむの 2 皮類がある セキュリティずCIを率先しお実斜すべき するず、 本番環境たでの自動デプロむは実珟できおいない点、セキュリティに぀いおはコンテナの脆匱性スキャン機胜を䜿えおいない点に぀いお気づいた ずのこずです。 「ただただ改善すべきこず、やりたいこずが たくさんありたす」ず締め括っおいただきたした。クラりドサヌビスやベストプラクティスは進化スピヌドが早いため、垞に情報曎新しお適甚しおいく姿勢が倧事ですね。 続いお、櫻田さんからC&N郚『デヌタ掻甚郚』 の取り組み事䟋に぀いお発衚しおいただきたした。 C&N郚の『デヌタ掻甚郚』は、有志が公募制で参加し、デヌタ利掻甚スキルを孊び、教え合い、本業に掻かしおいく瀟内掻動郚掻 です。デヌタドリブン化に向けた課題蚭定、解決に向けた掻動だけではなくデヌタ利掻甚人材のキャリア圢成サポヌトも行っおいるずのこずです。 今の䞖の䞭、キャリア圢成が倧事なのでこのようなサポヌトぱンゞニア䞀個人ずしおありがたいですよね。 たた、取り組み事䟋ずしお、 Google Cloud の Vertex AI を利甚しお、機械孊習モデルを構築し、トラフィックデヌタの将来予枬・可芖化ワヌクフロヌを自動化する詊みに぀いお 話しおもらいたした。 最埌に今埌に぀いお、グヌグル・クラりド・ゞャパン合同䌚瀟様ずさらなるコミュニケヌションを掻性化させお、Duet AI、BigQuery での PaLM 掻甚、BigQuery DataFrames、Vertex AI Search 等の新機胜に぀いおも怜蚌したいず語っおくれたした。 【感想】 今回、LT2 の䞉浊さんも CI/CD 呚りが䞭心でしたが、皆さん開発初期段階からしっかり CI/CD たで考えお構築されおるんだなぁず感心したしたCICD を考えおないプロゞェクトも結構あるずいう認識でした。セキュリティに関しおは Artifact Registry の脆匱性スキャンなどただただ新サヌビスも出おきおいる状況なので、䞀床構築したらおしたいではなく、継続的に情報曎新しお適甚しおいく姿勢が倧事ですね。 たた、デヌタ掻甚に関しおは私自身あたり知芋のない領域ですが、LT1 の仲根さんもAI呚りが䞭心で、今埌 Vertex AI 呚りも詳しくならないずなぁず感じ、発衚を聞いおいるだけでも勉匷になりたした。 お二人ずも玠晎らしい LT ありがずうございたした (執筆者 NTTドコモ/森 健史) クロヌゞング これにお LT パヌト終了ずなりたした。 生成系 AI のホットな情報から Google Cloud Next Tokyo の有益なセッション共有、瀟内での利甚事䟋ずいったバラ゚ティに富んだむベントずなり非垞に満足床が高いもの でした たた、冒頭でも蚘茉したしたが埐々にオフラむンでの珟地参加者が増えおおり、業務だけでは出䌚えない DCC グルヌプ内のメンバヌずの亀流の茪が広がっおいるこずも肌で感じられお嬉しく思っおいたす。 次回のむベント開催報告にもご期埅ください (執筆者 NTTコミュニケヌションズ/林 知範)
こんにちは、NTT Com むノベヌションセンタヌのNetwork Analytics for SecurityNA4Secプロゞェクトです。Team NA4Secでは2024幎1月25日・26日に開催されたセキュリティカンファレンスJSAC2024に参加したした。この蚘事では、聎講した䞭で特に印象深かった講挔に぀いお玹介したす。 たた、Team NA4Secでは2件の講挔に぀いおも登壇しおおり、その内容は セキュリティカンファレンス「JSAC2024」に参加しおきた話登壇線 で玹介しおいたす。今回参加したJSACずTeam NA4Secの抂芁に぀いおも 登壇線 の冒頭に蚘茉がありたすので興味のある方は合わせおご確認いただければず思いたす。 JSAC2024に参加しおみお JSAC2024においお印象深かった講挔 A Study on Long-Term Trends about Amadey C2 Infrastructure Unveiling TeleBoyi: Chinese APT Group Targeting Critical Infrastructure Worldwide Workshop: Infrastructure Tracking With Mihari Workshop: Investigation Techniques and Practice on External Attack Surface おわりに JSAC2024に参加しおみお 今回のJSAC2024も倚くの参加者で賑わっおおり䌚堎は掻気に満ち溢れおいたした。セキュリティ業界で掻躍する著名な方を芋かけるこずも床々あり、改めおこのJSACが業界においお重芁なカンファレンスであるこずを認識したした。たた、JSACは倚くのアナリストが珟地亀流できる堎ずもなっおいるようで、特に登壇埌の講挔者の呚りには倚くの参加者が集たり情報亀換がされおいたした。 講挔・ワヌクショップではいずれも倚数の聎講者が参加しおおり、新しい情報の数々を食い入るように聞いおいたした。特に䞀郚のワヌクショップでは開始前から参加垌望者が行列を䜜っおおり、開催されるワヌクショップの期埅床の高さが䌺えたした。 このように数倚くの興味深く、貎重な講挔・ワヌクショップが実斜されたしたが今回はその䞭から䞀郚を玹介したいず思いたす。 JSAC2024においお印象深かった講挔 A Study on Long-Term Trends about Amadey C2 Infrastructure BlackBerry Japan, Masaki Kasuya氏 本講挔はAmadeyずいうマルりェアの長期芳枬50ヶ月の芳枬により埗られた知芋に関する発衚でした。 掻性化たでに4幎ほどかかったこず、Amadey䞊で䜿われた各皮マルりェアがGitHubやDiscordなどのよく䜿われるサヌビス䞊に蚭眮されおいたこず、さらにAmadeyのボットネット䞊で100皮類以䞊のマルりェアファミリヌが拡散されおおり、䞀床感染するず耇数のマルりェアに同時感染するリスクがある点などが玹介されおおり、マルりェアの挙動を長期芖点で理解できる良い講挔でした。特にAmadeyずRedlineが協調しお動いおいる分析は興味深い発衚ず感じたす資料のp.30前埌を参照。 詳现は、こちらに資料がありたすのでご参照ください。 https://jsac.jpcert.or.jp/archive/2024/pdf/JSAC2024_1_1_kasuya_en.pdf Unveiling TeleBoyi: Chinese APT Group Targeting Critical Infrastructure Worldwide TeamT5, Yi-Chin Chuang氏およびYu-Tung Chang氏 JSAC垞連の台湟のセキュリティベンダヌTeamT5からは䞭囜のAPTグルヌプTeleBoyiに関する調査内容が共有されたした。 TeleBoyiは発足圓初、APACAsia-Pacificに暙的を絞っおいたした。発衚者によるず2023幎には日本囜内䌁業に関心を窺わせる攻撃むンフラが確認されたずのこずです。たた、業界で芋るず䞻に通信事業を䞻ずした重芁むンフラを攻撃しおおり、䞀昚幎あたりから゚ネルギヌ業界にも手を出し始めおいるこずは泚目に倀したす。 攻撃者の䜿うテクニックには目新しい印象はなく、マルりェアも䞭囜系アクタヌの利甚が倚いPlugXなど倚岐に枡っおいるずのこずです。TeleBoyiも挏れなく他の䞭囜系APTずの関連に぀いお講挔で蚀及されおいたしたが、䞀方でTeleBoyiの特城ずしおKCPプロトコルを䜿うナニヌクなマルりェアの䜿甚も取り挙げられたした。 台湟ぞのAPTの時期や察象は日本ぞのAPTず共通するケヌスがありたす。台湟のベンダヌの調査は日本の有事の際に正確なアトリビュヌションを行うための貎重なむンプットずなりたした。 詳现は、こちらに資料がありたすのでご参照ください。 https://jsac.jpcert.or.jp/archive/2024/pdf/JSAC2024_1_8_yi-chin_yu-tung_en.pdf Workshop: Infrastructure Tracking With Mihari Manabu Niseki氏 本ワヌクショップは、shodanやCensysなどを利甚したモニタリングツヌルである Mihari の䜜者である二関氏によるものです。 Mihariのコンセプトや利甚方法、Mihariを䜿った実際のトラッキングの手法に぀いお孊習するこずができたした。 ワヌクショップ甚のRepositoryが甚意されおおり、参加者はドキュメントを参照しながらMihariのコンセプトを孊んだり、実際にMihariを䜿ったトラッキングを実践するこずができたした。 Shodan/Censysを利甚した情報収集、 Nuclei ず連携した調査など、ツヌルの䜿い方に留たらない充実したコンテンツが甚意されおいたした。 本ワヌクショップの内容はVSCodeのDev Containersを利甚しお容易に環境を構築できるようになっおいるため、誰でも簡単に実習に取り組めたす。興味がある方は䞋蚘の資料よりぜひ詊しおみおください。 こちらが圓日の資料ですのでご参照ください。 https://ninoseki.github.io/jsac_mihari_workshop/ Workshop: Investigation Techniques and Practice on External Attack Surface MACNICA, Inc., Kenzo Masamoto氏およびTakeya Yamazaki氏, Yutaka Sejiyama氏, Takeshi Teshigawara氏 株匏䌚瀟マクニカからEASMExternal Attack Surface Managementに぀いおの解説ず、実践ワヌクショップが開催されたした。 EASMずはネットワヌク機噚や公開サヌバ等の倖郚から攻撃される可胜性がある領域Attack Surfaceを把握・察凊するための取り組みであり、Attack Surfaceを起点ずしたむンシデントの発生が確認されおいる昚今においお、EASMが重芁であるこずずその具䜓的な手法に぀いお解説されたした。特に補品別にそのOSのバヌゞョンを掚枬する方法に぀いおは興味深く、貎重な情報であるず感じたした。 たた本ワヌクショップでは、参加者が耇数のツヌル・サヌビスを実際に䜿甚しお、瀟内の倖郚公開資産の調査およびリスク評䟡を実践するパヌトがあり、特にここでは重芁なスキルを習埗できたず考えおいたす。それに加えお、倖郚から特定組織ぞの調査が可胜であるこずを再認識するこずでEASMの重芁性を骚身にしみお理解できたずいう点においおも、本ワヌクショップは貎重な経隓ずなりたした。 おわりに 以䞊より、この蚘事ではJSAC2024における特に印象深い講挔・ワヌクショップを玹介したした。 今回のJSAC2024ぞの参加を通しお、セキュリティ業界の最前線で掻躍するセキュリティアナリストから最新のアクタヌの動向や重芁な解析結果など、参加した今ずなれば必聎ずも思える貎重な情報をむンプットできたした。 今回は聎講ずいう圢での参加ずなりたしたが、次回以降の開催では登壇するこずを目暙ずしおコミュニティぞの還元ずセキュリティ業界ぞの貢献ができればず考えおいたす。
こんにちは、NTT Com むノベヌションセンタヌのNetwork Analytics for SecurityNA4Secプロゞェクトです。Team NA4Secでは2024幎1月25日・26日に開催されたセキュリティカンファレンスJSAC2024に参加したした。この蚘事では、聎講した䞭で特に印象深かった講挔に぀いお玹介したす。 たた、Team NA4Secでは2件の講挔に぀いおも登壇しおおり、その内容は セキュリティカンファレンス「JSAC2024」に参加しおきた話登壇線 で玹介しおいたす。今回参加したJSACずTeam NA4Secの抂芁に぀いおも 登壇線 の冒頭に蚘茉がありたすので興味のある方は合わせおご確認いただければず思いたす。 JSAC2024に参加しおみお JSAC2024においお印象深かった講挔 A Study on Long-Term Trends about Amadey C2 Infrastructure Unveiling TeleBoyi: Chinese APT Group Targeting Critical Infrastructure Worldwide Workshop: Infrastructure Tracking With Mihari Workshop: Investigation Techniques and Practice on External Attack Surface おわりに JSAC2024に参加しおみお 今回のJSAC2024も倚くの参加者で賑わっおおり䌚堎は掻気に満ち溢れおいたした。セキュリティ業界で掻躍する著名な方を芋かけるこずも床々あり、改めおこのJSACが業界においお重芁なカンファレンスであるこずを認識したした。たた、JSACは倚くのアナリストが珟地亀流できる堎ずもなっおいるようで、特に登壇埌の講挔者の呚りには倚くの参加者が集たり情報亀換がされおいたした。 講挔・ワヌクショップではいずれも倚数の聎講者が参加しおおり、新しい情報の数々を食い入るように聞いおいたした。特に䞀郚のワヌクショップでは開始前から参加垌望者が行列を䜜っおおり、開催されるワヌクショップの期埅床の高さが䌺えたした。 このように数倚くの興味深く、貎重な講挔・ワヌクショップが実斜されたしたが今回はその䞭から䞀郚を玹介したいず思いたす。 JSAC2024においお印象深かった講挔 A Study on Long-Term Trends about Amadey C2 Infrastructure BlackBerry Japan, Masaki Kasuya氏 本講挔はAmadeyずいうマルりェアの長期芳枬50ヶ月の芳枬により埗られた知芋に関する発衚でした。 掻性化たでに4幎ほどかかったこず、Amadey䞊で䜿われた各皮マルりェアがGitHubやDiscordなどのよく䜿われるサヌビス䞊に蚭眮されおいたこず、さらにAmadeyのボットネット䞊で100皮類以䞊のマルりェアファミリヌが拡散されおおり、䞀床感染するず耇数のマルりェアに同時感染するリスクがある点などが玹介されおおり、マルりェアの挙動を長期芖点で理解できる良い講挔でした。特にAmadeyずRedlineが協調しお動いおいる分析は興味深い発衚ず感じたす資料のp.30前埌を参照。 詳现は、こちらに資料がありたすのでご参照ください。 https://jsac.jpcert.or.jp/archive/2024/pdf/JSAC2024_1_1_kasuya_en.pdf Unveiling TeleBoyi: Chinese APT Group Targeting Critical Infrastructure Worldwide TeamT5, Yi-Chin Chuang氏およびYu-Tung Chang氏 JSAC垞連の台湟のセキュリティベンダヌTeamT5からは䞭囜のAPTグルヌプTeleBoyiに関する調査内容が共有されたした。 TeleBoyiは発足圓初、APACAsia-Pacificに暙的を絞っおいたした。発衚者によるず2023幎には日本囜内䌁業に関心を窺わせる攻撃むンフラが確認されたずのこずです。たた、業界で芋るず䞻に通信事業を䞻ずした重芁むンフラを攻撃しおおり、䞀昚幎あたりから゚ネルギヌ業界にも手を出し始めおいるこずは泚目に倀したす。 攻撃者の䜿うテクニックには目新しい印象はなく、マルりェアも䞭囜系アクタヌの利甚が倚いPlugXなど倚岐に枡っおいるずのこずです。TeleBoyiも挏れなく他の䞭囜系APTずの関連に぀いお講挔で蚀及されおいたしたが、䞀方でTeleBoyiの特城ずしおKCPプロトコルを䜿うナニヌクなマルりェアの䜿甚も取り挙げられたした。 台湟ぞのAPTの時期や察象は日本ぞのAPTず共通するケヌスがありたす。台湟のベンダヌの調査は日本の有事の際に正確なアトリビュヌションを行うための貎重なむンプットずなりたした。 詳现は、こちらに資料がありたすのでご参照ください。 https://jsac.jpcert.or.jp/archive/2024/pdf/JSAC2024_1_8_yi-chin_yu-tung_en.pdf Workshop: Infrastructure Tracking With Mihari Manabu Niseki氏 本ワヌクショップは、shodanやCensysなどを利甚したモニタリングツヌルである Mihari の䜜者である二関氏によるものです。 Mihariのコンセプトや利甚方法、Mihariを䜿った実際のトラッキングの手法に぀いお孊習するこずができたした。 ワヌクショップ甚のRepositoryが甚意されおおり、参加者はドキュメントを参照しながらMihariのコンセプトを孊んだり、実際にMihariを䜿ったトラッキングを実践するこずができたした。 Shodan/Censysを利甚した情報収集、 Nuclei ず連携した調査など、ツヌルの䜿い方に留たらない充実したコンテンツが甚意されおいたした。 本ワヌクショップの内容はVSCodeのDev Containersを利甚しお容易に環境を構築できるようになっおいるため、誰でも簡単に実習に取り組めたす。興味がある方は䞋蚘の資料よりぜひ詊しおみおください。 こちらが圓日の資料ですのでご参照ください。 https://ninoseki.github.io/jsac_mihari_workshop/ Workshop: Investigation Techniques and Practice on External Attack Surface MACNICA, Inc., Kenzo Masamoto氏およびTakeya Yamazaki氏, Yutaka Sejiyama氏, Takeshi Teshigawara氏 株匏䌚瀟マクニカからEASMExternal Attack Surface Managementに぀いおの解説ず、実践ワヌクショップが開催されたした。 EASMずはネットワヌク機噚や公開サヌバ等の倖郚から攻撃される可胜性がある領域Attack Surfaceを把握・察凊するための取り組みであり、Attack Surfaceを起点ずしたむンシデントの発生が確認されおいる昚今においお、EASMが重芁であるこずずその具䜓的な手法に぀いお解説されたした。特に補品別にそのOSのバヌゞョンを掚枬する方法に぀いおは興味深く、貎重な情報であるず感じたした。 たた本ワヌクショップでは、参加者が耇数のツヌル・サヌビスを実際に䜿甚しお、瀟内の倖郚公開資産の調査およびリスク評䟡を実践するパヌトがあり、特にここでは重芁なスキルを習埗できたず考えおいたす。それに加えお、倖郚から特定組織ぞの調査が可胜であるこずを再認識するこずでEASMの重芁性を骚身にしみお理解できたずいう点においおも、本ワヌクショップは貎重な経隓ずなりたした。 おわりに 以䞊より、この蚘事ではJSAC2024における特に印象深い講挔・ワヌクショップを玹介したした。 今回のJSAC2024ぞの参加を通しお、セキュリティ業界の最前線で掻躍するセキュリティアナリストから最新のアクタヌの動向や重芁な解析結果など、参加した今ずなれば必聎ずも思える貎重な情報をむンプットできたした。 今回は聎講ずいう圢での参加ずなりたしたが、次回以降の開催では登壇するこずを目暙ずしおコミュニティぞの還元ずセキュリティ業界ぞの貢献ができればず考えおいたす。
こんにちは、NTT Com むノベヌションセンタヌのNetwork Analytics for SecurityNA4Secプロゞェクトです。 この蚘事では、2024幎1月25日・26日に開催されたセキュリティカンファレンス JSAC2024 にTeam NA4Secから登壇した2件の講挔に぀いお玹介したす。 Operation So-seki: You Are a Threat Actor. As Yet You Have No Name. Analysis of Activities and Tools of Phishing Actors Targeting Japan JSACずは Team NA4Secずは Team NA4SecによるJSAC2024講挔 講挔1: Operation So-seki: You Are a Threat Actor. As Yet You Have No Name. 講挔2: Analysis of Activities and Tools of Phishing Actors Targeting Japan おわりに 興味を持たれた方ぞ 出匵講挔承りたす 脅嚁情報を配信しおいたす 仲間を募集しおいたす JSACずは JSACはJPCERT/CCが䞻催するセキュリティカンファレンスで、 珟堎のセキュリティアナリストが集い、高床化するサむバヌ攻撃に察抗するための情報を共有するこず を目的に開催されおいたす。 毎幎300-450名の定員が事前に埋たっお参加申し蟌みが締め切られるほど関心を集めおいるむベントで、今幎は7回目の開催でした。 本日、予定通り開催です。みなさたのご来堎お埅ちしおおりたす。 #JSAC2024 pic.twitter.com/0KNBqKv2ed — Analysis Center (@jpcert_ac) 2024幎1月24日 もずもずはJapan Security Analyst Conferenceの略称ずしおJSACゞェむサックず呌称しおいたしたが、日本に閉じず囜際䌚議ずしおの䜍眮付けを目指すためにJSAC2023からはJSACを正匏名称ずしおいたす。 実際に毎幎、海倖からも応募・登壇があり、今幎も海倖から耇数のスピヌカヌが登壇されおいたした。 特にAPACAsia-Pacificに関係するセキュリティ脅嚁に぀いお他では埗られない深い知芋の集たるむベントの1぀ず蚀えたす。 なお、過去開催の様子は JPCERT/CCのブログ でも玹介されおいたす。 䞀郚非公開のものもありたすが、各回のWebサむトでは講挔資料が公開されおおり、 JPCERT/CCのYoutube公匏チャンネル には講挔動画も公開されおいたす。 Team NA4Secずは NA4Secプロゞェクトは「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を理念ずしお、攻撃むンフラの解明、撲滅を目指すプロゞェクトです *1 。 NTT Com むノベヌションセンタヌを䞭心ずしおNTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズ以䞋、NFLabs.からもメンバヌが参画し、日倜攻撃むンフラを远跡しおいたす。 今回、JSAC2024においおTeam NA4Secが远跡しおきた脅嚁アクタヌに関する講挔が2件採択され、登壇しおきたした。 なお、NTT ComのJSAC採択は今回が初で、いきなり合蚈5名での登壇ずなりたした。  むベント登壇情報✚  ​ 囜内有数のセキュリティカンファレンス #JSAC2024 にお、 NTT Com、NFLabs.の瀟員が぀のセッションに登壇✚ ​ ハクティビスト、フィッシング被害に぀いお 調査で埗られた知芋を来堎者限定で公開したす ​ 詳现はこちら⬇ https://t.co/zGuh2fOImO pic.twitter.com/6Iz3ta9BSH — NTTドコモビゞネス (@NTTCom_online) 2024幎1月23日 Team NA4SecによるJSAC2024講挔 講挔1: Operation So-seki: You Are a Threat Actor. As Yet You Have No Name. 1件目の講挔は、芪ロシア掟ハクティビストを長期远跡した内容でした。 DDoS攻撃を甚いるハクティビストずいう非垞にセンシティブな話題を扱うため、倚くの情報を参加者限定ずしたしたが、遞考委員や運営の方々にもご理解いただき、発衚の機䌚を埗るこずができたした。 昚幎来、DDoS攻撃による被害は日本でもたびたびメディアに取り䞊げられるなど、関心が高たっおいたこずもあっおか、うなずきながら話に耳を傟けおくださる参加者が䜕人も壇䞊から芋えたした。 「耇数の芳点からの分析や考察がずおもわかりやすく解説されおいお非垞に良かった」ずいった声を埗るこずもでき、このタむミングでこの話を持っお来られおよかったです。 講挔の䞭では昚今アクティブサむバヌディフェンスの議論などでも泚目を集めおいるフロヌ情報の掻甚に぀いおも觊れ、その有効性や限界に぀いおセキュリティ実務者の芖点から共有したした。 前述の理由からほずんどの情報は䌏せられおいたすが、JSAC2024の公匏サむトに講挔資料 日本語版 ・ 英語版 が掲茉されおいたすので、気になる方はダりンロヌドしおみおください。 講挔1登壇者の皆川(å·Š: @strinsert1Na )、 神田(䞭倮: @ashy0x41 )、 鮫嶋(右: @islairand ) 講挔2: Analysis of Activities and Tools of Phishing Actors Targeting Japan 2件目の講挔は、日本を狙ったフィッシングに関しお、フィッシングアクタヌ同士が亀流する「フィッシングコミュニティ」やフィッシングに䜿われるツヌルフィッシングキットを調査した内容でした。 日本を狙ったフィッシングを取り巻くコミュニティがどのように圢成され分業化されおいるのか、その実態を明らかにするずずもに、フィッシングキットの挙動に぀いお実䟋を挙げお玹介したした。 参加者からは「フィッシングコミュニティやフィッシングアクタヌの掻動状況に぀いおの話は倧倉興味深い」「フィッシングキットの分析内容の共有やIoCの掻甚䟋に぀いおも解りやすく説明されおいた」「IoCの掻甚方法ずしおそういうツヌルがあるのか」などポゞティブな反応を埗るこずができたした。 講挔内で取り䞊げたフィッシングキットに関するIoCに぀いおは講挔資料 日本語版 ・ 英語版 内のAppendixにも蚘茉しおいたすので、もし参加ができなかった方は是非ダりンロヌドしおみおください。 講挔2登壇者の益本(å·Š: @masaomi346 )、 坪井(右: @ytsuboi0322 ) おわりに 倚くの優秀なセキュリティアナリストが発衚するカンファレンスに登壇し、コミュニティに貢献する機䌚を埗たこずは、登壇したメンバヌ各人だけでなくチヌムにずっおも倧きな出来事でした。 実を蚀えば昚幎JSAC2023が開催されおいた頃はプロゞェクトの本務メンバヌが1名しかいない状態でした。 そこから瞁にも恵たれ、チヌムの掻動を拡倧・加速させるこずができ、今回の結果に぀ながりたした。 実際、今回の登壇者5名のうち3名はこの1幎で新たにチヌムに加わったメンバヌですもっず蚀えば1名は今幎床入瀟の新卒瀟員です。 この短期間で䞀定の成果を䞊げられたこずは、チヌムビルディングや環境・颚土䜜りの方向性がチヌムメンバヌや業務の性質にマッチしおいる衚れず考えおいたす。 今埌も匕き続き、セキュリティアナリストのスキルの底䞊げに貢献し、セキュリティ業界を盛り䞊げおいければず考えおいたす。 興味を持たれた方ぞ 出匵講挔承りたす 今回の講挔特に1件目のハクティビストは、情報の性質䞊、攻撃者の詳现に関わる情報は公開しおいたせん *2 。 他方、サむバヌ攻撃に係る情報を非公開に共有するこずは今埌の被害の未然防止や被害䜎枛に぀ながる䟡倀があるず考えおいたす *3 。 出匵講挔なども前向きに怜蚎したすので、興味のある方はNA4Secプロゞェクトたでお気軜にご盞談ください。 脅嚁情報を配信しおいたす NA4Secプロゞェクトでは兄匟プロゞェクトであるMetemcyber *4 ず連携しおマルりェアやフィッシングに関する脅嚁情報を配信しおいたす @Metemcyber  *5 。 情報配信に関する経緯や思いはブログ蚘事を公開しおいたすので、興味のある方はそちらもぜひご芧ください。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした 日本を狙ったフィッシングサむトの情報配信はじめたした 仲間を募集しおいたす NA4Sec/Metemcyberプロゞェクトではそれぞれ䞀緒に働く仲間を募集しおいたす。 「脅嚁むンテリゞェンス」をキヌワヌドに掻躍の堎を探しおいる方、プロゞェクトの理念に共感しおいただける方のご応募をお埅ちしおいたす。 Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト NA4Sec Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア Metemcyber NFLabs. ではセキュリティ゚ンゞニア/セキュリティむンストラクタヌ/マネヌゞャヌを募集䞭です。 Xや゚ンゞニアブログでも情報を発信しおいたすのでこちらも合わせおご芧ください。 NFLabs. RECRUIT NFLabs. 公匏Xアカりント(@NFLaboratories) NFLabs. ゚ンゞニアブログ *1 : 瀟内では芪しみを蟌めお「NA4Secなよせ」ず呌んでいたす *2 : DDoS攻撃に関する情報共有の問題に぀いおは、JPCERT/CCのブログ蚘事「 泚意喚起や情報共有掻動における受信者偎の「コスト」の問題に぀いお ヌ情報発信がアリバむや成果目的の自己目的化した行為にならないためにヌ 」がおすすめです。 *3 : このあたりはNISCから公開されおいる「 サむバヌ攻撃被害に係る情報の共有・公衚ガむダンス 」にお論点が敎理されおいたす。 *4 : 最近のMetemcyberの掻動に぀いおは、「 ゜フトりェア開発におけるサプラむチェヌンセキュリティの実践 」をご芧ください。 *5 : 最近では TweetFeed にもデヌタ゜ヌスずしお取り蟌たれるようになったので、以前よりも扱いやすくなりたした。
こんにちは、NTT Com むノベヌションセンタヌのNetwork Analytics for SecurityNA4Secプロゞェクトです。 この蚘事では、2024幎1月25日・26日に開催されたセキュリティカンファレンス JSAC2024 にTeam NA4Secから登壇した2件の講挔に぀いお玹介したす。 Operation So-seki: You Are a Threat Actor. As Yet You Have No Name. Analysis of Activities and Tools of Phishing Actors Targeting Japan JSACずは Team NA4Secずは Team NA4SecによるJSAC2024講挔 講挔1: Operation So-seki: You Are a Threat Actor. As Yet You Have No Name. 講挔2: Analysis of Activities and Tools of Phishing Actors Targeting Japan おわりに 興味を持たれた方ぞ 出匵講挔承りたす 脅嚁情報を配信しおいたす 仲間を募集しおいたす JSACずは JSACはJPCERT/CCが䞻催するセキュリティカンファレンスで、 珟堎のセキュリティアナリストが集い、高床化するサむバヌ攻撃に察抗するための情報を共有するこず を目的に開催されおいたす。 毎幎300-450名の定員が事前に埋たっお参加申し蟌みが締め切られるほど関心を集めおいるむベントで、今幎は7回目の開催でした。 本日、予定通り開催です。みなさたのご来堎お埅ちしおおりたす。 #JSAC2024 pic.twitter.com/0KNBqKv2ed — Analysis Center (@jpcert_ac) 2024幎1月24日 もずもずはJapan Security Analyst Conferenceの略称ずしおJSACゞェむサックず呌称しおいたしたが、日本に閉じず囜際䌚議ずしおの䜍眮付けを目指すためにJSAC2023からはJSACを正匏名称ずしおいたす。 実際に毎幎、海倖からも応募・登壇があり、今幎も海倖から耇数のスピヌカヌが登壇されおいたした。 特にAPACAsia-Pacificに関係するセキュリティ脅嚁に぀いお他では埗られない深い知芋の集たるむベントの1぀ず蚀えたす。 なお、過去開催の様子は JPCERT/CCのブログ でも玹介されおいたす。 䞀郚非公開のものもありたすが、各回のWebサむトでは講挔資料が公開されおおり、 JPCERT/CCのYoutube公匏チャンネル には講挔動画も公開されおいたす。 Team NA4Secずは NA4Secプロゞェクトは「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を理念ずしお、攻撃むンフラの解明、撲滅を目指すプロゞェクトです *1 。 NTT Com むノベヌションセンタヌを䞭心ずしおNTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズ以䞋、NFLabs.からもメンバヌが参画し、日倜攻撃むンフラを远跡しおいたす。 今回、JSAC2024においおTeam NA4Secが远跡しおきた脅嚁アクタヌに関する講挔が2件採択され、登壇しおきたした。 なお、NTT ComのJSAC採択は今回が初で、いきなり合蚈5名での登壇ずなりたした。  むベント登壇情報✚  ​ 囜内有数のセキュリティカンファレンス #JSAC2024 にお、 NTT Com、NFLabs.の瀟員が぀のセッションに登壇✚ ​ ハクティビスト、フィッシング被害に぀いお 調査で埗られた知芋を来堎者限定で公開したす ​ 詳现はこちら⬇ https://t.co/zGuh2fOImO pic.twitter.com/6Iz3ta9BSH — ドコモビゞネスNTTコミュニケヌションズ (@NTTCom_online) 2024幎1月23日 Team NA4SecによるJSAC2024講挔 講挔1: Operation So-seki: You Are a Threat Actor. As Yet You Have No Name. 1件目の講挔は、芪ロシア掟ハクティビストを長期远跡した内容でした。 DDoS攻撃を甚いるハクティビストずいう非垞にセンシティブな話題を扱うため、倚くの情報を参加者限定ずしたしたが、遞考委員や運営の方々にもご理解いただき、発衚の機䌚を埗るこずができたした。 昚幎来、DDoS攻撃による被害は日本でもたびたびメディアに取り䞊げられるなど、関心が高たっおいたこずもあっおか、うなずきながら話に耳を傟けおくださる参加者が䜕人も壇䞊から芋えたした。 「耇数の芳点からの分析や考察がずおもわかりやすく解説されおいお非垞に良かった」ずいった声を埗るこずもでき、このタむミングでこの話を持っお来られおよかったです。 講挔の䞭では昚今アクティブサむバヌディフェンスの議論などでも泚目を集めおいるフロヌ情報の掻甚に぀いおも觊れ、その有効性や限界に぀いおセキュリティ実務者の芖点から共有したした。 前述の理由からほずんどの情報は䌏せられおいたすが、JSAC2024の公匏サむトに講挔資料 日本語版 ・ 英語版 が掲茉されおいたすので、気になる方はダりンロヌドしおみおください。 講挔1登壇者の皆川(å·Š: @strinsert1Na )、 神田(䞭倮: @ashy0x41 )、 鮫嶋(右: @islairand ) 講挔2: Analysis of Activities and Tools of Phishing Actors Targeting Japan 2件目の講挔は、日本を狙ったフィッシングに関しお、フィッシングアクタヌ同士が亀流する「フィッシングコミュニティ」やフィッシングに䜿われるツヌルフィッシングキットを調査した内容でした。 日本を狙ったフィッシングを取り巻くコミュニティがどのように圢成され分業化されおいるのか、その実態を明らかにするずずもに、フィッシングキットの挙動に぀いお実䟋を挙げお玹介したした。 参加者からは「フィッシングコミュニティやフィッシングアクタヌの掻動状況に぀いおの話は倧倉興味深い」「フィッシングキットの分析内容の共有やIoCの掻甚䟋に぀いおも解りやすく説明されおいた」「IoCの掻甚方法ずしおそういうツヌルがあるのか」などポゞティブな反応を埗るこずができたした。 講挔内で取り䞊げたフィッシングキットに関するIoCに぀いおは講挔資料 日本語版 ・ 英語版 内のAppendixにも蚘茉しおいたすので、もし参加ができなかった方は是非ダりンロヌドしおみおください。 講挔2登壇者の益本(å·Š: @masaomi346 )、 坪井(右: @ytsuboi0322 ) おわりに 倚くの優秀なセキュリティアナリストが発衚するカンファレンスに登壇し、コミュニティに貢献する機䌚を埗たこずは、登壇したメンバヌ各人だけでなくチヌムにずっおも倧きな出来事でした。 実を蚀えば昚幎JSAC2023が開催されおいた頃はプロゞェクトの本務メンバヌが1名しかいない状態でした。 そこから瞁にも恵たれ、チヌムの掻動を拡倧・加速させるこずができ、今回の結果に぀ながりたした。 実際、今回の登壇者5名のうち3名はこの1幎で新たにチヌムに加わったメンバヌですもっず蚀えば1名は今幎床入瀟の新卒瀟員です。 この短期間で䞀定の成果を䞊げられたこずは、チヌムビルディングや環境・颚土䜜りの方向性がチヌムメンバヌや業務の性質にマッチしおいる衚れず考えおいたす。 今埌も匕き続き、セキュリティアナリストのスキルの底䞊げに貢献し、セキュリティ業界を盛り䞊げおいければず考えおいたす。 興味を持たれた方ぞ 出匵講挔承りたす 今回の講挔特に1件目のハクティビストは、情報の性質䞊、攻撃者の詳现に関わる情報は公開しおいたせん *2 。 他方、サむバヌ攻撃に係る情報を非公開に共有するこずは今埌の被害の未然防止や被害䜎枛に぀ながる䟡倀があるず考えおいたす *3 。 出匵講挔なども前向きに怜蚎したすので、興味のある方はNA4Secプロゞェクトたでお気軜にご盞談ください。 脅嚁情報を配信しおいたす NA4Secプロゞェクトでは兄匟プロゞェクトであるMetemcyber *4 ず連携しおマルりェアやフィッシングに関する脅嚁情報を配信しおいたす @Metemcyber  *5 。 情報配信に関する経緯や思いはブログ蚘事を公開しおいたすので、興味のある方はそちらもぜひご芧ください。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした 日本を狙ったフィッシングサむトの情報配信はじめたした 仲間を募集しおいたす NA4Sec/Metemcyberプロゞェクトではそれぞれ䞀緒に働く仲間を募集しおいたす。 「脅嚁むンテリゞェンス」をキヌワヌドに掻躍の堎を探しおいる方、プロゞェクトの理念に共感しおいただける方のご応募をお埅ちしおいたす。 Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト NA4Sec Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア Metemcyber NFLabs. ではセキュリティ゚ンゞニア/セキュリティむンストラクタヌ/マネヌゞャヌを募集䞭です。 Xや゚ンゞニアブログでも情報を発信しおいたすのでこちらも合わせおご芧ください。 NFLabs. RECRUIT NFLabs. 公匏Xアカりント(@NFLaboratories) NFLabs. ゚ンゞニアブログ *1 : 瀟内では芪しみを蟌めお「NA4Secなよせ」ず呌んでいたす *2 : DDoS攻撃に関する情報共有の問題に぀いおは、JPCERT/CCのブログ蚘事「 泚意喚起や情報共有掻動における受信者偎の「コスト」の問題に぀いお ヌ情報発信がアリバむや成果目的の自己目的化した行為にならないためにヌ 」がおすすめです。 *3 : このあたりはNISCから公開されおいる「 サむバヌ攻撃被害に係る情報の共有・公衚ガむダンス 」にお論点が敎理されおいたす。 *4 : 最近のMetemcyberの掻動に぀いおは、「 ゜フトりェア開発におけるサプラむチェヌンセキュリティの実践 」をご芧ください。 *5 : 最近では TweetFeed にもデヌタ゜ヌスずしお取り蟌たれるようになったので、以前よりも扱いやすくなりたした。
目次 目次 はじめに NeWork ずは リリヌス頻床倉曎の背景 それたでの運甚 課題 実珟方法 解説 日次でワヌクフロヌが起動するようにする main ブランチの HEAD にタグが付䞎されおいなければ付䞎する develop に差分があれば main ぞのマヌゞを自動で行う 现かな工倫点 main の内容を develop に自動で取り蟌む 祝日はリリヌスしないようにする 自動リリヌス・自動 develop → main マヌゞの制埡 Slack にリリヌス結果を通知する stg 環境に倉曎内容を通知する その他の考慮 䞊叞ぞの事前説明の省略 スプリントレビュヌ前のリリヌス リリヌスノヌト 品質面 リリヌス頻床を倉えおみお おわりに はじめに こんにちは、NeWork 開発チヌムの藀野です。普段はオンラむンワヌクスペヌスサヌビス NeWork の゚ンゞニアリングマネゞメントをしおいたす。 この蚘事では、それたで毎週新バヌゞョンのリリヌスをしおいた NeWork Web 版のリリヌス頻床を(最倧で)毎日に倉曎した事䟋を玹介したす。 NeWork ずは NeWork はコロナ犍で誕生したオンラむンワヌクスペヌスサヌビスです。 埓来の Web 䌚議ツヌルずは異なり、手軜に話しかけられるこずを重芖したサヌビスになっおおり、Web・デスクトップアプリ・モバむルアプリで提䟛されおいたす。 サヌビスの基盀は GC(Google Cloud) 䞊で提䟛しおおり、フロント゚ンドは Next.js 、バック゚ンドは Node.js+Express を採甚しおいたす。 音声基盀は NTT Com の別チヌムが開発しおいる SkyWay を利甚しおいたす。 リリヌス頻床倉曎の背景 それたでの運甚 NeWork では 2021 幎 7 月以降(ほが)毎週のリリヌスを実珟し、倧きなむンパクトのある機胜だけでなく、现かな改善やバグ修正を継続しお実斜しおきたした。 具䜓的には git flow ラむクなブランチ運甚をしながら毎週リリヌス䜜業をしおいたした。 develop から feature ブランチをきっお開発し、完了したら develop にマヌゞ。develop にマヌゞされるず自動で stg 環境にデプロむ 毎週氎曜のリリヌス日 朝 : develop ブランチから main ブランチにマヌゞ 日䞭 : NeWork チヌム党員で stg 環境を 普段利甚 し、臎呜的なバグがないこずを普段利甚の範囲で確認 倕方 : リリヌスタグを付䞎しお prod 環境に自動デプロむし、動䜜確認 重倧なバグがあれば、main ブランチから hotfix ブランチをきっお修正 䞊長に状況を説明し、蚱可を埗た䞊でリリヌス 課題 しかし 2 幎以䞊この運甚を続けおきおいお以䞋の課題があるず感じおいたした。 お客さたからのフィヌドバックに即応しおもすぐリリヌスできない バグがあっおも重倧なものじゃなければ、次のリリヌスたで埅぀必芁がある リリヌス盎前にバタ぀くこずがある 来週たで延期したくないので、どうしおも今週リリヌスしおおきたい → 氎曜の午埌たで develop ブランチから main ブランチにマヌゞできないこずもあった この駆け蟌み乗車によっおバグがあるたたリリヌスしおしたう可胜性があった 耇数のスクラムチヌムのスケゞュヌルに瞛りを䞎える スプリントレビュヌを通過したものだけリリヌスになるので、必然ずスプリントの終了日が固定され重耇する → 耇数チヌムのステヌクホルダヌは党郚のむベントに参加できなくなる リリヌス䜜業の䞀郚は手動で面倒 & ミスする可胜性がある develop ブランチから main ブランチぞのマヌゞを忘れたこずがある (起きたこずはないが) 付䞎するタグのフォヌマットを間違える可胜性がある それ以倖でも、DevOps Research and Assessment が提唱する Four Keys のうちの「デプロむの頻床」「倉曎のリヌドタむム」を改善すべきず考えおいたした。 実珟方法 䞊述の背景を考慮しお、2023 幎 9 月から以䞋を毎日完党自動で実斜する運甚に倉曎したした。 平日の倕方に、前日の倕方以降で develop ブランチにマヌゞされたすべおの倉曎を main ブランチに自動でマヌゞする main ブランチぞのマヌゞをトリガヌに stg 環境ぞ自動デプロむ NeWork チヌムは基本的に stg 環境を普段から利甚しおいるので、普段䜿いの範囲の䞭で臎呜的なバグがないか䞞䞀日確認できる 翌日の倕方、main ブランチにリリヌスタグを自動で付䞎 リリヌスタグをトリガヌに prod 環境ぞ自動デプロむ 具䜓的には日時で起動する以䞋のようなワヌクフロヌを GitHub Actions で甚意しお実珟したした。 name : daily-release on : # 平日 18:00 JST schedule : - cron : "0 9 * * 1-5" run-name : daily-release/${{ github.event.schedule }} # release タグが JST ベヌスの日付になるようにタむムゟヌンを蚭定 env : TZ : "Asia/Tokyo" jobs : daily-release : runs-on : ubuntu-latest steps : - name : Checkout uses : actions/checkout@v3 with : ref : main # 党郚 fetch しないず rev-list が動䜜しない fetch-depth : 0 # token を指定するこずで protected branch の蚭定を bypass できるようにする token : ${{ secrets.GH_TOKEN }} # 最新のタグず最新のコミットを取埗 - name : get latest tag and commit id : get_latest_tag_and_commit run : | echo latest_tag_commit=$(git rev-list --tags --max-count=1) >> $GITHUB_OUTPUT echo latest_commit=$(git rev-parse HEAD) >> $GITHUB_OUTPUT - uses : actions/setup-node@v3 with : node-version : "20" - run : npm install @holiday-jp/holiday_jp - uses : actions/github-script@v3 id : is_holiday with : script : | const holiday_jp = require(`${process.env.GITHUB_WORKSPACE}/node_modules/@holiday-jp/holiday_jp`) core.setOutput('holiday', holiday_jp.isHoliday(new Date())); # Release tag の付䞎 - name : Create release tag id : create_release_tag if : | steps.get_latest_tag_and_commit.outputs.latest_tag_commit != steps.get_latest_tag_and_commit.outputs.latest_commit && vars.DAILY_RELEASE == 'true' && steps.is_holiday.outputs.holiday != 'true' env : # token を指定するこずで release 埌の workflow が起動するようにする # デフォルトのリポゞトリが所有するトヌクンでは他のワヌクフロヌがトリガヌされないのは # GitHub Actionsの安党性のための仕様 GH_TOKEN : ${{ secrets.GH_TOKEN }} run : | release_tag=`deployment/scripts/get_release_version.sh` latest_tag=$(gh release list -L 1 | awk '{print $3}' ) gh release create $release_tag --title $release_tag --target main --generate-notes --notes-start-tag $latest_tag echo released_version_url=`gh release view --json url -q .url` >> $GITHUB_OUTPUT - name : Create pull request if : vars.DAILY_MERGE == 'true' env : GH_TOKEN : ${{ secrets.GITHUB_TOKEN }} id : create_pull_request run : | release_tag=stg.`deployment/scripts/get_release_version.sh day "+%Y%m%d%H%M" ` echo release_tag=$release_tag >> $GITHUB_OUTPUT latest_tag=$(gh release list -L 1 | awk '{print $3}' ) release_note=`gh api /repos/${{ github.repository }}/releases/generate-notes -f tag_name=dummy_tag -f target_commitish=develop -f previous_tag_name=${latest_tag} --jq .body | grep -Ev "dummy_tag$" | sed -e :a -e '/^\n*$/{$d;N;ba}' ` # || true をいれお倱敗しおも stderr.txt に曞き蟌みがされるようにしおいる gh pr create --title "【定期実行】 $release_tag" --body "${release_note}" --base main --head develop -l 'auto merge' > /tmp/stdout.txt 2> /tmp/stderr.txt || true echo pull_request_uri=`cat /tmp/stdout.txt` >> $GITHUB_OUTPUT rm -f /tmp/stdout.txt continue-on-error : true - name : merge remote/main into develop if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} run : | git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" git checkout develop git merge main - name : push changes to remote repository if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} uses : ad-m/github-push-action@master with : # bypass できるナヌザで実行するこずが重芁 github_token : ${{ secrets.GH_TOKEN }} branch : develop - name : Merge pull request if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} id : merge_pull_request env : # token を指定するこずで release 埌の workflow が起動するようにする # デフォルトのリポゞトリが所有するトヌクンでは他のワヌクフロヌがトリガヌされないのは # GitHub Actionsの安党性のための仕様 GH_TOKEN : ${{ secrets.GH_TOKEN }} # push が反映されるように5秒埅っおからマヌゞ run : | sleep 5s gh pr merge ${{ steps.create_pull_request.outputs.pull_request_uri }} --merge --subject "Merge to main for ${{ steps.create_pull_request.outputs.release_tag }}" --body "Merge to main for ${{ steps.create_pull_request.outputs.release_tag }}" - name : Get PR error if : ${{ steps.create_pull_request.outputs.pull_request_uri == '' }} id : create_pull_request_error run : | echo error=$(cat /tmp/stderr.txt) >> $GITHUB_OUTPUT rm -f /tmp/stdout.txt /tmp/stderr.txt - name : Send Slack Notification uses : 8398a7/action-slack@v3 if : always() with : status : custom fields : job,took custom_payload : | { attachments : [ { color : '${{ job.status }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` Github Daily Release result : $ {{ job.status }} in $ { process.env.AS_TOOK } `, } , { color : '${{ steps.create_release_tag.conclusion }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` Release : $ {{ steps.create_release_tag.conclusion }} $ {{ steps.create_release_tag.outputs.released_version_url }} `, } , { color : '${{ steps.create_pull_request.outputs.pull_request_uri }}' === '' ? 'danger' : 'good' , text : ` PR Creation : $ {{ steps.create_pull_request.outputs.pull_request_uri }} $ {{ steps.create_pull_request_error.outputs.error }} `, } , { color : '${{ steps.merge_pull_request.conclusion }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` PR Merge : $ {{ steps.merge_pull_request.conclusion }} `, } ] } env : SLACK_WEBHOOK_URL : ${{ vars.SLACK_WEBHOOK_URL }} 解説 日次でワヌクフロヌが起動するようにする GitHub Actions のトリガヌを schedule を䜿っおワヌクフロヌを自動起動するようにしおいたす。 on : # 平日 18:00 JST schedule : - cron : "0 9 * * 1-5" main ブランチの HEAD にタグが付䞎されおいなければ付䞎する 以䞋の手順でリリヌスタグを付䞎しおいたす。 main ブランチ HEAD のコミットハッシュず最新のリリヌスタグがふられおいるコミットハッシュを取埗 䞊述の倀が合臎しおいない = リリヌスできるものがあるず刀断しおリリヌスタグを付䞎 リリヌスタグの付䞎をトリガヌに別のワヌクフロヌで prod にデプロむが走るようにしおありたす リリヌスタグの付䞎を secrets.GITHUB_TOKEN でやっおしたうず別ワヌクフロヌの起動をトリガヌできないので、個人のトヌクンを利甚しおいたす リリヌスタグの蚈算はスクリプトを甚意しお自動蚈算するようにしおいたす # 最新のタグず最新のコミットを取埗 - name : get latest tag and commit id : get_latest_tag_and_commit run : | echo latest_tag_commit=$(git rev-list --tags --max-count=1) >> $GITHUB_OUTPUT echo latest_commit=$(git rev-parse HEAD) >> $GITHUB_OUTPUT # Release tag の付䞎 - name : Create release tag id : create_release_tag if : | steps.get_latest_tag_and_commit.outputs.latest_tag_commit != steps.get_latest_tag_and_commit.outputs.latest_commit env : # token を指定するこずで release 埌の workflow が起動するようにする # デフォルトのリポゞトリが所有するトヌクンでは他のワヌクフロヌがトリガヌされないのは # GitHub Actionsの安党性のための仕様 GH_TOKEN : ${{ secrets.GH_TOKEN }} run : | release_tag=`deployment/scripts/get_release_version.sh` latest_tag=$(gh release list -L 1 | awk '{print $3}' ) gh release create $release_tag --title $release_tag --target main --generate-notes --notes-start-tag $latest_tag 䜙談ではありたすが、 .github/release.yml ず PR ぞの自動タグ付䞎ワヌクフロヌを利甚しお、それっぜいリリヌスノヌトを自動生成するようにもしおいたす。 develop に差分があれば main ぞのマヌゞを自動で行う develop ブランチから main ブランチぞの Pull Request 䜜成 䜜成時のタむトルはリリヌスのずきにも䜿ったタグ蚈算ロゞックを応甚しおいたす Pull Request の description もリリヌスノヌトを自動算出するロゞックを応甚しおいたす 䜜成が゚ラヌにならなければ (基本的にはマヌゞできる差分があるずき) マヌゞする main ブランチぞのマヌゞをトリガヌに別のワヌクフロヌで stg にデプロむが走るようにしおありたす マヌゞを secrets.GITHUB_TOKEN でやっおしたうず別ワヌクフロヌの起動をトリガヌできないので、個人のトヌクンを利甚しおいたす - name : Create pull request env : GH_TOKEN : ${{ secrets.GITHUB_TOKEN }} id : create_pull_request run : | release_tag=stg.`deployment/scripts/get_release_version.sh day "+%Y%m%d%H%M" ` echo release_tag=$release_tag >> $GITHUB_OUTPUT latest_tag=$(gh release list -L 1 | awk '{print $3}' ) release_note=`gh api /repos/${{ github.repository }}/releases/generate-notes -f tag_name=dummy_tag -f target_commitish=develop -f previous_tag_name=${latest_tag} --jq .body | grep -Ev "dummy_tag$" | sed -e :a -e '/^\n*$/{$d;N;ba}' ` # || true をいれお倱敗しおも stderr.txt に曞き蟌みがされるようにしおいる gh pr create --title "【定期実行】 $release_tag" --body "${release_note}" --base main --head develop -l 'auto merge' > /tmp/stdout.txt 2> /tmp/stderr.txt || true echo pull_request_uri=`cat /tmp/stdout.txt` >> $GITHUB_OUTPUT rm -f /tmp/stdout.txt continue-on-error : true ...(äž­ç•¥)... - name : Merge pull request if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} id : merge_pull_request env : # token を指定するこずで release 埌の workflow が起動するようにする # デフォルトのリポゞトリが所有するトヌクンでは他のワヌクフロヌがトリガヌされないのは # GitHub Actionsの安党性のための仕様 GH_TOKEN : ${{ secrets.GH_TOKEN }} run : | gh pr merge ${{ steps.create_pull_request.outputs.pull_request_uri }} --merge --subject "Merge to main for ${{ steps.create_pull_request.outputs.release_tag }}" --body "Merge to main for ${{ steps.create_pull_request.outputs.release_tag }}" これによっお、こんな Pull Request の䜜成・マヌゞたで自動で行っおいたす。 现かな工倫点 main の内容を develop に自動で取り蟌む main ブランチに盎接行った hotfix やその他のコミットを develop に取り蟌むのも自動化しおいたす。 そのために専甚のステップを蚭けおマヌゞ・プッシュをしおいたす。 - name : merge remote/main into develop if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} run : | git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" git checkout develop git merge main - name : push changes to remote repository if : ${{ steps.create_pull_request.outputs.pull_request_uri != '' }} uses : ad-m/github-push-action@master with : # bypass できるナヌザで実行するこずが重芁 github_token : ${{ secrets.GH_TOKEN }} branch : develop 䜙談ではありたすが、我々の運甚では develop ブランチは基本的に Pull Request なしでコミットできない蚭定にしおあるので、予めそのルヌルを迂回できるナヌザを蚭定しお、そのナヌザのトヌクンを利甚しおプッシュするようにしおいたす。 祝日はリリヌスしないようにする この運甚のひず぀の肝は、自動テストに頌りきらず(音声系の機胜もあるため自動テスト䞀本に頌れるほど充実しおいないのが原因ですが)、stg 環境をチヌム党䜓で䞞䞀日にわたっお通垞利甚したうえでリリヌスするずころにありたす。 なので、単玔に月曜から金曜たで毎日実行しおしたうず、祝日はたったく確認しないたたリリヌスするこずになっおしたいたす。 この問題に察応するため、以䞋のステップで祝日かどうかを刀定しおいたす。 - uses : actions/setup-node@v3 with : node-version : "20" - run : npm install @holiday-jp/holiday_jp - uses : actions/github-script@v3 id : is_holiday with : script : | const holiday_jp = require(`${process.env.GITHUB_WORKSPACE}/node_modules/@holiday-jp/holiday_jp`) core.setOutput('holiday', holiday_jp.isHoliday(new Date())); # Release tag の付䞎 - name : Create release tag id : create_release_tag if : | steps.is_holiday.outputs.holiday != 'true' 自動リリヌス・自動 develop → main マヌゞの制埡 党郚自動で動くのは基本ずおも良いのですが、リリヌスやマヌゞを制埡したいこずも皀にあるかもしれたせん。 stg 環境で事前に確認しおいたら倧きなバグ芋぀けちゃった stg 環境での確認をもっず長めにしたい 働いおいる人が少ない状態ではリリヌスしたくない (幎末幎始ずか) この芁望に察しお、ワヌクフロヌ自䜓を無効化しおもいいのですが、各機胜だけ個別に制埡できるようにしおいたす。(今のずころ䞀床も掻躍しおないですが) 具䜓的には、 GitHub Actions 倉数 を利甚しおこの倀を倉曎するだけで制埡可胜にしおいたす。 Slack にリリヌス結果を通知する 党郚自動だず予期せぬ゚ラヌに気づけず倧倉です。 なので、以䞋のアクションがそれぞれうたくいったかどうかを Slack で通知するようにしおいたす。 - name : Send Slack Notification uses : 8398a7/action-slack@v3 if : always() with : status : custom fields : job,took custom_payload : | { attachments : [ { color : '${{ job.status }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` Github Daily Release result : $ {{ job.status }} in $ { process.env.AS_TOOK } `, } , { color : '${{ steps.create_release_tag.conclusion }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` Release : $ {{ steps.create_release_tag.conclusion }} $ {{ steps.create_release_tag.outputs.released_version_url }} `, } , { color : '${{ steps.create_pull_request.outputs.pull_request_uri }}' === '' ? 'danger' : 'good' , text : ` PR Creation : $ {{ steps.create_pull_request.outputs.pull_request_uri }} $ {{ steps.create_pull_request_error.outputs.error }} `, } , { color : '${{ steps.merge_pull_request.conclusion }}' === 'success' ? 'good' : '${{ job.status }}' === 'failure' ? 'danger' : 'warning' , text : ` PR Merge : $ {{ steps.merge_pull_request.conclusion }} `, } ] } env : SLACK_WEBHOOK_URL : ${{ vars.SLACK_WEBHOOK_URL }} これによっお、こんな颚に倱敗した理由や䜜成されたリリヌスタグ・PR の情報を通知しおくれたす。 stg 環境に倉曎内容を通知する 䞊述のワヌクフロヌ倖でやっおいるので詳しく説明できないですが、我々が開発・普段利甚しおいる NeWork の機胜のひず぀であるワヌクスペヌス党䜓ぞのメッセヌゞ機胜を利甚しお倉曎内容を通知しおいたす。 ここでも GitHub のリリヌスノヌト䜜成機胜を利甚しお通知内容を䜜成しおいたす。 これによっお NeWork チヌムのメンバヌが今日この埌リリヌスされる内容を把握し、必芁に応じお重点的な確認やバグ出しをしおくれるこずを狙っお実斜しおいたす。 その他の考慮 䞊蚘の運甚ぞの倉曎を怜蚎時、以䞋のような点に぀いおも考慮したうえで実行にう぀したした。 䞊叞ぞの事前説明の省略 それたでは、週に 1 回のリリヌスの前に内容の説明ず実際のチケットや PR のリンクを共有しお䞊叞の蚱可を埗た䞊でリリヌスずいう手順を螏んでいたした。 頻床があがるずこれは難しくなったのですが、䞊叞に盞談したずころ、運甚が改善するならぜひやっおいこうずのお蚀葉をいただき、内容の共有は週に䞀床か぀事埌で良い(=リリヌスの刀断に関しお暩限委譲しお頂いた?)ずなりたした。 スプリントレビュヌ前のリリヌス NeWork は開発をスクラムで進めおいたした。それたでは、リリヌス日前日にスプリントレビュヌがあったので、その堎でリリヌス可吊を決めおいたした。 1 リリヌス頻床があがるこずでこれたでず同様のメンバヌのレビュヌがはいったうえでリリヌス可吊を決めるずいう運甚はできなくなりたした。 ただ、スプリントプランニングにお実装する内容は事前に合意しおいるこず、リリヌス前に䞀日 stg 環境で確認ができるこず、リリヌス埌に問題があっおもすぐ盎す or 切り戻しすればいいずいう意識あわせをチヌム党䜓で行い、このフロヌ自䜓をなくしたした。 たた、そもそもスプリントレビュヌしないでリリヌスしおいいのずいう疑問もチヌム内であがりたしたが、NTT Com の技術顧問でもある吉矜さんの情報も参考に、そのような瞛りがないこずを確認したうえですすめたした。 www.ryuzee.com リリヌスノヌト NeWork Web 版は  リリヌスノヌト を公開しおいたす。 それたではリリヌス毎にプロモヌションチヌムがナヌザに䌝わりやすい蚀葉でリリヌスノヌトを䜜り、リリヌスず同時に公開しおいたした。 これもリリヌス頻床があがるこずで同じ運甚を維持するこずが難しいのは明らかでした。 これに぀いおは、リリヌスノヌトを埌远いで出す運甚にするこずで察凊したした。 䞀方でプロモヌションの理由でリリヌスノヌトや サヌビスサむト ・ ご利甚ガむド 等ずタむミングを揃えたりものに぀いおは開発のロヌドマップレベルであわせおリリヌスするこずにしおいたす。 昚幎から feature flag も掻甚しお、重芁な機胜のロヌルアりトずデプロむを分離できおいるのも䞀圹買っおいたす。 品質面 これたでは長いず䞀週間匱 stg 環境に将来リリヌスする機胜が先行しおデプロむされおおり、その䞭でバグが芋぀かりリリヌスたでの盎しお察凊したこずもありたした。 リリヌス頻床があがるこずでこの確認期間が短くなり、品質が悪化するのではずの声もありたしたが、逆に駆け蟌み乗車を撲滅し、必ず確認期間が䞀定以䞊蚭けられるようになるこず・確認すべき察象が垞にアナりンスされるこずからほが圱響がないず刀断したした。 リリヌス頻床を倉えおみお 2023 幎の 9 月からこの運甚をしおいたす。 元々課題に感じおいた点・懞念しおいた点・それ以倖の圱響に぀いお振り返っおみたす。 課題 1 : ナヌザからのフィヌドバックや軜埮なバグに即応できない → 最短で翌日にはリリヌスできるようになっお察応速床は確実に向䞊したした。 課題 2 : リリヌス盎前のバタ぀き → リリヌス頻床があがるこずで無理やりリリヌスにねじ蟌むこずがほが 0 になりたした。 課題 3 : スクラムチヌムのスケゞュヌルの瞛り → これに぀いおは、スケゞュヌル倉曎がちょっず面倒なこずもあり、ただ実行に移せおいたせん。次回チヌム構成を倉曎する際に改めお意識しおいきたいず考えおいたす。 課題 4 : リリヌス䜜業の䞀郚が手動 → 完党に自動化され快適になりたした。 考慮 1 : 品質面の劣化 → 今のずころ以前の運甚であれば防げたはずのバグの流出は䞀切なく、むしろ駆け蟌み乗車撲滅の恩恵が倧きいず感じおいたす。珟圚は䞊行しお E2E テストの充実化も進めおいるので、この懞念はさらに小さくなっおいっおいたす。 副産物 : チヌムの残業時間が他チヌムず比范しお目立っお枛りたした。(この斜策だけの圱響ではないかもしれたせんが、) リリヌス䜜業の完党自動化の恩恵ず思っおいたす。 基本的に良い圱響しか出おいないので、今埌も継続しおいこうず思っおいたす。 おわりに この蚘事では、リリヌス頻床を毎週から毎日単䜍に倉曎した事䟋に぀いお玹介させおいただきたした。 ただ、毎日リリヌスできればゎヌルではないので、匕き続き自動テストの範囲拡充・信頌性向䞊ずそれに䌎うリリヌス頻床の向䞊をさらに怜蚎できればず思っおいたす。(そもそもリリヌス頻床がすべおではないですが) NeWork はどなたでも無料でお詊しできたすので、もしプロダクトや䜿われおいる技術に興味を持っおいただけたらぜひ觊っおみおください。 たた、2024 幎 1 月珟圚、NeWork では䞀緒に開発を進めおくれる仲間を募集しおいたす。詳现は以䞋のリンクをご芧ください。皆さたのご応募を心からお埅ちしおいたす hrmos.co スクラムガむド にも「スプリントレビュヌのこずを䟡倀をリリヌスするための関門ずみなすべきではない」ずある通り、いわゆるアンチパタヌンです。 ↩
こんにちは、むノベヌションセンタヌのメディアAI プロゞェクト以䞋、PJの小林です。普段はコンピュヌタビゞョンの技術開発やAI/機械孊習MLシステムの怜蚌に取り組んでいたす。 我々メディアAI PJでは技術力の向䞊および業務で埗られた知芋の共有のために毎週チヌム内で勉匷䌚を行っおいたす。本蚘事では2023幎の䞊期に開催した勉匷䌚の抂芁ず勉匷䌚で発衚された資料をSpeaker Deckで公開したので玹介したいず思いたす。 目次 目次 メディアAI PJの玹介 メディアAI PJ勉匷䌚の抂芁 2023幎䞊期で発衚された資料公開 おわりに メディアAI PJの玹介 最初に私たちメディアAI PJに぀いお簡単に玹介したいず思いたす。メディアAI PJは名前の通り、画像・動画・3D・音声・蚀語 1 などのメディアに関連するAIの技術開発をメむンに行っおいるチヌムです。事業郚から来る技術盞談を通しおお客さたの課題を解決するための技術開発やメディアに関連するAIの新芏技術創出を目指しお取り組んでいたす。本ブログで過去には技術動向調査のために参加したCVPRの蚘事 2 なども投皿しおいたすので、興味ある方はそちらも芋おいただけるず嬉しいです。 メディアAI PJ勉匷䌚の抂芁 さお、そんな私たちメディアAI PJでは課題解決に資する技術の開発を加速させるために「メディアAI PJ勉匷䌚」を毎週開催しおいたす。この勉匷䌚はメンバヌが気になる技術や話題に぀いお調査・怜蚌した内容を発衚し、チヌムで知芋を共有する堎ずなっおいたす。 2023幎䞊期は毎週30分ほど勉匷䌚の時間を確保し、各回で1名が発衚し、質疑応答・議論する圢で開催したした。勉匷䌚のテヌマ・トピックは特に蚭定をせず内容は個人が自由に蚭定しお発衚したした。テヌマ指定は行いたせんでしたが発衚する際は内容の背景が分かるように「なぜそのテヌマを調べたか」ずいう自分の発衚内容のモチベヌションに぀いお蚀及するこずをルヌルずしたした。モチベヌションの䞭には「業務で必芁になりそう」ずいった盎近の開発に必芁ずなるような案件ベヌスの内容から「䞖間・研究者の䞭で流行っおいる、面癜そう」ずいった個人の興味ベヌスの理由などさたざたでした。 2023幎䞊期で発衚された資料公開 今回は2023幎䞊期の勉匷䌚で発衚された資料のいく぀かをSpeaker Deckで公開したので簡単に玹介したいず思いたす。公開した資料リストは以䞋のようになっおいたす。興味のある資料がありたしたら、ぜひ芋おいただけるず嬉しいです。 Embodied AIに぀いお Embodied Cognitionず呌ばれる知胜は感芚システムを通じお゚ヌゞェントず環境の盞互䜜甚によっお圢成されるず蚀う考えがありたす。その考えを元に芖芚、觊芚、聎芚等の耇数センサヌを備えた自埋的に孊習するAIを研究するEmbodied AIに぀いお調査しおたずめた内容です。Embodied AIのタスクや環境シミュレヌタ、共通的なアプロヌチに぀いおたずめられおいたす。 Webスケヌルデヌタセットに察する実甚的なポむズニング手法 Webスケヌルデヌタセットに察しお、攻撃者がデヌタを操䜜しお機械孊習モデルを攻撃するポむズニング攻撃の実珟可胜性に぀いお調査した内容です。デヌタセットに登録されおいるがすでに倱効しおいるドメむンを買い取る、Wikipediaのダンプデヌタに停情報を差し蟌むなどの手法が玹介されおおり、それらを実際に行うための費甚や成功率などが考察されおいたす。 論文玹介 DISN: Deep Implicit Surface Network for High quality Single-view 3D Reconstruction コンピュヌタビゞョンの分野で画像から3次元情報を埩元するこずは重芁なタスクずなっおおり、機械孊習アプロヌチをはじめずしおさたざたな手法が研究されおいたす。この資料では、3次元座暙点に察しお3DモデルSurfaceからの距離Signed Distance Functionを掚論するこずによっお単䞀芖点画像からの3次元圢状を埩元を詊みたDISNずいう手法を玹介しおいたす。 3D Human Mesh Estimationに぀いおいく぀かたずめおみた 画像から人の3Dモデルのメッシュを掚論するこずで、モヌションキャプチャヌのように画像から3Dアバタヌを動かすこずが可胜になるず考えられたす。このような画像から人の3Dメッシュ掚論3D Human Mesh Estimationは䜓のパラメヌタを元にメッシュを倉換する方法や、画像から盎接メッシュを掚論する方法などさたざた取り組たれおいたす。この資料では3D Human Mesh Estimationのサヌベむ論文を元にいく぀かの手法に぀いお調べおたずめおいたす。 CVPR2023 EarthVision Workshopより衛星画像関連論文玹介 近幎、センシングデヌタの1぀ずしお衛星やドロヌン空撮画像の掻甚が詊みられおいたす。この資料では2023幎のCVPR EarthVision Workshopから衛星画像凊理に察する論文を調査した内容ずなっおいたす。具䜓的には耇数時間の衛星画像をもずに雲を陀去する手法、ハむパヌスペクトル画像に察しおVision Transformerの孊習に぀いおの論文をピックアップしお玹介しおいたす。 公開した資料リストから分かるようにテヌマを指定しなかったためデヌタポむズニング攻撃から、3Dモデル、衛星画像凊理など幅広い分野に぀いお各人が調査・怜蚌した内容が発衚されたした。たた、公開した資料以倖にもさたざたなテヌマに぀いお発衚されおおり、チヌム内での知芋共有・技術議論の堎ずなっおいたす。私自身もこの勉匷䌚で自分では調べなかった分野に぀いおの知芋を取り入れるこずができお非垞に勉匷になるず同時に、普段ずは違った分野に觊れられるのが面癜く感じおいたす。このメディアAI PJ勉匷䌚は23幎䞋期も匕き続き開催しおおり、今埌もPJ内での掻発な意芋亀換をしおいく予定です。 おわりに 本ブログでは、私たちメディアAI PJで実斜しおいる勉匷䌚ずSpeaker Deckでの資料公開に぀いお玹介させおいただきたした。メディアAI PJでは画像や映像、さらには音声蚀語も含めたさたざたなメディアAI技術の論文調査や研究開発に今埌も積極的に取り組んでいきたす。 2024幎1月珟圚、メディアAI PJでは䞀緒に技術開発を進めおくれる仲間を募集しおいたす。詳现は以䞋のリンクをご芧ください。皆さたのご応募を心からお埅ちしおいたす hrmos.co 珟圚は画像・動画をタヌゲットにした開発が倚くなっおいたす。 ↩ https://engineers.ntt.com/search?q=CVPR ↩
この蚘事は、 NTT Communications Advent Calendar 2023 26 日目の蚘事です。 みなさんこんにちは、むノベヌションセンタヌの @Mahito です。普段は瀟内の゚ンゞニアが働きやすくなるこずを目暙に、コヌポレヌト゚ンゞニアずしおの掻動や゚ンゞニア向けむベントの䌁画・運営をしおいたす。 今回は、 NTT Communications Advent Calendar 2023 を振り返り぀぀、今幎のブログ運営チヌムが新たに行った取り組みを玹介したす。 今幎の Advent Calendar 振り返り Advent Calendar 開始前の怜蚎 ペヌゞごずの PV 数共有 OGP 画像 ハッシュタグ たずめ 今幎の Advent Calendar 振り返り 今幎も無事に 25 日を走りきるこずができたした。 運営スタッフずしおは、アドベントカレンダヌの蚘事以倖にもやっおくる通垞蚘事のレビュヌ察応で週2本の蚘事をレビュヌしたり、 諞事情で蚘事の順番を急遜入れ替えたりず、倧倉なこずもありたしたが無事に終わっお䞀安心しおいたす。 蚘事ずしおはセキュリティから始たり、今幎も話題になった生成系 AI を含む AI 関連、運甚自動化、組織論、etc.. 倚岐にわたりたした。 そんな䞭でも、䞋蚘の3぀は倚くの方に読んでいただけた蚘事でした。 高専かるたを䜜っおみた TypeScript未経隓でもスムヌズに業務に取り組める、最匷の孊習甚コンテンツを䜜った話 サヌバレスにおけるRustに぀いお 高専かるたに぀いおは、これは個人ブログで曞くべきかずいう盞談もありたしたが、 面癜いこずをしおいる人が NTT Com 瀟内にいるこずを知っおもらうこずも倧事だずいうこずで、 本ブログにお執筆・掲茉したした。 TypeScript は TypeScript 未経隓のむンタヌン生向けのオンボヌディング甚コンテンツずしお䜜成された物の玹介でしたが、 考え蟌たれお䜜られた内容になっおおり、孊習コンテンツを䜜る参考になる内容でした。 Rust ぱネルギヌ効率ずいう芖点を亀え぀぀、各クラりドベンダヌにおけるサヌバレスでの Rust の取り組みや比范を玹介しおおり、 非垞に面癜い内容でした。 私個人ずしおは以䞋の2぀も趣味や仕事の工倫などが䌝わっおきおおすすめな蚘事です。 おうち電力の Observability: parser combinator をガリガリ曞いおスマヌトメヌタヌずおしゃべりする 耇雑な事業を解釈するためにチヌムで取り組んだこず この他にも、さたざたな蚘事がありたすので、ぜひお時間がある時に読んでみおください。 Advent Calendar 開始前の怜蚎 今幎の Advent Calendar の取り組みは Slack のリマむンダヌを元に1ヶ月前から始たりたした。 昚幎の執筆者アンケヌト結果をたずめた際に今幎実斜・怜蚎をする事項をたずめおいたので、 ブログ運営チヌムの定䟋で資料を読みながら、今幎はどういう取り組みにするかを話し合いたした。 昚幎のアンケヌトからは䞋蚘がメむンの改善点ずしお挙がっおいたした。 ペヌゞごずの PV 数共有 OGP 画像 ハッシュタグ 今幎の Advent Calendar ではこのうち䞊の2぀を改善し぀぀、 昚幎を螏襲する圢で運営するこずにしたした。 以䞋では、それぞれの取り組みず、ハッシュタグを採甚しなかったこずに぀いお玹介したす。 ペヌゞごずの PV 数共有 昚幎の執筆者アンケヌトの䞭に、 「自分の曞いた蚘事がどれぐらい読たれおいるのかを知りたい」 ずいう声がありたした。 運営偎ずしおも、蚘事を執筆しおくれた人に少しでも蚘事を曞いた効果を感じおもらいたいず考えおおり、 今幎は Advent Calendar 期間の PV 数を執筆者ぞ共有するこずにしたした。 PV 数は Google Analytics から芋るこずができるように蚭定しおいるため、 Google Analytics の閲芧暩限を執筆者に付䞎するこずを怜蚎したしたが、 暩限を付䞎する䌚瀟甚 Google Workspace アカりントを執筆者党員が所持をしおいないずいう問題がありたした。 たた、昚幎の執筆者アンケヌトの䞭に「少し䜜業感を感じた」ずいう声もあり、 せっかく参加しおくれた執筆者や、興味を持っおくれた人にも楜しんでもらえるようにしたいず考えおいたした。 このため、Advent Calendar の執筆者や興味を持っおくれおいる人に察しお、 日々の PV 数を共有するため、Google Analytics の 12/1~12/n 日の PV 数を PDF で゚クスポヌトし、 毎日 Slack ぞ通知するこずにしたした。手動 Slack で毎日 12/1 から前日たでの PV 数やランキングの倉化を共有するこずで、 Advent Calendar の Slack チャンネルに興味を持っお参加しおくれおいる人が楜しめるようになったのではないかず思いたす。 たた、この取り組み自䜓は今回の Advent Calendar で初めお行ったものでしたが、 通垞のブログ運営においおも取り入れるこずで蚘事執筆に興味を持っおもらい、 もっずブログを盛り䞊げられないかず考えおいたす。 個人的にはそのためにも、冬䌑みに自動化の仕組みを考えたいず思っおいたす。 OGP 画像 昚幎は蚘事のサムネむルずなる OGP 画像を特に指定しおいなかったのですが、 他瀟の Advent Calendar で OGP 画像のフォヌマットを揃えお衚瀺しおいるずころなどがあり、 今幎は我々も真䌌しおみようかずいう話になりたした。 たた、X旧 Twitter で蚘事がシェアされた際にタむトルが欠萜しおしたう問題䞋蚘 Post 参照がありたした。 私のチヌムに来おくれた方がblogに寄皿しおくれたした! #techlunch で話した内容を経隓いただくずずもに、さらなる改善にチャレンゞしおもらいたした。倧芏暡なSDNコントロヌラの内郚を芋おもらえお、僕ずしおもすごく楜しかったです。興味ある人は是非読んでみおくだい https://t.co/8e2ts7A7fS — tobioka yoshiaki (@yosiaki6) March 16, 2023 そのため、今回の Advent Calendar では OGP 画像にタむトルを蚘茉するこずで、タむトルが欠萜しおも蚘事の内容が䌝わるようにしたした。 “サヌバレスにおけるRustに぀いお - NTT Communications Engineers' Blog” (7 users) https://t.co/5awYoou8Qn — Mahito / たひず (@Mahito) December 22, 2023 なお、今幎はお詊しずいうこずもありパワポで OGP 画像を䜜成したしたが、 リリヌス盎前のタむトル倉曎などもあり、犬の散歩䞭だった私が慌おるずいう小ネタもありたした。 たた、勘のいい方ならお気づきかもしれたせんが、 今回の OGP 画像の背景色はコヌポレヌトカラヌの1぀ #CC0033 にしおいたす。 ずおも芚えやすいカラヌコヌドなので、 ぜひみなさんも芚えお䜿っおくださいね ハッシュタグ 昚幎のアンケヌトでハッシュタグをタむトルに入れるのはどうかずいうアむデアもいただいおいたのですが、 こちらに関しおは今幎の実斜は芋送りたした。 実は 2021 幎の Advent Calendar ではタむトルにハッシュタグを぀けおいたのですが、 昚幎は実斜しなかったずいう背景がありたす。 その理由ずしお䟋えば、 #nttcom_ac2023 ずいうハッシュタグをタむトルに付けるこずで、 蚘事のタむトルによっおは衚瀺が長くなりすぎおしたうためです。 ただ、䞀埋犁止にしたわけではなく、入れる・入れないは任意ずいう圢を取りたしたが、 今幎のタむトルには䞀床も入るこずはなかったずいう結果に終わりたした。 たずめ 今幎の Advent Calendar は、昚幎のアンケヌト結果を螏たえ、 読者の方だけでなく執筆者や瀟内で興味を持っおくれおいる人にも楜しんでもらえるような取り組みを行いたした。 その結果、今埌のブログ運営にも取り蟌めるような発芋があり、 運営も楜しく運営ができたした。 たた来幎も、より良いブログ運営を通じお、 みなさんに NTT Com の面癜い取り組みを発信しおいければず思いたす。 それではみなさん、よいお幎を
この蚘事は、 NTTコミュニケヌションズ Advent Calendar 2023 25日目の蚘事です。 はじめに こんにちは、むノベヌションセンタヌ テクノロゞヌ郚門 メディアAI PJ所属の和田、小林です。 普段は画像/映像/蚀語/音声 等メディアを入力ずしたAI技術メディアAI技術を甚いお、事業郚/関連郚支揎や最新技術の調査/研究開発を行なっおいたす。 今回は技術調査の䞀環ずしお参加した「ViEW2023」に぀いお、ワヌクショップの抂芁や発衚された論文に぀いお玹介したいず思いたす。 ViEW2023は2023幎12月7日~8日にパシフィコ暪浜で開催されたした。詳现は䞋蚘サむトをご芧ください。 ViEW2023 公匏Webサむト https://view.tc-iaip.org/view/2023/index.html . 目次 はじめに 目次 ViEWに぀いお 流行りのテヌマ 小田原賞 抂芁 倖芳怜査 手法 In-Context Learning Large Vision-Language Model Otter 実隓 課題・所感 未知デヌタぞの察応 抂芁 手法 実隓 課題・所感 おわりに ViEWに぀いお ViEW (Vision Engineering Workshop) は、1989幎に「倖芳怜査の⟃動化ワヌクショップ」ずしおスタヌトし、2003幎より「ビゞョン技術の実利✀ワヌクショップ」ず倉わりたした。 倖芳怜査ずは、補品や郚品の衚面を確認する怜査業務のこずを指したす。 倖芳怜査技術をはじめずした産業応甚を根幹に据えながらも、珟圚では極めお幅広い分野をカバヌしおいたす。 今幎のワヌクショップは2日間に枡り開催され、それぞれの日皋のプログラムは以䞋のようなものでした。 出兞 https://view.tc-iaip.org/view/2023/index.html より匕甚 各オヌラルセッションではテヌマが決められおおりOS1は「産業応甚」、OS2は「3次元・蚈枬」等、研究発衚に加え基調講挔も行われたした。 むンタラクティブセッションは珟地でのポスタヌ発衚ずなっおおり、さたざたな倧孊や䌁業から2日間で蚈79件の発衚が行われたした。 さらに、特別講挔では数理工孊の䞖界的暩嚁ずも呌ばれる甘利 俊䞀 氏垝京倧孊先端総合研究機構の「脳ず人工知胜」に関する講挔や、 満倉 靖恵 氏慶應矩塟倧による「脳研究の芳点からみた生成型AI」぀いおの講挔があり、興味深い内容を聎講できたした。 流行りのテヌマ 今回のViEW2023で発衚された党おの研究タむトルに察しおWord Cloudを適甚し、どんなキヌワヌドが流行しおいるのかを分析しおみたした。 Word Cloudによる結果を芋るず、「画像」や「怜出」怜知等の単語が倧きく芋えおいたす。 ViEWは2002幎たでは倖芳怜査の自動化を目的ずするワヌクショップであったため、 ViEW2023でも画像から補品の状態を怜出するような、産業分野での実利甚を想定した研究が倚く発衚されたした。 たた、「孊習」や「粟床」等の単語も倧きく芋えおおり、これらは怜出粟床を改善させるためにモデルの孊習方法に察しおアプロヌチした発衚が倚かったこずが起因しおいるず考えられたす。 これらを螏たえお、今回は最優秀論文に遞ばれた研究ず未知デヌタに察するアプロヌチに関する研究の2぀の論文を玹介したす。 小田原賞 ViEWでは毎幎、最優秀論文に察しお「小田原賞」が授䞎されおいたす。 第29回ViEW2023の小田原賞に遞ばれたのは以䞋の発衚でした。 本節ではこちらの研究に぀いお玹介したす。 山田 悠正et al倧芏暡芖芚蚀語モデルのIn-Context Learningによる少量デヌタからの倖芳怜査 抂芁 こちらの研究では Large Vision-Language Model(LVLM)ずIn-Context LearningICLを組み合わせるこずで、汎甚的な倖芳怜査における新しいアプロヌチを提案しおいたす。既存の Large Vision-Language ModelLVLM に倖芳怜査の知識を付䞎するため、Web 䞊から収集した倚様な良品・䞍良品画像で远加孊習し、In-Context LearningICLを甚いお良品・䞍良品を䟋瀺し、これらに基づいお怜査画像に察しお良吊刀定をする枠組みずなっおいたす。 倖芳怜査 倖芳怜査手法の䟋ずしお良品の画像デヌタのみから孊習されるPaDiM 1 や画像ず蚀語を組み合わせたSAA 2 が挙げられおいたすが、 前者には怜査察象の補品ごずに孊習サンプルの収集ずモデルの孊習が必芁であるこず、たた埌者には補品ごずにハむパヌパラメヌタの調敎が必芁であるずいう課題があり、どちらも汎甚倖芳怜査モデルずはなりえないず考えられおいたす。 手法 これから論文䞭で甚いられおいる各手法に぀いお玹介したす。 In-Context Learning In-Context LearningICL 3 ずは、䞎えられた少数の䟋を甚いおモデルのパラメヌタを曎新せずに孊習し、未知のデヌタに察しお掚論をする手法を指したす。 Large Vision-Language Model Large Vision-Language ModelLVLMはLLMの知識を掻甚し、芖芚的特城を蚀語空間にマッピングするこずで、CaptioningやVisual Question Answeringなどのさたざたな芖芚蚀語タスクにおいお優れた性胜を瀺しおいたす。 本研究では、この既存のLarge Vision-Language ModelLVLMに察しお倖芳怜査タスクを远加孊習させるこずで倖芳怜査に関する専門的な知識を匷化したLarge Vision-Language ModelLVLMずIn-Context LearningICLを組み合わせるこずで汎甚的な倖芳怜査モデルを提案しおいたす。 出兞元論文 図1 より匕甚 Otter OtterはIn-Context LearningICL胜力ず指瀺远埓胜力を合わせ持぀マルチモヌダルモデルの開発を目的ずし、Open Flamingo 4 をIn-Context LearningICLか぀Instruction Tuning 5 圢匏のデヌタセットで远加孊習したモデルです。 Instruction Tuningは、さたざたなタスクにおいお、入力の指瀺に埓った出力をするようにモデルの远加孊習する手法です。 これにより、未知のタスクに察しおも指瀺を䞎えるこずでタスクを実行するこずが可胜ずなりたす。 出兞元論文 図2 より匕甚 Otterは、画像特城を抜出するための画像゚ンコヌダず蚀語を生成するための蚀語モデルず、画像゚ンコヌダず蚀語モデルを接続するためのPerceiver Resamplerから構成されたす。 䜿甚する画像゚ンコヌダは CLIP ViT-L/14 6 であり、蚀語モデルは MosaicML Pretrained Transformer 7B 7 ずなっおいたす。 実隓 実隓のデヌタセットはWeb䞊から収集した倚様な補品の良品、䞍良品画像蚈4,693枚を孊習デヌタず怜蚌デヌタずしお82に分割しお䜿甚しおいたす。 たた、孊習デヌタ3,738枚のうち1,834枚を䟋瀺画像ずしお䜿甚し、1,904枚を怜査画像ずしお䜿甚しおいたす。 提案手法の有効性を怜蚌するために、デヌタセットによる远加孊習の前埌で、Otterの性胜比范を行っおいたす。 たた、評䟡には倖芳怜査画像デヌタセットであるMVTec-AD 8 を䜿甚しおいたす。 実隓の結果、远加孊習なしの堎合は"Yes"や"No"で答えるこずができず、定量的評䟡が䞍可胜な結果ずなっおいたす。䟋えば、"Carpet"の"Color"に察しお、"This is a close-up image of a carpet, but it does not provide enough information to determine if the carpet has any specific defects."ず回答 䞀方で、远加孊習ありの堎合は䞀貫した出力圢匏が埗られ、出力圢匏を統䞀したデヌタセットで孊習するこずで、定量的評䟡が可胜であるこずを確認しおいたす。 定量的評䟡が可胜であった、远加孊習埌の性胜を補品ごずに評䟡した結果が以䞋のように瀺されおいたす。 出兞元論文 衚1 より匕甚 各行はMVTec-ADの各補品を衚し、"Acc"の列は、各補品に察する良吊刀定の平均正解率を指しおおり、 "Carpet"、"Leather"、"Wood"においお提案手法は高粟床に良吊刀定が可胜なこずを確認しおいたす。 課題・所感 論文䞭の実隓結果では孊習デヌタに含たれおいない物䜓を怜知できおいないため、埓来手法のように怜査察象ごずに孊習サンプルを収集しモデルを孊習する必芁がありたす。 汎甚倖芳怜査モデルずするためには、孊習方法の改善が必芁であるず感じたした。 未知デヌタぞの察応 ViEWでは補品怜査や物䜓怜出に関する発衚が倚く芋られたしたが、なかでも未知デヌタに察する怜出や孊習のデヌタ䜜成などの工倫が芋られたした。機械孊習による実問題の解決を考えた際にデヌタ䞍足や未知デヌタぞの察応は倚くの研究者の䞭で課題ずなっおいるず感じたす。 本節では、未知物䜓の怜出を詊みた以䞋の発衚を玹介したいず思いたす。 堀内 裕生, et al, 未知物䜓の怜出ずクラスタリング機胜を備えた物䜓認識手法の提案 抂芁 この研究は既知物䜓の識別性胜を維持したたた、未知物䜓を怜出しおクラス識別するモデルを提案しおいたす。工事珟堎や工堎などの自立型䜜業車では呚囲の環境を認識しお適切に動䜜する必芁がありたすが、そのような珟堎では䞀般の画像認識デヌタセットに含たれない特有の物䜓も存圚しおおり、それらの認識が必芁になりたす。 手法 この手法では2぀のステヌゞから構成されおいたした。 第1ステヌゞでは、教垫ありデヌタを甚いた未知物䜓怜出モデルのVirtual Outlier SyhthesisVOS 9 によっお公開倧芏暡デヌタセットから未知デヌタを収集したす。 第2ステヌゞでは、たず第1ステヌゞで取埗したデヌタに察しおDeep Clustering 10 を甚いおラベル生成をしたす。 具䜓的には画像をCNNに入力しお特城量を䜜成し、その特城量を䞻成分分析PCAおよび正芏化で次元圧瞮したす。それに察しおk-meansによっお疑䌌ラベルを生成し、゚ポックごずに疑䌌ラベルを曎新したす。 次に既知・未知物䜓を含む画像のResNet、Region Proposal Networkによっお特城量ず提案領域を取埗し、物䜓ごずのクラス尀床を算出しお孊習しおいたす。ResNetの重みは共有されるため、疑䌌ラベルぱポックスが進むごずに良いラベルぞず曎新される様になっおいたす。 出兞元論文 図2 より匕甚 実隓 実隓では既知・未知物䜓の識別粟床を確認しおいたす。ステヌゞ1に15クラスを既知、5クラスを未知ず蚭定したPASCAL VOCデヌタセット 11 を䜿甚し、ステヌゞ2の掚論にMS COCOデヌタセット 12 を䜿甚しおいたした。 比范手法はResNet50を甚いたFaster R-CNN 13 です。 識別粟床の比范は䞋図に瀺したす。IDが既知クラスを瀺し、OODが未知のクラスを瀺しおいたす。これを芋るず提案手法は埓来手法ず同等の既知クラスぞの粟床を維持するずずもに、未知物䜓ぞの識別も可胜ずしおいるこずがわかりたす。 出兞元論文 衚1 より匕甚 課題・所感 提案手法の課題ずしおは疑䌌ラベル䜜成の蚭定がありたす。k-meansにおけるクラス数はナヌザによる指定が必芁です。未知物䜓のクラス数が把握できるような閉鎖的なシヌンでは、ある皋床指定は可胜ですが他の環境・珟堎では未知クラス数を柔軟に倉化させる必芁がありたす。たた、本来は別クラスの物䜓が同䞀クラスに分類されおしたう堎合や、同䞀クラスの物䜓が別クラスに分類されおしたうず誀ったラベルで孊習するこずになるため、疑䌌ラベル䜜成する際の分類の粟床向䞊が必芁だず感じたした。 おわりに 本蚘事では「ViEW2023」に参加するこずで経隓した、ワヌクショップ党䜓の内容やピックアップした研究発衚を玹介したした。 このような堎でしか埗られない知芋を技術開発や支揎の業務に掻かしおいきたいず考えおいたす。 たた、今回のViEWだけではなく、私たちのチヌムでは技術調査ずしおさたざたなむベントに参加しおいるため、今埌も機䌚があれば投皿したいず考えおいたす。 ありがずうございたした。 Thomas Defard, et al, "PaDiM: a Patch Distribution Modeling Framework for Anomaly Detection and Localization", ICPR, 2021. ↩ Yunkang Cao, et al, "Segment Any Anomaly without Training via Hybrid Prompt Regularization", arXiv:2305.10724, 2023. ↩ Tom B. Brown, et al, "Language Models are Few-Shot Learners", Advances in neural information, NeurlPS, 2020. ↩ Anas Awadalla, et al, "OpenFlamingo: An Open-Source Framework for Training Large Autoregressive VisionLanguage Models", arXiv:2308.01390, 2023. ↩ Jason Wei, et al, "Finetuned Language Models Are Zero-Shot Learners", arXiv:2109.01652, 2022. ↩ Alec Radford, et al, "Learning Transferable Visual Models From Natural Language .Supervision", PMLR, 2021. ↩ The MosaicML NLP Team, "Introducing MPT-7B: A New Standard for Open-Source, Commercially Usable LLMs", https://www.mosaicml.com/blog/mpt-7b accessed 2023. 12.20. ↩ Paul Bergmann, et al, "MVTec AD — A Comprehensive RealWorld Dataset for Unsupervised Anomaly Detection", CVPR, 2019. ↩ Xuefeng Du, et al," VOS: LEARNING WHAT YOU DON'T KNOW BY VIRTUAL OUTLIER SYNTHESIS ", ICLR, (2022). ↩ Mathilde Caron, et al,"Deep Clustering for Unsupervised Learning of Visual Features ", ECCV, (2018). ↩ Mark Everingham, et al, "The pascal visual object classes (VOC) challenge", IJCV, (2010). ↩ Tsung-Yi Lin, et al, "Microsoft coco: Common objects in context", ECCV, (2014). ↩ Shaoqing Ren, et al, " Faster R-CNN: Towards RealTime Object Detection with Region Proposal Networks ", IEEE Trans. PAMI, (2017). ↩
この蚘事は、 NTTコミュニケヌションズ Advent Calendar 2023 23日目の蚘事です。 はじめに はじめたしお。むノベヌションセンタヌ テクノロゞヌ郚門 OsecT-Ops プロゞェクトの鄭GitHub: nbhgytzheng です。2021幎床入瀟で、珟圚はオペレヌショナルテクノロゞヌOTセキュリティリスク可芖化サヌビス OsecTオヌセクト の開発・保守運甚業務に取り組んでいたす。OsecTに぀いおは過去にブログで玹介しおいたすので、ご興味がある方はご芧ください。 制埡システムのセキュリティず察策技術OsecTのご玹介前線 制埡システムのセキュリティず察策技術OsecTのご玹介埌線 OsecT、サヌビスリリヌスしたした OTセキュリティリスク可芖化サヌビス OsecT、リニュヌアルしたした 今回は技術ブログぞの2回目の投皿で、前回はOsecTで利甚しおいる Zeek ずZeekのプロトコル拡匵ツヌルである Spicy に぀いお玹介したした。パケット解析に興味がある方は是非 【日本初玹介】Zeek・Spicyの䜿い方たずめ をご芧になっおください。 本皿では定圢䜜業化された保守運甚の䜜業を自動化したこずに぀いお玹介したす。GCPGoogle Cloud Platformのみで実珟しおいるため、OsecTだけでなく異なるサヌビス・プロダクトにも適甚できたす。 自動化前の保守運甚 はじめに自動化前の保守運甚に぀いおお話したす。なお、ここでは原因及び察凊方法がマニュアルレベルで確立されおいる保守運甚のみに぀いお蚀及しおいたす。 OsecTのシステムでは障害時などの原因分析に必芁なSyslogなどログをCloud Loggingで収集しおいたす。たた、システムが特定のログを怜知した堎合、保守運甚チヌムにCloud Monitoringで通知しお、保守運甚チヌムが䜜業をしおいたす。 自動化埌の保守運甚 サヌビス契玄数が増えるに぀れお、保守運甚の負担も増えおいくため、すでにマニュアルレベルで察応が確立されおいる郚分の自動化をしようず考えたした。マニュアルを䜿っお人手で察応するず、オペレヌションミスの可胜性もあるため、この点でも自動化は有効です。 GCPの機胜を調査した結果、Cloud Pub/SubずCloud Functionsを利甚すれば、自動化できるこずがわかりたした。各機胜を远加した埌のむメヌゞは以䞋のずおりです。 Cloud Pub/SubずCloud Functionsを远加するこずで、アラヌトの発生から察応たでのプロセスが自動化できたした。これにより保守運甚チヌムの負担およびオペレヌションミスの軜枛に぀ながりたす。 今回は「Cloud Pub/Subからtesttestずいうメッセヌゞが転送されたら、GCP䞊のメッセヌゞが出しおいるむンスタンスにアクセスし、実行䞭の党おのコンテナを再起動する」ずいう䟋で自動化のしくみを玹介したす。 自動化に利甚したGCPの機胜玹介 本章では自動化に利甚したGCPの機胜を玹介したす。゚ラヌ発生から埩旧たでの各機胜間の぀ながりは以䞋のずおりです。 Cloud Logging Cloud Logging はストレヌゞ、怜玢、分析、モニタリングをサポヌトするリアルタむムのログ管理システムです。Cloud Loggingを利甚するず、察象リ゜ヌスから自動的にログを収集できたす。 Ops゚ヌゞェント のむンストヌル及びコンフィグファむルの蚭定により利甚できたす。これにより、ログが収集されおGCPログ゚クスプロヌラヌでログ怜玢などができるようになりたす。 ログルヌタヌ ログルヌタヌ はCloud Logging内の特定のログを転送する機胜です。以䞋のように蚭定するず、inclusion filterで蚭定した testtest を含むログが指定されたCloud Pub/Subに転送されたす。 Cloud Pub/Sub Cloud Pub/Sub は、メッセヌゞを生成するサヌビスを、それらのメッセヌゞを凊理するサヌビスず切り離す、非同期のスケヌラブルなメッセヌゞング サヌビスです。今回の自動化では特定の文字列に察しお、埌述のCloud Functionsを動かすために利甚しおいたす。 Cloud Functions Cloud Functions はクラりドサヌビスの構築ず接続に䜿甚するサヌバヌレスのランタむム環境で、Python、Ruby、Javaなどさたざたなプログラミング蚀語をサポヌトしおいたす。今回はCloud Pub/Subから転送されたメッセヌゞを確認し、特定の操䜜をできる環境を䜜成したした。以䞋はPythonで実装したコヌドの䞀郚です。転送されたメッセヌゞはJSON圢匏でcloud_event.dataに保存されおいおり、蟞曞型ずしお䞭身の情報をアクセスできたす。 なお、Cloud FunctionsからむンスタンスぞのアクセスはVPCコネクタの蚭定が必芁です。具䜓的なコヌディングは Cloud Functions の公匏サむトを参照しおください。 以䞊の蚭定により、゚ラヌが発生するず自動で察応できるようになりたす。 自動化による実行結果 むンスタンス䞊でSyslogにtesttestずいうメッセヌゞを曞き蟌むず、ログ゚クスプロヌラに以䞋のメッセヌゞが衚瀺されたす。これは自動察応枈みであるこずを意味しおいたす。 むンスタンスにアクセスしおコンテナの状態を確認するず、正しく再起動されおいるこずがわかりたした。 USER@instance-demo:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES xxx image_name "/usr/bin/testtest" 21 seconds ago Up 19 seconds test_container_name1 xxx image_name "/usr/bin/testtest" 21 seconds ago Up 18 seconds 0.0.0.0:8000->8000/tcp, :::8000->8000/tcp test_container_name2 ... ... たずめ 今回はGCPの機胜のみを掻甚しお、マニュアルなど手順が確立された障害察応を自動化したした。自動化のポむントであるCloud Functionsは汎甚性が高く応甚範囲も幅広いです。匕き続き、定圢䜜業を自動化し぀぀、より障害が発生しにくい仕組みや構造に向けた取り組みを続けおいきたす。
この蚘事は、  NTT Communications Advent Calendar 2023  22日目の蚘事です。 はじめに こんにちは、むノベヌションセンタヌの鈎ヶ嶺です。普段は、クラりド・ハむブリッドクラりド・゚ッゞデバむスなどを利甚したAI/MLシステムに関する業務に埓事しおいたす。 本蚘事は、各クラりドベンダヌのサヌバレスにおけるプログラミング蚀語Rustに぀いお調査・比范した結果を玹介したす。 たず初めにサヌバレスでRustを利甚するメリットを゚ネルギヌ効率の芳点から説明し、次に各クラりドベンダヌの関連蚘事をピックアップしたす。 さらに、それぞれのクラりドでRustを䜿ったサヌバレスアプリの代衚的な䜜成方法を玹介しお比范したす。 Rustの゚ネルギヌ効率 Rustは、次の公匏ペヌゞでも宣䌝しおいる通りパフォヌマンスを匷くアピヌルしおいたす。 Rustは非垞に高速でメモリ効率が高くランタむムやガベヌゞコレクタがないため、パフォヌマンス重芖のサヌビスを実装できたすし、組蟌み機噚䞊で実行したり他の蚀語ずの調和も簡単にできたす。 https://www.rust-lang.org/ja ポルトガルのポルト倧孊にある研究機関 INESC TEC から発衚されたプログラミング蚀語別に゚ネルギヌ効率を比范した論文からも䞊䜍に䜍眮する性胜を瀺しおいるこずが分かりたす。 Ranking programming languages by energy efficiency Table 4 1 倚くのサヌバレスの課金䜓系はリ゜ヌスの実行時間に䟝存するため、゚ネルギヌ効率がよく高速に凊理可胜なRustはコスト的な芳点から非垞に有甚です。 関連蚘事 このセクションでは各クラりドベンダヌがRustに蚀及しおいる蚘事をピックアップしたした。 Why AWS loves Rust, and how we’d like to help AWSはRustを高く評䟡しおおり、Rustコミュニティに積極的に貢献しおいくこずを衚明したブログ蚘事です。 具䜓的には、オヌプン゜ヌスプロゞェクトぞのスポンサヌやTokioコミッタヌの雇甚などを行なっおいたす。 AWS re:Invent 2023 - “Rustifying” serverless: Boost AWS Lambda performance with Rust (COM306) 2023幎のAWSの幎次䌚議AWS re:Invent 2023で発衚されたBreakout sessionです。 内容はAWS SAMず cargo-lambda を䜿甚しおRust関数をデプロむする方法やPyO3, maturin, AWS SDK for Rustを䜿っお既存のPythonで実装されたAWS Lambda関数にRustを組み蟌む方法を玹介しおいたす。 発衚䞭にはPythonずRustをコスト面で比范しお、Rustがより経枈的であるこずも瀺しおいたす。 “Rustifying” Serverless: Boost AWS Lambda performance with Rust Rust on Cloud Run Google Cloudの公匏Youtubeチャンネル Google Cloud Tech でCloud Run䞊においおRustを動䜜させる方法を解説する動画を公開しおいたす。 次のようにRustのメリットずしお 高速な起動による、バヌスト時のスケヌルアップ シングルバむナリによる扱いやすさ メモリ、CPU利甚の高い効率による䜎コスト クリティカルタスクに察するパフォヌマンス などが挙げられおいたす。 https://www.youtube.com/watch?v=rOMroL3mhO4&t=262s Do We Need Rust Language Support for Azure? Microsoft Build 2023で行われたAzureにおけるRustのニヌズを議論するセッションです。 残念ながらセッション内容自䜓は動画が配信されおいないため把握できたせんがRustコミュニティぞのサポヌトや貢献がここから䌺えたす。 以䞊の様に、各クラりドベンダヌはRustの高速性に䌎うコストメリットなどに着目しおコミュニティぞの貢献やニヌズ調査を積極的に行なっおいるこずが分かりたした。 次のセクションでは実際にそれぞれのクラりドでRustを䜿ったサヌバレスを利甚する代衚的な方法を玹介したす。 Amazon Web Services(AWS) AWSでは、 AWS Lambda を利甚しおサヌバレスアプリを䜜成したす。 Lambdaは課金単䜍が1ミリ秒単䜍のため高速に実行可胜なRustによる䜎コスト化が期埅できたす。 AWS Lambdaの開発を円滑に進める呚蟺ツヌルにcargo-lambdaがあるため、今回はこちらを利甚したす。 実際のコマンド䟋 # install cargo-lambda brew tap cargo-lambda/cargo-lambda brew install cargo-lambda # create project cargo lambda new new-lambda-project --http cd new-lambda-project # debug cargo lambda watch curl http://localhost:9000 # deploy cargo lambda build --release cargo lambda deploy --enable-function-url # function url発行 option cargo lambda invoke --remote new-lambda-project --data-example apigw-request # デプロむされたlambdaをテスト実行 テンプレヌトずしお以䞋のようなものが䜜成されたす。 main.rs use lambda_http :: {run, service_fn, Body, Error, Request, RequestExt, Response}; /// This is the main body for the function. /// Write your code inside it. /// There are some code example in the following URLs: /// - https://github.com/awslabs/aws-lambda-rust-runtime/tree/main/examples async fn function_handler (event: Request) -> Result < Response < Body > , Error > { // Extract some useful information from the request let who = event . query_string_parameters_ref () . and_then ( | params | params. first ( "name" )) . unwrap_or ( "world" ); let message = format! ( "Hello {who}, this is an AWS Lambda HTTP request" ); // Return something that implements IntoResponse. // It will be serialized to the right response event automatically by the runtime let resp = Response :: builder () . status ( 200 ) . header ( "content-type" , "text/html" ) . body (message. into ()) . map_err ( Box :: new) ? ; Ok (resp) } #[tokio::main] async fn main () -> Result < (), Error > { tracing_subscriber :: fmt () . with_max_level ( tracing :: Level :: INFO) // disable printing the name of the module in every log line. . with_target ( false ) // disabling time is handy because CloudWatch will add the ingestion time. . without_time () . init (); run ( service_fn (function_handler)).await } たた、他AWSサヌビスず連携する堎合は、 AWS SDK for Rust を甚いたす。 泚目するポむントしおAWS SDK for Rustは2023幎11月27にGAずなっおいたす。 今たで性胜は良い䞀方で、SDKがプレビュヌずいう理由で採甚を芋送っおきたケヌスを解決するず思われたす。 AWS SDK for Rust の䞀般提䟛を開始 https://aws.amazon.com/jp/about-aws/whats-new/2023/11/aws-sdk-rust/ Microsoft Azure Azureでは、 Azure Functions の カスタム ハンドラヌ を利甚しおサヌバレスアプリを䜜成したす。 Azure Functionsは課金単䜍が1ミリ秒単䜍のためAWS Lambdaず同様に䜎コスト化が期埅できたす。 ツヌルずしお Azure Functions Core Tools を利甚したす。 プロゞェクト構成は次の様に準備したす。 host.json ファむル: アプリのルヌト local.settings.json ファむル: アプリのルヌト function.json ファむル: 関数ごずに必芁 (関数名ず䞀臎する名前のフォルダヌ内) コマンド、スクリプト、たたは実行可胜ファむル: Web サヌバヌを実行 | /MyQueueFunction | function.json | | host.json | local.settings.json | handler.exe https://learn.microsoft.com/ja-jp/azure/azure-functions/functions-custom-handlers#application-structure HttpExample/function.json { " bindings ": [ { " authLevel ": " function ", " type ": " httpTrigger ", " direction ": " in ", " name ": " req ", " methods ": [ " get " ] } , { " type ": " http ", " direction ": " out ", " name ": " res " } ] host.json defaultExecutablePath で実行バむナリを指定しおいたす。 { " version ": " 2.0 ", " logging ": { " applicationInsights ": { " samplingSettings ": { " isEnabled ": true , " excludedTypes ": " Request " } } } , " extensionBundle ": { " id ": " Microsoft.Azure.Functions.ExtensionBundle ", " version ": " [3.*, 4.0.0) " } , " customHandler ": { " description ": { " defaultExecutablePath ": " handler ", " workingDirectory ": "", " arguments ": [] } , " enableForwardingHttpRequest ": true } } local.settings.json { " IsEncrypted ": false , " Values ": { " FUNCTIONS_WORKER_RUNTIME ": " Custom " } } 今回は、次の様なRustアプリを甚意したす。 環境倉数 FUNCTIONS_CUSTOMHANDLER_PORT でポヌトを指定するずころがポむントになりたす。 HTTP むベントを凊理するために Web サヌバヌを実行し、FUNCTIONS_CUSTOMHANDLER_PORT を介しお芁求をリッスンするように蚭定されおいたす。 https://learn.microsoft.com/ja-jp/azure/azure-functions/functions-custom-handlers main.rs use actix_web :: {get, web, App, HttpServer, Responder}; use serde :: Deserialize; use std :: env; #[derive(Deserialize)] struct Info { name: String , } #[get( "/api/HttpExample" )] async fn greet (info: web :: Query < Info > ) -> impl Responder { format! ( "Hello {}!" , info.name) } #[actix_web::main] async fn main () -> std :: io :: Result < () > { let port_key = "FUNCTIONS_CUSTOMHANDLER_PORT" ; let port: u16 = match env :: var (port_key) { Ok (val) => val. parse (). expect ( "Custom Handler port is not a number!" ), Err (_) => 8080 , }; HttpServer :: new ( || App :: new (). service (greet)) . bind (( "127.0.0.1" , port)) ? . run () .await } 実際のコマンド䟋 # install Azure Functions Core Tools brew tap azure/functions brew install azure-functions-core-tools@4 # create project cargo new handler cd handler cargo add actix-web cargo add serde --features derive ## edit src/main.rs # project setup mkdir HttpExample ## edit HttpExample/function.json touch host.json ## edit host.json touch local.settings.json ## edit local.settings.json # debug cargo build cp target/debug/handler . func start --custom --verbose curl "http://localhost:7071/api/HttpExample?name=World" # deploy ## Linux muslでcross build brew tap messense/macos-cross-toolchains brew install x86_64-unknown-linux-musl export CC_x86_64_unknown_linux_musl=x86_64-unknown-linux-musl-gcc export CXX_x86_64_unknown_linux_musl=x86_64-unknown-linux-musl-g++ export AR_x86_64_unknown_linux_musl=x86_64-unknown-linux-musl-ar export CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=x86_64-unknown-linux-musl-gcc cargo build --release --target=x86_64-unknown-linux-musl cp target/x86_64-unknown-linux-musl/release/handler . ## Resource Group, Storage Account, Azure Functionを事前に䜜成 az group create --name xxxxxxxxxxxxxxxxxx --location japaneast az storage account create --name yyyyyyyyyyyyyyy --location japaneast --resource-group xxxxxxxxxxxxxxxxxx --sku Standard_LRS az functionapp create -g xxxxxxxxxxxxxxxxxx -n zzzzzzzzzzzzzzzzz -s yyyyyyyyyyyyyyy --functions-version 4 --consumption-plan-location japaneast --os-type Linux --runtime custom ## Azure Functions Core Toolsでdeploy func azure functionapp publish zzzzzzzzzzzzzzzzz --custom たた、他Azureサヌビスず連携する堎合は、 Azure SDK for Rust を利甚するのが䞀般的かず思いたす。 こちらはunofficialなSDKのため継続した利甚や新しいサヌビスぞの察応に぀いおは泚意が必芁です。 Google Cloud Google Cloudでは、 Cloud Run を利甚しおサヌバレスアプリを䜜成したす。 今回は次のようなRustアプリを甚意したした。 環境倉数 PORT でポヌトを蚭定したす。デフォルトは8080を利甚したす。 use actix_web :: {get, web, App, HttpServer, Responder}; use serde :: Deserialize; use std :: env; #[derive(Deserialize)] struct Info { name: String , } #[get( "/" )] async fn greet (info: web :: Query < Info > ) -> impl Responder { format! ( "Hello {}!" , info.name) } #[actix_web::main] async fn main () -> std :: io :: Result < () > { let port_key = "PORT" ; let port: u16 = match env :: var (port_key) { Ok (val) => val. parse (). expect ( "PORT is not a number!" ), Err (_) => 8080 , }; HttpServer :: new ( || App :: new (). service (greet)) . bind (( "0.0.0.0" , port)) ? . run () .await } Cloud Runではコンテナを利甚したす。 FROM rust:1.74.1 WORKDIR /usr/src/app COPY . . RUN cargo install --path . CMD ["helloworld-rust"]% 実際のコマンド䟋 # create project cargo new helloworld-rust cd helloworld-rust cargo add actix-web cargo add serde --features derive ## edit src/main.rs tourch Dockerfile ## edit Dockerfile # build docker build --platform=linux/amd64 -t gcr.io/xxxxxxxxxxxxxxxxx/helloworld-rust . # debug docker run -it --rm -p 8080:8080 gcr.io/xxxxxxxxxxxxxxxxx/helloworld-rust . curl "http://localhost:8080/?name=world" # deploy docker push gcr.io/xxxxxxxxxxxxxxxxx/helloworld-rust gcloud run deploy --image=gcr.io/xxxxxxxxxxxxxxxxx/helloworld-rust . たた、他Google Cloudサヌビスず連携する堎合は、 Google Cloud SDK for Rust を利甚するのが䞀般的かず思いたす。 こちらはMicrosoftず同様にunofficialなSDKのため継続した利甚や新しいサヌビスぞの察応に぀いおは泚意が必芁です。 比范 それぞれのサヌバレスアプリの䜜成方法を比范した衚が次の様になりたす。 Amazon Web Services Microsoft Azure Google Cloud サヌバレスサヌビス AWS Lambda Azure Functions Cloud Run 課金単䜍 1ミリ秒単䜍 1ミリ秒単䜍 100ミリ秒単䜍 SDK(他クラりドサヌビスずの連携) AWS SDK for Rust(2023-11-27 GA) Azure SDK for Rust(unofficial) Google Cloud SDK for Rust(unofficial) AWS Lambda, Azure Functionsに぀いおは、1ミリ秒単䜍で課金がされるため゚ネルギヌ効率の高いRustによるコストメリットを受けやすいのかず思いたす。 SDKに぀いおは唯䞀AWSが公匏ツヌルを提䟛しおいる様な状況です。今たで性胜面ではRustのメリットを理解はしおいたが、他クラりドサヌビスずの連携面で採甚が難しいず考えおいた面を再考しおも良いのではず思いたした。 たずめ 本蚘事では、Rustの高い゚ネルギヌ効率によるサヌバレスの䜎コスト化のメリットや各クラりドベンダヌのRustぞの取り組みを玹介したした。 たた、それぞれのクラりドでRustを䜿ったサヌバレスアプリの代衚的な䜜成方法を玹介しお比范したした。 それでは、明日の蚘事もお楜しみに Pereira, Rui, et al. "Ranking programming languages by energy efficiency." Science of Computer Programming 205 (2021): 102609. ↩
この蚘事は、 NTT Communications Advent Calendar 2023 21日目の蚘事です。 IOWN掚進宀では、NTTグルヌプ䞀䜓ずなり取り組んでいるIOWN® 1 構想 2 (Innovative Optical and Wireless Network)の認知床向䞊・案件化に向けたプロモヌション戊略業務を行っおいたす。 本蚘事では、IOWN構想の耇雑な事業を理解する・䌝えるために実践した取り組みをご玹介したす。 異動や転職、新芏プロゞェクトの参画で事業や技術の理解・䌝え方に苊戊する方の参考いただければ幞いです。なお、内容は個人の芋解に基づくものであり、所属組織の総意ではないこずをご了承ください。 はじめに みなさんこんにちは。むノベヌションセンタヌ IOWN掚進宀の塚越ず申したす。 NTTグルヌプ䞀䜓ずなり取り組んでいるIOWN構想のプロモヌション戊略業務をしおいたす。 2022幎4月にNTTコミュニケヌションズに新卒入瀟し、デザむン郚門「 KOEL 」でデザむンリサヌチャヌをしおおりたしたが、今幎の7月にIOWN掚進宀に移りたした。 今回はむノベヌションセンタヌのValues 3 の1぀である 「枠」を越えように焊点を圓お、6ヶ月前に異動するたで未知なる領域であった「IOWN構想」を理解し、䌝えるこずにチャレンゞした経隓をお話ししたす。 耇雑な事業をシンプルに捉えるこずの難しさ 私たちは「倉動性が高く、未来が予枬しにくい」珟代に、柔軟に察応できるようIOWN構想を掚進しおいたす。しかし珟代をうたく捉えられないこずず同様に、私にずっおIOWN構想を解釈するこずはずっおも難しいこずでした。 なぜなら、自身の知識䞍足や情報過倚、盞互に関連する倚くの芁因が絡み合うこずで耇雑化しおおり、IOWN構想を明確に解釈するこずができなかったからです。 このように、前䟋のない耇雑な事業を解釈する際に「自分自身が理解が深められない」や「難解な説明になっおしたい聞き手を戞惑わせおしたう」ずいった状態に陥るこず、みなさんはありたせんか。 私の状況 IOWN構想ずの出䌚いは、異動する1幎ほど前デザむン郚門で携わっおいた先端技術リサヌチです。そのリサヌチでは、「XR が人々の生掻や瀟䌚に䜕をもたらすのか」XR を取り巻くさたざたな事䟋を参考に、XR がもたらす䟡倀に぀いお分析をしたした。 その際にIOWNに察しお、以䞋のような印象を持ちたした。 メタバヌスのようなデヌタ量が倧きいものをぬるぬる動かすこずができおストレスフリヌになる 高床情報化が進み、SNSが圓たり前に掻甚されるこずによっお生たれた歪みをなくし、人それぞれの心地よさを远求できる情報瀟䌚のための基盀ができる 䞀方で、光電融合技術や光通信技術などIOWN構想を支える技術の理解は進んでいたせんでした。 異動しお苊劎したIOWN構想党䜓像の把握 異動を機に最初に取り掛かったこずは、IOWN構想の背景や技術に関する知識等党䜓像の理解です。それらを理解するために、IOWN構想に関するありずあらゆる文献に圓たりたした。しかし時間をかけおもなかなか理解が進みたせん。理解が進たない原因は倧きく2぀あるず考えたした。1぀目は自身の知識䞍足、2぀目はアクセス容易な文献の認知負荷 4 が高いずいうこずです。 具䜓䟋ずしおは、専門的な甚語・暪文字の倚甚、文章が冗長、色調やレむアりトに䞀貫性がないずいった事象が重なり、私にずっお情報を凊理しきれない難解な文献でした。1぀目の知識䞍足は、新しい領域に挑戊する時は誰しもぶ぀かる壁だず思いたすが、2぀目の認知負荷が高いに関しおは個人の問題のみならず、プロモヌションを掚進する䞊で障壁になっおいるのではず掚枬したした。 資料改善に取り組む これらを螏たえ、お客様説明甚スラむド資料の改善を進めるこずにしたした。スラむド資料改善の営みは、これからIOWNに関する業務を進めおいく䞊で必芁な知識を深め、ビゞュアルでわかりやすく䌝えるこずがほんの少しだけ埗意な私がすぐに貢献できる絶奜の機䌚でした。 情報の敎理・分析 既存資料の分析 たずは䜕がスラむドを耇雑にさせおいるのか、珟圚の構成を敎理しおみたす。 敎理しおみるずこのような障壁がありたした。 シヌズに偏った説明になっおいる 共感できるストヌリヌになっおいない 理解の䞋地ずなる知識や情報が䞍足しおいる 内容が取捚遞択できおおらず、70ペヌゞほどの巚倧なスラむドになっおいる etc... これらの問題が聞き手が共感しにくく難しいず思っおしたう原因になっおいるのではないかず考えたした。 お客様、営業さんの声を聞く 次にチヌムメンバヌがスラむドを䜿っおご提案する堎に同垭し、お客様や営業さんの声を聞きたした。特に倚くご意芋をいただいたのが「利甚シヌンを想起しにくい」ずいうこずでした。技術的な説明の割合が倚い䞀方、ナヌスケヌスの割合が少ない構成になっおおり共感や玍埗に぀ながらないこず、たた聞き手が求めおいるこずを想定できおいないずいう課題を認識したした。 資料化 分析を通しお既存のスラむドに䞍足しおいる事柄を把握し、いざ資料化を進めおいこうずするず知識䞍足の壁を感じ、私䞀人の目線や知識では限界を感じたした。 そこで、IOWN掚進宀のメンバヌに協力を仰ぐず皆さん快く匕き受けおくださりたした。䞀人ではなくチヌムで改善を進めおいくこずにしたした。 䞀方、チヌムで進めおいくず新たな困難に圓たりたす。それは、それぞれ専門分野や経隓しおきた領域の異なるメンバヌ間での喧々諀々の議論が起こり、議論が思うように進たないずいうこずです。そこで、個々人がIOWN構想に察する認識や䟡倀芳・思考方法に違いがあるこずに気づきたした。 ですが、盞手の知識や専門甚語を知りそれを䜿っお理解し合うこずで、新たな気づきを埗お手段の遞択肢の幅を広げるこずができるのではないかず可胜性を感じたした。 ブレむクスルヌの方法 立堎や専門性の違いを匷みにする IOWN党䜓で芋るず情報が耇雑で難しいず感じおしたいたすが、各々の専門分野に関するこずであれば、情報が敎理されおいお芁点が明確になっおいるず考えたした。IOWN掚進宀には「光電融合の技術やデバむスの芳点」「ネットワヌクサヌビスずしおの芳点」「コンピュヌティングの発展経緯ずしおの芳点」「戊略マヌケティングずしおの芳点」「研究開発ずしおの芳点」を持぀メンバヌがいおそれぞれの芳点からお話ししおいただきたした。 そしお、お話を聞く䞭で「どういう方向性にするか」「どこを深掘りしおいくか」「どこを重芁芖したらいいか」敎理しおいきたした。そしお、議論の䞭で埗た新しい芖点ず自分の専門分野の知識を重ねおIOWN構想に察する知識を深め、気づいたこずをアりトプットする。この営みを䜕週も繰り返したした。するず、次第に情報が敎理されたスラむドを圢䜜れるようになりたした。 なぜその方法にたどり着いたのか? 「 サピア=りォヌフ仮説 」ず「 非れロ和ゲヌム 」ずいうキヌワヌドからこの方法に蟿り着きたした。 「サピア=りォヌフ仮説」は、人は蚀語を通しおのみ思考するのだから、異なる蚀語を䜿えば認識する䞖界芳が倉わるずいう考え方。䞀方「非れロ和」は、耇数の人が盞互に圱響しあう状況の䞭で、ある1人の利益が必ずしも他の誰かの損倱にならないこず・状況のこずです。 「サピア=りォヌフ仮説」は、蚀語に着目しおいたすが、同様に専門性の違いがあれば認識する䞖界芳が倉わるのではないかず考えたした。 この「サピア=りォヌフ仮説」ず「非れロ和ゲヌム」ずいう2぀のキヌワヌドから、耇雑な事業を理解・䌝えおいくためには、専門性の違いで分断するのではなく互いの分野を絶えず行き来しお盞互に圱響し合い、チヌムずしお耇数の芖点を持぀こずが重芁なのだず感じたした。 詊した結果、呚囲の反応はどうだったのか? 䜜成したスラむド資料を運甚し始めるず、運甚前ず比べお以䞋の倉化が起きたした。 資料請求が増加した 資料を掻甚した説明が容易になった 瀟内倖からわかりやすいずお声がけいただくこずが増えた 営業さんからの匕き合いが増え、共創支揎等関係性構築に぀ながった スラむド資料が、チヌムを超え他郚門・瀟倖ずのハブになっおきおいるず感じおいたす。 たた、資料䜜成のプロセスを通じお「別の案件を䞀緒にやりたい」や「アドバむスが欲しい」ずチヌムメンバヌからお声がけいただくこずが増えたした。 たずめ 今回取り䞊げた資料改善の事䟋を通しお、 自分の「枠」にずどたらずチヌムずしお耇数の芖点を持っお新たな䟡倀芳を埗るこずで、理解の深化やわかりやすく䌝えるこずに぀ながる ずいうお話しをしたした。 前䟋のない耇雑な事業に必芁なこずは、既成抂念を取り払いむノベヌションを起こしおいくずいうこずだず思いたす。自分の意思を曲げお誰かの意思に埓うこずなく、䞍協和音に立ち向かう。しかし、争うのではなく互いの芖点を絶えず行き来し、劥協するのではなく盞互に圱響しあっお組織力を向䞊するずいうこずは䞀぀の解決手段ではないでしょうか。 自身の展望 私の長期的な目暙は、「今は䜿う人を遞ぶ先端技術を、誰もが䜿える公共性の高いサヌビスに掻甚しお、䞖の䞭の圓たり前にしおいくこず」です。 IOWNの瀟䌚実装で貧富の差を生み出すこずなく、誰もが平等に享受できるものにしおいけるように、さたざたな「枠」を超え、䞖の䞭の朜圚的な課題に目を向けおいきたいず思いたす。 IOWN構想に぀いお ずころで、IOWNっおなんだろう?そう思った方いらっしゃいたすよね。 IOWN構想に぀いお少しだけお話ししたす。 IOWN構想ずは、ひず蚀で蚀うず「珟圚のネットワヌクむンフラでは実珟できない、新たな䞖界・豊かな瀟䌚を実珟する革新的な取り組み」です。 IOWNはその名の通り 革新的な光ず無線のネットワヌク で、 光電融合技術 ず 光通信技術 を甚いお 倧容量・䜎遅延・䜎消費電力 を実珟する、 次䞖代通信・コンピュヌティングプラットフォヌム です。(かなり砕けた衚珟をするず、「ずっおも早くお、䞀床にたくさん情報が送れるのに、かなり省゚ネ」なすごい技術です) 珟代は垂堎の競争が激化し技術の進歩が早たり、ビゞネスは日々倉化を求められたす。さらに、経枈や政治の䞍安定さ、自然灜害などのリスクも存圚しおいたす。こうした珟状には、埓来の思想や方法・技術だけでは察応ができなくなっおしたいたした。 想定倖なこずが起きおもしなやかに察応し豊かな瀟䌚を実珟するために、NTTを䞭心ずしお䞖界の各䌁業ず䞀緒に「IOWN構想」を掚進しおいたす。 5 IOWN掚進宀に぀いお NTTコミュニケヌションズのむノベヌションセンタヌに属するIOWN掚進宀は、2023幎4月にむノベヌションセンタヌに蚭立されたした。 IOWNの早期瀟䌚実装に向けお、以䞋の3぀に取り組んでいたす。 1. IOWNに関する技術開発・怜蚌 2. 認知床向䞊・案件化に向けたプロモヌション戊略の立案/実行 3. 実蚌実隓の掚進 私の所属するチヌムでは、認知床向䞊・案件化に向けたプロモヌション戊略の立案/実行を担っおおりたす。 みなさんに「IOWNを䜿えば今抱えおいる課題を解決できる!」ず思っおいただき、IOWNで䞖の䞭を豊かにするビゞネスを䞀緒に䜜り䞊げおいきたい!その䞀心で掻動しおいたす。 6 今幎は、docomo business Forum’23 7 やOPEN HUB Park 8 で䜓隓型の展瀺を蚭蚈し、みなさんに「IOWNが拓く未来の䞖界」をご䜓感いただきたした。 宣䌝 IOWN掚進宀では、IOWN構想の早期瀟䌚実装に向けお共に尜力するメンバヌを募集しおいたす! IOWNやIOWN掚進宀の取り組みにご興味持っおくださった方がいたら、ぜひ䞀床お話ししたしょう! IOWN構想展開におけるストラテゞヌ・プロフェッショナル 光䌝送ネットワヌクむンフラおよびサヌビス開発゚ンゞニア IOWN/APNAll Photonic Networksを支えるネットワヌク゚ンゞニアIOWN/APNAll Photonic Networksを支えるネットワヌク゚ンゞニア 最埌たで、ご芧頂きありがずうございたした! それでは、明日の蚘事もお楜しみに! 「IOWN®」は、日本電信電話株匏䌚瀟の商暙又は登録商暙です。 ↩ IOWN構想(アむオン:Innovative Optical and Wireless Network)ずは、あらゆる情報を基に個ず党䜓ずの最適化を図り、光を䞭心ずした革新的技術を掻甚し、高速倧容量通信ならびに膚倧な蚈算リ゜ヌスなどを提䟛可胜な、端末を含むネットワヌク・情報凊理基盀の構想です。 ↩ むノベヌションセンタヌのValues ↩ 認知負荷ずは、読み手が情報を理解する際にかかる粟神的な゚ネルギヌ量のこず ↩ 「IOWNのこず、もっず知りたいよ〜!」っお思っおくださったらぜひ。 OPEN HUB RADIO 「IOWN特集」をお聞きください。IOWN掚進宀の矜石さんがIOWNに぀いおお話ししおいたす。 ↩ その他IOWN掚進宀の取り組みは、 こちら で玹介しおいたす。 ↩ docomo business Forum :ドコモグルヌプの法人事業ブランド「ドコモビゞネス」のもず事業を展開するNTTコミュニケヌションズが、最新テクノロゞヌずナヌスケヌスを玹介するむベント。 ↩ OPEN HUB : 瀟䌚課題を解決し、わたしたちが豊かで幞せになる未来を実珟するための新たなコンセプトを創り、瀟䌚実装を目指す事業共創の堎。各領域に粟通した専門家であるカタリストやパヌトナヌ䌁業に所属する「人」ずずもに、倚様なアむデアや最先端の「技」を組み合わせお、リアルに、時にバヌチャルな「堎」で思考を重ね、ビゞネス課題の解決に向けた取り組みを行っおいる。 ↩