Kinesis Producer Library(KPL)とfluentdとLambdaを連携してKinesisのスループットを上げる | DevelopersIO
Kinesis Producer Library(KPL)とfluentdとLambdaを連携してKinesisのスループットを上げる 2016/06/03(金)のAWS Summit Tokyo 2016でクックパッド株式会社の星さんが「秒間数万のログをいい感じにするアーキテクチャ」という発表をされました。 クックパッドのログ収集基盤が Fluentd や Amazon Kinesis Streams や Redshift を活用していい感じするアーキテクチャが参考になった方は非常に多いと思います(あの規模のサービスに関わるかはともかく)。 発表の中でKinesis Producer Library(以下 KPL)を使ってログ数多すぎ問題を解決したことが語られていました。 個人的には、Kinesis Streams のシャード数を増やせばどうにかなるレベルのサービスしか担当したことがない
【AWS】SQSキューの前には難しいこと考えずにSNSトピックを挟むと良いよ、という話 | DevelopersIO
よく訓練されたアップル信者、都元です。SQSはみなさん使われていますでしょうか。複数のコンポーネント間の疎結合を保ち、バッチ処理等の冗長性・拡張性を確保するために必要不可欠なサービスです。 SQSの活用イメージにつきましては、AWSでジョブWorkerを構成するベストプラクティスのSQSの巻やBeanstalk worker tierの巻をご覧いただくと良いと思います。 さて。SQSを使うぞ、ということになった場合。メッセージを投げる側（＝プロデューサ）と、メッセージを受け取る側（＝コンシューマ）が必要です。どこかから持ってくる（実装済みの既成品を探してくる）か、もしくは自分自身で実装するわけです。 もちろん、プロデューサはSQSのインターフェイス（API）を理解し（依存し）ていなければなりません。要するに、キューにメッセージを投入する方法を知っており、それを使ってメッセージを投げるような
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
