Erlang & Elixir Fest 2019 に参加してきた

Erlang & Elixir Fest 2019 に参加してきました。
その感想をメモを兼ねて時系列順にざっと思うままに書いてみます。

開始前

Erlang & Elixir Festは過去に何度か開催されていたようですが、自分は今回が初参加でした。
場所は永田町で、10時開場、10:30セッション開始というスケジュールで、10:10くらいに入場しました。

会場は縦に長く、中央にプロジェクターのスクリーンが1枚という構成でした。
後ろの方に座るとスライドがよく見えないだろうと思ったので前の方の席を探すと中央の前から2番目というかなりのいい席に座ることができてセッション中に不自由しなかったのがとてもよかったです。

セッション

超並列高速実行処理系 Hastega 〜 Lonestar ElixirConf 凱旋帰国


一つ目の発表はHastegaというElixirのコードをOpenCLに変換して分散処理をするライブラリ(でいいのだろうか)についての発表でした。名前の由来はFFの仲間を強化する魔法だそうです。現状はdefhastegaというマクロで囲んだ中にあるEnum.mapなどが変換され、並列処理されるようになるそうです。また、将来はdefhastegaマクロを使わずに、できそうなところは変換するようにしたいとも話していました。
スライドに性能評価はありましたが、コード生成の仕組みに悩んでいるとのことでリリースはされていないそうです。Hastegaを使ったコード例を見た限り、使う分にはシンプルそうでよさそうでした。
Erlang/OTP 22からはHiPEが非推奨になるのでそこも悩みどころ、と話しており、それについてツイートしたところ、記事を教えていただきました。
どうやら、HiPEの開発チームが忙しいようです。

Nervesが開拓する「ElixirでIoT」の新世界

NervesというElixirでIoTをするフレームワークについての発表でした。
Raspberry Piをターゲットにしており、On The Airで手元のRaspberry PiのファームウェアをNervesHubからネットワーク越しに更新するというでもを見せてくれました。
mixを使ってttyでのシリアル接続なども可能だそうです。
これによって、サーバとデバイスの両方、つまり全てをElixirで書けるようになって嬉しいですね。
また、ブートローダ + rootfs + Erlang OTP + Elixirという構成になっているらしく、どのように動いているのかが個人的に非常に気になりました。ブート後の下回りではLinuxが動いていないらしいです。

工場の制御をElixirで 〜ラダー・ロジックを実行する〜


水力発電のシステムにElixirを使おう、というプロジェクトのお話でした。最近の発電所では、リモートで監視/制御をしたいが、実現するための技術とエンジニアの心に谷があり、いろいろな背景を持ったエンジニアが協力しないといけないため、文化を融合させるのに苦労しているそうです。
また、始めはPythonを使っていたが、並行性と信頼性の点でElixirに白羽の矢がたったと話していました。そして、ボタンなどのハードウェアそれぞれを軽量プロセスに対応づけて表現できないかを検討しているらしく、プロセスの異常終了時に状態の復元や、不整合が起きないようにするのが少し大変そうだと思いました。

Elixir プロセス 入門

タイトルの通りElixirのプロセス入門でした。
が、時間の都合でスピード感が凄まじかったです。
自分Erlangの経験があったから、聞いていて全く問題ありませんでしたが、初めて聞く人は少しついていけなさそうでした。
しかし、スピード以外は図も豊富でわかりやすくて良いスライドだと感じました

お昼休み && ハンズオン


ランチ弁当は美味しかったです。個人的に五穀米はとても好きです。
また、ohr486/ErlangElixirFestHandsOn2019 を使ったハンズオンがありました。直前のプロセス入門と合わせていい流れで取り組みやすいかなと思いました。

ElixirでやるDDD (ドメイン駆動設計)

タイトルにはドメイン駆動設計と書いてありましたが、Data Driven Developmentの略でした。Elixirのconcurrencyの特徴であるspawn_link/1, send/2を使ったメッセージパッシングはキューの処理がボトルネックとなり欠点になるそうです。関数は拡張が引数と戻り値を全て明示する必要があり難しいので、データを拡張する、そのために関数型プログラミングパターンを4つ(Protocol, Event sourcing, Linguistic tree, Composable context)紹介してくれました。正直、今スライドを見返しても余りよくわかっていません。キーワードをヒントとして調べてみるのがよさそうです。

Phoenix1.4とVueによるサービス構築のノウハウ

タイトルの通りノウハウ/Tips集でした。残念ながらPhoenixもVueも全くなのでよくわかっていません…

Protocol Buffers(proto3) を Elixir で実装する

実際のProtocol Bufferの値とElixirのコードを見ながらbitstringのパターンマッチを使って処理していくのを解説するという発表でした。やはり、パターンマッチはいい文明ですね。仕様とコードを見比べたときにわかりやすいです。

4才から24才までプログラミングを教えた結果、高校生にElixirを教えるに至った気付き

ゲームを作りたい、という高校生にC言語から教えたら全然だったけど、Elixirを使ったら上手く行ったよ、という教育系のお話でした。ゲームを作るのが目的でコードを書くのが目的じゃないので、いかに楽しんで自分は得意なんじゃないかと錯覚させることが大事とのこと。

Designing a (soft) realtime digital events platform for scale

タイトルにあるリアルタイムのデジタルイベントプラットフォームの設計のお話でした。プロジェクト自体をUmbrella Appsを使っており、DBレイヤ、push通知、などの粒度で分割しているそうです。またいくつかTipsも話しており、"Don't let it crash"というのが最も印象的で、長期間ステートを持っているプロセスが死んだら困るので死なないようにしている。ということのようです。個人的にもなんでもエラーしたら死ぬ、では難しいとこもあるよなと思っています。ただ、簡単に殺せないプロセスが生まれてしまうというのもErlang/Elixirの気軽にプロセスを終了して再起動すればいい、ようなやり方と相反しているようにも思いました。(考察が足りない)

XFLAG × スポーツ × Elixir

1年くらいElixir開発したノウハウを共有する、という話でした。半分くらいはProtocol Bufferを使ったAPIの話で、サーバとクライアントの型定義ファイルなどいろいろなものを自動生成しているそうで、かなり便利そうでした。ちなみにサービスはまだリリース前だそうです。Ruby on Railsを使っていて人を誘いやすいから、Elixirを採用したそうです。こういう話はたまに聞きますね。

Serverless BEAM with FaaS

AWS LambdaでElixirを動かす話でした。Lambdaやらサーバレスという言葉は最近耳にするが知らなかったので知る機会になってよかったです。サーバレスでElixirアプリケーションを動かすためにアーキテクチャ上の制約があるらしいので必要になったら見返したいです。

ロマサガRS における Elixir サーバー開発実践 〜生産性を上げてゲームの面白さに注力

ゲームサーバをElixirで開発したという話でした。Elixirでサーバというと大体がPhoenixですが、ここではCowboyを使っていたので少し意外でした。しかし質疑応答で選定理由は特に無いらしく、今だったらPhoenixを使うだろうとも答えていました。JSONを返却するAPIサーバで、平均のレスポンスタイムが50msという性能が出るそうです。また、Elixirを使うことで今までDBに保存していたゲームデータを起動時にETSに格納することで高速化に成功したらしく、Erlang/Elixirらしいと思いました。標準でETSのようなKVSが付いていると手軽でいいですね。また、ゲームのバトルロジックの計算もサーバサイドで行っているそうです。サーバサイドなので、チートの防止にもなり、StateにActionを適応していく、という方針で、かつ、関数型言語でImmutableが基本なので、テストがしやすいとのこと。また、これらのロジックのログや乱数シードを保存してバグを再現しやすくしているそうです。

Erlang/OTP で作るリアルタイムサーバー

1vs1の対戦ゲームのためにPubSubサーバを作ったという話でした。1vs1の対戦ゲームなので、自分のキャラ、相手のキャラ、自分の画面にいる相手のキャラのコピー、相手の画面にいる自分のキャラのコピーの合計4体を制御する必要があり、結果は直ぐに反映されてほしいという要件だそうです。既存の製品はあったが機能過多であり、可用性の観点から自前で作ることにしたと話していました。そして、土管を作る、ステートフルだがデータレスをコンセプトに作成したとのこと。またプロトコルも自前で作成したそうです。Tokenを使ってPubSubサーバからAPIサーバに問い合わせて認証をするなど、面改めて見たいのでスライドを公開してほしいです。

Erlang/OTP で WebRTC と QUIC


Erlang界隈では自分もTwitter上で見かけていましたが、激しい感じの発表でした。開発体制もレビューはしない、マネージメントはしない、開発用ドキュメントは書かずコメントはがっしり書く、など、まあ、おいそれとは真似できない、この人だからやっていられるんだろうな、という感じでした。パッケージ製品の販売をしているが、4年間で製品が落ちた、という報告を顧客から受けたことはないそうです。耳が痛いですね。おまけで紹介していたErlang VM の JIT 対応がとても気になります。

Lightning Talks

LTも一気に8つもあり
  • KISS からはじまる Elixir on Kubernetes
  • Erlang in Anger を有志で翻訳した話
  • Mix ProjectのConfigとmix release
  • Elixir黒魔術入門
  • Phoenix LiveViewで結婚式用Twitterを作った話
  • Enum.mapから始めるElixirデータサイエンス
  • Elixir でのゲーム開発事例
  • ElixirでFPGAハードウェアが作れちゃう,かも!!?
というタイトルでした。個人的にはElixir 1.9で大きく変わるというConfigが非常に気になりました。スライドがよくまとまっていたので使うときに見返します。

Erlang/OTP と ejabberd を活用した Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」の開発事例


最後のセッションはkeynoteの任天堂の発表でした。プッシュ通知の概要の説明を一通りしたあとに、Erlangとejabberdを運用していくにあたっての開発で現れた問題とその解決方法の話が主でした。しかし、抱えているユーザの規模が違うのでシステム全体への接続が1億台、ノード1個では50万から100万接続、全世界のSwitchが一斉にログインしてきたとしても30分で裁けてほしい、と超大規模でした。それらをデバッグするにあたって、etop、eprof、reconなどのトレースをかなり活用していたようです。また、スケールするんだから台数を増やせばいいよね、という前に技術的に解決してやろう(そして、出来ている)という姿がエンジニアとして憧れます。「問題はひとつずつ解決していこう」、いい言葉です。
ejabberdはOSSのプロダクトですが、発表を聞いた感じではかなり手を入れているそうです。また、開発していく上でクラスタ構築の面倒をErlangVMが行ってくれるから、というのがErlangを使う一番の理由だったそうです。

まとめ

LTも含めると全部で22の発表があったのでここまで書くのがつかれました。

一般参加チケットの料金は6000円で、購入時点では、まあ、高くはないなーと感じていましたが、参加後の今現在のお気持ちとしては安かったな、です。
いろいろな話が聞けて楽しかったので、来年もあるならば参加しようと思います。

コメント

このブログの人気の投稿

Android で MIME Type 判別

Java の 自作クラス を 配列 化する時の注意点