明日から始めるちょい足し λ / get-started-with-aws-lambda

Transcript

1. 開発現場に効く？サーバーレス 明日から始めるちょい足し λ Tech-on MeetUp #01 July 9, 2018 Ryo

   NAKAMARU, SUPINF Inc. / Rescale, Inc.

2. 中丸 良 @pottava • CTO at SUPINF Inc. / Software

   Engineer at Rescale, Inc. • ずーっとソフトウェア開発職 • Windows 独自プロトコルのクラサバシステムから始まり • 製造業・研究機関向け機械学習基盤、Cloud HPC の SaaS 基盤など Profile !2

3. SUPINF Inc. !3 • クラウド / コンテナ 中心のコンサルティング / 環境構築

   / 受託開発 / 運用 • 一方ではオンプレ × Kubernetes な機械学習環境なども • スピンフ、と読みます

4. Rescale, Inc. !4 • クラウド HPC プラットフォームを SaaS で提供 •

   商用アプリケーションを使ったシミュレーションをスケーラブルに • 航空宇宙、自動車、石油ガス、ライフサイエンス、機械学習、etc..

5. テーマ !5 開発現場に効く （改善策を探して導入したら、結果的に） サーバーレス （というか Lambda だった話 + その過程）

6. でもその前に、まず、懺悔 !6

7. AWS Lambda、想像以上に 難しい　　　　　　　　。 始めるのは簡単ですが、後悔なきよう 導入の判断 は慎重に !7 「明日から始める」 なんて書いてますが

8. サーバーレス !8 • 特徴 や 使いどころ は事前にしっかり把握しましょう • 苦労してでも使うべきところは 多々ある

   が • メンテナンスし続けるコスト、全くもって無視できない • 研究、PoC 期間を ちゃんと設けて 小さめにスタート〜

9. 今日の話 !9

10. トピック !10 • 社内事例 1: 共有された情報の検索 • 社内事例 2: 秘密情報の管理

    • 社内事例 3: 関係者用確認サイトのアクセス制御 • 一般的な開発プロセスと、よくある課題 • 明日から始まる λ の運用

11. 社内事例 !11

12. 社内事例 1: 共有された情報の検索 !12 • スプリント振り返りでの頻出 Problem？「情報共有」 • Confluence, DocBase,

    Google Drive, .. どこにあるの？ • ドキュメントの構造化・周知以外にできることは？ • Chat に #onboarding チャンネル を作るのも大切だけど・・ • 機械に任せよう、bot に検索させよう

13. Blueprints で探してみる !13 • Lambda 作成の強い味方 • 100 種類超のテンプレート •

    Slash commands の応答として slack-echo-command-python をベースに 検索 API を実行 • kmsEncryptedToken の設定で アクセスを制御しましょう

14. 社内事例 2: 秘密情報の管理 !14 • 目的: 各環境の秘密の情報の安全な管理 • 条件: •

    MUST: 権限 のある人のみが閲覧を許可される • MUST: 変更した人と時間が 履歴に残る • SHOULD: プロジェクトごとの集約管理 • MAY: 機械（CFn / CLI）からも人間からも扱いやすい • MAY: 安い

15. binxio/cfn-secret-provider !15 • 明確なゴールが事前に決まれば OSS にも有用な情報は豊富！ • 選んだのは cfn-secret-provider •

    なんと先ほどの条件をほぼ満たす • CFn ベースの解決策を採ったのは 社内の歴史的背景あってのこと

16. supinf/secrets-provider（非公開） !16 • DB パスワード、RSA 証明書、API キーなどを保管する機能群 • AWS アカウントごとに一つ、CFn

    スタックを作成 • binxio/cfn-secret-provider とは思想が異なるため PR せず • 社内の 運用手順 や既存資産に合わせたもの • OSS に極力追従しやすいよう変更は最小限 • IAM ユーザ・権限、KMS の鍵管理

17. 余談: GitHub の歩き方 !17 • awesome-xxx といったまとめリポジトリ • サーバーレスありきの課題解決は滅びればいいと思いつつ •

    調査段階では awesome-serverless などで探すのは有用 • aws / awslabs / aws-samples の散策も有意義 • firebase / GoogleCloudPlatform / GoogleContainerTools

18. 社内事例 3: 関係者用確認サイトのアクセス制御 !18 • 目的: 検収などで使うサイトのアクセス制御 • 条件: •

    MUST: 納品物への IP アドレス制限（後から変更できること） • SHOULD: Basic 認証、API キーによる制限もできる • SHOULD: インフラ含め バージョン管理 できること • MAY: 静的ファイルが対象でも同じアーキテクチャが使える • MAY: 安い

19. AWS Lambda@Edge !19 • AWS の CDN、CloudFront 上で 動作する Lambda

    関数 • 先の条件を全て満たしていた • S3 上でも OK なのは嬉しい • 検証用のアクセス頻度なら 　 コストも気にならない

20. AWS Lambda@Edge 利用例 !20 • git 管理、CI / CD パイプラインでファイアウォールが変更できる

    • 環境変数が使えない不自由など、諸事情あり SAM ではなく 通常の CloudFormation スタックとしてデプロイ • すべてレビューされ、バージョン管理される安心感 • おまけ 1: CloudFront 各種機能を本番想定で設定、利用できる • おまけ 2: ’/’ への要求に ‘/index.html’ のコンテンツを返せる

21. 社内事例についてのまとめ !21 • 開発目線での大規模な本番導入には慎重に、運用とても大切 • 導入する場合も、ちゃんと 運用できるできる形 で！！ • 公式テンプレートや

    OSS で利用できるものは積極的に活用 • AWS のマネージドサービスの理解もとても大切

22. 一般的な開発プロセスと、よくある課題 !22

23. 運用プロセスも改善したいですよね、もちろん !23

24. 開発プロセス !24 開発 CI リリース 運用 情報収集

25. 開発プロセス !25 開発 CI リリース 運用 情報収集 情報共有 あれどこだっけ？ スケジュール

    誰が何してる？ 各種試験 テストが増えて 時間かかりすぎ・・ 秘密情報の管理 ステータス 状況の通知 死活監視 メトリクス 収集

26. 開発現場に効く Try を考える !26 • もちろん、技術以外で解決すべき課題はたくさんある、が • 繰り返される課題 は技術的に解決する（できないか考える） •

    ツールを最初に思い浮かべない努力 • 安易に自作しようとしない • 新技術を研究する時間は 別途とり、かつ 成果は義務付けない

27. GitHub おもしろサーバーレスプロジェクト集 〜 Lambda でできることの発想を広げる 〜 !27

28. toricls/pingbot !28 Lambda による定期的な HTTP(S) ヘルスチェッカー

29. ks888/LambStatus !29 Lambda による管理者サイト付きステータスページ

30. lambci/lambci !30 多言語に対応し、Slack 連携した Lambda で動く CI ツール

31. prismagraphql/chromeless !31 ブラウザテストを Lambda で！ヘッドレス Chrome

32. prismagraphql/chromeless !32 ブラウザテストを Lambda で！ヘッドレス Chrome • API Gateway と

    API キーを使ってアクセス元を制御 • レンダリング結果をスクレイピングして JSON を返すのも S3 に スクリーンショット を保存するのもかんたん • CI からわざわざ Lambda にテストを委譲する？ • テストコードのみやすさ と並列実行のメリットを天秤に • ローカルからも実行しやすいというよさはある

33. grycap/scar !33 Lambda で Docker イメージを実行！！選択肢を広げよう なにこれ ちょっと キモい

34. grycap/scar !34 Lambda で Docker イメージを実行！！選択肢を広げよう • 制約を乗り越えれば大抵のものが Lambda で動かせるという期待

    • 当然、圧縮 + 展開イメージサイズ 512 MB 以内 & 実行 5 分 以内 • 内部的には Fakeroot が利用されているため glibc 必須 .. ≒ udocker ベースなので Alpine Linux は動かない

35. 明日から始まる λ の運用 !35

36. 運用のためのヒント !36 • 関連リソースを含め SAM で定義、CI/CD パイプラインを組む • git 以外から更新しない、IAM

    ユーザに権限を与えない • CloudWatch Metrics • Errors, Duration, Throttles, .. • 導入する機能の 特性に応じて Alarm を設定 • CloudWatch Logs メトリクスフィルター • ログから異常などが検知できるものには Alarm を設定

37. 社内からの声 !37 • 最近「それサーバーレスにした理由は？」とよく聞きます • API Gateway / Cognito 拡張は

    学習・運用コスト を考慮すべき • 通常のサーバーサイドでの実装との比較、慎重に • Lambda がなくても最近 SAM で CFn デプロイしてます（SAM 賞賛） • ChangeSets が考慮される & create / update の概念がなく簡素 • 過激派が自由に仕事をしていた弊社、採用中ですよ？

38. 次回予告 !38

39. !39 サーバーフル 13:00 - 13:45 E ルーム

40. ご静聴ありがとうございました 参考文献： • A CloudFormation custom resource provider for deploying

    secrets and keys https://github.com/binxio/cfn-secret-provider • Using the AWS Serverless Application Model (AWS SAM) https://docs.aws.amazon.com/lambda/latest/dg/serverless_app.html • AWS Lambda のメトリクスおよびディメンション https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/lam- metricscollected.html