第18回 jaws ug札幌勉強会やってみたで終わらないlambdaな話

第18回 JAWS-‐‑‒UG札幌勉強会
やってみたで終わらないLambdaな話
2016.4/21
⽐比企宏之

⾃自⼰己紹介
☁  cloudpack⼤大阪セクションリーダー
– 構築・24/365運⽤用
– MSP運⽤用⾃自動化推進役
☁ バックグラウンド
–  携帯電話/スマートフォン端末開発
エンタープライズシステム開発を経て
2014.4より現職
– AWS SAMURAI 2014受賞
– JAWS-‐‑‒UG MVP 2013受賞

サーバーレスアーキテクチャーのコア
AWS Lambda

Lambdaとは
☁ サーバーの負荷を気にせずインフラの管
理理不不要(AWS側が裏裏で⾃自動でスケールアウ
トしてくれる)
☁ 使った分だけの課⾦金金(リクエスト数+(時間
✖メモリ))
☁ 課⾦金金は100ミリ秒単位

⼿手軽に扱えるコンテナLambda
☁ 各実⾏行行環境の独⽴立立性を確保出来る。
☁ Dockerよりも簡単に構築・運⽤用が可能(主
観・⽤用途がLambdaに合ってる場合)
☁ 関数が実⾏行行している間だけ課⾦金金(無料料枠
あり)
☁ パッチ当て運⽤用が不不要
☁ 疎結合でLambda毎に実装効率率率が⾼高い⾔言語
で実装が可能

Lambdaの制約
☁ 最⼤大300秒
☁ メモリの最⼤大値が決まっている
☁ スケジュール実⾏行行は5分以下での間隔が設
定できない。
☁ 同時実⾏行行数は100で上限緩和申請可能
☁ インスタンスが⽤用意されてない初回起動
が遅い(JAVAは連続しても⼆二回⽬目も遅い)

EC2とLambdaの比較
具体例としてS3に配置された画像の変換処理
についてEC2とLambdaそれぞれで実行する
時の構築から運用までを比較してみます

EC2の場合（構築時）
EC2
サーバ準備
初期設定
ミドルウェア導⼊入
プログラム開発
監視設定
パッケージ更更新
ロケール設定
不不要サービス停⽌止
ユーザー管理理
死活監視
CPU監視
メモリ監視
ディスク
ロードアベレージ
ログ監視

Lambdaの場合（構築時）
Lambda
サーバ準備
初期設定
ミドルウェア導⼊入
プログラム開発
監視設定
実⾏行行回数監視
エラー回数監視
ログ監視

EC2の場合（運⽤用時）
プログラムバグ
監視アラート
脆弱性対応
EC2

Lambdaの場合（運⽤用時）
プログラムバグ
監視アラート
脆弱性対応 AWSにて対応
Lambda

責任範囲や⾒見見る部分が⼤大幅に減る
構築運⽤用コストが減る
最⾼高・・・

うまく適⽤用すると
AWS利利⽤用料料93%OFF
になったシステムあり
今⽇日持ってきたホワイトペーパーにも
記載あり(実部の配布は今⽇日が初・15部のみ)
さらばHubot さらばEC2。
API GatewayとLambdaで始めるMSPのIT化フェイズ3
http://unioce.hatenadiary.jp/entry/20151009/1444393907

開発時につまづきやすいポイント
☁ イベントフックの動作しているか(まず
CloudWatchのメトリクスで確認)？

開発時につまづきやすいポイント
☁ Cloud Watch Logsを⾒見見るときの落落とし⽳穴
⼀一⾒見見、末端まで⾒見見たかなと思っても、
ページ送りをすると、⽬目的のログが出てくることがある

実運⽤用中
なんかイベントが発⽕火しない・・・汗

http://qiita.com/Keisuke69/items/80df7211d989d136ce47

⾮非同期のイベントの処理理で
ENIの確保に
失敗した場合は現時点では
エラー検知できない・・・

クラウドは落落ちても良良いアーキテクチャー
↓
クラウドネイティブは動かない可能性を
フォローできるアーキテクチャー

なのでcloudpackのMSP開発チームでは

チェック項⽬目
☁ 例例外発⽣生時にきちんとエラーが検知されるように
できているか？
☁ ログに出⼒力力されるように作っているか？
☁ 動作しなかった場合のリカバリー⽅方法の⼿手段の⽤用
意
☁ 障害発⽣生時の時の検知⼿手段は確⽴立立されているか？
　Pageduty/slack/backlog/メール
☁ 検知⼿手段に障害発⽣生時のシステムを使わない運⽤用
⽅方法が確⽴立立されているか？
☁ システムが正常に動作している事の整合性を担保
する仕組みが提供されているか？

正しく動かない事を前提に考えて
実装＆運⽤用設計

開発・運⽤用をしてみて
☁ 気軽に実装・実⾏行行出来るのが素晴らしい。
☁ 処理理時間=コストが明確に出るので実装者
のスキルが試されるのが良良い(腕の⾒見見せ所)
☁ 通常の運⽤用時はパッチ当てなどが必要だ
が、AWS側でパッチ適応の運⽤用してもら
えるので運⽤用負荷が下がる。

☁ API Gateway→Lambdaのハンドラーの
間の処理理の間で、使⽤用している⾔言語で
パースできない情報が⼊入っていると
Lambdaのハンドラー前でエラーが発⽣生す
るので、他のクラウドサービスの
webhooksの受付先をAPI Gateway
+Lambdaで⾏行行う場合、先に検証が必要。

☁ EC2などはプロセス監視をしていたらある程
度度監視ができたが、イベントドリブンな
Lambdaが本当に動いているのかを確認する
必要がある気がする・・・
☁ 定期的に動作するLambdaをエラーログやメ
トリクス以外で動いているかの監視が必要な
気がする・・・
☁ 運⽤用を相当意識識して実装しないと、運⽤用フェ
イズで開発者へのエスカレーションばかりに
なり、開発者が疲弊してしまう。

☁ 上限緩和申請が可能だが、あまり多くは
望めない。
　必ずAWSに事前にピーク時に必要な
　処理理能⼒力力を確認してから設計/実装する
　同期処理理の場合は上限超えた場合は
429エラー

特性と課題を⾒見見極めて実践投⼊入を

Lambdaで？って思った⼈人は
是⾮非懇親会で話しましょう

ご清聴ありがとうございました

第18回 jaws ug札幌勉強会やってみたで終わらないlambdaな話

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to 第18回 jaws ug札幌勉強会やってみたで終わらないlambdaな話 (20)

More from Hiroyuki Hiki (20)