はじめに
初めまして、まずは私の自己紹介ですが現在会社Susten Capital ManagementというFintechベンチャーでbackend兼インフラエンジニアとして働いております。
インフラは主にAWSを使っていて日頃AWSさんにはサポートも含めお世話になっており、そんな中こちらのイベントの招待メールが届いたので参加してくることにしました！
私自身このようなイベントに参加したことはないのでドキドキでしたが他の金融ベンチャーの方と繋がることができるいい機会だし、Fintechのベストプラクティスにどれだけ現在のサービスが追い付いているか確認する機会としても最適だと思ったので参加してみました。
この記事ではAWS Fintech Bootcampで学んだ金融サービスのAWS設計ベストプラクティスを項目ベースでまとめていこうと思います！
disclaimerとしてですがこの記事で紹介しているのはあくまで個人の見解であり、特定の団体を代表するものではなく、各自FICSのガイドラインなどを読みインフラ設計を行なってくださいませ。
良い金融サービスとは？
良い金融サービスとはどんなサービスでしょうか？
「障害に強い」、「メンテナンス時間が短い」、「障害時の普及が早い」、「データ漏洩が発生しない」などいくつかの項目が挙げられるかと思います。
金融以外のサービスでももちろん上記事項を満たすことはとても大切ですが、顧客のお金を扱う金融サービスでは特に上記事項を意識する必要があります。
そこで金融サービスを提供する上で守らなければいけない規則がいくつか存在します。有名なところだと以下の通りです。
金融サービスではサービス提供資格取得の際や他社とのAPI連携の際に上記項目を満たしているか、該当する認定証の提示または自己申告ベースのセキュリティチェックシートを提出する必要があります。
Fintechスタートアップのジレンマ
金融サービスを提供するには満たすべき項目が多く、どうしてもスピードを重視する必要があるスタートアップには障壁となります。
スタートアップにとって一番注力すべき箇所は「ビジネスにフォーカスする」ということです。コンプラ要件を満たしたり堅牢なインフラを設計することももちろん大事ですがそれらの構築に時間をかけていては資金が尽きてサービスローンチまでに生き絶えてしまいます。
そこでスタートアップはコンプラ要件、システムの可用性をAWSにできるだけお願いすることで市場に提供したいサービスの開発に時間が当てられるようになります。
AWSには「責任共有モデル」という考えがあり、AWS管理下のサービスを利用することでシステムに関する責任がAWS側に委譲されます。
というわけでAWSにできるだけコンプラ要件や可用性などの「守り」の部分をお願いする上で、参考になった使用方法以下9選を紹介していきたいと思います。
AWS Fintech Best Practice9選
1. フルマネージドサービスを利用して責任を委譲すべし
AWSが提供するサービスにはマネージドサービスと呼ばれる一つの機能を提供するサービスと複数機能が最初から付いてくるフルマネージドサービスというものがある。
例えばS3とcloudfrontとgithub actionsを用いてフロントエンドをホストしdeploy pipelineを構築することができる。
だがAmplifyを使えばs3とcloudfrontを一緒に構築してくれdeploy pipelineもgithubアカウント認証を行うだけで自動でPRやbranchに紐づいたURLを発行しデプロイしてくれる。
s3+cloudfrontの方がより細かい設定は可能になるが初期フェーズではAmplifyに全てまるっとお願いし細かい設定をAWS管理下とすることで「責任共有モデル」の観点からもAWSに責任が委譲されるのでメンテナンス性・保守性の高いサービス構築を素早く行うことができる。
2. KMSでECSもRDSも暗号化すべき
AWSが提供するKMSと呼ばれるサービスを利用することで暗号化・複合化が簡単かつセキュアにできる。
EC2、ECS、RDSもボリュームをKMSを用いて暗号化することができるので可能な限り暗号化すべき。
RDSなどは作成時に暗号化を指定しないと後からenableできないので注意が必要。
3. KMSはAWS defaultではなく発行した鍵を使うべき
KMSの鍵の管理はFISCの要件で「暗号化keyは自社のコントロール化に置いたいつでも削除・更新できるものを使うこと」という記載があるのでAWSがdefaultで提供するものではなく独自に発行した鍵を使うのがベストプラクティス。
4. App Runnerは責任共有モデルにおいてVPC, LB周りもAWSに移譲されるのでおすすめ
AWSが提供するApp RunnerというサービスはECS+VPC+LBを一括で管理してくれauto scalingやdeploy pipelineなども構築できるフルマネージド型のサービス。
APIサーバーを構築する際ECS fargateを利用するとVPC、LBなどを構築する必要があるがそれをまるっとAWSにお任せできる。責任共有モデルの観点からもApp Runnerを利用することで必要なリソースを簡単かつ堅牢に作成できる。
ただしApp Runnerが発行するURLはpublicになり流入制限をかけることはできないのでWAFを前段に立てたい場合などは注意が必要。
5. NAT GWがいらないsubnetはprivate subnetではなくisolated subnetを使うべき
AWS subnetにはpublic, private, isolatedの3種類があり可能な限りisolated→private→publicの順に使用を検討すべき。
publicは外のネットワークとのIN/OUT双方向のtrafficを許容するsubnetであり、privateはOutのみ許容、isolatedはVPC内のtrafficのみ許容する。
例を挙げるとアプリ用のAPIサーバーはpublic subnetに置かれたEC2、社内内部で使用するバッチサーバーはprivate subnet(ECRからimageをpullするのに外のNetworkにアクセスするtrafficを許可する必要あり)、DBはisolated subnetに設置する。
API GWとVPC linkを用いることでAPIサーバーもprivate subnetに置く方法もあるので可能な限り閉ざされたsubnet下にリソースを置く方がよりセキュアになる。
6. subnet間の通信にはsecurity groupだけでなくnetwork aclを使用してsubnet間の通信も制限すべき
インフラリソース間の通信を許可するためにSecurity Groupを使用しているケースは多いがそれだけではなくNetwork ACLも設置すべし。
Security GroupとNetwork ACLの違いはSecurity Groupがインスタンス単位で設定するファイアウォール設定なのに対しNetwork ACLはサブネット単位で設定するファイアウォール設定となっている。
7. DBにはAurora Serverless v2を使用すべし
Aurora Serverless v2はDBのフルマネージド型サービスでAutoscaling, Fail over, multiAZ対応などの管理をしてくれるサービス。v1ではmultiAZ非対応、scale upが遅い等の懸念があったがv2では大幅に改善しており積極的に使用していきたいサービスである。
特にto CのFintechベンチャーでは負荷が見えづらい場合も多いと考えられるが、Aurora Serverless v2 ではシームレスなスケーリングでこれに対応できる。
一点気をつける点としてはmysqlの場合8.0以降しか使用できないので5.x系の場合は今の構成のまま8.0に上げてから導入検討するのがベター。
8. WAFは可能な限り前段に置くと良い
ALBとCloudfrontを両方使う場合WAFはどちらにも設置できるが前段のcloudfrontにつけた方がベター。理由としてはCloudfrontにWAFを入れておくことでedge location側で不正アクセスを防いでくれるが、ALBに入れるとregionまではアクセスを許すことになり世界中の不特定多数からのアクセスが同一regionに集中してしまうため。
可能であればedge locationを持つcloudfrontにWAFを設定して不正なアクセスを弾くべし。
9. バッチはEvent Bridge+ECSがおすすめ
バッチ実行環境を構築する際はEvent Bridgeと呼ばれるサーバーレスイベントバスのサービスを用いてECSでtaskを実行するのがおすすめ。Event Bridgeでは定期実行やtaskの実行が簡単に設置でき、使用していないときはtask数を0にすることで費用を抑えられるのが特徴。
バッチ専用のコンテナを必要な時に必要なスペックで起動することにより不要なコストがかかるのを防げる。logもECSからcloudwatchと連携することで簡単に収集・エラー検知の仕組みを構築できる。
感想
AWS App RunnerやServerless v2など最近GAとなったサービスも紹介されていて使ったことがなかったのでとても勉強になるbootcampでした！
またこのような機会があったら参加しようと思います、会場でお会いした方々及び開催してくださったAWSのSAの皆さんありがとうございました！！
Reference