XFLAG XFLAG × スポーツ × Elixir スポーツ事業推進室　村山 寛明 Erlang & Elixir Fest 2019 

2 自己紹介 スポーツ推進事業室 2014年ミクシィ新卒入社 　1年目 SNS mixiの開発/運用 (Perl) 　2年目 モンストサーバサイド開発 (Ruby) 　3年目 SRE (Ruby) 　4年目 ファイトリーグ サーバ開発 (Elixir) 　5年目 スポーツ事業 (Elixir) 　6年目 ← 今ここ 趣味 　クラフトビール 　ボードゲーム♟ 　ポーカー 村山 寛明 / Hiroaki Murayama 

3 XFLAGとスポーツ事業 

4 XFLAG がスポーツをやる理由 ● XFLAGとは ○ ミクシィ社のエンターテインメント事業領域の ブランド名 ○ 「友達や家族とワイワイ盛り上がれる『場』」を 提供することがコンセプト ○ スマホアプリ「モンスターストライク」 ● なぜスポーツなのか ○ 今度は「みんなでワイワイできる『場』」をスタ ジアムやアリーナなどのスポーツ観戦の場へ 

5 なぜElixirを選択したのか？ 

6 なぜElixirを選択したのか？ ● ファイトリーグでの開発実績があり資産を利用できる ○ ファイトリーグに関しては過去の発表資料があります ● Rubyライクで人を誘いやすい ○ 社内プロジェクトだとRubyの利用率が高く学習コストが低い ● ポータビリティが高く運用が楽 ● WebSocketを使ったインタラクション性の高いコンテンツを作る必要があった ○ プロトタイプ等には利用、今回のプロダクトには利用してない Erlang & Elixir Fest 2018 Elixir Conf 2017 

7 全体のアーキテクチャ 

8 全体のアーキテクチャ スマホアプリ ブラウザ ImageFlux メディア配信 Webクライアント EKS/k8s APPサーバ API CS Tool Admin Tool MySQL 5.7 Redis / RedisCluster メディア アップロード REST API (Protocol Buffers) データベース 

9 Protocol Buffersを使ったAPI開発 

10 Protocol Buffersを使ったAPI開発 ● Protocol Buffers とは ○ APIのインタフェースを定義する言語の一つ ○ データ領域がバイナリで通信量の削減 ○ ドキュメント/コードの自動生成がPluginとして可能 ● REST API + Protocol Buffers ○ リクエスト/レスポンスのフォーマットにProtobufを利用 ○ gRPCにもチャレンジしたかったがライブラリ等もまだ不十分であり、プロダク ション環境で使うには運用コストが高いと判断しProtbufのみ利用にした 

11 Protocol Buffersを使ったAPI開発 ● 自動生成しているもの ○ APIドキュメント ○ Elixir側 ■ APIのRequest/Responseの型定義 ■ Enumや共通の型定義 ○ クライアント側 ■ APIClientのモジュール定義 ■ APIのRequest/Responseの型定義 ■ Enumや共通の型定義 

12 Protocol Buffersを使ったAPI開発 ● 定義ファイルをリポジトリ管理 ● Dockerで管理しており開発者はdocker-compose runするだけ ○ protocというコンパイラがありpluginを指定することで各言語へ変換できる ○ pluginをdockerfileで管理して実行すると各Projectへコピー ● ドキュメントはREADME.mdとして定義ファイルと一緒にリポジトリで管理すると GitHub上でそのまま見ることができる Protobuf file Run protoc Copy to each projects 

13 Protocol Buffersを使ったAPI開発 ● xflagstudio/protobuf-elixir ○ オープンソースの tony612/protobuf-elixir がベース ○ enumを関数として呼び出せるようにしたもの ■ 既存のものはfieldアクセスなので動的にしかチェックできなかった ■ enumで定義されていない関数呼び出しがビルドエラーになる 

14 Protocol Buffersを使ったAPI開発 

15 Protocol Buffersを使ったAPI開発 sample.pb.ex sample.md 

16 Protocol Buffersを使ったAPI開発 ● 生成されたモジュールに encode/1, decode/1インタフェースが存在する ○ Protobuf <-> Struct の変換ができる ● リクエストパラメータはplugでデコード処理を共通化 ○ /sample/ping -> Api.Sample.Ping.Requestの呼び出し ■ String.to_existing_atom/1 を使うのが重要 ○ PhoenixControllerのパラメータと同様に扱うことが可能 ● レスポンスはパスに対して動的にエンコード ○ /sample/ping -> Api.Sample.Ping.Responseの呼び出し ○ templateやviewを使わずPlug.Conn.send_resp/1を使用 ● Controller/Routerやテストの自動生成もできると良い 

17 Protocol Buffersを使ったAPI開発 ● 気になった点 ○ Protobufのoptionalはnullではなくデフォルト値が入る ■ boolean型はデフォルトで false が入ってるので要注意 ○ 例外が起きたとしてもレスポンス型は変えれないので工夫が必要 ■ よくある status のフィールドの値によって全体のデータ型が変わるというの が出来ない ■ 適切なエラーハンドリングをする場合すべてのレスポンスにエラーハンドリ ング用の型を用意するかレンスポンスヘッダなどを活用する必要がある 

18 Kubernetes を使ったインフラ 

19 Kubernetes を使ったインフラストラクチャ ● Kubarnates(k8s)とは ○ コンテナオーケストレーションツール ○ Dockerコンテナのクラスタを管理できるツール ● Kubarnates(k8s)とPhoenix umbrellaは相性が良い ○ 個別ビルドしたアプリケーションをそのまま使える ○ Dockerfileにはビルドしたアプリケーションをforegroundで実行するだけ ○ ホットデプロイをPhoenix/Distilleryで頑張らなくても良い 

20 Kubernetes を使ったデプロイ環境 EKS/k8s APPサーバ API CS Tool Admin Tool 開発 者 Distillery kubectl docker build & push PR作 成 PRマージ 継続的デプロイ環境 ● GitHub ○ make PR ● CircleCI ○ docker build ○ docker push ○ kubectl apply 

● Phoenix Umbrella Project ○ API ○ CS Tool ○ Admin Tool ● Dockerfile ● k8s manifest 21 プロジェクトの構成 

22 プロジェクトの構成 Distillery API CS Admin AllInOne (API + CS + Admin) ● bitwalker/distillery ○ ビルド/デプロイツール ○ rel/config.exs に設定を書いて mix release ● ENV毎にAPPの構成を分けられる Unstable Production 

23 Kubernetes を使ったインフラストラクチャ EKS/k8s APP Pod API CS Tool Admin Tool mix task Pod mix Scheduled Task Pod (CronJob) mix ● Phoenix Applicationのpod ● 任意のmixコマンドを叩けるpod ● mix taskを定期実行するpod ○ k8sにはCronJobという定期実行する仕組みがある 

24 Kubernetes を使ったインフラストラクチャ 気になった点 ● クロスコンパイルできるけどOSに依存してるライブラリも存在する ○ ビルドした環境とアプリケーションを実行する環境が異なると実行時エラーに なる ○ 本プロダクトではAlpineLinuxを利用 ● 開発環境はホストOSで動かしてる ○ dockerだとelixirビルド/テストが遅い ■ volumeをhostにマウントしてたとしても ○ 一応開発用のdocker-composeファイルはある 

25 まとめ 

26 まとめ ● スポーツ事業でのElixir活用例を紹介 ● Elixir + Protocol Buffers は生産性が上がる ● Phoenix/Umbrella + Distilleryとk8sは相性が良い 今後やりたいこと ● 完全なgRPC化 ● Phoenixのコントローラ/テストの自動生成 ● LiveView使ってみたい 

Thank you 27