技術情報 の記事一覧

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。今回は2日目にリアル会場で開催された「クラウドネイティブセッション」をご紹介します。 登壇者 スピーカー 山下和彦GMOペパボ株式会社技術部技術基盤チーム佐藤慎治GMOグローバルサイン・ホールディングス株式会社マネージドサービス事業推進室山崎牧彦GMOペイメントゲートウェイ株式会社ITサービス統括部オペレーション・セキュリティ部サービス運用 モデレーター 長谷川泰斗GMOインターネットグループ株式会社インフラ・運用本部クラウドサービス開発部コンピュートプロダクトチーム （左から）GMOインターネットグループ 長谷川、GMOペパボ 山下、GMOグローバルサイン・ホールディングス 佐藤、GMOペイメントゲートウェイ 山崎 クラウド移行で、気になる「従量課金」 GMOインターネットグループのエンジニア4人が集まったセッション。クラウドだけでなく、オンプレミスのサービスにも精通している4人が、自社のサービスで利用するサーバーやアプリケーションなどについて語り尽くしました。 最初にモデレーターの長谷川が問いかけたのは、「従量課金の計算」について。オンプレミスからクラウドに移行した場合、従量課金で毎月の料金がどの程度変わるのか、という点を尋ねました。 GMOペイメントゲートウェイでは、AWS（Amazon Web Services）を採用していて、請求単位のAWSアカウントがサービスごと、環境ごとで分かれていていると山崎は説明。サービスごとに稟議を出して、それを元に予算が決まっていると話します。「円安で予算の計算が狂わなかったか」と問われ、山崎は「計算は狂っていませんが、それでも円安は大変で、コスト削減策も考えています」とのこと。 GMOペイメントゲートウェイ 山崎 コストに関しては、AWSの機械学習を用いたコストの異常検知アラーム設定を活用。特定のアカウントで急にコストが上がれば通知するという設定にしているといいます。 急激なコスト増だけでなく、「AWSでよくあるのが、ちょっとした作業でインスタンスを起こした際に、後で終了させるのを忘れてしまうこと」と話したのが山下。こうなってしまうと、ずっとコストがかかり続けてしまいます。 こうした状況に対して山崎は「定期的に棚卸しをする」という対策を示しますが、それでもアカウントの数が多いことで、担当者によっては放置されてしまうこともあり、注意が必要と話します。そのため、インスタンスの監視運用のためにLamdaを使って、「定時内しか起動しない」などの設定を実施しています。 佐藤は、 「同社がB2B向けの運用サービスを提供しており、コストの請求ツール提供、コストの監視設定、サーバーのトラフィック、サーバーのパフォーマンスといった監視も可能です」としています。ただ、それでも全てを完全にチェックすることは不可能で、コストなどに大きな変化があった場合に「SNSやSlackに送る」という使い方を紹介します。 どのようにナレッジの共有を行っているか 続いての質問では、長谷川がVM（仮想マシン）からコンテナ、オンプレミスからコンテナといったように、クラウドへの移行に際してのナレッジ共有をどうしているのか、と問いかけました。 GMOペパボは、山下が入社してすぐの7年前頃にはプライベートクラウドのOpenStackでサーバー基盤を開発していましたが、現在はコンテナに移行していると説明しました。OpenStackは、GMOインターネットグループのConoHaで使われており、そのナレッジがあったのでそれを活用して構築したものです。 GMOペパボ 山下 当初はサーバもレンタル契約でConoHaのOpenStackのノウハウをそのまま持ち込んでいたのですが、その後はサーバも自社で調達し、OpenStackのバージョンアップをしたほか、Kubernetesへも移行して、社内でコンテナ技術に関する知見を深めていきました。同社のサービスである「ロリポップ！マネージドクラウド」でコンテナ中心のサービスを提供したことでも知見を深められたといいます。こうして自分たちでナレッジを積み上げたのがGMOペパボです。 ちなみに、GMOペパボは事業部制で、「ハンドメイドサービスのminneでは9割がKubernetesで、AWSとオンプレミスのハイブリッドクラウド」（山下）でサービスを運営しています。。通常はOpenStackで9割のトラフィックを処理していますが、ピーク時にはAWSとオンプレミスの比率を変えることで処理を行っています。当初は手動で比率を変えていましたが、現在はトラフィックに応じて自動で比率を変えるようにしているそうです。 「AWSは移行のためのツールが揃っている」と話すのは佐藤です。「オンプレミスからAWS、クラウドからAWSへの移行など、マイグレーションツールを使うことでどの環境でも移行に対応できるようナレッジを蓄積してきました」と言います。それでも対応できない古いサーバーであれば、どのように対応するかは「お客様に合わせてお手伝いする。結構需要があります」（佐藤）とのこと。 他にも、「マルチクラウドの案件が増えてきている」（佐藤）。Googleの良さ、AWSの良さ、オンプレミスの良さはそれぞれあり、「いいとこ取りをしようと考えています」と佐藤は話します。 GMOグローバルサイン・ホールディングス 佐藤 クラウド利用時のセキュリティについて 次の「クラウド利用時のセキュリティの留意点」という質問には、まず山崎が「AWS Security Hubを使って、なるべく簡潔に運用コストを減らしています」と回答しました。Security Hubで検出された項目に対して、AWSアカウントの担当者に通知して修正してもらい、修正をチェックする、という手順になっているといいます。 GMOグローバルサイン・ホールディングス社のCloudCREWでは、お客様に提供するサービスとしてAWS Security Hubにも対応できるほか、お客様がセキュリティに興味がある、セキュリティを重視しているといった場合には、それ以外のセキュリティサービスも提供できるようにしています。AWSには複数のセキュリティに関するサービスがあるため、お客様にどのようにそのサービスを分かりやすく伝えるか、といった点を考えた結果、「新しいセキュリティサービスの設計をしているので期待して下さい」（佐藤）。 ただ、Security Hubは通知が多いため「ノイジーなところがある」と山下は指摘しました。GMOグローバルサインではSecurity Hubそのままの情報を提供するのではなく、精査をして重要なものだけを通知するようにしていると佐藤は説明。「クリティカルなものを通知するのが一番いい」というのが佐藤の判断です。 山崎もフィルターを設定しており、セキュリティ担当者と精査していると話します。Security Hub上では重要度が低い表示になっていても、環境によってはリスクが高い場合もあるとして、工夫が必要という認識を山崎は示します。 どのようにログを収集して、活用しているか 続いての議題はログ収集について。長谷川は、「Kubernetesでコンテナを立てていますが、コンテナがなくなるとログも消えてしまいます。どう収集していますか？」と問いかけます。 GMOインターネットグループ 長谷川 山下は、ライフサイクルによって変更しているとのことで、「基本的にはコンテナのログを集めて、それをApache Kafkaに出力。さらにそこからAmazon S3に保全する、BigQueryを使って解析に利用する」といった使い方をしているそうです。保存期間が短いログであれば、Grafana Lokiも使っていて、ログの検索もできるようになっているとのこと。 Grafana LokiはURLを使ってログの共有ができる点が便利だと山下。ライフサイクルに関しては、例えばセキュリティ関連のログは3～5年の期間、Amazon S3に保管していると話します。 GMOペイメントゲートウェイでは、オンプレミスのサービスではログ集約サーバーがあるのでそこに保管。AWSを使っているサービスでは、最終的にAmazon S3に集約して、ライフサイクルに応じて処理していると山崎は説明します。同社では、AWSアカウントごとに担当者がおり、それぞれログを調査したいといった場合もあるため、Amazon S3のバケットなどで調査分析をできるようにしているといいます。「集約を忘れないことが重要です」と山崎。 佐藤は、「ログは事件が起きたときに引っ張り出すのが重要」と指摘。「Amazon S3に蓄積して、BigQueryを使って見やすい状態にできるので、クラウドネイティブのサービスでもオンプレミスでも、ログだけは一貫した使い方をします」と説明します。 「実際の事件とまでは行かなくても、ヒヤリハットな事例はありましたか？」と長谷川が問いかけると、山下が「OpenStackのポートの論理情報を全て消してしまったことがありました」と明かしました。OpenStackは構成情報をキャッシュのように保持していて、マスターを消去してしまってもキャッシュが動作している限りは復元できるため、データベースを復旧して事なきを得たそうです。 山崎は、Amazon GuardDutyを設定しておいて良かったと感じているそう。「マネージド型脅威検出サービス」として活用されるGuardDutyですが、これまで一度だけアラートがあり、AWSの権限の設定間違いが検出されていたといいます。これ自体は大きな問題となるものではなかったのですが、通知によって問題に気付くことができたとその効果を指摘。「イベントベースでアラートを発行してくれるというのは、オンプレミスだとなかなか難しいのではと思っていて、それがクラウドの良さだと思う」と山崎は話します。 こうしたセキュリティ系のサービスは「よく分からないことをしているだけで料金が取られる、と感じてオフにしてしまう人もいる」と山崎は注意喚起をして、「地味な足回りですがセキュリティをきちんとやっていくのは大事」と強調します。 セキュリティ面では、スピーカーの山下が他の面々に対して質問もしていました。プログラミング言語のパッケージやコンテナなどの脆弱性の管理をどうしているか、というものでした。 佐藤は、お客様次第としつつ「IPアドレスで制限して入ってこられないようにしてしまう」という方法を紹介。「脆弱性は即時に対応できるものばかりではないので、対応が遅れたら危険なクリティカルなものを選んで対処している。どうしても対応できないものに対しては、アクセスをなるべく遮断しておくことで対応しています」と話します。 山崎は、社内のセキュリティ組織が脆弱性情報を集めて対策を検討し、対応が必要ならば通知が来るようになっていると説明します。AWSのコンテナでもオンプレミス上のアプリでも、どういったものが動作しているかインベントリーを収集して、脆弱性が関連するかどうかを見極めているそうですが、山崎は「まだ完全ではありません」と話します。 GMOペパボも同様の仕組みで対処をしていると山下は説明。危険な脆弱性であれば即日対処するといったように、危険度に応じた対処が重要だという指摘には佐藤も同意していました。 クラウドネイティブと、どう向き合っていくか 最後にコメントを求められた佐藤は、「クラウドネイティブの今後をどう捉えていくか」という質問を投げかけます。これに対して山下は「ひとつのキーワードは可搬性」と言います。これは、AWSでもGoogle Cloudでもどのクラウドでも、そしてKubernetesでもCloud FunctionsでもLambdaでも動作する、といった具合に1バイナリで環境を問わずに動作する世界を想定していました。 山下は、「Wasm（WebAssembly）が流行しかけているが、もうちょっと色んな言語で速く動くようになると、そんな時代になるのではないか」と期待感を表明。WasmがWebアプリケーションでもいろいろなプラットフォームで使われるようになると「アーキテクチャが変わってくるかもしれない」との考えを示します。 山崎はAWSが「一昔前はインフラを提供しているイメージだった」としつつ、例えばシムシティのような大規模3Dシミュレーション演算ができるサービスも提供するなど、幅広い領域に進出していると言及。結果として、AWSやGoogle Cloudなどはインフラエンジニアだけが触れるものだと避けるのではなく、アプリケーションエンジニアもどのように活用するかを考える必要性を指摘します。 こうしたコメントを受けて、長谷川自身もオンプレミスでのKubernetes構築の中で、OSやきょう体によって動作が異なるという点に苦しめられてきた経験を話し、基盤に関係なくアプリケーションがどの環境でも動作するのは重要だと同意していました。 さいごに 「クラウドはいいとこ取りができるので、皆さんもいいとこ取りをして下さい」と長谷川。山崎が「オンプレミスもいいとこありますからね」と笑い、和気あいあいとした雰囲気でセッションはまとめられた。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/c5jhet84uXI

GMOメイクショップ株式会社は、2004年からASP型のECシステム「MakeShop by GMO」を提供しています。サービススタートから18年目を迎え、現在法人で10,000社以上に利用されるなど順調に成長を続けていますが、規模が増大することによっていわゆるレガシーシステムとしての課題が浮き彫りになってきました。「サービスとして成功はしているけど、システムとしてはとても厄介な状態」から、GMOメイクショップはどうやって脱しようとしているのか。GMOインターネットグループが12月6日（火）～7日（水）に渋谷フクラスおよびオンラインにて開催したテックカンファレンス「GMO Developers Day 2022」で、GMOメイクショップの大森康充氏と森健太氏は、レガシーシステムの課題、レガシーシステムを安全に移行する方法と感想について紹介しました。 登壇者 GMOメイクショップ株式会社 事業推進部 マネージャー　大森 康充（左）森 健太（右） システムのレガシー化が引き起こす3つの課題 MakeShop by GMOの最重要指標であるGMV（流通取引総額）は、リリース以来18年連続で成長してきました。また、ここ数年ではコロナ禍の影響でEC市場が活性化し、流通総額も倍近く増加しています。しかし、こうした成長の裏では、システムの規模が増大することによるさまざまな課題が発生していました。 1つめは、技術的負債の蓄積です。大森氏は「技術的負債とはジェンガのようなもの。開発初期は順調に進められていたが、開発が進むにつれてシステムの要素が影響しあいバランスをとることが難しくなる。単純にエンジニアの数を増やしても開発のスピードが上がらなくなる」と説明します。 2つめは、パフォーマンスの問題です。フロントエンドとバックエンドが分離されていないモノリシックなアプリケーションが構築されていたため、スケールが困難に。また、当初の設計思想と乖離している、開発スピードを重視し継ぎ足しで作られた機能をはじめデータとロジックが増加するなど、パフォーマンスは悪化の一途をたどっていました。 3つめは、エンジニアのモチベーションの低下です。エンジニアは「レガシーなシステムの保守をしたくない」「技術的に新しいことをしたい」「キラキラしたことをやりたい」「勉強した内容を活用したい」などといった思いを持っているため採用が進まず、システム開発に大きな影響を与えていました。 リプレースは「テセウスの船のように」少しずつ移行 開発スピードが悪化するにつれて経営層をはじめ非エンジニアも課題を認識するようになったことで、経営層自らが強い危機感を持って率先してシステム課題の解決に向けて動き始め、リプレースプロジェクトがスタートしました。リプレースプロジェクトでは、「システムを止めないこと」「ショップ様に注文データや商品データ、会員データなどの移行の手間を発生させないこと」という2つの方針が定められました。 リプレースで目指したのは、複雑なシステムをシンプルで新しい技術スタックにすることです。大森氏は「システムは、アプリケーション、インフラ、データベース、ネットワークなどさまざまな要素で構成されており、複雑な形をしている。それをシンプルな形にして、パフォーマンスを上げ、エンジニアが開発しやすいようにしていくことを考えていた」とリプレースプロジェクトの目的について話します。 そうはいっても、システムのリプレースは簡単ではありません。特に一度にすべてを変えようとすると、リプレースの失敗に備えて切り戻しの手順を考えたり、さまざまなバックアップを取得してデータやリソースを移行し大きなテストを行ったりする必要があります。 そこで、GMOメイクショップでは、「テセウスの船のように」というギリシャ神話から着想を得たキャッチコピーを用いて、少しずつ移行する方法を採用することにしました。大森氏は「ただでさえ難易度の高いリプレースなので、少しずつ形を変えてリリースすることでリプレースの難易度を下げようと考えた。細かくリプレースすることでよりよいシステムをつくっていければ」とその狙いを説明します。 テセウスの船とは、物事を構成するパーツがすべて置き換えられても、それは過去のものとまったく同じものであるかどうかという問題を表現したものです。このプロジェクトでは、老朽化した船を補修するため劣化した部品を少しずつ修理・交換していくと、やがて最初に使われていた部品は1つもなくなり、まったく新しい船へと生まれ変わるテセウスの船を理想とし、インフラやアーキテクチャなど、システムを構成するパーツを1つひとつ入れ替えながら、「気がついたらリニューアルされていた状態」を目指しているといいます。 段階的に既存システムへの依存を減らすシステム構成 こうした方向性で、現在では段階的なリリースが進められています。既存システムは下図のような構成になっています。 アプリケーションはPHPで構成されており、数十台のアプリケーションサーバーとデータベースが稼働しています。図は簡略化されており、実際にはさまざまな外部アプリケーションやシステムと関連しています。 新システムの構成は下図のとおりです。 フロントエンドとバックエンドを分離し、フロントエンドには、Vue.jsを採用しています。バックエンドは、BFFとgRPCという2つのコンテナ群に分かれているのが特長です。BFFはフロントエンドからのリクエストをGraphQLで受付け、その裏のマイクロサービス群のgRPCにリクエストを投げます。これにより、フロントエンドからは柔軟なリクエストを受付けることができ、バックエンドは互いに独立して開発できるため、スケールが容易となります。 データベースは既存システムと共有することで、新システムからもデータの定義を変えることなく利用できる形になっています。また、一部APIや画面についてはiframeで呼び出すなど、既存システムで活用できる資源を極力活用し、リリースまでの期間を短くするよう工夫しています。また今回の構成では、GitHub Actionsを利用してビルト、テスト、デプロイなどの操作を自動化し、開発エンジニアがより開発に専念できる形にしています。 さらに、次の段階の構成としては、iframeおよびAPIの呼出を削除して既存システムへの依存関係を少しずつ減らし、最終的には、既存システムへの依存をゼロにすることを目指しています。データベースは既存システムと分割して、新システムで構築することを考えています。これにより、gRPCがそれぞれ独立したデータベースを持つことになります。さらに、互いのシステムが疎結合になるため、独立して開発できる要素が増えていきます。 技術的負債、パフォーマンスの改善を実現 リプレースプロジェクトによって、実際に技術的負債は改善されつつあります。まずは、フロントエンドとバックエンドを分離することによって、エンジニアはより専門性の高い開発ができるようになりました。また、マイクロサービス構成にしたことで、各サービスを独立して開発でき、開発スピードがスケールできるようになりました。そして、定期的にプロジェクトメンバー全員でリファクタリングを議論したことで、コードの均質化・見通しの良さの向上につながりました。 パフォーマンスも改善しています。バックエンドシステムの言語をPHPからGoに変更することで、アプリケーションサーバーのパフォーマンスが改善できています。また、DDD・クリーンアーキテクチャを採用し、複雑なロジックを極力疎結合で書くことで、余分な処理を減らしています。再利用性を高めることで、開発スピードも向上しました。マイクロサービス構成とすることで、負荷が高いサービスへのリソースの割当も可能となりました。 エンジニアのモチベーションはどう変わったか？ 最後に大森氏は、エンジニアのモチベーション低下というレガシーシステムの課題について、リプレースのフロントエンド開発を担当する新卒2年目の森氏と振り返りました。 大森プロジェクトにアサインされたときの気持ちはいかがでしたか。 一番新しい業務、技術に触れるということで、楽しみという気持ちが大きかったです。それと同時に自分にとっては初めての大型のチーム開発でしたので、ベテランのチームメンバーのなかプレッシャーも大きかったです。森 大森良かったと感じる点はありましたか。 入社当初は主に既存システムの保守や調査を行っており実務経験は皆無でした。メンバー内でエンジニアとしての経験値の差がかなりありましたが、技術自体の知識のスタートラインは皆同じだったので、お互いに勉強しながら教えあっていくことでチームとしてより強くなれたと感じています。森 大森逆に悪かったと思う点はありましたか。 エンジニアにとって自由度が高いということが災いして、全体像が見づらくなってしまっていました。それにより、途中で方向性を修正する必要がありました。森 大森どんなことに苦労しましたか。 レガシーで大規模なシステムとなっていたため、既存システムの仕様を細かく調査していくのに苦労しました。大まかな機能はわかっていても、他の機能との細かな連携を1つひとつ調べるのは大変です。森 大森新しいシステムが、現行のシステムのように苦労しないためにはどういうことが必要でしょうか。 シンプルに1つひとつの機能を分離していくという考え方です。また、この開発のなかできちんと記録を残していくということも大切になっていくと思います。森 大森ドキュメントはまだまだできていないので、そこは進めたいですね。また構成も、依存関係を少なくしてシンプルにしていきたいです。これから頑張りたいことには、どんなことがありますか。 ユーザビリティにより注力していきたいです。リプレース版のリリースが近づいていますが、リリース後お客様が使い始めてからは大きな変更は難しくなると思うので、今がよりよくする最後のチャンスだと思っています。既存システムを踏襲するだけでなくより進化させたものになるよう、ユーザビリティを考えた開発をしていきたいです。森 大森リプレースによって実際にモチベーションはあがりましたか？ 上がりました。新しい技術に触れること自体も楽しいですし、どんな技術を使って何をつくるか提案したり議論したりしながら進められるので、エンジニアにとって良い環境で開発ができていると感じています。森 大森フレームワークやライブラリの選定などもチームメンバーで気軽に話し合って決められているので、私も楽しくやらせていただいていると感じます。 大森氏は「変化を楽しもう。あなたは必ず変化する。人は気持ちで変化する。」というGMOインターネットグループスピリットベンチャー宣言のなかの言葉を紹介し、講演を締めくくりました。ソフトウェアの技術は常に変化を続けています。初期の技術選択が正解である保証はありません。GMOメイクショップでは、新しい技術の導入をカジュアルに検討し、変化を楽しんで開発を進めていこうというカルチャーをまさに造成しているところです。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/JfBqE9YiNho

GMOペパボ株式会社のデータ基盤チームは、社内外のデータを収集・統合して意味づけを行い、そこで得た情報を社内に循環させるという機能を担っています。GMOペパボは事業部制を採用し複数サービスを運営していますが、同チームは組織横断部門である技術部の1チームとして、他部門と連携しながら事業に貢献しています。GMOインターネットグループが12月6日（火）～7日（水）に渋谷フクラスおよびオンラインにて開催したテックカンファレンス「GMO Developers Day 2022」では、GMOペパボのデータ基盤チームの役割やデータ基盤「Bigfoot」のアップデート内容、データ活用を後押しする仕組みづくりについて、同チームの堤利史氏が紹介しました。 登壇者 堤 利史GMOペパボ株式会社技術部データ基盤チーム シニアエンジニア 組織横断的な取り組みを行うデータ基盤チームのミッション データ基盤チームは、データサイエンティスト1名、データアナリスト1名、データエンジニア3名で構成されており、下記のようなミッションを掲げ、データを切り口とした組織横断的な取り組みを行っています。 「ペパボ内のあらゆるデータに意味をつけ、そのデータによって意思決定の支援を行えるプラットフォームを構築し、ペパボの全パートナーに提供する。」 堤氏は、このミッションの言葉を紐解く形で、同チームの取り組みについて紹介していきました。 まずは「ペパボ内のあらゆるデータ」について。収集対象のデータを主に管理しているのは各事業部とCS室であり、データ基盤チームは必要なデータを収集する作業を担当しています。欲しいデータがない場合には、該当部門とともに新たにつくるという流れで作業を進めます。具体的なデータとしては、各事業用のデータベース、アクセスログや行動ログ、広告やSEOの運用に関わるデータなどといった事業データ、問い合わせデータおよび問い合わせ対応の業務記録といったCSデータがあります。これらのデータは社内のデータ基盤「Bigfoot」に集められます。 ＜参考＞・問い合わせ対応の生産性を計測・可視化するhttps://tech.pepabo.com/2022/06/13/customer-service-productivity/ ・ペパボのログ活用基盤『Bigfoot』を使った Zendesk のデータ可視化https://tech.pepabo.com/2021/02/10/zendesk-data-visualization-with-bigfoot/ 続いて「ペパボの全パートナーに提供」について。GMOペパボでは、自らSQLを書いたりダッシュボードをつくったりするパートナーが多いため、基本的にデータの提供はセルフサービス形式となっています。複雑な集計処理が必要な場合など、個別にやるよりも共通化したほうが効率的な場合にはデータ基盤チームが担当します。アクセス権限はTerraformで管理し、GitHub Enterprise Serverに対するプルリクエストでセキュリティ管理者へ申請する形となっており、3か月間利用していない権限があれば自動的に検知・停止されます。 「プラットフォームを構築」という言葉は、Bigfootを表しています。Bigfootは、主にGoogle Cloud Platform(GCP)を用いて構築されています。堤氏によると、GCPで提供されているサービスだけではニーズを叶えられない場合は、自社でOSSを開発して組み込むというスタンスを取っているといいます。 bigfootの概要図 データ基盤「Bigfoot」のアップデート Bigfootについては2021年のGMO Developers Dayでも紹介されています。そこで堤氏は、この1年間でのアップデート内容を中心に説明しました。 ＜参考＞・GMOペパボのサービスと研究開発を支えるデータ基盤の裏側https://www.youtube.com/watch?v=Kxlchi9fa3I データ基盤チームがまず取り組んだのは、データ抽出に特化した基盤「Yeti」の構築です。GMOペパボでは各事業部でRDBMSを運用していますが、データエンジニアリングに関するノウハウの蓄積と共有、マスキングやポリシータグ管理手法の共通化、事業を横断したデータ活用の推進という主に3つの目的に向けて、その共通基盤をつくりデータ抽出に特化した機能を持たせることにしました。 Yetiの概要図 Yetiは基本的にAWSで構築されています。特長は、各事業のデータベースへアクセスする際にパブリックネットワークを一切利用していない点にあります。Yetiについては、2022年4月にZOZOと共催した「Data Engineering Meetup」で詳しく触れられています。 ＜参考＞・データ抽出基盤Yetiをつくっている話https://speakerdeck.com/tosh2230/yeti-yet-another-extract-transfer-infrastructure データ基盤チームは、生産性指標であるFour Keysの計測にも取り組みました。Four keysとは、Googleが考案したソフトウェア開発チームのパフォーマンスを示す下記4つの指標です。 デプロイの頻度（組織による正常な本番環境へのリリースの頻度）変更のリードタイム（commitから本番環境稼働までの所要時間）変更障害率（デプロイが原因となり本番環境で障害が発生する割合）サービス復元時間（組織が本番環境での障害から回復するのに掛かる時間） Four Keysは事業や期間別にダッシュボード上に可視化され、誰でも閲覧できるようになっているといいます。 ＜参考＞・エンジニアの活動情報からFour Keysを集計、可視化した話https://tech.pepabo.com/2022/01/06/four-keys-dashboard/ また、Four Keysの可視化がきっかけとなり、データ基盤チームは汎用Webアプリケーション基盤「Verne」の構築も行いました。Verneは、Cloud Load Balancing、Cloud Run、IAPをつなぎ合わせたものであり、Four KeysダッシュボードはVerneで稼働している形となります。現在では、GoogleアナリティクスのUTMパラメーターが適切に設定できているかチェックできるツールなど、ダッシュボード以外のアプリケーションもVerne上で働いているといいます。 Verneの構成図 機械学習の活用も進んでいます。ハンドメイド通販サービス「minne」では、作品情報がアップロードされた際に、Apache Beamで説明文の形態素解析を行い、Vertex AIでトピックモデリングを行うという取り組みを行っています。こちらも、2022年4月にZOZOと共催した「Data Engineering Meetup」のなかで紹介されました。 ＜参考＞・BigQueryの日本語データをDataflowとVertexAIでトピックモデリングhttps://speakerdeck.com/zaimy/topic-modeling-of-japanese-data-in-bigquery-with-dataflow-and-vertex-ai また、オリジナルグッズの作成・販売サービス「SUZURI」には、バンディットアルゴリズムが実装されています。バンディットアルゴリズムは、静的A/Bテストで発生しうる機会損失を防ぐもので、minneでもすでに導入済みです。堤氏は、「バンディットアルゴリズムを複数の機能に適用していき、サービスを改善していきたい」と話していました。 データ活用を後押しする仕組み データ活用をするうえでは、データ品質が重要となります。データ基盤チームは、データ品質を向上するための取り組みとして3つのアプローチを取っています。 1つめは、データカタログです。GMOペパボでは、tblsというツールを用い、BigQueryにあるテーブル・列のDescriptionをGitHub Enterprise Serverのリポジトリで管理して誰でも更新できるようにしています。各事業部のRDBMSで利用している場合は、データ収集時にカタログも同期するという使い方ができます。 2つめはデータバリデーションです。データバリデーションは、Load/Transformとテーブルの状態確認の2種類です。前者では、Cloud Composer DAGでBigQueryのASSERT文を実行し、実行したジョブによるデータ操作が期待どおりであるかどうかを検査します。後者は、Querygazerをベースに「Shoegazer」というWebアプリを独自で構築。テーブルに格納されたレコード全体をみて、利用者が期待する状態であるかを定期的にRSpecで検査しています。 3つめはデータリネージです。データリネージでは、堤氏が開発した「Stairlight」というツールを使っています。これは、Cloud Composerにデプロイしているソースコード群からSQLを解析してデータのつながりを見つけるというもので、堤氏によるとVerneやRedashに入っているクエリなどにも展開できるといいます。 また、データ基盤チームでは、データ活用を後押しする取り組みとしてSQLパフォーマンス改善サポートも行っています。具体的には、RedashなどのBIツールにおけるSQL実行履歴から所要時間を確認して、より効率的なクエリになるようデータ基盤チームで支援するというものです。Redashであれば、データが格納されているPostgreSQLからクエリ実行履歴をYetiで抽出し、BigQueryにロード。これをVerneでモニタリングしていきます。 他部門とのさらなる連携とMLOps基盤の構築を目指す 講演の最後に、堤氏は「Bigfootが抱えるデータの量・種類が増えていくと、さらなる組織横断的な動きが求められる。連携をより強化するなかで、収集・付与するデータのバリエーションも増やしていきたい」と今後の展望について語りました。さらに、MLOps基盤の構築を進めていく考えについても次のように話していました。 「現在、機械学習を行いたい場合には各事業部で個別に対応しているが、今後はデータ基盤チームが中心となって基盤という形で共通化して使えるようにしていきたい。具体的には、機械学習パイプラインの整備と展開を進める。また、データリネージとモデルモニタリングを統合して、一気通貫で確認できるようにもしていければ」（堤氏） アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/PWvl-UODTC8

GMOインターネットグループが、12月6日（火）～7日（水）の2日間にわたり開催した「GMO Developers Day 2022」。東京・渋谷フクラスにおけるリアル登壇とオンライン配信のセッションを組み合わせたハイブリッドで開催された今回のイベントでは、Web3、AI、セキュリティ、クリエイティブといった「技術の拡張（Add on）」を、スペシャリストたちが紹介しました。今回はその中から、「プライバシー保護連合学習技術と活用方法について」と題したオンラインセッションをお届けします。登場するのはGMOサイバーセキュリティ byイエラエ株式会社から、AI開発部スペシャリストの伊藤一明です。 登壇者 伊藤 一明GMOサイバーセキュリティ by イエラエ株式会社AI開発部 スペシャリスト 連合学習に暗号技術を「Add on」したDeepProtect インターネット技術の中でもサイバーセキュリティなどに関する事業を展開するGMOサイバーセキュリティ byイエラエ。「誰もが犠牲にならない社会を創る～デジタルネイティブの時代を生きるすべての人が安全に暮らせる社会作りに貢献します～」をミッション＆バリューとして掲げています。 現代の課題の1つとして、伊藤は「複数の組織がデータを持ち寄って分析しないと解決できない課題に対して、データを共有したり開示したりできないという二律背反がある」と指摘します。 これを解決するための技術としてイエラエ社が社会実証・ビジネス化を進めているのが、連合学習と呼ばれる機械学習の手法に、暗号化したまま計算できる特性を持つ準同型暗号を「アドオン」したプライバシー保護連合学習技術である「DeepProtect」です。複数の組織が持つデータセットを互いに秘匿し、プライバシーや機密性を保ったまま共同で機械学習を行える、独自のプライバシー保護連合学習技術となります。 では、そのDeepProtectとはどんな技術でしょうか。 鍵となる技術である「連合学習」は、2017年にGoogleが提唱した機械学習モデルの手法です。Googleでは、キーボードアプリである「Gboard」の予測変換の精度向上に活用しています。 この技術は、機械学習に必要な学習用データを、1つの拠点やサーバに集約せずに作成できるという点が最大の特徴です。散在した学習用データを使っても、作成されたモデルは集約した場合と同等の性能があるとされています。 例えばGboardでは、各スマートフォン上で入力されたテキストデータと入力サジェストのクリック状況等から学習データを生成するのですが、キーボードで入力された文字列やクリック状況は機密性の高いデータになります。この学習データから機械学習を実行し更新モデルを作成するのですが、ここまではGboardをインストールしたスマートフォン内で行われ、学習データはローカルにとどまっています。 その後、更新モデルの差分情報のみがクラウドに送信され、他のユーザーの更新モデルと平均化されて、すべてのユーザーで共有する共有モデルを作成、改善されたモデルを再び共有します。これが個々のスマートフォンにダウンロードされて、再びローカルでの改善、更新モデルの作成に活用されます。これが繰り返されることで、キーボード入力の予測精度が向上する、というのがGboardの連合学習です。学習データ自体はスマートフォン内にとどまり、サーバに集約する必要がありません。 Gboardにおける連合学習の概念図。ローカル内で学習、改善、更新モデルの作成というサイクルを回しつつ、差分情報だけをクラウドに集約して、共有するためのモデルを作成、改善していきます。google資料「Federated Learning: Collaborative Machine Learning without Centralized Training Data」より抜粋 このように、学習モデルを作成する際には個人情報を含むデータの送信が行われず、学習によって得られた差分パラメータ（勾配情報）のみを送信することで、個人情報などの機密データを開示することなく学習モデルを構築できるのが連合学習です。 送信されるのは、プライバシーに関わるような個人情報などではなく、学習モデルの差分パラメータ（勾配情報）のみになります これに「アドオン」する準同型暗号は、その名の通り代数学で知られる「準同型（homomorphic）」の性質を持った暗号方式です。暗号化されたデータに対して加算や乗算といった演算を行った場合、復号した結果が、暗号化しない場合と同じデータ演算結果になる暗号方式です。 例えばEnc(m_1)とEnc(m_2)という暗号化されたデータがあった場合、復号をしない状態でEnc(m_1+m_2)、Enc(m_1×m_2)といった計算が可能で、復号した結果は、もともとの暗号化されていないデータの演算結果と同じとなっています。こうした特性から、暗号化した状態で中身を隠したままデータ処理ができるわけです。 連合学習技術と準同型暗号を組み合わせると、学習モデルの勾配情報を暗号化したまま計算して、その結果を集約して更新するため、データの漏えいを防ぐことができます。送信されるのが勾配情報に限られる上にそのデータは暗号化されているので、中身を見ることができないからです。 勾配情報を暗号化したまま計算する準同型暗号。計算式は図のようになります 厳格なセキュリティ、プライバシー保護によって、組織を横断したデータの利活用が妨げられるという課題に対して、プライバシー保護連合学習技術の「DeepProtect」であれば、個人情報などの機密性の高いデータを開示しなくても、組織を横断したデータ利活用が可能になります。 金融機関における不正取引検知で利用に期待 実例を見てみましょう。JST CRESTでの実証実験として、金融機関における不正取引検知でDeepProtectが活用されました。複数の銀行のデータを使って不正検知の学習モデルを作成するには、これまでは各銀行のデータを集約する必要がありました。口座情報や取引履歴などが含まれるため、通常は外部に出せない情報です。 DeepProtectでは、各銀行内で学習したモデルの勾配情報のみを暗号化し、中央サーバへアップロードします。中央サーバでは集約された勾配情報を、準同型暗号によって暗号化されたまま統合し、集約された勾配情報として更新をします。 各銀行では、この更新された学習モデルをダウンロードして、それぞれの学習モデルをまた更新します。このサイクルを繰り返すことで、精度の高い学習モデルが共同で構築できます。1つの銀行のデータだけではなく、複数の銀行のデータによる連合学習モデルを構築することで、より精度の高い不正取引検知ができるというわけです。 DeepProtectの実例として、金融機関の不正取引検知での概念図。それぞれの銀行の学習モデルの差分パラメータのみを暗号化、中央サーバにアップロードし、集約した差分パラメータを使って学習モデルを更新 実データ自体は外部に送信されず、あくまで差分パラメータという勾配情報のみが、しかも暗号化されたまま処理されるため、データの機密性やプライバシーが確保されているというのがメリットです。 実証実験の結果は、各銀行での被害取引の検知率で比較されています。1つの銀行のデータだけを用いた個別学習モデルと、DeepProtectの連合学習モデルを使った検知精度の比較では、検知率が個別の84％に対して85.3％と、1.3ポイントの向上が見られました。個別学習モデルでは検知できなかった不正取引が検知された事例も確認されました。 実証実験での結果。連合学習モデルの方が高い結果を得られました 銀行における不正取引の被害額は、把握されているものだけで約300億円程度とみられており、1ポイントの向上で3億円程度の不正が防げるということになります。表に出ている被害額は氷山の一角とも言われていますので、実際はもっと被害額を減らせる効果があると考えられます。 実証実験で示されたDeepProtectの高いポテンシャル 不正取得された口座が振り込め詐欺などの金融犯罪に使われる、といった加害取引検知の実証実験では、個別学習モデル単独と、個別学習モデルと連合学習モデルを組み合わせたハイブリッドモデルで検証。加害取引が検知されるとその口座を凍結するのですが、その口座凍結が個別学習モデルと比べて20～50週程度、早く検知できていたそうです。検知率も個別学習モデルで78.9％が、ハイブリッドモデルだと94.7％で15.8ポイントの向上。実証実験によって、DeepProtectの高いポテンシャルが証明されました。 加害取引検知の実験では、ハイブリッドモデルで大幅な性能向上が確認されました 金融機関に対する攻撃は複雑化、巧妙化しています。マネーロンダリングや不正送金、振り込め詐欺などが相次ぐ中、単独のデータだけでは不正対策が間に合わなくなっています。複数の金融機関にまたがってデータの解析を行うことで、不正の検知率が向上すれば、犯罪を未然に防ぐ可能性が高まります。 そのほかにも様々な分野での応用が期待されます。例えば医療・ライフサイエンスの分野では、ウェアラブルデバイスの普及で計測できるバイタルデータが急拡大。電子カルテシステムなどの環境整備も進み、大量のデータが収集されています。こうした極めて機密性の高いデータでも、セキュアに複数の機関やデバイスをまたいだ統合分析が可能になり、医療やライフサイエンスの進歩に貢献できる、と伊藤は話します。 マーケティング分野では、単独企業だけでなくグループ企業や業界内を横断した豊富なデータをベースにした学習モデルを構築。詳細なインサイトやターゲットの発見といった精度の高い分析の実現が期待できる、としています。 製造現場でも貢献できそうです。IoTの導入が進んだ製造現場では、AIを使ったデータ分析も始まっています。これによって、設備などの故障予知、部品の品質管理、製品の異常検知などの分野で活用が期待されています。こうした分析には、1社、1工場のデータだけでは不十分なので、複数企業の工場データを活用できるDeepProtectが「課題解決を支援します」と伊藤は言います。 サービスの分野にも応用できます。電力やガスなどの公益サービスでの需給バランスの最適化、自動翻訳、スパムメールの検出、カスタマーサービスのチャットボット、バーチャルアシスタントサービス、自律走行を制御する車両運行システムなど、伊藤は様々なサービスでの利用を例に挙げ、広く活用が期待できるとアピールします。 さいごに もともと今回の技術「DeepProtect」は、発明した情報通信研究機構（NICT）から技術移転された（ニュースリリース：https://www.nict.go.jp/press/2022/03/17-1.html）もので、サイバーセキュリティや暗号技術、機械学習に関して高い技術力を持つことからイエラエ社が移転先として選ばれました。社会実証やビジネス化を進めていますが、伊藤は、幅広い分野の多くの課題を解決できる可能性がある技術として、「今後に是非とも期待して欲しい」と締めくくりました。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=kx7V6_jNU7U

GMOインターネットグループは、事業の成長を加速させるため、マイクロサービス化の道を選択しました。しかし、そこにはさまざまな困難が待ち受けています。 ただ漫然とシステムを切り刻んだだけでは、思い描いた未来にはたどり着けません。GMOインターネットグループ株式会社 成瀬 允宣は、12月6日（火）～7日（水）に渋谷フクラスおよびオンラインにて開催されたテックカンファレンス「GMO Developers Day 2022」のスピーカーセッションで、開発者がその力を最大限発揮できる環境を目指してソフトウェア設計面から取っているアプローチについて紹介しました。 登壇者 成瀬 允宣　 GMOインターネットグループ株式会社テックリード／デベロッパーエバンジェリスト 開発生産性向上を目指し、マイクロサービス化を決断 事業が成長し、システムが肥大化すればするほど開発生産性は落ちていきます。マイクロサービス化を決断した背景には、開発生産性を150%アップしたいという目標がありました。 生産性向上にあたって課題となっていたのは、まず共通データベースの存在です。データベースを複数のサービスで共有していたため、システムの拡大につれて深刻な依存関係が生じていました。また、複雑怪奇なシステムにより一子相伝になりやすいのも課題で、成瀬によると「当時、自分が所属していたチームのバックエンドチームでも、一人前になるまでに3年掛かるという話をしていた」ほどだったといいます。さらに、各システムで機能が重複しているうえに、それぞれに微妙な違いが生まれているような状況で、統制がとれていないという課題もありました。 マイクロサービス化への道筋は、ソフトウェアから「越境」をデザインすること システムアーキテクチャを考えるにあたっては「システムを設計する組織は、自らのコミュニケーション構造を真似た設計を生み出すよう制約される」というコンウェイの法則が知られています。たとえば、アプリ開発チームとインフラチームのあいだに壁があると、チームごとに個別の設計を反映してしまう弊害が出てきやすくなります。マイクロサービス化にあたっては、この法則を逆手に取り、チームと組織構造を進化させて望ましいアーキテクチャへと導く「逆コンウェイの戦略」が有効となります。 ただし、これはあくまで前提であり、チームを単に分割しただけでは、リファクタリングのための作業時間が捻出できない上に、主導者が不在となり調査・改修のためにチーム横断のコミュニケーションが発生するなど、円滑に開発を進めていくことが困難となってしまいます。そこで、こうした課題を運用でカバーするのではなくエンジニアリングで解決するという方針を取ることにしました。 ソフトウェア開発の現場にある不必要な壁を取り払うことでイメージされやすいのがDevOpsではないでしょうか。しかしマイクロサービス化においてDevOpsのように開発と運用チームを安易に越境させてしまうと、共通データベース問題が起きてしまいます。マイクロサービスアーキテクチャを選んでいながらもサービスが密結合している分散モノリス状態となり「モノリスのデメリットとマイクロサービスのデメリットを併せ持つ最悪のパターンになってしまう」（成瀬）ため注意が必要です。 「“水の低きに就く如し”という言葉があるように、人は楽な方に流れてしまうので、安易な越境を防ぐためには、望ましいやり方が最も安易であるようにすることが求められる」と成瀬。講演タイトルにある「越境のデザイン」とは、これをソフトウェアからアプローチしようという発想に基づいているといいます。 サービス/チーム境界を越境するAPI モノリスで構築している段階では共有データベースは有利となりますが、データベースを共有するとデータストアを経由してサービスを超えた依存関係が生まれてしまうため、中長期的には不利になります。この対策として一般的にはAPIの利用が有効とされています。GMOインターネットグループでは、チーム間の連携のほとんどにHTTP APIを利用していました。ただ、チーム内ではさまざまなデータベースを共有している状況にあるため、複雑な依存関係がありました。そこで、HTTPによるコマンド受付を行いメッセージブローカーを使うようにすることで共有データベースを廃止することを目指しました。 メッセージブローカーを利用することのメリットは、耐障害性の高さです。サービス同士をRPCでつないでしまうと、あるサービスが落ちたときにそれを呼び出しているサービスも落ちるという形で、他のサービスにまで影響が及んでしまいます。一方、メッセージブローカーを用いた場合、障害発生時にメッセージブローカーが稼働していれば、そこにメッセージを貯めて復旧した際にメッセージを消費する流れになり、他サービスへの影響を防ぐことができます。 システムにおける過去・現在・未来の時間軸を越境するイベントソーシング 次に問題となるのは、どのようなメッセージを送るかということです。メッセージは、指示を表す「コマンド」と「クエリ」、そこで起きた事象を表す「イベント」の3種に分けられます。そして、イベントを送る際にポイントとなるのが、イベントソーシングです。イベントソーシングとは、データの現在の状態を格納する代わりに、実行されたアクションを記録するというGitのような考え方です。 イベントは、イベントジャーナルに保存され、Relayでメッセージブローカーに渡されます。これが実現できると、開発面で大きなメリットがあります。既存サービスの情報をもとに新しいサービスを作りたい場合、過去のデータであればすべての履歴がイベントジャーナルに保存されているので、既存サービスを修正しなくてもよい可能性が高まります。また、予測不可能な未来への対策を行うこともできるようになります。 組織上のメリットもあります。多数のサービスが使っているサービスの担当チームに修正・機能追加の要望が集まると、チームが疲弊しリードタイムの低下につながるおそれがありますが、メッセージブローカーにイベントが送出されていれば、他のチームが「勝手に使っている」状況が生まれ、他サービスのための作業を減らすことができるようになります。 個人間・チーム間の知識を越境するイベントストーミング メンバーが退職してしまうと、開発力が低下するだけでなく、ドメイン知識などソフトウェア化対象の周辺知識や属人化した知識が継承されないという問題が発生しがちです。こうした知識を共有する方法として、コードのコメントがありますが、システム横断の知識が記述できないほか、記述箇所を探すのが難しかったり、メンテナンスされなかったりという課題があります。ドキュメントを作成する方法もありますが、ビジネス最前線では仕様が変化しやすく、メンテナンスの難しさが難点となります。そこで有効となる手法が、イベントストーミングです。イベントストーミングは、ワークショップ形式のモデリング手法であり、ブレインストーミングのイベント版のようなものといえます。参加者はイベントを思いつく限り付箋へ記入し時系列に並べ、ルールに従って必要な付箋を追加していきます。そして、出揃ったものに対してチームで納得のいく命名をして、コンテキストで分割していきます。コードを用いないため開発職ではない人も参加できることが特徴で、成瀬は「仕様に詳しいビジネス職の人を招いてワークショップを行うと知識がマージされていく」とそのメリットを語ります。イベントストーミングを行うと、個人の知識がチームの知識として昇華されていくため、メンバーの退職に慌てないで済むほか、新しいメンバーも知識をキャッチアップしやすくなります。さらに、サービス同士の連携箇所が可視化されるので、改修時の影響範囲も明確になります。 成瀬は「イベントソーシングとイベントストーミングの相性は最高」だといいます。イベントソーシングを採用していると、イベントストーミングによって作成された図に従ってそのままコードに落とし込むことができるためです。 サービス運営負荷と責任を越境するコンシューマ駆動契約テスト システムは有益であればあるほどさまざまなサービスに使われるため、何か障害が起こった際には各方面から一手に苦情を受けることになります。さらに、こうしてサービスの供給者（プロバイダ）に責任を持たせてしまうと、依存関係の調査・タスクなどに掛かるコストが増大し、リードタイムの低下につながるおそれがあります。 成瀬によると、コンシューマ駆動契約テストでこうした課題を解決できるといいます。コンシューマ駆動契約テストは、「皆が使っているのなら皆でメンテナンスしよう」という考え方に基づき、サービスの利用者（コンシューマ）がプロバイダに向けてテストを提供するという手法です。 役割・チーム間を越境する組織設計 マイクロサービス化に向けたこうした知見があったとしても、実際のところ開発チームは多忙であり、新たなスキルを獲得するような時間がないという樵のジレンマに陥るケースは多くあります。成瀬も「兼務の技術研究チームで試したところ、本業を優先するために進まなかった。チーム対象にワークショップを実施してみたが、これを継続しようとすると自分と同じ役割の人が何人も必要になる」と苦戦したことを明かします。 ここで必要になるのがチームトポロジーという考え方です。チームトポロジーでは、「ストリームアラインドチーム」「イネイブリングチーム」「プラットフォームチーム」「コンプリケイテッドサブシステムチーム」という4つの基本的なタイプにチームを整理します。そのうえで、各チームは「コラボレーション」（チームとチームが密接に協力して作業すること）、「X as a Service」（最小限のコラボレーションで利用または提供すること）、「ファシリテーション」（障害を取り除くために他チームを支援したりされたりすること）という3つのインタラクションモードを活用します。 これを成瀬が以前行っていた業務に照らし合わせると、下記のように分けられるといいます。 サービス開発 → ストリームアラインドチームマイクロサービス化の支援 → イネイブリングチームクラウド等の利用方法策定 → プラットフォームチームチーム横断のモジュール開発やアーキテクチャ策定 → コンプリケイテッドサブシステムチーム こうしてチームの役割を整理し、チーム同士がどのように関わるかを宣言してインタラクションモードを使い分けることによって、チーム間の諍いを減らすことができるようになります。 GMOインターネットグループは、まさにこの取り組みを進めているところです。成瀬は、「マイクロサービス化をさせるにはファシリテーションを行えるメンバーの増強が不可欠。チームトポロジーの考え方で状況を整理してイネイブリングタイプのチーム組成を上申したところ、上長の後押しもあって実現できた。これにより、組織的なマイクロサービスを推進でき、各チーム内にも手練れが増えてきた」と現状について紹介。そして「ソフトウェア設計は人の心の動きを考えることから始まる。“水の低きに就く如し”を念頭に置いて、越境をデザインしていくことが大切。GMOインターネットグループも、まだ道半ばだが上手くいくようになってきている」と語り、講演を締めくくりました。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/dChUhH9MMm0

暗号通貨取引所「GMOコイン」、NFTマーケットプレイス「Adam by GMO」、オリジナルグッズ作成・販売サービス「SUZURI by GMOペパボ」におけるNFT連携機能——GMOインターネットグループ各社は、プロダクトという形でブロックチェーン技術をビジネス実装し、その価値を世の中に届けています。 GMOインターネットグループが2022年12月6日（火）～7日（水）の2日間、渋谷フクラスおよびオンラインにて開催したテックカンファレンス「GMO Developers Day 2022」のKEYNOTEセッションでは、ブロックチェーンをはじめとした分散システムを研究する京都大学 首藤 一幸教授をゲストモデレーターに迎え、GMOインターネットグループ株式会社の佐藤 史彦、GMOペパボ株式会社の黒瀧 悠太とともに、ブロックチェーン技術をビジネス実装する意義や課題について議論しました。  登壇者 モデレーター 首藤 一幸京都大学学術情報メディアセンター 教授 スピーカー 佐藤 史彦GMOインターネットグループ株式会社グループ研究開発本部 次世代システム研究室 室長黒瀧 悠太GMOペパボ株式会社SUZURI事業部 シニアエンジニアリングリード  （左から）ゲストモデレーター首藤氏、GMOインターネットグループ 佐藤、GMOペパボ 黒瀧 Ethereumを中心としたプロダクト開発・実証実験 佐藤が所属する次世代システム研究室は、GMOインターネットグループの事業領域で、様々なプロジェクトの技術支援・開発・解析などを行い、ビジネスの成功を支援する部門。近年は、ブロックチェーン技術の研究に注力しています。2015年末頃から技術調査を開始し、2016年2月には、スマートフォンゲームアプリのバックエンドの仕組みにブロックチェーン技術を適用することを発表。これを皮切りにブロックチェーン技術を社会実装するための研究を本格化し同年12月には、ブロックチェーン上に分散型アプリケーションが構築できるEthereum採用のPaaS型ブロックチェーンプラットフォームのβ版を公開しました。 「当初はプライベートブロックチェーンのソフトウェアをベースにプラットフォームを提供しようとしていましたが、紆余曲折あり、ParityのEthereumクライアントを使ってパーミンションド・ブロックチェーンPaaSを構築することになりました」（佐藤）GMOインターネットグループはこのプラットフォームを利用して、認証を受けた本人のみが受取可能な宅配ボックスの実証実験をセブン情報システムズと共に実施。さらに、チケットの転売防止に応用する提案なども行ったといいますが、実際の利用に至るまでは進められず、現在サービス自体はクローズしている状況です。しかし佐藤は、「こうした活動によってEthereumを中心にブロックチェーン技術を検証してきた。 この経験は、その後に開発するプロダクトにもいきている」とします。 GMOインターネットグループが取り組んできたブロックチェーン技術の歩みを伝える、佐藤 佐藤は、暗号資産関連の取り組みとして、GMO Trustが発行するステーブルコイン「GYEN」についても紹介しました。GYENは、ニューヨーク州規制当局の認可を得た世界初の日本円ステーブルコイン。基盤はEthereumからスタートしましたが、現在はそれ以外の基盤への展開を進めているところです。GYENが取引所に上場した2021年3月当時は、NFTアートが盛り上がりを見せており、GMOインターネットグループもNFT事業に参入することを決定した時期でした。このとき、NFTに関するシステム開発を一手に引き受けたのが、次世代システム研究室でした。佐藤は「いかに早く盛り上がっているタイミングでプロダクトをリリースするかが重要だった。我々のEthereum技術をいかし、4か月という短期間で『Adam by GMO』を立ち上げた」と説明します。「ブロックチェーン・ネイティブの領域を押さえるだけではなく、これまでのEC体験と同じように、一般の方でも日本円/クレジットカードで購入できるといった使い勝手を同時に実現しなければなりませんでした。これが難しく、かなり悩んだところです。試行錯誤を経て、なるべく使い勝手を優先する形で、オフチェーン処理にウェイトを寄せた設計で開発を進めました」（佐藤） SUZURIにおけるブロックチェーン活用の取り組み 黒瀧は、オリジナルグッズを誰でも作って販売できるサービス「SUZURI byGMOペパボ」の技術責任者という立場で現在、開発に携わっています。2017-18年頃には、「SUZURI People」というクリエイター支援に向けた月額制コミュニティーサービスを運用していました（現在は閉鎖）。実はもともとSUZURI People立ち上げの裏には、2016年頃からのICOブームを受け、ブロックチェーンを使ってクリエイターがトークンを発行し、ファンがそれを買うことでクリエイターを応援できるプラットフォームをつくるという構想があったといいます。 「SUZURI People」立ち上げを振り返る、黒瀧 「当時、社内のエンジニア2-3人でとりあえず本屋に行ってブロックチェーン関連の書籍を複数購入。これを読みながら、個々人がまず自分でICOをして、社内でトークンを配るという一連の流れを社内でやってみました。その後に、DEX（分散型取引所）におけるBancor Protocol（流動性を担保するための価格変動アルゴリズム）を社内でつくり、クリエイターさんに実証実験へ参加してもらいました。いろいろあってリリースができないという判断になり、SUZURI Peopleのような形で運用することになりましたが、こうした裏側があったのです」（黒瀧） しかし、ブロックチェーン技術をプロダクトに実装する取り組みは続いています。2022年5月にGMOペパボは、SUZURIの一機能として、NFTコンテンツからオリジナルグッズを作成できる機能をリリースしました。この機能は、ユーザーがブロックチェーンウォレットであるMetaMaskの情報と連携させることで、ウォレットのアドレスに紐づくNFTの画像を利用してSUZURI上でアイテムの作成ができるようになるというものです。今後は、クリエイター向けの機能としてだけではなく、「NFTの保有者で、かつ、NFTコンテンツの商用利用許諾を受けた方」も、より適切な形でオリジナルグッズを作成・販売できるような仕組みを整えていく予定です。 ブロックチェーン技術が社会に浸透するために必要なこと セッションでは、こうしたブロックチェーン技術に関するGMOインターネットグループ各社の取り組みを踏まえて、3名によるパネルディスカッションが行われました。以下ではその様子の一部をご紹介します。 首藤これまでの取り組みをはじめたきっかけや、その後どのような壁や困難にぶつかったか、それをどう乗り越えたのか、お話しいただきたいと思います。 皆さんに使ってもらえるように、いかに使いやすくするかというところが一番の課題でした。ブロックチェーンをはじめとするこの世界は、分散型、非中央集権的なムーブメントがあります。使いやすさと分散型のあいだにあるギャップを埋めることは、非常に難しいです。たとえば、セルフカストディ型のウォレットは、一般の方にとっては使いにくく、なかなか手を出しにくい。Adamの開発時には特に大きな問題になりましたね。佐藤 首藤MetaMaskにウォレット管理が集中してしまうことには、私からすると残念感があります。ただ、MetaMaskですら皆さんに使ってもらうのが難しいということもわかります。誰をターゲットにするのか、どの視点で見るのかによって、やらなきゃいけないことは変わってくると強く感じました。さらにコンシューマー寄りの仕事をされている黒瀧さんから見て、いかがでしょうか。 これからブロックチェーン技術がさまざまなところに浸透していくための鍵のひとつは、キラーアプリだと考えています。ウォレットのアプリとしてはMetaMaskがありますが、ウォレット以外のアプリもどんどん浸透していくことを期待しています。あとはFat Protocolという話もあるように、パーミッションレスで使えるプロトコルが今後増えていくことで、それに伴い開発者が増えていくこともポイントだと思っています。プロトコルレイヤーと、アプリケーションレイヤー両方の可能性がもっと広がっていくと良いですね。黒瀧 首藤それが商売にならないと発展しないという難しさもありますよね。 今ではWeb3関連のスタートアップも出てきていて、ITの世界に入るきっかけがWeb3だという若い人も多いと思います。一方で、Webアプリーケーションを10年くらい勉強してつくってきた私のような世代の人たちも、ブロックチェーンで何ができるのか、各業界でどうやってビジネスにしていくか考えているところだと思うので、世代ごとの知見をいかしてこれからさまざまなものが出てくることを楽しみにしています。黒瀧 首藤京大や東工大の学生にもブロックチェーン関連のプロジェクトにコミットしている人がけっこういますし、GMOのCVCであるGMO Web3のミーティングに参加していると、20代前半の人たちが、驚くほど新しいことを考えている様子を目の当たりにします。 Web3やブロックチェーン系のハッカソンに何回か参加したことがあるのですが、10代後半から20代前半の大学生・高校生の参加者が多かったです。懇親会で話してみたところ、自分が思っているよりもずっと真剣に未来のことを考えている方が多いと感じました。黒瀧 私の部署ではブロックチェーンをテーマにしたインターンシップをやってますが、熱量の高い学生が全国から集まってきています。若い人への期待感は感じますね。佐藤 インターネット技術黎明期との相違 セッションも終盤に差し掛かったなかで、会場参加者から3人に質問が寄せられました。 会場からも質問が寄せられて、議論が深まりました ブロックチェーン技術は、インターネット技術と比較されることがあります。今、ブロックチェーンは黎明期といわれていますが、インターネット技術黎明期と比べて、相違点や似ている点はありますか。 首藤私は研究業界にいるためかなり基礎的なことから考えてしまいますが、たとえばビットコインやEthereumは、何かすると世界中に影響が及んでしまうので、自分の範囲で局所的に実験をすることが困難です。昔のインターネットに比べて冒険しにくい構造があるように思っています。 インターネット黎明期は、オープンソースが今ほど一般的ではありませんでした。しかし、今ではソースコードがオープンなものも増えていますし、ブロックチェーンの場合は、そもそもプログラムや仕組みだけでなく、実際に流れているデータから世界でどういうことが起こっているのか、外から見えやすい環境にあります。もちろん技術を習得する必要はありますが、やる気があればなんでもやってみれるという点は、当時とは少し違うように感じています。佐藤 一方で、セキュリティの基準が最近すごく高まっていると感じています。当初はWebアプリーケーションのフレームワークも使わずに書いたものをとりあえず動かしている状態で、攻撃されてもあまり大きな問題にならないような状況だったと思いますが、攻撃者がさまざまなWebサービスを攻撃するようになってきたことで、Webサービスをつくる際にはWebアプリケーションのフレームワークを使って、意識して守るところは最小限に押さえ、堅くつくるというやり方が主流になってきました。そして、Web3は、攻撃されたときの金銭的な損失が今までのWebサービスと比べてより大きくなります。守りを意識して慎重に開発を進めなければ痛い目を見るので、セキュリティ的な観点ではハードルは高くなっているように思っています。黒瀧 首藤Web3の鬼門は、価値がネットワークに載るという点にありますね。その価値を守る必要性が高まったというところだと思います。 最後に、参加者から寄せられた「ブロックチェーン関連のスタートアップに対して、GMOとしてどのようなことを期待しているか」という質問に対して、佐藤は「我々の価値観や観点とは異なる部分。それをもとにどのような未来をつくっていくかという期待感を見せていただけることを期待している」、黒瀧は「これまで取り組んでこなかった企業が急にブロックチェーンでビジネスをやろうとしても、さまざまな理由から方向転換しづらい面がある。スタートアップには、ゼロから始められるという強みがある。スタートアップの方々には、長い将来を見据えたうえでさまざまな分野での応用事例をつくっていただき、スタートアップ同士や、歴史の長い企業とのコラボレーションが進んでいくとよい」とそれぞれコメントし、本セッションを締めくくりました。 Web3のムーブメントが拡大し、注目の集まるブロックチェーン技術。さまざまな業界や世代のプレイヤーが参入し、今後さらに盛り上がっていくことを期待したいです。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/-HuH_4HCMA4

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューション部の梅崎です今回はローカル5G案件でfree5GCを物理サーバー上で動かしどれだけのトラフィックをさばけるのか試しました free5GCを試してみた -Vol.01 https://developers.gmo.jp/23934/#%E6%AC%A1%E5%9B%9E 構成 free5GC の全コンポーネントを入れた物理サーバー(10Gbps接続✕2)を一台UERANSIM の UE & gNB 相乗りの VM を5台ずつ、3台の物理サーバー(10Gbps接続)へMEC見立ての物理サーバー(iperfの対向役)を一台 主に使ったもの 5Gコア free5GC この時点のものリンク１リンク２5Gアンテナ/端末シミュレーター UERANSIM v3.2.6リンク OS Ubuntu 22.04.1 LTSトラフィック生成ツール iperf version 2.1.5free5GC 側のサーバーCPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GBUERANSIM 側の物理サーバーCPU: Intel(R) Xeon(R) CPU E5-2670 v3 × 2ソケット（計24コア/48スレッド） メモリー: 128GBorCPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GBUERANSIM の VMCPU: 8個メモリー: 1GBMEC見立ての物理サーバー CPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GB トラフィック印加試験 1台のVMのみ # MECへUEごとにのトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbpsのときは問題ないですが 600Mbpsのときはそもそも、UERANSIMのVMからパケットが500Mbps前後しか出ない状態でした色々試したところ400Mbpsのトラフィック一本ならパケロス等も無いようで今回の構成のUE一台ごとの上限は400Mbpsのようです 15台のVM(UDP) # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbpsを15台分は特に問題なく 100Mbps * 2本が15台分は一瞬3Gbpsになるもののすぐにセッションが切断されてしまいました 15台のVM(TCP) 次にTCPでも同様なことを試してみました # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 300M -c ${受け側のIP} -P 2 #受け側 iperf -s -i 1 UDPをTCPにするとアップロード側が合計で最大7Gbps程度になり正直TCPよりUDPの方がスピードが出そうだと思っていたのですがTCPの方が圧倒的に多くのトラフィックを捌けていて驚いています…… 15台のVM(UDP、チューニングをしてみる) ちょっとTCP側と違いあまりチューニング方法が出てこなかったのですが一つそれらしいコマンドを見つけたので試そうと思います # UDPはソケットバッファを増やすとパフォーマンスが良くなるとのこと sysctl -w net.core.rmem_max=4194304 sysctl -w net.core.wmem_max=4194304 # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbps*2を15台の動作はあまり変わらないという結果でした ここで気がついたのですが合計トラフィックが3Gbpsを超えたところでパケットがMEC役のサーバーへ届かなくなり その後、しばらくしfree5GCのサーバーへ来るトラフィックが3Gbpsを割り始めるとパケットがMEC役のサーバーへ到達するようになりました 15台のVM(TCP、 UL/DL双方向) ちょっとUDPは挙動が怪しいですが、これ以上はチューニングを頑張らないとならなさそうなので一旦TCPの方を試していきます ここまではUEからみてUL方向のトラフィックのみだったので今度はTCPUL/DL双方向にしたところ # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 500M -c ${受け側のIP} -d #受け側 iperf -s -i 1 ULが4.5Gbpsほど、DLが3.5Gbpsほどになりましたただ、ULのみのときと同じく数分放置しているとセッションが切れてしまうUEが数台出てくる状態です 15台のVM(TCP、DL方向) 次にUEからみてDL方向のトラフィックをテストしてみます # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 500M -c ${受け側のIP} -r #受け側 iperf -s -i 1 DL方向のトラフィックも7Gbps程度はでるようでしたこちらも数分放置しているとセッションが切れてしまうUEが数台出ていました 15台のVM(TCP、UL方向、7Gbps以下) 最後に今までの上限トラフィックより少ないトラフィックだとUEのセッションが切れないようになってくれるか試してみます # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 400M -c ${受け側のIP} #受け側 iperf -s -i 1 最初は問題なく400Mbps*15台の6Gbpsほどを処理できています ただ、こちらも一時間放置したところいくつかのUEのセッションが切れてping届かなくなっていました まとめ free5GCを物理サーバー上に構築したところ今回のサーバースペックだとTCPがUL/DL合計7～8Gbps程度、UDPがULで3Gbps程度出るようですがトラフィックを流し続けているとUEのセッションが不安定になってしまうという結果でした ただし、この不安定さの原因がUERANSIM側なのかfree5GC側なのか、はたまた相性の問題なのかが不明なので今後はUE/coreの別実装でもテストする必要があるかなと思います 最後に 安定性はさておくと現状のローカル5G環境として利用する分には捌けるトラフィックは十分かなと感じています 次回は実際のRANをfree5GCにつなげてみて安定性等々を試していこうかと思います

こんにちは。GMOインターネットグループ株式会社 フロントエンドエンジニアの山名です。この度、弊社の新卒採用サイトのフルリニューアルを担当させていただいたので、その際に新卒なりに意識したことなどをご紹介していきます！ 執筆の背景 冒頭でも少し触れましたが、この度GMOインターネットグループ株式会社の新卒採用サイトをフルリニューアルするとのことで、企画から公開までフロントエンドとしてプロジェクトに参画させていただきました。 自分が配属されてから約3ヶ月、案件としてサイトの構築から担当するのは初めてだったこともあり、何もかも手探りの状態で制作を進めました。 そんな中でも、「ここはこうしよう」「これはこっちの方がいいはず」と自分の知識を総動員しつつサイト構築を行っていたのですが、今思えば結構大事なことを考えていたのかもしれないなぁと思っています。 ということで今回は、新しくなった新卒採用サイトの告知がてら新卒一年目がサイト構築で意識したあれこれをご紹介していこうと思います！ サイト構築で特に意識したこと4選 ここからはサイト構築で特に意識したことを4つご紹介していきます！ 1.チーム内のルールから逸脱しすぎない やって当然と言われそうですが、なんならここが一番大変だった気がします。 今までの個人制作では、厳密なルールなどは決めずに好きに作っていましたし、入社後担当していた商材の保守案件では元々チーム内のルールに沿って作られたものを編集するだけなことが多かったため、いざ1から作るとなるとどうしても自分の手癖が出てしまって苦労しました。 ある程度好きに作ってもいいよとは言われていたのですが、クラスや変数の命名規則、基本的なディレクトリ構成に関しては、今後の保守に関わってくる部分なのでコーディングをする際にはこういった部内ルールを守るようにしていました。 また、GMOインターネットグループ株式会社のサイトとして公開される以上、グループ共通のヘッダーやロゴの扱いに関しても厳しいルールがあるため、そういったことも含めて構築するサイトがチーム内のルールから逸脱しすぎないように意識していました。 // 例 // クラス名はBEMで書く // JavaSvcriptで制御するものには接頭辞に「js-」をつける <section class="mainvisual"> 　　<div class="mainvisual_movie"> 　　　　<video src="◯◯"></video> 　　</div> 　　<button class="mainvisual_movie_play js-movie_play">PLAY</button> </div> 2.誰が見ても分かるコード やって当然（2回目）です。それでもやっぱり難しいのですが... ”誰が見ても分かるコードを書く” ということに関しては、サイト構築の際だけじゃなく常日頃から気をつけていることになるのですが、やっぱり後々誰が触るかわからない以上自分だけがわかるコードじゃダメだと思っています。 そんな中で今回のサイト構築、自分1人で作っていくため誰が見てもわかるようなコードなのか判断が難しく、処理を書いては見返したり、クラス名や変数名がしっかりそのものを表しているか確認したり、モジュールは適切に分けられているか確認したり... とにかく一度自分が書いたコードを何度も確認することで、なんとか分かりやすいコードを目指しました。実際できているかは分かりませんがなんとか自分の癖は薄められたんじゃないかなと思います。笑 // 例 // モーダルウィンドウ表示部分の一部処理 // 変数の中身と処理の内容がわかりやすい（はず） const $movie_play = document.getElementsByClassName('js-movie_play'); const $modal = document.querySelector('.js-modal'); const $modal_movie = document.querySelector('.js-modal_movie'); const $modal_close = document.querySelector('.js-modal_close'); const $modal_back = document.querySelector('.js-modal_back'); for (let i = 0; i < $movie_play.length; i++) { $movie_play[i].addEventListener('click', () => { 　　　　const src = $movie_play[i].getAttribute('value'); 　　　　$modal_movie.setAttribute('src', src); 　　　　$modal.classList.add('is-active'); 　　　　$modal_back.classList.add('is-active'); }); 　・・・　 } 3.デザイナーとの連携 次にデザイナーさんとの連携です。 新卒採用サイトのリニューアルにあたり、同期のWebデザイナーがサイトデザインを担当していたのですが、コンセプトが「枠組みを壊せ」なだけあってダイナミックでおしゃれなデザインを作ってくれていて、それに合わせてアニメーションの提案やデザインの調整等の連携を積極的に行っていました。 分からないことや確認したいことも含めて些細なことをこまめに共有し合うことで、生産効率がかなり向上していたように思います！ 4.自分らしさを出す このままでは部内ルールに沿って、もらったデザインをコーディングしているだけなんですが、やっぱり自分らしさは少し出したい！といことで、企画から公開までの流れでちょくちょく自分なりに提案をさせてもらっていました。 結果的には、前述したアニメーションの提案やSEO対策、サイトの軽量化や運用に関わる部分で自分なりに考えた構築ができた気がします。 こうして自分らしさを少しずつ出しながら進めていくことで、終始楽しみつつモチベーション保って制作ができていたので、改めて大事なことだなぁとしみじみ感じました。 終わりに いかがでしたでしょうか。 分からないことだらけのサイト構築で、デザイナーや先輩方に助けていただきながらではありますが中々のものができたんじゃないかなーと思ったりしています。 実際にリニューアルしたサイトはこちらになります。 気になる方は是非見てみてください！ また、GMOインターネットグループ株式会社では、現在「次世代リーダー」を募集しております。 詳しくは上記サイトからご確認いただき、是非エントリーしてみてください！

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。初回は、初日KEYNOTEを飾った『CTO対談～技術責任者会議～』の模様をお届けします。 登壇者 スピーカー 三谷 隆GMOペイメントゲートウェイ株式会社 専務執行役員CTO 安藤 健一郎GMOリサーチ株式会社 取締役CTO 栗林 健太郎GMOペパボ株式会社 取締役CTO  モデレーター 稲守 貴久GMOインターネットグループ株式会社　グループ研究開発本部 マネージャー GMOペイメントゲートウェイ 三谷 GMOリサーチ 安藤  GMOペパボ 栗林GMOインターネットグループ 稲守 2022年、グループ各社CTOが集う技術責任者会議が発足  GMOインターネットグループにはインターネットインフラ事業をはじめとして広告・メディア・金融・暗号資産と様々な事業会社・開発組織があります。  これらの技術力を強化し、グループシナジーの最大化を図るため、今春から開発者の最高意思決定機関として「技術責任者会議」が組成され、グループ各社CTOは、毎週1回程度の頻度でミーティングを行っています。  このセッションでは、GMOインターネットグループから、GMOペイメントゲートウェイ株式会社の三谷 隆、GMOリサーチ株式会社の安藤 健一郎、GMOペパボ株式会社の栗林 健太郎と、この技術責任者会議のボードメンバーである3人のCTOが登壇して、GMOインターネットグループの開発体制における現状から、これからの展望について議論を交わしました。  モデレーターはGMOインターネットグループ株式会社（以下GMOインターネットグループとする）で、グループ研究開発本部 マネージャーを務める稲守 貴久が担いました。  それぞれのCTOは技術責任者会議が発足してから、どのように感じているか。参加者が同じCTOという立場のため、「自分一人の悩みが話せるようになった」と言うのは三谷。安藤も「横の繋がりが作りやすくなった」と歓迎します。  栗林は、「GMOインターネットグループは100社ぐらいあって、色んな会社に凄い技術者がいるが、それが知られていない」と話し、横連携ができるようになったことで、そうした社内の「ヤバいエンジニアをもっと広めたい」と言います。  各社それぞれの違いから議論が深まる そんな交流を深めているCTO同士の対談は、「質問1000本ノック」（実際に1000問あったわけではありません）からスタート。「山と海なら海派である」というライトなものから、「現在、開発組織で課題がある」といった会社組織にまつわるもの、「マネジメントよりコードを書いている方が好きだ」というCTOらしい質問に次々と回答していきました。  質問1000本ノックに次々と回答する3人  その中で、「開発組織で課題がある」という質問には3人がいずれも「○」と回答。詳しく話を聞いてみると、実は全員が同じ「人材採用」に課題を感じていました。3人とも「やりたいこととは山ほどある」と異口同音に語りつつ、人が足りなくても採用や評価が難しいという意見で一致しました。  ただ、「CTOの最大の仕事は技術者採用だ」との質問には全員が「×」。栗林は「採用はかなり大きな仕事」としつつ、外部に対して自社の技術的な方向性、能力、サービスの方向付けをすることが重要だと指摘。「テクノロジーによるカルチャーを体現し、それを作り上げていくのが重要な仕事」と話します。  安藤は、「一緒に働いている人が幸せになって欲しいし、楽しく働いて欲しい」と話しつつ、「転職するのもありだし、そういうときにその人の市場価値が高まるような状態になるように、お互い切磋琢磨して向上できるような環境にしていきたい」としています。  採用面の質問では、CTOの面々は「スペシャリスト」よりも「ゼネラリスト」を採用したいと回答していました。三谷は、「決済をずっとやっていたスペシャルの人が欲しいというのはありますが、なかなかそういう人はいない」とスペシャリストの少なさを指摘しますが、そもそもGMO-PGには多くの決済系システムが稼働しており、エンジニアも揃っています。そのため、システムやコードが「先生」となって学ぶことができるので、ある程度のコードを触った経験があって、それが好きで、「チャレンジしたい強い思いがある人であればいい」と言います。  安藤は、特定のシーンでスペシャリストが欲しいという状況はあるといいますが、必要な技術、人物像がその時どきで少しずつ異なるため、「いろいろやりたいという人の方が結果的にいい」と指摘します。  栗林は、「スペシャリストは"どれだけ深掘りできるか"というのに対して、ゼネラリストは"どれだけ横に広げられるか"」と話し、スペシャリストが専門性を深掘りするのと同様に、ゼネラリストは幅を広げることを求めます。「技術を極めたり、影響力を広めたり、できることを増やしたり、そういうマインドを持って欲しい」というのが栗林の考えです。  「Web3はこれからインターネットの主流になる」という問いに対しては、三谷と栗林が「×」と回答。栗林は、「色々なWebが並列するのでは」という意見。Web3のキーワードとして「分権化」があり、それだけでは主流にはならず、Web2的、Web3的と言った形で並列するという考え方です。  3人並んだCTOは、それぞれB2BのGMO-PGとGMOリサーチ、B2CのGMOペパボと立ち位置が異なります。そうした各社の違いについて問われた三谷は、「決済の裏側のB2Bの仕事が多いので、堅い面も半分ぐらいはある」としつつ、全てを「堅く」してしまうとコストがかさんでしまうため、内製化によって「省力化できるところは省力化して、それ以外はきちんとやって、メリハリを付けている」というのがカラーだといいます。  GMOペパボは、コンシューマ、小規模事業者向けですが、レンタルサーバーなどインフラやプラットフォームに近い業務のため、「そんなに派手なところがあるわけではない」と栗林。とはいえ、「僕もインターネットが好きでこの業界に入っていますし、インターネットが好き、プログラミングが好き、自身もクリエーターという人が（社員には）多いので、和気あいあいと好きなことをみんなで楽しみながらやっている」というのがカラーなのだといいます。  各社それぞれの違いから議論を交わす3人  さいごに 最後に参加者への一言を求められた3人。三谷は、エンジニアが成長するための3つコツとして、まず「厳しい非機能要件のプロジェクトなどに携わること」を挙げます。システムのデザインは、非機能要件が厳しいほど難しくなるので、そこにチャレンジすることで成長してほしいといいます。  2つ目のコツとして、「成長している市場や業界、将来性のある会社に身を置いてほしい」と（三谷）。こういったところは変化が激しいので、何をすべきか、将来を見越してどうシステムなどを作るか、といったデザインが非常に重要になるためだそうです。  3つ目はサービスやシステム、プロジェクトを担当する中で、「単に自分の担当領域だけに閉じこもるのではなく、全体に興味を持って知ろうとすることを心がけてほしい」と言います。書籍で学ぶだけでなく、自身が関わっているプロジェクトやサービスなどで担当以外に興味を持てば、周囲にはその道のプロがいるので、聞いて、吸収して次に生かせるようになって成長していってほしい、というのが三谷の考えです。  安藤は、日本CTO協会の理事に栗林が参加していることから、参加者や視聴者にCTOが居れば加入して一緒に話したいとコメント。栗林は、GMOインターネットグループの技術力、事業内容の面白さを「知ってほしい」と強調。100社以上というグループ企業には、「どこかに刺さる企業があるはず」と栗林は話し、エンジニアにとって楽しめたり成長できたりする場がどこかにあるとして、GMOインターネットグループにチャレンジしてほしいとアピールしていました。  アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=dF-GHc-YzLg&t=405s

こんにちは。GMOインターネットグループ株式会社 セキュリティエンジニアの赤瀬です。私は2021年に新卒入社し、現在はセキュリティチームでWebアプリケーションの脆弱性診断を行っています。まだ脆弱性診断を始めて2年目のひよっこエンジニアです。脆弱性の勉強＋知識の定着を兼ねて今回記事を執筆することになりましたので書いていきます。 はじめに 開発経験がある人でもない人でもエンジニアをやっている人が一度は聞いたことがあるであろうクロスサイトスクリプティング（以下、XSS）には大きくわけて反射型、蓄積型、DOM-Based XSSの3種類があります。簡単に上記3種類の説明を（ほんとにさらっとだけ） 反射型XSSユーザからのリクエストに含まれるスクリプトをそのままレスポンスに出力してしまい発動するXSS蓄積型XSSユーザが入力したスクリプトがWebアプリケーションに保存され、別のユーザがその保存箇所を読み込んだ際に保存されたスクリプトが発動するXSSDOM-Based XSSJavaScriptを使ってブラウザに表示しているHTMLを操作する場合に、攻撃者の用意した意図しないスクリプトが発動するXSS その中でも今回は、蓄積型XSSについて実際にWeb画面で挙動を紹介できればと思います！ 1.注意事項 検査により、意図せずにシステムの停止や不具合を引き起こしてしまう可能性があるため、紹介する手順を試してみたい場合は本番に影響を及ぼさない検証環境か、それ専用に作られたテストサイトでの作業をお勧めします。自組織が管理しないWebアプリケーションへの検査は、場合によっては不正アクセスとして違法となる可能性があります。 2.蓄積型XSS XSSとは、Webサイトに攻撃者がスクリプトを登録しておくことで、一般のユーザにそのコードを実行させること。攻撃例をあげると、Cookieの情報を抜き取ったりするなどがあります。今回紹介する蓄積型XSSというものは、攻撃者がWebサイトに直接スクリプトを登録し、そのWebサイトの一般利用者が該当のページを読み込むたびにそのスクリプトが実行されてしまうものです。 百聞は一見にしかずということで、実際にどういうのか見てみましょう。※今回は自分のローカル環境にECサイトっぽいものを作成して利用しています。※CSSなど凝ったものを作っていないのでサイトの見た目はご容赦ください。 ということで早速画像のような商品登録画面があるとします。今回は、商品登録を管理者ページでしかできないようなサイト仕様にしました。 普通の利用者が見る商品一覧ページはこんな感じです。最低限の実装って感じですね（自分で作ったんですけど）。 ということで、先程の管理者ページに何らかの方法で攻撃者がアクセスし商品登録できると仮定してスクリプトを仕込んでいきたいと思います。わかりやすいように下記のデータを商品として登録していきます。 商品名：スクリプト商品説明：’任意’ <script>alert(1);</script>価格：500円 無事登録することができました。本来、ここで<>のような記号が入力値にあった場合にそもそも登録できないようにしたり、特殊な意味を持つ記号をサニタイジングして登録する必要があります。 スクリプトを登録することができたので、一般利用者がサイトを利用する際にどういう挙動になるか見てみましょう。利用者は普通のECサイトだと思い商品一覧ページにアクセスします。すると先程登録したスクリプトが読み込まれ処理が実行されるので画像のようにJavascriptのホップアップがあがりました。 3.Cookie拾ってみる 上記を応用してJavascript内にCookieを表示させセッションIDなど取得してみようと思います。といってもやり方は先程同じで登録するデータの値を下記に変更するだけでCookieを取得することができます。 商品名：クッキー商品説明：’任意’ <script>alert(document.cookie);</script>価格：500円 登録できたので商品一覧ページにアクセスしてみます。 すると画像のようにPHPSESSIDをまるっと取得することができました。 少し見辛いですが、商品一覧ページのレスポンスを見てみるとスクリプトがそのまま登録されています。これにより利用者がサイトを読み込むたびにスクリプトが実行されてしまい、Cookieの情報を窃取されてしまいます。Cookieを窃取されてしまうとアプリケーションをのっとられたり、クレジットカード番号などの個人情報を不正に閲覧される可能性があります。 4.対策 3.の中でも少し触れましたが対策方法はいくつかあります。 今回はこんな対応方法があるよ！というのを一部紹介するので、その他の対策方法や、実装方法について詳細気になる方は是非調べてみてください。 対策方法 そもそも＜＞などの特殊な意味を持つ記号を登録しようとした際にエラーとして登録できないようにする。例）電話番号の入力欄は数字のみ許可。ふりがなは半角カタカナのみ許可。など入力データをそのまま登録せず、登録する際にサニタイジング処理を行う。サニタイジングとは「無害化」という意味で＜＞、＆などの記号を「&lt」「&gt」などに置換することでスクリプトとして処理が実行されないようにすることです。 5.おわりに いかがでしたでしょうか。文章だけだとわかりづらい脆弱性の挙動も、Webサイトの画面を見ながらだと意外とわかりやすい気がしてきませんか？この記事を読んでくださった方が自分の作成したサイトや今後開発を行う際に、入力値のサニタイズなど気にかけるようになってくれれば幸いです。