サーバレス連載 の第1弾です。 はじめにこんにちは、TIG/DXチームの栗田です。AWSのLambdaに代表されるサーバレスアプリは実行時のみ稼働するため、サーバー稼働によるあらゆるコストから解放され、システム開発の工数を減らすことができます。例えば何らかのAPIを提供する場合でも、API GatewayとLambdaを組み合わせることで提供可能です。 一方で、サーバーレスアプリを開発するとき、ローカルでのテストが課題となります。例えばLambda + DynamoDBであれば、先の連載の手法を参考に、テストコードを書くことで解決します。一方で… API GatewayからLambdaの着火もテストした上でDynamoDBまで書き込ませたい なんならAPI Gaweway自体もLambdaで叩きたい となると、少々ハードルがあがります。この問題を解決してくれるのが、AWS Serverle

photo credit: Violet electric lightning versus turquoise storm - 09072012 via photopin (license) JavaScript（Node.js）で記述した AWS Lambda から AWS-SDK を使って DynamoDBのテーブルをQueryするサンプルコードをご紹介。 ところでAWSのAPIのリファレンスって検索しにくいですよねえ。 Lambdaがいろんな言語に対応しているため、REST APIと各言語向けの説明が別れていてチュートリアルも検索結果にたくさん出てきます。 ※ 本記事ではDynamoDBのQueryするときのパラメータを説明します。 関連する記事として、検索条件を入力してQueryパラメータを生成するWebアプリは以下になります。合わせて参照してみてください。 takamints.

はじめに AWSでサーバレスの開発をするにはSAMを使うという記事や話を聞いたことがある人は多いと思います。じゃあ、自分もSAMでやってみようと思ってやってはみたものの、SAMのテンプレートが書けない！って挫折した人が少なからずいると思います。私もその一人でした。おそらく、そのような人は、AWS CloudFormation のテンプレートを書いたことがない人だと思います。 実は、SAMのテンプレートは、CloudFormationテンプレートの拡張です。AWS SAM Template Basicsに、このように書かれています。 AWS SAM templates are an extension of AWS CloudFormation templates. That is, any resource that you can declare in an AWS CloudForma

Kinesisを使うと、例えばデータファイルを行毎にストリームとして流すことが可能です。 またKinesisをLambdaトリガーとして使うことで、後続処理をLambdaで作ることができます。 アップロード テストとして、以下のLambdaFunctionを作成し、10,000件のデータファイルを流してみました。 1行あたりのデータ量は、平均で2KiB程度です。 Lambda Function import boto3 import urllib.parse s3 = boto3.resource('s3', aws_access_key_id='XXXXXXXXXX', aws_secret_access_key='XXXXXXXXXXXXXXXXXXXXXXXXX', region_name='ap-northeast-1' ) kinesis = boto3.client('kine

1 はじめに CX事業本部の平内（SIN）です。 処理ごとに蓄積される「一覧（ログ）ファイルを、リアルタイムにS3上に作成する」というニーズに対して、昨日、下記のようなブログを書きました。 これに対して、社内から、このような要件なら、「FIFOなSQSより、KinesisでSequenceで管理した方がLambdaも入れやすいし使い勝手は良さそうな気がします。」という貴重なアドバイスを頂いたので、やってみました。 注意：今回も、S3の「結果整合性」の制約下で完全な「排他制御」が出来たわけではありませんので・・・「それでも！」という方は、読み進めて頂ければ嬉しいです。 2 Kinesis Data Streams Kinesis Data Streamsを log-sample-stream という名前で作成しました。 ストリームを処理するタスクの同時実行を制限するために、シャードを1に設定

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 のシャード数を増やせばどうにかなるレベルのサービスしか担当したことがない

こんにちは。 最近ストリームデータ処理サービスである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型キュー」

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

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

はじめに 普段からWebアプリケーションにログイン機能を実装する際、バックエンドにAmazonCognitoを利用してきました。 Cognitoはログイン認証をサーバレスに実現してくれるマネージドなサービスです。開発者はログインユーザの情報を管理する必要が(ほとんど)ありません。 またAWSのリソースへのアクセス権限を一時的に発行することもできるので、ログイン後のトークンを利用して、アプリケーションからAWSの各リソースを利用することができます。 今回はそんなCognitoの外部IDプロバイダ認証を利用してログインし、トークンを取得するまでの流れをGoogleとFacebookでやっていこうと思います。 Cognitoの準備 Cognitoのデプロイ AmplifyCLIを利用してサクッと作っていきます。フロントはVue.jsを使っています。 この記事を参考にしていただければ、Cognit

おまけ 今回調査に使ったシェルスクリプト載せておきます。 権限毎にバケット何個も作って、オブジェクトも作って、アクセスしてみて、終わったら削除してという感じのものです。 #!/bin/bash UNIQ=$(date +'%Y%m%d%I%M%S') alias aws='aws --region ap-northeast-1' BUCKET_PREFIX=akeri-acl-test-$UNIQ- TARGET_PRINCIPAL="arn:aws:iam::123456789012:user/s3acltest" TARGET_MAIL="example@example.com" # create Bucket Policy Document UPLOADFILE=akeridayo.txt IAM_USERNAME=s3acltest echo "akeridayo" > $UPLO

AWSでのNAT接続を実現する方法を備忘を兼ねて記載。 NATインスタンス編はこちら NAT構成の必要性 簡単にいうと、 インターネットから接続される必要のないインスタンスについて、 インターネットからの接続を遮断しつつ、 自身はインターネットに接続を出来るようにするため。 外部から接続される危険性を減らすことと、 ライブラリの取得などで必要になる外部への接続の両立が可能となる。 参考 シナリオ 2: パブリックサブネットとプライベートサブネットを持つ VPC（NAT） http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Scenario2.html NATゲートウェイ http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-nat-gatew

はじめに セキュアな構成とは WebサーバやDBサーバを直接インターネットに公開しない。 パブリックとプライベートでサブネットを分割する。 パブリック・プライベート共に、特定のポートのみインバウンドを受け付ける。 プライベートサブネットは特定のサブネットからのみインバウンドを受け付ける。 踏み台サーバは必要な時のみ存在（起動）している。 今回の想定 試しに構築するだけなので、インスタンスは最小サイズを使用する。 おおまかな手順 リージョンの変更 VPCの構築 パブリックサブネットの構築 サブネットの構築 インターネットゲートウェイの構築 ルートテーブルの構築 プライベートサブネットの構築 サブネットの構築 NATインスタンスの構築 Elastic IPの割り当てと関連付け ルートテーブルの構築 Auto Scaling Groupのための前準備 プライベートサブネットにEC2インスタンス（

サブネットはVPC内部につくるアドレスレンジ VPCに設定したCIDRブロックの範囲に収まる小さなCIDRブロックを割り当てることができる(CIDRブロックのサイズはVPCと同様に16ビットから28ビットまで) 個々のサブネットには1つの仮想ルータがあり、このルータがルートテーブルとネットワークACLの設定を持っており、サブネット内のEC2インスタンスのデフォルトゲートウェイになっている [注意] 1. サブネットの最初の4つおよび最後の1つのアドレスは予約されていて、使用できない 2. 必要以上にサブネットを分割することはアドレスの浪費につながる 3. パブリックサブネットやプライベートサブネットという表現がされることがあるが、インターネットゲートウェイ・ルートテーブル・ネットワークACLなどを利用して、そのような役割を割り当てているだけ セキュリティグループはEC2など、インスタンス単