Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
グループウォレットアプリ6gramの運用をはじめてみた / 6gram SRE NEXT 2020
Ryosuke SATO
January 25, 2020
Technology
6
9.1k
グループウォレットアプリ6gramの運用をはじめてみた / 6gram SRE NEXT 2020
SRE NEXT 2020
Ryosuke SATO
January 25, 2020
Tweet
Share
More Decks by Ryosuke SATO
See All by Ryosuke SATO
Our monitoring past and future tale
ryosan470
3
1.1k
the background of mixi git challenge
ryosan470
1
290
新米SREとしての半年
ryosan470
1
2.5k
Other Decks in Technology
See All in Technology
220428event_overview
caddi_eng
2
210
Stripe Search APIを利用した、LINEとStripeの顧客情報連携/line-dc-202205
stripehideokamoto
0
120
New Features in C# 10/11
chack411
0
790
GitHub 엔터프라이즈 어카운트 소개 및 엔터프라이즈 서버 구축 경험
posquit0
1
140
TypeScript 4.7と型レベルプログラミング
uhyo
5
3.2k
Salesforce女子部-権限についてまとめてみたその1
sfggjp
0
180
⚡Lightdashを試してみた
k_data_analyst
0
170
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama
0
580
AWS CloudShellという推しサービスについて / lt-20220502-jawsug-cli
becominn
0
650
Power Query 日時の変換でちょっと焦ったケース +1 / Power Query Some cases
ishiayaya
0
150
Learning from AWS Customer Security Incidents [2022]
ramimac
0
500
Devに力を授けたいSREのあゆみ / SRE that wants to empower developers
tocyuki
3
460
Featured
See All Featured
Code Review Best Practice
trishagee
41
6.7k
Intergalactic Javascript Robots from Outer Space
tanoku
261
25k
Writing Fast Ruby
sferik
612
57k
Product Roadmaps are Hard
iamctodd
34
6.1k
Bootstrapping a Software Product
garrettdimon
295
110k
Embracing the Ebb and Flow
colly
73
3.3k
Rebuilding a faster, lazier Slack
samanthasiow
62
7.2k
Raft: Consensus for Rubyists
vanstee
126
5.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
38
12k
KATA
mclloyd
7
8.6k
Robots, Beer and Maslow
schacon
152
7.1k
Designing for Performance
lara
596
63k
Transcript
グループウォレットアプリ 6gram の運⽤をはじめてみた SRE NEXT 2020 株式会社ミクシィ ID・ペイメント事業部 佐藤 良祐
2020/01/25
⾃⼰紹介 佐藤 良祐 (@ryosan-470 / @jtwp470) 株式会社ミクシィ ID・ペイメント事業部 2017年4⽉⼊社 ‣
~ 2019/04 モンスターストライク⽇本版SRE ‣ 2019/04 ~ 新規の決済系サービス「6gram」や社内決済基盤の開発と運⽤
None
「6gram」サービス紹介 ひとりでも、グループでも使うことのできるウォレットサービス グループに⼊れたお⾦をシェアしたり、インスタントに発⾏したプリペイドカードに残⾼を割 り付けたりといろんな使い⽅ができる ‣ JCB プリペイドカードを1アカウントで複数枚発⾏できる ‣ ApplePay /
GooglePay と連携して QUICPay+ 決済 ‣ iOS では コンタクトレス決済に対応 ‣ リアルカードも発⾏予定 2019年11⽉にAndroid版を先⾏リリース ‣ 現在は完全招待制
None
iOSは審査中 (もうしばらくお待ちください)
今⽇は配布物の中に招待コードあります! QRコードを読み取って是⾮使ってくださいー
もくじ 決済サービスの基礎的な概念 PCI DSS 完全準拠 の⼯夫 6gram システム構成 開発、運⽤体制 課題
決済サービスの基礎的な概念 (出⾦ / カード発⾏、管理) ユーザー 加盟店 アクワイアラ 国際ブランド クレジットカード決済 イシュア
カード発⾏業務 加盟店管理 VISA / JCBなど ISO8583形式の電⽂ でやりとり ISO8583形式の電⽂ でやりとり
決済サービスの基礎的な概念 (⼊⾦ / 決済代⾏) ユーザー アクワイアラ 国際ブランド クレジットカードによる⼊⾦ 加盟店管理 VISA
/ JCBなど ISO8583形式の電⽂ でやりとり ISO8583形式の電⽂ でやりとり イシュア 決済代⾏
決済サービスの基礎的な概念 (まとめ) 「出⾦」と「⼊⾦」の両⽅とも⾃社でシステムを実装 「出⾦」では、プリペイドカードの発⾏、管理 「⼊⾦」では、ユーザーが⼊⾦するために必要なカード情報を保持 ⇨ これらをサポートするためには、「PCI DSS」に準拠しなければならない
PCI DSS とは? クレジットカード業界のセキュリティ基準 これに準拠することにより、カード番号などの情報を保持することができる 12要件、約400項⽬ 数年に⼀度、基準が改訂される
PCI DSS 完全準拠の⼯夫
アカウント要件 要件8 コンピュータにアクセスできる各ユーザーに⼀意のIDを割り当てる ‣ 8.2.3 パスワードは以下を満たす必要がある ‣ パスワードに7⽂字以上含まれる ‣ 数字と英⽂字を両⽅含む
‣ 8.2.4 パスワードは少なくとも90⽇ごとに変更する ‣ 8.2.5 これまで使⽤した最後の4つのパスワードのいずれかで同じである新しいパス ワードを許可しない
アカウント要件 パスワード管理めんどくさいなぁ
セキュリティ要件 要件5 すべてのシステムをマルウェアから保護する ⇨ 稼働中のサーバーにウイルスチェックなどが必要 要件11 セキュリティシステムおよびプロセスを定期的にテストする ‣ 11.4 侵⼊検知/侵⼊防⽌システムを使⽤して警告する
‣ 11.5 変更検出メカニズムを導⼊してファイル変更を監視、警告する
セキュリティ要件 ウイルス検知ソフトウェア、侵⼊検知ソフトウェアが落ちてもインシデント
われわれの⼤⽅針 ⇨ 運⽤負荷をできるだけさげたい
インスタンスを使わない
インスタンスを使わない
インスタンスを使わないことで何が嬉しいか アカウント管理をIAMに集約しやすい 90⽇に1回のパスワード変更祭り (しかも4回分は使えない) をしなくてすむ 管理すべきコンポーネントを減らすことができる 運⽤負荷を下げるために重要
さらに
コンテナをRead Only で動かす
セキュリティ要件 要件5 すべてのシステムをマルウェアから保護する ⇨ 稼働中のサーバーにウイルスチェックなどが必要 要件11 セキュリティシステムおよびプロセスを定期的にテストする ‣ 11.4 侵⼊検知/侵⼊防⽌システムを使⽤して警告する
‣ 11.5 変更検出メカニズムを導⼊してファイル変更を監視、警告する
インスタンスレス + Read Only で何が嬉しいか 侵⼊検知の仕組みを導⼊する必要がない リモートコンソールが存在しないためそもそも侵⼊できない ファイル変更検出ソフトウェアが不要になる Read Only
なのでそもそも書き換えができない
コンテナをRead Only で動かす⼯夫 コンテナはAWS Fargate上で動かしている コンテナは Read Only で稼働させている ‣
具体的には、ECSタスク定義の readonlyRootFileSystem を true にしている ⼯夫点 ‣ ログはファイルを作成せず、標準出⼒に ‣ 起動時に作成されるディレクトリはあらかじめ作成しておく
クレジットカード情報の保有についての制約 要件3 保存されるクレジットカード情報を保護する ‣ 3.4 クレジットカード情報は暗号化などの仕組みを⽤いて保存する ‣ 3.5.2 クレジットカード情報へのアクセスを必要最低限に制限する ‣
3.5.3 暗号化に使⽤される鍵の保存 要件7 クレジットカード情報へのアクセスを制限する 要件10 クレジットカード情報へのアクセスを追跡、監視する
クレジットカード情報の保有について クレジットカード情報をはじめとするすべてのデータをDynamoDBに保存 AWSには ‣ IAMをベースとした細かいアクセス制御 ‣ KMSによるテーブルの透過的暗号化 さらにスケーリングや管理をすべてAWSにお任せできる 運⽤をはじめて、DynamoDBを起因とする障害は今の所ない
その他の⼯夫点
定時実⾏処理 バッチ処理には CodeBuild を使⽤ 売上データを取得、オーソリゼーション業務などの定時処理をすべてCodeBuildで 採⽤理由 ‣ AWS Batch は裏でEC2が爆誕するからだめ
‣ Lambdaは実⾏時間が短すぎる ‣ Fargate で 「タスクを動かす」は⼀部やっていたがリトライなどを⼿動でやるのが ⼤変だった ‣ さらに「読み取り専⽤」環境では動かないソフトウェアがあった
リリースパイプラインの⾃動化 CodePipeline と CodeBuild を組み合わせたリリースパイプラインの構築 リリースの障壁をできる限り下げ、アジリティーを確保 コンテナイメージ のビルドと ECRへのプッシュ コンテナイメージ
ウイルススキャン Fargateへの ブルーグリーン デプロイ 要件5 のウイルススキャンを満たす
「6gram」システム構成図
「6gram」システム構成 ‣ 開発⾔語: Elixir ‣ ⼀部 DynamoDB Streams を経由した NodeJS
や解析環境で Python など ‣ インフラ: AWS ‣ データベース: DynamoDB ‣ コンピュート: Fargate ‣ 監視: CloudWatch、Rollbar ほぼすべてのコンポーネント (⼊出⾦処理、カード会社とのやりとり) は内製 ‣ なぜ内製しているのか、Elixir採⽤理由などは、Developer Boost 2019の「Elixirで 決済サービスを作ってみた」を! https://speakerdeck.com/enerick/elixir-dejue-ji-sabisuwotukututemita
PCI DSS 完全準拠の⼯夫まとめ 少⼈数で運⽤していくためにできる限り運⽤負荷を減らす努⼒をしている フルマネージドサービスを使うことで簡単に⾼い信頼性を確保できる アプリケーションの改善に注⼒できる
開発、運⽤体制
開発、運⽤体制 チーム構成 エンジニアリングマネージャ 1名 サーバーサイドエンジニア 5名 クライアントエンジニア 2名 SRE といった専⾨職ロールは存在せず、
全員で開発、運⽤を⾏っている
運⽤の⼯夫 (エラーの通知) Rollbar を⽤いて、対処する必要があるものに対してはSlack通知 具体的に responder が何をすればいいか記載しておくことで素早い対処が可能
運⽤の⼯夫 (インシデント対応計画) インシデント対応計画シミュレーションの実施 (年に1回程度) サイバー攻撃、セキュリティに関連するバグ、インフラストラクチャのバグなどの条 件を机上でシミュレーションする インシデントハンドリングを経験、改善点などの気づきが得られる
課題
課題 可観測性が低い 現状では細かいトレーシングやログなどを取りきれていない 分散トレースなどがほしい ⾃動化を突き詰めていく ⼈間の判断をできるかぎり減らす 開発環境をより本番環境に近づけていく 決済ネットワークとのつなぎこみを含め開発環境だけで再現できる領域を増やしてい きたい
None