Weitere ähnliche Inhalte Ähnlich wie AWSマネージドサービスをフル活用したヘルスケアIoTプラットフォーム (20) Kürzlich hochgeladen (11) AWSマネージドサービスをフル活用したヘルスケアIoTプラットフォーム2. 自己紹介
2
武田 大輝(たけだ ひろき)
* 2012/04 新卒入社
* Technology Inovation Group
* サーバサイドエンジニア 4年
* インフラ(主にAWS)エンジニア 1年
Twitter
はじめました
@datake914
Qiitaも
書いてます
@datake914
13. Big Data Pipeline
13
Collect STORE
PROCESS
ANALYZE
CONSUME
Amazon
S3
Amazon
DynamoDB
Amazon
RDS
AWS IoT
Amazon
SQS
Amazon
Machine Learning
Amazon
EMR
AWS
Lambda
Amazon
Redshift
Amazon Kinesis
Analytics
Amazon
QuickSight
Amazon
Glacier
AWS
Data Pipeline
Amazon Kinesis
Streams
Amazon Kinesis
Firehose
AWS
API Gateway
AWS
Import/Export Snowball
Amazon
ElastiCache
20. メッセージの複製, 分散, 再取得, 分散取得, 順序保証が求められる
• AWSマネージドならAmazon Kinesis Streams
• OSSならApache Kafkaが無難
プロダクトの選択肢として…
20
Self ManagedAWS Managed
Amazon
Kinesis Streams
Amazon
DynamoDB Stream
Amazon SQS
21. Kinesis vs Kafka - 基本機能
21
KinesisとKafkaの基本的な機能はほぼ同等
Enable Enable順序保証
Enable Enable複数配信
最大7日間 設定次第データ保持期間
Enable Enableシャーディング
3AZ Enableレプリケーション
全レプリカ書込後 選択可能Ack
Amazon
Kinesis Streams
Yes NoAWSマネージド
上限なし(~shards) 上限なし(~nodes)拡張性
22. Kinesis vs Kafka - スループット
リニアにスケールするためスループットはお金次第
• コストパフォーマンスの良し悪しは一概には言えない(後述)
• もろもろ小回りが利くのはKafka
Case1 : 1KB/msg × 10000msg/sec = 10MB/secをPUT
22
1stream, 10shard 3node(m4large × 3)
1topic, 3partition, 3replica, acks=all
$ bin/kafka-producer-perf-test.sh
--topic test
--num-records 10000000 ¥
--record-size 1024 --throughput 10000
--producer-props bootstrap.servers=<host>:9092 acks=all
10000000 records sent, 9996.893606 records/sec (9.74 MB/sec)
どちらも
(当然)捌ける
23. Kinesis vs Kafka - スループット
Case2: 0.1KB/msg × 100,000msg/sec = 10MB/secをPUT
Case3: 2MB/msg × 5msg/sec = 10MB/secをPUT
23
1000msg/shardの上限があるため、
1stream, 100shard必要
※KPLで集約を行うことでより少ないshardで対応可(後述)
1MB/shardの上限があるため、
1MBを超えるメッセージのPUTは不可
24. 運用・保守の負荷は (当前) Kinesisの方が低い
Kinesis vs Kafka - 運用・保守
24
N/A by yourselfリソース監視
CloudWatch連携 by yourself性能監視
UpdteShardCount API1発 by yourselfスケーリング
N/A by yourselfチューニング
N/A by yourselfバージョンアップ
N/A zookeeperフェイルオーバー
Amazon
Kinesis Streams
N/A by yourself死活監視
最低限ケアすべきは
スロットルエラーのみ
基本的には全て自前で
頑張る必要がある
25. Kinesis vs Kafka - コスト
条件次第で変わるので参考程度に…
• 1KB/msg, 1consumer/msg
• 1日あたりデータトラフィックはmsg/secの12時間分
• データ保持期間は24時間
• KafkaはKinesisと同等の可用性(3node, 3replica)を担保
25
$0.00
$250.00
$500.00
$750.00
$1,000.00
… put payload
… shard
… data transfer
… EBS volume
… EC2 computing (m4.large)
(msg/sec)2,0001,000 5,000 10,000 20,000
26. Kinesis vs Kafka - 結論
• Kinesisを採用
• スモールスタートという特性上、作りこみ不要かつ
初期のランニングコストが低いKinesisがマッチ
• 規模が拡大したときにKafkaへの移行も視野に入れる
• Kafkaも決してハマらないわけではない
26
28. HTTP APIサーバをどうするか
EC2インスタンス上に自前のAPIサーバを構築
• API Gatewayのサービス制限が懸念される
• エンドポイントは極力AWS依存度を低くしたい
• Kinesis Producer Libraryを利用したい (後述)
28
Yes NoAWSマネージド
HTTPS HTTP/HTTPSプロトコル
AWS IAM認証, APIキー認証,
カスタム認証(Lambda) 実装次第認証
1000rps 設定次第スループット
60 上限なしエンドポイント数
10MB 設定次第ペイロード上限
Amazon
API Gateway
API Server on
Amazon EC2
29. MQTT Brokerをどうするか
• メッセージのロストは許容前提
• 膨大なデバイス数を想定し、柔軟にスケール (アウト) したい
• SubscriberはKinesisにPUTするのみ
29
Broker Cluster Multi-Subscriber Kinesis
…
Publisher
同一トピックに
対する分散された
Subscriber
分散された
Broker Cluster
こんなイメージ…
30. MQTT Brokerをどうするか
• メッセージのロストは許容前提
• 膨大なデバイス数を想定し、柔軟にスケール (アウト) したい
• SubscriberはKinesisにPUTするのみ
30
Broker Cluster Multi-Subscriber Kinesis
…
Publisher
同一トピックに
対する分散された
Subscriber
分散された
Broker Cluster
こんなイメージ…
MQTTブローカーって
そもそもこんな気軽にスケールしない
31. MQTT Brokerをどうするか
• AWS IoTはスケールを前提としたアーキテクチャ
• QoS2非対応
• Retain非対応
• OSSだとVerneMQ, EMQあたりがクラスタ組めてよさそう
31
Self ManagedAWS Managed
AWS IoT
EMQ
ルールエンジンで
Kinesis連携までできるし
使えるんじゃね?
34. AWS IoTよさそうだけど…
34
• 結構お高い ($8/million msg)
• 1000msg/sでひと月運用するとPublishメッセージだけで$20736
• カスタム価格というものがあるらしいが…?
• ルールエンジンを利用するとKinesisへPUTするまでに
データの集約ができない
OSSも視野に入れて現在鋭意検証中
40. とにもかくにもまずは生データの格納
• 要件追加にも柔軟に対応できるよう限りなく生のデータ保持は必須
• 生データはAWS Lambdaを利用してAmazon S3に集約
• 容量制限なし
• 高可用性 (99.99%)
• 高耐久性 (99.999999999%)
• 低コスト
40
Amazon
S3
AWS
Lambda
Amazon Kinesis
Streams
S3が本基盤における
データレイクとなる
Kinesis Firehose
は利用しない (*1)
*1) 現時点では東京リージョンで利用できない、S3に格納するまでに加工処理ができない等の理由による。
指定件数でBatch取得 圧縮してPUT
1秒に複数回ポーリング
41. バッチ処理はS3 + EMR (Hadoop)
S3からデータをHDFSにコピーし処理
• あくまでEMRは処理エンジン(データを永続化しない)
• データ処理後にEMRクラスタをシャットダウンできる
• スポットインスタンスを活用できる
41
Amazon
S3
AWS
Lambda
Amazon Kinesis
Streams
Amazon
EMR
S3DistCp
42. リアルタイム処理は大きく2パターン
• 単一レコードに対する簡易な処理はAWS Lambda
• 複数レコードに対する高度な処理 (ウィンドウ集計など) はSpark
Streaming
42
AWS
Lambda
Amazon Kinesis
Streams
Amazon
EMR
指定件数でBatch取得
1秒に複数回ポーリング
Kinesis Client Libraryをラップした
Spark Streaming用のライブラリ (*1) により、指定間隔でポーリング
*1) http://spark.apache.org/docs/latest/streaming-kinesis-integration.html
44. ポイント① - データの重複を前提とする
Kinesis Streamsから連携されるデータは重複を前提として、
処理は冪等性を保証すべし
44
Amazon Kinesis
Streams
Producer
何らかのエラー時に
Producerがリトライを
行うことでメッセージが
重複する可能性がある
Producer側で重複を排除
(exactry onceを実現) するのは高コスト
AWS Lambda
Amazon EMR
Amazon EMR
メッセージに一意なIDを持たせるなどして
Consumer側で重複を排除できるように
ID: 123456
ID: 123456
48. ポイント - データストアは用途で使い分ける
48
Amazon S3
Amazon RDS
Amazon
DynamoDB
Amazon
ElastiCache
全ての生データを保持。
アプリケーションからの参照はない。
ユーザ情報などのマスタデータや
バッチ集計結果などを保持。
アプリケーションから参照・更新される。
ストリーム処理による分析結果や時系列データ
など大量・高頻度連携されるデータを保持。
アプリケーションから参照のみされる。
RDSのマスタデータをキャッシュ。
ストリーム処理におけるデータの
問い合わせに対して高速に応答する。
主用途
TB~PB
~GB
GB~TB
MB
データ
サイズ
コスト
低
高
アクセス
頻度
低
高
54. ポイント (再掲)
• データ収集層
• 連携頻度/データ種の増加に柔軟に対応できること
• AWSマネージドサービスは便利な反面、サービス制限や課金体系を考
慮して見極めること
• データ処理層
• データの重複を前提として、冪等性を担保すること
• 単一障害点は割り切り
• データストア層
• 中心となるデータストア(生データ保持)はS3一択
• データの特性に応じて「どう使い分けるか」が重要
54
58. リシャーディング - 実行方法
APIで実行 (※管理コンソール上からもできます)
58
$ aws kinesis split-shard --stream-name <stream-name> ¥
--shard-to-split <shard-id> --new-starting-hash-key <hashkey>
シャードID及び
分割位置となるハッシュキーを
指定する必要がある
• 従来の方式(分割)
$ aws kinesis merge-shards --stream-name <stream-name> ¥
--shard-to-merge <shard-id> --adjacent-shard-to-merge <shard-id>
結合対象のシャードIDを
指定する必要がある(*1)
• 従来の方式(結合)
$ aws kinesis update-shard-count --stream-name <stream-name> ¥
--target-shard-count <shard-count> --scaling-type UNIFORM_SCALING
シャード数の指定
だけで均等にリシャーディング
してくれる
• 新方式(分割・結合)
59. リシャーディング - 使い分け
• 新方式は便利な反面、制約が存在
• 1日2回まで…
• リシャード後のシャード数は1/2~2倍まで
• 1日1,2回の定期運用でリシャーディングを行う場合は新方式
• 柔軟にオートスケールさせたい場合などは従来の方式
59
60. オートスケール
CloudWatch + SNS + Lambdaで実現
AWS Lambda
Cloud Watch
Alerm
Amazon Kinesis
Streams
Amazon SNS
① Kinesisが発行するメトリクスを
アラームの条件として設定
② 閾値を超過した
場合にSNS通知
③ SNS通知をトリガーに
ラムダ関数を起動
④ Lambda関数により
リシャーディングを実行 & 閾値再設定
61. オートスケール - 閾値どうするか
例. ストリーム単位でシンプルに実施
利用するメトリクス: IncomingRecords
• ストリーム全体において5分に渡り、1秒あたりレコード数が総許容
レコードの80%を超える場合に総シャード数を2倍にする
• ストリーム全体において30分に渡り、1秒あたりレコード数が総許容
レコードの20%を下回る場合に総シャード数を1/2倍にする
62. オートスケール - 閾値どうするか
例. シャード単位で高度に実施 (※未検証)
利用するメトリクス: IncomingRecords (拡張シャードメトリクス)
• 特定シャードにおいて5分に渡り、1秒あたりレコード数が総許容
レコードの80%を超える場合に該当シャードを分割する
• 特定シャードにおいて30分に渡り、1秒あたりレコード数が総許容
レコードの20%を下回る場合に該当シャードを結合する
有料
結合対象のシャードを
どうするかなど色々考慮する
必要がある…はず
63. オートスケール - まとめ
• リシャーディングに必要な時間、流量の変動周期等を考慮して
適切に閾値を設定すべし
• 全シャードに均等にデータがPUTされるようパーティションキーを
設定することでシンプルなリシャーディングが可能に
• シャード数を増やす方はいいが、減らす方は慎重に
• 特にシャード単位で高度にスケールする場合はテスト重要
• 分割は自動、結合は運用という割り切りもあり
64. Kinesis Producer Library
• Kinesis StreamsのレコードPUTに特化した高度なライブラリ
• KPLはC++製、Java wrapperを通じて利用
• Linux, OS X, Windowsサポート (*1)
• 非同期的にレコードの集約・収集を行ってくれる
64
*1) 最新バージョンv0.12.3では未サポート
recordBrecordA
recordC recordD
recordC
recordB
recordD
recordA
KPL
recordBrecordA
recordC recordD
Kinesis Streams
複数レコードを
Kinesisの1レコードに
まとめる(集約)
複数レコードを
まとめてKinesisに
PUTする(収集)
2レコード
1リクエスト
で連携
65. Kinesis Producer Library - メリット
小さなレコードが大量連携される場合にコスト削減が可能
例. 0.25KB/msg × 10000msg/s = 2.44MB/secを捌く場合
• 通常 : 10shard, 10,000payload unit/s
• KPL利用 : 03shard, 100payload unit/s(25KBに集約)
65
約$650/月削減!!!
0
250
500
750
通常 KPL
(ドル)
レコードサイズが
小さければ小さいほど、
連携頻度が高ければ高いほど
効果あり
… put payload
… shard
66. Kinesis Producer Library - 注意点
• 集約・収集のためにレコードを内部でバッファリングするため、設定した
サイズ or 時間 or 数 (*1) に達するまで処理遅延が発生する可能性がある。
• 集約・収集のためにレコードを内部でバッファリングするため、
KPLが動作するEC2障害時などはメッセージがロストする可能性がある。
66
*1) RecordMaxBufferedTime, AggregationMaxCount, AggregationMaxSize, CollectionMaxCount, CollectionMaxSizeの設定値