読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

AWS Lambdaを紐解いてみた #LambdaMeetup

勉強会

おもにNode.jsをいじっていた

AWS Lambda(えーだぶるえす らむだ)とは

AWS Lambda(えーだぶるえす らむだ)とは

一言で言うと…

  • クラウドレベルでのイベント駆動開発を可能とする技術

Lambda以前

  1. ApacheによるCGIスタイル(EC2などない) -2000
  2. LAMPスタックやRails(RDSなどない) 2000-2005
  3. トラフィックの増加でキャッシュ使用(徐々に複雑になる) 2005-2008
  4. さらなるトラフィックでロードバランシングが必須(このあたりからAWS出てくる) 2008-2010
  5. モバイルでさらにトラフィック pubsub notification ビッグデータ解析 カジュアルにアップされるファイル トラフィックの予測ができなくなってきて、レビューするのもしんどくなってくる 実際のロードも難しく、構成設計もカンだのみ 2010-
  6. さらにシステムの入出力が多様化 仕様も複雑化→耐障害性がわかりづらい
  7. そしてLambda

そもそもラムダってなんだよ そんなにすごくないじゃん…っていう感想

理解

すべてなフルマネージドな世界への出発点 かつEC2の役割の縮小 クラウドアプリケーションの実現

EC2セットアップ→プログラムの仕様、設計→見積もり(期間、性能などの見積もり)→レビューに時間がかかる

Lambdaのメリット

  • 費用は従量課金
  • スケーラビリティは考えなくていい
  • 冗長性は考えなくていい
  • リアルタイムアプリケーションの作成
  • 運用コストの削減

開発リードタイムの削減

今までだと冗長・スケーリングからプログラム動作仕様、費用、期間などの見積もりに時間がかかる

  • 設計
  • 見積もり
  • セットアップ

これらの時間を削減出来たりできる

プログラム動作仕様→費用見積もり→開発期間見積もり だけでよくなる

サイクルタイムを短くすることが物を言う Marc Andressen

イベントログによる耐障害性

イベントログを残しておくことで再処理さえすれば同じ結果を得られる

イベントドリブンとAWS

  • クラウドレベルでのイベントドリブンができるのがLambda
  • イベント操作、メッセージの標準化(誰が書いても一緒のものができる)
  • シンプリシティ(EC2の設計、つなぎこみなどをシンプルにできる)

仕様策定と開発に集中できる

HTTPサーバとイベントドリブン

HTTPサーバもラムダもイベント待ち受けという点では一緒(口が違うだけ)

S3のファイルを使うときにルータを自作するとか

AWSとLambdaがもたらす変化

  • イベント起点の増加
  • よりデータに着目した設計に

まとめ

  • Resilience(耐障害性)
  • Agility(警戒さ)
  • Elasticity(えらすてぃっくなんとかのように伸縮可能)
  • Timeliness(リアルタイム処理)
  • Event-Driven Computing(ラムダの最大の特徴)