ログイン/再認証時のドメイン表示について

LotteryServに Eメールアドレス/パスワード以外の方法でログインまたは再認証するとき、以下の画面キャプチャの様にLotteryServではないドメインが表示されます。これは不具合ではなく、正常な動作ですのでご安心ください。

以下、このような表示になる原因について説明します。技術的な内容ですので、興味のある方だけ読んでいただければ十分です。

LotteryServは主にGCPの中の1サービスであるGAEを使って実装していますので、独自ドメインlotteryserv.bizはGAEアプリに接続しています。

その一方でユーザ認証は同じくGCPの中の別のサービスであるIdentity Platformを使用しています。Identity Platformでは「認証ハンドラのカスタマイズ」からリンクされた「カスタムドメインを接続する」に上記ユーザ認証画面で独自ドメインを表示する方法が説明されています。ここを読めばわかるように、上記のユーザ認証画面で独自ドメインを表示するには、独自ドメインをFirebase Hostingに接続する必要があります。

つまり独自ドメインをGAEとFirebase Hostingで奪い合って競合する事態になります。LotteryServでは独自ドメインはGAEに接続し、ユーザ認証画面での独自ドメイン表示は諦めています。

FirebaseはもともとGoogleとは独立した会社であったFirebase社が2011年に開始したサービスだったのですが、2014年にGoogleに買収されてGCPの一員となった経緯があります。そのためFirebase社の名残がいろいろなところにあったり、今回のユーザ認証画面の表示の様に まだGCPに統合しきれていない部分が残っていたりします。

FirebaseがGCPに完全に統合されるまで、この対応は簡単ではないと思われます。

2021/09/27追記

FirebaseAuth.generateEmailVerificationLink()メソッドなどが生成するEメールアドレス確認のリンクも、同様にドメインがFirebaseですね。

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つであるアクセス集中への耐性ですが、これも対応方法さえ知っていればどういうほどのことはありません。小さな工夫はたくさんありますが、長くなるのでまたの機会に。

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

デザインについて

 LotteryServの画面デザインですが、「チープ」「貧相」と思われるかもしれません。これはデザイナーに外注せず、エンジニアがデザインしているからです。そのため業務的な外観になっています。業務用アプリを使用したり開発にかかわったりした経験のある方は、どこかで見たような既視感があるかもしれません。

なぜデザイナーに外注しなかったのかは... 新型コロナウィルス蔓延による仕事の激減、収益の悪化で外注する資金がないからです。LotteryServ自身が利益を出すようになったら、見栄えのするものに変えたいと思っています。

当面の間はデザインよりも機能優先で更新する予定です。使いにくい点があると思いますが、ご辛抱ください。