ウェブ系サービスに必要なAPI課金システムをサーバーレスで構築、スタートアップ企業のスピード感とコストとニーズを満たすためAWSとStripeを活用

はじめに

株式会社Geoloniaは、提供している地図サービスの本格的な事業化に向け、課金システムの整備に着手。その設計と構築にあたって、Serverless Operationsにご依頼をいただきました。そのプロジェクトの詳細について、Geoloniaの代表取締役CEO 宮内 隆行さんと、Serverless Operations代表取締役の堀家さんにお話しをうかがいました。

サーバーレスにしたいから選んだ開発会社

――地図サービスの課金システムの開発にあたって、GeoloniaからはServerless Operationsに対してどのようなアプローチがあったのでしょうか。

宮内　そもそも、弊社が地図のサービスを展開するうえで、サーバーをなくしたかったんです。これまでのようにサーバーを置いて、それがすべてのトラフィックをさばくやり方だと、地図データではインフラが大変なことになる。100GBを超えるような、すごく大きなデータなので。でも、サーバーレスでやろうとすると、わからないこと、不安なことがたくさんあります。そこで堀家さんに相談しました。

いろんな開発会社があるなかで、Serverless Operationsだったのは、以前に堀家さんと一緒に仕事をしたことがあって、彼が「Serverless Framework」というオープンソースプロジェクトで活躍されていることを知っていたからです。だから、サーバーレス開発のことなら、堀家さんに聞くのが日本で一番確実だなと。

――課金システムの以前に、そもそものサービス開発から一緒にされていたんですね。

宮内　はい。Serverless Operationsの協力もあって地図のサービスが形になってきたので、サービス開始に必要な課金システムを作ることにしました。自分たちで作ることも考えたのですが、社内のエンジニアが少ないのと、課金システムは不具合があるとお客様にも影響が大きいので、信頼できる外部の事業者に協力してもらうことにしました。

それに、特定のエンジニアだけにまかせるとブラックボックスになりがちなので、係わるエンジニアを増やして多くの目に触れる状態にしたかったんです。そこで、もとの地図サービスを一緒に開発した、堀家さんに課金システムもお願いしました。

堀家　宮内さんからは最初「地図サービスの課金システムを作りたいんだけど、どうしたらいいかな」という、依頼というよりも相談みたいな形でお話しがありました。そこで、どのくらいの予算かうかがったうえで、開発における役割分担を切り分けを考えました。

Serverless Operations側が主に設計やバックエンドの開発などを担当し、Geolonia側が主に実装や展開（CI/CD）、それにダッシュボード（利用者側のインターフェイス）の開発などを担当するという体制を提案して、それで進めることになりました。

――具体的にはどういった体制で開発したのですか。

堀家　Geoloniaからは、鎌田さんというエンジニアが仕様決定や取りまとめ役として立ちました。Serverless Operationsからは、僕が設計とサービス選定、デモ開発を担当しました。僕から課金システムに利用するクラウドインフラや決済サービスを提案して、実際に動くデモを作って、鎌田さんがそれを見て決定する、という進め方でした。

後半からは、Geoloniaから小林さんというエンジニアも参加して、お客さんにクレジットカード情報の登録してもらうダッシュボードの開発をしてもらい、Serverless Operationsからは私と、途中でもうひとりのエンジニアに交代してバックエンドを作りました。

エンジニアは最大で4名がコミットして、期間は2020年の10月に開発を始め、2021年の2月いっぱいで終わりました。1月はほとんど作業をしなかったので、実質的には3カ月です。

インフラにAmazon Fargateを選んだ理由

――課金システムは、どのような仕組みなんでしょうか。

堀家　Geoloniaの地図サービスは、利用者がAPIを呼び出して使うもので、サービスのアクセスログはAmazon S3（AWSのストレージサービス）に保存されています。そのアクセスログからAmazon Athena（S3上のデータをSQLで操作できるAWSのサービス）で必要なデータだけを取り出し、AWS Fargate（AWSのコンテナ向けサーバーレスコンピューティングエンジン）に設置したプログラムで集計処理をして、結果をAmazon DynamoDB（AWSのNoSQLデータベースサービス）に保存します。

地図サービスのお客様への請求と決済には、Stripe（ネット向けの決済プラットフォームを提供する事業者）を使っています。あらかじめStripeに請求先やサイクル、料金体系、締め日などを設定しておくと、DynaboDBに保存した集計結果を元に月次の料金を計算して、請求日に請求書を自動的に発行してくれます。

――サーバーレスで開発するには多くのサービスがあり、AWSだけでも複数の選択肢があります。今回、Fargateを選択した理由はなんでしょうか。

堀家　コンピューティングエンジンに関しては、AWSに3つのサービスがあります。Lambda、Fargate、EC2と選択肢が3つあって、後にいくほど手間が増えていくんです。その替わり、できることの柔軟度が上がっていく。

Lamdaは、考えることが少なくて済みますが、ひとつのプログラムが15分以上動かないんです。だから、15分以内で処理を終わらせるようにしないといけない。逆にEC2は、CPUをどれにするか、どのくらいの数を立ち上げるか、メモリをどうするか、とか初期設定で考えないといけないことがたくさん増える代わりに、Lamdaのような制限がなくて何でもできるんです。Fargateは、その中間でEC2ほどではないけれど初期設定が必要だけど、Lamdaほどの制限はない。

僕は、サーバーレスで開発する場合、基本的にまずLamdaを検討するんです。今回の場合はログの集計処理で、ログはユーザー数や利用状況によってデータ量が大きく変動するので、データ量が大きい場合は15分を超えてしまう可能性がある。並列処理にするとか工夫することで対応できますが、データ量で処理時間が変化するので15分を過ぎるリスクが常にあります。それを考慮して、今回はFargateにしました。

Fargateも内部は結局EC2ですが、あらかじめサービスの側である程度設定を上手くやってくれます。コンテナをFargateにポンと投げれば、それだけで動いてしまう。だから、普通にウェブでサービスを作る場合はFargateが一番多く選ばれていて、最初からEC2でやるというケースは少ない気がします。

Stripeは開発者が使いやすい決済インフラ

――決済サービスについては、なぜStripeを選んだのですか。

堀家　決済サービスについては現状、Stripe一択という状況なので、特に迷うことはありませんでした。以前は、他にもサービスがあったのですが、そこも終了してしまったので、本当に選択肢がないんです。ただ、開発者にとってStripeはとても使いやすいんです。

課金を処理するためのAPIが非常に使いやすかったり、サブスクリプションから従量制までいろんな課金の仕組みに対応できたり、開発に必要なドキュメントの整備であったり、サポートが体制が充実していたりするんです。

――具体的にどういった点が、開発者にとって使いやすいのでしょうか。

堀家　サブスクリプションサービスで課金をする上で必要な機能が揃っているだけでなく、途中でプランを切り替えた場合の差額の処理といった、自分たちでゼロから考えて実装するにはかなり大変なところも、あらかじめ用意されているところですね。

そうした場合、締め日に合わせて日割りでやるのか、それとも申し込み日に合わせて締め日を変えるのか、とか考えることがものすごく多いんです。それをStripeなら、サービスの側で上手くやってくれる。

だから、Stripeしか選択肢がないというのは、ネガティブな意味ではなくてポジティブな本音です。Stripeに依存してベンダーロックインされているところもないです。ユーザーコミュニティも熱心に活動していて、ミートアップなども定期的に開催しているようです。こういうコミュニティがあるプロダクトは、個人的に信頼できると思っています。

宮内　地図サービスは、APIを介して利用するサービスなので、最初から漠然と「これとこれを数えておけば課金ができる」というイメージのはあったんです。そこを数える部分、ログの集計の部分をお願いしたんですけど、そこがすごいうまく動いているので、結果的にはどんな課金モデルでも対応できることになったので、良かったですね。

――課金システムの開発にあたって、重視したポイントはなんでしたか。

堀家　開発する上では、集計などでエラーが起きたときにどうするか気を付けました。エラー対応にはリカバリーのセオリーがあるので、それに沿った開発を行っています。ログ集計系については、先ほど述べたようにログの大きさでエラーが起きないように、コンピューティングエンジンを選んでいますし、決済系についてはStripeの信頼性が非常に高いので、そこに投げるデータさえ間違ってなければ問題ないです。クラウドサービスでの課金は、よく利用者側のミスで莫大な金額が請求されてしまうことがありますよね。そういったことがないようにしています。

宮内　課金で怖いのは、仕組みが間違っていてお客さんに多く請求してしまったり、少なく請求してしまったりすることです。少ない場合は、しょうがないですが（笑）。ただ、多く請求することは信用を失いますし、返金することになるとその手間も掛かる。

それに、開発を相談した時点では、地図サービスの料金体系がまだ確定していなくて、流動的だったんですよね。地図サービスには、グーグルマップという大きな競合がいるので、その料金体系は常に意識しないといけないんです。だから、正式な料金体系は、つい先日にやっと決まったばかりです。

課金システムを開発するのに料金モデルが決まらないので、サービスを開始するまで何ヶ月も開発に付き合ってもらうことになると思っていました。それが、思っていたよりもすんなりといけたのは良かったです。課金モデルも、Geolonia側からダッシュボード上の設定変更で対応できるので楽で助かります。

――どうもありがとうございました。