8月5日(土)にbuilderscon tokyo 2017で「ここが辛いよサーバーレス。だが私は乗り越えた」というタイトルで発表してきました。運営の方々、本当にありがとうございました！ 簡単に、発表と質疑応答の補足をしたいと思います。 発表で伝えたかったことbuildersconは特定の言語や技術に特化したイベントではありません。「Lambdaの話」とか「AWSの話」とかはいっぱい話されているので、なるべくそこに限定されない「サーバーレスの話」をしたいなと思って発表内容を詰めていきました。 僕が発表で一番伝えたかったのは２つです。 ・サーバーレスは「クラウドの技術」ではなく、サーバーレスのライフサイクルは自分で作れる ・マネージドサービスは「落ちる」かもしれないので、備えるべき このうち２つめは、質疑応答でも出た話につながるので、あとで説明します。 サーバーレスに関して僕が感じているのは
10分間で数億件を超えるIoT関連のデータをストリーム処理するためのPoC（概念実証）をする機会がありました。そこで経験をしてハマったことなど一部事例として紹介します。 検証の概要 まずは、何のために検証しようとしたかというと... IoT機器からKinesis Streamを通して大量のメッセージを受け取り、分散処理で関連付け処理を検証します。 実証検証の目的としては アーキテクチャ構成の妥当性を検証し コスト軽減のポイントを把握 運用に向けた課題を洗い出す としました。 データと要件の特性 今回の検証用データは自前で生成し投入する必要があり、結構なデータ量となります。 トラフィック量 およそ数十万件/秒（数億件/10分） 時間帯によってバースト（スパイク）が存在する メッセージの関連付け処理を行うが、いつ終点メッセージが届くかわからない。 数分後には処理結果を利用したいのでバッチでは実
コンプライアンスや情報セキュリティの観点から、データの暗号化が求められるケースは多々あります。 S3やRDSでは以前から保存時のデータ暗号化(encryption at rest)を提供してきました。 この度、KinesisストリームもKMSと連携したサーバーサイド暗号に対応したため、早速触ってみました。 Kinesisストリームの暗号化の方針 Kinesisストリームの暗号化は大きく以下の2方針があります。 サーバーサイド暗号 : Kinesisストリームがストレージに保存・取り出すタイミングで暗号・復号 クライアント暗号 : Producerが暗号化したデータをKinesisストリームにPut。ConsumerがGetしたデータを復号 今回紹介する機能は前者のサーバーサイド暗号です。 後者のクライアント暗号については、次のブログを参考にして下さい。 Encrypt and Decryp
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
