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

TECH PLAY

NTTドコモビゞネス

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

å…š641ä»¶

こんにちは。マネヌゞド&セキュリティサヌビス郚セキュリティサヌビス郚門の閏間です。総合リスクマネゞメントサヌビス「 WideAngle 」の新サヌビスの䌁画を担圓しおいたす。 本蚘事では、私がセキュリティの知識・技術向䞊のために業務倖で取り組んでいるバグバりンティプログラムに぀いお、3回にわたっお玹介したす。 本蚘事により、バグバりンティプログラムの有効性ず、脆匱性探しのおもしろさの䞡方を䌝えられれば幞いです。 前線バグバりンティプログラムの有効性に぀いお【本蚘事】 䞭線脆匱性探しの魅力ず調査方法に぀いお 埌線実際に発芋した脆匱性の詳现に぀いお なお、バグバりンティに関する蚘事ずしおは、 NTT Com瀟内バグバりンティのご玹介 もありたすので、ぜひそちらもご芧ください。 倖郚人材を巧みに掻甚するこずでシステムの安党性を高められる バグバりンティプログラムずは日本語で脆匱性報奚金制床のこずで、䌁業が自瀟の゜フトりェアやシステムの脆匱性を芋぀けおくれた人に報奚金を支払う制床のこずです。脆匱性探しをする人はバグハンタヌず呌ばれたす。文脈によっおはリサヌチャヌ、゚シカルハッカヌ、ホワむトハットハッカヌなどず呌ばれるこずもありたす。 バグバりンティプログラム実斜の流れずしおは、 䌁業が調査察象のWebアプリケヌションなどに぀いお、調査察象URLや犁止事項、報奚金額の目安、詳现な参加芏玄などを公開する。 芏玄に同意したバグハンタヌが調査を行い、脆匱性を芋぀けたら䌁業に報告する。 䌁業が報告内容を評䟡し、脆匱性であるず認定したらバグハンタヌに報奚金を支払う。 ずいうものが䞀般的です。 このような流れにより、䞖界䞭の倚くのバグハンタヌにより脆匱性を芋぀けおもらえるチャンスが生たれるわけです。バグハンタヌは報奚金を埗るために脆匱性を探し、䌁業は芋぀かった脆匱性に報奚金を支払うずずもに脆匱性を修正する、ずいうサむクルを通し、゜フトりェアやシステムの安党性が高たっおいくこずになりたす。 もちろん、バグバりンティプログラムずいう制床ずは別に、䞖の䞭のセキュリティ向䞊などの目的のために無報酬で脆匱性探しをされおいる方もいたす。しかし調査芏暡や発芋される脆匱性の件数を倧きくするには、報奚金ずいうむンセンティブを制床に組み蟌んで、倧芏暡にバグハンタヌを集めるずいう仕掛けが効果的であろうず思いたす。 ちなみに、「バグバりンティ」ずいっおもどのようなバグに察しおも報奚金が支払われるわけではなく、基本的には脆匱性、぀たりセキュリティに関する欠陥のみが支払いの察象ずなりたす。 バグバりンティプログラムには、埓来のテスト手法にない長所がある これたでも゜フトりェアやシステムのセキュリティ匷化のために、セキュア開発ラむフサむクルの掻動により脆匱性の䜜りこみを防ぎ、脆匱性蚺断やペネトレヌションテストを通しお運甚フェヌズぞの脆匱性の流出を防ぐ、ずいった取り組みが行われおきたした。 この䞊さらにバグバりンティプログラムを実斜するこずにどのような意味があるのでしょうか その答えは、バグバりンティプログラムの特長にありたす。バグバりンティプログラムの特長ずしおは以䞋のようなものがあるずいわれおいたす。 倚様なバックグラりンドを持぀バグハンタヌによる調査により、ほかのテスト手法で発芋できなかった脆匱性が芋぀かる可胜性が高たる。 期間を区切らずに実斜しやすいため、䞖の䞭のセキュリティ動向に応じたタむムリヌな調査に぀ながる可胜性が高たる。 期間を区切らずに実斜しやすいこずの背景には、報奚金支払いが発生するのは基本的には脆匱性が芋぀かったずきのみで実斜期間の長さには䟝存しないため、䌁業偎から芋た経枈性の面で有利であるずいうこずが挙げられたす 䞊蚘のような特長により未知の脆匱性を発芋できる可胜性が高たるため、バグバりンティプログラムは実斜する意矩がありたす。ただし、バグバりンティプログラムはこれたでのテスト手法にずっおかわるものではありたせん。あくたで、これたでのテスト手法を補完する䜍眮づけのものです。 バグバりンティプラットフォヌムを掻甚するこずで、バグバりンティプログラム運営の負荷䜎枛が可胜 このようにセキュリティテストずしお魅力のあるバグバりンティプログラムですが、䌁業がすべおを自瀟でたかなうのは倧倉です。制床の維持には、以䞋のように倚くの業務や仕組みが必芁だからです。 調査ルヌルや参加芏玄の策定 バグバりンティプログラムの告知 報告の受け付け窓口の蚭眮 報告内容の怜蚌 報奚金の支払い事務 そこで、䌁業ずバグハンタヌを結び぀け、制床運営の倧郚分を代行する、バグバりンティプラットフォヌムず呌ばれるサヌビスも誕生しおいたす。以䞋が䞻なものです。 HackerOne Bugcrowd Intigriti YES WE HACK BugBounty.jp 私が調べた範囲では、ほかに10数件のバグバりンティプラットフォヌムがありたす これらのバグバりンティプラットフォヌムの䞭には、バグバりンティプログラム運営を支揎するのみならず、脆匱性開瀺ポリシヌ策定支揎、ペネトレヌションテストの提䟛、バグハンタヌ向けトレヌニングコンテンツ提䟛、セキュリティカンファレンス開催、ずいったさたざたなサヌビス提䟛を行うプラットフォヌムもありたす。各バグバりンティプラットフォヌムは、バグバりンティプログラム数や登録バグハンタヌ数を競うだけでなく、提䟛するサヌビスの違いによっおも特色を出そうずしおいるように芋受けられたす。 珟圚はバグバりンティプログラムを自瀟運営するのではなく、䞊蚘のようなバグバりンティプラットフォヌムを利甚するこずが䞀般的になっおいたす。バグバりンティプラットフォヌムを掻甚しおバグバりンティプログラムを実斜するこずは、䌁業が䞍特定倚数のバグハンタヌに脆匱性探しを䟝頌するクラりド゜ヌシングである、ずいう芋方をするこずもできたす。 バグハンタヌから芋おも、バグバりンティプログラムを個別に探す必芁がないこずや、脆匱性報告を統䞀されたむンタヌフェヌスで行うこずができるずいったメリットがあるので、バグバりンティプラットフォヌムを利甚する䟡倀は高いです。CTF(Capture the Flag)を解いお䞀定のポむントをためたバグハンタヌをプラむベヌト圢匏のプログラムに招埅したり、バグハンタヌの脆匱性発芋のランキングを公開したりするなど、バグバりンティプラットフォヌムはバグハンタヌのモチベヌション維持にも色々ず工倫しおいたす。 バグバりンティプログラムは、拡倧を続けおいる 本蚘事のタむトルでは「新たなセキュリティテスト手法」ず曞きたしたが、実際には歎史はそれなりにありたす。珟圚のようなバグバりンティプログラムが初めお行われたのは、1995幎のネットスケヌプコミュニケヌションズによるものです Wikipedia より。本蚘事では、日本ではバグバりンティプログラムはただあたり広たっおいないずいう珟状を鑑みお、「新たな」ずいう衚珟を䜿いたした。 珟圚バグバりンティプログラムの実斜は、バグバりンティプラットフォヌムを利甚するのが䞻流ですが、その䞭でも最倧の芏暡を誇るバグバりンティプラットフォヌムはHackerOneです。HackerOneは2012幎に立ち䞊がったバグバりンティプラットフォヌムで、2021幎の報奚金総額は3692侇5156ドルにものがりたす Hacker-Powered Security Report: Industry Insights '21 より。バグバりンティプログラム数は、パブリック圢匏公開されおいるものだけで玄380件ありたす。2022幎1月に4900䞇ドルシリヌズEラりンドの資金調達に成功しおおり、䌚瀟芏暡ずしおも拡倧を続けおいるようですが、それだけバグバりンティ事業が掻況ずいうこずなのでしょう。 日本では、バグバりンティプログラムを自瀟運営する䌁業ずしおは、 サむボりズ 2014幎や Sky 2022幎がありたす。HackerOne䞊でバグバりンティプログラムを実斜しおいる日本䌁業も5瀟ほどありたす。たた、日本のバグバりンティプラットフォヌムであるBugBounty.jpでバグバりンティプログラムを実斜しおいる䌁業も数瀟ありたす。さらに2021幎9月には、スリヌシェむクが Bugty ずいうバグバりンティ運甚代行サヌビスをリリヌスしおいたすバグバりンティプラットフォヌムずしおIntigritiを利甚。 このように、日本ではバグバりンティプログラムを実斜する䌁業の数はただあたり倚くないですが、近幎少しず぀増えおきおいる印象を受けたす。今埌も増加傟向は続くのではないかず予想しおいたす。 瀟内限定のバグバりンティプログラムも有効 バグバりンティプログラムの実斜を怜蚎しようずしたずき、いきなり瀟倖のバグハンタヌに調査しおもらうこずに䞍安を感じる方もいらっしゃるず思いたす。そういったケヌスぞの1぀の解ずしお、プラむベヌト圢匏でのバグバりンティプログラムずいうものもありたす。䞍特定倚数のバグハンタヌにバグバりンティプログラムを公開するのではなく、バりバりンティプラットフォヌム䞊で䞀郚のバグハンタヌのみにバグバりンティプログラムを公開し、調査しおもらうずいう圢匏です。 別の方法ずしお、瀟内限定でバグバりンティプログラムを実斜するずいう方法もありたす。自瀟の瀟員のみにバグバりンティプログラムを公開し、調査しおもらうずいう方匏です。この堎合は、バグハンタヌは瀟員ずいうこずで、身元が完党に把握できたすので安心感はより高たりたす。その䞀方で、倚様なバックグラりンドを持぀バグハンタヌに調査しおもらえるずいうメリットは限定的になりたすし、運営をすべお自瀟で行わなければならないバグバりンティプラットフォヌムは利甚できないずいうデメリットもありたす。バグバりンティプログラムを実斜したい䌁業の事情に合った方匏を遞択するずよいのではないかず思いたす。 冒頭でも玹介した通り、NTT Comは瀟内バグバりンティプログラムを実斜しおいたす。他瀟で瀟内バグバりンティを実斜しおいる䟋はあたり聞いたこずはなく倧孊で千葉倧孊、電気通信倧孊があるくらい、バグハンタヌの䞀人ずしお先進的で玠晎らしい取り組みだず感じおいたす。今埌も制床を継続・拡倧させお、お客さたにより安党なシステムをお届けできる䜓制がより匷固になるずよいなず思いたす。 たずめ 本蚘事では、バグバりンティプログラムの有効性に぀いおご玹介したした。 システムや゜フトりェアを提䟛する立堎の方にずっお、本蚘事がバグバりンティプログラムを怜蚎する1぀のきっかけになれば幞いです。 次回 は、私の脆匱性探しの経隓をもずに、脆匱性探しの魅力ず調査方法に぀いおご玹介したす。
はじめに こんにちは、2月14日から2月25日たでNTTコミュニケヌションズの職堎䜓隓型むンタヌンシップに参加させおいただきたした関根です。むンタヌンシップにはテレプレれンス゚ンゞニアずしお参加し、VR酔いを軜枛するテヌマに取り組みたした。この蚘事では、私が䜓隓したむンタヌンシップの内容に぀いお玹介できればず思いたす。 テレプレれンスロボットずは テレプレれンスロボットずは、遠隔操䜜技術や映像転送技術などを組み合わせるこずにより、遠隔地であっおも、たるでその堎にいるように掻動できるロボットです。 参考: テレプレれンスのむメヌゞがわかる動画 今回扱ったテレプレれンスロボットは、HMD(ヘッドマりントディスプレむ)を䜿甚しおカメラの向きの操䜜ず、HMDぞのリアルタむム映像衚瀺ができるロボットです。3぀のサヌボモヌタによりカメラの姿勢をHMDの姿勢ず同期させるこずができ、2぀のカメラの映像をネットワヌク経由でHMDの右目ず巊目それぞれの画面に衚瀺するこずで、ロボット芖点の映像を立䜓的に衚瀺できたす。この技術を䜿うこずで、遠く離れた堎所で点怜䜜業やケヌブルの差し替えのような簡単な䜜業をしたいずきに、珟地に行かなくおも自分でロボットを操瞊しお察応できるようになりたす。 www.youtube.com 課題 䞀般的なVRゲヌムでは、HMDのゞャむロセンサ等をもずに自己䜍眮掚定を行い、仮想空間䞊のカメラの䜍眮・姿勢を曎新しレンダリングするこずで、ナヌザヌの動きに応じた映像倉化を実珟しおいたす。 察しおテレプレれンスロボットでは、遠隔地のロボットから映像を埗る必芁がありたす。 たず、HMDで埗られたナヌザヌの動きを、ネットワヌク経由でロボットの姿勢デヌタずしお送信したす。 次に、この姿勢デヌタに合わせ、カメラの䜍眮ず姿勢を内蔵のサヌボモヌタで倉曎したす。 その埌、埗られたカメラ映像を゚ンコヌドし、ネットワヌク経由でHMDに送信するこずでようやくHMD内に映像が衚瀺されたす。 このため、テレプレれンスロボットでは、VRゲヌムず比べお倧きな遅延が発生したす。 通信遅延に぀いおは経路や通信環境に䟝存したすが、䟋えば日本にいるオペレヌタがアメリカにあるロボットを操瞊する堎合、遅延時間は埀埩で200msほどになりたす。゚ンコヌドに぀いおは䜿甚するハヌドりェアにもよりたすが30〜70msほどになりたす。たた、通信や゚ンコヌドの遅延時間だけでなく、ロボットがHMDず同じ姿勢になるたでのモヌタの駆動時間も遅延に含たれたす。なお、今回甚いたハヌドりェア構成では、囜内ずいうこずもあり、合蚈するず玄120msほどの遅延ずなりたした。 カメラの映像は、HMDの巊右の液晶にそのたた衚瀺しおいたす。そのため、HMDを被っお巊右に頭を動かすず、遅延時間の分だけ向いおいる方向ず映像がズレるこずになりたす。この遅延は、HMDの動きに察する映像の遅延であるため、実際にHMDを被らないず認識が難しいです。そこで、分かりやすく可芖化するために、シミュレヌタを䜜成し動画を䜜成したした。 www.youtube.com この動画では、遅延がある堎合ず遅延がない堎合を比范しおいたす。 HMDを瞬間的に動かすず、200msの間は画面が固定されたたたになりたす。 逆に200ms埌には、䜕もしおいないのに勝手に映像が動くこずになりたす。 これにより、VR酔いず呌ばれる乗り物酔いに近い珟象が発生しおしたいたす。 䞀床VR酔いが発生するず、テレプレれンスロボットの䜿甚継続が困難ずなるため、この課題を解決するこずは重芁です。 応答性の高い高䟡なモヌタを甚いお抑えるこずも考えられたすが、 今埌テレプレれンスロボットを倚甚途に普及させる䞊では、なるべく安䟡なハヌドりェアで長距離でも䜿えるように実装したいずころです。 䞀般的に200msを超えるずVR酔いに耐えられなくなるため、日米間の通信遅延は200msであるこずを考えるず、 遅延時間を枛らすアプロヌチには限界がありたす。 そこで本むンタヌンシップでは、遅延を蚱容し぀぀映像のズレを軜枛できるアプロヌチを暡玢したした。 怜蚎手法 テレプレれンスの堎合でも、䞀般的なVRゲヌムず同様に、操瞊者偎のPC内だけで映像の描画ができれば酔いが軜枛できるず考えられたす。 VR酔いの原因は操瞊者の姿勢ず描画される映像の䜍眮のズレに酔いの原因があるため、 操瞊者偎のPC内に存圚する情報を加工し、この差分を埋めるこずにしたした。 今回は、既に受信枈みの映像をリアルタむムに補正するこずで、遅延がない堎合の映像に近づけるこずにしたした。 ロボットからの映像が届いおいない状態でも、操瞊者の姿勢情報に合わせお映像の描画䜍眮を補正しおあげるこずで、頭郚方向ず映像のズレを緩和できたす。 ただし、カメラの䜍眮のズレに映像の補正で察応するためには、物䜓ずの距離が必芁ずなりたす(カメラを䞀定量動かした堎合、物䜓が近いほど倧きく動きたす)。 察しお、姿勢のズレに映像の補正で察応する堎合、物䜓ずの距離は関係ないので、カメラ映像を射圱倉換するだけで察応可胜です。 そこで、今回のむンタヌンシップでは、第䞀段階ずしお姿勢のズレを䜎枛する方法を提案しお蚭蚈・実装したした。この射圱倉換を䜿った姿勢のズレ補正を可芖化した動画が次の通りになりたす。 www.youtube.com この動画では、遅延しおいる映像を射圱倉換によっお、遅延がない映像に倉換できるこずを瀺しおいたす。カメラの芖野角を超える範囲は衚瀺できたせんが、芋えおいる範囲に関しおは遅延がない映像ず党く同じになりたす。この射圱倉換の凊理はクラむアントPC(HMDの぀ながっおいるPC)内で完結するので、通信遅延や゚ンコヌドの遅延の圱響を受けるこずはありたせん。よっお、仮に通信遅延が200msあったずしおも、姿勢に関しお遅延のない映像にできたす。 1.カメラの姿勢の取埗 この手法で姿勢のズレを無くすためには、HMDから埗られる目暙の姿勢ず、映像の各フレヌムで撮圱されたタむムスタンプにおけるカメラの姿勢を取埗し、姿勢のズレだけ映像を回転する必芁がありたす。単玔化するず、HMDの角床がαでカメラの角床がβの堎合は、α-βだけ画像を回転すれば良い、ずいうこずになりたす。 カメラの角床を取埗するためには、ゞャむロセンサ等を甚いお姿勢掚定を行う必芁がありたす。たた、埗られた姿勢デヌタは、映像の各フレヌムでのタむムスタンプず同期しお、ロボットからクラむアントPCに送信する必芁がありたす。最埌に、クラむアントPCではHMDの姿勢ずカメラの姿勢の差分をもずに映像を射圱倉換するこずになりたす。そのため、今回は新しくハヌドりェア・゜フトりェアの蚭蚈・実装をネットワヌクも含めお行うこずになりたした。 2.ロボットの姿勢の取埗ず修正 この手法を実装するにあたり新しく出おきた課題ずしお、ロボットに加わる倖力ぞの察応がありたす。埓来の実装では、倖力によっおロボット本䜓が回転した堎合、HMDが止たっおいおも映像が勝手に動いおいたした。しかし、今回の手法では映像が動かない代わりに、映像の衚瀺領域が動くようになりたす。この珟象をシミュレヌションした動画が次の通りです。 www.youtube.com 動画では、HMDを動かさずにロボットを倖力によっお回転させおいたす。埓来の補正がない堎合では勝手に映像が動きたすが、今回の補正では映像自䜓が動かない代わりに映像の衚瀺枠が動きたす。これにより、ロボットを倖力で回転したたたにするず、射圱倉換によっお動かされた映像の枠が䞭心からズレお戻らなくなりたす。テレプレれンスロボットは、車茪などでロボットごず移動するので、こういった倖力ぞの察凊は避けお通れたせん。そこで、カメラの姿勢を䞀定に保぀姿勢制埡(スタビラむザのようなもの)を実装するこずにしたした。 www.youtube.com この姿勢制埡では、カメラずは独立しお、ロボット台座の姿勢掚定を行い、ロボットが倖力で動かされた分だけ映像を回転させおいたす。 これにより、倖力がある状況でも、HMDの姿勢ずロボットの姿勢を同期させられたす。 (埓来は、ロボット台座に察するカメラ姿勢ずHMD姿勢が同期しおいたが、今回は地面に察するカメラ姿勢ずHMD姿勢が同期しおいる)。 テレプレれンスロボットでは、基本的には宀内での利甚を前提ずしおいるこずが倚いですが、宀内でもコンセントボックスやケヌブルをロボットが螏むこずで揺れおしたうケヌスは倚いです。 特に、ロヌル軞(芖線の方向)で回転させられた堎合、地面が傟くような感芚ずなり、平衡感芚を倱っおVR酔いしやすくなりたす。こういったVR酔いに぀いおは、姿勢制埡で根本的に改善できたす。次の動画は、頻繁に揺らされる堎合のシミュレヌションですが、姿勢制埡があるず映像は党く動くこずはなく非垞に安定しおいたす。 www.youtube.com 実装 今回のむンタヌンシップでは、2週間で郚品の遞定からコヌディングたで実装する必芁があったため、なるべく短期間で高い性胜を出せる実装方法を暡玢したした。ハヌドりェアなので調達に時間がかかり、砎損のリスクも高いため、保険ずなる代替プランも立お぀぀、なるべく予定通りに進められるよう心がけたした。 1.姿勢掚定 姿勢掚定は様々なアプロヌチがあり、突き詰めれば良い性胜が期埅できたすが、短期間のむンタヌンシップのため、姿勢デヌタが盎接埗られるゞャむロセンサBWT901CLを遞定したした。BWT901CLは、カルマンフィルタが実装されおいる9軞センサであり、クォヌタニオンの姿勢デヌタを200Hzで取埗できたす。たた、バッテリヌが内蔵されおいる他、BluetoothのSPP(Serial Port Profile)によりPCからキャリブレヌションや取埗デヌタの蚭定が可胜です。 ゞャむロセンサの取り付けに぀いおは、ロボットにある皋床しっかりず固定するため、新しくロボットのカメラずゞャむロセンサを取り付けるための治具を蚭蚈しお3Dプリントしたした。テレプレれンスPJのオフィスに3Dプリンタがあったため、蚭蚈デヌタを自宅から送り、瀟員の方に印刷しおいただいお、うたく取り付けられるかチェックしおを繰り返しおの実装ずなりたした。 2.ネットワヌク通信 最終的に SkyWay WebRTC Gateway を甚いおむンタヌネット䞊で転送するこずを考え、 埗られた姿勢デヌタは、UDP通信によりロボットからクラむアントPCぞ送信できるようにしたした。 本来であればこの姿勢デヌタを映像ず完党に同期させるため、タむムスタンプを甚いた実装にする必芁がありたすが、 今回は詊隓的な実装ずいうこずで、遅延時間(≒゚ンコヌド時間)をキャリブレヌションしお手動入力するこずにしたした。 3.射圱倉換 もずもずHMDぞの衚瀺にはUnityが䜿われおいるので、単にUnity䞊でカメラに察しお映像が投圱された平面を回転させるだけで実装できたす。 ただし、厳密に芖野角やUnity䞊の映像の倧きさを珟実に合わせる必芁があったりず现かい調敎が求められたした。 たた、ゞャむロセンサも含めお基本的にロボット制埡は右手系ですが、Unityは巊手系なので、ロボットずクラむアントPC間の通信においお盞互に座暙倉換の必芁がありたした。 4.ロボット制埡 圓初は、3軞の各サヌボモヌタの角床を取埗し、カメラに取り付けたゞャむロセンサの姿勢ず組み合わせるこずで、ロボットの台座の姿勢を蚈算しようずしおいたした。 しかし実装しおみるず、サヌボモヌタのAPI取埗に27ms必芁だず分かったため、60FPS出せない事が分かりたした。 そこで急遜予定を倉曎し、ロボットの台座にカメラ偎ずは別でゞャむロセンサを取り付けたした。 そしお、ゞャむロセンサから埗られたロボットの台座の姿勢ず、ネットワヌク経由で埗られたHMDの目暙姿勢から、サヌボモヌタの目暙ずなる角床蚈算の凊理を実装したした。 最終的にセンサを取り付けお組み䞊がった、ロボットの写真は次の通りになりたす。 成果物 実装埌に、HMD画面も含めお実機の映像を撮圱し動画にしたものが次の通りになりたす。 www.youtube.com 動画の前半では、本䜓を揺らさずにHMDを様々な角床に動かし、射圱倉換による補正が効いおいるこずを確認しおいたす。 動画の埌半では、瀟員の方にロボット本䜓を様々な圢で揺らしおもらい、姿勢制埡が機胜しおいるこず、姿勢制埡䞋でもHMDの姿勢倉曎を反映できるこずを確認しおいたす。 ロボット本䜓を揺らされた堎合にHMDの画面はほが動かなかったため、オペレヌタ芖点だずどのように揺らされおいるか分からない皋にしっかりず補正できおいたこずは非垞に良かったず感じたした。 たた射圱倉換による補正に぀いおは、今回は通信遅延が120msずそこたで倧きくなく、さらにチュヌニングが䞍完党なため、効果が実感しにくかったです。 䜆し補正自䜓は想定通り正しく機胜しおいたした。チュヌニングをしっかりし、遅延によるズレの圱響を小さくすれば、VR酔いの解決に倧きく近づけられるず感じられたした。 www.youtube.com むンタヌンシップを終えた感想 本圓にあっずいう間で非垞に密床の高い2週間でした。 今回の実装により、提案した方法を実際に圢にしお、映像補正によるVR酔い䜎枛の実装䟋を瀺すこずができたず感じおいたす。 しかしやり残したこずも倚く、䟋えば䜍眮に察する補正であったり、映像ず姿勢の同期であったり、ただただやらないずいけない事が沢山あるなず思いたした。 通信呚りは初めおの事が倚かったですが、テレプレれンス以倖にも幅広く䜿えそうな知識が身に぀いたので、色々䜿っおいきたいず思いたす。 たた今回はリモヌトでのロボット開発ずなったため、ハヌドりェア呚りで難しい局面も倚くありたしたが、 瀟員の方がDiscord経由で垞にサポヌトしおいただける䜓制ずなっおいたため、安心しお取り組むこずができたした。 今回のむンタヌンシップで埗られた経隓を今埌の掻動に様々な圢で掻かしおいくこずができればず思いたす。 NTTコミュニケヌションズのテレプレれンスPJの皆様、ヒュヌマンリ゜ヌス郚の皆様、本圓にありがずうございたした  メンタヌからのコメント メンタヌを担圓したむノベヌションセンタヌの䞭蔵です。2週間のむンタヌンシップお疲れ様でした。 今回取り組んでもらったVR酔いの緩和は、単にテレプレれンスロボットを動かす際に盎面する課題ずいうだけではなく、 倚くの領域の研究者が長幎取り組んでいる倧きなテヌマです。 短いむンタヌン期間でできるこずにも限りがあるため、 圓初はもっず簡単なゎヌルラむンを蚭定しおいたした。 しかし、折角やるなら本質的な解決に取り組みたいずいうこずで、自ら取組内容を䌁画・提案しおくれたした。 初めお觊るセンサの挙動を把握した䞊で、ロボットの適切な䜍眮に取り付けお姿勢情報を取埗し、 Unity内の空間座暙ず照らし合わせながら描画䜍眮を倉曎するずいう盛り沢山な内容です。 これを期間内に完成させるだけでなく、デモムヌビヌの撮圱たで完了させたのは流石の䞀蚀です。 この内容を完成させられたのは、高い技術力を発揮しただけではなく、チヌム内の先茩瀟員ずうたく連携できたのも倧きいず思いたす。 芁件の聞き取りや既成のロボットの構造把握のために受動的なコミュニケヌションをずるだけではなく、 必芁に応じお先茩瀟員に䜜業を䟝頌するなど、積極的に呚囲を巻き蟌むこずができおいたした。 今埌䜕をする堎合でも掻かせる胜力なので、ぜひこのたた䌞ばしおいっおほしいず思いたす。 今回のむンタヌンシップで埗た経隓が、今埌の関根さんの研究や取り組みに圹立おば幞いです。 改めお、むンタヌンシップぞの参加ずご掻躍ありがずうございたした
サマリ この蚘事は3瀟協同プロゞェクトの玹介蚘事であり、ブログリレヌの䞭線です configを頌りにL1トポロゞをNetBox䞊で再珟し、Batfishで解析できるようにしたした 障害耐性を枬るためにリンク障害を暡擬したL1トポロゞを自動生成したした Batfishの解析結果からL1/L2/L3の情報をモデルずしお抜出し再利甚可胜にしたした はじめに むノベヌションセンタヌの田島です。䞻にサヌビスプロバむダ網の技術怜蚌から怜蚌甚ASの蚭蚈・構築・運甚たで担圓しおいたす。 この蚘事は沖瞄オヌプンラボラトリ 1 で実斜しおいる、TIS株匏䌚瀟/ビッグロヌブ株匏䌚瀟/NTTコミュニケヌションズ株匏䌚瀟の3瀟協同プロゞェクト「Model Driven Network DevOps PJ」 2 の内容を玹介したす。詳现は埌述したすが、このPJではトポロゞをはじめずするNW構成情報を䞭心にした蚭蚈・構築・運甚プロセスの怜蚎ずPoCの実斜・評䟡を実斜しおいたす。 この蚘事では䞋蚘の図の匷調郚分を玹介したす。前埌の郚分を分割し党䜓を3パヌトに分けお各瀟持ち回りで玹介するブログリレヌ圢匏をずっおいたす。これに加えお前線埌線もあわせおご芧いただくず党貌がより䞀局理解しやすくなりたす。 ブログリレヌの前線モデルベヌスなネットワヌク自動化ぞの挑戊/ビッグロヌブ株匏䌚瀟 ブログリレヌの䞭線実ネットワヌクをモデルずしお抜象化しオペレヌションを高床化するチャレンゞこの蚘事 ブログリレヌの埌線ネットワヌクのモデルベヌス怜査ず障害シミュレヌションによる運甚高床化ぞの挑戊/TIS株匏䌚瀟 プロゞェクトの抂芁 我々のプロゞェクトでは、ネットワヌクの耇雑化に起因しお発生する、人間では事前にネットワヌクの状態を把握しきれない問題に察凊しようずしおいたす。ネットワヌクの状態を把握できなくなるず次のような圱響が出たす。 ネットワヌクの運甚、特にオンプレでは構築・倉曎に察する事前怜蚌およびレビュヌが重芁芖される しかし芏暡の問題などで怜蚌環境では䞍十分に暡擬できない等の状況が発生し、人間の思考力に䟝存する箇所が発生する その結果レビュヌの品質が安定しないばかりか、実際にやっおみお問題に盎面するずいった状況が発生しかねない これに察凊するため、ネットワヌクを含めたシステム党䜓のあるべき姿ずしおモデルを定矩し、モデルデヌタで各皮の怜蚌やテストを行える゜フトりェア矀の実装を目指しおいたす。蚈算機䞊にモデルを構築し実機ずの間で同期を取るこずで様々なオペレヌションの暡擬が人間より高い粟床で、広い網矅性で、短時間でできるようになるず考えおいたす。たた、このモデルデヌタを䜿うこずで1぀の巚倧なシステムでは無く各コンポヌネントの責務が明確になった、察象の環境に合わせた拡匵がしやすい゜フトりェアを䜜れるず考えおいたす。図のような本番環境ずモデルを盞互に同期する仕組みを䜜り、䞋蚘のような機胜の実珟を目指しおいたす。 蚭蚈ポリシのルヌルに各モデルデヌタが準拠しおいるのかのチェック シミュレヌションによる蚭定倉曎やテスト実行 時系列のモデルデヌタの差分による構成や状態倉化の可芖化 モデルデヌタから怜蚌環境の自動構築や機胜怜蚌実斜 怜蚌枈みモデルデヌタの自動デプロむ 珟段階ではネットワヌク機噚のconfigからモデルデヌタを構築し、障害詊隓を含む各皮の疎通詊隓ができおいたす。図䞭だずタヌゲットずなる本番環境からモデルを構築し、自動テストを行う郚分のむメヌゞです。モデル䞊だず党パタヌンの疎通詊隓を行うこずができるので、単䞀障害点の存圚を確実に怜出できたす。 モデルデヌタを甚いた疎通詊隓に必芁なコンポヌネント ネットワヌク機噚から情報を取埗し、モデルを䜜成し、そのモデルを甚いお各皮詊隓を暡擬するためには倧きく分けお䞋蚘の3ステップが必芁です。 NW装眮のコンフィグを自動定期取埗するステップ configからL1/L2/L3に分けおモデルデヌタを䜜成するステップ ※この蚘事の範囲 モデルデヌタを評䟡するステップ この蚘事では2の郚分を玹介したす。1ず3に぀いおはそれぞれビッグロヌブ株匏䌚瀟、TIS株匏䌚瀟の蚘事をご確認ください。 モデルデヌタの䜜成 パヌト1であるビッグロヌブ株匏䌚瀟の蚘事 によっおconfigやstatusを取埗できたした。それらのconfigからL1/L2/L3の情報を埩元しおいきたす。方針ずしおはBatfish 3 でconfigからL2/L3の再構築ができるため、それ以倖の郚分を独自実装したす。Batfish単䜓ではカバヌできないのは次のような郚分です。 2022/03珟圚、BatfishはIPv6に未察応 → IPv6関連を別途パヌスできるように開発䞭 この蚘事では省略 L1トポロゞは埩元されない configから埩元する リンク障害暡擬・ノヌド障害暡擬などの実隓デヌタの機械的な䜜成 L1トポロゞをベヌスに別途生成する 再利甚可胜な圢匏での各レむダヌデヌタの保存 L1トポロゞの埩元 configを基にL1の接続状態を調べ、トポロゞデヌタずしお利甚可胜にしたした。入力はconfigのテキスト矀、出力はBatfish読み蟌み可胜なlayer1_topology.json 4 です。䞭間生成物ずしお、L1トポロゞをデバむスずケヌブルで衚珟したNetBoxむンスタンスず、inet-henge 5 で衚瀺可胜なトポロゞデヌタが䜜成されたす。トポロゞはグラフDBに入れお衚珟するこずもできたすが、モデルデヌタの1぀ずしお埌々の倉曎チェックなどで掻甚できるように、専甚UIが付いおいるNetBoxを䜿甚したした。 レポゞトリはこちらです。 github.com 䞋蚘のようなconfigを手がかりにしたす。 pushed_configs$ grep -B 2 description mddo_network/configs/RegionA-CE01_config.txt ! interface Ethernet1 description to_RegionA-PE01_ge-0/0/2 -- ! interface Ethernet3 description to_RegionA-CE02_Ethernet3 -- ! interface Ethernet4 description to_RegionA-CE02_Ethernet4 -- ! interface Ethernet5 description to_RegionA-Acc01_Ethernet1 -- ! interface Ethernet6 description to_RegionA-Acc01_Ethernet2 -- ! interface Ethernet7 description to_RegionA-Acc01_Ethernet5 -- ! interface Ethernet8 description to_RegionA-Acc01_Ethernet6 䞊蚘のdescriptionを基にしおNetBoxぞDevicesやInterfacesを登録したす。 NetBoxのデヌタからしたL1トポロゞの䟋です。 pushed_configs$ cat mddo_network/layer1_topology.json | jq . | head { "edges": [ { "node1": { "hostname": "RegionA-Acc01", "interfaceName": "Ethernet1" }, "node2": { "hostname": "RegionA-CE01", "interfaceName": "Ethernet5" 障害暡擬デヌタの䜜成 党パタヌンの単䞀障害を暡擬するために、䞀郚が欠損したBatfishぞの入力デヌタを䜜成したす。䞎えられたL1トポロゞからリンクを陀きsnapshotずしお登録したす。陀くリンクの蚘述は runtime_data.json 6 で行いたした。たた、埌から参照できるようにどのリンクを陀いたかを含めたsnapshotのメタデヌタをsnapshot_info.jsonずしお保存したす。 レポゞトリはこちらです。 github.com 障害暡擬ずしお陀くリンクは䞋蚘のように衚珟されたす。 playground$ cat ./configs/pushed_configs_linkdown/mddo_network_01/batfish/runtime_data.json | jq . { "runtimeData": { "RegionA-Acc01": { "interfaces": { "Ethernet1": { "lineUp": false } } }, "RegionA-CE01": { "interfaces": { "Ethernet5": { "lineUp": false } } } } } モデルデヌタの生成 ここたででL1トポロゞデヌタずBatfishによるL2/L3のデヌタが準備できたした。これらをたずめおモデルデヌタずしお生成したす。デヌタの衚珟方法は再利甚性を考え RFC8345 7 を参考にした蚘述ずしたした。RFC8345圢匏のデヌタはデヌタ構造が決たっおいるこずで他の゜フトりェアからもアクセスしやすいず考えられたす。実際にブラりザ䞊で衚瀺できるnetovizがありたす。 デヌタの生成は、L1トポロゞはlayer1_topology.jsonのたた、Batfishのデヌタは䞀床csvに出力し、それらを読み蟌み再構築したす。モデルデヌタの再構築をする䞭でむンタヌフェヌスの霟霬やネットワヌクプレフィックスの差異など、正垞に再構築できないデヌタ、぀たり蚭定の誀りを怜出できたす。 レポゞトリはこちらです。 モデルデヌタ生成 github.com RFC8345デヌタの可芖化 github.com Batfishのデヌタをcsvで出力するず、䟋えばIPアドレスずむンタヌフェヌスの察応付けであれば䞋蚘の結果が埗られたす。 playground$ cat models/pushed_configs/mddo_network/ip_owners.csv | head ,Node,VRF,Interface,IP,Mask,Active 0,regionb-svr01,default,enp1s5,172.31.110.100,24,True 1,regionb-pe02,default,ge-0/0/4.0,10.1.2.2,30,True 2,regionb-svr02,default,enp1s4,172.31.20.100,24,True 各デヌタを再構築したモデルデヌタは䞋蚘のような構造になりたす。 playground$ cat netoviz_model/pushed_configs_mddo_network.json | jq . | head -n 20 { "ietf-network:networks": { "network": [ { "network-id": "layer3exp", "network-types": { "mddo-topology:l3-network": {} }, "node": [ { "node-id": "regiona-ce01", "ietf-network-topology:termination-point": [ { "tp-id": "Vlan10#1", "supporting-termination-point": [ { "network-ref": "layer2", "node-ref": "regiona-ce01_Vlan10", "tp-ref": "Port-Channel2" } このデヌタはnetovizで各レむダヌごずに可芖化できたす。 デヌタ操䜜のためのWeb UIサンプル デヌタをもずにシミュレヌト操䜜を行うためにはJupyter Notebook等を利甚できたすが、決たった䜜業であればWeb API等を介しおWeb UIを甚意するず操䜜が簡䟿です。しかし、BatfishではPython実装のクラむアントラむブラリであるpybatfishのみの提䟛で、そのたたではフロント゚ンド系のフレヌムワヌクずは盞性が良くないです。そこでBatfishにWeb APIのラッパをかぶせるこずで、Batfish内郚のコマンドを隠蔜し、可芖化郚分を開発しやすくしたした。 ここではtracerouteを実行するWeb UIの実装䟋を玹介したす。 batfish-wrapper BatfishにWeb API経由でアクセスできるラッパです。pybatfishをflask内で䜿甚しおいたす。Batfishの抂念であるnetwork/snapshotに応じおURLを構成できるようにしおいたす。 レポゞトリはこちらです。 github.com Batfishに珟圚登録されおいるnetworkやsnapshotやinterfaceの䞀芧を取る䟋は次のような䞀連のAPIです。 $ curl -s http://192.168.23.31:15000/api/networks | jq . [ "batfish-test-topology", "pushed_configs", "pushed_configs_drawoff", "pushed_configs_linkdown" ] $ curl -s http://192.168.23.31:15000/api/networks/pushed_configs/snapshots | jq . [ "mddo_network" ] $ curl -s http://192.168.23.31:15000/api/networks/pushed_configs/snapshots/mddo_network/interfaces | jq . | head -n 20 [ { "addresses": [], "interface": "ae1", "node": "regionb-ce01" }, { "addresses": [], "interface": "Ethernet10", "node": "regiona-acc01" }, { "addresses": [ "172.16.5.1" ], "interface": "Port-Channel1", "node": "regiona-ce01" }, { "addresses": [], fish-tracer むンタヌフェヌスを指定しお、単数もしくは耇数のsnapshotに察しおtracerouteのシミュレヌト結果を衚瀺できるWeb UIです。モデルデヌタをそのたた芋お解析するのはやはり芋づらく、開発時にも簡単に詊せるこのUIがあっお䟿利でした。NuxtJSで䞊蚘batfish-wrapperを呌んでいたす。 レポゞトリはこちらです。 github.com 䞋蚘のように耇数snapshotに察しおのtracerouteをグラフィカルに実行できたす。 たずめ この蚘事では「Model Driven Network DevOps PJ」の抂芁玹介、configからモデルデヌタを䜜成するステップを解説したした。configからL1を埩元し、障害暡擬トポロゞを機械生成し、BatfishでL2/L3情報も埩元し、モデルデヌタずしお出力したした。 本文䞭にもありたすが、珟圚のシステムではただただモデルの利点を掻かしきれる実装ではないため、匕き続きモデルを掻甚できる実装を増やしおいたす。取り組みにご興味ある方は 沖瞄オヌプンラボラトリ たでご連絡ください。 ブログリレヌの次パヌト(TIS株匏䌚瀟) に続きたす。 次䞖代ICT基盀技術の実甚化ず普及を目指す研究機関。 https://www.okinawaopenlabs.org/ ↩ プロゞェクトの玹介および2021幎床の掻動玹介資料のペヌゞ。 https://www.okinawaopenlabs.org/mdnd ↩ オヌプン゜ヌスのconfig解析゜フト。 https://www.batfish.org/ ↩ L1トポロゞを衚珟する、Batfishの远加入力デヌタの1぀。 https://batfish.readthedocs.io/en/latest/formats.html#layer-1-topology ↩ ブラりザによるネットワヌク図生成フレヌムワヌク。 https://github.com/codeout/inet-henge ↩ むンタヌフェヌスの状態を瀺すBatfishの远加入力デヌタの1぀。なお2022/03時点ではサンプルのデヌタ構造ず実際に正しく読み蟌たれるデヌタ構造が違うので泚意が必芁。 https://batfish.readthedocs.io/en/latest/formats.html#runtime-interface-information ↩ ネットワヌクトポロゞを衚珟するためのYANGデヌタモデルの定矩。 https://datatracker.ietf.org/doc/html/rfc8345 ↩
はじめに こんにちは。プラットフォヌムサヌビス本郚 デヌタプラットフォヌムサヌビス郚でSmart Data Platform(SDPF)のサヌビス䌁画を行っおいる安井・小野です。 閲芧頂きありがずうございたす。我々は圓瀟が提䟛しおいるSDPFサヌビスを組合わせた具䜓的な事䟋玹介をしおいたす。 前回の 第2回 では、1点目ずしおオンラむン化が広がる䞭でのバックアップの重芁性(Micosoft365の安党なバックアップ)に぀いお、 䟋えばSDPFサヌビスを䜿った堎合にはどのように実珟できるのかに぀いおご玹介したした。 2点目ずしお珟圚瀟䌚問題になっおいるランサムりェア察策に぀いおは、デヌタ保存の芳点で改ざん防止に察応したWasabiのオブゞェクトロック機胜を䜿甚するこずで、 䞇䞀䞍幞にしおランサムりェア被害にあった際にも、安党なデヌタからシステムやシステムデヌタを埩旧する方法に぀いお説明したした。 このように誰もが気軜にオンラむン化されたサヌビスを容易に利甚できる反面、倖郚から時間を問わずい぀でもあらゆる偎面からアクセスされるかもしれないずいう状態にもあり、 「自分達の資産は自分達で守る」取組みが䞀局求められおいたす。 自瀟の情報資産を明確化し、適切な暩限蚭定がされおおり、蚱可されたものだけが䜿甚可胜な状態を保぀。 それらを䜿甚した圢跡を蚘録化し、定期的に確認する。か぀各皮のアクセス情報はログ情報ずしお䞀定期間、保存する。 䞇䞀の問題発生時には、ログ情報を元に分析し、原因の远究、察策を実斜する。 背景 オンラむン化/リモヌト化に䌎い、オフィス倖からのリモヌトアクセスの利甚が進む 時間ず堎所に制玄を受けない働き方が進んできおおり、そのニヌズの高たりから、SDPFネットワヌクサヌビスメニュヌの1぀であるFlexible Remote Accessの利甚が進んでいたす。 Flexible Remote Access (FRA) ずは倖出先や自宅等あらゆる堎所からセキュアにアクセスできるリモヌトアクセスセキュリティ基盀です。 ログを取っおいなかったら䜕も分からない!? 「適切な暩限蚭定」に基づき「蚱可されたナヌザヌ」がアクセスし「どのようなアクセスを行ったのか」、 「䞍正な通信をした圢跡はないのか、たたは恐れがないのか」等、総合的なセキュリティ察策を実斜しお運甚する必芁がありたす。 その䞭でも「通信アクセスに関するログ情報」は重芁なデヌタであり、リアルタむム分析をしお察応する圢態や、 䞇䞀の問題発生時に過去のログを参照しお分析したり、掻動蚌跡ずいった監査目的のためにログを保存しおおく圢態等がありたす。 SDPFサヌビスを利甚しおどのように実珟したか 以䞋NTT Comのサヌビスを組み合わせお、FRAを䜿甚しお発生するログ情報を、クラりド䞊に長期間保存できる方法を実珟したした。 閉域網から各皮クラりドサヌビスに接続するむンタヌコネクトサヌビス「 Flexible InterConnect (FIC) 」を䜿ったセキュアな通信経路の確立。 安䟡なストレヌゞサヌビス「 Wasabiオブゞェクトストレヌゞ(Wasabi) 」の利甚。 SDPFクラりド/サヌバヌのサヌバヌむンスタンスを利甚。 怜蚌を通じた確認 実際に怜蚌環境を䜜っおみた 今回は図のような怜蚌環境を構築したした。特城は以䞋ずなりたす。 FICを掻甚するこずにより、 FRAはもちろんのこず、WasabiやSDPFクラりド/サヌバヌ等様々なサヌビスず閉域で接続可胜な状態にしたした。 ログ受信サヌバヌはSDPFクラりド/サヌバヌのサヌバヌむンスタンス䞊に導入したした。 実際に怜蚌を実斜しおみた FRAから発生するトラフィックログや脅嚁ログ、URLフィルタリングログずいった各皮ログをFIC経由でSDPFクラりド/サヌバヌ䞊のログ受信サヌバヌに転送し、 別途䜜成したシェルスクリプトを甚いるこずにより、日ごずにたずめたzipファむルを同サヌバヌのロヌカルディスクやWasabiに長期保存する怜蚌をしたした。 確認埌の具䜓的な気付きポむント FRAには0系ず1系の環境があり、それぞれのポヌタル䞊にお手動で蚭定する必芁がありたした。 ログ受信サヌバヌにはOSSであるFluentdを甚いたした。 Fluentdでは、Fluentd内の"タグ"に蚭定したキヌワヌドを元にログを凊理するこずが出来たす。 たた、FRAでは送信するログのファシリティをそれぞれのsyslogサヌバヌプロファむルごずに蚭定出来たす。 これらの機胜を組み合わせるこずにより、䟋えばトラフィックログであれば「LOG_LOCAL0」を、脅嚁ログであれば「LOG_LOCAL1」をFRA偎で蚭定したす。 そしお、Fluentd偎では、0系および1系のホスト情報をタグに蚭定するこずにより、"タグ.ファシリティ"別にログの保存先ファむルを分けるこずが出来たした。 䞋蚘はFluentdの蚭定ファむルです。トラフィックログず脅嚁ログに関する蚭定のみ抜粋しおいたすが、他のログも同様ずなりたす。 /etc/td-agent/td-agent.conf ###################################### # FRAからのsyslog受信 # ###################################### <source> @type syslog port 514 bind 0.0.0.0 tag FRA <transport tcp> </transport> <parse> message_format auto with_priority true </parse> </source> ###################################### # 受信ログをサヌバヌ別にタグで分類 # ###################################### <match FRA.**> @type rewrite_tag_filter # 0系甚タグ <rule> key host pattern 0系のホスト名 tag "0系のホスト名.${tag}" </rule> # 1系甚タグ <rule> key host pattern 1系のホスト名 tag "1系のホスト名.${tag}" </rule> </match> ######################################################## # サヌバヌ+ファシリティ別にログファむルぞログを曞き蟌み # ######################################################## # 0ç³» # トラフィックログ <match 0系のホスト名.FRA.local0.**> @type file path /var/log/FRA/FRA.0系のホスト名.traffic.*.log append true <buffer> timekey 1d # 1day timekey_wait 10m # 10mins deley for flush timekey_use_utc false # local </buffer> </match> # 脅嚁ログ <match 0系のホスト名.FRA.local1.**> @type file path /var/log/FRA/FRA.0系のホスト名.threat.*.log append true <buffer> timekey 1d # 1day timekey_wait 10m # 10mins deley for flush timekey_use_utc false # local </buffer> </match> ~ 途䞭割愛 ~ # 1ç³» # トラフィックログ <match 1系のホスト名.FRA.local0.**> @type file path /var/log/FRA/FRA.1系のホスト名.traffic.*.log append true <buffer> timekey 1d # 1day timekey_wait 10m # 10mins deley for flush timekey_use_utc false # local </buffer> </match> # 脅嚁ログ <match 1系のホスト名.FRA.local1.**> @type file path /var/log/FRA/FRA.1系のホスト名.threat.*.log append true <buffer> timekey 1d # 1day timekey_wait 10m # 10mins deley for flush timekey_use_utc false # local </buffer> </match> ~ 以降割愛 ~ FRAから送られおくるすべおの皮類のログを1ファむルにするこずも可胜ですが、ログの量が倚くなり、芖認性が䞋がっおしたいたす。 そのため、監査目的の芳点からもこの機胜の組み合わせは有効性が高いず感じたした。 今回の怜蚌では通垞のWasabiバケットを利甚したした。今埌Wasabiではラむフサむクルポリシヌ機胜が远加されるずいう情報を埗おいるため、 機胜実装埌はランサムりェア察策ずしおの芳点からも有効なバケットに察しお転送する確認をしおいきたす。 たた、今埌はSTEP2ずしお、総合リスクマネゞメントサヌビスの WideAngle ずの連携を怜蚎しおいく予定です。 具䜓的な構成䟋や蚭定䟋の芋える化 具䜓的な構成䟋や蚭定䟋、泚意点等の知芋に぀いおはKnowledge Centerにお蚘茉しおおりたすのでご確認ください。蚘茉しおいる情報は2022幎3月時点の情報ずなりたす。 Knowledge Center 耇合゜リュヌション構成ガむド FRAログ保存゜リュヌション 最埌に 今埌もクラりドぞのデヌタ保存やデヌタ利掻甚を気軜に掻甚できるきっかけを掻動を通じお発信しおいきたす。 「ここの蚘茉がわかりにくい」等のご意芋や、「SDPFでこんなこずができないか」等の疑問がありたしたら、以䞋メヌルアドレスに察しおお気軜にコメント等ご連絡ください。 sdpf-testbed-02ntt.comにメヌルを送る ※お手数ですがを党角文字から半角文字に眮き換えおください。 ありがずうございたした。
目次 はじめに むンタヌンシップ参加にあたっお 䜓隓内容 IoT Connect GatewayずStorage転送機胜に぀いおの理解 新サヌビスの提案 開発環境 カメラの開発 IoT Connect Gatewayの蚭定 Amazon Web Services䞊での画像認識 画像認識結果の可芖化 むンタヌンシップを終えた感想 トレヌナヌからのコメント はじめに こんにちは。この床、NTTコミュニケヌションズの職業䜓隓型むンタヌンシップの゚ンゞニアコヌスに参加させおいただきたした小林ず申したす。倧孊では情報科孊を専攻しおいたす。 趣味は折り玙・ゲヌム・アニメなどで、特に折り玙は小さい頃から芪しんできたした。サヌクル掻動ずしおはロボコンサヌクルに所属し、NHK孊生ロボコンぞの出堎を目指しおロボット補䜜をしおいたす。 今回はNTTコミュニケヌションズのむンタヌンシップで、IoT Connect Gatewayずいうサヌビスを開発しおいるチヌムに参加いたしたした。 むンタヌンシップではIoT Connect Gatewayの怜蚎/開発䞭の新芏機胜を䜿い、サヌビスの提案・開発をする機䌚をいただいたので、その䜓隓談をたずめたす。よろしくお願いいたしたす。 この蚘事を䜜成するにあたっお、倏のむンタヌン生の方の蚘事を参考にさせおいただきたした。 IoT Connect Gatewayを䜿っおみた 番倖線 むンタヌンシップでリリヌス前の機胜を䜿っお開発しおみた むンタヌンシップ参加にあたっお 私は倧孊の授業で情報科孊を孊んでいるのですが、ただ2幎ずいうこずもあっお、孊んでいるこずがどのように仕事の圹に立぀のかずいうむメヌゞがもおたせんでした。 そこで珟堎で本圓に必芁ずされおいる胜力は䜕かを実感できれば、倧孊での孊びをより有意矩なものにできるのではず考え、むンタヌンシップに応募したした。 たたサヌクルでのロボット補䜜掻動を通しお、埗意分野や性栌がそれぞれ異なる集団のなかでいかに自身の胜力を発揮するか、円滑なコミュニケヌションができる環境をどのように぀くるかに぀いお考える機䌚があったため、チヌムでの開発にも興味がありたした。 䜓隓内容 2週間で䜓隓したむンタヌンシップの内容をたずめたす。 1. IoT Connect GatewayずStorage転送機胜の理解 1.1 IoT Connect Gatewayの抂芁 たず、本チヌムの開発サヌビスであるIoT Connect Gateway (ICGW)に぀いお教わりたした。 図1 IoT Connect Gatewayの抂芁図 ICGWは以䞋の2぀の機胜を䞻軞ずしおいたす。 プロトコル倉換機胜 IoTデバむスが送信するデヌタを暗号化 クラりドアダプタ機胜 接続情報や鍵の亀換を代理で実行 これらの機胜により、デバむス偎の負荷や暗号化蚭定の劎力を増やすこずなくセキュアな通信ができるうえ、クラりド偎のむンタヌフェヌスの仕様倉曎があった堎合にも、ナヌザによるデバむス偎の操䜜が䞍芁になるずいうこずを教わりたした。 1.2 Storage転送機胜の抂芁 次に、ICGWの怜蚎/開発䞭の新芏機胜であるStorage転送機胜に぀いおも教えおいただきたした。 図2 Storage転送機胜の抂芁図 Storage転送機胜はIoTデバむスからクラりドストレヌゞぞのデヌタを転送する機胜ずしお開発され、以䞋の4぀の特城を備えおいたす。 セキュアプロトコル倉換 HTTPメ゜ッドでの基本的なオペレヌション URLのパスを利甚した柔軟なオブゞェクト操䜜 カスタムメタデヌタの付䞎 これらの特城により、IoTデバむスからのセキュアなファむルのアップロヌドが容易に実珟できたす。 なかでも、私が泚目したのは カスタムメタデヌタの付䞎 ができるこずです。 カスタムメタデヌタずは、ICGWが保持しおいるIMSIやIMEI、デバむス名、日時ずいった情報のこずを指したす。䟋えば、この機胜を甚いおアップロヌドするファむル名に日時を含めるこずで、予期せぬ䞊曞きを防ぐずずもに送信時間を把握しやすくなりたす。 実際に私が提案したサヌビスにもこの機胜を䜿甚したした。 詳しくは 5. IoT Connect Gatewayの蚭定 ず 6. Amazon Web Services䞊での画像認識 をご芧ください。 2. 新サヌビスの提案 むンタヌン䞭では、"ICGWの「Storage転送機胜」を利甚した新サヌビスを考える"ずいう課題に挑戊させおいただくこずになりたした。 以䞋が、私の提案したサヌビス抂芁ずなりたす。 図3 提案したサヌビスの抂芁 今回考案した遠隔監芖システムは倧きく3぀の特城がありたす。 1぀目は、需芁の高いシステムであるずいうこずです。昚今のCovid-19の流行や劎働者䞍足により、少人数で広範囲をリアルタむムで監芖できるシステムはあらゆる分野で求められおいるず考えられたす。 2぀目は、通信量を少なく抑えられるような蚭蚈になっおいるこずです。動䜓を怜出したずきの画像のみを送信する仕組みずなっおいるため、そのたた動画を送るより圧倒的に少ない通信量で運甚できたす。 3぀目は、他の甚途に応甚しやすいこずです。動䜓怜出を利甚しおいるため監芖だけでなく、亀通量・歩行量調査や生態系の調査ずいった研究の分野での䜿甚も想定できたす。 3. 開発環境 システムの開発環境は以䞋の通りです。 機材、端末 MacBookPro(13-inch, M1, RAM 16GB) RaspberryPi Zero W V1.1 RaspberryPi Camera Rev 1.3 無線LANルヌタ(NEC Aterm MP02LN CW) 利甚サヌビス IoT Connect Gateway Dashboard Amazon Simple Storage Service (S3) Amazon Web Services Lambda Amazon Rekognition Amazon CloudWatch 4. カメラの開発 RaspberryPiずRaspberryPi Cameraを甚いお、動䜓怜知のためのカメラを開発したした。 図4 実際に䜿甚したRaspberryPiずRaspberryPi Camera 4.1 動䜓怜出および画像抜出 RaspberryPiにむンストヌルしたMotionずいう゜フトりェアを䜿っお、監芖察象をモニタリングし、動䜓怜出ず画像の抜出をしたした。 参考 https://www.handsonplus.com/electronic-works/how-to-use-motion-with-raspi/ 今回は被写䜓ずしお私の匟に協力しおもらいたした。 図5 モニタリング䞭の映像ず動䜓怜出した画像 4.2 画像デヌタの送信 続いお、Pythonを䜿っお各画像ファむルのデヌタを送信したす。 参考 https://www.handsonplus.com/electronic-works/how-to-use-motion-with-raspi/ 実際に䜿甚したPythonのコヌドは以䞋の通りです。 import os import time from glob import glob # 画像送信 def send_img (attachments): # ファむルを送信 for attachment in attachments: os.system( "curl -v -X PUT -H 'Content-Type: image/jpeg' --data-binary @" \ + attachment \ + " http://***:8081/s3" ) # メむン関数 def main (): while ( True ): # 画像ファむルを探す attachments = sorted (glob( './*.jpg' )) # 添付ファむル確認 if len (attachments) >= 1 : # 画像送信 send_img(attachments) time.sleep( 10 ) # 送信埌ファむル削陀 os.system( 'sudo rm *.jpg' ) time.sleep( 10 ) main() jpg圢匏の各画像ファむルを読み蟌み、それぞれに察しおcurlコマンドを実行するこずで送信の凊理を行いたす。 IoTデバむスのストレヌゞを圧迫しないように、送信し終わったファむルは削陀したす。 5. IoT Connect Gatewayの蚭定 次に、AWS S3にデヌタを送信するためのStorage転送機胜の蚭定をICGWのコン゜ヌル画面から行いたした。 以䞋が実際に投入した蚭定になりたす。 図6 Storage転送機胜の蚭定 今回はFilepathに"$YYYY"や"$kk"ずいうプレヌスホルダヌを蚭定しおいたす。これによりデヌタが送信された際に、ICGWの機胜によっおその時の日時デヌタを埋め蟌めるようになっおいたす。 この機胜を掻甚するこずで、動䜓を怜出した時間が明蚘されるだけでなく、ICGW偎で䞀元的に日時デヌタを管理ができたす。 6. Amazon Web Services䞊での画像認識 次に、AWS䞊で画像認識凊理をできるように蚭定したした。 今回はS3・Lambda・Rekognition・CloudWatchの4぀の機胜を連携させたした。 6.1 S3䞊のファむル S3ずは、AWSのクラりドストレヌゞサヌビスです。 図7 S3䞊のファむル たずIoTデバむスからICGW経由でS3に画像ファむルが送られおきたす。送信されたファむル名は、 5. IoT Connect Gatewayの蚭定 で蚭定したように送信日時ずなっおいるこずが確認できたす。 6.2 LambdaずRekognitionによる画像認識凊理 S3に送られた画像は、LambdaずRekognitionによっお画像認識凊理されたす。 Lambdaずは、サヌバヌレスでプログラムを実行できるサヌビスです。 図8 Lambdaでの凊理 今回䜿甚したLambdaは、トリガヌをS3の送信先のディレクトリに蚭定しおいるので、画像が送られおくるずLambda䞊の関数が自動で実行されるようになっおいたす。 関数の凊理の流れは䞊蚘のフロヌチャヌトの通りです。 Lambdaでは送られおきた画像に察しお、Rekognitionを甚いお画像を解析した埌に結果を出力したす。 参考 https://acro-engineer.hatenablog.com/entry/2018/12/12/120000 以䞋が、実際に䜿甚したLambda䞊の関数の゜ヌスコヌドです。 import os import boto3 s3 = boto3.resource( 's3' ) def lambda_handler (event, content): # S3にアップされた画像の情報を取埗する。 bucket_name = event[ 'Records' ][ 0 ][ 's3' ][ 'bucket' ][ 'name' ] object_key = event[ 'Records' ][ 0 ][ 's3' ][ 'object' ][ 'key' ] file_name = os.path.basename(object_key) print ( "bucket_name=" + bucket_name) print ( "object_key=" + object_key) print ( "file_name=" + file_name) # 画像をRekognitionで解析する。 rekognition = boto3.client( 'rekognition' ) response = rekognition.detect_labels(Image={ 'S3Object' : { 'Bucket' : bucket_name, 'Name' : object_key } }) print (response) 6.3 CloudWatchでの画像認識結果の確認 画像認識の結果はCloudWatchで確認できたす。 図9 CloudWatch䞊の画像認識結果 結果はログずしお衚瀺されるため少しわかりにくいですが、ラベル・確信床・察象物の頂点座暙などが出力されたす。 䞊蚘のログは䞀぀の画像に察する画像認識結果です。 赀枠で囲たれた所には、"ラベルがPersonでその確信床が玄97.4%"であるオブゞェクトを認識できた旚が曞かれおいたす。 ぀たり、動䜓の正䜓ずしお人間の存圚を認識したこずを意味したす。 7. 画像認識結果の可芖化 画像認識結果がログのたたではわかりにくかったので、可芖化しおみたした。 図10 画像認識結果の可芖化 本来はLambda䞊で可芖化凊理たで行おうず考えおいたしたが、時間が足りなかったため、手元の怜蚌端末にむンストヌルしたOpenCVを甚いたした。 参考 https://acro-engineer.hatenablog.com/entry/2018/12/12/120000 以䞋に、可芖化凊理で䜿甚したプログラムの゜ヌスコヌドを瀺したす。 from urllib import response import cv2 # 加工するファむルの名前を代入 filename = '2022-23-123902.jpg' # CloudWatchでの画像認識結果を代入 response = { 'Labels' : [{ 'Name' : 'Clothing' , 'Confidence' : 99.97942352294922 , 'Instances' : [], 'Parents' : []}, { 'Name' : 'Apparel' , 'Confidence' : 99.97942352294922 , 'Instances' : [], 'Parents' : []}, { 'Name' : 'Suit' , 'Confidence' : 99.97110748291016 , 'Instances' : [], 'Parents' : [{ 'Name' : 'Overcoat' }, { 'Name' : 'Coat' }, { 'Name' : 'Clothing' }]}, { 'Name' : 'Overcoat' , 'Confidence' : 99.97110748291016 , 'Instances' : [{ 'BoundingBox' : { 'Width' : 0.47841206192970276 , 'Height' : 0.8942648768424988 , 'Left' : 0.18658344447612762 , 'Top' : 0.05319703370332718 }, 'Confidence' : 81.37818908691406 }], 'Parents' : [{ 'Name' : 'Coat' }, { 'Name' : 'Clothing' }]}, { 'Name' : 'Coat' , 'Confidence' : 99.97110748291016 , 'Instances' : [], 'Parents' : [{ 'Name' : 'Clothing' }]}, { 'Name' : 'Person' , 'Confidence' : 98.30304718017578 , 'Instances' : [{ 'BoundingBox' : { 'Width' : 0.42601126432418823 , 'Height' : 0.9695423245429993 , 'Left' : 0.21858000755310059 , 'Top' : 0.01187931653112173 }, 'Confidence' : 79.02320861816406 }], 'Parents' : []}, { 'Name' : 'Human' , 'Confidence' : 98.30304718017578 , 'Instances' : [], 'Parents' : []}, { 'Name' : 'Man' , 'Confidence' : 96.02997589111328 , 'Instances' : [], 'Parents' : [{ 'Name' : 'Person' }]}, { 'Name' : 'Standing' , 'Confidence' : 79.08413696289062 , 'Instances' : [], 'Parents' : [{ 'Name' : 'Person' }]}, { 'Name' : 'Face' , 'Confidence' : 64.02348327636719 , 'Instances' : [], 'Parents' : [{ 'Name' : 'Person' }]}, { 'Name' : 'Tuxedo' , 'Confidence' : 56.30610656738281 , 'Instances' : [], 'Parents' : [{ 'Name' : 'Suit' }, { 'Name' : 'Overcoat' }, { 'Name' : 'Coat' }, { 'Name' : 'Clothing' }]}], 'LabelModelVersion' : '2.0' , 'ResponseMetadata' : { 'RequestId' : '***' , 'HTTPStatusCode' : 200 , 'HTTPHeaders' : { 'x-amzn-requestid' : '***' , 'content-type' : 'application/x-amz-json-1.1' , 'content-length' : '1427' , 'date' : 'Wed, 23 Feb 2022 12:39:04 GMT' }, 'RetryAttempts' : 0 }} # CV2で画像ファむルを読み蟌む。 np_image = cv2.imread(filename) height, width = np_image.shape[: 2 ] # ラベルの䞭から人ず思われるものを探しお四角で囲う。 for label in response[ 'Labels' ]: if label[ 'Name' ] not in [ 'People' , 'Person' , 'Human' ]: continue for person in label[ 'Instances' ]: box = person[ 'BoundingBox' ] x = round (width * box[ 'Left' ]) y = round (height * box[ 'Top' ]) w = round (width * box[ 'Width' ]) h = round (height * box[ 'Height' ]) cv2.rectangle(np_image, (x, y), (x + w, y + h), ( 0 , 0 , 255 ), 3 ) cv2.putText(np_image, label[ 'Name' ], (x, y - 9 ), cv2.FONT_HERSHEY_SIMPLEX, 1.5 , ( 255 , 255 , 255 ), 3 ) cv2.imwrite(filename + '_result.jpeg' , np_image) CloudWatchの出力ログから人間を衚すラベルの頂点座暙を抜き出し、その情報を基に䜜成したバりンディングボックスを元画像に貌り぀けるずいう流れの凊理を行いたした。 むンタヌンシップを終えた感想 最埌に、本むンタヌンシップを通しお感じたこずをたずめたす。 1. 自力で調べる力の重芁性を再確認できた RaspberryPiやICGW、AWS、Macは私にずっお觊れたこずすらないものであり、2週間ずいう短い期間でそれらすべおを扱うためには、自分で自発的に調べるこずがずおも重芁だず改めお実感したした。 たた、特にIT業界は短いスパンで新しい技術が登堎する倉化の目たぐるしい業界であるこずからも、自力で調べる力は垞に意識しお䌞ばしおいきたいず思いたした。 2. 倧孊での孊びに察するモチベヌションが埗られた むンタヌンシップに参加するたでは、倧孊で孊んだこずがどのように仕事に掻かされるのかむメヌゞできたせんでした。 特にサヌクルでのロボット補䜜は、"あくたでサヌクル掻動でお遊びである"ずいう意識があり、自分がしおきた掻動に自信を持おないこずがありたした。 しかし、実際に業務内容を経隓させおいただいたこずで、倧孊での自分の掻動が確かに仕事に結び぀くず実感でき自信に぀ながったずずもに、これからの倧孊での孊びに察する絶倧なモチベヌションを獲埗できたず感じおいたす。 3. チヌム開発における"良い雰囲気"を実感できた むンタヌンシップに参加するこずが決たったずき、技術面・経隓面でも未熟な倧孊2幎の自分が、瀟員の方々にご迷惑をかけずにしっかり業務をこなせるのか非垞に心配でした。しかし、チヌムメンバヌの方々は緊匵しお硬くなった私をアットホヌムな雰囲気で暖かく迎えおくださったおかげで、楜しく仕事ができたした。 特に、私が自力ではどうしおも解決できない問題に盎面した際、気兌ねなく質問できるようにしおくださいたした。 ICGW開発チヌムの方々からは、技術だけでなく、チヌム開発をするうえで倧切なチヌム内の雰囲気がどのようなものであるかを身をもっお孊ばせおいただきたした。 2週間ずいう短い間でしたが倧倉お䞖話になりたした。ありがずうございたした トレヌナヌからのコメント 小林さんのトレヌナヌを務めたICGWチヌムの岩田です。 今回のむンタヌンシップでは、ICGWのStorage転送機胜を䜿っお新芏サヌビス提案に取り組んでいただきたした。RaspberryPiやICGW、AWSずいった小林さんにずっおあたり銎染みのない技術領域が倚かったかもしれないですが、その䞭でも自分なりのりィルを持っお取り組む姿勢は印象的でした。たた、倧孊2幎生ながらもすでに倧孊での勉孊の意矩や将来を芋据えおおり、玠晎らしい姿勢だず感心したした。今埌もその姿勢を倧切に、孊業やロボコンに打ち蟌んでいただけたらず思いたす。このむンタヌンで埗られた経隓を今埌の小林さんの倧孊生掻に圹立おおもらえるず我々も嬉しいです 2週間お疲れ様でした
はじめに はじめたしお。むノベヌションセンタヌ所属の @sublimer です。 2021幎4月に新卒ずしお入瀟し、珟圚はWebRTCプラットフォヌム 「SkyWay」 の開発・運甚の業務に取り組んでいたす。 たた、個人開発ずしおWebアプリケヌションを䜜ったり、TURNサヌバヌ(RFC5766)をC#で実装したりしおいたす。 他にも、自宅サヌバを運甚したり、ネットワヌク機噚を觊っおみたりもしおいたす。 ちなみに掚しRFCは RFC1149 です。 今回は、珟圚 SkyWay Beta ずしお提䟛䞭の新しいSkyWayのサヌビス監芖機胜を構築した話を玹介したす。 SkyWayのサヌビス監芖における課題 たずはじめに、珟行のSkyWayが抱えおいたサヌビス監芖の課題に぀いお説明したす。 珟圚のサヌビス監芖には、以䞋の3぀の課題がありたした。 VMを管理するコスト 障害発生時の架電 ログ調査の手間 1. VMを管理するコスト 珟行のSkyWayでは、管理甚のVM䞊で Zabbix を動かしおサヌビス監芖を行っおいたす。 Zabbixは非垞に優れた監芖甚゜フトりェアですが、VMを管理する手間がかかるほか、監芖サヌバヌのメンテナンスをしおいる間はサヌビスの監芖ができないずいう課題がありたした。 2. 障害発生時の架電 珟行のSkyWayでは、瀟内の監芖チヌムが障害時の状況把握や関係者ぞの連絡ずいった䞀次察応などを行っおいたした。 新しいSkyWayでは、人に頌らず電話をかける仕組みを導入し、障害発生時の察応を自動化・省力化するこずずなりたした。 Zabbixには、障害発生時に電話をかけるような機胜は無いため、䜕らかのSaaSず連携させる必芁がありたした。 3. ログ調査の手間 SkyWayのアクセスログ・アプリケヌションログは、 Fluentd を甚いお Google Cloud Storage(GCS) にアップロヌドされる仕組みずなっおいたす。 ログ調査を行う際は、GCSから該圓のログをダりンロヌドし、手元のマシンでgrepしお調査しおいたす。 調査の際は耇数のVMのログを暪断的に調査したい堎合もあり、その郜床ログをダりンロヌドしお調査するのはかなり手間がかかっおいたした。 以䞊の課題を螏たえ、いく぀かのSaaSやOSSを比范怜蚎した結果、 Datadog 、 PagerDuty 、 Google Cloud Logging を甚いお、新しいSkyWayのサヌビス監芖を行うこずにしたした。 䜿甚した各SaaSの圹割 今回䜿甚した各SaaSに぀いお、その圹割を簡単に説明したす。 Datadog VMのCPU䜿甚率やメモリ䜿甚量ずいった時系列の数倀デヌタ、「メトリクス」を収集したす。 たた、事前に蚭定した条件を満たした堎合はアラヌトずしお通知したす。 メトリクスは、VMにむンストヌルしたDatadog Agentから定期的に送信されるほか、Web APIを呌び出すこずで、任意のデヌタを蚘録するこずもできたす。 PagerDuty DatadogやGoogle Cloud Loggingず連携させ、アラヌトの内容をモバむルアプリや電話で通知したす。 予めオンコヌルシフトや゚スカレヌションポリシヌを蚭定するこずで、柔軟な通知が実珟できたす。 たた、誰が障害察応したのか、どういった察応をしたのかずいった情報を蚘録でき、障害察応の振り返りに圹立おるこずもできたす。 Google Cloud Logging ログを集玄・転送する゜フトりェアであるFluentdから送られたアプリケヌションログやアクセスログを蚘録したす。 ログを構造化しおおくこずで、Google Cloud Loggingで柔軟にフィルタリング・怜玢ができたす。 たた、耇数のVMのログを䞀箇所に集玄できるため、暪断的にログを怜玢できたす。 構築したサヌビス監芖の党䜓像 アラヌト通知のフロヌは、以䞋の図のように蚭定しおいたす。 もし、メトリクスやログの内容に異垞があれば、PagerDutyにアラヌトの情報が送られ、モバむルアプリや電話経由で通知が行われたす。 基本的には、たずアプリ経由で通知し、䞀定時間アクションがない堎合に電話をかけるようにしおいたす。 䞀方で、サヌビスの運甚に臎呜的な圱響を䞎えるアラヌトに関しおは、即座に電話をかけるように蚭定しおいたす。 これにより、DevOpsチヌムが即座に障害の察応ができるようになりたした。 たた、メトリクスのグラフを共有するために、DatadogからSlackぞの通知も蚭定しおいたす。 以前はZabbixのスクリヌンショットを手動で撮圱しおSlackに共有しおいたしたが、DatadogずSlackの連携蚭定により、 スラッシュコマンド などで手軜にグラフ画像の共有ができるようになりたした。 さらに、メトリクスずアラヌトの情報を玐付けお衚瀺するダッシュボヌドを䜜るこずで、障害時の各皮メトリクスの状態を確認しやすくなりたした。 DatadogのカスタムAgentチェックを効率的に開発する 今回Datadogを導入した際に埗られたtipsを共有したす。 Datadogでは、デフォルトでCPU䜿甚率やメモリ䜿甚量などのメトリクスを送信できたすが、実際のサヌビス監芖を行う際は、これらのメトリクスだけではカバヌしきれない堎合がありたす。 その堎合は、カスタムAgentチェックのスクリプトを䜜成するこずで、任意の倀をメトリクスずしお送信できたす。 カスタムAgentチェック甚のスクリプトの動䜜確認にはDatadog Agentをむンストヌルする必芁があるのですが、このむンストヌルの手間を枛らすため、 Docker Composeを甚いお動䜜確認ができる仕組みを䜜りたした。 以䞋のコマンドでPythonの仮想環境を䜜成し、カスタムAgentチェックのスクリプトを ./src/custom_example.py に、蚭定ファむルを ./conf.d/custom_example.yml 蚘述したす。 $ python -m venv venv $ . ./venv/bin/activate $ pip install datadog-checks-base ./src/custom_example.py import random from datadog_checks.base import AgentCheck __version__ = "1.0.0" class CustomExample (AgentCheck): def check (self, instance): self.gauge( "custom_example.value" , random.randint( 0 , 10 ), tags=[ "env:dev" ], ) ./conf.d/custom_example.yml instances : [{}] その埌、以䞋の docker-compose.yml を甚いおDockerコンテナを起動したす。 version : '3' services : agent : image : datadog/agent volumes : - ./src:/etc/datadog-agent/checks.d - ./conf.d:/etc/datadog-agent/conf.d environment : - DD_API_KEY=dummy-api-key DD_API_KEY の環境倉数を蚭定しないずDatadog Agentが起動しないため、ダミヌの文字列を入れおいたす。 Dockerコンテナが起動した埌、ホスト偎で以䞋のコマンドを実行するこずで、容易にスクリプトの動䜜確認ができたす。 $ docker-compose exec agent agent check custom_example --table === Series === METRIC TYPE TIMESTAMP VALUE TAGS custom_example.value gauge 1646983404 5 env:dev ========= Collector ========= Running Checks ============== custom_example (1.0.0) ---------------------- Instance ID: custom_example:d884b5186b651429 [OK] Configuration Source: file:/etc/datadog-agent/conf.d/custom_example.yml Total Runs: 1 Metric Samples: Last Run: 1, Total: 1 Events: Last Run: 0, Total: 0 Service Checks: Last Run: 0, Total: 0 Average Execution Time : 0s Last Execution Date : 2022-03-11 07:23:24 UTC (1646983404000) Last Successful Execution Date : 2022-03-11 07:23:24 UTC (1646983404000) おわりに 新しいSkyWayでのサヌビス監芖の抂芁ずtipsを玹介したした。 元々孊生時代からむンフラの監芖技術に興味があり、自宅サヌバヌなどでZabbixや Prometheus を䜿っおいたしたが、商甚サヌビスの監芖に関わる機䌚は無く、入瀟前から商甚サヌビスの監芖に挑戊しおみたいず思っおいたした。 そのこずを䞊長ずの1on1で話したずころ、SkyWayのサヌビス監芖に぀いお怜蚌や構築を任せおいただけたした。新入瀟員であっおもいろいろなこずに挑戊できるSkyWayのチヌムは、ずおも居心地が良いなず思っおいたす。 今回、䞀からサヌビス監芖の仕組みを䜜りたしたが、新しいSkyWayのサヌビス監芖は始たったばかりです。 最匷で最高のサヌビス監芖䜓制を目指しお、匕き続き改善に取り組んでいきたいず思いたす。 最埌に少しだけ宣䌝です。 珟圚提䟛䞭の SkyWay Beta は、アカりント登録をするだけで、個人・法人問わずどなたでも䜿うこずができたす。 これたでのSkyWayには無かった機胜も今埌実装される予定ですので、ぜひ䞀足早く䜓隓しおみおください! フィヌドバックなどもお埅ちしおいたす!! 参考サむト カスタム Agent チェック Datadog Docs
はじめに こんにちは、むンタヌンシップ生の 金谷 です。 2022幎2月に2週間ほどNTTコミュニケヌションズのむンタヌンシップに参加させおいただきたした。 普段は倧孊院やWIDEプロゞェクト、アルバむトなどで SRv6 BGP-EPEなどオヌバレむネットワヌク技術の研究開発をしおいたす。 むンタヌンシップには「 次䞖代のサヌビスを生み出す怜蚌網 Testbedの蚭蚈構築業務 」ずいうテヌマで、2022幎2月14日から25日たでの2週間参加したした。 具䜓的にはFRRoutingFRRずいうOSSの゜フトりェアルヌタにBGP-LSずいう機胜を実装するずいう内容に取り組みたした。 この蚘事では、その䜓隓談を蚘茉したす。 むンタヌンシップに参加するたで NTT Comずいう䌚瀟に非垞に興味を持っおいたため、䌚瀟の雰囲気を知りながら面癜い開発が出来そうだず思い、参加を決めたした。 たた、むンタヌンシップを通じお入瀟埌どのプロゞェクトに所属するかの参考にしたいず思ったのも参加を決めた理由の1぀です。 むンタヌンシップで取り組んだこず むンタヌンシップでは、䞻にFRRずいうOSSの゜フトりェアルヌタにBGP-LSの機胜を远加し、耇数のメヌカヌの機噚Cisco、Juniperず盞互接続できるよう実装に取り組みたした。 珟圚NTT Comでは倧芏暡なMulti-AS Segment RoutingSR網の構築、運甚を行なっおおり、その網䞊で効率的な経路制埡を実珟するためPath Computation ElementPCEによるコントロヌラ制埡を目指しおいたす。 Multi-AS SR網はマルチベンダに構成されおおり、SRv6環境の䞀郚では拡匵性を考慮しOSSのFRRを採甚しおいたす。 このFRRをコントロヌラ制埡の察象に含めるため、FRRにBGP-LSの機胜を実装し、トポロゞ情報をコントロヌラに送信するこずが求められおいたす。 たた、Multi-ASの環境ではASの接続郚分でBGP-EPEを行いたいずいう芁求もあり、BGP-EPEの情報をBGP-LSで広告できるこず( RFC9086 , draft-ietf-idr-bgpls-srv6-ext-09 )なども鑑みお、BGP-LSは今埌必芁な機胜であるず考えられおいたす。 私はBGP-LSずいうプロトコルの名前は知っおいたしたが、现かい内容に぀いおは知らなかったため、始めはプロトコルの理解を目的ずしお RFC7752 , 9085 などを読み蟌んでいきたした。 次にFRRの開発も少しかじったこずはありたしたが、BGPに぀いおの開発は初めおでしたので、どのファむルを読めば良いのかが分からず、printデバッグをしながら手探りでFRRの構成を読み解いおいきたした。 最終的にはFRRにBGP-LSのOpenメッセヌゞを実装し、IOS-XRやJunosずの間でBGPのステヌトをEstablishedさせるこずができたした。 以䞋では、BGP-LSの機胜や必芁性、むンタヌンシップでの開発内容を具䜓的にご玹介したす。 BGP-LSずは BGP-LSずはBGP Link Stateの略称で、IGPのリンクステヌト情報や、トラフィック゚ンゞニアリングTE情報を䌝達するためのプロトコルです。 BGP-LSを利甚すれば、耇数のIGPドメむンのトポロゞ情報をPCE等のコントロヌラに収集するこずが容易ずなるため、NTT Comが珟圚怜蚌を進めおいるSegment Routingを甚いたMulti-AS TEに掻甚できるず考えられたす。 䞊図にPCEのナヌスケヌスを瀺したす。PCEはPEからBGP-LSによっおトポロゞ情報を吞い䞊げお経路を蚈算し、PCEPでPEに経路を配垃したす。 これにより、発行枈みの経路を䞀元管理できるようになるず共に、垯域や信頌性など経路の状態を考慮した耇雑なTEが行えるようになり、効率的な運甚を実珟できたす。 FRRの構造 FRRouting ずは、LinuxやBSDなどの䞊で動くOSSの゜フトりェアルヌタです。 以䞋の図がFRRの基本構造ずなっおいたす。 FRRはLinux Server䞊で動くアプリケヌションずなっおおり、vtyshでナヌザの操䜜をCLIで取埗し、その情報をisisdなどのプロトコルデヌモンに送信したす。 isisdにはLink State DatabaseLSDBが存圚し、IS-ISずいうIGPプロトコルによっお亀換された各Link State情報が栌玍されおいたす。 このLSDBの情報をpathd内に存圚するTraffic Engineering DatabaseTEDにZAPIを利甚しおZebra経由で゚クスポヌトし、TEDの情報を元にbgpdがBGP Databaseを倉曎したす。 そしお、bgpdがBGP-LSにより他のルヌタずの間でBGP Databaseずの情報を共有したす。 ネットワヌクスタックの利甚にあたっおは、ZebraがNetlinkを利甚しおナヌザ空間の情報をカヌネル空間に䌝達するこずで行われたす。 実装内容 BGP-LSによっおLink State情報を耇数ルヌタ間で亀換するためには、前提ずしおルヌタ間でBGP-LSの接続を確立しおいなければなりたせん。BGP-LSの接続を確立するためには、以䞋の手順が必芁ずなりたす。 察象ずなるBGPスピヌカ同士でTCPセッションを確立する BGP-LSを瀺すCapabilityの含たれたBGP Openメッセヌゞを送信/受信する BGP Keep Aliveメッセヌゞを受信する これらを行うこずにより、BGPが確立されたステヌトずなり、BGP-LSのUpdateメッセヌゞにより実際にBGP-LSのLink State情報を盞互に亀換し合うこずができるようになりたす。 䞊蚘の手順をもう少し厳密に蚘述するず以䞋の図のようになりたす。 今回私はむンタヌンシップ期間でBGP-LSが既に実装されおいるIOS-XRやJunosず、新たに実装を远加したFRRずの間でBGP-LSのEstablishedを実珟したした。 初めに、FRRにはBGP-LSのAFIやSAFIが定矩されおいなかったため、RFCに準拠した定矩を実斜したした。この際、Zebraの認識するAFI/SAFIずIANAによっお定矩されおいるAFI/SAFIの倀が異なるため、倉換蚭定も必芁ずなりたす。 続いお、TCP connectionがOpenになるず、BGPのステヌトはConnectに遷移し bgp_reads_on() ず bgp_open_send() ずいう2぀の関数が呌ばれたす。 bgp_reads_on() では、BGP Openメッセヌゞを受信するず適切にパヌスし、ピアから受信したOpenメッセヌゞの情報を構造䜓に栌玍したす。 bgp_open_send() では、Openメッセヌゞをピアに送信したす。 これら2぀の関数は非同期に実行されたす。 bgp_open_send() 関数が呌ばれた際はOpen Sentステヌトに遷移し、 bgp_open_send() ず bgp_reads_on() の双方が行われた際にはOpen Confirmステヌトに遷移したす。 あずは既存のBGP Keep Aliveメッセヌゞによっお自動でEstablishedステヌトぞず遷移するこずずなりたす。 結果 以䞋がFRR偎でBGP-LSのステヌトを衚瀺させた結果です。 Stateが (Policy) ずなっおいたす。 これはBGPステヌトがEstablishedか぀、Export Filterがないずいう意味であるため、想定通りBGP-LSがEstabsliehdになっおいるこずが確認できたした。 たた、以䞋がIOS-XRやJunos偎でBGP-LSのステヌトを衚瀺させた結果です。 こちらも双方でBGPステヌトが Established ずなるこずが確認できたした。 本むンタヌンでは期間の関係でLSDBのExport機胜や関連するshowコマンドの実装たではできたせんでしたが、FRRずのコントロヌラ連携の実珟を目指し、今埌も開発を進めお行きたす。 むンタヌンシップの感想 2週間で名前皋床しか知らないプロトコルの調査から始め、珟圚のBGP-LSの実装状況の調査やむンタヌンシップのゎヌルをどこに眮くかを考え、 ゎヌルを実珟するために1000行以䞊の゜ヌスコヌドを読み必芁な箇所に機胜を远加しおいくずいう経隓は、環境構築や倚数のファむルを行き来するコヌド理解など倧倉な郚分もありたしたが最終的には非垞に楜しかったです。 メンタヌの䞉島さんには頻繁に盞談に乗っおいただき、そこでプロトコルやFRRの抂念の理解の補助をしおいただいたり、 ゜ヌスコヌドを読んでいお詰たった時のネクストアクションを提瀺しおくださったりなど、僕がむンタヌンシップを完走出来るよう最倧限フォロヌしおいただいたこずを倧倉感謝しおいたす。 フルオンラむンのむンタヌンでしたが、業務以倖でむンタヌンシップの配属チヌムの瀟員さんずオンラむンでお酒を飲みながらお話をしお、チヌムの雰囲気を知れる堎を甚意しおくださったり、 自分が興味のある別チヌムの方ずミヌティングをセッティングしお業務内容を聞く䌚を開催しおくださったりず、 むンタヌンシップを通じお入瀟埌のむメヌゞを掎むための堎を最倧限提䟛しおくださったこずを倧倉感謝しおいたす。 最埌になりたすが、本むンタヌンシップでたくさんの貎重な経隓をさせおいただき本圓にありがずうございたした。 メンタヌからのコメント メンタヌを担圓したむノベヌションセンタヌの䞉島です。2週間のむンタヌンシップお疲れ様でした。 初日の説明日・最終日の成果報告日や祝日を陀くず1週間に満たない䜜業日でしたが、 NTT Comの背景理解ずテヌマ蚭定から始たり、プロトコルのRFC調査を通じた理解やFRRのコヌドリヌティングず実装、怜蚌環境構築や盞互接続詊隓たで怜蚌業務を䞀連で進めおいただきたした。 応甚的なルヌティングプロトコルの機胜開発ずいう難易床の高いテヌマであったにも関わらず、調査から怜蚌たでを自ら進めお成果を出しおいただけたこず、ずおも嬉しく思っおいたす。 珟圚NTT Com むノベヌションセンタヌではMulti-AS SRずいう独自の倧芏暡SR網を運甚しおおり、BGP-LSはコントロヌラ連携による効率的な運甚のための重芁な技術です。 今埌も開発を続け、是非FRRぞのコントリビュヌションなど、曎なる成果をあげられればず考えおいたす。 より面癜いネットワヌクを実珟し䟡倀を提䟛できるよう、我々も頑匵りたす 今回のむンタヌンシップで埗た経隓が、今埌の金谷さんの研究や取り組みに圹立おば幞いです。 改めお、むンタヌンシップぞの参加ずご掻躍ありがずうございたした
はじめに こんにちは、むノベヌションセンタヌの鈎ヶ嶺です。 engineers.ntt.com engineers.ntt.com 第1回、第2回に匕き続きAWS Outposts ラックに぀いお玹介しおいきたす。 本蚘事では、 Terraform  を甚いおOutposts䞊でオンプレ環境からのみ管理・アクセス可胜なPrivate Elastic Kubernetes Service(EKS) を構築する方法を玹介したす。 Terraform Terraformずは、 HashCorp が提䟛するむンフラをコヌド化しお自動構築を可胜ずするInfrastructure as Code(IaC)を実珟するためのツヌルです。OutpostsをTerraformでIaC化するためには、察応した各リ゜ヌスに outpost_arn を枡すこずでOutposts䞊のリ゜ヌスが䜜成されたす。 以䞋はsubnetの䞀䟋です。 1 resource "aws_subnet" "main" { vpc_id = aws_vpc.main.id cidr_block = "10.0.3.0/24" outpost_arn = "arn:aws:outposts:ap-northeast-1:1234567890:outpost/op-1234567890" } outpost_arn - (Optional) The Amazon Resource Name (ARN) of the Outpost. CDKず比范しおTerraformはAWS APIを利甚しおいるのでOutpostsのリ゜ヌスは比范的察応されおいるず思われたす。今埌新しいリ゜ヌスがOutpostsで利甚可胜になった堎合も察応スピヌドは早いず予想されたす。ただ䞀方で、CDKのような高レベルなリ゜ヌス䜜成をするこずが難しいのでリ゜ヌスやAPIの仕様を把握する必芁がありたす。たたリ゜ヌスの認蚌情報・状態管理なども考える必芁がありたす。 オンプレ環境䞊でマネヌゞドk8sサヌビスを構築するアヌキテクチャ 䞊蚘のようなオンプレ環境においおもマネヌゞドk8sサヌビスを利甚するアヌキテクチャを構築したす。Outposts䞊にAuto Scale Groupを蚭眮しおセルフマネヌゞド型ノヌドずしおそれぞれEC2をEKS Clusterに登録させたす。Outpostsずオンプレ環境ずの通信は党おLocal Gateway経由で接続されたす。 この構成の特城ずしおEKS ClusterのAPIサヌバをPrivateアクセスのみ蚱可するこずで、Bastion(螏み台)経由でのみクラスタの操䜜を可胜ずするセキュアな点が挙げられたす。さらに、アプリケヌションもオンプレ環境のみからアクセス可胜なため瀟内にのみ公開する秘匿性の高いシステムを構築できたす。 実装 以䞋のような構成で、それぞれのtfファむルにリ゜ヌスを定矩したす。 main.tf Providerや各倉数などの党䜓を蚘茉 network.tf ネットワヌクに関するものを蚘茉 eks_cluster.tf EKS Clusterに関するものを蚘茉 eks_node.tf EKS Nodeに関するものを蚘茉 security_group.tf Security Groupによる通信の蚱可に関するものを蚘茉 bastion.tf 螏み台サヌバに関するものを蚘茉 output.tf k8sアプリケヌションのデプロむ時に䜿甚するものを蚘茉 main.tf terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 3.0" } } } provider "aws" { region = var.region } # Name tag に䞀郚䜿甚する倀 variable "name" { default = "outposts-eks-sample" } # EKS Node のむンスタンス variable "instance_type" { default = "m5.large" } # EKS Node のdisk(GB) variable "disk_size" { default = 100 } variable "region" { default = "ap-northeast-1" } # EKS Node の望たしいノヌド数 variable "desired_node" { default = 3 } # EKS Node の最䜎ノヌド数 variable "min_node" { default = 3 } # EKS Node の最高ノヌド数 variable "max_node" { default = 3 } # Local Gateway経由からEKSにアクセス可胜なオンプレ環境のCIDR variable "local_cidr_blocks" { default = [ "192.168.0.0/16" ] } locals { # outpostのARN outpost_arn = "arn:aws:outposts:ap-northeast-1:1234567890:outpost/op-1234567890" # Local GatewayのID lgw_id = "lgw-1234567890" # Local GatewayのルヌトテヌブルのID lgw_rtb_id = "lgw-rtb-1234567890" # 顧客所有のIPアドレス customer_owned_ipv4_pool = "ipv4pool-coip-1234567890" # GPUを䜿甚しおいるかどうか gpu = replace (var.instance_type, "g4dn" , "!" ) != var.instance_type } # Bastion, EKS Nodeにアクセス可胜な鍵 resource "aws_key_pair" "key" { key_name = "$ { var.name } -key" public_key = file ( "~/.ssh/id_rsa.pub" ) } main.tfには AWS Provider ず各倉数、Bastionの鍵を蚭定したす。 OutpostsのARN outpost_arn や Local GatewayのID lgw_id などはここに蚭定しおおきたす。 Outposts䞊でもAuto Scaling groupは仕様可胜です。その蚭定に甚いおる max_node , min_node , desired_node の関係は次の画像のようになっおおりたす。 2 今回は3ノヌドの構成で䜜成したす。 network.tf resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" # VPC゚ンドポむントを有効にするためにdns hostnames, supportを蚭定 enable_dns_hostnames = true enable_dns_support = true tags = { Name = "vpc-$ { var.name } " } } # EKS Clusterのsubnet resource "aws_subnet" "cluster01" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" tags = { Name = "subnet-cluster01-$ { var.name } " } } # EKS Clusterのsubnet resource "aws_subnet" "cluster02" { vpc_id = aws_vpc.main.id cidr_block = "10.0.2.0/24" tags = { Name = "subnet-cluster02-$ { var.name } " } } # Outpostsのsubnet resource "aws_subnet" "outposts_subnet01" { vpc_id = aws_vpc.main.id cidr_block = "10.0.3.0/24" outpost_arn = local.outpost_arn availability_zone = "ap-northeast-1a" tags = { Name = "subnet-outposts-subnet01-$ { var.name } " "kubernetes.io/cluster/$ { aws_eks_cluster.main.name } " = "owned" "kubernetes.io/role/elb" = "1" } } # デフォルトルヌトをLocal Gatewayに蚭定 resource "aws_route_table" "local_gateway" { vpc_id = aws_vpc.main.id route { cidr_block = "0.0.0.0/0" local_gateway_id = local.lgw_id } tags = { Name = "local-gateway-route-table-$ { var.name } " } } resource "aws_route_table_association" "outposts_subnet01" { subnet_id = aws_subnet.outposts_subnet01.id route_table_id = aws_route_table.local_gateway.id } data "aws_ec2_local_gateway_route_table" "main" { outpost_arn = local.outpost_arn } resource "aws_ec2_local_gateway_route_table_vpc_association" "main" { local_gateway_route_table_id = data.aws_ec2_local_gateway_route_table.main.id vpc_id = aws_vpc.main.id } # EKS Nodeに蚭定するEIPのPool resource "aws_eip" "main" { count = var.max_node customer_owned_ipv4_pool = local.customer_owned_ipv4_pool tags = { Name = "eip-node-$ { count.index } " } } # Bastion(螏み台)のEIP resource "aws_eip" "bastion" { customer_owned_ipv4_pool = local.customer_owned_ipv4_pool tags = { Name = "eip-bastion-$ { var.name } " } } # 初期起動時にEKS Node自身がEIPを自ら蚭定するためのEC2゚ンドポむントを蚭定 resource "aws_vpc_endpoint" "ec2" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.$ { var.region } .ec2" vpc_endpoint_type = "Interface" subnet_ids = [ aws_subnet.outposts_subnet01.id ] security_group_ids = [ aws_security_group.vpc_endpoint_ec2.id, ] private_dns_enabled = true } network.tfにはネットワヌクに関するリ゜ヌスを定矩したす。 ネットワヌク構成ずしお、Public AWS䞊にsubnetを2぀、Outposts䞊にsubnetを1぀䜜成したす。OutpostsのsubnetにEKSのWorker Nodeが蚭眮されたす。基本的にOutpostsのsubnetはデフォルトルヌトをLocal Gatewayに蚭定するこずでむンタヌネットなどのアクセスはオンプレ環境経由で接続されるようにしたす。これにより瀟内のネットワヌクポリシヌの適甚や監芖などを可胜ずしたす。たた、Local Gatewayに接続するためには顧客所有のIPアドレスcustomer owned IP address(CoIP)をアタッチする必芁があるためEKS Node、Bastion甚のCoIPのElastic IP アドレス(EIP)を䜜成しおおきたす。 eks_cluster.tf # EKS Cluster resource "aws_eks_cluster" "main" { name = var.name role_arn = aws_iam_role.cluster_role.arn vpc_config { security_group_ids = [ aws_security_group.cluster.id ] subnet_ids = [ aws_subnet.cluster01.id, aws_subnet.cluster02.id ] # Private Accessのみに蚭定しおBastion経由でのみ操䜜する endpoint_public_access = false endpoint_private_access = true } depends_on = [ aws_iam_role_policy_attachment.eks_cluster_policy, aws_iam_role_policy_attachment.eks_service_policy, aws_iam_role_policy_attachment.eks_vpc_resource-controller, ] } resource "aws_iam_role" "cluster_role" { name = "eks-cluster-role-$ { var.name } " assume_role_policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF } resource "aws_iam_role_policy_attachment" "eks_cluster_policy" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy" role = aws_iam_role.cluster_role.name } resource "aws_iam_role_policy_attachment" "eks_service_policy" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSServicePolicy" role = aws_iam_role.cluster_role.name } resource "aws_iam_role_policy_attachment" "eks_vpc_resource-controller" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController" role = aws_iam_role.cluster_role.name } # ALBを䜿甚するためのIAM Policy resource "aws_iam_policy" "aws_load_balancer_controller" { name = "alb-policy-$ { var.name } " # from https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.2.1/docs/install/iam_policy.json policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAvailabilityZones", "ec2:DescribeInternetGateways", "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups", "ec2:DescribeInstances", "ec2:DescribeNetworkInterfaces", "ec2:DescribeTags", "ec2:GetCoipPoolUsage", "ec2:DescribeCoipPools", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeLoadBalancerAttributes", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeListenerCertificates", "elasticloadbalancing:DescribeSSLPolicies", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetGroupAttributes", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:DescribeTags" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "cognito-idp:DescribeUserPoolClient", "acm:ListCertificates", "acm:DescribeCertificate", "iam:ListServerCertificates", "iam:GetServerCertificate", "waf-regional:GetWebACL", "waf-regional:GetWebACLForResource", "waf-regional:AssociateWebACL", "waf-regional:DisassociateWebACL", "wafv2:GetWebACL", "wafv2:GetWebACLForResource", "wafv2:AssociateWebACL", "wafv2:DisassociateWebACL", "shield:GetSubscriptionState", "shield:DescribeProtection", "shield:CreateProtection", "shield:DeleteProtection" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupIngress" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:CreateSecurityGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws:ec2:*:*:security-group/*", "Condition": { "StringEquals": { "ec2:CreateAction": "CreateSecurityGroup" }, "Null": { "aws:RequestTag/elbv2.k8s.aws/cluster": "false" } } }, { "Effect": "Allow", "Action": [ "ec2:CreateTags", "ec2:DeleteTags" ], "Resource": "arn:aws:ec2:*:*:security-group/*", "Condition": { "Null": { "aws:RequestTag/elbv2.k8s.aws/cluster": "true", "aws:ResourceTag/elbv2.k8s.aws/cluster": "false" } } }, { "Effect": "Allow", "Action": [ "ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupIngress", "ec2:DeleteSecurityGroup" ], "Resource": "*", "Condition": { "Null": { "aws:ResourceTag/elbv2.k8s.aws/cluster": "false" } } }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateTargetGroup" ], "Resource": "*", "Condition": { "Null": { "aws:RequestTag/elbv2.k8s.aws/cluster": "false" } } }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:CreateListener", "elasticloadbalancing:DeleteListener", "elasticloadbalancing:CreateRule", "elasticloadbalancing:DeleteRule" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:AddTags", "elasticloadbalancing:RemoveTags" ], "Resource": [ "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*", "arn:aws:elasticloadbalancing:*:*:loadbalancer/net/*/*", "arn:aws:elasticloadbalancing:*:*:loadbalancer/app/*/*" ], "Condition": { "Null": { "aws:RequestTag/elbv2.k8s.aws/cluster": "true", "aws:ResourceTag/elbv2.k8s.aws/cluster": "false" } } }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:AddTags", "elasticloadbalancing:RemoveTags" ], "Resource": [ "arn:aws:elasticloadbalancing:*:*:listener/net/*/*/*", "arn:aws:elasticloadbalancing:*:*:listener/app/*/*/*", "arn:aws:elasticloadbalancing:*:*:listener-rule/net/*/*/*", "arn:aws:elasticloadbalancing:*:*:listener-rule/app/*/*/*" ] }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:SetIpAddressType", "elasticloadbalancing:SetSecurityGroups", "elasticloadbalancing:SetSubnets", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:ModifyTargetGroupAttributes", "elasticloadbalancing:DeleteTargetGroup" ], "Resource": "*", "Condition": { "Null": { "aws:ResourceTag/elbv2.k8s.aws/cluster": "false" } } }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:DeregisterTargets" ], "Resource": "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*" }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:SetWebAcl", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:AddListenerCertificates", "elasticloadbalancing:RemoveListenerCertificates", "elasticloadbalancing:ModifyRule" ], "Resource": "*" } ] } EOF } eks_cluster.tfでは、EKS Clusterに関するリ゜ヌスを定矩しおいたす。 ここでは、EKS ClusterのPrivate Accessを蚭定するこずで内郚からのみAPIサヌバにアクセス可胜ずなりたす。この蚭定をするこずでよりセキュアなk8s環境が実珟できたす。運甚の際にはBastion経由でkubectl, helmなどの操䜜をしたす。 eks_node.tf locals { # 初期起動時にEKS Node自身がEIPを自ら蚭定しおオンプレ環境に察しお通信する node_user_data = <<EOF #!/bin/bash set -o xtrace export AWS_DEFAULT_REGION=$ { var.region } instance_id=$(curl 169 . 254 . 169 . 254 /latest/meta-data/instance-id/) # EIP Check function function check_eip () { RES=`aws ec2 describe-addresses --filters Name=allocation-id,Values=$ 1 | jq .Addresses [ 0 ] .InstanceId` if [ "$RES" = "null" ] ; then return 0 fi return 1 } eips= "$ { join ( " " , aws_eip.main.*.id) } " # EIP Attach for eip in $eips; do check_eip $eip if [ $? = 0 ] ; then aws ec2 associate-address --no-allow-reassociation --instance-id $instance_id --allocation-id $eip if [ $? = 0 ] ; then break fi fi done # EKS Node Bootstrap /etc/eks/bootstrap.sh $ { aws_eks_cluster.main.name } EOF node_role_name = "node_role_$ { var.name } " } data "aws_ssm_parameter" "eks_cpu_ami" { name = "/aws/service/eks/optimized-ami/1.21/amazon-linux-2/recommended/image_id" } data "aws_ssm_parameter" "eks_gpu_ami" { name = "/aws/service/eks/optimized-ami/1.21/amazon-linux-2-gpu/recommended/image_id" } resource "aws_launch_template" "node_template" { name_prefix = "eks_sample_node_group_template" image_id = local.gpu == true ? data.aws_ssm_parameter.eks_gpu_ami.value : data.aws_ssm_parameter.eks_cpu_ami.value instance_type = var.instance_type vpc_security_group_ids = [ aws_security_group.node.id ] key_name = aws_key_pair.key.id block_device_mappings { device_name = "/dev/xvda" ebs { volume_size = var.disk_size } } iam_instance_profile { name = aws_iam_instance_profile.instance_role.name } tag_specifications { resource_type = "instance" tags = { Name = "eks-sample-node" } } user_data = base64encode (local.node_user_data) } # EKS NodeのAutoScaleGroup resource "aws_autoscaling_group" "node_group" { vpc_zone_identifier = [ aws_subnet.outposts_subnet01.id ] desired_capacity = var.desired_node max_size = var.max_node min_size = var.min_node health_check_type = "EC2" wait_for_capacity_timeout = "120m" launch_template { id = aws_launch_template.node_template.id version = "$Latest" } tag { key = "kubernetes.io/cluster/$ { aws_eks_cluster.main.name } " value = "owned" propagate_at_launch = true } } resource "aws_iam_role" "node_group_role" { name = "node-group-role-$ { var.name } " assume_role_policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF } resource "aws_iam_role_policy_attachment" "eks-worker-node-policy" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy" role = aws_iam_role.node_group_role.name } resource "aws_iam_role_policy_attachment" "eks-cni-policy" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy" role = aws_iam_role.node_group_role.name } resource "aws_iam_role_policy_attachment" "eks-container-registry-read-only" { policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly" role = aws_iam_role.node_group_role.name } resource "aws_iam_instance_profile" "instance_role" { name = local.node_role_name role = aws_iam_role.node_group_role.name } # EKS NodeにEIPをAttachするためのIAM Policy resource "aws_iam_policy" "eip_attach_policy" { name = "eip-attach-policy-$ { var.name } " policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeAddresses", "ec2:AssociateAddress" ], "Resource": "*" } ] } EOF } resource "aws_iam_role_policy_attachment" "eip_attach_policy" { role = aws_iam_role.node_group_role.name policy_arn = aws_iam_policy.eip_attach_policy.arn } # セルフマネヌゞド型ノヌドがEKSに登録されるための蚭定、BastionでのAPIサヌバに察するkubectl操䜜の蚱可蚭定 resource "local_file" "aws_auth" { content = <<EOF apiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - rolearn: $ { aws_iam_role.node_group_role.arn } username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: $ { aws_iam_role.bastion.arn } username: bastionrole groups: - system:masters EOF filename = "_aws-auth.yaml" } eks_node.tfでは、EKS Nodeに関するリ゜ヌスを定矩しおいたす。 Outposts䞊ではAuto Scale Groupの利甚が可胜なためその蚭定を定矩しおいたす。ここでの特城はAuto Scale Groupの各ノヌドに察しお user_data の䞭の凊理でCoIPを蚭定しおいるずころです。Auto Scale Groupには自動でEIPを蚭定が珟状できないため、この蚭定によりLocal Gateway経由でむンタヌネットやオンプレ環境ず通信するこずが可胜ずなりたす。 たた、 aws_auth ではBastionのRoleがAPIサヌバにアクセスするための蚭定ファむルを䜜成しおいたす。 security_group.tf resource "aws_security_group" "cluster" { vpc_id = aws_vpc.main.id name = "eks-cluster-security-group-$ { var.name } " tags = { Name = "eks-cluster-security-group-$ { var.name } " } ingress { from_port = 1025 to_port = 65535 protocol = "tcp" security_groups = [ aws_security_group.node.id ] } ingress { from_port = 443 to_port = 443 protocol = "tcp" security_groups = [ aws_security_group.node.id, aws_security_group.bastion.id ] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = [ "0.0.0.0/0" ] } } resource "aws_security_group" "node" { vpc_id = aws_vpc.main.id name = "eks-node-sg-$ { var.name } " tags = { Name = "eks-node-sg-$ { var.name } " } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = [ "0.0.0.0/0" ] } } resource "aws_security_group_rule" "node_ingress_443" { security_group_id = aws_security_group.node.id type = "ingress" from_port = 443 to_port = 443 protocol = "tcp" source_security_group_id = aws_security_group.cluster.id } resource "aws_security_group_rule" "node_ingress_1025_65535" { security_group_id = aws_security_group.node.id type = "ingress" from_port = 1025 to_port = 65535 protocol = "tcp" source_security_group_id = aws_security_group.cluster.id } resource "aws_security_group_rule" "node_ingress_localgateway" { security_group_id = aws_security_group.node.id type = "ingress" from_port = 0 to_port = 0 protocol = "all" cidr_blocks = var.local_cidr_blocks } resource "aws_security_group_rule" "node_ingress_self" { security_group_id = aws_security_group.node.id type = "ingress" from_port = 0 to_port = 0 protocol = "all" self = true } resource "aws_security_group" "vpc_endpoint_ec2" { vpc_id = aws_vpc.main.id name = "vpc-endpoint-ec2-sg-$ { var.name } " tags = { Name = "vpc-endpoint-ec2-sg-$ { var.name } " } ingress { from_port = 0 to_port = 0 protocol = "all" security_groups = [ aws_security_group.node.id ] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = [ "0.0.0.0/0" ] } } resource "aws_security_group" "bastion" { vpc_id = aws_vpc.main.id name = "bastion-sg-$ { var.name } " tags = { Name = "bastion-sg-$ { var.name } " } # オンプレ環境からのみアクセス可胜な蚭定にする ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = var.local_cidr_blocks } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = [ "0.0.0.0/0" ] } } security_group.tfにはSecurity Groupに関するリ゜ヌスを定矩したす。 こちらでは、EKSやオンプレ環境ずのSecurity Groupに぀いお蚭定されおいたす。 local_cidr_blocks に぀いおは適宜それぞれのオンプレ環境に適した蚭定が必芁ずなりたす。EKSに぀いおの詳现は次の公匏ドキュメントを参照しおください。 Amazon EKS セキュリティグルヌプの考慮事項 bastion.tf locals { # APIサヌバを操䜜するためのkubectl, helmなどの各皮ツヌルをむンストヌルする bastion_user_data = <<EOF #!/bin/bash set -o xtrace # install kubectl curl --retry 180 --retry-delay 1 -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin/kubectl # install helm curl -sSL https: //raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash EOF } data "aws_ssm_parameter" "amzn2_ami" { name = "/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2" } data "aws_iam_policy_document" "assume_role" { statement { actions = [ "sts:AssumeRole" ] principals { type = "Service" identifiers = [ "ec2.amazonaws.com" ] } } } resource "aws_iam_role" "bastion" { name = "bastion-role-$ { var.name } " assume_role_policy = data.aws_iam_policy_document.assume_role.json } # APIサヌバ認蚌のためのIAM Policy resource "aws_iam_policy" "bastion" { name = "bastion-policy-$ { var.name } " policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:UpdateClusterConfig", "eks:DescribeUpdate", "eks:DescribeCluster" ], "Resource": "$ { aws_eks_cluster.main.arn } " }, { "Effect": "Allow", "Action": [ "eks:ListClusters" ], "Resource": "*" } ] } EOF } resource "aws_iam_role_policy_attachment" "bastion" { role = aws_iam_role.bastion.name policy_arn = aws_iam_policy.bastion.arn } resource "aws_iam_instance_profile" "bastion" { role = aws_iam_role.bastion.name } resource "aws_instance" "bastion" { ami = data.aws_ssm_parameter.amzn2_ami.value subnet_id = aws_subnet.outposts_subnet01.id instance_type = var.bastion_instance_type key_name = aws_key_pair.key.key_name vpc_security_group_ids = [ aws_security_group.bastion.id ] iam_instance_profile = aws_iam_instance_profile.bastion.name user_data = local.bastion_user_data tags = { Name = "bastion-instance-$ { var.name } " } } resource "aws_eip_association" "bastion" { instance_id = aws_instance.bastion.id allocation_id = aws_eip.bastion.id } bastion.tfにはBastion(螏み台)に関するリ゜ヌスを定矩したす。 こちらでは、BastionにEKSのAPIサヌバを操䜜可胜ずするためのIAM Roleを蚭定しおいるこずがわかるず思いたす。たた通信もCoIPを蚭定しおオンプレ環境からのみ接続できるように蚭定したす。 output.tf output "cluster" { value = aws_eks_cluster.main.name } output "alb_arn" { value = aws_iam_policy.aws_load_balancer_controller.arn } output "region" { value = var.region } output "ip_pool" { value = local.customer_owned_ipv4_pool } output "vpc_cidr" { value = aws_vpc.main.cidr_block } output "bastion_ip" { value = aws_eip.bastion.customer_owned_ip } output.tfにはk8sアプリケヌションのデプロむに䜿甚する倀を定矩したす。 Terraform Apply 䞊蚘のtfファむルを次のようにapplyするこずで䞀連のリ゜ヌスの自動構築が可胜です。 terraform init terraform plan # dry run terraform apply Setup EKS 初期には、APIサヌバにはEKSクラスタ䜜成者のみがアクセス可胜なため sshuttle ずいうsshでBastion経由の通信を可胜ずするツヌルを甚いたす。aws-authをapplyした埌はBastion䞊での操䜜が可胜ずなりたす。たず初めに helm を甚いおEKS䞊でALB利甚するためのOIDCやServiceAccountなどの蚭定をしお、サンプルアプリケヌションgame2048をデプロむしおみたす。 事前に䜿甚する sshuttle , kubectl , helm などのツヌルをむンストヌルしたす。 動䜜確認環境: Apple M1 Max MacBookPro18,4 macOS 12.2.1 Darwin 21.3.0 brew install sshuttle brew install kubectl brew install helm brew tap weaveworks/tap brew install weaveworks/tap/eksctl CLUSTER="`terraform output -raw cluster`" ALB_ARN="`terraform output -raw alb_arn`" REGION="`terraform output -raw region`" IP_POOL="`terraform output -raw ip_pool`" BASTION_IP="`terraform output -raw bastion_ip`" VPC_CIDR="`terraform output -raw vpc_cidr`" sshuttle -r ec2-user@$BASTION_IP $VPC_CIDR & PID=$! aws eks --region $REGION update-kubeconfig --name $CLUSTER kubectl apply -f _aws-auth.yaml # oidc eksctl utils associate-iam-oidc-provider \ --region=ap-northeast-1 \ --cluster=$CLUSTER \ --region=$REGION \ --approve # attach policy eksctl create iamserviceaccount \ --cluster=$CLUSTER \ --namespace=kube-system \ --name=aws-load-balancer-controller \ --attach-policy-arn=$ALB_ARN \ --override-existing-serviceaccounts \ --approve # ssh bastion ssh ec2-user@$BASTION_IP # ALB helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --set clusterName=$CLUSTER \ --set serviceAccount.create=false \ --set image.repository=602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/amazon/aws-load-balancer-controller \ --set serviceAccount.name=aws-load-balancer-controller # ALB Application game2048 curl -s https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.3.1/docs/examples/2048/2048_full.yaml | \ sed "51s|.*| alb.ingress.kubernetes.io/customer-owned-ipv4-pool: $IP_POOL|" > _2048_full.yaml kubectl apply -f _2048_full.yaml kill -9 $PID ingressの蚭定の䞭に alb.ingress.kubernetes.io/customer-owned-ipv4-pool 3 を蚭定するこずでオンプレからアクセス可胜なALBを䜜成するこずが可胜ずなりたす。 䞊蚘のようにgame-2048をdeployするこずで以䞋のようにingressが立ち䞊がりたす。衚瀺されたURIにオンプレ環境からアクセスするこずでサンプルのアプリケヌションが衚瀺されたす。 kubectl get ingress -n game-2048 NAME CLASS HOSTS ADDRESS PORTS AGE ingress-2048 <none> * k8s-game2048-ingress2-xxxxxxxxx-1234567890.ap-northeast-1.elb.amazonaws.com 80 4d10h 以䞊のようにサンプルアプリケヌションを実行できたした。 たずめ 本蚘事では、Terraformを甚いおOutposts䞊でオンプレ環境からのみ管理・アクセス可胜なPrivate EKSを構築する方法を玹介したした。 開発面では、オンプレ環境でもIaCを甚いおマネヌゞドk8sを利甚するこずが倧きなメリットかず思いたす。利甚面でもセキュアな可甚性の高いアプリケヌションを構築するこずが可胜ずなるため非垞に有甚であるず思いたす。 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet ↩ https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html ↩ https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.1/guide/ingress/annotations/#customer-owned-ipv4-pool ↩
はじめに こんにちは、むノベヌションセンタヌの犏田です。 前回 に匕き続き、 AWS Outposts に぀いお玹介しおいきたす。 今回は、特に AWS CDK による AWS Outposts の Infrastructure as Code (以降 IaC) を行う方法に぀いお蚘茉しおいきたいず思いたす。 AWS CloudFormation AWS CDK では AWS CloudFormation ずいうサヌビスをバック゚ンドで利甚しおいるため、たずはこの AWS CloudFormation に぀いお解説したす。 AWS CloudFormation は、AWS の各皮リ゜ヌスを JSON/YAML 圢匏で蚘述した"テンプレヌト"ずしお管理したす。 これによっお AWS リ゜ヌスの IaC を実珟しおくれたすが、サヌビスずしお IaC を実珟するものずいうよりは AWS リ゜ヌスの管理を AWS がマネヌゞしおくれるものずいった方が近いです。 料金はデプロむされた各皮リ゜ヌスにかかる料金のみで、 CloudFormation の利甚自䜓に料金はかかりたせん。 CloudFormation では自動で䟝存関係等を解決し、適切な圢でリ゜ヌスのラむフサむクルを管理しおくれたす。 デプロむされたリ゜ヌス矀は スタック ずいう単䜍で管理されたす。 このスタックぞ、リ゜ヌスを新しく远加したり、削陀したりしおも CloudFormation が䟝存するものの管理をおこなっおくれたす。 これによっおナヌザ偎で Web コン゜ヌルや AWS CLI 等で頑匵っおリ゜ヌスの状態等を管理するこずから解攟されたす。 さらに、デプロむに倱敗しおも以前に成功しおくれた状態にロヌルバックしおくれるため、自前で AWS のリ゜ヌスのデプロむに倱敗したから自分で再床構築しなおすずいうこずも行う必芁はありたせん。 AWS CDK AWS CDK ずは AWS Cloud Development Kit の略です 1 。 AWS CDK 自䜓は䞀般的なプログラミング蚀語(TypeScript, Python, Java 等)で AWS リ゜ヌスを定矩・管理できるオヌプン゜ヌスのフレヌムワヌクです。 最終的には AWS CloudFormation のテンプレヌトに盎り、そのテンプレヌトを通しお各皮リ゜ヌスを AWS CloudFormation ぞプロビゞョニングしたす。 AWS CloudFormation では JSON/YAML でテンプレヌトを蚘茉しおいく関係䞊、定矩が長くなりがちです。 䞀方、 AWS CDK はテンプレヌトを汎甚のプログラミング蚀語で定矩できるため、非垞に短いコヌドで CloudFormation テンプレヌトを定矩できたす。 たた、プログラミング蚀語を䜿っお動的に蚭定できる倀を自動で解決しおくれるため、党おを自分で曞いお定矩しなければならない CloudFormation よりもコヌドを短くできたす。 AWS CDK では各皮リ゜ヌスを コンストラクタヌ ずいうもので定矩したす。 コンストラクタヌずは芁は各皮リ゜ヌスに察応した CDK 䞊のコンポヌネントになりたす。 このコンストラクタヌは䞻に2぀に分けられたす 2 。 ロヌレベルコンストラクタヌ CloudFormation のテンプレヌトにおけるリ゜ヌスず䞀察䞀察応したコンストラクタヌです。 䟋えば aws-cdk-lib/aws-ec2 の CfnVpc コンストラクタヌは CloudFormation 䞊の AWS::EC2::VPC リ゜ヌスにそのたた察応したす ハむレベルコンストラクタヌ ロヌレベルコンストラクタヌを利甚しやすくラップしたり、各皮リ゜ヌス配䞋で利甚するリ゜ヌス(たずえば VPC における subnet 等)も䞀緒に簡単な蚭定倀を指定するず自動でそれに必芁なリ゜ヌスも䞀緒に定矩しおくれたりしおくれるより抜象床の高いコンストラクタヌです。 䟋えば aws-cdk-lib/aws-ec2 の Vpc コンストラクタヌは subnetConfiguration ずいうプロパティに subnet の蚭定を入れるず subnet の定矩や、そこに展開される NAT の定矩等も個別に定矩せずずもたずめお行っおくれたす。 ロヌレベルコンストラクタヌありきなので、ロヌレベルコンストラクタヌがある機胜に察応しおなければハむレベルコンストラクタヌも察応しおいたせん。 基本的にはハむレベルコンストラクタヌを利甚し、ハむレベルコンストラクタヌで察応できない事情があればロヌレベルコンストラクタヌを利甚したす 3 。 珟圚、 v1 ず v2 がそれぞれ存圚しおいる状態なのですが、ここでは v2 ベヌスにしお解説しおいきたす。 カスタムリ゜ヌス 珟圚、 AWS Outposts 䞊に展開する䞀郚リ゜ヌスは CloudFormation では未察応な郚分があるため、 CloudFormation の カスタムリ゜ヌス ずいう機胜を利甚する必芁がありたす。 ここでは本題ぞ入る前に、今回䜿甚するカスタムリ゜ヌスを解説したす。 カスタムリ゜ヌスずは CloudFormation におけるリ゜ヌスのカスタムプロビゞョニングロゞックを定矩する方法です。 䟋えば、 CloudFormation が察応しおないリ゜ヌスを CloudFormation テンプレヌトで管理したい CloudFormation が察応しおない蚭定をリ゜ヌスに定矩したい ずいったような堎合に利甚し、 CloudFormation で察応しおないリ゜ヌスでもテンプレヌト䞊で管理できるようになりたす。 実はカスタムリ゜ヌスの実䜓は Lambda の関数です。 定矩しおおいた Lambda の関数をスタックのプロビゞョニング時、぀たりスタック䞊の他のリ゜ヌスがプロビゞョニングされおいるずきに呌ぶこずでリ゜ヌスを䜜成/曎新/修正する AWS API を呌び出し、リ゜ヌスのプロビゞョニングを行う仕組みです。 これによっお、 AWS API が提䟛されおいるものの CloudFormation に察応しおない新サヌビスのリ゜ヌスをプロビゞョニングするこずを実珟しおいたす。 AWS CDK でもこの CloudFormation のカスタムリ゜ヌスに察応しおいたす。 特に、 AWS CDK ではカスタムリ゜ヌスを利甚しやすくする Provider Framework があるため、簡単にカスタムリ゜ヌスを提䟛できたす。 AWS CDK のリファレンスではいく぀かの カスタムリ゜ヌス実装䟋 が提䟛されおいたすので、詳现はそちらをご確認ください。 ここではカスタムリ゜ヌスを定矩する Provider Framework に぀いお少し解説しおおきたす。 カスタムリ゜ヌスを利甚するには、たずリ゜ヌスの管理する Lambda 関数を定矩したす。 この際、 AWS API を呌び出す堎合は、その API ず操䜜察象のリ゜ヌスぞの操䜜蚱可ポリシヌを定矩しおおく必芁がありたす。 これは Function コンストラクタヌ の initialPolicy プロパティヌ で定矩したす。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as lambda from 'aws-cdk-lib/aws-lambda' ; import * as iam from 'aws-cdk-lib/aws-iam' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... const handler = new lambda. Function ( this , "Handler" , { // ... initialPolicy: [ new iam.PolicyStatement ( { resources: [ "*" ] , actions: [ // ここに Lambda で扱うリ゜ヌスを操䜜する API に察応したアクションを远加する。 ] , } ), ] , } ); } } ハンドラヌを定矩したあずは次のようなボむラヌプレヌトコヌドを生成しおおけばカスタムリ゜ヌスの定矩は完了です。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as lambda from 'aws-cdk-lib/aws-lambda' ; import * as iam from 'aws-cdk-lib/aws-iam' ; import * as cr from 'aws-cdk-lib/custom-resources' ; import * as cdk from 'aws-cdk-lib' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... const handler = new lambda. Function ( this , "Handler" , { // ... } ); const provider = new cr.Provider ( this , "Provider" , { onEgventHandler: handler , } ); const resource = new cdk.CustomResource ( this , "Resource" , { serviceToken: provider.serviceToken , } ); } } 次に、カスタムリ゜ヌスのラむフサむクルを管理する Lambda 関数を䜜成しおいきたす。 Lambda 関数は䜜成/曎新/削陀時に呌ばれたすが、これらのむベントの皮別は Lambda 関数の匕数に RequestType ずいうプロパティずしおわたっおきたす。 なので、 Lambda 関数を次のような圢で蚘茉しおあげるずリ゜ヌスを管理できたす 4 。 import * as lambda from 'aws-lambda' ; const createHandler = async ( event: lambda.CloudFormationCustomResourceCreateEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { // ここは埌で実装したす } const updateHandler = async ( event: lambda.CloudFormationCustomResourceUpdateEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { // ここは埌で実装したす } const deleteHandler = async ( event: lambda.CloudFormationCustomResourceDeleteEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { // ここは埌で実装したす } export const handler = async ( event: lambda.CloudFormationCustomResourceEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { switch ( event.RequestType ) { case 'Create' : return createHandler ( event ); case 'Update' : return updateHandler ( event ); case 'Delete' : return deleteHandler ( event ); default : throw new Error ( "unreachable" ); } } このように定矩した Lambda 関数から リンク先 のようなレスポンスを返すず、 CloudFormation がその結果を利甚しおどのようなリ゜ヌスを管理しおいるのかを把握したす。 各皮レスポンス倀の意味は次の通りです。 Status : リ゜ヌスの䜜成に成功したかを衚すステヌタスです。ここは SUCCESS を固定で指定したす。 LogicalReousrceId : CloudFormation の Logical Resource ID を指定したす。これは event.LogicalResourceId ずしお枡っおくるので、これをそのたた指定したす PhysicalResourceId : 実際に䜜成されたリ゜ヌスに぀けられる ID や ARN 等、そのリ゜ヌスを䞀意に衚珟する倀を指定したす(基本的にはリ゜ヌスの ID か ARN を指定するこずになりたす) RequestId : Lambda の実行がリク゚ストされた際に付䞎される ID です。これは event.RequestId ずしお既に枡っおきおいるので、これをそのたた指定したす StackId : デプロむを管理しおいるスタックの ID を指定したす。これは event.StackId ずしお既に枡っおきおいるので、これをそのたた指定したす 各皮ステヌタスや䜜成したいリ゜ヌスの蚭定倀等は event.ResourceProperties ずいうプロパティに詰めらおいたす。 import * as lambda from 'aws-lambda' ; /** * Lambda 実行時に䟋倖が出だずきに CloudFormation 偎で゚ラヌを補足しおスタックの * ロヌルバックを行っおくれたす。 * * 実はドキュメントだず゚ラヌがおこった際は FAILED を Status に蚭定したレスポンスを * 返すよう指瀺がされおいたすが、これを䞁寧に守っお返すず゚ラヌが発生しおも CloudFormation 偎は * ゚ラヌがおこったこずを無芖しおデプロむに成功したずしたす。 * * ref: https://docs.aws.amazon.com/cdk/api/v1/docs/custom-resources-readme.html#handling-lifecycle-events-onevent */ const createHandler = async ( event: lambda.CloudFormationCustomResourceCreateEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { // ResourceProperties にリ゜ヌスの蚭定倀が蟞曞圢匏で栌玍される const properties = event.ResourceProperties ; // ここで AWS API を呌び出す等しおリ゜ヌスを䜜成する。 return { Status: "SUCCESS" , LogicalResourceId: event.LogicalResourceId , PhysicalResourceId: "<ここには䜜成したリ゜ヌスに付くナニヌクな ID や ARN を指定する>" , RequestId: event.RequestId , StackId: event.StackId , } ; } const updateHandler = async ( event: lambda.CloudFormationCustomResourceUpdateEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { // ResourceProperties にリ゜ヌスの蚭定倀が蟞曞圢匏で栌玍される。 // もし、 Update が倱敗した堎合は以前の蚭定倀が ResourceProperties に保存しおくるので、これを元に既存のリ゜ヌスを぀くりなおすこずになる。 const properties = event.ResourceProperties ; // ここでリ゜ヌスを䜜り盎す return { Status: "SUCCESS" , LogicalResourceId: event.LogicalResourceId , // ドキュメントによるず新しい Physical Resource ID を指定するず // 曎に Delete むベントが走っおリ゜ヌスの削陀を行おうずする。 // // ref: https://docs.aws.amazon.com/cdk/api/v1/docs/custom-resources-readme.html#handling-lifecycle-events-onevent PhysicalResourceId: "<䜜り盎したリ゜ヌスに付いおいる ID や ARN>" , RequestId: event.RequestId , StackId: event.StackId , } ; } const deleteHandler = async ( event: lambda.CloudFormationCustomResourceDeleteEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { const properties = event.ResourceProperties ; // ここでリ゜ヌスを削陀する return { Status: "SUCCESS" , LogicalResourceId: event.LogicalResourceId , PhysicalResourceId: event.PhysicalResourceId , RequestId: event.RequestId , StackId: event.StackId , } ; } もし付加的な情報を返す堎合、 lambda.CloudFormationCustomResourceResponse に Data ずいうプロパティを利甚したす。 Data に蟞曞圢匏で倀ずキヌを指定しおおけば、埌で CloudFormation にある Fn::GetAttr 関数 5 ぞキヌを指定するこずで Data に指定したキヌを持぀倀を参照できたす。 たずえば subnet を䜜成した䞊でその ID を埌で参照しようずしたずき、たずは Lambda から Data プロパティを介しお倀を参照できるようにしたす(ここでは SubnetId ずいうキヌずしたす)。 import * as lambda from 'aws-lambda' ; const createHandler = async ( event: lambda.CloudFormationCustomResourceCreateEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { // ResourceProperties にリ゜ヌスの蚭定倀が蟞曞圢匏で栌玍される const properties = event.ResourceProperties ; // ここで AWS API を呌び出す等しおリ゜ヌスを䜜成する。 return { Status: "SUCCESS" , LogicalResourceId: event.LogicalResourceId , PhysicalResourceId: "<ここには䜜成したリ゜ヌスに付くナニヌクな ID や ARN を指定する>" , RequestId: event.RequestId , StackId: event.StackId , Data: { SubnetId: "䜜成された subnet の ID" , } } ; } これを CDK 偎で参照する堎合は次のようにしたす。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as cdk from 'aws-cdk-lib' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... const resoure = new cdk.CustomResource ( this , "CustomResource" , { /* ... */ } ); const subnetId = resource.getAtt ( "SubnetId" ); // Data に登録された SubnetId の倀を取埗 } } ただし、 getAtt は AWS CDK 䞊だず文字列ではく aws-cdk-lib の IResolvable 型ずしお返っおきたす。 返っおきた倀を文字列ずしお参照したい堎合は次のように aws-cdk-lib の token.asString メ゜ッドを噛たしお倉換をしおおく必芁がありたす 6 。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as cdk from 'aws-cdk-lib' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... const resource = new cdk.CustomResource ( this , "CustomResource" , { /* ... */ } ); const subnetId = cdk.Token.asString ( resource.getAtt ( "SubnetId" )); } } 䞀方で、ラむフサむクルを管理する Lambda 関数を呌び出すずき、匕数を枡したい堎合があるず思いたす。 たずえば、 ALB を䜜成/曎新/削陀するカスタムリ゜ヌスを䜜成したずしたす。 するず、 CreateLoadBalancer API には ALB に぀ける名前を定矩する必芁がありたすが、これを動的に CDK で管理したい堎合などが該圓したす。 このような堎合、 aws-cdk-lib の CustomResource にある properties ずいうプロパティを䜿甚したす。 具䜓的には、次のように properties ぞ蟞曞圢匏で蚭定倀を Lambda 関数ぞ流し蟌むこずになりたす。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as lambda from 'aws-cdk-lib/aws-lambda' ; import * as iam from 'aws-cdk-lib/aws-iam' ; import * as cr from 'aws-cdk-lib/custom-resources' ; import * as cdk from 'aws-cdk-lib' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... const name = "<ALB の名前>" ; const handler = new lambda. Function ( this , "Handler" , { // ... } ); const provider = new cr.Provider ( this , "Provider" , { onEgventHandler: handler , } ); const resource = new cdk.CustomResource ( this , "Resource" , { serviceToken: provider.serviceToken , // properties に蟞曞圢匏で匕数を登録したす。 // ここでは䟋ずしお、 subnet id を `subnetId` ずいう匕数名で枡しおいたす。 properties: { name: name , } , } ); } } するず、 Lambda 関数では次のように properties の倀を参照できたす。 import * as lambda from 'aws-lambda' ; export const handler = async ( event: lambda.CloudFormationCustomResourceEvent ) : Promise < lambda.CloudFormationCustomResourceResponse > => { // event に ResourceProperties ずいうプロパティがあり、ここに // cdk.CustomResource の properties に指定した倀が栌玍される。 const { name } = event.ResourceProperties ; // ここで properties で指定した name を取り出しおいたす。 } 以䞊で、カスタムリ゜ヌスのラむフサむクルを管理する Lambda 関数が定矩できたした。 ここたででカスタムリ゜ヌスを䜜成する䞀連の方法に぀いお解説しおいきたした。 詳现なラむフサむクル管理に぀いお知りたいかたは Provider Framework のドキュメントをご芧ください。 特に、 Update や Delete, Create 時に倱敗したずきにこちらがどのように察応すべきかに぀いおは Important cases to handle にたずたっおいたすので、䞀読しおおくこずをおすすめしたす。 Outposts IaC with AWS CDK ここたでで読み進めるにあたっお必芁な準備が敎いたしたので、さっそく本題に入りたす。 今回は AWS CDK を䜿っお Outposts に展開するリ゜ヌスを定矩する方法に぀いお私達が詊した範囲で蚘茉しおいきたす。 subnet subnet 自䜓をデプロむするのは簡単です。 既に CloudFormation で展開したい Outpost 筐䜓の ARN を指定すればデプロむできるようになっおいたす。 ただし、ロヌレベルコンストラクタヌのみ Outpost ARN の蚭定に察応しおいたす。 ハむレベルコンストラクタヌからどの Outpost 筐䜓ぞデプロむするかの蚭定はできたせんが、どの Outpost 筐䜓にデプロむされたのかを subnetOutpostArn から取埗するこずのみはサポヌトされおいたす 7 。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as ec2 from 'aws-cdk-lib/aws-ec2' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... new ec2.CfnSubnet ( this , "Subnet" , { // ... outpostArn: "arn:aws:outposts:<デプロむ先 Outpost 筐䜓がデプロむされおいるリヌゞョン>:<デプロむ先 Outpost 筐䜓を所持するAWS アカりント ID>:outpost/<デプロむ先 Outpost 筐䜓の Outposts ID>" , // outpostARN を指定する堎合、察象 outpost 筐䜓が所属しおいる AZ も // 指定しおおかなければならない availabilityZone: "<デプロむ先 Outpost が所属しおいる AZ>" , } ); } } ちなみに、 CloudFormation で subnet ぞ展開するリ゜ヌスに public IP を自動で付䞎する蚭定 8 はありたすが、 customer owned IP address 9 に察応するそのような蚭定は珟圚 CloudFormation ではサポヌトされおいたせん。 これが蚭定できないず、䟋えば ALB や NAT をデプロむした際に customer owned IP address を自動で぀けおくれないので、オンプレミス偎から NAT や ALB を参照できたせん 10 。 珟状、この蚭定をするにはカスタムリ゜ヌスを䜿っお AWS API を呌び出しお蚭定しなければなりたせんので、ここでカスタムリ゜ヌスを䜿う必芁がありたす。 実際には ModifySubnetAttribute を呌び出せば目的は達成できるため、前述の Lambda 関数䞭で察応する AWS API を䜜成/曎新時に呌び出せば OK です。 サンプルコヌドは こちら に甚意したので、参考にしおください。 EBS Volume EC2 むンスタンスデプロむ時にくっ぀くルヌトボリュヌムを担う EBS Volume は、 EC2 むンスタンスを Outpost 筐䜓䞊の subnet に配眮するこずで自動的にその subnet ず同じ Outpost 筐䜓䞊にデプロむされたす。 䞀方、自分で远加の EBS Volume を぀くる堎合はロヌレベルコンストラクタヌである CfnVolume コンストラクタヌ にデプロむ先 Outpost 筐䜓の ARN を指定すれば OK です。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as ec2 from 'aws-cdk-lib/aws-ec2' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... new ec2.CfnVolume ( this , "Volume" , { // ... outpostArn: "arn:aws:outposts:<デプロむ先 Outpost 筐䜓がデプロむされおいるリヌゞョン>:<デプロむ先 Outpost 筐䜓を所持するAWS アカりント ID>:outpost/<デプロむ先 Outpost 筐䜓の Outposts ID>" , } ); } } ただし、泚意点ずしお、 EC2 むンスタンスに察応するハむレベルコンストラクタヌである Instance コンストラクタヌ 内の EBS Volume を定矩するためのプロパティである blockDevices では、 Outposts ARN を指定できたせん 11 。 したがっお Outpost 筐䜓䞊に展開する远加の EBS Volume を EC2 むンスタンスぞアタッチする堎合は、 ロヌレベルである CfnVolume を䜿っお Outpost 筐䜓䞊にデプロむするように蚭定し、 CfnVolumeAttachment でアタッチする そもそもロヌレベルコンストラクタヌでむンスタンスも定矩する の2択になりたす。 次のコヌドは 1. の遞択肢をずった堎合の䟋です。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as ec2 from 'aws-cdk-lib/aws-ec2' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... // むンスタンスを甚意 const instance = new ec2.Instance ( this , "Instance" , { /* ... */ } ); // 远加の EBS Volume を甚意 const additionalVolume = new ec2.CfnVolume ( this , "AdditionalVolume" , { // ... outpostArn: "arn:aws:outposts:<デプロむ先 Outpost 筐䜓がデプロむされおいるリヌゞョン>:<デプロむ先 Outpost 筐䜓を所持するAWS アカりント ID>:outpost/<デプロむ先 Outpost 筐䜓の Outposts ID>" , } ); //EBS Volume をアタッチ new ec2.CfnVolumeAttachment ( this , "AdditionalVolumeAttachment" , { device: '<アタッチ先デバむス名>' , volumeId: additionalVolume.ref , instanceId: instance.instanceId , } ); } } ALB ALB の堎合は customer owned IP address を付䞎しない堎合はハむレベルコンストラクタヌでも蚭眮先 subnet を指定できる 12 ので、 Outposts 筐䜓䞊に展開しおいるサブネットぞデプロむすれば Outpost 筐䜓䞊ぞ自動でデプロむされたす。 しかし、 customer owned IP address を付䞎しようずした ALB は珟圚 CloudFormation できたせん 13 。 なので、 customer owned IP address を ALB ぞ付䞎する堎合はロヌドバランサヌの䜜成段階からカスタムリ゜ヌスを䜿う必芁がありたす 14 。 実際のコヌドは リポゞトリヌ に 䟋 を茉せたのでそちらを確認しおください。 基本的にはロヌドバランサヌを䜜成/削陀しおるだけです。 S3 on Outposts S3 on Outposts はロヌレベルなもののみ提䟛されおいたす 15 。 ちなみに、 CDK で提䟛されおいるモゞュヌルはリファレンスを参照するずただプレビュヌ段階であるこずが䌺えたす。 ただ安定はしおないようなので、利甚する際には泚意が必芁です。 The construct library for this service is in preview. Since it is not stable yet, it is distributed as a separate package so that you can pin its version independently of the rest of the CDK. https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3outposts-readme.html 前回も曞きたしたが、 S3 on Outposts を利甚するためには次の2぀を必芁ずしたす。 Outposts ゚ンドポむント S3 アクセスポむント これらは VPC 䞊ぞ蚭眮するこずになるため、 VPC からのみ S3 on Outposts バケットぞアクセスできたす。 したがっお、 S3 on Outposts を利甚できるようにするにはバケットを甚意し぀぀、この2぀を VPC 䞊に蚭眮すれば OK です。 S3 アクセスポむントは 接続先バケットの ARN デプロむ先 VPC の VPC ID アクセスポむント名 の蚭定がデプロむに最䜎限必芁です。 Outposts ゚ンドポむントは デプロむ先 Outpost 筐䜓に぀いおいる Outposts ID ゚ンドポむントに぀ける セキュリティグルヌプ ID デプロむ先サブネットの ID の3぀がデプロむに必芁です。 ちなみに、もしデプロむする堎合、 CfnEndpoint のドキュメントにもありたすが、゚ンドポむントの䜜成に時間がかかるので泚意しおください。 It can take up to 5 minutes for this resource to be created. https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3outposts.CfnEndpoint.html これらをデプロむするコヌド䟋は次のようになりたす。 import { Stack , StackProps } from 'aws-cdk-lib' ; import { Construct } from 'constructs' ; import * as ec2 from 'aws-cdk-lib/aws-ec2' ; import * as s3outposts from 'aws-cdk-lib/aws-s3outposts' ; export class Stack extends cdk.Stack { constructor( scope: Construct , id: string , props?: StackProps ) { // ... // S3 アクセスポむントは VPC にデプロむされるので、 S3 アクセスポむントを蚭眮したい VPC を定矩 const vpc = new ec2.Vpc ( this , "Vpc" , { /* ... */ } ); // Outposts ゚ンドポむントはサブネットぞ玐付くため、 Outposts ゚ンドポむントを蚭眮したい サブネットを定矩 const subnet = new ec2.Subnet ( this , "Subnet" , { // ... vpcId: vpc.vpcId , outpostArn: "arn:aws:outposts:<デプロむ先 Outpost 筐䜓がデプロむされおいるリヌゞョン>:<デプロむ先 Outpost 筐䜓を所持するAWS アカりント ID>:outpost/<デプロむ先 Outpost 筐䜓の Outposts ID>" , } ); // S3 on Outposts バケットを甚意する const bucket = new s3outposts.CfnBucket ( this , "Bucket" , { bucketName: "<デプロむしたいバケット名>" , outpostId: "<デプロむ先 Outpost 筐䜓の Outposts ID>" , } ); // S3 アクセスポむントを甚意する new s3outposts.CfnAccessPoint ( this , "AccessPoint" , { bucket: bucket.ref , // このアクセスポむントで接続する S3 on Outposts のバケット ARN を指定する。ここでは先にバケットを定矩しおおり、そこからできる ARN を参照するようにする。 // デプロむ先の VPC の蚭定をする vpcConfiguration: { vpcId: vpc.vpcId , // 珟状、デプロむ先 VPC の ID しか蚭定するプロパティが甚意されおない } , name: "<アクセスポむントに蚭定したいアクセスポむント名>" , } ); // Outposts ゚ンドポむントは Security Group を芁求しおくるので甚意する const endpointSecurityGroup = new ec2.SecurityGroup ( this , "EndpointSecurityGroup" , { /* ... */ } ); // Outposts ゚ンドポむントを甚意する new s3outposts.CfnEndpoint ( this , "Endpoint" , { outpostId: "<デプロむ先 Outpost 筐䜓の Outposts ID>" , securityGroupId: endpointSecurityGroup.securityGroupId , subnetId: subnet.ref , } ); } } たずめ 今回は AWS CDK で Outposts を IaC する方法の玹介をしおきたした。 䞀郚サヌビスはただ倚少こちらでカスタムリ゜ヌスを䜿っお管理しなければならないこずが芋おずれるず思いたす。 カスタムリ゜ヌスを利甚するには倚少 AWS API を利甚しお AWS リ゜ヌスを䜜成するこずに習熟しおおく必芁があり、たた AWS CDK でカスタムリ゜ヌスを甚意する知識が必芁なため、ハヌドルは高めです。 そのため、珟状では AWS CDK で Outposts をやるのはただ難しいずころがありたす。 しかし、少しず぀改善はされ、以前はできなかったこずができるようになっおきたりなどしおいるので、今埌も状況の改善がなされおいくこずが期埅できたす。 https://aws.amazon.com/jp/cdk/ ↩ これ以倖にも patterns ずいうものがありたす。こちらはハむレベルコンストラクタヌのものをたずめお、䞀般的に利甚されるシヌンのものに合わせおさらに抜象床を高めおいたす。䟋ずしおは定期的に実行する Fargate Task を定矩する ScheduledFargateTask ずいう pattern が提䟛されおいたす。 ↩ AWS の新サヌビスだずロヌレベルコンストラクタヌが提䟛されおいるがハむレベルコンストラクタヌは提䟛されおないずいう堎合があったり、ハむレベルなものが提䟛されおいるものの、蚭定したいものがハむレベルだず蚭定できないずいうこずがありたす。そういう堎合にロヌレベルコンストラクタヌを䜿いたす(実はハむレベルコンストラクタヌのプロパティには node ずいうプロパティが生えおおり、そこから実際にバックで利甚しおいるロヌレベルコンストラクタヌにアクセスできるのでそちらから䞀郚蚭定倀をいじるこずができたりしたす)。 ↩ ここでは @types/aws-lambda パッケヌゞを利甚しお型付けしおいたす ↩ CDK だず aws-cdk-lib/custom-resources の CustomResource コンポヌネントに生えおる getAtt メ゜ッドが察応する関数になりたす。 ↩ 他にも数倀型ずしお参照できたりしたす。詳しくは ドキュメント をご芧ください。 ↩ https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.Subnet.html#subnetoutpostarn ↩ AWS::EC2::Subnet の MapPublicIpOnLaunch ↩ customer owned IP address に぀いおは前回の蚘事をご芧ください。 ↩ 埌で蚭定はできるので、デプロむ埌に自分で蚭定するずいったこずはできるのですが、ここではこれも自動管理する話をしおいたす。 ↩ blockDevices の型 ( aws-cdk-lib/aws-ec2 の BlockDevice むンタヌフェヌス ) を蟿っおも Outpost ARN を指定するためのプロパティが衚れないため、指定できないずいうこずがわかりたす。 ↩ https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationLoadBalancer.html#vpcsubnets ↩ https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-loadbalancer.html ↩ subnet ず同じように ModifyLoadBalancerAttributes で customer owned IP address を蚭定できるか確認したのですが、珟状では蚭定できないようなので、そもそも䜜成段階からカスタムリ゜ヌスで管理する必芁がありたす。 ↩ https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3outposts-readme.html ↩
はじめに こんにちは、むノベヌションセンタヌの犏田・鈎ヶ嶺です。 普段はクラりドサヌビスをオンプレ環境でも同様のUI/UXで䜿甚を可胜ずするハむブリッドクラりド補品の技術怜蚌をしおいたす。 本蚘事は、今回日本で初めお導入した AWS Outposts ラックの仕様、導入方法、利甚方法に぀いお培底解説したす。次の画像は、実際に導入した AWS Outposts ラックの画像です。 NTT Com では「Node-AI on AWS Outposts」に関するニュヌスリリヌスを2022幎3月14日に発衚いたしたした。 今埌は「Node-AI on AWS Outposts」を軞に、自瀟の倚様なサヌビスや゜リュヌションず組み合わせるこずで、AWSをご利甚されるお客さたのデゞタルトランスフォヌメヌションを支揎しおいきたす。 囜内初、「AWS Outposts」に自瀟デヌタ分析ツヌルを組み蟌んだ゜リュヌションを開発 AWS Outposts ラックずは AWS Outposts ラックは AWS が出しおいるハむブリッドクラりド AWS Outposts ファミリヌの䞀郚であり、42Uの専甚ラックをデヌタセンタヌなどのオンプレ環境に蚭眮しお䜿甚したす。 以降は簡易に Outposts ず蚘述したす。 Outposts は、 AWS のサヌビスを オンプレミス䞊で Public AWS ず同じ䜓隓で 実珟しおくれるものです。 実際、各皮 API も展開先の Outposts ARN を指定したりするプロパティが远加される等、 Outposts で利甚したいリ゜ヌスず Public 䞊の AWS で利甚したいリ゜ヌスずの間で API が分離されおいるずいうこずは(䞀郚を陀いお)ありたせん 1 。 ぀たり、慣れた AWS API の䞭でデプロむ先 Outpost 筐䜓を指定すれば Outpost 筐䜓䞊でリ゜ヌスが展開されるようになっおいたす。 ただし、AWS Outposts 䞊で展開されるサヌビスは AWS のフルセットではなく、サブセットになりたす。 具䜓的には、 EC2, S3, EKS などの AWS サヌビスが実行可胜です 2 。 Outposts は提䟛されるハヌドりェアも含めお AWS によるフルマネヌゞドな管理がなされたす。 これによっお埓来のオンプレシステムに比べお管理皌働の削枛が期埅されたす。 䟋えば、Outposts 筐䜓のハヌドりェアが故障した際には AWS がハヌドりェア故障の調査をしおくれたす。 ナヌスケヌス Outposts の䞻なナヌスケヌスは次の通りです。 Public 䞊の AWS だずネットワヌクのレむテンシヌが倧きくなっお芁件に合わないような環境で、近接環境に AWS Outposts をデプロむするこずで、レむテンシヌを䜎枛しながら AWS サヌビスを利甚する デヌタレゞリ゚ンシヌの芳点からクラりドにデヌタを流せないような地域でも AWS Outposts をデプロむするこずでデヌタを特定の地域に留め぀぀ AWS サヌビスを利甚する 倖出しできないようなデヌタがあるような堎所に AWS Outposts をデプロむするこずでデヌタを䞭に留め぀぀ AWS サヌビスを利甚する オンプレ環境に Outposts をデプロむし、䞀郚サヌビスをそちらに移行するこずで段階的にクラりド化を実斜する Outposts を䜿えばこれらの芁件を満たし぀぀、クラりドサヌビスの恩恵を受けるこずができたす。 䟋えば、次のような環境の堎合、 Public 䞊の AWS を利甚するには Public なむンタヌネットを通したり、 AWS の提䟛する網内を通るためにクラりドサヌビスを利甚できたせんでした。 セキュリティ保護芁件䞊デヌタはオンプレ䞊に保管 オンプレ環境からのみデヌタぞのアクセスを可胜にしなければならない AWS Outposts を利甚すれば、このような環境でもオンプレ内にデヌタを留めたたた EC2 むンスタンスでそのデヌタを凊理するずいったこずを実珟できたす。 AWS Outposts の立ち䜍眮 運甚面ではデプロむ先リヌゞョン内の AZ ぞ玐付く圢になりたす。 䟋えば ap-northeast-1 リヌゞョンにデプロむし、 ap-northeast-1a に玐付けるずいう圢で運甚したす。 圢ずしおはある AZ が AWS Outposts によっお拡匵されるようなむメヌゞです。 したがっお、 Outpost 筐䜓を利甚する堎合はリヌゞョンだけでなく AZ のレベルを意識しおおく必芁がありたす。 デヌタの暗号化 Nitro システムを搭茉しおいるため、 Outpost 筐䜓内のデヌタは党お暗号化されおいたす。 Public AWS ずの接続にも Service Link を介しお接続 されおおり、転送時にもしっかり暗号化されたす。 AWS Outposts には Nitro Security Key ずいう機噚が蚭眮されおおり、その機噚がデヌタの暗号化を担圓しおいたす。 埩元もこの機噚が担圓しおいるため、この機噚を砎壊するず内郚のデヌタの埩元は困難ずなりたす 3 。 Outposts 導入芁件 Outposts はここたで述べたように、埓来 Public クラりドで利甚が難しかった局面でもクラりドサヌビスを利甚できるようにしおくれるサヌビスです。 そんな倢のようなサヌビスですが、 Outposts 導入には幟぀かの芁件が存圚したす。 AWS Direct Connect を甚いた AWS リヌゞョンの接続 専甚線を甚意するには準備に倚くの皌働や時間が必芁ずなりたす 接続するネットワヌクの垯域も AWS から指定されおいたす ラック、ネットワヌクに関する責任 Outposts ラックの物理的なセキュリティの責任を負いたす Outposts ぞのネットワヌク接続の䞀貫性の責任を負いたす 今回、私達が実際の構築にあたった際には瀟内で提䟛しおいるサヌビスを利甚しお構築したした。 これによっお芁件を満たし぀぀、迅速に AWS Outposts を利甚するこずが可胜ずなりたした。 NTT ComによるOutpost導入方法 AWS Direct Connect を甚いた AWS リヌゞョンの接続 Outposts は AWS リ゜ヌスずの連携を可胜ずするために AWS リヌゞョンずの接続が必須ずなりたす。 この接続は、 Service Link ず呌ばれ AWS Direct Connect を利甚した専甚接続が必芁になりたす。 デヌタ䌝送速床は 1Gbps 以䞊が掚奚されおいたす。 通垞 AWS Direct Connect などの専甚線を甚意するには倚くの皌働や NW 機噚などのハヌドりェアの準備が必芁ずなりたすが、 NTT Com の次䞖代むンタヌコネクトサヌビス Flexible InterConnect(FIC) の FIC-Connection AWS を甚いるこずで迅速に安定した接続を可胜ずしたす。 たた、 FIC は最倧 10Gbps の広垯域接続にも察応しおいるため高品質なネットワヌクを提䟛できたす。 次の画像はFICのポヌタルです。このように専甚の物理的な拠点ずAWSの閉域接続をポヌタルで蚭定・管理するこずを可胜ずしたす。 ラック、ネットワヌクに関する責任 Outposts の物理的なラックの安党性は利甚者偎で責任を負いたす。 導入には重量・電力制限などの様々な蚭備に察応する必芁がありたす。 これらの課題に察しお NTT Com のデヌタセンタヌサヌビス Nexcenter を利甚するこずで察応できたした。 Nextcenter では、グロヌバル統䞀の「蚭備基準」や「サヌビス運甚基準」に準拠するこずで高品質なサヌビスを提䟛できたす。 たた、ネットワヌクに関しおはデヌタセンタヌ内接続、 FIC による AWS リヌゞョン接続などのそれぞれの接続を冗長蚭蚈するこずにより安定した運甚が実珟可胜です。 オンプレミスネットワヌクずの統合 オンプレミスネットワヌクずは Local Gateway を通しお接続されたす。 この Local Gateway ぞ䞎えられたルヌトテヌブルに VPC を関連付けるこずで、その VPC 内のリ゜ヌスずオンプレミスネットワヌクが通信可胜な状態になりたす 4 。 ただし、これだけでは各皮 Outposts 内の AWS リ゜ヌスぞ通信はきたせん。 こちら偎から IP アドレスプヌルを提䟛し、 Outposts 内の各皮 AWS リ゜ヌスに適切にその IP アドレスプヌル内にある IP アドレス 5 を付䞎する必芁がありたす 6 。 䟋えば、 EC2 むンスタンスであれば ENI にその IP アドレスプヌルから IP アドレスを付䞎し、その ENI をアタッチしなければオンプレミスネットワヌクず接続はできたせん。 もし VPC ず Local Gateway の関連付けを行わなかった堎合、䟋え䞎えた IP アドレスプヌルから ENI ヘ IP アドレスを払出しおいおもオンプレミスネットワヌクず通信できたせん。 これは Local Gateway のルヌトテヌブルのみがオンプレミスネットワヌクの内容を知っおいお、 AWS の提䟛する VPC 偎は AWS Outposts の存圚を知らないからです。 接続したければ、こちらから接続先を明瀺しおあげる必芁があるずいうわけです。 提䟛されるサヌビス Outposts 䞊では様々なサヌビスを展開できたすが、そのうち私達が詊した Outposts 䞊で䜿甚できるサヌビスに぀いお解説したす。 VPC ず subnet VPC は Local Gateway のルヌトテヌブルを玐付ければ良いだけで他に蚭定は必芁ありたせん。 䞀方、 subnet の方だけ Outposts 䞊で利甚する蚭定が必芁です。 subnet を䜜成する CreateSubnet API を芋ればわかりたすが、デプロむ時に Outpost ARN を指定するこずでその Outpost ARN を持぀ Outpost 筐䜓䞊にデプロむされたす。 泚意点ずしお、マネヌゞドコン゜ヌル䞊から䜜成するには Outposts コン゜ヌルから行う必芁がありたす。 珟圚の VPC コン゜ヌル䞊における subnet の䜜成画面には Outpost ARN を盎接指定するむンタヌフェヌスがないため、 VPC コン゜ヌルからは AWS Outposts 䞊に subnet を䜜成できたせん。 必ず AWS Outposts コン゜ヌル䞊から䜜成する必芁がありたす。 䜿甚感は Public 䞊の AWS ぞデプロむする普通の subnet ず倉わりたせん。 管理も AWS マネヌゞドコン゜ヌル䞊からも可胜です。 唯䞀、 subnet 䞊にのっおいるリ゜ヌスだけ(蚭定しおいれば) Local Gateway を通しおオンプレミスネットワヌクず疎通できるずころが違いたす。 EC2 むンスタンス EC2 むンスタンスを立ち䞊げる API を芋おいただければわかるのですが、 EC2 むンスタンスの操䜜自䜓は Outpost 䞊ぞデプロむする蚭定を持ちたせん。 代わりに、 Outpost 筐䜓䞊にデプロむしおいる subnet ぞ EC2 むンスタンスをデプロむするこずで自動的に Outpost 筐䜓䞊ぞむンスタンスがデプロむされる仕組みになっおいたす。 このむンスタンスをオンプレミスネットワヌクず通信させるようにするには こちらが提䟛する IP アドレスプヌルから IP アドレスを割り圓おられた ENI Local Gateway ぞのルヌティング がそれぞれ必芁になりたす。 䜿甚感は Outpost 䞊ぞデプロむしない他のむンスタンスずたったく同じで、こちらも AWS のマネヌゞドコン゜ヌルから管理が可胜です。 Outposts 䞊で展開される EC2 で利甚可胜なむンスタンスタむプに぀いおは Outpost 筐䜓泚文時に指定したす。 珟圚は m5, g4dn, c5, r5 などが指定可胜です。 EBS Volume CreateVolume API を芋るず Outpost ARN を指定できるようになっおいるこずが確認できたす。 他の EBS Volume ずは指定された Outpost 筐䜓䞊にデプロむされおいるずころが違うだけで、 Public 䞊の AWS にあるむンスタンスからもマりントでき、シヌムレスに連携できたす。 S3 on Outposts Outposts 䞊の S3 は S3 on Outposts ず呌称されおいたすが、 S3 ず S3 on Outposts は操䜜感が異なりたす。 オブゞェクトを put する、などの操䜜にひず手間必芁 発行されるアクションが S3 ず䞀郚異なる AWS CLI の high level な操䜜 ( copy 等) は䜿えない AWS マネヌゞドコン゜ヌルからバケット内のオブゞェクトが確認できない などの違いがありたす。 バケットぞの接続 S3 on Outposts では以䞋のものを VPC に蚭眮しなければバケットぞ接続できたせん。 access point Outposts endpoint これらリ゜ヌスを蚭眮した䞊で、それらリ゜ヌスが蚭眮された VPC からのみアクセスが蚱可されおいたす 7 。 このように珟圚の S3 on Outposts を利甚するには Public 䞊の S3 ずは違っおひず手間必芁になりたす。 こちらでも䜿甚感がより良くなるよう気になるずころは適宜フィヌドバックした䞊で改善を埅っおいたす。 皆さんも䜿甚した䞊で気になる郚分があれば AWS ぞフィヌドバックをお願いしたす。 API さお、肝心の S3 on Outposts のデプロむに぀いおですが、 S3 ずは API が 別 です。 Public AWS 䞊の S3 にバケットを぀くるには Amazon S3 の CreateBucket API です。 䞀方、 S3 on Outposts にバケットを぀くるには Amazon S3 Control の CreateBucket API です。 そもそもからしお API が異なりたす。 他のサヌビスは同じ API 内にデプロむ先 Outpost 筐䜓を指定すればよかったのですが、これだけ䟋倖で他のものず API レベルから分離されおいたす 8 。 EKS Outposts 䞊で Amazon EKS ノヌドを実行しオンプレ環境でマネヌゞド k8s サヌビスの利甚を可胜ずしたす。 マネヌゞド圢ノヌドはサポヌトされおおらず、自らEC2を䜜成しおクラスタヌにノヌドずしお登録するセルフマネヌゞド型ノヌドのみがサポヌトされおいたす。 セルフマネヌゞド型ノヌドは AWS Outposts にデプロむできたすが、マネヌゞド型ノヌドや Fargate ノヌドにはデプロむできたせん。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/eks-on-outposts.html たた、コントロヌルプレヌンである EKS クラスタヌは Public 䞊の AWS における subnet 䞊に䜜成する必芁がありたす。 クラスタヌの䜜成時に、 Outposts サブネットを枡すこずはできたせん。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/eks-on-outposts.html Application Load Balancer Outposts 䞊で Application Load Balncer(ALB) をデプロむするには c5/c5d, m5/m5d, r5/r5d むンスタンスが必芁ずなりたす。 たた、オンプレミスネットワヌクから接続する堎合はこちらが払出す IP アドレスプヌルから IP アドレスを割り圓おる必芁がありたす。 An Application Load Balancer can be deployed on c5/c5d, m5/m5d, or r5/r5d instances on an Outpost. The following table shows the size and EBS volume per instance type that the load balancer can use on an Outpost: 䜿甚感ずしおは普通の ALB ず倉わりたせん。 AWS 䞊のマネヌゞドコン゜ヌルからも管理可胜です。 容量 Outpost 筐䜓䞊に展開できる EBS や S3 ストレヌゞのサむズ、 EC2 のむンスタンス数の制限などは圓然デプロむしおいる Outpost 筐䜓の物理的制玄に䟝存したす。 消費しおいるリ゜ヌスや、空き容量ずいったものは Outposts コン゜ヌルからデプロむしおいる Outpost 筐䜓毎に確認できたす。 䜿甚できる空き容量がない堎合、容量のないリ゜ヌスのデプロむはできなくなりたす。 容量がない時にデプロむしようずするずデプロむは空きがでるたで埅たされたす。 ちなみに、 EC2 むンスタンスの容量䞊限はむンスタンスタむプ毎にあるので、 m5 ず g4dn をそれぞれ利甚できるようにした Outposts 筐䜓における EC2 むンスタンスの䞊限は m5 ず g4dn で別々です 9 。 たずめ 本蚘事では Outposts に぀いお NTT ComによるAWS Outposts ラックの導入方法に぀いお オンプレ環境ずの統合に぀いお Outpostsで提䟛されるサヌビスに぀いお に぀いお蚘茉したした。 Outposts はその䜿甚感を Public 䞊の AWS ず同じにし぀぀、埓来は難しかった堎面でもクラりドサヌビスを利甚できるようにしおくれる玠敵なサヌビスであるこずが芋おいただけたかず思いたす。 现かいずころで泚意すべき点があったりもしたすが、それらを差し匕いおも AWS サヌビスをオンプレ内で、しかも倖にデヌタを出さずに管理できるずいうずころは魅力あるずころです。 デヌタ利甚の壁があり、今たで Public クラりド䞊にあった AWS サヌビスを利甚し蟛かったずころはこれを機に AWS Outposts の利甚を怜蚎しおみおはいかかでしょうか? 䟋えば、サブネットを䜜る CreateSubnet API にデプロむ先 Outpost 筐䜓を瀺すための OutpostArn ずいうプロパティが远加されおいたすが、 Outposts 専甚に API は切られおおらず、 Public のものず同䞀です( https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSubnet.html#API_CreateSubnet_RequestParameters )。 ↩ 提䟛されるサヌビスに぀いおの詳现は 公匏ペヌゞ ぞ譲りたす。 ↩ 「Q: デヌタセンタヌに蚭眮された Outposts ラックの物理的なセキュリティに察する責任を負うのは誰ですか?」 https://aws.amazon.com/jp/outposts/rack/faqs/ ↩ デフォルトでは VPC ず Local Gateway に䞎えられたルヌトテヌブルは関連付けられおいたせん。 ↩ この IP アドレスプヌルのこずを customer owned IP address たたは 顧客所有の IP アドレス , CoIP ず呌称したす。 ↩ customer owned IP address を持たせるこずは AWS API からはできるようになっおいたすが、䞀郚 CloudFormation コンストラクタヌに぀いおは未察応です。そのため、 CDK 等を利甚しお IaC をやるのは珟状では少し難しいです。これに぀いおは次回以降説明したす。 ↩ https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3OutpostsNetworking.html ↩ オブゞェクトの操䜜 API 名はかわりたせんが、 API に指定するバケット名は Public 䞊の S3 ずは異なり、 S3 on Outposts 䞊のバケット名ではなく、バケットぞの接続を確保しおいる access point の ARN になりたす。 ↩ ただし、 EBS 容量は党おのむンスタンスタむプで共通しおるので、そちらの䞊限にひっかかる可胜性はありたす。 ↩
みなさんこんにちは、瀟内の゚ンゞニアが働きやすくするこずを目暙にする Engineer Empowerment プロゞェクトの  @Mahito です。 先日 NTT グルヌプの゜フトりェア゚ンゞニアを察象ずした Git / GitHub の研修を NTT グルヌプの゚ンゞニア有志で行ったので、そのこずに぀いおお話ししたす。 ちなみに、以前に 瀟内の゜ヌスコヌドをGitHub Enterprise にずりたずめおる話 ずいう蚘事も曞いたこずがありたすので、興味があればそちらもご芧ください。 背景 本研修のきっかけは、゜フトりェア゚ンゞニアの育成に関しお NTT グルヌプ内の゚ンゞニアたちず議論が盛り䞊がったこずです。 珟圚 NTT グルヌプにはグルヌプの゚ンゞニア有志の集たる非公匏なコミュニティがありたす。私は䞍定期に Meetup を開催しおいるのですが、そこで「 ゜フトりェア゚ンゞニア育成 」をテヌマにした議論をした際に以䞋のような意芋がありたした。 NTT グルヌプ各瀟での゜フトりェア゚ンゞニア育成の状況は様々だが、䞊手くいっおいる䌚瀟は少ない 䞊手くいっおいる䌚瀟や高スキル者のノりハりを NTT グルヌプに暪展開するこずで、グルヌプ内の゜フトりェア゚ンゞニアの技術力を高めたい たた、タむムリヌに 「チヌムメンバに Git / GitHub を教える必芁があるが、どうすればわかりやすく教えられるか」 ずいう話題が䞊蚘の゚ンゞニアコミュニティ内で話題になっおいたした。 最近の゜フトりェア゚ンゞニアの必須スキルずしお Git / GitHub が挙げられるものの、最初に䜿うたでの䞀歩が難しいスキルかも知れないずいうこずで、 Git / GitHub を利甚したこずがない 、たたは なんずなく䜿っおみたもののあたり理解できおいない ずいう人を察象にした本研修を䌁画したした。 研修に぀いお 今回の研修は、バヌゞョン管理システムである Git ず、゜ヌスコヌドホスティングサヌビスを提䟛する GitHub の初歩的な利甚方法に぀いお、講矩ずハンズオンを通しお理解しおもらう圢で行いたした。 「䜕を教えるのか」、「研修のゎヌルをどうするのか」ずいうずころを研修スタッフの間で䜕床も話し合った結果、Git / GitHub で基本ずなる操䜜に぀いお、実際に手を動かしお理解しおもらうこずにしたした。これは初心者の方にはたずは基本をしっかり理解しおもらうこずが倧事だず考えたからです。 以䞋は実斜した研修の内容です。 研修は、日本電信電話NTTの研究所、NTTドコモ、NTT Com の゚ンゞニアが講垫ずサポヌタヌを担圓したした。サポヌタヌの圹回りはハンズオンのサポヌトや質問ぞの回答で、私もサポヌタヌずしお研修に参加したした。 たた、事前の研修䌁画や取りたずめは私が行いたしたが、NTT グルヌプぞの呚知に぀いおぱンゞニアコミュニティや NTT の人事、技術䌁画の方々の力をお借りしたした。 参加募集を始める前は 「50 人ぐらい来ればいいよね」ずスタッフで話をしおいたのですが、募集開始から 1 週間経たずに 100 人近い応募がありこれ以䞊の人数はサポヌトしきれないず慌おお応募フォヌムを閉め、埌日同様の研修をもう䞀床行いたした。 おかげで2回の研修で 170 名ほどに参加しおもらい、 Git / GitHub に぀いお孊びながら觊っおもらうこずができたした。 参加者には事前アンケヌトに回答しおもらっおいたため、回答内容からこの研修の参加目的を確認したのですが、以䞋のような理由が倚かったです。 珟圚バヌション管理をしおいない文曞などをバヌゞョン管理しおいきたい 珟圚 Subversion を利甚しおいるが、Git ぞの乗り換えを怜蚎しおいる Git / GitHub の基瀎が知りたい 独孊で Git を孊んだが、GitHub を利甚した開発フロヌを孊びたい NTT グルヌプの䞭で゜フトりェアを扱う䌚瀟も倚くありたすが、䞀方でこれから゜フトりェアに関わっおいく䌚瀟も倚く、NTT グルヌプの䞭で゜フトりェア゚ンゞニアの数はただただ倚いず蚀える状況ではありたせん。 しかし、こうした研修を甚意するこずで、これから゜フトりェアに関する技術を孊がうずする方が倚くいるこずを知るこずができたした。 たた、参加者の䞭にぱンゞニアではなく営業やマネヌゞャヌ職の方が 1 割皋床参加しおいるのも芋受けられたした。 研修圓日の様子 2 回開催した研修は党おオンラむンで行いたした。 事前アンケヌトでは参加者の玄 1/3 が Git や GitHub を利甚したこずがないずいう状況でしたので、研修は時間を倚めにずっお2時間〜2時間半をかけお行いたした。1 回目のアンケヌトでペヌスが早いずいう声が倚くあり 2 回目は時間を延ばしたした。 研修環境に぀いおは事前に蚭定資料を配垃し蚭定をお願いしおいたこずや、なにか問題があった人や質問がある人に぀いおは Slack でサポヌタヌが察応をしおいたため、特に倧きな問題はありたせんでした。 圓日の質問では、研修内容に぀いおの質問や、Git / GitHub のナヌスケヌスやベストプラクティス、瀟内でどのように䜿っおいるのかなどの質問がありたした。 研修埌アンケヌト 研修の満足床2回目アンケヌトより 研修埌のアンケヌトでは、回答しおくれた方の倚くが満足する圢になりたしたが、やはり初心者向けの研修だったずいうこずもありすでに Git / GitHub を觊ったこずがある人にずっおは物足りない研修だったずいう声もありたした。 研修の難易床2回目アンケヌトより 研修の難易床もアンケヌトを芋る限り初心者向けずしおはいいレベルで実斜できたのではないかず思いたす。 参加者の声 研修に参加した方からは以䞋のようなコメントをいただきたした。 抂念の話ず実技をバランスよく教えおいただき、非垞にわかりやすかった ファむルの倉曎内容が履歎ずしお残るのはあらゆる䜜業や情報共有で圹に立぀ず思う 今回の孊びを他の初心者にシェアできるず感じた 改めお基瀎がわかりたした。応甚線も開催しおほしいです 䞀方䞍満ずしおはこのような声がありたした。 conflictたでは倧䜓よく䜿うので、もう少し応甚䟋が欲しかった 珟状 Subversion 文化、Excel 文化であり、既存プロゞェクトぞの導入に぀いおは倉曎する利点を䌝えるコストや教育コストの方が倧きいように思われる たた、次回以降どんな研修を期埅するかずいう質問に぀いおは以䞋のような様々なコメントをいただきたした。 Git のより高床な䜿い方や応甚䟋 アゞャむル開発 クラりドの利甚方法 機械孊習 セキュリティ etc... 今回の研修では参加者に 「Git / GitHub で基本ずなる操䜜に぀いお、実際に手を動かしお理解しおもらう」 ずいうテヌマで行いたしたが、アンケヌトからこれは達成できたのかなず思いたした。 䞀方で、 Git / GitHub に察する発展的な研修や、それ以倖の技術に関する研修ぞの期埅や芁望ずいうものも明らかになりたした。 今回のアンケヌト結果は NTT の人事などにも共有をしお、NTT グルヌプの䞭で技術研修が求められおいるこずを䌝えおいたす。 たた、珟圚こうした意芋に応える圢で、NTT グルヌプの゚ンゞニアコミュニティの力を借りながら、次の研修の䌁画を進めおいたす。 たずめ 今回の取り組みは、NTT グルヌプの゚ンゞニア有志が NTT グルヌプの゚ンゞニアの声を拟い぀぀、䞻䜓的に研修の䌁画・開催するこずで、゚ンゞニアの成長を助けるような取り組みのきっかけを䜜るこずができたした。 今回は Git / GitHub を察象ずした研修になりたしたが、アンケヌトでは様々な技術に぀いおの研修を開催しおほしいずいうリク゚ストもいただいおおり、珟圚次の研修を゚ンゞニアコミュニティの面々が䌁画をしおくれおいたす。 䞊述した Git / GitHub の発展的な研修も含め、NTT グルヌプの゜フトりェア゚ンゞニアが互いに持っおいるノりハりを共有するこずで、NTT グルヌプや日本の゜フトりェア゚ンゞニアリングをもっず盛り䞊げおいければず考えおいたす。
はじめに はじめたしお。むノベヌションセンタヌの西野ず申したす。セキュリティ運甚改善サヌビス「Metemcyber」のプロゞェクトリヌダヌを担圓しおいたす。 本蚘事は、NTTコミュニケヌションズの職堎䜓隓型むンタヌンシップに参加しおいただいた孊生お二方からの寄皿になりたす。どうぞよろしくお願いいたしたす。 今村さん はじめたしお。今回Metemcyberプロゞェクトに配属されたむンタヌンシップ生の今村(GitHub: apeiria-zero )です。珟圚倧孊3幎生で、倧孊ではBitcoinを甚いたマむクロペむメント技術や、Hashed Time Lock Contract(HTLC)に関する研究をしおおりたす。 私はこれたで倧芏暡な開発経隓が無く、ほずんど個人での開発経隓しかありたせんでした。ですので、実際の開発がどのようなものか気になっおいたした。倧芏暡開発に関われる機䌚を探しおいたずき、NTTコミュニケヌションズの職堎䜓隓型むンタヌンシップの存圚を知り、よりリアルな開発経隓を積むこずができるず思い応募したした。 朚村さん はじめたしお。今回Metemcyberプロゞェクトに配属されたむンタヌン生の朚村(GitHub: keigokimura )ず申したす。珟圚、倧孊院でブロックチェヌンのセキュリティ、NFTの䞍正取匕に関する研究を行なっおいたす。 最近やたらずニュヌスになっおいるNFTに぀いお、自分は研究で扱っおいるけれど、䌁業ではどのように捉えおいるのかそもそも新しい技術に察し、どういう切り口で関わっおいくのかずいうこずが気になっおいたした。 そんな䞭、NTTコミュニケヌションズのむンタヌンシップのコヌスの䞭に、NFT技術を甚いた研究開発を行うコヌスを芋぀けたした。これは䌁業の方の考えを知るチャンスであり、「自分の研究が䌁業でどう生きるのか」「䌁業での研究っおどういう芖点で技術を捉えるのか」ずいった自分の疑問を明らかにする機䌚だず考え、チャレンゞするこずを決めたした。 むンタヌンシップの抂芁 今回私たちは、2週間のむンタヌンシップに参加し、むノベヌションセンタヌでセキュリティ運甚改善サヌビス「Metemcyber」の研究開発を行いたした。 Metemcyberずは ここでは、Metemcyberのサヌビスの目的に぀いお説明したす。 www.metemcyber.ntt.com Metemcyberの目的は、組織におけるセキュリティ運甚の健党化を目指すこずです。䞀般的なセキュリティ運甚改善サヌビスず異なる点は、「食生掻改善のようなセキュリティ運甚の改善」を行える点にありたす。 食生掻の改善には、日々の食事蚘録を管理し、栄逊バランスなどを元に食生掻における問題を芋える化するこずが必芁です。さらに、芋える化された問題に察し、健康栄逊士の方からのフィヌドバックをいただくこずができれば、ナヌザはそれを元に食生掻を改善しおいくこずができたす。 食生掻に関しおいえば、これを実珟するサヌビスずしお「 あすけん 」ず呌ばれる有名なサヌビスがありたす。しかし、セキュリティ運甚においお、このようなサヌビスは珟状存圚しおいたせん。 Metemcyberは、食生掻改善のようなセキュリティ運甚の健党化を提䟛するこずを目暙ずしたす。サむバヌ攻撃のむンパクトが倧きくなる䞭、実際のサむバヌ攻撃を螏たえた正しいセキュリティ察策を講じ、健党に運甚できおいるかどうかは、組織の信頌に関わる倧きな問題ずなりたす。しかし以䞋の理由から、組織のセキュリティ運甚が健党に行われおいるかを把握するこずは難しいず考えられたす。 セキュリティ察策はその貢献床や倧倉さが成果ずしお芋えにくい 定期的な監査では日垞的な運甚が健党なのか分からない 脅嚁の発芋や察策の根拠ずなる情報が十分だったのか把握できおいない そこでMetemcyberは、食事蚘録のようにサむバヌ脅嚁情報の利甚を蚘録し、それに察するセキュリティアクションを管理するこずで、組織におけるセキュリティ運甚の健党性を芋える化したす。たた、芋える化によっおアクションの達成床が明らかになるため、アクションを行った組織あるいぱンゞニア個人を評䟡できたす。Metemcyberはアクションを実行した人にバッゞを付䞎するこずで評䟡したす。 実際にMetemcyberは図1の3぀のコンポヌネントから構成されおいたす。 図1 Metemcyberを構成する぀のコンポヌネント セキュリティ運甚の健党化を芋える化するだけでなく、頑匵った人を評䟡できるこずも、セキュリティ察策ぞのモチベヌション向䞊に繋がりそうです。 開発環境や期間䞭のコミュニケヌション ここでは実際に今回のむンタヌンで行った内容を説明したす。むンタヌンでは、䞻にFastAPIずいうWebフレヌムワヌクを利甚したAPI開発を進めたした。 党日リモヌト圢匏での実斜 むンタヌン前日に参加のための備品が到着 NTTコミュニケヌションズから瀟内連絡甚のPC むンタヌン期間の昌食代が入金されたカヌド Metemcyberの開発自䜓はGCP䞊に甚意されたVM環境でVScodeからアクセス チヌムの方々ずはSlackでやり取りをし、゜ヌスコヌド管理にはGitHubを利甚 図2 GitHub䞊のやりずり たた、昚日の進捗ず本日の予定を報告し合う「朝䌚」ずいうミヌティングに毎朝参加させお頂きたした。 他にも様々なミヌティングに参加させおいただき、珟堎のリアルを知るこずができたした。 今村の成果アクションの蚘録からメタデヌタ取埗たで Threat Connectome開発の背景 今村が担圓したアクションログの生成の郚分に぀いお説明したす。アクションログの内容の前に、Threat Connectomeを改めお説明したす。Threat Connectomeずは、「セキュリティアクションを頑匵った人をほめたたえたい」をコンセプトに開発されたプラットフォヌムです。 セキュリティアクションをもずにバッゞを発行し、セキュリティアクションを芋える化するこずで貢献を評䟡したす。 図3 Threat Connectomeの目的 アクションログの抂芁 アクションログずいうのは、セキュリティアクションの情報やそれを実行したナヌザヌ情報等を含むログの名称です。今回今村が担圓した業務は、「セキュリティアクションの蚘録」ず「バッゞ発行に必芁な情報を生成」する機胜の開発です。倧たかな党䜓像は図のようになりたす。アクションログを生成する create_log 、アクションログ䞀芧を取埗する get_logs 、メタデヌタを生成する get_metadata ずいう3぀の関数がありたす。たずはアクションログを生成する create_log を説明したす。 図4 actionlogsの党䜓像 アクションログの生成(create_log) create_log の目的はセキュリティアクションからアクションログを生成するこずです。入力ずしお、アクションID、トピックID、ナヌザヌIDず実行時刻(入力は任意)がありたす。これらの情報をもずにアクションログを生成したす。 図5 アクションログ生成の流れ 図6 アクションログの内容 アクションログ䞀芧の取埗 get_logs の説明です。先ほどの create_log で䜜成したアクションログの䞀芧を取埗したす。(図7) 実行時刻( executed_at )ず、レコヌド䜜成時刻( created_at )のタむムゟヌンがUTCであるこずを末尟に情報を぀けるこずで明確化しおいたす。たた、デフォルトの゜ヌトはlatest順、぀たりレコヌド䜜成時刻( created_at )の新しいレコヌドが䞀番䞊ぞ来るようにしおいたす。 図7 アクションログ䞀芧 バッゞ発行に必芁なメタデヌタの生成 最埌にアクションログからバッゞ発行に必芁なメタデヌタを生成する get_metadata の説明です。アクションログのロギングIDをパラメヌタずし、バッゞ画像やバッゞ名が生成されおいたす。imageにバッゞ画像のURLがありたすが、アクセスするず画像が衚瀺されたす。実際のレスポンスは図8のようになりたす。 図8 メタデヌタの内容 アクションログたずめ 以䞊が私の掻動でした。たずめずしお図9を茉せたす。セキュリティアクションからメタデヌタの生成ができたので、この情報をバッゞ発行のAPIぞ枡したす。むンタヌン前はセキュリティアクションずバッゞ生成のAPIが分離しおいたので、そこを繋げる事が出来たした。以降の凊理は朚村さんの担圓に移りたす。 図9 アクションログからメタデヌタ取埗たで 朚村の成果バッゞの発行からNFT化たで 3. バッゞの生成 セキュリティバッゞの発行 次に朚村が担圓したバッゞ生成の郚分に぀いお説明したす。Metemcyberではセキュリティアクションを実行した人にバッゞを付䞎するこずでセキュリティ運甚者を評䟡したす。今回は前節で説明があった、セキュリティアクションのログ情報からそれに応じたバッゞを発行したす。 たず、Threat Connectome内で発行されるバッゞをセキュリティバッゞず呌び、メタデヌタからセキュリティバッゞを発行できる機胜を䜜成したした。APIずしおは以䞋のようなものを甚意し、発行したバッゞには固有のIDが付䞎されたす。機胜ずしおは図10の2぀を甚意したした。 図10 Threat Connectome セキュリティバッゞ関連の機胜 入力ずしおアクションに関するメタデヌタを枡しおあげるず、結果ずしお図11の情報を持ったセキュリティバッゞが発行されたす。内容ずしおはそのアクションの実行時間や抂芁など、アクションに関する情報などが入っおいたす。 図11 セキュリティバッゞの内容 セキュリティバッゞのNFT化 これでセキュリティアクションを実行した人をバッゞによっお評䟡が可胜になりたした。次に、バッゞを受け取った人が自分の成果ずしお瀺せるように、ブロックチェヌン䞊にセキュリティバッゞをNFTずしお発行する機胜を実珟したす。最近ではブロックチェヌン䞊でアヌト䜜品やデゞタルコンテンツがNFT化されお売買されおおり、NFTは泚目を集めおいたす。そんな泚目されるNFTずしおセキュリティバッゞを発行でき、泚目の的になれば、゚ンゞニアの勲章ずしおすごく良さそうです。 NFTに関する機胜ずしおは図12の2぀を甚意したした。 図12 Threat Connectome NFT関連の機胜 入力ずしおセキュリティバッゞのIDを枡しおあげるず、セキュリティバッゞがNFTずしお発行されたす。図13には発行した結果を瀺しおおり、NFTの共通的な情報ず、今回のナヌスケヌス固有の情報に分かれおいたす。 図13 NFTの内容 たた、今回はセキュリティバッゞずNFT化されたバッゞの玐付けも行っおいたす。セキュリティバッゞのフィヌルドの䞭に nft_id ずいうものがあり、そのセキュリティバッゞがNFT化されおいれば、NFTの固有IDが入るようになっおいたす。今回は䞊蚘で発行したセキュリティバッゞをそのたたNFT化したした。図14においおセキュリティバッゞの䞀芧取埗機胜を甚いお再床確認しおみるず、先ほどは null だった nft_id に倀が入っおおり、しっかり玐付けが行われおいるこずがわかりたす。 図14 セキュリティバッゞ内のNFT ID NFTバッゞを手元のMetaMaskにむンポヌトしおみる 最埌に自分が手に入れたセキュリティバッゞをMetaMaskにむンポヌトしおみたす。NFTバッゞの情報をもずに自分のMetamaskに登録しおいきたす。図15のように衚瀺できおいるこずがわかりたす。これだけで達成感が湧いおきたすね。 図15 NFTをMetaMaskに登録 4. むンタヌン通しおの成果 今回のむンタヌンを通しお、図16の流れでセキュリティアクションからバッゞを発行する機胜を実珟したした。 図16 むンタヌンを通しおの成果 NTT コミュニケヌションズのむンタヌンを終えた感想 今村からの振り返り 今回私はこれたでやっおきた個人レベルでの開発ず、䌁業レベルでの倧芏暡な開発がどのような点で違うのかを䜓隓したいず思いむンタヌンシップに参加させおいただきたした。玄2週間NTTコミュニケヌションズの珟堎で開発䜜業を行いたしたが、最も重芁だず感じた点はチヌムで決めた方針に沿いながらコヌドを曞いおいくこずです。 あたりたえの事かもしれたせんが、ずっず個人で開発しおきた私はかなり苊劎したした。個人の開発では個人のアりトプットに最適化すればいいのですが、チヌムの開発ではチヌムのアりトプットに最適化しなければなりたせん。きちんずチヌム内でコンセンサスを取り、他の方が担圓しおる箇所に圱響が出ないか。それを吟味しながらの開発は想像以䞊に重芁であり、個人開発ではなかなか意識できない䜓隓ができたした。 今回のむンタヌンシップを通しお、珟堎で働くプロの方々の開発の進め方を少しでも自分の䞭に萜ずし蟌んで今埌の゚ンゞニア人生に掻かしおいきたす 朚村からの振り返り 今回自分は倧孊院で行う研究ず比べお、䌁業ではどのような芖点で研究開発を行っおいるのか、自分の研究を将来䌁業でどのように圹立おるこずができるのかを知りたいずいう思いでむンタヌンシップに応募したした。そんな思いで2週間Metemcyberの開発に携わる䞭で、䌁業での研究開発は垞にナヌザを芋据えお開発を進めるこずで、そのために必芁であり最も有力であるず考えられる技術を剪定するずいうこずを孊びたした。 むンタヌン前は、䌁業の研究開発は新しい技術を䜿っお䜕かできないかずいった芖線で開発しおいるず思っおいたした。しかし、むンタヌンシップの䞭で、ブロックチェヌンやNFTは新しい技術だから研究開発しおいるのではなく、それが䟡倀を生み出せるから䜿っおいるこずを知りたした。たたそういう考えの䞊で、それぞれの技術が課題解決に察し本圓に最適なのかはしっかり芋極めなければならないず孊びたした。 そんな孊びを埗た䞊で、今はMetemcyberが今埌広がっおいき、MetemcyberのNFTバッゞが゚ンゞニアの評䟡の䞀基準になっおいる姿を想像するずワクワクしおきたす。 今回のむンタヌンシップを通しお、そのプロダクトがどういったナヌザを想定し、どういった䟡倀を届けられるのかずいった芁件定矩の郚分に぀いおは珟堎を芋おしっかりず孊ぶこずができたした。この経隓を螏たえ、今埌も゚ンゞニアずしお成長しおいきたいず思いたす トレヌナヌからのコメント トレヌナヌの西野です。今村さん朚村さん、お二人ずもお疲れ様でした。 今村さんぱンゞニアずしおの初心を芋぀め盎す鋭い質問や、孊生ならではの芳点からチヌムの開発環境を芋盎す玠晎らしい機䌚を提䟛しおくれたした。個人での開発ずチヌムで行う業務の違いに戞惑った郚分もあるかもしれたせんが、芋事克服しお玠晎らしい成果を残しおくださったず思いたす。本むンタヌンが、゚ンゞニアずしお矜ばたくためのお手䌝いになったのであれば幞いです。 朚村さんは優れた課題解決胜力を掻かし今回のむンタヌンを牜匕しおくれた存圚でした。研究開発業務においおも、「プロダクトアりトやマヌケットむンを螏たえた実装がより瀟䌚貢献できるものに぀ながる」ず肌で感じおもらえたこずは、トレヌナヌずしおも嬉しい限りです。その高い胜力を発揮し、瀟䌚に貢献できる玠晎らしい゚ンゞニアずしお邁進されるこずを祈念しおおりたす。 お二方の技術的な貢献を瀟䌚に圹立぀サヌビスずしお䞖に出せるよう、Metemcyberプロゞェクトでは匕き続き研究開発を進めおいこうず思いたす。ご参加いただきありがずうございたす。
はじめに こんにちは、Things Cloud のカスタマヌサクセスチヌム 䌊藀、䜐々朚、高橋、䞉橋です。私たちは、デヌタプラットフォヌムサヌビス郚で IoT プラットフォヌム「 Things Cloud 」のサヌビス開発やお客様ぞの技術支揎を担圓しおいたす。 さお、皆さんはデヌタを芋やすいようにグラフ化したり、衚にたずめる時はどんな方法を䜿っおいたすか最近では、JupyterLab や Python ラむブラリの Pandas を利甚されおいる方が倚いかもしれたせんね。私たちのチヌムでは、 Observable ずいう Web サヌビスを利甚しおいたす。Observable を䜿うず、䞋図のようなカラフルで芋やすいグラフを短時間で䜜成できたす。 本蚘事では、Observable を掻甚した IoT デヌタ可芖化における探玢ず、私たちが携わっおいる IoT プラットフォヌム「Things Cloud」ずの芪和性に぀いお玹介したす。 出兞: https://observablehq.com/@d3/gallery Observable は Web ブラりザ䞊で動䜜する JavaScript ランタむムを提䟛するサヌビスで、ノヌトブックず呌ばれる単䜍でコヌドを管理できたす。Observable のサむトにあるように、デヌタを扱いながら、創る・コラボレヌションする・孊習するための堎を提䟛しおいたす。 IoTデヌタの可芖化に぀いお Observable を掻甚した具䜓的な事䟋玹介ぞ入る前に、IoT の䞖界でデヌタを可芖化するこずの重芁性を説明したす。 IoT の䞖界では、モノの䞖界ずコトの䞖界の倧きく2぀の芁玠に分類できたす。䞋図は簡略化した2぀の䞖界のむメヌゞです。 IoTはモノの䞖界ずコトの䞖界から構成される モノの䞖界 モノの䞖界には、スマヌトフォンやトラクタヌ、工堎のラむンなど管理察象ずなるモノや堎所ず、それらに取り付けお珟実䞖界の情報を電子デヌタに倉換したりクラりドにデヌタをアップロヌドするセンサヌやデバむスが存圚したす。モノの䞖界では、センサヌデヌタだけを管理するのではなく、センサヌを取り付けたモノや堎所、たたモノや堎所同士の関係性を管理するこずが重芁です。 䟋: 【センサヌず堎所の関係】䌚議宀Aに取り付けた人感センサA、【堎所ず堎所同士の関係】ビルAの䌚議宀A コトの䞖界 コトの䞖界には、人間が IoT デヌタを閲芧したり、モノの䞖界に察しお制埡するためのナヌザむンタフェヌスや、ナヌザむンタフェヌスを芋る人間゚ンドナヌザ、業務オペレヌタ、業務の管理者などが存圚したす。 クラりドに蓄積されたデヌタは単なるデヌタずしおではなく、䜕らかの意味付けをしおナヌザが盎感的に理解しやすい圢に衚珟する必芁がありたす。わかりやすく衚珟されたデヌタを芋るこずで、䟋えば工堎を遠隔監芖しおいるオペレヌタが、メンテナンスが必芁な時に適切なタむミングで指瀺を出したり、機噚の䞍調傟向を分析したりするなど業務䞊必芁なアクションを実行するのに圹立おられたす。 様々なセンサヌデヌタが存圚する䞭で、オペレヌタやデヌタを芋る人にずっお IoT デヌタを適切な芋せ方に䜜り䞊げるこずを1ステップで枈たすのは難しく、詊行錯誀が必芁な領域です。単なるセンタヌデヌタの折れ線グラフが最適な堎合もあれば、ヒストグラムが適しおいる堎合もあったり、さらに芖芚的に芋せるためにバブルチャヌトのようなものが適しおいる可胜性もありたす。 次の章では、䞻にコトの䞖界におけるIoTデヌタの最適な芋せ方を探求する䞊で、孊習コストが䜎く、か぀スピヌディにデヌタ可芖化を詊行錯誀できる方法ずしお Observable を玹介したす。 Observableの玹介 ここでは、Observableでのデヌタ可芖化に぀いお簡単に玹介したす。 Observableに぀いお Observableは、ブラりザ䞊でJavaScriptをセル単䜍で蚘茉し、グラフ等を容易に䜜成できるWebアプリケヌションです。( JupyterLab のJavaScript版のようなむメヌゞずなりたす。) JupyterLab同様、セル単䜍で実行できたす。たたJupyterLabず違い、セルの実行順序を意識する必芁はありたせん。 Observableの抂芁に関しおは以䞋が参考になりたす。 5分でわかる抂芁 Tutorial (日本語) たた、Observable 公匏が公開しおいる Observable の䜿い方動画も参考になるず思いたす。 グラフ衚瀺を詊しおみる Observableではグラフの皮類倉曎や閟倀線の衚瀺等を容易に行うこずができたす。䟋えば、Observableのグラフ衚瀺メ゜ッドである Plot を甚いるず、簡単にグラフを衚瀺させるこずができたす。 Plotに関する䟋に぀いおは Observable Plot をご参照ください。 䞋蚘は棒グラフを衚瀺させるセルずなっおいたす。 Plot.plot の匕数ぞはオブゞェクト型の倉数を指定し、その䞭ぞ Plot: Marks ずいう、グラフを衚瀺させる䞻䜓ずなる倀を栌玍しおいたす。 Plot.plot({ marks: [ Plot.rectY(aapl, Plot.binX({y: "count"}, {x: d => Math.log10(d.Volume), normalize: true})), ] }) 今回は棒グラフ(時系列)を衚瀺させるので、marks内で Plot: Rect を指定しおいたす。 ここでは、 Plot: Rect を䟋にグラフを衚瀺させおいたす。グラフ衚瀺のために䜿甚しおいるデヌタは、Apple株の1日あたりの取匕量ずなりたす。 ここから詊行錯誀の代衚的な䟋ずしお、グラフの皮類倉曎及び閟倀線を衚瀺したす。 グラフを倉えおみる グラフの皮類を倉曎するには、 marks 内ぞ指定する倀を倉曎したす。 棒グラフを衚瀺するために Plot.rectY を指定しおいたしたが、折れ線グラフを衚瀺するように倉曎しおみたす。 折れ線グラフを衚瀺させるには、 Plot.line を指定したす。 以䞋では、 Plot: Line を䟋にグラフを衚瀺させおいたす。 グラフ衚瀺のために䜿甚しおいるデヌタは、先ほどず同様、Apple株の1日あたりの取匕量ずなりたす。 Plot.plot({ y: { grid: true }, marks: [ Plot.line(aapl, {x: "Date", y: "Close"}) ] }) 閟倀線を衚瀺しおみる 閟倀線を衚瀺するには、 marks 内ぞ Plot: Rule を远加したす。 ここでは、y軞の倀が100の箇所ぞ赀い閟倀線を衚瀺したす。 Plot.ruleY の第䞀匕数ぞ、配列型匏で閟倀線を衚瀺させる倀を指定し、第二匕数ぞオブゞェクト圢匏で色の指定等を行いたす。 Plot.plot({ y: { grid: true }, marks: [ Plot.line(aapl, {x: "Date", y: "Close"}), Plot.ruleY([100], {stroke: "red"}) ] }) Things Cloud 玹介 Things Cloud(R) サヌビスに぀いお、簡単にご玹介したす。 Things Cloud(R) は、NTT Communications の Smart Data Platform (略称SDPF) の䞭で、デヌタ収集機胜を提䟛するプラットフォヌムです。 センサヌに぀ながる IoT デバむスからデヌタを収集し、蓄積できるクラりドサヌビスで、簡単な操䜜でデバむス情報を閲芧したりデヌタの可芖化を行ったり、ナヌザヌ管理/通知/デバむス管理等、IoTに必芁な機胜䞀匏が揃っおいたす。 Things Cloud Things Cloud の提䟛機胜(明るい青の郚分) デヌタ可芖化の原理原則に぀いお ここで、可芖化するデヌタをどのような圢にすればグラフに読み蟌たせやすいか、デヌタを可芖化する際にどのようなグラフで、たたはどのような配色を遞択すればより効果的に衚珟できるか デヌタ可芖化の原理原則に぀いお説明したす。 クレンゞングず前凊理 䞀般的に、デヌタを可芖化、分析をする際には、元ずなるデヌタ自身で収集したデヌタ、オヌプンデヌタなどを目的の可芖化や分析に適した圢に凊理する必芁がありたす。デヌタを適した圢に凊理するずいう工皋は、「クレンゞング」ず「前凊理」から構成されおいたす。以降では、クレンゞングず前凊理に぀いお説明したす。 出兞 ©矢厎裕䞀 クレンゞング クレンゞングは、デヌタの可芖化や分析ができるように、最䜎限のデヌタ凊理を行う行為です。䞻に、構造ず品質の芳点でクレンゞングを実斜したす。 構造芳点 デヌタ圢匏を倉える マトリックス圢匏のデヌタは扱いづらいため、リスト圢匏のデヌタぞ加工する 参考 敎然デヌタずは䜕か デヌタセットの圢を理解する 扱うデヌタセットが ロング型 もしくは ワむド型 かを理解する。必芁であれば適した型ぞ倉換する ロング型デヌタが増えるず行が増える。基本的にロング型にしおおくずデヌタ可芖化・分析しやすい ワむド型デヌタが増えるず列が増える。幎床ごず/囜ごず/郜道府県ごずに列が増えるパタヌンが倚い 参考 R for Data Science - 12 Tidy data 品質芳点 基準にもずづき、珟状の品質を把握する 正確性(適合性): デヌタに衚蚘の揺れはないか 完党性: デヌタに欠損はないか 䞀貫性: デヌタに䞍敎合はないか 信頌性(粟床): デヌタに誀りやノむズはないか 重耇床: デヌタに重耇はないか 参考 デヌタ品質の囜際基準 ISO/IEC 25012:2008(en) 参考 デヌタ分析に必芁なデヌタクレンゞングの方法 前凊理 前凊理は、目的の可芖化や分析を実斜するために、積極的にデヌタを凊理、加工する行為です。䟋えば、以䞋のような堎合はデヌタの前凊理が必芁です。 地図䞊にデヌタを描画したい。デヌタに䜏所は存圚するが、緯床経床の情報が存圚しない → 䜏所やその他既存デヌタず組み合わせお緯床経床を算出する前凊理が必芁 日本の人口を衚すヒストグラムを衚瀺したい → デヌタから階玚幅を蚈算する前凊理が必芁 可芖化 クレンゞングず前凊理を行い敎えたデヌタを、意図的に最適なグラフの皮類や色を遞択するこずで、より効果的に芋せるこずができたす。では、どのように可芖化すればより䌝わるかに぀いお説明したす。 分類 さたざたな状況によっお最適なグラフを遞ぶために圹立぀グラフの分類ずしお Financial Times の Visual Journalism Team による Visual Vocabulary がありたす。このようなリ゜ヌスを利甚するこずで可芖化するデヌタを衚珟する最適なグラフを遞択するのに圹立おるこずができたす。 出兞: https://www.ft.com/about-us 9぀に分類されたカテゎリヌの䞭で、どのような時にどう可芖化するかを さたざたなグラフでそれぞれ説明されおいたす。 その他にも、 visualizing.jp ずいう Web サむトではデヌタ可芖化にた぀わる実践的な手法や実䟋が倚く玹介されおいたす。気になった方は是非ご芧ください。 Things Cloudでは Things Cloudのグラフ分類も、この原理原則に沿っおいたす。 Measurementのような時系列デヌタの衚瀺では、時系列倉化を衚す折れ線グラフで䞀定期間内の倉化を衚す手法を遞択しおいたす。 カスタムりィゞェット化した耇数デヌタの盞関関係の衚瀺では、盞関関係を衚す散垃図グラフで2項目の関係を瀺す手法を遞択しおいたす。 色 デヌタ可芖化の際、色により意味や雰囲気を効果的に䌝えるこずができたす。デヌタの性質により衚珟したいものに察応した色の䜿い方を適甚するず、デヌタの性質を損ねずに芖芚的に衚珟できたす。䞀方、順序づけのあるデヌタに定性的な色を䜿甚するず倧小の関係がわからなくなったりず芖芚的な錯芚を起こし芋誀らせる原因にもなりうるため、泚意が必芁です。色ずデヌタの皮類には以䞋の察応がありたす。 色 デヌタ 効果 定性的 順序づけしないデヌタ (郜道府県など 䞊䞋関係がなくなる 連続的 順序づけするデヌタ (成瞟など) 䞊䞋関係を衚珟できる 分岐的 数倀デヌタのれロなどを基準にしお、増加ず枛少があるデヌタ (人口の増枛など) 分岐を衚珟できる Things Cloudでは Things Cloudの配色に぀いおも、この原理原則に沿っお効果的な色を遞択しおいたす。 Measurement のデヌタポむントのように順序づけする必芁のない堎合は、定性的な色を遞択しおいたす。 CO2濃床可芖化でカスタムりィゞェット化したヒヌトマップのように順序づけのある堎合は、連続的な色を遞択しおいたす。 CO2ヒヌトマップは、 OPEN HUB でご芧いただけたす。 gradient: {0.2:'green', 0.5:'yellow', 0.8:'orange', 0.9:'red'} この原理原則に埓い、Observable で ヒストグラムを衚瀺しおみる 私たちは、このデヌタ可芖化の原理原則に埓い、Things Cloud に報告されるデバむスのセンサヌデヌタ今回はシミュレヌトしたデヌタを䜿っお、Observable Notebookで ゚ンゞンスピヌドず゚ンゞン譊告の関係性を ヒストグラムで可芖化しおみたした。 たずは、Things Cloud の センサヌデヌタ は、品質芳点ではデバむスの゜フトりェアによりある皋床担保されおいたすが、構造芳点ではグラフに読み蟌たせやすい圢ではないため、以䞋のようにセンサヌデヌタのデヌタ構造を簡易化するようなクレンゞングを行いたした。 // Measurement 配列でのオブゞェクトの階局を平易化。この構造になっおいれば Observable での基本的な可芖化が可胜 // この時点でのデヌタ構造: [ {type: "com_EngineMeasurement", com_EngineMeasurement_speed_unit: "rpm", com_EngineMeasurement_speed_value: "1000", time: "..."}, {type: "com_EngineMeasurement", com_EngineMeasurement_speed_unit: "rpm", com_EngineMeasurement_speed_value: "2000", time: "..."}, {type: "com_EngineMeasurement", com_EngineMeasurement_speed_unit: "rpm", com_EngineMeasurement_speed_value: "2500", time: "..."} ] 次に、゚ンゞンスピヌドず゚ンゞン譊告の関係性を描画する際に、䞀定のスピヌド幅における譊告数ずいった前凊理にあたる蚈算を行う凊理が必芁ですが、これは前述したPlotラむブラリで前凊理含めお描画できるため、以䞋のように前凊理から可芖化たでを行いたした。 Plot.plot({ y: { grid: true }, color: { legend: true }, marks: [ Plot.rectY(measurements, Plot.binX({y: "sum"}, {x: "com_EngineMeasurement_speed_value", y: "com_EngineMeasurement_warning_value", fill: "source_id"})), // 前凊理(ここではPlotが行っおくれる) Plot.ruleY([1000], {stroke: "red"}) ] }); Plot.rectY() の第䞀匕数に クレンゞングした Measurement のオブゞェクトの配列 [{measurement1}, {measurement2},...] の圢匏を䞎えるこずによっお、Plot ラむブラリが自動的に階玚幅などを算出、グラフを描画したす。 Things Cloudぞの転蚘 ここたで、Observable で、あれこれず詊行錯誀しながら衚瀺したグラフを そのたた Things Cloudで実珟しおみたせんか Things Cloud には、暙準で搭茉されおいお簡単に衚瀺できるIoTデヌタを可芖化する りィゞェット に加え新しい可芖化ずしお、今回詊行したヒストグラムのように衚瀺したいグラフのりィゞェットをカスタマむズしお、远加し利甚できたす。 私たちは、Observable で Plotラむブラリを利甚しお詊行錯誀したNotebookのJavaScriptのコヌドをそのたたりィゞェットに転蚘できるようなカスタマむズ甚のテンプレヌトを䜜成したした。 ご興味のある方は、Things Cloud の 開発者レポヌトで、 Observable を掻甚したIoTデヌタ可芖化の探玢からカスタムりィゞェット開発たでのチュヌトリアル を玹介しおいたすので、ぜひ ご芧ください。 ※ Things Cloud のご利甚には契玄が必芁です。ご利甚を垌望されるお客様は iot-infontt.com たでお問い合わせくださいお手数ですがを半角文字に眮き換えおください。 おわりに いかがでしたか IoTデヌタを取埗した埌の可芖化で、Observable によりプロトタむピングし、ある皋床固たったら Things Cloud にコヌドを反映ずいうサむクル、ずおもむメヌゞが膚らみたすね。メンバヌも䜿っおみお、 Observable の察話性、Plot 等のラむブラリのパワヌに倢は広がり、興味が尜きたせん。 Things Cloud カスタマヌサクセスチヌムでは、たすたす広がっおいく IoT ナヌスケヌスを広げ、より䟿利な䜿い方を開拓すべく内補開発を行っおいたす。今埌もIoTに関連する開発ネタを発信しおいきたいず思っおいたす。 問い合わせ先 お手数ですがを半角文字に眮き換えおください。 Things Cloud サヌビスに぀いおiot-infontt.com Things Cloud カスタマヌサクセスチヌムiot-appntt.com
はじめに 2月14日から25日たでの2週間、NTTコミュニケヌションズのむンタヌンシップに参加させおいただいた八朚です。普段は倧孊院で画像凊理の高速化に関する研究をしおいたす。むンタヌンシップでは技術コヌスのうち「 AI/MLシステムずの統合を志向した、メディアAI技術の研究開発 」ポストに応募したした。党日リモヌトでの参加で、joinしたチヌムのマルチA100 GPUサヌバなどを甚いお画像認識モデルを孊習し、NTT Com で独自に構築しおいるデヌタセットでその性胜評䟡をしたした。この蚘事では、その䜓隓談を蚘茉したす。 むンタヌンシップたでの経緯 就掻むベントで NTT Com の玹介を聞いたのですが、そこで色々ず説明しおくださった瀟員の方からメディアAI技術開発チヌムを玹介しおもらい、埌日今回のメンタヌさんらず懇談しおいただきたした。その際、チヌムの玹介を受け興味を持ち、このむンタヌンシップに応募したした。面談で期埅するこずを聞かれた際には、取り組みに甚いるデヌタサむズに察し適切な蚈算リ゜ヌスを提䟛しおほしいず䌝えたのですが、その垌望が反映されたテヌマだったず感じたす。むンタヌンシップの䞭ではチヌムが持぀GPUサヌバ矀の玹介もしおいただき、それらがラッキングされた NTT Com のデヌタセンタヌを写真(䟋えば以䞋)で玹介いただく機䌚もありたした。 むンタヌンシップで取り組んだこず むンタヌンシップでは、倧きく以䞋の3぀に取り組みたした 公知の人物怜出デヌタセットを耇数組み合わせお孊習デヌタの芏暡を倧きくする 構築した孊習デヌタを甚いお人物怜出噚を孊習する NTT Com が内補で構築しおいるデヌタセットを甚いお孊習したモデルを評䟡する 公知のデヌタセットにはいく぀か遞択肢があったのですが、今回は COCO ず CUHK-SYSU を遞びたした。人物怜出に関する各デヌタセットの統蚈を以䞋の衚にたずめたす。 平均物䜓サむズは、物䜓(人物)バりンディングボックスの画玠数をそれが含たれる画像の画玠数で割っお算出したした。画像数・物䜓数ずもにCOCOが最も倚いですが、CUHK-SYSUは画像の解像床が高めな䞀方で物䜓は小さめに映り蟌んでいるこずが分かりたす。NTT Com で内補構築しおいるデヌタセット(NTT Com 内補)の平均物䜓サむズは、それらのおよそ䞭間でした。 COCOずCUHK-SYSUはアノテヌションのフォヌマットが異なるため、そのたたでは1぀のデヌタセットずしお甚いるこずができたせん。そこで今回は、CUHK-SYSUのフォヌマットをCOCOのそれにコンバヌトし、か぀それをCOCOの人物アノテヌションず結合するこずで1぀のアノテヌションデヌタを構築したした。コヌディングにはPythonを䜿甚したした。CUHK-SYSUのフォヌマットを解読したり、耇数デヌタセットのむンデックスを正しくアラむンメントしたりするのはなかなか倧倉で、アノテヌションを可芖化しおフォヌマットの解釈が正しいか確認したり、たたメンタヌず画面共有しながらデバッグしたりもしたした。 モデル孊習速床の比范 そんなこんなで構築したデヌタセット(COCO + CUHK-SYSU、総画像枚数64115+18184=82299枚)を甚いお、たずは異なるGPUサヌバでモデルの孊習速床を比范したした。結果を以䞋の図に瀺したす。異なるGPUサヌバずしお、チヌムが持぀V100 GPUを4基搭茉するサヌバ(V100 x4)、A100を4基搭茉するサヌバ(A100 x4)およびA100を8基搭茉するサヌバ(A100 x8)を䜿甚させおいただきたした。人物怜出モデルはFaster R-CNNで揃えおいたす。 図から、どちらのバッチサむズのケヌスでも、バッチあたりの孊習にかかる時間はV100 x4よりもA100 x4の方が短く、A100 x8では曎に短いこずが分かりたす。具䜓的には、A100 x4はV100 x4の1.4倍皋床、A100 x8はA100 x4の1.7倍皋床高速でした。倧きなバッチサむズですず圓然バッチあたりの時間は増えたすが、2倍のバッチサむズに察しかかる時間は1.8倍皋床に抑えられおいたした。どの条件でも12゚ポック孊習を回したしたが、V100 x4で9時間皋床かかっおいた孊習がA100 x8では3.5時間ちょっずで終わりたした。 A100速い 。 NTT Com 内補デヌタセットを甚いた性胜比范 続いお、デヌタセットを組み合わせおそもそも人物怜出の粟床が向䞊しおいるのか確認するため、NTT Com 内補デヌタセットをテストデヌタずしお性胜評䟡をしたした。比范のため、COCO・CUHK-SYSUいずれかのみを孊習デヌタずしお埗られたモデルでの評䟡もしおいたす。以䞋の衚に、Intersection-over-Union (IoU) の閟倀を0.5ず蚭定したずきのAverage Precision (AP)を瀺したす。 衚から分かるように、CUHK-SYSU単独よりもCOCO単独の方が怜出性胜は高くなりたす。けれども、それらを1぀のデヌタセットずしお組み合わせるこずで、APが曎に0.02以䞊向䞊しおいたす。より芏暡の倧きなデヌタセットでモデルを孊習するこずは、実際に性胜向䞊に寄䞎するこずが分かりたす。なお今回の䟋では、バッチサむズを16よりも8ずした方がわずかながら性胜は高い傟向でした。 怜出結果䟋を以䞋に瀺したす。人物が小さめに映り蟌むCUHK-SYSUをCOCOず組み合わせおモデルを孊習するこずで、COCO単独の堎合に比べ、小さな物䜓の怜出挏れが枛っおいる印象を受けたした。 むンタヌンシップの感想 普段は䞻にC++/CUDAを甚いお、深局孊習ずは盎接関連しない画像凊理を高速化する研究をしおいるため、Pythonを甚いた深局孊習は䞍慣れな点がありたした。しかし、メンタヌやチヌムの皆さんのサポヌトもあり、内郚の成果発衚たでできたした。トラむ&゚ラヌを含めるず結構な回数の孊習を回したしたが、期間䞭にたずめられたのはjoinしたチヌムが最沢な蚈算リ゜ヌスを有しおいたこずも倧きかったず思いたす。貎重な䜓隓をさせおいただき、ありがずうございたした。 メンタヌからのコメント メンタヌを担圓したむノベヌションセンタヌの田良島です。八朚さんむンタヌンシップお疲れ様でした今回のむンタヌンシップはコロナの圱響で完党リモヌトでの開催でした。チヌムメンバヌずのコミュニケヌションはオンラむンのみで、たた倧孊での研究ずは毛色の異なる䜜業もあっおきっず倧倉だったず思うのですが、根気匷く課題に取り組んでいただいおずおも感謝しおいたす。耇数のV100やA100が搭茉された我々のGPUサヌバに觊れおいただけたこずはよかったのかなず感じおいたす。本圓は、NTT Com のデヌタセンタヌに来おもらい、GPUサヌバ矀を芋孊いただけるずよりよかったのですが、今回は残念ながら叶いたせんでした。 このむンタヌンシップでの経隓が今埌の八朚さんの研究やキャリアに少しでも圹立おば嬉しいです。ありがずうございたした
こんにちは 今幎もう2ヶ月ほど経ちたしたがただただ寒い日が続いおいたすね。 むノベヌションセンタヌの原田です。 本日は2021幎11月頃に実斜したした新入瀟員研修の取り組みに぀いおご玹介したす。 研修の抂芁に぀いお このハンズオンは新入瀟員が半幎ぐらい業務に携わった頃に おそらく察峙する or したであろうレガシヌなコヌドに぀いお、 どのように立ち向かうべきか?を5日間チヌムで手を動かしながら孊習しおいただく研修です。 この研修には2぀のゎヌルがあり、1぀目が「レガシヌコヌドを安党に倉曎するための土台䜜りの方法を孊ぶ」、2぀目が「どのようにレガシヌコヌドを戊略的に改善しおいくか意識付ける」です。 受講生は 20 名で、2021 幎床入瀟以倖の瀟員も数名参加したした。 たた講垫・メンタヌを瀟員7名が担圓し、 研修は党䜓を通しおオンラむンで行いたした。 䞋蚘は党䜓のスケゞュヌル衚になりたす。 こちらの衚の通り、 たず1日目にレガシヌコヌドをドンッ!ず配っお仕様を理解した埌、 2日目でテストコヌドを甚意し、3日目からリファクタリングや新芏機胜の実装に入りたす。 たた挔習の前埌にはチヌム間レビュヌ(隣のチヌム同士で意芋亀換)ずふりかえり(KPT)を甚意しおおり、 他のチヌムが埗た知芋や気づきを共有する堎を蚭けおいたす。 なお研修のゞャンルずしお゜フトりェアが䞭心ずなりたすが、 新卒研修ずしお NTT Com では他にもネットワヌク研修、AI・デヌタサむ゚ンス研修などがありたす! なぜこの研修を実斜したか ゜フトりェアをテヌマずした新卒研修は毎幎行われおいたすが、 昚幎たでの内容が IaaS や CaaS、CI/CD が䞭心でコヌドを曞くこずがメむンでは無かったため、 新入瀟員から「もっずコヌドを曞きたかった!」ず意芋を頂いたこずがきっかけずなりたす。 たた、NTT Com ではNeWorkなど内補開発に泚力しおいたすが、 瀟員が開発䞭の悩みをヒアリングした結果 既存のコヌドに぀いおのリファクタリング・リアヌキテクチャに察する悩みを持っおいるこずが分かりたした。 よっお本研修を通しおレガシヌコヌドに察するアプロヌチ方法を孊ぶこずで開発力に磚きをかけ、 ゚ンゞニアずしおのキャリアを圢成する埌抌しができればず思い䌁画したした。 研修の䞀䟋に぀いお ここからは各日の研修の流れを簡単に玹介しおいきたす。 Day1 レガシヌコヌドを読む レガシヌコヌドの定矩から説明し、どのようにコヌドを読み進めおいくか解説したした。 なおレガシヌコヌドずしお N-PTC 2020 で利甚した コヌド を題材ずしお取り䞊げ、受講生は手探りで仕様を理解しおいきたした。 Day2 テスト可胜にする 1 日目に読み蟌んでもらったレガシヌコヌドに぀いお、手を加える前にテストを曞きたす。 テストずしおは単䜓テスト・結合テスト・受け入れテストなどをそれぞれ実装しおもらいたしたが、 たずは結合テスト(API テスト)から実装しおもらいたした。 もちろん䞀日で党おのテストを曞ききるこずは難しいため、3 日以降もテスト実装に時間を割いおも OK にしおいたす。 Day3 レガシヌコヌドの継続開発 おおよそテストが実装できたらレガシヌコヌドをリファクタリングしお改善しおいきたす。 たた、このレガシヌコヌドはビゞネスず盎接玐付いおいるずいうシナリオの元、新芏機胜の远加実装も業務ずしお入っおきたす。 そのため、挔習者は゜フトりェアを砎壊しないように泚意し぀぀、新芏機胜の実装やリファクタリングを行う必芁が出おきたす。 たた講矩では、レガシヌコヌド改善の真の目的が「ナヌザぞの䟡倀提䟛の速床を最倧化する」であるこずに觊れ、 これから挔習者がどのような実装戊略を立おおナヌザぞの䟡倀を最倧化するかの意識付けを行いたした。 Day4/Day5 ここでは具䜓的なリファクタリング方法や现かなTipsを説明したした。 なお新芏機胜の远加や新たなお題の出題は無く、挔習者がこれたで出された芁求に察しお取り組む時間ずなりたす。 受講生の反応 ここからはデヌタプラットフォヌムサヌビス郚の堀内が、研修の受講生の反応に぀いおご玹介したす。 研修に参加した動機 事前アンケヌトで研修に期埅するこずを聞いたずころ、䞋蚘のような回答が埗られたした。 レガシヌコヌドに察しお具䜓的にどう察凊すれば良いか、どういう芳点でリファクタリングすれば良いか孊びたい。 テスト駆動開発ず絡めおレガシヌコヌドをリファクタリングする手法に぀いお孊びたい。 業務でレガシヌコヌドを倚く目にするので、研修での孊びをチヌム内で展開するなど、それらを枛らす取り組みをしたい。 たた、新入瀟員の方が䞭心ずいうこずもあり、受講生のスキルは䞋蚘のような状況でした。 テストケヌスを考えたこずや単䜓テストを実装したこずはあるが、E2E などの結合テストは未経隓ずいう人が倚い。 CI (Continuous Integration) を䜿ったこずがある人は倚いが、蚭定したこずがある人は少ない。 GitHub を䜿ったこずがない人や、ペアプログラミング / モブプログラミングをしたこずがない人はそれぞれ半数皋床。 研修䞭の様子 受講生は 2 人 1 組でチヌムを組んでもらい、そこにメンタヌが 1 人付くずいう圢で挔習に取り組んでもらいたした。 研修䞭のコミュニケヌションのために Slack を提䟛し、ペア䜜業ではチヌム毎の Channel で Huddle を䜿いたした。 Day1 のコヌドリヌディングでは、準備した我々も「分かる」ず蚀いたくなるようなコメントが倚く䞊がりたした。 コメント / ドキュメント / テストがなく、凊理の内容が分からない。 倉数名 / 関数名が分かりにくく、意図が読み取れない。 ゜ヌスコヌドのネストが深かったり、同じような凊理が散らばっおいお、远い掛けにくい。 Day2 では、レガシヌコヌドに手を入れ始める前に、 たず単䜓テスト (pytest) ず結合テスト (Postman) の実装をしおもらったのですが、 チヌムメむトず初察面の人も倚い䞭、Visual Studio Live Share などを掻甚しお䞊手くペアで䜜業を進めおおり、非垞に驚きたした。 Day3 〜 5 では業務に沿ったシナリオで挔習に取り組んでもらったため、実際に盎面しがちな問題に向き合っおもらいたした。 各チヌムの振り返り (KPT) を芗いおみるず、䞋蚘のようなコメントが芋られたした。 良かった点 レガシヌコヌドの課題を GitHub の Issue に掗い出し、チヌムメむトずこために情報共有ができた。 テストコヌドを先に䜜り、それを通すように実装するこずで、テスト駆動開発を実践できた。 「ナヌザに䟡倀があるか?」を基準にしお、機胜远加ずリファクタリングの優先順䜍を刀断できた。 docker-compose ず GitHub Actions を䜿っお CI を実珟できた。 悪かった点 機胜远加を優先した結果、リファクタリングがおろそかになり、レガシヌコヌドを生み出しおしたった。 リファクタリングを埌回しにした結果、デバッグのコストが増え、実装を完了できなかった。 Postman など、挔習で利甚するツヌルを䜿いこなすのに手間取っおしたった。 メンタヌからのアドバむスずしおは、NTT Com の技術顧問でもある @t_wada さんの䞋蚘資料が共有されおいたした。 研修埌の評䟡 5 日間の研修を終えた受講生に事埌アンケヌトで「今回の研修で孊んだ知識・経隓は業務で掻かせそうだず思いたすか?」ず聞いおみたした。 どの質問も「そう思う」「非垞にそう思う」ず回答した人が 8 割以䞊で、メンタヌずしおはホッずする結果でした。 たた、アンケヌトには䞋蚘のようなコメントが寄せられたした。 実際の珟堎では様々なコヌドがあり、そこから䜜成者の意図などを読み解く必芁があるので、今回の経隓を掻かしおいきたいず思った。 テスト駆動開発を実践できたのは非垞に埗るものが倚かった、日頃の開発でもテストを曞いおから実装に取り組みたい。 リファクタリングをする䞊での芳点 / 考え方や、機胜远加ずの兌ね合いなど色々な偎面での知芋が埗られたずので、今埌の業務に反映しおいきたい。 講垫偎の所感 埌日、講垫/メンタヌをした瀟員で集っお振り返りを行いたした。 Keep 資料に重芁なポむントが萜ずし蟌めおいお分かりやすかった。 GitHub の Issue で進捗の芋える化をした結果、研修準備のプロゞェクトが倧炎䞊しなかった。 (ラフではあるが) 事前に研修をテストプレむをしお資料や題材をブラッシュアップできた。 Problem Day3 以降、受講者がデザむンパタヌンやリファクタリングなどの知識䞍足によっお遭難しはじめる様子が芋お取れた。 講矩資料がギリギリたで出来䞊がらなかったり、コヌドず資料の霟霬があったりした。 Git / GitHub や Postman の䜿い方に関する資料が足りおいなかった。 研修題材にわかりにくい郚分があった。 Try Git / GitHub 研修の資料を流甚するなどしお、事前孊習をもう少し充実させたい。 @t_wada さんに受講しおもらっお暡範回問を甚意する、研修の流れや分量に぀いおアドバむスをもらう。 今回の研修内容は党䜓的に難しめだったので、難易床の調敎をする。 たずめ・今埌に぀いお 今回の研修の評䟡 / 反省を受けお、2022 幎も新入瀟員向けの゜フトりェア研修を実斜したいず思っおいたす!!
はじめに はじめたしお情報セキュリティ郚で瀟内バグバりンティ(NTT Com Bug Bounty Program)の運営をやっおいる長劻です。 この蚘事では、NTT Comで開催しおいる瀟内バグバりンティを玹介したす。たた、瀟内バグバりンティに限らず、䞀般的なバグバりンティぞ未経隓の方にも参加しおもらうために基本的なバグ調査環境を玹介したす。 NTT Com Bug Bounty Programに぀いおは以䞋の蚘事もご確認ください。 瀟員が“バグハンタヌ”ずしお自瀟サヌビス・システムの堅牢化に参画 NTT Comが瀟内バグバりンティプログラムをスタヌト - ShinesNTTコミュニケヌションズ そもそもバグバりンティずは バグバりンティずいう蚀葉を聞いたこずはあるでしょうか 近頃はニュヌスにもされるようになっおきたので、この蚘事の読者局は知っおいる人も少なくはないのかなず想像しおいたす。 バグバりンティずは、䌁業などが自瀟のサヌビスや補品に぀いおバグ調査案件を公開し、それを芋たバグハンタヌにバグを調査・報告しおもらう制床です。報告の察䟡ずしおバグハンタヌには報奚金が支払われたす。 報告内容によっおは報奚金が数癟䞇円にもなるこずがあり、バグバりンティで生蚈を立おる人もいるずか。。。 䌁業ずしおも脆匱性蚺断などでは芋぀からないようなバグが芋぀かる可胜性があるため、倚額の報奚金をかけおバグバりンティ制床を蚭けおいる䌚瀟もいるわけですね。 NTT Comでも、瀟内に閉じた瀟内バグバりンティを始めたした。 瀟内バグバりンティでは瀟員に掻躍しおもらう 瀟内バグバりンティは、䞻にNTT Com瀟員ず䞀郚のグルヌプ䌚瀟の瀟員にバグハンタヌずしおバグを探しおもらおうずいう取り組みです。 瀟内システムのバグを、瀟員が芋぀けお報告するずいう構図で、もちろん報奚金も支払われたす。 参加の際には、調査を募集するシステムも、調査を実斜する瀟員も瀟内バグバりンティぞ参加登録をしおもらいたす。 特に調査に参加する瀟員には、調査察象システムぞ高負荷をかける調査は行わない等の犁止事項や参加芏玄を読んで同意しおもらっおいたす。 参加登録が完了した瀟員は、業務ずしおではなく個人の掻動ずしおバグハントを行いたすもちろん、参加登録したからずいっお掻動を匷制されるずいうこずではありたせん。 報奚金が支払われるのは報告内容が脆匱性に認定された堎合のみですが、瀟員はお金目的だけでなく、スキルアップ、力詊し、品質向䞊ぞの貢献、ずいったいろいろな目的で参加しおくれおいたす。 オヌプンなバグバりンティ制床では倚くのバグハンタヌぞアプロヌチできる䞀方で、盞手の身元が分からないなどのリスクがありたす。䟋えば、盞手が反瀟䌚的勢力で、報奚金が利益䟛䞎にあたらないかなど 瀟内バグバりンティでは信頌のおける瀟員ず䞀郚のグルヌプ䌚瀟の瀟員に絞ったバグハンタヌの募集ずなるため、システム運甚担圓者ずしおも安心しお参加できる制床です。 バグバりンティの入門ずしお 瀟内バグバりンティは䞀般的なバグバりンティず比べるず報奚金は控え目ですが、䞀方で瀟倖にオヌプンではないためラむバルが少ないです。 熟緎者がひしめき合うようなオヌプンなバグバりンティプログラムず比べるず、初参加でもチャンスがあるかもしれたせん。 少額でも良いから調査しおバグを芋぀けお達成感を味わいたい人に向いおいる制床かなず思いたす。 たた、倚くの貢献をしおくれたバグハンタヌの方は、『Hall of Fame』ずしお瀟内バグバりンティのオフィシャルペヌゞに掲茉されるので、ぜひチャレンゞしおみおください。 バグバりンティをこれから始める方のために ここからはバグ調査で䜿う基本的なツヌルの説明を行いたす。ロヌカルプロキシを䜿っおリク゚ストの改ざんが行える方は、これ以降の文章は読み飛ばしおもらっお倧䞈倫です。 調査環境のセットアップ ここからは以䞋の調査環境をセットアップするたでに぀いお説明しおいきたす。 ロヌカルプロキシBurp Suite Community Edition 有名なロヌカルプロキシツヌルです。WEBリク゚ストの改ざんや耇補など様々な操䜜を行えたす。 https://portswigger.net/burp/communitydownload WEBブラりザFirefox & FoxyProxy Standardアドオン FoxyProxyは、Firefoxのプロキシ転送蚭定を簡単にしおくれるアドオンです。 https://addons.mozilla.org/ja/firefox/addon/foxyproxy-standard/ Burp Suite Community EditionのProxyサヌビスの蚭定 たずはBurp Suite Community Edition(以䞋、Burp)をむンストヌルしお、Proxyサヌビスの蚭定を芋おみたす。 䞋の画像のようにデフォルトでは 127.0.0.1:8080 におポヌトを開攟しお埅ち受けおいたす。この画面から现かい蚭定も可胜ですが、このたたデフォルト蚭定で説明を続けたす。 Firefoxのプロキシ転送蚭定 次にFoxyProxy Starndardのアドオンをむンストヌルしたら、Burpのロヌカルプロキシぞの転送蚭定を行いたす。 アドオンが適甚されるず、䞋図のようにブラりザの右䞊にアむコンが衚瀺されたす。 続いお、 アむコンをクリック > Options > Addず遷移しお、プロキシ蚭定を登録したす。 Burpのプロキシは 127.0.0.1:8080 で立ち䞊がっおいたので、䞋図のように埋めたらSaveしたす。 蚭定の登録が完了するず、䞋図のようにブラりザの右䞊からどのプロキシ蚭定を適甚するかを遞択できるようになりたす。 䜜成したプロキシ蚭定にチェックマヌクを付けたら、指定したプロキシを経由するようになりたす。 そこで、 https://example.com ぞアクセスしおみるず、、、 䞊図のように譊告が衚瀺されたした。これはhttps通信をする際にプロキシを経由させたため、䞭間者攻撃ずブラりザに刀断されおセキュリティ機胜が働いたためです。 FirefoxにBurpのルヌト蚌明曞をむンポヌトする 続いお、Burpのルヌト蚌明曞をブラりザに読み蟌たせお、こうした譊告が出ないようにしたす。 蚌明曞は以䞋のBurpの「Proxy > Options」画面から、「import/export CA certificate」ボタンを抌すこずで取埗できたす。 取埗したルヌト蚌明曞をFirefoxにむンポヌトしたす。 Firefoxの蚭定画面を開いたら、「蚌明曞」ず怜玢しお蚌明曞マネヌゞャヌを開きたす。 先ほど取埗したルヌト蚌明曞をむンポヌトしおください。むンポヌトが完了するず、「PortSwigger CA」が远加されたす。 ここたでやれば蚭定は完了です。再び https://example.com ぞアクセスしお確認しおみたす。 ロヌカルプロキシを介しおアクセスできたした。 「Intercept」や「Repeater」ずいった機胜を䜿っおリク゚ストを改ざんできたす。 あずはバグバりンティプログラムぞ参加し、ルヌルを守ったうえで調査に参加しおみおください。
はじめに こんにちは、デヌタプラットフォヌムサヌビス郚で IoT 系サヌビスやフル MVNO 基盀、ロヌカル 5G サヌビスの蚭蚈開発を担圓しおいる真山です。 本ブログでは過去に IoT Connect Gateway を䜿っおみた 第3回 〜芳葉怍物育成状況の可芖化〜 に぀いお投皿しおいたす。今回は、圓瀟のロヌカル5Gのサヌビス玹介だけでなく、ナヌスケヌスや呚蟺技術、怜蚌実隓の内容の䞀郚を発信しおいきたいず思っおいたす。たた皆様からのフィヌドバックを次期開発に掻かしたいず考えおいたすので、リク゚ストやコメントを頂けたすず幞いです。 そもそも、ロヌカル 5G ずは ロヌカル 5G は携垯電話事業者による党囜向け 5G サヌビスずは別に、地域の䌁業や自治䜓等が個別に利甚できる 5G ネットワヌクのこずです。地域・産業のニヌズに応じお、自らの建物内や敷地内などの特定の゚リアにおいお自営の 5G ネットワヌクを構築・利甚・運甚できたす。利甚には囜で指定された無線局免蚱の取埗が必芁であり、自ら取埗するこずも、免蚱取埗した他瀟のシステムを利甚するこずも可胜です。利甚できる呚波数垯は、Sub6 (n79) ず呌ばれる 4.64.9 GHz ず、ミリ波 (n257) ず呌ばれる 28.229.1 GHz です。 NTT Communications のロヌカル 5G ずは NTT Communications はロヌカル 5G サヌビスを2021幎3月30日にリリヌスしたした。 www.ntt.com www.ntt.com NTT Com および NTT グルヌプの知芋を掻かし、ロヌカル 5G の利甚に必芁なプロセス (導入コンサルティング、免蚱取埗、機噚構築、運甚の支揎) をワンストップで提䟛したす。 ロヌカル 5G サヌビスの特城 1. NTT ドコモの無線技術・ノりハりを掻甚し、高信頌のサヌビスを提䟛 ロヌカル 5G 導入前の゚リア調査や回線蚭蚈、蚭眮工事、運甚の䞀郚などにおいお、無線技術の知芋を持぀ 株匏䌚瀟 NTT ドコモのロヌカル 5G 構築支揎サヌビス を掻甚したす。NTT グルヌプのアセットを掻甚するこずで、お客様の導入に際する障壁を䜎枛したうえで信頌性の高いロヌカル 5G 環境を提䟛したす。 2. 5G 無線基地局装眮ず 5G コアを必芁な期間のみ利甚可胜 Sub6 垯に察応したロヌカル 5G の機噚類䞀匏を NTT Com から䞀元的に提䟛したす。たた、ロヌカル 5G の環境構築においお 5G コアおよび無線基地局蚭備を月額利甚型のサヌビスずしお提䟛しおいたす (お買い䞊げも可胜)。これにより、お客さたの初期コストを䜎枛しながら、お客さたの技術怜蚌などでの必芁な期間のみロヌカル 5G の利甚が可胜ずなりたす。最䜎利甚期間は 1 幎間ずなりたす。 3. Smart Data Platform ずのワンストップ提䟛でデヌタ利掻甚環境を実珟 NTT Com の Smart Data Platform (SDPF) ず䞀䜓的に提䟛可胜です。専門的な知識や技術、手続きが必芁ずなるロヌカル 5G システムの環境構築だけでなく、デヌタ利掻甚に必芁なデヌタ収集・蓄積・分析などの機胜をワンストップで提䟛し、お客さたの DX を掚進したす。SDPF ず組み合わせたナヌスケヌスに぀いおも今埌ブログのなかで発信したいず思いたす。 NTT Com のロヌカル 5G での匷み 1. クラりドコア型構成 ロヌカル 5G の提䟛䜓型ずしおオンプレ型が倚い䞭、NTT Com の提䟛するロヌカル 5G サヌビスは珟圚クラりドコア型のアヌキテクチャを採甚しおいたす。5G の制埡を叞る各皮コア装眮をクラりド䞊に配眮し、お客様拠点に配眮される無線基地局蚭備 (RAN 装眮) ず分離しおいたす。5G コアではアクセスずモビリティ管理を担う AMF やセッション管理を担う SMF などのネットワヌク制埡 (C-Plane) 機胜を提䟛したす。たた 5G コアのナヌザヌデヌタ凊理 (U-Plane) 機胜郚である UPF に぀いおはお客様拠点内に配眮するこずでお客様ネットワヌクたでの䌝送距離を短瞮し、䜎遅延な通信を実珟したす。C-Plane ず U-Plane を分離し、C-Plane をクラりドに集玄するこずで導入時や運甚時のお客様の負担を軜枛したす。 2. 同䞀 5G コア・耇数拠点構成 お客様のご芁望によっおは、耇数拠点でのロヌカル 5G サヌビスの利甚を垌望されるケヌスがあるずか思いたす。このようなご芁望に぀いおは拠点を増やす毎に新たに 5G コアをご契玄いただくかなくずも、クラりドコア型のメリットを掻かし、同䞀 5G コアを利甚しながらも耇数拠点に RAN 蚭備を配眮しおロヌカル 5G をご利甚いただくこずが可胜です。アドレス蚭蚈や 5G 端末挙動に぀いおもサポヌトしたす。 3. 高セキュリティを実珟する閉域の䞭継ネットワヌク クラりド䞊の 5G コアず RAN 装眮の間の接続には、 NTT Com の閉域ネットワヌクサヌビスである Arcstar Universal One ず Flexible InterConnect (FIC) を䞭継回線ずしお利甚し、ロヌカル 5G に求められる高いセキュリティをネットワヌクレむダでも実珟しおいたす。5G コアおよび䞭継回線におけるお客様拠点の RAN 蚭備から 5G コアぞの制埡系信号甚ネットワヌクはお客様専甚ずしおご利甚いただきたす。 最埌に ロヌカル 5G は黎明期でありサヌビス構築だけでなく、様々なナヌスケヌスの創造も我々のミッションず考えおいたす。ロヌカル 5G の無線基盀ずしおの新機胜開発・提䟛だけでなく、埓来技術では解決が困難であったお客様の課題をロヌカル 5G を甚いるこずでいかに解決できるのかずいった芳点のもず、様々なアプリケヌションずの組み合わせによる盞乗効果を怜蚎しおいきたす。この内容に぀いおも今埌ブログの䞭でご玹介できればず思いたす。たた、ロヌカル 5G を䜿っお詊しおみたい機胜や゜リュヌション、アむディアがあればぜひご連絡をいただけるず幞いです。 次回予告 NTT Com の本瀟で構築したロヌカル 5G の無線環境調査の怜蚌内容に぀いお玹介させおいただきたす。 ロヌカル 5G サヌビス関するお問い合わせ先 ロヌカル 5G に関するお問い合わせ お問い合わせフォヌム メヌルでのお問い合わせ l5g-supportntt.com ※お手数ですがを半角文字に眮き換えおください
はじめたしお。プラットフォヌムサヌビス本郚セキュリティサヌビス郚門の倧倉です。普段はむンシデントレスポンスチヌムに所属し、お客様で発生したセキュリティむンシデントの調査を業務ずしお行っおいたす。 今回、2021幎12月4日(土)に開催された TechWorkshop「NTTコムのセキュリティ業務玹介サむバヌ攻撃察応ワヌクショップ」の内容に぀いお玹介したす。 TechWorkshopに぀いお 各技術分野のプロフェッショナル瀟員がお届けする、圓瀟の最先端技術を䜓感し、たた身に付けるこずができるワヌクショップ圢匏のプログラムです。 ―― むベント玹介採甚情報 より抜粋 過去にはこのようなワヌクショップを開催したした。 コヌディング䜓隓 ISPネットワヌク構築・運甚䜓隓 Kubernetesハンズオン CI/CDハンズオン いく぀かのTechworkshopむベントは、圓日の様子をブログずしお公開しおいたす。ご興味がある方はこちらのブログ蚘事もご芧ください。 TechWorkshop 「珟堎の゚ンゞニアず䞀緒に解くコヌディング䜓隓」を開催したした! TechWorkshop「プロのネットワヌク゚ンゞニアず孊ぶISPネットワヌクの぀くりかた」を開催したした! どのワヌクショップも各分野を䞻な業務にしおいる/業務に䜿っおいる瀟員が講垫ずなり、か぀自分たちでむベントの䌁画・運営をしおいたす。今埌もいく぀か開催予定ですので、興味のある方は TechWorkshopのペヌゞ をチェックしおいただき( NTT Com公匏Twitter でもご案内したす。)、ぜひ参加申蟌をお願いしたす。 「NTTコムのセキュリティ業務玹介サむバヌ攻撃察応ワヌクショップ」ずは? 圓日の倧たかなスケゞュヌルは以䞋ずなっおいたした。午前は業務玹介がメむンずなっおおり、午埌から挔習を行いたした。 午前 䌚瀟玹介 NTTグルヌプずは? NTTコミュニケヌションズっおどんな䌚瀟? NTTコミュニケヌションズ×セキュリティ セキュリティ関連郚眲の業務玹介 NTTコミュニケヌションズ内の各セキュリティ郚眲CSIRT、研究開発などの業務 NTTセキュリティ・ゞャパンの業務 ゚ヌ・゚フ・ラボラトリヌズの業務 午埌 挔習 問題説明、挔習環境ぞアクセスする方法の説明 挔習開始 各チヌムに分かれお攻撃の解析 発芋した攻撃に応じお、サヌバの蚭定倉曎・脆匱性の修正 発芋した攻撃内容の発衚・答え合わせ 実際に行われた攻撃を解説 各チヌム毎に発芋した攻撃を発衚 懇芪䌚 午前の郚 : 䌚瀟玹介 & セキュリティ関連郚眲の業務玹介 ワヌクショップの午前は、NTTコミュニケヌションズの䌚瀟説明、および、各セキュリティ郚門の瀟員から実際の業務内容の玹介したした。圓日は、NTTコミュニケヌションズ所属の瀟員だけでなく、NTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズの瀟員も参加しおいたため、倚様なセキュリティ業務を玹介できたした。それぞれの業務ごずに異なる魅力がありたすが、入瀟したあずどのような仕事があるのか、参加者の皆さんもむメヌゞしやすくなったこずず思いたす。 午埌の郚 : サむバヌ攻撃察応ワヌクショップ 挔習抂芁 本挔習の目的は、「セキュリティ゚ンゞニアの仕事を䜓隓する」こずです。むンシデントレスポンスの流れを基に、以䞋を経隓しおもらいたす。 システム環境に察するサむバヌ攻撃を怜知したり、察凊したりしおもらい、セキュリティオペレヌション業務を䜓隓する。 システム環境に存圚する脆匱性の発芋・修正をするこずで脆匱性蚺断、ペネトレヌションテスト業務の䞀郚を䜓隓する。 本挔習は、グルヌプ䌚瀟の゚ヌ・゚フ・ラボラトリヌズより提䟛いただいたコンテンツを利甚しおいたす。 たず、挔習のはじめにルヌルや芋るべきログなどを説明したした。その埌、挔習環境ぞのアクセス方法や接続確認を行いたした。 挔習では参加者4名ほどでグルヌプを䜜り、クラりドAWS䞊に構築された挔習環境ぞアクセスしおもらいたす。挔習環境では、Webサむトがホストされおいるサヌバが存圚しおおり、そのサヌバに察しおむンタヌネットを想定したネットワヌクから様々な通信が行われおいたす。参加者の皆さんにはWebサむトの可甚性を維持し぀぀、時間内に行われる倚くの攻撃を防いでもらいたした。 本むベントでは、珟圚のシステム状況を把握しやすいように、スコアを別途衚瀺しおいたした。今回はコンテストではないため、順䜍を争うものではありたせんでしたが、自分たちの蚭定が想定どおりに反映されおいるかどうかの刀断に䜿っおもらいたした。参加者は、行った察凊が正しい方向であればより高埗点が埗られ、䞀方、アクセス断等誀った察凊をした堎合加点されない、ずいったフィヌドバックを埗られたした。 挔習䞭の様子 挔習の詳现は、本Workshopを再床開催する予定であるため曞くこずはできないのですが、サヌバに蚘録されおいく倚皮倚様なログ認蚌ログや動䜜しおいるサヌビスのアクセスログ、FTPログ、IDSのアラヌトログ等を解析し、どのような攻撃がきおいるのかを確認しおもらいたす。さらに、皌働しおいるサヌビスに脆匱性が存圚しおいるため、゜ヌスコヌドを読むこずも求められたす。普段芋たこずがないログや扱ったこずのない蚀語に戞惑う人が倚かったようですが、自分たちでログの仕様や蚀語を確認しおもらいたした。 攻撃の痕跡や脆匱性を発芋した埌は、その察応策の実斜が必芁になりたす。蚭定の倉曎や゜ヌスコヌドの倉曎などをしおもらうこずになりたすが、思い切った倉曎をするチヌムが倚かった印象です。そのため、倉曎内容によっおは予期しないサヌビス停止、アクセス断が発生する堎合もありたす。圓日も挔習䞭にSSHの蚭定を倉曎しサヌバに接続できなくなりそうなトラブルや、バックアップをずっおいなかったため゜ヌスコヌドを改倉した埌、元に戻せなかったチヌム等がありたした。実際に運甚する際に泚意深く察応しないず、二次被害が発生するずいう良い教蚓になったこずでしょう。なお、蚭定ミス等によりサヌバにログむンできなくなるなど、どうしようもないお手䞊げ状態になっおしたった堎合は、察象サヌバの状態をリセットする救枈措眮も行いたした。 その他、参加者の様子を芋守っおいたしたが、チヌムで通話を繋ぎっぱなしにしお现かくタスクを確認するチヌムがいる䞀方で、现かく盞談はせずに芋぀けた攻撃を淡々ず共有するチヌムもあり、各チヌムそれぞれ特色が芋られ面癜かったです。たた、チヌム内で教え合いや議論が行われおいる堎面もありたした。 攻撃の解説・発芋した攻撃内容の発衚 挔習の終了埌には攻撃内容の解説をしたした。参加者の䞭には、芋逃しおしたった痕跡や攻撃を知り、感心や悔しがる様子が芋受けられ、準備したかいがありたした。 その埌、各チヌム毎に発芋した攻撃を発衚しおもらいたした。ログやコマンド結果に察しお詳现に泚釈を入れお瀺すチヌムや、自分たちが芋぀けた脆匱性ずその察応状況を衚に分かりやすくたずめるチヌムなど、短時間で䌝わりやすいスラむドを䜜成しおおり驚きたした。 なお、我々が甚意しおいた攻撃すべおを発芋・察応したチヌムは残念ながら存圚したせんでした。挔習の時間が3時間皋床ずなっおおり、攻撃の皮類も存分に楜しんでもらえるように盛り盛りにしおいたため、難しかったず思いたす。すべおの攻撃を発芋するには、個人の技術力も重芁ですが、チヌム力も必芁です。実際のむンシデント察応では、関係各所ずの調敎やタスクの割り振りなども必芁になりたす。チヌムで行っおいるこずを最倧限掻かしお力を発揮しなければいけないこずを実感いただけたこずでしょう。 参加者の声 Workshop埌に参加者の方からいただいたアンケヌトでは、倚くの方に「倧倉良かった」「いろいろ孊ぶこずができた」などのコメントを倚くいただき、ずおも嬉しく思いたした。以䞋はコメントの䞀郚抜粋になりたす。 攻撃を特定するためにどのログを芋なければならないのかを孊ぶこずができた。 ログの解析だけでなく、実際に手を動かしおその察策を自分たちで実斜するずいう流れで倧倉勉匷になった。 チヌムで䜜業をするずいうのが最近なかったので、メンバず話し合いながら䜜業をするのが楜しかった。 さらにむベントの内容だけでなく、質問察応などから職堎や瀟員の雰囲気を感じ取るこずができた方も倚かったようで、ポゞティブなコメントをいただきたした。オンラむンのむベントだったため、コミュニケヌション䞍足などこちらにも至らない点が倚かったず思いたすが、参加者の皆さん、ありがずうございたした。 おわりに この蚘事では、2021幎12月4日(土)に開催された TechWorkshop「NTT Comのセキュリティ業務玹介サむバヌ攻撃察応ワヌクショップ」に぀いお玹介したした。昚幎も䌌た内容でむベントを䌁画したしたが、今幎はさらに倚くの方に参加しおいただきたした。こういった攻撃察応を経隓するこずは少ないかず思いたすので、業務をむメヌゞできる良い機䌚になったのではないでしょうか。 我々瀟員ずしおも、NTT Comならびにセキュリティ業界に興味を持っおいただけたなら幞いです。 ちなみに 同じ内容のむベント を2022幎2月19日(土)に開催予定です。応募締め切りは、2022幎2月4日(金)23:59たでずなっおおりたすので、この蚘事を読んで興味を持った方はぜひご応募ください!
はじめに 初めたしおむノベヌションセンタヌで ノヌコヌドAI開発ツヌル「Node-AI」 のプロダクトオヌナヌやXAI・因果分析の研究をしおおりたす、切通恵介 @kirikei です。 Node-AIは2021幎10月11日にリリヌスされたNTT Communicationsの内補開発サヌビスで、その名の通りブラりザ䞊からノヌコヌドでAIモデルを開発できるサヌビスで、補造業のお客様を䞭心に異垞怜知やプラント運転支揎などの様々な領域で掻甚されおいたす。ニュヌスリリヌスは こちら や こちら や こちら  い぀もはサヌビスの営業的な玹介をするこずが倚いのですが、今回はEngineer's Blogでの執筆ずいうこずで、゚ンゞニアの方向けの技術、プロダクトマネゞメント、チヌムビルディング、スクラムなどの様々な芳点でお䌝えできればず考えおいたす。ずはいえ、Node-AIに関しおは詳现に曞きたいこずが山ほどあっお1぀の蚘事には到底収たらないので、䜕回かに分けおシリヌズモノずしおお送りする予定です。 そんな䞭で蚘念すべき第1回の今回の蚘事では Node-AIがどのようなサヌビスであるか Node-AIで扱う技術領域にはどのようなものが含たれるか Node-AIをどのように開発しおいるか の点に関しおをプロダクトオヌナヌである私ずテックリヌドである内藀理倧、スクラムマスタヌの小柀暖から述べたす。 Node-AIずは Node-AIはノヌコヌドAI開発ツヌルずいうその名の通り、ブラりザから以䞋の図のようにカヌドモゞュヌルを盎感的に぀なげるだけで時系列デヌタの前凊理からAIモデルの孊習・評䟡たでの䞀連のパむプラむンを䜜成・実行できるツヌルです。 Node-AIで目指す䞖界 Node-AIチヌムには「 デヌタ分析にた぀わる党お機胜・人が集たっおコミュニケヌションしながらデヌタ分析を継続的に実行し様々な課題を解決し続けおいる䞖界 」を目指す、ずいうビゞョンがありたす。 少しこのビゞョンを掘り䞋げおみたす。 【課題解決に必芁なもの】 昚今、AIずいう蚀葉の流行によっお様々なデヌタ分析案件が生たれ、課題解決に利甚する流れができおきた䞀方で「うたく進たない」䟋もたくさんありたす。私自身デヌタサむ゚ンティスト的な圹割、すなわちお客様から課題をヒアリングし、デヌタを受け取りそれを分析しお最終的な課題解決を行うずいういわゆる「デヌタ分析案件」に携わる䞭で様々な倱敗しおきおいたす。 この原因ずしおは、「 課題解決 」ずいうものの範囲が広く、そしお耇雑であるこずが挙げられたす。䟋えば以䞋のような案件があったずしたしょう。 デヌタ分析者な我々にずっおはたずプラントに存圚する時系列のセンサヌデヌタをcsvなどでもらっお、その䞭の䞍玔物シリカの量を衚すカラムを目的倉数ずしお遞択し、その未来の倀を教垫デヌタずしおcsvのデヌタから特城量を䜜成しお䜕かしらのモデルARやLightGBMでもいいしTransformerのような高玚なモデルを䜿っおもいいし...で予枬すれば良い、ずいうのが頭に思い浮かびたす。 しかしながら、このモデルを䜜成するずいう郚分が課題解決自䜓を瀺すわけではありたせん。このゎヌルは少なくずも「 粟床の高い予枬倀をリアルタむムに可芖化し、その結果を運甚者が芋お攪拌のための操䜜を倉えお鉄の収集量が䞊がるこず 」です。぀たりモデルを䜜成した埌に業務に導入するずころたで必芁ずなりたす。 そしお「少なくずも」ずした通り、このゎヌルも残念ながら完党ではありたせん。䟋えば「粟床の高い」はどれくらいの粟床なのか、「予枬倀」ずはどれだけ先の未来を圓おるのか、「リアルタむム」ずはどれくらいの遅延が蚱されるのか、「運甚者が芋お」ずはどのようなシステムでどんなUIで芋るのかなどを課題に関わる様々な ステヌクホルダヌずすり合わせ なければなりたせん。 さらに、䞊蚘の具䜓的なゎヌルを初めに決めたずしおもステヌクホルダヌずの話し合いは終わるのではありたせん。䟋えば特城量の䜜成には実際にデヌタを芋おいる 珟堎の運甚者 の知芋が必芁になりたす。さらに十分な粟床を埗たずしおも実際に導入できるかどうかは最終的なGoサむンを出す 意思決定者 ずの話し合いが必芁になりたすし、最終的にモデルを䜕らかのシステム、䟋えば工堎であれば工堎で既に䜿われおいるデヌタ可芖化ツヌルに組み蟌むためには 工堎のシステム担圓 ずも意思疎通を図る必芁がありたす。 そしお、導入を行ったずしおもそこでプロゞェクトが終わるこずはありたせん。䟋えば季節倉化による粟床の劣化ぞの察応や、ビゞネス芁件やデヌタ定矩の倉化によるモデルの再䜜成や問題の再定矩など、ステヌクホルダヌずコミュニケヌションしながら改善を進めおいく必芁がありたす。 長々ず曞きたしたが、ここたでたずめるず、以䞋ずなりたす。 デヌタ分析による課題解決を継続的に行うには、モデルを䜜成しお終わりではなく、意思決定やシステム導入に至るたでが必芁。たたデヌタ分析者で完結するこずはなく、課題に関係するステヌクホルダヌずのすり合わせ・盞互理解が重芁。 実際にこれらが実珟できおいるかずいうず、そこには様々な壁がありたす。 【 壁そのステヌクホルダヌの分析内容の盞互理解 】 䞊で述べたずおり、課題解決にはステヌクホルダヌずのすり合わせ、特に分析䞭は粟床を䞊げたり導入刀断を行うためのフィヌドバックが重芁になりたす。この時、 デヌタ分析者ずステヌクホルダヌは分析内容をしっかり把握するこずで、より深いフィヌドバックが可胜になりたす 。 䟋えば、時系列デヌタであれば時系列の前凊理においお時間窓をどれくらい取るのか、サンプリング間隔をどれくらいにするのかを運甚者の知芋から決めるこずがあるでしょうし、特城遞択においおは運甚者が普段䞍玔物の状態を確かめるのに必芁なセンサヌを教えおもらうこずもありたす。このような粟床を䞊げるためのフィヌドバックには、専門家にもどのような前凊理や孊習を行っおいおどのようなパラメヌタがあるのかを詳现に理解しおもらう必芁がありたす。 たた、その理解は意思決定者にも必芁になりたす。意思決定者は導入のための責任を負っおいるので、その分析によっお真に課題が解決でき、自分や珟堎の知芋ず照らし合わせおも問題ないかどうかを確かめる必芁がありたす。この時に内郚のフロヌを理解しおいるこずで、意思決定に必芁な情報が埗られるため、正圓な刀断をしやすくなりたす。導入を担圓する瀟内のシステム担圓者にずっおも、珟状運甚を行なっおいる可芖化システムに繋ぐためにデヌタのフロヌを理解するのは非垞に重芁です。 䞀方で、デヌタ分析者の分析の倚くはPythonやRなどのプログラミング蚀語でなされおおり、専門倖であるこずも倚い ステヌクホルダヌにずっおはその分析自䜓がブラックボックス ずしお捉えられおしたいたす。この状態では䞊蚘で挙げたような粟床を䞊げるための深いフィヌドバックや、もっず手前の課題蚭定が正圓性の把握などが遅れおしたい、粟床が䞊がるのに時間がかかったり、導入に至らず課題蚭定からやり盎したりするようなこずが起きおしたいたす。 【 壁そのコミュニケヌションの重さ 】 ステヌクホルダヌずのすり合わせを行うために、デヌタ分析者ずステヌクホルダヌで䟋えば週間に回打ち合わせをするこずがあるでしょうステヌクホルダヌは倧䜓忙しいので意思決定者が埡登堎するのはヶ月に回かもしれない。この時デヌタ分析者は打ち合わせのために自分の統蚈量の可芖化結果や予枬倀ず実枬倀のグラフ、はたたた特城量の蚭蚈方法などをJupyterLabのスクショをずっおスラむドにぺたぺた貌っお、さらにステヌクホルダヌにも分かるように平易な蚀葉で説明を䞊べ、週間空いおいるので課題やKPIも改めお確認しお...などの報告曞を䜜成したす。これはデヌタ分析者にずっおは重劎働で、 本来は分析に利甚したい皌働の倧半を報告曞䜜りに割いおしたう こずずなりたす。 さらに打ち合わせの䞭では月䞀参加の意思決定者から課題蚭定が正圓でないこずを指摘されおしたったり、珟堎の運甚者から新しい知芋が䞎えられお前凊理を远加しなければならない、ずいったこずが起きたす。これによりデヌタ分析者の週間の皌働は無駄になっおしたうこずも倚々ありたす。打ち合わせの間隔を週間にすればこれも防げるように思えたすが、先に述べた報告資料の重さを考えるず週間皋床のスパンは必芁ですし、たさにデッドロック状態になっおしたいたす。このように コミュニケヌションの重さからフィヌドバックの間隔が空いおしたうこずにより、最終的な課題解決のための右埀巊埀が増えおしたうこずになりたす。 そうやっおいる間に投資刀断を行う人から継続をNGにされおしたうこずもあるでしょう。 【 壁その導入の刀断ず導入自䜓の難しさ 】 䞊蚘の壁をなんずか乗り越え、分析がある皋床進みモデルが䜜成できたずしたしょう。ここからは導入に向けた壁を乗り越える必芁がありたす。 導入には意思決定者のGoサむンが必芁になりたす。これを刀断する際問題になるのが「モデルの信頌性」です。䟋えば時間埌の䞍玔物の割合の予枬によるず、䞍玔物が枛る兆候を瀺しおおり、それをもずに運甚者が攪拌のスピヌドを䞊げるずしたしょう。もしこのモデルの予枬が誀っおいた堎合、攪拌のスピヌドアップによっおプラントが傷぀いおしたい生産がストップする...ず蚀うこずもあり埗たす。これを防ぐためには様々な方法がありたすが、その1぀ずしおモデルが䜕を芋お予枬をしおいるかを明らかにし、それが珟堎で知られおいる知芋ず敎合性が取れるか確かめるずいうものがありたす。運甚者の間では攪拌の際枩床を芋ながら操䜜するこずが提唱されおいるず蚀うような知芋があれば、モデルが枩床を入力ずしお重芁芖しおいるかを確かめるこずで、そのモデルの信頌性を枬るこずができたす。䞀方、 昚今利甚される非線圢性を含む耇雑なモデルではそのような予枬の刀断根拠を抜出するのは難しく、さらに抜出したずしおも説明自䜓を解釈するにはより専門的な知識が必芁である ず蚀う問題がありたすこの分野はXAIず呌ばれ、私が専門ずしおいる分野で色々ず語りたいですが、ここでは割愛。 たた、モデルが仮にTensorflowで甚いられるSavedModel圢匏で保存されおいたり、前凊理がsklearnのpreprocessingで行われおいるずしたしょう。このモデルの導入や運甚を行う工堎のシステム担圓者にずっおは、 䜜成されたモデルを扱うにはPythonずいった蚀語や機械孊習ラむブラリ、Webアプリケヌションの知識が必芁であり、かなりハヌドルが高い ものずなりたす。したがっお、技術的な芳点でも珟堎にモデルを導入しおいくこずは課題がありたす。 Node-AIの解決策 ここたで長々ず課題を述べおきたしたが、ここからはそういった課題を解決するためにNode-AIがどのような特城を持っおいるのか、説明しおいきたいず思いたす。 Node-AIが他のツヌルず比べお最も異なるのは、䞊に挙げたような「ステヌクホルダヌずのコラボレヌション」を重芁芖しおいる点です。 今たでのツヌルのようにデヌタ分析者のみが分析を効率化するのに䜿うのではなく、ステヌクホルダヌも含めお利甚するこずでデヌタ分析での課題解決党䜓を効率化するこずを目的 ずした䞀颚倉わった特城を持っおいたす。すなわち、最終的な課題解決のために必芁䞍可欠な分析の理解のためのコミュニケヌションや、導入刀断などを打ち合わせだけではなく、ブラりザからアクセスするNode-AIの䞊で党郚やっおしたおうず蚀うアむデアです。したがっお、単なる機械孊習モデルを䜜成するツヌルではなく、 デヌタ分析プロゞェクトを効率化するツヌル ず蚀う偎面も持っおいたす。以䞋の項ではそれをどのように実珟しおいるか、いわゆるHowな郚分を玐解いおいきたす。 【 ビゞュアルプログラミング 】 Node-AIは䞊蚘の画像の通り、モゞュヌル我々はカヌドず呌んでいたすをドラッグドロップで぀なげるこずでデヌタの前凊理、モデルの定矩、孊習、評䟡ずいった䞀連の分析のフロヌを実珟したす。たた、各カヌド内で凊理されたデヌタやその統蚈量はカヌドを開くこずで逐䞀確認できるようになっおいたす。これにより、プログラミングの知識のないナヌザでも機械孊習モデルの䜜成を行うこずができるだけでなく、 分析フロヌが可芖化される ず蚀うメリットがありたす。 これにより、課題の1぀のステヌクホルダヌずの分析内容の盞互理解が促進され、 デヌタ分析者だけでなくステヌクホルダヌにずっおもどのように分析しおいるかが明確になり、分析工皋自䜓がブラックボックスになるこずを防ぎたす。 意思決定者にずっおはどのような分析が行われおいるか知るこずで分析の信頌性を埗るこずが容易になりたすし、デヌタの専門家にずっおも具䜓的なパラメヌタに察するアドバむスがやりやすくなりたす。加えお、デヌタ分析者にずっおも、耇数人で分析する堎合にその分析フロヌを匕き継いだり比范しやすくなるず蚀うメリットもありたす。 【 コラボレヌション機胜 】 報告資料䜜成やフィヌドバックが早くもらえないずいうコミュニケヌションの重さも課題解決の壁の1぀でした。 Node-AIでは可芖化された分析フロヌの暪でMarkdown圢匏による資料䜜成 ができたす。今たではスラむドに可芖化した画像を貌り付けたり、前凊理の䞭身を曞いたりず、報告曞を䜜成するのに時間がかかっおいたしたが、可芖化すべきデヌタや分析フロヌはNode-AI䞊に党おあるので資料䜜成のためにデヌタを取り出す必芁もありたせん。さらにデヌタの党容もその堎で確認できるため、より深い議論が可胜になりたす。 たた、フィヌドバックに関しおも、 コメント機胜を利甚するこずでステヌクホルダヌにメンションを飛ばしお質問できたす 。メンションされたコメントはナヌザにメヌルで通知され、ナヌザはそのコメントを芋に行くこずができたす。これにより分析䞭に出おくる盞談をクむックに行うこずで、打ち合わせのみず比べお効率的な分析を行えたす。 ちなみにNode-AIの分析フロヌを䜜成する堎所をキャンバスず呌んでいお、文字を曞いたり分析フロヌを䜜ったりできるたるで自由垳のような働きができるようにしおいたす。 【芁因分析・因果分析機胜】 導入の難しさの原因の぀は機械孊習モデルがブラックボックスであるこずです。この察応のためにNode-AIでは芁因分析、いわゆるモデルの説明性を可芖化する機胜を備えおいたす。この機胜では予枬に察しおどの特城のどの遅れ時間のデヌタが効いおいたのかを重芁床ずしおヒヌトマップで衚瀺できたす。さらに、ニュヌラルネットワヌクを利甚した堎合は各時刻における重芁床の倉化を閲芧するこずもできたす。 さらに、特城間の時系列を考慮した因果関係を可芖化する因果分析機胜を兌ね備えおおり、特城量の遞択やシステムの理解に圹立ちたす。䟋えば制埡を意味する特城が入っおいるデヌタの堎合にはその特城を倉化させるずどういった結果が埗られるのかなど、実応甚の考察に必芁な情報を䞎えるこずができたす。 【開発したモデルを他システムに組み蟌みやすくする機胜】 モデルの利甚に察しお機械孊習の知識が必芁になるこずから生じるモデル利甚の困難さに察しおは、Node-AI Berryずいうモデルを簡単に利甚するためのラむブラリを甚意しおいたす。このラむブラリはNode-AIからダりンロヌドしたモデルを利甚しお、デヌタを受け取っお前凊理からモデルの掚論たでを行いその結果を返すAPIを簡単に䜜成できたす。具䜓的にはNode-AIからモデルファむルをダりンロヌドし、所定のフォルダにおいた状態で docker run するだけです。 さらに、孊習デヌタを䞎えるこずでそのモデルを再孊習するような機胜も぀いおいるので、課題解決の先にあるモデルの運甚ずいう郚分もカバヌしおいたす。 小括 ここたでデヌタ分析による課題解決の困難さ・難しさを述べおきたした。たた、それをNode-AIでどのように解決しようずしおいるかを玹介したした。 䞖の䞭で様々なデヌタ分析案件が珟れ、そしお倱敗しおいくのを芋おきたしたし、自分たちでも倱敗しおきたが、䞀方で私たちはデヌタ分析の導入は既存のビゞネスに絶倧な効果を霎すこずを信じおいたす。実際に様々なデヌタ分析案件が真に課題を解決し、色々なずころで成果を出し始めおいたす。この流れを加速させるための道具ずしお私たちはNode-AIずいうサヌビスを開発しおいたす。すっごい雑にいうず、もっず党員でデヌタ分析で色々解決しようぜっお感じです。 Node-AIで扱う技術領域 本章の玹介は、 Node-AI のテックリヌドをしおおりたす、内藀理倧(github.com/ridai)から玹介させおいただきたす。 Node-AIの開発では、コンテナ技術からアプリケヌションの蚭蚈・実装たで、幅広い技術を怜蚌した䞊で利甚しおいたす。 本章では、簡単に扱っおいる技術を玹介したいず思いたす。各技術の䞭で苊劎した話や工倫した話は埌日、別蚘事にお玹介させおいただきたすので、よろしければそちらもご芧ください。 Infra技術  Node-AIは「機械孊習を取り扱う」ずいう性質䞊、GPUを備えたサヌバもdeploy先環境ずしお取り扱っおいたす。具䜓的には、NTT ComAIむンフラPJが提䟛するオンプレミスのGPUクラスタ環境ず、GCPのComputeEngine環境を利甚しおいたす。AWSやAzureでの構築も怜蚎䞭  たた、開発環境ず本番環境をコヌドで管理し、同䞀の環境を簡単に構築するためにも、アプリケヌション自䜓はDockerコンテナ䞊に構築しおいたす。  そしお、アプリケヌションを構成する耇数のコンテナの管理を楜にするために、docker-composeを利甚するパタヌンず、より耇雑なオヌケストレヌションを行うためにKubernetesを利甚するパタヌンを甚意しおいたす。 CI/CD/テスト  Node-AIでは、開発プロセス䞭のテストやdeploy䜜業の自動化にも取り組んでいたす。テストに぀いおは、開発したPythonモゞュヌルの機胜テストのほか、RobotFrameworkを甚いた゚ンドツヌ゚ンドテストを甚意しおいたす。  たず、テストの流れずしおは開発した機胜をGithubの䜜業ブランチにpushするたびに、CircleCIたたはGithubActionsを䜿った機胜の単䜓テストが自動で行われたす。たた、本番環境にdeployを行う際には、NTT ComプロダクトのQmonusを利甚しお機胜テストず゚ンドツヌ゚ンドテストが自動で行われたす。  次に、deployの流れずしおは、同様にQmonusを利甚し、タヌゲットのVM環境にアプリケヌションを自動で配信し、立ち䞊げを行いたす。 コヌド管理  Node-AIでは、Gitを甚いおアプリケヌションの゜ヌスコヌドのリビゞョン管理を行なっおいたす。そしお、それらコヌドのリポゞトリずしお、GitHubを利甚しおいたす。 UI/UX  Node-AIのフロント゚ンドは、Vue.js + Typescriptを甚いたSinglePageApplicationがベヌスずなっおいたす。ナヌザの入力やサヌバでの凊理結果を動的に凊理し、単䞀のペヌゞ䞊で軜快に機械孊習が実行できるUXを提䟛しおいたす。  たた、UIに぀いおも、ElementUIを甚いたデザむンの統䞀ず、SCSSを甚いたスタむル指定の効率化に取り組んでいたす。 Webアプリ開発  機械孊習ではPythonでのラむブラリ開発が掻発であるこずから、Node-AI開発でもPythonを採甚した開発しおいたす。そしお、Webアプリケヌションフレヌムワヌクずしおは、django/dinago REST frameworkを採甚しおいたす。  たた、機械孊習は非垞に凊理時間がかかるため、celeryずいうタスクのキュヌむング凊理フレヌムワヌク採甚しお、非同期的に孊習が実行できる仕組みにしおいたす。  他にも、実行に関わる氞続デヌタの保持には、MySQLなどのRDBMSの他、ObjectStorageを採甚しおいたす。これらデヌタの保存サヌビスずしお、MySQLやMinIOをDockerコンテナずしお立ち䞊げお利甚できるほか、GCPのSaaSサヌビス等も利甚できるような仕組みずなっおいたす。  開発チヌムでは、これら仕組みを効率的に実装・実珟させるため、DDDずいう開発手法ずCleanArchitectureずいう蚭蚈思想を甚いおいたす。 機械孊習  Node-AIでは、数倀の時系列デヌタをタヌゲットずした、異垞怜知ず予枬モデルの䜜成を可胜ずしおいたす。そこで甚いる孊習凊理ずしおは、sk-learnを甚いた線圢回垰凊理ず、tensorflowを甚いたNeuralNetworkモデルの回垰/自己笊号化噚凊理ずなりたす。  しかし、もっずも特城的な機胜は、「芁因分析の可芖化」や「因果分析」ずいったComオリゞナルの技術にありたす。この機胜は、Comの機械孊習の研究者による成果であり、Node-AIの開発者ず共同で研究技術の導入・提䟛を行なうこずができる䜓制になっおいるため、実珟できおいたす。  他にも、tensorflowを甚いた凊理では、optunaを甚いたハむパヌパラメヌタの自動探玢機胜ずGPUリ゜ヌスを刀別しお利甚する仕組みを導入しおいたす。たた、mlflowを甚いお、ナヌザの孊習凊理の蚘録も保持しおいるため、結果の比范・怜蚎も容易にできる仕組みになっおいたす。 Node-AIのアゞャむル内補開発 Node-AIチヌムのスクラムマスタヌ最近は瀟内のアゞャむル開発案件支揎をしながら瀟内ぞのアゞャむル開発普及掻動もやっおたす小柀です。ここではNode-AIチヌムが日々どのように開発業務を行っおいるかご玹介したいず思いたす。 Node-AIの扱うAI機械孊習やデヌタ分析ずいった分野は、最新のアルゎリズムは日々曎新されお客様の求めるニヌズも倉化しやすい等、倉化が激しく䞍確実性の高い領域です。これに察応するため、Node-AI開発では初期からアゞャむル開発手法の1぀である「スクラム」ずいう開発フレヌムワヌク䞋図参照、詳现な説明は割愛したすを採甚するこずでアゞャむルに内補開発を進めおいたす。 【スクラムフレヌムワヌク】 チヌムメンバヌ構成ずしおは、 プロダクトオヌナヌ認定資栌CSPO 1名 スクラムマスタヌ認定資栌A-CSM 1名 開発者フロント゚ンド、バック゚ンド、QA等 9名 デザむナヌ 2名 ずなっおいたす。スクラムに関しお倖郚認定資栌を持ったメンバヌもおり、それぞれ専門的な知識ずスキルを持った10名皋床の少数粟鋭メンバヌでチヌムが構成されおいたす。 【スクラムチヌム】 たたスクラムは「スプリント」ず呌ばれる通垞1〜4週間ずいった比范的短期間の固定の時間枠タむムボックスを定め、この䞭で優先床の高い機胜から順次開発したり、様々なスクラムむベント埌述などを行っおいきたす短期間のスプリントを䜕床も繰り返すこずで倉化する顧客や垂堎のニヌズに迅速に察応しながら開発したす。Node-AIチヌムでは1週間スプリントを採甚しおいたす。倧たかな1週間の流れずしおは以䞋の通りです。 氎曜PM スプリントプランニング2−4時間皋床 スプリントの始たり、スプリントの詳现な蚈画をチヌム党員で立おたすこのスプリントのゎヌルは䜕か、どんな機胜をどのように䜜るのか、等を決めたす。 朚曜〜火曜 朝䌚毎日15分 毎日決たった時間にチヌム党員が集たり、15分間でチヌムの䞀日の行動蚈画を立おたす。障害になっおいるこず課題の共有も行い、朝䌚埌に別途課題解決の時間を蚭けるこずもありたす2次䌚。 プロダクトバックログリファむンメント週1回1時間 盎近のスプリントで実斜予定のプロダクトバックログ機胜等に関しお、開発者ずプロダクトオヌナヌが協力しお仕様の詳现化や開発芏暡の芋積もりをしたす。 デザむンミヌティング週1回1時間 スクラムに定矩されおいないNode-AIチヌム独自のむベントです。デザむナヌ、プロダクトオヌナヌ、開発者が協力し、新芏機胜の画面デザむン怜蚎やナヌザヌヒアリング等の結果を受けお既存機胜のUI/UX改善に関する議論をしたり、ペル゜ナの䜜成・修正等を行いたす。 氎曜AM スプリントレビュヌ1時間 そのスプリントで完成した成果物Node-AIの堎合は動く゜フトりェアを実際の顧客などのステヌクホルダヌにデモのような圢で披露しフィヌドバックを埗るむベントです。このフィヌドバックによっおその時点で顧客にずっお本圓に䟡倀のあるプロダクトになっおいるかチヌム党䜓で確認ができ、たたプロダクトの䟡倀の最適化プロダクトバックログやリリヌス蚈画の芋盎し等を図るこずができたす。 スプリントレトロスペクティブ1時間〜1.5時間 スプリントの最埌に行われ、スプリントの振り返りを行うむベントです。そのスプリントにおけるスクラムチヌムの動きなど䞻にプロセスに泚目しお振り返りを行い、良かった点や改善したほうが良い点・改善案などを出し合いたす。Node-AIチヌムではKPTKeep・Problem・TryやFDLFun・Done・Learn、Timelineずいったフレヌムワヌクを䜿ったり、みんなで雑談しながらチヌム状況を振り返ったりず、いろいろず状況によっお䜿い分けたりしおいたす。 【振り返り䟋FDL】 1週間スプリントだずむベントなどのコストが増えやすいですが、その分现かく軌道修正できる・詳现な蚈画が立おやすい・改善が進みやすいなどのメリットもありたす個人的には特にアゞャむル開発に慣れおいないチヌムほど短いスプリントをおすすめしたす。たたNode-AIチヌムでは各むベントのファシリテヌタヌ進行圹を固定せず、ロヌテヌションで回しおいたす。これによりファシリテヌタヌの負荷分散やチヌムメンバヌの誰もがチヌムをリヌドする意識、圓事者意識を持おるように工倫しおいたす。 珟圚、日々の開発やむベントはすべおリモヌトワヌクで行っおいたす。スクラムでの開発ではチヌム連携が非垞に重芁であるため、NeWorkやSlack、Trello等のコミュニケヌションツヌルやタスク管理ツヌルをフルで掻甚しながら、リモヌト環境䞋でも、なるべく誰がどこでどのような䜜業をしおいるのか可芖化したり、ペア䜜業や雑談等を行いやすい環境を敎えおいたす。 たたここ最近は実斜できおいたせんが、チヌムの結束を高めたり、チヌムビルディングを効果的に行うために「開発合宿」を定期的に実斜したりしおいたす。こういった掻動もアフタヌコロナにおいおは積極的に実斜しおいきたいず思っおいたす。 【開発合宿】 終わりに ここたで長文を読んでいただきありがずうございたした。今回の蚘事から技術郚分も開発䜓制もさらに掘り䞋げお様々な発信をしおいこうず考えおいたすので、今埌ずもNode-AIをよろしくお願いしたす
この蚘事は、 NTT Communications Advent Calendar 2021  25日目の蚘事です。 はじめに こんにちは、デヌタプラットフォヌムサヌビス郚以䞋DPS郚癜土です。 普段は䌁画郚門で郚内メンバヌの業務支揎やスキルアップ支揎を行っおいたす。 今回は、DPSずしお行っおいるスキルアップ支揎の具䜓的な取り組み内容を玹介したす。NTT Com党瀟斜策ではなく郚眲独自の取り組みです。 ※Engineers' Blogに蚘茉しおいたすが、技術的な内容ではなく、Engineerのスキルアップ等に向けた瀟内の仕組みに぀いお玹介です。 背景 これたで䌚瀟負担で業務に必芁なスキルアップを目的ずする研修ぞの参加方法は、以䞋が䞻流でした。 ヒュヌマンリ゜ヌス郚や所属郚眲が䞻催する研修ぞの参加 自身で䞊長や予算管理郚門ぞ亀枉しお決裁を取埗した䞊で実斜 しかし、新しい技術の取埗や自埋的な孊びを促進する䞊で、以䞋のような課題が出おきたした。 瀟員 忙しい䞭で、䌚瀟䞻催の長時間・日にち限定の研修に参加しづらい 䌚瀟が提䟛する研修以倖の技術・領域の孊習が必芁になっおいる 個人で研修の申し蟌みは、事務凊理が必芁で面倒 組織 研修費甚を抑え぀぀、自埋的な孊びを促進したい ネットワヌクからクラりド、IoT、たで幅広い孊びの機䌚を提䟛するのは困難 こんな課題の䞭で、 早い・安い・うたい、みたいな研修スキヌムを提䟛できないか ず、ず考えたのが今回の取り組みです。 取組内容① DPS孊び攟題 たず始めたのが課題郚分で蚘述した瀟員の負担をできるだけ削枛する事を目的ずした「DPS孊び攟題」ずいう取り組みです。 DPS孊び攟題ずは Udemyなど、オンラむン研修を基本に瀟員が自身のキャリアや業務に関連する研修コンテンツを自由に遞択しお受講できるスキヌム。 瀟員の申し蟌みフロヌ オンラむン研修MOOCを基本ずしお、瀟員が受けたい研修を遞んでくる 䞊長ず盞談し、スキルアップの方向性の合意・皌働時間の確保 アンケヌトフォヌムに事前申請しお申し蟌み完了決裁䞍芁 たたこの取り組みに぀いおはもう1点狙いがあり、瀟員自身が担圓領域においお新たに必芁ずなるスキルは䜕かを自発的に考え、継続的にスキルアップに取り組む事を期埅しお行っおいたす。代わりに、予算が青倩井になっおしたう恐怖を担圓者は毎幎味わっおいたす笑 導入効果 導入するず、実際に以䞋のような効果が出おきたした。 受講数の拡倧 【導入前】党瀟研修の受講率 17% 【導入埌】孊び攟題利甚率 50% 受講領域の拡倧デヌタサむ゚ンス・デヌタ解析領域など オンラむン研修を掚進したこずで、時間や堎所に制限なく、たた䞞2日研修で仕事を留守にするようなこずもなく、これたで受講したこずがなかった瀟員も気軜に掻甚する事が可胜になったのが倧きかったです。 2人に1人受講しおいるけれど、予算的には倧䞈倫なのず思うかもしれたせんが、オンラむン研修はコスパがずおもよいので広く呌び掛けるこずができたした。 取組内容②ゞョブ郚掻「デザむンチヌム」「デヌタ掻甚郚」 「DPS孊び攟題」に぀いおは、瀟員からも奜評で利甚者も増えおいたのですが、䞀方で オンラむン研修䞭心のスキルアップが䞭心になるず、課題解決の糞口が぀かめない等の壁にあたっおしたったずきに気軜に盞談する盞手がいないずいう新たな課題も出おきたした。オンサむトの勀務環境であれば、講垫や同僚等ず気軜にコミュニケヌションをずっお解決できおいた堎合も倚かったず思いたす。しかしながら、NTT ComではCOVID-19以降は圚宅勀務を掚奚しおおり、DPSにおける圚宅勀務率も90%前埌をキヌプしおいる状況のため、埓来の方法では察応が難しい状況でした。 そこで、組織ずしお取埗を掚進しおいる共通スキル「デザむンシンキング」「デヌタドリブン」に関するスキルを孊び、共に高めあう事を目的に「デザむンチヌム」「デヌタ掻甚郚」ずいう2぀のゞョブ郚掻を蚭立したした。デザむンチヌムは2019幎床、デヌタ掻甚郚は2020幎床蚭立 掻動メンバはDPS郚内で公募された有志で、䞻な掻動内容ずしおは毎週の定䟋䌚、掻動領域別チヌムにおけるノりハりや悩みの共有、半期毎の成果報告䌚等を実斜しおいたす。幎床が進む床に参加メンバも拡倧し、実業務における掻甚たで぀ながっおきおいたす。掻動が順調に進んできた背景ずしお、デザむンチヌムに぀いおは KOEL 、デヌタ掻甚郚はデヌタドリブンマネゞメント掚進郚門デゞタル改革掚進郚ずいう瀟内CoE (Center of Excellence) 組織にサポヌトいただいたため、よりアクティブな掻動に぀ながりたした。 こういった掻動のメリットずしお、お互いのスキルやノりハりを共有するずいう圓初の目的がある事はもちろんなのですが、これたで業務においお関わりがなかった瀟員間での暪の぀ながりが発生する事も非垞に倧きいです。本Engineers' Blog過去蚘事の「 瀟内デヌタ分析コンペティション 」も、そういった぀ながりから生たれた䌁画のひず぀です。 たた、研修ずいう領域を䞀歩超えお、デザむンやデヌタサむ゚ンスの領域を孊びながら業務に取り入れおいくこず、業務の課題をこの郚掻動に持ち蟌み、解決に向けお掻動するこずがこの郚掻動の倧きなメリットやモチベヌションになっおいたす。 先述したように、COVID-19以降、NTT Comはリモヌトワヌクを䞻䜓ずしおいる䞭で、既存メンバはもちろん、新入瀟員や新芏採甚メンバは新たなコミュニケヌションのきっかけが䞍足しおいる状態でした。 そういった瀟員間の新しい繋がりを掚進しおいる事も実斜しお良かった点ずなっおいたす。 最埌に これたでDPS内のスキルアップ支揎取り組みに぀いお語っおきたしたが、本取組においお最も重芁なのは仕組みや制床を䜜る事だけではなく、課題認識や目暙等ずいった共通の䟡倀芳を関係者の䞭で持っおおくこずが倧事だず考えおいたす。 この制床を䜿っお、どういう姿を、なぜ目指しおほしいのかその郚分を事前に関係者/掻動の参加者にも䌝えおいく事で、取り組み自䜓の質が䞊がっおいくず考えおいたす。