Erlang&ElixirFestJP2019 のイベントレポート

こんにちは。1 年くらい Elixir 書いていた Nash です。

この記事は『Erlang&ElixirFestJP2019 のイベントに参加してきたレビュー記事』になります。

イベントのスライドだけをご覧になりたい方は、下記にまとめてあります。

Erlang&Elixir Fest JP 2019 スライドまとめ

Erlang&ElixirFestJP2019 について

知らない人向けに、ざっくりで説明していきます。

Erlang とは？

耐障害性が極めて高い言語です。Erlang の作者曰く、本番環境での稼働率がナインナイン(99.9999999%)を実現させることが出来るレベルです。

当カンファレンスでも、その話がありましたので詳細は任天堂様のブロックで記述してあります。

Elixir とは

BEAM(ErlangVM) で動作する関数型言語です。

Rails の作者の 1 人である JoseVaim が作成しているため、Ruby のシンタックスにとても似ています。

Erlang の耐障害性や過去の資産を使える上に、関数型でありながら 再代入ができたりと(正確には再束縛) Web アプリケーションを開発できるだけの柔らかさを持ち合わせています。

また、パターンマッチングやパイプライン演算子など、関数型・モダンな機能が多く盛り込まれているため、書いていて気持ち良いです。

当カンファレンスでも、「書いていて気持ち良い説」は出てましたね。

海外では

海外でも様々な Elixir&Erlang 系のカンファレンスが開かれています。

最近の動向として、Elixir と Erlang をより近づけていくために同一カンファレンスになっているケースが多いようです。また名称も Elixir&Erlang から BEAM という名前を使うところもあります。

当カンファレンスでも、海外の Elixir&Erlang カンファレンスに行ってきた旨の発表がありました。

去年との比較

去年にも「Erlang &Elixir Fest JP 2018」が行われています。去年との比較としての所感ですが、話の比率が下記の通りです。

※ Nerves ＝ Elixir で IoT デバイスを動作する FW・プラットフォームなどの総称。

  • 2018 　 → 　 Elixir/Phoenix によるサービスが大半で、Erlang の話が 2 割くらい。
  • 2019 　 → 　 Erlang、Elixir/Phoenix、Nerves の話が同じくらいの割合。

自分の興味領域が Elixir/Phoenix での Web アプリケーションがメインのため、全体的に他界隈の話が多くなった印象が強かったです。

ちなみに、去年のイベントレポートは下記に記載しています。

Erlang & Elixir Fest JP 2018 まとめ

では、2019 のイベント内容についてレポートしていきます。

Erlang&ElixirFestJP2019 イベント

聴講内容について、ポイントや所感などをまとめていきます。

Opening

＜ポイント＞

  • 日本の ElixirConference は、今年で 3 年目！

超並列高速実行処理系 Hastega (ヘイスガ) 〜 Lonestar ElixirConf 凱旋帰国

＜ポイント＞

  • GPU で動く機械学習などの処理系の Hestega を開発について。

  • 海外カンファレンス（LonestarElixrConf2019）で行った発表の概要。

  • Hestega を作成した時代背景。

  • LonestarElixrCong2019 の参加で気付いたこと。

＜所感＞

  • LonestarElixirConf では、Elixir/Phoenix と同列に Nerves が熱くなっている（本人談）。
  • Elixir/Phoenix はファイナルファンタジー由来ではない。Elixir 作者の Jose は FF をやったことがない（衝撃の事実）。

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

＜ポイント＞

  • IoT 系で動作する Nerves の説明。
  • ハンズオンと、ライブデモ。

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

＜ポイント＞

  • 組み込み系、制御系を行う FactoryAutomation の世界の説明。
  • Elixir を採用した理由。

＜所感＞

  • 「IoT ＝ラズパイ」のイメージだったが、界隈が違うと「IoT ＝水力発電所の制御システム」となるのは面白かった。

Elixir プロセス 入門

＜ポイント＞

  • Elixir プロセスに関する説明をコードベースに行う。
  • spawn/reveice/send、Agent、GenServer、Registery、spawn_link、Supervisor

＜所感＞

  • 内容がめちゃくちゃわかりやすい、かつプロセスに関して知っておくべき内容しかなかったので、実務で Elixir を書く人は必須で読んでおくと良い内容だった。

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

＜ポイント＞

ゲーム系などのロジック部分を CRQS などで具体的にどのように記述しているか？を解説。

＜所感＞

  • 難しい内容だが、その分密度が高い。あとでじっくり読みたい。

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

＜ポイント＞

  • Phoenix と Vue での結合についてを解説。

＜所感＞

  • View レイヤーを Vue やらの JS 系の FW で記述するなら、テンプレートエンジンは使わずに Phoenix は API サーバとして使うほうが良い、と強く思った。

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

＜ポイント＞

  • Protocol Buffers とは？
  • PB を Elixir で実装するためのレクチャー。

＜所感＞

  • Elixir だとバイナリパターンマッチングが出来るから、バイナリの操作も楽にできるよね。

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

＜ポイント＞

  • Elixir での教育的なハンズオンを行った知見のまとめ。

＜所感＞

  • スモールステップなら JavaScript の方が良いのでは？説があるが、バックエンドとしてなら Elixir の可読性は高いので、良いと思う。

Designing a (soft) realtime digital events platform for scale

＜ポイント＞

本番環境で Elixir で書いた学びについて。

＜所感＞

  • Erlang でよく言う Let it crash ではなく、Don’t let it crash. 系の話は Supervisor 設計系の話でよく出るやつ。

XFLAG × スポーツ × Elixir

＜ポイント＞

Elixir を使ったスポーツ系 Web サービスでの知見。

  • クラサバのプロトコルは ResfulAPI だが、ProtocolBuffer を使ってる。
  • ホットデプロイが distillery(ライブラリ)だとアプリケーションレイヤーで解決するこちになるが、k8s+umbrella ならコンテナレイヤーで行えるので、この２つの相性が良い。

＜所感＞

  • プロトコルについて。以前開発していた現場では、message pack を使っていたが、クラサバの結合部分とドキュメントの更新のコストがものすごく高かった。この発表である通り、PB だとクラサバの結合部分やドキュメントを自動ビルドしてくれるので、DX がとても良さそう。

Serverless BEAM with FaaS

＜ポイント＞

  • FaaS の概要、時代、金額、メリデメの説明。
  • FaaS で Elixir を動かす場合の仕組みについて。

＜所感＞

  • サーバーレスで BEAM(Elixir/Erlang)を動かす、という試みは面白いなーと思う反面、メリットがあまりわからなかった。Elixir・Erlang の特徴となる、OTP による SupervisorTree や WebSocket が使えないのではないのでは？と思う。とはいえ、FaaS+Elixir 自体がまだまだ未成熟なところなので、今後に期待。

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

＜ポイント＞

WebSocket・API サーバとして Elixir を使った事例の紹介。

＜所感＞

  • Elixir を選定しただけで一定の速度を担保できるメリットはやはり強いように感じる。

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

＜ポイント＞

スマホゲームの時代背景から、システム的な面での説明。

  • Pub/Sub 配信の土管作りの話

Erlang/OTP で WebRTC と QUIC

＜ポイント＞

資料の読み方をプレゼンします。Erlang のコードの話はしない。パッケージがどうやって作るられるか？を話す。

  • パッケージ製品＝納品したら終わりで、更新できない。稼働時間、バグが無い、などがとても大事。
  • ライブラリをあまり使わないで、ほとんど自前で作っている。処理を理解しないといけないので、結局自分で作ったほうが早いから。
  • 1 プロセス起動に対して、だいたい 20 プロセスが立ち上がる。
  • メッセージパッシングは遅いので使わない。
  • 機能追加は出来る限りしない → メンテコストが高いから。
  • microsoft は Skype があるから、QUIC に乗り気かもね。
  • WebRTC 系のコミッターがほぼ全員を QUIC に乗り気。

＜所感＞

  • パッケージ製品の開発の話は、Web 系のカンファレンスに行ってもあまり聞かないので、面白かった。特に、ビジネス的な制約が色々異なる点なども学びがあった。
  • あと、全体的にレベルが高すぎて震える。

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

＜ポイント＞

システムと 開発の雰囲気

  • Java と Ruby をメイン言語。

  • 「Ruby は好きで、20 年くらい使ってる」

  • スケーラリビリティ →1 億接続に耐えるレベル

  • ejabberd を選定した大きな理由は、Erlang の処理系でクラスタを担保しているから。

  • 社内で Erlang を使っているプロジェクトはなかった。

  • ＜ API ＞＋＜常時接続サーバ＞＝＜ API：Ruby on Rails ＞＋＜常時接続（プッシュ通知で利用）：Erlang/OTP + ejabberd ＞

  • 技術キャッチアップは、書籍と勉強会。

  • 負荷試験でわかった問題を１つずつ PDCA を回した。

  • 全世界の Switch が同時にログインしてきても、30 分でログインできるのが要件。

  • ログ処理の改善の結果、2 時間が 30 秒に。

  • 「もう大丈夫。このときはそう思ってました。」

  • Redis が想定の 5 倍 →Redis がシングルスレッドなのでスケールできない

    • 問題を仮定として特定するが。。。本当にこれかが、わからない。
    • 本番が動いているから、デプロイ出来ない？
    • 手作業で hot code deploy。
    • 直接、ErlangNode にタッチして更新。
    • 怖かったから。トリプルチェック＋ 2 回テスト環境で試してから、本番にて実施。

結果

  • 1000 万+ 同時接続
  • 20 億 通/日
  • 2 年超立っているが、本番でクラスタ停止は一度も発生していない。

＜所感＞

  • 「Erlang について、社内で今までナレッジがまったくない状況から開始して、最終的に同時接続 1 億台数に耐えられるシステムを書いた」ということに震えた。特に Erlang の有識者がリードしていくのではなく、社内にいるエンジニアがキャッチアップして開発を進める、ということで、割と衝撃を受けた。
  • QA の時間がめちゃくちゃ長く取ってあり、様々な QA があったが、ほぼすべての質問に対してすでに先回りしてどこまで答えて OK か？の許可を取っていた。「こういう点からも Nintendo 様のエンジニアすごい」となる。

総括

  • Elixir は、Phoenix だけでなく Nerves も熱くなってる（Nerves ＝ IoT・組み込み系・FA 系とハード寄り）。

  • 言語名の Elixir はファイナルファンタジー由来ではない（衝撃の事実）。