10年目の『エブリスタ』を支える技術
•Descargar como PPTX, PDF•
2 recomendaciones•24,167 vistas
まもなく10年目を迎える小説投稿プラットフォーム『エブリスタ』。 この10年で業界は大きく変化し、本サービスもリニューアルという大きな転換期を迎えました。 10年という歳月によりシステム全体もレガシー化し、不要なモジュール、増え続ける機能、機能の変化によるテーブル構造の不都合やパフォーマンス課題など様々な課題が浮き彫りとなってきました。 本セッションではこれらの課題を解決すべく実施したリニューアルのプロセスやその現場におけるKubernetesやGraphQLといった新技術の活用を事例を交えご紹介します。
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 10年目の『エブリスタ』を支える技術
Similar a 10年目の『エブリスタ』を支える技術 (20)
Más de DeNA
Más de DeNA (20)
10年目の『エブリスタ』を支える技術
- 1. #denatechcon #denatechcon 10年目の 『エブリスタ』 を支える技術 井田 祐太 / 松尾 卓朗 ゲーム・エンターテインメント事業本部IPプラットフォーム事業部サービス開発部
- 4. #denatechcon #denatechcon 10年目の 『エブリスタ』リニューアル を支える技術 井田 祐太 / 松尾 卓朗 ゲーム・エンターテインメント事業本部IPプラットフォーム事業部サービス開発部
- 5. #denatechcon 自己紹介 - 井田 祐太 - @da_ponta - https://note.mu/fablab - 2017年4月中途入社 - エブリスタの開発全般を担当 - Perl - Ruby - node.js - Android - Kubernetes 普段はテラリウムなどものづくり全般やってます
- 9. #denatechcon 10年めのサービスの負債 - 誰も把握していない仕様 - コピペされたコード - 独自フレームワーク - 未知のテーブル、カラム - 存在しないテスト、ドキュメント - SJIS - フィーチャーフォン - 4,5種類存在するUI ...
- 12. #denatechcon リニューアルに際しての課題 - エンジニアリソース（3〜4人😰） - 機能数（コントローラ数換算：900, テーブル数：1000） - 既存サービスの運用も継続しなければならない - リリース後も高速な開発サイクルにしたい
- 17. #denatechcon GraphQLのリニューアルにおける利点 - UI要件の変化への対応が不要 →開発速度UP - ドキュメント作成が不要 →工数DOWN - コードがクリーンに保てる →工数増加防止 - モチベーション向上と2年間の維持ができた →開発速度維持
- 18. #denatechcon UI要件の変化への対応が不要 query($userId: ID!) { user(userId:$userId) { nickname introduction } } ※画面は開発中のものです 😅<ここに作品をいれたいんだ けど…
- 19. #denatechcon UI要件の変化への対応が不要 query($userId: ID!) { user(userId:$userId) { nickname introduction novels { title updated_at ... } } } ※画面は開発中のものです
- 20. #denatechcon ドキュメント作成いらず # 型定義 class ContestType < Types::BaseObject # 型の名称 graphql_name "Contest" # 型の説明文 description "公式イベント" # 取得できるデータ field :contest_id, ID, "イベントID", null: false end # Queryの定義 class FindContest < Resolvers::Base # 返す型 type ContestType, null: false # クエリの説明 description "公式イベント" argument :contest_id, ID, "公式イベントID", required: true ... end
- 21. #denatechcon GraphiQL # Queryの定義 class FindContest < Resolvers::Base # 返す型 type ContestType, null: false # クエリの説明 description "公式イベント" argument :contest_id, ID, "公式イベントID", required: true ... end
- 23. #denatechcon GraphiQLだと少し足りない query($userId: ID!) { user(userId:$userId) { nickname introduction novels { title updated_at ... } } } novelsはどの型が持 っているんだ？
- 25. #denatechcon Railsあるある（？） - アソシエーションとビジネスロジックでファットなモデル - ビュー処理とモデルの呼び出しでファットなコントローラ ▶ graphql(-ruby)だとスッキリ！
- 26. #denatechcon エブリスタにおけるアーキテクチャ models モデルに閉じたビジネスロジック policies 権限の判定ロジック repositories DB以外も含めた外部リソース操作ロジック services 何らかの一連のビジネスロジック graphql コントローラ or ViewModel
- 27. #denatechcon Modelの関連をGraphQLが吸収 - 返却するデータ構造の構築が不要 - model・controllerに複雑なロジックを書く必要がない - 意識せずにテーブルと対応したnull安全なデータに # User has a novel class UserType field :novel, NovelType, null: false ... end # Novel belongs to user class NovelType field :user, UserType, null: true ... end
- 29. #denatechcon モチベーションについて② 開発効率が良くないと乗り切れない！！ - プロジェクト期間：2年 - エンジニア数：3〜4人 - 機能数：コントローラ数ベース：900 - テーブル数：1000 - 作りながら要件は変化・増加する
- 30. #denatechcon わずか2,3行でAPIにデータが追加される class Types::UserType < Types::BaseObject description "ユーザ" ... field :followers, Types::UserType.connection_type,"フォロワー", null: false, connection: true def followers(**args) @object.follower_users end end class User < ApplicationRecord self.primary_key = :user_id has_many :followers has_many :follower_users, through: :followers ... end
- 32. #denatechcon ハマりどころも - エラーハンドリングはどう行うか？ - フロントエンドから無制限にデータを参照されるのでは？ - パフォーマンス面（N+1問題など）
- 33. #denatechcon デフォルトのエラー形式 query { user(userId:"存在しないID") { nickname } } { "data": null, "errors": [ { "message": "User not found.", # システムメッセージ "locations": [ # クエリにおける発生行 { "line": 2, "column": 3 } ], "path": [ # クエリにおける発生階層 "user" ], } ] } →メッセージとエラーの発生した階層だけなのでクライアントでのハンドリングが困難
- 34. #denatechcon graphql-errors + エラーカスタム class ApiError < GraphQL::ExecutionError def initialize(message, type = nil) @type = type super(message) end def to_h super.merge("type" => @type) end end graphql-errors https://github.com/exAspArk/graphql-errors GraphQL::Errors.configure(schema) do rescue_from ActiveRecord::RecordNotFound do |e| raise ApiError.new(“#{e.model} not found”, "NotFound") end # 独自エラークラス rescue_from Errors::PermissionDenied do |e| raise ApiError.new(e.message, e.class.to_s) end end
- 35. #denatechcon 拡張されたエラー形式 query { user(userId:"存在しないID") { nickname } } { "data": null, "errors": [ { "message": "User not found.", "locations": [ { "line": 2, "column": 3 } ], "path": [ "user" ], "type": "NotFound" } ] } →パターン化された`type`によりエラーハンドリングが可能に
- 38. #denatechcon 本番と最小限の差異の開発環境 - minikubeを使ったローカルkubernetes - helmによるテンプレート化 - ドメインの割当 - SSL化
- 39. #denatechcon kubernetesを活用した開発環境 - minikubeを利用 - minikubeからNFSマウント - minikubeからk8sにコード共有
- 40. #denatechcon podへのソースコードマウント（抜粋） $ sudo nfsd start $ IP=$(minikube ip | awk -F"." '{print $1"."$2"."$3".1"}') $ minikube ssh -- sudo mount -t nfs $IP:/path/to/src /src -o rw,async,noatime,rsize=32768,wsize=32768,proto=tcp containers: - name: api image: "api:v1" volumeMounts: - mountPath: "/opt/api" name: "api-volume" volumes: - name: "api-volume" hostPath: path: "/src/api" その他の手法 Tilt,Skaffold：ビルドが発生するのでその分の遅延有り Docker for Mac：マウントするファイル数が多くなると参照エラーが発生し断念 Dockerイメージは/opt/apiを WORKDIRに指定します
- 41. #denatechcon Helmによるテンプレート化（抜粋） - レプリカ数 - Dockerイメージのリポジトリ - 起動コマンドの引数 - configMapの数、種類 spec: replicas: {{ .Values.replica }} template: spec: containers: - name: estar-api image: “{{.Values.REPO}}/api:latest" args: [ {{- range .Values.args }} "{{ . }}", {{- end }} ] envFrom: {{- range .Values.args }} - configMapRef: name: {{ . }} {{- end }}
- 42. #denatechcon まとめ - エンジニアリソースの課題 → GraphQLにより実装が簡易化されエンジニア体制が最適化 → minikubeにより環境整備の工数削減 - 900の機能数 → GraphQLによりAPI開発数の減少（150クエリに） - リリース後も開発サイクルを高速で回したい → フロントエンド主導の開発プロセスが実現
- 45. #denatechcon 自己紹介 松尾卓朗 •2017年新卒 DeNA入社（２年目） • IPPF事業部 • サーバーサイド、クラウドを担当
- 54. #denatechcon ですが
- 55. #denatechcon リソースが足りない、、、 事業部エンジニア ● アプリケーション開発 ● インフラ構築 ● ネイティブアプリ開発
- 58. #denatechcon Amazon SES Amazon ElasticSearch Service クラウド環境 kubernetes が分かっていれば、 クラウド環境も理解できる を目指す
- 60. #denatechcon クラウドの管理 GCP • メモリー • CPU • アプリケーションサービスのノード数 • インスタンスのライフサイクル • ロードバランサ • ネットワーク周り • Cluster nodeの管理 • 各種ミドルウェア
- 61. #denatechcon Infra as a codeはどこまで？ すでにcode化されている code化しない GCP • メモリー • CPU • アプリケーションサービスのノード数 • インスタンスのライフサイクル • ロードバランサ • ネットワーク周り • Cluster nodeの管理 • 各種ミドルウェア
- 65. #denatechcon クラウド環境 • コンテナ • ログの収集 • 監視 • ネットーワーク • デプロイ • データコンバート
- 68. #denatechcon ログの収集 • Cluster nodeのメモリ,CPU ..etc • コンテナのメモリ,CPU ..etc