Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
空調設備向けIoTシステムにおけるクラウドランニングコスト
Search
Kenta Nohara
October 22, 2019
Technology
4.1k
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
空調設備向けIoTシステムにおけるクラウドランニングコスト
ServerlessDays Tokyo 2019
Kenta Nohara
October 22, 2019
More Decks by Kenta Nohara
See All by Kenta Nohara
AWSを活用した空調機IoTプラットフォームの開発
nohara
7
7.3k
Other Decks in Technology
See All in Technology
HolmesGPTで始めるSREエージェント入門!プラットフォームの障害調査はAIにお任せ 〜
sanghyuk
0
220
「どのログを見ればいい?」 から始めた サーバーレス障害解析
y_waka1
1
150
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
16
120k
行動するAIのためのオントロジー | DevRev — Encraft #26.pdf
dvrv_tknrszk
1
500
HacobuにおけるFDEとは/登壇資料(戸井田 裕貴)
hacobu
PRO
1
130
認知負荷を吸収し、プロダクトをまたぐPR Preview基盤の設計事例
taiki45
2
460
C#コードの結合を可視化する Roslyn解析による設計改善と リファクタリング判断
dora56
0
870
GitHub Agentic Workflows を触ってみる
htkym
2
780
作って終わりじゃないサーバーレス 〜9年運用する大規模EC物流API基盤の設計・運用のリアル〜
zozotech
PRO
0
560
なぜAI任せのゲームは面白くならないのか?
hirohasuyoutube
0
200
20260929_AmazonGuardDutyの検出通知メールにAWS DevOpsAgentの調査結果を追加する
yhana
1
280
【データ横丁主催】AI Agentがコンテキストを使って仕事をした後、何が残るのか― 組織の経験を次の判断に引き継ぐ「Agent Memory」
shisyu_gaku
2
110
Featured
See All Featured
WCS-LA-2024
lcolladotor
0
830
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
910
SEO for Brand Visibility & Recognition
aleyda
0
4.8k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
First, design no harm
axbom
PRO
2
1.3k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
550
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.4k
Amusing Abliteration
ianozsvald
1
320
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Making the Leap to Tech Lead
cromwellryan
135
10k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.7k
Transcript
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 空調設備向けIoTシステムにおける クラウドランニングコスト
ダイキン工業株式会社 野原健太
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 2 自己紹介
野原 健太 ダイキン工業株式会社所属 ➢ 2008年4月に入社 ➢ 入社以降、組み込みソフト開発(主にC++) ➢ ここ数年、IoTシステム開発に進出 ➢ クラウド歴=AWS歴=サーバーレス歴 2年ほど
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 3 今日話したいこと
製造メーカーの組み込みソフト開発技術者が、 サーバーレスIoTシステムの開発に挑戦し、 苦労した話 Amazon DynamoDBの設計について、クラウ ドランニングコスト最適化の観点で工夫した話
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. ダイキン工業のIoTへの取り組み
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 5 ダイキン工業株式会社とIoT
会社概要 • 空調事業を主力とする会社 • 150カ国以上に事業を展開 IoTの取り組み(Daikin Global Platform) 全世界の空調機をインターネットにつないで、販売、 施工、運用、保守、更新といったライフサイクルに対 するサービスを提供する
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 6 Daikin
Global Platform Daikin Global Platform アプリケーション インターネット インターネット 建物 Edge 空調設備 機器 空調設備 機器 建物 Edge 空調設備 機器 空調設備 機器 インターネット
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 7 Daikin
Global Platform システム規模 • 想定機器接続台数500万台(各機器から毎分データ発生) • 想定ユーザー数30万人(同時アクセス9万人) • 求められる高い処理性能とスケーラビリティ • 無限に発生するデータを扱えるストレージ サーバーレスでやるしかない!! • 性能とスケーラビリティの担保をAWSに任せる! • 断固としてRDBは使わず、全てをNoSQLでまかなう!
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 8 Daikin
Global Platform 接続台数に応じてコスト最適化 • 初期投資を限りなく抑えたい(スモールスタート) • 接続台数とクラウド利用料を限りなく正比例にしたい サーバーレスでやるしかない!! • 徹底的な従量課金サービスの利用へ! 利用料 接続台数
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 9 サーバーレス開発
サーバーレスのクラウドサービスを適切に使いこなすことで、機能面、非機 能面ともに、作りたいシステムは作れる。 あとは、目標ランニングコスト以内で動くシステムを作れるかどうか。 一般的に、「サーバーレス化=コストが下がる」と言われることがあるが、 大量の負荷がかかるシステムでは、コストが青天井になるケースがある。 (サーバーレスが故に、負荷に応じてスケールし動いてしまうので。) そのため、コストを意識した設計や実装が重要となる。 各サービスの特性、課金体系を把握し、それに応じて適切に設 計を行うことが重要 サーバーレス開発は クラウドランニングコストとの闘い!! といっても過言ではない
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. Daikin Global
Platformのシステム構成
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 11 システム構成
Daikin Global Platform アプリ ケーション Edge 空調設備 機器 Amazon Kinesis Data Streams Amazon DynamoDB Amazon API Gateway • 空調設備機器から送られてくる運転データをKinesisで受け、Lambda で処理してDynamoDBに格納 • DynamoDBに格納された運転データを API Gateway ⇒ Lambdaを経由してDynamoDBから取り出し • DynamoDBには、設備機器の遠隔監視のため、最新の機器データのみ を格納(時系列データではない) 建物 ユーザ AWSのサーバーレスのサービスを組み合わせて構築
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 12 システムの負荷条件
Daikin Global Platform アプリ ケーション Edge 空調設備 機器 Amazon Kinesis Data Streams Amazon DynamoDB Amazon API Gateway 空調設備機器側の負荷 • 1機器あたりの運転データサイズ=数百項目(数十kB) • 機器から送られてくる運転データは、毎回全項目が送られてくるわけでは なく、数項目ずつ送られてくる。(値の変化があった項目のデータのみ送 られてくる) • 各機器の運転データは毎分数項目変化する ⇒毎分、接続機器数×数個の運転データが送信される 建物 ユーザ
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 13 システムの負荷条件
Daikin Global Platform アプリ ケーション Edge 空調設備 機器 Amazon Kinesis Data Streams Amazon DynamoDB Amazon API Gateway アプリケーション側の負荷 • 機器の遠隔監視のため、API Gateway経由で運転データを取り出す • 各ユーザは建物内の全機器の監視を行うために、同時に複数機器(数十機 器)の運転データを取り出す • ユーザは遠隔監視中は毎分運転データ取り出しを行う 建物 ユーザ
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 14 クラウドランニングコスト構造
Daikin Global Platform アプリ ケーション Edge 空調設備 機器 Amazon Kinesis Data Streams Amazon DynamoDB Amazon API Gateway 建物 ユーザ 以下のランニングコストが全体の大半を占める ①大量の運転データをDynamoDBに書き込む際に消費する WCUコスト ②機器の遠隔監視をリアルタイムに行うために、アプリから大 量に送られてくるリクエストを処理するために必要なLambda にかかるコスト ① ②
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 15 クラウドランニングコスト構造
Daikin Global Platform アプリ ケーション Edge 空調設備 機器 Amazon Kinesis Data Streams Amazon DynamoDB Amazon API Gateway 建物 ユーザ ①のWCUをおさえ、②のLambdaの処理時間をおさえ、 ランニングコストを最適化するためには、 DynamoDBのデータ構造がポイントとなる。 ① ②
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. コストを抑えるためのDynamoDB設計
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 17 DynamoDB設計
その1 最初に設計したDynamoDBの構造は以下の通り Primary Key Data-Item Attributes… Partition Key Sort Key Data 機器ID 時刻 100 2019-10-22T14:40:00.000Z 運転データ(JSON形式) 101 2019-10-22T14:40:00.000Z 運転データ(JSON形式) ・・・ ・・・ ・・・ 1機器1アイテムとして運転データを格納する この設計には問題があった…
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 18 DynamoDB設計
その1 Primary Key Data-Item Attributes… Partition Key Sort Key Data 機器ID 時刻 100 2019-10-22T14:40:00.000Z 運転データ(JSON形式) 数十kB 101 2019-10-22T14:40:00.000Z 運転データ(JSON形式) 数十kB ・・・ ・・・ ・・・ 1アイテムが数十kBあるため、数百項目ある運転データの1項目だけが送られてき た場合でも、その書き込み処理に数十WCUを消費する。 各機器からは、毎分データが送られてくるため、毎分、数十WCU×接続機器数の WCUを消費する。 運転データ書き込みの際のWCUがかかりすぎる 【DynamoDBの課金仕様】 アイテムの一部だけ更新する場合でも、1アイテムのサイズ分のWCUを消費する
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 19 DynamoDB設計
その2 その1を踏まえ、見直したDynamoDBの構造は以下の通り Primary Key Data-Item Attributes… Partition Key Sort Key Data 機器ID 運転データ項目名 100 項目1 項目1の運転データ(JSON形式) 100 ・・・ ・・・ 100 項目N 項目Nの運転データ(JSON形式) 1機器Nアイテムとして運転データを格納する これにより1アイテムあたりのサイズは1kB以下となり、1項目 だけ送られてきた場合はWCUを1だけ消費する、ということに なりWCU消費量を改善できた。 この設計にも問題があった…
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 20 DynamoDB設計
その2 1回の運転データ取り出しで数十機器の運転データを取り出す ため、数十機器×N項目=数千アイテムをDynamoDBから取り 出す必要あり 運転データ取り出しのLambda処理時間がかかりすぎる 【DynamoDBのAPI仕様】 ・Queryで指定できるPrimaryキーの数はひとつ ・BatchGetItemで取得できるアイテム数は最大100 ⇒いずれを利用しても、数十回APIを実行する必要があり、処理時間がかかる Primary Key Data-Item Attributes… Partition Key Sort Key Data 機器ID 運転データ項目名 100 項目1 項目1の運転データ(JSON形式) 100 ・・・ ・・・ 100 項目N 項目Nの運転データ(JSON形式)
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 21 DynamoDB設計
その3 その2を踏まえ、見直したDynamoDBの構造は以下の通り Partition Keyを建物IDとし、1機器Nアイテムとして運転 データを格納する 建物IDをキーとしてQueryを実行することで、1回のAPI呼び 出しで建物内の全機器の運転データを取得 (項目ごとに書き込めるのでWCUも抑えたまま) Primary Key Data-Item Attributes… Partition Key Sort Key Data 建物ID 機器ID_運転データ項目名 A 100_項目1 項目1の運転データ(JSON形式) A ・・・ ・・・ A 100_項目N 項目Nの運転データ(JSON形式)
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 22 DynamoDB設計
まとめ • データ書き込み側(少しずつ書き込みたい)と、データ読み 込み側(まとめて取り出したい)のユースケースが相反する ケースにおいて、両者のバランスを取る最適なデータ構造を 探ることができた • DynamoDBのデータ構造(キー設計)は、クラウドランニ ングコストの観点で非常に重要。アクセス頻度が高いデータ はキー設計を適切に行わないと、非常にコストがかかる! • DynamoDBの場合、書き込みにかかる料金(WCUの料金) は、読み込みにかかる料金(RCUの料金)の10倍以上なので、 特に、⾼頻度でデータ書き込みを行う箇所のキー設計が重要 (IoTシステムにおいて、機器のデータを書き込む箇所がま さに該当する)
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 余談
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. 24 開発中に失敗した事例
皆様、お気をつけください 事例1 インスタンス停止し忘れ 高負荷をかけてシステムを評価するテストを実施する際に、負 荷ツールを動かすために、かなりハイスペックなEC2を2台使 用。テスト自体は数時間で完了したが、テスト終了後にインス タンスを停止し忘れ、1週間ほど放置。〇〇万円が課金されて しまった。 (負荷ツールも従量課金制のサーバーレスで動かせば!) 事例2 大量デバッグログ 高負荷をかけてシステムを評価するテストを実施する際に、ロ グレベルをDEBUGのままテストを実行。CloudWatch Logsに 数百億件のログを送信し、〇〇万円が課金されてしまった。 (CloudWatch Logs高い…)
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved. Daikin Global
Platformに興味を持っていただいた方! AWSをやりたい方! 一緒にDaikin Global Platformを作りませんか? ご応募、お待ちしております! (採用HP) http://www.daikin.co.jp/recruit/career/ ご清聴ありがとうございました
Copyright: ©2019 DAIKIN INDUSTRIES, LTD., All Rights Reserved.