グループウォレットアプリ『6gram』に、オリジナルの決済システムをわざわざ導入した理由

2021.03.12

新決済サービス『6gram』は、アプリ上でカードを発行しチャージして使うウォレットサービス。大きな特徴としては、グループで使えること。1つのアカウントで、複数のプリペイドカードを発行することができ、たとえば友達同士、家族間など複数名で利用することが可能です。

今回は、そんな『6gram』の開発技術について聞きました。ID・ペイメント事業部 システム部マネージャーとして自社のID管理やペイメントシステムの開発を統括している田岡が語ります。

 

田岡 文利(たおか ふみとし)
2012年新卒として入社。SNS「mixi」でサーバー、クライアント問わず幅広いサービス開発を担当したのち、経営企画本部に異動。グループ会社の開発支援のために、開発プロセス改善や基幹システムの開発に注力。2016年XFLAGに異動し、サービスやゲームをつなぐプラットフォームの開発と運用を担当。現在はIDペイメント事業部のシステム部マネージャーとして、自社のID管理やペイメントシステムの開発を統括。

 

決済サービスで「PCI DSS」への対応は必須

━━最初に、『6gram』のサービスについて簡単に教えてください。

アプリ上ですぐにプリペイドカードを発行し、チャージして使うウォレットサービスです。インターネットでの買い物時はもちろん、タッチ決済に対応している日本全国のお店で使うことが可能。店舗の端末にお使いのスマートフォンをかざして、サッと馴染みのある方法で支払いをすることができます。

━━他のプリペイドカードとの大きな違いはどこですか?

いくつかありますが、大きな違いは、グループみんなでも使える点ですね。みんなで自由にお金を出し合って、支払うことができます。たとえば、複数人で何かイベントを行なった場合。あらかじめ、金額を決めてお金を出し合っておけば、あとから割り勘をしてお金を集めて…という手間がありません。いつもよりもちょっと便利に使っていただけると思いますね。

━━では、次に『6gram』の技術構成についてお聞きしたいです。

私たちが構築・運用しているのは、「サーバレスでのPCI DSS対応クレジット決済システム」になります。言い換えると、「PCI DSS」の基準に対応しながら、サーバをもたない構成をとっています。

開発言語やインフラというところでいうと、以下の内容になりますね。

・開発⾔語:Elixir
  ⼀部DynamoDBStreamsを経由したNodeJSや解析環境でPythonなど
 インフラ:AWS
 データベース:DynamoDB
 コンピュート:Fargate
 監視:CloudWatch、Rollbar、PagerDuty

━━「PCI DSS」の基準に対応しながら、サーバをもたない。このような技術構成にした背景は?

運用コストと負荷を軽減したいというのが大きな背景です。
前提の話にはなるのですが、クレジットカード決済情報を扱う上では、「PCI DSS」に準拠することが求められます。この「PCI DSS」というのは、クレジットカード情報や、ユーザーそれぞれの取引情報を厳格に保護するために策定された規定です。アカウントやセキュリティなど12要件、約400項目にわたって、細かく基準が設けられています。そこでいうと、私たちが作りたいウォレットサービスにおいて「PCI DSS」に対応することは必須条件だったわけです。

━━12要件、400項目とは、すごい数ですね。

そうなんです(笑)。しかも、「PCI DSS」は有効期限が1年間のため、更新のための監査を毎年受ける必要があります。その際、基準を満たす安全な運用を行なっていることの証拠として、運用に関する様々な記録を残しておく必要もあります。

また、現在運用されている PCI DSS は公開から数年が経過しており、近年のシステム運用のスタンダードからすると過剰に窮屈になっていたり、内容自体が古くなっていたりする部分もあるんですよね。

たとえば、パスワードに関しては、少なくとも90日ごとに変更するという要件がありますが、近年ではパスワードの強制的な定期変更はパスワード認証の強度を高めないため推奨しない、という意見が主流になってきています。これは一つの例ですが、このように鵜呑みにするのではなく、現状に合っている形は何なのか、本当に大事なことは何なのかを考えて、策を練っていく必要があると感じていました。

 

「PCI DSS」に準拠しながら、運用負荷を抑えるには

━━しかし、この基準に真正面から対応していったら、運用負荷がかなり上がりそうです。

おっしゃる通りです。私たちの大方針としても、「運用負荷をできるだけ下げたい」というものがありました。というのも、今では開発チームは10名ほどですが、初期の開発段階では5人規模の少人数体制でした。専門職ロールは設けず、全員で開発・運用を行なっていましたから、ここをどうクリアするかは、大きな課題の一つでしたね。

━━具体的にはどういった工夫を行なったんでしょうか?

例えばファイルの整合性を監視することを求める要件があるのですが、これに対応するには通常、コンテナ上に専用のソフトウェアを導入し、そのソフトウェア自体を最新状態に保ちつつ、動作状況を監視する仕組みを整える必要があります。最初私たちも同様の対応を行ないましたが、運用の負担が非常に大きかったんです。なんとかこの負荷を軽減できないかと検討し設計を見直した結果、コンテナのファイルシステムを ReadOnly モードで動作させファイルの変更をそもそも禁止することでこの負荷を回避できるようになりました。

━━管理するもの自体を減らすことで、運用コストを軽減されたと?

ええ、作業量は格段に減りました。
コンテナのホストやネットワークのアクセス権などは、AWSが適切に管理しています。AWSにはPCI DSSコンプライアントなマネージドサービスがいくつもあります。これらを組み合わせて利用することで、自分たちで全ての要件を満たすために工数を割かなくても、代わりにクラウドサービスがその工数の一部を払ってくれている形になるわけですね。

━━(笑)。コストダウンにもつながりますし、大きなメリットがあると感じます。一方で、デメリットだと思われている点は?

何かが起きた時には基本的に手出しができないところでしょうか。誰も侵入できないことが前提になっていますから、当然ながらサーバの調子がおかしいというときに、一般的な調査が出ないんです。ですから、アプリケーションで必要なログを出すなど、監視の工夫は重要になってきますね。

━━なるほど。他に技術構成での工夫はありますか?

データベースの扱いでしょうか。私たちはデータベースに DynamoDB を採用しています。決済システムのデータベースには高い可用性が求められますが、そのための管理運用の負担で手一杯になり、サービスのセキュリティや使い勝手がおろそかになっては本末転倒です。そこで、AWS のフルマネージドサービスである DynamoDB を採用しました。実際私たちがデータベースの管理運用に関してやることはほとんどない状態を維持できていて、サービスの向上に集中できています。あと、余談ですが、フルマネージドサービスはサービスの改善も勝手に行われるのも魅力の一つだと思いますね。

もう一つ、RDBは時間課金に対して、DynamoDBはリクエスト課金というところもポイントです。時間課金というのは、意外と無駄が多くて。待機時間は常に課金されている状態になるわけです。リクエスト課金のほうが無駄がなく、コストを減らすことにもつながりました。

ミクシィは RDBを採用しているプロダクトが多く、DynamoDBのようなKeyValueStoreを採用していることは稀です。なので、初期は設計を含めて苦労することがありました。開発メンバーの中には、RDBでどうやって設計するか逆に考えにくくなっているメンバーも出てきましたね。

 

要件を満たすパッケージがない。それなら自分たちでつくろう

━━そして、「サーバーレスPCI DSS対応クレジットカード決済」という基盤システムを運用しながら、『6gram』の開発を行なっていったわけですね。

そうです。『6gram』の開発をするにあたり、まずは必要要件を整理しました。私たちが必要としていたのは、カード番号や残高などを管理するイシュア機能と決済代行機能とよばれるものでした。インフラの構成として AWS のフルマネージドサービスをできるだけ活用するような構成を考えており、それが実現できるような外部ベンダーのパッケージ製品も探してみましたが、当時そのような製品は見つかりませんでした。

━━どうやって解決したのでしょうか?

諸々検討した結果…『6gram』に合ったものを社内で開発することにしました。もちろん、既製品を使うという選択もあったのですが、ランニングコストや一般的なPCI DSS対応を行なったときの運用コストなどを考えたら、内製したほうがよいのではないか、という結論に至ったんです。

━━オリジナルの決済システムをつくるって、すごい発想ですね。

言葉だけ聞くと確かにそうかもしれないです(笑)。でも、既製品だって、誰かが設計して、誰かが開発しているわけですよね。だったら、自分たちでもやれるよね、って。決済システムは、作り自体はシンプルですから、一つ一つのことは特別難しいことをするわけじゃないですし。そんな温度感でした。

あとは、ミクシィ社内の課題としても、決済とIDをまとめる基盤的な機能が欲しいという要望があったのも事実です。ですから、『6gram』のサービスから生まれたシステムを社内にもどんどん還元していきたいという気持ちも強くありました。実際に、『6gram』のシステムは、スポーツギフティングサービス『Unlim』や競輪ライブエンターテインメント『TIPSTAR』でも使われていますし、今後も利用を拡大していく予定です。

━━リリースしてみてトラブルはありませんでしたか?

システムにおける大きな課題はありませんでしたね。スムーズに展開できていると思います。サービスとしても順調に拡大していけていますし、クレジットカードのシステムでも、様々な機能を追加できるように開発を続けています。他にも、さまざまな決済方法が6gramや社内のサービスで使えるように準備していますね。新しい決済方法をスムーズに導入できるのは、自分たちで決済システムを作ったからというのを感じることがあります。決済方法の“接点”だけを変えれば、済んでしまう仕組みにしているので、障害が起きにくいですね。

━━画期的ですね。最後に、田岡さんが『決済サービス』について考えていることを教えてください。

決済サービスに携わる中で、世の中の雰囲気として、“決済に関わる部分は怖いから触らないでおこう”“下手にいろいろ触るのは危険だし、怖い”と感じられてるな、と思うことが多くあるんですよね。でも、決済の部分って、売上にダイレクトに影響を与える部分。本当はめちゃくちゃ大事なことなんです。

僕は決済の仕組みって気軽に使えるようにするべきだと考えています。今回作った決済基盤システムもそれを意識して作っているので、それを活用した6gramはサービス改善が気軽にできる形にできました。また、社内の決済基盤を使うサービス側でもいろんな決済方法を短時間で導入していたり、改善ができたりしています。

私たちが作っているものは、会社の営業利益に直結する重要なものだし、新しいビジネスを生み出す価値がある素晴らしいものです。チームのみんなと共に、そのことを証明していけたらいいですね。

人気の記事はこちら