2021/07/29

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

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ですね。

2021/07/26

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

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

2021/07/22

デザインについて

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

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

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

不正アクセス

Wordpressを狙った不正アクセスの発見です。


不正アクセス その1

 独自ドメインを公開してしばらく(3~4日程度)すると、以下の様なアクセスがログに残っていました。

画像だと検索に反映されないし、再利用もしにくいので、文字にしたのが以下。

/sito/wp-includes/wlwmanifest.xml
/cms/wp-includes/wlwmanifest.xml
/site/wp-includes/wlwmanifest.xml
/wp2/wp-includes/wlwmanifest.xml
/media/wp-includes/wlwmanifest.xml
/test/wp-includes/wlwmanifest.xml
/wp1/wp-includes/wlwmanifest.xml
/shop/wp-includes/wlwmanifest.xml
/2019/wp-includes/wlwmanifest.xml
/2018/wp-includes/wlwmanifest.xml
/news/wp-includes/wlwmanifest.xml
/wp/wp-includes/wlwmanifest.xml
/website/wp-includes/wlwmanifest.xml
/wordpress/wp-includes/wlwmanifest.xml
/web/wp-includes/wlwmanifest.xml
/blog/wp-includes/wlwmanifest.xml
/
/xmlrpc.php?rsd
/wp-includes/wlwmanifest.xml

頻度は2~19時間に1回、上記のアクセスが連続してきます。


不正アクセス その2

これも独自ドメインを公開して4日程度経った頃から来るようになったアクセスです。
これも文字にすると、
/wp-login.php

頻度は基本は1日1回のようですが、5日空くケースがあったり、なぜか4回連続する場合もありました。


私はWordpressを使ったことがないですし、現在稼働中のLotteryServも当然Wordpressは使っていません。このアクセスに対するアクセスポイントも存在しないので、404 Not foundが返っています。"/"だけは実在しますが、これはスタティックなHTMLです。発生する被害は、警告が残ってログが見にくくなるだけです。


Wordpressを使っている皆さん、注意を。

2021/07/21

LotteryServサービス開始

抽選を代行するサービス LotteryServのサービスを開始しました。


きっかけ

このサービスを開始するきっかけになったのは、新型コロナウィルス(COVID19)の蔓延によるマスク不足の解消のため、いくつかのメーカーから発売されたマスクの抽選販売で、アクセス集中による販売の一時停止が起きたことです。私も抽選に応募してみましたが、アクセス過多でなかなか応募に成功しませんでした。応募を繰り返しながら「クラウドをうまく使えば こんなに重くならないだろう」と思っていました。

その後、抽選に使えるサービスやアプリケーションソフトを探してみましたが、意外と少ないうえ、クラウドで実装したものは見つかりません。ほとんどは景品の抽選を対象としたもので、抽選販売を対象にしたものはごくわずか。アクセス集中する状況に対応するものはなさそうでした。

さらに利用価格がどれも想像していた以上に高価で、気軽に使えないどころか利益を圧迫してしまいそうでした。

いいものがないのなら作ってしまおうと、行動に移してみました。


目指したもの

開発のきっかけから、アクセス集中してもサーバダウンしない、レスポンスが悪くならないは もちろんです。
例えば何か物を売る場合、望まれるだけの数・量を提供できるのが理想です。しかし原材料の調達、生産能力などが理由で、望まれただけ提供できないケースもあります。こうしたケースで気軽に導入できるサービスを目指しました。
抽選なんてあまり使われるものでもないので、このサービスもあまり使っていただけないかもしれません。しかし必要になった時、使っていただけるように用意しておくのも社会への貢献になるかなと、思っています。

特徴

  • アクセスの集中に強い。
    応募が殺到してもサーバダウンは発生しにくくなっています。急激なアクセスの増加などで一時的なレスポンスの低下が発生することはあります。仮にアクセス集中によるエラーに遭遇しても、1~2回のリトライで応募を完了できるはずです。
  • 低価格。
    導入時の初期費用なし、月額料金などの固定費用もなし、募集ごとの費用のみです。そのため季節性の商品など、一定期間のみ販売するような商品でも少ない費用負担で導入いただけます。
どちらもクラウドだから実現できたものです。

抽選の導入をお考えの方に、ぜひ使っていただければと思います。

2021/07/15

LotteryServ準備中

LotteryServのサービス開始に向けて作業中です。


まずはサービスできる最低限の機能でスタートします。

作りながらも今後増やしたい機能や改良の構想は浮かんできますが、それらはいったん置いておいて、最初は最低限必要と思われる機能からのスタートを目指しています。