S3のコスト削減に成功した話 〜カギはバッチウィンドウ〜｜ハンズラボ株式会社
こんにちは！POSグループのhktです。 こちらの記事は、「S3のコスト削減に失敗した話」の後編になります。 もしまだ前編をご覧になっていない方は、ぜひ読んでみてください。 さて、前編では、S3のコストを調査したところ、最も費用がかかっているのがPutObjectであることが判明しました。 今回は、S3のコストを削減するために、PutObjectの実行回数を減らすことはできないか検討しました。 PutObjectの実行回数を減らしたい POSグループが運用するAWSアカウントでは、ログデータをS3に保存するために、Kinesis Data StreamsをトリガーとするLambda関数が稼働しています。 具体的には、以下のような構成になっています。HandsPOSアプリからKinesis Data Streamsにログデータが送信され、Kinesis Data StreamsからLambd
Spark 2.0 on EMR で Structured Streaming をやってみた
“Distributed computing (Apache Hadoop, Spark, …) Advent Calendar 2016” の 12/19 担当ということで、Spark 2.0 on EMR で Spark Streaming と Structured Streaming をやってみた結果を書きます。 この記事でやること この記事では Spark 2.0 で、現在アルファ版の Structured Streaming をやってみます。 Structured Streaming とは、Spark SQL エンジンで実現されたストリーム処理の仕組みです。 従来型の Spark Streaming は RDD を DStream とよばれる Spark Streaming 特有のモデルを導入して扱うのに対して、Structured Streaming では Spark SQL
Lambda Streaming responseで、S3に置いた大きなJSONデータを編集しながらレスポンスしたらどれくらい速いのか調べてみた | DevelopersIO
timestamp はエポックミリ秒、value は気温を模したランダムな数値です。 deviceId には"001"の固定値を仮り置きしています。 実験の内容 3 種類の lambda 関数をそれぞれメモリサイズ 128MB, 256MB, 512MB で実行し、レスポンス完了までにかかる時間を調べました。 すべての関数とも、取得したデータを 1 ヶ月分だけに filter して返します。 1. s3 のデータを返す（stream） import { Writable, Readable } from "node:stream"; import { Handler } from "aws-lambda"; import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3"; import { chain } from "stre
Glue Schema Registry の導入を断念した話
業務で AWS Glue Schema Registry を使おうとしたけど、やっぱりやめたというお話。 Glue Schema Registry#What’s Schema Registry?#AWS Glue Schema Registry は2020年に発表された AWS の機能だ。 Control the evolution of data streams using the AWS Glue Schema Registry一方、私が最初に schema registry 的なものを見たのは Confluent の例。 Schema Registry の概要 - ConfluentAWS の Glue Schema Registry はこれより後のリリースであり、同等のものの AWS マネージド版といったところだろうか。 schema registry で何ができるかは Confl
AWS DMS と Snowpipe を活用した Snowflake 用リアルタイムデータパイプラインの構築
(画像は Snowflake 公式 Web サイトのものを流用) 概要 データエンジニアとして働いていると RDB 上での変更をリアルタイムで近い形でデータウェアハウスに転送し、即座にデータ分析に利用できるようにしたいというニーズについて相談を受ける機会があります。 筆者は、RDB からデータウェアハウスの間のリアルタイムデータパイプライン部分を OSS 中心とクラウドサービス中心の 2 つの構成で構築した経験があります。その際の経験を踏まえて、両者の簡単な比較について紹介します。 （前職）OSS 中心のデータパイプライン RDB・・・AWS RDS Aurora (PostgreSQL) BigQuery データパイプライン・・・Kafka、Debezium コンテナオーケストレーション・・・データパイプラインを AWS EKS 上 k8s クラスタにデプロイ （現職）クラウドサービス中
Amazon Quantum Ledger Database (QLDB) 実運用のための検証
1. 概要Amazon Quantum Ledger Database（QLDB）は、「データ整合性」「完全性」「検証可能性」が不可欠なSoR（System of Record）アプリケーションに相性の良い台帳管理専用データベースです。弊社が取り組んでいるブロックチェーン文脈においても、上記の３要素については金融文脈だけではなく、物流やサプライチェーンにおけるトレーサビリティにおいて重要であると考えています。 図1. QLDB概要図2. QLDBとブロックチェーンの違い上記の３要素を満たすような分散台帳を選ぶ際に、ethereum, Hyperledger Fabric, Corda, miyabiといったブロックチェーンを利用することが真っ先に考えられますが、その中でどのような特徴やユースケースがあるのかを検討しています。 QLDBの特徴としては下記が挙げられます。QLDBは分散台帳でも
Kinesis Data Analytics の「時間」と「ウィンドウクエリパターン」について理解する | DevelopersIO
先日より、Kinesis Data Analytics について学習をはじめています。 今回は、Kinesis Data Analytics のアプリケーション内データストリームで時系列データを扱うにあたって重要な「時間」と「ウィンドウクエリパターン」についての理解を深めていきます。 目次 アプリケーション内データストリームにおける「時間」 どの「時間」を使って分析する？ 2 ウィンドウ戦略 3つのウィンドウクエリ・パターン タンブリングウィンドウ Stagger Windows（ずらしウィンドウ） スライディングウィンドウ まとめ アプリケーション内データストリームにおける「時間」 アプリケーション内データストリームでは、以下 3 タイプの時間に分類されます。正しく分析結果を得るためには、それぞれの時間についての意味を正しく理解しましょう。 引用元：Amazon Kinesis Anal
ストリーミングズンドコをKinesis Data Analyticsでキヨシ判定してみた | DevelopersIO
ズンドコキヨシ(プログラム)とは？ Javaの講義、試験が「自作関数を作り記述しなさい」って問題だったから 「ズン」「ドコ」のいずれかをランダムで出力し続けて「ズン」「ズン」「ズン」「ズン」「ドコ」の配列が出たら「キ・ヨ・シ！」って出力した後終了って関数作ったら満点で単位貰ってた — てくも (@kumiromilk) March 9, 2016 今回はこのズンドコキヨシを、Kinesis Data AnalyticsのSQL Applicationsでやってみました。 入力はKinesis Data Streamsに別のプログラムとして送っており、キヨシ判定後に終了しないため、もしかすると純粋ズンドコキヨシではないのかもしれませんが、あらかじめご承知おきください。 What if... 世界は変化し、あらゆるプログラムがズンドコを送るようになりました。 これに対応するため、あなたは多数の
Amazon Kinesis Data Analytics が東京リージョンで利用可能になりました | Amazon Web Services
Amazon Web Services ブログ Amazon Kinesis Data Analytics が東京リージョンで利用可能になりました 2019年5月、Amazon Kinesis Data Analytics が東京リージョンで利用できるようになりました。 これまで、東京リージョンにあるデータソース（Amazon Kinesis Data Streams または Amazon Kinesis Data Firehose）を Kinesis Data Analytics に接続するためには、リージョンを跨いで接続する必要がありました。Kinesis Data Analytics が東京リージョンで利用可能となったことにより、日本国内にあるデータソースと接続しやすくなり、ストリームデータ分析の環境をよりシンプルに構築できるようになりました。 Kinesis Data Analyt
AWS で実現した Mackerel 時系列データ1分粒度長期保存の裏側 / Mackerel Meetup #11 Tokyo
2018/02/05 https://mackerelio.connpass.com/event/76678/
最新のログもすぐクエリできる速くて容量無限の最強ログ基盤をRedshift Spectrumで作る - クックパッド開発者ブログ
こんにちは。去年の今頃は Rust を書いていました。 インフラストラクチャー部データ基盤グループの id:koba789 です。 背景 クックパッドではデータ基盤の DBMS として Amazon Redshift を利用しています。 既存のデータ基盤について詳しいことは クックパッドのデータ活用基盤 - クックパッド開発者ブログ を参照してください。 今まで、ログは数時間に1度、定期実行ジョブで Redshift 内のテーブルにロードしていました。 ロードジョブの実行間隔が "数時間" と長めなのは、Redshift のトランザクションのコミットが遅いためです。 クックパッドでは数百ものログテーブルがあるため、仮に1分おきにすべてを取り込もうとすると秒間数回以上のコミットを行わなければなりません。 このような頻繁なコミットは Redshift 全体のパフォーマンスを悪化させてしまいます
Amazon Kinesis Data Firehose で Apache Parquet または ORC フォーマットのデータをリアルタイムでストリーミング
Amazon Kinesis Data Firehose で Apache Parquet と Apache ORC フォーマットが追加サポートされるようになりました。これにより、コスト効率の良いストレージと分析のため Amazon S3 に対しリアルタイムのデータをストリーミングできます。 Apache Parquet と Apache ORC は柱状のデータフォーマットで、データをより効果的に、コスト効率良く保存し、クエリを実行できるようになります。これからは、ご使用の Kinesis Data Firehose のストリーム配信を構成し、S3 バケットにデータを配信する前に、Parquet または ORC フォーマットに自動変換するよう設定できます。コーディングの必要はなく、Amazon Athena および Amazon Redshift Spectrum を使用することで S3
DynamoDB StreamをトリガーにしてLambdaを実行する - Qiita
DynamoDB Streamとは DynamoDB Streamは、DynamoDBに対する項目の追加、変更、削除をイベントとして検出できる機能です。DynamoDB Streamを使うことで、項目が追加・変更された時にプッシュ通知を飛ばしたりといった実装が可能になります。今回は、そのイベントをLambdaで受け取ってみたいと思います。 参考：DynamoDB ストリーム を使用したテーブルアクティビティのキャプチャ DynamoDB側でStreamを有効化 先んず、DynamoDBの概要のタブにある「ストリームの管理」から、Streamを有効化します。新旧イメージを選択すると、項目の変更時にLambdaが項目のBefore&Afterの両方を受け取ることができます。 DynamoDB Streamを受け取るためにLambdaに必要な権限 LambdaがDynamoDB Streamを受
スケーラブル tail -f | grep on AWS - KAYAC engineers' blog
こんにちは。組長こと @fujiwara (id:sfujiwara) です。 早速ですが皆さん、ログは見ていますか? 当然見ていますよね。tail -f で追いかけるとか大好きですよね。という前提で話を進めましょう。 この記事は Tech KAYAC Advent Calendar 2016 の24日目の記事です。 TL;DR 多種多様なホストから発生するログの末尾を tail -f で追いかけたい fluentd + ローカルファイルで行うのはちょっと面倒 Amazon Kinesis + Lambda を使ってスケーラブルな仕組みを考えてみた kinesis-tailf というツールも作った 既存の仕組みと問題点 techblog.kayac.com 弊社の Lobi とソーシャルゲームでは、この記事で紹介されたような Fluentd を活用したログ集約の仕組みを整備しています。この
Kinesis Client Libraryを実案件でつかってみて - Qiita
Kinesis Client Libraryをつかってみて Kinesis Client Library(KCL)って？ Amazon Kinesisはストリーム処理を行うことができるサービスで、 Kinesis StreamはMessage Queueのような働きをします。 Kinesis Client Libraryは、Amazon Kinesisを利用する上で気を付けなければいけない部分を薄くラップしてくれる便利なライブラリです。 Checkpointを利用したデータのトランザクション処理、再送処理や、 リシャーディングにあわせた処理の並列化などをサポートしてくれます。 詳細はこちら ⇒ Kinesis Client Library 実案件で感じたKinesisを使うメリット データを取得するConsumer側のペースにデータの流入を調整できるため、バックエンドの負荷を調節しやすくな
Kinesis Firehose のデータ変換を Rust でやってみて速度向上が見込めた話 - ソモサン
概要 Rust コードを Lambda 上で動かせたーと喜んだんですが、活用どころあるんだろうかと考えてみて検証してみました。 結果として Python 比較で1秒当たりで 15 倍ほど多く処理できました。 以下でつらつらと書いていってます。 前提: Lambda の環境について Python比で起動時間に差がない Rust はそこそこバイナリサイズが大きくなります。 前回書いた Kinesis から S3 へ保存するコードも、Lambda のコンソール上で 1MB という数字になってました。 ライブラリ結構使っているとはいえ、やっぱりでかいです。 当然デバッグ情報の削除やならんやらで小さくはなるのですが、 Python なら500 B 程度。 結果として初期の起動速度の差がでてるのかなーと考えてます。 ので、Rust を使うなら起動してすぐ結果をかえす場面でなく、そこそこじっくりと処理す
Deep Dive of Flink & Spark on Amazon EMR - February Online Tech Talks
Organizations are demanding increasingly faster tools to process and analyze data in real time. Apache Spark and Apache Flink have emerged as popular, open source frameworks to address these requirements. In this tech talk, we provide an overview of these technologies and the differences between them. We show how you can deploy Apache Spark and Flink on AWS to address common big data use cases suc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Serverless Analytics with Amazon Kinesis and AWS Lambda
Analyze a Time Series in Real Time with AWS Lambda, Amazon Kinesis and Amazon DynamoDB Streams | Amazon Web Services
Amazon kinesisで広がるリアルタイムデータプロセッシングとその未来