PHPからGoへのマイグレーション for DMMアフィリエイト

by yabako kobayashi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© DMM.com リプレイス後アーキテクチャ工数や影響を考慮して段階的なリプレイスを採用 ● ユーザーの画面を対象 ○ 全ての画面を一気にリプレイスせず、変更後の影響範囲を狭める ● フロントとバックエンドは分離 ○ 既存は密結合している ○ 規模や報酬を扱うことを鑑みると、分離してスケーラビリティや変更影響を限定的にしたい ● DBはオンプレミスをそのまま使用 ○ 報酬(金銭)の取引があるため個人情報が保存されており、クラウド移行に大きな課題がある 8

Slide 9

Slide 9 text

© DMM.com Go採用のモチベーション ❏ 部署内で言語統一の流れがあった ❏ Go言語への統一プロジェクトで進化を遂げる、マーケティングテクノロジー部の決意移管されてきたプロダクト各プロダクトごとに開発言語や環境が異なり、相互に連携してるので複雑度が高い部署の課題古いシステムが多い属人化が激しく、メンテナンス性も著しく損なっているので保守工数が増大 Goへの言語統一 ● システム全体の一貫性の向上 ● エンジニアリソースを流動的に配置生産性/メンテナンス性UP 課題へのアプローチ 9

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© DMM.com アフィリエイトに対するGoの合致度 1. パフォーマンス観点 a. データ量 i. いままで発生した報酬履歴 1. レポーティングなどで使用 ii. 未来に支払いする報酬の計算 b. 負荷 i. 動画などキャンペーン時にはアフィリエイトを通した大量リクエスト 1. 大体300rpsぐらい 2. スケーラビリティ(並行処理) a. リアルタイムデータの集計 b. レポートの生成 11 Goのイメージ ❏ パフォーマンスが高い ❏ コンパイルされたバイナリが直接実行されるため、レイテンシが格段に少ない ❏ メモリ管理が効率的 ❏ スケーラビリティに優位性がある ❏ 軽量なゴルーチン（並行処理）が簡単に使える ❏ シンプルな構造と明確な依存管理アフィリエイト特性に当てはめて検討 Goにマッチしてそう

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© DMM.com Go開発の取り組み(プロジェクト構成) 13 課題1. 記述量増加 // Item構造体を定義 type Item struct { ID int `json:"id"` Name string `json:"name"` Price float64 `json:"price"` } // 指定IDのアイテムを取得する関数 func getItem(w http.ResponseWriter, r *http.Request) { id := r.URL.Query().Get("id") var item Item err := db.QueryRow("SELECT id, name, price FROM items WHERE id = $1", id).Scan(&item.ID, &item.Name, &item.Price) if err != nil { http.Error(w, "Item not found", http.StatusNotFound) return } w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(item) } // 指定IDのアイテムを取得する関数 function getItem($id) { global $pdo; $stmt = $pdo->prepare("SELECT id, name, price FROM items WHERE id = ?"); $stmt->execute([$id]); return $stmt->fetch(PDO::FETCH_ASSOC); } // APIの呼び出し処理 header('Content-Type: application/json'); echo json_encode(getItem($_GET['id'])); Go PHP

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© DMM.com Go開発の取り組み(プロジェクト構成) 15 1. フロントとバックエンドのインターフェース共通化 ❏ OpenAPI定義を元にコードを生成 ❏ 使用ツール ❏ Backend: oapi-codegen ❏ Frontend: swagger-typescript-api ❏ OpenAPI定義とRes/Req構造体を見比べる必要がなくなった ❏ レビュー負荷軽減各リポジトリにサブモジュールとして配置

Slide 16

Slide 16 text

© DMM.com Go開発の取り組み(プロジェクト構成) 16 2. DB操作はSQLによったものを選定 ❏ SQLから生成できるsqlc ❏ SQLクエリの書き方さえ知ってればよいので ORMのメソッドを調べたり、メソッドで表現できない複雑なクエリとで書き分ける必要がない ❏ SQLはメンバー全員慣れていたので好都合 →しかしテーブル依存で断念。。。 ❏ 主な敗因 ❏ さまざまなシナリオをカバーするために複数の類似クエリを作成することが多い ❏ 構造体がNULLになりえるのにNOT NULL型で生成される(#1208) CREATE TABLE account ( id INTEGER PRIMARY KEY, name VARCHAR(128) NOT NULL, email TEXT ); SELECT email, (SELECT a.id FROM account a WHERE a.name = 'foo' LIMIT 1) AS "id" FROM account; type TestRow struct { Email sql.NullString ID int32 // 本当は sql.NullInt32 になってほしい! } 例:

Slide 17

Slide 17 text

© DMM.com Go開発の取り組み(プロジェクト構成) 17 2. DB操作はSQLによったものを選定 (2回目) ❏ SQLファーストなORMを採用 ❏ bun ❏ クエリビルダーの感覚で使用できる ❏ 機能が少ないので、なにを使うかで迷うことがないデメリット ❏ インデックスヒントやオプティマイザヒントは提供されてないので、必要なプロダクトの場合相性が良くない ❏ 有名なJSランタイムの名前と被っているのでググラビリティがすこぶる悪い

Slide 18

Slide 18 text

© DMM.com Go開発の取り組み(プロジェクト構成) 18 自動生成するなら goaという選択肢もあるのでは？ ❏ まずgoaを採用していても大きな問題になるような構成ではなかった ❏ 今回に関しては既存の知識で解決できたので、追加の学習の観点で採用しなかった ❏ goaのDSLについて知る必要がある ❏ OpenAPI定義とSQLは広く知られている ❏ goa genにカスタマイズするみたいなパターンが出てきた時や、トラブルシュートに不安があった ❏ DMMではgoaは広く採用されているが、部署内では採用事例がなかった

Slide 19

Slide 19 text

© DMM.com Go開発の取り組み(プロジェクト構成) 19 課題2. レイヤー分割 ❏ クリーンアーキテクチャを採用 ❏ Goのフレームワークには LaravelやCakePHP のようなフルスタックフレームワークのお決まりが無いことが度々ある ❏ 今後は規模が大きくなる想定だったので、責務はある程度分割したかった ❏ ベースとなるルールを用意したかった ├── app/ │ ├── domain/ │ │ ├── model/ │ │ │ └── account.go │ │ ├── repository/ │ │ │ └── account.go │ │ └── service/ │ │ └── account.go │ ├── infra/ │ │ ├── dao/ │ │ │ └── account.go │ │ └── external/ │ │ └── db │ ├── interface/ │ │ └── account.go │ └── usecase/ │ └── account.go └── cmd/ └── main.go

Slide 20

Slide 20 text

© DMM.com Go開発の取り組み(プロジェクト構成) 20 type Account struct { ID uint Email string Name string Created time.Time Modiﬁed time.Time } 最初はdomain/modelとテーブルが１対１で作成していた ❏ 開発初期は使用テーブルも少なかったので、不都合が発生しなかった ❏ 既存フレームワークもmodelがテーブル同等だったので、なんら問題がないように思えた課題2. レイヤー分割

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© DMM.com Go開発の取り組み(プロジェクト構成) 22 課題2. テーブル構造の負債 ❏ Domain Modelとテーブル操作用の structを分割 ❏ Domain Modelとテーブル操作後の変換層を追加 ├── domain/ │ ├── model/ │ │ ├── account.go │ │ └── reward.go │ └── repository/ │ ├── account.go │ └── reward.go └── infra/ ├── adapter/ │ ├── account.go │ └── reward.go └── persistence/ └── entity/ ├── account.go ├── reward.go ├── price.go └── conversion.go repository adapter entity model dao use implement

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© DMM.com PHP開発者がハマるGoの開発 25 レシーバー /メソッド ❏ DIと合わせて「どうなってるか分かりづらい」と言われることあり ❏ 「クラスを定義する」という発想を捨て、「構造体に機能を持たせる」という考え方に切り替える方が理解してもらいやすいコンストラクタが独立しているかつ関数名が決まってない PHP構文との違いだがclass(struct)の中で宣言されていないので、メソッドなのが直感的でない

Slide 26

Slide 26 text

© DMM.com PHP開発者がハマるGoの開発 26 グローバル変数 ❏ PHPではグローバル変数をリクエスト毎の共有として使ってしまったりする ❏ 例えば、セッション情報をグローバル変数に格納して、どの処理でもアクセス可能にする // PHPでのグローバル変数使用例 $_SESSION['user'] = $user; ❏ Goでグローバル変数を使うと... ❏ スレッドセーフではないため、データが競合し、アプリケーションが不安定になることがある ❏ 場合によってはOOMが発生する ❏ Goではcontextでリクエスト毎の情報伝搬を行なう

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© DMM.com コンテナサービスとの親和性 30 スピンアップが早い ❏ PHPにも動的コンパイルをキャッシュする仕組みがあり、これを利用することで実行速度を向上できる 1. PHPスクリプトを読み込む 2. パースして中間コードに変換 3. 中間コードを実行 4. 中間コードをキャッシュ保存 5. 次回以降、キャッシュした中間コードを再利用 ; OPcacheを有効化 opcache.enable=1 ; CLIスクリプトでも有効化（任意） opcache.enable_cli=1 ; キャッシュサイズを設定（単位: MB） opcache.memory_consumption=128 ; キャッシュするスクリプトの最大数 opcache.max_accelerated_files=10000 ; キャッシュが更新されるタイミング opcache.revalidate_freq=2 PHP実行の流れとopcache opcacheの設定

Slide 31

Slide 31 text

© DMM.com コンテナサービスとの親和性 31 スピンアップが早い ❏ opcacheで速度改善できるが初回リクエストがくるまでは動的につくるのでスケール前提のコンテナサービスでは上手く作用しづらい ❏ 初回前にキャッシュを作ることもできるが設定が煩雑になったり別途スクリプトが必要になったりする ❏ Goは多くの設定をしなくても一定以上のパフォーマンスが出るので、スピンアップという点では優位があった