Slide 1
Slide 1 text
Architecture of enza.fun
おーはら @ drecom
Slide 2
Slide 2 text
agenda
● About me
● Goal of this talk
● About enza
● Architecture of service
● Development
● Operation
● Conclusion
Slide 3
Slide 3 text
About me
● Tsunenori Ohara/おーはら
○ Twitter : @ohrdev
○ Github : ohr486
● Community
○ tokyo.ex, ElixirConfJapan, Erlang&ElixirFest, JEA
○ meguro.rb, meguro.es
● Work
○ プラットフォーム開発部@Drecom
○ Ruby / Elixir programmer / Architect
● Hobby
○ 仏像制作
Slide 4
Slide 4 text
Goal of this talk
● 事例紹介が中心
○ サービスアーキテクチャの紹介
○ 技術選定
○ 開発運用の紹介
● 立ち上げ〜開発〜運用フェーズにおける気づき
● ソースコードはほぼありません
● 「Webサービス」の「運用」「構成」の紹介
Caution!!
Slide 5
Slide 5 text
About enza
● enza
○ HTML5 Game Platform
○ ©BXD Inc.
● HTML5 Game Platform
○ スマホ向け
○ ブラウザゲーム
○ プラットフォーム
Slide 6
Slide 6 text
https://bxd.co.jp
Slide 7
Slide 7 text
https://enza.fun
Slide 8
Slide 8 text
enza
Architecture of service
frontend
API
WS
serverless backend
Infra
GAME 外部機能/サービス
ココ
SDK
Slide 9
Slide 9 text
Architecture of service
● 発表のスコープ
○ ポータル(サイト)領域について話します
■ Webサービス
○ ゲームについての話はしません
○ 開発・運用のフローについて話します
● 技術スタック
○ React+Redux/TypeScript
○ Rails/Ruby
○ Phoenix/Elixir
○ ServerlessFramework/Python
Slide 10
Slide 10 text
Architecture of service
● Q: 技術スタック、Railsだけで十分なのでは？
● A: Railsだけで全てを満たすことはできなかった
○ HTML5, SPA
○ リアルタイムコミュニケーション
■ チャット、バッジ、通知、etc
○ マネージドサービス
■ Lambda、Kinesis、SQS、ApiGateway、etc
○ API, 管理機能, デベロッパー向け機能
○ 分析ツール・DSL・テスティング
Slide 11
Slide 11 text
Architecture of service
● アーキテクチャ/技術選定の視点
○ 性能観点（重視する）
■ 規模・コスト
○ 保守観点（考慮する）
■ テスト
■ デプロイメント
■ 自社運用実績
○ 採用観点（あまり考えない、自分達が最初にやってやるという意思）
■ 他社利用実績
■ エンジニア市場
■ 転向させれば良い
Slide 12
Slide 12 text
Architecture of service
● API
○ Rails
● 管理画面/DevCenter
○ Rails
● フロント/SDK
○ TypeScript
○ React/Redux
● WS/コミュニケーション
○ Phoenix
○ 性能的な要件
■ 同時接続数
■ F/W
● AWS managedサービス
○ lambda/Python
○ api-gateway
○ ServerlessFramework
Slide 13
Slide 13 text
Architecture of service : Rails / Phoenix
● 類似
○ MVC WAF
○ 標準のディレクトリ構造
○ テスティング、セキュリティ、etc
● 相違
○ ライブラリ数
■ gem >> hex
○ （言語としての）平行性・可用性
○ WebSocket
■ ActionCable
■ PhoenixChannel
Slide 14
Slide 14 text
Architecture of service : WebSocket Backend
● 技術選定
○ 同時接続数
○ CPU/Mem/etc
○ WAFの有無
● 同接比較
○ Rails : △ + 運用知見あり
○ Phoenix : ◯ + 運用知見あり
○ Golang : ◎ + 運用知見なし
○ Node.js : △
○ Clojure/C++ : ---
Slide 15
Slide 15 text
Architecture of service : WebSocket Backend
Elixir 1.4.0 / Erlang19.1 / Phoenix 1.3.0
サーバー1台のWebSocket(Channel)１つのtopicにws接続しpubsubが成功
EC2 r3.xlarge
4core 36Gmem
EC2 m4.4xlarge
16core 64Gmem
Slide 16
Slide 16 text
Architecture of service : 再掲
● API
○ Rails
● 管理画面/DevCenter
○ Rails
● フロント/SDK
○ TypeScript
○ React/Redux
● WS/コミュニケーション
○ Phoenix
○ 性能的な要件
■ 同時接続数
■ F/W
● AWS managedサービス
○ lambda/Python
○ api-gateway
○ ServerlessFramework
Slide 17
Slide 17 text
Architecture of service : AWS Managed
● モチベーション
○ サーバーを管理したくない
○ スケールアウト、アップのオペレーションを簡単にしたい
○ コストの最適化
■ 使ったぶんだけ支払いたい
● マネージドサービス
○ Lambda
○ ApiGateway
○ Kinesis
○ SQS
○ DynamoDB、etc
Slide 18
Slide 18 text
Architecture of service : AWS Managed
● 管理ツール
○ Webコンソール + 手動 : しんどい
○ ServerlessFramework : 運用知見あり
○ Apex : 運用知見なし
○ SAM : 運用知見なし
● 必要な要件
○ バージョニング、Lambdaのコード管理
● Lambdaのランタイム言語 : (宗教)
○ Python : 社内実績、方針
○ Node.js : 悪くないが、混在を避けた
○ Java
○ Golang : 選定時まだ無かった
Slide 19
Slide 19 text
hex gem
Architecture of service
React+Redux
SPA
Rails
API
Phoenix
WS backend
Terraform/HCL
Infra
Rails
Admin
Rails
DevCenter
TypeScript
SDK
Lambda/Python
Serverless
1サブシス1リポジトリで管理
gem
gem
Gatling
各種 tools
hex
hex
Slide 20
Slide 20 text
Development
● ワークフロー
○ 設計
○ 開発
○ テスト
○ QA試験
○ 負荷試験
○ デプロイメント
Slide 21
Slide 21 text
Development : 設計
● API(Rails)、WS(Phoenix)のI/Fは全てswaggerを定義
○ ruby-swagger
○ phoenix-swagger
● CIでswaggerに対する検証・更新を実施
● 関連サブシスが多いのでI/F定義ドリブン
Slide 22
Slide 22 text
Development : 設計
● 立ち上げフェーズ
○ モックのみ
● 開発フェーズ
○ swagger
○ サブシス間の結合のバランス
■ I/Fを壊さず通信
● 運用フェーズ
○ swagger + 性能テスト + セキュリティテスト
○ 性能が悪い = バグ
○ コストが高い = バグ
○ 危険 = バグ
・「バグ」の認識が広がった
・初期フェーズからswaggerを導入した
事で開発がドライブできた
Slide 23
Slide 23 text
Development : 開発・テスト
● 開発時のサブシスを繋ぐのはswagger
React+Redux
SPA
Rails
API
Phoenix
WS backend
swagger
GameServer
SDK
I/Fが変わるとまずい
ここを変えずに開発を行うため、
外部提供APIのswagger/schemaを
テスト
Slide 24
Slide 24 text
Development : 開発・テスト
● 立ち上げフェーズ
○ モックのみ
● 開発フェーズ
○ スクラムチーム
○ SREチーム
○ QAチーム
● 運用フェーズ
○ + デベロッパー対応チーム
■ ゲームプラットフォーム ・複数チームでもswaggerがハブになる
・外部提供APIの「仕様」をテストすると
安心できる
Slide 25
Slide 25 text
Development : QA試験・負荷試験
● QA試験
○ リリース前
○ QAチームが実施
○ テストシナリオは開発チームと一緒にレビュー
● 負荷試験
○ 新機能追加前
○ 定期的に実施（毎晩負荷試験を回すよう開発）
○ 負荷試験環境を常時メンテ
○ 負荷試験用のRailsEnv、MixEnvをコードベースに組み込んでメンテ
■ 負荷試験の実施を前提としたコードベース
Slide 26
Slide 26 text
Development : QA試験・負荷試験
● 立ち上げフェーズ
○ なし
● 開発フェーズ
○ QA: リリース前に実施
○ 負荷: リリース前に実施
● 運用フェーズ
○ QA: 本番適用前に実施
○ 負荷: 定期的に実施
■ AWSの事前申請は2week
・負荷テストを前提としたコードベースにして、
テストの敷居を下げた
・でも負荷テスト、お高いんでしょう？
- テスト実施タイミングでのみサーバーを
立てれば安くできる（見込）
- インフラ構成のコード化が前提
Slide 27
Slide 27 text
Development : デプロイメント
● frontend
○ TSコンパイル、webpack、S3upload
● Rails
○ cap deploy
● Phoenix
○ edeliver build & release
● serverlessframework : AWS lambda, API-Gateway, etcのデプロイメント
○ sls deploy
● Terraform : AWSの構成管理の更新
○ terraform plan & apply
Slide 28
Slide 28 text
Development : デプロイメント : Rails
deploy target
deploy host
checkout
Slide 29
Slide 29 text
Development : デプロイメント : Phoenix
build server
deploy host
deploy target
checkout
xxx.tar.gz
copy
release
同じOS/環境/アーキでなければならない
Slide 30
Slide 30 text
Development : デプロイメント
● CircleCIを利用してデプロイ
○ frontend
○ rails
○ phoenix
○ serverlessframework
○ terraform
それぞれdeployの方法・思想が全く違う
運用上、違いを意識したくない
同じI/Fで適用
Slide 31
Slide 31 text
Development : デプロイメント
● 立ち上げフェーズ
○ なし
● 開発フェーズ
○ 手動
● 運用フェーズ
○ CI/半自動化
・言語、F/Wによってdeploy方法が全く違う
・deployの（心理的、オペレーション的）コストは非常
に高い、特に本番への更新
・自動化することで、並列実行が可能になり deploy
時間の短縮ができる
Slide 32
Slide 32 text
Operation
● インフラ運用
○ 構成管理
○ サーバーのスケールアップ・ダウン・アウト・イン
○ サービス監視
● デプロイメント
○ 開発環境
● 負荷試験
Slide 33
Slide 33 text
Operation : 構成管理
● Terraform
○ IAM、Role、EC2、serverless以外の全てをコード化
○ 行数: 12000行
■ planに5分程度
○ サーバーの増減を手早く行いたいので、EC2は管理していない
● serverlessframework
○ Lambda、ApiGateway等のサーバーレスリソースをコード化
○ Terraformと分けているのはバージョン管理の頻度が異なるから
Slide 34
Slide 34 text
Operation : サービス監視
● エラー
○ sentryに集約
■ Rails
■ Phoenix
■ Lambda
● APM
○ newrelic : Rails
○ appsignal : Phoenix
● サービスメトリクス
○ CloudWatch
○ prometheus
Slide 35
Slide 35 text
開発1
Operation : デプロイ/環境
本番
サンドボッ
クス
ステージン
グ(安定
版)
負荷試験
セキュア診
断
開発1
開発1
Rails/Env
production
Rails/Env
staging
Rails/Env
staging
Rails/Env
staging
Rails/Env
production
Rails/Env
stress
ステージン
グ(次期
ver)
Rails/Env
staging
ローカル
Rails/Env
develop
常時維持
Slide 36
Slide 36 text
Operation : 負荷試験
● 定期的に実行
○ 新機能/APIが追加される時
○ 毎晩（開発中）
● Gatling
○ APIとWebSocket通信
● アプリコードベース
○ 負荷テスト用のコードをmasterブランチに組み込み
○ テストユーザー作成・ハンドルAPI
● インフラ
○ 負荷テスト用データのメンテ
○ terraformで必要なリソースを立ち上げ
○ mockサーバー/proxyの維持
Slide 37
Slide 37 text
Development team
● エンジニア規模
○ 20名程度
○ 管理対象リポジトリ : 27
● 構成
○ フェーズが変わるにつれ構造変わる
○ アーキテクチャが変わるにつれ構造が変わる
● アーキテクチャ・サービス構成に対応したチーム・構成
○ 少しずつ変化してきた
Slide 38
Slide 38 text
Development team
● 機能開発
○ スクラムチーム x 2
● インフラ・SRE
○ タスクベースのチーム
● 品質保証
○ タスク(チケット)ベースのチーム
○ スクラムチームと足並みを揃えて進行
● 運用チーム
○ GameDeveloperとの折衝
○ サービス運用
Slide 39
Slide 39 text
Conclusion
● enzaのポータル領域のアーキテクチャを紹介しました
● 複数のF/W、言語のアーキテクチャのサービスの事例紹介を行いました
● 立ち上げ、開発、リリース、運用を通しての気づきを紹介しました
● 運用やチーミングの紹介をしました
● 古くもなく新しくもなくいまどきの開発