「B/43（ビーヨンサン）」のシステムアーキテクチャ

B/43のインフラでは、AWSのマネージドサービスを積極的に活用しています。
PCI DSS準拠の観点から以下の点でAWSを採用しました。

• PCI DSS観点の大きな差はデータセンターなどの要件9がほぼ全てスキップできる事
• PCI DSSに限った話ではないが、企業にとってオンプレミスで構築/運用していくことはかなりのハードルになる事

クラウド基盤を使用するとは言えAWS、GCP、Azureなど色々ありますが、 私の今までのスキルセットと、セキュリティ実績が高かったことからAWSでいくことにしました。 AWSでは数多くのPCI DSSに準拠しているため、QSA(Qualified Security Assessor)も判断し易い環境であるのは間違いないと思います。

【参考】AWS における PCI DSS (Payment Card Industry Data Security Standard) 3.2.1 コンプライアンスガイド
https://d1.awsstatic.com/whitepapers/ja_JP/compliance/pci-dss-compliance-on-aws.pdf

サーバー環境はFargateを採用し、 readonlyRootFilesystem:true とすることでIDS/IPSの要件をクリアできました。

可用性向上の取り組み

AutoScaleに関してもCPUとメモリにてスケールするように設定するとともに、リクエスト数でもスケールするようにしています。1台のコンテナで捌けるリクエスト数の80%を超えた場合にスケールアウトするようにしています。
アーキテクチャ図にあるadmin-webは可用性とコストの観点でCloudFront+S3で構成されています。ログインはGoogleのSSOを利用しておりAWS Cognitoで実現しています。

デプロイフローについて

デプロイフローに関しては、githubにてマージされたことをトリガーにCodepipelineが動作してデプロイされます。弊社ではnewrelicを使ってパフォーマンス計測を行っており、デプロイのタイミングでパフォーマンスに変化が見られることが多いため、デプロイ時にデプロイメントマーカーをつけるようにしています。詳しくは こちら のブログをご覧ください。

バックエンドについて

バックエンドは以下の理由からGolangとRuby on Railsを採用しており、一部Pythonも採用しています。

• Golang
  • Visa電文規格やカード印刷工場への入稿フォーマットなど型を持って制御したい
  • 大量のリクエストを瞬間的に捌きたい
• Ruby on Rails
  • 開発者が開発経験豊富なため開発スピードの重視
  • コード量や開発者が増えても対処できる点
• Python
  • SREで管理しているLambdaの開発に利用
  • SREメンバーに馴染みがあるため採用

現在のアーキテクチャの課題と今後の展望

B/43は決済履歴も保存しており、決済とともにユーザー数が増えるとその決済履歴の閲覧によってDBの負荷が大きくなってしまいます。しかし現状ではReadとWriteの負荷を分散できておらず、Readの負荷をReadReplicaという形で分散することが課題の1つとなっています。 また、B/43では利用者の増加に伴い、アクセス数が増えてきております。PCIDSSの要件でもあるのですが、すべてのログをレビューする必要があります。SIEMテクノロジーの導入を行い、レビューをより確実に行うことも課題の1つとなっています。

◆執筆：エンジニアリング本部 SREチーム所属　上平 裕弥