タグ

awsとkinesisに関するi_matsuiのブックマーク (6)

  • f290ed5d4e305508dc63

    注記: re:Invent2019でLambda streamアクセス、エラーハンドルの仕方にupdateが入っております。 起動についてはこちら、エラーハンドルはこちらなど、update情報が落ち着いた後、こちらの記事をupdateしようと思いますので、updateが入っている前提で読んでいただければと思います。 はじめに AWS Lambdaの必要な数を設計するときに、同期/非同期/streamの呼び出しパターンがあるのは、ご存知でしょうか?公式情報はこちら 同期型はイベント駆動型というと理解が早いでしょうか? API Gateway/S3/CloudTrailをトリガーにした場合の呼び出し方法です。 stream型データ= kinesis streams/DynamoDB Streamsをトリガーにした場合です。 同期型の場合、利用量が増えてくるとAWS Lambdaの同時起動数を増

    f290ed5d4e305508dc63
  • 【Kinesis & Lambda】 サービスを使ったビッグデータ検証で苦労した話 | Casley Deep Innovations株式会社 技術ブログ

    こんにちは。 キャスレーコンサルティングの 鈴木 和翔 です。 今回は、現場業務でビッグデータ負荷検証を 「KinesisDataStream & Lambda」 にて検証した際に洗い出された 課題点とそれに対して行った対策案等を紹介して行こうと思います。 負荷条件 今検証での主な負荷条件は以下となります。 ・1レコード(1リクエスト容量) 150KB 程 ・求めるスループット 4000TPS 達成 つまり、どういう流量になるかというと、 1秒間 150KB * 4000(TPS) = 約586MB 1分間 586MB * 60(秒) = 約34GB 1時間 34GB * 60(分) = 約2040GB 1時間に 約2040GBものデータが流れる事となります! (間違えて自分のアカウントで検証すると一気に破産しますね。。) アーキテクチャ 今検証でのアーキテクチャーの紹介です。 「Kine

  • [詳説] Kinesis Client Library for Java によるコンシューマアプリケーションの実装

    はじめに Kinesis Client Library(以下、KCL) は、AWS Kinesis Data Stream に流れるデータ(レコード)を受信して処理を行うコンシューマアプリケーションを実装するためのAWS謹製のライブラリです。 Kinesisのレコードを処理するには、 Kinesisストリームからレコードを取得して処理するアプリケーション。EC2などの上で常駐させます。 Kinesisストリームをイベントソースとする Lambda 関数。 のいずれかの方法がありますが、KCL は前者の場合に使用します。 KCL はKinesisストリームからレコードを取得し、レコードプロセッサ と呼ばれるレコードを処理するためのハンドラを呼び出します。 アプリケーションの開発者はこの レコードプロセッサ に処理を実装するだけで良く、レコードの取得、どのレコードまで処理したかの状態、Kine

    [詳説] Kinesis Client Library for Java によるコンシューマアプリケーションの実装
  • Amazon Kinesis編~KCL for Pythonを使ってみる01~

    前回は『Amazon ECS編~ECSを使ってみる03~』と題して、Amazon ECSでコンテナの入れ替えを試してみました。 今回は『Amazon Kinesis編~KCL for Pythonを使ってみる01~』と題して、Kinesis Client Library for Pythonを試してみたいと思います。 Kinesis Client Library for Pythonとは Amazonから提供されているKinesis Client Library(KCL) のPython版です。 Amazon Kinesisからのデータ取得、ロードバランシングや可用性を高める機能などは、KCL for Javaを利用している構造となっており、その後の処理をPythonで記述する事が可能です。 Amazon KCL for Python 1.環境の準備 KCLで使う環境を準備しておきます。

  • AWS Kinesis Stream を大規模データで検証してわかったことの事例紹介

    10分間で数億件を超えるIoT関連のデータをストリーム処理するためのPoC(概念実証)をする機会がありました。そこで経験をしてハマったことなど一部事例として紹介します。 検証の概要 まずは、何のために検証しようとしたかというと... IoT機器からKinesis Streamを通して大量のメッセージを受け取り、分散処理で関連付け処理を検証します。 実証検証の目的としては アーキテクチャ構成の妥当性を検証し コスト軽減のポイントを把握 運用に向けた課題を洗い出す としました。 データと要件の特性 今回の検証用データは自前で生成し投入する必要があり、結構なデータ量となります。 トラフィック量 およそ数十万件/秒(数億件/10分) 時間帯によってバースト(スパイク)が存在する メッセージの関連付け処理を行うが、いつ終点メッセージが届くかわからない。 数分後には処理結果を利用したいのでバッチでは実

    AWS Kinesis Stream を大規模データで検証してわかったことの事例紹介
  • ストリームデータ処理サービスAmazon Kinesisについて調べた結果 - 夢とガラクタの集積場

    こんにちは。 最近ストリームデータ処理サービスであるAmazon Kinesisのドキュメントを読んだり、 クライアントコードのソースを読んだり、実際の小さいアプリケーションを作ったりしたのですが、 その際にわかったことをとりあえずまとめておこうと思います。 1.Amazon Kinesisとは?(http://aws.amazon.com/jp/kinesis/) ・Amazon Kinesis は、大規模なストリーミングデータをリアルタイムで処理する完全マネージド型サービス ・大容量のストリームデータを受信し、提供することができる 2.Kinesisの構造(http://docs.aws.amazon.com/kinesis/latest/dev/introduction.html) ・Kinesisの実態は「大規模でスケール可能、メッセージが一定時間保存されるPubSub型キュー」

    ストリームデータ処理サービスAmazon Kinesisについて調べた結果 - 夢とガラクタの集積場
  • 1