Elixir Conf Japan 2017 に参加しました

弊社がミッションクリティカルなシステムを構築する際には、実績やノウハウが充実した固い技術要素を選択することも多いのですが、絶え間無く進化する技術の恩恵を享受すると共に自身もコミッタとして貢献するべく、先端技術のキャッチアップにも注力しています。そんな技術調査の一環として4月1日、秋葉原コンベンションホールで開催されたElixir Conf Japan 2017に参加してきました。
未だ社内には採用実績が無くウォッチャーも少ない言語の為、言語仕様と歴史的背景の大まかな理解のみを携えて、まずは採用事例やその背景を伺う事を目的としました。

Elixir とは

Elixirは、一言で言えば「モダンなErlang」です。Erlangは30年前から電話会社のネットワークシステムを支えてきた、耐障害性と強力な並行処理のサポートを持つ言語で、それらの実装を支えるライブラリとデザイン集である「OTP」とセットで多くの場合「Erlang/OTP」と呼ばれます。

ErlangはWebサービスの様な高レベルなアプリケーションサーバではなく、低層のネットワークサーバやミドルウェアが主用途とされてきた為、独自の発展を遂げて仕様やライブラリやビルドシステムは一般的に馴染みのある他言語の使用感とは一線を画していました。

Elixirは、Erlang/OTPの特長はそのままに、近年のトレンドであるパッケージ管理やビルドの仕組やメタプログラミング、LL風のプログラミングスタイルといった物を持ち込んで、世の中の多くのプログラマーにとって馴染み易い言語となっています。

紹介リンク
1. Elixir School
2. 最近話題のWeb言語 Elixirのご紹介（2015年11月の記事）

Elixir Conf Japan 2017 概要

[発表資料]
Elixirのコミュニティの活動としては、 Sapporo.beam や tokyo.ex と言ったイベントが開催されています。そんな中、今回のカンファレンスはElixir作者のJosé Valim氏を招聘し、300人規模の会場で9時間で8セッション・8LTと日本では過去最大規模のイベントとなりました。有料(¥4,000)にも関わらず前日には参加枠が埋まり、当日はホールも懇親会会場も満員御礼の大盛況でした。

まだ若い言語だけあってセッションでは「運用してみて課題が見えて来た」「本格的な稼働はこれから」といった報告が多めでした。またElixir Confと銘打ちながらもErlang/OTPの話題に触れる機会が多く、「Erlang/OTPを使う手段としてのElixir」という位置付けの印象が強かったです。事実、主催者の方を含め複数の人が「次回は”Erlang & Elixir Conf”で良いんじゃないか？」との感想をお持ちの様です。

参加者層は（あくまで見た感じでの主観ですが）幅広い年齢層、女性が3～4％、外国人が5％くらい？という印象でした。9割9分がMBP/Macbookでした。開演の挨拶で「メリットを強調しようとすると他をディスる論調になりがちだけど絶対やめて！！！」と強く釘を刺されていました。

Opening Keynote - José Valim さん

オープニングの基調講演は、Elixirの生みの親による、Elixir誕生前夜の舞台裏から今後の展望について。Railsのコアメンバーでもある同氏は、Rubyで並行プログラムを安全にかつフル活用する良い方法が見付からず悩んでいた所に Seven Languages in Seven Weeks でErlang/OTPを知り、並行プログラムとの親和性の高さや安全性に惹かれ……といった所から始まり、メタプログラミングの導入と明示性の確保の間の苦悩等、言語開発者ならではの興味深い示唆と人間味の混じった誕生秘話が披露されました。今後の導入予定として語られた内容は以下1～3です。

1. UTF-8 Atoms (in progress)

日本語でテストが書ける
~~Emojiでソースが書ける~~

from 🍺 in 🍻,
    order_by: 🍺.💰,
    join: 🍗 in assoc(🎉, :🍴)
    |> Repo.all
    |> Enum.each(💸)

2. genHTTP (early research)

HTTPに応答するlow levelなビヘイビア？名前からして超気になる所ですが詳細は聞き取れませんでした。
Type System (early research)
静的型付け！公言したのはメーリングリスト含め今会場が初めてだそうです。どよめきました。
現時点では、ErlangVMには所謂厳密な静的型システムが有りませんが、Dialyzerという静的解析ツールをコンパイル後に実行する事でチェックする事が出来ます。ただ後のvoluntasさんのお話によると1万行のモジュールの解析に1分近くかかるとの事
また懇親会で伺った話によると skirino/croma というツール(日本の方!)を提供されていて、マクロによりコンパイル時の型チェックを実現できているという事でした。

import Croma.Defun
defun f(a :: integer, b :: String.t) :: String.t do
  "#{a} #{b}"
end

3. Data Stream & Property based testing (early research)

QuickCheck的な物ですね

セッション 1 - Phoenix で作るスケーラブルなリアルタイムゲームサーバー - 株式会社ミクシィ XFLAG STUDIO 古城秀隆さん

「Elixir歴が日本一長い」と自負するXFLAGでの採用経緯と運用事例です。

利用用途

モンストのバックエンドの他、”XFLAG STATION”のアプリケーションサーバとしてElixir、Phoenixを使用中

モバイルゲームの特徴

大量の更新リクエスト
イベント開催中のトラフィック増
協力プレイなどでリアルタイム通信は当たり前。サーバからのプッシュ通信もしたい

Elixirがもたらしたもの

メモリがあふれない限り大量のリクエストを漏らさず打ち返す。スループットはリクエストの量とサーバリソースに対して概ね線形に推移する
ErlangVMのホットデプロイでクライアントを切断する事無くサーバサイドのバージョンアップが実現する……かに思えたが実際には不具合に悩まされた
VM内にバージョン違いのモジュールが一時的に混在したり、旧バージョンの関数への参照を保持していたプロセスが予期せず落ちたり等
※これはドワンゴさんも通って来た道ですね。
MySQLは大量のリクエストを受けると詰まる。ectoのプロセスが緩和してくれた

misc

モバイルは通信がよく切れたり別経路で再接続したりする。cowboyのWebsocketとRabbitMQによるpubsubで対応した
Erlangのデフォルトのpubsubはサーバのクラスタリングが必要だったためRabbitMQにした

セッション 2 - Elixirから始める関数型言語 - Claude Tech株式会社 CTO Perez Danielさん

会社でのElixir採用歴1年、Tokyo.exでもよく登壇されているとの事。関数型言語の初心者向けに、以下1～4の特徴やElixirでの使用方法についての発表でした。個人的には、知っている人には「ああ、あれね」で通じるが初心者にとっては宇宙語では…？という印象を持った発表内容とスピードでしたが、心配には及ばず好評のようです。

パターンマッチ
再帰
高階関数
不変性

セッション 3 - Elixir導入提案 - 株式会社gumi CTO 幾田雅仁さん

nine nines(99.9999999％)のSLAを実現できると知って以来Erlang/OTPに惚れ込み10年になる幾田さん。隙あらばErlangなErlangおじさん。「今後gumiはElixirとともにある。Python2は3へは移行しません」と宣言しました。社内外含め初の公表だそうです。Alchemist的には勇気づけられますが、pythonistaの心境や如何に。

10年前の職場で決済代行サービスにErlang/OTPを導入したが、Perlとの接続等もあって複雑な構造になり、勉強会を何度も開催しても後続が育たなかった。気付けば皆Scalaに行った
gumi入社後、認証・課金の共通基盤を手掛ける事になり、早速Erlangでの開発を決めて時雨堂さんに発注した。以来4年間、計画的停止とAWS障害の2回を除き止まった事が無い。サーバ運用が超楽に、かつ安く上がっている。しかしErlang/OTPで組まれたシステムのメンテナンスは相変わらずトラックナンバー1
Elixirは馴染みやすい文法でErlang/OTPの信頼性とスケーラビリティを享受できる
現在は基盤のErlang/OTPをElixirに置き換えつつある
まだ一般社員向けの体系的トレーニングには至っていない。ゲームのサービスとしてリリースされるのは3年程先か
Erlang/OTPのプロセス設計は他の処理系には無い特徴が有り難しい。Elixirでもその点は同様。教育でもOTPに重点を置いている
シンガポールにオフショア開発を委託した実績がある
Dynamoを使う上でectoは不要で、Plugとcowboyで充分だったのでPhoenixは採用しなかった
求人数を調べると辛うじてErlangに勝っていた。Ruby:5k Elixir:54 Erlang:46

セッション 4 - Elixir はリアルタイムWeb に強いというのは本当か？ - mururuさん

東京大学大学院の院生にして、時雨堂から高難易度の仕事を任されたり、サンフランシスコのErlang Factoryで飛び入りLTしたりと、日本屈指のErlang/OTP・Elixirのエキスパートmururuさん。まず「リアルタイムWeb」という言葉の要件を定義して、そこにElixirはどう寄与するか？というお話。

リアルタイムWebの課題
大量コネクション
ステートフル
低遅延
耐障害性
Erlang/OTPの軽量プロセスの特長
一般的なグリーンスレッドと比べてもフットプリントが小さく、大量に起動してもメモリフレンドリー
軽量プロセス間でデータを共有しないのでGCがプロセス単位。stop the worldしない
グリーンスレッドを謳う処理系も、実は内部にCooperativeな部分が相当残っているErlang/OTPは極めてPreemptiveなスケジューリング（※例えばgoroutineは”partially preemptive”とか言われていますね）
軽量プロセス間で独立しているので障害が他の軽量プロセスに波及しない。逆に軽量プロセス別に障害を監視してハンドリングする事も可能
リアルタイムWebシステムが抱える課題に対し、軽量プロセスがもたらすメリットを挙げた上で、「それでもそれらを正しく活かすプロセス設計は大変」
プロセス設計がプアだと、メッセージパッシングがボトルネックになってパフォーマンス劣化に繋がり易い
Phoenix 等のフレームワークに乗れば、複雑なプロセス設計を賄ってくれる

セッション 5 - Rubyist |> (^o^) |> Alchemist 〜Elixirの採用からサービス稼動までの記録〜 - 株式会社ドリコム大原常徳さん

ここまでとは毛色が変わって導入におけるチーミングや運用の話がメインでした。

RailsからElixirへの移行
開発者に求めるスキルは「テストが書ける」事が実務の壁。並行処理やプロセス設計への理解はレビュアに求めるスキル
Elixirを使えば並行プログラムは簡単に書ける、だが逐次処理はもっと簡単に書けてしまう。意識して並行化可能なプログラムを書く必要がある点は他と変わらない
Red-Green-Refactorのサイクルに「平行化する」（あるいは「しないと判断する」）ステップを加える。という提唱
一般的なHeartbeatによる死活監視だと、プロセスが死んでもSuperviserがすぐ再起動するので検知できない。対応した通知機構を持つ必要がある
Erlang/OTP,Elixirはバージョンアップの頻度が高い。しかもErlang/OTPとElixirとのバージョンの組み合わせの選択も発生する。Elixirが年2回マイナーバージョンアップ、Erlang/OTPが年1回メジャーバージョンアップ
デバッグ中にErlangで書かれたソースを読む機会が往々にしてある
関数型言語の学習にはHaskel入門がおすすめ（※と言ってもElixirにはプレーンな状態だと関数合成やらカリー化やらモナドやらも無いので意図して深みにハマらない限りそこまでモナモナしい領域には達しないと思います）

セッション 6 - ニコニコを支えるErlang/Elixir 〜大規模運用して初めて見えたアレやコレ - 株式会社ドワンゴ原耕司さん

ニコニコ動画のコンテンツ配信システム Dwango Media Clusterについて。開発者20人で55万行のErlangに2万行のRustなど文字通り桁外れです。残念ながらElixirの話はほぼありませんでした。DMCでは形式的記述で「レシピ」を書くとErlang/C++/Lua等々のソース6万行を自動生成とか、開発部門の作業スケジュールを工数と優先度から自動生成＆公開しているとかいった発表内容自体は面白かったです。

今回の発表では触れられませんでしたが、ニコニコ動画の生放送の配信システムでもErlang/OTPが使われていて、こちらは10万locという事が以前発表されていました。

巨大なバイナリデータをshared heap領域で管理し軽量プロセスはそこへのポインタを持つ形で構成していた。プロセスが死んだ後もshared heap内でデータが生き残り、毎時2GBのメモリリークが発生した。monitorが死んだプロセスのDOWNを発信しなかった。根本的に解決出来なかったが自力でmonitor_with_pollingして回避した。

LT

よくある勉強会のノリでみなさん思い思いの「作ってみた」等々披露されていました。時間切れの銅鑼の音が心臓に悪いと不評で、音量を控えめにしてからは「ホワァ～ン」と気の抜けた音になったりしました。

Why did we decide to start using Elixir?
by ma2geさん
楽しんで進化する為
「Surge」 - Amazon DynamoDB for Elixir
by hirocaster
AWSのSDKにElixir用が無かったので
初心者のElixir |> Flow,GenStage |> Concurrent MapReduce
by ovrmrvさん
Elixirと言えど気を抜くと逐次処理になるぞ、性能落ちるぞ、を端的に見せ付けられて非常に良かったです
Elixir client from OpenAPI(Swagger) definition
by niku_nameさん
SwaggerでElixirクライアントソースを生成
AngulaとElixirの新しい関係
by isyumi_netさん
[スライド]
サーバとクライアントの2階建てMVC辛い。FluxのView部分だけAngularで書いて、後は全部Elixir/Phoenixで提供して1階建てMVCにするという夢のような悪夢のような試み。この方式、個人的に将来性がとても気になります
ElixirでHubotを倒す
ne_sachirouさん
実家のような安心感のある結論でした
「APIサーバーとしてのCowboy」
by hayabusa333さん
日本で数少ない(少なかった)Elixir書籍、エーフィーのアトリエの著者としてお馴染みのはやぶささん、いつの間にドリコムに
「Erlang and Elixir Factory San Francisco Bay 2017 参加報告」
by jj1bdx (力武健次)さん
1週間の有料トレーニングの真ん中にカンファレンスがある、という日程
発表内容は濃い物も多いがトレーニーでも充分楽しめる
コンパイラの挙動の解説やノード間通信の可視化の話、FPGAとErlangなどコアな講演から、「言語がコミュニティの特徴を方向付ける」等と言った抽象的な物まで
日本人もどんどん登壇すべき。今日のConfを見て行けると思った

Closing Keynote - voluntasさん

日本でErlang/OTPと言えば時雨堂ですね。Elixirの話は皆無でWhy Erlang/OTPの話しかしない、との英断、見事にはまっていたと思います。

Elixirは使った事が無く使う予定も無い。皆Erlang書くの辛いと言うが、手を付けて10年で辛いと思った事が無い
Erlangを採用するシステムは内情が明らかにされないケースが多いので採用の実態は把握し難い。公に出来る情報は氷山の一角
誰もOTPの話をしなかったのが残念。mururuかgumiはしてくれると思ったのに
Erlang/OTPを軽く試してみたいならまずネットワークサーバを書いてみると良い。HTTPサーバでも、HTTPを超えるオレオレプロトコルでも
Erlangで書かれたシステムは大体1万行程度。ドワンゴの55万行は世界的に見ても大きい方
有名どころだとWhatsAppがユーザー10億人、秒間7000万リクエストを捌くのにエンジニアは30人。ErlangVMにも手を入れてる。ゲーム会社ではRiotがある（※ 昔からRiotではLeague of Legendsのチャットサーバに使われている事が公開されていましたが、最近ゲームサーバのメッセージング部分もErlangで実装しているという記事が公開されました。更にゲーム繋がり(?)で言うとDiscordでのバーストやバックプレッシャーの話も興味深いです。）
Why not Golang
goで良い。狭いながらもErlangが勝てる領域があるのでそこで戦っているだけ
Why Erlang/OTP
適当に書いても動く
適当に書いても落ちない。落ちる時も軽量プロセスが単独で逝く
適当に書いてもスケールする。ARM96コアで利用率8000％まで行けた
巷で「MacでErlang試してみたけど落ちたぞ」と言ってるのは大体FD枯渇。デフォルトでは256しかないので
DSLでネットワークサーバ関連の記述が充実しているので超短く書ける
プロセス設計は難しい。だから僕にプロセス設計の依頼が来る
パターンマッチ最高。一度経験すると無い言語には戻れない
クラッシュダンプが読み難い。皆一度は読んで絶望する
E2Eテストが容易。HTTP非同期のテスト等も実際のTCPコネクションを使って簡単にテストできる
Erlang/OTP関係で問題が起きてSOSが回って来る時は9割方RabbitMQ。辛いので大抵断る
軽量プロセスについて
Erlang/OTPは1プロセスでは性能が出ない。複数プロセスを起動すると綺麗に終わらせるのが難しい
supervisorが死んでErlangVMが死ぬ事はある。simple_one_for_oneでtemporaryで、死に際に綺麗にログを出して～とやりだすとsupervisor不要
軽量プロセスは実はしぶとい。殺したつもりのプロセスが生きていて「プロセスリーク」の状態になる。waitingでもなくshutdownの一歩手前で生き残っている事がある
毎秒10万メッセージ辺りでキューが詰まり出す。これはErlangVMのメッセージパッシング速度が上がらないとどうしようもない
RabbitMQの場合、キュー溢れに対する挙動は「キューを捨てて再起動」
OTP 20.0 coming
2017-06-21 にリリース
やっとシグナルがハンドル可能になる。今まではCtrl+Cで止まらない等、コンテナ技術と相性が悪かった
stringモジュールがUnicode対応
古い言語の割にドラスティックにソースを変更する
etsが性能向上する
JITはLLVMベースで実験中

懇親会

スリーモンキーズカフェにて。会場は「最大300人」を謳ってますが相当すし詰め状態でした。そしてビュッフェの料理がデプロイされるテーブルがシングルスレッドでキュー溢れしてました。
私は初手でディープな方々のテーブルに突撃するのはハードルが高かったので比較的親しみ易い話題のテーブルをうろうろしていましたが、感想として多かったのは「やっぱりErlang/OTPか」と「どこに使えば良いんだ…？」でした。自己紹介すると「エンプラでElixirって使うんですか？」と訊かれ「それを探りに来ました」と返す会話が多かったです。そこは予想していた通りでしたが、使える場面を考える上で開発者の確保（教育/採用/調達全て込みで）はどうしたもんだろうねという話は、ほとんどど通じなかったのは意外でした。

まとめ

今回のElixir Conf Japanを通してのトピックを以下にピックアップします。

まずErlang/OTPの概念と現実から始めよう。すごいE本を読もう！
Erlangは遅いがスケールする
プロセス設計は難しいがPhoeninx等のFWの恩恵に預かれればその限りではない
導入も教育もまだまだ手探り中

なかなか使い所に迷う技術ではあるものの、１プログラマーの視点で見れば「書いていて楽しい」という最高に魅力的な言語には違いないので、引き続き知見を積んで行こうと思います。

Elixir Conf Japan 2017 参加レポート