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

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

Transcript

1. Ruby on Lambdaで
 はじめるServerless 2019-03-27（水）
 AWS Serverless Tech/事例セミナー
 
 株式会社ヴァル研究所 福本江梨奈 ＼手段先行でも悪くはない／
2. ？
11. ❖ 会社・チーム概要 ❖ なぜ Ruby on Lambda ? ❖ 検討 / 導入事例 ❖ 今後の展望 ❖ まとめ アジェンダ
12. コンシューマー向けWebアプリ担当 インフラ〜フロントまでなんでもやる
 フルなんちゃらエンジニア
 自己紹介 福本 江梨奈
 @pupupopo88 
 
 Rubyという言語とコミュニティが大すき
 
 インフラ周りは四苦八苦しつつ勉強中...
13. ձࣾ / νʔϜ֓ཁ
14. ❖ 創業：1976年 ❖ 従業員：160名弱 ❖ メイン商材：駅すぱあと ヴァル研究所
15. MSDOS版
 駅すぱあと
16. Web App
17. カレンダーに予定を
 入れるだけ！
18. ❖ 創業：1976年 ❖ 従業員：160名弱（エンジニアは4割ほど） ❖ メイン商材：駅すぱあと ❖ 開発言語はサービスによってバラバラ ❖ ここ数年の新人研修ではRubyを導入しているた め、若い人は多少触れる…はず ヴァル研究所
19. ❖ 駅すぱあとに関連した、コンシューマ向けのサー ビスを開発運用 ❖ iOSアプリ、Androidアプリ、Webアプリ…etc 所属チーム
20. Web App さっきのこれとか
21. ❖ 駅すぱあとに関連した、コンシューマ向けのサー ビスを開発運用 ❖ iOSアプリ、Androidアプリ、Webアプリ…etc ❖ リーダー + メンバー9人 ❖ iOS / Android / Web でなんとなくな班わけ 所属チーム
22. ❖ 所属チーム（Web商材）のメイン言語がRuby ❖ Rails（5.2以上）、Sinatra、時々Java… なぜ 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?
26. ❖ 所属チーム（Web商材）のメイン言語がRuby ❖ Rails（5.2以上）、Sinatra、時々Java… ❖ リーダーがRubyすき ❖ 私もすき ❖ 好き大事！！！ →チームではRuby on Lambdaを推奨していく方針 なぜ Ruby on Lambda?
27. ところで
28. ਓ͸ͳͥɺ4FSWFSMFTTΛ
 ໨ࢦ͢ͷ͔ʜ
29. https://aws.amazon.com/serverless/?nc1=h_ls
30. ❖サーバーの管理が不要 ❖柔軟性のあるスケーリング ❖価値に対する支払い ❖高可用性の自動化
31. ❖サーバーの管理が不要 ❖柔軟性のあるスケーリング ❖価値に対する支払い ❖高可用性の自動化
32. ʘ൥Θ͔͠͞Βղ์͞Ε͍ͨʗ
33. ❖ (誰も)慣れていない言語で書かれているとメンテが大変 ❖ そもそもコードレビューも満足にできない ❖ リファクタリングする気が起きない ❖ いざメンテが発生した時に時間がかかる つらかったPython 学習きっかけにはなった →他の言語を触ってみるのは良いこと
34. でもこれからは…！
35. ݕ౼ࣄྫ
36. όοναʔόͷ
 ஔ͖׵͑
37. ❖ ガラケーおよび、スマホのキャリア公式サービス の様々なバッチ処理を雑多に詰め込んだ闇鍋…
 もとい闇サーバ どんなバッチサーバ？
38. まだまだ運用中…
39. ❖ ガラケーおよび、スマホのキャリア公式サービス の様々なバッチ処理を雑多に詰め込んだ闇鍋…
 もとい闇サーバ ❖ 全体把握している人は…？→メンテ難しい ❖ 中身は全てRubyのスクリプトで、cronで定期的に 実行している どんなバッチサーバ？
40. 保存 アプリケーションで
 使用するデータを取得
 （JSONとか）
41. データ取得 集計データを
 メールで飛ばす
42. アプリケーションで
 使用するデータを取得 保存
43. ❖ （バージョンの違いはあれど）
 元がRubyのスクリプトだからそのまま使えそう ❖ CloudWatch Eventsでcron実行できる ❖ バッチ処理のLambda化はこれまでも事例があ り情報は豊富そう そのまま移行できそう！
44. 例えば
45. データ取得 データ保存
46. CloudWatch Events
 (cron設定できる！) データ取得 データ保存
47. 試してみた…
48. しかし問題が…
49. ❖ Rubyの外部ライブラリ(Gem)はnative extensions
 (libxml2とか)を利用しているものがある ❖ 有名どころ：nokogiri, mysql, pgなど… native extensions 問題 よくある「nokogiriインストールできない問題」
 はだいたいこの辺が原因
50. ❖ 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/
51. ざっくりいうと
52. lambci/lambda:build-ruby2.5 install bundle install deploy 場合によってはこいつを
 別途個別管理したり…
53. それだけじゃない…
54. RDBMSとLambdaの相性問題 ❖ Functionごと（コンテナごと）にDBへのコネクショ ンが張られるため、負荷増加やコスト増加になる
 
 参考：https://www.keisuke69.net/entry/2017/06/21/121501
55. コネクション
 使い回せない…！ 一月間隔！ 一日間隔！ 十分間隔！ 一分間隔！！
56. ❖ 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の相性問題
58. ❖ サーバをなくしたい、管理をラクにしたいという目的 に逆行する ❖ 依存しているnative extensionsをインストールし たLambdaコンテナを別途管理する…？ ❖ Function数が多くバッチ処理の間隔も短いため、
 RDSのconnection数、DBの移行コストを考えると
 あまり現実的ではない ❖ DBの問題が解決できず、全バッチを移行できない （サーバが残る）ため旨味が少ない… 移行は見送り
59. όοναʔόͷ
 ஔ͖׵͑ อ ཹ
60. ؆қAPIαʔόͷ
 ஔ͖׵͑
61. ❖ ガラケー用Webアプリにて、一部のコンテンツペー ジを表示する際に利用 どんなAPIサーバ?
62. 例えば：My天気情報 自分が登録した地域の
 週間天気が表示される
63. APIアクセス データ取得 ページアクセス
64. ❖ ガラケー用Webアプリにて、一部のコンテンツペー ジを表示する際に利用 ❖ memcachedからデータを引っ張ってきて、
 JSONで返す ❖ Ruby（Sinatra）製 ❖ ほぼメンテされてなかったので
 アップデートとかもしたかった… どんなAPIサーバ?
65. ❖ API Gateway ＋ Lambdaで実現できそう ❖ 既に他言語での事例がたくさんあるのでRuby だっていけるはず！ ❖ エンドポイントもかなり少ない、アクセスも少な いのでAPI Gateway + Lambda向き！ そのまま移行できそう！
66. つまり
67. ページアクセス APIアクセス データ取得
68. 具体的に検討してみた…
69. ⁉ けど…
70. そもそもこの機能自体
 いらない！！！！
 （ということに気がついた）
71. ❖ 利用者数 vs 運用コストの関係で、ガラケーサイ トのコンテンツ自体少しずつCloseしていってた ❖ 占い、晩御飯のレシピ、鉄道画像コーナー… ❖ APIサーバが担う部分が減ってきた どうして？
72. ❖ 利用者数 vs 運用コストの関係で、ガラケーサイ トのコンテンツ自体少しずつCloseしていってた ❖ 占い、晩御飯のレシピ、鉄道画像コーナー… ❖ APIサーバが担う部分が減ってきた ❖ かろうじて残る機能も、別サーバから直接データ を取得できることが判明 ❖ アクセス負荷も（今は）あまり心配いらない どうして？
73. 全体図
74. これは不要 これ使うので
76. ❖ サーバ（コンテンツデータAPI）そのものを無くそ うという方向に ❖ Lambdaを使いたいがために、不要なものをそ のままにしておく or 新しい環境をつくるなど 言語道断 移行は見送り
77. ❖ サーバ（コンテンツデータAPI）そのものを無くそ うという方向に ❖ Lambdaを使いたいがために、不要なものをそ のままにしておく or 新しい環境をつくるなど 言語道断 移行は見送り ＼これが本当のServerless／
78. ❖ サーバ（コンテンツデータAPI）そのものを無くそ うという方向に ❖ Lambdaを使いたいがために、不要なものをそ のままにしておく or 新しい環境をつくるなど 言語道断 移行は見送り ＼これが本当のServerless／
79. ؆қAPIαʔόͷ
 ஔ͖׵͑ อ ཹ
80. ϓϧϦΫ͓஌Βͤbotͷ
 ஔ͖׵͑
81. ❖ 会社全体のコミュニケーションツールとしてSlack を利用中 ❖ 朝会（10:00）前に、プルリクが出ているものを チームのチャンネルにお知らせ どんなbot？
82. 締切近いのをピックアップ
 してくれたりも パッと分かるよう
 タイトルに日付入れる運用
83. ❖ 持っている商材が多く、リポジトリ数も膨大 ❖ 比較的モダンなものから、あまり触れたことの ないものまで… ❖ TeamIDと紐づいているリポジトリだけでも45… ❖ プルリクを出しても気付かれない、忘れられる、 （最悪数年後closeされる）ってことがあった ❖ （当時は）Lambda + Pythonの学習 作った元々の背景
84. ❖ （前述の）メンテ問題 ❖ ずっと直したいバグがあった&Rubyならやる気が 上がる Ruby移行の背景
85. ❖ （前述の）メンテ問題 ❖ ずっと直したいバグがあった&Rubyならやる気が 上がる ❖ このイベント ❖ むしゃくしゃしたので意地でもRuby on Lambda 使いたかった Ruby移行の背景
86. ❖ CloudWatch Events ❖ Ruby on Lambda ❖ GitHub API v3 ❖ Slack API（& Incoming WebHooks） 構成
87. ϓϧϦΫ͓஌Βͤbotͷ
 ஔ͖׵͑ Ҡ ߦ ׬ ྃʂ
88. ❖ 感覚で使える、便利機能・メソッドが豊富 ❖ each周りとか、.digとか、&.とか、とにかくデー タが扱いやすい ❖ Rubyの標準機能のみで完結することができたため、 bundle installの必要もなくメンテがラク ❖ ローカル環境でDebugしやすい ❖ あんなこともできそう、こんなこともしたい！と
 機能が充実してくる（モチベが上がる） 移行してよかったところ
89. 通知除外するパターン設定
90. 好きなメッセージを付与 デフォルトはメッセージなし
 アイコンと合わせて自分好みのbotに…！
91. Layersに設定してみたり 最低限の設定で
 誰でも利用可能！ https://github.com/pupupopo88/pr_slack_notifier
92. そういえば…
93. Ruby遅いとか言う人もいるし
 高機能にもなったし
94. Pythonより遅くなっ…た 34.4 sec
95. だ…ろ……、えっ？ 23.8 sec
96. さすがにLayersは…、えっ？ 25.2 sec
97. ❖ Pythonで書いたコードがかなりだった可能性 ❖ 45リポジトリのプルリク取得してるので
 ちょっとの差が響いてくる ❖ Pythonで書いたやつの方が単純な作りだったはず… Pythonも内部ライブラリだけで書いてたけど… ❖ 気持ちが通じた（？？？） ❖ ちなみにどっちもウォームスタートでVPC外 なぜ早くなった？？？
98. ޷͖ɾಘҙ͸ਖ਼ٛʂ ＼よくわからないけど／
99. ❖ Slackでの発言内容に反応して情報を取得する ❖ API Gateway + Lambda + Slack Bot ❖ 「締め切り間近のプルリクは？」とか挑戦中… ❖ 通知対象条件の充実 ❖ 今はタイトルとリポジトリ名のみ まだまだ拡張の余地
100. ࠓޙͷల๬
101. ݕ౼͍ͨ͜͠ͱ
102. ❖ ガラケーやスマホ公式サイトのユーザー登録で利用 ❖ 元々メールサーバだったものを
 Lambda（Python）＋SendGridで置き換えた ❖ これを作り終わったくらいでRubyが… ❖ 同じくメンテがしづらい… ユーザ登録用空メール送信
 スクリプトの移行
103. ユーザー登録 ワンタイム
 token保存とか メール送信 受信メールの情報と突合
 その後の処理へ
104. ΑΓϥΫͳӡ༻Λ
 ໨ࢦͯ͠
105. ❖ （Rubyに限らず）本番稼働している環境が少ない、変更もそ う多くないため、管理・運用の最適化まで行き届いていない ❖ 正直今は手動でzipで固めてコンソール上からアップする ことがほとんど（やっててもshellくらい） ❖ samも触ってみたけど個人的にあまりしっくりこなかった
 →今持っているものからすると機能過多に感じた ❖ GitHubのリポジトリ数を圧迫するし…で、
 Lambda関連のリポジトリを一つにまとめてしまってる ❖ Ruby, Pythonごちゃ混ぜ、商材ごちゃ混ぜ 悩みどころ：管理・運用
106. ぜひ知見ください✋
107. ·ͱΊ
108. ❖ 簡単な処理であればすぐ書ける ❖ 便利な機能が標準で備わっており、データの取り 回しがしやすい ❖ Debugしやすい ❖ 好き・得意な言語を使うことでラクに楽しく！ Ruby on Lambdaは楽しい
109. ❖ 簡単な処理であればすぐ書ける ❖ 便利な機能が標準で備わっており、データの取り 回しがしやすい ❖ Debugしやすい ❖ 好き・得意な言語を使うことでラクに楽しく！ ❖ より大切なことに時間を使える！ Ruby on Lambdaは楽しい
110. ❖ 使用するGemの種類によっては別途環境を用意・ 管理する必要がある ❖ 今後積極的に活用していく計画があればよいが、 Rubyバージョンがバラけると苦しくなりそう ❖ 使い所は分かれると思う ❖ 1秒単位に何かするくらいの速さを求められる と厳しいかも… ここが大変Ruby on Lambda
111. 手段先行でも悪くはない ❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に
112. ここ、そうなってたんだ アーキテクチャの深い理解 あれ、これいらなくない？ こんなサーバがあったなんて…
113. こんなに
 潰せた
114. 手段先行でも悪くはない ❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に ❖ 理想の構成を考え、新サービスも知るきっかけに
115. そもそもこの作りはどうなんだ…？ 理想の構成を考えるきっかけ 今はこんな便利な
 サービスがあるのか！ こうなってたらよかったのに…
116. ❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に ❖ 理想の構成を考え、新サービスも知るきっかけに ❖ 運用改善、新規案件でServerlessも視野に入る 手段先行でも悪くはない
117. Serverlessも視野に入る いつも通り、
 インスタンス立てて… 以前 あれ、これこそ
 Lambdaでいいのでは… 現在
118. ❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に ❖ 理想の構成を考え、新サービスも知るきっかけに ❖ 運用改善、新規案件でServerlessも視野に入るように ❖ AWS様へのフィードバックでサービス改善に
 手段先行でも悪くはない
119. 使う フィードバック サービス改善 ユーザ増える
 知見集まる
120. 使う フィードバック サービス改善 ユーザ増える
 知見集まる Win-Win !!
121. ❖ 「Tryしてみたけどやめた」の積み重ねは無駄ではない ❖ 既存アーキテクチャの深い理解に ❖ 理想の構成を考え、新サービスも知るきっかけに ❖ 運用改善、新規案件でServerlessも視野に入るように ❖ AWS様へのフィードバックでサービス改善に
 →AWS様も我々ユーザーも明るい未来へ！！！ 手段先行でも悪くはない ただし、Lambdaを使うこと自体をゴールにしない
 （学習自体が目的だったらよいと思います）
122. ❖ いきなり「さぁServerlessだ！」と意気込んで
 やっていくと怪我するかも ❖ 学習コストはもちろん、「言語」「全体構成」 「管理」「デプロイ方法」などなど、考えなけ ればいけないことは結構多い ❖ まず、小さな機能からやってみて感覚をつかむ ❖ 運用改善したいところから少しずつ組んだり置き 換えを検討すると、思わぬ副次効果もあってよい 小さく始めるのがオススメ
123. タイトルテキスト ͓·͚
124. ❖ Lambda用のコンテナを使いやすくする何か？ ❖ 特にRuby2.6でbundlerが標準になったので、同 等環境でのGemインストールがしやすくなるの では？ ❖ 最低限メジャーなGemが使えるコンテナを指定 できるとか ❖ Aurora移行しなくても…そのままLambdaが使いや すく…なれば…（わがまま AWS様へのお願い