SecHack365@2017を振り返ろう
こんにちは。 遅くなりましたが、昨年2017年度に参加していたSecHack365ですが、先月無事に卒業することができました。今回はそのまとめについて書いていきたいと思います。
まず、私達のグループが最終報告回で発表した資料(一部修正)はこちらになります。忙しい方はこちらの資料に目を通して「ふーん」と思ってくれるだけでありがたいです!
改めまして、私は現在電気通信大学の大学院生をやっていますtokina(ひみつ)です。昔はネットワーク系の研究室に所属しており、自動車のセキュリティについての研究をしていました。現在は電通大のネットワーク系の研究室に移籍し、IoTに関する研究をしております。昨年からパブリッククラウド技術に興味を持ち始め、今回SecHack365の私のチームの中でもクラウド部分をメインに担当しています。
SecHack365について詳しくは以下のページをご参照下さい。
また、日程が非常に近いですが、SECCON×SecHackのセチャコンというイベントが開催予定です。皆さんよければ足を運んでみて下さい。秋葉原行きましょう! 2017.seccon.jp
現在('18.04.09執筆時)には2018年度生を募集しています。課題申し込みと提出申し込み締切が異なるので注意して下さい。 学生の方は無料で参加できます。ただし自己管理は徹底して下さいね。
今回、一年の総轄としてまとめました。SecHack365参加を目指す方の参考になれば幸いです。
私にとってのSecHack365(SecHack367)とは
私にとって、振り返ってみるとSecHack365とは技術的交流はもちろん、自身のモチベーションをしてくれる環境でした。
しかし、この機会で出会うことが出来た人や、今後の指針が見えてきたこともあり、私にとってはとても大切な一年だったことは間違いないと思っています。
ちなみに就職活動とかでも役に立つと思います!
え、 SecHack367 ですか?気になる方は参加して見ましょう!
応募のキッカケ
キッカケとは些細なものだと思います。私はセキュリティ・キャンプに参加していたので、サイボウズで情報が流れてきており、耳にはしていました。しかし、私はギリギリまで申し込んではいなかったのです。
申し込み期限前日、私はそういえばと思いサイボウズを開き、このSecHack365に応募しました。ちなみに応募課題は非公開だそうです。
最初、SecHack365を見たときに、「キャンプ関連なんだろうか・・・」くらいに漠然と考えていました。
実際に参加するとキャンプの講師やTAレベルの人が沢山おり、最初は不安でいっぱいでした。。。
ちなみに選考の基準ですが、「参加してともにイノベーションを起こせるか(なにか新しいことをひらめけるか)」だそうです(たしかそういっていた)。
学歴や大学、住んでいる場所とかは一切選考に関係ないそうです。また、名前も伏せて選考されます。つまり、応募者が何を考えているかの本質が見られるのだと思います。
プログラミング能力は必須でしょうか?
私は”必須”だと思います。無いと困るとかではなく、少なくとも「アイデアを実現する力」のタネが必要だと思います。まぁハッカソンだからとも言えるでしょうか。
ちなみに私のプログラミング能力はそんなに高くない...と思っています。
チームメンバーの紹介
私のチームは4人チームでした。チームメイトは私を含め以下の方たちでした。
@o_hi_rangosta, @kiyoooo44,@_tokina23 (私), @Balius1064
また、途中で(私が勝手にお願いして)特別顧問として協力してくれた
@Shi_ma715, @sm_nz_gk
みなさん、ありがとうございました!
SecHack365でなにをつくっていたのか?
私のグループでハッカソンしていたのは、一言で言うと 『自動車の情報を収集し、自動車情報を利活用するプラットフォーム』 です。最初の着眼点は「パブリッククラウドを使って自動車の情報を収集した例って聞いたこと無いよね?」「簡単にできそうだけど、実際に作ってみたらなにか見えてこないかな?」というところからでした。そこから見えてきたのが 「自動運転のための運転者データの収集」 でした。
全体の概要図は下図のようになります。こちらは実際の成果発表会で使用した資料を一部修正したものです。
実際にこのハッカソンでは 自動車に搭載する車載器から、フロントエンドの可視化まで一貫して作成 しています。これにより、自動車を完全に”IoT”化できました(たぶn)。
最終的にハッカソンで出来上がったアーキテクチャですが、もともとこのような最終形を想定していませんでした。今回は折角なので、そのアーキテクチャとともに振り返ってみたいと思います。
アーキテクチャと若干詳しい解説
私達グループメンバーはこの概要図にある通り、全体のうちの一部をそれぞれを担当していました。私はこの中でAWSやその周辺を主に担当しています。最初に掲載した資料にもありますが、最終的なアーキテクチャは以下になります。
データの流れに注目しましょう。まず、自動車に搭載された車載器からSORACOMへとデータが転送されます。ちなみにこの時データはSORACOMの専用回線を利用してアップロードされます。
そののち、SORACOM Funnelというサービスを利用して、AWS Kinesis Streamへとデータをストリーム転送します。このFunnelとはアップロードのみに特化したサービスです。一度AWS Kinesis Streamに流れてきたデータは少しポーリングされるため、厳密にはリアルタイムではありません。
次にKinesis StreamのデータがポーリングされるとAWS Lambdaのメインとなるプログラムがキックされ、Base64でデコード、JSONを取り出します。その後、異常値検出(ここでは簡単に閾値を決め打ちしています)、ElasticsearchにPOST、AWS SNSのキック、S3にデータをPOSTします。
管理者向けの利用を想定した可視化として、AWSに用意されているElasticsearc ServiceのKibanaを利用しています。ここで可視化されるデータとその型は以下です。
- 位置情報(GPS)
- geo_point
- 速度
- double
- エンジン回転数(RPM, rotation per minutes)
- int
- ステアリング
- double
- CANの使用帯域(bandwidth)
- double
- 自動車情報(自動車ID)
- Text
- エラーメッセージ
- Text
AWS SNSは通知サービスです。SNSで一括管理する通知先をLambdaで指定することで、複数の宛先(Slack, e-mail, LINEなど)へ一度に通知します。ここで、SlackやLINE(+IFTTT)はweb hookを噛ませないといけないので、スケーラビリティのため別のLambdaで実行しています。
S3に保存したデータは自動車情報毎に分けられ、全て生のテキストファイルとして置かれており、運転評価を行うEC2サーバ(今回はFlaskを利用してwebアプリを構築している)からデータを取得しに行きます。
EC2サーバで行う運転評価については@Balius1064が作成してくれました。
また、同じように@kiyoooo44さんが作成してくれたUnityアプリケーションはS3へデータを取りに行くのですが、AWS SDKを利用してデータにアクセスするための認証にCognitoとIAMを利用して承認を行っています。
以上が全体のデータの流れになります。
振り返り
SecHack365は(昨年度は)全部で7回のオフラインハッカソンと、その間のオンラインハッカソンで行われます。昨年度の日程は以下でした。
- 2017 05 東京 NICT(国立) 顔合わせ
- 2017 06 東京 蒲田 アイデアソン
- 2017 08 福岡 LINE福岡/志賀島 縁日(ワークショップ)、ハッカソン
- 2017 10 北海道 札幌 縁日(ワークショップ)、さくらのデータセンター見学、ハッカソン
- 2017 12 大阪 ハッカソン
- 2018 02 沖縄 糸満 成果報告
- 2018 03 東京 秋葉原 最終成果報告、ポスター展示
最初は運営の方々も手探り状態で、私達が最初の卒業生になるということもあり、一期生としての”責任”のようなものを感じていました。私達のグループメンバーは、蒲田回のアイデアソンのときから一貫して変わりませんでしたが、多くのひとはソロプレイヤーになったりするなど、悩んでいる人も多かったかな、という印象です。
今年は最後のブラッシュアップを鑑みて、12月と1月を空けて最終報告回になっていますね。
それではここからアーキテクチャとともに振り返ってみたいと思います。
2017 08 福岡 LINE福岡/志賀島 縁日(ワークショップ)、ハッカソン
8月当時、私は丁度AWSのインターンシップに参加したばかりで、パブリッククラウド初心者でした。そこで、インターンシップで利用したKinesis、Lambda、RDSを利用しようと考えたのです。
福岡回の最初はLINEさんのオフィスにて縁日という名前のワークショップをして頂きました。そこでnekoruriさんのワークショップにあったSORACOMを利用すればいいのでは?とヒントをいただきました。
自動車のデータはストリームデータですので、Kinesisを利用するのはわかっていました。また、その簡単な処理にはサーバレスファンクションであるLambdaが適していることもわかっていました。しかし、そこから先は正直当時はかじった程度しか理解できていなかったため、このような簡単な仕組みになっていました。結局8月回の最後にはSORACOMから送られてきたデータをKinesisで受け取るところまで進みました。
この8月で実際に作りたいモノがぼんやりと決まってきました。
8月回は非常に暑く、海辺での照りつける日差しを今でも覚えています。大自然発想法 ですね。ここは完全にリゾート地で、海が最高でした!
2017 10 北海道 札幌 縁日(ワークショップ)、さくらのデータセンター見学、ハッカソン
10月では、縁日は一部任意になり、ハッカソンがメインとなっていました。8月から10月までSlackでやり取りしながら少しずつ進めていきました。実は9月はトヨタ自動車にインターンシップに行ったり・・・
10月にはElasticsearchとLamndaの連携がどうしても上手く行かず、データの視覚化は出来ていませんでした。S3に保存は出来ていたような気がしますが、、
私達のチームはこの10月回から自動車の利用を申請しており、特別に外で実験させてもらいましたv
上の図は北海道回の最初のアーキテクチャで、この回の最後には下図のようになりました。
北海道回のハッカソンおかげで、かなり実際のものに近づいてきました。私は当時Elasticsearchにデータをどうしても格納できませんでした。もともとLambda一つでS3とElasticsearch両方にデータを流そうと考えていたのです。そこで、nekoruriさんにElasticsearchに格納する部分はNode.jsにすればよいのでは?とのアドバイスを頂いたのです。
私としては人生で修学旅行以来の2回めの北海道でした。案外寒くもなく、ホテルの屋内プールと屋上の露天風呂が最高だったのを覚えています。また紅葉が最高でした。空港では雪ミクを見れたり、時計台や電波塔にも行くことが出来ました。
2017 12 大阪 ハッカソン
「12月回でハッカソンは一通りおわりなので」とのことだったので、12月回までいろいろ頑張ってどうにか形にしようと奮闘しました。調べていてわかったのですが、どうやらPythonでElasticsearchにデータを流す例があまりないことがわかりました。それでもどうにかLambda一つでS3とElasticsearchにデータを流すことに成功し、大阪回で簡単な視覚化をできるところまで持っていくことが出来ました。これで、だいたいの形は決まりました。
ここまでがいわゆるインフラの部分であり、成果報告会まで、残るは”視覚化”部分となったのです。私が残る課題としていたのは付加価値である”通知”の部分です。AWS SNSの利用は決定していたのですが、時間が足りず当時はそこまで完成していませんでした。
大阪は以前から行く機会が多かったので特に何もありませんでしたね。個人的にモダン焼きが美味しくて良かったです。広島焼きとは違うのでしょうか?
2018 02 沖縄 糸満 成果報告
2月になるまで約1〜2週間に一度Slackでミーティングを行いながらどうにかみんなで形にできました。
私もAWS SNSを使った通知を実現し、それに合わせてこのような最後のアーキテクチャになりました。しかし、これはスケーラビリティや負荷などが考慮されていないため、実際の稼働の際にはさらに改良しないといけないのは明白ですが、去年全く知らない状態からここまで作り上げることが出来たので私としては一区切り出来たかなと考えています。
さて、この最終回の沖縄ですが、今年度の最終回も沖縄で開催される予定みたいですね。といってもホテルが豪華ですが、この時期の沖縄の天気は例年曇りで貼れることは珍しいのです。私は沖縄が大好きなので最終回が沖縄でとても嬉しかったです。ソーキそばおいしい!また国際通りに行きたいですね。
2018 03 東京 秋葉原 最終成果報告、ポスター展示
最後に、最終成果報告会と題して秋葉原にて一般向けのパネル展示と一部のグループ及び個人がプレゼンを行いました。この時行ったプレゼンの資料が冒頭のスライド資料になります。ここまで一年走りきれて本当に良かったと思っています。皆さんいろいろ思うことや悩んだことも合ったと思いますが、それも含めて成長できたのではないでしょうか。
デモしたい!
デモ用に撮影していた動画を貼っておきます。※一応許可をもらっています。
まず、このように実際に自動車に乗って実験を行います(車種は分かる人にはわかるかもしれないですね、、)。ダッシュボード上のラズパイが今回作成した車載器になります。ここからSORACOM回線でクラウドにデータをアップロードしています。
Kibana上ではこのようにデータが可視化されます。管理者は複数ユーザが存在する場合は一つにデータを絞ることができます。また警告データなどの絞り込みや、過去のデータの検索を比較的簡単に行うことが出来ます。ちなみにKibanaにはAWS ElasticsearchにProxyを利用してアクセスしています。
Unityのアプリケーションは再帰的にS3に更新データがないか問い合わせにいきます。AWS LambdaでデータがS3に保存されると、更新したデータがUnityアプリケーションに表示されます。Alertフラグが立っていた場合、動画のように警告が流れるようになっています。
最後に
最終成果報告会の様子について、アスキーさんの記事に取り上げていただきました!
SecHack365を通してパブリッククラウド技術を実際に利用することができて非常に私としても楽しんで取り組むことができました。この一年、就活や勉強、研究といろいろありました。またいつか皆と会えることを楽しみにしています!
と、ここまでこんなに長々と文章を書いておいて一体誰が読むんだ、、と自問自答しておりますw
いやしかし本当はまだ技術てきなレベルの記事をQiitaに書きたいのです、、
来年度からもSecHack365という取り組みがうまくいくように私も少しでもお手伝いできれば良いですね。私も社会人に向けて研究を頑張りたいと思います!