GMOペパボ の記事一覧

GMOペパボでは「Pepabo Tech Conference」と題し、開発者に向けたイベントを定期開催しています。今回の「Pepabo Tech Conference #14」では、ペパボのプラットフォームテクノロジーをテーマに、技術基盤チーム・データ基盤チーム・プラットフォームグループ（SRE）・セキュリティ対策室のメンバーが登壇し、各チームの取り組みについてお話させていただきます。 Pepabo Tech Conferenceとは？ GMOペパボでは、「アウトプットすること」を大切にする企業文化があり、自社で培ってきた技術や知見を幅広く公開し、社内だけでなく社会全体に貢献する姿勢を大切にします。その一環として「Pepabo Tech Conference」と題し、様々なテーマで開発者に向けたイベントを定期開催しています。 イベント概要 日　　時 ：2021年2月25日（木）時　　間 ：19:00～21:00場　　所 ：オンライン タイムテーブル 19:00オープニング19:05ペパボサービスインフラのこれから常松伸哉19:25ペパボにおけるコンテナとハイブリッドクラウド活用による可用性向上への取り組み高橋拓也19:45SREが取り組むカラーミーショップへのK8導入菅原千晶20:05データ基盤チームの設立と直近の取り組み堤利史20:253Coで支えるペパボのセキュリティ対策～Communication Completely Continuous～熊野・伊藤・森田20:55クロージング※発表順については変動の可能性があります。 イベント詳細・お申込みはこちら https://pepabo.connpass.com/event/204392/ 登壇者 〇常松伸哉2009年入社、技術部シニアエンジニアリングリード。サービスのインフラエンジニアを経た後、プライベートクラウドの構築・運用に携わるほか、全社的な課題解決にインフラ面から取り組んでいる。2020年より現任。エンジニア組織の運営と並行して、SREやクラウドネイティブといったトピックを推進している。カレーが大好きだけど最近全然食べに外出できていなくてツラい。 〇高橋拓也技術部技術基盤チームに所属するインフラエンジニア。2019年10月にGMOペパボ入社。2020年10月よりプリンシパルエンジニアに就任。ペパボが運営するサービスにおけるクラウドの有効活用によるシステムの安定稼働に注力する。 〇菅原千晶2018年3月にペパボカレッジ6期生として入社。SREとしてカラーミーショップの運用に携わっている。 〇堤利史2020年12月にGMOペパボ株式会社へ入社。技術部 データ基盤チームに所属するデータエンジニア。 〇熊野多聞2007年 に入社、マネージャー。複数商材のインフラエンジニア、インフラ基盤を支えるプロットフォームのマネジメントをヘテセキュリティ対策の推進、マネジメントに従事している。 〇伊藤洋也2007年 に入社、プリンシパルエンジニア。ホスティングのWebサービス〜事業部を横断した技術基盤チームの経験を活かしてセキュリティ対策の仕組み作りプロダクトの開発に従事している。 〇森田浩平2018 年 に新卒入社、シニアエンジニア。セキュリティ対策室で事業部を横断したセキュリティ対策等の基盤づくりに従事している。 お申込みをおまちしております！

GMOペパボでモバイルアプリケーションの開発をしているメンバーがお話させていただきます。 こんな方におすすめ！ ・モバイルアプリケーションの開発に携われている、開発者の方・minne/SUZURIにご興味のある方・大規模な自社サービスのエンジニアリングに興味のある方・若手エンジニアがどんな活躍をしているのか話を聞いてみたい学生の方・GMOペパボ、GMOインターネットグループに興味のある方 イベント概要 日時：2020年10月16日（金）19:00～21:00場所：オンライン対象者：エンジニアとして働いている方、またエンジニアリングに興味関心のある方 ※学生の方も大歓迎です！ タイムテーブル ・19:00　 オープニング・19:02 　新卒エンジニアが配属3ヶ月でやってきたこと @Tatsumi000・19:20 　バックエンド駆動UI: 画面の流動化（英語名：Backend-Driven UI: 　　　　　　　　　　Making Screens Dynamic） @yhkaplan・19:40 　iOS13でもSwiftUIでLazyなGridを実装したい！ @kuroyam・20:00 　ペパボのデザインシステムと、モバイルアプリ領域における取り組み @gyugyu・20:20 　SUZURI Androidアプリの例から提案するこれからのモバイルアプリケーションのデザインプロセス @putchom・20:40 　ペパボとFlutterのこれまでとこれから @osamtimizer・21:00 　クロージング 登壇者/セッション内容 セッション①：「新卒エンジニアが配属3ヶ月でやってきたこと」EC事業部 カラーミーショップグループ サービス基盤チーム西田 龍登 セッション②：「バックエンド駆動UI: 画面の流動化（英語名：Backend-Driven UI: Making Screens Dynamic）」minne事業部 マーケットグループジョシュア・カプラン セッション③：「iOS13でもSwiftUIでLazyなGridを実装したい！」SUZURI事業部 プロダクトチーム黒田 駿 セッション④：「ペパボのデザインシステムと、モバイルアプリ領域における取り組み」デザイン部 デザイン戦略チーム柳生祐介 セッション⑤：「SUZURI Androidアプリの例から提案するこれからのモバイルアプリケーションのデザインプロセス」SUZURI事業部 プロダクトチーム福嶋 瞭 セッション⑥：「ペパボとFlutterのこれまでとこれから」SUZURI事業部 プロダクトチーム時田 理 参加方法 connpassで参加ご登録いただいた方にZoomウェビナーの視聴用URLをお送りいたします。 ▼connpasshttps://pepabo.connpass.com/event/190760/

執行役員 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 やアンケートなどの機能があるため、これらを活用するなどして、視聴者との一体感をできるだけ醸成して行きたいと思います。 GMOペパボでは、新しい仲間を募集しています 募集中の職種や、詳しい社内の環境や制度に関しては以下をご覧ください。 GMOペパボ株式会社 採用サイト