手段先行でも悪くはない！Ruby on Lambdaで はじめるServerless / aws serverless tech

Slide 1

Slide 1 text

Ruby on Lambdaで  はじめるServerless 2019-03-27（水）  AWS Serverless Tech/事例セミナー    株式会社ヴァル研究所福本江梨奈＼手段先行でも悪くはない／

Slide 2

Slide 2 text

？

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

❖ 会社・チーム概要 ❖ なぜ Ruby on Lambda ? ❖ 検討 / 導入事例 ❖ 今後の展望 ❖ まとめアジェンダ

Slide 12

Slide 12 text

コンシューマー向けWebアプリ担当インフラ〜フロントまでなんでもやる  フルなんちゃらエンジニア  自己紹介福本江梨奈  @pupupopo88     Rubyという言語とコミュニティが大すき    インフラ周りは四苦八苦しつつ勉強中...

Slide 13

Slide 13 text

ձࣾ / νʔϜ֓ཁ

Slide 14

Slide 14 text

❖ 創業：1976年 ❖ 従業員：160名弱 ❖ メイン商材：駅すぱあとヴァル研究所

Slide 15

Slide 15 text

MSDOS版  駅すぱあと

Slide 16

Slide 16 text

Web App

Slide 17

Slide 17 text

カレンダーに予定を  入れるだけ！

Slide 18

Slide 18 text

❖ 創業：1976年 ❖ 従業員：160名弱（エンジニアは4割ほど） ❖ メイン商材：駅すぱあと ❖ 開発言語はサービスによってバラバラ ❖ ここ数年の新人研修ではRubyを導入しているため、若い人は多少触れる…はずヴァル研究所

Slide 19

Slide 19 text

❖ 駅すぱあとに関連した、コンシューマ向けのサービスを開発運用 ❖ iOSアプリ、Androidアプリ、Webアプリ…etc 所属チーム

Slide 20

Slide 20 text

Web App さっきのこれとか

Slide 21

Slide 21 text

❖ 駅すぱあとに関連した、コンシューマ向けのサービスを開発運用 ❖ iOSアプリ、Androidアプリ、Webアプリ…etc ❖ リーダー + メンバー9人 ❖ iOS / Android / Web でなんとなくな班わけ所属チーム

Slide 22

Slide 22 text

❖ 所属チーム（Web商材）のメイン言語がRuby ❖ Rails（5.2以上）、Sinatra、時々Java… なぜ Ruby on Lambda?

Slide 23

Slide 23 text

❖ 所属チーム（Web商材）のメイン言語がRuby ❖ Rails（5.2以上）、Sinatra、時々Java… ❖ リーダーがRubyすきなぜ Ruby on Lambda?

Slide 24

Slide 24 text

❖ 所属チーム（Web商材）のメイン言語がRuby ❖ Rails（5.2以上）、Sinatra、時々Java… ❖ リーダーがRubyすきなぜ Ruby on Lambda?

Slide 25

Slide 25 text

❖ 所属チーム（Web商材）のメイン言語がRuby ❖ Rails（5.2以上）、Sinatra、時々Java… ❖ リーダーがRubyすき ❖ 私もすきなぜ Ruby on Lambda?

Slide 26

Slide 26 text

❖ 所属チーム（Web商材）のメイン言語がRuby ❖ Rails（5.2以上）、Sinatra、時々Java… ❖ リーダーがRubyすき ❖ 私もすき ❖ 好き大事！！！ →チームではRuby on Lambdaを推奨していく方針なぜ Ruby on Lambda?

Slide 27

Slide 27 text

ところで

Slide 28

Slide 28 text

ਓ͸ͳͥɺ4FSWFSMFTTΛ  ໨ࢦ͢ͷ͔ʜ

Slide 29

Slide 29 text

https://aws.amazon.com/serverless/?nc1=h_ls

Slide 30

Slide 30 text

❖サーバーの管理が不要 ❖柔軟性のあるスケーリング ❖価値に対する支払い ❖高可用性の自動化

Slide 31

Slide 31 text

❖サーバーの管理が不要 ❖柔軟性のあるスケーリング ❖価値に対する支払い ❖高可用性の自動化

Slide 32

Slide 32 text

ʘ൥Θ͔͠͞Βղ์͞Ε͍ͨʗ

Slide 33

Slide 33 text

❖ (誰も)慣れていない言語で書かれているとメンテが大変 ❖ そもそもコードレビューも満足にできない ❖ リファクタリングする気が起きない ❖ いざメンテが発生した時に時間がかかるつらかったPython 学習きっかけにはなった →他の言語を触ってみるのは良いこと

Slide 34

Slide 34 text

でもこれからは…！

Slide 35

Slide 35 text

ݕ౼ࣄྫ

Slide 36

Slide 36 text

όοναʔόͷ  ஔ͖׵͑

Slide 37

Slide 37 text

❖ ガラケーおよび、スマホのキャリア公式サービスの様々なバッチ処理を雑多に詰め込んだ闇鍋…  もとい闇サーバどんなバッチサーバ？

Slide 38

Slide 38 text

まだまだ運用中…

Slide 39

Slide 39 text

❖ ガラケーおよび、スマホのキャリア公式サービスの様々なバッチ処理を雑多に詰め込んだ闇鍋…  もとい闇サーバ ❖ 全体把握している人は…？→メンテ難しい ❖ 中身は全てRubyのスクリプトで、cronで定期的に実行しているどんなバッチサーバ？

Slide 40

Slide 40 text

保存アプリケーションで  使用するデータを取得  （JSONとか）

Slide 41

Slide 41 text

データ取得集計データを  メールで飛ばす

Slide 42

Slide 42 text

アプリケーションで  使用するデータを取得保存

Slide 43

Slide 43 text

❖ （バージョンの違いはあれど）  元がRubyのスクリプトだからそのまま使えそう ❖ CloudWatch Eventsでcron実行できる ❖ バッチ処理のLambda化はこれまでも事例があり情報は豊富そうそのまま移行できそう！

Slide 44

Slide 44 text

例えば

Slide 45

Slide 45 text

データ取得データ保存

Slide 46

Slide 46 text

CloudWatch Events  (cron設定できる！) データ取得データ保存

Slide 47

Slide 47 text

試してみた…

Slide 48

Slide 48 text

しかし問題が…

Slide 49

Slide 49 text

❖ Rubyの外部ライブラリ(Gem)はnative extensions  (libxml2とか)を利用しているものがある ❖ 有名どころ：nokogiri, mysql, pgなど… native extensions 問題よくある「nokogiriインストールできない問題」  はだいたいこの辺が原因

Slide 50

Slide 50 text

❖ Rubyの外部ライブラリ(Gem)はnative extensions  (libxml2とか)を利用しているものがある ❖ 有名どころ：nokogiri, mysql, pgなど… ❖ これらのGemを利用するには、  実際に利用する環境と同等の環境でinstallする必要がある ❖ OSSでLambda用のDockerコンテナが提供されているのでそちらを活用すると良さそう native extensions 問題参考：https://www.stevenringo.com/ruby-in-aws-lambda-with-postgresql-nokogiri/

Slide 51

Slide 51 text

ざっくりいうと

Slide 52

Slide 52 text

lambci/lambda:build-ruby2.5 install bundle install deploy 場合によってはこいつを  別途個別管理したり…

Slide 53

Slide 53 text

それだけじゃない…

Slide 54

Slide 54 text

RDBMSとLambdaの相性問題 ❖ Functionごと（コンテナごと）にDBへのコネクションが張られるため、負荷増加やコスト増加になる    参考：https://www.keisuke69.net/entry/2017/06/21/121501

Slide 55

Slide 55 text

コネクション  使い回せない…！一月間隔！一日間隔！十分間隔！一分間隔！！

Slide 56

Slide 56 text

❖ Functionごと（コンテナごと）にDBへのコネクションが張られるため、負荷増加やコスト増加になる    参考：https://www.keisuke69.net/entry/2017/06/21/121501 ❖ LambdaからDBに接続するための中間層作る…？ ❖ AWS Aurora Serverlessならいけるみたいだけど、 PostgreSQLから移行…する…？ https://dev.classmethod.jp/cloud/aws/amazon-aurora-serverless-avaible-http-endpoint/ RDBMSとLambdaの相性問題

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

❖ サーバをなくしたい、管理をラクにしたいという目的に逆行する ❖ 依存しているnative extensionsをインストールしたLambdaコンテナを別途管理する…？ ❖ Function数が多くバッチ処理の間隔も短いため、  RDSのconnection数、DBの移行コストを考えると  あまり現実的ではない ❖ DBの問題が解決できず、全バッチを移行できない（サーバが残る）ため旨味が少ない… 移行は見送り

Slide 59

Slide 59 text

όοναʔόͷ  ஔ͖׵͑ อ ཹ

Slide 60

Slide 60 text

؆қAPIαʔόͷ  ஔ͖׵͑

Slide 61

Slide 61 text

❖ ガラケー用Webアプリにて、一部のコンテンツページを表示する際に利用どんなAPIサーバ?

Slide 62

Slide 62 text

例えば：My天気情報自分が登録した地域の  週間天気が表示される

Slide 63

Slide 63 text

APIアクセスデータ取得ページアクセス

Slide 64

Slide 64 text

❖ ガラケー用Webアプリにて、一部のコンテンツページを表示する際に利用 ❖ memcachedからデータを引っ張ってきて、  JSONで返す ❖ Ruby（Sinatra）製 ❖ ほぼメンテされてなかったので  アップデートとかもしたかった… どんなAPIサーバ?

Slide 65

Slide 65 text

❖ API Gateway ＋ Lambdaで実現できそう ❖ 既に他言語での事例がたくさんあるのでRuby だっていけるはず！ ❖ エンドポイントもかなり少ない、アクセスも少ないのでAPI Gateway + Lambda向き！そのまま移行できそう！

Slide 66

Slide 66 text

つまり

Slide 67

Slide 67 text

ページアクセス APIアクセスデータ取得

Slide 68

Slide 68 text

具体的に検討してみた…

Slide 69

Slide 69 text

⁉ けど…

Slide 70

Slide 70 text

そもそもこの機能自体  いらない！！！！  （ということに気がついた）

Slide 71

Slide 71 text

❖ 利用者数 vs 運用コストの関係で、ガラケーサイトのコンテンツ自体少しずつCloseしていってた ❖ 占い、晩御飯のレシピ、鉄道画像コーナー… ❖ APIサーバが担う部分が減ってきたどうして？

Slide 72

Slide 72 text

❖ 利用者数 vs 運用コストの関係で、ガラケーサイトのコンテンツ自体少しずつCloseしていってた ❖ 占い、晩御飯のレシピ、鉄道画像コーナー… ❖ APIサーバが担う部分が減ってきた ❖ かろうじて残る機能も、別サーバから直接データを取得できることが判明 ❖ アクセス負荷も（今は）あまり心配いらないどうして？

Slide 73

Slide 73 text

全体図

Slide 74

Slide 74 text

これは不要これ使うので

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

❖ サーバ（コンテンツデータAPI）そのものを無くそうという方向に ❖ Lambdaを使いたいがために、不要なものをそのままにしておく or 新しい環境をつくるなど言語道断移行は見送り

Slide 77

Slide 77 text

❖ サーバ（コンテンツデータAPI）そのものを無くそうという方向に ❖ Lambdaを使いたいがために、不要なものをそのままにしておく or 新しい環境をつくるなど言語道断移行は見送り＼これが本当のServerless／

Slide 78

Slide 78 text

Slide 79

Slide 79 text

؆қAPIαʔόͷ  ஔ͖׵͑ อ ཹ

Slide 80

Slide 80 text

ϓϧϦΫ͓஌Βͤbotͷ  ஔ͖׵͑

Slide 81

Slide 81 text

❖ 会社全体のコミュニケーションツールとしてSlack を利用中 ❖ 朝会（10:00）前に、プルリクが出ているものをチームのチャンネルにお知らせどんなbot？

Slide 82

Slide 82 text

締切近いのをピックアップ  してくれたりもパッと分かるよう  タイトルに日付入れる運用

Slide 83

Slide 83 text

❖ 持っている商材が多く、リポジトリ数も膨大 ❖ 比較的モダンなものから、あまり触れたことのないものまで… ❖ TeamIDと紐づいているリポジトリだけでも45… ❖ プルリクを出しても気付かれない、忘れられる、（最悪数年後closeされる）ってことがあった ❖ （当時は）Lambda + Pythonの学習作った元々の背景

Slide 84

Slide 84 text

❖ （前述の）メンテ問題 ❖ ずっと直したいバグがあった&Rubyならやる気が上がる Ruby移行の背景

Slide 85

Slide 85 text

❖ （前述の）メンテ問題 ❖ ずっと直したいバグがあった&Rubyならやる気が上がる ❖ このイベント ❖ むしゃくしゃしたので意地でもRuby on Lambda 使いたかった Ruby移行の背景

Slide 86

Slide 86 text

❖ CloudWatch Events ❖ Ruby on Lambda ❖ GitHub API v3 ❖ Slack API（& Incoming WebHooks）構成

Slide 87

Slide 87 text

ϓϧϦΫ͓஌Βͤbotͷ  ஔ͖׵͑ Ҡ ߦ ׬ ྃʂ

Slide 88

Slide 88 text

❖ 感覚で使える、便利機能・メソッドが豊富 ❖ each周りとか、.digとか、&.とか、とにかくデータが扱いやすい ❖ Rubyの標準機能のみで完結することができたため、 bundle installの必要もなくメンテがラク ❖ ローカル環境でDebugしやすい ❖ あんなこともできそう、こんなこともしたい！と  機能が充実してくる（モチベが上がる）移行してよかったところ

Slide 89

Slide 89 text

通知除外するパターン設定

Slide 90

Slide 90 text

好きなメッセージを付与デフォルトはメッセージなし  アイコンと合わせて自分好みのbotに…！

Slide 91

Slide 91 text

Layersに設定してみたり最低限の設定で  誰でも利用可能！ https://github.com/pupupopo88/pr_slack_notifier

Slide 92

Slide 92 text

そういえば…

Slide 93

Slide 93 text

Ruby遅いとか言う人もいるし  高機能にもなったし

Slide 94

Slide 94 text

Pythonより遅くなっ…た 34.4 sec

Slide 95

Slide 95 text

だ…ろ……、えっ？ 23.8 sec

Slide 96

Slide 96 text

さすがにLayersは…、えっ？ 25.2 sec

Slide 97

Slide 97 text

❖ Pythonで書いたコードがかなりだった可能性 ❖ 45リポジトリのプルリク取得してるので  ちょっとの差が響いてくる ❖ Pythonで書いたやつの方が単純な作りだったはず… Pythonも内部ライブラリだけで書いてたけど… ❖ 気持ちが通じた（？？？） ❖ ちなみにどっちもウォームスタートでVPC外なぜ早くなった？？？

Slide 98

Slide 98 text

޷͖ɾಘҙ͸ਖ਼ٛʂ ＼よくわからないけど／

Slide 99

Slide 99 text

❖ Slackでの発言内容に反応して情報を取得する ❖ API Gateway + Lambda + Slack Bot ❖ 「締め切り間近のプルリクは？」とか挑戦中… ❖ 通知対象条件の充実 ❖ 今はタイトルとリポジトリ名のみまだまだ拡張の余地

Slide 100

Slide 100 text

ࠓޙͷల๬

Slide 101

Slide 101 text

ݕ౼͍ͨ͜͠ͱ

Slide 102

Slide 102 text

❖ ガラケーやスマホ公式サイトのユーザー登録で利用 ❖ 元々メールサーバだったものを  Lambda（Python）＋SendGridで置き換えた ❖ これを作り終わったくらいでRubyが… ❖ 同じくメンテがしづらい… ユーザ登録用空メール送信  スクリプトの移行

Slide 103

Slide 103 text

ユーザー登録ワンタイム  token保存とかメール送信受信メールの情報と突合  その後の処理へ

Slide 104

Slide 104 text

ΑΓϥΫͳӡ༻Λ  ໨ࢦͯ͠

Slide 105

Slide 105 text

❖ （Rubyに限らず）本番稼働している環境が少ない、変更もそう多くないため、管理・運用の最適化まで行き届いていない ❖ 正直今は手動でzipで固めてコンソール上からアップすることがほとんど（やっててもshellくらい） ❖ samも触ってみたけど個人的にあまりしっくりこなかった  →今持っているものからすると機能過多に感じた ❖ GitHubのリポジトリ数を圧迫するし…で、  Lambda関連のリポジトリを一つにまとめてしまってる ❖ Ruby, Pythonごちゃ混ぜ、商材ごちゃ混ぜ悩みどころ：管理・運用

Slide 106

Slide 106 text

ぜひ知見ください✋

Slide 107

Slide 107 text

·ͱΊ

Slide 108

Slide 108 text

❖ 簡単な処理であればすぐ書ける ❖ 便利な機能が標準で備わっており、データの取り回しがしやすい ❖ Debugしやすい ❖ 好き・得意な言語を使うことでラクに楽しく！ Ruby on Lambdaは楽しい

Slide 109

Slide 109 text

❖ 簡単な処理であればすぐ書ける ❖ 便利な機能が標準で備わっており、データの取り回しがしやすい ❖ Debugしやすい ❖ 好き・得意な言語を使うことでラクに楽しく！ ❖ より大切なことに時間を使える！ Ruby on Lambdaは楽しい

Slide 110

Slide 110 text

❖ 使用するGemの種類によっては別途環境を用意・管理する必要がある ❖ 今後積極的に活用していく計画があればよいが、 Rubyバージョンがバラけると苦しくなりそう ❖ 使い所は分かれると思う ❖ 1秒単位に何かするくらいの速さを求められると厳しいかも… ここが大変Ruby on Lambda

Slide 111

Slide 111 text

手段先行でも悪くはない ❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に

Slide 112

Slide 112 text

ここ、そうなってたんだアーキテクチャの深い理解あれ、これいらなくない？こんなサーバがあったなんて…

Slide 113

Slide 113 text

こんなに  潰せた

Slide 114

Slide 114 text

手段先行でも悪くはない ❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に ❖ 理想の構成を考え、新サービスも知るきっかけに

Slide 115

Slide 115 text

そもそもこの作りはどうなんだ…？理想の構成を考えるきっかけ今はこんな便利な  サービスがあるのか！こうなってたらよかったのに…

Slide 116

Slide 116 text

❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に ❖ 理想の構成を考え、新サービスも知るきっかけに ❖ 運用改善、新規案件でServerlessも視野に入る手段先行でも悪くはない

Slide 117

Slide 117 text

Serverlessも視野に入るいつも通り、  インスタンス立てて… 以前あれ、これこそ  Lambdaでいいのでは… 現在

Slide 118

Slide 118 text

❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に ❖ 理想の構成を考え、新サービスも知るきっかけに ❖ 運用改善、新規案件でServerlessも視野に入るように ❖ AWS様へのフィードバックでサービス改善に  手段先行でも悪くはない

Slide 119

Slide 119 text

使うフィードバックサービス改善ユーザ増える  知見集まる

Slide 120

Slide 120 text

使うフィードバックサービス改善ユーザ増える  知見集まる Win-Win !!

Slide 121

Slide 121 text

❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に ❖ 理想の構成を考え、新サービスも知るきっかけに ❖ 運用改善、新規案件でServerlessも視野に入るように ❖ AWS様へのフィードバックでサービス改善に  →AWS様も我々ユーザーも明るい未来へ！！！手段先行でも悪くはないただし、Lambdaを使うこと自体をゴールにしない  （学習自体が目的だったらよいと思います）

Slide 122

Slide 122 text

❖ いきなり「さぁServerlessだ！」と意気込んで  やっていくと怪我するかも ❖ 学習コストはもちろん、「言語」「全体構成」「管理」「デプロイ方法」などなど、考えなければいけないことは結構多い ❖ まず、小さな機能からやってみて感覚をつかむ ❖ 運用改善したいところから少しずつ組んだり置き換えを検討すると、思わぬ副次効果もあってよい小さく始めるのがオススメ

Slide 123

Slide 123 text

タイトルテキスト ͓·͚

Slide 124

Slide 124 text

❖ Lambda用のコンテナを使いやすくする何か？ ❖ 特にRuby2.6でbundlerが標準になったので、同等環境でのGemインストールがしやすくなるのでは？ ❖ 最低限メジャーなGemが使えるコンテナを指定できるとか ❖ Aurora移行しなくても…そのままLambdaが使いやすく…なれば…（わがまま AWS様へのお願い