ネタが作れなかったので、 本業の話に触れてみる in IoTLT

自己紹介 ● SNSでの名前 ○ ufoo68（@ufoo_yuta） ● 出身地 ○ 滋賀県 ● やってること ○ スポーツIoTLT主催 ● 最近のできごと ○ YouTube活動はじめた

本来話したかったネタ M5Stackでリモート発表をにぎやかすもの mp3とかで声援的なものを再生する 聴講する人 pub/sub通信

できなかった理由 ● M5Stackのmp3再生ライブラリとwifiが一緒に動かせなかった ○ 理由は不明 ● WiFiModeをいじっていたらrebootを繰り返すようになってしまった ○ 壊れた（？） ● 詳しく調べる時間がなかった ○ 手を付けだしたのがほぼ前日

さて困った

ここで追加の自己紹介 ● 本名 ○ 松永勇太 ● 所属 ○ 株式会社ACCESS ○ IoT事業部（本当はもうちょっと長ったらしい） ● 普段のお仕事 ○ IoTが絡んだサーバーやフロントエンドの開発 ○ 最近はクラウド（AWS）がメイン

不本意ながら変えた上でのネタ IoTでのクラウド開発で気をつけたいこと

IoTが絡む上での課題 ● リソース制限 ○ クラウド側が意図的にパフォーマンスの制限を設けているもの ○ これは基本的には上限の引き上げでなんとかなる ● パフォーマンス ○ クラウドのリソースでの性能限界で起こったりする ○ 場合によっては設計変更が必要 ● コスト削減 ○ クラウドを使う上での使用料金の問題 ○ IoTが絡む場合は大量リクエストによって高額になったりする ざっとあげてみた感じこんなもの（おそらく他にもあるかも）

今回の話について ● AWSを使った課題について２つ触れてみる ○ DynamoDBとCloudWatch ○ IoTが絡まなくても起こりうる課題かもしれない ● 一部の元ネタは先日Qiitaに書いたけど１LGTMもつかなかった記事

DynamoDB

DynamoDBとは ● AWSが提供するNoSQLのデータベース ● フルマネージドで分散データベースの運用とスケーリングに伴う管理作業をまかせ ることができる ● 高い可用性と耐久性が特徴 ● Lambdaとの相性がいい ● 単純なデータの読み書きに強い

ここで気をつけたいこと DynamoDBは、 大量のデータの追加・読み取りには強いが大量のデータの更新に結構弱い ー＞数千件単位のデータ書き込みになるとその性能差がもろに出る data1 data2 data3 data1 data2 data3

ここで気をつけたいこと API Gatewayが絡む場合、それのタイムアウトについても気をつける必要がある ー＞最大でも３０秒。これ以内に収められない場合は、別のLambdaを呼び出すなどの システム変更、もしくは別の工夫が必要 timeout

CloudWatch

CloudWatchとは ● AWSリソースのモニタリングを行うためのサービス ● とりあえず今回取り上げるのはCloudWatch Logs ● CloudWatch Logsの中でもlambdaに関するlogの話 ● 要はconsole.log()やprint()で表示するデータ

ここで気をつけたいこと CloudWatchのログは保存より取り込みにお金がかかる ->console.log()を呼び出した分のお金がGB単位でかかる IoTレベルの大量リクエストを捌いてい るとここが結構響いてくるので、 logで 表示するデータの取捨選択が重要に なる

以上です

まとめ ● IoTに関する開発（主にサーバー）で意識すべきことは常に大量のリクエストが投げ られてくるということ ● クラウドを使うと便利な反面、リソース上限や使用コストを別で気にすることになる ● 結局のところ、システム構成・アプリケーションでの設計が重要