第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
EC2とLambdaの比較
具体例としてS3に配置された画像の変換処理
についてEC2とLambdaそれぞれで実行する
時の構築から運用までを比較してみます
構成
EC2 Lambda
EC2の場合(構築時)
EC2
サーバ準備
初期設定
ミドルウェア導⼊入
プログラム開発
監視設定
パッケージ更更新
ロケール設定
不不要サービス停⽌止
ユーザー管理理
死活監視
CPU監視
メモリ監視
ディスク
ロードアベレージ
ログ監視
Lambdaの場合(構築時)
Lambda
サーバ準備
初期設定
ミドルウェア導⼊入
プログラム開発
監視設定
実⾏行行回数監視
エラー回数監視
ログ監視
EC2の場合(運⽤用時)
プログラムバグ
監視アラート
脆弱性対応
EC2
Lambdaの場合(運⽤用時)
プログラムバグ
監視アラート
脆弱性対応 AWSにて対応
Lambda
責任範囲や⾒見見る部分が⼤大幅に減る
構築運⽤用コストが減る
最⾼高・・・
cloudpackで使ってみて
うまく適⽤用すると
AWS利利⽤用料料93%OFF
になったシステムあり
今⽇日持ってきたホワイトペーパーにも
記載あり(実部の配布は今⽇日が初・15部のみ)
さらばHubot  さらばEC2。
API  GatewayとLambdaで始めるMSPのIT化フェイズ3
http://unioce.hatenadiary.jp/entry/20151009/1444393907
開発時につまづきやすいポイント
☁ イベントフックの動作しているか(まず
CloudWatchのメトリクスで確認)?
開発時につまづきやすいポイント
☁ Cloud  Watch  Logsを⾒見見るときの落落とし⽳穴
        ⼀一⾒見見、末端まで⾒見見たかなと思っても、  
        ページ送りをすると、⽬目的のログが出てくることがある
実運⽤用中
なんかイベントが発⽕火しない・・・汗
プログラムのBUG?
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な話