「Elixirの生産性／エコシステムが想像以上！
カラビナテクノロジーに訪れたバックエンドのリストラ」
カラビナテクノロジー株式会社は、「”想像力”を”現実”に繋げる」を合言葉に、システム開発・アプリ開発・ウェブサイト制作を行なっています。
今回は、「顧問エンジニアチーム」を組んでお仕事をされている3名のうち、吉村さんと奥屋さんに、Elixirを使用することになった経緯や、実際に案件に使用しての現状についてお話を伺いました。
顧問エンジニアチームの3名（左から川上さん、吉村さん、奥屋さん）
――「顧問エンジニアチーム」では、どのようなお仕事をされているか教えてください。
奥屋：ツチローさん（吉村さん）と、リーさん（川上さん）と僕の3人で、顧問エンジニアチームを組んで仕事をしています。その中で、僕はフロントエンジニアを担当しています。
「顧問エンジニア」は、「アイデアはあるけどそれを実現する手立てが無い」というお客様に対して、Webシステムやアプリケーションを一緒に作っていく事業です。
仕様が固まっていない状況から、一緒に頭を捻って、共に作っていくという特徴があります。
そこで僕は、フロントエンドを担当していて、画面のデザインとフロントテンプレートのコーディング、それらのバックエンドとの繋ぎ込みしていて、インタラクションやアニメーションを実装するところまでを担当しています。
デザインツールはFigmaやXD。フロントエンドフレームワークはAngularを使用しています。
吉村：顧問エンジニアチームは、最終的には、3人共にデザイン／フロント／サーバの全ての分野を各々ができるようになることを目標としていますが、今はまだ始めたばかりということもあり、各自の得意分野を一手に引き受けるような担当割りをしています。
その中で僕は、バックエンドを引き受ける担当で、画面操作後のデータをサーバ側で受けるAPIと、その後のセッション処理やDB処理を、Elixirで実装しています。
お客様から見える部分では無いのですが、逆に言うと、お客様にはよく分からないけど、業務の整合性には最も重要な部分のデータを扱っています。
――Elixirを知ったきっかけと、Elixirを導入することになった経緯は？
吉村：前職が、fukuoka.exを主催している森さんと同じ会社だったこともあり、Elixirの社内勉強会に参加して、面白そうだったのがElixirを試したきっかけです。
その後、Elixirで作ったものを、fukuoka.exのMeetUpでElixirの特性を紹介するコンテンツとして登壇したりもしました。
同時期に、顧問エンジニアの1人であるリーさんも、fukuka.exに参加していて、彼は、元々Pythonでシステムを作っていたんですが、それに代わる別の言語を探していたんですね。
受託開発の場合、お客様側に開発言語やシステム環境の選択権があることが多いですが、顧問エンジニア事業のお客様は、システムや開発言語の知識があることは少なく、サービスのアイデアのみで勝負するお客様が多いため、言語や技術の選択は、われわれに任されます。
とはいえ、3人のチームで、色んな言語を並行して扱うのは難しいため、どれかに絞ろうと。
使っている人が多い言語としては、一般的にJava、PHP、Rubyなどがあります。しかし、今後の展望として、サービスが急激に成長したり、並列性を求めたり、IoT等での利用も見越した大量データ処理が必要な場面では、RubyやJavaだと生産性や性能に問題が出てくるのは、目に見えています。
では、それに代わる言語は？、と考えたときに、Elixirという選択肢を取りました。
――Elixirを使用するにあたり、一番の決め手となった部分は何だったのでしょうか？
吉村：既存のオブジェクト指向言語と比べて、並行性・並列性が最初から考慮されているところが大きかったです。
プログラムの言語使用的な側面から、オブジェクト指向言語では、大量のデータを処理する際、どこかが必ずボトルネックになり、一部の更新を待って他が返せなくなる傾向が頻繁にあります。
その一方で、Elixirは関数型言語であり、イミュータブルであり、基本的には状態を持たない、というところや、コアであるErlangVMが電話交換機の構築からスタートしているので、大量の情報を並行で捌いていける実績が多かったことが魅力的でした。
今年2月に、リーさんがRubyのコードをElixirに置き換える作業をしたのが、実案件での最初のElixir利用なので、Elixirを業務で使用し始めてから半年経っていますが、だいぶこなれてきた感じはありますね。
導入実績も、ライブラリも、どんどん増やしていますが、それでもまだ少ないことに、やや不安は感じるときもありますが、今後、大量データを処理する必要性が出てきたときに、言語変更の手間を省くことができる、というところの期待の方が大きいです。
――実際にElixirを使い始めた後の感触は？
吉村：僕が関数型言語に触れるのが初めてだった、ということもありますが、最初は戸惑いました。おそらく、既存のオブジェクト指向言語に触れていた方は、同じ流れを辿るのではないでしょうか。
関数型言語に慣れてくると、厳密なパターン定義などしなくていいことや、関数で書くからオブジェクトの設計をやらなくても、アプリが出来上がることに慣れてきます。
そんな風に慣れた後の今、僕が最も懸念していることは、これはElixirに限らずなんですが、一般的にデータベースがシングルポイントとしてボトルネックになり、システム全体の足を引っ張ってしまうことです。
課金的にも、データベースは、なかなか安くならずに、サーバはどんどん安くなっていきます。そのため、データベース側の性能に任せて行っていた「SQLでねじ伏せる処理」の部分を、APサーバ側のElixirの方に寄せていき、データベースからシンプルに取り出した単独データを、APサーバ側でSQLのように加工して出す、というスケールアウトのアーキテクチャを試している最中です。
それを作っているときに思ったことは、「SQLって偉大だったんだな」と（笑）。
Elixirは、JavaやGoよりは、書くコードが少ないのですが、それでもSQLだと一言で書けたことが、数行書かないと実現できなかったりする訳です。
ただ、だいぶ構築は進んだので、このアーキテクチャでSQLとほぼ同程度に書いていくことが可能になりつつあります。
このアーキテクチャにより、データベース性の負荷はだいぶ下げられているはずです。今後、性能テストに入っていくんですが、実際に運用を始めて、お客様がユーザを大量に獲得できてから効果を発揮するんじゃないかな、と思っています。
一方で、GraphQL等、SQLとは別アプローチで楽にするための次の技術が出始めてもいるので、そちらにもトライしないといけないと思っています。
今、開発が大詰めになってきている案件が３社ありますが、初めから大量データの取得が必要なお客様って、実はまだいらっしゃいません。小規模なところから運用をスタートして、いざ大量ユーザを獲得したときに、今までの苦労の成果が見えてくると思います。
――今後、Elixirをどのように使用する予定ですか？
吉村：マッチングサービスとして「誰かと誰かをシステムに繋げる」というサービスの需要が高いことを見越して、再開発せずともサービスを立ち上げられるような、弊社独自のElixirフレームワークを拡充している最中です。
仕事量でみると、Elixirの部分よりは、フロント側で実装する、お客様固有の画面の部分がどうしても手がかかります。
Elixirで作るバックエンドの仕組みは、お客様からすると「どうでもいい」ところなんですが（笑）、「画面が他社と一緒でもいい」というお客様は、顧問エンジニアの業務特性上、基本的にいませんので。
お客様毎のフロントエンドの満足度を向上させる活動に集中できるよう、バックエンドの都度構築をしなくて済むElixirフレームワークを作り込んでいます。
「mix deps.get」でインストールするだけで、ユーザの登録だったり、パスワードの設定だったり、AさんとBさんを繋いだり等、どんなシステムでも必要となる基本部分は、パッケージ化してしまいたい、と考えています。
このパッケージを使えば、「どんな条件でAさんとBさんを繋げたいの？」のような、お客様固有のところだけをカスタマイズすれば、バックエンドの構築は終わりです。
その結果、残りのフロント側の実装を3人で取り掛かれば、最初にお話したような、3人共に全ての分野を各々ができる状態に限りなく近付きます。
そして、実務面だけで無く、このフレームワークを「企業もオープンソースを作る」という流れの中で、弊社もオープンソースを提供する会社である、というブランディングとしても打ち出していければなぁ、という風に思っています。
Elixirだと、言語仕様的な使用例はありますが、デザインパターンなど、業務に活かせるものは、まだまだ少ないけど、今後、Elixirを使用する会社が増えれば増えるほど、その流れは加速していくので、これからが楽しみです。
言語は、通常プログラムを書くためのものですが、それだけでは流行りません。そこに、簡単にWebが作れるPhoenixなどのフレームワークだったり、ライブラリが管理できるHexがあってこそだと思います。
Javaも、Jarで固めたライブラリがどんどん増えていって盛り上がっていった経緯がありますし、RubyもGemでどんどん増えていった…と考えると、ElixirもHexを使ってリリースされたオープンソースライブラリが増えていけば、完全にその流れに乗るのかな、という気はします。
奥屋：今、3～4案件のサーバサイドを、ツチローさん1人で担当しています。
最初、ツチローさんとリーさんが2人でElixir担当、僕1人でフロントという体制でやっていたんですが、Elixirの生産性の良さが段々出てきて、ツチローさん1人でバックエンドは賄えるようになっていきました。
逆に、フロントの仕事量は、当初想定よりも多くて一杯一杯で、僕とリーさんがフロントをやる形にスライドしています。
吉村：Elixirのエコシステムが、思った以上に優れていたため、バックエンドに手が掛からないんですよ。
今、Elixirで一番、手が掛かっているのはテストです。
Phoenixは、APIも、そのテストも自動生成してくれますが、お客様の業務要件に合わせていくと、それだけで済まないことも多く、プログラムを書き換えて、テストも書き換えて、というところで、どうしても手間がかかっています。
とはいえ、先程お話したようなフレームワークのように、類似するサービスの最大公約数を基に作ると、テストも同じものを使うので、バックエンドはどんどん楽になっていくんです。
あくまで、「弊社で対応したことのある、同じような案件のお客様の中で」という前提付きにはなりますが、これはかなり有効です。
そして、今までのお客様と違った分野が発生したら、1つずつ押さえていけばいくほど、穴が埋まっていきます。
奥屋：今は、お客様の要望的にも、フロントエンドの方が、どんどん高度な要件が出てきている感覚で、そちらの方が追いかけるのも大変だし、手数もかかっている状況ですね。
吉村：なので、開発全体としては、いかにバックエンドに手をかけないようにして、フロント側の工数をより多く担保していく、というところが、われわれの現状課題です。
Elixirを使い始めた当初は、大量データでも耐えられる性能や並行性に着目していたんですが、直近では「いかに楽にバックエンドを実装できるか？」が、Elixirで叶っている領域で、だいぶ省略化できていますね。
Elixirは、アプリ開発への抵抗感が低く、最初にかける気合いみたいなものが、他言語と比べたら、だいぶ軽いことは確かです。
