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

Transcript

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

2. 自己紹介 • SNSでの名前 ◦ ufoo68（@ufoo_yuta） • 出身地 ◦ 滋賀県 •

   やってること ◦ スポーツIoTLT主催 • 最近のできごと ◦ YouTube活動はじめた

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

4. できなかった理由 • M5Stackのmp3再生ライブラリとwifiが一緒に動かせなかった ◦ 理由は不明 • WiFiModeをいじっていたらrebootを繰り返すようになってしまった ◦ 壊れた（？） •

   詳しく調べる時間がなかった ◦ 手を付けだしたのがほぼ前日

5. さて困った

6. ここで追加の自己紹介 • 本名 ◦ 松永勇太 • 所属 ◦ 株式会社ACCESS ◦

   IoT事業部（本当はもうちょっと長ったらしい） • 普段のお仕事 ◦ IoTが絡んだサーバーやフロントエンドの開発 ◦ 最近はクラウド（AWS）がメイン

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

8. IoTが絡む上での課題 • リソース制限 ◦ クラウド側が意図的にパフォーマンスの制限を設けているもの ◦ これは基本的には上限の引き上げでなんとかなる • パフォーマンス ◦

   クラウドのリソースでの性能限界で起こったりする ◦ 場合によっては設計変更が必要 • コスト削減 ◦ クラウドを使う上での使用料金の問題 ◦ IoTが絡む場合は大量リクエストによって高額になったりする ざっとあげてみた感じこんなもの（おそらく他にもあるかも）

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

10. DynamoDB

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

    • 単純なデータの読み書きに強い

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

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

14. CloudWatch

15. CloudWatchとは • AWSリソースのモニタリングを行うためのサービス • とりあえず今回取り上げるのはCloudWatch Logs • CloudWatch Logsの中でもlambdaに関するlogの話 •

    要はconsole.log()やprint()で表示するデータ

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

17. 以上です

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