Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
第18回  JAWS-‐‑‒UG札幌  勉強会
やってみたで終わらないLambdaな話
2016.4/21
⽐比企  宏之
⾃自⼰己紹介
☁   cloudpack⼤大阪  セクションリーダー
– 構築・24/365運⽤用
– MSP運⽤用⾃自動化推進役
☁ バックグラウンド
–  携帯電話/スマートフォン端末開発
エンタープライズシステム開発を経て
2014.4よ...
サーバーレスアーキテクチャーのコア
AWS  Lambda
Lambdaとは
☁ サーバーの負荷を気にせずインフラの管
理理不不要(AWS側が裏裏で⾃自動でスケールアウ
トしてくれる)
☁ 使った分だけの課⾦金金(リクエスト数+(時間
✖メモリ))
☁ 課⾦金金は100ミリ秒単位
⼿手軽に扱えるコンテナLambda
☁ 各実⾏行行環境の独⽴立立性を確保出来る。
☁ Dockerよりも簡単に構築・運⽤用が可能(主
観・⽤用途が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で始めるM...
開発時につまづきやすいポイント
☁ イベントフックの動作しているか(まず
CloudWatchのメトリクスで確認)?
開発時につまづきやすいポイント
☁ Cloud  Watch  Logsを⾒見見るときの落落とし⽳穴
        ⼀一⾒見見、末端まで⾒見見たかなと思っても、  
        ページ送りをすると、⽬目的のログが出てくることがある
実運⽤用中
なんかイベントが発⽕火しない・・・汗
プログラムのBUG?
http://qiita.com/Keisuke69/items/80df7211d989d136ce47
⾮非同期のイベントの処理理で
ENIの確保に
失敗した場合は現時点では
エラー検知できない・・・
クラウドは落落ちても良良いアーキテクチャー
↓
クラウドネイティブは動かない可能性を
フォローできるアーキテクチャー
なのでcloudpackのMSP開発チームでは
チェック項⽬目
☁ 例例外発⽣生時にきちんとエラーが検知されるように
できているか?
☁ ログに出⼒力力されるように作っているか?
☁ 動作しなかった場合のリカバリー⽅方法の⼿手段の⽤用
意
☁ 障害発⽣生時の時の検知⼿手段は確⽴立立されている...
正しく動かない事を前提に考えて
実装&運⽤用設計
開発・運⽤用をしてみて
☁ 気軽に実装・実⾏行行出来るのが素晴らしい。
☁ 処理理時間=コストが明確に出るので実装者
のスキルが試されるのが良良い(腕の⾒見見せ所)
☁ 通常の運⽤用時はパッチ当てなどが必要だ
が、AWS側でパッチ適応の運⽤用し...
開発・運⽤用をしてみて
☁ API  Gateway→Lambdaのハンドラーの
間の処理理の間で、使⽤用している⾔言語で
パースできない情報が⼊入っていると
Lambdaのハンドラー前でエラーが発⽣生す
るので、他のクラウドサービスの
web...
開発・運⽤用をしてみて
☁ EC2などはプロセス監視をしていたらある程
度度監視ができたが、イベントドリブンな
Lambdaが本当に動いているのかを確認する
必要がある気がする・・・
☁ 定期的に動作するLambdaをエラーログやメ
トリクス以...
開発・運⽤用をしてみて
☁ 上限緩和申請が可能だが、あまり多くは
望めない。
  必ずAWSに事前にピーク時に必要な
  処理理能⼒力力を確認してから設計/実装する
  同期処理理の場合は上限超えた場合は
      429エラー
特性と課題を⾒見見極めて実践投⼊入を
Lambdaで?って思った⼈人は
是⾮非懇親会で話しましょう
ご清聴ありがとうございました
Nächste SlideShare
Wird geladen in …5
×

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

第18回 jaws ug札幌 勉強会で発表したlambdaの話です

  • Als Erste(r) kommentieren

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

  1. 1. 第18回  JAWS-‐‑‒UG札幌  勉強会 やってみたで終わらないLambdaな話 2016.4/21 ⽐比企  宏之
  2. 2. ⾃自⼰己紹介 ☁   cloudpack⼤大阪  セクションリーダー – 構築・24/365運⽤用 – MSP運⽤用⾃自動化推進役 ☁ バックグラウンド –  携帯電話/スマートフォン端末開発 エンタープライズシステム開発を経て 2014.4より現職 – AWS  SAMURAI  2014受賞 – JAWS-‐‑‒UG  MVP  2013受賞
  3. 3. サーバーレスアーキテクチャーのコア AWS  Lambda
  4. 4. Lambdaとは ☁ サーバーの負荷を気にせずインフラの管 理理不不要(AWS側が裏裏で⾃自動でスケールアウ トしてくれる) ☁ 使った分だけの課⾦金金(リクエスト数+(時間 ✖メモリ)) ☁ 課⾦金金は100ミリ秒単位
  5. 5. ⼿手軽に扱えるコンテナLambda ☁ 各実⾏行行環境の独⽴立立性を確保出来る。 ☁ Dockerよりも簡単に構築・運⽤用が可能(主 観・⽤用途がLambdaに合ってる場合) ☁ 関数が実⾏行行している間だけ課⾦金金(無料料枠      あり) ☁ パッチ当て運⽤用が不不要 ☁ 疎結合でLambda毎に実装効率率率が⾼高い⾔言語 で実装が可能
  6. 6. Lambdaの制約 ☁ 最⼤大300秒 ☁ メモリの最⼤大値が決まっている ☁ スケジュール実⾏行行は5分以下での間隔が設 定できない。 ☁ 同時実⾏行行数は100で上限緩和申請可能 ☁ インスタンスが⽤用意されてない初回起動 が遅い(JAVAは連続しても⼆二回⽬目も遅い)
  7. 7. EC2と Lambda
  8. 8. EC2とLambdaの比較 具体例としてS3に配置された画像の変換処理 についてEC2とLambdaそれぞれで実行する 時の構築から運用までを比較してみます
  9. 9. 構成 EC2 Lambda
  10. 10. EC2の場合(構築時) EC2 サーバ準備 初期設定 ミドルウェア導⼊入 プログラム開発 監視設定 パッケージ更更新 ロケール設定 不不要サービス停⽌止 ユーザー管理理 死活監視 CPU監視 メモリ監視 ディスク ロードアベレージ ログ監視
  11. 11. Lambdaの場合(構築時) Lambda サーバ準備 初期設定 ミドルウェア導⼊入 プログラム開発 監視設定 実⾏行行回数監視 エラー回数監視 ログ監視
  12. 12. EC2の場合(運⽤用時) プログラムバグ 監視アラート 脆弱性対応 EC2
  13. 13. Lambdaの場合(運⽤用時) プログラムバグ 監視アラート 脆弱性対応 AWSにて対応 Lambda
  14. 14. 責任範囲や⾒見見る部分が⼤大幅に減る 構築運⽤用コストが減る 最⾼高・・・
  15. 15. cloudpackで使ってみて
  16. 16. うまく適⽤用すると AWS利利⽤用料料93%OFF になったシステムあり 今⽇日持ってきたホワイトペーパーにも 記載あり(実部の配布は今⽇日が初・15部のみ) さらばHubot  さらばEC2。 API  GatewayとLambdaで始めるMSPのIT化フェイズ3 http://unioce.hatenadiary.jp/entry/20151009/1444393907
  17. 17. 開発時につまづきやすいポイント ☁ イベントフックの動作しているか(まず CloudWatchのメトリクスで確認)?
  18. 18. 開発時につまづきやすいポイント ☁ Cloud  Watch  Logsを⾒見見るときの落落とし⽳穴        ⼀一⾒見見、末端まで⾒見見たかなと思っても、          ページ送りをすると、⽬目的のログが出てくることがある
  19. 19. 実運⽤用中 なんかイベントが発⽕火しない・・・汗
  20. 20. プログラムのBUG?
  21. 21. http://qiita.com/Keisuke69/items/80df7211d989d136ce47
  22. 22. ⾮非同期のイベントの処理理で ENIの確保に 失敗した場合は現時点では エラー検知できない・・・
  23. 23. クラウドは落落ちても良良いアーキテクチャー ↓ クラウドネイティブは動かない可能性を フォローできるアーキテクチャー
  24. 24. なのでcloudpackのMSP開発チームでは
  25. 25. チェック項⽬目 ☁ 例例外発⽣生時にきちんとエラーが検知されるように できているか? ☁ ログに出⼒力力されるように作っているか? ☁ 動作しなかった場合のリカバリー⽅方法の⼿手段の⽤用 意 ☁ 障害発⽣生時の時の検知⼿手段は確⽴立立されているか?   Pageduty/slack/backlog/メール ☁ 検知⼿手段に障害発⽣生時のシステムを使わない運⽤用 ⽅方法が確⽴立立されているか? ☁ システムが正常に動作している事の整合性を担保 する仕組みが提供されているか?
  26. 26. 正しく動かない事を前提に考えて 実装&運⽤用設計
  27. 27. 開発・運⽤用をしてみて ☁ 気軽に実装・実⾏行行出来るのが素晴らしい。 ☁ 処理理時間=コストが明確に出るので実装者 のスキルが試されるのが良良い(腕の⾒見見せ所) ☁ 通常の運⽤用時はパッチ当てなどが必要だ が、AWS側でパッチ適応の運⽤用してもら えるので運⽤用負荷が下がる。
  28. 28. 開発・運⽤用をしてみて ☁ API  Gateway→Lambdaのハンドラーの 間の処理理の間で、使⽤用している⾔言語で パースできない情報が⼊入っていると Lambdaのハンドラー前でエラーが発⽣生す るので、他のクラウドサービスの webhooksの受付先をAPI  Gateway +Lambdaで⾏行行う場合、先に検証が必要。
  29. 29. 開発・運⽤用をしてみて ☁ EC2などはプロセス監視をしていたらある程 度度監視ができたが、イベントドリブンな Lambdaが本当に動いているのかを確認する 必要がある気がする・・・ ☁ 定期的に動作するLambdaをエラーログやメ トリクス以外で動いているかの監視が必要な 気がする・・・ ☁ 運⽤用を相当意識識して実装しないと、運⽤用フェ イズで開発者へのエスカレーションばかりに なり、開発者が疲弊してしまう。
  30. 30. 開発・運⽤用をしてみて ☁ 上限緩和申請が可能だが、あまり多くは 望めない。   必ずAWSに事前にピーク時に必要な   処理理能⼒力力を確認してから設計/実装する   同期処理理の場合は上限超えた場合は      429エラー
  31. 31. 特性と課題を⾒見見極めて実践投⼊入を
  32. 32. Lambdaで?って思った⼈人は 是⾮非懇親会で話しましょう
  33. 33. ご清聴ありがとうございました

×