Architecture of 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、言語のアーキテクチャのサービスの事例紹介を行いました • 立ち上げ、開発、リリース、運用を通しての気づきを紹介しました • 運用やチーミングの紹介をしました •

    古くもなく新しくもなくいまどきの開発