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

893d85f170f55366735566c538f21c31?s=47 ぷぽ
March 27, 2019

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

「AWS Serverless Tech/事例セミナー - サーバーレスで Ruby 他、いろんな言語が使えるよ」で登壇した内容です。

893d85f170f55366735566c538f21c31?s=128

ぷぽ

March 27, 2019
Tweet

Transcript

  1. Ruby on Lambdaで
 はじめるServerless 2019-03-27(水)
 AWS Serverless Tech/事例セミナー
 
 株式会社ヴァル研究所

    福本江梨奈 \手段先行でも悪くはない/
  2. None
  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. None
  10. ❖ 会社・チーム概要 ❖ なぜ Ruby on Lambda ? ❖ 検討

    / 導入事例 ❖ 今後の展望 ❖ まとめ アジェンダ
  11. コンシューマー向けWebアプリ担当 インフラ〜フロントまでなんでもやる
 フルなんちゃらエンジニア
 自己紹介 福本 江梨奈
 @pupupopo88 
 
 Rubyという言語とコミュニティが大すき


    
 インフラ周りは四苦八苦しつつ勉強中...
  12. ձࣾ / νʔϜ֓ཁ

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

  14. MSDOS版
 駅すぱあと

  15. Web App

  16. カレンダーに予定を
 入れるだけ!

  17. ❖ 創業:1976年 ❖ 従業員:160名弱(エンジニアは4割ほど) ❖ メイン商材:駅すぱあと ❖ 開発言語はサービスによってバラバラ ❖ ここ数年の新人研修ではRubyを導入しているた

    め、若い人は多少触れる…はず ヴァル研究所
  18. ❖ 駅すぱあとに関連した、コンシューマ向けのサー ビスを開発運用 ❖ iOSアプリ、Androidアプリ、Webアプリ…etc 所属チーム

  19. Web App さっきのこれとか

  20. ❖ 駅すぱあとに関連した、コンシューマ向けのサー ビスを開発運用 ❖ iOSアプリ、Androidアプリ、Webアプリ…etc ❖ リーダー + メンバー9人 ❖

    iOS / Android / Web でなんとなくな班わけ 所属チーム
  21. ❖ 所属チーム(Web商材)のメイン言語がRuby ❖ Rails(5.2以上)、Sinatra、時々Java… なぜ Ruby on Lambda?

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

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

  24. ❖ 所属チーム(Web商材)のメイン言語がRuby ❖ Rails(5.2以上)、Sinatra、時々Java… ❖ リーダーがRubyすき ❖ 私もすき なぜ Ruby

    on Lambda?
  25. ❖ 所属チーム(Web商材)のメイン言語がRuby ❖ Rails(5.2以上)、Sinatra、時々Java… ❖ リーダーがRubyすき ❖ 私もすき ❖ 好き大事!!!

    →チームではRuby on Lambdaを推奨していく方針 なぜ Ruby on Lambda?
  26. ところで

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

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

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

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

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

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

    →他の言語を触ってみるのは良いこと
  33. でもこれからは…!

  34. ݕ౼ࣄྫ

  35. όοναʔόͷ
 ஔ͖׵͑

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

  37. まだまだ運用中…

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

  39. 保存 アプリケーションで
 使用するデータを取得
 (JSONとか)

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

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

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

  43. 例えば

  44. データ取得 データ保存

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

  46. 試してみた…

  47. しかし問題が…

  48. ❖ Rubyの外部ライブラリ(Gem)はnative extensions
 (libxml2とか)を利用しているものがある ❖ 有名どころ:nokogiri, mysql, pgなど… native extensions

    問題 よくある「nokogiriインストールできない問題」
 はだいたいこの辺が原因
  49. ❖ 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/
  50. ざっくりいうと

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

  52. それだけじゃない…

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

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

  55. ❖ 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の相性問題
  56. None
  57. ❖ サーバをなくしたい、管理をラクにしたいという目的 に逆行する ❖ 依存しているnative extensionsをインストールし たLambdaコンテナを別途管理する…? ❖ Function数が多くバッチ処理の間隔も短いため、
 RDSのconnection数、DBの移行コストを考えると


    あまり現実的ではない ❖ DBの問題が解決できず、全バッチを移行できない (サーバが残る)ため旨味が少ない… 移行は見送り
  58. όοναʔόͷ
 ஔ͖׵͑ อ ཹ

  59. ؆қAPIαʔόͷ
 ஔ͖׵͑

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

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

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

  63. ❖ ガラケー用Webアプリにて、一部のコンテンツペー ジを表示する際に利用 ❖ memcachedからデータを引っ張ってきて、
 JSONで返す ❖ Ruby(Sinatra)製 ❖ ほぼメンテされてなかったので


    アップデートとかもしたかった… どんなAPIサーバ?
  64. ❖ API Gateway + Lambdaで実現できそう ❖ 既に他言語での事例がたくさんあるのでRuby だっていけるはず! ❖ エンドポイントもかなり少ない、アクセスも少な

    いのでAPI Gateway + Lambda向き! そのまま移行できそう!
  65. つまり

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

  67. 具体的に検討してみた…

  68. ⁉ けど…

  69. そもそもこの機能自体
 いらない!!!!
 (ということに気がついた)

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

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

    かろうじて残る機能も、別サーバから直接データ を取得できることが判明 ❖ アクセス負荷も(今は)あまり心配いらない どうして?
  72. 全体図

  73. これは不要 これ使うので

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

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

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

    \これが本当のServerless/
  78. ؆қAPIαʔόͷ
 ஔ͖׵͑ อ ཹ

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

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

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

  82. ❖ 持っている商材が多く、リポジトリ数も膨大 ❖ 比較的モダンなものから、あまり触れたことの ないものまで… ❖ TeamIDと紐づいているリポジトリだけでも45… ❖ プルリクを出しても気付かれない、忘れられる、 (最悪数年後closeされる)ってことがあった

    ❖ (当時は)Lambda + Pythonの学習 作った元々の背景
  83. ❖ (前述の)メンテ問題 ❖ ずっと直したいバグがあった&Rubyならやる気が 上がる Ruby移行の背景

  84. ❖ (前述の)メンテ問題 ❖ ずっと直したいバグがあった&Rubyならやる気が 上がる ❖ このイベント ❖ むしゃくしゃしたので意地でもRuby on

    Lambda 使いたかった Ruby移行の背景
  85. ❖ CloudWatch Events ❖ Ruby on Lambda ❖ GitHub API

    v3 ❖ Slack API(& Incoming WebHooks) 構成
  86. ϓϧϦΫ͓஌Βͤbotͷ
 ஔ͖׵͑ Ҡ ߦ ׬ ྃʂ

  87. ❖ 感覚で使える、便利機能・メソッドが豊富 ❖ each周りとか、.digとか、&.とか、とにかくデー タが扱いやすい ❖ Rubyの標準機能のみで完結することができたため、 bundle installの必要もなくメンテがラク ❖

    ローカル環境でDebugしやすい ❖ あんなこともできそう、こんなこともしたい!と
 機能が充実してくる(モチベが上がる) 移行してよかったところ
  88. 通知除外するパターン設定

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

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

  91. そういえば…

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

  93. Pythonより遅くなっ…た 34.4 sec

  94. だ…ろ……、えっ? 23.8 sec

  95. さすがにLayersは…、えっ? 25.2 sec

  96. ❖ Pythonで書いたコードがかなりだった可能性 ❖ 45リポジトリのプルリク取得してるので
 ちょっとの差が響いてくる ❖ Pythonで書いたやつの方が単純な作りだったはず… Pythonも内部ライブラリだけで書いてたけど… ❖ 気持ちが通じた(???)

    ❖ ちなみにどっちもウォームスタートでVPC外 なぜ早くなった???
  97. ޷͖ɾಘҙ͸ਖ਼ٛʂ \よくわからないけど/

  98. ❖ Slackでの発言内容に反応して情報を取得する ❖ API Gateway + Lambda + Slack Bot

    ❖ 「締め切り間近のプルリクは?」とか挑戦中… ❖ 通知対象条件の充実 ❖ 今はタイトルとリポジトリ名のみ まだまだ拡張の余地
  99. ࠓޙͷల๬

  100. ݕ౼͍ͨ͜͠ͱ

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


    スクリプトの移行
  102. ユーザー登録 ワンタイム
 token保存とか メール送信 受信メールの情報と突合
 その後の処理へ

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

  104. ❖ (Rubyに限らず)本番稼働している環境が少ない、変更もそ う多くないため、管理・運用の最適化まで行き届いていない ❖ 正直今は手動でzipで固めてコンソール上からアップする ことがほとんど(やっててもshellくらい) ❖ samも触ってみたけど個人的にあまりしっくりこなかった
 →今持っているものからすると機能過多に感じた ❖

    GitHubのリポジトリ数を圧迫するし…で、
 Lambda関連のリポジトリを一つにまとめてしまってる ❖ Ruby, Pythonごちゃ混ぜ、商材ごちゃ混ぜ 悩みどころ:管理・運用
  105. ぜひ知見ください✋

  106. ·ͱΊ

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

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

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

    と厳しいかも… ここが大変Ruby on Lambda
  110. 手段先行でも悪くはない ❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に

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

  112. こんなに
 潰せた

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

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

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

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

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


    手段先行でも悪くはない
  118. 使う フィードバック サービス改善 ユーザ増える
 知見集まる

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

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


    →AWS様も我々ユーザーも明るい未来へ!!! 手段先行でも悪くはない ただし、Lambdaを使うこと自体をゴールにしない
 (学習自体が目的だったらよいと思います)
  121. ❖ いきなり「さぁServerlessだ!」と意気込んで
 やっていくと怪我するかも ❖ 学習コストはもちろん、「言語」「全体構成」 「管理」「デプロイ方法」などなど、考えなけ ればいけないことは結構多い ❖ まず、小さな機能からやってみて感覚をつかむ ❖

    運用改善したいところから少しずつ組んだり置き 換えを検討すると、思わぬ副次効果もあってよい 小さく始めるのがオススメ
  122. タイトルテキスト ͓·͚

  123. ❖ Lambda用のコンテナを使いやすくする何か? ❖ 特にRuby2.6でbundlerが標準になったので、同 等環境でのGemインストールがしやすくなるの では? ❖ 最低限メジャーなGemが使えるコンテナを指定 できるとか ❖

    Aurora移行しなくても…そのままLambdaが使いや すく…なれば…(わがまま AWS様へのお願い