日本のNo.1 QRコード決済サービス
西中智樹氏（以下、西中）：「PayPayでのAWS活用事例について」と題して、PayPay Platformチーム・西中が発表いたします。
簡単に自己紹介します。西中智樹と申します。2018年12月よりPayPayで仕事をしていまして、現在、AWSなどのPayPayのインフラを所管するPlatformのチームに所属しています。好きなAWSサービスはEKSです。
本日のセッションのアジェンダになります。この順番でお話をいたします。
まず、現在のPayPayについてです。おかげさまでPayPayは日本のNo.1 QRコード決済サービスとなっています。PayPayはQRコードを利用した支払いだけではなく、オンラインサイトや請求書などでも利用できます。
また、「PayPayモール」「PayPayフリマ」「PayPayピックアップ」などのミニアプリがあり、タクシーの予約、ボーナスの運用など、さまざまなことに利用できるスーパーアプリです。
ユーザー数も2018年10月のリリースからどんどん増加し、現在では3,000万人を超すサービスとなっています。
PayPayを支えるインフラはどのようになっているのか
そんなPayPayを支えるインフラはどのようになっているのか、説明いたします。
こちらがPayPayのインフラの概要になります。この発表ではVPCやネットワークの構成などは割愛し、どんなサービスなのか、どんなコンポーネントを使ってサービスを構成しているのかということをお話しいたします。
PayPayのシステムは主に6つのブロックから成り立っています。こちら、それぞれ説明いたします。
まず、メインとなるアプリケーションとコンテンツのレイヤーについて。サーバのアプリケーションはすべてKubernetes上で運用しています。Kubernetesはkopsと呼ばれるツールを利用して構成しています。
構成は、Tokyoの3AZにまたがるようにMasterとWorkerノードを配置しています。Workerノードは、PayPayでJavaの利用が多いため、メモリ最適化であるR系のインスタンスファミリーを利用しています。現在、本番環境では2,500Pod、2,500アプリケーションを超える数を運用しています。
ただ、この構成には、定期的なKubernetesのバージョンアップに必要なOSのチェックやコンポーネントの依存関係の確認など時間を要すためバージョンアップに時間がかかるなど、いくつかの問題があります。
次にセキュリティです。
PayPayでは主にALBを利用していますが、ALBにWAFをインテグレートしています。WAFというはWebアプリのファイアウォールでオートスケールするサービスのため、EC2にインストールするのに比べ、通信量が増加してもボトルネックの心配のないサービスです。
それ以外にもShieldやGuardDutyなどセキュリティ関連のAWSサービスを利用し、PayPayのサービスを守っています。
最後にコンテンツの配信になります。こちらは一般的なS3とCloudFrontの構成になり、PayPayのドメインで配信できるよう設定しています。
メッセージングシステムとロギング
次にメッセージングシステムになります。ロギングの箇所でもメッセージングシステムを利用しているので、併せて説明いたします。
PayPayでは主に2つのメッセージングシステムを利用しています。
まずKafkaです。アプリ間通信とログのメッセージキューとして利用しています。こちらはAnsibleを利用して構築しています。Kafkaも3AZにまたがるようにBrokerとZookeeperを配置し、メッセージも同様に3AZで保持しています。
もう1つはSQSになります。こちらはマネージド型のメッセージキューとなります。PayPayの一部のサービスでも利用していまして、スケールアウトを管理する必要のないサービスとなっています。
次にロギングになります。PayPayのログはAWSのElasticsearchサービスに保管しており、Kibanaで可視化をしています。
次にログの書き込みフローについて説明します。KubernetesのアプリからKafkaにパブリッシュし、Logstashでそのメッセージをコンシュームして、Elasticsearchに書き込みをします。
ただ、この構成にも問題があり、ログを保持するためにElasticsearchのデータノードを追加する必要があります。1年ほど前は3ヶ月分ほど保持できましたが、サービスも増え、現在では1ヶ月分ほどしか保持できない状況になっています。
データストアについて
次にデータストアです。
PayPayでRDSを使いたい場合は、基本はAuroraを利用しています。現在PayPayではMaster/Slave構成で約40クラスタを管理しています。すべてのデータベースはAWSのOsaka regionにあるDBにレプリケーションを張ってバックアップをしており、こちらはDRの用途で利用しています。
Auroraの障害発生時は自動的にフェイルオーバーすることが可能であること、マルチAZでインスタンス配置が容易であることなど、運用しやすいメリットが多いのが特徴だと思います。また、MySQL互換できるため、アプリケーションサイドの負担が少ない点も特徴となります。
ElastiCacheは、弊社ではRedisとして利用しています。ミリ秒応用の必要なサービスに利用していて、クラスターモードでマルチAZ構成、複数シャードで構成しています。こちらも障害発生時は自動的にフェイルオーバーが可能であるため、運用のしやすいサービスです。
DynamoDBについては、ここ最近一部サービスで利用を始めました。ほかのサービスと比較しても環境構築・運用管理の手間が非常に少ないサービスかと思います。
また、導入しているサービスは常時高トラフィックではないため、RDSで代用した場合、瞬間的なトラフィックに対応する構成をする必要があります。DynamoDBの料金体系はRead・Writeの状況によって課金されるので、非常にメリットがあると感じています。
最後にTiDBです。こちらOSSのデータベースになります。決済トランザクションの増加に対応するため、Auroraから移管するかたちで導入いたしました。水平方向の拡張性、クラウドネイティブであること、高可用性などの特徴をもつデータベースとなります。こちらもMySQL互換で利用可能なもので、PayPayではEKSバージョンと EC2のバージョンの2種類を運用しています。
DataLakeについて
次にDataLakeになります。DataLakeというのはPayPayでのデータ基盤です。さまざまなデータベースからデータを抽出し可視化します。RDB、Kafka、FTP、S3などをデータソースとすることが可能で、PayPayで開発しているソフトウェア群になります。
現在の処理フローですが、DBから定期的にEMR上でSparkからデータを抽出、ETL後S3にアップロードし、またSparkにてBigQueryにアップロード、Data Studioで可視化という構成になります。こちらはAWSとGCPの混合の構成となっています。
現在この処理フローは改修中で、Apache Hudiなどを利用したものを検討中です。
これら全体のインフラはTerraformを利用して構築しており、安全かつ効率的に管理するために、インフラの状態をコードで定義可能なソリューションとなっています。
メリットとしては、GUIを操作することなくインフラの構成が変更可能な点や、インフラのバージョン管理・共有や再利用が可能なことが挙げられます。コードであるためチームメンバーによるレビューが容易な点もメリットです。
デメリットは、コード化するため、その手間が発生することです。また、一度始めた場合、GUI操作はご法度となります。もちろん緊急的なGUIで操作することもありますが、その場合は事後でコードを修正する必要あります。
今後のPayPayのインフラについて
今後のPayPayのインフラについて説明します。
まずはKubernetesをEKSに移行しようと考えています。フルマネージド型のKubernetesのサービスで、現在CI/CDの部分やTiDBの一部で運用を初めています。
こちらを導入するメリットとしては、Masterノードの管理やKubernetesに必要なOS、Kubernetesに必要な関連コンポーネントの依存関係などはAWSで管理してもらえるので、kopsで運用するのに比べバージョンアップなどの容易性が考えられます。
明確なデメリットとしては、マネージドサービスである以上、最新のバージョンが使えないなどといったことが挙げられますが、こちらはクリティカルな問題でないと考えています。
EKS移行は、PayPayの開発環境から始める予定です。
また、先ほど説明した「データを保持する量に比例してデータノードを増やす必要があった」という課題を解決し、ログの保持期間の拡大とコストの削減を行なうため、ElasticsearchでのUltraWarmを利用する予定です。
こちらはUltraWarm Nodeと呼ばれる新しい階層を作成し、S3を通じて一部データを検索する機能になります。導入後の想定ですが、ログ期間が1ヶ月から3ヶ月に拡大しますが、コストに関しては3〜4割減が可能と予測しています。
さまざまなロールのエンジニアを募集
最後になりますが、PayPayではさまざまなロールのエンジニアを募集しています。フロントエンドエンジニアからモバイル、私の所属するPlatform、セキュリティまで、あらゆるエンジニアを採用しています。
現在、PayPayでは20ヶ国以上から集まった200名を超えるメンバーがいまして、約6割が外国籍のメンバーです。非常に多様性のあふれるダイバーシティで刺激的な環境となっています。
こちらのQRコードがPayPayの採用ページとなっています。もし興味がありましたら、応募いただけるとありがたいです。
これにて発表を終わります。ありがとうございました。
質疑応答
坂井華子氏（以下、坂井）：西中様、ありがとうございました。それではここからsli.doでいただいた質問を見てまいりましょう。かなり質問をいただいていますので、いくつかピックアップしたいと思います。
まず1つ目、「AWS WAFはマネージドルールを活用していますでしょうか？」とのことですが、こちらいかがでしょうか？
西中：WAFに関しては、いくつかの製品を買わせていただいて導入しているものもございますし、マネージドを使っているものもございます。以上になります。
坂井：ありがとうございます。続きまして、「Kafkaはマネージドですか？ Kubernetes上で動いている感じでしょうか？」とのことですが、こちらはいかがでしょうか？
西中：主に使っているKafkaに関しては、自分たちでEC2の上でAnsibleを使って構成しています。一部サービスでマネージドも使っていますが、ここで説明したアプリケーション間の通信におけるというところに関しましてはマネージドではありません。
坂井：ありがとうございます。続きまして、では「KafkaとSQSを並行して利用している理由は何かありますか？」とのことですが、こちらいかがでしょうか？
西中：こちらに関しましては、サービスごとに技術選定を行ない、SQSに対してメリットがあると思ったチームが導入を進めていったかたちになりまして、今は弊社全体ではKafkaの利用のほうが多いんですけれども、SQSを使っているチームも存在している状態です。
坂井：ありがとうございます。続きまして、「Terraformが対応していないサービス等で苦労したことはありますか？」ということですが、こちらいかがでしょうか？
西中：弊社での体験は、Global Acceleratorと呼ばれるサービスを導入したときに、そもそもTerraformが対応していなかったため手で全部を作ったことがあるんですけれども、それを再度コードに起こす作業で非常に苦労したことがありました。
坂井：ありがとうございます。「TiDBでEKS版とEC2版の2種類を運用しているのはなぜでしょうか？」とのことですが、こちらいかがでしょうか？
西中：まず弊社ではEKS版を先行して導入を進めていました。その後いくつかのサービスで導入を進めたなかで、EC2版のほうがメリットがありました。EKS版とEC2版はサービスが異なるものなので、メリット・デメリットも異なるというところで運用を2種類にしています。
坂井：ありがとうございます。「EKSに移行するにあたって、バージョン以外の懸念点がもしありましたら教えていただけますでしょうか？」。
西中：今のところクリティカルに発生するとは思っていないんですけれども、AWSのVPCのサブネットのプライベートIPを1Podあたり1つずつ消費するというのが、AWS EKSの課題に一応挙げられるかなと思っています。ただ、これに関しては大きなCIDRを利用することでとくに懸念にはならないと思っています。
坂井：ありがとうございます。もう少し質問を見てまいりたいと思います。お願いいたします。
西中：はい。
坂井：次の質問です。「EKSはすべてTerraformで管理していますか？ 別のツールも併用されていますか？」とのことですが、いかがでしょうか？
西中： EKSを載せるネットワークの部分に関しましてはTerraformで管理しているんですけれども、EKS本体に関しましては、eksctlと呼ばれるツールが提供されていますので、そちらのツールを利用してEKS自体は構築しています。
坂井：ありがとうございます。次に「モニタリングの話はありませんでしたけれども、SaaSやAWSサービスなどのどういったものを利用されていますか？」とのことですが、いかがでしょうか？
西中：アプリケーションに関しましては、現在New RelicおよびDatadogを利用してメトリクスの監視をしています。
データベースに関しまして、Auroraに関しましてはAWSの提供しているPerformance Insightsと呼ばれるサービスを利用して監視をしています。それ以外にもVivid Cortexと呼ばれる製品を利用しています。先ほどの話にもありましたTiDBに関しましては、TiDB側のほうの仕組みでPrometheusとGrafanaを使って監視しています。
その他AWSのコンポーネントに関しましては、主にNew Relicのほうにメトリクスをインテグレートして集約して監視しています。
坂井：ありがとうございます。次で最後の質問とにしたいと思います。「TiDB以外で、通常であればこうしたいけど、PayPayだからこその理由で構成を変えた部分や、AWS活用で悩んだ部分があればおうかがいしたいです」とのことです。こちらいかがでしょうか？
西中：今のところ構成自体で悩んだというところはあまりなく、AWSの範囲内で非常に便利に使用しています。
坂井：ありがとうございます。以上でPayPay・西中様の登壇を終了します。ありがとうございました。
西中：ありがとうございました。
