LotteryServアップデート

  　LotteryServを更新しました。今回の更新は細かい仕様変更や不具合修正です。

多要素認証の設定はEメールアドレスのみ必須に

　2025/05/06の更新で多要素認証に対応しましたが、同時に主催者の支払い方法を設定するにはユーザアカウントに多要素認証の設定を必須としました。しかしGoogleアカウントを利用している場合、Googleアカウントにパスキーや多要素認証が設定されているか否かを判断できないため、Googleアカウントの多要素認証とLotteryServの多要素認証で2回の第2認証が行われる可能性が発生しました。これは意味がないので、以下の仕様に変更しました。

• Googleアカウントの場合は、LotteryServでの多要素認証設定は任意とします。ただしGoogleアカウントにパスキーを利用するか、多要素認証の設定を推奨します。
• Eメールアドレスの場合は、LotteryServでの多要素認証設定は必須のままです。

応募・抽選結果のCSVをZipアーカイブに

　応募・抽選結果はCSVファイルでダウンロード可能ですが、応募数が多い（100,000以上）場合は複数のCSVファイルに分割しています。これは少々古いバージョンのExcelでも扱えるようにするための仕様です。

　従来はCSVファイルを1つずつダウンロードする必要がありましたので、応募数が多い場合は面倒でした。今回の更新では、すべてのCSVファイルを1つのZipアーカイブにまとめる仕様に変更しました。ダウンロード後に解凍は必要ですが、ダウンロードの手間は軽減されています。

ツールチップが表示されない不具合を修正

　操作可能なアイコンをマウスポインタでポイントすると、アイコンのそばにそのアイコンの説明を表示するのがツールチップです。上の図は主催者ログイン画面の告知リスト左下のリロードアイコンのものです。

　これを実装していたのですが、どこかの更新で表示されなくなっていました。おそらく2025/05/06の更新からだと思われます。気づくのに遅れましたが、今回修正しました。

　ただし全画面でツールチップに対応しているわけではありません。一部の画面では以前からツールチップには非対応です。なんとなくアイコンの見た目で機能は判断できると思いますので、今後もツールチップ非対応画面ではそのままの予定です。

LotteryServアップデート

 　LotteryServを更新しました。前回2025/05/06の更新に続いて、今回の更新もセキュリティの強化が中心です。

ワンタイムパスワード認証に対応

　多要素認証の第2要素として、ワンタイムパスワード認証を追加しました。

　多要素認証はログインできなくなった場合への備えとして複数の第2認証を登録することを勧めていますが、前回のアップデートで対応したSMS認証のみでは、複数のスマートフォン／携帯電話が必要になり、現実的とは言い難い状況でした。今回ワンタイムパスワード認証を追加したことで、スマートフォン／携帯電話は1台でも2つの第2認証に対応できるようになります。

　ワンタイムパスワードアプリは、以下の2つで動作することを確認しています。

• Google Authenticator
• Microsoft Authenticator

　ただし機種変更時の移行には、あらかじめワンタイムパスワード認証の設定をアカウントに保存するなど準備をしておくか、新旧2台を並べて操作するかが必要なようです。ご注意ください。

第2認証の完全な削除を可能に

　前回のアップデートでは、第2認証を複数登録した場合は1つずつ削除が可能でしたが、最後の1つの第2認証は削除不可能という制限がありました。今回のアップデートでその制限はなくなりました。

　すべての第2認証を削除すると、ログイン・再認証は第2認証なしとなります。もちろんこの場合は多要素認証の設定がないので、アカウントは脆弱な状態となります。

　多要素認証の設定がないユーザでは募集の開始ができない制限は、前回2025/05/06の更新からのものです。この制限はクレジットカード決済の悪用による被害を防ぐためのものです。

UIのモダナイズ

　前記ワンタイムパスワード認証の追加に伴い、主催者ログイン画面など一部の画面をモダンなデザイン・実装に変更しました。

　また他の画面でもごく一部に画面遷移やデザインを変更した個所がありますが、使い方には変化はありません。

メールでログインでもアイコンを利用可能に

　Eメールアドレス／パスワードでログインするアカウントの場合、従来はアイコンが固定でした。

　インタネット上に公開されているアイコンがある場合、そのアイコンのURIを指定していただくことで、LotteryServ上でもそのアイコンを表示するようになりました。

　ただ、現在このアイコンを表示するのは、ユーザメニューの最初の項目のみです。

その他軽微な不具合の修正

　詳細の説明は割愛いたしますが、軽微な不具合を複数修正しています。

LotteryServアップデート

　LotteryServを更新しました。今回の更新はセキュリティの強化のみです。そのために利用方法が若干変わった点があり、また新たな制限を追加しています。

3Dセキュア対応

　LotteryServのご利用料金はクレジットカード払いです。クレジットカードの不正利用のリスクを下げるため、EMV 3Dセキュアに対応しました。これは経済産業省の「クレジットカード‧セキュリティガイドライン」に準じるものです。

　以下に説明します今回の更新のその他の変更は、これに伴うものとなっています。

募集の開始・再開ができるユーザを制限

　募集の開始および、休止中の募集の再開ができるユーザを、主催者の支払い方法を登録しているユーザのみに制限しました。

　募集の開始・再開時にご利用料金の上限を決め、クレジットカードに対して支払いの予約を行うため、この制限が必要になりました。

　練習モードではこの制限はありません。

多要素認証に対応

　ログインの際に多要素認証を利用できるようにしました。今回の更新では第2要素に利用できるのは、SMS認証のみです。

　主催者の支払い方法を登録するユーザは、多要素認証の追加を必須としています。

LotteryServアップデート

　LotteryServを更新しました。

抽選の仕組みを更新

　抽選の仕組みを変更しました。

　抽選はユーザの方々からは見えないところで動作しているので、それを変更しても変化はまったく感じていただけません。UIの見た目や使い方にも影響や変化はありません。

価格の変更

　上記の抽選の仕組みの変更により、運用コストを下げることが可能になりましたので、それを価格に反映しました。Google Cloudの利用料金は米ドルで計算されるので、現在も続いている円安により運用コストが高めになっているのは頭が痛いことですが。

ユーザ認証の変更

　ログインや再認証のなどユーザ認証の実装を若干変更しました。Googleアカウントでの認証では、ポップアップウィンドウが出るように変更しています。

　まれにポップアップウィンドウが自動的に閉じられず、認証後も残ったままになることがあるようです。残っていても無害ですが、認証が成功していたらクローズボタンで閉じてください。

LotteryServアップデート

　LotteryServを更新しました。

主催者ページのデザイン変更

　主催者ログイン後のページデザインを全体的に更新しています。より扱いやすく、モダンなデザインになりました。ログインユーザに関する機能が画面共通で専用のUIにまとまりましたので、わかりやすさ・扱いやすさが向上しています。また一部除き基本的にシングルページアプリケーションに変更しましたので、サーバへのアクセスも減ってレスポンスもよくなっています。機能的には特に変わっていません。

Java17対応

　Javaで実装した部分については8→17に変更しましたので、若干レスポンスがよくなっていると思います。

価格の変更

　全体的に価格を下げました。LotteryServで利用しているGoogle Cloudは利用料金が米ドルで決められているので、相変わらず続いている円安ではランニングコストが高くなるのですが、戦略的な理由から下げることにいたしました。

　今回の更新では一時的に、更新前のサイトが表示されたり、ネットワーク関連のエラーが発生する可能性があります。これらの症状に遭遇した場合、リロードを試してください。それでもエラー表示か続くなら、時間を空けて試してください。更新後のサイトが表示されるようになるまで時間がかかる可能性もあります。

円安の影響

2022年に入ったあたりから円安による物価高が、いろいろなところに影響していると思います。わかりやすいのはガソリン・軽油、灯油、電気代、ガス代、食品あたりでしょうか。そのほかにもいろいろな商品がいつの間にか値上げされていてびっくりしたり。

GCPの利用料金は、使用しているリージョンに関係なく、米ドルで計算されます。そのため円相場は運用費用に大きく影響します。LotteryServの価格を決めた2021年は1ドル=110円くらいでした。多少レートが変動してもすぐには価格に影響させなくていいように考えて価格を決めたつもりなのですが、とうとう145円を超えてしまいました。それどころか150円にも届きそうな勢いです。わずか1年ちょっとでこんなに変わるなんて。

LotteryServの応募ページのレスポンスを向上では、ランニングコストも下がったはずなので、それを反映させたいと思っています。特に応募数が多い場面で効果が大きいはずです。

しかし今の円安は、この効果を見事に打ち消してしまっています。そのため今は価格改定の時期を検討しています。

LotteryServに練習モードを追加

LotteryServの募集に「練習モード」を追加しました。

募集は、あらかじめ入力された内容に従って時間の経過とともに状態を変えながら実行していくので、実行に先立って入力内容が思いどおりであるかを検証することが困難です。そこで入力とLotteryServの動作の関係を理解いただくための「練習モード」を追加してみました。

練習モードは、以下の目的でお使いいただけます。

• 使い方を覚えるために、練習しておきたい。
• LotteryServのご利用検討のために、機能・使い勝手を確認してみたい。

練習モードは、本番モードとは下記の点が異なります。

• 利用料金が無料。
• 応募者数が制限されます。
• 抽選は行いません。全応募者が落選となります。
• 募集期間および結果公開期間が、最大48時間までに制限されます。
• 当選通知Eメールは利用できません。
• 主催者に支払い方法が設定されていなくても利用できます。

LotteryServに興味をお持ちで導入を検討いただけるようでしたら、まずは練習モードをお試しください。ご意見やご要望があれば、問い合わせいただけますと幸いです。

LotteryServの応募ページのレスポンスを向上

 　LotteryServを更新しました。

　今回の更新内容は、応募および結果確認ページのレスポンス向上のみです。もともとそんなに重たい処理を行っていたわけではないのですが、応募や結果確認の操作を行なう応募者の方からは改善の効果は実感しにくいと思います。

　しかし、アクセス集中による影響を最も受けるページなので、アクセス集中時には効果が出ています。実際にアクセス集中を想定した検証を行ってみると、明らかなパフォーマンス向上が見られています。数値では表しにくいのですが、体感的には2倍程度速くになったように感じます。

　ちなみに修正内容は軽微なものではなく、該当ページ関連を再実装しています。

　今回の更新では、使い方や見た目は変わっていません。また応募および結果確認ページ以外には変更はありません。

LotteryServアップデート

　LotteryServを更新しました。

デザイン変更

　トップページを中心にデザインを変更しました。サイト構成はほぼ変わりませんが、各ページのデザインを変更してあります。

　またユーザ登録/主催者登録/募集編集の画面は入力していただく項目が多いので、入力内容の説明を増やして分かりやすくしました。

応募ページのモバイル対応

　応募/抽選結果の確認ページのみですが、モバイル対応しました。これまでスマートフォンなどで表示すると小さく表示されてしまい、拡大しないと文字が読めなくなっていましたが、5インチ程度のスクリーンを持つスマートフォンなら拡大しなくても読めるように変更しました。

　また応募者が入力すべき内容が分かりやすくなるよう、デザインを変更しています。

抽選時間の短縮

　内部実装を見直すことにより、抽選時間を短縮しました。抽選時間は、応募数によって変わりますが、おおむね以下の様に変わっています。

　上記の時間は実測値をもとにしていますが、状況により変化する可能性があります。目安くらいにお考え下さい。

価格の変更

　一部の価格を変更しました。下記の表の金額は消費税込みです。

　これまでは応募ステップが上がるごとに、5倍→2倍→5倍→2倍... と不等間隔の設定になっていましたが、ほぼ3倍毎に上がるように修正しました。それに伴って最大応募数が少なくなる応募ステップでは、価格を下げています。

　またより少ない応募数に対応したステップを追加しました。これにより小規模な募集ならさらにコストを抑えることが可能になります。

LotteryServの名称について

 しばらくこのブログを更新してなかったので、今回は無理やり話題を追加します。

LotteryServの名称についてですが、単純に「抽選を提供するサービス」を表すものとして

• 抽選 = lottery
• 提供 = serve

の英単語の組み合わせです。

最後の「e」が足りてませんが、開発の初期段階で打ち損ねて足りなかったのをそのままにしています。なんとなく「v」で終わっている方がカッコいい感じもしましたので。

もし正しいつづり「serve」を使うサイトがあったら、それはまがい物です。

LotteryServに当選通知Eメールの送信対応を追加

 LotteryServに新しい機能を追加しました。

募集ごとに、当選者に当選を通知するEメールを送信するか否かを設定できます。

設定

募集編集ページの以下の項目で設定します。

「送信しない」を選択した場合は今までどおりで、変りはありません。「送信する」を選択した場合、結果公開の開始と同時に、当選者に順次、応募時に入力されたEメールアドレス宛に、当選を通知するEメールを送信します。

実店舗との連携

以下の手順で、 LotteryServと実店舗のとの連携が可能になります。

1. 募集の編集を開始する。このとき上記の「当選通知Eメールの送信」で「送信する」を選択する。
2. その他の項目も入力し、募集を開始する。
   
3. 結果公開の開始日時が来ると、当選者に順次、当選通知Eメールが送信されます。
4. 当選者は実店舗で受信した当選通知Eメールを提示する。
5. 当選確認ページにて、当選通知Eメールに記載された 募集番号・当選番号 を入力する。
6. 当選者に該当の商品/サービスを提供する。
7. 必要なら、「購入」ボタンを押して、この当選者への商品/サービスの提供が完了したことを記録する。

最後の手順7は必須ではありません。当選者による2重購入を防ぎたい場合に有効です。

注意事項

• 応募者は、携帯電話/スマートフォンなどのモバイルデバイスで表示可能なEメールアドレスから応募することを前提としています。
• 現在この機能を利用できるのは、当選者数1000人以下の募集に限定しています。
• また複数の募集で同時期に結果公開開始が集中している場合、この機能をご利用になれない場合があります。

実装の背景

EC大手のShopifyやBASEでは、すでに抽選販売の機能が提供されています。これらのサービスをお使いの場合は、それらの抽選販売の機能を利用される方が簡単です。

それら以外の独自にECサイトを運用している場合や、実店舗のみの場合にお使いいただけると思います。

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

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自身が利益を出すようになったら、見栄えのするものに変えたいと思っています。

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

LotteryServサービス開始

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

きっかけ

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

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

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

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

目指したもの

開発のきっかけから、アクセス集中してもサーバダウンしない、レスポンスが悪くならないは もちろんです。

例えば何か物を売る場合、望まれるだけの数・量を提供できるのが理想です。しかし原材料の調達、生産能力などが理由で、望まれただけ提供できないケースもあります。こうしたケースで気軽に導入できるサービスを目指しました。

抽選なんてあまり使われるものでもないので、このサービスもあまり使っていただけないかもしれません。しかし必要になった時、使っていただけるように用意しておくのも社会への貢献になるかなと、思っています。

特徴

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

どちらもクラウドだから実現できたものです。

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

LotteryServ準備中

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

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

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