［開催レポート］GMO Developers Night#10 / ペパボECテックカンファレンス / 開発者向けブログ・イベント

執行役員 VP of Engineering 兼技術部長の @hsbt です。週末に少しずつ進めていたゼノブレイドディフィニティブエディションをやっとクリアしました。
今回は、6/24 に開催した GMO ペパボ EC テックカンファレンスの開催レポートをお届けします。

EC テックカンファレンスの開催について

GMO インターネットグループが昨年より開催している GMO Developer Night のイベントの一つとして開催しました。GMO Developer Night は渋谷フクラスにて、継続的に開催予定でしたが COVID-19 の拡大の影響によりリアルイベントとしては中止になり、EC テックカンファレンスも当初は 3 月頃の開催予定が白紙となりました。

今回、GMO Developer Night がオンラインとして開催が再開したため、EC テックカンファレンスもオンラインバージョンとして開催しました。GMO ペパボの EC 事業部がサービス運営しているカラーミーショップでは、新たにリリースしたアプリストア、サービスの可用性の向上、2018 年の情報流出のインシデント以降に体制を改めたセキュリティ対策、デザインやカスタマーリレーションの体制など、毎日幅広く技術・デザインの領域への取り組みを行なっています。今回開催した EC テックカンファレンスではカラーミーショップの毎日の取り組みを紹介する場として、「普段やっていること・考えていること」を中心にコンテンツを用意しました。

発表内容の紹介

カンファレンスの様子は YouTube Live を録画したものが公開されていますが、このエントリではEC事業部チーフテクニカルリードの@kenchanが各セッションの内容を簡単に紹介します。

ポストコロナの商売を支える、カラーミーショップのアーキテクチャのこれから

発表資料: ポストコロナの商売を支えるカラーミーショップのアーキテクチャのこれから / The new architecture of COLORME SHOP in the Post-COVID-19 world – Speaker Deck

最初のセッションでは、私@kenchanがサーバサイドとインフラのアーキテクチャについて現在取り組んでいる課題を紹介しました。

昨今の状況においては、ネットショップの重要性が以前とは比べ物にならないほど高いものになっています。その状況においてもお客様に選ばれるシステムであり続けるためには、システム全体の可用性を今まで以上に向上させなければいけないと考えています。そのために、データベースの耐障害性・可用性の向上、サブシステム単位でのスケーラビリティの向上、そして特定の箇所で発生した障害を広く波及させないためのアーキテクチャの検討を進めています。

大量購入を支える決済トランザクション設計

発表資料: 大量購入を支える決済トランザクション設計 / EC Payment Transaction Architecture – Speaker Deck

2 番目のセッションでは、EC 事業部テクニカルリードの@tsuchikazuが決済処理を設計するにあたり考慮すべきポイントと、カラーミーショップでの実装を紹介しました。

まず、決済処理のトランザクション設計をするにあたり必要な観点として、CAP 定理と BASE 特性という 2 つを提示しました。そして、それらを踏まえてカラーミーショップで実施している工夫として、トランザクションを細かく分離すること、補償トランザクション、データ突合の 3 つを紹介しました。

インターネット上でサービスを提供する際には、何らかの形で決済処理を設計、実装する必要があることから、Zoom 上での質問も、Twitter 上の反応も盛り上がっていました。

カラーミーショップカートの Angular 事情

発表資料: カラーミーショップカートの Angular 事情 / Angular circumstances of colorme-cart – Speaker Deck

3 番目のセッションは、@ku00_より、AngularJS から Angular へのバージョンアップの取り組みの発表でした。

カラーミーショップの新しいショッピングカートは AngularJS で実装されています。AngularJS はバージョン 2 から Angular をという名称になり、大きな変更が加えられました。今までは AngularJS のまま機能追加を行っていましたが、Angular のより便利な機能を使えなかったり、AngularJS の EOL が近づいてきたこともあり、チームでバージョンアップに取り組んでいます。定期的な勉強会を開くことでチームの技術力の向上を図りながら、Angular の機能を理解するために小さなアプリケーションを開発することで、移行後にもスムーズに機能開発ができるように工夫しています。

カラーミーのデザインについて

発表資料: GMOペパボ ECテックカンファレンスデザイナー登壇資料 – Speaker Deck

4 番目のセッションは、カラーミーショップのシニアデザイナーである@chocolatinaがカラーミーショップのそれぞれのチームにおけるデザイナーの取り組みを紹介しました。

カラーミーショップでは、ユーザーの登録から、そのユーザが私達のサービスを使いながら事業を成長させるところまで、トータルで支援できるようにチームを編成しています。その各フェーズにおいて、デザイナーに求められる役割はスキルは変わってきます。印刷物のビジュアルデザインから、プロダクトのUIデザイン、ユーザテストやインタビューまで、幅広い領域をデザイナーの皆さんがカバーしています。

カラーミーショップと ngx_mruby 2020

発表資料: カラーミーショップと ngx_mruby 2020 – Speaker Deck

休憩後、5 番目のセッションでは@yano3から、カラーミーショップにおける ngx_mruby の活用事例の紹介でした。

カラーミーショップアプリストアで提供されているカラーミーWPオプションは、ショップドメインと同じドメインで WordPress を公開することができます。この機能を実装するにあたり、より汎用的な仕組みとするためのルーティングの部分と、セキュリティ対策の 2 点において ngx_mruby を利用しています。

受注増でも変わらずショップ運営できる、利用者に寄り添い未来に備えるカラーミーショップについて

発表資料: 利用者に寄り添い未来に備えるカラーミーショップ – Speaker Deck

6 番目のセッションでは、サブマネージャの@nyanyamiが CRE チームの取り組みとその実績を紹介しました。

カラーミーショップの CRE(Customer Reliability Engineering)チームでは、ユーザーの課題解決のための技術的な調査や機能開発を行っています。CRE チームを結成しその目的を明確にしたことで、問い合わせ完了までの日数を大幅に改善しました。さらに、提供している機能の中でもよく使われている、重要な機能の改善に力をかけられるように、使われていない機能をユーザーの不利益にならないように工夫しながらクローズしています。

WAF を安全に導入するために取り組んだこと

発表資料: WAFを安全に導入するために取り組んだこと – Speaker Deck

7 番目のセッションでは、@takapi86がカラーミーショップにおける Web Application Firewall(以降 WAF)の導入プロセスを紹介しました。

既に動作しているウェブアプリケーションに対する WAF の導入は、誤検知を如何に減らすかがポイントになります。また、導入後の機能追加に追従して WAF のルールをメンテナンスしていくことも重要です。カラーミーショップへの導入時には、検知ログの収集の仕組みを構築し、除外ルールをコードで管理することで、これらの課題を解決しました。

デザインもドメインも違うサイト上でのプレビュー機能をフロントエンドのみで実現したらユーザーもエンジニアもハッピーになった話

発表資料: デザインもドメインも違うサイト上のプレビュー機能をフロントエンドのみで実現したらユーザーもエンジニアもハッピーになった話 / How to preview on cross domain – Speaker Deck

最後のセッションは、@MITLicenseからのプレビュー機能の実装における工夫の紹介でした。

カラーミーショップアプリストアでは、ユーザーが閲覧する「アプリストア」と、開発者がアプリストアに表示する情報を登録する「ディベロッパーサイト」を別のアプリ、ドメインで運用しています。そのため、開発者がアプリストア上でどのように表示されるかを確認するために、ディベロッパーサイト上でプレビューを実装する必要がありました。この問題に対して、利便性とセキュリティの両面から検討を行い、window.postMessageと iframe を利用した方式で実装しました。

ZoomウェビナーでのQA

事前に登録してくださった方にはZoomウェビナーのURLをお送りしており、当日はQA機能を使って質問を受け付けていました。本記事の最後に、そこで寄せられた質問とその回答を紹介します。

また、ハッシュタグ#GMOdev で寄せられた質問にもいくつか答えておりますのでこちらもご覧ください。

Q1. 分離環境についてすでにコンテナ環境の導入が進められているということでしたが、クラスタの分離というのは kubernetes 上でのクラスタの分離ということでしょうか？

現時点では、あくまでも論理的に分割しようというところまでで、技術的にそれをどうやって実現するかについては、まさに今検討しているところです。

Q2. 決済部分でAPIを使われるのですか。

購入ボタンを押して完了画面を表示するまでの間の決済トランザクションのタイミングで、決済代行会社へのリクエストをしています。

Q3. リトライが可能かつ、多重決済をおこさないために行っている具体的な工夫をぜひ知りたいです。いくつかチェックポイントを持った段階的なトランザクションのようですが、ロールバック不可能なタイミングなどはあるのでしょうか？また、リカバリーが困難な失敗したとき（ロックをロールバックすると危険な状態担った時）に、カスタマサポートへうまくエスカレーションする工夫はされていますか？

リトライが可能かつ、多重決済をおこさないために行っている具体的な工夫をぜひ知りたいです。

そのトランザクション用に、一意のIDを予め発行して、そのIDで決済APIを実行することにしています。仮に2度決済APIを実行したとしても、IDが重複してエラーになる。という形で、多重決済は防げています。

いくつかチェックポイントを持った段階的なトランザクションのようですが、ロールバック不可能なタイミングなどはあるのでしょうか？

いつでもロールバックは可能で、ある程度進んだら、もう戻らない。という形にしています。ロールバック不可能という意味だと、ロールバックのタイミングで障害が起きている場合があって、そのときはリトライでカバーという形です。

また、リカバリーが困難な失敗したとき（ロックをロールバックすると危険な状態担った時）に、カスタマサポートへうまくエスカレーションする工夫はされていますか？

リカバリに失敗した場合は、slackに全部流れるようになっていまして、大量に失敗した場合など異常事態が発生したら、弊社のエスカレのフローによって、CSへもエスカレーションするようになっています（エスカレもslack上で全部やっていきます）

Q4. 「ユーザーの操作ログ」みたいなリプレイをするためのログはとられていますか？

購入者の操作についてだと、APIへのアクセスログで操作の流れはわかる場合があります。しかし、操作を再現することを目的としたログは取得していません。ただし、社内向けの環境や、別途特定のブラウザに対してデバッグが必要な場合など、本番環境に影響を与えないように操作ログを取得する場合はあります。

Q5. そもそもAngularを採用した理由を聞きたいです。

カート開発当初にAngularJSを採用した理由について回答します。

プロジェクト開始当初（2014年10月頃）はBackbone.jsのような一世代前のライブラリか、その時の話題になっているAngularJSかの選択肢がありました。ReactやVue.jSはそもそも選択肢になかったので、カート画面の主な機能であるフォームのデータバインディングに最も適したフレームワークという点からAngularJSを選択しました。

Q6. iframeをつかったプレビューについて、iframe name + form target ではなく、postMessageをつかった理由はなにかありますか？また、Origin以外にトークン的なものをなげたりはしていますか？最後に、画像などは都度実際に保存していますか？それは保存時に正式な場所に移動したりしていますか？

iframeをつかったプレビューについて、iframe name + form target ではなく、postMessageをつかった理由はなにかありますか？

ご提案していただいた実装が候補に上がらなかった理由の一つとして、アプリストアは Vue.js (Nuxt) のアプリケーションなので、 form target による実装では POST のメッセージを受け取るために別途バックエンド側に何か用意するといった実装が必要になります。これはフロントエンドのみで実装が完結できる postMessage と比べると実装や再描画のコストが高くなってしまうため、もし候補に上がっていたとしても最終的には postMessage を選択することになったと思います。

Origin以外にトークン的なものをなげたりはしていますか？

入力されている情報をサーバー側に送ることがなく、基本的に発表中にあった満たしたいセキュリティ要件は origin の検証のみで達成できることから、トークンなどの検証は特に行っていません。

画像などは都度実際に保存していますか？それは保存時に正式な場所に移動したりしていますか？

保存を行っていない段階では画像ファイルは Data URI scheme を使ってやりとりをしており、ご指摘の通り申請情報を保存した時にサーバーへアップロードが行われます。

おわりに

このエントリのはじめに、「普段やっていること・考えていること」をコンテンツとして集めたという話がありましたが、その狙い通りのカンファレンスとなったのではないかと考えています。カラーミーショップを日々開発・運用している人たちが、どのような課題に、どうやって取り組んでいるのかを感じ取っていただけたでしょうか。

また、もし皆さんの身近な課題解決に役に立つ発表があったようでしたら、適用してみた結果を私達にもフィードバックしていただけたらとても嬉しく思います。

オンラインでのイベントは今年からはじめた新たな取り組みのため、リアルイベントとは異なりイベント後に「この話の詳細ですが〜」と個別にお話をする機会がなく伝えきれない部分や、逆にオンラインだからこそわかりやすい面、例えばスライドが見やすい、などメリット・デメリットの両方があります。Zoom では QA やアンケートなどの機能があるため、これらを活用するなどして、視聴者との一体感をできるだけ醸成して行きたいと思います。