Erlang & Elixir Fest JP 2018 まとめ

TL;DR

2018/06/16に行われたErlang & Elixir Fest 2018の発表内容についてサマっておきました。 基本的には発表者達のオリジナルをご自身で見てほしいですが、いかんせん現状ではカンファレンスの動画が無く、 発表中に口頭補足されていたところや、私自身の所感も合わせて書かせていただきます。 Elixir/Webエンジニア弱者なので、指摘事項などがあればコメントいただけると助かります。

冒頭での司会の方が述べられていた今回と去年のカンファレンスの内容についての傾向です。

  • 2017: これから開発が始まる系が多い
  • 2018: 実際に使った結果や運用面での話系が多い

SLIDE

  1. 「らくらく連絡網」が Elixir でリアルタイムメッセージング基盤を刷新した話
  2. 初めてのErlangサーバ開発と運用
  3. Phoenixアプリケーションを1年間運用して分かったこと
  4. from Python to Elixir
  5. ステートフルで大規模アクセスのあるsoft-realtimeなゲームサーバーをeasyにつくる
  6. Channel先生…!! PubSubがしたいです…
  7. Antikythera Framework: An Elixir framework for multiple web services
  8. 任意のBEAM系言語でプラグインを書ける安定したフレームワークの作りかた
  9. Erlang 事例紹介: メディアストリーム中継システム
  10. Erlang and Elixir Fest 2018 Keynote

1.「らくらく連絡網」が Elixir でリアルタイムメッセージング基盤を刷新した話 (rinosamakanata)

概要

  • ラクラク連絡網
  • メーリングリスト
  • リアルタイムトーク
  • 会社:イオレ
  • Ruby → Elixir

クラスタ化 vs 非クラスタ化

  • クラスタ化してる。なぜなら、quantumnで個別ノードでcron実行できる機能を使いたいから。
  • peerage
  • 垂直/水平スケール

Frontend

  • WebView
  • Elm
  • VirtualDOMが高速

調査

監視

まとめ/QA

  • Erlangは覚える必要はほぼなし。だが、BEAMについては知っておくべき
  • QA:BEAMの勉強方法→TheBeamBookがおすすめ
  • Q.エディタは何使ってる?
  • A.InteliJ

所感

  • ゲーム以外の導入事例は初めて見たが、メッセージングサービス/リアルタイムコミュニケーションのWebサービスとPhoenixの相性は確かに良い

あとで調べることまとめ

  • クラスタ化vs非クラスタ化
  • BEAMについての勉強を行う
  • IntelliJが良さげなら、購入
  • 各種のツールの概要理解
  • the beam book

2. 初めてのErlangサーバ開発と運用 (mookjp)

Intro

携わってるサービス

  • Webアプリ開発
  • チャットシステム

WhyErlang

Node

Architecture

  1. イベントループ
  2. シングルスレッド

問題発生時

  • 予期せぬ例外で、シングルスレッドなので、プロセスレベルでダウン
  • イベントループに積まれてる未処理の実行が全て破棄される
  • クライアントコネクションが全て切断される

★被害範囲が大きい

Erlang

Architecture

  1. メッセージパッシング
  2. 軽量マルチプロセス

問題発生時

  • 軽量プロセス単位でダウン
  • Supervisor-treeのStrategyに基づいてダウンしたプロセスに対して再起動などのアクションを起こす

★被害範囲が小さい

CaseStudy:Msgつまり

BadPattern

  1. メッセージを全体に送信
  2. 各プロセスで必要ないメッセージは破棄

→全プロセスに無題にメッセージパッシングされてしまう

GoodPattern

  • gprocでメッセージディクショナリー
  1. メッセージをgpocに送信
  2. gprocが送信する対象プロセスをハンドリングして宛先を絞ってくれる

→無駄なメッセージパッシングが減少する

→ElixirではRegisteryが標準で搭載されている

まとめ

  • Erlang in Angerを最初に読むべき →VMのメモリ確保の挙動
  • 英語力が超必要
  • 公式ドキュメント大事
  • Erlang Slackチャネルおすすめ→すぐ回答してくれる

3. Phoenixアプリケーションを1年間運用して分かったこと

想定対象: これから、Elixir/Phoenixを活用していく人に向けて

Intro

  • 会社
  • 40人位が使用してる
  • 新規事業で多く採用
  • ゲーム、ID管理
  • コミュニケーションサービス
  • ECサイト

Game Server Architecture

  • 2server間(API<->WebSocket)はRPC接続
  • 対戦マッチング用サーバは別に存在

Umbrella

Problem

ElixirはLL系のスクリプト言語と同等レベルで生産量は極めて高い。がコード量がどうしても多くなると、

ManyServicesになると、多々の問題が発生。(Deploy時間がかかる、etc…

→ではMicroService化する?

Solution

  • 複数サービスを1レポで管理
  • サービス間でコード共有
  • Umbrellaプロジェクトを使えば、1repoをアプリケーションレイヤで分割できる

Deploy

  • 問題:デプロイのタイミングでsocketが切断される
  • 解決:WebSocketとLogicサーバで分離→socketが切断されなくなる

Compile

macroはcompile-timeに評価

dependenciesが生まれると、関連モジュールもrecompielされる

問題

問題:1ファイルの修正に伴い、300ファイル近くがrecompileされる。

→生産性が低下

対象例

  1. __
  2. 構造体
  3. import
  4. behavior
  5. protocol
  6. type spec

原因

循環とは?dependencyの先に更にdependencyが発生していく形。

循環のコンパイル

循環を取り除く = 無駄なコンパイル依存を削除する = 依存を取り除く

> mix xref graph -format dat

Slow Test

Testのロード/コンパイルtimeが長い

最善:プロジェクトを分割するのが良い

Monitoring

対象

  • ETS table
  • 各API単位

Tool

  • Prometeus
  • Grafana

Erlang VM用のGrafnanaDash

調査

よく使うモノ

  • recon
  • remsh

Library

  • 所感:現時点で必要なものは一通り揃っている
  • ただ、無いものは作った、もしくば一部変更して使ってる

QA

  • Q. Phoenix1.4 のContextの導入は?
  • A. 今後、追従する。ボリュームは重い。DDDではないので、ゆるく行う予定。
  • Q. 困ったときのコミュニティは?
  • A. ElixirConf主催のTokyoEX、海外のElixirSlackChannel、ErlangFactory
  • Q. DIalyzerは使用してる?理由は?
  • A. 使用してない。理由は、時間がないw、から
  • コードが読みやすくなるので、できる限り書きたいとは思ってる。

所感

  • compile-timeの削減のために無駄なdependenciesを削除するのは、恩恵に対して、作業量が多そうなので、品質向上フェーズのタイミングで行うべき作業かと思われる

4. from Python to Elixir

  • ゲームの基本基盤

python->elixir

  • なぜ?
  • python2020年問題→サポートがdjango2.0→python2系が終わる

FW Phoenix ? 自作WAF?

phoenix辛い

  • なぜ?
  • マクロ辛い問題
  • 多段useのため、コード把握が厳しい
  • 書く量が少ないが、読む量が多くなる
  • 暫定は、Phoenixマスターを1人おいて、ごりおし。
  • 今後は、自作FWを作るかも

FWにおける問題は、Webアプリレイヤーではなく、DBへの処理レイヤー

垂直分割

  • UserDB
  • GuildDB

水平分割

  • シャーディング

Ecto

  • repo = Database
  • シャーディングに対応してないので作った
  • Yacto ライブラリ

GAME Project Template to Library

  • 今までテンプレートを作っていたが、メンテ性が悪すぎるのでやめた
  • すべてライブラリ化。
  • 基盤チームとアプリチームで、メンテ者と使用者で分けれるようになった。

5. ステートフルで大規模アクセスのあるsoft-realtimeなゲームサーバーをeasyにつくる

INTRO

  • TCG
  • PvP
  • HTML5
  • Real-time

開発思想/理念

  • 後からメンバがJoinしやすいように、できる限りレールは引いた(libraryの列挙と説明)
  • GenServerでの想定のコツは、多人数のケースを想定せず、2人のケースで想定すれば十分。

設計

Channel

  1. matching Channel
  2. PvP Channel
  • 理由;Matching条件が複数あるので、複数あるので、分離したいので。

HotCode

HotCodeDeployは行ってない。大変なので。下記で行ってる

  1. Deploy処理
  2. 各ServerへKill予定の通知
  3. Phoenixへの接続がなくなるまで待つ
  4. なくなったら、Deploy

Data

  • 作業内容をすべて履歴として残す。
  • あとで、joinしたユーザはこの内容を元に描画する(たぶん、イベントソーシング思考ってこと
  • または、この情報をAI化する

Knowledge

PhoenixのLoggerが1プロセスしかない。なので、大量Loggingがあると

  1. msgが詰まる
  2. Log出力の実行プログラムがLog実行と同期的になってしまう。

Compile_time_purgeの設定は大きくしておくと良い。

6. Channel先生…!! PubSubがしたいです…

pubsub とは?

購読=subscribe

  • topicに対して送信
  • topicから受信

タグ付け、に近い概念。

PubSub Backend

  • pg2
  • redis
  • 3rd party
  • adapterで独自実装

QA

  • なぜAdapterを作成した?
  • 性能面で。1台のRedisだと要件を満たせられない

9. Erlang事例紹介: メディアストリーム中継システム — amutake -

  • 生放送の中継、についての話
  • ニコニコの今後のシステムで採用されるところの話

POINT

  • 各種アルゴリズム比較して、分散システムを構築している。
  • できる限りメッセージパッシングしないように設計する
  • Erlangクラスタにするとフルメッシュ接続になる。今回採用された、HyParViewとは異なる思想なので。

Erlang/Elixirが付きつけるもの -力武 健次-

Intro

  • OpenErlang20週年
  • Elixir/Erlangではなく、Beamと表現してほしい旨を受ける
  • Elixir/ Erlangでの融合の時期?

Immutability

Erlangメリット

  1. Immutability
  2. ディープコピー
  3. リストのコピーは、参照ではない
  4. 参照がない

Erlangデメリット

  • 遅い
  • 仮想VMが中間層に入っているので
  • 速度で問題が発生したタイミングで機械語を利用するように
  • また、1つの処理を呼び出すのに約数msかかる。
  • 厳格な言語なので、Ruby/PHPのように、ゆるくは書けない

特徴

  • 従来の言語の原則
  • 安全よりも効率
  • ELixir/Erlangの思想
  • 効率よりも安全

ALT Erlang

  • LFE
  • efene
  • alpaca
  • cloherl
  • luerl

今後の展開

  • Erlangの基本理念「ほどほどなのが良い」
  • 安全は高速化に優先
  • 組み込み分野
  • GriSP
  • 組み込みの知識がなくてもErlangの知識があれば導入できる
  • 法律的に国内で利用できな
  • Nerves
  • 全体的
  • 大規模クラスタ:昔は100ノードどうする?だったが、今では1000ノードどうする?
  • ブロックチェーン:
  • Gradual Type System:型検査
  • Language Server Protocol:エディタなどでのエラー発生を言語間でも統一する

QA

  • Q. なんでErlangはあの文法?
  • A. prologの影響?
  • A. ドイツ語が読める人間的には読みやすいとか?

所感

  • 「効率よりも安全」を何度も強調していたのが印象深い
  • 「Erlang/Elixirが早いということは絶対にありえない」と強調していたのも印象深い。おそらく一時期バズった記事で「Elxiirが早い」という記事が挙がった過去もあったので強調主張していたのかと思われ。

全体を通した所感とか

  • 登壇内容またはQA内容で

クラスタ化 vs 非クラスタ化

hot-deployを行う?

の話が多かったが、大抵 非クラスタ化 / hot-deployはしない の選択肢をとる人が多かった。 その理由も「大変」「時間がない」「複雑になる」「面倒」etcなので、 現状では費用対効果的にここまで作り込むフェーズのサービスが少ない、または、これらの機能の技術的洗練が足りていない段階の可能性があるのかもしれない、と感じた。

記憶に残ったワード(カンファレンスに行った人ならわかる系の内輪ネタが多くて恐縮ですが)

  • これから始める人に必要なもの 英語・根性
  • 「お前disれるほどPhoenixを使ってんの?」
  • (PubSubのSupervisorTree見ながら)「どうです?かっこよくないです?」
  • 効率よりも安全
  • Elixirは早くない
  • Erlang in Anger
  • Elixirチョットデキル人
  • 1週間でElixirを完全に理解した

Erlang in Angerの話が多すぎて、これを機に日本語訳化が行われるかもしれないので、逆に今読むのは待ったほうが良いかも

HANDS ON

ErlangElixirFestHandsOn

Twitter


あとがき

自分のgithub-repoのtilに上記情報をまとめていたのですが、会社のテックリード先輩に「mediumとかに書きや」と言われたのと、この記事の内容がナマモノなので、急遽mediumに投稿しました。あとで調べて更新しようとしている箇所や校正しようと思っていた箇所がまだ多いので、見苦しい箇所が多いですが、後々で落ち着いたあたりで整えますのでご容赦を。