なぜ Elixir か

• このページの目標
  • Elixir の採用理由を認識する
  • 社内発フレームワークAntikytheraの目的意識を大まかに把握しておく
• 所要時間: 10 分程度

• サーバサイド開発には多くの言語やフレームワークが使われている
  • C++
  • C#
  • Erlang
  • Java
  • Perl
  • PHP
  • Ruby
  • Python
  • Node.js
  • Scala
  • Elixir
  • Go
  • Rust
  • Haskell
  • ...

そんな中で、IoT 事業部は近年、Elixir を標準としている。

なぜ ACCESS の IoT 事業部は Elixir を選んでいるか？

• Erlang VM では複数の「アプリケーション」を同時実行できる
• さらに、稼働中の VM に対し、個別のアプリケーションの更新を無停止で適用する仕組みがある(Hot Code Upgrade)
• すると、「共有された Erlang VM クラスタを用意し、そのリソースを複数案件で分譲利用する」ような環境を構築できる
  • まさにこれが社内発の Elixir 製 OSS フレームワーク・Antikytheraの目指すところ

• Antikythera以前、社内では案件ごとに個別の技術選択、CI/CD 環境・実行環境管理が行われていた
  • 今も多少は行われている
• どうなるかというと、
  • 利用する言語・フレームワーク・パッケージ、及びそれらのバージョン不一致やアップグレード不備
    • 知識・コードの共有を困難にする
    • 担当者多忙・不在・退職による放置はセキュリティリスクにつながる
  • 本質的なアプリケーションの実装以外のタスクが増加
    • 複数案件を高速に展開するにあたっての障害(オーバーヘッド)となる
    • 環境構築・インフラ管理等はそれ単体でもかなり専門性が高く、 注意しないとやはりセキュリティホールを拵えたり、コスト割高な構成を組んでしまったり
  • これらが複合的に重なると、アプリケーション自体の品質にも下げ圧がかかる
    • 人的・時間的リソースが不足
    • 自動テスト・継続的デリバリの慣習が不在

• Elixir 自体、
  • 公式ツールチェーンが充実しており、
  • 文法機能が比較的強力な割に、読みやすく迷いにくい言語で、
  • それでいて掘り下げれば高度な機能も充実していてリッチなフレームワークを構築できる
• と、統一サーバ言語として好ましい特徴を備えている
• ということで、2015 年からAntikytheraの開発が始まり、2016 年から実際に商用利用開始。 最近では特別な要請がない限りはAntikytheraを利用したサーバ開発を行っている

• 気づいたかもしれないが、現在社内的には Elixir の使用とAntikytheraの使用は実質不可分
  • Antikytheraの社内環境が整う以前には Elixir のデファクト・スタンダードな Web フレームワークである Phoenixを使った案件もあったが、今はまずない
  • 一概に、今となってはAntikytheraなしでは Elixir を使う理由がないというわけでもないが、 少なくとも社内ではAntikytheraの提供する利便性はそれだけ大きい
    • 案件個別の実行環境・CI/CD 体系を準備しなくてよく、即座にサーバ開発を開始し、デプロイまでできる
    • 便利な共通機能(非同期ジョブ実行機構、WebSocket プロセス管理機構、標準暗号ライブラリ、etc.)が整備されている
    • 依存ライブラリのバージョン管理や、全般的なセキュリティ調査・対応などを専属チームが統率してくれる
    • 静的アセット配布のための CDN 連携がついてくる