デジタル名刺をビジネスIDへ

こんにちは。Eightのサーバーサイドエンジニアをしている井上です。もうすぐ RubyKaigi ですね！昨年に続き、今年も参加予定なので、Rubyの未来や松山の街を楽しみにしています。

さてEightは今、名刺管理だけではなく名刺交換も行える「名刺アプリ」としてデジタル名刺に注力しています。デジタル名刺の交換としてQRコードやタッチ名刺交換といったさまざまな手段を提供していますが、紙の名刺交換をデジタルで置き換えるだけでなく、デジタルだからこそ実現できる新たな価値の提供にも取り組んでいます。

その1つとして、今回はデジタル名刺ログインをご紹介したいと思います。

デジタル名刺ログインとは

オンライン上でデジタル名刺をビジネスIDとして利用する機能となります。他のサービスに埋めこまれたQRコードを読み取り、Eightアプリで承認することにより一意のIDとプロフィール情報を連携できます。

世の中にあるソーシャルログインと似た部分はありますが、「名刺アプリ」であるEightでチェックインする体験とビジネスプロフィールに特化したデータ連携が価値となります。ビジネス系のアンケートやイベントの場面で大きな強みを発揮すると考えています。

仕組み

デジタル名刺ログインは認証に関わる機能のため、負荷とセキュリティの対策に重点をおいた設計をしています。特にQRコード読み取りでの認証フローはデバイスを跨ぐことになるため、インタラクティブな通信と本人確認が課題でした。

負荷対策

インタラクティブな通信では WebSocket を使っています。Eight のバックエンドは Rails を使っているので Action Cable で WebSocket を実現する選択肢もありましたが、QRコード表示毎にコネクションを貼る仕様上、プレビュー数の多いページに埋め込んだ時のサーバー負荷の懸念がありました。

そこで WebSocketのコネクション管理をサーバーレス化する構成としました。 QRコード表示後に API Gateway でコネクションを貼り、そのコネクションIDを Lambda 経由で DynamoDB に記録します。詳細は次の図となります。

これによりEightアプリでの承認を API Gateway 経由で通知するだけでよくなり、 Eightサーバーの負荷を大きく抑えることができました。ただ、WebSocket はネットワーク環境によって接続できないことがあるため、その場合はポーリングへフォールバックするようにしています。ポーリングの場合はEightサーバーの負荷となってしまうのですが、失敗率は3%前後であったため許容の判断をしています。

続いてはセキュリティ対策です。