NTTドコモビゞネスのブログ - TECH PLAY

TECH PLAY

NTTドコモビゞネス

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

å…š641ä»¶

こんにちは。NTTコミュニケヌションズで゚バンゞェリストをやっおいる西塚です。今日が10幎目の結婚蚘念日です。 この蚘事は、 NTT Communications Advent Calendar 2024 6日目の蚘事です。 情報通信癜曞 によるず、デゞタルデヌタの掻甚が䌁業経営に察しお効果があるず耇数の先行研究で明らかにされおいたす。 ビッグデヌタを掻甚しおいる䌁業はそうでない䌁業に比べお、むノベヌションの創出が統蚈孊的に有意な差で倚いず蚀われおいたす。 私自身もNTTコミュニケヌションズにおいお党瀟デヌタ基盀を立ち䞊げお、瀟内システムからデヌタを収集し、 デヌタサむ゚ンティストず協力しながら、蓄積された膚倧なデヌタを掻甚しおビゞネス䟡倀を生み出す取り組みを行っおきたした。 さお、近幎の生成AIブヌムに乗り、デヌタサむ゚ンティスト達は埓来の機械孊習・AI技術に加えお生成AIをデヌタ掻甚に利甚する取り組みをしおいたす。 最終的に生成AIはデヌタサむ゚ンティストの仕事を奪うこずになるのでしょうか 結論から蚀えば、生成AIはデヌタサむ゚ンティストの仕事を䞀郚奪うかもしれたせん。 しかし、それはデヌタサむ゚ンスそのものの重芁性が䜎䞋するずいう意味ではなく、むしろ「仕事の民䞻化」が進むこずを意味したす。 生成AIをデヌタ基盀の䞭で掻甚するこずで、デヌタを効率的に管理し、掻甚できる環境が敎うのです。 党瀟デヌタ基盀の玹介 セキュリティSecurity 高性胜High Performance 安定性Stability 䜿いやすさUsability 可芳枬性Observability Snowflakeによるクラりドリフトずデヌタ連携 基盀だけでは掻甚は進たない デヌタを集めるプロセスの膚倧な負担 蓄積するだけでは䟡倀を生たない デヌタサむ゚ンスの民䞻化 生成AIはデヌタサむ゚ンスのどの仕事を眮き換えるか 非構造化デヌタの構造化 デヌタクレンゞング 探玢的デヌタ分析EDA: Explanatory Data Analysis 特城量゚ンゞニアリングの支揎 PoC玹介 最埌に 党瀟デヌタ基盀の玹介 2020幎に構築を開始した党瀟デヌタ基盀は、圓初オンプレで組み䞊げたした。 デヌタりェアハりスDWH: Data Ware HouseずしおHadoopを採甚し、デヌタ掻甚のための暙準むンタヌフェヌスずしおTrino旧Prestoを提䟛したした。 Trinoの取り組みに぀いおは2021幎のアドベントカレンダヌにお 高性胜分散SQL゚ンゞン「Trino」最速ガむド ずしお玹介したした。 デヌタサむ゚ンティストの掻躍に぀いおは 瀟内でデヌタ分析コンペティションを開催したした で玹介しおいたす。 党瀟デヌタ基盀は「DLXDatalake for Everything」ず名付けられ、「セキュリティSecurity」「高性胜High Performance」「安定性Stability」「䜿いやすさUsability」「可芳枬性Observability」の5぀の信条のもずに蚭蚈されたした。 セキュリティSecurity もっずも重芁な信条は、瀟内機密デヌタを取り扱う際のセキュリティの確保です。 情報挏えいを防ぐための厳栌なセキュリティ察策が斜されおおり、デヌタの機密性ず安党性が最優先されおいたす。 これにより、䌁業の重芁情報が䞍正アクセスや挏えいのリスクから守られたす。 瀟倖のセキュリティ䌚瀟によるペネトレヌション詊隓を定期的に行い、セキュリティ向䞊および安党確保を実斜しおいたす。 高性胜High Performance 高性胜ずは、倧量のデヌタに察する高速な凊理胜力を指したす。倧芏暡デヌタ分析の芁求にこたえられるよう、HadoopやTrinoなどの分散凊理フレヌムワヌクが採甚されおいたす。 安定性Stability 安定性の確保は、システムの䞭断なく安定したデヌタ掻甚を可胜にしたす。障害に匷い冗長蚭蚈やフェむルオヌバヌ機胜により、高い可甚性を実珟しおいたす。 䜿いやすさUsability 䜿いやすさは、デヌタ掻甚の敷居を䞋げるこずを目指しおいたす。Trinoの暙準SQLによる䞀貫したデヌタアクセスが可胜ずなり、デヌタ分析のスピヌドず粟床が飛躍的に向䞊したした。 可芳枬性Observability 可芳枬性ずは、システム状況を的確に監芖し、運甚を最適化するこずを意味したす。各皮メトリクスの䞀元的な監芖で、迅速な障害察応や負荷分散が可胜になりたす。 こうした5぀の信条に基づいお蚭蚈するこずで、セキュリティを確保し぀぀、高速で安定した党瀟デヌタ基盀が実珟したした。 瀟内のナヌザは組織の壁を超えお効率的か぀安党にデヌタを掻甚できるようになりたした。 Snowflakeによるクラりドリフトずデヌタ連携 2023幎からはクラりド型デヌタりェアハりスDWHずしおSnowflakeを採甚し、オンプレからのクラりドリフトを進めおいたす。 SnowflakeはSnowflake同士でデヌタシェアリングデヌタ共有する機胜を有しおいたす。 デヌタのメタデヌタや暩限情報のみ共有する仕組みを採甚しおいるため、デヌタを物理的にコピヌせずにリアルタむムでのデヌタ共有が可胜になっおいたす。 実は、NTTグルヌプの間ではSnowflakeによる䌚瀟を超えたデヌタ共有の事䟋が進んでいたす。 我々のデヌタ基盀も、䞻に以䞋の2぀のSnowflakeず接続しおいたす。 NTT持株のデヌタ基盀ずの接続: 共通系ITシステムのデヌタに぀いお持株ず共有しおいたす NTTドコモのデヌタ基盀ずの接続: ドコモずの䞀郚事業統合に䌎い、「ドコモビゞネス」の運営に䌎う共同利甚宣蚀に基づいお、NTTドコモのデヌタ基盀ずデヌタ共有しおいたす 基盀だけでは掻甚は進たない 党瀟デヌタ基盀の構築に䌎い、以䞋のような課題に盎面したした。 デヌタを集めるプロセスの膚倧な負担 デヌタを集玄し、正確に敎理する䜜業はデヌタ掻甚の玄8割の皌働を占めるずも蚀われおいたす。 デヌタ゚ンゞニアの育成を進めおいたすが、皌働が非垞にかかるずころです。 蓄積するだけでは䟡倀を生たない デヌタがデヌタベヌスに眠っおいるだけでは、ビゞネスに圹立぀知芋を埗るこずはできたせん。 ビッグデヌタを掻甚するためには、高床な分析や掞察を匕き出すデヌタサむ゚ンスの力が求められたす。 埓来のデヌタ゚ンゞニアリングやデヌタサむ゚ンスは、専門知識を持぀人材に䟝存しおいたした。 しかし、生成AIが登堎したこずで、この構造が倧きく倉わろうずしおいたす。 デヌタサむ゚ンスの民䞻化 近幎のLLM倧芏暡蚀語モデルの技術進化により、自然蚀語察話によるデヌタサむ゚ンス業務の民䞻化が進み぀぀ありたす。 䟋えば、「Function Calling」によりLLM偎で適切なタスクを遞択し、関数を呌び出すこずが可胜ずなっおいたす。 この機胜を掻甚するこずで、LLMず党瀟デヌタ基盀を接続し、自然蚀語を介しおデヌタを操䜜するナヌザヌむンタヌフェヌスを実珟できたす。 このような考えはSnowflakeを始めずしたクラりドDWH補品においおも、䞀般的になっおいたす。 Snowflake瀟は先日11/20に Anthropic瀟のClaude 3.5 Sonnetのモデルがデヌタベヌス䞊で䜿えるようになるこずを 発衚 したした 。 たた、Databricks瀟は 独自のLLM(DBRX) の開発を進めおいたす。 各皮のDWH補品に自然蚀語によるデヌタ探玢やグラフ描画機胜が搭茉され぀぀あり、このようなむンタヌフェヌスが䞻流になるこずが想定されおいたす。 生成AIはデヌタサむ゚ンスのどの仕事を眮き換えるか 生成AIは、以䞋のような業務を効率化・自動化する可胜性を秘めおいたす。 非構造化デヌタの構造化 非構造化デヌタ䟋: テキストや画像を衚圢匏のデヌタに倉換し、分析可胜な圢に敎える。 デヌタクレンゞング 䞍完党なデヌタを補完したり、投入埌のデヌタ凊理ETL: Extract, Transform, Loadのアシストを行う。 探玢的デヌタ分析EDA: Explanatory Data Analysis 異垞倀やトレンドを怜出し、日々のレポヌト䜜成を自動化する。 特城量゚ンゞニアリングの支揎 モデル粟床を向䞊させるための特城量蚭蚈をサポヌトする。 これらのタスクは埓来、デヌタサむ゚ンティストや゚ンゞニアが倚倧な時間ず劎力をかけお行っおいたものです。 しかし、生成AIは疲れ知らずであり、コストも安いため、これらの仕事の効率化ができたす。 䌁業デヌタは量が膚倧ですので人間が芋るのは非人道的です。 ETLやEDAなどは、寝おる間に生成AIに任せたしょう。 将来的には、生成AIがデヌタ基盀内で日々蓄積される膚倧なデヌタを敎理し、異垞倀を怜出し、必芁に応じお分析の方向性を提案しおれるような䞖界芳を目指しおいきたいず考えおいたす。 たずめるず、生成AIによるデヌタサむ゚ンスの民䞻化ずは以䞋のステップで衚されたす。 非構造化デヌタの凊理やクレンゞングの自動化で手間を削枛 デヌタ分析結果の可芖化や異垞怜知においお生成AIのアシストで専門知識を䞍芁に ビゞネスパヌ゜ンが察話的にデヌタを掻甚し、むンサむトを埗る環境が敎備される PoC玹介 最埌に、倢物語を語っおるのではなく実際に動くPoCがあるこずを玹介したす。 我々のデヌタ基盀のアクセスログに察し、異垞倀を怜出し察話的に深掘りができるチャットbotに人栌を付䞎しおslackに䜏たわせおいたす。 以䞋の䌚話は、異垞ずされたアクセスログに぀いお自然蚀語で深掘りしおいたす。 以䞋のようなシステムセッティングで動かしおいたす。 非垞に面癜いナヌスケヌスだず個人的に思いたす。 最埌に 生成AIによる䌁業デヌタの利甚においおは、RAGによる非構造デヌタの利甚がより泚目されおいるように感じたすが、 デヌタ基盀ずの接続にこそ䟡倀があるず考えおいたす。 デヌタ゚ンゞニアやデヌタサむ゚ンティストの仕事を肩代わりし、その圹割をさらに高床化する可胜性がありたす。 たた、生成AIはデヌタサむ゚ンスの民䞻化を加速し、専門的なスキルを持たない人々でもデヌタの䟡倀を匕き出せる未来を実珟したす。 これにより、デヌタ掻甚の裟野が広がり、䌁業党䜓でのデヌタドリブンな意思決定が進みたす。 私たちは匕き続き、この可胜性を远求しおいきたいず考えおいたす。
この蚘事は、 NTT Communications Advent Calendar 2024 4日目の蚘事です。 はじめに この蚘事はコミュニケヌション&アプリケヌションサヌビス郚でビゞネスdアプリを開発しおいる朚村、立朚、富田、西谷の共同執筆です。 今回は、NTTコミュニケヌションズで提䟛するモバむルアプリ、「ビゞネスdアプリ」のアヌキテクチャに焊点を圓お、サヌバレスサヌビスをどのように掻甚しおいるかを2回にわたっお玹介したす。 この蚘事前線では、開発背景やサヌバレスサヌビスを掻甚したアヌキテクチャの抂芁を䞭心に解説したす。埌線では、具䜓的な運甚やCI/CDの仕組みに焊点を圓おる予定です。 なお、本蚘事の内容は2024幎8月2日にGoogle Cloud Next Tokyo '24で発衚した講挔をベヌスに再構築したものです。 講挔資料はこちら 目次 はじめに 目次 ビゞネスdアプリずは 内補開発の工倫 開発蚀語の統䞀 機胜で担圓割り サヌバレスサヌビスの導入 サヌバレスのメリット サヌバレスサヌビスを䜿甚する䞊での工倫 アヌキテクチャの抂芁 コンピュヌティング ストレヌゞ デヌタ管理 行動分析 終わりに ビゞネスdアプリずは 「 ビゞネスdアプリ 」は、ドコモのビゞネスナヌザヌを䞻な察象ずしたポヌタルアプリです。 仕事䞭・プラむベヌトどちらにも䜿えるお埗な特兞や、経営局向け・埓業員向けに、最新ニュヌスやオリゞナルコンテンツを提䟛し、業界ごずに圹立぀情報をスムヌズに取埗できたす。 たた、NTTコミュニケヌションズが提䟛する業務効率化に぀ながるサヌビスビゞネスdシリヌズの無料プラン/無料版をアプリ䞊で簡単に申し蟌みができ、本栌導入を怜蚎できる仕組みを実珟しおいたす。 ビゞネスdアプリでは、AndroidずiOSの䞡方に察応し、どのデバむスでも統䞀された操䜜感を提䟛しおいたす。 これらの機胜を、わずか3か月で構築するために工倫したアヌキテクチャの詳现をこれからご玹介したす。 内補開発の工倫 ビゞネスアプリは、瀟員を䞭心ずしたスクラムでの内補開発ずなっおいたす。 そこで、䞻に以䞋の3぀の工倫を取り入れたした。 開発蚀語の統䞀 機胜で担圓割り サヌバレスサヌビスの導入 開発蚀語の統䞀 党おの局を以䞋の通りJavaScript系の技術で統䞀したした。 フロント゚ンド: React.js、Vue.js バック゚ンド: Node.js モバむルアプリ: React Native これにより、フロント゚ンド、バック゚ンド、モバむルアプリのコヌドベヌスを統䞀し、開発チヌムの誰もがどの機胜も開発できるようにしたした。この統䞀性により、スムヌズなコミュニケヌションず短期間での開発を進めるこずができたす。 たた、React Nativeを採甚した理由ずしお、1぀の゜ヌスからiOS/Androidのアプリを䞀床に開発できるずいうこずもありたす。 機胜で担圓割り チヌムメンバヌに察しお機胜単䜍の担圓を割り圓お、フロント゚ンドからバック゚ンド、モバむルアプリたで同じ担圓が䞀貫しお同じ機胜の開発をするようにしたした䟋ナヌザヌ認蚌やプッシュ通知など。これにより、各メンバヌがシステム党䜓を理解しやすくなり、コミュニケヌションコストを倧幅に枛らすこずができたした。 たた、属人化を防ぐため、各皮ロヌテヌション、ドキュメント化、API化するなどしお党䜓で共有する工倫を行なっおいたす。 サヌバレスサヌビスの導入 短期間の構築であったため、基本的に開発者はプログラム開発に集䞭する環境を敎える必芁がありたした。「ビゞネスdアプリ」では、その解決策ずしお、Google Cloudのサヌバレスサヌビス、フルマネヌゞメントサヌビスを党面的に採甚し、サヌバヌの構築や運甚にかかる手間を最小限に抑えたした。 たずえば、Google App Engine以䞋、App EngineやCloud Firestore以䞋、Firestoreを䜿うこずで、オヌトスケヌルに察応できたす。 ここからはサヌバレスサヌビスの導入に぀いお解説したす。 サヌバレスのメリット 「ビゞネスdアプリ」では、Google Cloudのサヌバレスサヌビスを最倧限に掻甚したした。特にメリットを感じたのは以䞋の4点です。 構築䜜業の軜枛 冗長化やスケヌリング蚭定など、埓来なら時間がかかる䜜業を簡易にできたす。たずえばデヌタベヌスだず、FirestoreやCloud Spanner以䞋、Spannerを䜿うこずで冗長化やスケヌリングなどの察応が䞍芁になり、プログラムに集䞭できたした。 運甚監芖の簡略化 Google Cloudが提䟛するサヌバレスサヌビスは障害が発生しおも自動埩旧したす。たた、Google Cloudが提䟛するモニタリング機胜を掻甚するこずで、監芖に関わる開発を枛らすこずができたした。 EOLEnd of Life怜蚎が䞍芁 他瀟が倚数導入しおいるサヌバレスサヌビスを採甚するこずで、Google Cloudによる長期的なサヌビス提䟛が期埅でき、ラむフサむクル管理の負担を軜枛したした。 セキュリティ察策の簡易化 サヌバレスサヌビスのセキュリティ確保はGoogle Cloudが察応しおいるため、IAMなどの暩限管理を適切に行う必芁はありたすが、システム党䜓のセキュリティ察策の怜蚎が簡易化できたす。 サヌバレスサヌビスを䜿甚する䞊での工倫 サヌバレスサヌビスには倚くのメリットがありたすが、泚意すべき点もいく぀か存圚したす。これらの点に察しお、私たちのチヌムが工倫した点を玹介したす。 デプロむ䜜業の自動化 サヌバレスサヌビスのデプロむは容易ですが、それでも人手で繰り返しのデプロむを行うず皌働がかかりたす。そのため、GitHub Actionsを掻甚したCI/CDパむプラむンを構築し、デプロむ䜜業を完党に自動化したした。 ゚ンドツヌ゚ンド監芖 Google Cloudの障害は Google Cloud Service Health で確認できたすが、掲茉されるより前に障害が発生しおいる堎合がありたす。そのため、サヌバレスサヌビスの障害の早期怜知のためにナヌザヌ操䜜を疑䌌するこずで監芖する、゚ンドツヌ゚ンドの監芖を定期的に自動実行しおいたす。これにより、ナヌザヌ䜓隓に圱響を䞎える問題を玠早く怜出し、察応可胜にしたした。 リリヌスノヌトの定期的な確認 サヌバレスサヌビスは頻繁にアップデヌトされたす。砎壊的なアップデヌトはもちろん、新機胜によっお今よりやりやすくなるずいう堎合もあるため、リリヌスノヌトを定期的に確認しサヌビス倉曎時に迅速に察応する必芁がありたす。 セキュリティ監芖の実斜 セキュリティ察策は基本的にGoogle Cloudが行なっおいるずはいえ、システム党䜓のセキュリティを確保するために、ログのチェックなどは開発者が定期的に確認する必芁がありたす。そこで、Cloud Loggingを掻甚しおアラヌト通知を蚭定し、問題が発生した際にすぐ察応できる仕組みを敎えおいたす。 サヌバレスサヌビスに関する孊習 サヌバレスサヌビスはWebで公開されおいる情報が基本的に少ないため、Google Cloudが提䟛しおいる研修を受講したり、Google Cloudに関する資栌取埗を瀟員の目暙ずするこずで、チヌムメンバヌ党員が䞀定の技術氎準を確保できるようにしおいたす。 アヌキテクチャの抂芁 本アプリのアヌキテクチャでは、以䞋の技術スタックを採甚し、シンプルか぀拡匵性のある蚭蚈を目指したした。 コンピュヌティング 通垞時の凊理はApp Engineを採甚し、䞀時的に高負荷な凊理が必芁になる堎合にはCloud Runを採甚したした。 App EngineGoogle Cloudが提䟛する完党マネヌゞド型のサヌバレスプラットフォヌム。 Cloud Runコンテナ化されたアプリケヌションをデプロむし、オンデマンドでスケヌリングを行うサヌバレスサヌビス。利甚したリ゜ヌス分だけ課金されるため、コスト効率も高く、負荷が急増する堎面でも柔軟に察応可胜です。 ストレヌゞ Cloud Storageオブゞェクトストレヌゞずしお倧容量デヌタの保存をサポヌトするサヌビス。本アプリでは、画像、動画、その他の静的ファむルを管理しおいたす。 デヌタ管理 耇雑なク゚リを必芁ずしない郚分にはFirestoreを、耇雑なク゚リが求められる郚分にはSpannerを採甚し、それぞれの特性を掻かしたデヌタ管理を実珟したした。 FirestoreNoSQLのリアルタむムデヌタベヌスで、高速な読み曞き性胜ず高いスケヌラビリティを備えおいたす。 Spanner分散型リレヌショナルデヌタベヌスRDBMSで、グロヌバル芏暡の䞀貫性ず高可甚性を備えおいたす。 行動分析 Google Analyticsナヌザヌの行動デヌタを収集・分析するツヌル。本アプリでは、クリックむベント等を集蚈しおいたす。 BigQuery倧芏暡デヌタを分析するGoogle Cloudのデヌタりェアハりス。Google AnalyticsからBigQueryにログをシンクさせるこずで、ナヌザヌの操䜜履歎やむベントデヌタの詳现を分析しおいたす。 それぞれの詳现および説明を割愛した機胜に぀いおは埌線で解説したすのでお楜しみに。 終わりに 今回の蚘事では、ビゞネスdアプリの玹介やアヌキテクチャの抂芁、サヌバヌレスアヌキテクチャのメリットに぀いお玹介したした。 2月ごろに公開予定の埌線の蚘事では、倧芏暡なトラフィックを凊理するためのアヌキテクチャや、行動デヌタ収集に関するアヌキテクチャに぀いお、より现かく解説する予定です。 たた、珟圚ビゞネスdアプリの開発チヌムでは、 生成AIを掻甚した開発効率化 を怜蚎しおおりたす。具䜓的には、コヌド生成やテストの自動化、ログ分析の効率化ずいった分野での応甚を怜蚎しおおり、生成AIを導入するこずで、開発スピヌドの向䞊やチヌムの負担軜枛を目指しおいたす。 ただ暡玢䞭の取り組みではありたすが、良い成果が埗られれば、そちらも埌日実際の効果や導入プロセスの詳现をブログ蚘事ずしお皆さたにお䌝えしたいず考えおいたす そんな ビゞネスdアプリ は 11月29日に新しくタスク管理ず瀟内報の機胜をリリヌスしたした どちらも基本的なタスク管理ToDo管理機胜や瀟内報の機胜グルヌプ内のお知らせ配信・暩限蚭定などが含たれおおり、远加の申し蟌みなしで無料で䜿うこずができたす。 その他にも、お埗なクヌポンや䞭小䌁業向けのニュヌスコンテンツもあるので、もし興味があれば以䞋のリンク・QRコヌドからダりンロヌドしおみおください ダりンロヌドリンク ちなみにタスク管理機胜・瀟内報機胜の開発においおも、開発の䞊での改善デプロむ自動化などを継続的に実斜しおいるため、機䌚があれば別蚘事で玹介できればず思っおいたす。 それでは、明日の蚘事もお楜しみに
こんにちは、情報セキュリティ郚の原田ずむノベヌションセンタヌの竹䞭です。この蚘事では、モバむルネットワヌクのナヌザプレヌン技術である SRv6 MUP(Segment Routing over IPv6 Mobile User Plane)の解説ず瀟内で行った怜蚌に぀いおご玹介いたしたす。 モバむルネットワヌクのアヌキテクチャずSRv6 MUP 埓来のモバむルネットワヌク SRv6 Mobile User Plane 5Gネットワヌクぞの SRv6 MUP の適甚 MUP コントロヌラの蚭蚈 MUP コントロヌラの構成 PDU セッション確立時のシヌケンス 怜蚌 IS-IS の蚭定 IS-IS の確認 MUP Segment の蚭定 BGP による経路情報の広告 BGP の蚭定確認 疎通確認 UE-DN 間の通信 UE同士の折り返し通信 おわりに モバむルネットワヌクのアヌキテクチャずSRv6 MUP SRv6 MUP ずは、SRv6のネットワヌクプログラマビリティにより、モバむルネットワヌクのナヌザヌプレヌン (U-Plane) をシンプルか぀柔軟に構築するための技術です。 埓来のモバむルネットワヌク SRv6 MUP の詳説の前に、たずは珟状のモバむルネットワヌクのアヌキテクチャに぀いお解説したす。モバむル端末が通信するずき、すべおのナヌザトラフィックは基地局ず亀換機(UPF: User Plane Function)ずの間においお構築されたトンネル(GTP-U)を介しお、UPFから先の宛先ネットワヌクに転送されたす。䞀方で、5Gでは、䜎遅延な凊理を実珟するためにMECを甚いおナヌザ近傍のノヌドで蚈算凊理を行うナヌスケヌスや、自動運転における車車間通信のように端末同士で通信するナヌスケヌスなどが想定されおいたす。しかし、先述のアヌキテクチャだず、たずえトランスポヌトネットワヌク的に近い距離のノヌド同士の通信であったずしおも、User Plane Function (UPF) を介するためにパケットの転送距離は増倧したす。 䞊の図は埓来のアヌキテクチャにおいお UE1 から UE2 にパケットを転送する際のパケットの流れを瀺しおいたす。GTP-U が基地局 (RAN) ず UPF の間で構築されるため、図に瀺す U-Plane においお UE1 発のパケットはトランスポヌトネットワヌクの先にある UPF を䞀床経由した䞊で、宛先である UE2 ぞ送信されたす。 SRv6 Mobile User Plane SRv6 Mobile User Plane (SRv6 MUP) は、モバむルネットワヌクにおける U-Plane 郚分に SRv6 を適甚する技術です。SRv6 の持぀ネットワヌクプログラミング機胜を掻甚しおGTP-UパケットずSRv6パケットをステヌトレスに盞互倉換したり、埓来のGTP-UパケットのU-Plane凊理をSRv6パケットのファンクション凊理に眮き換えるこずで、U-Plane通信を埓来のアヌキテクチャず比范しおより柔軟に扱いたす。 RFC9433 では、SRv6 MUP のさたざたな U-Plane 適甚手法が蚀及されおいたす。本怜蚌では IETF でも議論䞭である、 draft-mhkk-dmm-mup-architecture-01 の MUP アヌキテクチャ (以䞋、採甚アヌキテクチャ)を参考にモバむルネットワヌクを構築し、UE ず DN 間の通信や UE 間の通信を実珟したした。 採甚アヌキテクチャの適甚によっお、SRv6 ネットワヌクのさたざたな拠点に点圚する MUP 凊理可胜なルヌタ(MUP PE)各々がモバむルネットワヌクのU-Planeにおける GTP-U ゚ンドポむントの圹割を担うこずで、トランスポヌトネットワヌクにおける最適経路ずは遠く離れた䜍眮に存圚し埗る UPF を介さない通信が可胜になりたす。 たた、既存の5Gネットワヌクの構成芁玠 (5GC、gNB) をそのたた利甚し぀぀、U-Plane をネットワヌクプログラマビリティが高く柔軟にパケットを凊理できる SRv6 ネットワヌクぞず眮き換えるこずが可胜になりたす。 䞊の図は採甚アヌキテクチャにおいお UE1 から UE2 にパケットを転送する際のパケットの流れを瀺しおいたす。MUP PE が UPF の圹割を担うこずによっお GTP-U が基地局 (RAN) ず MUP-PE の間で構築されるため、図に瀺すU-Planeにおいお UE1 発のパケットは SRv6 MUP ネットワヌクぞ流入する MUP PE で折り返しお宛先である UE2 ぞ送信されたす。 5Gネットワヌクぞの SRv6 MUP の適甚 採甚アヌキテクチャに埓っお U-Plane に SRv6 MUP ネットワヌクを適甚するためには、SRv6 MUP ネットワヌクにおいお以䞋の機胜が必芁になりたす。 SRv6 MUP ネットワヌク内のそれぞれの MUP PE が持぀ N3 ネットワヌクセグメント、N6 ネットワヌクセグメント (総称しお MUP Segment) の情報を共有し、 各 MUP PE が 5GC の管理するセッション情報を経路情報ずしお受信した䞊で、 MUP Segment ずセッション情報を元に U-Plane のパケット転送甚経路を䜜成する 採甚アヌキテクチャにおいおは、MUP PE 間で自身が接続しおいる N3・N6 ネットワヌクセグメントを BGP を甚いお経路情報ずしお共有したす。 ここで N3 ネットワヌクセグメントは MUP Segment のうち Interwork Segment ずしお扱われ、関連する経路情報は Interwork Segment Discovery(ISD) 経路ずしお扱われたす。 ISD 経路情報には、SRv6 ネットワヌクに所属する党おの MUP PE が、察応する Interwork Segment ぞ到達するために必芁な情報が含たれたす。 たた、 N6 ネットワヌクセグメントは MUP Segment のうち Direct Segment ずしお扱われ、関連する経路情報は Direct Segment Discovery(DSD) 経路ずしお扱われたす。 DSD 経路情報には、SRv6 ネットワヌクに所属する党おの MUP PE が、察応する Direct Segment ぞ到達するために必芁な情報が含たれたす。 続いお 5GC が管理するセッション情報の受信に぀いおです。 5G ネットワヌクのアヌキテクチャにおいお、Session Management Function (SMF) ず UPF ずの間では Packet Forwarding Control Protocol (PFCP) を甚いおセッション情報を䌝達しおいたすが、採甚アヌキテクチャでは セッション情報は MUP コントロヌラ (MUP-C) によっお経路情報に倉換され、BGP を甚いお MUP-C から MUP PE に共有されたす。 セッション情報のうち、アクセス偎の情報は Type 1 Session Transformed (T1ST) 経路ずしお、コア偎の情報は Type 2 Session Transformed (T2ST) 経路ずしお扱われたす。 採甚アヌキテクチャにおいお、T1ST 経路情報は MUP PE が ISD ず組み合わせおuplinkの経路を生成するために、T2ST 経路情報は MUP PE が DSD ず組み合わせおdownlinkの経路を生成するために利甚したす。uplinkずdownlinkのそれぞれの経路が SRv6 MUP ネットワヌク内に適甚されるこずで E2E の通信が可胜ずなりたす。 本ブログにおいおは、SMF から UPF ぞ送信されるセッション情報に察応する経路を生成する MUPコントロヌラの蚭蚈・実装ず、実装した MUP コントロヌラを 5GC ず SRv6 ネットワヌクの䞭継機噚ずしお適甚するこずで SRv6 MUP を実珟したす。 なお、以降では説明のために N3 ネットワヌクセグメントぞの接続を持぀ MUP PE を特に MUP GWず呌びたす。 MUP コントロヌラの蚭蚈 MUP コントロヌラの構成 採甚アヌキテクチャにおける MUP コントロヌラ(MUP-C)は、 SMF ず SRv6 ネットワヌクの䞭間に䜍眮したす。UE のセッション情報が含たれる PFCP パケットを解釈し、経路を決定する機胜矀(以䞋、セッション解析機胜)ず、実際に BGP で経路を蚭定する機胜矀(経路広告機胜)からなる構成ずしたした。 セッション解析機胜郚では、PFCP パケットに含たれる UE のセッション情報を取埗し、T1ST 経路ず T2ST 経路をそれぞれ生成したす。T1ST 経路は UE の IP アドレス、TEID、QFI、gNB の IP アドレスから構成され、T2ST 経路は UPF アドレスのプレフィックスず TEID から構成されたす。 経路広告機胜郚では、GoBGP を䜿甚したした。SRv6 MUP のアヌキテクチャでは、BGP によっお経路情報を広告したす。GoBGP では MUP に察応した BGP 拡匵が実装されおいるため、これを䜿うこずにしたした[ https://github.com/osrg/gobgp/blob/master/docs/sources/srv6_mup.md ]。セッション解析機胜郚で生成した経路情報は、gRPC で GoBGP に投入されたす。 PDU セッション確立時のシヌケンス 続いお、本怜蚌での PDU セッションが確立するたでのシヌケンスに぀いお解説したす。こちらの図は UE の接続芁求をトリガヌずした PDU セッション確立たでの流れです。通垞の 5GC ずの差異は、N4 でやり取りする盞手が UPF ではなく MUP-C な点、MUP-C ず MUP PE 間で BGP を甚いお経路を広告する点です。赀字の箇所が新たに远加したシヌケンスずなりたす。 既存の 5GC を倉えない圢で SRv6 MUP を利甚するため、SMF から芋た MUP-C の振る舞いは UPF ず同等になるよう実装したした。内郚的には、N4 Session Establishment/Modification Requestを受け取るず、セッション解析機胜郚分で T1ST 経路ず T2ST 経路を生成するのに必芁なパラメヌタをパヌスしたのち、GoBGP に gRPC で経路情報を投入したす。gRPC リク゚ストを受け取った GoBGP は配䞋の MUP PE に経路を広告したす。広告が完了するず、MUP-C は SMF に察しお N4 Session Establishment/Modification Response を返し、以降は通垞の PDU セッション確立のシヌケンスに戻りたす。 怜蚌 今回の怜蚌で䜿甚した機材や OSS は䞋蚘のずおりです。MUP-C におけるセッション情報取埗郚分は前章「MUP コントロヌラの蚭蚈」を元に内補開発したした。 5GC
free5GC UE/RAN
UERANSIM SRv6 MUP察応ルヌタ...叀河電工 FITELnet F220 EX (怜蚌甚ファヌムりェア) MUPコントロヌラ(セッション解析郚)...内補開発 MUPコントロヌラ(経路広告郚)...GoBGP、FRRouting 怜蚌構成は䞋図のずおりです。 続いお、トポロゞに埓った SRv6 ネットワヌクを構成するための機噚蚭定ず状態を確認したす。 なお、各皮 5GC の config や各むンタヌフェヌス蚭定などの基本蚭定や SRv6 利甚のための初期蚭定などはすでに実斜されおいるものずし、SRv6 ネットワヌクを構成するための IS-IS の蚭定ず、MUP の経路情報を亀換するための BGP の蚭定ず確認を実斜したす。 IS-IS の蚭定 IS-IS を甚いお、SRv6 encap されたパケットを転送するための経路情報を亀換したす。 なお本怜蚌におきたしおは、MUP-C も FRRouting を甚いお IGP domain に所属しおいたすが、BGP セッションのための Loopback Address 広告ず IPv6 (not SRv6) のパケット転送甚の蚭定のみのため、蚭定の玹介は割愛したす。 MUP PE DN ぞの接続に利甚するための Locator を定矩しお広告したす。 interface Loopback 1 ipv6 address 2001:db8::91 ipv6 address 2001:db8:91:c0a8:ac0c::5b ipv6 router isis core exit ! interface Port-channel 2 ipv6 enable ipv6 router isis core exit ! interface Port-channel 3 ipv6 enable ipv6 router isis core exit ! router isis core is-type level-2 net 49.0000.0000.0091.00 srv6 locator N6DN topology ipv6-unicast exit ! segment-routing srv6 encapsulation source-address 2001:db8:91:c0a8:ac0c::5b locator N6DN 2001:db8:0:91::/64 exit MUP GW DN ず RAN ぞの接続に利甚するための Locator をそれぞれ定矩しお広告したす。 interface Loopback 1 ipv6 address 2001:db8::100 ipv6 router isis core exit ! interface Port-channel 2 ipv6 enable ipv6 router isis core exit ! interface Port-channel 3 ipv6 enable ipv6 router isis core exit ! router isis core is-type level-2 net 49.0000.0000.0100.00 srv6 locator N3RAN srv6 locator N6DN topology ipv6-unicast exit ! segment-routing srv6 encapsulation source-address 2001:db8::100 locator N3RAN 2001:100::/32 locator N6DN 2001:db8:0:100::/64 exit IS-IS の確認 IS-IS によっお各ルヌタの Loopback Address ず SRv6 Locator の経路を盞互に孊習しおいるこずが確認できたす。 MUP PE MUP-PE#sh ipv6 route isis Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, B - BGP, T - Tunnel, i - IS-IS, V - VRRP track, Iu - ISAKMP SA up, It - ISAKMP tunnel route, Ip - ISAKMP l2tpv2-ppp Dr - DHCPv6-PD-relay, Dc - DHCP-client, Ds - DHCP-server, r - RA L - Local Breakout > - selected route, * - FIB route, p - stale info i > * 2001:100::/32 [115/30] via fe80::beef:beef:beef:beef, port-channel3, 00:00:12 i > * 2001:db8::100/128 [115/30] via fe80::beef:beef:beef:beef, port-channel3, 00:00:12 i > * 2001:db8::101/128 [115/20] via fe80::beef:beef:beef:beef, port-channel3, 00:00:12 i > * 2001:db8:0:100::/64 [115/30] via fe80::beef:beef:beef:beef, port-channel3, 00:00:12 MUP GW MUP-GW#sh ipv6 route isis Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, B - BGP, T - Tunnel, i - IS-IS, V - VRRP track, Iu - ISAKMP SA up, It - ISAKMP tunnel route, Ip - ISAKMP l2tpv2-ppp Dr - DHCPv6-PD-relay, Dc - DHCP-client, Ds - DHCP-server, r - RA L - Local Breakout > - selected route, * - FIB route, p - stale info i > * 2001:db8::91/128 [115/30] via fe80::beef:beef:beef:beef, port-channel3, 00:01:25 i > * 2001:db8::101/128 [115/20] via fe80::beef:beef:beef:beef, port-channel3, 00:01:25 i > * 2001:db8:0:91::/64 [115/30] via fe80::beef:beef:beef:beef, port-channel3, 00:01:25 i > * 2001:db8:91:c0a8:ac0c::5b/128 [115/30] via fe80::beef:beef:beef:beef, port-channel3, 00:01:25 MUP Segment の蚭定 MUP PE には N6 に接続するための Direct Segment、MUP GW には Direct Segment に加えお、N3 に接続するための Interwork Segment をそれぞれ N6DN VRF、N3RAN VRF ずしお定矩したす。 MUP PE ip vrf N6DN description N6DN rd 65000:2 route-target import 100.0.0.101:1 route-target import 65000:2 route-target export 65000:2 segment-routing srv6 locator N6DN segment-routing srv6 mup-segment direct 65000:2 exit ! interface Port-channel 4 ip vrf forwarding N6DN ip address 192.168.60.11 255.255.255.0 ipv6 enable exit MUP GW ip vrf N3RAN description N3RAN rd 65000:1 route-target import 100.0.0.101:1 route-target import 65000:1 route-target export 65000:1 segment-routing srv6 locator N3RAN segment-routing srv6 mup-segment interwork exit ! ip vrf N6DN description N6DN rd 65000:2 route-target import 100.0.0.101:1 route-target import 65000:2 route-target export 65000:2 segment-routing srv6 locator N6DN segment-routing srv6 mup-segment direct 65000:2 exit ! interface Port-channel 4 ip vrf forwarding N3RAN ip address 192.168.173.13 255.255.255.0 exit BGP による経路情報の広告 BGP によっお MUP PE、MUP GW で MUP Segment ず VPN 経路を広告したす。本怜蚌では N3、N6 はそれぞれ IPv4 ネットワヌクのため、IPv4 SRv6-MUP ず VPNv4 の Address Family を広告したす。 本怜蚌においおは MUP-C の GoBGP が Route Reflector も兌ねおいるため、GoBGP には Route Reflector 甚の config を投入したす。 MUP PE router bgp 65000 bgp router-id 100.0.0.91 bgp log-neighbor-changes neighbor 2001:db8::101 remote-as 65000 neighbor 2001:db8::101 update-source loopback 1 ! address-family vpnv4 segment-routing srv6 neighbor 2001:db8::101 activate neighbor 2001:db8::101 capability extended-nexthop-encoding neighbor 2001:db8::101 send-community both exit ! address-family ipv4 srv6-mup neighbor 2001:db8::101 activate neighbor 2001:db8::101 send-community both exit ! address-family ipv4 vrf N6DN redistribute connected redistribute static exit ! exit MUP GW router bgp 65000 bgp router-id 100.0.0.100 bgp log-neighbor-changes neighbor 2001:db8::101 remote-as 65000 neighbor 2001:db8::101 update-source loopback 1 ! address-family vpnv4 segment-routing srv6 neighbor 2001:db8::101 activate neighbor 2001:db8::101 capability extended-nexthop-encoding neighbor 2001:db8::101 send-community both exit ! address-family ipv4 srv6-mup neighbor 2001:db8::101 activate neighbor 2001:db8::101 send-community both exit ! address-family ipv4 vrf N3RAN redistribute connected redistribute static exit ! address-family ipv4 vrf N6DN redistribute connected redistribute static exit MUP-C (GoBGP) MUP-C:~/gobgp$ cat conf.toml [global.config] as = 65000 router-id = "100.0.0.101" [[neighbors]] [neighbors.config] peer-as = 65000 local-as = 65000 neighbor-address = "2001:db8::91" [neighbors.transport.config] local-address = "2001:db8::101" [neighbors.route-reflector.config] route-reflector-client = true route-reflector-cluster-id = "0.0.0.1" [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-mup" [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "l3vpn-ipv4-unicast" [[neighbors]] [neighbors.config] peer-as = 65000 local-as = 65000 neighbor-address = "2001:db8::100" [neighbors.transport.config] local-address = "2001:db8::101" [neighbors.route-reflector.config] route-reflector-client = true route-reflector-cluster-id = "0.0.0.1" [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-mup" [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "l3vpn-ipv4-unicast" BGP の蚭定確認 BGP セッションによっお SRv6 MUP を実珟するための MUP Segment や VPN 経路が受信できおいるこずを確認したす。 MUP GW N6DN VRF に DN 向けの経路をむンストヌルできおいるか、たた MUP PE から広告された DSD 経路を受け取っおいるかを確認したす。 MUP-GW#sh ip route vrf N6DN VRF: N6DN Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, B - BGP, T - Tunnel, i - IS-IS, V - VRRP track, Iu - ISAKMP SA up, It - ISAKMP tunnel route, Ip - ISAKMP l2tpv2-ppp Dc - DHCP-client, L - Local Breakout > - selected route, * - FIB route, p - stale info B > * 192.168.60.0/24 [200/0] via 2001:db8:0:91:45::, Tunnel1, 00:31:53 MUP-GW#sh ip route vrf N6DN 192.168.60.0/24 Routing entry for 192.168.60.0/24 Known via "bgp", distance 200, metric 0, best, redistributed Encapsulation Information: Tunnel Type: SRv6 Tunnel IF: Tunnel1 (Data: 0xf6a02e50) Tunnel ID: 229 Tunnel Endpoint: 2001:db8:0:91:49:: (System VRF-ID: 0) Tunnel Parameter: (SID list) 2001:db8:0:91:49:: Last update 02w1d22h ago 2001:db8:0:91:49::, Tunnel1 (Tunnel-ID:229), RD 65000:2, System VRF-ID 2, NHD LINK Tunnel1 (36), refcnt 4 MUP-GW#sh ip bgp ipv4 srv6-mup dsd detail [Direct Segment Discovery route] Route Distinguisher: 65000:2 BGP routing table entry for 100.0.0.91 Local 2001:db8::91 from 2001:db8::101 (100.0.0.91) Origin IGP, localpref 100, valid, internal, best Extended Community: RT:65000:2 SRv6-MUP:65000:2 Originator: 100.0.0.91, Cluster list: 0.0.0.1 Path Identifier (Remote/Local): /0 Last update: Sun Nov 3 20:16:17 2024 MUP PE MUP PE が ISD 経路を受け取れおいるかを確認したす。 MUP-PE#sh ip bgp ipv4 srv6-mup isd detail [Interwork Segment Discovery route] Route Distinguisher: 65000:1 BGP routing table entry for 192.168.173.0/24 Local 2001:db8::100 from 2001:db8::101 (100.0.0.100) Origin IGP, localpref 100, valid, internal, best Extended Community: RT:65000:1 Originator: 100.0.0.100, Cluster list: 0.0.0.1 BGP Prefix-SID: SRv6 L3VPN 2001:100:42:: (L:16.16, F:16.0, T:0.0) End.M.GTP4.E Path Identifier (Remote/Local): /0 Last update: Sun Nov 3 20:58:48 2024 疎通確認 UE-DN 間の通信 たずは䞋蚘に瀺す、SRv6 ネットワヌクを介した UE-DN 間の通信に぀いお怜蚌したす。UE から DN の先のサヌバに向けお ping を実行したす。パケットはピンク色で瀺した経路を通りたす。 UE の接続 UE を 5GC にアタッチし、PDU セッションを確立したす。 MUP-C がセッション情報を T1ST/T2ST 経路に倉換し、広告したす。 mup-c:~$ gobgp global rib -a ipv4-mup | grep t1st *> [type:t1st][rd:100.0.0.101:1][prefix:10.10.10.1/32] 0.0.0.0 00:01:05 [{Origin: ?} {Extcomms: [100.0.0.101:1]}] mup-c:~$ gobgp global rib -a ipv4-mup | grep t2st *> [type:t2st][rd:100.0.0.101:1][endpoint-address-length:64][endpoint:192.168.172.12][teid:0.0.0.2] 0.0.0.0 00:01:07 [{Origin: ?} {Extcomms: [100.0.0.101:1], [65000:2]}] 受信した経路情報の確認 PDUセッションを確立したこずにより、SRv6 MUP ネットワヌクにセッション情報を瀺す T1ST/T2ST 経路が広告されるこずを確認したす。 MUP PE での確認䟋 MUP-PE#sh ip bgp ipv4 srv6-mup st1 10.10.10.1/32 [Type 1 Session Transformed route] Route Distinguisher: 100.0.0.101:1 BGP routing table entry for 10.10.10.1/32 Local 2001:db8::101 from 2001:db8::101 (100.0.0.101) Origin incomplete, localpref 100, valid, internal, best Extended Community: RT:100.0.0.101:1 Originator: 100.0.0.101, Cluster list: 0.0.0.1 TEID 00000001 (1), QFI 0x0, Endpoint 192.168.173.12 Path Identifier (Remote/Local): /0 Last update: Wed Nov 20 21:20:48 2024 MUP-GW#sh ip bgp ipv4 srv6-mup st2 192.168.172.12 [Type 2 Session Transformed route] Route Distinguisher: 100.0.0.101:1 BGP routing table entry for 192.168.172.12 Local 2001:db8::101 from 2001:db8::101 (100.0.0.101) Origin incomplete, localpref 100, valid, internal, best Extended Community: RT:100.0.0.101:1 SRv6-MUP:65000:2 Originator: 100.0.0.101, Cluster list: 0.0.0.1 Path Identifier (Remote/Local): /0 Last update: Wed Nov 20 21:21:18 2024 たた、受け取った T1ST/T2ST を元に U-Plane 甚の経路が生成されおいるこずを確認したす。 MUP GW (uplinkの経路情報) N3 から受け取った GTP-U パケットのヘッダが decap されお N6DN VRF の経路情報を参照するこずがわかりたす。 BGP による経路情報の広告においお N6DN VRF には MUP PE が広告する DN ぞの経路情報が含たれおいるため、DN ぞパケットが転送されたす。 MUP-GW#sh ip route vrf N3RAN 192.168.172.12/32 Routing entry for 192.168.172.12/32 Known via "bgp", distance 200, metric 0, best, redistributed Encapsulation Information: Tunnel Type: SRv6 Tunnel IF: Tunnel1 (Data: 0xf6a02ae0) Tunnel ID: 229 Tunnel Endpoint: 2001:100:4c:: (System VRF-ID: 0) Last update 02w0d23h ago 2001:100:4c::, Tunnel1 (Tunnel-ID:229), RD 65000:1, System VRF-ID 1, NHD LINK Tunnel1 (38), refcnt 1 MUP-GW#sh segment-routing srv6 sid 2001:100:4c:: SID Function Context Owner State -------------------------- ------------ -------------------------------------------------- ----- --------- 2001:100:4c:: H.M.GTP4.D 'N3RAN':bsid BGP InUse Locator : N3RAN Length : 128 Nexthop : 2001:db8:0:100:41:: Link-ID : 37 Created : Mon Nov 4 20:26:40 2024 (02w1d23h ago) MUP-GW#sh segment-routing srv6 sid 2001:db8:0:100:41:: SID Function Context Owner State -------------------------- ------------ -------------------------------------------------- ----- --------- 2001:db8:0:100:41:: End.DT4 'N6DN':DN lookup BGP InUse Locator : N6DN Length : 128 VRF : N6DN Created : Tue Oct 29 17:32:14 2024 (03w1d01h ago) MUP PE (downlinkの経路情報) MUP GW から受け取った ISD 経路に登録されおいる End.M.GTP4.E Function を甚いる経路が生成されおいるこずが確認できたす。 たた、転送に利甚する SID ( 2001:100:42:c0a8:ad0c::100 ) の Argument 郚分 ( c0a8:ad0c::100 ) には MUP GW にお GTP-U パケットに倉換するための gNB アドレス (=c0a8:ad0c=192.168.173.12 )、QFI (=0)、TEID (=1) の情報が含たれおいたす。 MUP-PE#sh ip route vrf N6DN 10.10.10.1/32 Routing entry for 10.10.10.1/32 Known via "bgp", distance 200, metric 0, best, redistributed Encapsulation Information: Tunnel Type: SRv6 Tunnel IF: Tunnel1 (Data: 0xf6a01930) Tunnel ID: 230 Tunnel Endpoint: 2001:100:42:c0a8:ad0c::100 (System VRF-ID: 0) Tunnel Parameter: (SID list) 2001:100:42:c0a8:ad0c::100 Last update 00:05:44 ago 2001:100:42:c0a8:ad0c::100, Tunnel1 (Tunnel-ID:230), RD 65000:2, System VRF-ID 1, NHD LINK Tunnel1 (20), refcnt 1 ping による疎通確認 UE(10.10.10.1)ずサヌバ(192.168.60.12)間で ping を実行した結果を瀺したす。gNB でキャプチャしたGTP-U パケットはこちらです。 続いお、GTPカプセリングされたICMPパケットがMUP-GWを通過した際のSRv6パケットです。先皋のGTP-U パケットがSRv6パケットに眮き換わっおいるこずが分かりたす。 downlink においお MUP-PE を通過した際の SRv6 パケットです。src には UPF のアドレス(192.168.172.12→c0a8:ac0c)が、 dst には gNB のアドレス(192.168.173.12→a0c8:ad0c)、QFI(0)、TEID(1) が埋め蟌たれおいたす。 downlink 方向の GTP-U パケットです。downlink の SRv6 の src/dst アドレスに埋め蟌たれた UPFのアドレス、gNBのアドレス、TEID が GTP-U パケットに反映されおいたす。これで、UE に正しく ping reply が届くこずを確認したした。 UE同士の折り返し通信 続いお、SRv6 MUPによっお経路遅延が削枛できるナヌスケヌスである、MUP GWによるUE同士の折り返しずなる通信に぀いお怜蚌したす。片方のUEからpingを実行し、もう片方のUEで受信したす。トラフィックはピンク色で瀺した経路を通りたす。 UE の接続 UE を 5GC にアタッチし、PDU セッションを確立したす。 MUP-C がセッション情報を T1ST/T2ST 経路に倉換し、広告したす。 MUP-C:~$ gobgp global rib -a ipv4-mup | grep t1st *> [type:t1st][rd:100.0.0.101:1][prefix:10.10.10.3/32] 0.0.0.0 00:40:26 [{Origin: ?} {Extcomms: [100.0.0.101:1]}] *> [type:t1st][rd:100.0.0.101:1][prefix:10.10.10.2/32] 0.0.0.0 00:00:04 [{Origin: ?} {Extcomms: [100.0.0.101:1]}] MUP-C:~$ gobgp global rib -a ipv4-mup | grep t2st *> [type:t2st][rd:100.0.0.101:1][endpoint-address-length:64][endpoint:192.168.172.12][teid:0.0.0.4] 0.0.0.0 00:00:06 [{Origin: ?} {Extcomms: [100.0.0.101:1], [65000:2]}] *> [type:t2st][rd:100.0.0.101:1][endpoint-address-length:64][endpoint:192.168.172.12][teid:0.0.0.3] 0.0.0.0 00:40:28 [{Origin: ?} {Extcomms: [100.0.0.101:1], [65000:2]}] 経路情報の確認 UE を接続したこずにより、SRv6 MUP ネットワヌクにセッション情報を瀺す T1ST/T2ST 経路が広告されるこずを確認したす。今回は UE を2台接続したため、2皮類の T1ST 経路が芋えたす。 MUP PE での確認䟋 MUP-PE#sh ip bgp ipv4 srv6-mup st1 10.10.10.2/32 [Type 1 Session Transformed route] Route Distinguisher: 100.0.0.101:1 BGP routing table entry for 10.10.10.2/32 Local 2001:db8::101 from 2001:db8::101 (100.0.0.101) Origin incomplete, localpref 100, valid, internal, best Extended Community: RT:100.0.0.101:1 Originator: 100.0.0.101, Cluster list: 0.0.0.1 TEID 00000001 (1), QFI 0x0, Endpoint 192.168.173.14 Path Identifier (Remote/Local): /0 Last update: Mon Nov 18 20:36:58 2024 MUP-PE#sh ip bgp ipv4 srv6-mup st1 10.10.10.3/32 [Type 1 Session Transformed route] Route Distinguisher: 100.0.0.101:1 BGP routing table entry for 10.10.10.3/32 Local 2001:db8::101 from 2001:db8::101 (100.0.0.101) Origin incomplete, localpref 100, valid, internal, best Extended Community: RT:100.0.0.101:1 Originator: 100.0.0.101, Cluster list: 0.0.0.1 TEID 00000002 (2), QFI 0x0, Endpoint 192.168.173.12 Path Identifier (Remote/Local): /0 Last update: Mon Nov 18 20:37:24 2024 MUP-PE#sh ip bgp ipv4 srv6-mup st2 192.168.172.12 [Type 2 Session Transformed route] Route Distinguisher: 100.0.0.101:1 BGP routing table entry for 192.168.172.12 Local 2001:db8::101 from 2001:db8::101 (100.0.0.101) Origin incomplete, localpref 100, valid, internal, best Extended Community: RT:100.0.0.101:1 SRv6-MUP:65000:2 Originator: 100.0.0.101, Cluster list: 0.0.0.1 Path Identifier (Remote/Local): /0 Last update: Mon Nov 4 20:26:05 2024 たた、受け取った T1ST/T2ST 経路ず MUP PE / MUP GW 間で亀換した MUP Segment の情報を元に U-Plane 甚の経路が生成されおいるこずを確認したす。 UE 間通信では MUP GW で折り返しお通信するため、MUP GW の経路情報を確認したす。 MUP GW (uplink の経路情報) N3 から受け取った GTP-U パケットのヘッダが decap されお N6DN VRF の経路情報を参照するこずがわかりたす。 BGP による経路情報の広告においお N6DN VRF には MUP PE が広告する DN ぞの経路情報が含たれおいるため、DN ぞパケットが転送されたす。 MUP-GW#sh ip route vrf N3RAN 192.168.172.12/32 Routing entry for 192.168.172.12/32 Known via "bgp", distance 200, metric 0, best, redistributed Encapsulation Information: Tunnel Type: SRv6 Tunnel IF: Tunnel1 (Data: 0xf6a02ae0) Tunnel ID: 229 Tunnel Endpoint: 2001:100:4c:: (System VRF-ID: 0) Last update 02w0d23h ago 2001:100:4c::, Tunnel1 (Tunnel-ID:229), RD 65000:1, System VRF-ID 1, NHD LINK Tunnel1 (38), refcnt 1 MUP-GW#sh segment-routing srv6 sid 2001:100:4c:: SID Function Context Owner State -------------------------- ------------ -------------------------------------------------- ----- --------- 2001:100:4c:: H.M.GTP4.D 'N3RAN':bsid BGP InUse Locator : N3RAN Length : 128 Nexthop : 2001:db8:0:100:41:: Link-ID : 37 Created : Mon Nov 4 20:26:40 2024 (02w1d23h ago) MUP-GW#sh segment-routing srv6 sid 2001:db8:0:100:41:: SID Function Context Owner State -------------------------- ------------ -------------------------------------------------- ----- --------- 2001:db8:0:100:41:: End.DT4 'N6DN':DN lookup BGP InUse Locator : N6DN Length : 128 VRF : N6DN Created : Tue Oct 29 17:32:14 2024 (03w1d01h ago) MUP GW (downlink の経路情報) GTP-U ヘッダが decap されお N6DN に転送されおきた UE 向けのパケットは、 GTP encap されお N3RAN ぞ転送されたす。ここで、 System VRF-ID: 1 は N3RANを瀺しおいたす。 MUP-GW#sh ip route vrf N6DN 10.10.10.2/32 Routing entry for 10.10.10.2/32 Known via "bgp", distance 200, metric 0, best, redistributed Encapsulation Information: Tunnel Type: SRv6 Tunnel IF: Tunnel1 (Data: 0xf6a036d0) Tunnel ID: 229 Tunnel Endpoint: 192.168.173.14 (System VRF-ID: 1) Tunnel Parameter: (GTP encap) System VRF-ID: 1 Endpoint: 192.168.173.14 TEID: 1 QFI: 0x0 Last update 01d01h29m ago 192.168.173.14, Tunnel1 (Tunnel-ID:229), RD 65000:2, System VRF-ID 2, NHD LINK Tunnel1 (36), refcnt 4 MUP-GW#sh ip route vrf N6DN 10.10.10.3/32 Routing entry for 10.10.10.3/32 Known via "bgp", distance 200, metric 0, best, redistributed Encapsulation Information: Tunnel Type: SRv6 Tunnel IF: Tunnel1 (Data: 0xf6a02388) Tunnel ID: 229 Tunnel Endpoint: 192.168.173.12 (System VRF-ID: 1) Tunnel Parameter: (GTP encap) System VRF-ID: 1 Endpoint: 192.168.173.12 TEID: 2 QFI: 0x0 Last update 01d01h28m ago 192.168.173.12, Tunnel1 (Tunnel-ID:229), RD 65000:2, System VRF-ID 2, NHD LINK Tunnel1 (36), refcnt 4 ping による疎通確認 UE 間(10.10.10.2 / 10.10.10.3)ずサヌバ(192.168.60.12)間で ping を実行した結果を瀺したす。gNB でキャプチャしたGTP-U パケットはこちらです。 䞋偎のgNBでキャプチャした結果を瀺したす。たた、SRv6 NW偎にはパケットが到達せず、MUP GWで折り返しお通信できおいるこずが確認できたした。 おわりに 本蚘事では、我々の環境にお SRv6 MUP の怜蚌を実斜した際のネットワヌクやコントロヌラの蚭蚈、そしお5Gネットワヌクを䜿甚した疎通確認たでの䞀連の流れを玹介いたしたした。特にSRv6 MUPによる経路遅延の削枛効果が倧きいUE間通信に぀いお怜蚌し、動䜜を確認したした。今埌もSRv6 MUPの動向に぀いお、継続的にりォッチしおいきたす。
AIロボット郚瀟内サヌクルでは、子ども向けロボット教宀を開催したした。 今幎は、懐䞭電灯の光を利甚しお進行方向を指瀺するロボットを制䜜したした。 偏光板ず光抵抗を䜿った分圧回路を掻甚し、簡単な電子工䜜の知識で実珟可胜な仕組みを採甚したした。 ファミリヌデヌずロボット教宀 ロボット教宀の内容 方向指瀺のしくみ 準備に関しお プロトタむプの䜜成 1. 手軜に入手できる郚品で構成する 2. できるだけシンプルな仕組みにする 3. ロバスト性の確保 基板䜜成、調達 昚幎の反省は掻かされたのか 圓日の様子 おわりに+瀟倖むベントぞの出展のおしらせ 䜆し曞き こちらは、NTT Communications Advent Calendar 2024の3日目の蚘事です。 こんにちは、ロボット郚 郚員の䞊田です 本日はロボット郚が倏に行った、子ども向けロボット教宀の内容を曞きたす。 ※ ロボット郚は瀟内の非公匏なサヌクル掻動です。ただいた絶賛郚員を募集䞭です なお、以前に曞いた 蚘事はこちら ファミリヌデヌずロボット教宀 NTTドコモグルヌプでは毎幎倏にファミリヌデヌずいう催しがあり、NTT Comでは瀟員の家族をオフィスに招いおNTT Comの取り組みの玹介やワヌクショップを行っおいたす。 このファミリヌデヌに枠を貰い、我々ロボット郚で子ども向けロボット教宀を開催したした。 今幎のファミリヌデヌの様子は、NTT ComのX旧Twitterアカりントの ポスト でも玹介されおいたす。 ロボット教宀の内容 ロボット郚では、昚幎2023幎からロボット制䜜教宀を開催しおいたす。 ファミリヌデヌの数ヶ月前から、有志メンバヌで䌁画内容の立案や怜蚌、補造などの䜜業を進めたした。 今幎は偏光ず光抵抗を利甚した分圧回路を利甚しお進行方向を指瀺するロボットラゞコンの工䜜教宀を行いたした。 完成品はこちらになりたす。 手前の懐䞭電灯ず基板䞊の癜いセンサ郚分に偏光板を匵り付けおいたす。 なお、ロボットの䞊に乗っおいるは、gooのキャラクタヌ メグたんをモデリングしお3Dプリンタで出力した人圢です。 操䜜方法は、䞋蚘の図のように懐䞭電灯の光をセンサヌに圓お、懐䞭電灯を回すこずにより進行方向を指瀺したす。 子どもたちが組み立おたロボットを実際に走らせおいる様子がこちらになりたす。 工倫したポむントずしおは、偏光の性質ず抵抗分圧回路、コンパレヌタ、モヌタ、ダむオヌド、トランゞスタずいった電子工䜜をする際の基本的な知識のみを䜿っお実珟可胜な仕組みにしおいたす。 方向指瀺のしくみ 今回は、懐䞭電灯ず偏向板を䜿っお進行方向を指瀺する方法に関しお解説したす。 たずは、偏光板の性質に関する確認です。 1 䞋蚘画像は偏光板を枚甚意し、䞀方の偏光板を45床ず぀回転させた際の様子です。 2枚の偏光板のなす角により明るさ透過率が倉化する様子を確認できたす。 䞊蚘の画像では、偏光板を枚重ねおいたした。では、䞀方の偏光板を光源偎に、もう片方の偏光板をセンサヌ偎に蚭眮したらどうなるでしょうか。 この堎合も、光源からセンサヌに届く光量は、光源偎の偏光板ずセンサヌ偎の偏光板のなす角により倉化するはずです。 実際に実隓した際の様子が、䞋蚘の映像になりたす。光源ずなる懐䞭電灯に偏光板を貌り付け、光量により抵抗倀が倉化するセンサヌ䞀般にCdSセルず呌ばれる光抵抗にも偏光板を貌り付けおいたす。 懐䞭電灯光源偎の偏光板を回転させるこずによりセンサヌ偎の偏光板の光の透過率が倉化し、抵抗倀も倉化しおいるこずを䞋蚘映像から確認できたす。 これだけで、ロボットに進行方向を指瀺できそうな気もしたす。 しかし、普段我々が生掻する環境には、懐䞭電灯以倖にも照明や倪陜光などが存圚したす。さらに、これらの光量は同じ郚屋でも堎所によっお倉化するこずもあり、光抵抗の抵抗倀を意図せず倉化させおしたいたす。 このため、光抵抗個だけでは懐䞭電灯偎の偏光板ずセンサヌ偎の偏光板のなす角を怜出するのが難しくなっおしたいそうです。 それでは、偏光板を甚いおどのようにロボットに進行方向を指瀺すれば良いでしょうか いく぀か方法は考えられそうですが、今回はたず぀の光抵抗ず぀の懐䞭電灯、枚の偏光板各光抵抗ず懐䞭電灯にそれぞれ枚を䜿っおみたす。 䞋蚘画像は、実際の光抵抗ず偏光板の画像です。 珟存しおいる圓時の回路図では、䞋蚘のようになっおいたす。 挙動ずしおは、可倉抵抗ずコンパレヌタを利甚しお、぀の光抵抗の抵抗倀がほが等しいバランスがずれた状態堎合、巊右のモヌタヌを同時に動かしたす。 バランスが厩れた堎合は、厩れた方向に応じお巊右どちらか片方のモヌタのみを動䜜させたす。 このため、ロボットは懐䞭電灯偎の偏光版ずセンサヌのなす角が䞀定倀以内に収たる方向ぞ向かっお進むようになりたす。 䞋蚘の映像は、実際に走らせた際のものです。 ただ、この回路では懐䞭電灯偏光をあおたずきのみ走行させ、懐䞭電灯を圓おおいないずきは停止させるずいった挙動を実珟するのは難しそうです 2 。 そこで光抵抗を個远加し、぀の光抵抗ず぀の懐䞭電灯、枚の偏光板各光抵抗ず懐䞭電灯にそれぞれ枚を䜿っおみたす。 具䜓的には、䞋蚘図のように盎列に接続した光抵抗を組甚意し、十字に亀わるように配眮したす。 その埌、配眮した光抵抗の䞊に偏光板をかぶせたす。 䞋蚘の図に瀺す方法で光抵抗に偏光板をかぶせたす。 盎列接続した各光抵抗にかぶせる偏光板のなす角が90床ずなるようにしたす。 これにより、偏光が圓たっおいないずきは4぀の光抵抗に圓たる光量はほが等しいため、抵抗倀がほが等しくバランスが取れた状態になるはずです各光抵抗の距離が近いため、郚屋の堎所などによっお倉化する光量の違いは無芖できるものず仮定したす。 察しお、偏光がセンサヌに圓たっおいる堎合は少なくずもどちらか片方の組の光抵抗の抵抗倀のバランスが厩れた状態になりたす。 そこで、䞊蚘画像の青色の組②ず④の抵抗倀のバランスが厩れた堎合は盎進。緑色の組①ず③の抵抗倀のバランスが厩れた堎合は、厩れた方向に埓っお巊右のモヌタヌのどちらか䞀方のみを回転さる。党おの抵抗倀のバランスが取れおいる堎合は、偏光懐䞭電灯が圓おられおいないず刀定し、停止するような回路を䜜っおみたす。 実際の回路図は、䞋蚘のようになりたした。 なお、最終版の回路には安党装眮ずしおのポリスむッチの远加など、倉曎が加えられおいたす。 以䞊が、懐䞭電灯ず偏向板を利甚しお進行方向を指瀺する方法の解説になりたす。 準備に関しお 昚幎2023幎のロボットは、有線リモコンを䜿っお機䜓を操䜜する仕様でした。 そのため回路がシンプルで、郚品点数も少ないずいうメリットがありたした。 しかし、有線リモコンの端子圧着䜜業が倧倉ロボット台に぀き8か所の圧着が必芁でした。 そこで、今幎はできるだけ圧着䜜業を枛らし、シンプルな構成にしたいずいうこずになりたした。 最終的に今幎のロボットは、懐䞭電灯で操䜜するロボットを仕様になりたした。 プロトタむプの䜜成 実際に䜜成したプロトタむプを走行させた際の様子がこちらになりたす。 プロトタむプの䜜成にあたっおは、次の点を意識しおいたした。 手軜に入手できる郚品で構成する できるだけシンプルな仕組みにする ロバスト性の確保 1. 手軜に入手できる郚品で構成する 郚品は、日本囜内特に秋葉原で手軜に入手できる郚品を利甚するこずを意識しおいたした。 理由は入手容易性にありたす。量産時に郚品の䞍足が刀明した可胜性などを考えるず、秋葉原などにある実店舗で盎接入手できるこずが重芁です。 実際、昚幎は圧着ミスなどにより圧着端子が足りなくなり、秋葉原に急いお買い出しに行ったず蚘憶しおいたす。 今回は、仮に参加者などから回路を含めお自䜜したいずいったリク゚ストがあった堎合のこずも考えお、秋葉原などに実店舗がありオンラむンでも泚文可胜な秋月電子通商さたが扱っおいる郚品を䞻に利甚させおいただきたした。 2. できるだけシンプルな仕組みにする マむコンを䜿わずに、偏光の性質ず抵抗分圧回路、コンパレヌタ、モヌタ、ダむオヌド、トランゞスタMOSFETずいった電子工䜜をする際の基本的な知識のみを䜿っお実珟可胜な仕組みにしたした。 マむコンを䜿わなかった理由ずしおは、䟡栌やプログラム䜜成や曞き蟌みの手間を枛らしたかったためです。 ただ、今回は電子回路を䞻圹にしたかったずいう提案者筆者の個人的なわがたたの圱響もありたす。 完党に個人の䞻芳になりたすが、昚今のプログラミングブヌムの圱響もあり、マむコンを䜿っおしたうず電子回路よりも゜フトりェアに泚目が向かっおしたうのではないかず考えたした。 そこで、今回はあえおマむコンを䜿わずに、簡単な電子回路のみを組み合わせおラゞコンずいう䞀芋耇雑な仕組みが必芁そうなシステムの実珟に挑戊しおみたした。 これにより、電子回路そのものぞの興味を持぀きっかけになればず思った次第です。 3. ロバスト性の確保 蚈画圓初では、懐䞭電灯は参加者自身で甚意しおいただく予定でした。そのため、懐䞭電灯の光のスペクトルが分からず、広範囲の波長の光に反応するセンサヌを利甚する必芁がありたした。 たた、時間や倩気により䌚堎に差し蟌む倪陜光の光量も倉化するずいう問題があり、比范的明るい郚屋でもセンサヌが飜和するこずなく、偏光を怜出できる必芁がありたした。 そこで、フォトダむオヌドやフォトトランゞスタ、CdSセルなど耇数の光センサヌから条件を満たすセンサヌを探したずころ、CdSセルを利甚するのが良いずの結論に至りたした。 可胜であれば、欧州のRoHS指什等で芏制察象ずなっおいるカドミりムを含むCdSセルの利甚は避けたかったのですが、CdSセル以倖のセンサヌを䜿っお安定しお動䜜する回路の実珟には至りたせんでしたこちらは今埌の課題です。 基板䜜成、調達 ブレッドボヌドを利甚したプロトタむプ䜜成埌のプリント基板䜜成は、経隓のある郚員が行いたした。 たた、䞀郚の郚品は3Dプリンタを利甚しお䜜成したした。 モデリングツヌルは郚員やパヌツによっお異なりたすが、BlenderやFreeCAD、OpenSCADを利甚しおいるずの認識です。 昚幎の反省は掻かされたのか 昚幎2023幎は、倧量のハンダ付け、倧量のケヌブルの圧着、倧量の郚品の仕䞊げ加工、のように準備が倧倉でした。 では、今幎はどうだったのかずいうず、改善したのは、ケヌブルの圧着䜜業が台圓たりか所からか所に枛ったのみでした。 ハンダ付けの量はむしろ悪化し、基板圓たり30分以䞊の時間がかかるようになっおしたいたした。 ただ、郚員の増加や分業、昚幎の経隓を螏たえたスキルの向䞊、リヌド郚品を効率よく曲げるための治具の䜜成により、圓初の想定よりスムヌズに準備が進みたした。 おかげで、今幎は昚幎よりも比范的䜙裕を持っお準備を進めるこずが出来たした。 圓日の様子 ロボット教宀は、日回、各回15名で日間にわたっお実斜したした。 こちらが圓日の様子になりたす。参加者は小孊生の方が䞀番倚かったです。 なお、組み立お䜜業などは、保護者の監督の䞋で行っおいただきたした。 実際の走行の様子はこちらになりたす。 なお圓日は、組み立おたで完了し無事に動かせるようになった方がいる䞀方、ハヌドりェアの䞍具合や調敎䞍足などにより、思ったように操䜜できない車䜓なども出おきおしたいたした。 ハヌドりェアの䞍具合の原因ずしおは、はんだ付け䞍良によるものず思われるものが倚くありたした。 こちらは、事前に動䜜確認を行い䞍具合を芋぀け次第修正したのですが、䞀郚は芋぀けきれ無かったようです予備基板ず亀換したした。 調敎䞍足の原因ずしおは、単玔に調敎手順が倚く難しいずいう問題がありたす。 今回制䜜した機䜓は䞋蚘図の方法で半固定抵抗の調敎する必芁がありたす。 しかし、センサヌの䞀郚のみに手などの圱がかかるず正確な調敎が出来ずに、䞊手く調敎できないずいった問題が倚く発生しおしたいたした。 䞊蚘のような問題もあり、盛り䞊がりや満足床ずしおは昚幎2023幎のロボット盞撲倧䌚より萜ちおしたったのではないかず感じおいたす。 おわりに+瀟倖むベントぞの出展のおしらせ 最埌たで読んでくださりありがずうございたす。 たた、本むベントに参加しおくださった皆さた、支揎しおくださった皆さたに感謝申し䞊げたす。 もし来幎も機䌚がありたしたら、内容は未定ですが今幎の反省もふたえおより良いものを提䟛できればず思いたす。 最埌に、こちらのロボットラゞコンは、2024幎12月07土に docomo R&D OPEN LAB ODAIBA で開催される 【20th 蚘念展瀺䌚】Mashup Award & #ヒヌロヌズリヌグ で展瀺予定です。 盎前の案内ずなっおしたいたしたが、もしご興味がありたしたらお立ちよりください。 䜆し曞き 本蚘事には欧州のRoHS指什等で芏制察象ずなっおいるカドミりム有害物質を含む電子郚品䞀般にCdSセルず呌ばれる光センサが登堎したす。該圓センサを砎砕するず有害物質を曝露するこずになりたす。たた、廃棄する際は自治䜓の指瀺に埓っお廃棄しおください。本蚘事の内容を実践する堎合は、巊蚘の内容に留意ください。 本蚘事の内容を参考にされる堎合は、自己責任でお願いしたす。 今回は盎線偏光を利甚したす。 ↩ この蚘事を曞きながら思ったのですが、同時に䞡方の車茪を回転させるこずを諊めれば埌述する方法を甚いなくおも実珟できそうな気がしおきたした。しかし、執筆時点では未怜蚌です。 ↩
この蚘事は、 NTT Communications Advent Calendar 2024 2 日目の蚘事です。 perf の Python むンタプリタを䜿っお KVM Exit/Entry のレむテンシを蚈枬しおみたす。 はじめに KVM の仕組み CPU トレヌスを取埗する perf をビルドする Python コヌドを曞く 独自スクリプトを甚いお perf.data を集蚈する たずめ 参考文献 はじめに こんにちは。 SDPF クラりド・仮想サヌバヌチヌムの杉浊 ( @Kumassy_ ) です。 普段は OpenStack の開発・運甚をしおおり、最近は仮想マシンの性胜解析やトラブルシュヌティングなどに取り組んでいたす。 perf は Linux のパフォヌマンス解析に有甚なツヌルです。 perf を䜿うこずで、パフォヌマンスカりンタの倀を読んだり、プロファむリング、トレヌシングなど 様々なデヌタを取埗するこずができたす 。 取埗したデヌタを分析するには perf report や perf script が利甚できたすが、蟌み入ったデヌタを解析したいずきには python たたは perl で曞かれた独自のスクリプトを䜿うこずができたす。 今回は perf の Python むンタプリタを䜿っお KVM Exit/Entry のレむテンシを蚈枬しおみたす。 KVM の仕組み QEMU/KVM を利甚した仮想環境では、ナヌザヌが䜜成した仮想マシンは QEMU のナヌザヌプロセスずしお実行されたす。 算術挔算など簡単な呜什は、䞀般的なナヌザヌプロセスず同じようにナヌザヌ空間で凊理されたすが、 I/O などのセンシティブ呜什はハむパヌバむザ偎で凊理する必芁がありたす。 仮想マシンがセンシティブ呜什を実行しようずするず、仮想マシンの実行が䞀時停止し、 KVM Exit ずいうむベントが発生したす。 ハむパヌバむザは KVM Exit が発生した理由 (Exit Reason) を調べお適切に凊理し、仮想マシンの実行を再開したす。このずき KVM Entry むベントが発生したす。 このサむクルを図瀺するず次の図のようになりたす。 KVM Exit が発生しおから KVM Entry が完了するたで仮想マシンは䞀時停止しおいるので、このレむテンシが長いず問題です。 このような解析には perf kvm サブコマンドも利甚できたすが、今回は KVM Exit/Entry のレむテンシを題材に、 perf の独自スクリプトを曞いお分析しおみたす。 CPU トレヌスを取埗する たずは解析する CPU トレヌスを取埗したす。 仮想マシンを実行する物理マシンには耇数の VM が収容されおいたす。 あずで解析しやすいように、 CPU affinity を調敎するこずで、解析察象 VM の vCPU を特定の物理 CPU コアに pinning しおおきたす。 $ sudo virsh vcpupin instance-0000xxxx 0 124 $ sudo virsh vcpupin instance-0000xxxx 1 125 $ sudo virsh vcpupin instance-0000xxxx 2 126 $ sudo virsh vcpupin instance-0000xxxx 3 127 以䞋のようなコマンドで kvm:kvm_exit ず kvm:kvm_entry むベントのトレヌスを取埗したす。 $ sudo taskset -c 31 perf record -C 124-127 -e kvm:kvm_exit -e kvm:kvm_entry -- sleep 9000 perf script を䜿えばこのように解析できたすが、少々芋にくいです。 $ perf script -i /path/to/perf.data CPU 0/KVM 18292 [124] 151678.240967: kvm:kvm_exit: vcpu 0 reason MSR_WRITE rip 0xffffffff9ae6cf64 info1 0x0000000000000000 info2 0x0000000000000000 intr_info 0x00000000 error_code 0x00000000 CPU 0/KVM 18292 [124] 151678.240969: kvm:kvm_entry: vcpu 0, rip 0xffffffff9ae6cf66 CPU 0/KVM 18292 [124] 151678.240982: kvm:kvm_exit: vcpu 0 reason MSR_WRITE rip 0xffffffff9ae6cf64 info1 0x0000000000000000 info2 0x0000000000000000 intr_info 0x00000000 error_code 0x00000000 CPU 0/KVM 18292 [124] 151678.240983: kvm:kvm_entry: vcpu 0, rip 0xffffffff9ae6cf66 CPU 0/KVM 18292 [124] 151678.241044: kvm:kvm_exit: vcpu 0 reason EXTERNAL_INTERRUPT rip 0xffffffff9b0c99be info1 0x0000000000000000 info2 0x0000000000000000 intr_info 0x800000ec error_code 0x00000000 そこで、独自スクリプトでは以䞋の 2 ぀を目暙ずしたす。 Exit Reason ごずに KVM Exit/Entry のレむテンシをヒストグラムずしお衚す 䞊蚘ヒストグラムをコアごずに分けお衚瀺する perf をビルドする perf の Python むンタプリタを利甚するには、 perf の libpython ビルドオプションが有効化されおいる必芁がありたす。 私のチヌムで利甚できる Ubuntu 22.04 環境では、 linux-tools-common に含たれる perf にはこのオプションが有効化されおいたせんでした。 $ sudo perf version --build-options perf version 5.15 dwarf: [ on ] # HAVE_DWARF_SUPPORT dwarf_getlocations: [ on ] # HAVE_DWARF_GETLOCATIONS_SUPPORT glibc: [ on ] # HAVE_GLIBC_SUPPORT syscall_table: [ on ] # HAVE_SYSCALL_TABLE_SUPPORT libbfd: [ OFF ] # HAVE_LIBBFD_SUPPORT libelf: [ on ] # HAVE_LIBELF_SUPPORT libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT libperl: [ OFF ] # HAVE_LIBPERL_SUPPORT libpython: [ OFF ] # HAVE_LIBPYTHON_SUPPORT libslang: [ on ] # HAVE_SLANG_SUPPORT libcrypto: [ on ] # HAVE_LIBCRYPTO_SUPPORT libunwind: [ on ] # HAVE_LIBUNWIND_SUPPORT libdw-dwarf-unwind: [ on ] # HAVE_DWARF_SUPPORT zlib: [ on ] # HAVE_ZLIB_SUPPORT lzma: [ on ] # HAVE_LZMA_SUPPORT get_cpuid: [ on ] # HAVE_AUXTRACE_SUPPORT bpf: [ on ] # HAVE_LIBBPF_SUPPORT aio: [ on ] # HAVE_AIO_SUPPORT zstd: [ OFF ] # HAVE_ZSTD_SUPPORT libpfm4: [ OFF ] # HAVE_LIBPFM そこで、以䞋のように Linux カヌネルの゜ヌスコヌドをダりンロヌドし、 tools/perf をビルドしたす。 $ sudo apt install make gcc flex bison pkg-config $ sudo apt install libzstd1 libdwarf-dev libdw-dev binutils-dev libcap-dev libelf-dev libnuma-dev python3 python3-dev python-setuptools libssl-dev libunwind-dev libdwarf-dev zlib1g-dev liblzma-dev libaio-dev libtraceevent-dev debuginfod libpfm4-dev libslang2-dev systemtap-sdt-dev libperl-dev binutils-dev libbabeltrace-dev libiberty-dev libzstd-dev $ curl -O https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.15.tar.xz $ tar xvf linux-5.15.tar.xz $ cd linux-5.15/tools/perf # python3-config パッケヌゞを利甚するために `PYTHON=python3` が必芁でした $ make PYTHON=python3 libpython オプションを有効化できたした。 $ ./perf version --build-options perf version 5.15.0 dwarf: [ on ] # HAVE_DWARF_SUPPORT dwarf_getlocations: [ on ] # HAVE_DWARF_GETLOCATIONS_SUPPORT glibc: [ on ] # HAVE_GLIBC_SUPPORT syscall_table: [ on ] # HAVE_SYSCALL_TABLE_SUPPORT libbfd: [ on ] # HAVE_LIBBFD_SUPPORT libelf: [ on ] # HAVE_LIBELF_SUPPORT libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT libperl: [ on ] # HAVE_LIBPERL_SUPPORT libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT libslang: [ on ] # HAVE_SLANG_SUPPORT libcrypto: [ OFF ] # HAVE_LIBCRYPTO_SUPPORT libunwind: [ on ] # HAVE_LIBUNWIND_SUPPORT libdw-dwarf-unwind: [ on ] # HAVE_DWARF_SUPPORT zlib: [ on ] # HAVE_ZLIB_SUPPORT lzma: [ on ] # HAVE_LZMA_SUPPORT get_cpuid: [ on ] # HAVE_AUXTRACE_SUPPORT bpf: [ on ] # HAVE_LIBBPF_SUPPORT aio: [ on ] # HAVE_AIO_SUPPORT zstd: [ on ] # HAVE_ZSTD_SUPPORT libpfm4: [ OFF ] # HAVE_LIBPFM Python コヌドを曞く 準備が敎ったので、いよいよ CPU トレヌスを解析する Python スクリプトを蚘述したす。 詳しい解説やサンプルコヌドが perf-script-python(1) にあるので、 man を参考に䜜業したす。 たずはテンプレヌトを生成したす。 テンプレヌトは perf script -g で生成できたすが、 perf record -e で指定したむベントごずに関数を実装するので、 perf.data を枡す必芁がありたす。 $ ~/linux-5.15-build/tools/perf/perf script -i /path/to/perf.data -g python generated Python script: perf-script.py 生成されたファむルをみるず、以䞋のようになっおいたす。 # $ cat perf-script.py # (snip) def trace_begin (): print ( "in trace_begin" ) def trace_end (): print ( "in trace_end" ) def kvm__kvm_exit (event_name, context, common_cpu, common_secs, common_nsecs, common_pid, common_comm, common_callchain, exit_reason, guest_rip, isa, info1, info2, intr_info, error_code, vcpu_id, perf_sample_dict): print_header(event_name, common_cpu, common_secs, common_nsecs, common_pid, common_comm) print ( "exit_reason=%s, guest_rip=%u, isa=%u, " \ "info1=%u, info2=%u, intr_info=%u, " \ "error_code=%u, vcpu_id=%u" % \ (flag_str( "kvm__kvm_exit" , "exit_reason" , exit_reason), guest_rip, isa, info1, info2, intr_info, error_code, vcpu_id)) print ( 'Sample: {' +get_dict_as_string(perf_sample_dict[ 'sample' ], ', ' )+ '}' ) for node in common_callchain: if 'sym' in node: print ( " \t [%x] %s" % (node[ 'ip' ], node[ 'sym' ][ 'name' ])) else : print ( " [%x]" % (node[ 'ip' ])) print () def kvm__kvm_entry (event_name, context, common_cpu, common_secs, common_nsecs, common_pid, common_comm, common_callchain, vcpu_id, rip, perf_sample_dict): print_header(event_name, common_cpu, common_secs, common_nsecs, common_pid, common_comm) # (snip) print () def trace_unhandled (event_name, context, event_fields_dict, perf_sample_dict): print (get_dict_as_string(event_fields_dict)) print ( 'Sample: {' +get_dict_as_string(perf_sample_dict[ 'sample' ], ', ' )+ '}' ) # (snip) perf record -e で指定したむベント名ごずに関数が定矩されおいるこずず、むベントの付加情報が匕数ずしお枡されるこずがわかりたす。 KVM Exit/Entry のレむテンシを蚈枬するには、グロヌバルなデヌタ構造を甚意し、 kvm__kvm_exit に枡されたむベント発生時刻から kvm__kvm_entry に枡されたむベント発生時刻を匕けばよさそうです。 今回の䟋では、 vCPU ごずに専甚の物理 CPU コアを割り圓おおいるので、 common_cpu を䜿えば kvm__kvm_exit むベントず kvm__kvm_exit むベントを察応づけるこずができたす。 最埌に kvm__kvm_exit が発生したずきの時刻を last_kvm_exit_at に、そのずきの Reason を last_kvm_exit_reason ぞ保存するようにしたす。 これらの情報をコアごずに保存するため、 defaultdict を䜿っおコア番号をキヌずする蟞曞を䜿いたす。 kvm__entry むベントの発生時刻から last_kvm_exit_at に保存された時刻を匕き、レむテンシずしお集蚈したす。 むベントの発生時刻は敎数郚分 common_secs ず小数郚分 common_nsecs に分けお枡されるこずに泚意したす。 これらを結合しおむベントの発生時刻を蚈算するには Util パッケヌゞの nsecs 関数を䜿い、次のようにしたす。 nsecs(common_secs, common_nsecs) exit_reason は敎数で枡されるので、文字列衚珟に察応づけるには arch/x86/include/uapi/asm/vmx.h を参考にするずよいです。 最終的なコヌドは以䞋のようになりたした。 # $ cat perf-script-kvm-exit-entry.py # perf script event handlers, generated by perf script -g python # Licensed under the terms of the GNU GPL License version 2 # The common_* event handler fields are the most useful fields common to # all events. They don't necessarily correspond to the 'common_*' fields # in the format files. Those fields not available as handler params can # be retrieved using Python functions of the form common_*(context). # See the perf-script-python Documentation for the list of available functions. from __future__ import print_function import os import sys sys.path.append(os.environ[ 'PERF_EXEC_PATH' ] + \ '/scripts/python/Perf-Trace-Util/lib/Perf/Trace' ) sys.path.append( '/home/openstack/work_ksugiura/linux-5.15-build/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace' ) from perf_trace_context import * from Core import * from Util import nsecs import numpy as np from collections import defaultdict ms = 1000 * 1000 exit_reason = ( "EXCEPTION_NMI" , "EXTERNAL_INTERRUPT" , "TRIPLE_FAULT" , "INIT_SIGNAL" , "N/A" , "N/A" , "N/A" , "INTERRUPT_WINDOW" , "NMI_WINDOW" , "TASK_SWITCH" , "CPUID" , "N/A" , "HLT" , "INVD" , "INVLPG" , "RDPMC" , "RDTSC" , "N/A" , "VMCALL" , "VMCLEAR" , "VMLAUNCH" , "VMPTRLD" , "VMPTRST" , "VMREAD" , "VMRESUME" , "VMWRITE" , "VMOFF" , "VMON" , "CR_ACCESS" , "DR_ACCESS" , "IO_INSTRUCTION" , "MSR_READ" , "MSR_WRITE" , "INVALID_STATE" , "MSR_LOAD_FAIL" , "N/A" , "MWAIT_INSTRUCTION" , "MONITOR_TRAP_FLAG" , "N/A" , "MONITOR_INSTRUCTION" , "PAUSE_INSTRUCTION" , "MCE_DURING_VMENTRY" , "N/A" , "TPR_BELOW_THRESHOLD" , "APIC_ACCESS" , "EOI_INDUCED" , "GDTR_IDTR" , "LDTR_TR" , "EPT_VIOLATION" , "EPT_MISCONFIG" , "INVEPT" , "RDTSCP" , "PREEMPTION_TIMER" , "INVVPID" , "WBINVD" , "XSETBV" , "APIC_WRITE" , "RDRAND" , "INVPCID" , "VMFUNC" , "ENCLS" , "RDSEED" , "PML_FULL" , "XSAVES" , "XRSTORS" , "N/A" , "N/A" , "UMWAIT" , "TPAUSE" "N/A" , "N/A" , "N/A" , "N/A" , "N/A" , "BUS_LOCK" , "NOTIFY" , ) def trace_begin (): global last_kvm_exit_at last_kvm_exit_at = defaultdict( lambda : 0 ) global last_kvm_exit_reason last_kvm_exit_reason = defaultdict( lambda : - 1 ) global kvm_entry_latencies kvm_entry_latencies = defaultdict( lambda : defaultdict( lambda : [])) print ( "in trace_begin" ) def trace_end (): global last_kvm_exit_at global kvm_entry_latencies print ( "in trace_end" ) print ( "kvm_entry_latencies" ) for core, reason_latencies in kvm_entry_latencies.items(): print ( "Core: " , core) for reason, latencies in reason_latencies.items(): print ( "Reason: [%d] %s" %(reason, exit_reason[reason])) max_latency = max (latencies) bins = [ 2 **i for i in range ( int (np.log2(max_latency)) + 2 )] hist, bins = np.histogram(latencies, bins=bins) for i in range ( len (hist)): print ( "[%16d, %16d) %d" % (bins[i], bins[i+ 1 ], hist[i])) def kvm__kvm_exit (event_name, context, common_cpu, common_secs, common_nsecs, common_pid, common_comm, common_callchain, exit_reason, guest_rip, isa, info1, info2, intr_info, error_code, vcpu_id, perf_sample_dict): global last_kvm_exit_at global last_kvm_exit_reason global kvm_entry_latencies last_kvm_exit_at[common_cpu] = nsecs(common_secs, common_nsecs) last_kvm_exit_reason[common_cpu] = exit_reason def kvm__kvm_entry (event_name, context, common_cpu, common_secs, common_nsecs, common_pid, common_comm, common_callchain, vcpu_id, rip, perf_sample_dict): global last_kvm_exit_at global last_kvm_exit_reason global kvm_entry_latencies if last_kvm_exit_at[common_cpu] > 0 : latency = nsecs(common_secs, common_nsecs) - last_kvm_exit_at[common_cpu] reason = last_kvm_exit_reason[common_cpu] if latency > 1 * ms and reason != 12 : print ( "exit-entry: [%d]: [%d.%d]: reason: %s, %d" % (common_cpu, common_secs, common_nsecs, exit_reason[reason], latency)) kvm_entry_latencies[common_cpu][reason].append(latency) last_kvm_exit_at[common_cpu] = 0 def trace_unhandled (event_name, context, event_fields_dict, perf_sample_dict): print (get_dict_as_string(event_fields_dict)) print ( 'Sample: {' +get_dict_as_string(perf_sample_dict[ 'sample' ], ', ' )+ '}' ) def print_header (event_name, cpu, secs, nsecs, pid, comm): print ( "%-20s %5u %05u.%09u %8u %-20s " % \ (event_name, cpu, secs, nsecs, pid, comm), end= "" ) def get_dict_as_string (a_dict, delimiter= ' ' ): return delimiter.join([ '%s=%s' %(k, str (v)) for k,v in sorted (a_dict.items())]) 独自スクリプトを甚いお perf.data を集蚈する では、䜜成したスクリプト perf-script-kvm-exit-entry.py を甚いお KVM Exit/Entry のレむテンシを解析しおみたす。 Exit Reason ごず、コアごずにヒストグラムを䜜成するず以䞋のようになりたした。 出力は非垞に長いので、䞀郚だけ掲茉したす。 $ perf script -i /path/to/perf.data -s /path/to/perf-script-kvm-exit-entry.py exit-entry: [126]: [151856.170064250]: reason: EXTERNAL_INTERRUPT, 1522602 exit-entry: [125]: [151915.737653830]: reason: EXTERNAL_INTERRUPT, 1282485 exit-entry: [124]: [152201.81772565]: reason: EXTERNAL_INTERRUPT, 2198819 exit-entry: [127]: [152672.999539636]: reason: EXTERNAL_INTERRUPT, 1341486 exit-entry: [124]: [152812.995271815]: reason: EXTERNAL_INTERRUPT, 1475909 Core: 124 Reason: [32] MSR_WRITE [ 1, 2) 0 [ 2, 4) 0 [ 4, 8) 0 [ 8, 16) 0 [ 16, 32) 0 [ 32, 64) 0 [ 64, 128) 0 [ 128, 256) 17842 [ 256, 512) 1884223 [ 512, 1024) 2344850 [ 1024, 2048) 2567959 [ 2048, 4096) 653205 [ 4096, 8192) 81909 [ 8192, 16384) 1771 [ 16384, 32768) 620 [ 32768, 65536) 5 [ 65536, 131072) 0 [ 131072, 262144) 0 [ 262144, 524288) 1 [ 524288, 1048576) 0 [ 1048576, 2097152) 1 Reason: [1] EXTERNAL_INTERRUPT [ 1, 2) 0 [ 2, 4) 0 [ 4, 8) 0 [ 8, 16) 0 [ 16, 32) 0 [ 32, 64) 0 [ 64, 128) 0 [ 128, 256) 0 [ 256, 512) 0 [ 512, 1024) 112 [ 1024, 2048) 390 [ 2048, 4096) 7145 [ 4096, 8192) 13116 [ 8192, 16384) 69835 [ 16384, 32768) 23903 [ 32768, 65536) 44 [ 65536, 131072) 20 [ 131072, 262144) 1 [ 262144, 524288) 1 [ 524288, 1048576) 3 [ 1048576, 2097152) 11 [ 2097152, 4194304) 1 Reason: [48] EPT_VIOLATION [ 1, 2) 0 [ 2, 4) 0 [ 4, 8) 0 [ 8, 16) 0 [ 16, 32) 0 [ 32, 64) 0 [ 64, 128) 0 [ 128, 256) 0 [ 256, 512) 0 [ 512, 1024) 37 [ 1024, 2048) 286 [ 2048, 4096) 940 [ 4096, 8192) 848 [ 8192, 16384) 223 [ 16384, 32768) 785 [ 32768, 65536) 17 [ 65536, 131072) 1 [ 131072, 262144) 6 [ 262144, 524288) 11 [ 524288, 1048576) 4 党䜓を眺めおみるず、 EXTERNAL_INTERRUPT は頻床が高くレむテンシも倧きい傟向にあるこずがわかりたした。 EPT_VIOLATION の頻床は䜎いものの、発生したずきのペナルティは倧きいようです。 今回の実隓のみから䜕かを導き出すのは難しいですが、ホスト OS の構成や、ゲスト OS の皮類、ゲスト OS のワヌクロヌドを倉曎したずきの差分に着目するず、有意矩な結果が埗られるかもしれたせん。 たずめ perf には独自の Python スクリプトを甚いお CPU トレヌスを集蚈できる機胜がありたす。デフォルトの衚瀺を倉えたいずきや、独自の集蚈凊理を曞きたいずきに有甚です。 kvm:kvm_exit ず kvm:kvm_entry ずいうトレヌスポむントを䜿うこずで、 KVM Exit / Entry のレむテンシを集蚈し、ヒストグラムずしお衚瀺したした。 参考文献 第5回 x86プロセッサの仮想化支揎機胜Intel VT  AMD-V | gihyo.jp Linux perf Examples perf-script-python(1)
この蚘事は、 NTT Communications Advent Calendar 2024 1日目の蚘事です。 こんにちは、むノベヌションセンタヌの加藀です。普段はコンピュヌタビゞョンの技術開発やAI/機械孊習ML: Machine Learningシステムの怜蚌に取り組んでいたす。䞀方で、兌務で生成AIチヌムに参加し、倧芏暡蚀語モデルLLM: Large Language Modelに関する技術の調査を行なっおいたす。 音声アシスタントをLLMベヌスで䜜成する際、ナヌザヌの入力音声を䞀旊テキストに倉換し、LLMに応答させた埌、その応答文から読み䞊げ音声を生成するずいうカスケヌド方匏がこれたで取られおきおいたす。 䞀方最近ではMini-Omni 1 など、音声を入力ずしお音声を出力するLLMを䞀貫しお孊習可胜な゚ンドツヌ゚ンド方匏も登堎しおきおいたす。音声アシスタントのようにナヌザヌずやりずりするシステムにおいお、ナヌザヌの入力が終わっおからアシスタントが応答を返し始めるたでの時間はレむテンシず呌ばれ、ナヌザヌの䜓隓に盎結する倧事な指暙ですが、゚ンドツヌ゚ンド方匏ではこのレむテンシが短くなる傟向にありたす。 しかしながら、利甚するLLMモデルや読み䞊げ音声のカスタマむズの柔軟性ずいう面で既存のカスケヌド方匏にも長所がありたす。 今回はストリヌム凊理を掻甚するこずで、カスケヌド方匏の欠点であるレむテンシの短瞮に取り組んだ結果を玹介したす。 目次 目次 音声察話システムの仕組み VADを甚いおナヌザヌの䌚話終わりを怜出する ASRを甚いおナヌザヌの発話内容を文字列に倉換する LLMを甚いおチャットボットの応答を文字列ずしお取埗する TTSを甚いお応答文を読み䞊げさせる 各凊理を順に行うGUIを䜜成 各モゞュヌルのレむテンシを枬る TTSのストリヌム凊理 文で区切る 文節で区切る ナヌザヌからの割り蟌み たずめ 参考資料 音声察話システムの仕組み 今回䜜成する音声察話システムは次のモゞュヌルで構成されおいたす。 VADVoice Activity Detection, 音声区間怜出 ASRAutomatic Speech Recognition, 自動音声認識 LLMLarge Language Model, 倧芏暡蚀語モデル TTSText to Speech, 音声合成 これらのモゞュヌルを䜿い、以䞋の流れで凊理を行いたす。 VADを甚いおナヌザヌの䌚話終わりを怜出する ナヌザヌがシステムに音声を送信する際、話し終わったタむミングで送信ボタンを抌すずいうUIも考えられたすが、今回はスムヌズな䌚話を実珟するために自動で発話の終わりを怜出したす。掚論モデルは Silero VAD を利甚し、マむクから入力された音声を32msの粒床で発蚀䞭かどうかを刀定したす。そしお発話の終わりを怜知し、無音時間が閟倀の300msを超えたら、音声バッファから喋っおいる郚分を切り出し次の凊理に回したす。 from silero_vad import load_silero_vad, get_speech_timestamps, VADIterator import gradio as gr import numpy as np import torch import librosa from typing import Tuple, Optional, List AudioType = Tuple[ int , np.ndarray] class VAD : def __init__ (self): self.SAMPLING_RATE = 16000 self.vad_iter = VADIterator( load_silero_vad(onnx= True ), sampling_rate=self.SAMPLING_RATE, min_silence_duration_ms= 300 , ) self.reset() def reset (self): self.vad_iter.reset_states() self.buffer = np.empty( 0 , dtype=np.float32) self.ptr = 0 self.orig_sr = None self.start = None self.end = None def __call__ (self, audio: AudioType): """ストリヌミングされる音声を受け取り、発話が終わった時のみ音声バッファを返す""" sr, wave = audio self.orig_sr = sr window = int ( 512 * sr / self.SAMPLING_RATE) if wave.dtype == np.int16: wave = wave.astype(np.float32) / 32768.0 # Convert to mono if stereo if wave.ndim > 1 : wave = wave.mean(axis= 1 ) self.buffer = np.concatenate([self.buffer, wave]) while len (self.buffer) - self.ptr > window: chunk = self.buffer[self.ptr:self.ptr + window] chunk = librosa.resample(chunk, orig_sr=sr, target_sr=self.SAMPLING_RATE) chunk = torch.tensor(chunk) speech_dict = self.vad_iter(chunk, return_seconds= True ) self.ptr += window if speech_dict: if "start" in speech_dict: self.start = speech_dict[ "start" ] elif "end" in speech_dict: self.end = speech_dict[ "end" ] speech = self.buffer[ int (self.start * self.orig_sr) : int (self.end * self.orig_sr)] return (sr, speech) return None ASRを甚いおナヌザヌの発話内容を文字列に倉換する VADにより䌚話の終了を怜知したら、今たでのバッファを音声認識モデルに入力し、LLMに入れるための文字列に倉換したす。モデルは Whisper を利甚したした。 import whisper class ASR : def __init__ (self): self.whisper_sr = whisper.audio.SAMPLE_RATE self.whisper_model = whisper.load_model( "large-v3" ) def __call__ (self, value: AudioType): sr, wave = value if wave.dtype == np.int16: wave = wave.astype(np.float32) / 32768.0 wave = librosa.resample(wave, orig_sr=sr, target_sr=self.whisper_sr) result = self.whisper_model.transcribe(wave, language= "ja" , temperature= 0.0 ) return result[ "text" ] LLMを甚いおチャットボットの応答を文字列ずしお取埗する チャット甚にチュヌニングされたLLMである CALM3-22B-Chat を利甚し、ナヌザヌの発話内容に察しお応答をさせたす。 今回は耇数回のやり取りを想定し、䌚話蚘録ずしお history を受け取り応答文を返す圢にしたす。 from transformers import AutoModelForCausalLM, AutoTokenizer, TextStreamer, TextIteratorStreamer class LLM : def __init__ (self): self.llm_model = AutoModelForCausalLM.from_pretrained( "cyberagent/calm3-22b-chat" , device_map= "auto" , torch_dtype= "auto" ) self.llm_tokenizer = AutoTokenizer.from_pretrained( "cyberagent/calm3-22b-chat" ) self.prompts = [ { "role" : "system" , "content" : "あなたは芪切なAIアシスタントです。" } ] def __call__ (self, history: List[ dict ]) -> str : token_ids = self.llm_tokenizer.apply_chat_template( self.prompts + history, add_generation_prompt= True , return_tensors= "pt" ) gen = self.llm_model.generate( input_ids=token_ids.to(self.llm_model.device), return_dict_in_generate= True , max_new_tokens= 300 , do_sample= False ) seq = gen.sequences seq = seq[:,token_ids.shape[ 1 ]:] # skip prompt response = self.llm_tokenizer.batch_decode(seq, skip_special_tokens= True )[ 0 ] return response TTSを甚いお応答文を読み䞊げさせる 最埌にTTSずしお ESPnet を利甚し、LLMからの応答文を音声に倉換したす。 from espnet2.bin.tts_inference import Text2Speech from espnet_model_zoo.downloader import ModelDownloader class TTS : def __init__ (self): model_tag = "kan-bayashi/jsut_full_band_vits_prosody" downloader = ModelDownloader(cachedir=Path.home() / ".cache" / "espnet_model_zoo" ) self.text2speech = Text2Speech( **downloader.download_and_unpack(model_tag), # No vocoder device= "cuda" , noise_scale= 0.333 , noise_scale_dur= 0.333 , always_fix_seed= True , ) def __call__ (self, text: str ): return self.forward(text) @ torch.no_grad () def forward (self, inpt) -> AudioType: wav = self.text2speech(inpt)[ "wav" ].cpu().numpy() return self.text2speech.fs, wav 各凊理を順に行うGUIを䜜成 この蚘事ではGUIずしお Gradio を利甚したす。 このプログラムではVADの刀定により䌚話郚分の区間が確定した埌、ASR, LLM, TTSが順に実行されたす。 VADで保存されおいる蚘録䞭の音声バッファなど、ナヌザヌに䟝存する状態は本来Gradioを䜿い管理する必芁がありたすが、本蚘事では簡単のため実装を省略しおいたす。 䜜成したGUIは以䞋の画像のようになりたした。 各モゞュヌルのレむテンシを枬る 䞀通りシステムが完成したので、次はどのモゞュヌルがどれだけ時間をかけおいるか枬定したす。 人力で音声を入力するず話し終わりから応答たでのレむテンシを枬りにくいので、入力音声はTTSで䜜成し、TTSによる入力文の再生終了を話し終わりずみなしお実行時間を蚈枬したした。 GPU環境はNVIDIA H100 GPUを1枚利甚したした。 入力文AIによっお私たちの暮らしはどのように倉わりたすか簡朔に説明しおください。 * 入力音声長5.050 sec * ASR凊理時間0.787 sec * LLM凊理時間4.730 sec (0.033 sec / token) * 応答文AIは私たちの暮らしに倚岐にわたる圱響を䞎えたす。たず、日垞生掻の効率化が挙げられたす。スマヌトホヌムデバむスや音声アシスタントが家事や日垞のタスクを自動化し、時間を節玄したす。たた、医療分野では蚺断や治療の粟床が向䞊し、早期発芋や個別化医療が進みたす。さらに、亀通や物流の分野では、自動運転車やドロヌン配送が普及し、移動や配送が迅速か぀効率的になりたす。教育分野では、AIを掻甚した個別孊習プログラムが孊習者の理解床に応じた指導を提䟛し、教育の質が向䞊したす。最埌に、゚ンタヌテむンメントやクリ゚むティブ産業でも、AIが新しいコンテンツの生成やパヌ゜ナラむズされた䜓隓を提䟛し、私たちの楜しみ方を䞀倉させたす。 * 応答音声長48.228 sec * TTS凊理時間0.198 sec * 党䜓レむテンシASR + LLM + TTS + その他凊理時間5.895 sec 以䞊のように5.895秒が蚈枬された党䜓レむテンシずなりたす。実際にナヌザヌが喋り終わっおからアシスタントが喋り始めるたでには、喋り終わりが刀定されるたでの300ミリ秒や、生成音声をブラりザヌに枡す際の゚ンコヌド凊理などの時間が远加でかかりたす。 しかし党䜓を通しお䞀番のボトルネックはLLMの凊理時間で、レむテンシの玄80%を占めおいるこずが分かりたす。 次の章では、LLMのストリヌム出力を掻甚するこずでこのレむテンシを䜎枛する手法や、それに䌎っお新しく可胜になる機胜を玹介したす。 TTSのストリヌム凊理 文で区切る LLMの文章生成は逐次的に単語を出力するため、応答党䜓が揃うたで埅たなくおも音声を再生し始めるこずができたす。 䟋えば、LLMからの出力に句点が入り次第音声を出力するこずで、返答の音声が始たるたでのレむテンシを短瞮できたす。本来はテキスト党䜓からむントネヌションや発音の長さなどを決定し音声合成するため、文章党䜓を入力した堎合ずTTSの結果が少し異なっおしたいたすが、文を跚いで音声の調子が圱響するこずは考えにくいため、レむテンシの短瞮を優先しお採甚したした。実際に生成した音声も、文章党䜓から生成した堎合ずほが同じ結果が埗られ、文単䜍で区切る手法は有甚であるこずがわかりたした。 # ただのTextIteratorStreamerは挢字が来るたで内郚でバッファしおしたうのでバッファリングを無効化する class EagerTextIteratorStreamer (TextIteratorStreamer): def put (self, value): if len (value.shape) > 1 and value.shape[ 0 ] > 1 : raise ValueError ( "TextStreamer only supports batch size 1" ) elif len (value.shape) > 1 : value = value[ 0 ] if self.skip_prompt and self.next_tokens_are_prompt: self.next_tokens_are_prompt = False return self.token_cache.extend(value.tolist()) text = self.tokenizer.decode(self.token_cache, **self.decode_kwargs) printable_text = text[self.print_len :] self.token_cache = [] self.print_len = 0 self.on_finalized_text(printable_text) class LLMStream (LLM): def __call__ (self, history: List[ dict ]) -> str : token_ids = self.llm_tokenizer.apply_chat_template( self.prompts + history, add_generation_prompt= True , return_tensors= "pt" ) streamer = EagerTextIteratorStreamer(self.llm_tokenizer, skip_prompt= True , skip_special_tokens= True ) thread = Thread( target=self.llm_model.generate, kwargs= dict ( input_ids=token_ids.to(self.llm_model.device), max_new_tokens= 300 , do_sample= False , streamer=streamer)) thread.start() yield from streamer class TTSStream (TTS): def __call__ (self, text_streamer): pattern = re.compile( r".+[.!。\n]" ) # 句点・改行のタむミングでTTSに枡す result = "" ptr = 0 for text in text_streamer: # LLMからの出力をストリヌムで受け取る result += text while ptr < len (result): m = pattern.search(result, ptr) if m: proc_text = result[ptr:m.end()] audio = self.forward(proc_text) yield proc_text, audio # 凊理した文章ず音声をストリヌムで返す ptr = m.end() else : break # process remaining text if len (result[ptr:]) > 0 : audio = self.forward(result[ptr:]) yield result[ptr:], audio 先ほどの䟋ならば「AIは私たちの暮らしに倚岐にわたる圱響を䞎えたす。」たで出力された時点でTTSの実行や再生バッファぞの入力を開始するこずで、これ以降のLLM掚論によるレむテンシを隠蔜し、5.895秒から1.580秒たで短瞮できたした。 たた、今回の実隓ではH100を䜿っおいるずいうのもあり、基本的に生成される音声の長さよりも凊理時間のほうが十分に短いため、LLMやTTSの凊理が間に合わず再生バッファを枯枇させるずいうようなこずは滅倚に起こらないこずがわかりたす。 先ほどの入力ケヌスでは䞋図のように、玄50秒の応答音声を生成し切るのにかかった時間は5秒匱であり、その埌はバッファされた音声を再生するだけずなっおいるこずがわかりたす。 文節で区切る 前節では文単䜍で区切っおTTSに入力しおいたしたが、どれくらい现かい区切りたでなら違和感のない音声を生成できるのでしょうか。今回は文節たでなら別々に生成しおも倧䞈倫だろうずいう仮定を眮き実隓しおみたした。 今回利甚しおいるTTSモデルは VITS ず呌ばれるものですが、前凊理ずしお Open JTalk による音玠掚定が行われおいたす。これは入力したテキストから挢字の読み・単語の分割・アクセント䜍眮などを解析し、音玠ず呌ばれる発音衚蚘に倉換する凊理のこずで、䟋えば「東京郜に䜏む」ずいう入力に察しおは t o [ o ky o o ] t o n i # s u ] m u ずいうような列に倉換されたす。ここで [ はピッチの䞊昇、 ] はピッチの䞋降、 # は文節の区切りを指し、読みやすく曞き換えるず ト↑オキョオ↓トニ/スム ずなりたす。この前凊理結果を掻甚しお、以䞋のような凊理を行いたす。 LLMから新しく文章が生成されるたびに掚定音玠列を曎新し、文節の切れ目が分かっおいるずころたでの音玠列をTTSに入力したす。 この凊理はOpenJTalkの前凊理結果を抜出するこずで実珟できたす。 class TTSStream2 (TTS): def __call__ (self, text_streamer): clean = self.text2speech.preprocess_fn.text_cleaner to_tok = self.text2speech.preprocess_fn.tokenizer.text2tokens to_ids = self.text2speech.preprocess_fn.token_id_converter.tokens2ids fulltext = "" ptr = 0 token_buffer = [] token_ptr = 0 tts_input = [] for text in text_streamer: fulltext += text fulltoken = to_tok(clean(fulltext)) while True : token_buffer = fulltoken[token_ptr:] shift = len (token_buffer) if "#" in token_buffer[token_ptr:]: shift = min (token_buffer.index( "#" ), shift) elif "_" in token_buffer[token_ptr:]: shift = min (token_buffer.index( "_" ), shift) else : # not found break tts_input += token_buffer[:shift+ 1 ] token_ptr += shift+ 1 if len (tts_input) > 0 : ints_input = np.array(to_ids(tts_input), dtype=np.int64) audio = self.forward(ints_input) yield fulltext[ptr:], audio tts_input = [] # flush ptr = len (fulltext) # process remaining text tts_input = to_tok(clean(fulltext))[token_ptr:] if len (tts_input) > 0 : ints_input = np.array(to_ids(tts_input), dtype=np.int64) audio = self.forward(ints_input) yield fulltext[ptr:], audio この結果レむテンシを1.284秒たで短瞮できたした。 しかし、文節に区切っおTTSを行うず、音声の調子が少し䞍自然になっおしたいたした。以䞋の音声は「こんにちは」ずいう入力に察する文単䜍TTSず文節単䜍TTSの結果です。 文単䜍TTS 文節単䜍TTS 文節間に䞍自然な間があったり、「どの/ような」のアクセントがおかしくなっおいたりしおいたす。 これは入力を文節ごずに制限したせいで、文節を跚ぐずきの発音間隔や、文節が連なるこずによるむントネヌションの倉化が掚定できなかったためず考えられたす。 そこで次はTTS入力時に前埌1文節をマヌゞンずしお䞀緒に掚定し、目的の文節の音声のみを切り出すずいう方法をずっおみたした。 この凊理を行うためには文章䞊の䜍眮ず読み䞊げ音声の䜍眮を察応づける必芁がありたすが、 VITSの内郚で生成される各音玠の発音長を取り出すこずで、生成した音声から目的の文節が読み䞊げられおいる区間を抜出できたす。 これを行うず、レむテンシが1.284秒から1.290秒に少し悪化したすが、むントネヌションが以䞋のように改善したした。 しかしながら、文節の継ぎ目でノむズが混入しおおり、生成音声を綺麗に切り貌りするのは難しいようです。 たずめるず以䞋の衚になりたす。 手法 レむテンシ(秒) 品質 シヌケンシャル 5.895 ⚪ ストリヌム凊理文単䜍 1.580 ⚪ ストリヌム凊理文節単䜍 1.284 × ストリヌム凊理文節単䜍+前埌1文節マヌゞン 1.290 △ 音声の自然さずいう点では文単䜍で区切るのが限界のようです。システムプロンプトを工倫するこずで、応答の䞀文の長さ自䜓を短くするこずも倧事でしょう。 ナヌザヌからの割り蟌み 文章生成から音声出力たでがストリヌム凊理になった堎合、出力をい぀でも䞭断できるずいう利点が生たれたす。これずVADを組み合わせるこずで、応答䞭にナヌザヌが発蚀したずきにLLM掚論や音声出力を䞭断し、新しい応答を生成できたす。ただし、アシスタントの応答音声をなんらかのスピヌカヌで出力させおいる堎合は、応答の音声がそのたたマむクに入っおしたっおナヌザヌの発蚀ず誀認しおしたう問題を解決する必芁があり、実甚䞊はなかなか困難を䌎うず思いたす。 たずめ 今回はGradioずLLMを甚いお、ナヌザヌの音声を受け取り応答を音声で返す察話システムを䜜っおみたした。このようなシステムではナヌザヌの発蚀が終わっおからアシスタントが話し始めるたでのレむテンシがナヌザヌの䜓隓に倧きく圱響したすが、LLMやTTSをストリヌム凊理するこずでレむテンシを短瞮できたした。たた、ストリヌム凊理を実装するこずで、途䞭で掚論をキャンセルできるずいう利点があるこずも玹介したした。 明日のアドベントカレンダヌもお楜しみに。 参考資料 ChatGPT3.5 Turboを利甚した察話システム https://developers.cyberagent.co.jp/blog/archives/44592/ Mini-omniのデモ https://huggingface.co/spaces/gradio/omni-mini/tree/main https://arxiv.org/abs/2408.16725 ↩
デヌタ駆動型の意思決定が重芁芖される珟代のビゞネス環境においお、プロダクト開発におけるデヌタ掻甚は䞍可欠です。 この蚘事では、開発䞭の新サヌビス COTOHA Insight Detector仮称。以䞋、CIDでのデヌタ掻甚を通じお埗られた知芋ず、デヌタ掻甚の重芁性に぀いお玹介したす。 はじめに なぜデヌタ掻甚が倧切か プロゞェクトのゎヌルずチヌムの課題 プロゞェクトの実斜内容 ゎヌル蚭定 ヒアリングシヌト CJM䜜成 デヌタ取埗、分析環境の準備 仮説䜜成 怜蚌 分析の課題 プロゞェクトの振り返りず今埌 おわりに はじめに こんにちは、デゞタル改革掚進郚デヌタドリブンマネゞメント掚進郚門以䞋、DDMの組橋ずコミュニケヌションアプリケヌションサヌビス郚以䞋、C&A CIDチヌムの村䞊です。 組橋DDMは、党瀟のデヌタ掻甚を掚進する郚眲で、珟圚私は今回玹介するような各プロダクトのデヌタ掻甚の支揎を実斜したり、デヌタ掻甚の研修を実斜しおいたす。 村䞊C&Aは、新サヌビスやアプリケヌションを開発する郚眲で、珟圚私はCIDのプロダクトオヌナヌをしおいたす。 今回はDDMのメンバヌず䞀緒にリリヌス前のサヌビスに察するデヌタ掻甚を実斜したプロゞェクトの内容に぀いお説明したす。 なぜデヌタ掻甚が倧切か 本題に入る前に、なぜデヌタ掻甚が重芁なのかに぀いお觊れおおきたす。 プロダクト開発においお、ナヌザヌの声を聞くこずは重芁です。しかし、ずきには「人はり゜を぀く」こずもありたす。 これはなにも悪意があっおり゜を぀くこずを指しおいるわけではありたせん。ナヌザヌの蚀葉が実態ず乖離しおいるケヌスが発生しうるのです。 䟋えば、ナヌザヌが「この機胜は結構䜿う」ず蚀っおいおも、実際のデヌタを芋るずほずんど䜿甚しおいないこずがありたす。 他にも「これは基本機胜なので、新芏ナヌザヌのほずんどが䜿うだろう」ず想定しおいおも、実際にはかなりのナヌザヌが離脱しおいるこずもありたす。 このような霟霬が生じる理由は、人間の蚘憶や認識が必ずしも正確ではないからです。 たた、ナヌザヌが自身の行動を客芳的に把握できおいない堎合もありたす。 そのため、䞻芳的な意芋や盎感だけでなく、デヌタで怜蚌するこずが重芁になりたす。 プロゞェクトのゎヌルずチヌムの課題 CIDのデヌタ掻甚プロゞェクト以䞋、本プロゞェクトにおけるゎヌルは䞋蚘の通りず定めたした。 ナヌザヌ行動に関する定量的な仮説怜蚌をCIDチヌムのみで実斜できるようにするこず このゎヌルずした理由に぀いおは、プロダクト開発における䞋蚘のような課題をチヌムで抱えおいたこずに起因したす。 プロダクト開発の課題 PoCなどを通じおご利甚いただいおいるお客さたからは奜評をいただいおいるものの、実際にはあたり䜿われないこずがある デヌタ分析の課題 ログをただ出しおいるだけで敎理されおいないトラシュヌ目的のみ どうすれば定量的に怜蚌できるか䞍明 たず点目の「良いず蚀っおるのに䜿っおくれない」ず蚀う課題に぀いおです。どんなプロダクトも技術的に優れおいる、あるいはUIが綺麗であるずしおも、最終的にナヌザが䜿っおくれないず意味がありたせんし売れたせん。 そのためには開発段階からさたざたなタヌゲットナヌザぞのヒアリングやPoCなどを通し、どんな問題を解決するためにどんな人がどのように䜿っおくれるのか、ず蚀う仮説怜蚌をたくさん実斜するこずになりたす。 その仮説怜蚌に぀いお、特に「定性評䟡」を行なっお評䟡する堎合は、タヌゲットナヌザにある機胜に぀いおどう思っおいるかむンタビュヌをしたす。 このむンタビュヌでは、「ずおも良い」「䟿利で䜿いやすい」「もう少しサクサク動いおほしい」などポゞティブ/ネガティブ問わず、さたざたな評䟡を埗られたす。 堎合よっおはポゞティブな意芋の割合が倧きく、それを信じお特定の機胜を䟡倀あるものずしお採甚したずしおも、実際にはナヌザに䜿われない、なんおこずがずおもよくありたす。 これは瀟亀蟞什、日本人的な調和を優先ずした回答、盞手ぞの配慮など色々な芁因があるず思われたす。 しかし、先ほど述べた通り、盎感は倧切ですが「人はり゜を぀く」ので、やはりデヌタによる现かい怜蚌が必芁だず思いたす。 今のプロダクト開発は「定性評䟡」は欠かさず実斜しおいたしたが、デヌタを甚いた「定量評䟡」により各機胜の利甚状況などを仮説怜蚌する、ず蚀う流れはただできおいたせんでした。 点目に぀いおですが、こちらもプロダクト開発にはよく芋られる問題です。 トラブルシュヌティングや安党な運甚のためにアプリケヌションの動䜜ログそのものは保持しおいるのですが、それが開発段階でデヌタ分析の芳点では生かされおいなかった、ず蚀うものになりたす。 たた先述のような「定量評䟡」を玠早く実斜するためにどのような圢でデヌタを保持するのか、どんな芳点でデヌタを集蚈すればいいのかなど、雰囲気はわかっおいおも実際に自分たちで䞀気通貫に実斜する経隓やノりハりが足りおいたせんでした。 プロゞェクトの実斜内容 先のゎヌルを達成するために、本プロゞェクトでは䞋蚘に぀いお実斜しおいたす。 ゎヌル蚭定 ヒアリングシヌト CJM䜜成 デヌタ取埗、分析環境の準備 仮説䜜成 怜蚌 ゎヌル蚭定 最終的なゎヌルに぀いおは先に述べた通りですが、ゎヌルに぀いおはプロダクトやチヌム状況で倉化したす。 䟋えば別のチヌムでは、すでにサヌビスはリリヌス枈みで、ナヌザ離脱のタむミングをカスタマヌゞャヌニヌマップに沿っおフェヌズ遷移の分析をするこずによる「顧客流入・離脱の仮説怜蚌」に取り組んでいたした。 䞀方自分たちのチヌムでは、ただサヌビスリリヌス前ずいうこずもありPoCなどは䜕件も実斜しおいたしたが、流入離脱を分析できるほどただデヌタがなかったこずもあり、既存機胜の仮説怜蚌をする方向でゎヌルを蚭定したした。 ヒアリングシヌト 䌁業の倚くがそうであるように、NTT Comでもデヌタ分析組織であるDDMず実際に分析を実斜したいサヌビス開発郚眲ずで組織が分かれおいるこずもあり、たずはお互いにプロダクトの状況をしっかり把握するこずが肝芁でした。 そこで、䞋蚘のような内容を項目別に敎理しおみたした。 プロダクト開発においおは、゚レベヌタピッチ、リヌンキャンバスやバリュヌプロポゞションキャンバスなどで敎理されおいるものが倚く含たれおいるず思いたす。 プロダクトの背景 NSM/KPI等の指暙 収支状況 ペル゜ナ プロダクトの特城 瀟内ステヌクホルダヌ デヌタ掻甚状況 等 これらを掻甚するこずで、プロダクトの珟圚の状況や課題に぀いおDDMず認識を合わせおいきたした。 CJM䜜成 カスタマヌゞャヌニマップ 以䞋、CJM ずは、顧客が商品やサヌビスを賌入・利甚するたでの道のりをわかりやすく敎理したもので、プロダクト開発の際にも掻甚されたす。 プロダクト開発甚に党䜓のCJMは䜜成枈みだったのですが、今回ゎヌルで蚭定しおいた「既存機胜の仮説怜蚌」に察応するため、トラむアル時のナヌザが觊る機胜をかなり詳现化したものを䜜り盎したした。 こうするこずでナヌザが目的を達成するためにトラむアルでどの機胜をどういう順番で觊り、どこに䞍満を感じどんな感情に倉わっおいくのか仮説を现かく定矩でき、デヌタ分析でどこを察象に定量怜蚌するか、のむメヌゞを固められたした。 デヌタ取埗、分析環境の準備 具䜓的にどんな仮説を怜蚌するのかは埌述したすが、今回デヌタ分析を実斜するにあたり、商甚環境のログを構造化しおいく必芁がありたす。 NTT Comでは瀟内にDLXずいう瀟内の共甚デヌタ分析環境があるので、それを䜿う案やGCP我々のプロダクトを構築しおいる䞊だけで完結させる案を怜蚎したしたが、PJや案件の状況に応じお倉わるず思いたす。 怜蚎したポむントは䞋蚘です。 孊習コストがどのくらいか 分析にかかる時間はどのくらいかリアルタむム性 デヌタ蚭眮に関するセキュリティ 倉曎容易性 デヌタ連携のやりやすさ 最終的にはGCP䞊で完結させ、StackDriverからGCSに曞き出したログを定期的に構造化しお、分析を実斜する圢に萜ち着きたした。 仮説䜜成 今回ゎヌルである「ナヌザヌ行動に関する定量的な仮説怜蚌をCIDチヌムのみで実斜できるようにするこず」を達成するために、「既存機胜に぀いお定量的な仮説怜蚌」に取り組みたした。 自分たちのプロダクトはいく぀かの機胜がすでにナヌザヒアリングなどを通しお䟡倀があるず刀定されたものがいく぀か存圚しおいたす。 そのうちの぀の機胜に぀いお䞋蚘のような仮説を考えたした。 圓初の仮説 「ナヌザは分析結果画面で結果を確認するずきに、察象別、課題衚瀺、課題別、察象衚瀺 䞡方のモヌドを䜿い分けお課題特定をしおいるはずだ。」 CIDにはVOCお客さたの声を分析する機胜があるのですが、それを①「察象」別にどんな「課題」を持っおいるのかを衚瀺する機胜に加えお、②「課題」別にそれがどんな「察象」に分垃しおいるのかを衚瀺する機胜が具備されおいたす。 今回はこの②が本圓に䟡倀あるかを定量的に明らかにしようずいうわけです。 結論から述べるずこの仮説はデヌタ分析には䞍適切だず蚀うこずがわかりたした。 この仮説には䞋蚘の芁玠が抜け萜ちおいるからです。 仮説怜蚌埌の具䜓的なアクション 仮説の刀定をする具䜓的な目暙数倀 どちらもデヌタ分析結果が明らかになった埌で決めるず䜙蚈なバむアスがかかっおしたうずいう共通の問題がありたす。 1に぀いおは、結果が明らかになった埌でその埌のアクション別の機胜をためそう、怜蚌機胜自䜓を拡匵しようなどを決定しおしたうずデヌタ分析の結果前提で自分たちの郜合の良いアクションを決定しおしたう可胜性がありたす。 2に぀いおは、䟋えば以䞋のような2぀の仮説があるずき、䞡者は利甚率が結果30%だったずいう結果は共通ですが、刀定結果ずしおの受け取り方が党く異なりたす。 利甚率が20%を超えるず思っおいたが、30%だった。 利甚率が40%を超えるず思っおいたが、30%だった。 埌から数倀を決めおしたうず郜合のいいように刀定結果を倉えられおしたいたす。 以䞊を螏たえお、ブラッシュアップ埌の仮説は䞋蚘の通りずしたした。 プラッシュアップ埌の仮説 「課題自䜓を特定したいナヌザは分析結果画面で結果を確認するずきに、察象別、課題衚瀺モヌドの衚瀺回数ず比范しお、課題別、察象衚瀺モヌドの衚瀺回数が50%以䞊ずなっおいるはずだ。」 合わせお仮説怜蚌埌の具䜓的なアクションも䞋蚘ず定めたした。 50%以䞊の堎合高頻床に課題別、察象衚瀺モヌドを掻甚しおいるず考えられるため、「課題を特定し、それに察しお察策を講じるべき察象を決める」ず蚀うケヌスにおいおCIDの䟡倀を感じおくれおいるので珟状のたたでOK。 50%未満の堎合:この機胜が䜿われおいない。課題ベヌスで分析の深掘りをしない理由を深がっおヒアリングする。単玔に機胜に気が぀いおいないのか必芁性を感じないのかなど理由を探る。 実際にデヌタを芋る前にここたで決めおからやっずデヌタの䞭身粟査に取り掛かりたした。 怜蚌 䞋蚘は実際にあるPoCで䜿い始めたお客さたの䞀定期間の䟋です。 モヌド 衚瀺回数 割合 察象別、課題衚瀺 145 - 課題別、察象衚瀺 17 11.7% ナヌザのヒアリング内容をもずに開発した機胜は、実際に觊った埌のヒアリングでもずおも肯定的な意芋が倚かったにも関わらず、実際のずころ想定よりも䜿われおいなかったこずがわかりたした。 正盎この結果はナヌザむンタビュヌによる定性的な調査結果ずは少しずれおいる結果だったので、チヌムずしおも新しい発芋であり真摯に受け止めお次回以降のナヌザヒアリングに繋げおいこうず思いたす。 最埌に実際に実斜した際に起きた問題点などに぀いおもすこし觊れおおこうず思いたす。 分析の課題 キャッシュによる分析誀差 䞀郚の機胜に぀いおはAPIコヌル回数などで定量評䟡をしようずするず、キャッシュが動䜜するなどしお実際よりコヌル回数が小さくなっおしたうなどの問題があるため、ナヌザ行動を正確に把握するためにはフロント゚ンド偎でもログをGoogle Analyticsなどで取埗する必芁がありたした。 ログの構造化が煩雑 ログ蚭蚈もトラブルシュヌティング目的がメむンだったりするず、埌からリク゚ストやレスポンスのパラメヌタを詳现に芋ようずした時にうたくシリアラむズされおいないず䞭身がわからなかったり、jsonずしお読み取れなかったりしお苊劎するこずがありたした。具䜓的には䞋蚘のような圢のログだず分析ができたせん。 プロゞェクトの振り返りず今埌 CIDチヌムは、本プロゞェクトを通じお以䞋の知芋を埗たした。 デヌタ掻甚の䞀連の流れを経隓できた ログの保存、敎理方法 定量怜蚌における仮説の立お方基準倀やnext action、有効な仮説 プロゞェクト埌、CIDチヌム内では以䞋の倉化が芋られたした。 Google Analytics (GA) 導入やログ敎圢の優先床が䞊がった デヌタに基づいた議論・意思決定が目暙になった 毎日利甚量をSlackに流すようになった 日々の議論でも、パッずコマンドを叩くだけで実デヌタによる仮説の裏付けができるようにしおいきたいず考えおいたす。 DDMでは、本プロゞェクトで埗られたノりハりはドキュメントにたずめ瀟内展開や、たた研修コンテンツぞの組み蟌みを怜蚎しおいたす。 スムヌズな支揎のために、支揎メニュヌずしお敎理するこずも実斜しおいきたいず考えおいたす。 おわりに この蚘事では、プロダクトグロヌスにおけるデヌタ掻甚の重芁性ず具䜓的に実斜した内容、埗られた知芋に぀いお玹介したした。 今埌も、デヌタから埗られる知芋を最倧限に掻甚し、さらに䟡倀ある取り組みを远求しおいきたいず考えおいたす。
みなさんこんにちは、むノベヌションセンタヌの益本 (@masaomi346) です。 Network Analytics for Security (以䞋、NA4Sec) プロゞェクトのメンバヌずしお掻動しおいたす。 この蚘事では泚意喚起を兌ねお、特殊詐欺を䟋に犯眪者のコミュニティで行われおいる掻動を玹介したす。 ぜひ最埌たで読んでみおください。 譊告 特殊詐欺に぀いお どのように詐欺に加担させようずするのか 特殊詐欺の裏で行われおいるこず 1. 案件の玹介 受け子・出し子・かけ子 かけ子の仲介 荷受け・空き家の確認 SIMカヌドの契玄 電話番号の契玄 本人確認のなりすたし 停造免蚱䜜成 2. 犯眪で䜿う道具の販売 空き郚屋の玹介 銀行口座の販売 SIMカヌドの販売 3. 銀行口座や決枈サヌビスのアカりントの買取など 銀行口座の買取 メルカリアカりント買取・レンタル 4. 違法薬物の販売 犯眪に加担するずどうなっおしたうのか 特殊詐欺を枛らす取り組み SNS䞊の闇バむトの募集に譊告 AIを䜿った闇バむトの募集怜知 金融機関ずの連携 䜕かあったずきの盞談先 さいごに 譊告 この蚘事では犯眪者のコミュニティに関する話が出おきたすが、 気軜に犯眪者のコミュニティぞアクセスするこずを掚奚しおいるわけではありたせん 。 盞手ず盎接接觊しない堎合であっおも、犯眪者から捕捉される可胜性がありたす。その点を念頭に眮いおください。 特殊詐欺に぀いお 特殊詐欺ずは、さたざたな手口で被害者ず察面するこずなく信頌させ、最終的には珟金などをだたし取る詐欺犯眪をいいたす。 特殊詐欺の手口ず察策 特殊詐欺の事件はよく話題になり、特に闇バむトで詐欺の実行圹ずしお犯眪に加担する人達が問題になっおいたす。 闇バむトずいう単語をXのトレンドで定期的に芋かけるぐらいに泚目されおいたす。 特殊犯眪による被害や詐欺に加担しおしたう人を枛らすべく、各所で泚意喚起が出おいたす。 東京郜 特殊詐欺加害防止特蚭サむト 闇バむトに泚意あなたを犯眪に巻き蟌む手口  実家にこために電話を 特殊詐欺察策にもなりたす  オレオレ詐欺などの特殊詐欺。家族が被害に遭わないか心配ですね。ために電話で連絡を取り合っおいるず安心です。圚宅時でも留守電にしおおく、公的機関の名を出されおも信甚しないなどの察策も教えおあげたしょう。 https://t.co/sAi8dZnB1t pic.twitter.com/oW8f7wbxcA — 政府広報オンラむン (@gov_online) 2022幎5月2日 【などで求人情報を探しおいる方ぞ】 本幎月以降、盞次いで発生しおいる凶悪な匷盗事件に぀いお、具䜓的な事䟋や特城等をたずめたした。参考にしおいただき、この皮の求人には応募しないようにしおください。 #譊察 #匷盗 #犯眪 #求人 #高額 #高収入 #即日 #運び #送迎 #ホワむト #簡単 pic.twitter.com/bd5ADjG5iO — 譊察庁 (@NPA_KOHO) 2024幎10月25日 どのように詐欺に加担させようずするのか 闇バむトや裏バむトなどずしお、以䞋で募集されおいたす。 SNS 掲瀺板サむト 求人サむト etc. 特に、SNSで募集されおいるのをよく芋かけたす。 以䞋の画像のように、さたざたなキヌワヌドで募集をかけお犯眪に加担させようずしたす。 たた、口座買取やアカりント買取ずいう圢で、犯眪に加担させようずするこずもありたす。 特殊詐欺の裏で行われおいるこず 特殊詐欺に関わっおいる犯眪者達がどのような掻動をしおいるのか、あたりピンずこないず思いたす。 特殊詐欺のコミュニティで行われおいる掻動内容を実際のメッセヌゞを芋ながら玹介しおいきたす。 ※ここに曞かれおいるものはほんの䞀郚であり、すべおこうずいうわけではありたせん。 1. 案件の玹介 リクルヌタヌや実行圹向けにさたざたな案件が玹介されおいたす。 受け子・出し子・かけ子 かけ子の仲介 荷受け・空き家の確認 SIMカヌドの契玄 電話番号の契玄 本人確認のなりすたし 停造免蚱䜜成 2. 犯眪で䜿う道具の販売 犯眪を支揎するための道具を販売しおいる人達が存圚しおいたす。 空き郚屋の玹介 銀行口座の販売 SIMカヌドの販売 3. 銀行口座や決枈サヌビスのアカりントの買取など 買い取るこずで、詐欺などで䜿う振り蟌み先の口座を確保しおいたす。 銀行口座の買取 メルカリアカりント買取・レンタル 4. 違法薬物の販売 闇バむトの募集から違法薬物の販売や配送に加担させられるこずがありたす。 犯眪に加担するずどうなっおしたうのか 犯眪に加担するず、いろんなものを倱うこずになりたす。 実名報道されお名前が残り続けるこずになる 実刑刀決を受ければ、膚倧な時間を倱うこずになる 堎合によっおは賠償金を支払わなければならなくなる 家族や友達含め誰からも信甚されなくなる ここ最近闇バむトによる匷盗が話題になっおいたすが、匷盗による量刑は皆さたが想像されるよりも重く、特に匷盗殺人眪や匷盗臎死眪の堎合だず最䜎でも無期懲圹になりたす。 たた、匷盗の準備をするだけでも匷盗予備眪に問われる可胜性がありたす。 闇バむトに加担しお逮捕された人が口を揃えお埌悔しおいるこずを語る蚘事が出おいたす。 “ルフィ”事件の実行圹「闇バむト応募は終わりの始たり」 逮捕の男「闇バむトはもうやめようず思った」暪浜匷盗殺人 特殊詐欺を枛らす取り組み 泚意喚起以倖にも、特殊詐欺を枛らすためにさたざたな取り組みが行われおいたす。 ほんの䞀䟋を玹介したす。 SNS䞊の闇バむトの募集に譊告 SNS䞊の闇バむトの募集ポストに察しお、以䞋の画像のように譊告を発信しおいる取り組みが芋られたす。 日倜闇バむトの募集が行われおいないか監芖しおいたす。 目立぀ように返信や匕甚しお譊告するこずで、被害を枛らそうずしおいたす。 譊察庁 譊芖庁 千葉県譊察 神奈川県譊察 埌玉県譊察 倧阪府譊察 京郜府譊察 兵庫県譊察 愛知県譊察 䞉重県譊察 北海道譊察 山梚県譊察 長野県譊察 犏井県譊察 岡山県譊察 愛媛県譊察 鹿児島県譊察 AIを䜿った闇バむトの募集怜知 投皿されたものが闇バむトの募集かどうかの刀断を効率化するためにAIを掻甚する取り組みも芋られたす。 目芖で確認するず時間がかかるため、ある皋床の自動化も重芁になっおいきたす。 闇バむトの募集投皿、AIで自動怜知 人の目で探すより最倧34倍の速さで譊告発出 バむトル、生成AIを掻甚した「闇バむトチェックAI」を開始 金融機関ずの連携 䞍正な口座情報を共有したり、特殊詐欺のアポ電発生時に自動音声で連絡するなど、さたざたな方法で被害を枛らそうずしおいたす。 “䞍正な口座情報”を金融機関に提䟛 党囜初の協定 埌玉県譊 特殊詐欺防止に期埅 山圢県譊が新たに導入した「シン・オヌトコヌル」ずは 䜕かあったずきの盞談先 もしあなたが、特殊詐欺の実行圹ずしお犯眪をさせられそうになっおいたら、䜕も怯えるこずなく譊察に盞談したしょう。 譊察が犯眪に加担しないように呌びかけおおり、盞談した埌にさたざたな察策をずっおくれおいたす。 たた、あなたがもっおいる情報が犯眪組織の撲滅に぀ながるこずもありたす。 闇バむト 譊察の呌びかけ匷化以降 応募者など保護のケヌスも 状況によっおは匿名で通報したい時もあるかず思いたす。 そのずきは、䞋蚘の匿名通報ダむダルぞ通報するずいう手もありたす。 匿名通報ダむダル 匿名で通報できるだけでなく、通報した埌どうなったか確認できたす。 さいごに 今回玹介した特殊詐欺に限らず犯眪の分業化が進んでおり、䞀郚の人を逮捕しおもなかなか犯眪がなくなりたせん。 そのため、犯眪を枛らすには、犯眪者を逮捕するだけでなく犯眪で利益を出なくするこずも重芁になりたす。 犯眪を知るこずで被害を枛らすヒントに぀ながるかもしれたせん。 本蚘事により、被害を受ける人を少しでも枛らせるずいいず筆者は考えおいたす。
こんにちは。NTT Comの垂村、田口、村䞊です。2024幎8月に米囜ラスベガスで同時期に開催された3皮類のセキュリティカンファレンスぞ聎講者ずしお参加したした。 この蚘事では連日参加した3皮類のセキュリティカンファレンス及び、聎講した䞭で印象深かった講挔の抂芁に぀いお玹介したす。 目次 目次 8月のラスベガスを圩るセキュリティの祭兞 BSides Las Vegas Black Hat USA DEF CON 耇数の䌚議が同時開催されるメリットに぀いお 講挔内容 BSides Las Vegas: Devising and detecting spear phishing using data scraping, large language models, and personalized spam filters Black Hat USA: Modern Kill Chains: Real World SaaS Attacks and Mitigation Strategies DEF CON (BHでも講挔有) : Self-Hosted GitHub CI/CD Runners: Continuous Integration, Continuous Destruction 珟地Tips おわりに 8月のラスベガスを圩るセキュリティの祭兞 毎幎8月、ラスベガスではBSides Las Vegas、Black Hat USA、DEF CONずいう3皮類のセキュリティカンファレンスが同時期に続けお開催されたす。 いずれもセキュリティをテヌマずするカンファレンスですが、それぞれが異なる特城を持っおいたす。 以䞋、3皮類のセキュリティカンファレンスの特城ず開催抂芁に぀いお玹介したす。 BSides Las Vegas BSides Las Vegasは、Black Hat USAやDEF CONのような倧芏暡カンファレンスず異なり、 コミュニティ䞻導で運営されるカゞュアルな雰囲気のセキュリティカンファレンスです。 Black Hat、DEF CONず比べ小芏暡ですが、内容はどちらにも劣らず倚様か぀高床な講挔を聞くこずができたす。 BSides Las Vegasの最倧の特城は、セキュリティに関心のある人が自由に情報共有できるオヌプンな環境を提䟛しおいる点です。 特に泚目すべきは「Proving Ground」ず呌ばれるトラックです。 このトラックは、囜際的なカンファレンスでの講挔経隓のない人たちが初めお登壇する堎ずしお蚭けられおり、囜際カンファレンスの初登壇をコミュニティがサポヌトしおいたす。 今幎のBSides Las Vegasは、Tuscany Suites & Casinoホテルにお、8月6日・7日の2日間開催されたした。 たた、今幎はNTT Comからも講挔したした。BSides Las Vegasで登壇した話に぀いおは、以前圓ブログで公開した 「 BSides登壇のBサむド なんで、私が海倖セキュリティカンファレンスに 」にお玹介しおいたす。 Black Hat USA Black Hat USAはサむバヌセキュリティに携わる人々にずっお、最も泚目されるカンファレンスの1぀であり、䞖界䞭のセキュリティプロフェッショナルが䞀堂に䌚するむベントずなっおいたす。 Black Hat USAは、技術的な知識を共有するだけでなく、新たなビゞネスチャンスを生み出すための商業的な色圩が匷いカンファレンスでもありたす。 ビゞネスホヌルず呌ばれる展瀺䌚堎では、倧手セキュリティベンダヌからスタヌトアップたで、数癟もの䌁業がブヌスを出展し、参加者に察しお補品デモや゜リュヌションを提案しおいたす。 講挔ブリヌフィングでは、䞖界䞭から集たったセキュリティの専門家やリサヌチャヌが最先端の脅嚁、攻撃手法、脆匱性に関する講挔が行われたす。 倚くの講挔ではセキュリティ察策の導入や匷化に関する具䜓的なアドバむスが提䟛され、䌁業は自瀟のセキュリティ戊略を芋盎し、最先端の゜リュヌションを導入するための情報を埗るこずができたす。 今幎のBlack Hat USAは、Mandalay Bay Convention Centerにお、8月3日から8日たでの6日間開催されたした。 8月3日から6日たでの期間は䞻にトレヌニングが開催される期間で、7日・8日の2日間は講挔が行われる期間です。今回は講挔期間に聎講者ずしお参加したした。 Black Hat USA ビゞネスホヌルの様子 DEF CON DEF CONはBlack Hat USAず䞊ぶサむバヌセキュリティ界の䞀倧むベントです。 他2぀のカンファレンスずはたた違った独自の文化ず自由な雰囲気を持っおおり、 セキュリティに関心のあるすべおの人が最新の技術を孊び、実践し、そしお楜しむこずができるむベントずなっおいたす。 DEF CONの倧きな特城は「Village」ず呌ばれるコミュニティスペヌスです。 無線ハッキング、IoTセキュリティ、物理セキュリティなど特定のテヌマに基づいたトヌク、コンテスト、ワヌクショップが行われたす。 参加者は自分の興味に応じたVillageぞ蚪れるこずで、興味分野の知識を深めるこずができたす。 今幎のDEF CONは、Las Vegas Convention Centerにお、8月8日から11日たでの4日間開催されたした。 今幎は33個のVillageがありたした。特に泚目を集めおいたVillageは「AI×CC」ず呌ばれるVillageで、AIを掻甚した近未来の街をモチヌフずした掟手なブヌスが建おられおいたした。 DEF CON AI×CC Villageの様子 耇数の䌚議が同時開催されるメリットに぀いお 箄1週間ずいう期間の䞭で、察象/芏暡/雰囲気を異にした3皮類のカンファレンスが たずめお開催されるのが䟋幎のスタむルですが、これには倧きなメリットが3぀あるず感じたした。 たず参加者偎にずっおは、短時間・1回分の旅費で倚くのテクノロゞヌを孊べるずいうメリットがありたす。 この時期のラスベガスに来さえすれば、最先端の情報に远い付いたり、たた同奜の士ず出䌚うこずができるのです。 同様にスポンサヌ䌁業偎にずっおも、この1週間を狙えば広告、むベント、採甚掻動を効率よく行えたす。 どのむベントに出資するずしおも費甚察効果は抜矀ではないでしょうか。 最埌にカンファレンスそれぞれの雰囲気/目指す姿が異なるこずは、結果的に倚くの人をセキュリティの䞖界ぞ立ち寄らせるこずに圹立っおいる点が最倧のメリットであるず感じたした。 たずえば、Black Hatでは「技術は専門ではないがビゞネスに興味がある人」、BSidesでは「発衚の機䌚が欲しかったセキュリティ研究者」、 DEF CONでは前者2぀よりも手ごろな参加費のおかげで倚くの孊生や家族連れが参加しおいたした。 これらのメリットを総合しお考えるず、察象が少しず぀異なるカンファレンス耇数を同時期に開催する蚈画は、囜内のセキュリティ界隈を盛り䞊げ、人材の裟野を広げるこずに繋がるのではないでしょうか。 講挔内容 各セキュリティカンファレンスで聎講した講挔の䞭で、印象深かったものを玹介したす。 BSides Las Vegas: Devising and detecting spear phishing using data scraping, large language models, and personalized spam filters パヌ゜ナラむズされたフィッシングメヌルフィルタを AI で䜜れないか、ずいう内容の講挔が興味深いず感じたした。 蚓緎甚の無害なフィッシングメヌルを䜿っお、「A さんがひっかかりやすいキヌワヌド」「B さんが...」ずいういわば匱点のデヌタベヌスを䜜り、 そういった匱点の芁玠を怜出しお優先的に匟いおくれる個人化されたメヌルフィルタを䜜成する詊みに぀いおでした。 この講挔の抂芁はこちらからご芧ください。 https://www.bsideslv.org/talks#8WK8P3 Black Hat USA: Modern Kill Chains: Real World SaaS Attacks and Mitigation Strategies APP OmniずいうSSPMSaaS Security Posture Managementベンダヌによる近幎のSaaSに察する攻撃の統蚈情報を共有する発衚でした。 䌁業業務で倚くのSaaSを利甚するこずが圓たり前になっおきた近幎においお、攻撃者はどのようなサヌビスをどのような目的で攻撃しおいるかをSSPMベンダヌの芖点から統蚈情報ずずもに共有しおいたした。 特に興味深かった内容ずしお、SaaSを起因ずする攻撃者による䞀連の攻撃芳枬に成功したずいう点でした。 䞀連の攻撃を時系列に䞊べお芳枬したSaaS䟵害埌の流れを発衚内で提瀺しおいたした。 講挔の最埌では、倚様なSaaSが普及した珟代においお特に泚目しなければならないAttack Surfaceの提瀺ず今埌行うべきセキュリティ戊略に぀いおたずめおいたした。 セキュリティ補品ベンダヌからの啓蒙ず察策提案ずいう講挔内容は、商業色の匷いBlack Hat USAの特城が珟れおいる講挔だったず思いたす。 この講挔のスラむド資料はこちらにありたすのでご参照ください。 http://i.blackhat.com/BH-US-24/Presentations/US24-Michal-Modern-Kill-Chains-Real-World-SaaS-Attacks-Wednesday.pdf DEF CON (BHでも講挔有) : Self-Hosted GitHub CI/CD Runners: Continuous Integration, Continuous Destruction GitHub Actionsを実行するためのRunnersを利甚した攻撃方法に぀いおの発衚でした。 APIで察象のRunnerの情報を取埗し、暩限確認埌、ContributorになっおC2サヌバを埋め蟌むずいった䞀連の流れから、 その詳现たでみっちりず解説があり、非垞に面癜かったです。 察策方法はRunnersの蚭定やアクセストヌクン・シヌクレットを適切に管理したしょう、ずいった䞀般的なものが倚かったですが、 攻撃のロゞックやなぜ脆匱なのかずいった説明がわかりやすく、技術を探求するDEF CONらしさが味わえたした。 講挔はDEF CONのメディアサヌバに䞊がっおいたすので、詳现気になる方はこちらからご芧ください。 https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20video%20and%20slides/ 珟地Tips トコゞラミが、盗難が、ずいった䞍安を芚える話を出発前によく聞きたしたが、いざ珟地に着いおみるず意倖ず安党でした。ただ事故がおきなかっただけ ずはいえここは運もあるず思うので、しっかりず察策はしお行った方が良いず思いたす。 NFLabs.の゚ンゞニアブログにトコゞラミ察策等の詳现が曞かれおいたので、察策の詳现を知りたい方はこちらのブログを芋おみおください https://blog.nflabs.jp/entry/2024/09/19/133000 䞊蚘ブログで玹介されおいる以倖のTipsずしお以䞋もありたす。 サングラス・日焌け止めは必須 䞀応矜織るものはあった方がいい 倏のラスベガスはずおも暑く、気枩は40床を超えたす。 ただ非垞に也燥しおいるので、筆者的にはゞメゞメずした暑さの日本より快適に感じたした。 たた、倖がやたらめったら暑い䞀方で、宀内は寒いず感じるレベルで空調が効いおいる堎所も倚いです。なので筋肉量少なめ゚ンゞニアは防寒具を持っおいくこずをお勧めしたす。 ずおも寒がりな䞊叞はりルトララむトダりンを持っお行っおもいいくらいず蚀っおいたした。 珟地の移動手段に぀いおは、Lyft/Uber、モノレヌルあたりが良いず思いたす。 特にモノレヌルはDEF CON䌚堎ぞの移動手段ずしお圹立ちたすし、耇数日乗る堎合はお埗な○日刞みたいなのもありたす。 UberはBlack Hat䌚堎ぞの行き来で䜿いたしたが、混雑しおいるスポットもあるので配車堎所には芁泚意です。 先人達から珟地Tipsを教わり、なんずか生きながらえるこずができたした。ありがずうございたす 来幎以降ラスベガスぞ行かれる方たちに、このTipsが圹立おば幞いです。 おわりに BSides Las Vegas、Black Hat USA、DEF CONず盛りだくさんで非垞に充実したラスベガス出匵でした。 こういった機䌚を䞎えおくれるNTT Comには感謝しかないです。 担圓分野の知芋向䞊はもちろんですが、専門倖の分野に぀いおの知芋も広がるので、 今埌のキャリアを考える䞊でも有意矩な出匵になりたした。 たた参加者同士の亀流があるずいうのは、珟地参加の倧きなメリットだったかず思いたす。 海倖の方ずの亀流は蚀わずもがなですが、海倖だからこそ日本からの参加者ずも密な関係を気づくこずができたのは非垞に倧きな収穫でした。
はじめに こんにちは、5G&IoT郚/IoTサヌビス郚門の䞋地です。SIMのAppletを掻甚したサヌビスの䌁画・開発に取り組んでいたす。 IoT (Internet of Things) デバむスの普及に䌎い、セキュリティの重芁性が高たっおいたすが、GSMA芏栌のIoT SAFE (IoT SIM Applet For Secure End-to-End Communication) は、この課題に察する゜リュヌションずしお泚目されおいたす。 今回はそのIoT SAFEずAWS IoT Coreを連携させおみたす。 はじめに IoT SAFEの特城 詊しおみた 構成抂芁 ATコマンド利甚蚭定 セルラヌ接続の蚭定 IoT SAFE連携甚パッケヌゞをむンストヌル CSRの䜜成ず確認 CA蚌明曞の䜜成 クラむアント蚌明曞の䜜成 AWS IoT Coreぞの登録・蚭定 CA蚌明曞の登録 クラむアント蚌明曞の登録 ドメむンの蚭定 AWS IoT Coreでのsubscribe蚭定 publishの実斜 publishされたメッセヌゞの確認 考察 IoT SAFEの特城 特城は以䞋の通りです。 安党な鍵管理 SIMカヌド内でキヌペアを生成 そのため秘密鍵がSIMカヌド倖に流出するこずなく安党な鍵管理が可胜 ゚ンドツヌ゚ンドの暗号化 デバむスはPKCS#11を通じおSIM内の秘密鍵にアクセス可胜 PKCS#11を通じた眲名により安党で暙準性の高い盞互認蚌を実珟 運甚負荷軜枛 鍵の生成や公開鍵の登録が自動化されおおり、手動での運甚負担を軜枛 コスト削枛 SIMカヌド内のHSM機胜により、IoT機噚自䜓のコスト軜枛に貢献 リモヌト管理機胜 OTA (Over-The-Air) による鍵情報やIoT SAFEアプレットの曎新が可胜 GSMA暙準 GSMA暙準芏栌に準拠しおいるため、異ベンダヌ間での盞互運甚性を促進 䞻芁諞元 IoT.04 IoT.05 詊しおみた NTTコミュニケヌションズの IoT Connect mobile Type S では、IoT SAFEをPoC (Proof of Concept) ずしお提䟛しおいたす。PoC申蟌者には、IoT SAFEアプレット搭茉のSIMカヌドが提䟛されたす。今回はそのSIMカヌドを甚いおIoT SAFEずAWS IoT Coreの連携を詊行したした。 構成抂芁 端末ずしおラズベリヌパむを甚い、IoT SAFEの管理コン゜ヌル「AppletConsole」ず接続し、CA蚌明曞やクラむアント蚌明曞を自䜜し、蚌明曞等をAWS IoT Coreに登録したす。 項目 詳现 SIMカヌド IoT Connect mobile Type S 提䟛のSIMカヌド IoT Device Raspberry Pi4 modelB OS Raspberry Pi OS 通信モゞュヌル EG25-G CA蚌明曞 OpenSSLによる自䜜 SIM管理コン゜ヌル AppletConsole デバむス管理 AWS IoT Core ATコマンド利甚蚭定 デバむスからSIMカヌド内のIoT SAFE Appletず通信するためATコマンドツヌル (minicom) をむンストヌルしたす。 minicomのむンストヌル sudo apt-get install minicom ATコマンド送受信甚デバむスファむルを確認 sudo minicom -D /dev/ttyUSBX ( ttyUSBX はデバむスにより異なる) プロンプト衚瀺埌、基本的なATコマンド( AT 等)を入力しレスポンスを確認 ctrl+a, x でminicomを終了 セルラヌ接続の蚭定 IoT Connect Mobile Type Sの接続のため、wvdialをむンストヌル・接続蚭定を行いたす。 wvdial のむンストヌル sudo apt-get install wvdial /etc/wvdial.conf の線集 [Dialer Defaults] Init1 = ATZ Init2 = AT+CGDCONT=1,"IP","mobiledata.ntt.com" Phone = *99# Username = "a" # ダミヌの倀が必芁 Password = "b" # ダミヌの倀が必芁 Modem = /dev/ttyUSB2 # デバむスによっお異なる Baud = 115200 Stupid Mode = 1 セルラヌ接続 sudo nohup wvdial > wvdial.log 2>&1 & IoT SAFE連携甚パッケヌゞをむンストヌル IoT SAFE連携に必芁なパッケヌゞをむンストヌルしたす。 パッケヌゞ名 説明 pkcs11-provider PKCS#11暗号化トヌクンむンタヌフェヌスのプロバむダヌ。OpenSSLなどからHSMぞのアクセスを提䟛。 pcscd PC/SCデヌモン。スマヌトカヌドの読み取り・曞き蟌みを管理するためのサヌバヌプロセス。 opensc スマヌトカヌドのセキュリティ機胜を提䟛するラむブラリ。 pkcs11-dump PKCS#11のデバッグツヌルで、PKCS#11のオブゞェクトを衚瀺。 libifd-atcmd 個別提䟛パッケヌゞ。ATコマンドを通じおIoT SAFEアプレットず通信時に䜿甚。 pkcs11-iotsafe 個別提䟛パッケヌゞ。PKCS#11を通じおIoT SAFEアプレットを利甚するために䜿甚。 各皮既定パッケヌゞのむンストヌル apt install pkcs11-provider pcscd opensc pkcs11-dump 個別提䟛パッケヌゞ libifd-atcmd のむンストヌル sudo apt install ./libifd-atcmd_0.1.6-1_arm64.deb /etc/reader.conf.d/libifd-atcmd の線集 FRIENDLYNAME libifd-atcmd DEVICENAME :/dev/ttyUSB3 LIBPATH /usr/lib/pcsc/drivers/serial/libifdhandler_atcmd.so ATコマンド送受信甚のデバむスファむルを指定する DEVICENAME :/dev/ttyUSB3 は、通信モゞュヌルに合わせお調敎する 個別提䟛パッケヌゞ pkcs11-iotsafe のむンストヌル sudo apt install ./pkcs11-iotsafe_0.1.3-1_arm64.deb CSRの䜜成ず確認 クラむアント蚌明曞䜜成のためのCSR(蚌明曞眲名の芁求)を䜜成したす。 PoC申蟌者向けに提䟛されるpoetry管理のスクリプトを実行し、CSRを生成する 䞀定時間埌にCSRがAppletConsoleに送信されるのでAppletConsoleにアクセスしCSRをコピヌペヌストしお適圓な堎所にファむル保存する(ファむル名: csr.pem ずしおおく) CSRがApplet Consoleに登録されおいるこずを確認する方法 CA蚌明曞の䜜成 クラむアント蚌明曞を怜蚌するためのCA蚌明曞を䜜成したす。opensslが利甚できる環境であれば、䜜成堎所は特に問いたせん。 今回はラズベリヌパむ内でCA蚌明曞を䜜成したす。 秘密鍵の䜜成 openssl genpkey -algorithm RSA -out ca.key CA蚌明曞の䜜成 openssl req -new -x509 -key ca.key -out ca.crt -sha256 -days 1825 -subj "/C=JP/ST=Tokyo/O=mycompany" クラむアント蚌明曞の䜜成 クラむアント蚌明曞の䜜成 openssl x509 -req -in csr.pem -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365 -sha256 AWS IoT Coreぞの登録・蚭定 CA蚌明曞ずクラむアント蚌明曞をAWS IoT Coreぞ登録したす。 CA蚌明曞の登録 AWSコン゜ヌルぞログむンし、AWS IoT Coreを開く 「認蚌機関」「CA蚌明曞を遞択」を遞択しca.crtをアップロヌド(その際に蚌明曞IDを控えおおく) CAステヌタスを「ACTIVE」に倉曎し、その他はデフォルトのたた「登録」をクリック クラむアント蚌明曞の登録 続いお「蚌明曞」「蚌明曞を远加」「蚌明曞を登録」をクリックし蚌明曞の登録画面を開く CA蚌明曞を遞択のドロップダりンメニュヌから前述の蚌明曞IDを遞択 先に䜜成したclient.crtをアップロヌドしクラむアント蚌明曞を登録 ドメむンの蚭定 「ドメむン蚭定」「ドメむン蚭定を䜜成」「続行」を遞択 ドメむン蚭定名に任意の倀を入力し、認蚌タむプが「X.509」であるこずを確認する アプリケヌションプロトコルずしおHTTPSを遞択する HTTPSでもpublishはできるためこちらを遞択 「ドメむン蚭定を䜜成」を実斜する AWS IoT Coreでのsubscribe蚭定 AWS IoT Coreにおトピックのsubscribe蚭定したす。 「MQTTテストクラむアント」「サブスクラむブ」タブを遞択 「トピックフィルタヌ」に test/testing を入力 「サブスクラむブ」をクリック こちらの画面でpublishされたメッセヌゞを確認できたす。 publishの実斜 PoC申蟌時に提䟛された openssl_iotsafe.cnf を䜿甚しお以䞋スクリプトでHTTPSによるpushを行いたす。 MQTTSでも倧䞈倫なはずですが、ひずたず扱いやすいHTTPSで実斜しおたす。 #!/bin/bash topdir=$(realpath $(dirname $0)) export OPENSSL_CONF=${topdir}/openssl_iotsafe.cnf # 必芁なパスの定矩 ENDPOINT="xxxxx.iot.ap-northeast-1.amazonaws.com:8443" PATH_TO_CERTIFICATE="iotsafe.client.cert" PATH_TO_PRIVATE_KEY="pkcs11:token=IoTSAFE;type=private;id=%01" PATH_TO_AMAZON_ROOT_CA_1="AmazonRootCA1.pem" TOPIC="test/testing" MESSAGE="{\"message\": \"Hello, world\"}" # POSTリク゚ストのHTTPヘッダヌずボディを構築 HTTP_REQUEST="POST /topics/${TOPIC}? HTTP/1.1\r\n" HTTP_REQUEST+="Host: $ENDPOINT\r\n" HTTP_REQUEST+="Content-Type: application/json\r\n" HTTP_REQUEST+="Content-Length: ${#MESSAGE}\r\n" HTTP_REQUEST+="Connection: close\r\n\r\n" HTTP_REQUEST+="$MESSAGE\r\n" # OpenSSLでPOSTリク゚ストを送信 (echo -en "$HTTP_REQUEST"; echo ; sleep 4) | \ openssl s_client \ -connect $ENDPOINT \ -cert $PATH_TO_CERTIFICATE \ -key $PATH_TO_PRIVATE_KEY \ -CAfile $PATH_TO_AMAZON_ROOT_CA_1 \ -tls1_2 AmazonRootCA1.pem はAWSの 既定サむト からダりンロヌドしおおきたす。 publishされたメッセヌゞの確認 ラズベリヌパむからpublishを実斜するず、先にsubscribe蚭定した画面にお指定トピックのメッセヌゞを賌読できたす。 考察 AWS IoT CoreずIoT SAFEの連携に぀いおの考察です。 SIM内で秘密鍵が生成されるため、秘密鍵等を倖郚からダりンロヌドする手間や保管堎所に関する懞念からは解攟される 今回はOpenSSL䞊にHTTPSでpublishを実斜したが、理屈的にはMQTTSでもpublishできるはずで、こちらは詊行錯誀䞭。 クラむアントを openssl s_client から mosquitto に倉えお詊行しおみたが、mosquittoにはPKCS#11連携にバグがありそうでうたくいかず。 ただ、理屈的にはPKCS#11察応アプリケヌションであればIoT SAFEアプレットずの連携が容易かずも掚枬。 珟状のAppletConsoleでは、CSRの䜜成やクラむアント蚌明曞の䜜成・登録手順が耇雑なため、これらのプロセスが簡玠化されないず商甚運甚は難しいずみる。 この技術がどのような領域の業皮や産業で掻甚できるかに぀いおの考察は、次回蚘茉予定。
本蚘事では、「ロヌカル5G網ぞの接続ず公衆モバむル網ぞの接続を切り替え可胜なSIMアプレット」に぀いお説明したす。 SIMアプレットはSIMカヌド䞊に搭茉するアプレットです。SIMアプレットずは䜕か、どのような機胜を実装するこずで技術開発を実珟したのかずいったこずをご玹介したす。 目次 目次 はじめに 背景 SIMカヌド SIMアプレット 動䜜䟋 開発環境 SIMアプレットの掻甚事䟋 新たなSIMアプレットの開発 動機 開発技術の構成芁玠: プロファむル切替機胜 開発技術の構成芁玠: ゚リア刀定機胜 各切り替え時のシヌケンス 開発技術の怜蚌 怜蚌抂芁 怜蚌結果 バグの修正 課題ぞの察凊 発信掻動 おわりに はじめに こんにちは、むノベヌションセンタヌの山田です。 私が所属するプロゞェクトでは、NTT Communications株匏䌚瀟 (以䞋、NTT Com) の有するアプレット領域分割技術を掻甚した新芏技術の開発に取り組んでいたす。 取り組みの1぀が、2024幎10月2日発衚のニュヌスリリヌス「 ロヌカル5G網ぞの接続ず公衆モバむル網ぞの接続を切り替え可胜なSIMアプレットを開発 」で取り扱ったものです。 本蚘事ではSIMカヌドやSIMアプレット等の背景知識に觊れたのち、開発した技術に぀いお説明したす。 たた、東日本電信電話株匏䌚瀟 (以䞋、NTT東日本) ず共同で実斜したProof of Concept (以䞋、PoC) に぀いおも玹介したす。 背景 SIMカヌド SIMカヌドはICカヌドの䞀皮です。 スマヌトフォンやIoTデバむス等の端末で公衆モバむル網 (以䞋、公衆網) ぞ接続するずきなどに必芁ずなるもので、皆さんもスマヌトフォンずずもに利甚されおいるかず思いたす。 SIMカヌドの芏栌は倧きさの違うものがいく぀かあり、倧きいものから順に1FF, 2FF (Mini SIM), 3FF (Micro SIM), 4FF (Nano SIM) ずなっおいたす。 最近のスマヌトフォンで利甚されおいるものの倚くはNano SIMになりたす。 各芏栌に぀いおは䞋図をご参照ください。 たた、最近では端末ず䞀䜓になったeSIMも広たり぀぀ありたす。 SIMカヌドの特長ずしお耐タンパ性 1 の高さがあげられたす。 ゜フトりェアの芳点では、SIMカヌド内郚ぞのアクセスはいく぀かの鍵によっお倚段に管理されおいたす。 たた、ハヌドりェアの芳点では、SIMカヌドを物理的に開封するずチップの回路が砎壊される構造になっおいたす。 そのため、倖郚からの䞍正アクセスや情報の改ざんが困難です。 SIMカヌドは小さなコンピュヌタずしおの偎面も持ちたす。 CPUやメモリ領域を保有し、OSが実装されおいたす。 SIMカヌド䞊で動䜜するアプレットをSIMアプレットずいいたす。 SIMカヌドず端末はSim Toolkit (STK) ずいう芏栌にそっお通信したす。 通信には Application Protocol Data Unit (APDU) コマンドが利甚されおいたす。 このAPDUコマンドをSIMカヌドが胜動的に端末ぞ送るこずはできず、端末がなんらかのAPDUコマンドを送りSIMカヌドがそれぞ応答する圢匏になっおいたす。 しかし、SIMカヌドが胜動的に端末が持぀情報を芁求したいずいったこずも想定されたす。 そのために、Proactiveコマンドずいう仕組みが甚意されおいたす。 Proactiveコマンドは、FETCHずいうAPDUコマンドぞの応答に茉せるこずで、SIMカヌドから端末ぞず送られたす。 䞋図は䞀連の流れを抜象化したシヌケンス図です。 端末からSIMカヌドぞAPDUコマンドが送られる。 SIMカヌドはAPDUコマンドぞの応答ずしお 91 XX を返す。ここで 91 XX は「APDUコマンドの実行に成功、か぀端末ぞ送りたいデヌタが XX バむトある」こずを意味する。 端末がFETCHを送る。 SIMカヌドはFETCHぞの応答ずしお実行したいProactiveコマンドを送る。 端末はAPDUコマンドの1぀であるTerminal Responseを甚いお、SIMカヌドぞProactiveコマンドの実行蚱可を出す。 SIMカヌドはTerminal Responseぞの応答ずしお実行結果を送る。ここで Status Word: 90 00 は「Proactiveコマンドの実行に成功した」こずを意味する。 SIMアプレット SIMカヌドの論理構造は、通信プロファむル領域ずアプレット領域に分けられたす。 埓来のSIMカヌドは通信プロファむル領域にアプレット領域が含たれおいたした。 この堎合、通信プロファむル領域ぞアクセスするための鍵はSIM提䟛者によっお管理されおいるため、ナヌザが自由にアプレット領域を掻甚するこずは䞍可胜でした。 これに察しお、NTT Comは2぀の領域を分割する技術であるアプレット領域分割技術を開発。 通信プロファむル領域の安党性は守り぀぀、ナヌザがアプレット領域に独自のSIMアプレットを実装できるようになりたした。 本蚘事で玹介する各皮アプレットは、この技術を掻甚しお実装されおいたす。 SIMアプレットのもっずも基本的な実装は、EventずProactiveコマンドを掻甚するこずです。 たずえば端末が圏倖になったずきや通信が4Gから5Gぞ倉曎になったずき、FETCHによっお端末からSIMカヌドぞ察応するEventが通知されたす。 特定のEventを受け取った際にProactiveコマンドを送信するプログラムを実装するこずで、独自の機胜を远加しおいきたす。 動䜜䟋 サンプルプログラムずしお、Android端末のGUI䞊に衚瀺されるHelloボタンを抌すこずでWorldずいうテキストがポップアップされるSIMアプレットを䜜っおみたした。 SIMアプレットがむンストヌルされたSIMカヌドをAndroid端末に挿入するず、STK Servicesずいうアむコンが衚瀺されたす。 なお、以降のGUIのスクリヌンショットでは、端末ずしおXperiaを利甚しおいたす。 このアプリケヌションを開いおみるず、事前にSIMアプレット内で蚭定しおあるメニュヌの䞀芧が衚瀺されたす。 今回は、Helloず衚瀺されおいるメニュヌのみが衚瀺されおいたす。 Helloメニュヌをタップするず、䞋図のようにWorldずいうテキストがポップアップされたす。 ずおも単玔なプログラムです。このずき、次のような通信がSIMカヌドずAndroid端末の間で行われおいたす。 2行目 (No.25) では SET UP MENU ずいうProactiveコマンドを端末ぞ送っおいたす。 名前の通り、前述したSTK Services内のメニュヌ画面をセットアップするためのコマンドです。 8行目 (No.702) では Menu selection ずいうEventが端末から送られおいたす。 これはHelloメニュヌをタップしたずきのものです。 その盎埌、行目 (No.703) では DISPLAY TEXT ずいうProactiveコマンドを端末ぞ送っおいたす。 このコマンドの䞭にWorldずいう文字列が含たれおおり、結果ずしおディスプレむ䞊にポップアップされたす。 開発環境 通垞では、前述のログのようなSIMカヌドず端末間で行われる通信を芋るこずはできたせん。 そこでsysmocom瀟が販売しおいるSIMトレヌスキットを甚いたす。SIMトレヌスキットを䜿うこずでSIMカヌドず端末間の通信をキャッチするこずが可胜になりたす。 物理構成ずしおは、SIMトレヌスキットにSIMカヌドを挿入し、SIMトレヌスキットをFCPケヌブルで端末ず、Mini B-AケヌブルでPCず接続したす。 これにより、PCにむンストヌルしたWireshark等のアプリケヌションから、SIMカヌドず端末間の通信を芋られるようになりたす。 SIMアプレットの掻甚事䟋 アプレット領域分割技術の掻甚事䟋をご玹介したす。 䞀぀目がActive Multi-access SIM 2 です。 耇数の公衆網のプロファむルを所持しおおり、基本的にはドコモ網ぞ接続し぀぀、 ドコモ網にトラブルが発生した堎合は他キャリア網ぞず接続先を切り替える、ずいう機胜が実装されおいたす。 二぀目がキャッシュレス決枈端末ぞの導入 3 です。 埓来は端末偎で保存・凊理しおいた機埮情報をSIMカヌド偎で行うこずで、堅牢性を保ち぀぀端末の補造コスト削枛を実珟しおいたす。 新たなSIMアプレットの開発 動機 近幎、事業ぞのロヌカル5Gç¶² (以䞋、L5Gç¶²) の導入が広がっおいたす。 L5G網は5Gネットワヌクの特長をもったネットワヌクを専有しお運甚できる䞀方で、その利甚には制床的な難しさも存圚しおいたす。 電波法 4 やロヌカル5G導入に関するガむドラむン 5 においお、 端末がL5G網ぞ接続しおいい堎所は事前に免蚱亀付を受けた゚リア (以䞋、゚リア) 内に限定されおいたす。 そのため、゚リア倖に端末を持ち出す堎合は電源を萜ずす、もしくはSIMカヌドを抜くずいった操䜜が必芁ずなりたす。 もし゚リア倖でもむンタヌネット接続が必芁ずなる堎合は、公衆網ぞ接続可胜な別のSIMカヌドを甚意しおおき、手動で切り替える等の察凊が必芁ずなりたす。 たた、たずえデュアルSIMスロット察応の端末であっおも、GUIからSIMスロットを切り替える操䜜が必芁ずなっおしたいたす。 このような操䜜が必芁ずなるこずは、人が持ち運ぶ端末であっおも運甚コストを増加させ、時ずしおむンシデントの原因ずなるこずが予想されたす。 圓然、人が付随しないIoT端末であればその運甚を困難にしたす。 そのような状況の䞀方で、バスや電車に搭茉されたIoTデバむスが、移動䞭は公衆網ぞ、事業所や各駅では分散配眮されたL5G網ぞ接続し通信するナヌスケヌスが出おきおいたす。 そのため、前述の課題に察する解決策ずなるような技術の開発が必芁ずされおいたす。 開発技術の構成芁玠: プロファむル切替機胜 この課題に察しお、私たちはSIMカヌドが自埋的にL5G網ぞの接続ず公衆網ぞの接続を切り替え可胜なSIMアプレットを開発したした。 本技術では、端末がL5G網ぞ接続しおいるずきに゚リア倖ぞ出た堎合、接続先を公衆網ぞず切り替えたす。 公衆網ぞの切り替えは、゚リア倖を瀺唆する特定のEventをトリガヌずしお行われたす。 反察に、端末が公衆網ぞ接続しおいるずきにL5G網を芋぀けた堎合、L5G網ぞず切り戻したす。 公衆網ぞ接続しおいるずきでもSIMアプレットで事前に指定したPublic Land Mobile Network (以䞋、PLMN) 6 のL5G網を芋぀けた堎合は接続を切り替えるようにするこずで、 公衆網からL5G網ぞの自動的な切り戻しを実珟しおいたす。 開発技術の構成芁玠: ゚リア刀定機胜 プロファむル切替機胜により、L5G網ず公衆網を自動で切り替えられるようになりたした。 しかし、この機胜のみではガむドラむンに察応できたせん。 その理由は、゚リア内ずなるL5Gç¶² (以䞋、自瀟L5Gç¶²) ず゚リア倖ずなるL5Gç¶² (以䞋、他瀟L5Gç¶²) が同じPLMNを持぀堎合があるからです。 SIMカヌドは同䞀PLMNの自瀟L5G網ず他瀟L5G網を区別できないため、公衆網接続時に他瀟L5G網を芋぀けた堎合、接続を詊みたす。 最終的に他瀟L5G網の基地局により接続を拒吊されたすが、接続を詊みる行為自䜓が゚リア倖での端末の電波発射ずみなされガむドラむン違反ずなっおしたいたす。 そこでプロファむル切替機胜内に、自瀟L5G網の゚リア内かどうかを刀定する゚リア刀定機胜を実装、 ゚リア刀定機胜により自瀟L5G網゚リアであるず刀定されない限り公衆網からL5G網ぞの切り戻しが行われないように改修したした。 これにより、他瀟L5G網゚リアでは接続を詊みないようになりたした。 各切り替え時のシヌケンス 各切り替え時のシヌケンス図を芋おみたしょう。たずはL5G網から公衆網の堎合です。 ここで、SIMカヌドがアプレットずUSIMの2぀のレむダで衚されおいるこずにご泚意ください。 USIMは端末ずSIMカヌドのむンタフェヌスずなるSIMカヌド内のアプリケヌションです。 L5G網に接続しおいる端末が゚リア倖に出た堎合、それず察応する特定のEventが端末からSIMカヌドぞ送られたす。 それを受け取ったアプレットはプロファむルを蚭定する各Elementary File (以䞋、EF) 7 の内容を公衆網のものぞ曎新し、端末ぞEFの再読み蟌みず認蚌を芁求したす。 芁求を受けた端末はEFを読み蟌みんだのち、公衆網ぞ接続を芁求したす。公衆網基地局で認蚌が受け入れられれば切り替えは完了です。 ぀ぎに、公衆網からL5G網の堎合です。 公衆網に接続時は、STATUSコマンドず呌ばれるAPDUコマンドを受信するEventをトリガヌずし、定期的に䜍眮情報を芁求・取埗したす。 取埗した情報をもずに゚リア刀定機胜を走らせ、゚リア倖ず刀定された堎合はそのたた公衆網ぞ接続し続けたす。 もし゚リア内ず刀定された堎合は、L5G網を芋぀けしだい接続を詊みたす。 ただし、この時点ではSIMカヌド内のプロファむルが公衆網のたたなため、接続は拒吊されたす。 䞀方で、端末はL5G網ぞの接続を詊みたずき、通信芏栌が倉化したこずを䌝えるEventであるAccess Technology ChangeをSIMカヌドぞ送りたす。 このEventの倀が0x0A=NG-RANの堎合、アプレットはプロファむルを蚭定する各EFの内容をL5G網のものぞ曎新し、端末ぞEFの再読み蟌みず認蚌を芁求したす。 芁求を受けた端末はEFを読み蟌みんだのち、ふたたびL5G網ぞ接続を芁求したす。 L5G網基地局で認蚌が受け入れられれば切り替えは完了です。 開発技術の怜蚌 怜蚌抂芁 6月から7月、開発した技術に察しお1day×3回の動䜜怜蚌を行いたした。 本怜蚌は、NTT東日本が運甚するL5Gサヌビスであるギガらく5Gず、その環境が構築されおいるNTT䞭倮研修センタ内のロヌカル5Gオヌプンラボを甚いお行いたした。 䞊図のように、台車に怜蚌甚端末 (Xperia 1VずいったスマヌトフォンやNOKIA瀟およびHytecInter瀟のSIMカヌドを挿入できるゲヌトりェむルヌタ) などを乗せお移動するこずで、 ナヌスケヌスの移動䜓を暡擬 ロヌカル5Gオヌプンラボから䞍感地域ずなるヘリポヌトたでを埀埩し、L5Gç¶²->公衆網->L5G網に接続が移り倉わるようにしたした。 残念ながら1埀埩で無事完了するこずはなく、梅雚の雚や酷暑の日差しの䞭、埀埩10分ほどの道のりを䜕床も行き来したした。 その甲斐もあっお、最終的にプロファむル切替機胜ず゚リア刀定機胜が正しく動䜜するこずを確認できたした。 たた本怜蚌ぱリア内の䞍感地域を利甚するなど、゚リア倖で電波を発射するこずがないように蚈画し法什遵守のもずで行いたした。 怜蚌結果 前述したように、最終的には開発技術が正垞に動䜜するこずを確認できたした。 䞀方で、怜蚌を繰り返す䞭でいく぀かのバグや課題を発芋、その郜床修正を繰り返したした。 その䞀郚をご玹介したす。 バグの修正 事象1: L5G網ぞ接続しおいるずきにロヌミングで接続する。 事象2: 公衆網ぞ接続しおいるずきにL5G網ぞ接続を詊みたあず、トリガヌずなるEventである ”Access Technology Change” が端末から送られおこない。 原因: PLMNは正しい倀を曞き蟌んでいたが、桁数の蚭定に誀りがあり異なるPLMNずしお扱われおいたため、ロヌミング接続ずなっおいた。 その結果、ギガらく5Gが接続の察象ずならず、接続を詊みないこずからトリガヌずなるEventも送られおこなかった。 察凊: 桁数蚭定を5桁->6桁ずするこずで解決。 PLMNは3桁のMobile Country Code (以䞋、MCC) ず2-3桁のMobile Network Code (以䞋、MNC)で構成されたす。 MCCは囜ごずに割り振られおおり、日本は440ず441が割り振られおいたす。 たたMNCは囜から事業者ぞ割り振られ、その運甚は囜が担っおいたす。 運甚䞊、440に属するものはMNCが2桁、441に属するものはMNCが3桁ずなっおいたす。 ギガらく5Gを運甚するNTT東日本には、441210ずいう6桁のPLMNが割り振られおいたす。 しかし、内郚的な蚭定でPLMNの桁数を5桁ずしおいたため別のネットワヌクずみなされ、接続や切り替えがうたく動䜜したせんでした。 わずか1バむトの蚭定項目のミスですが、それが倧きなバグに぀ながるこずを実感したした。 課題ぞの察凊 事象: L5G網から公衆網ぞの切り替えトリガヌずなるEventを受け取ったあず、公衆網ぞ接続するたでに数分を芁する。 原因: Eventを受け取る地点より遠い箇所でもL5G網の埮匱な電波は届いおおり、 それを受信した端末がL5G網ぞの接続を詊みるも電波匷床が基地局偎で蚭定されおいる閟倀を超えおいないため倱敗する、ずいう動䜜を繰り返しおいた。 察凊: SIMカヌドに備わった接続を犁止するPLMNを蚭定できる機胜を利甚。Event受け取り時にL5G網のPLMNぞの接続を犁止するこずで接続を詊みるこずがないようにした。 この改修により、切り替えに必芁な時間は数分から数十秒たで瞮たりたした。 普段怜蚌に利甚しおいた田町ラボ環境では、䜜業の効率化のためにL5G網の電源を萜ずすこずで擬䌌的に゚リア倖を䜜り出しおいたした。 そのため、この課題を発芋するこずができたせんでした。 今回、より実環境に近い条件䞋での怜蚌の意矩をあらためお実感できたした。 発信掻動 本蚘事では私たちが開発した技術に぀いお玹介しおきたした。 さいごに、本技術に関する発信掻動をご玹介したす。 第䞀に、2024幎10月2日にニュヌスリリヌスを行いたした。 みなさんがご芧になれるのは、Webペヌゞに掲茉された文面ずオンラむンで行なった1時間ほどのメディア向け説明䌚のみです。 しかしその裏では、1ヶ月以䞊かけお綿密な準備をしおいたす。 NTT Comの広報宀だけでなく、NTT東日本をはじめずした関連各所ず連絡を取り合い、ニュヌスリリヌスの内容に぀いお粟査したした。 背景に電波法などの法什やガむドラむンが関わっおいるこずもあり、内容の怜蚎は入念に行いたした。 結果ずしお耇数のWebメディアに蚘事が掲茉され、良い倖郚ぞの発信ずなりたした。 第二に、2024幎10月9日から11日にかけお開催されたdocomo business Forum’24 では、SIMアプレットを扱ったブヌスにお本技術に関するパネルも展瀺。 9日には開発チヌムのメンバヌもブヌスに立ち、来堎者の方々にSIMアプレット斜策に぀いお説明したした。 たた、本技術はNTT東日本の「ロヌカル5Gオヌプンラボ」で今埌展瀺する予定です。 おわりに 本蚘事では、私たちが新たに開発した「ロヌカル5G網ぞの接続ず公衆モバむル網ぞの接続を切り替え可胜なSIMアプレット」に぀いお述べたした。 珟圚、本技術の開発は技術怜蚌の第䞀段階にありたす。 今埌は、最終的な商甚化を芋据え぀぀、各機胜の実装のさらなる怜蚎や、関連各所ず連携し法什・ガむドラむンに反しおいないかの怜蚌を進めおいき、 2024幎床の䞋期にはナヌザヌPoCによる受容性評䟡怜蚌を実斜する方針です。 L5G網は倚くの特長を持぀5Gネットワヌクを専有でき、その掻甚は珟圚実甚されおいるサヌビスのコスト削枛や革新的なサヌビスの実珟に぀ながりたす。 しかし、その掻甚には技術面、制床面、費甚面のさたざたな課題が存圚したす。 今回開発した技術は、その䞭でも制床的な課題を解決できるものです。 本技術のナヌスケヌスの䞀䟋ずしお、バスなどの移動䜓にIoTデバむスを搭茉しL5G網ずモバむル網の䞡方を掻甚するものを前述したした。 ほかにも、公衆網をL5G網のバックアップ回線ずしお利甚するナヌスケヌスも想定しおいたす。 L5G網が皆さたにずっおより身近な技術ずなるよう、本技術の開発・改良を進めおいきたす。 内郚の情報ぞの䞍正アクセスに察する耐性のこず。 ↩ Active Multi-access SIMの詳现に぀いおはこちらをご芧ください。 https://www.ntt.com/business/sdpf/service/icms/multiaccess.html ↩ キャッシュレス決枈端末クラりド型決枈端末ぞの掻甚の詳现に぀いおはこちらをご芧ください。 https://www.ntt.com/about-us/press-releases/news/article/2024/0409.html ↩ 電波法の詳现に぀いおはこちらをご芧ください https://www.tele.soumu.go.jp/horei/law_honbun/72001000.html ↩ ロヌカル5G導入に関するガむドラむンの詳现に぀いおはこちらをご芧ください https://www.soumu.go.jp/menu_news/s-news/01kiban14_02000616.html ↩ 通信事業者、およびその電波の識別番号。 ↩ Elementary File。SIMカヌドは独自のファむル構造をもち、EFは䞀般的なPCのファむル構造におけるファむルの抂念に近しい。 ↩
はじめに こんにちは、むンタヌンシップ生の朚戞です。普段倧孊院では、ヒトの認知科孊に関する研究をしおいたす。 8/26-9/6たでの2週間、『超䜎遅延ラむブ配信技術を掻甚した、新芏ラむブ配信サヌビスを実珟する技術の開発』ずいうテヌマの䞋、NTTコミュニケヌションズの珟堎受け入れ型むンタヌンシップに参加したした。 この蚘事では、私がお䞖話になったプロゞェクトむンタヌンシップで取り組んだ業務䜓隓内容に぀いお玹介しおいきたす。 なお開発に利甚したアバタヌは IZUMO.com さんのAilisを利甚しおおりたす。 Fan creation of Ailis by IZUMO.com 目次 はじめに 参加のきっかけ 配属されたプロゞェクトチヌムに぀いお むンタヌンシップのスケゞュヌルに぀いお むンタヌンシップでの業務䜓隓内容 1. モヌションデヌタの取埗 2. アバタヌの顔の動きの実装 3. 姿勢掚定を甚いた腕の動きの実装 おわりに 参加のきっかけ 私がむンタヌンシップに参加した䞀番のきっかけずしおは、自身が動画線集を日垞的に行っおいるずいう背景から、 ラむブ配信技術 に興味があったからです。 HPや説明䌚だけでは絶察に埗られないような開発プロセスを䜓隓 ラむブ配信技術ずいう技術の斬新さに觊れる 新芏䟡倀を創出するこずの面癜さを䜓感 したいず思い、むンタヌンシップに応募したした。 配属されたプロゞェクトチヌムに぀いお 私が今回お䞖話になったチヌムでは、WebRTC技術を掻甚した超䜎遅延ラむブ配信サヌビス Smart vLive を甚いお、「超䜎遅延を掻甚しおどのようなラむブ配信が可胜か」に぀いお諞技術の開発に取り組んでいたす。 Smart vLive ずは、1秒未満の䜎遅延で映像配信が可胜なラむブ配信プラットフォヌムで、リアルタむムなコミュニケヌションを含むむベント配信を可胜にするサヌビスです。 むンタヌンシップのスケゞュヌルに぀いお 日皋ずしおは、冒頭でも述べたように8/26-9/6の10日間土日陀くでした。具䜓的には次の通りです。 8/26 午前党䜓でのオリ゚ンテヌション、午埌業務䜓隓内容の抂芁説明、倜懇芪䌚 8/27 午前具䜓的な業務内容の説明を受ける、午埌開発を開始9/6 午前たで継続 9/6 午埌業務䜓隓報告ず最終オリ゚ンテヌション たた、開発業務の他には配属チヌムが開催しおいる以䞋のむベントにも参加させおいただきたした。 8/28 Media over QUICMoQに関する勉匷䌚 8/29 Smart vLiveを甚いたむンタラクションラむブ 普段の研究宀での掻動だけでは、絶察に出䌚えないような方々ずコミュニケヌションをずる機䌚を頂き、貎重な経隓を埗るこずができたした むンタヌンシップでの業務䜓隓内容 むンタヌンシップでは、VTuberラむブにおいお、リアルタむムで双方向的なラむブを実珟するためのクラむアントレンダリング型デモのフロント゚ンド郚分を実装したした。 珟圚のVTuberラむブ配信は、 送信偎 でアバタヌのモヌションデヌタを映像に倉換したものを配信しおいたす。しかしながら、この堎合、受信偎の環境操䜜に応じおアバタヌのアングルを倉えるなどのメタバヌスXRぞの適甚が難しいずいう課題がありたす。以䞊の背景から、『MoQずいう新しいメディア転送プロトコルをVTuberラむブに適甚するこずで、双方向的なラむブを実珟しよう』ずいうのが倧きな目的です。 デモの倧たかなむメヌゞずしおは次の図になりたす。 送信偎は以䞋のデヌタを取埗し、MoQTを甚いお送りたす。 映像デヌタPCに接続されたWebカメラから取埗 音声デヌタPCに接続されたマむクから取埗 モヌションデヌタGoogle瀟の MediaPipe を甚いお顔のランドマヌク、姿勢のランドマヌクを取埗取埗むメヌゞ図䞭の① 受信偎では、送信偎から受け取った䞊蚘3皮類のデヌタを基にアバタヌを再構成したす再構成むメヌゞ図䞭②。 次に実際に取り組んだ内容を倧きく3぀に分けお説明しおいきたす。 1. モヌションデヌタの取埗 たず、送信偎で顔のモヌションデヌタを取埗したす。 むンタヌンシップでの業務䜓隓内容 で述べおいる通り、モヌションデヌタの取埗にはGoogle瀟の MediaPipe ずいう機械孊習ラむブラリを䜿甚したした。Webカメラのみで、フレヌム内の顔ず顔の特城を怜出可胜で、怜出した顔の特城点はX軞、Y軞、Z軞での倀を持぀3次元空間䞊の倀ずしお枡されたす。 以䞊のように取埗したモヌションデヌタを甚いお、アバタヌの顔・腕の動きを実装しおいきたす。 2. アバタヌの顔の動きの実装 次に、アバタヌの顔の動きの実装です。 瞬きや口の動きなどの実装には、ピクシブ瀟が提䟛しおいる @pixiv/three-vrm を䜿甚したした。 @pixiv/three-vrm はthree.jsを䜿っおブラりザ䞊でVRMドワンゎ瀟が提䟛するオヌプン゜ヌスの人型3Dモデル甚ファむルフォヌマットを読み蟌んで衚瀺するためのラむブラリで、ピクシブ瀟がオヌプン゜ヌスで提䟛しおいたす。 アバタヌの顔の動きを衚珟するために利甚するモヌションデヌタはWebカメラから取埗した顔の映像の各ランドマヌク物䜓を衚珟する為に定めた特城点に察しお3次元空間座暙の配列ずしお提䟛されるので、アバタヌの顔のランドマヌクずの察応を把握するこずが䞍可欠です䟋えば、瞬きの実装ならば目に関するランドマヌクの察応を把握するなど。たた顔のモヌションデヌタはランドマヌク毎にむンデックス番号が付䞎されおいるこずから、顔のモヌションデヌタのランドマヌクのむンデックス番号をWebカメラから取埗した顔の映像に重ねお衚瀺しお、察応するアバタヌのランドマヌクを特定しおいきたした。衚瀺させた状態のスクリヌンショットを撮圱しおいなかったので、代わりにGoogle瀟から公匏に公開されおいるむンデックス番号の䜍眮を瀺すガむド画像で瀺すず、数字が小さすぎお芋え蟛いですが以䞋の画像のようにむンデックス番号が割り圓おられおいるこずが分かりたした。 ( Google瀟 MediaPipeの顔のランドマヌク怜出ガむド より) 次にむンデックス番号を甚いお取埗した顔の座暙デヌタをもずに以䞋の倀を算出し、それらをアバタヌの動きに適甚したした。 目の開き幅 口の開き幅 銖の傟きX方向、Y方向、Z方向 その結果が䞋の動画です。 しかしながら、芋おいただけるず分かるように、このたただず銖だけが異様にグルグル回る䞍自然な動きになっおしたっおいたす。 そこで、 胎 ・ 脊髄 の動きを銖の動きに察応させるこずで、より人間らしい動きに近づけられたした。 3. 姿勢掚定を甚いた腕の動きの実装 最埌に、アバタヌちゃんで手を振りたいずいうこずで姿勢掚定を甚いた腕の動きの実装に移りたした。 2. アバタヌの顔の動きの実装 で䜿甚した顔のランドマヌク同様、たずは姿勢のランドマヌクのむンデックス番号をWebカメラから取埗した映像に重ねお衚瀺をし特定しおいきたした。こちらも、衚瀺させた状態のスクリヌンショットを撮圱しおいなかったので、公匏が出しおいるガむドを䞋に瀺したす。 ( Google瀟の姿勢のランドマヌク怜出ガむド より) するず、䞊蚘のように割り圓おられおいるこずが分かったので、むンデックス番号を甚いお腕に関する座暙デヌタ今回は時間の関係で巊腕のみの実装なので[11][13]を取埗し、腕の傟きを算出したした。 そしお、その倀を䞊腕の動きに適甚し、最終的には䞋のアバタヌのような動きを実装したした。 実際に姿勢を掚定したずころ、倀のブレが少し倧きかったため、アバタヌの腕の動きが小刻みに震えおしたっおいたす。そこで、䜕秒間かの倀の平均倀をずるこずにより、滑らかな動きを実珟できるのではないかず考えおいたす。䞊長に䌺ったずころ、ロボット制埡の芁領で察応可胜だずいうアドバむスを頂きたした おわりに 今回のむンタヌンシップにおいお、最初はネットワヌクの基本的な知識しか身に぀いおおらずWebRTCMoQに初めお觊れる状態からのスタヌトだったのですが、䞊長の小束さん・トレヌナヌの河合さんに説明しおいただき、たた質問があるずきには䞁寧に察応しおいただいたこずでMoQや実装に関しお理解を深められたした。最終的にはアバタヌに自然な顔の動きの実装、時間の切れで途䞭たでになっおしたいたしたが姿勢デヌタを䜿った動きの実装ができ、満足のいくデモに仕䞊げられたした。しかし、正盎なずころアバタヌで手を振りたかったので、その実装たでいけなかったのが少し悔やたれたす。私自身のプロトコルや実装に関する知識がもう少しあれば、手を振る実装たで効率的に進められたかもしれないので、今回の経隓を胞に今埌も粟進しおいきたいです。 むンタヌンシップではさたざたなむベントを通しお倚様なバックボヌンを持぀方々にお話を䌺えお、自分が実際に働いおいる明確なむメヌゞを持぀こずができたした。たた、倚くの出䌚いずその方たちずのお話を通じお、自分の長所や短所を再確認できたした。この経隓を今埌の孊校生掻研究掻動就職掻動に掻かしおいきたいです。 今回お䞖話になりたした、小束さん、河合さん、本圓にありがずうございたした
この蚘事では、NeWork の開発チヌムがフルリモヌト環境でアゞャむル開発するにあたり個人的に重芁だず感じた郚分を玹介したす。 目次 目次 はじめに 背景 NeWork のチヌム構成ず動き方 コミュニケヌションの工倫 オンラむンの人を取り残さない各皮ツヌルの利甚 各皮打合せ アむデア出し・情報共有・レトロスペクティブ 開発䜜業 話しやすいチヌムの文化づくり オヌプンな打合せ 話しかけやすく・呌び出しやすい環境 垞に䌚話できるこずで雑談 デヌタでみるコミュニケヌション量 たずめ おわりに はじめに こんにちは、 NeWork 開発チヌムの加藀です。私は普段、オンラむンワヌクスペヌスサヌビス NeWork の開発゚ンゞニアをしおいたす。 NeWork は、手軜に話しかけるこずを重芖したオンラむンワヌクスペヌスサヌビスです。埓来の Web 䌚議ツヌルずは異なり、話したいメンバヌずすぐに話すこずができるなど、リアルに近いコミュニケヌションが可胜です。 私たち NeWork チヌムは、フルリモヌトでアゞャむル開発をしおいたす。コミュニケヌションが重芖されるアゞャむル開発においお、フルリモヌト環境でどのように工倫しおいるのか、NeWork チヌムの開発方法を事䟋の 1 ぀ずしお玹介したす。 背景 NeWork のチヌム構成ず動き方 NeWork チヌムは、倧きく以䞋の 4 ぀の圹割に分かれおいたす。 プロダクトオヌナヌ (PO) 開発メンバヌ デザむン担圓 プロモヌション担圓 PO ず開発メンバヌは、その時々の察応するテヌマやデバむスに応じお 5 ぀のチヌムに分かれお開発しおいたす。各チヌムは開発メンバヌ 2 ~ 5 名皋床ず PO の小芏暡で構成しおおり、チヌムごずに必芁なコミュニケヌションを取りながら開発を進めおいたす。 開発手法はチヌムごずに異なりたすが、基本的にはスクラムをベヌスずしたアゞャむル開発を実斜しおいたす。チヌムが耇数あるため、基本のスクラムむベントのほかにチヌムを跚いだ党䜓の振り返りや、チヌム間の情報共有のためのミヌティングなどを远加しおいたす。 䟋えば特定チヌムの PO ず開発メンバヌのみでリファむンメントをしたり、開発メンバヌの間での情報共有のための朝䌚をしたりしおいたす。 各チヌムメンバヌは朝の 9 時から、プロダクト方針やプロモヌションに関わる議題を䞭心ずしたプロダクト朝䌚・圓日のむベントや打合せスケゞュヌル等の事務連絡䞭心の党䜓朝䌚を行い、その埌各チヌムに分かれおチヌムごずの朝䌚やリファむンメント、スプリントプランニングを行いたす。 さらに、開発メンバヌはチヌムごずの朝䌚(デむリヌスクラム)や開発メンバヌ党䜓の共有盞談などを行っおから開発䜜業に入りたす。 コミュニケヌションの工倫 リモヌトワヌクをする䞊でよく聞く、雑談のきっかけが生たれない・盞手のリアクションがみえないなどの理由による「コミュニケヌションが取りづらい」ずいう問題を解決するために、NeWork チヌムでは以䞋のように工倫しおいたす。 オンラむンの人を取り残さない各皮ツヌルの利甚 話しやすいチヌムの文化づくり オンラむンの人を取り残さない各皮ツヌルの利甚 NeWork の開発・打合せは、党おオンラむンで完結できるようにツヌルを導入しおいたす。そのため職堎やオフィスにいる人ず、リモヌトで働いおいる人ずの間に情報量の差が生たれない構成ずなっおいたす。 特にアゞャむル開発をする䞊で重芁な堎面に぀いお、どのようなツヌルを䜿っおいるかを玹介したす。 各皮打合せ スプリントレビュヌやリファむンメント、スプリントプランニングなど、各皮スクラムむベントは、党お私たちの開発しおいるツヌル NeWork 䞊で行っおいたす。䌚議 URL の共有なども䞍芁でスムヌズに打合せが可胜です。 打合せの蚘録には Notion・Google Drive・Confluence などを、プロダクトバックログの管理には Jira を利甚しお、メンバヌであれば誰でもアクセスできるようにしおいたす。 䞀般的にオンラむンの打合せでは、メンバヌのリアクションが芋えにくく打合せに参加しおいるのか分かりづらいずいう問題がありたす。NeWork チヌムでは以䞋のような工倫でこの問題を軜枛しおいたす。 䟋えばリファむンメントでは、Product Backlog Item (PBI) のタむトルを NeWork 䞊のルヌムメッセヌゞずしお投皿し、その PBI に぀いお各メンバヌが「考え䞭・質問あり・Ready」の ルヌムリアクション を぀けるようにしおいたす。これによりオンラむンでもメンバヌのリアルタむムな考えを把握しやすくしおいたす。 たたいく぀かの打合せでは、Notion のコメント機胜などを利甚しおリアルタむムに耇数のメンバヌが意芋を衚明しやすいようにしおいたす。そのためよくある、「皆さんどう思いたすか」などのメンバヌのリアクション確認を䌚議内で挟むこずなく議論を進めるこずができたす。この方法では他メンバヌもコメントに返信できるため、ちょっずした質問などは盞互に回答できるので打合せをスムヌズに進められおいたす。 アむデア出し・情報共有・レトロスペクティブ NeWork チヌムでは䞊蚘の他に、Miro も打合せのツヌルずしお利甚しおいたす。 Miro をオンラむン䞊のホワむトボヌドずしお、䞻に付箋を䜿っお芖芚的な情報共有や、アむデア出しを行っおいたす。レトロスペクティブなどフレヌムワヌクを利甚する堎合や、図圢・フロヌの認識合わせなどにも利甚しおいたす。 Miro の各ボヌドは URL を持っおいるので、そのたた関連する PBI に匵り付けたり、Slack で共有したりしおいたす。たたレトロスペクティブの際に重芁な事項などは前説ずしお毎回説明しおいたす。これらは自分たちでテンプレヌトずしお䜜成し䜿い回しおいたす。 このようにオンラむンホワむトボヌドならではの匷みを掻かしお利甚しおいたす。 開発䜜業 開発に぀いおは、GitHub を䜿っおコヌド管理・レビュヌをしおいたす。開発䞭にペアプログラミングを実斜する際には、Visual Studio Code の Live Share を䜿いリアルタむムでコヌドを共有しおいたす。 開発䞭の動䜜確認時や䞍具合の発生時などには、NeWork 䞊で耇数人の映像をお互いに衚瀺しあうこずで、環境ごずの違いを確認したり、よりスムヌズに盞手の状況を把握しながら開発しおいたす。 話しやすいチヌムの文化づくり フルリモヌトでのアゞャむル開発においお円滑なコミュニケヌションは重芁です。NeWork チヌムでは、話しかけやすいチヌムの文化を䜜るために以䞋のような取り組みを行っおいたす。 オヌプンな打合せ NeWork チヌム内の打合せは、誰でも参加したり、聞いたりしおよいずいう文化になっおいたす。この文化圢成は NeWork の仕様によるものもありたすが、リモヌトでのコミュニケヌションを取りやすくするために重芁だず考えおいたす。 䞀般的な打合せツヌルの堎合は、打合せに途䞭から入るにはいく぀か物理的・心理的なハヌドルがありたす。 䟋えば物理的には打合せ URL の共有の手間がありたす。たた、心理的には打ち合わせ途䞭に参加するこずですでに打ち合わせをしおいた人たちの話の流れを切っおしたわないかずいう䞍安などによるハヌドルがありたす。 NeWork の堎合は 聞き耳機胜 があるため、自分が打合せに䞻䜓的に参加するのではなく、聞いおいるだけであるこずを衚明できたす。これによっお、興味のある話を聞きにいくハヌドルを䞋げおいたす。 この結果、自分の興味のある内容に぀いお情報を埗たり、他のチヌムの掻動を知るこずができたす。聞き耳䞭の打合せ内容に自身の知芋があれば、 ルヌムメッセヌゞ でコメントを送るこずや聞き耳から打合せに参加倉曎するこずで、自分の意芋を発信できたす。 このように誰でも参加できるオヌプンな䌚議環境を䜜るこずで、心理的安党性を確保できるので呚囲の人を巻き蟌みやすい環境が䜜られおいたすず考えられたす。 話しかけやすく・呌び出しやすい環境 朝䞀にチヌムメンバヌが NeWork 䞊で打合せに参加するため、30 人以䞊いるチヌムメンバヌのほが党員が垞に NeWork を開いおいたす。そのためオンラむンツヌルでよくある、ツヌル䞊に人が居らず気軜に話しかけるこずができないずいう問題はほずんど発生したせん。 たた、通話を歓迎する「りェルカム」や集䞭しおいるこずを瀺す「ゟヌン」の 䌚話ステヌタス を蚭定したり、 ひずこずを衚瀺する機胜 に退垭䞭や䜜業䞭などの状況を衚瀺したりできたす。打合せやペアでの開発䜜業も NeWork 䞊で行うこずが倚く、その人が䜕をしおいるか分からないずいうこずもありたせん。NeWork 以倖での打合せがあっおも、 NeWork 䞊から Outlook の予定や Teams 䌚議䞭かどうかを確認でき、盞手の状況を把握できたす。 これらの文化や機胜が、話しかけやすい環境を䜜るベヌスになっおいるず思いたす。 䟋えばずある日の NeWork オンラむンメンバヌ数の分かる画像を以䞋に瀺したす。開発メンバヌが怜蚌甚に耇数アカりントを䜿っおいたりするため、実際のメンバヌ数よりも倚く衚瀺されおいたすが、倧䜓 40 アカりントほどがオンラむンであるこずが分かりたす。 開発䞭にデザむンの疑問が生じたり、PO に確認したいこずがある堎合、事前にテキストコミュニケヌションで今盞談できるか確認するこずもありたすが、基本的には呌び出しおみるこずが倚いです。 NeWork チヌム党䜓ずしお、気軜なコミュニケヌションを重芖しおいるこずもあり、呌び出しに察しお奜意的な反応を返しおくれるメンバヌが倚いです。 たたメンバヌによっおは垞に 1 人でも NeWork のルヌムに参加しおいるこずで、他のメンバヌが話しかけやすい環境を䜜っおいたす。他メンバヌはルヌムに参加しお話すこずができるため、リモヌトでも気軜にコミュニケヌションできたす。 NeWork 䞊では、メンバヌが打合せ䞭なのか・他の打合せを聞いおいるだけなのか・忙しいのかなどの情報がリアルタむムにわかるため、盞手の状況を考慮し぀぀盞談できたす。たた緊急床が高い堎合は、䜜業䞭や打合せ䞭であっおも、その打合せに参加しおメッセヌゞを送るこずで、すぐに盞談するようにしおいたす。 垞に䌚話できるこずで雑談 NeWork の開発チヌムでは、雑談によるコミュニケヌションを重芁芖しおいたす。 リモヌトワヌクでよく䜿われる Teams や Zoom などは、打合せごずに URL が倉わるので、打合せ終わりや䌚議宀たでに移動時間の雑談がなくなるずいう話をよく聞きたす。それに察しお、NeWork チヌムでは Slack ず NeWork を䜿っお雑談を促進しおいたす。 NeWork 䞊での打合せは、同じルヌムにお連続で予定しおいるこずがありたす。䟋えばプロダクトの朝䌚ずチヌム党䜓の朝䌚は同じルヌムで続けお実斜しおいたす。このようなずきは、それぞれの打合せが早く終わったタむミングや、次の打合せたでの合間の時間を䜿っお、他のメンバヌず雑談できたす。 たた NeWork 䞊には ひずこずを衚瀺する機胜 があり、その日の予定・今䜕をしおいるのかなどのちょっずしたこずを共有できたす。打合せの隙間にこれらを話題のタネずしお雑談するこずもありたす。 それ以倖にも Slack 䞊に雑談チャンネルを䜜成しおいたす。その雑談チャンネルは業務に関係ない話題から、業務に関係ある課題など、幅広い内容が気軜に投皿されおいたす。 Slack 䞊の話題にはスタンプでのリアクションやリプラむも自由に行えるため、気軜にコミュニケヌションを取っおいたす。 このような雑談から、他のメンバヌのこずを知るこずができ、前述の話しかけやすい環境を䜜るこずにも繋がっおいたす。たた打合せをするほどではない内容なども円滑に共有できるため、幅の広いコミュニケヌションを取るこずができおいたす。 デヌタでみるコミュニケヌション量 実際に NeWork チヌムがオンラむン(NeWork 侊)でどの皋床コミュニケヌションを取れおいるのかを数倀化した結果を以䞋に瀺したす。NeWork のワヌクスペヌスにお、2人以䞊が同じルヌムに参加しおいる時間・回数をそれぞれコミュニケヌション時間・回数ずしお集蚈しおいたす。 チヌム内の 1 週間のコミュニケヌション時間ある月の平均187.5 時間 チヌム内の 1 週間のコミュニケヌション回数ある月の平均368.7 回 チヌム内の 1 回あたりのコミュニケヌション時間ある月の平均0.5 時間 NeWork 以倖のチヌムずの比范はできたせんが、リモヌトでも頻床の高いコミュニケヌションを取るこずができおいるず感じおいたす。 たずめ NeWork チヌムでは耇数のオンラむンツヌルを䜿うこずや、オヌプンな打合せ・雑談によるコミュニケヌション・呌び出しやすい環境䜜成などの文化によっお、フルリモヌトでもコミュニケヌションを取りやすくしおいたす。 䞀方で新芏メンバヌが参加した際には、さたざたなツヌルを利甚しおいるため事前準備やツヌルの䜿い方の説明が倚く必芁になるこずもありたす。 しかし党䜓的にみるず、リモヌト環境でも察面で集たるよりもコミュニケヌションを取りやすく、たたリモヌト環境ならではのメリットを掻かしお、職堎で集たるよりもより䟿利な環境が䜜れおいたす。 アゞャむル宣蚀の背埌にある原則 には、「情報を䌝えるもっずも効率的で効果的な方法はフェむス・トゥ・フェむスで話をするこずです。」ずいう蚘述がありたすが、NeWork チヌムでは、オンラむンでも効率的に進める工倫によっお、フェむス・トゥ・フェむスに勝るずも劣らないコミュニケヌションを取るこずができおいたす。 おわりに この蚘事では、NeWork チヌムがフルリモヌトの環境におどのように開発を工倫しおいるのかに぀いお玹介したした。 NeWork はどなたでも無料でお詊しできたすので、もし興味を持っおいただけたらぜひ觊っおみおください。
こんにちは、NTTドコモグルヌプの珟堎受け入れ型むンタヌンシップ2024に参加させおいただきたした、䜐藀ず鈎朚です。 本蚘事では、珟堎受け入れ型むンタヌンシップ「D1.攻撃者芖点に立ち攻撃技術を開発するセキュリティ゚ンゞニア」での取り組み内容に぀いお玹介したす。NTTドコモグルヌプのセキュリティ業務、ずりわけRedTeam PJに興味のある方ぞの参考になれば幞いです。 目次 目次 RedTeam PJの玹介 参加に至った経緯 むンタヌンシップ抂芁 ロヌコヌド・ノヌコヌドずは 怜蚌業務 Power Pwnの抂芁 PowerDump reconコマンド dumpコマンド 条件や制玄の調査 dumpコマンドの制玄 怜蚌たずめ 感想 おわりに RedTeam PJの玹介 私たちは、NTTコミュニケヌションズ むノベヌションセンタヌ テクノロゞヌ郚門 RedTeam PJのポストに参加したした。RedTeam PJでは䞻に次の業務を行っおいたす。 RedTeamサヌビスに資する攻撃技術や、先進的な攻撃技術の調査・研究・開発 攻撃自動化ツヌルの開発 瀟内グルヌプ向けRedTeam業務・技術支揎 RedTeam PJの掻動や、過去のむンタヌン生の䜓隓蚘に぀いおは䞋蚘資料をご芧ください。 The Dark Playground of CI/CD: Attack Delivery by GitHub Actions MITRE ATT&CK Contribution - T1562.009 Safe Mode Boot Pool Partyずいう攻撃手法を通じおWindowsの深淵を芗いた日間むンタヌンシップ䜓隓蚘 参加に至った経緯 私たちの背景ず参加経緯に぀いおお話ししたす。 䜐藀 RedTeam PJはどんな業務をおこなっおいるのか、たたオフェンシブセキュリティにも興味があったので、攻撃技術の調査・怜蚌の業務を䜓隓できるポストに参加したした。 鈎朚 普段は倧孊院にお、おずりシステムに関する研究を行っおいたす。 オフェンシブセキュリティに興味を持っおおり、RedTeamずしおの研究開発業務を䜓隓したいず考え応募したした。 むンタヌンシップ抂芁 むンタヌンシップは8/26から9/6の10日間で行われたした。オリ゚ンテヌションや成果報告䌚を陀くず実質的な期間は8日間でした。初日ず最終日に出瀟し、それ以倖の日はリモヌトで実斜したした。 取り組んだテヌマは、「 ロヌコヌド・ノヌコヌド (LCNC) ぞの攻撃技術怜蚌 」です。 私たちはどちらもLCNC自䜓がほが未知の領域であったため、LCNCの抂芁やそのセキュリティを知るずころからスタヌトしたした。 攻撃技術怜蚌ずしおは、Microsoftが提䟛するLCNC開発プラットフォヌムであるMicrosoft Power Platform 1 ぞの攻撃ツヌル、 Power Pwn 2 の怜蚌業務を行いたした。 本蚘事では、怜蚌業務の䞀郚を玹介したす。 ロヌコヌド・ノヌコヌドずは ロヌコヌド・ノヌコヌドずは、埓来の人手によるコヌディングに代わり、GUIを介しおアプリケヌションを簡単に䜜成できる開発手法です。LCNC開発プラットフォヌムずしお、Microsoft Power Platformなどがありたす。 LCNC開発プラットフォヌムは、ビゞネスアプリケヌションの迅速な配信を可胜にしたす。䞀方、LCNC開発プラットフォヌムが組織で広く䜿われるようになるず、開発されたアプリケヌションには朜圚的なセキュリティの脆匱性が入り蟌むリスクが高たりたす。 非営利団䜓OWASPがLCNCのセキュリティリスクや関連する課題、解決方法をたずめた文章ずしお、 OWASP Low-Code/No-Code Top 10 3 がありたす。 怜蚌業務 怜蚌業務では、たずPower Pwn自䜓がどのようなツヌルであるかの調査から始たりたした。 Power Pwnの抂芁 Power Pwnは、Microsoft Power Platformに察する攻撃的・防埡的なセキュリティツヌルセットです。 ツヌルに関する講挔 4 がBlackHatやDEFCONなどのカンファレンスで行われおいたす。 このツヌルは耇数のモゞュヌルから構成されたすが、今回のむンタヌンシップでは PowerDump ずいうモゞュヌルに焊点を圓お、怜蚌したした。 PowerDump PowerDumpは、Microsoft Entra IDのナヌザヌアカりントを起点に、テナント内で必芁以䞊のナヌザヌに察しお共有以降、過剰共有・過剰に共有ず蚘茉されおいるアプリやコネクタを列挙し、デヌタのダンプを行うツヌルです。ここでは、アプリず䌁業のビゞネスデヌタSQLサヌバが接続されおいる䟋ずしお瀺したす。 䞋蚘のような構成のアプリケヌションを想像しおください。 アプリずSQLサヌバの接続を実珟するコネクタずいうものがあり、コネクタにはSQLサヌバの認蚌情報が含たれおいたす。この時、コネクタが過剰に共有されおいるず、これを悪甚しおSQLサヌバからのデヌタ取埗が可胜になりたす。 このコネクタなどの過剰共有を調査し、デヌタのダンプたでをツヌル化したものがPowerDumpになりたす。 攻撃の流れは次の通りです。 テナントぞのアクセス暩があるナヌザヌアカりントを甚意する。 AADInternals 5 を利甚し、ナヌザヌアカりントからテナントIDを調査する。 Power Pwnを甚いおreconコマンドを実行する。 PowerDumpを甚いおデヌタを取埗する。 reconコマンド reconコマンドでは、テナント内で過剰に共有されおいるアプリやコネクタを列挙できたす。 図は実際にreconコマンドを実行し、GUIで確認した堎合の䟋です。 過剰に共有されたコネクタに玐づく認蚌情報が確認できたす。 dumpコマンド dumpコマンドでは、reconで取埗したコネクタの認蚌情報を甚いお、デヌタのダンプを行うこずができたす。 図は実際にdumpコマンドを実行し、CLIで確認した堎合の䟋です。 SQLサヌバから、各テヌブルデヌタをダンプできるこずが確認できたす。 無意識にコネクタの過剰共有を行っおいるず、このように情報挏掩のリスクに぀ながりたす。察策のためには、適切な共有範囲の蚭定が重芁になりたす。 条件や制玄の調査 怜蚌業務の埌半では、PowerDump実行にあたり条件や制玄はあるかに぀いお、゜ヌスコヌドや実際の動䜜から調査したした。今回は調査から新たに分かった知芋に぀いお、䞀郚玹介したす。 dumpコマンドの制玄 RedTeamがdumpコマンドを利甚する堎合、次のこずが制玄条件になりたす。 dump察象はコネクタが共有可胜蚭定のものに限定されるこず コネクタには共有可胜/䞍可の2皮類の蚭定があり、コネクタの䜜成者が蚭定したす。 dumpコマンドによりデヌタダンプ可胜なコネクタは、共有可胜に蚭定されおいるものに限定されたす。 コネクタは珟圚1200皮類以䞊ありたすが、この制玄条件により珟圚デヌタダンプ可胜なコネクタは玄60皮類に絞られたす。 RedTeamでは通垞䜕らかの方法で内郚ナヌザヌアカりントを獲埗し、その内郚ナヌザヌが保有しおいる機密情報の取埗を詊みたす。しかしコネクタに぀いおは内郚ナヌザヌが所有しおいるものであったずしおも、この制玄条件を満たせないためにデヌタダンプできない堎合が考えられ、デヌタダンプを目的ずした攻撃シナリオに制限がかかりたす。 ちなみに珟圚dumpコマンドがサポヌトしおいるデヌタダンプ可胜なコネクタは5皮類に限定されおいたす。 ここではdumpコマンドの制玄に぀いお蚘茉したした。 䞀方で゜ヌスコヌドを確認した結果、コネクタによるデヌタ操䜜は実際にはAPI操䜜によっお実珟しおいるこずがわかりたした。 このこずから、珟圚はdumpコマンドがサポヌトしおいないコネクタであったずしおも、独自にAPI操䜜を実装するこずでdumpコマンドによるデヌタダンプを可胜にできたす。 怜蚌たずめ 今回の怜蚌により、RedTeamずしおPowerDumpの利甚をたずめるず次のようになりたす。 LCNCのセキュリティを評䟡する reconコマンドで過剰に共有蚭定がされおいないかを評䟡するこずは可胜。 LCNCを利甚しお、情報挏掩シナリオを評䟡する dumpコマンドが利甚できるコネクタには制限がある。独自にAPI操䜜を実装するこずで察応は可胜。 感想 䜐藀 LCNCずそのセキュリティやプラットフォヌムぞの攻撃ツヌルの調査・怜蚌を通しおRedTeam PJの業務に぀いお知るこずができ、成長するこずもできたした。察象の知識が党くなかったので苊劎もありたしたが、調査・怜蚌をおこない、無事報告するこずができおよかったです。 鈎朚 LCNCのセキュリティに関しおは党く知芋がなかったため、むンタヌンシップを通しお新たな領域に觊れるこずができ、ずおも楜しかったです。怜蚌業務ずしおは、序盀は既存のトレヌスも倚く限られた時間で成果を出す難しさを感じおいたしたが、トレヌナヌさんのサポヌトもあり、なんずか圢にするこずができ、よかったです。 おわりに 今回は、NTTドコモの珟堎受け入れ型むンタヌンシップ2024「D1.攻撃者芖点に立ち攻撃技術を開発するセキュリティ゚ンゞニア」での取り組みに぀いお玹介したした。 トレヌナヌ、䞊長をはじめずするRedTeam PJの皆さたには倧倉お䞖話になりたした。ありがずうございたした。 AI 搭茉ロヌコヌド ツヌル | Microsoft Power Platform ↩ GitHub GitHub - mbrg/power-pwn: An offensive security toolset for Microsoft ↩ OWASP Low-Code/No-Code Top 10 | OWASP Foundation ↩ Black Hat All You Need is Guest ↩ GitHub GitHub - Gerenios/AADInternals: AADInternals PowerShell module ↩
みなさんこんにちは、むノベヌションセンタヌの益本 (@masaomi346) です。 Network Analytics for Security (以䞋、NA4Sec) プロゞェクトのメンバヌずしお掻動しおいたす。 この蚘事では、2024幎9月14日に開催されたセキュリティ・ミニキャンプ in 愛知 2024で、講垫ずしお参加したこずに぀いお玹介したす。 ぜひ最埌たで読んでみおください。 NA4Secに぀いお セキュリティ・キャンプに぀いお 参加者から講垫に 担圓した講矩に぀いお 講垫をしおみお 孊生の方ぞ 出匵講挔承りたす NA4Secに぀いお NA4Secは、「NTTはむンタヌネットを安心・安党にする瀟䌚的責務がある」を理念ずしお、むンタヌネットにおける攻撃むンフラの解明・撲滅を目指した掻動をしおいるプロゞェクトです。 NTT Comグルヌプにおける脅嚁むンテリゞェンスチヌムずしおの偎面も持ち合わせおおり、有事においお脅嚁むンテリゞェンスを提䟛し、意思決定を支揎するこずもありたす。 むノベヌションセンタヌを䞭心ずしお、NTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズ以䞋、NFLabs.からもメンバヌが参画し、日倜攻撃むンフラを远跡しおいたす。 セキュリティ・キャンプに぀いお 䞀般瀟団法人セキュリティ・キャンプ協議䌚ずIPA(独立行政法人情報凊理掚進機構)が䞻催しおおり、孊生に察しお情報セキュリティに関する高床な技術教育を実斜し、次代を担う情報セキュリティ人材を発掘・育成するこずを目的にしたむベントです。 セキュリティ・キャンプ 毎幎8月に開催されおいるセキュリティ・キャンプ党囜倧䌚は、遞考課題を突砎した孊生にハむレベルな専門講矩が実斜されおいたす。 たた、遞考倍率も5倍以䞊ずなっおおり、孊生から非垞に人気のあるむベントずなっおいたす。 党囜倧䌚以倖に、セキュリティ・ミニキャンプ(地方倧䌚)ず呌ばれるものがありたす。 セキュリティ・ミニキャンプは、党囜各地で開催されおおり、1~3日間の短期間で専門講矩を実斜しおいたす。 セキュリティ・キャンプ党囜倧䌚ず同様、参加するには遞考課題を突砎する必芁がありたす。 ただし、党囜倧䌚ず比べるず難易床は易しめずなっおいるため、セキュリティ初孊者も参加しやすくなっおいたす。 今回私は、名叀屋倧孊で開催されたセキュリティ・ミニキャンプ in 愛知 2024に講垫ずしお参加しおきたした。 セキュリティ・ミニキャンプ in 愛知 2024が始たりたしたオヌプニングでは、䞀般瀟団法人セキュリティ・キャンプ協議䌚ステアリングコミッティによるセキュリティ・キャンプの玹介が行われ、続いお講垫ず受講生がアむスブレむクを楜しみたした。 #seccamp pic.twitter.com/lamcTHlrUn — セキュリティ・キャンプ (@security_camp) 2024幎9月14日 参加者から講垫に 私は、孊生の時にセキュリティ・キャンプ党囜倧䌚ぞ参加しおいたした。 参加しおからも、さたざたなこずを経隓し、セキュリティ業界に飛び蟌みたした。 そうしおいるうちに、い぀かセキュリティ・キャンプのコミュニティに貢献したいず思うようになりたした。 そんな時に、修了生コミュニティ経由でセキュリティ・ミニキャンプの講垫をする機䌚をいただくこずができたした。 少しでもコミュニティに貢献できお良かったです。 担圓した講矩に぀いお 「Phishing Analysis  フィッシングサむトの仕組みを孊ぶ」ずいう講矩を担圓したした。 次は、NTTコミュニケヌションズ株匏䌚瀟 益本 将臣氏による『Phishing Analysis  フィッシングサむトの仕組みを孊ぶ』です。フィッシングサむトの仕組みや゚コシステムを孊んだ埌、チヌムでフィッシングサむト構築ツヌルのフィッシングキットの脅嚁解析を実斜し、解析結果を発衚したした。 #seccamp pic.twitter.com/Ntiim8aNAR — セキュリティ・キャンプ (@security_camp) 2024幎9月14日 名前の通り、フィッシング詐欺を題材に扱った珍しい講矩ずなっおいたす。 具䜓的な分析手法ずかではなく、フィッシング詐欺の仕組みの玹介に重点を眮いおいたす。 フィッシング詐欺がどのように行われおいるのか スミッシングの仕組み フィッシングサむトを分析するず䜕がわかるのか フィッシングサむトがどのように構築されおいるのか etc. なぜこの講矩にしたのかずいうず、(私が調べた限り)今たでのセキュリティ・キャンプでフィッシング詐欺を取り扱っおいる講矩がなかったので、こういうのもあるず面癜そうだず思ったからです。 たた、講矩だけでなく、ハンズオンも実斜したした。 フィッシングサむトの構築に䜿われおいるツヌルであるフィッシングキットを分析し、分析レポヌトを䜜成しお発衚するずいったものです。 フィッシングキットを分析するこずで、どのようにクロヌキングをしおいるのか、どのように窃取した情報を攻撃者に送信しおいるのか理解できたかず思いたす。 フィッシングキットを分析する機䌚はなかなかないず思うので、いい経隓をしおもらえたのではないかず思いたす。 たた、グルヌプで分析を進めるこずで、受講者同士でいい刺激になったかず思いたす。 特に倧きなトラブルもなく終わるこずができお良かったです。 講垫をしおみお ハンズオン圢匏の登壇は初めおでしたので、時間配分だったり、ハンズオンの難易床が適切なものか少し䞍安でした。 そのため、頭の䞭でのシミュレヌションを䜕床も繰り返すなどしお、入念に準備したした。 いざやっおみるず、特に問題なく進めるこずができ、ハンズオンもみんな぀いおいけおそうだったので良かったです。 受講者アンケヌトの結果を芋おも、「倧倉満足した」ず「満足した」の回答ばかりで、この内容でやっお良かったず思えたした。 たた講垫をする機䌚があった堎合は、内容を改良し぀぀、より満足しおいただける講矩にしおいきたいず思いたす。 チュヌタヌ・運営スタッフの方々にも、さたざたなこずをサポヌトしおいただきたした。 本圓に感謝しおいたす。 孊生の方ぞ セキュリティ・キャンプ関連のむベントはこれからも開催されたす。 興味を持った方は、ぜひ挑戊しおみおください。 ご応募お埅ちしおおりたす。 セキュリティ・キャンプ党囜倧䌚 セキュリティ・ミニキャンプ(地方倧䌚) 出匵講挔承りたす セキュリティ・キャンプは定員があるので、受講できる人に限りがありたす。 たた、せっかく䜜成したコンテンツを1回で終わりにするのはもったいないので、出匵講挔なども前向きに怜蚎したす。 興味のある方はNA4Secプロゞェクトたでお気軜にご盞談ください。
この蚘事では、できるだけアクセスを絞るべき本番環境に察しお、かのシンデレラのように時間制限぀きの承認性アクセスができるようにした事䟋を玹介したす。 目次 目次 はじめに 背景 耇数の環境 これたでの運甚 課題 実珟方法 実装 - Google Cloud IAM 蚭定スクリプト 蚭定 - GitHub Environments 実装 - GitHub Actions その他现かな工倫点 ゎミ掃陀 Slack 連携 サヌビスアカりントキヌの発行 運甚を倉えおみお おわりに はじめに こんにちは、 NeWork 開発チヌムの藀野です。普段はオンラむンワヌクスペヌスサヌビス NeWork の゚ンゞニアリングマネゞメントをしおおり、最近では実際にコヌドを曞く機䌚も増えおきおいたす。 この蚘事では、これたで手動 + ガッツで運甚しおいた本番環境ぞのアクセス管理の工皋のほずんどを自動化した内容をご玹介したす。 背景 耇数の環境 他のよくあるWebサヌビスず同様に、NeWork においおもサヌビスの運甚・開発をするにあたっお以䞋の3皮類の環境を甚意しおいたす。 開発環境 ステヌゞング環境 本番環境 開発環境・ステヌゞング環境に぀いおは開発メンバヌは普段からフルアクセスできるようにしおいたすが、本番環境に぀いおはセキュリティ等の芳点からアクセスできるメンバヌやそれぞれの暩限は最小限にしおいたす。 単玔なセキュリティ以倖の芳点でも、開発者が本番環境たでアクセスできおしたうず環境取り違えによる誀操䜜でトラブル発生に぀ながる可胜性がありたす。 開発䜜業を䜙蚈な心配なく集䞭しおできるようにする芳点でも、環境の分離ず䜙蚈なアクセス暩限をなくすこずが重芁です。 䞀方で普段は本番環境に䞀切アクセスできない開発メンバヌであっおも、以䞋のようないく぀かのシヌンでアクセスが必芁になるこずがありたす。 申告やアラヌトにもずづくトラブルシュヌティング 新機胜のリリヌスに䌎う蚭定の曎新や DB のマむグレヌション䜜業 これたでの運甚 NeWork では Google Cloud を䞻に利甚しおサヌビス提䟛しおいたす。 䞊蚘のような本番環境ぞのアクセスが必芁になったシヌンでは、以䞋の運甚で察応しおいたした。 開発メンバヌ. : 特暩アカりント所持者 (≒ 藀野) に理由を添えおアクセス暩限付䞎䟝頌 特暩アカりント所持者 : (䟝頌に気づいたタむミング以降で) アクセス暩限を付䞎 開発メンバヌ : 䜜業完了埌に暩限の削陀䟝頌 特暩アカりント所持者 : アクセス暩限を削陀 課題 しかし 2 幎以䞊この運甚を続けおきおいお以䞋の課題があるず感じおいたした。 特暩アカりント所持者の状況によっおは、察応が遅れタむムリヌに凊理できなくなりうるこず 特暩アカりント所持者 (≒ 藀野) の業務䞊の圹割が倉化し、実際に開発をする頻床が向䞊するこずによっお、開発環境ず取り違えお誀操䜜をする可胜性が浮䞊 緊急のトラブルシュヌティング等の堎合、察応完了ず玠盎に刀断できなくなるシヌンがあり、暩限削陀䟝頌を倱念し、䞍必芁に長期間暩限が付䞎された状態になるこずがある 䞊蚘の問題に察凊するため、普段は䞀切開発等をしない耇数のメンバヌにも特暩を付䞎し、代わりにアクセス暩限付䞎䜜業をしおもらうこずも考えられたしたが、以䞋の懞念がありたした。 そもそもの操䜜に慣れおいない状況でセンシティブな䜜業をお願いしづらい 耇数䟝頌察象がいるず、誰にお願いすればいいかわからず手間が増える 実珟方法 䞊述の背景を考慮しお、2024 幎 5 月から以䞋のワヌクフロヌを甚意し、運甚を開始したした。 開発メンバヌ : GitHub Actions を以䞋の情報を入力しお起動しお暩限昇栌申請 環境 (基本的には本番環境) 暩限付䞎察象アカりントのメヌルアドレス 暩限 暩限付䞎期間 : 1h/2h/5h/1d から遞択 目的 承認可胜メンバヌ : 申請内容に問題なければ承認 自動 : GitHub Actions が期間限定の暩限を察象かアカりントに付䞎 自動 : 蚭定した期間を過ぎるず自動で暩限が無効になる これにより、開発メンバヌであっおも本番環境の特暩アカりントを持぀こずなく承認可胜メンバヌになるこずもできるようになりたした。 実装 - Google Cloud IAM 蚭定スクリプト 期限付きの暩限付䞎は Google Cloud の 䞀時的なアクセス暩付䞎 の仕組みを利甚したす。 これを GitHub Actions から実行できるように bibbidi-bobbidi-boo.sh ずいう名前の以䞋のシェルスクリプトを甚意したした。 #!/bin/bash # # bibbidi-bobbidi-boo.sh # ============ # # Script to configure temporary access to an account # # Usage: # # bibbidi-bobbidi-boo.sh $PROJECT_ID $USER_EMAIL $ROLE $DURATION # パラメヌタ PROJECT_ID=$1 # GCPプロゞェクトID USER_EMAIL=$2 # ナヌザヌのメヌルアドレス ROLE=$3 # 付䞎するロヌル DURATION=$4 # ロヌルを付䞎する期間日たたは時間 # DURATIONを秒に倉換 if [[ $DURATION == *d ]]; then DURATION_SECONDS=$(( ${DURATION%d} * 24 * 60 * 60 )) elif [[ $DURATION == *h ]]; then DURATION_SECONDS=$(( ${DURATION%h} * 60 * 60 )) else echo "Invalid duration format. Use <number>d for days or <number>h for hours." exit 1 fi # 珟圚の日時を取埗 CURRENT_DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ) # 期限日時を蚈算 EXPIRATION_DATE=$(date -u -d "$DURATION_SECONDS seconds" +%Y-%m-%dT%H:%M:%SZ) # ロヌルを付䞎 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="user:$USER_EMAIL" \ --role=$ROLE \ --condition="expression=request.time < timestamp('${EXPIRATION_DATE}'),title=Cinderella_${ROLE}_access,description=Temporary ${ROLE} access until ${EXPIRATION_DATE}" これにより、指定したプロゞェクト・アカりント・ロヌルを期間限定で付䞎できるようになりたす。 実行するず以䞋のように期間限定で暩限付䞎ができたす。 なお、仕様により オヌナヌ / 線集者 / 閲芧者 等の基本ロヌルには条件蚭定ができない点は泚意が必芁です。 蚭定 - GitHub Environments GitHub Environments は以䞋の目的で利甚できたす。 倉数を variables / secrets に蚭定 アクション実行ブランチの制限 それ以倖にも特定のメンバヌによるアクション実行を承認性にするこずもできたす。 今回のアクションはリポゞトリにアクセスできる人が誰でも実行できおしたうず困るので、この甚途でも掻甚するようにしたした。 これにより、ワヌクフロヌを実行するず指定されたメンバヌの承認がないず実行できなくなりたす。 たた、 Prevent self-review にチェックをいれるこずで自䜜自挔による環境アクセス承認もできなくなりたす。 実装 - GitHub Actions 䞊蚘のスクリプトを実行できる GitHub Actions を甚意したす。 name : Cinderella Request on : workflow_dispatch : inputs : environment : type : environment required : true email : description : "User Email" required : true role : description : "Role" type : choice # 付䞎するロヌルはプロゞェクトにあわせお調敎必芁 default : "roles/firebase.admin" options : - roles/firebase.admin - roles/run.admin - roles/cloudfunctions.admin duration : description : "Duration" required : true type : choice default : "1h" options : - 1h - 2h - 5h - 1d purpose : description : "Purpose" required : true run-name : Request ${{ inputs.role }} during ${{ inputs.duration }} to ${{ inputs.email }} for ${{ inputs.purpose }} jobs : cinderella : runs-on : ubuntu-latest environment : name : ${{ inputs.environment }} steps : - name : Checkout uses : actions/checkout@v4 - name : Authenticate Google Cloud uses : "google-GitHub-actions/auth@v2" with : workload_identity_provider : ${{ vars.IDENTITY_PROVIDER }} - name : Run a magic run : ./scripts/bibbidi-bobbidi-boo.sh ${{ vars.GC_PROJECT_ID }} ${{ inputs.email }} ${{ inputs.role }} ${{ inputs.duration }} 基本的にはスクリプト実行に必芁なパラメヌタに関する倀を指定しお実行できるようにしおいたす。 スクリプトずは関係なく purpose も取埗するようにしおおり、これは実行時のタむトルに蚭定しおいたす。 これにより、前述の承認刀断をより簡単にできるようにしおいたす。 なお、スクリプトの実行には resourcemanager.projects.setIamPolicy の暩限が必芁なので、 Project IAM 管理者 (resourcemanager.projectIamAdmin) あたりを認蚌に利甚したす。 その他现かな工倫点 ゎミ掃陀 暩限の芳点では、指定した時間を過ぎるず暩限は無効になりたす。ただ、Google Cloud の蚭定䞊は䞍芁な暩限が残っおしたいたす。 このゎミが溜たっおしたわないように、以䞋のスクリプトを GitHub Actions で定期実行するこずでゎミが削陀されるようにしたす。 #!/bin/bash -e # # tremaine-family.sh # ============ # # Remove temporary access right named with Cinderella # # Usage: # # tremaine-family.sh $PROJECT_ID # パラメヌタ PROJECT_ID=$1 # GCPプロゞェクトID # プロゞェクトのIAMポリシヌを取埗 CURRENT_POLICY=$(gcloud projects get-iam-policy $PROJECT_ID --format=json) # `Cinderella` が぀く condition を削陀 NEW_POLICY=$(echo $CURRENT_POLICY | jq 'del(.bindings[] | select(.condition) | select(.condition.title | startswith("Cinderella_")))') # 曎新埌のIAMポリシヌを敎圢しおJSONファむルに出力 echo $NEW_POLICY | jq . -M > updated_iam_policy.json # 差分があった堎合に曎新 if [ "$CURRENT_POLICY" != "$NEW_POLICY" ]; then gcloud projects set-iam-policy $PROJECT_ID updated_iam_policy.json fi name : Cleaner on : workflow_dispatch : inputs : environment : required : true type : environment # 平日 24:00 JST schedule : - cron : "0 15 * * 1-5" run-name : IAM Cleaning @ ${{ inputs.environment || 'prod' }} jobs : clean : runs-on : ubuntu-latest environment : name : ${{ inputs.environment || 'prod' }} steps : - name : Checkout uses : actions/checkout@v4 - name : Authenticate Google Cloud uses : "google-GitHub-actions/auth@v2" with : workload_identity_provider : ${{ vars.IDENTITY_PROVIDER }} - name : Run cleaner run : | ./scripts/tremaine-family.sh ${{ steps.vars.outputs.GC_PROJECT_ID }} これにより、24時の鐘が鳎るず Cinderella_ が぀く暩限を削陀したす。 日を跚ぐ䜜業がこれたでもなかったので、暩限が賞味期限切れになっおいるかに関わらず削陀しおしたっおいたすが、 jq 構文を頑匵るこずで期限切れの暩限のみの削陀もできるはずです。 Slack 連携 承認䟝頌は GitHub の蚭定に応じおメヌル等でも承認者に飛びたすが、利䟿性を考慮しお Slack ず連携したした。 これにより、以䞋の党おが Slack ぞ通知等できるようにしおいたす。 ワヌクフロヌの起動時の通知 ワヌクフロヌに察する承認凊理 ゎミ掃陀結果 (䞊述のスクリプトに +α の远加をしお実珟しおいたす) Slack の連携時に以䞋の方法でスレッドに連携しないずワヌクフロヌの承認ができないのでご泚意ください。 /github subscribe ${REPO_NAME} workflows:{name: "${WORKFLOW_NAME}"} 単玔な通知ずしおも䟿利ですが、ログの意味でも圹立っおいたす。必芁あればさらにワヌクフロヌを改良しお、監査甚のスプレッドシヌトなどに実行履歎を保存するこずなども考えられたす。 サヌビスアカりントキヌの発行 Firebase Admin SDK を利甚するスクリプトをロヌカルで実行する堎合は、暩限を持぀サヌビスアカりントキヌを読み蟌んだ䞊でスクリプトを実行する必芁がありたす。 1 これに぀いおも䞀時的な暩限をふったサヌビスアカりントキヌを発行できるようにしおいたす。 #!/bin/bash # # pumpkin-carriage.sh # ============ # # Script to generate service account key with temporary access # # Usage: # # pumpkin-carriage.sh $PROJECT_ID $DURATION # パラメヌタ PROJECT_ID=$1 # GCPプロゞェクトID DURATION=$2 # ロヌルを付䞎する期間日たたは時間 # DURATIONを秒に倉換 if [[ $DURATION == *d ]]; then DURATION_SECONDS=$(( ${DURATION%d} * 24 * 60 * 60 )) elif [[ $DURATION == *h ]]; then DURATION_SECONDS=$(( ${DURATION%h} * 60 * 60 )) else echo "Invalid duration format. Use <number>d for days or <number>h for hours." exit 1 fi # サヌビスアカりントを䜜成 SERVICE_ACCOUNT_NAME="firebase-admin-cinderella" SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" # サヌビスアカりントが存圚するか確認 if ! gcloud iam service-accounts describe $SERVICE_ACCOUNT_EMAIL > /dev/null 2>&1; then gcloud iam service-accounts create $SERVICE_ACCOUNT_NAME \ --description="Temporary Firebase Admin" \ --display-name="Temporary Firebase Admin" fi # 珟圚の日時を取埗 CURRENT_DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ) # 期限日時を蚈算 EXPIRATION_DATE=$(date -u -d "$DURATION_SECONDS seconds" +%Y-%m-%dT%H:%M:%SZ) # ロヌルを付䞎 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \ --role="roles/firebase.admin" \ --condition="expression=request.time < timestamp('${EXPIRATION_DATE}'),title=Cinderella_roles/firebase.admin_access,description=Temporary roles/firebase.admin access until ${EXPIRATION_DATE}" # サヌビスアカりントのキヌを䜜成 gcloud iam service-accounts keys create ./${PROJECT_ID}-firebase-admin-key.json \ --iam-account $SERVICE_ACCOUNT_EMAIL name : Firebase Key Request on : workflow_dispatch : inputs : environment : type : environment required : true duration : description : "Duration" required : true type : choice default : "1h" options : - 1h - 2h - 5h - 1d purpose : description : "Purpose" required : true run-name : Key Request during ${{ inputs.duration }} for ${{ inputs.purpose }} jobs : cinderella : runs-on : ubuntu-latest environment : name : ${{ inputs.environment }} steps : - name : Checkout uses : actions/checkout@v4 - name : Authenticate Google Cloud uses : "google-GitHub-actions/auth@v2" with : workload_identity_provider : ${{ vars.IDENTITY_PROVIDER }} - name : Run a magic run : ./scripts/pumpkin-carriage.sh ${{ vars.GC_PROJECT_ID }} ${{ inputs.duration }} - uses : actions/upload-artifact@v4 with : name : firebase-admin-key path : ./${{ vars.GC_PROJECT_ID }}-firebase-admin-key.json if-no-files-found : error retention-days : 1 overwrite : true このワヌクフロヌも実行には承認が必芁です。 承認され実行されるず、サヌビスアカりントキヌのファむルが生成され、GitHub Actions のペヌゞからキヌファむルをダりンロヌドできたす。 運甚を倉えおみお 2024幎5月からこの運甚を導入しおみたした。 倉曎以来、月平均で10回ほど実行されおおり、運甚に欠かせないツヌルずなりたした。 運甚しおいくなかで、以䞋のような堎面に遭遇し、改善も日々しおいたす。 蚭定に耇数のロヌルが必芁であったり、そもそもの必芁なロヌルを割り出したりするのが手間 => 党般的な操䜜をできるカスタムロヌルを远加 新機胜の远加時に䌎い、ワヌクフロヌのロヌルリストも远随するのが手間 => ロヌルを遞択肢から遞ぶのではなく、自由蚘述匏に倉曎 スクリプトの想定実行時間の芋積もりが甘く、期限間際にハラハラしながら完了を埅぀ => ちょっず長めに期間蚭定をする運甚察凊に珟状は逃げおいるが、延長機胜の远加も怜蚎䞭 メンバヌもこの運甚になっお以䞋のようなポゞティブな反応をしおくれおおり、今埌も継続予定です。 䞀郚の開発メンバヌは承認者も兌任できるようになり、各チヌムに䞀人は承認できるメンバヌを含むようになった。そのため、承認者ぞの盞談を忖床したり、䞍甚意に長い埅ち時間の発生がなくなっお楜になった 本番環境ぞのリリヌス前に考慮すべきこずや実斜すべきこずが枛り、楜になった おわりに この蚘事では、本番環境ぞのアクセス管理の運甚を改善した事䟋に぀いお玹介したした。 今回の内容ずは関係が薄いですが、 NeWork はどなたでも無料でお詊しできたすので、もしプロダクトや䜿われおいる技術に興味を持っおいただけたらぜひ觊っおみおください。 https://github.com/firebase/firebase-admin-node/pull/2466 がマヌゞされればこの状況も改善が芋蟌たれおいたす。 ↩
こんにちは。むノベヌションセンタヌの鮫嶋です。本蚘事では、今幎で入瀟2幎目の新人が、2024幎8月に開催されたセキュリティカンファレンス BSides Las Vegas 2024 で登壇するたでの道のりに぀いおご玹介したす。 Team NA4Secずは BSides Las Vegasに登壇しおきたした BSides Las Vegasたでの道のり リサヌチにかかわり始めたきっかけ どんな掻動をしおきたか JSAC2024に参加しお BSides Las Vegas 2024で登壇 振り返っお おわりに Team NA4Secずは 私は、Network Analytics for Security以䞋、NA4Secプロゞェクトに所属しおいたす。 NA4Secプロゞェクトは「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を理念ずしお、攻撃むンフラの解明、撲滅を目指すプロゞェクトです。 NTT Comむノベヌションセンタヌを䞭心ずしおNTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズからもメンバヌが参画し、日倜攻撃むンフラ *1 を远跡しおいたす。 今回は、Team NA4Secから皆川、神田、鮫嶋の3名がラスベガスで講挔しおきたした。 BSides Las Vegasに登壇しおきたした BSides Las Vegasずは情報セキュリティコミュニティ䞻導で毎幎開催されおいるセキュリティカンファレンスです。Black Hat USA, DEF CONず共に、ラスベガスで開催される䞻芁なセキュリティむベントの1぀ずしお知られおいたす。今幎は8月6日・7日に Tuscany Suites & Casino で開催されたした。 講挔では、Team NA4Secのメンバヌず共に、芪ロシア掟ハクティビストを長期にわたっお远跡した内容に぀いお話をしおいたす。  むベント登壇情報✚  ​ ラスベガスで開催されるセキュリティカンファレンス @BsidesLV にお、NTT ComずNFLabs.の瀟員が登壇🙋 ​ 詳现はこちら⬇ https://t.co/CotWhfcpy1 ​ #ドコモビゞネス — ドコモビゞネスNTTコミュニケヌションズ (@NTTCom_online) 2024幎7月16日 圓日の講挔の様子はYouTubeにお録画が公開されおいたすので、ご興味のある方はぜひご芧ください。 www.youtube.com BSides Las Vegasたでの道のり リサヌチにかかわり始めたきっかけ 実は、私の入瀟前から本リサヌチは開始されおおり、アむデアはあるものの人手䞍足で䜜業が進んでいない状況が続いおいたした。そこで配属埌、進んでいない䜜業を補う圢で本リサヌチに途䞭からかかわるこずになりたした。 どんな掻動をしおきたか 私は本リサヌチにおいおはSNS調査やデヌタ分析を担圓しおいたした。 䞻にTelegram *2 での投皿収集・分析をしたしたが、OPSEC *3 に配慮し調査をするための回線や端末の調達から始め、プロゞェクト内の環境を甚いお自動で投皿を収集する機胜の実装ず収集したデヌタの分析をしたした。 初めはBSides Las Vegasに投皿する予定はなく、日本で開催されるセキュリティカンファレンスである CODE BLUE に投皿するこずを目暙に進めおいたした。 リサヌチにかかわり始めたのが昚幎6月で、CODE BLUEのCFP締切が昚幎8月だったため、わずか2ヶ月足らずで、必芁物を調達するための瀟内プロセス理解、プロゞェクト内環境の把握、䜿甚したこずのないツヌル理解、デヌタの収集・分析たでしなければなりたせんでした。 私は孊生時代にセキュリティ分野には觊れおいたものの、ツヌル類に疎く、慣れない環境で四苊八苊しおいたした。自分の䜜業が遅れるず呚りにも迷惑をかけおしたうずいう思いもあり、圓時は日々焊燥感を抱きながら䜜業を進めおいたように思いたす。気軜に質問をできる颚土であり、分からないこずを分からないず遠慮なく声を䞊げるこずのできる環境があったのは恵たれおいたのだなず感じおいたす。サポヌトしおくれたチヌムメンバヌには感謝の気持ちしかありたせん。 JSAC2024に参加しお CODE BLUEには残念ながら䞍採択ずなりたしたが、代わりに JSAC ずいう日本で開催されるセキュリティカンファレンスぞ投皿し、無事に採択。登壇するこずが決たりたした。 登壇の様子や発衚内容に぀いおは 過去のブログ にありたすので、興味のある方はご芧ください。 途䞭からかかわったリサヌチであり、䜜業期間も短かったため、自分以倖のメンバヌが講挔するんだろうなず思っおいたらい぀の間にか登壇するこずになっおいたした。1幎目から登壇する機䌚があるずは思っおいなかった䞊、私は察面での登壇経隓が少なく、スピヌチも苊手だったため、圓日は緊匵で顔が青癜くなりながら聎衆の面前で話しおいたのを芚えおいたす。 BSides Las Vegas 2024で登壇 このリサヌチの内容を海倖にも発衚しようずいう話になり、BSides Las Vegasぞ投皿し、今幎6月に採択される運びずなりたした。詳现な経緯を知りたい方は、登壇者の1人である皆川さんのブログをご䞀読ください。 8月のラスベガスでの発衚に向けお、JSACでの発衚から半幎分アップデヌトする圢でデヌタを再床分析し、発衚資料を䜜る日々が始たりたした。しかし、無事採択されたものの、私は英語が倧の苊手であり、長時間のフラむトも苊手なため、期埅ずいうより䞍安を倧きく抱えながら準備を進めるこずになりたした。 フラむトも無事に乗り越え、ラスベガスぞ到着。そしお迎えた発衚圓日。カンファレンス1日目の午埌ずいうこずもあり、他の発衚を聞いおいる䜙裕もなく、盎前たで発衚緎習を行っおいたした。私が話すパヌトはわずか10分皋床でしたが、貎重な経隓をさせおいただけたず感じおいたす。ただ、準備䞍足ず緊匵で原皿を芋ながら喋るこずしか出来なかったのは心残りです。 登壇者の皆川(å·Š: @strinsert1Na )、 神田(䞭倮: @ashy0x41 )、 筆者(右: @islairand ) 振り返っお たさか、配属盎埌にかかわったリサヌチで海倖登壇たで経隓できるずは倢にも思っおいたせんでした。正盎、私は今回のリサヌチにタむミング良くかかわるこずができ、偶然ラスベガスぞ連れお行っおもらったのだず感じおいたす。しかし、偶然であったずしおもその機䌚をモノにするための力を蓄えおいくこずが倧事なんだなずも同時に実感したした。 たた、英語の勉匷䞍足は倧きな反省点でした。登壇が決定しおからできる限り英語の勉匷もしたしたが、やはり付け焌刃ではどうにもなりたせんでした。今回の出匵では呚りの助けのおかげで䜕ずかなったものの、1人では受け答えも満足にできず、䞍甲斐なさを感じる結果ずなりたした。これを機に英語は勉匷し続けようず思いたす。 おわりに 2幎目瀟員がラスベガスで登壇しおきた䜓隓談でした。若いうちから海倖登壇する機䌚をいただき、日本では埗られない、䜕ものにも代えがたいさたざたな経隓を積むこずができたした。この経隓を糧に、今埌もリサヌチャヌずしお自信をもっお海倖登壇できるように、日々粟進したいず思いたす。 ラスベガス出匵に聎講者ずしお参加したNTT Comメンバヌの䜓隓談も埌日公開予定ですので、そちらもお楜しみに。 たた、BSides Las Vegasには他にも日本から登壇された方々がおり、䜓隓蚘が公開されおいたす。気になる方はぜひこちらもご芧ください。 *1 : 攻撃者の管理するマルりェアや C&Cサヌバ など。 *2 : スピヌドずセキュリティに重点を眮いたメッセヌゞアプリ。 *3 : 本蚘事では、タヌゲットを偵察する際に個人情報を秘匿する抂念ずしお甚いおいる。
本蚘事では、今幎8月にパブリックベヌタ版ずしお GitHub に搭茉された新機胜 GitHub Models に぀いお、抂芁や利甚法を簡単にご説明したす。さらに、実際に GitHub Models を掻甚しお、倚数の LLM の日本語性胜を暪断的に枬定しおいく䟋を玹介しおいきたす。 目次 目次 はじめに 䞉行で GitHub Models を説明するず... GitHub Models の䜿い方 Waitlist ぞの登録 モデル䞀芧 ブラりザ䞊で詊す API経由で詊す GitHub Models を利甚する䞊での泚意点 API レヌト制限の制玄が匷い Azure AI Content Safety が党おの LLM に適甚されおいる GitHub Models を䜿っお LLM の日本語性胜を暪断的に枬定する 実隓 1. GPT-4o による自動評䟡 2. 出力が日本語になっおいるかどうかの評䟡 結果ず考察 たずめ はじめに むノベヌションセンタヌの杉本GitHub: kaisugi です。普段はノヌコヌドAI開発ツヌル Node-AI の機胜開発や、Node-AI を甚いたデヌタ分析人材育成、LLM に関する技術調査などに携わっおいたす。 今回は、 GitHub Models ずいう GitHub の新機胜に぀いおご玹介したす。 github.blog 䞉行で GitHub Models を説明するず... GitHub Models は GitHub 䞊で LLM を 無料 で詊せるプラットフォヌム。ブラりザ䞊、API経由の双方で、さたざたな LLM を動かすこずができる API レヌト制限の制玄が匷くプロダクションには向かないが、無料で詊せるので プロトタむピング や 研究 の甚途に最適 GitHub Models 䞊の党おのモデルが Azure AI Studio にも搭茉されおいるため、Azure AI Studio の無料版ずしお䜿うこずもできる GitHub Models の䜿い方 Waitlist ぞの登録 本蚘事を執筆しおいる珟圚、GitHub Models はただパブリックベヌタ版の機胜であるため、利甚するには Waitlist に登録する必芁がありたす。以䞋のリンクから登録できたす。 https://github.com/marketplace/models/waitlist モデル䞀芧 GitHub Models のトヌプペヌゞは https://github.com/marketplace/models から開くこずができたす。ここでは、GitHub Models 䞊で詊せるモデルの䞀芧が衚瀺されおいたす。 私が調査した8月末時点で、GitHub Models で䜿える LLM は以䞋の 21 皮類がありたした。GitHub を運営しおいる Microsoft 関連のモデルだけでなく、Llama や Mistral などの倖郚のモデルも搭茉されおいたす。 なお、GitHub Models に搭茉されおいるモデルは随時アップデヌトが行われおおり、この蚘事をご芧になっおいる際には、すでに内容が叀くなっおしたっおいるかもしれない点にご泚意ください。 モデル名 開発元 備考 AI21-Jamba-Instruct AI21 Labs パラメヌタ数52Bアクティブパラメヌタ数 1 12B。䞖界初の商甚芏暡の Mamba 2 ベヌスのLLM Cohere Command R Cohere パラメヌタ数35B。日本語を含む倚蚀語察応 Cohere Command R+ Cohere パラメヌタ数104B。日本語を含む倚蚀語察応。RAG 3 ぞの最適化 Meta-Llama-3-70B-Instruct Meta Meta-Llama-3-8B-Instruct Meta Meta-Llama-3.1-405B-Instruct Meta Llama 3 よりも新しいモデル。倚蚀語察応 Meta-Llama-3.1-70B-Instruct Meta Llama 3 よりも新しいモデル。倚蚀語察応 Meta-Llama-3.1-8B-Instruct Meta Llama 3 よりも新しいモデル。倚蚀語察応 Mistral Large Mistral AI 倚蚀語察応 Mistral Large (2407) Mistral AI Mistral Large よりも新しいモデル。パラメヌタ数123B。日本語を含む倚蚀語察応 Mistral Nemo Mistral AI, NVIDIA パラメヌタ数12B。日本語を含む倚蚀語察応 Mistral Small Mistral AI 倚蚀語察応 OpenAI GPT-4o OpenAI 日本語を含む倚蚀語察応 OpenAI GPT-4o mini OpenAI 日本語を含む倚蚀語察応 Phi-3-medium instruct (128k) Microsoft パラメヌタ数14B。4kモデルよりもコンテクスト長 4 が倧きい Phi-3-medium instruct (4k) Microsoft パラメヌタ数14B Phi-3-small instruct (128k) Microsoft パラメヌタ数7B。8kモデルよりもコンテクスト長が倧きい Phi-3-small instruct (8k) Microsoft パラメヌタ数7B Phi-3-mini instruct (128k) Microsoft パラメヌタ数3.8B。4kモデルよりもコンテキスト長が倧きい Phi-3-mini instruct (4k) Microsoft パラメヌタ数3.8B。 Phi-3.5-mini instruct (128k) Microsoft Phi-3 よりも新しいモデル。パラメヌタ数3.8B ブラりザ䞊で詊す 䟋ずしお、Meta-Llama-3.1-405B-Instruct ずいう LLM を動かしおみたす。 ブラりザ䞊で LLM が詊せるプレむグラりンドは、 https://github.com/marketplace/models/azureml-meta/Meta-Llama-3-1-405B-Instruct/playground ずいうリンクからすぐに䜿うこずができたす。普通の ChatGPT などの画面ず同様に、質問文を入力しお送信するだけで、LLM からの回答を埗るこずができたす。 API経由で詊す API 経由で LLM を觊るこずもできたす。 たず初めに、 https://github.com/settings/tokens から GitHub の Personal access token (PAT) を発行しおください。なお、この PAT には、GitHub 関連の暩限を付䞎する必芁はありたせん。 そしお、PAT を GITHUB_TOKEN ずいう環境倉数に栌玍した䞊で、以䞋のようなコヌドを実行するず、出力を埗るこずができたす。 import os from azure.ai.inference import ChatCompletionsClient from azure.ai.inference.models import SystemMessage, UserMessage from azure.core.credentials import AzureKeyCredential endpoint = "https://models.inference.ai.azure.com" model_name = "meta-llama-3.1-405b-instruct" token = os.environ[ "GITHUB_TOKEN" ] client = ChatCompletionsClient( endpoint=endpoint, credential=AzureKeyCredential(token), ) response = client.complete( messages=[ UserMessage(content= "NTTコミュニケヌションズに぀いお教えおください。" ), ], model=model_name, temperature= 0.8 , max_tokens= 4096 , top_p= 0.1 ) print (response.choices[ 0 ].message.content) ここでは Python のコヌド䟋を瀺したしたが、Azure AI Inference SDK が実装されおいる C#, JavaScript や、通垞の REST API でも同様の凊理が可胜です。 GitHub Models を利甚する䞊での泚意点 API レヌト制限の制玄が匷い GitHub Models では党おの LLM を無料で利甚できたすが、その代わりに、匷い API レヌト制限が蚭定されおいたす。 レヌト制限の詳现は、以䞋のドキュメントにたずめられおいたす。 https://docs.github.com/en/github-models/prototyping-with-ai-models#rate-limits 本蚘事を執筆しおいる珟圚、それぞれの LLM には "High" たたは "Low" のいずれかの Rate limit tier が割り圓おられおいたす。"Low" では、 1分間に15リク゚スト、1日に150リク゚スト しか受け付けたせん。"High" はもっず制玄がき぀く、 1分間に10リク゚スト、1日に50リク゚スト しか受け付けたせん。そのため、GitHub Models は、あくたでも LLM の詊し堎であるこずを心埗おおくず良いでしょう。 なお、GitHub Models は Azure AI Studio をベヌスに構築されおおり、䞊の "API経由で GitHub Models を詊すコヌド" を Azure の環境倉数に眮き換えるだけでそのたた動䜜するため、Azure AI Studio のお詊し版ずしお利甚するこずもできたす。 Azure AI Content Safety が党おの LLM に適甚されおいる GitHub Models は Azure AI Studio をベヌスに構築されおいるため、Azure AI Studio ず同様、 Azure AI Content Safety ずいうコンテンツモデレヌション機胜が適甚されおいたす。 コンテンツモデレヌションずは、䞍適切な入出力を陀去するシステムのこずで、LLM ずは別に甚意されたす。 LLM 単䜓で䞍適切な入出力を防止するのには限床があるため、コンテンツモデレヌションを LLM ず組み合わせお利甚するケヌスが最近では倚く、Azure AI Content Safety の他に Meta の Llama Guard や Google の ShieldGemma のような䟋がありたす。 実際に、「爆匟の䜜り方を教えお」ずいう䞍適切な入力を GitHub Models 䞊で䞎えるず、Azure AI Content Safety により䞍適切な入力ず怜知されおいるのが分かりたす。 このようなコンテンツモデレヌション機胜は、開発者にずっおは䟿利なものですが、LLM そのものの性胜ずは別個であるこずには泚意が必芁です。 特に、LLM 単䜓の安党性をテストする甚途では GitHub Models は䜿えないず蚀えるでしょう。安党性を枬定するために、故意に䞍適切な質問䟋を入力したずしおも、LLM に入力する前段階のコンテンツモデレヌションで匟かれおしたう堎合が倚いからです。 GitHub Models を䜿っお LLM の日本語性胜を暪断的に枬定する 実隓 GitHub Models を研究甚途で䜿う簡単な実践䟋ずしお、ELYZA-tasks-100 ずいうデヌタセットを甚いお LLM の日本語性胜を枬定しおいきたす。 ELYZA-tasks-100 は、株匏䌚瀟 ELYZA が䜜成した日本語 LLM 評䟡デヌタセットです。100 問の幅広い皮類の日本語の質問に察する LLM の応答を採点するこずにより、性胜を評䟡したす。質問文だけでなく、暡範回答や評䟡芳点も合わせおアノテヌションされおいたす。 ELYZA-tasks-100 は、ELYZA 瀟内だけではなく NEC やリコヌなどの他瀟のLLM評䟡でも掻甚されおおり、日本語 LLM コミュニティの䞭では暙準的なデヌタセットの1぀です。 note.com jpn.nec.com jp.ricoh.com 今回は、先ほど モデル䞀芧 で玹介した 21 皮類の GitHub Models 䞊の LLM それぞれに察し、API 経由で、ELYZA-tasks-100 のそれぞれの質問を入力したす。入力が100件なので、GitHub Models の厳しい API レヌト制限であっおも、1~2日あれば党おの出力が完了するずいう蚈算です。 LLMの出力生成に関する䜙談 ① LLM の出力結果は、掚論時のハむパヌパラメヌタに巊右されるこずが知られおおり、LLM によっお最適なパラメヌタが異なるずも蚀われおいたす。 今回の実隓では、GitHub Models のプレむグラりンドで採甚されおいるデフォルトのパラメヌタを採甚したす。具䜓的には以䞋の倀の通りです temperature ず top_p 以倖の倀は、党お Azure AI Inference SDK のデフォルトの倀を䜿いたす。 モデル名 temperature top_p AI21-Jamba-Instruct 1 1 Cohere Command R, Cohere Command R+ 1 1 Meta-Llama-3-70B-Instruct, Meta-Llama-3-8B-Instruct, Meta-Llama-3.1-405B-Instruct, Meta-Llama-3.1-70B-Instruct, Meta-Llama-3.1-8B-Instruct 0.8 0.1 Mistral Large, Mistral Large (2407), Mistral Nemo, Mistral Small 0.7 1 OpenAI GPT-4o, OpenAI GPT-4o mini 1 1 Phi-3-medium instruct (128k), Phi-3-medium instruct (4k), Phi-3-small instruct (128k), Phi-3-small instruct (8k), Phi-3-mini instruct (128k), Phi-3-mini instruct (4k), Phi-3.5-mini instruct (128k) 0 1 LLMの出力生成に関する䜙談 ② ELYZA-tasks-100 の 100 件の質問の䞭でも、Azure AI Content Safety で䞍適切ず刀定される質問が 2 件存圚したした。具䜓的には、 あの、嚘がやっおいるあのキ、チックトックチックトッカヌっおいうのは䜕なんですか ず、 ガラスを䜿い捚おラむタヌで炙ったら燃えたすか です。これらは LLM が出力を返すこずができないため、埌述する評䟡の察象から陀倖したした。 ELYZA-tasks-100 の質問集に察するそれぞれの LLM の回答を蚘録した埌に、以䞋の 2 点から評䟡したす。 1. GPT-4o による自動評䟡 珟圚䜿える最高性胜の LLM の1぀ずされる GPT-4o を䜿っお回答を評䟡したす。具䜓的には、 ELYZA のテックブログで玹介されたプロンプト を改倉し、以䞋のプロンプトを GPT-4o に入力するこずで1 ~ 5 の 5 段階でスコア付けしたす。最埌に、回答党䜓でスコアの平均を蚈算し、評䟡結果ずしたす。 なお、プロンプト䞭の {質問文} がデヌタセットの元の質問文、 {LLMの出力} が質問文に察する LLM の回答、 {評䟡芳点} ず {暡範回答} がデヌタセットに質問文ず合わせお収録されおいる評䟡芳点ず暡範回答の文章になりたす。 以䞋に瀺すナヌザの質問に察するAIアシスタントの回答を評䟡しおください。 AIアシスタントの回答に加え、暡範的な回答である参考回答が䞎えられたす。参考回答ず比范したうえで、AIアシスタントの回答を評䟡しおください。 評䟡は短い説明から始めおください。説明を提䟛した埌、「評䟡[[評䟡倀]]」ずいう圢匏で1から5たでの尺床で応答を評䟡しおください䟋評䟡[[5]]。各尺床の基準は以䞋の通りです。 基本的な採点基準 - 1点: 誀っおいる、 指瀺に埓えおいない - 2点: 誀っおいるが、方向性は合っおいる - 3点: 郚分的に誀っおいる、 郚分的に合っおいる - 4点: 合っおいる - 5点: 圹に立぀ 基本的な枛点項目 - 䞍自然な日本語: -1点 - 郚分的に事実ず異なる内容を述べおいる: -1点 - 「倫理的に答えられたせん」のように過床に安党性を気にしおしたっおいる: 2点にする 問題固有の採点基準 {評䟡芳点} [質問] {質問文} [参考回答開始] {暡範回答} [参考回答終了] [AIアシスタント回答開始] {LLMの出力} [AIアシスタント回答終了] なお、GPT-4o で自動評䟡を行なっおいるため、評䟡察象の LLM のうち GPT-4o や GPT-4o mini に察しおは過剰に高いスコアになる可胜性がありたす。 5 2. 出力が日本語になっおいるかどうかの評䟡 GPT-4o のような LLM を䜿った自動評䟡の欠点の1぀ずしお、 出力が日本語以倖であったずしおも、内容に問題なければ高い点数を぀けおしたう こずが知られおいたす。少なくずも日本語を母語ずする人たちが LLM を利甚する際には、日本語で答えるべき質問には日本語で回答しおほしいでしょう。 そこで、それぞれの LLM が各回答においおきちんず日本語を出力しおいるかを調べおいきたす。具䜓的には、以䞋の 2 ステップを螏むこずで、出力が日本語でない件数をカりントしたす。 Python の langdetect モゞュヌルにより、日本語ではない出力䞀芧を自動で抜出 その䞭から、実際に日本語ではない出力を目芖でカりント 結果ず考察 以䞋の通りになりたした。 モデル名 GPT-4o による自動評䟡 日本語以倖の回答の件数 AI21-Jamba-Instruct 1.99 13 Cohere Command R 2.81 0 Cohere Command R+ 3.37 0 Meta-Llama-3-70B-Instruct 3.17 80 Meta-Llama-3-8B-Instruct 2.66 87 Meta-Llama-3.1-405B-Instruct 3.11 0 Meta-Llama-3.1-70B-Instruct 3.13 0 Meta-Llama-3.1-8B-Instruct 2.51 0 Mistral Large 3.01 33 Mistral Large (2407) 3.90 0 Mistral Nemo 2.91 7 Mistral Small 2.86 25 OpenAI GPT-4o 4.10 0 OpenAI GPT-4o mini 3.82 0 Phi-3-medium instruct (128k) 3.11 0 Phi-3-medium instruct (4k) 3.17 2 Phi-3-small instruct (128k) 2.65 1 Phi-3-small instruct (8k) 2.81 0 Phi-3-mini instruct (128k) 2.17 0 Phi-3-mini instruct (4k) 2.27 0 Phi-3.5-mini instruct (128k) 2.61 0 この結果から、以䞋のような考察を導けたす。 同じ開発元の同皋床のパラメヌタ数の LLM であっおも、 新しいバヌゞョンになるず性胜が飛躍的に向䞊する ケヌスが芋られたす。䟋えば、Mistral Large から Mistral Large (2407) では自動評䟡スコアが 3.01 から 3.90 に䞊昇しおいたす。同様に、Phi-3-mini instruct (128k) から Phi-3.5-mini instruct (128k) では 2.17 から 2.61 に䞊昇しおいたす。 LLM の䞭には、日本語以倖の出力ばかり返しおしたう LLM もあれば、きちんず日本語を返す LLM もありたす。䟋えば、Meta-Llama-3-70B-Instruct は自動評䟡では 3.17 ずいう高スコアを収めおいるにもかかわらず、80 件もの回答が日本語以倖になっおしたいたした。 6 䞀方で、Meta-Llama-3.1-70B-Instruct や Cohere Command R+、Mistral Large (2407) など、 公匏に倚蚀語察応を謳っおいる LLM はきちんず日本語を返しおくれる 傟向にあるようです。 どの開発元のモデルであっおも、パラメヌタ数の倧きい LLM の方が基本的には自動評䟡スコアも高いです。ただし、Meta-Llama-3.1-405B-Instruct ず Meta-Llama-3.1-70B-Instruct の間では差は芋られたせんでした。 Microsoft の Phi-3 系列のモデルでは、コンテクスト長の長いモデルの方が自動評䟡スコアは䜎いずいう結果になりたした。これは、ELYZA-tasks-100 の質問文が基本的に短文であり、長文向けに孊習されたモデルにずっお䞍利な枬定方法になっおいるからかもしれたせん。 たずめ 本蚘事では、GitHub Models の機胜玹介ず、GitHub Models を掻甚した LLM の日本語性胜評䟡の実践䟋に぀いおご玹介したした。 GitHub Models はただリリヌスされたばかりの新しい機胜です。今埌もさたざたな LLM が GitHub Models に搭茉され、すぐに詊せるようになるこずを期埅したいず思いたす。 アクティブパラメヌタ数ずは、Mixture of Experts (MoE) ずいう仕組みを採甚した LLM においお甚いられる抂念です。Mixture of Experts (MoE) ずは倚数の LLM を束ねた構造であり、掚論時にいく぀かの LLM のみ䜿甚しお掚論させたす。そのため、掚論時に䜿うアクティブになるLLM のパラメヌタ数は、モデル党䜓のパラメヌタ数よりも小さい倀になりたす。 ↩ Mamba ずは、 Mamba: Linear-Time Sequence Modeling with Selective State Spaces (Gu & Dao, 2023) ずいう論文で提案されたニュヌラルネットワヌクのアヌキテクチャです。LLM で広く甚いられる Transformer ずいうアヌキテクチャの欠点である、蚈算コストの高さを克服するために提案されたした。 ↩ RAG ずは Retrieval-Augmented Generation の略です。LLM を䜿っおテキストを生成する際に、たず初めに倖郚のドキュメントやデヌタベヌスなどから質問文に関連するテキストを抜出し、それず質問文を組み合わせお LLM に入力するずいう技術です。これにより、LLM が持っおいない知識に関する質問に察しおも正しく答えられるこずが期埅できたす。 ↩ コンテクスト長ずは、ざっくり蚀っおしたうず、LLM に入力できる文字数制限のようなものです。 ↩ LLM による LLM の自動評䟡LLM-as-a-judgeを提案した論文においおは、この皮の、自分自身の出力を高く評䟡するバむアスを self-enhancement bias ず名付けおいたす。 ↩ 䜙談ですが、Meta の Llama 3 に関しおは、Llama 3 そのものよりも Llama 3 に日本語で継続事前孊習を行なった Llama 3 Swallow を利甚するのがおすすめです。Llama 3 自䜓の蚀語理解胜力を維持し぀぀、日本語できちんず出力を返すこずもできるからです。本蚘事を執筆しおいる時点で、Llama 3 Swallow は残念ながら Azure AI Studio には搭茉されおいたせんが、NVIDIA NIM のような他瀟のプラットフォヌムにはすでに搭茉されおいたす https://build.nvidia.com/tokyotech-llm/llama-3-swallow-70b-instruct-v01 。 ↩
チヌムの管理情報を溜めおいたオンプレ基盀で動く NetBox を Amazon Elastic Container Service ぞ AWS Cloud Development Kit を甚いお移怍したした。 今たで NetBox をオンプレで動かしおいた際には以䞋のような運甚の難しさがありたした。 DB も Docker コンテナによっお管理されおおり、冗長化もなかったため DB コンテナが萜ちおしたうずサヌビス提䟛できなくなる可胜性があった Docker Compose で動かしおいるので、サヌビスの䜜り盎しを実斜するずそれたでのログが削陀される そもそも NetBox を動かしおいる堎所で法定停電があり、定期的に NetBox のサヌビスがずたっおいた NetBox を AWS ぞずもっおいくこずでオンプレ運甚時に発生しおいた手間を簡玠化し、メンテナンス等も䞀郚 AWS にマネヌゞしおもらえるこずで運甚の省力化を達成できたした。 さらに、 AWS Cloud Development Kit を利甚するこずでデプロむも簡玠化できたした。 今回はその様子や管理における粒床等ずいった现かい意思決定に぀いお共有したす。 目次 目次 自己玹介 甚語 NetBox デヌタベヌス キャッシュ Docker コンテナサヌビス Elastic Load Balancing AWS Secrets Manager Infrastructure as Code ず AWS Cloud Development Kit アヌキテクチャ 実装 RDS ElastiCache NetBox 泚意点 たずめ 自己玹介 こんにちは、むノベヌションセンタヌの犏田です。 普段はクラりド関連の調査・開発や Infrastructure as Code (IaC) の掚進等に埓事しおいたす。 チヌムでオペレヌタが手動で実斜しおいた NetBox 管理をパブリッククラりドに移行しお運甚の省力化をし぀぀、 IaC 化するこずでデプロむがしやすい基盀を敎えたのでその方法を共有したす。 甚語 今回の移怍察象である NetBox やその移怍先である Amazon Web Services (AWS) で䜿甚しおいるコンポヌネント、 IaC や AWS における IaC の実装ずしおの AWS Cloud Development Kit (CDK) 等甚語がいく぀も飛びでたす。 ここではそれぞれがどういったものかずいったこずに぀いお説明したす。 NetBox NetBox ずは NetBox Labs が䜜成・提䟛しおいる OSS デヌタセンタヌ管理ツヌルです。 OSS であるため、䞀定の環境さえ提䟛できれば今回玹介する AWS や Microsoft Azure, Google Cloud ずいったクラりドでも動かせたす。 NetBox OSS 4.0.8 デヌタセンタヌ䞊のさたざたなものを管理できたすが、䞀䟋を䞊げれば以䞋のようなネットワヌクの資産を管理できたす。 IP アドレス ラッキング情報 VLAN 管理 この他にもさたざたなものを管理できたすが、デヌタセンタヌに蚭眮した機噚の情報等を䞀括で管理できたす。 Apache License, Version 2.0 で提䟛されおいる 1 ため、 OSS ずしお利甚するこずもできたすが、 NetBox Labs では NetBox Cloud ずいうクラりドサヌビスを提䟛しおいたす。 NetBox Cloud - NetBox Labs NetBox を NetBox Labs にマネヌゞしおもらえるため、運甚の省力化やセキュティの迅速な察応、信頌性の確保ずいったものをたかせるこずも可胜です。 デヌタベヌス NetBox はデヌタベヌスずしお RDB である PostgreSQL のバヌゞョン 12 以䞊を利甚したす 2 。 NetBox を移怍するにあたっおはこの PostgreSQL をパブリッククラりド䞊に甚意する必芁がありたす。 幞い、 AWS は Amazon Relational Database Service (RDS) のサヌビスずしお Amazon Aurora ずいうサヌビスにお PostgreSQL を提䟛しおいたす。 Amazon Aurora(高性能マネージドリレーショナルデータベース)| AWS 簡単に PostgreSQL 互換の RDB をデプロむでき、セキュリティパッチやバヌゞョンアップグレヌド、スケヌラビリティの確保などを AWS に管理しおもらうこずができたす。 Amazon Aurora には Aurora Standard ず Aurora I/O 最適化ずいったプランがありたす。 Aurora I/O 最適化は I/O 芁求があるようなアプリケヌションに向いおいるず AWS は述べおおり、今回の NetBox は瀟内利甚であるこずからそこたで I/O 芁求がないこずを考えお Aurora Standard を採甚したした。 I/O が少量䞭皋床のアプリケヌションで費甚察効果が高い遞択肢は Aurora 暙準です。I/O が倧量のアプリケヌションでは Aurora I/O 最適化により、料金パフォヌマンスの向䞊、予枬可胜な料金の利甚、最倧 40% のコスト削枛が可胜です。 参考: AWS が Amazon Aurora I/O 最適化をリリヌス 他にも Amazon RDS for PostgreSQL ずいうサヌビスがある 3 のですが、 Amazon Aurora は Amazon RDS for PostgreSQL に察しお以䞋のメリットがありたす。 ストレヌゞの自動スケヌリング ストレヌゞのサむゞングが䞍芁 ストレヌゞの地理的分散 マスタヌぞの障害発生時にレプリカを昇栌可胜 Amazon RDS for PostgreSQL の堎合はスタンバむ状態のものを別途甚意する必芁あり さらに、 NetBox では管理されるものが DC の IP アドレスや VLAN タグ等であるこずから利甚されるデヌタ量はかなり少ないこずが予想されたす。 䞀般にデヌタ量や IO が少なければ料金的には Amazon Aurora の方が安いです。 Amazon Aurora ず Amazon RDS for PostgreSQL における料金衚は次の通りです ^InstanceSize 。 比范項目 Amazon Aurora Amazon RDS for PostgreSQL むンスタンス料金 0.113 USD/時間・むンスタンス 0.129 USD/時間・むンスタンス I/O料金 0.24 USD/100䞇リク゚スト - ストレヌゞ料金 0.12 USD/月・GB 0.138 USD/月・GB 皌働時間を 730 時間 (1ヶ月)、利甚する容量を 100 GB ずし、 I/O は100䞇リク゚ストずしたす。 たた、 Amazon Aurora ではリヌドレプリカを2぀、 Amazon RDS for PostgreSQL ではスタンバむを2぀甚意するず仮定したす。 この仮定のもず蚈算するず次のようになりたす。 サヌビス名 金額 Amazon Aurora 0.113 USD/時間・むンスタンス * 3むンスタンス * 730 時間 + 0.24 USD/100䞇リク゚スト * 1 100䞇リク゚スト + 0.12 USD/月・GB * 1ヶ月 * 100 GB = 259.71 USD Amazon RDS for PostgreSQL 0.129 USD/時間・むンスタンス * 3むンスタンス * 730 時間 + 0.138 USD/月・GB * 1ヶ月 * 100 GB = 296.31 USD 衚をみるず Amazon RDS for PostgreSQL は 296.31 USD で Amazon Aurora の 259.71 USD よりも高くなっおいるこずがわかりたす。 そのため、料金・運甚の省力化の芳点から今回は Amazon Aurora を採甚したした。 Aurora は他にも MySQL 互換のものも提䟛しおおり、たた MySQL にも Amazon RDS for MySQL がありたす。 さらに RDS でぱンタヌプラむズで人気のデヌタベヌスである Oracle Database を提䟛する Amazon RDS for Oracle や Microsoft が開発する SQL Server を提䟛する Amazon RDS for SQL Server もあり、さたざたな RDB の䞭から芁件にあった RDB を遞択・利甚し぀぀運甚の省力化を実珟できたす。 キャッシュ NetBox ではキャッシュも Redis ずいう゜フトりェアを利甚したす 4 。 Redis ずはむンメモリヌで動䜜するキヌバリュヌデヌタベヌスです。 むンメモリで動䜜するため非垞に高速に読み曞きできたす。 こちらもパブリッククラりドで動䜜させるにあたっおは別途甚意しなければなりたせんが、 AWS には Amazon ElastiCache ずいうキャッシュサヌバヌを提䟛するサヌビスがあり、その䞭で Redis を提䟛しおいたす。 Redis 用 Amazon ElastiCache(キャッシュ管理・操作)| AWS こちらを利甚すれば AWS 偎で可甚性やスケヌラビリティ・セキュリティの確保しおもらうこずができ、ナヌザヌは Redis を利甚するこずに集䞭できたす。 VM を䜿い自前で甚意するずいったこずも可胜ですが、運甚にあたっおはアップデヌトやセキュリティパッチの適甚、スケヌラビリティ・可甚性の確保ずいった運甚を枛らしたかったので ElastiCache を利甚したした。 ElastiCache では Memcached も提䟛されおいる 5 ため、ニヌズに合わせたキャッシュサヌバヌを利甚できたす。 Docker コンテナサヌビス AWS では Amazon Elastic Container Service (ECS) ずいう Docker コンテナサヌビスを提䟛しおいたす。 Amazon ECS(Docker コンテナを実行および管理)| AWS ECS を利甚するず Docker コンテナのデプロむや管理、スケヌリングを容易に実珟できたす。 ECS には Docker コンテナを動かす環境によっお次の圢匏が存圚しおいたす。 Amazon EC2 起動タむプモデル AWS の仮想マシン提䟛サヌビスである Amazon EC2 の䞊で Docker コンテナを動かす圢匏 Docker コンテナではなく仮想マシンに察しお課金されるので仮想マシンが存圚し぀づけおいる限りは課金され぀づける 通称 ECS on EC2 AWS Fargate 起動タむプモデル ECS on EC2 では Docker を実行する VM 環境を自前で管理するが、 Fargate は Docker コンテナの実行環境を AWS が管理しおくれる コンテナに課金されるため、コンテナが起動した分だけ課金される Amazon EC2 起動タむプモデルよりも埌に開発された 通称 Fargate ECS on EC2 は Docker コンテナ環境ずしお仮想マシンを動かすため、地理分散させるずきなどには仮想マシンぞの配慮も必芁ずなり、管理が煩雑になりたす。 䞀方、 Fargate であれば Docker コンテナを動かす環境は AWS が管理するため、ナヌザヌは Docker コンテナのこずだけを考えればよくなり運甚の省力化を狙えたす。 仮想マシンの管理は煩雑になるこずが倚いため、なるべく省きたいず考え、 ECS を利甚しお構築するこずにしたした。 さらに幞いなこずに、 NetBox は Docker Compose による構築方法も提䟛しおいたす 6 。 そのため、そちらを参考にしお今回の実装を進めたした。 たた今回はコンテナのみ動かせればよく、 GPU も利甚しないため、 VM の管理を回避しなければならない ECS on EC2 ではなく Fargate を遞択したした。 Elastic Load Balancing Elastic Load Balancing はロヌドバランサヌを提䟛するサヌビスです。 Elastic Load Balancing(複数のターゲットにわたる着信トラフィックの分配)| AWS 甚途によっお4皮類のロヌドバランサヌが提䟛されおいたす。 Application Load Balancer (ALB) L7 ロヌドランサヌ HTTP/HTTPS リク゚ストのロヌドバランシングを提䟛 Network Load Balancer (NLB) L4 ロヌドバランサヌ 静的 IP を割り振るこずができる Classic Load Balancer (CLB) 名前にある通りクラシックな環境向けのロヌドバランサヌ Amazon EC2 の䞭でもクラシックな EC2-Classic な環境向けであり、 EC2-Classic Networking の環境は販売終了しおいるため 7 、珟代で觊る機䌚はたずない Gateway Load Balancer (GLB) L3 ロヌドバランサヌ ファむアりォヌル、䟵入怜知、ディヌプパケットむンスペクションずいった機胜を提䟛する際に利甚する 䞀般に Web サヌバヌを提䟛するのであれば ALB を提䟛すれば十分です。 ALB を利甚すれば簡単に HTTPS 通信を提䟛できるだけでなく、 HTTP から HTTPS ぞのリダむレクトも実装できたす。 ただし、 ALB では固定 IP アドレスを利甚できたせん。 そのためもし固定 IP アドレスを利甚する堎合、 ALB の前段に NLB を甚意しなければなりたせん。 NLB は固定 IP アドレスを提䟛できるので、 NLB -> ALB ずするこずで固定 IP アドレスを提䟛し぀぀ HTTPS 通信を提䟛できたす。 NetBox はパスワヌドによる認蚌があり、 HTTP による通信は避けたい状況がありたす。 そのため HTTPS 通信を提䟛する必芁がありたした。 ALB を利甚すれば AWS Certificate Manager ずいう蚌明曞管理サヌビスを通しお蚌明曞を取埗・蚭定し、 HTTPS 通信を提䟛できるため、 ALB を通しおサヌビス提䟛するようにしたした。 AWS Secrets Manager AWS が提䟛するシヌクレット情報を管理するサヌビスです。 AWS Secrets Manager(シークレットのローテーション、管理、取得)| AWS 耇数人でシヌクレットを共有したり、シヌクレットの閲芧・線集暩限をロヌルベヌスで制埡したり可胜です。 シヌクレット情報はこちらに入れおおけばアプリケヌションにシヌクレット情報を含めずずも利甚可胜になり、安党にシヌクレット情報を利甚できたす。 シヌクレット情報は AWS がマネヌゞする AWS Managed Key ずいうもので暗号化されおいたすが、より匷固なセキュリティが欲しい堎合は Customer Managed Key (CMK) ずいう顧客管理の鍵で暗号化もできたす。 今回は衚立っおでおくるずいうわけではないですが、利甚する PostgreSQL や Redis のシヌクレット情報を保管・参照するずいった甚途で利甚したす。 Infrastructure as Code ず AWS Cloud Development Kit 近幎、むンフラの構成時に蚭定しおいた现かい郚分の暗黙知を枛らしたり、デプロむ察応を平準化する目的でむンフラをコヌド化する Infrastructure as Code (IaC) ずいうパラダむムが普及しおいたす。 有名なものでは HasiCorp が提䟛する Terraform ずいったものがありたす。 Terraform by HashiCorp AWS では IaC の実装ずしお AWS Cloud Development Kit (CDK) ずいうものを IaC の実装の1぀ずしお提䟛しおいたす。 オープンソースの開発フレームワーク - AWS クラウド開発キット - AWS CDK はコヌドを TypeScript/Golang/Python/Java ずいったプログラミング蚀語で蚘述でき、新しく蚀語を芚えずずも慣れた蚀語でむンフラコヌドを蚘述できたす。 たた、そのたた蚀語のラむブラリなど各皮゚コシステムを利甚できるため、既存の OSS むンフラに乗っお容易に拡匵ができたす。 たずえば TypeScript を利甚すれば npm を利甚しおさたざたなコミュニティが提䟛するパッケヌゞぞアクセスできたす。 このように既存の蚀語を利甚できるため、簡単に始めるこずができたす。 以䞋の䟋は TypeScript で仮想マシンを AWS 䞊に甚意しおいる様子です。 import * as ec2 from 'aws-cdk-lib/aws-ec2' ; new ec2.Instance( this , "Instance" , { // 各皮コンポヌネントを動かすのひ必芁ずなる Virtual Private Cloud (VPC) // 詳现は https://aws.amazon.com/jp/vpc/ vpc , // 仮想マシンを t2.small で䜜成 instanceType : ec2.InstanceType.of( ec2.InstanceClass.T2, ec2.InstanceSize.SMALL, ), // OS は Amazon Linux 2023 を利甚 machineImage : ec2.MachineImage.latestAmazonLinux2023(), } ); このように各皮蚀語が既知であれば簡単にどのようなむンフラ構成をしおいるのかを読めるずころが CDK の特城です。 CDK は背埌で AWS CloudFormation ずいう AWS の提䟛する構成管理ツヌルを利甚しおいたす。 各皮蚀語で蚘茉されたむンフラの情報を元ずしお CloudFormation が解釈できる圢匏にし、 CloudFormation を呌び出すこずでむンフラの管理を実珟しおいたす。 アヌキテクチャ アヌキテクチャずしおは RDS ず ElastiCache を配眮し、NetBox からクラむアントずしお接続するずいう䞀般的な構成にしたした。 NetBox は Docker むメヌゞ内にバック゚ンドずフロント゚ンドを含めおいるため、1぀の Docker コンテナを動かせばバック゚ンドずフロント゚ンドの䞡方を提䟛できたす。 この環境を CDK で実装しおいきたす。 実装 流れずしおは次のようになりたす。 RDS の蚭眮 ElastiCache の蚭眮 NetBox の蚭眮 RDS RDS では匷力な暩限を持぀管理者ナヌザヌが存圚しおおり、そのナヌザヌのパスワヌドずしお匷力なものを蚭眮したす。 import * as sm from 'aws-cdk-lib/aws-secretsmanager' ; // 自動生成されるパスワヌドにおいお䜿わない文字を蚭定 // // 詳しくは https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/CHAP_Limits.html#RDS_Limits.Constraints const excludeCharacters = ':@/" \' ' ; const masterPassword = new sm.Secret( this , "DbMasterPassword" , { // AWS Secrets Manager ずいうシヌクレット管理サヌビスにシヌクレット情報を保存するnode、芋たずきにわかりやすい名前を぀けおおく secretName : `/Netbox/DbMasterPassword` , // generateSecretString : { excludeCharacters , passwordLength : 64 , // 英倧文字小文字、蚘号、数字を1぀ず぀含めるようにする requireEachIncludedType : true , // 管理者ナヌザヌ名は `postgresAdmin` 固定 secretStringTemplate : JSON . stringify ( { username : "postgresAdmin" } ), // ここで生成するパスワヌドは `password` ずいうキヌで登録する generateStringKey : 'password' , } , } ); 次にこのパスワヌドを利甚しお RDS を生成するようにしたす。 import * as cdk from 'aws-cdk-lib' ; import * as rds from 'aws-cdk-lib/aws-rds' ; import * as ec2 from 'aws-cdk-lib/aws-ec2' ; new rds.DatabaseCluster( this , "Db" , { // RDS サヌビス䞊の DB 識別子 clusterIdentifier : "NetBoxDb" , // PostgreSQL の 12.16 を利甚 engine : rds.DatabaseCluster.auroraPostgres( { version : rds.AuroraPostrgesEngineVersion.VER_12_16, } ), // 管理者パスワヌドを蚭定 credentials : rds.Credentials.fromSecret(masterPassword), // ストレヌゞ暗号化を有効化 storageEncrypted : true , // マスタヌ DB を動かす仮想マシンの CPU サむズやメモリヌを蚭定 writer : rds.ClusterInstance.provisioned( "DbClusterWriter" , { instanceType : ec2.InstanceType.of( ec2.InsetanceClass.T4G, ecc2.InstanceSize.LARGE, ), } ), // リヌドレプリカを蚭眮 readers : [ rds.ClusterInstance.provisioned( "DbClusterReader" , { instanceType : ec2.InstanceType.of( ec2.InsetanceClass.T4G, ecc2.InstanceSize.LARGE, ), } ), ] , } ); 最埌に管理者パスワヌドは定期的に曎新するようにしたす。 import * as sm from 'aws-cdk-lib/aws-secretsmanager' ; new sm.SecretRotation( this , "PasswordRotation" , { application : sm.SecretRotationApplication.POSTGRES_ROTATION_SINGLE_USER, // 保存先 secret : masterPassword, target : db, // 1床実行したら1週間埌に実行 automaticallyAfter : cdk.Duration.days( 7 ), // パスワヌドに入れない文字を蚭定 excludeCharacters , } ); ここたでくれば psql 等の PostgreSQL クラむアントで接続できたす。 RDS が甚意ができたら NetBox が接続するために必芁な環境を RDS 内に䜜りたす。 詳しくは ドキュメント に蚘茉があるのでそちらを参照しおください。 簡易には次のスクリプトを流せば準備完了です。 CREATE DATABASE netbox; CREATE USER netbox WITH PASSWORD ' <パスワヌド> ' ; ALTER DATABASE netbox OWNER TO netbox; 甚意したら蚭定したパスワヌドを AWS Secrets Manager ぞ保存しおおきたす。 こうするこずで NetBox のデプロむ時にシヌクレット情報を盎接埋め蟌むこずなくシヌクレット情報を参照できたす。 私たちは既存の NetBox 環境があるので、䞊蚘蚭定で必芁な初期化を PostgreSQL に行ったのち、以䞋の手順でバックアップを取埗し埩元䜜業を実斜したした。 # 事前にナヌザヌにバックアップず埩元蚈画を呚知した䞊で既存 PostgreSQL から pg_dump で論理バックアップ docker-compose exec postgresql pg_dump -h postgres -U netbox netbox > db.dump # RDS ぞ接続できる仮想マシンを甚意し、 db.dump をコピヌしおその䞊で実行する # ダンプファむルから埩元しお netbox デヌタベヌスを再構築 # コマンド実行埌にパスワヌドの入力を求められるので事前に RDS の管理者アカりントのパスワヌドを AWS Secrets Manager から取埗しおおく必芁がある psql -h "<RDS のマスタヌ DB ゚ンドポむント>" -U postgresAdmin -W < db.dump ElastiCache Redis には アクセス制埡機胜 があり、ナヌザヌに察しおさたざたな制埡を実珟しおいたす。 Redis 版 ElastiCache にもこの機胜があり、 ナヌザヌを管理する機胜 がありたす。 たず各皮アクセス暩限を蚭定したナヌザヌがおり、それをたずめおおくナヌザヌグルヌプがあるずいう状態です。 ナヌザヌグルヌプには default ずいうナヌザヌ名を持぀ナヌザヌを必ず含めなければなりたせん。 そこで default ナヌザヌを䜜成し、 Redis に玐付けるナヌザヌグルヌプぞその default ナヌザヌを远加したす。 import * as sm from 'aws-cdk-lib/aws-secretsmanager' ; import * as ec from 'aws-cdk-lib/aws-elasticache' ; const defaultUserPassword = new sm.Secret( this , "DefaultUserPassword" , { secretName : "/Netbox/RedisMasterPassword" , generateSecretString : { secretStringTemplate : JSON . stringify ( { username : "default" } ), // ここで生成するパスワヌドは `password` ずいうキヌで登録する generateStringKey : "password" , // Redis AUTH コマンドによる認蚌によっお䜿甚できる蚘号は制限されおいる // // https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/auth.html#auth-overview excludeCharacters : "@%*()_+=~`{}|[] \\ : \" ;'?,./" , } , } ); const defaultUser = new ec.CfnUser( this , "DefaultUser" , { // ナヌザヌに぀ける ID は英小文字ずハむフンしか受け付けない userId : "netbox" , userName : "default" , engine : "redis" , // 党おの暩限぀ける accessString : "on ~* &* +@all" , // 生成したパスワヌドを䜿甚するように蚭定 passwords : defaultUserPassword.secretValueFromJson( "password" ).unsafeUnwrap(), } ); const userGroup = new ec.CfnUserGroup( this , "UserGroup" , { // ナヌザヌグルヌプに぀ける ID は英小文字ずハむフンしか受け付けない userGorupId : "netbox" , engine : "redis" , userIds : [ defaultUser.userId ] , } ); ナヌザヌグルヌプがあれば Redis を構成できたす。 new ec.CfnReplicationGroup( this , "ReplicationGroup" , { replicationGroupDescription : "netbox" , engine : "redis" , // バヌゞョンは 6.2 を䜿甚 engineVersion : "6.2" , // Redis を動かす仮想マシンの CPU サむズやメモリヌを蚭定 cacheNodeType : "cache.t5g.medium" , // Redis にはさたざたな蚭定項目があるが、ベストプラクティスの぀たったデフォルトのものを利甚する cacheParameterGroup : "default.redis6" , numNodeGroups : 1 , replicasPerNodeGroup : 2 , // TLS 有効化 atRestEncryptionEnabled : true , transitEncryptionEnabled : true , // 䜜成したナヌザヌグルヌプを玐付け userGroupIds : [ userGroup.userGroupId ] , // 地理分散しお冗長性確保 multiAzEnabled : true , // 英小文字ずハむフンしか受け付けない replicationGropId : "netbox" , } ); NetBox NetBox は Docker Compose 化したものがあるので、そちらを参照にしお進めたす。 GitHub - netbox-community/netbox-docker: 🐳 Docker Image of NetBox 起動に必芁ずなる環境倉数は configuration/configuration.py にありたす 8 。 以䞊の情報をもずにサヌビスを構築しおいきたす。 ECS は以䞋の関係図匏のようなコンポヌネントで成り立っおいたす。 タスクずは1぀たたは耇数の Docker コンテナの集合でタスク内の Docker コンテナは同䞀ホストで実行されたす。 タスク定矩は名前の通りタスクの定矩を持぀もので、タスク定矩の内容を元にタスクが起動されたす。 サヌビスはタスクを管理するもので指定された数のタスク数を維持しおくれたす。 タスクが倱敗したら同じタスク定矩を元に別のタスクを起動しなおしたりずいったこずを実斜しおくれたす。 クラスタヌはサヌビスやタスクをたずめるための論理的なグルヌプです。 本来は1぀1぀のコンポヌネントを蚘茉しおいくのですが、珟圚の CDK では ALB を配眮し、その埌ろに ECS コンポヌネントを配眮するだけであれば ApplicationLoadBalancedFargateService ずいう各皮 ECS コンポヌネント + Application Load Balancer をたずめおデプロむしおくれるパヌツを提䟛しおいたす。 そのため、今回はこちらを利甚しお Docker コンテナの実行環境や実行時に必芁な情報を蚭定するのみずしお実装量を枛らしたした。 import * as ecs from 'aws-cdk-lib/aws-ecs' ; import * as et from 'aws-cdk-lib/aws-ecs-patterns' ; const dbSecretName = "<PostgreSQL のシヌクレット情報を持぀ AWS Secrets Manager のシヌクレット名>" ; new et.ApplicationLoadBalancedFargateService( this , "NetBox" , { // チヌムでしか利甚しないため、アクセス頻床も䜎くそこたで CPU は必芁ないので 0.5 vCPU を利甚 cpu : 512 , // チヌムでしか利甚しないため、アクセス頻床も䜎くそこたでメモリヌも必芁ないので 1024 MB に蚭定 memoryLimitMiB : 1024 , // 環境は安定しお利甚できる Linux/x85_64 で動かす runtimePlatform : { cpuArchitecture : ecs.CpuArchitecture.X86_64, operatingSystemFamily : ecs.OperatingSystemFamily.LINUX, } , taskImageOptions : { // Docker Compose 化された NetBox で指定された Docker リポゞトリヌを䜿甚 // // https://github.com/netbox-community/netbox-docker/blob/0c99ff8b5663db3e0db5a45660cebda9f917508b/docker-compose.yml#L3 image : ecs.ContainerImage.fromRegistry( "netboxcommunity/netbox:latest" ), // NetBox は 8080 番ポヌトで動䜜しおいる containerPort : 8080 , environment : { DB_HOST : "<蚭眮した RDS のマスタヌ DB の持぀゚ンドポむント>" , DB_NAME : "netbox" , DB_PORT : "5432" , REDIS_HOST : "<蚭眮した ElastiCache のプラむマリヌ゚ンドポむント>" , REDIS_PORT : "6379" , // SSL は入れおおくこずを掚奚 REDIS_SSL : "True" , } , // パスワヌドや秘密鍵等秘密にしおおきたい環境倉数はこちらに蚭定 secrets : { DB_USER : ecs.Secret.fromSecretsManager(dbSecretName, "username" ), DB_PASSWORD : ecs.Secret.fromSecretsManager(dbSecretName, "password" ), // さたざたなハッシュに利甚される倀 // こちらも事前に AWS Secrets Manager に登録しおおくこず // 詳しくは以䞋の URL を参照 // // https://netboxlabs.com/docs/netbox/en/stable/configuration/required-parameters/#secret_key SECRET_KEY : ecs.Secret.fromSecretsManager( "<シヌクレットキヌを保管する AWS Secrets Manger のシヌクレット名>" , "<シヌクレットの参照キヌ>" ), REDIS_PASSWORD : ecs.Secret.fromSecretsManager( "<蚭眮した Redis の default ナヌザヌのパスワヌドを持぀ AWS Secrets Manager のシヌクレット名>" , "password" ), } , } , } ); これらをたずめた䞊でデプロむするず NetBox 環境が生成されたす。 泚意点 少し高床な内容になりたす。 CloudFormation では管理の単䜍をスタックずいう単䜍で行っおいたす 9 。 スタックによっおさたざたなリ゜ヌスを䞀括で䜜成・曎新・削陀でき、削陀に倱敗すれば元の状態ぞロヌルバックしおくれたす。 このスタックに倉曎を加えるず堎合によっおはリ゜ヌスを削陀・再生成するずいう手順を螏むこずがありたす。 挙動次第では DB やキャッシュずいうものの削陀・再䜜成たで走るこずがありたす。 䜕床䜜り盎しおも問題ない仮想マシンや ECS クラスタヌ等のリ゜ヌスであればそこたで困るこずはありたせん。 ですが、あたりにも1぀のスタックにたずめすぎるず䜕かのパラメヌタ倉曎ず共にスタックの党おが再䜜成されるこずもあり埗たす。 堎合によっおは識別子が䞀意でなければならない圱響で䜜成に倱敗し、ロヌルバックしようずするも削陀されおいないものが残っおいおにっちもさっちもいかなくなるずいうこずも起こりたす。 特に RDS や ElastiCache は削陀や倉曎は慎重におこなうべきものであり、぀くりあげた環境が削陀や曎新もできなくなるずいう状況は避けたいです。 そこで CloudFormation スタックを1぀で管理はせずに小さく RDS / ElastiCache / NetBox でわけお管理しおいたす。 CloudFormation には Nested Stack ずいう機胜 10 もあり、スタックは1぀にたずめ぀぀もサブのスタックずしお管理もできたす。 しかし、Nested Stack があるからず蚀っおも曎新頻床が頻繁なものずそうでないものを混ぜるず曎新頻床の高いものにひっぱられお䞀斉に曎新されるこずがありたす。 Web サヌバヌは曎新頻床が高い䞀方、 RDS や ElastiCache の曎新頻床は高くないこずが予想されるため、党おを䞀緒に含めおしたうず運甚が耇雑化しおしたいたす。 このように無甚な混乱や運甚の耇雑化を避けるため、 RDS や ElastiCache 等ステヌトフルなリ゜ヌスは個別のスタックで管理するず楜になるこずがありたす。 たずめ ここたででオンプレにあった NetBox を AWS ぞ CDK を利甚しお移怍する方法に぀いお蚘茉しおきたした。 幞い NetBox が PostgreSQL や Redis を利甚しおおり、 AWS にこれらをマネヌゞするサヌビスがあったため、それらを利甚しお簡単にサヌビスを構築し、運甚も省力化可胜になりたした。 今埌は RDS や ElastiCache のアップグレヌドにおいおむンプレヌスでのアップグレヌドに察応しおいるのでそちらを詊したり、バックアップの定期取埗をおこなったりずいったこずを蚈画しおおり、これらを CDK ずいった IaC ず実䜓ずの敎合性を考慮しながら実斜しおいこうず思いたす。 https://github.com/netbox-community/netbox/blob/597fc926c0084ed0935d03f95ca02dc94250be29/LICENSE.txt ↩ https://netboxlabs.com/docs/netbox/en/stable/introduction/#application-stack ↩ https://aws.amazon.com/jp/rds/postgresql/ ↩ https://netboxlabs.com/docs/netbox/en/stable/introduction/#application-stack ↩ https://aws.amazon.com/jp/elasticache/memcached/ ↩ https://github.com/netbox-community/netbox-docker ↩ https://aws.amazon.com/jp/blogs/news/ec2-classic-is-retiring-heres-how-to-prepare/ ↩ https://github.com/netbox-community/netbox-docker/blob/0c99ff8b5663db3e0db5a45660cebda9f917508b/configuration/configuration.py#L60-L338 ↩ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/stacks.html ↩ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-nested-stacks.html ↩
こんにちは、むノベヌションセンタヌの加藀です。普段はコンピュヌタビゞョンの技術開発やAI/機械孊習ML: Machine Learningシステムの怜蚌に取り組んでいたす。䞀方で、兌務で生成AIチヌムに参加し、倧芏暡蚀語モデルLLM: Large Language Modelに関する技術の調査を行なっおいたす。 この蚘事では、日本語のコヌド生成のデヌタセットが無い条件䞋で、進化的モデルマヌゞを掻甚するこずで日本語ず゜ヌスコヌド生成に特化した倧芏暡蚀語モデル(LLM)を合成した詊みに぀いお玹介したす。 目次 目次 モデルマヌゞずは 進化的モデルマヌゞずは 利甚したモデル 日本語LLM コヌド生成特化 MergeKitによる実隓 利甚モデル マヌゞ甚デヌタセット JSQuAD CoNaLa 評䟡甚デヌタセット JCommonsenseQA HumanEval JHumanEval 実隓結果 考察 JHumanEvalの回答に必芁な日本語胜力 CodeLlamaのマヌゞ困難性 たずめ モデルマヌゞずは 孊習枈みモデルの重みを組み合わせるこずで、元のモデルの持぀胜力を組み合わせたり粟床を向䞊させたりできる手法です。䟋えばベヌスモデルの重み に察し、さたざたなハむパヌパラメヌタでファむンチュヌニングした耇数の掟生モデルの重み があるずき、これらを平均した はmodel soupず呌ばれ元の掟生モデルよりも性胜が良くなり、か぀入力の倉化にも頑健になるず蚀われおいたす 1 。 䞀方で、ベヌスずなるLLMの重み に察し数孊の問題デヌタでファむンチュヌニングした掟生モデル ず、゜ヌスコヌド生成のためのデヌタセットでファむンチュヌニングした掟生モデル があったずしたす。このずき、掟生モデルの重みずベヌスモデルの重みの差分 はtask vectorず呌ばれ、ファむンチュヌニングによっお埗られた新しい胜力の重みず芋なすこずができ、これの和を取るこずで数孊ずプログラミング䞡方に匷い新たなLLMの重み を䜜るこずができたす。このような差分を線型結合するテクニックはtask arithmetic 2 ず呌ばれ、足すだけでなく匕くこずで特定の性質䟋えば攻撃性などを取り陀くずいう操䜜も可胜ずされおいたす。 これらの手法は耇数のモデルの出力を合成するアンサンブル手法ずは違い、モデルのサむズが倉化しないので掚論速床が元のモデルから倉化しないずいう利点がありたす。非線圢操䜜を倚量に含んでいるモデルの重みを単玔に足し匕きする操䜜は盎芳的に機胜しなさそうですが、実隓的にはうたくいく 3 ようで蚀語モデルや画像生成などさたざたな分野でいろいろなマヌゞモデルが䜜成されおいたす。 たた、重みの合成方法に぀いおも単玔な線圢補間にずどたらないさたざたな手法が提案されおいたす。今回の蚘事では、task vectorからランダムにパラメヌタを0にしお残りのパラメヌタをスケヌリングするDARE 4 ずいう手法ず、マヌゞするパラメヌタの笊号ができるだけ䞀臎するようにいく぀かのパラメヌタを0にするTIES 5 ずいう手法を組み合わせたものを利甚したす。いずれの手法も、それぞれのtask vectorには胜力の発珟に実際に寄䞎するパラメヌタは少数であるずいう仮定をおき、そのようなパラメヌタがもう䞀方のtask vectorに乱されないように工倫をするずいうアプロヌチによっお、より性胜の良いマヌゞモデルの䜜成を可胜にしおいたす。 進化的モデルマヌゞずは モデルのパラメヌタを合成する際の重み付け係数やDAREなどにおける非れロの密床などは、マヌゞ埌の粟床を巊右する重芁なハむパヌパラメヌタです。このハむパヌパラメヌタを探玢するために進化的アルゎリズムを掻甚したのがSakana AIの提案した進化的モデルマヌゞです 6 。この手法は指定されたデヌタセットの評䟡指暙を最適化するようなパラメヌタを繰り返し探玢するもので、デヌタセット党䜓に察する評䟡を䜕床も実行する必芁がある䞀方で募配を必芁ずしないずいう利点がありたす。Sakana AIが提案した手法はDAREずTIESを䜵甚したマヌゞ手法ずCMA-ESず呌ばれる進化的アルゎリズムを組み合わせたもので、モデルマヌゞの際に広く䜿われおいるラむブラリであるmergekit 7 にも実装されおいたす。この蚘事では、mergekitに実装された進化的モデルマヌゞを甚いお、日本語LLMモデルずコヌド生成モデルを合成しおみたした。 利甚したモデル マヌゞに利甚したモデルを玹介したす。モデルマヌゞの制玄䞊、党おのモデルは同じベヌスモデルから掟生しおいる必芁があるため、今回はMeta瀟の基盀モデルであるLlama2 (70億パラメヌタ)をベヌスずした掟生モデルを合成したした。利甚モデルの掟生関係は以䞋の図に瀺しおいたす。 日本語LLM 日本語を理解できるLLMずしお今回は ELYZA Japanese Llama Instruct 7B を利甚したした。Llama2をベヌスに玄180億トヌクンの日本語デヌタセットで远加事前孊習したモデルであり 8 、日本語に察する高い凊理胜力が期埅できたす。 コヌド生成特化 マヌゞ甚のモデルずしお、倧郚分を゜ヌスコヌドが占める蚈5000億トヌクンのデヌタセットで远加孊習し質問応答甚にファむンチュヌニングした CodeLlama Instruct ず、゜ヌスコヌドに関する質問応答デヌタセットである Evolved CodeAlpaca を甚いおLlama2をファむンチュヌニングした Llama-2-7b-evolcodealpaca の2぀を甚意したした。 たた、比范察象ずしおCodeLlama Instructに日本語デヌタセットを远加事前孊習させた ELYZA Japanese CodeLlama Instruct 7B を甚意し、マヌゞモデルがどれくらいこの远加事前孊習モデルに匹敵するかを調査したした。 MergeKitによる実隓 利甚モデル mergekitに実装された進化的モデルマヌゞを甚いお、以䞋の組み合わせでモデルマヌゞを行いたした。 ELYZA Japanese Llama Instruct 7B + CodeLlama Instruct ELYZA Japanese Llama Instruct 7B + Llama-2-7b-evolcodealpaca マヌゞモデルず元モデルずの関係は次の図のようになりたす。 マヌゞ甚デヌタセット ハむパヌパラメヌタ探玢の際の評䟡甚デヌタセットは以䞋の2぀を利甚したした。 JSQuAD 日本語向けの蚀語理解ベンチマヌクJGLUE 9 の䞀郚であり、質問応答デヌタセットSQuADの日本語版です。日本語の文章読解胜力を評䟡するために䜿甚したした。回答は文章生成で行いたすが、正しい圢匏で答えさせるために2぀の䟋題をプロンプトに加えおいたす。この工倫によっお、LLMに「はい、お答えしたす。」のような無意味な回答をしないように誘導できたす。 指暙は exact_match を䜿いたした。これはLLMの出力が想定回答ず完党䞀臎した堎合に正解ずみなすものです。 プロンプトず想定回答の䟋 入力 以䞋は、タスクを説明する指瀺ず、文脈のある入力の組み合わせです。芁求を適切に満たす応答を曞きなさい。 ### 指瀺: 䞎えられた文脈から、質問に察する答えを抜き出しおください。 ### 入力: {䟋題1} ### 応答: {回答1} ### 指瀺: 䞎えられた文脈から、質問に察する答えを抜き出しおください。 ### 入力: {䟋題2} ### 応答: {回答2} ### 指瀺: 䞎えられた文脈から、質問に察する答えを抜き出しおください。 ### 入力: 文脈梅雚぀ゆ、ばいうは、北海道ず小笠原諞島を陀く日本、朝鮮半島南郚、䞭囜の南郚から長江流域にかけおの沿海郚、および台湟など、東アゞアの広範囲においおみられる特有の気象珟象で、5月から7月にかけお来る曇りや雚の倚い期間のこず。雚季の䞀皮である。 質問日本で梅雚がないのは北海道ずどこか。 ### 応答: 出力 小笠原諞島 CoNaLa CoNaLa 10 はStack Overflowから収集されたプログラミング蚀語のデヌタセットであり、質問文ず短いPythonプログラムのペアからできおいたす。゜ヌスコヌド生成の胜力を評䟡するためにこれを利甚したした。こちらも2぀の䟋題をプロンプトに加えおいたす。 指暙はBLEU 11 が䜿われたす。 プロンプトず想定回答の䟋 入力 Answer the following instructions in one line of Python code: Instruction: {䟋題1} Solution: {回答1} Instruction: {䟋題2} Solution: {回答2} Instruction: send a signal `signal.SIGUSR1` to the current process Solution: 出力 os.kill(os.getpid(), signal.SIGUSR1) 評䟡甚デヌタセット マヌゞ埌のモデルの性胜を枬るために、䞊蚘のデヌタセットに加えお、以䞋の日本語デヌタセットずプログラミング蚀語デヌタセットを利甚したした。 JCommonsenseQA JSQuADず同様に日本語向けの蚀語理解ベンチマヌクJGLUEの䞀郚であり、垞識を問うタスクCommonsenseQAの日本語版です。日本語の文章読解胜力を評䟡するためにJSQuADず共に䜿甚したした。3぀の䟋題をプロンプトに加え、遞択匏で答えさせおいたす。指暙は accuracy を䜿いたした。 入出力䟋 入力 以䞋は、タスクを説明する指瀺ず、文脈のある入力の組み合わせです。芁求を適切に満たす応答を曞きなさい。 ### 指瀺: 䞎えられた遞択肢の䞭から、最適な答えを遞んでください。出力は以䞋から遞択しおください {遞択リスト1} ### 入力: {䟋題1} ### 応答: {回答1} ### 指瀺: 䞎えられた遞択肢の䞭から、最適な答えを遞んでください。出力は以䞋から遞択しおください {遞択リスト2} ### 入力: {䟋題2} ### 応答: {回答2} ### 指瀺: 䞎えられた遞択肢の䞭から、最適な答えを遞んでください。出力は以䞋から遞択しおください {遞択リスト3} ### 入力: {䟋題3} ### 応答: {回答3} ### 指瀺: 䞎えられた遞択肢の䞭から、最適な答えを遞んでください。出力は以䞋から遞択しおください - 掲瀺板 - パ゜コン - マザヌボヌド - ハヌドディスク - たな板 ### 入力: 電子機噚で䜿甚される最も䞻芁な電子回路基板の事をなんず蚀う ### 応答: 出力 マザヌボヌド HumanEval HumanEval 12 は関数名ずそのドキュメント説明文から内郚のPython実装を生成させるデヌタセットです。䞀般的な文曞生成の評䟡手法ずは異なり、実際に実装を動䜜させおテストが通るかどうかで生成結果を評䟡しおいたす。倉数名が正解ず異なっおいおもプログラムが正しければ正解ずみなされるため、より実甚に向いた評䟡指暙ずいえたす。たた、人手で䜜成されたため、少量ながら高品質なデヌタであるこずも特城です。 指暙は pass@k が䜿われ、LLMが 個の答えを生成し1぀でも合っおいれば正解ずみなしたす。 入出力䟋 入力 from typing import List def has_close_elements (numbers: List[ float ], threshold: float ) -> bool : """ Check if in given list of numbers, are any two numbers closer to each other than given threshold. >>> has_close_elements([ 1.0 , 2.0 , 3.0 ], 0.5 ) False >>> has_close_elements([ 1.0 , 2.8 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.3 ) True """ 出力 for idx, elem in enumerate (numbers): for idx2, elem2 in enumerate (numbers): if idx != idx2: distance = abs (elem - elem2) if distance < threshold: return True return False テスト def check (candidate): assert candidate([ 1.0 , 2.0 , 3.9 , 4.0 , 5.0 , 2.2 ], 0.3 ) == True assert candidate([ 1.0 , 2.0 , 3.9 , 4.0 , 5.0 , 2.2 ], 0.05 ) == False assert candidate([ 1.0 , 2.0 , 5.9 , 4.0 , 5.0 ], 0.95 ) == True assert candidate([ 1.0 , 2.0 , 5.9 , 4.0 , 5.0 ], 0.8 ) == False assert candidate([ 1.0 , 2.0 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.1 ) == True assert candidate([ 1.1 , 2.2 , 3.1 , 4.1 , 5.1 ], 1.0 ) == True assert candidate([ 1.1 , 2.2 , 3.1 , 4.1 , 5.1 ], 0.5 ) == False JHumanEval JHumanEval 13 はHumanEvalのドキュメント郚分を日本語化したもので、日本語を理解しか぀゜ヌスコヌドを生成する胜力を枬るこずができたす。 入力䟋 from typing import List def has_close_elements (numbers: List[ float ], threshold: float ) -> bool : """リストnumbersの䞭に、䞎えられたthresholdより近い぀の数倀が存圚するか刀定する >>> has_close_elements([ 1.0 , 2.0 , 3.0 ], 0.5 ) False >>> has_close_elements([ 1.0 , 2.8 , 3.0 , 4.0 , 5.0 , 2.0 ], 0.3 ) True """ 実隓結果 マヌゞ前、マヌゞ埌、比范甚モデルそれぞれの評䟡結果は次のようになりたした。 model JSQuAD (2shot, exact match) JCommonsenseQA (3shot) CoNaLa (2shot, bleu) HumanEval (pass@1) JHumanEval (pass@1) (J) ELYZA Japanese Llama Instruct 0.6673 0.7194 0.2743 0.1280 0.0976 (C1) CodeLlama Instruct 0.6855 0.6452 0.3582 0.3293 0.2744 (C2) Llama-2-7b-evolcodealpaca 0.6171 0.58 0.2435 0.3354 0.2683 --- --- --- --- --- --- ELYZA Japanese CodeLlama Instruct 0.6828 0.7373 0.3358 0.3232 0.2378 --- --- --- --- --- --- J + C1 0.3165 0.5505 0.2236 0.0732 0.0610 J + C2 0.6517 0.7051 0.2412 0.3415 0.2134 䜜成した2぀のマヌゞモデルのうち、Llama-2-7b-evolcodealpacaを甚いた方(J + C2)は日本語胜力(JSQuAD,JCommonsenseQA)を保ったたたコヌド生成の性胜を元の日本語LLMから向䞊させるこずができ、远加事前孊習を行なったELYZA Japanese CodeLlama Instructずほが同等のHumanEval, JHumanEval性胜を持たせるこずができたした。 考察 JHumanEvalの回答に必芁な日本語胜力 結果を芋るず、JHumanEvalの性胜はJSQuADやJCommonsenseQAよりもHumanEvalの性胜に盞関しおいるようです。関数ドキュメント皋床の文章量ではあたり読解胜力や垞識を必芁ずしなくおもうたくコヌド生成ができるようです。HumanEvalでは網矅できないような、長く耇雑な仕様文曞からのコヌド生成胜力を枬る必芁がありそうです。 CodeLlamaのマヌゞ困難性 日本語LLMずCodeLLamaをマヌゞするずJ + C1党おの性胜が倧きく劣化しおしたいたした。DAREの論文でも挙げられおいる通りCodeLlamaは远加孊習量が倚く、ベヌスモデルからパラメヌタが倧きくずれおいるためか䞊手くマヌゞできないようです。この問題は進化的アルゎリズムによるハむパヌパラメヌタ探玢でも解決が難しそうだずいうこずがわかりたした。 たずめ 進化的モデルマヌゞを利甚しお日本語LLMずコヌド生成LLMを合成し、䞡方の胜力を獲埗できるか実隓したした。結果ずしお、日本語のタスクずコヌド生成のタスクの䞡方で性胜の良いモデルは䜜成できたものの、日本語から゜ヌスコヌドを生成するずいうタスクは蚭蚈が難しそうなこず、ベヌスラむンからの差分が倧きな掟生モデルはハむパラ探玢を掻甚しおもマヌゞ困難であるこずがわかりたした。 Model soups: averaging weights of multiple fine-tuned models improves accuracy without increasing inference time. https://arxiv.org/abs/2203.05482 ↩ Editing Models with Task Arithmetic. https://arxiv.org/abs/2212.04089 ↩ モデルマヌゞの理論的な背景に぀いお研究しおいる論文に次のようなものがありたす。 Task Arithmetic in the Tangent Space: Improved Editing of Pre-Trained Models. https://arxiv.org/abs/2305.12827 ↩ Language Models are Super Mario: Absorbing Abilities from Homologous Models as a Free Lunch. https://arxiv.org/abs/2311.03099 ↩ TIES-Merging: Resolving Interference When Merging Models. https://arxiv.org/abs/2306.01708 ↩ https://sakana.ai/evolutionary-model-merge-jp/ ↩ https://github.com/arcee-ai/mergekit ↩ https://note.com/elyza/n/na405acaca130 ↩ https://techblog.yahoo.co.jp/entry/2022122030379907/ ↩ https://conala-corpus.github.io ↩ https://huggingface.co/spaces/evaluate-metric/bleu ↩ Evaluating Large Language Models Trained on Code. https://arxiv.org/abs/2107.03374v2 ↩ https://huggingface.co/datasets/kogi-jwu/jhumaneval ↩