Elixir を何故採用したのか - c4se記：さっちゃんですよ☆

Elixir Advent Calendar 2019 - Qiita 12/11

Kubernetes を何故採用したのかの續きだ。各項目の一般的な前提も前の記事に準ずる。よって讀んでくださってゐる事を期待する。

下記 slide 時期の昔話をする。何故技術撰定で Elixir を採用したのか。

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

採用後の具体的な運用の話はしない。それが今でも役立つ話題なら別にしやう。今でも個人的に Elixir を續けてゐる理由もここの話題ではない。

何が嬉しいか?

當時 game の rule や cycle は決まってゐなかった。しかし何人かで PvP を realtime に行ひたい、同時に行なはれる PvP は非常に多い (多くしたい) 事は判ってゐた。

組織內での第一の撰擇肢は Rails であったから先づは Rails を檢討した。求められる realtime 性が定かではない。rule や cycle を檢討してゐる途中なので出來るだけ柔軟性を保ちたかった。詰まり常時接續通信 (front は Web front であったから WebSocket の事である) で realtime PvP が行なへれば好ましい。勿論 realtime 性を減じれば Rails で實裝出來る。

realtime 性を減じて Rails で實裝する
RabbitMQ で client を仲介し、對戰 logic は client に持たせる。RabitMQ で MQTT を介し PvP する前例は經驗を有する。Web front で高速且つ派手な描画をする前例は無かったから描画するだけでも risk であり、更に複雜な logic と云ふ risk を client に持ち込む事に成る
Photon。これは組織內で現役であった。ただし Photon 側に對戰 logic は無く Unity で實裝した client 側に有る。それに WebSocket の實績は身近には無かった
Elixir / Phoenix。Elixir 自體の運用經驗は有ったが單純な HTTP API server である。Phoenix も同樣
node.js。この運用經驗も組織內には有る
Go。新規

柔軟性を保ち、安心して運用出來、手慣れてゐ、好みであり、組織內に知見が有る Elixir / Phoenix に決めた。

Phoenix.Channel の backend は Redis である。Redis の運用經驗は豊富であった。Redis で安定して性能が出せるかは不安であったから、随分後まで NATS や Kafka を檢討してゐたが、Redis で充分であった。

作り切れるか?

若し動く物が作れるなら必ず早目に動く物を作ってみなければならない。

既に dummy 的に作られた server が有った。これを模倣する事から始めた。docker-compose、lint、test を調へながらやり、二週間ほどで模倣出來た。dummy は chaos な實裝だったが、模倣はこの時既に函數型 paradigm で game logic を model 化してある。この model 化は假に Elixir を止めても役立つ筈だ。2 つの client で WebSocket を介して對戰出來る樣に成った。

Elixir が動く Erlang VM は實績の多い VM で、規模の大きな常時接續を捌く事で有名だ。

始めは全て Elixir で作る積りだったが、risk が大きく成り過ぎるので、Elixir は新しい PvP のみに限定し、手慣れた残りは手慣れた Rails で作る事に轉換した。これは話し合って決めた (他は決めてから話し合ってゐる……)。

これらから作り切れると判斷した。

また fallback 先としては、realtime 性を減じてでも Rails で實裝出來る見込みは有った。この場合經驗の豊富な者が組織內に多く、助けも借りられる。

運用出來るか?

TCP 接續はともかく、WebSocket をスマホから大量に繋ぎ維持する經驗は誰にも無かった。よってこれは實地試驗や負荷試験をする迄判らない。多分もっと早く實地試驗と負荷試驗をするべきであった。Erlang と Redis の實績は世間的にも豊富だったから油斷してゐたのだ。結果的にはうまくいったが、これは考へられたものではなかった。

Erlang, Elixir, library の ver.に就いて。minor ver.には即座に追隨する。Erlang, Elixir は經驗からすると minor ver.の互換性は安定してゐるから、即座に上げられないなら組織に問題が有る (Erlang, Elixir の話であり他には該当しないかもしれない)。minor ver.の更新で困る library は捨てるべきだ。major ver.の更新には 1 つ遲れ以內で着いてゆく。これらを早く決めた (明文化したのは大分後だが)。

開發を速く保ち續けられるかも大切だ。これは Elixir に依らない部分が大きい。開發の課題を繼續的に解決出來るか、その cost を如何に払うかは Elixir であってもなくても變はらない。作るものの genre に依る。Elixir が特別 refactoring しづらいなら考へるべきだが、函數型に依り明示的な programming を行なひ、test も書き、process の樣子も見易いならそれ以上特別に考へる事は無い。

人を増やせるか? team を作れるか?

これは難しい所だ。業界で Elixir が支配的に成る事は考へられない。

今から振り返るとこれは失敗したと言へる (更に未來の事はここで話題としない。失敗は一時的なものであり得る)。新しい開發が得意な者は難なく Elixir を習得した。他の product でも Elixir で開發が進んでゐ、組織の backup も得られると油斷した。一時的には成功したと言へる。業界的な圧力が無い所に私が Elixir を広めるのに失敗したと云ふ事だ。その面では Go を使ふのが好かっただらう。支配的には成らなくとも、もう少し魅力を増せれば好かったと思ふ。今後の課題である。

とは云へ巨大でもない組織 Go にも Elixir にも投資する事は無理だから、他の開發も進んでゐる事であったし Elixir を撰んだのは妥當だったと思ふ。