これはなに jq コマンドをサーバサイドで動くようにすることで、jq をクラウドに昇華させることを目的としたキータドキュメントです。 さらに、クラウドコンピューティングの発展の到達点とも言える概念であるサーバレスアーキテクチャを取り込み、極限までクラウド昇華させたサーバサイド・サーバレス・jqを提案します。 jq について jq とは JSON をいい感じにパースしたり加工したりしてくれる素晴らしいコマンドです。 こんな感じのコマンドです。 $ echo '{"items":[{"item_id":1,"name":"すてきな雑貨","price":2500},{"item_id":2,"name":"格好いい置物","price":4500}]}' \ | jq . { "items": [ { "item_id": 1, "name": "すてきな雑貨", "price": 2500
こんにちは、技術開発グループの松原です。 AWSでログを処理するときは以下の方法が考えられるかと思います。 CloudWatch LogsのデータをAmazon Elasticsearch Serviceにストリーミングする FluentdやLogstashを使ってログの収集、処理をする Fluentdを利用する場合はAggregatorがあった方が、リトライやバッファリング、タグを追加したいなどの場合にAggregatorの設定を変更するだけですむなど利点が多いです。 ただし、サーバの台数が少ない場合はAggregatorを構築するほどでも無いと思う場合もあるかと思います。 そこで、今回は以下のような構成を試してみます*1。 ここではログの格納先をS3にしていますが、Kinesisに置き換えても同様に実現可能かと思います。 Fluentdの設定 Fluentdで集めたログデータをS3に送
AWS LambdaではLambdaファンクションに指定したイベントソースで発生したイベントに応じてファンクションがInvokeされるのですが、イベントが発生したはずなのにファンクションが思ったようにInvokeされない！と悩むときがあるかと思います。そんなときイベントソースがイベントを送ったかどうか確認したくなるのですが、実はこれはユーザ側では難しかったりします。 というわけでそういった場合はサポートに問い合わせて調査をしてもらうわけですがイベントソースがS3の場合にサポートへ問い合わせる上で最低限必要となるのが2種類のリクエストIDです。気をつけなければいけないのはこれらは通常のアクセスログ等には記録されていないのでユーザ側で取得・記録する必要があるということです。また、状況に応じて必要になる情報は異なるので、これらだけで必ずしも原因が特定可能というわけではないこともお伝えしておきます
これは何でしょう AWS Lambda におけるチェーン呼び出しするような一連のLambda関数を動的にデプロイすることで単一のコードで書けるライブラリを書いてみましたという記事です。名付けて"Mizukiri"。 コードなど GitHub: https://github.com/takeshinoda/mizukiri npm: https://www.npmjs.com/package/mizukiri デモアプリ: https://github.com/takeshinoda/mizukiri-demo ことば ここでは AWS Lambda 上にデプロイされるアプリケーションのことをLambda関数と呼びます。AWSの公式ドキュメントでもそのように呼称されています。別の意味に解釈されそうな言葉ですがしょうが無いです。 概要 Mizukiriはnpmパッケージで、コンセプト実証のコー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
