LotteryServの開発

 LotteryServを開発してみて、苦労した点です。

1. 決済

最も苦労したのは決済です。
クレジットカード決済の実装が初めてで知識も経験もなかったというのもありますが、売掛で1度は実装したためにそれをクレジットカード決済対応に修正する必要が生じてしまったことも、作業量を増やす原因になってしまいました。
まず決済代行サービスの調査・選択から始まりました。決済代行サービスは20社以上出てきたのですが、ほとんどはリアル店舗での小売業を対象としたもので、ネットでAPIを使えるようにしているサービスは限られています。さらに各社から資料を取り寄せてAPIを精査してみると、1回ごとにクレジットカードの情報入力が必要なものと、予めクレジットカード情報を登録しておいてそれを使いまわせるものに分かれています。LotteryServでは応募数によって提供するサービスの途中で決済価格が変わるので、予めクレジットカード情報を登録できる決済代行サービスでないと、主催者に不便を強いることになります。そのため予めクレジットカード情報を登録できる決済代行サービスであることを確認する必要がありました。
またAPIの仕様が古くて、ちょっと使いたくないなと思わされるようなものもありました。10年以上前に作って、新しい技術が使われるようになっても仕様を更新することなくそのままになっている感じです。アクセス元を確認するために固定IPが必要など、GAEでは対応できない仕様を要求するものももあります。GCEなら対応できますが、決済のためだけにGCEを立ち上げたのではランニングコストが増えますし、何よりレスポンスが悪くてUIの構築が面倒になります。このような古い仕様のものは出来れば避けたいものです。
実装を始めてからも、最初は公開されているリクエストエンドポイントを直接たたいていたのですが、POSTのみリクエストを受け付けてもらえないという現象に悩まされました。GETは1発でクリアしたんですけどね。リクエストを受けた際のログなどが見れないので、どこに原因があるかわからず、解析が行き詰ってしまうことになりました。結局これは提供されているライブラリを利用することで回避しました。

2. 抽選

2番目が抽選でした。
応募数が多くなると抽選に時間がかかるようになるのは必然なので、応募数にあわせて並列処理することにしました。最初はとりあえずシングルスレッドで抽選処理の原型を作成。次にGAEで1インスタンスあたりどのくらいのスレッド数まで性能低下が起きないかを調査しておきます。
そしてどう並列実行を実装するのがベストかの調査です。
お手軽なGAEでの実装では、自動スケール/基本スケール/手動スケールそれぞれでパラメータを変えて試してみましたが、思ったようにインスタンスが増えてくれません。増えてほしいのになかなか増えててくれないか、まだ増えなくてもいいのに増えて何もせずに落ちていくとか。やはりGAEで思ったとおりにインスタンスを増減するのは難しいようです。ある程度おおざっぱな制御になります。デフォルト設定でもオートスケールしてくれるのは便利なんですけどね。
結局GAEは諦めてGCEで実装しています。GCEでは自分でインスタンスとスレッドの起動をコントロールするので思いどおりです。GCEでの実装の欠点は、無限にインスタンスを増やすことができないことです。あらかじめ用意しておいたディスクの数だけしかインスタンスを起動できません。これは運用で解決することにしました。

その他は、紹介してもつまらないものなので、割愛します。LotteryServの特徴の1つであるアクセス集中への耐性ですが、これも対応方法さえ知っていればどういうほどのことはありません。小さな工夫はたくさんありますが、長くなるのでまたの機会に。

しかし運用するためにそろえなければならない機能が多く、サービス開始までには思ったより時間がかかりました。