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

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