GMOペイメントゲートウェイ の記事一覧

7/14（木）にGMO Developers Night#35 「クラウドを活用した新決済基盤サービス開発の裏側」をオンラインにて開催しました！今回は、新決済サービス「fincode byGMO」について、開発者がサービスやシステム概要だけでなく、技術発信への取組みや開発体制・進め方の裏話、そして今後の開発ロードマップなどを余すことなく、語り明かしました。イベント告知：https://developers.gmo.jp/20150/本記事はこちらのイベントの書き起こしとなりますので、ぜひご覧ください。 登壇者（敬称略） GMOペイメントゲートウェイ　システム本部 関連事業サービス統括部 執行役員・統括部長吉田 剛士fincode開発担当米山 純司fincode開発担当志野 直生 会社説明_GMO-PGとは 吉田GMOペイメントゲートウェイの会社案内を簡単にさせていただきます。「PGマルチペイメントサービス」が当社のメインサービスとなりまして、主にEC事業者様とカード会社、コンビニ、金融機関などの決済事業者様をつなぐゲートウェイ部分を提供しております。EC事業者様がカード決済やコンビニ決済の利便性を考え、決済手段を追加していく際に、自前で直接繋ごうとすると個別の契約だけでなく様々なインターフェースや接続制約を踏まえてのシステム連携、精算処理といった手続きを決済ごとに対応していく必要があります。これは、加盟店様においては時間・費用ともに高コストになってしまいます。それらの、諸々の仕組みを弊社にて集約、ワンストップで各種決済をご利用いただくためのサービスを「PGマルチペイメントサービス」でご提供させていただいております。決済手段の多様化、キャッシュレスのトレンドなど、決済ゲートウェイへのニーズは年々高まっていて、現時点ではグループで13万強のお客様にご利用いただいておりまして、41億件強、約9.5兆円の年間トランザクションを処理しております。会社としても、毎年25%の営業利益成長を目標とする中で、16期連続で増収増益を達成しております。取引量だけでなく、サービス拡充を含め、開発ニーズにも広がりを続けているという状況です。これら処理を支えている我々システム本部ですが、現在エンジニアは約200名在籍し、内製開発にこだわりまして、LinuxやJavaを中心としたオープンソースベースの開発を行っております。システム本部のベースは現在渋谷ですが、福岡にも開発拠点を設けており、毎年新卒と中途採用を合わせて30名以上のエンジニアの方々を採用しております。 対談 「fincode byGMO」 とは 吉田今回クラウドを活用した新決済基盤サービス開発の裏側と称しまして、GMOペイメントゲートウェイの連結子会社でありますGMOイプシロンが本年5月18日、つい2ヶ月ほど前ですけどもリリースさせていただきました、「fincode byGMO」というプロダクトの開発の裏側を中心に早速ご紹介させていただこうと考えております。先ほども紹介しましたが、弊社は「PGマルチペイメントサービス」やGMOイプシロンの決済サービスなど、決済代行システムを長年にわたり運営させていただいております。こちらは多くのお客様にご利用いただいていますが、お客様の環境が以前と変わりつつある現状を踏まえて、新たな決済サービスの企画を我々としましても1年半ほど前から開始しておりました。それはまさに、テック系スタートアップ領域におけるお客様のニーズに応えることということで企画を始めておりました。新たな事業を始めるにあたって、CTOやプロダクトマネージャーといったエンジニアの方々に対して、より分かりやすく簡単に決済を組み込んでいただけるプロダクトをご提供し、スタートアップ企業様に複雑な決済サービスを短時間かつ最小限のワークロードで導入いただくことで、企業様の立ち上げや成長をぜひとも我々としましてもご支援させていただきたいという思いを大事に、今回のサービス開発に挑んでまいりました。続きまして、今回リリースさせていただきました「fincode byGMO」の特徴を簡単にご紹介します。実装の容易さや利用開始手続きの手軽さというのはもちろんのこと、開発支援コンテンツのWeb提供とかサブスク、プラットフォーム管理機能などの様々なお客様ビジネスにミートするための機能を実装しております。よって、ぜひスタートアップの企業の方々にとどまらず、多くのCTOやプロダクトマネージャーといった方々にも「fincode byGMO」のご活用の機会をいただければと考えております。ではここから、「fincode byGMO」の開発者2名より、実際にどのような観点で設計開発に従事してきたか、また開発中にどんな裏話があったかなどを共有いたします。こういったプロダクト開発をぜひ一緒にやってみたいと思っていただき、この機会を通じて仲間が一人でも増えたらうれしいという思いで本日お話をさせていただきます。 ここからは「fincode byGMO」の開発を担当しております米山からお話しさせていただきます。まずは自己紹介させていただきます。米山純司と申します。2015年にGMOペイメントゲートウェイに新卒で入社いたしまして、「PGマルチペイメントサービス」の担当となりました。2017年からセキュリティグループに異動して、PCI DSS、ペネトレーションテスト、AWSの運用などを担当しておりました。2020年から現在のチームで「fincode byGMO」の立ち上げより参画し、現在も担当しております。現在は、要件定義から保守運用まで一通り担当しております。得意分野はスライド記載のもので、直近ではJava、MySQL、AWSをよく触っております。本日はよろしくお願いいたします。米山 決済代行サービスとは はじめに、そもそも決済代行サービスというのはどのようなもので、どのようなメリットがあるのかをご説明します。決済サービスとは、一言で言うとネットEC事業者向けのサービスとなります。ネットEC事業者様は、利用する決済手段ごとに各決済業者と契約し、システムのつなぎ込みなどの開発を行う必要があります。クレジットカード決済だけ利用するにしても、ケースによっては数十社のカード会社と契約する必要があります。これだと手間も時間もかかって非常に大変です。そこで決済代行サービスの出番となります。契約の窓口と決済のインターフェースを一本化することで、契約の手間を削減、そしてシステムの開発のコストを削減することができます。お客様のシステムに簡単に決済を組み込むことができるというのが、決済代行サービスの概要と主なメリットになります。米山 「fincode byGMO」のきっかけ 続いて、「fincode byGMO」のきっかけとして、なぜ新サービスを作ることになったのかについてご説明いたします。まずはEC事業を行う加盟店様の背景からですが、昨今のEC業界ではエンジニアが決定権を持つケースが非常に増えてきております。この傾向は特にスタートアップのEC事業者様、加盟店様で多くみられる状況でした。そのような事業者様、お客様の要望要件を満たすためにはよりエンジニアに寄り添った機能が必要になります。ただ、弊社の既存サービスはもうすでに多くのお客様が利用していまして、インターフェースの大きな変更が難しい状況になっていました。そのため既存サービスでこれを実現するのではなくて、エンジニアファーストなサービスをゼロから作る、ということで「fincode byGMO」が立ち上がりました。何がエンジニアファーストなのかはこの後ご説明していきたいと思います。米山 システム構成 機能のお話の前にシステム構成についてご説明します。テーマについては大きくこの2つで構築いたしました。「クラウドネイティブ」と「サーバーレスへのチャレンジ」ということで、弊社ではオンプレで稼働するサービスが多いですが、せっかくゼロから作れるサービスということもあり、新しい試みとしてこれらのテーマを挙げて構築を進めました。こちらが「fincode byGMO」のシステム構成の全体図になります。少し簡略化はしています。構築スピードとリソースの柔軟性からAWSクラウドを利用しており、フルクラウドで実装しております。AWSで構築しているので、AWSのサービス名が何度か登場しますがご了承ください。なるべくご説明します。各機能の説明は別途お話ししますので、まずは全体のご説明ですが、真ん中のAWSの雲マーク、枠で囲っているところが「fincode byGMO」のシステムになります。ユーザーからのリクエストは基本的にお客様のサーバー、それとブラウザからのリクエストとなります。図の赤線部分です。それらのリクエストから基本的にすべてAPIで受け取って、それらを処理する構成としております。API処理を行うWebアプリケーションバッチはコンテナで稼働しております。データベースはRDS Aurora、こちらはAWSがマネージドしているデータベースのサービスを使っております。コンテナまわりベースもAWSマネージドサービスを使っているので、我々開発者側でミドルウェアをインストールするような作業は不要です。青線部分のところは、SPA、シングルページアプリケーションを提供しておりまして、それをクライアントサイドでレンダリングさせて、動かしているところになります。米山 ではここから、各ポイントの構成についてご説明していきます。まずはAPIリクエストを受け付けてAPI認証、それと流量制御を行っている個所についてご説明します。流量制御って何？という方もいらっしゃると思うのでご説明しますと、決済サービスでは加盟店様のお客様のセールなどによって一時的に大量のリクエストが発生するケースがあります。特定の加盟店様の大量リクエストによって他のお客様に影響を及ぼさない、サービス全体に問題が発生しない、といった仕組みを入れる必要があり、その仕組みを流量制御と呼んでおります。それをこちらの仕組みで実装しております。まずはCloudFrontとAPI Gatewayで、APIのリクエストの管理認証を担うサービスになります。APIのリクエストが正しい経路を通っているか、具体的には確実にWAFを通っているかのチェックを行う監視をしております。API Gatewayの導入も初めてでしたが、先ほどご説明した通りAPIが肝のサービス、APIで基本的な処理をすべて受け付けるサービス特性になりますので、初ながらもがんばって検証しつつ導入いたしました。次にLambdaオーソライザーです。LambdaがAWSのサービスになりまして、任意の開発言語で任意のスクリプトをサーバーレスで実行できるサービスになります。このLambda制御で、先ほどお話しした流量制御の中身の処理を書いております。それをAPI Gatewayにアタッチすることで流量制御を実現しています。最後に DynamoDBです。こちらは流量制御の処理で、1秒あたりのリクエストカウント数など一時的なデータをカウントアップでデータ保持をする必要があります。その一次データ格納に利用しております。キャッシュのイメージが近いかなと思っております。このDynamoDBにTTLという仕組みがありまして、何分以上過ぎたデータは自動で削除するといったものですが、一次データ格納で使っている本サービスではぴったりなので、導入して利用しています。こちらで、データの肥大化を自動で防げるようにしております。以上の構成で、バックエンドまでに到達する前、バックエンドのアプリケーションデータベースに負荷をかけずにこのような構成にしております。API認証・流量制御についての補足になります。先ほど認証流量制御を通過して流れてきたリクエストはALB、Application Load Balancerの略ですが、ロードバランサのシステムでAPIリクエストのURLパスによって処理するコンテナを振り分けております。例えばイメージに書いていますが、「/payments」だったら決済のコンテナ、「/○○」だと別のコンテナといったように振り分ける設定を入れております。またアプリケーションの負荷はCPUなどでモニタリングしており。特定の閾値を超えた場合はAuto Scalingという仕組みを使ってコンテナが自動で増えるような仕組みも導入しております。これも大量決済処理で他の機能に影響を及ぼさないといった目的の構成になります。米山 続きまして、APIのバッチのバックアップアプリについてです。ここはECS Fargateという、AWSがマネージドするコンテナサービスを利用しております。アプリの開発言語はJava、フレームワークはSpring Bootで実装しております。コンテナにすることのメリットとしては、SSHログインして操作するとか、従来のサーバーメンテナンスを一切不要にできるというのが一番大きなところです。必要な時に必要な個数だけコンテナを立ち上げて、使わない時はコンテナごと起動しないという運用ができるので、例えばバッチなどで稼働するタイミングが10分だとしたら10分だけ立ち上がるといった構成にできますので、ランニングコストの最適化ができるというメリットがあります。ECR、こちらはdockerのイメージを保持するサービスになりますが、ECS Fargateで動かすアプリケーションは基本的にこのイメージを保存してアプリ自体のバージョン管理をしているイメージです。イメージ保存をして、アプリのデプロイは基本的にECR、イメージ構築から作成しております。米山 続けてお客様向けの管理画面、アプリケーションとか、Webドキュメントのフロントエンドの構成についてご説明します。フロントエンドのアプリケーションはJavaScriptのフレームワークのVue.jsというアプリケーションで構築しております。こちらはシングルページアプリケーションになりまして、そちらを構築しています。CloudFront、こちらがCDNのサービスになります。S3、これがストレージのサービス、ファイルの保持とかファイルアップでファイル保管をするためのサービスですが、静的コンテンツであればそのWebサービスとしてWebサイトとして動かすこともできるものになっています。「fincode byGMO」では SPAモジュールをストレージサービスのS3に置いて、それをCDNサービスのCloudFrontで外部に配信するといった構築にしています。アプリをビルドしてできたモジュールをS3に置くだけの構成にしていますので、こちらも完全にサーバーレスで動いておりまして、サーバー起動量ゼロという、コストメリットが非常に大きい構成にしております。最後に、弊社のオンプレとの接続方法についてです。AWS上に「fincode byGMO」から弊社の既存サービスのナレッジやリソースを活用する際は、専用線接続のDirect Connectを利用しております。専用線接続にすることによって、通信をセキュアに、レイテンシーの観点でも安定した通信を行うため、このサービスのために工事して構築しました。システムの構成の説明は以上となります。構成については、AWSのベストプラクティスにのっとり、セキュリティ面でもPCI DSSに準拠した構成ではありますが、改善の余地はまだあるので、ブラッシュアップを続けていきたいと思っております。米山 エンジニアファーストをめざして 志野同じく「fincode byGMO」開発担当の志野です。私の方からはまず「fincode byGMO」の強みであり目標でもあるエンジニアファーストというものを実現するための機能や取り組みについてお話ししていこうと思います。自己紹介いたします。エンジニア歴は5年と少しといったところで、2017年から新卒で某企業にてWebエンジニアをやっておりました。その頃はECサイトの開発に携わり、フロントエンドもバックエンドもインフラもといった感じでフルスタックに経験を積んでおりました。そして昨年9月に転職して、弊社GMOペイメントゲートウェイに入社いたしました。入社の時から「fincode byGMO」の開発担当でやってきております。はじめはフロントエンドを主に担当しておりましたが、今年5月からは審査・精算システムという部分のバックエンド側の担当になっております。担当領域は要件定義設計から構造改定、実際に手を動かしての開発と保守運用まで一通り担当しております。 志野改めましてエンジニアファーストについてお話しいたします。「fincode byGMO」は主に3つの軸からエンジニアファーストを目指しました。それはまず「インターフェースを分かりやすく開発しやすいものにすること」、次に「開発時のコーディング時間を極力減らすための機能やサポートを提供すること」、そして最後に「待ち時間を極力減らせるような即時での利用を可能とするオンボードプロセスを提供すること」です。次のスライドからは、そのための機能などを具体的に紹介していきます。まずはテスト環境についてです。「fincode byGMO」ではテストアカウントを即座に発行できます。ユーザー名とメールアドレスとパスワードだけで発行できますので、最短1分程度で発行できるかと思います。「fincode byGMO」というサービスを知って、どんな機能があるのかと気になったらすぐにテスト環境にログインして管理画面を見てみたり、APIを実際に叩いて試してみたりしながら「fincode byGMO」のご利用を検討することができますので、エンジニアにとっては技術選定のフェーズなどで調査がすんなり進んでうれしいのではないのかなと考えております。また、このテストアカウントはテスト環境専用のアカウントとなっておりまして、本番環境用のアカウントとは完全に独立しております。ですので、後々の本番環境への影響の心配は不要ですし、これまでは利用しているサービスによっては本番環境のデータを見せたくないからアカウントを発行してもらえないといったエンジニアや開発者もいたのではないかと思いますが、「fincode byGMO」ではそういった開発者にもテスト環境のアカウントをどんどん発行していただいて、開発をよりスムーズに進めてもらえたらという思いがあります。 志野「fincode byGMO」に限らず開発を行う際にはAPIリファレンスをご参照いただくかと思いますが、「fincode byGMO」のAPIリファレンスはWebで公開しておりますので、資料請求など不要ですぐに参照いただけます。これも技術選定の際に素早く動けるようになるかと思いますので、そういった配慮もしております。また、リファレンス内にはリクエストのサンプルも用意しておりますので、コーディング時間の削減のためにご利用いただければと思っております。現時点ではサンプルはcURL、Python、Node.js、Go言語を用意しておりますが、順次追加予定となっております。ご要望があればどしどしご意見いただければと思います。 志野他にコーディング時間を削減するための機能を紹介しますが、決済画面の実装をサポートする機能を紹介します。左のUIコンポーネントは、加盟店様側で用意されているWebページに決済画面を埋め込む機能です。「fincode byGMO」が用意したJavaScriptを埋め込むだけで簡単に決済画面を組み込むことができます。真ん中のリダイレクト型は、URL発行用のAPIを叩いていただくだけで「fincode byGMO」側で決済画面を作成してそのURLをお渡しするという機能です。お客様へはそのURLに案内していただくだけで決済を行っていただくことができます。右側のモバイルSDKは、スマートフォンアプリに決済画面を実装するための機能です。どの機能もリファレンスに組み込み手順を用意しておりますので、それほど大きくない工数で組み込むことができるかと思います。これらの機能をご利用いただくと、単純に画面の実装をしなくてよくなるだけでなく、カード情報の非通過非保持も実現することができますので、そのあたりの実装コストも削減できるかと思います。 志野続いては「fincode byGMO」のAPI設計の観点からお話しします。「fincode byGMO」が提供するAPIは、エンジニアにとって一般的だと感じられ、分かりやすくなるようにRestfulな作りにしております。RestfulってどんなAPIなのかというと、 URLの決め方やレスポンスの形式などいろいろあるのですが、弊社内で大きく変わった点としてはHTTPメソッドを処理に応じてきちんと使い分けるようになったところです。既存サービスではAPIのパスにアクションと対象を記載したり、同じパスで違う処理を行っていたりといった事がありましたが、「fincode byGMO」では可能な限りアクションはHTTPメソッドで表現しているため、パスがすっきりしているかと思います。また、同じパスで登録と更新の両方の処理を行うようなことがあったのですが、「fincode byGMO」ではHTTPメソッドでPOSTとPUTでそれぞれ分けておりますので、動作がイメージしやすくなっているかと思います。またPUTやDELETEは、冪等性があるHTTPメソッドであるため、多重で叩いてしまっても問題ないといった見分けもしやすくなりますので、一番安全でないPOSTのAPIの呼び出しが減るといった、システムにとってより良い形になるというメリットもあるかと思います。 志野エンジニアファーストについての取り組みの紹介として最後にイベントログという機能を紹介します。APIのアクセス履歴を管理画面から確認できる機能で、リクエストの日時やHTTPステータスコード、リクエストボディ、レスポンスボディなどの基本的な部分に加えまして、処理にかかった時間なども確認することができます。開発している時に自分でログを出力せずとも結果を詳細に確認でき、エラー発生時の原因特定などにも役に立つかと思います。もちろん、この機能は本番環境とテスト環境のどちらでも提供しております。 志野いくつかエンジニアファーストを実現するための機能を紹介しましたが、これらはすべて「fincode byGMO」の開発を行っているエンジニアのメンバーが、同じエンジニアにとってどうなっていればうれしいかということを考えながら作っています。ただ、私たちではまだ思いつけていないような改善点もまだまだあるかとは思っておりますので、ご意見いただければどんどん反映していきたいと思っております。今後も真のエンジニアファーストであるサービスを目指し続けていきますのでご期待ください。 開発体制と裏話 志野続いては、「fincode byGMO」の開発体制や開発秘話などプロジェクトの進め方についてのお話をいたします。まずは開発プロセスについてです。「fincode byGMO」では従来とは異なる開発プロセスでプロジェクトが進行しました。従来では図のように、要件定義は企画営業チームが実施してシステムは設計と実装を実施するという形をとっていましたが、「fincode byGMO」ではエンジニアファーストを謳っておりエンジニアの意見を多く取り入れるため、最も身近なエンジニアとしてのシステムやデザインチームのメンバーが、出された要件に対して意見し、要件を変更しながら進めました。そのため、要件の確定に時間がかかってしまうとか、設計が進み始めてから要件変更になるということもままあり苦労はしておりますが、エンジニアファーストの実現のために必要なコストであると考え、頑張っております。また弊社では、エンジニアは営業や企画職、事務職とは違うフロアで業務を行うことが多いのですが、「fincode byGMO」の開発チームはすべてのチームが同じフロアで業務を行っています。リモートワークもありますので常に同室にというわけにはいかず、チャットツールやWeb会議でのコミュニケーションが実際はメインとはなっているのですが、対面で話した方が早いなと感じた時などにすぐに対面で話せて助かったという場面も非常に多かったです。エンジニアの意見が多く取り入れられている一例として、先ほど紹介しましたイベントログ機能は、開発チームのエンジニアが「この機能は絶対に欲しい」と思ったところから開発が始まりまして、優先度をかなり上げて対応させてもらいました。これは一部の例なのですが、出された要件には、すべての機能でエンジニアの意見が何かしら反映されております。 志野続いて「fincode byGMO」の開発スケジュールについてお話しします。「fincode byGMO」は2021年4月からプロジェクトが開始しました。そして、同年12月に限定公開として本番環境の稼働が開始しまして、2022年5月には一般公開でリリースされました。かなりのスピード感で進めたプロジェクトであるといえるかと思います。2021年9月の開発チームメンバー2人追加というところで自分が入社したのですが、この時点では正直に言ってまだ多くの機能はきちんとは動いておりませんでした。そのような状態から一つ一つ問題を解決していきまして、10月・11月・12月と進むにつれてどんどんきちんとしたシステムに仕上がっていくのが自分にとってとてもうれしかったです。また管理画面の細かいUI/UXの改善などはエンジニアの裁量に任せてもらっておりまして、自分の提案で使いやすいWebページにしていけるのは非常に気持ち良かったなと今思い出しても思います。そういった流れから、12月には自信を持ってリリースできたということを覚えております。 志野続いて、サービス名についてちょっと苦労したなという部分の開発秘話なのですが、「fincode byGMO」は当初サービス名が「fincode byGMO」ではなく、途中からこの名前になりました。はじめは仮のサービス名で開発していて、ほぼその名前で決定のように進行していたのですが、社内の他のチームなどからも様々な意見をいただいて、再度、エンジニアに向けたエンジニアのためのサービスであるということが分かりやすい名前にしようと検討が始まり、現在の「fincode byGMO」の名前に落ち着きました。ただ、開発が始まってしまっていたのでいろいろと修正箇所が出てきてしまいまして、ドメインを取り直したりですとか、GITのリポジトリ名やAWSで利用しているサービスに付けている名前を付け直したりといった対応が発生しまして、その対応にそれなりの工数がかかってしまったという苦い思い出があります。 メディア展開への取組み 志野続きましてメディア展開についてお話しします。「fincode byGMO」では、ProductBlogの運営とTwitterでの情報発信を実施しています。その狙いですが、既存サービスは決済サービスというサービスの性質からどうしても堅苦しいイメージを持たれてしまっていたかと思います。「fincode byGMO」ではそのようなイメージを払拭し、ユーザー、特にエンジニアにとって身近なサービスにしていきたいと考え、これらの取り組みを始めました。ブログの内容を一部紹介しますが、実際に「fincode byGMO」を組み込んでみてその手順などを記載したような記事も用意しております。エンジニアの方はサービスを組み込む際にQiitaなどの記事を参考にしたような経験があるかと思いますが、「fincode byGMO」ではそのような記事を自己完結で用意しており、エンジニアをサポートしております。このような記事以外にもコラムやイベント参加についての記事など様々なジャンルのページを公開していく予定ですのでご期待ください。ブログやSNSでの発信は私たちとしては初の取り組みであるため、記事の内容やTwitterでの発信内容については相談しながら進めています。考えたこととしては、エンジニアの興味をひく内容とはどんなものか、ネタ切れを防ぐためにはどうするか、ブログ・SNSアカウントのキャラクターを作ってみようかとか、アカウントの管理は誰がやるのか、どのアカウントをフォローするのか、ということを検討しているのですが、まだまだ駆け出しですので、今後の更新にご期待下さい。 今後の開発ロードマップ 志野続きまして、今後の開発ロードマップについてお話しします。「fincode byGMO」では、継続して機能拡張を予定しております。現時点で提供しているカード決済以外の決済手段追加や、サンプルコードの対応言語の追加などを優先して対応していく予定です。その他の9月以降の開発スケジュールはまだ社外秘となっておりましてお話しできないのですが、来月頃のリリースの内容ですと、「メールリンク」という、メールを「fincode byGMO」からお客様へ送信して、そのメール内に記載されたURLから決済画面に飛んでいただくという機能や、「3DS 2.0」対応という、より便利にセキュリティを担保できるような機能に対応したりしていきますのでご期待ください。もちろんその他にも、より使いやすいと思ってもらえるような機能追加、より良いと思われるデザイン改善を進めていく予定です。欲しい機能がある方がいらっしゃればご意見ください。絶対対応するとまでは約束できませんが、しっかり検討させていただきます。今後の「fincode byGMO」にご注目ください。 質疑応答/Q&A Q：「fincode byGMO」のTシャツは非売品ですか？ これは非売品です。米山 吉田このTシャツを着て、今後のイベント等にこれからも出張っていきたいと思っています。 Q：新しいサービスを作る社風はどこから生まれていますか？ 吉田弊社はエンジニアだけではなくて営業も含め社内のチーム全員がお客様第一ということを大きな念頭に置きながら常に業務に携わっております。ということは、お客様の悩みとか、今の市場においてどんなお客様がどんな動きをされているか、かつ既存のお客様も踏まえたニーズに常に耳を傾けております。そういった中で、「fincode byGMO」はスタートアップの領域のお客様に対してより分かりやすく、よりスピーディーなプロダクト提供ができないかということで我々も考えまして、今回のプロダクト開発に至っております。なので、社風としましては、やはりお客様第一で動いている会社です。それがエンジニアや営業だけではなく、全員がそういったマインドを持って従事しているというところがまさに社風であり、我々も非常にそこは大事にしているところになります。個人的にもいい社風かなとも考えております。 Q：「PGマルチペイメントサービス」との違いを教えてください 「PGマルチペイメントサービス」も「fincode byGMO」も同じオンライン決済サービスですが、ビジネス規模でいえば、「PGマルチペイメントサービス」は大手のお客様向けのサービスになります。お客様に対して個別に担当の営業の方がつきまして、場合によっては特定の機能を付けるなどの調整も開発に組み込む場合があります。「fincode byGMO」の場合は、どのお客様にも同じ機能をASPとして提供しておりまして、ビジネス規模でいうとスタートアップ向けという違いがあります。機能面でいうと、「PGマルチペイメントサービス」は結構長く運用を続けていますので、一言でいうと多機能で、決済手段などが豊富に揃っている状態です。「fincode byGMO」はこれから拡張していくというところで、機能面の差はあります。それともうひとつ異なる点はインターフェースです。「fincode byGMO」の方は、加盟店様やお客様に提供しているインターフェースの仕様について、今どきの流れに沿った形で提供しています。あと、「fincode byGMO」では、すぐに使える点により重きを置いておりますので、テスト環境とかモバイルSDKの提供などが違うと思っております。米山 Q：「イベントログを使いやすくするために考慮したことなどあれば知りたいです 志野イベントログ機能はエンジニアの方から発案して作らせていただいた機能なので、いろいろ考えてこだわった部分があります。「fincode byGMO」のAPIでは、リクエストボディやレスポンスボディなどは基本的にJSONを介するので、そこのJSONが読みやすいようにハイライトをしたりとか、他のページと構成が異なっていて、画面構成とかも結構考えて作ったりとかしています。また、なるべく多くの範囲が見えるように、文字サイズを小さめに調整するとかの点もこだわって作っていますので、ぜひご利用いただけたらと思います。 Q：景色綺麗です！オフィスですか？ 吉田こちらは渋谷のフクラスで、GMOペイメントゲートウェイのある本社の会議室です。非常にきれいなオフィスなので、ぜひご一緒いただける方がいらっしゃれば、どしどし採用ページを見ていただけたらと思います。 Q：開発チームの規模とか気になります 開発ピークの時とは状況は変わっていますが、いま開発環境で体制としては弊社のメンバーと、開発を一緒にお願いしているパートナーさん、合計で13～14名で進めている状況です。米山 吉田そのぐらいの開発規模のメンバーで、開発ロードマップにもありますように、この8月も含めて3か月に1回、クオーター単位ぐらいで新しい機能をどしどし開発していきたいと考えています。そういった開発要員の中で、この2人を中心としたエンジニアがモノづくりに励んでいるという状況です。 Q：スライドの開発体制はウォーターフォールになるでしょうか？ 吉田ウォーターフォールとアジャイルの中間の形で進めています。弊社の場合、完全なウォーターフォールだけで進めているわけではなく、機能改善を含めてアジャイル的に進める場合もあります。今回はまったく新規開発でのプロジェクト推進だったので、フェージングにはポイントを置きながらも、開発のスピードを上げなければいけないということで、ウォーターフォールとアジャイルの中間的な進め方をしております。今後も、スピードを重要視しながら、かつ品質を維持させていかなければいけないので、開発の進め方については逐次メンバーとも協議をしながら進めています。 Q：クラウドでの開発で、オンプレとの開発と比べて大変だったことはありますか？ 技術的には、個人的にはないです。クラウドにして良かったと思うことが多いです。困ったことはどちらかというと運用面で、開発標準が弊社の中であまり揃っていなかったり、実績がなかったりというのがあり、前例がないところにルールを決めながら作ったというのがあります。こういった時どっちを選べばいいのかといったような開発標準作り、ルールで決まってなかったところが苦労しました。そのあたりも整備されつつあるので、課題は解消されつつあります。米山 志野私はもともとフロントエンドの担当だったのでフロントエンド寄りの話になってしまいます。先ほど説明にもあったように、「fincode byGMO」のフロントはS3にVue.jsをビルドしたものを置いて動いているのですが、そこの仕組みが新しいもので、あまりリファレンスがない、調べてもあまり出てこないようなもので、何かしら不具合が出た時に苦戦した思い出があります。一例としては、トップページにはアクセスできるが、それ以外のページにはアクセスできない、エラーが出てしまうということが何度か発生しました。Vue.jsはindex.htmlという大元のHTMLファイルからいろいろなjsファイルを読み込んでいろいろなページを表示するという仕組みになっていて、どんなパスにアクセスしても必ずindex.htmlにアクセスして欲しいのですが、CloudFrontとS3という仕組みを使った結果、指定したパス、例えば「/login」にアクセスしようとしたらloginというファイルをS3の中から探そうとしてしまっていて、実際はVue.jsの仕組み的にはloginというファイルは存在しないのでエラーが出てしまうということが起きていました。CloudFrontでS3から配信する仕組みを使う場合はコツが必要で、CloudFront側でloginというファイルとか、何かしらのファイルが見つからない、403 Errorが返った時にはindex.htmlに向ける、複雑であまりしない動きをさせる必要があって、そこで苦戦したけどなかなか原因が分からなかった、そういったことはありました。 Q：少人数で短期間に開発するにあたって、工夫したことや苦労したこと等ありますか？ 現在進行形で工夫していることとして、「fincode byGMO」はサービスとしてまったく新しいものですが、弊社の既存の決済サービスは非常にナレッジがある状態です。「PGマルチペイメントサービス」や他のサービスも実績があるので、そういったナレッジを使いつつ開発することで、まったくゼロベースではないというか、仕様がある程度分かった状態で作ることができたということが非常に大きいところと思っています。ただ、まったく新しいものを作るという意識は捨てないようにしようと思っているので、コピー＆ペーストは絶対になしとか、そういった意識はしつつ、ナレッジを持ってこられるところは持ってくるという意識をして、開発スピードを担保しているところではあります。米山 志野工夫したことが2つあって、1つはなるべく機能を汎用的に作るように常に意識し続けるということです。そこを意識したことで、意識していなかったら機能をもう1つ追加になりそうだったところを0.3個追加みたいな感じでなんとかなったという場面がありました。あとは、開発の手が若干空いたタイミングで、なるべく各メンバーができることを増やすようにと意識して進めています。例えばフロントエンドのメンバーがバックエンドのAPIもいじれるようにとか、そういった環境を整えるとかいうことを意識してやってきて、そのおかげでうまく進んだというところがあるように感じています。 Q：SPAを採用した理由などあれば知りたいです 理由は、新しい技術を触ってみたいというのが大きいところだったと思います。Vue.jsというフレームワークで作っているのですが、あと2個候補があり、その中で早く開発できて、安定して動きそうなものということで進めておりました。進めている最中に、AWSの構成の話になりますが、S3にCDNを置くことで完全サーバーレス環境として動くのではないかということが分かってきて、それがSPA採用のより強い理由となりました。米山 志野自分が参画した時には、すでにその仕組みで作られていたので、採用した理由などは知りませんが、ただ単純にサクサク動くので採用してよかったのではないかと考えております。 Q：フロント画面担当者の方に質問です。画面パフォーマンスで気にかけたことがあれば教えてください 志野ちょっと難しいのですが、私が入社した時にはすでにCloudFrontでSPAと、パフォーマンスには意識された仕組みになっていると思っていたので、根本的なところに関してはあまり意識していません。実際動かしてみても、思ったよりサクサク動くと思って、結構問題ないと思っておりますので、そういう改革的なことはまだあまりやってない状態です。ただ、定期的にパフォーマンスのチェックはしていて、不要なライブラリを読み込んでいないかなどをコマンドを叩いて確認するといったことは実施していますので、今後問題が発生したら対応していこうと思っております。 Q：ProductBlogって書くテーマだったり、誰が書いたり、どう運営されているのでしょうか？ ProductBlogは社内のメンバーが書いていますが、メンバーはあまり限定していなくて、企画担当や営業担当とかで書くネタを探しています。システムが書く時は基本的には技術的な内容を担当していまして、そこも我々開発メンバーが書くのでは自作自演感があるので、当開発に入ってない同じ部署、チームのメンバーにお願いして、今度こういう機能をリリースするのだけど触ってみてくれということで実際に実装してもらうとか、割と生の声を書いてもらうような書き方にして、原稿を書いております。原稿は、しかるべきフローを経て決まった人が投稿するようなことになっております。米山 吉田開発者ではない人間が加盟店さんに成り代わってそういう立場で実装してみて、それでその実装感を記事に書いてもらうようなことをやっています。 Q：ビジネスサイド、開発メンバーが同じフロアで働ける環境による弊害などはありませんでしょうか？ 私はまったくなく、気持ち良く働かせていただいております。米山 志野しいて言えば、Web会議をしている時に、電話の声とかが入りがちでちょっと喋りにくいぐらいです。 吉田非常に和気あいあいとやる環境だったので、コミュニケーション良くできたのがよかったかなと思います。 Q：中途でPGに入社して開発を担当してPGってどんな会社だと思いましたか？ 志野ずっと「fincode byGMO」の開発チームにいますので、チームの印象かもしれませんけど、エンジニアの裁量が非常に大きいというか、そこがすごくいいなと感じました。UI/UXを自分の裁量でいいように作っていってOKみたいな感じになっていたので、やりがいがあるというか、自分が作っているっていう気持ちが非常に強く感じられて、そういった意味で良い会社だと感じております。 Q：監視系はAWSのツール以外には何か使っていますか？ AWS以外では、基本的にはあまり使っていません。サービスの内部監視としてDBの監視はアプリで実装しているので、そちらはAWSとは切り離されてアプリの監視、DBのログの監視をしている状態です。基本的にはAWSのCloudWatchというサービスでアラート監視をしているので、それ以外の監視は、外部監視を含めて特に今のところ入れていない状態です。米山 さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは金融システムの裏側はあまり公開されることがないので参考になりました、興味深かったなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/cH1y-qspl3Q

6/19（日）「JJUG CCC Spring 2022」がオンラインにて開催され、GMOインターネットグループはセッションスポンサーとして協賛・登壇しました！イベントでは2セッション登壇したうち、今回はGMOペイメントゲートウェイ株式会社が登壇したスポンサーセッション「クレジットカード決済システムをJavaで構築して10年間運用した話」について、登壇レポートをお届けいたします。イベント告知：https://developers.gmo.jp/19185/本記事はこちらのスポンサーセッションの書き起こしとなりますので、ぜひご覧ください。 登壇者 GMOペイメントゲートウェイ株式会社システム本部 決済サービス統括部 エグゼクティブ・リーダー米原 孝太 はじめに クレジットカード決済システムをJavaで構築して10年間運用した話をしたいと思います。GMOペイメントゲートウェイの米原と申します。よろしくお願いいたします。 我々GMOペイメントゲートウェイでは、ECサイトなどのお客様に対して様々な決済手段のサービスを提供しております。本日はその様々な決済手段サービスの中でも一番主力となる、クレジットカード決済のシステムについてお話しします。 まず、クレジットカード決済システムについて概要と、システムを設計した時に考慮した点、それから今回は移行のシステムとなるので、その際のパフォーマンステストについてお話しします。そして、そのシステムを10年間運用してきてその中でどのような対応を行ってきたのかというところを最後に説明します。 1．クレジットカード決済システムについて クレジットカード決済システムは、クレジットカードの会社へ決済の要求電文を送信するシステムとなります。送信先は、CAFISやCARDNETなどの決済用のネットワーク。これらに接続して要求電文を送ります。CAFISはNTTデータさん、CARDNETはJCBさんが提供しているサービスです。 このCAFISやCARDNETの決済ネットワークは、インターネットが始まるよりも前のサービスなので、RFCなどの規格とは関係のない、独自の通信プロトコルを使った独自仕様です。よって、専用のパッケージソフトを利用して接続するのが一般的です。 決済処理なので、トランザクションの一貫性（整合性）を確保することが重要です。また、ECサイトに提供するシステムなので、当然ながら24時間365日無停止のサービスを提供することになります。 今回の対象のシステムは、もともとベンダーへ委託して構築運用していたシステムがあり、それを新しくシステム更改という形で（内製で）新しく作り直したシステムとなります。 サービスの全体概要としては、まず購入者からECサイトを通じてGMOペイメントゲートウェイへのサービスの方に接続があります。そのあと、バックエンドサービスとしてCAFIS、CARDNETなどを通じてカード会社（三井住友カードさん、楽天カードさんなど）に決済要求の電文を上げる仕組みとなっています。 GMOペイメントゲートウェイの中のサービスとしては各種フロントサービスがあり、その後ろのサービスとしてクレジットカード決済システムが存在します。フロントサービス自体は目的によって無数のサービスが存在していて、お客様に対して管理画面を提供したいというようなサービスも提供しています。それらのフロントサービスの中でもクレジットカード決済の処理に関しては、今回発表するクレジットカード決済システムですべて処理する仕組みになっています。 2．システム構築時に考慮した点 このクレジットカード決済システムを構築する時にどういった点を考慮したかということについてお話しします。まず、セキュリティ監査。クレジットカードの世界ではPCI-DSSという監査仕様があるので、これに準拠するところ、また、24時間サービスなので耐障害性のための分散構成を採ったというところ、さらにトランザクションの一貫性を保つところもあり、厳密なトランザクションの処理制御を行うようにしています。では、障害調査の容易性、サービス移行後のパフォーマンスを確保するための仕組みというところを説明します。 ■セキュリティ監査（PCI-DSS）対応 まずセキュリティ監査（PCI-DSS）への対応ですが、PCI-DSSとはクレジットカードの国際ブランドが策定したセキュリティの仕様となります。2008年頃に実際に適用され始めたのですが、ちょうどこのシステムを作る時（2011年）、実際に日本国内でも徐々に対応するという形が広まってきたので、我々が社内で最初にPCI-DSSに準拠しようということで対応することになりました。 要点としては、まずソフトウェア脆弱性の即時対応があります。具体的には、セキュリティーホール等が見つかった時に、それらのパッチが発表されるとそれをすぐに適用するというのが、セキュリティの対応要件としてあります。これに対応するための方法は、CI/CDといったような即時にリリースするための仕組みもまだ用意していませんでした。そのため、採った方法としては変わっていますが、フレームワークとかOSSといったライブラリを極力使用しないことで、対応するというよりもそもそも対応の頻度を下げるという形で対応することにしました。 次にセキュリティ要件として、クレジットカード番号や3Dセキュアの認証情報といったセンシティブデータについては、非保持または暗号化が必要となっています。したがって、センシティブデータをDBに保存する際には暗号化を施しました。また、ログデータとして出力する時は伏せ字、TRUNCATEと呼びますが、アスタリスクで置き換える、意味を持たないデータにするようにしています。 次の要件として、機能単位にサーバを用意するというのが必要になります。具体的には、Webサーバ・DBサーバ・APサーバを1つの筐体の中で1つのサーバOS上に同居させるのではなく、それぞれ個別のサーバを用意してその上に稼働させるというのが要件としてあります。そのために複数サーバを実際に購入して運用するのは非常に費用もかかるので、OS仮想化機能を利用して、1筐体の中で論理的にサーバを細分化することでこれらを実現しました。 ■耐障害性のための分散構成 耐障害性のための分散構成ということで、主要なオンライン機能、具体的にはAPサーバについては多重化構成をとるようにしました。万が一ハードウェア障害などによってサーバがダウンしたとしても、シングル構成にはしない、最低でも2台以上は稼働している状態を保つようにしました。例えばプロセスのフリーズなどが発生した際に、シングル構成だと、早急に復旧させるということでエンジニアによる調査がなかなかできないという問題が出てきます。多重化構成にしておくことで、問題になったサーバについて時間をかけて調査ができるという利点が発生します。また、バッチ処理用のサーバや社内の管理画面に使うサーバについては、それほどクリティカルでもないために、単純な正／副構成とすることで効率を上げています。 ■厳密なトランザクション処理制御 今回、通信処理の部分はTCPソケットライブラリを利用して作成しています。複数のトランザクションを並列処理する部分についてはConcurrency Utilitiesを活用して作成しています。具体的には、処理の役割ごとにスレッドプールを用意して処理を行っています。受信処理と業務処理スレッドを分離することで、受信処理から業務処理スレッドを呼ぶことで制御を行っています。業務処理スレッドが不足している場合にはエラーを即時応答することができます。業務処理が規定時間内に完了しない場合には、規定の時間が経ったところでエラー応答するという仕組みを実装しています。また、規定時間内に完了しなかった取引については、障害取消の処理を行うようにしています。 業務処理スレッドプールについては、処理種別ごとにグループを用意しています。具体的には、業務処理スレッドとして決済要求を処理するグループ、それから取消処理をするグループ、照会などの参照をするためのグループというようにグループを分けることで、例えば決済処理をするグループの方でカード会社が遅延していて、スレッドがすべて埋まってしまったというような場合にでも、取消や照会の要求に対しては正常に処理をすることができるという利点が生まれます。 ■受信処理スレッドから業務処理スレッドへ処理依頼 具体的なコードとしては、ThreadPoolExecutorを利用してスレッドプールを事前に生成しておきます。処理スレッドから業務処理スレッドへ処理依頼する際には、対象のスレッドプールに対して業務処理のクラスを生成した上で渡します。submitの部分になります。submitした際にfutureパターンに沿ってfutureオブジェクトで受け取っておいて、タイムアウト時間を設定した上でget処理を行います。こうすることで、業務処理スレッドプールに空きがない場合にはリジェクトのexceptionが返却されるので、クライアントに対しては現在過負荷状態であるという旨を即時にエラー応答することができます。 この過負荷状態のエラー応答については、実際に大量の処理をする場合のコツがあります。例えば加盟店様がバッチ処理的に連続で処理を呼び出すような場合、即座に応答を返すと連続して処理要求が来て即座にエラー応答を返すということが連続で発生するために、ひたすら処理要求をエラーで返すということでCPUリソースなどを食いつぶしてしまう危険性があります。なので、意図的にエラーを返す前に少しスリープを入れるなどの工夫をして、あえてお客様へ対して処理を待たせるといった検討もしています。 このfuture.getによって規定時間内に処理が返って来なかった場合はタイムアウトエラーとしてクライアントに対してエラーを返します。この場合、業務処理スレッドの方は正常に処理ができている可能性もあるため、後処理として障害取消を行うことでトランザクションの一貫性を保つというふうにしています。 ■障害取消処理を非同期実行 この障害取消の処理を実行する部分の扱いは非同期実行で行うようにしています。障害取消処理の実行を依頼する部分については、DB上にキューに相当するテーブルを用意しておいて、そちらに障害取引の要求電文を書き込みます。処理を行っているスレッド自体は速やかにエラー応答をクライアントへ返すというふうにしています。また、CAFIS等の決済ネットワークの障害取消電文は、大元である決済要求電文とほぼ同じ形でデータ電文を生成することが多いため、通常の処理電文生成時点で障害取消電文も同時に生成しておくと非常に処理が楽になります。書き込まれたDB上の障害取消要求に対して別スレッドでキューから定期的にフェッチして処理を実行することになります。こちらについては別プロセスまたはバッチ処理での実行をするようにしています。 障害取消については、障害取消自体が失敗するということも考慮して設計する必要があります。失敗した場合リトライを行いますが、その際もリトライ間隔やリトライの回数、こちらは決済ネットワークの方の仕様によって時間等が決まっていることがあるので、それを加味した状態で調整するようになります。また、実際に運用しているとそれらの決済ネットワークの事業者からこういう間隔に変えて欲しいとか、間隔をもっと延ばして欲しいといったリクエストを受ける場合もあるので、それらはプロパティ等に設定するようにして、後から調整可能にしておくことが重要です。リトライを繰り返しても障害取消がどうしても完結しないというケースがどうしても出てきてしまいます。そういった場合については、完了しなかった障害取消は日次のレポート等に出力して、その後は人間による運用で対応するという形にしています。 ■障害調査を容易にする 障害調査を容易にする仕組みについて説明します。まず、ログについては1トランザクションにつき1行というのを原則にしています。こちらは、実際に秒何十件何百件というトランザクションが発生するので、1件ごとに複数のログを出してしまうと滝のように流れるログになってしまうため、1トランザクションにつき1行くらいがちょうどよいと思います。ログの内容としては、調査用のキーとなる項目を端的に出力する必要があります。具体的には、トランザクションIDや処理結果（OK／NG、エラーであればエラーコード）、実際にはどの処理がどうなっているかというのを確認する意味も含めまして処理時間、できればそのトランザクションに全体で何ミリ秒かかったのか、またそのうち自身のシステムの中で経過した時間は何ミリ秒だったのか、このあたりを出力しておくと、例えば処理遅延が発生した場合に原因が自身にあるのかそれとも外部にあるのか、こちらを素早く判断することができるので非常に有効になります。 また、調査専用のDBテーブルを用意しておくと非常に楽になります。実際運用していると、月間件数の集計など統計的なものを見ることが多いので、そういった場合に大元の実際の取引のデータ、こちらはレコードサイズも大きいし実際センシティブデータを含んでいることが多いので、集計等をするためだけに要点となる項目のみ絞り込んでさらに集計しやすいようにあらかじめコードで表現するとか、そういった加工したデータを保存するようにしておくと非常に便利になります。 運用していく中でリソースの処理状況を見る必要がありますので、できるだけ詳細な統計情報を取得するようにします。実際にスレッドの利用状況とかDBコネクションの利用数など、こちらを秒単位とかの短い間隔で統計情報として出力することで、実際にはどういう状態になっているのかというのを外部から判断することができるようになります。 3.移行を意識したパフォーマンステスト 今回は既存のシステムを移行する形でサービスシステムを構築しました。したがって、稼働してすぐに大量のトランザクションが実際に発生するというのが分かっていましたので、既存システムの負荷状況を分析しています。具体的には、時間帯ごとの負荷状況や、送信元（お客様）の偏り具合、取引が少ないお客様もいればすごく大量に発生するお客様もいますので、そのあたりの偏り具合も統計をとっています。また、送信先のカード会社、こちらもカードを発行する会社によって発行枚数が違い、平均的とはなっていないので偏り具合も分析しました。あと処理種別、先ほどあったような決済要求や取消など、そういった業務の処理の偏り具合も分析しています。さらに、正常処理だけではなく実際にはエラー処理も発生しますので、そのエラー処理も混ぜるようにしています。 これらの偏り具合を実際に再現するテストをするわけですが、この負荷状況をシミュレートするのにちょうどいいツールがなかったために、今回はJavaで専用のテストドライバを用意して対応しています。 データについては、実際に1ヵ月分のデータを採るのはちょっと難しいので、負荷がピークとなる日、経験上毎月1日に取引量が多いというのが分かっていたので、そちらの1日分のデータを統計としてとっています。 システム移行では当然ながら目標値は現行よりも数倍の性能を目指すので、テストドライバとしても倍率を指定して負荷テストを実施できるような仕組みを用意しています。 実際に統計を取った時の情報をご紹介します。詳細に公開できないところもあるので一部ぼかしていますが、こういった形で実際はかなり偏りがあるというところを再現するようにしています。円グラフになっているのはカード会社の偏り具合です。右下のグラフは、時間帯による取引の偏り具合を統計として取得したものになります。実際、0時～24時の統計ですので、真夜中2時・3時は取引が減っていて、昼休みにあたる12時頃とか、夜の23時頃にどうしても取引が大量に発生するというのが見えています。 今回、テストのために用意した仕組みですが、テストドライバ自体は単純な仕組みとしておいて、それらに渡すデータ（CSVデータ）を事前に生成しておき、そちらで様々なパターンをテストできるという仕組みにしました。実際、先ほど挙げたような統計情報を元にデータ生成ツール（スクリプト言語やExcelなど）を使ってあらかじめCSVのデータを生成しておき、テストドライバとしてはそれらを読み込んでテストデータをシステムの方に投げるという仕組みにしています。その取引のデータを投げた結果をまたデータとして出力して、それらをExcel等でグラフ化することで、処理遅延が発生していないかとか、エラーが大量に発生しないかというのを視覚化した上で、どこに問題があるかというのを推測することに充てています。 ■パフォーマンステスト時のポイント（1） パフォーマンス時のポイントをいくつか挙げたいと思います。 まず非機能要件を確認する。一般的にピーク時に秒何件発生するのかといった要件を入れていますが、同じように処理件数のピーク時の件数を設定します。こちらは瞬間ではなくて1時間それが継続するという想定を挙げています。結構重要なのが、最大の日次処理件数や月間の最大処理件数で、これらも明確にしておく必要があります。日次バッチの処理時間やDBバックアップの時の処理時間、これらを測定する必要があるので、日次・月間の処理件数を明確にしておくことは非常に重要になります。 また、取引の応答時間についても最大処理時間を決めておいて目標値としてその時間内に収まるようにします。ただ、どうしても突発的に遅延というのは発生するので、全体の99.9%が収まるようにといったような少し緩和する条件を付け加えるのもよいと思います。 あとは、前提条件として耐用年数を迎えた状態を用意する必要があります。具体的には、例えば5年後に月間5,000万件を処理するという想定であれば、仮にデータを3か月間保持するシステムで、1.5億件のデータをあらかじめデータベースのレコードとして用意しておきます。できれば意図的にデータも汚す、例えば正常の取引だけが1.5億件入っているだけよりも、そのうちの何割かは取消処理されたといったような少し汚れた状態を作っておくことが重要になります。 ■パフォーマンステスト時のポイント（2） 次に、特殊なテストパターンも用意しておく必要があります。我々はバースト処理と呼んでいますが、瞬間的に大量の取引が発生するということを想定しておきます。実際に、チケット販売のお客様の場合だと、チケットの販売直後にものすごく大量の取引が発生するようなこともあるので、そういった状況も考慮して、例えばある瞬間だけ5秒程度、秒1,000件～2,000件といった大量取引が発生するというような状態を試しておきます。この時、当然ながら目標値を超えるようなものはエラーになってしまいますが、重要なのは、その波を乗り切った後に正常状態に戻るかどうかというところになります。経験的にTomcatのServletとかでシステム構築していますと、そこでエラーが発生した後、さらになかなか波を乗り切っても元の正常状態に戻らないというようなことがよく発生するので、そういった状態が起きないかというのをあらかじめ検証しておくことは非常に重要になります。 それから、ロングランテスト。取引を流した状態で、できれば1週間程度連続稼働させています。こちらは、メモリリークが発生していないか、GC遅延等が発生しないかという様子を見るために非常に重要になります。 プロセス起動直後での高負荷が発生する状況というのもテストしておいた方がよいです。システムのプロセスを起動した直後は、スレッド数とかDBコネクションとか動的に増えるような要素がある部分についてはその高負荷状態に追いつかないケースがありますので、こちらはそれをなんとかするというよりは、そういう状態が起きるというのを事前に知っておくというのが非常に重要になります。なので、例えばリリースをする場合でも、もし負荷が高い時間帯にどうしてもやる場合は、こういったことが起きるかもしれないというのを考慮することができます。 ■パフォーマンステスト時のポイント（3） 当然ながら、設定した要件をクリアできることというのがパフォーマンステストのポイントですが、設定した要件を超えた場合の挙動を確認するという意味もあります。この場合、特にボトルネックになる箇所を見極めておくのが非常に重要になります。CPUのリソースがなくなるのか、メモリが不足するのか、それともDBコネクションが枯渇するのか、そういったボトルネックの箇所を見極めておくことで、将来サービスが拡張していく際にスケールアウトなどのシステムの拡張を行うにあたり、どこを拡張すべきかというのを事前に把握しておくことができます。 また、過負荷状態になった時、その後の平常状態に戻った時に問題が出ないことを確認する、過負荷状態が発生してエラーが発生しますが、その際に不整合の取引が発生していないかどうかを確認することが重要です。 これらのテストを行っていくわけですが、実際にどこまでテストすればいいのかというのが非常に悩ましいところ。私の経験としては、そのテストを指導する立場として、「ここまでテストしても実際の稼働した範囲に問題が出るならば仕方ない」という、自分の中でもう諦めがつくところまでテストするようにしています。 4.10年の間に行ったこと これまでがクレジットカード決済のシステムをJavaで構築した際の話ですが、ここからは、それを実際に運用していてどうなったかというところについて説明します。 ■システム変更履歴 実際に今回のシステムは、2012年10月に移行を開始しました。今回はお客様がたくさんいましたので、一度に全部ではなくて段階的に移行するという手法をとっています。その段階移行が完了したのが2013年1月になります。この後に旧システムを撤去しています。それからあまり時間が空いていませんが、2013年3月にサーバを増強しています。こちらはパフォーマンステストと実際のサービス移行をしている中で、すでにAPサーバが少しリソース不足であるというのがもう統計的には分かっていましたので、早いうちにサーバ増強の対応を行っています。続いて、2015年11月の時点で、お客様の要件としてもあったためにDR環境を新しく追加しています。こちらはシステム増強というか、DR用に別拠点にサブセットの環境も一式用意して、データ同期等を行うというような対応を行っています。2017年10月、ちょうど5年ほど経過したところで、DBサーバの方のリソースが不足気味であるというのが分かっていたのと、他のサービスでのDB移行を行うという目論みがあったために、この時点でDBサーバの更改を行っています。こちらのDBサーバの更改を行ったことで、システムとしてはさらに処理件数も増やせるような状況になっていました。それからさらに少し年数が経ちまして、去年（2021年12月）の時点で、それまで稼働していたDBサーバ以外の部分、WEB/AP/バッチサーバといった部分について、全面的に更改を行っています。 ■2021年更改時内容 その2021年の更改時に変えたところを説明します。 OS/Javaのバージョンアップ実際にサーバも変えていますので、当然ながらOSもバージョンアップし、このタイミングでJavaもほぼ最新のものにバージョンアップしています。 制御系処理の改善制御系処理を改善しています。具体的には、処理経路アルゴリズムを見直すことで処理の効率化を図っています。 制御系テーブルをインメモリDBへ変更分散処理をする上でどうしても制御系のテーブルをデータベースに持っていたのですが、この部分がどうしても処理パフォーマンス上のネックになるというのが分かっていました。よって、それらの制御系テーブルについてはインメモリDBを新しく用意してそちらに移し替えるという形にしています。これによってかなり処理のパフォーマンスが良くなっています。 バッチ処理モジュールにフレームワーク導入それまではバッチ処理も含めて基本的に各モジュールにはフレームワークを入れていなかったのですが、このタイミングでバッチ処理についてはフレームワークを入れるようにしました。具体的には、Spring Batchのフレームワークを導入しています。 バッチ処理実行をcron起動からジョブ管理製品へ変更それまではバッチ処理の実行をcron起動によって行っていましたが、このタイミングで一般的に売っているジョブネット等が組めるジョブ管理製品に変更しています。 ビルドツール変更それまでは使っているライブラリ等も少なかったので、実際にEcripse上でただコンパイルするだけというようなビルドの仕方だったのですが、今回の更改のタイミングから、Maven&Jenkinsを使ったビルド方式に変更しています。 不要テーブルの削除バッチ処理を変更したということと、監視系の見直し等も行った結果、使っていない、なくても特に問題ないといったテーブルがあったので、それらの不要テーブルをこのタイミングで削除しています。 暗号化用秘密鍵の管理方式変更セキュリティのために暗号化処理を行っていますが、そのための秘密鍵の管理方法を変更しています。こちらは、PCI-DSSの要件が2～3年おきに更新されていくので、PCI-DSSのバージョンアップに対応するための変更を行いました。 ■統括 今回のシステムのように業務要件の変更があまりないシステムについては、Javaで構築した息の長いプログラムを稼働するケースがあります。この場合、計画時に性能要件を明確にするとともに、定期的な性能測定を行いつつ、早めの拡張計画を立てることが必要です。また、ハードウェアの保守期間やOS／ミドルウェアのサポート期間の期限が切れることがあるので、これらを考慮した設計導入を行うことが非常に重要だと思っています。 むすび 最後になりますが、我々GMOペイメントゲートウェイではエンジニアの仲間を募集しています。我々GMOペイメントゲートウェイでは、お客様にサービスを提供することを主目的としています。そのサービス自体は我々自身で構築して運用しています。実際に、先ほども説明したように、10年近く前に構築したシステムを運用し続けるといったようなことを行っています。その中で実際に私自身もここについてはちょっと失敗したなというような思う点もありますが、逆にここについては狙い通りにできたというふうに思える部分もあります。我々はシステムを構築することが目的ではなくて、実際にそのシステムを運用してサービスを提供することが目的です。そういった自分の実績を確認できることは、エンジニアとして非常に幸せなことだと思っています。皆さんも、もし興味がありましたらぜひ採用サイトを訪れてみてください。 以上、ありがとうございました。 Q&A 質問1：金融システム観点で、設計段階から注意するべきことなどありますか？ 主催設定した要件を超えた場合の挙動、ここはシステム設計及び運用をされている上でも、やはり一番重要視されてることの1つだという風に考えてるんですが、いかがでしょうか。 そうですね、決済・お金を扱っていますので、これがあとで不整合みたいなことが起きると、非常に後処理が大変ですし信用も失っていきますので、その辺を十分に考慮して処理をすると。ウェブサービスよりも1段上のシステムを作っているという意識を持って設計テストをするようにしています。米原 質問2：システム更改の際、スプリングバッチ及びスプリングフレームワークの選定理由について教えてください。 主催PCI-DSSの観点で、当初のパッチの適用が必要になることからプレイバックをさけるみたいな話もちょっとあったかと思うんですけれども、そこはあえてスプリングバッチを入れた判断というのと、そのスプリングバッヂを選択した理由とかですね、その辺ちょっと差し支えない範囲でお話しいただけますか。 それまでがバッチ処理はクーロン起動っていう形でかなり作り込んで実施していたんですが、今回更改のタイミングでJP1を使ってジョブスケジュールでやることになりました。社内的に全部そちらで統一しましたので、そちらに移行した方が運用しやすい、となりました。その上でいろいろ作り変えていくとこがあったので、これを機にフレームワークを入れようという形で、特にこの機能が使いたいとか、そういうわけではなかったんですけれど、徐々にフレームワークを入れていこうという方針に変わってますので、それで対応したという感じですね。米原 主催そうなんですね。じゃあそこでスプリングバッジを選択したっていうのは、たまたまそこで何らかの基準があって、スプリングバッチを選択されたという感じですかね。 社内のシステムが基本的にはスプリング、フレームワーク系を使うように今なってますので、そうすると他のチームから移ってきた人とかも、同じフレームワークを使っている方がやりやすいというところもあって、社内的にある程度共通化していく、技術の共通化を図るというところを目指してます。米原 質問3：「安定稼働するシステムの更改タイミングについて」アーキテクト・プロジェクトリードの側面からコツ（勘所）を教えてください。 主催10年間（実際にはもう移行前からいうともっと長いかとは思うんですけれども）例えば今回の場合だと移行のタイムとアプリケーションのロジックをちょっと変えてみたりとかあったかと思うんですが、そのタイミングというのはどのように判断したのかっていうあたりで、アーキテクトの立場なのか、そのプロジェクトリードの立場なのかっていうのもいろいろあるかと思うんですけども、「このタイミングだ」という風に判断された理由とそのタイミングがいつだったかというところを、もしよければお話しいただければと思います。 そうですね。これタイミングが非常に難しくて、やっぱり安定して動いているシステムほどなかなか変えるっていうのが難しくて、正直に言えば一番はハードウェアの保守が切れて、もう変えなきゃいけないというタイミングでハードウェアを変えるのであれば、この時にアプリケーションも見直しをかけましょう、という、そういったタイミングでもないとなかなか動いているものに手を入れるっていうのは非常に勇気がいるというか難しいのが実情ですね。あとは長年運用していますと、だんだんサポート切れという問題も増えてきますので、そこをそういったサポート切れが一番タイミングとしては分かりやすいといいますか、機会としてはちょうどいいかと思います。ただ、そのために色々準備は必要ですので、早めにここから公開するぞという計画を立てるのが重要なところになります。米原 主催どっちかというと、外部要因が一番大きなインパクトや影響を受けたところではあるけれども、事前にもちろんそういうことがあってもいいように準備だけはしておかれたということですかね。 そうですね。まあ、普段から運用していますと、この辺がちょっとネックになっているとか問題があるとかだんだん上がってきますので、でもその場ですぐに対応するしかないというのは、どうしてもたまってくるんですよね。そういうのを事前に調べて、こういう風に変えていこうとかっていう調査とかは進めておいて、それをまとめて一気に対応するというような感じで運用することが多いですね。米原 質問4：フレームワークを使うメリット等あれば、教えてください。 主催PCI-DSSの観点でフレームワーク極力排しますっていうお話は、これが多分視聴者の皆さんもかなりインパクトがあったようでして。例えばこの10年間の中で、フレームワークあれば良かったなと思った時というとどんな時がありましたか？というご質問をいただいております。 一番は、やはりだんだんメンバーが入れ替わったり増えたりしていく中で、フレームワークを使ってないと、そもそもこれ何？みたいな感じでやっぱり入ってきた人にはちょっと意味が分からないみたいで。設計書はあるんですが、そんなに詳細な説明書を用意したわけでもないのでやはり少し見てもらって対応していく、という流れになります。最初の入り口で時間かかるので、そういう意味ではやっぱりフレームワークを入れていると、特にスプリングなんてもうメジャーですから、皆さんだいたい触ったことあります、分かりますと。プロジェクトに参加した時、最初の慣れてくるまでの時間という意味では、フレームはあった方がいいなというのは思いました。米原 主催なるほど、ありがとうございます。やはり最初に作った人と後から入ってきたというところにギャップがあって、そのキャッチアップに時間がかかるというのは、運用する上では結構厳しかったりもしますもんね。 そうですね、はい。米原 質問5：言語やライブラリのバージョンアップ問題による、影響などあれば教えてください。 主催2021年のタイミングでJAVAのバージョンアップもされましたよっていうお話をされていらっしゃいましたけど、今までいわゆるフレームワークを使わずに、元々のライブラリをずっとメンテナンスされてってことだったと思います。今まで御社で作られたライブラリもバージョンアップによってやはり何らかの形で影響があったかと思うのですが、どのあたりが一番影響が大きかったですか？ここも言える範囲でお願いいたします。 そうですね。まあ正直そんなに影響はなかったですね。ただやっぱりJAVAはバージョン変わるとそれまでとちょっと微妙に動きが変わるっていうところが出てきますので、そこを事前に動作を調べてどういう風に変わるか、どういう風に影響出るかっていう、これには結構時間がかかっています。具体的にはテスト担当が1人2人専属でやってもらって、やっぱり1～2ヶ月ぐらい。工数でいうと2人月3人月ぐらいはやっぱりかけて調べて、どういう風に対応すればいいかというところを調べた上で、結構やっぱり時間はかかります。米原 主催小さいけれど、やっぱりそれを潰していかないと突然予想できない動きをされると困るっていうところもありますよね。 そうですね。米原 質問6：パフォーマンス改善に伴う、ボトルネックなどあれば教えてください。 主催パフォーマンスが問題になる場合に、どの辺がボトルネックになることが多いですか？ピンポイントに絞っていただいて結構なので、例えばこういう例どうですかっていうところでお話しいただけますか。 そうですね、一番ネックになるのはやっぱりデータベースのコネクションですね。DB（データベース）コネクションはやっぱり無限に使えるわけではないので、今回例えば決済システムですと、この後ろに具体的にはクレジットカード会社をまたいで最終的な与信枠まで使って大丈夫かっていうチェックまでして返ってくるので、1秒から数秒かかるんですよね。単純に作ると、その間はずっとスレッドが動きっぱなしというか。そうするとコネクションも握りっぱなしで実際何もしてないのに、ただリソースだけを使う状態っていうのが発生するので、その辺りはちょっと工夫して一旦コネクション離すとかそういう工夫しないとすぐにコネクションツールを使い切ってしまうので、結構苦労してますね。米原 主催なかなかそこはそうですよね。やはりブロッキングになってしまうと、なかなか難しいというころですかね。やっぱりその辺りが興味深いと思ってる方々がやはり多いですね。 質問7：JAVAバージョンアップによるパフォーマンス改善の恩恵などあれば教えてください。 主催先程のJAVAのバージョンアップによって、挙動が変わったところをつぶして行かれた、というところに関連してなのですが、バージョンが上がると、例えばGC（ガベージコレクション）のパフォーマンスが上がるとか色々良いこと、もちろんこの機能無くなって困ったねっていうパターンもあるかとは思うんですけど、パフォーマンス的な違いっていうのって何か体感されたこと、例えばパフォーマンス指標自体収集されて、これぐらい変わったんだっていうのをもし御社の今回の移行の中でこの辺はすごいアップデートすることによって良い影響をもらったなっていうのは何かありましたらお話しいただけますか。 JAVAのバージョンアップ自体でパフォーマンスがこう劇的に上がったっていうのは実はそこまでないですね。どちらかというと、その仕組みを色々見直して結果2倍3倍ぐらいの処理能力に上げていますけど、やっぱ一番効いたのはデータベースで排他制御していたところをインメモリーDBに変えたとか、そういうところも効いてますし、でもそのためにやっぱりいろいろJAVAの新機能を使ったりしてますので、なかなか単純にJAVAのバージョンを上げたから、ポンと上がるっていうのはちょっと体感的にはないですね。米原 主催なるほど、そうですよね。GCE単体のベンチマークを取ってるとかっていうんだったら別でしょうけども、システムとしてはトータルで見ないといけないというところもあるんで、トータルで見ると、例えばインメモリーでDBを入れましたとか、その他あと工夫というかアーキテクチャー上の改善とかをされて、パフォーマンスが当初よりももちろん上がったというような感じですかね。 おまけ 主催米原さんよりお話をしたいことがあるということで、イベントの告知ですかね。では、ちょっとお願いできますか。 はい、我々GMOインターネットグループが開催してますオンラインイベントとして、Developers Nightというのがあります。これが7月14日（木）に開催されるのですが、その中で我々の新しい決済サービスであるfincode byGMOっていうのがあり、こちらの話をします。実はこちらのサービスの裏側として、今回説明した決済システムを使ってクレジットカードの処理をしています。こちらのサービス開始する時に実は私も一部関与していまして、実際に一緒に開発したメンバーがこちらのイベントで登壇しますので、ぜひ参加して話を聞いていただければと思います。よろしくお願いいたします。米原 主催はい、ありがとうございます。（イベントでは）なかなか濃い話をしていただける、と思っていいですか？ そうですね。具体的にどう作ったとかっていう話があるはずですので。米原 主催なるほど、ありがとうございます。どう作ったかというのもあるだろうし、ここ少し頑張ったよ、みたいなしみじみ感あるようなお話もあればいいかなと思います。視聴者の皆さん、ぜひ楽しみにしていただいて参加登録いただければと思います。 参加申し込みはこちら https://developers.gmo.jp/20150/ さいごに ご視聴・ご参加いただき、ありがとうございました。たくさんのご質問もいただき、重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://youtu.be/2tGMbGfJkW4 クレジットカード決済システムをJavaで構築して10年間運用した話 連載記事はこちら https://developers.gmo.jp/21413/

GMOペイメントゲートウェイのエンジニア向けオンラインイベント、「Developers Night #24」を開催し、様々な決済手段を一括導入できる総合決済システム「PGマルチペイメントサービス」をはじめ、 未回収リスクをGMOペイメントサービスが負担※1する「GMO掛け払い」や、返金・送金をスピーディーに代行する「GMO-PG送金サービス」、サービス・コンテンツ向け後払い決済「こんど払い byGMO」など、20年近く続くサービスから社会のニーズに合わせて生まれた新規サービスの裏側までお話ししました。 ※1GMOペイメントサービスによる与信審査を通過し、正常に完了した取引が対象 イベント告知：https://developers.gmo.jp/8793/  当日の様子をレポートいたします。  はじめに  こんにちは、GMOペイメントゲートウェイ（GMO-PG）の広報担当です。  今回は4つのテーマについて、GMO-PGと2021年4月にグループジョインしたビュフォート社のエンジニア計9名が登壇しました。  総合決済システムをはじめ、送金・返金、掛け払いや、コンテンツ・サービス向けの後払い決済などのシステムの立ち上げからこれまでの経験により得た教訓などをご紹介しました。  数百名の方にご視聴いただき、それぞれのセッション中に立ち上げや運用のお話しに多くの共感の声をいただきました。  セッション①：PGマルチペイメントサービスのこれまでとこれから  https://www.youtube.com/watch?v=zaxuGVz0NnY 決済手段を一括導入できる総合決済システム「PGマルチペイメントサービス」、通称「マルペイ」に関して、処理件数など具体的な数値と合わせてサービスをご紹介。また、システム構成や体制、見守り方など裏側についてもお話ししました。  また、実際の管理画面を見ながら、マルペイの機能やこれまでのシステム更改についてご紹介しました。若手開発担当者が考える「改善すべきポイント」「楽しいポイント」についての裏話を通して日々改善に取り組んでいることをお話ししています。現在絶賛開発中の「より使いやすい管理画面」の内容もご紹介しています。  ▼GMOペイメントゲートウェイのブログはこちら 前半：https://www.gmo-pg.com/blog/article-037/後半：https://www.gmo-pg.com/blog/article-038/ セッション②：年間3,000億円送金するシステムをサービス停止なしでシステム更改した話  https://www.youtube.com/watch?v=o3Tm4aBbu68 準備期間1年ほどをかけ更改した送金システムに関して、サービスのご紹介と、旧システムにおける課題に対して新システムでどのような対策を行ったかをお話ししました。  企業間取引における与信、請求、入金確認、督促業務を代行し、未回収リスクをGMOペイメントサービスが負担※1「GMO掛け払い」のローンチまで約1年の開発体制や工夫したことなどについてお話ししました。  ▼GMOペイメントゲートウェイのブログはこちら https://www.gmo-pg.com/blog/article-039/ セッション③：「GMO掛け払い」新規プロジェクト立ち上げからローンチまでの軌跡  https://www.youtube.com/watch?v=LGkufGI5RO0 企業間取引における与信、請求、入金確認、督促業務を代行し、未回収リスクをGMOペイメントサービスが負担※1「GMO掛け払い」のローンチまで約1年の開発体制や工夫したことなどについてお話ししました。  ▼GMOペイメントゲートウェイのブログはこちら https://www.gmo-pg.com/blog/article-040/ セッション④：共に成長するパートナーシップで決済サービスを構築する   https://www.youtube.com/watch?v=Ilg6_A27Nng コンテンツ・サービス向けの後払い決済サービス「こんど払い byGMO」のローンチに向け、当時外部パートナーであったビュフォート社の力を借りることで、クラウドネイティブ×マイクロアーキテクチャでの開発を実現しました。委託、受託の垣根を超えて新たな技術に取り組んだ進め方を、GMO-PGのエンジニアリングマネージャーからインタビュー形式で、ビュフォート社のお二人とお話ししました。  ▼GMOペイメントゲートウェイのブログはこちら https://www.gmo-pg.com/blog/article-041/ さいごに  GMO-PGは決済業界のリーディングカンパニーとして、キャッシュレスやDXを進める事業会社や金融機関に対して、各種決済・金融関連のソリューションやプラットフォームの提供、決済インフラの構築などを行っています。  15万店舗以上の加盟店様に、総合的な決済関連サービスや金融関連サービスを提供しており、2021年3月末時点で年間連結決済処理金額は6.9兆円を超える規模となりました。  今後も決済関連サービスや金融関連サービスについてのイベントを開催し、皆様と考える機会を創出できればと考えております。  なお、過去のエンジニアイベントの書き起こし記事を公開しておりますので、ご興味ありましたらご一読ください。  https://www.gmo-pg.com/blog/list.html?ch=ch_engineer GMO-PGでは、社会インフラともいえる決済サービスを安全・安心にご利用いただけるよう、品質向上のため日々エンジニアが自発的に業務に取り組んでいます。  そんな我々と共にサービスを支えてもらえる、仲間を絶賛募集しています。  お問合せお待ちしております！  GMOペイメントゲートウェイ採用ページ 

4月13日にGMO Developers Night#23を開催しました。「事業を支えるクラウドネイティブ×インフラエンジニアリング」をテーマにグループ4社からネット決済やネット広告、ホスティング、EC支援といったさまざまなサービスを担当するエンジニアが登壇しました。イベントページ：https://gmo.connpass.com/event/208362/当日の様子をお届けします。 はじめに 今回はグループ4社 GMOインターネット株式会社GMOペイメントゲートウェイ株式会社GMOペパボ株式会社GMOアドマーケティング株式会社 が登壇し、事業を支えているクラウドネイティブ技術についてセッションを行いました。1つ目と2つ目のセッションではプレゼン形式で事例を紹介させていただきました。3つ目のトークセッションでは、ネット決済やネット広告、ホスティング、EC支援といったさまざまなサービスを担当するエンジニア6名が登壇し、雑談形式で各社のクラウドネイティブ事情をお話ししました。 セッション内容について以下で詳しくご紹介いたします。 セッション① Cloud Run導入事例のご紹介 〜最速マネタイズを目指す〜 アドテクノロジー事業を展開するGMOアドマーケティングから堤が登壇し、新規事業立ち上げでCloud Runを導入した事例についてお話ししました。また、Cloud Runの特徴やチューニングのポイントなどもご紹介させていただきました。 https://youtu.be/d4Gsgf7sons?t=433 登壇者からのコメント ご視聴いただきありがとうございました！ 緊張しましたが楽しく参加させていただきました。これからもGMO Developers Nightをよろしくお願いいたします。 セッション② カラーミーショップにおけるハイブリッドクラウドを活用した可用性向上のためのアプリケーションインフラ刷新 GMOペパボの技術部技術基盤チームから高橋（@takutaka1220）が登壇し、GMOペパボが提供するカラーミーショップにおけるアプリケーションインフラのレイヤーで実施している可用性向上に関する取り組みを紹介しました。カラーミーショップでは、ショップオーナー様が安心してネットショップを提供できるよう、可用性向上に関してさまざまな角度から取り組んでいます。 https://youtu.be/d4Gsgf7sons?t=1424 登壇者からのコメント ご視聴いただきありがとうございました。ここが知りたい！ここはどうなってるの？といった点がありましたら、Twitter（@takutaka1220） などで気軽に質問いただければと思います。GMOインターネット グループ各社おもしろいことをたくさん実践しているので、今後の GMO Developers Night にもぜひご注目ください。 トークセッション CNDO振り返り＆座談会 先月開催されたCloudNative Days Spring 2021 ONLINE（CNDO）に登壇したGMOインターネットグループのメンバー3名を交えてCNDOを振り返りながら、グループのクラウド周辺技術などについて語り合いました。 https://youtu.be/d4Gsgf7sons?t=3138 今回はほぼ初対面のメンバーが多く、程よい緊張感の中で実際の業務について語ることができました。そんなライブ感のある雑談を楽しんでいただけると幸いです。 CloudNative Days Spring 2021 ONLINE（CNDO）について イベント内でご紹介したCloudNative Days Spring 2021 ONLINE（CNDO）のセッションもアーカイブ公開しております。今回登壇したメンバー以外にもGMOペイメントゲートウェイのCTOやSREエンジニアも登壇しております。お時間ある方はぜひご覧ください。 https://developers.gmo.jp/technology/3845/ モデレーター 山下（@pyama86）からのコメント 視聴していただきありがとうございました。今回登壇した会社だけではなく、GMOインターネットグループには多くの事業セグメント、会社があります。まだまだ眠っているおもしろトークがたくさんあるので、今後もぜひGMO Developers Night にご注目ください。僕自身もまた今後の会で呼んでもらえるよう、右肩を仕上げていきたいと思います。それでは、また同じ空の下でお会いしましょう。 さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは参考になりました、楽しかったです、またやってほしいですなど温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。まだ視聴していないという方もアーカイブ公開しておりますのでぜひセッションご視聴ください。 https://youtu.be/d4Gsgf7sons 登壇者もグループ会社同士でこうして雑談しながら、視聴者の皆さんと交流する機会があまりなかったため、大変良い機会となりました。今後、こうした企画も実施していきたいと思いますのでご注目ください。またのご参加お待ちしております！

GMOペイメントゲートウェイが初のオンラインイベントを開催しました！ GMOペイメントゲートウェイ初のエンジニア向けオンラインイベント「Developers Night #17 キャッシュレスの裏側～年間5.5兆円の決済システムを支えるエンジニア～」を開催し、決済の裏側を支えるエンジニアが直面した課題と対策について4名のエンジニアが登壇しました。イベント告知https://gmo.connpass.com/event/192336/当日の様子をレポートいたします。 はじめに こんにちはGMOペイメントゲートウェイ（以下、GMO-PG）の広報担当です。 今回GMO-PGとしては初の試みとなるエンジニアのオンラインイベントを開催いたしました。一口に決済といっても、様々な環境、技術を駆使してそのバックエンドを支えています。4つのセッションでは4名のエンジニアそれぞれが実経験をベースとした学びをご紹介いたしました！ オープニングトーク オープニングセッションでは、GMO-PGシステム本部CTOの三谷より、会社紹介、コロナ禍における決済市場・エンジニアの状況、また決済事業者で働くことのエンジニアのメリットやデメリットについてお話ししました。 その中から一部抜粋してご紹介いたします。 「昨今決済手段多様化しています。コロナ禍で非接触な形態でのキャッシュレスが非常に推進されてもいます。このエリアはニーズが高まっており、現時点で我々のお客様14万をこえて、取引量も現時点では5.8兆円で日々増えている状況です。会社としてはおかげさまで毎年25%成長を継続し、取引量だけでなくサービス拡充含め開発ニーズ自体も25%成長を続けています。その処理を支えているシステム本部の我々ですが、現在エンジニアは180名程度。内製開発にこだわっており、Linux、Javaを中心としたオープンソースベースで開発を行っています。システム本部のベースは渋谷ですが、福岡にも開発拠点があり、毎年新卒・中途あわせておおよそ30名ほど新しいエンジニアを増やしています。 決済事業者一般ではなく我々の特徴になると思いますが、サービスをインテグレーションするなかで、設計書の「てにをは」を直したり、テストエビデンス不足ばかりでうんざりといったことは、IT業界あるあるです。我々はそれを省いています。設計書ゼロではないですが数百ページの設計書の無駄は多いですから。 わたし（三谷）含め、マネージャーもみんなコードがかけるメンバーなので、最終的にはコードで会話するのが早いし正しいし間違いない。全体を理解するための概念設計書は作ったとしても、詳細なものは省いてスピードを速める。そんな発想からやっています。我々エンジニアを常に募集しています。少しでも興味が湧いたという方がいれば幸いです。」 配信映像はこちらhttps://youtu.be/e0-Ex_PboMo セッション①：10万店舗以上の加盟店様のオンライン決済を支える｢PGマルチペイメントサービス｣のマイクロサービス移行計画』 10年以上前にリリースしたPGマルチペイメントサービスはモノリシックなアプリであり、1つのアプリケーションの中に機能が詰め込まれていました。更改前の課題は、レガシーでモノリシックですので技術的な負債がどんどん蓄積されていくというところにありました。局所的な問題がアプリ全体に波及していく状態です。これを解決するため、2019年のシステム更改の際に「マイクロサービス移行計画」をたて、実行いたしました。その結果に関して、佐久間よりお話しいたしました。 セッション内容全文はこちらhttps://www.gmo-pg.com/blog/article-004/ 配信映像はこちらhttps://youtu.be/KvhHKKhPPPU セッション②：決済サービスをコンテナ+クラウドで運用するということ(運用半年編) R&D室の駒井からは、「こんど払い byGMO」というサービスを例に、オンプレKVMというアーキテクチャで構築してきたエンジニアチームが、クラウド＋コンテナというアーキテクチャでプロダクションサービス運用をはじめて半年で経験した良かった点、悪かった点の体験談をご紹介しました。 セッション内容全文はこちらhttps://www.gmo-pg.com/blog/article-005 配信映像はこちらhttps://youtu.be/d-BDhVU2GFg セッション③：オンプレ勢がAWSで月300万件の決済システムを作った話 3つ目のセッションでは、AWSにおける決済システムの開発について、継続課金決済グループの佐藤より、実際に300万のユーザー様の料金支払いに関して実現した取り組みをご紹介いたしました。 セッション内容全文はこちらhttps://www.gmo-pg.com/blog/article-006/ 配信映像はこちらhttps://youtu.be/MLW39vzZePY セッション④：PG流キャッシュレスのシクミ作り～新サービス提供に向けた早くて安定した決済システムをつくる～ 最後のセッションでは、中村より新しい決済サービスを提供するにあたり、考えるべき「シクミ」作りに関して1点目は「ユーザーが使いやすく、導入しやすいシクミとは？」2点目は「今後のサービス拡大に耐えうるシクミとは？」3点目は「スピーディに、かつ安心・安定したシクミにするには？」という、3点をご紹介しました。 セッション内容全文はこちらhttps://www.gmo-pg.com/blog/article-007/ 配信映像はこちらhttps://youtu.be/gafSMkoExtQ 感想 この度イベントにご参加いただいた方、またアーカイブなどご覧いただいた方誠にありがとうございました。リアルタイムでも数百名を超える多くの方にご覧いただき大変有難く、驚きましたが、弊社にご興味をお持ちいただき嬉しく思います。 ご質問も多数いただいておりましたが、想定以上に濃い内容のご質問をいただいたこともあり、回答できなかった方は申し訳ありませんでした。 今後もエンジニアチームとして、できるだけ発信をしていければと考えておりますので、是非GMO-PGの動向を追いかけてください。（三谷） まとめ 以上、イベントレポートとなります。今回のイベントの様子はYouTubeにてアーカイブを公開しております。イベント全編： https://youtu.be/x2BMp701SEw 動画を見られない方は、テキストでも公開しておりますので、是非ご覧ください。https://www.gmo-pg.com/blog/list.html?ch=ch_engineer また、GMO-PGでは、エンジニアを募集しています。募集概要は以下からご確認ください。GMOペイメントゲートウェイ採用ページ