Amazon Web Services ブログ

Serverless Tech/事例セミナー（2019年3月27日 実施） レポート Vol.1

「AWS re:Invent 2018」では多くのサーバーレス関連のアナウンスがありました。その中でも、Ruby や COBOL を始めとする開発言語対応の拡張やカスタムランタイム、共有ライブラリ管理機能（Layers）は、サーバーレスの成熟と広がりを感じさせるものでした。特に、日本で利用者の多い Ruby は長い間望まれていたことから、プロジェクトでの適用が急速に進みはじめています。

そこで、すでに利用し始めていただいているお客様として、ヴァル研究所様およびSansan様に2019年3月27日に実施のServerless Tech/事例セミナーで登壇いただき、その経験を共有いただきました。開発言語としてのRubyに対する熱い想いやモチベーションが伝わる講演内容でした。また、これからサーバーレスを検討される参加者のために、従来型開発との考え方の違いを、開発の観点からクラスメソッド様より説明がありました。

 

 

手段先行でも悪くはない！Ruby on LambdaではじめるServerless [資料はこちら]

株式会社ヴァル研究所 マーケティングテクノロジー部 CB開発チーム 福本江梨奈氏

 

「好きな言語での開発じゃないとモチベーションが上がらなくて、結果、メンテされない状態になる」
「RubyがLambdaでサポートされたことで、手段先行だけど、やる気になった」

「駅すぱあと」のサービスで知られるヴァル研究所ですが、その歴史は古く、講演の冒頭で MS-DOS版 駅すぱあとの紹介がされるほど。歴史のあるサービスゆえ、いろんな言語でつくられた、全体像を把握するのが困難なシステムや処理が生き続けています。

現在は新人研修でRubyを使っており、Rubyに触れたことがある人は比較的多くいます。福本氏自身もRubyが好きで、Rubyでの開発ならモチベーションが継続するけれど、他の言語だとどうしてもメンテが億劫になってしまうのだそうです。

昨年、AWS Lambda の Ruby 対応が発表されたことがひとつのきっかけになり、手段先行ながら、適用対象となるプロジェクトの検討が始まりました。サーバーレスは「煩わしさから解放されたい」というのがいちばんのモチベーションで、サーバーの管理が不要な状況を目指したいということろからきています。

短期間のうちに4つの検討（ガラケー向けバッチ処理、既存の簡易APIサービスの置き換え、プルリクエスト用ボット機能、空メールによるユーザー登録）が行われ、結果、前者2つは適用を見送ったものの、そのうち後者2つが適用対象になりました。

 

適用見送りプロジェクトの理由

バッチ処理:
ユーザーからのアクセス負荷をキャッシュで折り返せるように、バックエンドAPやRDB、S3からデータを取得し、キャッシュに格納するという作業を定期的に実行していました。このバッチサーバーを見直してサーバーレス化できるのでは、という検討を行いました。適用検討においてネックになったのがバッチで利用しているRDBMSとのサーバーレスの相性が良くないこと。制限事項を考慮すると使用に踏み切れませんでした。またnative extensionsに依存する処理があり、その設定や管理方法があることは認識していたもののその手間をかけるまでに至らず、移行は保留となりました。

既存の簡易API:
フロントAPサーバーとバックエンドAPとの間で、負荷吸収のためのキャッシュアクセス処理を行う仕組みがあり、その部分をサーバーレス化できるのでは、という検討を行いました。実際に検討の過程で現状の利用状況を精査したところ、該当部分が古いサービスで、この部分の現状の負荷レベルならキャッシュを挟まなくても問題ないことが判明し、この仕組み自体をなくすことにしました。ただ、この改善の発見のきっかけがサーバーレス適用検討だったので、検討作業は無駄ではありませんでした。

 

適用プロジェクトについて

Github へのプルリクエストの通知をSlackに流すボット機能:
過去にAWS Lambda 上の Python で作られていたもので、若干バグがあることがわかっていたものの、チームにPython 記述者が少なかったことや福本氏も不慣れであったため、メンテされておらず、だましだまし運用されていたものだそうです。今回、AWS Lambda が Ruby 対応したことで、改めてRubyで書き直し。好きな言語で書き換えたことにより生産性とモチベーションがアップし、さらにLambdaでの実装なので開発のみの集中できることがとても楽しかったとの印象を残されています。結果、いくつかの機能追加もしています。また、思わぬ結果として、過去のPythonより処理が速くなったとのこと。元々のPythonコードがよくなかったからでは、とおっしゃっていましたが、それをメンテするモチベーションがなかったのは事実。開発へのモチベーションの重要性はこんな効果を生むのかもしれません。

また、移行検討中なのがユーザ―登録用空メール送信処理です。現行は Pythonで書かれており、メンテしづらい状況なので、早くRubyにしたいとのことでした。

まだサーバーレス経験としては始めたばかりであり、コード管理については後回しとなってしまっているとのことですが、なにより「好き・得意は正義」で、好きな言語で開発に集中できることの良さ（サーバーレス、楽しい!）とコメントがありました。

サーバーレスに限った話ではないですが、新しい概念やパラダイムが登場すると既存アプリのアーキテクチャを見直すきっかけにもなりうるので、社内的にはサーバーレス化検討は（たとえ置き換えられなくとも）大変有意義であったとまとめました。また、既存の仕組みの見直しだけでなく、今後のプロジェクトに関しても、この要件ならサーバーレスでいけそう、という視野が広がったことは大きな意味があったとのことでした。

最後に、本セッションの資料はこちらからご覧いただけます。

 

 

【補足】

RDBMS相性問題はよく言われることであり、今後に向けてみなさまの声をあげていただけるとありがたいです。native extensionsについては、次のセッションで活用の紹介があったので、そちらを参照されることをお勧めします。

また、あわせて、以下のページもご覧ください。
プロジェクト責任者向け アーキテクト向け これから始めるエンジニア向け
ビジネス価値、事例、効果
 ユースケースパターン
 今から始めるサーバーレス
サーバーレス事業開発  杉