技術広報チーム の記事一覧

Perlを中心としたIT関連カンファレンス「YAPC::Kyoto  2023」が3月19日に京都市の京都リサーチパークで開催されました。Perlに限らないさまざまな技術情報が満載のイベントです。今回は「try/catch」をテーマにしたということで、初めて現地とオンラインというハイブリッドでの開催となりました。GMOインターネットグループからは、GMOペパボの技術者が参加して講演を行いました。今回はその講演から『入門 障害対応 「サービス運用はTry::Catchの繰り返しだよ、ワソン君」』をお届けします。 登壇者 渡部 龍一　@ryuichi_1208GMOペパボ株式会社 技術部プラットフォームフォームグループ SRE https://speakerdeck.com/ryuichi1208/ru-men-zhang-hai-dui-ying GMOペパボの古参サービスを支える技術部プラットフォームグループ 今回講演した渡部が主に担当しているサービスは、ネットショップ作成・運営のためのプラットフォームである「カラーミーショップ」です。2005年にサービス提供を開始した古参サービスで、流通総額は1兆円を超え、比較的大きなトラフィックを有するサービスです。 カラーミーショップのサービスの特徴やサービス構成は、「CI/CD Conference 2023 by CloudNative Days」（https://developers.gmo.jp/30849/）でもご紹介しているので、そちらも参考にしてください。 そんなカラーミーショップをはじめとしたGMOペパボのサービスにおいて、渡部が所属する技術部プラットフォームグループが担当しているのは、「サービスの多様性を確保し、サービスの成長に合わせて適切な環境を提供する」という点だと渡部は言います。具体的にはサーバーの調達、キッティング、SREによるサービスレベルの向上、クラウド環境の検証や選定、専門事業部門のアプリケーションの改善・開発など、事業の成長を支えることを目指しています。 障害対応における5つのフェーズ そんなGMOペパボにおける障害対応フローが今回のテーマです。 渡部はまず、サービス障害の定義として「通常の運用状態から逸脱してユーザーに影響を与える事象」と位置づけます。これはシステムの異常動作やアプリケーションの問題などが該当します。 それに対する「障害対応」とは、「サービス障害が起こった状態から通常の運用状態に戻すための対応」ということになります。 この障害対応を、渡部は5つのフェーズに分類します。 （1）障害の影響範囲の特定と分類 まずは提供範囲の特定が重要になります。使えない機能は何か、例えば外形監視が落ちている場合はどこに影響があるかを評価し、分類します。その結果、問題解決に必要な情報を集めることができ、影響範囲が分かれば、原因特定の方針決定の根拠となる情報も得られると言います。 （2）関係者への連絡 続いて、ユーザーに対してどのような影響があるのかを、関係者に周知することが重要だと渡部は指摘します。障害発生時は技術的な話をしがちですが、最初にやるべきはユーザーへの影響がどの程度あるかを共有することで、「報告は結論ファーストを意識している」と渡部。 同時に、サービスに関わる様々なチームへの連絡も行います。渡部の所属するSREチーさまざまは障害アラートなどを出しますが、障害の復旧がすべてできるわけではありません。そのため、マネージャーやカスタマーサポートチームに連絡して協力を仰ぐこともあるそうです。エンドユーザーに対して影響がある障害であれば、SNSなどでのアナウンスも必要になるので担当者と共有をします。 障害を起こしたアプリケーションに精通しているメンバーが、常に障害のアラートを受け取れるわけではないため、その場合はアプリケーションエンジニアに、セキュリティインシデントならセキュリティエンジニアにエスカレーションすることもあるそうです。 （3）原因調査 3番目が「なぜ繋がらないのか」を調べるフェーズです。「外形監視になった」、「Webサービスに繋がらなくなった」というだけでは、「なぜ繋がらないのか」の原因は分かりません。 最も頻度が多いのは、サービスに何かしらの変更を加えた際に繋がらなくなるエラーが起きることだと言います。そのため、まずは変更したシステムを調べることになります。 例えば、アプリケーションをデプロイした場合はその内容を確認したり、GUIの設定画面からサーバーの設定を変更していたらそれを確認したりします。とはいえ、「何もしていないのに壊れるケースが"たまによくある"」と渡部は苦笑します。 他にはハードウェアが原因の場合や急激なトラフィックでソフトウェアが耐えきれない場合があるので、もう少し詳しく原因を探っていくそうです。サービスを構成するコンポーネントから、怪しい部分を探るわけです。 原因調査は、仮説確認を繰り返していくフェーズだと渡部は話します。どこが怪しいのか全くわからない状いであれば、例えば構成図を見てロードバランサーやWebアプリケーション、データベース、ネットワーク、外部連携サービスなど、何かおかしくなっていないかを見ていきます。 渡部が取る手法としては「挟み撃ち法」があるそうです。これは、例えばL3レイヤーを調べたらL7のWebアプリケーションを確認し、L4を見てL6を見る、というような順番で確認していく方法です。「OSI参照モデルをイメージしてもらえれば分かりやすい」と言います。 このフェーズではログ調査も行って、怪しいログをチェックすることもしています。 （4）復旧作業の実施 原因が判明したら復旧作業を実施します。これには2つのパターンがあり、一つ目が「根本対応」です。調査で原因が完全に判明すれば根本的な対応が行えます。ところが、原因は分からないけれども接続できないということもあります。 そうした場合に行うのが「止血対応」と呼ばれる作業です。過去の知見から、「もしかしたら復旧するかもしれない」という対応手段を試していくというものです。ここで大事なのが、「原因が分からなくてもユーザーが正常にサービスを利用できる」ことを最優先にするということです。そのため、まずは止血対応によってサービスを正しい状態にすることを意識しているそうです。 具体的な手法としては、OSやミドルウェアの再起動、アップデートをしていたら根本原因が分からなくてもロールバックするといった手段で復旧を試みます。急激なトラフィック増加等があればリソース不足の可能性もあるので、スケールアウトなどの対応をします。 （5）ポストモーテム 最後のフローがポストモーテムです。これは障害対応後に行われる反省と改善のための分析会議」で、障害の原因、障害対応の振り返りを行うことで、今後の改善点を見つけることを目的としています。 こうした会議でありがちなのが、失敗の要因を明確にすることだけになってしまい、成功の要因が明らかにならないという例があります。そこで渡部は「対応がなぜうまくいったのか」という要因を分析してドキュメント化も行っているそうです。 この会議のドキュメントは、会議に未参加のチームや、今後参画する新メンバーも学んでいけることを意識して執筆していると言います。具体的にはなぜこうした対応をしたのか、障害復旧後にアクションアイテムがあったらイシュー化して追跡しやすくする、といった記録を残していると言います。 1人に頼らずメンバー全員の能力向上を こうした障害対応の能力をどのように向上させるか。渡部はまず「障害対応能力」について、前述の5フェーズを全て1人で担当できるという人物が能力値マックスと規定します。 そもそも障害をゼロにすることはできないという判断から、障害が発生したときに対応するメンバーの能力向上が必要というのが渡部の考えです。そのためには「何度でも障害に向き合っていく必要がある」と渡部は言います。 以前まで、GMOペパボでも障害発生時に一部の優秀なエンジニアが1人で原因特定から復旧までを短時間で対応してしまい、他のメンバーの知見が残らないということがあったそうです。 そういった優秀なエンジニアも24時間365日稼働できるわけではないので、そのエンジニアがいないときの障害対応の時間が長くなってしまい、サービスの信頼性低下にも繋がりかねません。 そのため、障害対応能力が高いメンバーがチーム内に多く存在するほど、サービスの信頼性向上に繋がる、というのが渡部の考えです。 そうしたメンバーを増やすためには、障害対応の教科書のような書籍を学習するだけで実践するのは難しいといいます。例えばサービスの再起動をするためのコマンドは学べても、どのタイミングで、どういった根拠で再起動をするのか、といった見極めは経験が必要だからです。もちろん、本番環境で学ぶのが一番なのですが、それが難しい場合もあります。 2つの施策で能力向上 渡部が採用した施策は2つ。Playbookの作成と障害対応訓練です。 Playbookとはアメリカンフットボールの用語で、戦略やプレイをまとめた資料です。渡部は「一定の知見や経験を持った人でなければ理解できない熟練者向けのドキュメント」と位置づけます。渡部のチームでは、障害対応能力の高いメンバーが行った作業内容と、その作業に至った思考の流れをドキュメント化しているそうです。 これまでのドキュメントには事実は記載されていましたが、具体的な対応方法の記載がありませんでした なぜそのコマンドを打ったのか、なぜその作業を行ったのか、結果として何が起きたのか、そういった部分を取りまとめることで、他のメンバーの障害対応能力向上に繋がると考えたと言います。 PlaybookはMarkdownによって事例ごとに情報を蓄積していきます こうしてPlaybookに事例を積み上げて情報を共有し、メンバーのノウハウを蓄積していくことに加えて、障害対応経験を増やすための訓練も行います。 過去に発生した障害などをテスト環境に再現して、実際に調査から復旧までを実践してもらう内容ということで、さらに出題者と回答者に分かれて実施しているそうで、机上演習のようなものというイメージのようです。 Playbookと障害対応訓練という施策を実施した結果、「チーム全体の障害対応能力の向上に繋げることができた」と渡部は言います。調査から復旧までを単独で実施できるメンバーも増えているそうです。訓練で実施したトレーニングと同じ障害が、訓練の数時間後に実際に発生する、といったこともあったそうで、訓練を生かすこともできたと言います。 障害対応も一日にしてならず 「障害を完全になくすことはできない」。まとめとして渡部はそう伝えます。そのため、障害は起きるものとして対応に向き合う必要があります。優秀なメンバーだけが対応するような属人的な状況は危険で、障害対応できるメンバー数を可視化していく必要があるとしています。 障害対応できるメンバーを増やすためのPlaybookや障害訓練といった施策も、すぐに効果が出るような施策ではなく、渡部は「ローマは一日にしてならず、障害対応も一日にしてならず」として、継続的に続けることが必要だと強調しました。 質疑応答では、Playbookを作成するためのコストの問題について問われ、渡部は「コストはかかるけれど、最終的にメンバーが増えるというチームの状況だったので、それでペイできるという判断で未来への投資としてメンバーを説得しました」と回答。ちなみにPlaybookには「障害対応での思考の流れをドキュメント化する」という例を挙げた渡部ですが、これは作業中にSlackのスレに書き込んでいって、最後にまとめるそうです。 障害対応訓練に対して問われた渡部は、「簡単なものだと30分や1時間で障害環境を用意して、回答を受ける側も1時間程度で終わる」とのことで、極端に長時間化かかるような訓練はまだしていないということです。逆に言えば、それでも訓練としては意味があるということと言えそうです。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=JsfhvMffnHk

2023年3月23日（木）〜25日（土）に技術カンファレンス「PHPerKaigi 2023」が練馬区立区民・産業プラザ Coconeriホールおよびオンラインにて開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛し、登壇セッションでは、GMOペパボ株式会社より小山 健一郎が登壇しました。その内容をご紹介します。 はじめに テスト戦略を策定する際の指針となるコンセプトの1つに「テストピラミッド」があります。テストピラミッドでは、ユニットテスト、インテグレーションテスト、E2Eテストの3つのレベルに分けて、この順でテストの量を小さくしていくピラミッド型にすることが推奨されます。一方で、React Testing Libraryの作者であるKent C. Dodds氏は「テスティングトロフィー」というインテグレーションテストに最も重点をおいたテストコンセプトを提唱しています。複数の選択肢があるなか、テスト構成の最適解はどのように考えていけばよいのでしょうか。2023年3月23日（水）〜25日（土）に練馬区立区民・産業プラザ Coconeriホールおよびオンラインにて開催された技術カンファレンス「PHPerKaigi 2023」で、GMOペパボ株式会社 小山 健一郎氏が自社での事例をもとに解説しました。 登壇者 小山 健一郎　＠k1LoWGMOペパボ株式会社 技術部 技術基盤チーム https://speakerdeck.com/k1low/phperkaigi-2023 テストピラミッドとテスティングトロフィーの違い 小山氏は、講演冒頭で単体テストの原則とそのパターンをまとめた書籍『単体テストの考え方/使い方』（マイナビ出版、2022年）を紹介しました。同書籍によると、テストピラミッドは、テスト・スイートにおいて、「単体テスト（ユニットテスト）」「統合テスト（インテグレーションテスト）」「E2E（エンドツーエンドテスト）」という異なる種類のテストがそれぞれ特定の割合でテストケースを持つようになっていることを提唱している概念とされています。そして、テストピラミッドの横幅は、テスト・スイートを構成する各種類のテストに含まれるテストケースの数を示します。そのため、テストピラミッドの層が横に長いものほど、テストケースが多いことになります。また、テストピラミッドの高さは、対象のテストがどれくらいエンドユーザーの視点に近いのかを示します。 一方で、テスティングトロフィーでは、テストの構成割合がテストピラミッドとは異なります。横幅をみると、インテグレーションテストが最も大きくなっており、重点的にインテグレーションテストを実施することが推奨されます。小山氏は「信頼性と速度・コストのトレードオフのバランスを上手くとっている、インテグレーションテストに労力を費やすと効率よくテストが進められるという主張だと考えられる」と説明します。 テストの分類 そもそも、ユニットテスト、インテグレーションテスト、E2Eテストには厳密な定義がなく、人によって認識がずれてしまうことも多くあります。ここで小山氏はそれぞれの考え方を次のように整理します。 「『単体テストの考え方/使い方』によると、ユニットテストは1単位の振る舞いを検証すること、実行時間が短いこと、他のテストケースから隔離された状態で実行されることという3つの性質を持つ。これら3つのうち1つでも損なっているものをインテグレーションテストに分類する。ただし、この定義でもすべてが明確になるわけではなく、“隔離された状態”についても解釈の異なる考え方がある」（小山氏） ここで、小山氏はテストの実行速度と決定性に着目したテスト分類としてテストサイズを取り上げます。これは『Googleのソフトウェアエンジニアリング』（オライリージャパン、2021年）で紹介されているテスト分類です。書類を元に小山氏は、テストサイズの定義を下記のように紹介します。 スモールテスト:単一プロセス（シングルスレッド）内で実行されるもの。sleep、I/O、ブロックは禁止ミディアムテスト:単一マシン内で実行されなければならない。ローカルホスト以外のシステムへのネットワーク呼び出しは禁止ラージテスト:複数マシンにまたがるテスト よりわかりやすくするためにテスト対象のアプリケーションを具体的に示したうえで考えると、テストサイズは図のようなイメージとなります 「良いテスト」とは？ 『単体テストの考え方/使い方』では、以下の項目が良いテストを構成する4本の柱とされています。 退行（regression）に対する保護リファクタリングへの耐性迅速なフィードバック保守のしやすさ ただし、1〜3は互いに排反する性質であり、すべてを成り立たせることはできません。こうした制約のなかでは、リファクタリングへの耐性と保守のしやすさを可能な限り備えたうえで、リファクタリングへの耐性と迅速なフィードバックの2つのあいだでバランスを調整するのが現実的な戦略となります。 ここで、テストサイズの観点からテストピラミッドのテスト戦略を捉え直してみます。退行に対する保護は、ラージ＞ミディアム＞スモールとなりますが、保守にかかるコストが増加するほか、迅速なフィードバックは得られません。したがって、保守コストと迅速なフィードバックを考えると、テストケースの数は、スモール＞ミディアム＞ラージという戦略になります。 一方、テスティングトロフィーをテスト戦略で捉え直すと、信頼性が重要視されるため、品質保証、つまり退行に対する保護を優先します。結果、ラージ＞ミディアム＞スモールの順でテストの信頼指数（品質保証への貢献度）は高くなりますが、ラージを重視すると迅速なフィードバックが得られません。そこで、バランスの良いミディアムテストに重点を置くという考え方になります。 小山氏は「テストピラミッドは、ほとんどのアプリケーションに効果を発揮する構成だが、それがすべてではない。良いテストを構成する4つの柱と、テスト対象の状況やフェーズ、開発体制などさまざまなパラメーターをみて判断していくことが重要」とします。 GMOペパボの事例に見る、テスティングトロフィー実践の課題と解決策 ここから小山氏はGMOペパボでの事例をもとに、テスト構成の方針の立て方について解説していきました。 今回対象となったのは、新規開発のAPIサーバです。扱うドメインはシンプルで、ドメインロジックもあまり複雑ではありませんが、データの取り扱いを慎重に行う点、また長期運用が想定されている点に気をつける必要がありました。動作環境はコンテナベースを想定しており、開発言語はGo、APIの定義にはOpenAPI Spec v3を採用しスキーマ駆動開発で進める方針となっていました。 小山氏によると、アプリケーションのテスト戦略を考えたのは開発初期だったといいます。当時は開発言語が決まったくらいの時期で、アプリケーションの実装が見えてこないことによる難しさがありました。 特に今回は、長期運用に耐えうることが要件に盛り込まれていた点がポイントでした。これを意識し、「まず外部とのインターフェイスであるAPIスキーマが重要。接点がある以上は、APIの更新がありつつも残るはず。データベースの寿命はアプリケーションよりも長いと考えられるため、データベースのスキーマも大事」（小山氏）と方針を決めていきました。小山氏は「一方で、アプリケーションのアーキテクチャが長期的に持続するかわからない、アーキテクチャの検討もできていない状況で、自分が今から設計するアプリケーションそのものが信用できない状態だった」と振り返ります。 ここで有効となるのが、テスティングトロフィーの考え方です。アプリケーションの外部からのテストに重点を置くことで、アプリケーションの実装の変化に影響されにくいテスト構成にするというアプローチを取ることができるためです。ただ、実現にあたっては大きな課題がありました。ミディアムテストのコストがスモールテストに比べて大きいという問題です。 まずは、テストの実行コストです。迅速なフィードバックの観点からすると、一般的にミディアムテストはスモールテストより実行時間が長くなるため、「並行実行の仕組みで緩和しつつも、ある意味許容する必要があった」と小山氏はいいます。また、テストの作成保守コストも課題です。「APIにHTTPリクエストを送信して、意図した結果や状態になっているかを確認する」というテストを書くこと自体に手間が掛かってしまうため、できる限り簡単に書ける仕組みを構築することが求められます。 この解決策としてのがrunnというツールです。runnは、シナリオに沿って操作を自動化できるパッケージ/ツールで、HTTP、gRPC、データベースをはじめさまざまなプロトコルに対応しています。 シナリオファイル（YAML）のフォーマットは、OpenAPI Specライクであり、シナリオ内のステップ間の値が自動で連携されるので、「ステップAを実行してからその結果を使ってステップBを実行する」というシナリオを構築しやすいといえます。分割実行、サンプリング実行、ランダム実行、並行実行なども可能で、ループ実行やリトライ実行の仕組みも組み込みで備わっています。 runnでは、1つのシナリオは1つ以上のステップから構成されており、1シナリオは1YAMLファイルになっています。これをランブックと呼びます。シナリオごとにランナーと呼ぶステップ実行コンポーネントを定義し、ランナーを使って各ステップを実行していくというアーキテクチャになります。 「ログインしてプロジェクト一覧を取得する」というシナリオは以下のとおりです。ランナー、変数を設定して、各ステップを書いていくという流れになっていることがわかります。 このように、ミディアムテストの課題であったテストの作成保守コストは、runnでスモールテスト並みに削減することができました。 「テスト構成の最適解はテストピラミッド一択ではない」 テスティングトロフィーを実践してみて「あくまで主観だがうまくいった」と振り返る小山氏。具体的な効果について次のように紹介しました。「1つのシナリオあたりのコードカバレッジが非常に大きいので、リファクタリングへの耐性、退行に対する保護への効果が大きい。シナリオの拡充もYAMLを書くだけでよいためかなり捗る。また、シナリオがOpenAPIライクだったので、エンジニアにとって読みやすいものになり、オンボーディングにも役立つ」（小山氏） 今後の規模拡大やアーキテクチャの安定化などの要因によってテスト構成がピラミッドに近づいていくことは大いにありうるといいますが、小山氏は「現時点においては（テスティングトロフィーの採用は）悪くない判断だった」と評価します。そのうえで「テスト構成の最適解はテストピラミッド一択ではない。その都度、状況にあわせて考えていきたい」と語りました。

先日開催された、技育祭【春】にGMOインターネットグループとして協賛しました。当日はリードエンジニアと若手エンジニアが講演に登壇、また当社の福利厚生についてご紹介しました。その内容をレポートしていきます！ イベント概要 技育祭は、GMOインターネットグループも年間協賛している「技育プロジェクト」の１つで、「技術者を育てること」を目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。 開催日：2023年3月18日（土）～3月19日（日）会　場：オンライン運　営：株式会社サポーターズ参加費：無料（事前登録制）公式HP：https://talent.supporterz.jp/geeksai/2023spring/ 講演登壇 DAY1 / 3月18日(土) 12:40-13:25「GMOのオールライトニッポン！ 〜若手エンジニアが現場のリアルを語ります〜」 ◆登壇者・GMOペパボ株式会社 シニアエンジニアリングリード　黒瀧 悠太・GMOペパボ株式会社　中田 輝・GMOインターネットグループ株式会社　火箱 力・GMOアドマーケティング株式会社　岸田 優輝 当日はリードエンジニアと新卒エンジニア３名が登壇し、事前に用意した９つの質問から３つ、Twitter#GMO悩み相談 でみなさまからいただいた質問８つに回答させていただきました。 ■回答した質問・こんなポートフォリオはいやだ・やらかした！失敗談・入社してからどれくらい成長した？・AIエンジニアとして、大学生の時にやっておくべきこと/勉強しておくと良いこと・ネットワークって何をやったらいい？・仕事で1番楽しかった経験は？・サイバー攻撃を体験したことはある？・技術のキャッチアップはどうしている？・インフラ系で就職するのに必要な経験は？・Chatgptを業務でどのくらい使ってる？・プログラミングでコメントはどのくらい書く？ チャットやTwitterからたくさんコメントをいただけ、登壇者らも楽しんで技育祭に参加することができました。 企業LT・CM 「GMOインターネットグループの福利厚生について」 ◆登壇者・GMOインターネットグループ株式会社 インフラ・運用本部 クラウドサービス開発部　長谷川 泰斗 GMOインターネットグループでは、働く仲間の意欲・能力が十分に発揮でき、また世界中から優秀な方が集まる仕組みを作ることは不可欠と考えています。そのため、コミュニケーションスペース「シナジーカフェ GMO Yours」、託児所「キッズルーム GMO Bears」、マッサージスペース・昼寝スペース「マッサージ＆おひるね GMO Bali Relax」、フィットネスGYM「GMO OLYMPIA」など、福利厚生の拡充を進めています。 今回の企業LTとCMでは、このような福利厚生施設についてご紹介しました。 ▼CMもぜひご覧ください。 https://www.youtube.com/embed/nTvoRn6CUuM さいごに ご視聴くださった学生の皆様、ありがとうございました。 また、技育祭 2023 秋でお会いしましょう！

CI/CDに特化したテックカンファレンス「CI/CD Conference 2023 by CloudNative Days」が、2023年3月20日に開催されました。東京都内のリアル会場とオンラインの双方で参加でき、全部で18のセッションが行われました。GMOインターネットグループではCMスポンサーとして協賛し、自社のインフラCI/CDの実装やその課題と解決に関して情報を提供するセッションをお届けしました。今回はその内容をご紹介します。 登壇者 渡部 龍一　@ryuichi_1208GMOペパボ株式会社 技術部プラットフォームグループ SRE アーカイブ動画：https://event.cloudnativedays.jp/cicd2023/talks/1755 https://speakerdeck.com/ryuichi1208/inhuraci-cdji-sok-de-gai-shan-nodao-nori GMOペパボの古参サービス・カラーミーショップの歴史 GMOインターネットグループのGMOペパボでは複数のサービスを運用しています。例えばカラーミーショップは2005年にサービスを開始しており、GMOペパボの中でも歴史あるサービスのひとつで、このサービスを利用して作成されたECサイトの流通総額は1兆円を超え、トラフィック量の大きなサービスとなっています。 GMOペパボが運用しているサービス一覧 構成は複数のユーザーで1つのリソースを共有するというマルチテナント型。開発体制は、人の流動性が結構激しいものの、アプリケーションエンジニアが数人から30人、SREは6人ぐらいというイメージだと渡部は説明します。 歴史の長いサービスだけあってカラーミーショップではインフラも随時変更されてきました。「オンプレ期」から始まり、OpenStack上のKubernetesでアプリケーションを運用していた時期を経て、現在は「ハイブリッドクラウド期」です。プライベートクラウドとパブリッククラウドに同じ環境を用意して接続し、アプリケーションやサービスを提供するという構成です。 ちなみに、このあたりの情報に関しては、別のイベントでカラーミーショップのエンジニアが解説したスライドがありますので、興味のある方はそちらもご覧ください。 https://speakerdeck.com/ch1aki/onpurek8stoeksnobing-xing-yun-yong-noshi-ji カラーミーショップがたどったインフラの歴史。プライベートクラウド、プライベートクラウド上のKubernetesで稼働していたKubernetes on プライベートクラウド期が現在主流で、ハイブリッドクラウドに移行しているところだといいます。 カラーミーショップのサービス構成 カラーミーショップは3層構造のサービス構成。ロードバランサーはプライベートクラウド、パブリッククラウド上にそれぞれに実装されていて、アプリケーションはVM（仮想マシン）またはKubernetes上に、データベースはAWS上に存在しています。 アプリケーションは80以上のロールで構成されています。基本的にはKubernetesへの移行を進めているそうですが、全てをVMから移行できるわけではなく、現時点ではVMの方がロールの数は多く、しかも一部のロールはコンテナ化しない予定であり、混在環境が継続することになります。 こうしたインフラ周りで使われている技術スタックは以下のようになっています。 プラットフォーム OpenStack、AWS、Kubernetes開発言語Ruby、mruby、GoミドルウェアNginx、MySQL、Redis、memcachedCI/CDGitHub Actions、ArgoCD監視Mackerel、Prometheus、Grafana、ElasticAPM、DataDogIaCPuppet、Ansible、Chef、Terraform ロールのほぼ全てはPuppetで管理されていますが、デプロイパイプラインとしてVMとKubernetesに分かれており、それぞれでCI/CDが異なっています。 VMの場合はOpenStackのレイヤをTerraformで管理。ミドルウェアの管理がPuppetで、ローカルでは各自でVMを用意してPuppetをアプライ。コードが完成したらGitHubにプッシュし、Puppetをアプライしたコンテナに対してServerspecでテストを実施。問題なければインテグレーション、ステージング、プロダクションなど、環境ごとにデプロイして動作確認するというフローになっているとのこと。 Kubernetesの場合は、「kubectlのデプロイは原則禁止で、いわゆるGitOpsのフローを取っている」と渡部。フローとしては、main branchがステージング環境に適用され、release branchがプロダクション環境へ適用されます。 開発ではmanifestの修正をGitHubにプッシュし、Dockerfileのテスト、DockerImageのビルドやプッシュを行い、ArgoCDを用いて実際のクラスターに適用するという流れです。 カラーミーショップが抱える6つの課題 こうしたカラーミーショップの環境には、以下の6つの課題を抱えていると渡部は説明します。 インフラテストへの課題コードとサーバーで差分が発生している問題暗黙知前提の運用問題VMとコンテナ混在問題セキュリティ対応問題使用しているツールが多く、学習に時間がかかる問題 インフラテストへの課題は、端的に「時間がかかりすぎる」というものです。例えばただnginxでパラメーターをひとつ変えるためのプルリクエストを出すだけでも、ローカルのVMにコードを適用するだけで15分、CIでコンテナを起動してコードが適用されるまで20分、合計35分がかかっていました。 デプロイまでのフローには複数の段階があり、些細な修正でも毎回35分程度の時間がかかっていました これだけ時間がかかるのは、CIが毎回プレーンな環境で実行されるという点にありました。プレーンになってしまうので修正以外の部分もやり直しになってしまいますし、「末尾のセミコロンを忘れた」というだけの修正確認でも20分かかってしまうのだそうです。 他にも様々な問題が発生しえます。最終的には「何もしなくても時間の経過とともにシステムは壊れていく」と渡部。 2番目のコードとサーバーの差分については、VMがミュータブルな点、障害対応時のアドホックな対応などが残っている点、ロールが80以上と多数になるため半年近くデプロイされていないものも存在する点などで差分が出てしまうことがあるとのこと。サービス開始当初のコード管理せずに構築されたロールなどもあって、属人化が進んでいるということもあったそうです。 似たような課題が暗黙知前提の運用で、インフラのコードに触れるメンバーがある程度固定化されてしまったため、セットアップする人がおらずに以前のセットアップ手順書が使えなくなってしまったり、メンテナンスがされていなかったり、コード変更作業がSREチームに依頼されるためチーム本来の作業ができないという問題がありました。 3番目のVMとコンテナ混在問題は、積極的なコンテナ化を進めつつもVMが混在する状況で、ミドルウェアの設定変更でVMとコンテナ双方で対応が必要になり、VMに最適化されたnginxなどのミドルウェアの設定も問題が発生することがあります。 セキュリティ対応問題では、パッケージなどの脆弱性をチェックするツールを使っても報告される数が膨大で対応しきれないという点があります。深刻度の高いもの以外は優先度を挙げられないという問題もありました。 学習コストの問題は、使用しているツールの数が多いために発生しています。IaCだけでも複数のツールがあり、運用ツールも多数の言語で実装されていて、現在メインのRubyとGo以外にも複数の言語が存在しています。 そもそも2005年からスタートしているサービスのため、当時の開発者の得意言語で作られたツールがシェルスクリプト、Perl、Pythonなどとバラバラにあり、しかもプロダクションで運用されて使われていることもあるため、メンテナンスのために言語習得が必要になることもありました。 課題をいかに解消するか こうした課題に対しては、まず「課題をどうしたいのか」という定義から始めました。 暗黙知前提の運用のためにインフラに触れるメンバーがスケールせず、「触るのも恐い」という状況で、SREチームがインフラ作業に従事せざるをえないという課題に、「アプリケーションエンジニアも安心して触れる、インフラCI/CDを目指す」ことを目標に改善を目指しました。 解決へのアプローチは以下の通り。 CIの高速化暗黙知の徹底排除テストの拡充開発環境の整備構成ドリフト検出のための仕組みの実装コンテナ on VM監視の見直しデイリーでコンテナイメージをビルドする仕組みの実装権限委譲 インフラテストで1回30分の時間を要していたCIは、GitHub Actionsの設定方法のチューニング、ライブラリやPuppetでのキャッシュや並列化などによって1割程度、2～3分程度は削減。 さらにパイプライン自体の最適化としてキャッシュを有効活用。kernelヘッダーやgccのアップデートなど、変更と関係ない部分をキャッシュしておき、毎日朝に適用済みコンテナイメージをプッシュしておき、当日はそのイメージを利用することで、10～15分の削減に繋がりました。 さらに誰でも簡単に使えるようにすることを目指し、暗黙知前提の運用排除を目指しました。まずはドキュメントの執筆と勉強会、ワークショップの実施もしつつ、CIに関する作業の自動化を進めました。 これはプルリクエストに対して必要なラベル付け、開発環境のセットアップコマンドによる必要なツール類のインストール、テストの拡充など多岐に渡り、テストのたびにGitHubにプッシュする必要がなくなるなど効率化。 コードとサーバーの差分で発生している問題については、定期的に差分検出やコード適用する仕組みを実装。毎朝1回、Terraformのplanをチェックしたり、Puppetの差分確認コマンドも時間を決めて実行し、差分の有無を確認したりしているといいます。 デプロイフローも整理して、GitHub Actionsからしか実行できないように整備しました。変更履歴の管理が容易になって、いつ、誰が変更したかを追跡しやすくなったことがメリットです。 VMとKubernetesの混在問題は、移行期間ということもあって同時に同じアプリケーションが動いていることがあります。これに対してDockerをVMで動かし、1コンテナを1つのVMで動かすことにしました。VMの修正はDockerファイルにコンフィグレーションを含めてビルド。そのイメージをプッシュすることにして、1つの修正でVM、Kubernetes双方に反映される仕組みを実装しました。 セキュリティの課題について、パッケージの脆弱性は最新版で改善されているケースが多いので、Dockerファイルのパッケージバージョンではlatest指定し、ステージングなどで動作確認を毎日行います。latest指定で壊れてしまっても、本番環境には影響が出なくなるわけです。 こうした取り組みによってインフラCI/CDが改善され、エンジニアが触りやすい環境にはなってきました。結果として、SREチームのレビューが必須だったブランチ運用ルールを不要にできたと渡部は説明。 とはいえ、CI/CDの改善による生産性の向上が実現したかは難しい問題だと渡部は指摘します。アプリケーションエンジニアの作業量が増えただけで組織全体では生産性が下がっているのではという懸念もあり、可視化ができていない点が課題なのだとしています。 それでも、SREチーム以外が触りづらかったインフラにおけるCI/CDの改善活動を続けて、状況は良くなってきました。現在も試行錯誤中ですが、GMOペパボにおける「コンテナとVMの混在環境」というのは、一般的に起こりえる状況なので、解決するための知見を今後もアウトプットしていきたいと渡部は話していました。

2023年3月23日（木）〜25日（土）に技術カンファレンス「PHPerKaigi 2023」が練馬区立区民・産業プラザ Coconeriホールおよびオンラインにて開催されました。GMOインターネットグループはダイヤモンドスポンサーとして「成瀬の挑戦状」という企画を実施。セッションでは、GMOインターネットグループメンバーよる挑戦の様子を出題者である成瀬允宣が実況・解説しました。  登壇者  成瀬 允宣GMOインターネットグループ株式会社 テックリード／デベロッパーエバンジェリスト  PHPerKaigi 2023 |スポンサーセッション「成瀬の挑戦状」レポート  問0：開始直後から各メンバーさまざまなアプローチで取り組む  今回「成瀬の挑戦状」に挑戦したメンバーは、GMOペパボのOさん、GMOペイメントゲートウェイのKさん、GMOリサーチのNさん、GMOインターネットグループのIさん、GMOメディアのAさんの5名です。120分間で問0、問1、問2、問3、最終問題を解いていきました。  挑戦状には、Dockerのロゴアイコンのようなイラストとともに「nrslib sampleにて待つ」と手書きで書かれています。これはGMOインターネットグループメンバー専用に問0として成瀬が用意したもので、Dockerから設問をプルするところから課題を始めてほしいという意図が込められています。  メンバーは、デスクトップでフォルダを作成するところから始める人、Docker Hubを見に行く人、Docker Desktopを起動して一覧化する人、Docker ComposeのYAMLファイルを書く人など、この時点でさまざまです。  問1：まずは「シーザー暗号」に気づけるかどうか  問1は下記のような問題です。  以下を解読し解答してください。 MXQJYIJXUDQCUEVJXYISYFXUH  以降の問題も暗号文を解読していく形式となっていました。「こちらをどのように解読していくかがプログラマーの勘所」と成瀬はコメントします。  今回の課題のポイントは「シーザー暗号（カエサル暗号）」です。シーザー暗号とは、下図のようにA からZまでの文字をD→A、E→B、F→Cといった形でシフトして文章を作成し暗号文とする暗号です。  今回の暗号文を+10シフトすると「WHAT IS THE NAME OF THIS CIPHER（この暗号の名前は何か）」という問題文となり、「シーザー暗号（カエサル暗号）」と解答すれば正解となります。  問1から苦戦するメンバーも多いなか、Aさんは、ChatGPTに「key: nrslib 暗号化方式：シーザー暗号化 復号化した文字列を教えて」「鍵を使ってシーザー暗号化された文字列を復号化するアルゴリズムをPHPで作成してください」などと入力して暗号化前の文章を復号しようとしていました。Nさんは、Web上のシーザー暗号解読機ツールを用いて暗号文を入力し、「WHAT IS THE NAME OF THIS CIPHER」という文章を見つけていました。  問2：シーザー暗号の進化系「ヴィジュネル暗号」を使う  問2では、鍵を用いながらヒントを解いていくと「CIPHER CONCEIVED IN THE LATE FIFTEEN AND LATE SIXTEEN CENTURIES（15世紀後半から16世紀後半にかけて考えられた暗号）」という文章が現れてきます。  これは「ヴィジュネル暗号」のことを指しています。ヴィジュネル暗号とは、シーザー暗号の進化系ともいえる暗号で、ヴィジュネル方陣という変換表を使って暗号化を行います。  ここでヴィジュネル暗号が用いられていることに気づけば、復号ツールを利用して「WHAT IS THE NAME OF THIS CHALLENGE（このチャレンジの名前は何か）」という問題文を導き出すことができます。問2の答えは「成瀬の挑戦状」です。  ヴィジュネル暗号が用いられていることにいち早く気づいたのはOさんでした。Nさんも2問目のヒントを順に解いていき、ヴィジュネル暗号の復号ツールを探して問題文にたどり着いていました。  問3：順調に解答していくメンバーがいる一方、苦戦するメンバーも  問3もビジュネル暗号でテータを解読するものでした。復号すると現れる緯度と経度の数値をもとに、GMOインターネットグループの所在地である東京都渋谷区桜丘町の「セルリアンタワー」という答えを導き出せれば正解となります。KさんはBase64で複数回デコードを行うことで緯度経度の数値を導き出していました。  一方で、苦戦するメンバーもいました。Aさんは解答欄に「障害対応が発生したため途中で諦めます」と書き込み、業務上の都合から途中でチャレンジを断念。お手あげ状態だったIさんは、ChatGPTに対して「この暗号わかる？」「この暗号は何の種類の暗号ですか？」などと質問をしていました。  最終問題：最終問題まですべて解答した完全制覇者が現れる  最終問題は、Base64で解読すると「final」という名前になるphpファイルにありました。「fourth.php」というダミーのファイルに騙されないことがポイントです。そして、最後の暗号をレインボーテーブルを用いながらヴィジュネル暗号で復号化すると、「WHAT IS THE ANSWER TO LIFE THE UNIVERSE AND EVERYTHING（生命、宇宙、そして万物に対する答えは何か）」という文章が出てきます。  この文章は英国の作家であるダグラス・アダムズのSF小説『銀河ヒッチハイク・ガイド』が元ネタになっており、同作品内に登場するスーパーコンピューターは、この質問に対して「42」という数字を導き出します。したがって、最終問題の解答は「42」となります。  こちらも最初に解答までたどり着いたのはOさんでした。Nさんはレインボーテーブルを見つけていたものの、気づかずにブルートフォースを試みていました。  今回の挑戦は「1〜2問でも解ければ十分すごい」  こうして、Oさんが完全制覇をする形でGMOインターネットグループメンバーによるチャレンジは終了しました。Kさんは最終問題に挑戦していたものの時間切れとなってしまいました。挑戦を振り返って、メンバーはそれぞれ次のようにコメントしていました。  Iさん：ぜんぜんわからなかったです。英語のできない子が、問題文が英語で書かれていて何を聞かれているのかわからない、という状態に近い感覚を覚えました。救済措置を求めます（笑）  Kさん：業務アプリ開発だと暗号には触らないでビジネスロジックを組んでいくと思うので、普段と違ったことができておもしろかったです。  Nさん：（途中から暗号の勉強をしていたことについて）何をやっていいのかわからなくなってしまい、太平洋戦争のときの暗号などをいろいろ調べました。  Oさん：初手でノーヒントなのがキツかったです（※本番ではヒントが出されました）。楽しかったですけど難しかったので大変でした。みなさんにもぜひやってもらいたいという気持ちがあります。  こうした結果に対し成瀬は、「完全制覇が現れたことについては素直に脱帽。もしかしたら企画当日も他に完全制覇者がいるかもしれない」と評価したうえで、「挑戦状の問題に関しては、完全制覇は出ないと思って作ったつもり。1〜2問解ければ十分すごいという感覚」と今回の課題の難易度について説明していました。  挑戦状の問題を解くなかでは「IWILLBLOG」というキーワードも出てきます。参加者の方はぜひブロク等で今回の感想を書いていただけるとありがたいです。  お知らせ 最後にお知らせです。 当日のスポンサーセッション放映後、成瀬本人の「成瀬の挑戦状」の解説ブログが投稿されました！より詳しい解説をご希望の方、本記事と併せて是非チェックしてみてください。 解説ブログ：カンファレンス協賛企画『成瀬の挑戦状』の解説【PHPerKaigi 2023】 また、劇中の「成瀬の挑戦状」はしばらくDocker内に残しておきますので、ご興味のある方はいつでもご挑戦ください！ アーカイブ映像 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=sAnNIQqjOaQ

2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day（DevDay）2022」が開催されました。ご来場頂いた方、またオンラインでご参加された方、ありがとうございました。今回わたしはフロントエンドとして配信ページの実装を担当いたしましたが、運営・デザイナーからの要望、負荷などを加味しながら実装する上で工夫したこと、また今年残った課題について書いていきたいと思います。 フロントエンドが関わる部分 毎年イベントの仕様自体が変わるのですが、今年はオフライン開催（会場参加）とオンライン開催（ブラウザで視聴）を同時開催することになりました。 そのため、Webページもオフライン参加・オンライン参加両方に関して記載、オンライン参加のための配信ページを作成しました。また、イベント中に告知されるキーワードを入力してスコアを取得・スコアに応じて景品が貰えるというキャンペーンを実施するため、キーワードの入力・スコア表示するためのページを作成しました。 設計 ディレクトリ DevDay 自体は2020年から開催されており、今年の実装と同時に2020年と2021年の集客ページのアーカイブ化をしてほしいという依頼がありました。また、イベント開催前・開催中・終了後でコンテンツが変わり、なおかつ短期間で確認とライブアップを繰り返す必要があることから、DevDay のトップページ developersday/ 配下に各年ディレクトリを作成、developersday/ から各年のトップページを読みに行くような設計にしました。 developersday/ ... developersday/2022/ 配下のファイルをインクルードするだけ ├ 2020/ ... 別ドメイン配下にあったページを移設 ├ 2021/ ... developersday/ 直下にあったページを移動 ├ 2022/ │ ├ index.php ... トップページ（申込フォームなど） │ ├ broadcast/ ... 配信ページ │ ├ comingsoon/ ... 集客が始まる前にトップページに表示する Coming soon ページ │ ├ devhunters/ ... キーワード入力キャンペーン用のページ │ └ login/ ... ログインページ ├ broadcast/ ... developersday/2022/broadcast/ 配下のファイルをインクルードするだけ └ login/ ... developersday/2022/login/ 配下のファイルをインクルードするだけ 集客が始まる前の developersday/ は comingsoon を表示 <?php include_once '～/developersday/2022/comingsoon/index.php'; ?> 集客が始まった後の developersday/ はトップページを表示 <?php include_once '～/developersday/2022/index.php'; ?> 来年以降 <?php include_once '～/developersday/2023/index.php'; ?> 2022/ 配下には社内閲覧のみ可能な制限を入れたので、トップページには Coming soon を表示しつつ、社内からは 2022/ 配下にアクセスすれば集客開始後のページの確認ができるなど、現在の表示と次のライブ確認が重なるような案件でおすすめの設計です。 また、今回2021年のページが developersday/ 直下にあったためアーカイブ化で移動が必要でしたが、次年は次年のディレクトリをインクルードすれば良いだけなので移動の手間が省けます。 DBにアクセスしない developers.gmo.jp は CMS がインストールされているので、運営チームがセッションのデータを入力したり、エンジニアを挟まずページを更新したりするのに利用しています。しかし後述の配信ページなどはリアルタイムにデータを取得する必要があり、その度に DB にデータを取りに行くと負荷がかかりすぎる可能性がありました（実際サーバーダウンしたこともありました）。 なので DB を介さずデータを取得するため、任意のタイミングで DB のデータを Json に書き込み、データは Json に取りに行くという仕組みにしました。 タイムテーブルのセッションをクリックするとモーダルが開いて詳細が見られるのですが、これも Json ファイルのデータを読んでいます。最初は DB に取りに行っていたのですが、Json に切り替えたことでモーダルが表示されるまでの時間も体感1～2秒早くなりました。 配信ページ 一番仕様が複雑だったのは配信ページでした。 去年リリース直前で問題が発生したので、事前に本番環境で動作確認がしたい2トラックを並行配信、タブで切り替えられるイベント開催前・開催中・開催後でコンテンツが変わるリアルタイムに現在配信中のセッション情報が表示されるセッション中、配信終了直前にアンケートを表示する各セッションが終了するとアーカイブに移動、アーカイブタブから視聴・アンケートに回答できるようになる 事前の動作確認 配信ページはイベント開催前は「Coming soon」を表示させる仕様だったのですが、同時に開催中の配信画面の動作確認を行いたいというのが依頼者の希望でした。 こちらに関しては前述の通り、developersday/broadcast/ では developersday/2022/broadcast/comingsoon/ をインクルードし、社内のみ developersday/2022/broadcast/ にアクセス許可することでエンドユーザーに配信画面を見せることなく動作確認が可能となりました。 2トラックを並行配信 今年はオフラインセッション（会場でリアルタイムに開催される対談）＝ TrackA とオンラインセッション（事前に録画した動画を配信）＝ TrackB の2トラックが並行配信されたため、配信画面で切り替えられるようタブが設置されていました。タブの切り替え自体は難しいことではないですが、視聴していない方のタブに現在配信中のセッションタイトルが表示されるという仕様をどう実装するかで迷いました。 最初は JS で Json を読み込み時間になったら切り替えるというのも考えたのですが、JS の場合ユーザーの環境によって時間がずれる可能性があるため、時刻が関わるデータの取得は全てサーバー側で実行することにしました。そのため、JS では1分ごとにサーバー（Json）にデータを取りに行き、返ってきたデータを出力するという処理のみ実施しています。 時間でコンテンツが変わる イベント（最初の配信）が始まる前、配信中、配信終了後で「開始までお待ちください」「終了しました」などコンテンツを変える必要がありました。結果的には配信ツールの方で動画内に表示ができたので不要だったのですが、配信動画自体がぎりぎりまで来ず仕様が不明だったため、現在のステータスを取得・ステータスごとにコンテンツを切り替えるという処理が入っています。 DAY1 配信前DAY1 配信中DAY1 配信終了～DAY2 配信前DAY2 配信中DAY2 配信後 リアルタイムに現在配信中のセッション情報を表示 上記の「2トラックを並行配信」の通り、JS で1分ごとにデータを取りに行く処理の中に含まれています。取得元を DB から Json に変えたことで処理はだいぶ軽くなってはいましたが、数百人のユーザーが1分ごとにデータを取りに行くのは負荷的に大丈夫なのか？という不安があったため、できる限りデータを取りに行く処理はまとめ、返ってきたデータを元に JS で表示を変えるような実装となっています。 負荷については、事前に負荷テストを行う予定ではあったのですが実装が間に合わずぶっつけ本番となりましたが、結果的には問題ありませんでした。 セッション中にアンケートを表示する 今回一番ネックだったのがこちらの処理です。各セッションの終了7分前から終了時刻までアンケートへの回答を促すバナーを表示という仕様でした。 バナーは押下するとアンケートフォームが開き、「×」ボタンを押下すると縮小するという仕様です。縮小した状態を押下すると再度バナーが開きます。時間通りにバナーを表示する処理自体は上記の1分ごとにデータを取りに行く処理に含められたのですが、逆に1分経つと状態がリセットされるということになってしまいました。 仕様を相談させて頂き、最終的には状態を Cookie に保存、最初に表示するときはバナー状態、2回目以降は縮小した状態で表示することになりました。 アンケート表示前（セッション終了の7分以上前）1回目の表示（バナー状態）2回目以降の表示（縮小した状態）アンケート回答済（アンケート送信処理の中で Cookie を更新しています） この場合バナーを拡大したタイミングでたまたま1分ごとのアップデートが走ると一瞬で縮小されてしまうのですが、工数を鑑みて今回はそれで OK となりました。先述の通り Ajax による非同期通信がどのくらいの負荷になるのか読めず、できるだけ通信はしないよう (※) に作っていたのですが、結果あまり負荷はかからないと分かったのでバナーを開閉したら状態を Cookie に保存する処理を入れても良かったかな　と思っています。※JS で Cookie を保存すると PHP で取得することができないので、バナーの開閉と同時に非同期通信し PHP で Cookie を保存する必要がありました。 終了したセッションはアーカイブ化 元々の依頼では各セッションが終了したら一覧に都度加わる　という仕様だったのですが、その場合もセッションが終了したかデータを取りに行く＝非同期通信が走るため、最初から全てのセッションを表示・トリガーを押下して初めて通信が走り、そこで取得するデータで終了済か分かるような仕様に変えて頂きました。 開催日やカテゴリーなどでセッションを絞り込むことができるのですが、この実装が一番時間がかかったかもしれません。全て押したら All が ON になってそうでなければ All は OFF になってそれが4種類あって同時に AND 検索で……　という複雑な仕様だったためトップページの「TIME TABLE」にある絞り込み処理をそのまま流用することができず、結局 Ajax を使って PHP 側で処理させる形になりました。 ログインページ・スタンプラリーページ ログインとスタンプラリー機能はシステム側で API を実装、組み込んだページです。今回システム側は最低限の工数・できる限りノーコードで実装するため、通常 DB を使用するところを Microsoft Lists に置き換えて実装していました。 今回システムが関わったのは、申込フロー・リマインドメール・ログインフローの3点です。 水色がシステム、黄色がフロントエンド の実装が必要な部分です。 申込フロー 登録処理自体は RPA が実行してくれるので、フロントエンド側は入力項目を指定のメールアドレスにメールするだけという簡単実装でした。 ユーザーが集客ページの申込フォームから項目を入力するフォームを送信すると指定のメールアドレスに入力項目が送信される届いたメールの内容から RPA が必要なデータを読み取り、Lists に保存同時にアカウント情報を埋め込んだQRコードを発行し、ユーザーにQRコードを添付したメールを送信 リマインドメール イベント開催が近付くと、登録ユーザーにリマインドメールを送信するという処理です。こちらについてはフロントエンド側は作業無しでした。RPA を介して Lists から参加者データを抽出し、任意の日時にQRコードを添付したメールを一斉送信するという機能でした。 ログインフロー 今回オフライン開催（会場参加）とオンライン開催（ブラウザで視聴）を同時開催するため、オフラインではメールに添付したQRコードを端末で読み取って判別、オンラインではログインフォームから入力して判別という2つのフローがあります。 オフライン（会場参加） ユーザーがメールに添付されたQRコードを表示、運営が端末で読み取るQRコードに埋め込まれたアカウント情報を Lists と照合し、入館可能か判別する結果を端末に返し表示する オンライン（ブラウザで視聴） ユーザーがログインフォームからメールアドレスを入力メールアドレスをAPIに送信、Lists と照合し、有効なメールアドレスか判別する返ってきた結果によってログイン、またはエラー処理を実行する 課題 概ね順調に進んだ一方、いくつか課題は残りました。 スケジュール管理 配信ツールの決定・検証用コードの発行・システム側の実装など各作業に細かく期限を設定していたのですが、全てが揃ったのはライブアップ前日とぎりぎりのスケジュールでした。 ミーティングごとに議事録は残していたものの見返す機会が少なく、またまとめて見ることができないため、あらかじめガントチャートのような形で用意しておくべきだったと途中で気付きました。予期せぬ遅れが発生することを前提に、全員が他のメンバーの進捗を俯瞰できる場を作っておくべきでした。 アンケートが表示されない 配信中、各セッションの終了7分前から終了時刻までアンケートが表示されるのですが、リアルタイムのチャット欄では「アンケートが表示されない」というコメントを多々見かけました。その場で検証を実施し、運営メンバー以外も巻き込んであらゆるデバイス・ブラウザで配信ページを見守っていましたが、結局その場では全ての環境で想定通りアンケートが表示されたため（もし実際にアンケートが表示されない環境があったとすれば）原因不明となってしまいました。 技術的な原因が見付からなかった一方、人為的な原因があったのでは？という仮説が挙がりました。それはセッション終了時にアンケート回答を促すアナウンスでした。前述の通り、アンケートの表示は終了7分前から終了時刻までという仕様でした。そのためセッションが伸びた場合、終了時にアナウンスがされる頃には既にアンケートが消えているということになります。特に会場参加のユーザーはセッションが終わってからWebページを開くので、アンケートを一度も目にすることも無かったのではないかと考えられます。 事前準備の段階では「オフライン開催の方はオフライン担当、オンライン開催の方はオンライン担当」というところがあり、双方の仕様に噛み合わないところがあったというのがアンケート問題の大本の原因だったのではないかと考えています。実際のセッションの流れをフロントエンド側も把握しておくべきだったと思います。また、配信ページ内に置くのではなく独立したアンケートページを用意しておくなど予期せぬ事故が起きても他が動くよう、機能を切り離すべきでした。 配信中に機能停止してしまった 今回一番の課題はリクエスト過多で機能停止してしまったことでした。短時間のアクセス集中に耐えられず、受付からスタンプラリーまで全てが停止してしまい配信中に改修作業を実施しました。 こちらについてはシステム側で精査しているようですが、フロントエンド側でもなるべく負荷をかけない実装を心掛けるべきでした。例えばスタンプラリーページはアクセスの度に RPA にアクセス・ログイン判定を実施していたのですが、途中で結果を保存し RPA へのアクセスを減らす仕組みに変更しました。 まとめ ひとまず終わって良かったと同時に、ああしておけば良かったという反省点も多くあります。去年一番の課題だった「事前確認」が今年は解消された一方で、また新たな課題も発生しているため、来年に向けてブラッシュアップを重ねていきます。

GMOインターネットグループとして、PHPerKaigi 2023にダイヤモンドスポンサーとして協賛いたします！今年のスポンサーセッション企画や、ブース、ノベルティ情報についてご紹介いたします。 PHPerKaigiとは？ PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、現在PHPを使用している方、​過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。​ 歴戦の勇者みたいな方はもちろん、初心者の方にも、全てのPHPerが楽しめるイベントです。 イベント概要 開催日：2023年3月23日（木）24日（金）25日（土）会　場：オン＆オフライン（@練馬区立区民・産業プラザ Coconeriホール）主　催：PHPerKaigi 2023 実行委員会参加方法：チケット購入制（チケット購入はこちらから）公式HP：https://phperkaigi.jp/2023/ ［スポンサーセッション］GMOインターネットグループ 株式会社 成瀬の挑戦状  2023年3月25日（土）16:10-16:30＠TrackA　成瀬 允宣 スポンサー企画「成瀬の挑戦状」にグループメンバーが挑戦！果たして完全クリア者は現れるのか！？実況と解説は成瀬がお送りします。こちらのセッションはスポンサー企画「成瀬の挑戦状」と連動しております。セッションでは解答解説も行います。みなさまもぜひ「成瀬の挑戦状」に挑戦して、メンバーの四苦八苦する姿をお楽しみください。https://fortee.jp/phperkaigi-2023/proposal/a09f4efc-b92b-4c85-81bd-07a4d30445a9 GMOインターネットグループテックリードの成瀬が○Tuberに！？いつもと一味違うセッションをお楽しみに！ また、スポンサーセッション終了後 同日16:45-17:10＠TrackB で成瀬本人登壇による「PHPerチャレンジ解説セッション」の開催が決定しました！ 併せて、ご参加ください！ ［スポンサーセッション連動企画］成瀬の挑戦状_あなたは何問解けますか？  スポンサーセッション「成瀬の挑戦状」劇中に登場する「挑戦状（問題）」はどなたでも（PHPerkaigi2023に未申し込みの方も）ご参加いただけます！全問正解した方には抽選で豪華景品をプレゼント！奮ってご参加ください。 解答受付期間：2023年3月22日 10：00～2023年3月25日 16：00 まで 2023年3月22日 10：00～「成瀬の挑戦状特設サイト」公開https://developers.gmo.jp/event/phperkaigi2023 ［cfpセッション］GMOペパボ 株式会社 Win Testing Trophy Easily / テスティングトロフィーを獲得する 2023年3月24日（金）11:15-12:05＠TrackB　小山 健一郎 「Testing Pyramid（テスティングピラミッド）」皆さんも聞いたことがあるのではないでしょうか？テストレベルごとにテストの量（数・実行）を上層ほど小さく下層ほど大きく（ピラミッド型に）すると良いというコンセプトです。一方、React Testing Libraryの作者であるKent C. Dodds氏は「Testing Trophy（テスティングトロフィー）」というインテグレーションテストに最も重点をおいたテストコンセプトを提唱しています。発表者はあるAPIサーバの開発にあたり設計時点でテスティングトロフィーを目指す決定をしました。本発表では「なぜそれを目指したのか（選択したアーキテクチャからテストコンセプト決定まで）」「いかにそれを実現していったか（インテグレーションテストを軽量に追加する仕組みでコストに対抗する）」について紹介したいと思います。https://fortee.jp/phperkaigi-2023/proposal/90c0d39b-108b-4104-b93e-f7e0711003c6 ［cfpセッション］GMOインターネットグループ 株式会社 初めてIT勉強会を開催するなら知っておくべき5選！〜PHP勉強会@東京や社内勉強会の運用からの知見〜  2023年3月25日（土）15:20-15:25＠TrackA　向井 賢一 PHPerKaigiで得た知見を社内に共有するために、勉強会を開催しようと意気込んでる方！実際の会場で勉強会をしたいが、何かトラブルがおこらないか不安な方！そんな方に、リアル会場でのイベント運用方法から機材の事、5選です！内容は、PHP勉強会@東京や自社の社内勉強会で実践・運用している事です。●運用集客、タイムテーブル、参加者の満足度を上げる方法など、運用して成功、失敗した事。●機材プロの配信エンジニアに教えてもらった、よくおこるトラブルの対処法で、私がおこなっている事。20分発表とLTは違う種類のマイクを使った方がいい？実は、ハンドマイクは扱いが凄く難しい。では、扱いの簡単なマイクの種類とは何か？発表者の持ち込みPCがスクリーンに映らないトラブルを減らす方法は？トラブルが起こりにくいメーカーのケーブル、コネクタ、コンバーターの紹介。https://fortee.jp/phperkaigi-2023/proposal/9e758cbe-9a7a-4d3f-83a9-64f8a2d9a42d ［オフライン会場限定］ブース出展 2023年3月24日（金）～3月25日（土） 会 場：@練馬区立区民・産業プラザ Coconeriホール オフライン会場ブースでは、スポンサーセッションとの連動企画「成瀬の挑戦状_あなたは何問解けますか？」特設ブースを実施予定！ブースでは挑戦状考案者のGMOインターネットグループ株式会社 テックリード 成瀬本人が、先着で「直筆挑戦状」と「特製ノベルティ（キーホルダー）」をプレゼントいたします。 企画に参加し、是非是非Getしてみてください！ ※オンライン参加の方も 「成瀬の挑戦状_あなたは何問解けますか？」 に参加可能です。ノベルティご希望の方はオフライン会場にお越しください。 ※新型コロナウイルス感染症感染拡大防止に関してご協力をお願いいたします。また状況に応じて直前でオフライン会場での開催を見送る可能性もございますのであらかじめご了承ください。 #PHPerチャレンジトークン PHPerチャレンジトークンをお探しのみなさまへヒントをお伝えいたします！2023年GMOインターネットグループが設定しているトークンは全5種！ 以下に、うち1つのトークンを設置いたします。 # 一味違うセッション さいごに 本スポンサーセッションは従来の「視聴する」だけではなく、「視聴者参加型の連動企画」を開催します！ご参加いただく上で、より楽しめるノベルティやブースもご用意しておりますので、是非参加をご検討くださいmm 本年度も企画盛沢山なPHPerKaigi！当日皆様とお会いできることを楽しみにしております！

本記事では、技育祭について紹介しています。2023年3月18日（土）から19日（日）までの2日間にかけて開催し、参加は無料です。GMOインターネットグループからは講演と企業LTがあり、エンジニアの育成や活躍事例について紹介します。さらに、新作CMの公開も予定されています。詳細は下記内容をご確認ください。 技育祭とは 技育祭は、GMOインターネットグループも年間協賛している「技育プロジェクト」の１つで、「技術者を育てること」を目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。 イベント概要 開催日：2023年3月18日（土）～3月19日（日）会　場：オンライン運　営：株式会社サポーターズ参加費用：無料（事前登録制）公式HP：https://talent.supporterz.jp/geeksai/2023spring/ GMOインターネットグループからの登壇 講演　DAY1 / 3月18日(土) 12:40-13:25 「GMOのオールライトニッポン！ 〜若手エンジニアが現場のリアルを語ります〜」 ◆登壇者・GMOペパボ株式会社 シニアエンジニアリングリード　黒瀧 悠太＜新卒1,2年目エンジニア＞・GMOペパボ株式会社　中田 輝・GMOインターネットグループ株式会社　火箱 力・GMOアドマーケティング株式会社　岸田 優輝 リードエンジニアと新卒エンジニアが登壇。入社1年それぞれの過ごし方から圧倒的No.1を目指すグロース戦略はもちろん、就活のハック法やポートフォリオ、企業選びのコツといった、みなさまのお悩みまで本音で答えます！ また、講演の中でお悩み相談コーナーを用意しています。みなさまのお悩みを大募集！Twitter「#GMO悩み相談」でラジオ風に質問を投稿してください！質問が講演内で採用されたら、Amazonギフト券プレゼント？！！ 企業LT　DAY2 / 3月19日(日) 10:30〜11:30 GMOインターネットグループ株式会社 インフラ・運用本部 クラウドサービス開発部 長谷川 泰斗 調整中... 新作CM公開予定！ 「まじめにベンチャー。まじめにギーク。 」〜福利厚生を使い倒しながら語る人編～ 主演：GMOインターネットグループ株式会社 長谷川 泰斗 今回の技育祭2023春のために新作のCMを制作中です！GMOインターネットグループにはさまざまな福利厚生があります。その福利厚生を使い倒しながらもまじめに技術と向き合うエンジニアの姿をお楽しみに！ さいごに 学生のみなさまのご参加をお待ちしております！ https://talent.supporterz.jp/geeksai/2023spring/

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。今回は1日目にオンラインで開催された「「お名前.com」チームのコラボレーション方法」をご紹介します。 登壇者/スピーカー 近岡 麗華GMOインターネットグループ株式会社事業統括本部Webプロモーション研究室クリエイティブチーム リードデザイナー GMOインターネットグループが運営する『お名前.com』は国内最大級のドメイン公式登録サービスです。.com .net .jpドメインなど、580種類以上のドメイン取得が可能で、さらにドメインを活用できるサービスも用意しています。 本セッションでは、そんな大規模サービスである『お名前.com』のデザイナーとしてWebサイト運用時に感じた課題と、改善するため取り組んだ施策からその成果まで、Webプロモーション研究室クリエイティブチームでリードデザイナーを務める近岡が話しました。 管轄が細分化されコラボレーションしづらさが課題に 普段はWebデザインを中心に行っている近岡は2017年にGMOインターネットグループに入社。グラフィック制作や撮影ディレクション、アニメーション制作、Webサイトのワイヤーフレーム作成やデザイン、進行管理など、その業務は多岐に渡っています。 近岡が担当する『お名前.com』はドメインだけでなく、ドメインを活用する上で必要となるレンタルサーバーやデスクトップクラウドなどを包括して購入できるのも特徴です。 サイト全体を現した構成図は以下のようになっています。 ドメインやレンタルサーバー、デスクトップクラウドなど、それぞれにサービスサイトが設けられており、お客様へご購入いただくフローへとご案内します。さらに購入後の管理画面にも遷移されるようになっています。 現在、ドメインやレンタルサーバー、デスクトップクラウドなど、それぞれのサイトにデザイナー・エンジニア・マーケターが配備されている組織構造で運用は行われています。 このように大きな組織で、管轄が細分化して担当を設けてサービスを運営すると起こりやすい課題として、デザイナー同士や、デザイナーとエンジニアが、コラボレーションしづらいという事が起こります。 一体、どの位、管轄は細分化されて煩雑になっているのでしょうか？以下は、近岡の管轄を現した図になります。 近岡はレンタルサーバーを中心に管轄しているのが分かります。それに対して、以下は、デザイナーBさんの管轄です。 デザイナーBさんは、ドメインを取り扱うサイトを中心にデザイン業務を行っています。そのため近岡が手掛けるレンタルサーバーのサイト領域に対して、何を行っているのか分かりづらいといったことが起こりやすくなります。 さらに以下はインフラエンジニアCさんの管轄です。 Cさんはサービスの管理画面のエンジニアリングが中心となっています。そのためサービスサイトのことは良く分かっていないということも起こります。 コラボレーションを促進する、職種を越えた「改善MTG」 近岡は、このように管轄下が異なる担当者同士がコラボレーションしづらいといった課題にどう向き合ったのでしょうか。まずWeb制作のフローについて整理したいと思います。 一般的なWebサイトの制作フローは以下の通りです。 今回、近岡が課題として改善したいと話す領域は「調査」「設計」のフローの部分。複数あるサイトを持つ『お名前.com』で、それぞれ担当が細かく分業化されることで、他ページで起こっていることが互いに把握できておらず、コラボレーションで生まれづらいことを解消することが目的です。 そこでエンジニア、CS（カスタマーサポート）、マーケターなど、それぞれヒアリングしてサービス改善につなげていく「改善MTG」を週次で実施することにしました。 近岡によると、改善MTGを実施すると、それぞれが担当する領域や職種で視野が、全く違うということが浮き彫りになったといいます。 例えば、近岡をはじめとするデザイナー側は、「サービスサイト全体のUIを統一したい」という意見を提示するも、CS（カスタマーサポート）からは、（サイト上の）お客様から問い合わせ導線が分かりづらいという声が寄せられており「お問い合わせ導線の枠を大きくしたい」といった話が出てきました。 マーケターからは「需要の高い機能を目立たせたい」という意見、エンジニアからは現行の仕様の裏側で実行したくない処理があるため「シンプルなコードに書き換えたい」といった話など、職種を横断して意見を集約していくと、サイト上で、それぞれが抱えている課題が見えてきました。 こうして意見を集約することでデザイナー側から、他の職種が抱える課題解決にもつながるデザイン提案を意識して行うことができるようになったと話します。それぞれの職種が、「お客様に分かりやすいサイトを提供しよう」と一丸となり、ノウハウがシェアされるなど好循環が生まれて、デザイナーからの提案にも深度が深まっていきました。 デザイナー同士の共同作業を支える「クラウドドキュメント」 デザイナー同士で、起こっていた課題もあります。個々にデザインが統一されずバラバラで、デザイナー同士の共有コストは上がっているが、運用効率は下がっているという悪循環が起こっていたのです。 そこでクラウドドキュメントで「モジュール」を一元管理することで、改善につなげました。以下は、『お名前.com』のレンタルサーバーのサイトで実際に活用されているクラウドドキュメントです。 ツールはAdobe XD のクラウドドキュメントを使用しているといいます。こうして一元管理することで、複数のデバイスからの共有や、他のデザイナーとの共同作業、バージョン管理が可能になります。 新しいデザイナーが入社後もこのクラウドドキュメントに則り、デザインを行うことで、経験者であるデザイナーと遜色ないデザインを仕上げることが出来ます。 以下はテキストのルールです。px（ピクセル）単位で細かくルール化したものを文書化して共有しています。 こうしてデザインガイドをクラウドドキュメントで共有することで、デザイナー同士はもちろん、デザイナーとフロントエンド実装のエンジニアまで、なんとなくといった感覚で実施するデザインを減らして、お客様がサイトを閲覧した時に、色々なページを見比べても違和感をつくらないように意識しています。 マイナスを減らして、仲間の引き出しを取り込む！がポイント コンポーネントやコンテンツの自動調整をしてくれるスタックを使うことで、デザイナー同士のデザインレートを短縮する工夫も行っています。 また誰でも新規パーツがつくれるような土台も準備しているといいます。そちらもドキュメントで管理してノウハウがシェアされている仕組みですが、それにより「モジュールリスト」にないパーツは作れないのか？といったデザイナーの閉塞感を軽減して、全員でノウハウをシェアしてひとつのサービスを創っていく方向性でデザイナー同士の意欲も高めることができます。 もちろん共同編集ができるとモジュールが重複することなど弊害も生まれます。そこでモジュールリストの取扱説明書となるドキュメントでルールを策定して、みんなが積極的に気分よく作業できるよう仕掛けづくりを行っています。 ポイントは、複数人でつくるマイナスをへらして、仲間の引き出しを取り込むこと。 こうした取り組みの結果、デザインからコーディングなどの実装までの時間が約7割も削減されたと近岡は話します。その理由のひとつに「モジュールリスト」にすべての要素がある場合、Webサイトのデザインを1から行うことなく、エンジニアと相談の上で、デザイン不要でコーディングなど実装に着手してもらうことが可能になったためです。デザイン業務に割く時間が短縮されたことで、LPサイトなど他のサイト制作へ時間を充てることができるようになりました。 モジュール化しないページも一定数もうける 本施策はデザインレートの大幅削減にもつながりました。それでは全てをモジュール化すれば良いのでしょうか？しかしそうすると遊びがゼロになり、閲覧する人にとってガイドブックのような事務的なサイトになってしまうと、近岡は話します。 そこでデザイン的な解決を行います。例えば、画像の枠組みだけを指定して、その中にはどのような画像も入れて良いとする。いくらでも自由に遊べる領域を持たせて、アニメーションや画像で奇抜なレイアウトを作ってみるなど、そうしたサイトでは閲覧するお客様にとって興味関心を持ってもらえるよう意識しています。 そのためモジュール化しないページを一定数用意しているといいます。LPのようなサイトや、より優先してお客様へ情報を伝えたいページをモジュール化しないことが多いといいます。 2019年、『お名前.com』ではレンタルサーバーを1億円かけて改修したにも関わらず、比較サイトなどで周知されておらず、競合にスペックで劣って見えてしまっていました。以下のLPページは、1億円かけて改修したことを認知してもらい、新規申込者へ訴求する目的で立ち上げられたサイトです。 サイトはレスポンシブで作成することが多いため、エンジニアと相談しながらデザインを固めていきます。フロントエンドエンジニアにデザインを渡す際には、演出的なガイドを細かく設置して、ボタンなどの挙動については、挙動を指定したアートボードにまとめているといいます。 Xdパーツというアートボードを組み、LPでも挙動を分けて保存しています。モーションの指定をするとき、参考URLをエンジニアに渡して動きを組んでもらうといいますが、伝えづらい動きのものは、近岡自身で動きをカスタマイズしたコードを組んでエンジニアと脳内リンクさせるミュニケーションの取り方も行っているといいます。 お客様がページを見るときに、気にされるのは容量という部分です。お客様の通信に悪影響やSEOによくなかったりもするので、できるだけレスポンシブで同じ素材を表示するようにコーディングで実装ができるようなレイアウトを意識して、本サイトのデザインは考えたと話します。 さいごに 管轄が細分化されコラボレーションしづらい組織のコラボレーション促進として「改善MTG」が有用だったという話し、さらにデザイナー同士、またデザイナーとエンジニアのコラボレーション促進として「クラウドドキュメント」や「モジュールリスト」の話しなどを本セッションではいただきました。 『お名前.com』の裏側では、メンバー同士が視野をシェアするなどコミュニケーションをたくさん持ち、作業はできるだけ削減する。そして削減した時間でLPサイトなどを制作して、サービス全体の質を上げていく取り組みが行われています。 近岡は「これからもチームで頑張りますので、『お名前.com』を今後もよろしくお願いします！」と意気込みを伝えて、本セッションを締めくくりました。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/523McnYvrwk

GMOインターネットグループでは、2022年12月6日（火）～7日（水）の2日間、開発者向けテックカンファレンス「GMO Developers Day 2022」を開催しました。「GMO Developers Day」は、GMOインターネットグループの最新技術を活用した新しい挑戦や、世の中が抱える課題解決への取り組みを、事例を交えて紹介するテック（技術）カンファレンスです。開催3回目となる今年は「Add on 技術の拡張で、新たな世界へ」をコンセプトに、初のオフラインとオンラインのハイブリッド開催で、全34セッションをお届けしました。GMO Developersではそんな大盛況を収めた同イベントのセッションを紹介していきます。今回は1日目にリアル会場で開催された「データサイエンティスト対談 ～GMOだからできるデータサイエンスとは～」をご紹介します。 登壇者 スピーカー 財津 大夏GMOペパボ株式会社技術部 データ基盤チーム大学で統計や社会調査を専攻して2012年にGMOペパボに入社。ホスティングやECサービスのディレクターとしてデータ駆動マーケティングやサービス運用改善に取り組んだ後、2018 年よりデータサイエンティストとして、ログ活用基盤「Bigfoot」の開発とその利用によるサービス改善を進めている。春田 雅也GMOアドマーケティング株式会社開発本部 開発部 チーフ大学で情報工学を専攻していたが、途中で機械学習について興味を持ち、進学した大学院では機械学習の応用研究を行う。2020年4月にGMOアドマーケティングに新卒入社。GCPをはじめとしたクラウド周りのバックエンドを担当してインプットに励みつつ、主力プロダクトの「AkaNe」の広告配信やアドテクに携わる。一方で、広告最適化の一環として自然言語処理モデルの改修や掲載順位最適化モデル構築など、機械学習エンジニアとしても活躍している。石地 睦GMOペイメントサービス株式会社ビジネスインサイト部 部長コンサルタントなどを務めてテック業界で経験を積んできた。2016年に決済処理サービスを提供するGMOペイメントサービスに入社。所属する決済事業推進統括部 ビジネスインサイト部は、事業の継続的な成長を支えることをミッションに、決済市場のドラスティックな変化や、サービスを提供する上で日々起こるリアルタイムの課題にスピーディーに対応するため、ビジネスサイドにも寄り添い、データ分析を活かして開発を行っている。 モデレーター 佐野 唯一郎GMOインターネットグループ株式会社グループ研究開発本部AI研究開発室データ解析 AI研究グループ マネージャーSlerやコンサルタントなどテック業界で色々な経験を積み、2015年にGMOインターネットグループに入社後、グループ研究開発本部（旧：次世代システム研究室）に配属。一度、グループを離れた後、2020年に再度入社して現職。グループ研究開発本部ではグループ横断プロジェクトにおいて、データサイエンス技術などを用いて技術支援・開発・解析などを行っている。機械学習エンジニアを中心に、サーバーサイドAPIなど多岐で活躍。Androidアプリの公式言語Kotlin（コトリン）にハマっている。 GMOインターネットグループ 佐野、GMOペパボ 財津、GMOアドマーケティング 春田、GMOペイメントサービス 石地 GMOインターネットグループだからできるデータサイエンスとは何か？それを考えるカギとなるのはグループ全体が手掛ける事業領域の広さにあります。 GMOインターネットグループはドメインからセキュリティ、決済までビジネスの基盤となるサービスをご提供するインターネットインフラ事業を主軸に、インターネット広告・メディア事業、インターネット金融事業、暗号資産事業を展開する総合インターネットグループです。お客様に喜ばれるサービスを迅速かつ低価格で提供するために、サービスは機器の選定から設置、構築、開発、運用までを内製化することを基本方針としており、グループ全110社に在籍する7,200名超のパートナーのうち、ITのモノづくりを担う開発者（エンジニア・クリエイター）は49.9%（※数字はいづれも2022年9月末時点）を占めています。 そんなGMOインターネットグループには、データ分析やAIを活用はもちろん、グループ各社が横断的にデータサイエンス技術を提供し合うプロジェクトもあり、さまざまな領域のデータサイエンティストが、日々、お客様へより高い価値を提供すべく活躍しています。今回は、Ｅコマース、広告、決済・金融と、グループ4社から色々な立場のデータサイエンティストが集まりました。MLなど開発の裏側はもちろん、業務を行う上で大切にされていることをお聞きして、データサイエンティストが果たす役割から、今後の展望までを話しました。 いま注目しているデータサイエンス技術とは？ モデレーターを務める佐野が、それぞれ立場が異なる3名に話しを聞く形式でセッションはスタートしました。先ずはそれぞれ自社プロダクトに携わるなかで、いま注目しているデータサイエンス技術について問いました。 XAI（Explainable AI：説明可能なAI）ですね。3年前まで学生という立場では、機械学習モデルをより高精度にしていくアプローチに注力していました。それがAIをビジネスに適用するうえでは、なぜ精度が高くなったのか、お客様に納得できる判定根拠を「説明」できるよう求められます。広告運用ではモデル全体の精度より、特定の媒体様にどのような条件が判定に寄与しているか説明できなければなりません。そうしたことからXAIに着目しています。春田 GMOアドマーケティング 春田 佐野XAIの代表的なものとして「SHAP」（シャップ）というものがあります。各特徴量が結果に対してどのように寄与しているのか、それがプラスかマイナスなのかと特徴量間での利得配分によって説明します。広告だとCTR（クリック率）など予測するのに、最先端なアルゴリズムも出ていますが、説明性といったところをXAIなどで人がサポートしていくことが重要なんですね。XAIはゲーム理論が起源で、経済学部出身の私からすると親近感がありますね。Eコマースの領域に携わっている財津さんはいかがでしょうか？ GMOインターネットグループ 佐野 GMOペパボはクリエイターさんがイラストを登録してオリジナルコップやTシャツなど、オリジナルグッズ・アイテムの作成・販売ができるプラットフォーム「SUZURI」というサービスがあるなど、イラストレーターなどクリエイターさんに使っていただくサービスが多いという点から「生成系」に興味を持っていますね。2010年代からGAN（敵対的生成ネットワーク）などもあり、最近は人が書いたものと遜色なくリアルな画像生成が可能になっていたりします。そのなかで2つパターンがあると思います。ひとつは入力と出力が違うもの。「テキスト」を入力すると「画像」を出力するものです。もうひとつは入力と出力が同じもので、「画像」から「画像」を生成するといったものです。前者は絵を描けない人でも、テキストベースで絵を書けるようになるなど、表現の幅が広がると思います。後者は絵を描ける人が、自身の画風を学習させて、表現の新たな技法や可能性を広げることに繋がります。そうしたことから興味を持って追いかけています。財津 GMOペパボ 財津 佐野いまチャットボット「ChatGPT（チャットジーピーティー）」（※OpenAIが2022年11月に公開）が大きな話題になっていますが、1年以上前に発表されたGPT-3（2020年7月）から、自然な文章が生成できると大きな話題になっていました。私もコードを生成してすごいと衝撃を受けましたね。そのコードがそのまま使えるとは限らないですが、人の思考をサポートしてスニペットを提供するというのは有用だなと感じました。人の活動を後押しするのが生成系AIの意義だという話ですが、一方でデザイナーの方の作品を無断で学習データとして使用することは著作権的な側面はもちろん、倫理的な問題もはらんでいます。その辺り、財津さんはどのように考えられていますか？ GMOペパボとしてやりたいのはクリエイターさんをはじめとした「人の表現活動を支援すること」です。作品を無断で学習データとして使用することが法律的には問題がなかったとしても、サービスに嫌悪感や反感を抱かれてしまうということは多分に起こると想定できます。そうなったら我々は何のために事業を行っているのか分からなくなるので、双方で合意が形成されている学習データを担保していくというのが、生成系AIを導入させる上では、大切なことだと感じます。 財津 佐野私も自分の書いたコードが勝手に使われて「出力」されたら、嫌だなと思うかもしれないですね。我々はお客様第一なので、いくら優れた生成系AIだとしても、お客様が不快になることはしてはいけないと考えます。堅牢性が求められる決済サービスに携わる石地さんはいかがでしょうか？ 石地堅牢性という点では、弊社のような決済サービスではAIが誤った判定をすることは絶対に避けなければいけませんね。いま着目しているのはデータ間の関係から、人が見えないかたちでデータを表現していくことです。我々のサービスをご利用いただいているグループ・集団のデータでの表現力が高いほど精度が高いモデルが作れるのではないかと考えています。そこでグラフニューラルネットワーク（GNN）を用いてグラフ化して、そこから特徴量を創り出していくことで、見た目のデータからは出来ない新たな表現が出てきます。こうした手持ちのデータからポテンシャルを引き出すといったことに、積極的にチャレンジしていきたいと思っています。 GMOペイメントサービス 石地 佐野ータの関係性を表す、グラフニューラルネットワーク（GNN）は、さまざまなシーンで使えますよね。それぞれお3人に注目する技術についてお話しをお聞きしましたが、Developers Dayなので、エンジニア視点で開発面の話も聞けたらと思います。 ML開発時に、それぞれが注意していること 佐野マシンラーニングサービス（MLサービス）や、それに関わるデータ分析基盤の開発時に皆さんはどのような事を注意しているか、エンジニアの一人として、すごく聞きたいです。要件を定義して開発からルールベースで動いてくれるWebアプリ・モバイルアプリと、MLサービスを比べると大きな性質の違いを感じます。MLサービスではプログラム開発時は正しかった概念が、パラダイムシフトしていき、将来的にデータのドリフトや分布が変わっていくことにも適応していかなければいけない。そんなML開発で皆さんが意識していることは何かが気になります。 広告最適化では、ユーザーに広告を掲示するまでの速度が重視されます。新しい機械学習モデルを導入した際、既存のプロダクトに悪影響は出さないのはもちろんですが、最適化から掲載までのスピードは意識されていて、0.1秒単位の世界と言っても過言ではありません。そのため学習コストや予測コストが高すぎるものは性能要件に引っかかって導入できないケースというのも多くあります。春田 石地サービスに悪影響を与えてしまったら本末転倒ですよね。ローカルの環境でモデルつくるとパフォーマンス重視になりがちですが、それが実際の環境下では負荷になったりするので、パラメーターチューニングを何度も行いました。またAIに学習した以上のことを逆にして欲しくないですよね。開発側とAIを活用する分野の範囲を明確化しています。常にフレッシュなデータ、フレッシュなモデルを渡しつづけないといけないので、それらがクイックに出来るよう、開発に着手する時点でシステム側と運用方針も決めました。AIを実装したことで、アプリ側の開発部隊の作業依頼などの負荷の増加も起こしていけないと思うので、そこにも注意しています。 佐野確かにそうですね。皆さんのお話しを聞いて、業種は違えど、割と抱えている問題は一緒だなというのを感じます。開発から運用の話に近い話になりますが、開発したものを継続していくなかで、クリーンに保っている知見をお聞かせいただければと思います。 ペパボの開発体制は事業部制なので、サービスの運用・開発をしている事業部と、私たちのデータ基盤チームがいます。複数人で開発をすることでクリーンに保つことを推進するために、データカタログのようなドキュメンテーションを基盤チームの方で整備して、みんなで勉強していくことで、開発も運用もしやすくなる施策を行っています。Googleの「Vertex AI」は検証中ですが、自分たちが使うワークフローエンジンを使って、ビジネスサイドも含めて、精度を見ながら、どうやってモデル改善しようか議論するところまで運用として回せることを心掛けていますね。 財津 佐野機械学習はデータを得て結果が生まれるので、お客様にタッチする立場のビジネスサイドを巻き込まないといけない。そのためにドキュメントや資料の準備は、非常に重要ですね。 データサイエンスが、日々、大切にしている技術検査 佐野次にデータサイエンティストとして、どのように技術検査をしているか。インプットとアウトプットの方法はいろいろあると思いますが、伺ってみたいと思います。 石地オンライントレーニングを多用して学習しています。いまではさまざまな企業や大学がMLをテーマに講義や学習コースを提供してくれていますね。私は以前、「edX」（ハーバード・MIT主導のMOOC）を受講していました。オープンデータを渡されて、学んだことから分析レポートを提出する課題があるのですが、受講生のなかから、相互レビューをして3人以上からレビューをもらえないと、次に進めないカリキュラムになっています。そこでそれぞれレビューし合うのですが、同じデータでもこういうアプローチの仕方があるのだと発見があり、学びが深まります。レビューで褒められると素直に嬉しいですし、分析アプローチが甘いんじゃないかと辛辣なコメントもありますが実務に近く感じられる。そうしたコミュニティのなかで学習できたことは大きな経験になると思いますね。 佐野「edX」いいですね！エンジニアとして、コードをどうキレイに整えていたか、あらためて考えると同じ仲間のソースコードレビューってめちゃくちゃ大事だと思っています。パーフェクトで提出したものに、いろいろな訂正が入って、それを何十回何百回、何千回と繰り替えてして、いまに至っている実感があるので、データサイエンスでも、そうしたレビューは成長につながると聞いていて感じました。春田さんはどうですか？ 普段はプライベートな勉強会と称して、週1回、人を集めて、勉強会を開催しています。そこで機械学習関連の技術書を選んで、具体的な機械学習の手法や機械学習のモデルを組むときのパターンの習得など、皆で学んでいます。春田 私も機械学習関連の技術書を読むことが多いです。手法的なところだと「Kaggle（カグル）」でスコアが高いレポートを読んだり、機械学習関連のニュースを見て、キャッチアップしています。 財津 佐野レポートを読むだけでも新しい発見につながりますね。「Kaggle（カグル）」は参加の敷居が高いと思われがちですが、まずそういった所から慣れるというのがいいですね。 さいごに 佐野GMOインターネットグループにはさまざまな分野の技術者がいます。データサイエンティストといっても経歴も多様で、私の同僚ではリサーチャーや研究者からデータサイエンティストに転向する方など、色々なバックグラウンドを持っているというのも、特徴のひとつだと思います。さいごに副題にもなっている「GMOだからこそ挑戦できるデータ分析」を伺ってみたいと思います。 GMOインターネットグループ全体もですが、GMOペパボ内でもECをやっていたり、ホスティングをやっていたりと、幅広く事業を展開しています。そうした適用先が違うデータ分析や機械学習モデルを、どんどん組み込んで実装していくことが出来るのが、私は、いちばん楽しいというか、挑戦できるところかなと思っています。 財津 プロダクトも内製化されていることで、データを使って学習ができる幅が広がっています。またGMOアドマーケティングでは、業務時間の一部をインプットの時間に充てており、その時間で知見やスキルを高めているのはもちろん、得たモデルを実際に試すことができる環境があるのは強みだと思っています。春田 石地データの豊富さを活かすことができる環境というのは大きいですね。自社のサービスや事業が成長していくことでお預かりするデータ数も増えていきます。また変化が早いが早く、スピード感を意識して、実行しなければないことも、たくさんあります。その分、アウトプットは速くなるので、そうした経験が積める環境も、魅力のひとつじゃないかと考えています。 佐野データの量もそうですし、決済もあれば広告もあって、ECもあって、バラエティに富んだデータが飛び交っていて、挑戦できるというのはGMOインターネットグループだからこそですね。私の所属するグループ研究開発本部AI研究開発室は、グループ各社のAI開発のお手伝いをさせていただくことが多いですが、組織も違えば、それによって生まれてくるデータの種類も量も違うので、どういったアーキテクトを組もうか、レコメンドアルゴリズム良いか、それぞれの立場に合わせて常に考えています。そうした多様な分析に携わることは大きな魅力だと思えるところなので、ぜひそういうところにチャレンジしたい方がいらっしゃったら、仲間として、一緒に働ければなと思います。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/Sh0a7bx7ThI