社内向けニュース提供APIをS3+API Gatewayでサーバーレスにサクっと構築してみた

こんにちは!VOYAGE MARKETINGシステム本部の@gomachan46です。 普段はRuby on Railsを用いてPeXというポイント交換サイトの開発を主に行っています。

さて、PeXにはポイントを貯められるコンテンツがたくさんあります。その中のひとつ「YOUの気持ち聞かせてよ!みんなのNEWSウォッチ」は、ニュース記事を読んでリアクションするだけで、簡単にポイントが貯まるコンテンツです。

pex.jp

今回は、「みんなのNEWSウォッチ」のコンテンツストレージとしてはもちろん、APIとしても縁の下から支えてくれているS3の活用事例について書いていきたいと思います。

3行まとめ

  • S3をAPIとして実際に利用してみた
  • 負荷や管理周りなど考える事が減って良い
  • ファーストリリースの価値検証等のフェーズでは特に一考の価値あり

「みんなのNEWSウォッチ」の仕組み

はじめに「みんなのNEWSウォッチ」の仕組みを簡単に説明しようと思います。

登場人物

  • ニュース提供元
    • 「みんなのNEWSウォッチ」の大元となるニュース記事を提供してくれている社内外のメディア
  • ニュースAPI
    • ニュースを配信するための社内用のAPI
  • PeX
    • ニュースAPIを利用して「みんなのNEWSウォッチ」を提供する自社サイト

「みんなのNEWSウォッチ」でニュースを表示するまでの流れ

ニュース提供元が用意したニュース情報をPeXが利用するまでには、簡単に言うと以下のステップが必要となっています。

  1. ニュース提供元に取り込んで欲しいニュース情報をxml形式で記載してもらう
  2. クローラが定期的に取得する
  3. ニュース情報を蓄積する
  4. 蓄積されたニュース情報をニュースAPIで取得可能にする
  5. PeXからニュースAPIを利用して「みんなのNEWSウォッチ」を表示する

はじめに検討していたシステム

一番はじめにパッと思いついたのは以下の構成図のようなシステムでした。

f:id:shiro_goma:20160908110534p:plain

Ruby on Rails等を用いたオーソドックスなwebアプリケーション+RDBの構成ですね。

バッチ処理でニュース提供元から情報を取得し、RDBに取り込む。そしてフロントとしてAPIサーバを立てて要求に応じてRDBにアクセスしニュース情報を返す。

そんな感じのごくごく普通のアプリケーション構成を考えていました。

出来れば楽をしたい

当然ではありますが、出来れば楽をしたいものです。

上記のような一般的なアプリケーションを一から作ってもまぁ良いのですが、出来れば

  • 開発は少なくライトに済ませたい
    • 新規コンテンツリリースというところもありコストをかけずにまず価値を検証したい
  • 安定して稼働するために色々頑張りたくない
    • 冗長構成など
  • 負荷とか気にしたくない
    • 負荷状況に応じてスケールアップ/スケールアウトするなど
  • レスポンスタイムとか気にしたくない
    • API周りのパフォーマンスチューニング等
  • データ量とか気にしたくない
  • 安く済ませたい

というように色々と欲はあるので、どうにかもう少し良くできないか、というところを考えた結果アプローチとして取ったのがS3でした!

S3を活用してサーバーレスAPIを実現

実際に構築したシステム構成図は以下の通りです。

f:id:shiro_goma:20160908111031p:plain

今回は、上記ステップの

ニュース情報を蓄積する

蓄積されたニュース情報をニュースAPIで取得可能にする

という部分をS3に任せるようにしてなるべく楽が出来るようにしてみました。

ニュースAPIとしての部分は、

などを用いて比較的簡単に実現することが出来ます。

S3を上手く活用することでニュースAPI周りのサーバーが不要になり、サーバーレスなアーキテクチャに近づける事が出来ました!

S3を活用にすることでどう楽が出来たか

ニュースAPI周りをサーバーレスに出来たことで、色んな恩恵が受けられるようになりました。

開発は少なくライトに済ませたい

webアプリケーションを一からカチッと作るのではなく、ニュース記事を取り込むスクリプトを1つ用意して定期的に実行する程度で済むようになりました。

APIとして安定して稼働するために色々頑張りたくない

S3任せにできるので、基本的に気にしなくて良くなりました。

負荷とか気にしたくない

ここもS3任せにできるので、基本的に気にしなくて良くなりました。

データ量とか気にしたくない

ここもS3任せにできるので、基本的に気にしなくて良くなりました。

レスポンスタイムとか気にしたくない

ここもS3任せにできるので、基本的に気にしなくて良くなりました。

出来れば安く済ませたい

上記のように強いAPIを作るための頑張りどころがS3任せに出来るようになったので、サーバ代を大きくコストダウン出来ました。S3も相当安いのでほぼ気にならない程度です。

また、監視体制などもだいぶ手軽なもので良くなったので、管理コストなども下げる事が出来ました。

まとめ

いかがでしたでしょうか。

もちろん普通にwebアプリケーションを作るよりも機能面での幅の効き方は劣ってしまうのでケース・バイ・ケースな部分はありますが、余りあるメリットも持っているアプローチだと思います。

要件と照らしあわせてみて、採用出来た時のメリットなどが少しでも伝われば、と思って書かせて頂きました。

リクエストに応じた動的な挙動(例えば検索など)はやはり静的コンテンツを扱うS3では厳しいですが、要件によっては必要十分な機能を取り揃えた、非常に簡単で、かつ安定したAPIを提供することが出来ます。

また、仰々しい構成を取らなくても良くなるので、機能は限定的でも良い新規コンテンツなどのファーストリリース等、価値検証のフェーズでの投入は有効なアプローチなのではないかなと思っています。

引き出しの一つとして持っておいて損はないのではないでしょうか。

「VOYAGE GROUP内ではこんな風にS3をAPIとして実際に活用しているよ!」という一例としてのご紹介でしたが、「うちではこんな感じに使ってるよ!」などなどあれば是非教えていただけると嬉しいです。