えんたつの記録

Cookpad Tech Kitchen #22 決済基盤の最新事情 - connpassに参加してきました。以下は内容のメモですが、それぞれスライドを公開していらっしゃっているので、そちら見た方がいいです。

概要から入り考えていることと目指していることを紹介しつつ最新情報を紹介したりととても整理された上で良い内容でした。



「クックパッドにおける決済基盤の歴史とこれから」
20191127_financier.pdf - Speaker Deck

決済基盤とユーザー基板の部長
エンジニア募集しています
今３人

コンウェイ　システム設計は組織構造を反映させたものになる
逆コンウェイ？　望ましい組織構造を促進法させるためにチームと組織構造を進化させる

経理、カスタマーサポート、複数のサービス、複数サイトの決済ゲートウエイ
基板がないと実装がばらばらに、経理も都度対応、契約書も複数

経理、カスタマーサポートは決済基盤とやりとり、サービスは決済基盤とやりとり
社内のセンモンチシキのハブとなる

フィナンシェという共通課金基盤を作った Financier
クックパッド本体から分離して作った　2012
様々な課金方法の差違を吸収
定期課金、その履歴
整合性
管理画面からキャンセルできるように
知見の集約

やらないこと
商品管理
個々のサービスに依存すること


歴史
2013-2017 ウェブしかなかった、直接アクセスポイントもある
2018- アプリ、アプリ内課金、アプリからデータ移動
2018- アプリ内課金、サブスクリプションとそのユーザー完了、課金のappleアカウントとユーザーは別なので統一で扱うAPIとSDKを作った

これから
ユーザー完了基盤との連携強化
c2c


「アプリ内課金の最新事情 クライアントサイド編」
アプリ内課金の最新事情 クライアントサイド編 / In-app Purchase in Cookpad 2019 - Speaker Deck

O'Reilly Japan - Design It!がいい本

定期課金機能の新機能を取り入れつつある
Cuisineというシステム
クックパッドは基本的に定期購入で、運用実績はある
iOS Promoting IAP, Promotional Offers
Android
アップグレード、ダウングレードは意図的に使っていない

API、実装ガイドライン、SDK提供
意図的に依存ライブラリを減らしている
課金まわりには固有ロジックが入る可能性が高いので自作
ここでいう実装ガイドラインとは、課金に対して各アプリで自前実装する際のガイドライン

共通化はやればできる
機能の話を受け手から動くと遅い
新機能の取り込みつつ、なるべき汎用的な概念に落とし込む


「アプリ内定期購入における状態管理と”通知”の活用 」
アプリ内定期購入における状態管理と”通知”の活用 / Using notifications to handle the states of in-app subscriptions - Speaker Deck

お金の支払い状態と、サービスイン利用状態を合わせる

ボーリングによる
有効期限が切れたら最新状態を取得
だが、購読にはオンオフ以外がある

自動更新の停止
猶予期間
商品変更
試用期間
延期
一時停止
価格変更
subscription offer

ボーリングだけだと全部はカバーできない
通知ができる前からサービスやっている


定期課金の通知
webhookで受信
状態を更新
通知のログをDWHに保存
各サービスにはAmazon SNSで通知

Android
クックパッドでは主にAWSなのでAWSで受け取っている
SQLで履歴とかを取れるようになる
利用方法
猶予期間に入ったユーザーへの通知
自動更新をオフにしたユーザーを追う
問い合わせ対応
施策のための調査

Apple
httpのpostで来る
複数の内容が入っていたりする
スキーマが一定ではない
複数行みないと何があったかわからない
DWHにはgoogleに寄せるように保存
2019-11-22に新しい通知がリリースされてました


QAコーナー
・不正決済への対応
クライアント上での課金処理ログを送る、サーバーでのレシート検証
ログはサポート部署にも使える
サーバーでもログを取る、監査ログ
アプリそのものの改ざんとかも含む話になる
クックパッドのサービスは換金できないのでそこまでではない
・運用ふえない？
運用系はどんどん自動化したり、来る前に解決できるようにする
・SDK組み込むサポートどうしてる？
ガイドラインで対応、導入時支援
・appleレシートの仕様変更への対応できるようにしたは？iOS6
フィールドの型が変わったのでそこで判定、クラス内で抽象化
・通知のとりこぼしは？
ボーリングがメイン、通知はサブ
・異なる定期課金の抽象化は？アプリとカード
アプリ内課金は分けた
定期購読の管理は抽象化
・レガシーコードへの対応は
レガシーコードがあるのはクックパッド本体
データ移行して残ったデータは協力したりしてる
・複数決済からの重複課金処理への対応は
自動検知と重複課金
アプリで警告を出し、そこから問い合わせしてもらう


採用CMタイム

DMM meetup #14 DMMを支えるプラットフォームの裏側 - connpass

決済周りを知りたくて参加して来ました。
以下メモです。


「プラットフォーム事業部の役割と目指す姿」

DMM、非上場会員数3000万
様々な事業がある

プラットフォームの役割分類
レコード、インサイト、エンゲージメント
採用してます



「ミライのデータエンジニア」
ミライのデータエンジニア - Speaker Deck

全社員から来るデータ活用要求、チームは６人
利用者の増加、雑なクエリ、増えるデータ量
セルフサービス化
gcpでデータ収集、データはオンプレのhadoop
このhadoopもgcp bigqueryに置くのを予定
募集してます



「巨大なレガシーコードをビッグデータでテストケースに変換する」
巨大なレガシーコードをビッグデータでテストケースに変換する - Speaker Deck

@rugamaga
商品情報持ってる、使われる場所が多く複雑だった。昔は。
直した手順。
ログをだすようにする
ログをテストケースにする
リファクタリングする

ロギング
aspect weaving
関数名と引数と戻り値、別途そのときのAPI,DBへのリクエスト
それらのデータを元にテストができる。大量だったのでサンプリングした。
よく使われる内容が優先される。
２人４ヶ月でレガシーシステムを置き換えられた。
募集中




「月間140億円の売上を支えるペイメントサービスの挑戦」

支払い機能、ポイント
クレジットカード
月間140億円、リクエスト2.3億
４チーム３３人

１０年で３００事業のために

キーワード
１０分でサービスイン
独立して利用できる
大量のリクエストを捌ける
データマイニングで情報を提供できる

最近つくったもの
payment gateway
支払い後、決済代行業者間からの通知を受け取る
api gateway, s3, aws lambda, sqs
まずs3にログ保存、sqsに入れて、別のlambdaがhook。dmmに送りつつ、workflowでリトライ処理。
非同期、サーバーレス。

intellij ultimateライセンスくれる
募集してます




「DMMの認証・会員情報プラットフォームの今とこれから」

金沢事業所
今年の７月に４事業所を統合
チーム３３名を省略するとMAST

アカウント登録、登録、会員情報
利用できないとそのまま機会損失になる
理想は止まらないこと、いかに信頼性を向上させるか

起こりにくくする
影響範囲を小さくする
すぐに復旧できるようにする

昔
検知は問い合わせベース
今
cloudwatch,datadog,kibanaによる検知、モニタリング
複数のサーバーにまたがるログ
slackからlambda経由でコマンドを実行できる
障害連絡もslackテンプレート化

PCがなくても対応できるようにした

次
MFA
マルチセッション
レガシー脱却
などなど

ユーザーにシームレス
時代の当たり前を提供したい



所感
独立した事業に共通基盤を提供すること、古くからあるシステムをどう改修するか、など、目的を持った上で改善したり入れ替えていくことが回そうとしたり回したという話がメイン。このジャンルの話は企業の考え方そのものともかかわるので面白い。