ORICALを支えるインフラ

f:id:ventus-inc:20211211172735p:plain

はじめに

こんにちは、ventus CTOの宮澤です。

CTOとしてはエンジニア採用や組織運営の仕事をしています。また、実際にバックエンド開発で手を動かしたり、実質この会社で1人しかいないインフラ担当として色々なサーバたちの面倒を見たりしています。

これまでにこの会社でエンジニアとしてやってきたことを簡単にまとめると、

Ruby on Rails を用いたAPIサーバ開発

RDB (MySQL) のスキーマ設計

バックエンド開発のPdM兼PM的な役回り

開発方針の決定（これはみんなで）
開発計画の策定
技術選定
仕様ぎめ、Issue立て
レビュー
その他定常タスク

弊社で使っている全サーバの管理、運用
オペレーション周り

CS対応
データ作成

こうして書いてみるとなんでもやる人みたいになってますね笑　小さい会社あるあるな気もしますが...

f:id:ventus-inc:20211208002830p:plain — 鯖缶のイメージ（実際はアラートが飛ぶのでこれとにらめっこすることは殆どありませんが...笑）

ORICALの現状

ventusでは、電子トレカ®︎コレクションサービスのORICALというプロダクトを運用しています。

現状では3つのパートナーさん（弊社では提携先企業さんのことをパートナーと呼んでいます）と一緒にやらせていただいており、それぞれの登録ユーザー数は以下の通りです（2021/11末現在）。

一日あたりのAU（アクティブユーザー）数は登録ユーザー数の半分弱なので、3サービスで1日約20,000人のAUがあるサービスを運用している計算になります。さらに、野球の試合が終わった直後などには「観戦限定トレカ」の受け取りのためアクセスが集中し、その際には大量のトラフィックをさばかなければなりません。

f:id:ventus-inc:20211208003349p:plain — 野球の試合が終わった直後にはアクセスが集中します

このようにアクセスが集中した時にも、ユーザーがアクセスに時間がかかりすぎることなく快適に利用できるようにする必要があります。このためには、インフラ構成を適切に設計し運用しなければなりません。

ventusでは、アクセスが集中した時やクラウドサービスプロバイダ側で障害が発生した時にも、サービス全体に影響を与えることなく対応できるようなインフラ構成を（紆余曲折を経ながらも）確立しています。

f:id:ventus-inc:20211208003445j:plain — ORICALの現在のインフラ構成

弊社では多くのスタートアップと同様に、クラウドサービスプロバイダとして主にAWSを用いてインフラを構築しています。

上のように図にしてみるとなにやら色々なサービスを使っているように見えますが、基本的にはフロントエンド（Webサーバ）、バックエンド（APIサーバ）、DBの三層構造です。

フロントエンドとバックエンドには AWS の Elastic Beanstalk と呼ばれる PaaS を用いており、それぞれ Node.js と Ruby のプラットフォームを使っています。

PaaS を用いることでデプロイ管理や環境変数などの様々な設定項目を AWS 側に委譲することができるので、インフラ担当が実質1人しかいない状況では大変重宝しています。

また、Elastic Beanstalk は基本的に（デプロイ管理以外は）他の AWS サービスの寄せ集めなので、裏でなにがどのように動いているのか簡単に把握することができるのもメリットです。実際、Elastic Beanstalk は裏で CloudFormation を使って各種リソースを制御しているので、俺は自分で全部やる！という強者は EB を使わずとも CloudFormation を使えば同じようなことを実現することができます。

フロントエンドとバックエンドのサーバーはオートスケーリングを用いて、一定の負荷がかかると自動でスケールアウトするような仕組みになっています。

とはいえ、負荷ベースのオートスケールは発火してから実際に使えるようになるまで数分間のラグがあるので、事前に予測できる負荷増大に対しては時間トリガーのオートスケールも組み合わせて使っています。

また、低負荷時でも最低2AZにまたがるような構成にしているので、単一のデータセンターに障害が発生してもサービスが使えない...ということには極力ならないようになっています。

ちなみに、上の図にある他のサービスに関しては以下のようになっています。