Architecture of enza

we love enza!

Transcript

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