グループウォレットアプリ6gramの運用をはじめてみた / 6gram SRE NEXT 2020

Transcript

1. 1.

   グループウォレットアプリ 6gram の運⽤をはじめてみた SRE NEXT 2020 株式会社ミクシィ ID・ペイメント事業部 佐藤 良祐

   2020/01/25
2. 2.

   ⾃⼰紹介 佐藤 良祐 (@ryosan-470 / @jtwp470) 株式会社ミクシィ ID・ペイメント事業部 2017年4⽉⼊社 ‣

   ~ 2019/04 モンスターストライク⽇本版SRE ‣ 2019/04 ~ 新規の決済系サービス「6gram」や社内決済基盤の開発と運⽤
3. 3.

   None
4. 4.

   「6gram」サービス紹介 ひとりでも、グループでも使うことのできるウォレットサービス グループに⼊れたお⾦をシェアしたり、インスタントに発⾏したプリペイドカードに残⾼を割 り付けたりといろんな使い⽅ができる ‣ JCB プリペイドカードを1アカウントで複数枚発⾏できる ‣ ApplePay /

   GooglePay と連携して QUICPay+ 決済 ‣ iOS では コンタクトレス決済に対応 ‣ リアルカードも発⾏予定 2019年11⽉にAndroid版を先⾏リリース ‣ 現在は完全招待制
5. 5.

   None
6. 6.

   iOSは審査中 (もうしばらくお待ちください)

7. 7.

   今⽇は配布物の中に招待コードあります！ QRコードを読み取って是⾮使ってくださいー

8. 8.

   もくじ 決済サービスの基礎的な概念 PCI DSS 完全準拠 の⼯夫 6gram システム構成 開発、運⽤体制 課題

9. 9.

   決済サービスの基礎的な概念 (出⾦ / カード発⾏、管理) ユーザー 加盟店 アクワイアラ 国際ブランド クレジットカード決済 イシュア

   カード発⾏業務 加盟店管理 VISA / JCBなど ISO8583形式の電⽂ でやりとり ISO8583形式の電⽂ でやりとり
10. 10.

    決済サービスの基礎的な概念 (⼊⾦ / 決済代⾏) ユーザー アクワイアラ 国際ブランド クレジットカードによる⼊⾦ 加盟店管理 VISA

    / JCBなど ISO8583形式の電⽂ でやりとり ISO8583形式の電⽂ でやりとり イシュア 決済代⾏
11. 11.

    決済サービスの基礎的な概念 (まとめ) 「出⾦」と「⼊⾦」の両⽅とも⾃社でシステムを実装 「出⾦」では、プリペイドカードの発⾏、管理 「⼊⾦」では、ユーザーが⼊⾦するために必要なカード情報を保持 ⇨ これらをサポートするためには、「PCI DSS」に準拠しなければならない

12. 12.

    PCI DSS とは? クレジットカード業界のセキュリティ基準 これに準拠することにより、カード番号などの情報を保持することができる 12要件、約400項⽬ 数年に⼀度、基準が改訂される

13. 13.

    PCI DSS 完全準拠の⼯夫

14. 14.

    アカウント要件 要件8 コンピュータにアクセスできる各ユーザーに⼀意のIDを割り当てる ‣ 8.2.3 パスワードは以下を満たす必要がある ‣ パスワードに7⽂字以上含まれる ‣ 数字と英⽂字を両⽅含む

    ‣ 8.2.4 パスワードは少なくとも90⽇ごとに変更する ‣ 8.2.5 これまで使⽤した最後の4つのパスワードのいずれかで同じである新しいパス ワードを許可しない
15. 15.

    アカウント要件 パスワード管理めんどくさいなぁ

16. 16.

    セキュリティ要件 要件5 すべてのシステムをマルウェアから保護する ⇨ 稼働中のサーバーにウイルスチェックなどが必要 要件11 セキュリティシステムおよびプロセスを定期的にテストする ‣ 11.4 侵⼊検知/侵⼊防⽌システムを使⽤して警告する

    ‣ 11.5 変更検出メカニズムを導⼊してファイル変更を監視、警告する
17. 17.

    セキュリティ要件 ウイルス検知ソフトウェア、侵⼊検知ソフトウェアが落ちてもインシデント

18. 18.

    われわれの⼤⽅針 ⇨ 運⽤負荷をできるだけさげたい

19. 19.

    インスタンスを使わない

20. 20.

    インスタンスを使わない

21. 21.

    インスタンスを使わないことで何が嬉しいか アカウント管理をIAMに集約しやすい 90⽇に1回のパスワード変更祭り (しかも4回分は使えない) をしなくてすむ 管理すべきコンポーネントを減らすことができる 運⽤負荷を下げるために重要

22. 22.

    さらに

23. 23.

    コンテナをRead Only で動かす

24. 24.

    セキュリティ要件 要件5 すべてのシステムをマルウェアから保護する ⇨ 稼働中のサーバーにウイルスチェックなどが必要 要件11 セキュリティシステムおよびプロセスを定期的にテストする ‣ 11.4 侵⼊検知/侵⼊防⽌システムを使⽤して警告する

    ‣ 11.5 変更検出メカニズムを導⼊してファイル変更を監視、警告する
25. 25.

    インスタンスレス + Read Only で何が嬉しいか 侵⼊検知の仕組みを導⼊する必要がない リモートコンソールが存在しないためそもそも侵⼊できない ファイル変更検出ソフトウェアが不要になる Read Only

    なのでそもそも書き換えができない
26. 26.

    コンテナをRead Only で動かす⼯夫 コンテナはAWS Fargate上で動かしている コンテナは Read Only で稼働させている ‣

    具体的には、ECSタスク定義の readonlyRootFileSystem を true にしている ⼯夫点 ‣ ログはファイルを作成せず、標準出⼒に ‣ 起動時に作成されるディレクトリはあらかじめ作成しておく
27. 27.

    クレジットカード情報の保有についての制約 要件3 保存されるクレジットカード情報を保護する ‣ 3.4 クレジットカード情報は暗号化などの仕組みを⽤いて保存する ‣ 3.5.2 クレジットカード情報へのアクセスを必要最低限に制限する ‣

    3.5.3 暗号化に使⽤される鍵の保存 要件7 クレジットカード情報へのアクセスを制限する 要件10 クレジットカード情報へのアクセスを追跡、監視する
28. 28.

    クレジットカード情報の保有について クレジットカード情報をはじめとするすべてのデータをDynamoDBに保存 AWSには ‣ IAMをベースとした細かいアクセス制御 ‣ KMSによるテーブルの透過的暗号化 さらにスケーリングや管理をすべてAWSにお任せできる 運⽤をはじめて、DynamoDBを起因とする障害は今の所ない

29. 29.

    その他の⼯夫点

30. 30.

    定時実⾏処理 バッチ処理には CodeBuild を使⽤ 売上データを取得、オーソリゼーション業務などの定時処理をすべてCodeBuildで 採⽤理由 ‣ AWS Batch は裏でEC2が爆誕するからだめ

    ‣ Lambdaは実⾏時間が短すぎる ‣ Fargate で 「タスクを動かす」は⼀部やっていたがリトライなどを⼿動でやるのが ⼤変だった ‣ さらに「読み取り専⽤」環境では動かないソフトウェアがあった
31. 31.

    リリースパイプラインの⾃動化 CodePipeline と CodeBuild を組み合わせたリリースパイプラインの構築 リリースの障壁をできる限り下げ、アジリティーを確保 コンテナイメージ のビルドと ECRへのプッシュ コンテナイメージ

    ウイルススキャン Fargateへの ブルーグリーン デプロイ 要件5 のウイルススキャンを満たす
32. 32.

    「6gram」システム構成図

33. 33.

    「6gram」システム構成 ‣ 開発⾔語: Elixir ‣ ⼀部 DynamoDB Streams を経由した NodeJS

    や解析環境で Python など ‣ インフラ: AWS ‣ データベース: DynamoDB ‣ コンピュート: Fargate ‣ 監視: CloudWatch、Rollbar ほぼすべてのコンポーネント (⼊出⾦処理、カード会社とのやりとり) は内製 ‣ なぜ内製しているのか、Elixir採⽤理由などは、Developer Boost 2019の「Elixirで 決済サービスを作ってみた」を！ https://speakerdeck.com/enerick/elixir-dejue-ji-sabisuwotukututemita
34. 34.

    PCI DSS 完全準拠の⼯夫まとめ 少⼈数で運⽤していくためにできる限り運⽤負荷を減らす努⼒をしている フルマネージドサービスを使うことで簡単に⾼い信頼性を確保できる アプリケーションの改善に注⼒できる

35. 35.

    開発、運⽤体制

36. 36.

    開発、運⽤体制 チーム構成 エンジニアリングマネージャ 1名 サーバーサイドエンジニア 5名 クライアントエンジニア 2名 SRE といった専⾨職ロールは存在せず、

    全員で開発、運⽤を⾏っている
37. 37.

    運⽤の⼯夫 (エラーの通知) Rollbar を⽤いて、対処する必要があるものに対してはSlack通知 具体的に responder が何をすればいいか記載しておくことで素早い対処が可能

38. 38.

    運⽤の⼯夫 (インシデント対応計画) インシデント対応計画シミュレーションの実施 (年に1回程度) サイバー攻撃、セキュリティに関連するバグ、インフラストラクチャのバグなどの条 件を机上でシミュレーションする インシデントハンドリングを経験、改善点などの気づきが得られる

39. 39.

    課題

40. 40.

    課題 可観測性が低い 現状では細かいトレーシングやログなどを取りきれていない 分散トレースなどがほしい ⾃動化を突き詰めていく ⼈間の判断をできるかぎり減らす 開発環境をより本番環境に近づけていく 決済ネットワークとのつなぎこみを含め開発環境だけで再現できる領域を増やしてい きたい

41. 41.

    None