クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

2015年1月18日
から hiruta
0件のコメント

Docker Meetup #4に参加してみて

昨日Docker Meetup Tokyo #4に参加してきました。セッション×7、LT×8と中身の濃い半日でした。

CoreOS、dockerの性能劣化に関する話、Kubernetes(GKE)、ECSなどコンテナ管理するサービスの話、Cgroupによるコンテナリソースの制限、コンテナモニタリング(Datadog)、docker専用OSであるRHEL (CentOS) Atomic Hostの話、dockerのプロダクション環境での事例(wantedy)、docker remote API(https://github.com/fsouza/go-dockerclient)からdockerにアクセスする話、クレデンシャル情報をdocker環境で使う方法(外出しするのがベスト)、dockerでQA環境を構築した話(https://prevs.io/ja.html)、docker Hosting 「tutum」がありました。

共通でいえることは、dockerを使って耐障害性の高いシステムを構築するには、コンテナスケジューリング、監視がポイント。Kubernetes、ECSなどのコンテナ管理サービスは役に立つと思われる。DockerFileはシンプルに。DockerFileが複雑になるアプリケーションは、dockerには向いていない。(1 Process程度がいいとのこと)

コンテナ(docker)のユースケースとしては、Dev & Test、Auto deployment、Microservices、Batch Processing、社内PaaSがある。

以下については、別途順次検証等レポートしていきたい。

CoreOS

CentOS Atomic Host

Kubernetes

ECS

 

2015年1月14日
から hiruta
0件のコメント

Route53 Request Limitに対応するにはリトライは必須

通常のRoute53登録では問題になることはないが、Route53をVPCからしかアクセスできないPrivate DNSとして使えるようになったのは既知の事実。

Route53 Requestには、5 request/1s (AWSアカウント単位)の制限がある。AutoScalingでRoute53でリクエストする場合は、リトライ処理は必須となる。100%再現までとはいかないが、かなりの確率でAPI Errorが起きます。

AutoScaling Launch Configrationで使うことができるcloud-initスクリプトはqiitaにアップしてありますので、こちらを参照ください。

http://qiita.com/web_se/items/754353b49013a37913e5

2014年12月23日
から hiruta
0件のコメント

Lambda Meetup #0に参加してみて #LambdaMeetup

昨日ADSJで行われたLambda Meetup #0に参加しました。Lambdaの使用例からLambdaではまったポイントなど内容が盛り沢山でした。

[slideshare id=42949148&doc=zenza-lambda-141222191631-conversion-gate02]

Lambdaを使う上で、デモが動かない(アプリケーションサーバーからエラー)話。LambaのLimitを超えていた。3rdサービス(顔認識)とLambdaの間で処理がループしていて、LambdaのLimitを超えていたとのこと。LambdaのLimitについては下記。 http://docs.aws.amazon.com/lambda/latest/dg/limits.html

  • ADSJ 清水崇之 「LambdaとKinesisで作るど根性Tシャツ」

http://qiita.com/shimy@github/items/efa6cdf0955a110d8372

raspberry piからKinesis+Lambdaの事例。IoT(Internet Of Thing)は今後さらに広がっていくと予想されるので、Lambdaの用途も広がると思われる。

Lamdaは、エラー処理がポイント。LambdaはKinesis Stream、DynamoDB Streamと連携する際、Streamにゴミデータが入った、エラー取りこぼし処理がポイント。

  • 株式会社ディー・エヌ・エー 篠崎祐輔氏 「AWS Lambdaを紐解いてみた」

non-EC2によるフルマネージドの利点。見積、サイジングの削減が計れる。RDS、CodeDeployなどCIからデータベースまでフルマネージドのサービスが揃いつつあります。Lambdaはすべてがフルマネージドの出発点!

  • アンダースコア株式会社 諏訪悠紀氏 「Lambda × Mobileの可能性」

[slideshare id=42931562&doc=20141222lambdameetuplambdaxmobile-141222055859-conversion-gate02]

AWS SDK for iOSを自力でLambdaに対応してみた話。

Lambdaは、DynamoDB Stream、Kinesis Stream、S3イベント通知に対応しているが、現状SNS通知には対応してない。SNS通知が正式版ではほしい!Lamadaでは、定期実行がないので、バッチ処理ができない。

  • NRIネットコム株式会社 佐々木拓郎氏 「Lambdaで作るクローラー/スクレイピング」

[slideshare id=42966283&doc=awslambdameetup0-141223085825-conversion-gate01]

Lambdaに負荷をかけて、処理サーバーの負荷分散が行われる話。100リクエスト程度なら、同一サーバーで行われるが、1000リクエストとかかけるとサーバーも分散(自動スケールアウト)する。自動スケールアウトはフルマネージドの1利点。

  • クックパッド株式会社 菅原元気氏 「Lambdaによるクラウド型言語の実装」

[slideshare id=42933911&doc=20141222clala-141222074131-conversion-gate01]

すべての話で共通していたのは、フルマネージドサービスは極力使うのがサイジング、設計、運用でトータルコストを削減できる。

やはり、SNS通知のLambda対応、タイムアウト時間のカスタマイズ対応が待たれる。

 

2014年12月21日
から hiruta
0件のコメント

Ruuning InstanceをAutoScaling Groupに追加する機能について

Running中のインスタンスを簡単にAutoScaling Groupに追加できるメールがありました。

It is now even easier to get started with Auto Scaling for your Amazon EC2 instances. Auto Scaling helps you maintain application availability and allows you to scale your Amazon EC2 capacity up or down automatically according to conditions you define. You can use Auto Scaling to help ensure that you are running the number of Amazon EC2 instances you need. Auto Scaling can also automatically increase the number of instances during demand spikes to maintain performance and decrease capacity during lulls to help reduce costs.
Starting today, we’ve made it easy for you to enable Auto Scaling on a running instance directly from the Instances view in the AWS Management Console. To learn how to enable Auto Scaling on running instances, please visit Attach EC2 Instances to Your Auto Scaling Group.

が、外部EBSを付け、ミドルウェアをインストールしたインスタンスをAutoScaling Groupにアタッチしてみました。

Launch Configuration、AutoScaling Groupはちゃんと作成はできました。が、実際インスタンスをterminateさせ、AutoScalingを発動してみました。

新たなインスタンスがLaunchはしてきましたが、外部EBS、ミドルとも元の状態には戻りませんでした。ミドルウェアを組み込んだAMIによるAutoScalingが結局必須の結論に。

2014年12月20日
から hiruta
0件のコメント

nginxのアクセスログをGoogle BigQueryに送信してみました。 #gcpja

GCP Advent Calendar 12/20のエントリ記事になります。LB + Autoscalerを書こうとしましたが、詳細に解説しているページがありましたので、HPCの基盤技術としてつけるBigQueryについて書きます。LB+AutoScalerについては以下で詳細にか書かれています。

http://qiita.com/soundTricker/items/951a02266a5c95165863

nginxのアクセスログの出力項目を変更します。time、hostがBigQueryのスキーマの項目に一致します。

     log_format  ltsv  'time:$time_iso8601\t'
                        'host:$remote_addr\t'
                        'uri:$request_uri\t'
                        'method:$request_method\t'
                        'forwardfor:$http_x_forwarded_for\t'
                        'request:$request\t'
                        'status:$status\t'
                        'size:$body_bytes_sent\t'
                        'referer:$http_referer\t'
                       'ua:$http_user_agent\t'
                        'reqtime:$request_time\t'
                       'upsttime:$upstream_response_time\t'

APIと認証→認証情報から、新しいクライアントIDを作成します。*.p12用のパスフレーズも表示されますので、控えておきます。下記作業では使用しませんが。

画像2

作成後、*.p12ファイルが作成されますので、サーバーの/etc/td-agentにアップロードします。

Fluentd pluginを導入します。

/usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-bigquery
/usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-forest

BigQuery用スキーマファイルを作成します。

[
  { "name": "time",    "type": "timestamp" },
  { "name": "size",  "type": "integer"  },
  { "name": "reqsize",    "type": "integer"  },
  { "name": "status",    "type": "integer"  },
  { "name": "host",  "type": "string"  },
  { "name": "uri",    "type": "string"  },
  { "name": "method",    "type": "string" },
  { "name": "ua",    "type": "string" },
  { "name": "vhost", "type": "string" },
  { "name": "reqtime",   "type": "float" },
  { "name": "apptime",  "type": "float"}
]

作成したスキーマファイルを使って、スキーマを作成します。

bq mk -t project_id:nginx_datasheet.access_log schema.json

S3にログを転送しつつ、BigQueryに送信するために、fluent-plugin-forestプラグインを使っています。

  type tail
  path /var/log/nginx/totalsolution.biz.access.log
  format ltsv
  time_key time_local
  time_format %d/%b/%Y:%T %z
  pos_file /var/tmp/nginx_access_log.pos
  tag nginx.access

# Output

  type forest
  subtype copy

      type s3

      s3_bucket XXXXXXXXXXXXXXXXXXX
      s3_region ap-northeast-1
      s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
      path logs/
      buffer_path /var/log/fluent/

     time_slice_format %Y/%m/%d/
     flush_interval 10m
     utc

      type bigquery
      method insert

      auth_method private_key
      email XXXXXXXXXXXXXXXX@developer.gserviceacco
unt.com
      private_key_path /etc/td-agent/my-cloud-environment-879d7473d230.p12

      project skillful-fx-531
      dataset nginx_datasheet
      table access_log
      buffer_chunk_records_limit 500
      buffer_chunk_limit 1000000
      buffer_queue_limit           5000
      flush_interval               1
      try_flush_interval           0.05
      num_threads                  4
      queued_chunk_flush_interval  0.01
      time_format %s
      time_field time
      schema_path /etc/td-agent/schema.json

画像3

 

Google BigQuery 機能 Redshift
95円/月
Wikipedia3億行
価格 \90,000
ストリーミング  不可
 Tableau  BI  Tableau

価格的にGoogle BigQueryが優位な結果に。

時たま500エラーがでるようだが。

 tabledata.insertAll API project_id="skillful-fx-531" dataset="nginx_datasheet" table="access_log" code=500 message="Unexpected. Please try again."
 [warn]: retry succeeded. instance=70122832844240

確かに、サーバーエラー(500)が起きている。考えられることはBigQueryのLimit、ネットワークがあるが。

screencapture-console-developers-google-com-project-skillful-fx-531-apiui-apiview-bigquery

2014年12月19日
から hiruta
0件のコメント

EC2 Container Serviceファーストインプレッション #jawsug

EC2 Container Service (ECS)のプレビューが通りましたので、早速Getting Started通りではありますが、試してみました。 プレビュー用のAWS CLIをまずインストール。AWS CLIは、1.6.5のようです。

$  aws --version
aws-cli/1.6.5 Python/2.7.5 Linux/3.10.0-123.el7.x86_64

Clusterをまず作成。もちろんap-northeast-1ではエラー。

$  aws ecs create-cluster --cluster-name MyCluster --region ap-northeast-1

HTTPSConnectionPool(host='ecs.ap-northeast-1.amazonaws.com', port=443): Max retries exceeded with url: / (Caused by <class 'socket.gaierror'>: [Errno -2] Name or service not known)

us-east-1で無事ACTIVEに。

$  aws ecs create-cluster --cluster-name MyCluster --region us-east-1
{
    "cluster": {
        "clusterName": "MyCluster",
        "status": "ACTIVE",
        "clusterArn": "arn:aws:ecs:us-east-1:XXXXXXXXXXX:cluster/MyCluster"
    }
}

CommunityAMI ami-34ddbe5cを使って、ECS用に最適化したインスタンスをLaunchします。 cloud-initに以下を入力

#!/bin/bash
echo ECS_CLUSTER=MyCluster >> /etc/ecs/ecs.config

root volume は、30GBがデフォルトで設定されています。

aws ecs list-container-instances --cluster MyCluster --region us-east-1
{
    "containerInstanceArns": [
        "arn:aws:ecs:us-east-1:XXXXXXXXXXXXXX:container-instance/be81fda7-5486-4584-89d0-2f8bff6119d3"
    ]
}

これですが、インスタンスタイプにt2.microを使ったためかもしれませんが、はじめMISSINGでしたが、無事ACTIVEに。

aws ecs describe-container-instances --cluster MyCluster --container-instances be81fda7-5486-4584-89d0-2f8bff6119d3 --region us-east-1
{
    "failures": [],
    "containerInstances": [
        {
            "status": "ACTIVE",
            "registeredResources": [
                {
                    "integerValue": 1024,
                    "longValue": 0,
                    "type": "INTEGER",
                    "name": "CPU",
                    "doubleValue": 0.0
                },
                {
                    "integerValue": 996,
                    "longValue": 0,
                    "type": "INTEGER",
                    "name": "MEMORY",
                    "doubleValue": 0.0
                },
                {
                    "name": "PORTS",
                    "longValue": 0,
                    "doubleValue": 0.0,
                    "stringSetValue": [
                        "2376",
                        "22",
                        "51678",
                        "2375"
                    ],
                    "type": "STRINGSET",
                    "integerValue": 0
                }
            ],
            "ec2InstanceId": "i-0000000000",
            "agentConnected": true,
            "containerInstanceArn": "arn:aws:ecs:us-east-1:XXXXXXXXXXX:container-instance/be81fda7-5486-4584-89d0-2f8bff6119d3",
            "remainingResources": [
                {
                    "integerValue": 1024,
                    "longValue": 0,
                    "type": "INTEGER",
                    "name": "CPU",
                    "doubleValue": 0.0
                },
                {
                    "integerValue": 996,
                    "longValue": 0,
                    "type": "INTEGER",
                    "name": "MEMORY",
                    "doubleValue": 0.0
                },
                {
                    "name": "PORTS",
                    "longValue": 0,
                    "doubleValue": 0.0,
                    "stringSetValue": [
                        "2376",
                        "22",
                        "51678",
                        "2375"
                    ],
                    "type": "STRINGSET",
                    "integerValue": 0
                }
            ]
        }
    ]
}

ECS用インスタンスの中身を確認しました。

$ which docker
/usr/bin/docker
$ docker ps
CONTAINER ID        IMAGE                            COMMAND             CREATED             STATUS              PORTS                        NAMES
844d5e0fe2fd        amazon/amazon-ecs-agent:latest   "/agent"            6 minutes ago       Up 6 minutes        127.0.0.1:51678->51678/tcp   ecs-agent

dockerのバージョンは、1.3.3

$ docker -v
Docker version 1.3.3, build c78088f/1.3.3

後ほどいろいろ検証してみたいと思います。

※Preview通っていないアカウントでは、もちろん利用できません。

$  /home/hiruta/.local/lib/aws/bin/aws ecs create-cluster --cluster-name MyCluster --region us-east-1

A client error (OptInRequired) occurred when calling the CreateCluster operation: The AWS Access Key Id needs a subscription for the service

2014年12月13日
から hiruta
0件のコメント

HPC on AWSクラウドシリーズ 第三回:メーカー企業におけるビックデータ活用

12/11 HPC on クラウドのセミナーに参加してきました。

HPC on クラウドを実現するビックデータ処理のご紹介

 

在庫管理、物流などをITで
さまざまなシステムが有機的につながっている
ITのリソースの用意 時間がかかっていた
購入、セットアップ
社内で稟議などで決めていた。無駄
必要名ときにプチとして使えないか
クラウドの原型

発電機をもつのが差別化要因では
電気を使って何を作っていくのが

大きなパラダイム
必要なときに使う。より速く、簡単に、安くを実現

今まで出来なかったことができるようになる
改善、イノベーションも

2006/3/14 Amazon S3発表

去年は280
今年は、500を超える位の新機能の追加

EC2使用率 年率99%の成長率

いろんなIOS9001等の認証を取得

StartClusterをOnc-Commandで作成管理する (http://utility onnpass.com/event/9512/)

HPCの構成

  • ヘッドノード
  • 計算ノード
  • ストレージノード lustre OrangeFS
  • WANの高速化ソリューション skeed , aspera

 

c3.8xlarge 1,656ノード
484.2 TFLOPS
TOP5000 64位 NOV 2013
一時間当たり約29万円

実行性能が上がってきている。Efficiency
レイテンシーで性能変わっている。レイテンシが短くなっている

AWS専用に強化されたCPUを搭載したC4インスタンス発表

空く具合で定価の1/10で利用可能

現行だと1.8倍速くなっています。 c3 > cr1

オンプレよりもC3の方が速い

GPUインスタンス
Hour単位で
グラフィックスで使えるのかお試しでも
G2 + XenApp
クラウド上のGPUで

HPCの紹介

  • CieSpace
    AWSでSaaS
  • OpenFormで計算
    流体形跡
  • PLEXUS CAE
    ブラウザだけで計算
  • NEC HPC Online
    計算リソース
  • VT-HCM2
    VisualTechnology

HPCクラウドを支えるインテルの技術

 

ビジネスを効率化するツールからビジネスそのものになってきている
コンシューマーから発信してくるデータが増えてきている
IoT、センサーからのデータ
街角のカメラ
工場の中のデータ
増えてきている

膨大なデータの処理
パラレルデータベース、サーチ
莫大なデータを扱うアプリケーション
HPCへのニーズも

研修所だけでなくてもハイパフォーマンスコンピューティングのニーズも

Xeon がHPCの核

集積回路 トランジスタのサイズが小さく
今後も
小さくなるメリット 実装面積も増やせるし、消費電力の削減、物理的な距離も短く

E5-2600 v3
18個のコア
電力管理の工夫
メモリ DDR4
新しいフューチャーも
浮動小数点の演算も進化
ベクトル演算ユニット
浮動小数点 356bit幅
FMA( Fused Multiply-Add) 乗算と演算を同時に
90% Linpack
120% SPECjbb 2013-M

暗号化処理の向上も

消費電力も上げっていない

E5 2666 v3
AWS専用

本田技研工業におけるHPC on AWSの歩み

re:invent 2014のリピートセッションになります。

[slideshare id=41528400&doc=bdt201-141113144712-conversion-gate02]

Local、スピード感ですすめてきた

それぞれのスパコン

グローバル化、効率化、生産開発体制、CAEのリソース 一カ所で集約

いろいろな研究、作っている
細かい要望も多い、製品になっていないものも
さまざまなリクエストに答えるのが難しくなってきた

量産系も研究開発が優先
基礎研に割り当てるのも難しい
答えることに行き着いたのがクラウド

一週間だけ使うのも

2012夏
社内でも調達できず、社外に目を向けた
ユーザがもとめている三ヶ月で終わらない
審査とか
いがいに使えるところがない

リードタイム
スピードに答えられるか
待てない、今過ぎ使いたい

柔軟性
止めたいとき止めたい
時間単位で貸してくれるのも

最新のCPUも
スパコンは新しいコアが使いたいニーズにも答えられる
スポットインスタンスも

 

[slideshare id=41572733&doc=spot301-141114135304-conversion-gate01]

リソースの5倍持っている
AWSは、1AZ、1DCに五万台
HPCでクラウドでAWSは避けられない

うまく使えるように
速く使ったほうがいいのを伝えたい

電力の問題
オレゴン、EUフランクフルト カーボンフリー
これも1つの魅力

Cluster manager job schedular
Computing node スポットインスタンス or オンデマンド(スポットインスタンスですべてのリソースはカバーできないので、オンデマンドを併用しているとのこと)
計算が終わったら、、終了

1/3の期間で終了
ピーク時は16,000コア同時に使っている
70%のコスト際限
スポットインスタンスを併用する
スポットインスタンスはAZのキャパで起動できない場合があるので、オンデマンドと併用しているとのこと
オンプレでやったらい
非常に難しい
三ヶ月かかる損失も出さないと明確には出せない

調達コストは
16,000コア 16,000コア持っていないといけない 1/7

性能、ライセンス

ライセンスのビジネスモデル
商用ソフトウェアの対応がネック

InfiniBandをつんでいるものと同等
最大スケールまでは出せていない
今後に期待

ISVの反応が変わってきている。個人的な所感

でも、このあたりの進化はまだまだ

ユーザ主導型のエコシステム =クラウド

こうゆうものがほしい、 →サービスが増えていく →ユーザが増えていく →リリースの数も増えていく 加速度的に増えていく

リクエストも投げるのも手

声を上げる 変えることもでできる

クラウドリソースを使うべきか
計算リソースを持てないところも使えるようになる

変えないとついて行けない

5年後

クラウドはHPC使うのは当たり前
マルチクラウドの形でリソースを使って行ければと

会社の特徴も持っているクラウド業者も

ソフトウェアのライセンスの問題
性能などもある

考え方も変えていかなければならない

前向きにとらえてやっていくのがポイント クラウドユーザ次第

オンプレとクラウドをシームレスに

HPC分野も、AWSを筆頭に、クラウドは避けて考えることはできないと実感しました。IoTなどセンサーネットワークが今後広がっていることも考えます。

2014年11月24日
から hiruta
0件のコメント

JAWS-UG CLI専門支部#7(祝日スペシャル) -VPCに参加しました。 #jawsug

本日、初めて、JAWS-UG CLI専門支部#7(祝日スペシャル) -VPCに参加しました。

VPCの作成から、サブネット、ルーティングテーブル、セキュリティグループ作成まで行い、作成したサブネットにEC2をLaunch、作成したVPC内のEC2インスタンスのterminateまでの流れでした。

検証環境とか本番環境とか構築する場合、セキュリティグループを作成する際、AWS Management Consoleだと、全く同じとは限りませんが、二度同じことを、アプリ毎の通信用件で、インバウンドルール/アウトバウンドルールを設定しないといけないが、AWS CLIを使うことで、一度スクリプトを作成しておけば、差分だけ変更するだけで、構築が可能になります。

自動化ではCLIは必須ではないかと。また、CloudFormationとの棲み分けか。CLIだとVPCの場合、Routing TableとかIGW、セキュリティグループなど関連オブジェクトがあり、ワンコマンドで削除が難。※Management Consoleだと、関連するものから順に消してくれます。ただ、Management Consoleにおいても、消えない場合があります。(DHCP Option Sets)

ハンズオンの中で、EC2-Classicが使えるAWSアカウントでしたので、ハンズオンの手順通りにはいかないことがありました。

・リージョンごとに、使えるAZが違う。※自分の場合、東京リージョンは、ap-northeast-1b/ap-norhteast-1cが使えます。ap-northeast-1aはスポットインスタンスの相場が表示されないインスタンスタイプがあります。

・EIPの作成(aws ec2 allocate-address)の項目がありましたが、EC2-Classicが使えるリージョンをあるAWSアカウントだと、オプション「–domain vpc」を付けないと、VPCで使えるEIPが取得できません。

本日の資料等は以下に公開されております。

[JAWS-UG CLI]VPC#1 VPC作成   qiita.com/tcsh/items/41e1aa3c77c469c92e84

[JAWS-UG CLI]VPC#2 VPCの使用例(EC2)  http://qiita.com/tcsh/items/b68ec66cf5de5a868ac7

また、re:Inventで発表したばかりのAWS Configを使って、インスタンスの状態を可視化する紹介がありました。※AWS Config自体、まだusリージョンのみなので、東京リージョンで使えるようになることが待ち遠しい。

http://qiita.com/ar1/items/c53e29c08ae159f5239b

インスタンスの変更履歴がとれるので、作業操作ログ等監査ログとしても使えると思われます。

2014年11月22日
から hiruta
0件のコメント

イベント告知「ゆくとしくるとし千葉エンジニア祭り」の案内 #chibadan

12月13日(土)に、『千葉に縁のあるエンジニアなら誰でも来い』をコンセプトに、千葉にもこんなエンジニアがいる事を知ってもらい、参加者同士の交流をより広げ・より深めようをコンセプトに、イベントを開催します。場所は、コワーキングスペース茅場町5Fです。(会場費1人当たり1,000円がかかります)

千葉ゆかりのあるIT業界では名前が知られているIBM、LINE、NTTデータ、Googleのエンジニアによるセッション(技術話もございます)があります。

イベントの詳細・申し込みは以下よりお願いします。

http://chibadan.doorkeeper.jp/events/17828

勉強会終了後、懇親会(忘年会)もあります。登壇される方々と親睦を深められること間違いなしです。懇親会にも参加してみてはいかがでしょうか。

http://chibadan.doorkeeper.jp/events/17829

2014年11月16日
から hiruta
0件のコメント

re:Invent 2014 MBL202 NEW LAUNCH: Getting Started with AWS Lambda セッションレポート #reinvent

re:Invent 2014のキーノートで発表されたサービスの1つになります。
ブレイクアウトセッションも行えることで、セッションを受講した所感になります。
Lambdaアプリケーション設定画面
IMAG0283
IMAG0284

概要

  • 処理が必要なときだけ発動(EC2のようにリソースのレンタルは行わないので低コスト)
  • lambda functionは現時点では、node.jsで記載
  • ImageMagickライブラリも含まれています。
    • node.jsのWebSocketは対応しているものか。

S3イベント通知との連動

ECS、AWS Lambda の発表の後ろに隠れてしまいましたが、S3イベントをAWS Lambda、SNSなどに通知が行えるようになっているので、Lambdaに通知することでS3アクセスログをCloudwatch Logsに書き出したり、DynamoDBに書き出すことが可能になります。

IMAG0287

LambdaからCloudWatch Logに出力するデモ。LambdaからDynamoDB、Kinesisとも連携可能

IMAG0290

AWS CLI

1.6.2ですでに対応

aws lambda add-event-source
aws lambda delete-function
aws lambda get-event-source
aws lambda get-function
aws lambda get-function-configuration
aws lambda invoke-async
aws lambda list-event-sources
aws lambda remove-event-source
aws lambda update-function-configuration
aws lambda upload-function

ユースケース

サムネ画像を生成するために、EC2を利用していたのをAWS Lambdaに置き換えることで、EC2コストの低減も図れるのではと考えられます。
バッチ処理を扱うシステムで利用されると思われます。
 センサーログ等を取得したいloT分野には最適なソリューションと思われます。

CDP

Data Generate Processing Pattern
lambdaを使ったCDPも考えられます。

Limit Previewの制限

  • サポート
DynamoDb stream
Kinesis Streams
  • 機能

Lambda console SDK andd CLI
Limit of 25 concurrent request per account
Limit of 60 seconds runninning time per request

Limit Previewはこちらからリクエストが可能です。

https://aws.amazon.com/jp/lambda/

EC2 Container Service、RDS Aurora Enginともに、Limit Previewに早速リクエストはしましたが、いつ使えるようになるのでしょうか。(速く使ってみたい!)